docs: align Harness step execution guidance

This commit is contained in:
KOKO\Mimi
2026-08-12 15:27:32 +09:00
parent 65d5e0748a
commit 18296a1944
4 changed files with 107 additions and 17 deletions
+24 -12
View File
@@ -14,26 +14,38 @@ Read these first:
- `AGENTS.md`
- `docs/SOLVER_AGENT_DESIGN.md`
- `docs/implementation-plans/README.md`
- `docs/HARNESS.md`
- `docs/HARNESS_WORKFLOW.md`
- `docs/build-test-reports/README.md`
- `docs/corrections/README.md`
- `docs/implementation-plans/<feature-id>-implementation-plan.md`
- Related requirements, formulation, numerical review, I/O definition, and reference model documents
For Harness implementation, also read `.agents/skills/harness/SKILL.md`,
`.codex/hooks.json`, the materialized phase indexes, and the Executor-selected current
`stepN.md`.
## Workflow
1. For planning, use the project-local `harness` skill to convert upstream documents into a
user-approved multi-Step draft. Create `phases/` files only after approval and never run the
executor without a separate explicit request.
2. For implementation, follow `RED -> GREEN -> VERIFY`.
3. RED: write the planned unit, integration, parser/I/O, or reference-comparison test first.
4. RED: run the targeted test and verify the expected failure before production code.
5. GREEN: implement the minimum C++17/MSVC-compatible code needed for the task.
6. VERIFY: run the targeted command, then the full MSVC build/test commands resolved from `.harness/config.json` or the Harness defaults.
7. For C++ production changes, require a related C++ test file in the same patch or already present.
8. Treat PreToolUse as a test-file-existence guardrail, not proof that RED was observed. Record the RED and GREEN commands and results in the implementation report.
9. Let Stop perform the final whole-project MSVC build/test before the Step ends.
10. For failure triage, classify as `configure | compile | link | test | reference-comparison | harness | environment | upstream-contract`.
11. Fix implementation-owned failures only and keep changes traceable to the implementation plan.
user-approved multi-Step draft. Materialize only planning files after approval; planning never
selects or runs a Step. Run `scripts/execute.py` only after a separate explicit user request.
2. For implementation, require the approved plan, materialized phase files, and the
Executor-selected current `stepN.md`. Do not start another pending Step.
3. Execute the current Step as `RED -> observed failure -> minimal GREEN -> focused/full VERIFY`.
Update only its Codex-owned `status` plus `summary`, `error_message`, or `blocked_reason`.
The Executor owns branch, pending-Step selection, retry, timestamps, commits, and advancement.
4. Hooks are automatic through `.codex/hooks.json`: PreToolUse intercepts before edits and Stop
performs whole-project validation. Do not manually run their entry points as substitutes.
5. RED: write the planned unit, integration, parser/I/O, or reference-comparison test first.
6. RED: run the targeted test and verify the expected failure before production code.
7. GREEN: implement the minimum C++17/MSVC-compatible code needed for the task.
8. VERIFY: run the targeted command, then the full MSVC build/test commands resolved from `.harness/config.json` or the Harness defaults.
9. For C++ production changes, require a related C++ test file in the same patch or already present.
10. Treat PreToolUse as a test-file-existence guardrail, not proof that RED was observed. Record the RED and GREEN commands and results in the implementation report.
11. Let Stop perform the final whole-project MSVC build/test before the Step ends.
12. For failure triage, classify as `configure | compile | link | test | reference-comparison | harness | environment | upstream-contract`.
13. Fix implementation-owned failures only and keep changes traceable to the implementation plan.
## Output Contract