harness-everything 0.30.10 → 0.31.0

package/docs/platform-capabilities.md

@@ -19,9 +19,11 @@ Codex and OpenCode are `Partial` in `liveHostVerification`. The Codex artifact v
 
 ### 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
 
@@ -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.
+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 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 followed read-before-skip or that another ChatGPT/Codex installation loaded the same hooks.
+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
 

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

@@ -42,7 +42,7 @@ 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 |
+| `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 |

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

package/fable-mode/agents/fable-orchestrator.md

@@ -45,6 +45,12 @@ first. Every stage declares `stageId`, goal, named agent, self-contained task,
 expected output, `dependsOn`, and `writeSet` per
 `fable-mode/CONTRACT-FORMAT.md`. `dependsOn: []` means no prerequisite;
 `writeSet: []` means read-only. Workers never widen their own write set.
+Declare stage-specific `requiredBindings` and `optionalBindings` in the same
+contract. The consumer/start/check output exposes paths only for dependency-ready
+stages; never preload bindings from future stages. Resolve active bindings with
+`workflow-disposition.js stage-binding` and evidence before passing the stage.
+If its objective check passes while bindings remain unresolved, the contract
+records `binding-unresolved`; resolve the bindings and rerun that exact check.
 
 Pass the router contract and stage array through
 `fable-mode/scripts/workflow-plan-consumer.js` before spawning anything. Use the
@@ -97,10 +103,11 @@ that stage's check before continuing.
 The run-scoped contract already exists before execution. When its exact
 `checkCommand` runs, `contract-test.js` correlates it to one
 `planId/runId/stageId`, updates that contract, and writes
-`evidence/<stageId>.json`. If the command is ambiguous across runs, none of the
-contracts is updated and the ambiguity must be resolved. Before delivery,
+`evidence/<stageId>.json`. A `pass` requires both an objective check and
+resolved declared bindings. If the command is ambiguous across runs, none of
+the contracts is updated and the ambiguity must be resolved. Before delivery,
 confirm every check-bearing contract in this run is `pass`; `planned`,
-`running`, `pending`, or `fail` is not delivery evidence.
+`running`, `pending`, `fail`, or `binding-unresolved` is not delivery evidence.
 
 The subagent scope guard separately compares worker changes to the immutable
 `writeSet` snapshot captured at burst start. An in-scope change is not proof of

package/fable-mode/execution-guardrails/SKILL.md

@@ -4,7 +4,7 @@ description: "Reference guardrails for verified warnings and safe replacements;
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.30.7
+  version: 0.31.0
 ---
 
 # Execution Guardrails

package/fable-mode/fable-haiku/SKILL.md

@@ -4,7 +4,7 @@ description: "Reference mechanical behavior profile (legacy alias haiku) for bul
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.30.7
+  version: 0.31.0
 ---
 
 # Fable Mode — Haiku

package/fable-mode/fable-opus/SKILL.md

@@ -4,7 +4,7 @@ description: "Reference orchestrator behavior profile (legacy alias opus) for st
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.30.7
+  version: 0.31.0
 ---
 
 # Fable Mode — Opus

package/fable-mode/fable-sonnet/SKILL.md

@@ -4,7 +4,7 @@ description: "Reference reasoning behavior profile (legacy alias sonnet/sonnect)
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.30.7
+  version: 0.31.0
 ---
 
 # Fable Mode — Sonnet