284 lines
12 KiB
Markdown
284 lines
12 KiB
Markdown
# 1C Delivery Frontend And Supabase Preparation Implementation Plan
|
||
|
||
> **For agentic workers:** REQUIRED: Use superpowers:subagent-driven-development (if subagents available) or superpowers:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||
|
||
**Goal:** Prepare the frontend and Supabase data model for a delivery-only workflow where orders are imported from 1C, delivery automation starts only after the full client order set is ready, and logistician, driver, and client interfaces work against live Supabase data.
|
||
|
||
**Architecture:** 1C remains the source of order creation and production progress. Supabase becomes the source of truth for delivery workflow state, imported source fields, grouped client delivery sets, invitations, slots, and operator actions. The frontend stops behaving like a generic order-management ERP panel and becomes a delivery workspace centered on logisticians, drivers, admins, and the public client delivery page.
|
||
|
||
**Tech Stack:** React, Vite, Supabase Auth, Supabase Postgres, existing order repositories and hooks, delivery invitation API, OTP email login.
|
||
|
||
---
|
||
|
||
## File Structure
|
||
|
||
**Existing files to modify**
|
||
- `src/pages/LoginPage.jsx`
|
||
- `src/components/auth/OtpLoginForm.jsx`
|
||
- `src/constants/roles.js`
|
||
- `src/constants/deliveryWorkflow.js`
|
||
- `src/services/supabase/orderRepository.js`
|
||
- `src/services/supabase/orderRepository.test.js`
|
||
- `src/hooks/useOrders.js`
|
||
- `src/pages/DashboardPage.jsx`
|
||
- `src/components/dashboard/RoleWorkspacePanel.jsx`
|
||
- `src/components/logistics/BotControlPanel.jsx`
|
||
- `src/components/orders/OrderDetailPanel.jsx`
|
||
- `src/components/driver/DriverDeliveryPlanner.jsx`
|
||
- `src/components/driver/DriverDeliveryDetail.jsx`
|
||
- `src/pages/ClientDeliveryPage.jsx`
|
||
- `src/components/client/DeliveryChoiceFlow.jsx`
|
||
- `src/components/client/DeliveryStateNotice.jsx`
|
||
- `supabase/schema.sql`
|
||
- `supabase/seed/stage-1-demo.sql`
|
||
- `docs/scenarios.md`
|
||
- `docs/architecture.md`
|
||
|
||
**New files to create**
|
||
- `src/services/deliverySetViews.js`
|
||
- `src/services/deliverySetViews.test.js`
|
||
- `src/components/logistics/LogisticsReadinessBoard.jsx`
|
||
- `src/components/logistics/LogisticsReadinessBoard.test.jsx`
|
||
- `src/components/logistics/DeliverySetDetailPanel.jsx`
|
||
- `src/components/logistics/DeliverySetDetailPanel.test.jsx`
|
||
- `src/components/client/DeliverySlotsPicker.jsx`
|
||
- `src/components/client/DeliverySlotsPicker.test.jsx`
|
||
- `docs/superpowers/specs/2026-04-13-1c-delivery-ui-design.md`
|
||
|
||
---
|
||
|
||
## Product Rules To Preserve
|
||
|
||
- Orders are created and progressed in `1С`, not in the web app.
|
||
- The new delivery flow must ignore the legacy `SMS` field from XML as a business trigger.
|
||
- Delivery automation must start only when the full client order set is ready.
|
||
- Readiness is evaluated per client delivery set, not per single imported order row.
|
||
- The web app is a delivery workspace for `logistician`, `driver`, and `admin`.
|
||
- The client is not an authenticated app user. The client uses a public invitation link.
|
||
|
||
---
|
||
|
||
## Delivery Data Model Direction
|
||
|
||
### Imported order-level fields
|
||
|
||
`public.orders` should carry imported 1C fields needed for UI and later automation:
|
||
|
||
- `source_order_number`
|
||
- `source_order_date`
|
||
- `source_customer_name`
|
||
- `source_customer_phone`
|
||
- `source_customer_email`
|
||
- `source_customer_city`
|
||
- `source_total_sum`
|
||
- `source_paid_at`
|
||
- `source_gateway`
|
||
- `source_associated_bills_text`
|
||
- `source_production_at`
|
||
- `source_saw_at`
|
||
- `source_glue_at`
|
||
- `source_h_glue_at`
|
||
- `source_curve_at`
|
||
- `source_accept_at`
|
||
- `source_ship_at`
|
||
- `source_payload jsonb`
|
||
|
||
### Delivery-set fields
|
||
|
||
`public.orders` also needs delivery-specific derived fields:
|
||
|
||
- `delivery_set_key`
|
||
- `delivery_set_name`
|
||
- `delivery_set_status`
|
||
- `delivery_set_ready_at`
|
||
- `delivery_ready_reason`
|
||
- `source_sms_legacy_at`
|
||
|
||
### Delivery-set rule
|
||
|
||
For the current phase, the canonical readiness rule should be:
|
||
|
||
- A single imported order is ready when `source_accept_at` is present and `source_ship_at` is absent.
|
||
- A client delivery set is ready only when all linked imported orders in the set are ready.
|
||
- The legacy XML `SMS` field is stored only as historical source data and must not start the new scenario.
|
||
|
||
### Grouping rule
|
||
|
||
Until real `n8n` grouping is finished, Supabase demo data and frontend logic should use:
|
||
|
||
1. explicit `delivery_set_key` from imported or seeded data
|
||
2. fallback grouping by normalized client phone and client name
|
||
3. linked order numbers from `source_associated_bills_text` as supporting context
|
||
|
||
---
|
||
|
||
## Chunk 1: Lock The Delivery Product Model
|
||
|
||
### Task 1: Reframe roles and statuses around delivery instead of order creation
|
||
|
||
**Files:**
|
||
- Modify: `src/constants/roles.js`
|
||
- Modify: `src/constants/deliveryWorkflow.js`
|
||
- Test: `src/constants/deliveryWorkflow.contract.test.js`
|
||
|
||
- [ ] **Step 1: Write failing contract assertions for delivery-centric wording and ownership**
|
||
- [ ] **Step 2: Run `npm test -- src/constants/deliveryWorkflow.contract.test.js` and confirm failure**
|
||
- [ ] **Step 3: Update role labels and permission text for `logistician`, `driver`, and `admin`**
|
||
- [ ] **Step 4: Update workflow comments, stage labels, and ownership so the flow is based on imported 1C orders**
|
||
- [ ] **Step 5: Re-run `npm test -- src/constants/deliveryWorkflow.contract.test.js` and confirm pass**
|
||
- [ ] **Step 6: Commit**
|
||
|
||
---
|
||
|
||
## Chunk 2: Prepare Supabase For 1C-Shaped Delivery Data
|
||
|
||
### Task 2: Extend schema for imported source fields and delivery-set state
|
||
|
||
**Files:**
|
||
- Modify: `supabase/schema.sql`
|
||
- Modify: `supabase/seed/stage-1-demo.sql`
|
||
|
||
- [ ] **Step 1: Add idempotent schema columns for source order fields, production-step timestamps, and delivery-set state**
|
||
- [ ] **Step 2: Add indexes for `delivery_set_key`, `delivery_set_status`, `source_accept_at`, and `source_ship_at`**
|
||
- [ ] **Step 3: Rewrite the seed so demo data represents grouped imported orders rather than hand-entered app orders**
|
||
- [ ] **Step 4: Add SQL comments documenting that `source_sms_legacy_at` is informational only**
|
||
- [ ] **Step 5: Review that schema can run before seed without missing-column failures**
|
||
- [ ] **Step 6: Commit**
|
||
|
||
---
|
||
|
||
## Chunk 3: Build Frontend Read Models Around Delivery Sets
|
||
|
||
### Task 3: Add delivery-set view helpers
|
||
|
||
**Files:**
|
||
- Create: `src/services/deliverySetViews.js`
|
||
- Create: `src/services/deliverySetViews.test.js`
|
||
- Modify: `src/services/supabase/orderRepository.js`
|
||
- Modify: `src/services/supabase/orderRepository.test.js`
|
||
- Modify: `src/hooks/useOrders.js`
|
||
|
||
- [ ] **Step 1: Write failing tests for grouping imported orders into delivery sets**
|
||
- [ ] **Step 2: Run `npm test -- src/services/deliverySetViews.test.js src/services/supabase/orderRepository.test.js` and confirm failure**
|
||
- [ ] **Step 3: Implement pure grouping helpers for readiness, buckets, and linked-order summaries**
|
||
- [ ] **Step 4: Extend repository output with source-field summary and delivery-set metadata**
|
||
- [ ] **Step 5: Update `useOrders` to expose grouped delivery-set buckets**
|
||
- [ ] **Step 6: Re-run `npm test -- src/services/deliverySetViews.test.js src/services/supabase/orderRepository.test.js` and confirm pass**
|
||
- [ ] **Step 7: Commit**
|
||
|
||
---
|
||
|
||
## Chunk 4: Turn The Dashboard Into A Logistics Workspace
|
||
|
||
### Task 4: Replace generic order emphasis with logistics-first sections
|
||
|
||
**Files:**
|
||
- Modify: `src/pages/DashboardPage.jsx`
|
||
- Modify: `src/components/dashboard/RoleWorkspacePanel.jsx`
|
||
- Create: `src/components/logistics/LogisticsReadinessBoard.jsx`
|
||
- Create: `src/components/logistics/LogisticsReadinessBoard.test.jsx`
|
||
- Create: `src/components/logistics/DeliverySetDetailPanel.jsx`
|
||
- Create: `src/components/logistics/DeliverySetDetailPanel.test.jsx`
|
||
|
||
- [ ] **Step 1: Write failing UI tests for logistics buckets and delivery-set cards**
|
||
- [ ] **Step 2: Run `npm test -- src/components/logistics/LogisticsReadinessBoard.test.jsx src/components/logistics/DeliverySetDetailPanel.test.jsx` and confirm failure**
|
||
- [ ] **Step 3: Build `LogisticsReadinessBoard` with sections `На подходе`, `Готово к запуску`, `Ожидает клиента`, `Нужна ручная работа`, `Согласовано`, `Завершено`**
|
||
- [ ] **Step 4: Build `DeliverySetDetailPanel` with linked source orders, source stages, slot state, and manual action placeholders**
|
||
- [ ] **Step 5: Integrate the new board into `DashboardPage` so `logistician` lands in a logistics-first workspace**
|
||
- [ ] **Step 6: Update `RoleWorkspacePanel` to use grouped delivery-set counts**
|
||
- [ ] **Step 7: Re-run `npm test -- src/components/logistics/LogisticsReadinessBoard.test.jsx src/components/logistics/DeliverySetDetailPanel.test.jsx` and confirm pass**
|
||
- [ ] **Step 8: Commit**
|
||
|
||
---
|
||
|
||
## Chunk 5: Tighten OTP Entry For Real Operator Use
|
||
|
||
### Task 5: Polish login UX and unknown-email handling
|
||
|
||
**Files:**
|
||
- Modify: `src/pages/LoginPage.jsx`
|
||
- Modify: `src/components/auth/OtpLoginForm.jsx`
|
||
- Modify: `src/context/AuthContext.jsx`
|
||
- Test: `src/components/auth/OtpLoginForm.test.jsx`
|
||
- Test: `src/context/AuthContext.test.js`
|
||
|
||
- [ ] **Step 1: Add failing tests for inbox and spam helper text and the unknown-email message**
|
||
- [ ] **Step 2: Run `npm test -- src/components/auth/OtpLoginForm.test.jsx src/context/AuthContext.test.js` and confirm failure**
|
||
- [ ] **Step 3: Update login copy so operators are told to check inbox and `Spam`**
|
||
- [ ] **Step 4: Keep strict existing-user-only auth and map unknown email to `Email не найден в системе. Обратитесь к администратору.`**
|
||
- [ ] **Step 5: Re-run `npm test -- src/components/auth/OtpLoginForm.test.jsx src/context/AuthContext.test.js` and confirm pass**
|
||
- [ ] **Step 6: Commit**
|
||
|
||
---
|
||
|
||
## Chunk 6: Make Client And Driver Screens Match The Real Flow
|
||
|
||
### Task 6: Prepare client delivery page and driver workspace for live demo
|
||
|
||
**Files:**
|
||
- Modify: `src/pages/ClientDeliveryPage.jsx`
|
||
- Modify: `src/components/client/DeliveryChoiceFlow.jsx`
|
||
- Modify: `src/components/client/DeliveryStateNotice.jsx`
|
||
- Create: `src/components/client/DeliverySlotsPicker.jsx`
|
||
- Create: `src/components/client/DeliverySlotsPicker.test.jsx`
|
||
- Modify: `src/components/driver/DriverDeliveryPlanner.jsx`
|
||
- Modify: `src/components/driver/DriverDeliveryDetail.jsx`
|
||
- Test: `src/components/client/DeliveryChoiceFlow.test.jsx`
|
||
|
||
- [ ] **Step 1: Write failing tests for slot rendering and read-only state notices**
|
||
- [ ] **Step 2: Run `npm test -- src/components/client/DeliveryChoiceFlow.test.jsx src/components/client/DeliverySlotsPicker.test.jsx` and confirm failure**
|
||
- [ ] **Step 3: Build `DeliverySlotsPicker` for date plus half-day choices from live slot data**
|
||
- [ ] **Step 4: Refine the public client page around invitation states and clear delivery-choice messaging**
|
||
- [ ] **Step 5: Refine driver screens to focus on assigned deliveries, slot, city, and result actions**
|
||
- [ ] **Step 6: Re-run `npm test -- src/components/client/DeliveryChoiceFlow.test.jsx src/components/client/DeliverySlotsPicker.test.jsx` and confirm pass**
|
||
- [ ] **Step 7: Commit**
|
||
|
||
---
|
||
|
||
## Chunk 7: Update Documentation And Demo Script
|
||
|
||
### Task 7: Make the product story match the real workflow
|
||
|
||
**Files:**
|
||
- Modify: `docs/architecture.md`
|
||
- Modify: `docs/scenarios.md`
|
||
- Create: `docs/superpowers/specs/2026-04-13-1c-delivery-ui-design.md`
|
||
|
||
- [ ] **Step 1: Write the design/spec doc for the 1C-driven delivery UI**
|
||
- [ ] **Step 2: Update `docs/architecture.md` to describe 1C import, Supabase delivery truth, and later n8n orchestration**
|
||
- [ ] **Step 3: Update `docs/scenarios.md` so the story is operator login -> logistician workspace -> client link -> driver completion**
|
||
- [ ] **Step 4: Add a short demo checklist for the first paid milestone**
|
||
- [ ] **Step 5: Commit**
|
||
|
||
---
|
||
|
||
## Verification
|
||
|
||
After each chunk, run the smallest relevant tests first. Before final completion, run:
|
||
|
||
```bash
|
||
npm test
|
||
npm run lint
|
||
npm run build
|
||
```
|
||
|
||
Also verify manually:
|
||
- unknown email shows the admin-help message
|
||
- login copy mentions inbox and spam
|
||
- logistician lands in a logistics-first workspace
|
||
- a ready delivery set is shown as one grouped client unit
|
||
- the client page shows live slot options
|
||
- the driver page shows assigned deliveries and result actions
|
||
|
||
---
|
||
|
||
## Out Of Scope For This Plan
|
||
|
||
- Real `n8n` workflow implementation
|
||
- FTP/XML polling automation
|
||
- Real 1C write-back integration
|
||
- Route optimization, truck loading, or waybill generation
|
||
- Changes to internal 1C production logic
|
||
|
||
This plan prepares the frontend and Supabase so those integrations can be connected later without redesigning the product again.
|