cool-workflow 0.1.82 → 0.1.83

package/docs/evidence-adoption-reasoning-chain.7.md

@@ -1,26 +1,26 @@
 # Evidence Adoption Reasoning Chain
 
 CW v0.1.26 adds the Evidence Adoption Reasoning Chain. Earlier releases can
-already answer *what* was adopted: `multi-agent evidence <run-id>` reports each
+already say *what* was adopted: `multi-agent evidence <run-id>` reports each
 evidence item as `adopted`, `rejected`, `pending`, `superseded`, `conflicting`,
 or `missing`, and traces the path worker result -> blackboard -> fanin ->
-candidate score -> selection -> verifier-gated commit. This release answers
-*why* each adoption happened, as a first-class, inspectable reasoning chain.
+candidate score -> selection -> verifier-gated commit. This release says
+*why* each adoption took place, as a first-class reasoning chain you can look into.
 
-The design keeps the base-system observability philosophy:
+The design keeps the base-system observability way of thinking:
 
-- raw state is the source of truth
-- the reasoning chain is a derived userland view, never a replacement for source
-  records and never authoritative over them
-- mechanism is separate from policy: the chain captures, stores, and renders the
+- raw state is the true source
+- the reasoning chain is a derived userland view; it never takes the place of source
+  records and never has authority over them
+- mechanism is kept apart from policy: the chain takes in, stores, and renders the
   recorded "why"; what counts as a *sufficient* reason stays with the verifier
   and role policy
-- fail closed, never infer: a "why" that cannot be traced to a real record
-  renders as `unexplained`, never a fabricated rationale, and an unexplained
-  adoption is never silently treated as explained
+- fail closed, never make a guess: a "why" that cannot be traced to a real record
+  renders as `unexplained`, never a made-up rationale, and an unexplained
+  adoption is never quietly handled as explained
 - plain files, stable JSON, deterministic output
-- backward compatible; pre-v0.1.26 run state loads and renders with derived,
-  empty-where-absent reasoning records
+- backward compatible; pre-v0.1.26 run state loads and renders with derived
+  reasoning records that are empty where absent
 
 ## What the chain records
 
@@ -30,22 +30,22 @@ makes the following traceable and machine-readable, per gate:
 - DECISION - what was adopted/rejected and at which gate (`fanin`,
   `candidate-score`, `selection`, `verifier`, or `commit`).
 - BASIS - the concrete evidence refs, provenance source, parent evidence ids,
-  and audit event ids that grounded the decision. These link to existing
-  `EvidenceProvenance` and trust-audit records; they are not duplicated.
+  and audit event ids that the decision is grounded on. These link to existing
+  `EvidenceProvenance` and trust-audit records; they are not copied.
 - AUTHORITY - which role / membership / worker / scorer / verifier made the call,
-  and the role `policyRef` under which it was permitted. Links to existing
+  and the role `policyRef` under which it was let through. Links to existing
   trust / policy / audit records.
-- RATIONALE - the explicit recorded reason. The chain reuses existing rationale
+- RATIONALE - the clearly recorded reason. The chain reuses existing rationale
   fields: selection `reason` and `AcceptanceRationale`, candidate score `notes`,
   verifier commit-gate result, commit `reason`, `CoordinatorDecision.reason`, and
-  judge-rationale audit metadata. No new rationale source of truth is created.
-- COUNTERFACTUAL - the rejected/losing alternatives (rejected candidates, failed
+  judge-rationale audit metadata. No new rationale source of truth is made.
+- COUNTERFACTUAL - the rejected/losing other options (rejected candidates, failed
   scores, rejected or superseded coordinator decisions) and the recorded reason
-  each lost, with a normalized score delta when computable, so an adoption is
-  understood relative to its alternatives.
+  each one lost, with a normalized score delta when it can be computed, so an adoption is
+  understood next to its other options.
 - INTEGRITY - a `sourceFingerprint` and `valid|stale|absent` freshness so a
-  reader knows the explanation still matches the underlying records, plus the
-  explicit `unexplained` state when a rationale is absent.
+  reader knows the reason still matches the records under it, plus the
+  clear `unexplained` state when a rationale is absent.
 
 ## Derived record model
 
@@ -61,14 +61,14 @@ rationale types by reference:
 - `EvidenceReasoningReport` - the run-level report: `freshness`,
   `sourceFingerprint`, `totals`, `chains`, and a `nextAction`.
 
-Status values mirror the existing evidence vocabulary and add the fail-closed
+Status values follow the existing evidence words and add the fail-closed
 `unexplained` state. A chain is `explained` only when *every* decision-bearing
 step is explained; if any adopting step has no traceable rationale the chain
 rolls up to `unexplained`.
 
 ## Durable storage
 
-`multi-agent reasoning <run-id> --refresh` materializes a durable, versioned,
+`multi-agent reasoning <run-id> --refresh` makes a durable, versioned,
 provenance-backed index under `.cw/runs/<run-id>/reasoning/`:
 
 - `index.json` - the `EvidenceReasoningIndex` (schema version, run id,
@@ -78,27 +78,27 @@ provenance-backed index under `.cw/runs/<run-id>/reasoning/`:
 - `report.json` - the rendered report at refresh time.
 
 Raw results, candidates, scores, selections, commits, blackboard records, and
-audit events are never deleted or overwritten. The reasoning view is derived and
-re-derivable; the index only persists a snapshot for freshness comparison.
+audit events are never deleted or written over. The reasoning view is derived and
+can be derived again; the index only keeps a snapshot for freshness comparison.
 
 ## Freshness
 
-`multi-agent reasoning <run-id>` re-derives the chain from current source state
-and compares its `sourceFingerprint` against the persisted index:
+`multi-agent reasoning <run-id>` derives the chain again from current source state
+and compares its `sourceFingerprint` against the kept index:
 
 - `absent` - no index has been refreshed yet.
-- `valid` - the persisted fingerprint matches current source state.
-- `stale` - source records changed since the last refresh; re-run with
+- `valid` - the kept fingerprint matches current source state.
+- `stale` - source records changed since the last refresh; run again with
   `--refresh`.
 
 This follows the v0.1.25 state-explosion summary discipline exactly. Freshness
-is a visible state, never an inferred guess.
+is a state you can see, never a guess.
 
 ## Commands
 
 `multi-agent reasoning <run-id>` (MCP: `cw_evidence_reasoning`) renders the
 report. Add `--evidence <id>` to explain a single adoption, `--refresh` to
-materialize the durable index first, and `--json` / `--format json` for the full
+make the durable index first, and `--json` / `--format json` for the full
 machine-readable report.
 
 `multi-agent reasoning <run-id> --refresh` with no `--evidence` returns the
@@ -109,17 +109,17 @@ additive `rationaleStatus` field (`explained`, `unexplained`, or
 `not-applicable`), so the existing evidence surface answers both *what* and
 whether the *why* is recorded.
 
-The console report adds a single new panel, `Adoption Rationale`, alongside the
+The console report adds one new panel, `Adoption Rationale`, next to the
 existing operator panels. It is the only panel added by this release.
 
 ## Composition with graph views and compaction
 
-The reasoning chain composes with the existing graph views, especially
+The reasoning chain works together with the existing graph views, above all
 `multi-agent graph <run-id> --view evidence`. A reasoning step is on the critical
 path: every decision-gate node backing an adopted chain (candidate, score,
-selection, commit, and fanin nodes) is protected from state-explosion
-compaction and is never collapsed into a synthetic summary node. In particular
-score nodes, which are otherwise collapsible, stay expanded when they carry a
+selection, commit, and fanin nodes) is kept safe from state-explosion
+compaction and is never folded into a synthetic summary node. In particular
+score nodes, which can be folded otherwise, stay open when they carry a
 reasoning step.
 
 ## Eval / replay regression gates
@@ -132,7 +132,7 @@ the `Evidence Adoption Reasoning Chain` section of the replay report:
 - `reasoning_chain_parity` - every chain's gates, decisions, rationale statuses,
   and counterfactual counts match the baseline.
 - `reasoning_unexplained_parity` - the set of `unexplained` chains is unchanged,
-  so a regression that hides or fabricates a rationale fails the gate.
+  so a regression that hides or makes up a rationale fails the gate.
 
 These sections are optional on pre-v0.1.26 snapshots so older fixtures stay
 loadable.
@@ -151,39 +151,39 @@ worker result / blackboard / coordinator decision
 ```
 
 No daemon, no hidden dashboard, no LLM call. The chain is derived from recorded
-state by `src/evidence-reasoning.ts` and rendered on demand.
+state by `src/evidence-reasoning.ts` and rendered when asked for.
 ## CLI ↔ MCP Parity (v0.1.27)
 
-Every command and tool referenced above is declared in the v0.1.27 capability
-registry (`src/capability-registry.ts`) and validated by `npm run parity:check`,
+Every command and tool named above is declared in the v0.1.27 capability
+registry (`src/capability-registry.ts`) and checked by `npm run parity:check`,
 so `cw <cmd> --json` and the matching `cw_<tool>` result render one data source.
 See [cli-mcp-parity.7.md](cli-mcp-parity.7.md).
 
 ## Run Registry / Control Plane (v0.1.28)
 
-The runs described here are indexed, searchable, resumable, archivable, and
+The runs talked about here are indexed, searchable, resumable, archivable, and
 rerunnable across repos by the v0.1.28 Run Registry / Control Plane, which derives
 a fingerprinted, fail-closed index over the same per-run `.cw/runs/<id>/state.json`
-source of truth. See [run-registry-control-plane.7.md](run-registry-control-plane.7.md).
+true source. See [run-registry-control-plane.7.md](run-registry-control-plane.7.md).
 
 ## Execution Backends (v0.1.29)
 
 v0.1.29 lifts execution into a pluggable driver layer: one narrow `ExecutionBackend`
 contract with interchangeable `node`/`bun`/`shell`/`container`/`remote`/`ci`
-drivers, selected by `--backend` (parallel to `--sandbox`) and inspected via
+drivers, picked by `--backend` (parallel to `--sandbox`) and looked at through
 `backend list|show|probe`. The result/evidence envelope is schema-identical across
 backends; the backend id + sandbox attestation are recorded as provenance, so this
-surface is unchanged regardless of which backend executed a run. See
+surface is unchanged no matter which backend ran a run. See
 [execution-backends.7.md](execution-backends.7.md).
 ## Web / Desktop Workbench (v0.1.30)
 
 v0.1.30 adds the Web / Desktop Workbench: a read-only, localhost-only human
 console that renders this surface (and the other four operator panels — run
 graph, blackboard, worker logs, candidate compare, audit timeline) for any run,
-reading the SAME capability `--json` payloads. It is a THIRD FRONT DOOR alongside
+reading the SAME capability `--json` payloads. It is a THIRD FRONT DOOR next to
 the CLI and MCP that holds no authoritative state and forks no schema: each panel
 equals its `cw <cmd> --json` payload byte-for-byte (parity-gated), and refresh
-re-derives everything from disk. See
+derives everything again from disk. See
 [web-desktop-workbench.7.md](web-desktop-workbench.7.md).
 
 ## Observability + Cost Accounting (v0.1.31)
@@ -203,20 +203,20 @@ verbs are parity-gated and render read-only in the v0.1.30 Workbench. See
 v0.1.32 adds Team Collaboration: a host-attested actor and append-only
 approvals/rejections/comments/handoffs provenance-linked to a durable target,
 plus a review gate that STACKS ON the verifier gate — required approvals from
-authorized roles, enforced inside `resolveCommitGate` AFTER the verifier checks
-and never instead of them, failing closed on quorum/authority/self-approval and
+authorized roles, made to hold inside `resolveCommitGate` AFTER the verifier checks
+and never in place of them, failing closed on quorum/authority/self-approval and
 recording who approved the very artifact that shipped. Policy (required approvals,
-authorized roles, self-approval) is data, default off (pre-v0.1.32 behavior
+authorized roles, self-approval) is data, off by default (pre-v0.1.32 behavior
 unchanged). The verbs are parity-gated and render read-only in the v0.1.30
 Workbench. See [Team Collaboration](team-collaboration.7.md).
 
 ## Release Tooling (v0.1.33)
 
-the per-tag mechanical surfaces (version bump across 17 surfaces, feature scaffold, and the forward-reference docs) become deterministic scripts, with a de-duplicated release gate. See release-tooling(7).
+the per-tag mechanical surfaces (version bump across 17 surfaces, feature scaffold, and the forward-reference docs) become deterministic scripts, with a release gate that has no repeats. See release-tooling(7).
 
 ## Real Execution Backend Integrations (v0.1.34)
 
-container/remote/ci backends really execute (docker/podman run, remote/CI POST-and-poll) under the sandbox contract, with byte-stable evidence vs node and fail-closed refusal when a runtime/endpoint is unavailable. See real-execution-backends(7).
+container/remote/ci backends truly execute (docker/podman run, remote/CI POST-and-poll) under the sandbox contract, with byte-stable evidence vs node and fail-closed refusal when a runtime/endpoint is not there to use. See real-execution-backends(7).
 
 ## Node Snapshot / Diff / Replay (v0.1.35)
 
@@ -248,15 +248,15 @@ evidence grounding + durable audit append + symlink-hardened containment + deter
 
 ## Robust Result Ingest (v0.1.42)
 
-capture findings/evidence from any reasonable agent shape (alt keys + prose), CW derives grounded evidence itself, warn on empty capture — closes the v0.1.41 live-drive 'accepted with 0 captured' failure
+capture findings/evidence from any agent shape that makes sense (alt keys + prose), CW derives grounded evidence itself, give a warning on empty capture — closes the v0.1.41 live-drive 'accepted with 0 captured' failure
 
 ## No-False-Green Gate & Launch Prep (v0.1.43)
 
-Hard gate blocking empty-capture verifier-gated commits, plus quickstart and launch-prep docs.
+Hard gate stopping empty-capture verifier-gated commits, plus quickstart and launch-prep docs.
 
 ## Release-Gate Determinism & Agents Vendor (v0.1.44)
 
-Release-readiness checks now validate the committed blob (`git show HEAD:<path>`) instead of the mutable working tree — eliminating false-red/false-green from concurrent working-tree writes (iCloud/Spotlight/editor). Adds the `agents` vendor manifest target: a generated `.agents/plugins/cool-workflow/` adapter giving any non-Claude AI agent one common interface to CW.
+Release-readiness checks now check the committed blob (`git show HEAD:<path>`) instead of the changeable working tree — taking away false-red/false-green from concurrent working-tree writes (iCloud/Spotlight/editor). Adds the `agents` vendor manifest target: a generated `.agents/plugins/cool-workflow/` adapter giving any non-Claude AI agent one common interface to CW.
 
 ## P1-P2 Fixes & CI Content Surfaces (v0.1.49)
 
@@ -273,7 +273,11 @@ Migration DAG with reversible edges (v0.1.45), capability auto-discovery (v0.1.4
 
 ## Fast Architecture Review (v0.1.80)
 
-Adds the opt-in fast architecture-review lane: scoped JSONL source contexts, diff-aware exports, reusable Map and Assess results, measurable wrapper metrics, actionable background full-review handoff, and userland model policy flags for routing fast/strong workers without changing the full review contract.
+Adds the opt-in fast architecture-review lane: scoped JSONL source contexts, diff-aware exports, reusable Map and Assess results, wrapper metrics you can measure, a background full-review handoff you can act on, and userland model policy flags for routing fast/strong workers without changing the full review contract.
 
-_No changes to the Evidence Adoption Reasoning Chain surface in v0.1.81. The v0.1.81 trust-audit `computeEventHash` fix hardens the underlying audit records this chain links to by reference, but the derived reasoning view, its commands, and its eval gates are unchanged._
+_No changes to the Evidence Adoption Reasoning Chain surface in v0.1.81. The v0.1.81 trust-audit `computeEventHash` fix makes the audit records under it that this chain links to by reference stronger, but the derived reasoning view, its commands, and its eval gates are unchanged._
 _No changes in v0.1.82._
+
+## Hardening and Onboarding (v0.1.83)
+
+Loaders fail closed on corrupt state; store writes are made safe under more than one writer; a new cw doctor checks your setup; help lists every command; and the docs are put into Basic English.

package/docs/execution-backends.7.md

@@ -17,25 +17,25 @@ node dist/cli.js worker manifest <run-id> <worker-id>
 ## DESCRIPTION
 
 An execution backend is a CW driver: a thin adapter that runs a dispatched
-task/worker somewhere, under the requested sandbox profile, and records a
-canonical result envelope plus a sandbox attestation. v0.1.29 lifts execution
-out of the kernel into this driver layer.
+task/worker somewhere, under the requested sandbox profile, and keeps a record of
+a canonical result envelope plus a sandbox attestation. v0.1.29 takes execution
+out of the kernel and puts it into this driver layer.
 
 The model is a BSD VFS / device-driver layer. There is ONE narrow
-`ExecutionBackend` interface (the mechanism) and many interchangeable drivers
+`ExecutionBackend` interface (the mechanism) and many drivers you can swap in and out
 (`node`, `bun`, `shell`, `container`, `remote`, `ci`). The kernel —
 orchestrator, dispatch, and pipeline-runner — never learns which backend ran a
-task. WHAT to run and which evidence to record is kernel policy; HOW and WHERE
-it runs is the driver's concern.
+task. WHAT to run and which evidence to keep is kernel policy; HOW and WHERE
+it runs is the driver's business.
 
 ```text
 selected backend -> sandbox attestation -> execution/delegation -> canonical envelope
 ```
 
-The result envelope, evidence refs, and provenance a task produces are
+The result envelope, evidence refs, and provenance a task makes are
 schema-identical no matter which backend ran it. The backend id and its sandbox
-attestation are recorded AS provenance, so eval/replay, the verifier gates, and
-the v0.1.28 run registry do not care which backend executed a run.
+attestation are kept AS provenance, so eval/replay, the verifier gates, and
+the v0.1.28 run registry do not care which backend ran a run.
 
 ## THE CONTRACT
 
@@ -49,69 +49,69 @@ run(request) execute (or delegate) under a sandbox profile and return a
              canonical ExecutionResultEnvelope { status, result, evidence, provenance }
 ```
 
-`run` takes a dispatch/worker manifest plus a resolved sandbox profile and
-returns `{ result, evidence }` (byte-stable across backends) and `provenance`
-(backend id + `SandboxAttestation` + optional delegation handle).
+`run` takes a dispatch/worker manifest plus a fixed sandbox profile and
+gives back `{ result, evidence }` (byte-stable across backends) and `provenance`
+(backend id + `SandboxAttestation` + an optional delegation handle).
 
 ## THE SANDBOX PROFILE IS THE CONTRACT
 
 Every backend MUST honor the five sandbox-profile dimensions: read, write,
-command, network, env. For each dimension a driver declares one of:
+command, network, env. For each dimension a driver says it does one of:
 
 `enforce`
-: the driver actively restricts the dimension at execution time.
+: the driver itself limits the dimension at execution time.
 
 `attest`
-: the driver records a verifiable claim but relies on the host/runner to
-  enforce it (mirrors the existing `sandbox.hostRequired` split).
+: the driver keeps a claim you can check, but it is up to the host/runner to
+  enforce it (this is the same split as the existing `sandbox.hostRequired`).
 
 `unsupported`
-: the driver can neither enforce nor attest it.
+: the driver can not enforce it or attest it.
 
-A profile requires a dimension when it restricts it (`command` when
+A profile needs a dimension when it limits it (`command` when
 `execute.mode != any`, `network` when `network.mode != any`, `env` when
-`env.inherit` is false; read/write are always bounded). If a required dimension
-is `unsupported`, or the backend is not ready, or the command is denied by the
-profile, the backend FAILS CLOSED: `run` returns `status: "refused"` with an
-attestation whose `status` is `refused`. It never silently downgrades to an
+`env.inherit` is false; read/write are always bounded). If a needed dimension
+is `unsupported`, or the backend is not ready, or the profile says no to the
+command, the backend FAILS CLOSED: `run` returns `status: "refused"` with an
+attestation whose `status` is `refused`. It never quietly drops down to an
 unsandboxed execution.
 
 ## DRIVERS
 
 `node` (default)
-: Reproduces pre-v0.1.29 behavior exactly. The host runs the worker in-process
+: Does pre-v0.1.29 behavior exactly. The host runs the worker in-process
   under CW's worker-output acceptance (a delegate-host execution). When it
-  executes a command it enforces command + env via the Node child process and
+  runs a command it enforces command + env through the Node child process and
   attests read/write/network to the host.
 
 `bun`
-: Node-compatible by default, Bun-friendly. Executes via the Node-compatible
-  runtime so evidence is byte-stable with `node`, and attests Bun availability
+: Node-compatible by default, Bun-friendly. Runs through the Node-compatible
+  runtime so evidence is byte-stable with `node`, and attests that Bun is there
   in provenance. Enforces command + env; attests read/write/network.
 
 `shell`
-: Runs a command/worker via the system shell (`/bin/sh -c`) under the sandbox
+: Runs a command/worker through the system shell (`/bin/sh -c`) under the sandbox
   contract. Enforces command + env; attests read/write/network.
 
 `container`
-: Delegates to a container runtime (docker/podman) and records the
+: Delegates to a container runtime (docker/podman) and keeps the
   `image@digest` handle + attestation + result. A container can enforce all
-  five dimensions. Fails closed when no image is supplied.
+  five dimensions. Fails closed when you give no image.
 
 `remote`
-: Delegates to a remote runner and records the endpoint + job handle +
-  attestation + result. Fails closed when no endpoint is configured
+: Delegates to a remote runner and keeps the endpoint + job handle +
+  attestation + result. Fails closed when no endpoint is set
   (`CW_REMOTE_ENDPOINT` or `--endpoint`).
 
 `ci`
-: Delegates to a CI runner and records the job handle + attestation + result.
-  Fails closed when no CI job target is configured (`CW_CI_ENDPOINT` or
+: Delegates to a CI runner and keeps the job handle + attestation + result.
+  Fails closed when no CI job target is set (`CW_CI_ENDPOINT` or
   `--job`).
 
 CW DELEGATES; IT DOES NOT BECOME THE EXECUTOR. The local drivers run a thin
-child process to capture verifiable evidence (exit code + an output digest). The
-container/remote/ci drivers delegate and record a handle + attestation +
-result; they never reimplement a container runtime or a CI system.
+child process to take in evidence you can check (exit code + an output digest). The
+container/remote/ci drivers delegate and keep a handle + attestation +
+result; they never build a container runtime or a CI system over again.
 
 ## SELECTION
 
@@ -121,17 +121,17 @@ Backend selection parallels `--sandbox`:
 --backend <id>   (flag)   > CW_BACKEND   (env)   > node   (default)
 ```
 
-Selection is recorded in run state (dispatch manifest, worker scope, worker
-manifest, the RunDispatch) and surfaced in the v0.1.28 run registry as the
-record's `backends` field. A per-task `backendId` overrides the run default.
-`backend list|show|probe` and the `--backend` flag are declared once in
-`src/capability-registry.ts`, so `cw <cmd> --json` and `cw_<cmd>` render one
-data source and pass the v0.1.27 parity gate.
+Selection is kept in run state (dispatch manifest, worker scope, worker
+manifest, the RunDispatch) and shown in the v0.1.28 run registry as the
+record's `backends` field. A per-task `backendId` takes the place of the run default.
+`backend list|show|probe` and the `--backend` flag are set out once in
+`src/capability-registry.ts`, so `cw <cmd> --json` and `cw_<cmd>` use one
+data source and get past the v0.1.27 parity gate.
 
 ## EVIDENCE PARITY
 
-The canonical evidence a local driver records for a command run is
-backend-independent:
+The canonical evidence a local driver keeps for a command run does not depend on the
+backend:
 
 ```text
 command:<command + args>
@@ -140,10 +140,10 @@ stdoutSha256:sha256:<hex>
 ```
 
 Running CW's own self-verify (`node dist/cli.js list`) through `node`, `shell`,
-and `bun` yields byte-identical `result` and `evidence`; only
-`provenance.backendId` (and the attestation detail) differs. The
+and `bun` gives byte-identical `result` and `evidence`; only
+`provenance.backendId` (and the attestation detail) is not the same. The
 `test/execution-backends-smoke.js` gate proves this, proves the fail-closed
-refusals, proves the recorded provenance and delegation handles, and proves the
+refusals, proves the kept provenance and delegation handles, and proves the
 verifier/registry stay backend-agnostic.
 
 ## ATTESTATION SHAPE
@@ -164,7 +164,7 @@ verifier/registry stay backend-agnostic.
 }
 ```
 
-A delegating driver additionally records `handle` (e.g.
+A delegating driver also keeps `handle` (for example
 `{ "kind": "container", "ref": "img@sha256:..." }`).
 
 ## FILES
@@ -179,23 +179,23 @@ A delegating driver additionally records `handle` (e.g.
 
 ## FAILURE MODES
 
-Unknown backends fail closed with `backend-not-found` (CLI/dispatch/`CW_BACKEND`).
+Backends it does not know fail closed with `backend-not-found` (CLI/dispatch/`CW_BACKEND`).
 
 `run` returns `status: "refused"` with `attestation.status: "refused"` when:
 
-- the command is denied by the sandbox profile (`sandbox-command-denied`),
-- a required sandbox dimension is `unsupported` (`sandbox-unenforceable`),
+- the sandbox profile says no to the command (`sandbox-command-denied`),
+- a needed sandbox dimension is `unsupported` (`sandbox-unenforceable`),
 - a local backend is not ready (`backend-not-ready`),
 - a delegating backend has no delegation target (`delegation-target-missing`).
 
-CW never silently downgrades a requested backend, and never runs a task
-unsandboxed when the requested profile cannot be honored.
+CW never quietly drops down a backend you asked for, and never runs a task
+unsandboxed when it can not honor the profile you asked for.
 
 ## COMPATIBILITY
 
-Execution Backends are introduced in CW v0.1.29. The default (`node`) backend
-reproduces pre-v0.1.29 behavior exactly; runs with no backend selected keep
-working and old run state loads unchanged (the backend fields are additive and
+Execution Backends come in with CW v0.1.29. The default (`node`) backend
+does pre-v0.1.29 behavior exactly; runs with no backend picked keep
+working and old run state loads unchanged (the backend fields are added on and
 optional). The `ResultEnvelope` schema (`summary`, `findings`, `evidence`) is
 unchanged — the backend id and attestation live in provenance and run state,
 never in the result envelope.
@@ -208,23 +208,23 @@ run-registry-control-plane(7), security-trust-hardening(7)
 ## Web / Desktop Workbench (v0.1.30)
 
 v0.1.30 adds the Web / Desktop Workbench: a read-only, localhost-only human
-console that renders this surface (and the other four operator panels — run
+console that shows this surface (and the other four operator panels — run
 graph, blackboard, worker logs, candidate compare, audit timeline) for any run,
-reading the SAME capability `--json` payloads. It is a THIRD FRONT DOOR alongside
-the CLI and MCP that holds no authoritative state and forks no schema: each panel
-equals its `cw <cmd> --json` payload byte-for-byte (parity-gated), and refresh
-re-derives everything from disk. See
+reading the SAME capability `--json` payloads. It is a THIRD FRONT DOOR next to
+the CLI and MCP that keeps no authoritative state and forks no schema: each panel
+is the same as its `cw <cmd> --json` payload byte-for-byte (parity-gated), and refresh
+works everything out from disk over again. See
 [web-desktop-workbench.7.md](web-desktop-workbench.7.md).
 
 ## Observability + Cost Accounting (v0.1.31)
 
 v0.1.31 adds Observability + Cost Accounting: `metrics show`/`metrics summary`
-derive durations, failure/verifier/acceptance rates (with sample counts and
+work out durations, failure/verifier/acceptance rates (with sample counts and
 fail-closed `n/a`), and host-attested token/cost from existing durable run state
-— no metrics database, no collector daemon, no hidden counter. Usage is additive
-and optional (absent ⇒ `unreported`, never 0); cost is `attested` (attested usage
-× a recorded pricing policy) or clearly `estimated`, with pricing as policy. Both
-verbs are parity-gated and render read-only in the v0.1.30 Workbench. See
+— no metrics database, no collector daemon, no hidden counter. Usage is added on
+and optional (when not there ⇒ `unreported`, never 0); cost is `attested` (attested usage
+× a kept pricing policy) or clearly `estimated`, with pricing as policy. Both
+verbs are parity-gated and show read-only in the v0.1.30 Workbench. See
 [observability-cost-accounting.7.md](observability-cost-accounting.7.md).
 
 
@@ -232,25 +232,25 @@ verbs are parity-gated and render read-only in the v0.1.30 Workbench. See
 
 v0.1.32 adds Team Collaboration: a host-attested actor and append-only
 approvals/rejections/comments/handoffs provenance-linked to a durable target,
-plus a review gate that STACKS ON the verifier gate — required approvals from
+plus a review gate that STACKS ON the verifier gate — needed approvals from
 authorized roles, enforced inside `resolveCommitGate` AFTER the verifier checks
-and never instead of them, failing closed on quorum/authority/self-approval and
-recording who approved the very artifact that shipped. Policy (required approvals,
+and never in place of them, failing closed on quorum/authority/self-approval and
+keeping a record of who approved the very artifact that went out. Policy (required approvals,
 authorized roles, self-approval) is data, default off (pre-v0.1.32 behavior
-unchanged). The verbs are parity-gated and render read-only in the v0.1.30
+unchanged). The verbs are parity-gated and show read-only in the v0.1.30
 Workbench. See [Team Collaboration](team-collaboration.7.md).
 
 ## Release Tooling (v0.1.33)
 
-the per-tag mechanical surfaces (version bump across 17 surfaces, feature scaffold, and the forward-reference docs) become deterministic scripts, with a de-duplicated release gate. See release-tooling(7).
+the per-tag mechanical surfaces (version bump across 17 surfaces, feature scaffold, and the forward-reference docs) become deterministic scripts, with a release gate that has no copies in it. See release-tooling(7).
 
 ## Real Execution Backend Integrations (v0.1.34)
 
-container/remote/ci backends really execute (docker/podman run, remote/CI POST-and-poll) under the sandbox contract, with byte-stable evidence vs node and fail-closed refusal when a runtime/endpoint is unavailable. See real-execution-backends(7).
+container/remote/ci backends truly run (docker/podman run, remote/CI POST-and-poll) under the sandbox contract, with byte-stable evidence vs node and fail-closed refusal when a runtime/endpoint is not there to use. See real-execution-backends(7).
 
 ## Node Snapshot / Diff / Replay (v0.1.35)
 
-per-node snapshot, structural diff, and isolated deterministic replay over StateNode, reusing the v0.1.23 eval harness; fail-closed on source drift (valid|stale|absent). See node-snapshot-diff-replay(7).
+per-node snapshot, structural diff, and isolated deterministic replay over StateNode, using the v0.1.23 eval harness over again; fail-closed on source drift (valid|stale|absent). See node-snapshot-diff-replay(7).
 
 ## Contract Migration Tooling (v0.1.36)
 
@@ -262,11 +262,11 @@ priority + concurrency limits + lease lifecycle + retry/backoff + fail-closed pa
 
 ## Agent Delegation Drive (v0.1.38)
 
-spawn an external agent process per worker, capture result.md + attestation, auto-drive plan->dispatch->fulfill->accept->commit
+spawn an outside agent process per worker, take in result.md + attestation, auto-drive plan->dispatch->fulfill->accept->commit
 
 ## Run Retention & Provable Reclamation (v0.1.39)
 
-tiered, append-only, cryptographically-verifiable run reclamation: seal the audit skeleton, free the reconstructable bulk, prove it
+tiered, append-only, cryptographically-verifiable run reclamation: seal the audit skeleton, free the bulk that can be built again, prove it
 
 ## Durable State & Locking (v0.1.40)
 
@@ -278,15 +278,15 @@ evidence grounding + durable audit append + symlink-hardened containment + deter
 
 ## Robust Result Ingest (v0.1.42)
 
-capture findings/evidence from any reasonable agent shape (alt keys + prose), CW derives grounded evidence itself, warn on empty capture — closes the v0.1.41 live-drive 'accepted with 0 captured' failure
+take in findings/evidence from any sensible agent shape (alt keys + prose), CW works out grounded evidence itself, give a warning on empty capture — closes the v0.1.41 live-drive 'accepted with 0 captured' failure
 
 ## No-False-Green Gate & Launch Prep (v0.1.43)
 
-Hard gate blocking empty-capture verifier-gated commits, plus quickstart and launch-prep docs.
+Hard gate stopping empty-capture verifier-gated commits, plus quickstart and launch-prep docs.
 
 ## Release-Gate Determinism & Agents Vendor (v0.1.44)
 
-Release-readiness checks now validate the committed blob (`git show HEAD:<path>`) instead of the mutable working tree — eliminating false-red/false-green from concurrent working-tree writes (iCloud/Spotlight/editor). Adds the `agents` vendor manifest target: a generated `.agents/plugins/cool-workflow/` adapter giving any non-Claude AI agent one common interface to CW.
+Release-readiness checks now check the committed blob (`git show HEAD:<path>`) in place of the mutable working tree — doing away with false-red/false-green from working-tree writes at the same time (iCloud/Spotlight/editor). Adds the `agents` vendor manifest target: a generated `.agents/plugins/cool-workflow/` adapter that gives any non-Claude AI agent one common interface to CW.
 
 ## P1-P2 Fixes & CI Content Surfaces (v0.1.49)
 
@@ -303,7 +303,11 @@ Migration DAG with reversible edges (v0.1.45), capability auto-discovery (v0.1.4
 
 ## Fast Architecture Review (v0.1.80)
 
-Adds the opt-in fast architecture-review lane: scoped JSONL source contexts, diff-aware exports, reusable Map and Assess results, measurable wrapper metrics, actionable background full-review handoff, and userland model policy flags for routing fast/strong workers without changing the full review contract.
+Adds the opt-in fast architecture-review lane: scoped JSONL source contexts, diff-aware exports, Map and Assess results you can use again, wrapper metrics you can measure, a background full-review handoff you can act on, and userland model policy flags for routing fast/strong workers without changing the full review contract.
 
 _No changes to the execution-backends surface in v0.1.81._
-_No behavioral change in v0.1.82 (the delegated child programs moved from inline `node -e` strings to `scripts/children/`; spawn argv and shell:false behavior are byte-identical)._
+_No behavioral change in v0.1.82 (the delegated child programs moved from inline `node -e` strings to `scripts/children/`; spawn argv and shell:false behavior are the same byte for byte)._
+
+## Hardening and Onboarding (v0.1.83)
+
+Loaders fail closed on corrupt state; store writes are made safe under more than one writer; a new cw doctor checks your setup; help lists every command; and the docs are put into Basic English.