Skip to content

Issues pane: live roadmap view (dependency order, blocked/ready, live work) toggled with the milestone view #13

Closed

Description

@tannerpolley

Request (owner, 2026-10-12)

The issues pane should become a live roadmap: a to-do list of the issues still to resolve, in execution and dependency order.

  • A toggle switches between this roadmap and today's milestone view.
  • Each row shows whether the issue is blocked or ready.
  • Each row shows a live indicator when the issue is being worked on now, connected to its thread, branch, worktree, pull request or delegated worker.

Today

  • apps/web/src/components/issues/issueTree.logic.ts: groupIssuesByMilestone groups by milestone and sorts each group by updatedAt, newest first. Nothing in it reflects order or dependencies.
  • packages/contracts/src/issue.ts: IssueSummary has no dependency or sub-issue fields.
  • T3 already has live work state (IssueWorkStatus in packages/contracts/src/issueWork.ts, ThreadLinkedIssue in threadIssue.ts), but it only covers repository-managed issue work.

Design

  1. Dependencies come from GitHub's native issue relationships only. Use the Issue blockedBy/blocking connections (also issueDependenciesSummary) and the parent/subIssues connections. Do not parse issue bodies.
    • Add blockedBy: IssueRef[] (open and closed) and parent: IssueRef | null to IssueSummary.
    • A blocker in another repository is shown but not ordered.
  2. The view toggle is "Milestones | Roadmap" in the pane header, remembered per repository. The milestone view stays exactly as it is today.
  3. Roadmap order. The list holds open issues only.
    • Run a topological sort over open blocker → blocked edges; closed blockers impose nothing. An open sub-issue also comes before its parent.
    • Break ties by milestone, in the milestone view's group order, then by issue number, oldest first.
    • If a cycle remains, list those issues by number and badge them "dependency cycle".
    • Sections, top to bottom:
      • In progress: has live work.
      • Ready: no open blockers.
      • Blocked: shows "blocked by #a, #b", each a link.
    • Within each section the topological order holds.
  4. Live indicator.
    • An animated "working" icon shows while any linked thread, task or worker has a running turn. A distinct icon shows for waiting on you, and a quiet icon for linked but idle.

    • The tooltip lists each linked thread's title, branch, worktree and pull request. A click opens the thread.

    • Link sources:

      • (a) existing repository-managed issue work and ThreadLinkedIssue;
      • (b) a pull request linked to a thread (link_pull_request) that references the issue;
      • (c) a new link_issue MCP tool, mirroring link_pull_request, so any thread or delegated child can register the issue it works on without becoming repository-managed issue work.

      Today delegate_task's issue parameter fails with "repository orchestrator is unavailable or paused" unless a repository orchestrator owns the issue, so plain orchestrator threads cannot link their workers.

  5. Liveness. The view refreshes on the existing issue refresh path. Dependency, label and work-state changes appear without a reload.

Acceptance (tannerpolley/ePC-SAFT, which records native Blocked by)

Out of scope

Editing dependencies from T3, manual ranking, and closed issues in the roadmap.

Activity

  1. tannerpolley commented on Oct 14, 2026

    @tannerpolley
    OwnerAuthor

    Two calls made during review (2026-10-13). Say if you want them the other way:

    • An open issue with any linked thread counts as In progress, whether the thread is working, waiting or idle. A finished builder waiting for review keeps the issue In progress rather than dropping it back to Ready.
    • Within the roadmap's dependency order, ties break by milestone, then Project Priority (Show GitHub Project Status and Priority in the issue panel #29), then issue number.

    Performance limits from the review:

    • Issue relationships and closing pull requests are fetched only for Roadmap reads; the Milestones view keeps Show GitHub Project Status and Priority in the issue panel #29's 1-point query.
    • The cross-reference timeline is not used, because mentions aren't work.
    • Live-work state comes from targeted queries, never the full thread snapshot.
    • Only page 1 refreshes every 60 s, as before.
  2. tannerpolley commented on Oct 14, 2026

    @tannerpolley
    OwnerAuthor

    Done on main (ca4dcec…7654bc3695); ships in v2.12.

    • Roadmap view: the Issues pane and thread details can switch between Milestones and Roadmap, remembered per repository. Roadmap orders open issues by blocked-by and sub-issue links, with cycles detected, and groups them into In progress / Ready / Blocked. Ties break by milestone, then Project Priority, then issue number.
    • Live work: each issue shows working / waiting / idle indicators that open the linked thread. Links come from managed issue work, the new link_issue/unlink_issue agent tools, and threads whose own pull request closes the issue.
    • Cost:
      • Relationships are fetched only for Roadmap reads: 2–3 GraphQL points per 100 issues, while Milestones stays at 1.
      • No timeline reads, and only page 1 refreshes every 60 s.
      • Live-work lookups use three partial indexes (fork migration 9). Measured on a copy of the real database (2,075 threads): ePC-SAFT 61.8 ms → 0.02 ms; upstream t3code 4.4 s → 0.05 ms. A test fails if the query plan scans the threads table again.
    • Review: reviewed by Opus over three rounds; the third replaced JSON scans with indexes.
    • Not yet checked: the UI in a real client. That happens in the v2.12 sandbox pass.
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

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions