To-be 42: the machines' modules, in order — every machine's, then the workstations', then one model's

2026-10-04 12:08:26 +02:00
parent f8a0402485
commit ca13f59c88
2 changed files with 99 additions and 0 deletions
@@ -0,0 +1,98 @@
+---
+layer: to-be
+status: in-progress
+code: [mesh-catalog, mesh-controller, mesh-host]
+updated: 2026-10-04
+decisions:
+  - 02-DECISIONS/0173-the-operators-machine-is-the-meshs-and-a-module-is-what-it-declares.md
+  - 02-DECISIONS/0040-what-a-module-is.md
+  - 02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md
+  - 02-DECISIONS/0175-one-tool-runtime-per-node-serves-every-modules-tools-on-the-host-side.md
+  - 02-DECISIONS/0182-inside-a-home-the-mesh-owns-what-it-places-and-holds-the-rest-as-found.md
+  - 02-DECISIONS/0198-a-modules-long-running-code-is-launched-by-the-node-runtime-and-reaches-the-bus-through-it.md
+  - 02-DECISIONS/0203-the-accounts-environment-is-one-modules-and-every-module-contributes-to-it.md
+  - 02-DECISIONS/0204-a-module-contributes-shell-code-to-the-login-shell-in-named-slots.md
+  - 02-DECISIONS/0205-software-the-distribution-does-not-package-ships-as-a-pinned-archive-of-the-module.md
+---
+
+# 42. The machines' modules, in order
+
+The order in which the modules of [research 026](../../01-RESEARCH/026-the-graphical-session-as-modules/00-overview.md)
+and [research 027](../../01-RESEARCH/027-the-system-layer-as-modules/00-overview.md) are built and rolled
+out, as the operator set it on 2026-10-04.
+
+Three phases, in order, each built from the bottom up (the most core module first):
+
+1. the modules every machine shares;
+2. those both workstations share;
+3. those of one machine model.
+
+The shell came first ([to-be 41](41-the-shell-and-the-accounts-environment.md)). Each module's
+definition, improvements and tools follow the research. A position that needs a new mechanism (a new
+seat, a gated assignment, generalised contributions) gets its record when its first module needs it,
+not before. Modules that need none go ahead now.
+
+## How every module moves
+
+1. Written in the catalogue, with its tools and their tests, and checked by the controller's catalogue
+   check.
+2. Merged, which builds it.
+3. Assigned to **the first workstation, the proving machine**, and pushed. Its tools and files are
+   proven there.
+4. Then assigned to every other machine it applies to, and pushed.
+
+The operator delegated the go-ahead for each step on 2026-10-04 ("non-important decisions, easily
+reversed"). Each step is reported.
+
+**Adopting is also improving** (research 026, 027 overviews): every module lists what it fixes over
+today, and leaves no predecessor copy of what it now owns.
+
+## Phase 1 — every machine
+
+In order:
+
+| | module | owns | improves |
+|---|---|---|---|
+| 1 | `sudo` | the operator account's escalation, as a drop-in it owns | declares what three modules' tools assume and nothing stated |
+| 2 | `localization` | locale, time zone, console keymap | one machine on another zone and keymap |
+| 3 | `time-sync` | timesyncd and its servers | two different daemons across four machines |
+| 4 | `pacman` | the package manager's configuration, mirrors and their refresh, cache cleaning | mirrors generated once and never again; caches never cleaned |
+| 5 | `logrotate` | the timer and base configuration | rotation running on one machine of four |
+| 6 | `avahi` | the daemon | on all four, owned by none |
+| 7 | `systemd` | the service manager's tools (to-be 41 WP4) | built, assigned nowhere |
+| 8 | `docker` | the runtime's packages, base configuration, group | four configurations, one owner on one machine |
+| 9 | `ssh-client` | everything under `~/.ssh` (research 027/03) | a predecessor's entries winning over the mesh's; stale keys |
+| 10 | scripts | the operator's own scripts, shared and per role (research 027/03) | under no version control, copied by hand |
+| 11 | `kernel` | kernel, microcode, boot entries | two machines without microcode |
+
+`kernel` is last because a mistake in it costs a boot. `docker` stays a module without the runtime seat
+until ADRs 0165 and 0166 are accepted.
+
+## Phase 2 — both workstations
+
+In order:
+
+1. `fonts`;
+2. `xorg` with autorandr;
+3. `lemurs`;
+4. `i3`;
+5. `xterm`;
+6. the theme module;
+7. `picom`, `rofi`, `dmenu`, `dunst`, the lock module, `xclip`, the clipboard manager, `feh` and
+   `i3status-rust`;
+8. `gnome-keyring`;
+9. `docker-compose`, `snapd`, `flatpak`, `cups`, `bluetooth`.
+
+The seats, gating and session-start questions of research 026 §2–§5 are recorded when `xorg` and `i3`
+need them.
+
+## Phase 3 — one machine model
+
+The laptop's hardware module (vendor daemon, GPU mode, charge limit, logind, brightness and vendor keys)
+and `memory-pressure` (research 027/03).
+
+## How it is checked
+
+Each module's own tests and the catalogue check, at merge. On the proving machine, each tool answered
+through the mesh and each owned file checked in place, before any other machine is assigned. This
+document's tables are updated as each module lands.