The predecessor is retired on every node and what it still owned on the two workstations — some thirty modules of dotfiles, user units and /etc files — is owned by nothing. To-be 29 covers one directory under the home; the operator wants the whole machine, system folders and home alike, as modules: one default configuration each, varied per node by settings or a kept region, never an edit; roles the machine has once as node-scoped seats with tool contracts; the graphical stack gated by a capability so the same catalogue serves the servers. Four documents: the intended behaviour in the mesh's words; the predecessor's desktop measured (34 modules, one with 88 files, 4 flavors and ~90 theme variables) against what the records already give and what is missing (the account is empty on every node, no user-scoped units, settings leak, tools run in a container per module per node); the direction the operator set for where tools run — one executor per node, host-side, module-agnostic, the console renamed and moved out of its container, superseding 0047/0150 for tools; and the candidate seats of the environment with first verbs, the shell first.
4.5 KiB
04 — The seats of the environment
Candidates, not decisions. To-be 33 says which verbs a seat serves is a decision per seat, taken slowly, because a seat's tools bind every future holder. This document lists the roles the operator's machine has once, who could hold each, what gates it, and a first verb or two — so each record has a starting point.
The rule for what is a seat here
A role the machine fills at most once is a node-scoped seat, declared by the module family that fills it (ADR 0126). A thing several of which coexist without contention — editors, browsers, media players — is not a seat; each is a module with its own tools, and nothing is singular about it. A seat is held by one assignment per node; other modules of the same family may be installed beside it without holding it (ADR 0040 §1, read with the sharper distinction: installed is not holding).
Candidate seats
| seat | holders | gated by | first verbs |
|---|---|---|---|
| login shell | zsh, fish, bash | nothing: universal | execute(command); show-config; the holding itself sets the account's login shell through the host's user shape |
| service manager | systemd | the service-manager capability the profile reports |
units: list, status, start, stop, restart, enable, journal; user scope on each |
| boot | grub, systemd-boot | a machine that boots itself (not a container host) | rebuild-images; entries |
| package manager | pacman, apt | the package-manager capability |
search, installed, upgrade, orphans; today a capability the host uses, not a seat anyone holds |
| display server | xorg, wayland compositors that are their own server | the graphical-session capability |
displays; layout |
| display session | i3, sway | the display server seat held on the node; i3 needs x11, sway needs wayland | reload; workspaces; windows; move |
| terminal emulator | xterm, alacritty, foot | display session | open; font |
| launcher | rofi, dmenu | display session | show; theme |
| notifier | dunst, mako | display session | send; history; rule |
| compositor | picom | display server (x11 only) | restart; effects |
| lock screen | i3lock, swaylock | display session | lock |
| bar | i3status-rust, waybar | display session | reload; blocks |
| login manager | lemurs, greetd | graphical session | sessions; default-session |
| audio | pipewire, pulseaudio | the machine reports a sound device | sinks, sources, default, volume, mute |
| clipboard | greenclip, cliphist | display session | history; clear |
Not seats, modules with their own tools: the editor, the browser, the mail client, the file manager, the media player, the chat client, the agent at the terminal, the downloads folder, the scripts folder, the sync client, the power and thermal daemons that are specific to one machine's hardware.
What the table implies
Capabilities come first. graphical-session, service-manager and package-manager are
reported today. A display server is held is not a capability but a seat being held, and a
module that needs it declares a dependency on the seat, not on a capability: i3 needs the
display server seat held by xorg. Whether a held seat can gate another's assignment is a
question for the controller's resolver, and the first environment module after the shell will
ask it.
The service manager comes early. Four of the predecessor's modules ship user units, and the
executor itself is a unit. User scope on the host's service shape is a host change whichever
module holds the seat; the seat's holder answers the questions about units, it does not apply
them — the host does, as it does for every declared resource.
The shell comes first. Universal, no capability, one verb that is immediately useful on
every node, and the user shape already makes the login shell declared state. It is the module
that proves the pattern: a package, files under the home owned by the account, a seat claim,
tools served by the executor, settings for the few things that vary per node, and a kept region
for the operator's own lines.
The login manager is the first system-scope one, because it needs nothing new: a package,
two files under /etc, a service — the same shape the ssh daemon module has today — and the
session script it owns is the file that was hand-fixed the day this effort opened.