[P1] Build a reproducible bug inventory and critical regression matrix

[fxbin]

Parent: #2

Why

The project currently contains many interacting subsystems (source sync, scheduler, analysis jobs, Today Picks, trend ingestion, auth, LLM, DuckDB/OLTP fallback and frontend state). Fixing bugs ad hoc without a shared reproduction contract makes regressions and duplicate fixes likely.

WorkOrder

Lead: QA / BA
Contributors: Frontend, Backend, Architect

Create a single bug/reproduction matrix before broad feature iteration.

Required dimensions

For every confirmed defect capture:

• user-visible symptom
• environment and preconditions
• exact reproduction steps
• expected vs actual result
• API / frontend / DB / scheduler boundaries touched
• logs / request ID / job ID where applicable
• severity: P0/P1/P2/P3
• reproducibility: always / intermittent / environment-specific
• regression test candidate
• owning implementation issue

Critical flow baseline

At minimum cover:

1. login/session/OAuth
2. source creation → scheduled/manual sync → content persisted
3. extraction/enrichment/classification
4. analysis job enqueue → recovery/dispatch → completion/failure
5. Today Picks query and marking/feedback paths
6. trending synchronization/snapshots
7. DuckDB unavailable → OLTP fallback
8. startup migration → scheduler start → graceful shutdown
9. frontend list/detail/loading/error/empty states for primary screens

Acceptance criteria

• Matrix is committed under planning/2026-08-stabilization/quality/.
• Every P0/P1 row has a dedicated GitHub issue and acceptance criteria.
• Intermittent issues include observability evidence requirements.
• Critical flows have smoke/regression ownership.
• No row is closed solely because it could not be reproduced once.

Non-goal

This issue inventories and contracts defects; individual product fixes belong in linked implementation issues.