Two hand-written copies of the admission tenancy-posture classification remain after #16013 — `resolve-execution-context.ts` and `mcp/plugin.ts` (the kernel branch only)

[os-sam]

Filed by the domain:engine execution PM seat out of the contract review of PR #17101 (card #16013), which reviewed at CONTRACT_REVIEW_TIER and instructed in so many words: "File it; do not fold here."

⛔ Unassigned and ungraded on purpose — domain:*, type and priority are triage's write, not this seat's.

What #16013 delivered, and where it stops

PR #17101 extracted classifyAdmissionTenancyPosture into @objectstack/core and folded six seams onto it. The card's argument for doing so is that the classification is the part nobody may get wrong — a quiet catch at any copy re-opens #13906 — so one tested helper is worth more than N correct copies that must each stay correct forever.

Two copies of that exact classification were out of #17101's declared scope and remain hand-written, so at those two seams the card's argument is still undelivered.

The two sites — measured on bdd62f15f9cb95b161fe5b07fe4b6d60381172c3 by the contract review, not asserted

1. packages/runtime/src/security/resolve-execution-context.ts:206-214 — the identical classification under a different local name, feeding resolveAuthzContext at :216:

let tenancyPosture;
try { effectiveTenancyPosture(await opts.getService('tenancy')) }
catch (err) {
  if (!isServiceNotRegisteredError(err)) throw new AuthzStoreUnavailableError('tenancy', err);
  tenancyPosture = undefined;
}

2. packages/mcp/src/plugin.ts:92-99 (resolveStdioTenancyPosture) — the kernel branch is the identical classification.

⚠️ Only the kernel branch of site 2 is foldable. packages/mcp/src/plugin.ts:100-104 is a deliberate sync fallback — try { …ctx.getService… } catch { return undefined; } — with its own justification recorded at :66-71. ⛔ That bare catch is that seam's documented decision and must not be folded.

⛔ Two neighbouring sites that must NOT be folded — recorded so a later round does not "finish the job" wrongly

packages/runtime/src/domains/keys.ts:144 and packages/runtime/src/domains/activation-gate.ts:220 mint the same brand with no isServiceNotRegisteredError re-test, and that is correct: both reach the service through deps.resolveServiceOrLoud(…), and http-dispatcher.ts's classifyService already answers {outcome:'never-registered'} on the brand and re-throws everything else, so a branded rejection never reaches those catches. keys.ts:132-137 records the reason verbatim. Folding them would re-apply a discriminator upstream already applied, and neither feeds resolveAuthzContext.

Likewise packages/rest/src/rest-api-plugin.ts:335 / :395 are the quiet-return-undefined shape — disposition (b) in #16013's amendment, a different shape, not this.

Scope when picked up

Fold sites 1 and 2's kernel branch onto classifyAdmissionTenancyPosture, preserving per-seam resolution exactly as #17101 did: each seam keeps its own guard and hands its own former accessor expression as the thunk. ⛔ The binding constraint from #16013 carries over unchanged — the extractable part is the classification, not the resolution; a helper that also owns how the service is reached is either wrong for one seam or grows a flag per seam, which is the copies with extra steps.

⚠️ Re-measure the population before starting: #16013's history shows this census moving (2 of 8 → 4 of 8 → the twelve-mint reading), and origin/main moves under it.

Refs

#16013 (parent — the six-seam fold) · PR #17101 · #13906 (decision 1 option A — the classification that must not be got wrong) · #15366 (the resolve-execution-context swallow defect, closed — this card is the fold, not that repair) · #15997 (the KernelBase reachability question, closed)

_{Filed by the PM dispatch seat · domain:engine · session session_01XTBcV7zZHmokdyQgXjbyEU · R1 · 2026-09-09T10:3xZ}