§12f. Activation scheduling

planarian @ a924e09 · Spec v4.6 · snapshot main · all versions

A verified candidate whose activation would restart or reload any unit in an active user session (audio, compositor, input, network, the session itself) waits in Built until an activation window: the session is idle, the user asks, or the next boot. It never activates while Foreground holds in any session, except a rollback the user or an Intent requests, or a repair rollback, as below. Changes that only take effect at boot (kernel, initrd, drivers) take the boot-only path (§12, step 7): published as a one-shot next-boot entry in AwaitingBoot, with a non-urgent “restart to finish” notice, and confirmed or reverted at that boot. Repairs are exempt: restoring a failed unit is not an activation. A transaction waiting in Built holds no lease-gated mutation and counts as active for I6, so §12a write-backs queue behind it; if the daemon restarts, it is Rejected(Interrupted) per the crash table and re-prepared with its original caller. “The next boot” as a window therefore means: re-prepared after boot and activated before any user session starts. Parking is bounded (owner decision, 30 Oct): a transaction may wait in Built for at most the parking limit (24 h, CLOCK_BOOTTIME); when it expires the transaction is Cancelled(Daemon) with a notice naming the change and how to re-issue it, and the incident, if any, reopens. AwaitingBoot has no limit — it waits for the reboot it was published for — but the console and planarian status report it as waiting for a restart, distinct from any failure, and the “restart to finish” notice is repeated daily. I12 is qualified accordingly.

Rollbacks (owner decision, Oct 31). A Rollback with Source::User or Source::Intent (planarian undo, “roll back”) runs at once: the request is the activation window, also while Foreground holds (owner decision, Nov 2). A Rollback with Source::Diagnoser, proposed after in-place repair of an incident has failed (§13 orders it last), is a repair: it does not wait for an activation window, and is not parked in Built. Being a repair exempts it from waiting, never from asking: the §11 disruption floors apply to it as to any transition, so a repair rollback that would end a session is AskFirst. While Foreground holds, a repair rollback runs only if its incident’s target is one the foreground work plausibly depends on (the list under Quiet mode); otherwise the diagnoser does not submit it — it is deferred with the incident, as quiet mode defers any repair, with no transaction opened, and runs when quiet mode ends. The revert of a candidate that fails its own checks (Reverting, §12 step 7) is that transaction’s recovery, not an activation, and is never deferred. I6 still holds: a rollback is a generation operation. When a repair rollback, or a rollback the user or an Intent requests, is about to run (admitted, and approved if it had to ask), an active generation transaction that has not yet mutated (one waiting in Built for its window) is withdrawn for it, Rejected(Interrupted), and prepared again once the rollback is terminal; one past Built is waited for, like any other. A rollback still waiting for approval withdraws nothing (owner decisions, Nov 2). Gym cases: rollback-repair-foreground-dependency (a committed update breaks Wi-Fi during a Foreground workload; the rollback runs at once, with one notice); rollback-repair-foreground-unrelated (the same update breaks the printer service; the rollback waits for the workload to end, then runs, and the incident’s budget does not advance meanwhile); rollback-repair-session-loss-asks (a repair rollback that would restart the compositor of an active session is AskFirst and does not run without approval).

Quiet mode. While Foreground holds for a session: Diagnostic probes and the gym’s trend work are deferred and Readiness probes drop to their slowest interval; activation of staged generations, garbage collection, store optimization, catalog and model updates, and sandbox snapshot creation are deferred; non-urgent notifications are queued and delivered as one batch when quiet mode ends; the model is not loaded (§20). Not deferred: repairs of units the foreground work plausibly depends on (audio, compositor, input devices, network, Bluetooth), including a repair rollback whose incident targets one of them (see Rollbacks), failure-posture responses, and repairs the user requests. Deferred repairs are deferred in fact: their incidents’ budgets and backoff do not advance while quiet mode holds (§13), and the repair loop skips them rather than running them. Gym case: a reference game workload runs while a garbage collection, a staged update, and a non-urgent fault are queued; frame-time p99 matches a baseline with Planarian stopped, and each deferred item runs within its window afterward; a PipeWire kill during the workload is repaired immediately and produces exactly one notice.