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

03-DESIGN/01-to-be/20-writing-a-module.md

@@ -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
+- **Which private registry.** That there *is* one is settled —
-  registries too. Two answers exist and nothing says which is the mesh's. That has to be settled
+  [ADR 0014](../../02-DECISIONS/0014-no-npm-workspace.md) says each module consumes its dependencies
-  before anything publishes.
+  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

04-ISSUES/053-the-sdk-is-pinned-twice-and-the-two-disagree/00-report.md

@@ -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
+- **Which private registry, and does the bootstrap have one?** The catalogue holds `verdaccio`;
-  registry, and reuses the forge a mesh already depends on to exist at all
+  a git host typically serves package registries too. ADR 0014 says *the* private registry as
-  ([ADR 0071](../../02-DECISIONS/0071-where-genesis-gets-its-source.md)). If so, the lock should say
+  though there is one, and today a fresh mesh has neither until something installs it — so the
-  so and the sibling path should never have been committed.
+  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