@caddis/cli 0.4.55 → 0.4.57

package/bundles/antigravity-plugin/skills/writing-plans/SKILL.md

@@ -102,7 +102,7 @@ Expected: PASS
 
 ```bash
 git add tests/path/test.py src/path/file.py
-git commit -m "feat: add specific feature"
+git commit -m "feat: add specific feature" -- tests/path/test.py src/path/file.py
 ```
 ```
 

package/bundles/antigravity-plugin/warm_start_agy.py

@@ -28,6 +28,19 @@ import os
 import subprocess
 import sys
 
+# No child process of this hook opens a console window on Windows (scripts/no_window.py). agy hooks ship
+# FLAT at the plugin root with scripts/ beside them; in the source repo scripts/ is one level up.
+try:
+    _nw_here = os.path.dirname(os.path.abspath(__file__))
+    for _nw_cand in (os.path.join(_nw_here, "scripts"), os.path.join(os.path.dirname(_nw_here), "scripts")):
+        if os.path.isfile(os.path.join(_nw_cand, "no_window.py")):
+            if _nw_cand not in sys.path:
+                sys.path.insert(0, _nw_cand)
+            break
+    from no_window import NO_WINDOW_KW  # noqa: E402
+except Exception:  # pragma: no cover - defensive
+    NO_WINDOW_KW = {"creationflags": 0x08000000} if os.name == "nt" else {}
+
 _ARTIFACT_DIRS = (".caddis",)
 
 INJECT_MAX_LINES = 120      # same budget as the Claude Code hook
@@ -151,7 +164,7 @@ def resolve_relay(root: str, session_id: str = "") -> tuple[str, str | None]:
     try:
         branch = subprocess.run(
             ["git", "-C", root, "rev-parse", "--abbrev-ref", "HEAD"],
-            capture_output=True, text=True, timeout=3,
+            capture_output=True, text=True, timeout=3, **NO_WINDOW_KW,
         ).stdout.strip()
     except Exception:
         branch = ""
@@ -232,23 +245,32 @@ def _hook_note(feature, exc, root=None):
 
 
 
-def _injected_marker(root, conversation):
-    """Path of the per-conversation "relay already injected" marker, or None."""
-    try:
-        safe = "".join(c for c in str(conversation) if c.isalnum() or c in "-_")[:64]
-        if not safe:
-            return None
-        return os.path.join(str(root), ".caddis", ".relay-injected", safe)
-    except Exception:
-        return None
+def _safe_conversation(conversation):
+    return "".join(c for c in str(conversation) if c.isalnum() or c in "-_")[:64]
+
+
+def _injected_markers(root, conversation):
+    """Where the "relay already injected" marker for this conversation may be: (repo marker, temp marker).
+
+    The repo marker lives in `.caddis/.relay-injected/`. The temp marker lives in the user's temp
+    folder, keyed by the repo path, for a repo that has no `.caddis/` (the hook must not create one).
+    """
+    safe = _safe_conversation(conversation)
+    if not safe:
+        return None, None
+    import hashlib
+    import tempfile
+    repo_marker = os.path.join(str(root), ".caddis", ".relay-injected", safe)
+    key = hashlib.sha1(os.path.normcase(os.path.abspath(str(root))).encode("utf-8", "replace")).hexdigest()[:16]
+    temp_marker = os.path.join(tempfile.gettempdir(), "caddis-relay-injected", key + "-" + safe)
+    return repo_marker, temp_marker
 
 
 def _already_injected(root, conversation):
     """True when this conversation has had its relay injected before. Fail-open: on any
     error return False, because a duplicate relay is a smaller harm than none at all."""
     try:
-        marker = _injected_marker(root, conversation)
-        return bool(marker) and os.path.isfile(marker)
+        return any(m and os.path.isfile(m) for m in _injected_markers(root, conversation))
     except Exception:
         return False
 
@@ -256,13 +278,15 @@ def _already_injected(root, conversation):
 def _mark_injected(root, conversation):
     """Record that this conversation received its relay. Never raises.
 
-    A failure here means the next truncation may re-inject — the pre-2026-08-22 behaviour,
-    which is exactly the fail-open direction we want.
+    The marker goes in `.caddis/` when the repo already has it, else in the user's temp folder:
+    this hook never creates `.caddis/` in a repo that did not opt in. A failure here means the
+    next truncation may re-inject, which is the fail-open direction we want.
     """
     try:
-        marker = _injected_marker(root, conversation)
-        if not marker:
+        repo_marker, temp_marker = _injected_markers(root, conversation)
+        if not repo_marker:
             return
+        marker = repo_marker if os.path.isdir(os.path.join(str(root), ".caddis")) else temp_marker
         os.makedirs(os.path.dirname(marker), exist_ok=True)
         with open(marker, "w", encoding="utf-8") as fh:
             fh.write("")

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

@@ -1,5 +1,5 @@
 {
   "name": "caddis-extras",
-  "version": "1.3.43",
+  "version": "1.3.45",
   "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/agent-orchestration/SKILL.md

@@ -128,7 +128,7 @@ Spec Input
 2. Categorise every item by effort (H = hours, D = days) and value (high / medium / low)
 3. Items that are **≤ 1 hour AND high-value** become quick wins (H1, H2, H3…)
 4. Implement quick wins in a single session
-5. Run full test suite — all tests must pass
+5. Run the tests of the touched files in the foreground (each command under 10 minutes) — all must pass. CI runs the full suite
 6. Commit: `feat: H1–H3 quick wins — <summary>`
 
 **Decision Gate:**
@@ -266,10 +266,10 @@ Score each identified risk:
 2. Provide the phase prompt:
    ```
    Read .caddis/plans/<feature>.md and implement Phase N.
-   Run pytest after every file change. All tests must pass before commit.
+   Run the tests of the files you changed, in the foreground, each command under 10 minutes. They must pass before commit. CI runs the full suite.
    ```
 3. Implement Agent reads the plan, executes numbered steps
-4. After implementation: run full test suite
+4. After implementation: run the tests of the touched files in the foreground (each command under 10 minutes). CI runs the full suite
 5. If tests pass → commit: `feat(<scope>): phase N — <summary>`
 6. If tests fail → fix within the same session before committing
 
@@ -340,7 +340,7 @@ The plan document should contain **copy-paste prompts** for each phase. This rem
    - Acceptance criteria
 3. **Write fix-up plan** — Place in `.caddis/plans/<feature>-fixup.md`
 4. **Execute** — Implement Agent works through issues sequentially
-5. **Verify** — Run full test suite + visual inspection
+5. **Verify** — Run the tests of the touched files (foreground, each command under 10 minutes) + visual inspection. CI runs the full suite
 6. **Commit** — `fix(<scope>): post-track cross-component polish`
 
 **Example from practice:**
@@ -610,7 +610,7 @@ Every stage that produces code changes should result in a commit:
 A well-orchestrated session should produce:
 
 - [ ] **Traceability** — Every spec requirement maps to a plan step, which maps to a commit
-- [ ] **Green tests** — Full suite passing after every commit
+- [ ] **Green tests** — Touched-file tests pass before every commit; CI runs the full suite on every PR
 - [ ] **Clean plan** — Fidelity audit: 0 gaps
 - [ ] **Managed risks** — No showstoppers unresolved
 - [ ] **Minimal rework** — Debug pass finds cosmetic issues, not fundamental errors

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

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

package/bundles/antigravity-plugin-extras/skills/deploy-local/SKILL.md

@@ -80,7 +80,8 @@ Example:
 ```powershell
 git status --short
 git add <files>
-git commit -m "fix(ci): resolve deploy health check"
+git diff --cached --name-only   # only <files>; else stop and report
+git commit -m "fix(ci): resolve deploy health check" -- <files>
 git push origin main
 git rev-parse HEAD
 ```

package/bundles/antigravity-plugin-extras/skills/update-readme/SKILL.md

@@ -54,7 +54,7 @@ Use this skill when users ask to:
 ### Phase 4 — Stage only README changes for docs commit
 
 1. Stage README files only:
-   - `git add README.md **/README.md`
+   - `git add README.md <each changed README by path>` (no `**` pattern: the guard denies it)
 2. Verify staged diff contains no non-README files.
 3. Suggested conventional commit:
    - `docs(readme): document <feature summary>`

package/bundles/codex/.codex/skills/coding/refactoring/SKILL.md

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

package/bundles/codex/.codex/skills/devops/gh-cli/SKILL.md

@@ -73,7 +73,10 @@ gh pr diff 55
 gh pr checkout 55
 gh pr review 55 --approve --body "LGTM!"
 gh pr review 55 --request-changes --body "Please fix error handling"
-gh pr merge 55 --squash --delete-branch
+# merge only on ci-watch RESULT: pass, only its HEAD:, with no default-branch run in progress
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --pr 55
+gh run list --branch main --json status       # no in_progress or queued run (main = the default branch)
+gh pr merge 55 --squash --delete-branch --match-head-commit <watched head>
 
 # Manage
 gh pr ready 55             # Mark draft as ready
@@ -168,10 +171,11 @@ gh alias set review 'pr list --search "review-requested:@me"'
 ```bash
 gh issue develop 42 --branch fix/issue-42
 git add src/auth/login.py tests/test_login.py   # named files only, never `git add .`
-git commit -m "fix: resolve login bug" && git push -u origin HEAD
+git commit -m "fix: resolve login bug" -- src/auth/login.py tests/test_login.py && git push -u origin HEAD
 gh pr create --title "fix: resolve login bug" --body "Closes #42"
-gh pr checks --watch
-gh pr merge --squash --delete-branch
+python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_lanes.py" ci-watch --pr <n>   # RESULT: pass, HEAD: <watched head>
+gh run list --branch main --json status       # wait while a default-branch run is in progress
+gh pr merge <n> --squash --delete-branch --match-head-commit <watched head>
 ```
 
 ### Release Workflow
@@ -189,8 +193,8 @@ gh release upload v1.3.0 ./dist/*.tar.gz
 | Create repo       | `gh repo create name --public`                 |
 | Create issue      | `gh issue create --title "..." --labels bug`   |
 | Create PR         | `gh pr create --title "..." --reviewer user`   |
-| Merge PR          | `gh pr merge 55 --squash --delete-branch`      |
+| Merge PR          | `gh pr merge 55 --squash --delete-branch --match-head-commit <watched head>`, only after ci-watch `RESULT: pass` |
 | Create release    | `gh release create v1.0.0 --generate-notes`    |
-| Watch CI          | `gh run watch`                                 |
+| Watch CI          | `caddis_lanes.py ci-watch --pr 55` (fallback: `gh run watch`) |
 | Set secret        | `echo "val" \| gh secret set KEY`              |
 | API call          | `gh api /repos/o/r --jq '.description'`        |

package/bundles/codex/.codex/skills/devops/git-commit/SKILL.md

@@ -87,9 +87,8 @@ Optional area of change:
    # Stage specific files
    git add path/to/file1 path/to/file2
 
-   # Stage by pattern
-   git add *.test.*
-   git add src/components/*
+   # Never stage by pattern or folder (`*.test.*`, `src/components/`): a pattern also takes
+   # files you did not change, and the caddis guard denies it. Name each file.
    ```
 
    **Never stage secrets** (`.env`, `credentials.json`, private keys).

package/bundles/codex/.codex/skills/docs/writing-plans/SKILL.md

@@ -102,7 +102,7 @@ Expected: PASS
 
 ```bash
 git add tests/path/test.py src/path/file.py
-git commit -m "feat: add specific feature"
+git commit -m "feat: add specific feature" -- tests/path/test.py src/path/file.py
 ```
 ```
 

package/bundles/codex/.codex/skills/workflow/roadmap/SKILL.md

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

package/bundles/codex/.codex/skills/workflow/roadmap/assets/review-protocol.md

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

package/bundles/manifest.json

@@ -1,8 +1,8 @@
 {
-  "poolVersion": "1.3.141",
+  "poolVersion": "1.3.143",
   "bundles": {
-    "antigravity-plugin": "1.3.141",
-    "antigravity-plugin-extras": "1.3.43",
+    "antigravity-plugin": "1.3.143",
+    "antigravity-plugin-extras": "1.3.45",
     "codex": "unknown"
   }
 }

package/package.json

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