# Project Charter — MN103S Optical-Drive IDE Recovery Programmer

**Project ID:** `PFES-PROJ-MN103S-RECOVERY-001`  
**Lifecycle state:** Incubating  
**Current design revision:** Rev B0  
**Repository state:** Deferred; not repository-ready

## Mission

Create a deterministic USB-controlled PATA/ATAPI host and recovery platform for
MN103S-powered optical drives. The device is intended to support diagnosis,
firmware acquisition, controlled recovery development, and later validated
programming workflows without relying on the target drive's ordinary host
system.

## Project Frankenstein relationship

The device supports:

- firmware acquisition and recovery;
- hardware validation of analyzer findings;
- controlled testing of flash and boot behavior;
- preservation of otherwise inaccessible or bricked MN103S optical drives;
- future comparison of logical firmware images with physical flash contents.

## Current hardware concept

- removable FANKE FK723M1-ZGT6 STM32H723 module;
- one keyed 40-pin PATA optical-drive connection;
- protected, direction-controlled dual-supply level translation;
- PIO-only initial operation;
- switched optical-drive LP4 power with manual and MCU control;
- SWD, UART, logic-analyzer headers, and test points;
- physical `RECOVERY_ARM` authorization input;
- bus outputs disabled by hardware defaults while the MCU is absent, reset,
  unpowered, halted, or not intentionally controlling the interface.

## Included scope

- standard ATA task-file and ATAPI packet access;
- read-only first-article bring-up;
- deterministic drive reset and cold-power cycling;
- voltage-presence monitoring;
- later controlled recovery and flash research after separate validation.

## Non-goals for the current revision

- DMA or UDMA;
- a generic USB mass-storage bridge;
- a second IDE device;
- a slim/JAE connector on the base board;
- onboard ST-LINK;
- USB-powered optical-drive operation;
- precision current telemetry;
- any present claim of safe automatic erase/program capability.

## Current maturity

The editable KiCad 9 schematic is complete for PCB-layout handoff. Rev B0 is not
a fabrication release. Mechanical spacing, preliminary footprints, ERC, PCB
layout, DRC, drive-current margin, unpowered-drive back-power behavior, and
first-article operation remain open.

## Safety boundary

Initial hardware and firmware validation must stop after standard read-only
ATA/ATAPI operation. Flash erase/program payloads remain prohibited until a
separate destructive-operation gate is reviewed and accepted.

## Repository decision

A dedicated repository is justified in principle but premature now. The design
still lacks a stable PCB layout, verified mechanical footprint set, clean ERC/
DRC baseline, first-article evidence, firmware source structure, and established
release boundary. PFES preserves the project and its artifact lineage during
incubation.

## Repository-readiness triggers

Re-evaluate repository admission after:

1. the KiCad project opens cleanly and ERC is reviewed;
2. module spacing and orderable connector footprints are physically verified;
3. PCB layout and DRC are complete;
4. BOM and selected parts are stable enough for first article;
5. a read-only bring-up and validation plan exists;
6. firmware, host utility, hardware, generated outputs, and manufacturing files
   have a coherent source-tree boundary;
7. an initial README and reproducible validation baseline accurately describe
   the project.
