[objectstack-fleet]

Requested by Warren · project thread

Refs #29398 (item 2)

Clause-②: no
Metadata-protocol: none

维护者速读

• 改了什么:组织成员数达到 1,000 时,解析器会先读一次 1,000 行、再按 id 分页读完整成员;现在两次读的结果取并集,而不是用第二次的结果替换第一次。
• 为什么改:若补全读看到的成员比第一次少(另一连接上的旧快照),同组织成员列表 org_user_ids 会比第一次读本身还短,这些成员在普通成员的 sys_user 读取里悄悄消失。
• 风险与回滚:两次读都按当前组织过滤,并集不会加入组织外的人;不增加也不改变任何读;回滚即 revert 本 PR。
• 先看:packages/core/src/security/resolve-authz-context.ts 第 5 步(orgMembers 的并集一行),再看同目录 resolve-authz-context.org-members-past-first-read.test.ts 的新用例。
• 两分钟验证:pnpm --filter @objectstack/core exec vitest run src/security/resolve-authz-context.org-members-past-first-read.test.ts,预期 9/9 通过。
• 需要你做的:无,席位落地。卡的第 1 项(按 id 顺序的逐页校验)不在本 PR,卡保持打开,见 Acceptance notes。

What changes

resolveUserAuthzGrants step 5 builds org_user_ids from Leg 1's sys_member read (orgMembersLeg, bounded at 1,000 rows). When that read comes back at its bound, readOrganizationMembersToCompletion reads the whole membership in id order. Its rows used to replace orgMembersLeg. They are now unioned with it, so a completion that sees fewer members than Leg 1 already held cannot shorten the list. Both reads filter on the active organization, so the union adds nobody outside it. No read is added, removed or changed, and the batch-equivalence goldens do not move.

One patch changeset for @objectstack/core.

Why

This is item 2 of the card: a completion that answers from an older snapshot on another connection returned a shorter list than the first read alone. Item 1 (the per-page order check) is held back. The Acceptance notes say why.

Tests

• New case in resolve-authz-context.org-members-past-first-read.test.ts: 1,005 members, and the completion's ordered reads cannot see five members the unordered first read returned. Every one of the five, and the whole membership, is still in org_user_ids, and nobody from the other organization is.
• The fake driver gains staleForOrderedReads, a set of user ids that its ordered sys_member reads (the completion's) do not return.

Ablation (head 3c6ddc2)

The union was reverted on disk with scripts/ablation-replace.mjs: anchor [...orgMembersLeg, ...await changed to [...await (anchor x1 to x0, replacement x0 to x1, blob c3eddd26 to 93bebcf0). The test imports the resolver from src/, so no build is involved.

• Mutated: Tests 1 failed | 8 passed (9). The new case is the only red: expected [ 'u000000', 'u000884', …(998) ] to include 'u000001'.
• Restored: blob back to c3eddd26, equal to HEAD, and git diff HEAD is empty.

Suites (head 3c6ddc2)

• pnpm --filter @objectstack/core test: Test Files 131 passed (131), Tests 2927 passed (2927).
• pnpm --filter @objectstack/core typecheck: exit 0.
• The past-first-read suite plus the batch-equivalence suite: Test Files 2 passed (2), Tests 45 passed (45).

Verification

Gates (head 3c6ddc2)

• node scripts/pm/dispatch-gates.mjs --commands derived 61 commands. All were run locally, exit codes were captured before any pipe, and --ran reconciled them: 61 derived, 60 run, 1 NOT-MEASURED, 0 UNRUN.
• pnpm check:dual-build-cjs-loads exited 3 (PREREQUISITE NOT MET, it needs every package built). It is NOT MEASURED locally and left to CI.
• check-plugin-teardown-shape --self-test passed after git fetch --unshallow (its fixture is pinned to an old commit). check:lean-entry-closure passed after building @objectstack/objectql.
• pnpm lint exited 0.

Acceptance notes

Item 1 of the card is held back, as the seat ruled. The card's suggested per-page check ("each id strictly greater than the row before it") would compare ids in JavaScript code-point order. driver-sql emits a plain ORDER BY id and id > ?, so the database collation decides the order. The keyset itself is sound under any collation, because the cursor and the order use the same comparison. A JavaScript check would not be. Measured on a local PostgreSQL 16, sorting seven nanoid-shaped values:

• C.UTF-8 database: AC Ab9 B-2 a-c aB3 ab b_1, which matches JavaScript.
• ICU en-US database (CREATE DATABASE ... LOCALE_PROVIDER icu ICU_LOCALE 'en-US'): a-c ab aB3 Ab9 AC b_1 B-2.

Member ids are mixed-case (nanoid in the drivers, better-auth's generator through plugin-auth). On such a database, every correctly ordered completion page would fail the check, and every request in an organization past the first read's bound would get a 503. MySQL's default utf8mb4_0900_ai_ci collation is case-insensitive and differs from code-point order in the same way (not measured here). Collation-safe designs are left on the card for a decision.

Human Minimum

• 1. Schemas start as Zod; packages/spec holds no runtime logic. (No spec change.)
• 2. Every name I added uses the casing for its kind.
• 3. No formatter ran; pnpm lint passes.
• 4. One issue, one branch off an up-to-date main, one pull request.
• 5. A change that publishes carries a changeset, and both declaration lines are filled in here and in the changeset.
• 6. packages/spec touched: n/a.
• 7. No hand edits to content/docs/references/, packages/*/CHANGELOG.md or content/docs/releases/.
• 8. Title, body and comments are in English.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/core, touching 1 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/deployment/environment-variables.mdx (via resolveUserAuthzGrants (symbol, a top-level function))

⛔ 3 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v16.mdx (via resolveUserAuthzGrants (symbol, a top-level function))
• content/docs/releases/v17/17-1.mdx (via resolveUserAuthzGrants (symbol, a top-level function))
• content/docs/releases/v17/17-5.mdx (via resolveUserAuthzGrants (symbol, a top-level function))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 60 of 216 client-bound route-ledger rows — the other 156 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 156: 0 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 55 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 101 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.
• a key NAME is not a key, so the hand re-read the line above prescribes can land on the wrong schema. The same spelling is authorable on one governed type and a [REMOVED] tombstone on another for each of active, aria, joins, objects, template, tools and version (censused on [finding] tools is a key on BOTH AgentSchema (tombstoned, dead) and SkillSchema (live, cloud-attested), so a name-based search attributes skill examples to the agent key — it produced a false stop-the-line alarm on PR #19059 #19093 over the liveness ledger's governed types, top-level keys); nothing in a search result distinguishes the two, so a grep hit on a LIVE example reads as evidence about the DEAD key. Measured on fix(spec): the agent.tools liveness row says dead — it claimed live on a key the schema tombstoned #19059: content/docs/ai/agents.mdx was reported as contradicting the agent.tools tombstone over its tools: example at :161, which is inside the defineSkill({ block opened at :155 — the page was already correct. Settle ownership by PARSING the value against both schemas, never by the name: that literal PASSES SkillSchema, and as an AgentSchema it FAILS at tools with the tombstone prescription. ⛔ These names are not the whole class — a key retired through a .strict() guidance map leaves no tombstone in the walked shape and none of them here (tool.category, live as AIToolDefinition.category).

Coarse fallback — 39 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 390bd2aedca2aa46776ae52380eb11577f2bea87 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b4feaf631e5f399ccc0011243c82bf3605e24078 — the merge of head 3c6ddc2d6426939732bf0afadcdc865313bb5b96 into base 390bd2aedca2aa46776ae52380eb11577f2bea87, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b4feaf631e5f399ccc0011243c82bf3605e24078 && git checkout b4feaf631e5f399ccc0011243c82bf3605e24078
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 390bd2aedca2aa46776ae52380eb11577f2bea87 3c6ddc2d6426939732bf0afadcdc865313bb5b96 && git checkout -B drift-repro 390bd2aedca2aa46776ae52380eb11577f2bea87 && git merge --no-ff 3c6ddc2d6426939732bf0afadcdc865313bb5b96

node scripts/docs-audit/affected-docs.mjs --json 390bd2aedca2aa46776ae52380eb11577f2bea87

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 390bd2aedca2aa46776ae52380eb11577f2bea87 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[objectstack-fleet]

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

席位核对

ACCEPT · domain:server#4 · head 3c6ddc2d6426939732bf0afadcdc865313bb5b96 · 2026-11-02T18:47Z · seat review of record at TIER_DEFAULT (not governed: check-governed-merges --pr 29545 0 of 3 paths; Clause-②: no; no packages/spec path)

1. Shape: draft, base main, body line 3 Refs #29398 (item 2) with no closing keyword anywhere in the body (scanned), so the card stays open for item 1. 3 files, +43/-3: one patch changeset for @objectstack/core (declaration lines present), the resolver's step 5, one test file. Seat read the diff: the completion's rows are unioned with orgMembersLeg; both reads filter { organization_id: tenantId } on origin/main (Leg 1 at tryFind(ql, 'sys_member', { organization_id: tenantId }, ORG_MEMBERS_FIRST_READ_ROWS); completion where = { organization_id, id: { $gt } }), and the ids pass through a Set, so the union adds no non-member and no duplicate.
2. Premise measured: item 2 holds (replace at resolve-authz-context.ts L1926-1928 on 399df5bb). Item 1's routed fix is falsified by the dev's measurement (report 6584978670): a JavaScript strictly-increasing id check uses code-point order while driver-sql orders by database collation; PostgreSQL 16 ICU en-US sorts mixed-case nanoid ids differently from C.UTF-8. The seat's dispatch order suggested that route; the seat accepts the correction and held item 1 back (route A).
3. Gates on this head: check-runs pinned to 3c6ddc2d: 63 total, 54 success, 9 skipped, 0 failed; Lint & Repo Gates success, TypeScript Type Check success. mergeable_state clean. Dev local: dispatch-gates --ran 61 derived / 60 run / 1 NOT MEASURED (check:dual-build-cjs-loads, covered by CI), pnpm lint 0, core 2927/2927.
4. Accepted deviations: item 1 not shipped (seat's ruling, above). Ablation reds only the new case (1 failed / 8 passed) and the restore equals HEAD.
5. Out of scope: item 1 (collation-safe order check) stays on core/security: the org-members completion read trusts the driver's orderBy and replaces the first read's rows, so a driver that drops the order, or a completion that sees fewer rows, can shorten org_user_ids silently #29398; the card returns to pm:queue at landing with the measurement as its premise. Skills-docs: n/a (Metadata-protocol: none).
6. Landing: not governed, under 3000 lines ⇒ the seat lands it (pr_ready + automerge_enable). At MERGED: landing record on core/security: the org-members completion read trusts the driver's orderBy and replaces the first read's rows, so a driver that drops the order, or a completion that sees fewer rows, can shorten org_user_ids silently #29398, Release: with item 1 named as the remainder, pm:dispatched → pm:queue, assignee cleared.

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 41505292716 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

分类：failure —— 按下面的日志分诊。

失败的 job（日志抽取，best effort）：

• Test Core (2/8) — 失败步骤: Run this shard's tests

  @objectstack/spec:test:repo:  FAIL   repo  scripts/strictness-ledger-doc.test.ts > the ledger and the generated counts agree > is checked in current — every shard on disk equals a fresh render, and no
    ↳ 失败原因: @objectstack/spec:test:repo: AssertionError: expected Map{ …(14) } to deeply equal Map{ …(14) }
  @objectstack/spec:test:repo:  FAIL   repo  scripts/strictness-ledger-doc.test.ts > the ledger and the generated counts agree > the read-time totals equal the sums of the shards' own rows
    ↳ 失败原因: @objectstack/spec:test:repo: AssertionError: expected 'untriaged: 1298 object site(s) across…' to be 'untriaged: 1297 object site(s) across…' // Object.is equality
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

⚠️ 断言这一侧有一类例外，判据是断言在测什么，不是它是不是 AssertionError。 断言的对象是产品行为（一个值、一个形状、一次拒收）⇒ 照上面读：真实的行为改变，去查，⛔ 不要重排掉；
断言的对象是这次实验自身的有效性前提（跑完的耗时、负载下的先后、任何只在时间预算内才成立的条件）⇒ 它跟超时是同一类，同样对负载敏感，重排一次是合法的判别手段。
识别是机械的：断言的消息或它比较的值本身点名了一段时长、一个时间戳、一个耗时计数。实测过的一对 —— AssertionError: SecurityPlugin.init() ran: expected false to be true 测的是产品行为（真回归）；
AssertionError: this run took over a second, so second-precision stamps could have differed too: expected 1006 to be less than 1000 测的是实验前提：它守护的那条不变式当时是绿的，同一个 head 原样重排一次即成功。
穿着 AssertionError 外衣的时间测量，仍然是时间测量。（⛔ 这只改「怎么读一次红」，不改「哪些测试可以重排」——后者由别处管。）

跨 PR 相同签名（24h，按失败测试文件聚合）：

• scripts/strictness-ledger-doc.test.ts — 24h 内已弹出 18 个 PR（feat(spec): declare the whole-deployment export, every installed package as installable packages in one read (PackageExportBundleSchema) #29100、feat(spec): push channel protocol face — device registration widening, stored device shape, device contract members, push route, APNs/FCM config by credentialRef #29218、fix(spec)!: refuse a dashboard globalFilters entry keyed dateRange beside a declared dateRange #29370、fix(spec)!: a datasource named drivers is refused at every door that parses a datasource #29423、feat(spec): a record page can name the apps whose routes open it (PageSchema.apps) #29437、docs(spec): tenancy-posture prose says which side of the open/commercial split gates activation #29454、feat(spec): declare features.sso on the auth config response #29455、feat(lint)!: os lint refuses a flow region the engine refuses to register (flow-region-shape-invalid) #29495、build(turbo): hash the Service Worker generator into the Console's build and type-check only #29504、fix(pm): the relay reads no runner 403 as the egress proxy's, and a refused advisory row names its cause #29505、fix(cli): os migrate organization-ownership --apply carries a public-form withdrawal onto a read-only package view into its .custom pair, declared #29508、docs(spec): the disabledActions description names Setup › Packaged Actions, not the retired Packaged automation page #29511、docs(spec): TOP_LEVEL_COLLECTIONS_NEVER_RESIDUAL names the readers of top-level datasets the tree has #29514、feat(pm): a ruled decision card still in the box is a patrol row, and the director's ruling lands with its knock #29515、feat(spec): the package export manifest declares withheldMaps, classified door for the unmanaged import #29521、docs(spec): email.defaultTemplateContext names baseUrl beside appName as a resolved key #29539、fix(core): the fellow-org peer list keeps every member the first membership read returned #29545、refactor(metadata-protocol): move the metadata list reads, the audit read and the UI-view read through the protocol host (#25467 E2 cut 1a) #29548），分属 2 条投机栈 ⇒ 2 次独立命中。汇总 issue：Queue-flake anchor: scripts/strictness-ledger-doc.test.ts #29524（已刷新）
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 36 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)

[objectstack-fleet]

domain:server#4 · os-warren · session_01JQwxbacSXJQqAztgt4UMrS

Queue ejection disposition · 2026-11-02T19:24Z · head 3c6ddc2d unchanged

• Signature: queue build 41505292716, Test Core (2/8), @objectstack/spec scripts/strictness-ledger-doc.test.ts (untriaged: 1298 vs 1297), triage comment 6586270048.
• Ledger: known signature, anchor Queue-flake anchor: scripts/strictness-ledger-doc.test.ts #29524; triage 6584739175 reads it as two ledger-regenerating PRs stacked in one queue window, not a flake and not a reader of this diff.
• Not this PR's: this diff touches packages/core/src/security/resolve-authz-context.ts, its test and a core changeset; nothing under packages/spec and no generated ledger.
• Action: re-armed once (automerge_enable) on the same head. If the same signature ejects it again the seat stops and waits for Queue-flake anchor: scripts/strictness-ledger-doc.test.ts #29524's fix rather than re-queue.