diff --git a/FABRIC.md b/FABRIC.md
index 274285e..638e5b4 100644
--- a/FABRIC.md
+++ b/FABRIC.md
@@ -5789,6 +5789,115 @@ document and committing that amendment as its own item.*
   so the prompt's final shape isn't lost, not because it's ready to build.
   *Refs:* §27.8, CLAUDE.md ACL section (Phase 8).
 
+- [ ] **4.4u — Locked bottom-up console layout design.** Captain Bob walked the full console
+  layout bottom-up in conversation on 2026-08-11 (evening session, after 4.4t landed); recorded
+  here verbatim as the reference spec before any of it is built, per this document's own
+  discipline of capturing design before implementation. **This revises 4.4m/4.4n's REPL-strip
+  sizing** — see the conflict note below; those items stay checked as a historical record of
+  what was decided at the time, not edited in place.
+  **The design, bottom-up, per architecture's own raster coordinates:**
+  1. **Row 0** — the very last pixel row of the physical framebuffer (`fb_height()-1`), same
+     rule on every ISA regardless of resolution. A horizontal line runs the full screen width.
+  2. A few pixels up from that line: the **REPL prompt baseline** — cursor and prompt
+     (`[Hera] ok>`) sit here, text flows left to right.
+  3. An **equal number of pixels** further up from the baseline (mirroring the gap below it):
+     a second horizontal line, full width — the REPL strip's top border. The strip is
+     symmetric around the baseline by construction.
+  4. **REPL input is single-line with horizontal scroll on overflow, not soft-wrap** — decided
+     explicitly in conversation after weighing both: soft-wrap would mean the strip grows
+     upward as a line wraps, pushing CANVAS's boundary and requiring CANVAS content to
+     reflow or get covered/uncovered live; horizontal scroll (classic readline-style, view
+     follows the cursor through a fixed single-line window into the full input buffer) needs
+     none of that and was chosen as "cleaner." **Input buffer width for this strip needs
+     resolving against `INPUT_BUFFER_SIZE`=1025 (CLAUDE.md) before this is buildable** — Bob's
+     verbal estimate was "like 255/256," well under the actual shared REPL/LOAD buffer size;
+     not reconciled yet, flagged here rather than guessed at.
+  5. A small additional gap above the REPL strip's top border.
+  6. A **literal drawn box** — an actual stroked rectangle outline, not just an implicit text
+     boundary — for the 640×480 scroll area (4.4o's geometry), centered horizontally (equal
+     left/right margins, already computed: amd64 x=[320,960], aarch64/riscv64 x=[80,720]).
+     All REPL output/scrollback history (4.4q) renders inside this box. **Not yet drawn** —
+     4.4t confined content to this rect but never stroked a visible border on it.
+  7. **Above the box: nothing, by default** — reserved blank space, no permanent content.
+  8. **The toggle (4.4r) is bound to the TAB key.** Toggling hides the box's contents; at that
+     point the box's own footprint *and* the blank space above it become one unified, full
+     CANVAS free-play area for vector/graphics work. Toggling again restores the box and its
+     scrollback content undisturbed. **The REPL strip (steps 1-4) is never covered by this —
+     toggle state only ever affects the box and the space above it, never the bottom strip.**
+  **Colors, decided explicitly:** REPL strip characters — **bright white** (`0xFFFFFF`,
+  `FB_ANSI_PALETTE[15]`). The two horizontal lines bounding the REPL strip — **gray** (exact
+  shade not yet pinned to a specific palette index or RGB triple; use a mid-gray consistent
+  with `FB_ANSI_PALETTE`'s existing gray entries — index 7 `0xAAAAAA` or index 8 `0x555555`  —
+  and confirm the choice with Bob before implementing, don't assume). Scroll-box content colors
+  are unchanged from what's already live (4.4h's orange `[VM]` prefix, cyan `ok>`).
+  **Conflict with 4.4m/4.4n, not silently resolved:** 4.4m decided a 96px/4-visible-line REPL
+  strip (one merged scroll+input box); this design has a single-line REPL strip (well under
+  96px — closer to one `VT100_TTF_CELL_H_PX` row, ~24-40px depending on the two gap sizes,
+  neither pinned yet) with scrollback living entirely in the separate box from step 6. 4.4n's
+  CANVAS-height arithmetic (`screen height − strip height − gap`) will produce a taller CANVAS
+  once the real (smaller) strip height is pinned down — a strict improvement on the 4.4n
+  numbers, not a fit failure, but the exact numbers need redoing, not assumed to still hold.
+  *Done when:* the two open gaps above (input buffer width vs. `INPUT_BUFFER_SIZE`; exact gray
+  shade; exact pixel values for the two REPL-strip gaps) are resolved with Bob, then this
+  item's numbers feed a redo of 4.4n's CANVAS rectangle before any drawing code is written.
+  *Refs:* §27.8, 4.4m, 4.4n, 4.4o, 4.4q, 4.4r, 4.4t.
+
+  > **Refined 2026-08-11, still open — mockup review round 1.** First rendered mockup
+  > (`evidence/mockups/console-layout-mockup-4.4u-amd64.png`, not live kernel code — a Python/
+  > PIL drawing at amd64's 1280×800 to check the geometry reads right before building it) shown
+  > to Bob. Two changes came back:
+  > - **The two REPL-strip gaps (baseline-to-bottom-line, baseline-to-top-line) both grow by
+  >   3px** — Bob wanted more headroom above the prompt specifically. First pass used 12px/12px
+  >   (a guess, not yet locked); now 15px/15px. Still not treated as final — just the current
+  >   working number for the next mockup pass, not a pinned spec value the way 4.4o's centering
+  >   math is.
+  > - **Scroll-box content needs its own soft-wrap** — separate from step 4's REPL-strip
+  >   horizontal-scroll decision. Text inside the drawn box (step 6) that exceeds the box's
+  >   inner width must wrap to additional lines within the box, not run past the box's right
+  >   border as the first mockup pass showed. This is scrollback *content* wrapping, not the
+  >   REPL input line — those are two different text flows with two different overflow
+  >   behaviors, don't conflate them when implementing.
+  > Second mockup pass regenerated with both changes and re-reviewed — approved as "pretty
+  > close." Both numbers above still informal (mockup-only, not implemented, not verified
+  > against real `TTF-TEXT` rendering) — this document's own discipline (don't assume a mockup
+  > number survives contact with real glyph metrics) means these still need to be re-checked
+  > once actually built, not carried forward as gospel.
+
+- [ ] **4.4v — M8 scope, precisely bounded: keyboard-to-REPL bridge.** Surfaced while
+  discussing 4.4u's TAB-toggle binding — Captain Bob's recollection was that keyboard input
+  already works end-to-end; checked against the code rather than assumed either way.
+  **What's real and already done** (confirmed by reading the code, not from milestone
+  status): `i8042.c` (amd64) and `virtio_input.c` (aarch64/riscv64) are genuine
+  interrupt-driven keyboard drivers — IOAPIC/IRQ1 routing confirmed live in this session's own
+  boot logs (`"I/O APIC: keyboard IRQ1 unmasked"`), scancodes/decoded `EV_KEY` events land in
+  a ring buffer, and `KBD-SCAN`/`KBD-DEBUG`/`VKBD-EVENT` (`keyboard_words.c`) expose that
+  buffer to FORTH, including a standing diagnostic (`g_i8042_isr_count`) that already caught a
+  real bug (a genuine IRQ misreported as spurious, item 4.3.5). This is real, tested,
+  interrupt-path-proven-alive infrastructure — not a stub.
+  **What's missing, precisely:** nothing calls `KBD-SCAN`/`VKBD-EVENT` from `repl.c`.
+  `sk_readline()` is documented in its own comment as reading "from serial console" and does
+  exactly that — no scancode-to-ASCII translation table exists, and no code path connects the
+  keyboard ring buffer to the REPL's line-read loop. The hardware/interrupt layer is done; the
+  bridge from that layer into text the REPL can act on is not. This is the same conclusion
+  `docs/lithosananke/ROADMAP.md`'s M8 section and this document's own 4.3.5-series entries
+  already recorded ("no keyboard path into the VM on any architecture, confirmed by reading
+  the code") — restated here specifically so 4.4u's TAB-toggle has an accurate prerequisite,
+  not because the earlier conclusion was in doubt.
+  **Scope for the bridge itself:** a scancode-to-ASCII table (amd64 i8042 scancode set 1 or 2 —
+  confirm which `i8042.c` actually captures, don't assume — plus `virtio_input.c`'s `EV_KEY`
+  codes for aarch64/riscv64, both need a table); `sk_readline()` gains a second poll path
+  alongside its existing serial read, merging both sources into the same line buffer (matches
+  the "merged serial+keyboard source" language already on record from the 4.3.5 entries); TAB
+  specifically needs to be intercepted *before* it reaches the line buffer as a character, and
+  routed to whatever the 4.4r toggle word ends up being, not inserted as a literal tab
+  character.
+  *Done when:* typing at a real (or QEMU-emulated) keyboard produces the same REPL behavior as
+  serial injection does today, on all three architectures, verified by QEMU boot with a
+  keyboard event injected via QEMU's own input-send-event monitor command (not socat/serial),
+  screendump showing the typed text landed in the REPL strip; three-arch QEMU boot + logs per
+  CLAUDE.md.
+  *Refs:* §27.8, 4.3.5 series, 4.4r, 4.4u, `docs/lithosananke/ROADMAP.md` M8 section.
+
 - [ ] **4.5 — URGENT, flagged by Captain Bob 2026-08-11: the kernel build has never used any
   compiler optimization.** **Blocking priority, set by Captain Bob 2026-08-11: no other
   punch-list item is worked until 4.5a–4.5f are done**, ahead of whatever would otherwise
diff --git a/evidence/mockups/console-layout-mockup-4.4u-amd64.png b/evidence/mockups/console-layout-mockup-4.4u-amd64.png
new file mode 100644
index 0000000..04fbafa
Binary files /dev/null and b/evidence/mockups/console-layout-mockup-4.4u-amd64.png differ