Reading incomplete bootout receipts

One malformed later field must not erase an earlier native change, and an acknowledged change must not turn an incomplete operation into success. Stado keeps both facts in the same failure receipt.

Read the normal command result

stado service bootout LABEL --host HOST --domain user --json

system selects the system scope; user selects the calling account's scope. Without --domain, selection stays system-preferred. The command does not remove the unit file or withdraw its registry declaration. See Service reconciliation receipts for native scope selection, failure classifications and the evidence fields.

A refusal receipt is printed as JSON and still returns a command error. Its detail retains the actual parser/native cause; evidence is not replaced by an empty object just because the overall result is unusable. Existing lifecycle errors and reconciliation rows carry the same retained facts into Desktop.

When a program result is available, failure detail retains its program_exit and nonempty stderr alongside the operation, target, scope and native detail. A program can exit successfully after reporting a native refusal; its stderr is not discarded because that exit is zero. A nonzero program exit remains an execution error even with a refusal packet and does not erase acknowledged effects.

What survives a later malformed field

Once a native operation descriptor has been validated for the requested system/user group, its acknowledged effect remains in confirmed even if a later descriptor is malformed. An invalid descriptor never gains change credit. For example, a GUI or user-domain acknowledgement cannot satisfy an explicit system request, nor can a system acknowledgement satisfy an explicit user request.

A usable native refusal phase is retained before later effect fields are read. Its original native detail remains alongside the later parsing cause. Known native mutation/postcondition failures therefore remain visible independently of the fact that the complete result could not be read. Earlier acknowledgements keep their order; usable pending work remains pending.

When there is no usable pending descriptor, the failure retains the requested bootout as unresolved rather than inventing a more specific native action. That request proves neither that the action executed nor that it had no effect. With no usable execution acknowledgement, the result remains execution unconfirmed. With an acknowledged prefix but no earlier native refusal phase, the later unusable result is an observation failure, not a claim that nothing ran. A previously reported native failure remains the first phase.

A coherent native sequence

One invocation uses one native manager and one system-versus-calling-account group, including with system-preferred any. A receipt cannot combine both groups or mix launchd with systemd. Reported launchd calling UIDs must agree; when the operation is bound to an exact native identity, its manager and any reported UID must match that identity too.

Effects cannot repeat or arrive out of order. Systemd positive completion needs both a verified stop and its later disable acknowledgement for the same scope; a stop alone is retained partial progress, not completed bootout. The compound stop/disable descriptor can only describe the unresolved initial request, and a pending disable requires the earlier verified stop. Launchd cannot acknowledge one namespace twice or report GUI work after the later user-domain work.

A coherent refusal can retain its valid partial sequence. A missing required acknowledgement, wrong manager/UID, duplicate or impossible transition instead refuses completion without crediting the offending descriptor. Earlier validated effects and the first native failure remain visible.

What is not accepted as proof

• Missing, duplicate or ambiguous operation packets and invalid field layouts do not authorize selecting an arbitrary packet or guessing a successful action.
• An unrecognized state or contradictory native failure phase is not a usable terminal result.
• absent and already_correct cannot carry operation effects. Such a contradiction does not become a credited change or successful no-op.
• A later malformed field or contradictory completion remains a command error, even when earlier effects are retained. A nonzero program/transport exit also remains an error and keeps the available evidence.

These are observations, not transactional rollback. A failure can legitimately show both an acknowledged native change and unresolved later work. Do not read host_mutation: true, one confirmed entry, or a printed receipt as completion of the whole bootout or retirement operation.