session-orchestrator 5.12.0 → 5.13.0

package/skills/discovery/probes/supply-chain-slopcheck.mjs

@@ -35,6 +35,7 @@
 
 import { existsSync, readFileSync } from 'node:fs';
 import { join } from 'node:path';
+import { fileURLToPath, pathToFileURL } from 'node:url';
 
 // ---------------------------------------------------------------------------
 // Constants
@@ -188,15 +189,16 @@ function extractCargoPackages(filePath) {
  * Attempt to dynamically import classifyPackages from slopcheck.mjs.
  * Returns null if the module is unavailable (Agent A not yet committed).
  *
- * @param {string} repoRoot
  * @returns {Promise<Function|null>}
  */
-async function loadClassifyPackages(repoRoot) {
-  const slopcheckPath = join(repoRoot, 'scripts', 'lib', 'slopcheck.mjs');
+async function loadClassifyPackages() {
+  // slopcheck.mjs ships with the PLUGIN: resolve it from this module, never
+  // from the scanned repoRoot (#1653 — absent in every consumer repo).
+  const slopcheckPath = fileURLToPath(new URL('../../../scripts/lib/slopcheck.mjs', import.meta.url));
   if (!existsSync(slopcheckPath)) return null;
 
   try {
-    const mod = await import(slopcheckPath);
+    const mod = await import(pathToFileURL(slopcheckPath).href);
     if (typeof mod.classifyPackages !== 'function') {
       return null;
     }
@@ -319,7 +321,7 @@ export default async function supplyChainSlopcheck({ repoRoot }) {
 
   // ── 4. Load classifyPackages (defensive) ──────────────────────────────────
 
-  const classifyPackages = await loadClassifyPackages(repoRoot);
+  const classifyPackages = await loadClassifyPackages();
 
   if (!classifyPackages) {
     return {
@@ -333,11 +335,11 @@ export default async function supplyChainSlopcheck({ repoRoot }) {
             registry: 'internal',
             classification: 'SKIPPED',
             evidence: null,
-            file: join(repoRoot, 'scripts', 'lib', 'slopcheck.mjs'),
+            file: 'scripts/lib/slopcheck.mjs',
           },
           recommendation:
-            'scripts/lib/slopcheck.mjs has not been committed yet. ' +
-            'Re-run /discovery after the slopcheck module is available.',
+            'scripts/lib/slopcheck.mjs is missing from the plugin install. ' +
+            'Reinstall or update the plugin.',
         },
       ],
       summary: {

package/skills/discovery/probes/vault-narrative-staleness.mjs

@@ -18,13 +18,17 @@
  *   age_days > T * 2  → medium
  *   age_days > T      → low
  *
+ * Passive projects (`_passive.md` marker, #1690) are skipped entirely and
+ * counted in `metrics.passive_skipped` (also in the JSONL record).
+ *
  * Missing `updated` field → low / confidence 0.7.
  * Parse errors           → low / confidence 0.6 (errors counter incremented).
  */
 
 import { existsSync, readFileSync, readdirSync, mkdirSync, appendFileSync } from 'node:fs';
-import { join } from 'node:path';
+import { dirname, join } from 'node:path';
 import { expandTilde } from '../../../scripts/lib/common.mjs';
+import { resolveLedgerPath } from '../../../scripts/lib/ledger-path.mjs';
 
 // ---------------------------------------------------------------------------
 // Constants
@@ -32,6 +36,10 @@ import { expandTilde } from '../../../scripts/lib/common.mjs';
 
 const NARRATIVE_FILES = ['context.md', 'decisions.md', 'people.md'];
 
+// Vault convention: `01-projects/<slug>/_passive.md` = no narrative duty.
+// Same marker the vault-staleness probe (#1238) and vault-lint honour.
+const PASSIVE_MARKER = '_passive.md';
+
 const TIER_THRESHOLDS = {
   top: 30,
   active: 60,
@@ -109,8 +117,8 @@ function computeSeverity(ageDays, threshold) {
   return 'low';
 }
 
-function makeMetricsPath(projectRoot) {
-  return join(projectRoot, '.orchestrator', 'metrics');
+function makeLedgerPath(projectRoot) {
+  return resolveLedgerPath('.orchestrator/metrics/vault-narrative-staleness.jsonl', projectRoot);
 }
 
 // ---------------------------------------------------------------------------
@@ -131,7 +139,7 @@ export async function runProbe(projectRoot, config) {
     if (!vaultDir) {
       return {
         findings: [],
-        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 0 },
+        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 0, passive_skipped: 0 },
         duration_ms: Date.now() - startMs,
         skipped_reason: 'vault-dir not configured',
       };
@@ -141,7 +149,7 @@ export async function runProbe(projectRoot, config) {
     if (!existsSync(vaultDir)) {
       return {
         findings: [],
-        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 0 },
+        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 0, passive_skipped: 0 },
         duration_ms: Date.now() - startMs,
         skipped_reason: 'vault-dir not found on disk',
       };
@@ -153,7 +161,7 @@ export async function runProbe(projectRoot, config) {
     if (!existsSync(projectsDir)) {
       return {
         findings: [],
-        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 0 },
+        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 0, passive_skipped: 0 },
         duration_ms: Date.now() - startMs,
         skipped_reason: '01-projects not found in vault',
       };
@@ -166,6 +174,7 @@ export async function runProbe(projectRoot, config) {
     let scannedNarratives = 0;
     let staleNarratives = 0;
     let errors = 0;
+    let passiveSkipped = 0;
 
     let projectEntries;
     try {
@@ -173,7 +182,7 @@ export async function runProbe(projectRoot, config) {
     } catch (err) {
       return {
         findings: [],
-        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 1 },
+        metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 1, passive_skipped: 0 },
         duration_ms: Date.now() - startMs,
         skipped_reason: `cannot read 01-projects: ${err.message || err}`,
       };
@@ -184,6 +193,14 @@ export async function runProbe(projectRoot, config) {
       const slug = entry.name;
       const projectDir = join(projectsDir, slug);
 
+      // #1690 — a passive project carries no narrative duty, so its narratives
+      // are not findings. Skipped before any read, but COUNTED so the skip is
+      // visible rather than indistinguishable from a healthy project.
+      if (existsSync(join(projectDir, PASSIVE_MARKER))) {
+        passiveSkipped++;
+        continue;
+      }
+
       scannedProjects++;
 
       const tier = readTier(projectDir, slug);
@@ -310,11 +327,13 @@ export async function runProbe(projectRoot, config) {
       scanned_narratives: scannedNarratives,
       stale_narratives: staleNarratives,
       errors,
+      passive_skipped: passiveSkipped,
     };
 
     // ── JSONL append ──────────────────────────────────────────────────────────
     try {
-      const metricsDir = makeMetricsPath(projectRoot);
+      const ledgerPath = makeLedgerPath(projectRoot);
+      const metricsDir = dirname(ledgerPath);
       if (!existsSync(metricsDir)) mkdirSync(metricsDir, { recursive: true });
       const record = {
         timestamp: new Date().toISOString(),
@@ -325,6 +344,7 @@ export async function runProbe(projectRoot, config) {
         scanned_narratives: scannedNarratives,
         stale_narratives: staleNarratives,
         errors,
+        passive_skipped: passiveSkipped,
         duration_ms: durationMs,
         findings: findings.map((f) => ({
           slug: f.evidence.slug,
@@ -336,7 +356,7 @@ export async function runProbe(projectRoot, config) {
         })),
       };
       appendFileSync(
-        join(metricsDir, 'vault-narrative-staleness.jsonl'),
+        ledgerPath,
         JSON.stringify(record) + '\n',
         'utf8',
       );
@@ -349,7 +369,7 @@ export async function runProbe(projectRoot, config) {
     // Top-level safety net — probe must never throw
     return {
       findings: [],
-      metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 1 },
+      metrics: { scanned_projects: 0, scanned_narratives: 0, stale_narratives: 0, errors: 1, passive_skipped: 0 },
       duration_ms: Date.now() - startMs,
       skipped_reason: `probe error: ${err.message || err}`,
     };

package/skills/discovery/probes/vault-staleness.mjs

@@ -37,8 +37,9 @@
  */
 
 import { existsSync, readFileSync, readdirSync, mkdirSync, appendFileSync } from 'node:fs';
-import { join } from 'node:path';
+import { dirname, join } from 'node:path';
 import { expandTilde } from '../../../scripts/lib/common.mjs';
+import { resolveLedgerPath } from '../../../scripts/lib/ledger-path.mjs';
 
 // ---------------------------------------------------------------------------
 // Minimal YAML frontmatter parser — top-level scalar fields only (<30 lines).
@@ -302,9 +303,10 @@ export async function runProbe(projectRoot, config) {
       })),
     };
     try {
-      mkdirSync(join(projectRoot, '.orchestrator/metrics'), { recursive: true });
+      const ledgerPath = resolveLedgerPath('.orchestrator/metrics/vault-staleness.jsonl', projectRoot);
+      mkdirSync(dirname(ledgerPath), { recursive: true });
       appendFileSync(
-        join(projectRoot, '.orchestrator/metrics/vault-staleness.jsonl'),
+        ledgerPath,
         JSON.stringify(record) + '\n'
       );
     } catch {

package/skills/discovery/probes-session.md

@@ -485,6 +485,9 @@ const files = readdirSync(dir).filter(f => f.endsWith('.md'));
 let hasErrors = false;
 for (const f of files) {
   const result = validateAgentFile(join(dir, f));
+  for (const w of result.warnings ?? []) {
+    console.log('WARN: ' + f + ' - ' + w.path + ' (' + w.rule + '): ' + w.message);
+  }
   if (!result.ok) {
     hasErrors = true;
     console.log('INVALID: ' + f);

package/skills/discovery/probes-vault.md

@@ -67,6 +67,8 @@ if (r.skipped_reason) console.log('SKIPPED:', r.skipped_reason);
 
 **Tier thresholds (days):** top=30, active=60, archived=180. Tier sourced from `_overview.md` frontmatter; defaults to `active` if missing.
 
+**Passive skip (#1690):** same marker and form as vault-staleness — a `01-projects/<slug>/` carrying `_passive.md` is skipped BEFORE any narrative is read, excluded from `scanned_projects` and counted in `metrics.passive_skipped` (same key in the JSONL record), so the skip stays visible.
+
 ---
 
 **Session-end integration:** When `vault-staleness.enabled: true` in Session Config, these same probes are also invoked at session-end Phase 2.3 — see `skills/session-end/SKILL.md` for the gating logic and strict-mode override behavior. The `/discovery vault` invocation here is the on-demand discovery path; Phase 2.3 is the close-time gate.

package/skills/dispatcher/SKILL.md

@@ -161,7 +161,7 @@ With the lease held, routing splits on whether the chosen entry is model-invocab
 ## Phase 5: Edge cases
 
 - **No free candidate** (`recommended === null` / `free` empty) → report "all repos busy", and offer `resume` (an in-progress session) or `wait` via AUQ. **Never force a selection** of a busy repo.
-- **vault off / glab missing** → degrade per the `warnings` array: rank on staleness × readiness only, surface the warning, continue. A missing CLI is never fatal.
+- **glab/gh missing or timed out** → the PRIORITY signal (open critical/high backlog counts via `scanBacklog`, `scripts/lib/dispatcher/rank.mjs`) falls back to a neutral 1 and a `warnings` entry says so: the repo is ranked on staleness × readiness only, surface the warning, continue. A missing CLI is never fatal. Ranking does not read the vault, so `vault-integration` off changes nothing here.
 - **Host resource probe failed** → readiness is scored without resource dampening (a warning says so); ranking still completes.
 - **Bad `--start-dir`** → CLI exits 1 (user/input error); fix the path and re-run.
 

package/skills/eval/SKILL.md

@@ -177,6 +177,7 @@ coordinator thread using the read-only agent `session-orchestrator:eval-judge`
 ```javascript
 import { runEvalJudge, mergeJudgeDimensions } from '$PLUGIN_ROOT/scripts/lib/eval/judge.mjs';
 import { appendEvalRecord } from '$PLUGIN_ROOT/scripts/lib/eval/sink.mjs';
+import { resolveLedgerPath } from '$PLUGIN_ROOT/scripts/lib/ledger-path.mjs';
 
 // dispatchAgent = the coordinator's Agent-tool dispatch closure targeting
 // subagent_type 'session-orchestrator:eval-judge'.
@@ -191,7 +192,8 @@ const { status, dimensions } = await runEvalJudge({
 const merged = mergeJudgeDimensions(record, dimensions);
 
 // The COORDINATOR appends the enriched record (subagents never write the journal).
-appendEvalRecord(merged, { path: '.orchestrator/metrics/eval.jsonl' });
+// In a linked worktree the main checkout's journal when it is gitignored there (#1722).
+appendEvalRecord(merged, { path: resolveLedgerPath('.orchestrator/metrics/eval.jsonl', process.cwd()) });
 ```
 
 - The judge dimension arrives `advisory: true` + `calibration_status:

package/skills/evolve/SKILL.md

@@ -100,6 +100,8 @@ Route based on mode:
 
 Extracts learnings from session history: pattern extraction across the 9 built-in analyzer types plus `evolve.extra-sources`, deduplication, relation judgment (#1016), the AskUserQuestion confirmation gate, and the archive-safe write pipeline (through the C2 auto-repair feeder). See [references/evolve-analyze-mode.md](references/evolve-analyze-mode.md). **Read WHEN:** Phase 2's Mode Dispatch routes to `analyze` (the default mode).
 
+**Agent-usage census (#1617).** Before extraction, run `node "${CLAUDE_PLUGIN_ROOT:-${CODEX_PLUGIN_ROOT:-$PLUGIN_ROOT}}/scripts/agent-usage-census.mjs" --days 14` (read-only over `~/.claude/projects` subagent transcripts, ~20 s for 14 days). Report the model shares and the top agent types (runs, turns/run, output/run, cache rebuilds, start context) in the analyze summary, and quote `malformed_lines`. It is an observation, not a learning source: nothing is written from it, and a shift (a type moving model, a new dominant type) goes to the operator as a finding. Housekeeping step 4 runs `/evolve analyze`, so the weekly maintenance loop carries the census without a second entry.
+
 ---
 
 ## Phase 4: Review Mode

package/skills/evolve/references/evolve-analyze-mode.md

@@ -51,7 +51,7 @@ For each of the 9 built-in analyzer learning types, apply these heuristics.
 
 - `waves[].files_changed` is a COUNT (a number), never a list of paths — do not iterate it (#1321). File identity comes from git, the method of `skills/session-end/learning-patterns.md:13`, run per session over its commit range:
   `git log --name-only --format="" <session_start_ref>..<end_ref> | sort | uniq -c | sort -rn`
-  with `<end_ref>` = the record's `end_ref` / `session_end_ref`; when neither exists use `HEAD` plus `--until=<completed_at>`. Records without `session_start_ref` fall back to `git log --name-only --format="" --since=<started_at> --until=<completed_at>`.
+  with `<end_ref>` = the record's `end_ref` / `session_end_ref`; when neither exists use `HEAD` plus `--until=<completed_at>`. When the record carries `session_work_trees: [{tree, start_ref}]`, run the same log once per entry, each inside its own tree (`git -C <tree> log …`) with its own ref — never apply one tree's ref in another tree — and add the results to the counts. Records without `session_start_ref` fall back to `git log --name-only --format="" --since=<started_at> --until=<completed_at>`.
 - **Prefer the ref range; label the fallback.** Only 26 of 201 real records carry `session_start_ref` (measured 2026-09-12), so most analyses land on the time-window fallback. That window also picks up commits a PARALLEL session made on the same branch in the same hours — it attributes foreign commits to this session. Use the ref range wherever the record has one, and mark every candidate whose evidence came from the fallback as `window: time (unattributed)` in its `evidence`.
 - Within a session: a file changed in 3+ commits of that session's range is fragile. Here the population rule's `n` counts the **commits in that session's range**, not records — one session is always one record, so counting records would WARN on every within-session check
 - Cross-session: if a file appears in 3+ different sessions' ranges, flag it
@@ -60,7 +60,7 @@ For each of the 9 built-in analyzer learning types, apply these heuristics.
 #### 2. effective-sizing (type: `effective-sizing`)
 
 - Compare `total_agents` and `total_waves` across session types
-- Calculate average agents per wave for each session type. Read a wave's agent count defensively — older records use other keys: `agent_count`, else `agents` when it is a number, else the length of `agents` when it is an array (of descriptions), else `agents_dispatched`. A record with `total_waves: 0` contributes no per-wave ratio — skip it rather than divide by zero. Exclude coordinator-direct waves (`coordinator_direct: true`, which dispatched no agents) from the ratio. In particular, a record whose waves are all coordinator-direct `Housekeeping` waves (predicate `isCoordinatorDirectHousekeeping` in `scripts/lib/session-schema/filters.mjs`, the session-end writer shape since #1321) contributes no per-wave ratio, same as `total_waves: 0`. Counting it would log a false 0.0 agents-per-wave observation.
+- Calculate average agents per wave for each session type. Read a wave's agent count with `waveAgentCount(wave)` (`scripts/lib/session-schema/filters.mjs`) — older records use other keys: `agent_count`, else `agents` when it is a number, else the length of `agents` when it is an array (of descriptions), else `agents_dispatched`, else `agent_count_started` / `agents_started`; no key → unmeasured, skip the wave. A record with `total_waves: 0` contributes no per-wave ratio — skip it rather than divide by zero. Exclude coordinator-direct waves from the ratio with `isCoordinatorDirectWave(wave)`: `coordinator_direct: true` OR a measured count of 0 without the flag (#1652 — 222 of 238 0-agent waves in this ledger carry no flag, measured 2026-10-17; excluding only flagged waves lowered the average from 3.92 to 2.96). When a candidate reports per-role numbers, group roles by `normalizeWaveRole(role)` (case- and separator-insensitive: `Finalization`/`finalization`, `Express-Path`/`Express Path` are one role). In particular, a record whose waves are all coordinator-direct `Housekeeping` waves (predicate `isCoordinatorDirectHousekeeping` in `scripts/lib/session-schema/filters.mjs`, the session-end writer shape since #1321) contributes no per-wave ratio, same as `total_waves: 0`. Counting it would log a false 0.0 agents-per-wave observation.
 - **Group by `(session_type, session_profile)` (#1247), never by `session_type` alone.** `ultradeep` is a PROFILE over `session_type: deep` (7 waves vs. deep's 4-5, STATE.md frontmatter key `session-profile` — see `scripts/lib/state-md.mjs`), not a distinct type, so a bare `session_type` grouping folds a 7-wave ultradeep session and a 5-wave deep session into the same row and silently averages their agents-per-wave numbers together.
 - Subject = `sizingSubject({ session_type, session_profile })` from `scripts/lib/learnings/sizing-subject.mjs` — e.g. `deep-session-sizing` (no profile, byte-identical to the pre-#1247 literal), `deep-ultradeep-session-sizing` (profile `ultradeep`), or `feature-session-sizing`. Always derive via this helper; do not hand-concatenate the subject string.
 - Insight = "Deep sessions average X agents across Y waves" or "Ultradeep sessions average X agents across Y waves" (name the profile in the insight whenever `session_profile` is present, so the two rows read as distinct sizing observations, not variants of one sentence)
@@ -105,7 +105,7 @@ For each of the 9 built-in analyzer learning types, apply these heuristics.
 - Five detection signals (aggregated per `(signal, host_class)` pair, ≥2 occurrences required):
   - **oom-kill** — `orchestrator.turn.stopped` (or its deprecated alias `orchestrator.session.stopped`, which `hooks/on-stop.mjs` still emits with `deprecated: true` until **2027-03-06**) with `exit_code: 137` or OOM-marker in `error`. Both names are accepted for the deprecation window because every OOM record already on disk carries only the legacy name; the detector's set lives in `OOM_TERMINAL_EVENTS` (`scripts/lib/hardware-pattern-detector.mjs`) and drops the alias on that date.
   - **heartbeat-gap** — registry sweep-log entries with `gap_minutes` above `resource-thresholds.zombie-threshold-min`
-  - **concurrent-session-pressure** — session-start events with `peer_count ≥ concurrent-sessions-warn`
+  - **concurrent-session-pressure** — session-start events inside a start wave: `recent_starts_count ≥ 5` foreign starts in the preceding 5 min (`DEFAULT_THRESHOLDS.startWaveMin`, mirrors `START_WAVE_MIN` in `hooks/on-session-start.mjs`). Re-aimed in #1654 off `peer_count ≥ concurrent-sessions-warn`, which held on 67.4% of M4 starts (a standing condition, HR-101). Events without a numeric `recent_starts_count` (all pre-#1650 records) are skipped, never counted. Not fed from `concurrent-sessions-warn`.
   - **disk-full** — events whose `error` matches `ENOSPC` / "no space left"
   - **thermal-throttle** — events whose `resource_snapshot.cpu_load_pct` crosses `cpu-load-max-pct`
 - Each candidate is piped through `candidateToLearning()` → `validateLearning()`. Default `scope` is `private` (in-repo only). To promote to `public`, the user runs `npm run share:hw-learnings -- --promote` (C3 export). This anonymizes each `private` hardware-pattern entry, validates via the privacy contract, and appends a `public` twin to `learnings.jsonl` (original preserved). Use `--dry-run` to preview without writing.

package/skills/evolve/references/evolve-dialectic-mode.md

@@ -103,7 +103,7 @@ const result = await runDialecticDeriver({
   | Text before the first `## ` heading | — | NOT applied | `preamble` + a `{ type: 'unmapped-preamble' }` entry in `conflicts[]` |
   | Falls inside an existing managed region that wraps MORE than one `## ` heading | — | NOT applied — the region stays byte-unchanged (no replace, which would delete its sibling headings' hand-written text; no append, which would duplicate the heading) | `{ type: 'multi-heading-region', region, headings, skipped }` in `conflicts[]` — `region` is the region's section name, `headings` the `## ` headings it wraps, `skipped` the proposed headings dropped. Operator action: split the region by hand into one managed region per heading, then re-run — or discard the proposal for those headings |
 
-  Existing names are read back out of the card rather than re-derived because the live names are not a pure function of their headings — measured 2026-09-11 in `.orchestrator/peers/AGENT.md`: `## Guard and protocol-migration discipline` → `guard-and-protocol-migration`. Re-slugifying would APPEND a duplicate section instead of replacing one.
+  Existing names are read back out of the card rather than re-derived because the live names are not a pure function of their headings — measured 2026-09-11 in this repo's `AGENT.md` peer card: `## Guard and protocol-migration discipline` → `guard-and-protocol-migration`. Re-slugifying would APPEND a duplicate section instead of replacing one.
 
   **Present `conflicts[]` before writing.** A non-empty `conflicts[]` (`duplicate-section`, `orphan-begin`, `unmapped-preamble`, `multi-heading-region`) is operator-visible content that the merge did not place — report it beside the delta line rather than writing silently.
 - **Close the loop — after a successful `--apply` AND after the operator explicitly discards a reviewed proposal** (never after a dry-run, a failure, a skip, or the drift-check's "keep the sidecar for another review" branch above): record the run and consume the sidecar, both from `scripts/lib/auto-dialectic.mjs`. Without these two calls the maintenance-due probe keeps `dialectic` (measured against `.orchestrator/dialectic-last-run`) and `pending-sidecar` (`.orchestrator/dialectic-pending.md` younger than 14 days) due forever — nothing else writes the one or moves the other (#1380). Both return `{ ok, error? }` and never throw; log a failure and continue. Since #1388 `consumeDialecticPending` MOVES the sidecar to `.orchestrator/consumed/<timestamp>-dialectic-pending.md` (newest 10 retained) instead of deleting it, so the reviewed text survives the apply; `archivedTo` on the result names the file. <!-- path-check: example -->

package/skills/gitlab-ops/SKILL.md

@@ -111,8 +111,8 @@ done
 **Taxonomy convention — `priority` REVERSED to scoped `::` (supersedes #727 for this one axis).**
 
 - **`priority::<level>` is canonical.** #727's stated rationale was that "this repo mirrors to GitHub, which has no scoped-label semantics … while a migration would break every existing label reference and issue." Both halves were checked on 2026-07-25 and neither holds:
-  - **Issues are not mirrored at all.** `aiat-poc-infra/docs/github-mirror-runbook.md:1,5` describes a git **push-mirror** with GitHub as "read-only downstream"; the external team-organization audit `docs/gitlab-team-org-2026-06-21.md:45` confirms there is no two-way GitLab issue sync. Nothing crosses the boundary that a label rename could break. <!-- path-check: example -->
-  - **GitHub already uses the scoped form.** `gh api "repos/AIAT-AIandBusinessgrowth/aiat-barrierefrei-engine/labels"` returns `priority::high`, `priority::low`, `priority::med`, `priority::medium` across 77 open issues, and **zero** `priority:high`. Same pattern on `aiat-doc-vlm`. GitHub treats `::` as an ordinary string; it merely does not enforce mutual exclusion.
+  - **Issues are not mirrored at all.** A consumer infra repo's GitHub-mirror runbook describes a git **push-mirror** with GitHub as "read-only downstream"; the external team-organization audit `docs/gitlab-team-org-2026-06-21.md:45` confirms there is no two-way GitLab issue sync. Nothing crosses the boundary that a label rename could break. <!-- path-check: example -->
+  - **GitHub already uses the scoped form.** On a GitHub consumer repo, `gh api "repos/<owner>/<repo>/labels"` returns `priority::high`, `priority::low`, `priority::med`, `priority::medium` across 77 open issues, and **zero** `priority:high`. Same pattern on a second consumer repo. GitHub treats `::` as an ordinary string; it merely does not enforce mutual exclusion.
   - Volume agrees independently: **416 `priority::` against 249 `priority:` and 7 bare** at the time of the decision. Chasing the minority spelling would mean re-labelling the majority.
   Producers were migrated FIRST (this change); the label-data migration follows separately, because migrating data before producers means the divergence returns within a day.
 - **`area:` / `type:` / `status:` / `from:` stay SINGLE-COLON** — but NOT on #727's rationale, which is disproven above. They stay because nothing measured argues for flipping them, and because each axis is its own migration cost. Flipping them is a separate decision and is explicitly NOT made here. Note that `status` in particular is the worst-disciplined axis on the instance (354 assignments, only 48 percent scoped, 5 genuine value conflicts), so any future flip there needs a conflict-resolution pass first.
@@ -355,9 +355,10 @@ Accepted template paths are configured in `.orchestrator/policy/templates-policy
 
 1. **Read the template first** — re-run the `create` call after a `Read` on the template
    path; the hook re-evaluates and sees the Read.
-2. **Session acknowledgement** — write `.orchestrator/runtime/templates-acknowledged.json`
-   containing `{ sessionId, acknowledgedAt }`; the hook allows all subsequent `create`
-   calls in this session.
+2. **Session acknowledgement** — run `/templates-ack [reason]` (`commands/templates-ack.md`);
+   it verifies the invoking session before recording the acknowledgement, and the hook
+   then allows all subsequent `create` calls in this session. Never write the
+   acknowledgement file by hand — that skips the command's session check.
 
 **What the hook mechanically enforces** (what this skill previously documented as convention only):
 
@@ -391,6 +392,6 @@ gh pr create -R <OWNER>/<REPO> --title "..." --body "..."
 - Hook implementation: `hooks/pre-bash-templates-first.mjs`
 - Read-history helper: `hooks/_lib/transcript-history.mjs` (checks session transcript for prior Reads)
 - Enforcement policy: `.orchestrator/policy/templates-policy.json`
-- Session acknowledgement: `.orchestrator/runtime/templates-acknowledged.json`
+- Session acknowledgement: `/templates-ack` (`commands/templates-ack.md`), the only sanctioned writer
 - Sister hook (destructive-command model): `hooks/pre-bash-destructive-guard.mjs`
 - PRD: "gsd Pattern Adoption Quick-Wins" (#519; archived in the private Meta-Vault) § Pattern 3 + § 3 Gherkin Pattern 3

package/skills/gitlab-portfolio/SKILL.md

@@ -185,9 +185,9 @@ repos: 2
 
 ## Error handling
 
-Behaviour is governed by `mode`. `warn`: emit warning to stderr, continue with partial data; repo rows show `(fetch failed)`. `strict`: any repo fetch failure or missing vault-dir exits 3 immediately. `off`: all errors are silently swallowed, partial data written.
+Behaviour is governed by `mode`. `warn`: emit warning to stderr, continue with partial data; repo rows show `(fetch failed)`. `strict`: any repo fetch failure exits 2 after the scan. `off`: the CLI exits 0 with one line before resolving the vault-dir or scanning any repo, and writes nothing (#1619).
 
-`--vault-dir` not found and write errors always exit 2 regardless of `mode`. `_PORTFOLIO.md` with no `_generator` key always results in `skipped-handwritten` (all modes). No repos discovered: `warn` → exit 0 (no file written); `strict` → exit 3.
+`--vault-dir` not found and write errors always exit 2 regardless of `mode`. `_PORTFOLIO.md` with no `_generator` key always results in `skipped-handwritten` (all modes). No repos discovered: exit 0 in every mode (no file written).
 
 ## Anti-Patterns
 

package/skills/go/SKILL.md

@@ -10,6 +10,17 @@ model: inherit
 
 The user has approved the session plan. Begin execution immediately.
 
+## No plan to execute
+
+Before executing either path below, check for a plan. A plan exists when either holds:
+
+- the conversation — including a context-compaction summary — contains a session-plan result that offers `Use /go to begin.` (wave plan or Express Path plan);
+- `<state-dir>/STATE.md` has `status: active` or `status: paused` and its frontmatter `session-id` (the raw harness id) equals this process's own raw id — `readProcessLocalSessionIds()` in `scripts/lib/session-identity/own-session.mjs` (Claude Code: `$CLAUDE_CODE_SESSION_ID`; `readInvocationSessionId()` there is the ancestor-process proof). That is an interrupted wave execution of this session; the raw id survives a context compaction.
+
+Never decide this by the labels STATE.md `session`, `semantic_session_id` or `.orchestrator/current-session.json`: they are repo-wide, and a peer session started later in the same repo owns them (`skills/_shared/state-ownership.md` § Session Identity and Lock Ownership). A STATE.md without `session-id`, without a measurable own id, or not `active`/`paused` proves nothing: session-plan does not write it, and the wave-executor sets `status: active` only when execution starts. If neither holds, print the line `/go: kein Plan vorhanden – nichts ausgeführt` and end the answer with the wait sentence `Ich warte auf den nächsten Auftrag.` (or `Bereit zum Schließen.` when the fleet handover applies) — the status line alone is not recognised as a waiting answer (`skills/_shared/fleet-protocol.md` § Rücklauf an den Navigator, Wartesatz). Do not re-plan or start a new session.
+
+In this no-plan case apply `skills/_shared/fleet-protocol.md` § Rücklauf an den Navigator (Pflicht) with the wait case `go-ohne-plan`: measure fleet and lease read-only (no check-in) and send exactly ONE report in this turn, even if an earlier turn already reported the same case (`SendMessage` with an active, reachable lease; on failure or otherwise a Lead-Todo; if that fails too, `Meldung gescheitert: <Grund>` in the last paragraph) — the session, `/go ohne Plan`, the time from `date`, and what the session needs next. Never wait for a reply (CSM-004). Return without executing work.
+
 ## Invocation
 
 Invoked as `/go [optional instructions]` with arguments: **$ARGUMENTS**. The user has approved the session plan; begin execution immediately.
@@ -38,7 +49,8 @@ If the banner is present (and the session-plan output emitted a 1-wave Express P
    await appendDeviationOnDisk(repoRoot, new Date().toISOString(), 'Express path: <N> tasks executed coord-direct (express-path.enabled: true, session-type: housekeeping, scope: <N> issues)');
    "
    ```
-3. **Invoke `session-orchestrator:session-end`** directly via the `Skill` tool. Session-end finalizes STATE.md (sets `status: completed`, writes `.orchestrator/metrics/sessions.jsonl`, runs vault-mirror if enabled). Without this auto-invocation, every Express Path run leaves no audit trail (issue #320).
+3. **Fleet check (#1620), then close.** Measure fleet integration first with the read-only one-liner in `skills/_shared/fleet-protocol.md` § Rücklauf an den Navigator. On `flotte: true` (fleet integration on this host, with or without an active lease) the session does NOT close itself (fleet-protocol § Übergabe Punkt 4): skip the rest of this step and steps 4–5. Instead give the session summary first, then report the wait case `fertig`, write the hand-over and end the reply with `Bereit zum Schließen.` as its last sentence, per fleet-protocol § Übergabe und Zug-Manifest (the coordinator only reads the last 600 characters). The deviation from step 2 is already on disk; the coordinator triggers `/close`, and the regular session-end flow finalizes STATE.md — the step-4 persistence check does not run on this path. On `flotte: false` continue:
+   **Invoke `session-orchestrator:session-end`** directly via the `Skill` tool. Session-end finalizes STATE.md (sets `status: completed`, writes `.orchestrator/metrics/sessions.jsonl`, runs vault-mirror if enabled). Without this auto-invocation, every Express Path run leaves no audit trail (issue #320).
 4. **Verify persistence after session-end completes:** read `<state-dir>/STATE.md` and confirm `frontmatter.status === 'completed'` and the body's `## Deviations` section contains an `Express path:` entry. If either is missing, warn the user inline with: `⚠ Express Path persistence verification failed — STATE.md not finalized. Re-run /close manually.` Then return the final summary.
 5. **Return** the session summary to the user. The express-path execution is complete.
 

package/skills/npm-publish/SKILL.md

@@ -7,7 +7,7 @@ description: Use when publishing this package to npm — a version release (npm
 
 # npm-publish — token auth, and the calls the script cannot make
 
-> **The release itself is `/release` → `scripts/release.mjs`.** That script mechanizes the whole sequence: version surfaces, CHANGELOG gate, drift sweep, tag/registry collision, CI, leakage gate, publish, the target-confirmed npm receipt boundary, tag-after-receipt, push to both remotes, GitHub-release handling, and live-site poll. This skill does not restate it.
+> **The release itself is `/release` → `scripts/release.mjs`.** That script mechanizes the whole sequence: version surfaces, CHANGELOG gate, drift sweep, tag/registry collision, CI, leakage gate, publish, the target-confirmed npm receipt boundary, tag-after-receipt, push to both remotes (under `mirror: curated` the GitHub side gets the verified export snapshot as main and the tag on that snapshot, never the release commit — `docs/github-mirror-protection.md` § Releases under `mirror: curated`), GitHub-release handling, and live-site poll. This skill does not restate it.
 >
 > What lives here is the half a script cannot own: the **token setup**, the **auth failure diagnosis**, and the **judgement calls** — which version, what a leak means, when to abort rather than repair.
 
@@ -29,6 +29,8 @@ Create at https://www.npmjs.com/settings/<user>/tokens → Generate New Token
 1. `NPM_TOKEN` in `.env.local` at the repo root (gitignored — verify with `git check-ignore .env.local` before writing; also confirm no `.env` pattern in the `files` whitelist of package.json). `scripts/release.mjs` refuses to read the token if that ignore check fails.
 2. Interactive fallback: operator runs `npm publish --access public` in a real terminal (only works when account 2FA is enrolled — OTP prompt appears).
 
+`release --check` verifies the token before any publish: `npm-token-live` (`npm whoami`) proves it authenticates, `npm-token-publish` reads `npm token list --json`, finds the token in use by its abbreviated `npm_xxxx...xxxx` form, and goes red when it lacks `bypass_2fa`, write `permissions`, a matching `scopes` entry, or has passed `expiry`/been `revoked` — the 5.13.0 EOTP case, where `whoami` was green. `npm token list` works with a granular token; `npm profile get` does not (npm 11.19.1, 2026-10-21).
+
 **Never** put the token in the tracked `.npmrc` (it holds `ignore-scripts=true` per SEC-020 and is committed), never persist it into `~/.npmrc`, never echo it into logs.
 
 ## The three judgement calls
@@ -39,7 +41,7 @@ The script gates mechanics. These three are yours, and it will not make them for
 
 **2. What a leak means when one is found.** A hit from the leakage gate is not a pattern to silence. Decide which of two it is: a real leak (fix `package.json` `files`, re-pack, re-check) or genuine over-matching (fix `LEAKAGE_PATTERNS` in `scripts/release.mjs` **with a test**). There is no third option, and neither is "publish anyway and clean it up in the next version" — an npm publish is not revocable, and unpublishing burns the version number permanently. Operator handling detail: `docs/distribution/npm-publish-checklist.md` § 3.
 
-**3. When to abort instead of repair.** Abort — do not patch forward — when the failure is upstream of the target-confirmed npm receipt: a red preflight row, a lagging `github` mirror, CI not green on the exact commit **on either platform** (`--check` carries both `ci-green-on-head` for GitLab and `ci-green-on-head-github` for the mirror, whose macOS matrix leg has no GitLab equivalent), a dead token, or a publish that did not issue the target receipt. These are cheap to fix and re-run from the top. Repair-in-place is only appropriate *after* that receipt, where the version is already immutable: registry availability (`--reconcile`), a missing GitHub release, or a lagging site deploy can be reconciled because npm already has the correct artifact. When `--publish` reports **Post-publish reconciliation required**, **do not rerun `--publish`**; repair the listed state directly. `skills/release/SKILL.md` § Abort criteria is the operative list.
+**3. When to abort instead of repair.** Abort — do not patch forward — when the failure is upstream of the target-confirmed npm receipt: a red preflight row, a lagging `github` mirror (under `mirror: curated`: github/main is not yet the snapshot of the release commit — run `/close` first), CI not green on the exact commit **on either platform** (`--check` carries both `ci-green-on-head` for GitLab and `ci-green-on-head-github` for the mirror, whose macOS matrix leg has no GitLab equivalent), a dead token, or a publish that did not issue the target receipt. These are cheap to fix and re-run from the top. Repair-in-place is only appropriate *after* that receipt, where the version is already immutable: registry availability (`--reconcile`), a missing GitHub release, or a lagging site deploy can be reconciled because npm already has the correct artifact. When `--publish` reports **Post-publish reconciliation required**, **do not rerun `--publish`**; repair the listed state directly. `skills/release/SKILL.md` § Abort criteria is the operative list.
 
 ## Failure-mode table
 
@@ -47,6 +49,7 @@ The script gates mechanics. These three are yours, and it will not make them for
 |---|---|---|
 | `E403 ... Two-factor authentication or granular access token with bypass 2fa enabled is required` — no OTP prompt | Account has no 2FA enrolled AND token (if any) lacks Bypass-2FA | Create granular token with all four requirements above, or enroll 2FA |
 | Same E403 despite a fresh token | Token created without the Bypass-2FA checkbox, or Read-only, or package-scoped on a first publish | Re-create: RW + All packages + Bypass-2FA |
+| `EOTP` from `npm publish` while `npm whoami` is green | Granular token without Bypass-2FA (5.13.0) | Re-create with Bypass-2FA; `release --check` row `npm-token-publish` now catches it before the publish |
 | `npm whoami` silent or non-zero | Token expired, or `.env.local` missing | Re-create the token; do not proceed — the preflight fails this row on purpose |
 | `E404` on `npm view <pkg>@<target>` after a target-confirmed publish receipt (npm answered HTTP 202) | The upload is **accepted, not yet available**. npm scans every new publish before it becomes installable: "typically around five minutes", "up to 15 minutes or more" at peak or depending on content/size, no service guarantee; the outcome may be published, **held for manual review**, or **blocked** (GitHub changelog 2026-07-28, read 2026-10-08, npm CLI 11.19.0). 5.10.0 stayed 404 for more than 25 minutes. A 404 alone does **not** tell you which of these applies — the package token cannot see the scan state | Let the script finish its tag/push/GitHub/site tail, then run `node scripts/release.mjs --reconcile --target <target>` (read-only, resumable; exit 0 only once installable). While still `pending`, check the owner-visible side: npm says a blocked package's publisher "may receive a notification with the option to appeal" — look at the npm account notifications/e-mail of the publishing account and the package page on npmjs.com. Do **not** rerun `--publish` and do not declare it blocked from the 404 |
 | `ENEEDAUTH` | No login/token at all | Token flow above, or `npm login` |

package/skills/plan/SKILL.md

@@ -46,6 +46,7 @@ Interactive sessions are unaffected — `/plan` works there as it always has.
 - `mode-feature.md` — Feature PRD: 2 Q&A waves, compact scope, acceptance criteria
 - `mode-retro.md` — Retrospective: metrics analysis, reflection waves, improvement actions
 - `soul.md` — Product Strategist identity and behavioral anchor
+- `prd-premortem-panel.md` — Phase 4.5 Refute + Deepen briefs (pre-mortem against the code)
 
 ## Soul Reference
 
@@ -125,6 +126,10 @@ Before each Q&A wave, dispatch 2-3 `Agent()` tool calls in a single message (par
 2. **Baseline analysis agent** — reads projects-baseline templates, rules, and scripts at `$BASELINE_PATH` to discover available options (archetypes, styles, configurations). Tools: Read, Glob, Grep.
 3. **Repo context agent** (skip for `/plan new` wave 1) — analyzes the current repository for existing patterns, file structure, dependencies, and conventions. Tools: Read, Glob, Grep.
 
+**Raw material before digest.** Brief the repo and baseline agents to start from the rawest reachable material, not from what has already been summarised: the code path that actually runs (caller census), the installed artifact or platform contract, live event or process data, a real run's output, the git history of the area. Issue text and docs come second. Two asks are mandatory in Wave 1:
+- **Reproduce the premise.** Re-measure the stated problem with a quoted command. If it does not reproduce, record it as a hypothesis in PRD § Evidence Baseline.
+- **Census local equivalents.** What already exists for this need (`build-value.md` BV-001 rung 2)? In 12 measured `/plan` runs the operator corrected 3 options with "that already exists".
+
 Example dispatch:
 
 ```
@@ -138,15 +143,9 @@ Agent({ subagent_type: "Explore", description: "Analyze repo context",
 
 Wait for ALL agents to complete before proceeding. Use `run_in_background: false` for all agents.
 
-### Opportunity Score (Ranking Candidate Subfeatures)
-
-When a Wave 1 "what to build" question surfaces multiple candidate subfeatures (rather than one clear scope), rank the candidates before recommending one. Score each candidate:
-
-```
-Opportunity Score = Importance × (1 − Satisfaction)
-```
+### Ranking Candidate Subfeatures
 
-Both `Importance` and `Satisfaction` are estimated on a 0..1 scale from the Wave 1 research/Explore agent findings (market signal, existing-issue signal, repo-pattern signal) — not asked of the user directly. Rank candidates descending by score; the top-ranked candidate becomes the `(Recommended)` Option 1 in the AskUserQuestion payload for that question. Apply this only when genuinely multiple candidates are surfaced — a single well-defined feature needs no ranking.
+When a Wave 1 "what to build" question surfaces several candidate subfeatures, rank them by measured signal: how often the problem shows up in events, issues or transcripts, and how much each one blocks. Cite the count and the command that produced it. With no measured signal, rank ordinally and say so. Never invent a score. The top candidate becomes the `(Recommended)` Option 1.
 
 ### 3.2 Question Presentation
 
@@ -157,6 +156,7 @@ Synthesize research results into 5 questions per wave. Split across 2 AskUserQue
 - Each option includes a `description` with Pros/Cons drawn from the research
 - Include an "Other" option when custom input makes sense
 - Use `multiSelect: false` unless the question genuinely requires multiple selections
+- If two options are not mutually exclusive (a default plus an opt-in, or both modes behind one switch), offer that combination as an option of its own. In 12 measured runs, 50 of 156 answers were free text, and 17 of those read "as recommended, but …".
 
 Example payload:
 
@@ -237,6 +237,12 @@ Use today's date. Derive the name slug from the project name (for new) or featur
 
 Ensure the target directory exists (create with `mkdir -p` if needed) before writing.
 
+## Phase 4.5: Pre-Mortem Panel (skip for retro mode)
+
+Dispatch the two read-only briefs in `prd-premortem-panel.md`, Refute and Deepen, as two `Agent()` calls in one message. Pass each the PRD path and its brief verbatim. Then merge their reports into the PRD per that file's § Coordinator merge: re-checked predictions go into § Risks, every acceptance criterion gets an `Oracle:` line, and criteria whose oracle cannot run in the implementing session go into § External Acceptance. A raw-material finding that contradicts the PRD's premise goes to the operator before Phase 5.
+
+Why this phase exists: replayed against their later history, three shipped PRDs anticipated 0 of 43 recorded surprises. The two briefs together hit 11 and found different classes (`prd-premortem-panel.md` § Why two briefs). The PRD reviewer below checks form; this panel checks the plan against the code.
+
 ## Phase 3.5: Package Legitimacy Audit (Slopcheck — #520)
 
 > Despite the name, this phase runs *after* Phase 4 (Document Generation) and *before* Phase 5 (PRD Review). The "3.5" identifier is historical, anchored to the PRD's Pattern-2 specification so cross-references stay searchable.
@@ -292,7 +298,7 @@ generation due to slopcheck failure — log + continue.
 
 Dispatch a reviewer subagent: read `prd-reviewer-prompt.md` in this skill directory for review instructions. Pass the full PRD content to the reviewer.
 
-The reviewer checks 7 criteria:
+The reviewer checks 8 criteria:
 1. **Completeness** — all sections filled, no TBD or placeholder content
 2. **Consistency** — no internal contradictions between sections
 3. **Clarity** — unambiguous enough that a developer could implement from this document alone
@@ -300,6 +306,7 @@ The reviewer checks 7 criteria:
 5. **YAGNI** — no unrequested features or gold-plating
 6. **SMART metrics** — success criteria are Specific, Measurable, Achievable, Relevant, Time-bound
 7. **User Stories** (gated — active only when a populated ## User Stories section is present) — section present, every story in one complete form (either the Als/möchte/damit persona form, or the job-story form: "When [situation], I want [motivation], so I can [outcome]"), each story links ≥1 acceptance criterion; SKIP when no User Stories section. No INVEST checks.
+8. **Verifiability**: every acceptance criterion names an `Oracle:` that is not the author's own unit test against a fake. Every External Acceptance row has an owner, a not-before date, a pass condition and a fallback. The Evidence Baseline quotes the command that measured the premise.
 
 ### 5.2 Revision Loop
 
@@ -353,6 +360,8 @@ Do NOT proceed to Phase 6 (Issue Creation) until the generated document (PRD or
 
 Two prior `/plan` sessions filed issues referencing a PRD path that no downstream session could find, because the document was written to disk (Phase 4.3) but never committed (issue #784). This gate closes that gap mechanically, right after user approval (Phase 5) and before any issue is filed (Phase 6). It applies to every mode that reaches Phase 6 — including `/plan retro`, which skips Phase 5's review loop but still saves a document and (conditionally) files issues.
 
+**`/plan new`:** the target repo does not exist until `mode-new.md` Phase 3 creates it, and the directory the planning ran from may not be a repo at all. There, `mode-new.md` Phase 3 Step 6 meets this gate: it copies the PRD into the new repo and commits it, then § 5.5.2 runs against that repo. Phase 6 files issues only after that.
+
 ### 5.5.1 Commit the Document
 
 The Epic issue does not exist yet at this point in the flow — do NOT reference an issue number in the commit message. Use a session-dated message instead:
@@ -399,6 +408,8 @@ The Epic issue's number is not known during § 5.5.1. Once Phase 6 creates it, s
 - **`/plan feature`** — derive from PRD Section 3 (Acceptance Criteria). Each Given/When/Then block becomes a sub-issue. Group under an Epic named after the feature.
 - **`/plan retro`** — derive from the improvement actions in the reflection phase. Each action becomes an issue (no Epic wrapper unless 5+ actions).
 
+**External Acceptance (all PRD modes).** Each row of the PRD's § External Acceptance becomes its own issue, titled `[Abnahme] <criterion>`. Its body carries the owner, the not-before date, the pass condition, the fallback and the oracle command. The issue that implements the criterion links to it and must not close it, so "implemented" and "accepted" stay separate states. Measured basis: 68 of 85 closed `[Plan]` issues were closed the day they were filed, and the real-world acceptance stayed undone in all three back-tested PRDs.
+
 ### 6.2 Auto-Prioritize
 
 Score each issue using three factors:
@@ -504,6 +515,7 @@ Skip this step if issue creation was cancelled at § 6.3 ("Cancel") — there is
 - **ALWAYS research before asking** — dispatch Explore agents before every Q&A wave. Questions without research backing are guesses.
 - **ALWAYS mark Option 1 as recommended** — with `(Recommended)` in the label. Every question must have a clear recommendation.
 - **ALWAYS use AskUserQuestion** — never present options as plain text. The structured UI is mandatory.
+- **Autonomous runs**: headless, autopilot, or a session the operator has told to decide on its own. Do not stop at an AUQ there. Answer each question with Option 1 when its evidence holds, and record the decision, its reasons and the rejected options as a comment on the Epic. Decisions the operator reserves (external effect, money, accounts, deleting data, security exceptions, irreversible product calls) go to the operator's decision queue and are marked "waits on owner" on the Epic. The Q&A still runs: the research, the recap and the recorded answers are the audit trail.
 - **ALWAYS save documents before creating issues** — the PRD/retro document is the source of truth. Issues reference it.
 - **ALWAYS commit the PRD before creating issues** — see Phase 5.5 (HARD-GATE). A saved-but-uncommitted document is unverifiable by any downstream session; commit to HEAD is the trust boundary, not disk-write.
 - **Security** — never include internal paths, IPs, or infrastructure details in output documents. Read sensitive baseline areas for context but filter from outputs.
@@ -511,7 +523,7 @@ Skip this step if issue creation was cancelled at § 6.3 ("Cancel") — there is
 
 ## Sub-File Reference
 
-This skill uses 8 sub-files in the same directory:
+This skill uses 9 sub-files in the same directory:
 
 | File | Purpose |
 |------|---------|
@@ -523,3 +535,4 @@ This skill uses 8 sub-files in the same directory:
 | `prd-feature-template.md` | 5-section compact PRD template for `/plan feature` |
 | `retro-template.md` | Retrospective document template for `/plan retro` |
 | `prd-reviewer-prompt.md` | PRD quality review instructions for the reviewer subagent |
+| `prd-premortem-panel.md` | Phase 4.5: Refute + Deepen briefs and the coordinator merge rules |