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

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). The lab design goes further and makes a module's own assertions the verdict on every delivery (design 01).
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.