# 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).