Mk
/
supersam
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
supersam/docs/superpowers/plans/2026-04-13-1c-delivery-fron...

12 KiB
Raw Permalink Blame History

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:

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.