diff --git a/internal/launchpad/assets/diagrams/diagrams-config.json b/internal/launchpad/assets/diagrams/diagrams-config.json
index 61561eaf..2644041f 100644
--- a/internal/launchpad/assets/diagrams/diagrams-config.json
+++ b/internal/launchpad/assets/diagrams/diagrams-config.json
@@ -59,66 +59,6 @@
     "type": "mermaid",
     "icon": "bi-geo-alt"
   },
-  {
-    "path": "assets/diagrams/legacy/staff-mobile-application/overview.mermaid",
-    "title": "Legacy App Overview",
-    "type": "mermaid",
-    "icon": "bi-phone"
-  },
-  {
-    "path": "assets/diagrams/legacy/staff-mobile-application/use-case-flowchart.mermaid",
-    "title": "Legacy App Use Cases",
-    "type": "mermaid",
-    "icon": "bi-diagram-2"
-  },
-  {
-    "path": "assets/diagrams/legacy/staff-mobile-application/api-map.mermaid",
-    "title": "Legacy App API Map",
-    "type": "mermaid",
-    "icon": "bi-phone"
-  },
-  {
-    "path": "assets/diagrams/legacy/staff-mobile-application/use-case-flows.mermaid",
-    "title": "Legacy App Use Cases BE Chart",
-    "type": "mermaid",
-    "icon": "bi-diagram-2"
-  },
-  {
-    "path": "assets/diagrams/legacy/staff-mobile-application/backend-architecture.mermaid",
-    "title": "Legacy App Backend Architecture",
-    "type": "mermaid",
-    "icon": "bi-diagram-2"
-  },
-  {
-    "path": "assets/diagrams/legacy/client-mobile-application/overview.mermaid",
-    "title": "Legacy App Overview",
-    "type": "mermaid",
-    "icon": "bi-phone"
-  },
-  {
-    "path": "assets/diagrams/legacy/client-mobile-application/use-case-flowchart.mermaid",
-    "title": "Legacy App Use Cases",
-    "type": "mermaid",
-    "icon": "bi-diagram-2"
-  },
-  {
-    "path": "assets/diagrams/legacy/client-mobile-application/api-map.mermaid",
-    "title": "Legacy App API Map",
-    "type": "mermaid",
-    "icon": "bi-phone"
-  },
-  {
-    "path": "assets/diagrams/legacy/client-mobile-application/use-case-flows.mermaid",
-    "title": "Legacy App Use Cases BE Chart",
-    "type": "mermaid",
-    "icon": "bi-diagram-2"
-  },
-  {
-    "path": "assets/diagrams/legacy/client-mobile-application/backend-architecture.mermaid",
-    "title": "Legacy App Backend Architecture",
-    "type": "mermaid",
-    "icon": "bi-diagram-2"
-  },
   {
     "path": "assets/diagrams/dataconnect/uml/user_uml_diagram.mmd",
     "title": "User UML Diagram Dataconnect",
diff --git a/internal/launchpad/assets/documents/documents-config.json b/internal/launchpad/assets/documents/documents-config.json
index 54532b03..46a80b01 100644
--- a/internal/launchpad/assets/documents/documents-config.json
+++ b/internal/launchpad/assets/documents/documents-config.json
@@ -1,4 +1,8 @@
 [
+  {
+    "title": "System Bible",
+    "path": "./assets/documents/legacy/system-bible.md"
+  },
   {
     "title": "Architecture Overview",
     "path": "./assets/documents/legacy/architecture.md"
@@ -27,6 +31,38 @@
     "title": "Use Case Documentation",
     "path": "./assets/documents/legacy/web-application/use-case.md"
   },
+  {
+    "title": "System Bible",
+    "path": "./assets/documents/prototype/system-bible.md"
+  },
+  {
+    "title": "Architecture Overview",
+    "path": "./assets/documents/prototype/architecture.md"
+  },
+  {
+    "title": "Architecture Overview",
+    "path": "./assets/documents/prototype/staff-mobile-application/architecture.md"
+  },
+  {
+    "title": "Use Case Overview",
+    "path": "./assets/documents/prototype/staff-mobile-application/use-case.md"
+  },
+  {
+    "title": "Architecture Overview",
+    "path": "./assets/documents/prototype/client-mobile-application/architecture.md"
+  },
+  {
+    "title": "Use Case Overview",
+    "path": "./assets/documents/prototype/client-mobile-application/use-case.md"
+  },
+  {
+    "title": "Architecture Overview",
+    "path": "./assets/documents/prototype/web-application/architecture.md"
+  },
+  {
+    "title": "Use Case Overview",
+    "path": "./assets/documents/prototype/web-application/use-case.md"
+  },
   {
     "title": "Dataconnect guide",
     "path": "./assets/documents/dataconnect/backend_manual.md"
diff --git a/internal/launchpad/assets/documents/legacy/system-bible.md b/internal/launchpad/assets/documents/legacy/system-bible.md
new file mode 100644
index 00000000..5da979d9
--- /dev/null
+++ b/internal/launchpad/assets/documents/legacy/system-bible.md
@@ -0,0 +1,235 @@
+# Krow Legacy Ecosystem: System Bible
+
+**Status:** Official System Constitution
+**Version:** 1.0.0
+**Date:** 2026-02-06
+**Scope:** Krow Legacy Ecosystem (Client App, Staff App, Web Platform)
+
+---
+
+## 1. Executive Summary
+
+The **Krow Legacy Ecosystem** is a comprehensive digital marketplace designed to revolutionize the temporary staffing industry. It eliminates the friction of traditional agencies by directly connecting **businesses** (restaurants, event organizers) with **temporary workers** (wait staff, security, chefs) through a unified, automated platform.
+
+**Why It Exists:**
+The traditional staffing model is slow, opaque, and manual (spreadsheets, phone calls). This ecosystem digitizes the entire lifecycle—from finding staff and verifying their skills to tracking attendance and processing payments—creating a transparent, efficient market for flexible work.
+
+**Who It Serves:**
+1.  **Business Owners ("Clients"):** Who need on-demand, vetted staff without the administrative burden.
+2.  **Workers ("Staff"):** Who seek flexible shifts, instant access to job opportunities, and reliable payment.
+3.  **Operations Teams:** Who manage the marketplace, ensuring quality, compliance, and dispute resolution.
+
+**Value Proposition:**
+"A trusted, transparent, and real-time workforce marketplace where businesses get reliability and workers get flexibility, powered by a single source of truth."
+
+---
+
+## 2. System Vision & Product Principles
+
+### Core Goals
+1.  **Frictionless Connection:** Reduce the time to fill a shift from days to minutes.
+2.  **Trust through Transparency:** Both sides (Client and Staff) must have total visibility into profiles, ratings, and attendance.
+3.  **Operational Excellence:** Automate low-value tasks (invoicing, timesheets) so humans can focus on high-value tasks (quality assurance, service).
+
+### Product Principles
+*   **Mobile-First for Users:** The primary interaction point for Clients and Staff is their phone. The experience must be fast, intuitive, and resilient to poor network conditions.
+*   **Centralized Truth:** Business logic lives on the Server, not the Client. Mobile apps are "smart viewers" but never the final authority.
+*   **Compliance is Mandatory:** The system must strictly enforce legal and operational requirements (e.g., "No uniform, no work").
+*   **Offline Resilience:** Staff must be able to perform critical actions (Clock In/Out) even in basements or fields with no signal.
+
+### What We Solve vs. What We Don't
+*   **WE SOLVE:** Shift discovery, booking, attendance verification, invoicing, and payout calculation.
+*   **WE DO NOT SOLVE:** Direct employment contracts (staff are independent contractors or agency employees), specialized tax advice, or instant banking transfers (we facilitate, we don't hold funds).
+
+---
+
+## 3. Ecosystem Overview
+
+The ecosystem is composed of three distinct applications that function as a single organic unit.
+
+| Application | Name | Primary User | Platform | Core Responsibility |
+| :--- | :--- | :--- | :--- | :--- |
+| **1. Client App** | `pineDev_krow-mobile-client-app` | Business Owners | Mobile (Flutter) | **Demand Generation.** Posting shifts, managing venues, verifying staff presence. |
+| **2. Staff App** | `pineDev_krow-mobile-staff-app` | Temporary Workers | Mobile (Flutter) | **Supply Fulfilment.** Finding work, proving compliance, executing shifts. |
+| **3. Web Platform** | `pineDev_legendary-web-app` | Admin / System | Web (Laravel) | **The Brain.** Marketplace orchestration, data storage, financial processing, admin control. |
+
+**Conceptual Fit:**
+Imagine a ride-sharing service. The **Client App** is the passenger requesting a ride. The **Staff App** is the driver accepting the ride. The **Web Platform** is the dispatch center managing the map, prices, and safety.
+
+---
+
+## 4. System Architecture Overview
+
+The system follows a **Hub-and-Spoke** architecture. The Web Platform is the central Hub; the mobile applications are the Spokes.
+
+### Architecture Style
+*   **Monolithic Backend / Smart Mobile Clients:** We utilize a robust, monolithic backend (Laravel) to ensure data integrity and simplified deployment, coupled with rich mobile clients (Flutter) that handle UI/UX complexity.
+*   **GraphQL Communication:** All apps communicate via a strictly typed GraphQL API. This decoupling allows mobile apps to evolve their UI without constantly requiring backend changes.
+
+### System Boundaries
+*   **Network Boundary:** The Mobile Apps communicate over the public internet to the Web Platform's API Gateway.
+*   **Security Boundary:** Authentication (Firebase) happens at the edge. No request passes to the core logic without a valid identity token.
+*   **Data Boundary:** Mobile apps cache data but own nothing. The Database behind the Web Platform is the only permanent record.
+
+### Architecture Diagram
+
+```mermaid
+flowchart TD
+    %% Define Styles
+    classDef clientApp fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1
+    classDef staffApp fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#bf360c
+    classDef backend fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20
+    classDef db fill:#eee,stroke:#333,stroke-width:2px,color:#333
+    classDef external fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#4a148c
+
+    subgraph Mobile_Apps["Mobile Ecosystem"]
+        direction TB
+        ClientApp["Client App<br/>(Business)"]:::clientApp
+        StaffApp["Staff App<br/>(Workers)"]:::staffApp
+    end
+
+    subgraph Core_Platform["Krow Web Platform"]
+        direction TB
+        AdminPanel["Admin Dashboard<br/>(Laravel Nova)"]:::backend
+        APIServer["GraphQL API<br/>(Laravel Lighthouse)"]:::backend
+        Database[("Central Database<br/>(PostgreSQL)")]:::db
+    end
+
+    subgraph External_Services["Cloud Services"]
+        direction TB
+        Firebase["Firebase<br/>(Auth/Push)"]:::external
+        Maps["Google Maps<br/>(Location)"]:::external
+    end
+
+    %% Communication Flows
+    ClientApp <-->|GraphQL| APIServer
+    StaffApp <-->|GraphQL| APIServer
+    AdminPanel <-->|Internal| APIServer
+    APIServer <-->|SQL| Database
+    Mobile_Apps -.->|Auth| Firebase
+    Mobile_Apps -.->|Location| Maps
+```
+
+---
+
+## 5. Application Responsibility Matrix
+
+This matrix prevents "logic creep" where business rules accidentally migrate into the mobile apps.
+
+| Feature Domain | Client App | Staff App | Web Platform (Backend) |
+| :--- | :--- | :--- | :--- |
+| **User Accounts** | Sign In / Profile Edit | Sign In / Profile Edit | **MASTER RECORD.** Validation, Ban/Approve. |
+| **Events/Shifts** | **CREATE / EDIT.** Define needs. | **READ / ACCEPT.** Browse & Book. | **VALIDATE.** Ensure availability, match skills. |
+| **Staff Selection** | View assigned staff. | N/A | Match algorithms, Notification triggers. |
+| **Attendance** | View status, Manual Override. | **EXECUTE.** QR Scan / Check-in. | **VERIFY.** Validate Time & Geolocation. |
+| **Payments** | View Invoices, Pay. | View Earnings. | **CALCULATE.** Rates * Hours + Tax + Fees. |
+| **Notifications** | Receive alerts. | Receive alerts. | **DISPATCH.** Decide who gets alerted and when. |
+| **Compliance** | N/A | Upload Docs, Complete Checklists. | **AUDIT.** Verify docs, enforce expiry rules. |
+
+**Crucial Rule:** Mobile Apps **DISPLAY** and **REQUEST**. The Web Platform **DECIDES** and **COMMITS**.
+
+---
+
+## 6. Use Cases (Core Canon)
+
+These are the officially recognized system workflows.
+
+### Group A: Onboarding & Identity
+*   **UC-01: Staff Registration & Verification** (Staff App -> Web Platform)
+    *   Staff signs up, uploads docs. Web Platform holds status as "Pending" until Admin approves.
+*   **UC-02: Client Business Setup** (Client App -> Web Platform)
+    *   Client creates account, defines venues (Hubs). Web Platform validates addresses via Maps.
+
+### Group B: The Marketplace Loop
+*   **UC-03: Shift Creation** (Client App -> Web Platform)
+    *   Client defines role, time, rate. Web Platform publishes to eligible staff.
+*   **UC-04: Shift Discovery & Booking** (Staff App -> Web Platform)
+    *   Staff sees job, accepts it. Web Platform locks the slot and confirms booking.
+
+### Group C: Operational Execution
+*   **UC-05: Pre-Shift Compliance** (Staff App -> Web Platform)
+    *   Staff confirms uniform/tools. App blocks clock-in until done.
+*   **UC-06: Attendance (Clock In/Out)** (Staff App -> Client App -> Web Platform)
+    *   Staff scans Client QR. Platform records timestamp & location. Updates Client view instantly.
+*   **UC-07: Live Monitoring** (Client App -> Web Platform)
+    *   Client sees who is on-site, late, or missing.
+
+### Group D: Finance & Closeout
+*   **UC-08: Ratings & Feedback** (Client App -> Web Platform)
+    *   Client rates staff performance. Platform updates Staff reputation score.
+*   **UC-09: Payroll Calculation** (Web Platform Internal)
+    *   System calculates final pay based on verified hours.
+*   **UC-10: Invoicing** (Web Platform -> Client App)
+    *   System generates PDF invoice. Client views/downloads in app.
+
+---
+
+## 7. Cross-Application Interaction Rules
+
+1.  **No Direct P2P:** The Client App and Staff App **NEVER** talk directly to each other. They communicate exclusively through the Web Platform.
+    *   *Why?* Security and audit trails.
+2.  **QR/NFC Exception:** The only "direct" interaction is the physical scanning of a QR code or NFC tag. This creates a data packet sent to the server, not a direct network connection between phones.
+3.  **Push, Don't Poll:** Apps should not constantly ask "Is there an update?". The Platform sends Push Notifications to trigger a data refresh.
+4.  **Graceful Degradation:** If the Web Platform is unreachable, mobile apps must allow read-only access to cached data (e.g., "My Schedule") but disable write actions (e.g., "Accept Shift").
+
+---
+
+## 8. Data Ownership & Source of Truth
+
+| Data Domain | Source of Truth | Read Access | Write Access |
+| :--- | :--- | :--- | :--- |
+| **Staff Profile** | Web Database | Staff App (Own), Client App (Assigned), Admin | Staff (Draft), Admin (Approve) |
+| **Events/Shifts** | Web Database | Client App (Own), Staff App (Public) | Client (Create), Admin (Override) |
+| **Timesheets** | Web Database | Client & Staff (View) | System (Automated), Admin (Correction) |
+| **Financials** | Web Database | Client (Invoices), Staff (Earnings) | System (Calculated Only) |
+| **Chat/Msgs** | Web Database | Relevant Users | Sender |
+
+**Principle:** "If it isn't in the Web Database, it didn't happen." Local storage on phones is temporary cache only.
+
+---
+
+## 9. Security & Access Model
+
+### Authentication
+*   **Provider:** Firebase Authentication.
+*   **Philosophy:** "Trust but Verify." We trust Firebase to say *who* someone is (Identity). We trust our own database to say *what* they can do (Permissions).
+
+### Authorization (RBAC)
+*   **Role: Client:** Can only see *their* Hubs, *their* Events, and Staff *assigned* to them.
+*   **Role: Staff:** Can only see *public* shifts they qualify for, and *their own* financial data.
+*   **Role: Admin:** Has god-mode access via the Web Panel, audited by logs.
+
+### Trust Boundaries
+*   **Mobile Apps are Untrusted:** We assume the mobile app could be hacked or modified. Therefore, the API validates EVERY request. (e.g., A hacked Staff App sending "I worked 24 hours" will be rejected by server logic).
+
+---
+
+## 10. Non-Negotiables & Guardrails
+
+1.  **No Business Logic in UI:** Flutter widgets must never calculate pay, taxes, or availability. They only display values provided by the API.
+2.  **Strict Typing:** GraphQL schemas must be strictly typed. No `JSON` blobs unless absolutely necessary.
+3.  **English Only:** Code, comments, and database columns must be in English. Localization happens at the UI layer only.
+4.  **Immutable Financials:** Once a shift is "Paid," its record can never be modified, only reversed via a new "Correction" transaction.
+5.  **Location Required:** Clock-in actions MUST include GPS coordinates. If GPS is missing, the action is flagged for review.
+
+---
+
+## 11. Known Constraints & Assumptions
+
+*   **Assumption:** Clients and Staff have smartphones with working cameras (for QR) and GPS.
+*   **Assumption:** Internet connectivity is available for Shift Creation and Booking. (Only Clock-in supports temporary offline mode).
+*   **Constraint:** The system currently handles a single currency per deployment.
+*   **Constraint:** Notifications are "best effort" via Firebase; they are not guaranteed to arrive instantly.
+
+---
+
+## 12. Glossary
+
+*   **Hub:** A physical location or venue owned by a Client (e.g., "Downtown Stadium").
+*   **Shift:** A specific time block requiring a worker (e.g., "Friday 18:00-22:00").
+*   **Position:** A specific role required for a shift (e.g., "Head Waiter").
+*   **Clock-In:** The digital act of starting work, verified by location and time.
+*   **Admin Panel:** The web interface for Krow operations staff.
+*   **Marketplace:** The collection of all open, unassigned shifts visible to staff.
+*   **BLoC:** (Business Logic Component) The code pattern used in the mobile apps to manage state.
+*   **GraphQL:** The data query language used for API communication.
diff --git a/internal/launchpad/assets/documents/prototype/architecture.md b/internal/launchpad/assets/documents/prototype/architecture.md
new file mode 100644
index 00000000..b84f9861
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/architecture.md
@@ -0,0 +1,152 @@
+# Krow Platform: System Architecture Overview
+
+## 1. Executive Summary: The Business Purpose
+The **Krow Platform** is an end-to-end workforce management ecosystem designed to bridge the gap between businesses that need staff ("Clients") and the temporary workers who fill those roles ("Staff").
+
+Traditionally, this process involves phone calls, paper timesheets, and manual payroll. Krow digitizes the entire lifecycle:
+1.  **Finding Work:** Clients post shifts instantly; workers claim them via mobile.
+2.  **Doing Work:** GPS-verified clock-ins and digital timesheets ensure accuracy.
+3.  **Managing Business:** A web dashboard provides analytics, billing, and compliance oversight.
+
+The system's goal is to reduce administrative friction, ensure legal compliance, and optimize labor costs through automation and real-time data.
+
+## 2. The Application Ecosystem
+The platform consists of three distinct applications, each tailored to a specific user group:
+
+### A. Client Mobile App (The "Requester")
+*   **User:** Business Owners, Venue Managers.
+*   **Role:** The demand generator. It allows clients to request staff on the fly, track who is arriving, and approve hours worked.
+*   **Key Value:** Speed and visibility. A manager can fill a sudden "no-show" gap in seconds from their phone.
+
+### B. Staff Mobile App (The "Worker")
+*   **User:** Temporary Staff (Servers, Cooks, Bartenders).
+*   **Role:** The supply pool. It acts as their personal agency, handling job discovery, schedule management, and instant payouts.
+*   **Key Value:** Flexibility and financial security. Workers choose when they work and get paid faster.
+
+### C. Krow Web Application (The "HQ")
+*   **User:** Administrators, HR, Finance, and Client Executives.
+*   **Role:** The command center. It handles the heavy lifting—complex invoicing, vendor management, compliance audits, and strategic data analysis.
+*   **Key Value:** Control and insight. It turns operational data into cost-saving strategies.
+
+## 3. How the Applications Interact
+The three applications do not "talk" directly to each other (e.g., the staff app doesn't send a message directly to the client app). Instead, they all communicate with a central **Shared Backend System** (The "Brain").
+
+*   **Scenario: Filling a Shift**
+    1.  **Client App:** Manager posts a shift for "Friday, 6 PM".
+    2.  **Backend:** Receives the request, validates it, and notifies eligible workers.
+    3.  **Staff App:** Worker sees the notification and taps "Accept".
+    4.  **Backend:** Confirms the match, updates the schedule, and alerts the client.
+    5.  **Web App:** Admin sees the shift status change from "Open" to "Filled" on the live dashboard.
+
+## 4. Shared Services & Infrastructure
+To function as a cohesive unit, the ecosystem relies on several shared foundational services:
+
+*   **Central Database:** The "Single Source of Truth." Whether a worker updates their profile photo on mobile or an admin updates it on the web, the change is saved in one place (Firebase/Firestore) and reflects everywhere instantly.
+*   **Authentication Service:** A unified login system. While users have different roles (Client vs. Staff), the security mechanism verifying their identity is shared.
+*   **Notification Engine:** A centralized service that knows how to reach users—sending push notifications to phones (Mobile Apps) and emails to desktops (Web App).
+*   **Payment Gateway:** A shared financial pipe. It collects money from clients (Credit Card/ACH) and disburses it to workers (Direct Deposit/Instant Pay).
+
+## 5. Data Ownership & Boundaries
+To maintain privacy and organization, data is strictly compartmentalized:
+
+*   **Worker Data:** Owned by the worker but accessible to the platform. Clients can only see limited details (Name, Rating, Skills) of workers assigned to *their* specific shifts. They cannot see a worker's full financial history or assignments with other clients.
+*   **Client Data:** Owned by the business. Workers see only what is necessary to do the job (Location, Dress Code, Supervisor Name). They cannot see the client's internal billing or strategic reports.
+*   **Platform Data:** owned by Krow (Admins). This includes the aggregate data used for "Smart Strategies" and market analysis—e.g., "Average hourly rate for a Bartender in downtown."
+
+## 6. Security & Access Control
+The system operates on a **Role-Based Access Control (RBAC)** model:
+
+*   **Authentication (Who are you?):** Strict verification using email/password or phone/OTP (One-Time Password).
+*   **Authorization (What can you do?):**
+    *   **Staff:** Can *read* job details but *write* only to their own timesheets and profile.
+    *   **Clients:** Can *write* new orders and *read* reports for their own venues only.
+    *   **Admins:** Have "Super User" privileges to view and modify data across the entire system to resolve disputes or manage configurations.
+
+## 7. Inter-Application Dependencies
+While the apps are installed separately, they are operationally dependent:
+
+*   **Dependency A:** The **Client App** cannot function without the **Staff App** users. An order posted by a client is useless if no workers exist to claim it.
+*   **Dependency B:** The **Staff App** relies on the **Web App** for financial processing. A worker can "clock out," but they don't get paid until the backend logic (managed via Web App rules) processes the invoice.
+*   **Dependency C:** All apps depend on the **Backend API**. If the central server goes down, no app can fetch data, effectively pausing the entire operation.
+
+---
+
+# System Overview Diagram
+```mermaid
+flowchart LR
+    subgraph Users [Users]
+        ClientUser((Client Manager))
+        StaffUser((Temporary Worker))
+        AdminUser((Admin / Ops))
+    end
+
+    subgraph FrontEnd [Application Ecosystem]
+        direction TB
+        ClientApp[Client Mobile App]
+        StaffApp[Staff Mobile App]
+        WebApp[Web Management Console]
+    end
+
+    subgraph Backend [Shared Backend Services]
+        direction TB
+        APIGateway[API Gateway]
+        
+        subgraph CoreServices [Core Business Logic]
+            AuthService[Authentication Service]
+            OrderService[Order & Shift Service]
+            WorkerService[Worker Profile Service]
+            FinanceService[Billing & Payroll Service]
+            NotificationEngine[Notification Engine]
+            AnalyticsEngine[Analytics & AI Engine]
+        end
+        
+        Database[("Central Database (Firebase/Firestore)")]
+    end
+
+    subgraph External [External Integrations]
+        PaymentProvider["Payment Gateway (Stripe/Bank)"]
+        MapService[Maps & Geolocation]
+        SMSGateway[SMS / OTP Service]
+    end
+
+    %% User Interactions
+    ClientUser -- Uses --> ClientApp
+    StaffUser -- Uses --> StaffApp
+    AdminUser -- Uses --> WebApp
+
+    %% App to Backend Communication
+    ClientApp -- "Auth, Orders, Timesheets" --> APIGateway
+    StaffApp -- "Auth, Job Claims, Clock-In" --> APIGateway
+    WebApp -- "Auth, Admin, Reports" --> APIGateway
+
+    %% Internal Backend Flow
+    APIGateway --> CoreServices
+    CoreServices --> Database
+    
+    %% Specific Service Interactions
+    AuthService -- "Verifies Identity" --> Database
+    OrderService -- "Matches Shifts" --> Database
+    WorkerService -- "Stores Profiles" --> Database
+    FinanceService -- "Processes Invoices" --> Database
+    AnalyticsEngine -- "Reads Data" --> Database
+
+    %% External Connections
+    AuthService -- "Sends OTP" --> SMSGateway
+    StaffApp -- "Verifies Location" --> MapService
+    FinanceService -- "Processes Payouts" --> PaymentProvider
+    NotificationEngine -- "Push Alerts" --> ClientApp
+    NotificationEngine -- "Push Alerts" --> StaffApp
+
+    %% Styling
+    classDef user fill:#e1f5fe,stroke:#01579b,stroke-width:2px;
+    classDef app fill:#fff9c4,stroke:#fbc02d,stroke-width:2px;
+    classDef backend fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
+    classDef external fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px;
+    classDef db fill:#e0e0e0,stroke:#616161,stroke-width:2px;
+
+    class ClientUser,StaffUser,AdminUser user;
+    class ClientApp,StaffApp,WebApp app;
+    class APIGateway,AuthService,OrderService,WorkerService,FinanceService,NotificationEngine,AnalyticsEngine backend;
+    class PaymentProvider,MapService,SMSGateway external;
+    class Database db;
+```
diff --git a/internal/launchpad/assets/documents/prototype/client-mobile-application/architecture.md b/internal/launchpad/assets/documents/prototype/client-mobile-application/architecture.md
new file mode 100644
index 00000000..f035e224
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/client-mobile-application/architecture.md
@@ -0,0 +1,161 @@
+# Client Mobile Application: Architecture Overview
+
+## 1. Executive Summary
+The **Client Mobile Application** is a specialized tool designed for business owners and managers ("Clients") to effortlessly manage their temporary workforce. It serves as the command center for staffing operations, allowing clients to request new staff, monitor active shifts in real-time, handle billing, and analyze operational performance.
+
+Think of it as the "Uber for Staffing" from the business perspective—providing on-demand access to a workforce, real-time tracking, and administrative control in a pocket-sized interface.
+
+## 2. High-Level Architecture
+The application is built using **Flutter**, a cross-platform framework that allows a single codebase to run natively on both iOS and Android devices.
+
+The architecture follows a **Feature-First Layered approach**. This means the code is organized primarily by the business features (e.g., "Creating an Order," "Viewing Reports") rather than just technical file types. This structure makes the app easier to navigate and maintain as it grows.
+
+At a high level, the system operates in three layers:
+1.  **Presentation Layer (UI):** What the user sees and interacts with (Screens, Buttons, Forms).
+2.  **Logic Layer (State Management):** The "brain" that handles user inputs and decides what to show next (currently managed via Riverpod and local widget state).
+3.  **Data Layer (Infrastructure):** The connection points to the backend database and external services (currently simulated with mock data for the prototype).
+
+## 3. Major Components & Modules
+
+The application is broken down into several key functional modules:
+
+### A. Authentication Module
+*   **Responsibility:** Handles secure user entry into the app.
+*   **Key Features:** `Sign In`, `Sign Up`, and `Get Started` onboarding flows.
+*   **Purpose:** Ensures only authorized business personnel can access sensitive staffing and billing data.
+
+### B. Dashboard & Home Module
+*   **Responsibility:** Provides an immediate "pulse check" of the business's staffing status.
+*   **Key Features:** `Live Activity` feed, `Spending Insights`, `Today's Coverage` summary, and `Quick Actions` for common tasks.
+*   **Purpose:** Gives managers the critical info they need within seconds of opening the app.
+
+### C. Order Management Module
+*   **Responsibility:** The core engine for requesting staff.
+*   **Key Features:**
+    *   **Rapid Order:** For urgent, same-day needs.
+    *   **One-Time Order:** For specific upcoming events.
+    *   **Recurring Order:** For regular weekly needs.
+    *   **Permanent Order:** For long-term staffing solutions.
+*   **Purpose:** Simplifies the complex logistics of scheduling shifts into intuitive, guided forms.
+
+### D. Workforce Management Module
+*   **Responsibility:** Managing the people and their time.
+*   **Key Features:**
+    *   **Shifts:** View upcoming, active, and past shifts.
+    *   **Workers:** Directory of assigned staff.
+    *   **Timesheets:** Review and approve work hours.
+    *   **Verify Attire:** Tools to ensure staff meet dress code compliance.
+
+### E. Analytics & Reporting Module
+*   **Responsibility:** Business intelligence and data visualization.
+*   **Key Features:** Reports for `Daily Operations`, `Spending`, `Forecasting`, `Performance`, and `Attendance` (No-shows).
+*   **Purpose:** Empowers clients to make data-driven decisions about their staffing budget and strategy.
+
+### F. Administration Module
+*   **Responsibility:** Account and configuration management.
+*   **Key Features:** `Billing` management, `Settings`, and `Hubs` (managing different business locations).
+
+## 4. Component Responsibilities
+
+| Component | Primary Responsibility | Example Task |
+| :--- | :--- | :--- |
+| **Router (GoRouter)** | Navigation traffic cop | Directs the user from the "Login" screen to the "Home" dashboard upon success. |
+| **Screens (UI)** | Displaying information | Renders the "Create Order" form and captures the user's input for date and time. |
+| **Providers (Riverpod)** | Data management & State | Holds the list of today's active shifts so multiple screens can access it without reloading. |
+| **Widgets** | Reusable UI building blocks | A "Shift Card" widget that displays shift details effectively, used in multiple lists throughout the app. |
+
+## 5. Data Flow
+
+1.  **User Action:** A client taps "Post Shift" on the Create Order screen.
+2.  **Input Processing:** The app validates the input (e.g., checking if the start time is before the end time).
+3.  **State Update:** The app updates its internal "State" to reflect that a submission is in progress (showing a loading spinner).
+4.  **Data Transmission (Future State):** The app sends a structured request to the backend server (API).
+5.  **Confirmation:** Upon success, the app navigates the user back to the Home screen and updates the "Live Activity" feed to show the newly created open shift.
+6.  **Read Action:** When viewing the Dashboard, the app requests the latest coverage metrics to display the "80% Covered" status.
+
+## 6. External System Communication
+
+While currently operating as a high-fidelity prototype with mock data, the architecture is designed to connect with:
+
+*   **Backend API (Firebase/Cloud Functions):** The app will communicate with a cloud backend to store and retrieve data. It uses `Firebase Core` and `Data Connect`.
+*   **Authentication Service:** Manages user identities securely.
+*   **Notification Service:** Sends push notifications to the client when a worker clocks in or if a shift is missed.
+
+## 7. Architectural Patterns
+
+*   **Model-View-ViewModel (MVVM) Inspiration:** The app separates the **View** (UI Screens) from the **Data Models**.
+*   **Declarative UI:** Using Flutter, the UI is built by describing *what* it should look like based on the current state, rather than manually updating elements.
+*   **Provider Pattern (Riverpod):** Used for Dependency Injection and State Management. This allows different parts of the app to share data (like the current user's profile) without tightly coupling components together.
+*   **Feature-Based Folder Structure:** Code is organized by "what it does" (e.g., `screens/client/reports`) rather than just technical type, making it easier for new developers to understand the business logic.
+
+## 8. Key Design Decisions
+
+*   **Flutter Framework:** chosen for its ability to produce high-performance, native-feeling apps for both iOS and Android from a single codebase, reducing development time and cost.
+*   **GoRouter for Navigation:** A modern routing package that handles complex navigation scenarios (like deep linking and sub-routes) which are essential for a multi-layered app like this.
+*   **Riverpod for State Management:** A robust solution that catches programming errors at compile-time (while writing code) rather than run-time (while using the app), increasing app stability.
+*   **Mock Data Services:** The decision to use extensive mock data allows for rapid UI/UX iteration and testing of business flows without waiting for the full backend infrastructure to be built.
+
+## 9. Overview Diagram
+```mermaid
+flowchart TD
+    subgraph ClientMobileApp["Client Mobile Application"]
+        direction TB
+        subgraph PresentationLayer["Presentation Layer (UI)"]
+            direction TB
+            Router["GoRouter Navigation"]
+            subgraph FeatureModules["Feature Modules"]
+                AuthUI["Auth Screens"]
+                DashUI["Dashboard & Home"]
+                OrderUI["Order Management"]
+                WorkUI["Workforce Management"]
+                ReportUI["Analytics & Reporting"]
+                AdminUI["Administration"]
+            end
+            Router --> FeatureModules
+        end
+        
+        subgraph LogicLayer["Logic Layer (State Management)"]
+            direction TB
+            Providers["Riverpod Providers"]
+            State["App State"]
+            Validation["Input Validation"]
+        end
+        
+        subgraph DataLayer["Data Layer (Infrastructure)"]
+            direction TB
+            Repositories["Repositories"]
+            Models["Data Models"]
+            MockService["Mock Data Service"]
+        end
+        
+        PresentationLayer --> LogicLayer
+        LogicLayer --> DataLayer
+    end
+    
+    subgraph ExternalSystems["External Systems"]
+        direction TB
+        Firebase["Firebase Backend"]
+        AuthService["Auth Service"]
+        Notify["Notification Service"]
+        CloudFunc["Cloud Functions"]
+    end
+    
+    DataLayer --> ExternalSystems
+    
+    %% Relationships & Data Flow
+    AuthUI -- "Login/Signup" --> Providers
+    OrderUI -- "Create Shift" --> Validation
+    Validation --> Providers
+    Providers -- "Update State" --> State
+    State -- "Notify UI" --> PresentationLayer
+    Repositories -- "Fetch Data" --> MockService
+    Repositories -. "Future Connection" .-> Firebase
+    
+    classDef layer fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#000
+    classDef module fill:#fff9c4,stroke:#fbc02d,stroke-width:1px,color:#000
+    classDef system fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#000
+    
+    class PresentationLayer,LogicLayer,DataLayer layer
+    class AuthUI,DashUI,OrderUI,WorkUI,ReportUI,AdminUI module
+    class ExternalSystems system
+```
diff --git a/internal/launchpad/assets/documents/prototype/client-mobile-application/use-case.md b/internal/launchpad/assets/documents/prototype/client-mobile-application/use-case.md
new file mode 100644
index 00000000..9223f6e6
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/client-mobile-application/use-case.md
@@ -0,0 +1,209 @@
+# Client Application: Use Case Overview
+
+This document details the primary business actions and user flows within the **Client Mobile Application**. It is organized according to the application's logical structure and navigation flow.
+
+---
+
+## 1. Application Access & Authentication
+
+### 1.1 Initial Startup & Auth Check
+*   **Actor:** Business Manager
+*   **Description:** The system determines if the user is already logged in or needs to authenticate.
+*   **Main Flow:**
+    1. User opens the application.
+    2. System checks for a valid session.
+    3. If authenticated, user is directed to the **Home Dashboard**.
+    4. If unauthenticated, user is directed to the **Get Started** screen.
+
+### 1.2 Register Business Account (Sign Up)
+*   **Actor:** New Business Manager
+*   **Description:** Creating a new identity for the business on the Krow platform.
+*   **Main Flow:**
+    1. User taps "Sign Up".
+    2. User enters company details (Name, Industry).
+    3. User enters contact information and password.
+    4. User confirms registration and is directed to the Main App.
+
+### 1.3 Business Sign In
+*   **Actor:** Existing Business Manager
+*   **Description:** Accessing an existing account.
+*   **Main Flow:**
+    1. User enters registered email and password.
+    2. System validates credentials.
+    3. User is granted access to the dashboard.
+
+---
+
+## 2. Order Management (Requesting Staff)
+
+### 2.1 Rapid Order (Urgent Needs)
+*   **Actor:** Business Manager
+*   **Description:** Posting a shift for immediate, same-day fulfillment.
+*   **Main Flow:** Taps "RAPID" -> Selects Role -> Sets Quantity -> Confirms ASAP status -> Posts Order.
+
+### 2.2 Scheduled Orders (Planned Needs)
+*   **Actor:** Business Manager
+*   **Description:** Planning for future staffing requirements.
+*   **Main Flow:**
+    1. User selects "Create Order".
+    2. User chooses the frequency:
+        *   **One-Time:** A single specific shift.
+        *   **Recurring:** Shifts that repeat on a schedule (e.g., every Monday).
+        *   **Permanent:** Long-term staffing placement.
+    3. User enters date, time, role, and location.
+    4. User reviews cost and posts the order.
+
+---
+
+## 3. Operations & Workforce Management
+
+### 3.1 Monitor Today's Coverage (Coverage Tab)
+*   **Actor:** Business Manager
+*   **Description:** A bird's-eye view of all shifts happening today.
+*   **Main Flow:** User navigates to "Coverage" tab -> Views percentage filled -> Identifies open gaps -> Re-posts unfilled shifts if necessary.
+
+### 3.2 Live Activity Tracking
+*   **Actor:** Business Manager
+*   **Description:** Real-time feed of worker clock-ins and status updates.
+*   **Location:** Home Tab / Coverage Detail.
+*   **Main Flow:** User monitors the live feed for worker arrivals and on-site status.
+
+### 3.3 Verify Worker Attire
+*   **Actor:** Business Manager / Site Supervisor
+*   **Description:** Ensuring staff arriving on-site meet the required dress code.
+*   **Main Flow:** User selects an active shift -> Selects worker -> Checks attire compliance (shoes, uniform, ID) -> Submits verification.
+
+### 3.4 Review & Approve Timesheets
+*   **Actor:** Business Manager
+*   **Description:** Finalizing hours worked for payroll processing.
+*   **Main Flow:** User navigates to "Timesheets" -> Reviews actual vs. scheduled hours -> Taps "Approve" or "Dispute".
+
+---
+
+## 4. Reports & Analytics
+
+### 4.1 Business Intelligence Reporting
+*   **Actor:** Business Manager / Executive
+*   **Description:** Accessing data visualizations to optimize business operations.
+*   **Available Reports:**
+    *   **Daily Ops:** Day-to-day fulfillment and performance.
+    *   **Spend Report:** Financial breakdown of labor costs.
+    *   **Forecast:** Projected staffing needs and costs.
+    *   **Performance:** Worker and vendor reliability scores.
+    *   **No-Show:** Tracking attendance issues.
+    *   **Coverage:** Detailed fill-rate analysis.
+
+---
+
+## 5. Billing & Administration
+
+### 5.1 Financial Management (Billing Tab)
+*   **Actor:** Business Manager / Finance Admin
+*   **Description:** Reviewing invoices and managing payment methods.
+*   **Main Flow:** User navigates to "Billing" -> Views current balance -> Downloads past invoices -> Updates credit card/ACH info.
+
+### 5.2 Manage Business Locations (Hubs)
+*   **Actor:** Business Manager
+*   **Description:** Defining different venues or branches where staff will be sent.
+*   **Main Flow:** User goes to Settings -> Client Hubs -> Adds/Edits location details and addresses.
+
+### 5.3 Profile & Settings Management
+*   **Actor:** Business Manager
+*   **Description:** Updating personal contact info and notification preferences.
+*   **Main Flow:** User goes to Settings -> Edits Profile -> Toggles notification settings for shift updates and billing alerts.
+
+---
+
+# Use Case Diagram
+```mermaid
+flowchart TD
+    subgraph AppInitialization [App Initialization]
+        Start[Start App] --> CheckAuth{Check Auth Status}
+        CheckAuth -- Authenticated --> GoHome[Go to Main App]
+        CheckAuth -- Unauthenticated --> GetStarted[Go to Get Started]
+    end
+
+    subgraph Authentication [Authentication]
+        GetStarted --> AuthChoice{Select Option}
+        AuthChoice -- Sign In --> SignIn[Sign In Screen]
+        AuthChoice -- Sign Up --> SignUp[Sign Up Screen]
+        
+        SignIn --> EnterCreds[Enter Credentials]
+        EnterCreds --> VerifySignIn{Verify}
+        VerifySignIn -- Success --> GoHome
+        VerifySignIn -- Failure --> SignInError[Show Error]
+        
+        SignUp --> EnterBusinessDetails[Enter Business Details]
+        EnterBusinessDetails --> CreateAccount[Create Account]
+        CreateAccount -- Success --> GoHome
+    end
+
+    subgraph MainApp [Main Application Shell]
+        GoHome --> Shell[Scaffold with Nav Bar]
+        Shell --> TabNav{Tab Navigation}
+        
+        TabNav -- Index 0 --> Coverage[Coverage Tab]
+        TabNav -- Index 1 --> Billing[Billing Tab]
+        TabNav -- Index 2 --> Home[Home Tab]
+        TabNav -- Index 3 --> Orders[Orders/Shifts Tab]
+        TabNav -- Index 4 --> Reports[Reports Tab]
+    end
+
+    subgraph HomeActions [Home Tab Actions]
+        Home --> CreateOrderAction{Create Order}
+        CreateOrderAction -- Rapid --> RapidOrder[Rapid Order Flow]
+        CreateOrderAction -- One-Time --> OneTimeOrder[One-Time Order Flow]
+        CreateOrderAction -- Recurring --> RecurringOrder[Recurring Order Flow]
+        CreateOrderAction -- Permanent --> PermanentOrder[Permanent Order Flow]
+        
+        Home --> QuickActions[Quick Actions Widget]
+        Home --> Settings[Go to Settings]
+        Home --> Hubs[Go to Client Hubs]
+    end
+
+    subgraph OrderManagement [Order Management Flows]
+        RapidOrder --> SubmitRapid[Submit Rapid Order]
+        OneTimeOrder --> SubmitOneTime[Submit One-Time Order]
+        RecurringOrder --> SubmitRecurring[Submit Recurring Order]
+        PermanentOrder --> SubmitPermanent[Submit Permanent Order]
+        
+        SubmitRapid --> OrderSuccess[Order Success]
+        SubmitOneTime --> OrderSuccess
+        SubmitRecurring --> OrderSuccess
+        SubmitPermanent --> OrderSuccess
+        OrderSuccess --> Home
+    end
+
+    subgraph ReportsAnalysis [Reports & Analytics]
+        Reports --> SelectReport{Select Report}
+        SelectReport -- Daily Ops --> DailyOps[Daily Ops Report]
+        SelectReport -- Spend --> SpendReport[Spend Report]
+        SelectReport -- Forecast --> ForecastReport[Forecast Report]
+        SelectReport -- Performance --> PerfReport[Performance Report]
+        SelectReport -- No-Show --> NoShowReport[No-Show Report]
+        SelectReport -- Coverage --> CovReport[Coverage Report]
+    end
+
+    subgraph WorkforceMgmt [Workforce Management]
+        Orders --> ViewShifts[View Shifts List]
+        ViewShifts --> ShiftDetail[View Shift Detail]
+        ShiftDetail --> VerifyAttire[Verify Attire]
+        
+        Home --> ViewWorkers[View Workers List]
+        Home --> ViewTimesheets[View Timesheets]
+        ViewTimesheets --> ApproveTime[Approve Hours]
+        ViewTimesheets --> DisputeTime[Dispute Hours]
+    end
+
+    subgraph SettingsFlow [Settings & Configuration]
+        Settings --> EditProfile[Edit Profile]
+        Settings --> ManageHubsLink[Manage Hubs]
+        Hubs --> AddHub[Add New Hub]
+        Hubs --> EditHub[Edit Existing Hub]
+    end
+
+    %% Relationships across subgraphs
+    OrderSuccess -.-> Coverage
+    VerifySignIn -.-> Shell
+    CreateAccount -.-> Shell
+```
\ No newline at end of file
diff --git a/internal/launchpad/assets/documents/prototype/staff-mobile-application/architecture.md b/internal/launchpad/assets/documents/prototype/staff-mobile-application/architecture.md
new file mode 100644
index 00000000..0c2ffbff
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/staff-mobile-application/architecture.md
@@ -0,0 +1,159 @@
+# Staff Mobile Application: Architecture Overview
+
+## 1. Executive Summary
+The **Staff Mobile Application** is the dedicated companion for the temporary workforce. It is designed to be the "one-stop-shop" for workers to find employment, manage their work life, and get paid.
+
+For a worker, this app replaces the traditional agency corkboard and paper timesheets. It allows them to browse available shifts in their area, claim jobs that fit their schedule, clock in and out using their phone, and track their earnings instantly. It also handles all the necessary administrative tasks like tax forms and certifications.
+
+## 2. High-Level Architecture
+Like its client-facing counterpart, this application is built on **Flutter**, ensuring a high-quality, native experience on both Android and iOS devices from a single codebase.
+
+The architecture is **User-Centric and Feature-Driven**. It is organized around the daily lifecycle of a worker: finding work, doing work, getting paid, and growing their career.
+
+The system is structured into three main logical layers:
+1.  **UI Layer:** The screens and interactive elements (The "Face" of the app).
+2.  **Application Logic:** The state management that handles user sessions, shift status, and data updates (The "Brain").
+3.  **Data & Service Layer:** The connection to backend systems for authentication, job listings, and payments (The "Backbone").
+
+## 3. Major Components & Modules
+
+### A. Onboarding & Authentication Module
+*   **Responsibility:** bringing new workers into the ecosystem securely.
+*   **Key Features:** `Get Started`, `Phone Verification` (OTP), and `Profile Setup`.
+*   **Purpose:** Verifies identity and collects essential initial information to create a trustable worker profile.
+
+### B. Marketplace (Jobs) Module
+*   **Responsibility:** connecting workers with open opportunities.
+*   **Key Features:** `Jobs Screen` for browsing open shifts, filtering by location/role, and viewing `Shift Details`.
+*   **Purpose:** Acts as the job board where supply meets demand.
+
+### C. Shift Management Module
+*   **Responsibility:** managing the "doing" of the work.
+*   **Key Features:**
+    *   **Shifts:** A personalized schedule of upcoming and past commitments.
+    *   **Clock In/Out:** GPS-enabled time tracking to verify attendance.
+    *   **Availability:** Tools for workers to set when they can and cannot work.
+
+### D. Financial Module
+*   **Responsibility:** handling compensation and benefits.
+*   **Key Features:**
+    *   **Earnings:** Visual breakdown of income.
+    *   **Payments:** Transaction history and bank account management.
+    *   **Early Pay:** Feature allowing access to wages before the standard payday.
+    *   **Benefits:** Access to worker perks and insurance.
+
+### E. Profile & Compliance Module
+*   **Responsibility:** managing the professional identity and legal requirements.
+*   **Key Features:**
+    *   **Compliance:** Uploading and verifying `Certificates`, `Documents`, and Tax Forms (`I-9`, `W-4`).
+    *   **Level Up:** `Krow University` for training and a `Leaderboard` for gamification.
+    *   **Support:** `FAQs`, `Privacy`, and `Messages`.
+
+## 4. Component Responsibilities
+
+| Component | Primary Responsibility | Example Task |
+| :--- | :--- | :--- |
+| **Authentication Screens** | Security & Entry | Validates the 6-digit code sent to the user's phone during login. |
+| **Shift Provider** | Data State Management | Keeps track of which shift is currently "Active" so the Clock-In button appears on the Home screen. |
+| **Router** | Navigation | Deep-links a user directly to a specific "Shift Detail" page from a push notification. |
+| **Mock Service** | Data Simulation | Generates a realistic list of "Available Jobs" nearby for the prototype to display. |
+
+## 5. Data Flow
+
+1.  **Discovery:** The worker opens the `Jobs` screen. The app requests "Available Shifts" from the Data Layer.
+2.  **Action:** The worker taps "Accept Shift".
+3.  **Processing:** The app updates the shift status locally to "Scheduled" and adds it to the worker's `My Shifts` list.
+4.  **Execution:** On the day of the job, the worker opens the `Clock In` screen. The app checks their geolocation.
+5.  **Verification:** If the location matches the job site, the "Clock In" action is allowed.
+6.  **Completion:** After clocking out, the data flows to the `Earnings` module, updating the "Pending Pay" balance.
+
+## 6. External System Communication
+
+The architecture is designed to interface with several critical external systems:
+
+*   **Identity Services:** For SMS-based phone verification and secure login.
+*   **Maps & Geolocation:** Uses device location services to verify "Clock In" actions are performed on-site.
+*   **Banking/Payment APIs:** Connects to payment processors for "Early Pay" and direct deposit functions.
+*   **Document Verification Services:** (Future State) To automatically validate uploaded IDs and certifications.
+*   **Backend Database (Firebase):** Stores the "Single Source of Truth" for user profiles, shift history, and compliance status.
+
+## 7. Architectural Patterns
+
+*   **Feature-First Organization:** The codebase is grouped by feature (e.g., `worker_profile/compliance`, `worker_profile/finances`). This "vertical slice" architecture keeps related code together.
+*   **State Management with Riverpod:** Used to manage global application state (like "Is the user logged in?" or "What is my current location?") in a clean, testable way.
+*   **Repository Pattern (Implied):** The service layer (`mock_service.dart`) acts as a repository, abstracting the data source so the UI doesn't care if data comes from a mock file or a real server.
+
+## 8. Key Design Decisions
+
+*   **Flutter for Mobile:** Ensures the app is responsive and performs well on the wide variety of devices low-wage workers might own.
+*   **Strict Compliance Separation:** Dedicating a specific sub-module to `Compliance` (Tax forms, I-9) highlights the importance of legal adherence in the staffing industry.
+*   **Gamification (Level Up):** The inclusion of `Krow University` and `Leaderboards` is a deliberate design choice to drive worker engagement and retention.
+*   **Offline-First Capabilities (Planned):** The architecture supports local data caching, which is critical for workers who may have spotty data connections while on job sites.
+
+## 9. Overview Diagram
+
+```mermaid
+flowchart TD
+    subgraph StaffMobileApp["Staff Mobile Application"]
+        direction TB
+        subgraph PresentationLayer["Presentation Layer (UI)"]
+            direction TB
+            Router["GoRouter Navigation"]
+            subgraph FeatureModules["Feature Modules"]
+                AuthUI["Auth & Onboarding"]
+                MarketUI["Marketplace & Jobs"]
+                ShiftUI["Shift Management"]
+                FinanceUI["Financial & Benefits"]
+                ProfileUI["Profile & Compliance"]
+            end
+            Router --> FeatureModules
+        end
+        
+        subgraph LogicLayer["Application Logic (State)"]
+            direction TB
+            Providers["Riverpod Providers"]
+            AuthState["Auth State"]
+            LocState["Geolocation State"]
+            ShiftState["Shift State"]
+        end
+        
+        subgraph DataLayer["Data & Service Layer"]
+            direction TB
+            MockService["Mock Data Service"]
+            Repos["Repositories"]
+        end
+        
+        PresentationLayer --> LogicLayer
+        Providers --> AuthState
+        Providers --> LocState
+        Providers --> ShiftState
+        LogicLayer --> DataLayer
+    end
+    
+    subgraph ExternalServices["External Services"]
+        direction TB
+        Firebase["Firebase Backend"]
+        Identity["Identity/SMS Service"]
+        Maps["Google Maps/Geolocation"]
+        Banking["Payment Processor"]
+        DocVerify["Doc Verification"]
+    end
+    
+    DataLayer --> ExternalServices
+    
+    %% Specific Data Flows
+    AuthUI -- "Verify OTP" --> Identity
+    MarketUI -- "Find Jobs" --> Repos
+    ShiftUI -- "Clock In" --> Maps
+    FinanceUI -- "Get Paid" --> Banking
+    ProfileUI -- "Upload Docs" --> DocVerify
+    Repos -- "Sync Data" --> Firebase
+    
+    classDef layer fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#000
+    classDef module fill:#fff9c4,stroke:#fbc02d,stroke-width:1px,color:#000
+    classDef system fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#000
+    
+    class PresentationLayer,LogicLayer,DataLayer layer
+    class AuthUI,MarketUI,ShiftUI,FinanceUI,ProfileUI module
+    class ExternalServices system
+```
\ No newline at end of file
diff --git a/internal/launchpad/assets/documents/prototype/staff-mobile-application/use-case.md b/internal/launchpad/assets/documents/prototype/staff-mobile-application/use-case.md
new file mode 100644
index 00000000..23b920b8
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/staff-mobile-application/use-case.md
@@ -0,0 +1,208 @@
+# Staff Application: Use Case Overview
+
+This document details the primary business actions available within the **Staff Mobile Application**. It is organized according to the application's logical structure and navigation flow.
+
+---
+
+## 1. Application Access & Authentication
+
+### 1.1 App Initialization
+*   **Actor:** Temporary Worker
+*   **Description:** The system checks if the user is logged in upon startup.
+*   **Main Flow:**
+    1. Worker opens the app.
+    2. System checks for a valid auth token.
+    3. If valid, worker goes to **Home**.
+    4. If invalid, worker goes to **Get Started**.
+
+### 1.2 Onboarding & Registration
+*   **Actor:** New Worker
+*   **Description:** Creating a new profile to join the Krow network.
+*   **Main Flow:**
+    1. Worker enters phone number.
+    2. System sends SMS OTP.
+    3. Worker verifies OTP.
+    4. System checks if profile exists.
+    5. If new, worker completes **Profile Setup Wizard** (Personal Info -> Role/Experience -> Attire Sizes).
+    6. Worker enters the Main App.
+
+---
+
+## 2. Job Discovery (Home Tab)
+
+### 2.1 Browse & Filter Jobs
+*   **Actor:** Temporary Worker
+*   **Description:** Finding suitable work opportunities.
+*   **Main Flow:**
+    1. Worker taps "View Available Jobs".
+    2. Worker filters by Role (e.g., Server) or Distance.
+    3. Worker selects a job card to view details (Pay, Location, Requirements).
+
+### 2.2 Claim Open Shift
+*   **Actor:** Temporary Worker
+*   **Description:** Committing to work a specific shift.
+*   **Main Flow:**
+    1. From Job Details, worker taps "Claim Shift".
+    2. System validates eligibility (Certificates, Conflicts).
+    3. If eligible, shift is added to "My Schedule".
+    4. If missing requirements, system prompts to **Upload Compliance Docs**.
+
+### 2.3 Set Availability
+*   **Actor:** Temporary Worker
+*   **Description:** Defining working hours to get better job matches.
+*   **Main Flow:** Worker taps "Set Availability" -> Selects dates/times -> Saves preferences.
+
+---
+
+## 3. Shift Execution (Shifts & Clock In Tabs)
+
+### 3.1 View Schedule
+*   **Actor:** Temporary Worker
+*   **Description:** Reviewing upcoming commitments.
+*   **Main Flow:** Navigate to "My Shifts" tab -> View list of claimed shifts.
+
+### 3.2 GPS-Verified Clock In
+*   **Actor:** Temporary Worker
+*   **Description:** Starting a shift once on-site.
+*   **Main Flow:**
+    1. Navigate to "Clock In" tab.
+    2. System checks GPS location against job site coordinates.
+    3. If **On Site**, "Swipe to Clock In" becomes active.
+    4. Worker swipes to start the timer.
+    5. If **Off Site**, system displays an error message.
+
+### 3.3 Submit Timesheet
+*   **Actor:** Temporary Worker
+*   **Description:** Completing a shift and submitting hours for payment.
+*   **Main Flow:**
+    1. Worker swipes to "Clock Out".
+    2. Worker confirms total hours and break times.
+    3. Worker submits timesheet for client approval.
+
+---
+
+## 4. Financial Management (Payments Tab)
+
+### 4.1 Track Earnings
+*   **Actor:** Temporary Worker
+*   **Description:** Monitoring financial progress.
+*   **Main Flow:** Navigate to "Payments" -> View "Pending Pay" (unpaid) and "Total Earned" (paid).
+
+### 4.2 Request Early Pay
+*   **Actor:** Temporary Worker
+*   **Description:** Accessing wages before the standard payday.
+*   **Main Flow:**
+    1. Tap "Request Early Pay".
+    2. Select amount to withdraw from available balance.
+    3. Confirm transfer fee.
+    4. Funds are transferred to the linked bank account.
+
+---
+
+## 5. Profile & Compliance (Profile Tab)
+
+### 5.1 Manage Compliance Documents
+*   **Actor:** Temporary Worker
+*   **Description:** Keeping certifications up to date.
+*   **Main Flow:** Navigate to "Compliance Menu" -> "Upload Certificates" -> Take photo of ID/License -> Submit.
+
+### 5.2 Manage Tax Forms
+*   **Actor:** Temporary Worker
+*   **Description:** Submitting legal employment forms.
+*   **Main Flow:** Navigate to "Tax Forms" -> Complete W-4 or I-9 digitally -> Sign and Submit.
+
+### 5.3 Krow University Training
+*   **Actor:** Temporary Worker
+*   **Description:** Improving skills to unlock better jobs.
+*   **Main Flow:** Navigate to "Krow University" -> Select Module -> Watch Video/Take Quiz -> Earn Badge.
+
+### 5.4 Account Settings
+*   **Actor:** Temporary Worker
+*   **Description:** Managing personal data.
+*   **Main Flow:** Update Bank Details, View Benefits, or Access Support/FAQs.
+
+---
+
+# Use Cases Diagram
+```mermaid
+flowchart TD
+    subgraph AppInitialization [App Initialization]
+        Start[Start App] --> CheckAuth{Check Auth Status}
+        CheckAuth -- Authenticated --> GoHome[Go to Main App]
+        CheckAuth -- Unauthenticated --> GetStarted[Go to Get Started]
+    end
+
+    subgraph Authentication [Onboarding & Authentication]
+        GetStarted --> InputPhone[Enter Phone Number]
+        InputPhone --> VerifyOTP[Verify SMS Code]
+        VerifyOTP --> CheckProfile{Profile Complete?}
+        CheckProfile -- Yes --> GoHome
+        CheckProfile -- No --> SetupProfile[Profile Setup Wizard]
+        
+        SetupProfile --> Step1[Personal Info]
+        Step1 --> Step2[Role & Experience]
+        Step2 --> Step3[Attire Sizes]
+        Step3 --> GoHome
+    end
+
+    subgraph MainApp [Main Application Shell]
+        GoHome --> Shell[Scaffold with Nav Bar]
+        Shell --> TabNav{Tab Navigation}
+        
+        TabNav -- Index 0 --> Shifts[My Shifts Tab]
+        TabNav -- Index 1 --> Payments[Payments Tab]
+        TabNav -- Index 2 --> Home[Home Tab]
+        TabNav -- Index 3 --> ClockIn[Clock In Tab]
+        TabNav -- Index 4 --> Profile[Profile Tab]
+    end
+
+    subgraph HomeAndDiscovery [Job Discovery]
+        Home --> ViewOpenJobs[View Available Jobs]
+        ViewOpenJobs --> FilterJobs[Filter by Role/Distance]
+        ViewOpenJobs --> JobDetail[View Job Details]
+        JobDetail --> ClaimShift{Claim Shift}
+        ClaimShift -- Success --> ShiftSuccess[Shift Added to Schedule]
+        ClaimShift -- "Missing Req" --> PromptUpload[Prompt Compliance Upload]
+        
+        Home --> SetAvailability[Set Availability]
+        Home --> ViewUpcoming[View Upcoming Shifts]
+    end
+
+    subgraph ShiftExecution [Shift Execution]
+        Shifts --> ViewSchedule[View My Schedule]
+        ClockIn --> CheckLocation{Verify GPS Location}
+        CheckLocation -- "On Site" --> SwipeIn[Swipe to Clock In]
+        CheckLocation -- "Off Site" --> LocationError[Show Location Error]
+        
+        SwipeIn --> ActiveShift[Shift In Progress]
+        ActiveShift --> SwipeOut[Swipe to Clock Out]
+        SwipeOut --> ConfirmHours[Confirm Hours & Breaks]
+        ConfirmHours --> SubmitTimesheet[Submit Timesheet]
+    end
+
+    subgraph Financials [Earnings & Payments]
+        Payments --> ViewEarnings[View Pending Earnings]
+        Payments --> ViewHistory[View Payment History]
+        ViewEarnings --> EarlyPay{Request Early Pay?}
+        EarlyPay -- Yes --> SelectAmount[Select Amount]
+        SelectAmount --> ConfirmTransfer[Confirm Transfer]
+    end
+
+    subgraph ProfileAndCompliance [Profile & Compliance]
+        Profile --> ComplianceMenu[Compliance Menu]
+        ComplianceMenu --> UploadDocs[Upload Certificates]
+        ComplianceMenu --> TaxForms["Manage Tax Forms (W-4/I-9)"]
+        
+        Profile --> KrowUniversity[Krow University]
+        KrowUniversity --> StartTraining[Start Training Module]
+        
+        Profile --> BankAccount[Manage Bank Details]
+        Profile --> Benefits[View Benefits]
+        Profile --> Support["Access Support/FAQs"]
+    end
+
+    %% Relationships across subgraphs
+    SubmitTimesheet -.-> ViewEarnings
+    PromptUpload -.-> ComplianceMenu
+    ShiftSuccess -.-> ViewSchedule
+```
\ No newline at end of file
diff --git a/internal/launchpad/assets/documents/prototype/system-bible.md b/internal/launchpad/assets/documents/prototype/system-bible.md
new file mode 100644
index 00000000..bbf8e972
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/system-bible.md
@@ -0,0 +1,251 @@
+# The Krow Platform System Bible
+
+**Status:** Official / Living Document
+**Version:** 1.0.0
+
+---
+
+## 1. Executive Summary
+
+### What the System Is
+The **Krow Platform** is a multi-sided workforce management ecosystem that digitizes the entire lifecycle of temporary staffing. It replaces fragmented, manual processes (phone calls, spreadsheets, paper timesheets) with a unified digital infrastructure connecting businesses ("Clients") directly with temporary workers ("Staff").
+
+### Why It Exists
+The temporary staffing industry suffers from friction, lack of transparency, and delayed payments. Businesses struggle to find reliable staff quickly, while workers face uncertain schedules and slow wage access. Krow exists to remove this friction, ensuring shifts are filled instantly, work is verified accurately, and payments are processed swiftly.
+
+### Who It Serves
+1.  **Clients (Businesses):** Venue managers and owners who need on-demand or scheduled staff.
+2.  **Staff (Workers):** Individuals seeking flexible, temporary employment opportunities.
+3.  **Admins (Operations):** Internal teams managing the marketplace, compliance, and financial flows.
+
+### High-Level Value Proposition
+Krow transforms labor from a manual logistical headache into a streamlined digital asset. For clients, it provides "staff on tap" with verified compliance. For workers, it offers "freedom and instant pay." For the platform operators, it delivers data-driven oversight of a complex marketplace.
+
+---
+
+## 2. System Vision & Product Principles
+
+### Core Goals
+1.  **Immediacy:** Reduce the time-to-fill for urgent shifts from hours to minutes.
+2.  **Accuracy:** Eliminate payroll disputes through GPS-verified digital timesheets.
+3.  **Compliance:** Automate the enforcement of legal and safety requirements (attire, certifications).
+
+### Problems It Intentionally Solves
+*   **The "No-Show" Epidemic:** By creating a transparent marketplace with reliability ratings.
+*   **Payroll Latency:** By enabling "Early Pay" features rooted in verified digital time cards.
+*   **Administrative Bloat:** By automating invoice generation and worker onboarding.
+
+### Problems It Intentionally Does NOT Solve
+*   **Full-Time Recruitment:** This system is optimized for shift-based, temporary labor, not permanent headhunting.
+*   **Gig Economy "Tasking":** It focuses on professional hospitality and event roles, not general unskilled errands.
+
+### Guiding Product Principles
+*   **Mobile-First for Operations:** If a task happens on a job site (clocking in, checking coverage), it *must* be possible on a phone.
+*   **Data as the Truth:** We do not rely on verbal confirmations. If it isn't in the system (GPS stamp, digital signature), it didn't happen.
+*   **Separation of Concerns:** Clients manage demand; Staff manage supply; Admin manages the rules. These roles never blur.
+
+---
+
+## 3. Ecosystem Overview
+
+The ecosystem comprises three distinct applications, each serving a specific user persona but operating on a shared reality.
+
+### 1. Client Mobile Application (The "Requester")
+*   **Platform:** Flutter (Mobile)
+*   **Responsibility:** Demand generation. Allows businesses to post orders, track arriving staff in real-time, and approve work hours.
+*   **Concept:** The "Remote Control" for the venue's staffing operations.
+
+### 2. Staff Mobile Application (The "Worker")
+*   **Platform:** Flutter (Mobile)
+*   **Responsibility:** Supply fulfillment. Empowering workers to find jobs, manage their schedule, verify their presence (Clock In), and access earnings.
+*   **Concept:** The worker's "Digital Agency" in their pocket.
+
+### 3. Krow Web Application (The "HQ")
+*   **Platform:** React (Web)
+*   **Responsibility:** Ecosystem governance. The command center for high-level analytics, complex financial operations (invoicing/payouts), vendor management, and system administration.
+*   **Concept:** The "Mission Control" for the business backend.
+
+---
+
+## 4. System Architecture Overview
+
+The Krow Platform follows a **Service-Oriented Architecture (SOA)** where multiple front-end clients interface with a shared, monolithic logical backend (exposed via API Gateway).
+
+### Architectural Style
+*   **Centralized State:** A single backend database serves as the source of truth for all apps.
+*   **Role-Based Access:** The API exposes different endpoints and data views depending on the authenticated user's role (Client vs. Staff).
+*   **Event-Driven Flows:** Key actions (e.g., "Shift Posted") trigger downstream effects (e.g., "Push Notification Sent") across the ecosystem.
+
+### System Boundaries
+The "System" encompasses the three front-end apps and the shared backend services. External boundaries are drawn at:
+*   **Payment Gateways:** We initiate transfers, but the actual money movement is external.
+*   **Maps/Geolocation:** We consume location data but do not maintain mapping infrastructure.
+*   **SMS/Identity:** We offload OTP delivery to specialized providers.
+
+### Trust Boundaries
+*   **Mobile Apps are Untrusted:** We assume any data coming from a client device (GPS coordinates, timestamps) could be manipulated and must be validated server-side.
+*   **Web App is Semi-Trusted:** Admin actions are logged for audit but are assumed to be authorized operations.
+
+```mermaid
+flowchart TD
+    subgraph Clients [Client Layer]
+        CMA[Client Mobile App]
+        SMA[Staff Mobile App]
+        WEB[Web Admin Portal]
+    end
+
+    subgraph API [Interface Layer]
+        Gateway[API Gateway]
+    end
+
+    subgraph Services [Core Service Layer]
+        Auth[Identity Service]
+        Ops[Operations Service]
+        Finance[Financial Service]
+    end
+
+    subgraph Data [Data Layer]
+        DB[(Central Database)]
+    end
+
+    CMA --> Gateway
+    SMA --> Gateway
+    WEB --> Gateway
+    Gateway --> Services
+    Services --> DB
+```
+
+---
+
+## 5. Application Responsibility Matrix
+
+| Feature Domain | Client App (Mobile) | Staff App (Mobile) | Web App (Admin/Ops) |
+| :--- | :--- | :--- | :--- |
+| **User Onboarding** | Register Business | Register Worker | Onboard Vendors |
+| **Shift Management** | **Create** & Monitor | **Claim** & Execute | **Oversee** & Resolve |
+| **Time Tracking** | Approve / Dispute | Clock In / Out | Audit Logs |
+| **Finance** | Pay Invoices | Request Payout | Generate Bills |
+| **Compliance** | Verify Attire | Upload Docs | Verify Docs |
+| **Analytics** | View My Venue Stats | View My Earnings | Global Market Analysis |
+
+### Critical Rules
+*   **Client App MUST NOT** access worker financial data (bank details, total platform earnings).
+*   **Staff App MUST NOT** see client billing rates or internal venue notes.
+*   **Web App MUST** be the only place where global system configurations (e.g., platform fees) are changed.
+
+---
+
+## 6. Use Cases
+
+The following are the **official system use cases**. Any feature request not mapping to one of these must be scrutinized.
+
+### A. Staffing Operations
+1.  **Post Urgent Shift (Client):**
+    *   *Pre:* Valid client account.
+    *   *Flow:* Select Role -> Set Qty -> Post.
+    *   *Post:* Notification sent to eligible workers.
+2.  **Claim Shift (Staff):**
+    *   *Pre:* Worker meets compliance reqs.
+    *   *Flow:* View Job -> Accept.
+    *   *Post:* Shift is locked; Client notified.
+3.  **Execute Shift (Staff):**
+    *   *Pre:* On-site GPS verification.
+    *   *Flow:* Clock In -> Work -> Clock Out.
+    *   *Validation:* Location check passes.
+4.  **Approve Timesheet (Client):**
+    *   *Pre:* Shift completed.
+    *   *Flow:* Review Hours -> Approve.
+    *   *Post:* Payment scheduled.
+
+### B. Financial Operations
+5.  **Process Billing (Web/Admin):**
+    *   *Flow:* Aggregate approved hours -> Generate Invoice -> Charge Client.
+6.  **Request Early Pay (Staff):**
+    *   *Pre:* Accrued unpaid earnings.
+    *   *Flow:* Select Amount -> Confirm -> Transfer.
+
+### C. Governance
+7.  **Verify Compliance (Web/Admin):**
+    *   *Flow:* Review uploaded ID -> Mark as Verified.
+    *   *Post:* Worker eligible for shifts.
+8.  **Strategic Analysis (Web/Client):**
+    *   *Flow:* View Savings Engine -> Adopt Recommendation.
+
+---
+
+## 7. Cross-Application Interaction Rules
+
+### Communication Patterns
+*   **Indirect Communication:** Apps NEVER speak peer-to-peer.
+    *   *Correct:* Client App posts order -> Backend -> Staff App receives notification.
+    *   *Forbidden:* Client App sends data directly to Staff App via Bluetooth/LAN.
+*   **Push Notifications:** Used as the primary signal to "wake up" an app and fetch fresh data from the server.
+
+### Dependency Direction
+*   **Downstream Dependency:** The Mobile Apps depend on the Web App's configuration (e.g., if Admin adds a new "Role Type" on Web, it appears on Mobile).
+*   **Upstream Data Flow:** Operational data flows *up* from Mobile (Clock-ins) to Web (Reporting).
+
+### Anti-Patterns to Avoid
+*   **"Split Brain" Logic:** Business logic (e.g., "How is overtime calculated?") must live in the Backend, NOT duplicated in the mobile apps.
+*   **Local-Only State:** Critical data (shift status) must never exist only on a user's device. It must be synced immediately.
+
+---
+
+## 8. Data Ownership & Source of Truth
+
+| Data Domain | Source of Truth | Write Access | Read Access |
+| :--- | :--- | :--- | :--- |
+| **User Identity** | Auth Service | User (Self), Admin | System-wide |
+| **Shift Status** | Order Service | Client (Create), Staff (Update status) | All (Context dependent) |
+| **Time Cards** | Database | Staff (Create), Client (Approve) | Admin, Payroll |
+| **Compliance Docs** | Worker Profile | Staff (Upload), Admin (Verify) | Client (Status only) |
+| **Platform Rates** | System Config | Admin | Read-only |
+
+### Consistency Principle
+**"The Server is Right."** If a mobile device displays a shift as "Open" but the server says "Filled," the device is wrong and must refresh. We prioritize data integrity over offline availability for critical transaction states.
+
+---
+
+## 9. Security & Access Model
+
+### User Roles
+1.  **Super Admin:** Full system access.
+2.  **Client Manager:** Access to own venue data only.
+3.  **Worker:** Access to own schedule and public job board only.
+
+### Authentication Philosophy
+*   **Zero Trust:** Every API request must carry a valid, unexpired token.
+*   **Session Management:** Mobile sessions are persistent (long-lived tokens) for usability; Web sessions (Admin) are shorter for security.
+
+### Authorization Boundaries
+*   **Horizontal Separation:** Client A cannot see Client B's orders. Worker A cannot see Worker B's pay.
+*   **Vertical Separation:** Staff cannot access Admin APIs.
+
+---
+
+## 10. Non-Negotiables & Guardrails
+
+1.  **No GPS, No Pay:** A clock-in event *must* have valid geolocation data attached. No exceptions.
+2.  **Compliance First:** A worker cannot claim a shift if their required documents (e.g., Food Handler Card) are expired. The system must block this at the API level.
+3.  **Immutable Audit Trail:** Once a timesheet is approved and paid, it cannot be deleted or modified, only reversed via a new corrective transaction.
+4.  **One Account Per Person:** Strict identity checks to prevent duplicate worker profiles.
+
+---
+
+## 11. Known Constraints & Assumptions
+
+*   **Connectivity:** The system assumes a reliable internet connection for critical actions (Claiming, Clocking In). Offline mode is limited to read-only views of cached schedules.
+*   **Device Capability:** We assume worker devices have functional GPS and Camera hardware.
+*   **Payment Timing:** "Instant" pay is subject to external banking network delays (ACH/RTP) and is not truly real-time in all cases.
+
+---
+
+## 12. Glossary
+
+*   **Shift:** A single unit of work with a start time, end time, and role.
+*   **Order:** A request from a client containing one or more shifts.
+*   **Clock-In:** The digital timestamp marking the start of work, verified by GPS.
+*   **Rapid Order:** A specific order type designed for immediate (<24h) fulfillment.
+*   **Early Pay:** A financial feature allowing workers to withdraw accrued wages before the standard pay period ends.
+*   **Hub:** A specific physical location or venue belonging to a Client.
+*   **Compliance:** The state of having all necessary legal and safety documents verified.
diff --git a/internal/launchpad/assets/documents/prototype/web-application/architecture.md b/internal/launchpad/assets/documents/prototype/web-application/architecture.md
new file mode 100644
index 00000000..2647f7db
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/web-application/architecture.md
@@ -0,0 +1,154 @@
+# Web Application: Architecture Overview
+
+## 1. Executive Summary
+The **Krow Web Application** is the "Mission Control" for the entire Krow platform. It acts as a powerful administrative dashboard where clients and internal operations teams can see the "Big Picture" that mobile apps can't provide.
+
+While the mobile apps are for *doing* the work (checking in, posting a shift), the web app is for *managing* the business of that work. It allows users to analyze workforce performance, manage complex vendor relationships, handle high-volume invoicing, and use AI to optimize staffing strategies.
+
+## 2. High-Level Architecture
+The application is a modern **Single Page Application (SPA)** built using **React**. This means it loads once in the browser and then dynamically updates as the user interacts with it, providing a snappy, app-like experience without constantly reloading pages.
+
+It follows a **Component-Based Architecture**, where the user interface is built from small, reusable pieces (like buttons, charts, and tables) combined into complex dashboards.
+
+The system is structured into three primary layers:
+1.  **Presentation Layer (Views):** The dashboards and reports the user sees.
+2.  **State Management Layer (Store):** The "memory" of the app that keeps track of data while the user navigates (using Redux Toolkit).
+3.  **Data Access Layer (Services):** The bridge that fetches data from the backend or mock services (using React Query).
+
+## 3. Major Components & Modules
+
+### A. Dashboard & Overview Module
+*   **Responsibility:** Providing immediate situational awareness.
+*   **Key Features:** High-level metrics (Spend, Fill Rate), recent activity feeds, and quick access to critical alerts.
+*   **Purpose:** The landing page that answers "Is everything running smoothly right now?"
+
+### B. Analytics & Intelligence Module
+*   **Responsibility:** Turning raw data into actionable insights.
+*   **Key Features:**
+    *   **Savings Engine:** AI-driven recommendations to cut costs.
+    *   **Performance Matrix:** Evaluating vendor and worker reliability.
+    *   **Smart Strategies:** Data-backed suggestions for operational improvements.
+
+### C. Workforce & Operations Module
+*   **Responsibility:** Managing the people and the work.
+*   **Key Features:**
+    *   **Workforce Directory:** Searching and managing staff profiles.
+    *   **Shift Management:** Overseeing schedules and assignments.
+    *   **Time & Attendance:** Verifying hours worked.
+
+### D. Finance & Marketplace Module
+*   **Responsibility:** The "Business" side of the platform.
+*   **Key Features:**
+    *   **Invoicing:** Generating and paying bills.
+    *   **Marketplace:** Finding and onboarding new staffing vendors.
+    *   **Wallet:** Managing payment methods and transactions.
+
+### E. Support & Communication Module
+*   **Responsibility:** Facilitating help and interaction.
+*   **Key Features:** Help center, ticketing system, and potentially chat/messaging interfaces.
+
+## 4. Component Responsibilities
+
+| Component | Primary Responsibility | Example Task |
+| :--- | :--- | :--- |
+| **React Router** | Navigation | Switches the main view from "Dashboard" to "Invoices" when the sidebar link is clicked. |
+| **Redux Store** | Global State | Remembers the user's "Dark Mode" preference across all pages. |
+| **React Query** | Data Fetching & Caching | Fetches the "Monthly Spend" data once and keeps it ready so it doesn't need to reload every time the user looks at it. |
+| **Tailwind CSS** | Styling | Ensures all buttons are the exact same shade of blue and responsive on mobile devices. |
+| **Recharts** | Visualization | Draws the "Spend vs. Budget" line graph on the analytics page. |
+
+## 5. Data Flow
+
+1.  **Trigger:** An Operations Manager selects "Last 30 Days" on the Analytics Dashboard.
+2.  **Request:** The "Analytics Component" asks the "Data Layer" (React Query) for data matching that date range.
+3.  **Fetch:** The Data Layer checks if it already has this info. If not, it calls the API (or mock service).
+4.  **Processing:** The API returns raw numbers. The "Business Logic" calculates the percentage growth.
+5.  **Update:** The application state updates with the new figures.
+6.  **Render:** The charts on the screen automatically redraw themselves to show the new trend lines.
+
+## 6. External System Communication
+
+The Web App serves as the central hub connecting various services:
+
+*   **Backend API:** The primary source of truth for all business data.
+*   **Authentication Provider:** Secures access to the dashboard.
+*   **Data Analysis Services:** Connects to AI/ML engines for the "Smart Strategies" and savings recommendations.
+*   **Payment Gateways:** Integrates with financial providers for processing large invoice payments.
+
+## 7. Architectural Patterns
+
+*   **Feature-Sliced Design:** The project structure groups files by *feature* (e.g., `features/finance`, `features/analytics`) rather than technology. This means all the code related to "Invoicing" (the UI, the logic, the data calls) is in one place, making it easier to maintain.
+*   **Container/Presentational Pattern:** Logic-heavy components ("Containers") fetch data and pass it down to simple UI components ("Presentational") that just display it.
+*   **Single Source of Truth:** Uses Redux and React Query to ensure that if data changes in one place (e.g., a new invoice is created), every part of the app viewing that data updates instantly.
+
+## 8. Key Design Decisions
+
+*   **React + Vite:** Chosen for blazing-fast development speed and high performance in the browser.
+*   **Tailwind CSS:** A "utility-first" styling framework that allows for rapid UI development and easy maintenance of a consistent design system.
+*   **React Query (TanStack Query):** Handles the complex job of fetching, caching, and synchronizing server data, significantly reducing the amount of "boilerplate" code developers need to write.
+*   **Mock Data Services:** Similar to the mobile apps, the web app uses a robust mock data layer (`services/mocks.ts`) to simulate complex scenarios (like thousands of data points for analytics) without needing a full backend during the prototype phase.
+
+## 9. Overview Diagram
+```mermaid
+flowchart TD
+    subgraph WebApplication["Krow Web Application"]
+        direction TB
+
+        subgraph PresentationLayer["Presentation Layer (UI)"]
+            direction TB
+            Router["React Router"]
+            
+            subgraph FeatureModules["Feature Modules"]
+                DashUI["Dashboard & Overview"]
+                AnalyticsUI["Analytics & Intelligence"]
+                WorkforceUI["Workforce & Operations"]
+                FinanceUI["Finance & Marketplace"]
+                SupportUI["Support & Communication"]
+            end
+            
+            Router --> FeatureModules
+        end
+
+        subgraph StateManagement["State Management Layer"]
+            direction TB
+            Redux["Redux Store"]
+            ReactQuery["React Query Cache"]
+        end
+
+        subgraph DataLayer["Data Access Layer"]
+            direction TB
+            APIServices["API Services"]
+            MockServices["Mock Data Generator"]
+        end
+        
+        PresentationLayer --> StateManagement
+        StateManagement --> DataLayer
+    end
+
+    subgraph ExternalSystems["External Systems"]
+        direction TB
+        BackendAPI["Backend API"]
+        AuthService["Auth Provider"]
+        AI_Engine["Data Analysis/AI Service"]
+        PaymentGateway["Payment Gateway"]
+    end
+
+    DataLayer --> ExternalSystems
+    
+    %% Relationships & Data Flow
+    DashUI -- "Check Status" --> Redux
+    AnalyticsUI -- "Request Report" --> ReactQuery
+    ReactQuery -- "Fetch Data" --> APIServices
+    APIServices -- "API Call" --> BackendAPI
+    APIServices -- "Get AI Insights" --> AI_Engine
+    APIServices -- "Process Payment" --> PaymentGateway
+    MockServices -. "Simulation Mode" .-> ReactQuery
+
+    classDef layer fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#000
+    classDef module fill:#fff9c4,stroke:#fbc02d,stroke-width:1px,color:#000
+    classDef system fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,color:#000
+
+    class PresentationLayer,StateManagement,DataLayer layer
+    class DashUI,AnalyticsUI,WorkforceUI,FinanceUI,SupportUI module
+    class ExternalSystems system
+```
\ No newline at end of file
diff --git a/internal/launchpad/assets/documents/prototype/web-application/use-case.md b/internal/launchpad/assets/documents/prototype/web-application/use-case.md
new file mode 100644
index 00000000..a4f65c95
--- /dev/null
+++ b/internal/launchpad/assets/documents/prototype/web-application/use-case.md
@@ -0,0 +1,170 @@
+# Web Application: Use Case Overview
+
+This document details the primary business actions and user flows within the **Krow Web Application**. It is organized according to the logical workflows for each primary user role as defined in the system's architecture.
+
+---
+
+## 1. Access & Authentication (Common)
+
+### 1.1 Web Portal Login
+*   **Actor:** All Users (Admin, Client, Vendor)
+*   **Description:** Secure entry into the management console.
+*   **Main Flow:**
+    1. User enters email and password on the login screen.
+    2. System verifies credentials.
+    3. System determines user role (Admin, Client, or Vendor).
+    4. User is directed to their specific role-based dashboard.
+
+---
+
+## 2. Admin Workflows (Operations Manager)
+
+### 2.1 Global Operational Oversight
+*   **Actor:** Admin
+*   **Description:** Monitoring the pulse of the entire platform.
+*   **Main Flow:** User accesses Admin Dashboard -> Views all active orders across all clients -> Monitors user registration trends.
+
+### 2.2 Marketplace & Vendor Management
+*   **Actor:** Admin
+*   **Description:** Expanding the platform's supply network.
+*   **Main Flow:**
+    1. User navigates to Marketplace.
+    2. User invites a new Vendor via email.
+    3. User sets global default rates for roles.
+    4. User audits vendor performance scores.
+
+### 2.3 System Administration
+*   **Actor:** Admin
+*   **Description:** Configuring platform-wide settings and security.
+*   **Main Flow:** User updates system configurations -> Reviews security audit logs -> Manages internal support tickets.
+
+---
+
+## 3. Client Executive Workflows
+
+### 3.1 Strategic Insights (Savings Engine)
+*   **Actor:** Client Executive
+*   **Description:** Using AI to optimize labor spend.
+*   **Main Flow:**
+    1. User opens the Savings Engine.
+    2. User reviews identified cost-saving opportunities.
+    3. User clicks "Approve Strategy" to implement recommendations (e.g., vendor consolidation).
+
+### 3.2 Finance & Billing Management
+*   **Actor:** Client Executive / Finance Admin
+*   **Description:** Managing corporate financial obligations.
+*   **Main Flow:** User views all pending invoices -> Downloads detailed line-item reports -> Processes payments to Krow.
+
+### 3.3 Operations Overview
+*   **Actor:** Client Executive
+*   **Description:** High-level monitoring of venue operations.
+*   **Main Flow:** User views a summary of their venue orders -> Reviews ratings of assigned staff -> Monitors fulfillment rates.
+
+---
+
+## 4. Vendor Workflows (Staffing Agency)
+
+### 4.1 Vendor Operations (Order Fulfillment)
+*   **Actor:** Vendor Manager
+*   **Description:** Fulfilling client staffing requests.
+*   **Main Flow:**
+    1. User views incoming shift requests.
+    2. User selects a shift.
+    3. User uses the **Worker Selection Tool** to assign the best-fit staff.
+    4. User confirms assignment.
+
+### 4.2 Workforce Roster Management
+*   **Actor:** Vendor Manager
+*   **Description:** Maintaining their agency's supply of workers.
+*   **Main Flow:** User navigates to Roster -> Adds new workers -> Updates compliance documents and certifications -> Edits worker profiles.
+
+### 4.3 Vendor Finance
+*   **Actor:** Vendor Manager
+*   **Description:** Managing agency revenue and worker payouts.
+*   **Main Flow:** User views payout history -> Submits invoices for completed shifts -> Tracks pending payments from Krow.
+
+---
+
+## 5. Shared Functional Modules
+
+### 5.1 Order Details & History
+*   **Actor:** All Roles
+*   **Description:** Accessing granular data for any specific staffing request.
+*   **Main Flow:** User clicks any order ID -> System displays shift times, roles, assigned staff, and audit history.
+
+### 5.2 Invoice Detail View
+*   **Actor:** Admin, Client, Vendor
+*   **Description:** Reviewing the breakdown of costs for a billing period.
+*   **Main Flow:** User opens an invoice -> System displays worker names, hours worked, bill rates, and total totals per role.
+
+---
+
+# Use Case Diagram
+```mermaid
+flowchart TD
+    subgraph AccessControl [Access & Authentication]
+        Start[Start Web Portal] --> CheckSession{Check Session}
+        CheckSession -- Valid --> CheckRole{Check User Role}
+        CheckSession -- Invalid --> Login[Login Screen]
+        Login --> EnterCreds[Enter Credentials]
+        EnterCreds --> Verify{Verify}
+        Verify -- Success --> CheckRole
+        Verify -- Failure --> Error[Show Error]
+        
+        CheckRole -- Admin --> AdminDash[Admin Dashboard]
+        CheckRole -- Client --> ClientDash[Client Dashboard]
+        CheckRole -- Vendor --> VendorDash[Vendor Dashboard]
+    end
+
+    subgraph AdminWorkflows [Admin Workflows]
+        AdminDash --> GlobalOversight[Global Oversight]
+        GlobalOversight --> ViewAllOrders[View All Orders]
+        GlobalOversight --> ViewAllUsers[View All Users]
+        
+        AdminDash --> MarketplaceMgmt[Marketplace Management]
+        MarketplaceMgmt --> OnboardVendor[Onboard Vendor]
+        MarketplaceMgmt --> ManageRates[Manage Global Rates]
+        
+        AdminDash --> SystemAdmin[System Administration]
+        SystemAdmin --> ConfigSettings[Configure Settings]
+        SystemAdmin --> AuditLogs[View Audit Logs]
+    end
+
+    subgraph ClientWorkflows [Client Executive Workflows]
+        ClientDash --> ClientInsights[Strategic Insights]
+        ClientInsights --> SavingsEngine[Savings Engine]
+        SavingsEngine --> ViewOpp[View Opportunity]
+        ViewOpp --> ApproveStrategy[Approve Strategy]
+        
+        ClientDash --> ClientFinance[Finance & Billing]
+        ClientFinance --> ViewInvoices[View Invoices]
+        ClientFinance --> PayInvoice[Pay Invoice]
+        
+        ClientDash --> ClientOps[Operations Overview]
+        ClientOps --> ViewMyOrders[View My Orders]
+        ClientOps --> ViewMyStaff[View Assigned Staff]
+    end
+
+    subgraph VendorWorkflows [Vendor Workflows]
+        VendorDash --> VendorOps[Vendor Operations]
+        VendorOps --> ViewRequests[View Shift Requests]
+        ViewRequests --> AssignWorker[Assign Worker]
+        VendorOps --> ManageRoster[Manage Worker Roster]
+        ManageRoster --> UpdateWorkerProfile[Update Worker Profile]
+        
+        VendorDash --> VendorFinance[Vendor Finance]
+        VendorFinance --> ViewPayouts[View Payouts]
+        VendorFinance --> SubmitInvoice[Submit Invoice]
+    end
+
+    subgraph SharedModules [Shared Functional Modules]
+        ViewAllOrders -.-> OrderDetail[Order Details]
+        ViewMyOrders -.-> OrderDetail
+        ViewRequests -.-> OrderDetail
+        
+        AssignWorker -.-> WorkerSelection[Worker Selection Tool]
+        
+        ViewInvoices -.-> InvoiceDetail[Invoice Detail View]
+        SubmitInvoice -.-> InvoiceDetail
+    end
+```