Skip to main content

crewship policy

Manage per-crew autonomy and behavior-mode policy. Each crew carries an autonomy_level (strict | guided | trusted | full) and a behavior_mode (warn | block) that together drive every HITL decision the orchestrator makes — memory writes, skill creation, behavior-monitor escalations, ephemeral spawns. The dial lives in crews.autonomy_level / crews.behavior_mode (v98 migration) and is consumed by every PR-B / PR-C subsystem via the shared policy.Resolver.

Subcommands


Levels and modes

Autonomy levels (closed set): Behavior modes (closed set):
The combination autonomy_level=full with behavior_mode=block is rejected by the API (opt-in trust paired with opt-in restriction is incoherent).

crewship policy get

Fetch the current policy + audit triple for one crew.
Sample output:
--format json and --format yaml pass the wire object through verbatim so jq/yq pipelines see the canonical field names (crew_id, autonomy_level, behavior_mode, set_by_user_id, set_at, reason).

crewship policy set

Update a crew’s policy. Atomic single PUT; on success the shared resolver cache is invalidated server-side so downstream subsystems (memory write gating, skill creation HITL, behavior monitor, ephemeral spawn) see the new state immediately rather than waiting for the 10s TTL.
Loosening autonomy (any → trusted or full) prompts for confirmation unless --yes; --level full additionally requires --reason. Raising a crew to full means journal-only logging — agents act without approval.
Validation order:
  1. --crew, --level presence checks (no round-trip on missing flags).
  2. Enum check for --level and --behavior — invalid values reject locally with a friendly error rather than letting the API return 400.
  3. --reason requirement for --level=full — matches the same rule the API enforces, but failing fast here keeps the network out of the loop on operator typos.
  4. Loose-transition confirmation (any → trusted or full) unless --yes.
Sample output:

crewship policy list

Show every crew’s policy in the current workspace, sorted by crew name (case-insensitive). Useful for fleet-wide audits and for spotting crews still on the default guided/warn pair.
Sample output:
The CREW column is enriched from /api/v1/crews because the policy API only returns crew_id; sorting on a CUID would be stable but useless to a human reader. If the crew-name fetch fails, the column falls back to and the list still renders — the policies themselves are usable without the friendly name.

Errors

  • PR-B F2 PRD section (PRD-AGENT-EVOLUTION-2026.md, internal spec) — autonomy slider design rationale.
  • crewship system aux-status — diagnostic surface for the parallel PR-B F3 auxiliary-model assignment.
  • crewship approvals — inspect the inbox items the autonomy dial routes through.