cool-workflow 0.1.82 → 0.1.83

package/docs/operator-ux.7.md

@@ -1,9 +1,9 @@
 # Operator UX
 
-Cool Workflow v0.1.12 added a read-only Operator UX layer for understanding a
+Cool Workflow v0.1.12 added a read-only Operator UX layer to help you see a
 run from the console. It does not change workflow state, dispatch workers, score
-candidates, or commit snapshots. It reads `WorkflowRun` state and renders
-deterministic summaries for humans while preserving JSON for scripts and MCP.
+candidates, or commit snapshots. It reads `WorkflowRun` state and makes
+deterministic summaries for people, while it keeps JSON for scripts and MCP.
 
 ## Inspect A Run
 
@@ -13,30 +13,30 @@ Human status is the default:
 node scripts/cw.js status <run-id>
 ```
 
-The status view includes run id, workflow/app id and version, loop stage, active
+The status view gives you run id, workflow/app id and version, loop stage, active
 phase, blocked reasons, phase/task counts, workers, candidates, feedback,
 commits, multi-agent runtime health, Multi-Agent Operator UX counts, report
-path, and the next recommended command.
+path, and the next command it puts forward.
 
-Machine-readable status stays available:
+Machine-readable status is still there for you:
 
 ```bash
 node scripts/cw.js status <run-id> --json
 node scripts/cw.js status <run-id> --format json
 ```
 
-`CoolWorkflowRunner.status()` and MCP `cw_status` continue to return structured
+`CoolWorkflowRunner.status()` and MCP `cw_status` still give back structured
 status data for integrations.
 
-In v0.1.13, MCP also exposes JSON-native operator tools:
+In v0.1.13, MCP also gives JSON-native operator tools:
 `cw_operator_status`, `cw_operator_graph`, `cw_operator_report`,
 `cw_worker_summary`, `cw_candidate_summary`, `cw_feedback_summary`, and
 `cw_commit_summary`.
 
 ## Next Actions
 
-Recommendations are deterministic and only use commands that exist in the CW
-CLI. Examples:
+The things it puts forward are deterministic and use only commands that are in
+the CW CLI. Examples:
 
 ```text
 node scripts/cw.js dispatch <run-id> --limit 4
@@ -55,39 +55,39 @@ node scripts/cw.js commit <run-id> --selection <selection-id>
   reason: a verified selected candidate is ready for a verifier-gated commit
 ```
 
-Open feedback is prioritized before dispatch or candidate work. If all tracked
-work is complete, the advisor points to `cw report <run-id> --show`.
+Open feedback comes first, before dispatch or candidate work. If all tracked
+work is done, the advisor points to `cw report <run-id> --show`.
 
 ## Graph
 
-Use the top-level graph command for a compact console map:
+Use the top-level graph command for a small console map:
 
 ```bash
 node scripts/cw.js graph <run-id>
 node scripts/cw.js graph <run-id> --json
 ```
 
-The legacy node command remains compatible:
+The legacy node command still works:
 
 ```bash
 node scripts/cw.js node graph <run-id>
 node scripts/cw.js node graph <run-id> --json
 ```
 
-The human graph groups phases, tasks, dispatches, workers, result nodes,
-verifier nodes, candidates, selections, commits, and feedback, then prints the
+The human graph puts phases, tasks, dispatches, workers, result nodes,
+verifier nodes, candidates, selections, commits, and feedback into groups, then prints the
 edges between them. v0.1.17 also adds `multi-agent-run`, `agent-role`,
 `agent-group`, `agent-membership`, `agent-fanout`, and `agent-fanin` nodes when
 the run has first-class multi-agent state. v0.1.18 adds `blackboard`,
 `blackboard-topic`, `blackboard-message`, `blackboard-context`,
 `blackboard-artifact`, `blackboard-snapshot`, and `coordinator-decision` nodes
-when shared coordination state exists. JSON output returns deterministic `nodes`
+when shared coordination state is there. JSON output gives back deterministic `nodes`
 and `edges`.
 
 ## Multi-Agent Operator UX
 
-v0.1.21 adds focused multi-agent operator views that answer who depends on
-whom, who is blocked, and which evidence was adopted into the accepted result:
+v0.1.21 adds clear multi-agent operator views that answer who is dependent on
+whom, who is blocked, and which evidence went into the accepted result:
 
 ```bash
 node scripts/cw.js multi-agent graph <run-id>
@@ -96,7 +96,7 @@ node scripts/cw.js multi-agent failures <run-id>
 node scripts/cw.js multi-agent evidence <run-id>
 ```
 
-The same derived model appears in `status`, `report --show`, and
+The same derived model is in `status`, `report --show`, and
 `cw_multi_agent_status` under `summaries.multiAgentOperator`. See
 [multi-agent-operator-ux.7.md](multi-agent-operator-ux.7.md) for the full
 trace from agent membership to verifier-gated commit.
@@ -109,19 +109,19 @@ trace from agent membership to verifier-gated commit.
 node scripts/cw.js report <run-id>
 ```
 
-Use `--show` or `--summary` when the operator needs a readable console report:
+Use `--show` or `--summary` when the operator needs a console report that is easy to read:
 
 ```bash
 node scripts/cw.js report <run-id> --show
 node scripts/cw.js report <run-id> --summary
 ```
 
-The console report includes the same high-value status panels plus active and
+The console report gives the same high-value status panels plus active and
 pending tasks, evidence paths and locators, and resource inspection commands.
 
 ## Resource Summaries
 
-Major run resources have human summaries by default and JSON when requested:
+The chief run resources have human summaries by default and JSON when you ask for it:
 
 ```bash
 node scripts/cw.js worker summary <run-id>
@@ -150,23 +150,23 @@ sandbox profile ids, manifest paths, result paths, and linked feedback for
 failed or rejected workers.
 
 Candidate summaries show registered/scored/selected/verified/rejected/failed
-counts, latest ranking path, selected candidates, candidates ready for commit,
-and obvious missing scoring/evidence/gate problems.
+counts, the newest ranking path, selected candidates, candidates ready for commit,
+and clear missing scoring/evidence/gate problems.
 
-Feedback summaries group records by open/tasked/resolved/rejected status,
+Feedback summaries put records into groups by open/tasked/resolved/rejected status,
 severity, classification, and retryability.
 
-Commit summaries distinguish verifier-gated commits from non-gated checkpoints
+Commit summaries make a clear line between verifier-gated commits and non-gated checkpoints
 and show snapshot paths, evidence counts, and linked verifier/candidate/selection
 ids.
 
 Multi-agent summaries show run and group status, role coverage, membership
 health, fanout/fanin progress, missing evidence, blocked reasons, and the next
-recommended action.
+action it puts forward.
 
 ## File Discipline
 
-Operator UX follows the same FreeBSD-flavored rule as the rest of CW:
+Operator UX keeps the same FreeBSD-flavored rule as the rest of CW:
 
 ```text
 clear console output for humans
@@ -175,6 +175,6 @@ plain files for evidence
 no hidden daemon assumption
 ```
 
-When in doubt, inspect `.cw/runs/<run-id>/state.json`, the resource directories,
+If you are not certain, inspect `.cw/runs/<run-id>/state.json`, the resource directories,
 and the command-specific `--json` output.
 0.1.51

package/docs/pipeline-runner.7.md

@@ -22,15 +22,16 @@ const result = runner.runPipelineStage(run, "verify", resultNode.id, {
 
 ## DESCRIPTION
 
-`Pipeline Runner` is the small execution kernel between workflow definitions,
-pipeline contracts, state nodes, and CW operations such as dispatch, result,
-verifier, commit, and report.
+`Pipeline Runner` is the small execution kernel that sits between workflow
+definitions, pipeline contracts, state nodes, and CW operations such as
+dispatch, result, verifier, commit, and report.
 
-The runner does not implement business workflow behavior. It owns only stage
-selection, contract validation, state-node transition, parent/child linking,
-artifact and evidence attachment, and structured failure preservation.
+The runner does not do business workflow behavior. It does only these things:
+stage selection, contract validation, state-node transition, parent/child
+linking, artifact and evidence attachment, and the keeping of structured
+failures.
 
-The runner uses existing CW helpers:
+The runner uses CW helpers that are already there:
 
 - `validatePipelineContract`
 - `assertNodeSatisfiesContract`
@@ -48,35 +49,34 @@ The default CW pipeline is:
 input -> plan -> dispatch -> result -> verify -> commit -> report
 ```
 
-A stage run receives a `WorkflowRun`, a `stageId`, and an input `StateNode` id.
-It resolves the active `PipelineContract`, validates the stage, creates the
-output node declared by the contract, links input and output nodes, writes node
-JSON under `nodes/`, and returns a structured result.
+A stage run takes a `WorkflowRun`, a `stageId`, and an input `StateNode` id.
+It finds the active `PipelineContract`, checks the stage, makes the output node
+named by the contract, links input and output nodes, writes node JSON under
+`nodes/`, and gives back a structured result.
 
-The runner records progress in files. There is no hidden in-memory-only
-pipeline cursor.
+The runner keeps a record of progress in files. There is no hidden
+in-memory-only pipeline cursor.
 
 ## CONTRACTS
 
-Stages come from `PipelineContract.stages`. A stage declares accepted input node
-kinds and statuses, required artifacts, required evidence, verifier gate
-requirements, and the produced output node kind.
+Stages come from `PipelineContract.stages`. A stage says which input node
+kinds and statuses it takes, which artifacts and evidence it needs, what the
+verifier gate needs, and the output node kind it makes.
 
-The runner does not duplicate contract validation. It uses the StateNode and
-PipelineContract helpers as the ABI boundary.
+The runner does not do contract validation a second time. It uses the StateNode
+and PipelineContract helpers as the ABI boundary.
 
 ## FAILURE MODES
 
-Contract failures become `StateNodeError` records. When the stage or contract
-failure policy preserves failure nodes, the runner creates an `error` node,
-records the structured error, links it to the input node, and persists it under
-`nodes/`.
+Contract failures turn into `StateNodeError` records. When the stage or contract
+failure policy keeps failure nodes, the runner makes an `error` node, records
+the structured error, links it to the input node, and keeps it under `nodes/`.
 
 Unknown run ids, unknown contract ids, unknown node ids, unknown stage ids, and
-corrupt state remain hard errors because the caller cannot proceed safely.
+broken state stay hard errors because the caller is not able to go on safely.
 
-Commit stages are verifier-gated. The default contract requires a verified
-verifier node with evidence before a `committed` commit node can be created.
+Commit stages are verifier-gated. The default contract needs a verified
+verifier node with evidence before a `committed` commit node can be made.
 Non-gated snapshots are written as `completed` checkpoint nodes outside the
 commit stage.
 
@@ -90,7 +90,7 @@ commit stage.
 .cw/runs/<run-id>/commits/*.json
 ```
 
-Inspection commands print stable JSON:
+Commands that look at runs print stable JSON:
 
 ```text
 cw.js contract show <run-id> [contract-id]
@@ -117,7 +117,7 @@ runPipelineStage(run, "plan", `${run.id}:input`, {
 });
 ```
 
-Preserve a failed stage:
+Keep a failed stage:
 
 ```ts
 const failed = runPipelineStage(run, "commit", taskNode.id, {
@@ -127,10 +127,10 @@ const failed = runPipelineStage(run, "commit", taskNode.id, {
 
 ## COMPATIBILITY
 
-Pipeline Runner is introduced in CW v0.1.3. It preserves v0.1.2 run state and
+Pipeline Runner is first added in CW v0.1.3. It keeps v0.1.2 run state and
 CLI behavior. New public types are plain TypeScript interfaces with optional
-fields where practical.
+fields where it makes sense.
 
-Older runs without `nodes` or `contracts` remain readable through the existing
-state loader, which initializes those arrays.
+Older runs with no `nodes` or `contracts` stay readable through the existing
+state loader, which sets up those arrays.
 0.1.51

package/docs/project-index.md

@@ -1,16 +1,16 @@
 # Cool Workflow Project Index
 
-Generated from the current repository code on 2026-06-15 by `npm run sync:project-index`.
+Generated from the current repository code on 2026-06-16 by `npm run sync:project-index`.
 
 ## Snapshot
 
 - Package: `cool-workflow`
-- Version: `0.1.82`
+- Version: `0.1.83`
 - Source modules: `61`
 - Workflow apps: `7`
 - Docs: `49`
-- Smoke tests: `87`
-- Repository: https://github.com/coo1white/cool-workflow
+- Smoke tests: `92`
+- Repository: http://local_proxy@127.0.0.1:33273/git/coo1white/cool-workflow
 
 ## Architecture
 
@@ -86,6 +86,7 @@ multi-agent host -> topology -> blackboard/coordinator
 - [collaboration.ts](../src/collaboration.ts)
 - [compare.ts](../src/compare.ts)
 - [contract-migration.ts](../src/contract-migration.ts)
+- [doctor.ts](../src/doctor.ts)
 - [drive.ts](../src/drive.ts)
 - [evidence-grounding.ts](../src/evidence-grounding.ts)
 - [evidence-reasoning.ts](../src/evidence-reasoning.ts)
@@ -110,7 +111,6 @@ multi-agent host -> topology -> blackboard/coordinator
 - [telemetry-demo.ts](../src/telemetry-demo.ts)
 - [telemetry-ledger.ts](../src/telemetry-ledger.ts)
 - [validation.ts](../src/validation.ts)
-- [verifier-registry.ts](../src/verifier-registry.ts)
 - [workbench-host.ts](../src/workbench-host.ts)
 - [workbench.ts](../src/workbench.ts)
 
@@ -200,6 +200,7 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [control-plane-scheduling-smoke.js](../test/control-plane-scheduling-smoke.js)
 - [coordinator-blackboard-smoke.js](../test/coordinator-blackboard-smoke.js)
 - [det-ids-b-smoke.js](../test/det-ids-b-smoke.js)
+- [doctor-smoke.js](../test/doctor-smoke.js)
 - [dogfood-release-smoke.js](../test/dogfood-release-smoke.js)
 - [durable-atomic-write-smoke.js](../test/durable-atomic-write-smoke.js)
 - [end-to-end-demo-smoke.js](../test/end-to-end-demo-smoke.js)
@@ -226,15 +227,18 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [one-way-boundary-smoke.js](../test/one-way-boundary-smoke.js)
 - [operator-ux-smoke.js](../test/operator-ux-smoke.js)
 - [parallel-onramp-smoke.js](../test/parallel-onramp-smoke.js)
+- [parity-doc-sync-smoke.js](../test/parity-doc-sync-smoke.js)
 - [pipeline-auto-advance-smoke.js](../test/pipeline-auto-advance-smoke.js)
 - [pipeline-runner-smoke.js](../test/pipeline-runner-smoke.js)
 - [project-index-sync-smoke.js](../test/project-index-sync-smoke.js)
 - [quickstart-smoke.js](../test/quickstart-smoke.js)
 - [real-execution-backends-smoke.js](../test/real-execution-backends-smoke.js)
+- [registry-corrupt-fail-closed-smoke.js](../test/registry-corrupt-fail-closed-smoke.js)
 - [release-flow-smoke.js](../test/release-flow-smoke.js)
 - [release-gate-smoke.js](../test/release-gate-smoke.js)
 - [release-tooling-smoke.js](../test/release-tooling-smoke.js)
 - [result-normalize-smoke.js](../test/result-normalize-smoke.js)
+- [robustness-failclosed-smoke.js](../test/robustness-failclosed-smoke.js)
 - [robustness-hardening-smoke.js](../test/robustness-hardening-smoke.js)
 - [run-export-import-smoke.js](../test/run-export-import-smoke.js)
 - [run-export-restore-rerun-smoke.js](../test/run-export-restore-rerun-smoke.js)
@@ -246,6 +250,7 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [run-resume-drive-smoke.js](../test/run-resume-drive-smoke.js)
 - [run-retention-reclamation-smoke.js](../test/run-retention-reclamation-smoke.js)
 - [sandbox-profile-smoke.js](../test/sandbox-profile-smoke.js)
+- [sched-policy-validation-smoke.js](../test/sched-policy-validation-smoke.js)
 - [schedule-routine-daemon-smoke.js](../test/schedule-routine-daemon-smoke.js)
 - [schema-validation-smoke.js](../test/schema-validation-smoke.js)
 - [security-trust-hardening-smoke.js](../test/security-trust-hardening-smoke.js)

package/docs/real-execution-backends.7.md

@@ -1,19 +1,19 @@
 # Real Execution Backend Integrations
 
-CW v0.1.34 makes the delegating execution backends REAL. v0.1.29 shipped the
-driver layer (`src/execution-backend.ts`) with `node`/`bun`/`shell` really
+CW v0.1.34 makes the delegating execution backends REAL. v0.1.29 gave us the
+driver layer (`src/execution-backend.ts`), with `node`/`bun`/`shell` really
 executing and `container`/`remote`/`ci` as contract-conformant stubs: `delegate()`
-built a handle and returned `status: "completed"` with `delegated:`/`handle:`
-evidence without running anything. v0.1.34 replaces that no-op so the three
-delegating drivers actually drive a container runtime, a remote runner, and a CI
-job — opt-in, fail-closed, and recording the SAME canonical evidence as `node`.
+made a handle and gave back `status: "completed"` with `delegated:`/`handle:`
+evidence, but ran nothing. v0.1.34 takes the place of that no-op, so the three
+delegating drivers truly drive a container runtime, a remote runner, and a CI
+job — opt-in, fail-closed, and keeping the SAME canonical evidence as `node`.
 
-The driver model and the sandbox contract are unchanged; only HOW/WHERE a
+The driver model and the sandbox contract do not change; only HOW/WHERE a
 delegated task runs becomes real.
 
 ## Identical Evidence, Any Backend
 
-A real delegated run records the SAME canonical evidence `executeLocal` produces:
+A real delegated run keeps the SAME canonical evidence `executeLocal` makes:
 
 ```text
 command:<command + args>
@@ -24,35 +24,35 @@ stdoutSha256:sha256:<hex>
 The execution handle (`image@digest`, `endpoint#jobId`) lives in
 `provenance.handle` and the sandbox attestation in `provenance.attestation` —
 NEVER in `evidence`. So a `container` run of the same task is byte-stable against
-`node` after stripping provenance: only `provenance.backendId`/`handle`/
-`attestation` and ISO timestamps differ. Eval/replay, the verifier gates, the
-v0.1.28 registry, and the v0.1.30 Workbench stay backend-agnostic.
+`node` once you take provenance away: only `provenance.backendId`/`handle`/
+`attestation` and ISO timestamps are not the same. Eval/replay, the verifier gates, the
+v0.1.28 registry, and the v0.1.30 Workbench all stay backend-agnostic.
 
 ## container
 
-Runs `docker` (or `podman`) really, under the sandbox contract:
+Runs `docker` (or `podman`) for real, under the sandbox contract:
 
 ```text
 <runtime> run --rm [--network none] -v <cwd>:<cwd>:ro -w <cwd> [-e NAME=VALUE ...] <image[@digest]> <command> <args>
 ```
 
-- **network** — `--network none` when the profile restricts it (`network.mode !=
-  any`); a container network namespace genuinely enforces this (the dimension is
-  declared `enforce`).
+- **network** — `--network none` when the profile holds it back (`network.mode !=
+  any`); a container network namespace truly puts this in force (the dimension is
+  marked `enforce`).
 - **read/write** — the workspace is mounted read-only at the same path; CW's
-  worker-output acceptance still bounds writes. (Write-through mounts are a later
-  refinement.)
-- **env** — only the profile's explicitly exposed names cross into the container;
-  the image supplies its own `PATH`/`HOME`, so host-specific base env is never
-  injected.
+  worker-output acceptance still keeps writes inside limits. (Write-through mounts
+  will come later.)
+- **env** — only the names the profile makes open cross into the container;
+  the image gives its own `PATH`/`HOME`, so host-specific base env is never
+  put in.
 
-Selection supplies the image via `--image` / `CW_CONTAINER_IMAGE` (+ optional
+Selection gives the image through `--image` / `CW_CONTAINER_IMAGE` (+ optional
 `CW_CONTAINER_DIGEST`).
 
 ## remote / ci
 
 Real HTTP delegation. The job `{ command, args, env, sandboxProfileId, jobId? }`
-is POSTed to the configured endpoint by a self-contained Node child (global
+is POSTed to the set endpoint by a self-contained Node child (global
 `fetch`, so the driver stays portable and synchronous from CW's view); a returned
 `jobId` is polled until `done`. The runner's `{ exitCode, stdout }` becomes the
 canonical evidence. Endpoints come from `--endpoint`/`--job` or
@@ -60,30 +60,30 @@ canonical evidence. Endpoints come from `--endpoint`/`--job` or
 
 ## Fail Closed
 
-A delegated run NEVER fabricates a completion. It returns `status: "refused"`
+A delegated run NEVER makes up a completion. It returns `status: "refused"`
 (`attestation.status: "refused"`, a `refused:<code>` evidence line, no
 `stdoutSha256:`) when:
 
 - `delegation-target-missing` — no image (container) or no endpoint (remote/ci).
 - `no-command` — a delegating backend was asked to run with no command.
-- `runtime-unavailable` — no `docker`/`podman` on PATH, or the daemon is
-  **unreachable**. A present CLI with a dead daemon is detected by a pre-flight
-  `<runtime> version --format {{.Server.Version}}` (which returns the server
-  version only when reachable) — the container run's own exit code is NOT a
-  reliable daemon-down signal across runtimes, so it is not relied upon.
-- `delegation-failed` — the runtime errored (e.g. `docker` exit 125 for a bad
-  image), the HTTP POST/poll failed or was unreachable, or the runner returned an
+- `runtime-unavailable` — no `docker`/`podman` on PATH, or the daemon cannot
+  be **reached**. A CLI that is there but with a dead daemon is found by a pre-flight
+  `<runtime> version --format {{.Server.Version}}` (which gives back the server
+  version only when it can be reached) — the container run's own exit code is NOT a
+  sure daemon-down sign across runtimes, so it is not used for this.
+- `delegation-failed` — the runtime gave an error (e.g. `docker` exit 125 for a bad
+  image), the HTTP POST/poll did not work or could not be reached, or the runner gave back an
   unparseable response or no `exitCode`.
 
-A container command that genuinely runs and exits non-zero is `failed` (a real
-result), distinct from `refused` (never ran).
+A container command that truly runs and exits non-zero is `failed` (a real
+result), not the same as `refused` (never ran).
 
 ## Compatibility
 
 The default backend stays `node`; the dispatch path stays a `delegate-host`
-execution reproducing pre-v0.1.29 behavior exactly. With no container runtime, no
-endpoint, and no credentials, every existing probe and test output is unchanged —
-real execution is strictly opt-in. The `ResultEnvelope` schema is unchanged.
+execution that copies pre-v0.1.29 behavior exactly. With no container runtime, no
+endpoint, and no credentials, every probe and test output that is there now does not
+change — real execution is strictly opt-in. The `ResultEnvelope` schema does not change.
 
 ## See Also
 
@@ -92,7 +92,7 @@ run-registry-control-plane(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, again using the v0.1.23 eval harness; fail-closed on source drift (valid|stale|absent). See node-snapshot-diff-replay(7).
 
 ## Contract Migration Tooling (v0.1.36)
 
@@ -104,11 +104,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
+start an outside agent process for each 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)
 
@@ -120,15 +120,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 that stops 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>`) and not the changeable working tree — taking away false-red/false-green that came from concurrent working-tree writes (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)
 
@@ -145,7 +145,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 real execution backends in v0.1.81._
-_No behavioral change in v0.1.82 (delegated child programs extracted to `scripts/children/`; spawn behavior byte-identical)._
+_No behavioral change in v0.1.82 (delegated child programs moved out to `scripts/children/`; spawn behavior byte-identical)._
+
+## 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.