feedback_lightweight_verification.md


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

---
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 `<figure>/<figcaption>` 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 `<img>` 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.