harness-everything 0.30.9 → 0.31.0

package/docs/platform-capabilities.md

@@ -15,19 +15,21 @@ Statuses are intentionally explicit:
 - `Unsupported`: official host documentation explicitly rules out the capability.
 - `Unknown`: the capability or its current host behavior was not established.
 
-All `liveHostVerification` rows except OpenCode are `Unknown`. OpenCode's row is `Partial`: retained evidence supports project-scope `.js` loading and edit/verification state on OpenCode 1.18.31 (macOS), not durable hard enforcement. No fresh artifacts exist yet for the other surfaces, managed-workspace import, or public OpenAI approval.
+Codex and OpenCode are `Partial` in `liveHostVerification`. The Codex artifact verifies user-hook compatibility capture for two consecutive turns on one Windows Codex CLI host; native plugin-hook mounting and other host/version combinations remain unverified. OpenCode's retained evidence supports project-scope `.js` loading and edit/verification state on OpenCode 1.18.31 (macOS), not durable hard enforcement. No fresh artifacts exist yet for the other surfaces, managed-workspace import, or public OpenAI approval.
 
 ### Routing contract vs. host evidence
 
-The repository routing contract uses **guidance-first workflow selection**. Each suggested skill still requires reading its complete `SKILL.md` entry/basic flow before omission; the selected topology is planning guidance and unresolved evidence produces reminders rather than a persistent workflow lock. A name, description, router summary, tier label, or generic “routine task” judgement is not enough skip evidence; unreadable suggestions are `unresolved/unavailable`, not silent skips.
+The workflow plan controller rejects present non-array required/optional binding declarations before recording a requirement plan. This input-validation contract is covered by deterministic mechanism tests and does not change live-host evidence status.
 
-This is a **repository/agent contract**, not an automatic upgrade to any platform row below. A hook can prove that the contract was injected into a session; it does not prove the model actually read every suggested skill. Instruction-only surfaces can carry the same rule without mechanically enforcing it. Promoting this behavior to live-host compliance requires retained host/session evidence under the #82 compatibility program. The Claude and local OpenAI packages carry workflow entry/completion **reminders** plus separate Rule-of-3/permission boundaries, but this package/mechanism change does not upgrade `platform-compatibility.json` live-host status values. See [workflow runtime](workflow-runtime.md) for scope, worktree isolation, and failure behavior. OpenCode and instruction-only/public Skills-only surfaces do not acquire equivalent runtime gating. Shell inspection is not a filesystem sandbox; absent hooks, agent-writable state, and indirect script effects remain limits.
+The repository routing contract uses **step-scoped workflow selection**. Normalized keyword/domain signals help compose ordered requirements but never select or load document paths. Each step/stage declares its required and optional skill/reference bindings; only active bindings are disclosed, and required bindings resolve before the step/stage passes. Unknown or unavailable required bindings stay visible and unresolved; missing evidence produces reminders rather than a persistent workflow lock.
+
+This is a **repository/agent contract**, not an automatic upgrade to any platform row below. A hook can prove that the contract was injected and record an agent's binding disposition; neither proves that a live host actually loaded or followed the referenced content. Instruction-only surfaces can carry the same rule without mechanically enforcing it. Promoting behavior to live-host compliance requires retained host/session evidence under the #82 compatibility program. Claude and local OpenAI packages carry workflow entry/completion **reminders** plus separate Rule-of-3/permission boundaries, but this package/mechanism change does not upgrade `platform-compatibility.json` live-host status values. See [workflow runtime](workflow-runtime.md) for scope, worktree isolation, and failure behavior. OpenCode and instruction-only/public Skills-only surfaces do not acquire equivalent runtime gating. Shell inspection is not a filesystem sandbox; absent hooks, agent-writable state, and indirect script effects remain limits.
 
 ## Current capability summary
 
 | Platform surface | Standalone skills | Plugin support | Hooks/lifecycle | Project scope | Global scope | Current evidence boundary |
 | --- | --- | --- | --- | --- | --- | --- |
-| Codex | `Supported` | `Mechanism verified` | `Mechanism verified` for the local OpenAI package, including session, prompt, supported-tool, subagent, and stop hooks | `.agents/skills/`, `AGENTS.md` | `~/.agents/skills/` | Local package hooks and the state-specific marketplace sync command are mechanically checked; live loading and marketplace refresh remain unverified. |
+| Codex | `Supported` | `Mechanism verified` | `Partial`: user-hook compatibility capture is live-verified for `UserPromptSubmit` and `Stop` on one Windows Codex CLI host; native plugin hooks remain mechanism-verified | `.agents/skills/`, `AGENTS.md` | `~/.agents/skills/` | [Live evidence](../benchmarks/results/live-host/codex-2026-10-13/README.md) verifies two consecutive turns on Codex CLI 0.162.1; native plugin mounting, other lifecycle events, and other versions remain unverified. |
 | ChatGPT / OpenAI Plugin | `Unknown` for a repository-local standalone path | `Mechanism verified` | `Partial`: local Work/Codex hooks are separate from ordinary Chat | Managed workspace marketplace | Not established | The public Skills-only bundle is mechanically reproducible; import, approval, and live behavior remain `Unknown`. |
 | Claude Code | `Supported` | `Supported` | `Mechanism verified` for Harness configuration | `.claude/skills/` | `~/.claude/skills/` | Native Claude surfaces and the state-specific plugin sync command are mechanically checked; fresh-host execution is not preserved here. |
 | OpenCode | `Supported` | `Partial` live-host loading for the project-scope, `.js`-filename install path on OpenCode 1.18.31 (macOS); other install paths remain `Mechanism verified` | `Partial` live-host evidence for project-scope `.js` loading and edit/verification state; hard lock reported only, with no retained blocked-tool trace and a post-reset final snapshot | `.opencode/skills/`, `.agents/skills/`, `.opencode/plugins/` | `~/.config/opencode/skills/`, `~/.agents/skills/`, `~/.config/opencode/plugins/` | [Retained evidence](../benchmarks/results/live-host/opencode-2026-09-16/README.md): loading and state effects verified in one host session; final snapshot post-reset; hard lock only an interactive observation; reflection operator-seeded, then agent-rewritten; no raw transcript or behavioral-effectiveness claim. `.mjs` auto-discovery broken (issue #127); global scope, npm-package installation, and other host versions remain unverified. |
@@ -61,16 +63,16 @@ The general installer’s target paths are tested independently from host discov
 
 These targets apply to both default link mode and explicit `--copy` mode. A canonical store is only a deduplication detail; it cannot make an unsupported host path supported. Install/uninstall tests also protect user-owned files and cover Linux, Windows, and macOS round-trip fixtures.
 
-The advisory installer text generated for Codex/Cursor/Copilot/Continue/Hermes carries the same read-before-skip rule. That proves only what Harness writes, not that the host/model complied with it.
+The advisory installer text generated for Codex/Cursor/Copilot/Continue/Hermes carries the same step-scoped binding rule. That proves only what Harness writes, not that the host/model loaded or followed an active binding.
 
 ## Codex / local OpenAI plugin boundary
 
 Codex has two paths that must not be collapsed:
 
-1. The general `--codex` installer writes advisory `AGENTS.md` plus repo-scoped skills under `.agents/skills/`. Its generated instructions require reading/evaluating every router-suggested skill before omission, but this remains instruction-governed.
-2. The local OpenAI plugin at `plugins/harness-everything/` packages the skills plus lifecycle hooks for session start, prompt routing, supported local tool calls, subagent lifecycle, and stop verification. Those hooks are mechanically checked, but no live plugin/session artifact is committed.
+1. The general `--codex` installer writes advisory `AGENTS.md` plus repo-scoped skills under `.agents/skills/`. Its generated instructions require resolving bindings declared for the active step, but this remains instruction-governed.
+2. The local OpenAI plugin at `plugins/harness-everything/` packages the skills plus lifecycle hooks for session start, prompt routing, supported local tool calls, subagent lifecycle, and stop verification. Those hooks are mechanically checked. A separate live run verifies the user-hook compatibility fallback for prompt/stop observation only; native plugin hook mounting remains unverified.
 
-The package is tested at the mechanism layer and remains subject to the host’s hook review/trust flow. A fresh host session is still required before claiming that a particular ChatGPT/Codex installation loaded and fired the hooks or that the model followed read-before-skip.
+The package remains subject to the host’s hook review/trust flow. The retained Codex CLI session proves that the selected user-level observation hooks were trusted and fired on one Windows setup; it does not prove that the model loaded or followed an active binding or that another ChatGPT/Codex installation loaded the same hooks.
 
 ### Native plugin install/update synchronization
 
@@ -98,13 +100,13 @@ The command detects Claude Code and Codex independently, ensures the Harness mar
 
 Mutating commands are issued with the current option set and retried without any option the host rejects, covering both commander wording (`unknown option '--json'`) and clap wording (`unexpected argument '--json' found`), so older Claude and Codex builds stay supported.
 
-The installed branch is intentionally an update branch even when the current release is already the newest version; the host command may report “already latest.” Codex marketplace upgrade is the current native refresh operation; the command does not edit private cache paths or `config.toml`. These are deterministic command/state tests, not live-host evidence, so `liveHostVerification` remains `Unknown` in the matrix.
+The installed branch is intentionally an update branch even when the current release is already the newest version; the host command may report “already latest.” Codex marketplace upgrade is the current native refresh operation. After successful Codex plugin install/update and verification, `plugin-sync.js` reads the installed plugin's tagged JSON source. It refreshes compatibility hooks only for `source: "local"` with an absolute filesystem path; `git`, `git-subdir`, `npm`, `remote`, unknown or missing variants, and relative paths fail closed before the installer runs. It does not reinterpret a repository subdirectory relative to the sync process working directory. An ownership/configuration error also makes Codex sync report failure. The installer does not alter trust state or private `config.toml`. Deterministic tests cover this source-shape policy; live Codex marketplace source reporting/sync remains unverified. The separate compatibility fallback has one retained live dispatch artifact on Windows, as recorded in the matrix.
 
 On Windows, the synchronizer resolves `codex`/`claude` the same way an interactive shell does: it walks `PATH` directories in order and tries `PATHEXT` extensions within each directory before moving on, so directory order — not which candidate happens to be a directly launchable `.exe` — decides the match. This matters because Node's non-shell `spawnSync` cannot execute a `.cmd`/`.bat` shim directly and, left to its own resolution, can silently prefer an unrelated, older standalone `.exe` elsewhere on `PATH` over a newer npm-installed shim with no error to signal it. Only the one case Windows genuinely requires an interpreter for — a resolved `.cmd`/`.bat` target — is run through `ComSpec`, using the already-resolved absolute path rather than re-resolving the bare command name.
 
 ### Explicit Codex user-hook compatibility fallback
 
-Current Codex documentation supports plugin-bundled hooks, so native plugin mounting remains the preferred path. Some host/source combinations have nevertheless failed to expose enabled plugin hooks for review/entry attribution (#122 and upstream Codex reports). Harness therefore provides an **explicit compatibility fallback**, not an automatic replacement for native plugin hooks:
+Current Codex documentation supports lifecycle hooks for manually installed Codex desktop plugins and requires users to review and trust non-managed hook definitions. The retained codex-cli 0.157.1 evidence records plugin_hooks as removed, so the user-hook compatibility installer remains necessary for that CLI path. Harness provides the compatibility path alongside the native plugin package:
 
 ```bash
 harness codex-hooks install
@@ -112,11 +114,11 @@ harness codex-hooks status
 harness codex-hooks uninstall
 ```
 
-The fallback copies the current packaged runtime into `$CODEX_HOME/harness-everything/compat-hooks/` and merges absolute-path entries into `$CODEX_HOME/hooks.json`. It does **not** modify `config.toml`, trust hashes, approval policy, or hook enablement. Codex must still show/review/trust the resulting non-managed hooks through its normal `/hooks` flow.
+The installer copies the current packaged runtime into `$CODEX_HOME/harness-everything/compat-hooks/` and merges absolute-path entries into `$CODEX_HOME/hooks.json`. harness codex-hooks status reports `inactive` when the compatibility hooks are absent, or `configured-unverified` when their files are healthy; it cannot read Codex trust state. A successful Codex run of plugin-sync.js installs or refreshes this copy automatically. The installer does **not** modify `config.toml`, trust hashes, approval policy, or hook enablement. Codex must still show/review/trust the resulting non-managed hooks through its normal `/hooks` flow.
 
 Ownership is deliberately strict: update/uninstall removes only exact entries recorded in the Harness compatibility manifest. If an installed Harness entry was edited after installation, the operation fails closed rather than overwriting or deleting that user-modified entry. Unrelated pre-existing and later-added user hooks are preserved.
 
-This fallback solves only plugin-source discovery/mounting. It does not claim to repair a Codex carrier that fails to dispatch `PreToolUse` at all; those host-level execution-path limitations remain a live compatibility boundary.
+The compatibility path registers hook commands in Codex user configuration and covers the missing plugin-mount route where user hooks dispatch. It does not repair a Codex carrier that fails to dispatch `PreToolUse` at all; those host-level execution-path limitations remain a live compatibility boundary.
 
 The public OpenAI Skills-only plugin is narrower again. Its ZIP contains the packaged `skills/` tree and referenced files, but not the local `.codex-plugin` lifecycle hooks. Public submission readiness is therefore a package/form contract, not evidence of public-directory approval or live hook execution.
 

package/docs/platform-compatibility.json

@@ -1,6 +1,6 @@
 {
   "format": "harness-platform-compatibility-v1",
-  "last_reviewed": "2026-09-21",
+  "last_reviewed": "2026-10-13",
   "status_vocabulary": {
     "Supported": "An official or native mechanism exists and the Harness behavior is verified.",
     "Mechanism verified": "Harness package, adapter, or installer checks pass, but a real host run is not confirmed.",
@@ -109,13 +109,13 @@
         "standaloneSkills": {"status": "Supported", "paths": {"project": [".agents/skills"], "global": ["~/.agents/skills"]}},
         "pluginSupport": {"status": "Mechanism verified", "paths": {"manifest": ["plugin.json", ".codex-plugin/plugin.json"]}},
         "bundledSkills": {"status": "Mechanism verified", "notes": "The local package contains a root skills/ tree."},
-        "hooksLifecycle": {"status": "Mechanism verified", "notes": "Codex officially supports plugin-bundled hooks and the local package is mechanism-tested. The plugin intentionally does not declare unsupported PostToolUseFailure; Codex uses documented PostToolUse semantics instead. Harness also provides an explicit user-config compatibility fallback that copies the packaged runtime and merges exact-owned entries into $CODEX_HOME/hooks.json without changing trust/config.toml. Neither path is promoted to live verified until a real host exposes and executes the hooks."},
+        "hooksLifecycle": {"status": "Partial", "notes": "Codex documents plugin-bundled hooks for manually installed desktop plugins, and the local package is mechanism-tested. The plugin intentionally does not declare unsupported PostToolUseFailure; Codex uses documented PostToolUse semantics instead. Harness also provides a user-config compatibility installer that copies the packaged runtime and merges exact-owned entries into $CODEX_HOME/hooks.json without changing trust/config.toml; successful plugin sync refreshes this copy. Live evidence verifies the UserPromptSubmit and Stop observation handlers through the compatibility fallback on one Windows Codex CLI 0.162.1 host; native plugin-bundled hook mounting and other lifecycle events remain unverified."},
         "projectScope": {"status": "Mechanism verified", "paths": {"skills": [".agents/skills"], "instructions": ["AGENTS.md"]}},
         "globalScope": {"status": "Mechanism verified", "paths": {"skills": ["~/.agents/skills"]}},
-        "installUninstallSymmetry": {"status": "Mechanism verified", "notes": "General Harness installer ownership is mechanism-tested. The optional codex-hooks compatibility fallback separately has exact-entry update/uninstall ownership tests and preserves unrelated user hooks; live Codex trust/dispatch still requires host evidence."},
+        "installUninstallSymmetry": {"status": "Mechanism verified", "notes": "General Harness installer ownership is mechanism-tested. The optional codex-hooks compatibility fallback separately has exact-entry update/uninstall ownership tests and preserves unrelated user hooks. Live evidence confirms trusted dispatch for the two observation handlers on one Windows Codex CLI host; native plugin mounting and other scopes remain unverified."},
         "assetsReferences": {"status": "Mechanism verified", "notes": "Packaged skill references are checked and remain inside the package."},
-        "updateSync": {"status": "Mechanism verified", "notes": "scripts/plugin-sync.js detects installed state and uses marketplace upgrade for an installed Codex plugin; unsupported CLI options are dropped and retried, and a Codex build without codex plugin list/add is reported as an actionable capability-boundary skip. No live Codex host refresh is preserved."},
-        "liveHostVerification": {"status": "Unknown", "notes": "No preserved Codex plugin/session artifact proves current bundled-hook entry. Native plugin mounting is preferred; the explicit user-hook fallback is mechanism-verified only and does not solve host carriers that bypass hook dispatch."}
+        "updateSync": {"status": "Mechanism verified", "notes": "scripts/plugin-sync.js detects installed state and uses marketplace upgrade for an installed Codex plugin; after successful install/update verification it refreshes the local codex-hooks compatibility runtime and hooks.json entries. Unsupported CLI options are dropped and retried, and a Codex build without codex plugin list/add is reported as an actionable capability-boundary skip. Live marketplace source reporting and plugin-sync refresh remain unverified; the separate compatibility fallback dispatch is live-verified as recorded in the evidence artifact."},
+        "liveHostVerification": {"status": "Partial", "evidence": "benchmarks/results/live-host/codex-2026-10-13/README.md", "notes": "The preserved artifact verifies two consecutive observation captures through the user-hook compatibility fallback on Codex CLI 0.162.1 for Windows, including current-turn labels. Native plugin mounting, marketplace source reporting, other lifecycle events, and other host/version combinations remain unverified."}
       }
     },
     {

package/docs/routing.md

@@ -6,7 +6,7 @@ The current architecture follows two coupled rules:
 
 > **Contract-first lifecycle; flexible reasoning/implementation and execution.**
 >
-> **Skill applicability is explicit: evaluation is mandatory, applicable core contracts are mandatory, and not-applicable dispositions require evidence.**
+> **Knowledge is step-scoped: the active step declares required/optional bindings, and required bindings resolve before that step passes.**
 
 A strong model remains free to decide *how* to perform the work. It may not decide that an applicable selected lifecycle can be skipped because the task feels simple or already understood.
 
@@ -17,7 +17,7 @@ For software/project work, Harness establishes routing context and lightweight r
 1. **Route before execution** — establish scope/tier and the smallest justified topology.
 2. **Verify before claim** — completion requires objective evidence appropriate to the change.
 3. **Re-plan after repeated failure** — after three same-signature failures, stop micro-retrying and use a fresh diagnosis / `zoom-out`.
-4. **Evaluate before omission** — read every suggested skill's complete `SKILL.md` entry before deciding applicability.
+4. **Bind knowledge by step** — compose ordered requirement steps and declare their required/optional skill or reference bindings before execution.
 5. **Resolve selected workflow** — satisfy the selected topology's required obligations before completion; tactics MAY adapt, but required lifecycle evidence cannot be silently skipped.
 6. **Surface status** — non-trivial work MUST keep the user informed through the single Harness Status format at required phase boundaries.
 
@@ -27,10 +27,11 @@ The model owns tools, implementation technique, reasoning, and decomposition det
 
 ```text
 kernel-router.js
-  ├─ delegates classification / guide discovery → tier-router.js
-  ├─ preserves tier + rationale + dynamic-skill suggestions
+  ├─ delegates classification / knowledge-signal detection → tier-router.js
+  ├─ preserves tier + rationale + normalized knowledge signals
   ├─ emits required invariants + structured workflow plan
-  ├─ requires applicability evaluation for suggested skills
+  ├─ treats keyword hits as step-composition signals, not document selectors
+  ├─ discloses bindings only for the active step / dependency-ready Fable stage
   ├─ records the selected workflow contract
   └─ exposes warnings/degraded/escape evidence instead of silently hiding limitations
 ```
@@ -89,19 +90,17 @@ label appeared on 1 of 4 turns while it sat inside the Harness Status contract
 (which is scoped to non-trivial work), and on 5 of 6 turns as its own final
 section.
 
-## Suggested skills vs. selected workflow
+## Knowledge signals and active-step bindings
 
-These are intentionally different concepts.
+Router keywords and domain matches are normalized planning inputs. They do not select, load, or print skill/reference paths. Requirement composition assigns needed knowledge to ordered steps:
 
-For **every suggested skill**:
+- Each step declares `requiredBindings` and `optionalBindings` by stable id, with a concrete path when known.
+- Only the active single-agent step or dependency-ready Fable stage exposes its bindings. Retained prompts and notifications keep this active-step view compact; future paths stay hidden.
+- A required binding MUST be loaded and its applicable skill core contract followed before the step can pass. Optional bindings resolve as loaded or not-needed.
+- An unknown/unavailable required binding remains visible and unresolved; it cannot be marked loaded without a declared path and evidence.
+- On Fable plans, the existing stage dependency graph controls readiness. A successful objective check records `binding-unresolved` until bindings resolve; rerun the exact check before the stage passes.
 
-1. **MUST** resolve/read the complete `SKILL.md` entry.
-2. **MUST** evaluate `USE FOR`, `DO NOT USE FOR`, workflow/basic flow, and hard rules.
-3. Read extra material only when the entry explicitly requires it for applicability.
-4. **MUST** resolve the suggestion as `use`, `not-applicable`, or `unresolved/unavailable`.
-5. If disposition is `use`, the skill's core contract **MUST** be followed. If it is `not-applicable`, a concise flow-grounded reason **MUST** be retained.
-
-A name, description, router summary, tier label, or generic “routine/common task” judgement is not sufficient evidence for `not-applicable`.
+For every active required skill binding, read its complete `SKILL.md` entry and follow its applicable core contract. If an active requirement does not need a discovered knowledge signal, do not bind or load an unrelated document. This replaces the former global read-every-suggestion rule while preserving per-step obligations.
 
 For the **selected workflow topology**:
 
@@ -135,7 +134,7 @@ Typical triggers: typo/docs correction, narrow local edit, bounded explanation,
 
 ### Tier 2 — Standard
 
-Typical triggers: normal feature work, bug fixes, multi-file changes, focused benchmark/review. Usually selects `iterative-single`: bounded reason/act work plus objective verification. Focused skills such as `tdd`, `verification-loop`, `security-review`, `using-git-worktrees`, and `eval-harness` may be surfaced and must be resolved for applicability.
+Typical triggers: normal feature work, bug fixes, multi-file changes, focused benchmark/review. Usually selects `iterative-single`: bounded reason/act work plus objective verification. Compose ordered requirements before execution; bind TDD to behavior-change steps, verification-loop to verification steps, and domain knowledge only where that step needs it.
 
 Operation labels such as `audit`, `evaluate`, `benchmark`, or `compare` describe **what** work is being done; they do not by themselves establish macro scope. A focused audit/review remains bounded unless an independent scope/structure signal (for example repository-wide, all files/modules, or multi-workstream structure) elevates it. A structured A/B experiment is different: its explicit control/treatment comparison is itself a multi-lane execution structure, so `A/B test` / `A/B benchmark` remains a macro signal.
 
@@ -161,7 +160,7 @@ The [workflow runtime contract](workflow-runtime.md) defines the executable boun
 
 - `workflow-gate.js` observes shell/direct mutation, Fable correlation, and major-workflow Git isolation and emits reminders.
 - `workflow-stop-gate.js` reports unresolved stage/verification evidence without rejecting Stop.
-- `workflow-disposition.js` starts/replans the run, records a scoped stage escape, or reports `blocked`.
+- `workflow-disposition.js` starts/replans the run, resolves active step/stage bindings, records a scoped stage escape, or reports `blocked`.
 
 Follow-up prompts retain useful evidence, but unresolved cognitive workflow state does not lock mutation or completion.
 

package/docs/system-one-observations.md

@@ -2,8 +2,8 @@
 
 Status: **accepted**, 2026-09-27. Owner decisions are recorded below.
 Implementation: `hooks/scripts/observation-hook.js`,
-`hooks/scripts/lib/observations.js`, `scripts/system-one-observations-export.js`
-and `scripts/system-one-observations-review.js`; tests in
+`hooks/scripts/lib/observations.js`, `scripts/system-one-observations-export.js`, `scripts/system-one-observations-import-codex-sessions.js` and
+`scripts/system-one-observations-review.js`; tests in
 `ci/mechanism-34-observations.test.js`. Issue
 [#233](https://github.com/dyphn1/Harness-everything/issues/233).
 
@@ -42,8 +42,8 @@ A turn runs from `UserPromptSubmit` to `Stop`. Its record:
 | `id`, `sessionId`, `turn`, `host`, `observedAt` | hooks | `id` = hash of session id + turn |
 | `prompt` | `UserPromptSubmit` | stored in the private text store only (see Storage) |
 | `previous` | the last assistant message before the prompt | truncated to 2 KB; text store only |
-| `router` | kernel-router output | lexical tier, strategy, suggested skills; System One shadow scores when present |
-| `behavior` | `PostToolUse`, `PostToolUseFailure` | counts and categories, never arguments: files written, distinct repositories written, files created, commands by class (git, gh, test, build, package, shell), skills loaded or read, subagents started. Failed attempts are counted separately (`toolFailures`, `failedWrites`, `failedSkillLoads`) and never count as a write or a load |
+| `router` | kernel-router output | lexical tier, strategy, normalized knowledge signals, active step/stage bindings; System One shadow scores when present |
+| `behavior` | `PostToolUse`, `PostToolUseFailure` | counts and categories, never arguments: files written, distinct repositories written, files created, commands by class (git, gh, test, build, package, shell), skills loaded or read, subagents started. Failed attempts are counted separately (`toolFailures`, `failedWrites`, `failedSkillLoads`) and never count as a write or a load. `null` means the capture source did not observe tool events; it is not a zero count. |
 | `workflow` | `workflow-run.json` / `workflow-disposition` | selected and confirmed strategy |
 | `selfReport` | label line in the final message | see below; `null` if missing or invalid |
 | `derived` | exporter | labels computed from the fields above |
@@ -98,6 +98,12 @@ purposes:
 - **Future features.** The counters can train or check later models
   without re-reading transcripts.
 
+Session backfill reads prompts and final labels, but does not reconstruct
+tool events or file writes. Its `behavior` is therefore `null`. Exports count
+observed and unobserved behavior separately and derive contradictions only
+from observed behavior. The default review page includes unobserved records
+and identifies the evidence gap.
+
 **Owner review.** Missing labels, contradictions, and turns where the
 router's tier and the self-reported tier differ go to a blind review page.
 The owner decides validity, context dependence and tier; each decision
@@ -157,11 +163,16 @@ warning sign. The review page samples the turns where they differ.
     it wrote no label; the same text as JSON reached the model and all five
     test turns carried a label. The Codex manifest therefore runs the router
     through `hooks/scripts/codex-user-prompt.js`, which wraps its output.
-  - Plugin-bundled hooks do not run on this version (`plugin_hooks` is
-    `removed`); the explicit fallback `harness codex-hooks install` is
-    needed, and Codex runs the hooks only after they are trusted in
-    `/hooks`.
+  - The retained `codex-cli 0.157.1` evidence found plugin hooks removed
+    (`plugin_hooks`); the local CLI path therefore uses the user-hook
+    compatibility installer. Successful `plugin:hosts` runs now install or
+    refresh that copied runtime and its `hooks.json` entries. The installer
+    does not change trust state; Codex still requires hook review/trust in
+    `/hooks`. Status reports `inactive` when absent and
+    `configured-unverified` when the files are healthy, because this command
+    cannot read Codex trust state.
   - The final message comes from the rollout's `task_complete` event.
+- Fresh live-host verification on Windows (Codex CLI 0.162.1, 2026-10-13) exercised the user-hook compatibility fallback: only the `UserPromptSubmit` and `Stop` observation hooks were individually reviewed/trusted. Two consecutive real turns produced `host: "codex"` records with distinct current `turn_id` values and their respective valid self-reports. The sanitized record excerpt and scope limits are preserved in [Codex live-host evidence](../benchmarks/results/live-host/codex-2026-10-13/README.md). This does not verify native plugin-bundled hooks, other lifecycle events, or tool behavior capture.
 - The final message must belong to the current turn. A transcript scan
   stops at the start of the current turn (Codex `task_started` or a user
   message; a Claude user prompt) and a Codex `task_complete` must carry the
@@ -174,18 +185,34 @@ warning sign. The review page samples the turns where they differ.
 - A missing field records `null` with a reason code. Collection must never
   block, slow down, or fail a turn; each hook has a short time budget.
 
+## Session backfill
+
+To recover self-reported labels written before the observation hooks were active, run:
+
+    node scripts/system-one-observations-import-codex-sessions.js --since 2026-09-27
+
+The importer scans local Codex rollout files and pairs each completed turn with its first user text item. It reads the final label from `task_complete.last_agent_message`; when that field is absent or not a string, the last assistant `response_item` can provide it unless that item is marked `commentary`. When a string completion has no label and the last assistant item is not marked `commentary` and has a valid label, their bodies are compared after `obs.stripLabels` removes label comments and trims surrounding whitespace. A match lets the assistant label provide the missing label; a difference reports `ambiguousFinalMessage`, skips the turn, and clears previous-message context rather than choosing one representation. An explicitly unlabeled completion never inherits a commentary or earlier assistant label, and an invalid completion label is not replaced by the assistant label.
+
+The importer accepts only valid label lines, applies the same email/home-path redaction, and appends idempotently to the private observations store. Backfill and live hook records deduplicate by `(host, writer.sessionId, writer.turnId)`. For older live records without a turn ID, an exact turn-and-text match is skipped; a partial match is counted as ambiguous and skipped to avoid silently duplicating training data. Duplicate and ambiguous legacy live matches are checked atomically under the store lock. A bounded lock timeout is reported as a persistence failure, not as a duplicate, and gives the importer a nonzero exit status; migration lock timeouts are reported the same way. Existing backfill behavior placeholders are migrated to `null`. Reports contain counts and generic error descriptions without printing session text. The cutoff defaults to the date the label contract was accepted. The importer never uploads or writes session content into the repository.
+
 ## Export
 
 `scripts/system-one-observations-export.js` writes to the private data
 repository:
 
 - `prompts-observed.jsonl`: `{id, family, source: "observation", split, text}`
-- `labels-observed.jsonl`: `{id, validity, contextDependent, tier, tierSource, intents, workflow, skills}`
+- `labels-observed.jsonl`: `{id, validity, contextDependent, tier, tierSource, intents, workflow, skills, behaviorEvidence, contradictions}`
 
 `family` groups near-duplicate prompts. The split is by time: the newest 15%
 is validation. The existing holdouts stay frozen and separate. Observed data
 may later seed a new holdout, but only after owner review.
 
+For a training candidate restricted to labels from the accepted label-line date, use an output directory outside the repository:
+
+    node scripts/system-one-observations-export.js --out <private-output-dir> --since 2026-09-27 --self-report-only
+
+This keeps unlabeled observations out of the candidate and leaves existing model and holdout directories untouched.
+
 ## Phases
 
 1. **Contract.** Define the label-line format in `AGENTS.md` rule 11 and in

package/docs/system-one-routing.md

@@ -360,9 +360,9 @@ small model only has to separate a few options at a time.
    `discuss`, `git`, `fix`, `edit`, `feature`, `refactor`, `review`, `test`,
    `docs`, `plan`, `investigate` or `unclassified`. A prompt has one primary
    intent and may have secondary intents.
-3. **Skills**: which canonical skills fit the prompt, scored against skill
-   descriptions. Only skills above the stage's calibrated threshold are
-   suggested, and they are suggestions, never required reads.
+3. **Skill relevance**: candidate signals for requirement composition,
+   scored against canonical skill descriptions. These candidates do not select
+   paths, trigger loads, or bypass the active-step binding contract.
 
 Each stage has its own gates, and a stage ships only when it passes them.
 The relevance-native plan in
@@ -371,8 +371,10 @@ adds a validity stage first and runs intent before tier, because tier3 is
 composed from the intent scores. Tier was trained first because the
 reviewed holdout exists for it. Later stages reuse the
 same collector, labeler, trainer and evaluator with a different catalog.
-Suggestions are advisory: explicit workflow requests, action gates, memory
-ownership, the Rule of 3 and deterministic policy always take precedence.
+Relevance candidates are advisory inputs to requirement composition: explicit
+workflow requests, action gates, memory ownership, the Rule of 3 and
+deterministic policy always take precedence. A candidate becomes a skill path
+only when a specific ordered requirement declares it as a binding.
 
 ## Rollout gates
 
@@ -383,8 +385,9 @@ provenance, repeatability and advisory rules below still apply.
 
 Phase 4 requires a separately reviewed, family-disjoint holdout of at least 200
 cases, at least 50 each in English and Traditional Chinese. System One output is
-advisory: it informs the agent and suggests skills. It never grants or removes
-policy. The owner therefore set the target at accepted precision ≥85% (the
+advisory: it informs requirement composition and provides skill-relevance
+candidates. It never grants, removes policy, or loads paths. The owner therefore
+set the target at accepted precision ≥85% (the
 80–90% band), coverage ≥80%, and macro-F1 at least the lexical baseline. A
 probabilistic scorer small enough to ship inside a skills plugin (a few MB, not
 hundreds) is not expected to reach 98%.

package/docs/system-one-suggestion-gates.md

@@ -42,12 +42,12 @@ All stages share the scoring and the calibration. Only the readout differs.
 | Intent | the 12 intents of [system-one-intent.md](system-one-intent.md) | set: every intent at or above its threshold, highest `p` first, truncated at the cap | 3 |
 | Tier | `tier1`, `tier2`, `tier3` | composed (see [Tier composition](#tier-composition)): tier3 when `feature` or `refactor` reaches its intent threshold; otherwise the tier scorer's pick; final tier = max(that, structural floor); none → abstain | 1 |
 | Workflow | the router's strategies (`direct-single`, `iterative-single`, `fable-staged`, `fable-parallel`, `fable-multi-agent-workspace`) | pick one, same rule; an explicit workflow request always wins | 1 |
-| Skills | canonical skills, scored against their descriptions | set, same rule | 3 |
+| Skill relevance | canonical skills, scored against their descriptions | candidate signals for requirement composition; never a document path/load decision | 3 |
 
-The cap of 3 for set stages comes from AGENTS.md rule 10: a suggested skill
-must be read before it can be dismissed, so each extra suggestion has a
-reading cost. The cap is part of the readout, so noise is bounded by
-construction; the gates then judge what survives the cap.
+The cap of 3 for set stages bounds scorer output noise in this proposed model;
+it is not a cap on the number of required workflow bindings. Under issue #297,
+any candidate knowledge signal must still be composed onto a specific ordered
+requirement step before a skill/reference path is disclosed or loaded.
 
 Stages run in table order: validity, intent, tier, workflow, skills. Tier
 reads the intent scores, so intent runs before it.

package/docs/workflow-runtime.md

@@ -6,7 +6,7 @@ Harness uses workflow state to **observe, explain, and remind about semantic con
 
 The runtime follows **minimal rails, maximum freedom**:
 
-- routing **MUST** establish the selected/deferred topology and suggested-skill applicability set;
+- routing **MUST** establish the selected/deferred topology and normalized knowledge signals for ordered requirement composition;
 - workflow state records useful evidence and unresolved obligations without becoming a cognitive lock;
 - selected-topology required obligations and applicable skill core contracts are semantic **MUSTs**;
 - the agent **MUST** verify before claiming completion and use the single user-visible Harness Status at required phase boundaries for non-trivial work;
@@ -16,7 +16,7 @@ The runtime follows **minimal rails, maximum freedom**:
 
 Those cognitive workflow conditions **MUST NOT** trap a session or require a reset command.
 
-A semantic MUST is not the same thing as a hard runtime lock. User-visible status, routing/applicability obligations, and verification-before-claim can remain mandatory agent contracts while host hooks observe or remind on a best-effort basis. Do not downgrade a semantic obligation to optional advice merely because the host cannot block it.
+A semantic MUST is not the same thing as a hard runtime lock. User-visible status, active-binding obligations, and verification-before-claim can remain mandatory agent contracts while host hooks observe or remind on a best-effort basis. Do not downgrade a semantic obligation to optional advice merely because the host cannot block it.
 
 The unified status shape uses a visible Markdown hierarchy:
 
@@ -87,8 +87,12 @@ A workflow may retain `blocked` as a descriptive status recorded by the controll
 
 ## Fable and worktrees
 
+Any present `requiredBindings` or `optionalBindings` declaration MUST be an array. Omitted declarations and empty arrays are supported; `null`, objects, strings, booleans, and numbers are rejected before a requirement plan changes workflow state, including fragments without `stepType`.
+
 When a Fable topology is selected, its stage graphs, dependencies, write sets, objective checks, synthesis barrier, and required verifier are semantic **MUSTs**. `maxWorkers` remains a **MAY** planning hint and no longer chunks ready stages as a hard concurrency cap.
 
+Requirement steps and Fable stages may declare required/optional skill or reference bindings. Runtime output exposes only the active single-agent step or dependency-ready Fable stages. A successful Fable check with unresolved bindings records `binding-unresolved`; after dispositions resolve, the exact check must be rerun before the stage passes. Unknown/unavailable bindings remain visible, while workflow hooks and Stop remain fail-open reminders. A binding disposition is auditable agent evidence, not proof that a host actually loaded or followed the referenced document.
+
 For Tier-3/Fable broad mutation, isolation disposition is a semantic **MUST**: use/reuse a verified linked worktree, or record an explicit degraded fallback when isolation is unavailable or the user explicitly chooses to stay in place. Missing isolation is surfaced prominently, but Harness-owned cognitive workflow hooks do not turn it into a self-deadlocking runtime state.
 
 ## Legacy state

package/docs/workflows/harness-everything.md

@@ -1,6 +1,6 @@
 # Workflow: Harness Everything
 
-> Route software/project work through the Harness kernel: classify Tier 1/2/3, establish mandatory invariants, then let the agent choose tactics and domain skills. Not general Q&A or non-software writing.
+> Route software/project work through the Harness kernel: classify Tier 1/2/3, establish mandatory invariants, compose step-scoped knowledge bindings, then let the agent choose tactics. Not general Q&A or non-software writing.
 
 Source of truth: `harness-everything/SKILL.md`. Deep dive: `harness-everything/references/triage-and-tiers.md`.
 
@@ -8,7 +8,7 @@ Source of truth: `harness-everything/SKILL.md`. Deep dive: `harness-everything/r
 
 ## 1. Skill Behavior Workflow
 
-The kernel establishes the smallest applicable workflow before mutation. Suggested skills are mandatory to evaluate and advisory to execute; the selected topology is mandatory to resolve.
+The kernel establishes the smallest sufficient workflow before mutation. Normalized keyword signals help compose ordered requirements but never select document paths. Each step declares its required/optional knowledge; the selected topology is mandatory to resolve.
 
 ```mermaid
 graph TD
@@ -22,8 +22,8 @@ graph TD
   Tier1Route --> Checkpoint["Surface Harness Routing Checkpoint"]
   Tier2Route --> Checkpoint
   Tier3Route --> Checkpoint
-  Checkpoint --> Evaluate["Read each suggested SKILL.md: USE FOR, DO NOT USE FOR, flow, hard rules"]
-  Evaluate --> Execute["Execute selected topology to resolution"]
+  Checkpoint --> Decompose["Compose ordered requirement steps and bindings"]
+  Decompose --> Execute["Load/resolve only active-step bindings; execute selected topology"]
   Execute --> VerifyGate{Objective evidence supports completion?}
   VerifyGate -->|Yes| Done([Evidence-backed completion])
   VerifyGate -->|No| Diagnose["Diagnose / bounded re-plan"]
@@ -37,18 +37,18 @@ graph TD
 
 ## 2. Triggering and Routing Path
 
-This diagram shows how the `harness-everything` skill is triggered and how it chains with companion skills. Routing suggestions are conditional on applicability; the selected topology is not advisory.
+This diagram shows how the `harness-everything` skill is triggered and how it composes step-scoped knowledge bindings. Keyword signals are not document selectors; the selected topology is not advisory.
 
 ```mermaid
 graph LR
   UserPrompt([User Input]) --> Router["harness-everything / kernel-router.js + tier-router.js"]
 
-  Router -->|Bug / Feature / Refactor| Ch1["tdd + todo-driven-workflow + verification-loop + verify-before-claim"]
-  Router -->|Commit / History / Isolation| Ch2["git-commit + rewrite-commits + using-git-worktrees + verification-loop"]
-  Router -->|Large / Multi-source / Multi-session| Ch3["fable-mode + fable-discipline + multi-agent-workspace + using-git-worktrees"]
-  Router -->|Architecture / Plan review| Ch4["improve-codebase-architecture + grill-me + grill-with-docs + to-spec + to-tickets"]
+  Router -->|Behavior change| Ch1["Bind TDD to the behavior-change step"]
+  Router -->|Verification| Ch2["Bind verification-loop to the verification step"]
+  Router -->|Large / Multi-source / Multi-session| Ch3["Fable stages expose bindings only when dependencies pass"]
+  Router -->|Architecture / Plan review| Ch4["Bind domain skills/references only to their consuming step"]
 
-  Ch1 --> Invariants["Invariants: route-before-execution, verify-before-claim, re-plan-after-x3, evaluate-before-skip, resolve-selected-workflow"]
+  Ch1 --> Invariants["Invariants: route-before-execution, verify-before-claim, re-plan-after-x3, resolve-active-required-bindings, resolve-selected-workflow"]
   Ch2 --> Invariants
   Ch3 --> Invariants
   Ch4 --> Invariants
@@ -65,9 +65,9 @@ graph LR
 graph TD
   Input1["User: 'Add a new settings page'"] --> Router1["kernel-router.js executes"]
   Router1 --> Triage2["Triaged as Tier 2: Standard Task"]
-  Triage2 --> Checkpoint1["Routing Checkpoint: tdd, todo-driven-workflow, verification-loop suggested"]
-  Checkpoint1 --> Eval1["Read each suggested SKILL.md; keep applicable, mark not-applicable with flow-grounded reason"]
-  Eval1 --> Exec1["Execute iterative-single to resolution; verify with tests before claiming done"]
+  Triage2 --> Checkpoint1["Planning signals help decompose ordered requirements"]
+  Checkpoint1 --> Eval1["Bind TDD to behavior change; verification-loop to verification"]
+  Eval1 --> Exec1["Load current-step binding, execute, and verify before claiming done"]
   Exec1 --> Done1([Feature delivered with objective evidence])
 
   Input2["User: 'Refactor DB architecture across services'"] --> Router2["kernel-router.js executes"]
@@ -91,7 +91,7 @@ Escape applies only to genuinely uncovered workflow scope with explicit scope +
 To ensure that the `harness-everything` skill is operating in strict compliance with Harness OS design laws, verify the following:
 
 - [ ] **Route before execution**: scope/tier and smallest applicable workflow established before mutation.
-- [ ] **Evaluate before omission**: each suggested skill's complete `SKILL.md` flow evaluated before deciding applicability.
+- [ ] **Bind knowledge by step**: required/optional skills and references are declared per ordered requirement; only active paths are loaded/disclosed.
 - [ ] **Resolve selected workflow**: the selected topology executed to resolution; escape only for uncovered scope with evidence.
 - [ ] **Verify before claim**: objective evidence (tests, checks, quoted tool output) supports completion.
 - [ ] **Re-plan on repetition**: after 3 same-signature failures, `zoom-out` reflection completed before resuming.

package/evals/harness-everything/tasks/positive-tier1.yaml

@@ -1,6 +1,6 @@
 id: positive-trivial-tier1-001
 name: Trivial edit routes to Tier 1
-description: "Route software/project work through Harness: classify tier/topology, resolve suggested skills, apply semantic obligations, and keep tactics flexible. Use for software triage/routing/re-routing; not general Q&A or non-software writing."
+description: "Route software/project work through Harness: classify tier/topology, compose active-step knowledge bindings, apply semantic obligations, and keep tactics flexible. Use for software triage/routing/re-routing; not general Q&A or non-software writing."
 tags:
   - positive-trigger
   - tier-1

package/evals/harness-everything/tasks/positive-tier2.yaml

@@ -1,6 +1,6 @@
 id: positive-standard-tier2-001
 name: Standard bug fix routes to Tier 2
-description: "Route software/project work through Harness: classify tier/topology, resolve suggested skills, apply semantic obligations, and keep tactics flexible. Use for software triage/routing/re-routing; not general Q&A or non-software writing."
+description: "Route software/project work through Harness: classify tier/topology, compose active-step knowledge bindings, apply semantic obligations, and keep tactics flexible. Use for software triage/routing/re-routing; not general Q&A or non-software writing."
 tags:
   - positive-trigger
   - tier-2

package/evals/harness-everything/tasks/positive-tier3.yaml

@@ -1,6 +1,6 @@
 id: positive-macro-tier3-001
 name: Architectural task routes to Tier 3
-description: "Route software/project work through Harness: classify tier/topology, resolve suggested skills, apply semantic obligations, and keep tactics flexible. Use for software triage/routing/re-routing; not general Q&A or non-software writing."
+description: "Route software/project work through Harness: classify tier/topology, compose active-step knowledge bindings, apply semantic obligations, and keep tactics flexible. Use for software triage/routing/re-routing; not general Q&A or non-software writing."
 tags:
   - positive-trigger
   - tier-3

package/fable-mode/CONTRACT-FORMAT.md

@@ -37,6 +37,8 @@ Every planned stage declares dependency and write scope before dispatch:
   "outputPath": "path/to/artifact-or-null",
   "dependsOn": ["stage-1"],
   "writeSet": ["src/auth", "tests/auth.test.js"],
+  "requiredBindings": [{ "id": "tdd", "path": "tdd/SKILL.md" }],
+  "optionalBindings": [{ "id": "security-review", "path": "security-review/SKILL.md" }],
   "checkCommand": "node --test tests/auth.test.js",
   "passCondition": "exit 0",
   "failureReturn": "failure summary + evidence + missing prerequisite"
@@ -48,6 +50,7 @@ Rules:
 - `stageId`, `goal`, `agent`, and `task` are required.
 - `dependsOn` is always explicit. Use `[]` for a root stage.
 - `writeSet` is always explicit. Use `[]` for a read-only stage.
+- `requiredBindings` and `optionalBindings` are optional arrays. Each entry is a stable `id` and may declare a concrete repository-relative `path`; paths reject absolute names, globs, and traversal. Availability is `available` only when the path resolves to a readable file: workspace references resolve only under the workspace, while recognized Harness bindings (a registered id at its registered path, or a skill id naming its own `<id>/SKILL.md`) also search installed Harness skill roots (`missing` otherwise; `unverified` when no hook runtime is installed). An id without a path resolves through self-evolved manifest metadata, else remains visible with unknown availability. A binding that does not resolve cannot be recorded as `loaded`.
 - `writeSet` contains concrete repository-relative path scopes, not globs,
   absolute paths, or `..` traversal.
 - a directory scope covers descendants; overlapping scopes cannot run in the
@@ -60,7 +63,7 @@ Rules:
 
 ## Workflow-plan consumer
 
-For a session with an active mandatory workflow, write the stage array to the router-displayed `workflow-stages.json` path and invoke its `workflow-disposition.js start --session-id <id>` command. This binds the run to the active `workflowId` and bound workspace even after entering a linked worktree. Every required stage needs an objective check, and an independent plan needs a read-only `fable-verifier` stage depending on all other stages. Stage results need observed worker identities and numeric exit codes; missing metadata is blocked/degraded, not success.
+For a session with an active mandatory workflow, write the stage array to the router-displayed `workflow-stages.json` path and invoke its `workflow-disposition.js start --session-id <id>` command. This binds the run to the active `workflowId` and bound workspace even after entering a linked worktree. The start/check output exposes bindings only for dependency-ready stages; future-stage paths stay undisclosed. Resolve an active binding with `workflow-disposition.js stage-binding --stage-id <id> --binding-id <id> --disposition loaded|not-needed|unavailable --evidence <evidence>`. A successful check with unresolved bindings records `binding-unresolved`; resolve them, then rerun the exact check before the stage can pass. This state is a reminder, not a tool or Stop lock. Every required stage needs an objective check, and an independent plan needs a read-only `fable-verifier` stage depending on all other stages. Stage results need observed worker identities and numeric exit codes; missing metadata is unresolved, not success.
 
 For standalone use without an active session contract, write the router contract and stage array to files and run:
 

package/fable-mode/SKILL.md

@@ -4,7 +4,7 @@ description: "Stage large tasks through plans, named fable agents, failable chec
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.30.7
+  version: 0.31.0
 ---
 
 # Fable Mode
@@ -29,17 +29,15 @@ metadata:
 
 ## Select Operation First
 
-For explanation/profile-only lookup, read only `<this-skill-dir>/references/profile-lookup.md` and answer. No stage state, delegation, or selector source reads. Quoted aliases do not start Fable. Mixed execution retains its topology.
-
-Execution follows the workflow below.
+For explanation/profile-only lookup, read only `<this-skill-dir>/references/profile-lookup.md` and answer. No stage state, delegation, or selector source reads. Quoted aliases do not start Fable. Mixed execution retains its topology; execution follows the workflow below.
 
 ## Workflow
 
 1. Discover the runtime and lock the authorized file scope before edits.
-2. Set artifact/check per stage; advisory replans never halt. Rule-of-3 applies to 3 same-signature failures.
+2. Per stage, set artifact, check, and required/optional bindings; dependency-ready stages disclose them, passing once resolved. Gaps never lock tools or Stop; advisory replans never halt. Rule-of-3 covers same-signature failures.
 3. Resolve the requested behavior profile with `model-selector.js`; `opus`, `sonnet`/`sonnect`, and `haiku` are compatibility aliases, not model bindings.
-4. Delegate by profile: orchestrator coordinates, reasoning handles bounded judgment, mechanical handles low-ambiguity work, and workers never spawn workers.
-5. Treat the host runtime-model floor as advisory; record its status without blocking Fable solely for model choice.
-6. Run each stage check, cold-review high-stakes artifacts, and audit profile/runtime/fallback fields.
+4. Delegate by profile: orchestrator coordinates, reasoning takes bounded judgment, mechanical takes low-ambiguity work; workers never spawn workers.
+5. The host runtime-model floor is advisory; record it, never block on model choice alone.
+6. Run stage checks, cold-review high-stakes artifacts, and audit profile/runtime/fallback fields.
 
 Deep dive: <this-skill-dir>/references/model-matrix.md