Skip to content

Port the GitHub Issues features #171

Closed

Description

@lukemaj

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

Blockers

Earlier port Issues per the order in #166 (D3').

Proof

Focused tests for Issue reads, links and status; data carry-over test on the snapshot.

Elon record

  • Requirements and who asked: Issues next to PRs (Issues in Chromeria: an Issues view with computed status, linked to threads #25 and follow-ups); user confirmed port (Absorb upstream main through 8d11fe1261 #166, D7.7).
  • 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.

Activity

  1. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    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.

    • Workspace: /Users/lukaszmaj/dev/toolboxmd/chromeria-worktrees/171-v2, branch feat/171-issues-v2.
    • Starting base/HEAD: 12069eefd707f78eafc27812027c994eea0613cf, remote origin verified as toolboxmd/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.
    • Implementation child: 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.
    • Port foundation: fork/v2 branch on upstream main with replays, drops and data isolation #167 is OPEN and origin/fork/v2 still contains only the upstream starting base. Foundation dependency remains pending; native parentThreadId avoids dependence on Port child threads onto upstream lineage and delegation #168's old helpers.
    • 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.

  2. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    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.

  3. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    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).

    Candidate: #6315 feat(issues): add multi-provider issue tracking

    • 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.
  4. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    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.

    Candidate

    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

    1. Issue comment and close now require source-control:write (v1: orchestration-operate). Standard client grants hold both scopes.
    2. 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.
    3. 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).
    4. Watching a child thread's PR from the parent's panel keeps upstream's watch behavior: it targets the parent thread.

    Gaps and dependencies

  5. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    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.

  6. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    What: The final #171 candidate is one commit, 17ec0845edeb3967120d6e4df6782a8c3b3df9a6, on origin/fork/v2 6e1653b671 (#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) 518 passed
    Real-data carryover (CHROMERIA_V1_SNAPSHOT_SOURCE) 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.

  7. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    What: The #171 candidate is now 8b7ce7b7c979d1b79271339799dbcac9520a9404, still one commit on origin/fork/v2 6e1653b671. 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.

  8. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    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.

    • Head 8b7ce7b7c979d1b79271339799dbcac9520a9404; base fork/v2 6e1653b6719565db2cc5094670e19e6efd3fc1ce (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.
    • 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.
    • Observer published after final review: cost remains unknown due to attribution/usage gaps, not zero spend.
    • 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.
    • Foundation Port foundation: fork/v2 branch on upstream main with replays, drops and data isolation #167 landed and final proof uses it. Port the GitHub Issues features #171 adds no write backfill; copy retains stored rows and repeat importer/hook invariance is asserted; partial-failure write-runner proof belongs to Port foundation: fork/v2 branch on upstream main with replays, drops and data isolation #167. Imported child parent links still depend on Port child threads onto upstream lineage and delegation #168 repair. No conversation fork rollup or PR lookup expansion.
    • 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.

  9. lukemaj commented on Oct 8, 2026

    @lukemaj
    ContributorAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions