diff --git a/docs/MILESTONES/M4/planning/m4-planning.md b/docs/MILESTONES/M4/planning/m4-planning.md
index 91c54af7..caa59eaf 100644
--- a/docs/MILESTONES/M4/planning/m4-planning.md
+++ b/docs/MILESTONES/M4/planning/m4-planning.md
@@ -1,417 +1,645 @@
-# **M4 Milestone Planning**
-
-## **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.
+# M4 Milestone Planning
 
-### 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 (BE)
 
-### Backend support for "Daily ops" report (client mobile)
+### Make Order creation flow a transaction using cloud functions
+**Goal:** Make Order creation flow a transaction using cloud functions
+**Based on:** https://github.com/Oloodi/krow-workforce/issues/420
+---
 
-- **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).
+### Validate Shift Acceptance by a Worker
 
-### Backend support for "Spend report" (client mobile)
+**Goal:** Prevent workers from accepting shifts they are not eligible to accept.
 
-- **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).
+**Where:** Backend validation (server-side).
 
-### Backend support for "Coverage report" (client mobile)
+#### Key Rules (M4)
+- Prevent accepting overlapping shifts. If a shift is already accepted in that time window, reject the accept action.
 
-- **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).
+#### Design Requirement
+Make the algorithm scalable so future shift-acceptance rules can be added without rewriting core logic.
 
-### Backend support for "No-show" report (client mobile)
+#### Acceptance Criteria
+- Backend rejects overlapping acceptance with a clear error reason.
+- Validation is enforced even if the client app is bypassed.
 
-- **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)
+### Validate Shift Creation by a Client
 
-- **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).
+**Goal:** Ensure shifts/orders created by clients meet required criteria.
 
-### Calculate the 3 AI insights for the client mobile reports page
+**Where:** Backend validation (server-side).
 
-- **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.
+#### 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**
+#### FE Dependency
+Also add a FE validation (user feedback) in addition to BE enforcement.
 
-### **Staff mobile application**
+#### Design Requirement
+Make the algorithm scalable so future creation rules can be added.
 
-### Show Google Maps location in worker shift details
+#### Acceptance Criteria
+- Backend returns a consistent validation response when the minimum-hours check fails.
+- FE shows a clear validation message before submission (soft check).
 
-- **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
+### Enforce Cancellation Policy (No Cancellations Within 24 Hours)
 
-- **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.
+**Goal:** Prevent cancellations within 24 hours of shift start time.
 
-### Implement attire screen in worker app
+**Where:** Backend enforcement.
 
-- **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.
+#### Open Decision
+Finalize the penalty for cancellations within this window.
 
-### Implement FAQ screen in worker app
+#### Acceptance Criteria
+- Backend blocks cancellation attempts inside the 24-hour window.
+- API response communicates the policy reason and references the penalty (once finalized).
 
-- **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
+### Implement Worker Documentation Upload Process
 
-- **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.
+**Goal:** Allow workers to upload required documents (e.g., certifications, tax forms) securely.
 
-### Restrict navigation when worker profile is incomplete
+**Where:** Backend (storage + linking).
 
-- **Goal**: Reduce access until onboarding/profile completion.
-- **Acceptance criteria**
-  - If the user has not completed their profile, only show **Profile** and **Home**.
+#### Scope
+- Upload flow.
+- Store documents.
+- Link documents to the worker profile.
 
-### **Client mobile application**
+#### Acceptance Criteria
+- Uploaded documents are stored securely and retrievable by authorized parties.
+- Each upload is reliably associated with the correct worker profile.
 
-### 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.
+### Parse Uploaded Documentation for Verification
 
-### Implement recurring order in client mobile app
+**Goal:** Extract relevant info from uploaded documents to assist verification.
 
-- **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.
+**Where:** Backend.
 
-### Implement permanent order in client mobile app
+#### Policy Requirement
+Manual verification by the client must still exist even if AI verification passes.
 
-- **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.
+#### Acceptance Criteria
+- Parsed fields are stored in a structured format for review.
+- Client can manually verify/override AI results.
 
-### 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.
+### Support Attire Upload for Workers
 
-### Complete reports interface with AI insights (client mobile)
+**Goal:** Allow workers to upload attire images for verification.
 
-- **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).
+**Where:** Backend.
 
-### Complete "Daily ops" report UI (client mobile)
+#### Acceptance Criteria
+- Attire images can be uploaded and linked to the worker profile.
 
-- **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)
+### Verify Attire Images Against Shift Dress Code
 
-- **Goal**: Implement the Spend report screen.
-- **Dependencies**
-  - Requires backend Spend report support.
-- **Acceptance criteria**
-  - Spend report UI is complete and renders real data.
+**Goal:** Verify uploaded attire meets dress code requirements.
 
-### Complete "Coverage report" UI (client mobile)
+**Where:** Backend.
 
-- **Goal**: Implement the Coverage report screen.
-- **Dependencies**
-  - Requires backend Coverage report support.
-- **Acceptance criteria**
-  - Coverage report UI is complete and renders real data.
+#### Policy Requirement
+Manual verification by the client must still exist even if AI verification passes.
 
-### Complete "No-show" report UI (client mobile)
+#### Acceptance Criteria
+- Verification results are stored and visible to the client for manual review.
 
-- **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)
+### Support Shifts Requiring "Awaiting Confirmation" Status
 
-- **Goal**: Implement the Performance report screen.
-- **Dependencies**
-  - Requires backend Performance report support.
-- **Acceptance criteria**
-  - Performance report UI is complete and renders real data.
+**Goal:** Support shifts where the worker must manually confirm before the shift becomes active.
 
-### Build dedicated interface to display hub details
+**Where:** Backend.
 
-- **Goal**: Show hub details in a dedicated UI.
-- **Acceptance criteria**
-  - Hub details page exists and displays hub information.
+#### Acceptance Criteria
+- Shift can enter an "awaiting confirmation" state.
+- Worker confirmation transitions the shift to the next expected active state.
 
-### 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.
+### Enable NFC-Based Clock-In and Clock-Out
 
-# **Research Tasks**
+**Goal:** Allow attendance via NFC.
 
-### Validate worker SSN number in the US
+**Where:** Backend tasks (APIs/events/storage to support NFC clock-in/out).
 
-- **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.
+#### Acceptance Criteria
+- Backend can record NFC clock-in/out events with appropriate validation and auditing.
 
-### 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.
+### Implement Worker Profile Visibility Settings ✅
 
-### What payment platforms do we want to integrate for processing payments to workers?
+**Goal:** Allow workers to hide their profile from clients if they choose.
 
-- **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.
+**Where:** Backend tasks (visibility settings + enforcement).
 
-### Implement test cases for 2 web dashboard features using agent-browser
+#### Acceptance Criteria
+- Worker can change visibility setting.
+- Backend enforces visibility in client-facing queries.
 
-- **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**
+### Support Rapid Order Parsing (Voice and Text) Using AI
 
-### Create template model for PDF reports in client and web apps
+**Goal:** Let clients create orders by describing needs in voice/text.
 
-- **Goal**: Align report format across platforms.
-- **Acceptance criteria**
-  - A shared template model is defined and ready to implement.
+**Where:** Backend tasks (parsing + mapping).
 
-### Handle operational risk scenarios that disadvantage clients
+#### Notes
+Always map the output similar to one-time order creation.
 
-- **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.
+#### Acceptance Criteria
+- Backend returns a structured draft order that matches the one-time order model.
 
-### 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.
+### Personalize Shifts Shown to Workers (Auto Match)
 
-### Handle worker data requests
+**Goal:** Show worker-personalized shifts.
 
-- **Goal**: Define a process for worker data requests.
-- **Acceptance criteria**
-  - A documented workflow exists (intake, verification, fulfillment, timelines).
+**Where:** Backend matching/filtering logic.
 
-### How should we rephrase key terminology in the app (for clarity and accuracy)?
+#### Inputs (M4)
+- Preferred locations.
+- Experience.
 
-- **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.
+#### Acceptance Criteria
+- Worker shift feed is personalized based on these inputs.
 
+---
+
+### Recurring Order and Reorder — Backend Support
+
+**Goal:** Enable recurring orders and reorder.
+
+**Where:** Backend.
+
+#### Acceptance Criteria
+- Backend can create and manage recurring orders and support reorder actions.
+
+---
+
+### Permanent Order and Reorder — Backend Support
+
+**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 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.
+
+---
+
+## Frontend (FE)
+
+### Maintain Auth Session (Client and Staff Mobile)
+
+**Goal:** Maintain the authentication session of the client and staff mobile application.
+
+#### Details
+Currently when the user restarts the application they are prompted to login. This UX barrier should be removed — if a valid authentication session is available, use it instead of prompting the user to re-login.
+
+#### Acceptance Criteria
+- The authentication session of the client and staff mobile applications is maintained across restarts.
+
+---
+
+### Enable iOS Deployment
+
+**Goal:** Enable iOS deployment of both applications.
+
+---
+
+## 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.
+
+#### Details
+The main goal is to list the required attires in the requirements section, but any other requirements can also be listed there.
+
+#### Acceptance Criteria
+- Shift details page includes a requirements section for that shift.
+
+---
+
+### 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**.
+
+---
+
+### Preferred Location Edit
+
+**Goal:** Create a separate page to edit the preferred locations of the staff.
+
+---
+
+## Client Mobile Application
+
+### Hide Edit Icon for Past or Completed Orders
+
+**Goal:** In the client application view order screen, hide the edit icon for orders that are in the past or completed.
+
+---
+
+### Implement Rapid Order Creation (Voice + Text)
+
+**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
+
+**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
+
+**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
+
+**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
+
+**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
+
+**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
+
+**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
+
+**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
+
+**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.
+
+---
+
+### Payment Platform Research for Worker Payouts
+
+**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 [agent-browser.dev](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 (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).
+
+---
+
+### Rephrase Key Terminology in the App
+
+**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.
+
+- **"Auto match":** What do we mean by this?
+  - 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.