Issues 007 resolved, 066 located, 064 diagnosed

04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md

@@ -1,11 +1,12 @@
 ---
-status: diagnosing
+status: resolved
 opened: 2026-08-23
-located-in: [hal]
+located-in: [hal (the instance), mesh-host internal/bootstrap (preflight asks the daemon), mesh-controller internal/catalogue (capabilities)]
 fixed-by:
   - "the instance only: PR #962 — incus hook. Merged, ran on one node in 6s of a 60s budget; pipeline #6832 green in 48s. The class remains open."
-  - "partly, on the mesh: mesh-host 73c010e, 9d8239a — preflight and the profile detectors ask the daemon, not the package (installed-but-broken reports absent). The class question the report asks of hal is not answered"
+  - "partly, on the mesh: mesh-host 73c010e, 9d8239a — preflight and the profile detectors ask the daemon, not the package (installed-but-broken reports absent)"
-amended-design:
+  - "the class, on the mesh: a manifest declares capabilities, an action declares verify (ADR 0005), and a module's own assertions are the lab's verdict (design 01). The old arrangement is replaced module by module, so its count is never taken"
+amended-design: 03-DESIGN/01-to-be/01-end-to-end-testing.md
 ---
 
 # 007 — An installed package is not an available capability

04-ISSUES/007-an-installed-package-is-not-a-capability/01-diagnosis.md

@@ -0,0 +1,20 @@
+# Diagnosis — 2026-09-21
+
+1. The instance was fixed in the arrangement being replaced, by a hook, and verified by hand; the
+   report's remaining question was about the class: does a module declare a capability — the
+   outcome — separately from the package that provides it, and how many other packages sit in the
+   same state.
+2. In the mesh the class is answered twice over, by design rather than by hook. A module's
+   manifest declares `capabilities` — what the machine must be able to do — and the host's
+   preflight and profile detectors ask the daemon, not the package, so an installed-but-broken
+   runtime reports absent. And an action a declaration runs carries `verify`, which the host
+   treats as the read-back and the idempotency check both: "is it there" is asked of the outcome,
+   never inferred from the step ([ADR 0005](../../02-DECISIONS/0005-the-node-host.md)). The lab
+   design goes further and makes a module's own assertions the verdict on every delivery
+   ([design 01](../../03-DESIGN/01-to-be/01-end-to-end-testing.md)).
+3. The count of other packages in that state in the old arrangement was never taken, and will not
+   be: the old arrangement is being replaced module by module, and each module that crosses over
+   declares what it needs and is proven in the lab.
+
+**Located in:** the arrangement being replaced, for the instance; the mesh, for the class, where
+it is answered by `capabilities` on the manifest, `verify` on an action, and the lab's verdict.

04-ISSUES/064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/01-diagnosis.md

@@ -0,0 +1,20 @@
+# Diagnosis — 2026-09-21
+
+1. The package half was read against what the mesh now runs. The mesh's package registry has
+   proxied the public one for every package since early September, before this issue was opened;
+   and the builder's `.npmrc` names the mesh's registry for the mesh's own scope only, so a public
+   package is asked of the public registry directly. Either the failing build ran before the
+   proxy, or its Dockerfile set the registry itself, or the build machine could not reach the
+   public registry at that moment. The report does not say which, and the 404 cannot be placed
+   without running the build again. Not fixed; not reproduced either.
+2. The image half has a precedent. The lab hit the same refusal pulling a vendor tool and found
+   the cause was the public hub denying anonymous pulls, not the mesh's redirect; the fix was to
+   pin the same image from another registry. A `COPY --from` of a public image is a build input
+   the manifest does not declare, so the mesh cannot pre-fetch or pin it the way it pins bases —
+   which is the second open question, and the one a decision has to settle.
+3. Ruled out: that the build environment has no internet. Package installs from the system's
+   repositories succeed in the same Dockerfiles.
+
+**Located in:** the builder (what it tells npm and the runtime) and the catalogue (three modules
+whose Dockerfiles fetch what no manifest names). Still open: a build must be re-run to place the
+404, and a decision is needed on whether a vendor image is declared as a build input.

04-ISSUES/066-a-partly-applied-declaration-leaves-a-mixed-state-with-no-rollback/00-report.md

@@ -1,7 +1,7 @@
 ---
-status: open
+status: located
 opened: 2026-09-20
-located-in: []
+located-in: [mesh-host internal/apply, mesh-controller internal/inventory (node_report)]
 fixed-by:
 amended-design:
 ---

04-ISSUES/066-a-partly-applied-declaration-leaves-a-mixed-state-with-no-rollback/01-diagnosis.md

@@ -0,0 +1,20 @@
+# Diagnosis — 2026-09-21
+
+1. The mixed state is already a first-class, visible one. The controller keeps three outcomes for
+   a machine's last report — applied, failed, refused — and defines `failed` as "some of it: the
+   machine is in a state nobody declared", with the failed resources and how many did apply beside
+   it. `status` lists such a machine as not doing what it was told. So the second open question
+   is answered as it stands: "partway through a change" is distinct from "converged" and from
+   "refused", and has been since the report was kept.
+2. What is not visible is duration, and that is [issue 065](../065-a-permanently-failing-resource-is-retried-for-ever-with-no-escalation/00-report.md),
+   resolved alongside: a machine that stays in the mixed state now reads as stuck.
+3. The first and third questions — pairings whose half-state is harmful, and whether `restart-on`
+   is the seed of a grouping — are a design decision the record does not yet contain. `restart-on`
+   couples a service to files within one apply but does not withhold either when the other fails.
+   No incident has produced a harmful pair; the report was written from reading the loop. A
+   grouping primitive without a case that needs it would be a rule enforced against nothing.
+
+**Located in:** mesh-host `internal/apply` (the loop) and the controller's report. Left open for
+the grouping question alone; it closes when a coupled pair that must not be half-applied is
+found in a module, and the declaration gains a way to say so — or when enough modules have run
+that the absence is evidence. The visibility half is done.