Shipping & Running
$defineprocess--plain-english
TLDROne running instance of a program — a living copy, not the file.
The MP3 on disk is silent. Hit play and you have a process.
Same bits. One of them is alive. It has an id, a slice of RAM, a slice of CPU. Close the player, the process dies. The file is still there. You can start a new performance whenever you want. Two players can open the same file. That is two processes.
bun run dev is you hitting play on the app. The runtime sits down and starts a process. Kill the terminal — or close the lid — and localhost goes dark. You did not delete the repo. You ended this particular living copy.
Why the todo list evaporates
RAM belongs to the process. In-memory state is a note taped to the performer. Restart, new performer, empty pockets. The database is how truth outlives any one run. If you "fixed" a bug by restarting and the bug is gone, you probably hid state in RAM.
A daemon is a process that keeps playing after you leave the room. On a laptop you usually just leave the terminal open. On a server, logout should not be an encore that kills the show.
Activity Monitor / ps is the list of who is currently on stage. When the laptop fans up during a demo, you are not asking "what files do I have." You are asking which processes are eating the room.
An agent is the same split. The system prompt is the file. The running agent is a process. Stop the process and the agent is gone, even if the instructions still exist. create-hackhaton-space-stack gives you scripts that start processes. You give them a cabinet so the next performance still knows the plot.
What this unlocks
"Kill it and start it again" stops sounding violent. You are ending a performance, not shredding the score. The CLI dev command is one living copy. Deploy is another, on a machine that does not close its lid.
The file is the song. The process is the night it is playing.