Escalation
cmd/crewship/cmd_escalation.go covers the three escalation verbs: per-crew listing, single-row resolution, and the workspace-wide pending-count aggregator used by dashboards and alerting.
crewship escalation list
Lists escalations under one crew via GET /api/v1/crews/{crewId}/escalations. --crew is required — the server enforces crew-level auth, and listing across all crews would require N fan-out calls anyway.
Table columns:
ID, TYPE, FROM, REASON (50-char truncated), STATUS, CREATED.
crewship escalation resolve <id>
PATCH /api/v1/escalations/{id}/resolve. Optional notes land in the audit row.
Escalation <id> resolved. on success.
Resolving a CREDENTIAL escalation is refused with 403 when the caller is
recorded as the owner of the agent that raised it — including a workspace OWNER,
which is not exempt. Two independent things put that
segregation of duties
rule in force, and either is sufficient:
- the workspace toggle (
crewship keeper second-approver enable), which covers every credential; or - the credential’s own L4 · critical tier, which forces the rule whether or not the workspace opted in — a tier can only tighten it, never loosen it.
crewship keeper status prints which of the two applies on its In force:
line, so you can check before you are refused rather than after. See
Keeper → The switch is a floor, not a master switch.
crewship escalation pending-count
Workspace-wide aggregate — backs dashboard tiles and alerting that just needs the total without per-crew fan-out. GET /api/v1/escalations/pending-count returns {"count": N}.
See also
crewship approvals— the related human-in-the-loop surface (Keeper denials, MCP gates).crewship notify— desktop notifications when escalations land.crewship journal— live event tail (escalations are journaled).