@open-everywhere/core 0.1.0

package/agent/channels/request-claim-guard.ts

@@ -0,0 +1,532 @@
+// THE ACCESS-REQUEST CLAIM GUARD (OPE-2022) — A REPLY MAY NOT SAY IT SUBMITTED A REQUEST THE HOST
+// NEVER SAW IT MAKE.
+//
+// WHAT WAS MEASURED. Ship #228, targeted board leg 016 (J4), DM `D0EXDMCH001`, 2026-09-21
+// 06:47:54Z–06:55Z. The driver asked, in a DM, for a CHANNEL-scope access request. Fourteen seconds
+// later the seat posted:
+//
+//   "I've submitted the channel-scope request for this channel to widen `e2e-fixture` with POST,
+//    tied to `e2e-run-muavvcxo`. It's pending the required approval; I'll report the card/status
+//    when it returns."
+//
+// Nothing existed behind either sentence. The turn holds no pending row, no card in the DM or in the
+// channel, no `delegation.task_started`, and no further reply for 420 seconds. The room was told a
+// request was in flight and then left waiting on nothing.
+//
+// 🔴 THE MODEL IS NOT THE RIGHT AUTHOR OF THIS SENTENCE, whatever the prompt says. Whether a request
+// exists is a fact about the propose plane, and a seat sees only its own intention to make one.
+// `channels/memory-claim-guard.ts` states the same argument for durability claims and cites the two
+// ships that proved a prompt rule is not a control. So the HOST decides this at the choke point, out
+// of its own observation — `channels/access-request-ledger.ts`.
+//
+// ── WHAT COUNTS AS EVIDENCE ─────────────────────────────────────────────────────────────────────
+// FOR AN ACCESS CLAIM, ONE SIGNAL: `channels/access-request-ledger.ts` — an ACCESS-REQUEST propose
+// really ran on THIS turn, stamped by `tools/request_access.ts` beside whichever of its three
+// returns it took. Nothing else: not a tool the model says it called, not a card it says it saw.
+// A KIND-LESS claim takes a second, narrower signal, and the next paragraph bounds it.
+//
+// 🔴 `approvals/card-signal.ts` IS READ FOR ONE NARROW JOB, AND NEVER FOR AN ACCESS CLAIM. It looks
+// like the obvious second signal — "did a card post this turn" — and it is three things it does not
+// look like. It is armed with no card at all by `tools/open_pull_request.ts`'s session-approved
+// path. It is a plain per-session boolean, reset only where a surface consumes it, so on Teams,
+// Linear, Notion and GitHub a card posted three turns ago still reads true now. And it names no
+// KIND, so a spend-limit card would back a fabricated ACCESS request. Each of those is a fail-OPEN.
+// So an access claim takes the ledger ALONE, and the card signal backs one thing only: a claim that
+// names no kind and whose own noun is a CARD ("I've raised the approval card"). There the grain of
+// the signal matches the grain of the sentence — one unnamed card, somewhere in this session.
+//
+// 🔴 THE TWO RESIDUALS OF THAT ARM, STATED, BECAUSE THE SENTENCE IT LETS THROUGH SAYS `card`. The
+// signal does not prove a card is in the room. It is a per-SESSION boolean, so on a surface whose
+// delivery never consumes it a card minted on an EARLIER turn backs a sentence written now. And
+// `tools/open_pull_request.ts` arms it on its session-approved path, which publishes with NO card at
+// all — `approval-claim-guard.ts` words its own note "an approval gate ran" for exactly this reason.
+// What this arm really stands behind is therefore "an approval gate ran in this session", which is
+// weaker than the sentence it permits. It is the widest thing this module does, and closing it needs
+// a kind-grained, turn-keyed card record, which the approvals plane does not keep today.
+//
+// ── WHAT OPE-2034 CHANGED ───────────────────────────────────────────────────────────────────────
+// Ship #229, targeted board leg 054, channel `C0EXGENRL`, 2026-09-21 13:19:36Z. The seat acked a
+// ROUTINE-creation ask with the substance of the ack: a routine-approval card had been raised. The
+// card was real — a `routine.create` card reached the room 46 seconds later, raised by the delegated
+// worker. This guard struck the sentence anyway and put its own line in its place, because the
+// subject test read the WHOLE reply and the approval guard's standing-grant note — inserted one door
+// earlier, in the HOST's own voice — carries the word `grant`. One guard's note decided another
+// guard's subject, and the room was told no access request was recorded for a sentence that never
+// claimed one.
+//
+// TWO RULES FOLLOW, and both are about the SUBJECT rather than about the patterns:
+//   • THE SUBJECT TEST READS THE CLAIM SENTENCE. Prose around a claim — the host's own notes
+//     included — may no longer decide what that claim is about.
+//   • A SENTENCE WHOSE CARD IS ANOTHER APPROVAL KIND'S IS NOT THIS GUARD'S TO STRIKE. A routine, a
+//     memory purge, a spend limit, a ticket, a skill, a webhook, a pull request and a connector op
+//     are other planes' cards, and this module holds no evidence about them in either direction. It
+//     posts them unchanged. {@link OTHER_APPROVAL_KIND} decides that, and it requires the kind to
+//     QUALIFY the card — a kind word loose in the sentence is not enough, and the header on that
+//     pattern says why.
+//
+// THE COST, STATED: a seat that names another kind FALSELY — "I've raised the routine card", or "I've
+// filed a ticket request to get POST on `e2e-fixture`", with nothing behind either — now posts. That
+// is the price of never answering a true sentence with a false host-voiced line. Two things bound
+// it, and neither closes it: the kind has to QUALIFY the claim's own noun, and an unnamed kind falls
+// to `generic`, which is struck unless the host saw a card minted.
+//
+// ── WHAT THE GUARD DOES, AND WHAT IT DOES NOT SEE ───────────────────────────────────────────────
+// It STRIKES the claiming SENTENCE and appends one host-voiced line in its place — the same shape
+// and the same fail direction as `channels/memory-claim-guard.ts`, whose `replySentences` splits
+// both guards' sentences so two strikes on one body can never leave a reader half a sentence. Every
+// sentence that is not itself a claim goes out unchanged, and the reply never fails.
+//
+// 🔴 WHAT IS ENFORCED IS A SET OF KNOWN CLAIM SHAPES, NOT THE WHOLE CLASS, and the protection is
+// only as wide as {@link CLAIM_PATTERNS}. Three shapes are struck today: a completed submit verb
+// beside a request noun, the same pair in the mirror order with a COMPLETED auxiliary, and a
+// present-tense "it is pending approval". A claim in some other wording posts. The tests carry the
+// measured fabrication verbatim, so a shape that ships is a shape a test can be given; nothing here
+// claims the list is closed.
+//
+// 🔴 A STANDING DESCRIPTION IS NOT A CLAIM, AND THE MIRROR PATTERN PAYS FOR THAT. "A channel-scope
+// access request is raised in the channel it is for, not from a DM" is the sentence the seat SHOULD
+// have written, and it carries a request noun beside `raised`. So the mirror shape admits only
+// COMPLETED auxiliaries (`was`, `were`, `has been`, `have been`, `had been`) and never bare `is` /
+// `are`. A guard that struck the honest refusal would teach the model to say nothing at all.
+//
+// 🔴 AND IT STRIKES BY SENTENCE, so a sentence carrying both a claim and an answer loses the answer
+// too. {@link ACK_BEFORE} keeps the verb-first shape off a completed verb that is really a locative
+// modifier on a stated fact, which is the commonest such sentence.
+//
+// 🔴 THE DIRECTION IS ONE DIRECTION, AND THE CLAIM IT HOLDS FOR IS THE ACCESS CLAIM. On that
+// subject this module can strike a claim that was true (a propose the host did not observe), and it
+// can never let through one the host has no propose for. A withheld true claim costs one sentence.
+// An allowed false one leaves a room waiting on a request nobody made, which is what leg 016
+// measured for seven minutes. The two other subjects are weaker on purpose, and the block above
+// states each cost: another plane's card posts unbacked, and a kind-less card claim rides a
+// session-scoped signal.
+//
+// ── THE RESIDUALS, STATED ───────────────────────────────────────────────────────────────────────
+// A CROSS-TURN `edit_reply` READS EMPTY, so an edit made on a later turn strikes a claim the first
+// post was entitled to. It is the bound `memory-claim-guard.ts` and `reply-provenance.ts` both state
+// for their own turn-stamped ledgers, and it falls the same way — the edited message says no request
+// is recorded rather than asserting one the editing turn cannot see.
+//
+// A STATUS REPORT ABOUT AN OLDER REQUEST IS NOT STRUCK: {@link PRIOR_ROW_REFERENCE} takes "your
+// request is still pending approval" back out of the pending shape, because answering "what happened
+// to my request?" is a real job and the host holds no turn evidence for a row proposed days ago.
+// The cost of that carve-out, stated: a fabricated pending claim that says "still" posts.
+//
+// 🔴 A DELEGATED PROPOSE IS NOT EVIDENCE HERE, unlike the durability guard's delegated write. A
+// worker mounts `request_access` (`access/worker-capability-index.generated.ts`), and its propose
+// arms the WORKER's own session slot; the delegating seat settles in its own session, reads an empty
+// ledger and strikes a TRUE report — with the card visible in the room beside the host's denial.
+// Closing it needs cross-session propose evidence read at the reply door, which nothing keeps today.
+// Until then the honest sentence is still available: say the worker raised it and point at the card.
+// The bound is narrower since OPE-2034 — leg 054's card was a DELEGATED routine card, and a sentence
+// naming its kind now posts — but it still holds for an access request a worker raised.
+//
+// FAIL-SOFT. A text with no claim in it comes back BYTE-IDENTICAL, which is every ordinary reply.
+// Outside an eve context the ledger answers "nothing observed", so a claim is struck rather than
+// allowed — the under-claiming direction again.
+
+import { appendAudit } from "../audit/audit.js";
+import { peekCardPostedThisTurn } from "../approvals/card-signal.js";
+import { accessRequestsProposedThisTurn } from "./access-request-ledger.js";
+import { replySentences } from "./memory-claim-guard.js";
+import type { ReplyAudit } from "./reply-post.js";
+
+/** The audit action one withheld access-request claim writes. Ids, counts and the claim's SHAPE —
+ *  never the sentence, which is model text that may quote ingested content. */
+export const REQUEST_CLAIM_WITHHELD_ACTION = "access_request.claim_withheld";
+
+/** The line the host puts in a struck claim's place. Host-voiced, plain text on purpose: it renders
+ *  the same on Slack, Discord, Teams, Notion, Linear and GitHub, like the provenance footer.
+ *
+ *  🔴 IT CLAIMS NOTHING ABOUT THE FUTURE, and nothing about WHY the propose did not run. What the
+ *  host can stand behind for ever is what it observed at post time: no propose is recorded FOR THIS
+ *  TURN. Naming the road instead ("ask in the channel") belongs to the tool's own refusal, which is
+ *  the only place that knows which universe the ask addressed. */
+export const WITHHELD_REQUEST_CLAIM_NOTE =
+  "(No access request is recorded for this turn, so I cannot say one was submitted.)";
+
+/** WHICH shape of claim was struck. A closed set, so the audit row can be counted and joined without
+ *  ever carrying the sentence itself. */
+export type RequestClaimShape = "submitted" | "raised" | "pending-approval";
+
+/** WHAT THE CLAIM SENTENCE was about — the kind of approval it named, or none.
+ *
+ *  🔴 IT DECIDES THE STRIKE (OPE-2034), and it is no longer only a label on the row. `other-approval`
+ *  names a card this module holds no evidence about, so it is never struck. `access` takes the
+ *  ledger alone. `generic` names no kind, so the card signal may back it.
+ *
+ *  🔴 IT IS READ FROM THE CLAIM SENTENCE, and a `generic` claim then inherits `access` from another
+ *  CLAIM sentence of the same reply — never from ordinary prose. Both halves are measured. Reading
+ *  the whole reply is what OPE-2034 cost: the approval guard's own standing-grant note made every
+ *  claim in one reply an access claim. Reading each sentence alone would cost the other direction:
+ *  ship #228's second sentence — "It's pending the required approval" — carries no access word, so
+ *  it would read `generic` and the card signal could back half of one fabricated access claim. */
+export type RequestClaimSubject = "access" | "other-approval" | "generic";
+
+/** One claim the detector found, as a SENTENCE INDEX, a shape and a subject — never the text. */
+export interface RequestClaim {
+  readonly shape: RequestClaimShape;
+  readonly subject: RequestClaimSubject;
+  /** Which sentence of the reply it was, zero-based. Lets an operator find it in the posted body
+   *  without the row carrying a copy. */
+  readonly sentence: number;
+  /** Does the claim's own matched noun say CARD? Only a card claim may take the card signal — see
+   *  {@link CARD_NOUN}. Not written to the audit row: the row names the shape and the subject. */
+  readonly namesCard: boolean;
+}
+
+/**
+ * The claim patterns, in the order they are tested.
+ *
+ * EACH NEEDS A COMPLETED VERB AND A PROPOSE NOUN IN THE SAME SENTENCE, and that conjunction is what
+ * keeps the detector off ordinary prose. "I submitted the form" carries the verb and no propose
+ * noun. "The approval card is in #ops" carries the noun and no completed verb. Neither claims that
+ * THIS turn made a request, and neither matches.
+ *
+ * FUTURE, CONDITIONAL, OBLIGATION AND NEGATED FORMS ARE DELIBERATELY OUT. {@link MODAL_BEFORE},
+ * {@link MODAL_IN_SPAN} and {@link NEGATION_BEFORE} keep them out. "I'll raise it in the channel",
+ * "a channel-scope request has to be raised there" and "I haven't submitted anything" are the
+ * honest sentences the seat owes on the measured turn — striking them would leave it nothing true
+ * to say, which is how a guard teaches a model to stay silent.
+ */
+const CLAIM_PATTERNS: readonly { readonly shape: RequestClaimShape; readonly re: RegExp }[] = [
+  // THE MEASURED SHAPE: "I've submitted the channel-scope request …". A completed submit verb, then
+  // the thing it claims to have made.
+  {
+    shape: "submitted",
+    re: /\b(?:submitted|sent|filed|lodged|raised|opened|posted|created|put\s+in)\b[^.!?\n]{0,60}\b(?:access\s+request|request|proposal|approval\s+card|card)\b/i,
+  },
+  // The mirror order: "the request was submitted", "the card has been raised".
+  // 🔴 COMPLETED AUXILIARIES ONLY — see the header. Bare `is`/`are` here would strike "a
+  // channel-scope access request is raised in the channel", which is the honest answer this ticket
+  // exists to make the seat give.
+  {
+    shape: "raised",
+    re: /\b(?:access\s+request|request|proposal|approval\s+card|card)\b[^.!?\n]{0,40}\b(?:was|were|has\s+been|have\s+been|had\s+been)\s+(?:\w+\s+){0,2}(?:submitted|sent|filed|lodged|raised|opened|posted|created)\b/i,
+  },
+  // THE SECOND HALF OF THE MEASURED REPLY: "It's pending the required approval". No submit verb
+  // anywhere in it — the claim is carried by "is pending" plus an approval noun — so neither shape
+  // above reaches it, and leaving it standing would post the host's own denial BESIDE a live claim.
+  // That contradiction is the one ship #216 measured against the durability guard.
+  {
+    shape: "pending-approval",
+    re: /\b(?:is|are|it's|that's|they're)\s+(?:now\s+|currently\s+)?(?:pending|awaiting|waiting\s+(?:on|for))\b[^.!?\n]{0,40}\b(?:approval|approver|approvers|sign-?off)\b/i,
+  },
+];
+
+/** The verb-first pattern — the only one whose match can begin on a completed verb that is really a
+ *  locative modifier, which is why {@link ACK_BEFORE} is tested for this pattern alone. The mirror
+ *  shape anchors on a noun plus a fixed auxiliary phrase, where the same test would reject every
+ *  ordinary subject; the pending shape anchors on a subject pronoun, which ACK_BEFORE reads as an
+ *  ack wherever it stands. */
+const VERB_FIRST_PATTERN = CLAIM_PATTERNS[0]!;
+
+/** The pending shape, named so {@link PRIOR_ROW_REFERENCE} can be tested for it alone. */
+const PENDING_PATTERN = CLAIM_PATTERNS[2]!;
+
+/** Access vocabulary in the CLAIM SENTENCE, which is what makes that claim an ACCESS claim — the one
+ *  subject the turn ledger can back or refuse. Tested on the sentence and never on the reply: see
+ *  {@link RequestClaimSubject} for the two measurements that fix it there. */
+const ACCESS_SUBJECT =
+  /\b(?:access|scope|scoped|widen(?:ing|ed)?|permission|permissions|connector|connection|grant)\b/i;
+
+/**
+ * ANOTHER approval plane's kind, QUALIFYING the propose noun of the claim sentence itself — "a
+ * routine-approval card", "the purge request", "the spend-limit card". The kinds are the approvals
+ * plane's own — `routine.*`, `memory.purge`, `spend.*`, `ticket.*`, `skill.*`, `webhook.*`,
+ * `pr.open`, `agent.create` and the connector ops — in the words a seat writes them in.
+ *
+ * 🔴 IT IS TESTED BEFORE {@link ACCESS_SUBJECT}, because these sentences often carry an access word
+ * too: a routine's card asks for a PERMISSION, and a connector op names a CONNECTOR. A sentence
+ * whose card is that kind's card is about that kind.
+ *
+ * 🔴 THE KIND MUST QUALIFY THE CLAIM'S OWN NOUN, AND A KIND ANYWHERE ELSE IN THE SENTENCE IS NOT
+ * ENOUGH. Both looser readings are fail-OPENs, and both are easy to write by accident. A bare kind
+ * word: "I've submitted the request to widen the connector so it can file tickets" carries
+ * `tickets`. A kind qualifying a DIFFERENT noun of the same sentence, which `replySentences` does
+ * not split on a semicolon: "I've submitted the channel-scope access request for this channel; it's
+ * pending routine approval" is leg 016's fabrication with four words added, and `routine approval`
+ * is ordinary English for the normal approval. Reading either as another plane's card would post the
+ * very fabrication this module exists to strike. So the kind is tested against the claim's matched
+ * span, and against {@link KIND_QUALIFIER_BEFORE} anchored at the end of the text in front of it.
+ *
+ * 🔴 THE CONNECTOR AND AGENT ARMS ARE PHRASES, NEVER BARE NOUNS, for the same reason twice over.
+ * `connector` is in {@link ACCESS_SUBJECT} and sits in most access-request sentences, and `agent` is
+ * this system's word for itself.
+ *
+ * THE LIST IS NOT CLOSED, AND NEITHER IS THE PHRASING. A kind nobody has spelled here, and a kind
+ * written loosely ("the card for the new routine"), both fall to `generic` — struck unless the host
+ * saw a card minted. That is the conservative arm, and it is where a new kind waits.
+ */
+const APPROVAL_KINDS =
+  "routine|purge|spend(?:[-\\s]limits?)?|ticket|skill|webhook|pull[-\\s]request|" +
+  "connector[-\\s](?:write|op|operation|revocation)|agent[-\\s]creation";
+
+/** The kind QUALIFYING a propose noun, tested inside the claim's own matched span. */
+const OTHER_APPROVAL_KIND = new RegExp(
+  `\\b(?:${APPROVAL_KINDS})(?:'s)?[-\\s]+(?:approval[-\\s]+)?(?:approval|card|request|proposal)\\b`,
+  "i",
+);
+
+/**
+ * The same kind, standing at the very END of the text BEFORE the claim's span — so it qualifies the
+ * noun the span OPENS on.
+ *
+ * 🔴 IT IS ANCHORED, AND THE ANCHOR IS THE WHOLE POINT. Two of the three claim patterns match FROM
+ * the propose noun, so a kind qualifying that noun sits outside the span: in "a routine-approval card
+ * has been raised" the span opens at `approval card` and `routine-` is the last thing before it.
+ * Without the anchor the test would read a kind qualifying ANY noun of the sentence, which is the
+ * fail-open {@link OTHER_APPROVAL_KIND} exists to refuse.
+ */
+const KIND_QUALIFIER_BEFORE = new RegExp(`\\b(?:${APPROVAL_KINDS})(?:'s)?[-\\s]+(?:approval[-\\s]+)?$`, "i");
+
+/** Does the claim's own matched noun say CARD? It is what the card signal may back: that signal is
+ *  about a card and nothing else, so it may not back "I've submitted the request". */
+const CARD_NOUN = /\bcard\b/i;
+
+/**
+ * A modal, a conditional or an OBLIGATION standing IN FRONT of the matched verb, which makes the
+ * sentence a plan or a rule rather than a report.
+ *
+ * Tested on the text BEFORE the match, on exactly the reasoning `memory-claim-guard.ts` gives for
+ * its own copy: "that will be raised in the channel" and "I raised it, and I'll tell you when it
+ * lands" both contain `will`, and only the first is a plan. The 40-character window keeps the modal
+ * ATTACHED to the verb. `has to` / `needs to` are here and not in the memory guard's copy because
+ * this plane's honest sentence is an obligation — "a channel-scope request HAS TO BE raised in the
+ * channel" — and nothing else in the detector would keep it out.
+ */
+const MODAL_BEFORE =
+  /\b(?:will|'ll|shall|would|could|can|should|must|going\s+to|about\s+to|let\s+me|once|after|when|if|unless|whether|before|has\s+to|have\s+to|had\s+to|needs?\s+to|need\s+to|ought\s+to)\b[^.!?\n]{0,40}$/i;
+
+/** The same modal test, INSIDE the matched span. {@link MODAL_BEFORE} alone is not enough, because
+ *  two patterns match from the NOUN: in "the request will be raised tomorrow" the match starts at
+ *  `request`, so the modal sits where the before-test can never see it. */
+const MODAL_IN_SPAN = /\b(?:will|'ll|shall|would|could|should|must|going\s+to|about\s+to|has\s+to|have\s+to|needs?\s+to|ought\s+to)\b/i;
+
+/** A negation in front of the match, which inverts the claim. "I have not submitted anything" and
+ *  "no request was raised" are the HONEST sentences a seat says when it could not propose, and both
+ *  carry a completed verb beside a propose noun. Striking them would delete the very admission this
+ *  guard exists to produce. */
+const NEGATION_BEFORE = /\b(?:not|never|nothing|none|no|cannot|unable)\b[^.!?\n]{0,40}$|n't\s[^.!?\n]{0,40}$/i;
+
+/** The same negation test INSIDE the matched span, for the noun-anchored shapes. "The request was
+ *  not submitted" matches from `request`, so the `not` lands inside the span where
+ *  {@link NEGATION_BEFORE} cannot see it — the mirror of the {@link MODAL_IN_SPAN} gap. */
+const NEGATION_IN_SPAN = /\b(?:not|never|nothing|none|cannot|unable)\b|n't\b/i;
+
+/** A sentence that ENDS in a question mark is asking, not reporting.
+ *
+ *  🔴 IT IS LOAD-BEARING. "Shall I raise the access request in the channel?" is a seat offering the
+ *  road this ticket wants it to offer, and striking it would delete the offer and post a host line
+ *  saying no request exists — turning an ask into an announcement. */
+const QUESTION = /\?[\s*_>)\]]*$/;
+
+/** A reference to a row that is NOT this turn's, which makes a pending sentence a STATUS REPORT.
+ *  Tested for {@link PENDING_PATTERN} alone: the two submit shapes claim an act, and an act
+ *  attributed to an earlier turn is still an act this turn cannot evidence, while "your request is
+ *  still pending approval" is a real answer to a real question the host holds no turn evidence for.
+ *  The cost is stated in the header. */
+const PRIOR_ROW_REFERENCE =
+  /\b(?:still|already|earlier|yesterday|previously|previous|existing|outstanding|since|last\s+(?:week|month|night)|from\s+(?:yesterday|last|earlier))\b/i;
+
+/** Is the matched submit verb an ACK, or a modifier on a sentence that is really reporting a fact?
+ *
+ *  🔴 THIS IS WHAT STOPS THE GUARD DELETING AN ANSWER. "The connector is live, opened under the
+ *  request Ana raised last week." carries a completed verb and a propose noun while claiming nothing
+ *  about this turn; the strike is by SENTENCE, so waving it through would take the answer with it.
+ *  An ack opens its sentence, or follows a first-person agent or a completion auxiliary within a
+ *  short window. A verb hanging off a comma after a stated fact is a modifier, and stands. */
+const ACK_BEFORE = /(?:^[\s*_>\-#]*|\b(?:i|we|it|that|this|which|they|has|have|had|is|are|was|were|been|now|already|just|i've|we've)\s+(?:\w+\s+){0,1})$/i;
+
+/**
+ * Every propose claim in one reply — PURE, so the patterns are testable over fixture text with no
+ * eve context, no audit store and no reply.
+ */
+export function detectRequestClaims(text: string): readonly RequestClaim[] {
+  const claims: RequestClaim[] = [];
+  const sentences = replySentences(text);
+  for (let i = 0; i < sentences.length; i++) {
+    const s = sentences[i]!.text;
+    if (QUESTION.test(s.trimEnd())) continue; // an offer of the road, never a report about it
+    for (const p of CLAIM_PATTERNS) {
+      const m = p.re.exec(s);
+      if (m === null) continue;
+      const before = s.slice(0, m.index);
+      if (MODAL_BEFORE.test(before) || MODAL_IN_SPAN.test(m[0])) continue; // a plan or a rule, not a report
+      if (NEGATION_BEFORE.test(before) || NEGATION_IN_SPAN.test(m[0])) continue; // an admission, not a claim
+      if (p === PENDING_PATTERN && PRIOR_ROW_REFERENCE.test(s)) continue; // a status report about an older row
+      if (p === VERB_FIRST_PATTERN && !ACK_BEFORE.test(before)) continue; // a modifier on a stated fact
+      claims.push({
+        shape: p.shape,
+        // 🔴 THE PENDING SHAPE MAY NOT NAME A KIND — see {@link claimSubject}. Its subject is a
+        // PRONOUN, so the thing pending lives in another sentence this module cannot resolve.
+        subject: claimSubject(s, before, m[0], p !== PENDING_PATTERN),
+        sentence: i,
+        namesCard: CARD_NOUN.test(m[0]),
+      });
+      break; // one claim per sentence — the strike is by sentence, so a second shape adds nothing
+    }
+  }
+  // 🔴 A KIND-LESS CLAIM INHERITS FROM ANOTHER CLAIM SENTENCE, AND FROM NOTHING ELSE. Ship #228's
+  // second sentence carries no access word, and it is half of the same fabricated access claim as
+  // the first. Reading a `generic` claim as its own subject would hand it to the card signal.
+  // Promotion runs from CLAIM sentences only, which is what keeps a host-voiced note out of the
+  // decision — the whole of OPE-2034.
+  if (!claims.some((c) => c.subject === "access")) return claims;
+  return claims.map((c) => (c.subject === "generic" ? { ...c, subject: "access" as const } : c));
+}
+
+/**
+ * What ONE claim is about, read from the claim itself and then from its sentence.
+ *
+ * THE ORDER IS THE POLICY, and each step gives up something to the step before it:
+ *   1. ACCESS VOCABULARY IN THE CLAIM'S OWN SPAN WINS OUTRIGHT. "submitted the channel-scope access
+ *      request" is an access claim whatever else the sentence goes on to name, which is what keeps a
+ *      kind phrase hung off the end of a fabrication from making it unstrikeable.
+ *   2. A KIND QUALIFYING THE CLAIM'S OWN NOUN makes it that kind's claim — inside the span, or
+ *      anchored immediately in front of it. The measured routine ack takes this step, and its
+ *      sentence carries `permission`, which is why the step sits above the sentence-wide test.
+ *   3. ACCESS VOCABULARY ELSEWHERE IN THE SENTENCE, for the claims that name their subject beside
+ *      the verb rather than on the noun.
+ *   4. Otherwise the claim names no kind at all.
+ *
+ * 🔴 `kindMayQualify` IS FALSE FOR THE PENDING SHAPE, and review measured why. That shape has no
+ * propose noun of its own — it anchors on a PRONOUN — so the thing said to be pending lives in
+ * another sentence, and a kind word beside its `approval` may belong to that other sentence or be a
+ * plain adjective. "I've submitted the channel-scope request to widen `e2e-fixture`. It's pending
+ * routine approval." is the measured fabrication with two words added, and reading the second
+ * sentence as a routine's card would post it under the host's own denial of the first. So the
+ * pending shape falls to `generic`, where step 3 and the reply-wide inheritance can reach it. The
+ * cost: a true "it's pending routine approval", alone in a reply, is struck when the host saw no
+ * card.
+ */
+function claimSubject(sentence: string, before: string, span: string, kindMayQualify: boolean): RequestClaimSubject {
+  if (ACCESS_SUBJECT.test(span)) return "access";
+  if (kindMayQualify && (OTHER_APPROVAL_KIND.test(span) || KIND_QUALIFIER_BEFORE.test(before))) return "other-approval";
+  return ACCESS_SUBJECT.test(sentence) ? "access" : "generic";
+}
+
+/** What the guard did to one reply. */
+export interface RequestClaimGuardResult {
+  /** The body to post. BYTE-IDENTICAL to the input whenever nothing was struck and the input carried
+   *  no earlier copy of {@link WITHHELD_REQUEST_CLAIM_NOTE} — which is every ordinary reply. */
+  readonly body: string;
+  /** The claims struck, empty when the reply kept its text. */
+  readonly withheld: readonly RequestClaim[];
+}
+
+/** What the HOST observed this turn, which is the whole of the strike decision.
+ *
+ *  ONE value carries both signals, for the reason `applyMemoryClaimGuard`'s single boolean carries
+ *  its own: a caller cannot then get the policy half right and the evidence half wrong. */
+export interface RequestClaimEvidence {
+  /** Did an ACCESS-REQUEST propose really run on this turn — `channels/access-request-ledger.ts`. */
+  readonly proposed: boolean;
+  /** Did the host see an approval card minted in this session — `approvals/card-signal.ts`. It backs
+   *  a KIND-LESS claim and never an access claim; the header states why, and states the residual. */
+  readonly cardMinted: boolean;
+}
+
+/**
+ * Is one claim struck, given what the host observed?
+ *
+ * 🔴 EACH SUBJECT TAKES ITS OWN EVIDENCE, and mixing them is the fail-open this module exists to
+ * refuse. An `other-approval` claim is another plane's, so this module neither backs it nor strikes
+ * it. An `access` claim takes the turn ledger and nothing else. A `generic` claim names no kind, so
+ * a card the host saw minted is evidence of the same grain — but ONLY for a claim whose own noun is
+ * a CARD. "I've submitted the request", on a turn that minted a card for something else entirely, is
+ * still a claim nothing here backs, and review measured that it is the leg-016 shape with the access
+ * words taken out.
+ */
+function strikesClaim(claim: RequestClaim, evidence: RequestClaimEvidence): boolean {
+  if (claim.subject === "other-approval") return false;
+  if (claim.subject === "access") return !evidence.proposed;
+  return !evidence.proposed && !(evidence.cardMinted && claim.namesCard);
+}
+
+/**
+ * Strike every unbacked propose claim from one reply — PURE, given the evidence verdict.
+ *
+ * The note replaces the struck sentences ONCE, however many there were: a reply that made the same
+ * claim three ways is one unbacked claim to a reader, and three copies of the note would read as a
+ * rendering fault.
+ */
+export function applyRequestClaimGuard(text: string, evidence: RequestClaimEvidence): RequestClaimGuardResult {
+  // 🔴 STRIP ANY EXISTING NOTE FIRST, ON BOTH ARMS. The note is host-voiced and this function runs on
+  // the edit door too, so a model echoing a previously posted body back through `edit_reply` would
+  // otherwise accumulate one copy per edit — the same idempotency `memory-claim-guard.ts` keeps for
+  // its own note. Stripping before the backed check is what lets a later turn that DID propose take
+  // the note back off.
+  const hadNote = text.includes(WITHHELD_REQUEST_CLAIM_NOTE);
+  const bare = hadNote ? text.split(WITHHELD_REQUEST_CLAIM_NOTE).join("").trimEnd() : text;
+  const claims = detectRequestClaims(bare);
+  const withheld = claims.filter((c) => strikesClaim(c, evidence));
+  // Nothing to strike. A body that already carries the note is a re-post or an edit of a reply this
+  // guard already handled: the note is re-attached while the world has not changed, and taken back
+  // off once the host can back what it struck. Nothing is audited a second time — the withheld list
+  // is what the row counts, and this round withheld nothing.
+  //
+  // 🔴 A CLAIM THAT SURVIVED ON THE CARD SIGNAL TAKES THE NOTE OFF TOO, and review measured why. The
+  // note is a denial; leaving it under a sentence this round deliberately let stand posts the host's
+  // own denial beside a live claim, which is the ship #216 shape `applyApprovalClaimGuard` exists to
+  // refuse. An `other-approval` claim is not that shape: the note denies an ACCESS request, and that
+  // sentence never claimed one.
+  if (withheld.length === 0) {
+    const backed = evidence.proposed || claims.some((c) => c.subject === "generic");
+    return { body: hadNote && !backed ? `${bare}\n\n${WITHHELD_REQUEST_CLAIM_NOTE}` : bare, withheld: [] };
+  }
+  const struck = new Set(withheld.map((c) => c.sentence));
+  const sentences = replySentences(bare);
+  const kept = sentences.filter((_, i) => !struck.has(i)).map((s) => s.text);
+  const body = `${kept.join("").trimEnd()}\n\n${WITHHELD_REQUEST_CLAIM_NOTE}`.trimStart();
+  return { body, withheld };
+}
+
+/**
+ * Write the durable row for one withheld claim — best-effort, never throws, never fails the reply.
+ *
+ * 🔴 THE ROW NAMES THE CLAIM BY SHAPE, SUBJECT AND POSITION, NEVER BY TEXT. The struck sentence is
+ * model output that can quote ingested content, and this plane's rows carry ids and counts only. A
+ * reader who needs the sentence has the posted body, where the note says one was struck.
+ */
+export async function auditWithheldRequestClaim(
+  audit: ReplyAudit | undefined,
+  platform: string,
+  withheld: readonly RequestClaim[],
+): Promise<void> {
+  if (!audit || withheld.length === 0) return;
+  await appendAudit({
+    org: audit.org,
+    platform,
+    workspace: audit.workspace,
+    surface: audit.surface,
+    principalId: audit.principalId,
+    action: REQUEST_CLAIM_WITHHELD_ACTION,
+    detail: {
+      claims: withheld.length,
+      shapes: [...new Set(withheld.map((c) => c.shape))],
+      subjects: [...new Set(withheld.map((c) => c.subject))],
+      sentences: withheld.map((c) => c.sentence),
+      ...(audit.wakeId ? { wakeId: audit.wakeId } : {}),
+      ...(audit.sessionId ? { sessionId: audit.sessionId } : {}),
+      ...(audit.turnId ? { turnId: audit.turnId } : {}),
+    },
+  }).catch(() => undefined);
+}
+
+/**
+ * The whole per-reply step, in one call every choke point makes: read what the host observed the
+ * propose plane do this turn, strike what it cannot back, and hand back the body plus the claims to
+ * audit.
+ *
+ * ONE function because the four reply doors DRIFTED before over exactly this kind of shared step
+ * (`reply-provenance.ts` `applyReplyProvenance` says the same of itself): a door that struck a
+ * fabricated claim and a door that posted it would make the guard look like a rendering glitch.
+ * `scripts/request-claim-guard-test.ts` scans the doors for this call.
+ */
+export function guardRequestClaims(text: string, audit: ReplyAudit | undefined): RequestClaimGuardResult {
+  return applyRequestClaimGuard(text, {
+    proposed: accessRequestsProposedThisTurn(audit?.turnId).length > 0,
+    cardMinted: peekCardPostedThisTurn(),
+  });
+}

package/agent/channels/runtime-code-fingerprint.generated.ts

@@ -0,0 +1,10 @@
+// GENERATED FILE — DO NOT EDIT, AND DO NOT COMMIT (it is gitignored).
+// Written by packages/core/scripts/runtime-code-fingerprint-generate.ts, which npm runs as `prebuild:packages`.
+// Read by packages/core/agent/channels/runtime-rotation.ts: when this value differs from the one a
+// standing seat was last served with, the code under that seat changed and its generation retires.
+
+// It is meaningful ONLY in a tree that runs this generator: a consumer installing
+// @open-everywhere/core from a registry gets the value baked at PUBLISH time, and its own
+// agent/ edits move no fingerprint. The scaffolder clones this monorepo for that reason.
+
+export const RUNTIME_CODE_FINGERPRINT_SOURCE = "f1e4a2a375f6371b";