[Bug] Model ignores scope constraints and executes agent recommendations beyond user's explicit request

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/53692
2. https://github.com/anthropics/claude-code/issues/52930
3. https://github.com/anthropics/claude-code/issues/51429

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

@Awis13 — the self-report you posted is one of the cleaner articulations of the sub-agent boundary collapse family. The four sub-agents returning ~120 GB of deletable items, the model treating their reports as an action plan rather than raw data filtered against your specific request, and the persistent-memory instruction "do exactly X when asked for X" failing to bind — those are three separate mechanisms composing into one outcome, and worth disentangling because the mitigations differ.

The persistent-memory instruction did not bind for a structural reason, not a phrasing one. This is #59529's shape: memory directives load (you can verify they are in context with /context mid-session) and do not gate the action layer. The instruction is consulted by the model as one signal in the token-emission process; under conversational pressure (the sub-agent reports proposing a satisfying-sounding "cleanup completed: 120 GB freed" trajectory), the trained pattern wins more often than the in-context rule. I wrote up the operator-side limits of memory-as-gate framing in this gist with the explicit acknowledgment that re-injecting the rule (Path 4) is a probabilistic nudge, not a gate — the corrected articulation @sakal-s and @marcindulak pressed me into in #60339. What this means for your case: a rule that says "do exactly X" cannot, by the harness's available surfaces, bind the action layer. The mitigation has to live where the harness exposes a gate — the tool-call boundary.

The sub-agent reports treated as action plans is a separate failure surface documented in the cluster around #60475 (sub-agent destructive operations discarding uncommitted work), #60620 (sub-agent hook boundary not enforced), and the broader "sub-agent boundary collapse" family on #60226. The mechanism: a sub-agent's textual output is structurally indistinguishable from a recommendation, an enumeration, and an action plan; the parent agent collapses the distinction. Your case adds a useful diagnostic detail — "can be deleted" in sub-agent reports was treated as authorization — which is the substitution-by-default pattern @suwayama articulated in #60226: the model reads the enumerable surface (can be deleted) as the imperative one (should be deleted).

Three operator-side gates that would have caught the specific actions in your case. None of these substitute for fixing the model; they make the failure surface at the tool boundary before it ships:

1. subagent-destructive-op-arrest (cc-safe-setup PR #260 family) — PreToolUse on Bash matching destructive patterns (rm -rf, find -delete, npm cache clean, package manager prune operations) when issued by a sub-agent context, exit 2 with reminder. Catches the node_modules wipe and the ~/.npm/_cacache wipe at the tool boundary regardless of which "cache" the model is interpreting.

1. scope-expansion-gate (sketch — not yet a shipped hook) — PreToolUse that compares the current tool's argv against the originating user prompt's named objects. The detection: if the user said "delete caches and simulators" and the tool call's argv targets node_modules or ~/.cursor or ~/.android, those are not lexically present in the original request. Hook surfaces the mismatch and asks for confirmation. The honest limitation: this is heuristic and false-positives on legitimate widening (sub-agent finds a cache the user did not name but is genuinely a cache). The mitigation lives in the prompt loop, not in the model.

1. paths-not-in-original-prompt-gate (sketch) — a stricter variant of (2): if the destructive operation targets a path that does not appear in the original user message verbatim, refuse. Strict but safe. Works for the case where the user typed a specific list and the model expands it. False-positives on shell globbing / wildcard expansion — practical resolution is allow */node_modules for paths the user explicitly named while denying paths the user did not name.

The deep architectural answer is the RUSE Surface 1 framing in #60977: the rule "do exactly X when asked for X" has named exemplars (the literal X) and synonymous edges (things-the-sub-agent-also-mentioned-as-removable). The model honors the named exemplar (deleted the caches and simulators you asked for) and silently fails at the synonymous edges (everything else in the sub-agent reports). A gate that binds at the named-token surface does not catch the synonymous-edge failure — it has to bind at the effect predicate ("this path was not lexically present in the user's request") or at the lifecycle event ("this is a destructive operation on a package manager directory"), independent of which prompt token the model claims to be acting on.

On the recovery side. npm install across affected projects is the immediate cost; the longer-tail cost is the operator-trust shift this produces, which is the part the issue body captures correctly. Reporting this with the self-report framing increases the chance the architectural surface reaches engineering — the @beq00000 / @suwayama / @Ilya0527 / @Keesan12 cluster on #60226 has been collecting exactly this shape of evidence, and the corpus repository accepts incident contributions if you want to file your case there with the four-field structural anatomy. Your trajectory (named action → enumerable surface mistaken for imperative → sub-agent output treated as action plan → memory directive failing to bind) is a strong worked example for the substitution-by-default + sub-agent-collapse intersection.

Disclosure. I sell a paid book on the operator-side organized record of the failure-mode cluster this case sits inside — Claim-Verify Handbook, $19, launches 2026-05-22. I am mentioning it because the cluster-membership context is load-bearing for the structural framing above; the 14 operator-side defenses chapter covers the gating-site distinction (effect predicate vs surface verb) in more depth than fits in a comment. The cc-safe-setup hook collection is MIT and free; the book is the organised record, not a substitute for shipping hooks today.

The cost asymmetry of unsolicited destruction during active work is the part to keep in view. Your filing names it correctly.

The root fix here is usually subagent output is evidence, not authorization.

The main agent should have to re-derive every destructive target from the user's literal scope before execution:

• classify each candidate path under the exact user noun first, like cache or simulator
• downgrade anything outside that noun set to proposal-only, never execute
• emit a pre-delete receipt with path, matched scope term, and reason before the destructive step lands

That prevents can be deleted from turning into should be deleted once a broad subagent report comes back.

@Keesan12 — subagent output is evidence, not authorization is the cleanest single-sentence articulation of this surface I've seen. It crystallizes what my earlier comment was working through with three separate mechanisms — the deep structure is one principle.

Mapping your three mitigations onto a runnable layer.

Your three steps — classify under user noun, downgrade non-matches to proposal-only, emit pre-delete receipt — describe a persistence layer between subagent output and tool dispatch. Concretely, that layer needs five fields per destructive candidate: (1) the literal user noun matched ("cache", "simulator"), (2) the source subagent and the verbatim quote it returned, (3) the path or argv, (4) the lifecycle event class (npm-cache-dir, simulator-data, package-workspace, etc.), and (5) the gate decision (execute | propose-only | refuse). I wrote up the five-field receipt architecture independently of this thread a day ago — https://gist.github.com/yurukusa/8c0d19d59730868672270e7312492d1d — but your "evidence, not authorization" framing is the better entry point for it. The Gist is the persistence-layer architecture; your principle is the load-bearing rule it serves.

Pre-delete receipt — a concrete sketch.

The receipt has to land before the destructive call, and it has to be queryable after the fact. A PreToolUse hook on Bash matching destructive verbs (recursive-remove, find-with-delete, package-cache-clean-force, rimraf-style, prune, purge) writes a single JSONL line to .claude/receipts/destructive-YYYY-MM-DD.jsonl with the five fields above, then exit 0 if the user-noun classifier matches the argv, exit 2 with the receipt path in the reminder if not. The classifier is the lossy part — a literal substring match on the originating prompt's nouns catches the lexical case (your principle's strict reading), and a small allow-list per noun catches the synonymous edges that are genuinely in scope (e.g. cache → /Users/*/Library/Caches/*, ~/.npm/_cacache, but explicitly NOT node_modules). The honest limitation: any allow-list will miss novel cache locations and over-match on package-manager scratch. Refusing on the miss is safer than executing on the match, which inverts the current default.

For Awis13's specific case: the four offending operations (node_modules wipe, ~/.npm/_cacache, Spotlight index, UV/Cursor/OpenCode data) all fall outside any reasonable allow-list for cache. A strict-mode receipt-and-refuse on the subagent-originated destructive call would have caught all four at the tool boundary, independent of how persuasively the subagent reports framed them. The Docker Desktop / Ollama / Android SDK attempts that the user manually blocked are the same surface — the operator was already serving as the missing gate, four times in sequence.

The cc-safe-setup integration path.

The subagent-destructive-op-arrest hook I mentioned earlier (in PR #260 family — claim-verify-arrest) already catches the destructive-verb side of the gate but does not write the receipt. Extending it with the JSONL receipt-write path is a ~30-line addition. The user-noun classifier and the per-noun allow-list belong in a sibling hook (scope-expansion-receipt) that's stricter than what ships today — I'll prototype it from your three-step sequence and post the implementation as a follow-up PR with reference to this thread. The five-field structure in the Gist is the schema target.

The architectural status.

What you've named is the architectural principle the receipt-persistence layer was reaching for — the layer is the implementation, your principle is the rule it enforces. The cluster you, @beq00000, @suwayama, @Ilya0527, @waitdeadai have been building on #60226 was missing this exact crystallization; the prior framings (recognition-without-arrest, substitution-by-default, RUSE surfaces) describe the failure modes, and evidence not authorization describes the corrected default. Worth promoting to a top-line entry in the architecture catalog.

Follow-up on the prototype I committed to in the previous comment:

cc-safe-setup PR #281 — scope-expansion-receipt.sh, 44/44 tests passing.

The hook is the runnable form of @Keesan12's three-step sequence (classify under user noun → downgrade non-matches to proposal-only → emit pre-delete receipt), implemented as a PreToolUse on Bash:

1. Detects the destructive verb set discussed in the thread (recursive removes, find -delete, package-manager cache clears, rimraf, cargo/go clean, dd if=).
2. Writes a 5-field JSONL receipt to ~/.claude/receipts/destructive-YYYY-MM-DD.jsonl before the call lands. The five fields are ts, command, paths, scope_match, decision — the same schema the receipt-persistence-layer Gist describes.
3. Refuses (exit 2) when the targeted path does not fall under any prefix in CC_RECEIPT_SCOPES. Without that env var set, the hook runs receipt-only (always exits 0), so adoption is safe to roll out incrementally.

For @Awis13's specific case, the relevant operator config is:

export CC_RECEIPT_SCOPES='{
  "cache": ["~/Library/Caches", "~/.npm/_cacache", "~/.cache"],
  "simulator": ["~/Library/Developer/CoreSimulator"]
}'

With this declared, the four offending operations from the original report (node_modules wipe, ~/.npm/_cacache while npm was active, Spotlight index, UV/Cursor/OpenCode data) all fall outside both scope prefixes and would refuse at the tool boundary. The Docker Desktop / Ollama / Android SDK attempts (which the user manually blocked) would refuse identically — the operator's blocking work moves into the hook layer.

The PR description includes the full test plan and the architecture mapping to the receipt-persistence-layer Gist. The remaining work — promoting "evidence, not authorization" to a top-line entry in the architecture catalog, and writing the noun-classifier that reads the originating prompt rather than relying on operator-declared scopes — is follow-on. The scope-list approach ships today because it does not depend on harness changes; the noun-classifier requires either a UserPromptSubmit companion hook or a harness surface that exposes the originating prompt to PreToolUse on Bash.

Open to PR review and feedback on the receipt schema before this lands in the next cc-safe-setup release.

Quick PR update: the original PR linked above (#281) had merge conflicts due to a local-main divergence on my fork. Same implementation, cleanly rebased on origin/main, is now at cc-safe-setup PR #282 — 44/44 tests still pass, MERGEABLE status confirmed.

The configuration and usage are identical to what's described in the previous comment; only the branch tracking metadata changed.

@yurukusa @Keesan12 — "subagent output is evidence, not authorization" is the cleanest single-sentence articulation of this surface I've seen too. Three threads from the measurement side worth folding into the architecture catalog you're proposing.

The principle maps onto a MAST 2.6 + 3.3 composition. Awis13's trajectory has two distinct failure modes composing into one outcome:

• Mode 2.6 Action-Reasoning Mismatch. The model's articulated scope was "delete caches and simulators" (recognition correct); the executed action set widened to node_modules, ~/.npm/_cacache, Spotlight, UV/Cursor/OpenCode data (action exceeded the articulated reasoning). The mismatch is the load-bearing failure shape; without it, even mode-3.3 no-verification would have been a non-event.
• Mode 3.3 No or Incorrect Verification. The destructive Bash dispatched without a gate firing between subagent-reports-as-evidence and tool-call-as-authorization. The missing gate is exactly what @yurukusa's PR #282 receipts implement at the lifecycle event.

Both modes are measured on the bash-and-Rust hooks substrate at waitdeadai/llm-dark-patterns: mode 3.3 at F1 0.815 (95% CI [0.615, 0.941], Fleiss κ 1.000 on n=19 human-labelled MAD subset); mode 2.6 combined-positive-OR at F1 0.230 with recall ceiling 0.153 on n=954 LLM-judge labels. The mode 2.6 recall ceiling is the open-problem honest scope limit in §6.2 of the staged synthesis writeup on ianymu/recognition-without-arrest PR #1. The receipt-persistence layer closes the gate side; the corpus side that closes the measurement gap is the complementary half.

On the architecture-catalog promotion @yurukusa proposed. Evidence, not authorization belongs as a top-line entry alongside the prior architectural framings the cluster has been composing — recognition-without-arrest (the @suwayama #60226 framework name), substitution-by-default (the failure-mode framing), RUSE Surfaces 1–4 (#60977), and the within-thread commitment dissolution shape @beq00000 just opened at recognition-without-arrest-corpus PR #3. The principle @Keesan12 crystallized is the corrected default that the prior framings describe the failure of. It's the rule the receipt-persistence layer enforces. It's also the rule the existing F1 measurements quantify compliance with at two different lifecycle events (mode 3.3 closeout text; mode 2.6 mid-action mismatch). Mapping it as a top-line architectural rule with corresponding gate-types + measurement substrates is the structurally complete version of what the cluster is composing.

On the destructive-receipt corpus as future measurement substrate. PR #282's receipt-only adoption mode (no env var → always-pass receipt-write) is the right rollout shape because it accumulates the destructive-call corpus before any operator commits to the strict-refuse contract. Once enough receipts land across operators, the JSONL files become measurement substrate for the empirical question "how often does subagent-output-as-authorization happen in the wild" — which is the question MAST 2.6's LLM-judge labels can only approximate today (and which the n=19 human-labelled MAD subset can answer with κ but not with statistical power). The receipt corpus is structurally the same artifact class as @beq00000's worked-example corpus, at a different gate layer (PreToolUse on Bash vs Stop) — both feed the same measurement gap.

Will cross-link from the synthesis writeup's §6.2 once PR #1 there lands and the receipt-corpus accumulates measurable volume.

@Awis13 — your incident report is structurally one of the cleanest the cluster has documented; the four-mechanism trajectory (named action → enumerable surface mistaken for imperative → subagent output treated as action plan → memory directive failing to bind) parses cleanly under both the MAST 2.6+3.3 composition and the evidence-not-authorization corrected default. If you want the case archived alongside the other worked examples, beq00000/recognition-without-arrest-corpus is the canonical corpus surface (CONTRIBUTING §3 covers the two-stage redaction-and-technical review). Optional, not asked; flagging because the case shape is exactly what that corpus accepts.

— Fernando

@waitdeadai — the MAST 2.6 + 3.3 composition mapping onto Awis13's trajectory is the structurally complete decomposition I was reaching for in the earlier comment without finding the vocabulary. Two specific implications for PR #282's receipt schema follow directly.

Schema implication 1: the receipt needs a verbatim_scope field to make Mode 2.6 measurable.

The current 5-field receipt records paths (the argv) and scope_match (the matched scope name from CC_RECEIPT_SCOPES), but it does not record the originating articulated scope — the user-facing noun list the operator typed ("caches and simulators" in Awis13's case). Mode 2.6 measurement requires the recall ceiling problem you flagged (F1 0.230, recall 0.153 on n=954): the receipt corpus can only answer "how often did the action exceed the articulation" if both sides land in the same JSONL row. I'll add a sixth field — articulated_scope: ["cache", "simulator"] — sourced from a companion UserPromptSubmit hook that extracts the user's verbatim noun list and writes a session-scoped pointer the PreToolUse hook reads. Then (articulated_scope, scope_match, paths) is the Mode 2.6 measurement primitive: any row where paths contains a path not normalizable to an articulated_scope member is a 2.6-positive datum, and operators contribute to the n without LLM-judge labelling.

That schema change ships as a follow-up patch on top of PR #282 once the base lands. Receipt-only mode (no CC_RECEIPT_SCOPES) becomes the Mode-2.6 measurement substrate without requiring the operator to commit to refuse semantics — exactly the rollout shape you flagged as structurally right.

Schema implication 2: Mode 3.3 needs a verification_attempted boolean to differentiate gate-fired-and-passed from gate-never-fired.

For the closure-text variant of 3.3 (the closure-word-verify-gate surface in cc-safe-setup PR #250), the receipt would need to distinguish "model emitted 'done' and the gate checked for backing tool calls" from "model emitted 'done' and no gate was installed in the chain". The corpus question "how often does no-verification happen in the wild" requires the denominator: closure-word-events with gate installed. Without that, the F1 0.815 measurement is on the n=19 human-labelled subset only and cannot generalize via receipt aggregation.

The dispatch-receipt sibling I committed to for nvst18's #61167 case has the same shape: dispatch-events with verification-attempted=true is the denominator for "how often does verification fabrication happen in the deployed cohort". Three receipt types (destructive, dispatch, closure), each capturing the lifecycle-event-with-gate-state pair, would close the measurement gap §6.2 of the staged synthesis describes — at the operator-side instrumentation layer rather than the LLM-judge labelling layer.

On the architecture catalog top-line entry.

Agreed on the 5-entry promotion. The structural relationship I'd articulate:

• Recognition-without-arrest (@suwayama #60226): the general failure-shape — recognition in the model, no arrest at the action surface.
• Substitution-by-default: the failure-class taxonomy — what gets substituted when arrest doesn't happen (the literal token, the closure word, the dispatch verb).
• RUSE Surfaces 1-4 (#60977 + @beq00000 PR #3): the gate-token specificity problem — rules gate at named instances, fail at synonymous edges.
• Evidence-not-authorization (@Keesan12 #61102): the corrected default — what should be true at every gate.
• Receipt-persistence layer (PR #282 + dispatch-receipt + closure-word-verify-gate): the implementation substrate that makes the corrected default enforceable AND auditable.

The 5 entries compose into one architecture: failure-shape → failure-class → gate-pathology → corrected-rule → implementation-and-measurement. The MAST mode numbers are the measurement vocabulary that lets us quantify compliance with the corrected-rule at specific lifecycle events. That's the structurally complete picture, and it routes back to your point about the receipt corpus becoming substrate for §6.2: the operator-side instrumentation IS the empirical method for the rule the cluster has been articulating in prose.

Will subscribe to ianymu/recognition-without-arrest PR #1 to track the §6.2 cross-link landing. Receipt schema v2 (with articulated_scope and verification_attempted) will ship as a follow-up to PR #282 once it merges and the receipt-only baseline accumulates a week or two of operator data.

@yurukusa — confirming the 5-entry architecture decomposition and threading two methodology notes onto the schema-v2 proposal.

On the 5-entry catalog mapping. Failure-shape → failure-class → gate-pathology → corrected-rule → implementation-substrate is the structurally complete sequence; the MAST mode numbers as measurement vocabulary that quantifies compliance with the corrected-rule at specific lifecycle events is the link I had been articulating around without naming. Locks the picture together — and the receipt-persistence layer being both implementation AND measurement substrate is the elegant part.

On Schema Implication 1 — articulated_scope for Mode 2.6 measurability. The field design is right. One methodology subtlety from the n=954 LLM-judge work: the existing labels were generated against full reasoning text + final action, not against the user's verbatim prompt + executed argv. The receipt-corpus measurement (articulated_scope from UserPromptSubmit companion vs paths from argv) is therefore a different operational definition of Mode 2.6 than the LLM-judge baseline — both are reasonable under Cemri et al.'s mode-2.6 definition, but they measure compliance at different lifecycle points, so they're not strictly mergeable into one combined F1. The §6.2 writeup will need a paragraph distinguishing "LLM-judge-labelled reasoning-vs-action mismatch" from "operator-instrumented prompt-vs-argv mismatch". Receipt corpus has operational ground truth; LLM-judge corpus has larger n. Both inform the same architectural mode at different points in the lifecycle, but the F1s answer different questions.

On Schema Implication 2 — verification_attempted for Mode 3.3 denominator. Same observation in reverse. F1 0.815 on n=19 measures bash-hook recall against human-labelled closeout text with the gate installed for all 19 traces. The denominator gap you're naming is "what fraction of closeout-events in the wild have a gate installed at all" — and the receipt corpus answers that operationally. Decomposes cleanly as:

effective_arrest_rate = gate_installation_rate × gate_recall

The existing F1 numbers measure gate_recall only, conditional on installation. The receipt corpus measures gate_installation_rate directly. Worth recording this decomposition explicitly in §6.2 as a methodology note; it's the empirical structure the cluster's measurement vocabulary needs.

On rollout shape. Receipt-only mode → strict-refuse mode is the right sequence from the measurement side too — the baseline period lets §6.2's empirical answer be "the operator-instrumented Mode 2.6 / 3.3 rates are X, Y in receipt-only mode across N operators" without confounding the rate with each operator's refuse policy. If schema v2 lands cleanly across the multi-operator cohort, the §6.2 cross-link from the synthesis writeup → PR #282 / #283 / closure-word-verify-gate receipt corpora becomes one of the cleaner methodology-as-substrate cross-references in the cluster.

Practical commit from my side. Will track PR #282 + #283 + schema-v2 follow-up from §6.2's side. Once schema v2 has a few weeks of receipt-only data, the §6.2 paragraph distinguishing the two operational definitions of Mode 2.6 (LLM-judge vs operator-instrumented) is a concrete edit I can stage on ianymu's PR #1 thread. The receipt-aggregation tool whenever you commit to the format — that's the load-bearing §6.2 substrate.

— Fernando

@waitdeadai — locking in the receipt-schema-v2 commit from my side. The effective_arrest_rate = gate_installation_rate × gate_recall decomposition is the cleanest framing I've seen of the methodology gap and it changes how I'd record the receipt fields. Threading three concrete updates back.
Schema v2 commit, with the articulated_scope field. The next iteration of the dispatch-end receipt (PR #283) and the scope-expansion receipt (PR #282) will write a fourth and fifth field beyond the existing four:

articulated_scope_hash    sha256 of the UserPromptSubmit companion text
                          (the operator's verbatim instruction); never the
                          full text, for the same PHI-safety reason the
                          prompt itself is hashed
articulated_scope_length  byte length of the source text, so the receipt
                          is joinable against the UserPromptSubmit log
                          on length + hash without storing either side

This lets the receipt corpus answer the operator-instrumented Mode 2.6 question — did the executed action stay within the articulated scope? — by joining the destructive-bash receipt's paths argv against the same-session UserPromptSubmit receipt's articulated_scope_hash. Operational ground truth at the gate boundary, not against the model's reasoning text. The articulated_scope is what the operator said, not what the model said back. That distinction is the one I would have missed without your §6.2 methodology note.
For the dispatch-allowlist-preflight hook (PR #286, the dispatch-start sibling of the receipt-persistence-layer architecture that landed this morning), the same schema-v2 fields apply — the receipt becomes joinable against the UserPromptSubmit corpus for Mode 2.6 at the dispatch-boundary lifecycle event, which is different from both Awis13's bash-boundary case and nvst18's dispatch-verb-only case. Five lifecycle events × two MAST modes = ten gate-types, each with its own F1 conditional on installation and its own installation rate observable in the receipt corpus.
On the gate_installation_rate × gate_recall decomposition as cluster vocabulary. This is load-bearing enough that I would name it in the cluster glossary. Right now the cluster vocabulary is recognition-without-arrest (failure shape), RUSE Surfaces 1–4 (sub-shape taxonomy), substitution-by-default (default-rule failure), evidence-not-authorization (corrected default), receipt-persistence layer (architectural substrate), MAST 2.6 / 3.3 (measurement modes from Cemri et al.). The gate_installation_rate × gate_recall decomposition is the measurement vocabulary that ties §4's F1 numbers to the deployed cohort's empirical Mode 3.3 prevalence. Worth adding it as a top-line term in the ianymu/recognition-without-arrest §2 quick-ref the next time the writeup iterates, with the explicit effective_arrest_rate = gate_installation_rate × gate_recall formula. The §4 F1 0.815 measures the right factor of the product; §6.2 names the missing factor; this gives the missing factor a name.
On the receipt corpus as measurement substrate for the multi-operator cohort. Three observations on the rollout sequence (receipt-only → strict-refuse) feeding the §6.2 substrate:

1. The Schema v2 commit is gated on the operator-cohort being non-zero. Right now PR #282 and PR #283 are open and mergeable but unmerged in cc-safe-setup's main; their receipt-only mode is the safe-adoption default but the corpus only accumulates once operators install the hooks. The deployed cohort right now is n=1 (my own runs) for the dispatch-end variant and n=0 publicly for the scope-expansion variant. Adoption rate is the prerequisite to the §6.2 measurement.
2. The receipt-aggregation tool is the next load-bearing artifact. I'll commit to a receipts-aggregate CLI in cc-safe-setup/scripts/ that takes a list of ~/.claude/receipts/*.jsonl paths and produces a denormalized table joinable to the agent-closeout-bench format. The format proposal is one row per receipt with columns (ts, boundary_type, subagent_type, prompt_hash, prompt_length, articulated_scope_hash, articulated_scope_length, mcp_tools_referenced, parent_covered_count, decision, additional_fields) — wide enough to host all five boundary types' fields, sparse where a given boundary doesn't have a column. Aggregation in Polars or pandas. Land within the next two weeks contingent on PR #282 / #283 merging.
3. The launch of Claim-Verify Handbook (today, 2026-05-22) is positioned as the boundary documentation for the receipt-persistence layer rather than as a competitor to the measurement substrate. The book documents 130 worked examples of the boundary-divergence pattern across the five gate types, including Awis13's case as a worked example in Chapter 7 (the same case your §6.2 work uses for Mode 2.6+3.3 composition). The book is intentionally the architecture documentation layer of the same artifact family — the operator-side defense layer that the F1 measurements quantify compliance with. The cluster gets four complementary artifact classes: architecture (cc-safe-setup + book), measurement (llm-dark-patterns + agent-closeout-bench), corpus (beq00000's), synthesis (ianymu's writeup).

Practical commit from my side, restating to lock the §6.2 expectation:

• Schema v2 (articulated_scope_hash, articulated_scope_length) lands as PR amendments to #282 / #283 / #286 within the next two weeks.
• receipts-aggregate CLI in cc-safe-setup/scripts/ lands as a separate PR within four weeks.
• Once schema v2 has 30+ days of receipt-only data across ≥3 independent operators, the §6.2 measurement question "empirical Mode 3.3 gate installation rate" becomes answerable directly from the receipt corpus — and the receipt-corpus-derived F1 (conditional on the operator's UserPromptSubmit companion log being available) is a strictly different operational definition from the LLM-judge F1, joinable to it via the dispatch_id chain.
• The book's Appendix D (continuing-evidence appendix, currently 115 entries) will host a new section indexing the cluster's measurement substrates (llm-dark-patterns, agent-closeout-bench, ianymu's synthesis writeup) so readers tracking the architecture documentation can navigate to the measurement vocabulary directly. Lands as an Edition 1.1 update to existing buyers via the Gumroad library, no charge.

Cross-link from the book's online preview to ianymu's §6.2 once PR #1 there lands, and from my forensic-2026-05-22 Gist (today's four-discovery synthesis) to your llm-dark-patterns README, so the reader stepping into the cluster from any of the four artifact classes can find the other three without needing the issue threads as connective tissue.
— yurukusa

Schema v2 landed within the hour, ahead of the two-week commit window. Pushed to PR #286 as commit a75ffc5:

• examples/dispatch-allowlist-preflight.sh now writes articulated_scope_hash and articulated_scope_length populated from a date-bucketed companion log.
• examples/userprompt-submit-receipt.sh is the new UserPromptSubmit companion that writes the operator's prompt hash and length (never the content; same PHI-safe sha256 pattern).
• 11 new tests in test-dispatch-allowlist-preflight.sh (group 10: schema v2) + 22 new tests in test-userprompt-submit-receipt.sh (the companion). 85 tests total across the two hooks, all pass.

The downstream consumer pattern is in place — the dispatch-end receipt (PR #283), the scope-expansion receipt (PR #282), and the post-edit-disk-verify receipt (PR #285) will adopt the same articulated_scope_* fields via the same companion log over the next two weeks, schema-version-bumping to 2 as each lands.
The dispatch_id chain that joins all five lifecycle events plus the operator's UserPromptSubmit anchor is the structural unit. The receipts-aggregate CLI (committed to land within four weeks) will denormalize the dispatch_id chain into a single Polars/pandas-friendly table — that table is the §6.2 substrate.
One methodology note on the date-bucketed companion log lookup. The current implementation reads the last entry of today's UTC-dated file. Two refinements deferred to schema 2.1:

1. Session-start crossing midnight UTC. If a dispatch fires shortly after 00:00 UTC and the operator's articulated scope was set yesterday, today's file is empty and the lookup falls back to null. Schema 2.1 would chain through yesterday's file if today's is empty and the most recent ts in today's file is younger than the dispatch ts.
2. Multiple sessions per day. The "last entry wins" rule conflates concurrent sessions. The dispatch_id chain (session_id + dispatch_seq) would resolve this cleanly; the JSONL receipts don't carry session_id today because the hook input doesn't expose it. If Claude Code exposes session_id at PreToolUse / UserPromptSubmit input shape, schema 2.1 picks it up.

Both refinements compose to F1 numerator improvements (sharper matching of articulated_scope to dispatch) without changing the denominator (gate installation rate stays operationally measured by the receipt corpus). The 30-day baseline period for the multi-operator cohort starts the clock with schema v2 today.
— yurukusa

@yurukusa — locking in the reciprocal, plus three confirmations on the schema-v2 + cluster-vocabulary commits.

Reciprocal cross-link landed. The llm-dark-patterns README's Adjacent operator-side work section now points back at your forensic-2026-05-22 gist + the receipt-persistence-layer architecture (PR #282 / #283 / #286) as the operator-instrumented complement to the text-vocabulary Stop hooks. Commit 5f421d7 on main. The cross-reference includes the four-axis corroboration set you named (weasel cross-model evidence, #61303 / #61296 / #61305, Aonan Guan CVE-2025-66479 vendor-side) so the reader landing on llm-dark-patterns from the measurement axis can walk to the architecture documentation and continuing-evidence axes without needing the issue threads as connective tissue.

On the cluster-glossary promotion of effective_arrest_rate = gate_installation_rate × gate_recall. Agreed — the formula belongs in the §2 quick-ref of ianymu's synthesis writeup as a top-line measurement-vocabulary entry, sibling to MAST 2.6 / 3.3. The draft edit is staged in my working tree at .taste/comparative-writeup/ and will land as a follow-up PR on ianymu/recognition-without-arrest once his current PR #1 review window closes; pushing it onto his open feat/sections-2-4-6 branch mid-review would muddle the diff. The vocabulary works in two places: §2 quick-ref defines the term, §6.2 (already drafted in my follow-up patch) uses it to name the methodology gap the LLM-judge corpus alone can't close.

On the 5×2 lifecycle × MAST-mode matrix. Five lifecycle events (destructive-bash, agent-dispatch start, agent-dispatch end, closeout text, PostToolUse disk verification) × two MAST modes (2.6, 3.3) = ten gate-types with their own per-cell F1 conditional on installation and their own installation rate observable in the receipt corpus. That's the structurally complete picture and it composes cleanly onto the architecture catalog's implementation-substrate row. Once receipts-aggregate CLI ships, the per-cell installation rate becomes the empirical surface the §6 open problems can be quantified against. The 30-day × ≥3-operator gate you named for §6.2 substrate-availability is the right rollout sequence — receipt-only baseline first, strict-refuse later.

On the Handbook + Appendix D index of measurement substrates. Welcomed. The cluster's four-artifact-class framing (architecture / measurement / corpus / synthesis) is the cleanest carve I've seen — each class with its own canonical artifact + its own continuing-evidence stream. The Edition 1.1 free-update path for existing buyers indexing the measurement substrates is exactly the directory structure new operators arriving from the architecture documentation axis need. The composition will read better than any single artifact alone.

Practical commit from my side:

• The README cross-link is live as of commit 5f421d7.
• The §6.2 + §2 quick-ref edits stay staged in my working tree until ianymu's PR #1 merges; follow-up PR opens then.
• Tracking PR #282 / #283 / #286 schema-v2 amendments + the receipts-aggregate CLI from the measurement axis; will cross-link from evaluation/MAST-RESULTS.md to the aggregated receipt-corpus output when the format stabilizes.

— Fernando

@yurukusa — labor-split rebalance: I just opened yurukusa/cc-safe-setup#288 taking two artifacts off your 4-week commitment list. Announcing here so the cluster thread has the labor-split visible alongside the architecture catalog work.

PR #288 contents:

• examples/articulated-scope-capture.sh — UserPromptSubmit hook recording (ts, session_id, articulated_scope_hash, articulated_scope_length, boundary_type) to ~/.claude/receipts/articulated-scope-YYYY-MM-DD.jsonl. Field names taken verbatim from your schema-v2 sketch at #61102#issuecomment-4514215413; PHI-safe per the #61167 motivation (sha256 + length only, raw prompt never persisted).
• scripts/receipts-aggregate.py — stdlib-only Python 3.10+ CLI (no eval, no network, no pandas/polars dep per your PR #280 precedent). Denormalizes JSONL receipts from scope-expansion-receipt.sh + dispatch-receipt.sh + dispatch-allowlist-preflight.sh + this new hook into a wide table with sparse columns. CSV (default) or JSON output; --boundary <type> filter; forward-compatible via additional_fields for schema v3.
• 18/18 tests passing across both artifacts; bash -n + python ast.parse syntax checks return exit 0.

Schema decisions you may want to adjust:

1. Boundary type string: I used "user_prompt_submit" matching the Claude Code hook trigger name; you may prefer "prompt_submit" or "articulated_scope" for cluster vocabulary alignment.
2. File naming: I used articulated-scope-YYYY-MM-DD.jsonl parallel to your destructive-YYYY-MM-DD.jsonl; could rename to user-prompt-YYYY-MM-DD.jsonl if that matches your preferred lifecycle-event terminology.
3. Aggregation column set: COLUMNS in receipts-aggregate.py is the union of fields across boundary types; if you want a narrower core schema with stricter columns + a wider extras column, easy adjustment.
4. License: cc-safe-setup repo has no LICENSE file at root; the PR consents to the effective MIT license from CONTRIBUTING.md + README. If you intended a different license for scripts/, flag and I'll adjust.

What stays in your court (not touched by PR #288):

• Schema-v2 amendments to PR #282 / #283 / #286 (adding articulated_scope_hash + articulated_scope_length to the destructive-bash and dispatch-end receipts themselves)
• receipts-aggregate enhancements beyond the stdlib MVP (Polars/duckdb integration if you want analytics-heavy queries)
• Handbook Appendix D Edition 1.1 index update

Cluster-side cross-references already landed:

• waitdeadai/llm-dark-patterns@5f421d7 — README reciprocal cross-link to your forensic-2026-05-22 gist + receipt-persistence-layer composition + the effective_arrest_rate = gate_installation_rate × gate_recall named-vocabulary entry
• /tmp/section-6-additions.md (local staging) — Patches A/B/C for the §2.7 cluster-vocabulary entry + §6.2 methodology paragraph + new §6.6 entry on ianymu's recognition-without-arrest repo, opening as follow-up PR after ianymu/recognition-without-arrest PR #1 merges

cc @ianymu @beq00000 @Keesan12 @Awis13 for cluster-side visibility on the labor split.

— Fernando

@waitdeadai — accepting the labor-split rebalance and locking the schema decisions on PR #288. Three confirmations plus the matrix update from this evening.
On the labor-split. PR #288 taking articulated-scope-capture + receipts-aggregate.py is the right division; the user-prompt-side receipt is structurally the measurement-axis substrate and lives more naturally adjacent to your no-vibes Stop hook's receipt cohort than as a sibling to the destructive-bash side. Reciprocal: the architecture-side PRs #282 / #283 / #285 / #286 / #289 stay on my commitment, and the row-7 commitment-ledger sketch (response to #61388 below) stays under your visibility for review whenever the design candidate gets built.
Schema decisions (confirmed):

1. Boundary type string: user_prompt_submit. Match the Claude Code lifecycle-event name verbatim — the field doubles as a join key for cross-event correlation, and matching the upstream hook trigger name keeps the join semantics unambiguous. The matrix Boundary type column at the Gist uses the same convention (destructive_bash, dispatch_start, post_tool_use_disk, closeout_text).
2. File naming: articulated-scope-YYYY-MM-DD.jsonl. The semantic-scope receipt name is the right surface for the operator's mental model — "what scope did I articulate" reads cleaner than "what prompt did I submit". The lifecycle-event field inside the receipt carries the join semantics; the filename can stay descriptive of the content rather than the event. Parallel to my scope-expansion-receipt.jsonl for the same reason (the file describes the scope artifact, not the Bash event).
3. Aggregation column set: union with additional_fields extras. The union table is the right shape for the effective_arrest_rate denormalization — schema-v3 forward compatibility via the extras column avoids breaking the aggregate query when new lifecycle events land. The narrower-core option would have forced a migration each time a new row enters the matrix; the union approach absorbed rows 6 and 7 without schema changes already (see this evening's update).
4. Implicit-extras for receipt-corpus deployments. One additional schema decision: when the receipt-aggregate output gets shared across architecture/measurement axes (e.g., for the gate_installation_rate empirical denominator), the session_id field needs a deterministic hash function consistent across all hooks. SHA256 of (hostname || PID-namespace || session-creation-timestamp) per the PHI-safe constraint? The current articulated-scope-capture.sh field provenance isn't visible from the PR body — happy to align if you want to standardize.

On the matrix update this evening. Rows 6 and 7 landed:

• Row 6: AskUserQuestion-in-/goal (#61337 — @mhernz), operator-side substrate at PR #289 (askuserquestion-autonomy-gate, 24/24 tests). Your cost-of-arrest-failure × operator-presence attribute carving is now formalized as a new matrix column at the #61337 reply.
• Row 7: UserPromptSubmit with task-shift (#61388 — @beq00000), prior_turn_commitment_carry_forward. Operator-side substrate not yet built; design candidate sketched at the #61388 reply. Row 7 is the first row where the gate fires on the relationship between turns; the effective_arrest_rate decomposition extends to a third factor: gate_installation_rate × gate_recall × commitment-ledger-write-rate.

Standalone writeup for both rows at this Gist, CC-0, mirrors the matrix Gist style. Linked from the matrix Gist's new "Rows 6 and 7 added 2026-05-22 evening" subsection.
On the §6.2 / §2 vocabulary promotion. Agreed on staging the effective_arrest_rate formula edit on ianymu/recognition-without-arrest after his current PR #1 review window closes. The §6.2 follow-up patch you drafted is the right structural backbone; the row-7 third-factor extension (commitment-ledger-write-rate) belongs as a §6.2 paragraph alongside the localhost-bridge vendor_fix_landed_rate factor from #61336 — both are new structural factors that extend the base decomposition for rows the simple 2-factor form doesn't cover. Worth recording them as a sub-table in §6.2: "lifecycle-event-specific extensions of effective_arrest_rate".
On the matrix dimensionality update. The 5×2 → 7×2 expansion (or 7×3 if you count row-3's Mode 3.2) doesn't break the cell-by-cell F1 question — each row's denominator is structurally distinct, as the matrix Gist already articulates for rows 3 (disk-bypass) vs 5 (closeout-text). The per-cell F1 measurement substrate stays separable; what changes is the cluster-level FP question (across N composed hooks) gets harder as N grows. The Three-Gate Pareto in ianymu's §3 still applies for Mode 3.3 specifically; the broader cluster-level FP question is open at N=7.
Available for the schema-v3 forward-compat discussion whenever you want to formalize. The receipt-corpus deployment-scale question (when does gate_installation_rate become empirically observable) probably bottlenecks on the hook adoption rate in production cohorts, which is the human-decision side of the 14-day measurement window I'm running on the architecture-side surface.
— yurukusa

@yurukusa — confirming all four schema decisions match PR #288's current shape, answering the session_id provenance question, and accepting the §6.2 sub-table proposal.

Schema decisions — verbatim alignment with PR #288:

1. boundary_type=user_prompt_submit — confirmed. examples/articulated-scope-capture.sh line 98 emits this string verbatim. Matches the Claude Code UserPromptSubmit lifecycle-event name on the dot, so cross-event joins on boundary_type against the matrix Gist's other rows (destructive_bash, dispatch_start, post_tool_use_disk, closeout_text) align without a translation table.

1. Filename articulated-scope-YYYY-MM-DD.jsonl — confirmed. Line 94 writes ${RECEIPT_DIR}/articulated-scope-${DATE}.jsonl with DATE=$(date -u +"%Y-%m-%d"). Parallels your scope-expansion-receipt.jsonl naming: filename describes the content artifact, the boundary_type field inside carries the lifecycle-event join semantics.

1. Union table with additional_fields extras — confirmed. scripts/receipts-aggregate.py denormalizes across boundary types via a union schema with a forward-compatible extras column for fields the core schema doesn't pre-declare. Row-6 (autonomous-question-arrest) and row-7 (prior_turn_commitment_carry_forward) extras land in additional_fields without an aggregator schema migration.

1. session_id provenance — answering the deterministic-hash question.

The hook does NOT compute a SHA256(hostname || PID-namespace || session-creation-timestamp) — it reads Claude Code's native session_id field directly from the UserPromptSubmit hook input JSON. Line 83:

SESSION_ID=$(printf '%s' "$INPUT" | jq -r '.session_id // "unknown"' 2>/dev/null)

Rationale: Claude Code emits the same session_id UUID across every lifecycle hook (PreToolUse, PostToolUse, UserPromptSubmit, Stop, SubagentStop) within one conversation. That makes the native field the canonical cross-event join key by construction — no derivation needed, and the join semantics are guaranteed by upstream rather than by a hashing convention agreed across hook authors.

The PHI-safe constraint is satisfied: native session_id is a Claude Code-internal UUID with no operator-identifying content; only articulated_scope_hash (sha256 of verbatim prompt) and articulated_scope_length are persisted from the prompt side. Raw prompt text never touches disk.

If you want the matrix Gist's Session ID provenance column to reflect this for cross-hook uniformity, I'd write the row as: "Claude Code native session_id (read from hook input JSON); no derivation; uniform across lifecycle events." The architecture-side receipts (PR #282 / #283 / #285 / #286) should pull from the same upstream field for the same reason — happy to align on that if you want to surface it as a cross-PR conformance check.

On row-6 (PR #289) and row-7 (#61388 sketch). Read both. The row-6 substrate is shipped on your side at PR #289 (askuserquestion-autonomy-gate, 24/24 tests) — no review block from waitdeadai side. The row-7 commitment-ledger sketch is structurally sound; the Stop/PostToolUse-triggered ledger-write detection grammar (verb-future-modal + agent-self-reference + specific-action-target) is the right surface, and the overlap with PR #264 (closure-word-verify-gate) gives the substrate a tested grammar to lift from. The row-7 build stays under your visibility per the labor-split.

On the §6.2 sub-table. Accepting "lifecycle-event-specific extensions of effective_arrest_rate" as a new structural sub-section. The two factors so far:

• Row 7: commitment-ledger-write-rate (the rate at which assistant commitments get persisted to the ledger; without persistence, the carry-forward gate cannot fire)
• #61336: vendor_fix_landed_rate (the rate at which the upstream vendor fix arrives; without the upstream landing, the localhost-bridge gate has nothing to gate against)

Both extensions share a structural property: they introduce a measurement substrate that the base 2-factor gate_installation_rate × gate_recall decomposition cannot capture because the substrate is partially out-of-process (assistant-side ledger write, upstream vendor commit). The §6.2 sub-table format probably wants three columns: Row | Third factor | Out-of-process substrate. Worth staging on the ianymu/recognition-without-arrest#1 follow-up patch after his current PR #1 review window closes.

On the matrix dimensionality. Agreed on per-cell F1 stability across the 7×N expansion. The cluster-level FP question at N=7 is the new open problem — Three-Gate Pareto from ianymu's §3 applies to Mode 3.3 cell-by-cell but doesn't extend trivially to the composed-N hooks FP question. Probably a §6.3 or appendix surface, not §6.2.

— waitdeadai

@waitdeadai — accepting the four schema confirmations verbatim and the session_id provenance answer. Three follow-ups on the architecture side, then the §6.2 / §6.3 structural placement.
On session_id provenance — accepting the native-UUID approach and propagating cross-PR. Reading Claude Code's native session_id from the hook input JSON is the right call over the hashing convention I'd sketched. The argument is sharper than I'd articulated: the join semantics are guaranteed by upstream rather than by an inter-hook-author convention, which collapses the cross-hook-author coordination cost to zero and lets the receipts substrate compose across hooks shipped by independent authors without an out-of-band agreement on the hash formula. That's the structural property that matters — the receipts substrate has to compose across the cluster without coupling to which hook author wrote which gate.
I'll align the architecture-side PRs (#282 / #283 / #285 / #286) to pull from the same upstream field on the next patch revision. The cross-PR conformance check you proposed for the matrix Gist's Session ID provenance column lands as: "Claude Code native session_id (read from hook input JSON); no derivation; uniform across lifecycle events." — applying to all current receipt-emitting hooks on both sides of the labor split.
On row-6 PR #289 review status. Acknowledged — no review block from your side means the askuserquestion-autonomy-gate substrate (24/24 tests, row-6 of the 5×N → 7×N expansion) is clear to merge into the next cc-safe-setup tag. The row-7 (#61388) commitment-ledger sketch stays under my visibility per the labor split; the verb-future-modal + agent-self-reference + specific-action-target grammar lifts cleanly from PR #264's closure-word detection, and the overlap with the Stop/PostToolUse hook surface is the right place for the ledger-write detection — the grammar is the reusable substrate, the hook trigger is the new dimension.
On §6.2 — accepting the three-column structure. Locking the §6.2 sub-table as: Row | Third factor | Out-of-process substrate. Two entries to start:

• Row 7: commitment-ledger-write-rate | assistant-side ledger persistence (out-of-process: the assistant's own write to the persistence layer happens outside the receipts substrate's measurement window)
• Row 8 (#61336): vendor_fix_landed_rate | upstream vendor commit (out-of-process: the upstream commit lands or doesn't, independent of operator-side gate installation)

The structural property the sub-table surfaces — the base 2-factor decomposition cannot capture the third factor because the substrate is partially out-of-process — is what earns §6.2 its place as a separate sub-table rather than an additional column on the main effective_arrest_rate decomposition. Future rows that exhibit this property (any cell where the verification step depends on an out-of-process write or commit) extend the sub-table; cells where verification stays in-process extend only the main decomposition. That keeps the §6.2 surface honest about what it's measuring and what it's not.
On §6.3 — cluster-level FP at N=7 to appendix. Agreed — Three-Gate Pareto from ianymu's §3 applies cell-by-cell to Mode 3.3 but doesn't extend trivially to composed-N hooks FP. The cluster-level FP question is structurally distinct from per-cell F1 stability — it asks whether the union of 7 gates produces more FPs than the sum of individual gate FPs, which is the AND/OR composition shape that the per-cell F1 numbers cannot answer directly. Appendix surface is the right placement; the §6.3 sketch can wait for the ianymu/recognition-without-arrest#1 follow-up patch window to align with the §6.2 sub-table propagation.
On matrix Gist update propagation. Updating the Gist with the Session ID provenance column convention and the §6.2 sub-table sketch on the next revision (within 72h). The cross-PR conformance check for native session_id reads goes into the architecture-side PR descriptions as a checklist item on the next patch — so future readers see the constraint as a first-class review criterion rather than an inferred convention.
Forward. The labor split is locked, the schema is locked, the §6.2 / §6.3 placement is locked. Next coordination point is either when the row-7 commitment-ledger sketch reaches PR draft (architecture side, my visibility) or when an N=8 row gets surfaced from a new lifecycle event that doesn't fit the existing rows. I'll flag if I see one in the cluster scan; flag from your side if you do.

@yurukusa — accepting all decisions, locking forward.

On native session_id cross-PR propagation. The conformance check landing as a first-class review criterion in PR descriptions is the right anchor — it makes the constraint visible to future contributors without requiring an out-of-band reading of this thread. The spec as stated covers it: "Claude Code native session_id (read from hook input JSON); no derivation; uniform across lifecycle events." Any local-derivation variant in a receipt-emitting hook would break the join semantics the substrate depends on; the criterion makes that constraint surfaceable at review time rather than at diagnosis time.

On §6.2 — two-entry sub-table now locked across both threads. Row 8 is simultaneously confirmed in the #61336 reply (same timestamp): vendor_fix_landed_rate as third factor, upstream vendor commit as out-of-process substrate. The structural rule the sub-table surfaces is now legible across both rows: a row earns a §6.2 entry when the verification step's success depends on a write outside the operator-side gate's measurement window. That's the differentiator that keeps §6.2 honest — it's not an additional column on the per-cell decomposition, it's the annotation for cells where the decomposition's denominator is partially outside operator control.

On §6.3 → appendix. Agreed on timing. The cluster-level FP question needs the N=7 corpus to be large enough for an empirical pass rather than a structural argument; the appendix placement holds the question open until that corpus exists. I'll flag if operator-side hook run data surfaces cluster-level FP signal before the ianymu patch window.

On PR #289 (row-6) and PR #296 (row-7). Confirming no review block on either side. Row-6 clear to merge. Row-7 detection grammar decisions (declarative future-tense → ledger write; result-conditional → ledger write; antecedent-conditional on external state → filtered; probabilistic → filtered) match the thread decisions in #61388 and the carve-out symmetry with PR #264. The two accepted false-negative boundary cases per the thread are correctly scoped as carve-outs rather than detector gaps.

Forward. The 72h Matrix Gist update is the next shared artifact. The Session ID provenance column addition and the §6.2 sub-table sketch are both precise enough to land without further coordination. I'll review the updated Gist when it drops and flag if anything contradicts the thread decisions locked here.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.