Discussion: expand Mission from a promoted thread into a real multi-day mission (plan, orchestrator, executors, validators)

[devin-ai-integration]

Why this issue exists

Scoping #102 (channel-first missions, plan in
#143) surfaced that "Mission" as currently
planned is smaller than the concept we actually want. The founder's framing:

mission needs to be expanded […] it is not about a toggle and mark a thread as mission […]
mission in my mind is something can be run really long, up to a few days, has real mission,
orchestrator, validator, executor — check Factory Droid mission

This issue is a discussion record, not a work order. It captures where the feature stands,
what the expanded concept looks like, and the questions we need to answer before anyone plans
slices. It is deliberately not ready to implement and takes no decision number.

1. What is already settled and shippable

#143 is a plan-only, docs-only scope for #102 and
should ship as the durable spine. Its finding still holds and does not change under the
expanded concept:

Everything a Mission displays is already durable on the relay — except the fact that it is a
Mission.

Settled founder decisions recorded there:

• Promotion wire shape: owner-authored kind 9 carrying ["crew-mission","promote"] and
  ["crew-mission-goal","<title>"] with the normal h + NIP-10 e tags. No new event kind.
• Not the deferred board schema: the marker is thread-scoped with no lane, column, order or
  priority. Tripwire: the moment anyone wants priority or ordering on a Mission, the work
  stops and returns to the founder as a fresh decision.
• Promote anywhere: outside a Project there is no isolated checkout (worktree provisioning is
  fail-closed on trusted buzz://project-workspace? metadata), and the UI must say so plainly
  rather than failing mysteriously.
• Promotion is a manual toggle, and a Mission is never inferred from a worktree, a receipt, or
  agent telemetry. The valid marker is the only Mission authority.
• Mission state is a pure projection over relay events. The in-memory stores a naive
  implementation would reach for are forbidden by name as Mission authority
  (conversationOutcomeLedger 4h TTL, needsYouStore 30m TTL, activeAgentTurnsStore) because
  each would make a Mission silently un-complete itself.

That spine is a prerequisite for everything below: a mission that runs for days cannot be built on
state that expires in four hours or dies with the app process.

2. The expanded concept

Working definition to argue with:

A Mission is a named goal with a durable plan, a long-lived orchestrator that decomposes
it into work items, executors that do those items in isolated checkouts, and validators
that gate each milestone against success criteria agreed up front — all of it happening as
messages in one channel thread.

The marked thread is not the Mission; it is where the Mission lives.

3. Factory Droid Missions — the closest existing reference

Read from Factory's docs (https://docs.factory.ai/missions/overview,
https://docs.factory.ai/missions/planning, https://docs.factory.ai/missions/running-cli), not
inferred:

• /missions starts a planning conversation — back-and-forth, clarifying questions, not a
  one-shot prompt. Factory's own claim is that the planning phase is where most of the value is.
• Planning produces a structured plan: features grouped into milestones, each with success
  criteria and the skills needed.
• The human approves the plan before execution begins.
• An orchestrator agent then runs it from "Mission Control", dispatching roughly one feature
  worker per feature and validator workers at the end of each milestone, which QA the
  running application and self-correct.
• The human's job becomes project management of agents: monitor, unblock, redirect, pause the
  orchestrator and tell it what you are seeing. Explicitly not fire-and-forget.
• Rough budget: runs ≈ #features + 2 × #milestones, described as a floor.
• Factory states three of its own open questions: whether parallelism actually helps, how to stop
  long plans accumulating errors, and where the cost/quality line sits.

The one thing we should not copy: Mission Control is a dashboard. FOUNDER-PRODUCT.md is
explicit that Crew must not become a mission dashboard that users manage instead of talking in
channels. The Crew version of every Mission Control affordance should be a thread event:

Factory	Crew equivalent
Mission Control view	the promoted thread itself
Plan awaiting approval	a plan message you can argue with, then approve
Feature worker running	agent presence + live state in the thread
Milestone validation verdict	a receipt/evidence message in the thread
Worker stuck / retry limit hit	a "Need you" question inline
Pause and redirect the orchestrator	reply to it

4. What this would ride on — existing seams, not new machinery

Most of the concept has a home on the wire already, which is the point of checking before
designing:

• Orchestrator / executor / validator lifecycle: job kinds 43001-43006 and workflow kinds
  46001-46007; buzz-workflow already exists as a YAML-as-code engine.
• "Approve this plan before we spend days on it": the durable approval kinds 46010-46012.
• Milestone result: 46043 receipts.
• Validator output and human accept/reject: the evidence + NIP-25 reaction work in
  #121.
• Who does what: orchestrator and validator most likely want to be two more roles in
  #116's taxonomy, not a parallel assignment
  model beside it.
• Questions and cancellation mid-mission: the ACP user-input kinds 46040-46042.

None of the above is a commitment — it is the seam inventory the discussion should start from,
per the "extend Buzz's model, do not clone it" rule.

5. Two hard problems the expanded concept creates

1. "Days long" is a much higher durability bar than Channel-first missions: promote a thread into durable agent work in place #102 plans for. Channel-first missions: promote a thread into durable agent work in place #102's slices prove a
   Mission survives an app restart. A multi-day mission must survive the agent process dying,
   the machine rebooting, and the laptop closing mid-milestone — which means the orchestrator's
   next action has to be recomputable from relay events alone, not held in process memory. This
   is the load-bearing engineering requirement of the whole idea and it is bigger than anything in
   Channel-first missions: promote a thread into durable agent work in place #102.
2. Self-validation has a prerequisite Crew does not have. Factory says missions only work at
   "readiness level 4": one command to stand the app up, logs written to disk, and a programmatic
   way to drive the app like a user. #119's
   readiness is agent profile readiness, which is not the same thing. A validator that cannot
   actually run the app only rubber-stamps.

6. Open questions for the longer discussion

Not to be answered on the fly:

• Where does the plan live on the wire? A structured message in the thread, an addressable
  event, or a file in the repo the mission works on? Whatever we pick, it must be editable across
  days and re-readable after a restart.
• Milestones without becoming the deferred board. Milestones are ordered by nature; the
  current tripwire says ordering on a Mission returns to the founder. Does ordering inside one
  mission's plan fall under that tripwire or outside it?
• Approval granularity: approve the whole plan once, or approve each milestone as it comes up?
• Sequential or parallel executors? Factory has not settled this. Crew's constraint is
  concrete: worktree-per-thread, and concurrent multi-agent mutation of one worktree is already a
  non-goal.
• What does the founder see after eight hours away? The honest answer today is "scroll the
  thread", which is probably not good enough for a multi-day mission — and this is exactly where
  the deferred work-overview lens becomes tempting.
• Cost and duration visibility. #features + 2 × #milestones runs is real money and real
  hours. Does the thread show a budget up front, and warn as it burns?
• Failure policy: retry limits, when the orchestrator gives up, and what a half-finished
  multi-day mission leaves behind in the repo.
• How does a Mission end? Merged PR, owner acceptance, or the plan's success criteria being
  met — and who decides when those disagree.
• Does a single message inside a thread become its own Mission? Raised and deliberately left
  open; it changes what a Mission is identified by (the anchor), and whether missions can nest.

Definition of done for this issue

None yet — this is a discussion issue. It is done when we have agreed what a Mission is well
enough to write a scope for it. Concretely:

• Ship the durable spine (Channel-first missions: promote a thread into durable agent work in place #102 / docs(plans): scope #102 channel-first missions — projection-first, 5 slices, D-1/D-2/D-3 settled #143) and treat it as the foundation.
• Hold the longer discussion on the expanded concept, using §6 as the agenda.
• Only then open a scoped epic for the plan/orchestrator/executor/validator model, in the
  channel-first style, stating plainly that the orchestrator ships after the spine.

Nothing here is implemented, no decision number is taken, and no plan slices exist for §2-§6.

[oscarlehuu]

Handover-at-completion — a gap noted while brainstorming, parked here for the Mission scoping to absorb.

Routing (#148) solves the entry gate: work arriving at the wrong agent gets refused and redirected (the prompt section lists work-type → role → holder npubs, and the role section mandates refuse-and-redirect with ROLE-CHECK). What it does not cover is the exit gate: agent A finishes its part of a larger piece of work and the next part belongs to another role. Today nothing obliges A to hand off — it may mention B (it has the npub), but the handover quality is whatever the context refetch window happens to carry.

Cheapest conceivable form: a 3–4 line prompt rule in the routing section ('when your part is done and the work is not, mention the holder of the next role with a structured handover summary' — same weight class as the #121 evidence rule, no new kinds, no new machinery). The structured-note pattern from #173 (guided handover) is reusable here rotated 90°: agent→agent instead of old-session→new-session.

Deliberately not filed as its own issue: pairwise handover is subsumed by the orchestrator/executor/validator concept this discussion owns. When Missions get scoped, decide whether handover lives at the prompt layer (cheap, works outside Missions too) or the orchestrator layer (controlled, Mission-only) — or both, prompt rule first as the building block.