@opengsd/gsd-path 1.4.0 → 1.6.0

package/skills/gsd-path/references/planner.md

@@ -38,8 +38,9 @@ the how.
    security-critical; `verify-only` suits polish and low-risk feature waves
    whose Verify commands meaningfully cover the criteria.
 
-Every dependency must be in an earlier wave or in the same wave with no file
-overlap. Produce an acyclic graph; same-wave chains execute in layers.
+Every dependency must be in an earlier wave or in the same wave. Same-wave
+tasks may share files only when one transitively depends on the other. Produce
+an acyclic graph; same-wave chains execute in layers.
 
 Declare a dependency only when something real crosses it: data — the dependent
 consumes a symbol, signature, schema, endpoint, file format, or path named in
@@ -72,8 +73,17 @@ plan order above, which still keeps plan-invalidating risk in wave 1.
   criterion may appear in only one surface block. Put the surface in the same
   wave as the capability behind it. A milestone with a surface is not done
   when only its internals run.
+- When INTENT.md carries `## Edge coverage` or `## Prohibitions` (read the
+  supplied [spec-reach probes](spec-probes.md)), treat every ruling as a hard
+  limit on its criterion. For each `held-out` edge, write one PLAN.md
+  `## Held-out checks` row: a test file in the owning task's `files`, a
+  Verify that runs it, and an Acceptance criterion that names the edge id
+  and states its ruling from Detail. Omit the section when no edge is
+  held-out. Put each `judgment` prohibition's Must not and Detail in the
+  owning task's Approach.
 - Make `files` exhaustive, including imports, routes, generated artifacts,
-  tests, and wiring. Require disjoint files for same-wave tasks.
+  tests, and wiring. Require disjoint files for same-wave tasks that are not
+  dependency-ordered. A declared directory overlaps every path below it.
 - Write an Interface contract in every task: `None` for independent tasks;
   for any tasks that exchange a symbol, signature, schema, endpoint, file
   format, or path, the exact shapes both sides code against — identical text
@@ -86,6 +96,18 @@ plan order above, which still keeps plan-invalidating risk in wave 1.
   this task's work is skipped. That command must name a path from `files`,
   and must not be PLAN.md's project Verify unless an SC this task owns names
   that command. Criteria and Verify are the contract; Approach is guidance.
+  A task that lists a file of an earlier-wave task must also pass that
+  task's Verify to land. When it changes that behavior on purpose, list the
+  tests that Verify runs in its `files`.
+- Add `supersedes: [<task id>]` only when INTENT.md requires this task to
+  remove or replace behavior of an earlier-wave task, and that task's Verify
+  cannot pass after the change. The named task must be in an earlier wave,
+  in the same repo, and share a file with this task. Its Verify is then
+  retired: it does not run at this landing or at a later landing. State the
+  replacement in this task's acceptance criteria. This task's Verify then
+  runs in its place for each later task that shares a file with the named
+  task, so it must check the replacement behavior for all files of that
+  task.
 - In a multi-repo milestone (`.project/MEMBERS.md` lists members), each task
   changes exactly one repo. Give a member task `repo: <member>`; its `files`
   and Verify are relative to that member's root, and its Verify runs there.
@@ -105,7 +127,7 @@ family list. Copy `Finding skeptics:` from INTENT.md into PLAN.md Config as
 invent `on`. Quick-lane plans always write both values as `off`.
 
 Before returning, check veto exclusion, decision coverage, Intent coverage,
-the Surface contract, dependencies, file overlap, task size, criteria, and
+the Surface contract, Held-out checks, dependencies, file overlap, task size, criteria, and
 Verify commands.
 
 Return a brief structured summary: wave count, task count, and the wave-1

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

@@ -1,8 +1,13 @@
 ## Final integration mode
 
 Use only final-review.md. Treat INTENT.md success criteria as the rubric.
-Exercise the running system and record `met`, `not-met`, or `unverifiable`
-with checked command output or a precise file reference. When PLAN.md carries
+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
 by performing that surface's Walkthrough from its Entry in the supplied
 sidecar: `Surface` names that surface, Check names what was performed,
@@ -14,6 +19,19 @@ re-run PLAN.md's project Verify; cite the orchestrator's recorded
 project-verify sidecar output. `pass`
 requires every criterion to be `met`.
 
+When INTENT.md `## Edge coverage` or `## Prohibitions` tags a criterion with a
+`held-out` edge or a `judgment` prohibition, grade that criterion on cited
+evidence for every tag (see the [spec-reach probes](spec-probes.md)). Name
+each id in Check, Observed, or Reference with its evidence: the held-out
+test's recorded passing output from the PLAN.md `## Held-out checks` test, or
+the observed behavior judged against the prohibition's Detail. When a tag's
+evidence is missing, did not run, or cannot be judged, record `unverifiable`
+with `Finding: insufficient spec evidence: <id> <what is missing>` and a Fix
+direction naming the check to add or run. Never mark such a criterion `met`
+on inference or on code that merely looks right; the ship gate refuses a
+`met` verdict that does not cite every tag. Grade untagged criteria as usual:
+the trigger is the INTENT.md tag, never your own doubt.
+
 ## Final gap mode
 
 Use only gap-review.md. Check the one cross-wave risk in the brief against the

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

@@ -17,16 +17,26 @@ 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. Copy the criterion verbatim from
-INTENT.md. 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.
+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
+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
+id with what you observed. A missing held-out result or a violated ruling
+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`,
@@ -40,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
@@ -47,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
 
@@ -65,7 +106,10 @@ criterion's Intent coverage block includes `- **Surface**:`, `- **Check**:`, and
 `- **Observed**:` with the walked states and actual result. `Surface` holds
 exactly the surface name from PLAN's Surface contract; walkthrough detail belongs
 in Check and Observed. Reuse recorded task
-output if it proves that exact walkthrough; run only a missing check. Final-scope
+output if it proves that exact walkthrough; run only a missing check. Cite
+every `held-out` edge and `judgment` prohibition id of each criterion in its
+evidence; shipping derives FINAL.md from these records, and an uncited id
+sends the milestone to a dispatched final review instead. Final-scope
 coverage shares this wave artifact; do not write a second report. Shipping's
 runtime checks freshness and derives the final view from these records.
 

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

@@ -46,7 +46,9 @@ Resolve sibling links against this role file's directory.
   from the same model family is one evidence path; independence comes
   from re-run evidence, different sources, or a different model family.
 - Pass any reasonable satisfied reading of an ambiguous wave criterion and
-  warn that it needs tightening.
+  warn that it needs tightening, unless INTENT.md `## Edge coverage` or
+  `## Prohibitions` rules on that reading: a ruling there binds, and a
+  reading that contradicts it fails.
 - Do not edit code, tasks, plans, or implementation state.
 
 Return verdicts and the review output path without extra prose.

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

@@ -20,6 +20,15 @@ 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.
+
 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.

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

@@ -0,0 +1,150 @@
+# Spec-reach probes
+
+Define runs two probes over the success criteria before approval: the edge
+probe (what each criterion must do at its edges) and the prohibition probe
+(what each criterion must never silently become). Both leave a table in
+INTENT.md. Plan, build review, and final review read those tables; the
+`check_handoffs.py intent`, `plan`, and `final` gates enforce them.
+
+## Why define owns this
+
+A reviewer can only check what the intent states. An edge nobody wrote down
+is never checked: final review covers exactly the INTENT success criteria,
+and a reviewer passes any reasonable reading of an ambiguous one. Model
+reviewers are also confidently wrong on exactly these gaps. On three tasks
+whose correct behavior the spec left unstated, LLM verifier verdicts caught
+the defect 0 times in 12 while a held-out test caught all three; in a larger
+replication, stating the surfaced edge in the spec raised the verifier's
+catch rate to 98% ([Verifier Reach Is Spec Reach](https://github.com/davesienkowski/verifier-reach-is-spec-reach)).
+A smarter reviewer does not close that gap; a wider intent does. The user is
+present at define, so define is where the edge gets its ruling.
+
+## Edge probe
+
+Walk every success criterion:
+
+1. Name the data shapes the criterion handles, then raise only the
+   categories those shapes reach:
+
+   | Shape | Categories |
+   |-------|------------|
+   | numeric range, dates, money, counts | boundary, precision |
+   | list, set, rows, intervals | adjacency, empty, ordering |
+   | text, names, identifiers | empty, encoding |
+   | state that persists or repeats | idempotency, concurrency |
+   | files, network, processes | concurrency |
+
+2. For each raised category, write one concrete candidate edge and the
+   ruling you recommend:
+
+   | Category | Probe question |
+   |----------|----------------|
+   | boundary | What happens exactly at each minimum, maximum, or threshold, and one step either side? |
+   | adjacency | When two items are equal or just touch, do they merge, collide, or stay separate? |
+   | empty | What is the result for empty, single-item, or missing input? |
+   | encoding | Whose length or equality applies: bytes, code points, grapheme clusters, normalized form, case? |
+   | ordering | When items compare equal, is output order specified and stable? |
+   | precision | Where can rounding, overflow, or truncation happen, and which rule applies? |
+   | idempotency | What happens when this runs twice on the same input? |
+   | concurrency | If interrupted or run in parallel, what is guaranteed? |
+
+3. Ask the user in one small round, all criteria together, recommended
+   ruling first. Never rule on an edge's behavior yourself: the correct
+   answer is exactly what the criteria did not say, so a guess here is the
+   defect this probe exists to prevent. Under pre-approval, an edge whose
+   behavior the user has not stated is still a required answer: stop and
+   ask instead of ruling.
+
+4. Record each ruling as one row:
+   - `criterion SCn` when the answer is observable where the user sees the
+     work. Add or amend that success criterion (define owns criteria), then
+     point the row at it. An existing criterion that already states the
+     edge may be named directly.
+   - `held-out` when the answer is a precise rule or a set of examples that
+     belongs in a test rather than a user-facing criterion (a normalization
+     form, a rounding rule, an inclusive bound on an internal API). Write the
+     ruling or the user's examples verbatim in Detail. The plan must schedule
+     a named test that pins it.
+   - `dismissed` when the edge cannot occur for this criterion. Detail says
+     why ("input is a closed enum"). "Not important" is not a reason.
+
+Every criterion gets at least one row. A criterion with no data shape gets
+one row with category `none`, dismissed with its reason.
+
+## Prohibition probe
+
+Walk every success criterion with one adversarial question: what could this
+silently become that the user would not want, although nothing in INTENT.md
+forbids it? Generate candidates privately, then keep only values, safety,
+privacy, fairness, and transparency items: "must not email unsubscribed
+users", "must not store raw card numbers in logs", "must not use guilt
+wording". Drop routine engineering items (mutating input, throwing on empty
+input, leaking handles); those are edges or ordinary review. Do not mint
+generic security or compliance canon (injection, path traversal, data
+retention law); record a real compliance need under Constraints instead.
+Expect two or three kept items for work people touch, and often none for
+internals.
+
+Present the kept items with a recommended ruling and record each as a row:
+
+- `criterion SCn` when a test or command can check it. State it as a
+  success criterion and point the row at it.
+- `judgment` when it is real but not mechanically checkable. Detail says
+  what the final reviewer looks for.
+- `dismissed` when the user rules it out. Detail records the reason.
+
+Work that affects no person directly records a single row instead, and no
+other: `| N1 | all | none | dismissed | <why no person is affected> |`.
+
+## INTENT.md tables
+
+```markdown
+## Edge coverage
+
+| Edge | Criterion | Category | Disposition | Detail |
+|------|-----------|----------|-------------|--------|
+| E1 | SC1 | boundary | criterion SC4 | |
+| E2 | SC1 | empty | dismissed | the command always receives at least one file |
+| E3 | SC2 | encoding | held-out | names compare by NFC code points, case-sensitive |
+
+## Prohibitions
+
+| Prohibition | Criterion | Must not | Disposition | Detail |
+|-------------|-----------|----------|-------------|--------|
+| N1 | SC2 | send a reminder to an unsubscribed user | criterion SC5 | |
+| N2 | SC2 | use guilt or shame wording | judgment | reminder copy is neutral and states only the due item |
+```
+
+Ids are contiguous from `E1` and `N1`. Detail is required for every row that
+is not `criterion SCn`. The headings are exact: `## Edge coverage` and
+`## Prohibitions`. An INTENT.md without them predates the probes and is not
+rechecked; a near-miss heading fails the gate rather than switching it off.
+
+## Downstream
+
+- **Plan.** Every `held-out` edge gets one PLAN.md `## Held-out checks` row
+  naming the task that owns the edge's criterion and the test file (a
+  `path::test_name` node id is fine). That file is listed in the task's
+  `files`, the task's Verify runs it, and the task's Acceptance criteria
+  state the edge id and its ruling. A `criterion SCn` row needs nothing extra: SCn is
+  already covered like any criterion. A `judgment` prohibition belongs in
+  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.
+- **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
+  output, or the observed behavior judged against Detail. When that
+  evidence is missing, did not run, or cannot be judged, record
+  `unverifiable` with `Finding: insufficient spec evidence: <id> ...`;
+  never `met` on inference. The trigger is the tag, not reviewer doubt:
+  criteria without a tag are graded as usual and never abstained.
+
+## What the gates can and cannot prove
+
+`check_handoffs.py intent` (before approval and again when define records
+approval), `plan`, and `final` prove the tables are complete, every held-out
+edge has a scheduled test, and every tagged `met` cites its tags. They cannot
+prove who made a ruling or that a cited result says what the verdict claims.
+Those stay with the define conversation and the reviewer's recorded evidence.