Tracker intake: spawn worker sessions from assigned issues

[anirudh5harma]

Context

ReverbCode already has most of the runtime pieces needed to supervise agent work after a session exists: project registration, isolated worktrees, worker/orchestrator sessions, PR observation, lifecycle status, notifications, and dashboard visibility.

The missing product loop is issue-driven intake: a human should be able to mark an issue as ready for agent work, and ReverbCode should start exactly one worker session for it, preserve the issue context on the session, and let the existing PR/lifecycle machinery take over from there.

This issue tracks the first focused phase of that loop. It is intentionally narrower than full tracker synchronization.

Current phase scope

Build a minimal vertical slice for issue intake:

• Add a daemon-side intake loop for registered projects with issue intake enabled.
• Poll the configured issue tracker for eligible open issues.
• Define an explicit eligibility rule, such as a project-configured label, assignee, or both.
• Spawn one worker session per eligible issue.
• Save the tracker issue identifier on the session via the existing issueId field.
• Build the worker prompt from the issue title, body, URL, and relevant metadata.
• Avoid duplicate sessions for the same issue, including daemon restarts.
• Surface the issue-linked session clearly in the existing session list/dashboard.
• Keep the implementation read-only toward the tracker in this phase.

Non-goals for this phase

• No tracker status transitions.
• No automatic issue comments.
• No webhook receiver.
• No multi-provider abstraction expansion beyond what is needed to keep the current design clean.
• No new orchestration policy beyond "eligible issue creates one worker session".

Design notes

The current implementation already has several useful foundations:

• domain.IssueID exists on SessionRecord and API session responses.
• The tracker port and a read-side tracker adapter already exist.
• The session manager already accepts IssueID in ports.SpawnConfig.
• Existing PR observation and lifecycle reactions can handle the work once a PR exists.

The first implementation should reuse those pieces rather than adding a parallel task system.

Suggested flow:

flowchart LR
  Issue["Eligible issue"] --> Intake["Tracker intake loop"]
  Intake --> Spawn["Spawn worker session with issueId"]
  Spawn --> Agent["Agent works in isolated worktree"]
  Agent --> PR["PR opened by agent"]
  PR --> Existing["Existing PR observer + lifecycle"]
  Existing --> Dashboard["Dashboard status + notifications"]

Loading

Future phases

After the intake loop is working end-to-end, follow-up work can expand the lane:

• Add lifecycle-to-issue mirroring through comments and state transitions; see Tracker: mirror agent lifecycle to issue via Comment + Transition #40.
• Add richer tracker fact observation into lifecycle decisions; see Tracker observer loop: poll + ApplyTrackerFacts into LCM #35.
• Add provider-specific configuration for additional issue trackers.
• Add a webhook mode for providers that can push issue events instead of requiring polling.
• Add dashboard controls for intake rules, dry-run previews, and pause/resume.
• Add conflict handling for externally reassigned, closed, or edited issues while a session is active.
• Add policy controls for max concurrent intake sessions per project.

Acceptance criteria

• A project can opt into issue intake without affecting existing projects.
• An eligible issue creates a worker session with the issue identifier attached.
• Restarting the daemon does not create duplicate sessions for the same issue.
• Ineligible issues are ignored.
• Tracker/API failures back off and do not block the daemon or existing session workflows.
• Tests cover eligibility, duplicate prevention, spawn request construction, and restart behavior.

[anirudh5harma]

Continued in AgentWrapper/agent-orchestrator#2282 and AgentWrapper/agent-orchestrator#2283, with backend PR AgentWrapper/agent-orchestrator#2288 and stacked UI draft AgentWrapper/agent-orchestrator#2289. Closing this legacy issue.