task-24: dead band above the letters page was max_rows across layers

docs/tasks/24-keyboard-layout-rethink.md

@@ -125,6 +125,31 @@ The keyboard layout on the phone matches a validated reference design
 The bottom row has ≤7 keys. Every level (letters, shift, opt, opt+shift)
 is screenshot-verified on the device. No key placement surprises.
 
+## Update 2026-07-27 — the dead band above the primary view, fixed
+
+The empty strip above the keys on the letters page was the row-count math
+this task warned about, caught in the act.
+
+`pos_input_surface` sets key height as `min_height / pos_osk_widget_max_rows()`
+(`pos-input-surface.c:1292`), and `max_rows` is the **MAX across every layer**
+of the layout, not the layer being drawn (`pos-osk-widget.c parse_layers:743`).
+Patch 0004 had appended a 4-key arrow row to us.json's `opt` and `opt+shift`,
+making those two layers 5 rows while `''` and `shift` stayed at 4. So every
+key shrank to a fifth of the surface and the letters page drew four of them —
+leaving exactly one row of dead space, measured at 145 device px against a
+139 px row (696 / 5).
+
+Fixed in **stevia 0.56.0-8** (`Pixel3Arch` 84adb45): the arrow row is gone
+from us.json, all four layers are 4 rows, keys fill the surface. Built on
+archdev, installed on the phone, screenshot-verified. `terminal.json` keeps
+its arrows — patch 0002 put them *on* the bottom row rather than adding one,
+which is why the terminal layout never had this bug and is the pattern to
+copy if arrows are wanted on the daily layout later.
+
+**The rule this makes concrete:** a row added to any one layer resizes keys
+on all of them. Row counts must stay equal across the four levels unless the
+key-height math is changed first.
+
 ## Connects to
 
 TASK-17 (the original keyboard task — this is its layout-rework