45 lines
1.7 KiB
Markdown
45 lines
1.7 KiB
Markdown
# Rayforge Windows GUI preflight
|
|
|
|
- Date: 2026-10-19
|
|
- Scope: isolated no-device launch prerequisite check
|
|
- Transport: none
|
|
- Installation performed: no
|
|
|
|
## Result
|
|
|
|
The pinned Rayforge source and the external no-device JCZ addon are present,
|
|
but the current test environment cannot launch Rayforge's GTK application.
|
|
The observed launch failure is:
|
|
|
|
```text
|
|
ModuleNotFoundError: No module named 'gi'
|
|
```
|
|
|
|
Rayforge's Windows development path expects an MSYS2 UCRT64 installation,
|
|
`PyGObject`, GTK4 and Libadwaita. Neither `C:\msys64\msys2_shell.cmd` nor the
|
|
checkout's generated `.msys2_env` is present. The lightweight Python venv used
|
|
for the transport-free encoder spikes therefore cannot substitute for the GUI
|
|
runtime.
|
|
|
|
The deterministic preflight result is stored in
|
|
`tests/fixtures/rayforge-windows-gui-preflight.json`. It deliberately reports
|
|
the manual GUI checkpoint as blocked rather than treating source/model tests
|
|
as a successful application launch.
|
|
|
|
## Safety and scope
|
|
|
|
The attempted instance used an isolated configuration directory and contained
|
|
only the external no-device addon. The addon has no discovery or transport
|
|
implementation. No USB endpoint or controller command was reached.
|
|
|
|
No dependency or runtime was installed. Installing Rayforge's full Windows
|
|
toolchain is a separate, reviewable action: upstream's setup includes MSYS2,
|
|
GTK, compiler/build packages and network downloads, so it should not be an
|
|
implicit side effect of a workflow test.
|
|
|
|
## Next action
|
|
|
|
Provide an already reviewed Rayforge Windows build/runtime, or explicitly
|
|
approve installation of the pinned checkout's MSYS2/UCRT64 dependencies. Then
|
|
rerun the preflight and perform the packaged no-device interaction checklist
|
|
from `rayforge-graphical-workflow-spike.md`.
|