Proposal: agent task lists are per-process and ephemeral — let agents persist plans as draft issues

# Proposal: agent task lists are per-process and ephemeral — let agents persist plans as draft issues

## Motivation

`buzz-dev-mcp`'s `todo` tool is how an agent decomposes work into steps. Its own module doc describes the storage:

> In-memory session task list with `_Stop` and `_PostCompact` hooks.
> …
> State is per-process (`Vec` behind a `Mutex`). Items are `{text, done}` — no ids; the LLM provides a full replacement list.

The surrounding machinery shows the list is treated as important:

- `_Stop` returns objection text if the agent tries to end a turn with open items.
- `_PostCompact` re-injects the full list after context compaction/handoff.
- Replacing the list while dropping an open item triggers a soft warning.

So Buzz already cares that an agent finishes what it planned. But the plan itself:

- **dies with the process** — a crash, restart, or harness swap loses it entirely;
- **has no ids**, so nothing external can reference a single step;
- **is invisible to humans** — it lives in the agent's session, not in the workspace;
- **cannot be reviewed before the work happens.**

That last point is the one that motivates this proposal. Today an agent's intent only becomes visible through its effects.

## What already exists that this could build on

Buzz already has the durable primitive:

- `buzz issues` — NIP-34 issues (`create`/`get`/`list`/`status`)
- a **draft** status already exists — `KIND_GIT_STATUS_DRAFT` (1633) in `buzz-core`'s `kind.rs`, and `buzz issues status` accepts `draft`

A `draft` issue is, semantically, exactly "proposed but not accepted."

## Proposed solution

An **opt-in, per-agent propose mode**: the agent explores read-only, decomposes the work, and persists its task list as `draft` issues with rationale — executing nothing. A human reads the plan as ordinary issues, accepts or edits it, and execution is dispatched afterwards.

Minimal first slice:

- a way for `todo` (or a sibling tool) to persist the current list as draft issues, with stable ids per item;
- a per-agent setting that makes an agent propose rather than act;
- linkage from each draft item back to the session/turn that produced it.

The tool's existing shape mostly carries over — the change is where the list lives and whether the agent proceeds.

## Why this shape

- **Two-key safety.** Propose (cheap, read-only, reviewable) → approve → execute (privileged). A proposing agent needs no write access at all, so the blast radius of a misbehaving plan is zero.
- **Relevant to the ACP permission default.** `buzz-acp` defaults `--permission-mode` to `bypassPermissions`, which skips the per-tool-call permission flow. A propose-only agent doesn't need that flow, because it isn't acting. This is a way to get a reviewable checkpoint without adding blocking prompts to a chat UI.
- **Plans survive.** Compaction, handoff, restart, and crash currently lose the list; `_PostCompact` exists precisely because that hurts.
- **The channel is the UI.** No new panel surface required.

## Open questions

- **Round-trip cost.** This must be opt-in per agent — it would be wrong as a default, since many agents should just get on with it.
- **Who executes an accepted plan?** The same agent in a second, privileged pass; a different agent; or a human. This proposal deliberately doesn't decide.
- **Issue volume.** One issue per task could be noisy. An alternative is one draft issue per plan, with items as a checklist — probably the better v1.
- **Overlap with #3871.** Configurable orchestration workflows include per-run artifacts (plans, diffs, summaries) that later steps read. That covers plans *inside a workflow run*; this covers an agent's own task list outside one. If the maintainers would rather these be one mechanism, that's a reasonable outcome — happy to fold this in.

## Duplicate search

Searched open and closed issues for task-list persistence, ephemeral todos, and agent draft plans — none found. Closest related:

- **#3871** — configurable orchestration workflows (run artifacts; see overlap above)
- **#3863** — native signed extension panels (a different surface for showing state)

Happy to take direction on scope before writing any code.

Start with the todo tool's module documentation and its _Stop/_PostCompact hooks, then inspect buzz-core's kind.rs and the buzz issues status path for existing draft support. Done means the opt-in propose-mode scope, persistence and linkage model, and execution boundary are agreed before implementation begins.

Written by the indexing model from the issue text.