@opengsd/gsd-path 1.6.1 → 1.7.0

package/skills/gsd-path-undo/scripts/worktree_paths.py

@@ -7,11 +7,13 @@ import sys
 # Runtime helpers must not modify their immutable installation.
 sys.dont_write_bytecode = True
 
+import contextlib
 import hashlib
 import json
 import os
 import tempfile
 from pathlib import Path
+from typing import Optional
 
 if __package__:
     from . import _common
@@ -22,7 +24,39 @@ else:
         from scripts import _common
 
 
+# Run-scoped cache for read-only consumers (#469): recovery resolves a
+# placement per task, and each resolution lists the whole worktree registry
+# and re-reads the placement receipt. Within one read-only run none of that
+# can change, so the listing and the derived workspace answer once. Flows
+# that create, move, or retire worktrees never enter this scope.
+_PLACEMENT_CACHE: Optional[dict] = None
+
+
+@contextlib.contextmanager
+def readonly_placement_cache():
+    global _PLACEMENT_CACHE
+    if _PLACEMENT_CACHE is not None:  # already inside a read-only run
+        yield
+        return
+    _PLACEMENT_CACHE = {"porcelain": {}, "workspace": {}}
+    try:
+        yield
+    finally:
+        _PLACEMENT_CACHE = None
+
+
 def _worktree_list_porcelain(primary: Path) -> tuple[str, bool]:
+    if _PLACEMENT_CACHE is not None:
+        key = str(primary)
+        if key in _PLACEMENT_CACHE["porcelain"]:
+            return _PLACEMENT_CACHE["porcelain"][key]  # type: ignore[index]
+        output = _worktree_list_porcelain_uncached(primary)
+        _PLACEMENT_CACHE["porcelain"][key] = output
+        return output
+    return _worktree_list_porcelain_uncached(primary)
+
+
+def _worktree_list_porcelain_uncached(primary: Path) -> tuple[str, bool]:
     try:
         if __package__:
             from . import pipeline_git as pg
@@ -58,6 +92,17 @@ def _identity(path: Path) -> str:
 
 
 def _workspace(primary: Path, pin: bool) -> Path:
+    if _PLACEMENT_CACHE is not None and not pin:
+        key = str(primary)
+        if key in _PLACEMENT_CACHE["workspace"]:
+            return _PLACEMENT_CACHE["workspace"][key]  # type: ignore[index]
+        workspace = _workspace_uncached(primary, False)
+        _PLACEMENT_CACHE["workspace"][key] = workspace
+        return workspace
+    return _workspace_uncached(primary, pin)
+
+
+def _workspace_uncached(primary: Path, pin: bool) -> Path:
     common = Path(_git(primary, "rev-parse", "--git-common-dir"))
     common = (primary / common).resolve()
     identity = _identity(primary)

package/skills/path/BUILD.md

@@ -130,7 +130,11 @@ STATE.md-only "finalize" checkpoint for work already checkpointed. The helper
 refuses a `build:` checkpoint that deletes or renames a `.project/tasks/`
 brief unless the canonical `build: abandon milestone <slug>` checkpoint moves
 that same brief into `.project/archive/`; build adds fix tasks and repairs
-briefs, it never replans.
+briefs, it never replans. It also refuses a `build:` checkpoint while the
+committed STATE is `ship/active`: final-review outputs stay uncommitted until
+the ship commit. The one exception is the patch re-entry checkpoint: the
+worktree STATE is `build/active` and its Log ends with `patch plan reopened`,
+`patch plan approved`, `build started`.
 
 ## Execute from runtime receipts
 

package/skills/path/DEFINE.md

@@ -273,7 +273,8 @@ question. The rules change for every primary mode:
    for kept prohibitions, each with a recommended ruling first. A ruling
    observable where the user sees the work becomes or amends a success
    criterion; write every ruling into `## Edge coverage` and
-   `## Prohibitions`. Program mode skips this step (each milestone runs it
+   `## Prohibitions`. Bound every absence criterion in the edge round
+   (search space, check, absent result). Program mode skips this step (each milestone runs it
    in milestone mode); milestone mode runs it inside its confirmation.
 7. Classify the proposed milestone lane before writing the approval draft.
    Milestone mode keeps `Lane: milestone` and skips this classification.

package/skills/path/PLAN.md

@@ -114,6 +114,11 @@ as stated in Lookahead mode.
      `worktree: null`, and `task_branch: null` values on every new task.
      In patch mode, tasks already `done` keep their landed metadata; only
      the appended patch tasks must start clean.
+   - A `status: withdrawn` task is an owner-ruled tombstone: its file and id
+     stay in place, it is never dispatched, and its Log must carry a
+     `Withdrawn — <date>: <owner ruling verbatim>` entry. Reject an uncited
+     tombstone, a dependent that is not `done` or withdrawn, and an SC it
+     still owns; re-own or remove that SC through a Define INTENT Correction.
    - Require every dependency id to exist, forbid later-wave dependencies,
      detect cycles, and forbid unordered file overlap between planned tasks
      in the same wave. Same-wave tasks may share files only when one
@@ -266,6 +271,11 @@ as stated in Lookahead mode.
    A landed brief is immutable history: the helper checks its `files` scope
    at the recorded historical base and does not check the paths that its
    prose and Verify name.
+   Approval also refuses unsupported `.project/` entries (anything outside
+   the fixed set of state files and milestone directories): remove or
+   relocate them first — a staged `git rm` already satisfies the gate and
+   the approval checkpoint commits the removal. Task `files` may not
+   declare anything under `.project/`.
    This applies to plan re-approval too; the dispatch CLI remains HEAD-only
    with no overrides.
 

package/skills/path/SHIP.md

@@ -69,7 +69,8 @@ so the position is unchanged. Then:
    task logs prove it is the immediately preceding `ship/blocked` finding
    set, the approved patch tasks copied every finding verbatim, and those tasks
    are now done; otherwise it blocks. Git history preserves the superseded
-   finding, while final review itself still creates no pre-ship commit.
+   finding, while final review itself still creates no pre-ship commit
+   (`isolation.py checkpoint` refuses a `build:` checkpoint at `ship/active`).
 2. Derive a stable numbered list of cross-wave integration risks from
    interfaces and flows that span waves. List only genuine risks that could
    plausibly fail; never pad the list. Include PLAN.md's project Verify as
@@ -89,7 +90,14 @@ so the position is unchanged. Then:
    head and holds the exact output; there is no reusable ledger entry.
    Single-repo re-entry at the same command and commit reuses the execution,
    including a failed one, and finishes interrupted collection without running
-   the command again.
+   the command again. The one exception is an owner-diagnosed host failure (for
+   example a host toolchain version the project does not pin): re-run
+   `workflow_run.py prepare-final` with `--rerun` to retire the recorded
+   execution, run the command again, and append a second ledger entry marked
+   `rerun` — the failed entry stays as history. Product failures never take
+   `--rerun`; they go through the patch plan. The sidecar inherits the
+   orchestrator environment, PATH included, by design: the Verify must run the
+   project's own toolchain, so a host/PATH mismatch is a host failure.
    Missing legacy output requires evidence reconciliation, not a blind rerun.
    Any non-zero result stops this step; preserve its stderr and diagnose through
    the bundled forensics contract. Do not launch reviewers while project Verify
@@ -145,7 +153,8 @@ so the position is unchanged. Then:
    verdict `met` with a non-`none` Check or Reference, and every criterion
    listed in PLAN.md's Surface contract requires a matching `Surface` field
    and a non-`none` Check. A non-zero exit is
-   `ship/blocked`; never rerun project Verify to repair the evidence.
+   `ship/blocked`; never rerun project Verify to repair the evidence (a
+   host-caused command failure uses the `prepare-final --rerun` route above).
 6. Redispatch one complete corrected brief for a missing or invalid reviewer
    artifact under the same logical task name, following the runtime dispatch
    contract. Before dispatch, record the invalid destination's exact SHA-256.
@@ -274,7 +283,16 @@ The persisted `STATE.archive` field is the transaction identity.
    `awaiting-merge`, report the member PR
    link, stop, and rerun the same command after the user merges it; never
    merge a member PR yourself. When it returns `integrated`, keep its `body`
-   for the ship commit below.
+   for the ship commit below. When it refuses with
+   `member reviewed HEAD reached <default> outside Path`, the member's work
+   was already published past its reviewed HEAD by an earlier user-approved
+   step: present the member, its reviewed HEAD, and the live default-branch
+   tip, and ask the user whether to adopt that landing. Only on an explicit
+   user approval rerun the same command with
+   `--adopt-landed-member <member>=<live tip SHA>`; the helper then publishes
+   the bound branch and an `adopted-landing` milestone tag at that tip and
+   makes no merge. A mismatched or stale SHA is refused, and a later rerun
+   validates the adoption without the flag.
 5. Only after preflight passes, record shipment through the journaled helper;
    for a program it atomically replaces both ROADMAP.md and STATE.md, setting
    the current entry to `Status: shipped` with the exact `Archive:` pointer:
@@ -329,7 +347,13 @@ The persisted `STATE.archive` field is the transaction identity.
      `build/rebase-adoption.json`) may advance the ref from the adopted head
      to its immediate, canonical `.project/`-only ship child under an exact-SHA
      lease after the helper proves the clean ship state, receipt, and archived
-     tasks. Every other value blocks. If origin/main advances
+     tasks, and a strict ancestor of the ship commit — a build task may have
+     legitimately pushed the bound branch as a deploy pin (#464) — is adopted
+     only after the user approves, by rerunning with
+     `integrate --adopt-published-bound <live 40-hex SHA>`; the helper requires
+     the SHA to equal the live tip exactly and fast-forwards under the same
+     exact lease, and direct integration only. Every other value blocks. If
+     origin/main advances
      after the local merge but rejects the push, a retry may discard and
      rebuild only the unpublished canonical merge and tag under the helper's
      existing recovery checks.
@@ -416,10 +440,15 @@ Run this recovery setup from a separate checkout, outside the closed primary
 worktree's guard.
 
 1. Create separate disposable trust and validation checkouts from the same
-   published origin and `STATE.branch`. This separation is required because an
-   explicit runtime upgrade changes the trust checkout's declaration and launcher,
-   while archive validation requires a clean checkout. Never use the primary
-   worktree for either role.
+   published origin and its default branch (checking out `STATE.branch` when
+   it still exists; a rebase-merged pull request may have deleted it). This
+   separation is required because an explicit runtime upgrade changes the
+   trust checkout's declaration and launcher, while archive validation
+   requires a clean checkout. Never use the primary worktree for either role.
+   A rebase-merged milestone additionally needs the original ship commits to
+   resolve — use a checkout that fetched and retained them (the primary
+   always does; a clone that never fetched the bound branch does not), and a
+   checkout whose originals were collected cannot carry a full validation.
 2. From the trusted fixed GSD Path checkout, preview and then explicitly upgrade only the
    disposable trust checkout's managed trust anchor:
 
@@ -447,6 +476,11 @@ worktree's guard.
    python3 -B <verified-runtime>/archive_milestone.py validate-integrated --repo <validation-root> --slug <STATE.milestone>
    ```
 
+   When the validation checkout is on the default branch after the milestone
+   closed (the bound branch is gone), pass `--historical`; a rebase-merged
+   landing is then accepted only through the milestone tag's Ship/Landing
+   pair plus a re-proven rebase replay.
+
 4. A pass restores the normal shipped handoff without another commit or
    publication action. Remove only the disposable checkouts. A failure is a
    new validation finding: report it with the primary worktree's archived

package/skills/path/SKILL.md

@@ -227,7 +227,9 @@ A coordinator project can change other repositories (members) in the same
 milestone; `.project/MEMBERS.md` lists them. Change members only at a
 milestone boundary, never during build or ship. Resolve the bundled
 `scripts/members.py` to an absolute path and use it; never edit MEMBERS.md
-or a member marker by hand.
+or a member marker by hand (the one exception is adding the optional
+`Prepare:` row below through a reviewed change — `members.py` has no
+subcommand for it yet).
 
 - To add an existing repository, it needs a GitHub.com `origin`, a clean
   worktree, and no active milestone of its own. Its default branch can have
@@ -240,6 +242,19 @@ or a member marker by hand.
   When `validate` or member close later reports
   `remote default must be <recorded>`, stop and report it; never edit the
   record.
+- A member whose isolates need more than tracked files — uninitialized
+  submodules, gitignored build inputs — declares a `Prepare:` command in its
+  MEMBERS.md row (added by editing the committed file through a reviewed
+  change; `members.py` validates it like any field). The runtime runs it
+  inside every fresh member isolate, task or verify, before any Verify: it
+  must provision by copying from the member's primary checkout, never by
+  linking (retirement defuses links, and a link would let the isolate mutate
+  shared inputs). For submodules, the offline recipe is
+  `git config submodule.<name>.url <primary>/.git/modules/<name> && git -c protocol.file.allow=always submodule update --init <name>`
+  — it reads the primary's object store and touches no network. A failed
+  Prepare fails the isolation loudly with its output before a Verify runs.
+  Retained isolates keep their provisioning: a re-authorized rerun does not
+  Prepare again.
 - To create a new member repository, present the exact `owner/name`,
   visibility, and checkout path as the **Review** surface and get approval
   first, as for a new GitHub repository. Then run the same command with

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

@@ -207,7 +207,16 @@ dispatch contract and perform steps 1–5 by hand.
    its exact base prove the remaining branch before deletion. Create the retry
    from the new clean primary HEAD. A member task (`repo: <member>`) stays
    `pending` in the coordinator; its rejected attempt lives in the member
-   sidecar. Copy the live copy's Log delta into the coordinator task file,
+   sidecar. When the failure was environmental — the isolate could not build
+   a Verify for reasons outside the product, and the coder fixed the
+   environment inside the retained sidecar — do not re-isolate: rerun
+   `python3 <absolute isolation.py> activate-member-task --repo <absolute
+   primary> --member <member> --task-id <id> --reauthorize` after checking
+   that the live copy's Log stayed append-only and the member base is
+   unchanged; it re-arms the authorization the failed finish cleared, and the
+   next `finish` runs the full Verify set once and lands (#461). A
+   product-failure rejection instead follows the full retry: copy the live
+   copy's Log delta into the coordinator task file,
    checkpoint it, then retire the sidecar with `python3 <absolute isolation.py>
    retire-member-task --repo <absolute primary> --member <member> --task-id
    <id> --task-file <task path> --force`. It refuses until the committed task
@@ -231,7 +240,11 @@ dispatch contract and perform steps 1–5 by hand.
    `python3 <absolute check_handoffs.py> plan --repo <absolute repo root>`
    before creating any worktree; a lint or coverage failure is a documented plan
    defect — repair it against INTENT.md and SYNTHESIS.md, then re-establish
-   the base. Then isolate each ready task with
+   the base. The brief lint is read-only and idempotent; it reports progress
+   on stderr (one line every 20 tasks) and its stdout is exactly the result
+   JSON. A host timeout that cut it off with no failure output is not a
+   contract verdict — rerun it with a larger timeout and judge only the
+   completed run. Then isolate each ready task with
    `python3 <absolute workflow_run.py> prepare-task --repo <absolute primary>
    --expected-head <recorded base> --task-id <id> --round-size <N>` where N is the
    number of tasks in this dispatch round. For a coordinator task, serial
@@ -619,7 +632,11 @@ dispatch contract and perform steps 1–5 by hand.
    Log waiver — or, in program flow (ROADMAP.md exists), to abandon the
    milestone under the Milestone abandon procedure — listing the
    orchestrator's recommended option first marked `(recommended)` with a
-   one-line reason drawn from the review evidence. Never choose silently.
+   one-line reason drawn from the review evidence. When the cap cycle is
+   later than 1 and a blocking group in its `groups` has `first_seen_cycle`
+   1, recommend sending it
+   to define: fix cycles since cycle 1 have not closed that criterion, so it
+   is likely unbounded. Never choose silently.
    When the canonical verdict is `pass` and `wave-N.cycleC.panel.md` reports
    `Actionable` greater than 0, do not advance silently: present **Outcome**
    with the canonical pass plus the actionable count, **Review** linking the

package/skills/path/references/coder.md

@@ -35,7 +35,10 @@ reality:
   item in INTENT.md `## Success criteria`.
 - Confirm your Interface contract text appears verbatim in every sibling
   task file it exchanges with. Sibling task files under `.project/tasks/`
-  are readable in your worktree — read-only; never edit them.
+  are readable in your worktree — read-only; never edit them. On a member
+  task the orchestrator pins them under
+  `.gsd-path-coordinator/.project/tasks/` beside your live task copy —
+  read them there.
 - Confirm every path the Verify command references exists or is declared.
 
 Route any mismatch before writing a line of product code: a clear defect — a
@@ -86,8 +89,8 @@ them.
 
 - You are not alone in the repository. Other agents may use sibling worktrees;
   do not inspect, revert, or overwrite their changes.
-- Never edit `base`, `worktree`, `task_branch`, `status`, or `agent`.
-  The orchestrator owns them.
+- Never edit `base`, `worktree`, `task_branch`, `status`, `agent`, or
+  `member_base` (member tasks). The orchestrator owns them.
 - Never stage, commit, amend, rebase, reset, or otherwise mutate Git.
 - Never add an unnamed dependency, weaken verification, or improve adjacent
   code.

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

@@ -1,6 +1,16 @@
 ## Final integration mode
 
 Use only final-review.md. Treat INTENT.md success criteria as the rubric.
+To locate each task's authoritative accepted evidence instead of joining
+task Logs, ledger rows, and gap artifacts by hand, run
+`python3 <absolute build_state.py> evidence-manifest --repo
+<absolute primary> --project-dir .project --head <reviewed HEAD>`:
+it classifies every task as `ledger`, `log-only`, `rejected`,
+`superseded`, or `missing` and names the receipt, and reports the member
+project Verify as `gap-embedded` only from a passing `final-gap-1.md` at
+the reviewed HEAD — a
+`log-only` task is accepted through its retained isolated-Verify Log, and
+an absent ledger row is explained, never treated as data loss.
 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

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

@@ -8,19 +8,45 @@ tasks in this wave as the rubric. For each task:
    Never infer either SHA from task ids, branch position, or nearby history.
 2. Fail a missing, malformed, or invalid SHA. Inspect the commit with
    `git show --format=fuller --stat --patch <commit> --`.
-3. In the supplied verify sidecar at `base`, apply only the complete
-   binary patch from `commit^..commit` for the task's declared product files
-   and inspect the diff. Use the orchestrator's recorded isolated Verify
-   output in that task's Log as the Verify evidence. Do not re-run the
-   task Verify command or PLAN.md's project Verify. Re-run a command only
-   when the recorded output plus the isolated diff cannot check the
-   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 (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
+3. Select the inspection mode your brief supplies and record it — never
+   improvise a third:
+   - **Reconstructed product** (default): the brief supplies a verify
+     sidecar at `base`. In it, apply only the complete binary patch from
+     `commit^..commit` for the task's declared product files and inspect
+     the diff. Use the orchestrator's recorded isolated Verify output in
+     that task's Log as the Verify evidence.
+   - **Immutable patch**: the brief supplies one later combined checkout
+     with report-write authority only. Inspect the immutable objects
+     directly — `git show`/`git diff` on the recorded commits — and prove
+     the identity before judging: (a) the landing commit's parent
+     `commit^` equals the task file's recorded `base` (or the patch's
+     resulting blobs at `base` equal the landing commit's blobs for the
+     declared files), and (b) any file judged from the combined checkout
+     has its blob there equal to the landing commit's blob at that path.
+     Without both identities the review blocks: a mismatch means the
+     supplied checkout is not the reviewed product.
+   In both modes: do not re-run the task Verify command or PLAN.md's
+   project Verify; re-run a command only when the recorded output plus
+   the diff cannot check the 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 (` — `), name the
+   criterion (see Review file format below): copy the complete task
+   acceptance or interface criterion verbatim, or — on a `pass` line only —
+   cite the criterion by its stable id in the task's numbered acceptance or
+   interface list (`T012/AC3`, `T012/IF2`) together with the evidence. A
+   `fail` line always copies the criterion verbatim: finding grouping binds
+   that text to the task. Give the observed result, `file:line`, and
    concrete fix direction for each failure.
+5. Account for every claim. Each acceptance criterion (`T012/AC3`) and
+   interface bullet (`T012/IF2`) of the task must appear in its
+   section as an evidence reference, a finding, or an explicitly
+   authorized disposition — a bare line naming the id with
+   `disposition: <authority and date> (<Cn>): <reason>`, where `Cn` is a
+   numbered INTENT.md correction. No citation, or a `Cn` that
+   `## Corrections` does not define, fails the gate. One observation may
+   support several claims when each is identified by its id. The wave gate
+   rejects a review that leaves a claim unaccounted for.
 
 A Log entry `orchestrator regression Verify of <task id> retired: superseded
 by <task id>` is not evidence: judge the superseding task's acceptance
@@ -30,8 +56,12 @@ criteria. The same applies to the entry `orchestrator regression Verify of
 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
 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
+file format below). Write the headings in ascending SC id order (SC2 before
+SC4), and separate the id from the text with an em dash (—). Mark `pass`
+or `fail` with evidence; a failed owned SC blocks the wave. Under a `pass`
+SC, record each subclaim a numbered INTENT.md correction excludes as
+`- Excluded by <Cn>: <subclaim>`; the gate rejects an exclusion under a
+failing SC or one that cites an undefined correction. 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
@@ -40,8 +70,12 @@ fails the SC.
 
 Allow changed paths only in the task's `files` plus its assigned task file.
 Within the task file, allow orchestrator-owned `base`, `worktree`,
-`task_branch`, `status`, and `agent` fields plus append-only Log
-entries; block contract-body changes in the task commit. Warn on disabled tests
+`task_branch`, `status`, and `agent` fields — and, on a member task,
+`member_base` — plus append-only Log entries; block contract-body changes
+in the task commit. `base` names the task's starting commit in the
+coordinator repository; `member_base` names the starting commit in the
+member repository from which the member task branch and isolate were
+created. Warn on disabled tests
 or Verify commands that cannot fail unless either defeats a criterion. Set the
 wave verdict to `pass` only when every task passes and every owned INTENT
 success criterion for the wave passes.
@@ -65,10 +99,14 @@ criterion text does not match. Apply the rules before you write the file.
   `- ❌ ` 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.
+- **Criterion text.** In a `### SCn —` heading and on every `- ❌ ` fail
+  line, 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. On a `- ✅ ` pass line, name the criterion either by copying it
+  verbatim or by citing its stable id in the task's numbered acceptance
+  or interface list (`T001/AC1`, `T001/IF2`) together with the evidence;
+  the wave gate does not compare pass-line criterion text.
 - **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
@@ -116,8 +154,9 @@ runtime checks freshness and derives the final view from these records.
 ## Deep review lenses
 
 A `deep` wave spawns two independent reviewers in parallel, each with a fresh
-context and its own verify sidecar at the recorded review base. Every
-Wave mode rule above applies to both lenses.
+context and its own isolated workspace at the recorded review base (a verify
+sidecar in reconstructed mode, or the supplied combined checkout in immutable
+mode). Every Wave mode rule above applies to both lenses.
 
 - **Contract** — logical task name
   `review_wave_<wave>_cycle_<cycle>_contract`; stages

package/skills/path/references/reviewer.md

@@ -5,16 +5,18 @@ Verify written GSD Path expectations and block failures. Never fix code.
 ## Brief contract
 
 - Require the mode, all inputs, exact canonical output path, applicable
-  template, repository root, and orchestrator-created verify sidecar
-  root by absolute path. Wave mode also requires the absolute INTENT.md
-  path. The brief must also name the staged output path under
-  that sidecar.
+  template, and repository root by absolute path. Wave mode also requires
+  the absolute INTENT.md path and names the inspection mode: a verify
+  sidecar root for reconstructed-product review, or one combined checkout
+  with report-write authority for immutable-patch review. The brief must
+  also name the staged output path under that workspace.
 - Read AGENTS.md and the template before reviewing.
-- Write only the exact assigned review output under the supplied verify sidecar
+- Write only the exact assigned review output under the supplied workspace
   at its staged `.project/review/` path. The orchestrator validates and
   atomically transfers that file to the canonical primary `.project/review/`
   path after collection. Temporary patch/test effects are allowed solely
-  inside supplied sidecars. Never edit a product path or any other
+  inside supplied sidecars; an immutable-mode combined checkout carries
+  report-write authority only. Never edit a product path or any other
   primary-worktree path. Stop on a missing input or template.
 
 ## Load the assigned mode

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

@@ -20,6 +20,42 @@ 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.
 
+When the runtime enforcing an active task cannot finish it, one narrowly
+authorized recovery exists:
+`python3 -B <absolute isolation.py> runtime-hotfix --repo <absolute primary>
+--task-id <id> --runtime <64-hex runtime digest printed by runtime_store.py publish>
+--authorized-by <the owner ruling>` validates the replacement runtime,
+re-runs that task's Verify in a fresh sidecar at the recorded base under the
+replacement pin, and records the receipt twice: a Log line in the task file
+naming the task, base, and both runtime digests, and an identical blob behind
+the local ref `refs/gsd-path/runtime-hotfix/<task>-<base>`. Only a Log line
+whose exact twin that ref holds later admits `.gsd-path/runtime.json` into that
+task's landing, and only when the pin names exactly the receipt's runtime; any
+other task, base, a Log line alone, or a bare mention authorizes nothing, and a
+failing re-run refuses the hotfix. Limits: the command serves only a serial
+task working in the primary and refuses parallel or member tasks; the ref is
+local repository state, so a clone without it cannot land the pin and the
+proof fails closed. The guard applies two rules to agent shell commands. It
+denies any command where `runtime-hotfix` directly follows `isolation.py`, stdin
+`-`, or an `isolation` module operand (`-m isolation`, `-Bm isolation`,
+`-misolation`). It also denies every Git command with a word, including global
+`-c` options and inline variable assignments, that contains `refs/gsd-path/` or
+`runtime-hotfix`. This deliberately blocks read-only uses such as
+`git log refs/gsd-path/<ref>` or `git log --grep runtime-hotfix`, and commit
+messages or branch names that contain `runtime-hotfix`. Limits: it cannot see a copied or renamed
+`isolation.py`, a refspec stored in a Git config file, a ref write made from
+inside another program, a direct edit of files under `.git/`, or shell
+expansion that splits both protected words, such as
+`refs/gs{d,}-path/task-authorizations/<task>`.
+
+Publishing a runtime to the shared store is project-free:
+`python3 -B <absolute runtime_store.py> publish --source <absolute package root>`
+verifies and publishes the content-addressed runtime, printing its version,
+digest, and store path as JSON; `--provenance` records a note in that output
+only. Publication alone neither authorizes execution nor changes a project's
+trusted runtime — a project runs the bytes only when its own pin names that
+digest.
+
 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

package/skills/path/references/spec-probes.md

@@ -96,6 +96,23 @@ Present the kept items with a recommended ruling and record each as a row:
 Work that affects no person directly records a single row instead, and no
 other: `| N1 | all | none | dismissed | <why no person is affected> |`.
 
+## Absence criteria
+
+A criterion that claims absence ("X does not exist", "no X anywhere",
+"never Y"), including one written from a prohibition, has no end until it
+says where to look. Each review can look somewhere new, so the build loops
+to the cycle cap. Every absence criterion states:
+
+- the search space: the files, surfaces, or artifacts to check;
+- the check: the command or observation that covers that space;
+- the absent result: the output that counts as absent.
+
+When one is missing, propose a bounded form in the same question round as
+the edges, recommended form first, and amend the criterion after the user
+rules. Do not choose the search space yourself: a narrower space is a scope
+ruling. Under pre-approval, an unbounded absence criterion is a required
+answer: stop and ask.
+
 ## INTENT.md tables
 
 ```markdown
@@ -131,7 +148,8 @@ rechecked; a near-miss heading fails the gate rather than switching it off.
   the owning task's Approach so the coder knows the line.
 - **Review.** A row pins the reading of its criterion. A reviewer does not
   pass a reading that contradicts a ruling in either table, and cites each
-  held-out edge and judgment prohibition id with its evidence.
+  held-out edge and judgment prohibition id with its evidence. An absence
+  criterion is judged over its stated search space only.
 - **Final review.** A criterion that carries a held-out edge or a judgment
   prohibition is `met` only when its Check, Observed, or Reference cites
   every such id with the evidence: the held-out test's recorded passing