Initial commit: tungsten's memory tree

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.