Design 57: ship the packages as one release, rehearsed in the lab

The operator chose one delivery over one per package; the packages meet on one branch per repository and reach main as one delivery group.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

03-DESIGN/01-to-be/57-building-config-and-provisioning.md

@@ -23,14 +23,35 @@ them. It is the shape [design 38](38-building-the-operators-machine.md) gave the
 
 **Each package is one issue in the issue tracker, and one pull request per repository it touches.** The
 issue carries the package's number here in its title, links the packages it waits for with `depends-on`,
-and links ADR 0348 or ADR 0349 and this design. At most five packages are worked at once, each by its own
-agent in its own worktree; a package starts only when every package it depends on is delivered, not
-merely merged. Every pull request is reviewed independently at its head and merged only with both
-required checks green (`mesh/merge-gate`, `mesh/repo-check`).
+and links ADR 0348 or ADR 0349. At most five packages are worked at once, each by its own agent in its
+own worktree; a package starts once every package it depends on is merged. Every pull request is
+reviewed independently at its head and merged only with its checks green.
+
+**It ships as one release.** The operator's decision of 2026-10-14: one delivery, not one per package.
+Each of mesh-controller, `mesh-host`, mesh-sdk, mesh-catalog and hq has the branch
+`feat/57-config-and-provisioning`, and every package's pull request merges into that branch, never into
+main. When the last package is merged, the whole is rehearsed in the lab: the walk, the moves of data in
+their order, and every proof that is run live. Then each repository's branch reaches main in one pull
+request, and the five, sharing their branch's name, are one delivery group (ADR 0239 §2), judged as one
+future state and delivered by one walk (ADR 0276). The release holds every package but T6, R1 and R2:
+the media catalogue and the applications live in repositories of their own and move after it, and only
+then can the old forms be refused (R1) and the record say what runs (R2).
+
+**The moves of data run after the delivery, in this order, each a verb that says what it did:**
+placement out of the settings layers (F2), the settings layers into mesh-config (K5), the secrets into
+the vault, nothing rotated (V3), then the providers one by one (B2, B3). Each is rehearsed in the lab
+first, and each is checked by reading back through the module that owns the data before anything
+points at it.
+
+**What a release costs.** A proof that is run live (dunst on g14, a secret reaching its file, a database
+consumer connecting) is first seen in the lab rehearsal, and a fault found then holds the release, not
+one package. A failed member of the group stops the walk, which walks the others again without it
+(ADR 0299).
 
 **Nothing breaks on the way.** ADR 0349 clause 17: each file is filled the old way or the new way, never
 both, by the form of its manifest, and the old forms stay accepted until the last module has moved.
-Every package below keeps the mesh composing as it does today until a module is moved to the new form.
+Inside the release this still holds: the media catalogue and the applications kept in their own
+repositories move after it, so the old forms stay accepted until they have (R1).
 
 ## What exists already, measured
 
@@ -82,7 +103,7 @@ S1        P6                             R1        T5, T6, K6, K7, P7, V4, B3, L
 R2        R1
 ```
 The issue tracker holds the same links as `depends-on`, so the packages ready to start are those whose
-linked packages are all resolved. The first wave touches different repositories and different files:
+linked packages are all merged into the release's branches. The first wave touches different repositories and different files:
 **T1, F1, F3, P1 and F4**. K1 waits for T1 because both change `internal/catalogue/manifest.go`; P3
 waits for F3 because both change `internal/broker`; F2 joins as soon as a slot is free.
 
@@ -301,6 +322,7 @@ amended, ADR 0348's and 0349's built status is said, and this document's status
 
 ## How this list is kept true
 
-Each package's proof is run when the package is delivered, and its line here gains the date and the
-commit. A package whose proof fails is not reworded; the failure is recorded under it and the package
+Each package's proof that runs in its tests is run when it is merged into the release's branch, and its
+line here gains the date and the commit; a proof that runs live is run in the lab rehearsal and again
+after the release's delivery. A package whose proof fails is not reworded; the failure is recorded under it and the package
 stays open. The issue tracker says which packages are worked now; this document says only the order.