@rune-kit/rune 2.2.0 → 2.2.2

package/skills/plan/SKILL.md

@@ -171,6 +171,11 @@ Save to `.rune/plan-<feature>.md`:
 - <decision 1 — chosen approach and why>
 - <decision 2>
 
+## Decision Compliance
+- Decisions (locked): [list from requirements.md — plan MUST honor these]
+- Discretion (agent): [list — agent chose X because Y]
+- Deferred: [list — explicitly excluded from this feature]
+
 ## Architecture
 <brief system diagram or component list — NOT implementation detail>
 
@@ -226,17 +231,27 @@ function validateInput(raw: unknown): TradeEntry[];  // throws ValidationError
 ```
 
 ## Tasks
+
+Each task MUST include: **File** (exact path), **Test** (test file or N/A), **Verify** (shell command), **Commit** (semantic message). Granularity: 2-5 min per task. If >10min, decompose.
+
 - [ ] Task 1 — Create calculateProfit function
-  - File: `src/foo/bar.ts`
-  - Create: `function calculateProfit(entries: TradeEntry[]): ProfitResult`
+  - File: `src/foo/bar.ts` (new)
+  - Test: `tests/foo/bar.test.ts` (new)
+  - Verify: `npm test -- --grep "calculateProfit"`
+  - Commit: `feat(trading): add calculateProfit with fee calculation`
   - Logic: sum entries by side, apply fees (0.1% per trade), return net P&L
   - Edge: empty array → return { netPnL: 0, totalFees: 0, winRate: 0 }
 - [ ] Task 2 — Add input validation
-  - File: `src/foo/baz.ts`
-  - Modify: add `validateInput()` before processing
+  - File: `src/foo/baz.ts` (modify)
+  - Test: `tests/foo/baz.test.ts` (new)
+  - Verify: `npm test -- --grep "validateInput"`
+  - Commit: `feat(trading): add input validation for trade entries`
   - Logic: check side is 'long'|'short', prices > 0, quantity > 0
-- [ ] Task 3 — Write tests
-  - File: `tests/foo/bar.test.ts`
+- [ ] Task 3 — Write integration tests
+  - File: `tests/foo/bar.test.ts` (modify)
+  - Test: N/A — this IS the test task
+  - Verify: `npm test -- --grep "trading" && npx tsc --noEmit`
+  - Commit: `test(trading): add integration tests for edge cases`
   - Cases: happy path, empty input, negative values, overflow
 
 ## Failure Scenarios
@@ -503,6 +518,8 @@ Max 200 lines. Self-contained — coder needs ONLY this file.
 | Plan without scout context — invented file paths | CRITICAL | Step 1: scout first, always |
 | Phase with zero test tasks | CRITICAL | HARD-GATE rejects it |
 | 10+ phases overwhelming the master plan | MEDIUM | Max 8 phases — split into sub-projects if more |
+| Task without File path or Verify command | HIGH | Every task MUST have File + Test + Verify + Commit fields — no vague "implement the feature" tasks |
+| Plan ignores locked Decisions from BA | CRITICAL | Decision Compliance section cross-checks requirements.md — locked decisions are non-negotiable |
 
 ## Done When
 

package/skills/review/SKILL.md

@@ -3,7 +3,7 @@ name: review
 description: Code quality review — patterns, security, performance, correctness. Finds bugs, suggests improvements, triggers fix for issues found. Escalates to opus for security-critical code.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L2
   model: sonnet
   group: development
@@ -70,14 +70,17 @@ Determine what to review.
 - If context is unclear: use `rune:scout` to identify all files touched by the change
 - List every file in scope before proceeding — do not review files outside the stated scope
 
-### Step 2: Logic Check
+### Step 2: Logic Check (Production-Critical Focus)
 
-Read each changed file and check for correctness.
+Read each changed file. Prioritize bugs that **pass CI but break production** — these are the highest-value findings because linters and type checkers already catch the rest.
 
 - Use `Read` on every file in scope
+- **Race conditions**: async operations without proper sequencing, shared mutable state, missing locks
+- **State corruption**: mutations that affect other consumers, cache invalidation gaps, stale closures
+- **Silent failures**: caught errors that swallow context, empty catch blocks, promises without rejection handling
+- **Data loss paths**: write operations without confirmation, delete without soft-delete, truncation without backup
+- **Edge cases**: empty input, null/undefined, zero, negative numbers, empty arrays, Unicode, timezone boundaries
 - Check for: logic errors, off-by-one errors, incorrect conditionals, broken async/await patterns
-- Check for: missing error handling, uncaught promise rejections, silent failures
-- Check for: edge cases — empty input, null/undefined, zero, negative numbers, empty arrays
 - Flag each finding with file path, line number, and severity
 
 **Common patterns to flag:**
@@ -163,6 +166,39 @@ Identify gaps in test coverage.
 - If untested code found: call `rune:test` with specific instructions on what to test
 - Flag as HIGH if business logic is untested, MEDIUM if utility code is untested
 
+### Step 5.5: Two-Stage Review Gate
+
+Separate spec compliance from code quality. Most reviews conflate both — this gate forces the distinction.
+
+**Stage 1 — Spec Compliance (check FIRST)**
+
+Before evaluating code quality, verify the implementation matches what was asked:
+
+- Load the originating plan, task, ticket, or `requirements.md` if available
+- Does the implementation cover every acceptance criterion? Check each one explicitly
+- Is there **under-engineering** — requirements stated but not implemented?
+- Is there **over-engineering** — abstractions, generalization, or features beyond scope?
+- Does the file/function structure match what the plan specified?
+
+Flag spec deviations as HIGH — clean code that misses requirements ships broken products.
+
+```
+# Spec Compliance Checklist
+[ ] All acceptance criteria from plan/ticket covered
+[ ] No stated requirements missing from implementation
+[ ] No unrequested features added (scope creep)
+[ ] API surface matches what was specified (signatures, endpoints, return types)
+[ ] File structure matches plan (no renamed or relocated files without justification)
+```
+
+If spec violations found: document them separately from code quality findings in the report. Label as `SPEC-MISS` or `SPEC-CREEP`.
+
+**Stage 2 — Code Quality**
+
+Proceed to Step 6 only after Stage 1 passes. Code quality findings (bugs, patterns, security, coverage) are the existing Steps 2–5 above.
+
+The review report MUST show both stages: spec compliance verdict first, then code quality findings.
+
 ### Step 6: Report
 
 Produce a structured severity-ranked report.
@@ -340,7 +376,10 @@ LOW       — style inconsistency, naming suggestion, minor refactor opportunity
 | Expanding review scope beyond the diff | MEDIUM | Limit to `git diff` scope — do not creep into adjacent unchanged files |
 | Security finding without sentinel escalation | HIGH | Any auth/crypto/payment code touched → MUST call rune:sentinel |
 | Skipping UI anti-pattern checks for frontend changes | MEDIUM | Any .tsx/.jsx/.svelte/.vue in diff → MUST run UI/UX Anti-Pattern Checks section |
+| Skipping spec compliance check (Step 5.5 Stage 1) | HIGH | Code quality without spec check ships clean code that does the wrong thing — always load the plan/ticket before reviewing quality |
 | Treating purple/indigo accent as "just a color choice" | MEDIUM | It is a documented AI-generated UI signature — always flag for domain justification |
+| Suggesting "add X" without checking if X is used | MEDIUM | YAGNI pushback: grep codebase for the suggested feature → if uncalled anywhere → respond "Not called anywhere. Remove? (YAGNI)". Valid pushback, not laziness |
+| Adding abstractions "for future flexibility" | MEDIUM | Three similar lines > premature abstraction. Only abstract when there are 3+ concrete callers today |
 
 ## Done When
 

package/skills/review-intake/SKILL.md

@@ -3,7 +3,7 @@ name: review-intake
 description: Use when receiving code review feedback, PR comments, or external suggestions before implementing any changes. Prevents blind implementation, enforces verification-first discipline.
 metadata:
   author: runedev
-  version: "1.0.0"
+  version: "1.1.0"
   layer: L2
   model: sonnet
   group: quality
@@ -112,9 +112,25 @@ UNCLEAR:  "Need clarification on [specific aspect]."
 BANNED: "You're absolutely right!"
 BANNED: "Great point!" / "Great catch!"
 BANNED: "Thanks for catching that!"
+BANNED: "I agree with your suggestion"
+BANNED: "That's a good idea"
+BANNED: "I see what you mean"
+BANNED: Any sentence that adds no technical information
 BANNED: Any performative gratitude — actions speak, not words.
 ```
 
+<HARD-GATE>
+Every response to a review item MUST start with an ACTION VERB:
+- "Fixed — [description]"
+- "Reverted — [reason]"
+- "Deferred — [reason + ticket]"
+- "Pushed back — [technical evidence]"
+- "Clarifying — [question]"
+
+Responses starting with praise, agreement, or social pleasantries are BLOCKED.
+This is a professional code review, not a conversation — signal with actions, not words.
+</HARD-GATE>
+
 When replying to GitHub PR comments, reply in the thread:
 ```bash
 gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies \

package/skills/skill-forge/SKILL.md

@@ -3,7 +3,7 @@ name: skill-forge
 description: Use when creating new Rune skills, editing existing skills, or verifying skill quality before deployment. Applies TDD discipline to skill authoring — test before write, verify before ship.
 metadata:
   author: runedev
-  version: "1.0.0"
+  version: "1.1.0"
   layer: L2
   model: opus
   group: creation
@@ -106,6 +106,33 @@ Follow `docs/SKILL-TEMPLATE.md` format. Required sections:
 | Cost Profile | YES | Token estimate |
 | Mesh Gates | L1/L2 only | Progression guards |
 
+#### SKILL.md Anatomy — WHY vs HOW Split
+
+A skill file answers WHY and WHEN — not HOW. Code examples, syntax references, and implementation patterns belong in separate files:
+
+```
+skills/[name]/
+├── SKILL.md          ← WHY: purpose, triggers, constraints, sharp edges (~150-300 lines)
+├── references/       ← HOW: code patterns, syntax tables, API examples
+│   ├── patterns.md   ← Implementation patterns with code blocks
+│   └── gotchas.md    ← Language/framework-specific pitfalls
+└── scripts/          ← WHAT: deterministic operations (shell, node)
+```
+
+**Rules:**
+1. SKILL.md MUST NOT contain code blocks longer than 10 lines — move to `references/`
+2. One excellent inline example (≤10 lines) is OK for clarity — more than that is a smell
+3. Format templates (Output Format section) are NOT code — they stay in SKILL.md
+4. Pressure test scenarios (Phase 2) are NOT code — they stay in SKILL.md
+5. If a skill has >3 code blocks → create `references/` and extract them
+
+**Why this matters:** Code blocks in SKILL.md inflate context tokens on EVERY invocation. References are loaded only when needed. A 500-line SKILL.md with 200 lines of code examples should be a 300-line SKILL.md + a 200-line references file.
+
+<HARD-GATE>
+Code blocks in SKILL.md > 10 lines = review failure.
+Extract to references/ or scripts/. No exceptions.
+</HARD-GATE>
+
 #### Frontmatter Rules
 
 ```yaml
@@ -119,11 +146,16 @@ metadata:
 ---
 ```
 
-**Description rules:**
+**Description rules (CSO Discipline):**
 - MUST start with "Use when..."
 - MUST describe triggering conditions, NOT workflow
 - MUST be third person
 - MUST NOT summarize what the skill does internally
+- AI reads description → decides whether to invoke → if description contains workflow summary, AI skips reading the full SKILL.md content (it thinks it already knows)
+- Test: if you can execute the skill from the description alone, the description leaks too much
+
+Bad: "Analyzes code quality through 6-step process: scan files, check patterns, run linters, compare metrics, generate report, suggest fixes"
+Good: "Use when code changes need quality review before commit. Symptoms: PR ready, refactor complete, pre-release check."
 
 ```yaml
 # BAD: Summarizes workflow — agent reads description, skips full content
@@ -302,10 +334,13 @@ Techniques:
 | Skill passes test but breaks mesh connections | MEDIUM | Phase 6 integration: verify output compatibility |
 | Editing skill without testing the edit | MEDIUM | Adapting section: same TDD cycle for edits |
 | Overly verbose skill burns context tokens | MEDIUM | Token efficiency guidelines: layer-based word targets |
+| Code blocks in SKILL.md bloat every invocation | HIGH | WHY vs HOW split: SKILL.md ≤10-line code blocks, extract rest to references/ |
+| Writing skill without TDD (no observed failures first) | CRITICAL | Skill TDD: RED (run scenario WITHOUT skill → document failures) → GREEN (write skill targeting failures) → REFACTOR (find bypasses → add blocks) |
+| Description leaks workflow → agent skips full content | HIGH | CSO Discipline: description = triggers only. Test: can you execute from description alone? If yes, it leaks too much |
 
 ## Done When
 
-- Baseline test documented with observed failures
+- Baseline test documented with observed failures (TDD RED phase)
 - SKILL.md follows template format completely
 - Skill passes pressure test (agent complies with skill loaded)
 - No new failures in 2 consecutive varied-pressure test runs

package/skills/skill-router/SKILL.md

@@ -4,7 +4,7 @@ description: "Meta-enforcement layer that routes EVERY agent action through the
 user-invocable: false
 metadata:
   author: runedev
-  version: "1.1.0"
+  version: "1.2.0"
   layer: L0
   model: haiku
   group: orchestrator
@@ -64,14 +64,33 @@ Before standard routing, check if adaptive routing rules exist:
 - Model hints are written by cook Phase 8 when debug-fix loops hit max retries on the same error pattern
 - Model hints do NOT override explicit user model preferences
 
+### Step 0.25 — Request Classifier (Fast-Path Filter)
+
+Before intent classification, categorize the request into one of 5 types. This determines the **enforcement level** — how strictly routing must be followed.
+
+| Request Type | Keywords / Signals | Enforcement | Action |
+|---|---|---|---|
+| `CODE_CHANGE` | "build", "implement", "add", "create", "fix", "refactor", "update code" | **FULL** | cook mandatory, no exceptions |
+| `QUESTION` | "what is", "how does", "explain", "why" | **LITE** | Check if a skill has domain knowledge first; answer directly if no skill matches |
+| `DEBUG_REQUEST` | "error", "bug", "not working", "broken", "crash", "fails" | **FULL** | debug skill mandatory |
+| `REVIEW_REQUEST` | "review", "check", "audit", "look at this code" | **FULL** | review skill mandatory |
+| `EXPLORE` | "find", "search", "where is", "show me", "list" | **LITE** | scout if codebase-related; answer directly if general |
+
+**Enforcement levels:**
+- **FULL** → MUST route through a skill. Writing code without skill invocation = protocol violation.
+- **LITE** → SHOULD check if a skill applies. Can answer directly if no skill matches and the response involves no code changes.
+
+**Escape hatch**: If request is clearly trivial (< 5 LOC change, single-line fix, user says "just do it"), classify as CODE_CHANGE but cook activates Fast Mode automatically.
+
 ### Step 0.5 — STOP before responding
 
 Before generating ANY response (including clarifying questions), the agent MUST:
 
-1. **Classify the user's intent** using the routing table below
-2. **Identify which skill(s) match** — if even 1% chance a skill applies, invoke it
-3. **Invoke the skill** via the Skill tool
-4. **Follow the skill's instructions** — the skill dictates the workflow, not the agent
+1. **Check the request type** from Step 0.25 — if FULL enforcement, routing is mandatory
+2. **Classify the user's intent** using the routing table below
+3. **Identify which skill(s) match** — if even 1% chance a skill applies, invoke it
+4. **Invoke the skill** via the Skill tool
+5. **Follow the skill's instructions** — the skill dictates the workflow, not the agent
 
 ### Step 1 — Intent Classification (Progressive Disclosure)
 
@@ -143,7 +162,11 @@ These are rarely invoked directly — they're called by Tier 1/2 skills:
 
 #### Tier 4 — Domain Extension Packs (L4)
 
-When user intent matches a domain-specific pattern or user explicitly invokes an L4 trigger command, route to the L4 pack. The agent reads the pack's PACK.md and follows the matching skill's workflow.
+When user intent matches a domain-specific pattern or user explicitly invokes an L4 trigger command, route to the L4 pack.
+
+**Split pack loading** (context-efficient): First `Read` the pack's PACK.md index. If the index contains `format: split` in its frontmatter metadata, it is a split pack — the index lists skills in a table but skill content lives in separate files under `skills/`. Match user intent to the specific skill name in the table, then `Read` only that skill file (e.g., `extensions/backend/skills/api-design.md`). This loads ~100-200 lines instead of ~1000+.
+
+**Monolith pack loading** (legacy): If no `format: split` marker, the PACK.md contains all skills inline — read it fully and extract the matching `### skill-name` section.
 
 | User Intent / Domain Signal | Route To | Pack File |
 |---|---|---|
@@ -159,13 +182,41 @@ When user intent matches a domain-specific pattern or user explicitly invokes an
 | Three.js, WebGL, game loop, physics | `@rune/gamedev` | `extensions/gamedev/PACK.md` |
 | Blog, CMS, MDX, i18n, SEO | `@rune/content` | `extensions/content/PACK.md` |
 | Analytics, A/B testing, funnels, dashboards | `@rune/analytics` | `extensions/analytics/PACK.md` |
+| Chrome extension, manifest, service worker | `@rune/chrome-ext` | `extensions/chrome-ext/PACK.md` |
+| PRD, roadmap, KPI, release notes, product spec | `@rune-pro/product` | `extensions/pro-product/PACK.md` |
+| Sales outreach, pipeline, call prep, prospecting | `@rune-pro/sales` | `extensions/pro-sales/PACK.md` |
+| Data science, SQL, dashboards, statistical analysis | `@rune-pro/data-science` | `extensions/pro-data-science/PACK.md` |
+| Support tickets, KB, escalation, SLA tracking | `@rune-pro/support` | `extensions/pro-support/PACK.md` |
+| Budget, expense, revenue forecast, P&L, cash flow | `@rune-pro/finance` | `extensions/pro-finance/PACK.md` |
+| Contract review, NDA, compliance, GDPR, IP audit | `@rune-pro/legal` | `extensions/pro-legal/PACK.md` |
 
 **L4 routing rules:**
-1. If user explicitly invokes an L4 trigger (e.g., `/rune rag-patterns`), read the PACK.md and follow the skill workflow directly
+1. If user explicitly invokes an L4 trigger (e.g., `/rune rag-patterns`), read the PACK.md index first, then load only the matching skill file (split packs) or extract the matching section (monolith packs)
 2. If the intent also involves implementation, route to `cook` (L1) first — cook will detect L4 context in Phase 1.5
 3. L4 packs supplement L1/L2 workflows — they are domain knowledge, not standalone orchestrators
 4. L4 packs can call L3 utilities (scout, verification) but CANNOT call L1 or L2 skills
 5. If the L4 pack file is not found on disk, skip silently and proceed with standard routing
+6. **NEVER load an entire split pack** — always load index first, then only the specific skill file needed
+
+### Step 1.5 — File Ownership Matrix (Constraint Inheritance)
+
+When the routed skill produces file changes, the **owner skill's constraints** apply to those files — even if a different skill (e.g., cook) is the orchestrator.
+
+| File Pattern | Owner Skill | Constraints Applied |
+|---|---|---|
+| `*.test.*`, `*.spec.*`, `__tests__/` | `rune:test` | Test patterns, assertions, no `test.skip`, coverage rules |
+| `migrations/`, `schema.*`, `*.prisma` | `rune:db` | Migration safety, rollback script, parameterized queries |
+| `Dockerfile`, `*.yml` (CI/CD), `terraform/` | `rune:deploy` | Deployment checklist, no hardcoded secrets |
+| `docs/*.md`, `README.md`, `CHANGELOG.md` | `rune:docs` | Documentation patterns, no stale references |
+| `SKILL.md`, `PACK.md` | `rune:skill-forge` | Skill template compliance, frontmatter validation |
+| `.env*`, `*secret*`, `*credential*` | `rune:sentinel` | Security scan mandatory, never commit secrets |
+| `*.css`, `*.scss`, `tailwind.config.*` | `@rune/ui` | Design system patterns (if L4 pack installed) |
+
+**Ownership rules:**
+1. Ownership = **constraints apply**, NOT exclusive access. cook can modify test files during Phase 4 as long as test constraints are honored.
+2. If a file matches multiple patterns, ALL matching constraints apply (union, not exclusive).
+3. If no pattern matches, the routed skill's own constraints apply (default behavior).
+4. File ownership is checked DURING implementation, not at routing time — it augments, not replaces, skill routing.
 
 ### Step 2 — Compound Intent Resolution
 
@@ -235,9 +286,22 @@ These DO NOT need skill routing:
 
 ## Output Format
 
+### Routing Proof (Required in Every Code Response)
+
+Every response that involves code changes MUST begin with a routing proof line:
+
+```
+> Routed: rune:<skill> | Type: CODE_CHANGE | Confidence: HIGH
+```
+
+This is NOT optional formatting. It is evidence that routing occurred. If this line is missing from a code response, the response violated skill-router compliance. For LITE enforcement (QUESTION, EXPLORE), the proof line is optional.
+
+### Full Routing Decision (when announcing route)
+
 ```
 ## Routing Decision
 - **Intent**: [classified user intent]
+- **Type**: CODE_CHANGE | QUESTION | DEBUG_REQUEST | REVIEW_REQUEST | EXPLORE
 - **Skill**: rune:[skill-name]
 - **Confidence**: HIGH | MEDIUM | LOW
 - **Override**: [routing override applied, if any]
@@ -278,6 +342,24 @@ For multi-skill chains:
 - Success = every agent response passes through routing check
 - Failure = any code written without skill invocation
 
+## Self-Verification Trigger (MANDATORY)
+
+<HARD-GATE>
+Before EVERY response, complete this 3-point self-check:
+
+1. **Did I classify this request?** (Step 0.25 — what type is it?)
+2. **Did I route through a skill?** (Step 1-2 — which skill handles this?)
+3. **Am I about to write code without a skill invocation?** → **STOP. Route first.**
+
+If the request type is `CODE_CHANGE` or `DEBUG_REQUEST` (FULL enforcement) and ANY answer is "no":
+→ DO NOT RESPOND. Complete routing first.
+
+If the request type is `QUESTION` or `EXPLORE` (LITE enforcement):
+→ Check if a skill has relevant domain knowledge. If yes, route. If no, respond directly.
+
+**User override**: If user explicitly says "skip routing", "just write it", "no process" → respect the override. Log: "User override: routing skipped per explicit request."
+</HARD-GATE>
+
 ## Cost Profile
 
 ~0 tokens (routing logic is internalized from this document). Cost comes from the skills it routes to, not from skill-router itself. The routing table is loaded once and cached in context.

package/skills/team/SKILL.md

@@ -5,7 +5,7 @@ context: fork
 agent: general-purpose
 metadata:
   author: runedev
-  version: "0.3.0"
+  version: "0.4.0"
   layer: L1
   model: opus
   group: orchestrator
@@ -250,6 +250,29 @@ Error recovery:
     → Present to user for decision before continuing
 ```
 
+**3c. Evaluate subagent status per stream.**
+
+Each cook instance MUST have returned one of four statuses. Team handles them as follows:
+
+| Cook Status | Team Action |
+|-------------|-------------|
+| `DONE` | Stream cleared for merge — proceed normally |
+| `DONE_WITH_CONCERNS` | Stream cleared for merge, BUT trigger **cross-workstream review**: check if the concern impacts any other stream's files or contracts before merging ALL streams. Log concern in Team Report. |
+| `NEEDS_CONTEXT` | Stream paused — present the specific question to user. Resume that stream after answer. Other independent streams may continue in parallel. |
+| `BLOCKED` | Stream blocked from merge. If stream has no dependents → continue with remaining streams and report partial completion. If stream has dependents → STOP all dependent streams, present to user with full blocker details. |
+
+**Cross-workstream review (triggered by any DONE_WITH_CONCERNS)**:
+
+```
+1. Read the concern from the cook report
+2. Check if the concern touches shared contracts, interfaces, or shared files
+   → Use Grep to find the concern's affected symbols/files across all worktrees
+3. If concern is isolated to stream's own files → proceed to merge (concern logged only)
+4. If concern crosses stream boundaries → resolve before merge:
+   → Present to user with: affected streams, concern details, two remediation options
+   → Do NOT merge any stream until user decides
+```
+
 Mark todo[2] `completed`.
 
 ---

package/skills/test/SKILL.md

@@ -3,7 +3,7 @@ name: test
 description: "TDD test writer. Writes failing tests FIRST (red), then verifies they pass after implementation (green). Covers unit, integration, and e2e tests."
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L2
   model: sonnet
   group: development
@@ -23,6 +23,13 @@ THE IRON LAW: Write code before test? DELETE IT. Start over.
 - Do NOT look at it to "inform" test design
 - Delete means delete. `git checkout -- <file>` or remove the changes entirely.
 This is not negotiable. This is not optional. "But I already wrote it" is a sunk cost fallacy.
+
+ROLE BOUNDARY: Test writes TEST FILES only. NEVER modify source/implementation files.
+- Do NOT "quickly fix" a broken import in source to make tests run
+- Do NOT refactor source code to be "more testable"
+- Do NOT add missing exports to source files
+- If source needs changes → hand off to `rune:fix`. Test's job ends at the test file.
+This separation ensures test never writes code biased toward passing its own tests.
 </HARD-GATE>
 
 ## Instructions
@@ -144,6 +151,23 @@ After GREEN phase, call `verification` to check coverage threshold (80% minimum)
 - If coverage drops below 80%: identify uncovered lines, write additional tests
 - Report coverage gaps with file:line references
 
+### Phase 6.5: Diff-Aware Mode (optional)
+
+When invoked with `mode: "diff-aware"` or by `cook` after implementation:
+
+1. Run `git diff main --name-only` to get changed files
+2. For each changed file, trace its **blast radius**: what imports it? what routes does it serve? what components render it?
+3. Map changed files → affected routes/endpoints/pages
+4. Prioritize tests: files with most downstream dependents get tested first
+5. Generate targeted test commands that cover ONLY affected paths — skip unchanged modules
+
+This mode is valuable for large codebases where running the full suite is slow. It answers: "what could this diff have broken?"
+
+```
+Input:  git diff main --name-only
+Output: Prioritized test plan targeting only affected paths
+```
+
 ## Test Types
 
 | Type | When | Framework | Speed |
@@ -152,6 +176,7 @@ After GREEN phase, call `verification` to check coverage threshold (80% minimum)
 | Integration | API endpoints, DB operations | supertest/httpx/reqwest | Medium |
 | E2E | Critical user flows | Playwright/Cypress via browser-pilot | Slow |
 | Regression | After bug fixes | Same as unit | Fast |
+| Diff-aware | After implementation, large codebases | Same as unit + integration | Fast (targeted) |
 
 ## Error Recovery
 
@@ -214,6 +239,7 @@ If you catch yourself with ANY of these, delete implementation code and restart
 7. MUST NOT say "tests pass" without showing actual test runner output
 8. MUST delete implementation code written before tests — Iron Law, no exceptions
 9. MUST show RED phase output (actual failure) — "I confirmed they fail" without output is REJECTED
+10. MUST NOT modify source/implementation files — test writes test files ONLY, hand off source changes to rune:fix
 
 ## Mesh Gates
 
@@ -256,6 +282,7 @@ Known failure modes for this skill. Check these before declaring done.
 | Testing mock behavior instead of real code | HIGH | Constraint 4: test what the real code does, not what the mock returns |
 | Coverage below 80% without filling gaps | MEDIUM | Coverage Gate: identify uncovered lines and write additional tests |
 | Introducing a new test framework instead of using existing one | MEDIUM | Constraint 6: detect framework first, use project's existing one always |
+| Modifying source files to make tests work | HIGH | Role boundary: test writes test files ONLY — source changes go to rune:fix |
 
 ## Done When
 

package/skills/verification/SKILL.md

@@ -3,7 +3,7 @@ name: verification
 description: "Universal verification runner. Runs lint, type-check, tests, and build. Use after any code change to verify nothing is broken."
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.4.0"
   layer: L3
   model: haiku
   group: validation
@@ -98,6 +98,91 @@ If build fails: record first 20 lines of build output, mark as FAIL.
 
 Compile all results into the structured report. Update all TodoWrite items to completed.
 
+### 3-Level Artifact Verification
+
+> From GSD (gsd-build/get-shit-done, 30.8k★): "Task done ≠ Goal achieved."
+
+Every file created or modified during implementation must pass ALL 3 levels:
+
+**Level 1 — EXISTS**: File is on disk, non-empty.
+```
+Glob("path/to/expected/file") → found
+```
+
+**Level 2 — SUBSTANTIVE**: Contains real logic, NOT a stub. Scan for these stub patterns:
+
+| Pattern | Language | Meaning |
+|---|---|---|
+| Component returns only `<div>Placeholder</div>` or `<div>TODO</div>` | React/Vue | Stub component |
+| Route returns `{ message: "Not implemented" }` or `res.status(501)` | API | Stub endpoint |
+| Function body is only `return null` / `return {}` / `return []` / `pass` | Any | Stub function |
+| Class with all methods throwing `NotImplementedError` | Python/Java | Stub class |
+| `useEffect` with empty body / `async function` with no `await` | React/JS | Hollow implementation |
+| File has only type/interface exports but no implementation | TypeScript | Stub types-only file |
+| `// TODO` or `# TODO` as the only content in a function | Any | Placeholder |
+
+If ANY stub pattern detected → mark file as STUB, Level 2 FAIL.
+
+**Level 3 — WIRED**: Actually imported/called/used by the rest of the system.
+
+| File Type | Wiring Check |
+|---|---|
+| Component | `Grep("<ComponentName")` in parent files → ≥1 consumer |
+| API route | `Grep("fetch\\|axios\\|api.*endpoint")` for this path → ≥1 caller |
+| Hook | `Grep("useHookName(")` → ≥1 consumer |
+| Utility function | `Grep("import.*from.*this-file")` → ≥1 importer |
+| DB model/schema | `Grep("ModelName\\|table_name")` in query files → ≥1 reference |
+| CSS/style module | `Grep("import.*from.*this-style")` → ≥1 importer |
+
+If file has 0 consumers → mark as UNWIRED, Level 3 FAIL.
+
+**Exception**: Entry-point files (main.ts, index.ts, App.tsx, routes config) are exempt from Level 3 — they ARE the top-level consumers.
+
+<HARD-GATE name="3-level-verification">
+ALL new files must pass Level 1 + Level 2 + Level 3.
+EXISTS but STUB = "Existence Theater" — agent created files but didn't implement them.
+EXISTS and SUBSTANTIVE but UNWIRED = dead code — created but never connected.
+Report which level failed for each file in the Verification Report.
+</HARD-GATE>
+
+### Artifact Output Verification
+
+> Inspired by CLI-Anything (HKUDS/CLI-Anything, 14.5k★): "Never trust exit 0."
+> Many tools exit 0 even when they fail silently. Always verify ACTUAL output.
+
+After each phase command, verify that the expected artifact or indicator is present:
+
+**Test output** — scan stdout for the pass/fail summary line:
+- Vitest/Jest: look for `X passed`, `X failed` — if neither appears, output is incomplete
+- Pytest: look for `X passed` or `X failed` — exit 0 with no summary = runner crashed silently
+- If only exit code available and no summary line found → mark as INCOMPLETE, not PASS
+
+**Build output** — after `npm run build` / `cargo build` / `go build`:
+- Verify the output file exists: `Glob("dist/**/*.js")` or equivalent
+- Verify file size > 0 bytes: a zero-byte output = silent truncation failure
+- If output directory is missing → FAIL even if command exited 0
+
+**Lint output** — parse stdout for counts, not just exit code:
+- ESLint: look for `X problems (Y errors, Z warnings)` — `0 problems` = PASS
+- Ruff/Flake8: zero output lines = PASS; any file:line output = FAIL
+- If linter exits 0 but output contains `error` keyword → log as suspicious, mark WARN
+
+**Generated files** — check magic bytes for binary outputs:
+- PDF: first bytes must be `%PDF` — use `Bash("head -c 4 file.pdf")`
+- ZIP/XLSX/DOCX: first bytes must be `PK` (ZIP magic) — use `Bash("head -c 2 file.zip")`
+- File size must exceed minimum threshold (PDF > 1KB, ZIP > 100 bytes)
+
+**Type check** — do not trust exit code alone:
+- TypeScript `tsc --noEmit`: look for `Found X errors` or absence of error lines
+- `Found 0 errors` = PASS; any other count = FAIL
+- Empty output from `tsc` = PASS (no errors emitted) — note explicitly
+
+<HARD-GATE name="artifact-verification">
+Verification MUST check actual command output for success indicators, not just exit codes.
+Exit 0 without a confirming output artifact or success string = UNVERIFIED.
+Report the specific line that confirmed success (e.g., "3 passed, 0 failed").
+</HARD-GATE>
+
 ## Error Recovery
 
 - If project type cannot be detected: report "Unknown project type" and skip all checks
@@ -130,6 +215,13 @@ Types:     [PASS/FAIL/SKIP] ([X errors])
 Tests:     [PASS/FAIL/SKIP] ([passed]/[total], [coverage]%)
 Build:     [PASS/FAIL/SKIP]
 
+### 3-Level File Verification
+| File | L1 Exists | L2 Substantive | L3 Wired | Verdict |
+|------|-----------|----------------|----------|---------|
+| src/auth/login.ts | ✓ | ✓ | ✓ (imported by routes.ts) | PASS |
+| src/auth/reset.ts | ✓ | STUB (returns null) | — | FAIL L2 |
+| src/utils/format.ts | ✓ | ✓ | UNWIRED (0 importers) | FAIL L3 |
+
 Overall:   [PASS/FAIL]
 
 ### Failures (if any)
@@ -137,6 +229,8 @@ Overall:   [PASS/FAIL]
 - Types: [first 5 type errors]
 - Tests: [first 5 failing test names]
 - Build: [first 5 build errors]
+- Stubs: [files that failed Level 2 with stub pattern detected]
+- Unwired: [files that failed Level 3 with 0 consumers]
 ```
 
 ## Evidence-Before-Claims Gate
@@ -187,6 +281,9 @@ Known failure modes for this skill. Check these before declaring done.
 | Marking check as PASS when the tool isn't installed | MEDIUM | Mark as SKIP (not PASS) — PASS means the tool ran and reported clean |
 | Stopping after first failure instead of running remaining checks | MEDIUM | Run all checks; aggregate all failures so developer can fix everything at once |
 | Reporting PASS when output has warnings but zero errors | LOW | PASS is correct but note warning count — caller decides if warnings matter |
+| Trusting exit code 0 without output verification | CRITICAL | Artifact Verification HARD-GATE: always confirm success indicator in stdout (pass count, "0 errors", output file exists) |
+| Existence Theater — file exists but is a stub | HIGH | 3-Level check: Level 2 scans for stub patterns (`<div>Placeholder</div>`, `return null`, `NotImplementedError`) |
+| Dead code — file created but never imported/used | MEDIUM | 3-Level check: Level 3 greps for consumers. 0 importers = UNWIRED |
 
 ## Done When