harness-everything 0.2.1 → 0.3.6

package/.claude-plugin/marketplace.json

@@ -0,0 +1,27 @@
+{
+  "name": "harness-everything",
+  "owner": {
+    "name": "dyphn1",
+    "url": "https://github.com/dyphn1"
+  },
+  "plugins": [
+    {
+      "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",
+      "author": {
+        "name": "Miya Daniel"
+      },
+      "license": "Apache-2.0",
+      "keywords": [
+        "agent-harness",
+        "orchestration",
+        "circuit-breaker",
+        "tdd",
+        "verification"
+      ],
+      "category": "productivity"
+    }
+  ]
+}

package/.claude-plugin/plugin.json

@@ -0,0 +1,51 @@
+{
+  "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",
+  "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"
+  },
+  "keywords": [
+    "agent-harness",
+    "orchestration",
+    "circuit-breaker",
+    "tdd",
+    "verification"
+  ],
+  "hooks": "./hooks/hooks.json",
+  "agents": "./fable-mode/agents",
+  "skills": [
+    "./multi-agent-workspace",
+    "./environment-detection",
+    "./eval-harness",
+    "./fable-discipline",
+    "./fable-mode",
+    "./find-skills",
+    "./git-commit",
+    "./grill-me",
+    "./grill-with-docs",
+    "./harness-everything",
+    "./improve-codebase-architecture",
+    "./install-cognitive-os",
+    "./repo-docs",
+    "./rewrite-commits",
+    "./security-review",
+    "./self-evolve",
+    "./skill-creator",
+    "./skill-style",
+    "./tdd",
+    "./to-spec",
+    "./to-tickets",
+    "./todo-driven-workflow",
+    "./using-git-worktrees",
+    "./verification-loop",
+    "./verify-before-claim",
+    "./zoom-out"
+  ]
+}

package/.gitattributes

@@ -0,0 +1 @@
+* text=auto eol=lf

package/.github/workflows/behavioral-evals.yml

@@ -0,0 +1,36 @@
+name: Behavioral Evals (Weekly)
+
+on:
+  schedule:
+    - cron: '0 6 * * 1'  # Every Monday 06:00 UTC
+  workflow_dispatch:
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - name: Validate eval case structure (free)
+        run: node behavioral-evals/run.js validate
+      - name: Install Harness for eval
+        run: node scripts/installer.js install --force
+      - name: Run behavioral evals
+        run: |
+          # Run evals if claude CLI is available; skip gracefully otherwise
+          if command -v claude &> /dev/null; then
+            node behavioral-evals/run.js run
+          else
+            echo "::warning::claude CLI not found — skipping live evals"
+            echo "Validate-only mode: case structure verified, no token cost"
+          fi
+      - name: Commit results if any
+        if: success()
+        run: |
+          git config user.email "ci@harness-everything"
+          git config user.name "Harness CI"
+          git add behavioral-evals/results/ || true
+          git diff --staged --quiet || git commit -m "chore(evals): weekly behavioral eval results [skip ci]"
+          git push || true

package/.github/workflows/ci.yml

@@ -0,0 +1,117 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  self-regression:
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, windows-latest]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - name: Install dependencies for regression suite
+        run: npm ci
+      - name: Run hermetic self-regression suite
+        run: npm test
+
+  skill-quality:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          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
+        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
+            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
+            fi
+            if echo "$out" | grep -qE "SKILL.md is [0-9]+ tokens \(hard limit 500\)"; then
+              echo "::error file=$dir/SKILL.md::token budget exceeded (hard limit 500)"
+              fail=1
+            fi
+            if ! grep -q "^## USE FOR:" "$dir/SKILL.md"; then
+              echo "::error file=$dir/SKILL.md::missing '## USE FOR:' trigger section"
+              fail=1
+            fi
+            if ! grep -q "^## DO NOT USE FOR:" "$dir/SKILL.md"; then
+              echo "::error file=$dir/SKILL.md::missing '## DO NOT USE FOR:' trigger section"
+              fail=1
+            fi
+          done
+          exit $fail
+      - name: Verify eval coverage against SKILL.md requirements
+        run: |
+          fail=0
+          for eval in evals/*/eval.yaml; do
+            skill=$(dirname "$eval" | xargs basename)
+            echo "=== $skill"
+            waza spec verify "$skill" "$eval" --fail --threshold 1 || fail=1
+          done
+          exit $fail
+      - name: Block 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]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+      - name: Install Node dependencies
+        run: npm ci
+      - name: Docs, manifest, and eval-coverage consistency
+        run: npm run test:consistency
+      - name: Skill executable and deep-dive references resolve
+        run: npm run test:references
+      - name: Release tag skill tree and references remain verifiable
+        run: npm run test:release
+      - name: Skill description collision detection
+        run: npm run test:collision
+
+  installer-e2e:
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, windows-latest]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v4
+      - 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"

package/.github/workflows/release.yml

@@ -0,0 +1,45 @@
+name: Release
+
+on:
+  push:
+    tags:
+      - '*'
+
+permissions:
+  contents: read
+  id-token: write
+
+jobs:
+  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:
+    needs: gate
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 20
+          registry-url: https://registry.npmjs.org
+      - name: Install dependencies for publishing
+        run: npm ci
+      - name: Publish to npm
+        run: npm publish --provenance --access public
+        env:
+          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

package/.husky/commit-msg

@@ -0,0 +1 @@
+npx --no -- commitlint --edit "$1"

package/.waza.yaml

@@ -0,0 +1,22 @@
+# yaml-language-server: $schema=https://raw.githubusercontent.com/microsoft/waza/main/schemas/config.schema.json
+
+paths:
+  skills: .
+  evals: evals/
+
+tokens:
+  warningThreshold: 500
+  limits:
+    defaults:
+      # Skill bodies stay lean (progressive disclosure); deep detail lives in
+      # references/*.md which may be larger but still bounded.
+      # "*.md" (no slash) is required to match root-level files like README.md;
+      # "**/*.md" alone cannot match them because its regex demands a leading path segment.
+      "SKILL.md": 500
+      "**/SKILL.md": 500
+      "*.md": 4000
+      "**/*.md": 4000
+    overrides:
+      # Append-only history / audit documents — size grows by design.
+      "CHANGELOG.md": 12000
+      "VERIFICATION.md": 10000

package/AGENTS.md

@@ -1,2 +1,60 @@
----
-description: "
+---
+description: Operating guide for AI agents working inside the Harness-everything repository — layout, change rules, quality gates, and release policy.
+---
+
+# 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.
+
+## 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. |
+| `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. |
+
+## 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/`.
+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.
+
+## Verification Before You Claim Done
+
+Run the full local gate — all of these 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
+```
+
+If waza is installed (`~/bin/waza`), also run what CI runs:
+
+```bash
+waza check <skill-dir>                                  # readiness gates per skill
+waza spec verify <skill> evals/<skill>/eval.yaml --fail --threshold 1
+waza tokens check                                       # token budgets
+```
+
+Do not report "it works" from reading code. Every check above names a command; run it and paste nothing less than its exit code.
+
+## Behavioral & Benchmark Evidence
+
+Mechanism tests prove hooks fire; they cannot prove agents behave differently. For that:
+
+- `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.

package/BENCHMARK_SOP.md

@@ -1,62 +1,62 @@
-# Harness Skills Benchmark SOP
-
-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.
-
-## Testing Process
-
-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**.
-   - 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`.
-3. **Experimental Group (Harness Session)**:
-   - Open a session with **all Harness Skills loaded**.
-   - 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`.
-4. **Automated Scoring (Scoring)**:
-   - Paste both logs to an Agent with Harness loaded and input: `Please launch eval-harness to score these two tests.`
-
----
-
-## Benchmark Scenarios (Test Scenarios)
-
-### Test A: Over-engineering Test (Tier 1 Task)
-- **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.
-
-### 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".
-- **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.
-
-### 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.
-
-### 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.
-
-### 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.
+# Harness Skills Benchmark SOP
+
+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.
+
+## Testing Process
+
+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**.
+   - 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`.
+3. **Experimental Group (Harness Session)**:
+   - Open a session with **all Harness Skills loaded**.
+   - 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`.
+4. **Automated Scoring (Scoring)**:
+   - Paste both logs to an Agent with Harness loaded and input: `Please launch eval-harness to score these two tests.`
+
+---
+
+## Benchmark Scenarios (Test Scenarios)
+
+### Test A: Over-engineering Test (Tier 1 Task)
+- **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.
+
+### 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".
+- **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.
+
+### 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.
+
+### 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.
+
+### 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.