From 7398b7dd7c2ffe921813141ecabc88d644660439 Mon Sep 17 00:00:00 2001 From: Jason Woltje Date: Wed, 21 Oct 2026 02:06:24 -0500 Subject: [PATCH] agents: row 195 DESIGN r6 (b7239bb66, approved duckworth-0055) carried onto c515273db unchanged, the base for r7 (#1693) --- agents/darkwing/work/queue-195/DESIGN.md | 872 +++++++++++++++++++++++ 1 file changed, 872 insertions(+) create mode 100644 agents/darkwing/work/queue-195/DESIGN.md diff --git a/agents/darkwing/work/queue-195/DESIGN.md b/agents/darkwing/work/queue-195/DESIGN.md new file mode 100644 index 000000000..46bbcf2b1 --- /dev/null +++ b/agents/darkwing/work/queue-195/DESIGN.md @@ -0,0 +1,872 @@ +# Row 195 design: the Case 1 install on 10.1.1.53 (r6) + +Darkwing, 2026-10-20. Brief: `docs/plans/2026-10-20_hub-own-uid.md`, blob 45be7f09afc1 (f24f2cd40, +sage-1439). Gitea #1693. Reviewer Duckworth, gate owner Sage. Chained on row 190's candidate (round 3, +df65a3d4c on `darkwing/row190-r3`, rebased on row 192; the config canon) and on row 230's candidate +(C2-13a, #1732, Gosalyn: `scripts/case2-unit.sh` and `case2-precheck.sh`), Q177, sage-1499. Row 230's +brief is `docs/plans/2026-10-20_case2-rows.md` "C2-13a" at 5b8def2f1, from Gosalyn's design r11 +(eac92d956 on `gosalyn/case2-design`, approved webby-0038). It has no candidate yet, so I read that +brief as the interface and expect a rebase. Section 2 lists what Case 1 needs from it that the brief +doesn't give. + +Changes from r5 (Duckworth's REVIEW-r4.md at 62200362b on `duckworth/reviews`, duckworth-0054). This +round changes only B1's and B2's lines, their section 7 cases and the notes: + +- B1. The result line `confirm` writes said op `confirm`, because `log_line` (:58) writes `$OP` and + `OP="$1"` (:1493). `from_log` (:169) reads only `adopt`, `activate` and `rollback`, so it would have + skipped every .53 activation: after adopt C0 and re-pins to C1 and C2, `from_log previous` returns + C0. Now A5's `ok` line and R4's line carry the op, from and to of the activation's `started` line, + and the backup that A3 records in the rollback set. Real sequence 7 and a mutant that writes op + `confirm`. Section 4. +- B2. r5 recorded the migration after the migrate, while today's run sets TAKEN before + `migrate-schema.mjs` (:1004-1005). A migrate that changed the store and then exited 1 would have + left no record, so R2 would skip the restore and R4 would gate OLD on a half-migrated store. A3 now + writes `MIGRATING` after `backup_store` returns and before the migrate. Real sequence 8 and a mutant + that records after the migrate. Section 4. +- N1. The marker step makes `$RS` with capture's exclusive `mkdir` (:416), and capture under + `--units external` makes none. N2. `gate` takes `--since T`, root's clock before its A2f start, as + its start floor. N3. Section 0 now has a read-only grep of `/etc/apparmor.d` for the word `bwrap`, + and item 3 matches the word against a list of exactly one file. N4. Item 4 runs under + `systemd-run` with the units' `NoNewPrivileges=yes`, as 2a' does. N5. A1's plan takes + `--expect-from OLD` and refuses `pointer-differs`. +- Not in this round: claude's path. gosalyn-0058 proposes that `--claude`, like `--node`, takes only a + root-owned path outside the home, and `/srv/mosaic/.local/bin/claude` fails that. I asked Sage to + rule and recommended moving claude under `/opt/mosaic-stack`. That change gets its own round. + +Changes from r4 (Duckworth's REVIEW-r3.md at 9f4d5556b on `duckworth/reviews`; mos-1098; mos-1101; +gosalyn-0049): + +- B1. An activation now has exactly one result line, written at the end. A5's gate failure and A3's + failure after its capture write no log line. Each writes a `FAILED` file next to `AWAITING-UNITS` and + exits 1, so the activation stays open for R2 and R4, and R4 writes the result. A3 writes + `AWAITING-UNITS` right after `started`. Refusals by `confirm`, `revert` and `gate` log no activation + id, so a refused `confirm` can't close one either. There are real-sequence tests on one log, and + mutants that put back r4's interim line, r4's marker order and a refusal that names the activation. + Section 4 and section 7. +- B2. The bwrap profile has an owner and a stop. `scripts/case1-hostcheck.sh` checks the profile file + against the pin in `scripts/case1-pins.sh`, the two loaded profiles, the live label of a process + bwrap runs, the statoverride and mode, that no other profile names bwrap, two sysctls and the port + floor. It has three callers: + 1. A1 of every re-pin refuses `profile-drift`. + 2. A root apt hook runs it after every package run, unattended ones included. + 3. A boot unit runs it before the bus starts. + + On drift, callers 2 and 3 unload the profile and close `/usr/bin/bwrap` to `mosaic`, so every role + session refuses to start. They write `DRIFT` and log it, and only root clears it. ops-01 owns the host + side under a Mos go: it reads the log in each STATE report and, before each re-pin window, compares + the upstream profile to the pin. A changed upstream profile becomes a new pin, which is its own review + round. Section 1 has the details. The facts behind it are in section 0: unattended-upgrades runs daily + on .53 with the security pocket, and the pinned bubblewrap is in that pocket. +- N1 and mos-1098 point 2. P9 has a seventh item: no `mosaic-bwrap` profile is loaded, and no profile + other than Ubuntu's attaches to `/usr/bin/bwrap`. r4 never installed `mosaic-bwrap`. F5 now compares + exact strings. P9 reads `accepted mos-1096` only while all seven items hold. +- N2: a role session gets no capabilities, so a nested bwrap fails. Section 1. N3: A3 refuses "before + it logs `started`". N4: the stale-start rule and its fixtures handle `ActiveEnterTimestamp`'s whole + seconds. +- The port squat (mos-1101 item 5, gosalyn-0049). It applies: role sessions share the host's network + namespace (`packages/seat/src/sandbox.mjs:67` unshares no net), so while the Console is down a + session can bind its loopback port. The Console moves to 127.0.0.1:732 with + `CAP_NET_BIND_SERVICE` on its unit (row 230's line), so no session can take it. The tester port stays + 7333, because serve refuses a tester port below 1024. That residue is P10, accepted under Mos's + reading. Case 1 can't meet the preview trio or the proof pair, because .53 has no proxy. Section 2 + names the factory serve set for row 230. +- Jason's Q9 (Vikunja #429) is still open. If install and upgrade become product commands, these + steps become that installer's configuration and row 195 rebases on its row (sage-1491). Section 6. + +## 0. What I checked on the host + +Read only, as `localadmin` over ssh, 2026-10-20 between 20:40Z and 21:00Z, and again at 21:27Z for the +last seven rows (the brief allows this): + +| Item | 10.1.1.53 today | Needed | +|---|---|---| +| OS | Ubuntu 24.04.5, kernel 6.8.0-124, x86_64, 12 cores, 94 GiB, 217 GiB free on `/` | fits | +| `mosaic` user, group, `/srv/mosaic` | absent | step 2a creates them | +| node | `/usr/local/bin/node` v22.22.2, root-owned | 24 or later (every `packages/*/package.json` engines line); dragon-lin runs 26.8.1 | +| bwrap | absent, no statoverride; apt candidate `bubblewrap 0.9.0-1ubuntu0.3` | every role session runs under `/usr/bin/bwrap` (`packages/seat/src/sandbox.mjs:43`) | +| user namespaces | `kernel.apparmor_restrict_unprivileged_userns = 1`, apparmor 4.0.1, no bwrap profile loaded | bwrap needs a user namespace, which this setting refuses unless a profile allows it | +| `apparmor-profiles` | not installed; candidate `4.0.1really4.0.1-0ubuntu0.24.04.9`, whose `/usr/share/apparmor/extra-profiles/bwrap-userns-restrict` has sha256 `11d39094f044f0cda0febb3ad517b830301da6b2ce929664af09ee9e4dd264f9` (read from the deb on dragon-lin) | section 1 | +| `fs.protected_hardlinks`, `fs.protected_symlinks` | 1, 1 | mos-1096 item 2 | +| journald | `SplitMode=uid` (the default) | section 4, B2 | +| `useradd` | `USERGROUPS_ENAB yes` | 2a passes `--user-group` anyway | +| claude | not on localadmin's PATH | the factory's harness; dragon-lin runs 2.1.304 | +| ports 7330-7333 | free (no listener) | tester | +| `localadmin` | NOPASSWD sudo (#423 step 1, applied 20:05:47Z, mos-1066, mos-1077) | the root steps run through it | +| `jarvis` | groups sudo, docker, lxd, adm | #423 step 4 removes all four (section 5, P5) | +| unattended-upgrades | on: `APT::Periodic::Unattended-Upgrade "1"`, `apt-daily-upgrade.timer` enabled. Allowed origins `${distro_id}:${distro_codename}`, `-security`, ESM apps-security and ESM infra-security. No `Package-Blacklist` | B2: packages change daily without a window | +| bubblewrap's pocket | `0.9.0-1ubuntu0.3` is in both `noble-updates` and `noble-security`, so its later security updates install unattended | B2 | +| apparmor | installed `4.0.1really4.0.1-0ubuntu0.24.04.8`. The `.9` candidate is in `noble-updates` only, which unattended-upgrades doesn't take. `aa-status --json` works | B2 | +| profiles that name bwrap | at 21:51:46Z `grep -rlw bwrap /etc/apparmor.d` and `grep -rlF /usr/bin/bwrap /etc/apparmor.d` both find nothing (exit 1). After 2a' the word grep lists only `bwrap-userns-restrict` | N1, P9 item 7, hostcheck item 3 | +| `net.ipv4.ip_unprivileged_port_start` | 1024 | the port squat | +| listeners below 1024 | 22 (sshd) and 53 (the resolver) only; 732 is free | the Console's port (section 1) | +| other listeners | 4003, 6052, 6055, 8123, 8765, 14242, 18555, and on loopback 1933, 5905, 6085, 6379, 6380, 9119, 9225, 18554, 18789, 38147 | none in 7330-7333 | + +## 1. The install as inputs to the Case 2 scripts + +Instance. Row 190's canon with the default name, `dev`, as Case 2 uses it (Gosalyn design 9). `~` is +`mosaic`'s home, `/srv/mosaic`, so: + +| Input | Value | +|---|---| +| user | `mosaic`, primary group `mosaic` with no other member | +| home | `/srv/mosaic`, 0700, owner `mosaic` | +| config dir | `/srv/mosaic/.config/mosaic-dev` | +| data root | `/srv/mosaic/.mosaic-dev`, marker `instance.json` `{"instanceVersion":1,"name":"dev"}` | +| business | `mosaic-stack`, file `/businesses/mosaic-stack.json` (section 2) | +| profile | `--profile factory` (row 230, C2-13b) | +| roles | the factory set in section 2 | +| human id | Jason's id, given in the window's go. Not `tester` (`broker.mjs:245`) | +| model credential | `/secrets/claude-session.env`, 0600 (row 190's `SESSION_ENV` for the default instance) | +| token slot path | none for this row (section 2) | +| Console port | 127.0.0.1:732, below the port floor, bound through the Console unit's `CAP_NET_BIND_SERVICE` (row 230). The port squat below says why | +| tester port | 127.0.0.1:7333 (P10) | +| board | none. UNITS has no board unit, and the Console gets no `--board` | +| harness | claude at `/srv/mosaic/.local/bin/claude`, pinned through `MOSAIC_CLAUDE_BIN` (decision 91), which the bus unit's `@CLAUDE_ENV@` line sets (section 2) | +| node | `/opt/mosaic-stack/node-/bin/node`, a pinned 26.x release, `root:root`. Row 230 refuses a `--node` under the home or not owned by root | +| PM | on: the bus unit's `@PM_FLAGS@` renders ` --pm` (section 2, section 4) | +| source | `/srv/mosaic/src/mosaic-stack` (`mosaic`'s checkout, section 4) and `/root/mosaic-stack` (root's) | + +Why `dev` and not a named instance: one instance per OS user, and Case 2's rows already assume +`/srv/mosaic/.config/mosaic-dev`. A second instance under `mosaic` on .53 would need a name, and row 190 +makes that a flag, not a move. + +Why node lives under `/opt/mosaic-stack`: changing `/usr/local/bin/node` would change what Hermes and +anything else on the host runs, and Q181 keeps Hermes running. r4 put node under `/srv/mosaic`, but row +230 requires a root-owned `--node` outside the home. Nothing else on the host puts `/opt/mosaic-stack` +on its PATH. + +PATH for `mosaic`'s steps. `sudo -u mosaic -H` resets PATH to sudo's `secure_path`, which finds +`/usr/local/bin/node`, v22. The precheck would then refuse, and `scripts/mosaic` would run v22 (it runs +`exec node` from PATH, `scripts/mosaic:22-40`). So every `mosaic` step in the run sheet and in +`case1-repin.sh` runs as `sudo -u mosaic -H env PATH=:/usr/local/bin:/usr/bin:/bin ...`, the +list row 230 renders as the units' `@PATH@`. `case1-repin.sh` builds it from the `--node` in +`case1-unit.args`. + +The units (row 230, design r11). Two system units, from the existing templates, in start order: +`mosaic-bus@mosaic-stack.service` from `packages/cli/systemd/mosaic-bus.service.in`, then +`mosaic-webui.service` from `packages/webui/systemd/mosaic-webui.service.in`. Root stops them in the +reverse order. `@REPO@` is the copy dir, and `%h` becomes the literal home. Row 230 adds +`ProtectSystem=strict`, `ReadWritePaths=/srv/mosaic`, `ProtectHome=yes` and `PrivateTmp=yes` to both, and +`AmbientCapabilities=CAP_NET_BIND_SERVICE` with `CapabilityBoundingSet=CAP_NET_BIND_SERVICE` to the +Console only. The Console unit has no `[Install]`, so root starts it by hand after a reboot until Jason +rules (mos-1097). The install call is: + +``` +case2-unit.sh --profile factory --user mosaic --home /srv/mosaic --business mosaic-stack --copy ID \ + --node /opt/mosaic-stack/node-/bin/node --pm --claude /srv/mosaic/.local/bin/claude \ + -- --port 732 --business mosaic-stack --tester-port 7333 +``` + +`--pm` and `--claude` are the two inputs row 230's brief doesn't have yet (section 2). A re-install +must pass the same `--node`, flags and serve flags, and only the copy id may change (row 230's +re-install check). So 2c writes the whole argument list, without `--copy`, to +`/etc/mosaic-stack/case1-unit.args`, `root:root` 0644, one argument per line. Every later +`case2-unit.sh` call in section 4 reads that file and adds `--copy`. `mosaic` can't write it. Changing +a serve flag is a re-install with its own go, not a re-pin. + +The port squat (mos-1101 item 5). Role sessions share the host's network namespace: +`packages/seat/src/sandbox.mjs:67` unshares the user, PID and IPC namespaces and not the network. So +while the Console is down, which A2 to A4 of every re-pin and any crash before `Restart=on-failure` +brings it back both cause, a session can bind 127.0.0.1:7332. It would then receive Jason's `ssh -L` +traffic, and it would answer the gate's `/healthz` (`stack-release.sh:485-487`) in the Console's place. +At 732 that can't happen. The floor is 1024 (section 0), a session has no capabilities (below), and +`mosaic`'s own processes outside the sandbox have none either. Only the Console unit holds +`CAP_NET_BIND_SERVICE`. Its children, the human-cli and read scripts it spawns +(`packages/webui/src/bus.mjs:31`, `reads.mjs:79`), inherit the ambient capability. No role session +descends from the Console: sessions are children of the bus unit, which has no capability line. The +gate needs no change, because `console_port` (`stack-release.sh:213-215`) reads the Console's `--port` +from the pointer. Row 230's precheck refuses when the floor is at or below the Console's port, and +`case1-hostcheck.sh` checks it after every package run (B2). The tester port can't go below 1024, +because serve refuses that (`packages/webui/src/cli.mjs:33`), so P10 records it. + +Node download (N4). The run sheet pins one release, its tarball name and its sha256. As root, in a +root-owned temp dir: fetch the tarball, `SHASUMS256.txt` and `SHASUMS256.txt.asc`; `gpg --verify` the +`.asc` against the Node release keys listed in the nodejs/release-keys repository, imported into a +keyring under `/etc/mosaic-stack/node-keys`; check that the tarball's line in the verified file is the +pinned sha256; then `sha256sum -c` the tarball and unpack it to `/opt/mosaic-stack/node-`, +`root:root`, no file writable by group or other. Any mismatch stops the step. Rollback: `rm -r` that +dir. + +Claude (N5). The run sheet pins the version, 2.1.304 unless the window's plan names a newer one. As +`mosaic`: `npm install --prefix /srv/mosaic/.local @anthropic-ai/claude-code@`, with `@` +exact. `/srv/mosaic/.local/bin/claude` is the path `MOSAIC_CLAUDE_BIN` names. The autoupdater stays off +through `/etc/claude-code/managed-settings.json`, `root:root` 0644, holding +`{"env":{"DISABLE_AUTOUPDATER":"1"}}`. Root writes it in 2a'. Why there: + +- `ENV_ALLOW` (`packages/seat/src/session.mjs:83-88`) doesn't pass `DISABLE_AUTOUPDATER`, so a unit + `Environment=` line never reaches a role session (gosalyn-0046 item 3). +- A role session's HOME is the run's own `home/`, and the sandbox doesn't show `~/.claude` + (`session.mjs:92-93`, `sandbox.mjs:16`). So `mosaic`'s claude settings file doesn't reach one either. +- The sandbox mounts `/etc` read-only (`sandbox.mjs:85`), and Claude Code reads managed settings from + `/etc/claude-code/` whatever HOME is. `mosaic`'s own CLI runs, like the precheck's marker prompt + and F6, read it too. + +The pinned binary is a read-only bind inside the sandbox (`sandbox.mjs:9-10`), so a session can't +rewrite it anyway. The managed file covers `mosaic`'s runs outside the sandbox. If the installed +version doesn't honour `env` there, F6 catches the drift. Rollback: `rm` the file. + +bwrap and the user namespace (mos-1091 4a, 4b; mos-1096 item 2; N1). Three root steps in 2a', in this +order, each with its rollback. The `mosaic` group must exist first (2a). + +1. `apt-get install bubblewrap=0.9.0-1ubuntu0.3`, the version the run sheet pins. Then record + `stat -c '%U:%G %a' /usr/bin/bwrap` to `/etc/mosaic-stack/bwrap.orig` (I expect `root:root 755`). + Rollback: `apt-get remove bubblewrap`. +2. Ubuntu's own `bwrap-userns-restrict`, one file, not the package. `apt-get download + apparmor-profiles=4.0.1really4.0.1-0ubuntu0.24.04.9` into a root-owned temp dir, extract + `./usr/share/apparmor/extra-profiles/bwrap-userns-restrict` with `dpkg-deb --fsys-tarfile`, check + its sha256 is `11d39094f044f0cda0febb3ad517b830301da6b2ce929664af09ee9e4dd264f9`, and install it as + `/etc/apparmor.d/bwrap-userns-restrict`, `root:root` 0644. Load it with `apparmor_parser -r + /etc/apparmor.d/bwrap-userns-restrict`. `aa-status` then lists `bwrap` and `unpriv_bwrap` in + enforce mode. Why one file: the package also installs 20 profiles under `/etc/apparmor.d` + (`usr.sbin.dnsmasq`, `bin.ping`, `usr.sbin.smbd` and more), which would load at the next boot and + could change services on the host that have nothing to do with Mosaic. + What the profile does: `bwrap` gets `userns`, `capability` and `mount` for its own setup, and + every program it runs is stacked under `unpriv_bwrap`, which has the same file and network rules + with `audit deny capability`. So a role session gets a user namespace and no capabilities in it. + The sysctl stays at 1, so nothing else on the host gains user namespaces. + One consequence (N2): a bwrap that a session starts inside its own sandbox fails, because it needs + capabilities in the namespace. Claude Code's own sandbox is such a bwrap, and it's off by default, + so a role session doesn't use it. F3 shows a session still answers under the profile. + Rollback: `apparmor_parser -R /etc/apparmor.d/bwrap-userns-restrict`, then `rm` it. +3. `dpkg-statoverride --update --add root mosaic 0750 /usr/bin/bwrap` (Mos). Only root and the + `mosaic` group can read or run bwrap, and package upgrades keep the mode. Rollback: + `dpkg-statoverride --remove /usr/bin/bwrap`, then `chown` and `chmod` to the values in + `bwrap.orig`. +4. The drift stop (B2, below): `case1-hostcheck.sh` and `case1-pins.sh` from `/root/mosaic-stack` to + `/usr/local/lib/mosaic-stack/`, `root:root` 0755 and 0644; the apt hook + `/etc/apt/apt.conf.d/80mosaic-hostcheck`; the boot unit `mosaic-hostcheck.service`, enabled. Then + `case1-hostcheck.sh --check` exits 0. Rollback: disable and remove the unit, `rm` the hook file and + the dir. + +Full rollback runs 4, 3, 2, 1. Tests after 2a' and again in section 5: as `mosaic`, `bwrap --unshare-all +--ro-bind / / true` exits 0 (row 230's precheck line, F4); as `jarvis`, `/usr/bin/bwrap --version` +fails with "Permission denied" (P9); `getent group mosaic` lists no member and no other account has +gid `mosaic` (P9); `fs.protected_hardlinks` is 1 (P9). A role session running under the profile is F5. + +One more test runs in 2a', because I can't settle it from here. Row 230's units keep the templates' +`NoNewPrivileges=yes`, and AppArmor limits profile changes for a task with no-new-privs set. The +`bwrap` attach happens on exec from an unconfined task, and the child's change is a stack +(`bwrap//&unpriv_bwrap`), which only narrows. I expect both to pass under no-new-privs, since bwrap +sets no-new-privs on itself before it runs the child, and Ubuntu's profile works with that. But I +haven't seen it run, and .53 is read-only to me. So as root, after step 4: `systemd-run --wait --pipe +--uid=mosaic --gid=mosaic -p NoNewPrivileges=yes -p ProtectSystem=strict -p ProtectHome=yes -p +PrivateTmp=yes /usr/bin/bwrap --unshare-user --unshare-pid --ro-bind / / cat /proc/self/attr/current` +prints `bwrap//&unpriv_bwrap (enforce)`. If it fails, the window stops at 2a' and rolls back 4 to 1, +before any `mosaic` step. That beats finding it at F5. + +The drift stop (B2, Duckworth's REVIEW-r3 B2, mos-1098 point 1). r4 installed a profile file that no +package owns, from a pinned deb, onto a host where unattended-upgrades changes packages every day +(section 0). Three things can move under it: bubblewrap (its security updates install unattended), the +`apparmor` package and its parser, and any new profile a package ships that attaches to +`/usr/bin/bwrap`. Two more host values matter to this design: the user-namespace sysctl and the port +floor. So: + +- `scripts/case1-pins.sh` holds the pins, sourced by the scripts below: the `apparmor-profiles` version + the file came from, the file's sha256, and the bubblewrap version 2a' installs. Changing a pin is a + reviewed commit and its own round. The bubblewrap version is an install pin, not a drift item: + a security update to bubblewrap keeps the statoverride, and the profile attaches by path. +- `scripts/case1-hostcheck.sh` checks seven items and prints one line each: + 1. `/etc/apparmor.d/bwrap-userns-restrict` has the pinned sha256, and `dpkg -S` finds no package + that owns it. + 2. `aa-status --json` lists `bwrap` and `unpriv_bwrap` in enforce mode, and no loaded profile named + `mosaic-bwrap`. + 3. `grep -rlw bwrap /etc/apparmor.d` lists exactly `/etc/apparmor.d/bwrap-userns-restrict`. The word + match also catches a path written as `/{usr/,}bin/bwrap`. Section 0's read found no file today. + 4. The live label: 2a' line `systemd-run --wait --pipe --uid=mosaic --gid=mosaic -p NoNewPrivileges=yes + -p ProtectSystem=strict -p ProtectHome=yes -p PrivateTmp=yes /usr/bin/bwrap --unshare-user + --unshare-pid --ro-bind / / cat /proc/self/attr/current` prints exactly `bwrap//&unpriv_bwrap + (enforce)`. It runs under the units' no-new-privs, so it reads the label a role session gets. + This catches a profile that attaches by a glob that item 3's search misses. + 5. `dpkg-statoverride --list /usr/bin/bwrap` reads `root mosaic 0750`, and `stat` agrees. + 6. `kernel.apparmor_restrict_unprivileged_userns` is 1 and `fs.protected_hardlinks` is 1. + 7. `net.ipv4.ip_unprivileged_port_start` is above the Console's `--port` in the installed unit. + + `--check` exits 0 when all hold and 1 otherwise. `--enforce` runs the same check and always exits 0. + On a failure, or while `/etc/mosaic-stack/DRIFT` exists, it applies the stop: + `apparmor_parser -R` on the profile if loaded, then `chown root:root` and `chmod 0700` on + `/usr/bin/bwrap`. It writes the failed items to `DRIFT` and appends a line to + `/var/log/mosaic-stack/hostcheck.log`. With bwrap closed to `mosaic`, every role session refuses + to start. That's the fail-closed state, and the stack needs no change for it. The chmod is undone by + the next bubblewrap upgrade, which reapplies the statoverride. But the apt hook runs again right + after that upgrade and finds `DRIFT`, so it closes bwrap again. Only root removes `DRIFT`, in a + reviewed step with a new pin or a Mos go. I don't call `dpkg-statoverride` from inside the hook, + because I haven't confirmed it can take dpkg's lock while apt holds the frontend lock. +- Three callers. A1 of every re-pin runs `--check` and refuses `profile-drift` on exit 1. The apt hook + is `DPkg::Post-Invoke { "/usr/local/lib/mosaic-stack/case1-hostcheck.sh --enforce || true"; };`, so it + runs after every package run, unattended ones included, and can't fail one. The boot unit, + `mosaic-hostcheck.service` (`Type=oneshot`, `After=apparmor.service`, + `Before=mosaic-bus@mosaic-stack.service`, `WantedBy=multi-user.target`), runs `--enforce` before the + bus starts, which covers a kernel or parser change that takes effect at boot. +- Owner. ops-01 owns the host side under a Mos go. It reads `hostcheck.log` in each STATE report and + sends any `DRIFT` to Mos. Before each re-pin window it also runs `--upstream`, which downloads the + current `apparmor-profiles` candidate into a temp dir and compares its `bwrap-userns-restrict` to the + pin. A difference goes to Mos as a new-pin request and refuses nothing. The pins and the scripts are + this row's, and later changes go through review like any other. + +Who runs what: + +| Step | Runs as | Through | +|---|---|---| +| 2a: `useradd --system --user-group --home-dir /srv/mosaic --shell /usr/sbin/nologin mosaic`, `/srv/mosaic` 0700, `/etc/mosaic-stack` `root:root` 0755, `/var/log/mosaic-stack` `root:root` 0750 | root | ops-01, `ssh localadmin@10.1.1.53`, `sudo` (#423 step 1) | +| 2a': node under `/opt/mosaic-stack`; bubblewrap, the AppArmor profile, the statoverride, the drift stop and the managed settings file, each with the test and rollback above; the no-new-privs test | root | ops-01, same path, R27 (mos-1091) | +| 2a'': a `git bundle` of the reviewed commit copied to .53; root clones it to `/root/mosaic-stack` and checks HEAD is the commit the go names; it installs the bundle as `/srv/mosaic/incoming/.bundle`, owner `mosaic`, 0600 | root | ops-01, same path | +| 2b: claude under `~/.local` (above); `git clone` of the bundle to `/srv/mosaic/src/mosaic-stack`; `scripts/bootstrap.sh`; `stack-copy.sh copy`; the install with the inputs above (C2-13b's `case2-install.sh --profile factory` if it has landed, else the run sheet's steps) | `mosaic` | `sudo -u mosaic -H env PATH=...` from `localadmin` (PATH above). `mosaic` gets no key and no login shell | +| 2b': place `claude-session.env` | Jason, or who he names (Q173 secrets rule) | section 3 | +| 2c: write `case1-unit.args`; `case2-unit.sh` with those arguments and `--copy `, from `/root/mosaic-stack`; then `case2-precheck.sh --profile factory` as `mosaic`, which reads the Console's `--port` from the installed unit for its port-floor line, so it runs after the render; `systemctl enable` the bus unit; the first start of UNITS. The Console unit has no `[Install]` until Jason rules (C2-13a), so it isn't enabled, and after a host reboot root starts it by hand until then. The run sheet says so | root | ops-01, same path | +| 2c': `stack-release.sh adopt mosaic-stack --units external`, which records the running copy as the pointer (`do_adopt`, `scripts/stack-release.sh:856`) | `mosaic` | `sudo -u mosaic -H` | +| every later re-pin or rollback | root, with its `mosaic` steps through `sudo -u mosaic -H` | ops-01 runs `case1-repin.sh` (section 4) | +| acceptance (section 5) | `localadmin`, with `sudo -u mosaic -H` for the in-instance checks | the agent the window names | + +No git credential lands on .53. Both checkouts come from bundles that ops-01 copies in, and a re-pin +brings a new bundle that `mosaic` fetches into its checkout. + +## 2. Where Case 1 differs from Case 2 + +| Case 2 item (row 230 brief) | Case 1 | Reason | +|---|---|---| +| business file with the library mapping | business `mosaic-stack` with no `library` key; `--profile factory` refuses a `kind: "library"` project (`profile-library-business`) | the factory has no books repo | +| `bean`, `chet`, persona vars and files, specialists | factory roles from `roles/`, with a chief that has a harness var | Jason names the set in the go. I haven't read his live business file and won't. The acceptance needs only the chief (F3), since a chief with no harness var answers `no-route`. Others are added later by the human with `instances.set`, no new row | +| token slot `library-gitea` | none | the factory's per-agent git identity is row 199's credential store (Megavolt, #1697). Until it lands, git work stays on dragon-lin (Q182) | +| precheck: `bus.tester` is not on | `bus.tester` is on; `factory` requires it | the acceptance and the Q173 test system need the tester (agents act as tester, never Jason) | +| precheck: persona file modes and digests | skipped under `factory` | no persona files | +| precheck: `library.sync`, `library.status` | skipped under `factory` | no library | +| precheck: `ZAI_API_KEY` in the key file | doesn't run | no instance has provider `zai` | +| precheck: no Discord binding | kept | the factory's Discord connector stays on dragon-lin. Two connectors on one bot token would split its events | +| precheck: claude marker prompt with `--system-prompt-file` | runs, since the chief's harness is claude-code | | +| precheck: `sudo -n true` fails, `id -G` one entry, run root 0700, config validates, node 24 or later, `bwrap` exits 0, free memory, HOME | kept | node and bwrap are in row 230 (gosalyn-0034) | +| Console serve flags: `--port` 1..1023, `--business`, the preview trio, `--send`, the proof pair, no `--tester-port` | `--port 732`, `--business mosaic-stack`, `--tester-port 7333`. No preview trio, no `--send`, no proof pair | below | +| bus: `@PM_FLAGS@` and `@CLAUDE_ENV@` render empty | ` --pm`, and `Environment=MOSAIC_CLAUDE_BIN=/srv/mosaic/.local/bin/claude` | below | + +All of these are inputs. Nothing in the Case 2 scripts hardcodes a Case 1 value (gosalyn-0034 item 4). +Row 230's brief says the factory profile takes the library serve set plus an optional `--tester-port`, +and that row 195 names any other difference (gosalyn-0049). .53 can't meet the library set, and the bus +needs two lines the brief renders empty. The factory profile I need from row 230: + +1. Serve flags. `--port N` with N in 1..1023 and `--business ID` are required, and `--tester-port N` in + 1024..65535, not equal to `--port`, is optional. The preview trio (`--public-host`, `--auth-header`, + `--allow-user`) and the proof pair (`--proof-header`, `--proof-file`) are refused. Both exist for a + proxy in front of the Console: the proxy signs the user in and adds the header, and the proof shows + the request came through it. .53 has no proxy. Jason reaches the Console with `ssh -L` (sage-1451 + Q3), so there is no header to trust and no proxy to hold the proof. `--send` is refused too, since + serve takes it only with the trio or `--sso` (`packages/webui/src/cli.mjs:15`). When Q175 SSO reaches + .53, `--sso` with an optional `--send` (row 192) would be the factory's sign-in, and adding it is a + re-install with its own go. Row 230 can accept `--sso [--send]` under factory now or later. Either + way it needs a `console.sso` block in `mosaic`'s config, which this row doesn't write. `--checkout` + and `--board` stay refused, as in the library set. +2. `--pm` (factory only) renders the bus unit's `@PM_FLAGS@` as ` --pm`. The factory's PM dispatches its + work on .53 as on dragon-lin (section 4). With the token empty the bus never launches the PM, and + A5's PM check fails every re-pin. +3. `--claude PATH` (factory only) renders `@CLAUDE_ENV@` as `Environment=MOSAIC_CLAUDE_BIN=PATH`, the + line `scripts/bus-service.sh:79` renders today. PATH must be absolute. Without it the bus runs + `claude` from the unit's PATH, which is the node dir, `/usr/local/bin`, `/usr/bin` and `/bin`, and + holds no claude on .53. The chief's first launch would then fail. The precheck's claude marker + prompt should run the same binary, so it reads the path from the installed bus unit. +4. Row 190's two template tokens, if row 190 lands before row 230. Row 190 adds `@CONFIG_ENV@` to both + templates and `@SESSION_ENV@` to the bus template's `EnvironmentFile=` line. For the default + instance, `@CONFIG_ENV@` is deleted (`scripts/instance.sh`) and `@SESSION_ENV@` is + `/.config/mosaic-dev/secrets/claude-session.env`. Row 230's "every token has one value" list + and its `EnvironmentFile=` check need both. This applies to the library profile too. + +I've sent these to Gosalyn. If row 230's candidate lacks any of them, row 195's manifest names the +change to `case2-unit.sh` or `case2-precheck.sh`, reviewed by Duckworth with Webby told. + +## 3. Model access + +Q185: Case 1 uses the account the factory uses today, the Claude subscription behind dragon-lin's +`claude-session.env`. The install never copies that file from dragon-lin. In the window, Jason (or the +person he names under the Q173 secrets rule) makes a credential for .53 from that account and writes it +to `/srv/mosaic/.config/mosaic-dev/secrets/claude-session.env` as `mosaic`, mode 0600. Nobody prints it, +and no script reads its value. The precheck checks only its mode, owner and that the variable name is +present (a `grep -c` on the name, output a count). + +Quota: the factory on dragon-lin and on .53 share one subscription. Q185's "use existing" accepts that. +Case 2 shares nothing with it (Mos's reading of Q185). + +The pi harness stays off on .53 until P19 #383 settles (mos-0865). The business file names claude only. + +## 4. Re-pin, rollback and backup on .53 + +Unit form (ruled, sage-1451 Q1): system units that root writes, with `User=mosaic`. `mosaic` can't +start or stop them, and root never runs code that `mosaic` can write. `stack-release.sh activate` today +does everything in one run under `systemctl --user` and puts the old stack back inside that run +(`rollback_in_run`, `scripts/stack-release.sh:561`). On .53 the same run needs two users. So one +re-pin is one ordered list, and one root command drives all of it: `scripts/case1-repin.sh`, run by +ops-01 from `/root/mosaic-stack`. Each `mosaic` step is `sudo -u mosaic -H` running +`/srv/mosaic/src/mosaic-stack/scripts/stack-release.sh` with `--units external`. Copies carry no +`stack-release.sh` (`COPY_PATHS`, `scripts/stack-copy.sh:23-30`), so the `mosaic` steps run from that +checkout, as dragon-lin's run from the canonical one. + +What root holds, and where each value comes from (r4's B1): + +| Value | Source | +|---|---| +| ID, the target copy | the go | +| TO, a rollback's target | the go, as `--to ID` | +| `--restore ACT --events N` | the go, when the rollback restores | +| OLD, the running copy | the `ExecStart=` of the two unit files root installed. If the bus and Console units name different copies, A1 refuses `units-disagree` | +| the `case2-unit.sh` arguments | `/etc/mosaic-stack/case1-unit.args` (section 1) | +| each `mosaic` step's result | its exit code | + +Root parses nothing `mosaic` wrote and runs nothing under `/srv/mosaic` except through `sudo -u mosaic +-H`. It never needs the activation id: the `mosaic` steps find it themselves. + +One result line per activation (B1). The stack log closes an activation on the first line after +`started` that names it, whatever the result (`interrupted`, :146-156). r4 wrote an interim +`... rollback pending` line at A3's and A5's failures. That line closed the activation, so R2 and R4 +then refused `open-activation` against an activation the log no longer held open. The rollback could +never run as designed, and nothing tested the steps in sequence. r5 keeps an activation open from A3's +`started` line until its single result line, and A5 or R4 writes that line: + +| Activation ends at | Result line | Written by | +|---|---|---| +| A3 fails before its rollback set exists (marker or capture) | `refused code marker-failed` or `refused code capture-failed`, as `capture || refuse` does today (:987). Nothing has changed, so there is nothing to roll back | A3 itself, exit 3, after it removes the marker. Root runs A2f | +| A5 passes | `ok` | A5 | +| A3 (after capture), A4 or A5 fails, and the rollback passes | `failed code rollback ok` for A3 and A4, `gate-failed code rollback ok` for A5 | R4 | +| the rollback fails at R4's gate | `rollback-failed code rollbackCode ` | R4 | +| R1, R2 or R3 fails, or the run dies | none. The activation stays open, and the next activate refuses `interrupted-run` (:603-606), which Jason or Mos settles as on dragon-lin | | + +What the result line carries (r5's B1). `log_line` (:58) writes `op "$OP"`, and `from_log` (:169) +reads only lines whose op is `adopt`, `activate` or `rollback`. So `confirm` doesn't log under its own +op. Before A5's `ok` line or any line R4 writes, it sets OP, FROM and TO from the open activation's +`started` line, ACT to that activation, and BACKUP from the rollback set's `BACKUP` file, which A3 +writes when `backup_store` returns. A re-pin's lines then read `op activate`, a rollback's `op +rollback`, each with the from, to and backup a dragon-lin run would log. `from_log previous` and +`from_log backup` read .53's log as they read dragon-lin's. `confirm` reads only the line A3 wrote for +that activation, which `interrupted` already names. + +A failing `mosaic` step after `started` writes no log line. It writes its code to `FAILED` beside +`AWAITING-UNITS` and exits 1. R4 reads that code for the result line. Root passes R4 `--cause +A3|A4|A5`, the step it saw fail, from its own exit codes. A4 is root's own step and has no `FAILED` +file, so R4 writes `failed code units-start` for it. A cause with no `FAILED` file where one should be +writes code `unrecorded`. + +The open activation. A3 writes `$STATE/stack-rollback//AWAITING-UNITS` holding the target copy +(renamed from r3's `PENDING`, which read like the pointer's `pmPending`, `P_PENDING` at :128; N3). +`confirm` and `revert` take the copy root passed, not an activation id. Each lists the +`AWAITING-UNITS` files and the `interrupted` set (:146), and goes on only when there is exactly one +file, its activation is the one `interrupted` names, and the copy in it is the copy root passed. +Anything else refuses `open-activation` with exit 3 and the list it found, and changes nothing. +`confirm` without `--rollback` also refuses `activation-failed` when `FAILED` exists, so a second +confirm can't pass an activation that already failed. Whichever `confirm` writes the result line +removes `AWAITING-UNITS` and `FAILED` after it. + +Refusals of the three external verbs. `confirm`, `revert` and `gate` act on an open activation by +design, so they skip the `interrupted-run` refusal (:605). Their refusals log `result refused` with no +activation id: they set ACT only after every check has passed. So a refused `confirm`, a wrong copy +say, leaves the open activation open. Today's `refuse` (:62-67) adds the activation id whenever ACT is +set, and the external verbs keep that order. A test and a mutant hold it (section 7). + +Root's step log. Every step `case1-repin.sh` runs appends one line to `/var/log/mosaic-stack/case1-repin.log`, +`root:root` 0640: the time from `date -u`, the step, its argv, its exit code. `mosaic` can't write it, +so it stays readable after a run that dies before `mosaic` logs anything. + +### Activate: `case1-repin.sh activate ID [--migrate] [--timeout S]` + +| # | Step | Runner | On failure | +|---|---|---|---| +| A1 | `/root/mosaic-stack` HEAD is the commit the go names. ID is 40 lowercase hex and names a copy under `/srv/mosaic/.local/share/mosaic-stack/copies` that holds `scripts/mosaic` (row 230's copy-id rule). `case1-hostcheck.sh --check` exits 0, else `profile-drift` (B2). Root reads OLD from the unit files. `stack-release.sh activate ID mosaic-stack --units external --plan --expect-from OLD` exits 0. The plan refuses `pointer-differs` when the pointer's copy isn't OLD (N5), so a pointer and units that disagree stop before any stop | root; the plan as `mosaic` | refuse, exit 3. Nothing has changed | +| A2 | `systemctl stop` UNITS in reverse order, then wait until each is inactive, within `--timeout` | root | A2f below | +| A3 | `stack-release.sh activate ID mosaic-stack --units external [--migrate]`. Before it logs `started` (N3), it refuses `units-running` unless each of UNITS is inactive (system-manager reads, which need no privilege) and the store is stopped (`stopped`, :359), and `interrupted-run` while any activation is open. Then, in this order: logs `result started`; makes `$RS` with capture's `mkdir -p` of `stack-rollback` and exclusive `mkdir -m 0700` (:415-416), and writes `AWAITING-UNITS` in it at once (N1); captures the rollback set into that directory, making none (pointer, wrapper, and the sha256 and `ExecStart=` of each installed unit, read only); takes `backup_store` (:372) into `$DATA/backups/stack/` and writes its name to `BACKUP` in the rollback set; under `--migrate`, writes `MIGRATING` in the rollback set and sets TAKEN, both before `migrate-schema.mjs` runs, where today's run sets TAKEN (:1004-1005, r5's B2), then migrates; installs the wrapper for ID. It writes no pointer | `mosaic` | a refusal before `started` exits 3 with nothing changed. A marker or capture failure, an existing `$RS` included, removes the marker if it wrote one, logs its `refused` line and exits 3. Root runs A2f for both. Any later failure writes `FAILED` with its code, logs nothing, cleans up nothing and exits 1. Root runs R1-R4 with `--cause A3` | +| A4 | `case2-unit.sh` with `case1-unit.args` and `--copy ID`, `systemctl daemon-reload`, `systemctl start` UNITS in order | root | R1-R4 with `--cause A4` | +| A5 | `stack-release.sh confirm ID mosaic-stack --units external --timeout S`. This is `gate` (:522), which polls `gate_once` (:471) every second until `--timeout`, with the external checks below. On a pass it writes the pointer, logs `result ok`, removes `AWAITING-UNITS`, exit 0. When the timeout runs out it writes `FAILED` with the last gate code, logs nothing and exits 1 | `mosaic` | R1-R4 with `--cause A5` | + +Why A3 writes the marker first and does no cleanup of its own. With the marker written last, as in r4, +an A3 failure after `started` left an open activation with no marker, and R2 and R4 refused it. With +the marker first, every A3 failure after the marker leaves exactly what R2 needs: the open activation, +its marker and whatever part of the rollback set exists. R2 is then the one cleanup path, for A3, A4 +and A5 alike. Two cleanup paths, A3's own and R2, would each need their own tests for each failure point. + +A2f, a stop that fails or times out, or an A3 that exits 3. This run has no open activation: A2 logs nothing, and +A3's exit 3 comes either before `started` or after its own `refused` line. Nothing of `mosaic`'s has +changed. Root reads `date -u +%s` as T, runs `systemctl start` UNITS in order, then `stack-release.sh gate +OLD mosaic-stack --units external --since T --timeout S`, a new verb that runs `gate` on OLD and writes no +log line, no pointer and no file. A2f has no `started` line to take a start floor from (the first +re-pin after adopt has none at all), so `--since` is the floor, and `gate` refuses `usage` without it +(r5's N2). T is root's own clock, so root still parses nothing `mosaic` wrote. A unit that never +stopped keeps its old `ActiveEnterTimestamp`, fails `stale-start` and takes the exit 2 path below. +If that passes, root logs `A2 failed, OLD running` (or `A3 refused`) in its step log and exits +1. If it fails, root stops UNITS, logs `OLD gate failed ` and exits 2. The next run's +`interrupted` check finds nothing open either way. + +The external gate. `gate_once` keeps its order and codes, with these changes under `--units external`: + +- `systemctl` without `--user` for `is-active` and `show`. Both work unprivileged against the system + manager. +- This start's time is the bus unit's `ActiveEnterTimestamp`, read with `systemctl show --timestamp=unix + -p ActiveEnterTimestamp`, in place of the `START_MS` that `start_both` (:451) sets on dragon-lin. + It is whole seconds (`@1792540800`), and the `started` line has milliseconds (N4). So the rule + compares seconds: the start passes when its second is at or after the floor of `started`'s second. + A unit that was active across A3 can't reach this check, because A3 refuses `units-running`, so the + equal second can only be a start after A3. An earlier second fails `gate_once` with the gate code + `stale-start`. It's a gate failure like any other, not a refusal (r4 had it as a refusal, which + would have logged against the open activation): `gate` keeps polling, since `Restart=on-failure` + can bring a fresh start, and at the timeout `FAILED` holds `stale-start`. The PM check's + `startedAt` bound uses the same second. +- `copy-check` runs `stack-copy.sh check --units external`, which reads the system units. +- The PM check is below. + +The PM (r4's B2). .53 runs the PM: the factory's PM dispatches its work, as it does on dragon-lin, and the +serve flags carry `--pm`. The pointer's `pm` comes from the installed bus unit's `ExecStart=`, as the +unit parse at :195 already reads it. Today's `pm_launched` (:505) takes the run id from the +`launched ...` line in `journalctl --user -u BUS_UNIT`. On .53 that read fails twice over: the unit is +a system unit, and under `SplitMode=uid` the logs of a system-range uid land in the system journal, +which `mosaic` (no `adm` or `systemd-journal` group) can't read. Under `--units external` the check +reads `launches list --json` alone. It passes when exactly one entry has business `mosaic-stack`, +instance equal to the business file's `launch.by` (the PM's instance, the one `bus start --pm` launches +at `packages/cli/src/launcher.mjs:675`), `live` true, and `startedAt` at or after this start's time. +Zero entries, two, a stale one or one for another business fail with `pm-launch-unconfirmed` and what +it saw, as today. A run the PM starts for another role has another instance, so it doesn't count. + +Why not the other reads. A regular uid for `mosaic` would put its logs in a per-user journal it can +read, but it changes the account Case 2's install creates. Root reading the journal and passing the run id in +would make root parse output from `mosaic`'s process, which section 4's rule forbids. + +Under `--units external`, `pm-on` (:1137) and `activate --pm-after-harness` refuse `external-pm`. Both +flip the PM on dragon-lin by restarting the user bus with new arguments. On .53 the PM's state is a +serve flag in a root-owned unit, so changing it is a re-install with its own go. + +### Rollback inside the run (R1-R4) + +| # | Step | Runner | On failure | +|---|---|---|---| +| R1 | `systemctl stop` UNITS, then wait as in A2 | root | rollback-failed | +| R2 | `stack-release.sh revert ID mosaic-stack --units external`. It finds the open activation as above, puts the wrapper back from the rollback set and checks its sha256, and restores TAKEN (`restore_store`, :396) only if the rollback set holds `MIGRATING`. Each part is idempotent, so it works for an A3 that stopped partway: no `MIGRATING` means no restore, a migrate that failed partway is restored from the backup taken before it, and copying the saved wrapper over an unchanged one changes nothing. It writes no log line | `mosaic` | rollback-failed, activation left open | +| R3 | `case2-unit.sh` with `case1-unit.args` and `--copy OLD`, `systemctl daemon-reload`, `systemctl start` UNITS | root | rollback-failed, activation left open | +| R4 | `stack-release.sh confirm ID mosaic-stack --units external --rollback OLD --cause A3\|A4\|A5 --timeout S`. It finds the open activation, checks OLD is its `from`, gates OLD with `gate`, and writes the activation's one result line from the cause and the `FAILED` code: `failed code rollback ok` (A3, A4), `gate-failed code rollback ok` (A5), or `rollback-failed code rollbackCode ` when OLD's gate fails | `mosaic` | rollback-failed, logged | + +rollback-failed: root stops UNITS and exits 2, as `rollback_failed` (:587) does. When R4's gate fails, +the log has the `rollback-failed` line and the activation is closed. When R1, R2 or R3 fails, no +`mosaic` step writes a result, so the activation stays open with its marker. Root's step log has the +codes, the next activate refuses `interrupted-run` until Jason or Mos settles it (:605), and status +shows it. I chose that over a log-only verb for root to call after an R2 failure: nothing could gate +the old stack at that point, and a closed activation would let the next activate start against a +wrapper and store in an unknown state. Exit codes match `stack-release.sh`: 0 ok, 1 failed with the old +stack running (rolled back, or A2f), 2 rollback-failed with UNITS stopped, 3 refused with nothing +changed. + +### Rollback to the previous copy: `case1-repin.sh rollback --to ID [--restore ACT --events N]` + +The same list with TO in place of ID. The go names TO, from Mos's or Sage's read of `stack-release.sh +status` as `mosaic`. Root passes it. A1's plan, `stack-release.sh rollback mosaic-stack --units external +--to ID --plan --expect-from OLD`, refuses `pointer-differs` as in activate. It also exits 3 unless ID +is `from_log previous` (:162), the previous distinct copy, so a +stale or mistyped go refuses before anything stops. With `--restore`, the plan also refuses unless +`$DATA/backups/stack/ACT` exists. `--to` is a new flag, accepted only with `--units external`; +dragon-lin's rollback keeps reading TO from the log. + +The post-backup event count runs in A1's plan as `mosaic` while the bus still holds the store (the +`heldcount` read, :1074), and again in A3 on the stopped store. A difference refuses +`post-backup-events`, as `run_steps` does (:1013). + +### Migrations (N4) + +`--migrate` under `--units external` runs only inside A3, and A3 refuses `units-running` before it logs +or migrates anything while any of UNITS is active. So a migration never runs against a store a live bus +holds. The test is in section 7. + +### Backup + +A3's `backup_store` is today's. It copies the stopped store into `$DATA/backups/stack/`, so +`rollback --restore ` and row 181's guard find it. As on dragon-lin, the config dir isn't in the +backup, and the credential isn't either. PBS backups of VM 1008 cover the disk (P4). A restore swaps +only `bus/` and leaves `secrets/claude-session.env` in place (N6, in the run sheet). + +The install's adopt (2c') takes no backup. The store holds only what the acceptance wrote, and the first +re-pin's A3 takes the first backup. + +### The log + +Every `mosaic` line goes to `$DATA/state/stack-activation-log.jsonl`, as today, with `units external` +added. So `from_log previous` reads .53's history the same way it reads dragon-lin's. A3 writes +`started`. A5 or R4 writes the one result line, with the op, from, to and backup of that activation, +or A3 its `refused` line before any change. Refusals of +`confirm`, `revert` and `gate` log no activation id. If a run dies between `started` and the result, +the log keeps `started` with no result, the next run's `interrupted` check reports it, and root's step +log shows the last step that ran. + +### Who + +Mos or Sage plans each re-pin. ops-01 runs `case1-repin.sh` on Jason's or Mos's go, and a STATE report +follows. The gate and the in-run rollback have one owner, the root command, as they do on dragon-lin. + +### dragon-lin's path + +`--units external` is a new value. Without it, `stack-release.sh` and `stack-copy.sh check` run as they +do today, `pm_launched` still reads the user journal, and rollback still takes TO from the log. +`confirm`, `revert`, `gate` and `--to` refuse without it. Section 7 names the tests that show this. + +### Not taken + +- Row 190's user units under `mosaic`, with root running `loginctl enable-linger mosaic` once. Every + existing re-pin tool would work unchanged and root would be needed only once. But the unit form + would differ from Case 2, and a user manager would run as `mosaic`. +- A sudoers rule that lets `mosaic` start and stop the units. P1 and row 230's precheck require that + `mosaic` has no sudo. +- `confirm` and `revert` taking ACT from root. Root would have to read it from `mosaic`'s output or + log, which the rule above forbids (r4's B1). + +## 5. Acceptance checks + +A new script, `scripts/case1-accept.sh`, in this row's manifest. It runs on .53 as `localadmin` and prints +one line per check: ` `. The marks are `closed`, `accepted Q182`, +`accepted Q183`, `accepted mos-1096`, and `unnamed`, which means "not named in Q182, Q183 or a Mos +ruling". The script ends with a count of each mark. It exits non-zero only when a functional check (F) +fails. A P check never changes the exit status. Each `unnamed` line goes to Mos, who takes it to Jason +(R8 N1). + +Functional checks. Any failure fails the row: + +| Id | Check | How | +|---|---|---| +| F1 | the units run as `mosaic` | `systemctl show -p User -p MainPID` for each of UNITS; each MainPID's uid in `/proc//status` is `mosaic`'s, and each unit is active | +| F2 | the Console listens on 127.0.0.1:732 on .53 and answers there | `curl -fsS http://127.0.0.1:732/healthz` on .53 succeeds, and the listener table shows 732 bound to 127.0.0.1 only, by the Console unit's MainPID. Jason reaches it with `ssh -L 7332:127.0.0.1:732 localadmin@10.1.1.53` and his browser at 127.0.0.1:7332 as today. A LAN listener waits for Q175 SSO (sage-1451 Q3) | +| F3 | one tester message gets a reply | as `mosaic`: `mosaic talk chief --tester`, then `mosaic follow --tester`, with a 300 s limit. A stored reply to the marked message passes. The inbox alone shows decisions only, so it isn't used (N3) | +| F4 | the precheck passes | `case2-precheck.sh --profile factory` exits 0 as `mosaic` | +| F5 | a role session runs under bwrap with the profile | while F3's reply is pending: a `/usr/bin/bwrap` process owned by `mosaic` has a claude process under it. `/proc//attr/current` equals `bwrap (enforce)` and the claude process's equals `bwrap//&unpriv_bwrap (enforce)`, each compared as an exact string after the trailing newline is cut (N1). If `launches list --json` records the sandbox, the build reads that for the first part, since a short session can end before `ps` sees it | +| F6 | claude is the pinned version | `/srv/mosaic/.local/bin/claude --version` as `mosaic`, after F3, equals the run sheet's pin | +| F7 | the PM run is live | `launches list --json` as `mosaic` has exactly one live entry for the PM's instance, the check `confirm` runs (section 4) | + +Privilege and host paths. These report and never fail the row: + +| Id | Path | Mark | Evidence the script prints | +|---|---|---|---| +| P1 | `mosaic` has sudo | closed only when `sudo -l -U mosaic` prints "is not allowed to run sudo" (N2); any other output is unnamed | the `sudo -l` result | +| P2 | `mosaic` has supplementary groups or a key | closed when `id -G mosaic` is one entry and `~mosaic/.ssh/authorized_keys` is absent or empty | `id`, file state | +| P3 | `localadmin` NOPASSWD sudo, reached with the dragon-lin key | accepted Q183 (agents keep ssh to .53; localadmin from #423 step 1) | `sudo -l -U localadmin` | +| P4 | root on pve over VM 1008, and PBS backups of VM 1008, which hold `/srv/mosaic` including the credential | accepted Q182 and Q183 (agents keep root on pve and PBS) | a fixed line; the script can't see pve from inside | +| P5 | `jarvis`, which runs Hermes, can reach `/srv/mosaic` through sudo, or through the docker or lxd groups, which are root-equivalent | closed when `jarvis` is in none of sudo, docker and lxd; unnamed otherwise. #423 step 4 lands before the install (mos-1091 4c), and its `step4.sh` removes `jarvis` from sudo, docker, lxd and adm, so after it this reads closed (Duckworth N2) | `id jarvis` | +| P6 | other members of sudo, docker, lxd | closed when sudo holds only `localadmin` and docker and lxd are empty. Every other member is its own unnamed line, `jarvis` included (N1) | `getent group` lines | +| P7 | a file under `/etc/sudoers.d` naming `mosaic` | closed when none | the file names | +| P8 | the Console or tester reachable from the LAN | closed when 732 and 7333 are bound to 127.0.0.1 only, each by the Console's MainPID, and nothing listens on 7331 | listener table | +| P9 | a user namespace through `/usr/bin/bwrap` | accepted mos-1096 only while all seven hold, unnamed otherwise: (1) `dpkg-statoverride --list /usr/bin/bwrap` reads `root mosaic 0750`; (2) `aa-status --json` lists `bwrap` and `unpriv_bwrap` in enforce mode; (3) `/etc/apparmor.d/bwrap-userns-restrict` has the pinned sha256 and no package owns it; (4) `sudo -u jarvis /usr/bin/bwrap --version` fails with "Permission denied"; (5) `getent group mosaic` lists no member and no other account in `/etc/passwd` has its gid; (6) `fs.protected_hardlinks` is 1; (7) no `mosaic-bwrap` profile is loaded, no other file under `/etc/apparmor.d` names `bwrap`, and the live label of a process bwrap runs is exactly `bwrap//&unpriv_bwrap (enforce)` (N1, mos-1098 point 2). Items 1-3, 6 and 7 are `case1-hostcheck.sh --check`'s, so P9 reuses its lines | each item's line, and Mos's reason: "Case 1's agents are the factory's agents. In Q182 and Q183 Jason accepted that the factory reaches root on pve and, through it, every VM. So a user-namespace path to root on .53 gives that class no new reach." With the profile, what's left is bwrap's own setup, run by `mosaic` | +| P10 | a session binds the tester port, 7333, while the Console is down | accepted mos-1101 while `ip_unprivileged_port_start` is above 732 and 7333 is held by the Console's MainPID at the check. Serve refuses a tester port below 1024 (`cli.mjs:33`), so the Console-port fix can't cover it. A squatter would get the tester's writes and could answer them. The tester's users are the factory's agents, the class Mos's reading covers (mos-1101 item 5). Mos can object, and then this line reads unnamed | the floor, and the owner pid of 7333 | + +Tests, in `packages/cli/tests/case1-accept.test.mjs`. The script takes a fake root (`--root DIR`) for +`/proc`, `/etc` and `getent` output, and fake `systemctl`, `curl`, `ss`, `sudo`, `bwrap`, `aa-status`, +`dpkg-statoverride`, `sysctl` and `claude` on PATH. Cases: +- each F check failing gives a non-zero exit with its line; +- each P check in each of its marks, including P1 with output that grants nothing but lacks the refusal + text (unnamed), P9 unnamed once for each of its seven items missing, and P10 unnamed with a floor of + 700 and with 7333 held by another pid; +- F5 fails on a label of `unpriv_bwrap (enforce)`, `bwrap//&unpriv_bwrap (complain)` and + `bwrap (enforce)` with a trailing space; +- a run with every P check `unnamed` still exits 0; +- the summary counts match the lines. + +Mutants: one per F check (the check made to pass on failure), one that maps P5 to `closed`, one that +closes P1 on any output without a rule line, one that drops P9's jarvis item, one that drops P9's item +7, and one that makes F5 a substring match. + +Nothing in the tests reaches .53 or dragon-lin's live state. + +## 6. Rulings + +sage-1451: + +- Q1, unit form: the brief's system unit. C2-13's `ExecStart=` check accepts a varying copy id, and + C2-13 took that (gosalyn-0034 item 3). +- Q3, the Console: it listens on 127.0.0.1 on .53 (`packages/webui/src/serve.mjs:466`; `cli.mjs` passes no + host), and Jason reaches it with `ssh -L`. F2 says so. A LAN listener waits for Q175 SSO. +- Q4, the date: if C2-13's candidate is late, I build on C2-13's latest commit and rebase (Q177). Under + the #426(a) push rules (mos-1086) a rebase goes to a new branch name. + +mos-1091 (none goes to Jason): + +- Q2 4a: installing bubblewrap is an install step, run by ops-01 as root under R27. Rollback is + `apt-get remove`. +- Q2 4b: a per-binary AppArmor profile for `/usr/bin/bwrap`, the sysctl left at 1. r4 takes Ubuntu's + `bwrap-userns-restrict` for it (mos-1096). Section 1 has the steps. +- 4c: P5 ends at #423 step 4, which Mos sent to Duckworth so it lands in Jason's VM 1008 boot session, + before the install. The P5 check stays. + +mos-1096: + +- B1 and B2 are mine, and so is the PM answer: .53 runs the PM (section 4). +- The `dpkg-statoverride` on `/usr/bin/bwrap`, the hardlink and group checks, the jarvis refusal and F5 + under the profile (sections 1 and 5). +- P9 is Mos's acceptance, with the reason quoted in section 5. +- Jason's Q9 on install and upgrade is open. r4 goes ahead, since B1's re-pin and rollback are needed + whatever he answers. If his answer changes how upgrades reach .53, the change lands in section 4 and + the run sheet as a new round. + +mos-1098 and mos-1101 (on Duckworth's REVIEW-r3): + +- Duckworth's CHANGES stand. B1 and B2 are fixed in this round, with B1's real-sequence test, and all + three of B2's asks: an owner across upgrades, what fails closed, and the pins as reviewed values. +- r4's PM, statoverride and P9 stand. mos-1098's two questions are answered in section 1: the profile's + owner across upgrades is ops-01 with `case1-hostcheck.sh`, and the stop is bwrap closed to `mosaic`. + Both profiles attach to `/usr/bin/bwrap`: `bwrap` to the binary and `unpriv_bwrap` stacked on what it + runs. P9 item 7 checks that no third one does. +- P9 has seven items and F5 compares exact strings (N1). +- The port squat applies (section 1). The Console takes Case 2's fix, a port below 1024 with + `CAP_NET_BIND_SERVICE` and the floor checked. Only the tester port can't take it, and P10 records it + under Mos's reading that Case 1's sessions are the factory class. I've told Mos, who can object. +- Work on r5 goes ahead while Jason's Q9 (Vikunja #429) is open. If install and upgrade become + product commands, these steps become that installer's configuration and row 195 rebases on its row + (sage-1481, sage-1491). + +sage-1499: C2-13a is row 230 (#1732, Gosalyn), and row 195 chains on row 230's candidate. + +gosalyn-0049: the factory profile is the library set plus an optional `--tester-port`, and row 195 names +any other difference. Section 2 names four, with the reason .53 can't meet the preview trio, `--send` or +the proof pair. The managed-settings route needs no Case 2 change. + +## 7. Manifest (planned) + +- `scripts/case1-repin.sh` (new) and `packages/cli/tests/case1-repin.test.mjs` (new). Fake `systemctl`, + `sudo` and `case2-unit.sh` on PATH record their argv, with a scratch home standing in for `/srv/mosaic`, + a scratch dir for `/etc/mosaic-stack` and one for `/var/log/mosaic-stack`. Cases: + - a pass runs A1-A5 in order; + - a failure at A3, A4 or A5 runs R1-R4 with `--cause` set to that step, and exits 1; + - an A3 exit 3 runs A2f, not R1-R4; + - a failure at R2 or R4 exits 2 with UNITS stopped; + - A1 refuses `profile-drift` when a fake `case1-hostcheck.sh --check` exits 1, before any stop; + - every `mosaic` step's argv carries `env PATH=:/usr/local/bin:/usr/bin:/bin`, with the node + dir from `case1-unit.args`; + - a HEAD mismatch, an ID that fails the copy-id rule, or unit files that name two copies refuses with + exit 3 before any stop; + - A1's plan argv carries `--expect-from` with OLD from the unit files; + - A2f passes `gate OLD --since T`, with T from a fake `date` that root calls before its start; + - A2f: a fake `systemctl` that never reports inactive. The script starts UNITS, runs `gate OLD`, exits + 1 with OLD's gate passing and 2 with it failing, and the stack log is byte-identical before and + after; + - `rollback --to` with an ID that isn't `from_log previous` exits 3 before any stop; + - every exec of a path under the home goes through `sudo -u mosaic -H` (from the recorded argv); + - no argv root passes holds an activation id, and OLD comes from the unit files, not from anything + the `mosaic` steps print; + - every `case2-unit.sh` call carries the arguments in `case1-unit.args` and differs only in `--copy`; + - the step log has one line per step with its exit code. +- `scripts/stack-release.sh`: `--units external` for `adopt`, `activate`, `rollback` and `status`, the + `--to` flag for an external rollback, and the new `confirm`, `revert` and `gate` verbs, which refuse + without it. `scripts/stack-copy.sh`: `check --units external`, which reads the system units. Tests in + `packages/cli/tests/stack-release-external.test.mjs` (new), against a fake system-scope `systemctl` + and a fake `mosaic` for `bus status` and `launches list`: + - `units-running` refuses while any unit is active, and `activate --migrate` with a unit active + leaves the store, the log and TAKEN as they were (N4); + - activate leaves the pointer as it was, writes `AWAITING-UNITS`, and writes a backup of the stopped + store under `$DATA/backups/stack/`; + - `confirm` and `revert` refuse `open-activation` with zero `AWAITING-UNITS` files, with two, with + one whose copy isn't the one passed, and with one whose activation isn't in the `interrupted` set; + - `confirm` polls: a fake bus whose status turns good after 3 s passes with `--timeout 10` and fails + with `--timeout 1`; + - `stale-start` (N4): with `started` at 1792540800.900, an `ActiveEnterTimestamp` of `@1792540800` + passes and `@1792540799` fails `gate_once` with `stale-start`. A fake that turns to `@1792540805` + after 2 s passes with `--timeout 10`, which shows it's a gate code that polling can clear, not a + refusal; + - `confirm` on a pass writes the pointer, logs `ok` and removes `AWAITING-UNITS`. On a timeout it + writes `FAILED` with the gate code, leaves the pointer, the log and the marker as they were, and + exits 1; + - `confirm` without `--rollback` refuses `activation-failed` when `FAILED` exists; + - every line `confirm` writes has op `activate` or `rollback`, never `confirm`, and the from, to and + activation of its `started` line, and backup equal to the rollback set's `BACKUP`; + - `gate` (N2): with `--since 1792540800`, `@1792540800` passes and `@1792540799` fails `stale-start`; + without `--since` it refuses `usage`; + - `--plan --expect-from` (N5) refuses `pointer-differs` when the pointer names another copy, for + activate and for `rollback --to`; + - A3's order: a fake that fails the capture leaves the log with `started` and `refused code + capture-failed` for that activation, no marker and no `FAILED`, and exit 3. An existing `$RS` + gives `refused code marker-failed` and exit 3, and a capture under `--units external` makes no + directory of its own. A fake that fails the + wrapper install after a migration leaves `started` only, the marker, `FAILED`, TAKEN as migrated, + and exit 1; + - refusals by `confirm`, `revert` and `gate` log with no activation id, and the `interrupted` set + is the same before and after each one; + - the PM check passes with one live entry for the PM's instance since the start, and fails + `pm-launch-unconfirmed` with none, with two, with one whose `startedAt` is before the start, with one + not live, and with one for another business. A second live entry for another instance doesn't + count. A fake `journalctl` on PATH records any call, and no external run makes one; + - `pm-on` and `activate --pm-after-harness` refuse `external-pm`; + - `revert` puts the wrapper back, and restores TAKEN only after a migration; + - `confirm --rollback OLD` writes the line for each `--cause` (A3 and A4 `failed`, A5 `gate-failed`, + with the `FAILED` code, `units-start` for A4, `unrecorded` when the file is missing), or + `rollback-failed` when OLD's gate fails. It removes the marker and `FAILED` after the line, and + refuses when OLD isn't the open activation's `from`; + - real sequences on one log (B1). The fake `sudo` execs the real `stack-release.sh` as the test's + user, so each step reads the log and state the last one wrote. Fakes stand in only for + `systemctl`, `mosaic` and `case2-unit.sh`. Each sequence ends with the log holding exactly one + `started` and one result line for its activation, an empty `interrupted` set, no marker or + `FAILED`, and a following `activate --plan` that doesn't refuse `interrupted-run`: + 1. activate, confirm times out, revert, `confirm --rollback --cause A5` passes: + `gate-failed code rollback ok`; + 2. activate with `--migrate`, the wrapper install fails, revert restores TAKEN, `confirm --rollback + --cause A3`: `failed code rollback ok`; + 3. activate, root's A4 fails, revert, `confirm --rollback --cause A4`: `failed code units-start + rollback ok`; + 4. activate whose capture fails: `refused code capture-failed` and nothing open, then A2f's + `gate OLD` writes nothing; + 5. activate, then `confirm` with the wrong copy is refused, then revert and `confirm --rollback + --cause A5` still close the activation, because the refusal didn't; + 6. activate, revert fails (a wrapper whose saved copy is missing): the activation stays open, and + the next `activate --plan` refuses `interrupted-run`; + 7. adopt C0, activate C1 and confirm, activate C2 and confirm (r5's B1): both `ok` lines read + `op activate` with their `started` line's from and to and the backup each took. `rollback --to C1 + --plan` exits 0 and `--to C0 --plan` refuses. A rollback to C1, confirmed, logs `op rollback`, and + `from_log previous` then names C2; + 8. activate with `--migrate`, where the copy's `migrate-schema.mjs` is a fake that writes to the + store and exits 1 (r5's B2): `FAILED` holds `migrate-failed` and `MIGRATING` exists. revert + restores the store byte-identical to the backup, and `confirm --rollback --cause A3` gates OLD on + it: `failed code migrate-failed rollback ok`; + - `rollback --to` refuses when ID isn't `from_log previous`, and `rollback --restore` finds a backup + that an external activate took; + - `gate` writes nothing: the log, the pointer and the state dir are byte-identical before and after; + - `confirm`, `revert`, `gate` and `--to` refuse without `--units external`. +- dragon-lin unchanged. `stack-release.test.mjs` and `stack-copy.test.mjs` run unchanged and green. A + new case in `stack-release-external.test.mjs` runs a default activate, rollback and check against a + fake `systemctl` that records argv, and every call carries `--user`. A default `activate --plan` + prints the same bytes on the candidate as on its base, with the base output as a fixture. +- Mutants for the re-pin: + - `confirm` writes the pointer on a gate failure; + - `confirm` calls `gate_once` once in place of `gate`; + - the external PM check counts entries of any instance; + - the external PM check drops the `startedAt` bound; + - `confirm` takes the newest `AWAITING-UNITS` instead of refusing two; + - `rollback --to` skips the `from_log previous` comparison; + - `case1-repin.sh` skips R1-R4; + - `case1-repin.sh` exits 0 after A2f; + - `case1-repin.sh` runs `mosaic`'s `stack-release.sh` without `sudo -u mosaic`; + - the default path drops `--user` from one `systemctl` call; + - `confirm`'s timeout writes r4's interim `gate-failed ... rollback pending` line (B1; killed by + sequences 1 and 5); + - A3 writes `AWAITING-UNITS` last, after the wrapper (killed by sequence 2); + - an external verb's refusal logs with the open activation id (ACT set before the checks; killed by + sequence 5 and the refusal test); + - `stale-start` is a refusal again (killed by the polling case); + - `revert` restores TAKEN without `MIGRATING` (killed by the revert case); + - `confirm` logs with its own op, `confirm` (killed by sequence 7 and the op case); + - A3 writes `MIGRATING` after `migrate-schema.mjs` (killed by sequence 8); + - `gate` takes its floor from the newest `started` line when `--since` is missing (killed by the + `gate` case). +- `scripts/case1-pins.sh` and `scripts/case1-hostcheck.sh` (new), + `packages/cli/systemd/mosaic-hostcheck.service` (new) and `packages/cli/tests/case1-hostcheck.test.mjs` + (new). The script takes `--root DIR` for `/etc`, `/proc/sys` and `/usr/bin/bwrap`'s stat, and fake + `aa-status`, `dpkg`, `dpkg-statoverride`, `apparmor_parser`, `systemd-run`, `chown` and `chmod` + on PATH record their argv. Cases: + - `--check` exits 0 with all seven items and 1 with each one failing alone, its line naming it; + item 3 fails on a second file naming `bwrap` as a word, one that writes `/{usr/,}bin/bwrap` included, + and passes with `bwrap-userns-restrict` alone. Item 4 fails on a label of `unpriv_bwrap (enforce)` + or one with a trailing space, and its `systemd-run` argv carries `-p NoNewPrivileges=yes` and the + other 2a' properties. Item 7 fails with the floor at 732; + - `--enforce` exits 0 on a pass and on every failure. On a failure it unloads the profile, closes + bwrap to `root:root` 0700, writes `DRIFT` and one log line. With `DRIFT` present and every item + passing, it still closes bwrap; + - `--enforce` never calls `dpkg-statoverride` with `--update`, `--add` or `--remove`; + - a bubblewrap version other than the install pin is a printed line, not a failure; + - `--upstream` against a fake deb whose file differs prints the difference and exits 0; + - the service unit has `Type=oneshot`, `After=apparmor.service`, + `Before=mosaic-bus@mosaic-stack.service` and runs `--enforce`. + + Mutants: `--enforce` exits 1 on a drift; `--enforce` ignores `DRIFT` when the items pass; item 1 + drops the `dpkg -S` owner check; item 3 matches only the `/usr/bin/bwrap` path; item 4 matches a + substring; item 4 drops `-p NoNewPrivileges=yes`; item 7 compares with `>=`. +- `scripts/case1-accept.sh` (new) and `packages/cli/tests/case1-accept.test.mjs` (new), section 5. +- Row 230 (C2-13a). `--profile`, the node, bwrap and port-floor precheck lines, the copy-id rule, the + two units and the Console's capability lines are in its brief at 5b8def2f1. Section 2's four items + are not. Any of them that row 230's candidate lacks becomes a named change here, reviewed by + Duckworth with Webby told. I told Gosalyn earlier that the settings-file route for + `DISABLE_AUTOUPDATER` doesn't reach a role session, and that Case 1 uses the managed settings file. +- Docs: the Case 1 run sheet `docs/guides/case1-install.md` (new). It lists the window's steps in order, + each with who runs it and its go, the pinned node sha256 and claude version, a pointer to + `case1-pins.sh` for the bubblewrap and profile pins, the statoverride, the drift stop and the managed + settings file, each with its rollback, how ops-01 clears a `DRIFT`, the `ssh -L` line for port 732, + and a note that a restore leaves the credential in place. +- No change to `~/.mosaic-dev`, `~/.config/mosaic-dev`, dragon-lin's units or `~/.mosaic`.