Start Lab V1 Lite Before Windows Compute
Context
The current public host can publish documentation and automation evidence, but it cannot safely host the Windows VM lab because nested KVM is unavailable and resources are limited.
Decision
Proceed with a lightweight-first Lab V1 milestone on the current public host: portfolio evidence, architecture docs, synthetic data, PowerShell scaffolds and future runbooks. Keep the full Windows VM lab blocked until separate compute and private access are approved.
Alternatives Considered
Wait for the final lab host before doing more work
- Avoids any chance of confusing planned work with implemented work.
- Stops useful documentation, automation and portfolio progress.
- Leaves public evidence thin while the compute decision is pending.
Force Proxmox or Windows VMs onto the current public host
- Would avoid buying or selecting another host.
- No nested KVM is available.
- The host is too small for reliable Windows VM workloads.
- Existing services would inherit unnecessary operational risk.
Proceed with Lab V1 Lite
- Creates useful evidence immediately.
- Keeps production and lab risk separated.
- Prepares the future full lab without spending on compute yet.
- Does not prove AD or Windows workstation behavior until compute is selected.
Reasoning
The project should keep momentum without pretending the full Windows lab exists. A lightweight milestone lets ABD Labs publish accurate architecture decisions, improve scripts and prepare runbooks while preserving the hard boundary around hypervisors, Windows VMs and public management services.
This decision changes the immediate next step, not the final architecture. The current public host remains the public and documentation layer. Full Windows Lab V1 still needs approved compute, private access, Windows evaluation/licensing, storage quota and snapshot policy before provisioning begins.