T
Sign in

Docs

Project docs

Planning + technical docs for the greige fabric system.

APP.md — what's live, and how to walk it

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

Read
ARCHITECTURE.md — one journal, two books

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

Read
BOARDS-A.md — DASHBOARD SPECIFICATION (final, rounds 27–43, 2026-09-02)

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

Read
BRIDGE.md — file-based interchange with the existing software

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

Read
BUILD-LOG.md — production build progress (autonomous)

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

Read
BUSINESS.md — domain model for the greige fabric system

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

Read
COMPLETION.md — the master completion checklist (no silently half-done work)

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

Read
COMPONENTS.md — component-first forms (the thin-shell standard)

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-

Read
CORRECTIONS-AUDIT.md — done-list verification (audit session)

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

Read
CORRECTIONS-LOG.md — worker's append-only status feed

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

Read
CORRECTIONS-REOPEN.md — audit session's append-only reopen feed

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

Read
CORRECTIONS.md — pending corrections shelf (owner-driven)

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

Read
COSTING.md — the fabric costing & conversion engine (verified from the owner's sheet)

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

Read
DASHBOARDS.md — runtime dashboards + the report catalogue

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

Read
DEPLOY-PAGES.md — Cloudflare Pages (`trading-tyno.pages.dev`)

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

Read
DEPLOY.md — hosting, deploy loop, credentials

Architecture Browser ── https://trading.tynolabs.com ──► Cloudflare edge (TLS) │ cloudflared named tunnel "dsh" (outbound only) ▼

Read
DESIGN.md — design system (monochrome zinc, §195)

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

Read
DUMPS.md — universal form-dump exports (the dump station)

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

Read
FIELDMAP.md — field inventory extracted from the existing software

Caveat (owner, 2026-09-02): the existing system is buggy/haphazard — fields below are indicative , verify before trusting (STATUS.md caveat). Extracted via OCR

Read
Focus entry — the wizard + summary form pattern

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

Read
GAP-EXPECTATION.md — what the docs promise vs what is shipped (owner-alignment)

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

Read
HANDOFF-PHASE2.md — start here if this session owns PHASE 2 corrections

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:

Read
HELD.md — rows waiting on a decision, ready for the interactive session

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

Read
Correction line — incident report & runbook (vps-d3go)

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

Read
JOURNEYS.md — user journeys (one per role, step by step)

Global shell (PLANNING §29): dashboard-first; TODOS = topmost card (desktop) / first in the mobile sidebar; Global Explorer (search/dropdown or app-button grid

Read
MIGRATION.md — from the myTextile Inventory System to this platform

Migration planning for the existing myTextile Inventory Management System – Unit 4 (job-work + trading modules) into the greige-fabric platform. This document i

Read
Needs you

Nothing needs you right now — the runner is working the board on its own.

Read
ORDER-FORMS.md — the form-by-form reading of the order flow

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

Read
OWNERSHIP.md — file map for sequential correction rows

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

Read
PHASES-GUIDE.md — the build phases: meaning + how you check them

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

Read
PLANNING.md — flow-first planning before any production

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.

Read
PLATFORM.md — the scalable platform architecture

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

Read
PROMPTING.md — how to phrase a correction so it lands first time

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

Read
QA-GAPS.md — overnight QA ledger (2026-09-05)

Every documented item checked and its disposition. Sources: the four doc audits (screens/fields · journeys/roles · reports/prints · engine/ architecture) + the

Read
QUESTIONS.md — questions for the owner (append-only)

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

Read
QUEUE-AUTO.md — the automatic watcher (plain-language)

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

Read
QUEUE.md — runner-owned machine ledger (generated)

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

Read
REPORTS.md — report placement, exceptions & approvals (catalogue)

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

Read
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-liv

Read
STACK.md — how each piece is wired

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

Read
STATUS.md — project state & how to resume

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

Read
TESTS.md — the test suite & the two test rules

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

Read
UI pattern — Textile ERP NextJS reference language

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

Read
VALUE-SETS.md — the formal status/dropdown value sets (Phase 1)

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

Read
VERIFICATION-PHASE1.md — Phase 1 · Database complete · Verification Sheet

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

Read
VERIFICATION-PHASE2.md — Phase 2 · Engine & domain services · Verification Sheet

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

Read
YARN-FLOW.md — complete yarn flow (by order mode)

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

Read
Full Flow — the complete A–F map

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

Open