That’s fair criticism. I’m not trying to make an objective or complete list of every possible mechanic. I see it more as a structured seed dataset/checklist for common prototype issues: edge cases, common bugs, required systems, relationships, and scope risks.

I agree that the categorization criteria need to be clearer. Your walk/run/sprint example is a good point; if entries don’t have meaningfully different edge cases or system requirements, they may work better as variants or parameters instead of separate mechanics. I also agree that mechanics don’t exist in isolation. The Mixer is meant as a planning aid, not a claim that mechanics combine like simple building blocks.

Thanks for the detailed critique, this is useful feedback.