cowork-harness 2.2.0 → 2.3.0

package/dist/run/trace-view.js

@@ -362,6 +362,13 @@ export function buildGateTrace(file) {
         rows.push({
             question: req.questions.map((q) => q.question ?? q.header ?? "").join(" / "),
             requestId: req.id,
+            // The ask-time options ride along unmodified — no truncation here, only at render time, so a JSON
+            // consumer (`--output-format json`) gets the full offered text and the text view stays readable.
+            subQuestions: req.questions.map((q) => ({
+                question: q.question ?? q.header ?? "",
+                options: q.options ?? [],
+                ...(q.multiSelect !== undefined ? { multiSelect: q.multiSelect } : {}),
+            })),
             subQuestionCount: req.questions.length,
             injectedAnswer: answers.get(req.id),
             delivered: tr ? (tr.isError ? "error" : "ok") : "unobserved",
@@ -423,6 +430,36 @@ export function buildGateTrace(file) {
     }
     return rows;
 }
+/** Per-option description cap in the TEXT view only. Long enough for the producer-authored sentence a
+ *  founder is deciding on; short enough that a gate offering four options stays one screen. The JSON
+ *  envelope carries the untruncated text, so nothing is lost — only wrapped. */
+const GATE_OPTION_DESC_CAP = 240;
+/** The offered options of one gate, indented under it. Rendered for EVERY gate that recorded options —
+ *  not only bundled ones — because the whole point is that this text was previously invisible. A gate
+ *  whose payload carried no options at all renders nothing extra rather than an empty `offered:` header. */
+function formatGateOptions(subs) {
+    if (!subs.some((s) => s.options.length))
+        return "";
+    const multi = subs.length > 1;
+    const out = [];
+    for (const s of subs) {
+        if (!s.options.length)
+            continue;
+        // The sub-question label is repeated only on a bundled gate; on a single-sub-question gate it is
+        // already the row's headline and repeating it is noise.
+        if (multi)
+            out.push(`    ${s.question}${s.multiSelect ? " (multi-select)" : ""}:`);
+        else if (s.multiSelect)
+            out.push(`    (multi-select)`);
+        for (const o of s.options) {
+            const desc = o.description === undefined || o.description === ""
+                ? ""
+                : ` — ${o.description.length > GATE_OPTION_DESC_CAP ? o.description.slice(0, GATE_OPTION_DESC_CAP) + "…" : o.description}`;
+            out.push(`    ${multi ? "  " : ""}• ${o.label}${desc}`);
+        }
+    }
+    return out.length ? `\n    offered:\n${out.join("\n")}` : "";
+}
 export function formatGateTrace(rows) {
     if (!rows.length)
         return "(no AskUserQuestion gates in this run)";
@@ -432,7 +469,8 @@ export function formatGateTrace(rows) {
         // sub-question count is shown only when the gate bundled more than one — reconciles this row
         // against questions_count_max, which counts sub-questions, not gates.
         const subCount = r.subQuestionCount > 1 ? ` (${r.subQuestionCount} sub-questions)` : "";
-        return `${mark[r.delivered]} gate "${r.question}"${subCount}\n    answered: ${r.injectedAnswer ?? "(none)"}\n    delivered: ${r.delivered}${r.error ? ` — ${r.error}` : ""}${prov}`;
+        const offered = formatGateOptions(r.subQuestions ?? []);
+        return `${mark[r.delivered]} gate "${r.question}"${subCount}${offered}\n    answered: ${r.injectedAnswer ?? "(none)"}\n    delivered: ${r.delivered}${r.error ? ` — ${r.error}` : ""}${prov}`;
     });
     const totalSubQuestions = rows.reduce((sum, r) => sum + r.subQuestionCount, 0);
     lines.push(`\n${rows.length} gate(s), ${totalSubQuestions} sub-question(s) total — questions_count_max counts sub-questions (assert with \`questions_count_max: ${totalSubQuestions}\`)`);

package/dist/sync/cowork-sync.js

@@ -1179,10 +1179,23 @@ export function checkCodeTripwires(bundle) {
         flags.push(`NOTE: code tripwire: io.modelcontextprotocol/skills capability appears ${skillsExt}x (was 1) — the MCP-skills capability surface changed; re-verify whether MCP servers can now contribute skills`);
     return flags;
 }
+/** Sites building the delete-deny resolver on the newest baseline (Desktop 1.37937.1): the VM-loop
+ *  mount-set builder and host-loop `computeBashMounts`. A FLOOR, not an equality — see its use site. */
+const MOUNT_DELETE_DENY_MIN_SITES = 2;
 export function checkMountModeFacts(bundle) {
     const flags = [];
-    if (!/\?"rwd":"rw"/.test(bundle))
-        flags.push('mountLayout: the delete-deny resolver (IX `…?"rwd":"rw"`) is gone from the asar — outputs/projects default mode may have changed; re-derive mountLayout.mounts[].mode (see baselines $comment_modes)');
+    // The delete-deny resolver. A bare `.test()` was the same single-anchor hole the per-mount checks below
+    // just closed: the resolver is now built on BOTH lanes (1 site in Desktop 1.34493.1, 2 from 1.37937.0),
+    // so once one lane has it, `.test()` cannot see the other lane losing it. Guard a FLOOR rather than an
+    // exact count — a lane gaining the resolver is benign and must not red a sync, a lane losing it is the
+    // containment change. The floor is the count observed on the newest baseline; raise it deliberately
+    // when a release adds a lane. Running `sync` against a Desktop OLDER than the floor's release will
+    // flag, which is correct: that install does not build what the pinned baseline describes.
+    const denySites = (bundle.match(/\?"rwd":"rw"/g) ?? []).length;
+    if (denySites < MOUNT_DELETE_DENY_MIN_SITES)
+        flags.push(`mountLayout: the delete-deny resolver (IX \`…?"rwd":"rw"\`) is built at ${denySites} site(s), below the pinned floor of ` +
+            `${MOUNT_DELETE_DENY_MIN_SITES} — an execution lane lost delete-deny resolution, so outputs/projects default mode may have ` +
+            "changed on that lane; re-derive mountLayout.mounts[].mode per lane (see baselines $comment_modes)");
     // Every mount whose mode is HARDCODED at the mount-set builder, rather than resolved through
     // NOTE the lane difference, because "spawn-time" is wrong for half of it: the VM-loop builder runs
     // once at spawn, but the host-loop one is wired as `computeBashMounts` and RECOMPUTES PER BASH CALL
@@ -1192,18 +1205,30 @@ export function checkMountModeFacts(bundle) {
     // outputs and each connected folder go through the resolver (`rw`, or `rwd` once approved) while these
     // are pinned `"ro"`. Worth pinning individually because a mount silently moving from `ro` to a
     // writable mode is a containment change we would otherwise model wrongly with nothing failing.
+    //
+    // EVERY SITE must carry the mode, not merely one of them. Each of these names is built at TWO sites —
+    // the VM-loop mount-set builder and host-loop `computeBashMounts` — and an `re.test(bundle)` is
+    // satisfied by either, so a one-lane `ro`→`rw` flip (a real containment change on exactly one
+    // execution tier) passed green. Comparing the site count to the with-mode count closes that: the
+    // `site` pattern locates the mount irrespective of its mode, `ro` requires the mode too.
     const hardcodedRo = [
-        ["uploads", /\("uploads"\)\][^}]{0,90}mode:\s*"ro"/],
-        [".claude/skills", /\("\.claude\/skills"\)\][^}]{0,120}mode:\s*"ro"/],
-        [".claude/projects", /\("\.claude\/projects"\)\][^}]{0,120}mode:\s*"ro"/],
+        ["uploads", /\("uploads"\)\]/g, /\("uploads"\)\][^}]{0,90}mode:\s*"ro"/g],
+        [".claude/skills", /\("\.claude\/skills"\)\]/g, /\("\.claude\/skills"\)\][^}]{0,120}mode:\s*"ro"/g],
+        [".claude/projects", /\("\.claude\/projects"\)\]/g, /\("\.claude\/projects"\)\][^}]{0,120}mode:\s*"ro"/g],
         // Project ATTACHMENTS (`userSelectedProjectUuids`) — one mount per uuid, read-only. This is the fact
         // that settles whether a project mount belongs in the delete-denied set: it does not, because it is
         // not writable at all.
-        [".projects/<uuid>", /\(`\.projects\/\$\{[^}]+\}`\)\][^}]{0,90}mode:\s*"ro"/],
+        [".projects/<uuid>", /\(`\.projects\/\$\{[^}]+\}`\)\]/g, /\(`\.projects\/\$\{[^}]+\}`\)\][^}]{0,90}mode:\s*"ro"/g],
     ];
-    for (const [name, re] of hardcodedRo)
-        if (!re.test(bundle))
+    for (const [name, siteRe, roRe] of hardcodedRo) {
+        const sites = (bundle.match(siteRe) ?? []).length;
+        const ro = (bundle.match(roRe) ?? []).length;
+        if (sites === 0)
             flags.push(`mountLayout: the read-only ("ro") mount for ${name} is gone from the asar — its mode may have changed; re-derive mountLayout.mounts[].mode (see baselines $comment_modes)`);
+        else if (ro !== sites)
+            flags.push(`mountLayout: ${name} is built at ${sites} site(s) but only ${ro} carry mode:"ro" — one execution lane's mount became writable; ` +
+                `re-derive mountLayout.mounts[].mode per lane (see baselines $comment_modes)`);
+    }
     return flags;
 }
 /**
@@ -2108,7 +2133,22 @@ const SPAWN_PIN_KEYS = [
     // what is new is the Cowork spawn setting it outright.
     "CLAUDE_PREVIEW_CLASSIFIER_FLOOR",
     "DISABLE_AUTOUPDATER",
+    // Desktop 1.37937.0. MCP_TOOL_TIMEOUT is the first key that is BOTH 1p-pinned and 3p-constructed:
+    // W1 builds it unconditionally (`String(<getter>())` → the `??18e4` default), and the 3p-only branch
+    // in W3 gained a second, settings-conditional site (`...i!==void 0&&{MCP_TOOL_TIMEOUT:String(i)}`,
+    // `i` a chunk-local `let`). It stays PINNED here, on its W1 site. Allowlisting it instead would be a
+    // silent contract loss: resolveInto checks SPAWN_ENV_ALLOWLIST BEFORE this list, so the key would
+    // vanish from the generated env entirely — and it is not in REQUIRED_SPAWN_KEYS, so nothing would
+    // hard-fail. The 3p site is handled per-SITE by the branch rule in applyWindow, not per-key here.
     "MCP_TOOL_TIMEOUT",
+    // Desktop 1.37937.0. Both UNCONDITIONAL in W1 (no gate, no session/deployment branch), constructed as
+    // plain string literals between ENABLE_APPEND_SUBAGENT_PROMPT and ENABLE_PROMPT_CACHING_1H — which is
+    // still set, so these are ADDITIVE rather than its replacement. Same call as
+    // CLAUDE_PREVIEW_CLASSIFIER_FLOOR above: unconditional in W1 ⇒ every first-party Cowork session
+    // receives them ⇒ pin, so a later gate or value change is a --diff line, not a silent shift. They read
+    // 0 times in agent 2.1.241 and 6 times each in 2.1.246, so this is a live contract, not a dormant one.
+    "CLAUDE_CODE_PROMPT_CACHE_TTL",
+    "CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL",
     "USE_LOCAL_OAUTH",
     "USE_STAGING_OAUTH",
 ];
@@ -2307,6 +2347,101 @@ function braceScanWindow(bundle, anchor) {
     }
     return null;
 }
+/**
+ * The literal that marks the 3p-only deployment branch. Anchoring on CONTENT rather than on the
+ * predicate identifier is deliberate: the branch reads `...n&&{…}` where `n=<deployment>().type==="3p"`
+ * is bound in the enclosing FUNCTION HEADER, which sits before every window's start anchor — so `n`
+ * cannot be resolved from inside the window, and hard-coding `n` would be exactly the minified-name
+ * anchoring that has broken sentinels three releases running (S6c, Cg, S14b). DISABLE_GROWTHBOOK has
+ * been the first key of that literal in every build on record, and SPAWN_ENV_ALLOWLIST already treats
+ * it as the branch's canonical marker in prose.
+ */
+const THIRD_PARTY_BRANCH_MARKER = "DISABLE_GROWTHBOOK:";
+/**
+ * The `mcp__` membership of the spawn's `allowedTools[]`, pinned as a SET (S10b). Read from Desktop
+ * 1.37937.1; `mcp__plugins__search_connectors` is the entry that was new in 1.37937.0 and that S9/S10
+ * could not see. Note this array is the pre-approval list only — a name here does not mean the tool is
+ * OFFERED: `search_connectors` is declared solely on the 3p deployment
+ * (`getDynamicTools:()=>…type==="3p"?[…]:[]`, and its handler branch re-checks the same predicate), so
+ * the first-party inventory the harness serves is unaffected. Re-classify, then re-pin, on any delta.
+ */
+const SPAWN_ALLOWED_MCP_TOOLS = [
+    "mcp__mcp-registry__search_mcp_registry",
+    "mcp__mcp-registry__suggest_connectors",
+    "mcp__mcp-registry__list_connectors",
+    "mcp__plugins__search_plugins",
+    "mcp__plugins__search_connectors",
+    "mcp__plugins__suggest_plugin_install",
+    "mcp__plugins__list_plugins",
+    "mcp__skills__list_skills",
+    "mcp__skills__suggest_skills",
+    "mcp__scheduled-tasks__list_scheduled_tasks",
+    "mcp__computer-use",
+];
+/**
+ * Slice the SPAWN's balanced `allowedTools:[…]` array text (bracket-aware, so a nested `[]` cannot end
+ * it early). Anchored on the built-in head S9 pins, NOT on the bare `allowedTools:[` — the joined bundle
+ * holds several unrelated `allowedTools` arrays (settings schemas, the bundled CLI) and the first one is
+ * not the spawn's. A first-match slice reported all 11 pinned tools as removed at once, which is what a
+ * mis-anchored window looks like: a total, implausible delta rather than a plausible one.
+ */
+function sliceAllowedToolsArray(bundle) {
+    const a = bundle.search(/allowedTools:\["Task","Bash","Glob","Grep","Read","Edit","Write","NotebookEdit","WebFetch"/);
+    if (a < 0)
+        return null;
+    const open = bundle.indexOf("[", a);
+    let depth = 0;
+    for (let i = open; i < bundle.length; i++) {
+        const c = bundle[i];
+        if (c === "[")
+            depth++;
+        else if (c === "]") {
+            depth--;
+            if (depth === 0)
+                return bundle.slice(open, i + 1);
+        }
+    }
+    return null;
+}
+/**
+ * Slice the `...<pred>&&{…}` spread whose balanced body contains the 3p marker, or null when the window
+ * carries no such branch (W1/W2 today). Returns the WHOLE spread text (`...<pred>&&{…}`) so the caller
+ * can blank it wholesale. Brace matching is string-aware, since the body holds nested spreads and
+ * quoted values.
+ */
+function sliceThirdPartyBranch(text) {
+    for (const m of text.matchAll(/\.\.\.[^{}]{0,80}?&&\{/g)) {
+        const open = m.index + m[0].length - 1;
+        let depth = 0;
+        let q = null;
+        for (let i = open; i < text.length; i++) {
+            const c = text[i];
+            if (q) {
+                if (c === "\\")
+                    i++;
+                else if (c === q)
+                    q = null;
+                continue;
+            }
+            if (c === '"' || c === "'" || c === "`") {
+                q = c;
+                continue;
+            }
+            if (c === "{")
+                depth++;
+            else if (c === "}") {
+                depth--;
+                if (depth === 0) {
+                    const body = text.slice(open, i + 1);
+                    if (body.includes(THIRD_PARTY_BRANCH_MARKER))
+                        return text.slice(m.index, i + 1);
+                    break;
+                }
+            }
+        }
+    }
+    return null;
+}
 /** Parse `K:"v"`-style inner pairs of a `{…}` object body (used for gate-conditional spread inners). */
 function enumSpawnKeys(text) {
     const out = [];
@@ -2403,6 +2538,27 @@ export function deriveSpawnEnv(bundle, gates, files) {
             hardFail = true;
         }
     };
+    // Inner key of the 3p-only branch (`...<deploymentType==="3p">&&{…}` — located by CONTENT, see
+    // THIRD_PARTY_BRANCH_MARKER). Classify by NAME ONLY: the branch is the classifier, and the harness
+    // models a FIRST-PARTY session, so no value inside it can ever reach the modeled env.
+    //
+    //  - allowlisted → fine (this is what every "3p-provider-only branch" entry already means);
+    //  - PINNED → fine, and deliberately NOT resolved. A pinned key earns its value from its 1p site in
+    //    W1/W2; a 3p-only expression says nothing about it. Resolving here would (a) flag on shapes that
+    //    are irrelevant to the modeled session — Desktop 1.37937.0's `String(i)`, where `i` is a
+    //    chunk-local `let` — and (b) be actively dangerous if it DID resolve: `resolveConst` hops a
+    //    1-char name against a whole 2 MB chunk, so a build whose first `i=` happened to be numeric would
+    //    silently write a 3p value. W1 is applied last and would win either way, so nothing is lost.
+    //  - unknown → still a hard-fail. A brand-new key must be classified even here, which is the whole
+    //    point of keeping the branch enumerated rather than discarding it.
+    const classifyThirdPartyInner = (rawKey) => {
+        if (SPAWN_ENV_ALLOWLIST[rawKey] !== undefined)
+            return;
+        if (SPAWN_PIN_KEYS.includes(rawKey))
+            return;
+        flags.push(`spawn.env: unknown key ${rawKey} constructed in the 3p-only deployment branch — ${SPAWN_ADVICE}`);
+        hardFail = true;
+    };
     // A window's non-gate-spread keys. Gate-conditional spreads (…<helper>("id")&&{…}) are handled first
     // (they must be resolved against gate STATE, not read as plain literals — an off-gate NONBLOCKING:"0"
     // must not override W2's "true"), then blanked so the generic pass never sees them. Helper name is
@@ -2410,6 +2566,31 @@ export function deriveSpawnEnv(bundle, gates, files) {
     const applyWindow = (text, target, isW1) => {
         let work = text;
         const scope = chunkFor(text);
+        // The 3p-only branch (W3 today; W2 would be handled the same way). Blanked BEFORE the generic pass so
+        // it never reads the branch's inner keys as unconditional 1p literals.
+        //
+        // NOT applied to W1, deliberately. W1 is the window every modeled 1p key comes from, so a marker
+        // appearing there is either a Desktop restructure or a false positive — and blanking on either would
+        // silently delete real pinned keys from the derived env, an all-or-nothing contract violated
+        // quietly. Flag and let the generic pass run instead: worst case the branch's keys read as
+        // unconditional (loud, diff-visible), never a silent deletion.
+        if (isW1) {
+            if (sliceThirdPartyBranch(work) !== null) {
+                flags.push(`spawn.env: the 3p-only deployment branch (marker \`${THIRD_PARTY_BRANCH_MARKER}\`) now appears in W1, the window the ` +
+                    `modeled first-party env is derived from — re-derive which window owns the deployment split before trusting this env; ${SPAWN_NO_BYPASS}`);
+                hardFail = true;
+            }
+        }
+        else {
+            const tp = sliceThirdPartyBranch(work);
+            if (tp) {
+                for (const k of enumSpawnKeys(tp)) {
+                    enumerated.add(k.key);
+                    classifyThirdPartyInner(k.key);
+                }
+                work = work.replace(tp, "");
+            }
+        }
         if (isW1) {
             // B6: the gate helper acquired an `o.`-style receiver here too (`...o.isFeatureEnabled("id")&&{…}`);
             // without this widening the block is never blanked and the generic pass below reads its inner keys
@@ -2718,6 +2899,24 @@ export function checkSpawnContractFacts(bundle, files) {
         miss("S9 allowedTools head", "the allowedTools[] head list moved (AskUserQuestion is tools-only)");
     if (!has(/allowedTools:\[[^\]]{0,400}"ToolSearch","mcp__/))
         miss("S10 allowedTools tail-guard", "the built-in→mcp__ boundary moved");
+    // S10b (Desktop 1.37937.0): S9 pins the built-in HEAD and S10 only the built-in→mcp__ BOUNDARY, so the
+    // `mcp__` region between the boundary and the closing bracket was unguarded — and a real addition
+    // (`mcp__plugins__search_connectors`) shipped through both of them green. Pin the membership itself.
+    // A set comparison, not a literal regex, so the flag NAMES the delta instead of just saying "moved".
+    {
+        const arr = sliceAllowedToolsArray(bundle);
+        if (arr == null)
+            miss("S10b allowedTools mcp__ membership", "the allowedTools[] array could not be sliced");
+        else {
+            const seen = new Set((arr.match(/"mcp__[^"]*"/g) ?? []).map((s) => s.slice(1, -1)));
+            const pinned = new Set(SPAWN_ALLOWED_MCP_TOOLS);
+            const added = [...seen].filter((t) => !pinned.has(t)).sort();
+            const gone = [...pinned].filter((t) => !seen.has(t)).sort();
+            if (added.length > 0 || gone.length > 0)
+                miss("S10b allowedTools mcp__ membership", `the allowedTools[] mcp__ set changed${added.length ? ` (+${added.join(", ")})` : ""}${gone.length ? ` (-${gone.join(", ")})` : ""}` +
+                    " — classify each entry (which server serves it, and whether it is offered on the 1p deployment) before re-pinning SPAWN_ALLOWED_MCP_TOOLS");
+        }
+    }
     // S11/S12 scoped to W1; S13 scoped to W2 — the earn-the-pin assertions for local-agent / cron / provider.
     if (!w1 || !has(/CLAUDE_CODE_ENTRYPOINT:"local-agent"/, w1))
         miss("S11 ENTRYPOINT local-agent", "the W1 local-agent entrypoint literal is gone");

package/dist/types.js

@@ -222,10 +222,24 @@ const toolGlob = z
 // `cowork-harness assertions --list` (which reads `Assertion.shape[k].description`) — the list can never drift
 // from the schema. Keep descriptions one line.
 export const Assertion = z.strictObject({
-    transcript_contains: z.string().min(1).optional().describe("the transcript contains this literal substring"),
-    transcript_not_contains: z.string().min(1).optional().describe("the transcript does NOT contain this literal substring"),
-    transcript_matches: z.string().optional().describe("regex (case-insensitive) over the transcript — fuzzy content for stochastic prose"),
-    transcript_not_matches: z.string().optional().describe("regex (case-insensitive) that must NOT match the transcript"),
+    transcript_contains: z
+        .string()
+        .min(1)
+        .optional()
+        .describe("the transcript contains this literal substring. Sees top-level assistant_text ONLY — it excludes every tool_use/tool_result, so text the agent emitted inside a tool call (an AskUserQuestion gate question, an option label or description) can never match at any phrasing"),
+    transcript_not_contains: z
+        .string()
+        .min(1)
+        .optional()
+        .describe("the transcript does NOT contain this literal substring. Sees top-level assistant_text ONLY — it excludes every tool_use/tool_result, so text the agent emitted inside a tool call (an AskUserQuestion gate question, an option label or description) can never match at any phrasing"),
+    transcript_matches: z
+        .string()
+        .optional()
+        .describe("regex (case-insensitive) over the transcript — fuzzy content for stochastic prose. Sees top-level assistant_text ONLY — it excludes every tool_use/tool_result, so text the agent emitted inside a tool call (an AskUserQuestion gate question, an option label or description) can never match at any phrasing"),
+    transcript_not_matches: z
+        .string()
+        .optional()
+        .describe("regex (case-insensitive) that must NOT match the transcript. Sees top-level assistant_text ONLY — it excludes every tool_use/tool_result, so text the agent emitted inside a tool call (an AskUserQuestion gate question, an option label or description) can never match at any phrasing"),
     tool_result_contains: z
         .string()
         .min(1)
@@ -507,12 +521,15 @@ export const Assertion = z.strictObject({
     computer_links_resolve: z
         .literal(true)
         .optional()
-        .describe("fails if any computer:// link in the model-visible transcript does not resolve to an artifact that exists in the run's collected outputs/mounts — REQUIRES at least one link (zero links FAILS: use computer_links_resolve_if_present for the presence-free variant); only `true` is valid (writing `false` is a rejected footgun — omit to skip)"),
+        .describe("fails if any computer:// link in the model-visible transcript does not resolve to an artifact that exists in the run's collected outputs/mounts — REQUIRES at least one link (zero links FAILS: use computer_links_resolve_if_present for the presence-free variant); only `true` is valid (writing `false` is a rejected footgun — omit to skip). Sees top-level assistant_text ONLY — it excludes every tool_use/tool_result, so a computer:// link that appeared only inside a tool call or its result is invisible here"),
     computer_links_resolve_if_present: z
         .literal(true)
         .optional()
-        .describe("like computer_links_resolve, but PASSES VACUOUSLY when the transcript has zero computer:// links — the lenient, presence-free variant; only `true` is valid"),
-    question_asked: z.string().optional().describe("a question matching this regex was asked"),
+        .describe("like computer_links_resolve, but PASSES VACUOUSLY when the transcript has zero computer:// links — the lenient, presence-free variant; only `true` is valid. Sees top-level assistant_text ONLY — it excludes every tool_use/tool_result, so a computer:// link that appeared only inside a tool call or its result is invisible here"),
+    question_asked: z
+        .string()
+        .optional()
+        .describe("a question matching this regex was asked. This text is model-composed and is reworded run to run — pin a producer-authored constant, not model prose"),
     question_options: z
         .strictObject({
         when_question: z
@@ -540,7 +557,20 @@ export const Assertion = z.strictObject({
         message: "question_options: set exactly one of `equals` or `contains`",
     })
         .optional()
-        .describe("assert the option SET and ORDER a gate offered the user — the founder-facing half no other gate key covers (question_asked matches question text only). Exactly one of equals|contains is required. Evidence is captured at ask time, so it covers a gate that was shown and then denied/stalled/unanswered; a run whose gate evidence is absent fails evidence-unavailable, never vacuously"),
+        .describe("assert the option SET and ORDER a gate offered the user, by LABEL (question_asked matches question text only; option DESCRIPTIONS are not compared here — use question_context for those). Exactly one of equals|contains is required. Evidence is captured at ask time, so it covers a gate that was shown and then denied/stalled/unanswered; a run whose gate evidence is absent fails evidence-unavailable, never vacuously. This text is model-composed and is reworded run to run — pin a producer-authored constant, not model prose"),
+    question_context: z
+        .strictObject({
+        when_question: z
+            .string()
+            .optional()
+            .describe("regex narrowing to sub-questions whose label matches (the same string question_asked matches); omit to search EVERY gate — unlike question_options, omitting it is not ambiguous here, because this key asks whether the text was shown at all, not which gate offered which set"),
+        matches: z
+            .string()
+            .min(1)
+            .describe("regex that must match somewhere in the selected gate(s)' founder-visible payload (case-insensitive). NON-EMPTY: an empty pattern compiles to //i and matches every field of every gate, so it would green any run that fired one — a required field whose empty value asserts nothing is worse than an absent one"),
+    })
+        .optional()
+        .describe("a regex matched against everything a gate put in front of the user: the question label, every option LABEL, and every option DESCRIPTION. Use this when the skill's own wording may land in any of those fields — question_asked sees only the question text and question_options compares only labels, so a sentence delivered in an option's `description` is invisible to both. Evidence is the ask-time AskUserQuestion payload (never a producer's tool_result, which would grade true whether or not the model surfaced anything). Zero gates recorded FAILS; a lane that cannot read the gate payload fails evidence-unavailable, never vacuously. This text is model-composed and is reworded run to run — pin a producer-authored constant, not model prose"),
     questions_count_max: z
         .number()
         .int()
@@ -645,7 +675,7 @@ export const Assertion = z.strictObject({
             .describe("default false: also send each sub-agent's TEXT turns (RunResult.subagents[].reasoning, kind:'text' only) to the judge. Opt-in because it enlarges the judged document, which can re-grade an existing rubric. Use for a fan-out skill whose real work happens in sub-agents — their text is otherwise invisible to the judge. Sub-agent THINKING is excluded: it arrives empty with redacted:true, so including it would pad the document with blanks"),
     })
         .optional()
-        .describe("LIVE-ONLY: a pinned LLM judge grades the rubric against the run's answer; skipped-loud on replay (like egress_*). The judged document is finalMessage + transcript + authored files. NOTE the transcript is TOP-LEVEL assistant_text ONLY — no tool_use/tool_result, and no sub-agent text (even fork-scoped) unless include_subagent_text is set. A rubric claim about whether a TOOL was called can therefore never grade true; use tool_called/present_files_called/subagent_dispatched for that"),
+        .describe("LIVE-ONLY: a pinned LLM judge grades the rubric against the run's answer; skipped-loud on replay (like egress_*). The judged document is finalMessage + transcript + authored files. NOTE the transcript is TOP-LEVEL assistant_text ONLY — it excludes every tool_use/tool_result, and no sub-agent text (even fork-scoped) unless include_subagent_text is set. A rubric claim about whether a TOOL was called can therefore never grade true; use tool_called/present_files_called/subagent_dispatched for that"),
 });
 /** Verdict modifiers: assertions that verify nothing themselves — each opts into (suppresses) one
  *  default-fail in `computeVerdict`. They are pure no-op `ok()` passes in `assert.ts` and are kept on

package/docs/README.md

@@ -29,6 +29,9 @@ reading order and tables that follow.
 | **Test a skill that asks the user questions** | scripted `answers:` in [scenario.md](./scenario.md), or a live decider while you're still discovering what it asks ([decider-dir.md](./decider-dir.md)) |
 | **Prove my skill doesn't reach the network, or leak host paths** | `egress_denied` / `transcript_no_host_path` in [scenario.md](./scenario.md#full-schema); the enforcement model in [boundary.md](./boundary.md) |
 | Compare a skill across a fix (before/after, without averaging over both) | [debugging.md → iterate across fixes](./debugging.md#iterating-a-skill-across-fixes--the-verification-loop) + `stats --group-by skill-hash` ([stats.md](./stats.md)) |
+| **My sub-agent wrote a file and nothing was delivered** | [subagents.md → Canonical outputs addressing](./subagents.md#canonical-outputs-addressing--tier-qualified-there-is-no-single-cross-tier-literal-form) — the outputs path is **tier-qualified**, so a hand-off path that works on one loop silently lands in sandbox scratch on the other; `analyze-skill` catches it statically, before you pay for a run |
+| **Assert on how the run *behaved*, not what it produced** | [README → Assert on the run, not the output](../README.md#assert-on-the-run-not-the-output) — `subagent_tool_absent`, `dispatch_count_max`, `no_delete_in_outputs`: claims no output diff can reach |
+| **See exactly what a gate put in front of the user** (option labels *and* descriptions) | `trace <run> --view questions`; assert it with `question_context` ([scenario.md](./scenario.md#full-schema)). When no view renders the field you need, read `events.jsonl` directly — [debugging.md → investigate the run](./debugging.md#the-skill-misbehaved--investigate-the-run) has the `jq` recipes |
 | Debug a run that no-ops an assertion | [debugging.md](./debugging.md) |
 | Check whether the sandbox really enforces the boundary | [boundary.md](./boundary.md) |
 | Sync after a Claude Desktop update | [maintenance.md](./maintenance.md) |

package/docs/cassette.md

@@ -463,10 +463,10 @@ the rules and CI-placement rationale (why each category behaves this way), see
 
 | Assertion key | What it checks |
 |---|---|
-| `transcript_contains` | literal substring in assistant transcript |
-| `transcript_not_contains` | literal absent from transcript |
-| `transcript_matches` | case-insensitive regex matches transcript |
-| `transcript_not_matches` | regex does not match |
+| `transcript_contains` | literal substring in assistant transcript **Sees top-level `assistant_text` only — it excludes every `tool_use`/`tool_result`**, so text the agent emitted only inside a tool call (an `AskUserQuestion` gate question or option, a tool result) can never match at any phrasing; use the gate keys (`question_asked`, `question_context`, `question_options`) or `tool_result_contains` for those. |
+| `transcript_not_contains` | literal absent from transcript **Sees top-level `assistant_text` only — it excludes every `tool_use`/`tool_result`**, so text the agent emitted only inside a tool call (an `AskUserQuestion` gate question or option, a tool result) can never match at any phrasing; use the gate keys (`question_asked`, `question_context`, `question_options`) or `tool_result_contains` for those. |
+| `transcript_matches` | case-insensitive regex matches transcript **Sees top-level `assistant_text` only — it excludes every `tool_use`/`tool_result`**, so text the agent emitted only inside a tool call (an `AskUserQuestion` gate question or option, a tool result) can never match at any phrasing; use the gate keys (`question_asked`, `question_context`, `question_options`) or `tool_result_contains` for those. |
+| `transcript_not_matches` | regex does not match **Sees top-level `assistant_text` only — it excludes every `tool_use`/`tool_result`**, so text the agent emitted only inside a tool call (an `AskUserQuestion` gate question or option, a tool result) can never match at any phrasing; use the gate keys (`question_asked`, `question_context`, `question_options`) or `tool_result_contains` for those. |
 | `tool_called` | agent invoked the named tool |
 | `tool_not_called` | agent never invoked it |
 | `tool_result_contains` | literal substring in a tool result |
@@ -501,6 +501,7 @@ the rules and CI-placement rationale (why each category behaves this way), see
 | `task_count_min` | at least N tasks were created (`RunResult.tasks.length >= N`) — presence companion for task assertions; evidence-unavailable when `tasks` telemetry is absent |
 | `task_status` | a task whose `subject` OR `id` matches the `match` regex reached the given `status` — evidence-unavailable when `tasks` telemetry is absent |
 | `question_asked` | agent asked an AskUserQuestion matching the regex |
+| `question_context` | a regex matched the gate's founder-visible payload (question label + option labels + option descriptions) |
 | `question_options` | the option set + order that gate offered the user |
 | `questions_count_max` | at most N **sub-questions** asked — a bundled `AskUserQuestion` with K sub-questions counts as K, not 1; `trace --view questions`'s footer total uses the same definition |
 | `gate_answers_delivered: true` | answered gates' answers reached the model — **zero gates fired passes vacuously** (gate firing is model-dependent); pair with `gate_answer_count_min: >= 1` to also require a gate, or drop it and declare `questions_count_max: 0` in a gate-clean scenario |
@@ -522,7 +523,7 @@ the rules and CI-placement rationale (why each category behaves this way), see
 | `allow_delete_in` | verdict modifier — kept on replay → no-op pass (the live per-mount delete scan it waives is zeroed on replay, same as its outputs-scoped sibling) |
 | `allow_undelivered_deliverables` | verdict modifier — kept on replay → no-op pass (suppresses the `undelivered_deliverables` WARN; a replay runs no scratchpad walk of its own, so the signal is evidence-unavailable there regardless) |
 
-**`question_asked`, `question_options`, `questions_count_max`, `gate_answers_delivered`, `gate_answer_count_min`, `hook_blocked`,
+**`question_asked`, `question_options`, `question_context`, `questions_count_max`, `gate_answers_delivered`, `gate_answer_count_min`, `hook_blocked`,
 `no_hook_blocked`, `vm_path_denied`, `path_denied`, `no_path_denied` require `controlOut`** (full-fidelity
 replay). On an old cassette without `controlOut` these keys are excluded from evaluation — not vacuously
 passed — and a loud warning fires (see §Backward compatibility). The hook and path-denial keys need
@@ -645,7 +646,7 @@ When the cassette carries `controlOut`, replay consumes **both** recorded direct
 On replay, the replay decider (built by `buildReplayDecider()`) indexes `controlOut` by `request_id` and serves the recorded response to
 the decision pipeline instead of consulting a live decider or asking the user. This makes the full
 `Run.handleDecision` path execute on replay, which populates `rec.questions`, `rec.gateAnswers`, and
-`rec.gateDeliveries` — exactly as in a live run. Consequence: `question_asked`, `question_options`, `questions_count_max`,
+`rec.gateDeliveries` — exactly as in a live run. Consequence: `question_asked`, `question_options`, `question_context`, `questions_count_max`,
 `gate_answers_delivered`, and `gate_answer_count_min` are now genuinely evaluated, not silently skipped
 or vacuously passed.
 
@@ -729,7 +730,7 @@ regressing to the prior false-green behavior:
    ::warning:: [replay] cassette has no controlOut (pre-full-fidelity) — question/gate assertions
    are NOT checked; re-record to enable them
    ```
-2. **`question_asked`, `question_options`, `questions_count_max`, `gate_answers_delivered`, `gate_answer_count_min` are
+2. **`question_asked`, `question_options`, `question_context`, `questions_count_max`, `gate_answers_delivered`, `gate_answer_count_min` are
    excluded** from the evaluated assertion set for that run — not vacuously passed, absent.
 3. All other content assertions (transcript, tool, subagent, result) evaluate normally.
 
@@ -895,6 +896,8 @@ real filesystem selection work `--dry-run` doesn't do, so the combination is rej
 (`cowork-harness record scenarios/ --dry-run`): a superset of what actually gets re-recorded (every
 committed cassette's source scenario, not just the ones whose fingerprint drifted), so it's conservative in
 the right direction.
+>
+> **The path-dependent advisory notes in that preview do NOT describe `--rerecord-stale`.** The preview computes each scenario's DEFAULT cassette path, while `--rerecord-stale` writes to the committed cassette it found — a different path, so a different host-inventory/portability verdict. (A `--rerecord-stale` target always exists, so `hostInventoryPreflight` warns there rather than refusing.) The scenario LIST is still a conservative superset; only the notes are not transferable.
 
 Each cassette is written **atomically** — to a same-directory temp file, then `rename`d over the target
 (atomic on POSIX). An interrupted, failed, or OOM-killed batch therefore never leaves a partial or corrupt
@@ -1029,10 +1032,16 @@ counts). Uploads and `mode:r` connected folders are hash-only, and a file over t
   **`record` carries its own preflight for the same risk.** Recording at a host-inheriting tier
   (`protocol`, `hostloop`, or `cowork` resolving to hostloop) into a repo-visible cassette path is
   refused by default — that recording would freeze this machine's MCP servers, agents, and account
-  metadata into a committed fixture. `--allow-host-inventory-fixture` is the boolean consent to record
-  anyway; it is distinct from `verify-cassettes`' `--allow-host-inventory <regex>` above (a per-finding
-  suppressor, not a record-time consent) and is appropriate only when the session has no personal MCP
-  servers or plugins.
+  metadata into a committed fixture. `--allow-host-inventory-fixture` bypasses **that pre-flight only**.
+  It does NOT consent to a leak: the finished recording is still scanned (below), and a real finding still
+  refuses the write and quarantines the recording. So you do not have to audit the session by hand to pass
+  it — the scan is the actual gate. Writing a recording the scan DID flag needs the separate, louder
+  `--allow-host-inventory-findings`. Both are distinct from `verify-cassettes`' `--allow-host-inventory
+  <regex>` above (a per-finding suppressor on an already-committed cassette, not a record-time flag).
+
+  **Until 2.2.0 one flag did both jobs**, so an operator who passed it to get past a precondition they
+  could not check also switched off the measured scan that would have caught a real leak — the escape
+  hatch defeated the guard that was working.
   **The preflight is a PREDICTION; `record` now also checks the EVIDENCE.** The preflight reads the tier
   and the destination path before the paid spawn, which is the right place for it — but it never looks at
   the resulting bytes, so it can be wrong in both directions. After redaction and before the write, the
@@ -1047,6 +1056,22 @@ counts). Uploads and `mode:r` connected folders are hash-only, and a file over t
   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.
 
+  **The pre-flight IS previewable, and is previewed.** `record --dry-run` on a SINGLE scenario file runs
+  the same refusal the real record does, from the same `--out` path and the same flags, and refuses
+  identically — it is a pure function of tier and destination path, so it costs nothing to answer.
+  On a **directory** the same verdicts are reported as `⚠ would-refuse (advisory)` notes and do **not**
+  affect the exit code: a directory target takes no `--out`, so the preview must guess the destination, and
+  a guess must not gate a batch. Dry-run the single file with the real flags to get a binding answer.
+
+  **What is deliberately NOT previewed is what the scan would FIND.** It is the obvious ask —
+  "tell me the inventory before I pay" — and it cannot be answered honestly before the run. The pre-flight
+  is a *prediction* from the tier and the destination path; the inventory itself does not exist until the
+  agent has run and the `system/init` frame has been received. A preview would either re-implement the
+  scanner against a hypothetical (a second oracle, free to disagree with the real one — the failure mode
+  this whole layer exists to avoid) or require the spend it was meant to avoid. The scan on the finished
+  bytes is the answer, and it is why you do not have to audit the session by hand to pass
+  `--allow-host-inventory-fixture`.
+
   **The right way out is usually `fidelity: container`**, which is sealed (`HOME=/tmp`) and has nothing
   to leak. Redirecting the *output* elsewhere is not equivalent: a cassette recorded outside the repo
   and moved in afterwards is [unverifiable for staleness from its own location](#where-a-cassette-lives-and-why-it-cant-move-afterwards) — recoverable only by passing `--session <file>` on every invocation —

package/docs/debugging.md

@@ -71,6 +71,31 @@ already happened.
 2. **`trace` — what did it actually do?** Digests the run's `events.jsonl` into the tools it called, the
    questions (gates) it was asked and how they were answered, and the sub-agent dispatch tree. This is how
    you answer "how many sub-agents *really* dispatched?" or "which gate fired, with what offered labels?"
+   — `--view questions` prints each gate's full ask-time payload, every option's **label and
+   `description`**, which is where a skill routinely puts the sentence the user is actually deciding on.
+
+   **When `trace` doesn't render the field you need, read `events.jsonl` directly.** The views are a
+   digest, not the record: the run dir's *evidence* surface is wider than any view's *observation*
+   surface, and wider still than the assertion catalog. Nothing in the pipeline discards an event, so a
+   field no command prints is still on disk — and concluding "it never happened" from a view that
+   doesn't render it is a false negative, not a finding. The file is one JSON object per line:
+
+   ```bash
+   RUN=~/.cowork-harness/runs/<scenario>/<session>          # `--keep` printed this path
+   # every AskUserQuestion payload, exactly as the model emitted it — options, descriptions and all
+   jq -c 'select(.type=="control_request" and .request.tool_name=="AskUserQuestion") | .request.input' "$RUN/events.jsonl"
+   # what the harness answered, keyed by request_id (the other half of the gate). Note the DOUBLE
+   # `.response.response` — the outer is the control envelope, the inner is the tool decision.
+   jq -c 'select(.response.response.updatedInput.answers)
+          | {request_id: .response.request_id, answers: .response.response.updatedInput.answers}' "$RUN/control-out.jsonl"
+   # the raw line behind a `trace` row you want to see unabridged
+   sed -n '204p' "$RUN/events.jsonl" | jq .
+   ```
+
+   If what you find there is worth *gating* on rather than just reading, promote it to an assertion:
+   [`question_context`](./scenario.md#full-schema) matches a regex against everything a gate put in front
+   of the user (question label, option labels, option descriptions), and `tool_result_contains` /
+   `artifact_json` cover most of the rest. An assertion is the version of the finding that survives you.
 3. **`verify-run` — re-assert cheaply.** If the run itself was fine and only an *assertion* is wrong,
    re-check the scenario's assertions against the kept run dir with no live re-record (~1s). When the
    scenario scripts answers, it also re-checks they still match the run's actual gates — so a reworded gate

package/docs/fidelity-gaps.md

@@ -898,7 +898,11 @@ The remote lane also has an internal MCP server the harness does not model at al
 `internal__remote-devices__<tool>` (note the `internal__` prefix, not `mcp__`). Agent-facing tools include
 `device_bash`, `device_list_dir`, `device_stage_files`, `device_commit_files`,
 `device_request_folder_access`, `get_device_info`, and device-artifact tools; `device_commit_files` is the
-remote lane's write-to-disk leg and consumes a `file_uuid` from a prior `SendUserFile`. Desktop advertises
+remote lane's write-to-disk leg and consumes a `file_uuid` from a prior `SendUserFile`. Desktop 1.37937.0
+added `device_fs` and `device_request_delete_permission` to that set, plus a folder-access announce mode
+(`card` / `dialog` / `off`) — the Desktop half of the six `cowork_*` risk categories that had appeared in
+agent 2.1.237's auto-mode permission rubric. **This list is illustrative, not an inventory** (see the
+feature-gating note below), so it is not kept exhaustive; it is updated when a release moves the shape. Desktop advertises
 these *outward* to a cloud session over a device-OAuth bridge; every handler logs
 `session_type: "cowork-remote"`, and no `internal__*` name appears in the local spawn's tool list.
 

package/docs/maintenance.md

@@ -77,6 +77,20 @@ git commit -m "parity: sync to Desktop <new>"
 cowork-harness run examples/scenarios/   # regression — drift shows as test diffs (this repo's scenarios live under examples/)
 ```
 
+> **The live-asar tripwires are macOS-local ONLY — CI cannot run them, so a green CI is not evidence the
+> baseline still matches the installed Desktop.** Every oracle that reads the real bundle gates on
+> `process.platform !== "darwin"` (`test/baseline.test.ts`), and `ci.yml` has **no macOS runner** — all
+> its jobs are `ubuntu-latest` / `ubuntu-24.04-arm`. So the golden spawn-env oracle, the
+> `checkSpawnContractFacts` real-asar regression and every mutation case built on the live bundle
+> **skip in CI, silently**. Measured on this release: Desktop 1.37937.0 added a construction site the
+> resolver could not parse, and both `ci.yml` and `release.yml` would have gone green with that drift
+> unfixed — only running `sync` on a Mac surfaced it.
+>
+> Practical consequence: **the per-release runbook above is the only thing that catches parity drift.**
+> Do not defer it on the strength of a green pipeline. A committed-asar fixture tier (so the oracles have
+> something to run against off-macOS), or at minimum a loud skip in the CI job summary rather than a
+> `console.warn` nobody reads, is open work.
+
 If the agent version bumped, there is no image rebuild: the agent ELF is bind-mounted at runtime from the staged Desktop install (`resolveAgentBinary`, `src/baseline.ts`), not baked into the container image. A bumped `agentVersion` only updates `agentBinary.stagedPath` in the baseline (`src/cli.ts`); the container picks up the new binary from that path.
 
 ### Agent-binary provenance (`sha256`)
@@ -97,7 +111,7 @@ Another runtime knob in the same family: `COWORK_HARNESS_RESOURCE_INTERVAL_MS` s
 Old staged binaries are re-downloadable from Anthropic's own release channel. For the **container/microvm** tiers the harness needs the **Linux/arm64 ELF**, so download it directly and point the resolver at it:
 
 ```bash
-V=2.1.237   # your baseline's agentVersion (read it from baselines/desktop-<latest>.json)
+V=2.1.246   # your baseline's agentVersion (read it from baselines/desktop-<latest>.json)
 curl -fSL "https://downloads.claude.ai/claude-code-releases/$V/linux-arm64/claude" -o "claude-$V"
 # verify against the committed baseline sha256 (== manifest platforms["linux-arm64"].checksum):
 shasum -a 256 "claude-$V"