# Appendix D — Current Engineering State

**State date:** 2026-07-16  
**Canonical machine-readable source:** `PFES_CURRENT_STATE.json`

## Strategic objective

Develop validated methods for understanding, reproducing, emulating,
preserving, modifying, recovering, and extending optical-drive firmware and
media systems.

## Current focus and boundary

- Panasonic MN103S-based HLDS firmware;
- original Xbox optical-drive authentication and media acquisition;
- firmware compatibility and capability transplantation;
- topology-guided reverse engineering and behavioral emulation;
- evidence-first hardware validation and provenance;
- development of controlled recovery hardware for MN103S optical drives.

GDR-8050L remains the canonical capability donor. GDR-8081N board evidence
identifies `HD62602AFD1`; it remains outside the MN103S-focused effort unless a
separate architecture project is admitted.

## Canonical repository state

| Repository | Role | Current maintained boundary |
|---|---|---|
| `pfes` | specification/evidence/decisions | cumulative PFES release history and current state |
| `xbox-dvd-tools` | analyzer and host tools | 126-path maintained source tree |
| `mn103s-emulator` | CPU execution and GDR bridge | 51-path maintained tree; full v258 import preserved |
| `friidump` | dumping application and drive profiles | 97-path canonical source tree |

All four repositories are active authorities. Same-disk bundles are recovery
aids, not backups.

## Project incubation state

PFES-ENG-045 and PFES-TR-010 now define project admission and repository
readiness. The MN103S Optical-Drive IDE Recovery Programmer is admitted at Rev
B0 as `incubating`. It has no canonical repository yet.

The schematic is complete for PCB-layout handoff, not fabrication release.
Mechanical verification, ERC, layout/DRC, first article, read-only operation,
and destructive-operation authorization remain separate open gates.

## Analyzer state

The staged chain and current evidence contracts are established. Stage5B can
exceed 100 minutes, so source/report validation must precede reruns. The main
refinement target remains indirect/table-driven command resolution; absence of
a direct `0xAD` compare does not prove absence of READ DVD STRUCTURE handling.

## Emulator state

- v206: known-good live stateful iSCSI behavior reference;
- v258: complete historical workspace baseline;
- maintained `main`: cleaned runtime/proof boundary;
- READ(10) host-LBA ingestion and phase-4 descriptor handoff proven;
- `single_call_stack_proof=false`;
- `firmware_derived_delta=false`;
- v259 continues in the separate emulator workstream.

## Media and host-tool state

FriiDump has validated GC/Wii and selected Xbox workflows on supported hardware.
The XGD1 option-1 reconstruction is structurally validated but not
Redump-identical. Xbox `CD_READY` indicates media presence/readiness independently
of authentication state.

## Operational constraints

- Ghidra is unavailable; use objdump, custom scripts, and project tooling.
- Firmware, media, and evolving incubation packages do not automatically belong
  in source repositories.
- Preserve provenance-distinct payloads and ranking rows even when hashes match.
- Use stable canonical filenames in installable update packages.
- Use `-LiteralPath` for PowerShell paths containing brackets.
- Keep at least 15% of the project filesystem free.
