shipper auto-ship resume
shipper auto-ship resume
Section titled “shipper auto-ship resume”Usage: shipper auto-ship resume
Clear an engaged Auto-ship safety stop
Arguments
Section titled “Arguments”| Argument | Required | Description | Choices |
|---|---|---|---|
| None | - | - | - |
| Long | Short | Value | Default | Description | Choices |
|---|---|---|---|---|---|
| None | - | - | - | - | - |
Examples
Section titled “Examples”Clear an engaged repository safety stop without enabling Auto-ship.
shipper auto-ship resumeExit Codes
Section titled “Exit Codes”| Code | When |
|---|---|
| 0 | The safety stop is cleared or none was engaged. |
| 1 | Repository identity or safety-stop storage fails. |
Constraints
Section titled “Constraints”- Clears only the current repository safety stop. Enablement, worker count, repository halt, and checkout registration remain exactly unchanged.
- This command is not an enable gesture and is not a halt-clear gesture. Use
shipper auto-ship clear-haltfor an operator halt. It reports cleared when a stop was engaged and succeeds as an explicit no-op when none was engaged. - The command works with no supervisor running, starts or contacts no supervisor, and returns immediately. It records local durable runtime state when clearing an engaged stop; when none is engaged, it only inspects the state and performs no write.
- Enabled means requested rather than running; repository-control state may request safe-checkpoint Stops or retract unconsumed requests after observation; a running supervisor normally observes an external write within roughly five seconds.
- Only a strictly proven alive holder may be named. Absent, unreadable, malformed, mismatched, dead, or indeterminate evidence is reported unavailable without claiming that nothing is running.
- 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.