harness-everything 0.11.5 → 0.11.7

package/ci/mechanism-30-opencode-plugin-loadability.test.js

@@ -40,13 +40,29 @@ function verifyInstall(text) {
   }
 }
 
+function isWorktreeRoot(dir) {
+  try {
+    return fs.existsSync(path.join(dir, '.git'));
+  } catch (_) {
+    return false;
+  }
+}
+
 function walk(directory) {
   return fs.readdirSync(directory, { withFileTypes: true }).flatMap(entry => {
-    if (['node_modules', '.git'].includes(entry.name) || entry.isSymbolicLink()) return [];
+    if (['node_modules', '.git', '.worktrees'].includes(entry.name) || entry.isSymbolicLink()) return [];
     const file = path.join(directory, entry.name);
     const relative = path.relative(root, file).split(path.sep).join('/');
     if (relative === 'benchmarks/results' || relative === 'CHANGELOG.md') return [];
-    return entry.isDirectory() ? walk(file) : [file];
+    if (relative === '.worktrees' || relative.startsWith('.worktrees/')) return [];
+    if (entry.isDirectory()) {
+      // Skip linked worktrees / nested checkouts: a `.git` file marks a
+      // linked worktree root, a `.git` dir marks a nested repo. Either way
+      // the content belongs to another checkout, not this one (#170).
+      if (isWorktreeRoot(file)) return [];
+      return walk(file);
+    }
+    return [file];
   });
 }
 
@@ -68,12 +84,28 @@ try {
   }
   assert.deepStrictEqual(invalidTargets('opencode-plugin/index.mjs .opencode/plugins/example.js'), []);
 
-  const violations = [];
-  for (const file of walk(root).filter(file => /\.(?:md|js|mjs|json|jsonc|yml|yaml|txt)$/.test(file))) {
+  const scanViolations = (readText = file => fs.readFileSync(file, 'utf8')) => {
+    const violations = [];
+    for (const file of walk(root).filter(file => /\.(?:md|js|mjs|json|jsonc|yml|yaml|txt)$/.test(file))) {
+      const text = readText(file);
+      for (const target of invalidTargets(text)) violations.push(`${path.relative(root, file)}: ${target}`);
+    }
+    return violations;
+  };
+  assert.deepStrictEqual(scanViolations(), [], 'Unsupported OpenCode install destinations; only .js/.ts are auto-discovered');
+
+  const scannedFiles = walk(root);
+  assert.ok(scannedFiles.includes(readmeFile), 'Tracked OpenCode README must remain in the repository scan');
+  const plantedTarget = '.opencode/plugins/' + 'negative-control.mjs';
+  const planted = scanViolations(file => {
     const text = fs.readFileSync(file, 'utf8');
-    for (const target of invalidTargets(text)) violations.push(`${path.relative(root, file)}: ${target}`);
-  }
-  assert.deepStrictEqual(violations, [], 'Unsupported OpenCode install destinations; only .js/.ts are auto-discovered');
+    return file === readmeFile ? text + '\n' + plantedTarget + '\n' : text;
+  });
+  assert.ok(
+    planted.some(item => item === `${path.relative(root, readmeFile)}: ${plantedTarget}`),
+    'Scanner negative control must fail when a tracked file contains an unsupported .mjs install target'
+  );
+
   const readme = fs.readFileSync(readmeFile, 'utf8');
   for (const destination of ['.opencode/plugins/harness-enforcement.js', '~/.config/opencode/plugins/harness-enforcement.js']) {
     assert.ok(readme.includes(`cp opencode-plugin/index.mjs ${destination}`));

package/docs/architecture.md

@@ -73,6 +73,23 @@ For selected Fable topologies on Claude:
 
 Other topologies use their own applicable mechanisms: loop budgets, regular verification stop-gates, action gates, and task-specific skills. Mechanism coverage is not assumed identical across hosts.
 
+### Scoped runtime advisories and capabilities
+
+Two kernel mechanisms adjust plans without changing the mandatory-workflow contract:
+
+- **Ensemble policy (`harness-everything/scripts/ensemble-policy.js`):** an advisory plan annotation, not a separate topology. It is selected only when uncertainty is high (or stakes are high) **and** the task asks for comparable outputs or preserves explicit disagreement **and** the selected strategy is already `fable-*`. Creative generation, mechanical bulk work, an explicit user prohibition, unavailable subagents, or a blocked base plan force exclusion. When selected, the plan caps at 3 candidates with `preserve-disagreement` synthesis, an independent verifier, and `parallel-self-consistency` pattern invariants. Covered by deterministic mechanism tests; no live-host effectiveness claim follows from the annotation alone.
+- **Single-use memory capability (`kernel-router.js#issueMemoryCapability`):** when the selected plan permits memory writes, the router issues one capability token bound to `sessionId`/`workflowId` with a stored SHA-256 hash (`memoryAuthorization`, coordinator-only writer role, `usedAt` tracking). Plans with `memory.write === 'none'` receive no capability. This binds a memory write to the workflow that authorized it; it is not a general credential and proves nothing about a live host honoring the binding.
+
+### PreToolUse guard trio and denied-mutation probes
+
+On the Claude hook path, three narrowly scoped `PreToolUse` guards sit alongside the workflow/action gates:
+
+- `boundary-guard.js` (Grep/Glob/Read): hard-blocks whole-file reads over 512KB without `offset`/`limit` and searches inside known noise directories (`node_modules`, `.git`, build output, etc.). Fails open on parse/lookup errors.
+- `depth-guard.js` (Write): blocks overwriting an existing file that was never Read earlier in the session transcript. New files are unaffected. Fails open on parse/lookup errors.
+- `context-compact.js`: estimates working-tree context pressure from `git status`/`git diff --numstat` so later stages can compact or halt before lost-in-the-middle degradation.
+
+Shell mutation accounting is per-tool-call: `workflow-isolation.js` fingerprints observed effects per tool-use identity, `state-persist.js` settles probes in a single ordered handler, and `workflow-mutation-denied.js` discards probes for denied shell executions so a denial never counts as an observed mutation. See [runtime transitions and limitations](workflow-runtime.md). These are mechanism-tested behaviors on the packaged hook surface, not proof that a live session loaded or fired them.
+
 ## Integration Touchpoints
 
 Harness aligns to each host's actual lifecycle/tool APIs. Shared skill text defines a contract; only supported host mechanisms can mechanically block or observe particular transitions.

package/docs/audit.md

@@ -2,17 +2,58 @@
 
 Maintainer-facing audit record. If you just want to know whether Harness works and how to verify it yourself, start at [VERIFICATION.md](../VERIFICATION.md) instead — this file records *how the scores below were obtained* and what changed between audit cycles.
 
-> **Historical snapshot boundary:** the scorecard below is the 2026-09-01 audit and is intentionally preserved as evidence of what was measured on that date. Platform capabilities have changed since then (including the OpenAI/Codex local plugin work and the OpenCode plugin implementation). Do not treat the 2026-09-01 platform rows as current-state documentation; use [platform-capabilities.md](platform-capabilities.md) for the current matrix.
+> **Historical snapshot boundary:** the scorecards below are dated audits and are intentionally preserved as evidence of what was measured on each date. Platform capabilities have changed since the 2026-09-01 snapshot (including the OpenAI/Codex local plugin work and the OpenCode plugin implementation). Do not treat any dated platform row as current-state documentation; use [platform-capabilities.md](platform-capabilities.md) for the current matrix.
 
-**Last self-audited: 2026-09-01**, by running the actual test suite and the VERIFICATION.md recipes on Windows 11 — not by reading the code and assuming it works.
+**Last self-audited: 2026-09-18**, by running the deterministic test suite and gates on macOS (Node.js 24.14.1) — not by reading the code and assuming it works. The 2026-09-01 Windows 11 snapshot is preserved below. Live-host and behavioral evidence layers were not re-run in this cycle; retained artifacts are referenced, not re-measured.
 
-## The 2026-07-23 mis-measurement incident
+## The 2026-09-18 audit cycle
+
+Measured on `docs/sync-skills-and-mechanisms` at `45f2123` (docs-only delta over v0.11.6): 26/26 on-disk canonical skills, 26/26 routing-eval directories (`evals/` also holds `evaluation-reports.md`), and the following gate results:
+
+| Gate | Result on 2026-09-18 |
+|---|---|
+| `npm test` (self-regression, 43 passing checks) | Green except one pre-existing failure: `mechanism-30-opencode-plugin-loadability`, reproduced on the clean tree and caused by leftover `.worktrees/docs-skill-catalog` fixtures asserting `.mjs` destinations — not by product code |
+| `npm run test:mutations` | Passed: 8 production mutations rejected by focused tests |
+| `npm run test:consistency` (incl. doc-capability + repo-contract) | Passed |
+| `npm run test:references` | Passed: 66 skill path references resolve across 26 skills |
+| `npm run test:collision` | Passed: no description collisions at 0.75 threshold |
+| `npm run test:routing:skills` | Passed: 34 positive cases across 26 direct skills; 4 nested skills classified |
+| `npm run test:routing:invariants` | Passed: 275 checks, 0 failures (incl. workflow execution enforcement) |
+| `node ci/disclosure-check.js` | Passed: 26 skills, 26 workflow docs |
+| `npm run test:plugin:openai` / `test:plugin:submission` / `test:platform:compatibility` / `test:release` | All passed; release catalog green for v0.11.6 at 26/26 |
+| `waza tokens check` | All 26 canonical skills within the 500-token limit; the single exceedance is the intentional `eval-framework/fixtures/over-budget-skill` negative control (855 tokens, exists to exercise the failure path) |
+
+Since the 2026-09-01 snapshot, the product gained the mandatory-workflow contract (#142), runtime budget enforcement (#143), structured action gate (#144), memory governance (#145), self-evolve closed loop (#146), telemetry core (#147), contract-integrity phase 1 (#148), workflow controller recovery and isolation hardening (#150/#152/#154/#156/#158), observed-mutation accounting (#160), the Codex local plugin plus Claude certification boundary (#123), OpenCode `.js` loadability guard and partial live-host evidence (#128/#129), and the paired-benchmark contract (#130) — all covered by deterministic mechanism tests. The docs lag this cycle closed: stale `docs/workflows` rewrites, the README index gaps, and the previously undocumented ensemble/memory/guard/probe mechanisms are synced in the same change as this audit entry.
+
+## Five Core Verification Criteria — 2026-09-18 re-measurement
+
+| Criterion | Score | Verified basis |
+|---|---|---|
+| **Skill Description Completeness** | 10/10 | 26/26 skill directories carry complete frontmatter and the required trigger sections, verified by the consistency gate in this cycle. Internal hooks remain intentionally non-routable. |
+| **Routing Accuracy** | 9/10 | 34/34 positive prompts across all 26 skills plus 275/275 invariant-routing checks in this cycle. Waza generalization (ambiguous/metaphorical prompts) and live model sessions remain unmeasured. |
+| **Test Coverage of All Skills** | 9.5/10 | Self-regression now spans syntax, CLI, routing matrix, positive route coverage, invariant routing, references, behavioral-case structure, Fable contract, mutations, and 40+ mechanism suites. Waza full-matrix verify and live sessions remain separate on-demand evidence; `mechanism-30` is red only where the stale `.worktrees` leftover exists. |
+| **Configuration Balance** | 9/10 | Hard `exit(2)` blocking hooks on Claude Code, mechanism-tested local Codex plugin package, and partial OpenCode live-host evidence (project `.js` scope, 1.18.31 macOS) — all centralized in `docs/platform-capabilities.md`. Live parity beyond the retained artifacts is still unclaimed. |
+| **Workflow Conformance** | 9/10 | 26/26 skills have matching workflow documents (two stale ones rewritten in this cycle), the selected-workflow contract with escape/budget/stop-gate semantics is mechanism-tested, and disclosure passes. Runtime tool-call sequence conformance remains host-dependent and is not claimed. |
+
+## Overall Scorecard — 2026-09-18
+
+| Category | Score | Notes |
+|---|---|---|
+| **Architecture** | 9/10 | Per-session state isolation, worktree-gated Tier 3 mutation, per-tool mutation probes settled in one ordered handler, and single-use memory capabilities — all mechanism-tested in this cycle. |
+| **Test Coverage** | 9.5/10 | 43 passing self-regression checks, 8/8 mutations rejected, 66/66 references resolve. Live model evaluation remains on-demand and is not represented by a local simulation. |
+| **README Completeness** | 9.5/10 | Catalog counts, layer labels, route coverage, and the 26-skill tree match after this cycle's index fix (`contract-integrity`/`telemetry`/`eval-framework` rows added). |
+| **Maintainability** | 9/10 | ~600 commits across 20+ PRs since 09-01 landed without breaking the consistency/release/disclosure gates; new non-skill directories are documented as non-skills rather than left ambiguous. |
+| **Skills Design** | 9.5/10 | All 26 skills keep the Skill Contract format, `USE FOR`/`DO NOT USE FOR` sections, and the 500-token limit (verified by waza in this cycle); internal hooks remain intentionally non-routable. |
+| **Agent Compatibility** | 9/10 | Claude hard-mechanism support measured, Codex local plugin mechanism-tested, OpenCode partial live evidence retained — see the current platform matrix, not this row, for status. |
+| **Beginner Friendliness** | 7.5/10 | Unchanged since 09-01: Tier Routing / Rule of 3 / session-scoped state remain load-bearing concepts. The two rewritten workflow docs reduce stale-doc confusion but add no onboarding track. Not addressed in this audit round. |
+
+## The 2026-07-23 mis-measurement incident (preserved)
 
 Seven independent AI-model audits (Gemini 3.1 Pro, Gemini 3.5 Flash, GPT/Copilot on Mistral Medium/Small, and others) ran the same week and disagreed sharply on whether core hooks even functioned. Three of them tested `rule-of-3.js`, `boundary-guard.js`, and `state-persist.js` by piping JSON through `echo '...' | node script.js` in Windows Git Bash, which mangles stdin/TTY state and produced false "broken" verdicts. Re-running the identical payloads through Node's own `child_process` stdin API (the technique VERIFICATION.md's recipes now use) showed every one of those mechanisms working exactly as documented — the scores below reflect that corrected, verified state, not the average of the seven reports.
 
 This incident is why VERIFICATION.md's recipes were rewritten to be Windows-safe (`node -e` stdin instead of a shell `echo` pipe), and why the §2 mechanism checks were automated as `ci/mechanism-test.js` (`npm run test:mechanism`) — copy-paste recipes that can be mis-executed are not a reliable verification substrate.
 
-## Five Core Verification Criteria (per VERIFICATION.md §5a)
+## Five Core Verification Criteria — 2026-09-01 snapshot (per VERIFICATION.md §5a)
 
 | Criterion | Score | Verified basis |
 |---|---|---|
@@ -22,7 +63,7 @@ This incident is why VERIFICATION.md's recipes were rewritten to be Windows-safe
 | **Configuration Balance** | 8.5/10 | **Historical 2026-09-01 result:** hard `exit(2)` blocking hooks were measured on Claude Code and the other then-installed platform paths were evaluated as advisory. This row predates the later OpenAI/Codex local plugin and OpenCode plugin work; see `docs/platform-capabilities.md` for current status. |
 | **Workflow Conformance** | 8.5/10 | Every skill in the snapshot had a matching workflow document, and `ci/skill-routing-check.js` executed every positive route case against the real router. Runtime tool-call sequence conformance remained host-dependent and was not claimed. |
 
-## Overall Scorecard
+## Overall Scorecard — 2026-09-01 snapshot
 
 | Category | Score | Notes |
 |---|---|---|
@@ -36,6 +77,12 @@ This incident is why VERIFICATION.md's recipes were rewritten to be Windows-safe
 
 ## Change log by audit cycle
 
+### 2026-09-18
+- Re-measured the deterministic suite and gates on macOS (Node.js 24.14.1): 43 passing self-regression checks, 8/8 mutations rejected, 66/66 references resolve, 34/34 positive routes, 275/275 invariant checks, disclosure 26/26, release catalog green for v0.11.6. Sole red is the pre-existing `mechanism-30` failure from leftover `.worktrees/docs-skill-catalog` fixtures, reproduced on the clean tree.
+- Closed the docs lag accumulated since 09-01 in the same change: rewrote the stale `docs/workflows/harness-everything.md` and `install-cognitive-os.md`, added the missing README index rows (`contract-integrity`/`telemetry`/`eval-framework`), and documented the ensemble policy, single-use memory capability, guard trio, and mutation-probe lifecycle in `docs/architecture.md` / `docs/workflow-runtime.md`.
+- Product changes since 09-01 now covered by mechanism tests: mandatory-workflow contract, budget enforcement, structured action gate, memory governance, self-evolve closed loop, telemetry core, contract-integrity phase 1, controller recovery/isolation hardening, observed-mutation accounting, Codex local plugin, OpenCode partial live evidence, paired-benchmark contract. Live-host and behavioral layers were not re-run; retained artifacts stand.
+- Beginner Friendliness stays 7.5/10: still no onboarding track. Candidate for the next cycle.
+
 ### 2026-09-01
 - Fable v3 integration exposed explicit Haiku, Sonnet, and Opus entrypoints, with deterministic model selection and visible inline fallback or blocked escalation in `fable-mode/model-matrix.json` and `fable-mode/scripts/model-selector.js`.
 - The workflow used native host TODO tracking or Markdown checklists. The older shared TODO CLI/state-machine references below are retained only as historical audit evidence; no current runtime, test, or active workflow depends on them.

package/docs/release-evidence.md

@@ -9,6 +9,9 @@ The following evidence was collected on 2026-09-07 before the issue #20 integrat
 | Version | Registry observation | GitHub release | Workflow run | Gate and publish result |
 | --- | --- | --- | --- | --- |
 | 0.3.6 | `npm view harness-everything version dist-tags --json`: version and latest are `0.3.6` | `v0.3.6`, published 2026-09-01T03:50:44Z | [33466676632](https://github.com/dyphn1/Harness-everything/actions/runs/33466676632), commit `5aa74119d08ff241a7d6fe8f163a6a0d40c3c932` | `gate=success`, `publish=success` |
+| 0.11.6 | `npm view harness-everything version dist-tags --json` (collected 2026-09-18): version and latest are `0.11.6` | `v0.11.6`, published 2026-09-18T12:51:58Z | [35346673284](https://github.com/dyphn1/Harness-everything/actions/runs/35346673284), commit `23d87db8230dcb524651dc67e932f54aa6f5c737` | `gate=success` (12/12 jobs incl. skill-quality, runtime-floor, self-regression x3 OS, consistency x3 OS, installer-e2e x3 OS, release-semantics), `publish=success` (job `release`) |
+
+Intermediate versions between 0.3.6 and 0.11.6 were published via the same tag-driven workflow but were not individually ledgered here; the rows above are the two deliberately collected observations. A registry/GitHub listing alone is still not a completed row — each field must be a command output or inspectable URL.
 
 The source capture for this row is the local review artifact `.git/issue-review-20260907/release-evidence.md`. That review artifact is not expected to be present in every checkout; it is historical evidence, not a release artifact shipped in the npm package.
 

package/docs/workflow-runtime.md

@@ -63,6 +63,19 @@ have effects a hook cannot infer. OS/host sandboxing is needed to contain them.
 Agent-writable state is also not tamper-proof. These mechanisms prevent tested
 bypasses; they do not establish durable containment against a malicious agent.
 
+## Mutation probes
+
+Shell-effect accounting is keyed per tool call, not per command text. The gate
+registers a pending probe per shell tool-use identity (`workflow-isolation.js`),
+`state-persist.js` settles probes in a single ordered handler, and
+`workflow-mutation-denied.js` discards the probe when that shell execution is
+denied — a denial is never recorded as an observed mutation. Staging-insensitive
+fingerprinting keeps the comparison on visible content, so metadata-only Git
+operations do not register as workspace effects. These lifecycle semantics are
+covered by deterministic workflow mechanism tests (`ci/mechanism-2ah-*`); live
+host loading and behavioral improvement still require separately retained host
+traces and paired evaluations.
+
 ## Escape, replan, and completion
 
 Escape names one stage in the correlated run and records the uncovered scope,

package/docs/workflows/environment-detection.md

@@ -1,63 +1,73 @@
 # Workflow: Environment Detection
 
-> Active shell, operating system, and toolset environment detection, providing safety guardrails and running preflight syntactic verification.
+> Detect OS, shell variant, and available dev tools at session start so commands use the right path, variable, and CLI syntax and avoid repeated execution errors.
 
----
+Source of truth: `environment-detection/SKILL.md`.
 
 ## 1. Skill Behavior Workflow
 
-This section visualizes how the `environment-detection` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
-
 ```mermaid
 graph TD
-  Start([Session Start / Discover Phase]) --> CheckNode{Node.js Executable?}
-  CheckNode -->|Yes| RunPreflight["Run scripts/preflight.js"]
-  CheckNode -->|No / Fails| Heuristic["Inspect <environment_info> & Probe Shell via echo/env"]
-  
-  RunPreflight --> ParseOutput["Parse OS, Shell, Path Separators & CLI Runtimes"]
-  Heuristic --> ParseOutput
-  
-  ParseOutput --> SelfHeal["Run self-heal.js if Node available"]
-  SelfHeal --> AlignSyntax["Adopt Path Slash (/ vs \\) & Env Var Syntax ($VAR vs %VAR%)"]
-  AlignSyntax --> End([Environment Context Established])
+  SessionStart([Session start or complex terminal sequence]) --> Preflight[Run preflight.js from skill dir]
+  Preflight --> PreflightOk{Preflight succeeded?}
+  PreflightOk -->|yes| ParseOut[Parse OS shell PATH and CLIs]
+  PreflightOk -->|no| FallbackProbe[Inspect environment_info and probe shell]
+  FallbackProbe --> ParseOut
+  ParseOut --> SelfHealAudit[Audit harness touchpoints with self-heal.js]
+  SelfHealAudit --> AdoptSyntax[Adopt shell-specific syntax]
+  AdoptSyntax --> DoneCtx([Session context aligned])
 ```
 
----
+```mermaid
+graph TD
+  Adopted[Adopted syntax context] --> GitBash[Git Bash: forward slash and dollar-VAR with Unix cmds]
+  Adopted --> PowerShell[PowerShell: env-prefix vars with cmdlets]
+  Adopted --> CmdShell[CMD: backslash and percent-VAR with dir del copy]
+  GitBash --> GuardCwd[Stay inside process cwd]
+  PowerShell --> GuardCwd
+  CmdShell --> GuardCwd
+  GuardCwd --> FailCount{Same command failed 3 times?}
+  FailCount -->|yes| ZoomEsc[Trigger zoom-out]
+  FailCount -->|no| ContinueRun[Continue with aligned syntax]
+```
 
 ## 2. Triggering and Routing Path
 
-This diagram illustrates how the `environment-detection` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
-
 ```mermaid
 graph LR
-  Router["harness-everything / tier-router.js"] -->|Pre-flight command execution| Env["environment-detection / SKILL.md"]
-  Env -->|Guards runner execution commands in| TDD["tdd / SKILL.md"]
-  Env -->|Guards script installations in| InstallOS["install-cognitive-os / SKILL.md"]
-  Env -->|Guards PR quality checks in| VerLoop["verification-loop / SKILL.md"]
+  StartTrigger[Session start request] --> EnvDetect[environment-detection SKILL]
+  ComplexSeq[Complex terminal sequence] --> EnvDetect
+  EnvDetect --> AlignedRun[Aligned command execution]
+  AlignedRun --> RepeatedFail{Three failures on same command?}
+  RepeatedFail -->|yes| ZoomOut[zoom-out]
+  RepeatedFail -->|no| AlignedRun
 ```
 
----
+## 3. Real-World Use Case
 
-## 3. Real-World Use Case Flowchart
+A session starts on Windows with PowerShell as the active shell. The agent needs to list files and check Node availability before running tests.
 
-Here we model concrete real-world scenarios and use cases of the `environment-detection` skill, illustrating standard success paths, error handling, or recovery loops.
+1. Run `node "<skill-dir>/scripts/preflight.js"` to detect Windows + PowerShell + available CLIs.
+2. Adopt PowerShell syntax for paths and env vars instead of Git Bash assumptions.
+3. If `preflight.js` cannot run, inspect `<environment_info>` and probe with minimal echo/env commands, then adopt syntax.
+4. Stay inside `process.cwd()`; ignore other workspace, history, or temp paths shown by the IDE.
+5. If the same aligned command still fails three times, stop retrying the syntax and trigger `zoom-out`.
 
 ```mermaid
 graph TD
-  Start["Agent wants to run: 'rm -rf build && mkdir build' on Windows Powershell"] --> Trigger["Environment detection pre-flight check"]
-  Trigger --> Detect["Identifies OS: Windows, Shell: PowerShell"]
-  Detect --> AnalyzeSyntax["Identifies that 'rm -rf' will fail or behave unexpectedly in PowerShell"]
-  AnalyzeSyntax --> Rewrite["Rewrites command to PowerShell equivalent or executes using native node commands"]
-  Rewrite --> Run["Executes safely with exit code 0"]
-  Run --> Done([Syntax error and execution crash avoided])
+  AgentGoal[Need to list files and check Node on Windows] --> DetectEnv[Run session-start detection]
+  DetectEnv --> FoundShell[Detected PowerShell on Windows]
+  FoundShell --> UseCmd[Use PowerShell syntax for listing and env lookup]
+  UseCmd --> CmdResult{Command works?}
+  CmdResult -->|yes| ProceedTask[Proceed with task]
+  CmdResult -->|no after 3 tries| ZoomStep[Trigger zoom-out]
 ```
 
----
-
 ## 4. Verification Check
 
-To ensure that the `environment-detection` skill is operating in strict compliance with Harness OS design laws, verify the following:
-
-- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
-- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
-- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
+- [ ] Detection ran at session start via `environment-detection/scripts/preflight.js`, with `<environment_info>` inspection and probing used only as fallback
+- [ ] Adopted syntax matches detected shell: Git Bash uses `/`, `$VAR`, Unix cmds without `dir`/`del`; PowerShell uses `$env:VAR` and cmdlets; CMD uses `\`, `%VAR%`, `dir`/`del`/`copy` without Unix cmds
+- [ ] All commands stayed inside `process.cwd()`; no commands ran outside the current project root
+- [ ] No toolchain installation was attempted; scope stayed to detection, alignment, and touchpoint repair
+- [ ] After three failures of the same command, execution stopped blind retry and triggered `zoom-out`
+- [ ] Shell detail followed `environment-detection/references/shell-syntax-rules.md` where needed

package/docs/workflows/eval-harness.md

@@ -1,64 +1,71 @@
 # Workflow: Eval Harness
 
-> Evaluates AI developer agent performance based on accuracy, resource efficiency, and anti-loop metrics.
+> Score an agent execution log or conversation history on correctness, token efficiency, anti-loop focus, and environment awareness, and save the result as a scorecard when a benchmark is requested.
 
----
+Source of truth: `eval-harness/SKILL.md`.
 
 ## 1. Skill Behavior Workflow
 
-This section visualizes how the `eval-harness` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
-
 ```mermaid
 graph TD
-  Start([Trigger: Benchmark / Evaluate Log]) --> ParseLog["1. Parse Log: Actions, Error Loops, Token Indicator"]
-  ParseLog --> CalcRubric["2. Calculate Scores across 4 Dimensions (0-10)"]
-  CalcRubric --> CheckScript{3. Is evaluate.js Executable?}
-  
-  CheckScript -->|Yes| RunScript["Run node eval-harness/scripts/evaluate.js"]
-  CheckScript -->|No / Fails| FileFallback{"4. Markdown File Fallback"}
-  
-  FileFallback -->|evals/ Exists| WriteEvals["Save Scorecard to evals/scorecard.md"]
-  FileFallback -->|No evals/ Folder| WritePlatform["Save Scorecard to .github/harness-everything/evals/scorecard.md"]
-  
-  RunScript --> End([Evaluation Scorecard Logged])
-  WriteEvals --> End
-  WritePlatform --> End
+  BenchReq([Benchmark request with log or history]) --> ParseLog[Parse actions errors tokens timing]
+  ParseLog --> ScoreDims[Score four dimensions 0-10 via scoring-rubric]
+  ScoreDims --> RunEval[Run scripts evaluate.js with scores and insights]
+  RunEval --> EvalOk{Evaluate script succeeded?}
+  EvalOk -->|yes| SavedCard([Scorecard saved])
+  EvalOk -->|no or missing| MdFallback[Write evals scorecard.md fallback]
+  MdFallback --> SavedCard
 ```
 
----
+```mermaid
+graph TD
+  ScoreStart[Start scoring] --> Correctness[Score correctness 0-10]
+  ScoreStart --> Efficiency[Score efficiency 0-10]
+  ScoreStart --> AntiLoop[Score anti-loop focus 0-10]
+  ScoreStart --> EnvAware[Score environment awareness 0-10]
+  Correctness --> CombineScores[Combine into four-dimension card]
+  Efficiency --> CombineScores
+  AntiLoop --> CombineScores
+  EnvAware --> CombineScores
+  CombineScores --> EmitCard[Emit via script or markdown fallback]
+```
 
 ## 2. Triggering and Routing Path
 
-This diagram illustrates how the `eval-harness` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
-
 ```mermaid
 graph LR
-  Router["harness-everything / tier-router.js"] -->|Analyzes performance metrics| EH["eval-harness / SKILL.md"]
-  EH -->|Synthesizes lessons learned for| Evolve["self-evolve / SKILL.md"]
-  EH -->|Detects error loops triggering| ZoomOut["zoom-out / SKILL.md"]
+  UserBench[User asks to run benchmark] --> EvalSkill[eval-harness SKILL]
+  LogInput[Execution log or conversation history provided] --> EvalSkill
+  EvalSkill --> RubricStep[Apply references scoring-rubric.md]
+  RubricStep --> ScriptStep[Run scripts evaluate.js]
+  ScriptStep --> OutputLoc[Write to workspace evals or github fallback dir]
 ```
 
----
+## 3. Real-World Use Case
 
-## 3. Real-World Use Case Flowchart
+A reviewer wants to compare two runs of a file-migration task.
 
-Here we model concrete real-world scenarios and use cases of the `eval-harness` skill, illustrating standard success paths, error handling, or recovery loops.
+1. Collect the execution log with tool calls, errors, tokens, and timing.
+2. Score correctness, efficiency, anti-loop focus, and environment awareness 0–10 using `eval-harness/references/scoring-rubric.md`.
+3. Run `node <skill-dir>/scripts/evaluate.js <A> <B> <C> <D> "insights"`.
+4. On script failure or absence, write `<workspace>/evals/scorecard.md`, or `<workspace>/.github/harness-everything/evals/` if needed.
+5. Leave the evaluated code unchanged; output is only the scorecard and insights.
 
 ```mermaid
 graph TD
-  Start["Agent session finishes implementing a complete backend server"] --> Trigger["eval-harness skill executed"]
-  Trigger --> Gather["Collects: 15 minutes elapsed, 32 tool calls, 45,000 tokens consumed"]
-  Gather --> Score["Scores: Correctness 10/10, Resource Efficiency 9/10, Anti-loop 10/10"]
-  Score --> Output["Generates benchmark report summarizing optimal execution speed and zero looping errors"]
-  Output --> Done([Benchmark logged for project history])
+  ReviewAsk[Reviewer asks to score migration run] --> GatherLog[Gather execution log]
+  GatherLog --> ApplyRubric[Score four dimensions with rubric]
+  ApplyRubric --> TryScript[Try evaluate.js]
+  TryScript --> ScriptOk{Script ok?}
+  ScriptOk -->|yes| DoneScore([Scorecard emitted])
+  ScriptOk -->|no| WriteMd[Write scorecard.md fallback]
+  WriteMd --> DoneScore
 ```
 
----
-
 ## 4. Verification Check
 
-To ensure that the `eval-harness` skill is operating in strict compliance with Harness OS design laws, verify the following:
-
-- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
-- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
-- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
+- [ ] Input included both a benchmark request and an execution log or conversation history; tasks without a log were declined
+- [ ] All four dimensions were scored 0–10 using `eval-harness/references/scoring-rubric.md`: correctness, efficiency, anti-loop focus, environment awareness
+- [ ] `eval-harness/scripts/evaluate.js` was run with four scores plus insights; markdown fallback was used only if the script failed or was missing
+- [ ] Scorecard was written under `<workspace>/evals/` or `<workspace>/.github/harness-everything/evals/`
+- [ ] No evaluated code was written or fixed, and no general review was substituted for dimension scoring

package/docs/workflows/fable-discipline.md

@@ -1,59 +1,71 @@
 # Workflow: Fable Discipline
 
-> Shadow guard for fable-mode preventing context bloat, enforcing physical boundaries, and preserving compact stage handoffs.
+> Act as a background guard while staged multi-agent work runs, keeping output compact, stage scope tight, handoffs explicit, and diverging builds halted.
 
----
+Source of truth: `fable-discipline/SKILL.md`.
 
 ## 1. Skill Behavior Workflow
 
-This section visualizes how the `fable-discipline` skill executes internally, detailing the sequence of operations, state transitions, and evaluation steps.
-
 ```mermaid
 graph TD
-  Start([Fable Task Initiated]) --> AuditContext["Audit active context against the stage contract"]
-  AuditContext --> CheckTokenLimit{Context exceeds the active budget?}
-  CheckTokenLimit -->|Yes| TrimContext["Evict raw logs, completed tasks, and non-essential file contents"]
-  CheckTokenLimit -->|No| KeepState["Continue monitoring context state"]
-  TrimContext --> EnforceLimit["Enforce physical boundary guidelines"]
-  KeepState --> EnforceLimit
-  EnforceLimit --> RecordHandoff["Record a compact stage handoff"]
-  RecordHandoff --> End([Context maintained under safe, high-attention limits])
+  FableActive([fable-mode active with staged work]) --> CompactMilestone[Compact state after milestone]
+  CompactMilestone --> ScopeCheck[Enforce stage scope and output limits]
+  ScopeCheck --> HandoffStep[Require state manifest at handoff]
+  HandoffStep --> BuildHealth{Build errors diverging?}
+  BuildHealth -->|yes| HaltZoom[HALT and call zoom-out]
+  BuildHealth -->|no| KeepGuard[Continue background guard]
+  KeepGuard --> CompactMilestone
+  HaltZoom --> MapErrors[Map error dependency graph for human]
 ```
 
----
+```mermaid
+graph TD
+  IncomingAgent[Incoming stage agent] --> VerifyManifest[Verify outgoing state manifest first]
+  VerifyManifest --> ManifestOk{Manifest complete?}
+  ManifestOk -->|yes| DoStage[Run stage within allowed files]
+  ManifestOk -->|no| AskManifest[Require missing APIs and IO details]
+  AskManifest --> VerifyManifest
+  DoStage --> OneCommit[One commit per independent logic block]
+  OneCommit --> LeaveManifest[Leave manifest for next agent]
+```
 
 ## 2. Triggering and Routing Path
 
-This diagram illustrates how the `fable-discipline` skill is triggered through user requests or developer actions, and how it integrates or chains together with other companion skills in the Harness OS ecosystem to form unified workflows.
-
 ```mermaid
 graph LR
-  Fable["fable-mode / SKILL.md"] -->|Monitors context on every turn| FD["fable-discipline / SKILL.md"]
-  FD -->|Trims and prunes files from| ActiveContext["Active AI Session Context"]
-  FD -->|Triggers high-level reflection when overloaded| ZoomOut["zoom-out / SKILL.md"]
+  FableMode[fable-mode active] --> FableDisc[fable-discipline shadow guard]
+  FableDisc --> WorkspaceGuard[Constrain multi-agent-workspace mutations]
+  WorkspaceGuard --> FableMode
+  FableDisc --> DivergedBuild{Diverging build errors?}
+  DivergedBuild -->|yes| ZoomOut[zoom-out]
+  DivergedBuild -->|no| FableMode
 ```
 
----
+## 3. Real-World Use Case
 
-## 3. Real-World Use Case Flowchart
+Long architectural migration runs under `fable-mode` with sub-agents handling separate stages.
 
-Here we model concrete real-world scenarios and use cases of the `fable-discipline` skill, illustrating standard success paths, error handling, or recovery loops.
+1. After each milestone, compact decisions and drop unneeded history; avoid broad regex and avoid reading irrelevant files over 1000 lines.
+2. Confirm working directory before touching core architecture; keep one commit per independent logic block.
+3. Outgoing agent leaves a manifest with completed APIs and expected inputs/outputs; incoming agent verifies it first.
+4. If fixes create more breakage, halt immediately, call `zoom-out`, and map the error dependency graph instead of continued patching.
 
 ```mermaid
 graph TD
-  Start["Fable-mode is editing a large monorepo with growing context"] --> Monitor["Fable-discipline analyzes active context"]
-  Monitor --> TriggerPruning["Identifies raw logs & completed sub-task details"]
-  TriggerPruning --> Clean["Evicts completed step details and logs from immediate active context"]
-  Clean --> Compress["Summarizes historical state into the stage handoff"]
-  Compress --> Done([Active context remains bounded while preserving required facts])
+  LongTask[Migration stage completes] --> CompactState[Compact milestone state]
+  CompactState --> CheckBloat[Check for bloat or oversized reads]
+  CheckBloat --> Handoff[Write and verify handoff manifest]
+  Handoff --> BuildCheck{Build diverging?}
+  BuildCheck -->|yes| HaltNow[HALT and zoom-out]
+  BuildCheck -->|no| NextStage[Start next stage guarded]
 ```
 
----
-
 ## 4. Verification Check
 
-To ensure that the `fable-discipline` skill is operating in strict compliance with Harness OS design laws, verify the following:
-
-- [ ] **Physical Boundary Verification**: The skill boundaries are respected and do not leak context.
-- [ ] **State Checkpoint Verification**: The active state is established, validated, and recorded at the beginning and end of each execution branch.
-- [ ] **Cognitive Alignment**: The skill conforms to the **Think > Try > Summarize > Record** cognitive loop.
+- [ ] Ran only as a background shadow for the whole `fable-mode` duration; not used standalone, not used for small tasks or routine single-file edits
+- [ ] After each milestone, state was compacted and unneeded history dropped; no broad regex without precise conditions and no irrelevant 1000+ line reads
+- [ ] Working directory was confirmed before core changes, with one commit per independent logic block
+- [ ] Every sub-agent handoff via `multi-agent-workspace` left a state manifest with completed APIs and expected inputs/outputs, verified by the incoming agent first
+- [ ] On diverging build errors, execution halted immediately and called `zoom-out` with an error dependency map instead of continued patching
+- [ ] Made no direct state mutations of its own; only constrained `fable-mode` and `multi-agent-workspace` mutations
+- [ ] Detail followed `fable-discipline/references/discipline-rules.md` where needed