A Saved PID Is a Ghost
After a reboot, or after the daemon itself is gone, a number you wrote down is not a process. It is a ghost that might now belong to someone else, or to no one. Restore that treats a saved PID as still alive is how you attach to the wrong job, or to nothing, and then tell the operator the compiler is back. It is not back. A new process with a coincidental number is not the old process. Resurrection is the lie. Rematerialization is the truth: this is a new process launched from a saved recipe.
The recipe is a declaration. Host, command, directory, split geometry, maybe a seat name. Restore re-runs that command in that directory on that host. It does not scrape the last line of the journal and hope. An arbitrary command caught mid-flight is how you duplicate side effects — a deploy that already ran, a migration that already migrated, a rm that already removed. The journal is history of output, not a script to replay as input.
The Allowlist Is the Only Afterlife
A shell recipe is easy: launch the declared shell in the declared directory. A REPL or an editor is different. People want python back, or vim back, as itself, not as a shell that happens to have been in the middle of a file. That afterlife is allowed only for programs on an allowlist. The default list is a product decision, and operators can extend it. It is not a heuristic that sniffs argv[0] and guesses. If it is not listed, restore gives you the declared shell, not a second copy of a compiler that was halfway through a build.
Guessing is how you resurrect the dangerous half of a command. An allowlist is how you say, out loud, which foreground programs are safe to start again as themselves. Everything else comes back as the recipe's shell and waits. That wait is not a missing feature. It is the refusal to duplicate work.
Boot UUID Draws the Line
Live processes do not survive a reboot. Declarations do. The daemon needs a line it cannot argue with: this boot is not that boot. A boot UUID — sysctl kern.bootsessionuuid, not a hardware IOKit id — is that line. Same boot, daemon still up: a crashed projection can reattach to living jobs. Daemon restart on the same boot: PTYs are gone; restore rematerializes from declarations. New boot, living jobs are gone, restore rematerializes from declarations only. No amount of clever PID storage crosses that line honestly.
This is the Mac-owned root the phone will stand on. A pocket surface that "restores" by pretending last week's PID is still there is a pocket surface that will type into the wrong place. Restore tells the truth in the chrome: new process, old recipe. The operator can decide whether to run it.