# Backlog

## Feed health: recency/frequency tracking + dead-feed detection

**Motivation:** migrating 108 feeds from Inoreader surfaced ~19 feeds the
user had manually flagged "dead?" over there — there's currently no way
for this app to tell that on its own. Want automatic detection instead of
relying on manual tagging carried over from another tool.

**What's needed:**
- Track each feed's normal posting cadence (e.g. median interval between
  the last N articles' `publishedAt` — already stored on `ArticleEntity`,
  no new fetch required, just a read-side computation).
- Surface a "stale" indicator on the feed list when a feed has gone
  quiet for meaningfully longer than *its own* historical cadence — not
  a fixed global threshold. A feed that normally posts yearly shouldn't
  be flagged after 3 quiet months; a feed that normally posts daily
  should be flagged after a couple of quiet weeks.
- Treat "feed URL itself is broken" as a distinct, stronger signal from
  "author's just gone quiet": `FeedEntity.lastError` already records
  fetch failures (404s, parked domains, etc.) — a feed with several
  consecutive failures is a different case than a live, fetchable feed
  that simply has no new posts.

**Rough shape (not yet built):**
- Compute per-feed on read (no new table needed at first): take the last
  N `publishedAt` values for a feed, find the median gap, compare against
  time since the most recent post. Flag if the current gap is some
  multiple (e.g. 3x) of the historical median.
- `FeedListScreen`: a small badge next to the feed row when flagged,
  distinguishing "quiet" (posting-cadence signal) from "broken"
  (`lastError` signal) since they call for different user action (wait
  it out vs. go look for a replacement feed).
- Out of scope for now: any automated "find where the author moved"
  logic — that's a manual research task when a feed's actually declared
  dead, not something to build detection for.

## YouTube embeds

**Motivation:** the reader's WebView runs with JavaScript off (feed/extracted
content never needs it, and it keeps articles from running arbitrary
scripts) — so a YouTube iframe embedded in an article currently just shows
as a broken/blank box instead of a playable video or thumbnail.

**Rough shape (not yet built):** detect a YouTube iframe/embed URL in the
extracted or feed-provided HTML and swap it for a tap-to-play thumbnail
(image + play button) that opens the video in the YouTube app/browser on
tap, rather than trying to make the embed actually play inline (which would
mean turning JS back on for untrusted third-party content).

## Bottom action strip (partially done)

**Done:** swipe-to-next-article dropped entirely (two different attempts at
keeping it from interfering with WebView scrolling both failed to actually
fix the reported jerkiness, and the second broke swipe outright). Replaced
with explicit Previous/Next buttons in a new bottom bar -- no gesture to
disambiguate with scrolling at all now.

**Still open:** the top bar is still crowded (reader-toggle, open-in-browser,
bookmark, Stash, overflow) and top-heavy for one-handed use. Move those
action icons + the overflow menu down into the bottom bar alongside
Previous/Next, and auto-hide both the top and bottom bars together on
scroll (hide on scroll-down, reveal on scroll-up or tap), matching the
common "immersive reading" pattern other reader apps use.

## Scroll jerkiness (still open, root cause unknown)

Reported as "jerky, loses track of my motion." Two theories tried and
ruled out live, not just in code review:
- An orientation-aware Compose gesture detector wrapping the WebView (for
  swipe-to-next-article) -- kept working correctly for paging, but didn't
  fix the reported jerkiness either, so it likely wasn't (only) about
  gesture-arbitration overhead from that detector.
- A passive native OnTouchListener replacing the above -- broke swipe
  outright, reverted, and jerkiness was never re-tested in isolation since
  swipe was still present in that build.

Swipe is now gone entirely (see "Bottom action strip" above), which removes
one whole category of possible interference. Worth a fresh look at whether
scrolling still feels jerky now that nothing above the WebView is doing any
gesture detection at all -- if it still does, the cause is something else
(WebView rendering/compositing itself, the emulator's software rendering
not reflecting real-device feel, etc.), not gesture interception.