From 25715f22da8054ed9b8374b868ddf0d2e7011d34 Mon Sep 17 00:00:00 2001
From: graphlemon <graphlemon@localhost>
Date: Fri, 7 Aug 2026 02:23:23 +0800
Subject: [PATCH] graphlemon: auto-commit uncommitted changes for 48c56ba7-48f1-489b-9d7a-0b35adcd2c48-main-checkout-drift

---
 .claude/agent-memory/planner/project_nav_current_project_context_prd.md | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+), 0 deletions(-)

diff --git a/.claude/agent-memory/planner/project_nav_current_project_context_prd.md b/.claude/agent-memory/planner/project_nav_current_project_context_prd.md
index e41407c..cdd80f0 100644
--- a/.claude/agent-memory/planner/project_nav_current_project_context_prd.md
+++ b/.claude/agent-memory/planner/project_nav_current_project_context_prd.md
@@ -29,3 +29,30 @@ fills, not a contradiction. If this PRD proceeds to SDD stage, `frontend/app.js`
 query-string (`?key=value`) parsing exists there at all today, so FR-5 ("fix") is really
 "add"; flag that wording precisely if it recurs at SDD/Coder stage (accuracy issue, not a
 contradiction, so it wasn't in-scope for this consistency review).
+
+**2026-08-07 re-confirmed while planning a Work Graph for the same goal** (nav re-read fresh:
+`frontend/index.html`'s `<nav>` is still 8 static `<a>`s, no widget). Reconfirmed facts, not
+yet superseded:
+- `render()` (app.js:118) is still the single right place to refresh the nav widget — both
+  existing `setCurrentProjectId()` call sites (`mountProjectList`'s "选择" button, app.js:230;
+  `mountProjectSetup`'s create-project success handler, app.js:353) already immediately set
+  `window.location.hash`, which fires `hashchange` → `render()` on its own; no new event
+  wiring needed for "switch project → nav updates".
+- Precedent for the "no new backend aggregation endpoint" call already exists in shipped code,
+  not just reasoning: `mountBudgetSettings` (app.js ~2423-2429) already does
+  `fetch("/api/tasks?project_id=..&status=blocked_pending_human")` and uses `.length` for a
+  count. Generalizing this to all statuses = one unfiltered `GET /api/tasks?project_id=...`
+  fetch + client-side reduce over `TASK_STATUSES` (app.js:844-847) — single round trip, not 9.
+  `task_query.list_tasks` has no LIMIT/OFFSET anywhere (checked `src/task_query.py`), so
+  "no pagination" is the whole codebase's existing convention, not a gap being introduced here.
+- New open decision surfaced this pass that the earlier PRD review didn't record: the user's
+  example "done 12 · running 2 · pending 3" implies grouping graphlemon's 10 raw task
+  statuses into ~3-4 display buckets, not a literal 10-number readout — PRD must pick and
+  spell out the bucket→raw-status mapping explicitly (product decision), and must also decide
+  the click target when a bucket maps to >1 raw status, since `task_query.list_tasks`'s
+  `status` param only accepts one value at a time.
+- `render()`'s nav `a.active` toggle (app.js:159-161) and its `routes[hash]`/regex-table
+  lookup both do exact/full-hash matching — once a nav link produces `#/tasks?status=done`,
+  `render()` must split path from query *before* route dispatch, or the lookup breaks. This is
+  a required `render()` change, called out explicitly so SDD doesn't file it as a
+  frontend-only add unrelated to routing.
--
libgit2 0.21.4