Move apps to mobile directory structure

Relocated all app directories (client, design_system_viewer, staff) and their contents under the new 'apps/mobile' path. This change improves project organization and prepares for future platform-specific structuring.

apps/docs/01-architecture-principles.md

@@ -1,134 +0,0 @@
-# KROW Architecture Principles
-
-This document is the **AUTHORITATIVE** source of truth for the KROW engineering architecture.
-All agents and engineers must adhere strictly to these principles. Deviations are interpreted as errors.
-
-## 1. High-Level Architecture
-
-The KROW platform follows a strict **Clean Architecture** implementation within a **Melos Monorepo**.
-Dependencies flow **inwards** towards the Domain.
-
-```mermaid
-graph TD
-    subgraph "Apps (Entry Points)"
-        ClientApp[apps/client]
-        StaffApp[apps/staff]
-    end
-
-    subgraph "Features (Presentation & Application)"
-        ClientFeature[packages/features/client/jobs]
-        StaffFeature[packages/features/staff/schedule]
-        SharedFeature[packages/features/shared/auth]
-    end
-
-    subgraph "Interface Adapters"
-        DataConnect[packages/data_connect]
-        DesignSystem[packages/design_system]
-    end
-
-    subgraph "Core Domain"
-        Domain[packages/domain]
-        Core[packages/core]
-    end
-
-    %% Dependency Flow
-    ClientApp --> ClientFeature & SharedFeature
-    StaffApp --> StaffFeature & SharedFeature
-    ClientApp --> DataConnect
-    StaffApp --> DataConnect
-
-    ClientFeature & StaffFeature & SharedFeature --> Domain
-    ClientFeature & StaffFeature & SharedFeature --> DesignSystem
-    ClientFeature & StaffFeature & SharedFeature --> Core
-
-    DataConnect --> Domain
-    DataConnect --> Core
-    DesignSystem --> Core
-    Domain --> Core
-
-    %% Strict Barriers
-    linkStyle default stroke-width:2px,fill:none,stroke:gray
-```
-
-## 2. Repository Structure & Package Roles
-
-### 2.1 Apps (`apps/`)
-- **Role**: Application entry points and Dependency Injection (DI) roots.
-- **Responsibilities**:
-  - Initialize Flutter Modular.
-  - Assemble features into a navigation tree.
-  - Inject concrete implementations (from `data_connect`) into Feature packages.
-  - Configure environment-specific settings.
-- **RESTRICTION**: NO business logic. NO UI widgets (except `App` and `Main`).
-
-### 2.2 Features (`packages/features/<APP_NAME>/<FEATURE_NAME>`)
-- **Role**: Vertical slices of user-facing functionality.
-- **Internal Structure**:
-  - `domain/`: Feature-specific Use Cases and Repository Interfaces.
-  - `data/`: Repository Implementations.
-  - `presentation/`: 
-    - Pages, BLoCs, Widgets.
-    - For performance make the pages as `StatelessWidget` and move the state management to the BLoC or `StatefulWidget` to an external separate widget file.
-- **Responsibilities**:
-  - **Presentation**: UI Pages, Modular Routes.
-  - **State Management**: BLoCs / Cubits.
-  - **Application Logic**: Use Cases.
-- **RESTRICTION**: Features MUST NOT import other features. Communication happens via shared domain events.
-
-### 2.3 Domain (`packages/domain`)
-- **Role**: The stable heart of the system. Pure Dart.
-- **Responsibilities**:
-  - **Entities**: Immutable data models (Data Classes).
-  - **Failures**: Domain-specific error types.
-- **RESTRICTION**: NO Flutter dependencies. NO `json_annotation`. NO package dependencies (except `equatable`).
-
-### 2.4 Data Connect (`packages/data_connect`)
-- **Role**: Interface Adapter for Backend Access (Datasource Layer).
-- **Responsibilities**:
-  - Implement low-level Datasources or generated SDK wrappers.
-  - map Domain Entities to/from Firebase Data Connect generated code.
-  - Handle Firebase exceptions.
-
-### 2.5 Design System (`packages/design_system`)
-- **Role**: Visual language and component library.
-- **Responsibilities**:
-  - UI components if needed. But mostly try to modify the theme file (packages/design_system/lib/src/ui_theme.dart) so we can directly use the theme in the app, to use the default material widgets.
-    - If not possible, and if that specific widget is used in multiple features, then try to create a shared widget in the `packages/design_system/widgets`.
-  - Theme definitions (Colors, Typography).
-  - Assets (Icons, Images).
-  - More details on how to use this package is available in the `docs/03-design-system-usage.md`.
-- **RESTRICTION**: 
-  - CANNOT change colours or typography.
-  - Dumb widgets only. NO business logic. NO state management (Bloc).
-  - More details on how to use this package is available in the `docs/03-design-system-usage.md`.
-
-### 2.6 Core (`packages/core`)
-- **Role**: Cross-cutting concerns.
-- **Responsibilities**:
-  - Extension methods.
-  - Logger configuration.
-  - Base classes for Use Cases or Result types (functional error handling).
-
-## 3. Dependency Direction & Boundaries
-
-1.  **Domain Independence**: `packages/domain` knows NOTHING about the outer world. It defines *what* needs to be done, not *how*.
-2.  **UI Agnosticism**: `packages/features` depends on `packages/design_system` for looks and `packages/domain` for logic. It does NOT know about Firebase.
-3.  **Data Isolation**: `packages/data_connect` depends on `packages/domain` to know what interfaces to implement. It does NOT know about the UI.
-
-## 4. Firebase Data Connect Strategy
-
-Since Firebase Data Connect code does not yet exist, we adhere to a **Strict Mocking Strategy**:
-
-1.  **Interface First**: All data requirements are first defined as `abstract interface class IRepository` in `packages/domain`.
-2.  **Mock Implementation**:
-    -   Inside `packages/data_connect`, create a `MockRepository` implementation.
-    -   Use in-memory lists or hardcoded futures to simulate backend responses.
-    -   **CRITICAL**: Do NOT put mocks in `test/` folders if they are needed to run the app in "dev" mode. Put them in `lib/src/mocks/`.
-3.  **Future Integration**: When Data Connect is ready, we will add `RealRepository` in `packages/data_connect`.
-4.  **Injection**: `apps/` will inject either `MockRepository` or `RealRepository` based on build flags or environment variables.
-
-## 5. Feature Isolation
-
--   **Zero Direct Imports**: `import 'package:feature_a/...'` is FORBIDDEN inside `package:feature_b`.
--   **Navigation**: Use string-based routes or a shared route definition module in `core` (if absolutely necessary) to navigate between features.
--   **Data Sharing**: Features do not share state directly. They share data via the underlying `Domain` repositories (e.g., both observe the same `User` stream from `AuthRepository`).

apps/docs/02-agent-development-rules.md

@@ -1,83 +0,0 @@
-# Agent Development Rules
-
-These rules are **NON-NEGOTIABLE**. They are designed to prevent architectural degradation by automated agents.
-
-## 1. File Creation & Structure
-
-1.  **Feature-First Packaging**:
-    *   **DO**: Create new features as independent packages in `packages/features/<feature_name>`.
-    *   **DO NOT**: Add features to `packages/core` or existing apps directly.
-2.  **Path Conventions**:
-    *   Entities: `packages/domain/lib/src/entities/<entity>.dart`
-    *   Repositories (Interface): `packages/<feature>/lib/src/domain/repositories/<name>_repository_interface.dart`
-    *   Repositories (Impl): `packages/<feature>/lib/src/data/repositories_impl/<name>_repository_impl.dart`
-    *   Use Cases: `packages/<feature>/lib/src/application/<name>_usecase.dart`
-    *   BLoCs: `packages/<feature>/lib/src/presentation/blocs/<name>_bloc.dart`
-    *   Pages: `packages/<feature>/lib/src/presentation/pages/<name>_page.dart`
-3.  **Barrel Files**:
-    *   **DO**: Use `export` in `lib/<package_name>.dart` only for public APIs.
-    *   **DO NOT**: Export internal implementation details (like mocks or helper widgets) in the main package file.
-
-## 2. Naming Conventions
-
-Follow Dart standards strictly.
-
-| Type | Convention | Example |
-| :--- | :--- | :--- |
-| **Files** | `snake_case` | `user_profile_page.dart` |
-| **Classes** | `PascalCase` | `UserProfilePage` |
-| **Variables** | `camelCase` | `userProfile` |
-| **Interfaces** | terminate with `Interface` | `AuthRepositoryInterface` |
-| **Implementations** | terminate with `Impl` | `FirebaseDataConnectAuthRepositoryImpl` |
-| **Mocks** | terminate with `Mock` | `AuthRepositoryMock` |
-
-## 3. Logic Placement (Strict Boundaries)
-
-*   **Business Rules**: MUST reside in **Use Cases** (Domain/Feature Application layer).
-    *   *Forbidden*: Placing business rules in BLoCs or Widgets.
-*   **State Logic**: MUST reside in **BLoCs**.
-    *   *Forbidden*: `setState` in Pages (except for purely ephemeral UI animations).
-*   **Data Transformation**: MUST reside in **Repositories** (Data Connect layer).
-    *   *Forbidden*: Parsing JSON in the UI or Domain.
-*   **Navigation Logic**: MUST reside in **Modular Routes**.
-    *   *Forbidden*: `Navigator.push` with hardcoded widgets.
-
-## 4. Data Connect Mocking Strategy
-
-Since the backend does not exist, you must mock strictly:
-
-1.  **Define Interface**: Create `abstract interface class <name>RepositoryInterface` in `packages/<feature>/lib/src/domain/repositories/<name>_repository_interface.dart`.
-2.  **Create Mock**: Create `class MockRepository implements IRepository` in `packages/data_connect/lib/src/mocks/`.
-3.  **Fake Data**: Return hardcoded `Future`s with realistic dummy entities.
-4.  **Injection**: Register the `MockRepository` in the `AppModule` (in `apps/client` or `apps/staff`) until the real implementation exists.
-
-**DO NOT** use `mockito` or `mocktail` for these *runtime* mocks. Use simple fake classes.
-
-## 5. Prototype Migration Rules
-
-You have access to `prototypes/` folders. When migrating code:
-
-1.  **Extract Assets**: 
-    * You MAY copy icons, images, and colors. But they should be tailored to the current design system. Do not change the colours and typgorahys in the design system. They are final. And you have to use these in the UI.
-      * When you matching colous and typography, from the POC match it with the design system and use the colors and typography from the design system. As mentioned in the `docs/03-design-system-usage.md`.
-2.  **Extract Layouts**: You MAY copy `build` methods for UI structure.
-3.  **REJECT Architecture**: You MUST **NOT** copy the `GetX`, `Provider`, or `MVC` patterns often found in prototypes. Refactor immediately to **Bloc + Clean Architecture with Flutter Modular and Melos**.
-
-## 6. Handling Ambiguity
-
-If a user request is vague:
-
-1.  **STOP**: Do not guess domain fields or workflows.
-2.  **ANALYZE**: 
- - For architecture related questions, refer to `docs/01-architecture-principles.md` or existing code.
- - For design system related questions, refer to `docs/03-design-system-usage.md` or existing code.
-3.  **DOCUMENT**: If you must make an assumption to proceed, add a comment `// ASSUMPTION: <explanation>` and mention it in your final summary.
-4.  **ASK**: Prefer asking the user for clarification on business rules (e.g., "Should a 'Job' have a 'status'?").
-
-## 7. Dependencies
-
-*   **DO NOT** add 3rd party packages without checking `packages/core` first.
-*   **DO NOT** add `firebase_auth` or `cloud_firestore` to any Feature package. They belong in `data_connect` only.
-
-## 8. Follow Clean Code Principles
-* Add doc comments to all classes and methods you create.

apps/docs/03-design-system-usage.md

@@ -1,131 +0,0 @@
-# 03 - Design System Usage Guide
-
-This document defines the mandatory standards for designing and implementing user interfaces across all applications and feature packages using the shared `packages/design_system`.
-
-## 1. Introduction & Purpose
-
-The Design System is the single source of truth for the visual identity of the project. Its purpose is to ensure UI consistency, reduce development velocity by providing reusable primitives, and eliminate "design drift" across multiple feature teams and applications.
-
-**All UI implementation MUST consume values ONLY from the `design_system` package.**
-
-## 2. Design System Ownership & Responsibility
-
-- **Centralized Authority**: The `packages/design_system` is the owner of all brand assets, colors, typography, and core components.
-- **No Local Overrides**: Feature packages (e.g., `staff_authentication`) are consumers. They are prohibited from defining their own global styles or overriding theme values locally.
-- **Extension Policy**: If a required style (color, font, or icon) is missing, the developer must first add it to the `design_system` package following existing patterns before using it in a feature.
-
-## 3. Package Structure Overview (`packages/design_system`)
-
-The package is organized to separate tokens from implementation:
-- `lib/src/ui_colors.dart`: Color tokens and semantic mappings.
-- `lib/src/ui_typography.dart`: Text styles and font configurations.
-- `lib/src/ui_icons.dart`: Exported icon sets.
-- `lib/src/ui_constants.dart`: Spacing, radius, and elevation tokens.
-- `lib/src/ui_theme.dart`: Centralized `ThemeData` factory.
-- `lib/src/widgets/`: Common "Smart Widgets" and reusable UI building blocks.
-
-## 4. Colors Usage Rules
-
-Feature packages **MUST NOT** define custom hex codes or `Color` constants.
-
-### Usage Protocol
-- **Primary Method**:Use `UiColors` from the design system for specific brand accents.
-- **Naming Matching**: If an exact color is missing, use the closest existing semantic color (e.g., use `UiColors.mutedForeground` instead of a hardcoded grey).
-
-```dart
-// ❌ ANTI-PATTERN: Hardcoded color
-Container(color: Color(0xFF1A2234))
-
-// ✅ CORRECT: Design system token
-Container(color: UiColors.background)
-```
-
-## 5. Typography Usage Rules
-
-Custom `TextStyle` definitions in feature packages are **STRICTLY PROHIBITED**.
-
-### Usage Protocol
-- Use `UiTypography` from the design system for specific brand accents.
-
-```dart
-// ❌ ANTI-PATTERN: Custom TextStyle
-Text('Hello', style: TextStyle(fontSize: 24, fontWeight: FontWeight.bold))
-
-// ✅ CORRECT: Design system typography
-Text('Hello', style: UiTypography.display1m)
-```
-
-## 6. Icons Usage Rules
-
-Feature packages **MUST NOT** import icon libraries (like `lucide_icons`) directly unless specified. They should use the icons exposed via `UiIcons` or the approved central library.
-
-- **Standardization**: Ensure the same icon is used for the same action across all features (e.g., always use `UiIcons.back` for navigation).
-- **Additions**: New icons must be added to the design system (only using the typedef _IconLib = LucideIcons and nothing else) first to ensure they follow the project's stroke weight and sizing standards.
-
-## 7. UI Constants & Layout Rules
-
-Hardcoded padding, margins, and radius values are **PROHIBITED**.
-
-- **Spacing**: Use `UiConstants.spacing` multiplied by tokens (e.g., `S`, `M`, `L`).
-- **Border Radius**: Use `UiConstants.borderRadius`.
-- **Elevation**: Use `UiConstants.elevation`.
-
-```dart
-// ✅ CORRECT: Spacing and Radius constants
-Padding(
-  padding: EdgeInsets.all(UiConstants.spacingL),
-  child: Container(
-    borderRadius: BorderRadius.circular(UiConstants.radiusM),
-  ),
-)
-```
-
-## 8. Common Smart Widgets Guidelines
-
-The design system provides "Smart Widgets" – these are high-level UI components that encapsulate both styling and standard behavior.
-
-- **Standard Widgets**: Prefer standard Flutter Material widgets (e.g., `ElevatedButton`) but styled via the central theme.
-- **Custom Components**: Use `design_system` widgets for non-standard elements or wisgets that has similar design across various features, if provided.
-- **Composition**: Prefer composing standard widgets over creating deep inheritance hierarchies in features.
-
-## 9. Theme Configuration & Usage
-
-Applications (`apps/`) must initialize the theme once in the root `MaterialApp`.
-
-```dart
-MaterialApp.router(
-  theme: StaffTheme.light, // Mandatory: Consumption of centralized theme
-  // ...
-)
-```
-**No application-level theme customization is allowed.**
-
-## 10. Feature Development Workflow (POC → Themed)
-
-To bridge the gap between rapid prototyping (POCs) and production-grade code, developers must follow this three-step workflow:
-
-1. **Step 1: Structural Implementation**: Implement the UI logic and layout **exactly matching the POC**. Hardcoded values from the POC are acceptable in this transient state to ensure visual parity.
-2. **Step 2: Logic Refactor**: Immediately refactor the code to:
-   - Follow the `docs/01-architecture-principles.md` and `docs/02-agent-development-rules.md` to refactor the code.
-3. **Step 3: Theme Refactor**: Immediately refactor the code to:
-   - Replace hex codes with `UiColors`.
-   - Replace manual `TextStyle` with `UiTypography`.
-   - Replace hardcoded padding/radius with `UiConstants`.
-   - Upgrade icons to design system versions.
-
-## 11. Anti-Patterns & Common Mistakes
-
-- **"Magic Numbers"**: Hardcoding `EdgeInsets.all(12.0)` instead of using design system constants.
-- **Local Themes**: Using `Theme(data: ...)` to override colors for a specific section of a page.
-- **Hex Hunting**: Copy-pasting hex codes from Figma or POCs into feature code.
-- **Package Bypassing**: Importing `package:flutter/material.dart` and ignoring `package:design_system`.
-
-## 12. Enforcement & Review Checklist
-
-Before any UI code is merged, it must pass this checklist:
-1. [ ] No hardcoded `Color(...)` or `0xFF...` in the feature package.
-2. [ ] No custom `TextStyle(...)` definitions.
-3. [ ] All spacing/padding/radius uses `UiConstants`.
-4. [ ] All icons are consumed from the approved design system source.
-5. [ ] The feature relies on the global `ThemeData` and does not provide local overrides.
-6. [ ] The layout matches the POC visual intent and element placement(wireframing and logic) while using the design system primitives.

apps/mobile/.gitignore

@@ -4,6 +4,9 @@ prototypes/*
 # AI prompts
 ai_prompts/*
 
+# Docs
+docs/*
+
 # Template feature
 packages/features/shared/template_feature/*