cool-workflow 0.1.82 → 0.1.84

package/docs/run-retention-reclamation.7.md

@@ -2,16 +2,16 @@
 
 CW v0.1.39 adds Run Retention & Provable Reclamation: a tiered, append-only,
 cryptographically-verifiable way to **free disk WITHOUT violating the audit/replay
-moat**. A single day of dogfooding produced ~1 GB across 200+ runs under
+moat**. One day of dogfooding made ~1 GB across 200+ runs under
 `.cw/runs/`, and before v0.1.39 there was **zero disk reclamation** — `run archive`
-only marked an overlay (it never freed bytes), `sched reclaim` reclaimed expired
-leases (not disk), and worker scratch dirs were never cleaned. Naive GC is
-forbidden: CW's entire value is "don't trust, verify." So reclamation is a
+only marked an overlay (it never freed bytes), `sched reclaim` got back expired
+leases (not disk), and worker scratch dirs were never cleaned. Simple GC is
+not allowed: all of CW's value is "don't trust, verify." So reclamation is a
 **verifiable, append-only state transition** — freeing bytes leaves behind
-cryptographic proof that what was freed is reconstructable-or-worthless and that
+cryptographic proof that what was freed can be made again or has no worth, and that
 the audit-essential subset is sealed.
 
-This release builds directly on a precise lineage: v0.1.28's archive overlay
+This release is built straight on a clear line of past work: v0.1.28's archive overlay
 (`run-registry.ts` — "Archive is an overlay mark, not a delete"), v0.1.35's
 per-node snapshot/diff/deterministic replay (`node-snapshot.ts`), v0.1.32's
 append-only collaboration log, and v0.1.37's policy-as-data scheduling. It EXTENDS
@@ -26,37 +26,37 @@ reclaimed tombstone + skeleton + digests  verify-only (or re-runnable-by-reconst
 ```
 
 `archived` keeps its mark-only semantics, untouched. `reclaimed` is the NEW
-disk-freeing tier above it. The lifecycle ceiling for this release is `reclaimed`;
-a future `forgotten` compliance tier (discarding even the skeleton, keeping only
+disk-freeing tier over it. The lifecycle ceiling for this release is `reclaimed`;
+a future `forgotten` compliance tier (dropping even the skeleton, keeping only
 the chained tombstone hash) is out of scope — the `RunLifecycleState` union gains
-ONLY `reclaimed`, and the hash chain is designed to extend to it later.
+ONLY `reclaimed`, and the hash chain is made to extend to it later.
 
 ## The red line — never delete what is audit-essential AND irreproducible
 
-A byte is freeable ONLY if it is one of two classes:
+A byte can be freed ONLY if it is one of two classes:
 
-1. **reconstructable** — deterministically re-derivable from RETAINED inputs + a
+1. **reconstructable** — deterministically able to be made again from RETAINED inputs + a
    recorded recipe + an `expectDigest`, or
 2. **pure scratch** — zero audit value,
 
 AND it is **referenced by no surviving evidence locator or audit/collaboration
-event.** Any path that is neither class defaults to **RETAINED** (fail closed).
+event.** Any path that is in neither class defaults to **RETAINED** (fail closed).
 The hard ALLOW-LIST — never freed under any policy — is `state.json`, `audit/`,
 `commits/`, the collaboration log, the attestation chain, `report.md`, and the new
 `reclaimed.json` overlay.
 
-The **skeleton** is the machine-checkable contract for what must survive every
+The **skeleton** is the machine-checkable contract for what must live through every
 reclamation (`SKELETON_REQUIRED_KEYS` + `validateSkeleton()`): the final verdict,
 every commit record, every evidence locator's content digest, the attestation
 chain, the cost record, and the append-only audit + collaboration logs. If a
-complete skeleton cannot be extracted, reclamation **refuses with
+full skeleton cannot be pulled out, reclamation **refuses with
 `skeleton-incomplete` and frees zero bytes.**
 
 ## Write-ahead, fail-closed sequencing — order is the safety property
 
-The reclamation transaction is four discrete, individually-callable steps:
+The reclamation transaction is four separate steps, each one able to be called on its own:
 
-1. `extractSkeleton()` — extract + seal the audit-essential subset.
+1. `extractSkeleton()` — pull out + seal the audit-essential subset.
 2. `buildTombstone()` — write the full freed-manifest with a **pre-deletion
    sha256 per path**, plus the hash chain.
 3. `commitTombstone()` — **fsync** the tombstone into the append-only
@@ -64,9 +64,9 @@ The reclamation transaction is four discrete, individually-callable steps:
    through the existing append-only trust-audit log.
 4. `freeBulk()` — ONLY THEN free the bulk bytes.
 
-A crash between any steps leaves **EITHER the full run OR a complete tombstone —
-never a half-deleted run with no proof.** This is testable by design:
-`runReclamation(run, policy, { faultAfter })` throws a synthetic `ReclamationAbort`
+A crash between any steps leaves **EITHER the full run OR a full tombstone —
+never a half-deleted run with no proof.** This can be tested by design:
+`runReclamation(run, policy, { faultAfter })` throws a made-up `ReclamationAbort`
 after the named step (`skeleton` | `tombstone-write` | `tombstone-commit`) — never
 by killing the process.
 
@@ -75,9 +75,9 @@ by killing the process.
 The tombstone is a NEW `reclaimed.json` overlay (a peer of `archive.json`'s role).
 Only the bulk DATA bytes are freed — no existing audit, state, or commit record is
 ever rewritten. It is itself a new audit record, **hash-chained**: `tombstoneHash`
-is recomputed from the freed-manifest + sealed skeleton + `prevTombstoneHash`
-(genesis = sha256 of the sealed skeleton). `gc verify` recomputes `tombstoneHash`
-**independently**, never trusting the stored value, so a tampered registry entry
+is worked out again from the freed-manifest + sealed skeleton + `prevTombstoneHash`
+(genesis = sha256 of the sealed skeleton). `gc verify` works out `tombstoneHash`
+again **on its own**, never trusting the stored value, so a changed registry entry
 is caught — flipping a per-path sha256 fails with `tombstone-digest-mismatch`;
 editing a hash link fails with `tombstone-chain-broken`.
 
@@ -90,22 +90,22 @@ enumerable `record.capabilityReason` (a closed set, e.g.
 `snapshot-reclaimed-no-reconstruction` | `inputs-and-expectdigest-retained` |
 `scratch-only-reclaimed`) — never free-text prose.
 
-**Reconstruction is a distinct code path, NOT live `verifyNodeReplay`.** A reclaimed
+**Reconstruction is a separate code path, NOT live `verifyNodeReplay`.** A reclaimed
 artifact making `loadNodeSnapshot` return `absent` is the EXPECTED fail-closed
 signal. The reconstruction verifier re-runs the recorded recipe against the
 RETAINED inputs (keyed on the retained-inputs digest) and compares the result's
-sha256 to the tombstoned `expectDigest` — it never routes through the freed source
+sha256 to the tombstoned `expectDigest` — it never goes through the freed source
 bytes. Flipping one retained input byte fails with `reconstruction-digest-mismatch`.
 
 ## The eager-scratch exception
 
-Worker scratch is the one class reclaimed eagerly. A worker's scratch dir is pure
+Worker scratch is the one class reclaimed early. A worker's scratch dir is pure
 scratch with zero audit value, and its `result.md` is already copied to
 `results/<task-id>.md` and evidence-gated. Before the scratch is freed, the result
 node's `worker-result` artifact (set by `recordWorkerOutput` to a path INSIDE the
 scratch dir) is **re-pointed** to the retained `results/<task-id>.md` copy, and the
-result-node snapshot is proven to stay `valid` (not `absent`) — so no surviving
-node references a freed path. Opt out with `--keep-scratch`.
+result-node snapshot is shown to stay `valid` (not `absent`) — so no surviving
+node points to a freed path. Opt out with `--keep-scratch`.
 
 ## CLI
 
@@ -115,14 +115,14 @@ cw gc run    [run-id] [--reclaimAfterArchiveDays N] [--keep-scratch] [--keep-sna
 cw gc verify <run-id> [--scope repo|home] [--json]
 ```
 
-- `gc plan` is a pure **dry-run**: it computes eligible runs, the exact bytes that
+- `gc plan` is a pure **dry-run**: it works out eligible runs, the exact bytes that
   WOULD be freed per kind, and the per-run capability downgrade. It frees nothing
   (`plan.bytesToFree` equals the summed per-path sizes it lists).
-- `gc run` executes the write-ahead transaction for eligible runs, bounded by
+- `gc run` runs the write-ahead transaction for eligible runs, bounded by
   `maxReclaimRuns` / `maxReclaimBytes`, fail-closed on any incomplete skeleton.
 - `gc verify` re-proves a reclaimed run end-to-end.
 
-Eligibility is explicit and fail-closed: a run is reclaimable exactly when its
+Eligibility is explicit and fail-closed: a run can be reclaimed exactly when its
 **derived lifecycle is `completed` or `failed` AND it is archived AND it has no
 open feedback AND it is past `reclaimAfterArchiveDays`.** `running` / `blocked` /
 `queued` runs are NEVER reclaimable; the check reads live source state and fails
@@ -134,8 +134,8 @@ action, never a daemon.
 ## MCP
 
 `cw_gc_plan`, `cw_gc_run`, and `cw_gc_verify` are the peers of the CLI verbs,
-registered in the capability registry and validated by `parity:check` (fail-closed
-on drift). The read-only `gc plan` / `gc verify` payloads obey the now-derived-field
+registered in the capability registry and checked by `parity:check` (fail-closed
+on drift). The read-only `gc plan` / `gc verify` payloads follow the now-derived-field
 rule: only ISO timestamps may be now-derived.
 
 ## Policy-as-data
@@ -147,16 +147,16 @@ Back-compatible defaults reclaim nothing; pre-v0.1.39 runs load unchanged.
 
 ## Compatibility
 
-Additive. The kernel `state.json` schema is unchanged beyond the new per-run
+Additive. The kernel `state.json` schema is unchanged but for the new per-run
 `reclaimed.json` overlay + policy fields; pre-v0.1.39 runs load unchanged. The
 `RunLifecycleState` union gains only `reclaimed`. `run archive` keeps its mark-only
-semantics. Nothing in the original audit log is ever edited or erased.
+semantics. Nothing in the first audit log is ever edited or wiped.
 
 ## See Also
 
 - `docs/run-registry-control-plane.7.md` — the v0.1.28 archive overlay this extends.
-- `docs/node-snapshot-diff-replay.7.md` — the v0.1.35 snapshot engine reconstruction layers beside.
-- `docs/control-plane-scheduling.7.md` — the v0.1.37 policy-as-data lineage.
+- `docs/node-snapshot-diff-replay.7.md` — the v0.1.35 snapshot engine reconstruction sits beside.
+- `docs/control-plane-scheduling.7.md` — the v0.1.37 policy-as-data line of work.
 - `docs/team-collaboration.7.md` — the v0.1.32 append-only log sealed in the skeleton.
 
 ## Durable State & Locking (v0.1.40)
@@ -169,15 +169,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 sensible agent shape (alt keys + prose), CW derives grounded evidence itself, warn on empty capture — shuts 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 — getting rid of 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 that gives any non-Claude AI agent one common interface to CW.
 
 ## P1-P2 Fixes & CI Content Surfaces (v0.1.49)
 
@@ -194,9 +194,17 @@ 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, measurable wrapper metrics, useful background full-review handoff, and userland model policy flags for routing fast/strong workers without changing the full review contract.
 
 ## Deterministic Freed Manifest (v0.1.81)
 
-The freed manifest is path-sorted before it feeds `tombstoneHash`, so reclamation's write-ahead tombstone hash-chain is reproducible across hosts regardless of filesystem enumeration order. Reclaimed tiers, the re-point seam, and the default (reclaim-nothing) policy are unchanged.
+The freed manifest is path-sorted before it feeds `tombstoneHash`, so reclamation's write-ahead tombstone hash-chain can be made again across hosts no matter the filesystem enumeration order. Reclaimed tiers, the re-point seam, and the default (reclaim-nothing) policy 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.
+
+## Privacy Release (v0.1.84)
+
+No other change to this page in v0.1.84.

package/docs/sandbox-profiles.7.md

@@ -16,14 +16,14 @@ node dist/cli.js worker manifest <run-id> <worker-id>
 
 ## DESCRIPTION
 
-A sandbox profile is a CW policy contract. It tells the agent host what a
-worker may read, write, execute, access over the network, and receive through
+A sandbox profile is a CW policy contract. It says what the agent host lets a
+worker read, write, execute, get to over the network, and take in through
 environment variables.
 
-It is not a container, jail, chroot, seatbelt profile, packet filter, or OS
-process sandbox by itself. CW enforces profile validation, deterministic path
+By itself it is not a container, jail, chroot, seatbelt profile, packet filter,
+or OS process sandbox. CW does profile validation, deterministic path
 normalization, worker result acceptance, and durable feedback for denied worker
-output. The agent host must enforce OS-level file access, process execution,
+output. The agent host has to do OS-level file access, process execution,
 network access, and environment filtering.
 
 The design goal is simple:
@@ -32,28 +32,28 @@ The design goal is simple:
 named policy -> resolved worker manifest -> host enforcement -> CW acceptance
 ```
 
-Profiles are selected at dispatch time and stored in run state, worker records,
+Profiles are picked at dispatch time and kept in run state, worker records,
 dispatch manifests, worker manifests, feedback records, and reports.
 
 ## BUNDLED PROFILES
 
 `default`
-: Preserves existing Worker Isolation behavior. Workers may read the workspace
-  and write only accepted worker output paths unless additional `allowedPaths`
-  are supplied by older APIs.
+: Keeps the same Worker Isolation behavior. Workers may read the workspace
+  and write only accepted worker output paths, unless more `allowedPaths`
+  come from older APIs.
 
 `readonly`
 : Workers may read the workspace and write only worker-local output paths.
-  Network access is denied by profile. CW still relies on the host to enforce
-  read-only mounts or equivalent OS policy.
+  Network access is denied by profile. CW still needs the host to do
+  read-only mounts or an equal OS policy.
 
 `workspace-write`
-: Workers may read and write the workspace, plus worker-local output paths.
-  Use this only for workers expected to modify repository files.
+: Workers may read and write the workspace, and worker-local output paths too.
+  Use this only for workers that are meant to change repository files.
 
 `locked-down`
 : Workers may read only `input.md` and write only `result.md`. Command,
-  network, and inherited environment access are denied by policy.
+  network, and inherited environment access are all denied by policy.
 
 ## PROFILE SHAPE
 
@@ -73,14 +73,14 @@ Profile files use schema version `1`:
 }
 ```
 
-Supported path tokens are `$cwd`, `$runDir`, `$workerDir`, `$inputPath`,
-`$resultPath`, `$artifactsDir`, and `$logsDir`. Relative paths are resolved
+The path tokens you may use are `$cwd`, `$runDir`, `$workerDir`, `$inputPath`,
+`$resultPath`, `$artifactsDir`, and `$logsDir`. Relative paths are worked out
 from the run workspace. Empty paths, control characters, unknown tokens, and
-`..` traversal are rejected.
+`..` traversal are turned away.
 
 `execute.mode` and `network.mode` are `none`, `allowlist`, or `any`.
 Allowlisted commands or network targets are exact strings. Environment variable
-names must use normal shell identifier syntax.
+names have to use normal shell identifier syntax.
 
 ## ENFORCEMENT
 
@@ -93,15 +93,15 @@ CW-enforced:
 
 Host-required:
 
-- preventing reads outside `readPaths`
-- preventing writes before CW accepts a result
+- stopping reads outside `readPaths`
+- stopping writes before CW takes a result
 - command execution restrictions
 - network restrictions
 - environment variable filtering
 
-Worker manifests include both lists as `sandbox.enforcedByCW` and
-`sandbox.hostRequired`. Do not present CW Sandbox Profiles as OS-level
-sandboxing unless the agent host actually applies OS policy.
+Worker manifests have both lists as `sandbox.enforcedByCW` and
+`sandbox.hostRequired`. Do not put forward CW Sandbox Profiles as OS-level
+sandboxing unless the agent host truly puts OS policy to work.
 
 ## FILES
 
@@ -118,20 +118,20 @@ sandboxing unless the agent host actually applies OS policy.
 
 Unknown requested profiles fail closed with `sandbox-profile-not-found`.
 
-Malformed profile files fail validation with `sandbox-profile-invalid`.
+Bad profile files fail validation with `sandbox-profile-invalid`.
 
-Denied worker output writes create `sandbox-write-denied` feedback. Runtime
-helpers also provide `sandbox-read-denied`, `sandbox-network-denied`, and
-`sandbox-command-denied` for hosts that want to record those decisions through
+Denied worker output writes make `sandbox-write-denied` feedback. Runtime
+helpers also give `sandbox-read-denied`, `sandbox-network-denied`, and
+`sandbox-command-denied` for hosts that want to note down those decisions through
 CW.
 
-CW never silently downgrades a requested profile to `default`.
+CW never quietly drops a requested profile down to `default`.
 
 ## COMPATIBILITY
 
-Sandbox Profiles are introduced in CW v0.1.8. The legacy `allowedPaths` field
-remains in worker scopes and manifests as the effective write-path alias for
+Sandbox Profiles come in with CW v0.1.8. The legacy `allowedPaths` field
+stays in worker scopes and manifests as the effective write-path alias for
 older callers. New hosts should read `sandboxPolicy.readPaths` and
-`sandboxPolicy.writePaths`, then apply worker output allowances from
-`sandboxPolicy.workerOutput`.
+`sandboxPolicy.writePaths`, then put worker output allowances from
+`sandboxPolicy.workerOutput` to work.
 0.1.51

package/docs/scheduled-tasks.md

@@ -1,9 +1,9 @@
 # Scheduled Tasks
 
-CW scheduled tasks support looping prompts, cron-like schedules, one-shot
-reminders, expiration, jitter, and explicit completion.
+CW scheduled tasks let you make looping prompts, cron-like schedules, one-shot
+reminders, expiration, jitter, and clear completion.
 
-CW stores schedules in:
+CW keeps schedules in:
 
 ```text
 .cw/schedules/tasks.json
@@ -11,7 +11,7 @@ CW stores schedules in:
 
 ## Commands
 
-Create a `/loop`-compatible schedule:
+Make a `/loop`-ready schedule:
 
 ```bash
 node scripts/cw.js loop \
@@ -19,7 +19,7 @@ node scripts/cw.js loop \
   --prompt "Check this workflow and continue if work is due."
 ```
 
-Create a loop:
+Make a loop:
 
 ```bash
 node scripts/cw.js schedule create \
@@ -28,7 +28,7 @@ node scripts/cw.js schedule create \
   --prompt "Check this workflow and continue if work is due."
 ```
 
-Create a cron schedule:
+Make a cron schedule:
 
 ```bash
 node scripts/cw.js schedule create \
@@ -37,7 +37,7 @@ node scripts/cw.js schedule create \
   --prompt "Run the due workflow scan."
 ```
 
-Create a reminder:
+Make a reminder:
 
 ```bash
 node scripts/cw.js schedule create \
@@ -46,7 +46,7 @@ node scripts/cw.js schedule create \
   --prompt "Remind me to inspect the report."
 ```
 
-List and scan:
+List and look through:
 
 ```bash
 node scripts/cw.js schedule list
@@ -59,13 +59,13 @@ node scripts/cw.js schedule history <schedule-id>
 node scripts/cw.js schedule delete <schedule-id>
 ```
 
-Run the local desktop-style daemon once:
+Run the local desktop-like daemon one time:
 
 ```bash
 node scripts/cw.js schedule daemon --once
 ```
 
-Run it continuously:
+Run it without stopping:
 
 ```bash
 node scripts/cw.js schedule daemon --intervalSeconds 60
@@ -73,8 +73,8 @@ node scripts/cw.js schedule daemon --intervalSeconds 60
 
 ## Notes
 
-- Resolution is minute-level.
-- Default expiration is 7 days.
-- `jitterSeconds` can spread runs.
+- Time is measured to the minute.
+- By default, expiration comes after 7 days.
+- `jitterSeconds` can put space between runs.
 - CW does not start the daemon by default. Use `schedule daemon`, cron, or
-  another supervisor to call `schedule due` and execute due prompts.
+  some other overseer to call `schedule due` and run due prompts.

package/docs/security-trust-hardening.7.md

@@ -2,13 +2,13 @@
 
 CW v0.1.15 adds a local trust audit layer for worker sandbox decisions,
 evidence provenance, candidate selection, and verifier-gated commits.
-CW v0.1.22 reuses this same layer for multi-agent role policy, blackboard
+CW v0.1.22 uses this same layer again for multi-agent role policy, blackboard
 write audit, message provenance, judge rationale, panel decisions, and policy
 violations.
 
 ## Audit Records
 
-Every run has an audit directory:
+Every run has an audit directory of its own:
 
 ```text
 .cw/runs/<run-id>/audit/
@@ -17,37 +17,37 @@ Every run has an audit directory:
   summary.json
 ```
 
-`events.jsonl` is append-friendly. `index.json` and `summary.json` are
-deterministic inspection files regenerated by CW commands.
+`events.jsonl` is made so you can add to the end. `index.json` and `summary.json` are
+fixed, repeatable look files that CW commands make again.
 
-Each event records:
+Each event keeps a record of:
 
 - schema version, event id, timestamp, run id, kind, decision, and source
-- actor, worker id, task id, node id, candidate id, score id, selection id, or commit id when relevant
+- actor, worker id, task id, node id, candidate id, score id, selection id, or commit id when it has a part to play
 - sandbox profile id and policy snapshot/reference
-- normalized path, command, network target, or env variable names when relevant
+- normalized path, command, network target, or env variable names when they have a part to play
 - evidence references and parent audit event ids
 - feedback ids for denied or failed decisions
 
-Event sources are explicit:
+Event sources are clear:
 
-- `cw-validated`: CW checked a policy or gate locally.
-- `host-attested`: the agent host or operator recorded what the host enforced.
-- `operator-recorded`: a human or caller supplied the record.
-- `runtime-derived`: CW derived the event from run state.
+- `cw-validated`: CW checked a policy or gate on the local machine.
+- `host-attested`: the agent host or operator put down a record of what the host made certain.
+- `operator-recorded`: a person or caller gave the record.
+- `runtime-derived`: CW got the event from run state.
 
-CW does not store secrets or raw environment values. Environment audit records
-store names only.
+CW does not keep secrets or raw environment values. Environment audit records
+keep names only.
 
 ## Enforcement Boundary
 
-CW validates sandbox profiles, normalizes paths, validates worker output
-acceptance, validates command/network/env decisions when asked, and records
-durable feedback for denied worker decisions.
+CW checks sandbox profiles, normalizes paths, checks worker output
+acceptance, checks command/network/env decisions when asked, and keeps
+lasting feedback for denied worker decisions.
 
-The agent host must still enforce OS-level read isolation, write isolation,
-process execution restrictions, network restrictions, and environment filtering.
-The audit layer makes that boundary inspectable; it is not a kernel.
+The agent host must still make certain of OS-level read isolation, write isolation,
+limits on process execution, limits on network, and environment filtering.
+The audit layer lets you look at that boundary; it is not a kernel.
 
 ## CLI
 
@@ -67,24 +67,24 @@ node scripts/cw.js audit decision <run-id> <worker-id> --network example.com
 node scripts/cw.js audit decision <run-id> <worker-id> --env SECRET_NAME
 ```
 
-Denied audit decisions are written to audit files and linked to feedback/error
-records. Environment values are redacted to names.
+Denied audit decisions are put into audit files and joined to feedback/error
+records. Environment values are cut back to names.
 
 ## Evidence Provenance
 
-`StateEvidence` remains backward compatible. v0.1.15 adds optional
+`StateEvidence` still works with older versions. v0.1.15 adds optional
 `provenance` metadata that can point from:
 
 ```text
 worker result -> result node -> verifier node -> candidate -> score -> selection -> commit
 ```
 
-Candidate scores, selections, and verifier-gated commits preserve provenance
-links instead of only copying evidence arrays.
+Candidate scores, selections, and verifier-gated commits keep provenance
+links in place of only copying evidence arrays.
 
 ## Why Accepted
 
-Selected candidates and verifier-gated commits carry an acceptance rationale:
+Selected candidates and verifier-gated commits come with an acceptance rationale:
 
 - selected candidate id
 - score id and score criteria
@@ -95,12 +95,12 @@ Selected candidates and verifier-gated commits carry an acceptance rationale:
 - commit gate result
 - audit event ids
 
-Verifier-gated commits fail closed when the acceptance rationale cannot explain
+Verifier-gated commits fail closed when the acceptance rationale is not able to make clear
 the evidence chain.
 
 ## MCP
 
-The MCP server exposes matching tools:
+The MCP server gives these like tools:
 
 - `cw_audit_summary`
 - `cw_audit_worker`
@@ -113,5 +113,5 @@ The MCP server exposes matching tools:
 - `cw_audit_attest`
 - `cw_audit_decision`
 
-Existing MCP tool names remain stable.
+MCP tool names that are already there do not change.
 0.1.51