fix(kernel-cli): log fatal exits from daemon-entry before terminating

[FUDCo]

Summary

• Add process-level handlers in daemon-entry.ts for uncaughtException, unhandledRejection, SIGHUP, and exit.
• Each handler synchronously appends a line to daemon.log before the process exits.
• Handlers install at module load, before main() runs, so early kernel-init failures also leave a fingerprint.

Why

daemon-entry runs with stdio: 'ignore' under the CLI spawner (see daemon-spawn.ts). Node's default behaviour on uncaughtException / unhandledRejection (print stack to stderr, exit 1) therefore writes to nowhere, and the operator sees only that the daemon vanished — no trace in ~/.ocap*/daemon.log.

I've hit two silent daemon deaths in the last few weeks (matcher daemon disappearing mid-rehearsal, services daemon disappearing between registration and the next call), and in both cases the log ended cleanly on the last successful message with no shutdown line, no error, no stack trace. Debugging cost real time each time.

With this change, every terminating path now leaves at least one line:

[timestamp] [error] Uncaught exception (about to exit): <stack>
[timestamp] [error] Process exiting (code=1).

or

[timestamp] [error] SIGHUP received; exiting.
[timestamp] [error] Process exiting (code=0).

Log-write itself is wrapped in try/catch so a broken log file doesn't mask the original exit cause.

Test plan

• yarn workspace @metamask/kernel-cli test:dev:quiet --run — all package tests pass.
• yarn workspace @metamask/kernel-cli lint — clean.
• CI green.
• Manual (in a downstream branch): induce an uncaught exception in a scratch daemon under a temp $OCAP_HOME, confirm the log line lands and the process exits 1.

🤖 Generated with Claude Code

---

Note

Low Risk
Observability-only changes to daemon exit paths; SIGHUP now logs and exits 0 explicitly instead of the default silent terminate, with no auth or data-handling impact.

Overview
Daemon fatal-path visibility when the CLI spawns daemon-entry with stdio: 'ignore': uncaught errors and signals no longer vanish with no record in daemon.log.

daemon-entry now builds the file logger at module load (before main()), registers installFatalHandlers() immediately, and logs then exits on uncaughtException, unhandledRejection, and SIGHUP, with an exit handler that always writes a final line. The log transport switches from dynamic require('node:fs') to appendFileSync so fatal handlers flush synchronously. CHANGELOG documents the fix under Unreleased.

^{Reviewed by Cursor Bugbot for commit 70b96eb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	71.31% ⬇️ -0.08%	8869 / 12437
🔵	Statements	71.13% ⬇️ -0.08%	9019 / 12678
🔵	Functions	72.46% ⬇️ -0.13%	2140 / 2953
🔵	Branches	64.81% ⬇️ -0.11%	3584 / 5530

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
packages/kernel-cli/src/commands/daemon-entry.ts	0% 🟰 ±0%	0% 🟰 ±0%	0% 🟰 ±0%	0% 🟰 ±0%	14-203

Generated in workflow #4529 for commit 70b96eb by the Vitest Coverage Report Action

[grypez]

I think it would suffice to create the logger at file root scope instead of in the main header. File-scoped logger for entrypoints is alreadystandardconvention across the monorepo; seems we just missed this one because it is a command.

[grypez]

Suggested change

	/**
	*Appendafatal-pathentryto`daemon.log`synchronously.Usedfrom
	*`process.on('uncaughtException' | 'unhandledRejection' | 'SIGHUP')`
	*handlerswheretheasyncloggerpipelinecan't be trusted to
	*flushbeforetheprocessexits.Best-effort: ifthelogfileis
	*unwritableweswallowtheerrorratherthanthrowfromafatal
	*handler.
	*
	* @paramlogPath-Thedaemon-logfilepath.
	* @parammessage-Shortlabelfortheentry.
	* @paramdetail-Optionalextradata(stack,error,etc.)—coerced
	*tostring.
	*/
	functionlogFatalSync(
	logPath: string,
	message: string,
	detail?: string|number,
	): void{
	try{
	consttail=detail===undefined ? '' : ` ${detail}`;
	constline=`[${newDate().toISOString()}] [error] ${message}${tail}\n`;
	// eslint-disable-next-line n/no-sync -- fatal handler must flush before exit
	appendFileSync(logPath,line);
	}catch{
	// Best-effort — the daemon is dying either way.
	}
	}

The logger dispatch routine is already synchronous; async methods follow 'spray and pray' semantics, i.e. best effort.

I think the process.on handlers are doing the work here, not this function.

[FUDCo]

Good call — done in 70b96eb. Logger dispatch is indeed synchronous (Logger.#dispatch iterates transports via .forEach) and our file transport is appendFileSync, so logger.error(...) from a fatal handler flushes to disk before exit. Dropped the parallel sync helper.

[grypez]

Suggested change

	logFatalSync(logPath,'Uncaught exception (about to exit):',detail);
	logger.error('Uncaught exception',detail);

[FUDCo]

Done — the handler now calls logger.error(...) directly, and the file-scoped logger it references is hoisted to module top level in the same commit.