@rune-kit/rune 2.2.2 → 2.2.4

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/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.6.0"
   layer: L2
   model: opus
   group: creation
@@ -149,6 +149,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 +228,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`.
@@ -519,7 +605,10 @@ 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 |
 
 ## Done When
 

package/skills/review/SKILL.md

@@ -380,6 +380,7 @@ LOW       — style inconsistency, naming suggestion, minor refactor opportunity
 | 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 |
+| Missing cross-phase integration check at phase boundary | MEDIUM | When reviewing a phase completion: check orphaned exports, uncalled routes, auth gaps, E2E flow continuity. Delegate to completion-gate Step 4.5 |
 
 ## Done When
 

package/skills/sentinel-env/SKILL.md

@@ -3,7 +3,7 @@ name: sentinel-env
 description: Environment-aware pre-flight check. Validates OS, runtime versions, installed tools, port availability, env vars, and disk space BEFORE coding starts. Prevents "works on my machine" failures. Like sentinel but for the environment, not the code.
 metadata:
   author: runedev
-  version: "0.1.0"
+  version: "0.2.0"
   layer: L3
   model: haiku
   group: validation
@@ -111,6 +111,34 @@ Detect and verify tools the project depends on:
 4. **Database tools**: Check if `prisma`, `drizzle`, `alembic`, `django` migrations exist → verify DB client installed
 5. **Build tools**: Check for `turbo.json` (turborepo), `nx.json` (Nx), `Makefile`, etc.
 
+6. **Hard dependencies** — tools the project WRAPS (not just uses as dev dependency):
+   > From CLI-Anything (HKUDS/CLI-Anything, 17.4k★): "The software is a required dependency, not optional."
+
+   Scan for evidence that the project wraps an external tool:
+   - `Grep` for `shutil.which(`, `which `, `command -v ` → project looks up an executable at runtime
+   - `Grep` for `subprocess.run(`, `child_process.exec(`, `Deno.Command(` → project invokes external CLI
+   - `Read` README/docs for "requires X installed" or "depends on X"
+
+   For each detected hard dependency:
+   ```bash
+   # Verify the tool exists on PATH
+   which <tool-name> 2>/dev/null || echo "MISSING: <tool-name>"
+   # If found, check version
+   <tool-name> --version 2>/dev/null
+   ```
+
+   **Verdict:**
+   - Tool found on PATH → PASS (log version)
+   - Tool NOT found → **BLOCK** with clear install instructions per OS:
+     ```
+     [ENV-XXX] Required tool '<tool>' not found on PATH
+       → Debian/Ubuntu: sudo apt install <tool>
+       → macOS: brew install <tool>
+       → Windows: winget install <tool> (or choco install <tool>)
+       → Manual: <download URL if known>
+     ```
+   - This prevents the entire class of "it worked in CI but not locally" failures where `subprocess.run()` silently fails
+
 ### Step 4: Port Availability Check
 
 Detect which ports the project needs and check if they're available:
@@ -210,6 +238,8 @@ For each finding, include a specific remediation command the developer can copy-
 | .env file contains secrets — accidentally logged | CRITICAL | NEVER read .env values, only check key existence via grep for key names |
 | Platform detection wrong — WSL vs native Windows | MEDIUM | Check for WSL explicitly (`uname -r` contains "microsoft") |
 | Over-checking — flagging optional tools as required | MEDIUM | Only check tools evidenced by config files, not speculative |
+| Missing hard dependency — project wraps external CLI but tool not checked | HIGH | Step 3.6: scan for `shutil.which`, `subprocess.run`, `child_process.exec` → verify tool exists on PATH |
+| Hard dep found but wrong version — tool exists but API changed | MEDIUM | Log version for manual review. Version compatibility is project-specific — don't guess |
 
 ## Done When
 

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.1.0"
+  version: "1.2.0"
   layer: L2
   model: opus
   group: creation
@@ -214,6 +214,62 @@ Run additional pressure scenarios with varied pressures. For each new failure:
 
 Repeat until no new failures emerge in 2 consecutive test runs.
 
+#### Pressure Types for Test Scenarios
+
+Best tests combine 3+ pressures simultaneously:
+
+| Pressure | Example Scenario |
+|----------|------------------|
+| Time | "Emergency deployment, deadline in 30 min" |
+| Sunk cost | "Already wrote 200 lines, can't restart" |
+| Authority | "Senior dev says skip testing" |
+| Economic | "Customer churning, ship now or lose $50k MRR" |
+| Exhaustion | "50 tool calls deep, context filling up" |
+| Social | "Looking dogmatic by insisting on process" |
+| Pragmatic | "Being practical vs being pedantic" |
+
+#### Scenario Quality Requirements
+
+1. **Concrete A/B/C options** — force explicit choice (no "I'd ask the user" escape hatch)
+2. **Real constraints** — specific times, actual consequences, named files
+3. **Real file paths** — `/tmp/payment-system` not "a project"
+4. **"Make agent ACT"** — "What do you do?" not "What should you do?"
+5. **No easy outs** — every option has a cost
+
+#### Meta-Testing (When GREEN Isn't Working)
+
+If the agent keeps failing even WITH the skill loaded, ask: "How could that skill have been written differently to make the correct option crystal clear?"
+
+Three possible responses:
+1. "Skill was clear, I chose to ignore it" → foundational principle needed (stronger HARD-GATE)
+2. "Skill should have said X explicitly" → add that exact phrasing verbatim
+3. "I didn't see section Y" → reorganize for discoverability (move up, add header)
+
+#### Bulletproof Criteria
+
+A skill is bulletproof when:
+- Agent chooses correct option under maximum pressure (3+ pressures combined)
+- Agent CITES skill sections as justification for its choice
+- Agent ACKNOWLEDGES the temptation but follows the rule anyway
+
+#### Persuasion Principles for Skill Language
+
+Research (Meincke et al., 2025, 28,000 conversations) shows 33% → 72% compliance with these techniques:
+
+| Principle | Application | Use For |
+|-----------|-------------|---------|
+| Authority | "YOU MUST", imperative language | Eliminates decision fatigue, safety-critical rules |
+| Commitment | Explicit announcements + tracked choices | Creates accountability trail |
+| Scarcity | Time-bound requirements, "before proceeding" | Triggers immediate action |
+| Social Proof | "Every time", universal statements | Documents what prevents failures |
+| Unity | "We're building quality" language | Shared identity, quality goals |
+
+**Prohibited in skills:**
+- **Liking** ("Great job following the process!") → creates sycophancy
+- **Reciprocity** ("I helped you, now follow the rules") → feels manipulative
+
+**Ethical test**: Would this serve the user's genuine interests if they fully understood the technique?
+
 ### Phase 6 — INTEGRATE
 
 Wire the skill into the mesh:

package/skills/team/SKILL.md

@@ -5,7 +5,7 @@ context: fork
 agent: general-purpose
 metadata:
   author: runedev
-  version: "0.4.0"
+  version: "0.5.0"
   layer: L1
   model: opus
   group: orchestrator
@@ -152,7 +152,11 @@ Mark todo[1] `in_progress`.
 
 **2a. Launch parallel streams.**
 
-Launch independent streams (depends_on: []) in parallel using Task tool with worktree isolation:
+Launch independent streams (depends_on: []) in parallel using Task tool with worktree isolation.
+
+> From agency-agents (msitarzewski/agency-agents, 50.8k★): "Structured handoff docs prevent the #1 multi-agent failure: context loss between agents."
+
+Each stream receives a **NEXUS Handoff Template** — not a bare prompt:
 
 ```
 For each stream where depends_on == []:
@@ -160,22 +164,54 @@ For each stream where depends_on == []:
     subagent_type: "general-purpose",
     model: "sonnet",
     isolation: "worktree",
-    prompt: "Cook task: [stream.task]. Files in scope: [stream.files]. Return cook report on completion."
+    prompt: <NEXUS Handoff below>
   )
 ```
 
+**NEXUS Handoff Template** (sent to each cook instance):
+
+```markdown
+## NEXUS Handoff: Stream [id]
+
+### Metadata
+- Stream: [id] of [total]
+- Depends on: [none | stream ids]
+- File ownership: [list — ONLY these files may be modified]
+- Model: sonnet
+
+### Context
+- Project: [project name and type]
+- Overall goal: [1-line feature description]
+- This stream's goal: [specific sub-task]
+- Conventions: [key patterns from scout — naming, file structure, test framework]
+
+### Deliverable
+- [ ] [specific outcome 1 — e.g., "AuthService with login/register/reset methods"]
+- [ ] [specific outcome 2 — e.g., "Unit tests covering happy path + 3 error cases"]
+- [ ] [specific outcome 3 — e.g., "Types exported for Phase 2 consumers"]
+
+### Quality Expectations
+- Tests: must pass with evidence (stdout captured)
+- Types: no `any`, strict mode
+- Security: no hardcoded secrets, parameterized queries
+- Conventions: [project-specific — from scout output]
+
+### Evidence Required
+Return a Cook Report with:
+- Exact files modified (git diff --stat)
+- Test output (stdout — not just "tests pass")
+- Any CONCERNS discovered during implementation
+```
+
 **2b. Launch dependent streams sequentially.**
 
 ```
 For each stream where depends_on != []:
   WAIT for all depends_on streams to complete.
-  Then launch:
-  Task(
-    subagent_type: "general-purpose",
-    model: "sonnet",
-    isolation: "worktree",
-    prompt: "Cook task: [stream.task]. Files in scope: [stream.files]. Patterns from stream [depends_on] are available in worktree. Return cook report."
-  )
+  Then launch with NEXUS Handoff that includes:
+  - Completed stream's deliverables as "Available Context"
+  - Exported interfaces/types from prior streams in "Code Contracts" section
+  - Any CONCERNS from prior streams in "Known Issues" section
 ```
 
 **2b.5. Pre-merge scope verification.**
@@ -367,16 +403,24 @@ Mark todo[4] `completed`.
 - **Duration**: [time across streams]
 
 ### Streams
-| Stream | Task | Status | Cook Report |
-|--------|------|--------|-------------|
-| A | [task] | complete | [summary] |
-| B | [task] | complete | [summary] |
-| C | [task] | complete | [summary] |
+| Stream | Task | Status | Deliverables | Concerns |
+|--------|------|--------|-------------|----------|
+| A | [task] | DONE | 3/3 delivered | None |
+| B | [task] | DONE_WITH_CONCERNS | 2/2 delivered | Perf regression on large input |
+| C | [task] | DONE | 2/2 delivered | None |
+
+### Acceptance Criteria
+| # | Criterion | Stream | Evidence | Verdict |
+|---|-----------|--------|----------|---------|
+| 1 | Auth endpoints return JWT | A | Test stdout: "3 passed" | PASS |
+| 2 | No SQL injection | A | Sentinel: PASS | PASS |
+| 3 | Dashboard loads < 2s | B | No perf test run | UNVERIFIED |
 
 ### Integration
 - Merge conflicts: [count]
 - Integration tests: [passed]/[total]
 - Coverage: [%]
+- Unresolved concerns: [count — from DONE_WITH_CONCERNS streams]
 ```
 
 ---
@@ -405,6 +449,8 @@ Known failure modes for this skill. Check these before declaring done.
 | Agent modified files outside declared scope | HIGH | Pre-merge scope verification in Phase 2b.5 — flag before merge, not after |
 | Merge failure with no rollback path | HIGH | pre-team-merge tag created before merges — git reset --hard on failure |
 | Poisoned cook report merged blindly | HIGH | Phase 3a.5 integrity-check on all cook reports before merge |
+| Bare prompt to cook instance — no context, conventions, or scope boundary | HIGH | NEXUS Handoff Template: structured handoff with metadata, deliverables, quality expectations, and evidence requirements |
+| Cook returns "done" with no acceptance criteria tracking | MEDIUM | Team Report includes Acceptance Criteria table with per-criterion evidence and PASS/FAIL/UNVERIFIED verdict |
 
 ## Done When
 

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.3.0"
+  version: "0.5.0"
   layer: L2
   model: sonnet
   group: development
@@ -168,15 +168,73 @@ Input:  git diff main --name-only
 Output: Prioritized test plan targeting only affected paths
 ```
 
-## Test Types
+## Test Types — 4-Layer Methodology
 
-| Type | When | Framework | Speed |
-|------|------|-----------|-------|
-| Unit | Individual functions, pure logic | jest/vitest/pytest/cargo test | Fast |
-| 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) |
+Tests are organized in 4 layers. Each layer catches a different failure class. Higher layers are slower but catch integration issues lower layers miss.
+
+| Layer | Type | What It Catches | Framework | Speed |
+|-------|------|-----------------|-----------|-------|
+| L1 | **Unit** | Logic bugs, boundary violations, pure function errors | jest/vitest/pytest/cargo test | Fast |
+| L2 | **Integration** | API contract breaks, DB query errors, service interaction failures | supertest/httpx/reqwest | Medium |
+| L3 | **True Backend** | Real tool/service output correctness (not just exit 0) | Same + real software invocation | Medium-Slow |
+| L4 | **E2E / Subprocess** | Full workflow from user/agent perspective, installed app works | Playwright/Cypress/subprocess | Slow |
+
+**Layer rules:**
+- **L1 (Unit)**: Synthetic data, no external deps. Every function tested in isolation. Fast, deterministic, CI-friendly
+- **L2 (Integration)**: Tests service boundaries — API endpoints, DB operations, message queues. May need test DB or mock server
+- **L3 (True Backend)**: **Invokes the REAL tool/service** and verifies output programmatically. No graceful degradation — if the dependency isn't installed, tests FAIL (not skip). Verify: magic bytes, file size > 0, content structure. Print artifact paths for manual inspection
+- **L4 (E2E/Subprocess)**: Tests the installed command/app via subprocess or browser automation. Full user workflow: input → process → output → verify
+
+**"No graceful degradation" rule** (L3/L4): Hard dependencies MUST be installed. Tests MUST NOT skip or produce fake results when the dependency is missing. A silently skipping test is worse than a loudly failing test.
+
+Additional modes:
+
+| Type | When | Speed |
+|------|------|-------|
+| Regression | After bug fixes | Fast |
+| Diff-aware | After implementation, large codebases (Phase 6.5) | Fast (targeted) |
+
+## TEST.md — Test Plan + Results Document
+
+For non-trivial features (3+ test files or 20+ test cases), create a `TEST.md` in the test directory. This is BOTH a planning doc (written BEFORE tests) and results doc (appended AFTER tests pass).
+
+### Before writing tests — write the plan:
+```markdown
+# Test Plan: [Feature Name]
+
+## Test Inventory
+- `test_core.py`: ~XX unit tests planned (L1)
+- `test_integration.py`: ~XX integration tests planned (L2)
+- `test_e2e.py`: ~XX E2E tests planned (L3/L4)
+
+## Unit Test Plan (L1)
+| Module | Functions | Edge Cases | Est. Tests |
+|--------|-----------|------------|------------|
+| `core/auth.py` | login, register, refresh | expired token, invalid creds, rate limit | 12 |
+
+## E2E Scenarios (L3/L4)
+| Workflow | Simulates | Operations | Verified |
+|----------|-----------|------------|----------|
+| User signup | New user onboarding | register → verify → login | Token valid, profile created |
+
+## Realistic Workflow Scenarios
+- **[Name]**: [Step 1] → [Step 2] → verify [output properties]
+```
+
+### After tests pass — append results:
+```markdown
+## Test Results
+[Paste full `pytest -v --tb=no` or `npm test` output]
+
+## Summary
+- Total: XX | Passed: XX | Failed: 0
+- Execution time: X.Xs | Coverage: XX%
+
+## Gaps
+- [Areas not covered and why]
+```
+
+**Why TEST.md**: Planning tests before code catches missing edge cases early. Appending results creates permanent evidence. One document = complete testing story.
 
 ## Error Recovery
 
@@ -271,6 +329,36 @@ If you catch yourself with ANY of these, delete implementation code and restart
 - [existing test that broke, with error details]
 ```
 
+## Testing Anti-Patterns (Gate Functions)
+
+Before writing tests, check yourself against these 5 anti-patterns. Each has a **gate function** — a question you MUST answer before proceeding.
+
+### Anti-Pattern 1: Testing Mock Behavior
+Asserting that a mock exists (e.g., `testId="sidebar-mock"`) instead of testing real component behavior. You're proving the mock works, not the code.
+**Gate**: "Am I testing real component behavior or just mock existence?" → If mock existence: STOP. Rewrite to test real behavior.
+
+### Anti-Pattern 2: Test-Only Methods in Production
+Adding `destroy()`, `reset()`, or `__testSetup()` methods to production classes that are ONLY called from test files. Production code should not know tests exist.
+**Gate**: "Is this method only called by tests?" → If yes: STOP. Move to test utilities or test helper file, not production class.
+
+### Anti-Pattern 3: Mocking Without Understanding Side Effects
+Mocking a function without first understanding ALL its side effects. The real function may write config files, update caches, or emit events that downstream code depends on.
+**Gate**: Before mocking, STOP and answer: "What side effects does the REAL function have? Does this test depend on any of those?" → Run with real implementation first, observe what happens, THEN add minimal mocking.
+
+### Anti-Pattern 4: Incomplete Mocks
+Partial mock missing fields that downstream code consumes. Your test passes because it only checks the fields you mocked, but production code reads fields your mock doesn't have → runtime crash.
+**Iron Rule**: Mock the COMPLETE data structure as it exists in reality, not just fields your immediate test uses. Examine actual API response / real data shape before writing mock.
+
+### Anti-Pattern 5: Mock Setup Longer Than Test Logic
+If mock setup is 30 lines and the actual test assertion is 3 lines, the test is testing infrastructure, not behavior. This is a code smell that indicates wrong abstraction level.
+**Gate**: "Is my mock setup longer than my test logic?" → If yes: test at a higher level (integration) or extract mock factories.
+
+**Red flags — any of these means STOP and rethink:**
+- Mock setup longer than test logic
+- `*-mock` test IDs in assertions
+- Methods only called in test files
+- Can't explain in one sentence why a mock is needed
+
 ## Sharp Edges
 
 Known failure modes for this skill. Check these before declaring done.
@@ -279,10 +367,13 @@ Known failure modes for this skill. Check these before declaring done.
 |---|---|---|
 | Tests passing before implementation exists | CRITICAL | RED Gate: rewrite stricter tests — passing without code = not testing real behavior |
 | Skipping the RED phase (not confirming FAIL) | HIGH | Run tests, confirm FAIL output before calling cook/fix to implement |
-| Testing mock behavior instead of real code | HIGH | Constraint 4: test what the real code does, not what the mock returns |
+| Testing mock behavior instead of real code | HIGH | Anti-Pattern 1 gate: "Am I testing real behavior or mock existence?" |
+| Mocking without understanding side effects | HIGH | Anti-Pattern 3 gate: run with real impl first, observe side effects, THEN mock minimally |
+| Incomplete mocks missing downstream fields | HIGH | Anti-Pattern 4 iron rule: mock COMPLETE data structure, not just fields your test checks |
 | 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 |
+| Test-only methods leaking into production code | MEDIUM | Anti-Pattern 2 gate: if method only called by tests → move to test utilities |
 
 ## 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.4.0"
+  version: "0.5.0"
   layer: L3
   model: haiku
   group: validation
@@ -233,6 +233,33 @@ Overall:   [PASS/FAIL]
 - Unwired: [files that failed Level 3 with 0 consumers]
 ```
 
+## Output Completion Enforcement
+
+> From taste-skill (Leonxlnx/taste-skill, 3.4k★): Truncated code is worse than no code — it passes reviews but breaks at runtime.
+
+When verifying code files (Level 2 SUBSTANTIVE check), also scan for **truncation patterns** — signs that the agent generated partial output and stopped:
+
+| Banned Pattern | Language | What It Means |
+|---|---|---|
+| `// ...` or `/* ... */` as a statement | JS/TS | Agent truncated remaining code |
+| `# ...` as a statement (not comment) | Python | Agent truncated |
+| `// rest of code` / `// remaining implementation` | Any | Explicit truncation admission |
+| `// TODO: implement` as sole function body | Any | Placeholder, not implementation |
+| `{ /* same as above */ }` | JS/TS | Copy-paste truncation |
+| `...` (bare ellipsis, not spread operator) | JS/TS/Python | Truncation marker |
+| `[PAUSED]` / `[CONTINUED]` in source | Any | Agent session marker leaked into code |
+
+**Action on detection:**
+- Mark file as TRUNCATED (distinct from STUB) in Verification Report
+- TRUNCATED files are Level 2 FAIL — they CANNOT pass verification
+- Report the specific line number and pattern detected
+- If agent claims "done" with truncated files → REJECTED by Evidence-Before-Claims gate
+
+**Continuation protocol** — if the agent hit output limits mid-file:
+- Agent MUST log: `[PAUSED — X of Y functions complete]` in its response (NOT in the code file)
+- Agent MUST resume and complete the file in the next turn
+- Verification re-runs after completion to clear the TRUNCATED flag
+
 ## Evidence-Before-Claims Gate
 
 <HARD-GATE>
@@ -284,6 +311,7 @@ Known failure modes for this skill. Check these before declaring done.
 | 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 |
+| Truncated code — agent hit output limit mid-file | HIGH | Output Completion Enforcement: scan for `// ...`, `// rest of code`, bare ellipsis patterns. TRUNCATED = Level 2 FAIL |
 
 ## Done When