@arbiterforge/ca-pi 0.6.3 → 0.10.0

package/plugins/ca-pi/routines/dispatching-parallel-agents/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: dispatching-parallel-agents
-description: "The parallel fan-out primitive. Routed to by any skill or command that splits work across independent units and dispatches an agent per unit — subagent-driven-development, /sprint, parallel /review. It owns the dispatch/collect/funnel discipline: bound concurrency, isolate units, collect every result, dedupe overlap, and funnel through finding-triage then checkpoint-aggregator. Raw agent output is never consumed before the funnel runs; an agent that errors drops its unit without corrupting the batch."
+description: "The parallel fan-out primitive. Routed to by any skill or command that splits work across independent units and dispatches an agent per unit — subagent-driven-development, /sprint, parallel /review. It owns the dispatch/collect/funnel discipline: bound concurrency, isolate units, collect every result, dedupe overlap, and funnel through finding-triage then the read-only verdict-aggregator. Raw agent output is never consumed before the funnel runs; an agent that errors records its unit as incomplete without corrupting the batch."
 disable-model-invocation: true
 ---
 
@@ -59,8 +59,8 @@ Gate: the result set is deduped, contradictions surfaced, and completion claims
 
 The batch is consumed only here, through the fixed funnel — never directly by the caller.
 
-1. Dispatch `finding-triage` (`<plugin-root>/agents/finding-triage.md`) over the deduped result set: it classifies severity, marks out-of-scope items with an inline `[NEEDS-TRIAGE]` marker, and discards noise.
-2. Hand the triaged set to `checkpoint-aggregator` (`<plugin-root>/agents/checkpoint-aggregator.md`): it aggregates into the single batch verdict the caller consumes — pass, or a blocking finding list.
+1. Dispatch `finding-triage` (`<plugin-root>/agents/finding-triage.md`) over the deduped result set and batch completion contract: it classifies severity and marks out-of-scope items with an inline `[NEEDS-TRIAGE]` marker. Every reviewer finding reaches the verdict; only non-finding transport metadata may be omitted.
+2. Hand the triaged set to `verdict-aggregator` (`<plugin-root>/agents/verdict-aggregator.md`): it composes the single read-only batch verdict the caller consumes — `PASS`, `BLOCKING_FINDINGS`, or `INCOMPLETE`.
 
 The errored and deferred units from Phase 3 ride through the funnel as findings — an `ERRORED` unit is a finding the caller must see, not a silent gap.
 
@@ -71,6 +71,6 @@ Gate: the caller receives only the aggregated verdict. Bypassing the funnel —
 - MUST NOT dispatch two units that mutate the same path in one batch; isolate via `using-git-worktrees` or serialize.
 - MUST NOT fan out unbounded; dispatch within the concurrency bound.
 - MUST NOT let one `ERRORED` unit discard or corrupt the rest of the batch.
-- MUST NOT consume agent output before the `finding-triage` → `checkpoint-aggregator` funnel runs.
+- MUST NOT consume agent output before the `finding-triage` → `verdict-aggregator` funnel runs.
 - MUST NOT trust a subagent's self-reported completion; verify with a fresh proving command.
 - MUST NOT silently drop a unit — every unit terminates with a recorded state that rides through the funnel.

package/plugins/ca-pi/routines/release/SKILL.md

@@ -269,7 +269,7 @@ The tag and the GitHub Release publish together, and only after the user explici
 On authorization:
 
 1. Push the tag: `git push origin ${TAG_PREFIX}${VERSION}`.
-2. **Resolve `<Phase-1 section file>` fresh in every Phase-3 invocation — never assume Phase 1's scratch file survived** (HIGH, blind exercise run 19). That file was created with `mktemp` outside the working tree and discarded once Phase 3 no longer needed it; on the `resume_publish` path (tag composed in a prior invocation, published now) it is normally already gone, and there was previously no stated way to get it back that did not read as the "re-derive or hand-write" the hard rules forbid. There is one sanctioned, mechanical way: `"$PY" "<plugin-root>/hooks/_releaselib.py" changelog-section $CHANGELOG ${VERSION}` prints the `## [${VERSION}] …` section back out of the COMMITTED `$CHANGELOG` verbatim — guaranteed present, because Phase 1 step 7 committed it before any tag existed. Redirect its stdout to a fresh local file and use that as `<Phase-1 section file>` for every step below; this is reading the exact text back from its one permanent home, not composing new notes. Exit 1 (no heading for `${VERSION}`) means `$CHANGELOG` and the tag have drifted — STOP and investigate; never compose a substitute section by hand. On a same-session fresh publish the Phase 1 scratch file is still there and this reconstruction is redundant but harmless — run it anyway, so Phase 3 does not need to know which case it is in. **Guard the notes-file first:** assert its first heading matches the tag — `"$PY" "<plugin-root>/hooks/_releaselib.py" notes-match ${TAG_PREFIX}${VERSION} <Phase-1 section file>` (exit 0). A stale notes-file (`notes_heading_matches` False) would publish the wrong changelog section under the right tag — STOP on mismatch. Then create the GitHub Release from the **same changelog section composed in Phase 1** — reuse it as the notes, never re-derive or hand-write them. **`--latest` follows the declared row:** assert it only when `$TARGET`'s row declares `latest-eligible: true`, and only when this tag is also the newest release across every declared series (compare against `gh release list`; vacuously satisfied when only one series is declared); every other target passes `--latest=false`. GitHub has one repo-wide "Latest"; a declared file may name several series, so a target claiming it wrongly hides another's current release from every visitor. `gh release create ${TAG_PREFIX}${VERSION} --title "<title>" --notes-file <Phase-1 section file> --latest --verify-tag` when the row qualifies per the rule above, otherwise `gh release create ${TAG_PREFIX}${VERSION} --title "<title>" --notes-file <Phase-1 section file> --latest=false --verify-tag` — two distinct, individually runnable commands, never the bracket notation `--latest[=false]`, which is prose shorthand and not shell `gh` accepts. The title convention is `<$DISPLAY_NAME> ${VERSION}: <summary>` — `$DISPLAY_NAME` is the row's declared `display-name`, or `$TARGET` itself when the row declares none — with no em-dash separator. **`<summary>` is derived, not invented** (MEDIUM, adversarial review 2026-07-31, run 3: it appeared exactly once in this file and was never defined, so it was whatever the agent made up): take the single highest-precedence entry from the Phase 1 section — the first bullet under `### Added` if the window bumped minor, otherwise the first bullet under `### Fixed`, else the first bullet of the first non-empty group — and compress it to a noun phrase under ten words, in the entry's own words. If that yields nothing usable because the section has one group with one terse bullet, use that bullet verbatim. Never write a summary that names a change absent from the section.
+2. **Resolve `<Phase-1 section file>` fresh in every Phase-3 invocation — never assume Phase 1's scratch file survived** (HIGH, blind exercise run 19). That file was created with `mktemp` outside the working tree and discarded once Phase 3 no longer needed it; on the `resume_publish` path (tag composed in a prior invocation, published now) it is normally already gone, and there was previously no stated way to get it back that did not read as the "re-derive or hand-write" the hard rules forbid. There is one sanctioned, mechanical way: `"$PY" "<plugin-root>/hooks/_releaselib.py" changelog-section "<project-root>" "${TAG_PREFIX}${VERSION}" "$CHANGELOG" "$VERSION"` prints the `## [${VERSION}] …` section back out of the exact regular-file blob committed under the already-composed tag — guaranteed present, because Phase 1 step 7 committed it before the tag was created. The project root and every value are separate quoted arguments; the helper rejects a nested or unrelated root, an absolute or escaping changelog path, a non-regular Git tree entry, a malformed heading, `Unreleased` in a released position, and duplicate target sections. It resolves the tag to a commit hash before reading the blob, so a dirty/deleted working file, a changed current `HEAD`, or an unrelated current directory cannot substitute Release notes after the tag is composed. Redirect stdout to a fresh local file and use that as `<Phase-1 section file>` for every step below; this is reading the exact text back from its one permanent home, not composing new notes. Exit 1 (no heading for `${VERSION}`) means the committed changelog and tag version disagree; exit 3 means the root/revision/path/blob binding could not be proven; exit 4 means the changelog is malformed or ambiguous. Every one STOPs for investigation; never compose a substitute section by hand. On a same-session fresh publish the Phase 1 scratch file is still there and this reconstruction is redundant but harmless — run it anyway, so Phase 3 does not need to know which case it is in. **Guard the notes-file first:** assert its first heading matches the tag — `"$PY" "<plugin-root>/hooks/_releaselib.py" notes-match "${TAG_PREFIX}${VERSION}" <Phase-1 section file>` (exit 0). A stale notes-file (`notes_heading_matches` False) would publish the wrong changelog section under the right tag — STOP on mismatch. Then create the GitHub Release from the **same changelog section composed in Phase 1** — reuse it as the notes, never re-derive or hand-write them. **`--latest` follows the declared row:** assert it only when `$TARGET`'s row declares `latest-eligible: true`, and only when this tag is also the newest release across every declared series (compare against `gh release list`; vacuously satisfied when only one series is declared); every other target passes `--latest=false`. GitHub has one repo-wide "Latest"; a declared file may name several series, so a target claiming it wrongly hides another's current release from every visitor. `gh release create "${TAG_PREFIX}${VERSION}" --title "<title>" --notes-file <Phase-1 section file> --latest --verify-tag` when the row qualifies per the rule above, otherwise `gh release create "${TAG_PREFIX}${VERSION}" --title "<title>" --notes-file <Phase-1 section file> --latest=false --verify-tag` — two distinct, individually runnable commands, never the bracket notation `--latest[=false]`, which is prose shorthand and not shell `gh` accepts. The title convention is `<$DISPLAY_NAME> ${VERSION}: <summary>` — `$DISPLAY_NAME` is the row's declared `display-name`, or `$TARGET` itself when the row declares none — with no em-dash separator. **`<summary>` is derived, not invented** (MEDIUM, adversarial review 2026-07-31, run 3: it appeared exactly once in this file and was never defined, so it was whatever the agent made up): take the single highest-precedence entry from the Phase 1 section — the first bullet under `### Added` if the window bumped minor, otherwise the first bullet under `### Fixed`, else the first bullet of the first non-empty group — and compress it to a noun phrase under ten words, in the entry's own words. If that yields nothing usable because the section has one group with one terse bullet, use that bullet verbatim. Never write a summary that names a change absent from the section.
 3. Handle edge cases explicitly, never silently: if a Release for the tag already exists, report it and skip creation (the tag push may already have landed); if `gh` is missing, unauthenticated, or the call fails, STOP and print the exact `gh release create` command so publication can be finished by hand rather than left half-done.
 4. **Verify publication — never assume it.** Read the Release back: `gh release view ${TAG_PREFIX}${VERSION} --json url,isDraft,tagName`. STOP unless it returns a **non-draft** Release on the correct tag; `gh release create` can partially succeed (tag pushed, Release rejected for an empty notes-file or a permissions/`--verify-tag` race), and an unverified publish is not a published release. Report the Release URL only once the read-back confirms it.
 5. **Record the tag's provenance, when the row declares one.** A git tag is a mutable ref, and the commit a tag was *originally* published at is not recoverable from the API once it moves — a moved tag looks exactly like a tag that was always there. So, when `$TARGET`'s row declares `$PROVENANCE_MANIFEST`, write it down: add the new tag to that file under `tags`, as `{"object_sha": <the ref's sha>, "object_type": "tag", "commit_sha": <the commit it dereferences to>}`. Read both mechanically from the remote you just pushed to, never from local state: `git ls-remote --tags origin ${TAG_PREFIX}${VERSION}` for the ref sha and `git rev-parse ${TAG_PREFIX}${VERSION}^{commit}` for the commit. If this project runs an automated tag-drift check in CI against that file, an unrecorded tag is an unguarded tag there. **A row declaring no `$PROVENANCE_MANIFEST` skips this step — say so explicitly in the report** rather than silently doing nothing (a skipped step and a forgotten one must never look the same to the person reading the report). The entry rides in a normal commit through `commit-gate` on the release branch.

package/plugins/ca-pi/skills/ca-checkpoint/SKILL.md

@@ -23,8 +23,8 @@ Periodic sweep of the entire codebase with the reviewer fleet, funneled to a sin
    | `architecture-drift-reviewer` | `decisions/`; drift between code and accepted ADRs |
 
 2. Route to `dispatching-parallel-agents` (`<plugin-root>/routines/dispatching-parallel-agents/SKILL.md`) with that unit list (read-only batch). It dedupes, then
-   funnels through `finding-triage` → `checkpoint-aggregator`.
-3. `checkpoint-aggregator` writes the dated report to
+   funnels through `finding-triage` → `verdict-aggregator` and returns the single read-only verdict.
+3. After the verdict returns, separately dispatch `checkpoint-aggregator` with that verdict. It writes the dated report to
    `<project-root>/.codearbiter/checkpoints/YYYY-MM-DD.md`: findings by severity with
    file:line, and out-of-scope items marked inline `[NEEDS-TRIAGE]`.
 4. Write the current override **count** to `<project-root>/.codearbiter/last-checkpoint` — the
@@ -38,8 +38,9 @@ Periodic sweep of the entire codebase with the reviewer fleet, funneled to a sin
 ## Hard gate
 
 Read-only except writing the checkpoint doc and `last-checkpoint` — MUST NOT modify code. MUST NOT
-consume raw reviewer output — only the `finding-triage` → `checkpoint-aggregator` verdict. MUST NOT
-resolve a `[CONFIRM-NN]` surfaced during the sweep by guessing. The report surfaces findings; it does
+consume raw reviewer output — only the `finding-triage` → `verdict-aggregator` verdict. Checkpoint
+persistence MUST remain the separate `checkpoint-aggregator` step and MUST NOT run for `/ca-review`
+or another generic parallel batch. MUST NOT resolve a `[CONFIRM-NN]` surfaced during the sweep by guessing. The report surfaces findings; it does
 not block or sign off anything.
 
 ## When NOT to use

package/plugins/ca-pi/skills/ca-cleanup/SKILL.md

@@ -6,6 +6,12 @@ argument-hint: (none)
 
 # /ca-cleanup — post-merge branch transition
 
+<!-- catalog-compatibility-notice:start -->
+> Compatibility route. Prefer `/ca-pr --cleanup` for new usage. This installed route remains
+> functional under the command-route compatibility policy at <plugin-root>/includes/command-compatibility.md;
+> continue with the unchanged cleanup workflow below.
+<!-- catalog-compatibility-notice:end -->
+
 Your PR merged. You are still standing on the branch, with build output, worktree
 residue, and scratch files around you. This command owns the ordinary walk back:
 prove the branch actually landed, decide what the leftovers are, get to a clean

package/plugins/ca-pi/skills/ca-context-check/SKILL.md

@@ -6,6 +6,12 @@ argument-hint: (none)
 
 # /ca-context-check — manual drift audit
 
+<!-- catalog-compatibility-notice:start -->
+> Compatibility route. Prefer `/ca-status drift` for new usage. This installed route remains
+> functional under the command-route compatibility policy at <plugin-root>/includes/command-compatibility.md;
+> continue with the unchanged drift workflow below.
+<!-- catalog-compatibility-notice:end -->
+
 An optional, on-demand audit for bypass cases: a merge or external edit
 changed a tracked source file you are not about to commit, so commit-gate's
 auto-heal did not fire. Routes to the `context-check` skill.

package/plugins/ca-pi/skills/ca-create-context/SKILL.md

@@ -6,6 +6,12 @@ argument-hint: (none)
 
 # /ca-create-context — brownfield populate
 
+<!-- catalog-compatibility-notice:start -->
+> Compatibility route. Prefer `/ca-init --brownfield` for new usage. This installed route remains
+> functional under the command-route compatibility policy at <plugin-root>/includes/command-compatibility.md;
+> continue with the unchanged brownfield workflow below.
+<!-- catalog-compatibility-notice:end -->
+
 Wraps an existing codebase in project state without guessing. Dispatches parallel scouts to read the repository, synthesizes their findings into the surviving `.codearbiter/` doc set, resolves gaps via a targeted interview, and locks the project initialized. No arguments — the skill reads the repo and asks only what it cannot determine.
 
 The only permitted path to populate `.codearbiter/` when meaningful source code already exists. For a greenfield project with no source, use `/ca-decompose`.

package/plugins/ca-pi/skills/ca-decompose/SKILL.md

@@ -6,6 +6,12 @@ argument-hint: (none)
 
 # /ca-decompose — greenfield populate
 
+<!-- catalog-compatibility-notice:start -->
+> Compatibility route. Prefer `/ca-init --greenfield` for new usage. This installed route remains
+> functional under the command-route compatibility policy at <plugin-root>/includes/command-compatibility.md;
+> continue with the unchanged greenfield workflow below.
+<!-- catalog-compatibility-notice:end -->
+
 Stands up project state for a greenfield project — one with no meaningful source code yet. A senior-architect persona drives a six-layer interview eliciting purpose, scope, primary users, domain vocabulary, and architectural constraints, persisting each layer to disk so a context reset loses nothing, then writes the surviving `.codearbiter/` doc set and locks the project initialized. No arguments — the skill interviews the user (a handoff summary may be supplied freely during the interview).
 
 The only permitted path to populate `.codearbiter/` when no meaningful source exists. For an existing codebase, use `/ca-create-context`.

package/plugins/ca-pi/skills/ca-doctor/SKILL.md

@@ -42,3 +42,7 @@ remediation.
 Read-only. MUST NOT create markers, stage files, grant trust, weaken a block, or retry the
 wrapper self-test with different spelling. MUST preserve the degraded active-dispatch diagnosis until
 supported-version real-host promotion/CI evidence closes PI-AC-28.
+
+For an arbiter-enabled repository, the mechanical report treats the Git backstop as healthy only
+after exact managed-shim and live-enforcer validation, plus a harmless selected-Git
+`git hook run pre-push` probe with empty input. It never executes a foreign hook.

package/plugins/ca-pi/skills/ca-init/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ca-init
 description: Opt this repo into codeArbiter — scaffold the root-level .codearbiter/ state store.
-argument-hint: "(none) | --stage N | --check"
+argument-hint: "[--stage N] [--greenfield|--brownfield] | --check"
 ---
 
 # /ca-init — first-run scaffold
@@ -15,6 +15,23 @@ the SessionStart persona injection. The scaffolded
 `CONTEXT.md` is a **stub** (no initialization sentinel), so after scaffolding the project still needs
 populating before normal operation.
 
+<!-- catalog-command-modes:start -->
+## Explicit population strategies
+
+<!-- command-mode:--greenfield legacy-route:decompose -->
+`--greenfield` selects the exact `<plugin-root>/skills/ca-decompose/SKILL.md` workflow.
+
+<!-- command-mode:--brownfield legacy-route:create-context -->
+`--brownfield` selects the exact `<plugin-root>/skills/ca-create-context/SKILL.md` workflow.
+
+The two flags are mutually exclusive and neither may combine with `--check`. `--stage N` may
+accompany one only while `.codearbiter/CONTEXT.md` is absent: scaffold at that stage, then enter the
+selected workflow. When an uninitialized stub already exists, skip the refusing scaffolder and enter
+the selected workflow directly. An initialized marker or source-shape mismatch retains the selected
+legacy workflow's BLOCK. Without an explicit strategy, continue with the unchanged auto-detection
+procedure below.
+<!-- catalog-command-modes:end -->
+
 ## Procedure
 
 1. Run the scaffolder against the repo's git toplevel (resolved by the script):

package/plugins/ca-pi/skills/ca-pr/SKILL.md

@@ -1,13 +1,29 @@
 ---
 name: ca-pr
 description: Open a pull request the only sanctioned way — clear every BLOCK-level review finding, then stage the PR. Never a direct write to the default branch.
-argument-hint: (none)
+argument-hint: "[\"title\"] | --watch [PR] | --cleanup"
 ---
 
 # /ca-pr — open a pull request
 
 The only permitted path to a pull request. Every change lands through a PR — never a direct write or force-push to the default branch. No PR is drafted while any BLOCK-level review finding stands.
 
+<!-- catalog-command-modes:start -->
+## Compatibility modes
+
+<!-- command-mode:--watch legacy-route:watch -->
+`--watch [PR number | URL | branch]` loads and follows
+`<plugin-root>/skills/ca-watch/SKILL.md` with the remaining arguments. This is an internal resource
+handoff to the exact watcher contract, not a second host-command invocation.
+
+<!-- command-mode:--cleanup legacy-route:cleanup -->
+`--cleanup` loads and follows `<plugin-root>/skills/ca-cleanup/SKILL.md` with no remaining argument. It
+retains the cleanup route's containment proof and per-item confirmations.
+
+The flags are mutually exclusive. A bare or quoted title named `watch` or `cleanup` is not a mode;
+without either flag, continue with the unchanged PR flow below.
+<!-- catalog-command-modes:end -->
+
 ## Flow
 
 Routes to the `finishing-a-development-branch` skill, open-PR path. The orchestrator reads the current

package/plugins/ca-pi/skills/ca-review/SKILL.md

@@ -6,7 +6,7 @@ argument-hint: "[path | #<pr> | <pr-url>] (defaults to the current diff)"
 
 # /ca-review — diff review
 
-Read-only review of a change. Routes to `dispatching-parallel-agents` (`<plugin-root>/routines/dispatching-parallel-agents/SKILL.md`): dispatches the reviewer fleet by path matrix, dedupes, then funnels through `finding-triage` → `checkpoint-aggregator` to a single verdict. No code is modified.
+Read-only review of a change. Routes to `dispatching-parallel-agents` (`<plugin-root>/routines/dispatching-parallel-agents/SKILL.md`): dispatches the reviewer fleet by path matrix, dedupes, then funnels through `finding-triage` → `verdict-aggregator` to a single in-memory verdict. No code is modified.
 
 **The change under review does not have to be yours.** `/ca-review #123` reviews an inbound pull request through the same fleet, the same matrix, and the same triage. That is the point of issue #80: a tool that only reviews the diff you just wrote is a linter for authors, not a gate for a team, and reviewing code you did NOT write is where a governance gate earns its keep.
 
@@ -38,7 +38,7 @@ It is an ARGUMENT, not a second command. The scope resolver already took one, th
 
 3. Route to `dispatching-parallel-agents` with that unit list (read-only batch — no collision check).
    It dedupes overlapping findings, then funnels through `finding-triage` (severity + inline
-   `[NEEDS-TRIAGE]` on out-of-scope items) → `checkpoint-aggregator` (single verdict).
+   `[NEEDS-TRIAGE]` on out-of-scope items) → `verdict-aggregator` (single read-only verdict).
 4. Surface the aggregated verdict: findings by severity, file:line, remediation, and the applicable
    control from `<project-root>/.codearbiter/security-controls.md` for security findings.
 5. **For a PR target, posting the verdict is a separate, confirmed step.** Report locally first; post only on explicit instruction, with `gh pr review <number> --comment --body-file <file>`. A review comment on someone else's PR is outward-facing and effectively public the moment it lands — it notifies subscribers and cannot be un-sent. Never `--request-changes` or `--approve` from here: those carry merge authority, and this command produces a finding list, not a maintainer's decision.
@@ -52,8 +52,7 @@ It is an ARGUMENT, not a second command. The scope resolver already took one, th
 
 ## Hard gate
 
-Read-only — MUST NOT modify a file, and MUST NOT check out, merge, or otherwise move the repository to the PR's branch: reviewing an inbound PR means reading its DIFF, not adopting its code, and a checkout would run its content through hooks that trust the working tree. BLOCK on any CRITICAL or HIGH finding on your OWN change: it must be resolved before `/ca-pr`. On an inbound PR there is nothing local to block — the verdict is the deliverable. MUST NOT consume raw reviewer output — only the `finding-triage` → `checkpoint-aggregator`
-verdict. MUST NOT resolve a `[CONFIRM-NN]` surfaced during review by guessing.
+Read-only — MUST NOT modify a file, and MUST NOT check out, merge, or otherwise move the repository to the PR's branch: reviewing an inbound PR means reading its DIFF, not adopting its code, and a checkout would run its content through hooks that trust the working tree. BLOCK on any CRITICAL or HIGH finding on your OWN change: it must be resolved before `/ca-pr`. On an inbound PR there is nothing local to block — the verdict is the deliverable. MUST NOT consume raw reviewer output — only the `finding-triage` → `verdict-aggregator` verdict. MUST NOT resolve a `[CONFIRM-NN]` surfaced during review by guessing.
 
 ## When NOT to use
 

package/plugins/ca-pi/skills/ca-spike/SKILL.md

@@ -15,24 +15,31 @@ it never merges, never PRs, and never becomes the implementation. What survives
 1. **Name the question** — a spike without a falsifiable question is just freelancing. Restate
    `$ARGUMENTS` as the question the spike answers and the timebox (default: one session). STOP for
    the user's confirmation.
-2. **Branch** — create `spike/<slug>` from the current branch. All spike work stays on it.
+2. **Branch** — create `spike/<slug>` from the current branch. All exploratory code and experiments
+   stay on it; only the completed findings file may later cross back to the parent.
 3. **Explore** — no `tdd`, no plan, no review fleet. Two rules survive even here: no secret leaves
    the approved store, and no irreversible operation (prod data, destructive migration) runs from a
    spike.
 4. **Exit — exactly one of:**
    - **Answered** → write the findings to `<project-root>/.codearbiter/spikes/<slug>.md`
-     (the question, what was tried, the answer, what it implies), then delete the branch. If the
-     answer warrants building, hand the findings to `/ca-feature` — the spike file seeds
+     (the question, what was tried, the answer, what it implies), and commit only that findings file
+     on `spike/<slug>`. Return to the parent branch and run
+     `git restore --source spike/<slug> -- .codearbiter/spikes/<slug>.md` to transfer only the
+     committed findings file, review it, and commit that one file through `/ca-commit`; do not
+     merge the spike branch. Then delete the spike branch. If the answer warrants building, hand the
+     findings to `/ca-feature` — the spike file seeds
      `brainstorming` (`<plugin-root>/routines/brainstorming/SKILL.md`); the spike code is reference material, never the implementation.
-   - **Timebox expired, no answer** → record that too (a dead end is a finding), delete the branch.
+   - **Timebox expired, no answer** → record that in the findings file and use the same findings-only
+     transfer before deleting the spike branch.
 
 ## Hard gate
 
-MUST NOT merge or PR a `spike/*` branch — its only exits are a findings file and deletion. MUST NOT
-copy spike code into an implementation branch wholesale; implementation re-enters through
+MUST NOT merge or PR a `spike/*` branch — its only exits are a findings file and deletion. Do not
+transfer spike code: the parent may receive only the committed findings file. MUST NOT copy spike
+code into an implementation branch wholesale; implementation re-enters through
 `/ca-feature` and `tdd`. Secret-handling and irreversibility rules hold even in a spike. Commits on
-a `spike/*` branch are exempt from `commit-gate` — the exemption is safe precisely because nothing
-on the branch can ever land.
+a `spike/*` branch are exempt from `commit-gate` — the exemption is safe because no spike commit is
+merged and the parent may copy only the committed findings file's contents, never spike code.
 
 ## When NOT to use
 

package/plugins/ca-pi/skills/ca-status/SKILL.md

@@ -1,13 +1,25 @@
 ---
 name: ca-status
 description: Show the project's current state at a glance — stage, open tasks, open questions, overrides since the last checkpoint, current branch. Read-only.
-argument-hint: (none)
+argument-hint: "(none) | drift"
 ---
 
 # /ca-status — state snapshot
 
 A read-only summary of `.codearbiter/` state. No skill is routed to; no file is modified.
 
+<!-- catalog-command-modes:start -->
+## Drift mode
+
+<!-- command-mode:drift legacy-route:context-check -->
+With the exact argument `drift`, load and follow
+`<plugin-root>/skills/ca-context-check/SKILL.md`. The audit begins read-only; re-scout or re-baseline may
+write only after the user's explicit selection. In drift mode the `context-check` contract governs;
+the opening summary and Hard gate below apply only to the no-argument snapshot. With no argument,
+continue with the unchanged read-only snapshot below. Reject other arguments rather than treating
+them as drift mode.
+<!-- catalog-command-modes:end -->
+
 ## Flow
 
 The orchestrator reads and presents:

package/plugins/ca-pi/skills/ca-watch/SKILL.md

@@ -6,6 +6,12 @@ argument-hint: "<PR number | url | branch>"
 
 # /ca-watch — PR CI babysitter
 
+<!-- catalog-compatibility-notice:start -->
+> Compatibility route. Prefer `/ca-pr --watch` for new usage. This installed route remains
+> functional under the command-route compatibility policy at <plugin-root>/includes/command-compatibility.md;
+> continue with the unchanged watcher workflow below.
+<!-- catalog-compatibility-notice:end -->
+
 Watch a pull request's checks to completion without babysitting them by hand. The
 wait happens server-side, so it costs nothing while CI runs; arbiter wakes once, on
 the verdict — diagnoses a red, or offers you the merge on a green. Arbiter never

package/plugins/ca-pi/includes/dev-mode.md

@@ -1,30 +0,0 @@
-<!-- codeArbiter — maintainer dev-mode detail. Loaded on demand by the orchestrator
-when the user invokes /ca-dev or /ca-arbiter. The always-on kernel (ORCHESTRATOR.md)
-keeps only the env-gate + logged + load-before-gates-off invariant as a stub; the full
-mode description lives here. -->
-
-# /dev — Maintainer Override (evaluated FIRST, every turn, before anything else)
-
-`/ca-dev` (optionally `/ca-dev "note"`) **suspends the gates entirely** to edit codeArbiter itself
-with no orchestration mediating — skill, agent, command, and hook bodies, `ORCHESTRATOR.md`, settings.
-It is the gates-off escape hatch, **not** the required lane for touching those files: normal
-development of codeArbiter — fixing a hook bug, adding a command, editing this persona — flows through
-the ordinary gated lanes (`/ca-feature`, `/ca-fix`, `/ca-chore`) and ships via PR + release, the same
-dogfooding path as any other change. Reach for `/ca-dev` only when orchestration itself is broken or
-genuinely in the way of editing it. It is **env-gated and logged**:
-
-- **Gate:** activates only when the `CODEARBITER_DEV` environment variable is set to `1`. Absent or
-  empty → refuse in one line ("dev mode requires CODEARBITER_DEV=1") and remain in orchestration.
-- **Log:** on entry, append `[ISO-8601] | BY: <git user.email> | DEV: enter | NOTE: <note or —>` to
-  `.codearbiter/overrides.log` (append with `>>`, per ORCHESTRATOR §7's append-only rule). On exit,
-  append the matching `DEV: exit` line. Dev mode is on the audit trail like any other bypass.
-- **Mode:** while active — no routing, no skills, no gates, no `[CONFIRM-NN]` surfacing, no redirect,
-  no startup presentation; a plain, direct coding assistant. Drop the transient marker
-  `<project-root>/.codearbiter/.markers/dev-active` (gitignored local UI flag). The marker is NOT the log — the overrides.log
-  lines are.
-- **Exit:** `/ca-arbiter` restores orchestration (removes the marker, writes the exit line). A new
-  session also restores it (SessionStart clears the marker); write the exit line at the next
-  opportunity if the session ended mid-dev.
-
-Even in dev mode, `overrides.log` itself is never rewritten — the append-only rule has no dev
-exception.

package/plugins/ca-pi/skills/ca-arbiter/SKILL.md

@@ -1,36 +0,0 @@
----
-name: ca-arbiter
-description: Exit maintainer dev mode — restore orchestration, remove the dev marker, log the exit.
-argument-hint: (none)
----
-
-# /ca-arbiter — restore orchestration
-
-The exit door for `/ca-dev`. No-op if dev mode is not active.
-
-## Flow
-
-1. **Log exit** — append to `<project-root>/.codearbiter/overrides.log` (append-only, `>>`):
-
-   ```
-   [ISO-8601 timestamp] | BY: <email> | DEV: exit
-   ```
-
-2. **Marker** — remove `<project-root>/.codearbiter/.markers/dev-active`.
-3. **Resume** — re-present the startup state (stage, blocking `CONFIRM-NN`, in-flight tasks) and
-   await a slash command. Orchestration, routing, and all gates are back in force.
-
-## Hard gate
-
-MUST write the `DEV: exit` line to `overrides.log` and remove the `dev-active` marker before resuming
-orchestration — the exit is on the audit trail like the entry. MUST NOT rewrite or truncate
-`overrides.log` — the append-only rule has no dev exception, on entry or exit. If a prior session
-ended mid-dev, SessionStart has already appended the synthetic `BY: session-cleanup | DEV: exit` close
-line and cleared the marker (`session-start.py`, observability-001). In that case MUST NOT write a
-second `DEV: exit` for that orphaned entry — the close is already on the trail.
-
-Session-scoped clearing (#271): SessionStart's synthetic close is now conditional on the marker
-plausibly being abandoned rather than owned by a different, still-live session — it will NOT clobber
-another concurrently-running session's live `/dev` marker or write a false `DEV: exit` for it.
-`/ca-arbiter` remains the ONLY way to cleanly close your OWN `/dev` session's audit pair; do not
-rely on a future SessionStart to do it for you.

package/plugins/ca-pi/skills/ca-dev/SKILL.md

@@ -1,42 +0,0 @@
----
-name: ca-dev
-description: Maintainer override — suspend orchestration to edit codeArbiter itself. Env-gated (CODEARBITER_DEV=1), entry/exit logged to overrides.log.
-argument-hint: "[note]"
----
-
-# /ca-dev — maintainer override
-
-Suspends orchestration for working ON codeArbiter — skill, agent, command, and hook bodies,
-`ORCHESTRATOR.md`, settings. Not for project work; for that, use the normal commands or
-`/ca-override`.
-
-## Flow
-
-1. **Env gate** — check the `CODEARBITER_DEV` environment variable. Not set to `1` → refuse in one
-   line ("dev mode requires CODEARBITER_DEV=1") and remain in orchestration. This keeps the mode a
-   deliberate maintainer posture, not a casual bypass.
-2. **Log entry** — detect identity from `git config user.email`; append to
-   `<project-root>/.codearbiter/overrides.log` (append-only, `>>`):
-
-   ```
-   [ISO-8601 timestamp] | BY: <email> | DEV: enter | NOTE: <note or —>
-   ```
-
-3. **Marker** — drop `<project-root>/.codearbiter/.markers/dev-active` (gitignored UI flag).
-4. **Mode** — plain, direct coding assistant: no routing, no skills, no gates, no `[CONFIRM-NN]`
-   surfacing, no redirect. Persists until `/ca-arbiter` or a new session.
-
-Note (#271): if another session starts in this repo while this marker is live, SessionStart no longer
-unconditionally clears it out from under you — it is session-scoped now, so a concurrently-running dev
-session's marker survives a different session's startup. See `/ca-arbiter` for the exit-path detail.
-
-## Hard gate
-
-MUST refuse without `CODEARBITER_DEV=1`. MUST write the `DEV: enter` log line before suspending
-orchestration. Even in dev mode, `overrides.log` is never rewritten — the append-only rule has no
-dev exception.
-
-## When NOT to use
-
-- Bypassing a single gate on project work → `/ca-override "reason"`.
-- Asking a question → `/ca-btw`.