These rules apply to future work in this repository.
- Read
PROJECT_CONTEXT.md,ARCHITECTURE.md,GAME_DESIGN.md,ROADMAP.md, andIDEAS.md. - Inspect the current module structure, relevant implementations, tests, and
git statusbefore choosing an approach. - Preserve existing user changes. Do not revert or overwrite unrelated work.
- Prefer the project's current patterns and dependencies over introducing a new framework.
- Keep camera and MediaPipe code independent from exercise, combat, and UI rules.
- Keep exercise detectors independent from enemies and damage.
- Put reusable fitness contracts in
:domain, combat rules in:game, content/repositories in:data, and Android/Compose orchestration in:app. - Store balance and content in catalogs/configuration rather than UI branches.
- Add extension points only where a known future mechanic needs them.
- Experimental features must fail safely and be clearly marked for users and developers.
- Complete requested work end to end: implementation, tests, build, and relevant manual QA.
- Keep release behavior free of debug-only controls.
- Add focused tests for new rules, edge cases, and regression-prone behavior.
- When adding generated or third-party assets, keep stable filenames, optimize file size, and update notices when licensing requires it.
- Do not add network services, analytics, camera uploads, medical claims, or automatic exercise selection without an explicit product decision.
- Run unit tests for affected modules.
- Compile both debug and release code for user-facing changes.
- Run Android lint when UI, resources, manifest, or Android integration changes.
- For interaction changes, validate the main flow on an emulator when available, including error-free logs.
- State clearly when hardware-dependent camera or pose behavior could not be fully verified.
- Update
PROJECT_CONTEXT.md,ARCHITECTURE.md,GAME_DESIGN.md, andROADMAP.mdwhenever product behavior, architecture, balance, or priorities change. - Record uncommitted product concepts in
IDEAS.md; move them toROADMAP.mdonly when scope and completion criteria are clear. - Keep documentation factual and aligned with the code.
- Review the final diff and exclude IDE-only or unrelated files.
- Finish completed tasks with a concise commit describing the delivered behavior.
- Push the branch and provide a short GitHub summary when publication is part of the request.