pi-gauntlet 7.43.0 → 8.0.0

package/skills/subagent-driven-development/reference/fix-loop.md

@@ -1,45 +0,0 @@
-# Escalated fix rounds
-
-Use the dispatch-contract one-step carrier for escalated and funded implementers and every review, with output/file-only/schema and a status/verdict stopOn. Consume structured results only. Serialize a fix with missing parallelSafe; absent touchedTasks on a multi-task repair means all dispatched tasks. Escalate a re-review missing trajectory instead of requesting the line again.
-
-**Escalate** = one escalated round; stop only on failure. Call `gauntlet_setting({ key: "escalationLoop" })` (unavailable -> stop and report). `implModel` undefined -> stop note. Otherwise re-dispatch that fix - same payload and isolation knobs (`cwd`, `worktree`, `SCOPED_TEST_COMMANDS`, status protocol, prior patch, spec anchors) plus the prior report path under `## Previous review report (re-review trigger)` - overriding only `model: <implModel>`, `context: "fresh"`, `async: false`; one implementer, no fan-out. Run the normal fix-round review gate (SR then CR on `Behaviour-change: yes`, else the triggering reviewer with the re-review marker). All clean -> proceed; the escalated patch supersedes the prior one at integrate. A non-`DONE` status or a dispatch error -> stop note per `stop-note.md`. A review with issues -> a funded round while one remains for the task (below), otherwise stop note; no other second dispatch. Once per loop; independent of the convergence exception. No `plan_tracker` write during escalation - keep the task `in_progress` until the wave commit or, on a stop, the human decides.
-
-## Funded rounds
-
-Delegate a current `**Amend-grant:**` read and grant decoding through the answer/evidence one-step carrier using **Value decoding** in [Standing grants](../../brainstorming/reference/amendment-surface.md#standing-grants) before each funded dispatch. Funding is independent of ordinary fixes and the escalated round; it never supplies a missing `implModel`, another escalation grant, verify credits, or `grant_fix_rounds`. Keep the review-3 convergence exception once per loop; never re-arm it through funding.
-
-Start one per-task ledger at zero when each task first enters Fix-Loop Rounds. Carry it across SR, behavior-change reroutes, the SR-to-CR transition, and wave repairs re-entering SR; use no wave-level allowance. Determine touched owners using the SR targeting rule (tasks whose files the fix touches). For a multi-task CR repair, spend once from every touched task; a touched exhausted owner stops the wave with that task's stop note before dispatch.
-
-Before every funded dispatch, print `funded round <k> of <N> for task <n>` for each touched task. Apply mid-loop grants prospectively, with spent starting at zero: rounds before the token was written neither count against nor toward it. Repeat the escalated payload and isolation exactly: configured `model: <implModel>` from `escalationLoop`, `context: "fresh"`, `async: false`, one implementer, no fan-out, same `cwd`/`worktree`, planPath and task anchors, prior patch path, spec path, status protocol, `SCOPED_TEST_COMMANDS`, and saved prior report path under `## Previous review report (re-review trigger)`. Run the same tests and same review gate: SR then CR on `Behaviour-change: yes`, otherwise the triggering reviewer with the re-review marker, trajectory block and Fix delta. Every dispatched round spends one, including failures.
-
-| Funded outcome | Action |
-|---|---|
-| Errors and non-`DONE` | Count as spent and stop with the task's stop note. |
-| Any funded re-review reports `STAGNANT` | Stop immediately regardless of funding remaining. |
-| Issue-bearing re-review with rounds left | Dispatch the next funded round. |
-| Issue-bearing re-review after N rounds | Stop with the exhausted task's stop note. |
-| All reviews clean | Continue through the wave gate and commit before task completion. |
-
-Emit the task's stop note for the funded-stop outcomes above (including `STAGNANT`) and an escalated-round failure with no funded round left. While a budget token exists, include `budget: <spent> of <N> spent` in every stop note after `Problem:` and any `Searched:` lines and before the file finding, including pre-escalation stops, missing `implModel`, and exhausted fact lookups at spent zero; use the `(not recovered on resume)` suffix below when recovery fails, and omit the line without a token. Treat this line as the only round-history exception to `stop-note.md`'s no-round-history rule.
-
-On resume, keep header restoration unchanged; recover each task's spent count only from its `funded round <k> of <N>` transcript lines. Without recoverable lines, treat funding as exhausted; stop the next issue-bearing re-review with `budget: <N> of <N> spent (not recovered on resume)`. Treat a newly written budget token as the human refund, never a resume reset. Use no new spent carrier or handoff/resume grammar.
-
-## Implementer-failure stops
-
-Decode grants through [Value decoding](../../brainstorming/reference/amendment-surface.md#standing-grants); absent/`none`/budget-only: retain the ordinary two-attempt stop. Follow [stop-note.md](../stop-note.md) for lookups/status; preserve review/funding rules above.
-
-1. **Hard stops**: stop first for malformed grants, missing `implModel`, unavailable settings tools, dirty-tree/commit-boundary returns, empty-commit stagnation, cap, funded re-review `STAGNANT`, `REJECT`, and [redraws](../SKILL.md#implementer-status).
-2. **Takeable decision**: route only `BLOCKED`/`NEEDS_CONTEXT` decisions with attempts remaining below. Compare whitespace-normalized `file:line` finding or failing command plus assertion already auto-resolved on this task -> `Recommendation: none - evidence repeats task <n>`; stop.
-3. **Execution escalation**: after two failed attempts, escalate before routing `Recommendation:`; call `gauntlet_setting({ key: "escalationLoop" })`; `implModel` undefined stops with the existing note. Print `escalated round for task <n> after 2 failed attempts`. Dispatch one implementer: `model: <implModel>`, `context: "fresh"`, `async: false`, same payload and isolation as above (`SCOPED_TEST_COMMANDS`, the prior report path and the anchored task payload); retain siblings; no fan-out/re-chain. Spend once/task/site, independently of review escalation/funding.
-4. **Resulting decision**: dispatch error or non-`DONE` spends escalation; use step 2's table; no fourth unnamed repair. Success still runs the ordinary scoped tests and SR/CR gates before wave commit/completion.
-
-When taken, print `took recommendation: <option> for task <n>`.
-
-| Recommendation | Action |
-|---|---|
-| In-task repair | Preserve payload/isolation; count every re-dispatch as an ordinary attempt; enforce two-attempt limit. |
-| Spec/plan rule edit, including drafted-AC-row text correction backed by quoted implementer test/assertion/code evidence | Follow [amendment-surface section 5](../../brainstorming/reference/amendment-surface.md#5-apply-aftermath-commit) under grant. |
-| `fix-first` | Enter `/skill:shape-ticket` at its gate. |
-| `none`/budget/consent/redraw/separate change | Emit stop note ending in `Recommendation: <option> - <why>`; wait. |
-
-Recover only that line in matching task's transcript, not a review escalation or sibling line; unrecoverable means spent. A mid-loop grant or explicit retry never re-arms.

package/skills/subagent-driven-development/spec-reviewer-prompt.md

@@ -1,125 +0,0 @@
-# Spec Compliance Reviewer Prompt Template
-
-Use this template when dispatching a spec compliance reviewer subagent.
-
-**Purpose:** Verify implementer built what was requested (nothing more, nothing less)
-
-```
-Dispatch a subagent with this prompt:
-  description: "Review spec compliance for Task N"
-  prompt: |
-    You are reviewing whether an implementation matches its specification.
-
-    planPath: [absolute plan path]
-    anchor: "### Task N:"
-    anchors: [use instead of anchor for a multi-task review]
-    Spec: [absolute authoritative home spec path]
-    Work from: [review checkout]
-    SCOPED_TEST_COMMANDS: [dispatch-supplied values | none; evidence only, never execute]
-    Implementer report: [saved implementer report path]
-
-    Read the selected task sections first. Read their Spec anchors, Tests:/via: and Files: Create:/Test: paths yourself; derive Rules from the task and home-spec leg as your persona directs. Read the saved implementer report, then verify its claims independently.
-
-    ## Previous review report (re-review trigger)
-
-    [Re-review only: saved previous review report path; omit this section on initial review]
-    Read that report yourself before evaluating trajectory.
-
-    ## Spec Authority
-
-    Derive the spec anchor list and task contract from the selected sections; distinguish plan task anchors from spec clause anchors. The task text is a derivative of the spec, not its authority.
-
-    The spec is the sole authority — human-approved; the task never wins a dispute. Read the anchored ranges from the spec file yourself. Requirements in scope are ONLY the cited anchor ranges; do not extract, review, or flag the rest of the spec file.
-
-    - **Correctness / wording / completeness:** judged against the anchored spec lines. The spec wins every dispute.
-    - **Scope ("nothing more"):** the boundary is the anchor set — the slice of spec this task owns. Diff work outside the anchored slice is flagged **out-of-anchor-slice** even if task prose mentioned it.
-    - **Plan transcription gap:** spec-required work inside the anchored slice that is missing from the diff because the task prose omitted it — the requirement still binds; flag it. Missing case only: diff work that is spec-authorized but unmentioned by task prose is compliant — note it as a plan-fidelity remark outside the F1..Fn finding stream, never as a finding.
-    - **Task-vs-spec divergence** (task says X, anchored spec says Y): unconditional flag; quote the spec literal with spec file:line so the fix re-dispatch carries authoritative wording. Never silently trust the task; never silently substitute the spec — the flag is the mechanism. Closure: the finding closes when the current patch conforms to the anchored spec; re-reviews judge the diff against the spec, not stale task prose — a divergence already corrected in the diff is not re-flagged.
-    - **Anchor-less task** (Anchors: omitted): the task text alone is your contract; no out-of-anchor-slice or transcription-gap flagging — only nothing-extra-vs-the-chore review.
-    - **Finding grammar:** divergence findings use the existing F1..Fn finding grammar - a finding kind by prose label, not a new schema; the `Parallel-safe:` and `TRAJECTORY:` grammars are untouched.
-    - **Condition match:** for every anchored clause that fixes a value, threshold, comparison, or trigger ("only when", "unless", "if", a literal), the clause row carries two indented sub-lines, before `touched-files:` where present: `spec-condition: <clause fragment quoted from the spec>` and `code-condition: <what the code checks, file:line>`. If the two differ, the clause is `PARTIAL` at most - regardless of passing tests. A plausible condition is not the specified condition.
-    - **Plan/task code snippets:** implementation guidance, not review authority; a diff matching a snippet never proves compliance. For anchor-less tasks the task text's prose requirements remain your contract.
-    - **Task contract (Tests:/via:/Files:):** The task's `**Tests:**` block, `via:`, and its `Files:` paths supplement the anchored spec where it is silent; the anchored spec wins a conflict - report the divergence once, against the plan, never against code corrected to the spec. Findings: a `Create:` path absent from the diff or created elsewhere; a test that does not call the `via:` entry point; a `Tests:` block the diff contradicts. Existing files need no diff touch. You never run the commands.
-
-    ## CRITICAL: Do Not Trust the Report
-
-    The implementer finished suspiciously quickly. Their report may be incomplete,
-    inaccurate, or optimistic. You MUST verify everything independently.
-
-    **DO NOT:**
-    - Take their word for what they implemented
-    - Trust their claims about completeness
-    - Accept their interpretation of requirements
-
-    **DO:**
-    - Read the actual code they wrote
-    - Read each touched file in full, not just the diff hunks, continuing in chunks; note in the report any touched file not read to the end
-    - Compare actual implementation to requirements line by line
-    - Check for missing pieces they claimed to implement
-    - Look for extra features they didn't mention
-
-    ## Boundaries
-
-    - **Read code and compare to spec: yes**
-    - **Edit, create, or delete any files: NO**
-    - **Run tests, linters, or type-checkers: NO.** Never run tests, linters, or type-checkers. Your evidence is the diff and the files you read.
-    - **Code-quality opinions (naming, design, complexity, test aesthetics, style): NO.** Those belong to code-reviewer. Report only spec-vs-implementation deltas.
-    - You are a reviewer. Your output is a written report listing what matches and what doesn't.
-    - If you find issues, describe them — do NOT fix them.
-
-    ## Your Job
-
-    <!-- clause decomposition / snippet non-authority / whole-file reads / task-contract supplement: keep in lockstep with agents/spec-reviewer.md — change them together or not at all -->
-
-    Decompose the binding contract - the anchored spec lines, or the task text when anchors are omitted - into atomic clauses, covering every requirement, acceptance criterion, and explicit non-goal. Each independently checkable statement is one clause; a sentence listing three requirements yields three clauses.
-
-    Read the implementation code and verify:
-
-    **Missing requirements:**
-    - Did they implement everything that was requested?
-    - Are there requirements they skipped or missed?
-    - Did they claim something works but didn't actually implement it?
-    - Anchored spec work absent from the diff because task prose omitted it? Label it "plan transcription gap".
-
-    **Extra/unneeded work:**
-    - Did they build things that weren't requested?
-    - Did they over-engineer or add unnecessary features?
-    - Did they add "nice to haves" that weren't in spec?
-    - Diff work outside the task's anchor slice? Label it "out-of-anchor-slice" (distinct from a spec-declared non-goal).
-
-    **Misunderstandings:**
-    - Did they interpret requirements differently than intended?
-    - Did they solve the wrong problem?
-    - Did they implement the right feature but wrong way?
-
-    **Verify by reading code, not by trusting report.**
-
-    Report in the output format `agents/spec-reviewer.md` defines in your system prompt. Emit structured output matching its contract and the report verdict and footer. On an unreadable plan/anchor report NEEDS_REWORK with anchorUnreadable formed by concatenating planPath, a literal #, and the dispatched anchor verbatim, including the ### prefix and trailing colon. Use that same exact identity in the required Reasoning line; never ask the parent to read it or mark an unread section compliant.
-
-    ## Re-review: trajectory verdict
-
-    If your task contains a "Previous review report (re-review trigger)" section
-    and you found issues, append exactly one more line after `Parallel-safe:` — this
-    line, not `Parallel-safe:`, is the true final line of the report:
-
-    TRAJECTORY: CONVERGING (<n_prev> -> <n_now>)
-    TRAJECTORY: DIVERGING
-    TRAJECTORY: STAGNANT (repeat of: <finding>)
-
-    Pick the first label that applies, in this order:
-
-    1. STAGNANT: a previous finding survives materially unchanged - name it.
-       (e.g. the same missing requirement flagged last round is still missing)
-    2. DIVERGING: <n_now> >= <n_prev>, or the fix introduced any new finding.
-       (e.g. 3 findings fixed but the fix drifted from the spec elsewhere: DIVERGING, not CONVERGING)
-    3. CONVERGING: otherwise - the count fell, nothing new appeared, and every
-       surviving finding was materially improved.
-
-    <n_prev>/<n_now> are finding counts.
-
-    The orchestrator dispatches one extra fix only when this line says CONVERGING
-    - be accurate, not generous.
-
-    If you found no issues, report success as usual and omit this line.
-    First reviews (no previous-report section) omit this line.
-```