From 80527ff84340c85ad707f1cc67f084b7b64d055a Mon Sep 17 00:00:00 2001
From: iris <2+iris@noreply.localhost>
Date: Sun, 13 Sep 2026 23:51:48 -0400
Subject: [PATCH] Reorder: alignment before the chain, and what the chain must
 fix

---
 docs/IRIS_EXTRACTION_HANDOFF.md | 43 ++++++++++++++++++++++-----------
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/docs/IRIS_EXTRACTION_HANDOFF.md b/docs/IRIS_EXTRACTION_HANDOFF.md
index 3e493c1..0f13388 100644
--- a/docs/IRIS_EXTRACTION_HANDOFF.md
+++ b/docs/IRIS_EXTRACTION_HANDOFF.md
@@ -111,23 +111,38 @@ today's `Len` and let the dp slice follow, rather than pulling both in at once.
 
 Still in the target, roughly in dependency order:
 
+- **Built-in alignment, and probably size**, directly after #16 and before the
+  position chain: the chain is an optimisation, this is behaviour. A child of a
+  span is handed the full extent on the ortho axis, so `.width(rel(0.5))`
+  inside a `Dir::DOWN` span changes what the child reports and not the box it
+  gets. **Do not "fix" that by reading the child's ortho `size_hint`**: a `Pad`
+  between the `SetSize` and the span has no hint of its own, so the declared
+  width silently goes back to filling. It works only when nothing is in the
+  way. Alignment has to belong to the widget rather than be discovered through
+  whatever happens to sit on top of it.
+
+  Two things beyond the bug argue for it. Built-in size removes `SetSize`,
+  and with it the mismatch that made `OnResize`'s old default unsafe -- a
+  wrapper reporting one size while handing its child the whole box. And
+  built-in alignment is what would let `OnResize::Translate` apply to centred
+  content, which otherwise has to say `Redraw` because only its own draw knows
+  where the middle was.
+
+  Size is the harder half: a declared size beside `set_size` is two sources of
+  truth for one thing, so settle what each means before building it.
 - **The position chain** (LAYOUT.md §2): `UiData::move_offsets`, per-primitive
   slot ids and a bounded chain walk in WGSL, so moving a subtree writes one
-  slot instead of every descendant's primitives. Agreed to come directly after
-  #16.
+  slot instead of every descendant's primitives.
+
+  It also has to make `OnResize::Translate` possible, which is the reason that
+  variant does nothing today. `ActiveData::region` is both the box a widget was
+  given and the box its primitives occupy, and `mov` remaps out of it; keeping
+  a drawing at its old size while the box grows leaves the two disagreeing and
+  the next move stretches it. Found by rendering `tabs` against `main`, not by
+  a test. Whatever the chain does, the drawn box and the offered box have to
+  stop being one field.
 - **`UiRenderState` behind `Rc<RefCell<..>>`**, queued by the owner on
-  2026-09-13 as fundamental, and especially so for text. After the two below.
-- **Built-in alignment, and possibly size**, directly after the position
-  chain. A child of a span is handed the full extent on the ortho axis, so
-  `.width(rel(0.5))` inside a `Dir::DOWN` span changes what the child reports
-  and not the box it gets. **Do not "fix" this by reading the child's ortho
-  `size_hint`**: a `Pad` between the `SetSize` and the span has no hint of its
-  own, so the declared width silently goes back to filling. It works only when
-  nothing is in the way, which is the shape of bug the review pass is for.
-  Alignment has to belong to the widget rather than be discovered through
-  whatever happens to sit on top of it. Size is the harder half: a declared
-  size beside `set_size` is two sources of truth for one thing, so settle what
-  each means before building it.
+  2026-09-13 as fundamental, and especially so for text.
 - **`Len`, `LayoutLen` and dp.** The archive splits the type so that `rest` is
   unrepresentable where it is meaningless (a padding), and folds a density in
   at resolve time. 21 files mention `Len`, so it is wide but shallow. After the