The SDK's delivery is decided; the git URL violates it

ADR 0014 is accepted and unambiguous: each module consumes its dependencies from
the private registry, the mesh's own shared library included, and a cross-package
change is publish then consume.

So the git dependency at a pinned commit is not a mechanism under consideration.
It is the shared library being consumed a way the record rules out, and the lock
naming a sibling directory is what that looks like when nobody publishes. Issue
053 is reclassified from a question about mechanism to a violation with a
direction.

What stays open is narrower and real: which software serves the private registry,
and that a fresh mesh has none when the first SDK is built — ADR 0014 assumes one
exists, and at genesis nothing has installed it.

Recorded after arguing at length for a bespoke content-addressed alternative,
against a decision that was already made and that I had not read.

Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx
This commit is contained in:
2026-09-15 16:50:40 +02:00
parent bc271d4de0
commit 27b2161379
2 changed files with 27 additions and 7 deletions
+7 -3
View File
@@ -163,9 +163,13 @@ knows. Putting the Plex client anywhere else is the shared-library disease with
### What this leaves open
- **Which registry.** The catalogue holds a `verdaccio` module, and a forge typically serves package
registries too. Two answers exist and nothing says which is the mesh's. That has to be settled
before anything publishes.
- **Which private registry.** That there *is* one is settled —
[ADR 0014](../../02-DECISIONS/0014-no-npm-workspace.md) says each module consumes its dependencies
from the private registry, the mesh's own shared library included. Which software serves it is
not: the catalogue holds `verdaccio`, and a git host usually serves package registries too.
- **And the bootstrap does not have one.** ADR 0014 assumes a registry exists; on a fresh mesh
nothing has installed one when the first SDK is built. That is the same pivot as everything else
and it has not been designed.
- **Who may publish.** A builder pushing a package needs an account on that registry, which is a
credential in the bootstrap path and does not exist yet.
- **Versions and ranges.** Everything else the mesh delivers is pinned by digest, and a range is
@@ -39,12 +39,28 @@ way ([ADR 0074](../../02-DECISIONS/0074-the-wire-is-specified-not-the-types.md))
repository does, the Rust and Python ones will do, so the shape is worth getting right before there
are four of them.
## It is a violation, not an open question
[ADR 0014](../../02-DECISIONS/0014-no-npm-workspace.md) already decided this, and was accepted:
> Each module is an independent package that declares its dependencies and **consumes them from
> the private registry, including the mesh's own shared library.** A cross-package change is
> therefore two steps: publish the producer, then consume it.
So a git dependency at a pinned commit is not an alternative mechanism under consideration. It is
the mesh's own shared library being consumed by a means the record rules out, and the lock naming
a sibling directory is what that looks like when nobody publishes.
**Which makes the fix a direction rather than a discussion**: publish the SDK to the private
registry, consume it by version, and the lock stops being able to name a path that exists on one
machine.
## Open questions
- **Is a git dependency at a pinned commit the intended mechanism?** It works, needs no package
registry, and reuses the forge a mesh already depends on to exist at all
([ADR 0071](../../02-DECISIONS/0071-where-genesis-gets-its-source.md)). If so, the lock should say
so and the sibling path should never have been committed.
- **Which private registry, and does the bootstrap have one?** The catalogue holds `verdaccio`;
a git host typically serves package registries too. ADR 0014 says *the* private registry as
though there is one, and today a fresh mesh has neither until something installs it — so the
first SDK build happens before the registry the record assumes.
- **Or should the SDK be a published package?** The catalogue holds a private registry module, and a
published package is how the rest of the world does this — at the cost of a mesh needing that
registry up before it can build anything, which is a bootstrap problem where there is currently