shipper auto-ship drain

shipper auto-ship drain

Usage: shipper auto-ship drain

Halt the repository until the halt is explicitly cleared

Arguments

Argument	Required	Description	Choices
None	-	-	-

Flags

Long	Short	Value	Default	Description	Choices
None	-	-	-	-	-

Examples

Halt the repository until the halt is explicitly cleared.

shipper auto-ship drain

Exit Codes

Code	When
0	A halt is recorded, including an explicit already-halted no-op.
1	Repository identity or desired-state storage fails.

Constraints

• Acts only on the current checkout and changes only the halt; enablement, worker count, safety stop, and checkout registration remain unchanged.
• A halt is a persistent operator-requested repository hold. It suppresses new automatic dispatch and automatic merges, withdraws queued automatic starts, and requests repository-control Stops for running automatic Ships at their next safe checkpoint. It survives an idle repository, running work reaching its checkpoints, and daemon, Desktop, CLI, or machine restarts, and it ends only through shipper auto-ship clear-halt.
• The halt is repository-scoped and machine-local. Disabling and later enabling Auto-ship does not clear it, and clearing an engaged safety stop with shipper auto-ship resume does not clear it either.
• Explicit manual work stays available while halted, including hand-driven workflow advances and per-run Pause and Stop actions.
• The durable write returns immediately and does not prove dispatch has stopped. Use shipper status to confirm; a running supervisor normally observes an external write within roughly five seconds.
• The command starts no supervisor and reports whether durable halt intent changed or was already set. It then performs one read-only daemon inspection and reports exactly one represented runtime observation: draining observed, no automatic work observed, in-flight work without confirmed draining, or runtime facts unavailable. Like shipper status, that inspection may briefly attach to a reachable daemon, closes the inspection connection, and can reset the daemon’s existing client-free idle grace period. It never claims the halt was consumed and never reports an observed stop or retraction count.
• Every Auto-ship record mutation first classifies the retained bytes under the shared lock. A future schema is retained unchanged and refused with its path and a request to reconnect with a current Shipper client or re-run the Shipper installation. A valid record for another canonical repository is retained unchanged and refused with both identities and a request to resolve the file outside Shipper. Neither conflict has a Shipper repair, reset, or discard gesture, and refusal output makes no dispatch-holder or mutation-success claim. Corrupt replaceable records can still be recreated, versions 1 and 2 migrate losslessly to version 3, and successful output reports core applied/unchanged outcomes plus any migration.