[mrchypark]

Reopening Dory could immediately terminate a newly bootstrapped daemon: RunAtLoad started doryd, then an unconditional kickstart -k restarted it. Reopening during an earlier bootout could also replace the still-stopping job. Separately, whole-VM shutdown could leave live-restored containers running and ignore a failed data unmount before poweroff.

Make LaunchAgent reconciliation non-destructive: accept successful RunAtLoad bootstrap, use non-forcing kickstart only when needed, and wait for a stopping job to disappear. Compare loaded Dory configuration when a plist was recreated while preserving genuine plist changes such as ExitTimeOut. Equivalent plist serialization does not trigger replacement.

Preserve Docker live-restore for daemon-only restarts. Whole-VM shutdown validates and atomically replaces daemon.json, sends HUP, and requires effective LiveRestoreEnabled=false confirmation through the explicit local Unix socket before terminating dockerd. Configuration validation and reload polling share a monotonic ten-second budget, including probes near the deadline. Disappearance before confirmation fails closed. Require service exit, checked data unmount and root read-only remount before poweroff. Align helper/host/launchd budgets at 55/60/70 seconds, with longer client budgets. Both generated VZ init and fallback init handle mountpoint -q correctly.

Source validation:

• Latest-main PR sources: 21 generated-shell tests plus one timing test passed in an isolated harness. Local app sources: 20 shell tests plus one timing test passed.
• Lifecycle tests: 36 passed for PR sources and 33 for local app sources. The executed pre-fix newborn-daemon-kill replay was rejected.
• Coverage includes late reload recovery, persistent API failure, daemon disappearance, PID 1 protection, service ordering, reclaim children, failed unmount/root remount, configuration preservation, generated/fallback parity, and stale 45-second launchd templates.
• Corporate-connectivity static contract, plist/shell syntax and diff checks passed. Default live-restore assertions remain intact.

Installed validation limits:

The installed candidate contained this change, its independently proposed host-share companion, and local signing/build integration. It was not an independent runtime test of this upstream branch. Two ordinary GUI quit/reopen cycles passed path/signature/PID and stable health checks, although initial four-second API requests timed out before recovery. One normal engine stop reported checked data unmount/root read-only; restart retained selected Docker/PVC payload hashes and live-restore. The original native Linux e2image workload completed without the earlier host-share engine crash. Boot e2fsck completed all five passes with exit 0; data e2fsck completed all five passes with exit 4 for a disconnected directory inode. The checker was not OOM-killed.

Zero complete engine/filesystem acceptance cycles passed. The disconnected inode's cause is unproven; no completed earlier data fsck establishes a clean baseline. Earlier prototypes are not substituted as evidence for this revision. Dory repair work has stopped following the user's transition decision. This proposal remains held for the parent to decide whether to submit as an explicitly qualified draft after the replacement environment is verified; it must not be presented as successful full installed acceptance.

Full-package verification is incomplete. The PR checkout's own Rust sources produced its compatible FFI artifacts and passed provenance checks. Two earlier filtered full-package attempts on the patched checkout failed before tests in unchanged MachineManager code (Any to UInt64). No clean upstream-main compile was run, so baseline causality is not established.

Submitted as a draft for source review. The combined installed Dory candidate did not pass complete engine/filesystem acceptance; the data fsck failure and its cause remain unresolved. No further Dory runtime qualification or repair is claimed.

Companion: #112 — independent host-share drain/ACK timing proposal. Installed observations above apply to the combined candidate and do not establish full filesystem acceptance.