mirror of
https://github.com/l0ng-ai/tty7.git
synced 2026-10-09 08:02:12 +00:00
l0ng-ai
21ddd01bc9
`crash::install` puts a panic hook in front of `crash.log`. The GUI installs it and the server installs it. The updater did not — and of the three it is the one that needs it most. It runs *detached*, after the GUI it is replacing has exited, so its stderr is attached to nothing anybody will read. And it is doing the one job in this product that can leave an install broken. A panic mid-swap was therefore silence: the app does not come back, `tty7-updater.log` stops mid-sentence, and there is nothing anywhere that says why. All three of its `cfg`'d mains install it now, so the role travels with whichever platform failed. `crash.log` is the file the other two roles already write, in the config directory, so the three land in one place in the order they failed. The CLI stays out deliberately: it is a short-lived foreground process whose panic prints to a terminal someone is already looking at, and a second copy in `crash.log` buys nothing. The guard reads the three entry points rather than a list kept here, and was checked against the state that shipped — it names the updater. The mechanism itself was already covered: `a_panic_lands_in_the_crash_log` proves the hook writes the record. What nothing held was whether each binary calls it, which is exactly what was missing.