Research 018: the operator's machine as modules #291

2026-10-02T13:19:44Z

mesh-admin commented

2026-10-02 13:19:44 +00:00

Opens research effort 018 — The operator's machine as modules (playbook 01). Four documents, no design or decision written.

Why now. The predecessor is retired on every node. What it still owned on the two workstations — some thirty modules of dotfiles, user units and /etc files — is owned by nothing; a fix is a hand edit nothing records. To-be 29 covers one directory under the home and draws a boundary inside it. The operator wants no boundary: the whole machine as modules, system folders and home alike, and the same catalogue serving the servers.

What the documents hold.

01 — The intended behaviour, in the mesh's words: one module per managed thing with no module kinds (any module may serve tools); one default configuration, varied per node only by a declared setting rendered into the file or a kept operator region (ADR 0011 stands, the predecessor's drift-adoption does not return); roles a machine has once as node-scoped seats with tool contracts (login shell → execute(command), boot → rebuild-images, service manager → the units); the graphical stack gated by the graphical-session capability.
02 — What exists, and what is missing: the predecessor's desktop measured (34 modules; the desktop module alone 88 files, 4 flavors, 2 user units, ~90 theme variables; one-off steps in hooks), what the migration did with them, which records already say what is wanted, and the seven gaps — the account is empty on all four node records, no user-scoped units, one-off steps, settings leak (issue 168), tools in a container per module per node, undecided seat verbs, catalogue placement.
03 — One tool executor per node: the direction the operator set. Evidence: the packet-filter holder is a container per node on all four nodes to serve three verbs; 67 module tools each from their own container. Direction: one host-side, module-agnostic executor per node loading every assigned module's tool bundle and serving the membership's subjects; never in a container; root is the module's concern; any node calls any tool; the console is the executor renamed and moved out of its container. Supersedes 0047/0150 for tools, keeps 0152 in substance, amends to-be 33 §6 and 34, makes 0170 §3 moot. Open: the executor's language, how a bundle reaches the node, reload on push.
04 — The seats of the environment: fifteen candidate node-scoped seats with holders, gate and first verbs; what is a module but not a seat; why the shell comes first and the login manager is the first system-scope one.

Relation to open changes. Rests on the account and home-ownership records proposed in #286 and the settings record proposed in #271 — cited by title, not number, since both are unmerged. The container-runtime seat's "holder runs as a supervised process" is consistent with the executor; whether that holder serves through it is left open.

records.py, index.py, cycle.py pass; every link resolves; no node names, paths or domains.

Opens research effort **018 — The operator's machine as modules** (playbook 01). Four documents, no design or decision written. **Why now.** The predecessor is retired on every node. What it still owned on the two workstations — some thirty modules of dotfiles, user units and `/etc` files — is owned by nothing; a fix is a hand edit nothing records. To-be 29 covers one directory under the home and draws a boundary inside it. The operator wants no boundary: the whole machine as modules, system folders and home alike, and the same catalogue serving the servers. **What the documents hold.** - **01 — The intended behaviour**, in the mesh's words: one module per managed thing with no module kinds (any module may serve tools); one default configuration, varied per node only by a declared setting rendered into the file or a kept operator region (ADR 0011 stands, the predecessor's drift-adoption does not return); roles a machine has once as node-scoped seats with tool contracts (login shell → `execute(command)`, boot → `rebuild-images`, service manager → the units); the graphical stack gated by the `graphical-session` capability. - **02 — What exists, and what is missing**: the predecessor's desktop measured (34 modules; the desktop module alone 88 files, 4 flavors, 2 user units, ~90 theme variables; one-off steps in hooks), what the migration did with them, which records already say what is wanted, and the seven gaps — the account is empty on all four node records, no user-scoped units, one-off steps, settings leak (issue 168), tools in a container per module per node, undecided seat verbs, catalogue placement. - **03 — One tool executor per node**: the direction the operator set. Evidence: the packet-filter holder is a container per node on all four nodes to serve three verbs; 67 module tools each from their own container. Direction: one host-side, module-agnostic executor per node loading every assigned module's tool bundle and serving the membership's subjects; never in a container; root is the module's concern; any node calls any tool; the console is the executor renamed and moved out of its container. Supersedes 0047/0150 *for tools*, keeps 0152 in substance, amends to-be 33 §6 and 34, makes 0170 §3 moot. Open: the executor's language, how a bundle reaches the node, reload on push. - **04 — The seats of the environment**: fifteen candidate node-scoped seats with holders, gate and first verbs; what is a module but not a seat; why the shell comes first and the login manager is the first system-scope one. **Relation to open changes.** Rests on the account and home-ownership records proposed in #286 and the settings record proposed in #271 — cited by title, not number, since both are unmerged. The container-runtime seat's "holder runs as a supervised process" is consistent with the executor; whether that holder serves through it is left open. `records.py`, `index.py`, `cycle.py` pass; every link resolves; no node names, paths or domains.

mesh-admin added 1 commit 2026-10-02 13:19:45 +00:00

Research 018: the operator's machine as modules 7fb59bde98

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.

mesh-admin merged commit 54213ba90c into main

2026-10-02 14:27:28 +00:00

mesh-admin deleted branch research/018-the-operators-machine

2026-10-02 14:27:29 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#291