@opengsd/gsd-path 1.5.0 → 1.6.1

package/skills/gsd-path/scripts/workflow_run.py

@@ -210,8 +210,14 @@ def run_workflow(repo: Path, action: str, project_dir: str, expected_head: str =
                         "--base", expected_head, "--task-id", task_id,
                         "--round-size", str(round_size))
             if task["mode"] == "serial":
+                name = f"task-{task_id.lower()}-verify"
+                stale = isolation.sidecar_root(repo, "verify", name)
+                if os.path.lexists(stale / ".git"):
+                    # An earlier prepare-task left this sidecar. Only one that is proven untouched is replaced.
+                    steps.append({"script": "isolation.py", "result": isolation.retire_stale_verify(
+                        repo, stale, isolation.verify_branch_name(name))})
                 step("isolation.py", "isolate-verify", "--repo", str(repo),
-                     "--base", expected_head, "--name", f"task-{task_id.lower()}-verify")
+                     "--base", expected_head, "--name", name)
         elif action == "build-evidence":
             proof = step("build_state.py", "verify-landed", *common, "--head", expected_head)
             # The landing proof has one canonical home; lean final-review reuse allows only this path.
@@ -278,7 +284,8 @@ def run_workflow(repo: Path, action: str, project_dir: str, expected_head: str =
             if action == "approve-plan":
                 step("pipeline_state.py", "approve", *common, "--kind", "plan",
                      "--expected-head", expected_head)
-    except (StepFailed, OSError, subprocess.CalledProcessError, ValueError, KeyError, TypeError) as error:
+    except (StepFailed, isolation.IsolationError, OSError, subprocess.CalledProcessError,
+            ValueError, KeyError, TypeError) as error:
         return {"status": "blocked", "reason": str(error), "steps": steps,
                 "next": next_step}
     return {"status": "complete", "steps": steps, **outputs}

package/skills/gsd-path/templates/final-review.md

@@ -21,12 +21,12 @@ Overall verdict: <pass | blocked>
 
 ## Success criteria
 
-<!-- Each `### SCn —` title must match INTENT.md `## Success criteria` as
-     `_success_criteria` stores it: continuation lines join with a single
-     space and keep `- ` sub-bullet markers; comparison uses `_normalize_ws`
-     only. -->
+<!-- Each `### SCn —` title has every word of the criterion in INTENT.md
+     `## Success criteria`: join continuation lines and sub-bullets with a
+     single space (the `- ` markers of sub-bullets are optional). The gate
+     compares every other word. -->
 
-### SC1 — <criterion as stored by the gate>
+### SC1 — <criterion from INTENT.md>
 
 - **Verdict**: <met | not-met | unverifiable>
 - **Surface**: <exactly the surface name PLAN.md's Surface contract lists this criterion under, with no detail after it; omit the whole field for any other criterion>

package/skills/gsd-path/templates/state.md

@@ -13,6 +13,7 @@ archive: null       # persisted archive transaction path; never recomputed
 integration_default: direct # direct | pull-request | external-landing; project setting
 integration: direct # current milestone; may override the default before build
 integration_source: default # default | milestone; preserves override provenance
+default_branch: main # origin default branch; initialization records it once, nothing changes it
 ---
 
 # Project State

package/skills/gsd-path/templates/task.md

@@ -11,6 +11,7 @@ task_branch: null   # orchestrator-owned: gsd-path-task/<id> while parallel; nul
 # Optional explicit dispatch overrides: model: <advertised slug|inherit>
 # effort: <advertised effort|inherit>
 # repo: <member>    # multi-repo only: the MEMBERS.md member this task changes; omit for the coordinator
+# supersedes: [<task id>]  # only when INTENT requires it: earlier-wave tasks whose behavior this task replaces; retires their Verify
 files:              # every file this task may touch — dispatch checks overlap
   - <path>
 ---

package/skills/gsd-path/templates/wave-review.md

@@ -26,9 +26,17 @@ Tasks reviewed: <count>
 
 ## T001 — <title>: <pass | fail>
 
-<!-- Per task criterion: copy the full acceptance/interface criterion verbatim
-     before the em dash; join wrapped lines with spaces. An AC id or summary
-     alone cannot be matched by review_findings.py. -->
+<!-- Task sections go in task id order (T001 before T002), not in the order
+     of the PLAN.md wave table. The heading title is the exact `title:` of
+     the task file. An evidence line starts with `- ✅ ` (pass) or `- ❌ `
+     (fail). A section needs one or more lines with the marker of its own
+     verdict, so a failed task needs a `- ❌ ` criterion line.
+     Per task criterion: copy every word of the acceptance/interface
+     criterion before the em dash; join wrapped lines and sub-bullets with
+     spaces (the `- ` markers of sub-bullets are optional). An AC id or
+     summary alone cannot be matched by review_findings.py.
+     Write literal markup and code in backticks inside a sentence: text
+     such as <b> outside backticks reads as an unfilled placeholder. -->
 - ✅ <criterion> — <evidence: verify output / file:line checked>
 - ❌ <criterion> — found: <what exists instead, file:line>
   fix: <concrete direction a coder can execute without re-investigating>
@@ -47,13 +55,14 @@ Contract violations (blocking):
      wave, ending `: pass` or `: fail`. `scripts/check_handoffs.py wave
      --review <this file>` gates the SC id set and verdicts. Omit this
      section when no task in the wave owns an SC.
-     Copy the criterion text from INTENT.md `## Success criteria` exactly as
-     `_success_criteria` stores it: indented continuation lines join with a
-     single space and keep their leading `- ` markers; the gate compares
-     heading text with `_normalize_ws` only (no paraphrase or stripped
-     sub-bullets). -->
+     Copy every word of the criterion from INTENT.md `## Success criteria`:
+     join indented continuation lines and sub-bullets with a single space
+     (the `- ` markers of sub-bullets are optional). The gate compares every
+     other word: no paraphrase, no dropped sub-bullet.
+     Each SC block needs an evidence line with the marker of its own
+     verdict: `- ✅ ` (pass) or `- ❌ ` (fail). -->
 
-### SC1 — <criterion as stored by the gate>: <pass | fail>
+### SC1 — <criterion from INTENT.md>: <pass | fail>
 - ✅ <evidence: verify output / file:line checked>
 - ❌ <criterion> — found: <what exists instead, file:line>
   fix: <concrete direction a coder can execute without re-investigating>

package/skills/gsd-path-build/references/build-native.md

@@ -128,6 +128,10 @@ dispatch contract and perform steps 1–5 by hand.
        rerun `recover`. The original lineage must stay reachable: keep a local
        branch on the old tip until the milestone ships. Adopted tasks report
        `attested` with `provenance: owner-authorized-rebase`.
+   - `block` with a `leftover` path: the task is landed, and that path is what
+     a failed removal left of its isolate; it holds nothing that Git does not
+     have. Do not set `build/blocked`. Stop with the returned reason; after
+     the path is removed, rerun `recover`.
    - `block` for any other reason: set `build/blocked` with the returned
      reason and stop.
    - `none`: take no recovery action for that task.
@@ -142,6 +146,13 @@ dispatch contract and perform steps 1–5 by hand.
    order, or overlap-check tasks in prose. Readiness is continuous, not
    layered: a task becomes selectable the moment its last dependency lands,
    even while unrelated tasks still run, so rerun `ready` after each landing.
+   Two tasks that each share a file with the same `done` task of an earlier
+   wave never run together: `ready` returns one and holds the other until the
+   first is `done`. The second then starts from a base that has the first
+   landing, and the step 5 rerun of the earlier Verify checks both edits. A
+   task with a retained isolate keeps its turn. A task that a `supersedes`
+   field retires still counts: the superseding task never runs together
+   with a task that shares a file with the superseded task.
    A `NEEDS-ORCHESTRATOR` block stays unselectable until its `Orchestrator
    answer` is recorded in the task Log and the task is back to `pending`.
    An all-done wave whose latest canonical review cycle has any blocked lens
@@ -151,6 +162,11 @@ dispatch contract and perform steps 1–5 by hand.
    repair remains, `ready` returns no tasks and adds `blocked_review` (`wave`,
    `cycle`, `waiting_waves`); a later passing canonical review cycle releases
    the waiting waves.
+   `unreviewed_waves`, when present, lists earlier waves whose tasks are all
+   `done` and that have no canonical review file. A repair wave is not
+   listed: the next review cycle of its source wave judges it. `ready` reports
+   the listed waves and does not hold the returned tasks: run step 6 for each
+   listed wave before you dispatch.
    Its typed errors are the recovery rule:
    - `task-recovery-required`: for each listed failed or blocked task run
      `python3 <absolute build_state.py> reconcile --repo <absolute primary>
@@ -263,7 +279,8 @@ dispatch contract and perform steps 1–5 by hand.
    defective task contract before establishing the round base. Run ready work
    up to capacity. Verify commands marked `Heavy: yes` (`verify_heavy` in the
    ready set) run one at a time across every concurrent task, including the
-   step 5 rerun; light ones are unconstrained. Do not wait for the whole
+   step 5 rerun; light ones are unconstrained. `verify_heavy` is also true
+   when step 5 reruns a heavy Verify of an earlier task. Do not wait for the whole
    round before unlocking dependents: each task landing in step 5 re-opens
    step 2, and a newly ready
    task dispatches in a fresh round at the current clean HEAD while unrelated
@@ -289,8 +306,35 @@ dispatch contract and perform steps 1–5 by hand.
      native child tools; no child command is needed. It reproduces serial work
      in its prepared sidecar, runs authoritative Verify, records exact output,
      lands through `isolation.py`, records eligible ledger evidence, and retires
-     the isolate. A `landed` receipt proves those steps; do not run them again
-     or author another implementation narrative. A blocked receipt preserves
+     the isolate. Authoritative Verify is the task's own Verify, then the
+     Verify of each `done` task of an earlier wave, in the same repo, that
+     shares a declared file with this task. `finish` selects those commands;
+     never select them by hand. An earlier command does not run again in two
+     cases only: it is identical to the own Verify, or the own Verify is the
+     unchanged Verify that `fix-tasks` wrote from the task's `deps` and the
+     command belongs to one of them. A Verify that only contains the command
+     text does not replace the rerun. A failed earlier-task Verify blocks the landing as a
+     failed own Verify does. The receipt (`regressions`) and the task Log
+     entry `orchestrator regression Verify of <task id>` name the earlier
+     task. The ledger records only the own command.
+     A plan-approved `supersedes` field retires the Verify of each earlier
+     task that it names: `finish` does not run that Verify for the task, or
+     for a task that lands after the task is `done`. The receipt (`retired`)
+     and the task Log entry `orchestrator regression Verify of <task id>
+     retired: superseded by <task id>` name both tasks. When the generated
+     Verify of a fix task loses only the copy of a retired Verify, the
+     `retired` entry has the key `part` and the Log entry is `orchestrator
+     regression Verify of <fix task id>: part of <task id> retired:
+     superseded by <task id>`. The superseding
+     task inherits the role of each task that it names, also through a
+     chain: after it is `done`, its Verify runs in the place of the retired
+     Verify for each later landing that shares a file with a superseded
+     task, also in its own wave. The Log entry is `orchestrator regression
+     Verify of <task id> (supersedes <task id>)`.
+     A `landed` receipt proves those steps; do not run them again
+     or author another implementation narrative. A `cleanup_warning` on a
+     landing means only that the isolate was not removed: the task is landed,
+     and the next `round` or `finish` checks the isolate again. A blocked receipt preserves
      its failure evidence and follows the recovery rule, never a manual bypass.
      Keep the pre-finish declared-path check above. Each landing re-opens step 2
      so ready dependents can run while unrelated children remain in flight.
@@ -503,26 +547,69 @@ dispatch contract and perform steps 1–5 by hand.
      again.
    - Otherwise batch `fix_batches` into complete fix tasks from the task
      template — one task per batch, never one per finding — each carrying
-     its groups' failed criteria and observed evidence verbatim. A group
+     its groups' failed criteria and observed evidence verbatim. Each batch
+     is in one repo: a batch with `repo` is for that member and its fix task
+     has `repo: <member>`; a batch without `repo` is for the coordinator. A
+     finding whose source tasks are in two repos gives one batch for each
+     repo. A group
      with `repeat` true is evidence its earlier fix failed, never a new
      finding; a re-review never spawns a duplicate fix task for a finding
-     already carried. Write each fix task to `.project/tasks/` with `wave`
+     that a fix task not yet `done` already carries in the same repo. A
+     repeat after its fix
+     landed gets the next fix task. After a build recovery, a changed wave
+     is reviewed again from cycle 1; the fix tasks and PLAN.md repair wave
+     of the review that recovery set aside do not count for the new one.
+     Write each fix task to `.project/tasks/` with `wave`
      set to the current wave or a newly appended `## Wave N` heading in
-     PLAN.md before dispatch. Its dependencies include every source task in
-     the batch; its files match the batch. In `## Review findings`, use one
+     PLAN.md before dispatch. Its dependencies include every source task of
+     the batch that is in the same repo, and every landed fix task of the
+     same source wave and repo that carried one of its findings; its Verify
+     runs the Verify of those source tasks; its files are the batch files or a subset of them, never
+     none. When a finding names a fix site outside the batch files, follow
+     [build recovery](build-recovery.md) to plan, which adds a repair task
+     with those files, the batch's `## Review findings` and the same
+     dependencies; `repair-evidence` accepts that task. In
+     `## Review findings`, use one
      `### <locator>` block per group, `Criterion: <verbatim criterion>`, and
      every observation verbatim. Run the repair through the same isolated
      layer loop, even when its appended wave repairs an earlier blocked wave.
+     An appended repair wave has the highest wave number and still runs before
+     the pending waves, because `ready` gates them on the blocked wave (step
+     2). Do not renumber waves or move the repair wave.
      After landing, call `review_findings.py repair-evidence --repo <primary>
      --wave <source wave> --cycle <source cycle> --task <repair id>` and save
-     its JSON as the repair evidence for the next review. The helper validates
+     its JSON as the repair evidence for the next review. The helper selects
+     the batch by the repair's locators and repo, then validates
      the carried batch, original and repair landings, isolated product scope,
-     unchanged source reports and reusable Verify. On success, brief the next
+     unchanged source reports and reusable Verify. For a member repair it
+     checks the product in the member repository, against the member commits
+     and the member Verify record, and the receipt adds `member`,
+     `member_base` and `member_commit`. Another change to the checked files
+     is accepted only when it is the landing of a linked repair: a `done`
+     task of the same repo that carries one of the repair's findings in
+     `## Review findings`, with the same locator and criterion, and is
+     joined to the repair by `deps`. A finding on an acceptance criterion of
+     a fix task counts as the finding that this fix task carries with the
+     same criterion; the same criterion text under another locator is
+     another finding. Linked
+     repairs in the repair base are in `earlier_repairs`. Linked repairs
+     after the repair are in `later_repairs`; then the landing and the
+     recorded Verify of the last one are the evidence, and `chain_files`
+     lists the files checked from the repair base to the tip: those of the
+     repair and of every later linked repair. From the repair base to the
+     parent of the repair landing, no landing can change these files, also
+     not a linked one. On success, brief the next
      original-wave review with this receipt and the reviewer role's
      **Re-review after a proven repair** contract. Reuse command evidence;
      the new review judges the repaired product against the original criteria.
      Preserve prior verdicts and source tasks. On helper rejection, resolve
      the evidence blocker rather than redispatching an already proven fix.
+     When the blocker cannot be resolved, for example `repair base contains
+     unlinked changes to original product` or `product changed after the
+     repair landing` because a task that is not a linked repair changed the
+     same files, run the next review cycle of the source wave in full at the
+     current HEAD, without the receipt. This is the supported fallback: it
+     needs no ruling and no plan change.
    At the cap, record all attempts in the STATE.md log and ask the user —
    through an interactive user-input tool when available — after linking
    the resolved absolute blocking wave review, every deep lens file for the

package/skills/gsd-path-build/references/build-recovery.md

@@ -69,6 +69,19 @@ checks landed-task preservation and restored intent ownership, restores review
 evidence only for unchanged contracts, and creates the normal journaled plan
 checkpoint. A failed approval leaves recovery open.
 
+A wave keeps its review evidence when INTENT.md, its own `## Wave N` section,
+its task files, and every other non-wave PLAN.md section are byte-identical to
+the recovery base. Two edits are exempt: the value of the `max_review_cycles`
+and `wave_budget` lines in `## Config`, and all of `## Dependency notes`. In
+`## Config` only those two values may change; any other edit there, a comment
+edit included, drops the evidence of every wave, as does any other non-wave
+edit. A `- review_panel:` line that is added, removed, or changed anywhere in
+PLAN.md also drops the evidence of every wave. The approval result reports
+this in `recovery_reviews`: `restored` lists the waves that kept their evidence, and
+`review_again` lists each wave that lost it, with the reason. Review every
+`review_again` wave again after build resumes; completion refuses a wave
+without a passing review.
+
 Return through `plan/done → build/active` with event `build started`. The dispatch
 driver uses a separate record directory for this recovery base, while retaining
 the milestone budget ledger. Resume only from the new approved task inventory.

package/skills/gsd-path-build/references/coder.md

@@ -51,9 +51,13 @@ costs the run.
 2. Satisfy every acceptance criterion and every owned INTENT success
    criterion within the Approach constraints, matching conventions in the
    listed files.
-3. Edit only exact paths in `files`, plus the task file's Log. There is no
-   exception for imports, routes, generated files, or wiring.
-4. Run Verify. Fix failures only within the allowed paths.
+3. Edit only paths in `files`, plus the task file's Log. A declared
+   directory covers the files below it; a declared file covers only itself.
+   There is no exception for imports, routes, generated files, or wiring.
+4. Run Verify. Fix failures only within the allowed paths. The orchestrator
+   also runs the Verify of each earlier-wave task that shares a file with
+   yours. A Log entry `orchestrator regression Verify of <task id>` with
+   `fail` names a task you broke; make its Verify pass too.
 5. Append the implementation and Verify result to Log. On a block, append the
    specific reason. Do not edit frontmatter state.
 

package/skills/gsd-path-build/references/model-policy.md

@@ -70,7 +70,9 @@ settings block; their default inheritance remains usable.
 Resolve the bundled helper to an absolute path. Use one record under the Git
 common directory's `gsd-path/model-selection/` directory per assignment. Scope
 the path and `--scope` to the milestone, active/lookahead track, and review cycle
-where applicable; later work must not reuse an earlier record.
+where applicable; later work must not reuse an earlier record. The helper
+refuses a relative `--record`, and `release` of a missing record names the
+path and creates nothing.
 
 ```text
 python3 -B <helper> resolve --repo <primary> --scope <milestone/track/cycle> --assignment <logical-name> --role <role> --record <absolute-record> --capabilities <advertised-json>

package/skills/gsd-path-build/references/operating-rules.md

@@ -38,8 +38,8 @@ bundles this file; spawned agents follow their role brief instead.
   the lookahead planning track for the next milestone; it follows the same
   marker rule, owns no task frontmatter, and never binds a branch.
 - STATE.integration_default is the project closeout choice and
-  STATE.integration is the current milestone choice. Both are `direct` or
-  `pull-request`; STATE.integration_source is `default` or `milestone` and
+  STATE.integration is the current milestone choice. Both are `direct`,
+  `pull-request`, or `external-landing`; STATE.integration_source is `default` or `milestone` and
   preserves explicit override provenance. Older v2 state defaults to `direct`,
   and modes may be changed only through `pipeline_state.py
   configure-integration` before build. A next milestone resets its current
@@ -82,7 +82,9 @@ bundles this file; spawned agents follow their role brief instead.
   `isolation.py attest` may stand in for it: one `.project/`-only commit that
   names the base, the attested HEAD, the declared files that changed, the
   task Verify recorded as passing at that HEAD, and the ruling verbatim.
-  `recover` reports it as `attested`, never as a proven landing.
+  `recover` reports it as `attested`, never as a proven landing. Attestation
+  matches the declared files literally: work that is only below a declared
+  directory can land but cannot be attested.
 - All pipeline work for a milestone lives on `gsd-path/M00N` (M001, M002,
   …) bound in STATE.branch. The next milestone binds a new unused
   `gsd-path/M00N` at the remote default after the previous ship integrates.
@@ -90,6 +92,12 @@ bundles this file; spawned agents follow their role brief instead.
   branch — either Path's direct merge or a Path-owned PR merged by the user.
   The bound branch never receives merges or back-merges and is never the
   GitHub default.
+- The default branch is the one that STATE `default_branch` records at
+  initialization; a STATE file without the field means `main`. `main` and
+  `origin/main` in these rules mean that branch. Never change the record and
+  never take the name from a later `origin/HEAD` lookup. For a member
+  repository, the branch is the one that its `.project/MEMBERS.md` section
+  records as `Default branch`; a section without the field means `main`.
 - After initialization writes STATE.md, and before entering the first pipeline
   phase in an existing Git repository, the router calls
   `scripts/pipeline_git.py bind-initial` with the selected M00N and exact
@@ -128,8 +136,9 @@ bundles this file; spawned agents follow their role brief instead.
   for the current STATE.branch milestone must be an ancestor of origin/main;
   if it is not, that milestone's integration is incomplete and control routes
   to ship, not build. Direct mode requires the matching canonical `integrate:`
-  commit; PR mode requires tag metadata and a two-parent merge whose second
-  parent is the ship commit. A null branch returns
+  commit; PR mode requires tag metadata and either a two-parent merge whose
+  second parent is the ship commit or a proven rebase merge of the ship
+  commits. A null branch returns
   to the router; build never creates, selects, switches, or rebinds it.
 - The ship phase makes exactly one commit on the bound branch — the
   `.project/`-only ship commit recording

package/skills/gsd-path-build/references/reviewer-final.md

@@ -1,11 +1,11 @@
 ## Final integration mode
 
 Use only final-review.md. Treat INTENT.md success criteria as the rubric.
-Each `### SCn —` heading must match the criterion text as
-`check_handoffs._success_criteria` stores it from INTENT.md `## Success
-criteria`: indented continuation lines join with a single space and keep
-their `- ` list markers; the gate compares titles with `_normalize_ws`
-only. Exercise the running system and record `met`, `not-met`, or
+Each `### SCn —` heading must have every word of the criterion in INTENT.md
+`## Success criteria`: join indented continuation lines and sub-bullets
+with a single space. You can keep or remove the `- ` markers of the
+sub-bullets; the gate compares every other word. Exercise the running
+system and record `met`, `not-met`, or
 `unverifiable` with checked command output or a precise file reference.
 When PLAN.md carries
 a `## Surface contract`, every criterion it lists under a surface is checked

package/skills/gsd-path-build/references/reviewer-wave.md

@@ -17,19 +17,21 @@ tasks in this wave as the rubric. For each task:
    criterion. Never use the primary worktree or branch tip as task
    evidence. Do not create or remove Git worktrees yourself.
 4. Mark `pass` or `fail`. Before the evidence separator (` — `), copy the
-   complete task acceptance or interface criterion verbatim, joining wrapped
-   lines with spaces. Do not substitute an AC id or summary: finding grouping
-   binds this text to the task. Give the observed result, `file:line`, and
+   complete task acceptance or interface criterion (see Review file format
+   below). Do not substitute an AC id or summary: finding grouping binds
+   this text to the task. Give the observed result, `file:line`, and
    concrete fix direction for each failure.
 
+A Log entry `orchestrator regression Verify of <task id> retired: superseded
+by <task id>` is not evidence: judge the superseding task's acceptance
+criteria. The same applies to the entry `orchestrator regression Verify of
+<fix task id>: part of <task id> retired: superseded by <task id>`.
+
 Then check each INTENT.md success criterion owned by a task in this wave
 against that same isolated product. In each `### SCn —` heading, copy the
-criterion text exactly as `check_handoffs._success_criteria` stores it from
-INTENT.md `## Success criteria`: indented continuation lines are joined
-with a single space and keep their `- ` list markers in the compared text;
-only whitespace is normalized at the gate. Do not paraphrase or drop
-sub-bullets. Mark `pass` or `fail` with evidence; a failed owned SC blocks
-the wave. Omit the Intent coverage section when no task in the wave owns
+complete criterion text from INTENT.md `## Success criteria` (see Review
+file format below). Mark `pass` or `fail` with evidence; a failed owned SC
+blocks the wave. Omit the Intent coverage section when no task in the wave owns
 an SC. When INTENT.md `## Edge coverage` or `## Prohibitions` has rows for
 an owned SC, judge it against those rulings too: cite each `held-out` edge
 id with its held-out test's recorded output and each `judgment` prohibition
@@ -48,6 +50,30 @@ For cycle greater than 1, read the previous review, re-check every failure,
 and regression-check affected passes. State when the same criterion fails for
 a different reason. Use only the wave-review template.
 
+### Review file format
+
+`scripts/check_handoffs.py wave` rejects a review file that breaks one of
+these rules, and `scripts/review_findings.py` cannot group a failure whose
+criterion text does not match. Apply the rules before you write the file.
+
+- **Section order.** Put the `## T### —` sections in task id order (T001
+  before T002). The order of the PLAN.md wave table does not apply. A `pass`
+  review has one section for each task of the wave.
+- **Section heading.** Write `## T### — <title>: pass` or `: fail`, where
+  `<title>` is the exact `title:` value of the task file.
+- **Evidence lines.** An evidence line starts with `- ✅ ` for pass or
+  `- ❌ ` for fail. Each task section and each `### SCn —` block needs one
+  or more lines with the marker of its own verdict. A failed task needs a
+  `- ❌ ` criterion line, also when other text describes the failure.
+- **Criterion text.** In a task evidence line and in a `### SCn —` heading,
+  copy every word of the criterion. Join wrapped lines and sub-bullets with
+  one space. You can keep or remove the `- ` markers of the sub-bullets.
+  A changed, added, removed or moved word does not match.
+- **Angle brackets.** Text such as `<b>` or `<path>` outside backticks reads
+  as an unfilled template placeholder and is rejected. Write literal markup
+  and code in backticks inside a sentence, for example: the output has
+  `<b>hello</b>`.
+
 ### Re-review after a proven repair
 
 When the brief supplies a `review_findings.py repair-evidence` receipt, use
@@ -55,14 +81,21 @@ its isolated repair product for the linked original criteria, including owned
 INTENT criteria. The original faulty landing and earlier verdicts remain
 historical evidence; they do not force the later verdict to remain failed.
 Reconstruct the receipt's repair `base` plus only its `commit^..commit` patch
-for `files` inside the supplied sidecar. Read the repair task's recorded
-Verify, inspect the patch against the original unchanged contract, and reuse
+for `files` inside the supplied sidecar. For a member repair (the receipt
+names `member`), use `member_base` and `member_commit` in that member's
+repository. `earlier_repairs` are linked repairs of the same findings that
+are already in the repair base. When the receipt has `later_repairs`, linked
+repairs changed the same files after this repair: apply their patches in
+order too. Read the repair task's recorded
+Verify, or with `later_repairs` that of the last one, which is the receipt's
+`verification`; inspect the patch against the original unchanged contract, and reuse
 settled checks. Check unaffected criteria from their prior evidence plus the
 repair diff for regressions. Cite the receipt, repair landing and task Log in
 the new review. A receipt proves provenance, not acceptance: judge whether the
 repair actually satisfies the criterion. A missing or rejected receipt blocks
-using that repair; the parent resolves it rather than creating another product
-fix for the unchanged historical failure.
+using that repair; the parent resolves it, or briefs this review in full at
+the current HEAD without a receipt, rather than creating another product fix
+for the unchanged historical failure.
 
 ## Final scope in a quick full wave
 

package/skills/gsd-path-build/references/runtime-selection.md

@@ -20,6 +20,16 @@ references to bundled copies of those helpers. Other skill helpers, templates,
 and role briefs remain in the installed skill bundle. Pass `-B` to Python helper
 invocations so execution does not create bytecode in the runtime store.
 
+The selected runtime is authoritative for each helper in its `manifest.json`;
+this includes `review_findings.py` and `task_context.py`. A selected runtime
+that was published before a helper became a runtime file does not list that
+helper: run the bundled copy until the project runtime is upgraded.
+`dispatch_driver.py` and `workflow_run.py` always run from the installed skill
+bundle, because they read role briefs and templates from it; a skill update
+replaces them, a runtime upgrade does not. The driver reloads the helper modules
+that it imports from the selected runtime, and runs the subprocess helpers that
+the runtime lists (such as the fix-task brief lint) from it.
+
 With no declaration, retain the legacy helper lookup. An existing
 `.gsd-path/runtime/` requires the explicit `--runtime-migrate --project PATH`
 operation before adopting external storage; review the resulting Git diff.