Revise M4 milestone planning with new requirements
Updated M4 milestone planning document to include new goals, acceptance criteria, and key rules for backend and frontend tasks.
This commit is contained in:
Achintha Isuru
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user