T
Sign in

ROADMAP.md — build the greige fabric system

All docs GitHub source

ROADMAP.md — build the greige fabric system

Build-strategy decision (2026-09-02): ONE-GO BUILD, single cutover. The full system (all signed A–F features) is built as one product — NO feature-phased go-lives. The stage lists below are the INTERNAL build order/checklist, not release gates. Guardrail kept from the earlier agreed planning gate: before the single cutover there is an internal RUN-TEST window — staff exercise the complete system on real data in parallel (via the BRIDGE file-interchange), fixes land, then ONE flip off the old software. UX: capture-first entry + dashboard-as-home (pending queue per role, next-step cards), with a Forms section, a dump station and a report station as power-user shortcuts (PLANNING §27).

ROADMAP.md — build the greige fabric system in phases

Greige fabric manufacturing tracking on top of the existing SvelteKit scaffold (this repo). One feature at a time, each phase ships, deployable, committed and pushed (per the one rule in README). Every phase ends with a working vertical slice the owner can use that day — no month-long builds.

Guiding principles:

  • Single conversion engine: all kg↔mtrs math lives in one server module (src/lib/server/yarn-math.ts eventually), driven by the construction master. Screens never ask staff to convert by hand.
  • Soft allocations: yarn can be re-assigned between orders at runtime, with a full audit trail.
  • Plan first, integrate later: partner-ERP production pickup is a later phase; manual entry shortcuts exist from the start so the system is usable standalone.
  • Print is a feature: challans/reports are first-class screens.

Phase 0 — Planning gate (no production before this)

Per the owner's directive: the system is planned flow-first before any feature is built. This phase produces and signs off:

  1. Working flow — the operational process, both profit centres on one spine (docs/PLANNING.md §1).
  2. Flow → form map — every step ↔ new screens (who, input mode) (PLANNING.md §2).
  3. Per-form field validation — necessity, sourcing (auto/scan/select/ number/text), who/when; labour screens end zero free-text (PLANNING.md §3).
  4. Reports & dashboards plan — existing reports mapped to exportable vs live tiles (docs/DASHBOARDS.md).
  5. Open questions resolved (FIELDMAP.md §10), numbering/tenancy/period rules decided.

Sign-off is a checklist item, not a cosmetic step — production Phase 1 starts only after the flow diagram and screen inventory are approved. Report uploads keep feeding the map through the whole planning phase; nothing changes the flow silently.

Phase 1 — Foundation (1 release)

Goal: the skeleton + master data + conversions, proving the pipeline.

  • Roles & auth hardening: planner, godown, checking, production, owner (Better Auth already gives email/password + session).
  • Platform foundation (from PLATFORM.md; seams built now, enforcement staged):
    • Tenancy: tenant_id (company) × setup_id (site) columns on every table now; session context middleware; RLS enforcement only when a second tenant goes live (Stage-2 trigger).
    • Event backbone: /api/events ingestion (typed, idempotent, source-tagged) + event log tables; the first floor event types.
    • Realtime hub: SSE/WebSocket delta push; the live operations board shell (per-setup, live meters/stock/checking counters).
    • Store: bun:sqlite through Phase 0–1 — Postgres is Stage-2, trigger-gated (PLATFORM.md §3), with the seams (Drizzle-only SQL, tenancy columns, event log) keeping the shift cheap. No Postgres install now.
  • Master data CRUD: yarn_master (type/count/party), construction_master (EPI/PPI/counts/crimp/width/GSM), customers, suppliers, units (in-house weaving + each out-house sizer/weaver), Samples/Leads master lookups.
  • Conversion engine + calculator page: enter a construction + mtrs → warp kg, weft kg, size-up, theoretical GSM. This page is shown to the owner early to validate the formulas against reality (closing question §3).
  • DB migrations + seed data; dashboard shell with daisyUI.

Exit: owner can add constructions and verify "for 10,000 m of 20×16 64×48 63" I need X kg warp, Y kg weft" matches mill numbers; floor entries flow into a live board in real time.

Phase 1 — MVP: orders, yarn stock, procurement (the core ask)

Goal: "running track of raw material vs pending orders — how much to procure" is answered daily.

  • PO module: create PO (supplier, yarn, count, kgs, rate, promise date); PO delivery tracking — partial receipts with lot numbers, received kgs, challan no.; status open/partial/closed.
  • Yarn stock ledger: lots with in-transit / available / allocated / in-process / consumed; godown location; closing stock per yarn.
  • SO module: SO + delivery schedule; statuses enquiry (link to Lead) → confirmed → in-production → part/full-delivered.
  • Requirement & allocation: compute yarn requirement per SO line (kgs), show available vs allocated vs still-to-procure per yarn; allocate/un-allocate lots to SOs at runtime with history; market- bought stock is picked up here too (apportion later).
  • Yarn rate board form (procurement manager): rate-list/WhatsApp upload via SHARE TARGET (no file browsing), OCR + clarify confused rates, approved per count/ticket → quote prefill + trend.
  • Yarn rate board + rate ingestion: daily yarn rates (excl/incl GST per supplier/mill) with trend history; ingested from WhatsApp rate-list images/PDFs + text via OCR with clarification prompts — feeds costing/quotes immediately and yarn-trend analytics.
  • Procurement suggestion screen: per yarn: total SO demand (kgs) − free stock − in-transit = suggested buy — the daily "how much to procure" number, both modes (order-driven and market-trend) are just different entry paths into the same ledger.
  • Reports: open POs, SO vs delivery position, yarn stock & allocation sheet (printable).

Exit: owner plans a week's procurement from one screen; re-assigning a lot from SO-A to SO-B is 2 clicks and visible in history; the live board shows stock/orders as they move (runtime not periodic).

Cross-cutting: management dashboards (grow every phase)

The runtime dashboards are built up from Phase 0 onward, one board per phase's data: Phase 0 live operations board (meters/stock/checking counters) → Phase 1 procurement & order board → Phase 2 production board (beams/machines per setup, in-house vs out-house) → Phase 3 dispatch/grade board → Phase 4 commercial board (leads/samples) → Phase 5 company analytics. Middle management sees per-setup floors; top management sees company rollups per PLATFORM.md §5. Dashboards are subscribers of the real-time hub + aggregates — they always show the current picture, never a batch.

Phase 2 — Sizing, beams, weaving (production)

Goal: track warp from greige yarn → sized beams → meters woven.

  • Warping → beams: beam register (construction, total ends, length, computed kgs); beam status draft → warped → issued-to-sizing → sized → in-weaving → consumed.
  • Sizing jobs (out-house): beams sent, sizer, rate basis, out/in dates, sized kgs (pickup), challan print.
  • Weaving jobs: assign sized beams to in-house unit (machine/set) or out-house weaver; meters target; production entry (mtrs/day, mobile-friendly, per unit login — the checking clerk/weaver logs it).
  • Capacity view: in-house loom load vs outsourced load; planner overview of all beams in flight.
  • Fabric meters per beam auto-computed; beam consumption tracking.

Exit: owner sees every weight/beam and its meters status in one screen; outsourced weaving is tracked to the day.

Phase 3 — Checking, grading, dispatch (fully closes the loop)

Goal: finished goods graded, reported, dispatched, tracked against SO.

  • Checking module: per job, mtrs checked, defects (per 100 m points), grade A/B/C/seconds; the checking report is generated in-system and printed (unit, mtrs, grade split, defects, measured vs computed GSM).
  • Dispatch & delivery vs SO: issue graded mtrs, challan + vehicle, grade-wise delivered position per SO; delivery shortfall visible.
  • Finished goods stock by grade (mtrs) until dispatched.

Exit: "checked today" → report printed in 2 minutes; SO delivery position by grade; seconds easily identifiable.

Phase 4 — Samples & leads + commercial acceleration (CRM-lite)

  • Lead capture autopilot (Android): always-on notification-listener auto-drafting (NEW LEAD pattern → draft, zero user action); a11y full- chat read when opening drafts; snip overlay only for images; iOS = share- sheet. Web Share Target everywhere (PWA in the share sheet; forward → destination form). No Business API at low volume; whatsapp-web rejected.

  • Voice-assisted order entry (trading path): speak party/broker/rate/ quality alias → auto-filled fields with explicit confirm taps (Android Chrome Web Speech API).

  • Intake & layout learning (pilot): upload raw WhatsApp screenshots / broker contract photos / PDFs / copied messages → OCR + per-sender template learning → field prefill with confirm taps (rate lists too). Official WhatsApp Business API as a later push-inbound option.

  • Sample tracking: strike-offs sent to parties, purpose, follow-up dates, result (approved → links into SO).

  • Lead tracking: enquiry pipeline (new → quoted → follow-up → order/lost), quote log, activity notes; convert lead→SO in one click.

  • Owner pipeline view (open leads, pending samples, conversion).

Exit: nothing from a customer conversation is lost on paper.

Phase 5 — Integrations & polish

  • Weaver ERP pickup: per partner weaver, their production/meters can be imported (Excel/CSV at minimum — whatever their "manufacturing ERP" exports; API if it has one). Design decision: we push beam/job details to them and pull daily production. Confirm partners' systems in the meantime (BUSINESS.md §6, q.4) — cheap to build once the format is known.
  • Reports/analytics: yarn consumption vs procurement, loom efficiency, order book vs capacity, party-wise delivery performance.
  • Notifications (WhatsApp/email for due PO deliveries, pending samples), backups, and any local-language screen pass.

Explicitly out of scope (for now)

Billing/financials, payroll, HR, dyeing/finishing (this is greige only), and yarn dyeing (unless stripe constructions appear — then a dyed-yarn stock flag can be added to yarn_master).

How each phase is delivered — slices, ground-tested (build vs bridge per slice)

Phases are targets; the unit of delivery is a slice — the smallest piece staff can ground-test (usually 1–2 screens + the events they create + one report). Each phase is an ordered slice list; every slice ships, staff test it on the ground for a few days, reconcile, sign off — and only then is the next slice's path chosen.

At each slice we make a live tradeoff, never a one-time architecture call:

Do this Use when
S — Switch build in the new system, migrate that slice's records, retire it in the old software the old export is weak for this domain, or the slice is the core (stock ledger, allocations) where duplication pain is highest
B — Bridge keep the old software as owner, wire its periodic file push into our import ledger as a live working copy, revisit next checkpoint migrating this slice's history is risky/costly and the old export is trustworthy
H — Hold defer not needed yet

The bridge mechanism is the only integration possible with the existing system (it periodically pushes files we import, and vice versa) — its contracts, idempotency, and reconciliation rules are in docs/BRIDGE.md. Read that before any B decision.

Illustrative Phase-1 slice order (reviewed at each step):

  1. Masters + conversion engine (S — pure enablement, nothing to migrate)
  2. PO + receipts (S or B — old open POs can bridge in if its export is reliable)
  3. Stock ledger own + party (S — the heart; opening balance cutover printed + signed; old history bridges or not)
  4. SOs (B first — import open SOs, then switch authoring)
  5. Requirement & allocation (S — only meaningful on new-system stock + SOs)
  6. Procurement suggestion (S — pure computation)

Ground-testing rhythm: slices overlap only slightly; during coexistence the owner reviews the reconciliation screens weekly; every bridge has a retirement date written on it when it is created.

Building blocks shared by every slice

  1. Same repo (SvelteKit runes, Drizzle/bun:sqlite — schema evolves via drizzle-kit generate; drizzle/ migrations committed).
  2. Deploy = sudo bash scripts/deploy.sh "phase N slice M: ..." (build → restart → health check → commit + push). The one rule applies to every slice: docs updated in the same commit.
  3. Each slice updates this ROADMAP + BUSINESS.md/ARCHITECTURE.md/BRIDGE.md with what was built vs bridged vs deferred (keep the four in sync).