# Recovery 3001 0.4.0 Beta 1

## Target

Recovery Core 0.4.0 and Windows 0.4.0 Beta 1 are the active target.
Android remains an archived USB alpha until product direction is decided.

Beta 1 is a test release, not a signed commercial GA release.

## Weighted acceptance areas

| Area | Weight | Acceptance summary |
|---|---:|---|
| Source safety | 12% | No source write path; system and same-physical-disk blocks pass |
| Imaging | 12% | Deterministic image, resume, SHA-256, and accurate error map |
| Filesystem scan | 13% | FAT32/exFAT clean-delete candidate discovery at least 99% |
| Type and confidence | 13% | Signature tests pass; extension conflicts never receive high confidence |
| Recovery | 13% | No overwrite; clean supported corpus is SHA-256 exact |
| Windows UX | 12% | Six-step guided flow and actionable errors |
| QA evidence | 15% | 1,000-file manifest and multi-condition regression evidence |
| Release | 10% | Immutable version archive, hashes, notes, Range download, rollback |

Implementation alone earns at most half of a milestone. A milestone reaches
100% only after the required runtime or hardware evidence is attached.

## Dev 1

The first 0.4.0 increment adds content-aware candidate assessment:

- JPEG, PNG, GIF, PDF, ZIP/Office, MP4/MOV, AVI, WAV, WebP, DWG, and OLE
  signature detection;
- independent extension and content comparison;
- 0–100 confidence score based on retained FAT chain or contiguous inference;
- high, medium, and low confidence with Korean evidence notes;
- Windows table and search support for detected type and confidence.

Dev 1 must not be described as Beta 1 complete until the 1,000-file regression,
multi-device tests, code signing, and public release gates are complete.

## Dev 2

The second increment adds the reproducible real-device regression gate and
extends extension-aware confidence scoring for the field corpus:

- full 1,000-file manifest-to-candidate-to-recovered-file traceability;
- original path, original name, size, SHA-256, detected kind, confidence, and
  evidence notes exported for every file;
- hard pass gates for candidate count, batch recovery, size, SHA-256, extra
  outputs, signature conflicts, and confidence field validity;
- HWP/HWPX, macro-enabled Office, M4A, and additional OpenXML container
  extension mappings.

Dev 2 still remains a development build until the six-step Windows UX,
additional physical USB coverage, and signed Beta 1 package gates are complete.

## Dev 3

The third increment adds the guided Windows product flow and verifiable result
reporting:

- explicit six-step state gates from safety notice through result verification;
- explicit source selection with no automatic device choice;
- step-specific screens, keyboard actions, low-resolution scrolling, and
  cause-impact-next-action error guidance;
- per-output SHA-256 and candidate-size checks;
- non-overwriting HTML and JSON reports with candidate evidence and failures;
- a clear distinction between output-hash stability and equality to an unknown
  pre-deletion source.

Dev 3 passes 40 Rust tests, Clippy with zero warnings, Windows Release builds,
the expected behavior of all eight synthetic/real matrix environments, and a
fresh 1,000-file SanDisk regression. Internal start, source, image, and result
screens were rendered at the available 1024 x 720 viewport.

Dev 3 still remains a development build until actual Windows 10 and 150% scale
coverage, an unsupervised five-user study, additional physical USB and real
exFAT coverage, and Windows code signing are complete.

## Dev 4

The fourth increment hardens exFAT structure validation and recovery:

- validates both exFAT main and backup boot-region checksums;
- uses the validated backup boot region when the main checksum is invalid and
  rejects the image when both regions are invalid;
- follows a complete preserved exFAT FAT chain so fragmented deleted files are
  not incorrectly recovered as contiguous extents;
- keeps NoFatChain and cleared/incomplete FAT-chain recovery explicitly marked
  as contiguous inference;
- adds a standard exfatprogs filesystem corpus built from the same 1,000 public
  field-file manifest used by the FAT32 regression.

The exfatprogs corpus contains 1,000 files and 10,427,498,573 source bytes in a
15,032,385,536-byte exFAT image. Every file is verified before deletion, the
filesystem is checked clean after deletion, and the image is mounted read-only
for scan and recovery. This closes the real-data exFAT image gate but is not a
substitute for testing a separately provisioned physical exFAT USB device.

Dev 4 remains a development build until physical exFAT and additional USB
models, Windows 10 and 150% scale coverage, the unsupervised five-user study,
and Windows code signing are complete.

## Dev 5

The fifth increment makes the Windows six-step layout gate repeatable:

- generates a complete AccessKit tree for every workflow step in a headless
  egui frame;
- requires all seven critical actions to be enabled and wholly inside the
  logical viewport;
- covers 1280 x 720 at 100%, 1920 x 1080 at 150%, and the more constrained
  1280 x 720 at 150%;
- captures native Windows screenshots for welcome, source, image, and result
  states and records the OS, work area, applied DPI, executable hash, and
  Authenticode state;
- produces JSON, Markdown, logs, screenshots, and an evidence checksum file
  through one versioned PowerShell command.

Dev 5 closes the automated resolution and 150% layout gate. It does not replace
an actual Windows 10 run, the unsupervised five-user usability study, physical
exFAT and additional USB coverage, or Windows code signing.
