Fixes the red `main`: `planning-browser-e2e.test.ts > places the sole
contextual comment trigger by viewport in embedded and modal Planning`.
**Unclaimed and not a flake.** `check-file-claimed` reported UNCLAIMED,
it is not in the quarantine ledger, it reproduced locally and
deterministically, and it failed identically across three consecutive
Full Suite runs. Quarantine would have been the wrong instrument — that
rule is for flakes, and appeasing a consistent failure buries a real
regression.
## Root cause
`PlanningModeModal.css` sizes dialog Planning as a **full-viewport
sheet**:
```css
.planning-modal:not(.planning-modal--embedded) {
height: 100dvh;
min-height: 100dvh; /* ← beats max-height: 100% */
max-height: 100%;
}
```
That was correct until the modal branch moved **inside
`FloatingWindow`** (`FNXC:ModalTouchGeometry 2026-07-26-14:10`). The
floating host's body is shorter than the viewport — it sits below a
title bar — so the rule now asks the sheet to be *taller than the box
containing it*. `min-height` wins over `max-height`, so the sheet cannot
shrink to its host and overflows.
Measured by walking the ancestor chain at 768×900:
```
BUTTON.btn top=928 h=36 ← 28px past the fold
DIV.planning-actions top=919 h=101
DIV.modal h=900 ← forced to full viewport height
DIV.floating-window__body h=763 sh=900 ← host is 763 tall, content is 900
DIV.floating-window h=765
```
The "Add comment to selection" control needed a scroll to reach —
exactly what the placement case exists to prevent.
## The fix
A scoped override under `.floating-window`, rather than editing the
sheet rule, so Planning rendered **outside** a floating host keeps its
full-viewport sizing:
```css
.floating-window .planning-modal:not(.planning-modal--embedded) {
height: 100%;
min-height: 0;
}
```
## Surface enumeration
Embedded Planning was **never affected** — it is excluded from the sheet
rule, and all four embedded viewports passed throughout. The failure was
modal-only, at every modal viewport (768, 769, 1024, 1280 — it fails
fast at the first).
**No new test.** The existing placement case already asserts this
invariant across **4 viewports × 2 presentations = 8 combinations**,
which is the surface enumeration for this affordance. It was red; it is
now green. Adding a narrower repro-only test would be the anti-pattern
the Fix-the-Invariant rule names.
## A disproven hypothesis, recorded
`min-height: 0` on `.planning-plan-review > .planning-plan-pane` — the
canonical flex-overflow fix, and a pattern used 10+ times in this very
file — **does not fix it**. Measured, not assumed. The overflow is one
level up, at the sheet/host boundary. Noted so the next reader does not
repeat the experiment.
## Verification
```
fix applied Tests 5 passed (5)
fix reverted Tests 1 failed | 4 passed (5) ← the test genuinely holds this fix
fix restored Tests 5 passed (5)
```
Neighbours green: **57 tests across 8 suites** (mobile
footer/bottom-space/pan-containment, terminal keyboard layout,
task-detail tablet width, mission planning modals mobile, mobile
planning input font size, task-detail floating geometry) plus **9**
planning e2e.
Changeset included (`patch`, category `fix`) — this is user-visible
dashboard behaviour.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
efd8454b6c