# M4 Milestone Planning --- ## Backend (BE) ### 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 --- ### 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. --- ### 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.