FleetOS Sprint 1 — PRD & Claude Code Brief

February 7, 2026 | Work Session

Purpose: This document is both a Product Requirements Document AND a briefing for Claude Code (terminal). Drop this file into docs/PRD-Feb7.md in the repo. When starting a Claude Code session, say: "Read docs/PRD-Feb7.md and follow the instructions."

---

CONTEXT: What We're Building

FleetOS is a fleet maintenance coordination platform replacing WhatsApp chaos. A fleet manager creates a service request, a supplier gets notified via WhatsApp with a "magic link," taps it, sees the job, and accepts. No app download required.

Tech stack: Vite + React + TypeScript + Supabase + Vercel Repo: ZBO19/FleetOS Live at: https://fleetos.us Target market: Miami (Waymo launched Jan 22, 2026 — autonomous vehicles need maintenance NOW)

---

PART 1: SPRINT 1 AUDIT

Sprint 1 scope (Feb 7–21) defined these deliverables. Before building anything new, AUDIT what currently exists. For each item, check the codebase and report: ✅ DONE, ⚠️ PARTIAL, ❌ MISSING.

1.1 Quote/Cost Tracking (THE CRITICAL GAP)

The entire value of FleetOS breaks down without cost tracking. Fleet managers need to see what things cost for end-of-month reconciliation.

Database fields required (check Supabase schema + types):

• quoted_amount — supplier enters this when accepting a job

• final_cost — supplier enters this when completing a job

• currency — dropdown (USD, ZAR, EUR, GBP at minimum)

Supplier-side (magic link view):

• Quote input appears during accept flow (NOT on initial view — see UI spec below)

• Final cost input appears during completion flow

• Currency selector on both

Fleet manager side (dashboard):

• Quoted amount visible on request cards / detail view

• Final cost visible on completed requests

• Cost summary or totals somewhere accessible

Data layer:

• QueryService handles quote/cost CRUD

• Supabase RLS policies allow supplier to update quote/cost on assigned requests

1.2 Status Filters

• Dashboard filter by status: URGENT / TODAY / SCHEDULED / COMPLETED (or equivalent)

• Filter is visible and usable, not hidden in a menu

• Counts shown per status (e.g., "Urgent (3)")

1.3 Date Range Filter

• Filter requests by date range on dashboard

• At minimum: Today, This Week, This Month, Custom range

• Works in combination with status filter

1.4 Mobile Responsiveness

• Test all views at 375px width (iPhone SE)

• No horizontal scroll

• Buttons are tappable (min 44px touch targets)

• Text is readable without zooming

• Magic link view is mobile-first (this is the primary device)

1.5 Architecture Cleanup

• HTML <title> says "FleetOS" not "T420 ROBO-HUB"

• No Robo-Hub imports in FleetOS production build

• No hostname detection in App.tsx (or it's been removed/simplified)

• Bundle size reasonable (target < 400KB, was 570KB)

---

PART 2: UI/UX REQUIREMENTS

Problem Statement

The current in-app supplier view (RequestResponseView.tsx) shows ALL actions simultaneously — 7+ buttons, quote input, ETA input, call/WhatsApp buttons, accept/decline, all on one screen. This is unusable on mobile and overwhelming on desktop.

The magic link (external view) was already fixed to use a step-based flow. The in-app view needs the same treatment.

2.1 Design Principle: One Decision Per Screen

Every supplier interaction should follow this pattern:

STEP 1: VIEW         → See job details. Two choices: Accept or Can't Help.
STEP 2: QUOTE        → "Want to add a quote?" Optional. Skip or enter amount.
STEP 3: ETA          → "When can you get there?" Quick-tap chips + custom input.
STEP 4: CONFIRMED    → Summary card. Contact buttons (Call/WhatsApp) now make sense.

• Maximum 2 buttons per step (primary action + back/cancel)

• Call Fleet / WhatsApp are SMALL secondary actions, never primary buttons

• Step indicator dots at bottom showing progress

• Smooth transitions between steps (fade/slide)

2.2 Reference Design

A reference component has been saved at docs/design-specs/supplier-view-reference.jsx. This is the TARGET design. It shows:

• Step-based flow with state machine (VIEW → QUOTE → ETA → CONFIRMED → DECLINED)

• FadeIn animation component

• Quick-tap ETA chips ("30 min", "1 hour", "2 hours", "Tomorrow 9am")

• Clean confirmation view with summary

• Contact buttons only on confirmation screen

• Mobile-first dark theme

DO NOT replace the existing component wholesale. Instead:

1. Keep all existing API calls (QueryService, ContactService, Supabase)

2. Keep all existing data flow and props

3. Restructure ONLY the rendering logic to match the step-based flow

4. Preserve the dark theme aesthetic

2.3 Specific Component Fixes

RequestResponseView.tsx (In-App Supplier View):

• Refactor to step-based flow matching reference design

• Remove simultaneous display of all action buttons

• Quote and ETA become separate sequential steps

• "Can't Help" becomes a clear secondary option (not a tiny text button)

Dashboard / Request List:

• Each request card should show: Fleet name, vehicle, job description, urgency, time

• Status badges with color coding (red=urgent, amber=today, green=completed)

• Tappable cards that expand or navigate to detail view

• If quote/cost exists, show it on the card

Request Detail View (Fleet Manager Side):

• Timeline showing request lifecycle: Created → Assigned → Accepted (with quote) → In Progress → Completed (with final cost)

• Cost section clearly visible

• Supplier contact info accessible

2.4 Color System

Maintain existing dark theme. Use this consistent system:

• Emerald/green (#10b981) — primary actions, confirmations, "accept"

• Amber (#f59e0b) — urgency, warnings, "today"

• Red (#ef4444) — decline, urgent, errors

• Slate (#64748b range) — secondary text, borders, backgrounds

• White (#ffffff) — primary text

---

PART 3: TASK CHECKLIST (Priority Order)

Claude Code should work through these in order. Each task should be a commit.

Priority 1: Audit & Report

Task: Run the Sprint 1 audit from Part 1 above.
Output: A checklist in the terminal showing what's ✅/⚠️/❌ for each item.
DO NOT fix anything yet. Just report the current state.

Priority 2: Fix Critical Gaps

Task: For any ❌ MISSING items in the quote/cost tracking section, implement them.
This is the #1 priority. Without cost tracking, FleetOS doesn't close the workflow loop.
Database schema → Data layer → UI integration.

Priority 3: In-App Supplier View Refactor

Task: Refactor RequestResponseView.tsx to step-based flow.
Reference: docs/design-specs/supplier-view-reference.jsx
Rules:
- Keep ALL existing API integration (QueryService, ContactService, supabase)
- Keep ALL existing data flow and props
- ONLY change the UI rendering structure
- Step flow: VIEW → QUOTE → ETA → CONFIRMED / DECLINED
- Max 2 primary buttons per step
- Add step indicator dots
- Add FadeIn transitions between steps

Priority 4: Dashboard Filters

Task: Add status filter and date range filter to the dashboard.
- Status pills/tabs at top: All | Urgent | Today | Scheduled | Completed
- Date range selector: Today | This Week | This Month | Custom
- Both filters work together
- Show count per status

Priority 5: Mobile Responsiveness Pass

Task: Test all views at 375px width. Fix any:
- Horizontal overflow
- Buttons too small to tap
- Text overlapping or truncated
- Layout breaking
Priority screens (in order):
1. Magic link view (supplier external)
2. In-app supplier view
3. Dashboard
4. Request creation form

Priority 6: Architecture Cleanup

Task: Fix these specific issues:
1. HTML <title> → "FleetOS" (check index.html)
2. Remove any Robo-Hub imports from FleetOS pages
3. Simplify App.tsx routing (remove hostname detection if present)
4. Check bundle size: npm run build → report total JS size

---

PART 4: ACCEPTANCE CRITERIA

Sprint 1 is DONE when a real user can:

1. Fleet manager creates a request with vehicle details, photos, location, urgency

2. Supplier receives WhatsApp notification with magic link

3. Supplier taps link, sees job details in a clean, readable format

4. Supplier accepts with a quote (optional) through a step-by-step flow

5. Supplier sets ETA with quick-tap options

6. Fleet manager sees acceptance, quote, and ETA on their dashboard

7. Supplier marks job complete with final cost

8. Fleet manager can filter by status and date range

9. Fleet manager can see costs for reconciliation

10. Everything works on mobile at 375px width

If all 10 work end-to-end, Sprint 1 is complete.

---

PART 5: WHAT NOT TO DO

• ❌ Do NOT refactor the entire codebase

• ❌ Do NOT separate FleetOS from Robo-Hub into different repos (Q2 task)

• ❌ Do NOT add new features not listed here (CSV export = Sprint 2)

• ❌ Do NOT change the Supabase project or auth configuration

• ❌ Do NOT touch anything related to T420 tokens, portal, or Robo-Dapp

• ❌ Do NOT redesign the fleet manager request creation flow (it works)

• ❌ Do NOT add analytics, tracking, or telemetry (Sprint 2)

---

REFERENCE FILES

File	Purpose
docs/design-specs/supplier-view-reference.jsx	Target UI for supplier step-based flow
docs/PRD-Feb7.md	This document
src/components/RequestResponseView.tsx	Current in-app supplier view (needs refactor)

---

NOTES FOR ZANE

How to use this with Claude Code:

1. Copy this file to docs/PRD-Feb7.md in the FleetOS repo

2. Copy the supplier reference JSX to docs/design-specs/supplier-view-reference.jsx

3. In Claude Code terminal, say:

Read docs/PRD-Feb7.md. Start with Part 3, Priority 1: run the Sprint 1 audit
and report what's ✅/⚠️/❌ for each item. Don't fix anything yet.

1. After reviewing the audit, tell Claude Code to proceed with Priority 2, 3, etc.

2. Review each commit before moving to the next priority.

Why this approach works:

• Claude Code gets explicit scope (no guessing)

• Audit-first prevents building on broken foundations

• Reference design gives visual target, not just descriptions

• "What NOT to do" prevents scope creep

• Priority order ensures most critical work happens first even if you run out of time/tokens

---

PRD Version 1.0 | February 7, 2026 | Created by Claude Opus 4.6 for Zane/T420