Map: the issue queue as a first-class surface in T3 Code

[radroid]

Destination

Decide what the fork builds, defers, or upstreams in order to make the GitHub issue queue a
first-class working surface inside T3 Code — a visible wayfinder map, skill invocation that actually
fires, a skill picker that routes by situation rather than alphabet, and an agent that works the
queue. Done when every piece has a verdict, an order, and the evidence behind it.

Notes

Domain. The fork, radroid/t3code. Fork-owned namespaces are apps/server/src/coil/,
apps/web/src/coil/, packages/contracts/src/coil/ — not t3x/; the rename moved them and
some docs are still stale. Every edit to an upstream-owned file takes a row in
docs/t3x/SEAMS.md, updated in the same commit. Tracker conventions, including the frontier query
and the sub-issue/dependency commands, live in docs/t3x/agents/issue-tracker.md.

Skills each session should consult. /grilling and /domain-modeling by default. /research
for AFK research tickets. /prototype where the question is "how should it look or behave".

Standing preferences.

• Plan, don't build. Experiments are in scope as task/research tickets because they unblock
  decisions. Feature implementation is not — the map hands off to /to-spec → /to-tickets.
• HITL by design. This effort spends a human's time and an agent's together. Its product is
  tickets a looping agent can then take unattended.
• Nothing goes upstream. Upstream is not accepting contributions at present, so every fix lands
  fork-local and pays a seam row. This is a change from the usual "prefer upstreaming" posture and
  it is load-bearing for ticket ordering.
• Web and desktop only.
• Order: panel → invocation → routing → maintainer agent.

Ordering rationale. The panel is the highest-value piece (it removes the constant bounce between
the Issues list and the chat). The maintainer agent is last because an agent autonomously running
skills you cannot yet reliably invoke, against a queue you cannot yet see, is the riskiest possible
first move — and its verdict may legitimately come out "defer".

Decisions so far

None yet.

Not yet specified

• The handoff seam into the loops map. ask-matt is explicit that a cleared map merges onto the
  main flow at /to-spec, then /to-tickets, then /implement. How that handoff physically works
  — and where it meets the separate loops effort ([Feature]: supervise long-running threads — turns complete while background subagents are still working, and nothing restarts the run #38, [Feature]: Self-paced loops — the Claude binary can already wake a T3 thread; surface it, bound it, and give models a durable T3-native wake_me instead #42) — cannot be specified until the panel's
  shape is known.
• Whether the panel later renders non-wayfinder issues. Deliberately not chartered now; the
  general issue list is a browser tab that already works.
• [Feature]: maintainer agent — work a repo's issue queue automatically (triage → plan or draft PR → human approval) #44's machinery. GitHub polling cadence, rate limits, per-project enablement, thread
  bootstrap, safety rails. All real, all blocked behind whether [Feature]: maintainer agent — work a repo's issue queue automatically (triage → plan or draft PR → human approval) #44 survives at all.
• A concrete oddity worth chasing. The $ picker displays every skill as scope "Project",
  including ones resolved from ~/.claude/skills, which ClaudeSkills.ts:102-104 scopes as
  user. Either a display bug or a misreading of the resolution order. Not yet sharp enough to
  ticket — it may fold into the invocation work.

Out of scope

• [Feature]: Provider-agnostic orchestration ("ultracode for every model") — a fork-owned MCP toolkit that lets any adapter fan out into real T3 threads #43 — provider-agnostic orchestration. Upstream is actively rebuilding this layer: PR feat(orchestrator): introduce new orchestrator pingdotgg/t3code#2829
  (orchestrator v2) is open and moving, and PR feat: scheduled tasks (automations) pingdotgg/t3code#3638's scheduled-tasks work is still not an ancestor
  of upstream/main. Revisit once v2 lands; building against today's main risks a rewrite.
• Loops — [Feature]: supervise long-running threads — turns complete while background subagents are still working, and nothing restarts the run #38 (Loop Watch) and [Feature]: Self-paced loops — the Claude binary can already wake a T3 thread; surface it, bound it, and give models a durable T3-native wake_me instead #42 (self-paced loops). Their own map. They split from this one
  on a real seam: loops are about keeping an agent running; this map is about what you point it at
  and how you watch it. Higher priority to work, but charted separately.
• Mobile. Doubles the surface for the piece least likely to be used on a phone.
• Upstreaming anything, including the $ picker fix, for as long as upstream declines
  contributions.