Skip to content

Tier deferrals (manual passes owed)

Acceptance criteria that no automated tier in this repository can physically observe. Each is registered here with a named owner and a status; a PENDING entry does not block a merge, but it does mean a human owes a manual pass that nothing will fail if they skip.

Source: docs/tier-deferrals/*.md.

PASS-385 — a retracting URL bar leaves no band under the sheet

One deferred acceptance criterion from PASS-385 (Sign-in overscroll exposes the theme surface behind the fixed blue/white front door — give the app its own scroll container). Every other criterion in that story is gated by a test that reds under a named revert; this is the only one no available tier can observe.

  • Criterion:

Scenario: A retracting URL bar leaves no band under the sheet Given the sign-in content is shorter than the viewport And the mobile browser's URL bar is visible When the student scrolls and the URL bar retracts Then the sheet's bottom edge stays flush with the bottom of the viewport throughout And no band of any third colour appears between the sheet and the bottom of the viewport

  • Unobservable because: the criterion is about the divergence between the small viewport (100svh, URL bar showing) and the large viewport (100lvh, URL bar retracted), and about the live transition between them. Headless Chromium — the only browser tier this repository has — renders no browser chrome at all, so 100svh, 100lvh and 100dvh all resolve to the same number and there is no bar to retract. The scenario's own binding (test_app_shell_scroll_container_bdd.py, step "the mobile browser's URL bar is visible") probes those two units at runtime and fails on their equality, which is what the deferral rests on: not an opinion that the test is hard to write, but a measured fact about what this browser can produce. Playwright's set_viewport_size does not substitute — it resizes the layout viewport, so svh and lvh simply both change to the new value and stay equal.

  • Observing tier: a real mobile browser on a real handset, with visible chrome that retracts on scroll — Safari on iOS and Chrome on Android are the two that matter for this app's students. Per CLAUDE.md's mobile-first rule and PASS-385's own VERIFICATION section: 360px, 390px and 430px, in both a light and a dark semester theme, with the URL bar cycled.

  • Owner: Anthony Graca

  • Status: PENDING

  • Evidence: the owner will open / (sign-in) on a physical iOS Safari and a physical Android Chrome at each of the three widths, in the csub and harry-potter themes, scroll to make the URL bar retract and then reverse to bring it back, and record for each combination whether any band of a colour other than the sheet's #ffffff appears between the bottom of the sheet and the bottom of the viewport at any point during the transition — including mid-animation, which is where a dvh-versus-container mismatch shows most clearly. Screen recordings, not stills, since the criterion says "throughout". The recorded result replaces Status above with PASSED <ISO date> or FAILED <ISO date>.

What is already gated, and what this does not excuse

The app-shell change that this criterion is about is gated, twice over, by tests that do red under a revert:

  • app_shell_scroll_container.feature scenario 8 fails if any full-height screen is sized in a viewport unit while #root is sized by inset: 0 — which is the structural cause of the band. Reverting one route's min-height: 100% to 100dvh reds it.
  • Scenarios 1, 2, 3 and 7 drive a real compositor with elastic overscroll on and read the resulting pixels, so the general claim "no gesture uncovers the page canvas at either edge" is measured rather than argued.

What remains unobserved is narrower than the scenario text suggests: whether a real URL-bar retraction, specifically, can still open a band. The app shell removes the mechanism that produced it (nothing inside #root is sized in a viewport unit any more, and #root itself is inset: 0 on a position: fixed frame), but "the mechanism is gone" is a reading of the code, not an observation of a device, and this file exists so that distinction is not quietly lost.

PENDING does not block the merge. It does mean this story ships with a manual pass owed to a named human, and that no automated tier will notice if that pass is never done. Nothing in the test suite asserts on this file: writing it is what would make such an assertion pass, so it would gate nothing.