pi-gauntlet 7.38.0 → 7.38.1

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## v7.38.1 - 2026-10-28
+
+### Changed
+
+- Amendment-aftermath `plan_check` and baseline failures attributable to the batch's edits become at most two retry items in that same batch, with the spec's amend grant controlling automatic apply; unrelated failures, protected paths, exhausted retries, and repeated evidence retain their existing stops, and only eligible tracked paths named by an attributable dirtied-source row receive a narrow orchestrator restore, not general implement-phase cleanup.
+
 ## v7.38.0 - 2026-10-28
 
 ### Changed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-gauntlet",
-  "version": "7.38.0",
+  "version": "7.38.1",
   "description": "Opinionated, gated workflow skills, subagent personas, and runtime extensions for the pi coding agent.",
   "author": "Jacek Juraszek",
   "type": "module",

package/skills/brainstorming/reference/amendment-surface.md

@@ -142,7 +142,33 @@ Before the aftermath, `read` this section again; never run it from memory.
 
 Apply accepted items only: reviewer clears, `accept`, `alt-n`, and state-changing `custom`. Print one line per applied item: `amended the spec: <title> - <what>`.
 
-Aftermath, once per batch, only when at least one item applied (nothing applied -> skip to the commit below). Ledger exists (line 1 `# Ledger - loop engine` in the resolved plan dir) -> skip `plan-writer`, `plan_check`, and `plan_tracker`. Reconcile the ledger against the approved spec dispositions: `deviates:`, `deferred:`, or `elsewhere:` -> `cut`, evidence = the disposition; factual or requirement-preserving amendment -> preserve rows; re-bounded `done` row -> `open`, evidence = `reopened by amendment`. Preserve every row's attempts and the ledger's iterations. Never auto-edit ticket or approved drafted AC row texts; reconcile dispositions only, never text/add/remove changes. Commit spec + ledger together with subject `loop: cut row <n>` for a batch containing only one cut, otherwise `loop: amend` (including mixed batches), carrying the amendment audit body below (including each `granted` record and granting sentence); continue without task-plan aftermath. No plan yet -> commit the spec; continue. Plan exists -> read `git -C "<abs worktree path>" status --porcelain` (plain jj: `jj -R "<abs worktree path>" diff --summary`); collect the parent's in-flight workflow edits as worktree-relative paths, including the amended spec and staged in-place wave-repair deliverables. Dispatch `plan-writer` per `writing-plans` `## Author the plan` step 3 with an `Amend:` block naming the amended spec sections, an `In-flight:` list of those paths (the parent supplies the set; the child never infers it), and the rule "preserve every task title and wave position the amendment does not touch; edit only affected anchors and tasks", then run that section's steps 5-6 (the parent `plan_check` and its branches), then read the amended plan once (step 7's read, without its phase completion or `plan_tracker` init) - the main loop never edits the plan text; then update the tracker: `plan_tracker` `add` for new tasks; anchor-changed completed tasks are reopened as `in_progress` and re-run the task loop (`update` never sets `pending`). A removed task is deleted from the plan; then re-`init` the tracker with `{ name, status }` elements: preserved tasks keep their order and statuses, reopened tasks are `in_progress` in place, every still-`pending` task (including newly added ones, whatever wave label they carry) trails the non-pending ones, removed tasks are the only deletions (the only permitted `init` after handoff; never `clear`). Commit spec + plan together; continue. A task reopened while `verify` or `ship` is in progress stays in that phase - no `phase_tracker` call. Repair it through the current phase's fix loop and `plan_tracker({ action: "update", index: N, status: "complete" })` it once that repair's review or re-audit accepts; open tasks block `complete verify`, and in `ship` nothing checks them, so close them explicitly.
+Aftermath, once per batch, only when at least one item applied (nothing applied -> skip to the commit below). Ledger exists (line 1 `# Ledger - loop engine` in the resolved plan dir) -> skip `plan-writer`, `plan_check`, and `plan_tracker`. Reconcile the ledger against the approved spec dispositions: `deviates:`, `deferred:`, or `elsewhere:` -> `cut`, evidence = the disposition; factual or requirement-preserving amendment -> preserve rows; re-bounded `done` row -> `open`, evidence = `reopened by amendment`. Preserve every row's attempts and the ledger's iterations. Never auto-edit ticket or approved drafted AC row texts; reconcile dispositions only, never text/add/remove changes. Commit spec + ledger together with subject `loop: cut row <n>` for a batch containing only one cut, otherwise `loop: amend` (including mixed batches), carrying the amendment audit body below (including each `granted` record and granting sentence); continue without task-plan aftermath. No plan yet -> commit the spec; continue. Plan exists -> read `git -C "<abs worktree path>" status --porcelain` (plain jj: `jj -R "<abs worktree path>" diff --summary`); collect the parent's in-flight workflow edits as worktree-relative paths, including the amended spec and staged in-place wave-repair deliverables. Dispatch `plan-writer` per `writing-plans` `## Author the plan` step 3 with an `Amend:` block naming the amended spec sections, an `In-flight:` list of those paths (the parent supplies the set; the child never infers it), and the rule "preserve every task title and wave position the amendment does not touch; edit only affected anchors and tasks", then run that section's steps 5-6 (the parent `plan_check` and its branches).
+
+At that return point, classify human-facing outcomes with this table; let writing-plans' first `Findings:` repair run as written.
+
+| Outcome | Enter the attribution check |
+|---|---|
+| Second identical `plan_check` FAIL | compare the FAIL lines and their quoted plan text |
+| First `- Task N: ... fails on <sha>` or `dirtied tracked source` row | compare the row's baseline command |
+
+Compare the quoted FAIL plan text or baseline command with this batch's edits: use the owning task's `Spec:` anchors to an amended section or its changed `Tests:` text against `git -C "<abs worktree path>" show HEAD:<plan path>`. Require text this batch added or changed; neither a plan line number, task membership, nor retained baseline evidence proves attribution. For unchanged text and writer-only defects (such as missing `baseline:` without spec text behind it), render the writing-plans step-6 branch in full from the outcome already in hand: quote the FAIL lines verbatim as the open question; state the task, command, SHA, exit, and summary with `fix-first`, `narrow`, and `amend` options on their own lines and `Recommendation: <option> - <reason>`, then pause; name dirty paths and cause; clear the parent's own wave/amendment source work through its own commit step and list doc-only work under `In-flight:` before re-dispatch; take every other path, including every test-dirtied path, to the human to commit, discard, or move, without restoration - never name step 6 and defer the exit. Partition mixed output: form items only from attributable lines and render the unrelated lines' step-6 branches in full by the same rule. Classify attributable outcomes as amendment items independent of candidate answers and grant state. Keep findings from this batch's own aftermath in this batch until commit; apply section 1's later-finding rule after commit.
+
+Apply at most two aftermath items per batch. Send a third human-facing outcome, or evidence repeating an already-applied item's evidence, to step 6 as written without restoration, rendering the exit in full and listing the batch's retry items and evidence. Before restoring any path, handle a redraw-class finding by committing the batch as-is, handing dirty paths to step 6 without restoration, then taking `../SKILL.md`'s redraw path. Treat the spec/plan commit as batch preservation, not cleanup. For an amend-class `dirtied tracked source` row, check every named path with `git -C "<abs worktree path>" ls-files -- "<path>"` and against the spec, plan, and `In-flight:` list. Require every path to print as tracked and to be outside those protected paths before restoring any. Route an entire row with any untracked or protected path through step 6, without partial restoration; a new `??` at a `Create:`/`Test:` path is ineligible. Preserve `artifacts:` and `In-flight:` paths. Restore exactly the eligible row's paths, one quoted path per command, in the explicit worktree; for example:
+
+```bash
+git -C /tmp/report-worktree ls-files -- "eval/report-runner/report.md"
+git -C /tmp/report-worktree checkout -- "eval/report-runner/report.md"
+# Plain jj: root the fileset; -R alone does not root paths.
+jj -R /tmp/report-worktree restore -- 'root:"eval/report-runner/report.md"'
+```
+
+Use the checkout command for git or the restore command for plain jj, not both. Stop on a nonzero restore and print the shell error. Keep this narrow restore with the orchestrator, never the plan-writer or implementer; grant no general permission to restore test damage. Preserve the pre-batch working tree except for batch edits.
+
+Hold each eligible item with verbatim FAIL lines or baseline row as `evidence`, the correction as `recommended: accept` or a named `alt-n`, and the amended-section `location`. Re-read the grant through section 1's predicate and Value decoding before applying: malformed -> stop and quote the offending lines; amend permission -> apply the recommended edit and print `amended the spec: <title> - <what>`; budget-only, `none`, or absent -> run sections 2-4 and end the turn without re-dispatch. After the reply, apply only the chosen edit; return a redirect or drop to the original step-6 exit without re-dispatch over the unfixed spec.
+
+After an applied aftermath item, re-dispatch the plan-writer with only an `Amend:` block naming the amended sections and quoting the FAIL lines or baseline row inside its rule sentence, plus `In-flight:` including both spec and plan. Preserve unaffected task titles and wave positions. Run the parent's steps 5-6 again through this return point; retain the ledger/no-plan bypass above before any retry.
+
+Finalize every plan aftermath path once, only after steps 5-6 return `PASS`, including the first dispatch's `PASS` without a retry: read the amended plan once (step 7's read, without its phase completion or `plan_tracker` init) - the main loop never edits the plan text; then update the tracker: `plan_tracker` `add` for new tasks; anchor-changed completed tasks are reopened as `in_progress` and re-run the task loop (`update` never sets `pending`). A removed task is deleted from the plan; then re-`init` the tracker with `{ name, status }` elements: preserved tasks keep their order and statuses, reopened tasks are `in_progress` in place, every still-`pending` task (including newly added ones, whatever wave label they carry) trails the non-pending ones, removed tasks are the only deletions (the only permitted `init` after handoff; never `clear`). Commit spec + plan together; continue. A task reopened while `verify` or `ship` is in progress stays in that phase - no `phase_tracker` call. Repair it through the current phase's fix loop and `plan_tracker({ action: "update", index: N, status: "complete" })` it once that repair's review or re-audit accepts; open tasks block `complete verify`, and in `ship` nothing checks them, so close them explicitly.
 
 One commit per batch:
 
@@ -153,7 +179,7 @@ amend: <N> item(s) - <first title>[, <second title>]
 <the granting sentence, quoted, when a grant applied>
 ```
 
-For a ledger batch, use the loop subject above and retain this same audit body. `amend:` is the subject marker `finishing-a-development-branch` Step 4 greps for its digest; `<what>` is the item's one-sentence what-changes field, so the digest renders `<title> - <what changed>` from the body alone. When no item applied (every item dropped or redirected), nothing changed on disk; the commit still lands, with `git commit --allow-empty`, so the per-item `custom(<effect>)` records stay in the batch body - the digest ignores them because it reads only `auto-apply` and `granted` records. Wrong apply -> `git revert` the batch commit; then read the `**Amend-grant:**` line from the pre-revert HEAD (`git -C <abs worktree path> show HEAD^:<spec path>` through the predicate) and, if the working tree's line differs, restore that value and persist it per [Standing grants](#standing-grants) before re-entering this surface for the items to keep - the pre-revert HEAD holds every consent change committed so far, revocations included.
+Record aftermath items in this same audit as `granted` or `accepted`/`alt-n` with their evidence, in the single `amend:` commit whose `git revert` undoes the retries with the batch. For a ledger batch, use the loop subject above and retain this same audit body. `amend:` is the subject marker `finishing-a-development-branch` Step 4 greps for its digest; `<what>` is the item's one-sentence what-changes field, so the digest renders `<title> - <what changed>` from the body alone. When no item applied (every item dropped or redirected), nothing changed on disk; the commit still lands, with `git commit --allow-empty`, so the per-item `custom(<effect>)` records stay in the batch body - the digest ignores them because it reads only `auto-apply` and `granted` records. Wrong apply -> `git revert` the batch commit; then read the `**Amend-grant:**` line from the pre-revert HEAD (`git -C <abs worktree path> show HEAD^:<spec path>` through the predicate) and, if the working tree's line differs, restore that value and persist it per [Standing grants](#standing-grants) before re-entering this surface for the items to keep - the pre-revert HEAD holds every consent change committed so far, revocations included.
 
 ## Conformance entry