@harness-engineering/cli 1.8.2 → 1.9.0

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

@@ -122,12 +122,15 @@ Run mechanical checks to establish an exclusion boundary. Any issue caught mecha
 
 **Checks:**
 
-1. **Harness validation:**
-   ```bash
-   harness validate
-   harness check-deps
-   harness check-docs
+1. **Harness validation:** Use `assess_project` to run all harness health checks in parallel:
+   ```json
+   assess_project({
+     path: "<project-root>",
+     checks: ["validate", "deps", "docs"],
+     mode: "detailed"
+   })
    ```
+   This runs `harness validate`, `harness check-deps`, and `harness check-docs` in parallel and returns a unified report. Any check failure is reported in the `checks` array with `passed: false`.
 2. **Security scan:** Run `run_security_scan` MCP tool on changed files. Record findings with rule ID, file, line, and remediation.
 3. **Type checking:** Run the project's type checker (e.g., `tsc --noEmit`). Record any type errors.
 4. **Linting:** Run the project's linter (e.g., `eslint`). Record any lint violations.
@@ -202,13 +205,21 @@ Gather context in this order until the ratio is met:
 
 #### Graph-Enhanced Context (when available)
 
-When a knowledge graph exists at `.harness/graph/`, use graph queries for faster, more accurate context:
+When a knowledge graph exists at `.harness/graph/`, use `gather_context` for efficient context assembly:
 
-- `query_graph` — traverse dependency chain from changed files to find all imports and transitive dependencies
-- `get_impact` — find all affected tests, docs, and downstream code
-- `find_context_for` — assemble review context within token budget, ranked by relevance
+```json
+gather_context({
+  path: "<project-root>",
+  intent: "Code review of <change description>",
+  skill: "harness-code-review",
+  tokenBudget: 8000,
+  include: ["graph", "learnings", "validation"]
+})
+```
+
+This replaces manual `query_graph` + `get_impact` + `find_context_for` calls with a single composite call that assembles review context in parallel, ranked by relevance. Falls back gracefully when no graph is available (`meta.graphAvailable: false`).
 
-Graph queries replace manual grep/find commands and discover transitive dependencies that file search misses. Fall back to file-based commands if no graph is available.
+For domain-specific scoping (compliance, bug detection, security, architecture), supplement `gather_context` output with targeted `query_graph` calls as needed.
 
 #### Context Assembly Commands
 
@@ -493,7 +504,9 @@ emit_interaction({
   type: "confirmation",
   confirmation: {
     text: "Review complete: <Assessment>. Accept review?",
-    context: "<N critical, N important, N suggestion findings>"
+    context: "<N critical, N important, N suggestion findings>",
+    impact: "Accepting the review finalizes findings. If 'approve', ready for merge. If 'request-changes', fixes are needed.",
+    risk: "<low if approve, high if critical findings>"
   }
 })
 ```
@@ -528,7 +541,16 @@ Call `emit_interaction`:
     "reason": "Review approved with no blocking issues",
     "artifacts": ["<reviewed files>"],
     "requiresConfirmation": true,
-    "summary": "Review approved. <N> suggestions noted. Ready to create PR or merge."
+    "summary": "Review approved. <N> suggestions noted. Ready to create PR or merge.",
+    "qualityGate": {
+      "checks": [
+        { "name": "mechanical-checks", "passed": true },
+        { "name": "no-critical-findings", "passed": true },
+        { "name": "no-important-findings", "passed": true },
+        { "name": "harness-validate", "passed": true }
+      ],
+      "allPassed": true
+    }
   }
 }
 ```
@@ -591,9 +613,8 @@ _This section is not part of the pipeline. It documents the process for respondi
 
 ## Harness Integration
 
-- **`harness validate`** — Run in Phase 2 (MECHANICAL). Must pass for the pipeline to continue to AI review.
-- **`harness check-deps`** — Run in Phase 2 (MECHANICAL). Failures are Critical issues that stop the pipeline.
-- **`harness check-docs`** — Run in Phase 2 (MECHANICAL). Documentation drift findings are recorded for the exclusion set.
+- **`assess_project`** — Used in Phase 2 (MECHANICAL) to run `validate`, `deps`, and `docs` checks in parallel. Must pass for the pipeline to continue to AI review. Failures are Critical issues that stop the pipeline.
+- **`gather_context`** — Used in Phase 3 (CONTEXT) for efficient parallel context assembly. Replaces separate graph query calls.
 - **`harness cleanup`** — Optional check during Phase 2 for entropy accumulation in changed files.
 - **Graph queries** — Used in Phase 3 (CONTEXT) for dependency-scoped context and in Phase 5 (VALIDATE) for reachability verification. Graceful fallback when no graph exists.
 - **`emit_interaction`** -- Call after review approval to suggest transitioning to merge/PR creation. Only emitted on APPROVE assessment. Uses confirmed transition (waits for user approval).

package/dist/agents/skills/gemini-cli/harness-codebase-cleanup/SKILL.md

@@ -205,7 +205,7 @@ After removing the `legacy-auth` module:
 - **`harness cleanup --type dead-code --json`** -- Dead code detection input
 - **`harness check-deps --json`** -- Architecture violation detection input
 - **`harness skill run harness-hotspot-detector`** -- Hotspot context for safety classification
-- **`apply_fixes` MCP tool** -- Applies safe fixes via the MCP server
+- **`detect_entropy` MCP tool with `autoFix: true`** -- Detects entropy and applies safe fixes via the MCP server
 - **`harness validate`** -- Final validation after all fixes
 - **`harness check-deps`** -- Final architecture check after all fixes
 

package/dist/agents/skills/gemini-cli/harness-execution/SKILL.md

@@ -26,20 +26,27 @@ Deviating from the plan mid-execution introduces untested assumptions, breaks ta
 
 1. **Load the plan.** Read the plan document from `docs/plans/`. Identify the total task count and any checkpoints.
 
-2. **Load state.** Read `.harness/state.json` to determine current position. If the file does not exist, this is a fresh start — position is Task 1.
+2. **Gather context in one call.** Use the `gather_context` MCP tool to load all working context at once:
 
-3. **Load learnings.** Read `.harness/learnings.md` for context from previous sessions. These are hard-won insights — do not ignore them.
+   ```json
+   gather_context({
+     path: "<project-root>",
+     intent: "Execute plan tasks starting from current position",
+     skill: "harness-execution",
+     include: ["state", "learnings", "handoff", "validation"]
+   })
+   ```
 
-4. **Load failures.** Read `.harness/failures.md` for known dead ends. If any entries match approaches in the current plan, surface warnings before proceeding.
+   This returns `state` (current position — if null, this is a fresh start at Task 1), `learnings` (hard-won insights from previous sessions — do not ignore them), `handoff` (structured context from the previous skill), and `validation` (current project health). If any constituent fails, its field is null and the error is reported in `meta.errors`.
 
-5. **Load handoff.** Read `.harness/handoff.json` if it exists. Contains structured context from the previous skill (e.g., harness-planning passing context to harness-execution). Use this to prime session state.
+3. **Check for known dead ends.** Review `learnings` entries tagged `[outcome:failure]`. If any match approaches in the current plan, surface warnings before proceeding.
 
-6. **Verify prerequisites.** For the current task:
+4. **Verify prerequisites.** For the current task:
    - Are dependency tasks marked complete in state?
    - Do the files referenced in the task exist as expected?
    - Does the test suite pass? Run `harness validate` to confirm a clean baseline.
 
-7. **If prerequisites fail,** do not proceed. Report what is missing and which task is blocked.
+5. **If prerequisites fail,** do not proceed. Report what is missing and which task is blocked.
 
 ### Graph-Enhanced Context (when available)
 
@@ -75,7 +82,17 @@ For each task, starting from the current position:
 
 4. **Commit atomically.** Each task produces exactly one commit. Use the commit message specified in the plan. If no message is specified, write a descriptive message in the project's convention.
 
-5. **Run mechanical gate.** After each task commit, run the full gate check: test suite, linter, type checker, build, and `harness validate`. This is binary pass/fail.
+5. **Run mechanical gate.** After each task commit, run the full gate check. Use `assess_project` to run harness checks (including lint) in parallel, then run the test suite:
+
+   ```json
+   assess_project({
+     path: "<project-root>",
+     checks: ["validate", "deps", "lint"],
+     mode: "summary"
+   })
+   ```
+
+   Then run the project's test suite (`npx turbo run test` or equivalent). This is binary pass/fail.
    - **All pass →** proceed to the next task.
    - **Any fail →** retry with error context (max 2 attempts).
    - **Still failing after retries →** record the failure in `.harness/failures.md`, escalate, and stop.
@@ -109,7 +126,9 @@ Plans contain three types of checkpoints. Each requires pausing execution.
      type: "confirmation",
      confirmation: {
        text: "Task N complete. Output: <summary>. Continue to Task N+1?",
-       context: "<test output or file diff summary>"
+       context: "<test output or file diff summary>",
+       impact: "Continuing proceeds to the next task. Declining pauses execution for review.",
+       risk: "low"
      }
    })
    ```
@@ -125,7 +144,27 @@ Plans contain three types of checkpoints. Each requires pausing execution.
      type: "question",
      question: {
        text: "Task N requires a decision: <description>",
-       options: ["<option A>", "<option B>"]
+       options: [
+         {
+           label: "<option A>",
+           pros: ["<pro 1>", "<pro 2>"],
+           cons: ["<con 1>"],
+           risk: "low",
+           effort: "low"
+         },
+         {
+           label: "<option B>",
+           pros: ["<pro 1>"],
+           cons: ["<con 1>", "<con 2>"],
+           risk: "medium",
+           effort: "medium"
+         }
+       ],
+       recommendation: {
+         optionIndex: 0,
+         reason: "<why this option is recommended>",
+         confidence: "medium"
+       }
      }
    })
    ```
@@ -162,7 +201,15 @@ emit_interaction({
     completedPhase: "execution",
     suggestedNext: "verification",
     reason: "All plan tasks executed and verified",
-    artifacts: ["<list of created/modified files>"]
+    artifacts: ["<list of created/modified files>"],
+    qualityGate: {
+      checks: [
+        { name: "all-tasks-complete", passed: true, detail: "<N>/<N> tasks" },
+        { name: "harness-validate", passed: true },
+        { name: "tests-pass", passed: true }
+      ],
+      allPassed: true
+    }
   }
 })
 ```
@@ -236,7 +283,16 @@ Skipping this step means subsequent graph queries (impact analysis, dependency h
        "reason": "All tasks complete",
        "artifacts": ["<list of created/modified files>"],
        "requiresConfirmation": false,
-       "summary": "Completed <N> tasks. <N> files created, <N> modified. All quick gates passed."
+       "summary": "Completed <N> tasks. <N> files created, <N> modified. All quick gates passed.",
+       "qualityGate": {
+         "checks": [
+           { "name": "all-tasks-complete", "passed": true, "detail": "<N>/<N> tasks" },
+           { "name": "harness-validate", "passed": true },
+           { "name": "tests-pass", "passed": true },
+           { "name": "no-blockers", "passed": true }
+         ],
+         "allPassed": true
+       }
      }
    }
    ```
@@ -265,6 +321,7 @@ These are non-negotiable. When any condition is met, stop immediately.
 ## Harness Integration
 
 - **`harness validate`** — Run after every task completion. Mandatory. No task is complete without a passing validation.
+- **`gather_context`** — Used in PREPARE phase to load state, learnings, handoff, and validation in a single call instead of 4+ separate reads.
 - **`harness check-deps`** — Run when tasks add new imports or modules. Catches boundary violations early.
 - **`harness state show`** — View current execution position and progress.
 - **`harness state learn "<message>"`** — Append a learning from the command line.

package/dist/agents/skills/gemini-cli/harness-planning/SKILL.md

@@ -46,7 +46,34 @@ Work backward from the goal. Do not start with "what should we build?" Start wit
      type: "question",
      question: {
        text: "The spec mentions X but does not define behavior for Y. Should we:",
-       options: ["A) Include Y in this plan", "B) Defer Y to a follow-up plan", "C) Update the spec first"]
+       options: [
+         {
+           label: "A) Include Y in this plan",
+           pros: ["Complete feature in one pass", "No follow-up coordination needed"],
+           cons: ["Increases plan scope and time", "May delay delivery"],
+           risk: "medium",
+           effort: "high"
+         },
+         {
+           label: "B) Defer Y to a follow-up plan",
+           pros: ["Keeps current plan focused", "Ship sooner"],
+           cons: ["Y remains unhandled", "May need rework when Y is added"],
+           risk: "low",
+           effort: "low"
+         },
+         {
+           label: "C) Update the spec first",
+           pros: ["Design is complete before planning", "No surprises during execution"],
+           cons: ["Blocks planning until spec is updated", "Extra round-trip"],
+           risk: "low",
+           effort: "medium"
+         }
+       ],
+       recommendation: {
+         optionIndex: 1,
+         reason: "Keeping the current plan focused reduces risk. Y can be addressed in a dedicated follow-up.",
+         confidence: "medium"
+       }
      }
    })
    ```
@@ -174,7 +201,9 @@ When presenting the task breakdown, use progress markers:
      type: "confirmation",
      confirmation: {
        text: "Approve plan at <plan-file-path>?",
-       context: "<task count> tasks, <estimated time> minutes. <one-sentence summary>"
+       context: "<task count> tasks, <estimated time> minutes. <one-sentence summary>",
+       impact: "Approving unlocks task-by-task execution. Plan defines exact file paths, code, and commands.",
+       risk: "low"
      }
    })
    ```
@@ -192,7 +221,16 @@ When presenting the task breakdown, use progress markers:
         "reason": "Plan approved with all tasks defined",
         "artifacts": ["<plan file path>"],
         "requiresConfirmation": true,
-        "summary": "<Plan title> -- <N> tasks, <N> checkpoints. Estimated <time>."
+        "summary": "<Plan title> -- <N> tasks, <N> checkpoints. Estimated <time>.",
+        "qualityGate": {
+          "checks": [
+            { "name": "plan-written", "passed": true, "detail": "Written to docs/plans/" },
+            { "name": "harness-validate", "passed": true },
+            { "name": "observable-truths-traced", "passed": true },
+            { "name": "human-approved", "passed": true }
+          ],
+          "allPassed": true
+        }
       }
     }
     ```

package/dist/agents/skills/gemini-cli/harness-pre-commit-review/SKILL.md

@@ -43,6 +43,20 @@ pnpm typecheck 2>&1 || npx tsc --noEmit 2>&1 || make typecheck 2>&1
 pnpm test 2>&1 || npm test 2>&1 || make test 2>&1
 ```
 
+#### 2b. Harness Health Check
+
+If the project uses harness, run `assess_project` for harness-specific validation:
+
+```json
+assess_project({
+  path: "<project-root>",
+  checks: ["validate", "deps"],
+  mode: "summary"
+})
+```
+
+If `healthy: false`, include harness check failures in the mechanical check report. This replaces manually running `harness validate` and `harness check-deps` as separate commands.
+
 #### 3. Gate Decision
 
 - **Any check fails:** STOP. Report the failure. Do not proceed to AI review. The author must fix mechanical issues first.
@@ -133,12 +147,21 @@ If no source files are staged, skip the security scan.
 
 Perform a focused, lightweight review of staged changes. This is NOT a full code review — it catches obvious issues only.
 
-#### 1. Get the Staged Diff
+#### 1. Quick Review via review_changes
 
-```bash
-git diff --cached
+Use the `review_changes` MCP tool with `depth: 'quick'` for fast pre-commit analysis:
+
+```json
+review_changes({
+  path: "<project-root>",
+  diff: "<output of git diff --cached>",
+  depth: "quick",
+  mode: "summary"
+})
 ```
 
+This runs forbidden pattern checks and size analysis. For the semantic review items below, supplement with manual diff reading.
+
 #### 2. Quick Review Checklist
 
 Review the staged diff for these high-signal issues only:
@@ -219,6 +242,8 @@ fi
 - Follows Principle 7 (Deterministic-vs-LLM Split) — mechanical checks first, AI review second
 - Reads `.harness/review-learnings.md` for calibration (if present)
 - Complements harness-code-review (full review) — use pre-commit for quick checks, code-review for thorough analysis
+- **`assess_project`** — Used in Phase 1 for harness-specific health checks (validate + deps) in a single call.
+- **`review_changes`** — Used in Phase 4 with `depth: 'quick'` for fast pre-commit diff analysis.
 
 ## Success Criteria
 

package/dist/agents/skills/gemini-cli/harness-release-readiness/SKILL.md

@@ -111,7 +111,19 @@ Run every check below. Record each as **pass**, **warn**, or **fail**:
 | `test` script exists in root `package.json`                     | fail                |
 | `lint` script exists in root `package.json`                     | fail                |
 | `typecheck` or `tsc` script exists in root `package.json`       | fail                |
-| `harness validate` passes (project-level health check)          | fail                |
+| `assess_project` passes (harness health + lint gate)            | fail                |
+
+For the `assess_project` check, run it with all harness-specific checks including lint:
+
+```json
+assess_project({
+  path: "<project-root>",
+  checks: ["validate", "deps", "docs", "lint"],
+  mode: "detailed"
+})
+```
+
+If `healthy: false`, each failing check in the `checks` array maps to a separate finding with its `topIssue`. This replaces running `harness validate`, `harness check-deps`, and lint as separate commands.
 
 ##### i18n Coverage (conditional)
 
@@ -507,7 +519,7 @@ This framing is informational — it does not block anything. It gives the team
 
 ## Harness Integration
 
-- **`harness validate`** — Run after auto-fixes to verify project health. Also included in AUDIT phase as a meta-check (does the project pass its own validation?).
+- **`assess_project`** — Used in AUDIT Phase 1 (CI/CD section) to run harness validation, dependency checks, doc coverage, and lint in a single parallel call. Also run after auto-fixes in Phase 3 to verify project health. Automatically inherits new checks added to `assess_project`.
 - **Sub-skill invocations** — Phase 2 dispatches `detect-doc-drift`, `cleanup-dead-code`, `enforce-architecture`, and `diagnostics` as parallel agents. Phase 3 delegates fixes to `align-documentation` and `cleanup-dead-code`.
 - **State file** — `.harness/release-readiness.json` enables session resumption and progress tracking. This file is read at the start of each invocation and written at the end.
 - **Report file** — `release-readiness-report.md` is written to the project root. It is a snapshot, not a tracked artifact — regenerate it on each run.

package/dist/agents/skills/gemini-cli/harness-verification/SKILL.md

@@ -177,7 +177,9 @@ emit_interaction({
   type: "confirmation",
   confirmation: {
     text: "Verification report: <VERDICT>. Accept and proceed?",
-    context: "<summary: N artifacts checked, N gaps found>"
+    context: "<summary: N artifacts checked, N gaps found>",
+    impact: "Accepting proceeds to code review. Declining requires gap resolution first.",
+    risk: "<low if PASS, high if gaps remain>"
   }
 })
 ```
@@ -212,7 +214,21 @@ Call `emit_interaction`:
     "reason": "Verification passed at all 3 levels",
     "artifacts": ["<verified file paths>"],
     "requiresConfirmation": false,
-    "summary": "Verification passed: <N> artifacts checked. EXISTS, SUBSTANTIVE, WIRED all passed."
+    "summary": "Verification passed: <N> artifacts checked. EXISTS, SUBSTANTIVE, WIRED all passed.",
+    "qualityGate": {
+      "checks": [
+        { "name": "level1-exists", "passed": true, "detail": "<N> artifacts present" },
+        { "name": "level2-substantive", "passed": true, "detail": "No stubs or placeholders" },
+        {
+          "name": "level3-wired",
+          "passed": true,
+          "detail": "All artifacts imported, tested, integrated"
+        },
+        { "name": "anti-pattern-scan", "passed": true, "detail": "No matches" },
+        { "name": "harness-validate", "passed": true }
+      ],
+      "allPassed": true
+    }
   }
 }
 ```

package/dist/bin/harness.js

@@ -4,15 +4,15 @@ import {
   createProgram,
   findConfigFile,
   loadConfig
-} from "../chunk-Y7U5AYAL.js";
-import "../chunk-LB4GRDDV.js";
+} from "../chunk-RTPHUDZS.js";
+import "../chunk-6JIT7CEM.js";
 import {
   getUpdateNotification,
   isUpdateCheckEnabled,
   readCheckState,
   shouldRunCheck,
   spawnBackgroundCheck
-} from "../chunk-SAB3VXOW.js";
+} from "../chunk-CGSHUJES.js";
 import {
   handleError
 } from "../chunk-ULSRSP53.js";

package/dist/{chunk-LB4GRDDV.js → chunk-6JIT7CEM.js}

@@ -1,6 +1,6 @@
 import {
   Ok
-} from "./chunk-SAB3VXOW.js";
+} from "./chunk-CGSHUJES.js";
 
 // src/commands/validate-cross-check.ts
 import * as fs from "fs";