mirror of
https://github.com/vitorpamplona/amethyst.git
synced 2026-10-06 03:38:23 +00:00
Vitor PamplonaandClaude Opus 5
808762d574
Two defects found testing the screens on a Pixel 9 emulator against the caches other clients have already published. 1. Four of the five tabs were unreachable. GeocachesScreen put its SecondaryScrollableTabRow first in the *content* of DisappearingScaffold, and that content is drawn from the top of the window, behind the bar — so the row landed under the status bar. uiautomator put it at y=36..89 with "Mine" clipped to 36px at the screen edge; nothing rendered between the status bar and the title, and tapping where the tabs claimed to be did nothing, so Map, Hunts, Finds and Mine could not be opened at all. The row moves into topBar, which is where DiscoverScreen already stacks its tabs. After the change the same dump reads y=309..362, below the title bar, and the tabs are visible and selectable. 2. A cache never asked for its own finds. A NIP-CC found log hangs off the listing by a lowercase `a` — the tag the engagement watcher already queries — but kind 7516 was in none of its kind lists, so the cache screen asked for every reaction to a listing and never for the logs that are the point of the screen. "Treasure of the castle" reads "No one has logged this cache yet" while nos.lol, a relay the account is connected to, holds three 7516s for it. Note what this does and does not fix: the client now *asks*. Whether the logs arrive still depends on overlap, because the watcher asks the author's inbox relays and the relays the listing itself was seen on — a log written by a finder to their own outbox and nowhere else is still invisible. That is a relay-coverage question, not a filter one, and it is worth a separate look. The new test asserts the address watcher asks for 7516, and it has teeth: dropping the kind from the list again fails it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>