Build Android, unsigned iOS, or App Store IPA artifacts.
## Coding Style & Naming Conventions
Follow Dart style with 2-space indentation and `flutter_lints` from `analysis_options.yaml`. Use `dart format` before larger changes. Prefer existing patterns: static API classes in `lib/apis/`, model classes in `lib/models/`, page-level controllers beside views, and shared widgets in `lib/widgets/`.
Name Dart files in `snake_case.dart`; classes, controllers, and models use `PascalCase`. Keep route names and paths centralized in `lib/routes/routes.dart`.
## Testing Guidelines
Use `flutter_test`; place tests in `test/` and name files `*_test.dart`. Add focused tests for routing, service behavior, utilities, and widget regressions when changing shared logic. Run `flutter test` and `flutter analyze` before submitting changes.
## Commit & Pull Request Guidelines
Recent history uses short Conventional Commit-style prefixes, often in Chinese, such as `fix: ...`, `chore: ...`, and `docs: ...`. Keep commits scoped and descriptive.
Pull requests should include a clear summary, affected platforms (`iOS`, `Android`, or both), test results, and screenshots or screen recordings for UI changes. Link related issues when available and call out release-sensitive changes such as signing, payments, permissions, app version, or native dependency updates.
## Security & Configuration Tips
Do not commit new secrets. Existing signing and app configuration files may contain sensitive values; avoid moving or printing them in logs. Keep Kotlin at `1.8.22` because payment dependencies rely on it, and preserve the iOS deployment target at `13.0+` unless release requirements change.
