fix(web): close Issues integration gaps (#25)

[lukemaj]

Problem

The final integration review of #37 found gaps that no component PR owned:

• Issues entry points were gated on pullRequests, so upstream and older servers answered issues.list with Unknown request tag: a permanent error banner and no Load more.
• The side panel showed no linked threads or PRs (a Issues in Chromeria: an Issues view with computed status, linked to threads #25 criterion).
• The palette could not find threads by an Issue linked by hand, by MCP or by Start thread (a Issues in Chromeria: an Issues view with computed status, linked to threads #25 criterion).
• User docs did not cover manual linking.
• Start thread could pick a project on a server without Issue links.

Fix

1. Capability gating. ServerEnvironment advertises issues: true (an optional contract key, like issueLinks). The Issues list reads only those servers, and the sidebar Issues icon, the palette's "Open issues" action and the PRs/Issues switch show only when a connected server has it. One pure helper, environmentIdsWithCapability, backs the list and the issueLinks checks.
2. Side panel. It lists the Issue's linked threads (click opens the thread), then its closing and thread-linked pull requests (state glyph, opens on GitHub).
   • The panel reads these itself for the one Issue, with one threadsForIssues call to every server with issueLinks. So it also works when opened from a thread's link, with the row not loaded.
   • The Issue detail read now carries closing pull requests, from the same fields as the list. Its mapping lives in issueDetailOf.
   • Thread PRs that the list did not read show without a state.
3. Palette lookup by linked Issue. When the query is #N, owner/repo#N or an Issue URL, the palette asks threadsForIssues on servers with issueLinks, debounced by 300 ms. A bare #N is bounded to 20 GitHub repositories per server. Linked threads show first, including archived ones, each once. Plain words and bare numbers stay ordinary searches.
   • Each lookup carries the Issue's closing pull requests, so threads linked only through a closing PR are found too. They come from the loaded Issues list entry, or else, for owner/repo#N or a URL, from one debounced issues.detail read on a server that lists Issues.
   • A bare #N that the list has not loaded finds stored and branch links only; the user docs say so.
4. Docs. Linking by hand in the Linked PRs and Issues panel, unlinking, the link_issue and unlink_issue MCP tools, the panel's linked work and the palette lookup.
5. resolveIssueProject takes a preference, and Start thread prefers a checkout on a server that keeps Issue links, falling back to the first checkout.
   • An issue= link resolves its server through resolveIssuePanelEnvironment. That uses the named selectedEnvironmentId only when that server lists Issues; otherwise it picks a server that lists Issues and checks the repository out, preferring one that keeps Issue links. So a shared link never reaches an upstream server.

Proof

Everything below ran at the head of this PR.

• Live suite, real gh and GitHub (apps/server: T3CODE_ISSUES_LIVE=1 T3_LIVE_GITHUB=1 vp test run src/issues/ src/issueLinks/): 58 passed, 1 skipped (Browse Issues: list, filters, parent tree and side panel #27's write test, which needs its fixture).
  • The detail read returns Prism settings in the Providers layout: role list with toggles, lanes only for Worker #26's closing PR feat(web): Prism settings in the Providers layout, lanes only for Worker #35 as merged.
  • The Computed Issue status, status grouping and filters #29/feat(web): computed Issue status with grouping and filters (#29) #36 thread-linked case now holds whatever feat(web): computed Issue status with grouping and filters (#29) #36's state is. feat(web): computed Issue status with grouping and filters (#29) #36 has merged since, and the list reads it with GitHub's state merged, which no longer drives Computed Issue status, status grouping and filters #29's status.
• Server: vp test run src/environment src/issues src/issueLinks src/auth/RpcAuthorization.test.ts src/mcp/McpHttpServer.test.ts: 113 passed, 12 skipped (the live suites). It includes a CI test that decodes a detail fixture with one closing PR node and one null node and maps it through issueDetailOf. src/server.test.ts: 197/197.
• Web: vp test run src/components/issues/ src/components/CommandPalette.logic.test.ts src/components/SidebarChildActivity.logic.test.ts: 102 passed. New tests cover:
  • environmentIdsWithCapability;
  • palette reference parsing and targets: every links server, worktrees once, a named repository, the 20-repository bound, no lookup for plain queries;
  • issuePanelPullRequests: order, dedupe, unread state;
  • resolveIssueProject preferring an issueLinks server;
  • closing PRs passed into the palette lookup, and when the palette's detail read runs or is skipped;
  • resolveIssuePanelEnvironment.
• Contracts: issueStatus.test.ts and issueLinks.test.ts: 45 passed.
• Checks:
  • tsc --noEmit -p tsconfig.json in apps/server, apps/web, packages/contracts, packages/shared and packages/client-runtime: 0 errors.
  • vp lint: 0 findings in the changed fork files. CommandPalette.tsx, SidebarChrome.tsx and ServerEnvironment.ts have 4 warnings both before and after this change.
  • vp fmt --check on changed files: clean. vp run knip:check: pass. scripts/fork-check.sh: OK.

Notes

• The new files are mapped under issues-status. Its sharedFiles add ServerEnvironment.ts, CommandPalette.tsx, SidebarChrome.tsx and contracts/environment.ts, all already allowlisted.
• No screenshots, as agreed. There has been no integrated client pass, no independent review of this head, and fork CI is not observed yet.

Model: Claude Opus 5.5 (medium) via T3 Code

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ No successful main baseline artifact is available yet. This run establishes the initial measurement.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	—	13.5 KiB	—	15.1 KiB	✅
Codex	Thread snapshot wire	—	7.1 KiB	—	7.3 KiB	✅
Codex	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Codex	Live turn WebSocket decoded	—	56.2 KiB	—	66.4 KiB	✅
Codex	Live turn messages	—	9	—	21	✅
Claude	Total thread wire	—	13.5 KiB	—	15.1 KiB	✅
Claude	Thread snapshot wire	—	7.1 KiB	—	7.3 KiB	✅
Claude	Live turn WebSocket wire	—	6.4 KiB	—	7.8 KiB	✅
Claude	Live turn WebSocket decoded	—	57.0 KiB	—	66.4 KiB	✅
Claude	Live turn messages	—	9	—	21	✅

Baseline: unavailable · PR result: 3336b68 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 113.9 KiB
• Claude decoded thread snapshot: 114.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[lukemaj]

Merging with the Fork Stack Model check failing for a known CI cause unrelated to this change: the workflow on this PR's base (feat/25-issues) fetches only 100 upstream commits, upstream is 113 past the fork base, so fork-check.sh cannot find the merge base and exits before printing fork-check: base. Fixed for main in #39. The real stack check runs on the full result in #37 against main. All other checks pass on 3336b68; independent review findings from 638cdb4 were fixed in 3336b68 and checked by the coordinator.