2026-08-23 20:24:16 +00:00
1 changed files with 48 additions and 1 deletions
@@ -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.