06 / Test protocol
One Windows layer. One metric. One rollback.
Do not combine High priority, a power plan, unknown FastFlags, a DNS change, and a third-party PowerShell utility. A combined result cannot tell you which change helped, did nothing, or caused the regression.
Choose one hypothesis
Example: “High priority may improve CPU-bound frame-time consistency while background compilation is running.” Avoid a claim such as “all tweaks give 500 FPS and zero ping.”
Capture the Windows value
Save the current process priority, active power scheme, exact registry value, TCP autotuning level, or DNS server list. Also record Windows build, Luczystrap 1.4.9, hardware, power source, and Roblox version.
Run the baseline three times
Use the same experience, server where possible, camera path, graphics level, background workload, duration, and temperature state. Record median FPS, 1% low or frame-time percentiles—not a single peak.
Enable only the chosen control
Accept administrator elevation only when the expected layer requires it. Do not run commands from a video, Discord pack, or “optimizer” alongside the Luczystrap toggle.
Repeat and inspect trade-offs
Repeat the same workload three times. Measure the target metric plus temperature, clock, battery/power, input, audio, recording, downloads, and connectivity where relevant.
Restore and verify Windows
Use the control’s known off path only where it matches your baseline. Otherwise restore the recorded power scheme or DNS values through Windows. Re-run the read-only state check and one final Roblox test.
Make a decision
Keep the tweak only if the effect repeats, the trade-off is acceptable, and rollback is proven. If the result is within run-to-run noise, the honest outcome is “no measured benefit on this system.”