Three issues resolved: one closed by evidence, two answered by the replacement

012 named its own closing condition — a scenario with four images coming up —
and the scenario now stocks seven and has raised cleanly many times at the
memory the wrong diagnosis had raised.

001 is answered by the host reading the package database back after installing.
002 was NOT answered and was present here too, so it is a fix rather than a
note: a stale index is now named instead of reported as a failed install.

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

@@ -1,8 +1,8 @@
 ---
-status: open
+status: resolved
 opened: 2026-08-22
-located-in: []
-fixed-by:
+located-in: [mesh-host]
+fixed-by: mesh-host — a package is read back from the package database after installing
 amended-design:
 ---
 
@@ -47,3 +47,18 @@ This is an instance where it was never applied.
 - 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?
+
+## How it is answered
+
+*2026-08-31.* **The host reads the package database back after installing**, and refuses when it
+does not have the package:
+
+> `<name> was installed without error and the package database does not have it`
+
+That is the general rule this issue is one instance of, and the host applies it to everything it
+does: a command exiting zero says a transaction was *accepted*, not that the machine changed. The
+same read-back is why a container that starts and immediately dies fails an apply, and why a
+service asked to run is checked rather than assumed.
+
+HAL keeps the fault until its provisioning is switched off. Fixing it there would mean
+implementing the read-back twice, in the system being replaced.