[VM Stage 8] Integrate VM isolation into Windows/Linux installation, guided setup, reconfiguration, and repair

[iteathen]

Parent: #107
Depends on: #108–#115
Coordinates with: #103

Goal

Make the VM-only repository execution boundary a first-class installation/configuration capability on both host families:

• Windows -> Hyper-V;
• Linux -> KVM/QEMU/libvirt.

By this stage the active host sandbox should already have been removed in Stage 1 and repository execution restored through VMs in Stage 6. Setup must never recreate direct-host repository execution when VM readiness is absent.

Setup should discover first, recommend safe defaults second, and prompt only for unresolved choices or explicit local consent.

Mandatory planning gate

Before changing code:

1. read AGENTS.md, DB-020, docs/vm-migration.md, docs/vm-lego-studs.md, Stage-1 sandbox-removal/no-provider evidence, all VM stages, Reduce setup/configuration burden with guided auto-discovery and confirmation #103, setup/bootstrap docs, doctor behavior, and transactional configuration rules;
2. inspect completed provider/image/environment/bridge implementation and enumerate what can be discovered, provisioned, repaired, or only diagnosed per platform;
3. map every setup action to the existing provider/image/environment/composition interface; setup-only raw Hyper-V/libvirt bypasses are architecture defects;
4. research Hyper-V feature/privilege/reboot behavior and Linux KVM/QEMU/libvirt package/service/group/socket/storage/network setup plus safe cleanup;
5. research base-image acquisition/provisioning, storage requirements, networking, and guest bootstrap prerequisites;
6. plan discovery, prompts, defaults, elevation/reboot/service handling, image acquisition, per-repo guest selection, resources, transactional config, repair/reset/migration, rollback, uninstall, noninteractive setup, and sandbox-era config migration;
7. apply Reduce setup/configuration burden with guided auto-discovery and confirmation #103's discover-first/suggest-second/prompt-only-when-needed rule.

Provider discovery

Windows:

• Hyper-V availability/enabled/usable state;
• management privilege/readiness;
• DevBridge image/environment inventory.

Linux:

• KVM acceleration usability;
• QEMU/libvirt package/service/provider readiness;
• selected system-provider access, normally qemu:///system where policy allows;
• DevBridge image/environment inventory.

Both:

• storage/free space;
• existing repo/provider/guest environments;
• image generations;
• bridge/bootstrap health;
• approved repositories and immutable repo IDs;
• configured guest profiles/resources;
• installed-but-unusable prerequisites.

Do not infer readiness from /dev/kvm, virsh, Hyper-V installation, or a VM/domain name alone.

Guided choices

Present a proposed configuration covering repositories, guest profiles, provider, image generations, storage implications, memory/vCPU/lifecycle defaults, prerequisites requiring elevation/reboot/package/service/group/session changes, and exact DevBridge-owned objects that will be created/changed/removed.

Do not silently create authority-bearing environments merely because capability was discovered.

Provisioning / repair / re-entry

Use the same provider/lifecycle studs used by runtime/doctor; do not duplicate raw provider management.

Support re-entry for:

• adding/removing repo environments;
• enabling/disabling guest profiles;
• image migration;
• degraded provider/bridge repair;
• reset/reseed;
• resource/storage policy changes;
• cleanup of obsolete owned images/environments;
• recovery after host/provider changes.

Temporary provider unavailability must degrade execution, not reactivate a host fallback or delete persistent configuration.

Sandbox-era configuration migration

Stage 1 removes the execution effect of sandbox-era configuration. Stage 8 owns the deliberate operator-facing migration/deprecation of remaining keys such as:

• workspace.externalReadRoots;
• execution.allowUncontainedTools;
• proposal/tool profile sandbox.* fields.

These keys must never be silently reinterpreted as permission for direct host repository execution. Migrate when semantics are unambiguous; otherwise emit an actionable error/reviewed change.

Non-interactive setup

Support declarative automation through the same validation/authority/provider interfaces. It must not bypass repository approval, image/provider/environment identity, host path ownership, or prerequisites.

Uninstall / cleanup

Distinguish DevBridge state, repo writable layers, immutable images, DevBridge-owned Hyper-V/libvirt objects, and operator/system virtualization infrastructure.

Do not casually disable Hyper-V, remove KVM/libvirt packages, stop shared services, or delete operator-owned provider objects.

Acceptance criteria

• Fresh Windows setup discovers Hyper-V/image readiness before platform questions.
• Fresh Linux setup discovers KVM/QEMU/libvirt/image readiness first.
• Setup uses the same provider-neutral capability/health/lifecycle studs as runtime/doctor.
• Setup derives approved repo identity from GitHub discovery rather than arbitrary local paths.
• Operator can select per-repo guest profiles and safe image/resource/storage defaults.
• Elevation/reboot/package/service/group/session requirements are precise and recoverable.
• Provisioning is transactional/recoverable and touches only owned artifacts.
• Setup validates bridge/bootstrap/tool readiness before reporting repository execution usable.
• Reconfiguration supports add/remove/reset/reseed/migrate without reinstall.
• Provider/image/VM unavailability is degraded/fail-closed, never direct-host fallback.
• doctor remains diagnostic; authority-changing operations belong to explicit setup/lifecycle actions.
• Sanitized config export/import does not transfer secrets or blindly trusted host/image state.
• Noninteractive setup obeys the same authority rules.
• Sandbox-era config is deliberately migrated/deprecated and cannot reactivate host repository execution.
• Generic setup/controller code contains no raw Hyper-V/libvirt command/path special cases outside adapters.
• Uninstall preserves operator-owned virtualization infrastructure.
• Reduce setup/configuration burden with guided auto-discovery and confirmation #103 remains compatible with the VM-only architecture.

[iteathen]

Fast-track multi-repository qualification update (durable notes: commit 9c5c13f on codex/temp-fast-functional):

• Auth-token repository visibility must remain observation only. Setup should preview bounded discovered repositories, then separately provision/admit each immutable repository ID; it must not derive trusted actors, execution, VM, or publication authority.
• Route setup needs idempotent append/remove/reconfigure with exact policy CAS/reconciliation and recovery when VM creation succeeds but route admission or health verification does not.
• A real second environment for UCI Arena (repository ID 1297121161) proved isolated routing and 4/4 repository tests. It also exposed that the disposable image clones one SSH host identity across environments; production needs unique environment-bound key generation and authenticated enrollment.
• Multi-repository setup/status needs per-repository progress and failure reporting while sharing the account-wide GitHub rate budget and preserving one-effective-task admission.
• Reconfiguration should include provider-aware VM resource/idle policy without assuming Hyper-V and libvirt expose identical controls.

The executable fast-track implementation remains an uncommitted local candidate; this comment records problems and acceptance direction, not production readiness.

[iteathen]

Stage 8 setup correction: #138 supersedes per-repository VM provisioning. Setup must separate repository approval from execution-profile provisioning. Selecting repositories (including all) means register/approve repositories only. VM creation/start belongs to demand-driven material execution profiles such as windows, linux, windows+cuda, or linux+cuda. Setup should map repositories to compatible profiles, summarize repository count separately from profile count/resource implications, and preflight resources before explicit profile creation/resizing. Existing repo-owned VMs require a recoverable workspace migration/retirement path.

[iteathen]

Temp Fast setup/install/repair evidence addendum

Canonical findings index: #141. This comment promotes the concrete operator/setup lessons from the disposable fast-track branch into the production Stage-8 backlog. Do not port the fast implementation wholesale.

Hyper-V readiness and elevation

Setup must distinguish at least:

1. feature/service present;
2. ordinary provider management usable by the configured operator/runtime identity;
3. host-network mutation requiring elevated administrator authority;
4. image/profile/bootstrap readiness;
5. repository-code execution readiness.

Observed reality: membership/session changes were needed before routine Hyper-V management worked, while New-NetIPAddress / New-NetNat still required a separately elevated token.

Required UX/recovery:

• discover first and explain the exact missing capability;
• least-privilege group/account change only with explicit consent;
• durable checkpoint before sign-out/reboot/session refresh;
• resume setup after re-entry and re-observe capability;
• bounded elevated helper receives only a locally derived digest-bound provider-foundation mutation;
• never elevate daemon/repository/controller arbitrary execution;
• persist planned/result/reconcile evidence and verify exact owned switch/gateway/NAT afterward.

Foreign virtualization state

The test host contained non-DevBridge VMs/switches/disks. Setup/uninstall must classify owned / adopted-with-provenance / foreign and never infer ownership from a name or existence. Do not disable/remove shared Hyper-V infrastructure during uninstall merely because DevBridge used it.

Image acquisition and unattended media

Fast-track experiments proved that provider-compatible images need source-specific handling:

• Azure VHD != automatically valid on-prem Hyper-V base image;
• ordinary Ubuntu cloud QCOW != directly a VHDX base;
• NoCloud seed did not create a no-prompt install unless boot media requested autoinstall;
• installer-time commands and first-boot user/tool ownership have different lifecycle semantics.

Production setup needs:

• source-specific acquire/build/import adapters;
• checksum/signature/provenance and license/consent where applicable;
• owned/checksumable unattended seed/media construction;
• seed schema validation;
• explicit installer vs first-boot bootstrap phases;
• restartable acquisition/build/generalize/publish/profile-provision progress;
• immutable image generation identity;
• no extension-based compatibility guessing;
• clean qualification on more than the original lab machine.

Networking UX

WinNAT/internal-switch behavior and NAT conflicts are real setup concerns. Setup should:

• preflight existing route/switch/NAT state without claiming it;
• choose/offer a non-conflicting owned network plan;
• use unsigned-safe address/prefix calculations;
• verify guest DNS + HTTPS, not only interface state;
• present actionable bounded provider errors rather than PowerShell progress/CLIXML noise;
• never silently choose the Hyper-V Default Switch just because Temp Fast used it as a disposable workaround.

SSH / guest first-trust enrollment

Fresh cloned targets need unique host identity and an explicit trust path. Setup/reseed/migration must:

• regenerate unique SSH host identity after clone;
• enroll/bind the exact observed key to the exact owned profile instance;
• reject blind keyscan/shared cloned host private keys as production authority;
• make host-key change/reset/reseed an explicit reconcile/re-enrollment event.

Repository discovery is not profile provisioning

Per #138:

• selecting all repositories means approve/register the repositories, not create/start one VM each;
• summarize repository count separately from execution-profile count/resource cost;
• provision profiles only when compatible capability demand requires them;
• resource-preflight memory/storage before profile creation/start;
• migrate old repository-owned environments conservatively and retire only exact obsolete owned artifacts after replacement is proven.

Setup input and authority UX found by live retry

Production setup should include the exact usability/security corrections exposed by the trial:

• accept natural whitespace and comma-separated selections plus all/none semantics;
• recover from a bad repository/actor/environment selection in-place rather than aborting the entire setup session;
• expose authenticated self explicitly;
• positively resolve custom repositories/logins/actor IDs through authenticated GitHub;
• reject canonical subject/ID mismatch;
• display immutable repository IDs / actor IDs when committing authority;
• require a final exact confirmation before persisting newly granted repository/task-author authority;
• token/account visibility is discovery only and never grants queue, task-author, execution, profile, or publication authority.

Versioned setup/bootstrap re-entry

The fast track exposed an update/setup deadlock where an older managed runtime may be unable to invoke the updater that fixes it, plus incomplete setup markers that could re-trigger authority prompts.

Production requirements:

• versioned stage-0 compatibility transition before depending on newer runtime protocol;
• durable setup protocol/state separate from ordinary daemon operation;
• normal commands never silently re-enter setup;
• explicit setup/repair/reconfigure path resumes interrupted steps;
• transaction/reentry points around fetch, elevation, reboot, image build, profile creation, identity enrollment, validation, and activation;
• custom DevBridge home rewrites canonical default state/workspace roots instead of copying defaults pointing elsewhere;
• headless start; foreground daemon only when explicit; bounded logs/status/repair UX;
• coordinate installation-wide supervisor ownership and activation with Harden installation-wide supervisor ownership and candidate activation coordination #144.

Uninstall / cleanup

Use a durable versioned ownership manifest. Track created/adopted/foreign provenance and distinguish:

• app-only uninstall;
• configuration reset;
• profile/workspace/image removal;
• full exact purge.

Requirements include:

• explicit destructive confirmation;
• exact re-observation before delete;
• referenced-image protection;
• interrupted uninstall reconciliation;
• Windows/OneDrive/sharing locks reported separately from Git metadata cleanup;
• non-recursive parent pruning only when the exact parent is empty after owned child removal;
• final removed/preserved report.

#141 contains the complete Temp Fast inventory; #142, #143, and #144 own the newly separated data-path, scratch, and supervisor boundaries.

[iteathen]

#138 production contract update (implemented in PR #145): Stage 8 setup/reconfiguration must treat the execution profile as the persistent VM ownership/provisioning unit and the repository/profile pair as the isolated workspace unit. Selecting multiple repositories that use the same profile must ensure/reuse one physical environment for that profile, then create/repair separate workspace routes inside it. Do not provision or count one VM per repository. Resource policy (memory/vCPU/storage/lifecycle) is profile-scoped; reset/reseed/cleanup remains workspace-scoped unless the operator explicitly destroys the whole profile environment. Legacy repository-owned VM state must be surfaced for deliberate migration rather than silently adopted.

[iteathen]

Application-management hierarchy coordination

Issue #180 formalizes setup's position in the complete application stack:

Permanent Entry -> Runner / Bootstrap Manager -> Accepted Runtime -> Services -> Declared Execution Environments

For #116, setup/re-entry remains owned by the accepted runtime. The permanent entry and runner only establish working DevBridge application software; they must not grow a second configuration/provider/setup system.

#180 adds two explicit setup acceptance cases:

1. Configured recovery: when installation identity/operator authority survive but runtime/VM/image materialization is gone, runtime reconstruction must preserve that authority and continue into the normal environment lifecycle.
2. True fresh host / authority loss: application software may be reconstructed automatically, but DevBridge must stop at guided setup/re-entry rather than infer repositories, trusted actors, provider ownership, destructive policy, or credentials.

Uninstall and full purge should also remain distinct: executable/runtime removal must not silently equal destruction of durable operator authority or declared environment state.

[iteathen]

Fresh-host installation plan correction — coordinate #192

Stage 8 must now treat #192 as part of its acceptance boundary.

A normal installation starts with no assumed provider, source media, base image, Windows license/activation method, artifact repository, GitHub Release permission, or durable local image cache. Setup must discover those facts read-only and establish missing authority through re-enterable local setup.

For Windows, Stage 8 must keep four things separate: image-construction source/recipe authority; prepared-image distribution/storage authority; per-materialized-VM activation authority; and the execution-profile declaration. Product keys/MAK/KMS/AD/subscription secrets do not belong in the generalized base image or normal config.

The default GitHub artifact source, when selected, must be user-derived/private (for example <authenticated-owner>/devbridge-base-images) rather than hard-coded to a developer account. Prepared Windows bytes may be published only when applicable distribution rights are locally confirmed; otherwise setup must preserve a deterministic local-reconstruction recovery path from approved Microsoft source media.

Stage 8 acceptance therefore includes: Linux-only setup not blocked by Windows questions; add-Windows-later re-entry; source/licensing/artifact-policy discovery; protected activation-authority configuration; real image construction/qualification; #178 packaging/reacquisition; post-materialization Windows activation; and rebuild reactivation/reconciliation after disk loss.

See docs/fresh-host-image-provisioning.md on the planning branch and #192.

[iteathen]

Development-environment coordination update: Stage 8 should preserve a clean split between DevBridge setup authority and ordinary persistent-guest self-preparation. Setup/re-entry owns provider/image/profile declarations, prepared capabilities, credentials, protection boundaries, and other authority-bearing prerequisites. It should not grow per-tool installation workflows for normal guest software. After an exact guest is admitted, #214 is the generic console path for agents to install/configure long-tail CLI tooling with ordinary ecosystem mechanisms; #215 owns generic user-defined observation packaging. Setup/doctor may report important guest readiness/degradation, but discovery of an arbitrary guest package must not imply that DevBridge needs to register/approve that package individually. GUI software is allowed; reliable arbitrary GUI interaction remains a documented limitation only.

[iteathen]

Setup UX contract update from #103/#192:

Stage 8 should no longer assume a guided questionnaire as the normal first-run UX. The default target is one trusted bootstrap/setup command from a blank supported machine, using reasonable safe defaults and stopping only at genuine non-defaultable boundaries.

Stage-8 acceptance should therefore include:

• no pre-authored DevBridge config required for normal install;
• ordinary Linux/Ubuntu profile selected by default unless explicitly overridden or invalid;
• authenticated GitHub repo discovery with <=30 eligible repos auto-selected, 31+ requiring repository selection, never silent truncation;
• initial local setup options may carry bounded consent for routine provider/execution changes, while provider/image/readiness checks remain mandatory;
• internal image/canary/keyring/snapshot/package/payload/provider details remain behind setup composition;
• successful setup installs a stable devbridge command on persistent PATH without clobbering an unrelated executable and verifies resolution;
• successful setup ends with a welcome/operator handoff showing readiness and devbridge, devbridge status, devbridge doctor, and devbridge setup next steps;
• interactive prompts remain fallback behavior for unresolved auth/elevation/reboot/licensing/resource/ownership decisions, not the default installation mode.

Normative docs are being updated on fix/197-one-command-setup in docs/setup.md and docs/fresh-host-image-provisioning.md.

[iteathen]

DB-HO005 least-privilege Hyper-V network research update. The physical host confirms the split already recorded by Temp Fast: the ordinary account is enabled in BUILTIN Hyper-V Administrators and can manage Hyper-V objects, but its medium-integrity token cannot run New-NetIPAddress/New-NetNat. Microsoft documents that an internal-switch WinNAT setup starts from Administrator PowerShell and that Windows supports only one internal NAT prefix per host: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/setup-nat-network . The host already has one older DevBridge-marked NAT (192.168.175.0/24) whose durable owner is not present in the current state root; the current foundation has a separate planned switch/prefix (192.168.160.0/24). It is unsafe to create a second NAT, silently adopt the old one, or remove it by name. The Hyper-V Default Switch is a viable explicitly selected Windows-client topology with Windows-managed NAT/DHCP, but the Microsoft Hyper-V team describes it as non-customizable and best for convenient laptop networking, while the Temp Fast record explicitly classifies it as a disposable workaround rather than production owned-network readiness: https://techcommunity.microsoft.com/t5/virtualization/what-s-new-in-hyper-v-for-windows-10-fall-creators-update/bc-p/2267078 . Windows Sudo does not eliminate privilege: Microsoft says every use still elevates through UAC, and it is disabled on this host: https://learn.microsoft.com/en-us/windows/advanced-settings/sudo/ . JEA can delegate narrowly constrained administrative functions through temporary privileged virtual accounts, but adds a persistent remoting endpoint and role-merging/ACL surface: https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/overview and https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/security-considerations . Recommended current production direction remains the already-proven bounded setup repair from the historical fast branch: local double consent; one digest/foundation-bound request; fixed hidden helper; only the neutral environment-foundation network action; credential stripping; durable intent/result/reconciliation; ordinary-process exact re-observation. Do not elevate the complete accepted runtime. PR #272 remains a safe temporary fail-closed stop but its whole-shell guidance is not the final least-privilege UX. A current port must also reject the one-WinNAT conflict before any switch/gateway mutation and require deliberate owned-state migration or an explicitly authorized alternate topology.

[iteathen]

DB-HO005 follow-up: #197 construction and persistent Stage-2 networking should not be conflated. The disposable Ubuntu image-builder can likely avoid host elevation entirely by using the read-only verified Windows-managed Default Switch, Ubuntu DHCP, exact owned-VM binding, Hyper-V KVP address discovery, and the already pinned SSH host key. This would not mutate or claim ownership of the Default Switch and would not advertise it as persistent execution-network readiness.

The full evidence/options/licensing split is recorded on #197: #197 (comment)

#116 still owns the persistent environment-network decision. Its current custom internal switch requires host gateway/WinNAT mutation, Microsoft limits WinNAT to one internal prefix per host, and the live host's one existing older DevBridge-marked NAT lacks current durable ownership evidence. Any #116 solution must therefore either use the reviewed digest-bound elevated repair plus deliberate old-state migration, or introduce an explicitly selected alternate persistent topology with its own readiness/ownership contract. The #197 construction-only use of the Default Switch must not silently settle that broader decision.

[iteathen]

Additional DB-HO005 least-privilege network research (2026-08-24): there are supported alternatives to requiring every operator invocation to be elevated, but none makes host NAT part of a packaged VHDX. (1) An administrator can pre-provision an external Hyper-V switch once; later VM attachment can use existing Hyper-V operator authority and guest DHCP from the physical LAN, but switch creation/configuration still requires administrative rights and inherits LAN/VLAN/DHCP/exposure policy. Microsoft reference: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/create-a-virtual-switch-for-hyper-v-virtual-machines . (2) DevBridge could install a narrow privileged Windows service or JEA endpoint once and let a non-admin client request only registered networking operations. Microsoft confirms service creation requires Administrator SCM authority and warns that service configuration rights are security-critical; JEA can delegate bounded administrative commands through virtual accounts. References: https://learn.microsoft.com/en-us/windows/win32/services/service-security-and-access-rights and https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/security-considerations . This is a real future architecture, but it requires authenticated local IPC, exact operation schemas, ACLs, audit/reconciliation, upgrade identity, and fail-closed ownership; it is not a shortcut inside #197. (3) Hyper-V sockets avoid IP networking, but require a registered host service plus a compatible guest client/kernel and provide only a data stream, so general installer/package connectivity would need a new proxy/bootstrap design: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/make-integration-service . (4) Fully offline package media avoids host networking but needs signed archive-index/dependency-closure/package admission and local repository media, plus component-license review. Current conclusion: exact read-only use of the Windows-managed construction switch remains the smallest #197-only boundary. A pre-provisioned external switch and an installed privileged broker should remain explicit #116 design candidates; neither is portable disk state.

[iteathen]

Stage-8 profile-selection checkpoint is pushed at exact commit 6e4abb67ad0a71faee2dac570d49279378770331 on stage8/362-protected-activity-channel.

Implemented:

• bounded local --profiles <linux|windows|both|none|defer> setup choice;
• default Linux selection only when no accepted selection exists;
• accepted-selection preservation and component-owned interrupted-transaction recovery;
• explicit refusal to absorb another setup component's working transaction;
• defer with no selection-authority write and none as an accepted empty selection;
• Windows media/read-only construction observation only when Windows is selected;
• Ubuntu prerequisite/authority/construction attachment only when Linux is selected;
• cross-profile construction/media rejection before platform adapters run;
• Windows-only fail-closed behavior instead of Linux activation fallback;
• path-free, operation-id-free local status projection;
• durable assessment/research/plan/implementation record in docs/testing/DB-HO048-issue-116-profile-selection.md and operator contract in docs/setup.md.

Verification on the exact candidate:

• focused selection/setup/CLI/architecture tests: 69 passed, 0 failed;
• repository preflight: 112 syntax files, 2 JSON files, 105 targeted test files passed;
• complete suite: 1,590 total, 1,575 passed, 15 expected platform skips, 0 failed.

This was entirely non-elevated: no provider, VM, image, lifecycle, guest, or UAC effect was invoked. The issue remains open. Guided provider establishment, Windows construction/activation, Linux protected lifecycle completion, reconfiguration/repair/uninstall, and real Hyper-V plus KVM/libvirt qualification are not claimed by this checkpoint.

[iteathen]

Stage-8 setup integration advanced at exact pushed commit eed880c on stage8/362-protected-activity-channel. The accepted profile selection now controls one serialized construction authority: Windows-only and combined selections are supported, combined construction is deterministically Linux then Windows, one invocation advances at most one durable frontier, and plain setup calls observation ports only. Empty/deferred selections and unavailable or malformed observations fail closed with no host fallback. Verification: focused 79/79; repository preflight 113 syntax files, 2 JSON files, 106 targeted test files; complete suite 1,598 total / 1,583 passed / 15 expected platform skips / 0 failures. No elevation or physical provider action was performed. Issue remains open for the remaining guided setup, protected activation, real-provider qualification, and both-guest C acceptance criteria.

[iteathen]

Checkpoint 835940532bbe58dce16884b57a6548ce9a1dfe97 is pushed on stage8/362-protected-activity-channel.

This completes the non-elevated selected-profile declaration/activation composition slice:

• the accepted configuration publisher now consumes injected neutral profile sources and no longer owns Ubuntu-specific policy;
• isolated Ubuntu and Windows source owners bind exact image/bootstrap authority;
• Windows construction and declaration publication share one production-output identity;
• Windows-only setup can continue from an exact complete image through the existing protected lifecycle/activation studs without touching Ubuntu authority;
• combined activation is serialized in accepted order, returns after one changed environment, and never skips an earlier blocker;
• configuration must cover every accepted profile before lifecycle work or operational enablement;
• public readiness language is profile-neutral.

Evidence: focused owner/boundary suite 55/55; repository preflight 118 syntax + 2 JSON + 109 targeted files; complete suite 1,614 total / 1,599 passed / 15 expected platform skips / 0 failed; git diff --check passed. Durable assessment/research/plan/implementation evidence is in docs/testing/DB-HO050-issue-116-selected-profile-environment-activation.md.

No installed setup, UAC request, provider mutation, VM operation, media approval, or guest execution was performed. The operator has prohibited UAC/elevation for the next three days. Keep this issue open: real protected Hyper-V activation, exact Windows/Linux environment materialization, and both-guest C acceptance remain pending.