1. Establish a simple baseline
A build on this Wiki means a workable starting configuration made through the controls the current game exposes. Begin with the simplest setup you can understand and reproduce, then record its visible state. The baseline is not presented as optimal. Its job is to give every later adjustment a clear reference while keeping the game’s stated qualitative goal of a solid and clear arrangement in view.
2. Confirm consistent behavior
Observe the baseline more than once when practical before expanding it. Confirm that the intended setup remains saved and that the visible feedback is stable enough to compare. If the same configuration produces conflicting observations, keep building decisions conservative and check the current version or conditions. Complexity added before consistency is understood only creates more variables to explain.
3. Identify the first limitation
Describe the first visible limitation as a specific behavior or feedback difference rather than an assumed hidden weakness. Decide what evidence would show that the limitation changed. This keeps the build process focused on function and prevents unsupported component values, technical specifications, or copied formulas from controlling the progression.
4. Move into Sound Arrangement
Move from basic setup into Sound Arrangement once the baseline is reproducible and the first limitation has been described. Arrangement is the stage where changes become intentional: each adjustment should answer a known question rather than merely make the setup larger. Preserve the baseline while organizing the next version so the original function remains available for comparison. This boundary keeps build progression distinct from detailed arrangement troubleshooting.
5. Test deliberately
Test the arranged version against the preserved baseline using the same available observation when possible. Record the visible difference before deciding what caused it. If the change produces a consistent improvement or exposes a repeatable weakness, the result can guide refinement. If outcomes conflict, return to the stable build instead of adding another layer. Testing reveals where the progression needs attention; it does not supply undocumented internal values.
6. Decide whether refinement is ready
The build is ready for deeper refinement when it can be recreated, behaves consistently enough to compare, has one clearly identified limitation, and retains a usable baseline. Readiness means the next arrangement decision can be evaluated; it does not prove optimal performance. Use Sound Arrangement for organization and refinement, Sound System Testing for result interpretation, and the checklist before battle. Component specifications, hidden weights, numeric thresholds, and guaranteed formulas remain unverified. Before moving forward, confirm that the baseline still serves its original function and that the first limitation was identified through visible behavior rather than assumption. If the build cannot be reproduced, return to the first step. If it reproduces but behaves inconsistently, pause progression and use the Testing page. If it is stable and the limitation is clear, refinement has a defined purpose. This decision point prevents build work from becoming an endless sequence of additions with no testable goal. Record the ready state before changing it: note the visible setup, intended behavior, known limitation, and next comparison. This reference makes later results easier to interpret because a failed refinement can be compared with a working build instead of reconstructed from memory. It also separates a build decision from an arrangement preference.