Docs
Project docs
Planning + technical docs for the greige fabric system.
The platform is live at https://trading.tynolabs.com (no browser password — the app login is the door: fresh@example.com / supersecret123 — dev owner; or skpawa
How the new system unifies the two existing softwares without losing what they were built for. 1. The two worlds today (and why they duplicate) Job work module
Status: FROZEN in principle ("mota-mota we are there"). The interactive reference is /board.html (the master mock — all sections, all component pages, per-user
The ONLY integration mechanism possible with the existing systems is a utility where the existing software periodically pushes data out as files which we import
Started 2026-09-02/03. Every revision: committed + deployed healthy at trading.tynolabs.com, no half-stuck state. Revision 149 — a state factory now RUNS in tes
This document captures how the system must model the business: greige (grey) fabric woven from yarn , with an in-house weaving unit, outsourced sizing, and outs
Written into the repo at the start of the complete-to-spec build program (PLANNING §97). Purpose: every screen, flow and print the specs promise is listed here
Rule (AGENTS.md mandate 12): a route +page.svelte is a thin shell. It loads data, then composes small components. It must not grow into a monolith. Small, well-
FILE OWNERSHIP: this file is written ONLY by the audit session. The docs session never edits it; the worker session never edits it. One writer per file = overwr
FILE OWNERSHIP: this file is written ONLY by the worker session, APPEND-ONLY (one line per status change — never edit or delete existing lines). The docs sessio
FILE OWNERSHIP: this file is written ONLY by the audit session, APPEND-ONLY (one line per reopen — never edit or delete existing lines). The docs session reads
FILE OWNERSHIP — READ FIRST: this file is written ONLY by the docs session (owner's dictation). The worker session MUST NEVER edit this file — not even the Stat
Source: the owner's Google Sheet "Calcn" (fabric costing). Every formula below was recomputed cell-by-cell against that sheet's values ; the verification trace
The dashboard is the HOME of the system (PLANNING §27): attention- driven pending queue per role + live tiles; next-step cards drive the work; forms/reports are
Production URL: https://trading-tyno.pages.dev — no custom domain is attached; trading.tynolabs.com still points at the phone until the phone is retired. Same s
Architecture Browser ── https://trading.tynolabs.com ──► Cloudflare edge (TLS) │ cloudflared named tunnel "dsh" (outbound only) ▼
The design standard for every screen in this app, derived from the owner's UI reference github.com/skpawar1305/textile-erp-nextjs (PLANNING §52, 2026-09-04; pre
Owner rule (round 24, binding): every form in the system can be dumped to Excel/CSV with filters drawn from that form's own fields. Dumps are NOT reports (see R
Caveat (owner, 2026-09-02): the existing system is buggy/haphazard — fields below are indicative , verify before trusting (STATUS.md caveat). Extracted via OCR
Copy-exact. This document is the whole specification: a worker who has never opened another form builds one by following this file alone. Every rule below names
Written after the owner said: "I have already said in other sessions while building the form that there will be handwritten text. There is so much OCR discussio
Written 2026-09-07 for a NEW parallel session that will work Phase-2 (Engine & domain services) corrections while the main session fixes Phase 1 (per the owner:
Generated by queue-next.ts --hold-brief (also written by --sync ). Each entry carries its own evidence, so the assistant can open the page, decide, and act in o
Date: 2026-09-30 Host: vps-d3go (2 vCPU, 6 GiB RAM, 512 MiB swap) Services: queue-watch.service , opencode.service , project@trading.service , caddy , cloudflar
Global shell (PLANNING §29): dashboard-first; TODOS = topmost card (desktop) / first in the mobile sidebar; Global Explorer (search/dropdown or app-button grid
Migration planning for the existing myTextile Inventory Management System – Unit 4 (job-work + trading modules) into the greige-fabric platform. This document i
Nothing needs you right now — the runner is working the board on its own.
One section per form, filled as the owner walks it. Each decision line is written in his words where the wording matters, and is what a row must satisfy. Anythi
Rows run one at a time, top-to-bottom of the Pending table, one row per fresh session ( scripts/row-run.sh , agent row ). There are no parallel lanes, so overla
Owner-facing guide to the complete-to-spec build program (PLANNING §97, docs/COMPLETION.md). Each phase: what it means in plain words, what it means technically
Gate: no production features are built until this plan — the working flow, the form map, and the per-field validation — is reviewed and signed off by the owner.
The system is not "an app for one mill" — it is the company platform : multi manufacturing setups, accounting/CRM integration, the base for the company's IoT pr
The queue runner is only as good as the row it is given. A correction that names a screen, a visible outcome, and a way to check it gets implemented and verifie
Every documented item checked and its disposition. Sources: the four doc audits (screens/fields · journeys/roles · reports/prints · engine/ architecture) + the
FILE OWNERSHIP: written ONLY by scripts/queue-next.ts --ask and --answer (the runner asks; any session records your answer). Append-only — one line per question
This is the "row line" switch: it works the correction board by itself , one row at a time, so you don't type /next for every row. How it works - Rows run top-t
FILE OWNERSHIP: written ONLY by scripts/queue-next.ts --sync (the runner). It is a projection of the owner's docs/CORRECTIONS.md Pending table plus the reopen f
Round 24 (2026-09-02) — rebuilt to the owner's philosophy. This catalogue is built step by step, one workflow step at a time : for each step we decide what repo
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-liv
This is the org default stack: Bun → SvelteKit (@sveltejs/adapter-bun) → daisyUI (Tailwind v4) → Drizzle → bun:sqlite , plus Better Auth on top. Every file refe
One-page handoff. Everything referenced below lives in this repo — if this conversation is compacted or you start a new one, read THIS file first, then the poin
Everything here follows the repo rules (README — "The rules of this repo"): - Rule 2 — every solved edge case gets a test. A bug fix, or a change that handles a
Every screen should feel like one calm monochrome workspace — white rounded-xl sidebar with zinc active pills, zinc-100 workspace, white 20px cards, near-black
Every fixed-choice column in the schema, its formal set (what the code may write), and the live range observed in data.db (2026-09-06 audit). These sets are the
Owner contract per PLANNING §97 + PHASES-GUIDE.md §Phase 1: you check the three layers (automated proof, this sheet, your own spot-check) and sign. (You intende
Owner contract per PLANNING §97 + docs/PHASES-GUIDE.md §Phase 2: you never read code — you check the three layers (automated proof, this sheet, and your own 5-m
The yarn spine, drawn for the three order modes the system supports. Node legend: [DOC] = document/event created · (act) = action by role · SYS: = derived by sy
Trading — exhaustive flow × form × field map (A3) @page { size: A3 landscape; margin: 9mm 7mm; } body { font-family: 'DejaVu Sans', sans-serif; font-size: 7.6px