--- name: feedback-lightweight-verification description: "Keep emulator/live verification lightweight — don't burn turns on repeated screenshot-scroll navigation to visually confirm something already proven at the data/HTML level" metadata: node_type: memory type: feedback originSessionId: 375c858e-e817-41e8-a076-7920d22eab2b --- Told directly: "your recent development method has been extremely token-heavy, let's aim for lightweight approaches when possible." This followed a stretch of repeated screenshot-then-swipe-then-screenshot cycles trying to visually scroll to a specific spot in a long WebView article (to eyeball a YouTube thumbnail fix), overshooting back and forth many times because scroll-gesture distance on the emulator is hard to predict from a screenshot. **Why:** visual confirmation of something already verified structurally (e.g. checking the extracted HTML in the DB shows the right `
/
` markup) is often redundant — the rendering path was already proven reliable elsewhere in the session. Burning many screenshot round-trips to *also* see it on screen adds cost without adding real confidence. **How to apply:** for [[project_feedreader]] and [[project_feedreader_emulator]] work: - Prefer one targeted check over an exploratory loop. If a screenshot doesn't land where expected, don't keep guessing coordinates — either use `uiautomator dump` for exact bounds (already noted in project_feedreader_emulator.md) or fall back to DB/HTML-level verification and move on. - Structural proof (DB content, grep on extracted HTML, a build succeeding) is often sufficient evidence on its own — a live screenshot is a nice-to-have confirmation, not always required, especially for a rendering path (e.g. plain `` display) already exercised successfully earlier in the same session. - When something isn't behaving as expected in the UI (e.g. taps landing on the wrong element), don't retry many times with slightly adjusted coordinates -- stop, reconsider the approach (uiautomator dump, or skip to code-level verification) rather than iterating blindly.