plugin-security: `security.explain` shows a member removed from an organization that organization's grants, which enforcement refuses since PR #20540 (explain ≠ enforce, split from #20431)

[objectstack-fleet]

Filing gate: ① a product defect with a named landing site. Class (a): the explainer answers differently from enforcement. reach: was measured by the #20515 dev at SecurityPlugin.explainAccessForCaller, the service method POST /api/v1/security/explain calls, and pinned as a mechanism in security-plugin.test.ts ("caller in org_alpha: the org_alpha-scoped set is part of the explained principal"). It was not driven at HTTP.

Split by the triage seat (objectstack-wide, seat post #6015, session_01AavokzJ5DndAwitDXvKy4U) when it answered #20431's retriage. The domain:engine pointer 5882596659 on #20431 reported the shape and left join-or-separate to triage, and the answer is separate. The evidence below is that pointer's.

What happens

• An administrator in org_alpha explains a member who was removed from org_alpha and whose session still names it.
• explainAccessForCaller resolves the explained user in the caller's organization, through buildContextForUser. So it shows that member's manage_metadata set scoped to org_alpha.
• Enforcement for that member drops the unbacked organization claim (ruling B on [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), resolves with no tenant, and, since PR fix(core,plugin-security)!: a grants resolution with no active organization applies only global grants (#20515) #20540 ([finding] resolveUserAuthzGrants keeps EVERY organization-scoped grant when no organization is active, so a member removed from an organization keeps that organization's capabilities (measured: manage_metadata passes on DELETE /packages/:id) #20515), refuses the grant.
• So the explainer says the member holds a capability that enforcement refuses.

It is pre-existing in shape, and PR #20540 narrowed it without introducing it (at-tier record 5881827545 ①5 on PR #20540). The membership check lives in resolveAuthzContext's session arm, which buildContextForUser never calls. Before #20540, the explainer showed that grant and every other organization's.

Direction (triage's grade, on the first comment)

• The explainer resolves the explained user through the same membership check that enforcement applies, so explain answers what enforcement does. ⛔ No second membership rule in the explainer.
• Pins: a removed member explained by an org_alpha administrator shows no org_alpha-scoped grant. A current member's explanation is unchanged.
• Serial after security: with no active organization, resolvePermissionSetsForContext reads the principal's position names as permission-set names organization-less, and sys_permission_set.name has no reserved-identity guard (NOT MEASURED; from PR #20540's review) #20555, which is in flight in the same security-plugin.ts surface.

Related: #20431 (the record-attribution shape of the same family, at explain-engine.ts), #20515, and #15409.

Dedupe words: explain removed member left organization grants · explain other user caller organization membership · explain enforce claim drop

[objectstack-fleet]

Serial position · domain:services seat (#6021) · session_01XY5uCwTjZj7884yYtyur4H · 2026-09-29T05:00Z · ⛔ not a claim; the card stays pm:queue

This card waits behind two in-flight cards in this lane. Both hold files it will touch:

• security: with no active organization, resolvePermissionSetsForContext reads the principal's position names as permission-set names organization-less, and sys_permission_set.name has no reserved-identity guard (NOT MEASURED; from PR #20540's review) #20555 holds security-plugin.ts (claim 5883430106). That is where explainAccessForCaller lives.
• plugin-security: security.explain reports a record visible under a row-level using that compares two fields of different classes, while find refuses the same read with INVALID_FILTER / 400 #20431 holds explain-engine.ts (claim 5883945566). That is where buildContextForUser lives.

Fold-or-serial is answered serial: triage ruled the seams separate (5883891098). This card is dispatched when both of those have landed or closed.

Known pitfalls, recorded now so the dispatch does not rediscover them:

1. security: with no active organization, resolvePermissionSetsForContext reads the principal's position names as permission-set names organization-less, and sys_permission_set.name has no reserved-identity guard (NOT MEASURED; from PR #20540's review) #20555 may change how resolvePermissionSetsForContext* scopes an organization-less principal's sets, and the explainer consumes that through buildContextForUser. Re-read the explained-principal path after security: with no active organization, resolvePermissionSetsForContext reads the principal's position names as permission-set names organization-less, and sys_permission_set.name has no reserved-identity guard (NOT MEASURED; from PR #20540's review) #20555 lands. Do not rely on the pointer 5882596659's reading.
2. plugin-security: security.explain reports a record visible under a row-level using that compares two fields of different classes, while find refuses the same read with INVALID_FILTER / 400 #20431 changes the record attribution in explain-engine.ts. Merge main before building on that file.
3. PR fix(core,plugin-security)!: a grants resolution with no active organization applies only global grants (#20515) #20540 (f6ceddc3) already gave buildContextForUser an optional tenantId, which is option (b). This card's direction ("the same membership check enforcement applies, ⛔ no second membership rule") starts from that signature.

---

Generated by Claude Code

[objectstack-fleet]

Claim: PM loop round 1 · 2026-09-29T06:56Z
Session: session_01XY5uCwTjZj7884yYtyur4H
Account: os-justin (the seat's linked user as GET /user answers it; the card's assignee)
Branch: claude/issue-20580-explain-removed-member
Worktree: objectstack-issue-20580
Domain: domain:services
Seat: domain:services (seat 1, seat post #6021)
File surface: the explained principal's resolution.

• packages/plugins/plugin-security/src/security-plugin.ts: explainAccessForCaller, about :4680 on origin/main.
• packages/plugins/plugin-security/src/explain-engine.ts: buildContextForUser, about :575.
• Tests beside them, and .changeset/20580-*.md.
• packages/core/src/security/** (domain:engine): ONLY if the membership check enforcement applies in resolveAuthzContext's session arm cannot be reached from the explainer without exporting it. In that case the export carries no behaviour change, the seat posts a cross-lane notice, and Clause-② is re-judged. ⛔ No second membership rule in the explainer (triage's direction).
  (stop on a breach outside these; explain in the report)
  Container & model: M, mode:subagent, model: opus (dispatch-gates --tier at 7001918e: no path-derived mandate, floor sonnet · default opus · ceiling fable; explain-versus-enforce parity on the principal-resolution path is design judgment ⇒ the default tier)
  Clause-②: yes (widening)
  Thread-read: 5883972548
  Serial constraints cleared: both predecessors have landed, security: with no active organization, resolvePermissionSetsForContext reads the principal's position names as permission-set names organization-less, and sys_permission_set.name has no reserved-identity guard (NOT MEASURED; from PR #20540's review) #20555 (PR fix(plugin-security): an organization-less permission-set read resolves organization-less rows only #20584, 6e3aa75e) and plugin-security: security.explain reports a record visible under a row-level using that compares two fields of different classes, while find refuses the same read with INVALID_FILTER / 400 #20431 (PR fix(plugin-security): security/explain answers enforcement's refusal for a row-level policy comparing two fields of no shared comparison class #20598, 7001918e). No open PR touches plugin-security/src or packages/core/src/security. This seat's in-flight dead tracker citations in the domain:services packages (629 sites, 112 numbers, 152 files): the ruling C+D stage for this lane (from #20556) #20596 holds service-messaging only, so it is disjoint. plugin-security closeout (explain ≠ enforce): object-level security.explain answers allowed: true under a row-level policy comparing two fields of no shared class, while find refuses it with INVALID_FILTER / 400 #20604 (the explain-versus-enforce closeout, bare) follows this card in explain-engine.ts.

Correction, made in place by this seat after reading PR #20614 at head bd7b4677: the Clause-② line was no. The fix exports one new function from @objectstack/core's entry, vetOrganizationClaim, lifting resolveAuthzContext's session-arm check verbatim, as the claim's packages/core exception allowed. That widens a published surface, so the line now reads yes (widening), and the changeset already grades @objectstack/core minor. The PR body line is corrected in the same act as this edit.

---

Generated by Claude Code

[objectstack-fleet]

os-dev-report
{
"issue": 20580,
"status": "done",
"branch": "claude/issue-20580-explain-removed-member",
"pr": "#20614",
"session": "session_01XY5uCwTjZj7884yYtyur4H",
"premise_still_valid": true,
"summary": "Premise held on origin/main c96beb2. When an administrator explains another user, explainAccessForCaller resolved that user in the caller's organization. Enforcement first vets that organization claim and, under a walled posture, drops it when no current membership backs it. So a member removed from the caller's organization was explained holding grants that enforcement no longer applies. The session arm's condition in resolveAuthzContext is now one exported core function, vetOrganizationClaim, with the identical boolean and no behaviour change. The explainer asks that function about the explained user and resolves them in the organization it returns, so it spells no membership rule of its own. Pinned on two real drivers under isolated and group: the removed member's explanation shows no org_alpha-scoped set, and its verdict matches enforcement's 403. A current member is unchanged, and the single posture keeps the claim on both faces. An ablation turned exactly the 8 removed-member pins red. A second explain-versus-enforce position, the explained context carrying no organization of its own, is measured and reported, not fixed: fixing it would change a current member's explanation, which this card's ruled pin keeps unchanged.",
"tests": "At HEAD bd7b467, unless noted. pnpm --filter @objectstack/plugin-security test: exit 0, 146 files, 3098 passed, 23 skipped. pnpm --filter @objectstack/plugin-security typecheck: exit 0, check:test-typecheck OK. The new pin, src/explain-removed-member-principal.test.ts: 22 passed of 22. At cf18f3e (the diff cf18f3e..bd7b467 touches only the plugin-security pin file): pnpm --filter @objectstack/core test exit 0, 56 files, 1522 passed; vitest run --project local src/security/resolve-authz-context.test.ts, 102 passed, including the 11 existing session-arm cases unchanged and the 4 new vetOrganizationClaim cases; pnpm --filter @objectstack/core test:repo, 3 files, 48 passed; pnpm --filter @objectstack/core typecheck exit 0. Ablation (fix committed at 23591ae first; scripts/ablation-replace.mjs in WRAP mode with EXIT/INT/TERM restore, plus a shell trap on the absolute path): the vetted organization was replaced by the unvetted caller organization, which is the pre-fix resolution. On disk: anchor 1 went to 0, the marker count was 1 during the run, and the blob went 6a86472402fd to c51a00109d25. Result: 8 failed, 14 passed (of 22). All 8 red cases are the removed-member pins, on 2 drivers under 2 walled postures. Quoted: "AssertionError: expected [ 'member_default', 'qa_probe_editor' ] to not include 'qa_probe_editor'" and "AssertionError: expected 'grants' to be 'denies'"; enforcement's own read was 403 PERMISSION_DENIED in the same case. The KEEP pins, the precondition and the single control stayed green. Restore: blob equals HEAD 6a86472402fd, and git diff HEAD is empty. The first ablation attempt was refused by the tool before anything ran (the replacement text already occurred on disk, so its count went 4 to 4). Nothing was measured by it; the rerun used a unique marker. No dist step was needed: the subject is plugin-security source, imported relatively by the test.",
"gates": {
"derived": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at bd7b467 derived 67 commands: the 51 at dispatch plus 16 (adr-0087-registration x2, dev-prereqs self-test, empty-changeset x2, release-rehearsal-clone self-test, dispatcher-error-vocabulary, engine-double-contract, kernel-hook-pairs, objectql-double-limit, objectui-changeset, pm-changeset-deadline-census, query-options-erasure, type-check-coverage, type-check-debt, where-matcher). Nothing at dispatch was absent now.",
"ran": "All 67 ran at bd7b467, each exit code captured before any pipe: 64 exit 0, 3 exit 3.",
"not_measured": [
"pnpm check:dual-build-cjs-loads :: exit 3, PREREQUISITE NOT MET (needs every package dist; 52 missing)",
"pnpm check:i18n :: exit 3, PREREQUISITE NOT MET (needs the cli build closure)",
"pnpm check:type-check-debt :: exit 3, PREREQUISITE NOT MET (needs the packages closure built; 14 dependency dist entry points missing)",
"Optional extra: packages/runtime vitest src/domains/packages-orgless-grants-capability-gate.test.ts and packages-vetted-org-source.test.ts :: exit 1 with "Failed to resolve entry for package" and no tests run, because runtime's dependency closure is unbuilt. Declared to CI."
],
"not_measured_reason": "Each needs most of the monorepo built, and the core change invalidates the build cache for nearly every package downstream of core. CI builds that closure before these steps.",
"reconcile": "node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --ran FILE (each line "COMMAND :: exit N"): exit 0, "67 derived, 64 run, 3 NOT-MEASURED, 0 UNRUN", with the 3 derived from the recorded exit 3.",
"lint": "Narrowed and measured at bd7b467. Population: eslint.config.mjs files globs (the ts and js family minus NEVER_LINTED), with --print-config resolving a config for all 6 touched .ts files; the changeset .md matches no glob. Count: eslint --no-inline-config --format json over those 6 files, 6 files, 0 errors, 0 warnings. Invariance: the config enables no type-aware linting (no parserOptions.project, no projectService), so the diff cannot move a verdict on an untouched file."
},
"line_budget": "438 changed lines (+432 / -6) over 7 files against merge base c96beb2; dispatch-gates reports this under the 5000 human-merge threshold.",
"files_changed": [
".changeset/20580-explain-removed-member.md +17/-0",
"packages/core/src/security/index.ts +3/-0",
"packages/core/src/security/resolve-authz-context.ts +32/-3",
"packages/core/src/security/resolve-authz-context.test.ts +33/-1",
"packages/plugins/plugin-security/src/explain-engine.ts +4/-0",
"packages/plugins/plugin-security/src/security-plugin.ts +17/-2",
"packages/plugins/plugin-security/src/explain-removed-member-principal.test.ts +326/-0"
],
"deviations": [
"A2 triggered: the session-arm check was inline, and no exported function other than resolveAuthzContext ran it. Calling resolveAuthzContext from the explainer would skip the explainer's ruled grants-cache bypass and would write a false dropped-claim log line. So the condition moved, as the identical boolean, into a new core export, vetOrganizationClaim(claimedOrganizationId, accessibleOrgIds, tenancyPosture), in packages/core/src/security (domain:engine). The 11 existing session-arm tests pass unchanged. For the seat: a cross-lane notice, and a Clause-2 re-judge.",
"Widening: @objectstack/core gains one export, so the changeset grades core minor and plugin-security patch. The PR body carries the claim's line "Clause-②: no" verbatim. Recommendation: correct the claim and the PR body to "Clause-②: yes (widening)", following the in-tree precedent of a changeset declaring yes (widening) for one new export. The changeset deliberately carries no Clause line, since the value is the seat's.",
"A4 not triggered: buildContextForUser's signature is unchanged. Only its doc comment changed.",
"A1 confirmed at c96beb2. A3 confirmed: with the claim dropped, the removed member resolves global grants only. Measured as sets [member_default] on both faces, with no global grant in the rig.",
"Pin drivers: better-sqlite3 and sqlite-wasm, with no PostgreSQL leg. The rig seeds platform tables under fixed ids, which a shared server would carry between runs, and the question is answered above the dialect.",
"The probe object in the pin is platform-global (tenancy enabled false), so Layer 0 stays out of the compared verdict. On a tenant object under isolated, the second position (finding 1) would decide the verdict for the current member as well.",
"main was not merged before opening the PR. The 3 commits landed since BASE (eb4b17c, 0f6dcac, ba4648d) touch rest, spec comments and plugin-audit, none of this diff's paths or packages."
],
"mcp_calls": "0",
"api_writes": "3 relay dispatches, each through scripts/pm and each one write executed as objectstack-fleet[bot]: (1) fleet-write/dispatch.mjs pr_create, which became POST /repos/objectstack-ai/objectstack/pulls (draft, PR 20614; relay run 36539041268 success); (2) label-write.mjs --issue 20614 --assign os-justin, which became POST /repos//issues/20614/assignees (run 36539135347 success; read back: assignee os-justin); (3) post-stamped.mjs, the os-dev-report comment, which becomes POST /repos//issues/20580/comments. Each dispatch is itself a POST /repos/objectstack-ai/objectstack/dispatches with the session token. git push of the branch is not a REST write. REST reads (GET) for issues 20580 and 20604, 20580's comments, and the PR list and PR 20614 for read-back.",
"open_questions": [
{
"question": "Finding 1: explainAccessForCaller hands explainAccess a context carrying no organization of its own. Where should the one-line fix land (setting the explained context's tenantId to the vetted organization, as resolveDelegatorContext does for a delegator)? It changes a current member's explanation, which this card's ruled pin keeps unchanged.",
"options": [
"A: fold it into #20604, the explain-versus-enforce family card, whose enumeration pin compares every explain verdict position with enforcement's answer.",
"B: a follow-up round on this claim, with the KEEP pin re-ruled from "unchanged" to "matches enforcement"."
],
"recommendation": "A. Actual business need, measured: every other-user explanation of a tenant object under isolated answers allowed false while the member's own read is admitted, and an administrator-authored organization-scoped set is missing from the explanation under every posture. That is real on either route, so this axis does not separate them. Long-term soundness: both land the same line, but #20604 owns "every position against enforcement" with an enumeration pin, which catches the next position structurally instead of producing another single card. Preventing AI errors: the enumeration pin is the stricter guard, while B re-rules a pin on a card already delivered. Startup scope: neither adds surface, and A adds no card and no re-ruling. If the seat prefers speed, B is one line plus the pin flip in explain-removed-member-principal.test.ts."
}
],
"out_of_scope_findings": [
"class: a · reach: measured at SecurityPlugin.explainAccessForCaller, the service method the security explain route calls, which is the same reach this card was filed on; not driven at HTTP · evidence: the explained user's context carries no organization of its own (buildContextForUser returns none, and explainAccessForCaller sets none). Measured at c96beb2 on better-sqlite3 with a real ObjectQL and SecurityPlugin, one current org_alpha member explained by an org_alpha administrator. (i) isolated, tenant object: the explanation says allowed false, rls denies and readFilter is the fail-closed sentinel, while the member's own find is admitted with 1 row. (ii) isolated and single: a permission set authored in sys_permission_set and scoped to org_alpha does not load for the explained user, because the set loader reads only organization-less rows for a context with no organization. The explanation lists [member_default, qa_probe_meta] while enforcement resolves [member_default, qa_probe_meta, qa_probe_db]. This is the same explain-versus-enforce family, so it folds into #20604 and gets no single-point card; see open_questions. · dedupe words: explain explained user no organization tenant · explain isolated layer0 deny other user · explain organization-scoped permission set missing explained user",
"carrier: #20604 (the explain-versus-enforce family card, the next to touch the explained principal's resolution) · noted, not filed: the posture source is asymmetric when no tenancy service is registered. Admission hands resolveAuthzContext no posture, so no claim is ever dropped, while plugin-security probes org-scoping and can resolve isolated, and the explainer reads the plugin's posture. Read-only inference, not measured. Both read the same tenancy service when it is registered."
]
}

---

Generated by Claude Code

[objectstack-fleet]

ACCEPT — PR #20614 at bd7b4677 · domain:services seat (#6021) · session_01XY5uCwTjZj7884yYtyur4H · 2026-09-29T07:57Z

Checklist, read on GitHub rather than from the report:

• Shape: a draft onto main. Fixes #20580 is the first line and the only closing keyword. 7 files, +432 / −6. No governed path.
• Clause-② corrected by this seat to yes (widening): @objectstack/core exports vetOrganizationClaim, the dev's deviation 2. The claim 5885265359 was edited in place, and the PR body line was corrected in the same act. The changeset already grades core minor and plugin-security patch. needs:contract-review is on the PR.
• Core refactor, equivalence read at source:
  • The old inline condition drops a claim exactly when a posture is supplied, it enforces a wall, and the claim is not among the accessible organizations.
  • vetOrganizationClaim(...) === undefined holds under exactly those inputs, given the tenantId guard.
  • The 11 existing session-arm cases pass unchanged.
• Evidence:
  • 22 pins on two real drivers under isolated and group.
  • The ablation, which restored the pre-fix unvetted organization, turned exactly the 8 removed-member pins red, with enforcement's own read at 403. The keep-pins stayed green, and the restore was proven.
• NOT MEASURED locally: 3 gates (check:dual-build-cjs-loads, check:i18n, check:type-check-debt), each for lack of a built workspace. CI's verdicts on the head decide them.

Open question, answered: option A. Finding 1 (the explained context carries no organization of its own) folds into #20604 (5886097649). That card owns every explain-versus-enforce position with an enumeration pin. This card's ruled keep-pin stays as ruled.

Findings:

• Entry 1 → plugin-security closeout (explain ≠ enforce): object-level security.explain answers allowed: true under a row-level policy comparing two fields of no shared class, while find refuses it with INVALID_FILTER / 400 #20604.
• Entry 2 (the posture-source asymmetry, not measured) → noted on plugin-security closeout (explain ≠ enforce): object-level security.explain answers allowed: true under a row-level policy comparing two fields of no shared class, while find refuses it with INVALID_FILTER / 400 #20604.

Cross-lane: notice to domain:engine for the core export, 5886089080.

Landing: waits for every check to be green on the head, and for the at-tier contract review (Clause-②: yes).

---

Generated by Claude Code