FABRIC.md §25: item 2.1 acceptance now tests what 2.1 changes

Review item REVIEW-D1.

Item 2.1 restates vm_physics_touch on tick count and accepted on the
dictionary-hash double-boot check from item 0.10. That check cannot detect the
work: §18.5 establishes that vm_physics_touch writes node->physics, not
DictEntry.execution_heat, and so never reaches the parity hash. The dict hash
would be identical whether 2.1 succeeded, failed, or was skipped entirely.

Acceptance is now an identical fleet heat sum across two boots of the same
capsule -- fleet heat being the quantity the item actually changes. The
dict-hash check still runs, as a regression guard rather than as evidence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Robert Allan James
2026-08-03 11:09:16 -04:00
co-authored by Claude Opus 5
parent d7d9e274c8
commit 941fb778e2
+10 -2
View File
@@ -2089,10 +2089,18 @@ document and committing that amendment as its own item.*
- [ ] **2.1 — Restate heat transfer on tick count.**
`vm_physics_touch()` scales transfers by wall-clock elapsed time
(`capsule_vm_physics.c:272`). Restate it on tick count.
*Done when:* no wall-clock value influences heat, and the double-boot reproducibility
check from 0.10 still passes.
*Done when:* no wall-clock value influences heat, **and the same capsule booted twice
produces an identical fleet heat sum across the two runs.**
*Refs:* §18.5, §19.6 #3.
> **Acceptance corrected.** This item previously accepted on the dictionary-hash
> double-boot check from 0.10. That cannot detect this work: §18.5 establishes that
> `vm_physics_touch()` writes `node->physics`, **not** `DictEntry.execution_heat`, and
> therefore never reaches the parity hash. The dict hash would be identical whether 2.1
> succeeded, failed, or was skipped. Fleet heat is the quantity this item changes, so
> fleet heat is what has to be compared. Run 0.10's dict-hash check as well, as a
> regression guard — but it is not evidence for 2.1.
- [ ] **2.2 — Bound the VM registry.**
The registry is a `kmalloc`-backed unbounded list, which makes fleet K an identity that
cannot fail (§20.2). Give it the hard bound decided in 1.5.