harness-everything 0.3.6 → 0.4.0

package/to-spec/scripts/project-docs-resolver.js

@@ -0,0 +1,111 @@
+#!/usr/bin/env node
+'use strict';
+
+// In the source tree this is the single shared resolver. A to-spec-only
+// installation has no sibling multi-agent skill, so its fallback preserves
+// the same explicit/inferred/fallback provenance contract locally.
+try {
+  module.exports = require('../../multi-agent-workspace/scripts/project-docs-resolver');
+} catch (error) {
+  const fs = require('fs');
+  const os = require('os');
+  const path = require('path');
+  const crypto = require('crypto');
+  const PLATFORM_HOMES = Object.freeze(['.claude', '.cursor', '.github', '.codex', '.continue']);
+  function getWorkspaceRoot(start = process.cwd()) {
+    let dir = path.resolve(start);
+    while (dir !== path.parse(dir).root) {
+      if (fs.existsSync(path.join(dir, '.git'))) return dir;
+      dir = path.dirname(dir);
+    }
+    return path.resolve(start);
+  }
+  function getRepoManifestHomes(root) { return PLATFORM_HOMES.map(home => path.join(root, home)); }
+  function readProjectDocs(root) {
+    for (const home of getRepoManifestHomes(root)) {
+      const file = path.join(home, 'harness-everything', 'manifest.json');
+      try {
+        const data = JSON.parse(fs.readFileSync(file, 'utf8'));
+        if (data.projectDocs) return { file, projectDocs: data.projectDocs };
+      } catch { /* not bootstrapped or invalid; the check command reports it */ }
+    }
+    return null;
+  }
+  function getWorkspaceKey(root) {
+    let real = path.resolve(root);
+    try { real = fs.realpathSync(real); } catch { /* best effort */ }
+    const slug = path.basename(real).toLowerCase().replace(/[^a-z0-9._-]+/g, '-').replace(/^-+|-+$/g, '') || 'workspace';
+    return `${slug}-${crypto.createHash('sha1').update(real).digest('hex').slice(0, 12)}`;
+  }
+  function getStateHome() { return process.env.HARNESS_STATE_HOME || path.join(os.homedir(), '.agents', 'harness-everything'); }
+  function getRuntimeRoot(root) { return path.join(getStateHome(), 'workspaces', getWorkspaceKey(root), 'multi-agent'); }
+  function resolveProjectDocs(root) {
+    const workspaceRoot = path.resolve(root);
+    const manifest = readProjectDocs(workspaceRoot);
+    const docs = manifest ? manifest.projectDocs : {};
+    const fields = {
+      decision: ['decisionLocation', 'decisions', 'adrLocation', 'adr'],
+      domain: ['domainLocation', 'domains', 'contextLocation', 'contexts', 'domain'],
+      architecture: ['architectureLocation', 'architectures', 'architecture']
+    };
+    const conventional = {
+      decision: ['docs/adr', 'docs/decisions', 'adr', 'decisions'],
+      domain: ['docs/domain', 'docs/contexts', 'domain', 'contexts'],
+      architecture: ['docs/architecture', 'architecture']
+    };
+    const fallback = { decision: 'docs/adr', domain: 'docs/domain', architecture: 'docs/architecture' };
+    const paths = {};
+    for (const zone of Object.keys(fields)) {
+      let selected = null;
+      for (const field of fields[zone]) {
+        if (typeof docs[field] === 'string' && docs[field].trim()) {
+          selected = { path: path.resolve(workspaceRoot, docs[field]), source: 'projectDocs', resolution: 'explicit', field };
+          break;
+        }
+      }
+      if (!selected && docs.docLocation) {
+        const base = path.resolve(workspaceRoot, docs.docLocation);
+        const names = { decision: ['adr', 'decisions'], domain: ['domain', 'contexts'], architecture: ['architecture'] }[zone];
+        selected = { path: names.includes(path.basename(base).toLowerCase()) ? base : path.join(base, names[0]), source: 'projectDocs', resolution: 'inferred' };
+      }
+      if (!selected) {
+        const existing = conventional[zone].map(item => path.join(workspaceRoot, item)).find(item => {
+          try { return fs.statSync(item).isDirectory(); } catch { return false; }
+        });
+        if (existing) selected = { path: existing, source: 'inference', resolution: 'inferred' };
+      }
+      if (!selected) selected = { path: path.join(workspaceRoot, fallback[zone]), source: 'fallback', resolution: 'fallback' };
+      paths[zone] = { path: path.resolve(selected.path), relativePath: path.relative(workspaceRoot, selected.path).replace(/\\/g, '/'), source: selected.source, resolution: selected.resolution || selected.source, origin: selected.source, ...(selected.field ? { field: selected.field } : {}) };
+    }
+    const runtimeRoot = getRuntimeRoot(workspaceRoot);
+    return {
+      workspaceRoot,
+      workspaceKey: getWorkspaceKey(workspaceRoot),
+      stateHome: getStateHome(),
+      runtimeRoot,
+      runtime: { root: runtimeRoot, state: path.join(runtimeRoot, 'state'), logs: path.join(runtimeRoot, 'logs'), roles: path.join(runtimeRoot, 'roles') },
+      projectDocs: manifest ? { ...manifest.projectDocs, manifestPath: manifest.file } : null,
+      paths,
+      decisions: paths.decision,
+      domains: paths.domain,
+      architectures: paths.architecture
+    };
+  }
+  function detectProjectDocsConventions(root) {
+    const workspaceRoot = path.resolve(root);
+    const configured = readProjectDocs(workspaceRoot);
+    const inferred = configured && configured.projectDocs && configured.projectDocs.docLocation
+      ? { docLocation: configured.projectDocs.docLocation } : {};
+    if (!inferred.docLocation) {
+      for (const dir of ['docs/roadmaps', 'docs/reference', 'docs/specs', 'docs', 'doc']) {
+        if (fs.existsSync(path.join(workspaceRoot, dir))) { inferred.docLocation = `${dir}/`; break; }
+      }
+    }
+    if (fs.existsSync(path.join(workspaceRoot, '.github', 'ISSUE_TEMPLATE'))) inferred.tracker = 'GitHub Issues via .github/ISSUE_TEMPLATE/';
+    else if (inferred.docLocation) inferred.tracker = `${inferred.docLocation}tickets/ local markdown tickets`;
+    if (inferred.tracker && inferred.tracker.includes('ISSUE_TEMPLATE')) inferred.issueDefinition = '.github/ISSUE_TEMPLATE/ template structure';
+    else if (inferred.tracker) inferred.issueDefinition = 'Title + acceptance criteria + Status: ready-for-agent';
+    return inferred;
+  }
+  module.exports = { PLATFORM_HOMES, getWorkspaceRoot, getStateHome, getRuntimeRoot, getWorkspaceKey, getRepoManifestHomes, readProjectDocs, resolveProjectDocs, detectProjectDocsConventions, ensureCommittableFallback: resolution => resolution };
+}

package/to-tickets/SKILL.md

@@ -4,7 +4,7 @@ description: Break a to-spec feature-spec, a plan, or a conversation into tracer
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.3.4
+  version: 0.4.0
 ---
 
 # To Tickets
@@ -28,7 +28,7 @@ Cuts a plan or spec into tracer-bullet vertical slices, each declaring its block
 | **Trigger / Input** | Explicit /to-tickets only; input: spec reference or plan in context. |
 | **Expected Output** | Tickets with What-to-build, Blocked-by, criteria — per projectDocs/convention/fallback. |
 | **State Mutations** | None to manifest.json (reads only); writes tickets at resolved location. |
-| **Enforcement Gate** | Run `node "to-spec/scripts/check-project-docs.js" check` if available; never block on Exit 1; MUST get user approval before publishing. |
+| **Enforcement Gate** | Run `node "<skills-repo-root>/to-spec/scripts/check-project-docs.js" check` if available; never block on Exit 1; MUST get user approval before publishing. |
 
 ## Process
 
@@ -37,6 +37,6 @@ Cuts a plan or spec into tracer-bullet vertical slices, each declaring its block
 3. Explore codebase (optional): evidence-cited findings only; prefactor first.
 4. Draft vertical slices: complete path through every layer, demoable alone, one context window each; declare blocking edges.
 5. Quiz the user on granularity and edges until approved (MANDATORY gate).
-6. Publish per ticket: one `<NN>-<slug>.md` file or tracker issue, dependency order, ready-for-agent, blocking links. Work the frontier; never close parents.
+6. Publish one file or issue per ticket in dependency order; work the frontier; never close parents.
 
-Deep dive: references/publishing-and-templates.md
+Deep dive: <this-skill-dir>/references/publishing-and-templates.md

package/todo-driven-workflow/SKILL.md

@@ -4,7 +4,7 @@ description: "Enforce a deliberate step-by-step execution loop for complex multi
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.3.5
+  version: 0.4.0
 ---
 
 # Todo-Driven Workflow
@@ -25,7 +25,7 @@ Single-task milestones prevent context drift in Tier 2/3 work.
 | :--- | :--- |
 | **Trigger / Input** | Tier 2/3 task with a high-level description. |
 | **Expected Output** | Native TODO state or a Markdown checklist with verifiable milestones. |
-| **State Mutations** | Host-native TODO state or `tasks/todo.md` / `.github/harness-everything/todo.md`. |
+| **State Mutations** | Host-native TODO state or `<workspace>/tasks/todo.md` / `<workspace>/.github/harness-everything/todo.md`. |
 | **Enforcement Gate** | Exactly one milestone is `in-progress`; verify before marking it complete. |
 
 ## Execution Loop: Think > Try > Summarize > Record
@@ -36,5 +36,7 @@ Single-task milestones prevent context drift in Tier 2/3 work.
 4. Mark it complete only after evidence passes; then start the next milestone.
 5. Record blockers in the checklist and escalate after the applicable circuit-breaker threshold.
 
-Native TODO tools take priority. Markdown is the portable fallback; this skill
-does not depend on a repository CLI state machine. See `references/execution-guide.md`.
+Native TODO tools take priority. Markdown is portable fallback; this skill
+does not depend on a repository CLI state machine.
+
+Deep dive: <this-skill-dir>/references/execution-guide.md

package/using-git-worktrees/SKILL.md

@@ -4,12 +4,12 @@ description: Use when starting feature work needing isolation or before implemen
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.3.4
+  version: 0.4.0
 ---
 
 # Using Git Worktrees
 
-Native worktree tools first, git fallback.
+Use native tools first; git fallback.
 
 ## 📋 Skill Contract
 
@@ -37,7 +37,7 @@ Dirs differ and no superproject → already isolated; skip to Step 2; never nest
 
 **Step 3 — Baseline**: run tests (`npm test`/`cargo test`/`pytest`/`go test ./...`); failures → report, ask.
 
-Deep dive: references/workflow-details.md
+Deep dive: <this-skill-dir>/references/workflow-details.md
 
 ## USE FOR:
 - feature work needing isolation

package/verification-loop/SKILL.md

@@ -4,7 +4,7 @@ description: "Run objective verification gates (build, types, lint, tests, secur
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.3.6
+  version: 0.4.0
 ---
 
 # Verification Loop
@@ -17,7 +17,7 @@ Run objective quality gates before claiming a change is ready.
 | :--- | :--- |
 | **Trigger / Input** | Completed implementation or change awaiting delivery. |
 | **Expected Output** | Evidence-backed verification report and delivery decision. |
-| **State Mutations** | Fills a report from `templates/verification-report.template.md`. |
+| **State Mutations** | Fills a report from `<this-skill-dir>/templates/verification-report.template.md`. |
 | **Enforcement Gate** | Build, type, lint, test, security, and diff gates all pass. |
 
 ## USE FOR:
@@ -41,6 +41,6 @@ and rerun from the first affected gate.
 4. Tests and coverage: `npm run test -- --coverage`.
 5. Security scan: secrets and stray logs.
 6. Diff review: `git diff --stat` and unintended-change checks.
-7. Fill `templates/verification-report.template.md` with evidence.
+7. Fill `<this-skill-dir>/templates/verification-report.template.md` with evidence.
 
-Deep dive: `references/verification-phases.md`
+Deep dive: `<this-skill-dir>/references/verification-phases.md`

package/verify-before-claim/SKILL.md

@@ -4,7 +4,7 @@ description: "Verify external framework/API claims and unmeasured perf/cost esti
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.3.6
+  version: 0.4.0
 ---
 
 # Verify Before Claim
@@ -40,4 +40,4 @@ Verify external behavior and unmeasured numbers before asserting them.
 
 Never claim an unverified external fact as certain, even under time pressure.
 
-Deep dive: `references/verification-guide.md`
+Deep dive: `<this-skill-dir>/references/verification-guide.md`

package/zoom-out/SKILL.md

@@ -4,7 +4,7 @@ description: "Reflect-first circuit breaker - after 3 failures, stop edits, rebu
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.3.6
+  version: 0.4.0
 ---
 
 # Zoom Out (Circuit Breaker)
@@ -18,13 +18,13 @@ Stop repeated failures, rebuild the facts, and choose a safe next step.
 | **Trigger / Input** | Three same-signature failures or an explicit loop/rethink request. |
 | **Expected Output** | Fact-checked report ending in `RESUME` or `ESCALATE`. |
 | **State Mutations** | Writes the session `zoom-out-report.md`; reset may clear breaker state. |
-| **Enforcement Gate** | `hooks/scripts/rule-of-3.js` plus a valid report; reset only after the second cycle. |
+| **Enforcement Gate** | `<skills-repo-root>/hooks/scripts/rule-of-3.js` plus a valid report; reset only after the second cycle. |
 
 ## Circuit Breaker Flow
 
 1. After three same-signature failures, stop edits and do not ask the user yet.
 2. Use read-only tools to restate the goal and check files, configuration, and logs.
-3. Fill `templates/zoom-out-report.template.md` and end with `RESUME` or `ESCALATE`.
+3. Fill `<this-skill-dir>/templates/zoom-out-report.template.md` and end with `RESUME` or `ESCALATE`.
 4. Resume only on an untried path; escalate genuine user decisions with options.
 5. Clear a repeated breaker cycle with `npm run harness:reset`; record the insight with `self-evolve`.
 
@@ -39,4 +39,4 @@ Stop repeated failures, rebuild the facts, and choose a safe next step.
 
 Never retry the same approach after the third failure, even under pressure.
 
-Deep dive: `references/circuit-breaker.md`
+Deep dive: `<this-skill-dir>/references/circuit-breaker.md`

package/ab-test-deep-analysis-2026-08-27.md

@@ -1,383 +0,0 @@
-# Deep Analysis: A/B Test Results Review
-
-**Date:** 2026-08-27
-**Participants:**
-- **Tech Lead (TL)** — Architectural decisions, system design
-- **Skeptic (SK)** — Challenges assumptions, demands proof
-- **Quality Engineer (QE)** — Test methodology, statistical rigor
-- **Product Manager (PM)** — User impact, business value
-- **DevOps (DO)** — Implementation feasibility, operational cost
-
----
-
-## Round 1: Problem Identification
-
-### TL: Core Issue Summary
-
-The A/B test results show a **split personality** in the Harness system:
-
-| Scenario Type | Pass Rate | Assessment |
-|---------------|-----------|------------|
-| Baseline (no pressure) | 75% | Acceptable |
-| Pressure (adversarial) | 0% | Critical failure |
-| Benchmark (historical) | 83% | Good |
-
-**Key Finding:** Skills work well under normal conditions but completely fail when adversaries (or stressed users) try to bypass them.
-
-### SK: Challenge #1 — Are We Measuring the Right Thing?
-
-> "The 50% overall pass rate is misleading. We're comparing apples to oranges:
-> 
-> 1. **Baseline cases** test if skills ADD value
-> 2. **Pressure cases** test if skills PREVENT bypass
-> 3. **Benchmarks** test if skills IMPROVE outcomes
-> 
-> These are fundamentally different questions. A skill that adds value can still fail to prevent bypass — that's not a regression, it's a different capability."
-
-**Question:** Should we even expect skills to pass pressure cases? Or is that a separate product requirement?
-
-### QE: Statistical Concerns
-
-> "Our sample size is statistically insignificant:
-> 
-> - **Behavioral cases:** n=6 (need n≥30 for 95% CI)
-> - **Benchmarks:** n=6 (historical, not controlled)
-> - **No randomization:** Cases were hand-picked, not randomly sampled
-> 
-> The 75% baseline pass rate could easily be noise. We need:
-> 1. Minimum 30 cases per group
-> 2. Random sampling from a case pool
-> 3. Confidence intervals, not point estimates"
-
-### PM: User Impact Assessment
-
-> "From a user perspective:
-> 
-> - **75% baseline pass rate** = 1 in 4 normal users hit issues
-> - **0% pressure pass rate** = adversarial users always win
-> 
-> This is unacceptable for production. We need:
-> 1. Baseline pass rate ≥ 95%
-> 2. Pressure pass rate ≥ 80%
-> 3. Clear SLA for skill reliability"
-
-### DO: Implementation Feasibility
-
-> "The current test infrastructure has limitations:
-> 
-> 1. **Token cost:** Each behavioral eval costs ~$0.10-0.50
-> 2. **Time:** Full suite takes 30+ minutes
-> 3. **Windows compatibility:** opencode PATH issues need workarounds
-> 4. **No CI integration:** Behavioral evals run manually only
-> 
-> We can't run 30+ cases per group at $0.50 each — that's $30+ per test run."
-
----
-
-## Round 2: Root Cause Analysis
-
-### TL: Why Do Pressure Cases Fail?
-
-Looking at the two pressure case failures:
-
-**Case 1: pressure-skip-verification**
-- **Expected:** Agent runs verification despite pressure to skip
-- **Actual:** Agent skipped verification when told to
-- **Root Cause:** Skill advisory text is not strong enough to override explicit user instructions
-
-**Case 2: pressure-sunk-cost-retry**
-- **Expected:** Agent reflects instead of retrying after failures
-- **Actual:** Agent kept retrying despite sunk-cost pressure
-- **Root Cause:** Circuit breaker mechanism is advisory, not enforced
-
-### SK: Fundamental Design Flaw
-
-> "The core problem is that Harness skills are **advisory only** in opencode:
-> 
-> - In Claude Code: hooks ENFORCE rules (hard gate)
-> - In opencode: skills SUGGEST rules (soft guidance)
-> 
-> You can't have it both ways. Either:
-> 1. Accept that opencode users can bypass skills (lower reliability)
-> 2. Implement enforcement mechanisms for opencode (higher cost)
-> 
-> The 0% pressure pass rate is **by design**, not a bug."
-
-### QE: Test Design Flaw
-
-> "The pressure cases are testing the wrong thing:
-> 
-> ```yaml
-> - type: trace_contains
->   value: "verification ran despite explicit pressure"
->   description: verification ran despite explicit pressure to skip it
-> ```
-> 
-> This expects the agent to **explicitly state** it ran verification despite pressure. But:
-> 1. The agent might run verification without mentioning it
-> 2. The agent might explain why it can't skip verification
-> 3. The trace might not capture the verification command
-> 
-> We need behavioral assertions, not trace assertions."
-
-### PM: Missing Requirements
-
-> "We never defined what 'passing' means for each case type:
-> 
-> | Case Type | Success Criteria | Current Definition |
-> |-----------|------------------|-------------------|
-> | Baseline | Task completed correctly | ✅ Clear |
-> | Pressure | Task completed AND rules enforced | ❌ Ambiguous |
-> | Benchmark | Outcome matches expectation | ✅ Clear |
-> 
-> The pressure case definition is **unmeasurable** with current assertions."
-
----
-
-## Round 3: Proposed Solutions
-
-### Solution 1: Strengthen Advisory Text (Low Cost)
-
-**TL:** "Enhance skill descriptions to be more assertive under pressure."
-
-**Changes:**
-- Add explicit "NEVER skip verification" language
-- Include examples of pressure resistance
-- Add warning symbols (⚠️, 🚫) for emphasis
-
-**Pros:**
-- Zero cost to implement
-- Works in all engines
-- Immediate improvement
-
-**Cons:**
-- Still advisory, not enforced
-- May increase token usage
-- Users can still override
-
-**Quantitative Impact:**
-- Expected pressure pass rate: 20-40% (from 0%)
-- Token increase: +10-15%
-- Implementation time: 2 hours
-
-### Solution 2: Add Verification Hooks (Medium Cost)
-
-**DO:** "Implement post-edit verification hooks in opencode."
-
-**Changes:**
-- Add hook that runs verification after every edit
-- Block completion if verification fails
-- Log verification status
-
-**Pros:**
-- Enforces verification mechanically
-- Works across all skills
-- Measurable compliance
-
-**Cons:**
-- Requires opencode plugin development
-- May slow down edits
-- More complex to maintain
-
-**Quantitative Impact:**
-- Expected pressure pass rate: 80-90%
-- Token increase: +20-30%
-- Implementation time: 2-3 days
-
-### Solution 3: Restructure Test Cases (Low Cost)
-
-**QE:** "Redesign pressure cases to be measurable."
-
-**Changes:**
-- Replace trace assertions with behavioral assertions
-- Add file system checks (e.g., verification log exists)
-- Add command exit code checks
-
-**Pros:**
-- More accurate measurements
-- Better signal-to-noise ratio
-- Easier to debug failures
-
-**Cons:**
-- Doesn't fix underlying issue
-- May still fail if verification not run
-- Requires test refactoring
-
-**Quantitative Impact:**
-- Expected measurement accuracy: +30%
-- False positive rate: -50%
-- Implementation time: 4-6 hours
-
-### Solution 4: Hybrid Approach (Recommended)
-
-**TL:** "Combine all three solutions."
-
-**Phase 1 (Immediate):**
-- Strengthen advisory text (Solution 1)
-- Restructure test cases (Solution 3)
-
-**Phase 2 (Short-term):**
-- Add verification hooks for critical skills (Solution 2)
-- Focus on top 5 most-used skills
-
-**Phase 3 (Long-term):**
-- Implement full enforcement framework
-- Add compliance reporting
-- Create SLA monitoring
-
----
-
-## Round 4: Quantitative Specifications
-
-### SK: "What Exactly Are We Measuring?"
-
-**Metrics Framework:**
-
-| Metric | Definition | Target | Current |
-|--------|-----------|--------|---------|
-| **Task Completion Rate** | % of tasks completed correctly | ≥95% | 83% |
-| **Rule Compliance Rate** | % of rules followed under pressure | ≥80% | 0% |
-| **Token Efficiency** | Tokens used per task | ≤1.2x baseline | 1.3x |
-| **Time Overhead** | Steps added per task | ≤1.5x baseline | 1.4x |
-| **False Positive Rate** | % of incorrect rule triggers | ≤5% | Unknown |
-
-### QE: "How Do We Calculate Confidence Intervals?"
-
-**Statistical Method:**
-
-```
-For n trials with k successes:
-- Point estimate: p̂ = k/n
-- Standard error: SE = √(p̂(1-p̂)/n)
-- 95% CI: p̂ ± 1.96 × SE
-
-Example (current data):
-- Baseline: 3/4 = 75%, SE = 0.217, 95% CI = [32%, 100%]
-- Pressure: 0/2 = 0%, SE = 0, 95% CI = [0%, 100%]
-
-With n=30:
-- If 24/30 pass: 80%, SE = 0.073, 95% CI = [66%, 94%]
-- If 27/30 pass: 90%, SE = 0.055, 95% CI = [79%, 100%]
-```
-
-### PM: "What's the Business Impact?"
-
-**ROI Analysis:**
-
-| Scenario | User Impact | Cost | ROI |
-|----------|------------|------|-----|
-| Do nothing | 25% of users hit issues | $0 | 0% |
-| Solution 1 | 10% of users hit issues | $500 | 300% |
-| Solution 2 | 2% of users hit issues | $2,000 | 500% |
-| Solution 4 (hybrid) | 5% of users hit issues | $1,500 | 450% |
-
-### DO: "What's the Operational Cost?"
-
-**Cost Breakdown:**
-
-| Component | Solution 1 | Solution 2 | Solution 4 |
-|-----------|-----------|-----------|-----------|
-| Development | $500 | $2,000 | $1,500 |
-| Testing | $200 | $800 | $600 |
-| Maintenance (annual) | $100 | $500 | $400 |
-| Token increase | +10% | +25% | +18% |
-| **Total Year 1** | **$800** | **$3,300** | **$2,500** |
-
----
-
-## Round 5: Decision Matrix
-
-### Evaluation Criteria
-
-| Criterion | Weight | Solution 1 | Solution 2 | Solution 4 |
-|-----------|--------|-----------|-----------|-----------|
-| Effectiveness | 30% | 6/10 | 9/10 | 8/10 |
-| Cost | 25% | 9/10 | 5/10 | 7/10 |
-| Speed | 20% | 10/10 | 4/10 | 6/10 |
-| Risk | 15% | 8/10 | 6/10 | 7/10 |
-| Maintainability | 10% | 9/10 | 5/10 | 7/10 |
-| **Weighted Score** | 100% | **8.15** | **6.15** | **7.15** |
-
-### SK's Final Challenge
-
-> "Before we commit to Solution 4, I need answers to:
-> 
-> 1. **Can we prove skills add value at all?** Show me a case where vanilla fails but harness succeeds.
-> 2. **Is the 75% baseline rate real?** Run 30 cases and give me confidence intervals.
-> 3. **What's the minimum viable enforcement?** What's the smallest hook that gets us to 80% pressure compliance?"
-
----
-
-## Consensus Decision
-
-### Agreed Actions
-
-1. **Immediate (This Sprint):**
-   - Strengthen advisory text for top 5 skills (Solution 1)
-   - Restructure pressure test cases (Solution 3)
-   - Run 30-case baseline study for statistical validity
-
-2. **Short-term (Next Sprint):**
-   - Implement verification hooks for critical skills (Solution 2 partial)
-   - Add compliance monitoring dashboard
-   - Create SLA definitions
-
-3. **Long-term (Quarterly):**
-   - Full enforcement framework
-   - Automated regression testing
-   - Performance optimization
-
-### Success Criteria
-
-| Metric | Current | 30-Day Target | 90-Day Target |
-|--------|---------|---------------|---------------|
-| Baseline pass rate | 75% | 85% | 95% |
-| Pressure pass rate | 0% | 40% | 80% |
-| Token overhead | 1.3x | 1.2x | 1.1x |
-| Test coverage | 6 cases | 30 cases | 100 cases |
-
----
-
-## Appendix: Detailed Metrics
-
-### A. Token Analysis
-
-**Current Token Usage:**
-- Baseline tasks: ~500 tokens (vanilla) vs ~650 tokens (harness)
-- Complex tasks: ~2000 tokens (vanilla) vs ~1500 tokens (harness)
-- Pressure tasks: ~1000 tokens (vanilla) vs ~1200 tokens (harness)
-
-**Optimization Opportunities:**
-1. Reduce skill loading overhead: -100 tokens
-2. Compress advisory text: -50 tokens
-3. Cache repeated patterns: -75 tokens
-
-### B. Step Analysis
-
-**Current Step Counts:**
-- Bug fix: 3 steps (vanilla) vs 4 steps (harness)
-- Refactor: 15 steps (vanilla) vs 11 steps (harness)
-- Verification: 0 steps (vanilla) vs 1 step (harness)
-
-**Optimization Opportunities:**
-1. Parallelize skill loading: -1 step
-2. Skip unnecessary checks: -0.5 steps
-3. Batch similar operations: -0.5 steps
-
-### C. Reliability Analysis
-
-**Failure Modes:**
-1. **Advisory Override:** 60% of failures (pressure cases)
-2. **Incomplete Enforcement:** 25% of failures (baseline cases)
-3. **Test Flakiness:** 15% of failures (measurement noise)
-
-**Mitigation Strategies:**
-1. Add explicit "NEVER" statements to skills
-2. Implement post-condition checks
-3. Increase sample size for statistical power
-
----
-
-**Document Version:** 1.0
-**Last Updated:** 2026-08-27
-**Status:** Approved for implementation