@rune-kit/rune 2.2.3 → 2.2.6

package/skills/debug/SKILL.md

@@ -3,7 +3,7 @@ name: debug
 description: Root cause analysis for bugs and unexpected behavior. Traces errors through code, uses structured reasoning, and hands off to fix when cause is found. Core of the debug↔fix mesh.
 metadata:
   author: runedev
-  version: "0.5.0"
+  version: "0.7.0"
   layer: L2
   model: sonnet
   group: development
@@ -67,6 +67,24 @@ Understand and confirm the error described in the request.
 - Confirm the error is consistent and reproducible before proceeding
 - If no reproduction steps provided, ask for them or attempt the most likely path
 
+### Step 1.5: Scope Lock (Edit Boundary)
+
+After reproducing the error, **lock edits to the narrowest affected directory** to prevent debug-driven scope creep — the #1 source of "while I'm here, let me also fix..." violations.
+
+1. Identify the narrowest directory containing the affected files (from stack trace or error location)
+2. Announce to user: "Debug scope locked to `<dir>/`. Changes will be restricted to this area."
+3. Any fix recommendation in the Debug Report MUST reference only files within this boundary
+4. If root cause traces outside the boundary → expand scope with user confirmation first
+
+**Skip conditions** (do NOT lock):
+- Bug spans the entire repo (3+ unrelated directories in stack trace)
+- Cannot determine affected area from initial evidence
+- User explicitly says "investigate everything"
+
+**Why:** Debugging naturally expands scope as you trace root causes. Without a boundary, rune:fix receives recommendations touching 10+ files across unrelated modules. The scope lock forces discipline: fix at the source, not at every symptom site.
+
+> Source: garrytan/gstack v0.9.0 (investigate skill) — auto-freeze to affected module during debug sessions.
+
 ### Step 2: Gather Evidence
 
 Use tools to collect facts — do NOT guess yet.
@@ -231,6 +249,30 @@ After Step 4 (Test Hypotheses): if NO hypothesis is confirmed after 3 cycles of
 Within any single step: 5+ consecutive Read/Grep calls without forming or testing a hypothesis = stuck. Stop reading, form a hypothesis from what you have, and test it. Incomplete hypotheses that get tested are better than perfect hypotheses that never form.
 </HARD-GATE>
 
+### Hash-Based Evidence Loop Detection
+
+Beyond counting reads, detect when debug is **re-gathering the same evidence without progress** — the most common debug-specific stuck pattern.
+
+**Detection signals** (track mentally across hypothesis cycles):
+
+| Signal | Count | Meaning | Action |
+|--------|-------|---------|--------|
+| Reading the same file:line range in different cycles | 2x | Re-examining without new lens | Form hypothesis from existing evidence NOW |
+| Running the same test command with same failure output | 3x | No code changed between runs | STOP — hand off to fix with current diagnosis, even if incomplete |
+| Grepping the same error string after already finding all occurrences | 2x | Hoping for different results | Evidence is complete — move to Step 3 (hypothesize) |
+| Same hypothesis tested with same evidence across cycles | 2x | Circular reasoning | Mark hypothesis INCONCLUSIVE, try a DIFFERENT hypothesis category |
+
+**Hypothesis category diversity rule**: If H1 (cycle 1) was "wrong input data" and it was RULED OUT, H1 (cycle 2) MUST be from a DIFFERENT category:
+
+| Category | Examples |
+|----------|---------|
+| Data | Wrong value, missing field, type mismatch, encoding |
+| Control Flow | Wrong branch, missing guard, race condition, async ordering |
+| Environment | Wrong config, missing env var, version mismatch, path issue |
+| State | Stale cache, mutation side-effect, leaked reference, dangling connection |
+
+> Source: goclaw (832★) — content-aware loop detection adapted for debug hypothesis cycles.
+
 ## Red Flags — STOP and Return to Step 2
 
 If you catch yourself thinking any of these, you are GUESSING, not debugging:
@@ -301,6 +343,11 @@ ALL of these mean: STOP. Return to Step 2 (Gather Evidence).
 | Escalating to plan when the APPROACH is wrong (not the module) | HIGH | If all 3 fixes hit the same category of blocker (API limit, platform gap), the approach needs pivoting via brainstorm(rescue), not re-planning |
 | Not tracking fix attempt number for recurring bugs | HIGH | Debug Report MUST include Fix Attempt counter — enables escalation gate |
 | Adding instrumentation without region markers | MEDIUM | All debug logging MUST use `#region agent-debug` — unmarked code gets cleaned up prematurely by fix |
+| Re-reading same file:line in different hypothesis cycles | HIGH | Hash-based evidence loop: if same evidence gathered 2x, form hypothesis from existing data — don't re-gather |
+| Same hypothesis category across cycles after RULED OUT | HIGH | Hypothesis category diversity: if "data" ruled out in cycle 1, cycle 2 must try "control flow", "environment", or "state" |
+| Running same test 3x with same failure without code change | MEDIUM | True stuck loop — no progress possible. Hand off to fix with current incomplete diagnosis |
+| Scope creep via debug — "while investigating, also fix X" | HIGH | Step 1.5 Scope Lock: lock edits to narrowest affected directory. Fix recommendations MUST stay within boundary. Expand only with user confirmation |
+| Debug report recommends touching 5+ unrelated files | HIGH | Symptom of fixing at crash sites instead of source. Backward trace (Step 2) to find origin. If truly 5+ files → likely architectural issue → escalate via 3-Fix Rule |
 
 ## Done When
 

package/skills/deploy/SKILL.md

@@ -4,7 +4,7 @@ description: "Deploy application to target platform. Use when user explicitly sa
 disable-model-invocation: true
 metadata:
   author: runedev
-  version: "0.3.0"
+  version: "0.4.0"
   layer: L2
   model: sonnet
   group: delivery
@@ -64,6 +64,49 @@ If sentinel returns CRITICAL issues → STOP. Do NOT proceed. Report issues.
 
 Both gates MUST pass. No exceptions.
 
+### Step 1.5 — Release Checklist (Production Deploys Only)
+
+**Skip for**: staging, preview, development deploys.
+
+Before production deploy, verify ALL items:
+
+| # | Check | How | Gate |
+|---|-------|-----|------|
+| 1 | Version bumped | `package.json`/`pyproject.toml` version matches release | BLOCK if unchanged |
+| 2 | Changelog updated | `CHANGELOG.md` has entry for this version | WARN if missing |
+| 3 | Breaking changes documented | RFC artifact exists for each breaking change | BLOCK if RFC missing |
+| 4 | Migration scripts ready | DB migrations tested on staging first | BLOCK if untested migration |
+| 5 | Rollback plan documented | `.rune/deploy/rollback-<version>.md` exists | WARN if missing |
+| 6 | Release notes drafted | Customer-facing notes for release-comms | WARN if missing |
+| 7 | Dependencies locked | Lock file committed, no floating versions | BLOCK if unlocked |
+
+**Rollback Plan Template** (`.rune/deploy/rollback-<version>.md`):
+
+```markdown
+# Rollback Plan: v<version>
+
+## Trigger Conditions
+- [When to rollback — e.g., error rate >5%, P0 incident, data corruption]
+
+## Steps
+1. [Revert command — e.g., `vercel rollback`, `fly releases rollback`]
+2. [DB rollback — e.g., `npm run migrate:rollback` or "N/A — no migration"]
+3. [Cache invalidation if needed]
+4. [Notify stakeholders]
+
+## Verification
+- [ ] Previous version serving traffic
+- [ ] Health check passing
+- [ ] No data loss confirmed
+
+## Post-Rollback
+- [ ] Incident created for root cause analysis
+- [ ] Fix branch created from rolled-back commit
+```
+
+If any BLOCK item fails → STOP deploy. Fix before retrying.
+If WARN items missing → proceed but flag in deploy report.
+
 ### Step 2 — Detect platform
 
 Use `Bash` to inspect the project root for platform config files:
@@ -147,6 +190,8 @@ Deploy Report with platform, status (success/failed/rollback), deployed URL, bui
 3. MUST verify deploy is live and responding before declaring success
 4. MUST NOT deploy with known CRITICAL security findings
 5. MUST log deploy metadata (version, timestamp, commit hash)
+6. MUST complete release checklist for production deploys — version bump, changelog, rollback plan
+7. MUST create rollback plan artifact before first production deploy of a version
 
 ## Sharp Edges
 

package/skills/fix/SKILL.md

@@ -3,7 +3,7 @@ name: fix
 description: Apply code changes and fixes. Writes implementation code, applies bug fixes, and verifies changes with tests. Core action hub in the development mesh.
 metadata:
   author: runedev
-  version: "0.4.0"
+  version: "0.5.0"
   layer: L2
   model: sonnet
   group: development
@@ -97,6 +97,32 @@ Confirm the change works and nothing is broken.
 - If project has a type-check command, run it via `Bash`
 - If project has a lint command, run it via `Bash`
 
+### Step 4.5: Quality Decay Check (Self-Regulation)
+
+When fix is called repeatedly (e.g., by cook Phase 4, or iterative fix loops), track a **WTF-likelihood score** — the probability that continued fixing is making things worse.
+
+**Compute every 3 fix attempts** (or when called 5+ times in a single cook session):
+
+| Signal | Score Adjustment |
+|--------|-----------------|
+| A fix was reverted (any test that passed now fails) | +15% |
+| Fix touched >3 files (blast radius expanding) | +5% per extra file beyond 3 |
+| 15+ fixes already applied in this session | +1% per fix beyond 15 |
+| All remaining issues are LOW severity | +10% |
+| Fix touched files outside the original diagnosis scope | +20% |
+| Consecutive fixes without running tests between them | +10% |
+
+**Thresholds:**
+- **>20% WTF-likelihood**: STOP fixing. Report current state to cook/user with: "Quality decay detected — continued fixes risk introducing more bugs than they resolve. {N} fixes applied, {score}% risk. Recommend: commit current progress, re-assess remaining issues."
+- **Hard cap: 30 fixes per session** — regardless of score. After 30, STOP and report.
+
+**Reset conditions:** WTF-likelihood resets to 0% when:
+- User explicitly says "continue fixing"
+- A full test suite run shows zero regressions
+- Scope is narrowed to a single file
+
+> Source: garrytan/gstack v0.9.0 (qa skill) — prevents runaway fix loops where each fix introduces new risk.
+
 ### Step 5: Post-Fix Hardening (Defense-in-Depth)
 
 After the fix works, make the bug **structurally impossible** — not just "fixed this time."
@@ -207,6 +233,7 @@ Known failure modes for this skill. Check these before declaring done.
 | Fixing at crash site without tracing data origin | HIGH | Defense-in-depth: trace where bad data ORIGINATES, add validation at every layer it passes through |
 | Single-point validation (fix one spot, hope it holds) | MEDIUM | Step 5: add entry + business logic + environment + debug layers for data-flow bugs |
 | Removing debug instrumentation before fix is verified | MEDIUM | Step 5b: preserve `#region agent-debug` markers until all tests pass — premature cleanup erases failure history |
+| Runaway fix loop — 20+ fixes without checking quality decay | HIGH | Step 4.5: WTF-likelihood self-regulation. >20% risk = STOP. Hard cap 30 fixes/session. Each fix adds risk — diminishing returns after ~15 |
 
 ## Done When
 

package/skills/git/SKILL.md

@@ -3,7 +3,7 @@ name: git
 description: Specialized git operations — semantic commits, PR descriptions, branch management, conflict resolution guidance. Replaces ad-hoc git commands with a dedicated, convention-aware utility.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: utility
@@ -27,6 +27,7 @@ Specialized git operations utility. Handles semantic commits, PR descriptions, b
 - `/rune git pr` — manual PR generation
 - `/rune git branch <description>` — generate branch name
 - `/rune git changelog` — generate changelog from commits
+- `/rune git release <version>` — create tagged release with changelog
 
 ## Calls (outbound)
 
@@ -187,6 +188,49 @@ Group commits by conventional commit type. Format as [Keep a Changelog](https://
 
 Link to PRs/issues when references found in commit messages.
 
+### Release Mode
+
+Create a version tag with release artifacts.
+
+**Triggers:**
+- `/rune git release <version>` — create release for specified version
+- Called by `launch` (L1) during release pipeline
+- Called by `deploy` (L2) after successful production deploy
+
+#### Step 1 — Validate Version
+
+Parse version string. Must follow semver (`major.minor.patch`):
+- Breaking changes → major bump
+- New features → minor bump
+- Bug fixes → patch bump
+
+Check `git tag -l` to ensure version doesn't already exist.
+
+#### Step 2 — Generate Release Artifacts
+
+1. **Changelog**: Run Changelog Mode to generate entries since last tag
+2. **Version bump**: Update version in `package.json`, `pyproject.toml`, `Cargo.toml`, or equivalent
+3. **Release notes**: Summarize changes for GitHub Release body
+
+#### Step 3 — Tag and Push
+
+```bash
+git add <version-files>
+git commit -m "chore: bump version to v<version>"
+git tag -a v<version> -m "Release v<version>"
+git push origin master --tags
+```
+
+#### Step 4 — Create GitHub Release
+
+```bash
+gh release create v<version> --title "v<version>" --notes "<release-notes>"
+```
+
+#### Step 5 — Notify
+
+If deploy reports customer email list available (via rune-pay `/admin/emails`), flag for notification.
+
 ## Output Format
 
 ### Commit Mode
@@ -235,6 +279,16 @@ Examples: `feat/jwt-refresh`, `fix/123-login-crash`, `refactor/auth-module`
 - Change description (#PR)
 ```
 
+### Release Mode
+```
+## Release: v<version>
+- **Tag**: v<version>
+- **Commits**: [count] since last release
+- **Changelog**: [path to CHANGELOG.md]
+- **GitHub Release**: [URL]
+- **Artifacts**: version bump, changelog, tag, release
+```
+
 ## Constraints
 
 1. MUST use conventional commit format — no freeform messages

package/skills/hallucination-guard/SKILL.md

@@ -3,7 +3,7 @@ name: hallucination-guard
 description: Verify AI-generated imports, API calls, and packages actually exist. Catches phantom functions, non-existent packages, and slopsquatting attacks.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: validation
@@ -74,15 +74,30 @@ File: resolved file path
 
 If export not found → mark as **WARN** (symbol may not be exported).
 
-### Step 3 — Verify external packages
+### Step 3 — Verify external packages (Dependency Check Before Import)
+
+> From taste-skill (Leonxlnx/taste-skill, 3.4k★): "Before importing ANY 3rd party lib, check package.json."
 
 Use `Read` on the project's dependency manifest to confirm each external package is listed:
 
 - JavaScript/TypeScript: `package.json` → check `dependencies` and `devDependencies`
-- Python: `requirements.txt` or `pyproject.toml`
-- Rust: `Cargo.toml` → `[dependencies]`
-
-If package is **not listed** in the manifest → mark as **BLOCK** (phantom dependency).
+- Python: `requirements.txt` or `pyproject.toml` → `[project.dependencies]` and `[project.optional-dependencies]`
+- Rust: `Cargo.toml` → `[dependencies]` and `[dev-dependencies]`
+
+**Pre-import gate** (BEFORE writing import statements, not just after):
+1. If the agent is ABOUT to import a package → check manifest FIRST
+2. If package is NOT in manifest → output install command before writing the import:
+   ```
+   ⚠ Package '<name>' not in dependencies. Install first:
+     npm install <name>        # JS/TS
+     pip install <name>        # Python
+     cargo add <name>          # Rust
+   ```
+3. If package IS in manifest → proceed with import
+
+**Post-import verification** (after code is written):
+- If package is **not listed** in the manifest → mark as **BLOCK** (phantom dependency)
+- If package is listed but not installed (no lockfile entry) → mark as **WARN** (not yet installed)
 
 Also check for typosquatting: if package name has edit distance ≤ 2 from a known popular package (axios/axois, lodash/lodahs, react/recat), mark as **SUSPICIOUS**.
 

package/skills/journal/SKILL.md

@@ -3,7 +3,7 @@ name: journal
 description: Persistent state tracking and Architecture Decision Records across sessions. Manages progress state, module health, dependency graphs, and ADRs for any workflow.
 metadata:
   author: runedev
-  version: "0.2.0"
+  version: "0.3.0"
   layer: L3
   model: haiku
   group: state
@@ -43,6 +43,7 @@ None — pure L3 state management utility.
 .rune/module-status.json   — Machine-readable module states
 .rune/dependency-graph.mmd — Mermaid diagram, color-coded by health
 .rune/adr/                 — Architecture Decision Records (one per decision)
+.rune/risks/               — Risk Register entries (one per identified risk)
 ```
 
 ## Execution
@@ -111,6 +112,50 @@ For each architectural decision or trade-off made during this session (applies t
 - **[Alternative B]**: Rejected because [specific reason]. May reconsider if [condition changes].
 ```
 
+### Step 3.5 — Record risks
+
+For each risk identified during the session (technical, schedule, dependency, security):
+
+1. Generate a risk filename: `.rune/risks/RISK-[NNN]-[slug].md` where NNN is next sequential number
+2. Use `Write` to create the risk file:
+
+```markdown
+# RISK-[NNN]: [Risk Title]
+
+**Date Identified**: [YYYY-MM-DD]
+**Identified By**: [workflow — cook | plan | deploy | audit | adversary]
+**Severity**: Critical | High | Medium | Low
+**Likelihood**: High | Medium | Low
+**Status**: Open | Mitigated | Accepted | Closed
+
+## Description
+[What could go wrong — specific scenario, not vague "things might break"]
+
+## Impact
+[What happens if this risk materializes — quantify if possible]
+
+## Mitigation
+[Actions to reduce likelihood or impact]
+- [ ] [Action 1 — owner, deadline]
+- [ ] [Action 2]
+
+## Trigger Conditions
+[How to detect this risk is materializing — monitoring, alerts, symptoms]
+
+## Contingency
+[What to do if risk materializes despite mitigation — the Plan B]
+```
+
+3. **Risk classification matrix**:
+
+| Likelihood \ Severity | Critical | High | Medium | Low |
+|----------------------|----------|------|--------|-----|
+| **High** | 🔴 Immediate action | 🔴 This sprint | 🟡 This quarter | ⚪ Backlog |
+| **Medium** | 🔴 This sprint | 🟡 This quarter | ⚪ Backlog | ⚪ Accept |
+| **Low** | 🟡 This quarter | ⚪ Backlog | ⚪ Accept | ⚪ Accept |
+
+4. Risks marked 🔴 MUST have mitigation actions with deadlines. ⚪ Accept = documented acknowledgment, no action required.
+
 ### Step 4 — Update dependency graph
 
 If any module dependencies changed during this session (new imports, removed dependencies, refactored interfaces):
@@ -145,6 +190,7 @@ Emit the journal update summary to the calling skill.
 - **Module**: [current module]
 - **Health**: [before] → [after]
 - **ADRs Written**: [count]
+- **Risks Logged**: [count] ([severity breakdown])
 - **Files Updated**: [list of .rune/ files modified]
 - **Next Module**: [next in queue, or "rescue complete"]
 ```
@@ -154,8 +200,9 @@ Emit the journal update summary to the calling skill.
 ```
 1. Read .rune/RESCUE-STATE.md   → full rescue history
 2. Read .rune/module-status.json → module states and health scores
-3. Read git log                  → latest changes since last session
-4. Read CLAUDE.md               → project conventions
+3. Read .rune/risks/             → open risks and their status
+4. Read git log                  → latest changes since last session
+5. Read CLAUDE.md               → project conventions
 → Result: Zero context loss across rescue sessions
 ```
 
@@ -180,6 +227,7 @@ Known failure modes for this skill. Check these before declaring done.
 ## Done When
 
 - All decisions from the session recorded as ADR files with rationale
+- All identified risks recorded as RISK files with severity, mitigation, and trigger conditions
 - Progress state updated (module status, phase, or deploy event as appropriate)
 - Dependency graph updated if module relationships changed
 - Journal Update summary emitted to calling skill

package/skills/plan/SKILL.md

@@ -3,7 +3,7 @@ name: plan
 description: Create structured implementation plans from requirements. Produces master plan + phase files for enterprise-scale project management. Master plan = overview (<80 lines). Phase files = execution detail (<150 lines each). Each session handles 1 phase. Uses opus for deep reasoning.
 metadata:
   author: runedev
-  version: "0.4.0"
+  version: "0.9.0"
   layer: L2
   model: opus
   group: creation
@@ -101,10 +101,25 @@ High-level multi-feature planning — organize features into milestones.
 - `skill-forge` (L2): plan structure for new skill
 - User: `/rune plan` direct invocation
 
-## Cross-Hub Connections
+## Data Flow
+
+### Feeds Into →
+
+- `cook` (L1): master plan + phase files → cook's Phase 2-4 execution roadmap
+- `team` (L1): task decomposition + wave grouping → team's parallel workstream dispatch
+- `fix` (L2): phase file tasks → fix's implementation targets
+- `test` (L2): phase file test tasks → test's RED phase targets
+
+### Fed By ←
+
+- `ba` (L2): Requirements Document → plan's primary input (locked decisions, user stories)
+- `scout` (L2): codebase analysis → plan's convention/pattern awareness
+- `neural-memory` (external): past architectural decisions → plan's precedent context
 
-- `plan` ↔ `brainstorm` — bidirectional: plan asks brainstorm for options, brainstorm asks plan for structure
-- `ba` → `plan` — BA produces Requirements Document, plan consumes it as primary input
+### Feedback Loops ↻
+
+- `plan` ↔ `brainstorm`: plan requests options when multiple approaches exist → brainstorm generates options → plan selects and structures the chosen approach
+- `plan` ↔ `cook`: cook discovers plan gaps during implementation → plan updates phase files → cook resumes with corrected tasks
 
 ## Executable Steps (Implementation Mode)
 
@@ -149,6 +164,46 @@ Phase decomposition rules:
 - **Dependencies before consumers**: create what's imported before the importer
 - **Test alongside**: each phase includes its own test tasks
 - **Max 5-7 tasks per phase**: if more, split the phase
+- **Vertical slices over horizontal layers**: prefer "auth end-to-end" over "all models → all APIs → all UI"
+
+### Wave-Based Task Grouping (within each phase)
+
+Tasks inside a phase MUST be organized into **waves** based on dependency analysis. Independent tasks within the same wave can execute in parallel.
+
+```
+## Tasks
+
+### Wave 1 (parallel — no dependencies)
+- [ ] Task 1 — Create types/interfaces
+  - File: `src/types.ts` (new)
+  - ...
+- [ ] Task 2 — Create validation schema
+  - File: `src/validation.ts` (new)
+  - ...
+
+### Wave 2 (depends on Wave 1)
+- [ ] Task 3 — Implement core logic (imports types from Task 1)
+  - File: `src/core.ts` (new)
+  - depends_on: [Task 1]
+  - ...
+
+### Wave 3 (depends on Wave 2)
+- [ ] Task 4 — Wire into API endpoint (imports core from Task 3)
+  - File: `src/routes/api.ts` (modify)
+  - depends_on: [Task 3]
+  - ...
+- [ ] Task 5 — Write integration tests (tests core from Task 3)
+  - File: `tests/core.test.ts` (new)
+  - depends_on: [Task 3]
+  - ...
+```
+
+**Wave rules:**
+- Wave 1 = tasks with zero dependencies (types, schemas, configs) — always first
+- Subsequent waves: a task goes in the earliest wave where ALL its `depends_on` tasks are in prior waves
+- Tasks within the same wave have NO dependencies on each other → safe for parallel dispatch
+- `depends_on` field is MANDATORY for Wave 2+ tasks — explicit is better than implicit
+- `team` orchestrator can dispatch wave tasks as parallel subagents; solo `cook` executes sequentially within a wave but respects wave ordering
 
 ### Step 4 — Write Master Plan File
 
@@ -188,6 +243,52 @@ Save to `.rune/plan-<feature>.md`:
 
 **Max 80 lines.** No implementation details — that's what phase files are for.
 
+### Step 4.5 — Workflow Registry (Complex Features Only)
+
+> From agency-agents (msitarzewski/agency-agents, 50.8k★): "Every route is an entry point. Every worker is a workflow. If it's missing from the registry, it doesn't exist."
+
+For complex features (4+ phases OR 3+ user-facing workflows), build a **4-view Workflow Registry** before writing phase files. This catches missing pieces, dead ends, and integration gaps at plan time — not implementation time.
+
+**Skip conditions**: trivial tasks, inline plans, single-workflow features.
+
+**4 cross-referenced views:**
+
+```markdown
+## Workflow Registry
+
+### View 1: By Workflow
+| Workflow | Entry Point | Components Touched | Exit Point | Phase |
+|----------|-------------|-------------------|------------|-------|
+| User signup | POST /auth/register | AuthService, UserRepo, EmailService | 201 + email sent | Phase 1 |
+| Password reset | POST /auth/reset | AuthService, EmailService, TokenRepo | 200 + reset email | Phase 2 |
+
+### View 2: By Component
+| Component | Used By Workflows | Owner Phase | Status |
+|-----------|-------------------|-------------|--------|
+| AuthService | signup, login, reset | Phase 1 | Planned |
+| EmailService | signup, reset, invite | Phase 2 | Planned |
+| TokenRepo | reset, invite | Phase 2 | Missing ← RED FLAG |
+
+### View 3: By User Journey
+| Journey | Steps (workflow chain) | Happy Path | Error Path |
+|---------|----------------------|------------|------------|
+| New user → first action | signup → verify email → login → onboard | 4 steps | signup fail, email bounce |
+
+### View 4: By State
+| Step | User Sees | DB State | Logs | Operator Sees |
+|------|-----------|----------|------|---------------|
+| After signup | "Check your email" | user.status=pending | user.created event | New user in admin |
+| After verify | Dashboard | user.status=active | user.verified event | Active user count +1 |
+```
+
+**Validation rules:**
+- Every component in View 2 MUST appear in at least one workflow in View 1 — orphaned components = dead code
+- Every workflow in View 1 MUST map to a phase — unphased workflows will be forgotten
+- "Missing" status in View 2 = **red flag** — component needed but not planned in any phase → add to a phase or create new phase
+- Every user journey step in View 3 MUST have a corresponding state row in View 4
+
+**Output**: Add the registry to the master plan file (it fits within the 80-line budget when tables are compact). Phase files reference it but don't duplicate it.
+
 ### Step 5 — Write Phase Files
 
 For each phase, save to `.rune/plan-<feature>-phase<N>.md`.
@@ -235,6 +336,7 @@ function validateInput(raw: unknown): TradeEntry[];  // throws ValidationError
 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
+  - Req: REQ-001 (P&L calculation)
   - File: `src/foo/bar.ts` (new)
   - Test: `tests/foo/bar.test.ts` (new)
   - Verify: `npm test -- --grep "calculateProfit"`
@@ -242,12 +344,14 @@ Each task MUST include: **File** (exact path), **Test** (test file or N/A), **Ve
   - 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
+  - Req: REQ-002 (input validation)
   - 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 integration tests
+  - Req: REQ-001, REQ-002 (integration coverage)
   - File: `tests/foo/bar.test.ts` (modify)
   - Test: N/A — this IS the test task
   - Verify: `npm test -- --grep "trading" && npx tsc --noEmit`
@@ -296,6 +400,14 @@ Each task MUST include: **File** (exact path), **Test** (test file or N/A), **Ve
 - [ ] Performance: calculateProfit(10K entries) < 100ms
 - [ ] No `any` types, no mutation, no `toFixed()` for money
 
+## Traceability Matrix
+| Req ID | Requirement | Task(s) | Test(s) | Status |
+|--------|-------------|---------|---------|--------|
+| REQ-001 | P&L calculation with fees | Task 1 | `tests/foo/bar.test.ts` | ⬚ |
+| REQ-002 | Input validation | Task 2 | `tests/foo/baz.test.ts` | ⬚ |
+
+Every requirement from BA's Requirements Document MUST appear in this matrix. Missing requirement = incomplete phase. `completion-gate` checks this matrix during verification.
+
 ## Files Touched
 - `src/foo/bar.ts` — new
 - `src/foo/baz.ts` — modify
@@ -314,17 +426,36 @@ Every phase file MUST include ALL of these sections (Amateur-Proof Checklist):
 6. ✅ Cross-Phase Context — what's assumed from prior phases, what's exported for future phases
 7. ✅ Acceptance Criteria — testable, includes performance if applicable
 8. ✅ Test tasks — every code task has corresponding tests
+9. ✅ Traceability Matrix — every BA requirement mapped to tasks and tests (skip if no BA requirements exist)
 
 A phase missing ANY of sections 1-7 is INCOMPLETE — the weakest coder will guess wrong.
 Performance Constraints section is optional (only when NFRs apply).
 </HARD-GATE>
 
+### Step 5.5 — Completeness Scoring (Alternatives)
+
+When presenting alternative approaches (from brainstorm or Step 3 decisions), rate each with **Completeness X/10**:
+
+| Score | Meaning |
+|-------|---------|
+| 9-10 | Complete — all edge cases, full coverage, production-ready |
+| 7-8 | Happy path covered, some edges skipped |
+| 4-6 | Shortcut — defers significant work |
+| 1-3 | Minimal viable, debt guaranteed |
+
+**Always recommend higher-completeness option.** With AI-assisted coding, the marginal cost of completeness is near-zero. Show dual effort estimates for each approach: `(human: ~X / AI: ~Y)`.
+
+**Anti-pattern**: "Option B saves 70 LOC" → 70 LOC delta is meaningless with AI. Choose complete. The last 10% of coverage is where production bugs hide.
+
+> Source: garrytan/gstack v0.9.0 — "Boil the Lake" principle.
+
 ### Step 6 — Present and Get Approval
 
 Present the **master plan** to user (NOT all phase files). User reviews:
 - Phase breakdown
 - Key decisions
 - Risks
+- Completeness scores for chosen approach (from Step 5.5)
 
 Wait for explicit approval ("go", "proceed", "yes") before writing phase files.
 
@@ -519,7 +650,23 @@ Max 200 lines. Self-contained — coder needs ONLY this file.
 | 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 |
+| Horizontal layer planning (all models → all APIs → all UI) | HIGH | Vertical slices parallelize better. Use wave-based grouping: independent tasks in same wave, dependent tasks in later waves |
+| Tasks without `depends_on` in Wave 2+ | MEDIUM | Implicit dependencies break parallel dispatch. Every Wave 2+ task MUST declare `depends_on` |
 | Plan ignores locked Decisions from BA | CRITICAL | Decision Compliance section cross-checks requirements.md — locked decisions are non-negotiable |
+| Complex feature missing Workflow Registry — components planned but never wired | HIGH | Step 4.5: 4-view registry catches orphaned components, unphased workflows, and missing state transitions before phase files are written |
+| Recommending shortcut approach without Completeness Score | MEDIUM | Step 5.5: every alternative needs X/10 Completeness score + dual effort estimate (human vs AI). "Saves 70 LOC" is not a reason when AI makes the delta cost minutes |
+
+## Self-Validation
+
+```
+SELF-VALIDATION (run before presenting plan to user):
+- [ ] Every task has a clear file path — no "update relevant files" vagueness
+- [ ] Wave dependencies are acyclic — no task depends on a task in the same or later wave
+- [ ] Every code-producing phase has at least one test task
+- [ ] Phase files have ALL Amateur-Proof sections (data flow, code contracts, failure scenarios, rejection criteria)
+- [ ] Locked decisions from BA are reflected in plan — none contradicted or ignored
+- [ ] Every BA requirement has a corresponding Req ID in at least one phase's Traceability Matrix
+```
 
 ## Done When
 
@@ -534,6 +681,7 @@ Max 200 lines. Self-contained — coder needs ONLY this file.
 - Every code-producing phase has test tasks
 - Master plan presented to user with "Awaiting Approval"
 - User has explicitly approved
+- Self-Validation: all checks passed
 
 ## Cost Profile