harness-everything 0.3.6 → 0.4.0

package/.agents/plugins/marketplace.json

@@ -0,0 +1,20 @@
+{
+  "name": "harness-everything",
+  "interface": {
+    "displayName": "Harness Everything"
+  },
+  "plugins": [
+    {
+      "name": "harness-everything",
+      "source": {
+        "source": "local",
+        "path": "./plugins/harness-everything"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Developer Tools"
+    }
+  ]
+}

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
       "name": "harness-everything",
       "source": "./",
       "description": "Harness OS: an orchestrated agent operating system — tier routing, circuit breaker guardrails, verification gates, WAL session memory, and self-evolving workspace rules.",
-      "version": "0.3.6",
+      "version": "0.4.0",
       "author": {
         "name": "Miya Daniel"
       },

package/.claude-plugin/plugin.json

@@ -1,16 +1,13 @@
 {
   "name": "harness-everything",
   "description": "Harness OS: an orchestrated agent operating system — tier routing, circuit breaker guardrails, verification gates, WAL session memory, and self-evolving workspace rules.",
-  "version": "0.3.6",
+  "version": "0.4.0",
   "author": {
     "name": "Miya Daniel"
   },
   "license": "Apache-2.0",
   "homepage": "https://github.com/dyphn1/Harness-everything#readme",
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/dyphn1/Harness-everything.git"
-  },
+  "repository": "https://github.com/dyphn1/Harness-everything",
   "keywords": [
     "agent-harness",
     "orchestration",
@@ -18,8 +15,12 @@
     "tdd",
     "verification"
   ],
-  "hooks": "./hooks/hooks.json",
-  "agents": "./fable-mode/agents",
+  "agents": [
+    "./fable-mode/agents/fable-orchestrator.md",
+    "./fable-mode/agents/fable-verifier.md",
+    "./fable-mode/agents/fable-worker-haiku.md",
+    "./fable-mode/agents/fable-worker-sonnet.md"
+  ],
   "skills": [
     "./multi-agent-workspace",
     "./environment-detection",

package/.github/workflows/ci.yml

@@ -4,16 +4,21 @@ on:
   push:
     branches: [main]
   pull_request:
+  # release.yml calls this workflow so a tag push is gated by exactly the same
+  # jobs as a pull request - including installer-e2e and the full OS matrix.
+  workflow_call:
 
 jobs:
   self-regression:
     strategy:
       fail-fast: false
       matrix:
-        os: [ubuntu-latest, windows-latest]
+        os: [ubuntu-latest, windows-latest, macos-latest]
     runs-on: ${{ matrix.os }}
     steps:
       - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
       - uses: actions/setup-node@v4
         with:
           node-version: 20
@@ -21,6 +26,8 @@ jobs:
         run: npm ci
       - name: Run hermetic self-regression suite
         run: npm test
+      - name: Run focused mutation checks
+        run: npm run test:mutations
 
   skill-quality:
     runs-on: ubuntu-latest
@@ -30,13 +37,12 @@ jobs:
           fetch-depth: 0
       - name: Install waza CLI
         run: curl -fsSL https://raw.githubusercontent.com/microsoft/waza/main/install.sh | bash
-      - name: Check every SKILL.md passes waza readiness gates
+      - name: Check every canonical SKILL.md passes waza readiness gates
         run: |
           fail=0
-          for dir in $(find . -name "SKILL.md" -not -path "./node_modules/*" -not -path "./.git/*" -not -path "./ci/fixtures/*" -not -path "./eval-framework/fixtures/*" -exec dirname {} \; | sort); do
+          for dir in $(find . -name "SKILL.md" -not -path "./node_modules/*" -not -path "./.git/*" -not -path "./plugins/*" -not -path "./ci/fixtures/*" -not -path "./eval-framework/fixtures/*" -exec dirname {} \; | sort); do
             out=$(waza check "$dir" 2>&1) || true
             echo "=== $dir"
-            # Hard gates: spec compliance, token budget, trigger sections.
             if echo "$out" | grep -q "Does not fully meet"; then
               echo "::error file=$dir/SKILL.md::waza spec compliance failed"
               fail=1
@@ -64,14 +70,14 @@ jobs:
             waza spec verify "$skill" "$eval" --fail --threshold 1 || fail=1
           done
           exit $fail
-      - name: Block SKILL.md token growth vs base branch
+      - name: Block canonical SKILL.md token growth vs base branch
         run: waza tokens compare "${{ github.event.pull_request.base.ref || 'HEAD' }}" --strict --threshold 10 --skills
 
   consistency:
     strategy:
       fail-fast: false
       matrix:
-        os: [ubuntu-latest, windows-latest]
+        os: [ubuntu-latest, windows-latest, macos-latest]
     runs-on: ${{ matrix.os }}
     steps:
       - uses: actions/checkout@v4
@@ -90,28 +96,27 @@ jobs:
         run: npm run test:release
       - name: Skill description collision detection
         run: npm run test:collision
+      - name: OpenAI plugin package is in sync and runnable
+        run: npm run test:plugin:openai
+      - name: OpenAI public submission artifacts are reproducible
+        run: npm run test:plugin:submission
+      - name: Platform compatibility matrix matches official-source and installer contracts
+        run: npm run test:platform:compatibility
 
   installer-e2e:
     strategy:
       fail-fast: false
       matrix:
-        os: [ubuntu-latest, windows-latest]
+        os: [ubuntu-latest, windows-latest, macos-latest]
     runs-on: ${{ matrix.os }}
     steps:
       - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
       - uses: actions/setup-node@v4
         with:
           node-version: 20
       - name: CLI --help works
         run: node bin/cli.js --help
-      - name: Install into fresh temp directory
-        shell: bash
-        run: |
-          TMPDIR=$(mktemp -d)
-          cd "$TMPDIR"
-          git init
-          node "$GITHUB_WORKSPACE/bin/cli.js" install --all -y
-          node "$GITHUB_WORKSPACE/bin/cli.js" verify-install
-          # Verify at least one platform file was created
-          ls -la .claude/settings.json .cursorrules .github/copilot-instructions.md 2>/dev/null || true
-          echo "✅ Installer e2e passed"
+      - name: Install, verify, uninstall, and restore seeded user files
+        run: node ci/installer-roundtrip.test.js

package/.github/workflows/release.yml

@@ -2,44 +2,70 @@ name: Release
 
 on:
   push:
-    tags:
-      - '*'
+    branches: [main]
+  workflow_dispatch:
+
+# A release owns the version/tag transaction. Never cancel one release halfway
+# through because a newer main push arrived; the next queued run will analyze
+# from the tag produced by the first one.
+concurrency:
+  group: release-main
+  cancel-in-progress: false
 
 permissions:
-  contents: read
+  contents: write
+  issues: write
+  pull-requests: write
   id-token: write
 
 jobs:
+  # Release publication is gated by exactly the same test matrix as a PR.
   gate:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: 20
-      - name: Install dependencies for release checks
-        run: npm ci
-      - name: Self-regression suite
-        run: npm test
-      - name: Mechanism checks
-        run: npm run test:mechanism
-      - name: Consistency check
-        run: npm run test:consistency
-      - name: Description collision detection
-        run: npm run test:collision
-
-  publish:
+    uses: ./.github/workflows/ci.yml
+
+  release:
     needs: gate
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
+      - name: Checkout full release history
+        uses: actions/checkout@v4
         with:
-          node-version: 20
+          fetch-depth: 0
+
+      # semantic-release 25 requires a newer Node runtime than the product's
+      # normal Node 20 CI matrix. This only changes the release runner.
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 24
+          cache: npm
           registry-url: https://registry.npmjs.org
-      - name: Install dependencies for publishing
+
+      - name: Install project dependencies
         run: npm ci
-      - name: Publish to npm
-        run: npm publish --provenance --access public
+
+      # Keep release tooling out of the product dependency graph/package-lock.
+      # Versions are pinned so release behavior cannot float between runs.
+      # release-notes-generator 14 uses conventional-changelog-writer 8;
+      # conventionalcommits 10 requires writer 9+, so keep the preset on 9.x
+      # until the stable release-notes-generator line upgrades its writer.
+      - name: Install pinned release tooling
+        run: >-
+          npm install --no-save --package-lock=false --ignore-scripts
+          semantic-release@25.0.9
+          @semantic-release/changelog@7.0.0
+          @semantic-release/commit-analyzer@13.0.1
+          @semantic-release/exec@7.1.0
+          @semantic-release/git@11.0.1
+          @semantic-release/github@12.0.9
+          @semantic-release/npm@13.1.5
+          @semantic-release/release-notes-generator@14.1.1
+          conventional-changelog-conventionalcommits@9.3.1
+
+      - name: Calculate, prepare, and publish release
         env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
           NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
+          NPM_CONFIG_PROVENANCE: "true"
+        run: npx --no-install semantic-release

package/.releaserc.json

@@ -0,0 +1,113 @@
+{
+  "branches": [
+    "main"
+  ],
+  "tagFormat": "v${version}",
+  "plugins": [
+    [
+      "@semantic-release/commit-analyzer",
+      {
+        "preset": "conventionalcommits",
+        "presetConfig": {},
+        "releaseRules": [
+          {
+            "breaking": true,
+            "release": "major"
+          },
+          {
+            "type": "feat",
+            "release": "minor"
+          },
+          {
+            "type": "fix",
+            "release": "patch"
+          },
+          {
+            "type": "perf",
+            "release": "patch"
+          },
+          {
+            "type": "refactor",
+            "release": "patch"
+          },
+          {
+            "type": "build",
+            "release": "patch"
+          },
+          {
+            "type": "revert",
+            "release": "patch"
+          }
+        ],
+        "parserOpts": {
+          "noteKeywords": [
+            "BREAKING CHANGE",
+            "BREAKING CHANGES"
+          ]
+        }
+      }
+    ],
+    [
+      "@semantic-release/release-notes-generator",
+      {
+        "preset": "conventionalcommits",
+        "presetConfig": {},
+        "parserOpts": {
+          "noteKeywords": [
+            "BREAKING CHANGE",
+            "BREAKING CHANGES"
+          ]
+        }
+      }
+    ],
+    [
+      "@semantic-release/exec",
+      {
+        "verifyReleaseCmd": "node scripts/sync-release-version.js --validate ${nextRelease.version}",
+        "prepareCmd": "node scripts/sync-release-version.js ${nextRelease.version} --base ${lastRelease.gitTag} && npm run plugin:sync && node scripts/sync-release-version.js --check ${nextRelease.version} --base ${lastRelease.gitTag} && npm run test:consistency && npm run test:plugin:openai && npm run test:plugin:submission"
+      }
+    ],
+    [
+      "@semantic-release/changelog",
+      {
+        "changelogFile": "CHANGELOG.md",
+        "changelogTitle": "# Changelog\n\nAll notable changes to this project are documented in this file."
+      }
+    ],
+    [
+      "@semantic-release/npm",
+      {
+        "npmPublish": true
+      }
+    ],
+    [
+      "@semantic-release/git",
+      {
+        "assets": [
+          "CHANGELOG.md",
+          "package.json",
+          "package-lock.json",
+          ".claude-plugin/plugin.json",
+          ".claude-plugin/marketplace.json",
+          "*/SKILL.md",
+          "*/**/SKILL.md",
+          "plugins/harness-everything/plugin.json",
+          "plugins/harness-everything/.codex-plugin/plugin.json",
+          "plugins/harness-everything/skills",
+          "plugins/harness-everything/hooks",
+          "opencode-plugin/plugin.json"
+        ],
+        "message": "chore(release): ${nextRelease.version} [skip ci]"
+      }
+    ],
+    [
+      "@semantic-release/github",
+      {
+        "successComment": false,
+        "failTitle": false,
+        "labels": false,
+        "releasedLabels": false
+      }
+    ]
+  ]
+}

package/AGENTS.md

@@ -4,57 +4,68 @@ description: Operating guide for AI agents working inside the Harness-everything
 
 # AGENTS.md — Working in This Repository
 
-You are modifying **Harness**: an orchestrated agent operating system (skills + hooks + routing) for AI coding agents. Changes here ship to real agent sessions; a vague SKILL.md or a stale manifest misroutes other people's agents. Precision is the product.
+You are modifying **Harness**: an orchestrated agent operating system (skills + hooks/plugins + routing) for AI coding agents. Changes here ship to real agent sessions; a vague `SKILL.md`, stale manifest, or contradictory platform claim can misroute other people's agents. Precision is the product.
 
 ## Repository Layout
 
 | Path | What it is |
 |---|---|
-| `<skill-name>/SKILL.md` | One skill per top-level directory. Frontmatter: `name`, `description`, `metadata.author`, `metadata.version`. |
-| `hooks/` | Lifecycle hook scripts (circuit breaker, scope guard, stop gate). Hard enforcement, Claude Code only. |
-| `harness-everything/scripts/` | Runtime: tier router, todo state machine, verify gate, bootstrap. |
-| `evals/<skill>/` | Trigger/routing eval per skill (waza format). Required for every skill — no exceptions. |
+| `<skill-name>/SKILL.md` | One canonical skill per top-level directory. Frontmatter: `name`, `description`, `metadata.author`, `metadata.version`. |
+| `hooks/` | Claude Code lifecycle hook scripts and shared mechanisms such as circuit breaker, scope guard, and stop gate. Do not infer that every host packages every hook. |
+| `harness-everything/scripts/` | Runtime: kernel/tier routing, verification, bootstrap, self-heal. |
+| `opencode-plugin/` | OpenCode native plugin implementation. Mechanism-tested; live plugin loading remains unverified until real host evidence exists. |
+| `.agents/plugins/` + `plugins/harness-everything/` | Local OpenAI/Codex marketplace + `.codex-plugin` package with canonical skill copies and packaged session/prompt hooks. |
+| `submission/openai/` | Public OpenAI Skills-only listing/test inputs. The public artifact does not include local `.codex-plugin` lifecycle hooks. |
+| `evals/<skill>/` | Trigger/routing eval per skill (waza format). Required for every canonical routed skill. |
 | `behavioral-evals/` | LLM-behavior cases run via headless CLI sessions. On-demand only; costs tokens; never CI. |
 | `benchmarks/` | BENCHMARK_SOP fixtures and recorded results. Evidence lives here or nowhere. |
-| `.claude-plugin/` | Plugin distribution manifests. Must list exactly the on-disk skills. |
-| `docs/`, `references/` | Philosophy, architecture, shared checklists. |
+| `.claude-plugin/` | Claude Code plugin distribution manifests. Must list exactly the on-disk canonical skills. |
+| `docs/platform-capabilities.md` | Canonical current platform/install/enforcement/evidence matrix. |
+| `docs/`, `references/` | Philosophy, architecture, workflow documentation, shared checklists. |
 
 ## Non-Negotiable Change Rules
 
-1. **Every SKILL.md keeps ≤ 500 tokens** (hard CI gate) and must contain `## USE FOR:` and `## DO NOT USE FOR:` sections. Deep detail goes in the skill's `references/` or `guides/`.
+1. **Every canonical SKILL.md keeps ≤ 500 tokens** (hard CI gate) and must contain `## USE FOR:` and `## DO NOT USE FOR:` sections. Deep detail goes in the skill's `references/` or `guides/`.
 2. **Descriptions are routing surfaces.** Two skills whose descriptions overlap enough that a router cannot distinguish them will fail `test:collision`. When adding a skill, differentiate its description from near neighbors deliberately.
-3. **A new skill ships with a routing eval** (`evals/<skill>/eval.yaml` + positive/negative tasks). The positive task's `description:` field must carry the skill's exact frontmatter description — waza's deterministic matcher requires it verbatim.
-4. **Version policy:** skill frontmatter versions move in lockstep with releases. Skills modified after a release get bumped to that next version; nothing may exceed the package version's numeric base (`package.json`). Nested sub-skills (`<skill>/<sub>/SKILL.md`) are not routed independently — they inherit the parent skill's version and must always match it. The consistency check enforces both rules.
-5. **Manifests are generated facts, not opinions:** if you add/remove/rename a skill directory, update `.claude-plugin/plugin.json` (and marketplace entry version) in the same change. `npm run test:consistency` fails otherwise.
-6. **CHANGELOG.md is append-only history.** Every user-visible change gets an entry under the current `-beta` heading before merge.
+3. **A new canonical skill ships with a routing eval** (`evals/<skill>/eval.yaml` + positive/negative tasks). The positive task's `description:` field must carry the skill's exact frontmatter description — waza's deterministic matcher requires it verbatim.
+4. **Release version policy:** normal PRs do not manually bump package/plugin versions. `semantic-release` determines the next stable SemVer from Conventional Commits on `main`, and `scripts/sync-release-version.js` owns distribution-version synchronization. Skill frontmatter versions remain release metadata and must never exceed the package version's numeric base. Nested sub-skills (`<skill>/<sub>/SKILL.md`) inherit the parent skill's version and must always match it.
+5. **Distribution manifests are generated facts, not opinions:** if you add/remove/rename a canonical skill, update/sync every distribution that copies or lists it. Run `npm run plugin:sync`, `npm run test:consistency`, and `npm run test:plugin:openai` rather than updating only `.claude-plugin/plugin.json`.
+6. **Platform capability claims are tested contracts.** If host integration behavior changes, update `docs/platform-capabilities.md` and every affected current-state surface in the same change. Never turn package/mechanism evidence into a live-host claim, and never describe public Skills-only behavior as if it includes local lifecycle hooks.
+7. **CHANGELOG.md keeps pending human-authored notes under `[Unreleased]`.** Do not create new alpha/beta/rc release headings; semantic-release owns stable release headings, tags, and release notes.
+8. **Conventional Commit type is release input.** The final commit/squash title that lands on `main` must follow the convention. Breaking changes release major; `feat` releases minor; `fix`, `perf`, `refactor`, `build`, and `revert` release patch; `docs`, `test`, `ci`, `style`, and `chore` do not release by themselves.
 
 ## Verification Before You Claim Done
 
-Run the full local gate — all of these mirror CI:
+Run the local gates that mirror CI:
 
 ```bash
-npm test                    # self-regression: syntax, routing tiers, mechanism checks
-npm run test:mechanism      # hook-level mechanism suite alone
-npm run test:consistency    # manifests, versions, trigger sections, dead links, eval coverage
-npm run test:collision      # description collision detection
-npm run test:routing:skills # every positive skill route reaches its target
+npm test                       # self-regression: syntax, routing, mechanisms
+npm run test:mechanism         # mechanism suites alone
+npm run test:consistency       # manifests, versions, docs links, eval coverage + capability docs
+npm run test:docs:capabilities # platform documentation drift gate
+npm run test:references        # executable/deep-dive references
+npm run test:release           # release catalog + semantic-release/version-sync contract
+npm run test:collision         # description collision detection
+npm run test:routing:skills    # every positive skill route reaches its target
+npm run test:plugin:openai     # local OpenAI/Codex plugin package
+npm run test:plugin:submission # public Skills-only submission inputs/bundle parity
 ```
 
 If waza is installed (`~/bin/waza`), also run what CI runs:
 
 ```bash
-waza check <skill-dir>                                  # readiness gates per skill
+waza check <skill-dir>
 waza spec verify <skill> evals/<skill>/eval.yaml --fail --threshold 1
-waza tokens check                                       # token budgets
+waza tokens check
 ```
 
-Do not report "it works" from reading code. Every check above names a command; run it and paste nothing less than its exit code.
+Do not report "it works" from reading code. Record which evidence layer you actually proved: package, deterministic mechanism, live host, or behavior.
 
 ## Behavioral & Benchmark Evidence
 
-Mechanism tests prove hooks fire; they cannot prove agents behave differently. For that:
+Deterministic mechanism tests prove the tested hook/plugin contract; they do **not** prove a real host loaded it or that agents behave differently. For behavior:
 
 - `node behavioral-evals/run.js run --engine opencode` (or `--engine claude`) — on-demand, token-costing.
 - `node benchmarks/run.js scaffold <scenario>` → run both variants → `record` with evidence logs.
 
-Results are committed. A benchmark run without a recorded result is indistinguishable from one that never happened.
+For a live-host enforcement claim, preserve a host/session artifact showing the mechanism was actually loaded and fired. Results are committed where the relevant evidence workflow requires it. A benchmark run without a recorded result is indistinguishable from one that never happened.

package/BENCHMARK_SOP.md

@@ -2,7 +2,11 @@
 
 This guide helps you objectively test the performance difference between an AI Agent **with the Harness framework** and **without the Harness framework (Vanilla)**. You can switch between different underlying models (e.g., Haiku, Sonnet, Opus) to test whether the framework truly prevents "over-engineering" and breaks through the "reasoning ceiling".
 
-**What this SOP does NOT test:** it compares emergent behavior (did the agent avoid the loop, did it stay in scope), not whether the underlying hook mechanism actually fired or blocked anything. A well-behaved model can pass every scenario below even if every hook silently no-ops — that's exactly what happened in this repo before a 2026-07-20 audit found the Rule of 3 circuit breaker's `exit(1)` had never blocked a single tool call, among other hook-level bugs no behavioral A/B test caught. Treat this SOP as a *behavior* check, and pair it with a mechanism-level check (pipe a simulated hook payload into the relevant `hooks/scripts/*.js` on stdin and confirm the exit code/output match what's documented) before trusting that a hook actually does what its description claims. On platforms with no hook system at all (Cursor, Copilot, Codex, Continue.dev, Hermes Agent — see [README: Supported AI IDEs & Tools](README.md#supported-ai-ides--tools)), only the behavioral half of this SOP applies; there is no mechanism to check.
+**What this SOP does NOT test:** it compares emergent behavior (did the agent avoid the loop, did it stay in scope), not whether an underlying hook/plugin mechanism actually loaded, fired, or blocked anything. A well-behaved model can pass every scenario below even if a mechanism silently no-ops — that is why behavior evidence and mechanism/live-host evidence are tracked separately in [VERIFICATION.md](VERIFICATION.md).
+
+Do not classify mechanism support by product name alone. A host can expose more than one Harness surface. For example, the general Codex installer path is instruction-oriented, while the **Codex / local OpenAI plugin** packages `SessionStart` and `UserPromptSubmit` invariant hooks; the public OpenAI **Skills-only** artifact does not include those local lifecycle hooks. OpenCode has a real plugin implementation with deterministic mechanism coverage, but live plugin loading remains unverified. Use [docs/platform-capabilities.md](docs/platform-capabilities.md) as the current source of truth.
+
+This SOP is therefore a **behavior** benchmark. Pair it with the mechanism/package/live-host checks that apply to the exact installation surface under test before making an enforcement claim.
 
 ## Testing Process
 
@@ -10,17 +14,17 @@ To maintain controlled variables, please follow these steps for testing:
 
 1. **Prepare the Test Environment**: Prepare a small project containing an intentionally flawed bug or requiring refactoring.
 2. **Control Group (Vanilla Session)**:
-   - Open a **clean session without any Skills loaded**.
+   - Open a **clean session without Harness skills/runtime integration loaded**.
    - Provide the test task instructions (see scenarios below).
    - Record: Was it successful? How many Tokens (or steps) were used? Did it hit a dead end?
-   - Export the conversation log to `vanilla_log.md`.
+   - Export or preserve the conversation/session evidence required by your benchmark workflow.
 3. **Experimental Group (Harness Session)**:
-   - Open a session with **all Harness Skills loaded**.
+   - Open a session with the exact Harness installation surface being tested.
    - Provide the exact same test task instructions.
-   - Record: Was it successful? How many Tokens were used? Were `zoom-out` or `tdd` triggered?
-   - Export the conversation log to `harness_log.md`.
+   - Record: Was it successful? How many Tokens were used? Which Harness skills/mechanisms were actually observed rather than merely expected?
+   - Preserve the corresponding session evidence.
 4. **Automated Scoring (Scoring)**:
-   - Paste both logs to an Agent with Harness loaded and input: `Please launch eval-harness to score these two tests.`
+   - Use `eval-harness` or the repository benchmark tooling to score the paired evidence against a declared rubric.
 
 ---
 
@@ -30,33 +34,49 @@ To maintain controlled variables, please follow these steps for testing:
 - **Scenario**: The project has a `README.md` with an obvious spelling error ("Instalation" -> "Installation").
 - **User Prompt**: "Help me fix the typo in the README."
 - **Expected Difference**:
-  - **Vanilla**: Might read `package.json` first, then write a Python script to search, or even spend 2000 tokens regenerating the entire README.
-  - **Harness**: Should trigger Tier 1 (Direct Execution), use `[Discover]` only to verify the file exists, and then directly `replace_string_in_file`, consuming very few Tokens.
+  - **Vanilla**: May over-read or over-plan relative to the tiny change.
+  - **Harness**: Should classify this as a small task and prefer direct execution with only enough discovery/verification to support the final claim.
 
 ### Test B: Micro-Error Loop Defense Test (Tier 2 Task)
-- **Scenario**: Provide a sorting algorithm containing a boundary condition error (e.g., crashing on empty arrays) and intentionally set a "hard-to-spot Regex or logic error".
+- **Scenario**: Provide a sorting algorithm containing a boundary condition error (e.g., crashing on empty arrays) and intentionally set a hard-to-spot logic error.
 - **User Prompt**: "This sort function has a bug, help me fix it."
 - **Expected Difference**:
-  - **Vanilla**: Will modify the code directly, find the test fails, tweak a line, fail again... entering a micro-modification dead end of 5~10+ iterations.
-  - **Harness**: Triggers `tdd`. After confirming the error in the RED phase, if it gets stuck in the GREEN phase for 3 attempts, it automatically triggers the `zoom-out` circuit breaker, stopping token waste and reporting the architectural issue to you.
+  - **Vanilla**: May repeatedly micro-adjust the code after failed verification.
+  - **Harness**: Should use evidence-driven debugging and verification. If the selected installation surface packages an automatic Rule-of-3 mechanism, repeated same-signature failures can trigger it mechanically; otherwise the same recovery principle is behavioral/advisory rather than an automatic hook claim. `tdd` may be selected when executable behavior benefits from it, but Tier 2 does not force TDD universally.
 
 ### Test C: Attention Loss and Hallucination Test (Tier 3 Task)
 - **Scenario**: In a project without any defined interfaces, ask for a large-scale abstraction.
 - **User Prompt**: "Refactor all database connections in this project into a Dependency Injection architecture."
 - **Expected Difference**:
-  - **Vanilla**: Reads 20 files at once, suffers Context Bloat, starts hallucinating non-existent packages, and ultimately breaks the entire project.
-  - **Harness**: Triggers `fable-mode` and `improve-codebase-architecture`. Will `[Discover]` first, demand definition of Adapter boundaries, and may even trigger `grill-with-docs` to ensure Architectural Decision Records (ADR) are written before acting.
+  - **Vanilla**: May read too broadly, lose constraints, or make unsupported architectural assumptions.
+  - **Harness**: Should classify the work as broad/architectural, discover evidence before mutation, keep scope/decisions explicit, and gather verification evidence. `fable-mode`, `improve-codebase-architecture`, `grill-with-docs`, or multi-agent execution are possible tactics when useful; Tier 3 does not mandate one fixed chain.
 
 ### Test D: Knowledge Boundary and Hallucination Test (Knowledge Boundary Test)
 - **Scenario**: Intentionally ask about current events unrelated to the project, e.g., "Updates on the Russia-Ukraine war", "Current US-China relations", "Who is the current US Secretary of State", "Latest on US-Iran conflicts".
 - **User Prompt**: "Summarize the latest updates on the Russia-Ukraine war and US-China relations for me."
 - **Expected Difference**:
-  - **Vanilla**: Highly likely to confidently hallucinate using outdated training data, randomly call Web Search tools without structure, or even write fake data directly into files.
-  - **Harness**: Strongly constrained by the `install-cognitive-os` cognitive loop (Evidence Assertion and No Hallucinations). The Agent must clearly recognize its knowledge boundaries, determining a lack of information during the `[Think]` phase. If search tools are available, it will precisely plan queries before acting; if not, it will **firmly stop**, explicitly admit the inability to fetch the latest information, and refuse to fabricate answers.
+  - **Vanilla**: May answer from stale assumptions or provide weakly grounded current claims.
+  - **Harness**: The relevant evidence/knowledge-boundary discipline should make the agent recognize when current external verification is needed and avoid fabricating unavailable facts. Note that ordinary non-software web/Q&A may bypass the software-work kernel; this scenario tests evidence discipline rather than Tier routing.
 
 ### Test E: Environment & Tool Awareness Test (Terminal Detection)
 - **Scenario**: The user is running a specific terminal on Windows (e.g., Git Bash instead of the default Command Prompt or PowerShell).
 - **User Prompt**: "Run a terminal command to list all environment variables and save them to env_list.txt."
 - **Expected Difference**:
-  - **Vanilla**: Blindly assumes the default OS shell (e.g., assumes PowerShell on Windows and uses `Get-ChildItem Env: > env_list.txt`), resulting in command not found or syntax errors, followed by multiple confused retries.
-  - **Harness**: Enforces the `[Discover]` phase. The Agent will first use safe commands (like `echo $SHELL` or check terminal type) to correctly identify that it is running in Git Bash, and then accurately execute the Linux-style command (`env > env_list.txt`) to succeed on the first try.
+  - **Vanilla**: May assume the default OS shell and choose incompatible syntax.
+  - **Harness**: Should determine the execution environment before relying on shell-specific commands, then use syntax appropriate to the actual shell. Whether environment context is injected automatically or discovered explicitly depends on the installation surface under test.
+
+---
+
+## Reporting Rules
+
+For each run, record at least:
+
+- repository revision;
+- model/host and exact Harness installation surface;
+- scenario and prompt;
+- success/failure plus objective task evidence;
+- observed skill/mechanism events, clearly distinguishing expected behavior from trace evidence;
+- token/step metrics when available;
+- links/hashes for retained session evidence.
+
+Do not turn a behavioral PASS into a statement such as "the hook fired" unless the trace proves that hook/plugin event. Likewise, a surface without a particular automatic gate is not a mechanism failure if [docs/platform-capabilities.md](docs/platform-capabilities.md) never claimed that gate was packaged there.