Hazard review

• scenarioreviewedboundaryedge_case

  Worst case: the card ends exactly on a row boundary, so the last visible row is fully drawn and a user believes the list is complete - the fold affordance silently vanishes and rows below stay undiscovered; the never-comes-out-even rule and the 70-percent panel cap are the two protections, and the overflow/exact-fit partition plus the cap arithmetic are the boundary pair. boundary: every-row-fits versus rows-overflow flips the height source (full list height versus folded height), and the frozen-top ceiling once a search pins the card is the second cap boundary. edge_case: mixed base and detail row heights (search narrowing or dmenu subtext) make the fold land at a different row for the same row count, and submenu drilling reusing the starting ceiling are the witnessed corners - all display-only misestimates graded low, no state or data consequence. Catalog 1.11.0 re-review: input_domain not applicable, it reads no external text input. concurrency_scale not applicable, view state recomputed from the current rows on each UI event: no process, timer or lock, and events are handled one at a time.

• propertyrevieweddeterminism

  foldedListHeight and availableRowsHeight are pure functions of totals, available, and the panel geometry: the same menu content in the same layout state computes the same card height every open, so the fold position is stable rather than flickering between opens.

• structuralnot applicable

  Integer/real arithmetic over panel dimensions bounded by physical display size; no overflow-relevant range, no memory, pointer, or encoding surface.

• domainnot applicable

  Pure layout arithmetic inside the menu surface; no IPC payload, file, network, crypto, or privilege input participates in the fold computation.