KOKO\Mimi
199 lines
7.7 KiB
Markdown
199 lines
7.7 KiB
Markdown
---
|
|
name: harness
|
|
description: Use when planning agentic implementation phases, creating phases/index.json and self-contained step files, or running the Harness step executor.
|
|
---
|
|
|
|
# Harness Workflow
|
|
|
|
이 프로젝트는 Harness 프레임워크를 사용한다. 아래 워크플로에 따라 작업한다.
|
|
|
|
## 필수 읽기와 실행 소유권
|
|
|
|
계획, phase 파일 생성, 또는 Executor 실행 전 `AGENTS.md`,
|
|
`docs/HARNESS.md`, `docs/HARNESS_WORKFLOW.md`를 읽는다. Step을 구현할 때는
|
|
`.codex/hooks.json`, phase index, Executor가 선택한 현재 `stepN.md`도 읽는다.
|
|
|
|
| 책임 | 소유자 |
|
|
|---|---|
|
|
| branch, pending Step 선택, retry, timestamps, commits, advancement, top-level phase status | Executor (`scripts/execute.py`) |
|
|
| Executor-selected current Step의 작업과 해당 Step의 `status` 및 `summary` / `error_message` / `blocked_reason` payload | Implementation Agent |
|
|
| PreToolUse interception과 Stop whole-project validation | `.codex/hooks.json`으로 등록된 hooks |
|
|
|
|
Hook은 자동으로 작동한다. `scripts/hooks/pre_tool_use.py` 또는
|
|
`scripts/hooks/stop_validation.py`를 수동 실행해 등록된 hook의 대체물로 사용하지 않는다.
|
|
계획 승인은 Executor 실행 권한이 아니다. `scripts/execute.py`는 별도의 명시적 사용자
|
|
요청에서만 실행한다.
|
|
|
|
## A. 탐색
|
|
|
|
`AGENTS.md`와 `docs/` 하위 문서(PRD, ARCHITECTURE, ADR 등)를 읽고 프로젝트의 기획,
|
|
아키텍처, 설계 의도를 파악한다. 병렬 탐색이 실제로 유용하고 현재 세션에서 허용될
|
|
때만 Codex subagent를 선택적으로 사용한다.
|
|
|
|
## B. 논의
|
|
|
|
구현을 위해 구체화하거나 기술적으로 결정해야 할 사항이 있으면 사용자에게 한 번에
|
|
하나씩 제시하고 논의한다.
|
|
|
|
## C. Step 설계
|
|
|
|
사용자가 구현 계획 작성을 지시하면 여러 step으로 나뉜 초안을 작성해 피드백을
|
|
요청한다.
|
|
|
|
설계 원칙:
|
|
|
|
1. **Scope 최소화** — 하나의 step에서 하나의 레이어 또는 모듈만 다룬다. 여러
|
|
모듈을 동시에 수정해야 하면 step을 쪼갠다.
|
|
2. **자기완결성** — 각 step 파일은 독립된 Codex 실행에서 사용된다. 외부 대화
|
|
참조를 금지하고 필요한 정보를 모두 파일 안에 적는다.
|
|
3. **사전 준비 강제** — 관련 문서와 이전 step에서 생성하거나 수정한 파일 경로를
|
|
명시한다.
|
|
4. **시그니처 수준 지시** — 함수와 클래스의 인터페이스를 제시하고 내부 구현은
|
|
Codex 재량에 맡긴다. 멱등성, 보안, 데이터 무결성 같은 핵심 규칙은 명시한다.
|
|
5. **AC는 실행 가능한 command** — 추상적 조건 대신 실제 빌드와 테스트 command를
|
|
포함한다.
|
|
6. **주의사항은 구체적으로** — "X를 하지 마라. 이유: Y" 형식으로 적는다.
|
|
7. **네이밍** — step name은 핵심 작업을 표현하는 kebab-case slug로 정한다.
|
|
|
|
## D. 파일 생성
|
|
|
|
사용자가 초안을 승인한 후에만 다음 파일을 생성한다.
|
|
|
|
Planning Agent는 초안을 만들고 승인받아 planning files만 materialize한다. planning
|
|
Agent는 Step을 선택하거나 실행하지 않는다.
|
|
|
|
### D-1. `phases/index.json`
|
|
|
|
여러 task를 관리하는 top-level 인덱스다. 이미 존재하면 `phases` 배열에 새 항목을
|
|
추가한다.
|
|
|
|
```json
|
|
{
|
|
"phases": [
|
|
{
|
|
"dir": "0-mvp",
|
|
"status": "pending"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
- `dir`: task 디렉터리명
|
|
- `status`: `pending` | `completed` | `error` | `blocked`
|
|
- timestamp는 executor가 상태를 바꿀 때 기록하므로 생성 시 넣지 않는다.
|
|
|
|
### D-2. `phases/{task-name}/index.json`
|
|
|
|
```json
|
|
{
|
|
"project": "<프로젝트명>",
|
|
"phase": "<task-name>",
|
|
"steps": [
|
|
{ "step": 0, "name": "project-setup", "status": "pending" },
|
|
{ "step": 1, "name": "core-types", "status": "pending" },
|
|
{ "step": 2, "name": "api-layer", "status": "pending" }
|
|
]
|
|
}
|
|
```
|
|
|
|
필드 규칙:
|
|
|
|
- `project`: `AGENTS.md`에 정의된 프로젝트명
|
|
- `phase`: task 이름이며 디렉터리명과 일치
|
|
- `steps[].step`: 0부터 시작하는 순번
|
|
- `steps[].name`: kebab-case slug
|
|
- `steps[].status`: 초기값 `pending`
|
|
|
|
상태와 기록 주체:
|
|
|
|
| 전이 | 기록 필드 | 기록 주체 |
|
|
|------|-----------|-----------|
|
|
| `completed` | `summary`, `completed_at` | Codex가 summary, executor가 timestamp |
|
|
| `error` | `error_message`, `failed_at` | Codex가 message, executor가 timestamp |
|
|
| `blocked` | `blocked_reason`, `blocked_at` | Codex가 reason, executor가 timestamp |
|
|
|
|
`summary`에는 다음 step에 유용한 생성 파일과 핵심 결정을 한 줄로 적는다.
|
|
task `created_at`과 step `started_at`은 executor가 기록하므로 생성 시 넣지 않는다.
|
|
|
|
### D-3. `phases/{task-name}/step{N}.md`
|
|
|
|
````markdown
|
|
# Step {N}: {이름}
|
|
|
|
## 읽어야 할 파일
|
|
|
|
먼저 아래 파일을 읽고 프로젝트의 아키텍처와 설계 의도를 파악하라:
|
|
|
|
- `/AGENTS.md`
|
|
- `/docs/ARCHITECTURE.md`
|
|
- `/docs/ADR.md`
|
|
- 이전 step에서 생성하거나 수정한 파일 경로
|
|
|
|
이전 step의 코드를 꼼꼼히 읽고 설계 의도를 이해한 뒤 작업하라.
|
|
|
|
## 작업
|
|
|
|
구체적인 구현 지시를 파일 경로, 클래스와 함수 시그니처, 로직 설명과 함께 적는다.
|
|
구현체는 Codex에 맡기되 설계 의도에서 벗어나면 안 되는 핵심 규칙은 명시한다.
|
|
|
|
## Acceptance Criteria
|
|
|
|
프로젝트 형식에 맞는 명령을 사용한다. `.harness/config.json`이 있으면 해당 preset,
|
|
solution, configuration, platform, test command를 우선한다.
|
|
|
|
```powershell
|
|
# CMake
|
|
cmake --build .harness/build --config Debug
|
|
ctest --test-dir .harness/build -C Debug --output-on-failure
|
|
|
|
# 직접 MSBuild
|
|
MSBuild.exe MyProject.sln /m /p:Configuration=Debug /p:Platform=x64
|
|
.\build\tests\Debug\MyProjectTests.exe
|
|
```
|
|
|
|
## 검증 절차
|
|
|
|
1. Acceptance Criteria command를 실행한다.
|
|
2. ARCHITECTURE 디렉터리 구조를 따르는지 확인한다.
|
|
3. ADR 기술 스택과 `AGENTS.md` CRITICAL 규칙을 확인한다.
|
|
4. 결과에 따라 task index의 Executor-selected current Step만 갱신한다.
|
|
- 성공: `status`를 `completed`로 바꾸고 한 줄 `summary` 기록
|
|
- 실행을 계속할 수 없는 오류: `status`를 `error`로 바꾸고 `error_message` 기록
|
|
- 사용자 개입 필요: `status`를 `blocked`로 바꾸고 `blocked_reason` 기록 후 중단
|
|
- retry, timestamp, commit, 다음 Step 선택과 advancement는 Executor가 기록한다.
|
|
|
|
## 금지사항
|
|
|
|
- 이 step의 범위 밖 기능을 추가하지 마라. 이유: step의 독립성을 깨뜨린다.
|
|
- 기존 테스트를 깨뜨리지 마라. 이유: 이전 동작을 회귀시킨다.
|
|
````
|
|
|
|
## E. 실행
|
|
|
|
별도의 명시적 사용자 요청이 있고 approved planning files가 materialize된 경우에만
|
|
Executor를 시작한다. Implementation Agent는 Executor가 선택한 current `stepN.md` 하나만
|
|
`RED -> observed failure -> minimal GREEN -> focused/full VERIFY` 순서로 수행하고 다음
|
|
Step을 시작하지 않는다.
|
|
|
|
```bash
|
|
python scripts/execute.py {task-name}
|
|
python scripts/execute.py {task-name} --push
|
|
```
|
|
|
|
환경에서 Python 3 실행 명령이 `python3`이면 그 명령을 대신 사용한다.
|
|
|
|
executor가 처리하는 작업:
|
|
|
|
- `feat-{task-name}` 브랜치 생성 또는 checkout
|
|
- `AGENTS.md`와 `docs/*.md` guardrail 주입
|
|
- 완료 step의 summary를 다음 prompt에 누적
|
|
- 실패 시 최대 3회 재시도하며 이전 오류를 prompt에 전달
|
|
- 코드 변경과 metadata를 분리해 commit
|
|
- `started_at`, `completed_at`, `failed_at`, `blocked_at` 기록
|
|
|
|
에러 복구:
|
|
|
|
- `error`: 해당 status를 `pending`으로 바꾸고 `error_message`를 삭제한 뒤 재실행
|
|
- `blocked`: 원인을 해결하고 status를 `pending`으로 바꾸고 `blocked_reason`을 삭제한
|
|
뒤 재실행
|