diff --git a/04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md b/04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md
index ebcf3ab..646bb1d 100644
--- a/04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md
+++ b/04-ISSUES/007-an-installed-package-is-not-a-capability/00-report.md
@@ -1,8 +1,9 @@
 ---
-status: open
+status: diagnosing
 opened: 2026-08-23
 located-in: [hal]
 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."
 amended-design:
 ---
 
@@ -68,3 +69,49 @@ hooks, and hooks have their own recorded failure mode: thirteen were found that
   that shape.
 - How many other declared packages are in this state? Nothing currently reports it, which means
   the answer is unknown rather than zero.
+
+## The instance is fixed; the class is what this issue is now about
+
+*Updated 2026-08-23.* A hook now does the post-install work — group membership, subordinate id
+ranges, enabling both units, creating the storage pool, the bridge, and the default profile.
+Verified independently afterwards: the group exists with the operator in it, both id files
+carry the range, the service is active, and the storage pool reports `CREATED`.
+
+**So the mechanism was never missing.** Hooks are exactly the right place for this, and used
+properly they work. The gap is narrower and worse than "there is no way to do it":
+
+> The hook did six things. **Six checks were then performed by a human, by hand.** Nothing in
+> the pipeline asserted any of them, and a pipeline that dispatched a hook which silently never
+> fired would have been green in the same 48 seconds.
+
+That is not hypothetical — a hook named for a feature its module does not carry is skipped
+without complaint, and thirteen such hooks were found at once in the past. The distance between
+*the hook ran and did six things* and *the hook was dispatched* is invisible from the outside,
+and it is the whole of this issue.
+
+### The verification that was done by hand is the assertion set
+
+The six checks performed after the merge are, almost word for word, what the module's own
+verification should assert — outcomes, not steps, exactly as the lab design requires:
+
+| Asserted by hand | As a module assertion |
+|---|---|
+| operator in the admin group | the group exists and contains the operator |
+| subordinate id range in both files | both files carry the range |
+| both units enabled, service active | the service is active, and still active shortly after |
+| storage pool present | the pool exists and reports created |
+| bridge present with an address | the bridge exists and holds its address |
+| default profile wired to both | the profile references the bridge and the pool |
+
+They currently live in a chat message. Moved into the module, they would run on every delivery
+to every node, and the difference between a hook that worked and a hook that was merely
+dispatched would stop being something a person has to notice.
+
+### What this issue now asks
+
+- Does a module gain a way to declare a **capability** — the outcome — separately from the
+  package that provides it, or is "write assertions" the whole answer?
+- The verify stage exists and asserts almost nothing. Is this simply the first module that
+  should use it properly, making the issue a coverage problem rather than a design gap?
+- **How many other declared packages are in the state this one was in?** Still unknown, still
+  unreported by anything, and now demonstrably worth asking.