Operations and administration commands
Operational commands inspect or change workspace, host, network, license, installed-version, and release state. Resolve exact syntax and effects through the machine inventory or day-shift commands describe "<command path>" --format json before acting. JSON automation defaults to protocol v2; approved bounded inspection surfaces use compact detail unless overridden. Use --detail full for audit output, or --protocol-version 1 to preserve the compatibility-window full default. Unsupported versions fail before command work with typed no-write recovery.
Configuration and diagnostics
Section titled “Configuration and diagnostics”Exact roots: config, doctor, about, agent, and completion. Read-only inspection reports resolved configuration, runtime identity, scoped health, agent guidance, or shell integration text. Configuration edits and completion installation are explicit writes. Treat local configuration and diagnostic output as potentially sensitive.
Licensing
Section titled “Licensing”Exact root: license. Status and inspection are read-only; activation, installation, refresh, or removal can change host state and may use the network. Verify authorization, destination, confirmation, and rollback from the descriptor. See license management.
Managed versions
Section titled “Managed versions”Exact root: version. Current/list inspection is read-only. Install and update can download and replace binaries; pin writes repository selection state; uninstall is destructive and may require --replace-with. Verify exact release identity and post-install day-shift --version evidence. See installation.
Workspace migration and prompt delivery
Section titled “Workspace migration and prompt delivery”Exact roots: workspace migrate and workspace upgrade.
workspace migrate handles workspace-schema compatibility. Preview or --dry-run is required evidence before apply. Apply is an explicit multi-path write; never manually move .day-shift assets around a malformed or partially upgraded workspace. Stop on conflict or partial-state recovery evidence.
Structural migration uses --check, then --plan with explicit --mapping, --root-order, or --task-sequence values when discovery is ambiguous. Apply requires --apply, the exact --expected-plan-digest sha256:<hex>, and --confirm apply-workspace-migration. It transactionally writes canonical numbered destinations, retires legacy sources, rewrites reviewed references, and binds a durable migration record. Ordinary reads do not rename legacy paths.
workspace upgrade preview is a separate read-only latest-layer prompt-delivery check. workspace upgrade apply requires the exact preview hash and --confirm apply-workspace-upgrade; it updates .day-shift/prompts/latest and prompt materialization state without overwriting user prompts. Choose materialize, disabled, or legacy-not-materialized deliberately rather than treating a missing latest layer as automatic permission to replace user customization.
Prompts, templates, and manifests
Section titled “Prompts, templates, and manifests”Exact roots: prompt, template, and manifest. List, show, search, diff, and review report evidence. Edit, update, materialize, and manifest-update operations are explicit workspace writes and must preserve user ownership and merge boundaries.
For a delivered latest-layer change, run prompt reconcile preview --prompt <user-prompt> first. It reports the three-way base/user/upstream drift without writing. prompt reconcile apply requires that exact preview hash and an explicit preserve or replace decision; it is scoped to the selected user-layer prompt and its materialization state. It is not a generic body merge or a license to overwrite another user prompt. See prompt and template catalogs and customization.
For installed-contract drift in a workspace template, run template reconcile preview --template <workspace-template> first. template reconcile apply requires that exact preview hash and an explicit preserve or replace decision. Replace adopts the packaged body for only that selected template; it never updates manifests, prompts, workflows, generated output, or planning artifacts, and it is not a generic merge.
Resume, archive, and release
Section titled “Resume, archive, and release”Exact roots: resume, archive, and release. Resume inspection revalidates derived evidence; create/replace/cleanup changes coordination state. Archive previews are read-only and archive/apply operations move or record selected state.
release check is read-only validation of local release inputs and staged output. release build creates local release assets, then release check validates the resulting staging and archives. These local filesystem writes are not externally consequential publication actions. release build --dirty --version <version> is an engineering-only build that writes under dirty-release/<version>/; it permits an uncommitted worktree but does not publish to npm, upload website assets, create a release record, or qualify the output as an immutable public candidate. A dirty build must never be copied to a public downloads directory.
day-shift workspace migrate --check --format jsonday-shift workspace upgrade preview --latest-mode materialize --format jsonday-shift prompt diff --layer user --format jsonday-shift prompt reconcile preview --prompt .day-shift/prompts/user/task.next.md --format jsonday-shift template reconcile preview --template .day-shift/templates/phase-overview.md --format jsonday-shift resume inspect --format jsonday-shift release check --version <version> --output-dir <release-output-root> --format jsonThese examples are evidence-only. Do not substitute an apply, update, cleanup, or release write without reviewing the matching descriptor and preview.
Migration transactions and recovery
Section titled “Migration transactions and recovery”An incomplete structural apply returns a transaction id, retained .day-shift/state/transactions/<transaction-id>/ path, and exact current recovery fingerprint. Keep the lock, manifest, restricted staged bytes, status, durable migration record, and recovery receipts unchanged while deciding between roll-forward and restore.
The recovery lane is workspace migrate --recover <roll-forward|restore>. It requires the exact --transaction-id, current --evidence-fingerprint, bounded --actor and --reason, plus --confirm recover-workspace-migration. Recovery reacquires the repository lock, revalidates the same evidence under that lock, writes a sanitized receipt, verifies the selected outcome, and then removes only eligible operational state.
Live locks, stale fingerprints, diverged targets, unavailable actions, missing staged evidence, unsafe restoration, wrong transaction kind, and conflicting receipts reject without recovery mutation. Schema-only migration, partial-field migration, cross-family migration, automatic mapping, review-triggered migration, and manual transaction cleanup do not provide alternative recovery paths. See Migrate an existing workspace and Transaction and operational recovery.
Promotion transactions and recovery
Section titled “Promotion transactions and recovery”Exact roots: task promote and work promote. task promote ships Basic-to-Structured and Basic-to-Governed planning and apply. work promote ships Structured-to-Governed planning and apply. Planning is read-only by default; apply requires the exact revision-bound plan id plus actor and reason and uses an applies-transaction write posture.
Promotion preserves semantic task identity and paired implementation evidence, including attempt, baseline, validation, deviation, waiver, blocker, and review records, while rebinding destination organization metadata. Incomplete mappings, stale revisions, destination collisions, and raced plans fail without canonical mutation. Retained incomplete transactions expose exact-fingerprint roll-forward or restore recovery; do not reconstruct the move manually.
Demotion is unsupported, and review does not automatically promote or mutate lifecycle state. See Promote planning work and Promotion and evidence preservation.
Shared failure and recovery contract
Section titled “Shared failure and recovery contract”JSON output classifies usage, validation, environment, conflict, authorization, and unexpected failures and records writeOutcome. For network or host failures, confirm whether state changed before retrying. For destructive or external effects, honor confirmation and idempotency. For partial writes, follow the typed inspection or rollback action; never infer that retry is safe.
Related recovery: configuration and health, troubleshooting, and resume, trace, archive, and release handoff.