@caddis/cli 0.4.55 → 0.4.57

package/bundles/antigravity-plugin/skills/implement/SKILL.md

@@ -32,8 +32,8 @@ These override everything below. They exist because branch isolation and the run
 depend on them:
 
 - **Work ONLY on the current branch.** You are already on the feature branch (the current branch,
-  `git branch --show-current`; that read is the only `git branch` form allowed). **NEVER** run
-  `git checkout`, `git switch`, `git branch <name>`, `git switch -c`, or any command that changes,
+  `git branch --show-current`; that read is the only `git branch` form allowed).
+  **NEVER** run `git checkout`, `git switch`, `git branch <name>`, `git switch -c`, or any command that changes,
   creates, or leaves the current branch. Read the default branch with
   `git symbolic-ref --short refs/remotes/origin/HEAD`, which prints `origin/<default>`: remove the
   `origin/` prefix before you compare. If that command fails (origin/HEAD is not set), the default
@@ -46,7 +46,9 @@ depend on them:
   the project's test command anywhere (config, CI, package scripts). The runner treats any such edit as
   tampering and fails the run. If the plan asks you to touch these, skip that step and note it in the
   review file instead.
-- **Commit per phase, on this branch, with a normal commit.** Use `git add <paths> && git commit -m "…"`.
+- **Commit per phase, on this branch, with a normal commit.** Use `git add <paths>`, then check `git diff --cached --name-only` lists only those paths (refuse on any
+  other staged path: a peer staged it; note it in the review file), then `git commit -m "…" -- <paths>`.
+  Never `git add -A`, `.`, `-u` or a folder, and never `git commit -a` (the guard denies them).
   Do not use `--no-verify` (a pre-commit hook guards the branch — let it run). Do not amend or rebase
   prior commits. One phase → one (or more) commit(s); never one giant end-of-run commit.
 - **Never ask a question, never pause, never wait for input.** No human will answer. Never use
@@ -55,7 +57,7 @@ depend on them:
 
 ## Three rules: one attempt, one review
 1. **Think before you send.** Before a task goes to any coder, write its edge cases and check the facts it depends on (one query or one file read).
-2. **Run it before review.** The coder runs the same checks as CI (name the exact commands in the task). Then run the change once on real data.
+2. **Run it before review.** The coder runs only the tests of the files it touched, in the foreground, each command under 10 minutes (split into parts if needed). Name the exact commands in the task. Never start the full suite in the background and never wait on a monitor for it: CI runs the full suite on every PR. Then run the change once on real data.
 3. **Review by tier.** Run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" review-tier --range <base>...HEAD` (add `--plan <plan> --phase <N>` inside a plan; no `TIER:` line means tier 2).
    Tier 0: gates only. Tier 1-small: your self-check only. Tier 1: one review by another vendor; stop at
    the first CLEAN. Tier 2: two reviewers of two other vendors, in one round. Fix blocking findings only;
@@ -164,8 +166,11 @@ row, visible to any later reader without anyone having to catch it live.
      so it proves timing by design.
 3. **ACCEPT** means run `caddis_lanes.py accept --plan <plan> --phase N --attempt K --message
    "<the phase's commit message>"`. It runs only on the programme branch, never on `main`. It
-   refuses a `BLOCKING` review. If you checked the finding and it is false, add
-   `--override-review "<why the finding is false>"`. The script records that reason in the packet.
+   refuses a `BLOCKING` review and a `MISSING` review (no verdict: provider down, 429, filter
+   refusal). If you checked the finding and it is false, add
+   `--override-review "<why the finding is false>"`. For a `MISSING` review, re-run the review
+   first; add the override only if the owner accepts a phase with no vendor verdict. The reason
+   must not be empty. The script records it in the packet.
 4. Allow at most **2 attempts** per phase on a non-Claude lane. An out-of-budget switch is not an
    attempt. The owner can request TAKEOVER at any time.
 5. A UI phase needs a `ui-design-reviewer` screenshot review before ACCEPT. This rule applies
@@ -180,12 +185,17 @@ row, visible to any later reader without anyone having to catch it live.
    this wording without `--allow-load`. Only the owner gives that flag.
 7b. **Write test economy into every agent brief, not only the lane prompt.** The script already adds it
    to its lane prompts. A brief you write yourself (an Agent-tool subagent, a peer session) needs the same
-   five lines: after each step run only the tests for the file or module you changed; run the full suite only
-   for the baseline and once at the end; run no review loop inside the agent (you review); report progress
-   every 20 minutes; never start a second heavy test run while one is still running. **Two parallel agents
-   must not both run full suites.** Measured 2026-10-02 on one shared box: a 2,063-test suite took 2.7 min
+   five lines: after each step run only the tests for the file or module you changed, in the foreground, each
+   command under 10 minutes; never start the full suite, and never wait on a monitor for it (CI runs it on every PR);
+   run no review loop inside the agent (you review); report progress
+   every 20 minutes; never start a second heavy test run while one is still running. **Agents never run
+   the full suite.** Measured 2026-10-02 on one shared box: a 2,063-test suite took 2.7 min
    alone and 6.7 min beside a second test-heavy agent, and one agent's brief (baseline, tests after each of 9
    module switches, full gates, in-agent review) cost 30-40 of its 59 minutes.
+   On 18-19 Oct 2026 agents started the full suite (about 40 min) in the background and waited through
+   monitors with their own timeouts. One missed the finish and sat "Waiting" for over 1 h. Four parallel
+   suites also slowed the box. The orchestrator checks a stalled agent by process (pytest alive, CPU moving),
+   not by its monitor.
 8. Record these Tracker values:
    - `Model` = the packet's `model`.
    - `Lane` = the lanes tried, joined with ` -> ` and followed by the reason. For example,
@@ -234,7 +244,8 @@ report — do not redo completed work.
    - **REFACTOR** — clean names/structure/duplication while keeping green.
    - **VERIFY** — run the phase's exit-gate check (the literal command the plan names) and the relevant
      suite so you didn't regress. Do not claim a state you did not run.
-   - **COMMIT** — `git add` the phase's files and `git commit` with the phase's conventional-commit message
+   - **COMMIT** — `git add` the phase's files by name, check `git diff --cached --name-only` shows only
+     them, and `git commit -m "…" -- <files>` with the phase's conventional-commit message
      (from the plan, or a faithful equivalent). Stay on the current branch.
    - **UPDATE THE TRACKER** — edit the plan's `## Tracker` row for this phase: set Status to `done`, fill
      the short commit hash (`git rev-parse --short HEAD`), set the `Lane` column to the lane this phase
@@ -282,10 +293,12 @@ You:     /clear, then paste ↓
 **In headless/runner mode, never ask — halt, write the block, and exit.** The block is how a
 non-interactive run tells a human what it needs; asking is still forbidden.
 
-**4. Run the tests yourself.** After the last phase you complete, run the project's full test command once
-more and record the real result. The runner will re-run it independently and that decides success — but
-you run it too so your reported `"tests"` value is truthful, not assumed. Never report `"passed"` on a
-suite you did not see go green.
+**4. Run the tests yourself.** After the last phase you complete, run the tests of the files you touched
+once more, in the foreground, each command under 10 minutes (split into parts if needed), and record the
+real result. Never start the full suite in the background and never wait on a monitor for it. CI runs the
+full suite on every PR and is the gate before merge. The runner re-runs its own gate independently and
+that decides success — but you run your tests too so your reported `"tests"` value is truthful, not
+assumed. Never report `"passed"` on tests you did not see go green.
 
 **4b. If every phase is now done, tidy the plan into `done/` IN THE SAME COMMIT.** Only when the
 whole plan is finished (every `## Tracker` row is `done`, no halt, no blocker) — a mid-plan halt is
@@ -303,8 +316,9 @@ for a later session to clean up, and nothing is left uncommitted. Order matters:
    no other file. **Refuse** if it would touch anything else, or prints `ERROR` or `NOT MOVED`:
    stop, do not commit the move, and report the output in the review file.
 3. `git add` the moved plan by name (`.caddis/plans/done/<plan>.md`, so the status and Tracker edits
-   are staged with the rename), then make the final commit. The move, the status and the last
-   Tracker row land in one commit.
+   are staged with the rename), then make the final commit with
+   `git commit -m "…" -- .caddis/plans/<plan>.md .caddis/plans/done/<plan>.md` (both sides of the
+   rename). The move, the status and the last Tracker row land in one commit.
 
 (Falls back to `scripts/caddis_tidy.py` from a source checkout; **skip this step if the script is
 missing** — degrades open, same as the gates in Step 1.) A **collision** (`done/<name>` already

package/bundles/antigravity-plugin/skills/mmr/SKILL.md

@@ -22,7 +22,7 @@ The exit codes follow `caddis_exit.py`: 0 clean, 1 blocked, 2 advisory, 3 could
 
 ## Three rules: one attempt, one review
 1. **Think before you send.** Before a task goes to any coder, write its edge cases and check the facts it depends on (one query or one file read).
-2. **Run it before review.** The coder runs the same checks as CI (name the exact commands in the task). Then run the change once on real data.
+2. **Run it before review.** The coder runs only the tests of the files it touched, in the foreground, each command under 10 minutes (split into parts if needed). Name the exact commands in the task. Never start the full suite in the background and never wait on a monitor for it: CI runs the full suite on every PR. Then run the change once on real data.
 3. **Review by tier.** Run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" review-tier --range <base>...HEAD` (add `--plan <plan> --phase <N>` inside a plan; no `TIER:` line means tier 2).
    Tier 0: gates only. Tier 1-small: your self-check only. Tier 1: one review by another vendor; stop at
    the first CLEAN. Tier 2: two reviewers of two other vendors, in one round. Fix blocking findings only;

package/bundles/antigravity-plugin/skills/pr-merge/SKILL.md

@@ -9,7 +9,7 @@ End-to-end delivery of feature-branch work through the reviewed lane in one shot
 push safely, create or update the Pull Request, monitor CI checks to green, merge into the default
 branch, validate the deployment, and clean up the feature branch.
 
-For a hotfix straight to the default branch with no PR ceremony, use `/ship` (the express lane) instead.
+For a quick commit and push of a feature branch, use `/ship` (the express lane). It never pushes the default branch.
 To open a PR and stop at green for human review without merging, use `/ship-pr`.
 To merge an already-opened PR, use `/ship-merge`.
 
@@ -29,11 +29,47 @@ can be provided.
 Read `AGENTS.md` + the detected workflow file(s) first for the repo's real gate names, default
 branch, and merge conventions — never assume `main`, never assume job names.
 
+## Step 0b — Is this checkout safe to move?
+
+<!-- checkout-safety: keep byte-identical in pr-merge, ship-pr, ship-merge and cloud-phases; a test pins it -->
+Some steps below move the files of this checkout (`git rebase`, `switch`, `checkout <branch>`, `pull`, `merge`,
+`stash`, `reset --hard`). Before the first of them, run:
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_checkout_guard.py" shared --root .
+```
+It prints `SHARED: yes <reason>` or `SHARED: no` and exits 0. It says yes when the repo's `AGENTS.md` has a line
+`Shared checkout: yes` (a dev service serves from this checkout), or when `git status` lists a change. With no
+`--own-files`, every change counts as another session's. A linked worktree is never shared.
+
+- **On `SHARED: no`,** do the steps as written, in this checkout.
+- **On `SHARED: yes`,** never move this checkout. Leave its changes as they are, and report them. Instead:
+  - **Rebase:** `git worktree add --detach "$TEMP/<repo>-rebase" <branch>`, then
+    `git -C <worktree> rebase origin/<default>` and `git -C <worktree> push --force-with-lease origin HEAD:<branch>`.
+  - **Pull a branch to test it:** `git fetch origin`, then
+    `git worktree add --detach "$TEMP/<repo>-<branch>" origin/<branch>` (for the default branch,
+    `origin/<default>`), and run the gates there. Install dependencies fresh; never link `node_modules` or a venv.
+  - **Clean up after a merge:** do not switch or pull. Run `git fetch --prune`, then
+    `git fetch origin <default>:<default>`: it fast-forwards the default branch with no checkout. Git refuses when a
+    checkout has the default branch out; then leave it and report it. Delete the local feature branch only when no
+    checkout has it out.
+  - Remove each worktree you made when its step ends: `git worktree remove <worktree>`.
+
+`$TEMP` is `%TEMP%` (`$env:TEMP` in PowerShell). The caddis guard checks only the `Shared checkout: yes` line in
+`AGENTS.md`, not a dirty tree: with that line, it asks before a tree move, and denies it in a headless session.
+<!-- /checkout-safety -->
+
 ## Step 1 — Refuse on the default branch
 
-A PR is *branch → default*. If HEAD **is** the default branch, stop and point at `/ship` — there is
-nothing to open a PR from. (Offer to create a feature branch from the current work if the changes
-are uncommitted.)
+A PR is *branch → default*. Read the default branch as a bare name: `git rev-parse --abbrev-ref
+origin/HEAD` prints `origin/<default>`, so strip the `origin/` prefix before you compare.
+```bash
+d=$(git rev-parse --abbrev-ref origin/HEAD 2>/dev/null) && d=${d#origin/}   # prints origin/<default>: strip origin/
+[ -n "$d" ] || d=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)   # origin/HEAD not set
+git branch --show-current                                                  # compare with "$d"
+```
+If HEAD **is** the default branch, stop: there is nothing to open a PR from. Offer to move the
+uncommitted work to a feature branch (`git switch -c <branch>`), or run `/ship`, which does that and
+hands back here.
 
 ## Step 2 — Preflight (local gates mirroring CI)
 
@@ -69,6 +105,8 @@ Run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" review-tier --range <
   git rebase <default-branch>
   git push --force-with-lease origin <branch> # never bare --force
   ```
+- In a shared checkout (Step 0b says `SHARED: yes`), never rebase here: rebase in a detached worktree, as
+  Step 0b says.
 
 ## Step 5 — Push + create or update the PR
 
@@ -141,6 +179,8 @@ If the default branch triggers an automated deployment pipeline:
 **Only after** the merge is complete and deployment (if any) is validated green:
 - Run `git status --short`. If it shows changes you did not make, do not switch, stash, reset or commit:
   leave them, report them, and stop cleanup here (a shared checkout often holds a peer's edits).
+- In a shared checkout (Step 0b says `SHARED: yes`), skip the switch and the pull below. Clean up as Step 0b
+  says: `git fetch --prune`, `git fetch origin <default-branch>:<default-branch>`, then delete the branches.
 - Fetch and prune: `git fetch --prune`.
 - Switch to the default branch: `git switch <default-branch>`.
 - Fast-forward to the merge commit: `git pull --ff-only origin <default-branch>`.
@@ -168,7 +208,7 @@ Cleanup:       remote branch deleted / local branch deleted / backup ref dropped
 
 - Never merge a PR whose required checks are red or absent.
 - Never delete a feature branch before its merge is confirmed and any deploy validated.
-- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies the first two).
+- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies all three, and `git add -u` and `git commit -a`). Commit with `git commit -m "..." -- <files>`, after `git diff --cached --name-only` shows only those files.
 - Never force-push without a `backup/*-preship` recovery ref; force pushes are `--force-with-lease` only.
 - Never edit a workflow file (`.gitea/workflows/`, `.github/workflows/`) to make a gate pass — fix the source.
 - Local-only lane: refuse + point at `/ship`. On the default branch: stop + point at `/ship`.

package/bundles/antigravity-plugin/skills/refactoring/SKILL.md

@@ -128,7 +128,8 @@ Activate when:
    ```bash
    git status --short          # stage the files you changed, by name
    git add tests/test_<module>.py
-   git commit -m "chore: add tests before refactoring"
+   git diff --cached --name-only  # only the files you named
+   git commit -m "chore: add tests before refactoring" -- tests/test_<module>.py
    ```
 
 ---
@@ -387,7 +388,8 @@ DEPRECATED_VALUE = 5              # Not referenced
 
 2. **If tests pass, commit**
    ```bash
-   git commit -m "refactor: extract validation to separate method"
+   git add <files you changed>
+   git commit -m "refactor: extract validation to separate method" -- <files you changed>
    ```
 
 3. **If tests fail, revert**

package/bundles/antigravity-plugin/skills/review-pr/SKILL.md

@@ -34,8 +34,11 @@ gh pr view <n> --repo <owner/repo> --json number,title,author,state,isDraft,merg
 - the PR is **merged or closed** — there is nothing to decide;
 - it is a **draft** — say so and ask whether to continue;
 - **the operator is the author.** GitHub does not allow approving your own PR. Say it plainly, and
-  say the alternatives: have someone else approve it, or merge with an admin bypass
-  (`gh pr merge <n> --squash --admin`). Do not silently produce a review they cannot submit.
+  say the alternatives: have someone else approve it, or merge with an admin bypass. An admin
+  bypass skips the approval only, never the CI rule: merge only after `caddis_lanes.py ci-watch
+  --pr <n>` prints `RESULT: pass`, with no default-branch run in progress (section 4)
+  (`gh pr merge <n> --squash --admin --match-head-commit <watched head>`). Do not silently produce a
+  review they cannot submit.
 
 ## 2. Gather what the decision needs
 
@@ -85,12 +88,18 @@ Lead with the verdict. Keep it short enough to read before deciding:
 - **CI** — green, red, or still running. Name the failing check.
 - **Merge state** — and what would clear it.
 
-Then print the exact commands, and stop:
+Then print the exact commands, and stop. The merge follows the CI rule: wait with ci-watch, and
+merge only on `RESULT: pass`, only the head it watched (`HEAD:`), and never while a CI run on the
+default branch is in progress.
 
 ```bash
 # approve
 gh pr review <n> --repo <owner/repo> --approve
-gh pr merge  <n> --repo <owner/repo> --squash --delete-branch
+# wait for CI; merge only on RESULT: pass. HEAD: is the watched head
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --pr <n> --repo <owner/repo>
+# no in_progress or queued run may be listed
+gh run list --repo <owner/repo> --branch <default branch> --json status
+gh pr merge  <n> --repo <owner/repo> --squash --delete-branch --match-head-commit <watched head>
 
 # or ask for changes
 gh pr review <n> --repo <owner/repo> --request-changes --body "..."

package/bundles/antigravity-plugin/skills/roadmap/SKILL.md

@@ -89,8 +89,26 @@ python scripts/caddis_roadmap.py recheck --roadmap <slug>
   `Depends on` milestone `done` or `not-needed`, and no open blocker other than `data-condition` (exit 1 names it),
   then runs the Exit check (300 s): pass -> `done`; fail with a `data-condition` blocker -> `code-done/data-pending`;
   fail otherwise -> an `external` blocker
-  `exit check failing (exit <n>)` (never the command's output). A milestone with no phase refs and no Exit check is
-  refused (exit 4).
+  `exit check failing (exit <n>): <tail>` (the last 3 non-empty output lines on one line, the whole reason at most
+  200 characters, masked as below). The part before `: ` is the blocker's identity: a later rollup adds no second
+  row, and `unblock --reason "exit check failing (exit <n>)"` removes every row of that prefix. A check that fails
+  on a missing environment (exit 9009/127/126, or output in its last 40 lines such as `No module named`,
+  `Cannot find module`, `ENOENT`, `run npm run build first`) is exit 3: no blocker, no PR. Either way the last 64 KB
+  of output (masked the same way) go to `.local/exit-check-<id>-<utc>.log` (the newest 10 stay), and rollup prints
+  the path. A milestone with no phase refs and no Exit check is refused (exit 4).
+  **Masked** in the reason and the log: the values of secret-named variables (`caddis_redact`); a whole
+  `-----BEGIN ... PRIVATE KEY-----` block up to its END line (or the end of the output); AWS, GitHub, Slack and JWT
+  tokens; a quoted value after a `password`/`secret`/`api_key`/`token` name, spaces included; an unquoted
+  `*PASSWORD*=`/`*TOKEN*=`-style line value; URL credentials (`scheme://***@`); and absolute paths as `<path>`: a
+  drive or UNC path up to the end of the line, a quote, `<`, `>` or `|`, and a `/home/`, `/Users/`, `/tmp/`, `/root/`,
+  `/var/`, `/etc/` or `/opt/` path up to the end of the line or a quote. Other text is published as printed.
+- **`**Exit setup:** <command>`** (optional, one per roadmap, beside `Runner host:`; no `|`) runs in the temp worktree
+  before every Exit check (900 s). It must install fresh into that worktree, for example
+  `python -m venv .venv && .venv\Scripts\pip install -e .[dev]` or `npm ci && npm run build`. Each command runs in a
+  new shell, so the Exit check must call the venv itself: `.venv\Scripts\python -m pytest tests -q`, not
+  `python -m pytest`. Never link or junction a shared venv or `node_modules`: the worktree is removed with `--force`
+  after the check. A setup that fails or times out is exit 3 and writes nothing; the runner stops
+  `BLOCKED rollup not run` and the owner decides (the stop names a docs PR that was opened but not merged).
 - **Owner-only changes:** `set` Status `not-needed`, any `set` Owner, `unblock` of an `owner-gate`, and `block --check`
   (recheck runs that command unattended later). They need `--by-owner` and are refused headless: `CADDIS_HEADLESS`
   or `CLAUDECODE` in the environment (even empty), stdin not a terminal, or on
@@ -179,8 +197,8 @@ Stops (each one notifies and releases the lock): a STOP file (`~/.caddis/STOP` o
 `caddis_spend.py` still counts across runs), a lock or batch claim that cannot be written
 (`BLOCKED claim not written`, before any session), the agy spend cap refusing a reservation, three sessions
 with no newly merged phase, a roadmap write that fails, and the **snapshot guard**: one baseline for the whole run.
-The Milestones and Blockers tables (every cell of every row, rows added, removed or moved) and the `Runner host` line
-are frozen. Every origin read (each `next`, after the runner's own writes, after each session) is compared with the
+The Milestones and Blockers tables (every cell of every row, rows added, removed or moved), the `Runner host` line
+and the `**Exit setup:**` line are frozen. Every origin read (each `next`, after the runner's own writes, after each session) is compared with the
 previous one; the only differences allowed are the exact edits the runner itself made and recorded for that read: a
 Status it set, a blocker row it added, and what a rollup's audit entry (`changes.jsonl`) says it actually wrote.
 Anything else stops the run `FAILED roadmap changed`.
@@ -206,7 +224,10 @@ refuses a plan that a roadmap lock names, at start and before every session. `-D
 the session command, the worktree and any pending rollup, skips the host check, writes no files and starts nothing; it
 does run `git fetch`, which updates the remote-tracking refs. `-GhAccount <login>` (recorded in the launch options,
 passed on by the recheck task and in the printed task) makes every gh call of the runner and of `--last-stop` use
-GH_TOKEN from `gh auth token -u <login>`; on a machine with several gh logins, give the repo's account. A gh call that
+GH_TOKEN from `gh auth token -u <login>`; on a machine with several gh logins, give the repo's account. The sessions
+never get that token, nor GH_TOKEN, GITHUB_TOKEN, GH_ENTERPRISE_TOKEN, NPM_TOKEN or NODE_AUTH_TOKEN from the
+environment; with CADDIS_HEADLESS=1 the guard denies `git push`, `gh pr merge|create`, `gh release`, a write through
+`gh api`, `gh workflow run` and package publishes. Only the runner publishes. A gh call that
 cannot answer (gh missing, 401, 404) is an error, never "not merged": the run stops
 `BLOCKED gh cannot see <repo> with account <login>`, notified and recorded.
 
@@ -223,7 +244,8 @@ phases) holds the whole plan for every other roadmap and for plan mode. At the t
 every milestone that waits only for its rollup (Status not finished, every phase merged, and the same rule as
 `next`: no blocker, dependencies finished, Owner the runner); `--last-stop` says `rollup-ready:` for such a milestone,
 so recheck restarts the runner. A sweep rollup that writes nothing stops `BLOCKED rollup of <id> wrote nothing`
-(recorded, not restartable) and is not retried or reported until the roadmap changes. The dry run lists them first. If
+(recorded, not restartable) and is not retried or reported until the roadmap changes. A rollup that exits 3 (its
+exit check or Exit setup could not run) stops `BLOCKED rollup not run: <id> ...` (not restartable; the owner decides). The dry run lists them first. If
 the owner edits the roadmap during a merge wait, the restart stops `FAILED roadmap changed ...` and names the
 recovery: `roadmap-run.ps1 -Roadmap <slug> -AcceptRoadmap` (owner only, refused headless) takes the runner lock (a live
 runner refuses it), prints the diff from the published baseline, asks you to type `accept` (or `--yes`), and accepts

package/bundles/antigravity-plugin/skills/roadmap/assets/review-protocol.md

@@ -1,15 +1,15 @@
 ---
 type: reference
 title: Review protocol
-description: The review method one model can rely on - invariants, inputs and writers, shared state, execute what the change promises, tests, docs, then severity (only blocking stops the merge; each finding needs a reproduction), one FINDING line per finding and an END REVIEW line. caddis_review.py sends it to every review run.
+description: The review method one model can rely on - invariants, inputs and writers, shared state, check what the change promises, tests, docs, then severity (only blocking stops the merge; each finding needs a reproduction), one FINDING line per finding and an END REVIEW line. caddis_review.py sends it to every review run.
 status: current
 ---
 
 # Review protocol (generic, any diff)
 
-You review a diff. You do NOT edit, create or delete files, and you do not commit. You may read files and run commands
-(tests, dry runs, the commands that plans, cards and docs name). Work through ALL steps in order. Do not stop at the
-first finding. Include a short section per step, in order.
+You review a diff. You read only: you have Read, Grep and Glob and no shell, so you run no test and no command, and
+you do not edit, create or delete files. The diff is in the prompt. Tests are the implementer's and CI's job. Work
+through ALL steps in order. Do not stop at the first finding. Include a short section per step, in order.
 
 ## Step 1 - Purpose and invariants
 Read the card, the plan or design section it cites, and the diff. Write the list of INVARIANTS this change must keep:
@@ -26,12 +26,14 @@ accident or on purpose? This includes the agent or session the code is meant to
 List state that two runs, two kinds of target, or two processes could share (files, locks, relays, logs, caches).
 Can they collide? Can one read the other's output as its own?
 
-## Step 4 - Execute what the change promises
-Run the tests the card names. Then run every command that the plan, its exit gates, the docs or the skill text say
-should work for this change (dry runs, the documented usage lines), exactly as written. Use the repo's OWN fixtures
-and example files, not ones you build, and run unattended scripts (hooks, runners) as they are really run (as a script,
-with a real payload). Compare risky behaviour with the parent commit when the change claims to fix or tighten
-something. Report any that fail or that cannot work as documented.
+## Step 4 - Check what the change promises
+For every command that the plan, its exit gates, the docs or the skill text say should work for this change (the
+documented usage lines, exactly as written), follow it through the code by reading: the argument parsing, the paths it
+reads and writes, the repo's OWN fixtures and example files. Read unattended scripts (hooks, runners) as they are
+really run (as a script, with a real payload). Compare risky behaviour with the code before the change (the `-` lines
+of the diff) when the change claims to fix or tighten something. Report any that would fail or that cannot work as
+documented. For a check you cannot settle by reading, write one line `not executed: <command> (reviewer has no
+shell)`.
 
 ## Step 5 - Tests
 For each new or changed test: could it pass for the wrong reason (no assertion that can fail, mocked away the thing
@@ -52,9 +54,10 @@ Severity rule. Only **blocking** stops the merge, so use it with care:
   negative test, a doc that is wrong in a way that does not make a command fail, an error message that misleads.
 - **nit** = style and wording.
 
-Every finding needs a concrete reproduction: a command, an input or a test that shows the failure, written in the
-failure scenario. A finding without a reproduction is a **nit**, whatever its severity would otherwise be. Do not
-write "might", "could in theory" or "a future change may": show it or call it a nit.
+Every finding needs a concrete reproduction: a command, an input or a test that would show the failure, written in
+the failure scenario (you do not run it; the implementer does). A finding without a reproduction is a **nit**,
+whatever its severity would otherwise be. Do not write "might", "could in theory" or "a future change may": show it
+or call it a nit.
 
 The gate exits by the findings. A **blocking** finding fails it. **should-fix** and **nit** findings do not: they are
 listed in the report under "Follow-up (not blocking)". The tool allows 3 completed review rounds for a phase; the 4th completed round

package/bundles/antigravity-plugin/skills/ship/SKILL.md

@@ -9,11 +9,12 @@ Ship the current working changes via this repo's actual delivery pipeline. The p
 repo, so **detect it first**, then follow the matching lane. Preflight, staging, and commit are
 identical across lanes; only monitoring and validation differ.
 
-> **This is the express lane** — it pushes straight to the default branch with no review pause.
-> Right for a hotfix. On a repo where that push deploys to production, Step 2c stops it before the
-> push and the owner merges. **For feature work, use the reviewed lane instead: `/ship-pr`** (open a
-> PR, monitor CI, stop at green) **→ `/ship-merge`** (merge the green PR behind a deploy-confirm,
-> validate, clean up).
+> **This is the express lane** — commit, push the current feature branch and watch its CI, with no
+> review pause. **It never pushes to the default branch.** On the default branch (Gitea or GitHub lane)
+> it moves the change to a new branch and hands over to the reviewed lane: **`/caddis:ship-pr`** (open
+> a PR, monitor CI, stop at green) **→ `/caddis:ship-merge`** (merge the green PR behind a
+> deploy-confirm, validate, clean up). Why: a direct push skips the PR, the ci-watch `RESULT: pass` on
+> the watched head and the check that no default-branch run is in progress.
 
 Optional message: **$ARGUMENTS** (if empty, derive a conventional commit message from staged changes)
 
@@ -36,13 +37,32 @@ names, branch, and service identifiers — never assume.
 - Tests: run only if the user says they're needed or a gate explicitly requires them
 - Fix any failures before proceeding. Do not commit broken code.
 
-**2. STAGE + COMMIT** — Stage only the intended files, by name (never `git add -A`, `git add .` or a folder):
+**1b. BRANCH CHECK** — Read the default branch as a bare name (don't assume `main`) and the current
+branch. `git rev-parse --abbrev-ref origin/HEAD` prints `origin/<default>`, so strip the `origin/`
+prefix before you compare, or the check never matches:
+```bash
+d=$(git rev-parse --abbrev-ref origin/HEAD 2>/dev/null) && d=${d#origin/}   # prints origin/<default>: strip origin/
+[ -n "$d" ] || d=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)   # origin/HEAD not set
+git branch --show-current                                                  # compare with "$d"
+```
+- **On a non-default branch:** continue at Step 2, then Step 3 pushes that branch.
+- **On the default branch, Gitea or GitHub lane:** do not commit here. Run `git switch -c ship/<slug>`
+  (the uncommitted changes go with you) and commit on it (Step 2). Then **STOP: `/ship` ends here.**
+  Do not run Step 3 or later. Hand over to `/caddis:ship-pr` → `/caddis:ship-merge`.
+  A direct push to the default branch is refused: it skips the PR, the CI pass on the watched head
+  and the in-progress check.
+- **Local-only lane:** there is no CI and no PR; commit where you are.
+
+**2. STAGE + COMMIT** — Stage only the intended files, by name (never `git add -A`, `git add .`, `git add -u`, a folder, or `git commit -a`):
 ```
 git status --short      # confirm what's staged
 git add <specific files>
-git commit -m "<type>(<scope>): <message>"
+git diff --cached --name-only   # must list ONLY <specific files>
+git commit -m "<type>(<scope>): <message>" -- <specific files>
 git rev-parse HEAD      # record SHA for monitoring
 ```
+If `git diff --cached --name-only` lists a path you did not change, **stop**: a peer staged it. Do not
+commit, unstage or stash it; report it. `-- <files>` commits only the named files even then.
 Use conventional commits: `fix:`, `feat:`, `chore:`, `refactor:`, `docs:`. Scope = affected module.
 
 **2b. CROSS-REVIEW TRIGGER** — `ship` has no review pause at all, which is how sixteen fixes reached production unreviewed in one day.
@@ -52,10 +72,12 @@ Run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" review-tier --range <
 `<base>` is `origin/<default branch>` (on the default branch itself, the commit before this change). Tier 0 or 1-small: no model review. Tier 1: one `/caddis:cross-review`. Tier 2: two reviewers of two other vendors in one round. No `TIER:` line means tier 2.
 <!-- /shared:cross-review-trigger -->
 
-**3. PUSH** — to the repo's default branch (confirm the branch first; don't assume `main`):
+**3. PUSH** — only when Step 1b found a non-default branch (on the default branch, `/ship` stopped at Step 2):
 ```
-git push origin <branch>
+git push -u origin <feature branch>
 ```
+Never `git push origin <default branch>`: the change reaches the default branch only through
+`/caddis:ship-pr` → `/caddis:ship-merge`, which merge on ci-watch `RESULT: pass` at the watched head.
 Confirm the push succeeded and the SHA is accepted by the remote. (Local-only lane: skip if there is
 no remote, and note that nothing was pushed.)
 
@@ -119,7 +141,7 @@ Small work that does not meet a trigger skips its block.
 
 ## Rules
 - Never push before preflight gates are green.
-- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies the first two).
+- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies all three, and `git add -u` and `git commit -a`). Commit with `git commit -m "..." -- <files>`, after `git diff --cached --name-only` shows only those files.
 - Do not edit a workflow file (`.gitea/workflows/` or `.github/workflows/`) to make a failing gate
   pass — fix the source.
 - Gitea lane: tag-triggered runs after `release_metadata` are expected; verify `deploy_prod` is

package/bundles/antigravity-plugin/skills/ship-merge/SKILL.md

@@ -28,6 +28,35 @@ Resolve the target PR from `$ARGUMENTS`, else the current branch's open PR. No o
 that and point at `/ship-pr`. Read `AGENTS.md` + the workflow file(s) for the repo's real deploy
 job names and default branch — never assume.
 
+## Step 0b — Is this checkout safe to move?
+
+<!-- checkout-safety: keep byte-identical in pr-merge, ship-pr, ship-merge and cloud-phases; a test pins it -->
+Some steps below move the files of this checkout (`git rebase`, `switch`, `checkout <branch>`, `pull`, `merge`,
+`stash`, `reset --hard`). Before the first of them, run:
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_checkout_guard.py" shared --root .
+```
+It prints `SHARED: yes <reason>` or `SHARED: no` and exits 0. It says yes when the repo's `AGENTS.md` has a line
+`Shared checkout: yes` (a dev service serves from this checkout), or when `git status` lists a change. With no
+`--own-files`, every change counts as another session's. A linked worktree is never shared.
+
+- **On `SHARED: no`,** do the steps as written, in this checkout.
+- **On `SHARED: yes`,** never move this checkout. Leave its changes as they are, and report them. Instead:
+  - **Rebase:** `git worktree add --detach "$TEMP/<repo>-rebase" <branch>`, then
+    `git -C <worktree> rebase origin/<default>` and `git -C <worktree> push --force-with-lease origin HEAD:<branch>`.
+  - **Pull a branch to test it:** `git fetch origin`, then
+    `git worktree add --detach "$TEMP/<repo>-<branch>" origin/<branch>` (for the default branch,
+    `origin/<default>`), and run the gates there. Install dependencies fresh; never link `node_modules` or a venv.
+  - **Clean up after a merge:** do not switch or pull. Run `git fetch --prune`, then
+    `git fetch origin <default>:<default>`: it fast-forwards the default branch with no checkout. Git refuses when a
+    checkout has the default branch out; then leave it and report it. Delete the local feature branch only when no
+    checkout has it out.
+  - Remove each worktree you made when its step ends: `git worktree remove <worktree>`.
+
+`$TEMP` is `%TEMP%` (`$env:TEMP` in PowerShell). The caddis guard checks only the `Shared checkout: yes` line in
+`AGENTS.md`, not a dirty tree: with that line, it asks before a tree move, and denies it in a headless session.
+<!-- /checkout-safety -->
+
 ## Step 1 — Refuse unless green + mergeable + reviewed
 
 All of, per the repo's own rules:
@@ -102,6 +131,8 @@ attempt a silent re-deploy — and **skip cleanup** (Step 6).
 **Only after** Step 5 is green:
 - Run `git status --short`. If it shows changes you did not make, do not switch, stash, reset or commit:
   leave them, report them, and stop cleanup here.
+- In a shared checkout (Step 0b says `SHARED: yes`), do not switch or pull. Clean up as Step 0b says:
+  `git fetch --prune`, `git fetch origin <default-branch>:<default-branch>`, then delete the branches.
 - `git fetch --prune`, then switch to the default branch and fast-forward it to the merge commit.
 - Delete the **remote** feature branch; delete the **local** feature branch (for a squash merge, compare
   the branch tree with the merged tree first, not ancestry).
@@ -123,7 +154,7 @@ Cleanup:       remote branch ✗ deleted / local ✗ deleted / backup ref droppe
 ## Rules
 - Never merge without: green required checks **and** the explicit human deploy-confirm.
 - Never delete a branch before its deploy is validated green.
-- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies the first two). Never edit a workflow file to make a gate pass.
+- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies all three, and `git add -u` and `git commit -a`). Commit with `git commit -m "..." -- <files>`, after `git diff --cached --name-only` shows only those files. Never edit a workflow file to make a gate pass.
 - Local-only lane: no PR, no merge — refuse and point at `/ship`.
 
 ## Skill reference

package/bundles/antigravity-plugin/skills/ship-pr/SKILL.md

@@ -10,7 +10,7 @@ after. This command does the mechanics only: push safely, open (or update) the P
 and **stop at green** with a mergeability verdict. It **never merges and never deploys** — on these
 repos merge == deploy, so the merge stays a separate, deliberate act: `/ship-merge`.
 
-For a hotfix straight to the default branch, use `/ship` (the express lane) instead.
+For a quick commit and push of a feature branch, use `/ship` (the express lane). It never pushes the default branch.
 
 Optional argument: **$ARGUMENTS** (PR title override; default = derived from the branch's
 conventional-commit summary).
@@ -27,11 +27,47 @@ conventional-commit summary).
 Read `AGENTS.md` + the detected workflow file(s) first for the repo's real gate names, default
 branch, and merge conventions — never assume `main`, never assume job names.
 
+## Step 0b — Is this checkout safe to move?
+
+<!-- checkout-safety: keep byte-identical in pr-merge, ship-pr, ship-merge and cloud-phases; a test pins it -->
+Some steps below move the files of this checkout (`git rebase`, `switch`, `checkout <branch>`, `pull`, `merge`,
+`stash`, `reset --hard`). Before the first of them, run:
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_checkout_guard.py" shared --root .
+```
+It prints `SHARED: yes <reason>` or `SHARED: no` and exits 0. It says yes when the repo's `AGENTS.md` has a line
+`Shared checkout: yes` (a dev service serves from this checkout), or when `git status` lists a change. With no
+`--own-files`, every change counts as another session's. A linked worktree is never shared.
+
+- **On `SHARED: no`,** do the steps as written, in this checkout.
+- **On `SHARED: yes`,** never move this checkout. Leave its changes as they are, and report them. Instead:
+  - **Rebase:** `git worktree add --detach "$TEMP/<repo>-rebase" <branch>`, then
+    `git -C <worktree> rebase origin/<default>` and `git -C <worktree> push --force-with-lease origin HEAD:<branch>`.
+  - **Pull a branch to test it:** `git fetch origin`, then
+    `git worktree add --detach "$TEMP/<repo>-<branch>" origin/<branch>` (for the default branch,
+    `origin/<default>`), and run the gates there. Install dependencies fresh; never link `node_modules` or a venv.
+  - **Clean up after a merge:** do not switch or pull. Run `git fetch --prune`, then
+    `git fetch origin <default>:<default>`: it fast-forwards the default branch with no checkout. Git refuses when a
+    checkout has the default branch out; then leave it and report it. Delete the local feature branch only when no
+    checkout has it out.
+  - Remove each worktree you made when its step ends: `git worktree remove <worktree>`.
+
+`$TEMP` is `%TEMP%` (`$env:TEMP` in PowerShell). The caddis guard checks only the `Shared checkout: yes` line in
+`AGENTS.md`, not a dirty tree: with that line, it asks before a tree move, and denies it in a headless session.
+<!-- /checkout-safety -->
+
 ## Step 1 — Refuse on the default branch
 
-A PR is *branch → default*. If HEAD **is** the default branch, stop and point at `/ship` — there is
-nothing to open a PR from. (Offer to create a feature branch from the current work if the changes
-are uncommitted.)
+A PR is *branch → default*. Read the default branch as a bare name: `git rev-parse --abbrev-ref
+origin/HEAD` prints `origin/<default>`, so strip the `origin/` prefix before you compare.
+```bash
+d=$(git rev-parse --abbrev-ref origin/HEAD 2>/dev/null) && d=${d#origin/}   # prints origin/<default>: strip origin/
+[ -n "$d" ] || d=$(gh repo view --json defaultBranchRef -q .defaultBranchRef.name)   # origin/HEAD not set
+git branch --show-current                                                  # compare with "$d"
+```
+If HEAD **is** the default branch, stop: there is nothing to open a PR from. Offer to move the
+uncommitted work to a feature branch (`git switch -c <branch>`), or run `/ship`, which does that and
+hands back here.
 
 ## Step 2 — Preflight (local gates mirroring CI)
 
@@ -56,7 +92,7 @@ source checkout; skip this step if the script is missing or the repo has no `.ca
 - Exit **1** — **stop; do not open the PR.** Show each `CHECK VIOLATION` or `ERROR` line.
   - `plan <path>: tracker done, status <s>` — run
     `caddis_tidy.py --repo-root . --apply --only <path>`, `git add` the moved plan by name,
-    commit, and run this step again.
+    commit with `git commit -m "..." -- <old path> <new path>`, and run this step again.
   - `plan <path>: tracker done, but done/<name> already exists (rename one of them)` — `--apply`
     cannot fix this; it changes nothing while the name is taken. Rename the plan or the old
     `done/` copy with `git mv`, commit, and run this step again.
@@ -108,6 +144,8 @@ Run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" review-tier --range <
   git rebase <default-branch>
   git push --force-with-lease origin <branch> # never bare --force
   ```
+- In a shared checkout (Step 0b says `SHARED: yes`), never rebase here: rebase in a detached worktree, as
+  Step 0b says.
 
 ## Step 5 — Push + create/update the PR
 
@@ -146,7 +184,7 @@ human-confirmed door.
 
 ## Rules
 - **Never merges, never deploys** — no merge action exists in this command, by design.
-- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies the first two).
+- Never `git add -A`, `git add .` or `git add <dir>`, even after reading `git status`: stage named files only (the guard denies all three, and `git add -u` and `git commit -a`). Commit with `git commit -m "..." -- <files>`, after `git diff --cached --name-only` shows only those files.
 - Never force-push without a `backup/*-preship` recovery ref; force pushes are `--force-with-lease` only.
 - Never edit a workflow file (`.gitea/workflows/`, `.github/workflows/`) to make a gate pass — fix the source.
 - Local-only lane: refuse + point at `/ship`. On the default branch: stop + point at `/ship`.