Krow/Krow-workspace
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add Milestone 3 documentation including feature testing plan, demo notes, and demo flow details

Browse Source 
- Introduced comprehensive testing plan for Milestone 3 in m3-client-note.md
- Documented feedback and suggestions from demo sessions in m3-notes.md
- Created detailed demo flow for Milestone 3 in m3.md, outlining user interactions and expected outcomes
- Added planning tasks for Milestone 4 in m4-planning.md, covering backend and frontend development tasks, research, and business tasks
This commit is contained in:
Achintha Isuru
2026-02-12 16:33:16 -05:00
parent 368f28f354
commit fd47d84045
18 changed files with 829 additions and 1411 deletions
Download Patch File Download Diff File Expand all files Collapse all files

257
docs/MILESTONES/M3/demos/m3-client-note.md Normal file
View File

@@ -0,0 +1,257 @@
# KROW Workforce Platform — Feature Testing Plan for Milestone 3
**Version:** Milestone 3 (0.0.1-IlianaStaffM3 and 0.0.1-IlianaClientM3)
**Estimated Duration:** 25-30 minutes
---
## Required Applications
- Client Mobile Application (v0.0.1-IlianaClientM3)
- Staff Mobile Application (v0.0.1-IlianaStaffM3)
---
## 1. Testing Environment Setup
### Required Test Accounts
**Client Account (Business User):**
- Email: `legendary@krowd.com`
- Password: `Demo2026!`
- Client Name: "Krow"
**Staff Account (Worker):**
- Phone: `+15557654321`
- OTP Code: `123456` (testing mode)
- Name: "Mariana Torres"
### Prerequisites
1. ✅ Both apps installed on the device
2. ✅ Network connection stable
---
## 2. Testing Steps
### 2.1: Register Business (Client App)
**Purpose:** Show the client onboarding experience
**Steps:**
1. Open Client App → Tap "Create Account"
2. Enter business email, and password (not the provided test account credentials, use a new email for this step)
3. Navigate to the home page
**Observable Points:** :
- Empty dashboard, no orders, no workers, clean slate
---
### 2.2: Register Staff (Staff App)
**Purpose:** Show the worker onboarding experience
**Steps:**
1. Open Staff App → Tap "Sign Up"
2. Enter phone number and verify with OTP code (not the provided test account credentials, use a new phone number for this step)
3. Follow the onboarding process
4. Navigate to the home page
**Observable Points:** :
- Empty shifts list, no available work yet
---
### 2.3: Client Sign In with an Existing Account (Client App)
**Note:** Use the client demo account credentials provided above.
**Purpose:** Show the sign-in experience for returning users
**Steps:**
1. Close Client App and reopen it.
2. Tap "Sign In" button
3. Enter credentials:
- Email: `legendary@krowd.com`
- Password: `Demo2026!`
4. Tap "Sign In"
---
### 2.4: Client Views the Populated Dashboard (Client App)
**Purpose:** Show how the client app displays active operations
**Steps:**
1. After signing in, observe the home screen
2. Navigate through populated sections:
- Home: Coverage stats, upcoming shifts
- Orders: Posted shifts with workers assigned
- Coverage: Real-time worker status
**Observable Points:**
- Coverage percentage for today's shifts
- Workers checked in vs. needed
- Late workers alerts
- Today's estimated labor cost
---
### 2.5: Client Creates a New Hub (Client App)
**Purpose:** Show the hub creation process
**Steps:**
1. Navigate to Hubs page via the settings button in the top right corner of the home screen
2. Tap the "Hubs" button in the settings menu.
3. Tap the "+" icon at the bottom right of the hubs list, to open the hub creation form.
4. Fill in hub details:
- Hub name: "Downtown Convention Center"
- Address: Start typing and select an address.
5. Tap "Create Hub"
6. See the new hub appear in the hubs list
---
### 2.6: Client Creates New Order (Client App)
**Purpose:** Walk through the order creation process
**Steps:**:
1. Go back to the home screen.
2. Navigate to the "Orders" tab in the bottom navigation.
3. Tap the "+ Post" button on top right to open the order type selection screen.
4. Select "One-Time" from the order type options.
5. Fill in order details:
- Order name: "Summer Gala 2026"
- Date: [Select upcoming date]
- Hub: [Select existing hub]
- Add position: Server, Count: 3, Hours: 5PM-9PM
6. Tap "Create Order"
---
### 2.7: Client Views Order Details (Client App)
**Purpose:** View detailed shift information and worker assignments
**Steps:**
1. View the created order in the orders list on the order screen.
**Observable Points:**
- Event name and location
- Roles needed
- Clock in/out times
- Estimated cost
- Coverage percentage bar
---
### 2.8: Client Monitors Coverage Dashboard (Client App)
**Purpose:** Show real-time worker tracking capabilities
**Steps:**
1. Navigate to the "Coverage" tab in the bottom navigation.
2. Observe the worker status for active shifts.
**Observable Points:**
- Worker status (Checked In, En Route, Late, Not Arrived)
- Color-coded status badges (green, yellow, red)
- Worker information
---
### 2.9: Staff Logs In with Existing Account (Staff App)
**Note:** Use the staff demo account credentials provided above.
**Purpose:** Show the staff app sign-in experience for returning users
**Steps:**
1. Close the staff app and reopen it.
2. Tap "Log In" button
3. Enter phone number: `5557654321`
4. Tap "Send Code"
5. Enter OTP: `123456`
---
### 2.10: Staff Views Home Dashboard (Staff App)
**Purpose:** View worker's personalized dashboard
**Observable Points:**
- Welcome message with worker's name
- Today's Shifts section (confirmed shifts for today)
- Tomorrow's Shifts section
- Recommended shifts section
---
### 2.11: Staff Finds Available Shifts (Staff App)
**Purpose:** Show the shift search and discovery experience for workers
**Steps:**
1. Navigate to the "Shifts" tab in the bottom navigation.
2. Tap the "Find Shifts" button on top to view available shifts.
**Observable Points:**
- List of shifts
- Hourly rate prominently displayed
- Role requirements (e.g., "Bartender - Spring Gala")
- Date, time, and duration
**Note:**
>Due to the current order flow, newly created orders do not appear in the Find Shifts section, as it requires an approval from the vendor. This was discussed during the demo.
>We are actively updating this flow so orders will appear correctly in a future iteration.
---
### 2.12: Staff Applies for Shift (Staff App)
**Purpose:** Show the application process from worker side
**Steps:**
1. Tap on an available shift to view details
2. Review business name, location, pay, requirements
3. Tap "Book Shift" button
4. Tap "Book" on the confirmation dialog
4. See confirmation
---
### 2.13: Staff Views Confirmed Shifts (Staff App)
**Purpose:** Show worker's shift confirmation
**Observable Points:**
- Week-by-week calendar navigation
- Color-coded status (Confirmed, Pending, Completed)
- Quick access to shift details and directions
---
### 2.14: Staff Clock-In to Shift (Day of Event) (Staff App)
**Purpose:** Demonstrate the clock-in process
**Steps:**
1. Navigate to the clock-in page.
2. Use the "Clock In" slider to clock in.
**Observable Points:**
- Timestamp automatically recorded
- Status changes to "Checked In" with green indicator
---
### 2.15: Staff Clocks-Out of Shift (Day of Event) (Staff App)
**Purpose:** Demonstrate the clock-out process and shift completion
**Steps:**
1. Navigate to the clock-out page.
2. Use the "Clock Out" slider to clock out.
3. Navigate to the "My Shifts" section in the Shifts tab to see the updated status via the bottom navigation.
**Observable Points:**
- Clock-out timestamp automatically recorded
- Status changes to "Completed"
---
### 2.16: Staff Profile Management (Staff App)
**Purpose:** Demonstrate worker profile features and compliance management
**Steps:**
1. Navigate to Profile tab in bottom navigation
2. Review profile sections:
- **Profile Info:**
- **Emergency Contact:** Name, relationship, phone number
- **Bank Account:** Linked payment account for direct deposit
- **Tax Forms:** W-4, I-9 compliance documents
- **Time Card:** Historical shift records with hours and earnings

63
docs/MILESTONES/M3/demos/m3-notes.md Normal file
View File

@@ -0,0 +1,63 @@
# KROW M3 Demo — Test Feedback
**Date:** February 3, 2026
---
## Demo 1: Register Business & Show Empty States (Client App)
- **Flickering company name:** Every time I navigate to the home screen, I see "your company" for a moment before it changes to the real name.
- Creating a One-Time Order shows "No Vendors Available" — this is expected, OK.
**Suggestions: Achintha:**
- We need to have a shimmer loading state while fetching data, to avoid flickering and empty states.
---
## Demo 2: Register Staff & Show Empty States (Staff App)
**Onboarding — Add preferred work locations:**
- Suggestion: Use Google Maps to suggest only city names. Currently users can type anything, which will cause misspellings and inconsistent data. Important for the max distance feature.
**Home page:**
- Same flickering issue — shows "Krower" briefly before displaying the real name.
**Profile page:**
- Phone number should be read-only, or require re-verification if changed.
- Emergency contact: "Save & Continue" works, but shouldn't we navigate to the profile page after? Other flows do this.
- Tax Documents: Would be great to add a file uploader where our AI could identify documents and prefill fields.
- Bank Account: Need to plan real bank verification (KYC)? Ensure the account is real and belongs to the user. Also, I can list banks but I don't see how to change/switch bank.
**Home (empty state):**
- Clicking "Find shifts →" does nothing. But "Find Shifts" with the search icon works.
**My Availability:**
- Working. Some latency, but OK for now.
---
## Demo 5: Client Creates a New Hub
- Hub editing feature seems missing — we'll need this for NFC configuration later.
- No confirmation before deleting a hub.
---
## Demo 6: Client Creates New Order
- "Up Next (x)" counter is confusing. I created 2 orders but it shows "Up Next (1)". Sometimes shows 0 when navigating, then back to 1.
---
## Demo 8: Staff Logs In with Existing Account
- If you accidentally click "Sign Up" with an existing phone number, you get stuck:
1. OTP screen shows error: "This user already has a staff profile. Please log in"
2. Clicking back → login → same OTP error loop
3. Only fix: kill and restart the app
---
## Demo 10: Staff Browses Available Shifts
- **Blocker:** I don't see the shift I created as the Client.

348
docs/MILESTONES/M3/demos/m3.md Normal file
View File

@@ -0,0 +1,348 @@
# KROW Workforce Platform — Feature Demo Plan for Milestone 3
**Version:** Milestone 3 (v3.0)
**Date:** February 3, 2026
**Audience:** Business Stakeholders, Customer Engineers, Sales Teams
**Duration:** 25-30 minutes
---
## 1️⃣ Demo Overview
### Purpose
This demo showcases the progress of the milestone 3.
- **For Businesses (Client App):** One-time shift creation, worker management, real-time coverage tracking
- **For Workers (Staff App):** Easy access to available shifts, clock-in and profile management
- **Complete Workflow:** From shift posting and worker check-in and completion
### Estimated Demo Duration
**25-30 minutes**
---
## 2️⃣ Demo Environment Setup
### Required Test Accounts
**Client Account (Business User):**
- Email: `legendary@krowd.com`
- Password: `Demo2026!`
- Client Name: "Krow"
**Staff Account (Worker):**
- Phone: `+15557654321`
- OTP Code: `123456` (demo mode)
- Name: "Mariana Torres"
### Prerequisites
1. ✅ Both apps installed on demo devices (or simulators)
2. ✅ Network connection stable
3. ✅ Seed data is ready to be populated (the database should be empty at start)
### Make Commands Reference
| Command | Purpose |
|---------|---------|
| `make dataconnect-clean` | Clean the database before seeding |
| `make dataconnect-seed` | Populate the database with seed data for demo |
### Recent Fixes Applied
- ✅ Fixed 2 bugs on TaxForm: marital status and Citizenship Status now properly saved
- ✅ Fixed update screen after create or update TaxForm
- ✅ Created seed data script
- ✅ Created make commands to create and delete information in DataConnect
---
## 3️⃣ Demo Flows
### Demo 0: Show Empty Database
**Purpose:** Demonstrate the starting point before any data exists
**Steps:**
1. Run `make dataconnect-clean` to ensure database is empty
2. Show the empty database in Firebase console
---
### Demo 1: Register Business & Show Empty States (Client App)
**Purpose:** Show the client onboarding experience and empty states
**Steps:**
1. Open Client App → Tap "Create Account"
2. Enter business email, and password
3. Navigate to home page
4. **Point out:** Empty dashboard, no orders, no workers, clean slate
---
### Demo 2: Register Staff & Show Empty States (Staff App)
**Purpose:** Show the worker onboarding experience and empty states
**Steps:**
1. Open Staff App → Tap "Sign Up"
2. Enter phone number and verify with OTP code
3. Follow the onboarding process
4. Navigate to home page
5. **Point out:** Empty shifts list, no available work yet
---
### 🔄 PAUSE: Populate Database
Run the seeding command:
```bash
make dataconnect-seed
```
---
### Demo 3: Client Logs In with Existing Account
**Purpose:** Show the sign-in experience for returning users
**Screen:** Get Started → Sign In
**Steps:**
1. Restart Client App
2. Tap "Sign In" button
3. Enter credentials:
- Email: `legendary@krowd.com`
- Password: `Demo2026!`
4. Tap "Sign In"
---
### Demo 4: Client Views Populated Dashboard
**Purpose:** Show how the client app displays active operations
**Steps:**
1. After signing in, observe the home screen
2. Navigate through populated sections:
- Home: Coverage stats, upcoming shifts
- Orders: Posted shifts with workers assigned
- Coverage: Real-time worker status
**What to Notice:**
- Coverage percentage for today's shifts
- Workers checked in vs. needed
- Late workers alerts
- Today's estimated labor cost
---
### Demo 5: Client Creates a New Hub
**Screen:** Hubs Tab → "Add Hub" button
**Steps:**
1. Navigate to Hubs tab in bottom navigation
2. Tap the "+" or "Add Hub" button
3. Fill in hub details:
- Hub name: "Downtown Convention Center"
- Address: Start typing and select from Google Places autocomplete
4. Tap "Create Hub"
5. See the new hub appear in the hubs list
---
### 📋 Main Demo Flow Explanation
```
Client Posts Shift [O1]
↓
*Vendor Accepts the Shift (Missing for now) / Vendor is selected by client* [O2]
↓
Worker Searches for a Shift [O3]
↓
Worker Applies [O4]
↓
Confirmation (Missing for now, auto-confirmed)* [O5]
↓
Worker Checks In [O6]
↓
Shift Completed [O7]
```
---
### Demo 6: Client Creates New Order - [O1]
**Purpose:** Walk through the shift creation process
**Screen:** Orders Tab → "Post" button
**What to Fill:**
- Order name: "Spring Gala 2026"
- Date: [Select upcoming date]
- Location: [Select existing hub]
- Add position: Server, Count: 3, Hours: 5PM-9PM
---
### Demo 7: Client Views Order Details
**Purpose:** Show detailed shift information and worker assignments (second part is missing for now)
**Screen:** Orders Tab → Tap on any order card
**What to Notice:**
- Event name and location
- Roles needed (e.g., "2 Servers")
- Clock in/out times
- Estimated cost
- Coverage percentage bar
---
### Demo 8: Staff Logs In with Existing Account
**Purpose:** Show the worker sign-in experience
**Screen:** Get Started → Sign In with Phone
**Steps:**
1. Restart the staff app
2. Enter phone number: `5557654321`
3. Tap "Send Code"
4. Enter OTP: `123456`
---
### Demo 9: Staff Views Home Dashboard
**Purpose:** Show worker's personalized dashboard
**What to Notice:**
- Today's Shifts section (confirmed shifts for today)
- Tomorrow's Shifts section
---
### Demo 10: Staff Browses Available Shifts - [O3]
**Purpose:** Show how workers discover and view available work
**Screen:** Shifts → "Find Work"
**What to Notice:**
- List of shifts matching worker skills
- Hourly rate prominently displayed
- Role requirements (e.g., "Bartender - Spring Gala")
- Date, time, and duration
---
### Demo 11: Staff Applies for Shift - [O4]
**Purpose:** Show the application process from worker side
**Screen:** Shift Details → "Book" Shift button
**Steps:**
1. Tap on an available shift to view details
2. Review business name, location, pay, requirements
3. Tap "Book" Shift button
4. See confirmation
---
### Demo 12: Staff Views Confirmed Shifts - [O5]
**Purpose:** Show worker's shift management interface
**Screen:** Shifts Tab → "My Shifts"
**What to Notice:**
- Week-by-week calendar navigation
- Color-coded status (Confirmed, Pending, Completed)
- Quick access to shift details and directions
---
### Demo 13: Client Monitors Coverage Dashboard - [O5]
**Purpose:** Show real-time worker tracking capabilities
**Screen:** Client App → Coverage Tab
**What to Notice:**
- Live worker status (Checked In, En Route, Late, Not Arrived)
- Color-coded status badges (green, yellow, red)
- Worker information
---
### Demo 14: Staff Clock-In to Shift (Day of Event) - [O6]
**Purpose:** Demonstrate the clock-in process
**Screen:** Clockin page → "Clock In" slider
**What to Notice:**
- Timestamp automatically recorded
- Status changes to "Checked In" with green indicator
---
### Demo 15: Client Sees Clock-In Update - [O6]
**Purpose:** Show cross-app interaction and real-time updates
**Screen:** Client App → Coverage Tab
**Action:** Press the update button on the top right to refresh worker statuses
**What to Notice:**
- Status update
- User status changes to "Checked In"
- Check-in time displayed
---
### Demo 16: Staff Clocks-Out of Shift - [O7]
**Purpose:** Demonstrate the clocks-out process and shift completion
**Screen:** Clockin page -> Clock-out slider
**What to Notice:**
- Clock-out timestamp automatically recorded
- Status changes to "Completed"
- Total hours worked calculated automatically
---
### Demo 17: Client Views Completed Shift in Coverage - [O7]
**Purpose:** Show how completed shifts appear in the client app
**Screen:** Client App → Coverage Tab
**Action:** Press the refresh button to update worker statuses
**What to Notice:**
- Worker status changes to "Completed"
- Check-out time displayed alongside check-in time
- Total hours worked visible
- Shift marked as complete in orders list
- Cost finalized based on actual hours
---
### Demo 18: Staff Profile Management
**Purpose:** Demonstrate worker profile features and compliance management
**Screen:** Staff App → Profile Tab
**Steps:**
1. Navigate to Profile tab in bottom navigation
2. Review profile sections:
- **Profile Info:**
- **Emergency Contact:** Name, relationship, phone number
- **Bank Account:** Linked payment account for direct deposit
- **Tax Forms:** W-9, I-9 compliance documents *(bugs fixed: marital status and Citizenship Status now work properly)*
- **Time Card:** Historical shift records with hours and earnings
---
## 4️⃣ Customer Handover Checklist
### Deliverables
- [ ] Android apps (Client and Staff)
- [ ] Demo account credentials (see below)
### Demo Accounts
| Account | Credentials |
|---------|-------------|
| **Client** | Email: `legendary@krowd.com` / Password: `Demo2026!` |
| **Staff** | Phone: `+15557654321` / OTP: `123456` (demo mode) |

420
docs/MILESTONES/M4/planning/m4-planning.md Normal file
View File

@@ -0,0 +1,420 @@
# **Development Tasks**
These are written to be readable by a project manager and easy to translate into GitHub issues later.
Each item keeps a question-style title and includes a lightweight issue outline (goal, scope, acceptance criteria).
## **BE**
### Validate shift acceptance by a worker
- **Goal**: Prevent workers from accepting shifts they are not eligible to accept.
- **Where**: Backend validation (server-side).
- **Key rules (M4)**
- Prevent accepting overlapping shifts.
- If a shift is already accepted in that time window, reject the accept action.
- **Design requirement**
- Make the algorithm scalable so future shift-acceptance rules can be added without rewriting core logic.
- **Acceptance criteria**
- Backend rejects overlapping acceptance with a clear error reason.
- Validation is enforced even if the client app is bypassed.
### Validate shift creation by a client
- **Goal**: Ensure shifts/orders created by clients meet required criteria.
- **Where**: Backend validation (server-side).
- **Key rules (M4)**
- Add a *soft check* for minimum shift hours when creating an order.
- When a client creates an order, check if shift hours are below the vendor minimum.
- Current minimum hours: **5 hours**.
- **FE dependency**
- Also add a FE validation (user feedback) in addition to BE enforcement.
- **Design requirement**
- Make the algorithm scalable so future creation rules can be added.
- **Acceptance criteria**
- Backend returns a consistent validation response when the minimum-hours check fails.
- FE shows a clear validation message before submission (soft check).
### Enforce cancellation policy (no cancellations within 24 hours)
- **Goal**: Prevent cancellations within 24 hours of shift start time.
- **Where**: Backend enforcement.
- **Open decision**
- Finalize the penalty for cancellations within this window.
- **Acceptance criteria**
- Backend blocks cancellation attempts inside the 24-hour window.
- API response communicates the policy reason and references the penalty (once finalized).
### Implement worker documentation upload process
- **Goal**: Allow workers to upload required documents (e.g., certifications, tax forms) securely.
- **Where**: Backend (storage + linking).
- **Scope**
- Upload flow.
- Store documents.
- Link documents to the worker profile.
- **Acceptance criteria**
- Uploaded documents are stored securely and retrievable by authorized parties.
- Each upload is reliably associated with the correct worker profile.
### Parse uploaded documentation for verification
- **Goal**: Extract relevant info from uploaded documents to assist verification.
- **Where**: Backend.
- **Policy requirement**
- Manual verification by the client must still exist even if AI verification passes.
- **Acceptance criteria**
- Parsed fields are stored in a structured format for review.
- Client can manually verify/override AI results.
### Support attire upload for workers
- **Goal**: Allow workers to upload attire images for verification.
- **Where**: Backend.
- **Acceptance criteria**
- Attire images can be uploaded and linked to the worker profile.
### Verify attire images against shift dress code
- **Goal**: Verify uploaded attire meets dress code requirements.
- **Where**: Backend.
- **Policy requirement**
- Manual verification by the client must still exist even if AI verification passes.
- **Acceptance criteria**
- Verification results are stored and visible to the client for manual review.
### Support shifts requiring "awaiting confirmation" status
- **Goal**: Support shifts where the worker must manually confirm before the shift becomes active.
- **Where**: Backend.
- **Acceptance criteria**
- Shift can enter an "awaiting confirmation" state.
- Worker confirmation transitions the shift to the next expected active state.
### Enable NFC-based clock-in and clock-out
- **Goal**: Allow attendance via NFC.
- **Where**: Backend tasks (APIs/events/storage to support NFC clock-in/out).
- **Acceptance criteria**
- Backend can record NFC clock-in/out events with appropriate validation and auditing.
### Implement worker profile visibility settings
- **Goal**: Allow workers to hide their profile from clients if they choose.
- **Where**: Backend tasks (visibility settings + enforcement).
- **Acceptance criteria**
- Worker can change visibility setting.
- Backend enforces visibility in client-facing queries.
### Support rapid order parsing (voice and text) using AI
- **Goal**: Let clients create orders by describing needs in voice/text.
- **Where**: Backend tasks (parsing + mapping).
- **Notes**
- Always map the output similar to **one-time order creation**.
- **Acceptance criteria**
- Backend returns a structured draft order that matches the one-time order model.
### Personalize shifts shown to workers (auto match)
- **Goal**: Show worker-personalized shifts.
- **Where**: Backend matching/filtering logic.
- **Inputs (M4)**
- Preferred locations.
- Experience.
- **Acceptance criteria**
- Worker shift feed is personalized based on these inputs.
### What backend work is needed to support recurring order and reorder?
- **Goal**: Enable recurring orders and reorder.
- **Where**: Backend.
- **Acceptance criteria**
- Backend can create and manage recurring orders and support reorder actions.
### What backend work is needed to support permanent order and reorder?
- **Goal**: Enable permanent orders and reorder.
- **Where**: Backend.
- **Acceptance criteria**
- Backend can create and manage permanent orders and support reorder actions.
### Backend support for reports page (client mobile)
- **Goal**: Provide APIs/data needed to render the main reports entry and summary experience.
- **Where**: Backend.
- **Acceptance criteria**
- Reports API contracts are defined and documented.
- Client can load the reports page without placeholder data.
### Backend support for "Daily ops" report (client mobile)
- **Goal**: Provide the data required for the Daily ops report.
- **Where**: Backend.
- **Acceptance criteria**
- Daily ops report API returns all fields required by the UI.
- Response is documented (including filters/date ranges, if applicable).
### Backend support for "Spend report" (client mobile)
- **Goal**: Provide the data required for the Spend report.
- **Where**: Backend.
- **Acceptance criteria**
- Spend report API returns all fields required by the UI.
- Response is documented (including filters/date ranges, if applicable).
### Backend support for "Coverage report" (client mobile)
- **Goal**: Provide the data required for the Coverage report.
- **Where**: Backend.
- **Acceptance criteria**
- Coverage report API returns all fields required by the UI.
- Response is documented (including filters/date ranges, if applicable).
### Backend support for "No-show" report (client mobile)
- **Goal**: Provide the data required for the No-show report.
- **Where**: Backend.
- **Acceptance criteria**
- No-show report API returns all fields required by the UI.
- Response is documented (including filters/date ranges, if applicable).
### Backend support for "Performance report" (client mobile)
- **Goal**: Provide the data required for the Performance report.
- **Where**: Backend.
- **Acceptance criteria**
- Performance report API returns all fields required by the UI.
- Response is documented (including filters/date ranges, if applicable).
### Calculate the 3 AI insights for the client mobile reports page
- **Goal**: Produce the three AI insights shown on the reports page.
- **Where**: Backend.
- **Acceptance criteria**
- Insights are generated consistently and returned in the reports API response.
## **FE**
### **Staff mobile application**
### Show Google Maps location in worker shift details
- **Goal**: Display shift location on a map.
- **Acceptance criteria**
- Shift details page shows the correct location using Google Maps.
### Show shift requirements in worker shift details
- **Goal**: Make requirements visible before acceptance.
- **Acceptance criteria**
- Shift details page includes a requirements section for that shift.
- **Details**
- The main goal is to have list the the required attires in the requirement section but if there are any other requirements we can also list them there.
### Implement attire screen in worker app
- **Goal**: Let workers understand attire requirements and submit attire for review.
- **Scope (M4)**
- Show the list of **MUST HAVE** attire items.
- Show the list of **NICE TO HAVE** attire items.
- Allow workers to upload images of their attire for verification.
- Show uploaded attire images in the worker profile.
- **Acceptance criteria**
- Attire screen renders required lists and supports image upload flow.
- Uploaded images appear in the worker profile UI.
### Implement FAQ screen in worker app
- **Goal**: Provide common answers in-app.
- **Acceptance criteria**
- Worker app includes an FAQ screen accessible from appropriate navigation.
### Implement Privacy and Security screen in worker app
- **Goal**: Provide key privacy/security controls and documents.
- **Scope (M4)**
- Profile visibility setting.
- Terms of service (use a generated placeholder for now; replace with final for launch).
- Privacy policy (use a generated placeholder for now; replace with final for launch).
- **Acceptance criteria**
- Screen is accessible and displays all items above.
### Restrict navigation when worker profile is incomplete
- **Goal**: Reduce access until onboarding/profile completion.
- **Acceptance criteria**
- If the user has not completed their profile, only show **Profile** and **Home**.
### **Client mobile application**
### Implement rapid order creation (voice + text) in client mobile app
- **Goal**: Allow clients to quickly create same-day orders by describing needs via voice/text.
- **Scope (M4)**
- Capture voice/text input.
- Send input for parsing.
- Populate a screen equivalent to the one-time order creation screen so the client can adjust before finalizing.
- Always map similar to one-time order creation (handles same-day orders).
- **Acceptance criteria**
- Parsed output populates the one-time order creation UI correctly.
- Client can edit and successfully submit the order.
### Implement recurring order in client mobile app
- **Goal**: Allow clients to create recurring orders.
- **Scope (M4)**
- Create a recurring order UI flow.
- **Acceptance criteria**
- Client can create and submit a recurring order successfully.
### Implement permanent order in client mobile app
- **Goal**: Allow clients to create permanent orders.
- **Scope (M4)**
- Create a permanent order UI flow.
- **Acceptance criteria**
- Client can create and submit a permanent order successfully.
### Update reorder modal to support order types
- **Goal**: Ensure reorder works across supported order types.
- **Acceptance criteria**
- Reorder modal reflects the correct order type and fields.
### Complete reports interface with AI insights (client mobile)
- **Goal**: Implement the main reports UI and display AI insights.
- **Dependencies**
- Requires backend reports APIs and AI insights availability.
- **Acceptance criteria**
- Reports interface is complete and shows AI insights (no placeholder UI).
### Complete "Daily ops" report UI (client mobile)
- **Goal**: Implement the Daily ops report screen.
- **Dependencies**
- Requires backend Daily ops report support.
- **Acceptance criteria**
- Daily ops report UI is complete and renders real data.
### Complete "Spend report" UI (client mobile)
- **Goal**: Implement the Spend report screen.
- **Dependencies**
- Requires backend Spend report support.
- **Acceptance criteria**
- Spend report UI is complete and renders real data.
### Complete "Coverage report" UI (client mobile)
- **Goal**: Implement the Coverage report screen.
- **Dependencies**
- Requires backend Coverage report support.
- **Acceptance criteria**
- Coverage report UI is complete and renders real data.
### Complete "No-show" report UI (client mobile)
- **Goal**: Implement the No-show report screen.
- **Dependencies**
- Requires backend No-show report support.
- **Acceptance criteria**
- No-show report UI is complete and renders real data.
### Complete "Performance report" UI (client mobile)
- **Goal**: Implement the Performance report screen.
- **Dependencies**
- Requires backend Performance report support.
- **Acceptance criteria**
- Performance report UI is complete and renders real data.
### Build dedicated interface to display hub details
- **Goal**: Show hub details in a dedicated UI.
- **Acceptance criteria**
- Hub details page exists and displays hub information.
### Enable hub editing (separate page)
- **Goal**: Allow hub editing via a dedicated screen.
- **Acceptance criteria**
- Separate edit hub page exists and updates the hub data.
# **Research Tasks**
### Validate worker SSN number in the US
- **Goal**: Identify a viable SSN validation approach.
- **Scope (research)**
- Research third-party services/APIs that provide SSN validation.
- Evaluate cost, reliability, and integration effort.
- Outline an integration plan and highlight risks.
### Validate worker bank account details in the US
- **Goal**: Identify a viable bank account validation approach.
- **Scope (research)**
- Research third-party services/APIs for bank account validation.
- Evaluate cost, reliability, and integration effort.
- Outline an integration plan and highlight risks.
- Note: legacy app only uses soft FE checks; M4 aims for a proper validation process.
### What payment platforms do we want to integrate for processing payments to workers?
- **Goal**: Select a payout/payment platform.
- **Scope (research)**
- Research platforms (e.g., Stripe, PayPal, Square) that support payouts.
- Evaluate cost, reliability, and integration effort.
- Outline an integration plan and highlight risks.
### Implement test cases for 2 web dashboard features using agent-browser
- **Goal**: Add automated test coverage runnable via <https://agent-browser.dev/>.
- **Scope (research + spike)**
- Research how to implement test cases for web apps using the agent browser.
# **Business Tasks**
### Create template model for PDF reports in client and web apps
- **Goal**: Align report format across platforms.
- **Acceptance criteria**
- A shared template model is defined and ready to implement.
### Handle operational risk scenarios that disadvantage clients
- **Goal**: Define policies for common operational issues.
- **Scenarios (M4)**
- Worker is a no-show.
- Shifts are not getting enough applicants.
- **Acceptance criteria**
- Written policy decisions exist and are ready to translate into product rules.
### Finalize terms of service and privacy policy for mobile apps
- **Goal**: Provide legal documents for launch readiness.
- **Acceptance criteria**
- Terms of service and privacy policy drafts exist and are approved for implementation.
### Handle worker data requests
- **Goal**: Define a process for worker data requests.
- **Acceptance criteria**
- A documented workflow exists (intake, verification, fulfillment, timelines).
### How should we rephrase key terminology in the app (for clarity and accuracy)?
- **Goal**: Use consistent product language.
- **Topics (M4)**
- Worker registration: is it "signup" or "onboarding"?
- Context: workers are expected to be attached to a vendor; the flow is closer to onboarding (phone number + OTP) than self-service signup.
- Worker profile visibility: is it "profile visibility" or "availability status"?
- Context: workers are not fully invisible; they are marking themselves unavailable.
- What do we mean by "auto match"?
- Should this exist by default anyway?
- Is this only a marketing item?
- These are just examples; the discussion may surface additional terminology decisions.
- **Acceptance criteria**
- A terminology decision list exists with approved wording.