@caddis/cli 0.4.51 → 0.4.53

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

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

@@ -55,20 +55,8 @@ are uncommitted.)
 ## Step 3b — Cross-review trigger (before anything is pushed)
 
 <!-- shared:cross-review-trigger — keep byte-identical across commands; a test pins it -->
-**Run the trigger, do not eyeball the diff:**
-
-```bash
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" review-trigger --range <base>...HEAD
-```
-
-Exit **0** — say nothing, carry on. Exit **2** — it prints which rule fired and on which files.
-Run `/caddis:cross-review`, show the findings, and let the user decide. It **never blocks**: this
-picks when to ask for a second opinion, it is not a verdict, and a review gate that blocks a ship
-gets switched off inside a week.
-
-It fires on SQL and repositories, `services/`, caches and refresh jobs, auth and RBAC, or a diff
-over 400 changed lines. No judgement in any of those — deliberately, because judgement is exactly
-what failed.
+Run `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_gate.py" review-tier --range <base>...HEAD` and review by its tier (rule 3).
+`<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 -->
 
 ## Step 4 — Rebase-safe currency
@@ -104,6 +92,12 @@ Watch the PR's checks job-by-job until completion:
 - If any check fails (red check): report the failure, classify the cause, and **stop before merging**.
   Do not merge a failing PR. Apply the minimum source fix and re-push.
 
+## Programme triggers
+
+Small work that does not meet a trigger skips its block.
+
+**Trigger: Always, when the repo deploys on push.** No merge while a push run on the default branch is in progress. Check `gh run list --branch <default> --event push --status in_progress`; if a run is listed, wait for it. `python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_merge_chain.py"` does this check.
+
 ## Step 7 — Merge to default branch
 
 Once all required checks are **green**, there are no merge conflicts, and review requirements are satisfied:

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

@@ -21,9 +21,8 @@ Interview the user to fill gaps. Ask only what you can't infer from the codebase
 Ask in small batches; stop interviewing once the spec is testable.
 
 ## Headless mode
-When the invocation contains the marker **`HEADLESS RUN RULES`**, **or `CADDIS_HEADLESS` /
-`DOCKET_PLAN` / `DOCKET_BRANCH` is set in the environment** (the caddis OSS launchers export
-`CADDIS_HEADLESS` on claude's `-p`/`--print`; the docket runner sets the others) — a non-interactive
+When the invocation contains the marker **`HEADLESS RUN RULES`**, **or `CADDIS_HEADLESS` is set in
+the environment** (the caddis OSS launchers export it on claude's `-p`/`--print`) — a non-interactive
 caller spawned this session and no human is present, so the Discovery interview above is **suspended and
 forbidden**. This mode exists for one-line ideas: the card may be nothing more than a short title with
 **no description**, and there may be **no codebase or `STACK.md`** to draw on. That is expected and still
@@ -50,13 +49,6 @@ Absolute rules in this mode (they override everything above):
 - **Honor the caller's output path and slug.** Write to the `artifact_dir`/`feature` slug the caller
   specifies (falling back to `.caddis/prd/<feature-slug>.md`); set `feature: <slug>` in the
   frontmatter to that same slug. The frontmatter shape is unchanged from the interactive flow.
-- **Also emit a visual companion** — a self-contained, scannable HTML page at `<artifact_dir>/<slug>.html`
-  presenting the PRD visually (a goal/success card, an FR/NFR table, edge cases, and open questions as
-  distinct sections). **Use inline `<style>` ONLY** — the visual is rendered in a *sandboxed* iframe with
-  no script execution, so a `<script>`/CDN (e.g. the Tailwind browser CDN) would NOT run and the page
-  would appear unstyled. Keep it fully portable — no external `<script>`/`<link>`, no local asset files,
-  no `/`-rooted paths. This is the visual the human reviews in docket alongside the markdown. Write it
-  after the `.md`; the runner finds it by the matching `<slug>.html` name.
 - **Always write the artifact file, then end with exactly one fenced `json` highlights block** as the
   final output — nothing after it. Keep `summary` ≤ 280 chars; `open_questions` = the count of bullets
   under `## Open questions`: