Foundation: complete host startup, maintenance and planning-agent setup #83

Factory's execution host should come back ready for work after a normal reboot and have an owned maintenance routine. On 20 October, the owner asked for this to be configured on the existing host and made part of Foundation setup, including the host planning agent's relationship with Foundation.

The current method already mentions startup, recovery and update ownership, but an installation can still look ready while the operator apps do not start and no maintenance schedule is active. Turn those requirements into applied, verified setup and a clear operational handoff.

Responsibility and architecture

Document the owner-side host planning agent/coordinator as an installation choice with an explicit mandate. It retains host continuity, coordinates shared-host maintenance and asks Foundation to prepare or repair the conditions for work. Foundation owns the reusable setup method and supplies scoped readiness evidence. Existing project AgentOps leads retain product priorities, workers and acceptance; ADLC retains task execution.

The coordinator role does not grant administrator access or expose personal accounts/connectors to Factory workers. Resolve the actual host, account, native client/server routes, permissions and recovery operator during setup. Reuse the same coordinator and existing leads across ordinary restarts and migrations. Keep identities, paths, raw history and recovery material in the private installation record.

Required setup outcome

• Configure the chosen operator applications to open through supported desktop startup after login. Distinguish desktop startup from headless service boot, and account for encrypted-disk unlock and any login step.
• Verify the native execution service, user-service persistence where needed, network/Tailscale and the chosen remote-access service start and recover through their supported service managers. Preserve existing access controls and account boundaries.
• Set an appropriate host power policy: remain reachable on external power, retain deliberate screen locking and battery protection, and explain what requires local intervention after power loss.
• Establish one owned nightly maintenance opportunity using the selected native scheduler. Record the channel and update owner separately for the OS/packages, desktop apps and T3 execution service. Avoid duplicate schedules after migration.
• Distinguish check/no-op, installation, required restart and verified continuation. A timer or release notification alone does not prove automatic updates. Defer an unsafe transaction with its exact next action and owner.
• Use verified recovery material before consequential changes. Check disk space, time synchronization, useful logs and bounded retention. A root filesystem snapshot is not proof of a consistent backup of live application data or the home subvolume.
• Test the chosen boot/login, client-disconnect, reconnect and scheduled-wake paths at a safe boundary. Reuse unchanged evidence; notify on meaningful failure, required action or completed change rather than daily unchanged status.

Acceptance

• Foundation's existing setup/adoption guides and architecture explain the host coordinator/Planning Agent relationship and operational handoff.
• A representative installation applies the selected startup and service configuration and verifies it through normal OS/native readback.
• A controlled reboot/login plus independent client reconnect demonstrates the intended reachability; unlock/login limitations remain explicit.
• Exactly one maintenance schedule wakes the intended host coordinator, produces an attributable result and preserves ongoing work.
• One eligible native update or genuine already-current result is qualified, including recovery and continuation where applicable.
• Missing access, recovery or launcher evidence is retained as an actionable gap with a named role, not silently marked complete.
• Updated method checks and independent representative review pass; public evidence is sanitized and private installation details stay private.

Related: #34 owns the current T3 safe-update/recovery qualification; reuse it rather than creating a parallel updater. #80 owns effective account/instruction/connector boundaries; #32 owns broader worker access boundaries. This issue owns completion of the reusable host setup and architecture/operational responsibility. Prefer OS, T3 and harness facilities; add no Factory daemon or orchestration runtime.