012: on conflict, install the mesh's version

Decided by the operator. Where the existing configuration and the mesh's
disagree, the mesh's version is installed, the conflict is flagged, and it is
reconciled afterwards — the mesh's configuration is known to work, the machine's
is not, and a half-adopted machine is a state nobody understands.

So adoption always completes and flags inform rather than block, which also
settles what 'adopted with open questions' prevents: nothing. The node is a
node. The original is kept, so nothing is unrecoverable.

One class left open rather than folded in, because it is the one place the
oldest rule in this record argues the other way. 'Known to work' is true of the
mesh's configuration in isolation, not on this machine. Most disagreements are
preference and overwriting them is right. A few are tied to what is physically
present — a storage driver against the filesystem it is actually on, a data
directory pointing at a mount that exists — and installing ours there does not
discard a preference, it can make existing data unreadable. Restoring the
configuration file afterwards does not undo that.

The default is settled. The exception is not 'there is a conflict' but 'applying
ours would destroy something a configuration backup cannot restore', and
identifying that class is open.
This commit is contained in:
2026-08-26 21:37:04 +02:00
parent 60736199a4
commit bcb18c7329
@@ -110,15 +110,30 @@ Conflicts are **flagged, not resolved**. That is the same principle the declarat
already applies — name every problem at once, to somebody who can act on it — at a larger
scale, and applied to a case where refusing wholesale would be worse than proceeding.
**The question this turns on: are flags advisory or blocking?** A briefing nobody opens is worse
than a failure, because the machine is in service and the record says it went well. That is
[04-ISSUES/003](../../04-ISSUES/003-firewall-scope-is-read-by-no-code/00-report.md) again — a
thing declared and never read.
### On conflict, the mesh's version is installed
The working position, to be tested: the node is **usable**, and the mesh **knows** it has
unresolved adoption questions. *Adopted with open questions* is a state something can ask about,
rather than a document in a log directory. What that state blocks — nothing, placement of
certain modules, or promotion out of a provisional condition — is undecided.
Decided by the operator: where the existing configuration and the mesh's disagree, **the mesh's
version is installed**, the conflict is flagged, and it is reconciled afterwards.
The reasoning is that the mesh's configuration is known to work, the machine's is not, and a
half-adopted machine is a state nobody understands. Adoption therefore always **completes** —
flags inform, they do not block — and the original is kept, so nothing is unrecoverable.
That also answers what *adopted with open questions* prevents: nothing. The node is a node.
**One class of conflict this should not cover, and it is the open part.** *Known to work* is
true of the mesh's configuration in isolation, not on this machine. Most disagreements are
preference — tuning, logging, a mirror — and overwriting them is right. A few are tied to what
is physically present: a container runtime's storage driver against the filesystem it is
actually on, a data directory pointing at a mount that exists. Installing the mesh's version
there does not discard a preference; it can make existing data unreadable, and restoring the
configuration file afterwards does not undo that.
So the default is settled and the exception is not: the exception is not *there is a conflict*
but *applying ours would destroy something a configuration backup cannot restore*. Identifying
that class is open, and it is the one place where this repository's oldest rule — the incident
that came from a tool acting on a path it did not own — argues for refusing rather than
proceeding.
## Open questions
@@ -126,8 +141,9 @@ certain modules, or promotion out of a provisional condition — is undecided.
|---|---|
| What is the closure for a one-node mesh? | The skeleton asserts four pinned services. [Research 006](../006-mesh-from-scratch/00-overview.md) already asks whether it is four or five and does not answer. A graph gives a computed answer instead of an asserted one, which is [research 011](../011-the-module-graph/00-overview.md). |
| Is "tier" the same thing as a graph level? | Tiers were named as a bootstrap order. If the closure is computed, tiers may be a derived view of the graph rather than a separate concept — or they may be a coarser boundary that survives for a different reason. |
| ~~What happens when existing configuration contradicts what the mesh needs?~~ | **Answered** — flagged in a briefing rather than resolved either way. What remains is whether a flag blocks anything. |
| Do flags block, or only inform? | A briefing nobody opens is worse than a failure. The working position is that the node is usable and the mesh knows it has open questions; what that state prevents is undecided. |
| ~~What happens when existing configuration contradicts what the mesh needs?~~ | **Answered** — the mesh's version is installed, the conflict is flagged, and it is reconciled afterwards. The original is kept, so nothing is unrecoverable. |
| ~~Do flags block, or only inform?~~ | **Answered** — they inform. Adoption always completes, and the node is a node. |
| Which conflicts are destructive rather than merely disagreements? | The one exception to the rule above. Overwriting a preference is right; overwriting something tied to the machine's filesystem or existing data can make that data unreadable, and a configuration backup does not undo it. Identifying that class is open. |
| Where does the kept original live, and for how long? | Whether it is recorded in the node's state so adoption is visibly reversible, and whether it is returned when the mesh stops managing the thing. |
| What shape is a briefing? | Structured enough to be acted on, prose enough to be read. It is the first thing a session on a new node sees, which makes it an interface rather than a log. |
| Does owning a package mean owning its version? | Owning configuration and owning the package are different scopes. The second means the mesh decides which version is installed, and that decision then has to survive the machine's own package manager updating it. |