@wazir-dev/cli 1.2.0 → 1.4.0

package/expertise/digests/reviewer/code-smells-digest.md

@@ -0,0 +1,53 @@
+# Code Smells — Reviewer Digest
+
+> Detection-focused extract for reviewer context. For full remediation guidance, see `antipatterns/code/code-smells.md`.
+
+## Method-Level Smells
+
+| Smell | Detection Signal | Severity |
+|-------|-----------------|----------|
+| **Long Method** | >30 lines or >3 levels of nesting | medium |
+| **Parameter List** | >4 parameters | medium |
+| **Feature Envy** | Method accesses another object's data more than its own | high |
+| **Message Chains** | `a.b().c().d()` — 3+ chained calls | medium |
+| **Inappropriate Intimacy** | Class reaches into another's private/internal state | high |
+| **Refused Bequest** | Subclass overrides parent methods to do nothing | medium |
+
+## Class-Level Smells
+
+| Smell | Detection Signal | Severity |
+|-------|-----------------|----------|
+| **Large Class** | >300 lines or >10 public methods | medium |
+| **God Class** | Handles >3 unrelated responsibilities | high |
+| **Data Class** | Only getters/setters, no behavior | low |
+| **Lazy Class** | <3 methods, delegating everything | low |
+| **Speculative Generality** | Abstract classes/interfaces with single implementation | medium |
+| **Middle Man** | Class delegates >80% of methods to another | medium |
+
+## Structural Smells
+
+| Smell | Detection Signal | Severity |
+|-------|-----------------|----------|
+| **Shotgun Surgery** | One change requires edits to 5+ files | high |
+| **Divergent Change** | One file changes for multiple unrelated reasons | high |
+| **Parallel Inheritance** | Adding a subclass in one hierarchy requires adding one in another | medium |
+| **Data Clumps** | Same 3+ fields appear together in multiple places | medium |
+| **Primitive Obsession** | Using primitives where a domain type would be clearer | low |
+| **Switch Statements** | Repeated switch/if-else on the same discriminant | medium |
+
+## Code Duplication
+
+| Smell | Detection Signal | Severity |
+|-------|-----------------|----------|
+| **Exact Duplication** | Identical blocks >5 lines | high |
+| **Structural Duplication** | Same algorithm with different types/names | medium |
+| **Semantic Duplication** | Different code doing the same thing | medium |
+
+## Naming Smells
+
+| Smell | Detection Signal | Severity |
+|-------|-----------------|----------|
+| **Misleading Name** | Name implies different behavior than actual | high |
+| **Inconsistent Naming** | Same concept has different names across files | medium |
+| **Generic Name** | `data`, `info`, `handler`, `manager`, `utils` without qualifier | medium |
+| **Encoded Type** | Hungarian notation or type in name (`strName`, `arrList`) | low |

package/expertise/digests/reviewer/coupling-cohesion-digest.md

@@ -0,0 +1,54 @@
+# Coupling & Cohesion — Reviewer Digest
+
+> Evaluation-focused extract for reviewer context. For full guidance, see `architecture/foundations/coupling-and-cohesion.md`.
+
+## Coupling Assessment
+
+| Coupling Type | Detection Signal | Severity |
+|---------------|-----------------|----------|
+| **Content Coupling** | One module directly modifies another's internal state (private fields, internal data structures) | critical |
+| **Common Coupling** | Multiple modules read/write shared global state (global config they all mutate, shared DB table without coordination) | high |
+| **Control Coupling** | Function parameter controls another module's execution flow (boolean flag argument that switches behavior) | medium |
+| **Stamp Coupling** | Passing a large object when only 1-2 fields are needed (entire User object for a function that needs email) | low |
+| **Data Coupling** | Passing only needed data — this is GOOD coupling | none (target) |
+| **Message Coupling** | Modules communicate through events/messages with no identity knowledge — this is BEST coupling | none (target) |
+
+## Cohesion Assessment
+
+| Cohesion Type | Detection Signal | Quality |
+|---------------|-----------------|---------|
+| **Functional** | Module does one thing and does it completely | best |
+| **Sequential** | Output of one operation feeds input of the next (ETL pipeline) | good |
+| **Communicational** | Operations work on the same data (read, compute, format same record) | acceptable |
+| **Temporal** | Operations happen at the same time but serve different purposes (init, cleanup) | poor |
+| **Logical** | Operations share control flow but not purpose (util files, catch-all handlers) | poor |
+| **Coincidental** | No relationship between operations (random grab-bag module) | worst |
+
+## Quick Check
+
+For each module in the diff, ask:
+1. **Cohesion:** Can I describe this module's purpose in one sentence without "and"? If no, low cohesion.
+2. **Coupling:** If I change this module's internals, how many other files need to change? If >2, high coupling.
+3. **Direction:** Do dependencies flow from unstable (UI, API handlers) toward stable (domain, utilities)? If reversed, structural debt.
+
+## Connascence Quick Reference
+
+Connascence refines coupling into a more granular classification. Ordered from weakest (acceptable) to strongest (most harmful):
+
+| Connascence | Description | Acceptable? |
+|-------------|-------------|-------------|
+| **Name** | Two components must agree on a name (function name, variable name) | Yes — unavoidable and cheaply refactored |
+| **Type** | Two components must agree on a type (parameter type, return type) | Yes — enforced by type systems |
+| **Meaning** | Two components must agree on the meaning of a value (true = active, 0 = success) | Caution — use enums/constants instead of magic values |
+| **Position** | Two components must agree on parameter order | Caution — use named parameters or option objects |
+| **Algorithm** | Two components must use the same algorithm (hashing, encoding) | Risky — extract shared algorithm to single location |
+| **Execution** | Two components must execute in a specific order | Risky — make ordering explicit in control flow |
+| **Timing** | Two components must execute at the same time or within a window | High risk — source of race conditions |
+| **Value** | Two components must have correlated values (e.g., two arrays that must be same length) | High risk — encapsulate into a single data structure |
+| **Identity** | Two components must reference the same object instance | High risk — shared mutable state |
+
+## Module Boundary Health
+
+- Modules should have narrow interfaces (few public exports relative to total code)
+- Changes should be localized: a bugfix in module A should not require changes in modules B, C, D
+- Test for boundary health: can you write a unit test for this module without importing 5+ other modules?

package/expertise/digests/reviewer/ddd-digest.md

@@ -0,0 +1,60 @@
+# Domain-Driven Design — Reviewer Digest
+
+> Evaluation-focused extract for reviewer context. For full guidance, see `architecture/foundations/domain-driven-design.md`.
+
+## Bounded Context Check
+
+- Is the module boundary aligned with a domain concept (not a technical layer)?
+- Do different modules use the same term to mean different things? If yes, a context boundary is needed.
+- Are there translation/mapping layers between modules? If not and they share types, potential coupling risk.
+- Is the system applying DDD where it's warranted? (Complex domain logic, multiple teams, long-lived system) Or is it over-engineering CRUD?
+
+## Entity & Value Object Check
+
+- Do domain objects have identity (ID field) that persists across state changes? If yes, they are Entities.
+- Are domain objects defined purely by their attributes (money, address, date range)? If yes, they are Value Objects.
+- Are entities being compared by value when they should be compared by ID?
+- Are value objects being given IDs when they should be immutable and interchangeable?
+- Are value objects actually immutable? (No setters, no mutation methods)
+
+## Aggregate Check
+
+- Is there a clear aggregate root that controls access to child entities?
+- Are child entities being accessed directly (bypassing the root)? This breaks aggregate invariants.
+- Does the aggregate enforce its invariants (validation, state transitions)?
+- Are aggregates too large? (>5 entities suggests decomposition needed)
+- Are aggregates being loaded in full when only a subset is needed? (Performance smell)
+- Do transactions span multiple aggregates? (Design smell — aggregates should be consistency boundaries)
+
+## Domain Event Check
+
+- Are significant state changes published as domain events?
+- Do event names use past tense and domain language? (`OrderPlaced`, not `HandleOrder`)
+- Are events immutable once published?
+- Is there a clear distinction between domain events (within bounded context) and integration events (across contexts)?
+
+## Naming Review
+
+| Signal | Issue | Severity |
+|--------|-------|----------|
+| Generic names: `Service`, `Manager`, `Handler`, `Processor` | Missing domain language | medium |
+| Technical names in domain layer: `UserDTO`, `OrderRepository` | Infrastructure leaking into domain | medium |
+| Inconsistent naming: `Customer` in one module, `Client` in another for same concept | Missing ubiquitous language | high |
+| Verb-only names: `validate`, `process`, `handle` without domain qualifier | Ambiguous responsibility | medium |
+| Pluralization confusion: `Order` entity vs `Orders` service vs `OrderList` collection | No naming convention | low |
+
+## Repository Pattern Check
+
+- Do repositories return domain objects (not database rows/DTOs)?
+- Is the repository interface in the domain layer, implementation in infrastructure?
+- Are queries filtering by domain concepts (not SQL/table structure)?
+- Is there one repository per aggregate root? (Not per entity or per table)
+
+## Strategic DDD Red Flags
+
+| Signal | Issue | Severity |
+|--------|-------|----------|
+| Universal data model shared across all modules | Missing bounded contexts | high |
+| One "User" type used everywhere with 30+ fields | Context-specific models needed | high |
+| Tactical patterns (Aggregates, Value Objects) without strategic boundaries | Cargo-culting DDD | medium |
+| No ubiquitous language — developers and domain experts use different terms | Core DDD principle violated | high |

package/expertise/digests/reviewer/dependency-risk-digest.md

@@ -0,0 +1,40 @@
+# Dependency Risk — Reviewer Digest
+
+> Detection-focused extract for reviewer context. For full analysis, see `antipatterns/code/dependency-antipatterns.md`.
+
+## Dependency Antipatterns
+
+| Antipattern | Detection Signal | Severity |
+|-------------|-----------------|----------|
+| **Trivial Dependency (Left-Pad)** | Package imported for one utility function achievable in <10 lines | medium |
+| **Phantom Dependency** | Import resolves at dev time but not in production (missing from package.json `dependencies`) | critical |
+| **Version Range Roulette** | `"*"` or `"latest"` or overly broad ranges (`^0.x`) in package.json | high |
+| **Dependency Confusion** | Internal package name collides with public registry name; no scoped namespace | critical |
+| **Typosquatting Risk** | Package name is one character off from a popular package | high |
+| **Circular Dependency** | A imports B imports C imports A | high |
+| **Diamond Dependency** | Two deps require incompatible versions of a shared transitive dep | high |
+| **Stale Lock File** | package-lock.json / yarn.lock not updated after package.json change | medium |
+| **Dev Dependency in Production** | devDependency imported in src/ code | high |
+| **Unused Dependency** | Package in package.json but no import found in src/ | low |
+| **Deprecated API Usage** | Calling APIs marked @deprecated in the dependency | medium |
+| **Tightly Coupled to Dependency** | Dependency's types/interfaces leak through public API | medium |
+| **Unmaintained Dependency** | No commits in 12+ months, unresolved security advisories | medium |
+| **License Incompatibility** | Dependency license conflicts with project license (e.g., GPL in MIT project) | high |
+| **Transitive Bloat** | Adding one dependency pulls in 100+ transitive deps | medium |
+
+## Import Health Checks
+
+- Every `import` or `require` resolves to an installed package or local file
+- No circular import chains (check with `madge --circular`)
+- Lock file is consistent with package.json
+- No `node_modules` path imports (e.g., `require('pkg/node_modules/sub')`)
+- No relative imports escaping package boundaries (e.g., `../../other-package/src/`)
+
+## New Dependency Evaluation
+
+When a PR adds a new dependency, check:
+1. **Necessity:** Can the functionality be achieved in <20 lines without the dep?
+2. **Health:** Last publish date, open issues ratio, known CVEs
+3. **Size:** What is the install footprint? (check `bundlephobia` or `packagephobia`)
+4. **License:** Compatible with project license?
+5. **Alternatives:** Is there a lighter or more maintained alternative?

package/expertise/digests/reviewer/error-handling-digest.md

@@ -0,0 +1,55 @@
+# Error Handling — Reviewer Digest
+
+> Detection-focused extract for reviewer context. For full analysis, see `antipatterns/code/error-handling-antipatterns.md`.
+
+## Error Handling Antipatterns
+
+| Antipattern | Detection Signal | Severity |
+|-------------|-----------------|----------|
+| **Pokemon Exception (AP-01)** | `catch(Exception e)` / `catch(e) {}` catching everything without discrimination | critical |
+| **Swallowed Exception (AP-02)** | Empty catch block, or catch that only logs without re-throwing or recovering | high |
+| **Exception as Flow Control (AP-03)** | Using try/catch for expected conditions (not found, validation failure, empty input) | medium |
+| **Incomplete Error Handling (AP-04)** | Handling some error cases but not others from the same operation | high |
+| **Missing Async Error Handling (AP-05)** | `await` without try/catch or `.catch()`; unhandled promise rejections | high |
+| **Re-throw Without Context (AP-06)** | `catch(e) { throw e }` losing stack/context information; no wrapping | medium |
+| **Error String Matching (AP-07)** | `if (error.message.includes('not found'))` instead of typed error classes | medium |
+| **Silent Failure (AP-08)** | Function returns null/undefined on error with no indication to caller | high |
+| **Inconsistent Error Types (AP-09)** | Same module throws Error, string, object, and number | medium |
+| **Missing Error Boundary (AP-10)** | UI component tree can crash entirely from one child component error | high |
+| **Retry Without Backoff (AP-11)** | Retrying failed operations in a tight loop without exponential backoff | high |
+| **Logging Without Acting (AP-12)** | `catch(e) { logger.error(e) }` — logged but no recovery, no re-throw, no alert | high |
+| **Overly Broad Recovery (AP-13)** | Catch block returns a default value for ALL errors, masking different failure modes | high |
+| **Missing Cleanup (AP-14)** | Resources (file handles, DB connections, locks) not released in error paths | high |
+| **User-Facing Stack Traces (AP-15)** | Error responses include internal stack traces, file paths, or SQL queries | high (security) |
+| **Missing Correlation ID (AP-16)** | Errors logged without request/trace ID, making debugging across services impossible | medium |
+
+## Async Error Patterns
+
+- Every `await` should be in a try/catch or the promise should have `.catch()`
+- `Promise.all` should handle partial failures (use `Promise.allSettled` if appropriate)
+- Event handlers and callbacks should have error handling
+- Stream/iterator error events should be subscribed to
+- Async generators should handle `throw()` method calls
+
+## Error Propagation Check
+
+- Do errors propagate upward with context added at each layer?
+- Is there a top-level error handler (global catch, error middleware, process.on('unhandledRejection'))?
+- Are user-facing error messages sanitized (no stack traces, no internal details)?
+- Are errors logged with correlation IDs for tracing?
+- Do error responses use consistent format (error code + message + optional details)?
+
+## Transaction & State Consistency
+
+- Are multi-step mutations wrapped in transactions?
+- If a step fails mid-operation, is partial state rolled back or compensated?
+- Are idempotency keys used for operations that might be retried?
+- Do constructors/initializers validate invariants, or can objects be created in invalid state?
+
+## Resource Cleanup Checklist
+
+- File handles: opened in try, closed in finally
+- Database connections: returned to pool in finally
+- Locks/mutexes: released in finally
+- Temporary files: deleted in finally
+- Event listeners: removed in cleanup/dispose

package/expertise/digests/reviewer/review-methodology-digest.md

@@ -0,0 +1,49 @@
+# Code Review Methodology — Reviewer Digest
+
+> Detection-focused extract for reviewer context. For full analysis, see `antipatterns/process/code-review-antipatterns.md`.
+
+## Reviewer Antipatterns to Avoid
+
+| Antipattern | Signal You're Doing It | Correction |
+|-------------|----------------------|------------|
+| **Rubber Stamping (AP-01)** | All passes clean with no findings | Every diff has something worth noting. Look harder. |
+| **Nitpick Focus (AP-02)** | >50% of findings are style/formatting | Rebalance: logic > structure > style |
+| **Too-Late Review (AP-03)** | Raising architectural objections after full implementation | Review early artifacts (spec, design, plan) when available |
+| **Scope Creep (AP-04)** | Suggesting features/refactors outside the diff | Review what changed. File issues for what should change next. |
+| **Severity Inflation (AP-05)** | Everything is "blocking" | Reserve blocking for: security, data loss, crash, wrong behavior. |
+| **Severity Deflation (AP-06)** | Nothing is "blocking" despite clear bugs | If it would break in production, it's blocking. Period. |
+| **Confirmation Bias (AP-07)** | Checking "did they follow the plan" not "does it work" | Test against the spec, not the approach. |
+| **Anchoring (AP-08)** | Prior review pass findings anchoring this pass | Each pass is independent. Re-read the diff fresh. |
+| **Inconsistent Standards (AP-09)** | Different quality bar for different authors or modules | Apply the same severity criteria uniformly across the codebase. |
+| **Review by Checklist Only (AP-10)** | Mechanically checking boxes without reading logic | Checklists supplement deep reading, they don't replace it. |
+
+## Severity Calibration
+
+| Severity | Criteria | Examples |
+|----------|----------|---------|
+| **blocking** | Would cause incorrect behavior, data loss, security vulnerability, or crash in production | Missing auth check, SQL injection, unhandled null, wrong business logic |
+| **warning** | Degrades quality but does not break correctness | Missing error message, poor naming, missing test for edge case |
+| **note** | Improvement opportunity, style preference, or observation | Alternative approach suggestion, documentation gap, minor duplication |
+
+## Dimension Coverage Discipline
+
+- Score EVERY assigned dimension, even if it passes cleanly
+- A dimension with no findings gets score 10 with brief justification
+- Never skip a dimension because "it looks fine" — that is rubber stamping
+- Findings must reference specific file:line locations
+
+## Review Pass Independence
+
+- Each review pass is a fresh evaluation — do not anchor on previous pass findings
+- Re-read the diff from scratch on each pass
+- If a prior finding was fixed, verify the fix independently (don't assume it's correct)
+- Track pass numbers explicitly: pass 1 of N, pass 2 of N
+
+## Finding Quality Checklist
+
+Each finding must have:
+1. **Location:** file path and line number(s)
+2. **Severity:** blocking / warning / note
+3. **Dimension:** which review dimension it belongs to
+4. **Description:** what the issue is and why it matters
+5. **Source tag:** `[Internal]`, `[Codex]`, or `[Both]`

package/exports/hosts/claude/.claude/commands/learn.md

@@ -2,37 +2,90 @@
 
 ## Purpose
 
-Extract durable scoped learnings and experiments from the completed run.
+Extract durable scoped learnings from the completed run using the 4-stage promotion pipeline.
 
 ## Phase entry
 
 On entering this phase, run:
-`wazir capture event --run <run-id> --event phase_enter --phase <phase-name> --status in_progress`
+`wazir capture event --run <run-id> --event phase_enter --phase learn --status in_progress`
 
 ## Inputs
 
 - run artifacts
-- review findings
+- review findings (all passes, all tiers)
 - verification proof
 
 ## Primary Role
 
 - `learner`
 
+## Pipeline Stages
+
+The learning pipeline follows a 4-stage promotion model (Tally → Candidate → Promote → Active):
+
+### Stage 1: TALLY (Automatic)
+
+Every finding from the run is:
+1. Canonicalized (file paths, line numbers, identifiers stripped)
+2. Hashed for dedup
+3. Clustered by semantic similarity in `finding_clusters` table
+4. Category-tagged (from the reviewer's finding category)
+
+Also:
+- Read `.wazir/runs/<id>/decisions.ndjson` for recurring patterns
+- Append summary to `memory/findings/cumulative-findings.md`
+
+Implementation: `tooling/src/learn/pipeline.js` → `tallyFinding()`
+
+### Stage 2: CANDIDATE (Automatic)
+
+Clusters meeting the promotion threshold are flagged:
+- **Occurrence threshold:** 3+ findings with the same canonical pattern
+- **Run threshold:** Pattern must appear across 2+ distinct runs
+- **Drift cap:** No promotion if active antipatterns count >= 30
+
+Implementation: `tooling/src/learn/pipeline.js` → `identifyCandidates()` + `promoteToCandidates()`
+
+### Stage 3: PROMOTE (Human Gate)
+
+Candidates are proposed for user review:
+- Written to `memory/learnings/proposed/<run-id>-<NNN>.md`
+- User reviews and accepts/rejects via `/wazir audit learnings`
+- Accepted candidates move to `status: accepted` in `antipattern_candidates` table
+
+### Stage 4: ACTIVE (Automatic)
+
+Accepted antipatterns are loaded into reviewer context for future runs:
+- Injected as project-level learnings alongside expertise modules
+- Hit-rate tracked: if an antipattern triggers in <5% of runs over 90 days, it's demoted
+- Max 30 active project-level antipatterns (drift prevention)
+
+## Drift Prevention
+
+- **Cap:** 30 active project antipatterns maximum
+- **TTL:** 90-day expiry on unreviewed candidates
+- **Demotion:** Antipatterns with <5% hit rate over 90 days are auto-demoted
+- **Consolidation:** When count exceeds 25, similar antipatterns are merged
+
 ## Outputs
 
-- proposed learning artifacts
-- experiment summaries
+- Tallied findings in `finding_clusters` table
+- Promoted candidates in `antipattern_candidates` table
+- Proposed learning artifacts in `memory/learnings/proposed/`
+- Cumulative findings appended to `memory/findings/cumulative-findings.md`
 
 ## Approval Gate
 
-- accepted learnings require explicit review and scope tags
+- Accepted learnings require explicit user review and scope tags
+- Learnings are NEVER auto-applied to future runs without user acceptance
 
 ## Phase exit
 
 On completing this phase, run:
-`wazir capture event --run <run-id> --event phase_exit --phase <phase-name> --status completed`
+`wazir capture event --run <run-id> --event phase_exit --phase learn --status completed`
 
 ## Failure Conditions
 
-- auto-applied learning drift
+- auto-applied learning drift (bypassing human gate)
+- candidate count exceeds cap without consolidation
+- stale candidates not expired

package/exports/hosts/claude/.claude/commands/plan-review.md

@@ -39,7 +39,9 @@ On completing this phase, run:
 
 ## Loop Structure
 
-Follows the review loop pattern in `docs/reference/review-loop-pattern.md` with plan dimensions. The planner role resolves findings. Pass count determined by depth. No extension.
+Follows the review loop pattern in `docs/reference/review-loop-pattern.md` with 8 plan dimensions (including Input Coverage). The planner role resolves findings. Pass count determined by depth. No extension.
+
+**Input Coverage dimension:** The reviewer reads the original input/briefing, counts distinct items, and compares against tasks in the plan. If `tasks_in_plan < items_in_input`, this is a HIGH finding listing the missing items. This prevents silent scope reduction where 21 input items become 5 tasks.
 
 ## Failure Conditions
 

package/exports/hosts/claude/.claude/commands/verify.md

@@ -14,6 +14,16 @@ On entering this phase, run:
 - changed files
 - claimed outcomes
 - acceptance criteria
+- project type (detected via `detectRunnableType(projectRoot)` → web | api | cli | library, from `tooling/src/verify/proof-collector.js`)
+
+## Process
+
+1. **Detect project type:** Run `detectRunnableType(projectRoot)` to determine verification strategy
+2. **Collect evidence:** Run `collectProof(taskSpec, runConfig)` with the detected type
+3. **For runnable output (web/api/cli):** Run the application and capture runtime evidence (build output, screenshots, curl responses, CLI output)
+4. **For non-runnable output (library/config/skills):** Run lint, format check, type check, and tests — all must pass
+5. **Save evidence:** Write to `.wazir/runs/<id>/artifacts/proof-<task>.json`
+6. **Validate:** Ensure every acceptance criterion has at least one evidence item mapped to it
 
 ## Primary Role
 
@@ -21,7 +31,11 @@ On entering this phase, run:
 
 ## Outputs
 
-- verification proof artifact
+- verification proof artifact (produced by `collectProof` from `tooling/src/verify/proof-collector.js`)
+
+## Proof Collection
+
+Use `detectRunnableType` to classify the project, then `collectProof` to gather evidence. The proof-collector runs type-appropriate commands (build, test, lint, type-check) using `execFileSync` and returns structured `{ type, evidence }`.
 
 ## Approval Gate
 
@@ -32,6 +46,19 @@ On entering this phase, run:
 On completing this phase, run:
 `wazir capture event --run <run-id> --event phase_exit --phase <phase-name> --status completed`
 
+## Proof of Implementation
+
+The verifier detects whether the project output is runnable and collects appropriate evidence:
+
+| Project Type | Detection | Evidence Collected |
+|-------------|-----------|-------------------|
+| `web` | next/vite/react-scripts in deps | Build output, Playwright screenshot (if available), curl response |
+| `api` | express/fastify/hono in deps | curl endpoint responses with status codes |
+| `cli` | `bin` field in package.json | `--help` output, test run with sample args |
+| `library` | default (no runnable markers) | npm test, tsc, eslint, prettier — all must pass |
+
+Evidence is saved to `.wazir/runs/<id>/artifacts/proof-<task>.json` using `collectProof()` from `tooling/src/verify/proof-collector.js`.
+
 ## Relationship to Review Loops
 
 Verification is invoked per-task during execution, not as a review loop. It produces deterministic proof, not adversarial findings.
@@ -39,3 +66,5 @@ Verification is invoked per-task during execution, not as a review loop. It prod
 ## Failure Conditions
 
 - stale or partial verification
+- proof-collector reports `status: "fail"` for any evidence item
+- runnable type detected but no evidence collected

package/exports/hosts/claude/.claude/settings.json

@@ -1,21 +1,22 @@
 {
   "hooks": {
-    "PreToolUse": [
+    "Stop": [
       {
-        "matcher": "Write|Edit",
         "hooks": [
           {
             "type": "command",
-            "command": "./hooks/protected-path-write-guard"
+            "command": "./hooks/stop-pipeline-gate"
           }
         ]
-      },
+      }
+    ],
+    "PreToolUse": [
       {
-        "matcher": "Bash",
+        "matcher": "Write|Edit|Bash",
         "hooks": [
           {
             "type": "command",
-            "command": "./hooks/context-mode-router"
+            "command": "./hooks/pretooluse-dispatcher"
           }
         ]
       }

package/exports/hosts/claude/export.manifest.json

@@ -1,7 +1,7 @@
 {
   "host": "claude",
   "source_hashes": {
-    "wazir.manifest.yaml": "f00776eb08ed3332b8f855001a2fd0b866cd0b81d009c6fbb316149c398c51ca",
+    "wazir.manifest.yaml": "48a188248faf429807b241eb57fbb99afae3c6ddfdf71b24c5c532ca0bc2d33f",
     "roles/clarifier.md": "1e1b8a2c05f1070fdcef485963cfcbffff62c4b2703a8d73fe51ac52d056e573",
     "roles/content-author.md": "cc20b80bd70ab68b3239a9cf56bf1ffc2c06843d38afc6b190844b35a1d73c3e",
     "roles/designer.md": "76cff5bda82975cfb4074de71681e7c8ba284e2e49d0cc98f90208642fef74fc",
@@ -18,23 +18,26 @@
     "workflows/design.md": "7f69758b22f88c12d16846ac1dd444f4e178ab116559ef9f2f26f6daa1a10d62",
     "workflows/discover.md": "0696add486f739a46ed4c2b71b67bdda3ab9fea2d1395e662191282529ed21d2",
     "workflows/execute.md": "33428704476877b2c8cf34c6eda3a56d1fd71e8bbea0f05c122bb3da2c6475a6",
-    "workflows/learn.md": "9b1955a00eb0ea47af08a3639c3cbc2f15b8eab6cc02127e829bc8c83b0a52b5",
-    "workflows/plan-review.md": "8696c472cb4605a171fd4ac8a9c51b7cf337807c4881ed163515dc56e61fd818",
+    "workflows/learn.md": "450bbfbfaa9143365284e13c608f800e94caea47210c57d252d1c9a720160035",
+    "workflows/plan-review.md": "1dfe76dfe4fd9c32409d508e47654ad3b985b5429bd4616adde719b19fd606ac",
     "workflows/plan.md": "fd52737159ab13688af8cbcb1c3fa224b1a9dda441b9ab337ab98cbfb5c68fa5",
     "workflows/prepare-next.md": "8769b692be6d9fddf3b3f36fee6888159fb9fb2a5c31360cdbc9402e0f43fc27",
     "workflows/review.md": "aaeaf7ab4515e325084a77e75e18b325295f8d16799f71f8b7cd0ec67c52c0d6",
     "workflows/run-audit.md": "e582f767967dc3fb6aaeb938ad1672e7bed18bf044055ce8c45c2114251b787a",
     "workflows/spec-challenge.md": "dc99137c28c49a6f8312924709afb6077754d128e90466dc911150ce15737897",
     "workflows/specify.md": "53b84e74871f6dbd93cae22a881cc5907e398b29501d0a1fa08c7ed69df705cb",
-    "workflows/verify.md": "45f9c189520dfe9d24c0bc340a15e6a80c988fca1b84dc187627032a6dbaee16",
+    "workflows/verify.md": "4eff7b9b1c94b9a2c4a6f65cae076a3cd5a278a86430109b6033cd958e1e8ab8",
     "hooks/definitions/context_mode_router.yaml": "a10dc927418bc130b447eb33faf0f45669ecd9c7917f56947ddd74850a4e0e37",
     "hooks/definitions/loop_cap_guard.yaml": "f0fd220e028ab6fad3d8fd650602884fe500ca4899eff6e428cf217af058618d",
     "hooks/definitions/post_tool_capture.yaml": "a773cd6e18972dee8eef3b7cb06fd1d319a71de4588897cebfbe643f6781a3b2",
     "hooks/definitions/pre_compact_summary.yaml": "daa0175d79f3e0127c5ce86a7a2f8df0be3f58b5c94fe749da715a17c7b2d04e",
     "hooks/definitions/pre_tool_capture_route.yaml": "3c2663380ff3cd09f09de5b96bcf6123266fa74d8a03dfb2d6fbe40a43fb13cf",
+    "hooks/definitions/pretooluse_dispatcher.yaml": "5b0646ab17704e6f4665bb4c08ead5bcfe2aa6e71395fa5694cb0debcbce69da",
+    "hooks/definitions/pretooluse_pipeline_guard.yaml": "ac89617b91093ff0a39da0e8c48affbcaa71054666fa316a42c32f73f656ae69",
     "hooks/definitions/protected_path_write_guard.yaml": "6683d41778b823e2a4e606065597569aa04363f091e135e165de9732f1fc2171",
     "hooks/definitions/session_start.yaml": "9383fcf1f8304c87e57726478a461706c0fc73dc62bcc4d8661f2eeffa43a82d",
     "hooks/definitions/stop_handoff_harvest.yaml": "67a3c0a8bb7cb66b88e77dc79e748082e964d278c47935662c453922a846482b",
-    "hooks/hooks.json": "f255345793951b5cf6f6d8c9a8b6a6ad2d3140023453410127a6f70d8e110c26"
+    "hooks/definitions/stop_pipeline_gate.yaml": "f27dde7605809aae56ac566b93b8692f5d40db1e11b569010e32d2878b677fcf",
+    "hooks/hooks.json": "65e022a151aa9546a6988581ee62ec853f0df5580aeed4b164e3ccc3dc2e72de"
   }
 }

package/exports/hosts/claude/host-package.json

@@ -32,9 +32,12 @@
     "hooks/definitions/post_tool_capture.yaml",
     "hooks/definitions/pre_compact_summary.yaml",
     "hooks/definitions/pre_tool_capture_route.yaml",
+    "hooks/definitions/pretooluse_dispatcher.yaml",
+    "hooks/definitions/pretooluse_pipeline_guard.yaml",
     "hooks/definitions/protected_path_write_guard.yaml",
     "hooks/definitions/session_start.yaml",
     "hooks/definitions/stop_handoff_harvest.yaml",
+    "hooks/definitions/stop_pipeline_gate.yaml",
     "hooks/hooks.json"
   ],
   "files": [

package/exports/hosts/codex/export.manifest.json

@@ -1,7 +1,7 @@
 {
   "host": "codex",
   "source_hashes": {
-    "wazir.manifest.yaml": "f00776eb08ed3332b8f855001a2fd0b866cd0b81d009c6fbb316149c398c51ca",
+    "wazir.manifest.yaml": "48a188248faf429807b241eb57fbb99afae3c6ddfdf71b24c5c532ca0bc2d33f",
     "roles/clarifier.md": "1e1b8a2c05f1070fdcef485963cfcbffff62c4b2703a8d73fe51ac52d056e573",
     "roles/content-author.md": "cc20b80bd70ab68b3239a9cf56bf1ffc2c06843d38afc6b190844b35a1d73c3e",
     "roles/designer.md": "76cff5bda82975cfb4074de71681e7c8ba284e2e49d0cc98f90208642fef74fc",
@@ -18,23 +18,26 @@
     "workflows/design.md": "7f69758b22f88c12d16846ac1dd444f4e178ab116559ef9f2f26f6daa1a10d62",
     "workflows/discover.md": "0696add486f739a46ed4c2b71b67bdda3ab9fea2d1395e662191282529ed21d2",
     "workflows/execute.md": "33428704476877b2c8cf34c6eda3a56d1fd71e8bbea0f05c122bb3da2c6475a6",
-    "workflows/learn.md": "9b1955a00eb0ea47af08a3639c3cbc2f15b8eab6cc02127e829bc8c83b0a52b5",
-    "workflows/plan-review.md": "8696c472cb4605a171fd4ac8a9c51b7cf337807c4881ed163515dc56e61fd818",
+    "workflows/learn.md": "450bbfbfaa9143365284e13c608f800e94caea47210c57d252d1c9a720160035",
+    "workflows/plan-review.md": "1dfe76dfe4fd9c32409d508e47654ad3b985b5429bd4616adde719b19fd606ac",
     "workflows/plan.md": "fd52737159ab13688af8cbcb1c3fa224b1a9dda441b9ab337ab98cbfb5c68fa5",
     "workflows/prepare-next.md": "8769b692be6d9fddf3b3f36fee6888159fb9fb2a5c31360cdbc9402e0f43fc27",
     "workflows/review.md": "aaeaf7ab4515e325084a77e75e18b325295f8d16799f71f8b7cd0ec67c52c0d6",
     "workflows/run-audit.md": "e582f767967dc3fb6aaeb938ad1672e7bed18bf044055ce8c45c2114251b787a",
     "workflows/spec-challenge.md": "dc99137c28c49a6f8312924709afb6077754d128e90466dc911150ce15737897",
     "workflows/specify.md": "53b84e74871f6dbd93cae22a881cc5907e398b29501d0a1fa08c7ed69df705cb",
-    "workflows/verify.md": "45f9c189520dfe9d24c0bc340a15e6a80c988fca1b84dc187627032a6dbaee16",
+    "workflows/verify.md": "4eff7b9b1c94b9a2c4a6f65cae076a3cd5a278a86430109b6033cd958e1e8ab8",
     "hooks/definitions/context_mode_router.yaml": "a10dc927418bc130b447eb33faf0f45669ecd9c7917f56947ddd74850a4e0e37",
     "hooks/definitions/loop_cap_guard.yaml": "f0fd220e028ab6fad3d8fd650602884fe500ca4899eff6e428cf217af058618d",
     "hooks/definitions/post_tool_capture.yaml": "a773cd6e18972dee8eef3b7cb06fd1d319a71de4588897cebfbe643f6781a3b2",
     "hooks/definitions/pre_compact_summary.yaml": "daa0175d79f3e0127c5ce86a7a2f8df0be3f58b5c94fe749da715a17c7b2d04e",
     "hooks/definitions/pre_tool_capture_route.yaml": "3c2663380ff3cd09f09de5b96bcf6123266fa74d8a03dfb2d6fbe40a43fb13cf",
+    "hooks/definitions/pretooluse_dispatcher.yaml": "5b0646ab17704e6f4665bb4c08ead5bcfe2aa6e71395fa5694cb0debcbce69da",
+    "hooks/definitions/pretooluse_pipeline_guard.yaml": "ac89617b91093ff0a39da0e8c48affbcaa71054666fa316a42c32f73f656ae69",
     "hooks/definitions/protected_path_write_guard.yaml": "6683d41778b823e2a4e606065597569aa04363f091e135e165de9732f1fc2171",
     "hooks/definitions/session_start.yaml": "9383fcf1f8304c87e57726478a461706c0fc73dc62bcc4d8661f2eeffa43a82d",
     "hooks/definitions/stop_handoff_harvest.yaml": "67a3c0a8bb7cb66b88e77dc79e748082e964d278c47935662c453922a846482b",
-    "hooks/hooks.json": "f255345793951b5cf6f6d8c9a8b6a6ad2d3140023453410127a6f70d8e110c26"
+    "hooks/definitions/stop_pipeline_gate.yaml": "f27dde7605809aae56ac566b93b8692f5d40db1e11b569010e32d2878b677fcf",
+    "hooks/hooks.json": "65e022a151aa9546a6988581ee62ec853f0df5580aeed4b164e3ccc3dc2e72de"
   }
 }

package/exports/hosts/codex/host-package.json

@@ -32,9 +32,12 @@
     "hooks/definitions/post_tool_capture.yaml",
     "hooks/definitions/pre_compact_summary.yaml",
     "hooks/definitions/pre_tool_capture_route.yaml",
+    "hooks/definitions/pretooluse_dispatcher.yaml",
+    "hooks/definitions/pretooluse_pipeline_guard.yaml",
     "hooks/definitions/protected_path_write_guard.yaml",
     "hooks/definitions/session_start.yaml",
     "hooks/definitions/stop_handoff_harvest.yaml",
+    "hooks/definitions/stop_pipeline_gate.yaml",
     "hooks/hooks.json"
   ],
   "files": [