finding(plugin-form): the line-items parent id asserts `RecordContextValue.recordId` down to `string`, so a numeric primary key reaches `buildMasterDetailEditBatch` typed as something it is not

[os-tesla]

Found while landing objectui#9304 (the two whole-context assertions on useRecordContext()), in packages/plugin-form/src/LineItemsPanel.tsx. ⛔ Not claimed.

What was measured

objectui#9304's acceptance asked what the inner assertion on the parent id turns out to be once the whole-context assertion above it is gone — pure redundancy, or a real mismatch. Measured on that branch, with the outer assertion removed and the inner one deleted, pnpm --filter @object-ui/plugin-form run type-check:

src/LineItemsPanel.tsx(262,64): error TS2345: Argument of type 'string | number' is not assignable to parameter of type 'string'.
  Type 'number' is not assignable to type 'string'.

⇒ a real mismatch, not a redundancy. The assertion is now the only thing that makes the two declarations meet. objectui#9304 kept it deliberately and documented it at the site instead of repairing it, because every repair moves bytes on the wire and that card is type-side with no runtime effect.

The two declarations

• RecordContextValue.recordId (packages/react, src/context/RecordContext.tsx) is declared string | number | null | undefined.
• buildMasterDetailEditBatch (packages/plugin-form, src/masterDetailTx.ts) takes parentObject: string, parentId: string.

The panel computes its parent id as schema.parentId || schema.recordId || record?.recordId and asserts the third arm down to string | undefined. A host that mounts a record with a NUMERIC primary key — which RecordContextValue explicitly permits, and which DataSource.update accepts as string | number — therefore hands the helper a number where its own declaration says string. The value flows on into the batch op's id and into the child filter keyed by relationshipField.

Why it was not repaired there

Both candidate repairs change runtime bytes:

• Coerce — String(record.recordId). Changes the id this panel sends and the child filter value; on a numeric-id backend an equality filter against a stringified id is a different query.
• Widen — buildMasterDetailEditBatch(parentId: string | number). Zero runtime change and it removes the assertion entirely, but it is masterDetailTx's contract, shared with MasterDetailForm, and BatchOp (an alias of BatchTransactionOperation) has to be read first to confirm its id already admits both.

⇒ this wants a decision on which, not a drive-by inside another card's scope.

Dedup

Declared with its boundary. MCP search_issues answered with a rate-limit error for this session's identity, so the check ran over the repo-scoped REST open issues list, fully paginated — 449 open issues over five pages, page six empty — with objectui#9304 itself carried as a known-hit control, which came back lit. Keyword sweep over those titles: recordId, line items, master detail, parentId, string | number, plugin-form. Nearest neighbours are objectui#7209 (the SchemaRendererContext cast family) and objectui#6904 (ObjectForm visibleWhen assertions); neither is this. ⛔ No text query over CLOSED cards was possible this session, so a closed duplicate would not have been seen.

Related

objectui#9304 (where it was measured) · objectui#9197 (the retype that opened this family) · objectui#7483 (same defect class)

Filed by an os-dev seat while working objectui#9304, generated with Claude Code; session https://claude.ai/code/session_01UzHd6hDYatoDn17BuwKxnZ.

---

Generated by Claude Code

[os-tesla]

Ruling recorded — S: a record id is a string, as the protocol declares everywhere; objectui's wider declarations narrow to it at the injection boundary, and no String() coercion is sprinkled at call sites (director seat, decision batch #129 item 5, 2026-09-13)

Maintainer, verbatim (live PM chat, reply received 2026-09-13T07:0xZ), to decision batch #129 presented as 1A·2(2)·3A·4(1)·5S: 「你是项目总监，9306 这种为什么你不直接决策呢？而且不是说要以协议为准吗？还需要立卡问 spec 多次一举啊。这个也需要更新skills。其他同意。」 — 「其他同意」 covers this card.

Derived first from the long-term axis: the protocol declares record ids as z.string() on every door (packages/spec/src/api/protocol.zod.ts:1932 get, :2115 update, :2172 delete, and the batch operation); a consumer type may not be wider than the protocol. The two middle layers this card found (buildMasterDetailEditBatch(parentId: string), BatchTransactionOperation.id: string) are the ones that agree with the protocol; the two ends (RecordContextValue.recordId: string | number | …, DataSource.update(id: string | number)) are the ones out of line. ②③④ do not overturn ①.

What is ruled

1. RecordContextValue.recordId narrows to string | null | undefined. A host that mounts a record with a numeric primary key stringifies it where the record enters objectui (its adapter / the RecordContext provider boundary) — one place, typed.
2. DataSource.update's id: string | number is the same defect class on the adapter contract and narrows in the same card (⛔ no separate card); a BYO backend with numeric keys maps at its adapter boundary, which is where examples/byo-backend-console will show any residual in the type check.
3. The documented assertion objectui#9304 left in LineItemsPanel.tsx is removed once 1 lands — it was evidence, and the evidence is discharged.
4. Clause-②: no (narrowing to the protocol); changeset under the launch-window convention naming both narrowed declarations.

State

needs-user-decision → pm:queue; bug / domain:spec / priority:p3 kept; file face spans packages/react, packages/types, packages/plugin-form — declared in the claim comment.

---

Generated by Claude Code

[os-sam]

Claim: PM loop round 6
Session: session_01L5xpA5q533BgTTNADibEFt
Branch: claude/issue-9333-record-id-narrows-to-string
Worktree: objectui-issue-9333
Domain: domain:spec
File surface: packages/react/src/context/RecordContext.tsx · packages/types/src/data.ts · packages/plugin-form/src/ (LineItemsPanel.tsx, masterDetailTx.ts and their pins) · a changeset (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default tier — ⛔ NOT DERIVED, the instrument refuses for a sister repo (see objectui#9088 comment 5662564255 for its verbatim refusal; re-run this round with the same result)
Clause-②: no
Thread-read: 5651810528
Serial constraints cleared: PR objectui#9471 (in flight, this seat) — packages/types/src/objectql.ts · zod/objectql.zod.ts · index.ts · two __tests__ files · plugin-calendar: DISJOINT. objectui#9088 (in flight, this seat) — packages/types/src/zod/imported-defaults.ts + its imported-defaults* pins: DISJOINT. No other claim on packages/react or packages/plugin-form.

---

The ruling governs, and it is quoted rather than paraphrased

Director seat decision batch #129 item 5, 5651810528, 2026-09-13, carried by the maintainer's 「其他同意」. ⛔ It is not this seat's to re-open or narrow. Verbatim, all four items:

1. RecordContextValue.recordId narrows to string | null | undefined. A host that mounts a record with a numeric primary key stringifies it where the record enters objectui (its adapter / the RecordContext provider boundary) — one place, typed.
2. DataSource.update's id: string | number is the same defect class on the adapter contract and narrows in the same card (⛔ no separate card); a BYO backend with numeric keys maps at its adapter boundary, which is where examples/byo-backend-console will show any residual in the type check.
3. The documented assertion objectui#9304 left in LineItemsPanel.tsx is removed once 1 lands — it was evidence, and the evidence is discharged.
4. Clause-②: no (narrowing to the protocol); changeset under the launch-window convention naming both narrowed declarations.

⭐ Clause-②: no is the ruling's reading, ⛔ not this seat's judgement, and it is recorded as the ruling's. This seat's own default on a published-type change leans the other way, and on objectui#9088 it corrected itself towards yes an hour ago. Here a ruling exists and 裁决 outranks 座位判断, so the ruling's answer stands and no needs:contract-review carrier is hung. ⚠️ If the dev measures any widening — an accept set that grows, a key that becomes writable — that is an opposite fact to the ruling's premise: ⛔ implement the ruling literally anyway, ⛔ make no promote or revert in the same PR, and report it so it can be raised as a decision card.

Premises re-measured on origin/main 02d424ab3e at 2026-09-14T10:33Z — ⛔ none inherited

⚠️ The card measured on objectui#9304's branch, and main has moved since: a686403b39 (objectui#9334) landed on 2026-09-13T01:37Z and touched two of the three named files. Every line number on the card is therefore suspect, and each premise was re-derived at the tip:

premise	verdict	measurement at the tip
RecordContextValue.recordId is still wider than string	TRUE	packages/react/src/context/RecordContext.tsx:117 — recordId: string | number | null | undefined;
the parent-id assertion objectui#9304 left behind is still there	TRUE	packages/plugin-form/src/LineItemsPanel.tsx:111 — schema.parentId || schema.recordId || (record?.recordId as string | undefined); ⚠️ the card cites line 262; it is 111 now
buildMasterDetailEditBatch still takes a string parent id	TRUE	packages/plugin-form/src/masterDetailTx.ts:124-125 — parentObject: string, / parentId: string,
the ruled action has NOT already been done by objectui#9334	TRUE	a686403b39 removed the two whole-context assertions and documented the inner one; its own commit message says so — "It did nothing at all while the binding was any; it does real work now, and the next reader needs to know which."
ruling item 2's DataSource lives where the ruling implies	TRUE, but the file was not named	the declaration is packages/types/src/data.ts; id: string | number appears at :420 and :435

⚠️ The ruling's ENUMERATION is narrower than the ruling's PRINCIPLE — and the dev does not get to choose

The principle recorded is "a consumer type may not be wider than the protocol", derived from the protocol declaring record ids as z.string() on every door. Applying that principle literally would reach more than the two declarations the ruling names. Measured at the tip, on the same surface:

packages/types/src/data.ts:392   findOne(resource: string, id: string | number, …)   ← NOT named by the ruling
packages/types/src/data.ts:420   id: string | number,                                 ← ruled (update)
packages/types/src/data.ts:435   id: string | number,                                 ← ruled
packages/types/src/views.ts:408  id: string | number;                                 ← NOT named, different surface
packages/types/src/views.ts:474  id: string | number;                                 ← NOT named
packages/types/src/views.ts:528  id: string | number;                                 ← NOT named

⛔ Execute the ruling literally: items 1-4 and nothing else. ⛔ Do not widen the PR to the unnamed sites on the strength of the principle — a ruling's enumeration is the ruling. ⭐ But do publish the census, with its counting rule, so the next decision is taken on a measured population rather than on this card's two examples. If narrowing the ruled declarations makes an unnamed one incoherent (a call that cannot type-check either way), stop and report rather than fixing it in passing.

⚠️ The census above is this seat's, taken with one grep on one spelling (id: string | number) over packages/types/src. That is a lower bound with a known blind spot — a member split across lines, a generic parameter, or an alias would not match. ⛔ Do not cite it as a population; re-derive it with a rule you can state.

What ruling item 1 actually costs, and where it must be paid

Item 1 says the stringify happens "where the record enters objectui (its adapter / the RecordContext provider boundary) — one place, typed." ⇒ the repair is not String(...) sprinkled at read sites; the ruling names that anti-pattern in its own title. Find the provider boundary, narrow the declaration, and pay the conversion once. examples/byo-backend-console is named by the ruling as the place a residual shows up in the type check — run it.

NOT MEASURED by this seat, each with its reason

• Model tier — the instrument refuses for a sister repo by design; no path-derived mandate exists.
• os-verify-lock.sh --status depth — the script does not exist in the objectui checkout. ⛔ Reported absent rather than read as depth 0. Independently: two agents in flight from this seat, both on disjoint surfaces.
• Whether any of the unnamed id: string | number sites is reached by the ruled narrowing — named as the dev's measurement, not asserted here.
• The comment count — the issue's comments counter reads 2 while the comments endpoint returns 1. That counter is denormalised and can disagree with the endpoint; the endpoint and the timeline are the authorities, so Thread-read is the ruling comment. ⚠️ If a second comment does exist and is a competing claim, this claim yields to the earlier timestamp.

Seat: domain:spec @ objectui, os-sam, 2026-09-14T10:34Z.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 9333,
  "status": "done",
  "branch": "claude/issue-9333-record-id-narrows-to-string",
  "pr": "https://github.com/objectstack-ai/objectui/pull/9501",
  "premise_still_valid": true,
  "summary": "HEAD 1b67972584c0df682669f290cbbc346038149297. One push, deliberately: at the previous head `Test (shard 1/4)` cleared its 20-minute ceiling by one second, so all four round-1 review repairs went in together. Standalone hand-off record posted on the PR itself (comment 5665292443), written to stand alone because the dispatching seat has clocked off and no round-2 review is coming. `PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 9501` at this head: EXIT 0. ROUND-1 REVIEW: FAIL on four items, all prose, none touching the ruling implementation, the breach boundary or the changeset - the reviewer verified all three independently and ablated both typeof-gate edges itself, each reddening its own row and leaving the other three green. All four repaired, each re-measured by me first rather than taken on report. (1) The diff-size figure had gone false: 536 was true of 01d4925261 and was falsified by the very next commit, this branch's own changeset rewrite, four minutes before the body was last edited. Repaired by binding the figure to a sha (559 at 1b679725, which GitHub's own additions field confirms) and pointing at the PR's live additions/deletions as the re-deriving instrument. (2) The census's positive control was measured on a different corpus than it certified: over the stated 65-file corpus DataSource appears on 39 lines in 7 files; the published 51 was the count over the 251-file set including __tests__/, which the census's own step 1 removes. Repaired to 39 with the miscount and its cause left in the body. (3) A universal quantifier in a PUBLISHED .d.ts was falsified by three untouched files - the TSDoc on RecordContextValue.recordId claimed 'everything downstream ... reads a string ... with no assertion in between', while record-details, record-quick-actions and record-alert in @object-ui/plugin-detail all read that member through an `as any`, all three present at the merge base. Repaired in the source: the sentence now says what was measured (LineItemsPanel) and names the three readers that still cast. The casts are deliberately NOT removed - plugin-detail is outside both the ruling's enumeration and the authorised breach boundary. Verified in the built artefact: the published .d.ts carries the narrowed sentence and no longer carries the universal. (4) The NOT MEASURED list was short by two of the eight reds on 297024df84. Repaired, and both classified from their OWN check-run annotations rather than by inference. A FIFTH DEFECT OF THE SAME CLASS, found by my own verification and not caught by the review: the census itself had gone stale. Re-run under its published rule at b58b36ec it returns 25 sites and 84 occurrences, not 26 and 85, because this very change narrows one of the 26 and shifts four others down three lines. Repaired by binding the whole section to the merge base af4ff1d1e0 and enumerating AND reading from that same ref, where it reproduces exactly: 251 files, 65 non-test, 85 occurrences, 26 id-bearing sites, identical list. ALSO CORRECTED IN MY OWN EARLIER REPORT: I had named only two of the three plugin-detail renderers that still cast; record-quick-actions was missing.",
  "tests": "AFTER THE REPAIRS, at head 1b67972584: @object-ui/react build exit 0, 0 error TS; packages/types, packages/react and packages/plugin-form `pnpm run type-check` all exit 0 with 0 error TS; the three new pins plus the two pre-existing RecordContext pins - 5 files, 35 tests, exit 0; apps/console project-tag rule 0 on that run. Gates re-run after the source edit: check-control-bytes, check-new-cross-file-line-citations, check-changeset-presence all exit 0; control-byte self-scan over the edited file exit 1 (no hits). Published-artefact check: `grep -c 'not about every reader' packages/react/dist/context/RecordContext.d.ts` = 1 and `grep -c 'Everything downstream' ...` = 0, so the .d.ts a consumer reads carries the repaired claim. ITEM 1 RE-MEASURED: `git diff --shortstat af4ff1d1e0 01d4925261` = 536 insertions; `... af4ff1d1e0 b58b36ecc1` = 553; `... af4ff1d1e0 1b67972584` = 559; GitHub's additions field = 559 at the current head. Ancestry control leg (known ancestor d7d0956568) exit 0, so the exit 1 readings are trustworthy. ITEM 2 RE-MEASURED: over the 65-file census corpus, DataSource = 39 line-hits / 41 occurrences in 7 files; over the 251-file set including __tests__/, 51 at the time it was published (61 today, since main has since added types tests - which is itself the same staleness class). ITEM 3 RE-MEASURED: three sites, `git grep` over packages/plugin-detail/src - record-alert.tsx:177, record-details.tsx:645, record-quick-actions.tsx:180 - each present in `git show af4ff1d1e0:FILE`, and `git diff --name-only af4ff1d1e0..HEAD -- packages/plugin-detail` empty, so all three are untouched by this PR. ITEM 4 RE-MEASURED: `GET /commits/297024df84.../check-runs?per_page=100` returns total_count 36, returned 36 (counts compared, not just the array read), conclusions 25 success / 3 skipped / 8 failure. The eight: Build Docs, Bundle Analysis, Doc Snippet Type Check, Lint, README Export Check, Skill Example Check, Test (shard 1/4), Type Check. The two the body had omitted are classified from their own annotations endpoint (200, even though log blobs answer 403): BOTH carry `line 469 col 57 | Argument of type 'string | number' is not assignable to parameter of type 'string'` plus `command (.../packages/core) pnpm run build exited (2)`. ⭐ Test (shard 1/4) is therefore NOT the ambient timeout that was the obvious hypothesis: it ran 886s against a 1200s ceiling while shards 2, 3 and 4 succeeded at 1042s, 796s and 1000s on the same head. Seven build-cascade casualties plus Type Check, the one verdict. FIFTH DEFECT RE-MEASURED: census at b58b36ec under its own published rule = 25 sites / 84 occurrences; at the merge base af4ff1d1e0, enumerated with `git ls-tree -r --name-only af4ff1d1e0` and read with `git show af4ff1d1e0:FILE` (same ref both halves) = 251 files / 65 non-test / 85 occurrences / 26 id-bearing sites, list identical to the published one. Enumeration control still fires: the worktree-glob spelling reads 208 against the dir-prefix 251-then-252, the two disagreeing being what catches it. CHECKOUT SHAPE, re-read at the moment of use: `git rev-parse --is-shallow-repository` = false at 2026-09-14T14:01:04Z in this worktree. CARRIED FORWARD FROM THE EARLIER ROUNDS, unchanged by these repairs: the 49-program run-to-completion type-check census (45 package programs plus 4 root programs, each run on its own so turbo could not cancel any, examples/hello-world reported ABSENT rather than counted as a pass) = 49 of 49 exit 0, 0 error TS, including the four CI had cancelled; whole-workspace build exit 0; vitest 365 / 1509 / 717 files across three runs, 0 failures; `pnpm lint` the whole farm 47 of 47 tasks, 0 errors - still this branch's only actual lint reading, since CI's Lint job died in its build prerequisite with ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL and never invoked eslint. NOT MEASURED: CI on head 1b67972584 (had not reported when this was written - in_progress, not green, and the push re-rolls a shard that cleared its ceiling by one second); the full `pnpm test`; playwright e2e; the merge_group leg of governed-surface-guard; @object-ui/site's build; and whether any consumer outside this monorepo hands a numeric key to the three narrowed published declarations.",
  "mcp_calls": "0 - every GitHub read and write went through repo-scoped REST, including the check-runs and check-run annotations endpoints used to classify the two previously-unaccounted reds",
  "open_questions": [
    {
      "question": "⚠️ objectui#9501 is NOT landable on `check-clause2-carriers --pair 9501` exiting 0, and the 0 cannot see why. Read from the gate script's own C4 block: `Implemented-by:` admits EITHER a session id OR a `claude/…` dev branch, and `Reviewed-by:` admits a session only. A mode:subagent dev has no session of its own, so its `Implemented-by:` value is the BRANCH. The round-1 verdict wrote a session on both lines; because a session is a structurally valid `Implemented-by:` token the pair check returns 0 anyway, and the script's own header warns that a seat-session there names the dispatching seat rather than the implementer. Who repairs the verdict comment?",
      "options": [
        "A - the rendering seat re-renders its verdict with `Implemented-by: claude/issue-9333-record-id-narrows-to-string`.",
        "B - a maintainer accepts the pair as-is, on the record that the dispatch orders never stated the spelling (the dispatching seat has recorded this as its own defect on the PR)."
      ],
      "recommendation": "Not mine to choose, and ⛔ I did not edit the verdict comment: it belongs to another actor and this repo's rule is to report such state rather than correct it. Recorded on the PR so the 0 is not read as a landing clearance."
    },
    {
      "question": "The branch is not synced past its merge base af4ff1d1e0 and origin/main has moved. Merging means a second push, which re-rolls `Test (shard 1/4)` - the job that cleared its 20-minute ceiling by one second. Sync or leave?",
      "options": [
        "A - leave it. The merge queue rebuilds on current main at landing, so the sync buys early detection of someone else's breakage rather than correctness.",
        "B - merge and take the re-roll, accepting the risk on a one-second margin."
      ],
      "recommendation": "A, taken knowingly rather than by omission and stated as such in the PR body. A maintainer who wants it synced should say so; it is one command."
    },
    {
      "question": "My order's census and the claim comment both annotate packages/types/src/data.ts:435 as ruled, but :435 is DataSource.delete's id - update's is :420, and ruling item 2 names only update. I narrowed only :420, so delete is still `string | number`. Was :435 meant to be in scope?",
      "options": [
        "A - the ruling is literal: only update narrows, delete stays wide (what landed).",
        "B - the annotation was the seat's reading and delete narrows too; a two-line change in the same file, with its own caller residuals, unmeasured here."
      ],
      "recommendation": "A, on the standing rule that a ruling's enumeration is the ruling - flagged rather than settled, because the two records disagree and the difference is one line of diff."
    }
  ],
  "out_of_scope_findings": [
    "noted, not filed: THREE `record:*` renderers in @object-ui/plugin-detail still read RecordContextValue.recordId through an `as any` - `record-details`, `record-quick-actions` and `record-alert`. ⚠️ CORRECTION to my own earlier report, which named only two and missed record-quick-actions: an incomplete population published as if complete, the same defect class as review item 3. All three casts are redundant now rather than load-bearing. Not repaired: plugin-detail is outside both the ruling's enumeration and the authorised breach boundary, and the reviewer confirmed leaving them is correct. Now recorded in the published .d.ts itself, so the next card inherits a measured population.",
    "noted, not filed: the ruling's principle does not terminate at the two declarations it enumerates. Each of the six consumer sites was red because a further declaration one layer in was ALSO wider than the protocol, and the same question is asked again by DataSource.findOne, delete, bulkUpdate and bulkDelete, and by the 25 unnamed id-bearing sites the card leaves behind. Not filed because ruling item 2 forbids a separate card for the DataSource half.",
    "noted, not filed: a published figure with no instrument behind it goes false silently, and this PR produced THREE instances in one day - the diff size (falsified by the next commit, four minutes before the body was edited), the census control (measured on a superset corpus), and the census itself (falsified by the very change it documents). All three were numbers copied into prose rather than pointers to something that re-derives them. The repair pattern that worked: bind the number to a sha so it becomes historical rather than wrong, and name the live field or command beside it.",
    "noted, not filed: GitHub's check-run ANNOTATIONS endpoint answers 200 for these sessions even where Actions log blobs answer 403. That is the difference between classifying two silent reds by measurement and classifying them by inference - and it refuted the obvious timeout hypothesis for `Test (shard 1/4)`, which the duration reading (886s against a 1200s ceiling, siblings green at 1042/796/1000s) then confirmed.",
    "noted, not filed: an enumeration trap worth knowing repo-wide - `git ls-files 'packages/types/src/**/*.ts'` returns 208 paths while the directory-prefix spelling returns 252, because git's default pathspec is not glob-magic and the two-star form demands at least one directory level, silently dropping every file sitting directly in src/ (which is where data.ts and views.ts live). The same trap bit a `.update(` census: `-- 'packages/*/src'` matched 0 files while `-- packages apps examples e2e scripts` matched 45. Both were caught only by running two spellings and comparing.",
    "noted, not filed: the labels now on objectui#9501 (`data-adapter`, `package: core`, `package: types`, `package: react`, `plugin`, `tests`) were applied by the repository's own labeler, not by this seat. ⛔ No label was added or removed here at any point."
  ]
}

---

Generated by Claude Code

[claude]

Delivered — landed on main

PR #9501 merged. Closing this card completed. Readings taken 2026-09-14T15:20Z.

Reading 1 — the merge queue's own timeline

added_to_merge_queue 15:01:30Z → removed_from_merge_queue 15:20:06Z → merged 15:20:07Z. ⛔ Not an auto_merge field read (consumed by the enqueue), ⛔ not a check_suite rollup.

Reading 2 — the content on origin/main, located by SYMBOL

⛔ Not by head-sha ancestry, ⛔ not by the merged boolean. Store re-fetched and proved non-shallow (is-shallow-repository = false, 15:20:31Z) before any ancestry call.

Landing commit 72d65875cf3665186fdc0ba025936e7fd93927cb
Title fix(types,react,plugin-form): narrow RecordContextValue.recordId and DataSource.update's id to the protocol's string (#9501)
Parent count: 1 — git show -s --format='%p' <sha> | wc -w ⇒ a squash.

⭐ The boundary is visible in one reading, and it is exactly the ruling's enumeration. packages/types/src/data.ts, both declarations located by their own update( / delete( openers:

ref	update's id	delete's id
origin/main	:423 — id: string ⇒ narrowed	:438 — id: string | number ⇒ still wide, correctly
merge-base af4ff1d1e0 (the control)	:420 — id: string | number	:435 — id: string | number

⭐ The control fires on update and is correctly silent on delete — so the reading is evidence of this change and not of a grep that matches everywhere, and it demonstrates the untouched half at the same time.

The old behaviour is gone

At the merge base, a caller could hand DataSource.update a numeric key that the protocol's own protocol.zod.ts refuses (id: z.string() at the get/update/delete doors, 14 occurrences file-wide, zero numeric or union ids). The type now matches the protocol, so that call no longer type-checks. RecordContextValue.recordId is narrowed the same way, and the published .d.ts was verified to carry the corrected TSDoc — the reviewer emitted the declaration at two refs, with the old universal present at b58b36ec (the control firing) and absent at the landing head.

⛔ What this card deliberately did NOT do

DataSource.delete's id stays string | number. Ruling item 2 names only update, and ⭐ a ruling's enumeration is the ruling. Whether delete should also narrow is objectui#9511 (needs-user-decision, open) and ⛔ is not answered here.

⚠️ The dispatching seat's own defect, recorded because it shaped this card. My dispatch census annotated packages/types/src/data.ts:435 as ruled. At the merge base :435 is delete's id; update's is :420 — the table above now shows both. The dev measured it, disagreed with my order, and was right. ⭐ A line number near a symbol is not a reading of which declaration OWNS it — brace-walk, not proximity. Round 2 confirmed it independently by walking the declaration extents (update 418..423, delete 433..437).

Three record:* renderers in @object-ui/plugin-detail still read the member through an as any — outside both the ruling's enumeration and the authorised surface, correctly untouched, and now named in the published .d.ts so the next card inherits a measured population.

Gate record

• ① round-2 contract review PASS at the exact landing head — 5666002615; the head it declares and the live head.sha compared as strings, character-identical.
• ② --pair 9501 exit 0, captured before any pipe, run after the verdict landed. ⛔ Silent on the clause-② independence limb — the mechanism is now established: check-clause2-carriers.mjs:2127-2132 declares a verdict on a PENDING pair's PR thread invisible to C4, and this card's thread carries zero ## Contract review comments (control returns 1, so the zero is a reading). ⇒ C4 was never going to fire.
• ③ 37 of 37 check-runs green at the landing head, 0 not-green, 0 running, legacy combined status success. ⚠️ 36 → 37 at undraft; this seat waited for Governed Surface Queue Guard to report before enqueuing rather than acting on the draft-era count.
• Carrier — ⛔ none, correctly: this card declares Clause-②: no, so needs:contract-review never belonged here and none was ever hung.

⭐ A fifth defect was caught by the dev's own verification, not by the review — the card's published census had gone stale against the very change it documents (26 id-bearing sites → 25). Repaired by binding the section to the merge base and enumerating and reading from that same ref; round 2 reproduced it exactly (65 files / 85 occurrences / 26 sites at the base, 84 / 25 at the head, with the four shifted sites each +3). That class is objectui#9509.

---

Generated by Claude Code