From e8f8b098ede58cba72f66b8b7e79ac08e2021c87 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Mon, 3 Aug 2026 11:21:15 -0400 Subject: [PATCH] =?UTF-8?q?FABRIC.md=20=C2=A725.7.1:=20second=20review=20p?= =?UTF-8?q?ass=20findings,=20awaiting=20rulings?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Full re-read of the document as it stood after the first review's corrections, looking for what would break a lower-capability model working the punch list. Nothing in this commit fixes anything -- it records fourteen findings for triage. The one that gates coding: GAP-A1. §16.4's inference "same tick ordinal → same hash" is unsound, because the hash covers execution_heat, which is co-written by the instruction stream and the tick stream, and a hardware timer makes the interleaving of those two streams wall-clock-dependent. Firing on tick count fixes the engine's schedule, not the composition. Blast radius: item 0.8 is ambiguous between two different kernels, 0.10's double-boot check fails by construction under one of them, and 2.1's corrected acceptance is still unachievable. Recommended resolution recorded (virtual tick as a pure function of the execution stream; hardware heartbeat as instrument and wake source only) but explicitly not decided. Also: three unverified prerequisites (DTB reachability for 0.3/0.6, FP-register save vs compile flags for 0.2/0.5, EL-dependence of the vector path vs 0.4's scope), seven punch-item defects (0.1 self-contradiction on block ranges, 0.2/0.5 unsatisfiable acceptance, 0.3's missing STIE and re-arm, §23.4 #4 not being a schedulable item, 1.11's informal deferral, 0.10's stale control framing, the hardcoded model attribution), and three amendment inconsistencies (stale K-denominator language in §17.3/§17.5/§17.6d, §19.6 #1-#2 unmarked as resolved, §20.3's stale LEANING). Triage order is stated in the section: A1 first, B1/B2 are ten-minute reads, C and D mechanical after that. C1-C3 minimum before any coding model starts. Co-Authored-By: Claude Fable 5 --- FABRIC.md | 110 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) diff --git a/FABRIC.md b/FABRIC.md index 3e54546..e4f9e07 100644 --- a/FABRIC.md +++ b/FABRIC.md @@ -2212,3 +2212,113 @@ so.* - `src/*.c.bak` files are tracked in git at the `src/` top level. - The `bump-z` / `bump-y` targets in the hosted `Makefile` reference version macros that do not exist in the generated `include/version.h`. + +### 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.* + +#### GAP-A1 — §16.4's central inference is unsound. NEEDS RULING BEFORE PHASE 0 CODING. + +§16.4 claims: *"same input → same tick ordinal → same reap and inference events → same +hash."* The last arrow is invalid. The hash covers `execution_heat`, which is co-written by +**two streams** — word executions (increments) and engine ticks (decay). Once ticks come +from a hardware timer, *where tick N lands relative to the instruction stream* is +wall-clock-dependent: under TCG, run A takes tick 42 after word #1000, run B after word +#1017. Decay interleaves differently, heat trajectories diverge, hashes differ. Firing on +tick count fixes the engine's *schedule*; the hash measures the *composition* of the two +streams, and that is not fixed. + +Blast radius: + +- **Item 0.8 is ambiguous between two different kernels.** Reading (i): the bottom half + services only TIME-TRUST bookkeeping — safe, parity holds, but "compudynamics on the + tick" did not actually happen. Reading (ii): the bottom half drives the engine/decay from + the hardware tick — parity breaks *by construction*, not by implementation error. +- **Item 0.10's double-boot dict-hash check** then fails under reading (ii), and no + implementation effort can fix it. +- **Item 2.1's corrected acceptance** (identical fleet heat *sum* across runs) is *still* + unachievable under a hardware tick: touch amounts scale with elapsed ticks between fixed + execution points, elapsed ticks vary run to run, so truncation losses vary, so the sum + varies. The first review's amendment did not go far enough. +- **The tempting split does not survive either.** "Hash-covered state on execution ticks, + TTLs on hardware ticks" fails because TTL expiry has side effects on the instruction + stream — a message expiring versus being delivered changes what runs, which corrupts heat + downstream. §17.1's "one tick" instinct was right; it picked the wrong clock. + +**Recommended resolution (not decided):** the engine's tick is a **virtual tick — a pure +function of the execution stream**, which is exactly what exists today and why parity holds +today. The hardware heartbeat becomes: the TIME-TRUST instrument (now real on three ISAs +instead of one), the idle wake source, and the driver of nothing that feeds patron state. +Scripted/parity runs stay bit-identical; interactive idling pumps virtual ticks from the +REPL poll loop so TTLs still expire in real time, in a context where parity was never +claimed. Phase 0's timer work remains fully justified as instrument and substrate. Under +this ruling §16.4, §17.1, §18.4 and items 0.8, 0.10, 2.1 all need rewording. The +alternative — re-baselining the parity claim itself — touches the patent support material +and is not recommended. + +#### GAP-B — unverified prerequisites (each is a short read; none has been done) + +- **B1 — Device tree reachability.** Items 0.3 and 0.6 instruct "read from the device tree" + (0.6 forbids alternatives). Whether the loader captures the DTB from the EFI + configuration table into `BootInfo` is unverified. If it does not, 0.3 and 0.6 silently + require loader plumbing that has no punch item. Read `uefi_loader.c` / `BootInfo` first. +- **B2 — FP/SIMD in the ISR path.** Items 0.2 and 0.5 save integer state only. If the + kernel is not built with `-mgeneral-regs-only` (aarch64) / soft-float (riscv64), a C + interrupt handler may clobber FP registers the interrupted mainline was using. One grep + of `Makefile.starkernel` settles it; the items should carry the check. +- **B3 — 0.4's EL detection does not govern the vector path.** 0.4 refuses to hardcode the + EL for timer registers, but 0.5 hardcodes `ELR_EL1`/`SPSR_EL1`/`eret`, and today's + `isr.S` installs `VBAR_EL1`. If EDK2 leaves the kernel at EL2, exceptions vector through + `VBAR_EL2` and 0.5's entire edit targets a table that is never consulted. EL + determination must govern VBAR, the saved-state register forms, *and* the timer set. + +#### GAP-C — defects in punch items a literal implementer will hit + +- **C1 — Item 0.1 contradicts itself.** Body says remove "blocks 2050–2059"; Refs says + block 2050 *survives*. The delete set is 2051–2056 + 2058–2059; 2050 is edited (banner + call kept, handshake/broadcast calls removed). A literal reading deletes the banner. +- **C2 — Items 0.2 and 0.5 have unsatisfiable acceptance.** Both require having "taken and + returned from at least one trap/IRQ," but at 0.2 no timer is armed (0.3) and at 0.5 there + is no GIC (0.6) and no armed timer (0.7). No interrupt source exists at those stages. + Fix: 0.2/0.5 accept on "boots unchanged, no regression"; the took-and-returned evidence + moves to 0.3/0.7. +- **C3 — Item 0.3 lost the two silent-failure modes.** The SBI timer is one-shot: a missed + re-arm stops the heartbeat forever with no error. `sie.STIE` is also unmentioned. 0.7 + says "re-armed each tick"; 0.3 must too. +- **C4 — §23.4 #4 blocks item 3.1 but is not a punch item.** The continuation-cell + encoding gates 3.1 by 3.1's own text, but rule 1 walks numbered items and nothing ever + schedules it. It should become item 1.12. +- **C5 — Item 1.11's deferral is not a formal prerequisite.** It says "do not settle + speculatively" but states no blocker, so rule 1 would schedule it. Add "(blocked on + 4.3)." +- **C6 — Item 0.10 misc.** "amd64 output unchanged" treats amd64 as a control, but 0.8 + changes amd64's engine plumbing by design — stale framing. "TIME-TRUST and variance + sane" is soft; sharpen to trust near `Q48_ONE`, variance small relative to the new + `expected_delta`. +- **C7 — The commit template hardcodes "Claude Opus 5."** Whichever model implements will + either violate the template or misattribute. Genericize. + +#### GAP-D — inconsistencies left by the layered amendments + +- **D1 — Three passages still argue from the K-justification the first review removed.** + §17.3 ("wastes the bounded capacity that gives K a fixed denominator"), §17.5's sizing + argument (same phrase), and §17.6(d) — the worst, since it cites §2 for a claim §2 now + explicitly disavows ("Without an inescapable bound, K is bookkeeping — §2 says this in as + many words"). +- **D2 — §19.6 #1 and #2 read as open but are resolved** (#1 by §23.1 with the residue in + §23.4 #4; #2 by §24.3). §17.4 got strike-through treatment; §19.6 did not. +- **D3 — §20.3 still says "LEANING nested"** one section before §21 decides it. One + forward pointer fixes it. + +#### What held up under this pass + +The patron taxonomy, behaviours-not-kinds dispatch, the three quantities, the two-valued +cell union, the nested-elastic-quota layout, the identity/mass invariant, Hera's +pin-and-panic, and §25.0's rules themselves. None of them moved. + +**Triage order when this is picked up:** rule on A1 first — it decides what item 0.8 even +means. B1/B2 are ten-minute reads. C and D are mechanical once A1 is ruled. Nothing should +go to a coding model before C1, C2 and C3 are fixed at minimum — those are the ones it +will hit in its first hour.