--- layer: to-be status: in-progress updated: 2026-09-15 decisions: - 02-DECISIONS/0067-genesis-is-a-pivot.md - 02-DECISIONS/0074-the-wire-is-specified-not-the-types.md - 02-DECISIONS/0075-two-stores-and-which-provides-what.md - 02-DECISIONS/0014-no-npm-workspace.md --- # The work ahead Everything decided this cycle and not yet built, in the order its dependencies allow. Each phase ends at something provable on a running mesh, because a phase that ends at a claim is a phase that went missing without anything complaining. ## Phase 0 — the installer completes, once **Why first.** Nothing below is testable end to end without an installer that finishes. It has been failing on regressions of mine — a stale carried builder, a diagnostic on the parsed stdout — not on the mesh. - [ ] 0.1 rebuild the builder image, and **verify the change is in it** (`grep`, not trust `make`) - [ ] 0.2 re-carry it, run the one-node installer, watch the phase-two base build with its own logs - [ ] 0.3 diagnose and fix whatever the base build actually does — the original hang, now visible - [ ] 0.4 all 22 checks green, twice, so it is reproducible rather than lucky **Done when.** A bare machine becomes a working mesh by running the installer, and the run passes again. ## Phase 1 — the protocol is one thing, and correct **Why here.** The Go control plane and the TypeScript SDK disagree about what a grant carries (`consumer` is the module in one, the node in the other). That is exercised by the installer's own provisioning — the catalogue's database — so it belongs before more is built on it. - [ ] 1.1 extract the wire contracts to one specification the two implementations both conform to - [ ] 1.2 make Go and TypeScript agree — one meaning for `consumer`, the envelope's six headers emitted by both - [ ] 1.3 an executable conformance suite, per capability, both existing SDKs made to pass it - [ ] 1.4 the `x-schema` header written, so a body's shape can version (ADR 0074) **Done when.** A fixture emitted by one implementation is read identically by the other, checked in both test suites. ## Phase 2 — the private package registry, and the SDK in it **Why here.** ADR 0014 says a module consumes its dependencies, the SDK included, from the private registry. Nothing installs one, so the SDK comes from a git URL (issue 053). Needs the installer (Phase 0) and gitea. - [ ] 2.1 gitea provides `package-registry` in full — the endpoints, an account the builder may publish with - [ ] 2.2 the builder publishes the SDK there on build, by version - [ ] 2.3 modules consume it by version; the git URL and the sibling-path lock are gone - [ ] 2.4 a second language's SDK published the same way, proving the path is not TypeScript-only **Done when.** A module builds against the SDK resolved from the mesh's own registry, and issue 053 closes. ## Phase 3 — nothing is special after installation **Why last.** The hardest and riskiest, and it needs everything above: an installer that completes, a protocol that agrees, a registry to publish to. Issue 051. - [ ] 3.1 the store is adopted — raised at genesis, then held as the `postgres` module; one server, the control plane's records and every module's database in it - [ ] 3.2 the broker is adopted — one `lavinmq`, the `/` vhost for the mesh bus, a vhost per consumer that requires `amqp`; the second server gone - [ ] 3.3 an upgrade of each, proven: a store the control plane reads from, a broker over the broker, each with a stated window - [ ] 3.4 `status` can say the substrate is behind its source, which today it cannot form **Done when.** A mesh built from bare metal runs one postgres and one lavinmq, and can upgrade either — so the twelve-module floor has no specialty left in it. ## The through-line Each phase leaves the mesh more able to describe and rebuild itself, and each ends at a run rather than a paragraph. The order is dependency, not preference: the installer carries everything, the protocol is what everything speaks, the registry is what everything is built from, and adoption is what makes the last two things ordinary.