ADR 0044 — No hosted plugin or theme marketplace

Cusp does not run a hosted plugin or theme marketplace. There is no catalogue server to fetch from, no curated listing the admin browses, and no out-of-repo runtime dependency for installing packages. Discovery is the operator's job; installation is one of two local paths.

The decision

Two install paths exist, both with zero network dependency on project-operated infrastructure:

• Browse bundled — first-party plugins and themes are baked into the worker bundle and install one-click through the internal _first_party:// resolver. No egress, no certificate, no host.
• Install by URL — paste an https:// URL pointing at a signed tarball. The InstallPackage workflow downloads it, verifies its signature, parses the canonical USTAR tar, and installs it.

Why

A hosted catalogue is project-operated infrastructure — an R2 bucket fronted by a hostname, holding curated submissions. It is the only out-of-repo runtime dependency the install surface would carry, and a catalogue that resolves to a TLS error is worse than no catalogue: every fresh deploy would meet an "unavailable" banner the moment an admin opened the install dialog. The URL path already provides everything a listing would, in exchange for none of that operational debt.

Anything a marketplace would surface — the signature, the manifest, the screenshot — the URL-install path presents at install time. The signed-package security model is the trust gate, not a listing.

The trust model

Cusp follows a WordPress-style posture: the admin is a trusted adult. Anything they paste, they vouch for. That trust is bounded by the runtime — a plugin can only reach the bindings its manifest declares, and the host enforces those declared capabilities regardless of where the package came from. Discovery is the operator's responsibility; containment is the platform's.

Authors publish signed tarballs wherever they like — a GitHub release, their own R2 bucket, anywhere reachable over https. Signature verification against the project's production keys, canonical USTAR tar parsing, per-file integrity, and R2 staging-and-promote all apply on every install regardless of source.

Consequences

• A fresh deploy has no out-of-repo runtime dependency for installing packages — the bundled set and the URL path both work offline of any project host.
• Community discovery is "paste a URL". There is no central index to publish to or curate.
• The signing keys and the WRONG_PURPOSE verifier discriminator remain, so a community-run catalogue could be stood up later without redesign — but that would be its own decision with its own host commitments.
• The seam is clean: re-adding a catalogue would be a new install-dialog tab fed by a new admin route fed by a new bucket. No current code makes that harder.

This is not a decision against community packages. They install through the URL tab today and continue to. It is purely a decision against the hosted catalogue as a shipped deliverable.