name: mobile-web-parity-uplift
description: Port a large web view to a React Native mobile screen with proportional fidelity, adapting features that don't translate to a glance-view surface.
---
# Mobile Web-Parity Uplift

## When to use
- User asks to "upgrade", "match", or "bring to parity" a mobile screen against an existing web view that is significantly larger (e.g., 200 LOC mobile vs 2000+ LOC web).
- Mobile screen already exists as a minimal stub and needs to mirror the breadth of a richer web counterpart.
- Both surfaces share a backend API/hook layer that can be reused or lightly extended.

## How to apply
1. **Read both files in full first.** Measure the size gap (mobile LOC vs web LOC) — this sets the scope. Do not skim.
2. **Inventory web sections.** List every visual block on the web view (header, summary, per-resource cards, lists, empty states). Build a section-by-section translation table before writing code.
3. **Audit the shared hook/API layer.** Identify any state the web view computes that the mobile hook doesn't yet return. Extend the hook minimally (add fields, tighten poll intervals) rather than duplicating fetch logic in the screen.
4. **Wire focus-based polling.** Use `useFocusEffect` to start/stop polling so the screen doesn't burn battery when backgrounded. Toggle the hook's `enabled` flag.
5. **Translate, don't transliterate.** For each web section, pick the mobile equivalent:
   - SVG arc gauges / sparklines → horizontal progress bars (unless you also port a rolling-history buffer).
   - Animated terminal/log strips → omit; they don't suit a glance surface.
   - Fleet/Local toggles or dense filter controls → show the simpler default; reserve toggles for desktop.
   - Insight/recommendation panels → encode the same thresholds as color on existing bars.
6. **Always include three states:** skeleton loading, empty ("No X Detected" with icon), and error banner. Never ship a screen that renders blank on first paint or on backend error.
7. **Color-code by severity.** Use a single threshold scheme (e.g., green <70%, amber 70–90%, red >90%) consistently across every progress bar so the user learns it once.
8. **Report explicitly what didn't translate.** End the change summary with a "Features from web view not translated" list, with a one-line reason for each omission. This makes the scope decision auditable.

## Rules
- Never reimplement the data layer in the mobile screen — extend the shared hook instead.
- Never silently drop a web section. If it's omitted, it goes in the "not translated" list with a reason.
- Never leave the screen blank on load or error — skeleton, empty, and error states are mandatory.
- Never poll without `useFocusEffect` gating; mobile screens that poll while backgrounded drain battery.
- Always read the entire web source file before mapping sections — partial reads cause missed blocks and parity gaps.
- Always pick mobile-native equivalents (progress bars, stat grids, horizontal scrolls) over porting SVG/canvas widgets unless the supporting state already exists.
- Always color-code severity consistently; mixing schemes between cards defeats the glance-view purpose.