jschoubben
77f3a4cea7
Every remaining cluster merged. Each was one design that had been split across
several records because it was worked out over days rather than at once.
the node host 8 -> 1 applies not decides, depends on nothing,
per operating system, root service, the
launcher, episodic, what a declaration is,
actions from the bundle only
a node and how it joins 4 -> 1 what a node is, joining, the link as
security boundary, the enrolment token
modules and the graph 7 -> 1 everything is a module, no domain modules,
three edges, provisioning, the core library
substrate and control 6 -> 1 the test, seven contexts, one control plane,
plane the authority is not a database, the named
products, the pinned bundle
connectivity 3 -> 1 a route is a grant, reachability declared,
filter rules
delivery 5 -> 1 reconciliation not a pipeline, artifacts,
the three silos, a failed step, the verdict
the lab 5 -> 1 (earlier)
how this repository 10 -> 1 (earlier)
works
Nothing was dropped. Each consolidated record carries the reasoning of the ones
it absorbs -- the measurements, the incidents, the alternatives rejected --
because that reasoning is the only reason to keep a record at all. What is gone
is the fragmentation: eight files to read to understand tier 0, when tier 0 is
one component.
The four superseded records went too. They existed to point at their
successors, and the successors now contain what they said.
The checker made this safe. Each merge left dangling links -- 38 files after
the host merge alone -- and it named every one. Nothing was found by reading,
and a manual pass would certainly have missed some, including references inside
AGENTS.md which every session loads.
113 lines
5.4 KiB
Markdown
113 lines
5.4 KiB
Markdown
---
|
|
status: accepted
|
|
date: 2026-08-28
|
|
deciders: jochen
|
|
reconstructed: false
|
|
consolidates: [0020, 0021, 0022, 0023, 0024, 0026, 0027, 0028, 0030]
|
|
---
|
|
|
|
# 19. How this repository works
|
|
|
|
*Consolidated 2026-08-28 from ten records that were one decision seen from ten angles. The
|
|
reasoning is kept; the fragmentation is not.*
|
|
|
|
## The repository
|
|
|
|
**`novox/hq` is Novox's headquarters, and it is public.**
|
|
|
|
Company-scoped, not the mesh's. Today almost everything in it is about the mesh, because the
|
|
mesh is what Novox is building — a fact about the present rather than a definition. A second
|
|
product would live here too.
|
|
|
|
**Public** means written for a reader who is not its author and has no access to the mesh it
|
|
describes. Nothing here may contain routable addresses, real domain names, node names, absolute
|
|
paths, usernames or credentials. The test: *would this paragraph still teach a stranger running
|
|
an entirely different mesh?*
|
|
|
|
**Separate from the code** because the cadence differs — a decision changes when thinking
|
|
changes, not when code changes — and because a public repository cannot be a private one's
|
|
subdirectory.
|
|
|
|
**The naming rule:** a repository belonging to a product carries that product's prefix. A
|
|
company-scoped one does not. So this is `hq` and the mesh's are `mesh-*`.
|
|
|
|
| Repository | Tier | Holds |
|
|
|---|---|---|
|
|
| `novox/mesh-host` | 0 | the node host — the one binary installed by hand |
|
|
| `novox/mesh-substrate` | 1 | the pinned tier-1 services, as declarations |
|
|
| `novox/mesh-control` | 2 | the control plane and its contexts |
|
|
| `novox/mesh-surfaces` | 3 | tools, web, cli — thin, no logic |
|
|
| `novox/mesh-sdk` | — | the mesh's own domain ([ADR 0044](0044-modules-and-the-graph.md)) |
|
|
| `novox/mesh-lab` | — | the lab: scenario lifecycle, networking, placement |
|
|
| `novox/hq` | — | this one |
|
|
|
|
**The product is `Novox Mesh`**, shortened to `mesh` in internal use — repository names, the
|
|
module namespace, environment variables, paths. **`Nox` is an identity of Novox**, an agent
|
|
participant within the mesh's own model, not a second system.
|
|
|
|
## The folders, and why they are numbered
|
|
|
|
**The numbering is the flow.** Research produces a decision; the decision authorises a design.
|
|
Following the numbers walks the process in the order it happens.
|
|
|
|
| | |
|
|
|---|---|
|
|
| `01-RESEARCH` | an open question, while it is open |
|
|
| `02-DECISIONS` | what was decided, and why |
|
|
| `03-DESIGN` | what is being built |
|
|
| `04-ISSUES` | something wrong at the level of design or governance |
|
|
|
|
**`03-DESIGN` has two layers and they are never mixed.** `00-as-is/` describes the mesh that
|
|
exists, written from the implementation and the operational record. `01-to-be/` describes the one
|
|
being built toward. Every document says which it is. A statement about the future does not belong
|
|
in an as-is document, and an as-is document is never edited to describe an intention.
|
|
|
|
**`04-ISSUES` is for design-level faults** — a rule enforced by nothing, a stated invariant that
|
|
is false, a failure the design permits to be silent. Not an operational ticket queue.
|
|
|
|
## What a decision record is, and is not
|
|
|
|
**If a decision is worth recording, it is worth a record. If it is not worth a record, it is not
|
|
recorded.**
|
|
|
|
That bar has been read too generously. A *finding* is not a decision. A bug is not a decision.
|
|
**A record is warranted when there is a genuine fork**: a direction reversed, an alternative
|
|
seriously considered and likely to be proposed again, or something contested that needs to stay
|
|
settled. Everything else belongs in the design document, where the reasoning is read.
|
|
|
|
**There is no ledger** — no separate document summarising, ranking or tracking decisions. A
|
|
chronological view is generated from frontmatter, which is what a ledger was actually for.
|
|
|
|
**The design layer is what you read.** These records explain *why* a thing is as it is. They are
|
|
not a description of the system, and needing to read them to understand it would mean the design
|
|
documents had failed.
|
|
|
|
## Status, and views over it
|
|
|
|
**Every document carries its state in YAML frontmatter** — research overviews, design documents,
|
|
decision records, issue reports.
|
|
|
|
**There are no central status files.** Every cross-cutting view — a status matrix, a decision
|
|
index, an open-issue list — is generated from frontmatter when asked for, never written to disk.
|
|
Two places holding one fact drift, and the written one wins by being closer to hand.
|
|
|
|
**Prose does not restate status.** One place, and two is one too many.
|
|
|
|
## Workflows are playbooks
|
|
|
|
Every workflow is a playbook in [`00-META/process/`](../00-META/process/): trigger, who runs it,
|
|
steps, outputs. People and agents follow the same ones, and **agents do not act outside them**.
|
|
|
|
Each is wrapped by a thin skill that defers to the playbook as authoritative and adds only the
|
|
mechanical scaffolding — so the process has one definition rather than a document and an
|
|
implementation that disagree.
|
|
|
|
## Consequences
|
|
|
|
- **A reader has one place per thing.** The design layer describes the system; these records say
|
|
why; the playbooks say how work is done.
|
|
- **Records will accumulate more slowly**, because the bar is a fork rather than a finding. This
|
|
record is itself the correction: ten records became one because they were one decision.
|
|
- **The public rule constrains everything written here**, permanently and at every commit. It is
|
|
the reason research describes real observations without identifying the mesh it observed.
|