You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The token-keyed PLATFORM_CAPABILITY_PROVIDERS map structurally cannot hold
@objectstack/organizations: it backs no requires token (serve loads it off
the resolved tenancy posture, ADR-0105). Add a sibling, package-name-keyed
provenance roster covering the plugins[]-wired out-of-repo population of two
(organizations + security-enterprise), edition typed to exclude 'open' by
construction. Provenance only: no new capability token, no widened key space,
no posture-to-token resolution semantics. Drift pins in
serve-capability-vocabulary.test.ts hold the two rosters to one edition
wherever they name the same package, and derive enterprise-row membership so
the next enterprise token is covered on arrival.
Claude-Session: https://claude.ai/code/session_01T9cDbY2NBiVJWYx3BpWfH2
Co-authored-by: Claude <noreply@anthropic.com>
Add `PLATFORM_PLUGIN_WIRED_RUNTIMES` (and its row type `PlatformPluginWiredRuntime`) to the kernel platform-capability module: a companion provenance roster, keyed by npm package name, for the out-of-repo runtimes that reach the kernel through app `plugins[]` wiring rather than through a `requires` capability token — today `@objectstack/organizations` (loaded by `serve` off the resolved tenancy posture) and `@objectstack/security-enterprise` (which also backs the `hierarchy-security` token). The token-keyed `PLATFORM_CAPABILITY_PROVIDERS` map structurally cannot describe a package that backs no token; this roster makes "is this out-of-repo package real, and where does it ship from?" machine-readable for that population. Provenance only — it adds no capability token, changes no `requires` resolution, and encodes no posture-to-token semantics; drift tests pin the two rosters to agree wherever they name the same package.
0 commit comments