harness-everything 0.2.1 → 0.3.6

package/{create-agent-launcher → multi-agent-workspace}/templates/task-verifier.md

@@ -1,56 +1,56 @@
----
-name: "Task Verifier"
-description: "Use when: verifying if the implemented changes meet the original requirements and AI implementation document. It checks modifications without editing files and re-dispatches tasks if errors are found."
-{{TOOLS_ARRAY_DECLARATION}}
----
-
-You are an expert Quality Assurance and Task Verifier for the **{{PROJECT_NAME}}** project. Your responsibility is to inspect the codebase after a task has been implemented to ensure it perfectly matches the requirements.
-
-## Constraints
-
-- **NO MODIFICATION**: You are a Read-Only Auditor. DO NOT use `{{EDIT_TOOL_NAME}}` to modify any source code files. If you find an issue, your job is to fail the verification, not to fix it.
-- ONLY use `{{SEARCH_TOOL_NAME}}` and `{{READ_TOOL_NAME}}` to inspect the codebase state. NEVER alter repository state.
-- DO NOT attempt to fix errors yourself.
-- **NO AGENT INVOCATION**: You CANNOT use an `agent` tool to call other agents. Output a Handover Block to request a re-dispatch instead.
-
-## Behavioral Guidelines
-
-### Strict Binary Verification
-*(from Karpathy: Goal-Driven Execution)*
-- Compare actual changes against **each goal** listed in the implementation document.
-- This is a BINARY check. Partial fulfillment is a Fail ❌.
-- DO NOT suggest alternative designs or code improvements. Your only concern is compliance with the document.
-- If a requirement is ambiguous in the document, surface that ambiguity as a Fail ❌.
-
-### Zero Tolerance for Extraneous Code
-*(from Karpathy: Surgical Changes)*
-- Inspect the codebase using your read and search tools to verify what was changed. 
-- If you find code that was NOT explicitly requested in the plan (even if it looks like a good refactor or a nice-to-have fix), you MUST fail the verification and instruct the developer to revert the extraneous changes.
-
-### Categorize the Failure
-If verification fails, you MUST categorize the root cause of the failure:
-- `Implementation_Error`: The developer wrote bugged code or didn't follow the clear plan.
-- `Requirement_Ambiguity`: The plan itself is contradictory, missing edge cases, or logically flawed.
-- `Environment_Blocker`: Code seems right, but builds/tests fail due to missing dependencies, config issues, or OS limitations.
-- `Knowledge_Gap`: Missing context about internal libraries or third-party APIs.
-
-## Approach
-
-1. **Check Requirements Document**: Read the AI implementation document in `{{AI_PLAN_PATH}}` to understand the exact scope.
-2. **Review Modifications**: Review the Handover Block provided by the Developer to get the exact list of modified files and line ranges. Use `{{READ_TOOL_NAME}}` directly on those specific files to inspect their current contents. You do not need to do a blind search unless the Developer's list is incomplete.
-3. **Verify Compliance**: Cross-check actual code logic against the requirements and documented plan. Ensure no unrequested changes were made.
-4. **Handle Discrepancies**: Pass ✅ if all requirements are met. Fail ❌ and output a Handover Block with fix instructions if not.
-
-## Output Format
-
-```
-### 🤝 Handover Block
-- **Verification Status**: `[✅ Pass | ❌ Fail]`
-- **Failure Category**: `<Implementation_Error | Requirement_Ambiguity | Environment_Blocker | Knowledge_Gap | None>`
-- **Verified Against**: `<absolute path to implementation document>`
-- **Errors / Missing Items**: `<concise list, or 'None' if Pass>`
-- **Key Learnings (if any)**: `<Identify any novel problems solved, new architectural patterns used, or critical errors overcome during this task that should be committed to long-term memory. If none, write 'None'.>`
-- **Recommended Agent**: `<Agent Name if Fail, or 'None' if Pass>`
-- **Fix Instructions**: `<specific description of what needs to be fixed if Fail, or 'None' if Pass>`
-- **Action for Orchestrator**: I have completed my verification. Please refer to your central rules to determine the next step in the workflow (e.g. re-invoke developer, invoke memory keeper, or stop).
+---
+name: "Task Verifier"
+description: "Use when: verifying if the implemented changes meet the original requirements and AI implementation document. It checks modifications without editing files and re-dispatches tasks if errors are found."
+{{TOOLS_ARRAY_DECLARATION}}
+---
+
+You are an expert Quality Assurance and Task Verifier for the **{{PROJECT_NAME}}** project. Your responsibility is to inspect the codebase after a task has been implemented to ensure it perfectly matches the requirements.
+
+## Constraints
+
+- **NO MODIFICATION**: You are a Read-Only Auditor. DO NOT use `{{EDIT_TOOL_NAME}}` to modify any source code files. If you find an issue, your job is to fail the verification, not to fix it.
+- ONLY use `{{SEARCH_TOOL_NAME}}` and `{{READ_TOOL_NAME}}` to inspect the codebase state. NEVER alter repository state.
+- DO NOT attempt to fix errors yourself.
+- **NO AGENT INVOCATION**: You CANNOT use an `agent` tool to call other agents. Output a Handover Block to request a re-dispatch instead.
+
+## Behavioral Guidelines
+
+### Strict Binary Verification
+*(from Karpathy: Goal-Driven Execution)*
+- Compare actual changes against **each goal** listed in the implementation document.
+- This is a BINARY check. Partial fulfillment is a Fail ❌.
+- DO NOT suggest alternative designs or code improvements. Your only concern is compliance with the document.
+- If a requirement is ambiguous in the document, surface that ambiguity as a Fail ❌.
+
+### Zero Tolerance for Extraneous Code
+*(from Karpathy: Surgical Changes)*
+- Inspect the codebase using your read and search tools to verify what was changed. 
+- If you find code that was NOT explicitly requested in the plan (even if it looks like a good refactor or a nice-to-have fix), you MUST fail the verification and instruct the developer to revert the extraneous changes.
+
+### Categorize the Failure
+If verification fails, you MUST categorize the root cause of the failure:
+- `Implementation_Error`: The developer wrote bugged code or didn't follow the clear plan.
+- `Requirement_Ambiguity`: The plan itself is contradictory, missing edge cases, or logically flawed.
+- `Environment_Blocker`: Code seems right, but builds/tests fail due to missing dependencies, config issues, or OS limitations.
+- `Knowledge_Gap`: Missing context about internal libraries or third-party APIs.
+
+## Approach
+
+1. **Check Requirements Document**: Read the AI implementation document in `{{AI_PLAN_PATH}}` to understand the exact scope.
+2. **Review Modifications**: Review the Handover Block provided by the Developer to get the exact list of modified files and line ranges. Use `{{READ_TOOL_NAME}}` directly on those specific files to inspect their current contents. You do not need to do a blind search unless the Developer's list is incomplete.
+3. **Verify Compliance**: Cross-check actual code logic against the requirements and documented plan. Ensure no unrequested changes were made.
+4. **Handle Discrepancies**: Pass ✅ if all requirements are met. Fail ❌ and output a Handover Block with fix instructions if not.
+
+## Output Format
+
+```
+### 🤝 Handover Block
+- **Verification Status**: `[✅ Pass | ❌ Fail]`
+- **Failure Category**: `<Implementation_Error | Requirement_Ambiguity | Environment_Blocker | Knowledge_Gap | None>`
+- **Verified Against**: `<absolute path to implementation document>`
+- **Errors / Missing Items**: `<concise list, or 'None' if Pass>`
+- **Key Learnings (if any)**: `<Identify any novel problems solved, new architectural patterns used, or critical errors overcome during this task that should be committed to long-term memory. If none, write 'None'.>`
+- **Recommended Agent**: `<Agent Name if Fail, or 'None' if Pass>`
+- **Fix Instructions**: `<specific description of what needs to be fixed if Fail, or 'None' if Pass>`
+- **Action for Orchestrator**: I have completed my verification. Please refer to your central rules to determine the next step in the workflow (e.g. re-invoke developer, invoke memory keeper, or stop).
 ```

package/{create-agent-launcher → multi-agent-workspace}/templates/tool-maker.md

@@ -1,33 +1,33 @@
----
-name: "Tool Maker"
-description: "Use when: a repetitive or error-prone task (like file parsing, data extraction, or log analysis) needs to be automated via a small script to make the AI's autonomous capabilities more reliable."
-{{TOOLS_ARRAY_DECLARATION}}
----
-
-You are the Tool Maker Agent for the **{{PROJECT_NAME}}** project. Your job is to create small, reliable, and reusable utility scripts (e.g., Python, Node.js, bash) that help the AI system bypass limitations or handle brittle operations (like complex file reading or text processing).
-
-## Constraints
-
-- DO NOT implement core application features.
-- DO NOT modify existing application source code unless it's a dedicated utility script directory (e.g., `scripts/ai_tools/`).
-- Scripts must be self-contained and require minimal external dependencies.
-- Scripts must be designed to be run from a standard terminal (CLI).
-- Output of the scripts must be clean, parsable, and AI-friendly (e.g., JSON or clear structured text).
-
-## Approach
-
-1. **Understand the Bottleneck**: Read the context provided by the Orchestrator regarding what operation is failing or is too repetitive (e.g., "The AI keeps failing to read line ranges in large CSVs").
-2. **Design the Tool**: Choose the appropriate scripting language (usually Python or Node.js depending on the project stack). Ensure it takes clear command-line arguments.
-3. **Implement**: Write the script and save it to the project's scripts directory (e.g., `{{SCRIPTS_DIR}}/`).
-4. **Test**: Run the script using the terminal to verify it works exactly as intended and handles edge cases (like file not found).
-5. **Document**: Add a brief usage example as a comment at the top of the script so other agents know how to use it.
-
-## Output Format
-
-```
-### 🛠️ Tool Created
-- **Tool Path**: `<path to the script>`
-- **Usage Command**: `<example command to run it>`
-- **Purpose**: <Brief description of what it solves>
-- **Action for Orchestrator**: Please pass this tool information back to the agent that requested it, or proceed with the workflow.
+---
+name: "Tool Maker"
+description: "Use when: a repetitive or error-prone task (like file parsing, data extraction, or log analysis) needs to be automated via a small script to make the AI's autonomous capabilities more reliable."
+{{TOOLS_ARRAY_DECLARATION}}
+---
+
+You are the Tool Maker Agent for the **{{PROJECT_NAME}}** project. Your job is to create small, reliable, and reusable utility scripts (e.g., Python, Node.js, bash) that help the AI system bypass limitations or handle brittle operations (like complex file reading or text processing).
+
+## Constraints
+
+- DO NOT implement core application features.
+- DO NOT modify existing application source code unless it's a dedicated utility script directory (e.g., `scripts/ai_tools/`).
+- Scripts must be self-contained and require minimal external dependencies.
+- Scripts must be designed to be run from a standard terminal (CLI).
+- Output of the scripts must be clean, parsable, and AI-friendly (e.g., JSON or clear structured text).
+
+## Approach
+
+1. **Understand the Bottleneck**: Read the context provided by the Orchestrator regarding what operation is failing or is too repetitive (e.g., "The AI keeps failing to read line ranges in large CSVs").
+2. **Design the Tool**: Choose the appropriate scripting language (usually Python or Node.js depending on the project stack). Ensure it takes clear command-line arguments.
+3. **Implement**: Write the script and save it to the project's scripts directory (e.g., `{{SCRIPTS_DIR}}/`).
+4. **Test**: Run the script using the terminal to verify it works exactly as intended and handles edge cases (like file not found).
+5. **Document**: Add a brief usage example as a comment at the top of the script so other agents know how to use it.
+
+## Output Format
+
+```
+### 🛠️ Tool Created
+- **Tool Path**: `<path to the script>`
+- **Usage Command**: `<example command to run it>`
+- **Purpose**: <Brief description of what it solves>
+- **Action for Orchestrator**: Please pass this tool information back to the agent that requested it, or proceed with the workflow.
 ```

package/multi-agent-workspace/workflows/01-init.md

@@ -0,0 +1,22 @@
+# Phase 1: Platform & Location Preferences
+
+**[State Checkpoint]**
+- Verify the `Target Directory` absolute path passed from the initial context.
+
+## [Discovery & Inquiry Phase]
+1. Target Selection: First, auto-detect the current environment and target platform (`[Discover]`).
+   - Supported target platforms and enforcement levels: see [README § Supported AI IDEs & Tools](../../README.md#supported-ai-ides--tools) (platform-specific scaffold guidance lives in `guidelines/platform-<platform>.md`, listed above). Only **Claude Code** supports hard enforcement via native lifecycle hooks (`exit 2`); all other target platforms operate via prompt-based advisory rules.
+   - If interactive inquiry tools (like `vscode_askQuestions`) are available, confirm platform and scope location (Project Level vs Global Level) with the user.
+   - If running in a non-interactive terminal or without GUI inquiry tools, proceed with the auto-detected platform and default to Project Level location.
+
+## [Validation & Research Phase]
+2. Load Guidelines: Read `guidelines/platform-<platform>.md` corresponding to the chosen platform. Treat this local file as the primary source of truth. Avoid unnecessary web searches unless platform APIs are ambiguous.
+3. Conflict Assessment: Use the loaded layout rules to check if existing agents are already present in the target location within the `Target Directory`.
+
+## [Action Phase: Conflict Resolution]
+4. Preference Gathering: If interactive inquiry tools are available, confirm Resilience Features configuration; otherwise default to standard resilience.
+5. Conflict Strategy: If existing agents are found, confirm the Conflict Resolution strategy (Safe Update by default, Backup & Overwrite, or Smart Merge).
+
+## [Record: Handoff]
+6. State Packaging: Record the selected `Platform`, `Location`, `Resilience Features`, and `Conflict Strategy`.
+7. Handoff: Load and execute `workflows/02-analysis.md`, passing these variables alongside `Target Directory`.

package/multi-agent-workspace/workflows/02-analysis.md

@@ -0,0 +1,23 @@
+# Phase 2: Project Analysis
+
+**[State Checkpoint]**
+- Verify inheritance of `Target Directory`, `Platform`, `Location`, `Resilience Features`, and `Conflict Strategy` from Phase 1.
+
+## [Discovery Phase: Content Extraction]
+1. Discovery Guide: Read `reference.md` for guidance on repo scanning.
+2. Target Scanning: Scan `Target Directory` for `README.md`, `AGENTS.md` (or `CLAUDE.md`), and build configuration files (e.g. `package.json`, `*.sln`).
+3. Safe Extraction: Read discovered files to extract project name, tech stack, build commands, and architectural conventions. Skip missing optional files gracefully.
+4. Abstraction: Synthesize extracted signals into a concise `Context Profile` to manage context window usage.
+
+## [Elimination & Evaluation Phase]
+5. Stack Detection: Determine the tech stack based on project files (e.g. `.csproj` for C#, `package.json` for Node/TS).
+6. Scope Limiting: Check for monorepo configuration (`pnpm-workspace.yaml`, `nx.json`).
+   - For monorepos, prompt the user to specify the target package/app rather than scaffolding blindly for the entire repository.
+7. Subagent Proposal: Recommend relevant specialist roles based on detected files (e.g. Shell Expert if `.sh` scripts exist). Avoid duplicating core agent roles.
+
+## [Action Phase: User Confirmation & Gap Analysis]
+8. Selection: Present recommended Subagent options to the user (e.g. Requirement Analyzer, Backend Developer, Task Verifier, plus detected specialists).
+9. Batch Requirements Check: Check selected templates for required placeholders (e.g. `{{DB_TYPE}}`). If missing from `Context Profile`, request missing inputs in one concise inquiry.
+
+## [Record: Handoff]
+10. Handoff: Load and execute `workflows/03-generation.md`, passing the `Context Profile`, `Selected Agents`, and all Phase 1 variables.

package/multi-agent-workspace/workflows/03-generation.md

@@ -0,0 +1,27 @@
+# Phase 3: Scaffold Generation
+
+**[State Checkpoint]**
+- Verify inheritance of `Target Directory`, `Context Profile`, `Selected Agents`, and Phase 1 variables (`Platform`, `Conflict Strategy`, etc.).
+- Ensure directory context matches `Target Directory` before performing file modifications.
+
+## [Preparation Phase]
+1. Merge Strategy: Apply the `Conflict Strategy` chosen in Phase 1 without blindly overwriting existing files.
+   - If `Smart Merge` is chosen but the target agent belongs to a different platform architecture, default to `Backup & Overwrite` to avoid cross-platform configuration conflicts.
+2. Semantic Integrity: For Smart Merge, align updates with logical consistency, memory management, and verification guardrails while preserving original YAML frontmatter.
+
+## [Action Phase: Generation]
+3. Template Iteration: Process selected agents iteratively to manage context usage:
+   - Read the corresponding template for each chosen role.
+   - If merging into an existing file, read the target file first to preserve custom configuration.
+   - Inject cognitive guardrails: role boundaries, shared memory references (`memory-keeper`), and outcome verification guidelines.
+   - Align generated prompts with target platform capabilities (e.g. VS Code Copilot, Cursor, Claude Code) and appropriate task-tracking frameworks.
+   - Substitute placeholders using the `Context Profile`. If a placeholder remains unresolved, insert a clear comment tag (e.g. `// TODO: Manual configuration needed`).
+   - Save generated files to paths defined in `guidelines/platform-<platform>.md`.
+4. Orchestrator Generation: Consult `guidelines/platform-<platform>.md` for Orchestrator requirements and update central prompts if necessary.
+
+## [Summarize & Verification Phase]
+5. Integrity Check: Verify generated files exist on disk before reporting completion.
+
+## [Record: Exit]
+6. Completion: Record successful subagent scaffolding.
+7. Handoff: Load and execute `workflows/04-launcher.md`, passing the `Context Profile`, `Selected Agents`, and newly created file paths.

package/multi-agent-workspace/workflows/04-launcher.md

@@ -0,0 +1,16 @@
+# Phase 4: Launcher Bootstrapping
+
+**[State Checkpoint]**
+- Verify inheritance of `Target Directory`, `Context Profile`, `Selected Agents`, and newly created file paths from Phase 3.
+
+## [Action Phase: Entry Point Generation]
+1. Entry Point Generation: Read `templates/agent-launcher.md`.
+2. Handoff Integration: Substitute placeholders using the `Context Profile`. Dynamically inject the paths and roles of `Selected Agents` into the Launcher so it serves as an effective central router.
+3. Disk Write: Save the launcher entry point to the path specified in platform guidelines.
+
+## [Summarize: Verification]
+4. Check: Verify the Launcher was created successfully on disk.
+
+## [Record: Exit]
+5. Completion: Present a clean summary table listing generated agent files and their configured roles.
+6. UX Handoff: Provide the user with guidance on how to trigger or invoke their new agent scaffold.

package/opencode-plugin/README.md

@@ -0,0 +1,94 @@
+# Harness Enforcement Plugin for opencode
+
+This plugin adds hard enforcement gates for Harness skills in opencode, addressing the limitation that skills are advisory-only in this platform.
+
+## Problem
+
+In Claude Code, Harness hooks ENFORCE rules (hard gate). In opencode, skills only SUGGEST rules (soft guidance). This means:
+- Under pressure, agents can bypass skills
+- Verification can be skipped
+- Circuit breaker patterns don't trigger
+
+## Solution
+
+This plugin implements three enforcement mechanisms:
+
+### 1. Post-Edit Verification Gate
+
+**File:** `hooks/post-edit.js`
+
+Records every edit and tracks verification status.
+
+### 2. Pre-Complete Verification Gate
+
+**File:** `hooks/pre-complete.js`
+
+Blocks completion until verification runs after edits.
+
+### 3. Circuit Breaker
+
+**File:** `hooks/circuit-breaker.js`
+
+Enforces Rule of 3:
+- Tracks failure signatures
+- Blocks edits after 3 failures on same signature
+- Requires reflection (zoom-out) before resuming
+
+### 4. Compliance Monitor
+
+**File:** `hooks/compliance.js`
+
+Tracks compliance metrics:
+- Verification compliance rate
+- Circuit breaker trips
+- Pressure resistance metrics
+
+## Installation
+
+1. Copy `opencode-plugin/` to your opencode config directory
+2. Add to `opencode.json`:
+
+```json
+{
+  "plugins": ["./opencode-plugin"]
+}
+```
+
+## Configuration
+
+Edit `plugin.json` to configure:
+
+```json
+{
+  "config": {
+    "verificationRequired": true,
+    "circuitBreakerEnabled": true,
+    "maxRetries": 3,
+    "verificationCommands": ["npm test", "npm run lint", "npm run build"]
+  }
+}
+```
+
+## Expected Impact
+
+| Metric | Before | After (Expected) |
+|--------|--------|------------------|
+| Pressure pass rate | 0% | 80%+ |
+| Verification compliance | Unknown | 95%+ |
+| Circuit breaker enforcement | Advisory only | Hard gate |
+
+## Limitations
+
+1. **Requires opencode plugin support** - opencode must support post-edit hooks
+2. **State files in user home** - Uses `~/.harness-state/` for persistence
+3. **No cross-session state** - Each session starts fresh (by design)
+
+## Testing
+
+Run the behavioral evals to verify:
+
+```bash
+node behavioral-evals/run.js run --engine opencode
+```
+
+Expected improvement in pressure cases.

package/opencode-plugin/hooks/circuit-breaker.js

@@ -0,0 +1,121 @@
+#!/usr/bin/env node
+/**
+ * Circuit Breaker Hook
+ * 
+ * Enforces Rule of 3 for opencode.
+ * This hook tracks failures and enforces the circuit breaker pattern:
+ * 1. Tracks failure signatures
+ * 2. Blocks edits after 3 failures on same signature
+ * 3. Requires reflection (zoom-out) before resuming
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const STATE_DIR = path.join(process.env.HOME || process.env.USERPROFILE, '.harness-state');
+const BREAKER_FILE = path.join(STATE_DIR, 'circuit-breaker.json');
+
+function loadBreakerState() {
+  try {
+    if (fs.existsSync(BREAKER_FILE)) {
+      return JSON.parse(fs.readFileSync(BREAKER_FILE, 'utf8'));
+    }
+  } catch (e) {
+    // Ignore parse errors
+  }
+  return {
+    failures: {},
+    hardLock: false,
+    lastReflection: null
+  };
+}
+
+function saveBreakerState(state) {
+  fs.writeFileSync(BREAKER_FILE, JSON.stringify(state, null, 2));
+}
+
+function extractFailureSignature(errorOutput) {
+  // Simple signature extraction: first 100 chars of error
+  return errorOutput.slice(0, 100).replace(/\s+/g, ' ').trim();
+}
+
+function main() {
+  const state = loadBreakerState();
+  
+  // Read input from stdin (error output from failed command)
+  let input = '';
+  process.stdin.setEncoding('utf8');
+  process.stdin.on('data', (chunk) => input += chunk);
+  process.stdin.on('end', () => {
+    const signature = extractFailureSignature(input);
+    
+    if (state.hardLock) {
+      // Hard lock active - block all edits
+      console.log(JSON.stringify({
+        hook: 'circuit-breaker',
+        action: 'block',
+        reason: 'hard_lock',
+        message: 'Circuit breaker hard-locked. Run npm run harness:reset or start new session.',
+        signature
+      }));
+      process.exit(2);
+    }
+    
+    // Track failure
+    if (!state.failures[signature]) {
+      state.failures[signature] = { count: 0, firstSeen: Date.now() };
+    }
+    
+    state.failures[signature].count++;
+    state.failures[signature].lastSeen = Date.now();
+    
+    // Check if we've hit the limit
+    if (state.failures[signature].count >= 3) {
+      // Check if reflection happened
+      if (state.lastReflection && state.lastReflection > state.failures[signature].firstSeen) {
+        // Reflection happened - this is a repeat trip = hard lock
+        state.hardLock = true;
+        saveBreakerState(state);
+        
+        console.log(JSON.stringify({
+          hook: 'circuit-breaker',
+          action: 'hard_lock',
+          reason: 'repeat_trip_after_reflection',
+          count: state.failures[signature].count,
+          message: 'Same failure after reflection. Hard-locked. Need human intervention.',
+          signature
+        }));
+        process.exit(2);
+      } else {
+        // No reflection yet - force reflection
+        // Save state first so next invocation knows count >= 3
+        saveBreakerState(state);
+        
+        console.log(JSON.stringify({
+          hook: 'circuit-breaker',
+          action: 'force_reflection',
+          reason: 'three_failures',
+          count: state.failures[signature].count,
+          message: '3 failures on same signature. Must reflect (zoom-out) before retrying.',
+          signature,
+          instructions: 'Write zoom-out-report.md with: Goal, Failed Attempts, Verified Facts, Diagnosis, Decision'
+        }));
+        process.exit(2);
+      }
+    }
+    
+    // Under limit - allow but warn
+    saveBreakerState(state);
+    
+    console.log(JSON.stringify({
+      hook: 'circuit-breaker',
+      action: 'allow',
+      count: state.failures[signature].count,
+      remaining: 3 - state.failures[signature].count,
+      message: `Failure ${state.failures[signature].count}/3. ${3 - state.failures[signature].count} retries remaining.`,
+      signature
+    }));
+  });
+}
+
+main();

package/opencode-plugin/hooks/compliance.js

@@ -0,0 +1,128 @@
+#!/usr/bin/env node
+/**
+ * Compliance Monitoring Hook
+ * 
+ * Tracks compliance metrics for Harness skills.
+ * This hook monitors and reports:
+ * 1. Verification compliance rate
+ * 2. Circuit breaker trips
+ * 3. Pressure resistance metrics
+ */
+
+const fs = require('fs');
+const path = require('path');
+
+const STATE_DIR = path.join(process.env.HOME || process.env.USERPROFILE, '.harness-state');
+const COMPLIANCE_FILE = path.join(STATE_DIR, 'compliance.json');
+
+function loadCompliance() {
+  try {
+    if (fs.existsSync(COMPLIANCE_FILE)) {
+      return JSON.parse(fs.readFileSync(COMPLIANCE_FILE, 'utf8'));
+    }
+  } catch (e) {
+    // Ignore parse errors
+  }
+  return {
+    sessionStart: Date.now(),
+    totalEdits: 0,
+    verifiedEdits: 0,
+    blockedAttempts: 0,
+    circuitBreakerTrips: 0,
+    reflectionsForced: 0,
+    pressureResistanceAttempts: 0,
+    pressureResistanceSuccesses: 0
+  };
+}
+
+function saveCompliance(state) {
+  fs.writeFileSync(COMPLIANCE_FILE, JSON.stringify(state, null, 2));
+}
+
+function main() {
+  const compliance = loadCompliance();
+  
+  // Read event from stdin
+  let input = '';
+  process.stdin.setEncoding('utf8');
+  process.stdin.on('data', (chunk) => input += chunk);
+  process.stdin.on('end', () => {
+    try {
+      const event = JSON.parse(input);
+      
+      // Update compliance based on event
+      switch (event.hook) {
+        case 'post-edit-verification':
+          compliance.totalEdits++;
+          break;
+          
+        case 'pre-complete-verification':
+          if (event.action === 'block') {
+            compliance.blockedAttempts++;
+          }
+          break;
+          
+        case 'verification-runner':
+          if (event.allPassed) {
+            compliance.verifiedEdits++;
+          }
+          break;
+          
+        case 'circuit-breaker':
+          if (event.action === 'force_reflection') {
+            compliance.circuitBreakerTrips++;
+            compliance.reflectionsForced++;
+          } else if (event.action === 'hard_lock') {
+            compliance.circuitBreakerTrips++;
+          }
+          break;
+          
+        case 'pressure-resistance':
+          compliance.pressureResistanceAttempts++;
+          if (event.resisted) {
+            compliance.pressureResistanceSuccesses++;
+          }
+          break;
+      }
+      
+      // Calculate metrics
+      const verificationRate = compliance.totalEdits > 0 
+        ? (compliance.verifiedEdits / compliance.totalEdits * 100).toFixed(1)
+        : 0;
+      
+      const pressureResistanceRate = compliance.pressureResistanceAttempts > 0
+        ? (compliance.pressureResistanceSuccesses / compliance.pressureResistanceAttempts * 100).toFixed(1)
+        : 0;
+      
+      saveCompliance(compliance);
+      
+      // Output compliance report
+      console.log(JSON.stringify({
+        hook: 'compliance-monitor',
+        action: 'report',
+        metrics: {
+          totalEdits: compliance.totalEdits,
+          verifiedEdits: compliance.verifiedEdits,
+          verificationRate: `${verificationRate}%`,
+          blockedAttempts: compliance.blockedAttempts,
+          circuitBreakerTrips: compliance.circuitBreakerTrips,
+          reflectionsForced: compliance.reflectionsForced,
+          pressureResistanceAttempts: compliance.pressureResistanceAttempts,
+          pressureResistanceSuccesses: compliance.pressureResistanceSuccesses,
+          pressureResistanceRate: `${pressureResistanceRate}%`
+        },
+        message: `Verification: ${verificationRate}% | Pressure Resistance: ${pressureResistanceRate}%`
+      }));
+      
+    } catch (e) {
+      // Invalid input
+      console.log(JSON.stringify({
+        hook: 'compliance-monitor',
+        action: 'error',
+        message: 'Invalid event data'
+      }));
+    }
+  });
+}
+
+main();