chore(workspace): bring the committed scaffold up to template version 31

.claude/agents/code-review.md → .claude/agents/scc-code-review.md

@@ -1,5 +1,5 @@
 ---
-name: code-review
+name: scc-code-review
 description: Reviews a diff for correctness and quality against the task list, re-runs the feature's tests and lint, and reports. Use it after the last task of a spec or plan is verified and before opening the PR — never on your own work as the author.
 tools: Read, Grep, Glob, Bash
 model: sonnet

.claude/agents/security-review.md → .claude/agents/scc-security-review.md

@@ -1,6 +1,6 @@
 ---
-name: security-review
-description: Reviews a diff for exploitable weaknesses, attack-class agnostic — traces attacker-controlled input to effect and reports reachable paths. Use it alongside code-review before opening a PR — the two are deliberately separate lenses.
+name: scc-security-review
+description: Reviews a diff for exploitable weaknesses, attack-class agnostic — traces attacker-controlled input to effect and reports reachable paths. Use it alongside scc-code-review before opening a PR — the two are deliberately separate lenses.
 tools: Read, Grep, Glob, Bash
 model: sonnet
 effort: high
@@ -9,7 +9,7 @@ effort: high
 You review a diff for security defects and nothing else. You do not write code and you
 do not fix what you find — you report it, and the orchestrator decides.
 
-Separate from `code-review` on purpose: **one reviewer asked for "everything"
+Separate from `scc-code-review` on purpose: **one reviewer asked for "everything"
 reliably under-weights security**, because correctness findings are easier to produce
 and crowd it out. The narrow scope is the point — no style, naming, or design taste,
 and do not re-report what a correctness reviewer obviously catches.

.claude/rules/delivery.md

@@ -24,7 +24,7 @@ Once the last task is done:
 1. **`scc validate --checks --pr`** on the integrated branch — artifacts, record and the
    four gates together, build first and stopping at the first failure; `2` is not done.
    Per-task runs cannot see breakage between tasks, and this is what `pre-push` runs.
-2. **`code-review` and `security-review`** subagents on the diff, dispatched together.
+2. **`scc-code-review` and `scc-security-review`** subagents on the diff, dispatched together.
    **Both, every time, on every PR** — not "when the change looks risky", which is the
    judgment call that ends with neither being run. Each returns a verdict, what it
    checked, and findings by severity; you fix from that report and do not re-review.

.claude/rules/knowledge-base.md

@@ -1,3 +1,8 @@
+---
+paths:
+  - "docs/**"
+---
+
 # The knowledge base — `docs/`
 
 A spec answers *what this feature does now*. `docs/` answers *why* — the durable

.claude/rules/specs.md

@@ -1,3 +1,8 @@
+---
+paths:
+  - "specs/**"
+---
+
 # Specs — the three artifacts
 
 `specs/<feature>/` holds exactly three files. `scc spec new <feature>` creates them;

.claude/rules/tasks.md

@@ -1,3 +1,9 @@
+---
+paths:
+  - "specs/**"
+  - "plans/**"
+---
+
 # Task grammar
 
 One grammar governs every task line, in a spec's `tasks.md` or a plan's checklist.