Two follow-up corrections to the in-process auto-backup interception:
- The matcher previously hijacked any `fn backup …` / `fusion backup …` /
`runfusion.ai backup …` form. The in-process replacement only knows how
to do `--create` + cleanup, so scheduling `--list`, `--cleanup`, or
`--restore <file>` would have silently executed a create instead of the
requested operation. The matcher is now anchored to `backup --create`
(with optional trailing flags), with positive/negative unit tests.
- Step-based automations (`AutomationStep` with `type: "command"`) also
shell out — the legacy-command interception alone left that path
vulnerable. `executeCommandStep` now applies the same in-process backup
detour, factored through a shared `runBackupActionInProcess` helper.
Independently, `runProbe` in fn-binary now spawns with `cwd: tmpdir()`.
The dashboard's `/system/fn-binary/status` route runs `<bin> --version`
on whatever fusion binary happens to be on PATH — older releases (e.g.
v0.13.0) initialise an engine and create a fresh `.fusion/<project>/
.fusion/` tree as a side effect. Pinning the probe's cwd to the OS temp
directory keeps any such artefacts off the developer's project.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
40ecccfc9e