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.
71 lines
3.9 KiB
Markdown
71 lines
3.9 KiB
Markdown
---
|
|
status: canonical
|
|
updated: 2026-08-23
|
|
---
|
|
|
|
# The Novox repositories
|
|
|
|
The map of where implementation lives. Humans use it for orientation; agents use it for issue
|
|
triage (playbook [`process/03-issues.md`](process/03-issues.md)). The `code:` frontmatter
|
|
field in design documents points at entries here.
|
|
|
|
Repository *names* are recorded; hosts, URLs and owners are not — this repository is public,
|
|
and a forge address is an operational detail (see [`README`](../README.md)).
|
|
|
|
| Repository | Owns |
|
|
|---|---|
|
|
| `hal` | The monorepo — the node runtime, the module catalogue, the delivery machinery, and the bootstrap scripts. Every core module lives here. |
|
|
| `hq` | This repository, under the company organisation — mission, research, design, decisions, issue diagnosis. Company-scoped ([ADR 0019](../02-DECISIONS/0019-how-this-repository-works.md)); the mesh is its first product. The source of truth for *why*. Carries no implementation. |
|
|
| *(one per application)* | Every standalone application, site or side-project gets its own repository, with `module.yml` at the root. Registered with the mesh as a build source; built and deployed by the same pipeline as anything in the monorepo. |
|
|
|
|
## What the mesh becomes
|
|
|
|
[ADR 0019](../02-DECISIONS/0019-how-this-repository-works.md) records the repositories the
|
|
monorepo decomposes into. **`mesh-lab` and `mesh-host` exist so far** — the lab is built first
|
|
([ADR 0016](../02-DECISIONS/0016-the-lab.md)); the rest are the
|
|
target, not the present.
|
|
|
|
| Repository | Tier | Holds |
|
|
|---|---|---|
|
|
| `mesh-host` | 0 | **exists.** The node host — one statically linked binary, requiring nothing present ([ADR 0037](../02-DECISIONS/0037-the-node-host.md)) |
|
|
| `mesh-substrate` | 1 | the four pinned services, as declarations |
|
|
| `mesh-control` | 2 | the control plane and its contexts |
|
|
| `mesh-surfaces` | 3 | tools, web, cli |
|
|
| `mesh-sdk` | — | contracts shared across tiers |
|
|
| `mesh-lab` | — | **exists.** The lab — scenario lifecycle, networking, placement. Ships to nobody; runs on a workstation. |
|
|
|
|
Tier 4's shape is open, and deliberately so: see ADR 0030 and
|
|
[research 005](../01-RESEARCH/005-domain-grouping/00-overview.md).
|
|
|
|
## What lives where inside the monorepo
|
|
|
|
Named by role, because the layout is itself part of the as-is design — see
|
|
[`03-DESIGN/00-as-is/`](../03-DESIGN/00-as-is/).
|
|
|
|
| Area | Holds |
|
|
|---|---|
|
|
| Module catalogue | One directory per module, each with a manifest. Core modules sit under the mesh's own namespace; everything else at the top level. |
|
|
| Node runtime | The daemon and interactive runtime that every node runs. |
|
|
| Bootstrap scripts | First-node initialisation, joining an existing mesh, and node rescue. |
|
|
| Shared library | The SDK every module builds against. |
|
|
| Pipeline test harness | End-to-end coverage of the delivery pipeline. Currently unbuildable — see [`04-ISSUES/005`](../04-ISSUES/005-pipeline-test-harness-unbuildable/00-report.md). |
|
|
|
|
## Why applications do not live in the monorepo
|
|
|
|
A standalone application in the monorepo is a convention violation, and reviewers reject it.
|
|
The reasoning is recorded in [`02-DECISIONS/0010`](../02-DECISIONS/0010-applications-live-in-their-own-repository.md):
|
|
the mesh installs, provisions for, and ships an application through exactly the same machinery
|
|
whether or not its source sits beside the mesh's own — so co-location buys nothing and costs
|
|
the monorepo's review cadence.
|
|
|
|
## There is no npm workspace
|
|
|
|
Each module is a standalone package that consumes its dependencies from the private registry,
|
|
not from a sibling directory. The workspace was removed after it caused build-versus-development
|
|
divergence — a workspace member importing another resolved to local unbuilt source in the
|
|
pipeline and to a published version in development. Recorded in
|
|
[`02-DECISIONS/0007`](../02-DECISIONS/0007-no-npm-workspace.md).
|
|
|
|
Consequence, and it is a real one: a cross-package change is two steps — publish, then consume
|
|
— and a repository-wide `npm install` does not exist.
|