Files
Krow-workspace/docs/MILESTONES/M4/planning/m4-planning.md
Achintha Isuru ca197f12e2 Revise M4 planning document title and content
Updated the title and removed introductory text for clarity.
2026-02-12 17:04:02 -05:00

16 KiB

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.

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.