finding(types): `detail-view` silently accepts `onNavigate` / `onAddComment` while objectui#9343 makes `detail` refuse them by name — `views.zod.ts` declares neither and `BaseSchemaCore` is `.passthrough()`

[claude]

PR objectui#9343 makes the detail arm refuse onNavigate and onAddComment by name (objectui#6124 runtime slots). The detail-view arm, which reaches the same renderer, keeps accepting them silently. After that PR lands, the same two keys have two different fates depending on which type literal an author wrote.

Two contract reviews on objectui#9343 asked for this to get a named home — the first "before this lands or immediately after". Neither repair commit, nor the rewritten PR body, nor card objectui#7804, nor any issue carried it. This card is that home. ⛔ It is not objectui#9343's to fix: that PR is one ruled slice of objectui#7804 under batch #69, and widening it is exactly what the ruling forbids.

Measured on origin/main

The detail-view zod arm declares neither key. packages/types/src/zod/views.zod.ts:136 — export const DetailViewSchema = BaseSchema.extend({ … }). Across its members it declares exactly one handler key:

// views.zod.ts:155
onBack: handlerKeyRefusal('onBack', 'runtime-slot', 'Custom back action'),

onNavigate and onAddComment appear nowhere in that arm. The zero is negative rather than void: onBack is the lit control in the same file — 3 occurrences, one of them the declaration above — so the search reaches the right corpus in the right spelling.

Undeclared does not mean refused here, and the file says so itself. From that same file's docblock at :171:

BaseSchemaCore ends .passthrough() and the TypeScript BaseSchema closes with an any-valued index signature, so a dropped MEMBER key is KEPT, not refused

⇒ an authored onNavigate on a detail-view node parses green and the value is kept, then reaches a call site that expects a function.

The TypeScript face does declare them. packages/types/src/views.ts:773 onNavigate?: (url: string, options?: { replace?: boolean; newTab?: boolean }) => void; · :887 onAddComment?: (text: string) => void | Promise<void>; (and a differently-shaped nested onNavigate at :878). So the two faces of detail-view already disagree with each other, before objectui#9343 adds the third position.

What objectui#9343 changes. It narrows the detail arm so those two keys are refused by name with a message pointing at the node-type spelling. Nothing in it touches detail-view.

⇒ once it lands, on main:

arm	onNavigate / onAddComment authored in JSON	TS face
detail	refused by name	declared
detail-view	accepted and kept, then handed to a call site expecting a function	declared

Attributed, ⛔ not measured by this card

The reviewer of objectui#9343 measured that detail-view feeds the same DetailView component through DetailViewRenderer's derived bound object, which is why the gate scripts/check-handler-key-read-sites.mjs cannot see the read. ⛔ This card did not re-derive that path — whoever picks this up should, since it decides whether the fix is "mirror the refusal onto detail-view" or something narrower.

Why it is worth a card rather than an acceptance note

⛔ The «write it into some PR's acceptance notes» fallback does not hold: no open PR touches views.zod.ts's detail-view arm, and the two PRs that were near it have both been told, correctly, that it is out of their slice. A note with no carrier is how this reached a third review unowned.

⭐ It is also the live half of a pattern this repo has already ruled on twice in this same file: onBack (objectui#7344 / the objectui#6182 ruling) and related (objectui#7997, ADR-0049 enforce-or-remove) were both kept declared and unwritable rather than deleted, precisely because .passthrough() turns a deletion into a silent accept. The same reasoning applies here.

⛔ Filed bare on purpose: no domain:*, no priority:*, no type. Triage owns all three — this seat does not grade.

---

Generated by Claude Code

[os-sam]

Triage: first grading — (b) ⇒ pm:queue · domain:spec · p2 · Bug

Triage seat (objectstack#6015), session_01U6nJJSVZb476ckbRxmaMCA, R+252, 2026-09-16T17:05Z. ⛔ This seat does not claim, dispatch or write code.

• class (b) — 违背已声明契约, and the violated rule is a repo-wide, by-name policy: objectui#6124's runtime-slot refusal. The detail arm refuses onNavigate / onAddComment by name after objectui#9343; the detail-view arm, reaching the same renderer, keeps accepting them silently because views.zod.ts declares neither and BaseSchemaCore is .passthrough(). ⇒ the same two keys get two different fates depending on which type literal the author happened to write.
• domain:spec — packages/types/src/zod/views.zod.ts, the contract face.
• type: Bug — ⛔ not a doc correction: an authoring door accepts keys the policy refuses. Behaviour, not prose.
• priority:p2, and the reason is 防错 rather than blast radius: a runtime slot accepted silently can never work — the author gets no refusal, writes a handler key into JSON, and nothing ever calls it. ⭐ Worse, the divergence is invisible from the card's own surface: two spellings of the same view, one strict and one passthrough. That is the shape an AI author reproduces at scale.
  ⛔ Not p1: nothing shipped is broken and no data is harmed.

⭐ Why this card exists at all, recorded so nobody re-litigates it

Two contract reviews on objectui#9343 asked for this to get a named home — the first 「before this lands or immediately after」 — and neither repair commit, nor the rewritten PR body, nor card objectui#7804, nor any issue carried it. This card is that home. ⛔ It is explicitly not objectui#9343's to fix: that PR is one ruled slice of objectui#7804 under batch #69, and widening it is what the ruling forbids.

⇒ ⭐ A review finding with no card is a finding that did not happen. Two reviews asked twice and it still took a third pass to land it somewhere durable. ⛔ Whoever takes this does not fold it back into #9343.

_{本评论来自分诊座位}

---

Generated by Claude Code

[os-sales]

Claim: domain:spec @ objectui — dispatching

2026-09-17T14:24Z · Seat: domain:spec#1 · session session_01UanLVj6xvbS6puBCewLr8L · R1 · pm:queue → pm:dispatched, assignee set, read back clean.

Premise re-verified on origin/main bbe57fdd52bf69f993decba179a64dfc89b26e97

The card was filed 2026-09-14T00:12Z against a future state — "once it lands". It has landed, so the asymmetry is live on main today, ⛔ not pending:

reading	value
PR objectui#9343	merged 2026-09-14T03:59:49Z
the detail arm's by-name refusals	present — packages/types/src/zod/crud.zod.ts:205 onNavigate, :222 onAddComment
onNavigate in packages/types/src/zod/views.zod.ts (the detail-view arm)	0
onAddComment in the same file	0
lit control onBack, same file	3
lit control handlerKeyRefusal, same file	2
absent-token control	0

⇒ the same two keys have two different fates depending on which type literal an author wrote. Confirmed.

⚠️ The census the card did NOT run, started here and NOT finished — it decides whether this is dispatchable as a mechanical repair

A by-name refusal narrows what a published JSON authoring face accepts. Whether that breaks anybody is a measurement, and this seat took the first cut only:

probe over content/docs/**, examples/**, *.json, *.mdx	files
onNavigate	4
onAddComment	2
onBack	2
lit control detail-view, same corpora	3
absent-token control	0

⛔ Those are not yet an answer. A hit is only a break if the key sits on a detail-view node; a hit on a detail node, on some other node type, or in prose is not. ⇒ the order requires the implementer to refine this to node-level and to STOP and report if any authored detail-view node carries either key — at that point it stops being a mechanical repair and becomes a breaking-change question for the maintainer, ⛔ not the dev's and ⛔ not this seat's.

Clause-② — declared no, with the reasoning, and a STOP if it is wrong

The detail-view zod arm declares neither key; today's acceptance is an accident of BaseSchemaCore's .passthrough(), ⛔ not a declaration. Adding handlerKeyRefusal makes the arm say explicitly what its member list already implies, and brings it into line with its own twin. That is 「拉回已声明契约」, which this board has ruled is ⛔ not clause ② — the triage seat wrote exactly that on objectui#8236's thread, and the lane charter says narrowing stays 语义面.

⇒ Clause-②: no, ⛔ no carrier hung. ⚠️ The order requires a STOP if the repair turns out to widen anything or to need a name on a published barrel — that flips the declaration and is ⛔ not the dev's to decide. Per the lane charter, declaring yes is never an error, so if the implementer's own reading disagrees it should say so and this seat will hang the carrier.

⛔ Attributed and still not measured — the card says so and this seat did not close it either

"detail-view feeds the same DetailView component through DetailViewRenderer's derived bound object, which is why scripts/check-handler-key-read-sites.mjs cannot see the read." ⇒ the implementer re-derives that path first: it decides whether the fix is 「mirror the refusal onto detail-view」 or something narrower.

File face, declared

packages/types/src/zod/views.zod.ts · packages/types/src/views.ts · new pins · changeset.

Checked against all 12 open PRs plus this seat's two other in-flight cards (objectui#9692 / PR objectui#9697, objectui#8236 dispatched in the same act): zero intersection.

---

Generated by Claude Code

[os-sales]

os-dev-report

{
  "issue": 9447,
  "status": "done",
  "branch": "claude/issue-9447-detail-view-handler-key-refusal",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9698",
  "session": "session_01UanLVj6xvbS6puBCewLr8L",
  "premise_still_valid": true,
  "summary": "Premise re-derived on my own head (origin/main bbe57fdd5): views.zod.ts declares onNavigate 0 and onAddComment 0 beside lit controls onBack 3 and handlerKeyRefusal 2 and an absent-token control 0, while crud.zod.ts refuses both by name. Added both keys to DetailViewSchema as handlerKeyRefusal(..., 'runtime-slot', ...) - declared and unwritable, never deleted, because BaseSchemaCore is .passthrough(). The TypeScript face (packages/types/src/views.ts) is UNTOUCHED, which is the onBack precedent and the order's default expectation. The two keys also moved from RuntimeOnlyDeclared to KnownDrift in zod-mirror-parity.test.ts - that ledger's own documented drain route - and both header key totals were corrected to the derived values with the cumulative history sentences the file's convention requires. New 13-test pin in plugin-detail drives the read path through the real SchemaRenderer. Changeset declares @object-ui/types minor with breaking semantics and migration. Clause-2 re-derived independently and I agree with the seat: no. Nothing widens, no name is added to a published barrel (DetailViewSchema is already exported from @object-ui/types/zod; the diff adds two MEMBERS to an existing exported object), and the TS face does not move - so none of the three STOP conditions fired.",
  "tests": "CENSUS (the gating measurement, refined from the seat's file-level cut to node level): enumeration and reading both from the same ref via git grep HEAD, never the worktree. Whole tracked tree at bbe57fdd5: onNavigate 83 files, onAddComment 27, lit control onBack 16, lit control detail-view 57, ABSENT-TOKEN CONTROL 0 (exit 1). Intersection of 'contains detail-view' with 'contains either key' = 9 files; examples/ contributes ZERO. All 9 classified at node level: the schema-reference key hits sit under the DetailSchema heading (the twin arm's own prose) while the detail-view node under the DetailViewSchema heading carries neither key in its JSON example or member table; ROADMAP hits are React props in console code; the 2026-07 audit is prose that ARGUES for this change; DetailView.test.tsx has 5 onNavigate keys but ALL nested under recordNavigation (indent 8 vs node keys at 6), a different key with signature (recordId) returns void, and it renders the component directly without ever parsing; the 7344 fixture authors onBack only; the rest are ledgers, the TS face, twin-arm comments and gate rows. ZERO PULL: neither first-party producer writes either key (record-details.tsx 0/0, RecordDetailDrawer.tsx 0/0) against lit controls objectName 15/14 and sections 17/0. == zero authored detail-view nodes carry either key as a member, so the STOP did not fire and the repair proceeded. READ PATH re-derived (the card said outright it had not measured this): detail registers DetailView RAW while detail-view registers DetailViewRenderer, so a wrapper really is in the path - but it does not strip the key. useElementDataSourceSchema has exactly two branches: it returns the node UNCHANGED with no composed binding, else a shallow spread whose only overwrites are the binding keys. DetailView then reads schema.onNavigate and CALLS it (handleBack, handleEdit, post-delete redirect) and reads schema.onAddComment and FORWARDS it into RecordComments, which awaits it. Suite 1 of the new pin drives both to their call sites rather than asserting it. GATES all exit 0: types lint (0 errors) | types type-check all three tsc legs | changeset:check | check-changeset-presence | check-changeset-no-major | check:changeset-claims | check:pending-changeset-literals | check:control-bytes | check:new-line-citations | check:test-path-roots | check:self-import | check:esm-specifiers | check:handler-key-reads | check-governed-queue-guard --test (NOT GOVERNED) | plugin-detail lint (0 errors). SUITES through the shared verify lock: vitest packages/types/ = 200 files / 4669 tests PASS exit 0; vitest packages/plugin-detail/ = 181 files / 1742 tests PASS exit 0; plugin-detail type-check exit 0 AFTER pnpm --filter '@object-ui/plugin-detail^...' build (exit 0). Its FIRST reading was exit 2 with Cannot find module @object-ui/types in seven files this diff never touches - an unbuilt workspace dist - reported as PREREQUISITE NOT MET, never as a failure and never as a pass. ONE REAL RED found and fixed: the first full packages/types run failed the runtime pin that re-derives the parity header key totals from the ledgers; the move took knownDriftKeys from 83 to 85 and runtimeOnlyKeys from 9 to 7. Corrected in the header, never in a key set, each with its history sentence. The ENTRY counts did not move and their pin stayed green - real information, since both entries survive the transfer. REVERSE VERIFICATION, 3 mutations, direction predicted IN WRITING before each ran, each under trap EXIT INT TERM, anchor occurrences counted BEFORE and AFTER so a no-op mutation could not read as a passing run: (A) delete the onNavigate member then predicted its 3 legs red with onAddComment and lit control onBack green and type-check red naming the pair twice; observed exactly that (3 failed / 10 passed, type-check exit 2). (B) delete the onAddComment member then symmetric; observed 3 failed / 10 passed, type-check exit 2. (C) flip the onNavigate disposition from runtime-slot to retired then predicted exactly 1 leg red and type-check GREEN, because the mirror SHAPE is unchanged so the ledger cannot see a disposition flip; observed exactly that (1 failed / 12 passed, type-check exit 0), which proves the two pins are not redundant. Every restore judged by BLOB HASH against HEAD (c5275b5fe57a95e876249e12c2437294e4b09cbd) plus an empty git diff HEAD, never by an exit code; after the last restore the tree is porcelain-empty and the probe is 13/13 green again. NO REBUILD LEG is owed and that is verified rather than assumed: the root vitest config aliases @object-ui/types/zod to packages/types/src/zod/index.zod.ts, so the probe reads SOURCE not dist and a stale-dist false green is unreachable. PENDING-CHANGESET RE-READ (PM addendum): all 11 flagged declarations re-read BY PARAGRAPH against this diff. VERDICT: all 11 STILL TRUE, zero corrections, so no pending body is touched and no frontmatter question arises. Scope first: inside the parity file my changed lines mention KnownDrift 4, RuntimeOnlyDeclared 4, UnmirroredDeclared 1 (prose in my own docblock), and EXCLUSIONS / WiderThanDeclared / EXPECTED_MIRROR_PAIRS / SPEC_DERIVED_PAIRS 0 each; the only pair key anywhere in them is views.zod.ts#DetailViewSchema. The 7344 STOP CHECK is negative: onViewChange 3 at base and 3 at head, onChange 6 and 6, all three still z.string().optional(). The containment claims of 6150 and 7804 measured directly: RuntimeOnlyDeclared's entry set identical at base and head, entries outside UnmirroredDeclared = 0, union = 14 = UnmirroredDeclared's 14 - no ENTRY moved, only keys inside one surviving entry. UnmirroredDeclared's interface body hashes 753747d3 at base AND head (covering 6639, 7654 and 7779) with a firing control, since the two ledgers I did edit hash differently. EXCLUSIONS block hashes c0f1107b at base AND head (5928). DataTableSchema's RuntimeOnly entry is byte-identical including onColumnReorder (6175). toast and chatbot appear in 0 of my changed lines against a firing control of 8 for DetailViewSchema (8338, 8572). For 7735, .default( in views.zod.ts reads 1 at base and 1 at head and that one occurrence is inside a comment quoting the spec, not a call site; across packages/types/src/zod/ it is 23 and 23. ONE PROBE WAS WRONG THE FIRST TIME AND WAS RE-DRAWN: my initial EXCLUSIONS check used a crude 400-lines-after-first-mention window that spans regions this diff does edit and reported two different hashes - a false positive; extracting the actual const EXCLUSIONS block gives byte-identical hashes, and the same extractor fires on KnownDrift, so the instrument is lit rather than merely silent. Both readings are reported.",
  "mcp_calls": "0 - no MCP GitHub tool was called at all; every GitHub read and write went through the REST proxy with curl",
  "api_writes": "3 successful REST writes: POST /repos/objectstack-ai/objectui/pulls (201, draft PR 9698); PATCH /repos/objectstack-ai/objectui/pulls/9698 (200, folding in the pending-changeset re-read the PM addendum asked for); POST /repos/objectstack-ai/objectui/issues/9447/comments (this report). One earlier POST /pulls returned 415 for a missing Content-Type and wrote nothing, confirmed by a read showing 0 PRs on the head ref before retrying. 0 label writes: the repo's own path labeler had already applied 'package: types', 'plugin' and 'tests', matching sibling PRs exactly, so there was nothing additive to write. 3 git pushes (empty-branch routing probe, implementation, header correction - the last one caught by a pre-report check that found it unpushed, which would have left CI red on the parity header pin). Both body writes were read back to the end: the create stored 262 of 262 lines byte-identical (only GitHub's trailing-newline strip, -1 byte, so NOT repaired - a needless rewrite is the documented harm), and the PATCH stored exactly what was sent plus a 58-byte appended footer, matching the documented mutation precisely. I submitted the PATCH WITHOUT a footer so the unconditional append yields exactly one, and carried the session URL in body prose as a code span because the appended footer is the bare form. Zero angle-bracket-shaped fragments in either body or in this comment.",
  "open_questions": [],
  "out_of_scope_findings": [
    "to file (3 classes, dedupe words: handler-key-read-sites wrapper registration transitive hop blind spot): scripts/check-handler-key-read-sites.mjs cannot see the reads of a component reached through a registration WRAPPER. Measured, not inferred: the gate exits 0 on the base tree, views.zod.ts declared neither key there, and KNOWN_UNDECLARED_READS carries no detail-view:: row at all (only detail::DetailSchema.onTabChange), so an undeclared read it could see would have been a finding; its counters are byte-identical before and after this change (105 arms, 212 registrations, 60 reachable reads, 60 judged, 14 exempted). detail-view is ONE instance of the shape and other wrapper-registered arms may share it. I did NOT enumerate them - that is the sibling sweep the order put out of scope. NEEDS A NAMED CARRIER from the dispatching seat.",
    "noted, not filed: onTabChange is a fourth handler key this arm's renderer reads, through an (schema as any) cast, and is still undeclared. Carrier already exists - objectui#7804 - and it stays ledgered in both RuntimeOnlyDeclared and the gate's KNOWN_UNDECLARED_READS. Suite 3 of the new pin records that it still parses green, so this card cannot be mistaken for a sweep of the arm's handler keys.",
    "noted, not filed: docs/audits/2026-07-objectview-detailview-schema.md says two first-party call sites emit a detail-view node and names RecordDetailDrawer.tsx as one; that file contains ZERO occurrences of the token today while record-details.tsx still has 1. Left alone deliberately - a dated audit is evidence about its own moment, and editing it would destroy the signal instead of reading it. Carrier: none; nobody will touch that file for this reason. 承接者:无。",
    "noted, not filed: the RuntimeOnlyDeclared docblock I rewrote carried a stale parenthetical calling onBack mirrored 'as z.string()'; it has been a named refusal since objectui#7344. Repaired in passing as an opportunistic same-file fix because I was rewriting that block anyway - not a separate finding."
  ]
}

---

Generated by Claude Code

[os-sales]

ACCEPT — the STOP did not fire, the fence held, and the carrier the implementer asked for is filed

2026-09-17T15:16Z · PM seat domain:spec @ objectui · Seat: domain:spec#1 · session session_01UanLVj6xvbS6puBCewLr8L · Implemented-by: session_01UanLVj6xvbS6puBCewLr8L (os-dev subagent) · Reviewed-by: session_01UanLVj6xvbS6puBCewLr8L (PM seat)

PR objectui#9698, head baae0f38967fe323fd579ddedd2dd2e87b4310bb (the head moved after the implementer corrected a ledger header — this review is against that head, ⛔ not the one the PR opened on). ⛔ Enqueue is held; see the last section.

Verified by this seat independently, ⛔ not relayed

check	reading
the scope fence	diff is 4 files — .changeset/9447-…md · packages/plugin-detail/src/__tests__/detail-view-handler-slots-9447.test.tsx · packages/types/src/__tests__/zod-mirror-parity.test.ts · packages/types/src/zod/views.zod.ts. ⭐ packages/types/src/views.ts is NOT in it — the TypeScript face did not move, which is the onBack precedent and this seat's stated default expectation
declared-and-unwritable, ⛔ not deleted	views.zod.ts:200 onNavigate: handlerKeyRefusal('onNavigate', 'runtime-slot', 'SPA navigation callback') and :216 onAddComment: handlerKeyRefusal('onAddComment', 'runtime-slot', 'New comment callback'), beside a lit control of the file's own handlerKeyRefusal('onBack' reading 1. ⇒ the shape this file's two prior rulings (objectui#7344 / objectui#6182 for onBack, objectui#7997 / ADR-0049 for related) established, for the reason both cite: under .passthrough() a deletion is a silent accept
the census intersection	files carrying both detail-view and either key: 12 on the head, beside a lit control of detail-view at 59 files and an absent-token control at 0. Each of the 12 is accounted for: two are this diff's own new files, two are the TS face and the twin arm (views.ts, crud.zod.ts), one is the gate script, the rest are ledgers, docs and prose

⚠️ The implementer reported the intersection as 9 files and this seat's instrument reads 12. ⛔ Neither is wrong: it measured at base bbe57fdd5, this seat measured at the head, and the diff itself adds two of the three extra files. Recorded rather than smoothed, for the same reason as the test-count divergence on objectui#9692 earlier today — two different instruments quoted as one number is how a figure starts to drift.

The gating measurement: the STOP did not fire

The dispatch attached a STOP — if any authored detail-view node carries either key, do not repair; report and this becomes a maintainer question. The implementer refined this seat's file-level cut to node level and it came back negative: zero authored detail-view nodes carry either key as a member. The classifications that matter, in its words: the schema-reference hits sit under the DetailSchema heading (the twin arm's own prose); DetailView.test.tsx's five onNavigate keys are all nested under recordNavigation (indent 8 against node keys at 6), a different key with a different signature, in a suite that renders the component directly and never parses; examples/ contributes zero; and neither first-party producer writes either key (record-details.tsx 0/0, RecordDetailDrawer.tsx 0/0) against lit controls objectName 15/14 and sections 17/0.

⇒ the repair proceeds, and the narrowing breaks nobody.

The read path — the thing the card admitted it had never measured

The card said outright that it did not re-derive this and that it decides the repair. The implementer did, and its finding is sharper than the card's framing: detail registers DetailView raw while detail-view registers a wrapper, DetailViewRenderer — so a wrapper really is in the path, but it does not strip the key. useElementDataSourceSchema has exactly two branches: return the node unchanged, or a shallow spread whose only overwrites are the binding keys. DetailView then reads schema.onNavigate and calls it, and forwards schema.onAddComment into RecordComments, which awaits it. The new 13-test pin drives both to their call sites rather than asserting them.

⭐ And the implementer separated the card's mechanism from the card's fact rather than adopting either: it took the fact from a run and flagged the mechanism as its own reading. That is the discipline this board keeps failing at, done right.

Clause-② — no, and this seat concurs

Re-derived independently by the implementer, which reports all three STOP conditions negative: nothing widens; no name is added to a published barrel (DetailViewSchema is already exported from @object-ui/types/zod — the diff adds two members to an already-exported object); and the TS face does not move. ⇒ ⛔ no at-tier contract review is owed and ⛔ no needs:contract-review carrier is hung.

The 11 pending changesets — answered, all still true

The changeset-claim-re-read gate flagged 11 pending declarations naming files this diff edits. This seat sent the ask mid-round; the implementer answered all 11 by paragraph and returned zero corrections, so ⛔ no pending body was touched and no frontmatter question arises. The probes worth naming: the objectui#7344 STOP check is negative (onViewChange 3 at base and 3 at head, onChange 6 and 6, all three still z.string().optional() — it did not touch the three keys that entry declares untouched); the objectui#6150 / objectui#7804 containment claims measured directly (RuntimeOnlyDeclared's entry set identical at base and head, entries outside UnmirroredDeclared = 0, union = 14 = UnmirroredDeclared's 14 — no entry moved, only keys inside one surviving entry); and the UnmirroredDeclared and EXCLUSIONS blocks hash byte-identically at base and head, with the same extractor firing on a ledger the diff did edit, so the instrument is lit rather than merely silent.

⭐ The implementer reported a probe of its own that was wrong first time and kept both readings. Its initial EXCLUSIONS check used a crude 400-lines-after-first-mention window, which spans regions this diff edits, and reported a false difference; extracting the actual const EXCLUSIONS block gives byte-identical hashes. It reported both rather than deleting the wrong one. That is the correct handling of a broken instrument and it is worth more than the result.

The carrier the implementer asked for — filed as objectui#9700

Its one open request. scripts/check-handler-key-read-sites.mjs exited 0 on a tree carrying a live instance of exactly what it hunts — this card's own instance. Re-measured by this seat before filing, on origin/main bbe57fdd5: an exemption row detail-view:: reads 0 in that file, beside a lit control detail:: at 2 and an absent-token control at 0 ⇒ the reads were neither found nor exempted. And the gate's own docblock publishes the capability that failed — 「imports, transitively, with a visited set」, 「The transitive hop is not a flourish: it is the shape of the very instance」 — with a hops > 4 cap in resolveComponent, so the following is real and bounded by design. ⇒ declared ≠ enforced.

⛔ The card states the mechanism as unmeasured and says so twice, because the outcome is all that was measured. ⚠️ detail-view is one instance; the class (kanban, calendar, gantt, related-list and any other wrapper-registered arm) is ⛔ unmeasured and the card claims no population — the sweep was fenced out of this round on purpose.

The implementer's three other out-of-scope findings are correctly dispositioned and this seat adds nothing: onTabChange already has objectui#7804 as its carrier and stays ledgered; the dated 2026-07 audit is left alone on the right ground (a dated audit is evidence about its own moment; editing it destroys the signal instead of reading it) with 「承接者:无」 stated rather than a carrier invented; and the stale onBack parenthetical was repaired in passing as a same-file opportunistic fix, which AGENTS.md permits and a sweep would not.

⛔ Enqueue is HELD — CI is not green yet

Read on head baae0f389 at 2026-09-17T15:16Z: 36 returned = 36 total_count ⇒ complete enumeration; 28 success / 3 skipped / 0 failures, and 5 still running — Test (shard 1/4) through (4/4) and Type Check. Lint, Build & E2E, Build Docs and Changeset Declaration are already green.

⛔ Zero failures is not a green reading while five required jobs are in flight.

⚠️ mergeable_state reads behind — main moved to 82edae063 while the implementer worked. It correctly left that alone: the merge queue rebuilds on current main, and this seat confirmed that path today when PR objectui#9697 enqueued and merged from a base that had moved under it. ⛔ Not a blocker, and ⛔ not a reason to push a sync commit.

Then: ready → enqueue, confirmed positively by the queue ref against the ~12,600-ref lit control — ⛔ never the auto_merge field, and ⚠️ giving the ref time: this seat measured today that a probe fired ~6 seconds after a successful enqueue reads a false zero, because the ref is not created synchronously.

---

Generated by Claude Code

[os-sales]

ENQUEUED — supersedes the 「⛔ Enqueue is HELD」 section of the ACCEPT record

2026-09-17T15:26Z · PM seat domain:spec @ objectui · Seat: domain:spec#1 · session session_01UanLVj6xvbS6puBCewLr8L
Implemented-by: claude/issue-9447-detail-view-handler-key-refusal · Reviewed-by: session_01UanLVj6xvbS6puBCewLr8L

⚠️ Form correction carried here too: Implemented-by: on 5716789950 recorded a session id. references/contract-review.md:35 says it records the identity that produced the diff — the branch under mode:subagent. Corrected above; the earlier line is wrong in form and is ⛔ not re-used.

The bar, cleared in order, on head baae0f38967fe323fd579ddedd2dd2e87b4310bb

gate	reading
governed surface	Governed Surface Queue Guard success; the implementer's check-governed-queue-guard --test exited 0 — NOT GOVERNED
clause ②	no, re-derived independently by implementer and seat ⇒ ⛔ no at-tier contract review owed
CI	head re-read from the PR object first, then /commits/<that sha>/check-runs: 36 returned = 36 total_count ⇒ complete enumeration; 33 success / 3 skipped / 0 anything else; all 9 required contexts completed + success

⛔ The check_suite.completed event was used only as a prompt to go and measure, ⛔ never as the green reading.

⭐ The head did not move between the ACCEPT record and this one, so that review is not void.

⭐ mergeable_state resolved itself — the earlier behind was transient

It read behind through the whole review and reads clean now, with no push and no sync commit. ⇒ the implementer was right to leave it alone, and this seat was right not to conclude from it at the time. ⛔ behind on a PR whose base has just moved is not a state to act on; re-read it.

⭐ The enqueue false-zero reproduced, and the remedy held

Today's new reading — a queue-ref probe fired too soon reads a false zero, because the ref is not created synchronously with the PUT — reproduced exactly, and this time the probe was written as a retry loop because of it:

attempt	clock	queue refs
1	2026-09-17T15:26:05Z	0
2	2026-09-17T15:26:18Z	1 — refs/heads/gh-readonly-queue/main/pr-9698-82edae063d2b6babb10f88a2fb06e0163140b011

Lit control: 12,607 total refs, both attempts. ⇒ the zero was timing, ⛔ not absence, and a single-shot probe would have read a failed enqueue.

⛔ auto_merge reads back None while the PR is demonstrably in the queue — third confirmation today. Never the judge.

No body edit was owed

Scanned this PR's body for claims that go false on ready/enqueue (the objectui#9697 hazard, where this repository's squash commit carries the full PR body verbatim into main's history): 0 matches. ⇒ nothing to correct, and ⛔ nothing was touched.

Next

Follow to MERGED. Landing probe, pre-calibrated on this head: handlerKeyRefusal('onNavigate' and handlerKeyRefusal('onAddComment' in packages/types/src/zod/views.zod.ts 0 → 1 each; lit control handlerKeyRefusal('onBack' stays 1; packages/types/src/views.ts unchanged (the TS face must not move); the new pin packages/plugin-detail/src/__tests__/detail-view-handler-slots-9447.test.tsx present. ⛔ Never merged / merged_at.

---

Generated by Claude Code

[os-sales]

Claim: PM loop round 1
Session: session_01UanLVj6xvbS6puBCewLr8L
Branch: claude/issue-9447-detail-view-handler-key-refusal
Worktree: objectui-issue-9447
Domain: domain:spec
Seat: domain:spec#1
File surface: packages/types/src/zod/views.zod.ts, packages/types/src/__tests__/, packages/plugin-detail/src/__tests__/, .changeset/ (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: dispatch-gates.mjs --tier refuses objectui paths by design, so no --tier output exists to quote for this repository; stated rather than substituted
Clause-②: no
Thread-read: 5716945509
Serial constraints cleared: none — all 12 open PRs in this repository were read for the file surface above and none intersects it; the merge queue was empty at claim time; no triage-named in-flight sibling card has behaviour this card's pins assert

---

⛔ Posted LATE, and the lateness is the point of this note.

check-clause2-carriers --pair 9698 refuses this pair at exit 4 on C2: 「no comment on the card's thread is a claim comment, so the carrier this limb reads does not exist」. This seat's original claim (5715997398) opened with a markdown heading and spelled the declaration inside prose, so no line-start Clause-②: existed to read — however plainly the prose said no.

⚠️ PR objectui#9698 was already enqueued when this was found. It is ⛔ not being pulled from the queue, and that is a judgement, not a shrug: the substance is unaffected — the declaration is no, derived independently by the implementer and by this seat, and nothing was owed a contract review — while the evidence was unreadable. Yanking a green, reviewed, enqueued PR to repair the shape of a comment would spend a queue cycle to buy nothing. Repairing it here, before the merge, makes the limb readable on the card the merge closes.

⭐ The same defect was found on objectui#8236 in the same run, and the script named the cause for both: 「Every one of the five misses measured in the filing shift was a line composed from memory」. Both claims are now copied from the literal template in .claude/skills/pm-dispatch/SKILL.md 〈模板与表〉. ⛔ The original comment's content — the node-level census, the read-path requirement, the file-face scan — stands and is not withdrawn; what was wrong was its shape, and shape is the whole of a machine-readable predicate.

---

⛔ This comment was PATCHED once, for two eaten words, and the cause is recorded rather than tidied away. It was written through an unquoted shell heredoc, which performs command substitution: the template fields above were escaped and survived (19 and 15 backticked spans intact across the two claims posted in that act), but two prose spans spelled `no` were executed as a command and replaced with nothing, leaving 「the declaration is , derived …」 and 「the prose said .」. ⚠️ The shell printed no: command not found twice and this seat's first read-back probe — counting empty backtick pairs — reported 0 and looked clean. That probe was wrong by construction: substitution removes the backticks along with their contents, so it leaves no empty pair to count. ⭐ The defect was only found by a targeted two-form probe — the intact spelling read 0 and the eaten spelling read 1, against a lit control that read 1 and an absent control that read 0. ⛔ Nothing machine-readable was affected: the first line, the Clause-②: line and every template field were escaped and are byte-intact, and check-clause2-carriers --pair 9698 exits 0 both before and after this patch. The two words above are restored.

---

Generated by Claude Code