Found while fixing #10921. Filed as an observation, not a defect: nothing is broken today. It records where #10921's governance half actually landed, so the next person does not re-derive it.
The thing #10921 was told to look for already exists
#10921 asked "may a published README name an @objectstack/ package this repo does not build, and where is that declared?", and offered option A: a declared roster with provenance (scripts/*.json, one row per out-of-repo package).
Measured on 98ea344: that roster exists, and it is PLATFORM_CAPABILITY_PROVIDERS in packages/spec/src/kernel/platform-capabilities.ts. Each row carries exactly the provenance option A described:
readonly package: string|null;// the npm package
readonly edition: 'open'|'enterprise'|'cloud';// where it ships from
readonly note?: string;// the edition boundary, in prose
It is machine-readable, drift-tested 1:1 against the capability vocabulary (serve-capability-vocabulary.test.ts), and read by both runtimes — the CLI preflight and cloud's objectos-runtime. Three out-of-repo packages already have rows: @objectstack/security-enterprise (enterprise), @objectstack/service-ai and @objectstack/service-ai-studio (cloud).
So building a second roster for #10921 would be precisely the divergence that file's own header warns against:
more than one runtime mounts this slate … A second description nobody checks is how that happens; one exported list is how it stops.
The gap
@objectstack/organizations — a real, closed-source, cloud-private enterprise runtime (404 on the public registry; called "cloud-private" or "closed-source" in ~a dozen places in this tree, e.g. serve.ts:229, serve.ts:2576, verify/src/harness.ts:44) — has no row, and structurally cannot get one as the map is keyed today:
PLATFORM_CAPABILITY_PROVIDERS is keyed by requires capability token.@objectstack/organizations is not resolved through requires. It is wired via plugins[] and loaded by serve from the host app, keyed off the resolved tenancy posture (group / isolated), not off a capability token.
So the roster's key space has nowhere to put it, and the one out-of-repo package whose install instruction serve prints at operators is the one the roster cannot describe. @objectstack/security-enterprise is also plugins[]-wired, but it does have a row because it happens to back the hierarchy-security token as well.
Why this was not fixed under #10921
packages/spec/** was explicitly fenced out of that card ("the spec seat's sole territory — read it freely, never edit; if a spec edit is genuinely required, stop and report for routing"). This is that report. Any fix here is a spec change — either a second, posture-keyed provenance map, or a widening of this one's key space — and it belongs to the spec seat.
What it would buy
Today the "is this a real out-of-repo package or a fabricated one?" question is answerable by grep-and-judgement, which is how @objectstack/framework (fabricated) sat next to @objectstack/organizations (real) in #10921's table for months looking identical. A declaration covering both plugins[]-wired enterprise runtimes would make the distinction machine-readable — and would be a population of two, not the population of one that made a fresh roster file look unearned.
Refs: #10921 and its PR · #10920 (same prior fact on a runtime surface).
Found while fixing #10921. Filed as an observation, not a defect: nothing is broken today. It records where #10921's governance half actually landed, so the next person does not re-derive it.
The thing #10921 was told to look for already exists
#10921 asked "may a published README name an
@objectstack/package this repo does not build, and where is that declared?", and offered option A: a declared roster with provenance (scripts/*.json, one row per out-of-repo package).Measured on
98ea344: that roster exists, and it isPLATFORM_CAPABILITY_PROVIDERSinpackages/spec/src/kernel/platform-capabilities.ts. Each row carries exactly the provenance option A described:It is machine-readable, drift-tested 1:1 against the capability vocabulary (
serve-capability-vocabulary.test.ts), and read by both runtimes — the CLI preflight and cloud's objectos-runtime. Three out-of-repo packages already have rows:@objectstack/security-enterprise(enterprise),@objectstack/service-aiand@objectstack/service-ai-studio(cloud).So building a second roster for #10921 would be precisely the divergence that file's own header warns against:
The gap
@objectstack/organizations— a real, closed-source, cloud-private enterprise runtime (404 on the public registry; called "cloud-private" or "closed-source" in ~a dozen places in this tree, e.g.serve.ts:229,serve.ts:2576,verify/src/harness.ts:44) — has no row, and structurally cannot get one as the map is keyed today:PLATFORM_CAPABILITY_PROVIDERSis keyed byrequirescapability token.@objectstack/organizationsis not resolved throughrequires. It is wired viaplugins[]and loaded byservefrom the host app, keyed off the resolved tenancy posture (group/isolated), not off a capability token.So the roster's key space has nowhere to put it, and the one out-of-repo package whose install instruction
serveprints at operators is the one the roster cannot describe.@objectstack/security-enterpriseis alsoplugins[]-wired, but it does have a row because it happens to back thehierarchy-securitytoken as well.Why this was not fixed under #10921
packages/spec/**was explicitly fenced out of that card ("the spec seat's sole territory — read it freely, never edit; if a spec edit is genuinely required, stop and report for routing"). This is that report. Any fix here is a spec change — either a second, posture-keyed provenance map, or a widening of this one's key space — and it belongs to the spec seat.What it would buy
Today the "is this a real out-of-repo package or a fabricated one?" question is answerable by grep-and-judgement, which is how
@objectstack/framework(fabricated) sat next to@objectstack/organizations(real) in #10921's table for months looking identical. A declaration covering bothplugins[]-wired enterprise runtimes would make the distinction machine-readable — and would be a population of two, not the population of one that made a fresh roster file look unearned.Refs: #10921 and its PR · #10920 (same prior fact on a runtime surface).