diff --git a/FABRIC-2.md b/FABRIC-2.md index c53d5c1..5bb5c72 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -302,6 +302,23 @@ and recorded. - [ ] **§17.4 — the framebuffer utility's internal heat/decay dynamics are undesigned.** Explicitly "Open, deferred": not a Stadium patron, but what physics (if any) governs it internally was never designed. Not blocking anything. + + > **CHECKED 2026-08-13, still correctly not ripe — precondition refined, item left open.** + > The actual FABRIC.md text (end of §17.5, not really §17.4 — that section number is a + > loose reference to the same "OPEN, deferred" paragraph) is explicit: "What those + > dynamics are is a question for when the framebuffer work actually happens... it should + > not be designed speculatively now." The console/framebuffer work (item 4.3/4.4 series) + > has since substantially shipped and is live, which looks at first glance like that + > precondition is now met. It isn't: grepped `src/starkernel/hal/framebuffer.c`, + > `vt100.c`, `console.c` (1,800 lines total) for `heat`/`decay`/`dirty` — zero hits. Every + > write is immediate-mode (`fb_scroll_rows()`, `fb_scroll_rect()`, direct glyph blits at + > the point of writing); there is no damage list, no dirty-region tracking, nothing a + > per-region heat/decay scheme would even attach to yet. That's consistent with Section + > A's item 1.11 (dirty-event granularity) still being unstarted — this item's true + > prerequisite is 1.11, not "the framebuffer work" in general as originally framed here. + > Designing framebuffer-internal physics before the dirty-event mechanism they'd govern + > exists would be exactly the speculative work FABRIC.md warns against. Left open, framing + > corrected: blocked on item 1.11, not merely deferred. - [x] **§23.4 #2 — cell-size validation against a real message shape.** "Check that a typical message still fits in one cell" was never done — item 3.1's own done-note confirmed no message-patron struct existed yet at the time. This is now checkable: item 4.2 built