RFC: opt-in async delegation — hand a plan-backlog backlog to a real async agent, then review the PRs with the kit #84

Type: design / RFC — not a committed build. Spun off from #82 (the /builder hallucination). #82/#83 fixed the correctness problem (never fabricate an async trigger; route to work-story). This RFC asks the separate, optional question: should the kit offer a real way to work a created backlog asynchronously, and if so, what shape?

The honest framing

Async delegation is not "the kit, but in the cloud." The kit's value — the in-chat plan-approval gate, adaptive quality gates (coverage ≥95%, security, e2e, a11y), stack-agnostic conventions read from CLAUDE.md/.claude, MCP tracker integration, verification evidence in the PR — does not travel to an external async agent (GitHub Copilot coding agent, Codex cloud, a team's own workflow). Those agents run their own loop. On the delegated path you are, in effect, using a different agent for the implementation and giving up the kit's pipeline there.

So the realistic feature is not "run work-story in CI" (basically infeasible: headless can't do MCP OAuth, and the plan-gate doctrine is interactive). It's a thin handoff + review:

1. Plan & enrich — the kit drafts/attaches the plan and writes a self-contained brief into each issue (acceptance criteria, plan, the stack's build/test/lint commands) so whatever async agent picks it up has the best possible guidance.
2. Delegate to a verified, real async agent — e.g. assign the issue(s) to @copilot via gh, only if Copilot coding agent is actually enabled / a real workflow exists (never a fabricated trigger — see fix: agent invents a /builder + GitHub Actions async trigger instead of routing to work-story #82).
3. Review the results with the kit — the async agent opens (draft) PRs; the kit's pr-review / fix-pr run on them. This is where the kit re-adds its value — the division of labor shifts from doing the work to framing + reviewing it.

What it implies / the hard parts

• No plan-approval gate on the delegated path — Copilot opens a draft PR you review after, which inverts the kit's "approve the plan first" doctrine. Would need to be reframed as a PR-review gate.
• Gates can't be enforced async — coverage/security/e2e are the kit running commands in a session. Best we can do is run them via pr-review on the resulting PR.
• Auth & tracker — the delegated agent uses its own auth (GitHub/OpenAI), not the user's MCP connectors; issue-update-style transitions may not happen the kit's way.
• External-API dependency — Copilot coding agent assignment / Codex cloud are young, changing surfaces → fragility + maintenance burden.
• Brand risk — if users delegate and skip the gates, PR quality drops, the opposite of the kit's promise. Positioning must be explicit: this trades the kit's gates for throughput; run pr-review on the results.

Open questions

• Is the demand real? (The correctness bug is already fixed; this is throughput-only.) Prefer demand-driven — build only if users ask.
• Which async target(s) to support first — Copilot coding agent (most GitHub-native), Codex cloud, or a generic "assign to a configured agent"?
• How much of the kit's conventions can we push into the delegated run (e.g. via .github/copilot-instructions.md, which the kit doesn't own) vs. a rich issue brief?
• Does the value collapse to "just use pr-review on whatever PRs show up"? If so, maybe no new feature is needed — just docs pointing users to the existing pieces.

Recommendation

Capture and wait for demand. If built, keep v1 tiny and honest: enrich issues + assign to a verified async agent + pr-review the resulting PRs, clearly positioned as trading gates for throughput. Do not attempt a full async work-story. Relates to #82, #83.