649 lines
16 KiB
Markdown
649 lines
16 KiB
Markdown
# 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.
|