# Backlog

Durable backlog for cross-session work.

Purpose:
- keep loosely defined ideas in one place
- refine them over time without losing context
- track status before they become concrete execution tasks
- give future chats one stable source of truth for pre-task work

## How to use

Workflow:
1. capture raw idea fast
2. clarify goal / payoff / constraints
3. split into next concrete step
4. only then move into `TASKS.md`, active implementation docs, or session todo work

Status meanings:
- `idea`: rough, not yet shaped
- `researching`: being explored
- `ready`: clear enough to execute
- `blocked`: waiting on info/access/decision
- `done`: completed or superseded

Fields:
- `id`: stable handle for future chats
- `status`: current maturity
- `goal`: real outcome wanted
- `why`: payoff / business value
- `open_questions`: what still blocks clarity
- `next_step`: single best next move
- `notes`: evidence, links, caveats

---

## Items

### BB-005 - Apply BB-002 patterns in Ballbox
- status: `idea`
- goal: apply the documented BB-002 offline/navigation patterns in `~/ballbox`, tied to the recent accessibility work there
- why: keeps Ballbox improvements aligned with the shared pattern set and folds this work into the accessibility/navigation effort already started
- open_questions:
  - which existing Ballbox accessibility workstream or doc should be the main anchor for this rollout?
  - which Ballbox surface should be first: docs/blog/public marketing vs authenticated admin/player?
  - which parts of BB-002 are worth shipping in Ballbox first beyond accessibility-related navigation behavior?
- next_step:
  - keep parked until BB-002 documentation is solid enough to use as the implementation source of truth
- notes:
  - user asked to track this separately from BB-002
  - associate with the recently started Ballbox accessibility work when that thread is picked back up

### BB-004 - Self-hosted RSS/feed system for offline reading
- status: `researching`
- goal: build a feed/RSS reading system on this server to replace the current app and support preloaded offline reading
- why: better control, better offline use on flights, and integration with local portal/nginx improvements
- open_questions:
  - is the current daily PDF archive enough as the primary phone/offline reader?
  - is any richer UX worth adding beyond a simple dated PDF archive?
- next_step:
  - treat `rss-offline` as the primary experiment, measure whether the daily PDF workflow is sufficient, and only then decide whether to keep evolving it or fold feed management into it
- notes:
  - should be evaluated together with BB-003 service-worker / offline-cache strategy
  - constraint: no paid options
  - current primary path is `/rss-offline/`: static PDF archive built from server-fetched local article copies, with a service worker under the same prefix
  - reason for pivot: cross-origin mobile browser caching of external blog pages was too unreliable, even with prefetch attempts
  - current generated artifacts and limits are documented in `pi-config/docs/bb-004-rss-offline-status-2026-05-14.md`
  - minimal bar that already beats the current app: feed subscriptions/import, background refresh, unread/read state, folders/tags optional, article list + readable article view, save-for-offline/preload, cached visited articles, mobile-friendly web UI, multi-device sync through server state
  - nice-to-haves later: full-text extraction, search, saved highlights, send-to-reader/share target, email/newsletter ingestion