@harness-engineering/cli 1.26.1 → 1.27.1

package/dist/agents/skills/claude-code/cleanup-dead-code/SKILL.md

@@ -26,7 +26,9 @@
 
 2. **Run `harness cleanup --type dead-code --json`** for machine-readable output focused specifically on unused code.
 
-3. **Review the report summary.** Note the total count and distribution. A few dead exports are normal; dozens suggest accumulated entropy from incomplete refactorings.
+3. **Check for stale constraints.** Run `detect_stale_constraints` to identify architectural constraints referencing removed code that should also be cleaned up.
+
+4. **Review the report summary.** Note the total count and distribution. A few dead exports are normal; dozens suggest accumulated entropy from incomplete refactorings.
 
 ### Graph-Enhanced Context (when available)
 

package/dist/agents/skills/claude-code/detect-doc-drift/SKILL.md

@@ -20,7 +20,9 @@
 
 2. **Run `harness cleanup --type drift`** for a deeper analysis that cross-references code changes against documentation references.
 
-3. **Optionally, run `git diff` against a baseline** (last release, last sprint, etc.) to identify which code files changed. This helps prioritize — docs for recently changed files are most likely to be drifted.
+3. **Check for stale constraints.** Run `detect_stale_constraints` alongside drift detection to find architectural constraints that no longer match the codebase.
+
+4. **Optionally, run `git diff` against a baseline** (last release, last sprint, etc.) to identify which code files changed. This helps prioritize — docs for recently changed files are most likely to be drifted.
 
 ### Graph-Enhanced Context (when available)
 

package/dist/agents/skills/claude-code/harness-architecture-advisor/SKILL.md

@@ -53,6 +53,10 @@ Store answers in: .harness/architecture/<topic>/discovery.md
 
 Read the codebase to understand the current state. Do not propose solutions yet — gather facts.
 
+#### Step 0: Discover Constraints and Trends
+
+Run `detect_constraint_emergence` to discover implicit architectural patterns that should be formalized as constraints. Run `detect_stale_constraints` to identify constraints that no longer apply or need updating. Check `get_decay_trends` to understand how architectural health has evolved and which areas are degrading fastest. Run `predict_failures` to forecast which constraints are most likely to be violated based on current trends.
+
 #### Step 1: Map Existing Patterns
 
 Search for how the codebase currently handles similar concerns:

package/dist/agents/skills/claude-code/harness-autopilot/SKILL.md

@@ -12,12 +12,13 @@
 
 ## Persona Agents
 
-| Skill                | `subagent_type`         | State(s)             |
-| -------------------- | ----------------------- | -------------------- |
-| harness-planning     | `harness-planner`       | PLAN                 |
-| harness-execution    | `harness-task-executor` | EXECUTE              |
-| harness-verification | `harness-verifier`      | VERIFY               |
-| harness-code-review  | `harness-code-reviewer` | REVIEW, FINAL_REVIEW |
+| Skill                   | `subagent_type`         | State(s)             |
+| ----------------------- | ----------------------- | -------------------- |
+| harness-planning        | `harness-planner`       | PLAN                 |
+| harness-execution       | `harness-task-executor` | EXECUTE              |
+| harness-verification    | `harness-verifier`      | VERIFY               |
+| **harness-integration** | **`harness-verifier`**  | **INTEGRATE**        |
+| harness-code-review     | `harness-code-reviewer` | REVIEW, FINAL_REVIEW |
 
 **Iron Law:** Autopilot delegates, never reimplements. If writing plan/execute/verify/review logic, STOP — delegate via `subagent_type`. Always use dedicated persona agents, never general-purpose agents.
 
@@ -31,15 +32,16 @@ Set at INIT (`--fast` / `--thorough`); persists for session. Default: `standard`
 | APPROVE_PLAN | Auto-approve, skip signals | Signal-based          | Force human review            |
 | EXECUTE      | Skip scratchpad            | Scratchpad >500 words | Verbose scratchpad            |
 | VERIFY       | `harness validate` only    | Full pipeline         | Expanded checks               |
+| INTEGRATE    | WIRE only, auto-approve    | Full tier-appropriate | Full + human ADR review       |
 
 ## State Machine
 
 ```
-INIT → ASSESS → PLAN → APPROVE_PLAN → EXECUTE → VERIFY → REVIEW → PHASE_COMPLETE
-                                                                    │
-                                                             [next phase?]
-                                                              │           │
-                                                           ASSESS   FINAL_REVIEW → DONE
+INIT → ASSESS → PLAN → APPROVE_PLAN → EXECUTE → VERIFY → INTEGRATE → REVIEW → PHASE_COMPLETE
+                                                                                  │
+                                                                           [next phase?]
+                                                                            │           │
+                                                                         ASSESS   FINAL_REVIEW → DONE
 ```
 
 ---
@@ -51,7 +53,7 @@ INIT → ASSESS → PLAN → APPROVE_PLAN → EXECUTE → VERIFY → REVIEW →
 3. Check for existing state: read `{sessionDir}/autopilot-state.json`. If present and not DONE: report "Resuming from `{currentState}`, phase {N}: {name}." Apply schema migration if `schemaVersion < 5` (backfill missing fields). Jump to recorded state.
 4. Fresh start: read spec, parse `## Implementation Order` for phases (`### Phase N: Name` + `<!-- complexity: low|medium|high -->`, default: `medium`). Capture `startingCommit` via `git rev-parse HEAD`. Write `autopilot-state.json` (schemaVersion: 5, currentState: "ASSESS", currentPhase: 0).
 5. Flags: `--fast` → `rigorLevel: "fast"`. `--thorough` → `rigorLevel: "thorough"`. `--review-plans` → `reviewPlans: true`. Both flags together → reject with error.
-6. Call `gather_context({ path, skill: "harness-autopilot", session: slug, include: ["state", "learnings", "handoff", "validation"] })`.
+6. Call `gather_context({ path, skill: "harness-autopilot", session: slug, include: ["state", "learnings", "handoff", "graph", "businessKnowledge", "sessions", "validation"] })`.
 7. → ASSESS.
 
 ---
@@ -60,10 +62,15 @@ INIT → ASSESS → PLAN → APPROVE_PLAN → EXECUTE → VERIFY → REVIEW →
 
 1. Read current phase at `currentPhase`.
 2. If `planPath` set and file exists: → APPROVE_PLAN.
-3. Complexity routing:
+3. **Intelligence-enhanced complexity assessment.** Before routing by complexity, refine the annotation with signals from available tools:
+   - Run `predict_failures` on the phase domain to check if constraints are trending toward violation — high failure probability suggests upgrading complexity.
+   - Run `compute_blast_radius` on files the phase is likely to touch — large blast radius (>15 affected modules) suggests upgrading to `high`.
+   - If the orchestrator is running, request intelligence analysis via `POST /api/analyze` with the phase title/description to get CML complexity scores and PESL simulation results. Use CML `structuralComplexity > 0.7` or PESL `riskScore > 0.6` as triggers to upgrade complexity routing.
+   - If no orchestrator, the MCP tool signals above are sufficient.
+4. Complexity routing:
    - `low`/`medium`: auto-plan via harness-planner → PLAN.
    - `high`: pause. Instruct: "Run `/harness:planning` interactively, then re-invoke `/harness:autopilot`." Wait for re-invocation.
-4. Update `currentState: "PLAN"`.
+5. Update `currentState: "PLAN"`.
 
 ---
 
@@ -93,6 +100,7 @@ On return: read `planPath` from `{sessionDir}/handoff.json`. Complexity override
    - `phase.complexityOverride !== null`
    - Handoff `concerns` non-empty
    - Task count > 15
+   - Knowledge gaps: `harness knowledge-pipeline --domain <phase-domain>` reports `totalGaps > 0` and `--fix` was not run during planning
 5. **Auto-approve:** emit report (mode, complexity, concerns, task count). Record decision with signal snapshot in `decisions[]`. → EXECUTE.
 6. **Pause:** show triggered signals. Ask "Approve? (yes / revise / skip phase / stop)." Record decision. Route accordingly.
 
@@ -120,13 +128,34 @@ prompt: "Phase {N}: {name}. Plan: {planPath}. Session: {sessionSlug}. Rigor: {ri
 
 ### VERIFY
 
-- `"fast"`: run `harness validate`. Pass → REVIEW. Fail → surface to user.
+- `"fast"`: run `harness validate`. Pass → INTEGRATE. Fail → surface to user.
 - `"standard"`/`"thorough"`: dispatch harness-verifier:
   ```
   subagent_type: "harness-verifier"
   prompt: "Phase {N}: {name}. Session: {sessionSlug}. Rigor: {rigorLevel}. Verify and report pass/fail with findings."
   ```
-  Pass → REVIEW. Fail → ask "fix / skip verification / stop." `fix`: re-enter EXECUTE (retry budget resets).
+  Pass → INTEGRATE. Fail → ask "fix / skip verification / stop." `fix`: re-enter EXECUTE (retry budget resets).
+
+---
+
+### INTEGRATE
+
+1. Resolve tier: `max(plan.integrationTier, derived-from-execution)`. If tier escalated: notify human with "Tier escalated from `{planned}` to `{derived}`: {reason}."
+2. Dispatch harness-integration skill:
+   ```
+   subagent_type: "harness-verifier"
+   prompt: "Phase {N}: {name}. Session: {sessionSlug}. Tier: {tier}.
+            Plan: {planPath}. Verify integration per harness-integration skill."
+   ```
+3. **Rigor interaction:**
+   - `"fast"`: WIRE sub-phase only, auto-approve, no ADR drafting.
+   - `"standard"`: Full tier-appropriate checks (WIRE + MATERIALIZE + UPDATE per tier).
+   - `"thorough"`: Full checks + human reviews every ADR draft + force knowledge graph verification.
+4. Pass → REVIEW.
+5. Fail → report incomplete items. Ask "fix / skip integration / stop":
+   - **fix:** re-enter EXECUTE with integration-specific fix tasks, then re-VERIFY, re-INTEGRATE. Retry budget resets.
+   - **skip:** record decision in `decisions[]`, proceed to REVIEW (human override).
+   - **stop:** save state and exit.
 
 ---
 
@@ -145,8 +174,8 @@ Persist findings to `{sessionDir}/phase-{N}-review.json`. No blocking → PHASE_
 
 ### PHASE_COMPLETE
 
-1. Present summary: name, tasks completed, retries used, verification result, review findings count, elapsed time.
-2. Record in `history[]`: phase index, name, startedAt, completedAt, tasksCompleted, retriesUsed, verificationPassed, reviewFindings.
+1. Present summary: name, tasks completed, retries used, verification result, integration report (`{sessionDir}/phase-{N}-integration.json`), review findings count, elapsed time.
+2. Record in `history[]`: phase index, name, startedAt, completedAt, tasksCompleted, retriesUsed, verificationPassed, integrationPassed, reviewFindings.
 3. Mark phase `complete` in state. Clear scratchpad: `clearScratchpad({ session, phase, projectPath })`.
 4. Sync roadmap: `manage_roadmap sync apply:true` (skip if no roadmap; never `force_sync: true`).
 5. Write session summary: `writeSessionSummary(projectPath, sessionSlug, { session, lastActive, skill: "harness-autopilot", phase, status, spec, plan, keyContext, nextStep })`.
@@ -188,9 +217,11 @@ Persist findings to `{sessionDir}/phase-{N}-review.json`. No blocking → PHASE_
 2. **ASSESS** — Route by complexity: low/medium auto-plans, high pauses for interactive planning.
 3. **PLAN → APPROVE** — Dispatch harness-planner, check approval signals, auto-approve or pause.
 4. **EXECUTE** — Dispatch harness-task-executor with plan path, handle checkpoints and retries (max 3).
-5. **VERIFY → REVIEW** — Dispatch harness-verifier and harness-code-reviewer, fix blocking findings.
-6. **PHASE_COMPLETE** — Summarize, sync roadmap, loop to ASSESS for next phase or proceed to FINAL_REVIEW.
-7. **FINAL_REVIEW → DONE** — Cross-phase review, offer PR creation, write final handoff.
+5. **VERIFY** — Dispatch harness-verifier, confirm code correctness and wiring.
+6. **INTEGRATE** — Resolve integration tier, dispatch harness-integration, verify system wiring, knowledge materialization, and documentation per tier.
+7. **REVIEW** — Dispatch harness-code-reviewer, fix blocking findings.
+8. **PHASE_COMPLETE** — Summarize (including integration report), sync roadmap, loop to ASSESS for next phase or proceed to FINAL_REVIEW.
+9. **FINAL_REVIEW → DONE** — Cross-phase review, offer PR creation, write final handoff.
 
 ---
 
@@ -205,9 +236,9 @@ Persist findings to `{sessionDir}/phase-{N}-review.json`. No blocking → PHASE_
 
 ## Gates
 
-- **No reimplementing delegated skills.** Writing planning/execution/verification/review logic → STOP. Delegate via `subagent_type`.
+- **No reimplementing delegated skills.** Writing planning/execution/verification/review/integration logic → STOP. Delegate via `subagent_type`.
 - **No executing without plan approval.** Every plan passes APPROVE_PLAN. No exceptions.
-- **No skipping VERIFY or REVIEW.** Human can override findings; steps cannot be skipped.
+- **No skipping VERIFY, INTEGRATE, or REVIEW.** Human can override findings; steps cannot be skipped. INTEGRATE may be skipped only via explicit "skip" choice with decision recorded in `decisions[]`.
 - **No infinite retries.** EXECUTE budget: 3 attempts. FINAL_REVIEW: 3 cycles. If exhausted, stop and surface.
 - **No modifying state files manually.** If corrupted, start fresh.
 
@@ -231,7 +262,7 @@ Persist findings to `{sessionDir}/phase-{N}-review.json`. No blocking → PHASE_
 
 ## Success Criteria
 
-- All phases in the spec are executed in order with plan → execute → verify → review per phase
+- All phases in the spec are executed in order with plan → execute → verify → integrate → review per phase
 - Every plan approval is recorded in `decisions[]` (auto or manual)
 - Retry budget (3 attempts) is enforced — exhausted retries surface to user, never silently continue
 - FINAL_REVIEW runs on `startingCommit..HEAD` diff and catches cross-phase coherence issues

package/dist/agents/skills/claude-code/harness-brainstorming/SKILL.md

@@ -35,10 +35,11 @@ When no arguments are provided (standalone invocation), the skill operates exact
 
 ### Phase 1: EXPLORE -- Gather Context
 
-1. **Read the existing codebase.** Understand architecture, constraints, and conventions. Check AGENTS.md, existing specs in `docs/`, and relevant source files.
-2. **Identify the problem boundary.** What exactly needs solving? What is out of scope? Write both down.
-3. **Check for prior art.** Has this been partially solved elsewhere? Are there patterns to follow or deliberately break?
-4. **Assess scope.** If the problem spans >3 major subsystems or >2 weeks to implement, decompose into sub-projects first.
+1. **Load project context.** Call `gather_context({ path: "<project-root>", intent: "<feature description>", skill: "harness-brainstorming", session: "<session-slug-if-known>", include: ["graph", "businessKnowledge", "sessions", "validation"] })`. The `graph` context surfaces `business_fact` nodes relevant to the feature domain. The `businessKnowledge` context loads documented domain knowledge from `docs/knowledge/`. Use both to ground exploration in verified facts rather than assumptions.
+2. **Read the existing codebase.** Understand architecture, constraints, and conventions. Check AGENTS.md, existing specs in `docs/`, and relevant source files.
+3. **Identify the problem boundary.** What exactly needs solving? What is out of scope? Write both down. Cross-reference `businessKnowledge` domains — if documented business rules constrain the problem, note them.
+4. **Check for prior art.** Has this been partially solved elsewhere? Are there patterns to follow or deliberately break?
+5. **Assess scope.** If the problem spans >3 major subsystems or >2 weeks to implement, decompose into sub-projects first.
 
 ---
 
@@ -107,9 +108,19 @@ These flow into `handoff.json` `contextKeywords` field. Select keywords that hel
    - Overview and goals
    - Decisions made (with rationale from brainstorming)
    - Technical design (data structures, APIs, file layout)
+   - Integration points (entry points, registrations, docs, decisions, knowledge impact)
    - Success criteria (observable, testable outcomes)
    - Implementation order (high-level phases, not detailed tasks)
 
+   The **Integration Points** section is required in every spec. It defines how the feature connects to the existing system. Populate it with five subsections:
+   - **Entry Points** -- Which system entry points does this feature touch or create? (e.g., new CLI command, new MCP tool, new skill, new API route, new barrel export)
+   - **Registrations Required** -- What registrations are needed for the feature to be discoverable? (e.g., barrel export regeneration, skill tier assignment, route registration)
+   - **Documentation Updates** -- What docs need updating to reflect the new capability? (e.g., AGENTS.md section, API docs, README, guides)
+   - **Architectural Decisions** -- What decisions warrant ADRs? List the decision and a one-line rationale. Only for medium/large tier changes -- omit for small changes.
+   - **Knowledge Impact** -- What domain concepts, patterns, or relationships should enter the knowledge graph?
+
+   If the feature is a small change (bug fix, config tweak, < 3 files), the section may contain only Entry Points and Registrations Required with "None" for the others. The section must still be present.
+
 2. **Run soundness review.** Invoke `harness-soundness-review --mode spec` against the draft. Do not write to `docs/` until the review converges with no remaining issues.
 
 3. **Write the spec** to `docs/changes/<feature>/proposal.md`.
@@ -308,7 +319,7 @@ Apply when output includes specific behavioral expectations.
 
 ## Success Criteria
 
-- Spec exists in `docs/` with all required sections (overview, decisions, technical design, success criteria, implementation order)
+- Spec exists in `docs/` with all required sections (overview, decisions, technical design, integration points, success criteria, implementation order)
 - Human explicitly approved before any implementation
 - YAGNI applied: no speculative features in the spec
 - 2-3 approaches presented with honest tradeoffs before decision

package/dist/agents/skills/claude-code/harness-code-review/SKILL.md

@@ -123,6 +123,10 @@ After review, consider suggesting `.harness/review-learnings.md` creation if you
 
 ## Pipeline Phases
 
+### Pre-Pipeline: Self-Review Baseline
+
+Generate a self-review checklist via `create_self_review` to establish baseline expectations before deeper analysis. This checklist feeds into Phase 4 subagents as an additional input.
+
 ### Phase 1: GATE
 
 **Tier:** fast | **Mode:** CI only (`--ci`). Skip when invoked manually.
@@ -154,10 +158,11 @@ Run mechanical checks to establish an exclusion boundary. Issues caught here are
 **Checks:**
 
 1. **Harness validation:** `assess_project({ path, checks: ["validate", "deps", "docs"], mode: "detailed" })` — runs checks in parallel.
-2. **Security scan:** `run_security_scan` on changed files. Record findings with rule ID, file, line.
-3. **Type checking:** Run `tsc --noEmit`. Record errors.
-4. **Linting:** Run linter. Record violations.
-5. **Tests:** Run test suite. Record failures.
+2. **Diff analysis:** Run `analyze_diff` to get a structured breakdown of changes by file, category, and risk level.
+3. **Security scan:** `run_security_scan` on changed files. Record findings with rule ID, file, line.
+4. **Type checking:** Run `tsc --noEmit`. Record errors.
+5. **Linting:** Run linter. Record violations.
+6. **Tests:** Run test suite. Record failures.
 
 **Output:** Set of mechanical findings (file, line, tool, message) forming the exclusion list for Phase 5.
 
@@ -197,6 +202,8 @@ Determine change type to shape review focus:
 | **Security**      | Security paths + data flow via `query_graph`              | Changed files + files with auth/crypto/SQL/shell patterns |
 | **Architecture**  | Layer boundaries + imports via `query_graph`/`get_impact` | Changed files + `harness check-deps` output               |
 
+Run `compute_blast_radius` on changed files to identify downstream modules that may be affected and should be included in context bundles.
+
 #### 1:1 Context Ratio Rule
 
 - **Small diffs (<20 lines):** 3:1 context-to-diff ratio.
@@ -342,7 +349,9 @@ Invokes `harness-security-review` in changed-files mode as the security fan-out
 
 2. **Stack-adaptive:** Node.js (prototype pollution, ReDoS, path traversal), React (XSS, dangerouslySetInnerHTML), Go (race conditions, integer overflow, unsafe pointer), Python (pickle, SSTI, command injection)
 
-3. **CWE/OWASP references:** All findings include `cweId`, `owaspCategory`, `remediation`.
+3. **Security posture alignment:** Check `get_security_trends` to see if the changes align with or diverge from the project's security posture trajectory.
+
+4. **CWE/OWASP references:** All findings include `cweId`, `owaspCategory`, `remediation`.
 
 Confirmed vulnerabilities are always `severity: 'critical'`.
 
@@ -383,7 +392,8 @@ Reviews architectural violations, dependency direction, and design pattern compl
 
 1. **Mechanical exclusion:** Discard AI findings where same file + line range already flagged by Phase 2.
 2. **Graph reachability (if available):** Verify claimed dependency paths via `query_graph`. Discard findings with invalid reachability claims.
-3. **Import-chain heuristic (fallback):** Follow imports 2 levels deep. If claimed impact unreachable within 2 hops, downgrade to `suggestion`.
+3. **Stale constraint check:** Run `detect_stale_constraints` to check if architectural constraints are still valid after the reviewed changes. Findings referencing invalidated constraints are downgraded.
+4. **Import-chain heuristic (fallback):** Follow imports 2 levels deep. If claimed impact unreachable within 2 hops, downgrade to `suggestion`.
 
 **Exit:** Validated finding set. Continue to Phase 6.
 
@@ -595,6 +605,11 @@ compliance|naming|suggestion|Names follow project conventions (check AGENTS.md o
 ## Harness Integration
 
 - **`assess_project`** — Phase 2: run validate/deps/docs in parallel. Failures are Critical and stop pipeline.
+- **`analyze_diff`** — Phase 2: structured breakdown of changes by file, category, and risk level.
+- **`create_self_review`** — Pre-pipeline: generate a self-review checklist as baseline expectations.
+- **`compute_blast_radius`** — Phase 3/5: run on changed files to identify downstream modules that may be affected by the changes.
+- **`detect_stale_constraints`** — Phase 5: check if architectural constraints are still valid after the reviewed changes.
+- **`get_security_trends`** — Phase 4 (Security Agent): check if changes align with or diverge from the project's security posture trajectory.
 - **`gather_context`** — Phase 3: parallel context assembly. Session parameter scopes to session directory.
 - **`harness cleanup`** — Optional Phase 2 check for entropy in changed files.
 - **Graph queries** — Phase 3 (dependency context) and Phase 5 (reachability verification). Graceful fallback.

package/dist/agents/skills/claude-code/harness-codebase-cleanup/SKILL.md

@@ -34,6 +34,8 @@
 3. **Compute top 10% threshold.** Sort all files by commit count. The file at the 90th percentile defines the threshold. Files above this threshold are "high churn."
 4. **Store as HotspotContext** for use in Phase 3 (CLASSIFY).
 
+Run `detect_stale_constraints` to find architectural constraints referencing removed or restructured code. Run `detect_anomalies` to identify structural irregularities that should be addressed during cleanup.
+
 ### Phase 2: DETECT -- Run Both Concerns in Parallel
 
 1. **Dead code detection** (skip if `--architecture-only`):

package/dist/agents/skills/claude-code/harness-debugging/SKILL.md

@@ -110,7 +110,11 @@ git diff HEAD~5
 
 What changed recently? Many bugs are caused by the most recent change. Compare the failing state to the last known working state.
 
-#### Step 5: Trace Data Flow Backward
+#### Step 5: Explore Code Structure
+
+Use `code_outline` to get a structural overview of suspect modules (functions, classes, exports) without reading full source. Use `code_search` to locate symbol usages, error strings, or patterns across the codebase. Use `code_unfold` to expand a specific symbol to its full implementation with dependency context. These tools let you navigate efficiently without reading entire files.
+
+#### Step 6: Trace Data Flow Backward
 
 Start at the error location and trace backward:
 
@@ -149,6 +153,10 @@ Look for:
 - Documentation or comments that describe expected behavior
 ```
 
+#### Step 1b: Run Anomaly Detection
+
+Run `detect_anomalies` to identify structural irregularities (orphaned files, missing tests, unusual coupling) that may relate to the bug. Anomalies near the failure site often point to the root cause.
+
 #### Step 2: Read Reference Implementations Completely
 
 When you find a working example, read it in its entirety. Do not cherry-pick lines. Understand:
@@ -306,6 +314,10 @@ Update the session status to `resolved`.
 - **`harness validate`** — Run in Phase 4 VERIFY after applying the fix. Confirms the fix does not break project-wide constraints.
 - **`harness check-deps`** — Run in Phase 4 VERIFY. Confirms the fix does not introduce dependency violations.
 - **`harness state learn`** — Run after resolution to capture learnings for future sessions.
+- **`code_outline`** — Use in Phase 1 INVESTIGATE to get a structural overview of suspect modules without reading full source.
+- **`code_search`** — Use in Phase 1 INVESTIGATE to locate symbol usages, error strings, or patterns across the codebase.
+- **`code_unfold`** — Use in Phase 1 INVESTIGATE to expand a specific symbol to its full implementation with dependency context.
+- **`detect_anomalies`** — Run in Phase 2 ANALYZE to identify structural irregularities (orphaned files, missing tests, unusual coupling) near the failure site.
 - **Debug session files** — Stored in `.harness/debug/active/` (in progress) and `.harness/debug/resolved/` (completed). These persist across context resets.
 
 ## Success Criteria

package/dist/agents/skills/claude-code/harness-dependency-health/SKILL.md

@@ -79,6 +79,8 @@ When no graph is available, use static analysis to approximate structural metric
 
 > Fallback completeness: ~60% — cannot compute transitive depth beyond what import parsing reveals; coupling metrics are approximate.
 
+6. **Detect structural anomalies**: Run `detect_anomalies` to identify structural irregularities (orphaned modules, unusual coupling patterns) that indicate dependency health issues.
+
 ### Phase 2: SCORE — Calculate Health Score
 
 Compute a weighted health score (0-100):
@@ -93,6 +95,8 @@ Compute a weighted health score (0-100):
 
 **Grades**: A (90-100), B (75-89), C (60-74), D (40-59), F (<40)
 
+Check `get_decay_trends` to see how dependency health metrics have changed over time and whether current trends are improving or degrading.
+
 ### Phase 3: RECOMMEND — Generate Recommendations
 
 For each problem found, generate a specific, actionable recommendation:

package/dist/agents/skills/claude-code/harness-execution/SKILL.md

@@ -45,25 +45,29 @@ When no arguments are provided (standalone invocation), discover plan from `docs
      intent: "Execute plan tasks starting from current position",
      skill: "harness-execution",
      session: "<session-slug-if-known>",
-     include: ["state", "learnings", "handoff", "validation"]
+     include: ["state", "learnings", "handoff", "graph", "businessKnowledge", "sessions", "validation"]
    })
    ```
 
-   If session slug is known, include `session` to scope reads/writes to `.harness/sessions/<slug>/`. If unknown, omit it — falls back to `.harness/`. Returns `state` (current position, null = fresh start), `learnings` (prior insights — do not ignore), `handoff` (context from previous skill), `validation` (project health). Failed constituents return null with errors in `meta.errors`.
+   If session slug is known, include `session` to scope reads/writes to `.harness/sessions/<slug>/`. If unknown, omit it — falls back to `.harness/`. Returns `state` (current position, null = fresh start), `learnings` (prior insights — do not ignore), `handoff` (context from previous skill), `graph` (business_fact nodes and module dependencies), `businessKnowledge` (documented domain knowledge from `docs/knowledge/`), `validation` (project health). Use graph and businessKnowledge context to inform implementation decisions — especially when tasks reference domain rules or business logic. Failed constituents return null with errors in `meta.errors`.
 
-3. **Load session summary for cold start.** If resuming (session slug known):
+3. **Review prior decisions and questions.** Check `decisions` and `openQuestions` from the planning session (loaded via `sessions` in gather_context). Resolved questions provide context for task execution. Open questions may require escalation before proceeding.
+
+4. **Load session summary for cold start.** If resuming (session slug known):
    - Call `listActiveSessions()` to read the session index.
    - Call `loadSessionSummary()` for the target session.
    - If ambiguous, present the index and ask which session to resume.
 
-4. **Check for known dead ends.** Review `learnings` tagged `[outcome:failure]`. Warn if any match current plan approaches.
+5. **Check for known dead ends.** Review `learnings` tagged `[outcome:failure]`. Warn if any match current plan approaches.
 
-5. **Verify prerequisites** for the current task:
+6. **Verify prerequisites** for the current task:
    - Dependency tasks marked complete in state?
    - Referenced files exist?
    - Test suite passes? Run `harness validate` for clean baseline.
 
-6. **If prerequisites fail,** do not proceed. Report what is missing and which task is blocked.
+6b. **Knowledge health check.** If `docs/knowledge/` exists and the knowledge graph is available, run the knowledge pipeline in detect-only mode for domains touched by the current plan. If contradictions exist (severity: critical), treat as a blocker — knowledge must be reconciled before implementation. If gaps exist, surface as a warning but do not block execution.
+
+7. **If prerequisites fail,** do not proceed. Report what is missing and which task is blocked.
 
 ### Graph-Enhanced Context (when available)
 
@@ -71,6 +75,8 @@ When a knowledge graph exists at `.harness/graph/`:
 
 - `query_graph` — check file overlap between tasks for conflict detection
 - `get_impact` — understand blast radius before executing a task
+- `compute_blast_radius` — before executing tasks that touch shared modules, simulate failure propagation to anticipate side effects
+- `predict_failures` — before risky tasks (large blast radius, many file touches), check which constraints are trending toward violation
 
 Fall back to file-based commands if no graph is available.
 
@@ -102,6 +108,8 @@ For each task, starting from current position:
 - For `reference` tier skills (type: `knowledge`): load the skill's SKILL.md content as supplementary context. Cap at 3 reference skills per task to manage context budget.
 - Use the skill content to inform implementation decisions but follow the plan's exact instructions as written. Skill context provides background knowledge, not overriding instructions.
 
+1c. **Auto-inject knowledge skills.** If the plan was produced with skill recommendations (`docs/changes/<feature>/SKILLS.md`), run `recommend_skills` for the current task domain. If the response includes `autoInjectKnowledge` entries, load those knowledge skills as supplementary context alongside any explicitly annotated skills. This ensures domain-specific business rules, API patterns, and framework conventions are available during implementation without manual annotation on every task.
+
 2. **Follow instructions exactly.** The plan contains exact file paths, code, and commands. Execute as written.
 
 3. **TDD rhythm:**
@@ -238,6 +246,8 @@ All session-scoped files use `{sessionDir}/` when session is known, otherwise `.
 
 **Graph Refresh:** If `.harness/graph/` exists, run `harness scan [path]` after code changes. Skipping causes stale graph query results.
 
+1b. **Knowledge reconciliation.** After code changes committed and graph refreshed, run the knowledge pipeline in extract-only mode to stage any new business signals discovered in the code (validation rules, API contracts, test descriptions) for future materialization. This keeps the knowledge graph current with what was actually implemented. Skip if no `docs/knowledge/` directory exists.
+
 2. **Append tagged learnings** to `learnings.md`. Tag every entry:
 
    ```markdown

package/dist/agents/skills/claude-code/harness-impact-analysis/SKILL.md

@@ -41,6 +41,8 @@ enable full analysis)" and use fallback strategies for all subsequent steps.
 
 ### Phase 2: ANALYZE — Query Graph for Impact
 
+Run `compute_blast_radius` on target files to simulate failure propagation and identify all downstream modules affected. Run `predict_failures` to forecast which architectural constraints are most at risk from the proposed changes.
+
 For each changed file:
 
 1. **Direct dependents**: Use `get_impact` MCP tool to find all files that import or call the changed file.