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:
co-authored by
Claude Opus 5
parent
d7d9e274c8
commit
941fb778e2
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user