The platform has had a complete story for one module using another's
*backend* since ADR 0006 — capabilities, versioned ranges, provider
registration. It has had none at all for one module using another's *browser*
code, and every workaround is wrong in a way that matters: a consumer cannot
import a peer module, it cannot re-implement a renderer for a domain it does
not own, and a second `entrypoints` role would put the platform in charge of
deciding when a slot inside someone else's screen should be filled.
Add a generic browser contribution. `manifestVersion: 7` declares one:
namespaced id, its own version, a target capability, a compatible range, and
one artifact. That is the complete list, and the omissions are the decision —
no payload schema, slot, ordering, or rendering hint exists anywhere, so Core
cannot learn what a slide is because the declaration cannot express it.
Discovery resolves a contribution artifact through the *identical* loop every
other compiled entrypoint uses, inheriting the path, containment, symlink,
extension, and file-kind checks rather than getting a weaker copy of them. The
registry publishes one only when another eligible module provides the target
capability within the declared range; otherwise it is absent rather than
mounted and broken. `apps/api` serves it as a sibling of the artifact and
display routes, with the same policy: three lookup keys, one exact match, one
already-validated path, and one indistinguishable 404 for unknown, undeclared,
stale, and incompatible alike.
A consumer discovers through the host, never through a URL. Its descriptor
carries identity, version, and capability; the URL stays server-side and is
resolved exactly as `api.request("records")` is. A module can only ever see
contributions aimed at a capability it itself provides, and cannot name its
way to anything else — a mount for a withheld id fails without fetching.
The consumer owns the domain contract entirely. Input is opaque JSON, checked
structurally so a Date, a function, a cycle, or `undefined` fails at the
boundary rather than vanishing somewhere far from the mistake, and checked for
nothing else. A contributed renderer receives its own id and that input: no
API client, realtime, principal, configuration, database, storage, or
credential. Loading one grants its module nothing.
The contribution ABI is versioned separately from the module UI ABI, because
the two have different shapes and lifecycles and coupling them would force
every module to rebuild whenever either moved. It supports asynchronous
readiness, update-without-remount (a screen that remounted per tick would
restart animations and reload media), deterministic cleanup in a `finally`,
and sanitized failure that never carries the consumer's domain data. Each
renderer mounts in its own isolated root with its own stylesheet.
The template now declares a contribution, so `pnpm build` exercises the whole
authoring path, and the shell suite drives the full relationship — one module
discovering, mounting, updating, and unmounting another's React renderer with
neither importing the other.
Co-Authored-By: Claude Opus 5 <[email protected]>
`manifest.storage.buckets` has existed since manifest version 1 and meant
nothing — discovery validated it and no code read it. This turns it into a
real capability, which is what stands between Announcements and the module
system: that product currently fetches a hardcoded LAN S3 endpoint, parses
ListObjectsV2 XML by hand, and hands the browser direct object URLs.
- A module declares a logical bucket and receives a scoped facade at
`context.storage` — list, head, get, put, delete. The contract names no
provider: no endpoint, region, credential, or physical bucket is reachable
from it, which is what lets the same module run under a future standalone
host over its own or a shared S3-compatible service.
- Core's first provider speaks S3 through the AWS SDK. SeaweedFS is the
deployment target (ADR 0004), never an API name. Probing the pinned image
found `CreateBucket` reporting `BucketAlreadyExists` rather than AWS's
`BucketAlreadyOwnedByYou`; treating only the AWS spelling as success would
have failed every second boot. A live test pins it.
- Logical → physical mapping is deterministic and collision-safe: an
installation prefix, the module and bucket ids joined by `--` (which cannot
occur inside either identifier, so `a-b`+`c` and `a`+`b-c` cannot collide),
and a digest over the full untruncated identity. Two modules declaring
`assets` always get separate namespaces; neither can see the physical name.
- Declaring a bucket is now a requirement: with no provider configured the
module is `blocked · storage_unavailable` through ADR 0028's existing
resolver, propagating to required dependents. An installation with no object
storage stays a complete deployment.
- Binding availability is not provider health. Eligibility asks whether
storage is configured, never whether it answered; bucket creation is lazy on
first use so a storage outage cannot stop the platform booting; a running
module whose store blinks stays running and retries. Nothing deletes a
bucket.
- Credentials are deployment-supplied, never persisted, never routed through
module configuration, and never visible to modules, module UI, diagnostics,
or API responses. Provider errors translate to a closed code set carrying no
endpoint, bucket, request id, or XML.
- Retires ADR 0029's transitional `bucket` configuration key. No manifest
version change. The template declares no bucket, so it still runs without S3.
See ADR 0030.
Co-Authored-By: Claude Opus 5 <[email protected]>
ekklesia