§16. CLI and console

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

CLI: planarian status | log | incidents | approve <hash> | resolve <txn> --as-committed|--as-reverted|--manual-repaired | undo | mark-good | mark-security-floor | override <unit> [--leave-alone|--stopped|--absent|--detached] [--until] | release <unit> | stop <unit> [--until] | ack | report boot | posture | hold release <unit> [--until] | agent run <name> -- <command> | gc, and ask "<phrase>". agent run starts an agent with the caller’s permissions, attributed to the agent (§11); it refuses a name already in use (I24). override/stop/release create and lift Overrides with the caller’s identity. ack acknowledges a failure-posture alarm (administrator for Integrity) and, with a unit, an inferred override (§11). report boot prints the last boot report; posture prints the declared posture and timeout and whether a weaker declaration is waiting for the next boot (§12d). Every verb §16 names exists in A; changing the posture or timeout is a configuration change (§12d). approve and mark-good require root and an interactive TTY in Phase A, the TTY established by the daemon from the peer for both verbs (§11; known weakness: any root process with a terminal qualifies; broker in C). mark-good changes the recovery baseline and requires administrator authority. known_good is always boot-confirmed (I1); mark-good on a boot-confirmed generation moves known_good to it. mark-good --accept-unconfirmed instead sets a separate accepted_baseline, which the revert path may use as revert_to when it is newer than known_good, but which never replaces known_good in the boot menu until a reboot confirms it. Both are refused if any Readiness probe is failing. Initial enrollment: the first generation booted after install becomes known_good once its Readiness probes pass at the 10-minute checkpoint on that boot; until then Planarian runs with max_tier = Runtime and reports “no baseline yet.”

Approvals show the change (owner decision, Nov 2). For a generation transition (ApplyChange, SwitchGeneration, Revert, Rollback) that asks, planarian approve, the console and the notice show the configuration diff it would apply: each option added, removed or changed, with its old and new value and its sensitivity, the Security- and External-sensitive ones first, and the units it would remove or stop. The same diff is part of the pending approval as structured data (planarian approve --json; IPC PendingApproval.diff), so an agent reads exactly what a person sees. The core computes it from the evaluated generations, never from the proposal; if it differs when the facts are re-derived at approval, the approval does not apply: the change is refused as stale, or asked for again when it re-binds.

Operational limits (normative): attempt budget 3 per incident; backoff 10 s / 60 s / 300 s; stabilization 5 min; regression window 30 min; escalation at 3 regressions; cooldowns 1 h then 6 h; token expiry 24 h; tick 5 s; probe timeouts as declared, default 10 s; settle default 15 s; generation deadline 15 min (networking 90 s); watchdog period 10 s; job-drain wait 60 s; journal preallocation 64 MB, compaction at 75%.