* test(#3576): gate shipped reference citations on the canonical resolvable form Failing-first gate for #3576: a backticked bare references/<name>.md cite resolves from no install location (agents, workflows, and references all install where a bare relative references/ path is dead). The gate walks the runtime-loaded trees the issue prescribes, strips @~/ include tokens PER-TOKEN (a line-skip guard would miss a bare cite sharing a line with an include — the issue-named trap), pins the genuinely relative ../ href and canonical forms as non-offenders, and checks canonical cite targets exist. 43 offenders today across 19 files. * fix(#3576): repair all 43 dead references/ cites to the canonical resolvable form Every backticked bare references/<name>.md cite across the 19 shipped files rewritten to gsd-core/references/<name>.md — the form every required_reading block and @~/ include already uses, and the only form that resolves from any install location. All 20 cited targets verified to exist; the one genuinely relative href (plan-phase.md's ../references/mvp-concepts.md) is untouched (the repair is backtick-anchored). Growth acks: new fragment for the three first-time paths, #3206-pattern appends to the five fragments already naming the other grown files (two ack sources may never name the same path). execute-phase.md lands at 93,391/93,400 and gsd-executor.md at 49,150/49,152 — exactly the issue's projections; every repair fits. * fix(#3576): drop stale default.md growth ack (nested modes file is hash-attributed, not growth-ratcheted) Review finding: the emitted-attribution ratchet covers only top-level workflows/ + agents/ files; discuss-phase/modes/default.md's delta is source-attributed, so acknowledging its growth is a stale entry the differential lane fails on. * chore(#3576): add changeset fragment * chore(#3576): backfill changeset pr number --------- Co-authored-by: sim <sim@local>
3.9 KiB
Revision Loop Pattern
Standard pattern for iterative agent revision with feedback. Used when a checker/validator finds issues and the producing agent needs to revise its output.
Pattern: Check-Revise-Escalate (max 3 iterations)
This pattern applies whenever:
- An agent produces output (plans, imports, gap-closure plans)
- A checker/validator evaluates that output
- Issues are found that need revision
Flow
prev_issue_count = Infinity
iteration = 0
LOOP:
1. Run checker/validator on current output
2. Read checker results
3. If PASSED or only INFO-level issues:
-> Accept output, exit loop
4. If BLOCKER or WARNING issues found:
a. iteration += 1
b. If iteration > 3:
-> Escalate to user (see "After 3 Iterations" below)
c. Parse issue count from checker output
d. If issue_count >= prev_issue_count:
-> Escalate to user: "Revision loop stalled (issue count not decreasing)"
e. prev_issue_count = issue_count
f. Re-spawn the producing agent with checker feedback appended
g. After revision completes, go to LOOP
Issue Count Tracking
Track the number of BLOCKER + WARNING issues returned by the checker on each iteration. If the count does not decrease between consecutive iterations, the producing agent is stuck and further iterations will not help. Break early and escalate to the user.
Display iteration progress before each revision spawn:
Revision iteration {N}/3 -- {blocker_count} blockers, {warning_count} warnings
Re-spawn Prompt Structure
When re-spawning the producing agent for revision, pass the checker's YAML-formatted issues. The checker's output contains a ## Issues heading followed by a YAML block. Parse this block and pass it verbatim to the revision agent.
<checker_issues>
The issues below are in YAML format. Each has: dimension, severity, finding,
affected_field, suggested_fix. Address ALL BLOCKER issues. Address WARNING
issues where feasible.
{YAML issues block from checker output -- passed verbatim}
</checker_issues>
<revision_instructions>
Address ALL BLOCKER and WARNING issues identified above.
- For each BLOCKER: make the required change
- For each WARNING: address or explain why it's acceptable
- Do NOT introduce new issues while fixing existing ones
- Preserve all content not flagged by the checker
This is revision iteration {N} of max 3. Previous iteration had {prev_count}
issues. You must reduce the count or the loop will terminate.
</revision_instructions>
After 3 Iterations
If issues persist after 3 revision cycles:
- Present remaining issues to the user
- Use gate prompt (pattern: yes-no from
gsd-core/references/gate-prompts.md): question: "Issues remain after 3 revision attempts. Proceed with current output?" header: "Proceed?" options:- label: "Proceed anyway" description: "Accept output with remaining issues"
- label: "Adjust approach" description: "Discuss a different approach"
- If "Proceed anyway": accept current output and continue
- If "Adjust approach" or "Other": discuss with user, then re-enter the producing step with updated context
Workflow-Specific Variations
| Workflow | Producer Agent | Checker Agent | Notes |
|---|---|---|---|
| plan-phase | gsd-planner | gsd-plan-checker | Revision prompt via planner-revision.md |
| execute-phase | gsd-executor | gsd-verifier | Post-execution verification |
| discuss-phase | orchestrator | gsd-plan-checker | Inline revision by orchestrator |
Important Notes
- INFO-level issues are always acceptable -- they don't trigger revision
- Each iteration gets a fresh agent spawn -- don't try to continue in the same context
- Checker feedback must be inlined -- the revision agent needs to see exactly what failed
- Don't silently swallow issues -- always present the final state to the user after exiting the loop