@caddis/cli 0.4.69 → 0.4.71

package/bundles/antigravity-plugin/scripts/schemas/request.schema.json

@@ -0,0 +1,39 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "caddis hub owner request (one line of requests.jsonl)",
+  "description": "Appended by the hub, applied by caddis_coordinate.py intake. Readers accept v N and N-1. pr may be null only for approve/decline, and then args.what is required (ruling R2).",
+  "type": "object",
+  "required": ["v", "id", "created_at", "expires_at", "repo", "pr", "head_sha", "action", "args"],
+  "additionalProperties": false,
+  "properties": {
+    "v": {"type": "integer", "enum": [0, 1]},
+    "id": {"type": "string", "minLength": 1},
+    "created_at": {"$ref": "#/$defs/utc"},
+    "expires_at": {"$ref": "#/$defs/utc"},
+    "repo": {"type": "string", "minLength": 1},
+    "pr": {"type": ["integer", "null"], "minimum": 1},
+    "head_sha": {"type": ["string", "null"], "description": "40 hex characters when pr is set; compared case-insensitively"},
+    "action": {"enum": ["hotfix", "unhotfix", "hold", "release", "approve", "decline"]},
+    "args": {
+      "type": "object",
+      "properties": {"what": {"type": "string", "minLength": 1}}
+    }
+  },
+  "allOf": [
+    {
+      "if": {"properties": {"pr": {"type": "null"}}, "required": ["pr"]},
+      "then": {
+        "properties": {
+          "action": {"enum": ["approve", "decline"]},
+          "args": {"required": ["what"]}
+        }
+      },
+      "else": {
+        "properties": {"head_sha": {"type": "string", "pattern": "^[0-9a-fA-F]{40}$"}}
+      }
+    }
+  ],
+  "$defs": {
+    "utc": {"type": "string", "pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}Z$"}
+  }
+}

package/bundles/antigravity-plugin/skills/_registry.md

@@ -58,7 +58,7 @@
 | Office Documents Official | `office-documents-official/` | 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. |
 | Tech Explainer | `tech-explainer/` | >- |
 | Technical Writing | `technical-writing/` | Documentation best practices for READMEs, API docs, architecture docs, runbooks and developer guides. Use when writing or reviewing docs or setting documentation standards. |
-| Writing Plans | `writing-plans/` | Use when you have a spec or requirements for a multi-step task, before touching code |
+| Writing Plans | `writing-plans/` | Use when you have a spec or requirements for a multi-step task, before touching code. In caddis, plans are written with /caddis:feature-plan, the only plan writer; this skill sends you there. |
 
 ### Frontend
 

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

@@ -45,7 +45,7 @@ Start by understanding the current project context, then ask questions one at a
 **Implementation (if continuing):**
 - Ask: "Ready to set up for implementation?"
 - Use the `using-git-worktrees` skill (caddis, devops/) to create an isolated workspace
-- Use `/caddis:feature-plan` for a phased plan, or the `writing-plans` skill (caddis, docs/)
+- Use `/caddis:feature-plan` to write the plan (it is the only plan writer in caddis)
 
 ## Key Principles
 

package/bundles/antigravity-plugin/skills/feature-plan/SKILL.md

@@ -12,6 +12,9 @@ If `$ARGUMENTS` is empty, ask what to plan and stop.
 The plan file is the **durable spine of the harness** — it must let any future session (or another
 agent, on any tool) resume with zero re-discovery. Optimize for that.
 
+This command is the only plan writer in caddis. The task-level shape, Global Constraints, Review Focus and
+the self-review checklist are adapted from obra/superpowers `writing-plans` 7.0.0 (MIT); see NOTICE.md.
+
 ## Headless mode
 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
@@ -186,6 +189,29 @@ internal repo path into stakeholder-facing copy, and set a `live` status flag th
 framework's own "Soon" badge). `tsc` clean, 632/632 tests green, cross-review CLEAN, exit gate
 satisfied. A headless run following it literally would have committed both, entirely green.
 
+### Choose how each phase's tasks run (`Execution:`)
+Write one `Execution:` line per phase, next to its `Lane:` and model lines. A fixed rule picks it:
+- **`Execution: per-task`** when the phase has 3 or more tasks that consume each other's interfaces,
+  OR when a mistake would be costly: security, data loss, money, merges or deploys, concurrency.
+- Otherwise `Execution: inline`.
+
+`inline` means today's behaviour: one implementer does the whole phase. `per-task` means the executor
+gives each task a fresh implementer (on the phase's model tier and lane) and a short task review (spec
+compliance, then quality) before the next task starts. The task review does not replace the phase's review by another vendor:
+`review-tier` and `/caddis:cross-review` still run once per phase.
+
+A `per-task` phase is split into tasks. Each task must have:
+- **`Files:`** — every file to create, modify and test, with exact paths.
+- **`Interfaces:`** — `Consumes:` (what it uses from earlier tasks) and `Produces:` (what later tasks
+  use): exact names, parameters and return types. An implementer sees only its own task; this block is
+  how it learns the names that its neighbours use.
+- **Steps** — write the failing test (its name, its assertions and the exact values from the spec); run
+  it, expected FAIL; implement the named signature; run it, expected PASS; commit with named files.
+
+A task is the smallest unit that has its own test cycle and is worth its own review. Put setup, config
+and docs steps in the task whose deliverable needs them. An `inline` phase may keep the lighter shape of
+the phase template.
+
 ### Group phases into MILESTONES — only when the plan is big enough
 **Add milestones when the plan has ~8+ phases OR spans multiple sessions.** Below that, phases and a
 Tracker are enough; a three-phase feature gains nothing from ceremony.
@@ -240,6 +266,16 @@ Creating Model: <model-id>
 ## Constraints & decisions
 - <key tech decision + rationale>
 
+## Global Constraints
+<The project-wide requirements: version floors, dependency limits, naming and copy rules, platform needs.
+One line each, with the exact values copied from the spec or PRD. Every phase's requirements include
+this section.>
+
+## Review Focus
+<Up to five inputs or failure modes that the spec implies but no task test exercises, most likely first.
+One line each: the input or condition, and the behaviour a user expects. Each line gets a test, added
+to the phase or task that owns the code. Write "none found" only after you checked.>
+
 ## Phases
 
 ### Phase 1 — <name>  ⏳
@@ -249,6 +285,7 @@ Creating Model: <model-id>
 **Model:** <tier> (`/model <alias>`) — <one-line rationale tied to this phase's difficulty>
 **Lane:** claude — this session  |  glm-headless — `claude-glm -p "/caddis:implement <this plan's path> — Phase 1 only"`
 **Type:** backend | hard | ui | tests | docs  *(required when the Lane runs through caddis_lanes.py)*
+**Execution:** inline | per-task  *(the rule in Step 2; per-task phases list their tasks below)*
 **Session:** continue | **fresh** (start a new session for this phase — note why: lane change / heavy context)
 **Risk:** high — token-verification seam; a wrong answer here is a silent auth bypass  *(omit this line when normal)*
 **Goal:** <one sentence>
@@ -264,6 +301,18 @@ Creating Model: <model-id>
 **Then:** update the Tracker row (status + hash). If this phase ends the session, WRITE the handoff
 yourself (relay + Tracker) before stopping — do not hand back "run `/caddis:handoff`" as the next action.
 
+#### Task 1.1 — <name>  *(per-task phases only)*
+**Files:** create `<path>` · modify `<path>` · test `<test path>`
+**Interfaces:**
+  - Consumes: `<name>(<params>) -> <return type>` from Task <N.M>, or "none"
+  - Produces: `<name>(<params>) -> <return type>`
+**Steps:**
+  1. Write the failing test `<test path>::<case>`: assert `<call>` == `<exact value from the spec>`.
+  2. Run `<literal test command>`: expected FAIL (<the reason, not an import error>).
+  3. Implement `<name>(<params>) -> <return type>` in `<path>`.
+  4. Run `<literal test command>`: expected PASS.
+  5. Commit: `git add <named files>` then `git commit -m "<message>" -- <named files>`.
+
 ### Phase 2 — <name>  🔲
 <same structure>
 
@@ -278,6 +327,8 @@ Three rules: one attempt, one review.
 
 - One phase at a time: read this plan → run the phase on its **Lane** → RED→GREEN→VERIFY→CROSS-REVIEW→
   COMMIT → update the **Tracker** row. The Tracker is the resume signal for every future session.
+  An `Execution: per-task` phase runs task by task: a fresh implementer per task, and a task review
+  before the next task. The cross-review still runs once for the phase.
 - **Session boundaries:** the executor WRITES the handoff (durable `relay.md` + Tracker) after any
   phase that ends a sitting — it performs the work, it does not suggest the command. Start a FRESH
   session (or `/clear`) before any phase marked `Session: fresh`, before a lane change, or whenever
@@ -360,6 +411,8 @@ done:
   spawning another one forever; the `Phase N only` suffix is what stops the child running to the end
   of the plan. The command is executed verbatim by a model with no slack to notice a missing flag,
   and `/caddis:implement` now refuses a command without `-p` rather than running it.
+- **Execution named** — every phase has an `Execution:` line set by the rule in Step 2, and every task
+  of a `per-task` phase has `Files:`, `Interfaces:` and its five steps.
 - **caddis_lanes command carries --phase** — a `caddis_lanes.py` launch command must name `--phase N`
   and `--type`; lane-check refuses one without `--phase`.
 - **Gate-detectable** — if this phase's instruction were WRONG, its exit gate would go red. A phase
@@ -369,6 +422,16 @@ done:
 
 If any phase relies on the implementer *reasoning out* a gap, close the gap in the plan now.
 
+**Self-review (run it yourself after you write the plan, then fix what it finds in place):**
+- **Spec coverage** — each requirement in the spec or PRD maps to a phase or task. Add a task for a gap.
+- **Step scan** — no step that decides nothing ("TBD", "handle edge cases", "add validation", a name
+  that no task defines). No full function body that the signature and the tests already determine.
+- **Name consistency** — a name, signature or field in a later task matches the one an earlier task's
+  `Produces:` defines.
+- **Review Focus coverage** — each Review Focus line has its test in the task that owns the code.
+- **Proportion** — a plan several times longer than its spec is a transcript of the code. Replace the
+  bodies with signatures, test names and assertions.
+
 A `risk: high` phase gets two independent review runs: run by the roadmap/plan runner automatically (from caddis-next Phase 11), and by hand in an interactive `/caddis:implement` run (`caddis_review.py --plan <plan> --phase <n> --runs 2`, from Phase 10). Only a `blocking` finding fails that review (exit 1); `should-fix` and `nit` findings go on a follow-up list and do not stop the merge. A phase gets 3 completed review rounds (a run that did not complete uses none); the 4th ends with exit 5, "stop, the owner decides". The advisory hub is retired; do not plan a separate validation session.
 
 ## Programme triggers
@@ -381,7 +444,7 @@ Small work that does not meet a trigger skips its block.
 
 ## Step 4 — Report
 Output the plan path (`.caddis/plans/<feature-slug>.md`), the phase list (one line each, with each
-phase's model tier + lane), confirm the local-coder gate passed (or list the phases that need
+phase's model tier + lane + execution), confirm the local-coder gate passed (or list the phases that need
 tightening), and: *"To start: `read the plan and implement Phase 1`. To resume later: `/handoff` at
 session end, then `read relay.md` next time. The plan's Execution protocol carries every command —
 nothing to memorize."*

package/bundles/antigravity-plugin/skills/flow-studio/README.md

@@ -3,7 +3,7 @@
 The `flow-studio` skill: a model file (JSON) describes a flow, lifecycle or journey, and one
 engine draws it as a self-contained HTML page with pan and zoom, lanes, linked nodes, a slide-in
 inspector, scenario playback, metric overlays, live update, motion that carries state, and numbered implementation notes. The design is in
-`.caddis/plans/flow-studio-skill-design.md`; the S4 stage status is in `.caddis/plans/flow-studio-s4-status.md`.
+`.caddis/plans/done/flow-studio-skill-design.md`; the S4 stage status is in `.caddis/plans/flow-studio-s4-status.md`.
 `SKILL.md` is the current playbook.
 
 ## Use it

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

@@ -36,7 +36,6 @@ them into its commit, so check first, before Step 1.
    - Step 3, point 4: make the plan's Tracker edit in `<worktree>/.caddis/plans/<feature>.md`, and write
      any new parking-lot item under `<worktree>/.caddis/parking-lot/`, not in this checkout.
    - Step 4: skip `caddis_tidy.py --apply` (report `skipped: shared checkout`).
-   - Step 6: retired; nothing to skip (row 8 reports `skipped: retired (see the 3-store model)`).
    - Step 6b: skip `session_state.py prune` (report `skipped: shared checkout`).
    - Step 6c: run `--reindex` in the worktree (it edits the tracked `DOC-MAP.md`).
    - Step 6d: runs as written. It never writes a file in this checkout; it only removes worktrees and
@@ -53,27 +52,22 @@ them into its commit, so check first, before Step 1.
 
 ## Checklist
 The handoff is a fixed checklist. Every row ends as `done`, `skipped: <reason>` or `failed: <error>`, and
-Step 8 prints all 14 in this order. Never drop a row from the report, even when its step did not apply.
-Rows 3 and 8 are retired (the 3-store model, 21 Oct 2026): they stay in the list so the row numbers do not
-move for a fleet that mixes caddis versions, and each always reports
-`skipped: retired (see the 3-store model)`. A later release removes them with their scripts.
+Step 8 prints all 12 in this order. Never drop a row from the report, even when its step did not apply.
 
 | # | Row | What it is | Shared checkout (Step 0) |
 |---|---|---|---|
 | 1 | `knowledge-transfer` | Step 1 | edits only in the Step 0 worktree |
 | 2 | `plan-tracker` | the plan's Tracker row (Rules) | edit in the Step 0 worktree |
-| 3 | `open-work-row` | retired: always `skipped: retired (see the 3-store model)` | never runs |
-| 4 | `relay` | Step 3: the relay, written from scratch with current state only | the relay is local; runs |
-| 5 | `tasks-file` | Step 3c | runs |
-| 6 | `kb-index` | Step 6c: refresh the KB index | in the Step 0 worktree |
-| 7 | `violations-report` | Step 6c: report standing violations, each with a one-line fix command | runs (report only) |
-| 8 | `todo-reconcile` | retired: always `skipped: retired (see the 3-store model)` | never runs |
-| 9 | `usage-record` | Step 6b: `session_state.py usage` | runs |
-| 10 | `tidy-apply` | Step 4: `caddis_tidy.py --apply` | `skipped: shared checkout` |
-| 11 | `state-prune` | Step 6b: `session_state.py prune` | `skipped: shared checkout` |
-| 12 | `prune-list` | Step 6b: `caddis_tidy.py --prune --temp`, list only | runs (lists, never applies) |
-| 13 | `handover-check` | Step 5 | runs |
-| 14 | `own-cleanup` | Step 6d: `caddis_created.py cleanup --apply` removes this session's merged, clean worktrees and scratch folders; lists the rest with a reason | runs (only this session's recorded worktrees and scratch) |
+| 3 | `relay` | Step 3: the relay, written from scratch with current state only | the relay is local; runs |
+| 4 | `tasks-file` | Step 3c | runs |
+| 5 | `kb-index` | Step 6c: refresh the KB index | in the Step 0 worktree |
+| 6 | `violations-report` | Step 6c: report standing violations, each with a one-line fix command | runs (report only) |
+| 7 | `usage-record` | Step 6b: `session_state.py usage` | runs |
+| 8 | `tidy-apply` | Step 4: `caddis_tidy.py --apply` | `skipped: shared checkout` |
+| 9 | `state-prune` | Step 6b: `session_state.py prune` | `skipped: shared checkout` |
+| 10 | `prune-list` | Step 6b: `caddis_tidy.py --prune --temp`, list only | runs (lists, never applies) |
+| 11 | `handover-check` | Step 5 | runs |
+| 12 | `own-cleanup` | Step 6d: `caddis_created.py cleanup --apply` removes this session's merged, clean worktrees and scratch folders; lists the rest with a reason | runs (only this session's recorded worktrees and scratch) |
 
 `tidy-apply` and `state-prune` run only on `SHARED: no`. Handoff never runs
 `caddis_tidy.py --prune --apply` on its own, in any checkout (nor `--prune --temp --apply`); only the user can ask for it (Step 6b). In a
@@ -172,7 +166,6 @@ history, and the relay has a 4,000-character budget (`caddis_budget.py`).
 >      checkout (Step 0) write it in the Step 0 worktree.
 >    - **The order of work:** the plan Tracker and the roadmap (below). Set the Tracker row of each phase this
 >      session finished (Rules).
->    Row 3 (`open-work-row`) is retired: report it exactly as `skipped: retired (see the 3-store model)`.
 >    The `.caddis/open-work.md` and `.caddis/todo-list/` stores are retired. Never write them. A repo that
 >    still holds an old file keeps it as its own document; caddis no longer reads or writes it.
 >    **Order of work:** when the repo has a roadmap (`caddis_roadmap.py list` prints a slug), the
@@ -294,11 +287,6 @@ incoming session looking for a prompt that was never written. Fix what it lists,
 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.
 
-## Step 6 — retired (task reconcile)
-This step is retired. It used to reconcile the `todo-list/` store, which is retired too (the 3-store model),
-so the step does nothing: do not run any script for it. Report row 8 (`todo-reconcile`) as
-`skipped: retired (see the 3-store model)`. The script stays in place for older installs only.
-
 ## Step 6b — record usage and tidy session state
 The Stop hook only writes the session-state file. These two used to run on every turn; they run
 here, once:
@@ -309,7 +297,7 @@ 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. Skip `prune` in a
+`.caddis/session-state/`; run it after Step 3c, 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.
 
@@ -328,12 +316,12 @@ yourself**; deleting is the user's choice. If they ask, run `--prune --temp --ap
 Both scripts fall back to `claude-harness/scripts/check_doc_coverage.py` and `scripts/caddis_tidy.py` in a
 source checkout; a script that is missing is `skipped: <script> not installed`.
 
-Checklist row 6, `kb-index` (in a shared checkout, run it in the Step 0 worktree, before the Step 0
+Checklist row 5, `kb-index` (in a shared checkout, run it in the Step 0 worktree, before the Step 0
 `finish`; it edits `DOC-MAP.md`):
 ```
 python "${CLAUDE_PLUGIN_ROOT}/scripts/check_doc_coverage.py" --reindex
 ```
-Checklist row 7, `violations-report` (all three only report; never fix files here):
+Checklist row 6, `violations-report` (all three only report; never fix files here):
 ```
 python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_tidy.py" --check
 python "${CLAUDE_PLUGIN_ROOT}/scripts/check_doc_coverage.py"
@@ -353,7 +341,7 @@ python "${CLAUDE_PLUGIN_ROOT}/scripts/caddis_roadmap.py" render --all
 ```
 
 ## Step 6d — remove this session's own worktrees and scratch folders
-Checklist row 14, `own-cleanup`. It runs in every checkout, a shared one too, after the Step 0 `finish`
+Checklist row 12, `own-cleanup`. It runs in every checkout, a shared one too, after the Step 0 `finish`
 (falls back to `scripts/caddis_created.py` in a source checkout; if the script is missing, or exits 2 because
 it has no `cleanup`, the row is `skipped: not installed`):
 ```
@@ -392,18 +380,16 @@ Print this block, every row filled with `done`, `skipped: <reason>` or `failed:
 === HANDOFF CHECKLIST ===
 1 knowledge-transfer   done | skipped: <reason> | failed: <error>
 2 plan-tracker         <same three forms>
-3 open-work-row        skipped: retired (see the 3-store model)
-4 relay                <same three forms>
-5 tasks-file           <same three forms>
-6 kb-index             <same three forms>
-7 violations-report    <same three forms>
-8 todo-reconcile       skipped: retired (see the 3-store model)
-9 usage-record         <same three forms>
-10 tidy-apply          <same three forms>
-11 state-prune         <same three forms>
-12 prune-list          <same three forms>
-13 handover-check      <same three forms>
-14 own-cleanup         <same three forms>
+3 relay                <same three forms>
+4 tasks-file           <same three forms>
+5 kb-index             <same three forms>
+6 violations-report    <same three forms>
+7 usage-record         <same three forms>
+8 tidy-apply           <same three forms>
+9 state-prune          <same three forms>
+10 prune-list          <same three forms>
+11 handover-check      <same three forms>
+12 own-cleanup         <same three forms>
 Shared checkout: yes|no <reason>
 ```
 

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

@@ -236,6 +236,17 @@ report — do not redo completed work.
      every phase after the first, which is the original bug wearing a different hat. For a
      `caddis_lanes.py` launch command, follow "Multi-lane phases" above instead of spawning the command
      blind.
+   - **EXECUTION** — read the phase's `Execution:` line. A missing line means `inline` (older plans
+     have none). `inline`: run the steps below for the whole phase, as before. `Execution: per-task`:
+     run the phase's tasks in order. Give each task a fresh implementer: a subagent on the phase's
+     lane and model, with a brief that holds the task's `Files:`, `Interfaces:` and steps, the plan's
+     Global Constraints and the test-economy lines (Multi-lane item 7b). If you cannot dispatch a
+     subagent, implement the task yourself and note that in the review file. After each task, run a
+     short task review before the next task: first spec compliance (the task's files, names and tests
+     match the plan), then quality (the author self-check). Fix blocking findings, then go on. Record
+     each task (name, commit, review result) under `## Task progress` in the review file. Then run the
+     phase's normal gates: VERIFY, the `review-tier` review by another vendor, COMMIT and the Tracker.
+     The task reviews never replace that review.
    - **RED** — write the failing test(s) the phase names (`<test file>::<case>`). Run them; confirm they
      fail for the right reason (the missing behavior, not an import error). If a phase genuinely has no
      testable surface, say so in the review file and implement the minimal change directly.
@@ -348,6 +359,9 @@ branch: <current branch>
 ## Assumptions made
 - <any gap the plan left that you decided — or "none">
 
+## Task progress  *(only for `Execution: per-task` phases)*
+- <phase N task N.M — commit <hash> — task review: clean | fixed <finding>>
+
 ## Not done / follow-ups
 - <phases skipped/blocked and why — or "none; all phases complete">
 

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

@@ -33,6 +33,15 @@ impactful finding** — the one most likely to reduce rate-limit consumption or
 
 Do NOT paraphrase every finding in prose — the report is already the output.
 
+## Step 2b — check the borrowed upstream skills
+
+Run `python "<scripts folder>/caddis_upstream_check.py"` from the project root (same folder as
+`usage_review.py`). It compares the upstream skills that caddis borrowed ideas from with the copies
+installed on this machine. Show every `DRIFT` line in the report under **Upstream drift**. A `DRIFT`
+line means: review the upstream diff, port what fits, then update `.github/upstream-sources.json`.
+Say nothing for `UP-TO-DATE`, `NOT-INSTALLED` or `NO-SOURCES` (no record: not the caddis source repo).
+The check never fails the review.
+
 ## Step 3 — offer to apply
 
 For each finding marked **[apply]** in the report, ask the user whether to apply it.