mustard-claude 3.1.7 → 3.1.10

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mustard-claude",
-  "version": "3.1.7",
+  "version": "3.1.10",
   "description": "Framework-agnostic CLI for Claude Code project setup",
   "type": "module",
   "bin": {

package/templates/commands/mustard/complete/SKILL.md

@@ -32,6 +32,8 @@ node .claude/scripts/verify-pipeline.js "$PROJECT_DIR"
 
 If ANY gate fails: do NOT mark complete → report what failed + suggest fix. If review wasn't run → run it now before completing.
 
+Re-reviews always dispatch with `model: "sonnet"` (see `review/SKILL.md § Model Selection`).
+
 #### Surface Accumulated Concerns
 
 Before finalizing, scan the active spec for any `## Concerns` section written during EXECUTE:
@@ -54,6 +56,7 @@ See `.claude/pipeline-config.md` Escalation Statuses for concern classification
    - Mark all remaining `[ ]` as `[x]`
 4. **Entity Registry — update if needed:**
    - `node .claude/scripts/sync-registry.js`
+   - **Schema-aware refresh (conditional):** If the spec's `## Files` section touched any file matching `*.schema.ts`, `*.entity.ts`, `*.prisma`, `*DbContext*.cs`, or `schema.rs`, run `rtk node .claude/scripts/sync-registry.js` to refresh `entity-registry.json`. If sync-registry fails (non-zero exit or script missing), log a warning and continue with close — this step is non-blocking.
 5. **Move spec** from `.claude/spec/active/` to `.claude/spec/completed/`
 6. **Pipeline State — cleanup:**
    - Extract `spec-name` from the spec directory (e.g. `2026-02-26-linked-services-card`)

package/templates/commands/mustard/feature/SKILL.md

@@ -104,6 +104,12 @@ After ANALYZE completes, if the analysis required heavy exploration (>8 file rea
 - Suggest to user: _"Analysis complete. Context is heavy — consider `/compact` before we proceed to implementation, then `/resume`."_
 - This is advisory only — proceed immediately if user declines or ignores.
 
+### End of ANALYZE — Validation
+
+Run: `rtk node .claude/scripts/analyze-validation.js --spec .claude/spec/active/{specName}/spec.md`
+If output `ok: false`, append each `issues[]` entry to the spec under `## Concerns` (non-blocking).
+Continue to PLAN regardless.
+
 ### PLAN Phase
 
 #### Full Scope
@@ -161,6 +167,58 @@ Rules:
 - Be specific: prefer exact files over broad directories when the change is known
 - Out-of-boundary edits during EXECUTE will surface a `[BOUNDARY WARNING]` from guard-verify — treat as a signal to re-evaluate, not an error to suppress
 
+### Pre-EXECUTE Existence Gate (Full scope only)
+
+**Skip conditions**: Light scope OR `## Files` section lists more than 8 files (cost-benefit inverts — Haiku 10-tool-use cap will not cover).
+
+Before dispatching implementation agents, run 1 Haiku explorer to verify the work is still needed.
+
+**Pre-check (free, zero LLM tokens)**: Before dispatching Haiku, run:
+
+```bash
+rtk git diff --stat HEAD -- <files listed in `## Files` of spec>
+```
+
+Skip rules based on pre-check output:
+- **Empty output** (no changes) → skip gate entirely, proceed to EXECUTE normally (nothing to verify)
+- **<10 total insertions/deletions** → skip gate entirely, proceed to EXECUTE normally (trivial changes, verification not worth the overhead)
+- **≥10 insertions/deletions** → proceed with Haiku dispatch below
+
+**Dispatch:**
+
+```javascript
+Task({
+  subagent_type: "Explore",
+  model: "haiku",
+  description: "Pre-EXECUTE existence check",
+  prompt: `# EXISTENCE CHECK
+Read .claude/spec/active/{specName}/spec.md sections: "## Files" and "## Checklist".
+
+For EACH checklist task (task-level, NOT file-level):
+  1. Extract 1-3 concrete identifiers from the task text — function names, component names, file path fragments, string literals.
+     Example: task "Add LogoutButton component with handleLogout handler" → identifiers: ["LogoutButton", "handleLogout"].
+  2. Identify target files for the task from "## Files" (match by extension, name hint, or task context).
+  3. Grep each target file for the identifiers.
+  4. Verdict for this task:
+     - ALL target files contain a MAJORITY of identifiers → all_present=yes
+     - SOME do, SOME do not → all_present=partial
+     - NONE do → all_present=no
+
+Return a markdown table:
+| task | target_files | all_present | evidence |
+|------|--------------|-------------|----------|
+| <task text> | <comma-sep files> | yes/partial/no | <identifier:line or "none"> |
+
+Return ≤20 lines total. Self-cap: ≤10 tool uses (the tool-use budget is the true limit, not the task count).`
+})
+```
+
+**Decision after return (orchestrator inspects the returned table):**
+
+- **All tasks `all_present=no`** → Gate is transparent. Proceed to EXECUTE normally.
+- **Mixed** (any combination that is NOT all-no AND NOT all-yes — includes all-partial, yes+no, partial+no, yes+partial, yes+partial+no) → Edit the spec: mark `[x]` on tasks where `all_present=yes`. Leave `[ ]` on `partial` and `no` (both require re-dispatch). Re-dispatch EXECUTE only for tasks still `[ ]`. Keep the original scope (Light/Full). Do NOT invent a new "PARTIAL" state.
+- **All tasks `all_present=yes`** → **MANDATORY user surface** via `AskUserQuestion`: _"Pre-EXECUTE Existence Gate detected all N tasks already implemented. Evidence: {inline table}. Choose: (a) Close as already-implemented, (b) Force EXECUTE anyway (the gate may be wrong), (c) Abort pipeline."_ Never silently skip EXECUTE.
+
 ### EXECUTE Phase (Light scope — same session)
 
 When user chooses "Approve and implement now":
@@ -188,7 +246,9 @@ After each agent returns, check the return value for an escalation status before
 
 If two or more agents in the same wave return `CONCERN`, surface all concerns together before starting the next wave. See `.claude/pipeline-config.md` Escalation Statuses and Diagnostic Failure Routing for the full status table.
 
-9. **REVIEW** — dispatch review agent for each affected subproject (reads guards + relevant skills, runs 7-category checklist: SOLID, Design System, Patterns, i18n, Integration, Build, Elegance). REJECTED → fix + re-review (max 2 loops)
+9. **REVIEW** — dispatch review agent for each affected subproject (reads guards + relevant skills, runs 7-category checklist: SOLID, Design System, Patterns, i18n, Integration, Build, Elegance). REJECTED → fix + re-review (max 2 loops).
+
+   Re-reviews always dispatch with `model: "sonnet"` (see `review/SKILL.md § Model Selection`).
 10. All passed + APPROVED → CLOSE flow inline (sync registry, move spec, cleanup state)
 11. Failed → max 2 retries, then STOP + report
 

package/templates/commands/mustard/metrics/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: mustard:metrics
+description: Show enforcement metrics report — hook hit rates, budget distributions, gate activity. Metrics are recorded automatically; just run this to see them.
+---
+
+# /mustard:metrics - Show Metrics Report
+
+## Trigger
+`/mustard:metrics [--since <ISO date>] [--event <type>]`
+
+## What it does
+Runs `.claude/scripts/metrics-report.js` and shows the aggregated report.
+
+Metrics are recorded **automatically** by enforcement hooks on every Task dispatch — no activation needed. Just run this command whenever you want to see the current state.
+
+## Action
+1. Run `rtk node .claude/scripts/metrics-report.js $ARGS` (pass through any flags)
+2. Display output verbatim
+
+## Optional flags
+- `--since <ISO date>` — filter events after this date
+- `--event <type>` — filter to one event type (e.g. `budget-check`)
+
+## Examples
+- `/mustard:metrics` — full report since beginning
+- `/mustard:metrics --since 2026-04-09` — only recent events
+- `/mustard:metrics --event budget-check` — only budget-check events
+
+## Notes
+- Metrics live in `.claude/.metrics/*.jsonl` (gitignored, runtime state)
+- Logs auto-rotate at 10MB
+- To reset: delete files in `.claude/.metrics/` manually
+- Advanced: override mode via `CONTEXT_BUDGET_MODE` env var (`strict`|`warn`|`observe`). Default is `strict`.

package/templates/commands/mustard/resume/SKILL.md

@@ -69,8 +69,8 @@ Before the normal detect-and-confirm flow, scan the newest pipeline state for a
    ## Context
    - Branch: {from git}
    - Files changed: {run `node .claude/scripts/diff-context.js`}
-   - Last agent: {from `.claude/.agent-memory/_index.json` last entry}
-   - Last action: {summary from last agent memory entry}
+   - Last agent: {Read `.claude/.agent-memory/_index.json` and pick the last entry's `agent_type`. If the file or `.agent-memory/` directory is missing, print literal `(none)` — do NOT probe with `ls`/`grep`, it surfaces noisy exit codes}
+   - Last action: {from the same last entry's `summary` field. If missing, print literal `(no prior memory)`}
    - Decisions: {decisions[] from pipeline state, if any}
 
    ## Next Action
@@ -97,6 +97,10 @@ Run `node .claude/scripts/diff-context.js` to capture the current git state. Inc
 **CRITICAL: Main context IS the Pipeline Runner. NEVER delegate to intermediate Task agent.**
 
 12. **Match recipe by name only:** Grep `{subproject}/.claude/commands/recipes.md` for recipe title matching the task type — do NOT read the full recipes file. Extract only: recipe number, pattern refs, reference modules
+12b. **Pre-EXECUTE Existence Gate**: Same gate as `feature/SKILL.md § Pre-EXECUTE Existence Gate`. Invoke identically (Full scope only, `## Files` ≤ 8). On retry/resume, the gate naturally handles idempotence: tasks already `[x]` from a prior run are treated as Mixed — the Haiku confirms they stay done and the orchestrator only re-dispatches what remains `[ ]`.
+
+    **Pre-check (same as `feature/SKILL.md § Pre-EXECUTE Existence Gate`):** Before dispatching Haiku, run `rtk git diff --stat HEAD -- <files listed in spec's ## Files>`. Skip gate entirely if output is empty (no changes) or total insertions/deletions <10. Only proceed with Haiku dispatch if ≥10 lines changed.
+
 13. **Plan waves:** `Depends on: none` → Wave 1; dependencies → later. DB+Backend parallel. Frontend after Backend UNLESS all parallel override conditions met (see `.claude/pipeline-config.md` Parallel Rules). Review agents: ALWAYS dispatch in single parallel message. Skip completed tasks.
 14. **Build agent prompts using template** (`.claude/commands/mustard/templates/agent-prompt/SKILL.md`):
     - Read template once, then fill placeholders per agent using `.claude/pipeline-config.md` data:

package/templates/commands/mustard/review/SKILL.md

@@ -1,102 +1,113 @@
-# /review - Pull Request Review
-
-> Review a PR using Claude's native code-review skill. Auto-detects current branch PR or accepts PR number/URL.
-
-## Trigger
-
-`/review [pr-number-or-url]`
-
-## Configuration
-
-Reads `mustard.json` from the **project root** for `git.provider`.
-
-| Provider | CLI | PR detection |
-|----------|-----|--------------|
-| `github` | `gh` | `gh pr view --json number,url` |
-| `gitlab` | `glab` | `glab mr view` |
-
-## Behavior
-
-- **ZERO confirmations** — detect PR, invoke review, done.
-- **ZERO questions** — auto-detect if no argument provided.
-
----
-
-## Step 1 — Resolve PR
-
-### If argument provided
-
-- Numeric → treat as PR number
-- URL → use directly
-
-### If no argument
-
-```bash
-gh pr view --json number,url,title,headRefName 2>/dev/null
-```
-
-If no PR found for current branch → error:
-> No open PR found for current branch. Run `/git merge` first to create one.
-
----
-
-## Step 2 — Invoke Code Review
-
-Use the Skill tool to invoke Claude's native code-review:
-
-```
-Skill({
-  skill: "code-review",
-  args: "<pr-number-or-url>"
-})
-```
-
-If the native `code-review` skill is not available, fall back to local review:
-
-```
-Task({
-  subagent_type: "general-purpose",
-  model: "opus",
-  description: "Review: PR <number>",
-  prompt: "Review the changes in the current branch against $PARENT. Checklist: SOLID, Security, Performance, Patterns, Integration."
-})
-```
-
----
-
-## Step 3 — Report
-
-Present the review results as returned by the skill/agent.
-
----
-
-## Provider Support
-
-| Provider | Auto-detect | Manual URL |
-|----------|-------------|------------|
-| GitHub | `gh pr view` | yes |
-| GitLab | `glab mr view` | yes |
-| Bitbucket | no | yes |
-
----
-
-## Rules
-
-- NEVER ask for confirmation before invoking the review
-- NEVER attempt both Skill and Task — try Skill first, fall back only if unavailable
-- ALWAYS use the PR number or URL directly — do NOT pass branch names to the skill
-- If provider CLI is missing, instruct the user to install it; do NOT improvise
-
-## Examples
-
-```bash
-/review              # Auto-detect PR for current branch
-/review 42           # Review PR #42
-/review https://github.com/org/repo/pull/42
-```
-
-## Performance Budget
-
-- **Max Bash calls**: 1 (PR detection)
-- **Max Skill/Task calls**: 1
-- **Max API calls total**: ≤ 4
+# /review - Pull Request Review
+
+> Review a PR using Claude's native code-review skill. Auto-detects current branch PR or accepts PR number/URL.
+
+## Trigger
+
+`/review [pr-number-or-url]`
+
+## Configuration
+
+Reads `mustard.json` from the **project root** for `git.provider`.
+
+| Provider | CLI | PR detection |
+|----------|-----|--------------|
+| `github` | `gh` | `gh pr view --json number,url` |
+| `gitlab` | `glab` | `glab mr view` |
+
+## Behavior
+
+- **ZERO confirmations** — detect PR, invoke review, done.
+- **ZERO questions** — auto-detect if no argument provided.
+
+---
+
+## Step 1 — Resolve PR
+
+### If argument provided
+
+- Numeric → treat as PR number
+- URL → use directly
+
+### If no argument
+
+```bash
+gh pr view --json number,url,title,headRefName 2>/dev/null
+```
+
+If no PR found for current branch → error:
+> No open PR found for current branch. Run `/git merge` first to create one.
+
+---
+
+## Step 2 — Invoke Code Review
+
+Use the Skill tool to invoke Claude's native code-review:
+
+```
+Skill({
+  skill: "code-review",
+  args: "<pr-number-or-url>"
+})
+```
+
+If the native `code-review` skill is not available, fall back to local review:
+
+```
+Task({
+  subagent_type: "general-purpose",
+  model: "opus",
+  description: "Review: PR <number>",
+  prompt: "Review the changes in the current branch against $PARENT. Checklist: SOLID, Security, Performance, Patterns, Integration."
+})
+```
+
+---
+
+## Step 3 — Report
+
+Present the review results as returned by the skill/agent.
+
+---
+
+## Provider Support
+
+| Provider | Auto-detect | Manual URL |
+|----------|-------------|------------|
+| GitHub | `gh pr view` | yes |
+| GitLab | `glab mr view` | yes |
+| Bitbucket | no | yes |
+
+---
+
+## Model Selection
+
+**Initial reviews**: use default model per `pipeline-config.md § Models` (sonnet for most; opus for Full + new patterns; etc.).
+
+**Re-reviews**: always dispatch with `model: "sonnet"`, regardless of the initial review's model.
+
+**Rationale**:
+- Re-reviews verify a targeted fix to already-reviewed code. Sonnet is capable enough even in complex codebases (see `pipeline-config.md` where Sonnet is default for audit, bugfix, and ≤5-file features).
+- For Full + new-pattern features (initial review in Opus), this saves ~$5/re-review without introducing Haiku quality risk.
+- Simpler than heuristic decision table: one rule, zero edge cases.
+
+## Rules
+
+- NEVER ask for confirmation before invoking the review
+- NEVER attempt both Skill and Task — try Skill first, fall back only if unavailable
+- ALWAYS use the PR number or URL directly — do NOT pass branch names to the skill
+- If provider CLI is missing, instruct the user to install it; do NOT improvise
+
+## Examples
+
+```bash
+/review              # Auto-detect PR for current branch
+/review 42           # Review PR #42
+/review https://github.com/org/repo/pull/42
+```
+
+## Performance Budget
+
+- **Max Bash calls**: 1 (PR detection)
+- **Max Skill/Task calls**: 1
+- **Max API calls total**: ≤ 4