Files
hq/01-RESEARCH
jschoubben 42bce02bba 006: answer the host-size question by measuring it
The skeleton's biggest unproven claim was that absorbing six concerns makes a
binary whose whole argument is having no dependencies carry six of them.

Measured against origin/main, and the question turns out to ask about the wrong
axis. By size the absorption is SMALLER than the machinery that already applies
state on a node — 2755 lines of adapters against 3059 lines of meshware,
env-sync and config-sync. The host is not a new large thing; it already exists,
spread across three core modules.

The real risk is direction, and it is two modules wide rather than six concerns
wide. Eight of ten adapters already receive derived state and only apply it, so
absorbing them moves code that has no dependency to move. Two — wireguard and
traefik — open a Postgres connection to the control plane and compute their own
configuration, which inside tier 0 would be an upward dependency and is exactly
what the tier rule forbids.

And the split has already been happening without being named: dnsmasq-app needs
the same node data as wireguard and does not query for it, because hand-
duplicated state went wrong and someone derived it centrally instead. Eight of
ten adapters are on the far side of that migration.

So the absorption is not a move, it is a split: deciding stays in tier 2,
applying goes to tier 0. The claim survives with its scope corrected — the host
carries ONE concern, apply declared state on this machine, of which the six are
instances.

Stated open rather than glossed: the two unsplit modules are the two hardest,
six concerns is still six vocabularies even at zero dependencies, and what the
host must carry versus find is issue 007 and unresolved.

Question B also recorded as answered by the operator — a node is a managed
machine, and a disconnected node is still a node in a different situation. The
question posed a class distinction; there is none, and what varies is state.
2026-08-25 02:20:32 +02:00
..

01-RESEARCH

Investigations that have not yet hardened into design.

Structure

Each effort lives in NNN-descriptive-name/ and must contain 00-overview.md, carrying its state in YAML frontmatter and a prose summary below it:

---
status: active | graduated | abandoned
initiated: YYYY-MM-DD
touches: []          # design docs, subsystems or areas the effort bears on
became: []           # required when status is terminal — what it turned into
---

The prose says what is being investigated, why, and what it touches. It does not restate the status — status lives in one place, and two places is one too many.

Further documents in the same folder hold the work itself: notes, evidence, option analyses, draft designs.

Lifecycle

status Meaning
active Investigation in progress.
graduated Checked against 00-META, decided in 02-DECISIONS/, and specified in 03-DESIGN — see became:.
abandoned Stopped or superseded. Nothing is deleted.

An effort graduates by producing a decision record and a 03-DESIGN entry. It is abandoned in place — never deleted. What was rejected, and why, is the more expensive half to rediscover.

Starting and closing efforts is playbook territory: 00-META/process/01-research.md and 02-graduation.md.

Rules

  • Markdown only. Do not skip or reuse a sequence number.
  • Evidence, not assertion. An effort that measured nothing has not finished.
  • Research describes real observations but never identifies the mesh it observed. The shape of a finding survives anonymisation intact.