ai-workflow-harness
Health Warn
- License — License: Apache-2.0
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Low visibility — Only 5 GitHub stars
Code Fail
- rm -rf — Recursive force deletion command in .claude/settings.json
- rm -rf — Recursive force deletion command in scripts/create-harness.sh
Permissions Pass
- Permissions — No dangerous permissions requested
No AI report is available for this listing yet.
A manual-first, approval-gated AI workflow harness for Claude Code, Codex, and Cursor. (계획·승인·검증·기록으로 이어지는 AI 개발 하네스)
ai-workflow-harness
A manual-first, approval-gated AI workflow harness for Claude Code, Codex, and Cursor.
(계획·승인·검증·기록으로 이어지는 AI 개발 하네스)
AI 코딩 에이전트와 반복 세션을 운영할 때 발생하는 범위 확장, 상태 불일치, 승인 없는 실행, 결정 기록 소실을 workflow 엔진 없이 문서와 명시적 gate만으로 제어한다.
Quick Start
[!NOTE]
fork / clone 후 신규/기존 프로젝트에 적용하려면:
- §10 New Project Adoption 확인 — scaffold 명령 실행
docs/SCAFFOLD-ONBOARDING-GUIDE.md따라 첫 세션 진행이 repository 자체를 직접 project-local workspace로 전환하지 않는다.
Table of Contents
- Quick Start
- Prologue
- 1. What This Harness Is
- 2. Document Layers
- 3. Session Lifecycle
- 4. Work Selection And Routing
- 5. Approval Matrix
- 6. STATUS And Work File Rules
- 7. Command Map
- 8. Trigger And Cascade
- 9. Git Flow
- 10. New Project Adoption
- 11. Key Documents
- 12. Repository Layout
- 13. Validation
- 14. Origin
- 15. License
Prologue
Claude Code, Codex 등은 강력하지만 context를 잘못 관리하면 세션마다 동일한 설명을 반복하거나, 승인 없이 범위를 넘는 작업을 수행하거나, 결정 사항이 사라지는 문제가 생긴다.
이 하네스는 그 문제를 직접 경험하고, 실제 프로젝트에 적용하면서 발견한 마찰을 하나씩 문서와 규칙으로 굳힌 결과물이다.
여정 요약: 첫 commit 이후 340여 개의 commit을 거쳐 2026-05-24에 첫 안정화 기준선을 태그했다.
ai-workflow-v1.0.0 — Lightweight Manual-First AI Workflow Harness v1
이 tag가 가리키는 의미:
- 전역 행동 원칙, 실행 규칙, 상세 protocol, 사용자 매뉴얼이 계층화되었다.
- Claude, Codex, Cursor, prompts, scaffold가 같은 핵심 계약을 참조한다.
STATUS.md는 dashboard, Work 파일은 작업 단위 SSoT로 분리되어 관리된다.- Approval Matrix로 scope, state update, commit gate가 하나의 기준으로 정리되었다.
- Multi Active Work 지원 — Work 파일 단위 SSoT로 컨텍스트를 분리해 여러 작업을 병렬 추적한다.
이후 변경은 v1.0을 더 키우기보다 실제 사용 중 발견된 반복 실패를 기준으로 작게 보정하는 방향으로 진행할 예정이다.
환경 지원: Primary macOS / Expected compatible Linux·WSL·Git Bash / Planned Windows native.
scaffold script와 일부 validation 예시는bash, Unix-style path,python3를 전제한다. Windows native 지원은HRN-032에서 추적한다.
1. What This Harness Is
AI Workflow Harness는 AI 세션을 감싸는 운영 구조다.
목표는 작업 상태, 승인 지점, 검증 결과, 결정 근거를 repo에 남겨 다음 세션과 다른 Agent가 이어받을 수 있게 하는 것이다.
| Problem | Without Harness | With Harness |
|---|---|---|
| Context 반복 설명 | 매 세션 다시 설명 | STATUS.md와 Work 파일로 복구 |
| Scope drift | AI가 선의로 범위 확장 | Approval Matrix로 중단 |
| 상태 소실 | 대화 기록에 의존 | repo-visible dashboard와 Work SSoT |
| 결정 근거 소실 | commit 또는 기억에 의존 | DR과 Recent Decisions로 보존 |
| 도구 전환 drift | Claude/Codex/Cursor가 다르게 행동 | 공통 원칙과 tool-specific 진입점 정렬 |
핵심 원칙:
- Behavior Principles First — 속도보다 신중함과 안정성.
- Context Is Limited — 필요한 파일만 읽는다.
- Plan Before Implement — 실행 전 범위, 파일, 검증, 리스크, 되돌리기 비용을 보고한다.
- Approval Before Risk — scope 확장, 상태 변경, commit은 gate를 통과한다.
- Surgical Changes — 요청된 최소 범위만 바꾼다.
- State Is Repo-Visible — 다음 Agent가 기억 없이 이어받을 수 있어야 한다.
워크플로우 엔진 없이 문서와 명시적 gate만으로 제어한다. AI 파이프라인 자동화보다 AI와 협업하는 방식을 먼저 정립하는 단계에 맞는 도구다.
2. Document Layers
Harness 문서는 역할별로 계층이 나뉜다.
세션 시작 시 기본값으로 읽는 것은 BEHAVIOR-PRINCIPLES.md, AGENT-WORKFLOW.md, STATUS.md current sections뿐이다.
조건이 생길 때만 해당 문서를 추가 로드한다. 상세 routing 기준은 docs/AGENT-WORKFLOW.md 참조.
flowchart TD
subgraph ENTRY ["Tool Entry Points"]
CLAUDE["CLAUDE.md\nClaude"]
AGENTS["AGENTS.md\nCodex"]
CURSOR[".cursor/rules/*.mdc\nCursor"]
end
subgraph CANON ["Canonical Rules"]
BP["docs/BEHAVIOR-PRINCIPLES.md\n전역 행동 원칙"]
AW["docs/AGENT-WORKFLOW.md\n공통 실행 규칙"]
HP["docs/HARNESS-PROTOCOL.md\n상세 protocol"]
HQ["docs/HARNESS-QUICK-REFERENCE.md\n실행 quick reference"]
end
subgraph STATE ["State And Work"]
STATUS["docs/STATUS.md\n현재 dashboard"]
BACKLOG["docs/backlog/\n후보 작업"]
WORK["docs/works/\nWork SSoT"]
DR["docs/decisions/\nDecision Records"]
ARCHIVE["docs/archive/\n완료 이력"]
end
subgraph SURFACE ["Reusable Surfaces"]
COMMANDS[".claude/commands/\nClaude workflows"]
RULES[".claude/rules/\npath-scoped guardrails"]
CURSOR_RULES[".cursor/rules/\nCursor rules"]
SKILLS[".agents/skills/\nCodex skills"]
HOOKS[".codex/hooks.json\nCodex hooks"]
PROMPTS["prompts/\nfallback/task templates"]
SCRIPT["scripts/create-harness.sh\nproject scaffold"]
end
CLAUDE --> BP --> AW --> HP
AGENTS --> BP
AGENTS --> AW
CURSOR --> BP
CURSOR --> AW
AW --> STATUS
STATUS --> BACKLOG
STATUS --> WORK
WORK --> ARCHIVE
STATUS --> DR
HP --> HQ
HP --> COMMANDS
AW --> RULES
AW --> CURSOR_RULES
AW --> PROMPTS
HP --> SCRIPT
%% Layout hint: place reusable surfaces below the main document layers.
ARCHIVE ~~~ COMMANDS
DR ~~~ PROMPTS
style BP fill:#f8d7da,stroke:#dc3545
style AW fill:#ffeeba,stroke:#ffc107
style HP fill:#d4edda,stroke:#28a745
style STATUS fill:#d4edda,stroke:#28a745
style WORK fill:#d4edda,stroke:#28a745
위에 포함되지 않은 User-facing docs(WORKFLOW-MANUAL.md, docs/retrospectives/, docs/troubleshooting/)는 평시 AI reading path에 포함하지 않고, 사용자가 매뉴얼 검토를 요청했거나 user-facing cascade가 필요할 때만 확인한다.
3. Session Lifecycle
모든 작업은 같은 state machine을 따른다.
flowchart TD
INIT["INIT\n상태 확인"] --> PLAN["PLAN\n범위·파일·검증·리스크·되돌리기 비용"]
PLAN --> APPROVAL{"APPROVAL\n사용자 승인?"}
APPROVAL -- "수정 요청" --> PLAN
APPROVAL -- "승인" --> EXECUTE["EXECUTE\n승인된 범위만 변경"]
EXECUTE --> VALIDATE["VALIDATE\n테스트·diff·링크·scaffold 확인"]
VALIDATE --> PASS{"통과?"}
PASS -- "아니오" --> FAIL["FAIL\n원인·영향·복구 옵션 보고"]
FAIL --> RECOVER["RECOVER\n계획 수정 또는 범위 축소"]
RECOVER --> PLAN
PASS -- "예" --> CHECKPOINT["CHECKPOINT\n필요한 상태 갱신·보고"]
CHECKPOINT --> END["END\n/done 또는 다음 작업"]
style INIT fill:#d4edda,stroke:#28a745
style APPROVAL fill:#fff3cd,stroke:#ffc107
style EXECUTE fill:#cce5ff,stroke:#004085
style FAIL fill:#f8d7da,stroke:#dc3545
style RECOVER fill:#fff3cd,stroke:#ffc107
/start또는 intent recognition으로 현재 상태를 확인한다./pick,/work,/resume,/debug중 맞는 흐름으로 진입한다.- Plan에는 Scope, Files, Verification, Risk, Reversal Cost를 포함한다.
- 승인 후 실행한다.
- 검증 실패 시 commit과 checkpoint를 만들지 않는다.
- Work 완료는
/close, 세션 요약은/done으로 분리한다.
4. Work Selection And Routing
STATUS.md는 dashboard이고, 모든 후보를 담는 backlog가 아니다.
flowchart TD
NEW["새 요청·아이디어·버그"] --> NOW{"지금 착수?"}
NOW -- "예" --> ACTIVE["STATUS.md Active Work\n현재 진행 pointer"]
ACTIVE --> WORK["/work\n계획 수립"]
WORK --> WORKFILE["docs/works/{category}\n{ID}-*.md"]
NOW -- "아니오" --> TYPE{"성격"}
TYPE -- "Product track / Phase 기능" --> PHASE["docs/backlog/PHASE{n}.md"]
TYPE -- "Harness / workflow" --> HARNESS["docs/backlog/HARNESS.md"]
TYPE -- "다음 세션 단기 후보" --> NEXT["STATUS.md Next Actions"]
TYPE -- "결정 필요" --> OQ["STATUS.md Blockers/OQ"]
OQ --> DR{"DR-worthy?"}
DR -- "예" --> DECISION["docs/decisions/DR-*.md"]
DR -- "아니오" --> OQ
style ACTIVE fill:#d4edda,stroke:#28a745
style WORKFILE fill:#d4edda,stroke:#28a745
style OQ fill:#fff3cd,stroke:#ffc107
style DECISION fill:#f8d7da,stroke:#dc3545
| Item | Location |
|---|---|
| 지금 하는 일 | docs/STATUS.md Active Work |
| Product track 후보 | docs/backlog/PHASE{n}.md |
| workflow/harness 후보 | docs/backlog/HARNESS.md |
| 큰 작업의 상세 계획 | docs/works/{category}/{ID}-{topic}.md |
| 결정 근거 | docs/decisions/DR-*.md |
| 완료 이력 | docs/archive/ |
5. Approval Matrix
실행 전 승인, 상태 변경 승인, commit 전 승인을 하나의 기준으로 묶는다.
| 변경 유형 | 실행 전 | 상태 변경 | commit 전 |
|---|---|---|---|
| L1 Product track surface | 간단 plan 승인 후 실행. Work 파일 없이 Quick Mode 가능 | Work checkpoint/discovery는 승인 불필요, 실행 후 대상 Work ID와 변경 보고 | validation 결과, diff summary, 제안 commit message 보고 후 승인 |
| L2 harness/workflow surface 또는 설정 | 상세 plan 승인 후 실행. Work 파일 사용을 기본값으로 둔다 | Work Done과 STATUS Active pointer 변경은 대상 Work ID 명시 후 승인 | validation 결과, diff summary, 제안 commit message 보고 후 승인 |
| L3 아키텍처·인프라·DB·보안 구조 | 관련 계획 또는 docs/PLAN.md 확인, AS-IS/TO-BE와 rollback 포함 후 승인 |
Phase/focus/criteria/Recent Decisions는 STATUS Update Proposal 승인 | validation 결과, diff summary, 제안 commit message, rollback 단위 보고 후 승인 |
- Quick Mode는 Product track surface의 작고 명확한 L1 작업에 한정한다.
- Harness/workflow surface(
entrypoint/workflow/protocol/command/rule/prompt/scaffold/status)를 건드리면 기본 L2로 다룬다. - 멀티 Active Work 환경에서는 모든 state-change proposal에 대상 Work ID를 명시한다.
AI가 반드시 멈춰야 하는 경우:
승인된 scope 밖 파일을 고쳐야 할 때 / STATUS Active Work pointer를 추가·제거해야 할 때 / Work를 Done 처리해야 할 때 / commit하려 할 때 / validation 실패 후 복구 방향을 바꿔야 할 때.
6. STATUS And Work File Rules
STATUS.md와 Work 파일의 역할은 다르다.
flowchart LR
STATUS["STATUS.md\ndashboard\n현재 상태·pointer"]
WORK["Work file\nSSoT\nPlan·Done Criteria·Verification·Checkpoints·Discovery"]
BACKLOG["backlog\n후보 pool"]
ARCHIVE["archive\n완료 이력"]
BACKLOG -->|"/work 승인"| STATUS
STATUS -->|"pointer"| WORK
WORK -->|"checkpoint/discovery"| WORK
WORK -->|"/close Done"| STATUS
WORK -->|"archive 승인"| ARCHIVE
style STATUS fill:#d4edda,stroke:#28a745
style WORK fill:#d4edda,stroke:#28a745
style ARCHIVE fill:#e2e3e5,stroke:#6c757d
STATUS.md — 현재 중심으로 가볍게 유지한다.
| Section | Meaning | Rule |
|---|---|---|
| Current State | 현재 phase와 주요 pointer | 자주 바꾸지 않는다 |
| Active Work | 현재 진행 중인 Work pointer | 상세 내용 금지 |
| Blockers/OQ | 진행을 막는 질문·결정 | 해소되면 Closed 또는 제거 |
| Recent Decisions | 최근 결정 digest | canonical 기록은 DR |
| Next Actions | 다음 세션 후보 | backlog가 아니다 |
Work File Lifecycle
stateDiagram-v2
[*] --> Active: /work 승인 후 Work 파일 생성
Active --> Done: /close 승인
Done --> Archived: archive 승인
Archived --> [*]
Done --> [*]: 재개 금지 — 후속 작업으로 분리
note right of Active
checkpoint / discovery
end note
/close와 /done은 다르다.
| Command | Purpose |
|---|---|
/close |
Work Done 처리 — status: Done, actual_end 기입, STATUS pointer 제거 제안 |
/done |
세션 요약 — Work Done 처리 없음. 완료했다면 먼저 /close |
7. Command Map
Claude slash command는 Codex 역시 같은 의도로 수행한다.
| Command | Use When | Core Action |
|---|---|---|
/start |
세션 시작 | STATUS current sections 확인, 현재 상태와 후보 요약 |
/pick |
다음 작업 선택 | product/harness backlog 비교 후 추천 |
/register |
새 항목 등록 | urgent/product/harness/OQ/Next Actions 중 라우팅 |
/work {ID} |
특정 작업 시작 | Work 파일 확인, risk 판단, plan 승인 대기 |
/resume {ID} |
중단 작업 재개 | 실제 파일 상태 vs STATUS/Work drift 확인 |
/debug |
오류 분석 | 원인 근거와 최소 수정 계획 |
/doc |
발표·보고·review package | brief, source, format, quality bar 확인 |
/record-decision |
결정 기록 | DR 초안 작성 |
/close |
Work 완료 | Done 처리와 선택적 archive |
/done |
세션 마무리 | 변경·검증·리스크·다음 prompt 요약 |
/health |
workflow 점검 | 구조 위생, full 점검, cascade 감사 |
Health 체크 권장 cadence:
| Health Mode | Use |
|---|---|
/health |
주 1~2회 또는 작업 블록 시작 전 |
/health --full |
Phase 전환 전 또는 월 1회 |
/health --cascade |
workflow/process 문서 변경 후 |
/health --full --cascade |
대형 harness 변경 후 최종 점검 |
8. Trigger And Cascade
Trigger는 AI가 자동 실행하는 명령이 아니라 제안 조건이다. 사용자 승인 전에는 파일을 바꾸지 않는다.
상세 trigger ID(T-번호)와 cascade 매핑은 docs/HARNESS-PROTOCOL.md 참조.
핵심 cascade 규칙:
- canonical workflow가 바뀌면 tool-specific, user-facing, scaffold surface를 함께 확인한다.
- command/rule/prompt/entrypoint가 바뀌면 Claude/Codex/Cursor alignment를 확인한다.
scripts/create-harness.sh또는 canonical workflow가 바뀌면 dry-run과 temp scaffold를 검증한다. scaffold script가 없는 repository는Skipped / Not Applicable로 보고한다.- commit 또는 PR 전에는 STATUS Finalization(T15)과 Tracking Finalization(T16)으로
docs/STATUS.md, backlog, Work, DR tracker의 최종 반영 여부를 판정한다.
9. Git Flow
이 repository의 기본 branch 전략은 Gitflow다. 상세 절차와 예외는 docs/GIT-WORKFLOW.md를 SSoT로 둔다.
main
└── develop
└── feature/*
- feature 작업은
develop기준으로 branch를 만든다. feature → develop 병합은 PR로만 한다. - develop → main PR은 의미 있는 패치가 완료된 release-ready 상태일 때만 생성한다. PR 생성 전
docs/GIT-WORKFLOW.md§3-1 Public Clean Baseline Gate를 수행하고 결과를 PR body에 남긴다. - main PR merge 후에는
main을 pull하고develop에origin/main을 merge한 뒤 push하여 동기화한다. - commit 전에는 validation 결과, diff summary, 제안 commit message를 보고하고 별도 승인을 받는다.
10. New Project Adoption
새 프로젝트 또는 기존 프로젝트에 적용할 때는 scripts/create-harness.sh를 사용한다.
기본 profile은 framework를 가정하지 않는 generic이다.
권장 경로: 이 repository를 clone한 뒤 직접 project-local workspace로 전환하지 않는다.
이 repository는 harness source로 유지하고, 실제 적용 대상은 아래 scaffold 명령으로 별도 target directory에 생성한다.
scaffold 후 첫 세션은docs/SCAFFOLD-ONBOARDING-GUIDE.md를 따라 진행한다.
# 신규 프로젝트
scripts/create-harness.sh my-app
scripts/create-harness.sh my-app /path/to/my-app
# 기존 프로젝트에 추가
scripts/create-harness.sh --existing my-app /path/to/existing-project
# Spring Boot example pack 포함
scripts/create-harness.sh --profile spring-boot my-app /path/to/my-app
# dry-run (파일 생성 없이 확인)
scripts/create-harness.sh --dry-run my-app
target-dir 생략 시 temp/<project-name>/에 생성된다.
flowchart TD
A(["Adoption 시작"]) --> B{"신규 / 기존?"}
B -- "신규 repo" --> C["create-harness.sh my-app\n또는 my-app /path"]
B -- "기존 repo" --> D["create-harness.sh --existing my-app /path"]
C --> E["scaffold 생성\nSTATUS.md · BOOTSTRAP.md\nbacklog · decisions · works\ncommands · rules · prompts"]
D --> F["AI: 코드베이스 읽기\n파일 내용 제안 → 사용자 승인"]
F --> E
E --> G["/start 첫 세션"]
G --> H{"STATUS.md Next Actions에\nbootstrap pointer 있음?"}
H -- "없음" --> I["일반 세션 시작\n/pick → /work → /close"]
H -- "있음" --> J["BOOTSTRAP.md 로드\n§8 First Prompt 사용"]
J --> K["Bootstrap Onboarding\nProduct Definition → Project Initialization\n→ Phase 1 Backlog"]
K --> L["STATUS.md Next Actions에서\nbootstrap pointer 제거"]
L --> I
style J fill:#fff3cd,stroke:#ffc107
style K fill:#cce5ff,stroke:#004085
style L fill:#d4edda,stroke:#28a745
style I fill:#d4edda,stroke:#28a745
Bootstrap onboarding은 Product Definition과 docs/PLAN-SUMMARY.md Implementation Baseline을 먼저 채운 뒤 Phase 1 backlog를 도출한다.
Implementation Baseline이 비어 있으면 feature candidate은 Not Ready로 보고하고 Project Initialization을 첫 P1 후보로 제안한다.
기존 프로젝트에 적용할 때는 코드베이스를 먼저 읽고 파일 내용을 제안하게 한다. 승인 전 파일을 채우지 않는다.
이 Repository에서 작업
Claude Code 세션: /start 실행 또는 docs/STATUS.md 확인.
Codex 세션: AGENTS.md를 읽고 /start intent로 현재 상태를 확인한다.
# pre-commit hook 선택적 설치 (일반 사용이나 scaffold 적용에는 불필요)
sh tools/git-hooks/install.sh
11. Key Documents
Language Policy
docs/decisions/DR-007-language-policy.md — 대부분의 문서는 한국어, Agent Core 문서는 영어.
Entry Points
| 문서 | 역할 |
|---|---|
| CLAUDE.md | Claude Code 진입점 |
| AGENTS.md | Codex 진입점 |
Workflow Core
| 문서 | 역할 |
|---|---|
| docs/BEHAVIOR-PRINCIPLES.md | 전역 행동 원칙 — 모든 AI 도구 공통 |
| docs/AGENT-WORKFLOW.md | 공통 workflow, Approval Matrix, status 규칙 |
| docs/HARNESS-PROTOCOL.md | 상세 protocol 레퍼런스 |
| docs/HARNESS-QUICK-REFERENCE.md | 세션 실행 규칙 빠른 참조 |
| docs/GIT-WORKFLOW.md | Git 브랜치 전략과 커밋 규칙 |
State & Tracking
| 문서 | 역할 |
|---|---|
| docs/STATUS.md | 현재 프로젝트 dashboard |
| docs/PLAN.md | 프로젝트 방향과 roadmap |
| docs/PLAN-SUMMARY.md | 세션 컨텍스트 경량 요약 |
| docs/works/ | Work 파일 및 인덱스 |
| docs/backlog/HARNESS.md | Harness 개선 backlog |
| docs/decisions/ | Decision Records |
Reference & Maintenance
| 문서 | 역할 |
|---|---|
| docs/WORKFLOW-MANUAL.md | 사용자용 workflow manual |
| docs/HARNESS-STRUCTURE.md | harness 구조와 정보 흐름 시각화 |
| docs/HARNESS-MAINTAINER-GUIDE.md | 유지보수·convention 가이드 |
| docs/SCAFFOLD-BOOTSTRAP.md | scaffold 직후 프로젝트 boot sequence 설계 기준 |
| docs/SCAFFOLD-ONBOARDING-GUIDE.md | scaffold 직후 첫 온보딩 가이드 (신규 적용자용) |
| prompts/README.md | Prompt 라이브러리 안내 |
12. Repository Layout
.
├── AGENTS.md # Codex 진입점
├── CLAUDE.md # Claude Code 진입점
├── .agents/
│ └── skills/ # Codex skill 파일
├── .claude/
│ ├── commands/ # slash command 정의 (/start, /work, /close 등)
│ └── rules/ # path-scoped rule mirror
├── .codex/
│ └── hooks.json # Codex hook 설정
├── .cursor/
│ └── rules/ # Cursor rule mirror
├── docs/
│ ├── BEHAVIOR-PRINCIPLES.md # 전역 행동 원칙
│ ├── AGENT-WORKFLOW.md # 공통 workflow·Approval Matrix
│ ├── HARNESS-PROTOCOL.md # 상세 protocol 레퍼런스
│ ├── HARNESS-QUICK-REFERENCE.md # 세션 실행 규칙 빠른 참조
│ ├── HARNESS-STRUCTURE.md # harness 구조 시각화
│ ├── HARNESS-MAINTAINER-GUIDE.md # 유지보수·convention 가이드
│ ├── SCAFFOLD-BOOTSTRAP.md # scaffold boot sequence 설계 기준
│ ├── GIT-WORKFLOW.md # Git 브랜치·커밋 전략
│ ├── STATUS.md # 현재 dashboard
│ ├── PLAN.md # 프로젝트 방향·roadmap
│ ├── PLAN-SUMMARY.md # 세션 컨텍스트 요약
│ ├── WORKFLOW-MANUAL.md # 사용자용 workflow manual
│ ├── backlog/ # 후보 작업 목록
│ ├── decisions/ # Decision Records
│ ├── retrospectives/ # 회고 기록
│ └── works/ # Work 파일 (작업 단위 SSoT)
├── prompts/ # portable prompt 템플릿
├── scripts/
│ └── create-harness.sh # scaffold script
└── tools/
└── git-hooks/ # pre-commit hook
13. Validation
git diff --check
bash -n scripts/create-harness.sh
./scripts/create-harness.sh --dry-run --profile generic sample /tmp/sample
14. Origin
이 저장소는 kyungseo/base-msa-template에서
Git history를 보존한 채 추출되었다. 하네스는 Spring Boot MSA template을 hardening하는 과정에서 형성되었으며,
현재는 AI Workflow Harness 자체에 집중한다.
15. License
LICENSE 참조.
Reviews (0)
Sign in to leave a review.
Leave a reviewNo results found