ecs-guidelisted

# Entity-Component-System Guidelines (Data-Oriented) Architecture for a data-oriented ECS: how entities and components are stored, how systems iterate them, and how to bridge the ECS to stateful external systems (renderer, physics) without losing parallelism or cache locality. For the underlying cache/layout reasoning see **data-oriented-design-guide**; for the renderer the ECS feeds, see **gpu-rendering-guide**; for the allocators behind component storage see **memory-management-guide**. ## Requirements - A component is plain data (POD-ish struct); behavior lives in systems, not components. - Storage groups entities by their set of components, so a system can walk matching components linearly. ## Essentials - **Entity type = component bitmask** - Group entities of identical component sets contiguously; iterate by type, see [references/storage-and-archetypes.md](references/storage-and-archetypes.md) - **One component instance per type** - Model "many of a thing" with child entities or a list-component, not duplicate components, see [references/single-vs-multiple-components.md](references/single-vs-multiple-components.md) - **Systems are filter-and-batch loops** - Select types matching a bitmask, walk co-located arrays in a tight loop, go wide across cores, see [references/systems-and-iteration.md](references/systems-and-iteration.md) - **Default to brute-force sync** - Re-push matching entities each frame; add dirty flags / change lists only when profiling proves it, see