Delete apps/mobile/ai_prompts directory
This commit is contained in:
Achintha Isuru
@@ -1,75 +0,0 @@
|
|||||||
You are continuing work on an existing **Flutter monorepo–based mobile system** with multiple applications and a shared data/connect layer.
|
|
||||||
|
|
||||||
This prompt **replaces all missing prior thread context** and must be treated as the **single source of truth** for how you reason, plan, and execute work in this thread.
|
|
||||||
|
|
||||||
## 🧭 PROJECT OVERVIEW
|
|
||||||
|
|
||||||
* The project contains **multiple Flutter applications** (e.g. Staff app, Client app) that are being **rebuilt from scratch** using **Flutter Clean Architecture**, while **reusing UI code and flows** from POCs (prototypes).
|
|
||||||
* The goal is to rebuild the mobile apps in a **production-grade, scalable, agent-first manner**, not as POCs.
|
|
||||||
|
|
||||||
## 🧠 YOUR ROLE IN THIS THREAD
|
|
||||||
|
|
||||||
You are acting as a **Senior Flutter Architect + Execution Agent**, responsible for:
|
|
||||||
* Enforcing architectural consistency across features
|
|
||||||
* Preventing scope creep, tight coupling, and shortcut implementations
|
|
||||||
* Producing outputs that are suitable for **real engineering teams**, not demos
|
|
||||||
|
|
||||||
You **do not** invent architecture, flows, or patterns unless explicitly asked.
|
|
||||||
You **do** challenge requirements if they violate architecture or agent rules.
|
|
||||||
|
|
||||||
|
|
||||||
## 📚 MANDATORY DOCUMENTS (NON-NEGOTIABLE)
|
|
||||||
|
|
||||||
You MUST strictly follow the rules and constraints defined in **both documents below** at all times:
|
|
||||||
|
|
||||||
### 1️⃣ Architecture Principles
|
|
||||||
|
|
||||||
**apps/mobile/docs/01-architecture-principles.md**
|
|
||||||
|
|
||||||
This document defines:
|
|
||||||
* Clean Architecture boundaries
|
|
||||||
* Layer responsibilities (presentation / domain / data)
|
|
||||||
* Dependency rules
|
|
||||||
* Navigation, state management, and feature isolation expectations
|
|
||||||
and others.
|
|
||||||
|
|
||||||
### 2️⃣ Agent Development Rules
|
|
||||||
|
|
||||||
**apps/mobile/docs/02-agent-development-rules.md**
|
|
||||||
|
|
||||||
This document defines:
|
|
||||||
* How features are planned, split, and executed
|
|
||||||
* What an agent may or may not do
|
|
||||||
* Output formats, assumptions, and guardrails
|
|
||||||
* How prompts must be structured for future reuse
|
|
||||||
and others.
|
|
||||||
|
|
||||||
### 3️⃣ Design system guidelines
|
|
||||||
|
|
||||||
**apps/mobile/docs/03-design-system-usage.md**
|
|
||||||
|
|
||||||
This document defines:
|
|
||||||
* The design system of the project and the rules on how to use the design system.
|
|
||||||
|
|
||||||
⚠️ If a request conflicts with either document, you must:
|
|
||||||
|
|
||||||
* Call out the conflict explicitly
|
|
||||||
* Propose a compliant alternative
|
|
||||||
* Never silently violate the rules
|
|
||||||
|
|
||||||
## 🔁 CURRENT STATE
|
|
||||||
|
|
||||||
* Prior thread context is **not available**
|
|
||||||
* Architecture and agent rules **do exist** and must be referenced
|
|
||||||
* Any assumptions you make must be stated clearly
|
|
||||||
|
|
||||||
## ✅ ACKNOWLEDGEMENT REQUIRED
|
|
||||||
|
|
||||||
Before proceeding with any feature work, you must:
|
|
||||||
|
|
||||||
1. Acknowledge that this context has been loaded
|
|
||||||
2. Confirm adherence to:
|
|
||||||
* `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
* `apps/mobile/docs/02-agent-development-rules.md`
|
|
||||||
* `apps/mobile/docs/03-design-system-usage.md`
|
|
||||||
3. Wait for the next instruction or feature prompt
|
|
||||||
@@ -1,34 +0,0 @@
|
|||||||
You are an expert Flutter architect and monorepo engineer.
|
|
||||||
|
|
||||||
You are working on the KROW workforce management platform.
|
|
||||||
Your responsibility is to rebuild two Flutter mobile applications (Client + Staff)
|
|
||||||
using a clean, agent-first architecture.
|
|
||||||
|
|
||||||
You must strictly follow:
|
|
||||||
- Clean Architecture
|
|
||||||
- Feature-first packaging
|
|
||||||
- Melos monorepo conventions
|
|
||||||
- Bloc for state management
|
|
||||||
- Flutter Modular for
|
|
||||||
- Modularized routes.
|
|
||||||
- Modularized Dependency Injection.
|
|
||||||
- Firebase Data Connect as the ONLY backend access layer
|
|
||||||
- No UI polish unless explicitly requested
|
|
||||||
|
|
||||||
IMPORTANT CONSTRAINTS:
|
|
||||||
- Firebase Data Connect code DOES NOT EXIST YET
|
|
||||||
- You must mock Data Connect responses using interfaces and fake implementations
|
|
||||||
- Domain entities MUST match the provided KROW domain model exactly
|
|
||||||
- No DTOs or entities inside feature packages
|
|
||||||
- Features must be independently testable
|
|
||||||
- Do not invent new entities, statuses, or workflows
|
|
||||||
|
|
||||||
You must never:
|
|
||||||
- Access Firebase directly
|
|
||||||
- Hardcode backend logic inside UI
|
|
||||||
- Mix domain logic with presentation
|
|
||||||
- Change entity definitions unless explicitly instructed
|
|
||||||
|
|
||||||
If ambiguity exists, document it instead of guessing.
|
|
||||||
|
|
||||||
Confirm understanding silently and wait for step instructions.
|
|
||||||
@@ -1,54 +0,0 @@
|
|||||||
TASK: Create the KROW Flutter monorepo skeleton using Melos.
|
|
||||||
|
|
||||||
You must:
|
|
||||||
1. Create the directory structure exactly as defined below (some of the parts are already developed)
|
|
||||||
2. Initialize Melos (some of the parts are already developed)
|
|
||||||
3. Create minimal pubspec.yaml files where required (some of the parts are already developed)
|
|
||||||
4. Do NOT add application logic
|
|
||||||
5. Do NOT generate Flutter apps yet (basic strcuture of the apps/ are developed)
|
|
||||||
|
|
||||||
Target structure:
|
|
||||||
|
|
||||||
root/
|
|
||||||
├── apps/
|
|
||||||
│ ├── client/
|
|
||||||
│ ├── staff/
|
|
||||||
│ └── design_system_viewer/
|
|
||||||
│
|
|
||||||
├── packages/
|
|
||||||
│ ├── core/
|
|
||||||
│ ├── design_system/
|
|
||||||
│ ├── domain/
|
|
||||||
│ ├── data_connect/
|
|
||||||
│ └── features/
|
|
||||||
│ ├─ domain/
|
|
||||||
│ │ ├─ repositories/
|
|
||||||
│ │ └─ usecases/
|
|
||||||
│ │
|
|
||||||
│ ├─ data/
|
|
||||||
│ │ ├─ datasources/
|
|
||||||
│ │ └─ repositories_impl/
|
|
||||||
│ │
|
|
||||||
│ ├─ presentation/
|
|
||||||
│ │ ├─ state/
|
|
||||||
│ │ ├─ pages/
|
|
||||||
│ │ └─ widgets/
|
|
||||||
│ │
|
|
||||||
│ └─ feature_manifest.md
|
|
||||||
├── docs/
|
|
||||||
└── dataconnect/
|
|
||||||
|
|
||||||
Rules:
|
|
||||||
- Use Flutter 3.x compatible setup
|
|
||||||
- All packages must be melos-aware
|
|
||||||
- Keep pubspec files minimal
|
|
||||||
- No dependencies unless required for structure
|
|
||||||
- No example widgets or boilerplate UI
|
|
||||||
|
|
||||||
Output:
|
|
||||||
- melos.yaml
|
|
||||||
- Folder tree
|
|
||||||
- Minimal pubspec.yaml per package/app
|
|
||||||
- Short explanation of dependency boundaries
|
|
||||||
|
|
||||||
Do NOT proceed beyond skeleton creation.
|
|
||||||
@@ -1,19 +0,0 @@
|
|||||||
TASK: Create docs/02-agent-development-rules.md
|
|
||||||
|
|
||||||
This document defines NON-NEGOTIABLE rules for AI agents.
|
|
||||||
|
|
||||||
Must include:
|
|
||||||
- File creation rules
|
|
||||||
- Naming conventions
|
|
||||||
- Where logic is allowed / forbidden
|
|
||||||
- How to mock Data Connect safely
|
|
||||||
- How to introduce new features
|
|
||||||
- How to reuse prototype code without copying architecture mistakes
|
|
||||||
- Rules for handling ambiguity (must document, not assume)
|
|
||||||
|
|
||||||
Format:
|
|
||||||
- Clear numbered rules
|
|
||||||
- Short explanations
|
|
||||||
- Explicit "DO / DO NOT" sections
|
|
||||||
|
|
||||||
This document will be enforced strictly.
|
|
||||||
@@ -1,251 +0,0 @@
|
|||||||
TASK: Create the shared domain package.
|
|
||||||
|
|
||||||
Domain Details:
|
|
||||||
|
|
||||||
## 1. Core Domain Logic
|
|
||||||
|
|
||||||
### 1.1 Domain Entities Overview
|
|
||||||
|
|
||||||
The KROW platform has **49 domain entities** organized into 8 logical groups:
|
|
||||||
|
|
||||||
```
|
|
||||||
┌────────────────────────────────────────────────────────────────────┐
|
|
||||||
│ KROW DOMAIN MODEL │
|
|
||||||
├────────────────────────────────────────────────────────────────────┤
|
|
||||||
│ │
|
|
||||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
|
||||||
│ │ USERS & │ │ BUSINESS & │ │ EVENTS & │ │
|
|
||||||
│ │ MEMBERSHIP │ │ ORGANIZATION│ │ SHIFTS │ │
|
|
||||||
│ ├─────────────┤ ├─────────────┤ ├─────────────┤ │
|
|
||||||
│ │ User │ │ Business │ │ Event │ │
|
|
||||||
│ │ Staff │ │ BusinessSet │ │ EventShift │ │
|
|
||||||
│ │ Membership │ │ Hub │ │ Position │ │
|
|
||||||
│ │ BizMember │ │ HubDept │ │ Assignment │ │
|
|
||||||
│ │ HubMember │ │ BizContract │ │ WorkSession │ │
|
|
||||||
│ └─────────────┘ └─────────────┘ └─────────────┘ │
|
|
||||||
│ │
|
|
||||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
|
||||||
│ │ SKILLS & │ │ FINANCIAL │ │ RATINGS & │ │
|
|
||||||
│ │ CERTS │ │ PAYROLL │ │ PENALTIES │ │
|
|
||||||
│ ├─────────────┤ ├─────────────┤ ├─────────────┤ │
|
|
||||||
│ │ Skill │ │ Invoice │ │ StaffRating │ │
|
|
||||||
│ │ SkillCat │ │ InvoiceItem │ │ PenaltyLog │ │
|
|
||||||
│ │ StaffSkill │ │ InvDecline │ │ BizStaffPref│ │
|
|
||||||
│ │ Certificate │ │ StaffPayment│ │ │ │
|
|
||||||
│ │ SkillKit │ │ │ │ │ │
|
|
||||||
│ └─────────────┘ └─────────────┘ └─────────────┘ │
|
|
||||||
│ │
|
|
||||||
│ ┌─────────────┐ ┌─────────────┐ │
|
|
||||||
│ │ STAFF │ │ SUPPORT │ │
|
|
||||||
│ │ PROFILE │ │ CONFIG │ │
|
|
||||||
│ ├─────────────┤ ├─────────────┤ │
|
|
||||||
│ │ EmergencyC │ │ Addon │ │
|
|
||||||
│ │ BankAccount │ │ Tag │ │
|
|
||||||
│ │ Accessibl │ │ Media │ │
|
|
||||||
│ │ Schedule │ │ WorkingArea │ │
|
|
||||||
│ └─────────────┘ └─────────────┘ │
|
|
||||||
│ │
|
|
||||||
└────────────────────────────────────────────────────────────────────┘
|
|
||||||
```
|
|
||||||
|
|
||||||
### 1.2 Key Entity Definitions
|
|
||||||
|
|
||||||
#### User & Authentication
|
|
||||||
|
|
||||||
| Entity | Description | Key Fields |
|
|
||||||
|--------|-------------|------------|
|
|
||||||
| **User** | Base auth entity (Firebase) | `id`, `email`, `phone`, `role` |
|
|
||||||
| **Staff** | Worker profile | `auth_provider_id`, `name`, `email`, `phone`, `status`, `address`, `avatar`, `live_photo` |
|
|
||||||
| **Membership** | Polymorphic org membership | `user_id`, `memberable_id`, `memberable_type`, `role` |
|
|
||||||
|
|
||||||
**Staff Status Flow:**
|
|
||||||
```
|
|
||||||
registered → pending → completed_profile → verified → [active | blocked | inactive]
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Business & Organization
|
|
||||||
|
|
||||||
| Entity | Description | Key Fields |
|
|
||||||
|--------|-------------|------------|
|
|
||||||
| **Business** | Client company | `name`, `registration`, `status`, `avatar` |
|
|
||||||
| **BusinessSetting** | Payroll config | `prefix`, `overtime`, `clock_in`, `clock_out` |
|
|
||||||
| **Hub** | Branch location | `business_id`, `name`, `address`, `status` |
|
|
||||||
| **HubDepartment** | Dept within hub | `hub_id`, `name` |
|
|
||||||
|
|
||||||
#### Events & Shifts
|
|
||||||
|
|
||||||
| Entity | Description | Key Fields |
|
|
||||||
|--------|-------------|------------|
|
|
||||||
| **Event** | Job posting | `business_id`, `hub_id`, `name`, `date`, `status`, `contract_type` |
|
|
||||||
| **EventShift** | Work session | `event_id`, `name`, `address` |
|
|
||||||
| **EventShiftPosition** | Job opening | `shift_id`, `skill_id`, `count`, `rate`, `start_time`, `end_time`, `break` |
|
|
||||||
| **EventShiftPositionStaff** | Assignment | `staff_id`, `position_id`, `status`, `clock_in`, `clock_out` |
|
|
||||||
|
|
||||||
**Event Status Flow:**
|
|
||||||
```
|
|
||||||
draft → pending → assigned → confirmed → active → finished → completed → closed
|
|
||||||
↘ under_review
|
|
||||||
```
|
|
||||||
|
|
||||||
**Assignment Status Flow:**
|
|
||||||
```
|
|
||||||
assigned → confirmed → ongoing → completed
|
|
||||||
↘ decline_by_staff → [penalty logged]
|
|
||||||
↘ canceled_by_staff → [penalty logged]
|
|
||||||
↘ no_showed → [penalty logged]
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Skills & Certifications
|
|
||||||
|
|
||||||
| Entity | Description | Key Fields |
|
|
||||||
|--------|-------------|------------|
|
|
||||||
| **Skill** | Job category | `category_id`, `name`, `price` |
|
|
||||||
| **StaffSkill** | Worker qualification | `staff_id`, `skill_id`, `level`, `experience`, `status` |
|
|
||||||
| **Certificate** | Required credential | `name`, `required` |
|
|
||||||
| **SkillKit** | Uniform/equipment req | `skill_id`, `name`, `is_required`, `type` |
|
|
||||||
|
|
||||||
**Skill Levels:** `beginner` | `skilled` | `professional`
|
|
||||||
|
|
||||||
#### Financial & Payroll
|
|
||||||
|
|
||||||
| Entity | Description | Key Fields |
|
|
||||||
|--------|-------------|------------|
|
|
||||||
| **Invoice** | Business bill | `event_id`, `business_id`, `status`, `total`, `work_amount`, `addons_amount` |
|
|
||||||
| **InvoiceItem** | Line item | `invoice_id`, `staff_id`, `work_hours`, `rate`, `amounts` |
|
|
||||||
| **StaffPayment** | Worker payout | `staff_id`, `assignment_id`, `amount`, `status`, `paid_at` |
|
|
||||||
|
|
||||||
**Invoice Status Flow:**
|
|
||||||
```
|
|
||||||
open → disputed → resolved → verified → paid/reconciled
|
|
||||||
↘ overdue
|
|
||||||
```
|
|
||||||
|
|
||||||
### 1.3 Core Business Workflows
|
|
||||||
|
|
||||||
#### Workflow 1: Event Lifecycle
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
sequenceDiagram
|
|
||||||
participant Client as Client App
|
|
||||||
participant API as Backend API
|
|
||||||
participant Admin as Admin
|
|
||||||
participant Staff as Worker App
|
|
||||||
|
|
||||||
Note over Client,API: 1. Event Creation
|
|
||||||
Client->>API: Create Event with Shifts & Positions
|
|
||||||
API-->>Client: Event Created (Draft)
|
|
||||||
Client->>API: Publish Event
|
|
||||||
API-->>Client: Event Published
|
|
||||||
|
|
||||||
opt 2. Staff Assignment (Optional)
|
|
||||||
Note over Admin,API: Optional Staff Assignment
|
|
||||||
Admin->>API: Assign Staff to Shift
|
|
||||||
API-->>Admin: Assignment Confirmed
|
|
||||||
API->>Staff: Notification: New Shift
|
|
||||||
end
|
|
||||||
|
|
||||||
Note over Staff,API: 3. Shift Acceptance
|
|
||||||
Staff->>API: Accept Shift
|
|
||||||
API-->>Staff: Shift Confirmed
|
|
||||||
|
|
||||||
Note over Client,Staff: 4. Day of Event
|
|
||||||
Client->>Client: Generate QR Code
|
|
||||||
Staff->>Staff: Scan QR Code
|
|
||||||
Staff->>API: Clock In
|
|
||||||
Staff->>API: Clock Out
|
|
||||||
|
|
||||||
Note over Client,API: 5. Post-Event
|
|
||||||
Client->>API: Rate Staff
|
|
||||||
API->>API: Generate Invoice
|
|
||||||
Client->>API: Approve Invoice
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Workflow 2: Staff Onboarding
|
|
||||||
|
|
||||||
```
|
|
||||||
1. Registration (Firebase Phone Auth)
|
|
||||||
├── Create Staff record (status: registered)
|
|
||||||
└── Profile created with auth_provider_id
|
|
||||||
|
|
||||||
2. Profile Completion
|
|
||||||
├── Personal info (name, email, address)
|
|
||||||
├── Avatar upload
|
|
||||||
├── Emergency contacts
|
|
||||||
└── Bank account details
|
|
||||||
|
|
||||||
3. Skills Declaration
|
|
||||||
├── Add skills with level/experience
|
|
||||||
└── Status: pending → verified (admin)
|
|
||||||
|
|
||||||
4. Certification Upload
|
|
||||||
├── Upload certificates
|
|
||||||
└── Status: pending → verified (admin)
|
|
||||||
|
|
||||||
5. Equipment Confirmation
|
|
||||||
├── Confirm uniforms per skill
|
|
||||||
├── Confirm equipment per skill
|
|
||||||
└── Upload photos as proof
|
|
||||||
|
|
||||||
6. Profile Submission
|
|
||||||
├── Complete verification checklist
|
|
||||||
└── Status: completed_profile → verified
|
|
||||||
```
|
|
||||||
|
|
||||||
#### Workflow 3: Payroll Calculation
|
|
||||||
|
|
||||||
```
|
|
||||||
Work Hours = (clock_out - clock_in) - break_duration
|
|
||||||
|
|
||||||
Overtime Rules:
|
|
||||||
├── Regular Hours (1x): hours <= 8
|
|
||||||
├── Overtime Hours (1.5x): 8 < hours <= 10
|
|
||||||
└── Doubletime Hours (2x): hours > 10
|
|
||||||
|
|
||||||
Payment = (regular_hours × rate × 1.0)
|
|
||||||
+ (overtime_hours × rate × 1.5)
|
|
||||||
+ (doubletime_hours × rate × 2.0)
|
|
||||||
+ addons_amount
|
|
||||||
```
|
|
||||||
|
|
||||||
You must:
|
|
||||||
1. Create domain entities for ALL KROW entities provided
|
|
||||||
2. Group entities by logical folders
|
|
||||||
3. Use immutable models
|
|
||||||
4. Do NOT add JSON, serialization, or Firebase annotations
|
|
||||||
5. Do NOT add business logic
|
|
||||||
6. Use enums for all status flows
|
|
||||||
7. Add Doc comments for readability of the code.
|
|
||||||
|
|
||||||
Entities MUST match:
|
|
||||||
- Names
|
|
||||||
- Fields
|
|
||||||
- Status flows
|
|
||||||
|
|
||||||
Include:
|
|
||||||
- Enums for status flows
|
|
||||||
- Value objects where appropriate
|
|
||||||
- Clear folder structure
|
|
||||||
|
|
||||||
Exclude:
|
|
||||||
- DTOs
|
|
||||||
- Repositories
|
|
||||||
- Firebase logic
|
|
||||||
- Validation logic
|
|
||||||
|
|
||||||
Create packages/domain/lib/domain.dart (barrel file)
|
|
||||||
This file must export ALL entities and enums.
|
|
||||||
|
|
||||||
All other packages will import ONLY:
|
|
||||||
import 'package:domain/domain.dart';
|
|
||||||
|
|
||||||
Must follow archtiecture principles defined in:
|
|
||||||
- docs/01-architecture-principles.md
|
|
||||||
|
|
||||||
Must Follow Agent rules defined in:
|
|
||||||
- docs/02-agent-development-rules.md
|
|
||||||
|
|
||||||
Output:
|
|
||||||
- Folder structure
|
|
||||||
- Dart files
|
|
||||||
- Short explanation of grouping strategy
|
|
||||||
@@ -1,26 +0,0 @@
|
|||||||
TASK: Create the data_connect package as a mockable abstraction layer.
|
|
||||||
|
|
||||||
You must:
|
|
||||||
1. Define abstract repositories for each domain group
|
|
||||||
2. Create fake/mock implementations using in-memory data
|
|
||||||
3. Simulate async GraphQL-style behavior
|
|
||||||
4. Ensure replaceability with real generated SDK later
|
|
||||||
|
|
||||||
Rules:
|
|
||||||
- No Firebase imports
|
|
||||||
- No HTTP
|
|
||||||
- No direct entity mutation
|
|
||||||
- Return domain entities ONLY
|
|
||||||
|
|
||||||
Must follow archtiecture principles defined in:
|
|
||||||
- docs/01-architecture-principles.md
|
|
||||||
|
|
||||||
Must Follow Agent rules defined in:
|
|
||||||
- docs/02-agent-development-rules.md
|
|
||||||
|
|
||||||
Include:
|
|
||||||
- Interfaces
|
|
||||||
- Fake implementations
|
|
||||||
- Clear TODO markers for real SDK replacement
|
|
||||||
|
|
||||||
This package must compile and be dependency-safe.
|
|
||||||
@@ -1,23 +0,0 @@
|
|||||||
Task is to reafactor an existing Flutter page so that it fully complies with the design system defined in:
|
|
||||||
- apps/mobile/docs/03-design-system-usage.md
|
|
||||||
|
|
||||||
## 📍 TARGET PAGE
|
|
||||||
|
|
||||||
File to refactor the widgets in:
|
|
||||||
|
|
||||||
- apps/mobile/packages/features/staff/profile_sections/compliance/tax_forms
|
|
||||||
/lib/src/presentation/pages
|
|
||||||
- apps/mobile/packages/features/staff/profile_sections/compliance/tax_forms
|
|
||||||
/lib/src/presentation/widgets
|
|
||||||
|
|
||||||
Example page to get inspiration as this page is fully complies with the design system guide mentioned above:
|
|
||||||
apps/mobile/packages/features/staff/authentication/lib/src/presentation/pages/profile_setup_page.dart
|
|
||||||
|
|
||||||
## 🎯 GOAL
|
|
||||||
|
|
||||||
Transform the existing page implementation so that it complies with the design guideline provieded.
|
|
||||||
|
|
||||||
## 🔒 STRICT RULES (NON-NEGOTIABLE)
|
|
||||||
While following the rules outlined in the document above you should also DO NOT remove or change existing functionality of the page, add doc comments and use named parameters in functions.
|
|
||||||
|
|
||||||
Proceed with the refactor now.
|
|
||||||
@@ -1,85 +0,0 @@
|
|||||||
# FEATURE EXECUTION WORKFLOW — Modular Feature Development
|
|
||||||
|
|
||||||
## APPLICATION TARGET
|
|
||||||
`apps/mobile/apps/staff`
|
|
||||||
|
|
||||||
## EXECUTION PLAN (MANDATORY 3-STEP PROCESS)
|
|
||||||
|
|
||||||
### Step 1: Prototype Implementation
|
|
||||||
- **Goal**: First move the entire UI(pages and widgets) and logic from the prototype into the new feature package without changes. The page in the new package should be an one-one of the POC page.
|
|
||||||
- **Action**: Create the package in the folder structure under `apps/mobile/packages/features/[domain]/[feature_name]`.
|
|
||||||
- **References**: Use the specified prototypes as the primary source of truth for UI/UX, logic and business logic.
|
|
||||||
- **MANDATORY**: The **Layout** and **Wireframing** from the prototype should stay **EXACTLY** as they are. Do not re-design the UX or move elements around.
|
|
||||||
- **Note**: Pages should end with `_page.dart` instead of `_screen.dart`.
|
|
||||||
|
|
||||||
### Step 2: Architecture & Clean Code Refactor
|
|
||||||
- **Goal**: Align the prototype code with the project's long-term standards.
|
|
||||||
- **Rules**:
|
|
||||||
- Follow `apps/mobile/docs/01-architecture-principles.md` (BLoC, Domain-Driven, Repository pattern).
|
|
||||||
- Move the logic into blocs, domain and data. Use only the `apps/mobile/packages/data_connect/lib/src/mocks` to retrive / add data. This should happen via the data layer (presentation (ui -> bloc) -> domain -> data).
|
|
||||||
- Apply Clean Code: Meaningful names, one responsibility per class, small methods. Add doc comments to the files, functions for better readability.
|
|
||||||
- No magic strings inside business logic.
|
|
||||||
|
|
||||||
### Step 3: Localization & Navigation Finalization
|
|
||||||
- **Goal**: Centralize resources and decouple routing.
|
|
||||||
- **Mandatory Requirements**:
|
|
||||||
1. **Centralized Localization**:
|
|
||||||
- Extract ALL strings to `apps/mobile/packages/core_localization/lib/src/l10n/en.i18n.json` (and `es`).
|
|
||||||
- Use a unique namespace for the feature (e.g., `t.feature_name.sub_section.key`).
|
|
||||||
- Remove `slang` dependencies from the feature; re-export `core_localization` instead.
|
|
||||||
2. **Typed Navigation**:
|
|
||||||
- Create `lib/src/presentation/navigation/[feature_name]_navigator.dart`.
|
|
||||||
- Implement an extension on `IModularNavigator` for all feature-specific routes.
|
|
||||||
- Replace all `Modular.to.pushNamed('/path')` with typed methods like `Modular.to.pushFeaturePage()`.
|
|
||||||
|
|
||||||
### Step 4: Design Matching & Design System Alignment
|
|
||||||
- **Goal**: Ensure the visual identity matches the Design System perfectly while maintaining the prototype's layout.
|
|
||||||
- **Action**: Follow `apps/mobile/docs/03-design-system-usage.md` (Section 10: POC → Themed workflow).
|
|
||||||
- **Mandatory Requirements**:
|
|
||||||
- **Colors**: Replace all hex codes or raw colors with `UiColors`.
|
|
||||||
- **Typography**: Replace all manual `TextStyle` with `UiTypography`.
|
|
||||||
- **Spacing/Radius**: Replace all magic numbers with `UiConstants`.
|
|
||||||
- **Icons**: Use `UiIcons` exclusively.
|
|
||||||
- **Policy**: Maintain the prototype's layout structure while upgrading the "atoms" and "molecules" to the Design System tokens.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
# FEATURE SCOPE — Staff shifts Screen
|
|
||||||
|
|
||||||
This feature implements the **staff shifts screen** for the **Mobile Staff application**.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## PROTOTYPE REFERENCES (SOURCE OF TRUTH)
|
|
||||||
|
|
||||||
* `apps/mobile/prototypes/staff_mobile_application/lib/screens/worker/payments_screen.dart`
|
|
||||||
|
|
||||||
## WHERE THE FEATURE SHOULD RESIDE
|
|
||||||
This feature should reside in the feature `apps/mobile/packages/features/staff/payments`.
|
|
||||||
|
|
||||||
## ARCHITECTURE CONSTRAINTS (NON-NEGOTIABLE)
|
|
||||||
|
|
||||||
You MUST strictly follow:
|
|
||||||
1. `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
2. `apps/mobile/docs/02-agent-development-rules.md`
|
|
||||||
3. `apps/mobile/docs/03-design-system-usage.md`
|
|
||||||
4. `MEMORY[user_global]` (Clean Code & architectural decisions)
|
|
||||||
|
|
||||||
Violations must be **explicitly reported**, never silently ignored.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## REFERENCE IMPLEMENTATION
|
|
||||||
|
|
||||||
Use:
|
|
||||||
|
|
||||||
```
|
|
||||||
apps/mobile/packages/features/staff/authentication
|
|
||||||
```
|
|
||||||
|
|
||||||
as the **gold standard** for:
|
|
||||||
|
|
||||||
* Feature structure
|
|
||||||
* Navigation pattern
|
|
||||||
* Localization strategy
|
|
||||||
* Design system integration
|
|
||||||
@@ -1,6 +0,0 @@
|
|||||||
for the "apps/mobile/packages/features/staff/payments" feature
|
|
||||||
|
|
||||||
- Follow apps/mobile/docs/01-architecture-principles.md (BLoC, Domain-Driven, Repository pattern).
|
|
||||||
- Move the logic into blocs, domain and data. Use only the apps/mobile/packages/data_connect/lib/src/mocks to retrive / add data. This should happen via the data layer (presentation (ui -> bloc) -> domain -> data).
|
|
||||||
- Apply Clean Code: Meaningful names, one responsibility per class, small methods. Add doc comments to the files, functions for better readability.
|
|
||||||
No magic strings inside business logic.
|
|
||||||
@@ -1,66 +0,0 @@
|
|||||||
Task is to refactor an existing Flutter package so that it fully complies with the architecture rules defined in:
|
|
||||||
|
|
||||||
* `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
|
|
||||||
## TARGET PAGE
|
|
||||||
|
|
||||||
Package to refactor:
|
|
||||||
|
|
||||||
```
|
|
||||||
apps/mobile/packages/features/staff/shifts
|
|
||||||
```
|
|
||||||
|
|
||||||
Reference feature that already follows the architecture correctly (this is the GOLD STANDARD):
|
|
||||||
|
|
||||||
```
|
|
||||||
apps/mobile/packages/features/staff/authentication
|
|
||||||
```
|
|
||||||
|
|
||||||
## GOAL
|
|
||||||
|
|
||||||
Refactor the feature so that it strictly follows **KROW Clean Architecture principles**, while preserving **all existing behavior and UI output**.
|
|
||||||
|
|
||||||
The result must be structurally correct, testable, and aligned with feature-level responsibilities.
|
|
||||||
|
|
||||||
## STRICT RULES (NON-NEGOTIABLE)
|
|
||||||
|
|
||||||
You MUST follow **all** rules defined in:
|
|
||||||
|
|
||||||
* `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
|
|
||||||
Additionally, enforce the following:
|
|
||||||
|
|
||||||
### Architecture Rules
|
|
||||||
|
|
||||||
* The pages **MUST remain inside the feature package**
|
|
||||||
* The pages **MUST NOT import other features**
|
|
||||||
* Business logic **MUST NOT exist inside the page**
|
|
||||||
* State handling **MUST be moved to a Bloc/Cubit or external widget**
|
|
||||||
* Use cases **MUST live in `domain/`**
|
|
||||||
* Repository access **MUST go through abstractions**
|
|
||||||
|
|
||||||
### Presentation Rules
|
|
||||||
|
|
||||||
* Use `StatelessWidget` for pages
|
|
||||||
* If state is required:
|
|
||||||
* Move it to a Bloc/Cubit, OR
|
|
||||||
* Extract it into a separate widget file
|
|
||||||
* Use named parameters
|
|
||||||
* Add clear doc comments where structure or intent is non-obvious
|
|
||||||
|
|
||||||
### Safety Rules
|
|
||||||
|
|
||||||
* ❌ Do NOT remove existing functionality
|
|
||||||
* ❌ Do NOT change user-facing behavior
|
|
||||||
* ❌ Do NOT introduce new dependencies
|
|
||||||
* ❌ Do NOT break modular boundaries
|
|
||||||
|
|
||||||
## EXPECTED OUTPUT
|
|
||||||
|
|
||||||
* A refactored page that:
|
|
||||||
* Fully complies with `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
* Has clean separation of concerns
|
|
||||||
* Is easy to reason about and extend
|
|
||||||
* Any required supporting files (Bloc, use case, widget extraction) created **inside the same feature**
|
|
||||||
|
|
||||||
Proceed with the refactor now.
|
|
||||||
@@ -1,88 +0,0 @@
|
|||||||
Task is to refactor the **domain and data layers** of an existing feature so that they fully comply with the architecture rules defined in:
|
|
||||||
|
|
||||||
* `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
|
|
||||||
## 📍 TARGET FEATURE
|
|
||||||
|
|
||||||
Feature to refactor:
|
|
||||||
|
|
||||||
```
|
|
||||||
apps/mobile/packages/features/staff/payments
|
|
||||||
```
|
|
||||||
|
|
||||||
Files exist in:
|
|
||||||
|
|
||||||
```
|
|
||||||
lib/src/domain/
|
|
||||||
lib/src/data/
|
|
||||||
```
|
|
||||||
|
|
||||||
## 🏆 GOLD STANDARD REFERENCE
|
|
||||||
|
|
||||||
Use the following feature as the **gold standard implementation** for structure, responsibility split, and dependency direction:
|
|
||||||
|
|
||||||
```
|
|
||||||
apps/mobile/packages/features/staff/authentication
|
|
||||||
```
|
|
||||||
|
|
||||||
Follow its patterns for:
|
|
||||||
|
|
||||||
* Repository interfaces
|
|
||||||
* Use case design
|
|
||||||
* Data layer delegation
|
|
||||||
* Interaction with `apps/mobile/packages/data_connect`
|
|
||||||
|
|
||||||
## 🎯 GOAL
|
|
||||||
|
|
||||||
Refactor the feature so that its **Domain** and **Data** layers strictly follow **KROW Clean Architecture** as defined in `apps/mobile/docs/01-architecture-principles.md`.
|
|
||||||
|
|
||||||
The feature must rely on **shared Domain entities** and must delegate all data access through `apps/mobile/packages/data_connect`.
|
|
||||||
|
|
||||||
## STRICT RULES (NON-NEGOTIABLE)
|
|
||||||
|
|
||||||
You MUST follow **all rules defined in**:
|
|
||||||
|
|
||||||
* `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
|
|
||||||
In particular, ensure that:
|
|
||||||
|
|
||||||
* Domain uses **only entities from**:
|
|
||||||
|
|
||||||
```
|
|
||||||
apps/mobile/packages/domain/lib/src/entities
|
|
||||||
```
|
|
||||||
* Feature-level domain models are removed
|
|
||||||
* Repository interfaces live in the Domain layer
|
|
||||||
* Repository implementations live in the Data layer
|
|
||||||
* Domain does NOT return concrete data objects
|
|
||||||
* Usecases in the domain layer must be extended from the `apps/mobile/packages/core/lib/src/domain/usecases/usecase.dart`.
|
|
||||||
* If there are arguments in the usecases, they must be extended from the `apps/mobile/packages/core/lib/src/domain/arguments/usecase_argument.dart`. Example usecase is given below
|
|
||||||
- `apps/mobile/packages/features/staff/authentication/lib/src/domain/usecases/verify_otp_usecase.dart`
|
|
||||||
* Data layer does NOT contain business logic and not create objects only call the `apps/mobile/packages/data_connect`.
|
|
||||||
* All data access flows through `apps/mobile/packages/data_connect`
|
|
||||||
|
|
||||||
## DOCUMENTATION
|
|
||||||
|
|
||||||
* Add clear **doc comments** to all files you modify
|
|
||||||
* Document:
|
|
||||||
* Purpose of the file
|
|
||||||
* Role of the class or interface in the architecture
|
|
||||||
|
|
||||||
## SAFETY GUARANTEES
|
|
||||||
|
|
||||||
* Do NOT change existing behavior
|
|
||||||
* Do NOT break presentation layer contracts
|
|
||||||
* Do NOT bypass `apps/mobile/packages/data_connect`
|
|
||||||
|
|
||||||
## EXPECTED OUTPUT
|
|
||||||
|
|
||||||
* Domain layer aligned with `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
* Data layer aligned with `apps/mobile/docs/01-architecture-principles.md`
|
|
||||||
* Structure and patterns consistent with:
|
|
||||||
|
|
||||||
```
|
|
||||||
apps/mobile/packages/features/staff/authentication
|
|
||||||
```
|
|
||||||
* Clean, documented, and compliant implementation
|
|
||||||
|
|
||||||
Proceed with the refactor now.
|
|
||||||
Reference in New Issue
Block a user