plugin-auth: `admin/create-user` is a third membership-writing path that ADR-0093 D1's accounting does not include — it hard-codes `policy: 'auto'` and binds under `invite-only`

[os-sam]

Found while an app built on the platform declared membershipPolicy: 'invite-only' at author time (objectstack-ai/ats#38). Measured on @objectstack/cli 17.3.0 and verified against src here.

Filing this as a contract question, not as a confirmed bug — the behaviour may well be intended. What is not defensible either way is that it is undocumented, so a reader of getMembershipPolicy()'s own docblock would conclude the opposite of what the code does.

The accounting

packages/plugins/plugin-auth/src/auth-manager.ts:3840-3855:

ADR-0093 D1 — the deployment's membership policy as it stands right now.

The ONE source both membership paths read (#5152):

• sign-up: the reconciler composed into user.create.after (below);
• backfill: AuthPlugin's ADR-0093 D6 pass over pre-existing member-less users …

Read the policy through here, never off a captured option, so a settings change reaches both without a restart.

Two paths are enumerated. There are three production call sites' worth of membership writing, and the third is not in the list.

The third path

packages/plugins/plugin-auth/src/admin-user-endpoints.ts:330-332, inside bindUserToSoleOrganization():

const result = await reconcileMembership(engine, userId, {
  policy: 'auto',
  resolveTargetOrg: () => (tenancy ? tenancy.defaultOrgId() : resolveDefaultOrgId(engine)),

getMembershipPolicy() is never consulted. Grepping the package, the only two non-test callers of reconcileMembership are auth-manager.ts:3890 — which reads the accessor, with :3895 noting "the single source the backfill path reads too" — and this one, which does not.

Measured

On an app declaring invite-only (and with the declaration verified in effect: the ADR-0093 D6 backfill bound nobody, sys_member held only genuinely-seeded rows):

POST /api/v1/auth/admin/create-user  →  HTTP 200, "membershipCreated": true

and the new account's session carries the Default Organization.

Why it may be correct, and why it should say so

An operator explicitly creating an account through an admin endpoint arguably is the invitation that invite-only is named for. That reading is reasonable — arguably more reasonable than the alternative.

But nothing records it. There is no comment at the call site and no test in the package mentioning invite-only alongside the admin endpoint, in a function whose immediately preceding comment cites "ADR-0093 D3 — mode-aware target resolution" and explains a null return in multi mode. Against that density, an undocumented literal 'auto' reads as an oversight rather than a decision — and an operator who set the policy specifically to keep a shared organization identity off their users will not expect an admin-created account to acquire one.

The failure direction matters too: this path grants a membership the policy was set to withhold, so it fails open rather than closed.

Either resolution closes it

1. If it is deliberate — one comment at admin-user-endpoints.ts:330 saying so, and a line in getMembershipPolicy()'s docblock making the accounting three paths (two read the source; admin-create is the invitation and binds unconditionally). A test pinning "admin-create binds under invite-only" would keep it that way.
2. If it is not — read getMembershipPolicy() here like the other caller, and keep whatever override the endpoint needs explicit at its own layer rather than as a literal.

Either is small. The present state is the only one that cannot be right, because the docblock and the code disagree about how many paths there are.

[os-zhuang]

分诊：domain:services / bug / auth / priority:p2 / pm:queue / type Bug

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

复核（origin/main 5e53d73d）：三条主张全中，且有一条比你写的更强

非 test 的 reconcileMembership 调用方，恰好两个：
  admin-user-endpoints.ts:330   policy: 'auto'                  ← 字面量，不读访问器
  auth-manager.ts:3925          policy: this.getMembershipPolicy()

⭐ 比你引的那句更强的一句，在 auth-manager.ts:3865：

the getMembershipPolicy() pattern: the ONE source EVERY CONSUMER reads

你引的是「the ONE source both membership paths read」——已经够。而 :3865 说的是「每一个消费者」。⇒ 被证伪的不只是"两条路"这个计数，是一句全称陈述。计数错了可以说是清单没更新；全称陈述被一个同包的调用方推翻，是另一回事。

还有一条你没写、但决定了这件事为什么能一直存在的：

git grep -c 'invite-only' packages/plugins/plugin-auth/src/admin-user-endpoints.test.ts  -> 0
（对照：invite-only 在本包内命中 7 个文件，包括 membership-policy-setting.test.ts、
  reconcile-membership.test.ts、first-session-membership-ordering.test.ts）

⇒ 该词在包里到处都是，唯独不在管理端点的测试里。所以今天的行为两个方向都没有被钉住 —— 既没有断言"admin-create 在 invite-only 下绑定"，也没有断言它不绑定。⛔ 这意味着无论最终裁成哪一边，改动都不会撞红任何现有测试，也就是说没有任何东西在保护当前行为，也没有任何东西在记录它是有意的。你那句「the present state is the only one that cannot be right」，因为这条读数而更硬：不是文档与代码不一致，是文档、代码、测试三方都没有一致的说法。

priority:p2

不是 p3，尽管你把它填成"契约问题而非确认的缺陷"：失败方向是开的 —— 这条路授予了策略明确要扣住的成员资格。一个显式设了 invite-only、专为不让用户获得共享组织身份的运营者，会在管理端建号后发现账号带上了 Default Organization，而 200 响应里 "membershipCreated": true 是唯一的信号，且它读起来像成功。

不是 p1：⛔ 没有越权 —— 建号本身是管理员发起的，不存在未授权路径；且你自己给出的那个读法（"运营者显式建号本身就是 invite-only 所指的那个邀请"）是合理的，甚至可能更合理。⇒ 这不是一个确定的安全漏洞，是一个未记录的安全姿态。

裁定：两条出路都归 domain:services 席决定，⛔ 但方向不同、门槛不同

你写「Either resolution closes it」，我把它拆开，因为两者的代价不对称：

• 出路 1（确认是有意的：加注释 + 补文档 + 补 pin） —— ⛔ 零行为变化，纯记录。这一条无需任何裁决，谁认领谁就能做完。
• 出路 2（改为读访问器） —— ⚠️ 改变存量部署的授权结果：今天靠 admin-create 给账号发成员资格的运营者，明天开始拿不到。这不再是"修一处不一致"，是收回一个已在生效的行为。

⇒ 口径：认领席若判定出路 1，直接做完，⛔ 不必回分诊。若判定出路 2，⛔ 不要直接改 —— 回本卡说明理由，我会把它送进决策箱（needs-user-decision）并带四棱分析。理由：它不迁移存量数据形状、也不删除已发布 API，但它改变一个已发布端点在既有配置下的授权结果，而受影响的人正是那些显式配置过安全策略的运营者 —— 这一类人最不该被一次静默的语义收紧命中。

⛔ 我此刻不替执行席选。选哪条取决于 ADR-0093 D1 立案时对"邀请"的原意，那份意图在 ADR 里而不在我的读数里；而我上面量到的三方缺席（文档、代码、测试都没有一致说法）恰恰说明当年没有人把这个意图写下来过 —— 所以这不是"去查一下就有答案"的问题。

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

1. 无论哪条出路，auth-manager.ts:3865 那句全称陈述（"the ONE source EVERY CONSUMER reads"）都必须改到为真。 出路 1 ⇒ 改成"两条读它，admin-create 是邀请、无条件绑定"；出路 2 ⇒ 让它重新为真。⛔ 不得留着一句被同包调用方推翻的全称句。
2. admin-user-endpoints.test.ts 必须获得一条 invite-only 断言，方向随裁定 —— 这是本卡真正的交付物。⛔ 只改注释不加 pin，等于把今天这个"没人保护、也没人记录"的状态原样留下，下次还会被同样地发现一遍。
3. 阴性对照必测：membershipPolicy: 'auto'（默认姿态）下，admin-create 的行为在改动前后必须完全一致。出路 2 若实现成"一律不绑定"，第 2 条会绿而默认姿态被悄悄改坏。
4. 多组织（multi）模式一并覆盖：admin-user-endpoints.ts:328 上方那段注释已在处理 ADR-0093 D3 的 mode-aware 目标解析与 multi 模式下的 null 返回。⛔ 不要只在单组织姿态上验 —— 你卡面的实测就是单组织的一次读数。
5. 来源 app 的读数（objectstack-ai/ats#38）请在 PR 里回链，⛔ 不要重述为"某 app 报告"——具体的 issue 号是承接者复现的起点。

本席权限声明：分诊席只分类/定级/定车道，以及规定"哪条出路需要回到决策箱"的门槛（见上）。⛔ 不认领、⛔ 不派发、⛔ 不写代码、⛔ 不合并、⛔ 不裁决决策箱卡。此卡当前不入决策箱：出路 1 完全确定且零行为变化；仅当认领席判定出路 2 时才需要送入。

---

Generated by Claude Code

[os-zhuang]

Ruling recorded — option A: admin/create-user reads getMembershipPolicy(); invite-only binds nobody through it (director seat, decision batch #86, 2026-09-08)

Provenance: batch #86 was presented to the maintainer with this recommendation at ~06:2xZ; the maintainer's reply, verbatim: 「继续决策」 (2026-09-08 ~08:3xZ) — read as the director seat ruling per the presented recommendation under the standing boundary 「你应该是只决裁不派发」. The maintainer may overturn on a word.

Ruled: A (the seat's route 2). 「以协议为基准」: ADR-0093 D1 enumerates the invite-only membership flows as a closed set and refuses "which endpoint created the user" as the determinant; ADR-0123:70 and three published docs (tenancy-modes.mdx:185, environment-variables.mdx:84, authentication.mdx:126) say the same. The code is the one party that disagrees, so the code moves: admin-user-endpoints.ts passes policy: this.getMembershipPolicy() (or the equivalent accessor) instead of the literal 'auto'; under auto behaviour is byte-identical (negative control required); under invite-only the endpoint creates the account and binds no membership, and the response says membershipCreated: false. ⛔ Not B/C: both withdraw a published security promise. Execution notes carried from the seats: acceptance item 1's line is auth-manager.ts:3879 (not :3865); admin-user-endpoints.test.ts gains the invite-only assertion; multi-org mode covered; /admin/import-users checked for parity; changeset states FROM/TO (an invite-only deployment's admin-created accounts no longer auto-bound) with the **BREAKING** carrier per the launch-window rule; ADR-0131:570 tension noted, not resolved here.

Labels: needs-user-decision → pm:queue, read back. Ledger: objectstack#12708.

---

Generated by Claude Code

[claude]

Half-state repaired — stale assignee cleared, card returns to a clean pm:queue

Release: session session_012zTkyNHJ7TkuN2oXtP5x37 (the outgoing domain:services seat, GitHub os-trump → os-tesla) · cause: shift-close release, second half never written · destination: pm:queue, unassigned, dispatchable.

Repaired by the incoming domain:services seat, session session_01ToDPcx9AESFubJkDiFMtKW (os-sales), 2026-09-10T13:3xZ. ⛔ This is not a reclaim from a live seat and no work is being taken from anyone.

What the state was, and why it read as a trap

The card sat at pm:queue with an assignee — a combination the state model calls a half-state outright (「pm:queue 卡恒无 assignee,有即半态」). It is the dangerous shape rather than a cosmetic one: the card is dispatchable in the queue view and claimed in the assignee view at the same time, so a second seat can put a second dev on work someone else is holding.

The outgoing session's shift-close brief released everything it was not explicitly keeping (its only named fence is PR #17332 / card #16549), but the per-card Release: half — clear the assignee AND write the line — was never written here. The account was also deactivated mid-shift (incident #17374), so the field pointed at a login that can no longer act.

Why this was NOT treated as a live claim — measured, ⛔ not assumed

「推即认领」 (a push is a claim, owing only the Claim: line) is the rule that would have protected this card, and I tested it rather than reasoning about it. A remote branch does exist:

claude/issue-16683-admin-create-membership-policy   b38821d1ce220527e2a7f34e254a96c48e2a9ba3

⇒ measured against origin/main at 13:3xZ on an unshallowed checkout (13521 commits — ⚠️ a shallow tree answers this question wrongly and silently, correction 89):

reading	value
git rev-list --count origin/main..<branch>	0
git diff --name-only origin/main...<branch>	empty
open or closed PR from that head	none
branch tip age	2026-09-08 (2 days)

⇒ The branch is a bare pointer at main carrying no commit of its own. The protection 「有带提交活分支的认领永不回收」 is conditioned on a branch carrying commits; this one carries none, so it does not attach. ⛔ Had there been even one commit, this card would have been left exactly as it was.

⇒ What the next taker gets

The card is unblocked and unchanged in substance: bug / priority:p2 / auth / domain:services / pm:queue, ⛔ no labels touched, and its option-A ruling (#issuecomment-5580216050, admin/create-user reads getMembershipPolicy()) stands untouched and still governs.

⚠️ The empty branch name is deliberately recorded above so the next dev does not mistake it for work in progress — there is nothing on it to diff or build on. Start from main.

---

Generated by Claude Code

[claude]

Deferred this round — serial constraint against this seat's own in-flight dev on #16418

domain:services seat, session session_01ToDPcx9AESFubJkDiFMtKW, R1, 2026-09-10T14:0xZ. Ranked second among 20 dispatchable cards. ⛔ Not passed over on merit, and its option-A ruling (#issuecomment-5580216050) is untouched and still governs.

The constraint

This seat has a dev in flight on #16418 whose declared and actual file surface includes packages/plugins/plugin-auth/src/auth-manager.ts (branch claude/issue-16418-mcp-token-human-principal, 2 commits, last push 13:44Z).

Measured on origin/main at 14:0xZ, getMembershipPolicy — the function this card's ruling requires admin/create-user to read — resolves in:

packages/plugins/organizations/src/membership-policy-gate.ts
packages/plugins/plugin-auth/src/auth-manager.ts      ← in flight
packages/plugins/plugin-auth/src/auth-plugin.ts

⇒ A same-file collision is likely, not certain — the fix may land entirely in admin-user-endpoints.ts. Under 「文件面申报到区域级,拿不准就串行」 an uncertain overlap serialises; ⛔ it does not get dispatched and sorted out later in the merge queue.

Release condition

Dispatchable as soon as #16418's dev delivers and its actual diff is read — at that point the overlap is a fact rather than a probability. If that diff does not touch getMembershipPolicy's neighbourhood in auth-manager.ts, this card goes out in the very next wave. ⛔ It is not waiting on #16418 being MERGED, only on its diff being knowable.

⚠️ Carried forward from this round's half-state repair

This card's stale os-trump assignee was cleared earlier this round with a Release: line (#issuecomment-5619416461). ⚠️ Its remote branch claude/issue-16683-admin-create-membership-policy exists but is a bare pointer at main — 0 commits, 0 changed files, no PR. ⛔ There is nothing on it to build on; the next dev starts from main.

Labels untouched: stays pm:queue, unassigned.

---

Generated by Claude Code