Issue 007: the instance is fixed, the class is the issue

The incus hook landed and does the post-install work — group, subordinate
id ranges, both units, storage pool, bridge, default profile. Verified
independently here: group exists with the operator in it, both id files
carry the range, service active, pool reports CREATED. The only thing that
fails is a shell whose process tree predates the usermod, which is how
group membership works and not a defect.

So the mechanism was never missing. Hooks are the right place and they
work. The gap is narrower and worse: the hook did six things, six checks
were then performed by a human by hand, and nothing in the pipeline
asserted any of them. A pipeline that dispatched a hook which silently
never fired would have been green in the same 48 seconds — and a hook
named for a feature its module does not carry is skipped without
complaint, thirteen of which were found at once in the past.

The six manual checks are, almost word for word, the module's own
verification: outcomes rather than steps, which is exactly the shape the
lab design asks for. They currently live in a chat message. In the module
they would run on every delivery to every node.

Status moves to diagnosing rather than resolved, and fixed-by records the
instance explicitly as the instance only.

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.