feat: publish the exact @ekklesia package train to the npm registry (ADR 0053)

Publishes one package release train to the Gitea npm registry under River_of_Glory_Church, whose packages are publicly readable on purpose: exactly the .tgz files the package-release gate proved, and nothing else. Nothing is published by this change. - scripts/publish-package-train.ts validates the whole local train before any request (gate manifest hash, version, revision, unmodified source, the nine packages, every artifact's size, SHA-256, integrity, SHA256SUMS line, and inner package.json), then publishes in dependency order with `npm publish <file.tgz>` under a staging tag. Each package is reconciled first (absent: publish; same bytes: accept; other bytes: hard stop, version burned), then read back: metadata (name, version, integrity, dependency maps, normalized bin, tarball on the registry) and the tarball itself, byte for byte, also anonymously. `latest` moves only after all nine verify; reruns converge and never delete anything. It writes a publication record. The token comes from EKKLESIA_PACKAGES_PUBLISH_TOKEN only, through a temporary npm config that refers to the variable. - scripts/test-package-publication.sh proves it against a disposable Gitea 1.27.2 with public owners, a publisher team and an outsider: anonymous reads, refused unauthorized publishing, byte-identical round trips, the registry's own 409, partial-train recovery, the burned version hard stop, and dist-tag retry convergence. - CI: package-release keeps its proven release and hands it on as an artifact with its manifest hash; the new package-publication job publishes exactly that artifact to the disposable Gitea. Artifact actions v3 (node20): v4 refuses any server other than github.com. - .github/workflows/publish-packages.yml publishes to the real registry only by manual dispatch on main, after its own gate run, with the secret in the publish step alone. - docs: the public-read model, the workflow, the record, credentials, immutability policy, provider moves, and the first-publication steps. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-08 09:49:27 -05:00
parent 57df2e15f2
commit d3c62e63bf
17 changed files with 2393 additions and 33 deletions
@@ -4,19 +4,21 @@ An Ekklesia platform release is one version. The platform image, the private wor
 and the public `@ekklesia/*` module-development packages all carry it. This page covers the order a
 release happens in and the public package train
 ([ADR 0053](../architecture/decisions/0053-standalone-module-development-packages.md)): how its
-artifacts are produced, what proves them, and what a future publication step will do with them.
+artifacts are produced, what proves them, and how exactly those artifacts are published.

-> **Registry publication is not implemented.** Nothing in this repository publishes a package, and
-> no CI job holds a registry credential. The release artifacts below are produced and proven on
-> every CI run. A future publication step publishes **exactly these artifacts**, unchanged, and
-> nothing else.
+> **The packages are publicly readable, on purpose.** Anyone can search, read, and install
+> `@ekklesia/*` from the registry with no account and no token, like any public npm package. That is
+> not a public launch: Ekklesia's source is already publicly readable, and the project is simply not
+> promoted yet. Only **publishing** is restricted, to one manual, authenticated workflow. Before
+> 1.0, the APIs may change between versions under the project's SemVer policy: a 0.x minor version
+> may break them.

 ## Where each step sits

 ```text
 version set ─▶ build ─▶ test ─▶ pack the public package train ─▶ standalone consumer proof
                                                                          │
-                     tag and release (maintainer) ◀─ [future: publish] ◀──┘
+     tag and release (maintainer) ◀─ publish the exact train (manual) ◀───┘
 ```

 1. **Version set.** A `chore(release): prepare X` pull request sets the release version: the root
@@ -28,14 +30,15 @@ version set ─▶ build ─▶ test ─▶ pack the public package train ─▶
 3. **Pack the public package train.** `pnpm packages:release` (below).
 4. **Standalone consumer proof.** A module outside the repository consumes exactly those
   artifacts (below).
-5. **[Future] publish.** Not implemented. Once it is, it must run only after steps 3 and 4 passed
-   for the same commit. It must check every artifact against the release manifest before
-   publishing it, and publish nothing else.
+5. **Publish the exact train.** By hand, with the `Publish packages` workflow on the version-set
+   commit on `main` ([Publishing the train](#publishing-the-train)). It publishes the artifacts its
+   own run's gate (steps 3 and 4) proved, and nothing else.
 6. **Tag and release.** Unchanged: the maintainer tags the merge commit of the version-set pull
   request. Nothing here creates, moves, or requires a tag.

-Steps 2 to 4 run in CI on every pull request and on `main`. The `package-release` job is the gate a
-future publication job must depend on.
+Steps 2 to 4 run in CI on every pull request and on `main`, and CI also publishes each proven train
+to a disposable registry (`package-publication`), never the real one. Step 5 runs only when a
+maintainer starts it.

 ## The public package train

@@ -192,3 +195,166 @@ Two builds of the same commit produce byte-identical tarballs, and CI proves it
  `packageManager`. Another Node.js or zlib build may compress differently. Each artifact's
  integrity is recorded either way, and that, not byte identity, is what a publication step must
  verify.
+
+## Publishing the train
+
+The registry is the Gitea npm registry under the `River_of_Glory_Church` owner:
+
+```text
+https://git.riverofglorymn.org/api/packages/River_of_Glory_Church/npm/
+```
+
+| Who | May |
+| --- | --- |
+| Anyone, signed in or not | search, read metadata, download, and install `@ekklesia/*` |
+| The publisher account, through the publish workflow | publish new versions and move dist-tags |
+| Anyone else | nothing more: publishing needs the publisher team's package write permission |
+
+### The workflow
+
+`.github/workflows/publish-packages.yml` (Actions → Publish packages → Run workflow, on `main`,
+with the release version). Nothing else can start it: no pull request or push does, and CI holds no
+registry credential at all.
+
+1. **The gate.** `package-release` runs the same credential-free gate as CI (build, reproduce,
+   consume) and hands the proven release on as a workflow artifact, with its manifest's SHA-256.
+2. **The publish job.** It builds and installs nothing. It downloads the artifact and runs
+   `scripts/publish-package-train.ts` with the secret `EKKLESIA_PACKAGES_PUBLISH_TOKEN`, which only
+   this step receives.
+3. **The publication record** is kept as an artifact of the run.
+
+### What the publication tool does
+
+`scripts/publish-package-train.ts` publishes exactly the `.tgz` files in the release directory. It
+never builds, packs, or edits a package, and it never deletes, unpublishes, or overwrites anything.
+
+1. **Validates the whole train before sending anything.** The manifest must be the one the gate
+   proved (`--manifest-sha256`), for the requested version and this commit (`--revision`), from a
+   clean tree (`"modified": false`), with exactly the nine expected packages. Every artifact's file
+   name, size, SHA-256, integrity, `SHA256SUMS` line, and the `package.json` inside it must match.
+2. **Publishes in dependency order.** Each package comes after the train packages it depends on,
+   then alphabetically. For each package:
+   - **absent:** `npm publish <file.tgz>` under the staging dist-tag `ekklesia-staging`. npm sends the
+     file's own bytes and runs no script for a file; the registry checks them against their
+     integrity and stores them as they are;
+   - **present with the same bytes:** accepted as already published, and verified;
+   - **present with other bytes:** a hard stop. Nothing is deleted or overwritten, nothing after it
+     is published, and the version is burned ([Immutability](#immutability)).
+3. **Reads every package back.** The registry's metadata must name the package and version, report
+   the artifact's integrity, and list the same `dependencies`, `peerDependencies`,
+   `optionalDependencies`, and `bin` as the tarball's `package.json` (npm writes `bin` paths without
+   a leading `./`). Its tarball URL must be on the configured registry, and the tarball it serves must
+   be the release artifact, byte for byte. With `--require-public-read`, an anonymous download must
+   give the same bytes too. A package is published only once all of that holds.
+4. **Moves `latest` last.** Only when all nine are verified does `latest` move to the train, never
+   backwards past a newer version. The train is published when every package's `latest` agrees.
+5. **Writes the publication record** (`--record`).
+
+A rerun is always safe. It publishes only what is missing, accepts what is already there and
+identical, and moves only the tags that are not yet right. A train interrupted after five packages,
+or after four tags, finishes on the next run. No retry ever deletes anything.
+
+### The publication record
+
+Evidence that one train was published, not a second package catalog, and never a secret:
+
+```json
+{
+  "publicationRecord": 1,
+  "packageTrain": { "version": "0.2.0", "revision": "<commit>", "manifestSha256": "<hex>" },
+  "registry": "https://git.riverofglorymn.org/api/packages/River_of_Glory_Church/npm/",
+  "finalTag": "latest",
+  "completedAt": "<ISO time>",
+  "packages": [
+    {
+      "name": "@ekklesia/contracts",
+      "version": "0.2.0",
+      "file": "ekklesia-contracts-0.2.0.tgz",
+      "outcome": "published",
+      "artifact": { "sha256": "<hex>", "integrity": "sha512-…", "size": 87379 },
+      "registry": { "tarball": "<url>", "sha256": "<hex>", "integrity": "sha512-…", "publicRead": true },
+      "finalTag": "moved",
+      "distTags": { "ekklesia-staging": "0.2.0", "latest": "0.2.0" }
+    }
+  ]
+}
+```
+
+`outcome` is `published` or `already-present`. `finalTag` is `moved`, `already-current`, or
+`kept-newer` (a newer version already holds `latest`).
+
+### Credentials
+
+- **One credential:** `EKKLESIA_PACKAGES_PUBLISH_TOKEN`, a repository Actions secret, used only by
+  the publish step. Nobody needs a token to read or install.
+- **The publisher** is a dedicated account, member only of a `River_of_Glory_Church` team whose one
+  permission is Packages: Write. Its token has only the `write:package` scope. Gitea's
+  `write:package` also allows deleting packages; the tool never does, and nothing else uses the
+  token.
+- **No token in git or in an `.npmrc`.** The tool writes a temporary npm configuration that refers to
+  the variable (`_authToken=${EKKLESIA_PACKAGES_PUBLISH_TOKEN}`), ignores every user, global, and
+  project npm configuration, sends the token only to the registry itself, and removes the
+  configuration afterwards.
+- **What remains trusted:** Gitea gives repository secrets to workflows run for pull requests from
+  branches of this same repository, so anyone who can push a branch here could read the secret
+  through a changed workflow. Keep write access to this repository to the maintainers.
+
+### Immutability
+
+Gitea refuses to upload a version that exists (409). But it lets anyone with package write
+permission delete a version, deletion leaves nothing behind, and an owner's package cleanup rules
+can delete versions on a schedule. So immutability is Ekklesia's policy, not the registry's
+guarantee:
+
+- **A published version is never deleted,** by anyone, for any reason short of a security incident.
+- **A version number is never reused with other bytes.** A version found on the registry with other
+  bytes is burned: investigate how it got there, and publish the train under a new version.
+- **No package cleanup rule** may be configured for the `River_of_Glory_Church` owner.
+- **The publisher never deletes.** The tool has no delete, unpublish, or overwrite, and its tests
+  check that.
+
+Module lockfiles record each package's integrity, so a replaced package would fail every install of
+it, rather than install silently.
+
+### Moving to another registry
+
+Only configuration changes: the registry URL (the workflow's `EKKLESIA_PACKAGES_REGISTRY`), the
+publisher credential, and modules' `@ekklesia:registry`. Modules then regenerate their lockfiles,
+because Gitea's tarball URLs are its own. Package sources, the train, its manifests, and every
+artifact already built stay as they are; the same bytes keep the same integrity.
+
+### Proving the publication machinery
+
+`pnpm test:package-publication` (`scripts/test-package-publication.sh`, the CI `package-publication`
+job) publishes a real release train to a disposable Gitea 1.27.2 configured like the real one:
+public owners, a publisher team, and an outsider. In CI it publishes the very artifact the
+`package-release` job handed on, after checking its manifest hash. It proves:
+
+- anonymous search, metadata, and download work;
+- publishing without credentials, or by a user outside the publisher team, fails;
+- the round trip is byte-identical, also anonymously;
+- the registry refuses a second upload of a published version;
+- a train interrupted before its sixth package resumes, verifying the five and publishing the rest,
+  with `latest` untouched until all nine are verified;
+- a version already published with other bytes stops the train, deleting and overwriting nothing,
+  and publishing nothing after it, on every retry;
+- a train interrupted while moving `latest` converges on a rerun, moving only the missing tags.
+
+### The first publication
+
+The first train published is the **next** platform release version, not 0.1.2. The `v0.1.2` tag
+predates the curated SDK and this release tooling, so packages built now and called 0.1.2 would
+claim to be source that 0.1.2 never contained.
+
+Before it, an administrator of the Gitea instance:
+
+1. creates the dedicated publisher account;
+2. creates a `River_of_Glory_Church` team, for example `package-publishers`, with only the Packages
+   unit at Write, and adds the account to it;
+3. creates a token for the account with only `write:package`, and stores it as the repository
+   Actions secret `EKKLESIA_PACKAGES_PUBLISH_TOKEN`;
+4. checks that the owner has no package cleanup rule.
+
+Then the release proceeds as usual: the version-set pull request merges, a maintainer starts
+Publish packages on `main` with that version, and tags the commit once the train is published.
+
@@ -660,6 +660,13 @@ versions, manifest inspection, release directory, manifest bytes, the pack hook)
 `tests/public-packages.test.ts`, part of `pnpm verify`. See
 [Releases and the public package train](releases.md).

+`pnpm test:package-publication` (the CI `package-publication` job, given the `package-release` job's
+artifact) publishes a release train to a disposable Gitea 1.27.2 with Docker, never the real
+registry, and proves the publication tool: byte-identical round trips, anonymous reads, refused
+unauthorized publishing, partial-train recovery, the hard stop on a burned version, and dist-tag
+convergence (`tests/package-publication.integration.ts`). The tool's own rules are unit-tested in
+`tests/package-publication.test.ts`, part of `pnpm verify`.
+
 ## The generic platform image and the reference deployment

 These need Docker and build images locally; nothing is pushed or published.