New frontend/e2e/fleet-ops-correction.spec.ts covers section 12 of the brief:
branding (Fleet Ops visible, no MobilityOps/PoC leaks, in all 3 languages), the
language switcher persisting across reload, the full status-recommendation flow
(non-mutating preview, exact-status confirm button, manual review with no apply
button, stale-token rejection), MO-016 order independence at the browser level, the
knowledge base grounding the exact brief question in its own language, and localized
audit/automation content with raw codes only under "Technical details".
Writing these tests surfaced two real bugs:
- DataQualityIssueDetail.tsx conflated "no conflict" with "manual review required"
because both carry safe_to_apply: false (a no_conflict recommendation has nothing to
apply, so it's trivially "not safe to apply" without being unsafe). This showed a
false "manual review required" panel for MO-016 after its overlap was resolved,
instead of the correct "no change needed" state. Fixed by keying the branch on
manual_review_required alone.
- test_mo_016_status_conflict_recommendation_is_order_independent never actually
exercised MO-016: _first_open() returned whichever vehicle_status_conflict issue was
most recently detected (there are ~14 open after a reset), not necessarily
DQ-DEMO-STATUS, so the test's MO-016 assertions were trivially true regardless of
what the code under test did. Added _first_open_for_vehicle() and rewrote the test
to explicitly target MO-016, and to assert the behaviour order independence actually
requires: resolving the overlap first must correctly leave nothing to apply (the
vehicle already matches the facts), not literally the same end status as resolving
the conflict first.
151 backend tests, Ruff, mypy green; full 108-test Playwright suite green (two
transient, non-reproducible flakes confirmed to pass in isolation and unrelated to
this change).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
