Make the creation plan say what the run will actually do

[ALERTua]

Closes #101.

Both mismatches were seen in a live run creating a Dev Drive in a .vhdx with deduplication declined. AGENTS.md says the plan summary must say what will actually happen on this machine; in that run it did neither of these.

The plan promised work that was skipped

The run answered "Neither" at the deduplication question. The plan said:

* Skip deduplication and compression setup
* Mark Dev Drive as trusted for Windows Defender performance
* Run initial optimization job to prepare the drive

and the run ended:

Skipping deduplication as requested.
All done. Dev Drive F: ready.

An optimization job is a deduplication job — the work sits inside the block that declining deduplication skips — but the line promising it was added outside that branch, so it printed whatever the user chose. It is inside the branch now.

The plan listed one step in the wrong place

Marking the drive trusted was listed second to last, after deduplication. The run applies it straight after formatting, before BitLocker:

Formatting the newly created partition drive F: to a Dev Drive
Dev Drive created at F:, named DevDrive.
Marking Dev Drive F: as trusted for Defender performance
...
BitLocker setup for F:

Read before deciding whether to proceed, that told the reader the trusted designation came after the longest and most failure-prone step in the run, when it comes before it. The line moved to where the work is.

The test that made both invisible

One assertion covered them, and it asserted their presence and nothing else:

It 'ends every mode with the two steps that always run' {

Its title was itself the falsehood — the optimization job is not one of the steps that always run. It is replaced by four assertions about position:

• where the trusted line sits relative to the name and the BitLocker lines, in every mode
• the order the body carries the steps out in, taken from the syntax tree: the Format-Volume call, then the fsutil call, then the BitLocker heading. Comparing the plan against a literal list is what let the two drift apart, so this compares it against the body instead
• the optimization line present with deduplication and absent without it
• that line sitting inside the guard's else body by syntax-tree containment, not by proximity

The fsutil anchor is found as a CommandAst, not by text: two pieces of retry advice quote the same command line earlier in the file, and a text match found one of those first.

Proved to have teeth

Each assertion was checked by reintroducing on a scratch copy the exact defect it exists to catch. The script was restored byte for byte.

real script                                          -> 766 passed, 0 failed
the trusted line goes back to the end of the plan     -> 1 failed
the optimization promise leaves the branch           -> 2 failed
the body marks the drive trusted somewhere else      -> 3 failed

Reviewed

An independent review of the commit raised one finding, applied: a two-line comment that said in two lines what one says. It also checked both relocated lines against the linear body and confirmed the new plan order matches the run step for step, and confirmed that the issue's aside about $RunInitialJob is not a gap — that flag is a hardcoded $true, never a user answer, so there is nothing for the plan to key to.

No change to what the run does. Only to what it says it will do.

🤖 Generated with Claude Code

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• dev_drive.ps1
• dev_drive.Tests.ps1

---

_{Reviewed by free · Input: 41.9K · Output: 13.6K · Cached: 384.4K}