harness-everything 0.15.0 → 0.16.1

package/docs/platform-capabilities.md

@@ -19,9 +19,9 @@ All `liveHostVerification` rows except OpenCode are `Unknown`. OpenCode's row is
 
 ### Routing contract vs. host evidence
 
-The repository routing contract uses **mandatory applicable workflow / conditional scoped escape**. Each suggested skill still requires reading its complete `SKILL.md` entry/basic flow before omission; the selected topology must resolve its applicable lifecycle obligations. 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 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.
 
-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 now carry workflow entry/completion gates, 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.
+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.
 
 ## Current capability summary
 
@@ -64,6 +64,22 @@ Codex has two paths that must not be collapsed:
 
 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.
 
+### 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:
+
+```bash
+harness codex-hooks install
+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.
+
+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 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.
 
 ## Install/uninstall ownership boundary
@@ -72,7 +88,7 @@ The general installer merges shared files only through Harness-owned markers and
 
 ## OpenCode boundary
 
-The OpenCode adapter uses the documented plugin API and has deterministic mechanism coverage. Retained evidence supports project-scope `.js` loading and edit/verification state on OpenCode 1.18.31 (macOS): [live-host evidence](../benchmarks/results/live-host/opencode-2026-09-16/README.md). The final snapshot is post-reset (`hardLock: false`, `count: 1`), not a history of the enforcement sequence. Hard lock is only an interactive observation with no retained blocked-tool trace. Reflection was operator-seeded, then agent-rewritten. Agent-controlled state deletion resets the breaker, so do not promote this into a durable hard-enforcement or behavioral-effectiveness claim. `.mjs` auto-discovery is broken on this host version (issue #127). Global scope, npm-package installation, and other host versions remain unverified.
+The OpenCode adapter uses the documented plugin API and has deterministic mechanism coverage. Retained evidence supports project-scope `.js` loading and edit/verification state on OpenCode 1.18.31 (macOS): [live-host evidence](../benchmarks/results/live-host/opencode-2026-09-16/README.md). The retained snapshot predates #190 and remains historical evidence only. Current OpenCode removes the permanent post-reflection hard lock; only the third-failure reflection boundary pauses edits. Reflection was operator-seeded, then agent-rewritten, so do not promote this into a behavioral-effectiveness claim. `.mjs` auto-discovery is broken on this host version (issue #127). Global scope, npm-package installation, and other host versions remain unverified.
 
 ## Official sources
 

package/docs/platform-compatibility.json

@@ -1,6 +1,6 @@
 {
   "format": "harness-platform-compatibility-v1",
-  "last_reviewed": "2026-09-14",
+  "last_reviewed": "2026-09-19",
   "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-supported SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, SubagentStart, SubagentStop, and Stop are covered by package checks; the plugin intentionally does not declare unsupported PostToolUseFailure. Non-managed hooks still require trust."},
+        "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."},
         "projectScope": {"status": "Mechanism verified", "paths": {"skills": [".agents/skills"], "instructions": ["AGENTS.md"]}},
         "globalScope": {"status": "Mechanism verified", "paths": {"skills": ["~/.agents/skills"]}},
-        "installUninstallSymmetry": {"status": "Mechanism verified", "notes": "Harness installer round-trip checks cover owned files and user-owned collisions."},
+        "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."},
         "assetsReferences": {"status": "Mechanism verified", "notes": "Packaged skill references are checked and remain inside the package."},
         "updateSync": {"status": "Unknown", "notes": "A real marketplace refresh has not been run in a Codex host."},
-        "liveHostVerification": {"status": "Unknown", "notes": "No preserved Codex plugin/session artifact is committed."}
+        "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."}
       }
     },
     {

package/docs/routing.md

@@ -4,21 +4,21 @@ Harness classifies software work and selects the smallest sufficient execution t
 
 The current architecture follows two coupled rules:
 
-> **Mandatory applicable workflow; flexible reasoning/implementation inside it.**
+> **Guidance-first workflow; flexible reasoning/implementation and execution.**
 >
-> **Skill applicability is evaluated explicitly; workflow escape is exception-only and evidence-backed.**
+> **Skill applicability is evaluated explicitly; skipped guidance should have a concise evidence-based reason.**
 
 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.
 
 ## Kernel invariants
 
-For software/project work, Harness establishes mandatory rails before mutation:
+For software/project work, Harness establishes routing context and lightweight rails before broad mutation:
 
 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.
-5. **Resolve selected workflow** - successful completion requires `satisfied`; `blocked` is a reportable incomplete outcome. Escape covers only a declared stage and preserves other obligations.
+5. **Review selected workflow** — use it as planning guidance and surface unresolved evidence before claiming completion.
 
 The model owns tools, implementation technique, reasoning, and decomposition details inside those rails.
 
@@ -30,8 +30,8 @@ kernel-router.js
   ├─ preserves tier + rationale + dynamic-skill recommendations
   ├─ emits required invariants + structured workflow plan
   ├─ requires applicability evaluation for suggested skills
-  ├─ activates the selected workflow execution contract
-  └─ exposes explicit blocked/degraded/escape state instead of silent downgrade
+  ├─ records the selected workflow guidance
+  └─ exposes warnings/degraded/escape evidence instead of silently hiding limitations
 ```
 
 Use:
@@ -97,7 +97,7 @@ No universal `TODO → TDD → verification-loop` order is implied. But when a s
 
 Typical triggers: repository-wide refactors, architecture/migration work, broad synthesis, or bounded delegation. The router may select `fable-staged`, `fable-parallel`, or `fable-multi-agent-workspace`.
 
-A selected Fable topology is mandatory for that run. `fable-parallel` dispatches only validated independent batches; `fable-staged` preserves ordered stage contracts; workspace mode preserves durable handoffs/roles while Fable owns staged execution.
+A selected Fable topology is structured guidance for that run; dependency/write-set validation remains useful evidence, while missing workflow state does not hard-block execution.
 
 Tier 3 does **not** automatically mean multi-agent. The smallest sufficient topology still wins.
 
@@ -107,25 +107,25 @@ Tier 3 does **not** automatically mean multi-agent. The smallest sufficient topo
 
 Policy lives in `hooks/scripts/action-gate-rules.json`. Matched actions are handled according to host capability and configured policy; approved/executed payload identity is audited. `HARNESS_ACTION_GATE_POLICY=always-ask` forces Claude's ask path where supported. Unsupported host behavior must remain visible rather than being described as equivalent hard enforcement.
 
-## Workflow lifecycle gates
+## Workflow lifecycle reminders
 
 The [workflow runtime contract](workflow-runtime.md) defines the executable boundary:
 
-- `workflow-gate.js` checks shell/direct mutation, correlated Fable entry, and major-workflow Git isolation.
-- `workflow-stop-gate.js` checks manifest stage membership and observed verification evidence before `satisfied`.
+- `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`.
 
-A follow-up prompt cannot erase unresolved obligations. Start from the router's displayed session stage-specification path; source mutation waits for entry and isolation. Replan is bounded. Escape requires `workflow-uncovered-scope` or `host-capability-unavailable`, a stage id, uncovered scope, and evidence. It never waives isolation or independent verification.
+Follow-up prompts retain useful evidence, but unresolved cognitive workflow state does not lock mutation or completion.
 
 Direct/iterative verification milestones are checked, while semantic check quality and iteration budgeting remain executor obligations. Shell inspection does not contain arbitrary script side effects. Package/mechanism tests do not prove host loading or behavioral compliance; #82 owns retained live evidence.
 
 ## Cognitive OS relationship
 
-`install-cognitive-os` remains the explanatory/manual entry point for Discover → Think → Try → Summarize → Record. It is a reasoning policy, not a peer skill that must be selected before domain work. The selected workflow contract governs lifecycle obligations; the model retains freedom inside it.
+`install-cognitive-os` remains the explanatory/manual entry point for Discover → Think → Try → Summarize → Record. It is a reasoning policy, not a peer skill that must be selected before domain work. The selected workflow guidance informs lifecycle choices; the model retains execution freedom.
 
-## Enforcement strength
+## Guidance and enforcement strength
 
-A contract can be semantically mandatory even when a host cannot mechanically enforce every transition. Keep those claims separate:
+Workflow guidance is intentionally non-blocking across hosts. Keep that separate from Rule-of-3 and explicit permission enforcement.
 
 - **contract:** what the agent is required to do;
 - **mechanism:** which transitions a packaged hook/plugin can block or observe;

package/docs/workflow-runtime.md

@@ -1,122 +1,92 @@
-# Selected workflow runtime
+# Workflow Runtime
 
-The selected applicable topology is mandatory. This contract governs lifecycle
-obligations; agents still choose tools, reasoning, and implementation inside it.
-Skill suggestions require individual applicability evaluation, not one universal
-skill sequence. Git mutation isolation and durable multi-agent workspace state
-are separate concerns.
+Harness uses workflow state to **observe, explain, and remind**. It is not a numeric-budget scheduler.
 
-## State and entry
+## Product rule
 
-`UserPromptSubmit` records `workflow-run.json` in the bound workspace's global
-Harness session state. It includes a unique `workflowId`, complete plan, prompt
-hash (no prompt text), revision count, and scoped exceptions. Unresolved work
-survives follow-up/status prompts; a weaker route cannot erase it. A stronger
-route blocks mutation until an explicit replan. A new task after `satisfied`
-gets a new identity. Invalid recorded state fails closed with a diagnostic.
+The runtime follows **minimal rails, maximum freedom**:
 
-```text
-pending -> running -> satisfied
-              |          (only after required evidence)
-              -> blocked -> start/replan (within budget)
-```
+- routing selects a useful topology and suggested skills;
+- workflow state records useful evidence and unresolved obligations;
+- verification hooks remind when evidence is missing;
+- worktree/isolation checks warn when a safer execution shape is available;
+- iteration, revision, replan, and worker counts are planning hints only.
 
-`blocked` is a reportable incomplete outcome, never successful completion.
-`deferred` means no topology has been selected. Legacy `active`/`escaped` records
-remain subject to isolation and cannot supply a correlated run implicitly.
+None of those cognitive workflow conditions should trap a session or require a reset command.
 
-For Fable, write a stage array in the exact `workflow-stages.json` path displayed
-by the router. This one file is allowed as runtime bootstrap data before entry;
-the exception does not authorize changing workflow state or source artifacts.
-Use the [stage schema](../fable-mode/CONTRACT-FORMAT.md); each stage needs an
-objective `checkCommand` and `passCondition`. If the plan requires independent
-verification, declare a read-only `fable-verifier` stage depending on every
-other stage. Then run the displayed controller with the host session id:
+The two intentionally separate hard boundaries are:
 
-```text
-node "<hooks>/workflow-disposition.js" start --session-id "<session>"
-```
+1. **Rule of 3** — the third matching failure pauses mutation until a zoom-out reflection is written;
+2. **user/host permission and dangerous-action approval** — authorization boundaries such as the action gate.
 
-The controller prepares the existing Fable consumer's run at the **bound** state
-root, even when tool execution has moved to a linked worktree. The run records
-both `workflowId` and `sessionId`; matching only strategy or creation time is
-insufficient. `start` creates contracts, not agents. Fable retains ownership of
-worker dispatch, dependency/write-set scheduling, and synthesis.
-
-## Isolation boundary
-
-Before Tier 3 or Fable source/artifact mutation, the gate verifies a registered
-linked Git worktree with the same common Git directory as the bound repository.
-It checks the tool's execution directory and actual Edit/Write/apply_patch paths,
-including move destinations, relative traversal, and symlink/junction resolution.
-Unknown direct targets, Git metadata, and nested repositories are rejected.
-Read-only discovery and a literal `git worktree add` transition remain available
-before entry. Prefer an already-ignored path or sibling path for setup; never
-edit the primary tree's ignore file just to establish mandatory isolation.
-
-Shell recognition is conservative: redirects, substitutions, chained commands,
-and side-effect options are not accepted as read-only. Mutation-capable shell
-execution requires an isolated working-directory field, with explicit outside
-paths and directory changes rejected. **This is not a filesystem sandbox**:
-arbitrary scripts, aliases/configuration, indirect variable paths, and races can
-have effects a hook cannot infer. OS/host sandboxing is needed to contain them.
-Agent-writable state is also not tamper-proof. These mechanisms prevent tested
-bypasses; they do not establish durable containment against a malicious agent.
-
-## Mutation probes
-
-Shell-effect accounting is keyed per tool call, not per command text. The gate
-registers a pending probe per shell tool-use identity (`workflow-isolation.js`),
-`state-persist.js` settles probes in a single ordered handler, and
-`workflow-mutation-denied.js` discards the probe when that shell execution is
-denied — a denial is never recorded as an observed mutation. Staging-insensitive
-fingerprinting keeps the comparison on visible content, so metadata-only Git
-operations do not register as workspace effects. These lifecycle semantics are
-covered by deterministic workflow mechanism tests (`ci/mechanism-2ah-*`); live
-host loading and behavioral improvement still require separately retained host
-traces and paired evaluations.
-
-## Escape, replan, and completion
-
-Escape names one stage in the correlated run and records the uncovered scope,
-evidence, and `workflow-uncovered-scope` or `host-capability-unavailable` reason:
+## Runtime flow
 
 ```text
-node "<hooks>/workflow-disposition.js" escape --session-id "<session>" --stage-id "<stage>" --reason-code workflow-uncovered-scope --scope "<uncovered scope>" --evidence "<evidence>"
-node "<hooks>/workflow-disposition.js" block --session-id "<session>" --evidence "<blocker>"
+route
+  -> selected workflow guidance
+  -> execute freely
+  -> observe edits / verification / stage evidence
+  -> emit reminders when evidence is weak
+  -> complete or continue
+
+same failure signature x3
+  -> zoom-out reflection required
+  -> reflection accepted
+  -> normal execution resumes
 ```
 
-An escape never resolves the whole run, waives isolation, or removes independent
-verification. Covered stages remain mandatory. Unavailable required verification
-means blocked. The controller permits the initial run plus the plan's
-`maxRevisionRounds` replans; exhaustion stays blocked. Previous run evidence is
-retained, but cannot satisfy a replacement run.
-
-`contract-test.js` records exact check commands, observed worker/session identity,
-numeric exit code, and run/plan/stage evidence. A failed check can recover on a
-later observed pass. A dependent check cannot pass before its prerequisites.
-Stop enumerates the manifest's expected stages, so deleting a contract does not
-make the run complete. A `pass` label without matching exit-zero evidence fails.
-The independent verifier must have a distinct observed identity and evidence
-after the latest mutation/check. This proves attribution, not reasoning quality.
-
-Unresolved Stop exits 2. If the host marks a Stop retry, the contract becomes
-`blocked` with diagnostics instead of looping indefinitely or recording success.
-Direct/iterative routes use observed edit/verification milestones; iteration
-counting and semantic check quality remain executor obligations, not proven by
-these gates. Broad verification-command recognition is a heuristic.
-
-## Host evidence
-
-Claude's manifest carries the shell/direct-mutation and Stop hooks. The local
-OpenAI package carries the same runtime for its declared `Bash|apply_patch`
-surface. Package tests exercise both layouts. Missing worker/exit metadata keeps
-Fable completion unresolved; it must be reported as degraded/blocked, not passed.
-Manual CLI routing without a session cannot persist lifecycle state.
-
-OpenCode and instruction-only/public Skills-only surfaces do not gain these
-runtime gates from this change. An absent/disabled hook or deleted state cannot
-be detected as an active contract by that same hook. No host compatibility status
-is upgraded: see [platform capabilities](platform-capabilities.md). Live hook
-loading, enforced host transitions, and behavioral improvement need separately
-retained host traces and paired evaluations.
+There is no `budget-exhausted -> blocked -> reset-budget` lifecycle.
+
+## Numeric guidance
+
+Router plans may still expose values such as:
+
+- `maxIterations`
+- `maxRevisionRounds`
+- `maxReplans`
+- `maxWorkers`
+
+These are **advisory defaults**, useful for prompts, diagnostics, or planning. Runtime hooks do not maintain authoritative counters, reserve mutation capacity, or reject the Nth event.
+
+A long loop should produce a message such as:
+
+> Iterative work is getting long; verify assumptions or consider re-planning.
+
+It should not create a lock.
+
+## Mutation observation
+
+The previous mutation-probe subsystem and `.mutation-probes.lock` were removed by #190. Shell classification is now best-effort evidence for reminders. A false positive/negative must not deadlock work.
+
+Direct edits can still update `lastMutationAt`. Shell outcomes can update handoff evidence heuristically. Missing or ambiguous evidence degrades reminder quality, not execution availability.
+
+## Completion
+
+`workflow-stop-gate.js` and `stop-gate.js` are reminder surfaces. When verification or Fable stage evidence is incomplete they report the missing evidence and return success to the host.
+
+A workflow may retain `blocked` as a descriptive status recorded by the controller or legacy state, but workflow hooks do not use that value as a persistent execution lock.
+
+## Fable and worktrees
+
+Fable stage graphs, dependencies, write sets, and objective checks remain useful planning/evidence structures. `maxWorkers` no longer chunks ready stages as a hard concurrency cap.
+
+For major work, a linked worktree remains strongly recommended. Missing isolation is surfaced prominently, but Harness-owned cognitive workflow hooks do not turn it into a self-deadlocking runtime state.
+
+## Legacy state
+
+Existing sessions may contain `budget.state = "budget-exhausted"`, old counters, or mutation-probe files from earlier versions. Current runtime code treats the budget API as advisory compatibility only and creates no new mutation-probe state.
+
+Starting a fresh session remains the cleanest way to discard old evidence, but it is no longer required to recover from numeric budget exhaustion.
+
+## Testing contract
+
+Regression tests should prove:
+
+- reminders fire when relevant;
+- commands/Stop remain available;
+- no mutation-probe lock or reservation state is created;
+- `exec_command` verification can update `lastVerifyAt`;
+- Rule of 3 trips exactly at three matching failures;
+- a valid reflection resets the cycle;
+- a later three-failure cycle requests another reflection rather than a permanent hard lock;
+- permission/dangerous-action boundaries remain separate and intact.

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 the Harness kernel: classify Tier 1/2/3, establish mandatory invariants, then let the agent choose tactics and domain skills. Use for software triage, routing, and re-routing; not general Q&A or non-software writing."
+description: "Route software/project work through the Harness kernel: classify Tier 1/2/3, surface planning guidance and applicable skills, then let the agent choose tactics. Use for software triage, routing, and 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 the Harness kernel: classify Tier 1/2/3, establish mandatory invariants, then let the agent choose tactics and domain skills. Use for software triage, routing, and re-routing; not general Q&A or non-software writing."
+description: "Route software/project work through the Harness kernel: classify Tier 1/2/3, surface planning guidance and applicable skills, then let the agent choose tactics. Use for software triage, routing, and 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 the Harness kernel: classify Tier 1/2/3, establish mandatory invariants, then let the agent choose tactics and domain skills. Use for software triage, routing, and re-routing; not general Q&A or non-software writing."
+description: "Route software/project work through the Harness kernel: classify Tier 1/2/3, surface planning guidance and applicable skills, then let the agent choose tactics. Use for software triage, routing, and re-routing; not general Q&A or non-software writing."
 tags:
   - positive-trigger
   - tier-3

package/evals/using-git-worktrees/tasks/positive-trigger.yaml

@@ -1,6 +1,6 @@
 id: positive-using-git-worktrees-001
 name: On-scope prompt triggers using-git-worktrees
-description: "Use when starting feature work needing isolation or before implementation plans - ensures an isolated workspace via native tools or git worktree fallback"
+description: "Use when starting feature work needing isolation or before implementation plans - recommends an isolated workspace via native tools or git worktree fallback"
 tags:
   - positive-trigger
 inputs:

package/fable-mode/SKILL.md

@@ -4,7 +4,7 @@ description: "Stage large, multi-source or multi-session tasks through a written
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.13.0
+  version: 0.16.1
 ---
 
 # Fable Mode (v3)

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

@@ -7,7 +7,7 @@ description: >-
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.13.0
+  version: 0.16.1
 ---
 
 # Execution Guardrails

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

@@ -4,7 +4,7 @@ description: "Run staged fable work on Haiku for bulk mechanical tasks with expl
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.13.0
+  version: 0.16.1
 ---
 
 # Fable Mode — Haiku

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

@@ -4,7 +4,7 @@ description: "Run staged fable orchestration on Opus for cross-stage synthesis,
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.13.0
+  version: 0.16.1
 ---
 
 # Fable Mode — Opus

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

@@ -4,7 +4,7 @@ description: "Run staged fable work on Sonnet for non-trivial implementation, re
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.13.0
+  version: 0.16.1
 ---
 
 # Fable Mode — Sonnet

package/fable-mode/scripts/workflow-plan-consumer.js

@@ -180,8 +180,9 @@ function dependencyBatches(stages, validateWrites, maxBatchSize = Infinity) {
   return batches;
 }
 
-function topologicalBatches(stages, maxWorkers) {
-  return dependencyBatches(stages, true, maxWorkers);
+function topologicalBatches(stages, _maxWorkers) {
+  // maxWorkers is an advisory planning hint, not a runtime concurrency lock (#190).
+  return dependencyBatches(stages, true);
 }
 
 function sequentialBatches(stages) {
@@ -197,7 +198,7 @@ function validateRouterPlan(routerContract) {
   if (plan.strategySelection !== 'selected') throw new Error(`workflow strategy is not selected: ${plan.strategySelection}`);
   if (!FABLE_STRATEGIES.has(plan.strategy)) throw new Error(`workflow strategy is not a Fable consumer topology: ${plan.strategy}`);
   if (plan.fallback && plan.fallback.disposition === 'blocked') {
-    throw new Error(`workflow plan is blocked: ${(plan.fallback.reasonCodes || []).join(', ') || 'unspecified reason'}`);
+    console.error(`[Fable Reminder] plan reports blocked/degraded capability: ${(plan.fallback.reasonCodes || []).join(', ') || 'unspecified reason'}`);
   }
   if (plan.strategy === 'fable-parallel' && (!plan.parallelism || plan.parallelism.allowed !== true)) {
     throw new Error('fable-parallel requires workflowPlan.parallelism.allowed=true');

package/harness-everything/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: harness-everything
-description: "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. Use for software triage, routing, and re-routing; not general Q&A or non-software writing."
+description: "Route software/project work through the Harness kernel: classify Tier 1/2/3, surface planning guidance and applicable skills, then let the agent choose tactics. Use for software triage, routing, and re-routing; not general Q&A or non-software writing."
 license: Apache-2.0
 metadata:
   author: Miya Daniel
-  version: 0.13.0
+  version: 0.16.1
 ---
 
 # Harness Everything
@@ -19,20 +19,20 @@ Kernel routing entry.
 - General Q&A or non-software writing.
 
 ## Invariants
-1. **Route before execution** — establish scope/tier and the smallest applicable workflow.
-2. **Verify before claim** — require objective evidence.
-3. **Re-plan on repetition** — after 3 same-signature failures, use `zoom-out`.
+1. **Route before execution** — establish scope/tier and useful workflow guidance.
+2. **Verify before claim** — seek objective evidence before saying work is done.
+3. **Zoom out on repetition** — after 3 same-signature failures, use `zoom-out`.
 4. **Evaluate before omission** — read each suggested skill's `SKILL.md` before deciding applicability.
-5. **Resolve selected workflow** — model confidence is not an escape condition.
+5. **Keep agency** — workflow state and numeric limits guide; they do not hard-stop execution.
 
 ## Workflow
 1. Reuse kernel output, or run `node "<this-skill-dir>/scripts/kernel-router.js" "<prompt summary>"`.
 2. Surface the **Harness Routing Checkpoint**.
-3. Read each suggested `SKILL.md`; evaluate `USE FOR`, `DO NOT USE FOR`, workflow/basic flow, and hard rules. "Simple", "routine", names, or summaries alone cannot justify omission.
-4. Execute the selected workflow topology to resolution. Suggested skills are conditional on applicability; the selected topology is not advisory.
-5. If the workflow genuinely cannot represent part of the task, use the explicit escape with uncovered scope + evidence. Covered obligations remain mandatory.
-6. Complete only after applicable workflow obligations and objective verification resolve.
+3. Read each suggested `SKILL.md`; evaluate `USE FOR`, `DO NOT USE FOR`, workflow/basic flow, and hard rules.
+4. Use the selected topology as planning guidance. Choose, combine, reorder, or skip steps when evidence supports doing so.
+5. Prefer worktree isolation for broad/Tier-3 mutation and objective verification before completion.
+6. If guidance is not useful, explain the reason briefly and continue; no Harness reset is required.
 
-**Rule:** mandatory applicable workflow; flexible reasoning/implementation inside it; evidence-backed escape only for uncovered scope.
+**Rule:** guidance may become louder when evidence is weak, but only Rule-of-3 reflection and explicit user/host permission boundaries may block.
 
 Deep dive: <this-skill-dir>/references/triage-and-tiers.md