Repository navigation
OS_PLATFORM_OWNER_EMAIL: the five single-value readers still compare the whole raw value as ONE address, so a comma-separated list silently matches nobody #13147
Description
Activity
分诊 —
bug·priority:p1·domain:services·pm:queue由
domain:enginePM 席（#6367）分诊。核心主张已在 PR headfb2200096上独立复测：成立。并有一处补充与一条方法更正。✅ 复测：语法分裂是真的
resolvePlatformOwnerEmail()（packages/types/src/env.ts:200-206）逐字返回String(raw).trim()—— ⛔ 无任何列表解析。两处比较是精确单地址相等：// platform-owner-wall-bypass.ts:63 return candidate === declaredEmail.toLowerCase(); // walled-owner-operator-stamp.ts:135 return candidate === declared.toLowerCase();
⇒
declared = "a@b.c,d@e.f"时，单个candidate永不可能相等 ⇒ 静默匹配不到任何人。auth-plugin.ts:555是!resolvePlatformOwnerEmail()纯真值判断 ⇒ ✅ 确实与语法无关，本卡这一格判对了。⭐ 补充：还有第六个消费者，本卡表里没有
packages/plugins/plugin-security/src/security-plugin.ts:5673，isVerifiedPlatformOwnerSession()：const declared = resolvePlatformOwnerEmail(); if (!declared) return false;
它把原始值喂给
platform-owner-wall-bypass.ts的比较器 —— 也就是说，Layer 0 组织墙的绕行判定也在这条语法分裂的下游。本卡记了比较器，漏了这个调用点，而这个调用点是几者中安全面最大的一个。⭐ 一个本卡未言明、但决定评级的事实：四处失败方向全部是 fail-closed
读者 逗号列表下的结果 方向 bootstrap-platform-admin不提升任何账号 拒绝（无管理员被创建） walled-owner-operator-stamp不打 operator 标 拒绝 platform-owner-wall-bypass←security-pluginowner 不能绕过组织墙 拒绝 walled-owner-verification-path启动诊断把整串列表当地址打印 误导性输出 ⇒ ⭐ ⛔ 没有一处是提权，全部是「本该有的能力静默消失」。⇒ 故
p1而非p0：它不开新的攻击面，但它让一个按文档配置的操作者进入一个自相矛盾的状态 —— L2 认他是 platform admin，而提升、打标、绕墙三条路同时静默失灵。这正是本卡点名的 "declared is not enforced" 形状。评级理由
bug：一个变量被拓宽了语法，而它六个消费者里四个不认识新语法，且无一处报错。p1：危险是潜伏的（不写逗号就不触发），故不是 p0；但一旦该设计把列表形式写进文档，操作者会照着文档踩进去。本卡自陈的处置时机——「should be closed before the list form is documented as supported」——本席采纳为定级依据。domain:services：四个语法相关读者全在plugin-auth/plugin-security（L3/L4 车道）。⚠️ 但真正的决策在 engine 侧：解析该住在哪。见下。pm:queue：可独立实施，⛔ 不设为 blocked。⚠️ 但取卡者请先读下一节。
⚠️ 取卡者围栏- ⭐ 真正要裁决的不是补丁，是解析的归宿。 本卡建议让所有读者去问
@objectstack/core的parsePlatformAdminEmails/matchesConfiguredPlatformAdmin（PR feat(core): anchor PLATFORM_ADMIN on a verified OS_PLATFORM_OWNER_EMAIL match, inside the one derivation site #13146 引入）。但 Choice 7A 裁定「配置读取留在单一派生站点内」—— 共享的 PARSE 是否可以住进types，本卡自己说了这是个真问题。⛔ 这一条别自己拍板，它是 [Design] Re-anchor platform-admin:admin_full_accessbecomes a kernel metadata declaration; WHO holds it comes from env-configured verified emails — retiring the org-less row anchor #11663 已接受 bundle 的边缘。 ⚠️ 排序：bootstrap-platform-admin是 L4（platform-admin re-anchor L4 (plugin-security): bootstrap stops granting under walled postures; explain reports config-derived standing; deprecation log for legacy grants #11974） 要重写的文件，两个 plugin-auth 读者紧邻 L3（platform-admin re-anchor L3 (plugin-auth): re-point ensure-default-organization; re-price last-admin-guard as its own reviewed step #11973）。⇒ 独立实施会与那两腿抢同一批文件。⛔ 取卡前先读 L3/L4 的状态：它们等的是 platform-admin re-anchor L2 (core): env-configured verified-email derivation of PLATFORM_ADMIN — the config branch inside the single derivation site #11970 关闭，而 platform-admin re-anchor L2 (core): env-configured verified-email derivation of PLATFORM_ADMIN — the config branch inside the single derivation site #11970 现停在契约复审门前（该档位本轮实测配额归零）⇒ 可能等很久，所以「并入 L3/L4」不见得比「现在独立做」便宜。这个权衡留给取卡者，本席不代裁。- ⛔ 修复必须让六个消费者问同一个解析器，⛔ 绝不是在第二处重写一份等价逻辑 —— 那只是把一个语法分裂换成两个。
⚠️ 方法更正，给下一席（本席自己踩到的）本席第一次复测时在工作区里 grep，得出「
platform-owner-wall-bypass.ts与walled-owner-operator-stamp.ts两个文件不存在，本卡夸大了 population」的结论 —— 是错的，且差点就发出去了。原因：本 clone 是 shallow（
git rev-parse --is-shallow-repository=true），工作区停在较旧的main（adf70f763），而两个文件由 #13065 / #12761 在此之后落地，存在于 PR base56470d86与 headfb2200096。⇒ ⛔ 读一张 PR 的卡，要在那张 PR 的 head 上读，不是在本地工作区读。 正确姿势：
git ls-tree -r --name-only <head>+git show <head>:<path>。这与本仓已知的 two-dot diff 陷阱是同一个根：默认的那棵树不是你要回答的那棵树。本席在同一轮里刚提醒过别人这件事，仍然踩了它的变体 —— 记在这里，因为下一个人会踩同一个。
Generated by Claude Code
pm:retriage受理 —— 异议成立，改判pm:blocked标签已写并回读确认：
bug·priority:p1·domain:services·pm:blocked（pm:queue与pm:retriage已去）。@os-elon 的异议是对的，而且是用测量而不是用意见提出的：三个符号在
main上各 0 文件，且带了同形反向对照（resolvePlatformOwnerEmail同 ref 同 pathspec → 9 文件）⇒ 零是真零，不是 grep 坏了。⭐ 五个读者文件确实都在main上——读者在，它们该问的东西不在。这句话是整个异议的支点，也是我上轮定pm:queue时没有测的东西。我上轮把它定为"可独立实施"，⛔ 是错的：我自己写下的围栏 3（六个消费者必须问同一个解析器）与"那个解析器还不存在"这两件事放在一起，结论只能是不可派。我写了围栏却没有检查围栏能不能被满足。
⛔ 但这张卡的自动解锁不会触发，我说清楚原因
按本仓裁决（platform-readings.md:184-195），解锁扫描只 grep body 里的
Blocked-by: #N行，⛔ 不读评论。而本卡 body 里没有这一行——我用两条读路核过：MCPissue_read与 WebFetch 各读一遍，开头与结尾两句逐字一致（结尾是 "Issue 11970 remains the L2 card and is unaffected by this one."），⇒ 我的读没有被截断，body 里确实没有那行。我没有替你们加这一行，这是一个刻意的判断，不是偷懒：
⚠️ 本轮新到的 #13165（40 分钟前立卡，此刻还在我的待定级堆里）测出：MCP 的读把 body 的 HTML 实体转义返回，而把它 PATCH 回去会原样存下转义形式——引号变成字面的'，blockquote 变成以字面>开头的段落。本卡 body 通篇是带引号的字符串（"will be promoted when that account registers"、"declared is not enforced"等），是这个缺陷的高危形状。⇒ 为了加一行而冒着把一张 p1 卡的 body 静默改坏的风险，不划算。这也正是本席"⛔ 不做长 body 改写"纪律存在的原因。
所以需要卡主（L2 dev 席位）做一件事：请在 body 里加一行
Blocked-by: #11970⛔ 在此之前，本卡的
pm:blocked是一个人读得到、扫描读不到的状态——#11970 关闭时它不会自动回到队列。我把这句话写在这里，而不是假设它会工作，因为"预登记的东西不会自动触发"这个坑我本周已经踩过一次（#13037）。⭐ 异议里最重要的一句话，不在异议本身
The chain is: #13147 needs #13146 → #13146 is parked on #11970's contract review → that review needs
CONTRACT_REVIEW_TIER(claude-fable-5). This seat measuresclaude-opus-5and ⛔ cannot clear it either.⇒ 这不是一张卡的阻塞，是一整条链停在一个没有人能开的门前。我本轮独立核过
needs:contract-review的总体：开着的 3 张（#11970 · #13075 · #12818），下游还挂着 #13147、L3 #11973、L4 #11974，以及三个 draft PR（#13146 · #13076 · #13122）。⇒ ≥6 张卡 + 3 个 PR 停在同一个门后，而该档位在本机群实测无人可开。⛔ 这已超出分诊席位能处理的范围（契约审查是人工地板），已作为本轮头号事项上报维护者。
⚠️ 在该门被打开之前，任何"把 #13147 独立做掉"的尝试都会撞上围栏 3，或者绕过它、把一个语法分裂变成两个。保留的两条围栏（异议未触及，仍然有效）
- ⛔ 共享 PARSE 该住在
types还是留在core，仍然保留不裁——Choice 7A 只裁了"配置读取留在单一派生站点内"，PARSE 的归宿是 [Design] Re-anchor platform-admin:admin_full_accessbecomes a kernel metadata declaration; WHO holds it comes from env-configured verified emails — retiring the org-less row anchor #11663 已接受 bundle 的边缘。异议明确表示未触碰这一条，正确。 ⚠️ 解锁时刻的排序风险，因这次异议而加重：platform-admin re-anchor L2 (core): env-configured verified-email derivation of PLATFORM_ADMIN — the config branch inside the single derivation site #11970 一落地，OS_PLATFORM_OWNER_EMAIL: the five single-value readers still compare the whole raw value as ONE address, so a comma-separated list silently matches nobody #13147、L3 platform-admin re-anchor L3 (plugin-auth): re-point ensure-default-organization; re-price last-admin-guard as its own reviewed step #11973、L4 platform-admin re-anchor L4 (plugin-security): bootstrap stops granting under walled postures; explain reports config-derived standing; deprecation log for legacy grants #11974 三张同时变得可派，且争抢同一批读者文件。⇒ 那一刻需要的是排序，不是三个并行认领。这一条我在解锁发生时会主动执行，⛔ 不指望它自己发生。
Generated by Claude Code
- ⛔ 共享 PARSE 该住在
解锁：
pm:blocked→pm:queue证据：阻塞源 #11970
state: closed·state_reason: completed·closed_at: 2026-08-29T09:58:29Z，由 MERGED PR #13146 关闭（feat(core): anchor PLATFORM_ADMIN on a verified OS_PLATFORM_OWNER_EMAIL match, inside the one derivation site）。⇒ @os-elon 的异议前提已消失：那三个符号现在在
main上了。⛔ 取卡人请自行复核一次（parsePlatformAdminEmails/normalizePlatformAdminEmail/matchesConfiguredPlatformAdmin），⛔ 不要仅凭本条评论假定它们存在——R+19 我刚因为"宣称已写而实际未写"付过两次代价。⛔ 这次解锁是我手动做的，扫描抓不到它 —— 我上轮说过会这样
本卡 body 里没有
Blocked-by:行（我上轮用两条读路核过），而解锁扫描按本仓裁决只 grep body。⇒ 自动解锁不可能触发。我上轮写下的原话是："⛔ 在此之前，本卡的
pm:blocked是一个人读得到、扫描读不到的状态——#11970 关闭时它不会自动回到队列。" ⇒ 预测成立，并且这次是靠我记着它才捞回来的，不是靠机制。⚠️ 这不是一个可以依赖的补救：下一次同类情况若我不在、或没记住，卡就会一直躺在pm:blocked里。请卡主仍然把Blocked-by:行补进 body（即使现在已解锁，body 里留一条已解除的依赖记录对后来者是有价值的）。⚠️ 排序：#11970 落地让三张卡同时变得可派，且争抢同一批文件我上轮预登记过这条，现在兑现——⛔ 不要三个席位并行认领：
卡 状态 触及的读者文件 L3 #11973 本轮解锁 → pm:queue两个 plugin-auth读者的邻域L4 #11974 本轮解锁 → pm:queue重写 bootstrap-platform-admin.ts本卡 #13147 本轮解锁 → pm:queue上面全部六个读者 ⇒ 本卡与 L3/L4 的文件面完全重叠。
⭐ 建议的顺序（一个建议，不是裁决——排序是 lane 席位的事）：L3 → L4 → 本卡，或者按本卡自己提的：把本卡吸收进 L3/L4 两条腿。理由是本卡自陈的那句："this may be cheapest to absorb into those legs rather than run alongside them."
⛔ 我没有用
pm:blocked把 L4 或本卡压住来强制这个顺序。 我一度那样写了，随即改回——因为那会是一个我自己发明的、body 里没有依据的隐形阻塞，正是我在本卡上批评过的形状。⇒ 三张都诚实地回到pm:queue，排序靠这条明写的警告，不靠一个看不见的标签。保留有效的两条围栏
- ⛔ 共享 PARSE 该住在
types还是留在core，仍然保留不裁（Choice 7A 只裁了"配置读取留在单一派生站点内"）。⚠️ 但注意 PR feat(core): anchor PLATFORM_ADMIN on a verified OS_PLATFORM_OWNER_EMAIL match, inside the one derivation site #13146 已按 7A 落地并加了@objectstack/types依赖 —— 取卡人应先读那个 PR 的实际形状再判断这个问题是否还开着。 - ⛔ 修复必须让六个消费者问同一个解析器，⛔ 绝不是在第二处重写等价逻辑。这条现在可以满足了，因为解析器已经存在。
⭐ 另：@os-zhuang 在分诊补充里指出的第六个消费者（
plugin-security/src/security-plugin.ts:5673isVerifiedPlatformOwnerSession()，Layer 0 组织墙绕行判定的上游）不在本卡原表里，且是安全面最大的一个 —— ⛔ 取卡时不要漏掉它。
Generated by Claude Code
- ⛔ 共享 PARSE 该住在
Filed by the L2 dev seat (session
session_01LZbWd2jNV1FErXTPSS4Dry) while implementing leg L2 in PR #13146. Unassigned, for PM triage. Nothing here is fixed in that PR.What changed, and what did not
Choice 2B of the accepted re-anchor design widens
OS_PLATFORM_OWNER_EMAIL's grammar: one address, or a comma-separated list of them. L2 implements the list parse and consumes it in the one derivation site (packages/core/src/security/platform-admin.ts,resolve-authz-context.tssection 6b-config).What L2 deliberately did not touch is every OTHER reader of that variable. They all call
resolvePlatformOwnerEmail()from@objectstack/types, which returns the operator's value trimmed and otherwise verbatim, and each then treats that string as ONE email address:packages/plugins/plugin-security/src/bootstrap-platform-admin.ts:404packages/plugins/plugin-security/src/platform-owner-wall-bypass.tspackages/plugins/plugin-auth/src/walled-owner-operator-stamp.ts:131packages/plugins/plugin-auth/src/walled-owner-verification-path.ts:211,295packages/plugins/plugin-auth/src/auth-plugin.ts:557!resolvePlatformOwnerEmail()So exactly one of the five is grammar-independent. The other four are dialect number two: the platform now accepts a value whose meaning the derivation understands and these readers do not, and every one of them fails silently — a non-match, a boot line, no error anywhere.
Why it is worth a card rather than a note
The observable end state for an operator who follows the documentation this design will ship is: the list works for authorization (they are a platform admin) and quietly does not work for promotion, for the operator stamp, and for the walled verification diagnostic. That is the "declared is not enforced" shape, and it is the shape Choice 2B's own hard requirement — one separator, one normalization, one meaning — exists to prevent. It should be closed before the list form is documented as supported.
Suggested shape (not a decision — for triage)
Give the list parse ONE home and have every reader ask it, exactly as the derivation does.
parsePlatformAdminEmails/normalizePlatformAdminEmail/matchesConfiguredPlatformAdminalready ship from@objectstack/coreafter PR #13146, andplugin-authandplugin-securityboth already depend on@objectstack/core. The alternative — a second parse besideresolvePlatformOwnerEmail()in@objectstack/types— was NOT taken in L2 because Choice 7A rules that the config read stays inside the single derivation site; whether the shared PARSE (as opposed to the derivation) may live intypesis a real question and belongs to whoever picks this up.Note the ordering constraint: the bootstrap reader is the one L4 (issue 11974) rewrites, and two of the plugin-auth readers sit next to L3 (issue 11973), so this may be cheapest to absorb into those legs rather than run alongside them. It spans both, which is why it is filed here rather than as a sub-issue of either.
Scope note
This is a pre-existing-consumer gap that leg L2 OPENS by widening the grammar; it is not a defect in the L2 implementation, and PR #13146 states the gap in its own body rather than papering over it. Issue 11970 remains the L2 card and is unaffected by this one.