fix(welcome): BitLocker PIN first-boot + recovery-key display + FlavourStep Next #14
Reference in New Issue
Block a user
Delete Branch "feat/wizard-recipes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Three wizard fixes from live e2e (the role app-recipes feature is not in this PR despite the branch name — it's still in design, pending the per-role app lists).
1. BitLocker PIN now works on the first boot. Dropped
-SkipHardwareTestfromEnable-BitLocker. With it, BitLocker sealed the key immediately against unvalidated PCRs → first post-enroll boot hitE_FVE_SECURE_BOOT_CHANGED/ PCR-11 mismatch and dropped to recovery every time. Without it, BitLocker runs its hardware test on the next reboot (the wizard's end-of-flow restart), validating the TPM+PIN unseal against the real boot config before encrypting — so the PIN works first time.2. The Done step now shows the BitLocker recovery key. Reads the 48-digit key the enrollment already saves (
C:\ProgramData\SilverMetal\bitlocker-recovery.txt) and displays it with a "write this down" warning. Previously it was never surfaced to the user — a lockout risk we hit directly on the VM.3. FlavourStep "Next" enables immediately. Selecting a role updated
State.Flavourbut didn't notify the wizard host, so Next stayed disabled until a back/forward re-render. Now it raisesOnSelected→ host re-evaluates (same pattern AccountStep uses).Verified: welcome solution builds, 29/29 tests pass.
Still tracked as follow-ups (not here): role → app recipes (winget vs curated mirror + per-role lists, pending operator input); escrow the recovery key to SilverSync.
🤖 Generated with Claude Code