RC -> Main

.cursor/rules/code-organization.mdc

@@ -0,0 +1,65 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+# Code Organization Guide
+
+## Package Structure
+Each package should follow this structure:
+```
+package_name/
+├── lib/
+│   ├── src/           # Implementation files
+│   ├── package_name.dart  # Public API
+│   └── models/        # Data models
+├── test/              # Test files
+└── pubspec.yaml       # Package configuration
+```
+
+## App Structure
+Each Flutter app should follow this structure:
+```
+app_name/
+├── lib/
+│   ├── main.dart      # Entry point
+│   ├── app.dart       # App configuration
+│   ├── features/      # Feature modules
+│   ├── shared/        # Shared components
+│   └── utils/         # Utility functions
+├── test/              # Test files
+└── pubspec.yaml       # App configuration
+```
+
+## Feature Organization
+Features should be organized as follows:
+```
+feature_name/
+├── data/             # Data layer
+│   ├── repositories/
+│   └── datasources/
+├── domain/           # Business logic
+│   ├── entities/
+│   └── usecases/
+└── presentation/     # UI layer
+    ├── pages/
+    ├── widgets/
+    └── controllers/
+```
+
+## Best Practices
+1. Keep files focused and single-responsibility. Multiple files is prefered with part/part-of instead of large files. 
+2. Use barrel files (index.dart) for clean exports, named export.dart
+3. Follow the dependency rule: presentation → domain → data
+4. Keep business logic in the domain layer
+5. Use dependency injection for better testability
+
+## Linting
+1. Avoid missing commas
+
+## Testing
+- Unit tests for business logic
+- Widget tests for UI components
+- Integration tests for feature flows
+- Place tests next to the code they test
+

.cursor/rules/development-workflow.mdc

@@ -0,0 +1,121 @@
+---
+description: 
+globs: 
+alwaysApply: false
+---
+# Development Workflow Guide
+
+## Project Structure
+- `apps/` - Contains the main applications
+  - `multichoice/` - Main application
+  - `showcase/` - Showcase application (ignored in melos)
+- `packages/` - Shared packages
+  - `core/` - Core functionality and business logic
+  - `models/` - Data models and entities
+  - `theme/` - App theming and styling
+  - `ui_kit/` - Reusable UI components
+- `functions/` - Firebase Cloud Functions
+- `designs/` - Design assets and resources
+- `docs/` - Project documentation
+
+## Getting Started
+1. Ensure you have Flutter installed and configured with FVM
+2. Run `make setup` to initialize the project
+3. Use `melos bootstrap` to install dependencies
+4. Run `melos get` to ensure all packages are up to date
+
+## Common Commands
+
+### Build and Development
+- `melos test:all` - Run all tests across packages
+- `melos rebuild:all` - Clean build artifacts and regenerate everything
+- `make db` - Run build_runner for code generation
+- `make fb` - Flutter build with code generation
+- `make frb` - Full Flutter rebuild (clean + code generation)
+- `make clean` - Clean all generated files
+- `make mr` - Melos rebuild all packages
+
+### Testing
+- `melos test:core` - Run tests for core packages
+- `melos test:multichoice` - Run tests for main app
+- `melos test:integration` - Run integration tests
+- `melos coverage:all` - Generate coverage reports for all packages
+- `melos coverage:core` - Generate coverage for core packages
+- `melos coverage:multichoice` - Generate coverage for main app
+
+### Package Management
+- `melos upgrade` - Upgrade package dependencies
+- `melos upgrade:global` - Clean and upgrade all dependencies
+- `melos analyze` - Run static analysis on all packages
+
+## Package Development
+When working on shared packages:
+1. Make changes in the relevant package under `packages/`
+2. Run `melos test:core` to verify changes
+3. Run `melos analyze` to check for issues
+4. Update version in package's `pubspec.yaml`
+5. Run `melos publish` to publish changes
+
+## App Development
+When working on applications:
+1. Navigate to the specific app directory under `apps/`
+2. Use `flutter run` to start the development server
+3. Make changes and test locally
+4. Run `melos test:multichoice` to verify changes
+5. Use `make db` to regenerate code when needed
+
+## Code Generation
+The project uses several code generation tools:
+- `build_runner` for general code generation
+- `freezed` for immutable models
+- `auto_mappr` for object mapping
+- `mockito` for test mocks
+
+Generated files include:
+- `*.g.dart` - General generated code
+- `*.gr.dart` - GraphQL generated code
+- `*.freezed.dart` - Freezed model code
+- `*.config.dart` - Configuration code
+- `*.auto_mappr.dart` - Object mapping code
+- `*.mocks.dart` - Test mock code
+
+## Code Style
+- Follow the Dart style guide
+- Use the provided `analysis_options.yaml`
+- Run `make format` before committing changes
+- Ensure all tests pass before committing
+- Maintain test coverage above 80%
+
+## Version Control
+- Use feature branches for new development
+- Follow conventional commits format
+- Create pull requests for code review
+- Ensure CI passes before merging
+- Keep commits atomic and focused
+
+## Common Issues and Solutions
+1. Code Generation Issues
+   - Run `make frb` to clean and regenerate all code
+   - Check for circular dependencies
+   - Verify all imports are correct
+
+2. Test Failures
+   - Run `melos test:all` to identify failing tests
+   - Check mock implementations in `mocks.dart` files
+   - Verify test data is properly set up
+
+3. Build Issues
+   - Run `melos rebuild:all` to clean and rebuild
+   - Check for version conflicts in `pubspec.yaml`
+   - Verify all dependencies are properly declared
+
+## Best Practices
+1. Always write tests for new features
+2. Keep packages modular and focused
+3. Use dependency injection for better testability
+4. Document public APIs and complex logic
+5. Keep UI components in `ui_kit` package
+6. Use the theme package for consistent styling
+7. Follow the established project structure
+8. Run analysis before committing changes
+

.cursor/rules/project-structure.mdc

@@ -0,0 +1,57 @@
+---
+description: 
+globs: project-structure.mdc
+alwaysApply: false
+---
+# Project Structure Guide
+
+This is a Flutter monorepo project managed by Melos. The project is organized as follows:
+
+## Main Directories
+- `apps/` - Contains the main Flutter applications:
+  - [multichoice/](mdc:apps/multichoice) - The main application
+  - [showcase/](mdc:apps/showcase) - A showcase/demo application
+
+- `packages/` - Contains shared packages:
+  - [core/](mdc:packages/core) - Core functionality and utilities
+  - [models/](mdc:packages/models) - Shared data models
+  - [theme/](mdc:packages/theme) - Shared theming and styling
+
+## Configuration Files
+- [melos.yaml](mdc:melos.yaml) - Melos workspace configuration
+- [pubspec.yaml](mdc:pubspec.yaml) - Root project dependencies
+- [analysis_options.yaml](mdc:analysis_options.yaml) - Dart analysis configuration
+
+## Development Tools
+- [Makefile](mdc:Makefile) - Common development commands
+- [.fvmrc](mdc:.fvmrc) - Flutter version management
+- [.devcontainer/](mdc:.devcontainer) - Development container configuration
+
+## Documentation
+- [docs/](mdc:docs) - Project documentation
+- [README.md](mdc:README.md) - Project overview and setup instructions
+
+## Service and Interface Structure
+- For every implementation file (e.g., `AppInfoService`), there must be a corresponding abstract interface file (e.g., `i_app_info_service.dart`).
+- Implementation files should be in the `implementations` directory, and interfaces in the `interfaces` directory.
+
+## UI Constants
+- For any UI constants (e.g., `const SizedBox(width: 16)`), refer to `spacing_constants.dart` in the `/constants` folder.
+- For any `BorderRadius.circular`, look at `border_constants.dart` in the `/constants` folder.
+- Always check the `/constants` folder for UI constants (e.g., padding, gaps, borders, etc.).
+- If a constant does not exist, add it to the appropriate file in `/constants`.
+
+## Page Structure
+- For any new pages (e.g., `edit_tab_page.dart`, `home_page.dart`), place the `Scaffold` and `AppBar` in a parent class.
+- Keep the main body content in a private child class (e.g., `_EditPage`, `_HomePage`).
+
+## Drawer and Widget Modularity
+- When refactoring a class like `HomeDrawer` and creating smaller, more modular classes, create new private files for each modular class.
+- For a public class like `HomeDrawer` found in the `/drawer` folder, if there is a `_Example` class, create a file named `_example.dart` in the `/widgets` folder and use `part`/`part of` for file linkage.
+- `part` sections should always be alphabetical.
+- Modular classes should be in their own file for clarity and maintainability.
+
+## Testing
+- For unit tests, keep the file structure and file name the same as the file being tested. Refer to existing tests in the `packages` directory for structure and naming conventions.
+- For widget/integration tests, refer to `widget_keys.dart` for key usage to ensure consistency and testability.
+

.firebaserc

@@ -0,0 +1,5 @@
+{
+  "projects": {
+    "default": "multichoice-412309"
+  }
+}

.fvmrc

@@ -0,0 +1,3 @@
+{
+  "flutter": "3.27.1"
+}

.github/README.md

@@ -0,0 +1,142 @@
+# Workflows
+
+This repository contains GitHub Actions workflows for managing the build and deployment process across different environments: develop, staging (RC), and production.
+
+## Version Management
+
+The versioning system follows semantic versioning (MAJOR.MINOR.PATCH+BUILD) with support for release candidates (RC).
+
+### Version Bumping
+
+Version bumps are controlled through PR labels:
+- `major`: Increments the major version (1.0.0 -> 2.0.0)
+- `minor`: Increments the minor version (1.0.0 -> 1.1.0)
+- `patch`: Increments the patch version (1.0.0 -> 1.0.1)
+- `no-build`: Skips version bumping
+
+### Version Suffixes
+
+- RC (Release Candidate) suffix is automatically added in the staging workflow
+- RC suffix is removed when promoting to production
+
+## Workflow Overview
+
+### Develop Workflow
+
+- Triggered on PR closure to `develop` branch
+- Supports manual trigger via workflow_dispatch
+- Runs tests, analysis, and builds Android app
+- Uploads APK to Firebase App Distribution
+- Creates AAB artifact
+- Version bumping based on PR labels (patch, minor)
+
+### Staging (RC) Workflow
+
+- Triggered on PR closure to `rc` branch
+- Supports manual trigger via workflow_dispatch
+- Runs tests, analysis, and builds Android app
+- Creates AAB artifact
+- Uploads to Google Play internal track
+- Adds RC suffix to version
+- Version bumping based on PR labels (major, minor, patch)
+
+### Production Workflow
+
+- Triggered on PR closure to `main` branch from `rc`
+- Supports manual trigger via workflow_dispatch
+- Runs tests, analysis, and builds Android app
+- Creates both APK and AAB artifacts
+- Removes RC suffix from version
+- Uploads to Google Play production track (currently commented out)
+
+## Common Features Across Workflows
+
+### Pre-build Steps
+
+- Version management
+- GitHub App token generation
+- Label validation
+- Version bumping based on PR labels
+
+### Build Steps
+
+- Flutter and Java setup
+- Core package coverage testing
+- Codecov integration
+- Android keystore setup
+- Secrets file generation
+- APK/AAB building
+- Artifact uploads
+
+### Post-build Steps
+
+- Tag creation
+- Version updates in pubspec.yaml
+- Google Play Store deployment (where applicable)
+
+## Concurrency Control
+
+- All workflows implement concurrency control
+- Prevents multiple builds from running simultaneously
+- Cancels in-progress builds when new ones are triggered
+
+## Security
+
+- Uses GitHub App tokens for authentication
+- Securely handles Android keystore and secrets
+- Implements proper permission scopes for GitHub Actions
+
+## Artifacts
+
+- APK files for direct installation
+- AAB files for Google Play Store submission
+- Coverage reports for code quality monitoring
+
+## Linting Workflow
+
+## Build Workflow
+
+- Runs with every closed PR into develop
+- Has workflow_dispatch
+- Concurrency
+
+- Only runs when the PR has been merged OR if there is no 'no-build' label
+- Runs on ubuntu-latest
+
+preBuild
+- Checks out repo
+action=app_versioning
+- Uses 'stikkyapp/update-pubspec-version@v1' to bump version
+- Updates the pubspec file
+- Uploads the pubspec file
+- Echos the new version
+
+- Reads the config
+- Extracts build flag and environment (true and release)
+- Downloads pubspec file
+
+build
+- Runs on ubuntu-latest
+- checks out repo
+- sets up Java and Flutter
+- Runs melos coverage:core
+- Uploads coverage
+- Runs dart analysis
+<- Get latest tag
+<- Get current version from pubspec.yaml
+<- Generate GitHub App Token
+<- Update version in pubspec.yaml
+- Downloads pubspec file
+- Downloads Android Keystore.jks file
+- Create key.properties
+- Create secrets.dart
+- Builds appbundle
+- Builds APK
+- Uploads AAB artifact
+- Uploads APK to Firebase
+<- Create new tag
+
+postBuild
+- Runs on ubuntu-latest
+- Checks out repo
+- Uses 'stefanzweifel/git-auto-commit-action@v5' to bump and commit