fix(ui): scope project session list requests

[shantur]

Summary

• update @opencode-ai/sdk to 1.17.8
• load session lists through client.session.list with scope=project
• use a single high-limit project request because this endpoint does not support cursor pagination

Validation

• npm run typecheck --workspace packages/ui

Notes

• Existing untracked .opencode/package-lock.json was left untouched.

[shantur]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Gatekeeper review for latest PR state.

Request understood: review PR #565 ruthlessly for regressions and implementation quality. I treated this as review-only and made no code changes.

Findings

1. Blocking regression: fetchSessions now hard-caps every project session list at 1,000 items and permanently disables pagination.

packages/ui/src/stores/session-api.ts:L215 clamps all fetches to exactly PROJECT_SESSION_LIST_LIMIT, L293 always calls setSessionPage(..., false, ...), and L333-L335 turns loadMoreSessions into a no-op. That means any project with more than 1,000 sessions silently loses access to older sessions in the sidebar. The old implementation could keep paging through v2.session.list; this PR replaces that with a one-shot request while the newer client.session.list API still exposes start and limit offset-style pagination in the generated SDK types. The better implementation is to preserve incremental loading with start/limit for the project-scoped endpoint, set hasMore based on whether a full page was returned, and have loadMoreSessions request the next offset. If cursor state is no longer applicable, rename/adapt the pagination model instead of leaving a dead cursor API behind.

2. Quality gap: pagination tests are now stale and no longer protect the current behavior.

packages/ui/src/stores/session-pagination.test.ts still verifies cursor storage and append semantics, but the PR removed cursor usage from the fetch path and made loadMoreSessions unreachable. This gives false confidence: tests pass even though the user-facing infinite-scroll behavior was removed. If the intended behavior is one-shot loading, tests should assert that explicitly and justify the 1,000-session cap. If not, add coverage for offset pagination and hasMore calculation.

Validation

npm ci completed successfully.

npm run typecheck --workspace packages/ui passes after installing dependencies from the lockfile.

Initial typecheck before npm ci failed because local dependencies were missing (solid-js, zod, Kobalte, etc.), not because of this PR.

Gatekeeper Decision

Request changes. The SDK migration itself typechecks, and scope: "project" is accepted by the new endpoint, but the current implementation trades the original pagination behavior for an undocumented hard cap. That is a real regression for large projects and should be fixed before merge.

--
Yours,
CodeNomadBot

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/27830530627

Artifacts expire in 7 days.
Artifacts:

• pr-565-0ba27bf40bc35361bcaf6e038b1c3ab9a1d89243-tauri-macos
• pr-565-0ba27bf40bc35361bcaf6e038b1c3ab9a1d89243-tauri-linux
• pr-565-0ba27bf40bc35361bcaf6e038b1c3ab9a1d89243-tauri-windows
• pr-565-0ba27bf40bc35361bcaf6e038b1c3ab9a1d89243-electron-macos
• pr-565-0ba27bf40bc35361bcaf6e038b1c3ab9a1d89243-tauri-macos-arm64
• pr-565-0ba27bf40bc35361bcaf6e038b1c3ab9a1d89243-electron-linux
• pr-565-0ba27bf40bc35361bcaf6e038b1c3ab9a1d89243-electron-windows

[shantur]

@CodeNomadBot

check again

[codenomadbot]

Re-check complete for the latest PR state.

Request understood: re-run the gatekeeper review after the new push. I reviewed this as a strict review-only pass and made no code changes.

Findings

1. Blocking regression remains: the PR still hard-caps project session loading at 1,000 sessions and disables incremental loading.

packages/ui/src/stores/session-list-options.ts:L1-L19 now centralizes the one-shot request and always sends limit: 1000 with scope: "project". packages/ui/src/stores/session-api.ts:L209-L212 always uses that request, L282 always marks the list complete with hasMore=false, and L322-L324 leaves loadMoreSessions as a no-op. This still means projects with more than 1,000 sessions silently lose older sessions from the sidebar.

The new commit adds tests, but they encode the regression rather than fixing it: packages/ui/src/stores/session-pagination.test.ts:L8-L18 explicitly asserts there is no start parameter, and L21-L26 asserts the list is complete after one request. That does not address the concern from the prior review.

Important detail: the installed @opencode-ai/sdk@1.17.8 generated type for client.session.list exposes start?: number and limit?: number (node_modules/@opencode-ai/sdk/dist/v2/gen/sdk.gen.d.ts:L954-L963). So even though cursor pagination is gone, offset-based loading appears available in the SDK surface. The safer implementation is to keep the existing infinite-scroll behavior by tracking the next start offset, requesting limit pages, and setting hasMore based on whether the endpoint returned a full page. If the server truly ignores or rejects start, that needs to be documented with evidence and the UI should not silently cap at 1,000 without a product decision.

2. API cleanup issue: fetchSessions still accepts limit but no longer honors it.

packages/ui/src/stores/session-api.ts:L194 keeps options?: { limit?: number; reset?: boolean }, and existing callers still pass getSessionFetchLimit(...), but the implementation ignores options.limit and always uses PROJECT_SESSION_LIST_LIMIT. This makes the public store API misleading and hides the pagination behavior change from callers.

Validation

npm run typecheck --workspace packages/ui passes.

node --test packages/ui/src/stores/session-pagination.test.ts passes.

Worktree remained clean after validation.

Gatekeeper Decision

Request changes. The new test commit improves coverage only for the chosen one-shot behavior; it does not remove the core regression. Merge should wait until session list loading either preserves incremental access beyond 1,000 sessions or the team explicitly accepts and documents the cap with UI behavior that does not pretend infinite scroll still exists.

--
Yours,
CodeNomadBot

[shantur]

Thanks for the detailed review. I fixed the API cleanup issue in 8ff9ed1 by removing the ignored limit option from fetchSessions, deleting the stale getSessionFetchLimit call path, and updating the close-session refresh caller to pass only reset.

On the remaining pagination concern: I do not think we should implement offset pagination with start for this endpoint. The SDK surface exposes start?: number, but for client.session.list that parameter is a timestamp/start-time filter, not a page offset. Using it as 0, 200, 400... would produce incorrect query semantics rather than reliable incremental loading.

The reason this PR uses client.session.list({ scope: "project", limit: 1000 }) is that it is the SDK endpoint that serializes scope=project and includes worktree sessions. The cursor-paginated client.v2.session.list path serializes /api/session, but the generated SDK does not support scope there, which is why those requests did not include project-scoped worktree sessions.

So the tradeoff in this PR is intentional: restore project/worktree session visibility via the endpoint that supports scope=project, while avoiding fake pagination with a timestamp filter. If we need lossless loading for projects above 1,000 sessions, I think the correct follow-up is an OpenCode API/SDK change that supports both project scope and real pagination (cursor or documented offset) on the same endpoint, rather than using start as pagination in the UI.

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/27833404275

Artifacts expire in 7 days.
Artifacts:

• pr-565-eb9694880f292562e13abb8be50f96136eb324b2-electron-windows
• pr-565-eb9694880f292562e13abb8be50f96136eb324b2-electron-linux

[shantur]

@CodeNomadBot

Again

[codenomadbot]

Re-check complete for the latest PR state at 8ff9ed1a.

Request understood: run the gatekeeper review again after the author response and cleanup commit. I treated this as review-only and made no code changes.

Findings

No blocking findings in the current PR state.

The previous API cleanup issue is fixed. fetchSessions no longer accepts the ignored limit option, the stale getSessionFetchLimit caller path was removed, and the close-session refresh now calls fetchSessions(instanceId, { reset: true }).

I am also withdrawing the earlier recommendation to implement pagination with start unless the OpenCode API explicitly documents it as offset pagination. The generated SDK only proves that start?: number exists; it does not prove offset semantics. The author’s explanation that start is a timestamp/start-time filter is plausible, and using 0, 200, 400... as offsets against a timestamp filter would be a worse bug than the current explicit one-shot request.

Residual Risk

The PR still intentionally caps project-scoped session loading at PROJECT_SESSION_LIST_LIMIT = 1000. That means projects above 1,000 sessions can still miss older sessions. Given the current stated API constraint, I am treating this as an accepted product/API limitation rather than a merge blocker for this PR. The correct longer-term fix is an OpenCode API/SDK endpoint that supports both scope=project and real cursor/offset pagination.

Small non-blocking cleanup opportunity: SESSION_PAGE_SIZE and getSessionNextCursor remain exported from packages/ui/src/stores/session-state.ts but now appear unused after cursor loading was removed. This is dead surface area, not a behavioral blocker.

Validation

npm run typecheck --workspace packages/ui passes.

node --test packages/ui/src/stores/session-pagination.test.ts passes.

Worktree remained clean after validation.

Gatekeeper Decision

Mergeable with known risk. The PR restores project/worktree session visibility through the endpoint that supports scope=project, and the latest cleanup commit removes the misleading ignored limit API. The remaining >1,000-session limitation should be tracked as an API/product follow-up, not blocked here unless the team requires lossless historical session loading before merge.

--
Yours,
CodeNomadBot

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/27833689732

Artifacts expire in 7 days.
Artifacts:

• pr-565-8ff9ed1adbcb3feb540916fc675adb7dfbfc70d8-tauri-macos
• pr-565-8ff9ed1adbcb3feb540916fc675adb7dfbfc70d8-tauri-linux
• pr-565-8ff9ed1adbcb3feb540916fc675adb7dfbfc70d8-tauri-windows
• pr-565-8ff9ed1adbcb3feb540916fc675adb7dfbfc70d8-electron-macos
• pr-565-8ff9ed1adbcb3feb540916fc675adb7dfbfc70d8-tauri-macos-arm64
• pr-565-8ff9ed1adbcb3feb540916fc675adb7dfbfc70d8-electron-windows
• pr-565-8ff9ed1adbcb3feb540916fc675adb7dfbfc70d8-electron-linux

[omercnet]

This scope change is amazing! Thank you! Saves a lot of troubling finding missing sessions