Status update (2026-07-20): P5 (Discovery Inbox) is shipped, not future work. This issue is retained as the living roadmap tracker for the discovery line and now points at what actually comes next.
P5 — Discovery Inbox (shipped ✅)
P5.0–P5.7 are complete and hosted-validated (PR #35, 2026-06-25): manual candidate intake, GitHub URL normalization + resolution, dedupe against stars.json by node_id, deterministic candidate artifacts + verify, the dashboard Discovery Inbox view, and the manual workflow_dispatch PR flow. Contract: docs/P5-discovery-inbox-spec.md.
What P5 deliberately left out — now the next step
The inbox exists but is fed by exactly one source: a manual config/discovery-inbox.yaml. The DiscoverySource.kind union already reserves future-telegram | future-youtube | future-web as scaffolding, but no automated source is wired yet.
P6 — Discovery sources (next, in design)
P6 adds automated discovery sources that feed the existing inbox, under the same invariants the inbox already enforces: deterministic, repo-owned, PR-gated (never a direct push to main), fail-soft in the dashboard, no central key custody, and human-review-first.
- First source: a Web/RSS watcher — easiest to give deterministic fixtures, lowest token/permission footprint.
- Telegram comes last (identity, private groups, bot-token custody, message edit/delete, privacy edges).
- YouTube sits in between (API quota, channel identity, Shorts/live/duplicate rules).
The P6 spec/ADR is being written and reviewed together with the trust-boundary review in #34 before any watcher implementation begins.
Open questions (still welcome): candidate-card fields, which filters matter, the status lifecycle (candidate / dismissed / promoted), whether source provenance is visible in the dashboard, and whether dismissed repos stay in history.
Non-goals (still deferred)
auto-star, AI deciding what to star, an always-on server, a central backend or shared service key, a browser extension, a GitHub OAuth app.
Status update (2026-07-20): P5 (Discovery Inbox) is shipped, not future work. This issue is retained as the living roadmap tracker for the discovery line and now points at what actually comes next.
P5 — Discovery Inbox (shipped ✅)
P5.0–P5.7 are complete and hosted-validated (PR #35, 2026-06-25): manual candidate intake, GitHub URL normalization + resolution, dedupe against
stars.jsonbynode_id, deterministic candidate artifacts +verify, the dashboard Discovery Inbox view, and the manualworkflow_dispatchPR flow. Contract:docs/P5-discovery-inbox-spec.md.What P5 deliberately left out — now the next step
The inbox exists but is fed by exactly one source: a manual
config/discovery-inbox.yaml. TheDiscoverySource.kindunion already reservesfuture-telegram | future-youtube | future-webas scaffolding, but no automated source is wired yet.P6 — Discovery sources (next, in design)
P6 adds automated discovery sources that feed the existing inbox, under the same invariants the inbox already enforces: deterministic, repo-owned, PR-gated (never a direct push to
main), fail-soft in the dashboard, no central key custody, and human-review-first.The P6 spec/ADR is being written and reviewed together with the trust-boundary review in #34 before any watcher implementation begins.
Open questions (still welcome): candidate-card fields, which filters matter, the status lifecycle (
candidate/dismissed/promoted), whether source provenance is visible in the dashboard, and whether dismissed repos stay in history.Non-goals (still deferred)
auto-star, AI deciding what to star, an always-on server, a central backend or shared service key, a browser extension, a GitHub OAuth app.