Issues → Kanban: a provider-agnostic task board with GitHub-issue import

[serge-ivo]

Problem

AgentCoder had a GitHub-issues kanban; the PAGS port scaffolded the DB columns (coding_sessions.issue_number/issue_title) but never wired the API or UI. There's no backlog/board for the coding agent.

Approach

Lead with an internal, provider-agnostic task model (keeps us multi-provider, works for local-only repos), with GitHub-issue import as the first adapter.

• New coding_tasks table (per repo): id, repo_id, title, body, status (todo/doing/needs-you/done), source (manual | github), external_ref (issue #/url), created/updated.
• Board: reuse the generic renderKanbanBoard. Columns ~ Ready · Working · Needs you · Done. A card's status comes from the live session run-state (the work I shipped: working/ready/needs-you).
• Tap a card → opens/starts the coding session for that repo targeting the task (the issue_number/issue_title plumbing already exists).
• Optional "Import GitHub issues" (when the GitHub App is installed) creates task cards from open issues; future adapters: GitLab/Bitbucket.

Scope

• Migration + lib/coding-tasks.ts (D1 CRUD) + routes (/coding/tasks CRUD, /coding/issues/import).
• A "Board" surface for coding agents (new console view).

Acceptance

• A coding agent shows a board of tasks; create a task manually OR import GitHub issues; clicking a task starts/visits the session; card status reflects live agent state.

Notes

Reuses renderKanbanBoard, the capability registry, and the live status work. Provider-agnostic by design so it's not GitHub-locked.

[serge-ivo]

Status update after code audit: partially shipped, but not complete as written. Shipped: coding agents now have a Board surface and 'Work on this' starts/visits work for GitHub issues. Still missing from this ticket: the provider-agnostic coding_tasks table/CRUD, manual task creation, and adapter-style GitHub issue import into internal tasks. Keep open, but it should be narrowed to the remaining provider-neutral task model/import work.

[serge-ivo]

Largely delivered since this was written. The premise — "never wired the API or UI. There's no backlog/board for the coding agent" — no longer holds:

• agents/coder/web/src/RepoIssues.tsx — GitHub issues per repo, fetched cloud-side, each row with Work on this (which now hands the issue to the Loop, i.e. it starts work rather than pre-filling text).
• github_list_issues / github_read_issue / github_create_issue are declared registry tools on the Repo Coder.
• store/console/src/tabs/BoardTab.tsx + the coding-session cards from [coordination] Ticket 2 — make coding work visible to a supervisor (domain writes) #206 put agent work on a real board backed by instance_runtime_tasks.

What is genuinely still open from this ticket is the provider-agnostic part — and that now overlaps #221 (GitLab/Bitbucket).

Also worth reconciling against #150, which proposes agent work as first-class Tickets. There are now three conceptions of "the board" in the tracker (this, #150, and the shipped instance_runtime_tasks cards) and nothing says which one wins.

[serge-ivo]

Closing: substantially delivered, and what remains is tracked elsewhere.

• GitHub issues per repo with a Work on this action: agents/coder/web/src/RepoIssues.tsx (it now hands the issue to the Loop, so it starts work rather than pre-filling text).
• github_list_issues / github_read_issue / github_create_issue are declared registry tools on the Repo Coder.
• A real board backed by instance_runtime_tasks: store/console/src/tabs/BoardTab.tsx plus the coding-session cards from [coordination] Ticket 2 — make coding work visible to a supervisor (domain writes) #206.

The provider-agnostic half is #221 (GitLab/Bitbucket). The "what is a unit of agent work" question is #150, which should be reconciled against the shipped board rather than restated here — noted in #250.