Operations and administration commands

Operational commands inspect or change workspace and host state, network availability, licenses, installed versions, and release output. 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

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

Exact root: license. license status verifies local license and reminder evidence without writing. license install installs a signed file into user-local storage; license cleanup-reminders removes eligible managed reminder regions. Online activation, refresh, and a license-removal command are not implemented. Purchase and recovery remain website-owned flows. See license management.

Managed versions

Exact root: version. Current/list inspection is read-only. version install accepts a local package source; version check --network explicitly checks remote availability. Selection and pin commands change local or repository selection state; uninstall removes a managed version and may require --replace-with. The GUI’s update flow is separate from these CLI commands. Verify exact release identity and post-install day-shift --version evidence. See installation.

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

Exact roots: prompt, template, templates, and manifest. templates list and the prompt/template reconciliation previews report evidence without writing. Prompt init/edit/update, template update/materialize, reconciliation apply, and manifest update are explicit workspace writes and must preserve user ownership. Do not infer a callable list, show, search, or diff command from a reserved descriptor.

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

Exact roots: resume and release. Resume inspection revalidates derived evidence; create/clear/cleanup changes coordination state. There is no top-level archive command. Use spec archive <id> to archive a registered specification; it changes registry visibility while retaining the source and history. Release archives are outputs of the separate release-build flow.

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 json
day-shift workspace upgrade preview --latest-mode materialize --format json
day-shift prompt reconcile preview --prompt .day-shift/prompts/user/task.next.md --format json
day-shift template reconcile preview --template .day-shift/templates/phase-overview.md --format json
day-shift resume inspect --format json
day-shift release check --version <version> --output-dir <release-output-root> --format json

These 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

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

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

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.