Extend pod lifecycle scope (commit vs PR/issue) with optional same-session reuse

Suggested labels: kind/feature needs-triage needs-priority needs-actor

Summary

Today, one Task = one Pod run: when a run finishes, any follow-up is a new Task (new Pod) with no session continuity. This issue proposes supporting pod lifecycle scope beyond the current commit-level behavior: allow PR-scoped or issue-scoped pod lifecycle and reuse or extend the same session so that multiple runs for the same PR/issue can share context.

Background / Current behavior

Commit-level pod lifecycle (current)

• A Task runs once in a single Pod and then terminates.
• In CI, one Task per commit means one Pod per commit; each run is an independent session.
• TaskSpawner creates one Task per issue/PR (taskspawner-{{item.ID}}). After that Task completes (success or failure) and is deleted by TTL, the spawner may create a new Task for the same issue/PR. That new Task is still a new Pod = new session, so previous context is not preserved.

Limitations

• When the same PR or issue needs multiple agent runs (e.g. review feedback, iterative fixes), each run starts a new Pod:
  • No prior conversation or context,
  • Working directory and state are reset,
  • No single “session” that spans the PR or issue.
• It would be useful to support one session per PR or per issue so that follow-up work can either reuse the same session or extend it (e.g. “continue” on the same pod/session).

Proposed behavior

1. Pod lifecycle scope

• Commit scope (current)

  • One execution (one Task) = one Pod.
  • Keep existing behavior as default.

• PR scope

  • One pod (or session) lifecycle per PR.
  • Follow-up runs for the same PR (e.g. after review) reuse or extend that pod/session instead of starting a new one.

• Issue scope

  • One pod (or session) lifecycle per issue.
  • PRs or follow-up work for that issue can reuse or extend the same session.

2. Same-session reuse and extension

• Session reuse

  • When a session is identified by PR or issue, a new Task could attach to the existing pod/session (e.g. enqueue work or run in the same session context) instead of creating a new Pod.

• Session extension

  • While a session is active:
    • New prompts/tasks could be queued onto the same session, or
    • A “continue” trigger could run additional turns in the same pod.
  • Session lifetime policy (TTL, max idle, etc.) could be configurable.

Expected benefits

• PR/issue-level context so review iterations and repeated fixes can reuse prior conversation and state.
• Backward compatible: keep commit-level execution as default and enable PR/issue-scoped session optionally.
• Fewer cold starts by reusing the same pod/session where appropriate.

No files or tests are named. Start by tracing the Task and TaskSpawner lifecycle described in the issue, then determine how commit, PR, and issue scope would identify and retain a session. Done requires a defined optional scope, reuse or extension behavior, configurable lifetime policy, and unchanged commit-level default behavior.