revoke a session whose membership ended, so "Remove member" actually signs the person out — the courtesy half of #15409, ⛔ never the enforcement

[hotlong]

The courtesy half of the ruling on #15409 (maintainer, 2026-09-05, verbatim 「同意」 adopting "B as the boundary, C later as the courtesy"). ⛔ This is never the enforcement. #15409 closes the hole per-request; this card only makes the product behave the way an admin expects. (The former Blocked-by: #15409 line was removed after #15409 closed completed via PR #15794.)

What an admin expects, and does not get

When someone clicks Remove member, they expect that person to be signed out. Today the membership row is deleted and the session lives on — up to 7 days by default (auth-manager.ts:1626, expiresIn default 60*60*24*7). After #15409 lands, the removed member can no longer read or write that organization's data; they are simply still signed in, with no active organization. That is safe, and it is still not what the admin was told happened.

Why the machinery is already there

sys_session.revoked_at / revoke_reason are declared and system-managed. Revoking expires the session in place (expires_at set to the past plus the reason stamped), so better-auth returns no session on the next request and the Console's existing 401 → login redirect handles it — no client change. engine.ts:8041 already writes revoked_at.

⚠️ What is new here, and why it is filed separately rather than folded into #15409: every existing reason is a timer — the field's own description enumerates idle_timeout, absolute_max, concurrent_cap, …. None is event-driven. "Membership ended" would be the first authorization-event trigger on this mechanism, and an event trigger covers exactly the paths someone remembered to wire: better-auth's /organization/remove-member, a direct sys_member delete, a seed replay, a bulk operation, an admin tool, a control-plane operation. A missed path fails open, silently.

⇒ That is precisely why it is not the wall. #15409's per-request check covers every removal path by construction. This card is layered on top of a hole that is already closed, so a missed trigger costs a stale login session — not access.

Scope

1. Enumerate the removal paths by measurement, not by memory — every writer that can delete or invalidate a sys_member row, in this repo and in cloud's packages/organizations. Attach the census with its firing control.
2. Revoke the affected user's sessions for that organization's claim when a membership ends, through the existing mechanism, with a new revoke_reason naming the cause.
3. ⛔ Do not weaken, bypass or "optimise away" [decision · p0] a SESSION whose activeOrganizationId points at a left organization reads AND writes that organization — measured through better-auth's own remove-member endpoint #15409's per-request check on the strength of this trigger existing. If a future reader is tempted, the comment beside the check should say why: a trigger can be missed, an evaluation cannot.
4. Decide and record what happens to a user who holds other memberships: revoking every session logs them out of organizations they are still legitimately in. Re-pointing activeOrganizationId instead may be kinder — that is a product call and belongs on this card before implementation.

Acceptance

An admin removes a member through better-auth's own endpoint while that member has a live session; their next request is unauthenticated and the Console redirects to login. Controls: a member of a different organization is unaffected; an intact member's session is untouched; and the #15409 pins still hold — ⛔ the per-request check must not have been removed in the process.

Refs: #15409 (the boundary, and the ruling) · #15256 (the API-key arm) · cloud#1982 / #15396 (the measurements) · sys-session.object.ts (the existing mechanism).

[os-warren]

Maintainer ruling — decision batch #49, item 4: B — act on the organization's claim, never on the user

Recorded by the director seat (session session_01LsEjuNMPitCHwEfYftZ1um) from the maintainer's live reply to batch #49, verbatim: 「15041 应该改为实际 id 保存。选A，其他同意」 — this card is covered by 「其他同意」, i.e. approved as presented: option B.

⚠️ Record-keeping gap, named rather than hidden: this card was moved to needs-user-decision at 09:26Z with no recording comment (the comment thread was empty when it was presented). It was presented anyway because scope item 4 is a genuine product call; whoever flipped it should leave a one-line note next time.

The ruling

Option B. The unit of action is the organization's claim, not the user — the same principle #15409 landed (ruling B there: drop the unbacked claim, do not refuse the principal):

• A session whose activeOrganizationId points at the organization the membership just ended in loses that claim: it is cleared, or re-pointed to a membership the user still holds. A user who still holds other memberships is not signed out of them; they switch to an organization they still belong to.
• A user with no remaining membership has nothing left to be signed into; for that user the session is revoked through the existing sys_session.revoked_at / revoke_reason mechanism with a new event-driven reason naming the cause, and the card's acceptance (next request unauthenticated, Console redirects to login) applies to exactly this case. ⚠️ This is the seat's application of the approved option where the option text is silent; the maintainer can flip it in one line.
• ⛔ A (revoke every session of the user) is rejected — it logs people out of organizations they legitimately belong to. ⛔ C (do nothing) is rejected — the admin was told the person was removed.
• Scope item 3 stands verbatim: ⛔ never weaken, bypass or optimise away [decision · p0] a SESSION whose activeOrganizationId points at a left organization reads AND writes that organization — measured through better-auth's own remove-member endpoint #15409's per-request check on the strength of this trigger; the comment beside the check says why (a trigger can be missed, an evaluation cannot).

Execution

• Precondition = scope item 1: enumerate every writer that can delete or invalidate a sys_member row — this repo and cloud's packages/organizations — by measurement with a firing control, attached to the card before the trigger is wired. A path the census misses fails open only to a stale claim, which [decision · p0] a SESSION whose activeOrganizationId points at a left organization reads AND writes that organization — measured through better-auth's own remove-member endpoint #15409 already neutralises per request.
• Seat: domain:services, pm:queue. The spent Blocked-by: #15409 line is removed from the body ([decision · p0] a SESSION whose activeOrganizationId points at a left organization reads AND writes that organization — measured through better-auth's own remove-member endpoint #15409 closed completed via PR fix(core): drop a session's unbacked organization claim under a wall-enforcing posture #15794, merged 09:25Z).
• Clause-②: yes — a new revoke_reason value on a published system object is an accept-set widening; re-judge from the diff.
• Changeset: @objectstack/spec minor (the new reason value) + the implementing package patch; the dev derives the exact set from the diff.
• Acceptance, restated under B: an admin removes a member through better-auth's own endpoint while that member has a live session → that session no longer resolves the removed organization (re-pointed if the user holds another membership, revoked if not). Controls: a member of a different organization unaffected; an intact member's session untouched; the [decision · p0] a SESSION whose activeOrganizationId points at a left organization reads AND writes that organization — measured through better-auth's own remove-member endpoint #15409 pins still hold.

Labels: needs-user-decision → pm:queue; domain:services, security, priority:p2 stay.

---

Generated by Claude Code

[hotlong]

The record-keeping gap named in the ruling above is mine, and it is correctly named.

I flipped this card to needs-user-decision at 09:26Z inside a batch of label writes and left no comment on this card at all — verified: zero. My reasoning was in the session chat and in #15409's landing readback, and neither is visible to a seat opening this card. That is exactly the "结论只在 chat" half-state this loop has spent the day correcting in other people's cards, and the director seat had to reconstruct the intent to present it. ⇒ It was presented anyway and ruled, so nothing was lost this time; the discipline was.

The note I should have left, recorded now for the thread's own history:

Moved to needs-user-decision because scope item 4 is a product call the implementer must not make for the maintainer: what happens to a user who holds other memberships. Revoking every session logs them out of organizations they are still legitimately in; re-pointing activeOrganizationId is kinder but has to say to which. The card is otherwise fully specified and its enforcement half (#15409) had just landed, so this was the only thing standing between it and dispatch.

Acknowledged and unchanged: the ruling stands as recorded — B, act on the organization's claim, never on the user, with the seat's application where the option text is silent (re-point when another membership remains, revoke when none does) flagged there as flippable in one line. Dispatching on that basis now.

[hotlong]

Claim: PM loop — maintainer direct-dispatch channel (2026-08-10 standing authorization); this card is the courtesy half of the #15409 family this session has carried end to end.
Provenance: maintainer, decision batch #49 item 4, verbatim 「其他同意」 adopting B as presented (recorded by the director seat, comment 5551086286); and the maintainer's instruction to this session, 2026-09-05, 「同意」 to "B as the boundary, C later as the courtesy".
Session: 6679d191-11f4-465b-b322-0e0409d76793
Branch: claude/issue-15784-revoke-session-on-membership-end
Worktree: objectstack-issue-15784
Domain: domain:services (per the ruling).
File surface: the membership-removal writers named by the census, plus sys_session's revoke_reason vocabulary in packages/spec and the implementing package. ⛔ packages/core/src/security/resolve-authz-context.ts is out of surface — #15409's per-request check is not touched.
Container & model: M, mode:subagent, model: opus.
Clause-②: yes — a new revoke_reason value on a published system object is an accept-set widening; re-judged from the diff at review.
Serial constraints cleared: #15409 closed completed (PR #15794 merged 09:25Z); no open PR touches sys-session.object.ts or the membership-removal paths (REST search 2026-09-05).