crewship work
Agent webhook work is recorded before its runtime starts. Chat, routine webhooks and other producers are not yet covered by this ledger.crewship work reads that ledger, so “we never received it”, “we received it and
filtered it out”, and “it ran and failed” are three different answers instead
of one shrug.
The full API contract is in the Work Items reference.
Nothing these commands print contains the accepted input, a webhook payload,
or model output. A work item’s input is, for a chat source, the conversation
itself — you get its
input_sha256 instead.
crewship work list
List work items in the current workspace, at most 100 per page.
Output columns: ID, STATE, CLASS, SOURCE, AGENT, ATTEMPTS, CREATED
A misspelt
--state is refused rather than answered with an empty page —
“nothing is running” is the wrong answer to a typo. When more rows remain the
command prints the exact --after invocation that continues.
needs_reconciliation deserves a look whenever it appears: it means a runtime
may still be alive under a locator nobody has verified, and it keeps holding
its capacity until somebody resolves it.
crewship work get <work-id>
Show one work item, every attempt, and its whole history.
crewship work cancel <work-id>
Ask for a work item to stop. Safe to repeat.
Cancelling does not undo external effects that already happened.
crewship work replay <work-id>
Create a new work item from a finished one.
This is not a retry. A retry keeps the work id and mints a new run id, and the
queue does that on its own for a repeatable failure. A replay is a new
authorization: the new item runs under your identity, carries
replay_of
and your reason, and re-uses the original input. Terminal history is never
rewritten.
Two refusals, each with an explanation rather than an opaque failure:
- Replaying work that has not finished. Cancel it first.
- Replaying webhook-sourced work whose raw payload has passed its retention. The delivery record survives the payload, so “we received it, we can no longer replay it” stays distinguishable from “we never saw it” — but only the sender can produce the bytes again.
crewship work deliveries list
List recorded inbound webhooks, at most 100 per page.
Output columns: ID, ENDPOINT, PROFILE, EVENT, DECISION, WORK, PAYLOAD, RECEIVED
Deliveries the filter rejected are listed too, with their reason and no work
id: a ping or a filtered event is auditable rather than invisible.
--endpoint together with --source-id asks the identity question — “did you
receive this one” — and answers with zero or one row. A sender’s delivery id
is only unique within an endpoint, so --source-id on its own is refused.
The PAYLOAD column is held or dropped, which is what decides whether
crewship work replay can work on the item this delivery produced.
crewship work deliveries get <delivery-id>
Show one delivery: which endpoint and signature profile accepted it, what the
filter decided and why, the work it produced, and whether its payload is still
held.
body_sha256 and the byte count identify
it without publishing whatever the sender put inside.
crewship work resolve <work-id>
An operator can settle needs_reconciliation after inspecting the runtime and
its external effects. Stop any surviving runtime first. Read the current
generation with work get, then record the observed outcome:
succeeded, failed, and cancelled. The command requires
manager permissions, a reason, the current generation, and explicit confirmation
that the runtime is stopped. It records the operator and reason, releases the
held ledger capacity, and rejects stale decisions. The confirmation is an
operator attestation; this command does not stop or automatically inspect a
container. Any subsequent rerun requires a separate, deliberate work replay.
Routine webhook runs remain under the pipeline API and have no work-item controls.