Nighty Tidy — known boundaries (part 3)

What it is

This is part 3 of the Nighty Tidy page. Parts 1 and 2 explain the owned-versus-shared boundary, how to run one, and the machinery under a run. This part collects what can still go wrong around an unattended night, and what Omniscio does about each of those cases.

Where to find it

Nothing here has a screen of its own: each boundary shows up as a row in Nighty Tidy → History or as a session still sitting in your inbox after a restart. Read this page before leaving a large run unattended overnight.

How it behaves

Known boundaries

• The offered LIST is independent, but two audits sharing a slug share the on-disk spec — use a NT2-specific slug to diverge a prompt.
• Concurrent same-slug runs from both panels on one project collide on the audit-<slug> worktree (one fails gracefully).
• A scheduled audit spanning an app restart loses its in-memory watcher; at next launch the startup cleanup RESCUES a run whose audit finished before the restart (its report on disk → History records its real success/findings result) and reaps only report-less rows to failed (the 24h watchdog is the steady-state backstop). Parked sessions stay in your inbox either way; only a restart landing BEFORE the report was written still records failed for work that might have finished. A crash that wrote NO new report but left a PRIOR run's report on disk is recorded failed, not a false findings: the run's report is kept only when it is genuinely this run's output (a fresh file time OR a _Completed: stamp at/after the run's start), so a weeks-old leftover can't be mis-recorded as this run's result (fixed 2026-08-27).
• A restart never re-runs an audit that already has a session (fixed 2026-08-25). The cleanup can auto-restart an interrupted run, but only when the run never spawned a session at all. Three checks now stand between a restart and a duplicate: the run is left alone if an audit session for it exists in ANY state (a restart parks live sessions into a terminal status and a recovery sweep re-arms them a minute LATER — that gap spawned duplicates); completion is proved from the run's own report folder rather than a file timestamp (on Windows a copied report keeps the SOURCE file's older timestamp, so a finished audit read as unfinished); and a re-dispatched run whose automation was deleted or disabled in the meantime is cancelled, not spawned — it shows in History with that reason.
• A run recorded failed that had actually published its findings now settles itself (fixed 2026-10-17). An audit can publish its findings while its report never comes home and its report path is never stored, so History said "no results" beside a database holding hundreds of them. failed is final, so nothing revisited those rows. The app now settles such a run from the findings it already holds: it becomes findings (or success when every finding was refuted), with the severity counters and the "findings imported" stamp re-read from the table and the false failure message cleared. No fix wave is started for a run healed this way — the findings are kept so one can go out later, but nothing paid launches while you have waves paused. It asks whether a session is still working the run before touching it, and a run parked on a question in your inbox is never touched. The same repair now also runs by itself — at startup and hourly — so a run whose counters, report path or wave plan never finalised heals without anyone running a command; a run with no findings and no report is left failed, which is the truth.
• An audit whose session dies at start now fails on that cause, and retries once (fixed 2026-10-16). A session parked on the durable recovery_failed give-up state — a cloud session that could not finish starting up, or that lost its machine — used to be read as "still recovering" and polled all the way to the 24-hour limit, which then told you the audit "ran too long without finishing". It had not: it never ran. History now names the real cause (the session failed to start or lost its connection) and the run settles about 30 minutes after the park rather than a day later, and a report that still arrives inside that window is recorded as the result it is. When the session died within 15 minutes of its run starting and shows no work at all, the audit is re-run once automatically on the same History row with the same scope, label and where-to-run choice; a restart cannot trigger a second attempt, and a retry that dies the same way records "could not start, twice". The 24-hour limit is unchanged for an audit that is genuinely still working.
• Auto-fix (apply) sessions are a separate cap and out of scope for the inbox-stay change above — the reported issue + fix were the read-only audit schedule.

For agents

These boundaries are enforced in the run watchdog and the findings backfill named in the frontmatter, plus the startup cleanup that re-arms or reaps a run at launch. The record of each repair is in the Nighty Tidy contracts.

Related

• Nighty Tidy — part 1, the owned-versus-shared boundary and how to run one.
• Nighty Tidy — how it works (part 2) — the machinery under a run and how to drive it from an AI operator session.
• night-shift.md — queuing a plan of work to run while you sleep.