| name | field-test-editor |
| description | The human-in-the-loop bug loop for the real Unreal editor — the AI prepares, fixes, verifies, and applies; the owner tests in a live UE editor; repeat until dead. Use for bugs only reproducible in-editor/PIE, and for packaged-fidelity verification. |
Field-test loop for the Unreal editor
You (the AI) do everything except the actual in-editor testing. The human tests, reports, and
decides "fixed" or "persists". Loop until fixed. Production-grade fixes only — root cause, never
a bandaid.
Environment facts (verify, don't assume, if anything fails)
- Live tree (where the owner tests):
C:\Yanivs\GameDev\ReactiveUI\ReactiveUI-Unreal.
NEVER edit it while the owner's Unreal editor is open (UE locks module DLLs — your edits +
rebuild will fail loudly anyway); NEVER kill their editor process.
- Work tree (where you develop): create a git worktree (e.g.
C:\Yanivs\GameDev\ReactiveUI\RUIU-work) on first need; branches off origin/dev.
- Engine path: per the
test-run skill's environment facts. ALWAYS redirect engine output to a
file.
- Live Coding (Ctrl+Alt+F11) hot-patches
.cpp function bodies only. Any header change,
UPROPERTY/UFUNCTION change, module add/remove, or Build.cs change ⇒ tell the owner to CLOSE
the editor and rebuild — the analogue of Godot's "plugin scripts don't hot-swap reliably;
restart".
The loop
- Reproduce & fix (work tree, feature branch off
origin/dev): root cause first; extend a
ReactiveUI.* suite to catch it when possible (per-section markers so hangs name their
culprit).
- Verify before handing over: the dev-process gate ladder — build,
RUICompile -check
(Phase 3+), affected suites, ReactiveUI.Boot.
- Commit on the feature branch (this loop is a standing ask to commit; author is the owner —
no Co-Authored-By).
- Apply to the live tree: if it's clean, fetch + checkout the branch (ask before switching
their checkout); otherwise copy the changed
Plugins/ReactiveUI/** files over. Then tell the
owner whether Live Coding suffices (cpp-body-only change) or the editor must restart
(anything else — when in doubt, restart).
- Owner tests. Ask for: what they did, what they saw,
Saved/Logs/ReactiveUIUnrealDemo.log,
the Message Log "ReactiveUI" page, and any scratch error file they pasted into.
- Fixed? Merge flow per dev-process (PR → dev, owner merges, fast-forward master), changelog +
bump BEFORE the PR. Persists? Back to 1 with the new evidence — never re-try the same
theory twice; add instrumentation instead.
Packaged-fidelity test (when the change affects packaging)
Test what a store user gets: scripts/package-plugin.ps1, unzip
ReactiveUI-<ver>-UE<ver>.zip into a FRESH project's Plugins/, open, enable the plugin,
expect the log banner ReactiveUI <ver> loaded and the demo/gallery to render. A missing banner
means the plugin is NOT running — silence is never "nothing to do".
Scar tissue (why these steps exist)
- Two-tree separation exists because editing the live tree under an open editor produced
locked-file half-states in the sibling repo's loop; the worktree makes it structurally
impossible.
- "When in doubt, restart": Live Coding accepting a patch is not proof the patch is LOADED —
reinstanced objects with stale layouts produced ghost bugs that vanished on restart; a
restart is cheaper than a ghost hunt.
- Ask for the log FILE, not a description — "it crashed" debugging burned loops until the
house rule became: no theory without the actual log text.
- The banner check is the packaged-fidelity keystone — a broken store zip once looked
"installed fine" with the plugin silently not loading.
