Files
hq/02-DECISIONS/0011-managed-files-are-generated-never-edited.md
jschoubben b4607dfc03 Numbers are identity; the reading order is a generated, checked index
Decided after measuring what renumbering actually costs: 96 references in code
comments across two repositories, none of which would have failed to compile.
They would have pointed at the wrong reasoning, which is worse than a broken
link because nothing reports it.

So a number identifies a record and never changes. It cannot also be a
position -- a position moves when the set changes, and an identity that moves
is not one.

The reading order moves into an index generated from each record's `topic:`.
Six topics, in the order somebody learns the system.

The index is WRITTEN rather than only generated on demand, which reverses what
this repository previously said. The reason it said otherwise is that a
hand-written index drifts -- but a reader looking at the folder on a forge sees
the folder, not a command, and the drift objection is answered by checking
rather than by refusing to write one. That is §5's own rule: a rule states how
it is checked.

Two checks, both confirmed to bite. index.py fails when the written order no
longer matches the records. records.py fails when a record has no topic or one
nobody defined -- the quiet failure being a record that vanishes from the order
rather than appearing in the wrong place.
2026-08-28 23:39:18 +02:00

3.0 KiB

topic, status, date, deciders, reconstructed
topic status date deciders reconstructed
building it accepted 2026-04-03 jochen true

11. Managed files are generated onto nodes and never edited there

Reconstructed after the fact from the evidence cited below.

Context

ADR 0006 put every binding in the mesh database. But the things that consume those bindings — environment files, service definitions, daemon configuration, firewall rules — are files on a node's disk, because that is what the software reading them requires.

So the same value exists twice: authoritatively in the database, and materialised in a file. Any edit to the file is a change to a copy. Before this decision, environment values could be pushed from a node back into the database, which made the direction ambiguous in both directions at once.

Considered options

  1. Bidirectional sync — a node's edits flow back to the database. Rejected, and removed. Two writers and no arbiter: whichever synced last wins, and neither is authority.
  2. Files are authoritative; the database is a cache of them. Rejected — it inverts ADR 0013 and returns to state that cannot be reconciled across nodes.
  3. Strictly one-directional: the database is written, files are generated. Chosen.

Decision

Every managed file is derived. A synchroniser regenerates it from the mesh database whenever the underlying values change. The write path is the mesh tool that owns the value; the file is an output.

This applies to generated environment files, service definitions, managed configuration, and anything else a synchroniser lists as its own.

An edit to a managed file survives until the next synchronisation and is then overwritten, without a warning, taking whatever it was fixing with it.

Consequences

  • A file edited on a node is a bug with a delay on it. This is now one of the mesh's core values, and it is a consequence of this decision rather than a stance taken independently.
  • To change a value you must know which tool owns it. That is a real cost, paid every time, and the reason the mesh provides a way to ask whether a given file is managed.
  • Debugging by editing a file no longer works, and fails in the most confusing way available: it works, and then stops working later for no locally visible reason.
  • Recovery is cheap. A node's entire managed surface can be regenerated from the database.
  • Values resolve by precedence — database override, then existing file value, then generated, then manifest default — which means an unset override does not clobber a generated password. The subtlety is real and has caused its own confusion.

References

  • Extract hal/env-sync module, remove syncEnvToDb, 2026-04-03 — the commit that removed the node-to-database direction.
  • Knowledge base: conventions/no-direct-file-mutation, provisioning (resolution priority).
  • Regeneration gaps: troubleshooting/changed-manifest-default-not-rerendered, troubleshooting/config-removed-from-manifest-not-pruned.