diff options
Diffstat (limited to 'feedback_lightweight_verification.md')
| -rw-r--r-- | feedback_lightweight_verification.md | 32 |
1 files changed, 32 insertions, 0 deletions
diff --git a/feedback_lightweight_verification.md b/feedback_lightweight_verification.md new file mode 100644 index 0000000..e3c9fe2 --- /dev/null +++ b/feedback_lightweight_verification.md @@ -0,0 +1,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. |