[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzgbJhFoXYsLSe5WSPP

Part of #27627

Claim: 6501011060
Clause-②: yes (widening)
Metadata-protocol: added
Skills-docs: none edited. No skill teaches which requests a record page sends when it opens, and the API skill's spec index (skills/objectstack-api/references/_index.md) lists schema files it reads from the installed package, so the new api/record-page.zod.ts needs no row (check:skill-refs exit 0). Named, not edited.

Metadata-protocol: added, measured. The claim's added named the app bundle (PR 2); this PR measures added for itself. The new request and response shapes enter packages/spec/authorable-surface/api.json, the authorable-surface shard the level axis reads, so check-changeset-no-major --event refuses none here. Nothing an author already writes changes meaning: no existing key, default or answer moves. Per the rule, every package this PR moves takes minor (both changesets).

维护者速读

• 改了什么： 新增 POST /api/v1/data/{object}/{id}/page，一次请求返回记录详情页打开时要的全部数据：记录本身（含查找字段展开）、每个相关列表的总数和前几行、字段权限、审批状态与锁、页头按钮的权限判定。控制台记录页（整页、分栏、抽屉）改为只发这一个请求，再把各部分交给原来各自去取的组件；抽屉里预取下一条将要显示的记录。
• 为什么改： 以前打开一条记录要分两到三批串行请求（测试里冷启动 13 个分两批、热启动 8 个；HotCRM 浏览器实测 45 / 23 个；改后冷启动只剩 1 个数据请求加对象定义读取，热启动 1 个），每个相关列表还要单独发一次 top=1 计数探测，远距离部署下每批都要多等一个往返。
• 风险与回滚： 每一部分都是在服务端以同一调用者身份调用被替代请求的同一个函数，所以对象权限、行级安全、共享和字段级安全照旧生效；看不到的相关列表只带拒绝，不带总数也不带行。打开之后的刷新、写入后重读仍走各组件自己的请求。回滚 = revert 本 PR。
• 先看： packages/rest/src/record-page-routes.ts（每一部分调用哪个函数、父记录条件怎么拼）、packages/qa/dogfood/test/record-page.dogfood.test.ts（非管理员成员下与分开请求逐项对比）、ui/packages/app-shell/src/views/recordPagePayload.ts（页面要哪些列表、答案交给谁）。
• 两分钟验证： cd packages/qa/dogfood && pnpm exec vitest run test/record-page.dogfood.test.ts → 3 个用例绿：非管理员成员拿到的记录、相关总数与行、字段权限、判定、审批与分开请求一致，无权限的相关列表 403 且无总数无行。
• 需要你做的： 无。本 PR 超过 3000 行属 Tier H，维护者已批准（os-zhuang，2026-10-30 12:49Z），席位核对后入队落地。

What changes

Request counts, before and after

Measured in a console test harness over the real ObjectStackAdapter on a held transport (each "wave" is one round: everything asked so far is answered together, and what the page asks next is the next wave). The record is a contact with one lookup and four related lists, opened in StrictMode on the default record page; the same harness file ran on origin/main (the ui/packages tree checked out from origin/main) and on this head, and both runs draw the record.

Correction to the figure quoted to the seat (warm 9 → 8)

The first harness run answered the record read (GET /data/{object}?filter=["id","=",…]) with no row, so it measured a "Record not found" page; its warm figure was 9 because the not-found page also read the approval lock. With the record answered, origin/main reads cold 13 in 2 waves and warm 8 in 1 wave. The cold figure is unchanged.

Before, origin/main at the merge base 178b5238:

COLD 13 requests, 2 waves
w1 GET  /api/v1/approvals/requests?object=os_27627_contact&recordId=c1
w1 POST /api/v1/security/explain {"operation":"update",…}
w1 POST /api/v1/security/explain {"operation":"delete",…}
w1 GET  /api/v1/data/os_27627_contact?populate=account&top=1&filter=["id","=","c1"]
w1 GET  /api/v1/meta/object/os_27627_task      (and _case, _deal, _event)
w2 GET  /api/v1/data/os_27627_task?top=1&filter=["contact","=","c1"]   (and _case, _deal, _event)
w2 GET  /api/v1/meta/object/os_27627_contact

WARM 8 requests, 1 wave
w1 approvals list, explain update, explain delete, the record, four top=1 probes

After, this head:

COLD 6 requests, 2 waves
w1 POST /api/v1/data/os_27627_contact/c1/page {"expand":["account"],"related":[4 lists, top 3],"explain":["update","delete"],"fieldAccess":true,"approvals":true}
w1 GET  /api/v1/meta/object/os_27627_task      (and _case, _deal, _event)
w2 GET  /api/v1/meta/object/os_27627_contact

WARM 1 request, 1 wave
w1 POST /api/v1/data/os_27627_contact/c2/page {…}

	Before	After (this PR)
Cold open, data requests	8 (4 in wave 1, 4 probes in wave 2)	1, wave 1
Cold open, top=1 probes	4	0
Cold open, object definitions	5 (one in wave 2)	5 (one in wave 2), unchanged until PR 2
Warm open, all requests	8	1
Step to a prefetched neighbour (split pane or drawer, ↑ ↓ or a row click)	a full open	0 for the record it opens; its own neighbours are then asked ahead (see "Merge with #28129")

The only second-wave request left is the record object's own definition (/meta/object/<object>), which the details block reads once the record arrives; it was there before too, and it is what PR 2's app bundle serves.

The route: POST /api/v1/data/{object}/{id}/page

The query form (a POST with a strict body) was chosen because the page must name its related lists, their declared filters and their order, and that does not fit a closed query string. Seat ruling: accepted, Clause-②: yes (widening).

Request (RecordPageRequestSchema, @objectstack/spec/api, strict; the query-parameter set is closed and empty):

{
  expand?: string[];                 // lookups to resolve, as GET /data/{object}/{id}?expand=
  related?: Array<{                  // max 50
    object: string;                  // the child object
    field: string;                   // its lookup/master_detail field referencing {object}
    filter?: unknown;                // the list's declared scope, AND-composed with the parent condition
    top: number;                     // 0..50 first rows
    sort?: Array<{ field: string; order: 'asc' | 'desc' }>;   // max 8
  }>;
  explain?: Array<'update' | 'delete' | 'transfer'>;
  fieldAccess?: boolean;
  approvals?: boolean;
}

Response data (RecordPageResponseSchema):

{
  object: string; id: string;
  record: Record<string, unknown>;                      // as GET /data/{object}/{id}
  related: Array<{ object; field; total?; records?; error? }>;   // request order
  fieldAccess?: GetRecordFieldAccessResponse | { error };
  explain?: { update?; delete?; transfer?: ExplainDecision | { error } };
  approvals?: { requests: Array<…>; lock: { locked: boolean } | null } | { error };
}

Every part is the read it replaces, asked as the same caller, through the same function:

Part	The read it replaces	Called through
record	GET /data/{object}/{id}	getData, after the same object-exposure gate, asked with the caller's context
related[i]	GET /data/{child}?filter=…&$count	findData with the canonical QueryAST (where, limit, orderBy, count: true), after the child's own exposure gate
fieldAccess	GET /data/{object}/{id}/field-access	getRecordFieldAccess
explain.<op>	POST /security/explain with the record id	the security service's explain
approvals	GET /approvals/requests for the record and GET /approvals/records/{object}/{id}/lock	listRequests (the pending row enriched by getRequest) and getRecordLock

• A record the caller cannot read refuses the whole request with the record read's own answer, before any other part is asked, so no part answers for a record the caller could not open.
• A part whose read refuses carries that refusal ({ code, status, message }) in place of its answer, and the other parts are answered. ⛔ A related list the caller may not read carries neither total nor records.
• A related entry must be a relationship to this record: a lookup or master-detail field of the child that references {object}, or a 400 VALIDATION_FAILED whose error.details.fields locates invalid_relationship at related.N.field, before anything is read. Both request refusals answer through the shared sendError; the catch relays mapDataError exactly as GET /data/{object}/{id} does (declared in check-route-envelope.mjs with the data family's [tracking] Envelope-position convergence line for packages/rest's flat dialect — the live ratchet owner #9559 ratchet). The parent condition is the server's, compiled to the field's arity ($contains for a multi-value field); a declared filter can only narrow it.
• Server-Timing. The route's metadata reads are timed as a meta span beside the existing db and total, under the existing gate (OS_SERVER_TIMING=true, or X-OS-Debug-Timing: 1 from an admin), per the seat's ruling. Opening Server-Timing to every caller would be a maintainer card. Cache-Control and ETag already answer on the metadata item routes (/meta/object/{name}), so nothing moves there in this PR; the bundle in PR 2 carries its own ETag.
• @objectstack/client: data.recordPage(object, id, request). Route ledger row POST /api/v1/data/:object/:id/page (disposition: 'sdk', client: 'data.recordPage', responseSchema: 'RecordPageResponseSchema').

The console

• RecordDetailView builds the request from the page it renders (the record:related_list nodes, the record:reference_rail entries and the lists derived for a synthesized page; the header's update / delete verdicts and transfer when the object has a queue; field access; approvals) and sends it once, in a layout effect, before any reader's effect runs. Each part is handed to the reader that used to ask for it, as that reader's read on the wire: RelatedCountStore.seed (tab badges, collapsed, compact and rail cards), seedRecordVerdict, seedQueueClaimDecision, seedRecordFieldAccess, seedRecordApprovals. A refused part reaches its reader as that read's refusal. No dual path: an adapter that implements getRecordPage never sends the replaced reads at open.
• In a drawer, the open record's page prefetches the record a ↑ / ↓ step shows next (the drawer's upcoming record from perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636) through DataSource.prefetchRecordPage (at most 4 held, taken once, dropped by any write). See "Merge resolution with perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636" below.
• What still reads for itself, by design: every reader after the open (a refresh, a write, a change on the data-invalidation bus); a list the page cannot name in the request (one declared through a listView, one whose filter carries a context token the reader resolves against the session first, one whose filter does not lower, the lists past the fiftieth); the attachments badge probe; a sorted list sharing a key with a rail card (the rail takes rows in the default order); and a list whose part the server refused: the store keeps no refusal, so a reader that mounts after the payload answered reads that list once more and gets the same refusal (measured in the harness: one extra request per refused list, never a count or a row). An adapter without getRecordPage reads exactly as before.

Files outside the claim's file surface

The claim named RecordDetailView.tsx, recordDrawerStack.tsx, recordBinding.tsx, RelatedCardStack.tsx and ui/packages/data-objectstack on the consumer side. Retiring the separate reads with no dual path meant each reader had to accept its part, so the diff also touches the readers themselves: ui/packages/types (the DataSource methods and shapes), ui/packages/components related-count-store.ts (seed / takeRows), ui/packages/plugin-detail (useRecordEditable.ts, queueClaim.ts, recordFieldAccess.tsx, RelatedList.tsx, index.tsx), ui/packages/app-shell useRecordApprovals.ts and the new recordPagePayload.ts, and the dogfood fixture and test. recordBinding.tsx and RelatedCardStack.tsx did not need to move. packages/spec/contracts/** does not exist; the shapes live in packages/spec/src/api/record-page.zod.ts beside the other REST shapes. packages/objectql did not move (each list's count rides its own findData with count: true).

Contract review should-fix (review 6508117594 on 330e18be1)

Item	What changed	Commit	Test
1. A refused related list could read as an empty one	RecordPageRelatedAnswerSchema is now a union of two strict arms, RecordPageRelatedRowsSchema {object, field, total, records} and RecordPageRelatedRefusalSchema {object, field, error}, so an answer carries rows or a refusal, never both and never neither. The authorable shard drops the five RecordPageRelatedAnswer:* rows (they never shipped) and gains the two arms' rows.	35a872079	record-page.test.ts: both arms parse; a refusal with total and/or records, and an answer with neither, are refused.
2. The explain answer hand-listed its operations; its schema was private	The explain part's keys derive from RecordPageExplainOperationSchema.options; RecordPageExplainAnswerSchema is exported with its z.input and Parsed aliases (rows in api-surface, export-origins, declaration-map, json-schema.manifest).	35a872079	record-page.test.ts: the explain object's keys equal the enum's options, and every option's refusal parses.
3. A malformed declared filter answered as a 400 part inside a 200	The route lowers every declared filter with parseFilterAST beside the invalid_relationship judgement, before the record read, and reuses the lowered filter for the list read. A refusal is a 400 VALIDATION_FAILED at related.N.filter (invalid_filter). related[].filter's description says so.	5a7107f65 (route, test), 35a872079 (description)	record-page-routes.test.ts: a filter parseFilterAST refuses ({ title: { $in: 'x' } }) is a located 400; neither getData nor findData is called.
4. approvals.requests on a deployment with no approval service	Its description says it is empty there, as lock says null.	35a872079	record-page-routes.test.ts (existing): with no approval service the part is { requests: [], lock: null }.

Metadata-protocol: added still holds for the final shape: the authorable shard gains rows and loses only rows this PR added. Every moved package stays minor.

Contract re-review must-fix (reviews 6512166649 on 0efe2a4de and 6513269907 on 392693230)

Each must-fix was a CI red on the head it was found on, and each landed with a test, or a typecheck, that fails without it.

Must-fix	What changed	Commit	Test
1. The record read asks the same exposure gate as GET /data/:object/:id	enforceApiAccess(req, res, p, environmentId, 'get', context): the route passes the context it already holds, as crud-routes.ts does since #27692 (the 5-argument call was TS2554, Type Check · workspace)	392693230	record-page-routes.test.ts "asks the object-exposure gate as GET /data/:object/:id does, with the caller's context (#27692)": the gate is asked once with 'get' and the resolved context. Ablated: with the 5-argument call it fails. @objectstack/rest typecheck (tsc and check:test-typecheck) exits 0
2. The related list read speaks the declared QueryAST	query: { object, where, limit, count: true, orderBy? }, typed against FindDataRequest with no cast; the wire aliases filter / top and the as any are gone. REGISTRAR_QUERY_SLOT_FLOORS gains 'record-page-routes.ts': 1 and the whole-package slot control goes 4 → 5	392693230	rest-server-canonical-query-ast.test.ts (rest test:repo, the Test Core (8/8) red) passes; record-page-routes.test.ts pins the exact findData arguments in the new spelling. The engine folds top into limit and filter into where, so the dogfood comparison against the separate list read is unchanged
3. The dogfood test, the contract's end-to-end consumer, compiles against the two-arm related answer	record-page.dogfood.test.ts reads each related part through rowsArm(i) / refusalArm(i), which narrow by 'total' in / 'error' in and fail the test on the wrong arm; no cast. Six TS2339 in @objectstack/dogfood typecheck (the Type Check · workspace red on 392693230) are gone	6f040ab5e	@objectstack/dogfood typecheck exits 0; the dogfood trio exits 0 (the refused ledger list now has to be the refusal arm, and the two readable lists the rows arm)

The review's ① also named the Type Check UI red (check:spec-symbols): @object-ui/types hand-declared RecordPageRelatedRequest, RecordPageRequest and RecordPagePartRefusal, three names @objectstack/spec/api exports. 8ad440797 re-exports them from the spec and binds RecordPageOperation to the spec's RecordPageExplainOperation. check:spec-symbols exits 0, and so do the remaining Type Check UI legs (below).

Correction to r2. r2 listed every locked suite and gate on 392693230 as exit 0, and they were, but @objectstack/dogfood typecheck was not among them: vitest runs the dogfood test without type-checking it, so the six TS2339 there (must-fix 3) reached CI. This revision runs turbo run typecheck over every package turbo ls --filter='...[merge base]' lists (73 packages, 142 tasks, the packages the PR touches and every dependent of them, @objectstack/dogfood included) and lists its exit code.

Correction to r1. r1 said every derived gate exited 0 on 0efe2a4de, and that was true of the 137 that dispatch-gates derives. CI then failed three required contexts that none of those 137 covers: @objectstack/rest typecheck (after the main merge), rest test:repo (my locked run had rest test only), and ui check:spec-symbols. This revision runs all three, plus the ui type-check legs, and reports each one's exit code.

Merge with #28129 (record pane v4), main at d70e94ae1

The merge queue dropped the PR at 14:17Z on a conflict with #28129. 49204ce58 merges origin/main at 277275aa4 through scripts/pm/os-regen-merge.sh; f66a0104b then merges main at d70e94ae1 (9 more commits, no conflict) the same way. Main moved no generated shard in either range, so step 2 kept the branch's bytes; the full regen chain on the merged tree (pnpm --filter @objectstack/spec build, gen:export-origins, gen:schema, gen:api-surface, check:generated --fix, gen:docs, gen:strictness-ledger, check:generated) exits 0 and leaves the tree clean (git status --porcelain: 0 lines).

One conflicted hunk, the ./recordDrawerStack.js import in ui/packages/app-shell/src/views/RecordDetailView.tsx. This PR imports RecordDrawerUpcomingContext (and adds the ./recordPagePayload.js import below it); main imports useRecordPane. Resolved as the union: one import of PrefetchUpcomingRelatedCounts, RecordDrawerReturnLink, RecordDrawerUpcomingContext, RecordPageDrawerHost, useRecordPane, then this PR's recordPagePayload line. Every other file merged without a conflict (recordDrawerStack.tsx, RelatedList.tsx, plugin-detail/src/index.tsx, data-objectstack, client).

A shape change the text merge did not show, fixed in 722a37c5a. #28129 changed RecordDrawerUpcomingContext from one record (RecordDrawerUpcoming | null, the step in the last direction) to readonly RecordDrawerUpcoming[], BOTH neighbours, the one in the last step's direction first. This PR's prefetch read upcoming.objectName / upcoming.recordId, which merged cleanly and is undefined on an array, so on the merged tree the pane would have asked no neighbour ahead. The fix asks each neighbour of the same object once this record's page has answered, keyed on the ids' content (AGENTS.md #10). The adapter's prefetch map holds up to 4 entries, so both fit.

v4 entry points checked.

• Split pane beside the list and the non-modal drawer over it: both are ObjectViewRecordOverlay → RecordStackDrawer, which renders the same embedded RecordDetailView inside RecordDrawerUpcomingContext. One page request per open.
• ↑ ↓ and a click on another row (root swap): the level's Fragment key is depth + object, so the record swaps in place through recordIdOverride; a swap to a prefetched neighbour sends nothing for that record.
• ⤢ maximize in place: NavigationOverlay keeps one element and restyles it; no remount, no re-ask.
• 「Open as full page」 (record header) and the row's ↗: the record route, the non-embedded view the cold and warm cases pin.

New test case in RecordDetailView.recordPagePayload-27627.test.tsx ("in the v4 pane, both neighbours are asked ahead as pages, and an in-place step to either opens from that answer"): the pane opens c2 with neighbours [c3, c1] → pages c2, c3, c1 and no count probe for either neighbour; an in-place step to c1 with neighbours [c0, c2] → only c0 and c2 are asked, nothing for c1, no non-page data request. The existing cases now hand the context an array. Ablation: prefetching only the first neighbour turns this case red (1 failed, 5 passed); restored, 6 passed.

Cost, stated. Each step re-asks the record just left: the open took its prefetched answer, and the adapter keeps no settled payload (a kept one would serve rows a write has since changed). That is one background page request per step, sent after the current page has answered, matching v4's choice to warm both sides (its count warm-up also covers both neighbours).

Merge with main at ba4ecf1d2 (178 commits)

428642e58 merges origin/main through scripts/pm/os-regen-merge.sh; 780dd8c26 regenerates the three surface shards the os-regen driver merged without a text merge. Nothing else moved.

One conflict, ui/packages/data-objectstack/src/index.ts, two hunks. Main's #27907 (objectstack#27626: concurrent getRecordFieldAccess asks share one request; 404 and 501 are remembered) and this PR each added adapter members in the same two places:

1. The fields beside inflightFindOnes: this PR's inflightRecordPages / prefetchedRecordPages, main's inflightFieldAccess / unansweredFieldAccess / fieldAccessUnsupported. Kept both, this PR's first.
2. dropInflightReads: this PR clears both record page maps (a payload carries other objects' rows, so any write drops it); main drops its field-access entries by the resource prefix. Kept both.

Main's rewritten getRecordFieldAccess and this PR's getRecordPage / prefetchRecordPage / readRecordPage merged without a conflict. The two do not overlap: with the payload, the console seeds field access from the page and never calls getRecordFieldAccess on open, while after a save the field-access readers still go through it (now shared).

Generated shards. The merge commit dropped main's three disabledActions authorable rows (the driver's silent one-sided merge); the regeneration restores them. Against main the three shards differ by exactly this PR's rows: api-surface +36, authorable-surface +30, export-origins +36. check:generated exits 0.

Merge resolution with #27636

origin/main gained #27636 (objectstack#27056: the related column loads counts first, then rows only for the cards in view, and the drawer warms the next record's related counts). The merge (7d6f3ed34) conflicted in three files:

• ui/packages/app-shell/src/views/RecordDetailView.tsx — the imports. The page now reads perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's RecordDrawerUpcomingContext for its prefetch.
• ui/packages/app-shell/src/views/recordDrawerStack.tsx — taken as main has it. This PR's own neighbours context (RecordNeighborsContext, previous and next sibling) is gone, so the drawer names one next record, perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's upcoming.
• ui/packages/plugin-detail/src/RelatedList.tsx — the fetch effect's dependency list, and a name collision. The compact branch reads the card context once (perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's compact). The payload adoption still runs before perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's in-view / non-zero gate (rowsWanted), so a card whose rows the payload carries draws them without reading, in view or not.

What runs where:

• An adapter with getRecordPage / prefetchRecordPage (the console's ObjectStackAdapter): the open asks one page payload, and perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's count set (useRelatedCounts → RelatedCountStore.fetch) joins the seeded counts, so it sends nothing. In a drawer, the page prefetches the upcoming record's payload once this one's has answered, and perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's PrefetchUpcomingRelatedCounts is not mounted. The next record's counts are asked once, inside its page, not twice.
• An adapter without them: nothing seeds the store. perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's count set, its in-view row reads and its drawer warm-up run unchanged.

Tests, both in the acceptance file, on the real adapter in a drawer (embedded, upcoming = c2):

• with the payload: the pages asked are exactly c1 and c2, and no count probe for c2 goes out. Ablated (the warm-up mounted regardless), this case fails.
• without it (the adapter's two methods removed): no page request, and each of c2's four related counts is asked exactly once by the warm-up.

#27636's own suites (RecordDetailView.relatedCountsFirst-27056, __tests__/recordDrawerStack.prefetch-27056, useRelatedCounts-27056, RelatedList.compactLazy-27056) pass unchanged on the merged head.

Tests

• packages/rest/src/record-page-routes.test.ts, 13 cases: the composed answer parses against RecordPageResponseSchema (expand, declared filter AND parent condition, multi-value $contains, sort → orderBy); only the named parts are asked; a record refusal is the whole answer; a related refusal carries error and no total / records; an API-disabled child is OBJECT_API_DISABLED 404 and never read; part refusals for field access, explain and approvals; missing services answer 501 parts and empty approvals; a system context without a user id gets a 401 explain part; invalid_relationship 400 before any read; a strict body refuses unknown keys and a bad sort order; a query parameter is a 400.
• packages/qa/dogfood/test/record-page.dogfood.test.ts, 3 cases, as a non-admin member on a booted stack (fixture: an account with an FLS-unreadable rating; notes under owner RLS with an FLS-unreadable secret; tasks with a declared filter; a ledger object with no grant; a private object). Each part equals its separate read for the same member: the record equals GET; notes total 2 and the same rows with no secret; tasks with {status:'open'} total 4 and 3 rows; the ledger list is a 403 part with neither total nor records; field access equals GET …/field-access; explain equals POST /security/explain; approvals match; an unreadable or missing record's page equals the record read's 404; invalid_relationship and query-parameter 400s.
• ui/packages/app-shell/src/views/RecordDetailView.recordPagePayload-27627.test.tsx, the card's acceptance test on the real adapter: a cold open sends exactly one page request and zero top=1 probes, every data request in wave 1, and every badge total comes from the payload; a warm open sends one page request; the drawer's next record is asked ahead with the same body, and stepping to it sends nothing but the following record's prefetch; the two merge-resolution cases below; and the v4 pane case (both neighbours, in-place step), 6 cases in all.
• packages/spec/src/api/record-page.test.ts (new, 3 cases) and one new case in record-page-routes.test.ts: the contract review's should-fixes, mapped below.
• The rest censuses a new route owes: rest-write-response-internal-fields.tripwire.test.ts drives the route as a read over POST (the read-path strip of internal: true fields, like POST /data/:object/query); rest-write-route-hook-refusal-sentence.ledger.test.ts drives a beforeFind refusal of the record read as the whole answer; record-page-routes.ts joins REST_SERVER_REGISTRAR_FILES, so the resolveExecCtx census and the docblock-position floors read it.
• Existing open-time pins updated to read the payload's body for the questions the separate reads used to ask (recordOpenRequests-11699, recordOpenRequests-12701, recordOpenWaves-13010, afterActionExplain-13341, recordReadFailure-11902): their assertions on what is asked, how often and in which wave are kept.

Verification

Exit codes are the verdict; counts are context.

Locked suites (os-verify-lock), each part with its own exit code

On f66a0104b (main d70e94ae1 merged, the v4 prefetch fix):

Suite	Exit	Counts
spec build, then the regen chain above	0 / 0	tree clean after it
turbo run build (whole repo)	0	116 tasks
ui packages/data-objectstack	0	106 files, 1236 passed
ui packages/plugin-detail + packages/app-shell (whole package, #28129's tests included)	0	2318 files, 20795 passed, 27 skipped
pnpm --dir ui run check:spec-symbols	0
ui turbo run type-check over CI's affected filter since d70e94ae1	0	107 tasks
@objectstack/rest typecheck / test / test:repo	0 / 0 / 0	354 files, 6829 passed / 5 files, 284 passed
turbo run typecheck over the 74 packages that depend on the merge base's changes (packages/*, apps/*)	0	144 tasks
dogfood record-page + authz-probe-blind-spot + authz-conformance	0	3 files, 73 passed

On 780dd8c26 (main merged, artifacts regenerated):

Suite	Exit	Counts
turbo run build (whole repo, after pnpm install for main's new driver-odata)	0	116 tasks
ui packages/data-objectstack	0	105 files, 1234 passed
ui packages/plugin-detail + app-shell RecordDetailView* + recordDrawerStack	0	430 files, 3655 passed, 18 skipped
pnpm --dir ui run check:spec-symbols	0
ui turbo run type-check over CI's affected filter since the merge base	0	107 tasks
@objectstack/rest typecheck / test / test:repo	0 / 0 / 0	354 files, 6825 passed / 5 files, 284 passed
turbo run typecheck over the 74 packages that depend on the merge base's changes (packages/*, apps/*)	0	144 tasks
dogfood record-page + authz-probe-blind-spot + authz-conformance	0	3 files, 73 passed
spec check:generated	0

On 6f040ab5e (must-fix 3):

Suite	Exit	Counts
turbo run typecheck over the 73 workspace packages the PR touches or that depend on one it touches (turbo ls --filter='...[merge base]', packages/* and apps/*)	0	142 tasks
@objectstack/dogfood typecheck	0
dogfood record-page + authz-probe-blind-spot + authz-conformance	0	3 files, 73 passed

On 392693230 (must-fixes 1 and 2):

Suite	Exit	Counts
@objectstack/rest typecheck (tsc --noEmit and check:test-typecheck)	0
@objectstack/rest test	0	343 files, 6720 passed, 326 skipped
@objectstack/rest test:repo	0	5 files, 284 passed, 19 skipped
@objectstack/rest build, then dogfood record-page + authz-probe-blind-spot + authz-conformance	0 / 0	3 files, 73 passed
ui scripts suite (pnpm --dir ui exec vitest run scripts/)	0	169 files, 4902 passed

On 8ad440797 (the ui types fix; no ui file moved after it), the Type Check UI legs:

Leg	Exit
pnpm --dir ui run check:spec-symbols	0
check:action-forward-parity, check:designer-field-key-parity, check:icon-record-names, check:i18n-keys, check:i18n-drift, check:phantom-deps, check:self-import, check:unreferenced-sources, check:side-effects-array	0 each
turbo run type-check over the ui packages changed since the merge base and their dependents (CI's filter; 106 tasks)	0
type-check:scripts, type-check:e2e, type-check:vitest-setup, type-check:coverage	0 each

Carried from r1, on 0efe2a4de (no file these cover moved since):

Suite	Exit	Counts
@object-ui/app-shell tsc --noEmit	0
ui packages/app-shell	0	1910 files, 17272 passed, 9 skipped
ui packages/plugin-detail + components/src/hooks + data-objectstack + types	0	824 files, 14724 passed, 18 skipped
@objectstack/client	0	52 files, 680 passed
@objectstack/spec / test:repo	0 / 0	754 files, 22394 passed / 87 files, 1448 passed
ui RecordDetailView* + recordDrawerStack tests	0	85 files, 548 passed

Correction to r0. r0 reported the app-shell suite green. That run exited 1: every test passed, but vitest counted three unhandled rejections from afterActionExplain-13341, raised by a seeded approvals part that no reader joined. Fixed in 367cfd2ad; the app-shell run above exits 0.

• dispatch-gates --commands on f66a0104b: 137 derived; --ran: 137 run, 0 NOT-MEASURED, 0 UNRUN, every gate exit 0; --ran itself exit 0 (resumed from an append-only record after a container restart at gate 45). None of the 137 is check:spec-symbols, a package typecheck or rest test:repo; those are run and listed above.
• check-changeset-no-major --base origin/main --event with this body: exit 0 (declaration Clause-②: yes (widening), Metadata-protocol: added)
• Size: 3193 additions + 103 deletions = 3296 changed lines (git diff --shortstat origin/main...HEAD, 48 files), up from 3257 by the v4 fix. Over the 3000 threshold, so this PR is Tier H and needs a maintainer approval.
• Head f66a0104b6d18598f4132bcc629f66d551d0a244.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WGufzhCjfxaYJQyy6tFjVr

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract-review-claim: session_01L6bhgV4fMGJHSdSdx3u9mK · head 330e18b · 2026-10-29T20:42Z

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 330e18be1c57e05fbe6e661913bcb18a3c9fcf7b
Local-runs: none
Scope: packages/spec/src/api/index.ts, packages/spec/src/api/record-page.zod.ts + packages/rest/src/record-page-routes.ts, packages/rest/src/record-page-routes.test.ts, packages/rest/src/rest-server.ts, packages/rest/src/rest-route-ledger.ts, packages/rest/src/crud-routes.ts (main), packages/rest/src/data-action-routes.ts (main), packages/rest/src/security-routes.ts (main), packages/rest/src/approvals-routes.ts (main), packages/rest/src/error-response.ts (main), packages/rest/src/query-allowlist.ts (main), packages/client/src/index.ts, packages/spec/src/api/protocol.zod.ts (main), packages/spec/src/security/explain.zod.ts (main), packages/spec/src/data/query.zod.ts (main), packages/spec/src/data/filter.zod.ts (main), packages/spec/src/shared/lazy-schema.ts (main), packages/objectql/src/engine.ts (main), packages/metadata-protocol/src/protocol.ts (main), packages/qa/dogfood/test/record-page.dogfood.test.ts, ui/packages/types/src/data.ts, ui/packages/data-objectstack/src/index.ts, ui/packages/app-shell/src/views/recordPagePayload.ts, .changeset/27627-record-page-payload.md, .changeset/27627-console-record-page-payload.md, packages/spec/authorable-surface/api.json, packages/spec/api-surface/api.json, packages/spec/export-origins/api.json, packages/spec/declaration-map/api.json, packages/spec/json-schema.manifest/api.json, packages/spec/llms.txt, docs/audits/2026-07-unknown-key-strictness-ledger.counts/api.md

Inputs read: card #27627 body and its three comments (deployment half 6500767235, claim 6501011060, claim amendment 6507391490); PR #27713 body, 47-file list and net diff from the files endpoint; the check-runs on the head. The rest of the diff (console readers, pins, docs, census tests) is the lane seat's ACCEPT at TIER_DEFAULT; its code was read where a hits hunk makes a claim about it, never reviewed.

① Derived judgments

• Gate verdicts on this head: NONE. GET /commits/330e18be…/check-runs returns total_count: 0; the five check-suites (objectstack-fleet, claude, vercel, fly-io, cloudflare) are all queued, none concluded; the commit status is pending, 0 statuses. Every derived gate family (check:docs, check:authorable-surface, check:route-envelope, check:strictness-ledger, check:spec-parsed-alias, check-changeset-no-major, Type Check UI, the rest/spec/ui suites) is therefore UNMEASURED on this head as far as this record can see. The PR body's dispatch-gates --ran: 137 run, 0 UNRUN, all exit 0 is the dev's own account and is not adopted here. This record's verdict is on the contract alone; the queue guard still owes a green head before the arm (AGENTS.md: never arm a PR that isn't green yet). Named right as a condition, not a finding against the tree.
• Public surface, @objectstack/spec (api barrel): export * from './record-page.zod' adds 3 consts (RECORD_PAGE_MAX_RELATED, …_ROWS, …_SORT), 8 schemas with their z.input type and …Parsed alias (RecordPageExplainOperation, RecordPageRelatedRequest, RecordPageRequest, RecordPagePartRefusal, RecordPagePartError, RecordPageRelatedAnswer, RecordPageApprovals, RecordPageResponse). Grep of packages/spec/src for other RecordPage* exports: none, so the barrel re-export collides with nothing (the ui/ default-record-page module exports no such name). Regenerated artifacts match the source: 27 rows in api-surface, 27 in export-origins, 16 in declaration-map, 8 in json-schema.manifest, 28 authorable rows (every key of the 8 object schemas; RecordPageExplainOperation is an enum and has no key row), llms.txt 210 → 211 / api 31 → 32, strictness count 449 → 459 (ten z.object sites in the module: related request, its sort item, request, part refusal, part error, related answer, approvals, its lock, response, its explain block — counted and matched). Right. One schema in the module, RecordPageExplainAnswerSchema, is a module-private const and so has no row anywhere; see ④ should-fix 2.
• Accept set, request: the route parses the body with RecordPageRequestSchema (strict; nested related entry and sort item strict); explain admits only update|delete|transfer, a strict subset of ExplainOperationSchema on main (read, create, update, delete, transfer, restore, purge, export), so every admitted operation is one security.explain understands. top is int 0..50; the engine folds top into limit by presence (!= null, engine.ts fold; protocol.ts options.limit != null → pageWindowValue) and the page-window schema admits 0, and limit: 0 is "no rows" in the in-memory applier (driver-query-in-memory.ts header: limit: 0 returns no rows; protocol.page-window.test.ts: limit: 0, an empty page), so the described "0 returns the count alone" is what the tree does. sort[].order is the spec's one spelling (SortNodeSchema: direction is REJECTED by name, 一个被静默丢弃的排序键对外部调用方仍然是静默的:direction 该 400 还是继续被丢掉(#4674 第 4 项) #4721) and the route hands it to query.orderBy unchanged. Right.
• Accept set, query string: RECORD_PAGE_PARAMS = [], exported, and the handler opens with refuseUnknownQueryParams(req, res, RECORD_PAGE_PARAMS) after the capability gates (same order as GET /data/:object/:id). Both halves pinned in record-page-routes.test.ts (refusal: status, nested error.code, getData never called; preservation: the exact getData / findData arguments). Route & surface ownership 5: satisfied. Rule 1: no other registration of /:object/:id/page under packages/rest, packages/runtime, packages/plugins; it sits under :id like :id/clone and shadows no CRUD literal. Right.
• Wire surface: one new route POST /api/v1/data/:object/:id/page, in REST_ROUTE_LEDGER (disposition: sdk, client: data.recordPage, responseSchema: RecordPageResponseSchema), registered through RestServer#registerRecordPageEndpoints with a host interface like the other moved registrars, listed in REST_SERVER_REGISTRAR_FILES, declared in check-route-envelope.mjs MODULES with the data family's [tracking] Envelope-position convergence line for packages/rest's flat dialect — the live ratchet owner #9559 ratchet. Right. @objectstack/client: data.recordPage(object, id, request) and the two type re-exports. Right.
• Consumer surface, @object-ui/types: hand-mirrored RecordPageRequest / RecordPagePayload (the ui types package does not import @objectstack/spec, consistent with RecordFieldAccess beside it). Field for field they match the spec shapes; explain is a partial record of operation to unknown, looser than the spec union, which the console reads only through isRefused. Right (a mirror, not a contract).

② Semver level

• .changeset/27627-record-page-payload.md: @objectstack/spec, @objectstack/rest, @objectstack/client all minor. .changeset/27627-console-record-page-payload.md: @object-ui/types, @object-ui/data-objectstack, @object-ui/components, @object-ui/plugin-detail all minor. Every other moved package is private (@object-ui/app-shell "private": true, @objectstack/dogfood "private": true) or not a package (scripts/, content/docs, docs/audits). New exports and a new route on existing ones, nothing removed, renamed or retyped: minor is the floor the Metadata-protocol rule sets ("a kind takes at least minor on a package the diff moves") and the right level. Matches.
• Metadata-protocol: added on the PR body and both changesets: the authorable-surface/api.json shard gains 28 rows, which is exactly the mechanical reading of added the rule names (a new key an author can write); no existing row moves. Right, and consistent with the claim amendment 6507391490.
• Clause-②: line: PR body Clause-②: yes (widening); changeset 1 Clause-②: yes (widening: a new route and its request and response shapes; no existing route, key or answer changes); changeset 2 Clause-②: yes (widening: optional DataSource.getRecordPage / prefetchRecordPage, new exports; no existing contract changes). One arm from the closed pair, consistent across the three, and true of the diff (no narrowing anywhere in the hits files: no key refused, no default moved). Matches.

③ Boundary flags

• Dev flag, PR body: packages/spec/contracts/** (the card's named home for the two shapes) does not exist on main; the shapes went to packages/spec/src/api/record-page.zod.ts beside the other REST request/response shapes (protocol.zod.ts, batch.zod.ts). Answered: confirmed absent on main (ls packages/spec/contracts is no such directory); src/api is where every other REST shape the ledger names lives, and the generated artifacts, strictness ledger and llms.txt all key on src/api/*.zod.ts. Right placement; the card's contracts/** was a guess.
• Dev flag: Metadata-protocol: added measured for PR 1 although the claim named the app bundle (PR 2). Answered in ②: the api shard counts, so added is correct for this PR on its own.
• Dev flag: Skills-docs: none edited with check:skill-refs exit 0. The API skill's index reads schema files from the installed package, so a new module needs no row. Not re-run (read-only); accepted as the dev's measurement, and it is not a hits file.
• Dev flag: Server-Timing kept under the existing gate (OS_SERVER_TIMING=true or admin header) rather than opened to every caller, and Cache-Control / ETag left where they already answer. Card item 4 wants them on every response; the dev says that widening is a maintainer card. Escalated as a note to the epic seat, not a finding against this PR: the card's acceptance 2 (the cloud re-read "with Server-Timing in the PR body") is the epic seat's to run after landing, and nothing in the hits files turns on it.
• Card acceptance 2 and 3 (cloud re-read on huayan.objectos.app; console preview verified by the epic seat before ACCEPT) are not this record's to judge and remain open on the card.
• No open_questions block on the card or the PR. No other dev flags.

④ Design judgment

packages/spec/src/api/index.ts — one export * line, placed between batch.zod and http-cache.zod. No collision (checked above), no ordering rule in the barrel it breaks. Holds.

packages/spec/src/api/record-page.zod.ts — judged against the ruling it implements (card target 1: one request returns the record with populated lookups, each related list's count and first N rows, the caller's field access, the approval lock state, the record's explain verdicts for the header actions) and against its first consumers: the route (record-page-routes.ts), the client, and the console builder (recordPagePayload.ts). The module's header is the contract; each clause was checked against the live code it cites.

Holds, clause by clause:

• "the record is GET /data/{object}/{id}" — the route calls p.getData({object, id, expand?, …scope}) after enforceAuth + enforceApiAccess('get'), the same gates and call crud-routes.ts makes; GetDataRequest.expand is z.array(z.string()) on main, so expand: string[] passes straight through. record is z.record(z.string(), z.unknown()), the same typing GetDataResponseSchema.record has.
• "a related list is GET /data/{child} with that filter and $count" — findData on the child with { filter: parent AND declared, top, count: true, orderBy? }, after apiAccessDenialFromEnable(item.enable, child, 'list'), the operation the list route uses. filter is lowered through parseFilterAST, which is the list door's own lowering (AST array or object passthrough, comparand types normalised), so "the filter syntax GET /data/{object} accepts" is literally true; the console lowers through toFilterNode before sending and drops lists it cannot lower. The parent condition is compiled to the field's arity ($contains for isMultiValueField) and the declared filter is AND-composed, so it can only narrow, as described. The dogfood test compares count and rows against the separate $filter … $count=true read for a non-admin member under owner RLS and FLS.
• "fieldAccess is GET /data/{object}/{id}/field-access" — security.getRecordFieldAccess(object, id, context), with the same null → RECORD_NOT_FOUND, undefined → 501, no-function → 501 branches as data-action-routes.ts lines 376–394. The part reuses GetRecordFieldAccessResponseSchema itself, so the shape cannot drift from the replaced read.
• "explain is POST /security/explain with the record id" — security.explain({object, operation, recordId: id}, context), refusing an unidentified caller 401 with the explain route's own sentence (security-routes.ts line 171–176). The part reuses ExplainDecisionSchema. The three admitted operations are in ExplainOperationSchema.
• "approvals is GET /approvals/requests for the record plus the lock" — listRequests({object, recordId}, context) then getRecordLock(object, id, context); the pending row enriched by getRequest, which is what the console's useRecordApprovals did in a second request. The list route declares no response schema on main ("No request schema is declared for this door"), so requests: z.array(z.record(…)) is as tight as the replaced read is declared. The lock part { locked: boolean } | null matches the lock route's answer.
• "A record the caller cannot read refuses the whole request" — getData is awaited before any part; its throw reaches the catch, which relays mapDataError as crud-routes.ts does. Pinned in the unit test (no part asked) and in dogfood (page deep-equals the record read's 404 for a hidden row and a missing id).
• "a related list the caller may not read carries neither a count nor rows" — enforced by the route ({...head, error} only) and pinned in both suites. Not enforced by the schema; see should-fix 1.

Tried to break it:

• top: 0 through the real engine (a falsy-fold would return a full page): fold is by presence, page window admits 0, limit: 0 is an empty page. Holds.
• sort spelled order vs the engine's direction rejection: the spec's one spelling is order. Holds.
• explain: ['read'] or ['export']: refused by the enum before any read (pinned). Holds.
• A transfer ask on an object without a queue: the console only asks it when the object has a queue; the route answers whatever explain answers. Holds.
• Metadata before the record: the child items are loaded and invalid_relationship judged before getData, so a caller who passed enforceApiAccess('get') on the parent but cannot read the row gets a 400 about a child field instead of the record's 404. That reveals a child object's field relationship, which /meta/object/{child} already serves to the same caller; it says nothing about the row. Read, no finding.
• Fifty entries against a missing id cost fifty metadata reads before the 404: cost, not correctness; cached by the meta read gate. No finding.
• Union ambiguity: { error: {...} } fails GetRecordFieldAccessResponseSchema (required object, recordId, readable, editable, writable) and ExplainDecisionSchema (required allowed, object, operation, …), so each union resolves to one arm. Holds.
• .describe() on a lazySchema proxy (RecordPagePartRefusalSchema.describe(...)): the same pattern auth.zod.ts / automation-api.zod.ts use; the [finding] gen:openapi and gen:schema disagree about OS_EAGER_SCHEMAS, so a published artifact's bytes depend on which generator ran — and it already made a measuring instrument lie #19101 facade aliases metadata onto the proxy. Holds.

Findings:

• should-fix 1 — RecordPageRelatedAnswerSchema makes total, records and error all independently optional, so it admits {object, field} with nothing, and {object, field, total, error}, both of which the module header and the route forbid ("a refused list carries neither a count nor rows"). The sibling parts fieldAccess and approvals are published as z.union([answer, RecordPagePartErrorSchema]); the related answer should be the same union over {object, field, total, records} and {object, field, error} (or a .refine), so the published JSON Schema says what the contract says and a consumer generated from it cannot read a refused list as "0 rows". The wire is right today (the route builds one arm or the other); only the contract is loose.
• should-fix 2 — RecordPageResponseSchema.explain hand-lists update / delete / transfer beside RecordPageExplainOperationSchema, and RecordPageExplainAnswerSchema is a module-private const, the only schema in the module without a row in json-schema.manifest / declaration-map. Derive the answer object's keys from the enum's .options (one source for which operations exist) and export the answer schema, so the next operation added cannot land in the request and be dropped from the answer.
• should-fix 3 — RecordPageRelatedRequestSchema.filter is z.unknown() and the route lowers it inside the per-list try, so a declared filter parseFilterAST refuses (INVALID_FILTER 400 on the replaced read) answers as a part refusal with status: 400 inside a 200, while a malformed field is a located request-level 400 before any read. Both are request-shape faults; judge the filter beside invalid_relationship before the record read, or say in the field's describe that a malformed filter is carried as the list's refusal. Neither test suite drives a malformed declared filter.
• should-fix 4 — RecordPageApprovalsSchema.requests is described as "as GET /approvals/requests lists them", but when no approvals service is mounted the route answers {requests: [], lock: null} where the replaced reads answer 501 (respond501). The console reads a 501 there as "no lock service" so the behaviour is equivalent for its one consumer, and lock's description already says "null when the deployment answers no lock"; requests' description should say the same, or the part should carry a 501 refusal like fieldAccess does.

No must-fix. The schema is a faithful declaration of the ruling's one-request payload, every part reuses or mirrors the replaced read's declared shape, the strict request and empty query set hold the ingress rules, and the first consumers (route, client, console builder) read it as written.

Implemented-by: claude/project-thread-2m7jqd
Reviewed-by: session_01L6bhgV4fMGJHSdSdx3u9mK

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzgbJhFoXYsLSe5WSPP

Contract re-review requested on the new head · 2026-10-30T03:06Z

Record 6513269907 was FAIL on 392693230, with must-fix 3 (the dogfood consumer reads the related-answer union without narrowing it). The head is now 6f040ab5e, a fast-forward that touches only packages/qa/dogfood/test/record-page.dogfood.test.ts. That file now reads each part through rowsArm(i) and refusalArm(i). These narrow with 'total' in or 'error' in and fail the test on the wrong arm, with no cast. The seat asks for a fresh verdict on 392693230..6f040ab5e.

The dev reports exit 0 for these on this head: a workspace turbo run typecheck over all 73 packages the merge base's dependents list (142 tasks, dogfood included), the dogfood record-page and authz trio, and dispatch-gates --ran at 137/137. Body r3 maps must-fix 3 to its commit. The PR is still Tier H at 3257 lines.

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract-review-claim: session_01L6bhgV4fMGJHSdSdx3u9mK · head 6f040ab5e3679e2da44ed1695475fd6293d3a4ff · 2026-10-30T03:32Z

---

Generated by Claude Code

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 6f040ab5e3679e2da44ed1695475fd6293d3a4ff
Local-runs: none
Scope: packages/spec/src/api/index.ts, packages/spec/src/api/record-page.zod.ts + packages/qa/dogfood/test/record-page.dogfood.test.ts, packages/qa/dogfood/package.json (main), packages/qa/dogfood/tsconfig.json (main), packages/rest/src/record-page-routes.ts, packages/rest/src/record-page-routes.test.ts, packages/spec/src/api/record-page.test.ts, ui/packages/app-shell/src/views/recordPagePayload.ts, packages/client/src/index.ts, .changeset/27627-record-page-payload.md, .changeset/27627-console-record-page-payload.md, packages/spec/authorable-surface/api.json, packages/spec/api-surface/api.json, packages/spec/export-origins/api.json, packages/spec/declaration-map/api.json, packages/spec/json-schema.manifest/api.json

This is a delta record on the FAIL of record 6513269907 (head 392693230fbb4563b5a5e828a042bd4ce7bff30e), which stood on the FAIL of record 6512166649 (head 0efe2a4de2c4b3a9bad7cf162749de433f6f6fe9) and, through it, the PASS of record 6508117594 (head 330e18be1c57e05fbe6e661913bcb18a3c9fcf7b). Inputs read: card #27627 body and its three comments (6500767235, 6501011060, 6507391490); PR #27713 body (r3), its 48-file list and net diff against main from the files endpoint, and its eleven comments (6507869678 to 6514294354, the re-review request 6513960408 among them); the 70 check-runs on the head, read at 2026-10-30T03:35Z when every run had completed (61 success, 9 skipped, 0 failure; the last completed at 03:24:19Z), with the annotations of the three type-check runs; and locally git log / git diff between the two heads. The move is one commit, 6f040ab5e3 test(dogfood), whose single parent is 392693230f: a fast-forward, no merge, so there is no main carry-over to separate (the merge base with origin/main is ef359b9512 as before, the base the PR reports). It touches one file, packages/qa/dogfood/test/record-page.dogfood.test.ts, +18 / −6; the blob the files endpoint serves for that path (231c3808d1) is the blob at the local head. Neither hits file moved (git diff 392693230f..6f040ab5e3 -- packages/spec/ .changeset/ is empty), nor did a changeset, a generated artifact, a doc page or any rest, client or ui file. Sections and clauses the delta does not touch stand as judged in record 6513269907 and, through it, 6512166649 and 6508117594, named where so.

① Derived judgments

• Gate verdicts on this head: measured, and GREEN on every required context. Lint & Repo Gates, Build Core, Governed Surface Queue Guard, Build & E2E UI, Live E2E UI, Type Check UI, Lint UI, every Test Core shard 1/8 to 8/8 and the Test Core summary, every Test UI shard 1/16 to 16/16 and the Test UI summary, and TypeScript Type Check (completed 03:19:45Z) are success. TypeScript Type Check is green through all four of its lanes: Type Check · workspace (completed 03:19:40Z), Type Check · source gates, Type Check · consumer gates and Type Check · debt ledger, each success. The workspace lane's two annotations are both notice level and neither names a file (the remote-cache notice and the runner-image notice); no annotation names packages/qa/dogfood, no TS2339, no annotation at all on a source path. Nothing is in_progress or queued. Check Changeset is success. The nine skipped runs are the same nine the previous records counted (the opt-in harnesses, the dogfood shards and verify CLI, the temporal conformance, the published-artifacts job and the schedule gate), none of them a required context.
• Must-fix 3 of record 6513269907, the dogfood consumer of the two-arm union: discharged in the tree and on the gate that redded. Read at the head: line 88 still parses the answer with RecordPageResponseSchema.parse, so data.related[i] is the union of RecordPageRelatedRowsParsed ({ object; field; total; records }, strict, record-page.zod.ts 116–121) and RecordPageRelatedRefusalParsed ({ object; field; error }, strict, 126–130). Lines 97–106 add two helpers over that union: rowsArm(i) reads data.related[i], throws unless 'total' in part, and returns the narrowed value; refusalArm(i) does the same on 'error' in part. total is declared on the rows arm alone and error on the refusal arm alone, so each in test is a discriminating narrowing TypeScript performs on a union of object types, and the return type of each helper is the one arm. The six reads the record named are now rowsArm(0).total (113), rowsArm(0).records.map (114), rowsArm(0).records (115), rowsArm(1).total (122), rowsArm(1).records (123) and refusalArm(2).error (130); records is required on the rows arm (z.array(...), not optional), so dropping the ?. and the ?? [] of the old lines 102–103 is right, not a loosening. No cast is introduced: the file's two pre-existing as any casts (line 67 on the parsed body, line 136 on fieldAccess) are unchanged and outside the move. The @objectstack/dogfood program that measured the red (package.json typecheck = tsc --noEmit; tsconfig.json strict: true, include: ["test/**/*"], no noUncheckedIndexedAccess, so data.related[i] is the union and not the union-or-undefined) is the program Type Check · workspace runs, and it is success on the head with no diagnostic. Right.
• The fix is the one the record asked for, and it strengthens the test rather than bypassing the union. Record 6513269907 offered two fixes (narrow with 'total' in / 'error' in as the route test does, or parse each list through the arm schemas); the move takes the first. On the wrong arm the old lines would have read undefined and failed a toBe; the new helpers fail the test with a message naming which arm arrived and the part's JSON, so the refused ledger list (index 2) must now be the refusal arm and the two readable lists (0, 1) the rows arm, which is exactly the property should-fix 1 of 6508117594 made the schema state. The unchanged assertions around them keep the whole-shape pins: toEqual on the complete rows arm at 112 and 121, not.toHaveProperty('total' / 'records') at 128–129 on the refusal. Right.
• Public surface delta: none. @objectstack/spec did not move; the four spec artifacts, the strictness ledger count, the docs index and llms.txt are as record 6512166649 counted them. @objectstack/rest, @objectstack/client and every @object-ui/* package are byte-identical to 392693230f. @objectstack/dogfood is private ("private": true) and publishes nothing. Right.
• Nothing else moved. The one file of the delta is the one file must-fix 3 named; no file outside the review's findings is touched, and nothing the previous records judged (the request accept set, the two union arms, the explain keys, the API gate's context, the canonical QueryAST, the floors row and the 4 → 5 control, the ui re-exports, the merge resolution with perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636, quiet()) moved. Must-fixes 1 and 2 of 6512166649 and the Type Check UI item stand discharged as 6513269907 found them, and the gates they redded (Test Core (8/8), Type Check · workspace, Type Check UI) are green on this head too. Stands as judged in 6513269907.

② Semver level

• Unchanged from record 6513269907 and, through it, 6512166649 and 6508117594: @objectstack/spec, @objectstack/rest, @objectstack/client minor; @object-ui/types, @object-ui/data-objectstack, @object-ui/components, @object-ui/plugin-detail minor. The delta moves a test in a private package and publishes nothing. Metadata-protocol: added still holds (authorable shard +30 / −0 vs main, unchanged). The Clause-②: yes (widening) line on the PR body (r3) and both changesets is unchanged, one arm from the closed pair, consistent, and true of the diff. Check Changeset is success on the head. Matches.

③ Boundary flags

• The re-review request (6513960408) names one item: the dogfood test reads each part through rowsArm(i) / refusalArm(i), narrowing with 'total' in / 'error' in, failing on the wrong arm, with no cast, in a fast-forward touching only that file. Every clause is true of the tree (① above). The PR body's "Contract re-review must-fix" row 3 maps it to 6f040ab5e and to @objectstack/dogfood typecheck exit 0; the commit is the one, and the gate that runs that typecheck is green.
• Dev flag, PR body r3, "Correction to r2": the locked-suite table now lists turbo run typecheck over 73 packages / 142 tasks and @objectstack/dogfood typecheck as exit 0 on this head. The head's own TypeScript Type Check agrees on every lane, so the correction the previous record said r2 owed is made and is true of the tree. Adopted on this head because the gate measures it, not because the body says it.
• Dev flag, same table: the dogfood trio (record-page + authz-probe-blind-spot + authz-conformance) exit 0, 73 passed. The Dogfood Regression Gate shards are skipped on this head as on every earlier head, so the runtime behaviour of the new helpers (which arm each index receives) is the dev's own run, not a gate verdict; it is consistent with what the route builds (one arm per list, read in 6513269907 ①) and with the test's own unchanged whole-shape toEqual pins, and the type-level claim the must-fix was about is CI-measured. Named, not adopted as a gate verdict.
• The Server-Timing escalation, the card's acceptance 2 and 3 (the epic seat's cloud re-run and console verification before ACCEPT), the Tier H maintainer approval the body names, and the absence of an open_questions block stand as recorded in 6508117594 and 6513269907.

④ Design judgment

packages/spec/src/api/index.ts — unchanged in the delta and since 6508117594. Stands as judged there.

packages/spec/src/api/record-page.zod.ts — unchanged in the delta. Judged afresh against the one consumer the move changed:

Holds:

• The union of two strict arms (RecordPageRelatedAnswerSchema, lines 134–141: "its count and rows, or its refusal. Never both, and never neither, so a refused list cannot be read as an empty one") now compiles against every first consumer in the PR's own tree: the route builds one arm per list, the route test narrows with 'total' in r / 'error' in list, the console reads an arm by error presence, the client returns the type unread, and the end-to-end dogfood test narrows with 'total' in part / 'error' in part and fails on the wrong arm. The schema's discriminating members are exactly the ones every consumer narrows on, which is what makes the union usable without a tag field: total and records live only on the rows arm, error only on the refusal arm, and both arms are .strict(), so a wire value cannot carry both and parse. Holds.
• The header's "every part is the answer of the read it replaces, asked as the same caller", the one-declaration request shapes through @object-ui/types, and should-fixes 1–4 of 6508117594 stand as judged in 6513269907.

Tried to break should-fix 1's union against the changed consumer on THIS head:

• Could rowsArm admit a refusal? Only if total were present on the refusal arm; it is not declared there and the arm is strict, so a parsed refusal never has the key, and 'total' in part is false. Could refusalArm admit rows? Same by symmetry on error. Could an index out of range slip through? data.related[i] on the parsed array is typed as the union (no noUncheckedIndexedAccess), and a runtime undefined would throw on the in operator before any read, failing the test rather than passing it vacuously; the request names three lists and RecordPageResponseSchema requires related to be an array answered "one per requested related list", so the indices 0–2 are the request's own. The unchanged toEqual at 112 and 121 pins each rows arm whole against the separate list read's total and records, so the helpers add a check and remove none. Holds.

Read, no finding: the two pre-existing as any casts in the dogfood file (the response body at 67, fieldAccess at 136) predate the union, are outside the move and outside the hits files; data.explain?.[operation] at 142 reads the enum-keyed explain object the schema derives (explainAnswerShape), optional chaining right because explain is optional on the response.

No must-fix and no new should-fix on the hits files. Must-fix 3 of record 6513269907 is discharged on the head, in the tree and on the gate it redded (Type Check · workspace and its parent TypeScript Type Check are success, with no source annotation); must-fixes 1 and 2 of 6512166649 and the Type Check UI item stay discharged. The move adds nothing outside the review's findings and breaks nothing the previous records judged. Every required context on the head is green. The schema's union, the finding that drove the last two FAILs, is now honoured by every consumer that compiles against it.

Implemented-by: claude/project-thread-2m7jqd
Reviewed-by: session_01L6bhgV4fMGJHSdSdx3u9mK

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzgbJhFoXYsLSe5WSPP

Epic preview check waived by the maintainer · 2026-10-30T11:21Z

At 2026-10-30T11:19Z, the maintainer wrote in the project chat: 「27713 你正常审核落地就行」. That waives the epic #26676 seat's console-preview check that #27627's order put before the seat's ACCEPT (request 6514401576 on #26676). The PR now goes through the normal ACCEPT.

First, a blocker: main has moved 178 commits, and git merge-tree origin/main 6f040ab5e conflicts in ui/packages/data-objectstack/src/index.ts. The dev is merging main and rerunning the suites that merge touches. The seat will verify the merge with remerge-diff on top of contract review PASS 6514375644 and then post the ACCEPT. The PR is Tier H at 3257 lines, so it then waits on a maintainer approval.

[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzgbJhFoXYsLSe5WSPP

维护者速读 (席位终稿)

• 改了什么： 新增 POST /api/v1/data/{object}/{id}/page，一次请求返回记录详情页打开时要的全部数据：记录本身（含查找字段展开）、每个相关列表的总数和前几行、字段权限、审批状态与锁、页头按钮的权限判定。控制台记录页（整页、分栏、抽屉）改为只发这一个请求，再把各部分交给原来各自去取的组件；抽屉里预取下一条将要显示的记录。
• 为什么改： 以前打开一条记录要分两到三批串行请求（测试里冷启动 13 个分两批、热启动 8 个；HotCRM 浏览器实测 45 / 23 个；改后冷启动只剩 1 个数据请求加对象定义读取，热启动 1 个），每个相关列表还要单独发一次 top=1 计数探测，远距离部署下每批都要多等一个往返。
• 风险与回滚： 每一部分都是在服务端以同一调用者身份调用被替代请求的同一个函数，所以对象权限、行级安全、共享和字段级安全照旧生效；看不到的相关列表只带拒绝，不带总数也不带行。打开之后的刷新、写入后重读仍走各组件自己的请求。回滚 = revert 本 PR。
• 先看： packages/rest/src/record-page-routes.ts（每一部分调用哪个函数、父记录条件怎么拼）、packages/qa/dogfood/test/record-page.dogfood.test.ts（非管理员成员下与分开请求逐项对比）、ui/packages/app-shell/src/views/recordPagePayload.ts（页面要哪些列表、答案交给谁）。
• 两分钟验证： cd packages/qa/dogfood && pnpm exec vitest run test/record-page.dogfood.test.ts → 3 个用例绿：非管理员成员拿到的记录、相关总数与行、字段权限、判定、审批与分开请求一致，无权限的相关列表 403 且无总数无行。
• 需要你做的： 无。Tier H（3257 行），你已批准（os-zhuang，12:49Z）；席位核对合并后入队落地。

席位意见：接受。分诊契约复核在 6f040ab5e 上 PASS（6514375644），此前两轮 FAIL（6512166649、6513269907）的三条 must-fix 都已在树上关闭，四条 should-fix 也都已实现。之后 head 只因合并 main 移动，席位自己用 remerge-diff 核对了这次合并。维护者已豁免 epic 预览核验（「27713 你正常审核落地就行」），并已批准本 PR、授权入队（「27713 我批准了，你审核之后可以直接入队落地」）。

席位核对 · ACCEPT · domain:spec seat 3 · os-support-ai · session session_01WGufzgbJhFoXYsLSe5WSPP · 2026-10-30T14:02Z

Head: 780dd8c269a6c0659be12514d0430bfc31c32862 · card #27627 (PR 1 of 2, Part of) · claim 6501011060 (amended 6507391490)

1. 形态: a draft PR to main carrying Part of #27627. It has 48 paths (+3154 / −103), inside the claim's surface as amended. Clause-②: yes (widening) and Metadata-protocol: added, so every moved package is minor; check-changeset-no-major --event exit 0 on body r4. The PR has no governed paths, but it is over 3000 lines, so the landing tier is H.
2. 前提实测: the dev measured one record open before and after (body, "Request counts, before and after"). Before: 13 cold requests in two serial batches, 8 warm (HotCRM 45 / 23). After: 1 data request plus the object definition read cold, and 1 warm. The dogfood record-page test compares every part with the separate reads it replaces, as a non-admin member.
3. 门禁 check-runs (on this head): 66 latest runs: 57 success, 9 skipped, none red or pending. Dev-side on this head, all exit 0: build (116 tasks), ui data-objectstack, plugin-detail and RecordDetailView, check:spec-symbols, the ui type-check over CI's affected filter, rest typecheck, test and test:repo, the workspace typecheck over the merge base's dependents (74 packages), the dogfood record-page and authz trio, check:generated, and dispatch-gates --ran 137/137.
4. 接受的偏差: the head moved after PASS 6514375644 (6f040ab5e) by a main merge only (428642e58, plus the regen 780dd8c26). The seat verified the merge itself with git show --remerge-diff 428642e58. The one conflict, in ui/packages/data-objectstack/src/index.ts, keeps both sides: this PR's record-page fields and .clear() calls, and perf(console): opening a record re-reads no list, asks its field access once, and the bell polls once a minute #27907's field-access fields and prefix deletes. The regen restores main's rows that the textual merge had dropped. Each surface shard now holds every row main holds, plus exactly this PR's rows. git diff ba4ecf1d2 780dd8c26 is the same 48 files and +3154 / −103 as before the merge, and merge-tree against the current main is clean. The epic epic: record page v2 — one default open mode per object (drawer by default, page by declaration; modal / split / popover retired as metadata); the drawer and the page are one page at two widths; related records open in place #26676 preview check is waived by the maintainer (recorded in 6521437724).
5. 范围外去向: Seam: one request opens a record — a record-page payload (record + related counts and first rows + field access + lock) and an app-scoped metadata bundle, so a record open is 2–3 requests instead of 23–45 serialized in three stages #27627 PR 2 (metadata bundling) is not started. Spec seat 3 goes off duty after this lands, so PR 2 is released for the next seat. The deployment half is cloud#3378.
6. 落地条款: Tier H. The maintainer approved (os-zhuang, APPROVED, 2026-10-30 12:49Z), and that approval stands across the merge push. The maintainer authorized enqueueing in words. The seat readies the PR and arms auto-merge in this act, follows it to MERGED, then posts Landed on Seam: one request opens a record — a record-page payload (record + related counts and first rows + field access + lock) and an app-scoped metadata bundle, so a record open is 2–3 requests instead of 23–45 serialized in three stages #27627 (the card stays open for PR 2).

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract-review-claim: session_01L6bhgV4fMGJHSdSdx3u9mK · head 780dd8c269a6c0659be12514d0430bfc31c32862 · 2026-10-30T15:07Z

---

Generated by Claude Code

[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzgbJhFoXYsLSe5WSPP

Contract re-review requested: scoped to 780dd8c26..f66a0104b · 2026-10-30T15:09Z

The seat's ACCEPT (6524688486) was on 780dd8c26. The merge queue then dropped the PR on a conflict with #28129 (record pane v4). The head is now f66a0104b. A triage claim from 15:07Z names 780dd8c26, which is stale; please read the new head.

The delta is three first-parent commits:

1. 49204ce58 merges 277275aa4 (feat(ui): record pane v4 in the console — split by default, maximize in place, full page only from the row and the header menu #28129). The one conflict is the recordDrawerStack import line in RecordDetailView.tsx, resolved as the union (it adds useRecordPane beside RecordDrawerUpcomingContext). The seat checked it with git show --remerge-diff.
2. 722a37c5a, the only behaviour change. feat(ui): record pane v4 in the console — split by default, maximize in place, full page only from the row and the header menu #28129 turned RecordDrawerUpcomingContext from one {objectName, recordId} | null into a readonly RecordDrawerUpcoming[] carrying both neighbours. This PR's prefetch read upcoming.objectName, which merged textually but was always undefined, so the v4 pane prefetched nothing. The fix asks each neighbour's page once the current record's page has answered, keyed on the ids. A new case in RecordDetailView.recordPagePayload-27627.test.tsx covers it: opening c2 with neighbours [c3, c1] sends pages c2, c3 and c1 with no count probes, and a step to c1 asks only the new neighbours. The case is ablation-checked. One cost: each step re-asks the record just left, as one background request after the current page answers.
3. f66a0104b merges d70e94ae1, with no conflict and no generated shard moved.

The PR is now 3296 lines, still Tier H. The maintainer's approval (12:49Z) stands. Auto-merge is off until the seat re-ACCEPTs.

[objectstack-fleet]

triage#1 · os-sales · session_01L6bhgV4fMGJHSdSdx3u9mK

Contract review

Served-tier: CONTRACT_REVIEW_TIER
Head-sha: 780dd8c269a6c0659be12514d0430bfc31c32862
Local-runs: none
Scope: packages/spec/src/api/index.ts, packages/spec/src/api/record-page.zod.ts + packages/spec/api-surface/api.json, packages/spec/authorable-surface/api.json, packages/spec/export-origins/api.json, packages/spec/declaration-map/api.json, packages/spec/json-schema.manifest/api.json, packages/spec/llms.txt, docs/audits/2026-07-unknown-key-strictness-ledger.counts/api.md, ui/packages/data-objectstack/src/index.ts, packages/rest/src/rest-server.ts, packages/rest/src/record-page-routes.ts, packages/rest/src/rest-write-route-hook-refusal-sentence.ledger.test.ts, scripts/check-route-envelope.mjs, ui/packages/app-shell/src/views/RecordDetailView.tsx, ui/packages/plugin-detail/src/RelatedList.tsx, packages/spec/src/api/protocol.zod.ts (main), packages/spec/src/security/explain.zod.ts (main), packages/spec/src/shared/lazy-schema.ts (main), packages/rest/src/error-response.ts (main), packages/rest/src/security-routes.ts (main), packages/rest/src/approvals-routes.ts (main), packages/rest/src/data-action-routes.ts (main), packages/objectql/src/engine.ts (main), .changeset/27627-record-page-payload.md, .changeset/27627-console-record-page-payload.md

This is a delta record on the PASS of record 6514375644 (head 6f040ab5e3679e2da44ed1695475fd6293d3a4ff), which stood on the FAILs of 6513269907 (head 392693230fbb4563b5a5e828a042bd4ce7bff30e) and 6512166649 (head 0efe2a4de2c4b3a9bad7cf162749de433f6f6fe9) and, through them, the PASS of 6508117594 (head 330e18be1c57e05fbe6e661913bcb18a3c9fcf7b). Inputs read: card #27627 body and its four comments (6500767235, 6501011060, 6507391490, 6524721817); PR #27713 body (r4), its 48-file list and net diff against main from the files endpoint, and its fifteen comments (6507869678 to 6526043049, the seat's waiver note 6521437724 and its ACCEPT 6524688486 among them); the 71 check-runs on the head, read at 2026-10-30T15:08Z when every run had completed (62 success, 9 skipped, 0 failure, 0 in_progress; the last completed at 14:04:07Z), with the annotations of Type Check · workspace, Build Core, Lint & Repo Gates and Type Check UI; and locally git log / git diff between the two heads and between the two main bases, read-only. The move is two commits. The first, 428642e, merges origin/main at ba4ecf1d2fc4b04d475f279fcc44ea1a96a007c0 (178 commits past the old merge base ef359b9512) into the branch, with one text conflict. The second, the head, regenerates three spec surface shards (+5 / −0). Main's carry-over is separated from the PR's own change below by two measurements: the PR's own diff before and after the merge, and main's own diff on the files both sides touched. Sections and clauses the move does not touch stand as judged in record 6514375644 and, through it, 6513269907, 6512166649 and 6508117594, named where so.

① Derived judgments

• Gate verdicts on this head: measured, and GREEN on every required context. Lint & Repo Gates, Build Core, Build Docs, Build UI Deps, Governed Surface Queue Guard (both runs), Build & E2E UI, Live E2E UI, Type Check UI, Lint UI, every Test Core shard 1/8 to 8/8 and the Test Core summary, every Test UI shard 1/16 to 16/16 and the Test UI summary, TypeScript Type Check and its four lanes (Type Check · workspace, · source gates, · consumer gates, · debt ledger), every Lint · leg, Check Changeset (both runs), Validate Package Dependencies, Spec property liveness and Check Documentation Links are success. Every annotation read is notice level and names no source path (the remote-cache and runner-image notices). Nothing is in_progress or queued. The nine skipped runs are the opt-in harnesses, the dogfood shards and verify CLI, the temporal conformance, the published-artifacts job, the schedule gate, and the duplicate Auto Label / Check PR Size runs of the second workflow trigger; none is a required context. The three artifact gates the regeneration answers to run inside green jobs: check:authorable-surface and check:export-origins in Type Check · source gates, check:api-surface (reads the built dist) in Type Check · consumer gates.
• Merge-forward test: the PR's own change is byte-identical before and after the merge. git diff ef359b9512 6f040ab5e3 and git diff ba4ecf1d2f 780dd8c269 are both 48 files, +3154 / −103, and every added and every removed line of the two diffs is the same line, prose (content/, docs/, .md, .mdx) included. The only difference between the two diffs is context lines in ui/packages/data-objectstack/src/index.ts, where main's perf(console): opening a record re-reads no list, asks its field access once, and the bell polls once a minute #27907 members now sit beside the PR's hunks. The PR's file list on the files endpoint is the same 48 paths as record 6514375644 read, and the blob the endpoint serves for each hits file (2ddabca24d for index.ts, 160e306ec6 for record-page.zod.ts) is the blob at the local head. Right.
• Main's side is preserved on every file both sides touched. Seven files were changed by both main (old base to new base) and the PR: packages/rest/src/rest-server.ts, packages/rest/src/rest-write-route-hook-refusal-sentence.ledger.test.ts, packages/spec/llms.txt, scripts/check-route-envelope.mjs, ui/packages/app-shell/src/views/RecordDetailView.tsx, ui/packages/data-objectstack/src/index.ts, ui/packages/plugin-detail/src/RelatedList.tsx. On those seven, the diff from the PR's parent 6f040ab5e3 to the merge commit equals main's own diff ef359b9512..ba4ecf1d2f, added and removed lines alike. So the merge dropped nothing of main's in source, and added nothing of its own. Right.
• The one conflict, ui/packages/data-objectstack/src/index.ts, two hunks: resolved as a union of both sides, and read as right. Hunk 1 (the adapter's fields beside inflightFindOnes, head lines 3322–3343): the PR's inflightRecordPages / prefetchedRecordPages first, then main's perf(console): opening a record re-reads no list, asks its field access once, and the bell polls once a minute #27907 inflightFieldAccess / unansweredFieldAccess / fieldAccessUnsupported, each with its own comment. Hunk 2 (dropInflightReads, head lines 3965–3980): the PR's this.inflightRecordPages.clear() and this.prefetchedRecordPages.clear() on a write to ANY resource (a payload carries other objects' rows, so no write leaves it current), then main's prefix-keyed deletes on inflightFieldAccess and unansweredFieldAccess. The two rules do not compete: each map is dropped by the reason its own owner gives. shareInFlight is declared once (head line 3757), was on main at the old base already, and is used by the PR's getRecordPage (7352, 7354) and by main's rewritten getRecordFieldAccess (7312) alike; the PR's PREFETCHED_RECORD_PAGES constant and recordPageKey helper (1031, 1034) survive. Main's getRecordFieldAccess memory (a 404 record stays unanswered until a write, a 501 server is never asked again) never meets the page path: the console seeds the page's fieldAccess part through the reader (seedRecordFieldAccess), not through the adapter method, so a page-carried refusal is not written into unansweredFieldAccess, and a remembered 501 does not suppress a page read. Type Check UI, the data-objectstack suites in Test UI, and the card's acceptance test (RecordDetailView.recordPagePayload-27627.test.tsx) are green on the merged head. Right.
• The regenerated shards: the merge dropped exactly five of main's rows and the regeneration restores exactly those five. The merge commit against main is +3154 / −108 on the same 48 files: five lines short. The regen commit is +5 / −0: "ANALYTICS_CUBE_NAME_REQUIRED (const)" in api-surface/api.json, its origin row in export-origins/api.json, and the three disabledActions rows (GetMetaItemCachedResponse, GetMetaItemResponse, GetMetaItemsResponse) in authorable-surface/api.json. All five are present on main at ba4ecf1d2f (grep: 1, 1, 3), none is the PR's. Against main the head's shards differ by exactly the PR's rows: authorable-surface +30 / −0 (the thirty api/RecordPage*:* keys, listed and read; no other key), api-surface +36 / −0 and export-origins +36 / −0 (every added row is a RecordPage* name or one of the three RECORD_PAGE_MAX_* constants, origin src/api/record-page.zod.ts), declaration-map +22, json-schema.manifest +11, llms.txt 2 / 2 (210 → 211 schemas, api 31 → 32, "Record Page"), the strictness ledger 449 → 460. Main did not move declaration-map, json-schema.manifest or the ledger between the bases, so those stand as record 6512166649 counted them; the counts for the three regenerated shards are the counts that record read too. The surface gates that read all five shards are green. Right.
• The regeneration is the right remedy, not a hand patch. The os-regen driver merged three JSON shards one-sided (silently taking the branch's copy); a hand-added row would have been the same bytes but an unverifiable claim. The regen commit says it ran the generators (spec build, gen:export-origins, gen:schema, gen:api-surface), and check:authorable-surface, check:export-origins and check:api-surface on the head agree that the committed shards equal what the merged source generates. Adopted from the gates, not from the message.
• Public surface delta: unchanged from record 6512166649. @objectstack/spec publishes the same rows against main as before the merge (above); @objectstack/rest, @objectstack/client and every @object-ui/* package carry the same added and removed lines as at 6f040ab5e3. Main's own additions to those packages (for example disabledActions on the meta item responses in protocol.zod.ts, meta: GET /meta/object serves which packaged actions are switched off beside the item, and the disabled-action refusal reads as a plain sentence #27842) are main's, already published on main. Right.
• Nothing else moved. Outside the merge carry-over, the move touches the three regenerated shards and nothing else: no hits file, no changeset, no doc page, no rest, client or ui source line of the PR's own. Nothing the previous records judged (the request accept set, the two-arm related union, the derived explain keys, the API gate's five-argument call with the caller's context, the canonical QueryAST read with count: true, the floors row and the 4 → 5 slot control, the ui re-exports, the rowsArm / refusalArm dogfood narrowing, the perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636 resolution, quiet()) changed a line. Stands as judged in 6514375644.

② Semver level

• Unchanged from record 6514375644 and, through it, 6513269907, 6512166649 and 6508117594: @objectstack/spec, @objectstack/rest, @objectstack/client minor; @object-ui/types, @object-ui/data-objectstack, @object-ui/components, @object-ui/plugin-detail minor. The move publishes nothing new: the PR's lines against main are identical before and after the merge, and the regeneration restores main's rows. Metadata-protocol: added still holds (authorable shard +30 / −0 vs main, every added key a RecordPage* key). The Clause-②: yes (widening) line on the PR body (r4) and both changesets is unchanged, one arm from the closed pair, consistent, and true of the diff. Check Changeset is success on the head (both runs). Matches.

③ Boundary flags

• Dev flag, PR body r4, "Merge with main at ba4ecf1d2": one conflict, two hunks, both sides kept; the regen restores three disabledActions rows; shards differ from main by +36 / +30 / +36; check:generated exit 0; "Nothing else moved". Every clause is true of the tree (① above), with one count the body understates: the regen restores five rows, not three (the ANALYTICS_CUBE_NAME_REQUIRED row in two shards besides the three authorable rows). Right in substance; the body's own commit message names the three as "e.g.".
• Dev flag, same section: main's rewritten getRecordFieldAccess and the PR's getRecordPage / prefetchRecordPage / readRecordPage "do not overlap". Read as true at the head (① above): different maps, different drop rules, no shared key, and the console's open never calls getRecordFieldAccess.
• Dev flag, the locked-suite table "On 780dd8c26": build 116 tasks, ui data-objectstack and plugin-detail/app-shell suites, check:spec-symbols, ui type-check 107 tasks, rest typecheck / test / test:repo, turbo run typecheck 144 tasks, the dogfood trio 73 passed, check:generated, all exit 0. The CI equivalents are green on the head and adopted from the gates. The dogfood trio is not: the Dogfood Regression Gate shards are skipped on this head as on every earlier one, so the end-to-end comparison of each part against its separate read ON THE MERGED TREE is the dev's run alone. It is consistent with what the merged route still calls (④ below) and with the rest route tests that are CI-run, but it is named, not adopted as a gate verdict.
• Seat note 6521437724 and ACCEPT 6524688486: the maintainer waived the epic epic: record page v2 — one default open mode per object (drawer by default, page by declaration; modal / split / popover retired as metadata); the drawer and the page are one page at two widths; related records open in place #26676 console-preview check (the card's acceptance 3) in words, and approved the PR (os-zhuang, APPROVED, 12:49Z, submitted on 6f040ab5e, the head before the merge). Whether a review submitted on an earlier head counts after a merge push is repository policy, not a contract finding; named. The seat's ACCEPT read 66 runs (57 success) at 14:02Z; this record read 71 (62 success) at 15:08Z after the remaining runs completed, no verdict changed.
• Observed, not judged: at 15:10Z, after this review's claim (6526043049, 15:07Z), the PR's head moved again, to a later commit that this record does not cover: two further merges of origin/main (main is now at d70e94ae1db083f2ef136e0a65597b2de09fd35f, 50 commits past ba4ecf1d2f, and touches RecordDetailView.tsx among the PR's files) and one console commit titled "warm both neighbours' record pages in the v4 pane". The check-runs on that later head were in_progress when read. This record is a record of 780dd8c269a6c0659be12514d0430bfc31c32862 alone; the later head owes its own record, and the console commit is a functional change the review has not read.
• The shallow local clone cannot compute a merge against today's origin/main (the graph is cut below the new base), so the mergeability of this head against the moved main is read from nothing here; it is the lane's business at landing, not a contract finding.
• The Server-Timing escalation, the card's acceptance 2 (the epic seat's cloud re-run after landing), and the absence of an open_questions block stand as recorded in 6508117594, 6513269907 and 6514375644.

④ Design judgment

packages/spec/src/api/index.ts — unchanged in the delta and since 6508117594; the one added export line is the same line, and the surface shards that index it are regenerated on the merged tree with the same rows. Stands as judged there.

packages/spec/src/api/record-page.zod.ts — unchanged in the delta (blob 160e306ec6 at both heads). Judged afresh against the merged tree, because the code it cites moved under it by 178 commits:

Holds:

• Its four imports resolve to the same declarations: lazySchema (shared/lazy-schema.ts, unmoved on main), ExplainDecisionSchema (security/explain.zod.ts, unmoved), GetRecordFieldAccessResponseSchema (api/protocol.zod.ts, which main changed by 68 lines, all of them the disabledActions key on the three meta item responses, meta: GET /meta/object serves which packaged actions are switched off beside the item, and the disabled-action refusal reads as a plain sentence #27842; the field-access response block is byte-identical between the bases). The fieldAccess part is therefore still exactly the shape GET /data/{object}/{id}/field-access answers. Holds.
• "Every part is the answer of the read it replaces, asked as the same caller": the route at the head still calls getData after enforceApiAccess(req, res, p, environmentId, 'get', context) (line 119), findData with count: true (200–208), security.getRecordFieldAccess(object, id, context) (227), security.explain({ object, operation, recordId: id }, context) (253), svc.listRequests / svc.getRequest / svc.getRecordLock (266–276), and relays mapDataError(error, object) (77, 302). Each of the replaced doors moved on main, and none moved away from the route: security-routes.ts (security: POST /api/v1/security/explain with an empty object answers 500 EXPLAIN_FAILED, a malformed request answered as a server fault #27719) refuses an explicit empty object or userId at the HTTP door before evaluation, a refusal the page part cannot meet because its object is the path parameter and it names no userId, so the part equals the door's answer for the caller as before; approvals-routes.ts folds its request-404 into readableRequestOr404, a route-level helper over the same svc.getRequest the page part calls; error-response.ts (error codes: an undeclared hook onError abort answers the data door with a code-less 400; give it a ledgered ADR-0112 code (#27508 code half) #27597) changes resolveErrorResponse for a sandboxed hook refusal that declared no code, inside mapDataError, which the page route and GET /data/{object}/{id} share, so the two still answer the same bytes; engine.ts extracts its where lowering to engine-query-lowering.js without changing findData's where / limit / orderBy / count contract; data-action-routes.ts still exports ServerScopedDataRequest (168). Holds.
• The child exposure gate still judges the object the data call serves. Main's rest: the cross-object POST /batch per-op exposure gate keys objects by name, so a legacy ns__short object addressed by its short name keeps the pass-through #27728/#27729 closed on the /data routes #27899 (rest-server.ts) replaced loadObjectItems with a private loadObjectItem(p, environmentId, name) that reads by name first (so a legacy ns__short object resolves as registry.getObject does) and made enforceApiAccess use it. The PR's host inlines the identical body for loadObjectItem (the metaListSource + objectItemReader + metaReadGate.loadObjectItem read), so the related list's child gate and the record's enforceApiAccess gate read the same object by the same rule on the merged tree. The duplication is a tidy-up for the lane (call the new private method), outside the hits files and not a finding here. Holds.
• The two-arm related union, the derived explain keys, the one-declaration request shapes through @object-ui/types, and should-fixes 1–4 of 6508117594 stand as judged in 6513269907 and 6514375644; no consumer of the schema moved in the delta, and the consumers main co-touched (RecordDetailView.tsx, RelatedList.tsx) kept every PR line and every main line, with the card's acceptance test and perf(plugin-detail,app-shell): the record page's related column loads counts first, then rows only for the cards in view, and never blocks the details #27636's four suites green in Test UI.

Tried to break the schema against the merged tree:

• Could main's adapter memory turn a page-carried fieldAccess refusal into a remembered 404 or 501 for the record? No: the memory is written only inside getRecordFieldAccess's own catch (head 7319, 7326), and the page path never enters that method. Could a remembered 501 (fieldAccessUnsupported) stop a page from being asked? No: getRecordPage consults neither flag. Could a write to one resource leave a stale prefetched page of another? No: both page maps are cleared on any write (3970–3971), as the PR's own rule says, while main's maps drop by prefix, each by its owner's reason. Holds.
• Could the regeneration have reordered or dropped a RecordPage* row so a shard no longer matches the source? check:authorable-surface, check:export-origins and check:api-surface are green on the head, and the thirty authorable keys read against main are the thirty record 6512166649 read. Holds.
• Could main's new disabledActions rows have been the PR's responsibility to carry? No: they are main's (meta: GET /meta/object serves which packaged actions are switched off beside the item, and the disabled-action refusal reads as a plain sentence #27842), present on main at ba4ecf1d2f, and the regen restores them beside the PR's rows exactly where a clean merge would have left them. Holds.

Read, no finding: scripts/check-route-envelope.mjs and the hook-refusal ledger test carry both main's and the PR's rows after the merge (the PR's MODULES row for record-page-routes.ts and main's additions coexist; Lint & Repo Gates and Test Core are green); llms.txt carries main's two-line edit and the PR's two counts.

No must-fix and no new should-fix on the hits files. The move is a merge of origin/main whose conflict resolution keeps both sides whole and whose regeneration restores exactly what the driver dropped; the PR's own diff against main is the same 3154 added and 103 removed lines as at 6f040ab5e3, prose included. It adds nothing outside the review's findings and breaks nothing the previous records judged. Every required context on the head is green. The later head pushed after this review's claim is not covered by this record.

Implemented-by: claude/project-thread-2m7jqd
Reviewed-by: session_01L6bhgV4fMGJHSdSdx3u9mK

VERDICT: PASS

---

Generated by Claude Code

[objectstack-fleet]

domain:spec#3 · os-support-ai · session_01WGufzgbJhFoXYsLSe5WSPP

席位核对 · ACCEPT (re-issued on the new head) · domain:spec seat 3 · os-support-ai · session session_01WGufzgbJhFoXYsLSe5WSPP · 2026-10-30T18:32Z

Head: f66a0104b6d18598f4132bcc629f66d551d0a244 · card #27627 (PR 1 of 2) · supersedes ACCEPT 6524688486 (on 780dd8c26)

席位意见：接受。合并 #28129（record pane v4）后，抽屉预取邻居记录的逻辑静默失效，开发已修复并补了测试；席位自己核对了这段增量，不影响契约面。

1. 形态: unchanged from 6524688486, apart from size: 3296 lines, Tier H, Clause-②: yes (widening), Metadata-protocol: added, every moved package minor. check-changeset-no-major --event exit 0 on body r5.
2. 契约复核: triage's PASS 6526284371 covers 780dd8c26, where the PR's diff against main was unchanged from PASS 6514375644. The delta 780dd8c26..f66a0104b touches none of the reviewed contract files (record-page.zod.ts, the route, the request shapes). It is two main merges plus one ui consumer fix, so the seat verified it under the head-move rule:
   • 49204ce58 merges feat(ui): record pane v4 in the console — split by default, maximize in place, full page only from the row and the header menu #28129. git show --remerge-diff shows one conflicted import line in RecordDetailView.tsx, resolved as the union.
   • 722a37c5a adapts the prefetch to feat(ui): record pane v4 in the console — split by default, maximize in place, full page only from the row and the header menu #28129's RecordDrawerUpcomingContext, which is now an array of both neighbours. It filters to the same object, keys on the ids' content, and asks each neighbour's page after this record's page answers. The new test case pins it, and the ablation goes red with one neighbour. The cost is one background request per step, named in the body.
   • f66a0104b merges d70e94ae1 with no conflict.
     The open re-review request (6526086727) stays on the PR, so a later verdict can still read this delta.
3. 门禁: CI on this head: 71 runs, all success or skipped. Dev-side on this head, all exit 0: turbo build, ui data-objectstack, plugin-detail plus the whole app-shell (20795 passed), check:spec-symbols, ui type-check, rest typecheck, test and test:repo, the workspace typecheck over 74 dependents, the dogfood trio, and dispatch-gates --ran 137/137.
4. 批准: os-zhuang's APPROVED (12:49Z) stands on this PR. The maintainer authorized enqueueing in words (「27713 我批准了，你审核之后可以直接入队落地」).
5. 落地条款: the seat arms auto-merge in this act, follows the PR to MERGED, then posts Landed on Seam: one request opens a record — a record-page payload (record + related counts and first rows + field access + lock) and an app-scoped metadata bundle, so a record open is 2–3 requests instead of 23–45 serialized in three stages #27627. The card stays open for PR 2, which is not started and is released for the next seat.