hamid
60 lines
3.0 KiB
Markdown
60 lines
3.0 KiB
Markdown
# The hardening loop prompt
|
||
|
||
Two ways to drive the chain. Both are self-terminating: when nothing is left unchecked, the agent
|
||
reports "chain complete" and stops instead of doing work.
|
||
|
||
---
|
||
|
||
## A. One phase per session (recommended)
|
||
|
||
Paste this into a **fresh** Claude Code session, once per iteration:
|
||
|
||
```
|
||
Read dev/post-phase/hardening/README.md and dev/post-phase/hardening/issues.md.
|
||
|
||
Find the FIRST phase (0→5) whose issues.md items are not all checked off, and whose dependencies
|
||
(per the README chain table) are already complete. Execute that phase's file
|
||
(dev/post-phase/hardening/hardening-phase-N-*.md) end to end:
|
||
|
||
1. Do the phase's required reading first. Do not re-audit findings — issues.md evidence is verified;
|
||
re-locate line numbers if they drifted.
|
||
2. Implement the full scope. Stay inside the phase's track (client/ or server/) unless the file says
|
||
otherwise.
|
||
3. Run that project's gate (client: npm run check + npm run test:ci · server: dotnet build Baya.sln +
|
||
dotnet test Baya.sln) and the phase's own Definition of Done — including any runtime probe it
|
||
demands. A phase is not done on a code-only fix if its DoD requires observed behavior.
|
||
4. Tick the finished items in issues.md (add the commit hash), write the phase report, update the
|
||
docs the phase names, and commit with message "hardening phase N: <title>".
|
||
5. End your reply with: the phase completed, what's verified, anything re-deferred (and why), and
|
||
which phase the loop should run next. If ALL items in issues.md are checked, say "HARDENING CHAIN
|
||
COMPLETE" and summarize the end state instead.
|
||
```
|
||
|
||
Repeat until it says complete. Phases 0 (frontend) and 1 (backend) may run in two parallel sessions —
|
||
they touch disjoint trees; everything else runs one at a time.
|
||
|
||
## B. Unattended interval loop (Claude Code /loop)
|
||
|
||
If you want it self-driving in one long session:
|
||
|
||
```
|
||
/loop Execute the next incomplete hardening phase per dev/post-phase/hardening/LOOP-PROMPT.md
|
||
section A (steps 1–5). One phase per iteration, commit when green. If issues.md is fully checked,
|
||
say "HARDENING CHAIN COMPLETE" and stop the loop.
|
||
```
|
||
|
||
Caveats for unattended mode: Phase 0's DoD needs the dev server + API running (keep them up, or let
|
||
the agent start them); Phase 4 involves product decisions (`cancellation_policy_code` set, REQ-027) —
|
||
the agent will decide from `product/` docs, so review that commit; nothing in the chain should push,
|
||
only commit locally.
|
||
|
||
## Guardrails (both modes)
|
||
|
||
- **Never skip a DoD runtime check.** H-01 survived nine phases precisely because "the code is
|
||
correct" was accepted without a live probe.
|
||
- **issues.md is the single progress state.** No side lists; re-deferrals get written there, not
|
||
dropped.
|
||
- If a phase file contradicts the live code (something already fixed, a file moved), trust the code,
|
||
note the drift in the report, and keep going — don't restore the file's assumption.
|
||
- One phase = one commit (Phase 4 may commit per REQ group). Don't batch phases into one commit.
|