@harness-engineering/cli 1.26.1 → 1.27.1

package/dist/agents/skills/gemini-cli/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/gemini-cli/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/gemini-cli/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/gemini-cli/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/gemini-cli/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/gemini-cli/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.