Reconciliation

Hostwright compares desired state from Manifest v3 with an observation from the selected runtime provider. It emits typed issues and a deterministic plan for review. Supported lifecycle commands and the managed daemon use the same fenced local operation authority.

The loop

1. Validate the selected manifest.
2. Observe provider state when the command requires it.
3. Check resources, policy, capacity, ownership, and runtime capability.
4. Produce a plan with explicit actions and issues.
5. Persist intent before any confirmed effect.
6. Verify observed postconditions and retain recovery evidence.

hostwright plan is non-mutating and does not inspect the runtime by default. Lifecycle dry-runs can include live observation. Confirmed commands revalidate the current plan, identity, provider, and authority before effects.

Background operation

The current-user daemon observes and reconciles supported drift through the same lifecycle saga. Its admission, maintenance, restart, health, and recovery policies remain subject to the declared local gates. It does not have authority to bypass confirmation rules, provider capability, ownership, or recovery holds.

The daemon and scheduler implementations are still undergoing aggregate current-source qualification. See the core reconciliation architecture, daemon architecture, and Limitations.