feat(issues): add issue tracking core with GitHub issues

[juliusmarminge]

Problem

T3 Code can track pull requests but not issues, and non-git trackers such as Linear and Jira have nowhere to plug in.

Change

Adds issue tracking as its own extension point beside source control.

• New @t3tools/issue-tracker-core package: the IssueTrackerApi port, IssueTrackerError, and defineIssueTrackerDriver. Each tracker declares capabilities (create, edit, comment, labels, assignees, reactions, templates, linked PRs, states, close reasons); clients only offer what a tracker declares.
• Contracts: issues are { tracker, host?, scope, key } (owner/repo + 123, or a team key + ENG-123 later), and state is { category: open | closed, name } so tracker-specific states keep their own names. Ten issues.* RPCs; writes require the source-control write scope.
• Server: IssueTrackerRegistry and IssueService. Project trackers resolve from the project's remote; issues on a repository no project owns are read-only.
• GitHub tracker in source-control-github, over the existing GitHubApi.
• RPC surface: the issue RPCs live in their own WsIssuesRpcGroup, merged into WsRpcGroup, with a separate handler layer in ws.ts. With Effect 4.0.4, adding them to the single core group pushed ServerWsRpcGroup.toLayer past TypeScript's instantiation depth (a hidden TS2589 that surfaced as a missing-any-service error in binCli.ts). Wire format, client, and authorization are unchanged. New domains should follow the same pattern.

Bitbucket retired its issue tracker and registers none.

Stack

1. This PR: core, contracts, service, GitHub
2. #19260: Issues page and detail panel
3. #19261: GitLab, Azure DevOps, Forgejo trackers
4. #19270: thread issue links and MCP issue tools
5. #19274: Linear as a standalone tracker

Verification

Targeted typechecks and the new service, GitHub tracker, and RPC authorization tests pass.

Rebuilt from #6315 by @Bil0000, which this stack uses as its reference for host APIs and UX.

Implemented with Claude Opus 5.5 and Claude Fable 5.1 in T3 Code, using the Claude Code harness.

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	+7 B (+0.1%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	+7 B (+0.6%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	20.9 KiB	20.9 KiB	0 B (0.0%)	29.3 KiB	✅
Codex	Live turn messages	2	2	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.2 KiB	21.2 KiB	0 B (0.0%)	29.3 KiB	✅
Claude	Live turn messages	2	2	0 (0.0%)	8	✅

Baseline: 173a970 · PR result: b72ded8 · 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: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

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

[Bombatomica64]

Small one on search: quoting the whole input keeps is:closed from being read as a qualifier, but it also turns the search into a phrase match. On this repo, is:issue "pull request panel" finds 32 issues, while "panel" "pull" "request" finds 68. Quoting each word on its own is just as safe against qualifiers and still finds issues where the words aren't next to each other. Ignore this if the phrase match is intended.

[juliusmarminge]

Good catch, the phrase match wasn't intended. Each word is now quoted on its own in c306735, so is:closed still can't act as a qualifier but the words match apart.

[Artic0din]

Opening any GitHub issue in the detail panel fails. GitHub rejects the detail query:

Field 'comments' has an argument conflict: {} or {last:"100"}?

ISSUE_DETAIL_GRAPHQL_QUERY interpolates ISSUE_ROW_FIELDS here, which already selects comments { totalCount }. Line 173 then selects comments(last: 100) { … } again. GraphQL won't merge the same field selected twice with different arguments, so the whole request errors. The issue list still works because the search query only uses the row fields.

The detail's comments(last: …) block already asks for totalCount, and RawDetailSchema overrides comments with that page. So the detail query can drop the row's count-only selection:

const ISSUE_ROW_BASE_FIELDS = `number title url state stateReason createdAt updatedAt closedAt
  author { login avatarUrl ... on User { name } }
  assignees(first: 20) { nodes { login name avatarUrl } }
  labels(first: 20) { nodes { name color } }`;

const ISSUE_ROW_FIELDS = `${ISSUE_ROW_BASE_FIELDS}
  comments { totalCount }`;

Then use ${ISSUE_ROW_BASE_FIELDS} in ISSUE_DETAIL_GRAPHQL_QUERY.

The tests didn't catch this because the tracker test stubs graphql with canned responses and never validates the query text.

Found by running the whole stack (#19259–#19274) merged onto main at 614b432a79 in a dev desktop build. All 17 issues.detail calls failed with this error, while issues.list worked.

[juliusmarminge]

Thanks for running the whole stack. That was a real blocker. Fixed in b72ded8 the way you suggested: the detail query uses ISSUE_ROW_BASE_FIELDS, so comments is selected once. I ran the detail, permission and search queries against a live issue here and GitHub accepts all three. The tracker test now also checks that the detail query names comments once, since its stubbed responses couldn't catch this.

[Artic0din]

Confirmed in a dev build of the full stack: opened an issue, commented and closed it without errors.

[Artic0din]

Question on forks: issue scope follows the canonical repository identity, which prefers the upstream remote (#16353). A fork project therefore lists the upstream repo's issues and never its own. Here that hides 73 open issues across three forks that track their own work. Is following upstream intended for issues, or should issues use the checkout's origin (which #16353 already reports), or list both?