@chamba/claude-extras 0.4.0 → 0.5.0

package/assets/agents/reviewer.md

@@ -12,7 +12,12 @@ risky assumptions, scope that's too big for one pass.
 
 When reviewing a diff, check for: correctness bugs, missing tests, unhandled
 errors, security/permissions issues, and anything that violates the project's
-stated conventions.
+stated conventions. When the diff **deletes** code, also check referential
+closure both ways: nothing still references what was removed (forward), and
+nothing the removal orphaned is left behind — now-unused exports, helpers or
+imports whose only caller is gone (backward). A token grep misses orphans whose
+name doesn't contain the deleted symbol; lean on the build/typechecker and a
+dead-code check, not just grep.
 
 Output a verdict (`approved` or `changes requested`) followed by a concise,
 prioritized list of concrete issues. Do not rewrite the code yourself — describe

package/assets/commands/ticket.md

@@ -8,17 +8,26 @@ plan validation, worktrees and vault memory; you delegate the thinking and the
 code to the configured subagents. **Run to the end and stop only for my final
 review** — do not pause for approval mid-way.
 
+**One exception to running autonomously:** the plan itself may mark an item as
+needing my approval (scope expansion beyond the ticket, a destructive or
+irreversible change, a product decision you can't make). You do NOT act on those.
+You complete everything else and surface them at the final gate. Autonomy is
+bounded by the plan's gates — it must never silently drop an acceptance criterion.
+
 The first token of the arguments is the ticket id; any further tokens are repos I
 named explicitly. Analyze first, create worktrees only for the repos actually
 touched — do not create a worktree for every repo in the workspace.
 
 1. Call `chamba_load_context` with the ticket to pull the workspace map (all repos
-   and what each one is) + relevant Obsidian notes.
+   and what each one is) + relevant Obsidian notes + each repo's coding rules.
 2. Delegate to the **planner** subagent to produce the plan. The plan MUST state
-   **which repos the ticket touches and why**, with subtasks grouped per repo. If I
-   named repos in the arguments, use exactly those; otherwise infer the set from the
-   ticket + the workspace map. If anything is ambiguous, list it as an assumption —
-   do not invent scope.
+   **which repos the ticket touches and why**, with subtasks grouped per repo, and
+   it MUST map **every acceptance criterion of the ticket** to a subtask. If an AC
+   needs a decision you can't make autonomously, the plan marks it
+   **needs-approval** — that is a hard gate, not something to resolve on your own.
+   If I named repos in the arguments, use exactly those; otherwise infer the set
+   from the ticket + the workspace map. List ambiguities as assumptions — do not
+   invent scope.
 3. Run the plan through `chamba_review_plan` and have the **reviewer** subagent
    audit it. Fix and re-review until approved (max 3 rounds). Do NOT stop to ask me.
 4. Create isolated worktrees ONLY for the repos the plan identified: call
@@ -26,8 +35,24 @@ touched — do not create a worktree for every repo in the workspace.
    inside these worktrees — never edit the main checkouts.
 5. For each subtask/repo, delegate implementation to the **implementer** subagent
    (in that repo's worktree) and the tests to the **tester** subagent; run them.
-6. Call `chamba_summarize_to_vault` with a summary of what changed.
-7. STOP and report for my review: the repos touched and why; per repo, what changed
-   and the test results; the `.code-workspace` to open; and the suggested commit +
-   `git merge --no-ff` commands. Do NOT commit, merge or push — I review, commit and
-   send to my company's code review by hand.
+6. **Verify against the real diff** (not the plan). For each touched repo: have the
+   **reviewer** subagent audit the actual diff for correctness, missing tests, and
+   **referential closure** — anything the change deleted must leave no orphaned
+   callers and no now-unused exports. Then run that repo's build / typecheck / lint,
+   and a dead-code check if the repo has one (knip, ts-prune). Token grep alone
+   misses orphans whose name doesn't contain the deleted symbol — rely on the
+   build/typechecker/dead-code tool, not just grep. Fix what comes back, then
+   re-verify (max 3 rounds).
+7. Call `chamba_summarize_to_vault` with a summary of what changed.
+8. STOP and report for my review. The report MUST include:
+   - the repos touched and why;
+   - per repo, what changed and the test + verify results;
+   - an **acceptance-criteria checklist**: every AC of the ticket marked
+     **Delivered** or **Not delivered**. Anything the plan marked
+     **needs-approval**, or any AC you could not deliver without a deferred
+     decision, goes under **"Needs your decision"** with what's pending and why —
+     never omit it;
+   - the `.code-workspace` to open, and the suggested commit +
+     `git merge --no-ff` commands.
+   Do NOT commit, merge or push — I review, commit and send to my company's code
+   review by hand.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@chamba/claude-extras",
-  "version": "0.4.0",
+  "version": "0.5.0",
   "description": "Optional Claude Code extras for chamba: slash commands, subagents and hooks installer",
   "license": "MIT",
   "type": "module",
@@ -31,8 +31,8 @@
   ],
   "dependencies": {
     "@inquirer/prompts": "^7.0.0",
-    "@chamba/adapters": "0.4.0",
-    "@chamba/core": "0.4.0"
+    "@chamba/adapters": "0.5.0",
+    "@chamba/core": "0.5.0"
   },
   "devDependencies": {
     "@types/node": "^22.0.0",