Filed by the PM dispatch loop as option C of the ruling on #15349 (comment 5553763390). ⛔ Unassigned and ungraded — domain:*, type and priority are triage's.
The residual
The four resolveAuthzContext posture repairs censused under #15256 (item 5) all derive the tenancy posture through an async service accessor. A KernelBase-shaped host — LiteKernel, i.e. serverless / edge — exposes getKernel() but no getServiceAsync. On such a host all four repaired seams therefore resolve no posture at all, even when plugin-auth has registered tenancy as a plain instance.
That is the ruled behaviour, not a defect in any of the four cards: #15256's landed comment states such a host "keeps the previous quiet answer, unchanged", and rest-server.ts documents why — a KernelBase host has no service factories (registerServiceFactory throws "not supported"), so absence is the only fault it could report anyway, and dereferencing a missing getServiceAsync would turn "this host shape has no async registry" into an outage.
But the consequence survives the justification: on such a host, the posture-conditional guards those four cards restore (organization_required, organization_membership_ended, and the #15409 session-claim drop) stay unreachable.
What this card asks for — a MEASUREMENT, not a fix
⛔ Do not implement a fallback here. The candidate fix (fall back to the sync ctx.getService probe when no async accessor exists, justified by the same "no factories, so a throw can only mean absence" fact) is a family-wide change across all four seams, and it would re-decide a Zone-1 ruling. It belongs to all four at once or to none.
The question to answer first, cheaply:
Do plugin-auth and plugin-sharing (and the other three seams' owners) actually boot together on a LiteKernel/KernelBase host at all?
- If reachability is nil — no supported composition puts these plugins on such a host — then the residual is theoretical and the family-wide fix costs nothing to skip. Say so with the measurement and close this.
- If reachability is real, this card's output is the evidence on which a maintainer decides the family-wide change, across all four seams together.
⚠️ Answer it per-composition, from the boot code. ⛔ A grep for LiteKernel across the repo is not a reading about whether a composition exists — that failure class produced three false holds in one PM session. Any zero-hit claim needs a positive control firing on the same command and scope.
Refs
#15349 (the card whose round surfaced this, and its PR #15996) · #15350 / #15351 / #15352 (the three sibling seams, same residual) · #15256 (the census and item-5 ruling) · #13906 (decision 1 option A, the classification the seams carry) · #15409 (the session-claim drop, one of the guards left unreachable)
Generated by Claude Code
Filed by the PM dispatch loop as option C of the ruling on #15349 (comment
5553763390). ⛔ Unassigned and ungraded —domain:*, type and priority are triage's.The residual
The four
resolveAuthzContextposture repairs censused under #15256 (item 5) all derive the tenancy posture through an async service accessor. AKernelBase-shaped host —LiteKernel, i.e. serverless / edge — exposesgetKernel()but nogetServiceAsync. On such a host all four repaired seams therefore resolve no posture at all, even whenplugin-authhas registeredtenancyas a plain instance.That is the ruled behaviour, not a defect in any of the four cards: #15256's landed comment states such a host "keeps the previous quiet answer, unchanged", and
rest-server.tsdocuments why — aKernelBasehost has no service factories (registerServiceFactorythrows "not supported"), so absence is the only fault it could report anyway, and dereferencing a missinggetServiceAsyncwould turn "this host shape has no async registry" into an outage.But the consequence survives the justification: on such a host, the posture-conditional guards those four cards restore (
organization_required,organization_membership_ended, and the #15409 session-claim drop) stay unreachable.What this card asks for — a MEASUREMENT, not a fix
⛔ Do not implement a fallback here. The candidate fix (fall back to the sync
ctx.getServiceprobe when no async accessor exists, justified by the same "no factories, so a throw can only mean absence" fact) is a family-wide change across all four seams, and it would re-decide a Zone-1 ruling. It belongs to all four at once or to none.The question to answer first, cheaply:
Do
plugin-authandplugin-sharing(and the other three seams' owners) actually boot together on aLiteKernel/KernelBasehost at all?LiteKernelacross the repo is not a reading about whether a composition exists — that failure class produced three false holds in one PM session. Any zero-hit claim needs a positive control firing on the same command and scope.Refs
#15349 (the card whose round surfaced this, and its PR #15996) · #15350 / #15351 / #15352 (the three sibling seams, same residual) · #15256 (the census and item-5 ruling) · #13906 (decision 1 option A, the classification the seams carry) · #15409 (the session-claim drop, one of the guards left unreachable)
Generated by Claude Code