web_frontend homepage still reads GitHub Projects directly, not bd nf-ct5w ← Beads

closed priority 2 task unassigned activesession:011-homepage

Twinned from https://github.com/cfsh/ninefold/issues/1173 by tools/beads/import_github.py's reconcile pass.

Session: TBD

Found live by Aedan: the dashboard homepage (/) still shows GitHub-sourced design-task-panel data, even though T3 (#1105, merged) moved design_docs/tools/status.py's build() onto bd months ago and T4 (#1097/#1100, merged) put every other route (/issue, /board) on Bd().

Root cause

tools/web_frontend/server.py's _serve_index calls fetch_design_task_panels(_recording_gh(gh.repo, gh)) — a completely separate, never-migrated implementation that does its own raw GitHub Projects v2 calls: _project_pointer hunts for the old **Project:** line (superseded by **Beads:** per T3), _live_project calls live_gh.project_view, _status_by_issue calls live_gh.project_item_list — real GraphQL, not bd. The docstring on _live_project explains why it doesn't import status.py: "design 008 §8 deliberately sizes T5/T6 as independent builds off T2, neither importing the other" — that constraint predates T3's bd rewrite and is stale; the right call now is to import and use the already-bd-based status.py, matching every other route in this file.

Fix

- Rewrite fetch_design_task_panels (and delete the now-dead _project_pointer/_PROJECT_LINE_RE/_PROJECT_URL_RE/_live_project/ _status_by_issue/_recording_gh helpers it alone depended on — B12, don't strand dead code) to call design_docs/tools/status.py's build() the same way dev.py designs does, giving it a Bd instance instead of a Gh/LiveGh. - Doc content (title, task table) still needs GitHub's Contents API per design 011's own architecture ("never trust a stale local checkout for a doc's live content") — status.py's build() already does this correctly (fetches content via gh.Gh, status via bd); reuse that, don't reinvent it here. - The open/closed PR lists on the homepage (fetch_open_prs/ fetch_closed_prs) are correctly GitHub-sourced and untouched by this — PRs stay on GitHub forever, per design 011's own scope boundary.

Verification (Aedan's ask)

As a check that this is actually fixed: **the web dashboard should never read Issues from GitHub in the end state** — grep this file after the fix for issue-side gh/github_live calls (project_view, project_item_list, issue_view, issue_list) and confirm none remain reachable from any route. PR-side calls are the only expected survivors.

Files: tools/web_frontend/server.py, its tests.

Dependencies

None.

Comments

No comments.

Add a comment