Record what the step 1 review found

The pre-submit review of the six one-ask commits found a scroll placing
content that fits into a window-length box rather than its viewport, and
three comments still calling window lengths frame lengths.

docs/LAYOUT_LOG.md

@@ -130,6 +130,51 @@ did not bring it back. Either an edit fixed it that I could not identify, or
 the rig is not as deterministic as it looks. If a seed ever fails once and
 not again, suspect the second.
 
+## What the step 1 review found (worker, 2026-09-19)
+
+The pre-submit review of the six commits `4328eac..a30971e` as one diff.
+Build, lint and every fuzzer were already clean, and the review still found
+one wrong layout.
+
+- **A scroll placed content that fits into a box the length of the
+  window.** `Scroll` asked for its content box as
+  `Place::Fill(Part::From(content))` with `content` defaulting to
+  `UiSpan::FULL`, and only replaced it when the content is scrolled or
+  longer than the viewport. A `Part::From` span is in window lengths, so
+  `UiSpan::FULL` -- `rel 0` to `rel 1` -- is the whole window rather than the
+  whole box. The 300 px viewport of a 400 px window put its content in a
+  400 px box anchored at the viewport's start: a 50 px child centred at
+  275..325 where #18 has it at 225..275. It is the common case, not a corner
+  one -- any content shorter than its viewport takes it.
+
+  Nothing in the repository caught it. The warm/cold oracle cannot: both
+  sides are wrong the same way, and it compares warm with cold rather than
+  with what is right. The render set cannot either: every scroll in
+  `minimal`, `tabs`, `random`, `text` and `view` is either window-length on
+  its axis or has content longer than its viewport, so all five are
+  byte-identical before and after the fix. Only a hand-written expectation
+  found it, which is the argument for keeping some.
+
+  Fixed at `e8a5792` by saying the whole of a box as `Part::All`, the one
+  expression that cannot mean anything else -- and, being the place the
+  child was already asked in, one that makes the placement a no-op. Pinned
+  by `scroll::content_that_fits_is_placed_in_the_viewport_and_not_in_the_window`.
+
+- **`Part::From`'s own documentation still called its spans frame lengths**,
+  which is what the scroll above read them as, and two comments in
+  `in_parent` still described the window ranges as frame ranges converted
+  through a frame. Corrected at `a888717`. When a unit changes, the comments
+  naming the old one are not decoration: this one cost a layout defect.
+
+Checks re-run at `a888717`: `cargo fmt --all --check`, clippy with and
+without `layout-diagnostics`, 123 suite tests, 20 core, 11 generated, the
+400-seed depth-5 shrinker over all sixteen cases (73 s, 34,488 widgets), the
+1000-seed depth-6 oracle (187 s), the 2000-seed depth-4 scan (347 s, 82,203
+widgets), all five renders at 1920x1200, the `tabs` replay, and a live
+resize of `random` to 900x1200 against a cold render there. The renderer was
+confirmed as Venus on the host's RX 7900 XT rather than llvmpipe. Every
+render is byte-identical to the same render at `a30971e`.
+
 ## What the one-ask protocol found (planner, 2026-09-18, third session)
 
 Branch `wip/one-ask` at `3091fb8` over `4328eac`. The change is described in