Management system for a car repair shop. Greenfield project moving the workshop off a paper calendar onto a web app for scheduling services and assigning workers.
Context generated with rs-flow (discovery → foundation → PRD → changes). Source of truth for this project lives in
spokospace/rs-flow-contexts→context/.
The shop is run by hand: scheduling on a paper calendar, no trace of where parts and tools are, no cost control, no reports. The owner answers customer calls without quick access to service status; workers keep hunting for tools and parts.
Four key gaps: (1) no service management, (2) no trace of parts & tools, (3) no cost control, (4) no reports.
- Stage: greenfield, discovery complete, first slice in progress.
- First slice (
01-feature-reservations): owner reserves services (create / edit / delete) + worker sees their daily schedule as a list. Core invariant: one worker cannot have two reservations in the same time slot.
- Właściciel (Owner / Admin) — manages reservations, assigns workers, sees all services, reports to customers.
- Pracownik (Worker / Member) — performs repairs, sees only their own services for today and upcoming days.
Auth: email + password, session-based, role-based access.
| Layer | Choice |
|---|---|
| Frontend (worker) | React + UnoCSS (simple list, not a calendar in slice 1) |
| Backend / Owner UI | PHP 8.3 + Laravel + Filament admin panel |
| Database | MySQL 8.0 |
| API | REST (session-based auth) |
| Architecture | Monolithic Laravel serving Filament + a REST API for the React SPA |
| Tests | PHPUnit + Playwright |
In: authentication, owner CRUD reservations (Filament), worker read-only daily list
(React), conflict validation (one worker ≠ two reservations at the same time),
users / reservations / workers schema, PHPUnit + Playwright tests.
Out (later slices): customer notifications (email/SMS), parts inventory & podnośniki, cost tracking & reports, PWA / multi-device sync.
- FR-001 — Owner can create a reservation (client, car, work description, date/time, workers).
- FR-002 — Owner can edit a reservation (blocked once the service has started).
- FR-003 — Owner can see all reservations (calendar/list).
- FR-004 — Owner can assign a worker to a service.
- FR-005 — Worker can see their services for today.
- FR-006 — Worker can see service details (client, car, work, other assigned workers).
Polish domain terms are intentional — keep them, avoid the English equivalents:
- Serwis — a car repair job (client, work description, car, date/time, assigned workers, status). Avoid: naprawa, zlecenie, zadanie.
- Rezerwacja — a time slot booked for a serwis. Avoid: booking, appointment.
- Pracownik — a worker performing repairs; sees only their assigned services.
- Właściciel — the shop owner; manages everything.
- Podnośnik — a workstation/resource a car occupies during a serwis.
- Część — a spare part needed for a serwis (in stock or to be ordered).
- Owner creates a reservation → appears in Filament, persisted, no duplicate on re-create.
- Worker logs in → sees today's reservations with correct details.
- Conflicting reservation → API returns
409, Filament shows a validation error. - PHPUnit (conflict logic, auth, API) and Playwright (owner creates → worker sees) pass.
- Deployable: Docker image builds, CI passes.
This README was generated from the rs-flow context/ package. For full discovery
notes, glossary, tech stack, and the slice plan, see the
context/ directory.