@gobing-ai/spur 0.4.0 → 0.4.2

package/plugins/sp/skills/brainstorm/SKILL.md

@@ -26,7 +26,6 @@ metadata:
 see_also:
   - sp:source-driven-development
   - sp:spur-cli
-  - sp:wayfinder
 ---
 
 # sp:brainstorm — Structured Ideation Workflow
@@ -35,7 +34,6 @@ Generate solution options with trade-offs, recommendations, and confidence scori
 
 **Key distinction:**
 - **`sp:brainstorm`** = Ideation: generate approaches with trade-offs
-- **`sp:wayfinder`** = Wayfinding: chart a multi-session map when the destination itself is foggy
 - **research** = verify and synthesize information (delegate inline by default — see [inline-default contract](../spur-dev/references/cross-cutting.md#inline-default-execution-surface))
 - **`sp:spur-dev`** = Task creation: structured task breakdown (planning half)
 - **`sp:source-driven-development`** = Verification: source-first claim validation
@@ -65,14 +63,13 @@ Activate sp:brainstorm when:
 | "research approaches" | User wants evidence-backed options |
 | "what are my options?" | User wants multiple solutions |
 | "how should I approach X?" | User wants recommendation with reasoning |
-| "wayfind" / "chart a course" | User needs a multi-session investigation map — escalate to `sp:wayfinder` (Phase 2) |
 
 **NOT for:**
 - Pure research (delegate to research skills inline by default; escalate via `spur agent run` only on a subprocess trigger)
 - Task creation without ideation (use `sp:spur-dev` instead)
 - Fact-checking or verification only (use `sp:source-driven-development` instead)
 - Task file operations (use `sp:spur-cli` instead)
-- Multi-session investigation when the destination itself is foggy (use `sp:wayfinder` instead)
+- Multi-session investigation when the destination itself is foggy (recommend `/sp:dev-find-way`; see [Scope Check](#scope-check-end-of-phase-1))
 
 ## Core Principles
 
@@ -317,51 +314,16 @@ non-deterministic intent into a reliable sequence, not bare forwarders (ADR-016)
 
 ---
 
-## Wayfinding Escalation (Phase 2)
+## Scope Check (end of Phase 1)
 
-When the discovery interview (Phase 1 of `/sp:dev-brainstorm`) surfaces that **the destination itself is foggy** — the spec can't be written in one session because too many decisions are unresolved — brainstorm escalates to `sp:wayfinder` instead of proceeding to ideation.
+Before ideation, ask: **"Can this be spec'd in one session, or is the destination itself still foggy?"**
 
-### Scope Check
-
-At the end of Phase 1, before ideation begins, run this scope check:
-
-> **"Can this be spec'd in one session, or is the destination itself still foggy?"**
-
-**Signals that wayfinding is needed:**
-- The topic touches ≥3 subsystems or unknown boundaries
-- Key decisions depend on research not yet done
-- The operator can describe the goal but not the shape of the solution
-- Multiple "it depends" answers in the discovery interview
-- The operator uses fog language: "I'm not sure yet", "we need to explore", "it depends on what we find"
-
-**Signals that standard ideation suffices:**
-- The destination is clear; only the approach is in question
-- All key decisions can be made from existing knowledge
-- The operator can enumerate the constraints and trade-offs
-
-### Escalation Path
-
-When the scope check indicates a foggy destination, offer the escalation:
-
-> *"This is a multi-session investigation. Want me to chart a wayfinder map so we can work through it one decision at a time?"*
-
-The operator **confirms** before wayfinding begins — never silently escalate. A 30-minute quick-answer need might touch a big domain without requiring a multi-session map.
-
-On confirmation, delegate to `sp:wayfinder` for the "Chart the map" mode. The resolved decision tree from Phase 1 seeds the map's **## Notes** and initial **## Not yet specified** sections.
-
-### `--wayfind` Flag
-
-When `/sp:dev-brainstorm` is invoked with `--wayfind`, the scope check is **skipped** — the operator has pre-approved the escalation. After the discovery interview, proceed directly to `sp:wayfinder` charting without the confirmation prompt.
-
-Use `--wayfind` when:
-- The operator already knows this is a multi-session investigation
-- A previous session recommended wayfinding
-- The topic is explicitly exploratory ("explore the solution space for X")
-
-### Integration with the Design Approval Gate
-
-A wayfinding escalation **replaces** the standard ideation output. The map feature (with its destination, notes, fog, and child tickets) is the artifact. The `needs_design` signal is not emitted — wayfinding defers design until the route to the destination is clear. When the last ticket resolves, the final session hands off to standard `sp:brainstorm` → `sp:spec-decomposition` with a now-clear destination.
+Fog signals: the topic touches ≥3 subsystems or unknown boundaries; key decisions depend on research
+not yet done; the operator can name the goal but not the solution's shape; repeated "it depends"
+answers. When they dominate, **stop** — do not ideate toward a destination that isn't there. Report
+the resolved decision tree and recommend `/sp:dev-find-way "<topic>"`, which owns multi-session
+investigation maps. Brainstorm never charts a map itself.
 
 ---
 
-**Remember:** Ideation ≠ Research. Generate approaches with trade-offs. Delegate verification to `sp:source-driven-development`. Delegate synthesis/research inline (escalate to `spur agent run` only on a subprocess trigger). Delegate task creation to `sp:spur-dev`. When the destination itself is foggy, escalate to `sp:wayfinder` — never force a spec that isn't ready.
+**Remember:** Ideation ≠ Research. Generate approaches with trade-offs. Delegate verification to `sp:source-driven-development`. Delegate synthesis/research inline (escalate to `spur agent run` only on a subprocess trigger). Delegate task creation to `sp:spur-dev`. When the destination itself is foggy, stop and recommend `/sp:dev-find-way` — never force a spec that isn't ready.

package/plugins/sp/skills/branch-workflow/SKILL.md

@@ -40,6 +40,7 @@ A git worktree gives you an isolated working directory for a branch without stas
 ```bash
 git worktree add ../<project>-<branch> <branch>
 cd ../<project>-<branch>
+spur projects add . 2>/dev/null || true   # Register in projects.json for the Board project switcher
 ```
 
 **When to use worktrees:**

package/plugins/sp/skills/branch-workflow/references/worktree-patterns.md

@@ -28,6 +28,7 @@ A git worktree gives you an isolated working directory linked to the same reposi
 ```bash
 git worktree add ../project-hotfix hotfix/critical-fix
 cd ../project-hotfix && bun install --frozen-lockfile
+spur projects add . 2>/dev/null || true   # list it in the Board project switcher
 ```
 
 The worktree directory is created alongside the main project. Name it `<project>-<branch>` for clarity.

package/plugins/sp/skills/code-implementation/SKILL.md

@@ -104,6 +104,13 @@ only burns wall clock and context budget.
 
 - **Run only targeted probes** to validate your changes: `bun test <file>`,
   `bun test <file> --test-name-pattern "<test>"`, or `bunx tsc --noEmit` on a single package.
+- **Run Spur through this tree's own entry point, never a bare `spur` (task 1110 R2).** Use the
+  invocation the pipeline supplies (`${vars.spurBin}`, e.g. `bun apps/cli/src/index.ts`) from the
+  execution tree — a bare `spur` on `PATH` resolves to the published bundle in `~/.bun/bin` or
+  `~/node_modules`, so a guard, a `task check` or a `task record` silently runs a different build
+  against a different tree. Same rule for the working directory: each shell call starts fresh, so
+  re-select the execution tree inside the call (`cd -- "$TREE"` plus the identity check) instead of
+  relying on a `cd` a previous call left behind.
 - **NEVER run** `bun run test`, `bun run spur-check`, `bun run check`, or any other full-suite /
   project-gate command from inside implement. These belong to the pipeline's `test` hop.
 - **Full-suite budget: at most 2 per task** (task 0436 R2) — counted across the whole task run
@@ -117,7 +124,35 @@ only burns wall clock and context budget.
 - If a targeted probe reveals a failure you cannot fix within implement scope, note it in
   `## Solution` and let the `test` hop's fixall handle it — do not pre-empt the gate.
 
-## Changed-path targeted checks (dependency-aware verification, task 0510 R3)
+### Public-surface probe (task 1135 R1/R6/R8)
+
+Narrow unit tests prove the seam you refactored, not the surface a user calls. Before this stage
+reports done it runs **one end-to-end probe per new or changed public surface** — a CLI verb/flag,
+an HTTP route, or a plugin script entry:
+
+- against a **throwaway project root** (a temp dir), never the repo corpus or the execution tree's
+tracked files;
+- bounded: 120 s per invocation, output capped at 8 KiB, no network beyond the CLI under test;
+- recorded as acceptance evidence: the **exact command** and its **observed output**;
+- a failing probe is evidence, never a reason to mutate the corpus.
+
+A service-layer test suite does **not** satisfy this. The gap it closes is measured: 19 service tests
+green while `task create --feature <verifying>` failed end-to-end (task 1135 Background). If the stage
+changed no public surface, report the single line
+`probe: not-applicable (no public surface changed)` instead.
+
+**Changed-path static self-check (R8)** — over the changed paths only, before reporting done:
+
+- `spur rule run` with the configured pre-check preset (catches a direct `process.env` read, the
+  `env-var-hygiene` rule, and its siblings);
+- `bun run script-contract-check` when a plugin script was touched (a stale generated `.mjs` twin);
+- the paired-script parity test when `package.json` changed (a half-updated `spur-check` /
+  `spur-check-new` chain).
+
+The single full project check stays the pipeline `test` hop's job (see the section above); these are
+changed-path checks, not that gate.
+
+## Changed-path targeted checks (dependency-aware verification, task 0510 R3 / task 1142 R3)
 
 "Run the narrow test first" needs a second half: *which* narrow tests, when a change to a shared
 surface can break a downstream consumer. The matrix below is dependency-aware — domain → app →
@@ -126,6 +161,12 @@ implement. **It augments narrow behavior tests; it never authorizes `bun run spu
 `bun run test`, or another full project check inside implement** — the pipeline's `test` hop owns
 that single full gate.
 
+**Worker iteration check order (task 1142 R3):**
+1. The **changed-path matrix** below (narrow behavior tests + affected consumers);
+2. the resolved `quality-gate` script in `light` mode (source-repo probe, else the installed twin) (biome on changed files, per-workspace typecheck, rule presets `rules:pre`/`rules:post`, related tests).
+
+Neither step takes the host-wide full-gate lock. The full gate is named only for the pipeline's `test` and `test-recheck` hops.
+
 | Changed surface | Required targeted tests | Required typechecks |
 | --- | --- | --- |
 | `packages/domain/src/**` public type/query | affected domain test; affected app service test; affected CLI command test | `@gobing-ai/spur-domain`, `@gobing-ai/spur-app`, `@gobing-ai/spur` |
@@ -143,6 +184,12 @@ that single full gate.
   creep into every plugin edit.
 - Run the applicable rows, then stop: the single full project check belongs to the pipeline's
   `test` hop (`task-pipeline.yaml` `${vars.qualityGateCmd}`).
+- **Mirrored surfaces: an edit lands on all of them.** When the change is one instance of a repeated
+  pattern — the same wiring rule on two runbooks, a signature in both a generator and its generated
+  `.d.mts`, a command chain in both `spur-check` and `spur-check-new` — grep for the siblings and
+  update each in this pass. Two H1-batch cycles (2026-10-08) were spent re-finding exactly this:
+  task 1129 fixed the guard wiring on one runbook and left its sibling, and task 1127 changed
+  `spur-check` while `spur-check-new`'s chain-parity assertion still expected the old chain.
 
 ## Behavior
 

package/plugins/sp/skills/code-verification/SKILL.md

@@ -165,7 +165,7 @@ classifies it as external and never raises `L4.stale-line-anchor` for it (R1). D
 that lives in this repo — in-repo evidence MUST use the repo-relative backtick form
 `` `path:line` `` / `` `path:start-end` ``, and citing it in the external form still reports (R2).
 
-**Concrete anchors (0804 R9):** cite existing `file:line`s, never globs — `references/verdict-schema.md`.
+**Concrete anchors (0804 R9):** existing `file:line`s only, never globs, always repo-root-relative — a basename is `L4.anchor-unresolved` at the `--as done` gate (`references/verdict-schema.md`).
 
 ### Step 5 — Acceptance Criteria guard
 
@@ -362,9 +362,8 @@ Confidence: HIGH
 The per-requirement traceability table MUST use `| Req | Status | Evidence |` (exactly this header, no `R#`/`R`/`Requirement` variant — `Status` in column 2 — and no extra columns between Req and Status). The Acceptance Criteria table MUST use `| AC | Status | Evidence Type | Evidence |`.
 The answer MUST carry exactly one `Confidence: HIGH|MEDIUM|LOW` line (task 1068): the verifier's stated confidence in the verdict — HIGH = fresh executable evidence + re-read anchors this run; MEDIUM = partial reliance on prior evidence, external/delegated outcomes, or an unstable tree; LOW = key evidence not re-executed. A missing or out-of-vocabulary line fails lint (`confidence-missing` / `confidence-value`) and blocks derivation; the value lands in the verdict artifact's `confidence` field and the recorded `## Testing` section.
 The answer MUST cite a source for external API/library claims in Requirement/AC evidence cells: a cell asserting a scoped-package (`@scope/name`), `node_modules/`, semver-version (`x.y.z`), or backticked function-call (`` `name(args)` ``) claim is rejected with `evidence-citation` unless the SAME cell carries a citation — a repo `path:line(-end)` (backticked or bare), the external named-origin form (@origin `path` line N), or a URL. Cross-cell references ("receipt above") do not count; marker-free receipts ("bun test 398 pass / 0 fail") need no citation.
-**MUST NOT:** place a `Severity` column between `Req` and `Status` in the authoring contract.
-The parser is tolerant of these variants (defense-in-depth), but the authoring contract is
-canonical.
+**MUST NOT:** place a `Severity` column between `Req` and `Status`. The parser tolerates variants
+as defense-in-depth; this contract is canonical.
 
 Under the pipeline, the verifier owns the answer file `.spur/run/<wbs>-verify-answer.txt` (0726
 R3): `Verdict: PARTIAL` first, append one row at a time, replace the verdict line only when all

package/plugins/sp/skills/code-verification/references/secu-review.md

@@ -90,6 +90,9 @@ Before declaring a task `done`, run this lightweight checklist. It catches the m
 - [ ] No `console.log` / `console.error` in production code (use the project logger).
 - [ ] No `--no-verify`, `--force`, or new suppression comments added to bypass gates.
 - [ ] Solution section contains `file:line` citations for every changed file.
+- [ ] API/library claims in changed docs carry a source citation (URL or `path:line`) and an honest
+      confidence level (HIGH/MEDIUM/LOW) per source-driven-development; the deterministic advisory backstop is
+      the `cited-version-strings` / `cited-api-claims` rules (`.spur/rules/docs/sourced-api-claims.yaml`).
 - [ ] Review section has P1–P4 findings table (even if all rows are empty — the table itself proves review happened).
 
 This checklist runs as part of the verify step when the task reaches `testing` status. It does not replace the formal gates — it augments them with between-pipeline hygiene checks.

package/plugins/sp/skills/code-verification/references/verdict-schema.md

@@ -35,9 +35,43 @@ interface VerifyVerdict {
     status: 'pass' | 'fail' | 'warn';
     evidence: string;
   }>;
+  /** Verifier confidence (task 1068 R3). REQUIRED for PASS — the done gate denies
+   *  a confidence-less PASS. Accepted case-insensitively, normalized to uppercase. */
+  confidence?: 'HIGH' | 'MEDIUM' | 'LOW';
 }
 ```
 
+## Confidence level (task 1068 R3)
+
+A PASS verdict must state the verifier's confidence: `"confidence": "HIGH" | "MEDIUM" | "LOW"`.
+The value is case-insensitive on read (normalized to uppercase), but a present value outside the
+enum invalidates the artifact, and a PASS with the field absent is denied at the `* → done`
+transition with a remediation naming the field (`--force-done` remains the documented escape).
+The verify answer's `Confidence:` lint rule (producer side) already guarantees the field for
+pipeline-produced artifacts; this closes the hand-authored / pre-1068 artifact hole.
+
+### Coherence: the level must be earned (task 1133)
+
+Presence and vocabulary are not enough — the level has to match the rows in the same answer, so the
+lint rejects a level that contradicts its own evidence. Two rejection classes, both addressed to the
+`Confidence:` line and both capped by the shared `ANSWER_LINT_MAX_FINDINGS` budget:
+
+- `confidence-unwarranted` — `HIGH` while any requirement row normalizes to `PARTIAL`/`UNMET`, any
+  acceptance-criteria row does not normalize to `MET`, or any `MET` row's evidence is hedged.
+  A `HIGH` claim says the evidence needs no re-check; a non-MET or hedged row says the opposite.
+- `confidence-understated` — `LOW` while at least one requirement row exists and every requirement
+  and acceptance-criteria row normalizes to `MET`. The evidence already did the work, so `LOW`
+  misreports the state as unproven.
+
+`MEDIUM` carries no coherence rule in either direction: it is the level a verifier uses for a caveat
+with no row to point at, and closing it would force either an overclaimed `HIGH` or an unusable
+`LOW`. The level is normalized to uppercase before the decision, so `high` is judged as `HIGH`.
+
+Set the level from the rows, not the mood: all rows `MET` with fresh evidence is `HIGH`; a
+`PARTIAL`/`UNMET` row or a hedge means `MEDIUM`, not `HIGH`. An unwarranted level does not merely
+warn — the lint rejects the answer and no verdict artifact is written, so the level is worth
+choosing deliberately before the verdict line is finalized.
+
 ## Compatibility alias: `scenario` row key
 
 Task 0410 hardened the verdict reader. Producers SHOULD use the canonical `id` field for every
@@ -138,6 +172,23 @@ the run actually verified. Since 0804 R9 the checker ignores complete parsed cit
 scanning for subjects, so a citation's filename (including snake_case paths) can never become a
 false subject — a real absent symbol, nonexistent file, or invalid range still reports.
 
+## Basename-only anchors are unresolved anchors (task 1110 R1)
+
+`spur task verdict --from-answer` accepts the citation *shape*, but the `--as done` gate resolves
+every Testing/Solution anchor against the repo root. A basename citation — `decision-events.ts:83`,
+`task.test.ts:42` — reports `L4.anchor-unresolved` at **error** and blocks
+`spur task update <wbs> done`, because the gate cannot tell which file the row meant. Write the
+repo-root-relative form from the first pass:
+
+- Right: `packages/app/src/decision/decision-events.ts:83`, `apps/cli/tests/commands/task.test.ts:42`
+- Wrong: `decision-events.ts:83`, `../services/foo.ts:12`, `@gobing-ai/ts-x/src/persistence.ts:108`
+  (a scoped package is never repo-relative — use the external named-origin form below)
+
+The pipeline's implement stage also runs a scoped `spur task migrate-anchors --wbs <wbs>` pass
+before the proof capture (task 1109), but it qualifies **unique** basenames only: an ambiguous
+basename (two tracked files share it) is reported and left untouched, and line drift and
+`L4.anchor-subject-mismatch` are never repaired by that pass — those remain the author's rows.
+
 ## Source citations for external claims (task 1070)
 
 A Requirement/AC evidence cell that asserts an external API/library claim must carry a verifiable
@@ -152,6 +203,23 @@ citation in the SAME cell, or lint rejects the row with `evidence-citation` (blo
   satisfy it. Marker-free receipts (test counts, reviewed-log notes) need no citation. The check is
   presence-only — which citation proves which claim is not deterministically decidable.
 
+## Hedged evidence is rejected on MET rows
+
+A MET row asserts the requirement is satisfied; evidence that hedges ("the guard likely prevents
+the leak") contradicts the assertion the row is making. The lint rejects such rows with
+`evidence-hedged`, naming the detected phrase, with two remedies: state the deterministic fact
+with a concrete anchor, or downgrade the row to PARTIAL (which is what suspected-but-unproven
+behavior actually is).
+
+- Detected phrases (closed set, word-anchored, case-insensitive): `likely`, `unlikely`,
+  `probably`, `presumably`, `apparently`, `seems/seeming/seemingly to`, `appears to`. Modal verbs
+  (`might`/`may`/`could`/`should`) are deliberately out of set — they are constant in remediation
+  prose and would drown the signal.
+- Only MET rows are scanned. Hedging a gap in an UNMET row ("the stale path likely still loads
+  the old bundle") is honest reporting and stays clean.
+- Citation spans are stripped before scanning, so a filename or test name containing a hedge
+  word (`likely-match.test.ts`) cannot fire.
+
 ## Checks evidence
 
 Wave C verification can emit the following additive `checks[]` rows:

package/plugins/sp/skills/fleet-join/SKILL.md

@@ -11,7 +11,7 @@ description: >-
 A guest is a session that **pulls** work: it is neither supervised nor restarted, it is addressed
 by concrete id only, and it never receives a stage (`requiresCapabilities` stages can never route
 to it — a guest carries no attestation). Joining registers an occupant row plus a heartbeat lease;
-leaving (or an expired lease) releases it and returns any claimed messages to `pending`.
+leaving (or an expired lease) releases it and returns any claimed messages to `queued`.
 
 ## Join
 

package/plugins/sp/skills/indexed-context/SKILL.md

@@ -144,14 +144,21 @@ an explicit allowlist entry.
 env dumps. Token estimates for Bash/Grep/Glob use response size **after a 4 KiB cap** and secret
 scrub; omit `tokens` when unknown (never `0`).
 
+**Session lifecycle:** `.spur/context/.session.json` is a private pointer to the in-flight session.
+It records the creating host's owner identity (`{host, sessionId}` — Claude's hook `session_id`, Pi's
+session-manager id) and only that owner's `SessionEnd` / `session_shutdown` may write the rollup and
+remove the pointer. A nested run reuses the parent's ledger for tool recording but cannot finalize
+or delete it; an ownerless (legacy) pointer is never finalized and expires under the existing
+idle-start window instead.
+
 ```jsonl
-{"ts":"2026-07-09T14:23:01Z","session":"session-2026-07-09-1423","type":"session_start"}
-{"ts":"2026-07-09T14:23:15Z","session":"session-2026-07-09-1423","type":"read","file":"src/dao.ts","tokens":648}
-{"ts":"2026-07-09T14:24:00Z","session":"session-2026-07-09-1423","type":"write","file":"src/dao.ts","tokens":222,"action":"edit"}
-{"ts":"2026-07-12T15:00:00Z","session":"session-2026-07-12-1500","type":"bash","summary":"ls -la","tokens":12}
-{"ts":"2026-07-12T15:00:01Z","session":"session-2026-07-12-1500","type":"grep","summary":"/TODO/ src"}
-{"ts":"2026-07-12T15:00:02Z","session":"session-2026-07-12-1500","type":"glob","summary":"**/*.test.ts"}
-{"ts":"2026-07-09T14:30:00Z","session":"session-2026-07-09-1423","type":"session_end","totals":{"reads":5,"writes":19,"tokens":2783}}
+{"ts":"2026-07-09T14:23:01Z","session":"session-2026-07-09-142318-a1b2c3d4","type":"session_start"}
+{"ts":"2026-07-09T14:23:15Z","session":"session-2026-07-09-142318-a1b2c3d4","type":"read","file":"src/dao.ts","tokens":648}
+{"ts":"2026-07-09T14:24:00Z","session":"session-2026-07-09-142318-a1b2c3d4","type":"write","file":"src/dao.ts","tokens":222,"action":"edit"}
+{"ts":"2026-07-12T15:00:00Z","session":"session-2026-07-12-150007-e5f6a7b8","type":"bash","summary":"ls -la","tokens":12}
+{"ts":"2026-07-12T15:00:01Z","session":"session-2026-07-12-150007-e5f6a7b8","type":"grep","summary":"/TODO/ src"}
+{"ts":"2026-07-12T15:00:02Z","session":"session-2026-07-12-150007-e5f6a7b8","type":"glob","summary":"**/*.test.ts"}
+{"ts":"2026-07-09T14:30:00Z","session":"session-2026-07-09-142318-a1b2c3d4","type":"session_end","totals":{"reads":5,"writes":19,"tokens":2783}}
 ```
 
 **Never edit `token-ledger.jsonl` by hand.** It feeds the Board **Observability → Tool Using** tab.

package/plugins/sp/skills/parallel-execution/SKILL.md

@@ -104,7 +104,7 @@ was meant to avoid. Let the reviewer reach its own conclusion.
 
 - **`sp:spur-dev`** owns task selection and lifecycle. When a batch contains independent tasks, the spine consults this skill for the fan-out pattern.
 - **`sp:super-planner`** is the orchestrator that executes the fan-out. Its parallel mode (documented in its agent definition) applies the patterns from this skill.
-- **`/sp:dev-parallel`** is the thin slash-command entry point that delegates to this skill.
+- **`/sp:dev-runall --mode parallel|auto`** is the task-batch entry point; its `batch-plan.mjs order` schedule applies this skill's dependency and file-overlap rows deterministically.
 
 ## When to use
 
@@ -135,7 +135,7 @@ Do **not** use this skill for:
 
 - **`sp:spur-dev`** — the orchestration spine that consults this skill for fan-out decisions.
 - **`sp:super-planner`** — the batch orchestrator that executes fan-out patterns.
-- **`/sp:dev-parallel`** — the slash command entry point for parallel execution.
+- **`/sp:dev-runall --mode parallel|auto`** — the slash command entry point for parallel task batches.
 
 ## Platform Notes
 

package/plugins/sp/skills/parallel-execution/references/dispatch-surface.md

@@ -70,7 +70,7 @@ own axis.
 Surface choice and model choice stay separate axes, but the invocation surface is where the
 cheap-model hint is applied. On hosts whose native subagent invocation accepts a per-call model
 override (Claude Code: the Agent tool's `model` parameter), dispatch read-only fan-out workers —
-`dev-parallel --mode investigation` and competency-lens review's read-only lenses — with the host's
+N-way investigation and competency-lens review's read-only lenses — with the host's
 cheapest capable model. The rule is owned by
 [fan-out-patterns.md § Cheap-model hint for read-only fan-out](fan-out-patterns.md#cheap-model-hint-for-read-only-fan-out)
 and carries two prohibitions and one exemption: invocation-side only, **never** a subagent

package/plugins/sp/skills/parallel-execution/references/fan-out-patterns.md

@@ -134,13 +134,13 @@ blocker** — never a permission-probing subsystem:
    [Keep a durable progress ledger](../SKILL.md#keep-a-durable-progress-ledger)).
 
 Read-only investigation fan-out avoids the write-permission class by construction:
-`dev-parallel --mode investigation` and competency-lens review's read-only lenses dispatch
+N-way investigation and competency-lens review's read-only lenses dispatch
 **read-only worker shapes** — search/read tools only, with no write surface declared.
 
 ## Cheap-model hint for read-only fan-out
 
 On hosts whose native subagent invocation accepts a per-call model override (Claude Code: the Agent
-tool's `model` parameter), dispatch read-only fan-out workers — `dev-parallel --mode investigation`
+tool's `model` parameter), dispatch read-only fan-out workers — N-way investigation
 and competency-lens review's read-only lenses — with the host's cheapest capable model. The rule is
 invocation-side, with two prohibitions and one exemption:
 

package/plugins/sp/skills/pr-reviewing/SKILL.md

@@ -112,9 +112,13 @@ unrelated uncommitted changes make safe editing or committing ambiguous.
 **Current-HEAD invariant.** Treat the PR's pushed `headRefOid` as the review identity. After every
 preflight, push, commit, and request, record the returned HEAD and require `wait`, `collect`, and
 the report to match that exact HEAD. A result for an older commit is stale; a result absent for the
-current HEAD is pending, not clean. Reject uncorrelated issue/conversation comments rather than
-using them to manufacture a current-HEAD result. In `fix` mode, discard the old result after the
-fix commit and judge only the forced re-review for the new pushed HEAD.
+current HEAD is pending, not clean. `wait` re-asserts this at two points, not one: at the start of
+every poll, and again immediately before it emits FOUND/CLEAN/TIMEOUT — a head that moved while the
+review was being fetched, or between polls, fails the wait (exit 2) instead of accepting an old-head
+result. The pinned identity is the PR number AND the expected head, so a different PR appearing on
+the branch is also a failure, never a silent retarget. Reject uncorrelated issue/conversation
+comments rather than using them to manufacture a current-HEAD result. In `fix` mode, discard the old
+result after the fix commit and judge only the forced re-review for the new pushed HEAD.
 
 **Reviewer authority.** Codex is an independent reviewer, not an authority. For every finding that
 may lead to a code change: inspect the referenced code, verify reachability and intended behavior,

package/plugins/sp/skills/session-review/SKILL.md

@@ -2,7 +2,7 @@
 name: session-review
 description: "Review the active coding-agent session: separate resolved from open issues with evidence, propose bounded improvements. With --fix auto (alias --triage), apply pure-doc / 1–2-line fixes inline and file the rest as tasks; with --fix all, fix every actionable finding inline and file none. Triggers: review this session, wrap-up, triage findings."
 license: Apache-2.0
-version: 1.2.0
+version: 1.3.0
 metadata:
   author: spur
   platforms: "claude-code,codex,openclaw,opencode,antigravity,pi"
@@ -24,7 +24,9 @@ compact, evidence-backed report of outcomes, resolved issues, remaining risks, a
 
 Use this skill immediately after focused operations when the operator asks what happened, what was
 resolved, or how the session could improve. Use imported-history analysis for ended sessions,
-cross-agent windows, recurrence, trends, or quantitative performance forensics.
+cross-agent windows, recurrence, trends, or quantitative performance forensics: on pi, run
+`spur history analyze --source pi --session <file-stem>` where `<file-stem>` is the transcript
+basename without `.jsonl` (e.g. `2026-10-07T22-44-33-625Z_01a1188a-…`), not the bare uuid.
 
 ## Arguments
 
@@ -92,7 +94,18 @@ issues with its evidence. Notes stay report-only.
    operator prompt, read-only from the host transcript. Run it once without `--group` to list the
    segments, then map them to stages (`"1-3,4,5-6"`). It splits each segment into `work` and
    operator `wait` (idle before the next prompt plus AskUserQuestion answer time) and counts tokens
-   once per message id.
+   once per message id. On pi the transcript is `$PI_SESSION_FILE` (pass it as `--transcript` when
+   the run reports no host session id). **A measurement that returns `segments: []` with zero totals
+   while the session had operator prompts is an unreadable or stale adapter, not an empty session:**
+   compare the installed copy against this tree's `plugins/sp/scripts/session-timeline.mjs` and
+   refresh it with `superskill install sp` before reporting numbers; report `n/a` until then.
+   The transcript resolves from `--transcript`, else `CLAUDE_CODE_SESSION_ID`, else `PI_SESSION_FILE`
+   (the pi host sets it and no Claude session id); with none of them the measurement reports
+   `available:false` with a reason and the table renders `n/a` instead of guessing. A pi
+   `<skill name="…">` wrapper row is the OPERATOR'S own `/skill` invocation, not an injected body:
+   it opens a segment rendered `/<name> <args>` (or `/<name>` when no arguments follow the closing
+   tag), and the wrapper body never appears in the prompt excerpt. Only the operator's prompts
+   segment the session.
 2. **Inventory outcomes.** List requested outcomes and classify each as completed, partial, blocked,
    or not attempted. Collapse repeated attempts into one outcome.
 3. **Classify issues.** For every material issue, distinguish resolved, open, or attempted. Record
@@ -140,10 +153,30 @@ step 4 excludes. Use `n/a` for any value not supported by the measurement.
 | --- | --- | --- | --- | --- |
 
 Evidence names the tool result, verification command, or concrete repository state visible in the
-session. Do not list ordinary implementation steps as issues. **Confidence** is `HIGH`, `MEDIUM`, or
-`LOW` for that row's claim, with its grounds in the cell (a level without grounds is not
-verification); any API/library statement in a row cites the installed source as `path:line` or a URL,
-and a claim the session could not ground is written `LOW` with the missing evidence named.
+session. Do not list ordinary implementation steps as issues.
+
+**Confidence** is `HIGH`, `MEDIUM`, or `LOW` for that row's claim. The level is **derived from the
+check that produced the claim, never assessed from how the row reads**, and the cell carries that
+verifier (e.g. `HIGH — gate exit 0, /tmp/g0.log re-run this session`). Add the row's **falsifier**
+when the level is not `HIGH`: what would have made it fail, or what moves it up. The same ladder
+grades this report's Open-issues table.
+
+| Level | Verifies when | Not this |
+| --- | --- | --- |
+| `HIGH` | An executed check in this session produced the result and its raw output is reachable (command + exit code, test counts, query row, gate log). Re-runnable now. | The code or change "looks correct"; a claim asserted only in prose. |
+| `MEDIUM` | The claim is inferred from observed facts, rests on prior-session or delegated evidence, or names state that moved after the check (stale by construction). Name which of the three. | Presenting an inference as an observation. |
+| `LOW` | No executable check was run. Name the missing evidence **and** the command that would ground it. | Dropping the row instead of marking it. |
+
+Two guards against level inflation:
+
+- Evidence that cannot be re-run, or that is only the agent's own summary, **caps the row at
+  `MEDIUM`** — a re-run is what promotes it.
+- An all-`HIGH` multi-finding review is a signal the ladder was not applied, not a clean session.
+  Where every row genuinely is `HIGH`, the cells show distinct check results rather than repeated
+  phrasing.
+
+Any API/library statement in a row cites the installed source as `path:line` or a URL, and a claim
+the session could not ground is written `LOW` with the missing evidence named.
 
 ### Open issues and risks
 

package/plugins/sp/skills/source-driven-development/SKILL.md

@@ -101,6 +101,11 @@ line: `Verification: HIGH|MEDIUM|LOW — <first failing check and deviation, or
 - **Honest confidence** — the stated HIGH/MEDIUM/LOW matches the evidence: HIGH requires a check against the pinned source this session; MEDIUM/LOW items are labeled, and LOW is never presented as fact.
 - **HIGH** — all three checks pass. **MEDIUM** — coverage intact but some citations are off-version (latest docs for a pinned dependency) or secondary-source only. **LOW** — an API/library claim lacks any citation, or a LOW-confidence claim was asserted as fact.
 
+Deterministic backstop: the `cited-version-strings` / `cited-api-claims` rules
+(`.spur/rules/docs/sourced-api-claims.yaml`, run in `recommended-pre-check`) flag markdown lines that
+assert version strings or time-anchored API claims with no citation anchor on the same line. They
+are an info-severity advisory backstop for this contract (they do not gate; the checks above and the SECUA checklist are the enforcement points).
+
 ## Common Rationalizations
 
 | Rationalization | Reality |

package/plugins/sp/skills/spec-decomposition/references/decomposition.md

@@ -562,9 +562,11 @@ schema before emitting.
 
 **Pass the deterministic task check.** Each `acceptance_criteria` bullet must be an exact feature
 scenario title (L4.uncovered-task-scenario); add task-local checks as prose after the bullets, not
-as extra bullets. No section body may use `HITL`, `approval`/`approved`, `merged`/`merge event`,
-`content-gate`, `GATED`, or `capstone` as standalone words (L4.gate-language) — say "operator
-answer" / "accepted" instead, and keep enum values out of that list too.
+as extra bullets. No section body may use `HITL`, `merge event`, `content-gate`, `GATED`, or
+`capstone` as standalone words (L4.gate-language); ambiguous words (`approval`, `approved`,
+`merged`) warn only with a gating cue (`until`, `after`, `once`, `before`, `pending`, `blocked`,
+`wait for`, `requires`) in the same sentence, so plain composition prose stays silent — say
+"operator answer" / "accepted" instead, and keep enum values out of that list too.
 
 **The order sidecar.** Also emit the private task-order sidecar at
 `.spur/run/<runId>-idea-task-order.json`: a JSON array (one entry per batch item) of

package/plugins/sp/skills/spur-cli/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: spur-cli
-description: "Reference and operate the complete `spur` CLI surface: task, feature, rule, workflow, builder, agent, message, self, history, and projects. Use for verb or flag lookup, machine-readable output and exit contracts, or CLI-gated corpus writes. Triggers: \"spur task\", \"spur history\", \"spur projects\", \"create a task\", \"task check\", and any Spur CLI convention. Not for planning or execution lifecycle orchestration (`sp:spur-dev`)."
+description: "Reference and operate the complete `spur` CLI surface: task, feature, rule, workflow, builder, agent, message, decision, self, history, and projects. Use for verb or flag lookup, machine-readable output and exit contracts, or CLI-gated corpus writes. Triggers: \"spur task\", \"spur history\", \"spur projects\", \"spur decision\", \"spur agent join\", \"create a task\", \"task check\", and any Spur CLI convention. Not for planning or execution lifecycle orchestration (`sp:spur-dev`)."
 license: Apache-2.0
 metadata:
   author: spur
@@ -17,6 +17,7 @@ metadata:
     - builder
     - agent
     - message
+    - decision
     - self
     - history
     - projects
@@ -44,7 +45,7 @@ Pick the noun, read its reference. Each Tier A and Tier B reference owns that no
 | **Tier A** | **rule** | Constraint quality gate: run presets, author rules, fine-tune, validate rule files/presets, extend engine | [references/rules.md](references/rules.md) |
 | **Tier A** | **workflow** | Dual-mode workflow runtime: author state-machine / transition-flow workflows, validate, run, read traces | [references/workflows.md](references/workflows.md) |
 | **Tier A** | **builder** | Release plumbing: bump a package (or the `workspace:`-pinned set) with `bump-ver`, delete release tags with `drop-tags`, commit + tag + optional push | [references/builder.md](references/builder.md) |
-| **Tier B** | **agent** | Coding-agent execution surface: run prompts via detected/named agents, list agent specs, start/stop supervised processes, readiness check | [references/agent.md](references/agent.md) |
+| **Tier B** | **agent** | Coding-agent execution surface: run prompts via detected/named agents, list agent specs (incl. `agent.fleet` members), start/stop supervised processes, fleet `report`/`join`/`leave`/`wait`/`trace`, readiness check | [references/agent.md](references/agent.md) |
 | **Tier B** | **message** | Durable inter-agent messaging: send, inbox, reply, watch | [references/message.md](references/message.md) |
 | **Tier B** | **self** | Self-management verbs: scaffold (`init`), database maintenance (`maintain`), schema migrations (`migrate`), local web server (`serve`), status overview (`status`); `self init` runs post-scaffold validation probes & layout classification | [references/self.md](references/self.md) |
 | **Tier B** | **history** | Import agent histories, aggregate forensic artifacts, render reports, and run the checkpoint-resumed daily pipeline | [references/history.md](references/history.md) |
@@ -142,6 +143,8 @@ and spreading it; full contract in `docs/04_DESIGN.md` §1.0.1.
   [dispatch-surface rule](../parallel-execution/references/dispatch-surface.md).
 - **[references/message.md](references/message.md)** - durable inter-agent messaging (`send`,
   `inbox`, `reply`, `watch`).
+- **[references/decision.md](references/decision.md)** - decision catalog (`list`, `show`, `run`,
+  `status`); offline by default via the built-in `typesafe` maker.
 - **[references/self.md](references/self.md)** - `spur self init|maintain|migrate|serve|status` CLI verbs
   (the five legacy top-level nouns remain hidden aliases). `self init` runs post-scaffold init
   validation (Phase 1.5/1.6 probes).