Spike: Design client request flow (packages, projects, Stripe) #121

New issue

Closed

opened 2026-06-06 20:54:19 +00:00 by ldraney · 0 comments

ldraney commented

2026-06-06 20:54:19 +00:00

Owner

Type

Spike

Lineage

Related to #107 (auth parent). Emerged from session designing four-role model — client role was the least defined.

Repo

ldraney/landscaping-assistant

Question

What does the client experience look like end-to-end? How do package changes and project requests flow from client through admin approval to Stripe payment?

What to Explore

Current data model: Service model exists (Mowing, Weeding, Edging & Trimming) but no pricing
Unified request lifecycle: both package changes and projects go through the same admin approval flow
ServiceRequest model design: status lifecycle (requested → quoted → paid → scheduled → completed)
Stripe integration approach: payment links vs checkout sessions, webhook vs polling
Property detail page: needs Projects button alongside existing Edit/Update Address/Go to Location
My Property tab: what the client actually sees (package, active projects, request form)

Success Criteria

docs/user-stories-auth.md updated with client request flow, data model, and permission matrix
ServiceRequest model documented in ERD
Delivery phases updated to reflect where client/Stripe work lands
Implementation tickets created and added to board with phase labels

Time-box

1 session — design only, no code.

project-landscaping-assistant
#107 — parent auth issue
#115 — Phase 1 Keycloak login
#116 — per-property photos (related: property detail page)

### Type Spike ### Lineage Related to #107 (auth parent). Emerged from session designing four-role model — client role was the least defined. ### Repo `ldraney/landscaping-assistant` ### Question What does the client experience look like end-to-end? How do package changes and project requests flow from client through admin approval to Stripe payment? ### What to Explore - Current data model: Service model exists (Mowing, Weeding, Edging & Trimming) but no pricing - Unified request lifecycle: both package changes and projects go through the same admin approval flow - ServiceRequest model design: status lifecycle (requested → quoted → paid → scheduled → completed) - Stripe integration approach: payment links vs checkout sessions, webhook vs polling - Property detail page: needs Projects button alongside existing Edit/Update Address/Go to Location - My Property tab: what the client actually sees (package, active projects, request form) ### Success Criteria - [ ] `docs/user-stories-auth.md` updated with client request flow, data model, and permission matrix - [ ] ServiceRequest model documented in ERD - [ ] Delivery phases updated to reflect where client/Stripe work lands - [ ] Implementation tickets created and added to board with phase labels ### Time-box 1 session — design only, no code. ### Related - `project-landscaping-assistant` - #107 — parent auth issue - #115 — Phase 1 Keycloak login - #116 — per-property photos (related: property detail page)