# Changelog All notable changes to this project are documented here. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/). The project uses [Semantic Versioning](https://semver.org/); as of 1.0.0, a backwards-incompatible change to a covered surface ([SPEC.md §12](./SPEC.md#12-versioning--the-10-compatibility-contract)) requires a major bump. ## [Unreleased] ## [2.5.0] — 2026-08-28 ### Added - **`cowork-harness assertions --list` gains a "Skill references (progressive disclosure)" family** for the two new keys, so they are not appended to a flat dump nobody reads. - **A guard that a committed cassette's `tool_not_called` is actually violable by its own recording.** The tool surface at a tier is **gate-conditional**: at `container`, `mcp__workspace__web_fetch` is offered only when `coworkWebFetchViaApi` is on (17 of 138 measured container runs), and with the gate off `WebFetch` is offered instead. `examples/replays/example-pdf-skill.cassette.json` asserts `tool_not_called: "mcp__workspace__web_fetch"` and passes today only because it was recorded gate-ON — a re-record with the gate off would leave it naming a tool the run could never have called, so it would keep passing while verifying nothing, and nothing in the suite would notice. `verify-cassettes`'s `replaced-builtin` note keys on the recorded *inventory*, never on the assertions, and only covers built-ins being replaced, never the inverse. The guard checks every committed cassette's `tool_called`/`tool_not_called` against that cassette's own frozen init inventory, through the same glob engine the evaluator uses. It deliberately does **not** cover `subagent_tool_absent` (judged against the per-dispatch `declaredTools`, a different inventory) and cannot see alias-class vacuity (`tool_not_called: "Task"` names a tool that is in every inventory yet never emitted — the agent binary canonicalizes `Task` to `Agent`); both are recorded as separate work rather than left implied. - **`referencesAccessed` — reference access through EVERY tool channel, not just the `Read` tool.** `referencesRead` counts one channel, and `critique`'s headline invited a reader to conclude the agent had opened no reference — a claim about *reading* that a one-channel count cannot support. An agent that `cat`s, `grep`s or globs a reference has reached it just as much. The new `RunResult` field (and its `subagents[]` twin) records each file with the channel(s) it was reached through: `read` (`Read.file_path`), `grep` (its `path` input), and `bash` (a `Bash`/`mcp__workspace__bash` command naming the path). All four channels apply the **same** `skillReferenceReadPath()` predicate, so a token only counts when it is rooted in the mounted plugin — the agent's own `node scripts/build.js` is not a skill-script access, and a non-skill filename never reaches `result.json` under a field claiming it is skill content. Redirection targets and every argument of a write verb (`rm`/`mv`/`mkdir`/`touch`/`chmod`/`tee`) is excluded, as is a verb that only inspects metadata (`ls`/`test`/`stat`/`echo`): those are files the command wrote or destroyed. It **deliberately under-approximates**. A `cd` into the skill dir followed by a bare `cat references/x.md`, a heredoc body and a `$VAR`-built path are all invisible, and there are tests pinning them as misses so a later widening is a visible change rather than a silent one. **Presence is the cannot-verify channel**, which is the one way it differs from `referencesRead`: `[]` means the drive ran and observed nothing (a real negative); **absent** means there was no observable drive, and must never be read as "none". Present on live *and* replay — cassettes freeze whole tool inputs, so the replay re-drive reconstructs every channel identically. `referencesRead` is unchanged in meaning and is now documented as this field's `read`-channel projection, produced by the same capture so the two cannot disagree. Scope is **main agent ∪ sub-agents**, via a single `unionReferenceAccesses()` derivation shared by the assertion keys, the critique report and `--probe dispatch` — a dispatcher-shaped skill does all its reading a level down, so judging the top-level list alone would report "never reached" on a run where a sub-agent read the file cover to cover. A **truncated cassette** (one that could never be driven) reports cannot-verify rather than an empty list, for the same reason. - **`reference_read` / `no_observed_reference_access` assertion keys.** Gate on whether a skill's progressive disclosure actually works: a well-partitioned skill and one whose second half is dead look identical from outside. Regex (unanchored, case-insensitive — the same shared helper every regex key uses), main agent ∪ sub-agents, evaluated on replay as well as live. The negative key is named `no_observed_reference_access`, not `no_reference_read`, because the detector under-approximates by design: it proves nothing was *seen*, not that the file went unread. Both keys **fail evidence-unavailable** when the run recorded no observable access list — including the negative one, which is the direction that would otherwise pass vacuously off a missing field. The scenario linter rejects asserting both with the same pattern. - **`critique` names why the GRADED turn errored** — `gradedErrorReason` in the JSON report and inline in the text NOTE. `taskResult: "error"` is a legitimate **gradeable** outcome and the critique still runs, but the report said only "the task run ended in error", so an exhausted quota or a dropped connection read as a defect in the skill under review. - **`critique` reports which model produced the GRADED run** — `gradedModels` in the JSON report and `graded model(s):` in the text header, read back from the graded turn's own `result.json` and filtered of the agent's locally-fabricated `` entries. The report named the *evaluator's* resolved model and no other, so the model that produced the behaviour being graded appeared nowhere. It cannot be inferred from context either: the turns are a subprocess that inherits no model from whatever invoked `critique`, so an omitted `--model` silently grades whatever the spawned agent defaults to. A run with nothing recorded now says `graded model(s): unknown` rather than staying silent. The ids are **observed, not requested** — read from the model stamped on the graded turn's assistant messages, not from the flag. - `isLiveModelId` (`src/types.ts`) — the agent-marker filter every consumer of `RunResult.models` must apply, now declared once beside the field it governs. It replaces **three** divergent copies, two of which disagreed: `src/run/provenance.ts` (which renders `provenance.model` on every JSON envelope) matched the angle-bracket **shape**, `scripts/eval-gate.ts` the `<` **prefix** — so a malformed or truncated marker such as `", )`; everything else renders as `INFRASTRUCTURE/PROTOCOL FAILURE ()` and it **fails closed** — `internal` is the CLI's catch-all for any unexpected throw (Docker down, container start failure, missing staged agent, a harness bug), so an unrecognized category is treated as an instrument failure rather than assumed ordinary. - **A turn that exited 1 was reported as a bare exit code, so an exhausted quota looked like a crash.** A turn that RAN and errored exits `1` with a full result envelope whose top-level `error` is `null` — its cause lives in `results[0]`, not in an error object. Reading only the error object left the report saying `reflection turn exited with code 1 (expected 0)` and nothing more, for a run whose actual cause was an exhausted seven-day quota; it was findable only by opening `events.jsonl` by hand. The failed turn's `resultErrorKind` / `errorSource` / `resultSubtype` are now read and rendered — `usage_limit` as "the account's quota is exhausted; retry after the reset. This is NOT a harness or skill defect", `transport` as a retryable tail-end drop — matching how the run renderer has always shown them. `usage_limit` and `transport` join the ordinary/actionable set; `agent` does not, because for critique's own protocol turn an agent-level failure *is* the instrument breaking. ## [2.4.0] — 2026-08-27 ### Fidelity - **Path resolution: the shell and the file tools use DIFFERENT roots, and the harness now models that.** Measured on desktop-local Cowork 2026-08-27: `mcp__workspace__bash` starts every call at the bare session root (`/sessions/`), while the agent process sits at the outputs dir, so a bare `Write` lands in `mnt/outputs` and is user-visible immediately. The two are different path spaces — a file the shell creates with a relative path is *not* where a relative `Write` puts one. `hostloop` ran its workspace bash at `${sessionRoot}/mnt/`, collapsing the two. The replaced derivation came from the asar's `cwd: c.vmCwd` spawn argument, which is **not load-bearing on the cowork path** — only the `chat` branch prepends an explicit `cd ${vmCwd}`, which would be redundant if the argument worked. It reproduced a prompt claim rather than an observed behaviour. Both cwds now come from one function (`hostLoopCwds`) and are pinned together in a single test: a single-value assertion cannot express "shell and file tools disagree, on purpose", which is the contract every previous version of this bug flattened. **What it changes for you:** a skill that writes deliverables from a shell script using relative paths looked correct at `hostloop` and delivered nothing in production. It now fails here too. - **`container` models production's VM-loop `web_fetch` swap.** When `coworkWebFetchViaApi` resolves on (true in every shipped baseline), the tier registers a workspace SDK-MCP server exposing **web_fetch only**, disallows the built-in `WebFetch`, and aliases the name to `mcp__workspace__web_fetch` (`VM_LOOP_TOOL_ALIASES`). Bash is deliberately untouched — "Bash is the only tool that truly diverges between loops" — which is why `container` keeps the built-in shell while `hostloop` replaces both. The three parts ship together by necessity: disallowing the built-in without the alias turns a fidelity fix into a regression, because the bare name stops resolving instead of landing on the workspace tool. The tool is advertised but deliberately **not** pre-approved — production's VM-loop registration passes the same approval hook the host loop does, so the call is gated at `can_use_tool`. Pre-approving it would make a scripted `webfetch:` answer, and `decide: deny` on it, silently inert. Its fetch is bound to the session egress allowlist and to URL provenance, exactly as the host loop's is. Both matter: this fetch runs in the harness's own process, outside the container network namespace, so the sidecar proxy never sees it and only these two gates constrain it. The handler's allowlist now defaults to **deny-all** rather than `["*"]`, so a caller that forgets to pass one gets nothing through instead of everything. The workspace handler now gates **dispatch** on the same set it advertises, not just `tools/list`. An unadvertised tool that still executed when named was a real hole: the VM-loop registration exposes web_fetch only, and a `bash` call arriving there must be refused rather than quietly exec'd into the container. **`microvm` is unchanged** and still offers the built-in `WebFetch` — `spawnMicroVm` does not receive the gate. **`chat` is unchanged too**: the swap applies to `run`/`record`, so `chat --fidelity container` still offers the built-in and the two surfaces differ at the same declared tier. ### Upgrade impact - **At `fidelity: container` under `run`/`record`, `WebFetch` is no longer in the offered tool set.** An assertion naming it no longer describes a callable tool. `tool_not_called: WebFetch` is the dangerous direction: it now passes **vacuously** rather than failing loudly, so a scenario that was genuinely testing "this skill does not fetch from the web" silently stops testing anything. Rename to `tool_not_called: mcp__workspace__web_fetch`. The shipped `example-pdf-skill` scenario carried exactly this defect and is fixed. `verify-cassettes` grew a `replaced-builtin` note for this class: it reads a cassette's recorded init inventory and reports built-in names the current build no longer offers at that tier. It is a **note, not a finding** — the swap is gate-conditional, so a recording made with the gate off is legitimately different, and an init event carrying no `tools` key is *no evidence* rather than a missing surface. Neither should be told to re-record. This does not break a covered surface ([SPEC.md §12](./SPEC.md#12-versioning--the-10-compatibility-contract)): no command, flag, schema or exit-code meaning changes. The tier's modelled tool inventory is a fidelity property, and moving it toward production is the project's purpose — so it ships in a minor. - **DEPRECATION: `fidelity:` becomes REQUIRED in the next major.** A scenario that omits it currently defaults to `container`, which models the **VM loop** — but production runs the **host loop** (gate `1143815894` is force-ON in every shipped baseline). So an omitted key silently measures the scenario against a lane real users are not on, and the two lanes differ in exactly the ways that bite: where a bare relative path lands, where the shell starts, and which tools are offered. Both `run` and the skill's `scenario.py` lint now warn (`fidelity-defaulted`). The check reads the RAW document, because Zod's `.default()` makes an omitted key indistinguishable from a deliberate `fidelity: container` — and those two deserve different treatment. Naming the tier explicitly silences it; `fidelity: container` remains a valid, non-warning choice. ### Fixed - **The semantic judge was told which authored files were never delivered.** The authored-file capture deliberately includes the scratchpad, but production discards anything outside `mnt/` — "never reaches the user or your file tools". Unlabelled, a rubric like "the report was written" graded TRUE on a file the user never receives: a false green inside the one evaluator that reads free-form prose and cannot infer the convention. Scratch files are now tagged `— SCRATCH, NOT delivered to the user`, with a note explaining they are evidence of what the run DID and not that anything was delivered. - **`sync` no longer refuses to write on the `subagentPromptServerOverride` gate.** Gate-ON only enables the lookup; the payload that would actually override is delivered **per session by the server** and appears in neither the asar, the fcache nor `config.json`. So gate state alone cannot separate "override active" from "gate on, no payload, fallback still correct" — the guard blocked forever rather than tripping, because it could never clear itself from its own inputs. It is now a non-blocking note that says what it can and cannot know. Settled by a live sub-agent probe instead: a real sub-agent's environment section matched the committed paraphrase on all four load-bearing claims, so no override was reaching that account. That is evidence, not proof — one account, one session, and a server rule can be segment-targeted. The note says so, and says to re-probe if the sub-agent append matters to what you are shipping. ### Documentation - **[docs/scenario.md](./docs/scenario.md) now states where a relative path actually lands**, as a measured table per tier, replacing a sentence that was simply wrong for the file tools. The guidance that follows it is lane-dependent, because the correct answer inverts between lanes: on the desktop host loop the file tools are already rooted at `outputs/`, so writing `outputs/x.md` doubles to `outputs/outputs/x.md` and the user never sees it — a **bare filename** is right there. At `container`/`microvm` a bare name lands in the scratchpad instead. Addressing a connected folder by name never reaches it on either lane: it builds a same-named decoy inside `outputs`, reports success, and gives no signal. - **[docs/fidelity-gaps.md](./docs/fidelity-gaps.md)** gained the path-resolution split, and its "VM tiers have no workspace tool aliases" entry is updated — closed at `container`, still open at `microvm`. - The skill's undelivered-deliverables guidance no longer hardcodes the literal prefix `outputs/`, which was wrong on the lane production actually runs. - **The product's vocabulary is mapped to this project's**, because one directory had four names and none of them was the one Cowork's UI shows. "Working folder" is the user-visible roots (`outputs/` plus each connected folder); "Scratchpad" is everything outside `mnt/`; `{{workspaceFolder}}` is a prompt token that renders to the *first* user-visible root. Also recorded: Cowork's **Scratchpad panel is an activity log, not a location listing** — it lists files as "wrote to" wherever they landed, so a file appearing there is not evidence it was undelivered. - **`Write`'s tool result echoes the raw path it was given and never absolutizes** (read from the agent binary). Nothing in the harness parses a path out of a `Write` result; this is recorded so nothing starts, since such an assertion would be reading something production does not emit. Cowork's own chat-surface prompt claims the opposite, so the product's description of its own tool is wrong here. ## [2.3.0] — 2026-08-26 ### Parity - **Baseline `desktop-1.37937.1` (agent `2.1.246`).** `sync` had been refusing to write on three `spawn.env` deltas; all three are now classified. **Two new pinned keys.** The Cowork spawn sets `CLAUDE_CODE_PROMPT_CACHE_TTL="1h"` and `CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL="5m"` unconditionally — no gate, no session or deployment branch — so every first-party session receives them. They are **additive**: `ENABLE_PROMPT_CACHING_1H="1"` is still set alongside. They read zero times in agent `2.1.241` and six times each in `2.1.246`, so the contract went live one agent release after Desktop began setting it. **`MCP_TOOL_TIMEOUT` is now classified per SITE, not per key.** Its first-party construction is unchanged (still resolving to `180000`), but the third-party-only branch gained a second, settings- conditional construction of the same key whose value expression the const resolver cannot reach. Allowlisting the key — the obvious fix — would have been a silent contract loss: the allowlist is checked *before* the pin list, so the key would have vanished from the generated env entirely, and it is not a `REQUIRED_SPAWN_KEYS` member, so nothing would have hard-failed. Instead the 3p-only branch is located by content and its inner keys are classified by name without resolving their values, which is what the branch already meant. A brand-new key there still hard-fails. **`CLAUDE_PREVIEW_CLASSIFIER_FLOOR` is now inert on the shipping agent** — recorded, not changed. Agent `2.1.246` renamed the flag it reads to `CLAUDE_CHROME_CLASSIFIER_FLOOR` (and its consumer field `previewClassifierFloorEnabled` → `chromeClassifierFloorEnabled`) while Desktop still sets only the old name, so the classifier floor now falls through to its GrowthBook default. The key stays pinned: the baseline records what the spawn constructs, and a Desktop-side rename must surface as a diff line rather than as silence. Nothing in the harness reads it behaviourally. Together with the cache-TTL keys above this is the same lesson pointing both ways — Desktop and the agent version the spawn env independently, so "Desktop sets X" and "the agent reads X" are separately-dated claims. Also found in the same pass and recorded in [docs/fidelity-gaps.md](./docs/fidelity-gaps.md), with no harness surface: the deliberately-unmodeled remote device-tool family gained `device_fs` and `device_request_delete_permission` plus a folder-access announce mode — the Desktop half of the six `cowork_*` risk categories that had appeared in agent `2.1.237`'s auto-mode rubric. Also verified unchanged against the retained previous asar: the Cowork system prompt (the retained raw files for 1.32885.1 through 1.37937.1 are byte-identical on disk), both sub-agent appends, `tools[]`, the `canUseTool` chain, the mount modes, the egress contract, and the VM rootfs image. - **All three committed example cassettes re-recorded against this baseline** — `example-pdf-skill` (`container`), `example-multiselect-gate` (`protocol`) and `hostloop-computer-links` (`hostloop`). The container one shows no behavioural change (transcript wording only). `verify-cassettes` is clean, and the recorded MCP inventory is the Cowork lane's own servers (`cowork`, `plugins`, `skills`, `workspace`) — no host inventory reached the fixtures, checked independently of the built-in scan because the 2026-08-04 leak hid from a `mcp__` grep and surfaced only through NAME fields. - **Live end-to-end pass re-run against this baseline.** `npm run test:live` — **4 suites, 19 assertions, 19 green, 0 skipped** — across `protocol`, `container` and `hostloop`, on agent `2.1.246`. Every `describe` in that lane is `skipIf`-gated on Docker, the staged-binary version and the token, so a gated case reports as skipped rather than passing vacuously; zero skips means the whole population executed. `DESIGN.md`'s scope note is re-stamped accordingly and now records that no baseline is unverified for want of a live run. Not claimed: the `boundary-check` sandbox proof and the example-scenario suite were part of the previous stamp and were not run here. ### Added - **`question_context: {when_question?, matches}` — assert what a gate actually put in front of the user.** A regex tested against a gate's founder-visible payload FIELD BY FIELD — the question label, every option **label**, and every option **description**, each as a separate string. Matching per field rather than over one joined blob is deliberate and load-bearing: a pattern cannot straddle two fields, so `invoicing[\s\S]*Audit logging` will not match by stitching one option's description to the next option's label — a "sentence" nobody was shown. The neighbouring transcript keys' docs teach `[\s\S]` for spanning turns, so that is the habit an author brings here. `matches` is required NON-EMPTY: an empty pattern compiles to `//i` and would green any run that fired a gate at all. `question_asked` matches question text only and `question_options` compares labels only, so a sentence the model delivered inside an option's `description` was invisible to every assertion key — a false-negative generator for any skill that puts context there, which the tool's own schema invites. Measured on a consumer's paid run: a producer-authored sentence arrived verbatim in the question, reworded inside it, and relocated into the proceed option's `description` across three runs of one scenario; the third redded a lane on a run where the founder had in fact been told. Evidence is the **ask-time** `AskUserQuestion` payload, never a `tool_result` — a skill's producer typically also writes the same sentence into its own gate-state file, so `tool_result_matches` on that phrase grades true whether or not the model ever surfaced it. Unlike `question_options`, omitting `when_question` on a multi-gate run is **not** ambiguous: this key asks whether the text was shown at all. Zero gates recorded fails; unreadable gate evidence fails evidence-unavailable, never vacuously. ### Changed - **`trace --view questions` now renders each gate's offered options — labels AND `description`s** — under an `offered:` block, sub-question-labelled on a bundled gate. It previously printed the question label alone, so the option `description` a skill routinely puts the deciding sentence in was reachable only by hand-reading `events.jsonl`; a reader who found nothing in the view could reasonably conclude the text was never delivered. The payload was always recorded — this was purely a rendering gap, and the same run dir answers the question either way. The row (`--output-format json`) gains `subQuestions[]` carrying the untruncated ask-time options; the text view caps each description at 240 chars, so nothing is lost, only wrapped. This pairs with `question_context`: the view is how you *find* the text, that key is how you *gate* on it. - **The `tool_use` blindness of `transcript_contains`/`_not_contains`/`_matches`/`_not_matches` and `computer_links_resolve`/`_if_present` is now documented and guarded.** `semantic_matches` has carried a ⚠️ spelling out that its corpus excludes every `tool_use` — "a rubric claim about whether a tool was called is unassertable" — while the six keys with the identical blindness said only "the assistant transcript". A consumer wrote a `transcript_matches` against text living in a gate question; it could not have matched at any phrasing, and the recording fail-closed after the spend. The caveat is now a property of an enumerable set (`TOOL_USE_BLIND_KEYS`) enforced across every surface that documents a key — the docs tables, the zod `.describe()` behind `assertions --list` and the generated JSON schema, and the packaged skill reference — so a newly-added blind key cannot ship without it. - **`question_asked`/`question_options`/`question_context` now warn that they match model-authored text.** Gate question text and option labels are composed by the model and reworded run to run. The `choose:` side already documented this (stable leading anchor, 1-based index); the assert side documented it nowhere. Guarded by `MODEL_AUTHORED_TEXT_KEYS`. - **A bad regex in a NESTED assertion field is now caught at load, not after the paid spawn.** The pre-compile pass reached only top-level string keys, so every regex one level down — `artifact_text.matches`, `artifact_text.not_matches`, `path_denied.path_matches`, `skill_tool_used.skill`/`.tool`, `subagent_dispatch_healthy.type`, `subagent_output_contains.match`, `task_status.match`, `question_options.when_question`, and the new `question_context.*` — was first compiled inside the evaluator. All eleven are now validated at load, and `test/nested-regex-leaves.test.ts` reads `assert.ts` and fails if the evaluator compiles a nested leaf the load-time table does not carry, so the gap cannot reopen silently. `lint`'s double-quoted-regex warning also now covers nested `matches:` leaves. - **`diff` with a single positional now names the missing operand** instead of printing bare usage. There is deliberately no one-argument form: `diff` is polymorphic over baselines, run dirs and cassettes, so it would need type dispatch plus a defined source for "the committed version". - **The two cost keys are cross-referenced.** `RunResult.cost.usd` is one invocation's SDK `total_cost_usd`; the critique report's `costUsd.totalUsd` aggregates the task turn, the reflection turn and both evaluator passes. Reading the wrong one returns `undefined` rather than erroring, which reads as "no cost recorded". Kept as two shapes on purpose — collapsing them would destroy the per-phase split. ### Fixed - **Two spawn-contract sentinels were weaker than their names implied; both now bite.** `checkSpawnContractFacts` pinned the `allowedTools[]` built-in head and the built-in→`mcp__` boundary but nothing between the boundary and the closing bracket — so `mcp__plugins__search_connectors` was added to the array and both checks stayed green. The `mcp__` membership is now pinned as a set, and the flag names the added and removed entries instead of reporting that something "moved". (That tool is declared only on the third-party deployment, so the first-party inventory the harness serves is unaffected — but the addition should not have been invisible.) `checkMountModeFacts` asserted each read-only mount with a single `regex.test`, while `uploads`, `.claude/skills` and `.projects/` are each built at **two** sites — the VM-loop mount-set builder and host-loop `computeBashMounts`. Either site satisfied the check, so a one-lane `ro`→`rw` flip — a containment change on exactly one execution tier — passed green. It now compares the site count to the count carrying `mode:"ro"` and names the lane count in the flag. Its fifth fact — the delete-deny resolver `?"rwd":"rw"` — had the same shape and the same two-lane reality (it went 1 site to 2 in this release) and now guards a floor on that count: a lane losing the resolver flags, a lane gaining one does not. - **All eight asar sentinels now carry a committed mutation case.** They are green on the previous release's asar too, so a green proves nothing on its own unless the checker is known to bite; five of them (`checkCodeTripwires`, `checkWebFetchFacts`, `checkEgressContractFacts`, `checkSyspromptMapFacts`, `checkNormalizationSanity`) had no such case. Each new one changes an **inner** character of its anchor, because a suffix rename still satisfies a substring regex — a mutation that cannot fail is not evidence — and asserts that the mutation actually applied. - **`record --dry-run ` no longer announces a WARN as a refusal.** The batch arm labelled every advisory note `⚠ would-refuse (advisory)`, but `cassettePortabilityPreflight` can only ever return `ok`/`warn` — it has no refuse path at all — and `hostInventoryPreflight` returns `warn` whenever the target cassette already exists, which is every re-record corpus sitting at the default path. So the preview told operators the real `record` would refuse runs it would in fact accept, on the one arm whose design principle is that a guess must not gate. The label now follows the verdict kind (`⚠ would-warn (advisory)`), the "ADVISORY, not this run's verdict" footer is unchanged, and exit codes were never affected either way. - **The 3p-branch rule refuses to blank W1.** W1 is the window every modeled first-party key is derived from, so a branch marker appearing there hard-fails instead of blanking; deleting real pinned keys from the derived env with nothing failing is the worse of the two outcomes. - **`record --dry-run` now runs every pre-spend refusal the real record runs, and one refusal moved from after the paid run to before it.** The rehearsal re-implemented the checks by hand, so it drifted: `hostInventoryPreflight` shipped 2026-08-04 and the commit three days later titled *"make `--dry-run` refuse what the real record refuses"* swept in the two checks returning `string | undefined` and missed the one returning a `{kind}` verdict — for 19 days an operator could not discover that refusal without spending. Separately, the slug-collision refusal (*"refusing to overwrite … it belongs to scenario X"*) sat **after** `executeScenario`: you paid for the run and were then refused, though it is a pure function of path + `--force` + the existing cassette's name. Both now run in one shared pre-spend block. Refusals are also uniform now. `promptPolicyRejection` threw while `hostInventoryPreflight` called `fail()`, which `process.exit`s — and the dir-batch loop catches a throw per item but cannot catch an exit, so a host-inventory refusal mid-batch abandoned concurrent runs already paid for. Under `--output-format json` a directory batch carries those advisory verdicts in a `notes[]` array, kept separate from `refusals[]` so automation cannot read a guess as a binding verdict. **On a directory, the path-dependent verdicts are ADVISORY (`⚠ would-refuse`) and do not affect the exit code**, because a directory target takes no `--out`: the preview would have to guess the destination, and a guess must not gate. Measured on a real consumer, gating on that guess would have refused 26 of 27 scenarios the real record accepts. Dry-run a single scenario file with the real flags for a binding answer. `--quiet` suppresses the notes; it never suppresses a refusal. Also new in the batch preview: the duplicate-cassette-path refusal the real batch already had. ### Upgrade impact - **`--allow-host-inventory-fixture` no longer waives a MEASURED host-inventory finding.** It was one flag doing two jobs: bypassing the pre-flight refusal (a precondition the operator cannot check — "use only when the session has no personal MCP servers or plugins") *and* downgrading the write-time scan's refusal to a warning. So an operator who passed it to get past the undecidable precondition also switched off the scan that would have caught a real leak. It is now the pre-flight bypass only; the finished recording is still scanned, and a finding still refuses the write and quarantines the recording. Writing a flagged recording needs the new, narrower `--allow-host-inventory-findings`. **A batch recorder that passes the old flag on a new-fixture path will now abort on a genuine finding where it previously warned and wrote.** A `--dry-run` that reports what *would* be captured was considered and declined: the inventory does not exist until the agent has run, so a preview would either re-implement the scanner against a hypothetical (a second oracle free to disagree with the real one) or require the spend it was meant to avoid. Reasoning is in [docs/cassette.md](./docs/cassette.md). This does not break a covered surface ([SPEC.md §12](./SPEC.md#12-versioning--the-10-compatibility-contract)): no command or flag is removed and no exit-code meaning changes — one flag's consent narrows, and the capability it shed is reachable through the new one. So it ships in a minor. ### Documentation Five gaps found by asking a consumer which harness properties actually changed an outcome on a real working day, then checking whether the docs said so. Four of the five were documented only as features, never as the failure they prevent — the sentence a reader needs to recognise their own situation. - **The blocking gate is now stated as a blocker.** `AskUserQuestion` *blocks*: it is a question to a human and `claude -p` has no human, so a gated skill under a plain CLI run stalls or never reaches the code behind the gate. That made half the skill untestable, not merely awkward to test — the README had only "untestable headless unless something answers it", buried as the last of two afterthought bullets. - **"Assert on the run, not the output"** — a new README section naming the class of claim the harness exists for (`subagent_tool_absent`, `dispatch_count_max`, `no_delete_in_outputs`, `subagent_file_write`) and why no output diff can reach it: a correct run and one that quietly handed a restricted sub-agent shell access produce byte-identical files. `subagent_tool_absent` did not appear in the README at all. - **The raw-`events.jsonl` escape hatch is documented**, with verified `jq` recipes, in [docs/debugging.md](./docs/debugging.md). Every documented route into the event log went through `trace`, whose views are a digest — so the run dir's *evidence* surface is wider than any view's *observation* surface, and wider still than the assertion catalog. Concluding "it never happened" from a view that doesn't render the field is a false negative, and the doc now says so and shows the read. - **Sub-agent delivery has a route.** The tier-qualified outputs contract — the reason a hand-off path that works on one loop lands in sandbox scratch on the other — was correctly documented in [docs/subagents.md](./docs/subagents.md) but filed under "read on demand", reachable only by someone who already knew the answer. It now has a "Common tasks" row keyed to the symptom. - **Replay's cost claim carries a number.** "Zero spend" is the price; the wall-clock is what makes an always-on per-PR gate obviously affordable, and no doc stated it (well under a second per cassette). - **The project's provenance is stated on every surface the framing travels to.** `README.md` (which renders on the npm page), `llms.txt`, both `.claude-plugin/marketplace.json` descriptions and `SKILL.md` now say the same thing: an independent project, not affiliated with, endorsed by, or supported by Anthropic; it bundles no Anthropic code; it is not Cowork. `SKILL.md` additionally tells the agent to say so when a user asks what it is. Nothing enforces the four staying in step, so an edit can still drop it from one of them unnoticed. ## [2.2.0] — 2026-08-25 ### Upgrade impact Two behaviour changes can turn a previously-green run red. Neither breaks a covered surface ([SPEC.md §12](./SPEC.md#12-versioning--the-10-compatibility-contract)) — both make an assertion report what it always documented — so they ship in a minor: - **`no_scratchpad_leak` at `container` can now FAIL.** It was measuring containment against a root in a different path space, so every presented file classified `leaked: false` and the check passed vacuously. A scenario whose skill genuinely leaves a presented file in the scratchpad will now red — that is the leak the key exists to catch. - **`baseline: desktop-1.11847.5` is now refused at `container`/`hostloop`/`microvm`.** It carries no `spawn` block, so those tiers cannot reproduce Cowork's toolset — a run on it launched an agent with no file or bash tools and still reported a verdict. Use a `sync`-recorded baseline, or `fidelity: protocol`. ### Fixed - **`present_files_called` no longer reports "the tool was never called" about a run that called it, and a hostloop delivery scenario can be recorded with a host-path redaction policy at last.** The assertion read presence off `RunResult.presentedFiles`, which is a *classification* of each presented path (scratchpad? promoted? leaked?) and requires an absolute path to compute. At `hostloop` a presented path is a real host path, so the shipped redaction policy rewrites it to `[REDACTED:local-path:]/mnt/outputs/report.html` — correct, documented, and deliberately ordered so the mount tail survives — and the classifier then drops every entry as un-normalizable. The list came back empty and the assertion stated, as fact, that the tool had never been called. Because `record` replays the base and redacted cassettes and refuses to write when the verdict differs, this was not merely a wrong message: **no cassette asserting `present_files_called` could be recorded at that tier at all**, so the assertion had never executed on the replay lane. The refusal was right — the redacted cassette genuinely could not support the assert — but the defect it was reporting was in the harness, not in the recording. Presence now comes from `RunResult.presentFilesCalls`, a new count of the `present_files` invocations that carried a well-formed `file_path`, taken from the tool_use input's shape and never from a path's content, so redaction cannot alter it. Classification is untouched: `presentedFiles` still drops what it cannot resolve, and `no_scratchpad_leak` still reads it. A run recorded before the field falls back to the old `presentedFiles`-non-empty test, so no existing green changes. A run whose every `present_files` call carried an unusable path now reports **cannot verify** rather than "never called" — the tool *was* invoked, and the harness already knew it. (The malformed count is deliberately kept out of that message: the record self-check normalizes `[REDACTED…]` tokens out of failing messages but not digits, so an interpolated count that differed between the two replays would refuse a cassette that is otherwise fine to write.) Pinned as an invariant ([docs/invariants.md](./docs/invariants.md)) with the end-to-end record self-check as its test anchor — the case that could not be recorded, and so had never run in CI. - **Guest paths are built from the tree the harness stages, not from a baseline's recorded mount layout.** `resolveMounts` returned `mountLayout.mntRoot` verbatim — or, when that field was absent and the recorded `sessionRoot` already ended in `/mnt`, the session root itself. But the staged tree is always `/mnt`: `stageWorkspace` creates it there and `dockerRunArgv` nests its read-only binds there. On a baseline recording anything else, `--plugin-dir` therefore pointed one directory **above** the staged plugin tree, so the plugin under test never loaded. `mntRoot` is now derived from the session root, and a recorded layout the harness cannot stage is reported as a fidelity divergence at spawn instead of silently composing a path no stager creates. Guest paths now anchor on `sessionRoot` — the bind target — rather than `cwd`, which is only where the agent's process starts (production's own working directory is a folder mount or `outputs`, so the two are not interchangeable even though every synced baseline records them equal). `dockerRunArgv` takes an explicit `agentCwd` for `-w`. Two more derivations of the same rule are gone: `prompt.ts` had a private `/sessions/` +`/mnt` literal (so the prompt could describe a tree the runtimes had not staged), and **microvm** read the agent's root from the baseline when lima structurally mounts it at `/sessions/` — which put `CLAUDE_CONFIG_DIR` and `--mcp-config` at paths nothing stages. A baseline recording a cwd that tier cannot honour is now **refused**, not warned about: the guest `cd` would otherwise succeed at the wrong directory. - **A baseline with no `spawn` block is refused at the sandbox tiers.** That block carries the tool set, pre-approvals, effort default and config-dir location, and the `?? []` fallbacks meant a run would launch an agent with **no Read/Write/Bash/Skill/Task at all** and still report a verdict. `fidelity: protocol` builds its own argv and is unaffected. - **`no_scratchpad_leak` can see a container leak again — the session root was in the wrong path space.** The root that `presentedFiles`' promoted/leaked classification is measured from was derived by the caller as `/work/session`, a HOST path, and handed to every non-`protocol` tier. But the path space the agent reports in is per-tier: at `container` (the default) it runs inside the sandbox and reports `/sessions//…`, and only at `hostloop` does it run natively and report host paths. Measured against a host root, no VM path is ever inside the root, so every presented file classified `leaked: false` — including the handler's copy-failure branch, which returns the source path unchanged when a file is blocked-extension, a directory, or absent. `no_scratchpad_leak` evaluates at `container` and nowhere else, so the assertion that exists to catch that leak could not catch it, and `verdict.ts`'s delivery check read the same `leaked: false` as a successful delivery. Each runtime now reports the session root it actually launched the agent with, and the run consumes that instead of deriving a second one — the two can no longer drift into different spaces. `chat` sets it on both serving tiers as well; it never did, so a hostloop chat's `presentedFiles` was inverted in its result file. `protocol` and `microvm` serve no `present_files` and keep the cwd fallback. Independently, the classifier now fails CLOSED on a space mismatch: if the agent's cwd is not at or inside the session root, the presented batch counts as malformed (`no_scratchpad_leak` → cannot verify) rather than being graded against a root it cannot be compared to. `leaked: true` is not derivable in that state either, and a `leaked: false` verdict there is exactly the vacuous pass the key exists to prevent. ### Added - **First live coverage for `present_files_called` / `no_scratchpad_leak`.** No scenario in the repo asserted either key, which is how a session root in the wrong path space could record `leaked: false` for every presented file without anything noticing. `e2e/scenarios/smoke-present-files.yaml` writes a file OUTSIDE `mnt/` and delivers it, so the promotion is real and the pair is non-vacuous; it runs in CI's live e2e loop. Measured on a live container run: `presentFilesCalls: 1`, promoted `true`, leaked `false`. - **`RunResult.presentFilesCalls`** — the count of `present_files` invocations that carried a well-formed `file_path`, in `result.json` and [schema/run-result.json](./schema/run-result.json). Content-class, so a replay re-drive reproduces it; read by `run`, `replay` and `verify-run` alike, and absent (not `0`) on a result written before this release, which is what the assertion's fallback distinguishes. Use it to answer "did the agent deliver anything?" from a result file without interpreting `presentedFiles`' promoted/leaked classification. ## [2.1.0] — 2026-08-24 ### Changed - **`rehash` leads with the split, and PARTIAL success has its own exit code (`4`).** The summary used to print last, after every per-file line had scrolled past — and those two counts *are* the decision: commit what migrated and budget a re-record for the rest, versus nothing here is salvageable. It now prints first, with the per-file lines as the detail behind it. **`4 migrated, 18 failed` and `0 migrated, 22 failed` both exited `1`**, which made a shell consumer unable to tell apart two situations demanding opposite responses. The JSON envelope always carried the split as `migrated`/`skipped`/`errors`; a bare terminal run did not. `rehash` now exits `0` (all migrated, or nothing needed migrating) / **`4`** (partial) / `1` (nothing migrated and at least one could not) / `2` (usage). **This is a behaviour change for anyone branching on `rehash`'s exit code** — a script testing `rc == 1` for "something failed" will miss the partial case, though `rc != 0` is unaffected. It ships in a minor deliberately: `rehash`'s codes were documented **nowhere** — zero mentions in its `--help`, absent from SPEC §11 — so there was no published contract to break, and a consumer on `rc == 1` was relying on observed behaviour. They are now documented in both places. `4` rather than `3` because the code space is per-command and `3`'s "could not verify" meaning is load-bearing on `verify-cassettes`. - **The batch cost estimate now reports its basis instead of claiming authority.** `estimatedCostUsd` is `sum(max(local run history))` — a max over whatever *this machine* has run. The line already qualified the partially-priced case with `— LOWER BOUND`, but the fully-priced case said `(all N scenario(s) priced from prior runs)`, which is an active claim of completeness and was the one case that said nothing qualifying. At a new baseline or a new agent binary the history describes a materially different configuration, so the estimate can **under**-predict exactly when it is most consulted — a consumer wrote "that is the ceiling, not the scope" into a plan off this line and had to retract it. The line now carries `basis: N prior run(s) on THIS machine, thinnest scenario has M; a max over that history, NOT a bound`, and the JSON payload gains `estimateBasis` (`{source, pricedRuns, thinnestScenarioRuns}`). `thinnest` is the useful half: a scenario with one prior run contributes a single sample, not a worst case. Wired through `pricedRunCount`, which had been exported and doc-commented *"for messages that report their own basis"* with zero callers. - **Pre-epoch cassettes: we could report ordinary content drift, and chose not to.** When a cassette recorded before the 2.0.0 hash-format epoch is read, `rehash` recomputes the **legacy** digest over the current tree and compares it to the legacy digest in the cassette. On a mismatch that is a positive determination of ordinary content drift — strictly more informative than `unverifiable-skill`, and the same determination 1.25.0 reported as warn-only `skill` drift. Replay does not report it, and that is a decision rather than a limit. Reporting it would require keeping a fold of the retired hash algorithm alive in the replay path — the most-run lane — permanently, to soften one release's migration; the population it would help shrinks with every re-record. The runtime cost would be nil (both digests fold from one tree walk); the cost is code that could never be deleted. **"We can compute this and chose not to report it, so the legacy fold can die" is a different claim from "this cannot be known", and the earlier phrasing implied the latter.** The remedy for a pre-epoch cassette is `rehash` where it can prove content unchanged, and a re-record where it cannot. ### Fixed - **The fast test lane had no global timeout, so 93 subprocess-spawning test files inherited vitest's 5s default.** They measure 167-888ms locally — a fine margin until you remember the lane runs 344 files in parallel across every core, and a CI runner is ~3x slower again. That is how an 888ms test crosses 5s; it cost two red CI runs on unrelated PRs before anyone looked at the failure rather than re-running it. `vitest.config.ts` now sets `testTimeout: 30_000` — ~34x the slowest measured non-e2e case, while a genuine hang still fails ~6x faster than in the live lane (which sets 180s). Per-test values still win. - **Redaction pattern ORDER is load-bearing, and now says so — plus a warning when it is wrong.** Patterns apply in sequence over the accumulating output, so a bare catch-all placed ahead of a lookahead-anchored rule for the same prefix matches first and eats the `/mnt/` tail the lookahead exists to preserve. The shipped policy depends on that order: with it, a run-dir path redacts to `[REDACTED:local-path:…]/mnt/outputs/report.md` and still resolves; without it the whole path is consumed and `normalizeHostShapedForReplay` returns `null` — **every `computer://` structural-marker resolution silently stops working, with no error and no finding.** `loadRedactionPolicy` now warns, naming both pattern indices, when a policy is in the hazardous order. Detection is deliberately conservative — it fires only when a later pattern's source is exactly an earlier one's plus a trailing lookahead (modulo lazy quantifiers) — because regex subsumption is undecidable in general and a false positive would train authors to ignore the warning. The remainder is matched by **shape**, never by parsing the lookahead's body. A first cut used `\(\?=[^()]*\)`, whose `[^()]*` silently skipped every lookahead containing a group — so `(?=/mnt(?:/|$|[\s"'\\)\]]))`, the natural way to write "slash, end, or delimiter" and arguably more correct than a bare `(?=/mnt/)`, went unflagged while being just as dangerous. Caught by a consumer running it against their own policy, which is now a regression fixture. Not looking inside also sidesteps escape- and char-class-awareness, since that policy carries an escaped `\)` inside a character class. `docs/cassette.md` states the requirement next to the existing "stop before `/mnt/`" guidance, which had the shape of the rule but not the ordering half. The new test pins the runtime consequence, not just the detector: a reorder must make the link fail to normalize AND be flagged, so the syntactic check cannot drift away from what it is standing in for. - **The copy-pasteable Action steps now pin `version: "^2"`, and a guard requires it.** Bounding every published npm floor last release fixed the *form* of a floor (`>=1.11.0` reads as a bound and silently means "and every future major too") but removed the input from the recipes rather than correcting it — so the shipped snippets carried no `version:` at all and fell back to the input's `latest` default. That reproduced the exact footgun `action.yml`'s own description warns about two lines earlier: a CLI major reaches a workflow the moment it is promoted, even though the `uses:` ref never changed. `^2` was not among the alternatives weighed at the time, and it is the form `action.yml` itself recommends: it holds the major, needs no patch number to remember, and only wants a human decision at the next major bump. **Five** steps were unpinned, not the three in the CI recipe — `README.md` carries two more. `action-docs-sync` now requires every copy-pasteable step (a `uses:` line inside a fenced block with a `with:`) to pin `^`; inline prose mentions are excluded, since there is nothing to pin. Verified by mutation: dropping one `version:`, regressing a pin to `^1`, and bumping the package major each fail. The guard also asserts it found the steps at all, because a parser that matches nothing passes every assertion after it. Guarding a floor's FORM does not guarantee a floor is PRESENT — this pins the behaviour instead. - **The `sessionFingerprint` field set is now stated completely, and a guard discovers the sites that state it.** The hash covers eight session fields; every place that enumerated them named six or fewer. `web_fetch` was missing everywhere, `agent_env` was missing everywhere, and `docs/invariants.md` also omitted `skills`. Fourteen sites carried the claim while the working assumption was three: **twelve enumerated the set** — four in prose, two in the current cassette schema, six in the retained v9-v11 schemas — and **two denied it existed at all**. `SPEC.md` and `docs/scenario.md` both said the session is "not drift-checked or fingerprinted". `model` genuinely is not hashed; connected folders and plugin/skill/MCP discovery are, which is the half a reader would have trusted. The `verify-cassettes` staleness message — the only enumeration a user ever sees — omitted `projects`, and `docs/cassette.md` quoted it with `projects` present. Both are fixed and now pinned to each other by test, so the doc cannot drift from the string again. New **invariant 14** in `check:versions` derives the field set from `buildSessionFingerprint`'s shape and **discovers** the enumeration sites rather than reading a list, so a new one is covered the day it lands. Two deliberate limitations are recorded as tests rather than left to look covered: it cannot see a flat denial (there is no enumeration to check — the coverage floor is what notices), and it cannot see a deleted "only when set" qualifier. `schema/cassette.v{9,10,11}.json` are allowlisted as frozen history: a retained schema documents the format as it shipped, and rewriting its description would make it describe a shape its own consumers never saw. Verified by mutation: run against the previous revision the guard flags all six then-existing sites with the correct missing fields; renaming the shape literal makes it error rather than silently pass; a ninth field invalidates a previously-complete site; and a whole-file token check — which would have passed today and then never failed again — is rejected in favour of span-scoped matching. - **The documented Action ref is now `@v2`, not `@main`** — 7 references across `README.md`, `SKILL.md` and `ci-recipe.md`. `@main` was right when it was written: no alias tag had ever been published, so naming one would have sent a copy-pasting reader to a `uses:` that 404s, and the guard's own note said to revisit "once 1.0.0 ships". Two things had to be true first, and now are — `v2`/`v2.0` point at a real release, and `release.yml` moves them on every stable release rather than leaving it to a checklist. Recommending a floating tag nobody remembers to move is worse than recommending `@main`; that was the actual situation while `v1` sat at 1.24.0. `action-docs-sync` now derives the expected ref from `package.json`'s major instead of hardcoding it, so the next major forces these docs to move with it rather than silently pointing a reader at the previous line. `@main` is deliberately no longer accepted there: permitting both would let the recommendation drift back with nothing noticing. Verified by mutation — regressing one reference to `@main` fails, and setting the package version to 3.0.0 fails all three files. **This changes nothing about which CLI you get.** The ref selects the Action; the CLI still comes from the `version:` input, which still defaults to `latest`. `@v2` looks more like a version pin than `@main` did, so that distinction matters more now, not less — it is spelled out in `README.md`'s Action section and in `action.yml`'s own input description. - **The CI recipe no longer teaches a bare version floor.** It carried `version: ">=1.11.0"` — which reads as "at least 1.11.0" and silently means "and every future major too", so a copy-paster gets the next major with no say in it. It was **not** broken today (`--min-severity` still exists in 2.x, and `lint` reads no cassette, so 2.0.0's hash-format epoch never applied to that step) — the defect was latent and in the FORM. The bare floor was first dropped rather than corrected — `^1.11.0` would have frozen every new copy-paster on the previous major, and `^2.0.1` needs remembering at each release — so the guidance moved to prose. **That went one step too far, and the same release corrects it** (see the `version: "^2"` entry above): dropping the input entirely falls back to `action.yml`'s `latest` default, which is the one remaining unbounded form and the exact footgun the input's own description warns about two lines earlier. `^2` was never among the alternatives weighed at the time, and it is what the recipes now carry. Reach for an exact pin only when you want byte-reproducible CI. [`action.yml`](https://github.com/yaniv-golan/cowork-harness/blob/main/action.yml)'s own description stops offering `>=1.11.0` and `^1.11.0` as interchangeable — they are not, and it had been recommending the unbounded one. `check:versions` invariant 13 now covers the Action's `version:` input, which it could not see before: it keys on `@>=`, and `version: ">=1.11.0"` has no `@` — the same defect in different syntax, with no coverage. Only the **unbounded** floor is rejected; verified against each form, `>=1.11.0 <3`, `^2`, `2.0.1` and `latest` all pass. - **`projects[].from` was missing from two places, and the second was a false green.** A connected project is a host path exactly like a connected folder, and it was: - **not resolved against the session file.** [`docs/session.md`](./docs/session.md) promises, without qualification, that *"relative paths resolve from the session file's own directory"* — and it was true of every path field except this one, which resolved against the **process CWD**. So the same session file mounted different content depending on which directory you invoked from. The doc was right; the resolver had simply skipped the field. - **not part of the session fingerprint.** Swapping which directory is mounted at `.projects/` changed the run's inputs and `verify-cassettes` reported nothing — a false green in the gate whose job is to notice that inputs moved. Folded in on the same **non-empty-only** terms as `agent_env`, so a session with no `projects:` (and one with an explicit `projects: []`) hashes byte-identically to before; only sessions that use the feature move. No committed cassette does. **A cassette recorded before this is reported `unverifiable`, not clean.** Its hash contains nothing about `projects[]`, so it cannot distinguish "the field was never covered" from "the mount changed since record time" — and reporting the mismatch as a benign migration would put the same false green back in the remedy. When everything else matches exactly, `verify-cassettes` says so and asks for a re-record to gain the coverage. `sessionFingerprintDrift` remains `verify-cassettes`-only: none of this can change a `replay` verdict, even under `--strict`. Three enumerations of the covered fields gained `projects` — [`docs/cassette.md`](./docs/cassette.md), [`docs/invariants.md`](./docs/invariants.md) and the shipped skill's `task-recipes.md`. `invariants.md` also described this as a hash of the **resolved** session; it is the **authored, pre-resolution** shape, deliberately, so the digest survives a different checkout — the function's own comment says so, and a resolved hash could never match on another clone. - **The published control-protocol schema rejected five kinds of frame the harness sends and answers.** `schema/protocol.v1.json` described four request subtypes; the harness has always answered **six** — adding `request_user_dialog` and `elicitation`/`side_question` — and it also sends a fail-closed `subtype:"error"` response envelope, whose payload is a *string* under `error` rather than an object under `response`, so a validator that knew only the success envelope rejected every one. Measured against the previous schema: all five representative frames **REJECT**; against the new one, all five accept. Anyone validating real traffic was seeing failures on frames the harness handles correctly. Added as new `oneOf`/`anyOf` branches plus one new top-level response shape — **111 insertions, zero deletions** in the surface baseline, so nothing existing was narrowed and no frame the schema already accepted is affected. Both spellings the parser accepts are admitted (`dialogKind`/`dialog_kind`, `mcp_server_name`/`server`, `message`/`prompt`) rather than guessing which the agent sends. The golden vector pack grew with it, generated from the **real** envelope builders rather than hand-authored lookalikes. The existing lockstep test — every schema definition must be exercised by a vector — caught all five additions immediately, which is what forced those vectors to exist. One of them asserts the error envelope does **not** validate as a success envelope, so the two shapes cannot be quietly conflated later. [`SPEC.md`](./SPEC.md) §12 now states the additive latitude for this surface explicitly. Its silence had read as a prohibition, which is plausibly why three subtypes went undescribed rather than added — while [`docs/protocol.md`](./docs/protocol.md)'s own versioning policy had said all along that an additive variant is a v1 minor note, which is where the dated entry now lives. - **The Marketplace alias tags are moved by the release workflow instead of by remembering.** `v1` sat at 1.24.0 through two releases because moving it was a checklist line. `release.yml`'s last step now points `vX` and `vX.Y` at the release it just published, with two guards a hand-run `git tag -f` skips: a **prerelease** tag moves nothing (the trigger accepts `v1.0.4-rc.1`, and pointing `v1` at an rc would hand every `@v1` consumer a prerelease), and an alias **never moves backwards** — re-releasing an older patch on a line moves `vX.Y` and leaves `vX` alone. Verified by executing the logic against a synthetic tag set rather than by reading it: releasing `v1.20.5` while `v1.25.0` exists correctly skips `v1` and still moves `v1.20`. It runs last, after publish and the GitHub Release, so a failure there cannot half-publish anything. Alongside it, the tags are now correct: **`v2` and `v2.0` created** (they did not exist, so nothing pointed at the 2.x Action), and **`v1` moved 1.24.0 → 1.25.0**. Worth recording what that move did and did not fix: the Action's whole surface — `action.yml` plus the `render.js` it loads — is **byte-identical from 1.24.0 through 2.0.1** apart from three lines of input *description*. So a stale `v1` was a promise the repo had stopped keeping, not a functional gap, and the one public `@v1` consumer pins `version:` on every step and was never exposed to the `latest` default at all. ### Documentation - **The invariants index said `check-versions.ts` has "no dedicated vitest file — it's a standalone script, not a unit-testable module boundary".** Three exist, for the invariants whose logic is an exported pure function: `check-cassette-version-claims`, `check-fingerprint-field-claims` and `check-design-scope-note`. The claim had already been stale before this release. - **The `uses:` ref pins the Action; the `version:` input pins the CLI — and only the second one holds a major.** Both are documented as if pinning `@v1` bounded what you install. It does not: they move independently, and `version:` defaults to `latest`, so promoting a CLI major reaches a workflow whose `uses:` ref has not changed in months. Measured at the time of writing — `v1` points at **1.24.0** and has never been moved, yet an `@v1` workflow with no `version:` input installs **2.x**. `README.md`, `action.yml` (the text GitHub Marketplace renders) and `RELEASING.md`'s alias-tag step now say so, and name the fix: pin the **input** (`version: ^2`), not the ref. Crossing 1.x → 2.x this way means the hash-format epoch, so pre-v12 cassettes need `cowork-harness rehash `. `RELEASING.md`'s "move the major/minor tags" step additionally records what moving `vX` does *not* do, since that step reads as the thing that controls consumer upgrades and is not. ## [2.0.1] — 2026-08-23 ### Added - **`lint` warns when `prompt:` names a slash command anywhere but the start** (⚠ `WARN [prompt-slash-not-leading]`). Writing `/` into a scenario prompt is what an author reaches for when a skill will not auto-trigger, and it works — the harness sends `prompt:` verbatim and the agent expands a **leading** slash before the model is called. Named mid-sentence ("review the deck with `/deck-review`") it is never expanded: the text reaches the model as prose, which may then pick the `Skill` tool on its own — the same auto-trigger path the slash was meant to bypass. The scenario still runs and can still pass, so it silently stops testing what it reads as testing. Paths, URLs, filenames and dates (`/mnt/uploads/x`, `https://…`, `/deck.pdf`, `8/22`) do not trigger it. ### Fixed - **Every published version floor was unbounded, so it resolved across a major.** The skill and the CI recipes advertised `cowork-harness@>=X.Y.Z`; `>=` does not stop at a major boundary — measured, `cowork-harness@>=1.0.0` matches 2.0.0 — so a consumer following the documented floor was handed the next **breaking** release automatically. That is not hypothetical: it is how `@>=2.0.0` resolved the deprecated 2.0.0. All 12 live floors across `README.md`, `SKILL.md`, `ci-recipe.md` and `examples/replays/README.md` are now `@^X.Y.Z`, which resolves the newest release **within the same major**, and the docs that teach the pattern teach the bounded form. `check:versions` gains invariant 13, which is what keeps it that way: **no shipped doc may advertise `@>=` with a real version**, and every doc carrying a live floor must agree with `SKILL.md`'s. It scans the whole shipped-doc corpus rather than a hand-listed set — `ci-recipe.md` and `examples/replays/README.md` had drifted out of the previous checks precisely by not being on such a list. A doc that deliberately cites an OLD floor to illustrate a past feature gate opts out of the equality rule with an inline `floor-historical` marker; it does **not** opt out of the `>=` rule, since the form is the defect whatever the version. - **Twenty authored objects silently STRIPPED unknown keys instead of rejecting them** (11 in `src/types.ts`, 9 in `src/session.ts`, all `z.object` → `z.strictObject`). For an authored document a typo did not fail — it changed what you wrote: `{ from: "/tmp/x", mdoe: "r" }` parsed to `{ from: "/tmp/x", mode: "rw" }`, turning a **read-only mount writable**. In the assertion layer a misspelled field on `path_denied` stripped to `{}`, which matches *any* path denial, greening a run that should have failed. The sweep reaches objects behind `z.array` (`Folder`, `Project`) that a top-level scan misses, and is guarded by a walk of the zod tree — the generated JSON Schema cannot express the difference (`z.object` and `z.strictObject` both emit `additionalProperties: false`), so a schema-based assertion there is a test that cannot fail. **Note the compatibility edge:** a document carrying such a typo loaded before and now fails at load. The published schema is unchanged (byte-identical); this tightens the loader. - **A connected folder's host path could reach a committed cassette.** `folderPrefixMap[].from` holds the record-time host path (`/Users//…`); neither the privacy scanner nor the redactor read the field, and `redactCassette` passed it through in its `...cassette` spread — so `verify-cassettes` reported `ok: true` with `privacyScanned: true` over a real username and directory layout. Fixed at all three sites: the scan, the redactor, and `readCassetteForScan`'s malformed-document projection — that last one is the trap, since a fixture built only from a valid cassette passes with half the fix missing. **The committed example was re-redacted in the same change** (`examples/replays/example-pdf-skill.cassette.json` — `"/Users/…/examples/data/project"` → `"/redacted/examples/data/project"`), so the path that was already public in this repo is scrubbed rather than merely blocked for future recordings. - **`--answer-policy` turned a one-character typo into zero rules, silently.** A document keyed `answer:` instead of `answers:` hit `?? []`, and an empty array passes an `Array.isArray` check — so the policy loaded as "no rules" and the run spent tokens before whiffing on the first gate. The parser now distinguishes a missing `answers` key from an empty list and names the top-level keys it actually found. - **A record-time warning named the wrong assertions.** When a secret triggers whole-field marker replacement, the warning claimed `artifact_json`/`user_visible_artifact` "will fail at replay". `user_visible_artifact` and `file_exists` check location, not content, and still **pass** (the marker is written with a recomputed `sha256`); only the body-reading keys fail. An author could read a passing visibility assertion as proof the scrubbed content survived. Corrected in the warning and in [`docs/cassette.md`](./docs/cassette.md) together — one claim in two places. - **A release no longer becomes every unpinned consumer's default install the moment CI goes green.** `npm publish` with no `--tag` writes `latest`, which is how 2.0.0 — a breaking hash-format epoch plus a flagship replay that exited 1 from an npm install — reached everyone with no human in between, and had to be rolled back to 1.25.0 by hand. CI now publishes with `--tag next`; the version is fully published and installable as `cowork-harness@next` or by exact version, and promoting it to `latest` is a documented [`RELEASING.md`](./RELEASING.md) step that needs a 2FA challenge, which is the point. - **The flagship zero-token replay now works from an npm install.** `README.md` and [`examples/replays/README.md`](./examples/replays/README.md) tell a new reader that the first thing to run is `cowork-harness replay examples/replays/example-pdf-skill.cassette.json`. From an npm install that exited 1: the cassette resolves `../sessions/default.yaml`, `../scenarios/…` and `../skills/my-pdf-skill`, and `package.json` `files[]` shipped only `examples/replays`. A 2.0.0 regression — before the hash-format epoch, unverifiable staleness warned and exited 0. `files[]` now also ships `examples/sessions`, `examples/skills`, `examples/scenarios` and `examples/data`, and a guard reads the packed file list and derives its requirements from the cassette itself (session, `scenarioSource`, every hashed `fileSig`), so a re-record cannot quietly outrun it. Note that `replay --strict` from an extracted tarball still reports the `format`-class `recorded in 'git' file-set mode, verifying in 'raw'`: a tarball is not a git work tree, so the file-set boundary differs from the one the cassette was recorded under. That is honest, not a packaging defect. - **Seven statements about what a global install ships were left stale by that packaging change**, five of them in `README.md` — including a "What ships" table row marking the runnable worked examples ✗ for npm, a callout saying `run examples/scenarios/…` "errors with a missing file", and two *(source checkout only — not shipped in the npm package)* parentheticals in [`docs/cassette.md`](./docs/cassette.md) and [`docs/discovery.md`](./docs/discovery.md) against files that now ship. Measured from an extracted tarball: all eight published example scenarios resolve their session and every skill/plugin root they stage, and `lint examples/scenarios/` is clean. What genuinely does not ship is `examples/matrices/`, `examples/answer-policies/` and `examples/probes/`, and the corrected prose says so. A `files[]` edit and the prose describing it had no mechanical link; a guard now resolves every shipped scenario's references against the packed file list, so the next such edit fails rather than quietly turning three pages into fiction. - **Nine relative links in shipped documentation pointed at files npm does not publish.** `./action.yml`, `.github/workflows/ci.yml` (twice), three `src/**` implementation pointers in [`docs/decider-dir.md`](./docs/decider-dir.md) and [`docs/run-status.md`](./docs/run-status.md), and two "runnable copy" pointers in [`docs/scenario.md`](./docs/scenario.md). All nine resolve in a git checkout — which is why nothing caught them — and all nine were dead from `npm i cowork-harness`. They are now `blob/main` links, the convention the companion skill's references already use for the same reason. A guard now reads the packed file list from `npm pack --dry-run --json`, extracts every link from every shipped Markdown file, and resolves each one against it; it also checks that every target it extracted exists in a source checkout, so a regex that starts matching prose fails rather than inflating the pass count. - **`pytest` from the repo root collected the paid `cowork` lane.** `addopts = "-m 'not cowork'"` lived only in `python/pyproject.toml`, and pytest reads the config at the rootdir for the invocation — so a bare `pytest` from the repo root read none of it and selected the three `@pytest.mark.cowork` tests, each of which spawns node, Docker and a real model. A root `pytest.ini` fixes that invocation. - **The `cowork` lane is now opt-in from the module, not just from config.** INI config does not travel with an installed helper: a consumer's `pytest` reads *their* rootdir, so `addopts` protects nobody downstream — and it will protect nobody here either once the helper ships as a `pytest11` plugin. `cowork_harness` now carries the rule itself: a collection hook skips `cowork`-marked tests, and the `cowork` fixture refuses to build a runner, unless the run asked for the lane (`-m` mentioning `cowork`, or the new `COWORK_HARNESS_PYTEST_LANE=1`). The two guards are not redundant — the hook keys on the marker, so a test that takes the fixture without wearing `@pytest.mark.cowork` reaches the fixture guard and nothing else. Selecting a lane test some other way (`-m fast`, a bare node id) is deliberately not opt-in; the skip reason names both switches. `pytest -m cowork` and `pytest -m 'not cowork'` behave exactly as before. - **Three present-tense claims about the cassette format were stale at `CASSETTE_VERSION` 12.** `task-recipes.md` — the page a skill author reads when they open a cassette — linked `schema/cassette.v11.json` and called 11 "current max", describing a version regime (`lane: remote` stamps 11, everything else 10) that the hash-format epoch had already replaced. `SPEC.md` said `schema/cassette.v9.json` and `v10` were "retained alongside v11", which both understated the retained set and re-stated 11 as the top. Corrected, and `check:versions` gained invariant 12: SPEC's max, read floor and retained-range sentences and task-recipes' schema pointer and "current max: N" are now checked against `CASSETTE_VERSION`, `MIN_SUPPORTED_CASSETTE_VERSION` and the `schema/cassette.v*.json` files on disk, and no shipped page may link a schema file that is not there. Bumping `CASSETTE_VERSION` in a scratch tree now fails the check naming all four surfaces. It guards **current** claims only. `docs/scenario.md` and `docs/cassette.md` explain the v10-vs-v11 `lane: remote` regime at length and are correct history; `CHANGELOG.md` is nothing but history. A guard that flagged those would train the next author to route around it. The retained set is stated as a range rather than a list precisely so it cannot go stale by omission the way the old sentence did — and the check refuses the range form outright if `schema/` ever stops being contiguous. - **`schema/scenario.schema.json` said nothing about its own scope, so validating against it read as "this will run".** It mirrors the two mutually-exclusive delete-assertion rules and nothing else, which means an editor or a CI step that checks a scenario against it alone greens files the harness refuses. Its `description` now says so and names where behavioural validation actually lives. Measured, because the answer is not one command: a matcher-less `answers:` entry (`{}`) passes `lint` **clean** and is refused by the loader (`record --dry-run`, exit 2), while `lane: remote` with a delivery-shaped assertion is caught by `lint` (`lane-remote-incompatible-key`, exit 1). Neither tool alone covers both, so the text points at both. Tests pin the gap from both sides — mirroring one of those rules in later, or dropping the one that IS mirrored, fails and forces the description to be rewritten. - **`RELEASING.md`'s tarball checklist told the releaser the companion skill "ships via the marketplace, not npm".** It ships on both: `package.json` `files[]` publishes `SKILL.md`, `references/` and the bundled `scenario.py` + `assertion-keys.json` — 26 files under `.claude/` in the packed tarball. The marketplace install is the NARROWER one, materializing only `.claude/skills/cowork-harness/**`. Since the checklist item exists to make a releaser confirm what is in the tarball, it was pointing at the wrong expectation at exactly the wrong moment. - **Four overclaims that a prospective user reads while deciding whether to trust the tool.** Each was checked against primary evidence rather than against the doc that repeated it. - **Egress parity was stated as identity, in five places.** `DESIGN.md` called the default allowlist "captured from the live asar"; `README.md` called it "the **synced** allowlist" and the fidelity "allowlist-exact"; `README.md` and `docs/boundary.md` said domain allow/deny "matches Cowork" / "is identical", and a `DESIGN.md` table row said the same. The pinned baseline refutes all five in its own `network.$comment`: the list is "a PINNED, hand-curated list — `sync` carries it forward and never re-derives it … a curated RECONSTRUCTION, not an extraction", because on the first-party deployment the VM egress allowlist is not in the app bundle at all (that class returns `vmEgressPolicy(){return null}`; the real list is server-delivered per session), and four entries are flagged UNVERIFIED as VM egress. What is true — enforcement is domain-exact against the pinned list — is now what the docs say. - **"A green test means green in real Cowork"** (`README.md`, `llms.txt`) was unconditional, 21 lines above a callout that correctly calls this an emulator of the contract. `mount_delete` alone is `severity: "warn"` here while production denies it. The tagline now claims what it can support — a green run has cleared the constraints that break skills in Cowork — and points at [`docs/fidelity-gaps.md`](./docs/fidelity-gaps.md) for the deliberate divergences. - **The local lane was described as an agent inside the microVM** in `README.md` and `DESIGN.md` §1, while `DESIGN.md`'s spawn-contract section says the opposite and is right. Measured: `decideLoopFromBaseline(desktop-1.34493.1)` returns `"host"` — the loop runs on the host and reaches the VM for shell. §1 now defers to that section instead of contradicting it. - **The hermetic-`CLAUDE_CONFIG_DIR` guarantee is not unconditional** (`README.md`, `docs/discovery.md`). At `protocol` fidelity with no `ANTHROPIC_API_KEY`, the harness deliberately keeps your real config dir — a fresh one breaks local OAuth — and layers discovery settings via `--settings` instead (`src/runtime/protocol.ts`, whose comment already says so). Both pages now carry the exception and name `COWORK_MANAGED_CONFIG=1`; the sandboxed tiers are unaffected. - **Seven documented gates that do not gate the way the docs say.** Each was measured against the CLI, not read off the code. - **`analyze-skill`'s `ok` and `--strict` semantics were wrong in five places.** Both key on **severity**, not on the finding count: `ok` mirrors the exit code, and `--strict` fails only on an `error`-severity finding. Measured with one finding present — plain run: `ok: true`, exit 0; with an advisory-only finding (`artifact-write-back-suspect`): **exit 0 even under `--strict`**. So "`ok` is true only when every file has zero findings" and "`--strict` … fails on any unsuppressed finding" ([`docs/subagents.md`](./docs/subagents.md), [`README.md`](./README.md)) are both false, and `action.yml`'s and README's description of the Action's `strict` input as applying to "any advisory finding" is the **inverse** of the truth — advisory is exactly the class that never gates. `docs/subagents.md` also called the three `/sessions` rules "all advisory findings"; every one is severity `error`. - **`README.md` claimed `analyze-skill` statically analyzes `.ts` sources.** `.ts`/`.tsx`/`.jsx` are in `ARTIFACT_UNPARSEABLE_EXTS` — out of scope. `docs/subagents.md` got the exclusion right but said such a target "is reported under `unscannedArtifactSources` rather than silently passing as clean"; that field is scoped to explicit positionals, so a **directory** scan over a TypeScript generator reports nothing at all. Both now say which one you get. - **The CI recipe defined overall pass without the verdict** — `result === "success" && assertions.every(pass)`. The verdict carries ~20 signal codes that fail a run with no failing assertion (`stalled`, `mount_delete`, `host_path_leak`, `undelivered_deliverables`, `permissive_auto_allow`, `ended_with_question`, `infra_error`, …). A parser copied from the recipe greened through every one; it now points at `verdict.pass` / `ok`. - **The recipe's "sha256-verified" step verified nothing** — `curl`, `chmod`, and two comments saying someone ought to verify. It now runs `sha256sum -c -` against the pinned digest and fails the job. - **`docs/scenario.md` told remote-lane authors to "assert the delivery itself"** — a key that does not exist. `src/run/execute.ts` and `src/assert.ts` both carry a comment saying so verbatim ("Advising it sent a consumer looking for a key that does not exist"); the error messages were fixed and the table was not. It now names the real remedy (`file_exists` + `transcript_matches`, or `lane: local`). - **`docs/scenario.md` pointed `run` at `--decider-llm`.** Measured: `run` is the only command that rejects it (`unexpected argument(s)`, exit 2 — `record`, `skill` and `decide` accept it), and `run --help` says "run omits `--decider-llm` by design". Three mentions now carry that, and name `on_unanswered: llm` and `--decider-dir` as what `run` does take. - **`docs/cassette.md` said `verify-cassettes` exits 1 on an unverifiable tree, twice.** Measured on a relocated cassette: `replay` exits 1, `verify-cassettes` exits **3** — could not verify, which the CLI's own help distinguishes from the exit 1 it uses for a verified failure. - **Seven authoring-surface claims that misdescribe what the code does.** The first two are in the shipped skill, so an installed agent was teaching them. - **`SKILL.md` said a "type-it-in-notes" option has "no scripted deterministic answer" today.** It has one: `answer:` — an arbitrary string delivered verbatim, bypassing label validation by author intent (`AnswerRule.answer` in `src/types.ts`, implemented at `src/decide/decider.ts`, and present in the published scenario schema). The claim steers agents onto the LLM decider, with its cost and its `nonDeterministic` flag, for something a scripted key already covers. What genuinely has no scripted equivalent is the `OTHER:` *directive*, which is what the surrounding parenthetical is about. - **"Never hand-write the `req-N.json`/`resp-N.json` files" is unachievable for three of four gate kinds.** The `answer` subcommand's only terminal write is `{id, answers}`, while the same channel carries **permission**, **dialog** and **elicit** gates, whose replies take `{behavior}` / `{action}`. Both [`SKILL.md`](./.claude/skills/cowork-harness/SKILL.md) and [`docs/decider-dir.md`](./docs/decider-dir.md) now scope the rule to question gates, and `decider-dir` documents the alternative: each `req-N.json` advertises its own `reply_with` template, so the shape never has to be guessed. - **`fidelity: cowork` can also require `allow_host_writes`.** The consent check gates on `effectiveFidelity === "hostloop"`, and `cowork` resolves to hostloop on every shipped baseline — so a gate flip can red an unchanged `cowork` scenario. [`docs/scenario.md`](./docs/scenario.md) described the consent as hostloop-only. - **Local marketplaces are read, not registered.** `.claude-plugin/marketplace.json` is parsed directly and the plugins it names are resolved to `--plugin-dir`; the `claude plugin marketplace add` registry is inert in cowork mode. [`docs/session.md`](./docs/session.md) said "registered via `claude plugin marketplace add`" in two places, and `src/session.ts` carried the same stale comment. - **Git-tracked staging does not apply to `hostloop` connected folders.** They are bind-mounted rather than copied there (matching production), and the git filter lives in the copy path — so the same session exposes untracked files at `hostloop` that are invisible at `container`. The rule was stated without a tier qualifier. - **The connected-folder delete assertion is `no_delete_in_mounts`, not `no_delete_in_outputs`.** `no_delete_in_outputs` covers `outputs/` only; the mount-wide form covers "outputs + every `rw` connected folder". [`docs/session.md`](./docs/session.md) and [`docs/boundary.md`](./docs/boundary.md) both routed the reader to the one that does not cover it. - **`web_fetch.approved_domains` is inert except at `hostloop`.** `enableWebFetchGate()` is called at one site, guarded by `effectiveFidelity === "hostloop" && viaApiOn`, and that gate is the only consumer of the set. The value is still parsed and seeded at `container`/`microvm`, where nothing reads it — [`docs/session.md`](./docs/session.md) described it as unconditional in two places. - **Nine claims where one page contradicted another — or itself.** The accurate version already existed in most cases; these hoist it rather than inventing new content. - **`SECURITY.md` classified scenario YAML as both "semi-trusted" and "trusted input", 30 lines apart.** The trusted reading is the correct one — `allow_if` is evaluated as host JavaScript via `new Function`, so an author can run arbitrary code, by design. That statement now leads the input-boundary section; cassettes and marketplace metadata stay semi-trusted. - **`SECURITY.md` said host resources are "reachable only through an MCP server, never via direct host tools".** Not at `hostloop`: the agent loop is a native host process whose Read/Write/Edit/Glob/Grep run with no container around them, contained only by a `PreToolUse` gate — which is exactly what production does, and why a writable connected folder there needs `allow_host_writes`. [`docs/boundary.md`](./docs/boundary.md) documented this correctly all along. - **`SECURITY.md` and `SPEC.md` routed `web_fetch` through the container egress boundary.** It is host-routed at `hostloop` (matching production's host-API route), so it never crosses the per-run proxy or guest firewall — those enforce `bash` egress. `SPEC.md` said so correctly in two later sections while two earlier ones said the opposite. - **`docs/scenario.md` listed `replay` as a `requires_capabilities` hard-fail case** in a bullet, and said the opposite two sentences later. Replay re-drives and resets the outcome; the bullet was the stale half. - **`docs/cassette.md` understated the committed body surface.** A cassette inlines the body of *every* under-cap regular file under `outputs/` and `.projects/` — UTF-8 as text, anything else as base64 — not just "the `outputs/` JSON bodies". An author can commit a spreadsheet, an image or a PDF believing only JSON is embedded. Uploads and `mode:r` folders are hash-only; over-cap files carry `truncationReason: "size"`. - **"Permanently unverifiable" is wrong in two places** ([`docs/cassette.md`](./docs/cassette.md), [`SKILL.md`](./.claude/skills/cowork-harness/SKILL.md) — the latter ten lines below its own correct statement of the recovery). A relocated cassette is unverifiable *from its own location*; `--session ` resolves it without a re-record. - **`docs/cassette.md`'s minimal CI snippet ran `replay` only**, on a page that opens with "In CI, run both commands". The snippet now runs `verify-cassettes` too, with its exit-code meanings. - **`docs/protocol.md` said all three callers "skip the offending frame loudly"** on a malformed frame. They do three different things, and only one is a skip: the live session surfaces a typed protocol error event, **cassette replay turns it into a FAILING `replay_protocol_fidelity` assertion** (a malformed frame could conceal a failed assertion, so a silent skip would risk a false green), and `trace` is the one that skips and moves on. - **`rehash` is the 2.0.0 upgrade step and the README command row did not say so.** The row now states that the hash-format epoch fails a bare `replay` until each cassette is migrated, and points at the CHANGELOG entry. - **Two replay-class misclassifications, and a guard that could not see them.** Which bucket an assertion key sits in — always-content, controlOut-gated, manifest-backed, or live-only — is what tells an author whether their assertion survives a token-free `replay` or is silently skipped. The existing `docs/cassette.md` guard compared a **union** of three buckets (leaving `LIVE_ONLY_KEYS` out entirely), and a union cannot see a key MOVE between buckets, which is the change that matters. - `fidelity-and-answers.md` enumerated the live-only set and omitted **`no_delete_in_mounts`** — a reader working from that list would expect it to replay. - `scenario.py`'s `scaffold` emitted `file_exists` and `user_visible_artifact` under a heading reading *"LIVE-only (skipped on replay)"*. Both are manifest-backed: they replay whenever the cassette carries an artifacts manifest, which `record` has snapshotted since 0.24. The scaffold contradicted the taxonomy declared in its own file, and taught new authors exactly the misconception the `manifest-needs-snapshot` INFO exists to correct. It now emits two labelled buckets. - Each bucket is now guarded independently and in **both** directions — every live-only key is named, and no key from another bucket is. Moving one key between buckets in `cassette.ts` fails four tests. The `scenario.py` check is deliberately a self-consistency check against that file's own sets rather than a mirror of the TypeScript constants, because `scenario.py` says outright that it is "NOT a 1:1 mirror" (it keeps the verdict modifiers out of `CONTENT_KEYS` on purpose). ### Documentation - **[`docs/fidelity-gaps.md`](./docs/fidelity-gaps.md) no longer narrates its own edit history.** Removed a parenthetical describing what a previous draft of the `PostToolUse:WebSearch` note had claimed. A reader arriving fresh has no "before" to contrast against, so being told that a claim absent from the document was wrong costs a parse and says nothing about the harness. The paragraph above it already states current behaviour. - **`docs-present-tense` also catches a doc narrating its own revisions.** Its patterns keyed entirely on tense markers (`no longer`, `used to`, `previously`, …), and doc-self-history carries none — "An earlier revision of this section claimed X. That was wrong." passed the guard while being precisely what the guard exists to stop. Three patterns added for that shape; each is covered by a mutation check rather than by matching nothing and being assumed live. - **[`docs/scenario.md`](./docs/scenario.md) — new "Slash commands in `prompt:`" section.** Documents that a slash command must START the prompt; that skills resolve by their bare frontmatter `name:` from either staging route (`skills.local` or a `--plugin-dir` plugin source); that an unregistered name is answered by the **agent**, not the model, ending the run with `Unknown command: /`, `num_turns: 0` and no tokens spent; and that expansion is not enforcement. - **[`docs/fidelity-gaps.md`](./docs/fidelity-gaps.md) — corrected the `UserPromptSubmit` rationale.** It previously justified not serving the hook with "a scenario `prompt:` is not a slash command, so the hook returns `{}`" — an assumption about consumer input, not a property of the harness, and one consumers do violate. The gap itself is unchanged and narrower than that framing implied: the agent binary performs the expansion on stream-json input on its own, so the body injection here is identical to production; only Desktop's additional `additionalContext` is missing. - **`--fail-on-skill-drift` does not detect skill drift when you replay from an npm install** — measured, and now pinned by a test that replays the flagship cassette from a real extracted tarball. A cassette is recorded in `git` file-set mode; an extracted tarball is not a work tree, so the walk falls back to `raw`. Digests taken over different file-set boundaries are not comparable, so staleness stops at the `format`-class `recorded in 'git' file-set mode, verifying in 'raw'` rather than inventing a content diff — and `format` is outside the skill-drift classes. The practical consequence: a tampered skill file in an extracted tarball replays `ok: true` under the flag whose job is to catch exactly that, and `--strict` fails on the boundary without ever naming the tampering. Run `replay` from a git work tree when skill-drift detection is the point. The test carries a git-mode positive control on the same directory and the same mutation, so the finding is a measurement rather than an absence of one. [`docs/cassette.md`](./docs/cassette.md)'s staleness-class list now says this at the finding itself — it previously described the boundary mismatch and told you to re-record, without noting that the finding REPLACES the skill comparison rather than accompanying it. ## [2.0.0] — 2026-08-21 ### Changed — BREAKING (requires a major bump; see [SPEC.md §12](./SPEC.md#12-versioning--the-10-compatibility-contract)) - **HASH-FORMAT EPOCH — `cassetteVersion` 12. Every cassette carrying a `skillHash` fails a bare `replay` until it is migrated.** Read that sentence literally: this is not a warning you can defer. **Migrate with one command.** `cowork-harness rehash ` proves each cassette's content unchanged and relabels it in place — no re-record, no model calls, no cost. For a cassette that has MOVED (a `git mv`, a repo reorg, a copy into another project) its skill sources cannot be resolved from its own directory, so use `cowork-harness rehash --session `. Anything `rehash` cannot prove is refused rather than migrated, and does need a real re-record. **After a successful `rehash`, the epoch is cleared and you are done with it.** Migration does not touch the other staleness classes, and it does not need to: `baseline`, `format` and `prompt-assets` behave exactly as before — they surface in `staleness[]`, print a `::warning::`, and **exit 0**. Only `unverifiable-skill` fails a bare `replay`, which is what the epoch produces and what `rehash` clears. So a cassette that also carries, say, baseline drift migrates cleanly and then goes green with that drift still reported as a warning, exactly as before this release. (Measured, not inferred: a cassette with a deliberately wrong `fingerprint.baseline` replays `pass: true`, exit 0, with a non-failing `[baseline]` finding.) **`verify-cassettes` is stricter than `replay`, and that is not new.** It treats ANY staleness finding as not-green, so a migrated cassette that still carries baseline drift replays green and reds the verification gate — as it did before this release, for the same reason. Clear it by re-recording, or by re-stamping `fingerprint.baseline` where the baseline moved without changing anything the recording exercises; [docs/cassette.md](./docs/cassette.md#cassette-versioning) covers when that re-stamp is honest and when it is not. This release also ships a new platform baseline, so expect that drift on cassettes recorded against the previous one. **What changed.** A plugin manifest now folds into `skillHash`/`contentSig` through canonical (JCS-style) serialization instead of insertion-order `JSON.stringify`, so **reordering keys in `plugin.json` no longer re-stales every cassette that hashes it** — semantically identical input now produces an identical digest. `contentSig` additionally folds the directory markers `skillHash` has always folded, so an added or removed **empty directory** is finally visible to it; `CONTENTSIG_ALGO` moves 4 → 5 to say so. A new `fingerprint.hashFormat` records which transform produced the digests — **absent means the legacy pre-v12 transform, never raw bytes**, since every cassette already on disk carries version-stripped manifest digests. **Why it fails rather than warns.** A pre-epoch digest and a post-epoch digest came from different algorithms; they cannot be compared at all. That is `unverifiable-skill` — "this was not verified" — and not `format`, which is waivable and exits 0. A warning everyone ignores for a release is exactly the green-against-unverified state the strict-replay change below exists to end, and on the day of an epoch it would apply to every cassette in existence. **Some cassettes will migrate with an unchanged digest.** A manifest whose keys were already in canonical order, or a tree with no manifest at all, hashes identically under both algorithms. Those are still flagged and migrated, **by recorded version rather than by whether the number moved** — otherwise they would pass unlabelled, and at the next epoch nobody could tell which algorithm produced them. `cassetteVersion` now means the minimum reader for the **whole cassette**, not just for its `scenario` keys: a v11 reader handed a v12 cassette would recompute legacy digests and report drift that is not there. The scenario-aware differential still applies above that floor. - **A bare `replay` now FAILS when skill staleness cannot be verified** (`unverifiable-skill`), where it previously warned on stderr, recorded the class in `staleness[]`, and exited `0`. "Could not be checked at all" and "checked and unchanged" are different claims and only the second is green — a cassette that had silently stopped proving anything kept passing the lane most people run, and green-against-unverified is worse than a loud red because silence prompts a re-record while green does not. The major is required because a previously-green input now exits non-zero — `verdict.pass` / `ok` and the per-command exit behaviour are covered surfaces ([SPEC.md §12](./SPEC.md#12-versioning--the-10-compatibility-contract)). Note the *meaning* of exit 1 is unchanged (still assertion-or-agent failure), so §11's exit-code table needs no edit; what changed is which inputs reach it. **Deliberately narrow.** The content-drift classes (`skill`, `shared-root`) still require `--fail-on-skill-drift`, so that flag keeps its meaning and no inverse escape hatch is needed. **One exception, and it exists to stop a false green:** under an explicit `--session`, the drift classes are escalated too. Without that, pointing `--session` at a WRONG but resolvable tree would turn `unverifiable-skill` (a hard fail) into ordinary `skill` drift (warn-only) — so the flag could be used, accidentally, to silence the very gate it exists to help you escape. `--session` is an escape from "cannot verify", never from "verified, and it changed". **Migration.** The commonest cause is a cassette that MOVED — use the new `--session ` below rather than re-recording. If you genuinely want the old behaviour for a lane, it was never expressible as a flag and still isn't; fix the resolution instead. - **`verify-cassettes --output-format json` gained a REQUIRED `privacyScanned` field on every result.** `schema/verify-cassettes.json` is a covered 1.0 surface ([SPEC.md §12](./SPEC.md#12-versioning--the-10-compatibility-contract)), and `privacyScanned` is now in its `required` list — so a consumer validating this build's output against an older copy of the schema is unaffected, but one validating an OLDER CLI's output against the NEW schema will fail. It is emitted on every return path, so anything keying on it can rely on it. The field exists because `error` became ambiguous. A cassette that fails SHAPE validation is now still privacy-scanned (see Fixed, below), so `error` covers both "never scanned" and "scanned fine, just not replayable" — and a gate cannot tell those apart from it. **If you have CI keyed on `error` meaning "this file was not checked", that reading is now wrong; switch to `privacyScanned === false`,** where `findings: []` is an absence of evidence rather than evidence of absence. `--skip-privacy` also reports `false`, for the same reason. ### Added - **`provenance.asarGateIds` — a gate-membership change is now nameable.** A baseline recorded `provenance.fcache` as two aggregates and a timestamp, so when a sync moved `featureCount` **271 → 278** nothing could say *which* seven arrived, a count-neutral membership swap was invisible entirely, and `content16`'s diff line had to hedge "membership **and/or** values moved". The fcache is also server-refreshed on its own schedule (3.7–20.8 min observed), so a count delta between two baselines is a net over days of rollout rather than a fact about the Desktop release — and the previous payload is overwritten in place, so the question goes unanswerable the moment you think to ask it. Baselines now additionally record the gate ids **this release's own bundle references**, sorted. That is a pure function of the shipped asar: reproducible by anyone, stable across the fcache's refetches, and attributable to the release. Diffing two baselines names the delta outright (1.32885.1 → 1.34493.1: **+14 / −1**), and `sync --diff` prints the ids rather than a count. It is deliberately **not** intersected with the syncing machine's fcache. Gate membership varies by account segment, so filtering through one machine would both leak which gates that operator is served and drop DARK gates — 51 of the recorded ids are absent from the live fcache, `enableToolSearchAuto` among them. To turn an id into a name, grep it as a quoted literal in the extracted bundle; the call site names it, which is how `PINNED_GATES` was built in the first place. - **`record` now scans what it wrote, and quarantines a leaking recording instead of publishing it.** `scanCassette` had exactly one production call site — `verify-cassettes` — which runs at commit time at the earliest. `hostInventoryPreflight` does fire before the paid spawn, but it reads the tier and the destination path, never the resulting bytes: it is a prediction, and it can be wrong in both directions. After redaction and before the write, the finished cassette is scanned. A `host-inventory` or `machine-inventory` finding on a repo-visible path writes the recording to `/quarantine/` (honouring `--run-dir` / `COWORK_HARNESS_RUNS_DIR`) alongside a `.findings.txt` naming exactly what leaked, then fails without writing the requested path. Three things about that policy are deliberate. **Quarantine, not discard** — the tokens are already spent, and throwing the recording away is both the most expensive answer and the one most likely to end in "just commit it anyway". **Only the machine-identity classes trigger it** — `email` / `currency` / `domain` / `path` findings are frequently legitimate scenario content, and a gate that fires on those teaches the operator to pass the escape flag by reflex, which is how a safety gate becomes decoration. **Outside a git repo it warns instead of quarantining** — nothing there publishes the file by accident, so quarantining would be obstruction rather than protection. If the runs root is itself inside a working tree, quarantine falls back to the OS temp dir and says so; moving a leak into another committable location would be theatre. `--allow-host-inventory-fixture` (the flag the preflight already honours) still writes the file, and now reports what it is publishing rather than going quiet. Coverage is labelled honestly: the policy (`classifyRecordLeak`) and the effect (`quarantineCassette`) are pure, exported and mutation-tested; the *wiring* inside `recordScenarioObject` needs a live spawn to reach, so it is guarded structurally — the same split this repo already uses for `buildCassette`. - **Corrected a standing inaccuracy in the record-consent docs.** `SKILL.md` and `ci-recipe.md` both said the host-inventory preflight "refuses outright rather than warn". It refuses for a **new** cassette path but **warns** for one that already exists — deliberately, since refusing there would fire on every `--rerecord-stale` pass and make the escape flag reflexive. That warn path was the gap the record-time quarantine above now covers, so both documents now say which is which. - **Platform baseline `desktop-1.34493.1` (agent `2.1.237`).** The Cowork system prompt, both sub-agent append branches, all 28 pinned gate states, the VM egress policy and the 22-key spawn env are all unchanged — re-derived from the new bundle rather than inferred from an absent diff row (only the minified prompt constant id rotated). `sync` reports no unknown deltas. The substantive change is in the **agent**, and an asar-only pass cannot see it: `2.1.237` adds six Cowork-specific risk categories to the auto-mode permission rubric's vocabulary — `cowork_delete_grant`, `cowork_folder_access`, `cowork_run_routine_now`, `cowork_scheduled_task_delete`, `cowork_scheduled_task_write`, `cowork_skill_persistence` — in both the native binary and the VM ELF. They are **inert for this harness**: the rubric is entered only on `permissionMode === "auto"`, which no scenario can request and no baseline pins (now pinned by `test/auto-mode-unreachable.test.ts`). They matter because the rubric's reach now names operations the harness does model, so the existing "auto-mode permission rubric is not modeled" gap has moved from generic infrastructure risk into Cowork territory. The agent's env-flag export table also moves 524 → 533; none of the additions are set by the Cowork spawn. All three committed example cassettes are re-recorded against this baseline and stamp v12 / `hashFormat: "jcs1"`. - **`--session ` on `replay` and `verify-cassettes`** — the escape hatch for a relocated cassette. A cassette stores `session:` relative to its own directory, so any move (`git mv`, a repo reorganisation, a copy into another project) made skill staleness permanently unverifiable with no way to say where the tree went; the only remedies were moving the file back or re-recording. It takes a **session**, not skill directories, because `staleness.hash_ignore` is a session-level field that is not stored in the cassette — an override carrying only directories would silently change the hash boundary. Refused for a directory target, for a path that is not a file, and for inline scenarios; the resolved session **and the dirs it produced** are echoed on stderr, since an override that silently pinned the wrong tree would manufacture false greens. An explicit override is trusted: a mismatch under it is reported as real drift rather than downgraded. - **Duplicate manifest paths are now reported as ambiguous** instead of silently under-reported. Two mounts can each contribute `skills/x/SKILL.md`, and every consumer keys `fileSigs` by path, so duplicates collapsed to the last occurrence and the changed-file list could name the wrong file or none. Drift was always still DETECTED — the hash folds every entry — so this is an attribution fix, not a false-green fix. Exact attribution needs per-root identity in the digest, which is a hash-format epoch change. ### Fixed - **A cassette that fails shape validation is now privacy-scanned.** `verify-cassettes` does two independent jobs — a privacy scan and a staleness check — and both sat behind one strict `readCassette`. Any document that failed shape validation returned early, so `scanCassette`, on the very next line, never ran: the file was reported with zero findings, which reads in every summary as `0 PII finding(s)`. That is a clean-looking number from an instrument that never ran, and a file too broken to replay is exactly the kind of file a leak arrives in. Measured on a malformed fixture carrying MCP server names, an account org and an agent roster: **0 findings and exit 3 before, 6 findings and exit 1 after.** The fix is a read-boundary **split**, not a loosening: `readCassette` stays exactly as strict (replay, staleness and the hash-format epoch's version/`hashFormat` invariant all depend on it). A separate `readCassetteForScan` reads the transcript only, requiring nothing but `events: string[]`, and `scanCassette`'s parameter type is narrowed to the fields it genuinely reads — so a future scan axis that reaches for some other field is a compile error until the projection carries it, rather than silently reading `undefined` off a partial document. Narrowing that type immediately turned up five fields the scan reads that a hand audit had missed (`userVisibleRoots`, `scenario.name`, `scenario.session`, `scenarioSource`, `environment.agentImage.ref`). The projection also **fails closed on an unrecognized tier**. `scanCassette` exempts a positively-sealed tier and scans everything else including `undefined`, but it tests set membership — so an arbitrary string (`"garbage"`, a typo'd `"containerr"`) is neither, and would have skipped the structural host-inventory scan entirely. The strict reader cannot produce that; this one can, because malformed input is its whole job. - **The pre-commit cassette gate now fails CLOSED.** `.githooks/pre-commit` tested `hook_status` for `1` (block) and `3` (warn) and let every other outcome through to a successful commit, so the guard switched itself off — silently — on outcomes that ordinary refactors produce: exit `2` (`examples/replays/` renamed or emptied, or any CLI flag renamed), exit `127` (`node` off `PATH`), and a missing `dist/cli.js`, which is the state of a fresh clone, a `git clean -xdf`, a branch switch, and any tree with a failing typecheck (`npm run build` does `rm -rf dist` first). None of those fail a test elsewhere. Anything that is not a proven clean `0` now blocks. This matters more than a local convenience: `ci.yml` triggers on `push: [main]` and `pull_request`, but the documented workflow lands with `merge --ff-only` into `main` and pushes afterwards — so on that path the hook is not one layer of two, it is the only gate, and what it waves through is already public when CI reds. - **An unscannable cassette no longer commits unscanned.** Exit 3 folds together unverifiable *staleness*, an unsupported `cassetteVersion`, and a per-file read error. Only the first means "we looked and could not conclude"; the other two mean the privacy scan never ran, so there is no evidence either way about host inventory — and a cassette recorded by a newer CLI than the committer's `dist/` committed with nothing having checked it. The hook now splits exit 3 by cause (`--output-format json`) and blocks on the two that are not staleness, in line with the `can't verify ⇒ not green` rule the CLI states everywhere else. A payload it cannot interpret is treated as undetermined, not as staleness. - **The gate no longer misses cassettes by filename.** `record --out` accepts an arbitrary path and does not validate the suffix, so a recording written to e.g. `notes/run.json` was invisible to the hook's trigger, to CI's pathspec, and to `git ls-files '*.cassette.json'`. The hook trigger is now content-derived (any staged `.json` whose staged blob carries the `"generator": "cowork-harness"` marker), and CI cross-checks the suffix-derived set against the content-derived one. Separately, `resolveInputs` does not recurse, so `examples/replays/sub/x.cassette.json` was reachable by neither the directory scan nor the per-file loop (which excluded all of `examples/replays/`); the exclusion is now scoped to files *directly* in that directory. - **CI scans every tracked cassette, not just one directory.** The sweep is derived from `git ls-files` rather than a hard-coded path, fails loudly if the pathspec ever matches zero files (an `xargs -r` sweep exits 0 on no matches and reads as success), and carries exactly one exclusion with its reason recorded: `test/evals/files/report-check.cassette.json` is an eval *attachment*, not a recording — it has no `scenario.session`, so `readCassette` rejects its shape before the scan can run. Measured rather than assumed: adding a `session` field does not make it verifiable, it converts the exit 3 into an exit 1 on baseline drift for a fixture that is never re-recorded. - **The local gate is no longer laxer than the CI gate on the same directory.** The hook passed `--allow-email`/`--allow-domain` suppressions that `ci.yml` does not; the committed fixtures verify clean without them, so they are gone. Its scratch file also moved from a predictable `/tmp` path to `mktemp`, and a clean run now says so instead of passing in silence. - **`sync` derived the enforced egress allowlist from a bundle-wide regex, and Desktop 1.34493.1 made that wrong.** `network.allowDomains` is the allowlist the harness ENFORCES (`boundaryAllowList` plus the session egress plan), but it was built by matching every `*.anthropic.com` / `*.claude.ai` literal in the whole app bundle. 1.34493.1 added a webview first-party-origin classifier — a navigation-trust tier naming `www.claude.ai` and `staging.claude.ai` — and the sweep pulled both into the enforced list, which would have permitted egress Cowork denies. Narrowing the sweep was investigated and rejected: on the first-party deployment there is nothing to narrow to. The 1p class returns `vmEgressPolicy(){return null}`, so `resolveVmAllowedDomains` falls through to the session's **server-delivered** `egressAllowedDomains`, and the only host the bundle contributes is the OTLP endpoint. `vmAllowedDomains`/`firewallAlso` are the 3p path and Desktop's own renderer endpoints — neither is the VM allowlist. Any bundle scan is unsound both ways: blind to server-delivered hosts, open to hosts that are not egress. `network.allowDomains` is therefore a **pinned, hand-curated list carried forward** from the newest committed baseline, and a new fail-closed `checkEgressContractFacts` guards the three constructions that justify pinning (the 1p null policy, the resolver's fall-through to its caller-supplied argument, and the OTLP-only augmentation) — so a real change in how Cowork computes egress hard-fails `sync` instead of silently rewriting the list. The baseline's `network.$comment` now records that provenance and names the entries that are unverified as VM egress; `network` became a `looseObject` so that note survives loading. - **Consumers of 1.25.0 were NOT affected by this** — it is recorded because the shape is worth knowing, not because it shipped. While building `--session`, skill staleness, session-shape staleness, label provenance and the skill-hash debug dump could each have resolved a different session. The cassette-relative join was duplicated byte-identically in three functions and `sessionFingerprintDrift` accepted an override its only caller never passed, so `--session` would have verified skill content against the override while session shape still resolved the recorded path — reporting "clean" on an axis that hard-fails when used normally. All consumers now share one resolver. - **An unresolvable session now says WHY** — missing file, unreadable/unparseable YAML, or declared mounts that do not exist — instead of one undifferentiated message. Those point at different fixes, and only the first looks like a relocation, so it also names the remedy. ### Known limitations (documented, not fixed) - **Multi-root skill hashing is order-dependent.** `hashSkillDirs` folds roots sorted by absolute path while deliberately excluding a root's own name from the digest, so identical content at differently sorting directory names hashes differently. One axis (root ORDER) fails loudly as false drift. A second is worse: roots fold into one digest with no root-boundary marker, so moving a file BETWEEN roots is invisible — a genuine false green. Multi-root cassettes are still not refused, because none exists in any reachable corpus and refusing would break input nobody has; instead replay now emits a note when a cassette records two or more roots. Fixing it needs a hash-format epoch. Not scheduled: no multi-root cassette exists in any reachable corpus (32 cassettes on the widest denominator across three repos), and no session declares 2+ plugin/skill roots. Pinned by tests in `test/skill-hash.test.ts` so the eventual fix is a deliberate change. ## [1.25.0] — 2026-08-20 ### Added - **Platform baseline `desktop-1.32885.1` (agent `2.1.234`).** The Cowork system prompt is byte-identical to the previous baseline, the egress allowlist is unchanged at 15 domains, and the spawn contract still derives the same 22 env keys — but the **host-loop sub-agent append gained a sentence**, so `baselines/prompts/desktop-1.32885.1/subagent-append-hl.md` is a newly re-derived paraphrase and `spawn.subagentAppendHostLoop` now points at it. The added text tells a host-loop sub-agent that its shell commands start at the VM session root and that anything written outside `/mnt/` — `/tmp` included — stays inside the sandbox, invisible to both the user and the sub-agent's own file tools. That is the host-loop split-filesystem fact the harness already models; it is now stated to the model. The `vm` branch is unchanged and keeps its existing asset. Worth knowing for anyone re-deriving this: the branch fingerprints decode `\uXXXX` escapes before hashing, so this is a real content change and not the codegen-escape artifact that moved both fingerprints a release earlier — the `vm` branch, which an escape change would also have moved, did not budge. **Live-verified against this baseline on 2026-08-19** across `protocol`, `container` and `hostloop`: the example-scenario suite 6/6, the `boundary-check` sandbox proof with all six constraints enforced, and `npm run test:live` at 4 suites / 24 assertions (20 green, 4 skipped). Three of those four skips passed on a re-run — the model-variance the suite skips loudly for rather than failing. The fourth, `live-outputs-delete`'s "a whole-line `#` comment is prose, not an executable delete", skipped in all three runs made against this baseline and so has **not** been green here; by that suite's own rule a skip persisting across runs means the agent has stopped being willing to run the pinned command, which makes it scenario-maintenance debt rather than a guard defect. Recorded rather than rounded away. - **A `--repeat` rollup now names the ARM it ran, so a one-armed batch can't be banked as an A/B.** `--ablate-skill --repeat 5` produces 5 control runs and zero treatment runs — correct for a single-arm flag — and summarized them as `repeat "": PASS — 5/5 passed (100%)`, which reads as a completed comparison. A consumer made exactly that read twice, producing 10 baseline runs and 0 treatment runs across two prompts before catching it at analysis. The verdict line now carries the arm: `repeat "": PASS [ABLATED — control arm] — 5/5 passed (100%)`. A partially-ablated batch (no flag produces one today; a resumed or hand-assembled run set could) reads `[MIXED ARMS: 2/3 ablated]` rather than being rounded to either arm, and a normal batch carries no tag at all — a label on every batch is noise, which is how the ablated one would come to be ignored. `--matrix`'s per-cell rollup lines get the same label, since that is where the largest batches run. **The flag combination stays legal.** Refusing it would ban a real measurement — "how variable is my no-skill baseline?" is a question these flags compose correctly to answer — and the output was never dishonest, only unlabeled at the one line a human reads. (Contrast `--ablate-skill --resume`, which *is* refused: there ablation does not take effect at all, so `ablated: true` would be a lie.) - **A `[provenance]` banner on every run verdict — "which experiment actually ran?"** Three separate multi-run measurements by one consumer were silently scoped to the wrong thing, and in every case the run record already held the answer: a whole finding measured on `claude-sonnet-5` because the session file omitted `model:`; a 10-run "A/B" that was 10 `--ablate-skill` control runs and zero treatment runs; an answer that read exactly like skill output, from a run where the skill was offered and never invoked (the model read the mounted `SKILL.md` as a file instead). `models`, `ablated`, `context.availableSkills` and `skillsInvoked` were all in `result.json` and none of them were anywhere a human looks, so checking meant hand-written scripts against the record — which nobody runs until a result looks wrong, i.e. after the money is spent. The footer now prints one line beside the verdict, on passing AND failing runs and on the replay lane: ``` [provenance] model=claude-opus-5 skill=offered,NOT-invoked ablated=false ``` `model` drops `<…>`-wrapped agent markers first — `` marks a locally fabricated turn, not a model, and an unfiltered join reads as a two-model run. `skill` has four states, and `offered,unknown` / `unknown` mean **evidence unavailable**, never "no": a banner that exists to prevent false confidence must not manufacture any. `ablated=false` prints too — the value is that the line is on every run. The same derived object rides in the `--output-format json` envelope as `results[].provenance` (beside `verdict`), so a consumer never re-derives the marker filter or the evidence-unavailable states. A `--repeat` batch gains an aggregate `provenance:` row on its rollup, reporting models and skill states as **sets** — a batch silently spanning two models is the multi-run form of the same defect, and collapsing to the first run would hide it. `--compact` (and `--demo`) suppress the line, matching the `[status]` contract. ### Changed - **`verify-run --output-format json` now emits `results[]` with a per-result `verdict`, matching `run`.** The two commands answered the same question — "did my assertions pass?" — in structurally different envelopes: `run` nested everything under `results[].verdict`, `verify-run` was flat (`pass`/`assertions[]`/`signals[]`, no `verdict`, no `failures[]`). The cost was not a missing field but a **silent false green**: the defensive jq idiom from `run`'s own docs — `.results[]? | .verdict.failures[]? | select(.kind=="assertion")` — returns `[]` when `.results` is null, and `[]` reads as "no failures" in the query whose entire purpose is detecting failure. Run against a **failed** `verify-run`, it reported success. This matters most where `verify-run` is promoted hardest: as the cheap, token-free iteration path in CI. `results[]` always holds exactly one entry — `verify-run` judges one run dir, which is the same shape `run` emits for a single scenario. **Additive**: the flat `pass`, `assertions[]`, `signals[]` and `answerCoverage` keys are unchanged, so an existing consumer reading them is unaffected; `ok` still mirrors the verdict. A cross-command regression test runs the real documented query against a real failing envelope, so restoring the flat-only shape as a "simplification" fails the suite rather than silently reopening the false green. ### Fixed - **The outputs-delete live suite was refusing to run, and a refused case verifies nothing.** It handed the agent a byte-pinned destructive command wrapped in prohibitions ("run this EXACTLY as written… do not modify it… do not run any other command") plus an unexplained sentinel, and asserted the command came back verbatim. The agent increasingly declined — over the framing, not the file operation — and a declined case SKIPS. Measured across 27 case-runs the refusal rate was **41%**; every case was refused at least once and the worst sat at 67%, so the suite could report success having verified almost nothing. It now asks for **ordinary tasks** whose completion requires the file operation — write two poems and delete one; write a poem and rename it. The agent has no delete tool, so a deletion must go through Bash, which is exactly the path the scanner watches, while a benign creative task gives it no reason to refuse. Measured 9 of 9 runs complied, zero refusals. The two form a polarity pair: one must trip the guard, one must not. Because the task is real, the run is now also asserted on its **effect** — exactly one poem file survives in `mnt/outputs` — where the pinned suite only ever proved the scanner had recorded an *intent* to delete. What is given up is byte-exactness: the agent picks its own filenames and command form, so assertions are on shape plus effect. Command-form distinctions that cannot be asked for naturally ("emptying a file is not a delete", "a commented-out `rm` is not a delete", the `mv` spellings) moved to `test/execute.test.ts`, deterministically and for free — including the `mnt/`-prefixed `mv` bytes the live case depended on, which no unit test had covered. Two intermediate attempts are recorded in the file's header so they are not retried blind: explaining the request (stated purpose, what the marker is for) made refusals **worse**, and retargeting one case's destination away from `/tmp` helped that case only. - **A fixture shrinking could red an unrelated test.** `replay-json-pipe-truncation` multiplied a seed cassette to exceed the 64KB pipe buffer, with the copy count hard-coded at 10 and justified as "~15KB/result". The real figure was ~5.5KB, so the total sat just under the buffer and a routine re-record of the seed tipped it under — reddening the suite for a reason unrelated to the truncation bug it exists to pin. The count is now derived from a measured result at ~2x the buffer; the `> 65536` assertion stays as the tripwire. - **`replay --help` now says that `--allow-failing` waives the skill-drift gate too.** `--assert-from` forces that gate on precisely so a re-asserted block cannot be frozen against a recording whose skill sources have moved — but the gate is the verdict, and `--allow-failing` waives the verdict wholesale. Nothing downstream re-checks drift. So `--assert-from --write --allow-failing`, which is the natural incantation when your asserts are legitimately failing (that being why you are re-asserting), persists the block against a drifted recording with no warning. Behaviour is unchanged — the flag is an explicit override and stays one — but it is now stated where it is reached for. The same block documents that text mode writes to stderr and nothing to stdout (a passing replay is 0 bytes), and names `verdict.failures[].kind` as the way to separate your own failing asserts from injected drift/corruption findings, which the exit code collapses. - **`verdict.failures[].kind` said "your assertion failed" when the cassette was corrupt.** That field is the documented way to tell an author's own failing `assert:` from something the harness injected — and seven cassette-corruption paths (duplicate `request_id`s with differing bodies, malformed control-out lines, a truncated recording) pushed their pseudo-assertions without the `source` stamp that drives it. `computeVerdict` falls back to `a.source ?? "assertion"`, so every one of them was reported as an authored assertion, in direct contradiction of the contract written above the field. A consumer asking "did MY assertions pass?" with the documented `select(.kind=="assertion")` query got a yes-it-failed on a cassette that was simply unreadable. They now stamp `cassette-format`, whose definition widens from "a cassette too new to interpret" to cover corruption as well — the shared property is that the cassette itself cannot be interpreted. No enum changed; `cassette-format` was already a member. **The guard that was supposed to catch this could not see it.** It scanned for the `{} as Assertion` cast shape, and all seven pass a real assertion key (`{ replay_protocol_fidelity: true }`), so they never matched — the suite stayed green while the sites shipped unstamped. It now keys on `assertions.push(` itself, which in these files is by construction an injection (an author's own asserts are evaluated elsewhere and never reach that call), and carries a mutation check proving the matcher rejects a bare push. Its site count is now counted rather than inherited: the old comment said 2 in `cli.ts`; there are 3. - **A stale sub-agent prompt pointer can no longer ship with a green `sync`.** The prompt assets a baseline points at (`spawn.subagentAppendHostLoop` / `spawn.subagentAppend`) are hand-authored, so `sync` carries the previous release's values forward untouched — while the drift sentinel compares the shipping app's text against a recorded fingerprint and never looks at those pointers. Recording a new fingerprint therefore cleared the sentinel whether or not the pointer moved, and a host-loop sub-agent would silently receive the previous release's paraphrase with every check green. A new coupling check closes it: when the newest recorded fingerprint differs from the one before it on an axis, the newest baseline's pointer for that axis must differ from the previous baseline's. Both inputs are already-committed data, so there is no new field to fill in — and nothing to copy-paste into compliance, which is what sank an earlier attempt at this. Verified by simulating the real failure: the check fires and names the exact edit required. Its limits are documented where it lives, not glossed: the committed asset is a deliberate paraphrase, so this enforces coupling and cannot verify faithfulness; it is dormant between fingerprint moves; and back-filling an older fingerprint entry equal to the newest silently disarms it. Alongside it, the per-tier branch-selection assertions were unfrozen from a pinned `desktop-1.20186.1` to `latest`. Pinned, they asserted real hl-vs-vm content semantics that could never observe a repoint of the CURRENT baseline — coverage in appearance only for the pointer production actually renders. - **`verify-cassettes` stopped flagging the agent's own built-in skills as operator inventory.** The host-inventory scan keys off a closed roster of skills the product itself ships; that roster still held a single entry (`deep-research`) while the agent grew fourteen more. The first fresh `protocol` recording after a sync therefore reported 14 `host-inventory` findings on a cassette carrying no operator inventory at all — the exact false positive that pushes people toward a blanket `--allow-host-inventory`, which would disable the check that matters. The roster is now current, established three ways rather than assumed: the recording was made against a **managed (fresh) config dir** whose session stages no plugins or skills, so nothing from the operator's own config could have been enumerated; every name appears as a literal in both the staged agent ELF and the host CLI; and ten personal/plugin skill names from the same machine are **absent** from that binary, so the check discriminates rather than matching everything. The known cost is unchanged and inherent to a name-keyed set: an operator whose own skill shares one of these bare names is no longer flagged — the same trade the built-in *agent* roster already makes. - **A minified `$` in the shipping app could make `sync` refuse a perfectly healthy Desktop release.** Several spawn-contract sentinels pinned a minifier-assigned binding, callee or member name with `\w+`. `\w` is `[A-Za-z0-9_]` — it cannot match `$`, which is a legal JavaScript identifier character that minifiers use freely. Claude Desktop 1.32885.1 named the empty-`ANTHROPIC_*` blank-sentinel helper `$s`, and the sentinel asserting that helper runs on the spawn env stopped matching. Nothing about the spawn contract had changed: re-deriving it against the new app produced the same 22 keys with the same values. An audit of every regex in the sync module found **11 such atoms across 7 patterns**, all in the spawn family, of which only one was firing — the other six were latent purely because their bindings happened not to draw a `$` this build. All of them are now `[\w$]`, including the captured env-object binding, which previously admitted a *trailing* `$` only and so would still have missed a `$`-initial name even with its callees widened. **The whole class fails closed** — an unresolvable value flags and refuses to write, rather than writing a wrong one — so the cost was a false refusal on a good release, never a silently incorrect baseline. That is also why six of the seven went unnoticed for so long, and why the fix ships with a guard rather than just a widening: a new test asserts the module contains **zero** regex atoms that cannot match a `$`-initial identifier, and backs that structural invariant with behavioural fixtures that drive the real sentinels using `$`-named bindings. The fixtures also assert the sentinels still *fire* when the contract genuinely breaks, so the widening cannot be mistaken for weakening them. Ships with one relaxation on the release checker: `check-versions`' DESIGN.md gap-form regex now accepts the singular *"1 baseline has shipped since"* — this release is the first N=1 gap on record, and the count is still verified against the enumerated list, so the singular form is not a loophole. ### Documentation - **Three claims about the committed example fixtures were wrong, and are corrected.** `docs/protocol.md` said all three golden protocol vectors were "extracted verbatim" from `example-multiselect-gate.cassette.json`. `initialize.json` cannot have been: it carries an `appendSubagentSystemPrompt` holding the VM sub-agent text and a session id present in no committed cassette, while a `protocol`-tier run renders no sub-agent append at all and that scenario has been `fidelity: protocol` for its entire history. It is a real captured frame, from a container-tier run that was never committed. The other two do come from that scenario, but "verbatim" has a shelf life — one still matches field-for-field, the other carries a `request_id` regenerated on every re-record. `examples/replays/README.md` described a fixture as "`protocol`-tier (no Docker/agent needed to replay)", implying the tier is the reason. Replaying any cassette needs neither Docker nor a staged agent whatever tier it was recorded at — replay reads recorded frames and spawns nothing, which is why the token-free CI lane replays the container, protocol and hostloop fixtures side by side. The same file called that fixture "synthetic"; that was true of its hand-written capability catalog and stopped being true when it was re-recorded hermetically for this release's baseline sync. - **`docs/maintenance.md` now names the repoint step.** The per-release procedure walked a maintainer through updating the paraphrase asset, appending a `subagentAppendVersions` entry and re-running `sync` — and never said to repoint `spawn.subagentAppendHostLoop` at the new asset. Those pointers are hand-authored, so `sync` carries the previous release's value forward untouched, and writing the fingerprint entry clears the sentinel whether or not you repoint. Skipping it ships a host-loop sub-agent the previous release's paraphrase with `sync` green. That is the step that was missed on 1.32885.1 and caught by eye. ## [1.24.0] — 2026-08-18 ### Added - **`verdict.failures[]` entries carry a `kind`, so "did MY assertions fail?" is answerable from the envelope.** A consumer was scraping stderr for this, because the only available discriminator was whether an entry carried an `assertion` key — and that was wrong in **both** directions. `verify-run` injects `{ answer_coverage: }`, which is not an `Assertion` key at all, so a coverage miss rendered exactly like one of the author's own asserts; meanwhile guard failures, `--strict` staleness, `--fail-on-skill-drift` drift and a too-new cassette all arrived key-less and indistinguishable from one another. (The sentence in the shipped CI recipe describing key-presence as the discriminator was therefore already false — corrected here.) Every entry now carries one of `assertion` | `guard` | `staleness` | `cassette-format` | `coverage`, stamped at each of the **five** pseudo-assertion injection sites via a new optional `RunResult.assertions[].source`. `jq '[.verdict.failures[] | select(.kind=="assertion")]'` is now the supported way to ask whether your own asserts held, and `select(.kind=="staleness")` whether the cassette is stale — neither is inferable from the exit code, since all of them land on exit 1. Additive: `assertion` and `message` are unchanged, so an existing consumer reading them is unaffected. A source-scanning guard fails if any future pseudo-assertion is pushed without a `source`, because the unit tests could only ever cover the sites they happen to construct — a mutation run proved that gap by deleting one stamp with every other test still green. - **`file_absent` and `artifact_text` — the two file-family gaps a consumer report named.** `file_absent: ` is the direct negative-existence check. The workaround until now was inverting `no_unexpected_files`, which is a different claim with two traps: it is **new-files-only**, so a file that existed before the run is invisible to it however tight the allowlist, and it needs a pre-run manifest — the consumer paid for a re-record just to allowlist an incidental `.lock` file. **LIVE/verify-run only**, deliberately: proving absence needs an exhaustive, healthy walk, and `buildManifest` collects through the health-*discarding* `collectArtifactPaths`, so on replay a containment-skipped or unreadable subtree is indistinguishable from an empty one and the key would pass while proving nothing. It also fails evidence-unavailable on `lane: remote` and on `preRunOrigin: remote-unavailable` — where the filesystem is not locally observable, a missing snapshot is not evidence of absence. It does **not** inherit `local-unreadable`: that flag describes an incomplete pre-run *baseline*, which says nothing about whether one named path is on the post-run tree. `artifact_text: {artifact, contains?, not_contains?, matches?, not_matches?}` asserts over a delivered artifact's text body — `artifact_json`'s companion for non-JSON deliverables, and the way to prove an internal filename did not leak into a file a user receives. A consumer shipped exactly that to a founder: an internal reference name appeared 13 times in the delivered `report.json` and 0 times in `report.md`, so the fix looked complete. `artifact` is a literal path, not a glob — one entry per delivered surface; a glob would be an exhaustive claim over the manifest's file set, which is `file_absent`'s class and unprovable there for the same reason. On `lane: remote` it names the lane rather than reporting a bare "file not found" — not a false green either way, but on a lane with no locally observable filesystem that message reads as "the skill didn't write it" (`artifact_json` still has that wart; the new key does not inherit it). Both are fail-closed on missing evidence, and one of those paths was a latent bug in the key they share a code path with: **`artifact_json` never checked `ctx.linkPaths`.** A manifest entry recorded as a symlink travels a different channel from `truncated` and materializes as a real 0-byte file; `artifact_json` survives it only because `JSON.parse("")` throws. A text matcher would have read the placeholder and reported "does not contain" as a pass, so the guard now lives in the shared block for every body-reading key. For the negative matchers, a body that is not lossless UTF-8 also fails evidence-unavailable rather than "passing" against replacement characters. And the record-time over-cap refusal that keeps `artifact_json` honest across lanes now covers `artifact_text` too — a deliverable big enough to be worth scanning for a leak is exactly the one that clears the 64 KiB body cap. Supporting change: `isLosslessUtf8` moved to the leaf module `src/run/artifacts.ts` (re-exported from `cassette.ts`) so `assert.ts` can use it without closing an import cycle, and `ALL_CLASSIFICATION_KEYS` now spreads `MANIFEST_KEYS` instead of hand-listing it — that literal was the one place a new manifest key threw at first replay for want of a second edit. Documented in `docs/scenario.md`, `docs/cassette.md` and the bundled skill — catalog rows, the goal→key index, and the replay-class lists: `artifact_text` joins the manifest class (its "all five" count becomes six) and `file_absent` the live-only class, with the reason it can never be replay-checked. The docs-sync guard cannot see that placement — `test/skill-docs-sync.test.ts` requires only that each key appear backtick-quoted somewhere in the skill's schema reference, which a single catalog row satisfies. - **`question_options` — assert the option SET and ORDER a gate offered the user.** The gate family could assert *that* a question was asked (`question_asked`, text only), how many, and whether the answer was delivered — nothing could assert what the person was actually SHOWN. A consumer hit the consequence: their skill enforced an option tuple on the file, the agent presented that list **reversed** — demoting the safe choice from first to last and putting a different option in the default slot — and every artifact assertion passed, because the artifact was correct. The only wrong thing was what a founder saw. ```yaml - question_options: when_question: "rubric doesn't fit" equals: ["Stop review", "Proceed anyway", "Pick another rubric"] # order compared by default ``` `when_question` is a regex over the same label `question_asked` matches (`question`, falling back to `header`); omit it only when the run fired exactly one sub-question — more than one without a selector FAILS as ambiguous rather than silently taking the first, since guessing would make the assertion depend on the gate order it exists to pin. Set exactly one of `equals` (the complete set) or `contains` (a subset) — both, or neither, is rejected at **load**, so a contradictory assert is refused before the run is spent rather than after. `order: exact` is the default; `order: any` compares membership only, as a multiset so a duplicated label is not equal to a distinct one. **The evidence is captured when the gate is ASKED, not when it is answered.** The answer-time channel (`decisions[].questions`) is written only on the answered branch, so a gate that was shown and then denied, stalled or left undelivered carries no option set there — which is precisely the case worth asserting. Live and replay read the new ask-time `RunRecord.gateOptions`; `verify-run` reads `events.jsonl`, the only sidecar that retains option labels (the distilled `trace.json` drops them), and does so whenever the key is asserted rather than only when the scenario has scripted `answers` — a scenario using `on_unanswered: first` or an LLM-decided gate would otherwise have reached the evaluator with no evidence at all. Every unreadable-evidence path fails **evidence-unavailable**: a truncated-cassette replay, an absent `events.jsonl`, or one with any unparseable frame (a partial gate set must never be graded as complete). Replay evaluates it only with `controlOut`, like the other gate keys. A cassette recorded with this key still stamps format v10 and is rejected by installs that predate the key — the standing consequence of any assertion-key addition. Documented in `docs/scenario.md` and in the bundled skill: the assertion catalog, the goal→key index, the four gate-key replay lists, and the `positional-choose-order` advisory, which stops telling you to compare option order by hand. ### Changed - **A `scripts/`-grounded `not-adjudicable` now says WHY it could not be decided.** `scripts/` is outside the evaluator's corpus by design — it grades authored guidance (`SKILL.md`, `references/**`, `agents/.md`), not implementation — and `docs/critique.md` has always said so. What the verdict never said is which kind of "can't decide" it meant. A consumer read `not-adjudicable` on a claim about their own `gate_state.py` and treated it as unproven; it was a **verified product bug**, and the evaluator had simply never been shown the file. The report now appends one note to that section naming the boundary, the reading ("could not SEE the code, not that the claim is false"), and the documented remedy — state a script's contract in `SKILL.md` or a `references/` file if it matters to how the skill is used. The corpus boundary itself is unchanged: packaging script bodies would widen the evaluator from grading guidance to grading implementation, which is a scope decision, not a bug fix. - **`lint` gains an ERROR-class `file-absent-contradiction` rule.** `file_exists: X` and `file_absent: X` on the same path cannot both hold, so a scenario carrying both would spend a run to fail. Like every ERROR-class finding it gates **without** `--strict`. It lives in the linter rather than in the TypeScript contradiction groups because those match on key PRESENCE across the assert array and cannot compare values — the linter already has the parsed YAML, so the comparison is free there. The `positional-choose-order` advisory also stops telling you to read `decisions[].questions[].options[]` by hand and points at `question_options` instead. - **`--strict` means two different things in one CLI, and both help strings now say so.** `lint --strict` fails on ERROR+WARN+**INFO**; `lint-skill --strict` fails on ERROR+WARN and **never** INFO, deliberately. Each help text was individually accurate and the pair was silently contradictory — a consumer met the stricter of the two and read its INFO findings as a gate. Each now names the other's rule, and the CI recipe states the `--strict --min-severity WARN` pairing at the line where someone copies it. The semantics are unchanged: narrowing `lint --strict` would silently weaken a gate people may be relying on, which needs a deliberate major-version decision rather than a quiet fix. - **Three documented gaps gain the framing a field report supplied.** The elicitation gap is not only "the form branch goes untested" — because the host's guidance is absent, so is every **conflict** between it and a skill's own instructions, and a real session produced exactly that (a skill mandating `AskUserQuestion` "(NOT plain chat)" against the host's injected form guidance). That class is structurally unobservable here, so a skill can ship a directive production silently overrides with every harness run green — which reframes what the planned opt-in stub server is worth. `docs/critique.md` now also states that a **fleet-consistency** defect is out of scope for any single critique by construction (the graded agent mounts the whole plugin; the evaluator's corpus is one skill), and the N-run recipe carries a measured case for why one critique is a sample: two runs of the same skill over the same document produced 78 vs 50 extracted figures and 12 vs 0 first-pass errors from the same real bug. - **`critique`'s cost guidance stated one ratio unconditionally, and it inverts for the skills people most want to critique.** `--help` and `docs/critique.md` said the two evaluator passes dominate spend at ~3/4 of an end-to-end total. That holds for a trivial probe. Measured on a real document-analysis run: **task turn ~61%, evaluator ~30%** — because evaluator cost is roughly fixed (bounded by the evidence package) while the graded task turn is unbounded. The harm was the advice that followed: swap `--evaluator-model` on a fleet sweep, trading the injection-resistance property that is verified **for the default evaluator only** for a saving a third the advertised size. Both surfaces now name both regimes and point at the per-run split, and the report's `cost:` line prints the evaluator's **share of the total** alongside the four-way breakdown — so a run corrects the guidance itself rather than waiting for the next reader of the docs. When the task turn dominates, the levers named are `--model`, `--timeout` and probe scope. - **`critique --out report.json` warns when the extension and `--output-format` disagree.** `--output-format` defaults to `text` and `--out` writes whatever it says, so the flag most likely to be scripted against had its format decided by a different flag with a non-obvious default: a downstream `json.load()` failed with `Expecting value: line 1 column 1`, which reads as a corrupt or missing report rather than a format mismatch. The warning fires at **argument-parse time**, before the four workloads spawn — the reported cost of this was a paid run discovered to be unparseable after the fact. Deliberately a warning and not extension inference: a filename is not proof of intent, and silently changing what an existing `--out foo.json` writes would break a script that already parses the text. - **`record` warns BEFORE the run when a cassette would not be portable.** A cassette stores its `scenario.session` and `scenarioSource` relative to its own directory, so if reaching them means climbing out of the project tree, the stored relatives resolve only from that one filesystem layout — the file is uncommittable, and `verify-cassettes` reports it permanently `unverifiable` for staleness. Two consumers discovered that *after* paying for the run. The new preflight fires at the same pre-spend point as the host-inventory guard, and in `record --dry-run`, so the rehearsal is free. The bundled skill states it where it already warned that a cassette cannot be moved after the fact, and on `--dry-run` itself. It tests **climb-out**, in both directions: the cassette written outside the tree (the reported `--out /tmp/…` case) and a `session:` that lives outside it (an absolute or `~` path) — the mirror image, equally unresolvable, and invisible to a check that only looks at where the cassette lands. `~` is expanded first: `parseScenarioFile` deliberately leaves a `~/…` session untouched, and a raw `~/x` reads as *relative*, so an unexpanded check resolves it under the cwd and calls it in-tree. The reference root is the scenario source's git top-level, falling back to the **cwd** — not the session file's directory, since `sessions/` and `cassettes/` are conventionally siblings and that anchor would warn on every default record. Paths are canonicalized as far as they exist, because `git rev-parse --show-toplevel` always returns a real path and `/var` vs `/private/var` would otherwise warn on every macOS record. A warning, not a refusal: an out-of-tree throwaway cassette is legitimate — the defect was that nothing said so while the author could still act. - **The host-inventory record refusal no longer recommends an out-of-repo `--out`, and its remedy is branch-aware.** Two consumers hit the same trap: the refusal told them to `--out` a path outside the repo, and taking that advice bakes a cassette whose `scenario.session` / `scenarioSource` — stored relative to its own directory — can never resolve again, so `verify-cassettes` reports it `unverifiable` for staleness (can't verify ⇒ not green, exit 3) and only a re-record recovers. It cost paid runs to discover, and the skill's own guidance had already started contradicting the message. That branch is gone; the message now names it as explicitly NOT a fix, with the consequence spelled out. The remedy it *does* offer is now scenario-dependent: `fidelity: container` normally, but a scenario asserting a hostloop-only key (`no_vm_path_file_op`, `vm_path_denied`, `path_denied`, `no_path_denied`, `subagent_dispatch_healthy`) cannot run at container at all, so it is pointed at `--allow-host-inventory-fixture` after auditing the session instead. The key set is read from the evaluator's own gate sites (`HOSTLOOP_ONLY_KEYS`, newly exported from `src/assert.ts`) rather than restated — `test/hostloop-only-keys.test.ts` scans the `hostloopOnly("…")` call sites and fails if the two drift, in either direction. - **Parity baseline synced to Claude Desktop 1.32352.0** (agent ELF unchanged at 2.1.229). Two spawn env keys are new: `CLAUDE_PREVIEW_CLASSIFIER_FLOOR` is **pinned** — it is unconditional in the Cowork spawn env, so every first-party session receives it (the variable is older; what is new is Cowork setting it outright rather than the desktop code-session runner setting it behind a gate) — and `CLAUDE_CODE_DIAGNOSTICS_FILE` is **allowlisted, not pinned**, because it is constructed only inside the third-party/MDM deployment branch and never on a first-party session. The `automode-permission-rubric` gate flipped `off (defaultValue)` → `on (force)` server-side; the rubric it enables is Desktop-side and applies to VM-loop non-chat sessions, which the harness does not construct — see `docs/fidelity-gaps.md`. `DESIGN.md`'s scope note moves from "no baselines have shipped since" to naming what the last live end-to-end pass does **not** cover, which is what shipping a baseline is supposed to force. ### Fixed - **`assertions --list` was advertised as emitting each key's replay class. It does not.** The bundled skill's CI recipe offered the JSON form as the authoritative substitute for hand-typed key enumerations — "every key, with its replay class" — and the output is `{key, description}`, with no structured class field to filter on. A consumer taking that at face value writes a `jq` selector against a field that has never existed, on the one surface recommended for not going stale. The line now says what the command emits, and points at the catalog's replay-class tables for the classes themselves. - **Five published sentences described `fingerprint.skillSources` as cassette-relative. It is not.** The "a cassette is not relocatable" guidance added earlier in this release listed `scenario.session`, `fingerprint.skillSources` and `scenarioSource` as all being rewritten relative to the cassette's own directory. Only the first and third are. `skillSources` is stored relative to the **session-file** directory and is diagnostics-only — nothing resolves against it. The real break chain is one hop (cassette dir → relative `session:` → that file's declared skill dirs), which is why a moved cassette loses the skill hash. Corrected in `SKILL.md`, `references/scenario-schema.md`, `docs/session.md`, `docs/cassette.md` and this file's own earlier entry; `docs/cassette.md` gains a note stating the chain positively, since knowing which reference actually breaks is what tells you whether a move is recoverable. - **`result.json`'s `models` array is documented as agent-verbatim, and `` is named.** A consumer hit `` in `models` and could find it nowhere — because it is not a harness string: the agent stamps that literal on assistant messages it fabricates locally (no API call, zero-filled `usage`), and the harness records model ids verbatim. Every surface that describes `models` said or implied each entry is a real model id — `schema/run-result.json` carried no `description` at all, while `docs/session.md` and `docs/debugging.md` told you to read the array back as run provenance, which two runs of the *same* pinned model can differ on purely by whether a synthesized turn occurred. All four now state the rule (drop `<…>`-wrapped entries — the angle-bracket prefix is the marker, not the one spelling), and `docs/gotchas.md` gains a symptom-keyed entry for the literal token someone greps for. The maintainer-only eval gate has filtered this since it was bitten live, but its comment mis-attributed the value to "a cassette/replay rep that used NO live model" — an ordinary live rep can carry it — and referenced a `single()` sort that F20 replaced; both corrected. The bundled skill carried the same "read `models` back" instruction in three places (measurement hygiene, the scenario schema's `model:` comment, the repeat-batch recipe); all three now carry the caveat with it. - **Documented what the harness is *for*, not only that it is faithful.** The README leads with the record as well as the contract, and a new **"Why not just `claude -p` or the Agent SDK?"** section states the five things that are structurally hard to get otherwise — the staged Cowork agent in cowork mode, a test of the **real** router (the agent binary does discovery, so `skill_triggered` checks a `description` edit rather than your own dispatcher), real plugin loading (a failed load surfaces as a missing skill in `context.availableSkills`), **derived** run evidence a raw `stream-json` stream does not carry (`skillActivity`, `skillsInvoked`, `subagents[].referencesRead`, `ablated`, …), and the reproduced *limitations* — plus token-free replay and scripted gate answers. Mirrored in `llms.txt`. `docs/README.md`'s "I want to…" table grows from 5 rows to 11, covering the questions the harness uniquely answers (did the skill actually run · did a description edit break triggering · did it pass or pass once · does the skill beat no skill · testing a skill that asks questions · proving no egress). - **`--ablate-skill` is documented as ONE arm.** The flag runs a single invocation with the skill removed — the control arm of a with/without comparison, not both arms; composed with `--repeat N` it produces N *ablated* runs and zero treatment runs. Now stated on `skill` and `run` in the README, in `docs/scenario.md`, in the companion skill (a new **Measure** section in Part II), and in the skill's Recipe 5, which described the experiment in prose without naming the flag. The scope is stated with it: the harness supplies the runs and the control arm; designing the comparison (scrubbing, shuffling, blind judging, unblinding) is the caller's. - **A `skill`-lane `PASS` is explained.** With no `assert:` block it reports that no *guard* fired — not that the skill was invoked, nor which model or arm produced the run. New gotcha in the companion skill and a note in the README, both pointing at `skillsInvoked` / `skillActivity` / `models` / `ablated`. - **"Confirm the skill was invoked" is now the first entry in the false-green hunt** (`docs/debugging.md`), alongside the failure family it belongs to: an answer that describes work the run never did. The skill's own source is mounted where the model can read it — in production too — so an answer that reads like skill output is not evidence of invocation. - **Model pinning is documented as a measurement requirement.** Omitting `model:` emits no `--model` flag at all, so the run uses whatever the *staged agent binary* defaults to — fine for tracking the agent default, never fine for a `--repeat` batch or a before/after. `docs/session.md` and the skill's schema reference say so, and note that the ad-hoc `skill` lane has no session file, so `--model` is the only control there. - **A recorded cassette is documented as NOT relocatable.** It rewrites `scenario.session` and `scenarioSource` relative to its **own** directory at record time, so a later move (a different `--out`, a `git mv`, a copy) leaves them unresolvable and `verify-cassettes` reports `unverifiable-skill` (exit 3). New section in `docs/cassette.md`, with caveats added next to the "relocatable bundle" promise in `docs/session.md` and the skill's schema reference, and next to the host-inventory record refusal — where `fidelity: container`, not an out-of-repo `--out`, is the answer. - **Assertion families now state their ceiling, not just their members.** The gate keys match question **text**, counts and delivery — no key asserts a gate's **option set or order** (the options are recorded at `decisions[].questions[].options[]`); `no_unexpected_files` is an allowlist over *newly created* files and is not a stand-in for "file X must not exist"; `skill_tool_used` counts **sub-agent** calls inside the window and matches tool **names** only, so it can say neither which agent called nor with what path. `allow_stall` is marked scenario-only — an open-ended `skill` run has no `assert:` block and therefore no way to suppress a `stalled` verdict. - **`lint` messages corrected and de-noised.** The unknown-assertion-key warning said the harness "would ignore it, so it silently does nothing"; `run`/`skill`/`record` in fact **reject** the scenario at load, and the message now says so and names the negative-form keys people reach for. The two unconditional INFO advisories (`manifest-needs-snapshot`, `gate-needs-controlout`) are reworded from imperative "re-record…" to "no action needed if your cassette is current", and `positional-choose-order` now notes that unstable option order is also what the *user* sees, not only a re-record flake. - **`verdict.failures[]` documented as the machine-readable failure breakdown** (`references/ci-recipe.md`): entries carrying an `assertion` key are your failed assertions; entries without one are guard signals, infra errors, or — under `replay --assert-from`/`--reassert` — skill-source drift. Both land on exit 1, so the exit code cannot separate them and the envelope can. - **`sync` mis-scanned the Desktop bundle, and it had been doing so silently since Desktop 1.25927.0.** `normalizeBundleQuotes` — the tokenizer that rewrites the bundle's backtick literals so every anchor in `sync` can be written against one quoting style — carried three defects that each desynchronised it, so that from the first bad character onward it paired the CLOSING backtick of one string with the OPENING backtick of the next. Downstream, whole regions were left unnormalised (every anchor over them reads as "gone") and stretches of code were rewritten into string literals. On Desktop 1.32352.0 this produced **32** unknown deltas of which **21** were phantom — and, less obviously, it *masked* four real ones, so the flag list was wrong in both directions rather than merely noisy. The three: an interpolation is code and may contain a **regex literal**, so a quote inside one (the POSIX shell-quote escaper `` `'${t.replace(/'/g, …)}'` ``) opened a phantom string; the regex-vs-division test admitted only punctuation, so a regex in a **keyword** context (`return/…/`) was read as division; and a substitution-free **tagged** template was rewritten into a string, which stops the tag being called and leaves text no parser accepts. Guarded by a parser oracle rather than by more anchors: `normalizeBundleQuotes` is now required to emit output that still parses, and that contains exactly the same multiset of string values as its input — a desync mints strings that were never in the source. It runs over every chunk of the installed Desktop bundle and skips cleanly where there is no install. The previous check — confirming that one known key had normalised — stayed green through two of the three defects. `sync` now also carries the tripwire itself, because that oracle needs a Desktop install and so never runs in CI — while `sync --diff` is the first thing run when a release lands. Any chunk whose normalized text stops parsing is reported **above** the deltas, saying in as many words that absent anchors may be phantom *and* real deltas may be masked. It is fail-soft by construction: a chunk is reported only when the RAW text parses and the normalized text does not, so a future Desktop shipping syntax the parser does not know reads as "not our damage" rather than blocking every sync. - **The path-gate and Artifact sentinels survive a release that mangles exported CONSTANT names.** Desktop 1.32352.0 renamed `HOST_LOOP_PATH_GATED_BUILTIN_TOOLS` to `Cg` (and `HOST_LOOP_EXCLUDED_BUILTIN_TOOLS`, `REQUEST_COWORK_DIRECTORY`, `SESSION_TYPE_CHAT` with it) while the values behind them stayed byte-identical, so every path-hook anchor reported the machinery "gone". The guidance to never anchor on a minified *member* name did not cover exported *constants*. Each now binds by content — the defining chunk is resolved through the install site's spread, the tool-set arrays are matched literally and then required to still be exported, and the two constants are anchored on their values. A second codegen change in the same release (arrow bodies are now parenthesised) is admitted the same way. `checkPathHookFacts` gains the real-asar regression test its two sibling checkers already had — its absence is why this reached `sync` with nothing red. - **The host-loop `canUseTool` chain is checked as a whole, including its new wrapper.** Production moved the `??` chain inside a block body wrapped by a pre-pass that can deny before any link runs and a post-pass that can turn the chain's ALLOW into a DENY. Teaching the extractor the block shape alone would have silenced three flags while leaving both new decision points invisible, so the wrapper is pinned too: the pre-pass must be awaited (an un-awaited async link yields a Promise, which is never nullish, so the early deny and the veto both go inert), must still carry the `/sessions` VM-path deny, and the chain's result must still flow through its `finish()`. Separately, the frame-artifacts predicate legitimately **dropped** its `!isHostLoop` term — `Artifact` now reaches the host-loop tier — so both term lists are admitted while the remaining tier restrictions are pinned. - **Prompt fingerprints compare rendered content, not codegen.** The Cowork system-prompt and sub-agent-append fingerprints hashed the RAW minified template source, justified as being independent of minifier-assigned names. It is not independent of **escape form**: Desktop 1.32352.0 began emitting non-ASCII as `\uXXXX`, which moved the prompt hash by +630 code points and moved **both** sub-agent branch fingerprints — while the rendered text was byte-identical, as a diff of the decoded bodies confirms. Every fingerprint now also records a `decodedSha256`/`decodedCodePoints` over the body with escapes resolved, and drift is judged on those; a raw-only move is reported as a re-stamp note instead of an unknown delta. The raw hashes stay — they are the committed history — and an entry predating the decoded pair still compares raw, saying so in the message. The golden-oracle test that pinned the 1.20186.0 raw hash was a version pin in an invariant's clothing (it went red the day Desktop updated, for no product reason); it now asserts the rendered-prompt hash, which genuinely has not moved since 1.20186.0. ## [1.23.0] — 2026-08-14 ### Added - **Platform baseline for Claude Desktop 1.30096.1 (bundled agent ELF `2.1.229`).** The agent ELF's `sha256` was verified against the official release manifest for 2.1.229. The modeled spawn contract is unchanged across the bump — `spawn.tools` stays 20 entries, `allowedTools` 19, the egress allowlist 15 domains, the spawn-env key set 61 with 31 conditional spreads, and the Cowork system prompt is byte-identical (its fingerprint is recorded for 1.30096.1 in `baselines/prompts/cowork-system-prompt-fingerprints.json`). `sync` refused to write this baseline until the two sentinel defects below were corrected. - **Two drift sentinels pinned in the synced baseline's `provenance.gates`**: the artifact-mount gate (`coworkArtifacts`) and the CIC `can_use_tool` handler (`cicCanUseToolEnabled`). Both are force-ON in production, and the artifact-mount gap documented in `docs/fidelity-gaps.md` rests on that fact — which was previously read from a live feature cache the baseline never recorded, so nothing would have noticed it changing. - **`check:versions` guards DESIGN.md's live-verification scope note (invariant 11).** That note is the repo's disclosure of how much of the *current* baseline has actually been verified live, and every figure in it is derivable from `baselines/desktop-*.json` — yet it sat in unguarded prose and had drifted twice, the baseline list having been extended without recounting. Understating how much is unverified is the doc error least worth shipping, so it is now checked. Two forms, selected by whether the note's live-pass baseline is the newest one: with a gap, the listed baselines must run contiguously from wherever the list starts through the newest baseline, and both counts must match the list and the real `agentVersion` transitions; with no gap, the note must say so explicitly and carry no stale enumeration. Either way the named agent must be the newest baseline's. Because shipping a baseline flips the no-gap form into the gap form, a new release now forces the note to be rewritten rather than silently overstating coverage. The list's *start* is deliberately not derived — the note omits baselines covered by the live pass itself, and encoding that rule would only relocate the drift. A missing or unrecognisable note is an error, never a skip. - **Cassettes now record the rootfs image they were recorded against**, closing the last gap in the agent-image provenance work. The image decides `missingCapabilityUse`, which `computeVerdict` fails on, so the rootfs is verdict-affecting — yet no cassette field named it, and a recording silently inherited whatever image happened to be on the machine. `environment.agentImage` now carries the resolved `ref` plus whichever identities exist: `configId` (the local config id, present for built **and** pulled images but not comparable across machines) and `registryDigest` (the registry manifest digest, pulled images only, and the only identity comparable across machines). The field is stamped only for the tiers whose capabilities actually come from that image — `container` and `hostloop`. `microvm` probes the Lima guest instead, so it records nothing rather than naming an image that had no bearing on the run. Additive: no `cassetteVersion` bump, absent on cassettes recorded before the field existed, and never backfilled — the absence is meaningful. `ref` is a verbatim `COWORK_AGENT_IMAGE` value, so a private registry ref (`registry.acme.corp/…`) would otherwise be committed into a public fixture with `grep`-clean transcript text. It is scanned by `verify-cassettes` and rewritten by redaction like every other user-controlled string; the digests are content hashes and are deliberately left intact. - **`replay` warns when the rootfs image differs from the recording.** It compares `registryDigest` first — the only identity stable across machines, which is the case the field exists to serve — and falls back to the local config id only when neither side has a registry digest. A recording made against a pulled image and replayed against a local rebuild is reported as drift rather than passing silently. Advisory only: a legitimately re-pulled image is the common case, so this names the difference instead of failing the replay. The current image is inspected at most once per `replay` invocation, and only when a cassette actually recorded one — so replay stays usable with no container runtime present, and the `verify-cassettes` privacy scan never shells out. ### Fixed - **The host-loop `canUseTool` chain sentinel could be widened silently.** Desktop 1.30096.1 inserts a fourth link into the chain — an allow carve-out that rewrites the tool's input and runs ahead of the existing deny. The sentinel was a prefix match with no terminator, so it accepted any chain that merely *started* with the expected calls: an inserted **synchronous** link would have passed unnoticed, and the block that surfaced this release only happened because the new link is `await`ed. The check now decomposes the chain with a real scanner (the assignment must be brace/paren-balanced, and `??` legitimately occurs inside a template interpolation in the chain's own log line) and asserts it end to end: the terminal operand must be a bare call to the saved original, every operand whose callee is an `async function` must be awaited, no link that can return an allow may precede the VM-path deny, and each link must resolve to a definition. The await rule is the load-bearing one — an un-awaited async link returns a Promise, which is never nullish, so `??` short-circuits and every later link *including the original callback* is skipped. Three and four link chains are both accepted so an older Desktop still syncs; a fifth is reported for classification. - **The early-allow ordering check had never fired.** It searched for a containment helper by two readable names, neither of which occurs in any shipped asar — production mangles the call — so the guard was permanently inert and its test passed only because the fixture hard-coded a token that does not exist in the product. The helper is now identified by shape and resolved through the export map. - **S6c no longer hard-blocks on a minifier rename.** It pinned the HIPAA-restriction call by its minified *member name*, so the rename `A.r()` → `t.hu()` failed a predicate that is otherwise byte-for-byte identical. The callee is now resolved through the chunk's export map and verified two hops to the reader that consults the restriction, with resolution failure treated as a miss. - **The `protocol`-tier live suite had been silently skipping itself for many releases.** `live-matrix` required a staged agent binary for a baseline pinned years back, but protocol fidelity spawns the host `claude` from `PATH` and never resolves a staged binary — the requirement was never real for that tier. Because Claude Desktop prunes old staged agents on update, the gate went false as soon as a machine moved past that agent version, and the suite dropped out on every developer machine and in CI without naming itself. It now gates on what the tier actually uses and emits a skip notice identifying the failing precondition, since this is the only protocol-tier live coverage there is. - **The `hostloop` uploads-are-`Read`-able live case no longer fails on the model's choice of exploration tool.** It asserted that neither native nor workspace bash ran at all, as a proxy for "the agent needed a workaround" — so a run where the agent listed the uploads directory with `ls` went red, while the next run, which used `Glob` instead, went green. In both the upload was `Read` directly at the advertised path and no outputs-delete fired, so the regression the case guards was absent either way. It now reads the recorded bash commands and fails only when one **names the uploaded file**, which is what reading or copying it as a workaround requires and what listing its directory cannot do. Verified against both recorded runs plus `cat`/`cp` mutations: the false red is gone and the workaround chain still trips it. ### Documentation - **A full live end-to-end pass now covers baseline `desktop-1.30096.1` / agent 2.1.229**, across all three tiers (`protocol`, `container`, `hostloop`), superseding the `desktop-1.20186.0` pin. DESIGN.md's claim and its scope note are re-stamped accordingly, including the caveats: two `live-outputs-delete` cases skipped as model-behaviour misses, the tiers were covered across two invocations because the `protocol` suite was repaired mid-pass, and the suites are model-dependent enough that a single red is evidence of variance until a re-run says otherwise. - **`docs/fidelity-gaps.md`'s artifacts section records the agent-side consent floor.** The server-delivered session flag no longer only decides Desktop's spawned tool list — the agent reads the corresponding spawn-env key itself and uses it to select its own artifact publish surface and a read-only mode. The agent also refuses artifact publishes, comment replies, comment-thread resolves and artifact database writes outright in a session with no answerable approval surface, and fails closed if it cannot confirm one. The section now also states why this is recorded rather than modeled: artifact operations are server-backed, on hosts outside the sandbox egress allowlist, so supplying the flag would offer a tool resolving against a service the sandbox cannot reach. - **The same section's mount-kind list is corrected.** It named a synthetic root that is not a mount kind and omitted one that is, which mattered because the artifact-mount gap is stated in terms of what the harness does and does not mount. - **`docs/maintenance.md` corrects what moves the floating agent-image `:2` tag.** It is a curated pointer moved deliberately by a manual publish with `immutable_only` unchecked — explicitly *not* something a release tag push moves. ## [1.22.0] — 2026-08-12 ### Added - **Platform baseline for Claude Desktop 1.28929.0 (bundled agent ELF `2.1.227`).** The modeled first-party spawn contract is unchanged: `spawn.tools` stays 20 entries, `allowedTools` 19, and the egress allowlist 15 domains. The Cowork system prompt, the sub-agent append, `coworkSyspromptMap` and the mount-mode anchors all passed unchanged, and the VM rootfs image is byte-identical, so no provisioning re-capture. The ELF's SHA-256 matches Anthropic's official `linux-arm64` release manifest checksum. All three committed cassettes replay clean (re-stamped, not re-recorded — replay runs no live agent, so their recorded behaviour could not move). Two spawn-contract deltas, both classified rather than bypassed: - Desktop can now splice an **`Artifact` tool** into the session tool list, between `AskUserQuestion` and `ToolSearch`. It is selected by a **server-delivered session flag**, not a feature gate — the flag arrives with the session config alongside `memoryEnabled`/`skillsEnabled`, so it is invisible to gate diffing and can change without a Desktop release. It is off for a default first-party session, so the rendered tool list is unchanged and `Artifact` is **not** added to the pin. - Desktop constructs one new spawn-env key, `CLAUDE_CODE_COWORK_FRAME_ARTIFACTS`, gated on that same flag. It is **allowlisted rather than pinned**: a default session never receives it, so pinning would bake a value into the baseline that production does not send. `provenance.spawnEnvKeys` grows 60 → 61 to record that Desktop constructs it. Also recorded: the `coworkRuntimeConfig` gate now serves a **1 h** (was 15 min) TTL for the host-loop `web_fetch` dedup cache. The harness reads that value from the baseline, so the change is carried automatically; the code-level fallback is unchanged and still mirrors Desktop's own absent-key default. - **Guards for the conditional `Artifact` tool and its spawn-env key.** `sync` admits the new spread only while it still resolves to the frame-artifacts predicate. The check walks the real chain — condition → attended-turn wrapper → predicate — capturing each callee rather than hard-coding minified names, and matches the condition as a **whole expression anchored at both ends**. Fragment matching is not sufficient and was the defect in an earlier draft: appending `||!0`, flipping the cached arm, or replacing the trailing restriction all make `Artifact` unconditional while still containing the right call. A companion check asserts the env key stays gated on the **same** predicate as the tool, in both directions, because allowlisting a key is unconditional by construction — without it, making either unconditional or re-keying one of them would be absorbed silently. Fifteen mutations covering these paths are executed as tests. - **Two drift sentinels** in the synced baseline's `provenance.gates`: the skill-argument collection guidance flag (on for a standard account) and the auto-mode permission rubric flag (dark). Neither flag name appears in the asar, so both carry kebab-case descriptors under the existing name caveat rather than names shaped like verified flags. ### Changed - **The tools-list tail guard now pins the whole tail.** It previously anchored only on the first spread after `ToolSearch`, leaving everything past it unguarded — which defeated its own stated purpose, since a tool appended there was invisible to both it and the head check. That region already held a second conditional tool. The tail is now pinned through its closing bracket, with the trailing tool's name and its condition both **resolved** rather than shape-matched: swapping either would otherwise pass silently. - **The CI boundary-parity job pulls the pinned agent-image digest instead of the floating `:2` tag.** CI previously certified whatever was published last while `doctor` certified the pin, so a green CI said nothing about the pinned image and vice versa. Both now validate the same bytes, and a pin naming a digest that was never pushed fails the gate rather than silently falling back to a rebuild. ### Fixed - **The egress proxy answered nothing when a CONNECT upstream failed before the tunnel was established.** A transient failure on an **allowlisted** host — DNS, a TCP reset, an unreachable route — destroyed the client socket with no HTTP response and no log record anywhere. The client saw the proxy accept CONNECT and then vanish (`curl: (56) Proxy CONNECT aborted`), and container logs were empty, so an intermittent left nothing to diagnose. The asymmetry was accidental: the plain-HTTP forward path already answered 502 on the same class of failure. CONNECT now matches it and emits a structured `upstream_error` line. The 502 is written only *before* the tunnel is established — afterwards the socket is a raw tunnel and an HTTP status would corrupt the stream. No egress-log row is written either way: `allow` is recorded only after a successful connect precisely so a failed request cannot false-pass `egress_allowed`, and `deny` would be untrue since the host is allowlisted and nothing was blocked. **The egress proxy image tag moves to `cowork-egress-proxy:5`.** The tag is the cache key, so existing installs would otherwise keep serving the old proxy while `doctor` reported it healthy. No action is required — the image is rebuilt automatically when the tag is absent. - **The two allowlisted boundary probes retry** (`--retry 2 --retry-all-errors`). A single-shot request through the proxy is exposed to the same ordinary transients, which failed a probe once in eight runs while the sandbox was behaving correctly. The off-list probes deliberately do **not** retry: they assert a 403 deny, and retrying a policy decision could turn a real enforcement failure into a later pass. - **Release tags no longer move the floating `:2` agent-image tag.** Every release rebuilt both image variants and repointed `:2`, while nothing re-recorded `docker/agent-image.json` — whose digests are transcribed by hand from a log line that tag-push builds never emit. Pin and tag therefore diverged permanently after the first release. `docs/maintenance.md` already stated the intended contract (move `:2` in the same release that ships the updated pin); the workflow now implements it. `:2` remains movable by an explicit dispatch, which is how a deliberate image refresh has always been described. ### Documentation - **`docs/fidelity-gaps.md` gains four sections.** *Artifacts — two mechanisms, neither modeled* (Cowork's per-artifact bind-mounts and the newer `Artifact` tool are mutually exclusive, the selecting flag is not observable locally, and the harness models neither); *HIPAA restriction is a process-global latch*; *Auto-mode permission rubric is not modeled* (dark, and scoped to sessions the harness does not model); and *Skill argument collection — the elicitation form branch is not reachable here*, which records that production splits between `AskUserQuestion` and an elicitation form while a harness run deterministically takes the former. That last one is an **open gap with a stated plan**, not a closed question. The `save_skill` section notes the tool is now additionally governed by the permission rubric. - **`RELEASING.md` gains an agent-image checklist item.** The release process never mentioned the image pin, which is what let the tag drift go unnoticed. It also notes that an unchanged `Dockerfile.agent` still yields different bytes on a rebuild, since its `apt`/`pip`/`npm` installs are unpinned. ## [1.21.1] — 2026-08-08 ### Fixed - **The agent-image pin silently skipped the full-parity variant.** `doctor` picked the local registry digest by matching only the ghcr-qualified repository (`ghcr.io/owner/name@sha256:…`). Docker records a RepoDigest per repository the image is known by, and that set is not predictable: `cowork-agent-full:2` carries only the bare `cowork-agent-full@sha256:…`. The ghcr-only filter missed it, the image was reported as a local build, and the pin check quietly did nothing for every full-parity user — a skipped check reads exactly like a passing one. Both forms are now matched, with the ghcr-qualified digest preferred when they disagree. - **A `main` CI run could be cancelled, making a good commit unpublishable.** `ci.yml` cancelled in-progress runs for any ref; `require-ci-success` requires `conclusion == success` for the SHA it checks, and `cancelled` is not it. Merging two PRs minutes apart left the earlier merge commit unpublishable. Cancellation now applies to pull-request refs only. ### Changed - **The freshness check's "works offline" property is now a guard, not a claim.** It was argued from the absence of a registry call, and an absence cannot fail when someone reintroduces one. A test now asserts the path contains exactly one spawn — the local `image inspect` — and no registry command. Comments are stripped before the check, so the guard cannot be satisfied by deleting its own rationale. - **`publish-image.yml` gains a `dry_run` input** (maintainer-facing): it runs the CI gate and the immutable-tag collision guard, then stops before building or pushing. The guard's *refusal* path was otherwise untestable without risking a repointed `:2-r`, which is the one thing a digest pin cannot survive. ## [1.21.0] — 2026-08-08 ### Upgrade notes - **`decide --decider-dir ` BLOCKS until you answer the gate — every other `decide` path returns in ~2 s.** That wait is the feature (it is a live rehearsal of the in-band rendezvous, using the same channel a real run uses), but it means a script or test that invokes this path without answering will sit on the 10-minute `COWORK_HARNESS_DECIDER_DIR_TIMEOUT_MS` backstop. Answer it with `cowork-harness answer --gate 1 --choose "