21 lines
1.5 KiB
Markdown
21 lines
1.5 KiB
Markdown
# 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.
|