Fix #48: issue list newest-first ordering #58

Merged

crueber merged 2 commits from fix/issue-48 into main

2026-09-04 21:39:25 +00:00

crueber commented

2026-09-04 21:35:27 +00:00

Owner

Fixes #48 — the combined open+closed list showed activity order (#2,#3,#1) instead of newest-first by number (#3,#2,#1).

Root cause (server-side, not client merge): ListIssues merged index open[] + closed_recent[] then sorted newest-activity-first (sortCards: updated_at desc). Any comment/edit on an older issue reordered the whole list. Frontend renders server order verbatim, so no client bug — fixed at the render layer.

Change:

internal/issues: new sortCardsByNum (num desc); ListIssues uses it on all three render paths (index-complete, LIST-degraded, LIST-merged). Index storage unchanged (still activity-first per 02 S2). windowCards cursor stays positional in display order.
internal/pulls: identical fix in ListPRs (same combined-list pattern found there) + sortCardsByNum; index storage unchanged.
web: new lib/sort.js sortByNumDesc applied at display in Issues.jsx + Pulls.jsx (stale cache/SSE refetch safety net, idempotent with backend).
Docs (law 12): Decisions amendments in docs/features/02_issues.md and docs/features/03_pull_requests.md stating lists render number-desc while the index object stays activity-first.

Tests:

Go: TestListIssuesNumberDesc, TestListPRsNumberDesc — fail pre-fix ([2 1 3]-class order), pass post-fix. Full -race suites green; cover 96.2% issues / 97.8% pulls (gate holds).
JS: web/test/unit/sort-num.test.js (3 tests); full node suite 245/245 green.
Browser (headless Chrome CDP vs scratch build, mixed open/closed repo): list reads #3 OPEN, #2 CLOSED, #1 OPEN in both themes; screenshots in PR worktree /tmp (wt48-dark/light.png). Two console 404s observed are pre-existing repo-layout probes (GET {o}/{r}/api/tasks from TasksOverlay, GET {o}/{r}/api summary) in untouched files — they fire on any repo page and the list renders regardless; out of scope, not introduced here.
No new deps.

Fixes #48 — the combined open+closed list showed activity order (#2,#3,#1) instead of newest-first by number (#3,#2,#1). Root cause (server-side, not client merge): ListIssues merged index open[] + closed_recent[] then sorted newest-activity-first (sortCards: updated_at desc). Any comment/edit on an older issue reordered the whole list. Frontend renders server order verbatim, so no client bug — fixed at the render layer. Change: - internal/issues: new sortCardsByNum (num desc); ListIssues uses it on all three render paths (index-complete, LIST-degraded, LIST-merged). Index storage unchanged (still activity-first per 02 S2). windowCards cursor stays positional in display order. - internal/pulls: identical fix in ListPRs (same combined-list pattern found there) + sortCardsByNum; index storage unchanged. - web: new lib/sort.js sortByNumDesc applied at display in Issues.jsx + Pulls.jsx (stale cache/SSE refetch safety net, idempotent with backend). - Docs (law 12): Decisions amendments in docs/features/02_issues.md and docs/features/03_pull_requests.md stating lists render number-desc while the index object stays activity-first. Tests: - Go: TestListIssuesNumberDesc, TestListPRsNumberDesc — fail pre-fix ([2 1 3]-class order), pass post-fix. Full -race suites green; cover 96.2% issues / 97.8% pulls (gate holds). - JS: web/test/unit/sort-num.test.js (3 tests); full node suite 245/245 green. - Browser (headless Chrome CDP vs scratch build, mixed open/closed repo): list reads #3 OPEN, #2 CLOSED, #1 OPEN in both themes; screenshots in PR worktree /tmp (wt48-dark/light.png). Two console 404s observed are pre-existing repo-layout probes (GET {o}/{r}/api/tasks from TasksOverlay, GET {o}/{r}/api summary) in untouched files — they fire on any repo page and the list renders regardless; out of scope, not introduced here. - No new deps.

crueber added 1 commit

2026-09-04 21:35:27 +00:00

Fix #48 : issue/PR lists render newest-first by number descending a4827d1e31

ListIssues/ListPRs merged open+closed_recent and sorted newest-activity-
first, so the combined list showed e.g. #2,#3,#1. Render now re-sorts the
merged pool by num desc under every filter; the index object itself stays
newest-activity-first per 02 S2, and the SPA re-sorts at display
(web/src/lib/sort.js) so stale caches/SSE refetches agree.

Docs: Decisions amendments in 02_issues.md (render number-desc, cursor
positional in display order) and 03_pull_requests.md (same rule for PRs).

Tests: TestListIssuesNumberDesc + TestListPRsNumberDesc (fail pre-fix with
[2 1 3]-class order, pass post-fix); web/test/unit/sort-num.test.js.

crueber referenced this pull request

2026-09-04 21:35:30 +00:00

Issue order is not sequential #48

crueber referenced this pull request from a commit

2026-09-04 21:38:59 +00:00

Review #58: ListFilter.Sort comment no longer claims updated default

crueber added 1 commit

2026-09-04 21:38:59 +00:00

Review #58 : ListFilter.Sort comment no longer claims updated default c7122da19e

Render is always number-descending per issue #48; sort= is parsed and
validated but does not change the order. The old '(default)' note
disagreed with the code (law 12).

crueber referenced this pull request

2026-09-04 21:39:11 +00:00

Issue order is not sequential #48

crueber merged commit 8d3574ca16 into main

2026-09-04 21:39:25 +00:00

crueber referenced this pull request from a commit

2026-09-04 21:39:26 +00:00

Merge pull request 'Fix #48: issue list newest-first ordering' (#58) from fix/issue-48 into main

crueber referenced this pull request

2026-09-04 21:39:26 +00:00

Issue order is not sequential #48