Find where a feature belongs

Start from the behavior

Describe the behavior in a few words, then search for its user-facing name, related type names, and nearby tests. For example, a block placement issue may involve the input action, targeting code, a block hook, and a world write.

Search C# files with rg from the repository root:

rg -n "OnBlockPlaced|CanPlaceAt" src/Voxel src/Player

If a behavior starts in a scene, inspect that scene’s attached script and follow the calls from there. The runtime map describes the usual startup and gameplay paths.

Follow ownership and callers

1. Find the type that makes the behavior decision.
2. Check its base class or interface to understand shared behavior.
3. Find direct callers and lifecycle hooks so you know when the code runs.
4. Check tests and registration/data setup for assumptions that affect the behavior.
5. Read the relevant subsystem guide and engineering notes before changing shared foundations.

Use the repository map to locate likely owners. Keep domain rules close to their owner: block behavior belongs with blocks, item use belongs with item behavior, and entity movement belongs with entities. Managers should coordinate shared lifecycle or storage.

Choose a small change

Prefer a change that has one clear owner and a way to observe its result. Reuse existing registries, data types, and helpers. Avoid duplicating a subsystem or pushing a local rule into a central manager. For voxel storage and meshing, preserve packed representations and allocation-conscious inner loops.

Before editing, note the expected behavior and the specific callers or data that could be affected. Afterward, inspect the diff and run the narrowest relevant validation described in build and validation.