Delete outdated demo plan for Milestone 3 and replace with new feature testing plan; add detailed testing steps and feedback notes for client and staff applications; outline development tasks for Milestone 4 including backend and frontend requirements; establish research and business tasks for operational improvements and compliance.
This commit is contained in:
Achintha Isuru
@@ -10,8 +10,6 @@
|
||||
- Fix the location field in CoverageShiftRole to use the correct fallback logic.
|
||||
- line 125 remove redundant location values.
|
||||
|
||||
- Update the dataconnect docs.
|
||||
- Track `lat` and `lng` in the staff preferred work locations (for now we are only storing the name).
|
||||
- Change the name of the dataconnect connector replacing the "ExampleConnecter" with "KrowConnecter"
|
||||
|
||||
- ` final String status;` in `OrderItem` make it an enum.
|
||||
@@ -25,6 +23,8 @@
|
||||
|
||||
|
||||
|
||||
- How to check if the shift can be accepted by a worker?
|
||||
- if a shift is already accepted in that time
|
||||
|
||||
- track minimum shift hours in the staff profile and show a warning if they try to apply for shifts that are below their minimum hours.
|
||||
- this need to be added in the BE and also a FE validation (5 hrs).
|
||||
@@ -51,4 +51,125 @@
|
||||
- How do we handle the current bank account verifcaiton in the current legacy application.
|
||||
- We need have a show a list of clothing items in the staff app -> shift page.
|
||||
- Template models for the pdf reports in the client and web apps.
|
||||
- remove `any` type and replace it with the correct types in the codebase.
|
||||
- remove `any` type and replace it with the correct types in the codebase.
|
||||
|
||||
|
||||
- What is the worker signup process
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Developement Tasks
|
||||
|
||||
## BE
|
||||
- Shift acceptance validation by a worker
|
||||
- How do we check if a shift can be accepted by a worker?
|
||||
- if a shift is already accepted in that time
|
||||
- we need to prevent accepting overlapping shifts.
|
||||
- Make the alogrithm sclable which enables to add future rules for shift acceptance.
|
||||
- This validation should be done in BE.
|
||||
- Shift creation validation by a client
|
||||
- Implement validation logic to ensure that shifts created by clients meet certain criteria
|
||||
- This validation should be done in BE.
|
||||
- CURRENTLY only add a Soft check for minimum shift hours when creating an order by a client
|
||||
- When a client is creating an order, we need to check if the shift hours are below the minimum hours set by the vendor.
|
||||
- This validation should be done in BE and also a FE validation
|
||||
- Current minimum hours is 5 hrs.
|
||||
- Make the alogrithm sclable which enables to add future rules for shift acceptance.
|
||||
- Cancellation policy enforcement
|
||||
- Implement logic to prevent cancellations within 24 hours of shift start time.
|
||||
- If a cancellation is attempted within this window
|
||||
- We need to finalise the penalty for this cancellation.
|
||||
- Documentation upload process
|
||||
- Implement a secure and efficient process for workers to upload required documentation (e.g., certifications, tax forms).
|
||||
- Ensure that the uploaded documents are properly stored and linked to the worker's profile.
|
||||
- Documentation parsing
|
||||
- Implement a system to parse and extract relevant information from uploaded documents (e.g., certifications, tax forms) for verification purposes.
|
||||
- there should be manual verification by the client even if the ai verification is passed.
|
||||
- Attire upload
|
||||
- Implement a system for workers to upload images of their attire for verification purposes.
|
||||
- Attire verification
|
||||
- Implement a system to verify the uploaded attire images against the required dress code for shifts.
|
||||
- there should be manual verification by the client even if the ai verification is passed.
|
||||
- Shift that require "awaiting confirmation" status
|
||||
- Implement logic to handle shifts that require "awaiting confirmation" status, where the worker needs to manually confirm the shift before it becomes active.
|
||||
- Enable NFC-based clock-in and clock-out functionality for staff members, allowing them to easily record their attendance using NFC technology (BE tasks).
|
||||
- Enable worker profile visibility, where the worker's can hide their profile from clients if they choose to, and implement the necessary logic to handle profile visibility settings (BE tasks).
|
||||
- Rapid order parsing (voice and text) using AI, allowing clients to quickly create orders by simply describing their needs, and implementing the necessary logic to parse and interpret the client's input to create accurate orders (BE tasks)
|
||||
- This is always mapped similar to one time order creation.
|
||||
|
||||
## FE
|
||||
|
||||
### Staff mobile application
|
||||
- Show google maps location in the shift details page in the woker app.
|
||||
- Add a requirment section in the shift details page in the worker app which shows the requirements for that shift.
|
||||
- Attire screen
|
||||
- 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 purposes.
|
||||
- Show the list of uploaded attire images in the worker profile.
|
||||
- FAQ screen in the worker app.
|
||||
- Privacy and Security screen in the worker app.
|
||||
- Profile visbility setting
|
||||
- Terms of services (For now use a generated one but we need to have a proper one for the launch)
|
||||
- Privacy policy (For now use a generated one but we need to have a proper one for the launch)
|
||||
|
||||
### Client mobile application
|
||||
- Implement the remaining order types
|
||||
- Rapid order creation using voicd and text input, allowing clients to quickly create orders by simply describing their needs, and implementing the necessary UI and logic to parse and interpret the client's input to create accurate orders (FE tasks).
|
||||
- After parsing this should be populated in the screen similar to one time order creation screen where the client can make any necessary adjustments before finalising the order.
|
||||
- This is always mapped similar to one time order creation as this only handles same day orders.
|
||||
|
||||
# Research Tasks
|
||||
- How do we validate the SSN number of a worker in the US?
|
||||
- Research third-party services or APIs that provide SSN validation.
|
||||
- Evaluate the cost, reliability, and ease of integration of these services.
|
||||
- Plan the integration process and identify any potential challenges.
|
||||
- How do we validate the bank account details of a worker in the US?
|
||||
- Research third-party services or APIs that provide bank account validation.
|
||||
- Evaluate the cost, reliability, and ease of integration of these services.
|
||||
- Plan the integration process and identify any potential challenges.
|
||||
- In the legacy application we are only using soft FE checks but we need to have a proper validation process.
|
||||
- What are the payment platforms we want to integrate for processing payments to workers?
|
||||
- Research popular payment platforms (e.g., Stripe, PayPal, Square) that support payouts to workers.
|
||||
- Evaluate the cost, reliability, and ease of integration of these platforms.
|
||||
- Plan the integration process and identify any potential challenges.
|
||||
- Implement test cases for 2 features in the web dashboard to be run in the agent browser (https://agent-browser.dev/)
|
||||
- Research how to implement test cases for web applications using the agent browser.
|
||||
|
||||
|
||||
# Business Tasks
|
||||
- Create a template models for the pdf reports in the client and web apps.
|
||||
- How do we handle situations like
|
||||
- If a worker is a no-show for a shift.
|
||||
- If the certain shifts are not getting enough applicants.
|
||||
- These situtations hevaly disadvantages the clients and we need to have a clear policy on how to handle these situations.
|
||||
- Terms of service and privacy policy for the mobile applications.
|
||||
- How to handle the data request from worker side.
|
||||
- Having a discussion about rephrasing certain termeniologies in the application
|
||||
- Meaning of the worker registration process, is it signup or onboarding, because we are not doing a proper signup process where the worker can create an account by themselves, instead we are doing an onboarding process where the worker needs to provide their phone number and then we create an account for them and send them the OTP to login, as they should be already attached to a vendor when they are providing their phone number, we can consider this as an onboarding process rather than a signup process.
|
||||
- Meaning of the worker profile visibility, is it "profile visibility" or "availability status", because the worker is not making their profile completely invisible to the clients, instead they are just marking themselves as unavailable for work, so we can consider this as "availability status" rather than "profile visibility".
|
||||
|
||||
|
||||
- Meaning of the the auto match ?
|
||||
- Shouldn't we do this any way ?
|
||||
- Is this only a marketing item ?
|
||||
|
||||
|
||||
- Validation layer
|
||||
- Profile info
|
||||
- emergency contact
|
||||
- experiences
|
||||
- attires
|
||||
- there should be manual verification by the client even if the ai verification is passed.
|
||||
- to track false positives and false negatives.
|
||||
- certifications
|
||||
- there should be manual verification by the client even if the ai verification is passed.
|
||||
- to track false positives and false negatives.
|
||||
- documents
|
||||
- tax forms
|
||||
|
||||
- We need have a show a list of clothing items in the staff app -> shift page.
|
||||
|
||||
@@ -193,7 +193,6 @@ class CoverageRepositoryImpl implements CoverageRepository {
|
||||
case dc.ApplicationStatus.REJECTED:
|
||||
return CoverageWorkerStatus.rejected;
|
||||
case dc.ApplicationStatus.CONFIRMED:
|
||||
case dc.ApplicationStatus.ACCEPTED:
|
||||
return CoverageWorkerStatus.confirmed;
|
||||
case dc.ApplicationStatus.CHECKED_IN:
|
||||
return CoverageWorkerStatus.checkedIn;
|
||||
|
||||
420
milestones/m4/planning/m4-planning.md
Normal file
420
milestones/m4/planning/m4-planning.md
Normal file
@@ -0,0 +1,420 @@
|
||||
# **Development Tasks**
|
||||
|
||||
These are written to be readable by a project manager and easy to translate into GitHub issues later.
|
||||
Each item keeps a question-style title and includes a lightweight issue outline (goal, scope, acceptance criteria).
|
||||
|
||||
## **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.
|
||||
|
||||
Reference in New Issue
Block a user