@caddis/cli 0.4.52 → 0.4.53

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

@@ -8,6 +8,42 @@ description: End-of-session handoff — capture exact state so the next session
 You are ending a work session. Produce/refresh this workstream's resume doc (`.caddis/relay/<name>.md`) so the next session
 (you, a future you, or another agent on any tool) can resume immediately. This is the anti-context-rot checkpoint.
 
+## Step 0 — is this a shared checkout?
+Another session may have uncommitted edits in this checkout. A handoff that commits here can carry
+them into its commit, so check first, before Step 1.
+
+1. Write this session's own files to a temp file: copy the list under `## Files changed this session`
+   in `.caddis/session-state/<session-id>.md` (the `` - `path` `` lines can be copied as they are).
+   No state file or no list means an empty file.
+2. Run:
+   ```
+   python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_checkout_guard.py" shared --root . --own-files <temp-file>
+   ```
+   It prints `SHARED: yes <reason>` or `SHARED: no` and exits 0. It says yes when the root `AGENTS.md`
+   has a line `Shared checkout: yes`, or when `git status` lists a path this session did not change.
+3. **On `SHARED: no`,** do the steps below as written.
+4. **On `SHARED: yes`,** write NO tracked file in this checkout. Run:
+   ```
+   python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_docs_pr.py" start --repo .
+   ```
+   It makes a new worktree from `origin/<default>` on a `docs/handoff-<utc>` branch and prints
+   `WORKTREE: <path>`. That worktree is this session's only; no other session's edits can enter it.
+   Then, in the steps below:
+   - Step 1: tell the `knowledge-transfer` subagent to edit files ONLY under the `WORKTREE:` path.
+   - Step 3, point 4: run `caddis_rows.py set --file <worktree>/.caddis/open-work.md ...`, and make the
+     plan's Tracker edit in `<worktree>/.caddis/plans/<feature>.md`, not in this checkout.
+   - Step 4: skip `caddis_tidy.py --apply` (report `skipped: shared checkout`).
+   - Step 6b: skip `session_state.py prune` (report `skipped: shared checkout`).
+   - The relay stays in this checkout: `.caddis/relay/` is local and gitignored.
+   After Step 6b, run:
+   ```
+   python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_docs_pr.py" finish --worktree <path> --title "docs(handoff): <name> session notes" --body "Handoff doc edits from a shared checkout."
+   ```
+   It commits only the worktree's changed files, pushes, opens a PR, and prints `PR: <url>` and one
+   `FILE: <path>` line per file (or `PR: none` when nothing changed). It always removes the worktree, and
+   it never merges. On a failure it prints `PATCH: <path>` with the edits; report that path. Put the
+   `PR:` line and the file list in your final report, under `Docs PR needed:`.
+
 ## Step 1 — capture learnings FIRST (knowledge-transfer)
 **Before** gathering git signals or writing relay.md, decide on `knowledge-transfer` — and the default
 is to run it.
@@ -36,7 +72,7 @@ committed before its generator last changed. Paste the parts a next session need
 them from memory.
 
 **Why this step is mechanical.** A handover used to be composed from what the outgoing session
-remembered, so it was only ever as complete as that memory. Bringing one Hub to a usable state took
+remembered, so it was only ever as complete as that memory. Bringing one successor session to a usable state took
 nine corrective round trips and the user caught six of them — including *"the handover listed no
 reports, documents, KB notes or scripts"*. None of those are judgement calls; every one is a
 directory listing. An agent recalls **what it did**; a generator enumerates **what exists**, and
@@ -53,39 +89,7 @@ clean phase boundary and lose or double-do the work.
 tracker shows plan A in progress, but the work moved to plan B), suggest the user run `/digress` to park
 plan A on the workstream stack — so its exact resume point survives and `/catchup [name]` can pop it back later.
 
-## Step 2b — Advisory-Hub handoff audit (conditional — skip silently if not applicable)
-
-**Trigger:** the active plan found in Step 2 has a sibling `<slug>-advisory-context.md`. **No such file
-→ skip this step entirely and silently** — no extra work on an ordinary handoff.
-
-> **First, say which command the user actually wants.** A context doc means a Hub is running, and
-> handing over a Hub is `/caddis:spawn-hub`, not this command. The two look interchangeable from
-> outside and are not: `/handoff` writes a resume doc for the same workstream, while `spawn-hub`
-> ends the Hub's tenure, runs the mechanical audit, conserves the carried-open ledger, and files
-> `hub-NN.spawn.md` in `.caddis/advisory-hub-reports/`. Tell the user plainly, then continue only if
-> they still want a plain handoff.
-
-**Why it is a distinct step:** a context doc is written *before* the work happens, so it is **always
-stale by the time it is needed**. The outgoing Hub's instinct is always "yes, this doc is designed for
-exactly this" — **that instinct has been measured and found wrong**: a real audit found seven gaps in a
-context file the outgoing Hub believed was current, including the single highest-value technique the Hub
-had developed by then.
-
-**Do not ask "are there gaps?" Assume there are, and find them mechanically** (full detail: the
-`advisory-hub` skill's §G):
-1. **List every technique, decision, and correction you actually used this session** — from your own
-   actions in this transcript, not by re-reading the context doc.
-2. **For each, check whether the context doc's instruction itself already covers it** — not whether the
-   word appears. Would a fresh Hub, reading only that file, be told to do the same thing?
-3. **The caveat that will burn you:** a literal-string grep over prose produces **false MISSINGs**. A
-   `0 matches` result means "this exact string isn't here," not "this isn't covered." **Read the section
-   before believing a 0-match grep.**
-4. **Land every real gap as a durable rule** in the right section of the advisory-context, carrying the
-   specific failure that earned it — a note left for later is not a fix.
-
-Record the outcome in relay.md's `## Learnings captured` line (below).
-
-## Step 2c — was any of it the harness?
+## Step 2b — was any of it the harness?
 
 <!-- shared:harness-friction-question — keep byte-identical across commands; a test pins it -->
 **One question, asked here because here is where you are already reflecting.** The observations
@@ -111,7 +115,7 @@ Nothing to say is the normal answer. Say nothing and move on — this must not b
 > `session_id` and `--session-id`. Never guess one: a wrong id disables session matching.
 >
 > 1. **Name the workstream** (active plan's `feature`, else the branch; the script prints nothing
->    on the default branch with no plan — then ask the user for a short name):
+>    on the default branch with no plan — run `caddis_workstreams.py list` (`python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_workstreams.py" list`) to show existing workstreams, then ask the user which one to use or for a short name):
 >    `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_workstreams.py" resolve --plan <feature> --branch <branch> --default-branch <main>`
 > 2. **Legacy repo:** if `.caddis/relay.md` exists and does not start with
 >    `<!-- caddis-workstream-index-v1 -->`, or an old `/digress` stack `.caddis/workstreams.json`
@@ -120,11 +124,21 @@ Nothing to say is the normal answer. Say nothing and move on — this must not b
 >    to the user and stop.
 > 3. **Read the stored version's hash** before you compose: `caddis_workstreams.py hash <name>`
 >    (prints `none` for a new workstream).
-> 4. **Write** the relay below to a temp file, then
->    `caddis_workstreams.py write <name> <temp-file> --expected-hash <hash>`. Exit 1 means another
->    session changed the relay since step 3: it prints the diff and writes nothing. Show the diff,
->    merge by hand, and retry with the new hash. Never force it.
-> 5. **Refresh the index:** `caddis_workstreams.py render-index --session-id <id> --branch <branch>`.
+> 4. **Open-work rows** (only when `.caddis/open-work.md` exists and its frontmatter says
+>    `type: open-work`): first set each row this session
+>    finished, by id and column name, never by hand:
+>    `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_rows.py" set --file .caddis/open-work.md --id <row id> --col Status=done --col Evidence=<evidence>`.
+>    In a shared checkout (Step 0), use `--file <worktree>/.caddis/open-work.md` instead.
+>    **Order of work:** when the repo has a roadmap (`caddis_roadmap.py list` prints a slug), the
+>    roadmap on origin is the order of work. Write the relay's "Next step (exact)" as
+>    `next: top open item of roadmap <slug> (caddis_roadmap.py status --roadmap <slug>)`. Never copy a
+>    list of open items into the relay.
+> 5. **Write** the relay below to a temp file, then
+>    `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_workstreams.py" put <name> <temp-file> --require-status --expected-hash <hash>`.
+>    It refuses a relay whose last line is not a valid status line (see "Programme triggers" below).
+>    Exit 1 also means another session changed the relay since step 3: it prints the diff and writes
+>    nothing. Show the diff, merge by hand, and retry with the new hash. Never force it.
+> 6. **Refresh the index:** `caddis_workstreams.py render-index --session-id <id> --branch <branch>`.
 >
 > (Source checkout: `scripts/caddis_workstreams.py`.) A repo still on the pre-rename `.claudster/`
 > won't see this relay until it's converted — `/caddis:migrate-dir` does that.
@@ -154,6 +168,7 @@ generated:
 <The single next action. Include the command/phase. Add a fallback if blocked.>
 
 ## Read first on resume
+Paths are relative to the repo root.
 - `<path>` — why it matters
 - `.caddis/plans/<feature>.md` — the plan + tracker
 
@@ -165,18 +180,26 @@ generated:
 
 ## Learnings captured
 knowledge-transfer: <✓ ran → files written | ✗ skipped → reason>
-advisory-context audit: <N candidates → M gaps → landed in <path>> | n/a (no advisory-context for this plan)
 
 ## Resume prompt
 \`\`\`
 Read .caddis/relay/<name>.md, then the plan it points to. Continue from <phase/step>. Next action: <exact>.
 \`\`\`
+
+STATUS: <CONTINUE | OWNER-GATE <P>-OG<n> | BLOCKED <owner> | FAILED <reason>>
 ```
 
+## Programme triggers
+
+Small work that does not meet a trigger skips its block.
+
+**Trigger: Always.** The relay ends with a status line, the last non-empty line, and it is exactly one of `STATUS: CONTINUE`, `STATUS: OWNER-GATE <P>-OG<n>`, `STATUS: BLOCKED <owner>` or `STATUS: FAILED <reason>`. In Step 3, point 5, write the relay with `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_workstreams.py" put <name> <temp-file> --require-status --expected-hash <hash>` instead of `write` (in short: put --require-status), with the same hash Step 3 read, so a peer's newer relay is never overwritten. It rejects a relay with no valid status line, and renders the index. When the repo has `.caddis/open-work.md` with `type: open-work` in its frontmatter, also set each open-work row's status with `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_rows.py" set --file <open-work.md> --id <row id> --col Status=<status>` (in a shared checkout, the copy in the Step 0 worktree). When the status is `done`, also pass `--col Evidence=<commit, PR or test>`: caddis_rows.py refuses `done` with no Evidence.
+
 ## Step 4 — tidy finished artifacts
 Flip any plan/prompt's frontmatter `status:` to `done` (or `superseded`) if this session actually
 finished it — that is your judgment call; the script below never makes it and never auto-flips
-status. Then run:
+status. In a shared checkout (Step 0), make the `status:` flip in the Step 0 worktree copy of the plan,
+never in this checkout. Then run (skip it in a shared checkout, Step 0: it moves tracked files):
 ```
 python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_tidy.py" --apply
 ```
@@ -184,7 +207,13 @@ python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_tidy.py" --apply
 skip this step** — it degrades open, same as the other machine gates; an older install must not
 be blocked by a script it does not have. Include its report in your output. A **collision**
 (`done/<name>` already exists) is reported by the script, not fatal — surface it, do not fail the
-handoff over it.
+handoff over it. Exit 2 means a plan is held because its Tracker still has open rows (`held (open Tracker rows): ...` lines, from Phase 3): show those lines; finish, park (`.caddis/parking-lot/<file>.md` in the row) or mark the rows `dropped: <reason>`, or set the plan status back. Do not fail the handoff over it.
+
+After step 4, for each item this session closed (a phase `<plan>#<n>`, a plan slug, or an open-work row id), run `mentions` to check whether another relay's Next step still names it:
+```
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_workstreams.py" mentions --item "<item>" --except <name>
+```
+Print a `WARNING:` line per hit (`WARNING: relay <other> still names closed item <item> in its Next step`). Never edit another workstream's relay (`caddis_workstreams.py mentions` only reads).
 
 ## Step 5 — check the handover you just wrote
 
@@ -197,7 +226,7 @@ report that repo's paths as missing, which is the tool being right about the wro
 
 It fails when the handover names a file that does not exist. The incoming session has **no other
 source** for those paths, so it cannot tell a typo from a real file: one live handover sent an
-incoming Hub looking for a prompt that was never written. Fix what it lists, then re-run.
+incoming session looking for a prompt that was never written. Fix what it lists, then re-run.
 
 It also notes any generated artefact committed before its generator last changed. That is advisory,
 not blocking — but do not quote a report the note names without rebuilding it first.
@@ -219,7 +248,8 @@ python "${CLAUDE_PLUGIN_ROOT}/scripts/session_state.py" prune
 `usage` finds this session's transcript by its id and appends one token-and-skill record to
 `.caddis/usage-log.jsonl`, which `/usage-review` reads. Pass `--transcript <path>` if you know the
 path and it is not under the Claude config folder. `prune` keeps the newest 8 files in
-`.caddis/session-state/`; run it after Step 6, which reads this session's file. Include the
+`.caddis/session-state/`; run it after Step 6, which reads this session's file. Skip `prune` in a
+shared checkout (Step 0). Include the
 `[USAGE]` line in your output. Both always exit 0; if the script is missing, skip this step.
 
 Then list old local state (falls back to `scripts/caddis_tidy.py`; skip if missing):
@@ -247,10 +277,9 @@ On the other machine, `/catchup <name>` fetches it.
   order: (1) interrupted mid-phase work → finish + commit it; else (2) the active plan's next not-started
   phase; else (3) the top open question/decision. Everything else is context, not the next step.
 - Only verified facts and real paths. Mark anything unconfirmed as `Unknown`.
-- Update the plan's tracker rows too (status + last commit) — relay and tracker must agree.
+- Update the plan's tracker rows too (status + last commit) — relay and tracker must agree. In a shared
+  checkout, edit the Tracker in the Step 0 worktree, never in this checkout.
 - Don't commit unless asked. Report which `.caddis/relay/<name>.md` was written and the one next action.
-- **Never hand off a Hub session on the strength of "the context doc is designed for this."** That is the
-  one instinct that has been measured and found wrong. Run Step 2b's audit instead.
 - **Prune the Done section — two rules, both apply:**
   1. **Merge-based:** Phases already merged to `main` (confirmed by a tag or commit) must be compressed
      to a single line: `- **RW-N**: merged to main as vYYYY.MM.DD.N (<commit>) ✅`. Only the current

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

@@ -5,10 +5,10 @@ description: Headless plan executor — implement an approved plan phase-by-phas
 
 # /caddis:implement — execute an approved plan (headless driver)
 
-Implement the plan at **$ARGUMENTS** (falls back to the `DOCKET_PLAN` env var if `$ARGUMENTS` is empty).
+Implement the plan at **$ARGUMENTS**.
 
-**Which plan.** An explicit plan always wins: `$ARGUMENTS` first, then the `DOCKET_PLAN` env var
-(it counts as an explicit argument). Only when both are empty, find the active plan:
+**Which plan.** An explicit plan always wins: the plan path comes only from `$ARGUMENTS`. Only when
+it is empty, find the active plan:
 
 ```bash
 python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_todo.py" active-plan
@@ -20,8 +20,9 @@ python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_todo.py" active-plan
   candidates it printed on stderr (or "none") in the review file, and end with the
   `"implemented":false` JSON block from step 6.
 
-This command is the **docket Implement lane's driver**. It is spawned autonomously by the docket runner —
-**no human is present**. It does not design or re-plan: the plan is the intelligence, you are the executor.
+This command is the **headless Implement driver**. It is spawned autonomously by a runner or a lane
+launcher (they set `CADDIS_HEADLESS`) — **no human is present**. It does not design or re-plan: the plan
+is the intelligence, you are the executor.
 The runner independently re-runs the tests and a fresh code-review after you finish and decides success
 itself — so your job is to implement faithfully, commit cleanly, and report honestly. Overstating success
 does not help you; the runner will catch it.
@@ -30,11 +31,15 @@ does not help you; the runner will catch it.
 These override everything below. They exist because branch isolation and the runner's post-run backstops
 depend on them:
 
-- **Work ONLY on the current branch.** You are already on the feature branch (`DOCKET_BRANCH`, e.g.
-  `agent/<slug>`). **NEVER** run `git checkout`, `git switch`, `git branch`, `git switch -c`, or any
-  command that changes, creates, or leaves the current branch. If you somehow find yourself on the default
-  branch (`DOCKET_DEFAULT_BRANCH`), **stop immediately, do not commit**, and emit the failure JSON below —
-  a commit on the default branch fails the run.
+- **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,
+  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
+  branch is `main` or `master`. **Stop immediately, do not commit**, and emit the failure JSON below when
+  `git branch --show-current` prints nothing (a detached HEAD) or prints the default branch — a commit
+  there is lost or fails the run.
 - **NEVER touch git remotes.** No `git push`, `git pull`, `git fetch`, `git remote`, no PR, no merge. The
   runner never pushes; neither do you.
 - **NEVER edit your own success criteria.** Do not modify `.caddis/PROJECT-FACTS.md`, and do not change
@@ -51,16 +56,36 @@ 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.
-3. **Review once.** Use whatever reviewer is available. Stop at the first CLEAN. After two blocking reviews, ask the owner.
+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;
+   park the rest. Re-review only the fix diff, and only when the fix changed logic. After 3 rounds, ask the owner.
 
-This run is headless, so "ask the owner" means: stop the phase, do not commit it, and record the
-two blocking reviews in the review file.
+**Author self-check** (tier 1-small, and before any review). It is not a model review. Answer all five:
+1. The CI gates named in the phase passed, with the literal output.
+2. Every changed function has a test that fails without the change.
+3. No TODO, placeholder or debug print is left.
+4. Error paths return or raise. None is swallowed.
+5. The diff touches only the phase's files.
+
+This run is headless, so "ask the owner" (after 3 rounds) means: stop the phase, do not commit it, and record the
+blocking findings of the 3 rounds in the review file.
+
+## Programme triggers
+
+Small work that does not meet a trigger skips its block.
+
+**Trigger: Always.** Mutation proof: for each gate the phase adds, break the code under test once with a recorded mutation and see the gate fail. Write the mutation and the failing test line in the review file.
+
+**Trigger: The phase computes or shows a number.** Value check: the computed figure must equal an independent source for a fixed past window, never today. Start from the `roadmap` skill's `assets/value-check.template.py`. Run it once with `--prove-it-can-fail` and see it exit 1.
+
+**Trigger: The phase changes UI.** Render check: the changed page must render at 1440 and 400 px wide with 0 console errors, after the network is idle plus the settle time (default 3 s). Start from the `roadmap` skill's `assets/render-check.template.mjs`. Run it once with `--prove-it-can-fail`.
 
 ## What to do
 
-**1. Read the plan.** Load the plan file (`$ARGUMENTS` / `DOCKET_PLAN`). Read its `## Phases`, `## Affected
-files`, `## Constraints & decisions`, and `## Tracker`. Read the `AGENTS.md` at the repo root and in each
-folder you will touch (the canonical rules; `CLAUDE.md` is an `@AGENTS.md` shim), and
+**1. Read the plan.** Load the plan file (`$ARGUMENTS`, or the active plan found above). Read its
+`## Phases`, `## Affected files`, `## Constraints & decisions`, and `## Tracker`. Read the `AGENTS.md`
+at the repo root and in each folder you will touch (the canonical rules; `CLAUDE.md` is an `@AGENTS.md` shim), and
 `.caddis/PROJECT-FACTS.md` if present (for the real run/test commands) —
 **read it, never edit it**. Identify the test command the plan/facts specify so you can run it yourself.
 
@@ -68,12 +93,11 @@ folder you will touch (the canonical rules; `CLAUDE.md` is an `@AGENTS.md` shim)
 
 ```bash
 python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" lane-check    --plan <plan> --phase <N>
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" verdict-gate  --plan <plan> --phase <N>
 python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" tracker-vs-git --plan <plan>
 ```
 
 Use the shared scale in `caddis_exit.py`: 0 clean, 1 blocked, 2 advisory, 3 could not run,
-4 error or bad usage. For `caddis_gate.py`, obey the exit code: **0** proceed · **1** STOP and report
+4 error or bad usage, 5 round limit (`caddis_review.py --plan` only: stop, the owner decides). For `caddis_gate.py`, obey the exit code: **0** proceed · **1** STOP and report
 why · **2** proceed but record the note it
 printed · **3** wrong lane — the launch command is on stdout, spawn it · **4** the launch command is
 malformed, do not run it.
@@ -92,7 +116,7 @@ You cannot always prove your own lane, but you can detect a known mismatch — a
 looking at `Lane: glm-headless`. Apply this **asymmetrically: act on a known mismatch, proceed when
 unsure.** On a known mismatch:
 
-- **Interactive session (no `CADDIS_HEADLESS`, no `DOCKET_PLAN`/`DOCKET_BRANCH` in the environment)
+- **Interactive session (no `CADDIS_HEADLESS` in the environment)
   → spawn the assigned lane.** Run the phase's literal launch command yourself — e.g.
   `claude-glm -p "/caddis:implement <plan> — Phase N only"` — wait for it, then verify it (below).
   On Windows `claude-glm` is `claude-glm.ps1` and resolves only on the **PowerShell** PATH; a
@@ -105,9 +129,9 @@ unsure.** On a known mismatch:
   > it spawns a session that is not marked headless, which reads this same `Lane:` line and spawns
   > again — unbounded recursion. Without `-p` the command also opens an interactive session, so the
   > parent waits forever on a child that is sitting at a prompt.
-- **Headless or docket-runner session → never spawn. Implement here and record the deviation.**
+- **Headless session (`CADDIS_HEADLESS` set) → never spawn. Implement here and record the deviation.**
   You may already *be* the spawned lane, and a session that spawns its own lane on every start is
-  an infinite loop. The env markers above are the guard: if either is set, someone else placed you.
+  an infinite loop. The env marker above is the guard: if it is set, someone else placed you.
 
 **After the spawn, verify it — do not assume.** Re-read the plan's Tracker row for that phase and
 confirm the status and commit hash the child claims to have written. "Wait for it and report" checks
@@ -122,7 +146,7 @@ the bug the lane routing exists to fix.
 
 **Record the lane you actually ran on in the Tracker's `Lane` column** — the lane you ran, never the
 lane the plan planned. A deviation then shows up as a diff between the phase block and the tracker
-row, visible to any later reader without an Advisory Hub having to catch it live.
+row, visible to any later reader without anyone having to catch it live.
 
 **Multi-lane phases — `caddis_lanes.py`.** Use this procedure when the phase launch command is
 `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" run …`.
@@ -179,89 +203,17 @@ row, visible to any later reader without an Advisory Hub having to catch it live
     or `You're out of extra usage`; the full list is `BUDGET_PATTERNS["claude"]` in
     `caddis_lanes.py`), run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" next-lane --role <the phase's role> --after <the model that ran>`.
     Re-dispatch the same phase prompt to the printed lane with its direct launch command:
-    `codex exec ...` or `agy ... -p "..."`, using the same form that `/feature-plan` writes.
+    `codex exec ...` or `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_spend.py" run --caller lane-pN -- agy ... -p "..."`,
+    using the same form that `/feature-plan` writes. Never start agy without the `caddis_spend.py run`
+    prefix: it is the global spend cap. Its own refusals have their own exit codes, never agy's:
+    **75** = over the cap or could not lock (treat like out of budget: switch lane, not an attempt);
+    **78** = the cap is not configured (stop and tell the owner to write `~/.caddis/spend-cap.toml`).
+    Each refusal also prints a `caddis_spend:` line on stderr. Any other exit code is agy's own.
     An out-of-budget switch is not an attempt (item 4). Record the fallback in the Tracker
     `Lane` column, for example `sonnet -> agy (claude out of budget)`.
     If `next-lane` exits 3, stop and report that no lane is left. As a last resort, the owner can
     open `caddis-run codex -m gpt-6-astra` and ask it to follow this same subsection.
 
-**Advisory-Hub mode (conditional — OFF by default).** Check whether a companion file
-`<plan-dir>/<plan-stem>-advisory-context.md` exists (e.g. plan `.caddis/plans/foo.md` → look for
-`.caddis/plans/foo-advisory-context.md`). **If it does not exist — the normal case, including every
-docket run — Advisory-Hub mode is OFF and nothing else in this command changes.** If it exists, read it
-and set Advisory-Hub mode ON for this run: it names locked decisions you may not change unilaterally,
-this project's declared safety conventions, and how to re-derive the plan's anchor numbers. See the
-`advisory-hub` skill for the full contract.
-
-**In Advisory-Hub mode, the previous phase's VERDICT gates this one.** Before starting phase N, require
-a verdict in `.caddis/advisory-hub-reports/` that satisfies **all three** of:
-
-1. **It covers phase N-1.** Usually `phase-(N-1).verdict.md`, but a **batched** verdict counts: a file
-   whose `phase:` is a range — `phase-10-11.verdict.md`, `phase: 10-11` — satisfies the gate for every
-   phase the range **covers**. Batched pairs are normal, not exotic: one live plan alone carries
-   `phase-05-06`, `08-09`, `10-11` and `13-14`. A literal `phase-(N-1)` lookup sends phase 12 hunting
-   for a `phase-11.verdict.md` that will never exist, and falsely blocks a properly validated plan.
-2. **It belongs to the plan you are implementing.** The report directory is flat and shared, so with two
-   hub-mode plans in one repo, plan A's `phase-02.verdict.md` would otherwise satisfy plan B's phase-3
-   gate. Match the verdict's identity field against the plan. **Accept either `plan:` (a path) or
-   `feature:` (a slug) — both are in live fleet use** and neither is wrong; one project's verdicts carry
-   one, another's carry the other. If a verdict carries neither, treat its identity as unproven: say so
-   and do not let it gate anything.
-3. **It carries `verdict: accept` or `verdict: accept-with-correction`.**
-
-- **Missing** → the Hub has not validated it yet. **STOP.** Mark the Tracker row
-  `blocked-pending-hub` and say which verdict you are waiting on.
-- **`verdict: reject`** → **STOP.** The phase is to be redone, not built upon.
-- **`verdict: accept-degraded`** → the Hub validated it **without an advisory context**, so the
-  locked-decision and safety-rule re-checks never ran. It is a partial check wearing an accept. Proceed
-  only if the phase is low-stakes, and **say in your report that you did so on a degraded verdict**.
-- Phase 1 (or the first phase of the plan) has no predecessor — proceed.
-
-This is the Hub's central power and until now it ran on human discipline alone: the verdict recorded
-whether the next phase could start, and *nothing read it*. Five lines of check make the claim true by
-machine.
-
-### Ringing the Hub, and waiting for it (Claude Code only, optional)
-
-Two moments in Advisory-Hub mode currently cost the user a copy-paste. Both are optional, both
-degrade to today's behaviour, and neither replaces a file.
-
-**After you file `phase-NN.report.md`** — if `ListAgents` is available, look for a peer session whose
-name starts with **this repo's directory name**. Sessions are auto-named `<repo-dir>-<hash>`, so a
-same-repo peer is the Hub:
-
-```
-SendMessage({to: "<peer-name>", summary: "phase-05 report filed",
-             message: "phase-05.report.md is filed and awaiting a verdict."})
-```
-
-**When you are BLOCKED on a verdict** — instead of stopping dead, subscribe once:
-
-```
-SendMessage({to: "<peer-name>", notify_when_idle: true,
-             message: "blocked on phase-05 verdict; ping me when you have written it"})
-```
-
-`notify_when_idle` is one-shot and costs the Hub nothing extra. **Never poll `ListAgents` in a loop,
-and never send "are you done yet?"** — that burns both sessions' context to no purpose.
-
-**The rules that keep this from becoming a mess:**
-
-- **The file is the decision; the message is a doorbell.** Never treat a chat message as a verdict.
-  If a peer says "accepted", still read `phase-NN.verdict.md` — the gate above checks the FILE, and
-  a message cannot be re-read next week or by a third session.
-- **No `ListAgents`, no peer, or more than one same-repo peer → do nothing and carry on.** caddis
-  also runs on agy and Codex, which have no cross-session messaging at all. Everything above is an
-  accelerant on one harness; the file protocol is the portable layer and is what actually works.
-- **Headless runs never message.** There is no copy-paste to save.
-- **Never ask a peer to perform work your own session was denied.** Permission boundaries are
-  per-session, and routing blocked work through another session launders the user's decision.
-
-**If a `phase-NN.prompt.md` exists for the phase you are about to run, it is the INSTRUCTION OF
-RECORD** — read it, and measure your DEVIATIONS against it, not against the plan alone. The Hub writes
-that file before the phase precisely so a deviation is falsifiable; an executor that never reads it
-undermines the whole argument.
-
 **2. Determine where to resume.** The `## Tracker` table is the resume signal. Start at the first phase whose
 status is not `done`/`✅`. If every phase is already done, verify the tests are green and go straight to the
 report — do not redo completed work.
@@ -289,33 +241,6 @@ report — do not redo completed work.
      ACTUALLY ran on (not the planned one — see Step 1), and add a one-line note. This is what lets a
      future session (or the runner) see progress. Commit the Tracker update with the phase (or as a tiny
      follow-up commit) — it lives in the plan file, which is fine to commit on this branch.
-   - **FILE THE PHASE REPORT — Advisory-Hub mode only.** *Skip this bullet entirely if Step 1 found no
-     `<slug>-advisory-context.md`.* Write `.caddis/advisory-hub-reports/phase-NN.report.md` (zero-padded
-     phase number; create the directory and add a `README.md` index row if absent — and when you
-     create `.caddis/advisory-hub-reports/` for the first time, also write an **`AGENTS.md`** there
-     carrying the naming, frontmatter and role rules from the `advisory-hub` skill, so they bind every
-     agent that writes to that directory including ones that never loaded the skill. The skill claims
-     this file ships; nothing ever created it, so it exists only where a Hub hand-wrote one.
-     **Never overwrite an existing `AGENTS.md`** — the hand-written ones in the fleet are the good
-     copies) using the
-     `advisory-hub` skill's report contract. Verbatim means verbatim — paste real terminal output, never
-     reconstruct it. Report the model/lane you actually ran on. Report every commit, including tooling and
-     config. `git add` the report file with this phase's commit. **If the report's SURPRISES /
-     CONTRADICTIONS section is non-empty, stop after this phase** — mark the Tracker row
-     `blocked-pending-hub`, leave later phases untouched, and let the Hub correct the plan; that is not
-     your call to make here.
-
-> **Give it OKF frontmatter — `type` is REQUIRED and its absence is a defect.**
-> Keep it flat (scalar `key: value` only; nested maps and lists defeat simple parsers):
-> ```yaml
-> ---
-> type: phase-report
-> plan: <path to the plan>
-> phase: 12          # or 10-11 for a batched pair
-> milestone: M4
-> ---
-> ```
-
 
    If a phase cannot be completed (a blocking gap the plan did not resolve, or a rule above would be
    violated), **stop there**: leave later phases untouched, record the blocker in the review file, mark the
@@ -327,7 +252,11 @@ or a **failed/blocked** phase. A lane change is not one of them: you spawn the l
 
 The `risk: high` halt is deliberately *after*, not before. Execute and commit the phase normally; the
 halt exists to stop the **next** phase building on it before a human has looked, so the blast radius
-stays one reviewable, revertable commit.
+stays one reviewable, revertable commit. One exception: when your session prompt itself says the runner
+reviews `risk: high` phases (the runner's `plan-resume-prompt.md` says so), do not halt; end the session
+`STATUS: CONTINUE`. The runner then reviews the phase twice (`caddis_review.py --plan --phase --runs 2`),
+starts one fix session on blocking findings, and stops `BLOCKED review` when findings remain.
+`CADDIS_HEADLESS=1` alone is NOT that instruction: without the prompt line, a `risk: high` phase still halts.
 
 **At every halt, PERFORM the handoff yourself, now, before you stop.** Write `relay.md` and update
 the Tracker in this session — you are the only party holding the context that makes them worth
@@ -358,31 +287,45 @@ more and record the real result. The runner will re-run it independently and tha
 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.
 
-**4b. If every phase is now done, tidy the plan into `done/`.** Only when the whole plan is
-finished (every `## Tracker` row is `done`, no halt, no blocker) — a mid-plan halt is not this.
-Flip the plan's own frontmatter `status:` to `done` (your judgment call: only if the Tracker
-genuinely backs it up), commit that with the final phase, then run:
-```
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_tidy.py" --apply
-```
-(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 exists) is reported by the script, not fatal — note it in the review file,
-do not fail the run over it.
-
-**5. Write a concise review file** to the path in the `DOCKET_REVIEW` env var (falls back to
-`.caddis/reviews/<slug>.md`, where `<slug>` is `DOCKET_SLUG`). Create `.caddis/reviews/` if needed.
+**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
+not this. Tidy is part of finishing: the plan closes in the PR that finishes it, so nothing is left
+for a later session to clean up, and nothing is left uncommitted. Order matters:
+
+1. Edit the final phase's `## Tracker` row to `done` (Step 3). **Do not commit it yet.**
+2. Run tidy on THIS plan only. It reads the Tracker, sets the plan's `status: done` and `git mv`s
+   it into `done/`. `--only` keeps it off every other file, so another session's finished plan, a
+   shipped prompt or a done parking-lot item is never swept into this PR:
+   ```
+   python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_tidy.py" --repo-root . --apply --only .caddis/plans/<this plan>.md
+   ```
+   Read the output before you commit. It must say `moved: .caddis/plans/<this plan>.md` and name
+   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.
+
+(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
+exists) is reported by the script, not fatal: it changes nothing, so commit the Tracker row as
+usual and note the collision in the review file; do not fail the run over it. `/caddis:ship-pr`
+runs `caddis_tidy.py --check` on the PR's files and stops on a plan whose Tracker is done but whose
+status is not, so a skipped tidy is caught before the PR opens.
+
+**5. Write a concise review file** to `.caddis/reviews/<slug>.md`, where `<slug>` is the plan file's
+name without `.md`. Create `.caddis/reviews/` if needed.
 Keep it short and scannable — this is what the human reviewer reads before merging the branch:
 
 ```markdown
 ---
 type: implement-review
 feature: <slug>
-branch: <DOCKET_BRANCH>
+branch: <current branch>
 ---
 
 # Implement review — <feature>
-**Branch:** `<DOCKET_BRANCH>`  •  **Phases done:** <N of M>  •  **Tests:** passed | failed
+**Branch:** `<current branch>`  •  **Phases done:** <N of M>  •  **Tests:** passed | failed
 
 ## What changed
 - <phase 1 — one line: what shipped + commit hash>
@@ -406,9 +349,6 @@ showed; `review` is the review-file path you wrote:
 {"implemented":true,"phases_done":<int>,"tests":"passed|failed","review":".caddis/reviews/<slug>.md"}
 ```
 
-(In Advisory-Hub mode, the phase report from Step 3 is a **file**, written per phase — this JSON block
-remains the one and only final output of the whole run, in every mode, unchanged.)
-
 If you had to stop before implementing anything (e.g. you were on the default branch, or the plan was
 unreadable), still end with the block using `"implemented":false,"phases_done":0,"tests":"failed"` and put
 the reason in the review file. The only acceptable final output is the code + commits + review file + this

package/bundles/antigravity-plugin/skills/migrate-dir/SKILL.md

@@ -62,7 +62,7 @@ the rename **on its own**, e.g. `chore(caddis): migrate .claudster/ -> .caddis/`
 
 ## Notes
 - Also grep the repo for stale refs the migrator leaves alone on purpose:
-  `.gitignore`, CI workflows, `.docket/config.json`, and any script hardcoding `.claudster/`.
+  `.gitignore`, CI workflows, and any script hardcoding `.claudster/`.
   Update those by hand in the same commit.
 - Repos that haven't migrated keep working indefinitely — the `.claudster` read-fallback is removed
   only after the whole fleet has migrated and soaked.

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

@@ -18,12 +18,15 @@ anything else is the task for `run`. Pass supported run flags such as `--type` w
 An unknown flag returns a usage error.
 
 The exit codes follow `caddis_exit.py`: 0 clean, 1 blocked, 2 advisory, 3 could not run,
-4 error or bad usage. In particular, `caddis_adhoc.py` returns 4 for bad usage.
+4 error or bad usage, 5 round limit (`caddis_review.py --plan` only: stop, the owner decides). In particular, `caddis_adhoc.py` returns 4 for bad usage.
 
 ## 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.
-3. **Review once.** Use whatever reviewer is available. Stop at the first CLEAN. After two blocking reviews, ask the owner.
+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;
+   park the rest. Re-review only the fix diff, and only when the fix changed logic. After 3 rounds, ask the owner.
 
 `/mmr` is for handing a task to another model, not for normal reviews. For a normal review, use
 `/cross-review`.

package/bundles/antigravity-plugin/skills/office-documents-official/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: office-documents-official
+description: Hint for Office and PDF file work. Use when the user asks to create, edit, read or convert a Word .docx, PDF, PowerPoint .pptx or Excel .xlsx file. caddis does not ship these skills; points to Anthropic's official document-skills plugin.
+---
+
+# Office and PDF files: use Anthropic's document-skills
+
+caddis does not include skills for Word (.docx), PDF, PowerPoint (.pptx) or Excel (.xlsx) files.
+These skills belong to Anthropic. Anthropic publishes them as the `document-skills` plugin.
+
+## Install (Claude Code)
+
+```
+/plugin marketplace add anthropics/skills
+/plugin install document-skills@anthropic-agent-skills
+```
+
+Source: https://github.com/anthropics/skills (see its README, section "Claude Code").
+
+## What to do
+
+1. If the plugin is installed, use its `docx`, `pdf`, `pptx` or `xlsx` skill for the file type. Do not work from this note.
+2. If the plugin is not installed, tell the user the two commands above. Then ask if they want to install it first.
+3. If the user cannot install it, say what you can do without it. For example, write the content as Markdown and let the user convert it.

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

@@ -66,7 +66,6 @@ Park it only if it is work **we** will do later. Redirect these instead, and say
 | Being worked on right now | `.caddis/plans/<feature>.md` |
 | An interrupted task you will come back to this session | `/caddis:digress` |
 | Blocked on a person outside this repo | `.caddis/comms/` + its `register.md` |
-| A card on the docket board | the board. **Never hand-edit `.caddis/backlog/`** — docket writes it |
 | A fact about the environment, not a task | the KB (`/caddis:kb`) |
 
 ### Step 2 — do not duplicate