Proposal pool

The pool is the junction between discovery and delivery. Analysis yields proposals, proposals pool and compete, and promotion out of the pool is the moment an epic is born. The pool exists because spec’ing is the expensive stage — prioritization must happen before the costly work, not after.

Proposals and sibling sets

A proposal (PRP-n) is a candidate piece of work: problem, approach, trade-off note, estimated scope and impact, affected repositories. Every proposal — including ones you write by hand — is anchored to at least one source report, which is what keeps the provenance chain unbroken.

Proposals group into sibling sets: competing approaches to one problem. The set carries the problem statement; the proposals are the answers. Independent proposals are simply sets of one. The set is the unit the pool orders, blocks, prunes, and promotes.

Most proposals arrive automatically: when an intent’s analysis settles, a derivation agent reads the reports and drafts proposals — deduplicating against what’s already open, adding alternatives to existing sets rather than creating twins. Derivation is all-or-nothing: a failed run inserts nothing and stays visible and retryable.

Ordering, dependencies, pruning

• Priority bands — urgent, high, medium, low — with free reordering inside each band. Ordering is entirely keyboard-accessible: Space grabs an entry, arrows move it (crossing bands re-prioritizes), Space drops; 1–4 set the band directly.
• Dependencies — an “after: X” edge between entries, with cycle prevention. Entries with unmet dependencies sit in the Blocked tab and flip to Ready — live — the moment the prerequisite epic completes.
• Pruning — declining a set requires a reason, and pruned sets are archived, not deleted; restore is one action. Nothing disappears silently.

Agents read the pool in exactly the order you see it: stella pool show returns the same ranking the screen renders.

Promotion — where epics are born

Promoting a sibling set out of the pool creates the epic, atomically, and it is deliberately the only way an epic can be created — in the UI, the API, or the CLI. Promotion passes the epic.promote checkpoint, which requires human approval by default: this is the loop’s cost-commitment point.

Two modes:

• Prune-first (default) — promote one chosen sibling; the epic starts with a single candidate. For sets of one this is implicit.
• Tournament — promote the whole set into one epic with one candidate per sibling, each implemented on its own branch, with review selecting the winner on results. See Epics and tasks.

The promote dialog shows the engine’s promotion guidance: a recommendation (prune or tournament) with its rationale and per-mode cost estimates, computed from three signals — how divergent the approaches are, how high the stakes, and whether the budget has headroom. A tournament is recommended only when all three hold.

Promotion outcomes are structured everywhere: created, held for approval, denied with a reason, blocked on named unmet dependencies, or conflicted (someone promoted it first). The CLI exits non-zero on blocked and names every unmet prerequisite.

Working with the pool