cyber-sdd 0.6.0 → 0.7.0

package/skills/spec-gate/scripts/classify-edit-class.mjs

@@ -0,0 +1,12 @@
+// Launcher for the engine of the same name. Run it as `node <skill>/scripts/<engine>.mjs`.
+// A checkout runs the .mts source. An npm install keeps the skill under node_modules, where Node
+// will not strip types, so it runs the self-contained bundle built for the package.
+import { spawnSync } from 'node:child_process'
+import { fileURLToPath } from 'node:url'
+
+const self = fileURLToPath(import.meta.url)
+const installed = /[\\/]node_modules[\\/]/.test(self)
+const target = self.replace(/\.mjs$/, installed ? '.bundle.mjs' : '.mts')
+const run = spawnSync(process.execPath, [...process.execArgv, target, ...process.argv.slice(2)], { stdio: 'inherit' })
+if (run.error) throw run.error
+process.exitCode = run.status ?? 1

package/skills/spec-producer-governance/README.md

@@ -2,6 +2,6 @@
 
 Non-user-invocable SDD skill holding the **default spec-producer procedure**: how to author the `spec.md` body and a boolean Gherkin `.feature` for a domain no plugin covers.
 
-Loaded via the harness (`Skill`) by the **conductor** (the main session) when it runs the spec-producer role from the SDD default — the conductor authors **inline** in its own warm context (recorded `produced-by.spec-producer: sdd:automaton`) rather than spawning a producer agent. The grader stays separate: a cold `sdd-spec-judge` reviews the output.
+Loaded via the harness (`Skill`) by the **conductor** (the main session) when it runs the spec-producer role from the SDD default — the conductor authors **inline** in its own warm context (recorded `produced-by.spec-producer: sdd:sdd-automaton`) rather than spawning a producer agent. The grader stays separate: a cold `sdd-spec-judge` reviews the output.
 
 References `sdd:spec-format-governance` (the universal format bar — including the required `## Use Cases` section, its actor-first enumeration, and the rule that scenarios derive from the CFG rather than from the stated use-case prose) plus the resolved oracle + builder + architect actor bars (the spec-gate lens set, forward face) as its self-alignment criteria, and `sdd:ownership-governance` for the write-ownership matrix. Bakes in the grilling discipline (breadth-first, depth one-at-a-time, prose before suite) and the reconcile-toward-the-correct-answer rule for contradictions surfaced during grilling.

package/skills/spec-producer-governance/SKILL.md

@@ -6,7 +6,7 @@ user-invocable: false
 
 # Spec-Producer Governance — the default authoring procedure
 
-The procedure the **conductor** follows when it runs the **spec-producer** role from the SDD default — i.e. no plugin covers the domain and no model-tuned producer agent is named for the slot, so the conductor **loads this governance and authors inline** in its own warm context (recorded `produced-by.spec-producer: sdd:automaton`). The grader is separate — a **cold spec-judge** (`sdd:sdd-spec-judge` or the plugin's judge) always reviews the output; this governance never judges its own work.
+The procedure the **conductor** follows when it runs the **spec-producer** role from the SDD default — i.e. no plugin covers the domain and no model-tuned producer agent is named for the slot, so the conductor **loads this governance and authors inline** in its own warm context (recorded `produced-by.spec-producer: sdd:sdd-automaton`). The grader is separate — a **cold spec-judge** (`sdd:sdd-spec-judge` or the plugin's judge) always reviews the output; this governance never judges its own work.
 
 Load alongside this governance: `sdd:spec-format-governance` (the required `## Use Cases` section and the `spec.md` enrichment / human-readability rule), `sdd:suite-format-governance` (the `.feature` format bar and scenario-ordering convention), and the resolved **oracle**, **builder**, and **architect** actor bars — **forward** face — to self-align before writing (scope and kill-or-ship, testability/coverage, structural fit). These are exactly the bars the spec-judge grades **backward** at the spec gate, so the producer self-aligns to the same lens set it will be graded against. Load `sdd:ownership-governance` for the write-ownership matrix — which fields the spec-producer may write and which belong to the conductor or the gate skill.
 
@@ -43,7 +43,7 @@ USER_ANSWERS:     <answers to previously returned QUESTIONS — or null>
 5. **Self-check the `.feature` form before returning.** Run the deterministic form check — the `check-suite` engine (`scripts/check-suite.mts` in the `spec-gate` skill), the executable form of `sdd:suite-format-governance` — scoped to what you just authored:
 
    ```bash
-   node "<spec-gate skill>/scripts/check-suite.mts" --files <the authored .feature path(s)>
+   node "<spec-gate skill>/scripts/check-suite.mjs" --files <the authored .feature path(s)>
    ```
 
    Exit `0` = form clean; exit `1` prints each `✗ <file>: <reason>`. **Fix every violation** (a non-boolean/hedged `Then`, leaked rubric lingo in an untagged scenario, a missing `Feature`/`Then`, or missing section comments over the sectioning threshold) and re-run until clean **before reporting `STATUS: complete`**. Settling this mechanical bar here spends no cold-judge round on a defect a linter catches every time; the same engine runs fail-closed at the gate (`../spec-gate/`), so an unfixed violation would block there anyway. If `node` is unavailable, self-review against the suite-format bar by hand.
@@ -62,7 +62,7 @@ USER_ANSWERS:     <answers to previously returned QUESTIONS — or null>
    the `spec.md`/`README.md` you just authored or touched:
 
    ```bash
-   node "<spec-gate skill>/scripts/check-spec-state.mts" --files <the authored spec.md/README.md path(s)>
+   node "<spec-gate skill>/scripts/check-spec-state.mjs" --files <the authored spec.md/README.md path(s)>
    ```
 
    Exit `0` = every referenced path resolves; exit `1` prints each `✗ <file>: references nonexistent

package/skills/spec-structure-governance/README.md

@@ -21,8 +21,10 @@ Read `SKILL.md` beside this file for the law itself — that is what those four
 - **The node taxonomy** — descriptive, reference artifact, behavioral artifact; declared in
   frontmatter, never guessed from which files happen to exist.
 - **Placement** — screaming architecture (folders named for capabilities), the three deliberate
-  non-capability folders, rules-in-design vs behavior-in-capability, the two-level depth cap, and
-  the concept axis for anything that cuts across.
+  non-capability folders, rules-in-design vs behavior-in-capability, the two-level depth cap on
+  capability nodes, the concept axis for anything that cuts across, and the shape of `design/` —
+  the current design at the top and, while one is under construction, the next design in a version
+  folder beside it.
 - **One spec per project** — and when a spec is hoisted out of its project directory rather than
   colocated in it.
 - **Strategy is policy, homes are data** — the layout strategy is a choice, so it is declared once

package/skills/spec-structure-governance/SKILL.md

@@ -41,7 +41,7 @@ folder names say what the project does. Three folders are deliberately *not* cap
 
 | Folder | Holds |
 |---|---|
-| `design/` | the **rules** — the model and the *why* (descriptive docs) |
+| `design/` | the **rules** — the model and the *why* (descriptive docs), in its own shape (below) |
 | `workflows/` | the **usage** — how capabilities compose into whole flows (the project-level suite) |
 | `ledger/` | the **provenance** — durable audit records; data, outside the node taxonomy |
 
@@ -55,9 +55,38 @@ mandated set stays minimal: anything that is one document lives as a **root file
 `glossary.md` — the project's ubiquitous language, every load-bearing term defined once — is
 required of every project spec.
 
-**Two levels, never three.** A node is `<capability>/<unit>` and never sits three deep. A
-sub-grouping inside a capability is a **cross-cutting concern**, so it is expressed as a `concept:`
-tag and recovered through the generated by-concept index — never as a third folder level.
+**Two levels, never three — for capability nodes.** A capability node is `<capability>/<unit>` and
+never sits three deep. A sub-grouping inside a capability is a **cross-cutting concern**, so it is
+expressed as a `concept:` tag and recovered through the generated by-concept index — never as a
+third folder level. The rule covers capability nodes only: its reason does not reach a design
+version, which is a whole alternate snapshot of the model that no `concept:` tag can express.
+
+**The `design/` shape — current at the top, the next design beside it.** `design/` is the single
+description of the system; ADRs are the frozen record of why it changed. A design stays trustworthy
+only if it is updated as a whole, so:
+
+- **Current at the top level, one file per perspective** — the angles a reader takes on the whole
+  system, one file each, **never a perspective folder**. The ADR log `design/decisions/` is the one
+  standing sub-folder.
+- **A version folder holds the next design while one exists.** The project names it (`design/next/`
+  is a suggestion; `design/v2/` works as well). It holds a **full copy** of the perspective files,
+  never a diff, so each version reads on its own and `diff -r` shows the whole change. It holds no
+  `decisions/`. At most one exists at a time.
+- **The cut is one commit**: the version folder's contents replace the top-level perspective files,
+  and the folder and its placement-map record go. Git keeps the previous version; `design/` never
+  carries a `previous/`.
+- **The cut trigger is recorded and checkable.** While a version folder exists, the root `spec.md`
+  placement map names it and what cuts it over — a capability set reaching `implemented`, or a named
+  release. Without a checkable trigger the next design drifts into an unofficial current. Making it
+  checkable is the author's duty; the formation Warden checks that one is recorded. A
+  sub-folder of `design/` the map does not name, other than `decisions/`, is a perspective folder.
+
+Current stays at the top rather than in `design/current/` so that links to a design doc survive
+every cut: most of a project's life has no next design, and links accumulate from ADRs, capability
+specs, and the docs site.
+
+**Rejected — a fourth exempt top-level folder** (`design-next/`). It grows the mandated set this
+governance keeps minimal, and it would sit among the capability folders as if it were one.
 
 **The concept axis.** The tree can privilege only one axis, and it privileges capability; a concern
 enacted across several capabilities is declared in `concept:` frontmatter and navigated through the
@@ -107,6 +136,8 @@ decisions the strategy alone does not settle, so a node placed by an explicit ro
 the strategy alone therefore reports false findings against exactly the placements a human already
 adjudicated. The test is a disjunction: a node is misplaced only when it **neither** follows the
 declared strategy **nor** matches a routing-table row.
+While a next design exists, the map also names the **design version** folder and its cut trigger
+(the `design/` shape above); a judgment of `design/` reads that entry.
 
 This is the same split the corpus-discovery rule already makes — fixed conventions are scanned,
 while an off-convention anchor list is declared and curated. "No drift" means *do not store what you
@@ -162,8 +193,12 @@ entry condition.
    folder, reference artifacts to the capability that owns them.
 3. **Screaming architecture** with three non-capability folders (`design/`, `workflows/`, `ledger/`)
    and **root files, not folders**, for single documents (`glossary.md` required).
-4. **Two levels, never three** — deeper sub-grouping is a `concept:` tag, not a folder.
-5. **One spec per project**; colocate by default and **hoist only when the spec cannot be kept out of
+4. **Two levels, never three, for capability nodes** — deeper sub-grouping is a `concept:` tag,
+   not a folder.
+5. **`design/` has its own shape** — current at the top, one file per perspective (never a
+   perspective folder), at most one project-named version folder holding a full copy of the next
+   design, a one-commit cut, and the cut trigger recorded in the placement map.
+6. **One spec per project**; colocate by default and **hoist only when the spec cannot be kept out of
    what ships** (the agentic plugin) — nesting is never the reason.
-6. **Strategy is policy, homes are data** — read the declared strategy from the placement map, derive
+7. **Strategy is policy, homes are data** — read the declared strategy from the placement map, derive
    homes from `concept:` tags, and let the strategy pick the derivation.

package/skills/start-mission/README.md

@@ -2,6 +2,6 @@
 
 The single user-facing entry for **changing an SDD project** — triggered by a general change request ("add a start-mission skill to sdd", "implement the auth capability", "work on `<github issue url>`"). User-invocable: opens a **change request** against the one durable project spec and runs the **mission loop** (intake → explore → deliver → handoff) over it.
 
-The session that runs this skill **is the conductor** — the in-session realization of the conductor role; the headless realization is the `automaton` agent. A third realization is **in-session plan-mode preview**: when Claude Code plan mode is active, explore runs its reasoning (classify, seed-intent grill, draft the spec + scenario list, cold spec-judge) but writes no repo files — it renders the drafted spec + suite into the plan file and ends at **ExitPlanMode**, dropping the build-to-learn spikes. On approval the next real explore adopts the preview as the settled draft. Plan mode is detected **in-body**, never via the trigger `description`, so it never re-fires per turn. It supersedes the retired spec-as-mission entries (`create-spec` / `revise-spec`): adding, revising, or deduping part of the project spec is now an **explore-phase operation inside a CR**, not a top-level mission.
+The session that runs this skill **is the conductor** — the in-session realization of the conductor role; the headless realization is the `sdd-automaton` agent. A third realization is **in-session plan-mode preview**: when Claude Code plan mode is active, explore runs its reasoning (classify, seed-intent grill, draft the spec + scenario list, cold spec-judge) but writes no repo files — it renders the drafted spec + suite into the plan file and ends at **ExitPlanMode**, dropping the build-to-learn spikes. On approval the next real explore adopts the preview as the settled draft. Plan mode is detected **in-body**, never via the trigger `description`, so it never re-fires per turn. It supersedes the retired spec-as-mission entries (`create-spec` / `revise-spec`): adding, revising, or deduping part of the project spec is now an **explore-phase operation inside a CR**, not a top-level mission.
 
 Bakes in: step-1 intake (recover the request or fetch an issue URL; scaffold the `.plan.md`); explore as the live grill (classify spec-type + artifact-types, scaffold the node, actor-first seed-intent Q&A, the inline spec-producer + cold spec-judge loop with build-to-learn spikes, the iteration cap, the **freeze re-open guard**, observation routing); the internal spec gate (freeze + per-CR gate line to the conductor's own `ledger/` shard + `status: approved`); deliver (spawned impl-producer builder + the internal impl gate); handoff; and the baked autonomy bar (initial strategy, per-gate verdicts, the three hard floors). Pairs with `pause-mission` / `resume-mission`.

package/skills/start-mission/SKILL.md

@@ -62,7 +62,7 @@ Get the CR into the system and create its plan brief — the plan is a step-1 ar
 - **Recover the request.** From a general change prompt, name the change and the target. From a **source URL** (`work on <github issue url>`), fetch the issue and read it as the CR body.
 - **Locate the project spec** by running the **`discover-specs`** skill (the `corpus/discovery` engine) — it returns the TOON list of every project spec at the SDD spec locations (the three fixed conventions plus any declared extra anchors, ADR-0019) with its `status` and `project-path`. Resolve the CR's target to one spec by folder slug or `project-path`; an ambiguous match is disambiguated with the user, never guessed. One project is one spec — there is no spec fleet to pick from. If `discover-specs` finds **no** spec for the target project, that is the **backfill** path (load `scaffold-project-spec`).
 - **Scaffold `.agents/plans/<cr-ref>-<what>.plan.md`** — name the brief with a short kebab `<what>` slug naming what the CR does, even when the ref comes from an external source (`github-34-rejudge-sweep.plan.md`, not `github-34.plan.md`). The source name (`github`) is **optional** — most projects draw from one external source, so a bare `34-rejudge-sweep.plan.md` is fine; keep the source prefix only when a project mixes sources. Fill from a basic template: frontmatter `todos` (ordered, `status: pending`, each `content` a **short summary < 120 chars**) + a `## NEXT` anchor + the CR link. Keep the plan body **concise** — it is read by the agent each resume, so phrase for an agent first while staying human-legible (terse lead, no prose padding). This is the portable handoff brief `pause-mission` / `resume-mission` operate on. **Safe-to-publish floor** (the same one the combat log carries in `combat-log-governance`): the brief is **tracked and committed**, so it references **only repo-relative paths** — never an absolute path, `$HOME`/`$USER`, an OS username, or any machine-local location outside the repo. When the CR's design came from a plan-mode doc under a machine-local path (e.g. `~/.claude/plans/…`), bring that content **into** the repo (a sibling `<cr-ref>.design.md` beside the brief) and reference it repo-relative — do not link the external absolute path. The `check-plan-safety` engine enforces this mechanically. **When that brought-in content is a plan-mode preview** (a drafted spec + scenario list from a prior `### Plan-mode preview` run), the explore phase **adopts it as the settled draft** (see Step 2) rather than re-grilling from scratch.
-- **Escape a non-CR.** If the grill shows no suite-relevant behavior, escape: create no draft, invoke no gate, write no record. Independently, **escape by tracking**: for each artifact the request touches, run the **`resolve-tracking`** skill (`intake/resolve-tracking`'s concrete engine) — `node "<skill>/scripts/resolve-tracking.mts" --root . --path <path> [--artifact-type <type>] [--explicit tracked|ignored]`, passing `--explicit` when the requester stated tracking directly and `--artifact-type` when convention already makes it obvious. If **every** touched artifact resolves `ignored`, escape the whole request the same way. If the request is **mixed**, carve the tracked artifacts into the CR and escape the ignored ones (the same carve-and-escape shape already used for the no-behavior case). Escaping does not mean stopping: if the artifact-type has a producer with an escaped-request entry point (`define-skill` for `skill`), invoke it directly to do the work; only state "leaving the lifecycle" and stop when no such producer exists.
+- **Escape a non-CR.** If the grill shows no suite-relevant behavior, escape: create no draft, invoke no gate, write no record. Independently, **escape by tracking**: for each artifact the request touches, run the **`resolve-tracking`** skill (`intake/resolve-tracking`'s concrete engine) — `node "<skill>/scripts/resolve-tracking.mjs" --root . --path <path> [--artifact-type <type>] [--explicit tracked|ignored]`, passing `--explicit` when the requester stated tracking directly and `--artifact-type` when convention already makes it obvious. If **every** touched artifact resolves `ignored`, escape the whole request the same way. If the request is **mixed**, carve the tracked artifacts into the CR and escape the ignored ones (the same carve-and-escape shape already used for the no-behavior case). Escaping does not mean stopping: if the artifact-type has a producer with an escaped-request entry point (`define-skill` for `skill`), invoke it directly to do the work; only state "leaving the lifecycle" and stop when no such producer exists.
 
 ## Step 2 — explore: grill the spec + suite, build to learn
 
@@ -77,11 +77,11 @@ Run authoring **in-session** as the conductor. Explore **builds the implementati
 For each unit the CR touches:
 
 - **Locate or place the node — provisionally.** If a `spec.md` / `README.md` already exists at the target → this is a **revise** (no scaffolding). Otherwise **scaffold** a new node and drop it in a *plausible* home **under the layout the project declared** in its root `spec.md` placement map — `capability-first` groups by what the project *does*, `mirror-source` mirrors the source tree. Placement is judged *within* that declaration, never against a preferred one (`sdd:spec-structure-governance`, "strategy is policy, homes are data"); where no strategy is declared, the `capability-first` default applies. A layered / framework-first **top level** stays discouraged under every strategy (it scatters a capability across folders, breaking node↔folder and degrading scheduling). Consult `project-spec/place-node` (`--concept` → candidate homes; `--name` → "belongs near X" duplicate-catch) and the placement-map routing table (root `spec.md`) for contested overlaps, but **do not agonize**: placement is **provisional** and finalized cheaply at **handoff** (step 4), where a scoped Warden pass relocates it to its blessed home *in the same change* (a pure rename — freeze survives, `sdd:lifecycle-governance`). If the user named no capability, propose a capability folder from the CR and confirm.
-- **Classify the node** (declared, never inferred): `spec-type: behavioral` (a testable unit → `## Use Cases` + a `<unit>.feature`), `reference` (a shipped non-testable artifact → `## Subject`, no `.feature`), or **descriptive** (an index → no marker). Tag the node's cross-cutting **`concept:`** (the concern it serves — e.g. `lifecycle` / `resolution`; a string or list, orthogonal to `spec-type`; it feeds `project-spec/concept-index`). Also classify each touched file's **artifact-type** (the squad key — resolved per file, **not stored**): **by convention first** (`skill` under `skills/`, `subagent` under `agents/`, …; the extension never decides). On a genuine **ambiguity or a user-flagged path**, consult and record the tiebreaker map `.agents/sdd/artifact-types.toml` and **confirm — never guess** (`sdd:artifact-type` model).
+- **Classify the node** (declared, never inferred): `spec-type: behavioral` (a testable unit → `## Use Cases` + a `<unit>.feature`), `reference` (a shipped non-testable artifact → `## Subject`, no `.feature`), or **descriptive** (an index → no marker). Tag the node's cross-cutting **`concept:`** (the concern it serves — e.g. `lifecycle` / `resolution`; a string or list, orthogonal to `spec-type`; it feeds `project-spec/concept-index`). Also classify each touched file's **artifact-type** (the squad key — resolved per file, **not stored**): **by convention first** (`skill` under `skills/`, `subagent` under `agents/`, …; the extension never decides). On a genuine **ambiguity or a user-flagged path**, consult and record the tiebreaker map `.agents/sdd/artifact-types.toml` and **confirm — never guess**.
 - **Scaffold the skeleton** per `sdd:spec-format-governance` (sections per type; `.feature` form per `sdd:suite-format-governance`). Write **no** control frontmatter (`status` / `project-path` / `approval` / `produced-by`) — those live on the root `spec.md` and belong to the conductor and the gate.
 - **Collect seed intent.** For a **new** feature, ask 3–5 targeted questions — **lead with the actors** (who reaches this capability, and who is affected by its outcome without invoking it), then their goals, then the core problem, observable behavior, edge cases / non-goals, and reviewers who must be heard. Ask for the **public interface last, and never first**: an interface offered up front becomes the anchor the use cases get read off, which is the enumeration failure `sdd:spec-format-governance` exists to prevent. For **backfill** (behavior already in code), skip — the producer reads source, tests, history. For a **revise**, collect what changes and why and the parts it touches.
 
-**The grill loop (the user loop).** You are the conductor. Run the spec-producer **inline** (load `sdd:spec-producer-governance`, or persona-load a plugin specialist for the `artifact-types`), **dispatch the cold spec-judge** each round — through the dispatch capability's intent seam when one is available (preferring its **warm** unit, context-cleared fresh via `npx cyberlegion@0.3.1 unit clear <ref>` before each round's judgment), else a portable cold subagent — and for build-to-learn **dispatch the impl-producer builder** the same way (its warm unit **keeps** its context across spikes; no reset) in `explore` mode against the **non-frozen** suite — spikes are thrown away; their learnings feed the live grill to steer the spec + suite. Set an **iteration cap** (default **3**; honor a user-named cap), then loop:
+**The grill loop (the user loop).** You are the conductor. Run the spec-producer **inline** (load `sdd:spec-producer-governance`, or persona-load a plugin specialist for the `artifact-types`), **dispatch the cold spec-judge** each round — through the dispatch capability's intent seam when one is available (preferring its **warm** unit, context-cleared fresh via `npx cyberlegion@<version> unit clear <ref>` before each round's judgment), else a portable cold subagent — and for build-to-learn **dispatch the impl-producer builder** the same way (its warm unit **keeps** its context across spikes; no reset) in `explore` mode against the **non-frozen** suite — spikes are thrown away; their learnings feed the live grill to steer the spec + suite. Set an **iteration cap** (default **3**; honor a user-named cap), then loop:
 
 **Governance provenance relay.** When you dispatch the cold spec-judge, forward the inline spec-producer's declared `governances_loaded` (`sdd:spec-producer-governance`) verbatim through the same dispatch channel, keyed **`producer_governances_declared`** — a brief field when the judge is a cold subagent, a mail envelope field when it runs through an agent pool. Forward it **as-is, including an empty set** — you render **no opinion** on which governances were actually required; that check is the spec-judge's own pre-flight (`sdd:sdd-spec-judge`).
 
@@ -119,7 +119,7 @@ Build-to-keep against the **frozen** suite. The deliver **read-set is scoped** (
 
 **Rebase onto the target — the last deliver act, before the gate.** Before running the impl gate, **rebase the CR branch onto the current tip of the declared target** (for a commit-to-main project, the equivalent `pull --rebase` onto the latest `main`), so the impl gate judges the **merged tree that will actually land** — keeping history linear and leaving handoff a pure consumer that never re-verifies. A **textual conflict** is resolved as **deliver code work** against the frozen `.feature` (never a `.feature` edit); the gate then runs on the resolved tree. A conflict you **cannot resolve confidently is never guess-resolved** — the frozen suite covers *this CR's* behavior, not the incoming change's, so a wrong resolution could still pass the gate and land broken; **stop and escalate** (in-session ask the user; headless return `needs-input` up the relay) and record a `halt`, never land a low-confidence resolution. Rebasing an *unmerged* CR branch is git-reversible (reflog), so it raises **no new hard floor** — but a conflict resolution that would **narrow** a frozen scenario still fires the existing **Clearance** floor, a semver class over the ceiling **Compatibility**, and a genuine contradiction **Conflict** (autonomy bar, below). The rebase-then-gate is **optimistic**: if the target **advances again** between the passing gate and the push (another CR merged in the window), **re-rebase onto the new tip and re-run the impl gate — do not push until the gate passes on the re-rebased tree**, looping until the push wins, so what lands is always a tree the gate saw green. **The loop is bounded, not forced** — if the target keeps advancing past a small cap of attempts, **stop and escalate** (record a `halt`) rather than spinning forever (a liveness stop, same as the unconfident-conflict halt).
 
-**The impl gate (Approved → Implemented, internal).** On entering the gate, overwrite the statusline file with `impl gate`. Dispatch the **cold impl-judge** (`sdd:sdd-impl-judge` or the covering plugin's judge) — same seam-when-available wiring, preferring its warm unit context-cleared fresh via `npx cyberlegion@0.3.1 unit clear <ref>` for this judgment, else a portable cold subagent — to run the verification per frozen scenario plus an orthogonal structural/scope read. Advance to **`status: implemented`** **only when every impl-judge passes** (a frozen scenario with no verification blocks the advance — impl-sync is this suite run, not a stored flag). The three actions: **approve** → `implemented`; **change** → fix the **code** (never the frozen `.feature`), under the same evidence-not-a-work-order remediation the spec gate uses (`sdd:remediation-governance`) — including the **provenance** account that stops a regressing loop; **reject** → redo, or a **Oracle-lens revert** (a frozen scenario proved fatal → unfreeze the `.feature`, return to `draft` — the only place a frozen `.feature` reopens).
+**The impl gate (Approved → Implemented, internal).** On entering the gate, overwrite the statusline file with `impl gate`. Dispatch the **cold impl-judge** (`sdd:sdd-impl-judge` or the covering plugin's judge) — same seam-when-available wiring, preferring its warm unit context-cleared fresh via `npx cyberlegion@<version> unit clear <ref>` for this judgment, else a portable cold subagent — to run the verification per frozen scenario plus an orthogonal structural/scope read. Advance to **`status: implemented`** **only when every impl-judge passes** (a frozen scenario with no verification blocks the advance — impl-sync is this suite run, not a stored flag). The three actions: **approve** → `implemented`; **change** → fix the **code** (never the frozen `.feature`), under the same evidence-not-a-work-order remediation the spec gate uses (`sdd:remediation-governance`) — including the **provenance** account that stops a regressing loop; **reject** → redo, or a **Oracle-lens revert** (a frozen scenario proved fatal → unfreeze the `.feature`, return to `draft` — the only place a frozen `.feature` reopens).
 
 ## Step 4 — handoff
 
@@ -137,13 +137,13 @@ Before you close out, run the **correction-line finalize backstop** (autonomy ba
 
 Also run the **plan-brief finalize backstop** (autonomy bar, below): reconcile the plan brief's `todos` and its `## NEXT` anchor to the landed state, **in this same change** — so the delivery never ships a landed mission described as in-progress.
 
-Before closing out, **reset the mission's warm units**: `npx cyberlegion@0.3.1 unit clear <ref>` (context-clear, pane stays warm) or tear down every warm unit this mission dispatched — none carries this mission's context into the next.
+Before closing out, **reset the mission's warm units**: `npx cyberlegion@<version> unit clear <ref>` (context-clear, pane stays warm) or tear down every warm unit this mission dispatched — none carries this mission's context into the next.
 
 Once landed, **do not spawn** the formation Warden. Surface a **one-line nudge** that a corpus-wide formation pass is due, pointing to `sdd:manage` ("audit the corpus structure" → `formation-loop`). The pass is **on-demand** — run deliberately, not auto-spawned on every landing; `sdd:manage` owns the trigger. Gate nothing on it.
 
 ## Autonomy, provenance, and the hard floor (baked in)
 
-- **Dispatch transport.** Every spawn beyond this session states a **dispatch intent** — role, brief, expected verdict schema — never a pinned command. When a harness-agnostic dispatch capability is available (detected at runtime; the concrete case is the Legate's `dispatch-governance` composing `cyberlegion` primitives — `agent resolve` + `unit spawn` + `mail await` — with **no** `dispatch` CLI verb, the seam named in the SDD project spec's `design/harness-spawning` node, repo-only), route through its intent seam and let it pick `subagent | channel | run-inline`, **preferring a warm unit** over a cold one-shot spawn; with no capability present, fall back to the portable cold subagent (depth-1) default — grader independence intact either way. **Warmth is a property of the unit/process; coldness of the context**: a judge's fresh-context guarantee (ADR-0016) is transport-agnostic — satisfied by a newly spawned cold subagent **or** a warm unit **context-cleared** to a fresh context before **each** judgment (re-deriving its oracle, carrying none of a prior round's context). Clear a warm unit with **`npx cyberlegion@0.3.1 unit clear <ref>`** (`<ref>` = unit id / handle / worktree branch or CR ref) — it injects the harness's own fresh-context command (`/clear` on Claude/Codex/Copilot, `/new-chat` on Cursor; fail-loud on a harness with no honest reset) so the **pane stays warm** while the **context goes cold**; it tears nothing down. The **impl-producer builder** instead stays warm and **keeps** its context across the explore spikes and the deliver build (never cleared between those uses). Warm units stay warm for **one mission** — reused within it, then **`unit clear`**'d or torn down at **handoff**, never carrying this mission's context into the next.
+- **Dispatch transport.** Every spawn beyond this session states a **dispatch intent** — role, brief, expected verdict schema — never a pinned command. When a harness-agnostic dispatch capability is available (detected at runtime; the concrete case is the Legate's `dispatch-governance` composing `cyberlegion` primitives — `agent resolve` + `unit spawn` + `mail await` — with **no** `dispatch` CLI verb, the seam named in the SDD project spec's `design/harness-spawning` node, repo-only), route through its intent seam and let it pick `subagent | channel | run-inline`, **preferring a warm unit** over a cold one-shot spawn; with no capability present, fall back to the portable cold subagent (depth-1) default — grader independence intact either way. **Warmth is a property of the unit/process; coldness of the context**: a judge's fresh-context guarantee (ADR-0016) is transport-agnostic — satisfied by a newly spawned cold subagent **or** a warm unit **context-cleared** to a fresh context before **each** judgment (re-deriving its oracle, carrying none of a prior round's context). Clear a warm unit with **`npx cyberlegion@<version> unit clear <ref>`** (`<ref>` = unit id / handle / worktree branch or CR ref) — it injects the harness's own fresh-context command (`/clear` on Claude/Codex/Copilot, `/new-chat` on Cursor; fail-loud on a harness with no honest reset) so the **pane stays warm** while the **context goes cold**; it tears nothing down. The **impl-producer builder** instead stays warm and **keeps** its context across the explore spikes and the deliver build (never cleared between those uses). Warm units stay warm for **one mission** — reused within it, then **`unit clear`**'d or torn down at **handoff**, never carrying this mission's context into the next.
 - **SDD's own judges go to the seam by file, not by name.** A dispatch capability may resolve a definition by name only in the project's own agent folder (cyberlegion's `agent resolve` does), so it cannot find one SDD ships. When the judge role resolves to SDD's own `sdd-spec-judge` or `sdd-impl-judge`, locate the definition yourself at **`agents/<name>.md` under the SDD plugin root** — two levels above this skill's own base directory (`<skill dir>/../../agents/<name>.md`) — and hand the capability **that path** (cyberlegion: `agent resolve --file <path>`, `unit spawn --agent-file <path>`), never the bare name. If no file is there, send the capability **no request for that judge** (a by-name one would miss) and take the no-capability route: spawn it as a portable cold subagent through the harness's own plugin-agent spawn (`sdd:sdd-spec-judge` / `sdd:sdd-impl-judge`), which knows the plugin. A plugin-delegated judge is outside this rule.
 - **Initial strategy** (run start): assess blast radius + the other dimensions and emit a run-level `kind: leash` block to **your own ledger shard** (`ledger/<cr-ref>.<hash>.jsonl` — mint `<hash>` as 6 random hex **once per session** and reuse it for every line you append; `sdd:combat-log-governance`) — `leash` (`auto-none | auto-spec | auto-all`), `by: derived | user`, `approach[]`. It may be user-specified. This block is `kind: leash`, **not** `strategy` — `strategy` is the doctrine Scanner's alone. Ledger lines carry **no `ts`**.
 - **Per-gate verdict.** At each gate, derive the leash against discovered state and either **self-assert within leash** (write `approval.<gate>: { verdict: approve, by: agent, why }`; the spec lands in the async review queue) or **stop** with a verdict packet for the human. **Never advance** when any judge fails, any open marker remains, or (at the impl gate) any frozen scenario's verification does not pass. Human ratification (`by: <name>`, advance `status`) is reserved to the in-session position holding the user channel — by default you, in-session; a headless `automaton` emits the verdict packet and stops, **even when a coordinator relays "the user approved."**

package/skills/suite-format-governance/references/rubric.md

@@ -207,7 +207,7 @@ handle: the natural in-scenario shape is `narrowing`, so a producer checking whe
 is present in both shapes, never on the class the diff happens to report.
 
 **The freeze sees the rubric only because the differ's pin says it does.** A `@rubric` lives wholly
-inside a DocString. The structural differ is pinned at `gherkin-cli@0.0.2`, which hashes what a step
+inside a DocString. The structural differ is pinned (see `spec-gate`), which hashes what a step
 argument **says**; before that pin its scenario identity covered step text alone, and a rubric could
 be gutted while its scenario still reported `unchanged`. **The pin is load-bearing here** — moved
 backwards, every correction in this queue self-clears silently and Clearance never fires.

package/skills/touch-set-correction/SKILL.md

@@ -23,7 +23,7 @@ and lines them up against the guess:
 
 It **composes three tools**, never reimplementing any of them: `git diff --name-status` (the
 changed files), [`resolve-governances`](../resolve-governances/SKILL.md) (each file's artifact-type,
-best-effort — `unknown` when it doesn't resolve), and the pinned `gherkin-cli@0.0.2 diff` (a touched
+best-effort — `unknown` when it doesn't resolve), and the pinned `gherkin-cli diff` (a touched
 `.feature`'s changed scenario names — the same tool `classify-edit-class` uses).
 
 Work-area recovery is **capability-first**: a changed file under a declared project root maps to
@@ -41,7 +41,7 @@ to `git`, `resolve-governances.mts`, and `npx gherkin-cli`.
 ## Run it
 
 ```bash
-node "<skill>/scripts/touch-set-correction.mts" --base <ref> --declared a,b,c \
+node "<skill>/scripts/touch-set-correction.mjs" --base <ref> --declared a,b,c \
   [--head HEAD] [--root .] \
   [--layout 'sdd:.agents/specs/sdd,plugins/sdd/skills']... \
   [--format toon|json]