From 60736199a4db317a8e47c03b53d0c335854964ec Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 26 Aug 2026 21:33:09 +0200 Subject: [PATCH] 012: keep the original, and flag what cannot be decided MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two additions from the operator, and the second answers a question this effort had open with two bad answers. Nothing is taken over without keeping what was there. Adoption happens on machines somebody is already using, and the configuration being taken over is configuration somebody chose. This is a never rule rather than a courtesy, and it earns that by the same incident the mesh's strongest rule carries: the worst loss in this record came from a tool acting on a path it did not own. Adoption is that act made deliberate, which makes the safeguard obligatory. And adoption produces a briefing, not just a result. It meets things a script cannot decide — a runtime configured one way against a mesh wanting another, a package pinned for a reason, local settings the mesh has no opinion about. Silently winning is wrong in both directions and refusing outright makes a machine in use unadoptable. So conflicts are FLAGGED: what it found, what it took over, what it could not resolve, written to be read by a person or an agent as the first thing a session on that node has to work with. That is the declaration parser's principle at a larger scale — name every problem at once, to somebody who can act on it. The question it turns on is recorded rather than assumed away: 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 — 04-ISSUES/003 again. Working position: the node is usable and the mesh KNOWS it has unresolved adoption questions, as a state something can ask about rather than a document in a log directory. What that state prevents is undecided. --- .../00-overview.md | 48 ++++++++++++++++++- 1 file changed, 46 insertions(+), 2 deletions(-) diff --git a/01-RESEARCH/012-the-minimum-viable-node/00-overview.md b/01-RESEARCH/012-the-minimum-viable-node/00-overview.md index 1f04e1e..3c91405 100644 --- a/01-RESEARCH/012-the-minimum-viable-node/00-overview.md +++ b/01-RESEARCH/012-the-minimum-viable-node/00-overview.md @@ -78,14 +78,58 @@ what the mesh never put there. Adoption is the deliberate act of taking ownershi that. The rule needs a companion rather than an exception: *never, unless adoption made it the host's*, with adoption being explicit, recorded, and visible in what the host says it owns. +## Nothing is taken over without keeping what was there + +**Before adoption touches a file, the original is kept.** Adoption happens on machines somebody +is already using, and the configuration being taken over is configuration somebody chose. A +one-way door on a working machine is not an installation, it is a risk nobody agreed to. + +This is a *never* rule rather than a courtesy, and it earns that by the same incident the mesh's +strongest rule already carries: the worst loss in this record came from a tool acting on a path +it did not own. Adoption is that act, made deliberate — which makes the safeguard obligatory +rather than optional. + +What that requires, and what remains open: where the copy lives, whether it is recorded in what +the node knows about itself so that adoption is *visibly* reversible, and whether the mesh keeps +it forever or hands it back when it stops managing the thing. + +## Adoption produces a briefing, not just a result + +Proposed by the operator, and it answers a question this effort had open with two bad answers. + +Adoption meets things a script cannot decide. A container runtime configured with one storage +driver and a mesh wanting another. A package pinned to a version somebody chose for a reason. +Local settings the mesh has no opinion about and no business discarding. Silently winning is +wrong in both directions; refusing outright makes a machine in use unadoptable. + +**So adoption has two outputs.** What it did — mechanical, recorded, in the node's state. And a +**briefing**: what it found, what it took over, and what it could not resolve, written to be +read by a person or an agent, which is the first thing a session on that node has to work with. + +Conflicts are **flagged, not resolved**. That is the same principle the declaration parser +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. + +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. + ## Open questions | Question | Why it is open | |---|---| | 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? | A runtime configured one way and a mesh wanting another. Silently winning in either direction is wrong; refusing may make a machine unadoptable. | -| Is adoption reversible? | If the configuration that was there is not recoverable, adoption is a one-way door on a machine somebody was already using. | +| ~~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. | +| 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. | | How does a bundle stay true between building and applying? | It is built against a scan of the target. The machine can move between the scan and the apply, so the host has to verify rather than assume — and fail plainly when the bundle no longer fits. | | What cannot be precomputed at all? | Anything built from source on the target still needs a toolchain and a network at that moment. Tailoring moves that cost rather than removing it, and *minimal viable* has to be honest about what it cannot ship ahead. |