launchpad: row 255 design, M1 conditions from mos-1666 item 3 in section 1 and P1

agents/launchpad/work/queue-255/DESIGN.md

@@ -71,9 +71,23 @@ The loader (`scripts/mosaic-config.mjs`) checks the shape: `release` is a `vX.Y.
 differs from the pin file (section 2), `origin` is an https origin, `port` is 1024 to 65535. It also cross-checks: when
 `components["pocket-id"]` is present, `console.sso` must have exactly one provider, `id` `pocket-id`,
 `issuer` equal to `origin`. A config with `console.sso` providers and no `components` is the existing
-choice and loads as today. **M1 (to Mos): this is a new top-level config key.** The loader refuses unknown
+choice and loads as today.
-keys today, so it is a config schema change, with the same rollback trap Q175 section 4 names: a copy older
+
-than the build row refuses a config that has the key.
+**M1, approved by Mos with three conditions (mos-1666 item 3).** `components` is a new top-level config key.
+The loader refuses unknown keys today, so this is a config schema change. The conditions:
+
+1. **Rollback trap.** A copy older than P1 refuses a config that has the key, the same trap Q175 section 4
+   names for `console.sso`. P1 documents the order. On a rollback past P1, first take `components` out of
+   config.json (restore the backup made before the key went in), then roll back the pointer. The STATE check
+   after the rollback reads config.json and confirms the key is absent.
+2. **Strict inside the key.** The loader refuses any name under `components` other than `pocket-id`, and any
+   field under `pocket-id` other than `release`, `origin` and `port`. Each refusal names the key path and
+   quotes no value, as `checkConsole` does.
+3. **test-config.sh cases:**
+   - a valid `components` loads;
+   - a malformed one fails, naming the bad key path;
+   - a config without `components` loads;
+   - the cross-check refuses a `console.sso` whose provider doesn't match `origin`.
 
 What each choice writes into `console.sso` is in section 5. For the bundled choice, Pocket ID is the only
 providers entry. The design keeps it that way because REQ-INST-2 says "the Console's one providers entry".
@@ -357,8 +371,11 @@ mosaic.woltje.com or 127.0.0.1:7332. The stand-ins:
 All are post-v1 (REQ-INST-2). Each row has Webby or Sage's named reviewer and its own gate. None of them
 runs on .53, .54 or dragon-lin, and none installs Pocket ID on any host.
 
-1. **P1, loader key.** `components["pocket-id"]` in `mosaic-config.mjs` and the cross-check against
+1. **P1, loader key.** `components["pocket-id"]` in `mosaic-config.mjs`, strict inside the key, and the
-   `console.sso`. Gate: test-config.sh green with the new cases, plus Mos's ruling on M1 first.
+   cross-check against `console.sso` (section 1, M1 conditions from mos-1666 item 3). P1 also writes the
+   rollback order into `docs/TOOLS.md` beside Q175's: remove `components` (restore the backup) before the
+   pointer goes back, and the post-rollback STATE check confirms the key is absent from config.json. Gate:
+   test-config.sh green with the four M1 cases.
 2. **P2, pin and fetch.** `scripts/pocket-id-pins.sh` with the build-time sha256 and the
    attestation evidence, and `component-pocket-id.sh fetch|verify`. Gate: the fetch tests against the local
    stand-in; the evidence file shows `gh attestation verify` output for each pinned asset.
@@ -375,7 +392,7 @@ runs on .53, .54 or dragon-lin, and none installs Pocket ID on any host.
 
 ## Open items for review
 
-- **M1 (Mos):** the new top-level `components` key in config.json (section 1).
+- M1 approved by Mos with three conditions (mos-1666 item 3), written into section 1 and P1.
 - M2 dropped: Sage chose R1 and rejected R2 (sage-4401).
 - **Q1 (Webby):** the private network namespace for enroll (section 4). The other option is to start the
   real unit and race `/setup`, which I think is unsafe while agents share the host network.