@caddis/cli 0.4.30 → 0.4.33

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

@@ -6,14 +6,19 @@ description: Multi-Model Review & Runner (MMR) — run an ad-hoc task in an isol
 # /caddis:mmr — Multi-Model Review & Runner
 
 Execute an ad-hoc task across model lanes (GLM-5.3 → Codex Sol → Claude) inside an isolated
-git worktree with automated test gates and second-vendor review (DeepSeek). Destroys the worktree
-immediately on completion (zero worktree leaks) and leaves the output on a clean branch with a
-simple Verdict Card.
+git worktree with automated test gates and second-vendor review (DeepSeek). A full PASS commits
+code changes and removes the worktree. A FAIL or PENDING keeps the worktree for inspection or
+Claude-lane work. The result appears in a Verdict Card.
 
 When invoked without a task prompt (or with a git range), `/mmr` runs a direct cross-model diff review.
 
 The user typed: **$ARGUMENTS**. Route it to one of the commands below: `keep`, `drop` or `status`
-as given; a git range to `review --range`; empty to `review`; anything else is the task for `run`.
+as given; a git range such as `origin/main..HEAD` to `review --range`; empty to `review`;
+anything else is the task for `run`. Pass supported run flags such as `--type` with the task.
+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.
 
 ## Natural Language Triggers
 You can trigger MMR naturally without typing the full slash command:
@@ -39,8 +44,9 @@ python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_adhoc.py" "<task description>"
 - **Failover Cascade:** Automatically cascades from GLM to Codex to Claude if a lane is out of budget.
 - **Local Test Gates:** Runs project test gates before review.
 - **Cross-Vendor Review:** DeepSeek or GLM reviews the diff.
-- **Immediate Worktree Cleanup:** Stashes/commits results to `lane/adhoc-<slug>` and immediately removes the worktree. Zero open worktrees remain.
-- **Verdict Card:** Prints PASS/FAIL summary with diff stats and next actions.
+- **Worktree result:** PASS commits code changes to `lane/adhoc-<slug>` and removes the worktree. FAIL keeps it. A Claude-lane `PENDING` keeps it and prints the `NEXT:` step. Gates that never ran show `Gates: not run`.
+- **No-op and gate failures:** A run with no code changes fails and keeps its worktree. A pytest gate that collects no tests also fails.
+- **Verdict Card:** Prints PASS, FAIL, or PENDING with diff stats and next actions.
 
 ### 2. Keep the Result
 ```bash
@@ -54,7 +60,7 @@ python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_adhoc.py" keep
 ```bash
 python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_adhoc.py" drop
 ```
-- Deletes the branch `lane/adhoc-<slug>`.
+- Removes a kept worktree, prunes its registration, and deletes the task branch.
 - Deletes the ephemeral plan file and run logs.
 - Workspace remains clean and untouched.
 
@@ -72,7 +78,7 @@ python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_adhoc.py" review [--range <range>]
 # Shorthand (no args):
 python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_adhoc.py"
 ```
-- Fast cross-model review of working tree or git range (e.g., `origin/main..HEAD`).
+- Fast cross-model review of working tree or git range (e.g., `origin/main..HEAD`). A range can also be passed directly as the first argument.
 
 ---
 

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

@@ -1,36 +1,6 @@
 ---
 name: resume
-description: Pop the most recently parked workstream off the stack and resume it at its exact resume point
+description: Renamed to /caddis:catchup (alias, removed next release)
 ---
 
-# /caddis:resume — pop the parked task and pick it back up
-
-A digression is finished; return to the task you parked with `/digress`. This pops the top frame off the
-workstream stack, restates where you were, realigns `relay.md`, and immediately continues the work — the
-user should not have to remember or re-state anything.
-
-## Step 1 — read the stack
-Read `.caddis/workstreams.json`. If it is **absent, unparseable, `version != 1`, or `stack` is empty**,
-say exactly `Nothing is parked.` and stop. Do nothing else.
-
-## Step 2 — pop the top frame
-The top of stack is the **last** element of `stack` (LIFO — most recently parked). Remove it and write the
-rest of the file back (preserve `version` and any other frames + unknown fields). This is the one write
-this command makes to the state file.
-
-## Step 3 — restate + realign relay.md
-Restate the popped frame to the user: its `plan`, `phase`, and `resumePointer` (and `repo` if set — the
-parked task lives in another repo, so say which). Then edit `.caddis/relay.md`'s `## Next step` section
-**in place** so it matches the popped frame's `resumePointer` — preserve every other section of relay.md
-untouched. (If relay.md or that section is absent, skip this edit silently; the restatement above is enough.)
-
-## Step 4 — resume the work
-Begin executing the `resumePointer` immediately. Ask nothing — the frame already carries the next action.
-If the parked plan lives in another `repo`, note that the user may need to open that repo first, then
-proceed there.
-
-## Rules
-- **Never** run a destructive or history-rewriting git action (no `git checkout`, `git reset`, `git stash`,
-  branch switches). Resuming is metadata-only.
-- Pop exactly one frame per invocation (the LIFO top). Run `/resume` again to pop the next.
-- Only real paths and verified facts — restate the frame as written; do not embellish the resume point.
+This command was renamed to /caddis:catchup. Run /caddis:catchup now in its pop-and-resume mode with the same arguments ($ARGUMENTS); if $ARGUMENTS is empty, pass `last` as the name, so this alias still pops the most recently parked task as /caddis:resume always did. Tell the user once: "/caddis:resume is renamed to /caddis:catchup; the old name will be removed in the next release."

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

@@ -1,100 +1,6 @@
 ---
 name: review
-description: Review someone else's OPEN pull request end to end — what changed, what CI says, what is risky — then approve or request changes. Never approves on its own.
+description: Renamed to /caddis:review-pr (alias, removed next release)
 ---
 
-# /caddis:review — review an open PR, then decide
-
-Review pull request **$ARGUMENTS** and walk the operator to an approve-or-not decision.
-
-> **This is the only caddis review surface aimed at a PULL REQUEST.** The others review a local
-> diff: `/caddis:gate-review` (adversarial, same vendor), `/caddis:cross-review` (a different
-> vendor's model). `/caddis:ship-pr` and `/caddis:ship-merge` create and merge PRs. This one is for
-> the case none of those covers — somebody else has opened a PR and you have to decide about it.
->
-> Do not reimplement the review itself. Gather the context, then hand the diff to
-> `/caddis:gate-review` (or Claude Code's native `/code-review`, which is better where it exists).
-
-## Absolute rule
-
-**Never approve, request changes, merge, or close on the operator's behalf.** Present the evidence
-and the exact command; the human runs it. An approval is the one human judgement in the pipeline —
-a review tool that also approves has removed the thing it was built to protect.
-
-## 1. Resolve the PR
-
-`$ARGUMENTS` is a PR number, optionally followed by `owner/repo`. With no repo, use the current
-directory's `origin`. If the number is missing, list the open PRs and stop.
-
-```bash
-gh pr view <n> --repo <owner/repo> --json number,title,author,state,isDraft,mergeStateStatus,reviewDecision,baseRefName,headRefName,additions,deletions,changedFiles,url
-```
-
-**Stop and say so, before reviewing anything**, if:
-- 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.
-
-## 2. Gather what the decision needs
-
-Four things, and report them even when they are boring — "CI is green" is information:
-
-```bash
-gh pr checks <n> --repo <owner/repo>            # every check and its state
-gh pr diff  <n> --repo <owner/repo>             # the change itself
-gh pr view  <n> --repo <owner/repo> --comments  # review comments, and any bot review
-```
-
-If an automated review has already commented, **read it and say whether you agree**. Two reviews
-that disagree is a finding; two that agree is worth stating once, not twice.
-
-`mergeStateStatus` explains a blocked PR without guessing: `BLOCKED` (needs a review),
-`BEHIND` (needs *Update branch*), `UNSTABLE` (a check failed), `DIRTY` (conflicts).
-
-## 3. Review the diff
-
-Hand it to `/caddis:gate-review` — or the native `/code-review` on Claude Code. Then, on top of its
-verdict, check the things that have actually cost this fleet time, because a generic reviewer will
-not know to look:
-
-- **A gate that cannot fail.** A check whose failure path cannot execute — piped to `Out-Null`,
-  wrapped in a `catch{}` a native non-zero exit can never trigger, or asserting something too broad
-  to attribute. It manufactures confidence. Worse than no check.
-- **A wall-clock assertion.** A timing threshold on a shared runner measures load, not the code.
-  Assert ordering instead.
-- **Staged directories.** `git add -A` / `git add .` sweeps in files nobody reviewed.
-- **CI shell assumptions.** The runner may be Windows PowerShell 5.1, where a native command's
-  stderr becomes a terminating error under `$ErrorActionPreference='Stop'`, and where `Should -Be`
-  (Pester 4 syntax) fails on a Pester 3 runner.
-- **Deploy-script changes.** If the pipeline runs the deploy script from a checkout it also updates,
-  the change does not take effect on the deploy that delivers it. Budget two deploys.
-- **Verification by proxy.** An HTTP 200 or a version string is not proof a page renders.
-- **Credentials.** A token scoped to the wrong host; a permission raised to make a test pass; a
-  secret in a URL where git will echo it into a log.
-- **A doc the change makes untrue.** Comments and runbooks that were accurate until this diff.
-
-## 4. Report, then hand over
-
-Lead with the verdict. Keep it short enough to read before deciding:
-
-- **What this PR does** — one or two sentences, not a file list.
-- **Blocking issues** — each with file, line, and why it matters. None is a valid answer, and say it.
-- **Should-fix / nits** — grouped, brief.
-- **CI** — green, red, or still running. Name the failing check.
-- **Merge state** — and what would clear it.
-
-Then print the exact commands, and stop:
-
-```bash
-# approve
-gh pr review <n> --repo <owner/repo> --approve
-gh pr merge  <n> --repo <owner/repo> --squash --delete-branch
-
-# or ask for changes
-gh pr review <n> --repo <owner/repo> --request-changes --body "..."
-```
-
-**If you found a blocking issue, say so in the verdict line** rather than burying it under the
-summary. The operator should be able to read the first line and know whether to keep reading.
+This command was renamed to /caddis:review-pr. Run /caddis:review-pr now with the same arguments ($ARGUMENTS), and tell the user once: "/caddis:review is renamed to /caddis:review-pr; the old name will be removed in the next release."

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

@@ -0,0 +1,100 @@
+---
+name: review-pr
+description: Review someone else's OPEN pull request end to end — what changed, what CI says, what is risky — then approve or request changes. Never approves on its own.
+---
+
+# /caddis:review-pr — review an open PR, then decide
+
+Review pull request **$ARGUMENTS** and walk the operator to an approve-or-not decision.
+
+> **This is the only caddis review surface aimed at a PULL REQUEST.** The others review a local
+> diff: `/caddis:gate-review` (adversarial, same vendor), `/caddis:cross-review` (a different
+> vendor's model). `/caddis:ship-pr` and `/caddis:ship-merge` create and merge PRs. This one is for
+> the case none of those covers — somebody else has opened a PR and you have to decide about it.
+>
+> Do not reimplement the review itself. Gather the context, then hand the diff to
+> `/caddis:gate-review` (or Claude Code's native `/code-review`, which is better where it exists).
+
+## Absolute rule
+
+**Never approve, request changes, merge, or close on the operator's behalf.** Present the evidence
+and the exact command; the human runs it. An approval is the one human judgement in the pipeline —
+a review tool that also approves has removed the thing it was built to protect.
+
+## 1. Resolve the PR
+
+`$ARGUMENTS` is a PR number, optionally followed by `owner/repo`. With no repo, use the current
+directory's `origin`. If the number is missing, list the open PRs and stop.
+
+```bash
+gh pr view <n> --repo <owner/repo> --json number,title,author,state,isDraft,mergeStateStatus,reviewDecision,baseRefName,headRefName,additions,deletions,changedFiles,url
+```
+
+**Stop and say so, before reviewing anything**, if:
+- 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.
+
+## 2. Gather what the decision needs
+
+Four things, and report them even when they are boring — "CI is green" is information:
+
+```bash
+gh pr checks <n> --repo <owner/repo>            # every check and its state
+gh pr diff  <n> --repo <owner/repo>             # the change itself
+gh pr view  <n> --repo <owner/repo> --comments  # review comments, and any bot review
+```
+
+If an automated review has already commented, **read it and say whether you agree**. Two reviews
+that disagree is a finding; two that agree is worth stating once, not twice.
+
+`mergeStateStatus` explains a blocked PR without guessing: `BLOCKED` (needs a review),
+`BEHIND` (needs *Update branch*), `UNSTABLE` (a check failed), `DIRTY` (conflicts).
+
+## 3. Review the diff
+
+Hand it to `/caddis:gate-review` — or the native `/code-review` on Claude Code. Then, on top of its
+verdict, check the things that have actually cost this fleet time, because a generic reviewer will
+not know to look:
+
+- **A gate that cannot fail.** A check whose failure path cannot execute — piped to `Out-Null`,
+  wrapped in a `catch{}` a native non-zero exit can never trigger, or asserting something too broad
+  to attribute. It manufactures confidence. Worse than no check.
+- **A wall-clock assertion.** A timing threshold on a shared runner measures load, not the code.
+  Assert ordering instead.
+- **Staged directories.** `git add -A` / `git add .` sweeps in files nobody reviewed.
+- **CI shell assumptions.** The runner may be Windows PowerShell 5.1, where a native command's
+  stderr becomes a terminating error under `$ErrorActionPreference='Stop'`, and where `Should -Be`
+  (Pester 4 syntax) fails on a Pester 3 runner.
+- **Deploy-script changes.** If the pipeline runs the deploy script from a checkout it also updates,
+  the change does not take effect on the deploy that delivers it. Budget two deploys.
+- **Verification by proxy.** An HTTP 200 or a version string is not proof a page renders.
+- **Credentials.** A token scoped to the wrong host; a permission raised to make a test pass; a
+  secret in a URL where git will echo it into a log.
+- **A doc the change makes untrue.** Comments and runbooks that were accurate until this diff.
+
+## 4. Report, then hand over
+
+Lead with the verdict. Keep it short enough to read before deciding:
+
+- **What this PR does** — one or two sentences, not a file list.
+- **Blocking issues** — each with file, line, and why it matters. None is a valid answer, and say it.
+- **Should-fix / nits** — grouped, brief.
+- **CI** — green, red, or still running. Name the failing check.
+- **Merge state** — and what would clear it.
+
+Then print the exact commands, and stop:
+
+```bash
+# approve
+gh pr review <n> --repo <owner/repo> --approve
+gh pr merge  <n> --repo <owner/repo> --squash --delete-branch
+
+# or ask for changes
+gh pr review <n> --repo <owner/repo> --request-changes --body "..."
+```
+
+**If you found a blocking issue, say so in the verdict line** rather than burying it under the
+summary. The operator should be able to read the first line and know whether to keep reading.

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

@@ -1,105 +1,6 @@
 ---
 name: statusline
-description: Install the caddis status line into Claude Code and agy — one renderer, once per machine
+description: Renamed to /caddis:install-statusline (alias, removed next release)
 ---
 
-# /statusline — set up the status bar
-
-Wire the caddis status line into every coding agent on this machine. One Python renderer serves
-both hosts. It installs at **user scope**, so every project gets the line and no project holds a
-copy that can drift.
-
-## What the user gets
-
-Claude Code:
-
-```
-⌂ claudster-source | saajunaid/caddis ⎇ main +2 ●1 ?3 ↑1 | ◆ Opus 5 (1M context) v2.1.239 |
-◉ 412k/1M [███░░░░░]  41%  | ⚡ 386k cached | effort:high | style:Plain | thinking |
-5h:12% 7d:40% | 💻 57% (37 GB) | ⏺ relay | ◷ 07:58
-```
-
-agy (Antigravity):
-
-```
-▛▜ agy | ● idle | 🧠 Gemini 3.6 Flash (High) (high) | 📁 claudster-source | ⎇ main ?3 |
-◉ 48.5k/1M [░░░░░░░░]  5%  | ⚡ 40k cached | q 62% | 💻 57% (37 GB) | ⏺ relay | ◷ 08:01
-```
-
-Both lines come from `caddis_statusline.py`. It has two profiles, because the two hosts send
-different field names — agy's payload is a sibling of Claude Code's, not a copy.
-
-## Run it
-
-Find the renderer in this install and run it. Try these paths in order and use the first that exists:
-
-- `${CLAUDE_PLUGIN_ROOT}/scripts/caddis_statusline.py`
-- `claude-harness/scripts/caddis_statusline.py` (working inside the caddis source repo)
-
-Then:
-
-```bash
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_statusline.py" --install          # both hosts
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_statusline.py" --install --host claude
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_statusline.py" --install --host agy
-python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_statusline.py" --install --dry-run # print, write nothing
-```
-
-`--install` does four things:
-
-1. Copies the renderer to `~/.caddis/statusline.py` — a **stable** path. Pointing the host
-   settings at the plugin cache would break on every caddis upgrade, because the version number
-   is in that path.
-2. Creates `~/.caddis/statusline.json` with the default toggles. It never overwrites an existing one.
-3. Backs up each host's `settings.json` to `settings.json.bak-caddis-statusline`.
-4. Sets `statusLine` in `~/.claude/settings.json` and `~/.gemini/antigravity-cli/settings.json`,
-   preserving every other key. A host that is not installed is skipped, not failed.
-
-Report the tool's own output to the user. Then tell them the line appears on the **next** session —
-neither host re-reads `settings.json` mid-session.
-
-## Verify
-
-```bash
-python ~/.caddis/statusline.py --check                        # what is wired where
-python ~/.caddis/statusline.py --sample --profile claude      # preview, no host needed
-python ~/.caddis/statusline.py --sample --profile agy
-```
-
-`--check` exits non-zero when a host's `statusLine` is missing or points somewhere else.
-
-## Change the look
-
-Edit `~/.caddis/statusline.json`. Every key is optional; a missing file means defaults.
-
-| key | default | what it controls |
-|---|---|---|
-| `color` | `true` | ANSI colour |
-| `icons` | `true` | Unicode segment icons. These are plain Unicode, **not** Nerd Font glyphs |
-| `progress_bar` | `true` | the `[███░░░░░]` context bar |
-| `bar_width` | `8` | bar cells |
-| `token_counts` | `true` | `◉ 412k/1M` |
-| `cached_tokens` | `true` | `⚡ 386k cached` — bold and bright by design, never width-gated |
-| `ram` | `true` | `💻 57% (37 GB)` |
-| `ram_min_width` | `0` | hide RAM below this terminal width; `0` always shows it |
-| `clock` | `true` | `◷ 07:58` |
-| `relay` | `true` | `⏺ relay` when a parked resume pointer exists |
-| `rate_limits` | `true` | `5h:12% 7d:40%` (Claude Code only) |
-| `session_id` | `false` | `#a1b2c3d4` |
-| `git` | `true` | branch, staged/unstaged/untracked counts, ahead/behind |
-| `separator` | `"\|"` | segment separator |
-
-Config changes take effect on the next render. No reinstall needed.
-
-## Notes for you, not the user
-
-- Do **not** hand-edit either `settings.json` to wire this. `--install` reads, merges and writes
-  back, so it cannot drop an unrelated key. Hand edits have dropped `trustedWorkspaces` before.
-- The renderer never crashes the host. A bad payload, a missing field, or an unreadable config
-  degrades to fewer segments; a hard failure degrades to the directory name.
-- RAM on Windows uses `ctypes` `GlobalMemoryStatusEx`, an in-process call. Do not replace it with
-  `Get-CimInstance Win32_OperatingSystem` — that cost about 300 ms on **every** render in the
-  PowerShell line this replaced.
-- If the user asks why their old `~/.claude/statusline-custom.sh` or
-  `~/.gemini/statusline/statusline.ps1` no longer runs: nothing points at them any more. They are
-  superseded, not deleted. Both are safe to remove once the user is happy with the new line.
+This command was renamed to /caddis:install-statusline. Run /caddis:install-statusline now with the same arguments ($ARGUMENTS), and tell the user once: "/caddis:statusline is renamed to /caddis:install-statusline; the old name will be removed in the next release."

package/bundles/antigravity-plugin-extras/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "caddis-extras",
-  "version": "1.3.37",
+  "version": "1.3.39",
   "description": "caddis-extras — the long-tail skills for the Antigravity (agy) caddis plugin; install alongside caddis for the full set."
 }

package/bundles/antigravity-plugin-extras/skills/cross-review/SKILL.md

@@ -79,7 +79,7 @@ python "$TOOL" --range origin/main..HEAD                   # review a branch's c
 ```
 Optional flags: `--cwd <repo>`, `--base-url <url>`, `--model <id>` (override the env).
 
-**Diff-size ceiling.** A diff over `REVIEW_MAX_DIFF_CHARS` (default 60,000 chars) is **split into batches** on whole-file boundaries and each batch reviewed separately (verdict is CLEAN only if every batch is). Exit 2 now means a *single unsplittable file* over the ceiling, or too many batches — not an ordinary large diff. Previously it was refused with exit 2
+**Diff-size ceiling.** A diff over `REVIEW_MAX_DIFF_CHARS` (default 60,000 chars) is **split into batches** on whole-file boundaries and each batch reviewed separately (verdict is CLEAN only if every batch is). Exit 4 means a *single unsplittable file* over the ceiling, or too many batches — not an ordinary large diff. Previously it was refused before any LLM call
 *before* any LLM call — an oversized diff has been observed to come back either an empty response, or
 worse, a `REVIEW: CLEAN` with zero real engagement. If you hit this, narrow `--range` or review in
 smaller chunks; don't just raise `--max-diff-chars` without knowing the endpoint's real limit.
@@ -89,14 +89,14 @@ smaller chunks; don't just raise `--max-diff-chars` without knowing the endpoint
 - **1 — REVIEW: BLOCKING** → the reviewer found blocking issues. **Read the printed findings, then FIX
   each blocking item** (or, if you judge one a false positive, state explicitly why it's safe to ignore).
   Re-run until CLEAN.
-- **2 — error** → no verdict parsed, a git failure, or an endpoint/parse failure. Read stderr; do not
+- **4 — error** → no verdict parsed, a git failure, or an endpoint/parse failure. Read stderr; do not
   treat this as CLEAN — investigate.
 - **3 — misconfigured** → `REVIEW_API_KEY` is unset. Set it (see Prerequisites) and re-run.
 
 ## Rules
 - This is a **read-only second opinion** — the tool never edits, commits, or pushes. YOU apply fixes in
   the main thread after reading the findings.
-- Treat exit 2/3 as blocking-unknown, never as approval (the tool is fail-closed by design).
+- Treat exit 3/4 as blocking-unknown, never as approval (the tool is fail-closed by design).
 - Different vendor ⇒ different style; weigh its findings on merit, don't cargo-cult them.
 - **Never use `find`, `Get-ChildItem -Recurse`, or any other filesystem-wide search to locate
   `oss_review.py`.** Check only the two paths above. On Git Bash under Windows, `find /` (or any

package/bundles/antigravity-plugin-extras/skills/data-lineage/SKILL.md

@@ -71,7 +71,7 @@ A comprehensive table specifying the complete end-to-end data lineage across the
 | ... | ... | ... | ... | ... | ... | ... | ... |
 
 Column specifications:
-- **App:** Application identifier (e.g. `rev-sight`).
+- **App:** Application identifier (e.g. `billing-portal`).
 - **UI Page:** User interface page path and title (e.g. `/runs (Run Monitor)`).
 - **API Route:** HTTP method and endpoint (e.g. `GET /api/runs`).
 - **Dataset:** Schema-qualified tables or views read (e.g. `[dbo].[CDR_RUN_LOG]`).

package/bundles/antigravity-plugin-extras/skills/golden-plan/SKILL.md

@@ -7,7 +7,7 @@ description: "USE THIS SKILL whenever a user asks for a comprehensive implementa
 # Golden Plan
 
 > **`/caddis:feature-plan` is the canonical planning entry point.** It writes to `.caddis/plans/`,
-> which is what `/caddis:implement`, `/caddis:handoff`, `/caddis:digress` and `/caddis:resume`
+> which is what `/caddis:implement`, `/caddis:handoff`, `/caddis:digress` and `/caddis:catchup`
 > actually read, and it now carries this skill's evidence gate. Reach for golden-plan when you
 > specifically need its heavier apparatus — the data-binding tables, the query catalog, the
 > self-sweep. For ordinary multi-phase work, feature-plan is the shorter path to the same place.

package/bundles/codex/.codex/config.toml.example

@@ -18,19 +18,3 @@
 # [[skills.config]]
 # path = ".codex/skills/devops/windows-deployment"
 # enabled = false
-
-# ── junai MCP (pipeline state + project context) ─────────────────────────────
-# OFF by default. The junai MCP server tracks pipeline stage and project state
-# across sessions. Enable when the server is available locally.
-#
-# Prerequisites:
-#   pip install junai-mcp   (or: uv tool install junai-mcp)
-#   codex mcp add junai -- python -m junai_mcp --project-root .
-#
-# Or add the block below manually and run `codex mcp list` to confirm:
-#
-# [[mcp_servers]]
-# name = "junai"
-# command = "python"
-# args = ["-m", "junai_mcp", "--project-root", "."]
-# env = {}

package/bundles/codex/AGENTS.md

@@ -57,7 +57,7 @@ On a fresh session read in order: `.caddis/relay.md` (if present) → the active
   runbook, analysis, handoff) must open with a YAML frontmatter block:
   ```yaml
   ---
-  type: plan|prd|adr|design|runbook|handoff|analysis|review
+  type: plan|prd|adr|design|runbook|handoff|analysis|review|prompt|parking-lot|rca|todo|relay|comms|reference|note|phase-report|implement-review|phase-verdict|hub-spawn|advisory-context|phase-prompt
   status: draft|current|done|superseded
   feature: <feature-slug>
   creation-agent: caddis
@@ -111,7 +111,7 @@ future: yes              # OPTIONAL. yes = committed. Absent or `no` = a candida
 life, and whether we have agreed to do it. `python scripts/caddis_tidy.py --check` and the
 `caddis_gate.py parking-lot` gate both fail on a non-conforming item, so this is enforced, not
 advised. Two neighbours that are NOT the backlog: `/caddis:digress` parks an interrupted task on a
-stack (`/caddis:resume` pops it), and `.caddis/backlog/` is written by **docket** as a projection of
+stack (`/caddis:catchup` pops it), and `.caddis/backlog/` is written by **docket** as a projection of
 its board — never hand-edit that one.
 
 ### Write environment facts down in the same turn

package/bundles/manifest.json

@@ -1,8 +1,8 @@
 {
-  "poolVersion": "1.3.119",
+  "poolVersion": "1.3.120",
   "bundles": {
-    "antigravity-plugin": "1.3.119",
-    "antigravity-plugin-extras": "1.3.37",
+    "antigravity-plugin": "1.3.120",
+    "antigravity-plugin-extras": "1.3.39",
     "codex": "unknown"
   }
 }

package/dist/claude-deepseek.js

@@ -326,7 +326,7 @@ import { isAbsolute, join } from "path";
 var PROVIDERS = {
   deepseek: {
     baseUrl: "https://api.deepseek.com/anthropic",
-    model: "deepseek-v4-flash[1m]",
+    model: "deepseek-flash[1m]",
     keyEnv: "DEEPSEEK_API_KEY"
   },
   glm: {

package/dist/claude-glm.js

@@ -326,7 +326,7 @@ import { isAbsolute, join } from "path";
 var PROVIDERS = {
   deepseek: {
     baseUrl: "https://api.deepseek.com/anthropic",
-    model: "deepseek-v4-flash[1m]",
+    model: "deepseek-flash[1m]",
     keyEnv: "DEEPSEEK_API_KEY"
   },
   glm: {

package/dist/claude-oss.js

@@ -326,7 +326,7 @@ import { isAbsolute, join } from "path";
 var PROVIDERS = {
   deepseek: {
     baseUrl: "https://api.deepseek.com/anthropic",
-    model: "deepseek-v4-flash[1m]",
+    model: "deepseek-flash[1m]",
     keyEnv: "DEEPSEEK_API_KEY"
   },
   glm: {

package/dist/cli.js

@@ -4888,7 +4888,7 @@ var init_resolve = __esm({
     PROVIDERS = {
       deepseek: {
         baseUrl: "https://api.deepseek.com/anthropic",
-        model: "deepseek-v4-flash[1m]",
+        model: "deepseek-flash[1m]",
         keyEnv: "DEEPSEEK_API_KEY"
       },
       glm: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@caddis/cli",
-  "version": "0.4.30",
+  "version": "0.4.33",
   "description": "Install, update and diagnose the caddis dev harness across every coding agent you use (Claude Code, agy/Antigravity, and more).",
   "keywords": [
     "caddis",