harness-everything 0.6.1 → 0.8.0

package/.claude-plugin/marketplace.json

@@ -10,7 +10,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.6.1",
+      "version": "0.8.0",
       "author": {
         "name": "Miya Daniel"
       },

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "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.6.1",
+  "version": "0.8.0",
   "author": {
     "name": "Miya Daniel"
   },

package/AGENTS.md

@@ -4,7 +4,7 @@ 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/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.
+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, contradictory platform claim, or router suggestion that can be skipped without reading its flow can misroute other people's agents. Precision is the product.
 
 ## Repository Layout
 
@@ -40,6 +40,7 @@ The retained [OpenCode evidence](benchmarks/results/live-host/opencode-2026-09-1
 7. **Runtime/workflow claims are generated facts.** `package.json`, `.nvmrc`, `Dockerfile`, and active `.github/workflows/*.yml` are parsed by `scripts/repository-contract.js`. After changing them, run `npm run docs:sync`; `test:repo-contract` rejects stale generated docs, unsupported action majors, Node runtimes below the support floor, or loss of the Node 22 compatibility lane.
 8. **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.
 9. **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.
+10. **Router suggestions are mandatory to evaluate, advisory to execute.** Before skipping any suggested skill, read its complete `SKILL.md` entry and evaluate `USE FOR`, `DO NOT USE FOR`, workflow/basic flow, and hard rules. A name/description/router summary or “routine task” judgement is not enough. Using one suggestion does not waive read-before-skip for other omissions; unreadable suggestions are `unresolved/unavailable`, not silent skips. Do not turn this into a fixed TODO/TDD/Fable execution pipeline.
 
 ## Verification Before You Claim Done
 
@@ -56,6 +57,7 @@ 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:routing:invariants  # kernel/read-before-skip routing contract
 npm run test:plugin:openai       # local OpenAI/Codex plugin package
 npm run test:plugin:submission   # public Skills-only submission inputs/bundle parity
 npm run test:platform:compatibility

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to this project are documented in this file.
 
+## [0.8.0](https://github.com/dyphn1/Harness-everything/compare/v0.7.0...v0.8.0) (2026-09-17)
+
+### Features
+
+* **router:** require evaluation before skipping suggested skills ([#140](https://github.com/dyphn1/Harness-everything/issues/140)) ([b959cb9](https://github.com/dyphn1/Harness-everything/commit/b959cb94afff984c4e4507f0be7f6c62dfa89961)), closes [#131](https://github.com/dyphn1/Harness-everything/issues/131)
+
+## [0.7.0](https://github.com/dyphn1/Harness-everything/compare/v0.6.1...v0.7.0) (2026-09-17)
+
+### Features
+
+* **router:** make routing checkpoint observable ([#139](https://github.com/dyphn1/Harness-everything/issues/139)) ([97dc06d](https://github.com/dyphn1/Harness-everything/commit/97dc06d6b07747ba5e9c328838b8d535c9585b00)), closes [#282](https://github.com/dyphn1/Harness-everything/issues/282)
+
 ## [0.6.1](https://github.com/dyphn1/Harness-everything/compare/v0.6.0...v0.6.1) (2026-09-17)
 
 ### Bug Fixes

package/README.md

@@ -19,7 +19,7 @@ AI coding agents are highly capable, but they struggle with self-regulation, env
 
 Harness acts as an automated system supervisor. It remains completely silent and out of the way, intervening only when execution boundaries are violated or failures are detected.
 
-Harness deliberately follows a **minimal rails, maximum freedom** design: the runtime enforces only a few cross-cutting invariants — route before execution, verify before claim, and re-plan after repeated identical failure — while capable agents remain free to choose, combine, reorder, or skip domain skills according to the task.
+Harness deliberately follows a **minimal rails, maximum freedom** design: the runtime enforces route-before-execution, verify-before-claim, and re-plan-after repeated identical failure. When routing emits skill suggestions, it adds one conditional rail: **evaluate before skip**. The agent must read each suggested skill's `SKILL.md` entry/basic flow before omitting it, but remains free to choose, combine, reorder, or skip execution after that evaluation.
 
 ### Comparison: Prompt vs. Skill vs. Harness
 
@@ -68,7 +68,7 @@ npx github:dyphn1/Harness-everything install
 1. **Use the selected surface's real mechanism:** Claude Code hooks, the local OpenAI plugin lifecycle hooks, OpenCode's plugin API, or advisory instructions depending on what you installed.
 2. **Preflight / session context where packaged:** Hook-capable surfaces can inject environment/session context automatically; advisory-only surfaces must not be described as if they do.
 3. **Verification boundary:** Completion claims require objective evidence; whether that boundary is mechanically invoked or explicitly called depends on the host surface.
-4. **Agent Freedom Preserved:** Tier classification suggests useful skills, but does not impose a universal TODO/TDD/Fable sequence.
+4. **Mandatory evaluation, advisory execution:** Tier classification may suggest useful skills. Before skipping any suggested skill, the agent reads its complete `SKILL.md` entry/basic flow and evaluates applicability; execution remains agent-controlled afterward, so Harness still does not impose a universal TODO/TDD/Fable sequence.
 
 ### What Gets Installed (and How to Remove It)
 
@@ -119,9 +119,10 @@ flowchart TD
 flowchart TD
     U([User Request]) --> K[Harness Kernel<br/>classify scope + establish invariants]
     K --> T{Tier recommendation}
-    T -->|Tier 1| A[Agent chooses smallest useful tactic / skill set]
-    T -->|Tier 2| A
-    T -->|Tier 3| A
+    T --> S{Suggested skills?}
+    S -->|Yes| R[Read each suggested SKILL.md<br/>evaluate flow + applicability]
+    S -->|No| A[Agent chooses smallest useful tactic / skill set]
+    R --> A
     A --> Exec[Execute Code / Run Commands]
     Exec --> Gate{Objective evidence supports completion?}
     Gate -->|No| Retry[Diagnose / iterate]
@@ -137,7 +138,7 @@ flowchart TD
     style Gate fill:#ffcdd2,stroke:#c62828,stroke-width:1px,color:#000000
 ```
 
-The Tier changes the **recommendations**, not the required order. Tier 2 may suggest `tdd`, `todo-driven-workflow`, or `verification-loop`; Tier 3 may suggest Fable or multi-agent capabilities. The model decides what actually helps.
+The Tier changes the **recommendations**, not the required order. Tier 2 may suggest `tdd`, `todo-driven-workflow`, or `verification-loop`; Tier 3 may suggest Fable or multi-agent capabilities. Suggestions are **mandatory to evaluate and advisory to execute**: read each suggested skill's `SKILL.md` flow before omission, then let the model decide what actually helps.
 
 ---
 
@@ -145,7 +146,7 @@ The Tier changes the **recommendations**, not the required order. Tier 2 may sug
 
 Harness operates through six core cognitive concepts:
 
-1. **Kernel Router (`kernel-router.js` + `tier-router.js`):** `tier-router.js` remains the classifier, dynamic-skill detector, and knowledge-guide matcher. `kernel-router.js` is the public runtime boundary: it preserves the classifier result, removes legacy fixed-pipeline instructions, injects the three mandatory invariants, and presents domain skills as advisory suggestions. This prevents host peer-skill selection from bypassing Harness while preserving agent autonomy. If nothing matches at all — including nothing already kept from the open skills ecosystem — `find-skills` checks `npx skills list` live and, if still nothing, searches `skills.sh`/`npx skills` with explicit approval before installation.
+1. **Kernel Router (`kernel-router.js` + `tier-router.js`):** `tier-router.js` remains the classifier, dynamic-skill detector, and knowledge-guide matcher. `kernel-router.js` is the public runtime boundary: it preserves the classifier result, removes legacy fixed-pipeline instructions, injects the baseline invariants, and adds `evaluate-suggestions-before-skip` whenever domain skills are suggested. Suggestions are mandatory to evaluate by reading their `SKILL.md` entry/basic flow, but advisory to execute after evaluation. This prevents host peer-skill selection or superficial routing summaries from bypassing Harness while preserving agent autonomy. If nothing matches at all — including nothing already kept from the open skills ecosystem — `find-skills` checks `npx skills list` live and, if still nothing, searches `skills.sh`/`npx skills` with explicit approval before installation.
 2. **Guard (`rule-of-3.js`):** The fail-safe circuit breaker. Tracks failure signatures across terminal runs on integration surfaces that package the required lifecycle hooks. If a test or command fails 3 times with the same signature, it locks mutating tools and forces a `zoom-out` reflection: re-verify every assumption with read-only tools, write a fact-checked report, then resume on a fresh diagnosis. A companion `Stop` gate (`stop-gate.js`) can bounce the end of a turn once per edit batch when edits were never followed by successful verification on hosts where that hook is installed.
 3. **Memory (`state-persist.js`):** Session transaction logging for stateful hook/plugin integrations. Static skills/instructions alone do not create WAL state.
 4. **Reflection (`self-evolve`):** Long-term workspace immunization. Upon task completion, the agent reflects on the root cause of resolved issues, then judges whether the lesson is a simple rule or a reusable, complex pattern: simple rules are appended to local workspace rules (`RULES.md`); genuinely reusable patterns are instead packaged as a dynamic skill (via `skill-creator`'s Dynamic Skill Generation Contract) and registered in `manifest.json` so the Router picks it up in future sessions. Either path is validated by a hermetic self-regression suite before it's persisted.
@@ -285,7 +286,7 @@ Mechanism tests prove individual packaged mechanisms; only real host/session evi
 
 ### Catalog hygiene
 
-`npm run test:consistency` keeps distribution manifests, docs links, skill frontmatter, routing-eval coverage, platform capability claims, and the generated repository runtime/workflow contract in lockstep with what is actually on disk. `npm run test:repo-contract` runs the runtime/workflow drift gate directly, while `npm run docs:sync` regenerates [docs/repository-contract.md](docs/repository-contract.md) after an intentional change. `npm run test:docs:capabilities` runs the platform-doc drift check directly. `npm run test:references` checks every executable/deep-dive path named by `SKILL.md`; `npm run test:release` compares release/catalog evidence; `npm run test:routing:skills` recursively classifies nested skills and executes the real router for every directly-routable skill's positive cases; `npm run test:routing:invariants` guards the invariant-first architecture; and `harness verify-install` detects stale installed versions or file trees. The installer E2E gate performs install → verify-install → uninstall against seeded user-owned files on Ubuntu, Windows, and macOS so path and ownership symmetry regressions fail CI. `npm run test:collision` fails CI when two skills' descriptions overlap enough to confuse the router.
+`npm run test:consistency` keeps distribution manifests, docs links, skill frontmatter, routing-eval coverage, platform capability claims, and the generated repository runtime/workflow contract in lockstep with what is actually on disk. `npm run test:repo-contract` runs the runtime/workflow drift gate directly, while `npm run docs:sync` regenerates [docs/repository-contract.md](docs/repository-contract.md) after an intentional change. `npm run test:docs:capabilities` runs the platform-doc drift check directly. `npm run test:references` checks every executable/deep-dive path named by `SKILL.md`; `npm run test:release` compares release/catalog evidence; `npm run test:routing:skills` recursively classifies nested skills and executes the real router for every directly-routable skill's positive cases; `npm run test:routing:invariants` guards the invariant-first architecture including read-before-skip; and `harness verify-install` detects stale installed versions or file trees. The installer E2E gate performs install → verify-install → uninstall against seeded user-owned files on Ubuntu, Windows, and macOS so path and ownership symmetry regressions fail CI. `npm run test:collision` fails CI when two skills' descriptions overlap enough to confuse the router.
 
 ---
 
@@ -311,4 +312,4 @@ npm run test:plugin:openai
 npm run test:plugin:submission
 ```
 
-After intentional runtime/workflow changes, run `npm run docs:sync` and commit the regenerated repository contract. All script modifications must pass 100% cleanly before pushing to keep the runtime immunized against behavioral regression.
+After intentional runtime/workflow changes, run `npm run docs:sync` and commit the regenerated repository contract. All script modifications must pass 100% cleanly before pushing to keep the runtime immunized against behavioral regression.

package/ci/invariant-routing.test.js

@@ -35,11 +35,27 @@ check(tier2.stdout.includes('Route before execution'), 'route-before-execution i
 check(tier2.stdout.includes('Verify before claim'), 'verify-before-claim invariant is present');
 check(tier2.stdout.includes('after 3 same-signature failures'), 'failure escalation invariant is present');
 check(tier2.stdout.includes('loop-budget:'), 'iterative-single loop budget invariant is present');
-check(tier2.stdout.includes('SUGGESTED SKILLS (ADVISORY'), 'domain skills are explicitly advisory');
+check(tier2.stdout.includes('evaluate-suggestions-before-skip'), 'non-empty suggestions inject evaluate-before-skip invariant');
+check(tier2.stdout.includes('SUGGESTED SKILLS (MANDATORY EVALUATION'), 'domain suggestions are mandatory to evaluate');
+check(tier2.stdout.includes('ADVISORY EXECUTION'), 'domain suggestion execution remains advisory');
 check(tier2.stdout.includes('tdd:'), 'Tier 2 can still recommend TDD');
 check(!tier2.stdout.includes('BASE EXECUTION LOOP'), 'legacy fixed base-execution-loop output is suppressed');
 check(tier2.stdout.includes('Do not enforce workflow order'), 'self-orchestration policy is explicit');
 
+const tier2Checkpoints = tier2.stdout.match(/HARNESS ROUTING CHECKPOINT \(REQUIRED VISIBLE STATE\)/g) || [];
+check(tier2Checkpoints.length === 1, 'Tier 2 emits exactly one required routing checkpoint');
+check(tier2.stdout.includes('- Tier: Tier 2'), 'checkpoint exposes the human-readable Tier 2');
+check(tier2.stdout.includes('- Strategy: iterative-single'), 'checkpoint exposes the selected strategy');
+check(/- Required invariants: .*verify-before-claim/.test(tier2.stdout), 'checkpoint exposes required invariants');
+check(/- Suggested skills: .*tdd/.test(tier2.stdout), 'checkpoint exposes deduplicated suggestions');
+check(tier2.stdout.includes('Suggestion evaluation: MANDATORY'), 'checkpoint makes suggestion evaluation mandatory');
+check(tier2.stdout.includes('read its complete SKILL.md entry'), 'checkpoint requires reading the suggested skill entry before skip');
+check(tier2.stdout.includes('name, description, router summary'), 'checkpoint rejects metadata-only skip decisions');
+check(tier2.stdout.includes('routine/common task'), 'checkpoint rejects generic routine-task skip decisions');
+check(tier2.stdout.includes('Using one suggestion does not waive read-before-skip'), 'checkpoint applies read-before-skip per omitted suggestion');
+check(tier2.stdout.includes('unresolved/unavailable rather than skipped'), 'checkpoint preserves unresolved suggestions instead of silent skip');
+check(tier2.stdout.includes('If all are skipped after evaluation'), 'all-skipped rationale is grounded after evaluation');
+
 const tier3 = spawnSync(process.execPath, [kernel, 'audit the entire repository architecture and coordinate multiple modules'], {
   cwd: ROOT,
   encoding: 'utf8',
@@ -48,12 +64,29 @@ check(tier3.status === 0, 'Tier 3 kernel routing exits successfully');
 check(/RECOMMENDED TIER:\s*Tier 3/i.test(tier3.stdout), 'macro task remains Tier 3');
 check(tier3.stdout.includes('"strategy":"fable-staged"'), 'Tier 3 dependent/unproven work selects fable-staged');
 check(tier3.stdout.includes('fable-mode / fable-discipline'), 'Tier 3 selected plan suggests Fable capabilities');
-check(tier3.stdout.includes('suggested skills remain advisory'), 'Tier 3 suggestions remain non-mandatory');
+check(tier3.stdout.includes('execution remains advisory after evaluation'), 'Tier 3 execution remains non-mandatory after evaluation');
+check(tier3.stdout.includes('evaluate-suggestions-before-skip'), 'Tier 3 suggestions also carry read-before-skip invariant');
+check(tier3.stdout.includes('HARNESS ROUTING CHECKPOINT (REQUIRED VISIBLE STATE)'), 'Tier 3 also emits the required routing checkpoint');
 
 const harnessSkill = read('harness-everything/SKILL.md');
 check(!/Requests that already name a skill/i.test(harnessSkill), 'harness entrypoint no longer opts out when another skill is named');
-check(/including work that already names or strongly matches another skill/i.test(harnessSkill), 'named domain skills still pass through Harness routing');
+check(/Work that names or matches another skill/i.test(harnessSkill), 'named domain skills still pass through Harness routing');
 check(/not a fixed pipeline/i.test(harnessSkill), 'skill contract rejects fixed pipeline semantics');
+check(/Harness Routing Checkpoint\*\*.*user-visible/i.test(harnessSkill), 'skill contract requires checkpoint visibility');
+check(/For every suggestion, read its `SKILL\.md`/i.test(harnessSkill), 'skill contract requires reading each suggested skill before skip');
+check(/`USE FOR`, `DO NOT USE FOR`, workflow\/basic flow, and hard rules/i.test(harnessSkill), 'skill contract defines the required evaluation scope');
+check(/Name, description, router summary, or "routine\/common task" alone cannot justify skip/i.test(harnessSkill), 'skill contract rejects metadata-only omission');
+check(/Using one suggestion does not waive evaluation of others/i.test(harnessSkill), 'skill contract applies evaluation per omitted suggestion');
+check(/Unreadable suggestions are `unresolved\/unavailable`/i.test(harnessSkill), 'skill contract defines unreadable suggestion disposition');
+check(/If all are skipped, give one brief flow-grounded reason/i.test(harnessSkill), 'skill contract preserves evaluated all-skipped rationale');
+check(/mandatory evaluation, advisory execution/i.test(harnessSkill), 'skill entry states the core disposition succinctly');
+
+const pluginHarnessSkill = read('plugins/harness-everything/skills/harness-everything/SKILL.md');
+check(pluginHarnessSkill === harnessSkill, 'canonical/plugin Harness SKILL.md copies remain identical');
+const pluginKernel = read('plugins/harness-everything/skills/harness-everything/scripts/kernel-router.js');
+check(pluginKernel === read('harness-everything/scripts/kernel-router.js'), 'canonical/plugin kernel-router copies remain identical');
+const pluginTriage = read('plugins/harness-everything/skills/harness-everything/references/triage-and-tiers.md');
+check(pluginTriage === read('harness-everything/references/triage-and-tiers.md'), 'canonical/plugin triage references remain identical');
 
 const cognitiveSkill = read('install-cognitive-os/SKILL.md');
 check(/policy, not a required peer-skill selection/i.test(cognitiveSkill), 'Cognitive OS is defined as policy rather than peer-skill dependency');
@@ -65,10 +98,50 @@ const command = promptHooks && promptHooks[0] && promptHooks[0].hooks && promptH
 check(command === 'node "${CLAUDE_PLUGIN_ROOT}/harness-everything/scripts/kernel-router.js"', 'UserPromptSubmit anchors the Harness kernel to the Claude plugin root');
 
 const triageDoc = read('harness-everything/references/triage-and-tiers.md');
-check(triageDoc.includes('Do not enforce workflow order. Enforce workflow invariants.'), 'architecture reference records the invariant-first decision');
+check(triageDoc.includes('Do not enforce workflow order. Enforce workflow invariants and evaluate suggestions before skipping them.'), 'architecture reference records invariant-first plus read-before-skip decision');
 check(triageDoc.includes('A tier is **not** a fixed pipeline'), 'tier documentation rejects rigid orchestration');
 check(!triageDoc.includes('MUST load `todo-driven-workflow`'), 'documentation no longer mandates TODO as universal Tier 2/3 first step');
 check(triageDoc.includes('```mermaid'), 'updated architecture retains executable flowchart documentation');
+check(triageDoc.includes('the kernel always emits a compact checkpoint'), 'reference makes checkpoint emission mandatory');
+check(triageDoc.includes('mandatory to **evaluate**'), 'reference requires evaluation of every emitted suggestion');
+check(triageDoc.includes('Using one suggested skill does not waive evaluation'), 'reference preserves per-suggestion evaluation');
+check(triageDoc.includes('cannot be resolved/read is not a valid skip'), 'reference preserves unresolved/unavailable state');
+check(triageDoc.includes('Kernel emission alone is not proof'), 'reference preserves the #82 host-evidence boundary');
+
+const routingDoc = read('docs/routing.md');
+check(routingDoc.includes('Suggested skills are mandatory to evaluate and advisory to execute.'), 'routing docs state mandatory-evaluation/advisory-execution contract');
+check(routingDoc.includes('complete `SKILL.md` entry'), 'routing docs require complete skill entry reads before omission');
+check(routingDoc.includes('“routine/common task.”'), 'routing docs reject routine-task skip shortcut');
+
+const architectureDoc = read('docs/architecture.md');
+check(architectureDoc.includes('Mandatory evaluation, advisory execution'), 'architecture docs expose the new routing contract');
+check(architectureDoc.includes('evaluate-suggestions-before-skip'), 'architecture docs name the conditional invariant');
+
+const philosophyDoc = read('docs/philosophy.md');
+check(philosophyDoc.includes('Mandatory Evaluation, Advisory Execution'), 'philosophy docs preserve autonomy after informed evaluation');
+
+const meshDoc = read('docs/mechanism-first-skill-mesh.md');
+check(meshDoc.includes('mandatory to evaluate before omission, but advisory to execute after evaluation'), 'skill-mesh docs prevent advisory suggestions from becoming dead code');
+
+const capabilitiesDoc = read('docs/platform-capabilities.md');
+check(capabilitiesDoc.includes('repository/agent contract'), 'platform docs distinguish routing contract from host enforcement evidence');
+check(capabilitiesDoc.includes('does not change `platform-compatibility.json` status values'), 'routing change does not inflate compatibility status');
+
+const readme = read('README.md');
+check(readme.includes('**evaluate before skip**'), 'README describes the conditional evaluation rail');
+check(readme.includes('mandatory to evaluate and advisory to execute'), 'README explains suggestion evaluation semantics');
+
+const agents = read('AGENTS.md');
+check(agents.includes('Router suggestions are mandatory to evaluate, advisory to execute.'), 'AGENTS.md requires read-before-skip for repository agents');
+
+const advisory = read('scripts/lib/advisory-text.js');
+check(advisory.includes('For EVERY suggested skill'), 'generated advisory instructions require per-suggestion evaluation');
+check(advisory.includes('entry/basic flow before skipping it'), 'Codex AGENTS generator includes read-before-skip');
+check(advisory.includes('There is NO universal TODO/TDD/Fable sequence'), 'advisory surfaces reject the old fixed execution pipeline');
+check(!advisory.includes('Initialize the `todo-driven-workflow` checklist first'), 'old forced Tier 2/3 checklist pipeline is removed');
+check(!advisory.includes('load `fable-mode` and `fable-discipline`, run sub-agents'), 'old forced Tier 3 Fable pipeline is removed');
+const pluginAdvisory = read('plugins/harness-everything/scripts/lib/advisory-text.js');
+check(pluginAdvisory === advisory, 'OpenAI plugin advisory mirror matches canonical source');
 
 console.log(`\n${failed === 0 ? 'PASS' : 'FAIL'}: invariant routing contract (${failed} failure${failed === 1 ? '' : 's'})`);
 process.exit(failed === 0 ? 0 : 1);

package/ci/openai-plugin-package.test.js

@@ -164,14 +164,18 @@ assert.strictEqual(second.status, 0, second.stderr);
 assert.strictEqual(first.stdout, second.stdout, 'identical routing input must produce identical output');
 assert.match(first.stdout, /RECOMMENDED TIER:\s*Tier 2/i);
 assert.match(first.stdout, /REQUIRED HARNESS INVARIANTS/);
-assert.match(first.stdout, /SUGGESTED SKILLS \(ADVISORY/);
+assert.match(first.stdout, /SUGGESTED SKILLS \(MANDATORY EVALUATION .*ADVISORY EXECUTION\)/);
+assert.match(first.stdout, /evaluate-suggestions-before-skip/);
+assert.match(first.stdout, /read its complete SKILL\.md entry/);
 assert.doesNotMatch(first.stdout, /BASE EXECUTION LOOP/);
 assert.match(first.stdout, /Do not enforce workflow order/);
 
 const trivial = route('Update one README typo');
 assert.strictEqual(trivial.status, 0, trivial.stderr);
 assert.match(trivial.stdout, /RECOMMENDED TIER:\s*Tier 1/i);
-assert.match(trivial.stdout, /No mandatory domain skill/);
+assert.match(trivial.stdout, /Suggested skills: none/);
+assert.match(trivial.stdout, /No domain skill was suggested/);
+assert.doesNotMatch(trivial.stdout, /evaluate-suggestions-before-skip/);
 
 const unmatched = route('frobnicate the quux');
 assert.strictEqual(unmatched.status, 0, unmatched.stderr);

package/docs/architecture.md

@@ -11,13 +11,16 @@ Harness is a **system supervisor**, not a universal workflow engine. Skills rema
 The architecture follows a mechanism-first skill mesh with a **minimal kernel**:
 
 - classify scope before mutation,
+- when the router suggests skills, require the agent to read/evaluate each suggested `SKILL.md` before omission,
 - require evidence before completion claims,
 - stop repeated same-signature micro-retries and re-plan,
-- leave domain skill selection, ordering, planning style, and delegation to the agent.
+- leave domain-skill execution, ordering, planning style, and delegation to the agent after evaluation.
 
 > **Do not enforce workflow order. Enforce workflow invariants.**
+>
+> **Mandatory evaluation, advisory execution:** a suggested skill must be read/evaluated before skip, but need not be executed when its flow does not apply.
 
-This is intentionally different from the older design where Tier 2 implied a fixed TDD/checklist pipeline and Tier 3 implied a mandatory Fable/multi-agent pipeline.
+This is intentionally different from the older design where Tier 2 implied a fixed TDD/checklist pipeline and Tier 3 implied a mandatory Fable/multi-agent pipeline. It is also stronger than a pure recommendation system where the model can ignore suggestions from their names alone.
 
 ```mermaid
 flowchart TD
@@ -29,8 +32,11 @@ flowchart TD
         Boot --> Preflight[Environment / integration discovery]
         Preflight --> KR[kernel-router.js]
         KR --> TR[tier-router.js<br/>classifier + guide discovery]
-        TR --> Inv[Inject minimal invariants]
-        Inv --> Choice[Agent chooses useful skills / tactics]
+        TR --> Inv[Inject invariants]
+        Inv --> Sug{Suggested skills?}
+        Sug -- Yes --> Eval[Read each suggested SKILL.md<br/>evaluate flow + applicability]
+        Sug -- No --> Choice[Agent chooses useful tactics]
+        Eval --> Choice
     end
 
     subgraph Execution [Agent-Controlled Execution]
@@ -61,10 +67,13 @@ flowchart TD
 `kernel-router.js` is the public runtime entry point. It delegates heuristic classification and dynamic guide/skill discovery to `tier-router.js`, then converts the result into the Harness contract:
 
 - recommended Tier + rationale,
-- required invariants,
-- advisory skill suggestions.
+- baseline required invariants,
+- a conditional `evaluate-suggestions-before-skip` invariant whenever suggestions exist,
+- skill suggestions under a **mandatory evaluation / advisory execution** contract.
 
-The kernel deliberately suppresses the old fixed `BASE EXECUTION LOOP` wording so that a host selecting `tdd`, `security-review`, `repo-docs`, or another peer skill cannot accidentally replace or bypass the cross-cutting Harness contract.
+For each suggested skill, the agent must read the complete `SKILL.md` entry and evaluate `USE FOR`, `DO NOT USE FOR`, workflow/basic flow, and hard rules before omission. A skill name, description, router summary, tier label, or “routine task” judgement is not enough to justify skipping. If the entry explicitly requires another document to determine applicability, that required material joins the evaluation; optional deep-dive references do not automatically become mandatory.
+
+The kernel deliberately suppresses the old fixed `BASE EXECUTION LOOP` wording so that a host selecting `tdd`, `security-review`, `repo-docs`, or another peer skill cannot accidentally replace or bypass the cross-cutting Harness contract. Using one suggested skill also does not waive evaluation of the other omitted suggestions.
 
 `harness-everything` remains the public/manual skill entry point for routing, debugging, and re-routing. `install-cognitive-os` remains the explanatory/manual entry point for the Discover → Think → Try → Summarize → Record policy. Automatic correctness must not depend on either one winning host peer-skill selection first.
 
@@ -93,12 +102,12 @@ Runtime state includes hook metadata, circuit-breaker counters, handoff/verifica
 The installer configures native lifecycle hooks and project skills.
 
 - `SessionStart`: `bootstrap.js` restores prior state and audits integrations.
-- `UserPromptSubmit`: `kernel-router.js` establishes routing + invariants before peer/domain skill execution.
+- `UserPromptSubmit`: `kernel-router.js` establishes routing + invariants before peer/domain skill execution and tells the agent that every suggested skill must be evaluated before omission.
 - `PreToolUse`: circuit breaker, boundary/depth/context guards, and subagent scope guards can block supported tool calls.
 - `PostToolUse`: records outcomes/state and tracks repeated failures.
 - `Stop`: `stop-gate.js` prevents an edit batch from being claimed complete without successful verification evidence.
 
-The prompt hook is intentionally lightweight: it does **not** prescribe TODO/TDD/Fable order. It gives the model the rails and lets the model orchestrate itself.
+The prompt hook is intentionally lightweight: it does **not** prescribe TODO/TDD/Fable order. It injects the routing rails and the read-before-skip requirement, then lets the model orchestrate execution after evaluation. Kernel emission by itself is not proof that the host/model actually read each skill; that requires retained live behavioral evidence.
 
 ### 2. OpenCode — plugin enforcement, scoped live verification
 
@@ -106,20 +115,20 @@ The prompt hook is intentionally lightweight: it does **not** prescribe TODO/TDD
 
 ### 3. Cursor — skills plus advisory rules
 
-The current installer uses `.cursor/skills/` plus `.cursorrules`. Cursor’s documented skill and plugin surfaces are separate from Harness runtime hooks; routing/verification/retry boundaries remain self-directed unless a compatible mechanism is independently verified.
+The current installer uses `.cursor/skills/` plus `.cursorrules`. Cursor’s documented skill and plugin surfaces are separate from Harness runtime hooks; routing/verification/retry boundaries and read-before-skip remain instruction-governed unless a compatible mechanism is independently verified.
 
 ### 4. GitHub Copilot agent surfaces — skills plus advisory instructions
 
-The current installer uses `.github/skills/` plus `.github/copilot-instructions.md`. GitHub’s Agent Skills paths are documented, but no Harness-specific plugin or live session is verified here.
+The current installer uses `.github/skills/` plus `.github/copilot-instructions.md`. GitHub’s Agent Skills paths are documented, but no Harness-specific plugin or live session is verified here. The generated instructions include read-before-skip, but repository text alone is not live compliance evidence.
 
 ### 5. Codex — local OpenAI plugin plus advisory installer path
 
 Codex has two distinct Harness integration surfaces and documentation must keep them separate:
 
-- The general `--codex` installer path writes Codex-facing skills/instructions such as `AGENTS.md`; where the host only consumes those instructions, that path is advisory.
+- The general `--codex` installer path writes Codex-facing skills/instructions such as `AGENTS.md`; where the host only consumes those instructions, that path is advisory. The generated `AGENTS.md` tells the agent to evaluate every router-suggested skill entry before omission.
 - The packaged local OpenAI plugin under `plugins/harness-everything/` includes `.codex-plugin/plugin.json`, all 26 canonical skills, and lifecycle hooks for `SessionStart`, `UserPromptSubmit`, supported local `PreToolUse` / `PostToolUse`, `SubagentStart` / `SubagentStop`, and `Stop`. Those hooks inject the compact session policy, run the invariant-first kernel, track supported edits and verification, and surface subagent scope changes.
 
-The local plugin therefore has **mechanism-tested local enforcement** for the packaged event/tool mappings. This is package evidence, not a live-host claim; the host's hook review/trust flow and a fresh session are still required. Do not infer broader Claude parity for events or tools that are not listed in the package.
+The local plugin therefore has **mechanism-tested local enforcement** for the packaged event/tool mappings. This is package evidence, not a live-host claim; the host's hook review/trust flow and a fresh session are still required. Do not infer broader Claude parity for events or tools that are not listed in the package, and do not infer that mechanism-tested prompt injection proves the model complied with read-before-skip.
 
 The public OpenAI **Skills-only** submission is narrower again: it ships reusable skills and referenced assets, not the local `.codex-plugin` lifecycle hooks. Public reviewer/listing claims must describe skill/workflow behavior rather than local hook enforcement. See [openai-plugin.md](openai-plugin.md).
 
@@ -148,9 +157,9 @@ flowchart LR
     Z --> T
 ```
 
-A domain skill may have its own lifecycle — for example RED/GREEN/REFACTOR inside `tdd` — without being forced into a global sequence. The only shared obligations are the kernel invariants.
+A domain skill may have its own lifecycle — for example RED/GREEN/REFACTOR inside `tdd` — without being forced into a global sequence. The shared obligations are the baseline kernel invariants plus read-before-skip when router suggestions exist.
 
-This separation solves the peer-skill routing problem: a strong host may correctly decide that a task primarily needs `tdd` or `security-review`; that choice is allowed. What it cannot silently erase is the routing/evidence/retry contract established by the runtime.
+This separation solves the peer-skill routing problem: a strong host may correctly decide that a task primarily needs `tdd` or `security-review`; that choice is allowed. What it cannot silently erase is the routing/evidence/retry contract or dismiss other suggestions without evaluating their actual skill flows.
 
 ---
 
@@ -171,9 +180,9 @@ Harness runs with a local-first, zero-trust model:
 Static configuration is not enough to claim that a host behaves correctly. Validation is layered:
 
 - syntax/reference/manifest checks prove package integrity,
-- `ci/invariant-routing.test.js` proves the kernel contract and documentation invariants,
+- `ci/invariant-routing.test.js` proves the kernel, read-before-skip, and documentation contracts,
 - `ci/doc-capability-consistency.test.js` prevents current platform capability claims from drifting apart,
 - mechanism tests prove supported hook/plugin behavior,
-- live host sessions are required before promoting a source/mechanism-tested adapter to live host enforcement.
+- live host sessions are required before promoting a source/mechanism-tested adapter to live host enforcement or claiming that agents actually followed the evaluation contract.
 
 The architecture and its Mermaid diagrams are part of that contract. Runtime changes that alter orchestration must update these documents in the same change.

package/docs/mechanism-first-skill-mesh.md

@@ -2,7 +2,7 @@
 
 Harness is not intended to be a rigid workflow engine. Its skills should remain independently useful, while still coordinating through lightweight mechanisms that help the model and the software engineer work together with less drift, fewer loops, and better evidence.
 
-The preferred shape is a **mechanism-first skill mesh**: skills are autonomous, coordination is explicit, and enforcement happens at narrow decision points through scripts, hooks, exit codes, and compact return values. Platform-specific enforcement claims follow [platform-capabilities.md](platform-capabilities.md).
+The preferred shape is a **mechanism-first skill mesh**: skills are autonomous to execute, coordination is explicit, and enforcement happens at narrow decision points through scripts, hooks, exit codes, and compact return values. Router-suggested skills are **mandatory to evaluate before omission, but advisory to execute after evaluation**. Platform-specific enforcement claims follow [platform-capabilities.md](platform-capabilities.md).
 
 ---
 
@@ -17,7 +17,7 @@ Each skill should be able to answer four questions on its own:
 3. **What mechanism do I expose?** When possible, the skill should provide a script, command, checklist primitive, verifier, or return-value contract that makes its guidance concrete.
 4. **What should I hand to nearby skills?** The skill may recommend a next skill, but it should not require a global handoff template to remain useful.
 
-This keeps the system composable: `tdd` can run alone, `verification-loop` can run alone, `todo-driven-workflow` can run alone, and `harness-everything` can route among them when the task benefits from orchestration.
+This keeps the system composable: `tdd` can run alone, `verification-loop` can run alone, `todo-driven-workflow` can run alone, and `harness-everything` can route among them when the task benefits from orchestration. The router may not execute every suggestion, but it may not discard suggestions without first reading/evaluating their actual `SKILL.md` flows.
 
 ---
 
@@ -30,7 +30,7 @@ A universal handoff block makes workflow state easy to parse, but it also has co
 - It can make the model optimize for satisfying the template rather than making the best next engineering move.
 - It adds prompt weight on platforms where the mechanism cannot actually enforce the block.
 
-Harness should avoid mandatory global handoff text. Local skills may still use concise reports when they need them, but the mesh should not depend on one universal response format.
+Harness should avoid mandatory global handoff text. Local skills may still use concise reports when they need them, but the mesh should not depend on one universal response format. The routing checkpoint is a compact state/evaluation surface, not a global handoff protocol.
 
 ---
 
@@ -42,7 +42,7 @@ Good mechanism outputs are:
 
 - **Short:** the result should be easy for the model to keep in active attention.
 - **Actionable:** the output should name the next constraint, gate, or recommended skill.
-- **Non-authoritarian:** the mechanism should guide the model without stealing all judgment from it.
+- **Non-authoritarian about execution:** the mechanism may require an evaluation step without forcing a universal workflow sequence.
 - **Portable:** hook-capable platforms can run the mechanism automatically; hook-less platforms can call the same script explicitly.
 
 Example shape:
@@ -50,12 +50,13 @@ Example shape:
 ```text
 HARNESS_DECISION
 tier: 2
-required: route-before-execution, verify-before-claim, re-plan-after-repeat-failure
+required: route-before-execution, verify-before-claim, re-plan-after-repeat-failure, evaluate-suggestions-before-skip
 suggest: todo-driven-workflow, verification-loop
+suggestion_policy: mandatory-evaluation/advisory-execution
 reason: user requested code changes
 ```
 
-This is not a handoff block. It is a compact mechanical signal. The model remains free to decide how to present the work, explain trade-offs, and collaborate with the engineer.
+This is not a handoff block. It is a compact mechanical signal. The model remains free to decide how to present the work, explain trade-offs, and collaborate with the engineer after it has evaluated the suggested skill flows.
 
 ---
 
@@ -71,7 +72,7 @@ Recommended contract:
 - **Neighbor links:** when another skill is commonly needed, recommend it by name and explain why.
 - **Exit discipline:** if the skill reaches a blocking state, it should say what evidence is missing or what human decision is needed.
 
-This contract keeps skills interoperable without requiring central ownership of every task path.
+The local workflow is why read-before-skip can work: the agent can inspect a suggested skill's complete entry and basic flow to judge applicability without loading the whole ecosystem. Optional deep references remain optional unless that entry explicitly makes one necessary to determine applicability.
 
 ---
 
@@ -81,15 +82,17 @@ Harness should coordinate skills through small, composable patterns.
 
 ### Router Decision
 
-`harness-everything/scripts/kernel-router.js` is the public invariant-first runtime entry point. It delegates classification and guide discovery to `tier-router.js`, then returns the recommended tier, rationale, required invariants, and advisory skill suggestions. It intentionally does not emit a mandatory global execution pipeline.
+`harness-everything/scripts/kernel-router.js` is the public invariant-first runtime entry point. It delegates classification and guide discovery to `tier-router.js`, then returns the recommended tier, rationale, required invariants, and skill suggestions. Suggestions use a **mandatory evaluation / advisory execution** contract: before omission, read the complete suggested `SKILL.md` entry and evaluate `USE FOR`, `DO NOT USE FOR`, workflow/basic flow, and hard rules. It intentionally does not emit a mandatory global execution pipeline.
+
+A name, frontmatter description, router summary, tier label, or “routine task” judgement is not enough to skip a suggestion. Using one suggestion does not waive read-before-skip for the others. If a suggestion cannot be resolved/read, preserve `unresolved/unavailable` rather than silently converting it into “not applicable.”
 
 ### Checklist State
 
-`todo-driven-workflow` may own explicit task decomposition state when that helps a Tier 2 or Tier 3 task. It is a suggested tactic, not a universal prerequisite, and the model may use native host TODO tracking or a Markdown checklist instead.
+`todo-driven-workflow` may own explicit task decomposition state when that helps a Tier 2 or Tier 3 task. It is not a universal prerequisite. When the router suggests it, however, the agent must evaluate its actual skill flow before deciding that native host TODO tracking, a Markdown checklist, or no explicit checklist is the better choice.
 
 ### Verification Gate
 
-`verification-loop` and `verify-gate.js` provide reusable verification mechanisms. Hosts with a compatible stop/completion hook can invoke verification mechanically; instruction-only hosts can call the same verifier explicitly before final delivery.
+`verification-loop` and `verify-gate.js` provide reusable verification mechanisms. Hosts with a compatible stop/completion hook can invoke verification mechanically; instruction-only hosts can call the same verifier explicitly before final delivery. If `verification-loop` is router-suggested, read/evaluate its flow before omission even though the kernel already carries a verify-before-claim invariant.
 
 ### Recovery Gate
 
@@ -97,7 +100,7 @@ Harness should coordinate skills through small, composable patterns.
 
 ### Skill Suggestion
 
-`self-evolve` and generated skills feed the router through manifest metadata. The router should surface likely skills, but the model keeps final responsibility for selecting what actually applies.
+`self-evolve` and generated skills feed the router through manifest metadata. Once the router surfaces a likely skill, the suggestion becomes an evaluation obligation: inspect its real entry/basic flow before deciding whether it applies. This does **not** make execution mandatory and does not create a fixed pipeline.
 
 ---
 
@@ -107,23 +110,23 @@ Harness should use the strongest mechanism each installation surface actually pr
 
 | Platform class | Preferred coordination style | Enforcement level |
 | --- | --- | --- |
-| Hook/plugin-capable surfaces | Hooks/plugins run routers, guards, trackers, or completion gates automatically | Mechanical injection/blocking is possible for the mechanisms actually packaged |
-| CLI/tool-capable but hook-less surfaces | The model explicitly calls Harness scripts at decision points | Mechanism-guided, not automatically enforced |
-| Prompt-only surfaces | Advisory instructions include command snippets and decision rules | Self-regulated by the model |
+| Hook/plugin-capable surfaces | Hooks/plugins run routers, guards, trackers, or completion gates automatically; prompt routing can inject the read-before-skip contract | Mechanical injection/blocking is possible for packaged mechanisms; actual model compliance with skill evaluation still needs live behavioral evidence |
+| CLI/tool-capable but hook-less surfaces | The model explicitly calls Harness scripts at decision points and reads/evaluates suggested skills | Mechanism-guided/instruction-governed, not automatically enforced |
+| Prompt-only surfaces | Advisory instructions include command snippets and read-before-skip decision rules | Self-regulated by the model |
 
 One host may expose more than one surface. Codex is the important example: the general `--codex` installer path is instruction/advisory oriented, while the **local OpenAI plugin** packages session, prompt, supported-tool, subagent, and stop hooks for mechanism-tested runtime enforcement. The public OpenAI **Skills-only** submission does not include those local lifecycle hooks.
 
-OpenCode is plugin-capable and has mechanism coverage, but live plugin loading remains unverified. Claude Code has the broadest currently verified Harness lifecycle-hook surface.
+OpenCode is plugin-capable and has partial live-host evidence for project-scope loading/state effects, but the read-before-skip behavioral contract still requires separate retained evidence before being called live-enforced. Claude Code has the broadest currently verified Harness lifecycle-hook surface.
 
 ---
 
 ## Guidance for Instruction-Only / Hook-Less Paths
 
-Do not recreate hooks with a rigid universal handoff template. Instead, make mechanisms easy to call.
+Do not recreate hooks with a rigid universal handoff template. Instead, make mechanisms easy to call and make the evaluation requirement explicit.
 
 Implemented today, both wired into `bin/cli.js` and referenced by name in the advisory text each platform's installer writes (`scripts/lib/advisory-text.js`):
 
-- `npx github:dyphn1/Harness-everything next "<prompt>"`: runs the Harness routing path and prints the recommended tier, invariant contract, and matching knowledge/skill suggestions.
+- `npx github:dyphn1/Harness-everything next "<prompt>"`: runs the Harness routing path and prints the recommended tier, invariant contract, and matching knowledge/skill suggestions. Every suggested skill must then be read/evaluated before omission.
 - `npx github:dyphn1/Harness-everything verify`: wraps `verify-gate.js`, running the target project's own lint/test scripts and exiting non-zero on failure. This is the explicit hook-less verification path; it is not equivalent to claiming that a host automatically runs a `Stop` hook.
 
 Both resolve their target scripts relative to the CLI's own package install, not the caller's cwd, so they work the same way regardless of which platform-specific directory (`.codex/skills/`, `.cursor/skills/`, `.github/skills/`, ...) a copy of the `harness-everything` skill also happens to be sitting in — a fixed relative path like `harness-everything/scripts/tier-router.js` would silently point at nothing depending on which platform installed it.
@@ -146,6 +149,7 @@ Harness should not become:
 - A command-only framework where skills cannot be understood by reading `SKILL.md`.
 - A hidden daemon that performs broad actions without visible evidence.
 - A platform-specific product that only works well when Claude Code hooks are available.
+- A recommendation system whose suggestions are routinely ignored without inspecting the workflows they represent.
 
 The mesh should remain local, legible, and cooperative.
 
@@ -156,10 +160,11 @@ The mesh should remain local, legible, and cooperative.
 When adding or revising a skill:
 
 1. Keep the skill independently executable.
-2. Add a script only when a mechanism can make the behavior more reliable than prose.
-3. Keep script output compact and stable enough for models to react to.
-4. Prefer gates at natural decision points: before editing, after repeated failure, before final delivery, and before persistence.
-5. Let the model choose wording and presentation unless the skill truly needs a specific artifact format.
-6. Document neighboring skills as recommendations, not hidden dependencies, unless the dependency is required for safety.
-
-The result should feel like an engineering co-pilot with good reflexes: autonomous where creativity matters, constrained where repeated mistakes are expensive, and explicit whenever evidence is needed.
+2. Put enough applicability and basic-flow information in `SKILL.md` for read-before-skip evaluation; do not hide the decision-critical contract only in optional deep references.
+3. Add a script only when a mechanism can make the behavior more reliable than prose.
+4. Keep script output compact and stable enough for models to react to.
+5. Prefer gates at natural decision points: before editing, after repeated failure, before final delivery, and before persistence.
+6. Let the model choose wording and presentation unless the skill truly needs a specific artifact format.
+7. Document neighboring skills as recommendations, not hidden execution dependencies, unless the dependency is required for safety. Router-surfaced recommendations still inherit mandatory evaluation before omission.
+
+The result should feel like an engineering co-pilot with good reflexes: autonomous where creativity matters, constrained where repeated mistakes are expensive, and explicit whenever evidence or applicability evaluation is needed.

package/docs/philosophy.md

@@ -12,12 +12,15 @@ The current mechanism/enforcement boundary is platform-specific; see [Platform C
 
 Many AI development frameworks attempt to fully control the model's execution flow. They use rigid DAGs, forced chains, or complex state machines. While this works for trivial, repetitive tasks, it can suppress useful model judgment on complex, novel engineering work.
 
-Harness takes the opposite approach:
+Harness takes a different approach: preserve execution autonomy, but make important decisions informed rather than superficial.
 
 1. **Model Autonomy is Paramount:** The model should have freedom to explore, choose useful skills/tools, and design its solution inside a small set of cross-cutting invariants.
-2. **Context-Driven Guidance:** Harness uses high-context, low-friction signals — skills, rules, local checks, and hooks/plugins where the host supports and packages them — rather than one rigid global execution path.
-3. **Reactive Guardrails:** On integration surfaces that expose the required lifecycle/tool hooks, Harness can stay quiet until a boundary is violated or a repeated failure is detected. On advisory surfaces, the same principles remain guidance rather than automatic blocking.
-4. **Behavior-First, Not Prompt-First:** Harness is not a collection of magic prompts. Its skills remain independently useful, while supported runtime adapters can react to real tool/session outcomes and workspace conditions.
+2. **Mandatory Evaluation, Advisory Execution:** When the router suggests a skill, the model must read/evaluate that skill's actual `SKILL.md` entry/basic flow before omitting it. Execution is still optional after evaluation. This prevents “advisory” from degenerating into “always ignored” without creating a fixed pipeline.
+3. **Context-Driven Guidance:** Harness uses high-context, low-friction signals — skills, rules, local checks, and hooks/plugins where the host supports and packages them — rather than one rigid global execution path.
+4. **Reactive Guardrails:** On integration surfaces that expose the required lifecycle/tool hooks, Harness can stay quiet until a boundary is violated or a repeated failure is detected. On advisory surfaces, the same principles remain guidance rather than automatic blocking.
+5. **Behavior-First, Not Prompt-First:** Harness is not a collection of magic prompts. Its skills remain independently useful, while supported runtime adapters can react to real tool/session outcomes and workspace conditions.
+
+The read-before-skip rule is intentionally narrow. It does not require every optional reference linked by a skill to be loaded, and it does not mean every suggestion must run. The agent reads the complete skill entry, evaluates `USE FOR`, `DO NOT USE FOR`, workflow/basic flow, and hard rules, follows any explicitly required applicability reference, and then decides whether execution adds value.
 
 ---
 
@@ -41,7 +44,7 @@ The Harness recovery invariant is to stop same-signature micro-retries and re-pl
 
 As sessions grow, models can read too broadly or produce oversized output, degrading active context.
 
-Harness uses narrow reads, explicit scope, compact evidence, and — where a compatible runtime adapter exists — boundary mechanisms that can react mechanically. Skill-only surfaces still receive the discipline, but not an imaginary background daemon or hook.
+Harness uses narrow reads, explicit scope, compact evidence, and — where a compatible runtime adapter exists — boundary mechanisms that can react mechanically. Read-before-skip is bounded to the suggested skill entry and any applicability-critical material that entry explicitly requires; it does not justify indiscriminately loading the whole skills tree. Skill-only surfaces still receive the discipline, but not an imaginary background daemon or hook.
 
 ### 4. Self-Evolution (Continuous Workspace Memory)