| name | resume |
| description | Use when someone asks to continue / pick up / check on earlier work ("can we keep going on X?", "what happened to that thing?"), or after a restart. Check what's actually in flight BEFORE deploying anything new. |
resume
Work lives in the run ledger and in each run's own project repo (~/Projects/<slug>), so it
survives restarts. When someone refers to prior work — "can we continue the X thing?", "did that
ever finish?", "pick up where we left off" — don't immediately deploy something fresh. First look
at what's already there.
The reflex
beckett task list — everything in flight and everything recent. Match what they're asking
about by title, repo, or recency.beckett task ask <run-id|slug> — the run's state, its checklist progress, its journal
tail, and (if it's live) the address to ask the worker directly.
Then reason about what you found:
- Live (implementing / reviewing) — it's actively staffed, and a restart resumes interrupted
sessions automatically. Ask the worker where it's at and relay that; steer it with
beckett task steer <ref> "…" if the person has new direction.
awaiting_input — also live, not stopped: a worker asked one question and is holding for
it. Answer with beckett task resume <ref> --answer "<text>" rather than treating it as dead
work or redeploying around it.- Parked — held with a typed
run.blocker. beckett task ask <ref> gives you its rendered
text as error; beckett task show <ref> gives you the typed object (class/actor) when
that matters. Most parks aren't gone for good: beckett task resume <ref> [--note "<steer>"]
clears the blocker and re-staffs the stage it parked from, and beckett task steer <ref> "…" on
a parked run does the same (steering outranks waiting). The work itself is safe — committed on
the run's branch in the same repo. Only reach for a fresh deploy when the direction genuinely
changed, not just to get a worker back on it. A run parked mid-publish is the exception — an
admin-permission blocker, or any run whose publish already left the machine — resume and steer
both refuse it by name; the fix is clearing whatever's blocking its PR, then
beckett task courier <ref> [--pr-url <url>], never a redeploy or a hand push.
unverified — also live, not failed: the publish landed but its proof (CI green, PR
resolved, or a courier's recorded PR URL) hasn't confirmed yet. The supervisor re-checks it on
its own and promotes it to done; don't re-staff it, don't courier it, don't relay it as
shipped.- Done — point them at the artifact link. If they want changes, that's NEW work: deploy
against the same
--repo slug so it builds in the same repo. Note that courier without a PR URL
lands a run unverified, not done — a "done" run really did get its proof confirmed.
- Nothing relevant — genuinely new work; deploy it normally ([[intake]]).
If beckett itself is on hold
beckett status shows a paused: line when someone has taken the chat-only hold. If it's there,
say so honestly in one line — you're paused, the reason if one was given — and don't deploy
anything until it lifts. Only the person it's appropriate to trust runs beckett resume; don't
lift someone else's hold on a whim.
Why this matters
The honest answer to "can we continue X?" is almost never "sure!" followed by starting over. It's
"let me check" → find the actual run and repo → continue that. Work in the same repo shares one
checkout, so committed progress is never lost — reuse it instead of duplicating it. When in doubt,
look before you deploy.
