@aicopycoders/exodus 2026.8.1400 → 2026.8.1600

package/assets/skills/exodus-meme/SKILL.md

@@ -7,8 +7,8 @@ description: Generate meme-style ad creative for the active brand — recommends
 Subcommands (three; the batch renders server-side):
   exodus meme recommend --brief "<text>" [--avatar "<text>"]
   exodus meme run --brief "<text>" --formats '<json>' [--formats-file <path>] [--avatar "<text>"] [--name "<label>"]
-  exodus meme regenerate --brief "<text>" --layer 1 --template-id <id> --template-name "<name>" --boxes <N>
-  exodus meme regenerate --brief "<text>" --layer 2|3 --format <formatId> [--hint "<text>"]
+  exodus meme regenerate --brief "<text>" --layer 1 --template-id <id> --template-name "<name>" --boxes <N> [--id <runId>]
+  exodus meme regenerate --brief "<text>" --layer 2|3 --format <formatId> [--hint "<text>"] [--id <runId>]
 
 Flow:
   1. recommend → { recommendations: [...] } — 15 picks (5 per layer), each with
@@ -20,9 +20,13 @@ Flow:
   3. Poll: exodus workflow status --id <runId>
      Memes render through the Image Rig, so a meme run IS a workflow run — the
      workflow verb is the one that can read it, NOT `status --type creative`.
-  4. regenerate → re-render one miss, synchronously (returns image_url). Do not
-     pass its optional --id the run id from step 2 — that flag takes a
-     creative-suite run id, a different id space.
+  4. regenerate → re-render one miss, synchronously (returns image_url). Pass
+     --id <runId from step 2> so the fresh meme is saved with that run; leave it
+     off and you only get a URL that is never saved. A bad --id is a 400 that
+     names the mismatch, raised before anything is rendered — but 400 is not the
+     only refusal: a --template-id / --format that isn't a real format is a 404,
+     and a lookup or render that breaks is a 502. Read the message, not just the
+     status.
 
 Keys (strict BYOK, refused server-side before anything starts):
   layer 1 needs the member's Imgflip login · layers 2/3 need their Kie.ai key ·
@@ -135,18 +139,54 @@ the recommend output you're still holding:
 ```bash
 # Classic (layer 1) miss:
 npx @aicopycoders/exodus meme regenerate --brief "<brief>" --layer 1 \
-  --template-id <imgflip_template_id> --template-name "<name>" --boxes <imgflip_box_count>
+  --template-id <imgflip_template_id> --template-name "<name>" --boxes <imgflip_box_count> \
+  --id <runId from step 2>
 
 # AI (layer 2/3) miss — --hint steers the re-roll:
 npx @aicopycoders/exodus meme regenerate --brief "<brief>" --layer 2 --format <format_id> \
-  --hint "make the punchline land the product"
+  --hint "make the punchline land the product" --id <runId from step 2>
 ```
 
 Regenerate is synchronous (caption + render server-side) and returns the new
-`image_url` directly. **Do not pass the run id from step 2 to `--id`** — that
-flag attaches the fresh meme to a *creative-suite* run, and since memes moved
-onto the Image Rig the id `run` prints is a workflow run id, a different id
-space. Omit `--id` and hand the user the returned URL.
+`image_url` directly.
+
+**Pass `--id` the runId from step 2** (#1164). The server matches it to the run's
+child for that format and files the fresh meme there, so it lands in the library
+beside its siblings and the user finds it where they expect. Both id spaces are
+accepted — the workflow run id `run` prints and a creative-suite child run id.
+
+**What `--id` now guarantees is the front door: a bad id is refused before you
+pay for anything.** The server resolves the id first, so a typo, an id from
+another brand, a run that made no memes, or a run with no meme in *this* format
+comes back as a 400 naming the mismatch — no caption call, no render, no credits
+spent. That is the promise; it is not a promise that nothing can go wrong after
+it.
+
+The refusals are not all 400s, so branch on the message, not the number alone:
+
+- **400** — the id didn't resolve (the message says which part didn't match), or
+  a required key is missing, or the brand couldn't be worked out ("No active
+  workspace for user"). Careful if you're reading the JSON envelope's `code`
+  rather than the status: that last one is labelled `INTERNAL_ERROR` even though
+  it is a plain 400, so route on the **status + message**, not the code.
+- **404** — the `--template-id` (layer 1) or `--format` (layer 2/3) isn't a
+  format the server knows. Re-check it against the recommend output you're
+  holding.
+- **429** — too many regenerates too fast (30 a minute). Wait and retry; the
+  response carries a `Retry-After`.
+- **502** — something broke rather than being refused: the run lookup failed, or
+  the caption/render leg threw. This one is worth retrying; a 400 or 404 is not.
+
+**One honest gap once the id resolves.** Filing the finished meme into the
+library is deliberately allowed to fail quietly — if that write breaks (a Convex
+hiccup), the route still answers **200** with the provider's own URL. So a 200
+means "here is your image", not "it is saved". If the user later can't find a
+regenerated meme in the library, that is the failure to suspect — and it is
+recoverable only by regenerating, since the returned URL expires.
+
+Leaving `--id` off is still valid and still returns the image URL, but that image
+is saved nowhere and the URL expires — only do it when the user explicitly wants
+a throwaway look.
 
 ### 5. Report
 
@@ -191,6 +231,16 @@ internals into chat.
   per-image provenance as any other rig render. That is why the poll verb is
   `exodus workflow status`, not `exodus status --type creative` — the creative
   status route reads `creativeSuiteRuns` for a Bearer caller.
+- Since #1164 `regenerate`'s `--id` accepts BOTH id spaces. The route resolves it
+  instead of casting it: a `creativeSuiteRuns` id is used as-is, a `workflowRuns`
+  id is walked to the rig child whose `memeFormat` matches this request, and an
+  id it can't place is a 400 raised BEFORE any caption or render is paid for.
+  Before that fix a CLI `--id` silently failed to save and left an orphaned blob.
+  What #1164 removed is the CAUSE, not the swallow: `persistMemeImage` still
+  catches a `recordMemeImage` failure, logs it, and returns null, and the route
+  still answers 200 with the provider URL. A genuine Convex failure is therefore
+  still a silent miss (plus an orphaned storage blob) — findable only in the
+  `[meme/persist] ORPHANED STORAGE BLOB` log line.
 - The rig's child image runs are still `creativeSuiteRuns` with engine `meme`,
   so finished memes appear in the creative-suite library alongside other engines
   and `exodus browse --agent meme` still covers them.

package/assets/skills/exodus-workflow/SKILL.md

@@ -9,7 +9,8 @@ Core — discover & run:
   exodus workflow describe <workflowId|name> [--json]        Inputs, prerequisites, outputs
   exodus workflow bots [--category <cat>] [--slug <slug>] [--json]   Bot catalog / one bot's spec
   exodus workflow run <workflowId|name> [--input key=value ...] [--fill <name>] [--auto-approve] [--wait] [--out <dir>] [--json]   Run it
-  exodus workflow status [--id <runId>] [--out <dir>] [--json]   Poll a run / read its outputs
+  exodus workflow status [--id <runId>] [--out <dir>] [--json]   Poll a run / read its outputs (no --id → the brand's 25 newest runs + their ids)
+  exodus workflow cancel <runId> [--reason "..."] [--json]   Stop a run that hasn't finished — queued, running, or parked
   exodus workflow export <workflowId|name> [--version <n>] [--out <file>] [--json]   Dump the contract (YAML)
 
 Authoring:
@@ -21,7 +22,7 @@ Authoring:
 
 Parked runs:
   exodus workflow inbox [--json]                             Every run parked waiting on you
-  exodus workflow checkpoint <runId> [show | edit <n> | approve [--reject <n,..>] [--wait] | retry [--wait] | cancel [--reason "..."]] [--json]   Resolve a checkpoint park
+  exodus workflow checkpoint <runId> [show | edit <n> | approve [--reject <n,..>] [--wait] | retry [--note "..."] [--wait] | cancel [--reason "..."]] [--json]   Resolve a checkpoint park
   exodus workflow gate <runId>                              RETIRED in 2.0 — prints a pointer at "checkpoint" and exits 1
   exodus workflow repair <runId> retry|skip|kill [--wait] [--json]   Resolve a repair park
   exodus workflow answer <runId> [--slot key=value ...] [--json]   Answer a nested workflow's slots (no --slot → list them)
@@ -79,6 +80,25 @@ An Exodus **Workflow** is a saved graph the member builds on the dashboard canva
 
 **The `--json` contract (read this once).** Every `workflow`, `session`, and `bank` verb takes `--json`, and that structured output **is** the machine API — there is no separate agent command set and no MCP server. Read for humans without it; parse `--json` when you need to chain or branch on the result.
 
+**Polling a run in `--json`: the fields that matter.** `workflow status --id <runId> --json` returns the run object as-is. The keys a poll loop actually needs:
+
+- **`status`** — the run's **stored lifecycle state**, as the machine spells it: `queued`, `running`, `awaiting-approval`, `succeeded`, `succeeded-with-warnings`, `failed`, `cancelled`. **Branch on this key, not on the printed words.** One warning: a run created before the 2.0 rename can still store the old spelling — `awaiting-review`, `completed`, `partial`, `canceled` — so treat those as the same states.
+  - **The human `status:` line is a JUDGEMENT, not this raw value.** It starts from this field and then reads the rest of the run, so the two can legitimately disagree: a run stored `succeeded-with-warnings` that delivered no slot at all prints `Failed — nothing delivered`, and a run stored `awaiting-approval` that is only waiting on a child workflow prints `Running — sub-workflow`. Neither is a bug — the printed line is the honest verdict for a human, the key is the state machine. If you need the verdict a person would see, don't recompute it from `status` alone: read `counts` and `deliveries` too, or just read the human output.
+- **`isTerminal`** — `true` once the run is finished for good and polling should stop. Trust this over comparing status strings yourself; a park is **not** terminal.
+- **`counts`** — step tallies: `done`, `failed`, `skipped`, `total`, plus `outOfScope` on runs that deliberately skipped steps outside the run's scope (absent otherwise). **This is a final tally, not a progress meter.** It is added up once, at the moment the run reaches its end — finished, failed, or cancelled — so on a run that is `queued`, `running`, or parked the key is simply **not there**. Never build a progress readout on it; count the `nodes` array yourself if you want live progress.
+- **`nodes`** — one entry per step, each with its own `nodeId`, `kind`, `status`, and `outputs`.
+- **`outputs`** — the flat pile of final deliverables, the chaining surface (see §8).
+- **`deliveries`** — the named, typed promises answered slot by slot (`delivered` / `unfulfilled`). Present on newer backends; when it's there, read it before `outputs`.
+- **`pauseReason`** — why the run parked. **Only read it when `status` is awaiting-approval**: it is left behind on a run that was cancelled out of a park, so a terminal row can still carry a stale one. **Five values are stored, and it can also be missing altogether — so always write a fallback branch, never a switch that assumes four cases:**
+  - `checkpoint`, `repair`, `slots` — each names the verb that resolves the park (`checkpoint` / `repair` / `answer`).
+  - `call` — informational. The run is waiting on a child workflow and resumes by itself when the child finishes, so there is nothing for you to do (which is also why `call` parks are kept out of `inbox`).
+  - `taste` — **frozen legacy**: a run that parked at the Gate box, which retired in 2.0. Nothing writes it any more, but old rows still carry it. It cannot be resumed — cancel the run and run the workflow again.
+  - **absent** — an old cost-gate park, from before parks recorded a reason. The run is still alive and still approvable, but **no CLI verb resolves it**: the checkpoint/repair/answer verbs all refuse it by name ("parked at the cost gate (legacy)"). Send the user to the dashboard run page to approve it there, or cancel it.
+
+Run `status --json` with **no** `--id` and you get `{ "runs": [...] }` instead — a lighter row per recent run, each carrying `_id`, `workflowName`, `status`, `pauseReason`, and `createdAt`. That is the list to search when you need a run's id.
+
+**That list is capped at the 25 newest runs, and it never says so.** Nothing in the output marks the cut-off, so a run that exists but is older than the last 25 simply isn't in it. Never read an absence there as "it didn't run" on a busy brand — say "not in the 25 most recent" and, if you have the run id, check it directly with `status --id <runId>`.
+
 **Auth is one bearer key.** `EXODUS_API_KEY` from `.env` authorizes every verb; there are no scoped tokens. If a call 401s, run `npx @aicopycoders/exodus doctor`.
 
 ## The agent operating loop
@@ -90,10 +110,10 @@ The end-to-end narrative, every step naming its verb. You rarely walk all of it
 3. **Import** — `workflow import <file>` to create, or `import <file> --update <id>` to edit in place.
 4. **Describe** — `workflow describe` to confirm inputs, prerequisites (✓/✗ primers), and outputs before spending a run.
 5. **Run** — `workflow run … --wait` (streams progress, prints outputs) or omit `--wait` and poll `workflow status --id <runId>`. Inputs come from `--input key=value` flags, from `--fill <name>` (a saved fill — a named, reusable set of launch answers saved from the app's Run dialog; flags win per key when you pass both), or a mix. Launches that don't satisfy the workflow's entry contract are rejected at the door with the gap named — `describe` shows each input's type, required/optional, and accepted values. Add `--auto-approve` only when the run is meant to go start-to-finish with nobody watching: it approves every Checkpoint the run hits, unchanged, instead of stopping for a verdict. It's a per-launch choice, not a setting on the workflow, and the run keeps a record of each stop it waved through — so confirm with the user before you pass it.
-6. **Notice the park** — a run can stop and wait on you. There are no webhooks in v1; you notice a park one of three ways: `run --wait` prints a pause notice naming the verb to use (the command keeps waiting — resolve from another shell, or Ctrl-C and pick it up via `inbox`), `workflow inbox` lists it, or `workflow status` shows `awaiting-review`.
+6. **Notice the park** — a run can stop and wait on you. There are no webhooks in v1; you notice a park one of three ways: `run --wait` prints a pause notice naming the verb to use (the command keeps waiting — resolve from another shell, or Ctrl-C and pick it up via `inbox`), `workflow inbox` lists it, or `workflow status --id <runId>` prints `status: Awaiting approval`.
 7. **Resolve** — `workflow checkpoint <runId> …` (the run reached a Checkpoint box), `workflow repair <runId> …` (a stalled collector), or `workflow answer <runId> …` (a nested workflow's slots).
 8. **Harvest** — read deliverables with `workflow status --id <runId> --json`; read banked deposits with `bank show <key>`; keep thinking with a bot via `session chat`.
-9. **Promote** — `bank promote <key>` lands the winner **and** fires the Winner Flywheel; then check `workflow inbox` for any background run it kicked off.
+9. **Promote** — `bank promote <key>` lands the winner **and** emits the `winner-promoted` event, so any workflow with an **enabled** matching trigger starts a background run. To find out whether one actually started, run `workflow status` with **no** `--id` — the recent-run list. Don't send the user to `inbox` for this: `inbox` only holds runs waiting on a person, and a flywheel run with no approval step will never appear there (§5).
 
 ## 1. Discover & run
 
@@ -149,7 +169,7 @@ npx @aicopycoders/exodus workflow status --id <runId>
 
 There is no way to run only part of a graph: a run executes the whole workflow or it doesn't start.
 
-**Read the `Deliveries:` block first.** Each Output node on the canvas is a named, typed promise — "Final ad copy · text", "Hero image · asset" — and a finished run answers every one of them: `delivered` with the artifacts underneath, or `unfulfilled` with the reason the upstream node gave. That block is the honest scorecard; the `Outputs:` block below it is the same artifacts as one flat pile, kept for chaining. If a run says `completed` but a slot says `unfulfilled`, the workflow did NOT deliver what it promised — say so.
+**Read the `Deliveries:` block first.** Each Output node on the canvas is a named, typed promise — "Final ad copy · text", "Hero image · asset" — and a finished run answers every one of them: `delivered` with the artifacts underneath, or `unfulfilled` with the reason the upstream node gave. That block is the honest scorecard; the `Outputs:` block below it is the same artifacts as one flat pile, kept for chaining. If a run says `Succeeded` but a slot says `unfulfilled`, the workflow did NOT deliver what it promised — say so.
 
 **Save the deliverables to disk with `--out <dir>`** (works on `run --wait` and on `status --id`):
 
@@ -160,7 +180,7 @@ npx @aicopycoders/exodus workflow status --id <runId> --out ./deliverables
 
 Every delivered slot becomes a file named `<workflow>-<runId tail>-<slot key>.<ext>` — text as `.md`, storyboards and frame sets as `.json`, images/video/audio downloaded from their URLs — and each written path is printed. Unfulfilled slots are reported, never written. The directory is created if it doesn't exist.
 
-Report the outputs plus a short take. Don't call a run "done" off the kickoff line alone — a run reaches `completed`, `partial`, `failed`, or **parks** (`awaiting-review`). A `partial` means some nodes were skipped or failed; a park means it's waiting on you (see the next section). Read `status` before declaring victory.
+Report the outputs plus a short take. Don't call a run "done" off the kickoff line alone. **`status` prints one `status:` line, and it says one of seven words:** `Queued`, `Running`, `Awaiting approval`, `Succeeded`, `Succeeded with warnings`, `Failed`, `Cancelled`. Some of them carry a short "why" after a dash — `Awaiting approval — needs repair`, `Awaiting approval — needs inputs`, `Running — sub-workflow` (it's waiting on a child workflow, not on you), `Failed — nothing delivered` (steps failed AND not one promised slot arrived, so it is not a success no matter what the run row says). `Succeeded with warnings` means some steps were skipped or failed but the run still delivered. `Awaiting approval` means it **parked** and is waiting on you (see the next section). Read `status` before declaring victory.
 
 ## 2. Runs that park
 
@@ -170,12 +190,49 @@ A run doesn't always finish on its own — it can **park** and wait for a human
 - **repair** — a require-all collector stalled on a dead input and needs a decision.
 - **slots** — a nested sub-workflow is waiting on inputs (slot answers).
 
-**No webhooks in v1 — nothing parks silently, but nothing pings you either.** You find parks three ways: `run --wait` prints a pause notice naming the verb to use (a park is not terminal — the command keeps polling so it can resume after you resolve; resolve from another shell, or Ctrl-C and pick it up via `inbox`); `workflow inbox` lists every parked run badged by kind (`checkpoint`/`repair`/`slots`; the badge `gate` shows up only on a pre-2.0 run parked at the retired Gate node — those can't be resumed, cancel and run the workflow again) and how it started (`bg`, `trig:<event>`); or `workflow status` shows `awaiting-review`. **`inbox` is the one place nothing hides** — including background runs a trigger fired or a promote's flywheel kicked off.
+**No webhooks in v1 — nothing parks silently, but nothing pings you either.** You find parks three ways: `run --wait` prints a pause notice naming the verb to use (a park is not terminal — the command keeps polling so it can resume after you resolve; resolve from another shell, or Ctrl-C and pick it up via `inbox`); `workflow inbox` lists every parked run badged by kind (`checkpoint`/`repair`/`slots`; the badge `gate` shows up only on a pre-2.0 run parked at the retired Gate node — those can't be resumed, cancel and run the workflow again) and how it started (`bg`, `trig:<event>`); or `workflow status --id <runId>` prints `status: Awaiting approval`.
+
+### `inbox` vs the run list — two different questions
+
+**`inbox` answers one question: what is waiting on a person?** For that job it is the right list — how a run started makes no difference to it. A run fired by a trigger, by a promote's flywheel, or in the background shows up there when it parks for a decision, exactly like a run you launched by hand.
+
+Two limits worth knowing before you treat an empty inbox as proof of anything:
+
+- **A run waiting on a child workflow is deliberately left out.** That is the `call` park — the parent resumes by itself when the child finishes, so there is nothing for you to decide and it is filtered out on purpose. It is still parked; it just isn't your problem.
+- **The inbox shows the 50 newest parked runs**, and prints no notice when it hits that ceiling. On a brand with more parks than that, the oldest ones fall off the end.
+
+**What `inbox` does not list is work that isn't waiting on anybody.** A queued run, a running run, and any automation that ran start-to-finish without an approval step never appear there — not because they're hidden, but because there is nothing for you to decide. Plenty of workflows are built that way on purpose; the shipped **Winner Flywheel** starter is one (brief → splitter → output, no Checkpoint box anywhere), so its run *can never* show up in `inbox`. An empty inbox after a promote means "nothing needs you", not "nothing ran".
+
+**To see runs that aren't waiting on you, run `workflow status` with no `--id`.** That prints the brand's recent runs — newest first, one row each with the workflow name, its status, the **date** it started, and its **run id**. That bare list is how you discover a background run at all, including one that started and finished while you weren't looking; take the id from it and `status --id <runId>` for the full detail.
+
+Two things about that list you have to know before you answer a question with it:
+
+- **It stops at the 25 newest runs and says nothing about the ones it dropped.** On a brand that runs a lot, "did my promote start a run?" can read as *no* when the honest answer is "yes, but more than 25 runs ago". Treat a miss as "not in the last 25", not as "never happened".
+- **The `created` column is a date with no clock time** (`2026-08-15`). Every run started today looks identical, so it cannot tell you whether a run started before or after something else you did a few minutes ago. Use the ordering instead — the list is newest-first, so a run kicked off by your promote is at or near the top.
 
 ```bash
-npx @aicopycoders/exodus workflow inbox
+npx @aicopycoders/exodus workflow status          # recent runs: name, status, created, run id
+npx @aicopycoders/exodus workflow status --id <runId>   # one run in full
+npx @aicopycoders/exodus workflow inbox           # only the runs waiting on a person
 ```
 
+### Stopping a run early — `workflow cancel`
+
+**A run you want to stop does not have to be parked.** `workflow cancel <runId>` stops any run that hasn't finished — waiting in the queue, halfway through, or parked at a checkpoint, all the same verb:
+
+```bash
+npx @aicopycoders/exodus workflow cancel <runId> --reason "wrong brief"
+```
+
+This is the verb to reach for the moment a run is going the wrong way. A run costs money the entire time it is queued or running, so you do **not** have to wait for it to reach a Checkpoint before you can pull the plug.
+
+What cancelling guarantees: the run is marked cancelled and will not advance another step, and any sub-workflow it started is cancelled with it. What it does **not** guarantee: that the step already mid-flight dies instantly. A stop is sent to the worker, but that hop is best-effort — if it doesn't land, the step can finish what it was already doing before everything comes to rest. So cancel promptly, and don't promise the user that a half-finished image or video was stopped mid-render.
+
+- **`--reason "..."`** is optional and recorded on the run's history, so anyone reading it later sees why it stopped. Use it.
+- **A run that already finished is refused** — the CLI relays the server's own sentence ("This run has already finished — there is nothing to cancel."). That is a statement of fact, not an error to work around.
+- **Get the run id from `workflow status`** (no `--id`) if you don't have it in front of you.
+- **`workflow checkpoint <runId> cancel` still works** and does exactly the same thing — it's the older name for this, kept so existing habits and scripts don't break.
+
 ### The `gate` verbs retired in 2.0
 
 `exodus workflow gate …` no longer does anything: the Gate node it drove was
@@ -186,12 +243,12 @@ resumed, because the step it's waiting on no longer exists. Cancel it and run th
 workflow again:
 
 ```bash
-npx @aicopycoders/exodus workflow checkpoint <runId> cancel --reason "legacy gate park"
+npx @aicopycoders/exodus workflow cancel <runId> --reason "legacy gate park"
 ```
 
 ### Checkpoint parks — show / edit / approve / retry / cancel
 
-A **Checkpoint** is its own box on the canvas, sitting on a wire between two steps: the step before it finishes, the work reaches the Checkpoint, and the whole run stops there until a human signs off. Because it's a box you can see, the diagram tells you exactly where a run will stop. It waits **indefinitely**, so a `run --wait` left unattended simply keeps polling; nothing times out and nothing is lost. A Checkpoint is never approved automatically — not in a background run, not in a triggered one. The single exception is a run someone launched with `run --auto-approve`, which is an explicit "nobody is watching this one" choice made at launch time; those runs approve each Checkpoint as they reach it and mark the stop as auto-approved.
+A **Checkpoint** is its own box on the canvas, sitting on a wire between two steps: the step before it finishes, the work reaches the Checkpoint, and the whole run stops there until a human signs off. Because it's a box you can see, the diagram tells you exactly where a run will stop. **The park itself waits indefinitely** — nothing on the server expires it, and the sweep that kills stalled runs deliberately skips parked ones, so a run can sit at a Checkpoint for days and lose nothing. **The `--wait` command watching it does not wait that long:** after about an hour of polling it gives up, exits non-zero, and prints `Timed out waiting. Check later: exodus workflow status --id <runId>`. That is the *command* ending, not the run — the run is still parked exactly where it was, and `inbox` or `status --id` picks it back up. A Checkpoint is never approved automatically — not in a background run, not in a triggered one. The single exception is a run someone launched with `run --auto-approve`, which is an explicit "nobody is watching this one" choice made at launch time; those runs approve each Checkpoint as they reach it and mark the stop as auto-approved.
 
 The box itself does no work: whatever arrives goes straight back out, unchanged, the moment you approve.
 
@@ -201,13 +258,13 @@ There are **no candidates to pick** — there's held work to read and either ble
 npx @aicopycoders/exodus workflow checkpoint <runId>                  # show what's waiting at the checkpoint
 npx @aicopycoders/exodus workflow checkpoint <runId> edit 1 --text "tighter opener"   # rewrite an output in place
 npx @aicopycoders/exodus workflow checkpoint <runId> approve --wait   # sign off, the run continues
-npx @aicopycoders/exodus workflow checkpoint <runId> retry --wait     # redo the step feeding it, wait for fresh output
+npx @aicopycoders/exodus workflow checkpoint <runId> retry --note "make the hook punchier" --wait   # redo the step feeding it
 npx @aicopycoders/exodus workflow checkpoint <runId> cancel --reason "wrong direction"   # stop the run here
 ```
 
 - **`edit`** takes `--text`, `--file <path>`, or piped stdin. It does **not** resume the run — edit first, then `approve`.
-- **`retry`** discards what's waiting and re-runs the step **feeding** the checkpoint (re-running the checkpoint itself would hand back the identical text, since it only passes things through). The run parks right back at the *same* checkpoint with the fresh output — that re-park **is** the success. So `retry --wait` finishes as soon as the new output is ready, prints it, and hands you back the same four choices; it does **not** wait for the run to complete (it never would). Review the fresh output and `approve` when you're happy.
-- **`cancel`** stops the run for good, recording your reason — the same audit trail the web uses.
+- **`retry`** discards what's waiting and re-runs the step **feeding** the checkpoint (re-running the checkpoint itself would hand back the identical text, since it only passes things through). The run parks right back at the *same* checkpoint with the fresh output — that re-park **is** the success. So `retry --wait` finishes as soon as the new output is ready, prints it, and hands you back the same four choices; it does **not** wait for the run to complete (it never would). Review the fresh output and `approve` when you're happy. Add **`--note "..."`** to say what was wrong: a step that calls a model is given the note on the re-run, and every step records it on the run's review trail either way.
+- **`cancel`** stops the run for good, recording your reason — the same audit trail the web uses. It is the same action as the top-level `workflow cancel <runId>`, so you can use either; the top-level one is the one to remember, because it also works on a run that hasn't parked.
 
 **Authoring one** (when you're building or editing a graph from the CLI): add a `checkpoint` node and put it **on the wire** — producer → checkpoint `in`, checkpoint `out` → whoever used to receive it. `in` accepts any wire type so the box drops onto any wire; `out` is typed by `config.passType`, which must name the **same type as the wire feeding it** (`text` is the default and by far the common case). Get that wrong and `validate` returns `bad-config` naming the wire's real type.
 
@@ -235,7 +292,7 @@ npx @aicopycoders/exodus workflow checkpoint <runId> approve --reject 2,5 --wait
 - `--reject` takes the **item numbers you see** (1-based, comma-separated) — not row numbers, not the 0-based indexes in `--json`.
 - **Rejecting is filtering, not failing.** The dropped items disappear from the batch and the run carries on with the survivors; nothing is marked failed and no warning is raised. Say it that way to the user: "kept 5 of 7."
 - **Approve with no `--reject` keeps everything** — the ordinary approve, unchanged.
-- **Rejecting every item is refused.** If nothing is worth keeping, `cancel` the run — that's the honest action, and the CLI relays the server's message telling you so.
+- **Rejecting every item is refused.** If nothing is worth keeping, stop the run instead (`workflow cancel <runId> --reason "..."`) — that's the honest action, and the CLI relays the server's message telling you so.
 - `edit <n>` works inside a fan exactly as it does anywhere else; edit the rows you want to fix, then approve (with or without `--reject`).
 
 ### Repair parks — retry / skip / kill
@@ -296,7 +353,22 @@ npx @aicopycoders/exodus bank show hooks           # entries, newest-first, with
 npx @aicopycoders/exodus bank promote hooks "Stop scrolling — your knees will thank you"
 ```
 
-`bank promote` lands a winning line **and fires the Winner Flywheel** — it emits the `winner-promoted` event with **exact web parity and no opt-out**. Any workflow with an enabled matching trigger then starts a background run. So **after a promote, check `workflow inbox`** for the background run it may have kicked off. Promote reads text from an argument, `--file <path>`, or stdin (one of the three), and takes optional flags for awareness tagging (`--awareness`, body bank), win metrics (`--spend`, `--roas`, `--ctr`, `--note`), and provenance (`--run`, `--node`) — see `bank promote --help`.
+`bank promote` lands a winning line **and fires the Winner Flywheel** — it emits the `winner-promoted` event with **exact web parity and no opt-out**. Any workflow with an enabled matching trigger then starts a background run. Promote reads text from an argument, `--file <path>`, or stdin (one of the three), and takes optional flags for awareness tagging (`--awareness`, body bank), win metrics (`--spend`, `--roas`, `--ctr`, `--note`), and provenance (`--run`, `--node`) — see `bank promote --help`.
+
+**Two honest things to tell the user after a promote.**
+
+**First: a promote often fires nothing, and that is the default.** The event goes out every time, but it only starts a run if some workflow on this brand has a `winner-promoted` trigger that is **switched on**. The shipped **Winner Flywheel** starter arrives with its trigger **disabled** on purpose — so on a brand that imported it and never enabled it, a promote lands the line and stops there. Check before you promise a run: `workflow triggers "Winner Flywheel"` shows the switch, and `workflow triggers "Winner Flywheel" enable 1` flips it on.
+
+**Second: check the run list, not the inbox.** `inbox` holds runs that are waiting on a person. The Winner Flywheel is three steps — brief → splitter → output — with **no Checkpoint box anywhere**, so its run has nothing to ask you and never lands in the inbox; it just runs and finishes. Looking for it there and finding nothing tells you nothing. Look here instead:
+
+```bash
+npx @aicopycoders/exodus workflow triggers "Winner Flywheel"   # is the switch even on?
+npx @aicopycoders/exodus bank promote hooks "…"                # land the winner
+npx @aicopycoders/exodus workflow status                       # did a run start? (25 newest runs + ids)
+npx @aicopycoders/exodus workflow status --id <runId>          # what it produced
+```
+
+Run it **right after** the promote: that list holds only the 25 newest runs, with no clock time on the rows, so the fresh run is only easy to spot while it's still near the top.
 
 ## 6. Versions
 
@@ -555,12 +627,12 @@ The inbox/checkpoint/session/bank verbs have v2 routes too, but the CLI is the m
 ## Failure handling
 
 - **`describe` shows a ✗ prerequisite** — don't run yet. Fill the primer via `exodus-primer` / `exodus-foundation`, then re-check `describe`.
-- **Run comes back `partial` or `failed`** — read `status --id <runId>` (drop `--json` for a readable view) to see which node failed and why **before re-running**. A partial still has usable outputs; harvest them first.
-- **A verb refuses because the run isn't in that state** — the checkpoint/repair/answer verbs preflight the run and name its **actual** state (e.g. "parked for repair" when you tried a checkpoint verb). Read the state it reports and switch to the matching verb, or check `inbox` for what's actually pending.
+- **Run comes back `Succeeded with warnings` or `Failed`** — read `status --id <runId>` (drop `--json` for a readable view) to see which node failed and why **before re-running**. "Succeeded with warnings" still has usable outputs; harvest them first. `Failed — nothing delivered` means the run produced none of what it promised.
+- **A verb refuses because the run isn't in that state** — the checkpoint/repair/answer verbs check the run first and name its **actual** state (e.g. "parked for repair" when you tried a checkpoint verb). Read the state it reports and switch to the matching verb, or check `inbox` for what's actually pending. **`cancel` is the exception on purpose**: it doesn't care what state the run is in, only that it hasn't finished.
 - **Trigger fingerprint mismatch** — the workflow changed since you listed its triggers. Re-list (`workflow triggers <wf>`) and retry the enable/disable/fire against the fresh numbering.
 - **`validate` / `import` errors** — fix the exact node/port each issue names using its remedy; don't guess. `validate` needs network + login — there is no offline check.
 - **`import --update` 409** — re-export, reapply, re-import. This is a conflict, not a bug.
-- **After a promote** — the success line includes the flywheel note; check `workflow inbox` for the background run it may have started.
+- **After a promote, and no run appeared** — first check the trigger is actually enabled (`workflow triggers "<workflow>"`); the Winner Flywheel starter ships **disabled**. If it is on, look in the **recent-run list** (`workflow status`, no `--id`), not in `inbox` — a flywheel run has no approval step, so it finishes without ever appearing in the inbox.
 - **Auth / whoami failure** — run `npx @aicopycoders/exodus doctor` and confirm `EXODUS_API_KEY`.
 - **Wrong brand** — workflows, sessions, and banks are per-brand. `npx @aicopycoders/exodus brand current` to confirm you're on the brand you think you are; switch with the `exodus-brand` skill.
 

package/dist/commands/bank.js

@@ -51,7 +51,7 @@ const LIST_PATH = "/api/v2/banks";
 const SHOW_PATH = "/api/v2/banks/show";
 const PROMOTE_PATH = "/api/v2/banks/promote";
 const FLYWHEEL_LINE = 'Winner Flywheel: "winner-promoted" dispatched — any workflow with an enabled ' +
-    "trigger starts a background run (watch: exodus workflow inbox)";
+    "trigger starts a background run (see it: exodus workflow status)";
 const VALUE_FLAGS = new Set(["file", "awareness", "spend", "roas", "ctr", "note", "run", "node"]);
 const defaultDeps = {
     get: (path) => apiGet(path),

package/dist/commands/doctor.d.ts

@@ -13,6 +13,7 @@ export declare function checkEnvFile(): CheckResult;
 export declare function checkWhoami(): Promise<CheckResult>;
 export declare function checkActiveBrandMatch(): Promise<CheckResult>;
 export declare function checkExodusDistFreshness(pkgRootOverride?: string): CheckResult;
+export declare function checkScaffoldedSkills(rootOverride?: string, assetsSearchOverride?: string): CheckResult;
 export declare function checkVersionCurrency(pkgRootOverride?: string, fetchImpl?: typeof fetch): Promise<CheckResult>;
 export declare function checkApiAndDrive(): Promise<CheckResult[]>;
 export declare function checkDashboardAuth(): Promise<CheckResult>;

package/dist/commands/doctor.js

@@ -3,7 +3,9 @@ import path from "node:path";
 import { fileURLToPath } from "node:url";
 import { execSync } from "node:child_process";
 import { apiGet, apiGetDashboard, getApiUrl } from "../lib/client.js";
-import { findWorkspaceRoot } from "../lib/state.js";
+import { findWorkspaceRoot, getScaffoldVersion } from "../lib/state.js";
+import { skillsDir } from "../lib/assets.js";
+import { getVersion } from "../lib/version.js";
 import { detectLayout, listBrandDirs, resolveActiveBrand, brandStateDir, } from "../lib/layout.js";
 import { auth401Hint, isPlaceholderApiUrl } from "../lib/backend-hint.js";
 import { compareVersions, readPackageVersion, } from "../lib/release.js";
@@ -252,6 +254,65 @@ export function checkExodusDistFreshness(pkgRootOverride) {
     }
     return { ok: true, label: "Exodus CLI build", detail: "dist up-to-date" };
 }
+function dirNamesIn(dir) {
+    return fs
+        .readdirSync(dir, { withFileTypes: true })
+        .filter((e) => e.isDirectory())
+        .map((e) => e.name)
+        .sort();
+}
+export function checkScaffoldedSkills(rootOverride, assetsSearchOverride) {
+    const label = "Workspace skills";
+    const refresh = `run \`npx ${pkgRef()} update\` to refresh your skills`;
+    const root = rootOverride ?? findWorkspaceRoot();
+    const running = getVersion();
+    const problems = [];
+    const stamped = getScaffoldVersion(root);
+    if (stamped && stamped !== running) {
+        problems.push(`scaffolded by ${stamped}, CLI is ${running}`);
+    }
+    let bundled = null;
+    try {
+        bundled = dirNamesIn(skillsDir(assetsSearchOverride));
+    }
+    catch {
+        bundled = null;
+    }
+    let installed = null;
+    if (bundled) {
+        try {
+            installed = dirNamesIn(path.join(root, ".claude", "skills"));
+        }
+        catch {
+            installed = null;
+        }
+        if (installed === null) {
+            problems.push("no .claude/skills/ in this workspace");
+        }
+        else {
+            const missing = bundled.filter((n) => !installed.includes(n));
+            if (missing.length > 0) {
+                problems.push(`missing skill(s): ${missing.join(", ")}`);
+            }
+        }
+    }
+    if (problems.length > 0) {
+        return { ok: true, warn: true, label, detail: problems.join("; "), fix: refresh };
+    }
+    if (!bundled) {
+        return {
+            ok: true,
+            warn: true,
+            label,
+            detail: "couldn't read the bundled skills to compare",
+        };
+    }
+    return {
+        ok: true,
+        label,
+        detail: `${installed?.length ?? 0} skill(s) installed${stamped ? `, scaffolded by ${stamped}` : ""} — every bundled skill is present`,
+    };
+}
 function npmRegistryUrl(channel) {
     return `https://registry.npmjs.org/@aicopycoders/exodus/${channel}`;
 }
@@ -550,6 +611,7 @@ export async function run(_flags) {
     results.push(checkEnvFile());
     results.push(checkLayout());
     results.push(checkExodusDistFreshness());
+    results.push(checkScaffoldedSkills());
     results.push(checkBrandProfileGenesisDepth());
     const apiAndDrive = await checkApiAndDrive();
     results.push(...apiAndDrive);

package/dist/commands/init.js

@@ -4,6 +4,8 @@ import { writeEnvScaffold, ensureGitignore, writeSkills, writeReferences, writeD
 import { loadWorkspaceEnv } from "../lib/load-env.js";
 import { ensureBrandDir } from "../lib/layout.js";
 import { pkgRef } from "../lib/channel.js";
+import { setScaffoldVersion } from "../lib/state.js";
+import { getVersion } from "../lib/version.js";
 export const helpText = `
 exodus init — Set up (or refresh) an Exodus workspace in the current folder
 
@@ -24,6 +26,7 @@ export function scaffoldInit(root) {
     const skills = writeSkills(root);
     writeReferences(root);
     const docs = writeDocs(root);
+    setScaffoldVersion(getVersion(), root);
     return { existing, envCreated, skills, docs };
 }
 export async function syncBrands(root) {

package/dist/commands/meme.js

@@ -9,8 +9,8 @@ Usage:
   exodus meme recommend --brief "<text>" [--avatar "<text>"]
   exodus meme run --brief "<text>" --formats '<json>' [--avatar "<text>"] [--name "<label>"]
   exodus meme run --brief "<text>" --formats-file <path> [--avatar "<text>"] [--name "<label>"]
-  exodus meme regenerate --brief "<text>" --layer 1 --template-id <id> --template-name "<name>" --boxes <N> [--id <runId>] [--avatar "<text>"]
-  exodus meme regenerate --brief "<text>" --layer 2|3 --format <formatId> [--hint "<text>"] [--id <runId>] [--avatar "<text>"]
+  exodus meme regenerate --brief "<text>" --layer 1 --template-id <id> --template-name "<name>" --boxes <N> [--id <run id>] [--avatar "<text>"]
+  exodus meme regenerate --brief "<text>" --layer 2|3 --format <formatId> [--hint "<text>"] [--id <run id>] [--avatar "<text>"]
 
 Flow:
   1. recommend  → { recommendations: [...] } — 15 picks (5 per layer), each with
@@ -25,8 +25,12 @@ Flow:
                   workflow run — the workflow verb is the one that can read it.
   4. regenerate → re-render a single miss using the format fields from the
                   recommend output. Synchronous; returns the new image URL.
-                  Its optional --id takes a CREATIVE-SUITE run id, which the id
-                  from step 2 is not — omit --id and use the returned URL.
+                  Pass --id <the runId from step 2> to file the fresh meme with
+                  the rest of that run, so it shows up in the library next to
+                  its siblings. Leave --id off and you just get the URL — handy,
+                  but that image is not saved anywhere. If the id doesn't match
+                  a run (or that run never made this format) you get a plain
+                  error saying so, not a silent miss.
 
 Keys (strict BYOK — checked server-side before anything starts):
   classic (layer 1) memes need your Imgflip login; AI (layer 2/3) memes need
@@ -36,6 +40,8 @@ Examples:
   exodus meme recommend --brief "grounding sheets reduce inflammation"
   exodus meme run --brief "grounding sheets reduce inflammation" --formats '[{"layer":2,"name":"Group Chat","format_id":"group-chat"}]'
   exodus meme regenerate --brief "grounding sheets reduce inflammation" --layer 2 --format group-chat --hint "make the last message land the product"
+  # Same re-roll, filed with the run it belongs to (the runId step 2 printed):
+  exodus meme regenerate --brief "grounding sheets reduce inflammation" --layer 2 --format group-chat --id <runId from step 2>
 `.trim();
 function dashboardUrlForRun(runId) {
     return `${getDashboardUrl()}/runs/${runId}`;
@@ -235,8 +241,9 @@ async function runRegenerate(flags) {
     }
     const res = await apiPostDashboard("/api/meme/regenerate", body);
     if (!res.ok) {
-        console.error(formatError(res));
-        if (res.status === 400) {
+        const detail = formatError(res);
+        console.error(detail);
+        if (res.status === 400 && /\bkey/i.test(detail)) {
             console.error(`Hint: run \`npx ${pkgRef()} doctor\` to check your keys.`);
         }
         process.exit(1);

package/dist/commands/update.js

@@ -1,4 +1,7 @@
+import fs from "node:fs";
+import path from "node:path";
 import { getVersion } from "../lib/version.js";
+import { findParentRoot } from "../lib/layout.js";
 import { run as runInit } from "./init.js";
 export const helpText = `
 exodus update — refresh this workspace from the installed CLI (alias of init)
@@ -14,7 +17,44 @@ Note: the CLI itself updates because npx resolves your channel fresh on each
 run — so invoke this as \`npx @aicopycoders/exodus update\` (or @beta on the
 beta channel), not from a stale local install.
 `.trim();
+function refuseRollback(root) {
+    console.error("`--rollback` isn't something this version can do.");
+    console.error("");
+    console.error("Rolling back was a feature of the old downloadable Exodus. This");
+    console.error("version installs fresh from npm every time you run it, so there is");
+    console.error("no saved copy here for it to put back — and refreshing now would");
+    console.error("overwrite your files again, which is the opposite of what you asked.");
+    console.error("");
+    const backupDir = path.join(root, ".backup");
+    let stamps = [];
+    try {
+        stamps = fs
+            .readdirSync(backupDir, { withFileTypes: true })
+            .filter((e) => e.isDirectory())
+            .map((e) => e.name)
+            .sort()
+            .reverse();
+    }
+    catch {
+    }
+    if (stamps.length > 0) {
+        console.error("Your old CLI did leave saved copies here:");
+        console.error(`  ${backupDir}`);
+        console.error(`  newest first: ${stamps.slice(0, 3).join(", ")}`);
+        console.error("");
+        console.error("To put one back, copy it over by hand, for example:");
+        console.error(`  cp -R "${path.join(backupDir, stamps[0], ".claude", "skills")}" "${path.join(root, ".claude")}/"`);
+    }
+    else {
+        console.error(`No saved copies found at ${backupDir}.`);
+    }
+    process.exit(1);
+}
 export async function run(flags) {
+    const root = typeof flags.root === "string" ? flags.root : findParentRoot();
+    if (flags.rollback)
+        refuseRollback(root);
+    const rooted = typeof flags.root === "string" ? flags : { ...flags, root };
     console.log(`Exodus ${getVersion()} — refreshing workspace scaffold…`);
-    await runInit(flags);
+    await runInit(rooted);
 }

package/dist/commands/workflow.d.ts

@@ -69,7 +69,7 @@ export interface WorkflowImportResult {
     unresolved: UnresolvedWorkflowRef[];
     warnings: string[];
 }
-export type GraphIssueCode = "bad-shape" | "unknown-kind" | "duplicate-node-id" | "dangling-edge" | "unknown-port" | "type-mismatch" | "duplicate-input" | "duplicate-input-key" | "cycle" | "missing-required-input" | "bad-config" | "bad-slot" | "bad-trigger" | "nested-split" | "fan-overlap" | "lane-ineligible" | "fan-image-budget" | "collector-unpaired" | "splitter-field-conflict";
+export type GraphIssueCode = "bad-shape" | "unknown-kind" | "duplicate-node-id" | "dangling-edge" | "unknown-port" | "type-mismatch" | "duplicate-input" | "duplicate-input-key" | "cycle" | "missing-required-input" | "bad-config" | "bad-slot" | "bad-trigger" | "nested-split" | "fan-overlap" | "lane-ineligible" | "fan-image-budget" | "collector-unpaired" | "splitter-field-conflict" | "competitor-source";
 export interface GraphIssue {
     code: GraphIssueCode;
     message: string;
@@ -211,6 +211,7 @@ export interface WorkflowDescribeResponse {
     }>;
     outputs: WorkflowOutputDescriptor[];
     deliveries?: WorkflowDeliveryDescriptor[];
+    warnings?: string[];
 }
 export interface WorkflowTemplateListItem {
     key: string;
@@ -568,6 +569,11 @@ export declare function checkpointRetryFlow(runId: string, opts: {
     note?: string;
     onProgressLine?: (line: string) => void;
 }, deps: WorkflowRunDeps): Promise<FlowResult>;
+export declare function cancelRunFlow(runId: string, opts: {
+    reason?: string;
+    json: boolean;
+    verb?: string;
+}, deps: WorkflowRunDeps): Promise<FlowResult>;
 export declare function checkpointCancelFlow(runId: string, opts: {
     reason?: string;
     json: boolean;

package/dist/commands/workflow.js

@@ -4,7 +4,7 @@ import nodePath from "node:path";
 import { apiGet, apiGetText, apiPost, apiPostDashboard, getDashboardUrl, } from "../lib/client.js";
 import { formatApiError } from "../lib/format.js";
 import { pollUntilDone } from "../lib/poll.js";
-import { normalizeRunStatus, storedWorkflowStatusForms, TERMINAL_RUN_STATUSES, } from "../lib/runStatus.js";
+import { normalizeRunStatus, isTerminalRunStatus, storedWorkflowStatusForms, TERMINAL_RUN_STATUSES, } from "../lib/runStatus.js";
 import { runVerdict } from "../lib/runVerdict.js";
 import { workflowToYaml, parseWorkflowText } from "../lib/workflowText.js";
 import { missingRouteLine } from "../lib/route-support.js";
@@ -20,7 +20,9 @@ Usage:
   exodus workflow templates export <key> [--out <file>] [--json]
   exodus workflow schema [--kind <kind>] [--face <face>] [--json]
   exodus workflow run <workflowId|name> [--fill <name>] [--input key=value ...] [--input <fileField>=<path> ...] [--rig-overrides <json|@file>] [--auto-approve] [--wait] [--out <dir>] [--json]
-  exodus workflow status [--id <runId>] [--out <dir>] [--json]
+  exodus workflow status [--json]
+  exodus workflow status --id <runId> [--out <dir>] [--json]
+  exodus workflow cancel <runId> [--reason "..."] [--json]
   exodus workflow versions <workflowId|name> [--json]
   exodus workflow export <workflowId|name> [--version <n>] [--out <file>] [--json]
   exodus workflow validate <file> [--update <workflowId>] [--json]
@@ -92,7 +94,12 @@ Flags:
                          Checkpoint box and waits until its fresh output is
                          ready and the run parks again — that IS its finish
                          line; a redo never runs the workflow to completion.
-  --id <runId>           Workflow run id for status detail
+  --id <runId>           (status) One run's full detail. LEAVE IT OFF and status
+                         prints the brand's recent runs instead — workflow name,
+                         status, when it started, and the run id — which is how
+                         you find the id of a run that started in the background
+                         (a trigger fired it, or a promoted winner did) and
+                         never stopped to ask you anything.
   --out <file>           Write the export to a file instead of stdout
   --out <dir>            (run --wait / status --id) Save every delivered output
                          of the finished run into this directory (created if
@@ -120,8 +127,8 @@ Flags:
                          Required for event triggers; rejected for cron triggers.
                          (checkpoint edit) The replacement copy for one output.
   --file <path>          (checkpoint edit) Load the replacement copy from a file.
-  --reason "..."         (checkpoint cancel) Optional reason recorded on the
-                         cancel.
+  --reason "..."         (cancel, checkpoint cancel) Optional reason recorded on
+                         the cancel, so the run's history says why it stopped.
   --note "..."           (checkpoint retry) Optional correction for the redo
                          ("make the hook punchier"). Steps that call a model
                          follow it on the re-run; deterministic steps only
@@ -160,8 +167,10 @@ Examples:
   exodus workflow run "Product Shots" --rig-overrides '{"rig_1":{"lines":{"line_1":{"count":3}}}}'
   exodus workflow run "Product Shots" --rig-overrides @rig.json --wait
   exodus workflow run "Launch Flow" --wait --out ./deliverables
+  exodus workflow status                      # recent runs + their ids
   exodus workflow status --id wr_123
   exodus workflow status --id wr_123 --out ./deliverables
+  exodus workflow cancel wr_123 --reason "wrong brief"
   exodus workflow versions "Launch Flow"
   exodus workflow export "Launch Flow" --out workflow.yaml
   exodus workflow export "Launch Flow" --version 3 --out v3.yaml
@@ -234,6 +243,19 @@ Notes:
   workflow bots --json emits the FULL catalog response verbatim (--category /
   --slug filters are ignored in that mode). workflow bots --slug <slug> --json
   emits just that one bot's catalog JSON.
+  workflow status with no --id lists the brand's recent runs — name, status,
+  when it started, and the run id — and that list is the ONLY place a run that
+  never stopped to ask you anything shows up. "workflow inbox" is a different
+  list: it holds runs waiting on a person, so a background run whose workflow
+  has no approval step finishes without ever appearing there. Take an id from
+  the run list, then read it with "workflow status --id <runId>". (#933/#934)
+  workflow cancel <runId> stops a run that has not finished — queued, running,
+  or parked, all of it. The run stops for good and any child workflow it started
+  is cancelled with it; a stop is also sent to the step still running, though
+  that last part is best-effort. --reason records why on the run's history.
+  A run that already finished is refused (nothing to cancel). The older
+  "workflow checkpoint <runId> cancel" is the same action under its old name and
+  keeps working. (#1231)
   workflow inbox lists every run parked waiting on you, badged by park kind
   (checkpoint/repair/slots/gate/legacy) and how it started (bg / trig:<event>).
   A run parked at a Checkpoint box is resolved with the "checkpoint" verbs: show
@@ -446,7 +468,7 @@ export function formatPauseNotice(pauseReason, runId, dashboardUrl) {
     if (pauseReason === "taste") {
         return [
             "  ⏸ paused at a Gate box, which retired in 2.0. Approvals now happen at a Checkpoint box.",
-            `     Cancel it here: exodus workflow checkpoint ${runId} cancel`,
+            `     Cancel it here: exodus workflow cancel ${runId}`,
             `     Or in the app:  ${dashboardUrl}${RUN_PAGE_PREFIX}${runId}`,
             "     Then run the workflow again.",
         ];
@@ -923,10 +945,19 @@ export function formatWorkflowList(workflows) {
         w._id,
     ]));
 }
+const RECENT_RUNS_PAGE = 25;
 export function formatRecentRuns(runs) {
     if (runs.length === 0)
         return "No workflow runs found for the active brand.";
-    return table(["workflow", "status", "created", "id"], runs.map((r) => [r.workflowName, runVerdict(r), dateOnly(r.createdAt), r._id]));
+    const rows = table(["workflow", "status", "created", "id"], runs.map((r) => [r.workflowName, runVerdict(r), dateOnly(r.createdAt), r._id]));
+    const notes = [];
+    if (runs.length >= RECENT_RUNS_PAGE) {
+        notes.push(`Showing the ${RECENT_RUNS_PAGE} newest runs — there may be older ones this list doesn't reach.`);
+    }
+    if (runs.some((r) => !isTerminalRunStatus(r.status))) {
+        notes.push(`Stop one that's still going: exodus workflow cancel <id> --reason "..."`);
+    }
+    return notes.length > 0 ? `${rows}\n\n${notes.join("\n")}` : rows;
 }
 export function formatWorkflowVersions(versions) {
     if (versions.length === 0) {
@@ -1004,7 +1035,7 @@ export function formatWorkflowRun(run) {
     lines.push(`workflowId:   ${run.workflowId}`);
     if (run.triggerRunId)
         lines.push(`triggerRunId: ${run.triggerRunId}`);
-    lines.push(`verdict:      ${runVerdict(run)}${counts ? ` (${counts})` : ""}`);
+    lines.push(`status:       ${runVerdict(run)}${counts ? ` (${counts})` : ""}`);
     if (run.isTerminal)
         lines.push("terminal:     yes");
     if (run.error)
@@ -1266,6 +1297,12 @@ export function formatDescribe(res) {
     if (res.description)
         lines.push(`description:  ${res.description}`);
     lines.push(`updated:     ${dateOnly(res.updatedAt)}`);
+    if (res.warnings && res.warnings.length > 0) {
+        lines.push("");
+        lines.push(`✗ ${res.warnings.length === 1 ? "Warning" : "Warnings"}:`);
+        for (const warning of res.warnings)
+            lines.push(`  ✗ ${warning}`);
+    }
     lines.push("");
     lines.push(`Inputs (${res.inputs.length}):`);
     if (res.inputs.length === 0) {
@@ -2518,7 +2555,7 @@ export async function checkpointShowFlow(runId, opts, deps) {
             ...rejectLine,
             `Edit:    exodus workflow checkpoint ${runId} edit 1 --text "..."`,
             `Redo:    exodus workflow checkpoint ${runId} retry --wait`,
-            `Cancel:  exodus workflow checkpoint ${runId} cancel --reason "..."`,
+            `Cancel:  exodus workflow cancel ${runId} --reason "..."`,
         ],
     };
 }
@@ -2633,17 +2670,17 @@ export async function checkpointRetryFlow(runId, opts, deps) {
         headline: "  ⏸ The step re-ran — its fresh output is waiting on your approval.",
     });
 }
-export async function checkpointCancelFlow(runId, opts, deps) {
-    const pf = await preflightPark(runId, ["checkpoint", "taste"], "workflow checkpoint cancel", opts.json, deps);
-    if (!pf.ok)
-        return pf.result;
+export async function cancelRunFlow(runId, opts, deps) {
     const res = await deps.post(CANCEL_PATH, {
         runId,
         ...(opts.reason !== undefined ? { reason: opts.reason } : {}),
     });
     if (!res.ok)
-        return triggerErrorResult(res, "workflow checkpoint cancel", opts.json);
-    return okLine(`Checkpoint canceled — run ${runId} stopped.`, { ok: true, runId }, opts.json);
+        return triggerErrorResult(res, opts.verb ?? "workflow cancel", opts.json);
+    return okLine(`Canceled — run ${runId} is marked cancelled and won't go any further. Any sub-workflow it started is cancelled too, and a stop was sent to the step still running.`, { ok: true, runId }, opts.json);
+}
+export async function checkpointCancelFlow(runId, opts, deps) {
+    return cancelRunFlow(runId, { ...opts, verb: "workflow checkpoint cancel" }, deps);
 }
 export async function repairFlow(runId, action, opts, deps) {
     const verb = `workflow repair ${action}`;
@@ -2964,6 +3001,15 @@ export async function run(flags) {
         console.error(`Error: unknown checkpoint action "${action}" (expected show, edit, approve, retry, or cancel).`);
         process.exit(1);
     }
+    if (sub === "cancel") {
+        const runId = rest[0];
+        if (!runId) {
+            console.error("Error: workflow cancel requires <runId>.");
+            console.log('Usage: exodus workflow cancel <runId> [--reason "..."] [--json]');
+            process.exit(1);
+        }
+        return printResult(await cancelRunFlow(runId, { reason: flagString(flags, "reason"), json }, defaultDeps));
+    }
     if (sub === "repair") {
         const runId = rest[0];
         if (!runId) {

package/dist/lib/state.d.ts

@@ -4,3 +4,5 @@ export declare function setActiveBrand(slug: string): void;
 export declare function clearActiveBrand(): void;
 export declare function getLayoutVersion(): number | null;
 export declare function setLayoutVersion(version: number): void;
+export declare function getScaffoldVersion(root?: string): string | null;
+export declare function setScaffoldVersion(version: string, root?: string): void;

package/dist/lib/state.js

@@ -4,14 +4,14 @@ import { findParentRoot } from "./layout.js";
 export function findWorkspaceRoot() {
     return findParentRoot();
 }
-function findStateDir() {
-    return path.join(findWorkspaceRoot(), ".exodus");
+function findStateDir(root) {
+    return path.join(root ?? findWorkspaceRoot(), ".exodus");
 }
-function statePath() {
-    return path.join(findStateDir(), "state.json");
+function statePath(root) {
+    return path.join(findStateDir(root), "state.json");
 }
-function readState() {
-    const p = statePath();
+function readState(root) {
+    const p = statePath(root);
     if (!fs.existsSync(p))
         return {};
     try {
@@ -21,10 +21,10 @@ function readState() {
         return {};
     }
 }
-function writeState(next) {
-    const dir = findStateDir();
+function writeState(next, root) {
+    const dir = findStateDir(root);
     fs.mkdirSync(dir, { recursive: true });
-    fs.writeFileSync(statePath(), JSON.stringify(next, null, 2) + "\n", "utf-8");
+    fs.writeFileSync(statePath(root), JSON.stringify(next, null, 2) + "\n", "utf-8");
 }
 export function getActiveBrand() {
     return readState().activeBrand ?? null;
@@ -47,3 +47,11 @@ export function setLayoutVersion(version) {
     s.layoutVersion = version;
     writeState(s);
 }
+export function getScaffoldVersion(root) {
+    return readState(root).scaffoldVersion ?? null;
+}
+export function setScaffoldVersion(version, root) {
+    const s = readState(root);
+    s.scaffoldVersion = version;
+    writeState(s, root);
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aicopycoders/exodus",
-  "version": "2026.8.1400",
+  "version": "2026.8.1600",
   "description": "CLI + Claude Code skills for the Copycoders Exodus ad pipeline",
   "repository": {
     "type": "git",