Skip to main content

AptDiskwright Overview

AptDiskwright is a Windows 11 disk-planning and GPT/UEFI migration desktop application built around one operating rule, stated directly in its own AGENTS.md: "plan first, execute second, record everything."

:::danger Physical-disk mutation is intentionally disabled Live migration and any physical-disk mutation are switched off until disposable-VHD and bootable-VM qualification is complete. This isn't a missing feature — it's a deliberate safety gate the project has not yet cleared, and the codebase enforces it rather than just documenting it. :::

Who it's for​

An operator who needs to plan disk repartitioning or GPT/UEFI migrations with real evidence trails — not a general consumer partitioning tool. The safety posture (stale-inventory rejection, mandatory validation, evidence-first design) assumes someone who wants to prove a migration was planned correctly before it touches a physical disk.

The core concept​

The architecture is split cleanly along a trust boundary:

AptDiskwright.vbproj (WPF client)   <-- unelevated, never runs as admin
        │
        │  authenticated named-pipe protocol (AptDiskwright.Engine.v1,
        │  length-prefixed UTF-8 JSON)
        ▼
engine/ (C++ Windows service)        <-- privileged, demand-start, the only
                                          component allowed to touch storage

The client can never destructively act on a disk on its own — every privileged operation has to cross the named-pipe boundary into the engine, and the engine is the one component qualified (eventually) to run destructive operations.

The planning workflow itself is: capture a live disk inventory → author an operation plan with a dependency-ordered transaction queue → validate the plan (stale inventory, dependency cycles, and drive-letter conflicts are all blocking findings) → freeze the plan by binding it to a SHA-256 manifest → only then hand execution to the engine.

Why this shape​

Disk migration tooling is exactly the kind of software where "it mostly works" isn't good enough — a wrong write to the wrong disk is unrecoverable. Splitting the unelevated planner from the privileged engine, requiring a frozen SHA-256-bound plan before any execution, and refusing to identify a destructive target by drive letter alone (drive letters can be reassigned between inventory capture and execution) are all safeguards against exactly the class of mistake that makes disk tools dangerous.