--- title: Nighty Tidy (an overnight audit that only touches its own work) --- # Nighty Tidy (the full-vision audit panel) ## What it is > **Shipped label / internal id:** users see this panel as **Nighty Tidy** — the "2" was dropped once the legacy original (`nightytidy`) was retired from view. Its internal id, DB tables, and IPC channels stay `nightytidy2` / `nighty_tidy_2_*` / `NIGHTY_TIDY_2_*` unchanged; this page uses **NT2** for that internal identity. ### What it is **Nighty Tidy** (`nightytidy2`) is THE Nighty Tidy going forward — the original (`nightytidy`) is left untouched as legacy. It is the full code-maintenance audit panel, with four screens: - **Run an audit** — pick a project (the repo picker shows each repo's icon — its real logo or a generated tile), pick a **run mode** (Read-only = report only, or Read-write + a severity = auto-fix the findings), tick audits from its own offered list (a user-edited spec shows an **"Edited"** badge; the four Omniscio-infrastructure audits are badged **"Omniscio-specific"** and are offered ONLY on your Omniscio checkout — they describe the app's own internals, so they are hidden on every other repo rather than producing Omniscio-flavoured findings there; if you have no Omniscio checkout registered they stay offered everywhere, as before), narrow what gets audited with the **Scope** section (always visible): quick-scope **preset buttons** (Frontend / Backend / Tests / Shared / Recent changes), a **folder browser** modal to pick specific directories, selected folders shown as removable **chips**, and a free-text **custom instructions** textarea (all composed into the scope prompt appended to every audit; char counter shows combined remaining vs the 4000-char limit). Optionally pick an **engine + model** (a Claude-family harness — default inherits your usual engine/model; I35), **Start Run** (one regular session per audit, billed normally). The panel is **compact**: Repository + Run mode sit together, the engine + model section tucks behind a small toggle that opens in place — and auto-opens when a value is already set, so nothing set is ever hidden (I39). The queue below shows REAL progress — each row is driven by run-updated pushes (queued → running → completed/failed; never invented client-side), and a **"Done — new run"** button appears only once every audit settled. - **Automate** — the **automations list**: automations **grouped under each repo**. A repo's header shows its name + one **outcome signal** (last night's worst severity "1 critical" in red / "Clean" / blank if never run); beneath it sits **one row per automation** — its **label** (or "Automation 1 / 2 …"), a one-line summary (**schedule · audits · auto-fix**), and its OWN **On/Off toggle** (enables/disables just that automation — never deletes). A quiet footer reads **"Last night: N audits · $X · Limits"** (Limits opens the global **ceilings** editor); only repos that already have an automation show here, with an empty state prompting the first. **"+ New automation"** (page header) opens a **step-by-step wizard** — one page each: **Repo → Audits → Instructions → Model → Schedule → Auto-fix → (optional) Advanced → Name & review → Create**. It gathers every choice and saves ONE automation at the end (the same upsert the quick-edit pickers use); you can't finish without a repo and ≥1 audit, and a brand-new automation is **read-only** (auto-fix OFF) unless you pick a fix level on the Auto-fix page. The wizard reuses the very same controls as the edit pickers, so the two never diverge. **Click an automation row → its quick-edit detail**: a findings summary on top, then settings rows — **Name** · **Schedule** · **Audits** · **Instructions** · **Auto-fix** · **Pacing** · **Advanced** — each shows its value inline and opens one small picker; changes apply the moment you make them (no Save button). The **Pacing** picker: **Max simultaneous audits** — a −/+ number stepper (1–20; replaced the old one/few/many mode control 2026-08-27). An automation always paces — only the **Run now** screen offers one more position above 20, labelled **"All"**, and it says on screen how many of your selected audits that will start at once — and **Limit how many per day?** — _no limit_ / _cap N/day_ / _spread N/day evenly_ (the **drip**: starts ~N spaced across the day instead of all at the cadence time). The nightly **$ spend cap** moves under an Advanced disclosure (each `0` = off; the $ is an estimate, not real charges on a managed plan). **Advanced** holds a cheaper **engine + model**, a **"Start from"** audit (which audit the rotation begins at — shown when 2+ audits are selected), and a **"Stop after N runs"** lifetime cap; once a capped automation has run N full passes it reads **"Finished N of N runs"** (dormant — raise the cap to re-arm). Remove one with **"Delete this automation"** (a confirm, plus Undo). A repo can hold as **many automations** as you like (e.g. one per feature) — each an independent row with its own schedule, audits, and toggle. Each automation runs paced by its OWN Pacing caps, all bounded by **global ceilings** (the concurrency / nightly-count / nightly-$ settings in the global editor, capping the SUM across every automation) — advancing through each automation's list before repeating, then looping, optionally auto-fixing at a severity. - **History** — run rows with status, finding-count badges, and a "fixes applied" marker. A run that couldn't even START (recipe missing / repo gone) records a visible **failed** row with humanized copy — a broken automation is never silent. A run that FINISHES is recorded by its **result** (findings, or a clean pass) — including one that finishes and then parks in your Needs-You inbox on a trailing question; a completed audit is never mislabeled **failed** (and no false "scheduled audit failed" alert fires for it). A **clean pass is only ever claimed when the audit's findings list was read and is empty**: an audit whose session ended or was archived before it wrote its report records **failed** ("stopped before it wrote its report"), and one whose report came without its findings list records **failed** too, with the report still there to open. **Delete a run** (per-row trash) or **Clear** the whole list — both soft-delete, behind a quick confirm. - **Findings** — an **intelligent, structured display** (severity summary + filter pills + group-by + expandable finding cards) read from the audit's `findings.json`, instead of the giant raw-markdown report (which stays as a fallback). The no-findings state is status-aware: still-running, failed (see History for the reason), or **"Clean pass"**. It has its own run history (`nighty_tidy_2_runs`), its own subscriptions (`nighty_tidy_2_subscriptions`), its own on/off switch (Settings → Plugins → **Nighty Tidy**), and a moon-icon sidebar row in the sidebar's **Plugins** section, which is expanded by default. It ships **on by default** — a one-time backfill enables it, so the row is visible out of the box; you can turn the plugin off afterward. (Until 2026-09-04 the row nested under **Developer Tools**, which ships collapsed — that hid the row entirely and left the plugin unreachable, since its row is its only entry point. You can also reach it from Settings → Plugins → **Open**.) Its panel sidebar is a **native column** — brand → the screens as vertical nav → an **Operator sessions** list (see below). **The original Nighty Tidy is touched zero times.** **Desktop is a marketplace WEBVIEW plugin; mobile is native React.** On desktop the panel renders through the generic plugin webview (`src/plugins/nightytidy2/ui/`) so it can update without shipping a whole app release; the webview **consumes the app's injected theme tokens** — surfaces, accent, semantic status colours, fonts, and the effective font size (plugin-webview-theme-contract `optional-look-and-feel-tokens`) — so it matches the app's look, custom themes, and text size, and draws its own 5-screen nav rail (Run · Automate · History · Findings · Custom audits). **The webview carries the app's UI standards by hand (contract I61).** `src/plugins` is excluded from the root tsconfig, eslint, and every renderer-globbed i18n / a11y / design-system guard, so NOTHING in the host toolchain reads this panel's code — which is how its number dropdowns drifted until they could not commit a value at all. It therefore ships its own equivalents of the app's primitives, and its own tests are the only thing holding them up. _What holds, and is guard-locked:_ `mountDropdown` (themed, owns a LIVE selection — it repaints its trigger on every pick and compares each pick against its own current value, so returning to the value it opened with still commits; Enter/Space commit on their own branch rather than stepping the highlight) replaces the native `