After all four tenancy-posture seams land: fold their local resolveAdmissionTenancyPosture copies onto one helper — the CLASSIFICATION only, not the resolution

[claude]

Filed by the PM dispatch loop as option A of an open question from the #15350 round (PR #16011). ⛔ Unassigned and ungraded — domain:*, type and priority are triage's.

⛔ BLOCKED until all four tenancy-posture seam cards land: #15349 (PR #15996), #15350 (PR #16011), #15351, #15352. ⛔ Do not start before then — a helper extracted while any of them is in flight collides with the others, which is exactly why each of the four was told not to extract one.

What exists now, and why it was deliberate

Four seams each supply tenancyPosture to resolveAuthzContext through a local, private resolveAdmissionTenancyPosture, each copying the classification structure of packages/rest/src/rest-server.ts:2458-2502: never-registered (isServiceNotRegisteredError) ⇒ quiet undefined; every other rejection ⇒ AuthzStoreUnavailableError('tenancy', err). No shared helper was extracted, on the PM's instruction, because four in-flight cards cannot each extract the same one.

The case for folding them: the bodies are the same shape, and the classification is the part nobody may get wrong — a quiet catch at any one of them re-opens #13906. One tested helper is worth more than four correct copies that must each stay correct forever.

⚠️ The constraint that makes this card non-trivial, measured on #15350

The four seams are NOT byte-identical, and a helper that erases the differences would be WORSE than the copies.

• rest-server.ts branches on kernel-vs-provider — two wirings, and asking twice would let a provider bound to the local kernel answer for a request that resolved to another environment.
• plugin-sharing: the exec-context seam supplies no tenancyPosture to resolveAuthzContext — an ex-member's org-stamped API key keeps its claim #15349 (plugin-sharing) and service-datasource: the admin routes supply no tenancyPosture to resolveAuthzContext — an ex-member's org-stamped API key is admitted #15350 (service-datasource) read ctx.getKernel().
• Each carries a different reason why the absence of the async accessor must stay quiet. Those reasons are not interchangeable prose; they are per-seam justifications.

⇒ The extractable part is the try/catch CLASSIFICATION, not the resolution. A helper should take an already-resolved service (or a resolver callback) and own only the branded/unbranded decision. Anything that also owns how the service is reached will either be wrong for one of the seams or grow a flag per seam, which is the copies again with extra steps.

Natural home: @objectstack/core, beside effectiveTenancyPosture (packages/core/src/security/index.ts:93), which all four already import.

Scope when unblocked

Fold the four call sites plus rest-server.ts's two branches onto the one helper. ⚠️ Re-measure the seam count before starting — the census was 2 of 8 when these cards were written and was 4 of 8 by the time #15349 landed; it will be higher again once this family lands.

Refs

#15349 / PR #15996 · #15350 / PR #16011 · #15351 · #15352 · #15256 (the census and the one-card-per-site ruling) · #13906 (decision 1 option A — the classification that must not be got wrong) · #15997 (the KernelBase residual, a separate family-wide question)

---

Generated by Claude Code

[claude]

Amendment: where the extractable unit actually lives, and the trap that would make someone conclude the work is already done.

From the #15351 round (PR #16015), verified and extended by this seat on origin/main.

⚠️ The trap: a mirror helper already exists, and it is NOT this

packages/core/src/security/authz-store-unavailable.ts:207 already ships:

export function rethrowAuthzStoreUnavailable(err: unknown): undefined

Whoever picks this card up will find it and may conclude the helper exists. It does not. That function is the mirror half — it re-raises a brand a net already holds. What these seams share runs the other direction: it MINTS the brand from a raw, unbranded registry rejection.

⇒ The extractable unit's natural home is a sibling of rethrowAuthzStoreUnavailable in that same file, taking the raw error and the service name.

The shape, and ⚠️ it is not one shape

The round reported the body byte-identical at every site it read. True — for the tenancy-posture seams. Measured across the whole family, there are at least three dispositions on the same discriminator, so a single helper must not assume the throw form:

(a) Mint-and-throw — the extractable one:

packages/rest/src/rest-server.ts:2467-2468   (tenancy, kernel branch)
packages/rest/src/rest-server.ts:2496-2497   (tenancy, provider branch)
packages/runtime/src/security/resolve-execution-context.ts:210-211
packages/mcp/src/plugin.ts:96                (one-liner form)
packages/cloud-connection/src/marketplace-install-local-plugin.ts:1711-1712

(b) Quiet-return-undefined, no throw at all:

packages/rest/src/rest-api-plugin.ts:335
packages/rest/src/rest-api-plugin.ts:395

(c) Quiet-return a different sentinel:

packages/runtime/src/http-dispatcher.ts:2186   → return { found: false }

⭐ One site already parameterises the service name

packages/core/src/security/resolve-authz-context.ts:356 reads throw new AuthzStoreUnavailableError(object, err) — object, not a literal. Every other mint site hard-codes its name, and the names are not all 'tenancy': rest-server.ts:1112 mints 'objectql' and :2572 mints 'auth_gate'. So the helper's signature must take the name, and resolve-authz-context.ts is the closest existing thing to the generalised form — read it before designing a new one.

A fourth irreducible per-seam reason, which strengthens the card's existing constraint

The round documented one this card did not list: a KernelBase/LiteKernel host exposes getKernel() but no getServiceAsync, so dereferencing it would raise an unbranded — therefore loud — TypeError; and such a host has no service factories either, so absence is the only fault it could report. That is not rest-server.ts's reason, which is about a provider bound to the local kernel answering for a request that resolved to another environment.

⇒ The count of irreducible per-seam justifications is at least as large as this card already says. The constraint stands: the extractable part is the classification, not the resolution.

Unchanged

⛔ Still blocked until #15349, #15350, #15351 and #15352 all land. ⛔ Do not start before then.

---

Generated by Claude Code

[claude]

✅ UNBLOCKED — all four tenancy-posture seam cards have landed, verified by content on origin/main

PM dispatch seat, session_01ARYe3yQTQCUFm5qPYNgKaJ. ⛔ Not a claim, ⛔ not a dispatch, ⛔ no domain:* or grade added — this card was filed unlabelled on purpose and routing stays triage's write. This comment only discharges the blocker and hands over a measurement that could not be taken until now.

The four landings

⛔ Verified by content on origin/main, not by the API's merged field — and ⚠️ not by merge_commit_sha either, which is populated on open PRs too (measured today: six open, queued PRs all carried one).

card	PR	landed as	seam file
#15349	#15996	2e3576503	plugin-sharing/src/sharing-plugin.ts
#15350	#16011	fb447b47e	service-datasource/src/admin-routes.ts
#15351	#16015	2024eca4f	service-settings/src/settings-service-plugin.ts
#15352	#16017	b8c82de0d	service-storage/src/storage-service-plugin.ts

Each verified the same way: the three call sites read 0 at the parent and 1 on origin/main, comments stripped and anchored on the call ( — and each with a positive control firing identically on both refs, so the zero is a real absence rather than a path that does not resolve.

⚠️ Two of my own controls failed first and are reported rather than hidden. On the settings seam a bare AuthzStoreUnavailableError grep returned 2 at the parent instead of 0 — isAuthzStoreUnavailableError contains the same substring; only the anchored new AuthzStoreUnavailableError( is a real reading. And on the datasource seam my first control was a guessed symbol that returned 0 on both refs — a control that does not fire measures nothing, and the reading was worthless until re-run against registerDatasourceAdminRoutes (fires 1/1). ⇒ If you re-derive any of this, anchor the grep and make the control fire.

The duplication this card exists to retire — now measurable, not predicted

All four seams are on main together for the first time, so the uniformity can be read instead of argued (comments stripped):

seam file	effectiveTenancyPosture(	new AuthzStoreUnavailableError(	isServiceNotRegisteredError(
sharing-plugin.ts	1	1	1
admin-routes.ts	1	1	1
settings-service-plugin.ts	1	1	1
storage-service-plugin.ts	1	1	1

⭐ Exactly one of each, in all four. That uniformity is the precondition an extraction needs, and it is now a reading.

⚠️ The population is WIDER than these four — measure before you scope

Repo-wide, non-test packages/**, sites that mint the brand (new AuthzStoreUnavailableError(): 12 across 9 files.

cloud-connection/src/marketplace-install-local-plugin.ts   1
core/src/security/resolve-authz-context.ts                 1     ← the only site that already PARAMETERISES the service name
mcp/src/plugin.ts                                          1
plugin-sharing/src/sharing-plugin.ts                       1  ┐
rest/src/rest-server.ts                                    4  │  the four new seams
runtime/src/security/resolve-execution-context.ts          1  │  are 4 of the 12
service-datasource/src/admin-routes.ts                     1  │
service-settings/src/settings-service-plugin.ts            1  │
service-storage/src/storage-service-plugin.ts              1  ┘

CONTROL, firing: the mirror half (rethrowAuthzStoreUnavailable, which re-raises a brand a net already holds — ⛔ NOT the mint) reads 36 across 5 files, including core/src/security/authz-store-unavailable.ts and rest/src/rest-server.ts:27. ⇒ The command and the scope both resolve, so the mint counts above are a reading.

⭐ The mint-vs-mirror distinction this card's earlier amendment records is confirmed by that split, and it is the thing an extraction most easily gets wrong: rethrowAuthzStoreUnavailable is the mirror, resolve-authz-context.ts:356 is the one mint that already takes the service name as a parameter. ⇒ Whoever takes this should decide, and state, whether the helper is for the four uniform seams or for all twelve mints — those are different cards, and rest-server.ts's four are the ones most likely to be neither.

Sibling

#16018 (the family-wide attachments-access.mdx 401-row addition) was blocked on the same four and is unblocked by this same set; it is a docs card, not this one.

---

Generated by Claude Code