From 39aa54b9a461ee4cf28f5909898493acb8485934 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Mon, 3 Aug 2026 11:34:14 -0400 Subject: [PATCH] =?UTF-8?q?FABRIC.md:=20fix=20GAP-D1=20through=20D3,=20clo?= =?UTF-8?q?se=20out=20=C2=A725.7.1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit D1 The three passages still arguing from the K-denominator justification that §2's correction removed: §17.3's opening now cites density's need for a volume (§19.2); §17.5's sizing argument re-grounded on mass swamping and §23.1's abolition of by-reference payloads; §17.6(d)'s bullet no longer cites §2 for a claim §2 explicitly disavows. D2 §19.6 #1 and #2 struck through as resolved (#1 by §23.1 with the residue scheduled as item 1.12; #2 by §24.3), matching §17.4's convention. D3 §20.3's stale LEANING now points at §21's DECIDED. §25.7.1's status updated: all fourteen findings closed. A1 ruled and applied, B1/B2 verified against the tree and fixed into their items, B3/C1-C7/D1-D3 applied. The findings text is preserved as the record of what was found. Co-Authored-By: Claude Fable 5 --- FABRIC.md | 49 +++++++++++++++++++++++++++++++------------------ 1 file changed, 31 insertions(+), 18 deletions(-) diff --git a/FABRIC.md b/FABRIC.md index a0fdede..a17ad92 100644 --- a/FABRIC.md +++ b/FABRIC.md @@ -715,7 +715,9 @@ This is worth stating plainly because "reap" reads as "free" and here it does no §16.3 left words as the unresolved patron. Pinning all of them resolves nothing — several hundred permanently resident, largely inert entries is the §9 screen-cell failure with a -different label, and it wastes the bounded capacity that gives K a fixed denominator. +different label, and it wastes the bounded capacity that density needs as its volume +(§19.2; this sentence originally cited the K-denominator justification that §2's +correction removed — D1). The better reading applies §5 unchanged. Storage sits beneath the Stadium. The **full dictionary sits beneath it too**, and only **hot words are on the floor**. @@ -880,10 +882,13 @@ patron, the grid is not. #### The sizing argument, independently A framebuffer is several megabytes of fixed device memory. Making it a patron means either -blowing the bounded capacity that gives K a fixed denominator (§2), or forcing the -by-reference payload path to exist for exactly one pathological object — which would decide -§12 Q1's payload threshold on the worst possible case. Sizing a design around its single -largest outlier is how the header ends up wrong for the other ten thousand entries. +swamping the bounded capacity (§2) — as mass, it would dwarf every other patron and make +density comparisons meaningless — or forcing a by-reference payload path to exist for +exactly one pathological object, which §23.1 has since abolished for patrons entirely. +Sizing a design around its single largest outlier is how the header ends up wrong for the +other ten thousand entries. *(This paragraph originally leaned on the K-denominator +justification removed from §2 and on the pre-§23.1 payload framing; the conclusion is +unchanged — D1.)* #### Not a patron does not mean no physics @@ -941,8 +946,10 @@ Per-entry heap allocation gives that up and takes several things with it: - **The finite state space.** Bounded capacity is what makes induction over the Stadium straightforward and what puts model checking on the table alongside theorem proving. -- **§2's hard outer wall.** Without an inescapable bound, K is bookkeeping rather than a - conservation law — §2 says this in as many words. +- **§2's hard outer wall.** The bound is what gives density a volume to be dense within + (§19.2) and §13 its finite index set. *(This bullet originally read "Without an + inescapable bound, K is bookkeeping — §2 says this in as many words"; §2 no longer says + that, and §20.2 established conservation is falsifiable regardless of the bound — D1.)* - **The engine's simplicity.** This is a freestanding kernel with `kmalloc.c` / `pmm.c` and no libc. Allocation in the reap path means the engine can fail to allocate, which means the engine needs a failure mode, which means it is no longer the thing §3 @@ -1258,14 +1265,14 @@ noun was overloaded. ### 19.6 Open -1. **What is mass, exactly, for each patron?** The definition is "cells occupied," which - requires §12 Q1 (payload threshold — inline versus by reference) and §12 Q2 (header - size) to be settled first. A patron stored by reference has small mass regardless of - payload size, which may be right or may be a loophole — a 1 MB block held by reference - would occupy one cell and read as dense. This needs deciding. -2. **Is mass constant for a patron's lifetime?** §17.4 Q4 (do patrons mutate in place) - decides this. If mass can change while a patron is resident, density is not stable and - ranking may thrash. +1. ~~**What is mass, exactly, for each patron?**~~ **RESOLVED by §23.1** — the by-reference + loophole is closed: if the payload is in the Stadium it counts toward mass, and what is + not in the Stadium is not resident. The one residue — whether continuation cells are + contiguous or linked, which shifts every large patron's mass — is §23.4 #4, scheduled as + item 1.12. (D2) +2. ~~**Is mass constant for a patron's lifetime?**~~ **RESOLVED by §24.3** — mass changes + only through an arbitrated transfer, never through traffic, so density is stable between + transfers and §13 gets a mass function that changes at enumerable points. (D2) 3. **How does traffic transfer heat between patrons, concretely?** `vm_physics_touch()` does this today for VMs, but it scales the transfer by wall-clock elapsed time (`capsule_vm_physics.c:272`), which §18.5 forbids for anything influencing patron state. @@ -1369,7 +1376,8 @@ This does not close Q6 by itself, but it changes the question. The choice is no between two greenfield designs; it is whether to formalise a nesting that is already half built, or to collapse it into a single region and discard the level that works. -**LEANING nested.** See §20.5 for what still has to be settled. +~~**LEANING nested.**~~ **DECIDED nested in §21**, written immediately after this section +(D3). See §20.5 for what still had to be settled. ### 20.4 A VM's mass is the capacity share Hera allocated it — PROPOSAL @@ -2300,8 +2308,13 @@ so.* ### 25.7.1 Second review pass — 2026-08-03, pre-coding. Awaiting rulings. *A full re-read of this document as it stood after the first review's corrections, looking -for what would break a lower-capability model working the punch list. Nothing here has been -fixed. GAP-A1 needs a ruling before item 0.8 is coded; the rest are queued for triage.* +for what would break a lower-capability model working the punch list.* + +**Status: all fourteen findings closed, 2026-08-03.** A1 ruled (virtual tick) and applied +to §16.4/§17.1/§18.4 and items 0.8/2.1. B1 verified (no DTB access; fixed into 0.3/0.6), +B2 verified (no FP restriction on any arch; fixed into 0.2/0.5), B3 applied (EL governs +the vector path; 0.4/0.5). C1–C7 applied to their items; D1–D3 swept. The findings below +are preserved as the record of what was found and why. #### GAP-A1 — §16.4's central inference is unsound. ~~NEEDS RULING~~ **RULED 2026-08-03: virtual tick.**