Restructure System Operation into a user-first Daily Operation page

[mairas]

Problem

user-guide/operation.md ("System Operation") is the first page after Getting Started, but ~150 of its 207 lines document firmware internals (Solo/Co-op modes, numbered shutdown sequences, watchdog mechanics) that are invisible to users on HaLOS or any OS with halpid. The everyday content (shutdown behavior, LED meanings) is buried at the bottom or written in firmware vocabulary. The page also carries facts that contradict the firmware.

Verified facts (firmware config.rs @ main, live device fw 3.3.1 / halpid 5.1.1)

• auto_restart: the firmware constant is true, but the production test suite sets it to false on every unit since early 2026 (HALPI2-tests 222_set_auto_restart_action.py), so current devices do not restart after a software shutdown. Older units restart after ~5 s (OFF_STATE_DURATION_MS). Toggle with halpi config set auto_restart <bool>.
• Watchdog timeout default: 10 s, not 30 s as operation.md claims.
• Blackout timer: 5 s (solo firmware default and halpid blackout-time-limit).
• Forced power-off after shutdown request: 60 s. Supercap thresholds: 8.0 V on, 5.5 V solo off. LED bar: LED n covers 5+n…6+n V.
• LED patterns per led_patterns.rs: operation.md's table is correct; troubleshooting.md's "scrolling green/yellow", "LED 1 flashing red = input >32 V", and "all blinking red = hardware fault" patterns do not exist in firmware.
• Standby is shipped (halpi standby with delay/datetime wakeup; EnteringStandby=blue, Standby=dim red), not "future" as operation.md says.
• Input voltage: official spec 10–32 VDC (shop, index.md). getting-started.md and troubleshooting.md say 11–32 (wrong). technical-reference/hardware.md says 9–36 — open question, needs an owner decision (component rating vs marketed spec).

Plan — phase 1 (English only)

1. Rewrite user-guide/operation.md in place as Daily Operation (~75 lines): automatic-power-management lead, powering on, shutting down (auto-restart gotcha first), canonical LED table in user vocabulary (keep the ## Status LED Indicators anchor), power-loss behavior, health check, running-without-daemon callout, blinkenlights pointer. No file moves, URL preserved.
2. Fill technical-reference/controller.md (placeholder) with the displaced internals: modes, shutdown sequences, watchdog, standby, exhaustive LED/state table, config parameter defaults, I2C pointer.
3. Fill technical-reference/power-supply.md (placeholder): input stage, current limiting, supercap charging/backup figures, power-loss detection thresholds.
4. Seed faq.md (restart-after-shutdown, keep it off, backup duration, power-loss action, persistent yellow bar).
5. Fix misdirected links: getting-started.md:196,200,343,383 → hardware.md anchors; retarget #power-management-and-shutdown-procedures references (troubleshooting.md, interfaces.md); hardware.md "Boot procedures" link; drop phantom "Common Use Cases" references (index.md, getting-started.md).
6. Correct facts everywhere: watchdog 10 s, voltage 10–32 V on user-facing pages, standby status, troubleshooting LED table reconciled with firmware.
7. mkdocs.yml nav: retitle "System Operation" → "Daily Operation"; tech-ref "Interfaces and Connectivity" → "Interface Reference"; flatten single-page Getting Started section; remove empty placeholder pages (integration, advanced-config, resources, compliance) from nav, keeping files.

Phase 2 (separate PRs, later)

• Translate changed pages into the 9 locale trees; add nav_translations keys for renamed titles — done in PR Restructure System Operation into a user-first Daily Operation page #47 (merged 2026-08-12)
• Fill software-development/daemon.md (config parameter + REST API reference promised by software.md)
• Split the 494-line Getting Started page; merge its embedded troubleshooting into user-guide/troubleshooting.md
• Decide the canonical input-voltage range in technical-reference/hardware.md (9–36 vs 10–32) — decided in PR Restructure System Operation into a user-first Daily Operation page #47: 10–32 VDC everywhere
• Add LED-table drift guard note to HALPI2-firmware release checklist

[mairas]

Phase 1 decisions from the PR #47 review cycle: input voltage is officially 10–32 VDC everywhere (the 9–36 entries in the Hardware Reference were aligned in the PR, so the phase-2 checkbox for that decision is resolved). Review also surfaced daemon/firmware bugs now tracked in HALPI2-rust-daemon#103/#104/#105 and HALPI2-firmware#41/#42; the docs document halpi shutdown and standby as working on the assumption those fixes land first.

[mairas]

Fact correction: the firmware constant DEFAULT_AUTO_RESTART = true is not the shipped default — the production test suite writes auto_restart = false into every unit since early 2026 (HALPI2-tests tests/200_controller/222_set_auto_restart_action.py). The issue body fact sheet and the PR #47 pages (Daily Operation, FAQ, controller reference) are updated: current units stay off after a software shutdown; enabling restart is the opt-in, and pre-2026 units shipped with it enabled.

[mairas]

Plan change: the 9-locale translations are required before PR #47 merges, not a follow-up PR. Doing them on the PR branch now; the nav_translations keys for the renamed titles are included.