Base layer: the mesh as it is, under the mesh as it should be

HQ held only the to-be. Every reader had to already know the system the
decisions were about, and an as-is claim had nowhere to live except inside
an intention.

Adds 02-DESIGN/00-as-is — eleven documents written from the implementation
and the operational record, not from intent, including the parts nobody
would choose again. The two existing designs move under 01-to-be. Layers
are declared in frontmatter and never mix: a design that ships does not
move, its as-is counterpart is written, and both stand.

Back-fills adr/0001-0014 for decisions taken in implementation and never
recorded — the broker, the module abstraction, the mesh database, managed
files, provisioning, migrations, the workspace removal, failing loudly,
the constitution, application placement, linking, the employee model, the
artifact, the three silos. Each marked reconstructed, dated from the
history, and citing the evidence it was recovered from. The two existing
records renumber to 0015 and 0016 so the ledger runs oldest first;
0017 extends 0015 to modules outside the core, principle only — the
domain list is deliberately not invented here.

how-we-build.md becomes the source of the mesh constitution, with a sync
playbook, so the enforced copy stops being the only one that is true.

Process becomes explicit: five playbooks, eight thin skills that defer to
them, a repository map, and AGENTS.md with CLAUDE.md as its include.

The five Observations become 04-ISSUES 001-005 where they can be owned and
closed. 006 is new and uncomfortable: HQ is not indexed into the knowledge
base. That claim is what decision 27 rests on, it was never checked, and
the README now says so instead of repeating it.

Also corrects the ADR index into something generated, the "02-DESIGN is
empty" claim, the VISION.md pointer that did not survive the repo split,
and a note asserting the symlink rule was contradicted — it was a
misreading; the rule forbids hand-made links, the installer links by design.

04-ISSUES/001-failed-package-install-reports-success/00-report.md

@@ -0,0 +1,49 @@
+---
+status: open
+opened: 2026-08-22
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 001 — A failed package install does not fail the job
+
+## Symptom
+
+A module declared a package. The install produced, from every mirror:
+
+```
+error: failed retrieving file … 404
+```
+
+followed by:
+
+```
+-> error installing repo packages
+```
+
+The prepare job then reported **success**. The package is absent; the pipeline is green.
+
+## Why this matters more than one missing package
+
+The first thing the lab work asked the mesh to install demonstrated the exact fault the lab
+exists to catch — a step that failed, reported success, and left the next step to run against
+state that was never produced.
+
+It is also a direct violation of a decision already taken and recorded:
+[ADR 0008](../../adr/0008-a-failed-step-fails-the-job.md) says a step that fails must fail the
+job. That record notes the rule is applied instance by instance and enforced by no mechanism.
+This is an instance where it was never applied.
+
+## Evidence
+
+- Observed 2026-08-22 while declaring the virtualisation package required by
+  [ADR 0016](../../adr/0016-a-lab-node-is-a-virtual-machine.md).
+- A fix is written and open as a pull request, unmerged since 2026-08-20.
+
+## Open questions
+
+- Why is the failure swallowed — is the exit status discarded, or never checked?
+- Is this specific to package installation, or does the surrounding stage swallow every
+  non-zero exit?
+- The fix has been open for two days. What is the review path for a change of this class?

04-ISSUES/002-stale-package-index-fails-silently/00-report.md

@@ -0,0 +1,40 @@
+---
+status: open
+opened: 2026-08-22
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 002 — A declared package can fail purely because the node's index is stale
+
+## Symptom
+
+A package install ran without first synchronising the node's package index. It therefore
+requested a version the mirrors had already superseded, and received a 404 from every one of
+them.
+
+The package exists. The declaration is correct. The node's view of what exists is old.
+
+## Why this matters
+
+The failure has nothing to do with the module, the manifest or the mirror. It is a property of
+when the node last synchronised, which nothing in the mesh manages or reports. Two nodes given
+the same declaration on the same day can produce different outcomes, and neither says why.
+
+Combined with [issue 001](../001-failed-package-install-reports-success/00-report.md), the
+failure is not only environmental but silent: today the node ends up without the package and
+the job is green.
+
+## Evidence
+
+- Observed 2026-08-22, same declaration as issue 001.
+- Documented as a recurring shape in the knowledge base under package installation failures,
+  where it is recorded as appearing in two disguises.
+
+## Open questions
+
+- Should the mesh own package-index freshness as a node property, the way it owns module
+  versions — or is an index sync part of the install step?
+- A partial sync is unsafe on the platform in use; a full upgrade is the only sanctioned fix.
+  Does that make index freshness a scheduled node concern rather than a pipeline one?

04-ISSUES/003-firewall-scope-is-read-by-no-code/00-report.md

@@ -0,0 +1,40 @@
+---
+status: open
+opened: 2026-08-22
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 003 — A firewall rule's `scope:` is read by no code
+
+## Symptom
+
+Five module manifests declare a `scope:` key on firewall rules. The key is not part of the
+firewall rule type and nothing reads it. Real scoping is expressed by a different field.
+
+A manifest can therefore appear to restrict a port and restrict nothing.
+
+## Why this matters
+
+This is the failure mode [`how-we-build.md`](../../00-GENESIS/how-we-build.md) names directly:
+*an unenforced rule is indistinguishable from a wrong one, and costs more, because people
+believe it.* Here it is worse than unenforced — the declaration reads as a restriction, so a
+reviewer checking whether a port is scoped will find that it is, and be wrong.
+
+It also says something about the manifest as a whole: an unknown key is accepted silently. Any
+misspelled or invented key behaves this way, and this one was found by reading rather than by
+any check.
+
+## Evidence
+
+- Five manifests carry the key. Zero code paths consume it.
+- Recorded as an observation on 2026-08-22.
+
+## Open questions
+
+- Should the manifest reject unknown keys outright? That is the general fix; this is one
+  instance of it.
+- Were the five declarations intended to restrict something that is currently open? Each needs
+  checking against what the node actually exposes — the declaration cannot be trusted either
+  way.

04-ISSUES/004-certificate-issuance-targets-production/00-report.md

@@ -0,0 +1,37 @@
+---
+status: open
+opened: 2026-08-22
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 004 — Certificate issuance always targets the authority's production endpoint
+
+## Symptom
+
+The reverse proxy sets no staging endpoint for its certificate resolver. Issuance therefore
+goes to the public authority's production endpoint in every case, including experiments.
+
+## Why this matters
+
+Production issuance is rate-limited per domain and per account. Every certificate experiment on
+a real node consumes quota that is not replenished quickly, and exhausting it is not
+recoverable by retrying — it removes the ability to issue a certificate anyone actually needs.
+
+The consequence lands hardest on exactly the work most likely to iterate: standing up a new
+node, changing how names resolve, or testing the lab's certificate authority split
+([ADR 0016](../../adr/0016-a-lab-node-is-a-virtual-machine.md)).
+
+## Evidence
+
+- The resolver configuration declares no staging endpoint.
+- Observed 2026-08-22.
+
+## Open questions
+
+- Should the endpoint be a node property — production for nodes serving real traffic, staging
+  everywhere else — rather than a fixed proxy setting?
+- The lab issues its own certificates and so does not consume public quota at all. Does that
+  make this a problem only for experiments run outside the lab, and therefore an argument for
+  running them inside it?

04-ISSUES/005-pipeline-test-harness-unbuildable/00-report.md

@@ -0,0 +1,47 @@
+---
+status: open
+opened: 2026-08-22
+located-in: [hal]
+fixed-by:
+amended-design:
+---
+
+# 005 — The end-to-end pipeline harness has not built since the workspace was removed
+
+## Symptom
+
+The repository's end-to-end pipeline test harness depends on a workspace that no longer
+exists. It has not been buildable since 2026-06-04. Nothing runs it, and nothing reports that
+nothing runs it.
+
+## Why this matters
+
+The delivery pipeline is the mesh's most consequential machinery — every module reaches every
+node through it — and its only end-to-end coverage has been silently dead for over two and a
+half months.
+
+That interval is not incidental. Several of the pipeline's most expensive defects landed
+inside it: packaging that was never actually split from build, migrations and provisioning
+scripts reading a source layout that no longer ships, selection files never packaged at all.
+Whether this harness would have caught any of them is unknown — which is itself the point. The
+coverage was assumed, not checked.
+
+## Evidence
+
+- The workspace was removed by pull request #240 on 2026-06-04
+  ([ADR 0007](../../adr/0007-no-npm-workspace.md)).
+- The harness has not built since that date.
+- Recorded in the knowledge base as a standing entry, not as a fixed incident.
+
+## Relationship to the lab
+
+[`02-DESIGN/01-to-be/01-end-to-end-testing.md`](../../02-DESIGN/01-to-be/01-end-to-end-testing.md)
+designs end-to-end testing on a lab mesh, which would replace this harness rather than repair
+it. That is a reason to decide its fate deliberately, not a reason to leave it broken and
+unmentioned: until the lab exists, this is the coverage the pipeline is presumed to have.
+
+## Open questions
+
+- Repair, or retire in favour of the lab? Leaving it in the repository unbuilt is the one
+  option that keeps the false impression of coverage.
+- Was anything relying on it, or had it already stopped running before the workspace removal?

04-ISSUES/006-hq-is-not-indexed-into-the-knowledge-base/00-report.md

@@ -0,0 +1,57 @@
+---
+status: open
+opened: 2026-08-23
+located-in: [hal, hal-hq]
+fixed-by:
+amended-design:
+---
+
+# 006 — This repository is not indexed into the knowledge base, and the claim that it is holds up a decision
+
+## Symptom
+
+[`README.md`](../../README.md) states, as the answer to the objection against creating this
+repository:
+
+> These documents are still indexed into the knowledge base, so `recall_search` returns them
+> beside everything else. One source, many surfaces — which was always the actual requirement.
+
+Searching the knowledge base for this repository's content returns nothing.
+
+## Evidence
+
+Verified 2026-08-23, two searches against the mesh's operational memory:
+
+| Query | Result |
+|---|---|
+| The full title of a decision record in this repository | No results |
+| A distinctive phrase from the decision ledger | No results |
+
+No entry, no partial match, no stale copy. The indexing does not exist and appears never to
+have existed.
+
+## Why this is an issue and not a task
+
+The claim is **load-bearing**. Decision 27 separates HQ into its own repository, and the
+objection it answers was that a fourth knowledge system repeats the mistake the mesh's
+knowledge consolidation was created to fix. The recorded answer is *"indexing, not location"* —
+that the split is safe **because** these documents remain searchable alongside everything else.
+
+Without the indexing, the objection stands unanswered and this repository is precisely the
+fourth knowledge system it was argued not to be. Either the indexing is built, or decision 27's
+reasoning is amended to something that is true.
+
+It is also, exactly, the failure this repository names in its own rules: a document stating a
+rule about the mesh must say how the rule is checked. This one stated a mechanism and nobody
+checked it — including in the same commit that wrote the rule.
+
+## Open questions
+
+- Where would the indexing run? The operational memory is written through a mesh capability;
+  is this a periodic sync of a repository into it, or a search surface that reads the
+  repository directly?
+- Which store — the flat symptom-indexed memory, the structured archive, or both? They have
+  different lifecycles ([`02-DESIGN/00-as-is/07-knowledge.md`](../../02-DESIGN/00-as-is/07-knowledge.md)),
+  and this content is governed rather than incidental.
+- Public repository, private mesh: the sync direction must not become a path for mesh-specific
+  content to arrive **into** these documents.

04-ISSUES/README.md

@@ -0,0 +1,46 @@
+# 04-ISSUES
+
+The front door for "something is wrong" at the level of the mesh's design or governance.
+Diagnosis happens here, where the whole mesh is in view; the fix lands in the owning code
+repository.
+
+## What belongs here
+
+| Belongs here | Belongs in the knowledge base |
+|---|---|
+| The design permits a failure to be silent | How to fix one occurrence of it |
+| A documented rule is enforced by nothing | A command that works around it |
+| A stated invariant is false in practice | A node-specific quirk |
+| The owner is unknown and finding it needs the whole mesh in view | Symptom → fix, once the answer is known |
+
+The knowledge base already holds the operational record and is indexed on symptoms. **This
+folder is not a second copy of it.** An issue here is a question HQ must *answer*; an entry
+there is an incident someone must *clear*. An issue whose answer is a general lesson belongs in
+both.
+
+## Structure
+
+```
+NNN-short-name/
+  00-report.md      the symptom as observed, with the evidence; status in frontmatter
+  01-diagnosis.md   the investigation trail, dated, including what was ruled out
+```
+
+## Frontmatter, on `00-report.md`
+
+```yaml
+---
+status: open | diagnosing | located | resolved | wontfix
+opened: YYYY-MM-DD
+located-in: []       # owning repo(s) or module(s), filled by diagnosis
+fixed-by:            # pull request or commit reference, filled at resolution
+amended-design:      # design doc path, when the root cause was a design gap
+---
+```
+
+## Rules
+
+- Anyone may open an issue. No localisation is required to report one.
+- The full flow is playbook [`00-GENESIS/process/03-issues.md`](../00-GENESIS/process/03-issues.md).
+- Closed issues are never deleted — they are the mesh's symptom-to-component memory.
+- `wontfix` is legitimate and requires a sentence saying why.