hq/03-DESIGN/01-to-be/42-the-machines-modules-in-order.md

layer, status, code, updated, decisions

layer	status	code	updated	decisions
to-be	in-progress	mesh-catalog mesh-controller mesh-host	2026-10-04	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 02-DECISIONS/0207-a-module-depends-on-the-node-seats-that-apply-its-resources.md 02-DECISIONS/0208-the-graphical-session-is-one-module-per-piece-on-the-meshs-seats.md

42. The machines' modules, in order

The order in which the modules of research 026 and research 027 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). 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

systemd, pacman and docker hold the three seats that apply resources (ADR 0207): every module that declares a service, a package or a container depends on them being held on its node. They go on every machine before the rest, and once they have, an unmet dependency is refused rather than reported.

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, contributions and session start are ADR 0208.

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.