Files
Krow-workspace/docs/MILESTONES/M4/planning/m4-planning.md
2026-02-17 16:19:07 -05:00

16 KiB

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.

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.