beetzung
0519936531
- Add SetDeviceVisibilityUseCase, SetLuftdataUseCase, SetNarodmonUseCase - Introduce DeviceModel enum (Basic, Mobile, Solar, Radiation, Custom) - Add device-type drawables (active/inactive icons for each model) - Refactor Device SDK: repository, DAO, database, local/remote data sources - Update DeviceSettingsScreen, ManageViewModel, theme colors - Add/update string resources (default, ru, be) Made-with: Cursor
59 lines
2.2 KiB
Plaintext
59 lines
2.2 KiB
Plaintext
---
|
|
description: Core constraints for AIRMQ recreation project
|
|
alwaysApply: true
|
|
---
|
|
|
|
# AIRMQ Recreation Core Rules
|
|
|
|
## CRITICAL: Path check before any edit
|
|
|
|
**BEFORE editing any file, verify its path.**
|
|
|
|
- Path contains `airmq-android` but **NOT** `airmq-android-2026` → **NEVER EDIT.** Read-only reference.
|
|
- Path contains `airmq-android-2026` → OK to edit.
|
|
|
|
Example: `C:\Users\sysop\Desktop\airmq-android\app\...` → **DO NOT MODIFY.**
|
|
|
|
## Hard repository constraint
|
|
|
|
ALL CHANGES ONLY IN `airmq-android-2026` REPO; NO CHANGES EVER IN `airmq-android`.
|
|
|
|
## Repository boundaries
|
|
|
|
1. **NEVER** modify anything under `C:\Users\sysop\Desktop\airmq-android`.
|
|
2. Treat `airmq-android` as read-only reference only.
|
|
3. Create and apply all code/config/build changes only under `C:\Users\sysop\Desktop\airmq-android-2026`.
|
|
|
|
## Working policy
|
|
|
|
- When referencing legacy implementation details, copy behavior intentionally into the new project rather than editing old files.
|
|
- If a task appears to require modifying the old project, stop and propose an equivalent change in `airmq-android-2026` instead.
|
|
|
|
## Naming convention
|
|
|
|
- Use `AirMQ` everywhere for product naming.
|
|
- Never use mixed-case variants in text, docs, comments, identifiers, filenames, or symbols.
|
|
|
|
## Baseline architecture and platform stack
|
|
|
|
Use this stack as the default foundation for all implementation work in `airmq-android-2026`:
|
|
|
|
1. Jetpack Compose for UI.
|
|
2. Compose Navigation 3 as the in-app navigation system.
|
|
3. Firebase for mobile backend capabilities (for example auth, analytics, crash reporting, messaging, or remote config as needed).
|
|
4. OpenStreetMap platform for map rendering and map-related interactions.
|
|
5. Apollo GraphQL for GraphQL schema integration, client generation, and network operations.
|
|
|
|
If a requested change conflicts with this baseline, ask for explicit approval before introducing an alternative.
|
|
|
|
## Temporary or implicit implementations
|
|
|
|
When implementing something implicitly or obviously temporary, document it in `temp.md` at the project root with all important details:
|
|
|
|
- What was implemented
|
|
- Why it is temporary or implicit
|
|
- Location (files, components, modules)
|
|
- Any follow-up work or conditions for proper replacement
|
|
|
|
Create `temp.md` if it does not exist.
|