ai-flow-dev 2.2.0 → 2.2.4

package/prompts/mobile/flow-build-phase-2.md

@@ -1,579 +1,573 @@
-# Phase 2: Navigation & Architecture
+## PHASE 2: Data Architecture (15-20 min)
 
-**Duration:** 15-20 minutes
-**Questions:** ~10 questions
-**Output:** docs/navigation.md, docs/architecture.md, parts of ai-instructions.md
----
-## 🎯 Objective
+> **Order for this phase:** 2.1 → 2.2 → 2.3 → 2.4 → 2.5 → 2.6 → 2.7
 
-Define the **navigation structure and architecture** for your mobile app:
+> **📌 Scope-based behavior:**
+> - **MVP/Basic Scope:** Focus only on essential entities and basic relationships.
+> - **Production-Ready Scope:** In-depth modeling including indexes, constraints, and audit fields.
 
-1. What navigation patterns will you use?
-2. How will you organize screens and components?
-3. What architecture pattern will you follow?
-4. How will you structure your codebase?
----
-## 📋 Questions
+### Objective
 
-### Question 2.1: Navigation Pattern
+Design the database model, entities, and relationships.
 
-**What navigation pattern will your app use?**
+---
 
-**For React Native:**
+## 🔍 Pre-Flight Check (Smart Skip Logic)
 
-- A) ⭐ **Stack Navigation** (Recommended)
-  - Hierarchical navigation (push/pop)
-  - Best for: Most apps, detail screens
-  - Library: React Navigation Stack
+> 📎 **Reference:** See [prompts/shared/smart-skip-preflight.md](../shared/smart-skip-preflight.md) for the complete smart skip logic.
 
-- B) 🔥 **Tab Navigation**
-  - Bottom tabs or top tabs
-  - Best for: Multi-section apps (Home, Search, Profile, etc.)
-  - Library: React Navigation Tabs
+**Execute Pre-Flight Check for Phase 2:**
 
-- C) **Drawer Navigation**
-  - Side menu drawer
-  - Best for: Apps with many sections
-  - Library: React Navigation Drawer
+- **Target File**: `docs/data-model.md`
+- **Phase Name**: "DATA ARCHITECTURE"
+- **Key Items**: Entities, relationships, data patterns, indexes
+- **Typical Gaps**: Missing entities, undocumented relationships, missing fields
 
-- D) **Combined (Tab + Stack)** (Most Common)
-  - Bottom tabs with stack navigators per tab
-  - Best for: Complex apps with multiple sections
-  - Example: Instagram, Twitter
+**Proceed with appropriate scenario based on audit data from `.ai-flow/cache/audit-data.json`**
 
-**For Flutter:**
+---
 
-- A) ⭐ **Navigator 2.0 / GoRouter** (Recommended)
-  - Declarative routing
-  - Best for: Modern Flutter apps
+## Phase 2 Questions (Full Mode)
 
-- B) **AutoRoute**
-  - Code generation for routes
-  - Best for: Type-safe routing
+**2.1 Database Type**
 
-- C) **Traditional Navigator**
-  - Imperative navigation
-  - Best for: Simple apps
-
-**For Native iOS:**
-
-- A) ⭐ **UINavigationController** (Standard)
-- B) **UITabBarController** (Tabs)
-- C) **Coordinator Pattern** (Advanced)
-
-**For Native Android:**
-
-- A) ⭐ **Navigation Component** (Recommended)
-- B) **Jetpack Compose Navigation** (If using Compose)
-
-**Your answer:**
-
-**If Combined selected, ask:**
+```
+[If detected from Phase 0, show:]
+✅ Database Detected: [PostgreSQL/MySQL/MongoDB/etc.]
+✅ Version: [version if found]
+✅ ORM/Client: [Prisma/TypeORM/Sequelize/SQLAlchemy/etc.]
 
-- How many bottom tabs? (3-5 recommended)
-- What are the main sections? (e.g., Home, Search, Profile, Settings)
----
-### Question 2.2: Screen Organization
+Is this correct? (Y/N)
+If no, please provide correct database type.
 
-**How will you organize your screens?**
+[If NOT detected, ask:]
+What type of database will you use? (Can select multiple)
 
-A) ⭐ **Feature-based** (Recommended)
+A) ⭐ PostgreSQL - Recommended for most backends (ACID, relational, JSON support)
+B) 🔥 MySQL/MariaDB - Popular, proven, wide ecosystem
+C) ⚡ MongoDB - Modern, NoSQL, flexible schema
+D) 🏆 Multi-database - PostgreSQL + Redis + S3, etc.
+E) Other: [specify]
 
-- Group by feature/domain
-- Example: `screens/auth/`, `screens/home/`, `screens/profile/`
-- Best for: Medium to large apps
+Why this choice?
+```
 
-B) **Flat Structure**
+**2.2 Core Data Entities**
 
-- All screens in one folder
-- Example: `screens/LoginScreen.tsx`, `screens/HomeScreen.tsx`
-- Best for: Small apps (<10 screens)
+```
+[If detected from Phase 0, show:]
+✅ Entities Detected from Code:
+- [User] - [description if inferred from code]
+- [Product] - [description]
+- [Order] - [description]
+- [etc.]
+
+Are these correct? (Y/N)
+Do you need to add more entities? (Y/N)
+
+[If NOT detected OR user wants to add more, show:]
+Based on your system type (from Phase 1, question 1.5), here are common entities:
+
+🛒 E-commerce typical entities:
+1) User - System users with authentication
+2) Product - Items available for purchase
+3) Category - Product categorization
+4) Cart - Shopping cart items
+5) Order - Customer orders
+6) OrderItem - Individual items in an order
+7) Payment - Payment transactions
+8) Address - Shipping/billing addresses
+9) Review - Product reviews and ratings
+10) Inventory - Stock tracking
+
+📱 SaaS typical entities:
+1) User - System users
+2) Organization - Tenant/workspace
+3) Team - Groups within organizations
+4) Role - Access control roles
+5) Permission - Granular permissions
+6) Subscription - Billing plans
+7) Invoice - Payment records
+8) ApiKey - API access credentials
+9) AuditLog - Activity tracking
+
+📊 CRM typical entities:
+1) User - System users
+2) Contact - Customers/leads
+3) Company - Organizations
+4) Deal - Sales opportunities
+5) Activity - Calls, emails, meetings
+6) Task - To-do items
+7) Note - Free-form notes
+8) Document - Attachments
+
+🎮 Social typical entities:
+1) User - Platform users
+2) Profile - User profiles
+3) Post - Content/publications
+4) Comment - Post comments
+5) Like/Reaction - Engagement
+6) Follow - User connections
+7) Notification - User alerts
+H) Message - Direct messages
+I) Group - Communities
+
+→ Your selection (e.g., A, C, F): __
+
+OR list your custom entities:
+
+1.
+2.
+3.
+4.
+5.
+...
+
+(Include brief description for custom entities)
+```
 
-C) **Domain-driven**
+**2.3 Relationships**
 
-- Group by business domain
-- Example: `screens/user/`, `screens/product/`, `screens/order/`
-- Best for: Large, complex apps
+```
+Common relationship patterns (select what applies to your entities):
 
-D) **Route-based**
+⭐ One-to-Many (most common):
+A) User → Order (one user has many orders)
+B) User → Post (one user creates many posts)
+C) Organization → User (one org has many users)
+D) Category → Product (one category contains many products)
+E) Order → OrderItem (one order has many line items)
+F) Post → Comment (one post has many comments)
+G) Other: __
 
-- Match folder structure to routes
-- Example: `screens/(tabs)/home/`, `screens/(tabs)/profile/`
-- Best for: File-based routing (Expo Router)
+→ Your selection (e.g., A, B, D): __
 
-**Your answer:**
----
-### Question 2.3: Component Organization
+⭐ Many-to-Many (via join table):
+A) Order ↔ Product (via OrderItem)
+B) User ↔ Role (via UserRole)
+E) Course ↔ Student (via Enrollment)
+F) Other: __
 
-**How will you organize your components?**
+→ Your selection (e.g., A, C, E): __
 
-A) ⭐ **Atomic Design** (Recommended)
+⭐ One-to-One (less common):
 
-- atoms/, molecules/, organisms/, templates/
-- Best for: Design system consistency
+⭐ One-to-One (less common):
+C) Order → Payment (one order has one payment)
+D) Other: __
 
-B) **Feature-based Components**
+→ Your selection (e.g., A, B): __
 
-- components/ shared across features
-- features/[feature]/components/ for feature-specific
-- Best for: Feature isolation
+⭐ Polymorphic (one entity relates to multiple types):
+C) Activity → (User | Organization | Deal) - activities linked to various objects
+D) Other: __
 
-C) **Flat Structure**
+→ Your selection (e.g., A, C): __
+---
+Your specific relationships (list main ones):
+---
+Your specific relationships (list main ones):
+-
+-
+-
 
-- All components in components/
-- Best for: Small apps
+(Format: EntityA → EntityB: Relationship type - description)
+```
 
-D) **Type-based**
+**2.4 Data Volume Estimates**
 
-- components/buttons/, components/cards/, components/forms/
-- Best for: Component library approach
+```
+Estimated data volume (Year 1):
 
-**Your answer:**
----
-### Question 2.4: Architecture Pattern
+- Total records: [Low (<10k) / Medium (10k-1M) / High (>1M)]
+- Growth rate: [Slow / Moderate / Fast]
 
-**What architecture pattern will you follow?**
+Data Complexity (Record Size):
+A) 📄 Low - Mostly text data (JSON, strings)
+B) 🖼️ Medium - Some images/documents (blobs, small files)
+C) 🎥 High - Heavy media/large files (video, audio, raw data)
 
-A) ⭐ **Feature-based Architecture** (Recommended)
+⭐ Standard for MVP:
+- Records: Low (<10k)
+- Growth: Moderate
+- Complexity: Low (mostly text)
 
-- Each feature is self-contained
-- Example: features/auth/, features/home/
-- Best for: Most React Native/Flutter apps
+🏆 Standard for Production/Scale:
+- Records: High (>1M)
+- Growth: Fast
+- Complexity: Medium/High (includes media/files)
+```
 
-B) 🔥 **Clean Architecture** (Popular)
+**2.5 Data Retention**
 
-- Separation: Presentation / Domain / Data layers
-- Best for: Complex apps, testability
+```
+Data retention policies:
 
-C) **MVVM (Model-View-ViewModel)**
+A) ♾️ Keep forever - Never delete data
+B) 🗓️ Regulatory compliance - Specific retention period (e.g., 7 years)
+C) 🔄 Archival strategy - Archive old data after __ months
+D) 🗑️ Auto-deletion - Delete after __ days/months
 
-- Common in Flutter and Native
-- Best for: State-heavy apps
+For each entity that has special retention needs, specify:
+```
 
-D) **MVI (Model-View-Intent)**
+**2.6 Data Migration**
 
-- Unidirectional data flow
-- Best for: Predictable state management
+```
+Is this a new system or replacing an existing one?
 
-E) **Simple (No strict pattern)**
+A) 🆕 New system - No legacy data
+B) 🔄 Replacing existing - Need to migrate from [system name]
+C) 🔌 Integration - Syncing with existing system
 
-- Organize as needed
-- Best for: Small apps, MVPs
+If migration needed:
+- Source system: __
+- Data volume to migrate: __
+- Migration strategy: [Big bang / Phased / Parallel run]
+```
 
-**Your answer:**
----
-### Question 2.5: Folder Structure
+**2.7 Critical Data Patterns**
 
-**What folder structure will you use?**
+```
+Select data patterns that apply:
+
+A) 🔐 Soft deletes - Keep deleted records with deleted_at flag
+B) 📝 Audit trail - Track who changed what and when
+C) 🕐 Temporal data - Track historical versions
+D) 🌍 Multi-tenancy - Data isolation per customer/organization
+E) 🎭 Polymorphic relationships - One entity relates to multiple types
+F) 🔗 Graph relationships - Complex many-to-many networks
+G) 📊 Aggregations/Materialized views - Pre-computed summaries
+H) 🗂️ Partitioning - Split large tables by date/region/etc.
+
+For each selected, provide brief detail:
+```
 
-**Example for Feature-based:**
+**2.7.1 Soft Delete Configuration** (if A selected above)
 
 ```
-src/
-├── features/
-│   ├── auth/
-│   │   ├── screens/
-│   │   ├── components/
-│   │   ├── hooks/
-│   │   └── store/
-│   ├── home/
-│   └── profile/
-├── components/ (shared)
-├── navigation/
-├── services/
-├── utils/
-└── types/
+How will you handle data deletion?
+
+Field for soft delete:
+A) ⭐ deleted_at (timestamp, null = active) - Recommended
+B) is_deleted (boolean)
+C) status field (e.g., status = 'deleted')
+D) Custom: __
+
+Entities with SOFT delete (keep record, mark as deleted):
+- Users ✅
+- Orders ✅
+- Products ✅
+- [List yours...]
+
+Entities with HARD delete (permanent removal):
+- Session tokens
+- Temporary files
+- Cart items after checkout
+- [List yours...]
+
+Permanent cleanup policy:
+A) ⭐ Purge soft-deleted after __ days (recommended: 90)
+B) Archive to cold storage after __ days
+C) Never delete (compliance requirement)
+
+Default query behavior:
+A) ⭐ Exclude deleted by default (add scope/filter)
+B) Include all, filter explicitly
 ```
 
-**Example for Clean Architecture:**
+**2.7.2 State Machines** (for entities with lifecycle states)
 
 ```
-lib/
-├── presentation/
-│   ├── pages/
-│   ├── widgets/
-│   └── providers/
-├── domain/
-│   ├── entities/
-│   ├── repositories/
-│   └── usecases/
-└── data/
-    ├── models/
-    ├── repositories/
-    └── datasources/
-```
+Do any entities have defined state lifecycles?
+
+A) ⭐ Yes - Define state machines
+B) No - Simple status fields without transitions
 
-**Your preference:** (Describe or select from examples)
----
-### Question 2.6: Navigation Library
+If yes, define for each entity:
 
-**Which navigation library will you use?**
+---
+Entity: Order (example)
+States: [draft, pending, confirmed, shipped, delivered, cancelled, refunded]
 
-**If React Native:**
+Valid Transitions:
+- draft → pending (action: submit)
+- pending → confirmed (action: pay) [requires: payment_id]
+- pending → cancelled (action: cancel, or timeout: 24h)
+- confirmed → shipped (action: ship) [requires: tracking_number]
+- shipped → delivered (action: deliver)
+- confirmed → refunded (action: refund)
+- delivered → refunded (action: refund) [within: 30 days]
 
-- A) ⭐ **React Navigation** (Recommended)
-  - Most popular, well-maintained
-  - Works with Expo and bare React Native
-  - Version: 6.x
+Invalid Transitions (explicitly forbidden):
+- shipped → cancelled (cannot cancel after shipping)
+- delivered → cancelled
 
-- B) **React Native Navigation** (Wix)
-  - Native navigation, better performance
-  - Requires native setup
-  - Best for: Performance-critical apps
+Side Effects:
+- pending → confirmed: send confirmation email, reserve inventory
+- confirmed → cancelled: release inventory, refund payment
+- shipped → delivered: send delivery notification
+---
 
-**If Flutter:**
+Your state machines:
 
-- A) ⭐ **GoRouter** (Recommended)
-  - Declarative, type-safe
-  - Best for: Modern Flutter apps
+Entity: __
+States: __
+Transitions: __
+```
 
-- B) **AutoRoute**
-  - Code generation
-  - Best for: Complex routing
+**2.7.1 Domain-Driven Design Concepts** (Production-Ready and Enterprise only)
+
+```
+Will you use Domain-Driven Design (DDD) patterns?
+
+A) ⭐ Yes - Using DDD tactical patterns
+   - Aggregate Roots for transactional boundaries
+   - Value Objects for immutable data
+   - Domain Events for decoupling
+
+B) 🔥 Partial - Only Aggregate Roots
+   - Define aggregate roots for complex domains
+   - Keep entities grouped by aggregate
+
+C) No - Simple CRUD patterns
+   - Standard entity relationships
+   - No aggregate boundaries
+
+If using DDD (A or B):
+
+What are your Aggregate Roots?
+(Aggregate roots are the entry points to groups of related entities)
+
+Examples:
+- Order (with OrderItems, Shipping, Payment)
+- User (with Profile, Preferences, Settings)
+- Project (with Tasks, Members, Files)
+
+Your Aggregate Roots:
+1. __ (contains: __)
+2. __ (contains: __)
+3. __ (contains: __)
+
+Domain Events (things that happen in your domain):
+- UserRegistered
+- OrderPlaced
+- PaymentCompleted
+- etc.
+
+Your key domain events:
+1.
+2.
+3.
+```
 
-**Your answer:**
----
-### Question 2.7: Deep Linking Strategy
+**2.7.4 Transaction Boundaries**
 
-**How will you handle deep links?**
+```
+Which operations require database transactions?
+
+List operations that must be atomic (all-or-nothing):
+
+1. User Registration:
+   - Create User record
+   - Create Profile record
+   - Send welcome email (queue, not in transaction)
+   → Rollback if: User or Profile creation fails
+
+2. Order Creation:
+   - Create Order record
+   - Create OrderItems
+   - Reserve inventory
+   - Charge payment
+   → Rollback if: Any step fails
+
+3. [Your operations]:
+   - Step 1
+   - Step 2
+   → Rollback if: __
+
+Your transactional operations:
+1.
+2.
+3.
+```
 
-A) ⭐ **Universal Links (iOS) + App Links (Android)** (Recommended)
+**2.8 Database Indexes**
 
-- Standard deep linking
-- Opens app directly
-- Best for: Most apps
+```
+What indexes will you need for performance optimization?
 
-B) **Custom URL Scheme**
+Indexes are critical for query performance. Based on your entities and relationships, consider:
 
-- myapp://path/to/screen
-- Simpler but less secure
-- Best for: Internal links
+Common indexes needed:
+A) Foreign keys (automatically indexed by most ORMs)
+B) Frequently queried columns (email, username, status)
+C) Columns used in WHERE clauses
+D) Columns used in JOIN conditions
+E) Columns used in ORDER BY clauses
+F) Composite indexes for multi-column queries
 
-C) **No Deep Linking**
+→ Your selection (e.g., A, B, C, D): __
 
-- App only, no external links
-- Best for: Standalone apps
+Do you have specific query patterns that need optimization?
 
-**Your answer:**
+Example:
+- User lookup by email: Index on users.email
+- Order search by date range: Index on orders.created_at
+- Product search by category and status: Composite index on (category_id, status)
 
-**If deep linking selected, ask:**
+Your specific indexes:
+1.
+2.
+3.
+```
 
-- What URL scheme? (e.g., `myapp://`, `https://myapp.com`)
-- What screens need deep links? (e.g., product details, user profiles)
----
-### Question 2.8: Navigation State Management
+**2.9 Transaction Management**
 
-**How will you manage navigation state?**
+```
+What transaction isolation level will you use?
 
-A) ⭐ **Navigation Library Built-in** (Recommended)
+A) ⭐ READ COMMITTED - Recommended default (PostgreSQL, MySQL default)
+   - Prevents dirty reads
+   - Allows non-repeatable reads and phantom reads
+   - Good balance of consistency and performance
 
-- React Navigation manages its own state
-- Flutter Navigator manages its own state
-- Best for: Most apps
+B) READ UNCOMMITTED - Lowest isolation (rarely used)
+   - Allows dirty reads
+   - Fastest but least safe
 
-B) **Redux / State Management Library**
+C) REPEATABLE READ - Higher isolation
+   - Prevents dirty reads and non-repeatable reads
+   - May have phantom reads
+   - Better consistency, slightly slower
 
-- Centralized navigation state
-- Best for: Complex navigation flows
+D) 🏆 SERIALIZABLE - Highest isolation (Enterprise)
+   - Prevents all concurrency issues
+   - Slowest but safest
+   - Use only when absolutely necessary
 
-C) **Custom State Management**
+Your choice: __
 
-- Your own navigation state
-- Best for: Advanced use cases
+Consistency model:
+A) ⭐ Strong consistency - All reads see latest writes (most backends)
+B) Eventual consistency - Acceptable delay for better performance (distributed systems)
 
-**Your answer:**
----
-### Question 2.9: Screen Transitions
+If eventual consistency:
+- Acceptable delay: __ seconds/minutes
+- Conflict resolution strategy: __
+```
 
-**What screen transition animations will you use?**
+**2.10 Schema Migrations**
 
-A) ⭐ **Default Transitions** (Recommended)
+```
+What migration tool will you use?
+
+A) ⭐ Prisma Migrate (if using Prisma)
+B) TypeORM Migrations (if using TypeORM)
+C) Alembic (Python/SQLAlchemy)
+D) Flyway (Java/Universal)
+E) Liquibase (Java/Universal)
+F) Django Migrations (Django)
+G) Laravel Migrations (Laravel)
+H) Rails Migrations (Ruby on Rails)
+I) Other: __
+
+Migration strategy:
+A) ⭐ Versioned migrations - Each change creates a new migration file
+B) Auto-migrations - Tool generates migrations automatically
+C) Manual SQL scripts - Write migrations manually
+
+Zero-downtime migrations:
+A) ⭐ Yes - Plan for zero-downtime migrations (Production-Ready/Enterprise)
+B) No - Accept maintenance windows (MVP)
+
+If zero-downtime:
+- Strategy: [Expand/Contract, Blue-Green, etc.]
+- Rollback plan: __
+```
 
-- Platform-native transitions
-- iOS: Slide from right
-- Android: Slide up/fade
-- Best for: Most apps
+### Phase 2 Output
 
-B) **Custom Transitions**
+```
+📋 PHASE 2 SUMMARY:
+
+Database: [type(s)]
+Core Entities: [list with descriptions]
+Relationships: [key relationships]
+Data Volume: [estimates]
+Retention: [policies]
+Migration: [strategy if applicable]
+Data Patterns: [selected patterns with brief details]
+Database Indexes: [list of indexes needed]
+Transaction Isolation: [level + consistency model]
+Schema Migrations: [tool + strategy + zero-downtime approach]
+
+Is this correct? (Yes/No)
+```
 
-- Fade, scale, slide custom directions
-- Best for: Branded experience
+---
 
-C) **No Animations**
+### 📄 Generate Phase 2 Documents
 
-- Instant transitions
-- Best for: Performance-critical apps
+**Before starting generation:**
 
-**Your answer:**
----
-### Question 2.10: Navigation Guards / Authentication Flow
+```
+📖 Loading context from previous phases...
+✅ Re-reading project-brief.md
+```
 
-**How will you handle protected routes?**
+**Generate `docs/data-model.md` automatically:**
 
-A) ⭐ **Navigation Guards** (Recommended)
+- Use template: `.ai-flow/templates/docs/data-model.template.md`
+- Fill with all Phase 2 entity and relationship information
+- Include entity catalog, relationships, data patterns
+- Generate entity-relationship diagram (ER diagram) in mermaid format showing all entities and their relationships
+- Write to: `docs/data-model.md`
 
-- Check auth state before navigation
-- Redirect to login if not authenticated
-- Best for: Most apps
+---
 
-B) **Separate Navigation Stacks**
+#### 🎨 MERMAID ER DIAGRAM FORMAT - CRITICAL
 
-- Auth stack vs App stack
-- Switch between stacks based on auth state
-- Best for: Clear separation
+> 📎 **Reference:** See [prompts/shared/mermaid-guidelines.md](../shared/mermaid-guidelines.md) for ER diagram syntax, relationship notation, and common mistakes.
 
-C) **No Protection**
+## **Example ER Diagram:**
 
-- All screens accessible
-- Handle auth in components
-- Best for: Simple apps
+```
+✅ Generated: docs/data-model.md
 
-**Your answer:**
----
-#### 🎨 MERMAID NAVIGATION DIAGRAM FORMATS - CRITICAL
+Document has been created with all Phase 2 information.
 
-**Use these exact formats** for mobile navigation diagrams:
----
-##### 1️⃣ Navigation Structure (Tab + Stack Pattern)
+📝 Would you like to make any corrections before continuing?
 
-Use `graph TD` to show navigation hierarchy:
+→ If yes: Edit docs/data-model.md and type "ready" when done. I'll re-read it.
+→ If no: Type "continue" to proceed to Phase 3.
+```
 
-```mermaid
-graph TD
-    subgraph "App Navigation"
-        ROOT[Root Navigator]
-    end
+**If user edits the file:**
+Execute `read_file('docs/data-model.md')` to refresh context before continuing.
 
-    subgraph "Tab Navigator"
-        TAB1[Home Tab]
-        TAB2[Search Tab]
-        TAB3[Profile Tab]
-        TAB4[Settings Tab]
-    end
+---
 
-    subgraph "Stack Navigators"
-        subgraph "Home Stack"
-            H1[Home Screen]
-            H2[Product Detail]
-            H3[Cart]
-            H4[Checkout]
-        end
+> ⚠️ **CRITICAL:** DO NOT generate README.md in Phase 2. README.md is ONLY generated in Phase 8 (step 8.5) after framework initialization.
 
-        subgraph "Search Stack"
-            S1[Search Screen]
-            S2[Results]
-            S3[Filter]
-        end
+---
 
-        subgraph "Profile Stack"
-            P1[Profile Screen]
-            P2[Edit Profile]
-            P3[Orders History]
-        end
-    end
-
-    ROOT --> TAB1
-    ROOT --> TAB2
-    ROOT --> TAB3
-    ROOT --> TAB4
-
-    TAB1 --> H1
-    H1 --> H2
-    H2 --> H3
-    H3 --> H4
-
-    TAB2 --> S1
-    S1 --> S2
-    S2 --> S3
-
-    TAB3 --> P1
-    P1 --> P2
-    P1 --> P3
-
-    style ROOT fill:#e3f2fd
-    style TAB1 fill:#e1f5ff
-    style TAB2 fill:#e1f5ff
-    style TAB3 fill:#e1f5ff
-    style TAB4 fill:#e1f5ff
-    style H1 fill:#fff4e6
-    style S1 fill:#fff4e6
-    style P1 fill:#fff4e6
-```
-
-**Use for:** Tab-based apps with nested stacks (Instagram, Twitter pattern)
----
-##### 2️⃣ Authentication Flow
-
-Use `graph LR` to show auth-protected navigation:
-
-```mermaid
-graph LR
-    subgraph "Unauthenticated"
-        SPLASH[Splash Screen]
-        ONBOARD[Onboarding]
-        LOGIN[Login Screen]
-        REGISTER[Register Screen]
-    end
-
-    subgraph "Authenticated"
-        MAIN[Main App<br/>Tab Navigator]
-        HOME[Home]
-        PROFILE[Profile]
-    end
-
-    SPLASH -->|First Launch| ONBOARD
-    SPLASH -->|Returning User| CHECK{Authenticated?}
-    ONBOARD --> LOGIN
-    LOGIN --> REGISTER
-    LOGIN -->|Success| MAIN
-    REGISTER -->|Success| MAIN
-
-    CHECK -->|Yes| MAIN
-    CHECK -->|No| LOGIN
-
-    MAIN --> HOME
-    MAIN --> PROFILE
-
-    style SPLASH fill:#e3f2fd
-    style CHECK fill:#fff9c4
-    style MAIN fill:#e8f5e9
-    style LOGIN fill:#fce4ec
-    style REGISTER fill:#fce4ec
-```
-
-**Use for:** Apps with authentication/onboarding flows
----
-##### 3️⃣ Deep Linking Routes
-
-Use `graph TD` to show deep link structure:
-
-```mermaid
-graph TD
-    subgraph "Deep Link Routes"
-        ROOT[myapp://]
-    end
-
-    subgraph "Public Routes"
-        PRODUCT[/product/:id]
-        CATEGORY[/category/:slug]
-        PROMO[/promo/:code]
-    end
-
-    subgraph "Protected Routes"
-        ORDER[/order/:id<br/>⚠️ Auth Required]
-        PROFILE_VIEW[/profile/:userId<br/>⚠️ Auth Required]
-    end
-
-    ROOT --> PRODUCT
-    ROOT --> CATEGORY
-    ROOT --> PROMO
-    ROOT --> ORDER
-    ROOT --> PROFILE_VIEW
-
-    PRODUCT -->|Opens| PD[Product Detail Screen]
-    CATEGORY -->|Opens| CL[Category List Screen]
-    ORDER -->|Opens| OD[Order Detail Screen]
-
-    style ROOT fill:#e3f2fd
-    style PRODUCT fill:#e8f5e9
-    style CATEGORY fill:#e8f5e9
-    style PROMO fill:#e8f5e9
-    style ORDER fill:#fce4ec
-    style PROFILE_VIEW fill:#fce4ec
-```
-
-**Use for:** Apps with universal links/app links
----
-##### 4️⃣ Screen Hierarchy (Feature-based)
-
-Use `graph TB` to show folder/screen organization:
-
-```mermaid
-graph TB
-    subgraph "Mobile App Structure"
-        subgraph "screens/"
-            subgraph "auth/"
-                A1[LoginScreen.tsx]
-                A2[RegisterScreen.tsx]
-                A3[ForgotPasswordScreen.tsx]
-            end
-
-            subgraph "home/"
-                H1[HomeScreen.tsx]
-                H2[ProductDetailScreen.tsx]
-            end
-
-            subgraph "profile/"
-                P1[ProfileScreen.tsx]
-                P2[EditProfileScreen.tsx]
-                P3[OrdersScreen.tsx]
-            end
-        end
-
-        subgraph "navigation/"
-            NAV[RootNavigator.tsx]
-            TAB[TabNavigator.tsx]
-            STACK[StackNavigators.tsx]
-        end
-    end
-
-    NAV --> TAB
-    TAB --> STACK
-    STACK -.-> H1
-    STACK -.-> P1
-    STACK -.-> A1
-
-    style NAV fill:#e3f2fd
-    style TAB fill:#e1f5ff
-    style STACK fill:#fff4e6
-```
-
-**Use for:** Documenting folder structure and file organization
----
-**Diagram Guidelines:**
-
-- Color code by level (Root=light blue, Tabs=blue, Stacks=orange, Screens=default)
-- Use subgraphs to group related screens
-- Show authentication checks with decision diamonds
-- Include deep link routes with ⚠️ for protected routes
-- Update screen names based on actual app structure
----
-## ✅ Phase 2 Completion
-
-After answering all questions, summarize:
-
-```
----
-✅ Phase 2 Complete: Navigation & Architecture
----
-Selected Architecture:
-- Navigation: Tab + Stack Navigation
-- Library: React Navigation 6.0
-- Architecture: Feature-based
-- Component Organization: Atomic Design
-- Folder Structure: Feature-based
-- Deep Linking: Universal Links + App Links
-- Auth Flow: Navigation Guards
-
-Proceed to Phase 3 (State & Data Management)? (Y/n)
-```
----
 ## 📝 Generated Documents
 
 After Phase 2, generate/update:
+- `docs/data-model.md` - Database schema and entity relationships
 
-- `docs/navigation.md` - Navigation patterns and setup guide
-- `docs/architecture.md` - System architecture overview
-- `ai-instructions.md` - Add navigation and architecture rules
----
-**Next Phase:** Phase 3 - State & Data Management
+---
 
-Read: `.ai-flow/prompts/mobile/flow-build-phase-3-state.md`
----
-**Last Updated:** 2025-01-XX
+**Next Phase:** Phase 3 - System Architecture (15-20 min)
 
-**Version:** 1.4.0
+Read: `.ai-flow/prompts/backend/flow-build-phase-3.md`
 
+---
 
+**Last Updated:** 2025-12-20
+**Version:** 2.1.8
 
+---
 
+## PHASE 3: System Architecture (15-20 min)