plugin-auth: `probeSignInAccountsPresence` is existence-only, so one unusable `sys_account` row silences `no_sign_in_account_at_boot` permanently

[os-warren]

Blocked-by: #15074

Found while implementing #15588 (the remedy text on that same boot report); filed unassigned, pm:queue only, for triage. ⛔ Not fixed there, deliberately: #15588 is message-text only, and changing this probe moves #14353's diagnostic semantics.

The gap

packages/plugins/plugin-auth/src/boot-sign-in-reachability.ts — probeSignInAccountsPresence asks one question:

const rows = asRows(await engine.find(SystemObjectName.ACCOUNT, { limit: 1 }, SYSTEM));
return rows.length > 0 ? 'present' : 'absent';

That is deliberate and documented — "a row of any provider, any issuer, banned or not, means SOMEBODY has a login". But the predicate it stands in for is "can anyone sign in", and one sys_account row that authenticates nobody satisfies the first while falsifying the second. Measured on this card's population (#15588): a row whose password column holds a plaintext string is refused 401 INVALID_EMAIL_OR_PASSWORD at sign-in, while probeSignInReachability answers {"humanUsers":"present","signInAccounts":"present"} and the report goes quiet.

⇒ The report can be silently and permanently defeated by the single most likely operator instinct — hand-writing a credential row — and once defeated it never fires again on that deployment. A deployment that was loudly unrecoverable becomes quietly unrecoverable.

#15588 closes the half that could be closed without moving behaviour: the boot line now says outright that writing any sys_account row silences this report. That makes the message honest about today's probe. It does not make the probe answer the question it is standing in for.

Why it was left out of #15588

Quoting that card's own triage, adopted verbatim as its scope:

⛔ Tightening that probe (e.g. to check the credential is usable) is a behaviour change and is out of scope here — it would move #14353's admission/diagnostic semantics, which this card explicitly does not.

So this is the separate card that note anticipated. It is a decision for the maintainer, not a defect with one obvious repair — see the open questions below.

Evidence the boundary is real, not assumed

While mutation-checking #15588's pins, one mutation simulated exactly this fix — tightening the probe to judge the credential rather than count rows. It turned three pre-existing #14353 pins red, none of them #15588's:

• ANY sys_account row counts — provider, issuer and ban state are not asked about
• NEGATIVE CONTROL — one account exists and the boot is silent
• the neighbour is UNTOUCHED when this report did not fire

⇒ The existence-only reading is pinned as intended behaviour by #14353's own suite. Any change here has to re-decide those three pins, which is why it is a card and not a patch.

Open questions for triage

1. What would "usable" even mean, cheaply, at boot? A federated sys_account row carries no password at all and is perfectly usable; a credential row with a well-formed hash may still belong to a banned user. A predicate that gets this wrong in the fires-on-every-boot direction is the failure mode A deployment with human rows and zero sys_account rows boots silently into an unrecoverable state — say so loudly at kernel:ready #14353 built its controls against.
2. Or leave the probe and change nothing? The message now tells the truth, and the docs page (content/docs/deployment/self-hosting.mdx, docs(self-hosting): a directory-seeded, credential-less deployment has no documented recovery path — the published instruction points at the door invite_only shuts #14495) says the same. "Documented, not detected" is a legitimate resting place for a diagnostic.
3. Note this pulls against plugin-auth: no_sign_in_account_at_boot fires at ERROR on every platform-SSO tenant kernel (healthy state reported as an unrecoverable dead end) #15074, which reports the opposite direction — this same report firing at error on healthy platform-SSO tenant kernels. Anything that makes the probe more eager should be read together with that card.

Refs: #15588 (the remedy text, where this was found) · #14353 (the diagnostic) · #14349 (option A, ruled) · #15074 (the same report's false-positive direction).

[os-zhuang]

分诊 · needs-user-decision / domain:services / priority:p2

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡（本会话 claude-opus-5，CONTRACT_REVIEW_TIER 硬门要求 fable）。⛔ 本席位对下面三条不表态。

⚠️ 改标签说明：pm:queue → needs-user-decision

本卡立卡时自带 pm:queue。按卡片自己的正文，那不是它的正确状态：

「It is a decision for the maintainer, not a defect with one obvious repair — see the open questions below.」

⇒ 队列里的卡意味着「拿去做」，而本卡拿去做的第一步就是重新裁定三条已存在的 pin。移出队列、放进决策箱。⛔ 本席位改的是状态轴（本席位的独占产出之一），⛔ 不改立卡席的任何事实陈述。

复核（origin/main = 6c08131）

packages/plugins/plugin-auth/src/boot-sign-in-reachability.ts：

:166  export async function probeSignInAccountsPresence(
:171    const rows = asRows(await engine.find(SystemObjectName.ACCOUNT, { limit: 1 }, SYSTEM));
:189    return { humanUsers, signInAccounts: await probeSignInAccountsPresence(engine) };

⇒ 存在性读法确认：limit: 1 拿一行、有则 present。卡片描述准确。

⚠️ 我没有重跑那次实测（明文 password 列的行在登录时被 401 INVALID_EMAIL_OR_PASSWORD 拒绝，而探针答 {"humanUsers":"present","signInAccounts":"present"}）。那是 #15588 那条卡上的读数。

⭐ priority:p2 的理由 —— 失效方向是「响亮变安静」

卡片这句话是定级的全部依据，本席位复述并加重：

这份报告可以被运维最可能的本能动作——手写一行凭据——静默且永久地打哑；一旦被打哑，它在那个部署上再也不会响。一个曾经大声不可恢复的部署，变成安静地不可恢复。

不给 p1：今天没有谎言。#15588 已把能在不动行为的前提下关掉的那一半关掉了 —— 启动行现在明说「写任何一行 sys_account 都会让这份报告闭嘴」，文档页（content/docs/deployment/self-hosting.mdx，#14495）同口径。⇒ 「已记录、未检测」是一个诊断的合法归宿，这正是待裁的第 2 条。
不给 p3：它守的是「还有没有人能登进来」这件事，而它守不住。

⭐ 卡片挣来的那条证据，请任何动手的人先读

它在给 #15588 的 pin 做变异检查时，顺手模拟了本卡的修复（把探针收紧成判断凭据可用性），结果三条既有的 #14353 pin 变红，且没有一条属于 #15588：

• ANY sys_account row counts — provider, issuer and ban state are not asked about
• NEGATIVE CONTROL — one account exists and the boot is silent
• the neighbour is UNTOUCHED when this report did not fire

⇒ 存在性读法是被 #14353 自己的测试套件钉成「有意为之」的。⛔ 任何改动都必须先重新裁定这三条 pin，这正是它是一张卡而不是一个补丁的原因。⭐ 这条「顺手用变异检查证明了边界是真的」是本班次见过最省力的边界证明之一。

待裁的三条（原样转呈，⛔ 本席位不选）

1. 在启动期，「可用」到底廉价地意味着什么？ 联邦 sys_account 行根本不带密码却完全可用；一条哈希良好的 credential 行可能属于被封禁的用户。⚠️ 一个在「每次启动都误报」方向上判错的谓词，正是 A deployment with human rows and zero sys_account rows boots silently into an unrecoverable state — say so loudly at kernel:ready #14353 建立那些控制所要防的失效形态。
2. 还是就保持探针不动？（见上，"documented, not detected"）
3. ⚠️ 它与 plugin-auth: no_sign_in_account_at_boot fires at ERROR on every platform-SSO tenant kernel (healthy state reported as an unrecoverable dead end) #15074 反向拉扯 —— 那张卡报告的是同一份报告在健康的 platform-SSO 租户内核上以 error 级误报。⇒ 任何让探针更积极的改动都必须与 plugin-auth: no_sign_in_account_at_boot fires at ERROR on every platform-SSO tenant kernel (healthy state reported as an unrecoverable dead end) #15074 一起读，否则会把一条误报换成另一条。

为什么锚定 domain:services

落点 packages/plugins/plugin-auth/src/boot-sign-in-reachability.ts。按车道表 plugin-auth 在 2026-08-19 并入 domain:services（原 domain:identity 退役，只退流通不删对象）。

依赖旗标（收尾简报用）

• 相关但反向：plugin-auth: no_sign_in_account_at_boot fires at ERROR on every platform-SSO tenant kernel (healthy state reported as an unrecoverable dead end) #15074（同一报告的误报方向，本席位 R+156 未处理该卡；它当时不在裸卡集）。
• 上游：A deployment with human rows and zero sys_account rows boots silently into an unrecoverable state — say so loudly at kernel:ready #14353（诊断本体与那三条 pin）· A deployment that seeds a people directory and no credentials is locked out for good: bootstrap-status and the audience bootstrap bypass both count HUMANS, not LOGINS #14349（option A，已裁）· plugin-auth: both remedies in the no_sign_in_account_at_boot report are unexecutable as written — and one of them silences the report #15588（remedy 文本，本卡由它派生）· docs(self-hosting): a directory-seeded, credential-less deployment has no documented recovery path — the published instruction points at the door invite_only shuts #14495（文档页）。
• 未见其他 open 卡的 Blocked-by: 指向本卡。

_{分诊席位 · claude-opus-5 · 本轮 R+158}

---

Generated by Claude Code

[os-warren]

Maintainer ruling recorded — 2: the probe stays existence-only; "documented, not detected" is this diagnostic's resting place until the probe is redesigned in both directions at once. Card stays open, pm:blocked on #15074.

Director seat (objectstack #12708), summon #14, session session_01LsEjuNMPitCHwEfYftZ1um, 2026-09-05T06:1xZ.

Provenance (who / verbatim / where): maintainer, live PM chat with the director seat, replying to decision batch #47 in which this card was item 3 with the recommendation 「推荐 2，且不关卡：pm:blocked on #15074」. The batch stated the options as the card's own 1 (a cheap boot-time "usable" predicate) and 2 (leave the probe). Verbatim reply: 「同意」 — 2 is adopted as recommended.

Ruled: 2. probeSignInAccountsPresence keeps its limit: 1 existence reading and the three #14353 pins that declare it intended stay as they are. The predicate the probe stands in for — "can anyone sign in" — is only computable by running the sign-in path; any cheaper "usable" predicate is a mirrored copy of the auth rules that drifts, which is the defect shape #15706 showed today on a p0. The boot line already says, since #15588, that writing any sys_account row silences this report, and content/docs/deployment/self-hosting.mdx says the same.

Not taken: 1 — its failure mode is the fires-on-every-boot direction #14353's controls exist to prevent, and it pulls directly against #15074, which reports this same probe firing falsely on healthy platform-SSO tenant kernels.

Why (① ≥50%): one predicate, two measured failure directions (silent here, noisy in #15074) — fixing one half in isolation moves the error to the other half. ② one measured population, already covered by the honest message. ③ the operator reading the boot line is told the silence condition plainly. ④ nothing added.

Reopen / continuation: when #15074 is ruled or worked, the probe is redesigned once, covering both directions, and this card's measurement is an input to that design. Blocked-by: #15074 appended to the body. A second real deployment hitting this silence before then is grounds to bring it back to the box with that deployment's shape.

State transition, same stroke: needs-user-decision → pm:blocked; priority:p2, domain:services retained. Ledger: objectstack director seat post #12708, summon #14.

---

Generated by Claude Code