autopilot chain command with --epic and --issues flags

[chanakyav]

Parent Epic

Part of #52 — Sequential stacked PR chains

Summary

Implement the autopilot chain CLI command with two input modes:

• autopilot chain --epic <N> — fetch sub-issues from GitHub issue #N via GraphQL, run as sequential stacked chain
• autopilot chain --issues 51,52,53 — explicit list of issue numbers, run as sequential stacked chain

Each sub-issue becomes a task that runs the full review-fix loop. Tasks execute one at a time in order, with each PR targeting the previous task's branch (stacked PRs). Uses standard git checkout for branch switching (no worktrees).

CLI Design

autopilot chain --epic 52                        # all sub-issues of #52
autopilot chain --issues 51,52,53                # explicit issue list
autopilot chain --epic 52 --only 51,53           # subset of epic's sub-issues
autopilot chain --epic 52 --plan                 # plan mode for all tasks
autopilot chain --epic 52 --model gpt-4.1        # model override for all tasks
autopilot chain --epic 52 --max-iters 3          # iteration limit per task

Changes

github_api.py

• Add get_sub_issues(issue_number) via GraphQL (issue.subIssues connection)
• Returns list of dicts: [{number, title, body, state}] in GitHub's order
• Handle GraphQL errors gracefully — if subIssues field is not available, raise clear error

cli.py

• Add cmd_chain(args) function
• For each issue in order:
  1. Create task with prompt from issue body
  2. Set parent_task_id to previous task's ID (NULL for first)
  3. Set epic_id to a generated chain ID
  4. Set base_branch: first task = get_default_branch(), subsequent = previous task's branch
• Sequential runner: git checkout <branch>, launch task in tmux, wait for COMPLETE, repeat
• Task FAILED mid-chain: stop, report which failed, remaining stay in INIT

cli_parser.py

• Add chain subcommand with --epic, --issues, --only, --plan, --model, --max-iters, --dry-run

chain.py (new module)

• run_chain(tasks, config) — sequential runner: launch each task, poll for completion, start next
• Chain state tracking and failure handling

persistence.py

• create_task() accepts parent_task_id, epic_id, base_branch (from Schema: parent_task_id, epic_id, base_branch, upstream_sha columns #55)
• get_chain_tasks(epic_id) — list tasks in chain order (from Schema: parent_task_id, epic_id, base_branch, upstream_sha columns #55)

Depends On

• Schema: parent_task_id, epic_id, base_branch, upstream_sha columns #55 (schema: parent_task_id, epic_id, base_branch)
• base_branch support for stacked PRs #54 (base_branch support in prompts and orchestrator)

Error Handling

• --epic N where #N has no sub-issues: clear message suggesting --issues
• Sub-issues API unavailable: clear fallback message
• Task failure mid-chain: stop, report, remaining in INIT
• Must provide --epic or --issues (not both, not neither)
• --only only valid with --epic

Testing

• --epic fetches sub-issues via GraphQL mock, creates correct chain
• --issues creates tasks in specified order
• --only filters subset of epic sub-issues
• Correct base_branch chain, parent_task_id chain, shared epic_id
• Sequential runner: task 1 COMPLETE triggers task 2 (with branch checkout)
• Task failure: remaining tasks stay in INIT
• No sub-issues: clear error
• Dry run shows plan without executing

[chanakyav]

Architecture Note: File Placement

The chain command introduces two significant pieces of logic:

1. Parser (--epic, --issues, --only, etc.) goes in cli_parser.py (recently extracted from cli.py for this purpose)
2. cmd_chain() handler goes in cli.py
3. Sequential runner loop goes in a new chain.py module — not in orchestrator.py or cli.py. This is the core chain orchestration logic:
   • run_chain(tasks, config) — launch tasks sequentially, wait for COMPLETE
   • Chain state tracking and failure handling

Tests go in a new test_chain.py.

This prevents cli.py (now ~750 lines after parser extraction) and orchestrator.py (1,357 lines) from bloating.