plugin-security: the first-user promotion picks the oldest authenticable user from an UNORDERED 50-row `sys_user` window, so on the default driver a seeded job seeker became platform admin and owned every seeded row

[os-sam]

Measured on @objectstack/plugin-security 17.3.0 while building an app on the platform (tracked there as objectstack-ai/ats#40; the app's own card notes it could not verify upstream write access, so I am relaying it with the source verified here).

This is not #11979. That card is the Choice-4B design follow-up — config-anchor the single posture, first-user promotion becomes development-only — and it is pm:blocked behind a transitive chain (#11978 → #11975 → #13515). This is a defect in the selection as it ships under 4A today, and it survives 4B: development-mode single keeps first-user promotion, and it would keep selecting the same wrong way.

It is also the next failure of the function #14348 last repaired. That card fixed "promotes a row nobody can log in as" by requiring a sys_account. Once an app seeds credentials — which #14348's own fix invites — the requirement is satisfied by many users, and which one wins is decided by something nobody chose.

The selection

packages/plugins/plugin-security/src/bootstrap-platform-admin.ts:571

const allUsers = await tryFind(ql, 'sys_user', {}, 50);
const humanUsers = allUsers.filter(isHumanUser);
…
const target = await oldestAuthenticable(ql, humanUsers);

and oldestAuthenticable (:557-564) sorts that array:

const oldestAuthenticable = async (ql2: any, users: any[]): Promise<any | undefined> => {
  const byAge = [...users].sort(byCreatedAtAsc);
  for (const user of byAge) { … }

The read has no order and a cap of 50. So "the oldest authenticable user" is really the oldest authenticable user among whatever 50 rows the driver happened to return first. With more than 50 users the intended target may not be in the window at all, and the client-side sort cannot notice — it sorts a sample and reports a global answer.

The comment above the read explains the posture decision carefully and the constant 50 passes without remark.

Measured harm

Same artifact, OS_PLATFORM_OWNER_EMAIL=admin@objectos.ai set, 113 seeded sys_user rows of which 7 carry credentials, the intended owner inserted first:

driver	what fills the 50-row window	promoted
memory	insertion order — owner is row 1	admin@objectos.ai ✅
sqlite (the default)	id order — usr_ats_c01 … usr_ats_c50; the owner is not in the window at all	candidate01@mail.example ❌

Verbatim from the sqlite boot:

[security] first user promoted to platform admin: candidate01@mail.example

A job-seeker persona received the unscoped admin_full_access grant, and claimSeedOwnership then handed it ownership of every seeded business row. Same code, same config, same data — the answer changed with the storage driver.

The configured owner is right there and this path never asks

PLATFORM_OWNER_EMAIL_ENV is imported into this very file (:73) and used at :447-480 — but only on the walled branch. The single branch at :571 does not consult it. So a deployment that has declared who the owner is can still have someone else promoted, which is the part that turns a nondeterminism bug into a security one.

Three fixes, cheapest first

1. Order server-side and drop the cap — tryFind(ql, 'sys_user', {}, …) with an order on created_at ascending, so the sort is over all users rather than a sample. Smallest change; makes the result driver-independent; does not alter the policy.
2. Prefer the declared owner when one is registered, before falling back to oldest-authenticable. The anchor already exists and is already imported in this file — this is the fix that makes the promotion match what the operator asked for.
3. What platform-admin re-anchor follow-up (Choice 4B): config-anchor the single posture — first-user promotion becomes development-only fallback #11979 rules, when it unblocks.

(1) and (2) are worth doing regardless of when (3) lands, because (3) explicitly preserves first-user promotion for development.

Suggested regression test

Seed more than 50 users where the intended owner sorts last by id and first by created_at, and assert the same user is promoted on the memory and sqlite drivers. That is the shape that fails today and the shape a client-side sort over a capped window cannot pass.

What the app did meanwhile, and why it is not a fix

It pinned the owner row to win under every ordering at once — id usr_ats_0_owner (collates before every other id), inserted first, created_at a year older than everyone. Re-measured green on both drivers. That is a seed working around a rule it should not have to know, and it holds only while no other seeded user sorts first on all three axes.

[os-zhuang]

分诊：domain:services / bug / security / priority:p1 / pm:queue / type Bug

车道：packages/plugins/plugin-security —— 车道表 domain:services 行。

复核（origin/main 5e53d73d）：三处全中，行号未漂

bootstrap-platform-admin.ts:571   const allUsers = await tryFind(ql, 'sys_user', {}, 50);   ← 无 order，cap 50
bootstrap-platform-admin.ts:557   const byAge = [...users].sort(byCreatedAtAsc);            ← 客户端排序
bootstrap-platform-admin.ts:73    import { PLATFORM_OWNER_EMAIL_ENV, … } from '@objectstack/types';
bootstrap-platform-admin.ts:447/:451/:480   ← 三处使用，全部在 walled 分支

⭐ 一处卡面没提、但让这个 bug 更难辩护的对照，就在同一个函数里：

bootstrap-platform-admin.ts:426   const holderRows = await tryFind(ql, 'sys_user', { id: holder.user_id }, 1);

同一个文件、同一个 tryFind，在 :426 用的是精确谓词 + cap 1。⇒ 这不是"作者不知道怎么精确查"，是 :571 那一处恰好写松了。而卡面指出的那件事在这个对照下更刺眼：:571 上方的注释把姿态决策讲得很细，常量 50 一句话都没有。

priority:p1 —— 本批第三张 p1，判据逐条

1. 默认驱动上就会发生。 卡面的两驱动对照是这张卡的支点：memory 走插入序 ⇒ 对；sqlite（默认）走 id 序 ⇒ 预期的 owner 根本不在那 50 行窗口里。同一份代码、同一份配置、同一份数据，答案随存储驱动改变。
2. 后果是最高权限的错误授予。 一个求职者 persona 拿到了无作用域的 admin_full_access，claimSeedOwnership 随后把每一行种子业务数据的所有权也交给了它。这不是"某个功能不工作"，是把系统交给了错的人。
3. ⭐ 运营者已经明确声明过所有者，而这条路径不问。 PLATFORM_OWNER_EMAIL_ENV 就在同一个文件里（:73 导入、:447-480 使用），single 分支的 :571 不查它。⇒ 这一条把"不确定性缺陷"变成"安全缺陷" —— 一个把 OS_PLATFORM_OWNER_EMAIL 设对了的部署，仍然可能提升别人。卡面这句判断我完全同意，且它是定 p1 而非 p2 的决定性一条。
4. 失败是安静的，且唯一的信号读起来像成功：[security] first user promoted to platform admin: candidate01@mail.example —— 一行 info。⛔ 没有告警、没有对照、没有"我在 113 行里只看了 50 行"的任何提示。
5. ⛔ 没有可接受的应用侧规避。 卡面自己把 app 的做法否掉了，而且否得对：把 owner 行钉成"在三条轴上同时排第一"（id 排序最前、插入最早、created_at 早一年）是一份种子在规避一条它不该知道的规则，且只在没有别的种子用户同时压过这三轴时成立。⇒ 这是运气，不是规避。

⛔ 不是 p0：它不破坏已在运行的生产系统 —— 首次提升只发生在引导期；受害面是新部署与开发/演示环境。但那正是每个客户第一次见到这个平台的地方。

与 #11979 的关系：⛔ 不要等它，卡面已经把理由写对了

卡面预先堵住了最可能的错误处置（「等 #11979 一起做」），我复核后确认这个理由成立并加一句：

4B explicitly preserves first-user promotion for development.

⇒ #11979 无论怎么裁，这段选择逻辑都会继续存在，只是适用面缩到开发模式。一个在开发模式下把管理员权限发给随机用户的引导路径，不因为"生产上会走别的路"就变得可以接受 —— 开发环境里的种子数据同样是真数据，而这正是本卡的实测现场。且 #11979 挂在 #11978 → #11975 → #13515 的传递链上，⛔ 把一张 p1 挂到一条三层传递链后面，是把它变成永不落地。

裁定：修法 1 + 2 都做，同一个 PR，⛔ 不要只做 1

• 只做 1（服务端排序 + 去掉 cap） 让结果与驱动无关、可复现 —— 但它仍然可能提升一个运营者没选的人（最老的可认证用户未必是 owner）。⇒ 修掉了不确定性，⛔ 没修掉安全性。
• 只做 2（优先取声明的 owner） 修掉了有声明时的安全面 —— 但没有声明时仍然在一个 50 行的乱序样本上排序。⇒ 修掉了主路径，⛔ 留着次路径。
• ⇒ 两条覆盖的是不同的失败，卡面自己说了「(1) and (2) are worth doing regardless of when (3) lands」。我把它从"值得"提到"必须"：拆开做会产生一个"看起来修好了"的中间态，而这个中间态在没设 OS_PLATFORM_OWNER_EMAIL 的部署上和今天一样坏。

验收口径（承接 PR 请照抄进 ## 验收备注）

1. 卡面给的回归测试形状原样采用，它是唯一能同时压住两条的形状：种 50 行以上用户，让预期 owner 按 id 排最后、按 created_at 排最前，然后断言 memory 与 sqlite 两个驱动提升同一个用户。⭐ 这正是今天会红的形状，也是"客户端在截断窗口上排序"结构性无法通过的形状。⛔ 只在 memory 上跑等于没跑。
2. 声明 owner 的腿单独一条：设 OS_PLATFORM_OWNER_EMAIL 指向一个既不是最老、也不在前 50 行的用户，断言提升的是它。
3. 阴性对照必测：
   • 未设 OS_PLATFORM_OWNER_EMAIL 时，回落到"最老的可认证用户"，且该结果在两个驱动上一致；
   • plugin-security promotes the OLDEST human sys_user row, so an app that seeds a people directory grants platform admin to a row nobody can log in as #14348 修的那条仍然成立：一个谁也登录不进去的用户不得被提升（sys_account 为空时走 :578 的分支）。一个"直接取 created_at 最小行"的实现会让第 1 条绿，同时把 plugin-security promotes the OLDEST human sys_user row, so an app that seeds a people directory grants platform admin to a row nobody can log in as #14348 的修复删掉。
   • 设了 OS_PLATFORM_OWNER_EMAIL 但该邮箱没有可用账号时的行为要有断言 —— walled 分支在 :447-451 已经为这种情况写了诊断，single 分支需要一个说得出口的答案（提升失败并告警，⛔ 不要静默回落到随机人）。
4. cap 的处置写进 PR：去掉还是提高。若保留任何上限，必须在超出上限时告警——⛔ 「我只看了 N 行」这件事不得再次静默。
5. 日志升级：[security] first user promoted… 这一行是最高权限授予的唯一记录，应当同时记录依据（声明的 owner / 最老可认证）与候选池大小。
6. ⛔ 不要改 :426 那处精确读 —— 它是对的，本卡引它只作对照。

给 app 侧的一句

objectstack-ai/ats#40 里那份"三轴同时压第一"的种子规避，请在本卡落地后移除并重新测一次。⛔ 留着它会掩盖回归 —— 它今天让两个驱动都绿，所以它也会让一个没修好的版本看起来绿。

本席权限声明：分诊席只分类/定级/定车道，以及裁定卡内补救的组合（1+2 同 PR）。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡。此卡不入决策箱：⛔ 不迁移存量数据形状、⛔ 不删除已发布能力；修法 1 只是让结果与驱动无关，修法 2 兑现的是运营者已经作出的声明 —— 两者都只否定今天本就不该发生的结果。#11979 那条策略裁决是另一件事，⛔ 本卡不越俎。

---

Generated by Claude Code

[os-trump]

Claim: session session_012zTkyNHJ7TkuN2oXtP5x37 · branch claude/issue-16682-first-user-promotion-selection · seat domain:services PM (#6021)

Dispatched to a dev seat. The dev inherits this claim and this branch; it posts no second claim and does not touch the assignee.

Triage's ruling is carried into the dispatch as binding, in particular:

• Fixes 1 AND 2 in the same PR — ⛔ not 1 alone. Server-side ordering makes the result driver-independent but can still promote someone the operator never chose; honouring the declared owner fixes the main path but leaves the fallback sorting a truncated unordered sample. Splitting them produces an intermediate state that looks fixed and is exactly as bad as today on any deployment that has not set OS_PLATFORM_OWNER_EMAIL.
• The regression must run on BOTH drivers — the owner sorting last by id and first by created_at, asserting the same user is promoted on memory and sqlite. ⛔ Memory-only is not a run.
• The plugin-security promotes the OLDEST human sys_user row, so an app that seeds a people directory grants platform admin to a row nobody can log in as #14348 negative control — a user nobody can authenticate as still must not be promoted. An implementation that simply takes the lowest created_at turns the first assertion green while deleting that fix.
• ⛔ :426's exact read is correct and is not to be touched; triage cites it only as the contrast that shows :571 was written loose.

One path constraint this seat adds, which triage could not have known: open PR #16805 currently claims packages/plugins/plugin-security/package.json, tsconfig.json and vitest.config.ts under the single-writer rule. bootstrap-platform-admin.ts is free. If the fix or its regression turns out to need any of those three config files, that is a stop-and-report, not something to push through — the PR would not be able to land.

---

Generated by Claude Code

[os-trump]

os-dev-report

{
  "issue": 16682,
  "status": "done",
  "branch": "claude/issue-16682-first-user-promotion-selection",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16863",
  "premise_still_valid": true,
  "summary": "Re-measured the card's defect verbatim on this branch and repaired both halves in one PR. The candidate read now carries orderBy created_at asc + id asc to the driver with no client-side re-sort left behind, and a declared OS_PLATFORM_OWNER_EMAIL holder who is human and authenticable is preferred before the age rule; a declared owner nobody can sign in as REFUSES loudly and promotes nobody rather than falling back. The bare cap 50 became a 200-row page walked oldest-first under a 5000-row ceiling that WARNS when reached, and the promotion log line plus the returned report now carry the basis (declared-owner / oldest-authenticable) and the candidate-pool size. One existing pin in bootstrap-platform-admin-walled-owner.test.ts asserted the exact behaviour triage ruled defective ('never consults the owner-email variable') and was re-authored, keeping #11974's over-denial invariant and quoting the superseding ruling verbatim — flagged in the PR as a ruling collision for the maintainer. The literal memory-driver test arm could not be pinned (two independent maintainer-only blockers); the real memory-driver readings were taken out-of-tree and reported instead.",
  "measured_before_after": {
    "fixture": "113 sys_user rows, 7 with sys_account, intended owner inserted FIRST, created_at oldest, id usr_zzz_owner collates LAST",
    "before_memory": "window[0]=usr_zzz_owner (insertion order), ownerInWindow=true, promoted admin@objectos.ai",
    "before_sqlite": "window[0]=usr_ats_c001 last=usr_ats_c050 (id order), ownerInWindow=FALSE, promoted candidate001@mail.example",
    "after_memory_declared": "promoted admin@objectos.ai, basis declared-owner",
    "after_sqlite_declared": "promoted admin@objectos.ai, basis declared-owner",
    "after_memory_undeclared": "promoted admin@objectos.ai, basis oldest-authenticable",
    "after_sqlite_undeclared": "promoted admin@objectos.ai, basis oldest-authenticable",
    "note": "the raw unordered 50-row window stays driver-shaped after the fix — that is a fact about the drivers and is pinned as an anti-vacuity case; the ANSWER is what stopped being driver-shaped"
  },
  "acceptance_conditions": {
    "1_card_regression_shape": "MET WITH DECLARED DEVIATION. The 113-row fixture is the card's verbatim (owner last by id, first by created_at). The literal 'memory AND sqlite' arm is NOT pinned — see stopped_on. Pinned instead: three natural row orders (AS_RETURNED / INSERTION / REVERSED) all on the real engine over the real better-sqlite3 driver, plus a case asserting all three agree, plus an anti-vacuity case proving the unordered 50-row window really does hide the owner on the real driver.",
    "2_declared_owner_leg": "MET. OS_PLATFORM_OWNER_EMAIL points at usr_zzz_declared whose created_at is the NEWEST of 113 and whose id collates last, so it is neither the oldest nor in the first 50 rows; promoted under all three orders with basis declared-owner, and asserted NOT to be the oldest authenticable human.",
    "3a_unset_fallback_consistent": "MET. A fixture deliberately different from condition 1 (oldest authenticable row is NOT the id-last row, separating the two axes); identical answer under all three orders, basis oldest-authenticable.",
    "3b_14348_survives": "MET, two cases. (i) The two oldest rows are credential-less directory rows and the only login is newer than both — the login is promoted under all three orders, so a min(created_at) implementation fails here while condition 1 stays green. (ii) A 60-row population where nobody can authenticate promotes NOBODY: no_authenticable_user, zero grant rows, and no warning (population far under the ceiling). Also re-asserted the #14348 case-D reserved fork: an existing unscoped grant still short-circuits to already_have_admin BEFORE any selection, so a declared owner cannot re-point an existing admin.",
    "3c_declared_owner_no_usable_account": "MET, two sub-cases (no sys_user row at all; a row with no sys_account). Both return reason declared_owner_not_authenticable, warn naming the variable, the address and the phrase 'NOT falling back to the oldest', and write ZERO grant rows. No silent fallback.",
    "4_cap_disposition": "MET, stated in the PR. See cap_decision below; warning pinned in both directions.",
    "5_log_upgrade": "MET. Exact text below; three cases pin the basis, the pool, the meta fields, and that the published prefix still matches.",
    "6_line_426_untouched": "MET. No edit to that exact read anywhere in the diff."
  },
  "cap_decision": {
    "disposition": "replaced, not merely raised; a bounded page plus a hard ceiling, and exceeding it WARNS",
    "constants": "PLATFORM_ADMIN_CANDIDATE_PAGE_SIZE = 200, PLATFORM_ADMIN_CANDIDATE_SCAN_CEILING = 5000, both exported so the guard reads the same numbers the selection does",
    "rationale": "A ceiling is kept rather than dropped because shouldReplayBootstrapFor re-runs this pass on every sys_user / sys_account insert until an admin exists, so an unbounded scan would be a per-sign-up full-table read on exactly the un-promoted deployments. What the orderBy changes is what truncation costs: an ORDERED page holds the OLDEST rows, which is exactly the set the age rule ranks, so truncation can only bite when every one of the oldest 5000 humans is non-authenticable — whereas the unordered 50 could drop the answer on a 51-row install. Reaching the ceiling is never silent again."
  },
  "log_line_exact_text": {
    "declared_owner": "[security] first user promoted to platform admin: admin@objectos.ai — basis: declared-owner; candidate pool: 1 address(es) declared in OS_PLATFORM_OWNER_EMAIL, 1 matching human user row(s)",
    "oldest_authenticable": "[security] first user promoted to platform admin: admin@objectos.ai — basis: oldest-authenticable; candidate pool: 113 human user row(s) examined oldest-first by created_at",
    "truncation_warning": "[security] the platform-admin candidate scan stopped at its ceiling of 5000 oldest sys_user row(s) and none of them can authenticate — rows beyond that point were NOT examined, so this deployment may hold a promotable human the boot did not see. Promote the intended administrator explicitly by setting OS_PLATFORM_OWNER_EMAIL.",
    "meta": "second logger argument carries { basis, candidatePoolSize, userId }; the returned report carries basis too",
    "prefix": "unchanged, so existing readers matching on 'first user promoted to platform admin: EMAIL' still match (pinned)"
  },
  "clause_2": {
    "conclusion": "no — needs:contract-review NOT hung on either carrier",
    "check_widening_tells": "node scripts/pm/check-widening-tells.mjs --declaration no --diff PR.DIFF -> exit 0: '4 changed file(s) read, no widening tell on any declared surface.'",
    "dispatch_gates_tier": "node scripts/pm/dispatch-gates.mjs --tier -> 'Model tier — no path-derived mandate: the surface hits none of the 3 declared glob(s), derived here, not recalled.'",
    "content_judgment": "The tier line is a floor, not a clearance, so judged on content too: the direction is NARROWING (fewer promotable people; a declared owner who cannot authenticate now refuses where somebody was previously promoted), no accept set gains a spelling or a value, and the only public-surface movement is an OPTIONAL basis field on a returned object — additive, so no consumer can be rejected by it.",
    "pair_exit_code": "not run — --pair is owed only on a 'yes' declaration"
  },
  "gate_union": {
    "derived": 66,
    "run": 66,
    "unrun": 0,
    "reconciliation": "node scripts/pm/dispatch-gates.mjs --ran RANFILE --repo objectstack-ai/objectstack -> exit 0: 'Run reconciliation — 66 derived, 66 run, 0 NOT-MEASURED, 0 UNRUN.'",
    "fresh_tree": "yes — git fetch origin main then merged origin/main twice; the final derivation printed NO STALE TREE warning, at commit 141876814",
    "findings_exit_1": "zero remaining",
    "not_measured_exit_3": "3 — pnpm check:dual-build-cjs-loads, pnpm check:i18n, pnpm check:type-check-debt. All three print PREREQUISITE NOT MET and say in their own words that nothing was measured; each needs a full workspace build that CI performs before them. Read as NOT MEASURED, not as red and not as green.",
    "gates_that_were_genuinely_red_and_were_fixed": "check:engine-double-contract (the three new engine doubles' update() now routes through assertEngineUpdateDispatch from @objectstack/metadata-core; the PINNED ledger grew via --write, the shrink-only baseline untouched), check:objectql-double-limit (the caller's bound applied AFTER the filter and by presence), check:where-matcher (the matchers refuse a $-combinator by name instead of reading it as a field name)",
    "route_envelope": "does not apply, measured not assumed: the whole change adds 0 lines matching 'c.json(' or 'res.json('. Explicitly checked because dispatch-gates cannot derive this family.",
    "lint": "pnpm lint — the FULL repo-wide 'eslint . --no-inline-config' — exit 0. Not narrowed, so no narrowing evidence is owed.",
    "governed_surfaces": "none touched (docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md), so no maintainer-speed-read section is owed"
  },
  "tests": "pnpm --filter @objectstack/plugin-security test -> 103 files, 1925 tests, all passing (VERDICT command-exit 0 under scripts/pm/os-verify-lock.sh). pnpm --filter @objectstack/plugin-security typecheck -> exit 0 including check:test-typecheck ('OK — 0 file(s) / 0 error(s) / 0 pinned signature(s)'). New suite bootstrap-platform-admin-promotion-selection.test.ts = 23 cases, all green. ABLATION, four legs, each mutating one enforcement point, proving the mutation on disk (anchor grep -c 1->0, injected-text count 0->1, git hash-object differing from the HEAD blob), running the guard, then restoring via 'git checkout HEAD -- ABSPATH' under a trap ... EXIT INT TERM and proving restoration by blob equality with the HEAD blob AND an empty git diff HEAD: A1 drop OLDEST_FIRST from the candidate read -> 3 RED including AS_RETURNED, the un-permuted real-driver arm; A2 disable the declared-owner leg -> 10 RED; A3 make the scanTruncated branch unreachable -> 1 RED; A4 strip basis and pool from the promotion line -> 5 RED. A fifth attempt was refused BY THE HARNESS: an empty replacement string makes the injected-text count unobservable (grep -c '' matches every line), so it aborted as a possible no-op and was redone with a countable marker. Tree at HEAD, git status clean, suite green after all four legs. CROSS-PACKAGE TYPE CHECK: the change is additive so the 'inject a rejected key' recipe has nothing to reject; the equivalent two-legged proof ran against packages/cli (the one value-importer) after rebuilding plugin-security — positive leg, a probe reading report.basis into the new union produced 0 errors ON THE PROBE FILE, proving the consumer read the REBUILT .d.ts; negative leg, assigning report.basis to number produced 'error TS2322: Type string | undefined is not assignable to type number', proving the type is live. The package's 111 pre-existing errors are unbuilt sibling packages, identical on both legs; probe removed, git status for packages/cli clean.",
  "mcp_calls": "7 — issue_read get_comments (claim verification + triage ruling), search_issues x2 (control word then dedup), issue_write (filed #16861), create_pull_request, pull_request_read (full body read-back), add_issue_comment (this report). Card body read via the zero-quota public-payload channel; REST is 403 for this session (repo-scoped probe against /repos/objectstack-ai/objectstack returned 403), so the degradation ladder was git-first then payload then MCP, and the search channel switch is declared here.",
  "open_questions": [
    {
      "question": "The memory-driver arm of acceptance condition 1 is measured but not pinned. Should it become a committed test?",
      "options": [
        "A — leave as is: the suite pins three row orders on the real sqlite driver (a superset of what memory and sqlite produce between them) and the real memory-driver readings live in the PR body",
        "B — maintainer adds a ruledConsumers entry to scripts/driver-memory-census.ledger.json AND the plugin-security package.json devDependency, then a dev adds the literal two-driver arm",
        "C — move the two-driver arm into packages/runtime, which already declares driver-memory in dependencies; still needs the ledger entry, since the file-level import is a new unledgered TS binding"
      ],
      "recommendation": "A for this PR, because both B and C require acts reserved to the maintainer (the ledger states ruled-permanent 'is a maintainer ruling and lives in ruledConsumers; nothing else may claim it', and the manifest edit collides with PR #16805's single-writer claim). If the literal arm is wanted, B is cleaner than C: it keeps the guard beside the code it guards, whereas C would put it in a package that reads plugin-security through dist."
    },
    {
      "question": "Two rulings collide on whether the `single` branch may read OS_PLATFORM_OWNER_EMAIL. #11974 / Choice 4A (maintainer acceptance 2026-08-25) is pinned as '`single` keeps first-user promotion byte-for-byte'; #16682's triage (2026-09-08) rules the declared owner MUST be preferred. I resolved it for the newer ruling because the dispatch carries it as binding, and re-authored the pin keeping its over-denial invariant.",
      "options": [
        "A — accept the resolution as landed: the pin's subject (retiring the walled write must not retire the single one) is intact; only the incumbent it incidentally snapshotted moved",
        "B — maintainer re-affirms #11974's byte-for-byte wording, in which case fix 2 has to be withdrawn and #16682 drops to fix 1 only (which its triage explicitly refused)"
      ],
      "recommendation": "A — the pin's own comment says it exists as an 'over-denial guard for the ruling's direction', i.e. to catch collateral damage from the walled retirement, not to rule that this branch may never read the variable. But the collision is named loudly in the PR because it is the maintainer's to confirm."
    },
    {
      "question": "The declared-owner leg does not REQUIRE email_verified (it prefers it). The walled derivation does require it, and its own comment names the threat: 'an attacker who registers the operator's address before the operator does gains no standing by it.'",
      "options": [
        "A — as landed: authenticable is the criterion, verified is a tie-break. `single` has no verification vocabulary anywhere (an existing pin asserts an unverified first user is still promoted here), and requiring it would refuse promotion on every deployment that never configured email verification",
        "B — require email_verified on this leg too, refusing loudly when the declared owner is unverified"
      ],
      "recommendation": "A, on the grounds that it is not a widening relative to the incumbent — today's rule hands the grant to whoever registers FIRST with no config knowledge required at all, so the set of winning attackers strictly shrinks — and that making `single` verification-keyed is a policy change rather than a repair. B is a defensible maintainer choice; note that sys_user.email is UNIQUE on the SQL family, so a squatted address is held exclusively and B would then mean no promotion at all until the operator can take the address back."
    }
  ],
  "out_of_scope_findings": [
    "filed as #16861: the already_have_admin short-circuit reads sys_user_permission_set with an unordered cap of 50 and applies the deciding !organization_id predicate client-side, so on an install with 50-plus organization-scoped grants of admin_full_access the existing unscoped holder can be missed and a SECOND unscoped platform admin minted — same defect class as this card, in the same function, on a different read; deduped with a validated control word first",
    "noted, not filed: sys_user.email carries a UNIQUE index, so on the SQL family two rows can never hold one address (measured as SQLITE_CONSTRAINT_UNIQUE while building the verified-first tie-break fixture) — which is why those two cases run on a double, and which is worth knowing for the verification question above"
  ],
  "stopped_on": [
    "The literal 'memory AND sqlite' regression arm. Two independent blockers, each outside a repair's authority: (i) declaring @objectstack/driver-memory needs packages/plugins/plugin-security/package.json, which open PR #16805 claims under the single-writer rule the dispatch names as a stop-and-report; (ii) independently, scripts/driver-memory-census.ledger.json must dispose of every declaration of that package, and the only fitting axis for a test consumer is ruled-permanent, which the ledger states is 'a maintainer ruling and lives in ruledConsumers; nothing else may claim it' — the gate's header says a third arrival 'is now refused at the gate'. I did NOT push through either. The real memory-driver before/after was measured out-of-tree instead and is reported in the PR body and above; the committed suite pins the property over three row orders on the real driver."
  ]
}

---

Generated by Claude Code

[os-trump]

Claim: session session_012zTkyNHJ7TkuN2oXtP5x37 · branch claude/issue-16682-first-user-promotion-selection · seat domain:services PM (#6021)

Clause-②: yes

Claim correction, superseding my earlier claim comment (5583064870). Same session, same branch, same dev — only the declaration changes, from no to yes. ⛔ Not a second claim and not a re-dispatch; nothing resets.

Why I am overturning my own claim-time no

I measured the export surface rather than reasoning from the dev's summary, and it splits in two directions:

• The two new exported consts are correctly OUT of scope. PLATFORM_ADMIN_CANDIDATE_PAGE_SIZE and PLATFORM_ADMIN_CANDIDATE_SCAN_CEILING are new export consts in bootstrap-platform-admin.ts, but packages/plugins/plugin-security/src/index.ts:33 re-exports that module by name — export { bootstrapPlatformAdmin } from './bootstrap-platform-admin.js' — not export *, and the package's exports map publishes only .. So neither const is reachable from the published entry point. On this axis the dev's reading was right and mine would have been wrong.
• basis is a new key on a published payload. bootstrapPlatformAdmin is re-exported, and the diff adds basis?: 'declared-owner' | 'oldest-authenticable' to its returned object, so the published .d.ts gains a key. references/contract-review.md's mechanical floor is unconditional on exactly this: 「新导出符号或已发布载荷上的新键恒 yes,直接锁契约复审档。」

The dev's argument for no — the field is optional and additive, so no consumer can be rejected by it — is a conformance argument, and it may well be the right answer. But the floor is not a breakage test; it is a routing rule, and conformance questions are the ones it explicitly refuses to mechanise (「conformance 类 ⛔ 不机械化」).

A tool disagreement worth recording rather than resolving here

check-widening-tells --declaration no returned exit 0 — "no widening tell on any declared surface" — on this same diff. So the mechanical tell-checker and the mechanical floor point different ways, presumably because the tell-checker's notion of a declared surface does not include a re-exported function's return type. I am not resolving that from this seat. The governing rule for exactly this position is 「claim 拿不准 ⇒ 按 yes 派契约复审档」, and 「真闸门在 PR 或报告时点的档位复核;声明被档位推翻 ⛔ 不作席位过失」 — so yes routes it to the seat that decides, and if the tier overturns it, that is the system working rather than anyone's error.

⇒ needs:contract-review hung on both carriers. ⛔ This does not enqueue at my tier.

Independently blocking: single-writer conflict with #16805

PR #16863 modifies scripts/engine-double-contract.pinned.json. So does open PR #16805 (measured on its current branch, not from memory). Under the single-writer rule no other open PR may claim that path, so #16863 cannot land until #16805 does — regardless of the contract-review question. Recording it here so it does not surface later as an unexplained red.

This is the second time this pair has collided; the dev correctly stopped rather than pushing through when the same rule blocked the memory-driver test arm on plugin-security/package.json.

Still outstanding for the maintainer

The ruling collision the delivery flagged stands and is not mine to resolve: #11974 / Choice 4A is pinned as "single keeps first-user promotion byte-for-byte", while this card's triage rules that the declared owner must be preferred. The dev implemented the newer ruling, kept #11974's over-denial invariant, quoted the superseding ruling verbatim in the re-authored pin, and named the collision in the PR. I agree with that disposition and with its reasoning — the pin's own comment says it exists as an over-denial guard for the walled retirement's direction, not as a rule that this branch may never read the variable — but a maintainer confirming or reversing it is the correct next step, not a seat decision.

The changeset is currently patch. Given what this PR does to who receives admin_full_access, and given the level axis is blind to nested packages (#16713), I am flagging it for the tier review to look at rather than pre-judging it — the #16878 round this morning showed both gates can be green on a level that is wrong.

---

Generated by Claude Code