[devin-ai-integration]

Change

Test-only. Removes the capture race behind the intermittent requirement hierarchy and declared satisfaction in {light,dark} at 768 failures (requirements-{light,dark}-768.png, ~1,800–1,900 px, the whole requirement diagram shifted by a fraction of a pixel). No application code, baseline PNG or diff threshold changes.

Cause. The diagram fits itself once, two animation frames after its nodes are measured (FitOnReady in Diagram.tsx), at whatever size the canvas has at that moment. The scenario only waited for the requirement card to be visible and then called page.setViewportSize({ width: 768 }). Usually the fit had already run on the 1440 px layout; occasionally the resize won, the pending fit was rescheduled and ran on the narrow canvas instead:

	camera after the resize	after zoomRequirementForReading	after centerRequirementCard
fit before resize (baseline)	0.392665 @ 37.288, 169.073	0.803755 @ -204.25, 41.424	-295.25, -228.576
fit after resize	0.207714 @ 19.5074, 195.484	0.803755 @ -693.548, -78.6014	-295.548, -228.601

zoomRequirementForReading normalizes the scale through the maximum-zoom endpoint, but not the pan. centerRequirementCard then pans with a real middle-button drag, which moves by whole pixels, so the different sub-pixel remainder (.25 vs .548) survives into the screenshot. The drag helper itself is deterministic; its input was not.

Fix. consumeRequirementAutomaticFit (tests/e2e/requirements-support.ts) runs before the resize. The pending fit is not observable on its own (it lands on the same camera React Flow's initial fitView already produced), so the helper round-trips the editor mode with the visible Split and Diagram buttons: each mode change re-arms the fit, Split must move the camera away from the full-canvas fit and Diagram must bring it back to exactly that camera. Once that retrying assertion holds, the one-shot fit has run at the 1440 px layout and the later resize cannot refit. The comment on zoomRequirementForReading that claimed independence from the initial fit is corrected to scale-only.

PR #39 should be re-run after this lands; its remaining requirements-dark-768.png failure is this race.

Evidence

Node 26.3.1, Playwright's bundled Chromium, production build with the real pinned engines, Linux.

• Before (unchanged develop): npm run test:e2e -- --project=visual --grep 'requirement hierarchy' --repeat-each=5 and a second run with --repeat-each=6 of the 768 pair: 7 of 22 narrow captures took the late-fit path (1,814 px dark / 1,900 px light against the baseline); the camera log above is from those runs.
• After: 48 narrow captures across three runs (--grep 'requirement hierarchy' --repeat-each=6, --grep 'requirement hierarchy.*768' --repeat-each=15, and the whole visual project with --repeat-each=3): every one is on the baseline camera, and the requirements-overview-* captures taken after the mode round trip are unchanged from before the fix. In the whole-project run each of the 89 scenarios gave the same result in all three repeats.
• Hosted Validate run on this PR: 17 critical scenarios and all 89 visual comparisons passed against the checked-in baselines.
• npm run check: passed (formatting, architecture, typecheck, unit and script tests).

Local limitation: this machine's glyph antialiasing differs from the baseline runner by a constant 14 px (28 px for the light overview) of isolated text pixels in every requirement capture, before and after the change, so local runs establish the camera and capture-to-capture stability, not an exact baseline match. The hosted visual run on this PR is the exact comparison.

Compatibility

None. Tests only; no source/model/view, saved-format, dependency or engine-profile effect.

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring