Krow/Krow-workspace
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Add Milestone 3 documentation including feature testing plan, demo notes, and demo flow details

Browse Source 
- Introduced comprehensive testing plan for Milestone 3 in m3-client-note.md
- Documented feedback and suggestions from demo sessions in m3-notes.md
- Created detailed demo flow for Milestone 3 in m3.md, outlining user interactions and expected outcomes
- Added planning tasks for Milestone 4 in m4-planning.md, covering backend and frontend development tasks, research, and business tasks
This commit is contained in:
Achintha Isuru
2026-02-12 16:33:16 -05:00
parent 368f28f354
commit fd47d84045
18 changed files with 829 additions and 1411 deletions
Download Patch File Download Diff File Expand all files Collapse all files

420
docs/MILESTONES/M4/planning/m4-planning.md Normal file
View 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.