@rune-kit/rune 2.2.3 → 2.2.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rune-kit/rune",
-  "version": "2.2.3",
+  "version": "2.2.4",
   "description": "58-skill mesh for AI coding assistants — 5-layer architecture, 200+ connections, 8 platforms (Claude Code, Cursor, Windsurf, Antigravity, Codex, OpenCode, OpenClaw, Generic)",
   "type": "module",
   "bin": {

package/skills/completion-gate/SKILL.md

@@ -4,7 +4,7 @@ description: "Validates agent claims against evidence trail. Catches 'done' with
 user-invocable: false
 metadata:
   author: runedev
-  version: "1.2.0"
+  version: "1.3.0"
   layer: L3
   model: haiku
   group: validation
@@ -123,6 +123,34 @@ IF no evidence found:
 UNCONFIRMED — 1 claim lacks evidence, 1 contradicted. Cannot proceed to commit.
 ```
 
+### Step 4.5 — Cross-Phase Integration Check
+
+> From GSD (gsd-build/get-shit-done, 30.8k★): "Phase boundaries are where integration bugs hide."
+
+When validating a completed phase in a multi-phase plan, check for integration gaps between phases:
+
+1. **Orphaned exports** — files/functions created in this phase that claim to be used by future phases (see `## Cross-Phase Context → Exports`) but are not yet importable:
+   ```
+   Grep for the export name in the current codebase:
+   - If export exists AND is importable → CONFIRMED
+   - If export exists but has wrong signature vs phase file contract → CONTRADICTED
+   - Expected export missing entirely → UNCONFIRMED ("Phase N claims to export X but X not found")
+   ```
+
+2. **Uncalled routes** — API endpoints added in this phase but not wired to any frontend/consumer yet:
+   - This is OK if a future phase handles wiring (check master plan)
+   - Flag as WARN if no future phase mentions consuming this route
+
+3. **Auth gaps** — new endpoints or pages without authentication/authorization:
+   - `Grep` for route handlers without auth middleware
+   - Flag as WARN (may be intentional for public endpoints, but worth checking)
+
+4. **E2E flow trace** — for the primary user flow this phase enables:
+   - Trace: entry point → business logic → data layer → response
+   - If any step in the chain is missing or stubbed → CONTRADICTED
+
+**This step is OPTIONAL for single-phase tasks and MANDATORY for multi-phase master plans.**
+
 ### Step 5 — Evidence Quality Gate
 
 Before emitting verdict, verify evidence quality:
@@ -170,6 +198,8 @@ Completion Gate Report with status (CONFIRMED/UNCONFIRMED/CONTRADICTED), claim v
 | Agent pre-generates evidence by running commands proactively | LOW | This is actually GOOD behavior — we want agents to provide evidence |
 | Completion-gate itself claims "all confirmed" without evidence | CRITICAL | Gate report MUST include the evidence table — no table = report is invalid |
 | Existence Theater — agent creates files but they're stubs | HIGH | Step 1b stub detection: grep for Placeholder/TODO/NotImplementedError in new files |
+| Cross-phase integration gaps — exports exist but wrong signature | HIGH | Step 4.5: verify exports match Code Contracts from phase file |
+| Phase complete but E2E flow broken — missing link in the chain | MEDIUM | Step 4.5 E2E flow trace: entry → logic → data → response must all be connected |
 
 ## Done When
 

package/skills/cook/SKILL.md

@@ -5,7 +5,7 @@ context: fork
 agent: general-purpose
 metadata:
   author: runedev
-  version: "0.7.0"
+  version: "0.9.0"
   layer: L1
   model: sonnet
   group: orchestrator
@@ -322,6 +322,11 @@ If the coder model needs info from other phases, it's in the Cross-Phase Context
 1. Mark Phase 4 as `in_progress`
 2. **Phase-file execution** — if working from a master plan + phase file:
    - Execute tasks listed in the phase file (the `## Tasks` section)
+   - **Wave-based execution**: if tasks are organized into waves (see `plan` skill), execute wave-by-wave:
+     - Wave 1 tasks first (no dependencies — can run in parallel if inside `team`)
+     - Wave 2 tasks only after ALL Wave 1 tasks complete
+     - Within a wave: `team` dispatches as parallel subagents; solo cook runs sequentially
+     - If a task in Wave N fails → do NOT start Wave N+1. Fix or DECOMPOSE the failed task first
    - Follow code contracts from `## Code Contracts` section
    - Respect rejection criteria from `## Rejection Criteria` section
    - Handle failure scenarios from `## Failure Scenarios` section
@@ -419,6 +424,7 @@ PARALLEL EXECUTION:
 **REQUIRED SUB-SKILL**: Use `rune:completion-gate`
 - Validate that agent claims match evidence trail
 - Check: tests actually ran (stdout captured), files actually changed (git diff), build actually passed
+- Check: no truncated code files (`// ...`, `// rest of code`, bare ellipsis) — agent MUST complete all output
 - Any UNCONFIRMED claim → BLOCK with specific gap identified
 
 **Gate**: If sentinel finds CRITICAL security issue → STOP, fix it, re-run. Non-negotiable.
@@ -739,13 +745,23 @@ A wrong first attempt that produces feedback beats perfect understanding that ne
 
 ```
 ## Cook Report: [Task Name]
-- **Status**: complete | partial | blocked
+- **Status**: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
 - **Phases**: [list of completed phases]
 - **Files Changed**: [count] ([list])
 - **Tests**: [passed]/[total] ([coverage]%)
 - **Quality**: preflight [PASS/WARN] | sentinel [PASS/WARN] | review [PASS/WARN]
 - **Commit**: [hash] — [message]
 
+### Deliverables (NEXUS response — when invoked by team)
+| # | Deliverable | Status | Evidence |
+|---|-------------|--------|----------|
+| 1 | [from handoff] | DELIVERED | [file path or test output quote] |
+| 2 | [from handoff] | DELIVERED | [file path or test output quote] |
+| 3 | [from handoff] | PARTIAL | [what's missing and why] |
+
+### Concerns (if DONE_WITH_CONCERNS)
+- [concern]: [impact assessment] — [suggested remediation]
+
 ### Decisions Made
 - [decision]: [rationale]
 
@@ -754,6 +770,8 @@ A wrong first attempt that produces feedback beats perfect understanding that ne
 - Saved to .rune/progress.md
 ```
 
+> When cook is invoked standalone (not by team), the Deliverables table is optional. When invoked by team with a NEXUS Handoff, the Deliverables table is MANDATORY — team uses it to track acceptance criteria across streams.
+
 ## Sharp Edges
 
 Known failure modes for this skill. Check these before declaring done.

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/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.4.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
 

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