Commit 25715f22da8054ed9b8374b868ddf0d2e7011d34
1 parent
f701da9d
graphlemon: auto-commit uncommitted changes for 48c56ba7-48f1-489b-9d7a-0b35adcd…
…2c48-main-checkout-drift
Showing
1 changed file
with
27 additions
and
0 deletions
.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` |
| 29 | 29 | query-string (`?key=value`) parsing exists there at all today, so FR-5 ("fix") is really |
| 30 | 30 | "add"; flag that wording precisely if it recurs at SDD/Coder stage (accuracy issue, not a |
| 31 | 31 | contradiction, so it wasn't in-scope for this consistency review). |
| 32 | + | |
| 33 | +**2026-08-07 re-confirmed while planning a Work Graph for the same goal** (nav re-read fresh: | |
| 34 | +`frontend/index.html`'s `<nav>` is still 8 static `<a>`s, no widget). Reconfirmed facts, not | |
| 35 | +yet superseded: | |
| 36 | +- `render()` (app.js:118) is still the single right place to refresh the nav widget — both | |
| 37 | + existing `setCurrentProjectId()` call sites (`mountProjectList`'s "选择" button, app.js:230; | |
| 38 | + `mountProjectSetup`'s create-project success handler, app.js:353) already immediately set | |
| 39 | + `window.location.hash`, which fires `hashchange` → `render()` on its own; no new event | |
| 40 | + wiring needed for "switch project → nav updates". | |
| 41 | +- Precedent for the "no new backend aggregation endpoint" call already exists in shipped code, | |
| 42 | + not just reasoning: `mountBudgetSettings` (app.js ~2423-2429) already does | |
| 43 | + `fetch("/api/tasks?project_id=..&status=blocked_pending_human")` and uses `.length` for a | |
| 44 | + count. Generalizing this to all statuses = one unfiltered `GET /api/tasks?project_id=...` | |
| 45 | + fetch + client-side reduce over `TASK_STATUSES` (app.js:844-847) — single round trip, not 9. | |
| 46 | + `task_query.list_tasks` has no LIMIT/OFFSET anywhere (checked `src/task_query.py`), so | |
| 47 | + "no pagination" is the whole codebase's existing convention, not a gap being introduced here. | |
| 48 | +- New open decision surfaced this pass that the earlier PRD review didn't record: the user's | |
| 49 | + example "done 12 · running 2 · pending 3" implies grouping graphlemon's 10 raw task | |
| 50 | + statuses into ~3-4 display buckets, not a literal 10-number readout — PRD must pick and | |
| 51 | + spell out the bucket→raw-status mapping explicitly (product decision), and must also decide | |
| 52 | + the click target when a bucket maps to >1 raw status, since `task_query.list_tasks`'s | |
| 53 | + `status` param only accepts one value at a time. | |
| 54 | +- `render()`'s nav `a.active` toggle (app.js:159-161) and its `routes[hash]`/regex-table | |
| 55 | + lookup both do exact/full-hash matching — once a nav link produces `#/tasks?status=done`, | |
| 56 | + `render()` must split path from query *before* route dispatch, or the lookup breaks. This is | |
| 57 | + a required `render()` change, called out explicitly so SDD doesn't file it as a | |
| 58 | + frontend-only add unrelated to routing. | ... | ... |