jochen
35db2aaa41
Asked what the "sidecar" is and whether a supervised process would do instead. The repository answers both ways. ADR 0047 (accepted, unsuperseded) says a module with tools or events runs a container carrying its compiled code. To-be 18 and 20 (both proposed) define a `process` resource type — the module's own code, a unit the machine's supervisor keeps up — and the worked guide says plainly "it is why these are `process` rather than four containers." Neither design doc names 0047, and no decision record mentions a `process` shape at all. Diagnosed rather than left open, because the ground truth settles what the report could not. The shape is real: mesh-host defines TypeProcess, applies it, and tests it, and the host's vocabulary is twelve shapes rather than the nine ADR 0029 counted. So the alternative the report offered — that two proposed documents describe a type that does not exist — is disproven. ADR 0029's mechanism is intact and was not enough. The vocabulary-count test names the decision behind each addition: network 0029, access 0051, opening 0100. The eleventh names a *proposed design document*, and TypeProcess is the only shape in the vocabulary whose doc comment cites no ADR. Requiring every addition to name something does not require it to name a decision. The argument this issue asked for already exists — as a Go test comment. "It is a full-host shape rather than a portable one: it needs a process supervisor to install into. It does NOT need a container runtime, which is the point — only software that genuinely needs isolation asks for a container." That is a decision's context and consequences, in another repository. What the catalogue does is a third thing: 115 container declarations against 3 process, all three in showcase — the module to-be 20 documents. There the tools resource is a container running `sleep infinity` on a bare upstream base with the broker credential mounted, and the tools and provisioner entrypoints are run by nothing. That is the condition 0047 was written to end, back in a new shape. Where the isolation argument leaks is narrower than expected and worth having precisely: the serving key and the credential shape both conform. But serveTools serves every registered module over one broker connection, the runtime takes its modules from a comma-separated list, and x-source is stamped from the single credential — so two modules in one runtime means the second's events are attributed to the first. Nothing refuses it and no test asserts against it. Located on hq rather than on a code repository: the implementation and the design layer agree, and the missing thing is the record. Which shape is right is left open, deliberately — this establishes that the question was answered in practice and never written down, not which answer is correct. One correction kept in the trail: the first search here was for len(Vocabulary()), found nothing, and was two steps from being written up as "the mechanism ADR 0029 relied on is gone." The test binds the slice to a local first. A negative search result read as a fact about the world is the same error issue 113 recorded.
Novox HQ
The single source of truth for what Novox builds — what it is, what it is becoming,
and why. Today that is almost entirely Novox Mesh, the foundation everything else runs on. Implementation lives in modules/; the reasoning behind it lives here.
Structure
| Folder | Purpose |
|---|---|
00-META |
Mission, foundational context, the rules that hold across the mesh, the repository map, and the process playbooks. The northern star for every decision. |
01-RESEARCH |
Active and historical investigations, before they harden into design. |
02-DECISIONS |
Numbered decision records, in the order the decisions were taken — what was chosen, and what was rejected. |
03-DESIGN |
The authoritative specification, in two layers: 00-as-is — the mesh that exists — and 01-to-be — the one being built toward. |
04-ISSUES |
The front door for "something is wrong" at the level of design or governance. |
The numbering is the flow. Research produces a decision; the decision authorises a design.
That is why decisions are 02 and design is 03 — a reader following the numbers walks the
process in the order it happens.
The flow
idea ──► 01-RESEARCH ──► decision (02-DECISIONS/) ──► 03-DESIGN/01-to-be ──► built (code repo)
│ │ │
│ │ └─► 03-DESIGN/00-as-is once shipped
│ └────► abandoned (recorded, kept)
└─(small/obvious, still recorded in 02-DECISIONS)──────────► 03-DESIGN directly
symptom ──► 04-ISSUES ──► diagnosis ──► code-repo fix and/or design amendment
00-META/how-we-build.md ──► sync ──► the constitution the mesh injects into design sessions
Implementation lives in the code repositories — see
00-META/repos.md. Every workflow is a playbook in
00-META/process/; agents operate through them and not outside them.
Rules
- Markdown only.
- No new top-level folders without explicit confirmation.
- Knowledge flows
GENESIS → RESEARCH → DESIGN. Research graduates into design only after analysis against GENESIS confirms alignment, and only through a recorded decision. - Status lives in frontmatter, never in a central status file. Cross-cutting views are generated on demand, never hand-maintained.
- GENESIS and DESIGN are instance-agnostic. They describe the mesh as a concept — no machine names, no counts, no topology. A reader must not be able to tell how many nodes the author happened to have.
- RESEARCH describes real observations, but never identifies the mesh it observed. Evidence is what makes research worth reading, and the shape of a finding survives anonymisation intact — a node publicly named but behind a household NAT carries the whole lesson without naming anything.
- The as-is layer records what is, not what should be — including behaviour nobody would choose again. A layer that keeps only the good decisions is a brochure.
- A document that states a rule about the mesh should say how that rule is checked. This repository has a rule requiring every capability-exposing module to declare the core runtime as a dependency; zero modules do. An unenforced rule is indistinguishable from a wrong one.
This repository is public
Written for a reader who is not its author and has no access to the mesh it describes. Concretely, nothing here may contain:
- routable addresses, real domain names, hosting providers, or node names — use the
documentation ranges (RFC 5737
203.0.113.0/24, RFC 1918) and role names such asanchor,home-server,workstation,laptop - absolute paths from anyone's machine, usernames, home directories, or email addresses
- credentials in any form, including lengths or hashes of live secrets
- operational detail that is only useful to an attacker — which host is the VPN hub, on which port, which node is reachable only through a forwarded port
Private-range addresses and the overlay plan are fine: they describe a pattern, not a target.
The test is whether a paragraph would still teach something to a stranger running an entirely different mesh. If it would, it belongs. If it only makes sense to someone who knows this particular installation, it is either a note in the wrong place or a disclosure.
Why this is its own repository
It began inside the code repository, on the reasoning that the mesh already has a mesh-native knowledge store and that adding a fourth knowledge system would repeat the mistake this folder was created to fix.
That objection was about a fourth knowledge system, and the answer offered was indexing rather than location — that these documents would be indexed into the knowledge base, so a symptom search returns them beside everything else. One source, many surfaces. Where the source is authored is then a separate question.
That indexing does not exist. It was checked on 2026-08-23 and returns nothing; it appears
never to have existed. Until it does, the objection stands unanswered and this repository is
the fourth knowledge system it was argued not to be. Recorded as
04-ISSUES/006, and
left standing here rather than quietly reworded, because a claim that held up a decision and
was never checked is precisely the failure this repository exists to name.
Answered separately, a repository of its own is the better home:
- The cadence is different. A decision changes when thinking changes, not when code changes. Tying documents to a code branch means they merge on the code's schedule.
- The reviewers are different. A design argument is not reviewed the way an implementation is, and it should not queue behind a build.
- The scope is wider than one repository. ADR 0001 sends most modules out of the monorepo entirely. Documentation that governs several repositories cannot live inside one of them.
The trade is real and worth naming: a change to a document and the change to the code it
describes can no longer land in one commit. Keeping them honest is a discipline now rather
than a mechanism — which is why every decision is recorded in
02-DECISIONS as it is taken, and why a document that states a rule should
say how the rule is checked.
Recorded as ADR 0019.