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,3 +29,30 @@ fills, not a contradiction. If this PRD proceeds to SDD stage, `frontend/app.js` | ||
| 29 | query-string (`?key=value`) parsing exists there at all today, so FR-5 ("fix") is really | 29 | query-string (`?key=value`) parsing exists there at all today, so FR-5 ("fix") is really |
| 30 | "add"; flag that wording precisely if it recurs at SDD/Coder stage (accuracy issue, not a | 30 | "add"; flag that wording precisely if it recurs at SDD/Coder stage (accuracy issue, not a |
| 31 | contradiction, so it wasn't in-scope for this consistency review). | 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. |