Files
msd-core/gsd-core/references/revision-loop.md
Tom Boucher ec7e49a64c fix(#3576): repair all 43 dead references/ cites and gate the canonical resolvable form (#3596)
* 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>
2026-08-17 15:24:24 -04:00

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:

  1. An agent produces output (plans, imports, gap-closure plans)
  2. A checker/validator evaluates that output
  3. 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:

  1. Present remaining issues to the user
  2. 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"
  3. If "Proceed anyway": accept current output and continue
  4. 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