Files
mesh-catalog/modules/mesh-config/README.md
T
mesh-tools 652b00b25b
mesh/merge-gate checking again: the gate refused `unknown` because the controller judged with a node-engine validator pinned before mesh-host #117; mesh-co…
mesh/repo-check checking again: the gate refused `unknown` because the controller judged with a node-engine validator pinned before mesh-host #117; mesh-co…
mesh/delivery-group group feat/owned-paths checking: 0 of 2 member(s) ready
mesh/delivery superseded: a newer head of the same pull request
Say on every directory how it treats files it does not know, and check it (issue 1024, ADR 0422)
Every directory and archive resource carries `unknown`: move-out for a home folder whose program writes nothing there (the node-engine, delivered in mesh-host #117, moves the rest to ~/.local/state/mesh-moved/<module>/ with a list), module for ~/.ssh and ~/.claude, program elsewhere; `knows` keeps what a program or the operator relies on (powerlevel10k's compiled files, i3's scripts and the asus/g14 drop-ins, dunst's slack rule, betterbird's records, node-env's forge credential, issue 1033). Two shared folders are no longer declared. Each module's README says it. checks/owned holds every manifest to it; checks/sshdir stays while main's merge check runs it (issue 1035). Tests that pin a manifest follow the new key only. Reviewed in three rounds.
2026-10-17 16:23:03 +00:00

4.2 KiB

mesh-config

Holds the mesh-config seat: the owner of every config value (novox/hq ADR 0348 §9, design 57 K3). Go, one binary (cmd/mesh-config), served by a runtime of its own on its own bus account (runs-as), so that its account alone writes its buckets.

What it keeps

  • mesh-config_values: each value set, keyed by its level: mesh.<key> (mesh config), node.<node>.<key> (node config) and module.<node>.<module>.<key> (a module's own value on one node), each with who set it, through which account, why and when.
  • mesh-config_resolved: each assigned module's value for each key it declares on its node, keyed <node>.<module>.<key>, with its source: default, mesh, node, module, or unset for a required value nothing sets.
  • mesh-config_predefined: the list of predefined keys, published from the list the controller kept (its mirror mesh-controller.predefined), the newest trunk build winning. A newer list dropping a key that still holds a value at the mesh or a node is withheld, and every listing says why, until that value is cleared.
  • mesh-config_proposals: each value proposed for the operator's Approve, whole, with the value stored at its level when it was proposed (what the operator is shown the change against), who proposed it, why, and what came of it.
  • the log history: every set, clear and move of resolved values, with the proven caller and why.

How a value resolves

From the controller's mirrors of the assignments and of each module's declarations (mesh-controller.assignments, mesh-controller.declared-config): the manifest's default; mesh config for the predefined key the value falls back to; node config for that key on the node; the module's own value on that node, the most specific winning. A value naming no predefined key resolves from its default and the module's own value only (ADR 0348 §2). It resolves at start, whenever a mirror moves, and every five minutes, writing only the values that moved.

The verb

mesh-config.config with action list (the default), set, clear or history, narrowed by module, node and key. A set or a clear names one level (no module and no node for mesh config, a node for node config, both for a module's own value), needs why, refuses a key the module or the predefined list does not declare (naming the declared keys), validates the value, writes it and the resolved values it moves, keeps it in the history and the controller's hand-act log, raises config-changed, and answers with each module on each node whose value moved. It opens no walk. A trusted value is taken only from the controller, which carries it from its terminal and names who gave it in by, or on the operator's Approve of a proposal.

Proposing a value (ADR 0348 §8, design 57 K4)

action propose (with value, or clear) judges the value as a set would, keeps it in mesh-config_proposals, and asks the operator under mesh-config's own name on the operator-channel seat (its own grant, from uses, and its own cap of three open asks; the same change twice is refused, and a newer proposal for the same level and key replaces the older). The ask says the level, the key and the value, exact where who answers is proven, and that, approved, it takes effect at once on every node it reaches; Approve and Decline are both at the level approve and each binds the proposal's level, key, value and the value it was shown against. On the answer mesh-config reads the router's own record of its ask and holds the warrant to the ask composed again from the proposal; it refuses, and sets nothing, when the proposal or the value stored at the level changed since. An Approve that holds sets the value as a set does, keeps who approved it beside the value (approved), and asks the controller to record the warrant in its hand-act log. A Decline, an expiry or the router's refusal sets nothing. action proposals lists them, newest first; with proposal, one read whole, with whether the router's ask is the one composed from it.

Files it does not know

Each directory or archive this module declares says how it treats a file it did not write (ADR 0422, ADR 0416).

  • ${dir:state}: everything in it is the program's; the mesh moves nothing out (ADR 0422 §2).