ThePirateRay/docs/status/phase-0.md

# Phase 0 status — complete

Last updated: 2026-10-24

## Completed

- Both repositories use `main` and have pushed, reviewable histories.
- PrivateStash uses Git LFS and preserves `raw/**` without line-ending or text
  normalization.
- The existing installer-stick source was read without modifying Google Drive.
- Private evidence snapshot `b6edf29` contains 307 files totaling 79,386,307
  bytes; 135 new LFS objects were uploaded in that import.
- Private manifest commit `50e589c` contains 307 SHA-256 entries, 307 matching
  Drive-file provenance entries, and 29 folder provenance entries.
- Public configuration analysis is linked to nine sanitized evidence entries.
- A private 340-token deny-list checks known Drive and machine identifiers
  without storing those identifiers publicly.
- A fresh clone of both remotes passed `git fsck`; the private clone additionally
  passed `git lfs fsck` and reproduced the expected file and byte counts.
- The public test suite and leak guard pass against the fresh private deny-list.
- Passive Windows enumeration of the connected controller confirmed device
  description `USBLMCV4`, USB VID/PID `9588:9899`, vendor-specific class, and
  USB revision descriptor `0005`. No compatible function driver is installed
  on the development computer; no endpoint was opened.
- Four LightBurn exports are preserved privately with SHA-256 manifests and
  Git LFS. Their public evidence records contain no private source locators.
- All three bundle manifests identify LightBurn `2.1.03`.
- The JPT export confirms a `JCZFiber`/`LibUSB` device profile, 110 x 110 mm
  work area, enabled Q-pulse-width control, `QPulseWidth` cut-list fields and
  a require-frame-before-start setting.
- The Eduard export confirms a Ruida/Serial profile with a 1500 x 1000 mm work
  area. A separate 500 x 300 mm Ruida profile remains physically unassigned.
- No vendor executable, plugin, DLL, or driver was run. No USB capture, framing,
  machine command, or laser output was performed.
- The actual control machine was inspected with the laser physically
  disconnected. LightBurn Pro 2.1.03 showed the `100 JPT E2 MOPA` device,
  `Disconnected` status, the `Mopa-100W-110mm` library and explicit kHz/ns MOPA
  UI units. The live preferences and newest native backup were preserved and
  hashed; see the [control-machine observation](../research/lightburn-control-machine-observation-2026-10-24.md).
- All five tabs of the ordinary LightBurn Settings dialog were supplied as
  screenshots and preserved privately with SHA-256 records.
- All three tabs of the JPT Device Settings dialog were subsequently supplied
  and preserved privately. They confirm the 110 x 110 mm field, Q-pulse-width
  enablement, visible 1-4000 kHz range and require-frame-before-start setting.

## Deferred hardware-readiness evidence

These items are still useful before hardware work, but no longer block the
completed Phase 0 evidence baseline or the offline M1 product checkpoint:

- safe exterior hardware/label photographs and startup/interlock notes;
- stock-driver identity and version from the actual LightBurn control computer.

An About screenshot is useful corroboration, but the window title and imported
bundle manifests already establish version `2.1.03`. The closed-application
preferences archive and three operator-verified `.lbrn2` examples are complete.

Collect them directly into a dated directory under PrivateStash by following
the [LightBurn checklist](../collection/lightburn.md). Do not use Google Drive
as an intermediate project workspace and do not generate Support Data.

Collect them when preparing an approved M3 hardware session. Do not expand the
offline product scope merely to keep Phase 0 open.

## Offline M1 status

The Rayforge/MeerK40t reuse track has now produced public, transport-free
evidence for:

- deterministic MeerK40t BalorMK mock MOPA encoding, hatch planning and mock
  spooling;
- an external Rayforge no-device addon with profile import, fixed-size list
  buffering, safe state ordering, cancellation and explicit recovery;
- semantic and 12-byte-record agreement between a Rayforge `Ops` stream and
  the pinned BalorMK mock values;
- fail-closed profile and encoder negative cases;
- Rayforge workflow-model serialization and preview behavior for power,
  frequency and pulse width;
- independent layer visibility/output state and ordered serialization;
- material-recipe matching plus a fail-closed PirateRay provenance and exact
  machine/source/lens/correction compatibility gate;
- one consolidated no-device acceptance report that reruns the complete
  public test suite and leak guard, then hashes the regression evidence;
- a non-executing Windows artifact verifier that checks portable paths,
  archive safety, sizes, hashes, the pinned Rayforge revision and every
  packaged addon source while retaining the manual GUI gate;
- a versioned manual desktop-acceptance template and validator that cannot
  pass missing steps, connected hardware, changed evidence, stop conditions or
  an absent/malformed human review record;
- a deterministic acceptance-kit generator that copies only four allowlisted
  public template/input sources, hashes the three immutable inputs, refuses to
  overwrite an existing run directory, and binds the report to the exact kit,
  repository commit and artifact-verification report;
- pinned Rayforge and MeerK40t license/source contracts with drift tests, plus
  checkpoint schema 2 requiring the Rayforge MIT notice in the portable ZIP
  and beside the installer manifest;
- a single fail-closed Rayforge API-23 compatibility adapter around the
  internal driver registry, with collision, drift and symmetric-cleanup tests.
- a written M3 hardware-research protocol, intentionally incomplete public
  plan template and standard-library validator that requires exact
  evidence-backed request bytes, distinct safety roles, physical controls and
  recovery planning while always denying hardware authorization.
- a deterministic M3 review-packet generator that accepts only a
  `ready_for_review` plan, freezes its exact bytes and session window, records
  SHA-256 bindings, refuses overwrite and emits an untouched, non-authorizing
  human approval-record template.
- a fail-closed M3 approval validator that verifies the full packet hash chain,
  commit, reviewer, bounded session and explicit safety statements while still
  requiring live preflight and returning no automatic hardware authorization.

The remaining M1 release gates are deliberately narrow:

- vector project frequency and `QPulseWidth` now use a LightBurn 2.1.03,
  evidence-bound Hz/ns contract; absent pulse width and image equivalence stay
  blocked;
- the addon now registers a read-only GTK Tools-menu preflight action, but
  packaged Windows/GTK interaction is blocked until a reviewed Rayforge
  runtime with PyGObject and MSYS2/UCRT64 is available; the repository build
  entry point fetches pinned source but never installs that runtime;
- three operator-verified projects establish project-level `frequency` and
  `QPulseWidth` serialization, and the offline bridge stages complete vector
  settings with output disabled; promotion still requires an
  absent-pulse-width policy, image equivalence and exact machine-context
  validation;
- graphical workflow, lens correction and controller behavior remain unproven
  at the physical boundary and belong to later gated milestones.

ADR 0002 is accepted for the offline product architecture. These release gates
do not reopen that decision.

No item in this section authorizes USB access, controller commands or laser
output.

The M3 protocol can currently report only `incomplete`. It has no allowlisted
controller operation, reviewed driver/rollback plan, assigned people or
confirmed physical controls. Even a future `ready_for_review` result requires
separate human approval before hardware access.