Designs 07 and 21 and issue 071: genesis now makes the root secrets

The installer half of the amended ADR 0085 is built and proven by the
genesis bed's root-secrets step; the foundation design closes its open item
and the installation design says what the installer does and what it still
cannot check.

03-DESIGN/01-to-be/07-the-foundation.md

@@ -8,7 +8,7 @@ code:
   - mesh-catalog modules/postgres
   - mesh-catalog modules/lavinmq
   - mesh-lab test/integration/mesh.test.ts (a bare machine becomes a mesh)
-updated: 2026-09-17
+updated: 2026-09-21
 decisions:
   - 02-DECISIONS/0004-a-node-and-how-it-joins.md
   - 02-DECISIONS/0078-the-store-and-broker-are-modules.md
@@ -246,12 +246,13 @@ host's vocabulary grows by one shape rather than by one resource type per founda
   the module that provides one.
 - **Whether one host can raise all three.** The claim under stage 2 of
   [the node host](05-the-node-host.md), never proved. If it is false, the tier boundary moves.
-- **The vault as the fourth piece.** [ADR 0085](../../02-DECISIONS/0085-a-secret-is-a-provision.md),
+- ~~**The vault as the fourth piece.**~~ **Closed 2026-09-21** by
-  amended, makes the vault a foundation module: genesis makes the operator key before anything
+  [ADR 0085](../../02-DECISIONS/0085-a-secret-is-a-provision.md) as amended: genesis makes the
-  is minted, replaces the fixed credentials the store and broker are raised with, and installs
+  operator key before anything is minted, raises the store and broker with credentials it made
-  `mesh-vault` beside the adopted store and broker ([24](24-the-secrets-vault.md)). The controller's
+  rather than the template's, adopts both as modules with those credentials, installs
-  half exists; the installer's does not yet, and the bundle still raises the foundation with
+  `mesh-vault` beside them, and writes the operator-sealed export next to the key
-  well-known credentials ([issue 071](../../04-ISSUES/071-the-foundation-is-raised-with-fixed-credentials/00-report.md)).
+  ([24](24-the-secrets-vault.md), [issue 071](../../04-ISSUES/071-the-foundation-is-raised-with-fixed-credentials/00-report.md)).
+  Proven by the one-node genesis bed's root-secrets step.
 - **How the foundation is updated once a mesh exists.** Pinned by hand at bootstrap; afterwards
   the controller could deliver it like anything else, and nothing says whether it does.
 

03-DESIGN/01-to-be/21-the-installation-in-full.md

@@ -5,7 +5,7 @@ code:
   - mesh-host internal/bootstrap
   - mesh-host cmd/mesh-bootstrap
   - mesh-lab test/integration/one-node-mesh.test.ts
-updated: 2026-09-20
+updated: 2026-09-21
 decisions:
   - 02-DECISIONS/0067-genesis-is-a-pivot.md
   - 02-DECISIONS/0073-the-installer-carries-a-builder.md
@@ -118,10 +118,16 @@ told anything.
 this is the lab being honest rather than the mesh being broken. What is missing is the step that
 puts the shipped unit on the machine.
 
-**The foundation is raised with fixed credentials, and they stay.** The store's superuser and the
+**The foundation's credentials are the installer's, not the template's.** The template still
-broker's administrator are constants in the bundle, carried into the mesh by `secret accept`. No
+carries a fixed store password and the broker image's default administrator, because it is applied
-operator key is made at genesis, so nothing minted during installation is sealed to one
+raw by beds that raise no mesh; the installer replaces both with values it makes once and keeps at
-([24](24-the-secrets-vault.md), [issue 071](../../04-ISSUES/071-the-foundation-is-raised-with-fixed-credentials/00-report.md)).
+the paths the store and broker modules declare, rewrites the produced bundle to use them, and
+writes that bundle at 0600. After enrolment and before the first secret is accepted it makes the
+operator key beside the bundle and gives the mesh its public half; the run ends with the
+operator-sealed export beside the key ([24](24-the-secrets-vault.md),
+[issue 071](../../04-ISSUES/071-the-foundation-is-raised-with-fixed-credentials/00-report.md)).
+What is not yet true: nothing rotates those two credentials afterwards, and the operator key is a
+file a person must carry off the machine — the installer says so and cannot check it.
 
 **Nothing asserts a mesh was installed this way.** A claim that a machine was brought up by this
 procedure cannot be contradicted by anything afterwards.

04-ISSUES/071-the-foundation-is-raised-with-fixed-credentials/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-09-20
 located-in: [mesh-host internal/bootstrap, mesh-host examples/foundation-first-node.lock]
-fixed-by:
+fixed-by: mesh-host feat/secrets-vault (ee0c8b8, genesis root credentials + operator key + vault); mesh-controller feat/secrets-vault (e140ed5, 565f144); mesh-catalog feat/secrets-vault; proven by the one-node genesis bed step V5
 amended-design: 03-DESIGN/01-to-be/24-the-secrets-vault.md
 ---
 
@@ -35,5 +35,7 @@ rests on are not random, and there is no operator key at genesis for anything to
 [24](../../03-DESIGN/01-to-be/24-the-secrets-vault.md): genesis makes the operator key first,
 mints real credentials for the store and broker before the bundle raises them (or changes them
 on the running servers before handing over), accepts those, and installs `mesh-vault` so the
-operator-sealed export exists from the first push. The controller's half — the key, the second
+operator-sealed export exists from the first push. Built on `feat/secrets-vault` across mesh-host, mesh-controller and mesh-catalog, and proven by
-seal, export and recovery — is built; the installer's half is not.
+the one-node genesis bed: the template's password is refused by the store, the export and the
+vault's copy hold no plaintext, and the superuser recovered off the mesh with the operator key
+opens the store.