Files
Ekklesia/docs/architecture/decisions/0054-public-package-reads-before-launch.md
T
ekklesiaandClaude Opus 5.5 486356a01e
CI / verify (pull_request) Successful in 1m4s
CI / infrastructure-smoke (pull_request) Successful in 36s
CI / migration-smoke (pull_request) Successful in 1m46s
CI / package-release (pull_request) Successful in 33s
CI / image-build (pull_request) Successful in 22s
CI / deploy-smoke (same-origin) (pull_request) Successful in 48s
CI / deploy-smoke (split) (pull_request) Successful in 1m27s
CI / package-publication (pull_request) Successful in 43s
docs: ADR 0054, Ekklesia's module-development packages are publicly readable before launch
ADR 0053 was accepted assuming a private package phase before launch. The
project owner has decided otherwise: Ekklesia is not secret, its source is
already public, and only publication must be restricted.

ADR 0054 supersedes ADR 0053 only where it describes that phase as
private or requires authenticated package reads. Packages may be read
anonymously, which is neither a launch nor an API stability promise
beyond pre-1.0 SemVer; publication stays authenticated and restricted;
published versions stay immutable; the River_of_Glory_Church Gitea
namespace is an acceptable host; a public launch remains a separate
decision. Every other ADR 0053 decision is unchanged.

ADR 0053 gets only a cross-reference line. The ADR index, the release and
module-development guides, the README status, and the publish workflow's
comment now point at ADR 0054.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-08 10:24:17 -05:00

5.4 KiB

0054: Ekklesia's module-development packages are publicly readable before launch

  • Status: Accepted
  • Date: 2026-10-08
  • Supersedes (partial): 0053 — only where it describes the package phase before launch as private: "Gitea may host the private phase", the read credential for module CI in "Registry access and the private phase", and its requirement that packages not be served anonymously while Ekklesia is not public. Every other part of that ADR remains accepted and unchanged: the npm registry protocol, the public package set and its boundaries, the curated SDK, the dependency rules, the coordinated package train, exact release artifacts, standalone module builds, provider portability, supply chain and immutability, and the credential handling for publishing.
  • Related: ADR 0049

Context

ADR 0053 decided how Ekklesia's module-development packages (@ekklesia/*) are built, released, and distributed over the npm registry protocol. It assumed that the phase before Ekklesia's public launch would be private: module CI would carry a read credential where reads needed one, and the first publication had to make sure the registry would not serve the packages anonymously.

Checking the chosen host before the first publication showed what keeping the packages private would take:

  • Gitea 1.27.2 decides package read access by the package owner's visibility, never a repository's. The River_of_Glory_Church owner is a public organization, so its packages are readable anonymously.
  • That organization's repositories, Ekklesia's source among them, are already publicly readable.
  • The instance allows self-registration, so "limited" visibility, readable by any signed-in user, is readable by anyone who creates an account.
  • Private packages would therefore need a separate private package owner, plus reader accounts and read tokens for every module repository, every module's CI, and every developer.

The project owner has decided that Ekklesia is not secret. Its source is public; the project is simply not being launched or promoted yet. Hiding the packages built from that public source would protect nothing, and would still cost every module author an account and a token.

Decision

  1. Ekklesia's module-development packages may be anonymously readable before the project's public launch. This covers the public package set of ADR 0053: search, metadata, and download.
  2. Readability is not a launch, and promises nothing more. Public readability does not mean:
    • that Ekklesia has been publicly launched;
    • that the APIs are stable beyond the project's pre-1.0 SemVer policy;
    • that third-party production use is supported;
    • that a marketplace or public module ecosystem exists.
  3. Reading needs no authentication in this phase. Installing @ekklesia/* needs no account, reader account, read token, or authenticated install workflow. A module repository configures only the scope's registry.
  4. Publication stays authenticated and tightly controlled. Only Ekklesia's release process publishes, with one dedicated publisher credential that holds nothing beyond package write access, used only by that process, as ADR 0053's credential handling for publishing already requires.
  5. Published versions stay immutable by Ekklesia policy. A published version is never deleted or republished with other bytes, whatever the registry technically allows.
  6. The current Gitea owner is an acceptable host. The River_of_Glory_Church package namespace on the current Gitea may host this phase, as long as publishing permission stays restricted to the publisher. No private package organization is needed.
  7. A public launch is a separate decision. Launching or promoting Ekklesia publicly, and anything that changes for its packages then, is a product and release decision this ADR does not make.

Consequences

  • Module authors and module CI need no Ekklesia credential. The committed .npmrc scope mapping is the whole registry configuration. ADR 0053's example of a read credential in user or CI configuration is no longer needed in this phase.
  • ADR 0053's pre-publication access check changes meaning. It now confirms that anonymous reads work as intended and that publishing is refused without the publisher's permission, rather than that reads are private. The disposable-registry suite proves both, and the publication tool can require an anonymous download to match each published artifact.
  • Restricting publishing is now the whole access boundary, so the publisher credential's scope, where it is held, and who can reach it matter all the more.
  • Making the packages private again would be a new decision. Package names, versions, and contents already published stay public, because a published version is never deleted.

Alternatives considered

  • A private package organization on the same Gitea. Rejected: it hides nothing that is not already public in the source, and it requires reader accounts and tokens for every module repository, its CI, and every developer.
  • "Limited" package visibility. Rejected: with self-registration open, anyone can read anyway, while the configuration suggests otherwise.
  • Requiring sign-in for the whole instance. Rejected: it would also hide the public repositories.
  • Another registry for a private phase. Unnecessary once reads are public.