@koda-sl/baker-cli 0.91.0 → 0.93.0

package/README.md

@@ -2322,6 +2322,8 @@ baker actions release <action-id>
 
 baker actions create --name "Build hero" --description "..."
 # → returns { ok, data: { tempId }, hints: [...] } — check hints for dependencies/description reminders
+baker actions create --name "Pull data" --description "..." --mission <ref> --order 0
+# → creates the action AND attaches it to the mission as a step in one atomic op (no loose-action flicker)
 baker actions update <action-id> --name "Better name"
 baker actions complete <action-id-or-tempId> --note "What was done"  # stages — applies on chat publish
 baker actions discard <action-id> --reason "obsolete"
@@ -2361,6 +2363,44 @@ Permissions enforced server-side:
 
 ---
 
+### Missions (`baker missions`)
+
+A **Mission** groups an ordered set of actions (its "steps") under one goal, with a markdown **overview** (the human-readable plan). Use a mission whenever a request decomposes into 2+ ordered actions — audits, campaigns, multi-step plans. A single one-off capture stays a loose action.
+
+Mission write ops stage on the **same chat draft as actions** and apply atomically on the existing publish — there is no separate apply. `BAKER_CHAT_ID` must be set for every command except `list`/`get`.
+
+```bash
+# 1. Open the mission FIRST with the detailed plan (the overview is the point).
+#    Returns { ok, data: { missionTempId }, hints }.
+baker missions create --title "Audit Google Ads" --overview "## Phase 1 — Pull data\n..."
+
+# 2. Create each step already attached to the mission, in order. This is the
+#    preferred path: create+attach is one atomic op, so a step never appears as
+#    a loose action between create and attach.
+baker actions create --name "Pull data" --description "..." --mission <missionTempId> --order 0
+baker actions create --name "Analyze" --description "..." --mission <missionTempId> --order 1
+
+# Attach an already-existing action to a mission (when it wasn't created with --mission).
+# Both --mission and --action accept a real id or a temp_* ref from the same draft.
+baker missions add-action --mission <id-or-missionTempId> --action <id-or-tempId> --order 0
+
+baker missions update <mission-id> --title "..." --overview "..."   # real id only
+baker missions set-status <mission-id> --status accomplished        # active | accomplished | aborted
+
+baker missions list [--include-aborted]   # per-mission progress (done/total) + ordered steps
+baker missions get <mission-id>
+```
+
+Rules:
+
+- **The overview is forward planning** — write it as numbered Phases (goal / what it produces / what unlocks next), with **no calendar framing** (dates, deadlines, ETAs) and **no effort framing** (quick-win, MVP, t-shirt sizes).
+- **Publishing the chat = the user approving the plan.** The mission and its ordered steps apply atomically; the dashboard then shows the mission grouped, ticking off as steps complete.
+- **Mark `accomplished` only when the goal is genuinely met**, `aborted` if abandoned — never auto-conclude from step status.
+- Hard dependencies between steps still go through `baker actions link`; missions (ordering) and dependencies (blocking) are orthogonal.
+- All staged mission ops revert automatically if the chat is discarded.
+
+---
+
 ### `baker schema [command]`
 
 Inspect command argument schemas for AI agent introspection.