session-orchestrator 5.11.0 → 5.13.0

package/skills/plan/mode-new.md

@@ -97,10 +97,10 @@ Agent({ subagent_type: "Explore", description: "Research success benchmarks",
 **Questions:**
 
 1. **MVP scope** — Shape Up appetite: 1 week / 2 weeks / 6 weeks. Frame trade-offs for each.
-2. **Success criteria** — SMART format (Specific, Measurable, Achievable, Relevant, Time-bound). Claude proposes draft from research, user refines.
+2. **Success criteria** — SMART format (Specific, Measurable, Achievable, Relevant, Time-bound), each with a measured baseline (or "none yet") and an oracle other than the author. Claude proposes the draft from research, the user refines it.
 3. **Known risks and mitigations** — Present common risks from agent research. User confirms, removes, or adds.
 4. **Post-launch plan** — Monitoring strategy, rollback plan, feedback channels.
-5. **Ecosystem dependencies** — Other repos in the 17-repo ecosystem this project depends on or integrates with. Agent verifies compatibility.
+5. **Ecosystem dependencies** — Other repos in the ecosystem (count them, never assume a number) this project depends on or integrates with. Agent verifies compatibility.
 
 ---
 
@@ -118,7 +118,8 @@ Agent({ subagent_type: "Explore", description: "Research success benchmarks",
    - **Section 7 (Risks & Dependencies):** From Wave 3 Q3 + Q5. Table format: Risk | Probability | Impact | Mitigation.
    - **Section 8 (Post-Launch Plan):** From Wave 3 Q4. Monitoring, rollback, feedback channels.
 3. Save PRD to `{plan-prd-location}/YYYY-MM-DD-{project-name}.md`.
-4. Dispatch reviewer per `prd-reviewer-prompt.md`. Max 3 iterations. Surface unresolved issues to user.
+4. **Pre-Mortem Panel:** dispatch the Refute and Deepen briefs per `SKILL.md` § Phase 4.5 and `prd-premortem-panel.md`, then merge into Sections 5, 5.A (Oracle lines), External Acceptance and 7.
+5. Dispatch reviewer per `prd-reviewer-prompt.md`. Max 3 iterations. Surface unresolved issues to user.
 
 ---
 
@@ -213,7 +214,7 @@ Choose the project-instruction file appropriate to the platform that will operat
 
 ### Step 6: Commit PRD
 
-Commit the PRD document to the new repo. Use a descriptive commit message:
+Copy the approved PRD from the path saved in Phase 2 into the new repo's `docs/prd/`, then commit it there. This step meets the PRD Commit Gate for `/plan new` (`SKILL.md` § Phase 5.5); run its § 5.5.2 checks in the new repo before Phase 4. Use a descriptive commit message:
 
 ```bash
 git add docs/prd/YYYY-MM-DD-{project-name}.md
@@ -268,16 +269,7 @@ Source: PRD Section 4 (Solution & Scope).
 
 ### Step 2: Auto-prioritize
 
-Score each issue using three factors:
-
-1. **Technical dependencies (highest weight):**
-   - DB schema before API, API before frontend, shared libs before consumers.
-   - Issues that block others → `priority::critical` or `priority::high`.
-2. **Business value (medium weight):**
-   - Core MVP features → `priority::high`.
-   - Nice-to-haves → `priority::medium` or `priority::low`.
-3. **Risk (tiebreaker):**
-   - Issues with identified risks from PRD Section 7 → bump up one level.
+Score each issue per `SKILL.md` § 6.2 Auto-Prioritize (technical dependencies, business value, and the Impact × Risk 2×2 triage), with risks taken from PRD Section 7. Add one `[Abnahme]` issue per External Acceptance row (`SKILL.md` § 6.1).
 
 ### Step 3: Apply labels
 

package/skills/plan/prd-feature-template.md

@@ -25,6 +25,13 @@
 ### Who
 {{Target users — existing personas or new audience — from Wave 1 Q3}}
 
+### Evidence Baseline
+> The premise, measured. One row per claim the plan rests on. A claim that did not reproduce stays here, marked `hypothesis`.
+
+| Claim | Command | Result | Measured (date / SHA) |
+|-------|---------|--------|-----------------------|
+| {{premise}} | `{{command}}` | {{result}} | {{YYYY-MM-DD @ sha}} |
+
 ## 2. Solution & Scope
 
 ### In-Scope
@@ -36,6 +43,9 @@
 - {{excluded-1 — why}}
 - {{excluded-2 — why}}
 
+### First Real Use / Kill
+{{The first use outside tests, who triggers it and by when (e.g. "first committed manifest in a consumer repo by YYYY-MM-DD"). If it has not happened by then: re-shape or kill (mvp-scope Circuit Breaker), never silent carry-over.}}
+
 ## User Stories
 
 > Optional intent layer — emitted only when the Wave-1 story toggle is "yes". Leave blank or delete this section if §3/§3.A acceptance criteria already capture the intent. Stories are the "who/why"; acceptance criteria are the "verify".
@@ -77,6 +87,15 @@ When {{action}}
 Then {{graceful handling}}
 ```
 
+> Under every scenario block, add one line `Oracle: {{who or what other than the author shows it holds — the installed artifact read back, the platform's own output, an independent process, a calibration fixture with known answers, a consumer-repo run}}`. Use `Oracle: n/a — {{reason}}` only when no such judge exists. The author's unit test against a fake is not an oracle.
+
+### External Acceptance
+> Criteria whose oracle cannot run inside the implementing session. Each row becomes its own `[Abnahme]` issue (SKILL.md § 6.1), which the implementing issue does not close.
+
+| Criterion | Oracle | Owner | Not before | Pass condition | Fallback if it cannot run |
+|-----------|--------|-------|------------|----------------|---------------------------|
+| {{AC ref}} | {{command / observation}} | {{owner}} | {{YYYY-MM-DD}} | {{pass}} | {{fallback}} |
+
 ## 3.A Acceptance Criteria (EARS)
 
 > Optional companion to Section 3 — translates each Feature Area's acceptance criteria into EARS-shaped statements for deterministic vitest stub generation by `/write-executable-plan`. Leave blank if Section 3's narrative Gherkin suffices.

package/skills/plan/prd-full-template.md

@@ -27,6 +27,7 @@
 
 ### Current State
 {{How users currently solve this problem. Pain points.}}
+{{Measured: one line per premise, `command` → result (date / SHA). A premise nobody measured is labelled `hypothesis`.}}
 
 ## 3. Target Audience & Personas
 
@@ -66,11 +67,17 @@
 
 ## 5. Success Criteria
 
-| Metric | Target | Measurement Method | Deadline |
-|--------|--------|--------------------|----------|
-| {{metric-1}} | {{specific target}} | {{how to measure}} | {{date}} |
-| {{metric-2}} | {{specific target}} | {{how to measure}} | {{date}} |
-| {{metric-3}} | {{specific target}} | {{how to measure}} | {{date}} |
+| Metric | Baseline (measured) | Target | Measurement Method (the oracle, not the author) | Owner | Deadline |
+|--------|---------------------|--------|-------------------------------------------------|-------|----------|
+| {{metric-1}} | {{value + command, or "none yet"}} | {{specific target}} | {{how to measure}} | {{owner}} | {{date}} |
+| {{metric-2}} | {{value + command, or "none yet"}} | {{specific target}} | {{how to measure}} | {{owner}} | {{date}} |
+
+### External Acceptance
+> Criteria whose oracle cannot run inside the implementing session. Each row becomes its own `[Abnahme]` issue (SKILL.md § 6.1).
+
+| Criterion | Oracle | Owner | Not before | Pass condition | Fallback if it cannot run |
+|-----------|--------|-------|------------|----------------|---------------------------|
+| {{AC ref}} | {{command / observation}} | {{owner}} | {{YYYY-MM-DD}} | {{pass}} | {{fallback}} |
 
 ## 5.A Acceptance Criteria (EARS)
 

package/skills/plan/prd-premortem-panel.md

@@ -0,0 +1,48 @@
+# PRD Pre-Mortem Panel — Two Subagent Briefs
+
+> Dispatched by SKILL.md Phase 4.5, after the PRD draft and before the PRD reviewer (Phase 5). Two read-only agents, one message, in parallel. Each receives its brief below verbatim plus the PRD path; neither sees the other's output.
+
+## Why two briefs
+
+Back-test 2026-10-19: three committed PRDs replayed in history-truncated clones against 43 surprises their later history recorded. The PRDs as shipped anticipated 0 of 43 (15 partially). A refute brief and a deepening brief each hit 7–8; together 11, because they find different classes. The refute brief hit security and structure (an unbounded command surface, generated mirrors missing from the file list). The deepening brief hit oracle gaps: a package census that was not the installed artifact, a run that was never measured and read as fixed, a lifecycle never exercised. Neither brief prevents the most frequent class on its own. Real-world acceptance stayed undone in 3 of 3 PRDs, so it is carried as structure (template § External Acceptance, SKILL.md § 6.1), not as a prediction.
+
+**Relation to `/grill`:** `/grill` is the interactive counterpart, one question per turn with the operator defending the plan (`skills/grill/soul.md` Tactics 5–6). This panel is the non-interactive pass `/plan` always runs. A prediction the merge cannot settle without the operator is a `/grill` candidate, not a silent drop.
+
+## Shared rules (both briefs)
+
+- Read-only. No edits, commits, network writes, or issue comments. Read the code the PRD touches, and run cheap local commands (grep, the repo's own scripts, `--help`, `ps`).
+- Every claim carries one evidence pointer: `file:line`, a command and its result, or the word `inference`. Never pass an inference off as a measurement (`skills/_shared/research-evidence.md` § Basis).
+- At most 20 predictions, P1..P20, each ≤2 sentences, concrete and checkable: what will go wrong, which assumption fails, what work will be missing, or what will be found later. No generic advice.
+- Return one Markdown report as your final message.
+
+## Brief A — Refute
+
+You review the PRD at `<path>` as the engineer who will be paged when it fails. Assume it ships exactly as written. Find what breaks, using the repository rather than the text. In particular:
+
+1. **Live path:** is the code path the PRD changes the one that runs in production? Census the callers and quote the grep.
+2. **Input surfaces:** every value read from a file, manifest, register or argument that reaches `exec`, `kill`, the filesystem, a URL or argv. Ask what a hostile or corrupt value does.
+3. **Declared-unchanged modules:** read each module the PRD calls "unchanged" or "reused" for the invariants the plan relies on.
+4. **Consumers and mirrors:** who reads the new signal (events, rubrics, telemetry, reports), and which generated mirrors, inventories or counts must move with it.
+5. **States:** for every read, what happens when the input is missing, unreadable or half-written, as distinct from empty.
+
+Output: `## Predictions` (P1..P20).
+
+## Brief B — Deepen
+
+The operator wants a deeper version of these tasks, not bigger ones. Work the four steps against the actual material, and do each step rather than only naming it:
+
+1. **Practice:** what would a top professional in this field do here that the PRD does not ask for? Name the field first.
+2. **Raw material:** what is the rawest material they would start from instead of what has already been digested (the issue text, docs, a summary)? That means the installed artifact, the platform binary or contract, live process or event data, a real run's output, the git history of the area. Open it where it is reachable and report what it shows.
+3. **Methods and tools:** name the specific methods and tools they would use, and apply them where it is cheap.
+4. **Oracle:** what, other than the author or the operator, would show the result is right? For each acceptance criterion, name that judge and say whether the PRD uses it. The author's own unit test against a fake does not count.
+
+Then rewrite the acceptance criteria to ask for exactly that: same scope, each criterion bound to its oracle. Name the criteria whose oracle cannot run inside an implementing session.
+
+Output: `## (1) Practice` · `## (2) Raw material` · `## (3) Methods` · `## (4) Oracle` · `## Rewritten acceptance criteria` · `## Predictions` (P1..P20).
+
+## Coordinator merge (SKILL.md Phase 4.5)
+
+1. **Predictions:** a prediction with an observed pointer that the coordinator re-checks in one command enters § Risks with its pointer and a Triage value. A prediction resting on `inference` enters as `unverified`, or is dropped with a one-line reason. Duplicates across briefs merge. Re-check before adopting (RCR-003); a brief's word is a claim, not a measurement.
+2. **Oracles:** every acceptance criterion gets an `Oracle:` line taken from Brief B, or `Oracle: n/a — <reason>`. A criterion whose oracle cannot run in the implementing session moves to § External Acceptance with an owner, a not-before date, a pass condition and a fallback.
+3. **Premise:** a Brief B raw-material finding that contradicts § 1 goes to the operator via AUQ before the reviewer runs. It is a premise change, not a risk.
+4. **Budget:** the panel deepens, it does not widen. A prediction that would add scope goes to Out-of-Scope or a follow-up, never silently into In-Scope.

package/skills/plan/prd-reviewer-prompt.md

@@ -10,7 +10,7 @@ You are a PRD reviewer. Your job is to ensure the PRD is complete, consistent, a
 
 ## Review Criteria
 
-Evaluate the PRD against these 7 criteria. For each, report **PASS** or **FAIL** with specific feedback.
+Evaluate the PRD against these 8 criteria. For each, report **PASS** or **FAIL** with specific feedback.
 
 ### 1. Completeness
 - All sections are filled — no `{{placeholder}}`, `TBD`, `TODO`, or empty sections
@@ -62,6 +62,13 @@ Evaluate the PRD against these 7 criteria. For each, report **PASS** or **FAIL**
   - (c) each story links at least one acceptance criterion via a `↳ AC:` pointer to §3/§3.A (feature PRD) or §5/§5.A (full PRD).
 - Do NOT apply INVEST (Independent / Negotiable / Estimable) checks — only the present/form/link checks above.
 
+### 8. Verifiability
+- Every acceptance criterion carries an `Oracle:` line naming who or what other than the author shows it holds: the installed artifact read back, the platform's own output, an independent process, a calibration fixture with known answers, or a consumer-repo run.
+- The author's own unit test against a fake is not an oracle. A criterion verified only that way FAILs unless its `Oracle: n/a` gives a reason.
+- Every External Acceptance row names an owner, a not-before date, a pass condition and a fallback.
+- The Evidence Baseline (feature PRD § 1) or the Current State measurement (full PRD § 2) quotes the command behind each premise, or labels the premise `hypothesis`.
+- **FAIL if:** any criterion lacks an oracle line, any External Acceptance row lacks an owner or date, or a premise is stated as fact without a measurement.
+
 ## Output Format
 
 ```
@@ -76,6 +83,7 @@ Evaluate the PRD against these 7 criteria. For each, report **PASS** or **FAIL**
 | YAGNI | PASS/FAIL | {{specific feedback}} |
 | SMART Metrics | PASS/FAIL/SKIP | {{specific feedback}} |
 | User Stories | PASS/FAIL/SKIP | {{specific feedback}} |
+| Verifiability | PASS/FAIL | {{specific feedback}} |
 
 ### Issues to Fix
 1. {{specific issue with location in PRD and suggested fix}}
@@ -89,7 +97,7 @@ Evaluate the PRD against these 7 criteria. For each, report **PASS** or **FAIL**
 ## Iteration Protocol
 
 1. SKILL.md dispatches you with the PRD content.
-2. You review against all 7 criteria.
+2. You review against all 8 criteria.
 3. If all PASS -> return APPROVED verdict.
 4. If any FAIL -> return REVISE verdict with specific issues.
 5. SKILL.md revises the PRD and re-dispatches you.
@@ -98,6 +106,6 @@ Evaluate the PRD against these 7 criteria. For each, report **PASS** or **FAIL**
 ## What You Are NOT
 
 - Not a copy editor — don't flag grammar or style (unless it causes ambiguity)
-- Not a pessimist — don't invent risks that aren't there
+- Not speculative — a risk you raise carries an evidence pointer (file:line or a command result); the pre-mortem against the code already ran in Phase 4.5, so judge the PRD, do not redo the panel
 - Not a maximalist — don't request more sections or detail than the template requires
 - Focus on: can this PRD be implemented as written? If yes -> PASS.

package/skills/plan/soul.md

@@ -30,7 +30,7 @@ You answer in the operator's language: `owner.language` in `~/.config/session-or
 ### Drive convergence
 - Each wave narrows the solution space. Start broad, end specific.
 - Wave 1 defines the problem. Wave 2 shapes the solution. Wave 3 locks the scope.
-- If alignment is reached early, stop early. Three waves is the max, not the target.
+- If alignment is reached early, stop early. The wave cap in SKILL.md § 3.3 is the max, not the target.
 - Progress means fewer open questions, not more.
 
 ## Output Levels

package/skills/portfolio/SKILL.md

@@ -32,11 +32,11 @@ Then continue with the remaining valid arguments.
 
 ## Behavior
 
-1. **Config gate** — Read the `gitlab-portfolio:` block from Session Config. If `enabled: false` (or the block is absent), log `Portfolio: disabled (gitlab-portfolio.enabled is false) — set enabled: true to activate.` and return exit code 0.
+1. **Config gate** — The CLI reads the `gitlab-portfolio:` block from Session Config. Only `enabled: true` activates it: an absent block parses to the default `enabled: false` (`scripts/lib/config/gitlab-portfolio.mjs`), and in both cases the CLI prints `gitlab-portfolio: disabled (set gitlab-portfolio.enabled: true in Session Config)` and exits 0.
 
-2. **Mode gate** — If `mode: off`, the command is a silent no-op; log a single line and exit 0.
+2. **Mode gate** — If `mode: off`, the command is a no-op: the CLI checks it before vault resolution and any repo scan, prints `gitlab-portfolio: mode: off — skipped (set gitlab-portfolio.mode: warn|strict to run)` and exits 0 (#1619). Dispatch as usual; under `strict`, repo fetch failures exit 2.
 
-3. **Vault resolution** — Read `vault-integration.vault-dir` from Session Config. If `vault-integration.enabled: false` or `vault-dir` is absent, exit 1 with: `Portfolio: vault-integration must be enabled with vault-dir set.`
+3. **Vault resolution** — The CLI takes `--vault-dir`, else `vault-integration.vault-dir` from Session Config (resolved host-locally). If neither yields a path it prints `gitlab-portfolio: vault-integration.vault-dir not configured in Session Config` and exits 2. `vault-integration.enabled` is not checked: a configured `vault-dir` is used even when vault integration is disabled.
 
 4. **Dispatch** — Invoke `scripts/lib/gitlab-portfolio/cli.mjs` with the resolved arguments:
 
@@ -90,9 +90,8 @@ Behaviour is governed by the `mode` config field:
 | Code | Meaning |
 |---|---|
 | `0` | Success (or `mode: off` / `enabled: false` no-op) |
-| `1` | User/config error (bad args, missing vault config) |
-| `2` | System error (vault-dir not found, write failed) |
-| `3` | Repo fetch failures in `strict` mode |
+| `1` | User error (bad arguments, `--repo` names no discovered repo) |
+| `2` | System error (Session Config unreadable, no `vault-dir` configured, `vault-dir` outside the home directory, repo discovery or fetch crashed, write failed, repo fetch failures in `strict` mode) |
 
 Exit codes follow `.claude/rules/cli-design.md` conventions.
 

package/skills/quality-gates/SKILL.md

@@ -147,11 +147,9 @@ its review output.
 
 ## Graceful Degradation
 
-Handle missing tools without failing the session:
+Handle missing tools without aborting the session; a missing configured command is still reported as a failed check:
 
-- If `{typecheck-command}` fails with "command not found" → skip TypeScript checks, note "No TypeScript configured".
-- If `{test-command}` fails with "command not found" → skip tests, note "No test runner configured".
-- If `{lint-command}` fails with "command not found" → skip lint, note "No linter configured".
+- If a configured typecheck, test or lint command fails with "command not found", report `fail` (exit 127; on Windows `cmd.exe` exits 1, so it is a plain `fail`). Correct the command or explicitly set it to `skip` in Session Config.
 - Non-TypeScript projects should set `typecheck-command: skip` in Session Config.
 
 Always continue with the remaining checks — never abort a variant because one tool is missing.

package/skills/reconcile/SKILL.md

@@ -55,6 +55,25 @@ any file is written. Advisory-only — rules are NEVER auto-applied.
   their findings to `docs/reconcile/<date>-<topic>.md`, never into the store. (Since
   2026-07-31 a read-side shape guard drops records lacking `learning_key`/`created_at` and
   `mergeCandidates` reports the count as `skipped` — that guard is a backstop, not a licence.)
+- **Verdicts outlive the checkout in an append-only ledger** (#1710).
+  `.orchestrator/metrics/reconcile-verdicts.jsonl` resolves against the MAIN checkout
+  (`resolveEventsLedgerRoot`) and sits beside `learnings.jsonl`, so it shares that file's
+  tracking (vault: tracked, needs `merge=union`; this repo: host-local). Verdict lines come
+  from `mergeCandidates`, once per terminal DECISION (`rejected`, `expired-swept`), and from
+  `markCandidateProcessed` when a decision is stamped over a kept `written` /
+  `already-on-disk` record (the merge keeps that record, so it cannot mirror the decision); the
+  branch-scoped `written` / `already-on-disk` / outcome-less records stay out, because the
+  tracked rule file's provenance marker already witnesses them across trees. After a non-dry
+  merge the engine appends one run line with the learnings count it loaded; run recency comes
+  from run lines only. A learning is terminal when the sidecar OR the ledger OR a
+  `.claude/rules/` provenance marker says so. Code never rewrites the ledger; the only
+  sanctioned hand edit is a deliberate re-open of a declined learning, and it must cover
+  EVERY checkout: remove the learning's verdict lines from the ledger in the main checkout
+  AND its record from the sidecar of the main checkout and of every linked worktree —
+  otherwise the next merge in a worktree whose sidecar still holds the terminal `rejected`
+  record appends it to the ledger again (backfill). Ceiling: a `/reconcile` in a linked
+  worktree of the vault appends to the main checkout's tracked ledger — an uncommitted
+  change there, committed by the vault's replica sync.
 - **Same pipeline as session-end Phase 3.6.8.** This skill uses the identical engine and
   writer seams as the automatic session-end reconciliation phase — operator experience is
   consistent, and any fixes to the engine benefit both paths.
@@ -396,9 +415,11 @@ consolidation survives the next `/reconcile`:
   latest: it must not outlive its shortest-lived content.
 - **An EXPIRED file no longer dedupes** (#1387): the provenance reader skips it
   whole, so its learnings become re-proposable — fail-open on an unparseable
-  date. Two known limits, measured 2026-09-18: this is the on-disk half only
-  (79 of this repo's 92 provenance keys are ALSO sidecar-terminal, so just 13
-  return), and a file the sweep cannot split or cannot read
+  date. Two known limits, measured 2026-09-18: this covers only the on-disk
+  source, not the sidecar or the verdict ledger (79 of this repo's 92
+  provenance keys are ALSO sidecar-terminal, so just 13 return; the ledger
+  carries decisions only, never a rule's own `written` verdict), and a file the
+  sweep cannot split or cannot read
   (`no-1to1-mapping`, `no-provenance-block`, `unreadable`, and since GH#70
   `no-counter-sentence` — the fail-closed branch that touches such a file not
   at all, deletion included; none in the live tree today, `skipped: []` over 7
@@ -412,7 +433,9 @@ consolidation survives the next `/reconcile`:
   repoRoot })` from `scripts/lib/reconcile/idempotency.mjs` — the ONLY
   sanctioned writer of `.orchestrator/runtime/reconcile-candidates.jsonl`
   (never append to that file by hand; the read-side shape guard drops foreign
-  records and `mergeCandidates` rewrites the store in full).
+  records and `mergeCandidates` rewrites the store in full). A `rejected` stamp
+  also reaches the verdict ledger, so the drop holds in fresh worktrees (and on
+  other hosts only where `.orchestrator/metrics/` is tracked).
 
 **Verify a consolidation with a dry run**, not by eye: `alreadyMaterialized`
 must equal absorbed + dropped. If it equals only the absorbed count, the drops

package/skills/release/SKILL.md

@@ -19,6 +19,7 @@ The user wants to cut a release of this package. Optional argument — the targe
 The flags this repo's release path uses — the operator-facing entry points, in the order they run:
 
 - `node scripts/release.mjs --set-version X.Y.Z` — rewrite every version surface and sync `package-lock.json`.
+- `node scripts/snapshot-probe.mjs --host win-wsl --json` — under `mirror: curated`, run the suite on the exported tree of the release commit before anything is pushed; `--check` requires its receipt.
 - `node scripts/release.mjs --check --json` — the preflight gate; every row must be green.
 - `node scripts/release.mjs --publish` — the irreversible step; give it ≥600 s of wall clock.
 
@@ -40,17 +41,21 @@ The same reading shows the other half: the GitHub releases for 3.15/3.18/3.19/3.
 
 ## The order
 
-1. **Preconditions.** Working tree clean, on `main`, and `origin/main` **and** `github/main` both level with `HEAD`. The mirror is checked because the site deploy hangs off `github`, not `origin`.
+1. **Preconditions.** Working tree clean, on `main`, `origin/main` level with `HEAD`, and the GitHub mirror current. The mirror is checked because the site deploy hangs off `github`, not `origin`. What "current" means follows Session Config `mirror` (`--check` row `github-mirror-mode` names it): under `mirror: github` (or unset), `github/main` equals `HEAD`; under `mirror: curated` (#1645), GitHub never receives `HEAD` — `github/main` is a squash snapshot whose `Source-Commit:` trailer must name `HEAD` (publish it with `/close` on `main`, session-end § 4.4). `docs/github-mirror-protection.md` § Releases under `mirror: curated`.
 2. **Set the version.** `node scripts/release.mjs --set-version X.Y.Z` — rewrites every version surface, syncs `package-lock.json`, re-stamps the measured census on the site.
 3. **Write the editorial half.** The dated `## [X.Y.Z] - YYYY-MM-DD` CHANGELOG entry, `[Unreleased]` folded, README highlights. The script does not write these; `--check` enforces them.
-4. **Gate, commit, push.** Full quality gate, then commit and push to **both** remotes.
-5. **CI green — on the commit that will be published, on BOTH platforms.** Not on its predecessor: a green pipeline from before step 4's commit is evidence about a different tree. And not on GitLab alone — `--check` carries two CI rows, `ci-green-on-head` (GitLab, via `origin`) and `ci-green-on-head-github` (the mirror). The GitLab pipeline is Linux-only; the **macOS** matrix leg exists solely in `.github/workflows/test.yml`, i.e. on the operator's own platform. The github row self-disables (`skipped — no github remote`) in a checkout without a mirror, and fails on `unknown`/`degraded` exactly like the GitLab one — "could not read the mirror" is not "the mirror is green".
-6. **Preflight.** `node scripts/release.mjs --check --json` — every row green. Run this after the release commit is pushed and its CI succeeds: the preflight requires a clean working tree, exact HEAD parity on both remotes and green CI on that commit. It derives its target from `package.json`, so checking the pre-bump version instead produces registry- and tag-collision failures.
-7. **Publish.** `node scripts/release.mjs --publish` — **give it ≥600 s of wall clock, or run it in the background.** The script sets no spawn timeout on purpose (a kill mid-`npm publish` or mid-push is the very failure the receipt boundary exists to avoid), and the tail is slow by construction: each of the two `git push` remotes re-runs the husky pre-push full gate, plus up to 120 s of live-site polling. A 3-minute default command timeout kills it mid-tail.
+4. **Gate, commit.** Full quality gate, then commit. Do not push yet.
+5. **Probe the export (under `mirror: curated`), before the push.** `node scripts/snapshot-probe.mjs --host win-wsl --json` — builds the curated tree of `HEAD` (the release commit), runs validate-plugin on it locally and the full suite on it remotely (the pre-push router's gate on that host). It needs no remote and no pushed commit. Run it here, not after the push: 5.13.0 found three blockers only after its first curated push (#1712), when the release commit was already on `main`, and the fixes took two more MRs (!223, !224). A red probe here is fixed before anything leaves this machine.
+   - **Host:** `win-wsl` is where the 5.13.0 red-proof and the green probe ran (#1712); the m5 gate timed out during that release. A host that is unknown, not ready or falls back exits 2 and writes no receipt. If win-wsl is asleep, run `node scripts/snapshot-probe.mjs --host m5-remote --json` only while the offload banner shows m5 without load. `--local` only with the owner's explicit consent: full suites do not run on the M4.
+   - **Receipt:** only a run with a suite step writes one, at `.orchestrator/tmp/snapshot-probe/<tree>.json`. It is keyed by the snapshot **tree**: a commit that changes only excluded files keeps it valid; any change to a public file, a test or the export policy invalidates it. `--check` row `snapshot-probe` reads it and never runs the suite itself.
+6. **Push** to **both** remotes — under `mirror: curated` the second "push" is the curated snapshot from `/close`, never a plain push of `main` (session-end § 4.4 refuses it).
+7. **CI green — on the commit that will be published, on BOTH platforms.** Not on its predecessor: a green pipeline from before step 4's commit is evidence about a different tree. And not on GitLab alone — `--check` carries two CI rows, `ci-green-on-head` (GitLab, via `origin`) and `ci-green-on-head-github` (the mirror). The GitLab pipeline is Linux-only; the **macOS** matrix leg exists solely in `.github/workflows/test.yml`, i.e. on the operator's own platform. The github row self-disables (`skipped — no github remote`) in a checkout without a mirror, and fails on `unknown`/`degraded` exactly like the GitLab one — "could not read the mirror" is not "the mirror is green".
+8. **Preflight.** `node scripts/release.mjs --check --json` — every row green. Run this after the release commit is pushed and its CI succeeds: the preflight requires a clean working tree, HEAD parity on both remotes (on GitHub under `mirror: curated`: the snapshot's `Source-Commit` trailer, row `head-pushed-github`) and green CI on that commit (on GitHub under `mirror: curated`: on the snapshot). It derives its target from `package.json`, so checking the pre-bump version instead produces registry- and tag-collision failures.
+9. **Publish.** `node scripts/release.mjs --publish` — **give it ≥600 s of wall clock, or run it in the background.** The script sets no spawn timeout on purpose (a kill mid-`npm publish` or mid-push is the very failure the receipt boundary exists to avoid), and the tail is slow by construction: each of the two `git push` remotes re-runs the husky pre-push full gate, plus up to 120 s of live-site polling. A 3-minute default command timeout kills it mid-tail.
 
-   The target-confirmed npm receipt is the irreversible boundary. Before that receipt, any failure aborts normally. After it, never rerun `--publish`: the script writes the publish proof `.orchestrator/runtime/release-<target>.json` (checked archive sha256 + sha512 integrity, receipt time, commit, tag), and a registry availability timeout/query/wait failure is reconciliation while the script still tags, pushes `main` + tag to both remotes, handles the GitHub release, and polls the live site. If tag/push fails after the receipt, the dependent GitHub-release and site steps are skipped and the script returns structured reconciliation guidance instead. Add the GitHub release for the new tag (`gh release create`) as part of this step, not "later" — "later" is what produced the three-second backfill above.
+   The target-confirmed npm receipt is the irreversible boundary. Before that receipt, any failure aborts normally. After it, never rerun `--publish`: the script writes the publish proof `.orchestrator/runtime/release-<target>.json` (checked archive sha256 + sha512 integrity, receipt time, commit, tag), and a registry availability timeout/query/wait failure is reconciliation while the script still tags, pushes `main` + tag to both remotes (under `mirror: curated`: `main` + tag to `origin`, the verified snapshot + a tag on that snapshot to `github`), handles the GitHub release, and polls the live site. If tag/push fails after the receipt, the dependent GitHub-release and site steps are skipped and the script returns structured reconciliation guidance instead. Add the GitHub release for the new tag (`gh release create`) as part of this step, not "later" — "later" is what produced the three-second backfill above.
 
-Steps 2–7 are one continuous act. A release left parked between step 4 and step 7 is exactly the `3.18.0` state: every surface says released, the registry disagrees.
+Steps 2–9 are one continuous act. A release left parked between step 6 and step 9 is exactly the `3.18.0` state: every surface says released, the registry disagrees.
 
 ## Abort criteria
 
@@ -59,8 +64,11 @@ Steps 2–7 are one continuous act. A release left parked between step 4 and ste
 | Signal | Why it stops the release |
 |---|---|
 | Any red row in `--check` | The preflight is the gate. A red row is a fact about this tree, not a formality. |
-| `github/main` behind `origin/main` or `HEAD` | The mirror carries the site deploy and the GitHub release. Publishing over a lagging mirror is how the site falls a release behind. |
+| `github/main` behind `origin/main` or `HEAD` (under `mirror: curated`: its `Source-Commit` trailer is not `HEAD`, or it carries none) | The mirror carries the site deploy and the GitHub release. Publishing over a lagging mirror is how the site falls a release behind. |
+| `github-push-url` red: the push URL of `github` differs from its fetch URL (`pushurl`/`pushInsteadOf`, e.g. the #1631 push lock) | Every github check reads the fetch URL; the push would go elsewhere. The publish tail refuses it too, but only after npm publish — unrecoverable then. |
+| `snapshot-probe` red: no receipt for `HEAD`'s export tree, a red step, or no suite step (`test`/`remote-gate`) | The exported tree differs from the private one; only a suite run on it proves the public mirror is green. A validate-plugin-only receipt ran no test. The detail names the fix: `node scripts/snapshot-probe.mjs --host <alias>`. |
 | `npm whoami` returns nothing or non-zero | The token is dead or absent. Publishing proceeds far enough to fail loudly *after* surfaces are committed. |
+| `npm-token-publish` red: the token in use lacks Bypass-2FA, write, scope or has expired (read from `npm token list`) | `whoami` was green for 5.13.0 and publish still died with EOTP. See `skills/npm-publish/SKILL.md` § Token requirements. |
 | CI not green on the exact commit being published (`ci-green-on-head`) | Green-on-the-previous-commit is the silent-regression class this repo exists to catch. |
 | GitHub mirror CI not green (`ci-green-on-head-github`) | The GitLab pipeline is Linux-only; the macOS matrix leg runs only on the mirror, and macOS is the operator's own platform. An `unknown`/`degraded` reading stops the release too — it means the mirror was never read. Only a checkout with no `github` remote passes this row, as `skipped`. |
 | `--skip-ci` together with `--publish` | **Refused by the script** (`validateFlags`), not merely discouraged. `--skip-ci` marks the CI row green without checking anything; a green tick that verified nothing must never authorise an irreversible publish. It is an inspection aid for `--check`, never a release path. |