You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What: Issues browse, links to threads, computed status and open-in-app work on upstream's GitHub API client and v2 thread reads. Why: Upstream deleted the gh CLI code and old reads these features use, and has no Issues feature of its own (#166 assessment g4). So what: An agent ports it into fork/v2 after child threads.
Part of #166 (port 5 of 11). Plan and decision table: #166.
Contribution to the Objective
Lets the Promachos work from tracked Issues.
Acceptance criteria
Issues browse on upstream's GitHubApi transport; links (link_issue/unlink_issue/list_thread_issues) on v2 threads and native parent links; status logic replayed; open-in-app links replayed.
fork_thread_issue_links data carries over.
Feature map and allowlist updated.
Non-goals
Moving or force-pushing main (only Issue 11 lands the port, with human approval).
Deleted:gh CLI calls (replaced by upstream's client).
Bottleneck: Upstream's GitHub client and repo identity (foundation).
Checked myself: no Issue schema in upstream contracts. On the v2 base 12069eefd7: no Issues feature on upstream main; open upstream #6315/#16552 are unmerged and not adopted. The V2 database starts as a full copy of V1 (initializeV2Database), and LegacyV1ThreadImporter keeps thread ids and deletedAt. On a read-only VACUUM INTO snapshot of real data, the stored links of live threads read back with exactly equal rows after the import, including after a repeated import. The rewritten GitHub queries pass against real GitHub.
What:#171 implementation is assigned to one visible Prism child in its exclusive v2 worktree. Why: The approved Issues port replaces deleted GitHub and orchestration reads while preserving fork behavior. So what: The dispatcher integrates proof, rebases onto the landed foundation, and obtains independent exact-head review before opening the single PR into fork/v2; no merge is authorized.
Final proof: focused reads/links/status and snapshot carryover tests, targeted lint/typecheck, feature map/allowlist validation. No repo-wide runs.
Independent review must inspect the final rebased exact SHA, with review/independent pending at dispatch, findings then success/failure on that SHA. Agent Observer cost publication is required before readiness, with any measurement gap recorded.
Browser/computer use is unauthorized. Integrated UI verification and before/after screenshots remain unverified. No versions, installations, deployments, main push or merge.
Elon record
Requirements and who asked: Existing #171 record and #166 D7.7 require preserving Issues browse, links, status and in-app opening; the user requires one PR into fork/v2 with independent review and focused proof. Deleted: The obsolete gh transport and sub.* lineage helpers are replaced by existing upstream APIs; no extra orchestration service, component PRs or browser launch. Bottleneck: Adapting the deleted GitHub/read seams; final carryover and review also depend on #167 landing. Checked myself: Full #171 and #166 bodies/comments, PORT-BRIEF and g4 assessment, v2 AGENTS and v1 fork docs read; origin and the exact upstream base verified; #167 live state remains OPEN.
What: Focused logic tests are the scoped UI proof for #171; screenshots and integrated UI verification are deferred. Why: The user explicitly keeps browser use disabled and assigns one integrated pass to the planner after all ports land on fork/v2. So what: The #171 PR will state UI evidence pending that integrated pass; this is an explicit proof disposition and does not block scoped PR delivery.
No subagent launches a dev server or browser. The later planner pass requires user permission and owns before/after capture. Foundation remains OPEN with no published migration interface; #171 uses only #167 acceptance until the exact interface lands. Issues choose fork origin identity; PR lookup changes stay outside this outcome and a concrete failure is escalated rather than silently expanded.
What: Upstream has no GitHub Issues feature on main; two open upstream PRs overlap it, and neither is adopted, so the port proceeds as decided in #166 D7.7. Why: The upstream-first rule prefers merged work; both candidates are unmerged and conflicting, and neither covers the fork's status, review-mark or descendant behavior. So what: The implementing agent ports the fork code onto fork/v2. The name collisions listed below need a decision at the next absorption if either PR merges.
Upstream checked (2026-10-08)
pingdotgg/t3code main at 12069eefd707: no Issue schema in packages/contracts/src, no issues.* RPC, no Issue commits since base de251fc2971a (git log -i -E --grep="github issues?|issue (view|link|panel|tab)" is empty).
Issues search: no open or closed upstream Issue tracks an Issues browser (the idea lives in Discussions, #14909).
Open, not draft, mergeable=CONFLICTING, head 3c514d10bc35, merge base a4c9494b0e (one commit before our base). 321 files, +57,708/-1,596; 189 non-test files, +30,010.
Fetched into a scratch bare repo outside the checkout (alternates to the full clone). Read in full: file list and stats, every contract, persistence, migration, legacy-import and MCP-tool diff, the GitHub transport and project resolution in IssueService.ts/GitHubIssueCli.ts. Not read line by line: the new web components and tests. Nothing from it was run.
Design: five trackers (GitHub, GitLab, Bitbucket, Azure DevOps, Linear) on GitHubApi. Thread links live inside upstream's v2 thread payload (OrchestrationV2AppThread.issues, internal command thread.issue-link.sync, IssueSyncReactor), plus migrations 61 (projection_threads.issue_links_json) and 62 (work_item_links), carried by a LegacyV1ThreadImporter edit.
Not covered compared with the fork: computed status (review/independent marks, blockers, whether a linked thread is working), links derived from branches and closing references, and links rolled up from child threads.
Why not adopted: unmerged, and the maintainers have not approved its scope (the PR says so). It edits upstream's v2 contract, projector and importer, which goes against the thin-fork Mission. D7.7 chose Port.
Collision watch if it merges: the MCP tool names link_issue, unlink_issue and list_thread_issues are the same as ours; it also adds read_issue, and its own issues thread field and issue contracts.
Candidate: #16552 feat(web): open GitHub issue links beside the thread
Draft, CONFLICTING, head 116d291f9018, 27 files, +1,168/-11. Whole diff read (contracts, server, client-runtime, web). Not run.
A read-only issue tab: issues.detail RPC on PullRequestService, an issues environment capability, and an issue right-panel surface.
Overlaps issues-open-links but not browse, links or status. Not adopted, because it is an unmerged draft.
Collision watch if it merges: the RPC name issues.detail is the same as the fork's ISSUE_WS_METHODS.issuesDetail.
Prior decisions applied
D7.5/D8a: fork Issues code prefers identity.origin over the canonical repository; PR lookup is not changed here.
D4.1: link_issue/unlink_issue/list_thread_issues stay as fork tools, declared through McpToolAccess.
What: The Issues port (browse, links, status, open-in-app) runs on fork/v2 in a local checkpoint 8a253ff712, stacked on the #167 checkpoint 2c849253fb. The focused tests, the real-data carryover check and the live GitHub reads pass. Why: Upstream replaced the gh CLI and the v1 reads; the port moves the fork's code onto GitHubApi, the v2 projection, McpToolAccess and native lineage without changing feature behavior. So what: The parent reviews the decisions below. After #167 merges, the agent rebases onto origin/fork/v2, adds the feature map and allowlist entries, reruns the final proof bound to that SHA, and squashes to one commit. No push and no PR yet.
Runtime: claudeAgent / claude-opus-5-5. The runtime does not report effort, so it is unknown.
Proof (host-neutral env from docs/fork.md: Node 24.13.1, Homebrew off PATH, ELECTRON_RUN_AS_NODE unset, real TMPDIR)
Check
Result
vp test run apps/server/src/issues apps/server/src/issueLinks
58 passed, 10 skipped (opt-in live and real-data suites)
vp test run apps/web/src/components/issues apps/web/src/components/threadDescendants.logic.test.ts apps/web/src/components/pullRequest/pullRequestFilterSearch.logic.test.ts apps/web/src/reopenClosedView.test.ts apps/web/src/rightPanelStore.test.ts packages/contracts/src/issue*.test.ts
all pass (188 web, plus contracts)
Real data: CHROMERIA_V1_SNAPSHOT_SOURCE=~/.t3/userdata/state.sqlite vp test run apps/server/src/issueLinks/IssueLinks.carryover.test.ts
2 passed. Read-only VACUUM INTO copy; 155 stored links on 93 live threads read back through forThread and threadsForIssues, unchanged after a repeated reconcileShells + runForkV1Backfills
Live GitHub, read-only: T3CODE_ISSUES_LIVE=1 vp test run apps/server/src/issues/IssueService.live.test.ts (with gh on PATH)
8 passed. The write fixture was skipped and not run
tsc --noEmit: contracts, client-runtime, server, web
exit 0
vp lint on every changed file
exit 0. The edited upstream files have the same 145 warnings at base and head (rule and message compared), so none are introduced; the new fork files have none
Final proof will be rerun after the rebase and bound to that SHA.
What changed from v1
GitHub:gh calls replaced by GitHubApi. All typed text and URLs are GraphQL variables; the batched resource(url: $…) aliases are built with the shared aliasedGraphQlDocument. Issue writes go through REST and may spend the reserve. Reads and writes are refused for a host with no GitHub project, so a client cannot send the server's token to a host it picks.
Repository identity: Issues use identity.origin ?? canonical (D8a): gitHubRepositoryOf, starting a thread from an Issue, and the markdown checkout. PR lookup is unchanged.
Thread reads: single-thread context uses OrchestratorV2.getThreadShell and ProjectService. Set reads (threads for Issues, PRs of Issue threads, descendants, prune) read the live orchestration_v2_projection_threads table, the way upstream's pullRequest/linkedThreads.ts does. They never read frozen v1 projection_threads.
Descendants: native lineage.parentThreadId, following only unbroken subagent links; forks and anything below them are excluded (parent-approved, tested).
Working status: derived from the v2 shell (runtime.status, plus subagent/background_task background work; monitors excluded). A spawned thread's work counts for its ancestors.
MCP:link_issue/unlink_issue use McpToolAccess.actsAsCaller and list_thread_issues uses readsAsCaller, behind the pull-requests capability.
Credentials: the closing-reference cache is keyed by credential fingerprint and reads under that credential, as the pull request caches are. One Issues list pins one credential per host across all its searches. Both are tested.
Client permissions:issues.comment and issues.setState are in CLIENT_GUARDED_RPC_SCOPES as source-control:write, the same as PR writes. The panel disables them through the command's permissionAtom.
Fallback: where a server lists no Issues, /issues/N links keep upstream's behavior, including the PR panel's not-found state (#14242).
Reopen: a closed Issue tab reopens through reopenClosedView.
Decisions for the parent
Issue comment and close now require source-control:write (v1: orchestration-operate). Standard client grants hold both scopes.
Shared pager: no Issues read pages within one request. The list continues from client cursors, as v1 did and as upstream's PR list does; readGraphQlPages is used only for walks inside one request. Recommendation: keep this. Changing it would change page size, latency and quota use.
Not ported: issueStatus.live.test.ts (it creates branches and workflows through gh); IssueLinks.live.test.ts (its closing-reference read now lives in IssueService.live.test.ts); ThreadLinksPanel.test.tsx (static-markup test, which AGENTS.md rules out; its state mapping is covered by issueLinks.logic tests).
Watching a child thread's PR from the parent's panel keeps upstream's watch behavior: it targets the parent thread.
UI before/after images are pending the parent's integrated pass (browser use was not authorized). There is no mobile Issues UI, the same as v1.
Process: two git fetch origin runs updated remote-tracking refs in the shared clone; nothing else outside this worktree was written. A shell bug once ran a repo-wide vp lint (read-only, no file changes).
What: The user's D27 decisions are applied in local checkpoint b347dacb11: Issue comment, close and reopen require source-control:write, and the Issues search reads through upstream's readGraphQlPages, one page per call. Why: The user chose the same scope upstream gives pull request writes, and approved the shared pager with from set to the client's cursor and maxPages: 1. So what: After #167 lands, the agent rebases onto origin/fork/v2, adds the feature map and allowlist, reruns the final proof bound to that SHA and squashes to one commit. The parent opens the PR, and the PR must carry the permission note below. No push yet.
Decisions (user, D27)
#
Decision
Applied
D27a
issues.comment and issues.setState require source-control:write, matching upstream PR writes. This is a deliberate permission change from v1 (orchestration-operate).
Listed in CLIENT_GUARDED_RPC_SCOPES, so the server middleware and the client command guard check the same scope. The panel disables writes through the command's permissionAtom. Reads stay orchestration:read; thread links stay orchestration:operate.
D27b
The Issues search uses readGraphQlPages with from = the client cursor and maxPages: 1.
Exactly one request per search per call. The returned cursor still becomes nextCursors, so the client's "Load more" contract is unchanged. Detail, states, closing references and the linked-only read are single requests with no connection to page.
Permission change, for the PR description
A grant with orchestration:operate but no source-control:write can no longer comment on, close or reopen Issues. It can still read them and link them to threads.
A grant with source-control:write but no orchestration:operate can now comment on, close and reopen them.
No grant is expanded automatically. Standard pairings already include both scopes, so default clients see no change.
To give a client the permission, create a fresh pairing link that includes it: npx t3 pair --scope … --scope source-control:write, or a standard pairing from Settings → Connections. Open that link in the browser, or use Add Environment for a saved remote or mobile environment. Reconnecting alone does not change permissions (docs/user/remote-access.md, "Manage or revoke access"). The Issues section of docs/user/source-control.md now says this and links there.
Proof at b347dacb11 (host-neutral env)
Check
Result
Focused tests: server Issues and links, client-runtime Issue permissions, contracts Issue tests, web Issues, descendants, filter search, reopen, right-panel store
20 files; 303 passed, 10 skipped (opt-in live and real-data suites)
Server: issueRpcAuthorization.test.ts
Operate-only: comment and close are refused with requiredPermission: source-control:write before the handler runs. Source-control-only: both reach the handler.
Client: issueCommandPermissions.test.ts
Operate-only: permissionAtom is false and authorize fails asking for source-control:write. Source-control-only: true, and authorize passes. Covers comment and close.
Pager: IssueService.test.ts
First call: one request with after: null, and the returned cursor comes back as nextCursors. Continuation: one request with that cursor. Also covers one credential pinned per host across searches.
Real data: CHROMERIA_V1_SNAPSHOT_SOURCE=… IssueLinks.carryover.test.ts
2 passed. The live threads' stored rows, with every persisted field (thread_id, host, repository, number, url, source, linked_at), are exactly equal (isDeepStrictEqual) before the import, after the reads and prune, and after a repeated import plus hook run. Visible and found links match. Failure messages print only counts and digests, never rows.
Live GitHub, read-only, after the pager change
8 passed; the write fixture was skipped
tsc --noEmit: server, client-runtime, contracts, web
exit 0
vp lint on the changed files
exit 0, no warnings in fork files; the edited upstream files' warnings are identical to base
Carryover, stated separately
#171 registers no write backfill: the v2 database starts as a copy of v1, so fork_thread_issue_links is carried over unchanged, and imported threads keep their ids. The startup hook still runs (runForkV1Backfills() after reconcileShells) and is idempotent here. The proof that the hook recovers from a failed step without duplicate rows comes from #167's runner test, not this Issue.
Still open
The feature map and allowlist wait for #167; the drafted new-file list will be refreshed from the final changed-file list, keeping one primary owner per upstream file. The #168 lineage repair is still needed for imported v1 children. UI images are pending the parent's integrated pass. The exact-head independent review is the parent's.
What: The final #171 candidate is one commit, 17ec0845edeb3967120d6e4df6782a8c3b3df9a6, on origin/fork/v26e1653b671 (#178). Every step of the final proof passed on that exact SHA. Why:#167 landed, so the port was rebased onto it, given its feature map and allowlist entries, squashed, and proven again. So what: The parent opens the one PR from the drafted body (/tmp/171-v2/pr-body.md), then runs the independent exact-head review and the cost report. No push or PR has been made by the implementer.
Rebase
Only the six Port the GitHub Issues features #171 commits above 2c849253fb were replayed onto origin/fork/v2; there were no conflicts. The rebased patch equals the pre-rebase patch except for unchanged foundation context lines. No foundation change is in the Port the GitHub Issues features #171 diff.
Squashed to one commit. The stale IssueRef comment about gh was corrected.
Upstream's RightPanelTabs.keyboard.test.tsx (#15686) pinned the old menu label as its evidence that the Mod+T menu opened. Only that string changed, to "Linked PRs and Issues" (parent-approved); every behavior assertion is unchanged. The file is owned by issues-links.
Inventory
docs/fork-features.md: adds issues-browse, issues-links, issues-status and issues-open-links. All 58 new files are listed. 25 upstream files have a primary owner here; server.ts, ws.ts and SidebarChrome.tsx stay owned by provider-auto-update and branding and are listed as shared. The header now says "the carried features below" instead of a count.
scripts/fork-upstream-edits.txt: adds exactly those 25 paths.
scripts/fork-check.sh: OK, 12 features, all 86 upstream edits in the stack owned once.
Final proof (/tmp/171-v2/final-17ec0845ed/, all exit 0)
Step
Result
Issues tests
207 passed, 10 skipped. The skips are exactly the 9 live GitHub tests and the 1 real-data test.
Tests next to the edited upstream files (21 files)
2 passed (synthetic + real). Exact persisted rows are equal before, after and on repeat. The test does not report its snapshot size; a separate read-only count of the source just after the run found 163 links on 101 live threads, which is not the test input.
Live GitHub, read-only (T3CODE_ISSUES_LIVE=1)
8 read-only tests passed. The write fixture is also gated on T3CODE_ISSUES_LIVE_FIXTURE, which stayed unset, so it was skipped and no GitHub write happened.
Typecheck: contracts, client-runtime, server, web
0 errors
Lint on the 85 changed TS/TSX files
0 errors. Upstream files: 145 warnings at base and at head, so none introduced; fork files have none.
Pending: the independent exact-head review, the cost report and the integrated UI pass, all the parent's.
What: The #171 candidate is now 8b7ce7b7c979d1b79271339799dbcac9520a9404, still one commit on origin/fork/v26e1653b671. It fixes CI's knip failure on the previous head, and the focused final proof passed again on this exact SHA. Why: CI Lint on PR #179 failed on 17ec0845ed because knip flagged an unused export, CREATED_AT, at apps/server/src/issueLinks/IssueLinks.testFixtures.ts:24. So what: The parent pushes this head to the same PR, CI reruns knip, and the parent runs the fresh exact-head review. The implementer has not pushed.
Repair
CREATED_AT is used only inside IssueLinks.testFixtures.ts, and no importer reads it. The constant stays, but it is no longer exported.
git diff 17ec0845ed 8b7ce7b7c9: 1 file, 1 line. The commit was amended, so the stack is still one commit. No ignore entries or waivers were added. Knip was not run locally because it is repo-wide; CI runs it on push.
Focused proof on 8b7ce7b7c9 (/tmp/171-v2/final-8b7ce7b7c9/, every step exited 0)
Step
Result
scripts/fork-check.sh
OK, 12 features, all 86 upstream edits in the stack owned once
Issues tests
207 passed, 10 skipped. The skips are exactly the 9 live GitHub tests and the 1 real-data test.
Tests next to the edited upstream files (21 files)
518 passed
Real-data carryover (CHROMERIA_V1_SNAPSHOT_SOURCE, VACUUM INTO snapshot)
2 passed (synthetic and real). Exact persisted rows are equal before, after and on repeat.
Live GitHub, read-only (T3CODE_ISSUES_LIVE=1)
8 passed, 1 skipped. The write fixture stayed off (T3CODE_ISSUES_LIVE_FIXTURE unset), so no GitHub write happened.
Typecheck: contracts, client-runtime, server, web
0 errors
Lint on the 85 changed TS/TSX files
0 errors. 145 warnings at base and at head, all in upstream files, so none introduced.
The PR body draft (/tmp/171-v2/pr-body.md) now names this head, links this log folder, and explains the repair.
What:#171 was delivered as one ready PR, then GitHub reported it merged externally during the final handoff: #179. Why: The accepted Issues browse, links, status and in-app open port now uses native v2 reads and upstream GitHub infrastructure. So what: Code proof and independent exact-head review pass. This dispatcher issued no merge command; the merger owns cleanup and any further delivery. UI evidence awaits the planner's agreed integrated pass.
Exact-head proof: 207 Issues tests pass, 518 adjacent tests pass, 2 carryover tests pass, 8 read-only live GitHub tests pass. Four targeted typechecks, scoped lint and fork inventory pass; 145 upstream lint warnings remain identical to base. All code CI passes, including knip and full CI test shards.
Default 10 skips are exactly 9 live GitHub tests (8 reads plus 1 additional fixture-gated mutation) and 1 real-snapshot test. Separate opt-ins passed the 8 reads and the 2-test carryover file (synthetic + real); the mutation stayed skipped. No live write was tested.
Independent review: no actionable defect. Newest review/independent status on this exact SHA is success, created by authenticated lukemaj. Credential concern was withdrawn after installed Effect source inspection; no speculative patch. Reviewer Codex / gpt-6-luna, max effort; no extra reviewer tests/browser.
D27 preserved: Issue comment/close/reopen uses source-control:write; operate-only loses these writes, source-control-only gains them, no auto-expanded grants, re-pair instructions in PR/user docs. Shared pager from + maxPages:1 preserves one request/search and cursors, tested first and continuation.
Browser disabled; before/after UI evidence explicitly deferred, no mobile Issues UI (v1 parity). No merge, install, deploy, main push or local repo-wide checks. Worktree/branch retained; merger owns retirement, and this dispatcher has no additional cleanup or installation instruction.
Exactly one PR is linked to this T3 thread; list inventory checked. Ready-event native fingerprint and automated review dispatch checks pass. Only the size-label metadata job is still running; no code check is pending and no unresolved bot finding is present. GitHub now reports merged at 2026-10-08T18:20:16Z, by lukemaj, merge commit 2647478da553b442c6e5000b76c3b42042b01e69, with the same reviewed head/base. This state changed outside this dispatcher's actions during final verification; the earlier open-state observation is superseded. T3 link inventory may lag the live state.
Requirements and who asked:#171/#166 fixed the Issues port and origin-aware scope; user D27 fixed permission/pager choices and explicitly deferred UI proof. Deleted: gh CLI and frozen-v1 runtime reads; no extra feature scope, versions, speculative credential fix or Issues write backfill. Bottleneck: Final integrated UI acceptance follows all ports; independent review and CI are complete for this code candidate. Checked myself: Exact live GitHub head/base/open ready state, clean one-commit diff, actual focused logs, newest authenticated exact-head review status, green code CI and bot transfer ceilings; Observer comment published with measurement gap.
Coordinator: Codex / gpt-6.1-sol, medium effort. Implementation: Claude Code / claude-opus-5-5, effective effort unavailable. Reviewer: Codex / gpt-6-luna, max effort. All children visible through T3/Prism.
Delivered into fork/v2 by #179 (squash 2647478da5, reviewed head 8b7ce7b7c9). Still pending outside this Issue: the planner's integrated UI pass on fork/v2 and the landing on main in #177.
Activity
lukemaj commentedon Oct 8, 2026
What: #171 implementation is assigned to one visible Prism child in its exclusive v2 worktree.
Why: The approved Issues port replaces deleted GitHub and orchestration reads while preserving fork behavior.
So what: The dispatcher integrates proof, rebases onto the landed foundation, and obtains independent exact-head review before opening the single PR into
fork/v2; no merge is authorized./Users/lukaszmaj/dev/toolboxmd/chromeria-worktrees/171-v2, branchfeat/171-issues-v2.12069eefd707f78eafc27812027c994eea0613cf, remote origin verified astoolboxmd/chromeria; created from the full clone without changing Port foundation: fork/v2 branch on upstream main with replays, drops and data isolation #167's dirty files.sub.sub.sub.thread-9c8e27a973f0.dispatcher-7353fa55a707.dispatcher-e9065b5ae29f.worker-cfc9f595df73, Prism worker hard,claudeAgent/claude-opus-5-5. Effective effort is not exposed by spawn/read tools and remains unverified pending child runtime evidence.origin/fork/v2still contains only the upstream starting base. Foundation dependency remains pending; nativeparentThreadIdavoids dependence on Port child threads onto upstream lineage and delegation #168's old helpers.review/independentpending at dispatch, findings then success/failure on that SHA. Agent Observer cost publication is required before readiness, with any measurement gap recorded.Elon record
Requirements and who asked: Existing #171 record and #166 D7.7 require preserving Issues browse, links, status and in-app opening; the user requires one PR into fork/v2 with independent review and focused proof.
Deleted: The obsolete gh transport and sub.* lineage helpers are replaced by existing upstream APIs; no extra orchestration service, component PRs or browser launch.
Bottleneck: Adapting the deleted GitHub/read seams; final carryover and review also depend on #167 landing.
Checked myself: Full #171 and #166 bodies/comments, PORT-BRIEF and g4 assessment, v2 AGENTS and v1 fork docs read; origin and the exact upstream base verified; #167 live state remains OPEN.
lukemaj commentedon Oct 8, 2026
What: Focused logic tests are the scoped UI proof for #171; screenshots and integrated UI verification are deferred.
Why: The user explicitly keeps browser use disabled and assigns one integrated pass to the planner after all ports land on fork/v2.
So what: The #171 PR will state UI evidence pending that integrated pass; this is an explicit proof disposition and does not block scoped PR delivery.
No subagent launches a dev server or browser. The later planner pass requires user permission and owns before/after capture. Foundation remains OPEN with no published migration interface; #171 uses only #167 acceptance until the exact interface lands. Issues choose fork origin identity; PR lookup changes stay outside this outcome and a concrete failure is escalated rather than silently expanded.
lukemaj commentedon Oct 8, 2026
What: Upstream has no GitHub Issues feature on
main; two open upstream PRs overlap it, and neither is adopted, so the port proceeds as decided in #166 D7.7.Why: The upstream-first rule prefers merged work; both candidates are unmerged and conflicting, and neither covers the fork's status, review-mark or descendant behavior.
So what: The implementing agent ports the fork code onto
fork/v2. The name collisions listed below need a decision at the next absorption if either PR merges.Upstream checked (2026-10-08)
pingdotgg/t3codemain at12069eefd707: no Issue schema inpackages/contracts/src, noissues.*RPC, no Issue commits since basede251fc2971a(git log -i -E --grep="github issues?|issue (view|link|panel|tab)"is empty).Candidate: #6315 feat(issues): add multi-provider issue tracking
mergeable=CONFLICTING, head3c514d10bc35, merge basea4c9494b0e(one commit before our base). 321 files, +57,708/-1,596; 189 non-test files, +30,010.IssueService.ts/GitHubIssueCli.ts. Not read line by line: the new web components and tests. Nothing from it was run.GitHubApi. Thread links live inside upstream's v2 thread payload (OrchestrationV2AppThread.issues, internal commandthread.issue-link.sync,IssueSyncReactor), plus migrations 61 (projection_threads.issue_links_json) and 62 (work_item_links), carried by aLegacyV1ThreadImporteredit.review/independentmarks, blockers, whether a linked thread is working), links derived from branches and closing references, and links rolled up from child threads.link_issue,unlink_issueandlist_thread_issuesare the same as ours; it also addsread_issue, and its ownissuesthread field andissuecontracts.Candidate: #16552 feat(web): open GitHub issue links beside the thread
CONFLICTING, head116d291f9018, 27 files, +1,168/-11. Whole diff read (contracts, server, client-runtime, web). Not run.issues.detailRPC onPullRequestService, anissuesenvironment capability, and anissueright-panel surface.issues-open-linksbut not browse, links or status. Not adopted, because it is an unmerged draft.issues.detailis the same as the fork'sISSUE_WS_METHODS.issuesDetail.Prior decisions applied
identity.originover the canonical repository; PR lookup is not changed here.link_issue/unlink_issue/list_thread_issuesstay as fork tools, declared throughMcpToolAccess.lukemaj commentedon Oct 8, 2026
What: The Issues port (browse, links, status, open-in-app) runs on fork/v2 in a local checkpoint
8a253ff712, stacked on the #167 checkpoint2c849253fb. The focused tests, the real-data carryover check and the live GitHub reads pass.Why: Upstream replaced the
ghCLI and the v1 reads; the port moves the fork's code ontoGitHubApi, the v2 projection,McpToolAccessand native lineage without changing feature behavior.So what: The parent reviews the decisions below. After #167 merges, the agent rebases onto
origin/fork/v2, adds the feature map and allowlist entries, reruns the final proof bound to that SHA, and squashes to one commit. No push and no PR yet.Candidate
feat/171-issues-v2, local only:8a253ff712on2c849253fb(Port foundation: fork/v2 branch on upstream main with replays, drops and data isolation #167 checkpoint, authorized local stacking). 54 new fork files, 27 upstream files edited.claude-opus-5-5. The runtime does not report effort, so it is unknown.Proof (host-neutral env from docs/fork.md: Node 24.13.1, Homebrew off PATH,
ELECTRON_RUN_AS_NODEunset, realTMPDIR)vp test run apps/server/src/issues apps/server/src/issueLinksvp test run apps/web/src/components/issues apps/web/src/components/threadDescendants.logic.test.ts apps/web/src/components/pullRequest/pullRequestFilterSearch.logic.test.ts apps/web/src/reopenClosedView.test.ts apps/web/src/rightPanelStore.test.ts packages/contracts/src/issue*.test.tsCHROMERIA_V1_SNAPSHOT_SOURCE=~/.t3/userdata/state.sqlite vp test run apps/server/src/issueLinks/IssueLinks.carryover.test.tsVACUUM INTOcopy; 155 stored links on 93 live threads read back throughforThreadandthreadsForIssues, unchanged after a repeatedreconcileShells+runForkV1BackfillsT3CODE_ISSUES_LIVE=1 vp test run apps/server/src/issues/IssueService.live.test.ts(withghon PATH)tsc --noEmit: contracts, client-runtime, server, webvp linton every changed fileFinal proof will be rerun after the rebase and bound to that SHA.
What changed from v1
ghcalls replaced byGitHubApi. All typed text and URLs are GraphQL variables; the batchedresource(url: $…)aliases are built with the sharedaliasedGraphQlDocument. Issue writes go through REST and may spend the reserve. Reads and writes are refused for a host with no GitHub project, so a client cannot send the server's token to a host it picks.identity.origin ?? canonical(D8a):gitHubRepositoryOf, starting a thread from an Issue, and the markdown checkout. PR lookup is unchanged.OrchestratorV2.getThreadShellandProjectService. Set reads (threads for Issues, PRs of Issue threads, descendants, prune) read the liveorchestration_v2_projection_threadstable, the way upstream'spullRequest/linkedThreads.tsdoes. They never read frozen v1projection_threads.lineage.parentThreadId, following only unbrokensubagentlinks; forks and anything below them are excluded (parent-approved, tested).runtime.status, plussubagent/background_taskbackground work; monitors excluded). A spawned thread's work counts for its ancestors.link_issue/unlink_issueuseMcpToolAccess.actsAsCallerandlist_thread_issuesusesreadsAsCaller, behind thepull-requestscapability.issues.commentandissues.setStateare inCLIENT_GUARDED_RPC_SCOPESassource-control:write, the same as PR writes. The panel disables them through the command'spermissionAtom./issues/Nlinks keep upstream's behavior, including the PR panel's not-found state (#14242).reopenClosedView.Decisions for the parent
source-control:write(v1: orchestration-operate). Standard client grants hold both scopes.readGraphQlPagesis used only for walks inside one request. Recommendation: keep this. Changing it would change page size, latency and quota use.issueStatus.live.test.ts(it creates branches and workflows throughgh);IssueLinks.live.test.ts(its closing-reference read now lives inIssueService.live.test.ts);ThreadLinksPanel.test.tsx(static-markup test, which AGENTS.md rules out; its state mapping is covered byissueLinks.logictests).Gaps and dependencies
docs/fork-features.mdandscripts/fork-upstream-edits.txtare not on fork/v2 or the Port foundation: fork/v2 branch on upstream main with replays, drops and data isolation #167 checkpoint yet. The four feature blocks and 25 allowlist paths are drafted for after Port foundation: fork/v2 branch on upstream main with replays, drops and data isolation #167 lands. The primary owners ofSidebarChrome.tsx,packages/contracts/src/index.tsandMcpHttpServer.tsdepend on the entries other features add.sub.*children import with a null parent; their links roll up only after Port child threads onto upstream lineage and delegation #168's lineage repair.git fetch originruns updated remote-tracking refs in the shared clone; nothing else outside this worktree was written. A shell bug once ran a repo-widevp lint(read-only, no file changes).lukemaj commentedon Oct 8, 2026
What: The user's D27 decisions are applied in local checkpoint
b347dacb11: Issue comment, close and reopen requiresource-control:write, and the Issues search reads through upstream'sreadGraphQlPages, one page per call.Why: The user chose the same scope upstream gives pull request writes, and approved the shared pager with
fromset to the client's cursor andmaxPages: 1.So what: After #167 lands, the agent rebases onto
origin/fork/v2, adds the feature map and allowlist, reruns the final proof bound to that SHA and squashes to one commit. The parent opens the PR, and the PR must carry the permission note below. No push yet.Decisions (user, D27)
issues.commentandissues.setStaterequiresource-control:write, matching upstream PR writes. This is a deliberate permission change from v1 (orchestration-operate).CLIENT_GUARDED_RPC_SCOPES, so the server middleware and the client command guard check the same scope. The panel disables writes through the command'spermissionAtom. Reads stayorchestration:read; thread links stayorchestration:operate.readGraphQlPageswithfrom= the client cursor andmaxPages: 1.nextCursors, so the client's "Load more" contract is unchanged. Detail, states, closing references and the linked-only read are single requests with no connection to page.Permission change, for the PR description
orchestration:operatebut nosource-control:writecan no longer comment on, close or reopen Issues. It can still read them and link them to threads.source-control:writebut noorchestration:operatecan now comment on, close and reopen them.npx t3 pair --scope … --scope source-control:write, or a standard pairing from Settings → Connections. Open that link in the browser, or use Add Environment for a saved remote or mobile environment. Reconnecting alone does not change permissions (docs/user/remote-access.md, "Manage or revoke access"). The Issues section ofdocs/user/source-control.mdnow says this and links there.Proof at
b347dacb11(host-neutral env)issueRpcAuthorization.test.tsrequiredPermission: source-control:writebefore the handler runs. Source-control-only: both reach the handler.issueCommandPermissions.test.tspermissionAtomis false andauthorizefails asking forsource-control:write. Source-control-only: true, andauthorizepasses. Covers comment and close.IssueService.test.tsafter: null, and the returned cursor comes back asnextCursors. Continuation: one request with that cursor. Also covers one credential pinned per host across searches.CHROMERIA_V1_SNAPSHOT_SOURCE=… IssueLinks.carryover.test.tsthread_id, host, repository, number, url, source, linked_at), are exactly equal (isDeepStrictEqual) before the import, after the reads and prune, and after a repeated import plus hook run. Visible and found links match. Failure messages print only counts and digests, never rows.tsc --noEmit: server, client-runtime, contracts, webvp linton the changed filesCarryover, stated separately
#171 registers no write backfill: the v2 database starts as a copy of v1, so
fork_thread_issue_linksis carried over unchanged, and imported threads keep their ids. The startup hook still runs (runForkV1Backfills()afterreconcileShells) and is idempotent here. The proof that the hook recovers from a failed step without duplicate rows comes from #167's runner test, not this Issue.Still open
The feature map and allowlist wait for #167; the drafted new-file list will be refreshed from the final changed-file list, keeping one primary owner per upstream file. The #168 lineage repair is still needed for imported v1 children. UI images are pending the parent's integrated pass. The exact-head independent review is the parent's.
lukemaj commentedon Oct 8, 2026
What: The final #171 candidate is one commit,
17ec0845edeb3967120d6e4df6782a8c3b3df9a6, onorigin/fork/v26e1653b671(#178). Every step of the final proof passed on that exact SHA.Why: #167 landed, so the port was rebased onto it, given its feature map and allowlist entries, squashed, and proven again.
So what: The parent opens the one PR from the drafted body (
/tmp/171-v2/pr-body.md), then runs the independent exact-head review and the cost report. No push or PR has been made by the implementer.Rebase
2c849253fbwere replayed ontoorigin/fork/v2; there were no conflicts. The rebased patch equals the pre-rebase patch except for unchanged foundation context lines. No foundation change is in the Port the GitHub Issues features #171 diff.IssueRefcomment aboutghwas corrected.RightPanelTabs.keyboard.test.tsx(#15686) pinned the old menu label as its evidence that the Mod+T menu opened. Only that string changed, to "Linked PRs and Issues" (parent-approved); every behavior assertion is unchanged. The file is owned by issues-links.Inventory
docs/fork-features.md: adds issues-browse, issues-links, issues-status and issues-open-links. All 58 new files are listed. 25 upstream files have a primary owner here;server.ts,ws.tsandSidebarChrome.tsxstay owned by provider-auto-update and branding and are listed as shared. The header now says "the carried features below" instead of a count.scripts/fork-upstream-edits.txt: adds exactly those 25 paths.scripts/fork-check.sh: OK, 12 features, all 86 upstream edits in the stack owned once.Final proof (
/tmp/171-v2/final-17ec0845ed/, all exit 0)CHROMERIA_V1_SNAPSHOT_SOURCE)T3CODE_ISSUES_LIVE=1)T3CODE_ISSUES_LIVE_FIXTURE, which stayed unset, so it was skipped and no GitHub write happened.Pending: the independent exact-head review, the cost report and the integrated UI pass, all the parent's.
lukemaj commentedon Oct 8, 2026
What: The #171 candidate is now
8b7ce7b7c979d1b79271339799dbcac9520a9404, still one commit onorigin/fork/v26e1653b671. It fixes CI's knip failure on the previous head, and the focused final proof passed again on this exact SHA.Why: CI Lint on PR #179 failed on
17ec0845edbecause knip flagged an unused export,CREATED_AT, atapps/server/src/issueLinks/IssueLinks.testFixtures.ts:24.So what: The parent pushes this head to the same PR, CI reruns knip, and the parent runs the fresh exact-head review. The implementer has not pushed.
Repair
CREATED_ATis used only insideIssueLinks.testFixtures.ts, and no importer reads it. The constant stays, but it is no longer exported.git diff 17ec0845ed 8b7ce7b7c9: 1 file, 1 line. The commit was amended, so the stack is still one commit. No ignore entries or waivers were added. Knip was not run locally because it is repo-wide; CI runs it on push.Focused proof on
8b7ce7b7c9(/tmp/171-v2/final-8b7ce7b7c9/, every step exited 0)scripts/fork-check.shCHROMERIA_V1_SNAPSHOT_SOURCE,VACUUM INTOsnapshot)T3CODE_ISSUES_LIVE=1)T3CODE_ISSUES_LIVE_FIXTUREunset), so no GitHub write happened.The PR body draft (
/tmp/171-v2/pr-body.md) now names this head, links this log folder, and explains the repair.feat(fork): port GitHub Issues browse, links, status and in-app links…
lukemaj commentedon Oct 8, 2026
What: #171 was delivered as one ready PR, then GitHub reported it merged externally during the final handoff: #179.
Why: The accepted Issues browse, links, status and in-app open port now uses native v2 reads and upstream GitHub infrastructure.
So what: Code proof and independent exact-head review pass. This dispatcher issued no merge command; the merger owns cleanup and any further delivery. UI evidence awaits the planner's agreed integrated pass.
8b7ce7b7c979d1b79271339799dbcac9520a9404; basefork/v26e1653b6719565db2cc5094670e19e6efd3fc1ce(feat(fork): carry Chromeria foundation onto upstream V2 #178 foundation). One Port the GitHub Issues features #171 commit, clean exclusive worktree/Users/lukaszmaj/dev/toolboxmd/chromeria-worktrees/171-v2; no foundation diff or version change.review/independentstatus on this exact SHA is success, created by authenticatedlukemaj. Credential concern was withdrawn after installed Effect source inspection; no speculative patch. Reviewer Codex /gpt-6-luna, max effort; no extra reviewer tests/browser.source-control:write; operate-only loses these writes, source-control-only gains them, no auto-expanded grants, re-pair instructions in PR/user docs. Shared pagerfrom+maxPages:1preserves one request/search and cursors, tested first and continuation.2026-10-08T18:20:16Z, bylukemaj, merge commit2647478da553b442c6e5000b76c3b42042b01e69, with the same reviewed head/base. This state changed outside this dispatcher's actions during final verification; the earlier open-state observation is superseded. T3 link inventory may lag the live state.Requirements and who asked: #171/#166 fixed the Issues port and origin-aware scope; user D27 fixed permission/pager choices and explicitly deferred UI proof.
Deleted: gh CLI and frozen-v1 runtime reads; no extra feature scope, versions, speculative credential fix or Issues write backfill.
Bottleneck: Final integrated UI acceptance follows all ports; independent review and CI are complete for this code candidate.
Checked myself: Exact live GitHub head/base/open ready state, clean one-commit diff, actual focused logs, newest authenticated exact-head review status, green code CI and bot transfer ceilings; Observer comment published with measurement gap.
Coordinator: Codex /
gpt-6.1-sol, medium effort. Implementation: Claude Code /claude-opus-5-5, effective effort unavailable. Reviewer: Codex /gpt-6-luna, max effort. All children visible through T3/Prism.feat(fork): port GitHub Issues browse, links, status and in-app links…
lukemaj commentedon Oct 8, 2026
Delivered into
fork/v2by #179 (squash2647478da5, reviewed head8b7ce7b7c9). Still pending outside this Issue: the planner's integrated UI pass onfork/v2and the landing onmainin #177.