Safety model

Planned conservative defaults: plan before mutation, dry-run before deletion, ownership-aware cleanup, and no secrets in logs.

Infrastructure tooling earns trust by being predictable when things go wrong. Hostwright’s intended safety posture is deliberately conservative. Today there is no runtime mutation, no apply, and no cleanup command.

Safety flow: validate the manifest, compute a plan, confirm destructive actions, then apply; dry-run exits before any mutation. — Nothing mutates before the plan is shown.

Principles

Plan before mutation. Future runtime changes must be computed and reviewable before they run.
Dry-run for cleanup. Future destructive operations must preview exactly what they would remove.
Explicit destructive confirmation. Future removal of real resources must be intentional and confirmed.
Conservative validation. Unsafe or ambiguous manifests are refused, not guessed at.
No hidden runtime mutation. Current commands do not mutate runtime state. Future mutation must use the planned, recorded path.
Ownership-tracked cleanup. No broad garbage collection; future cleanup may touch only resources Hostwright can prove it owns.
No secret leakage in logs. Future events and logs must avoid secrets and credentials.

Ownership

Hostwright must distinguish resources it created from resources you created by hand before cleanup exists. Future Hostwright-created resources should carry project and service ownership metadata where the runtime supports it; where it does not, Hostwright needs an ownership ledger in its own state store.

The rule is strict: future cleanup must never delete a resource it cannot prove Hostwright owns.

Resource	Cleanup rule
Owned containers	Removable, with dry-run preview.
Named volumes	Never removed automatically; explicit confirmation required.
Anonymous volumes	Removed only when linked to owned containers and stale.
Networks	Removed only with ownership proof and no attached foreign resources.
Images	Not removed by default.

Refusing unsafe applies

Future apply must stop rather than do something dangerous. An apply should be refused when, for example:

the stack exceeds the configured safe memory budget;
a service requests amd64 emulation without an explicit policy;
a required macOS, network, or container feature is unavailable;
a port conflict exists with no declared alternative;
an operation would require privileged access you have not approved.

Secrets

Secrets must not be committed into manifests. Future local secret handling should prefer the macOS Keychain rather than Hostwright-managed plaintext, and mounts must be least-privilege and read-only unless explicitly made writable.

Open questions

The exact ownership metadata Apple container can carry, versus what must live only in Hostwright’s ledger.
Whether anonymous-volume cleanup can be made safe enough to enable without confirmation.