so a tap on it opens nothing — Kind, Status, System date on all three, and on the job work form also Payment, Brokerage and Pass-on (C137/C138 keep them out of the wizard; a sale and a production order still ask them, so those rows are tappable there). No row anywhere falls back to the wizard's first step, and the shipped client chunk confirms the other half: the "Start the wizard" button is rendered only when the open flag is false (
i(jr)||e(pa) around the template that carries
Start the wizard) and its click handler reopens at the first step that still needs a popup (firstOpenWizardStep over the step ids, then wizOpen=true) — so the wizard starts by default AND a top button restarts it, the row's recorded assumption. MUST NOTs hold: the C141 commit changed no name=, no action="?/create", no enctype and no use:enhance line, server validation (validateOrderFields) and the redirect-based create are untouched, and the hidden form stays mounted (the signed FOCUS-ENTRY 2/3 design, where the visible faces are the read-only summary and the wizard). tests/c141-tap-field-opens-only-its-popup.test.ts 14/14, and RED is measured: pre-fix the module exported no tapOpensPopup (0 hits in 83d415c~1) and the component still carried the hijack
openWiz(i >= 0 ? i : 0).
bun run screens -- --only orders 7/7 and live-check 12/12 (schema 40 tables, evt index, party/design/user data). Note for the record: docs/FOCUS-ENTRY.md 3's example still shows
openWiz(r.step) and
rows: [{ step: 0, ... }] while the code carries each row's FIELD and resolves the popup from it — doc-example drift with no behaviour gap, left alone here because that doc is the signed pattern and C151 just made it copy-exact.
C142 done 2026-09-30 444f2a8 supervisor-settled: the row was genuinely unbuilt — it was claimed with no commit, no test file, and the pre-fix PROOF is the three forms opened over HTTP, where /orders/new/trading and /orders/new/production-order served no name="picks" anywhere (job work did) because picks was a job-only wizard step and the create action nulled the value for every other kind. Built it: picks is no longer job-only (jobRate still is, it is the only field that drives a rate), so a Trading SO and a Production Order ask it in the same own-field step just before the rate that job work uses, and a sale/production step gets the stepper, the coins and typing on top, with its own hint — the job-work step is left byte-for-byte alone, because there the rate really is job rate x picks, and its prefill is left on the exact pair as before so widening it could never move a job-work rate. New lastPicksFor() and picksSuggestions() carry the row's recorded ladder (same quality + same party's most recent actual picks, else that quality alone, else blank; only rows that STORE picks count, so a design master's construction pick count is never a prefill) as a badged prefill the user confirms — nothing is auto-committed. The server keeps the entered picks on every kind (picks = numbers.picks) and the /orders/[id] ?/complete action now records picks on every kind too, because a Picks box rendered on a sale that the action ignored would have swallowed its input; autoRate stays gated on the job-work kinds. MUST NOTs verified on real data, not by reading source: a posted SO with rate 41 + picks 4400 saves rate 41 and picks 4400 (never 41 x 4400) with job_rate null, a posted PROD keeps 38/2200, a posted JW still saves 0.35 x 4400 = 1540, and completing a sale's record to 4800 picks still leaves rate 41. No POST field name, action or validation changed (picks is still one input, still integer > 0) and the one existing expectation the row inverts — c100's "a sale has no picks popup" — now asserts the opposite, with the counted-in and job-rate halves of that test left as they were. tests/c142-picks-field-all-order-forms.test.ts 20/20 and RED is measured (pre-fix the import alone did not resolve), 28 order-related test files green, check clean, screens 75/75, live-check 80/80, deployed + pushed 444f2a8. Post-deploy proof by opening the LIVE app at 127.0.0.1:4102 (signed in through its own endpoint with the production Origin, since better-auth pins that origin): /orders/new/trading and /orders/new/production-order each serve exactly one name="picks" input plus the Picks summary row rendering as a that owns that popup, and no name="jobRate"; /orders/new/job-work serves both, unchanged. Note for the record: a parallel session swept this row's uncommitted source edits into its own commit e6ff4b2 mid-turn; the content is intact and the row's deploy commit is 444f2a8.
C68 done 2026-09-30 owner-closed closed by owner (verified)
C68 done 2026-09-30 owner-closed closed by owner (verified)
C145 verify 2026-09-30 e7b366d supervisor-settled (PLANNING §307): the row was ALREADY BUILT, so nothing was rebuilt — the fix was landed and proved. Landed by CHERRY-PICK of the workstream's own commit e9f5e1f, not by merging swarm/ws1: the brief assumed ws1 held only C145, but git log swarm/ws1 --not master is 12 commits / 12 rows (C143,C144,C145,C147,C148,C149,C150,C153,C155,C156,C159,C163,C165), and a full merge would have landed 11 other rows' unverified work under this row's name and closed rows that were never verified. One conflict only — the orderLogic import line in OrderEntryForm.svelte — resolved by keeping master's C142 lastPicksFor, picksSuggestions and adding qtyWheelMax; the working tree was clean and no merge was in progress, so nothing was clobbered. Because the ws1 conflict record covers all 12 rows, --conflict-clear ws1 was NOT run: it deletes the record and flips the 11 unlanded rows to pending/"stranded, no reachable branch", which is false (their work is reachable on the branch, the merge just conflicts). Instead C145 alone was dropped from .queue-conflicts/ws1.json and the other 11 stay honestly conflicted. The work itself: qtyWheelMax(qtyUnit) + QTY_SLOT_COUNT = 1000 in orderLogic.ts, so the job work quantity wheel spans 1,000 → 1,000,000 mtr and 1 → 1,000 beams instead of stopping at 20,000/20; a quantity TYPED above the top slot is still kept as typed (pickJobQty writes qty = String(v) with no clamp, and the qty field binds qty directly). MUST NOTs verified in the diff: the slot step is untouched (QTY_SLOT_MTRS 1000 / 1 beam), no name=, no action=, no use:enhance line changed, and +page.server.ts plus src/lib/server/ have a ZERO-line diff — the ceiling is a scroll range only, with no server-side maximum. Proof, not source-reading: bun scripts/live-check.ts 80/80 with all 40 tables, the evt dedupe index and 487 party / 627 design / 14 user rows; bun run screens -- --only orders 7/7 opening the real job-work form on a real record; the three order forms serve 200 over HTTP with the wizard on screen. tests/c145-qty-scroll-no-ceiling.test.ts 11/11 and tests/c136-jobwork-qty-unit-slot-scroll.test.ts 17/17 (C145 supersedes c136's own 20-slot pin, so that assertion was moved, not deleted), bun run check clean. NOT DEPLOYED, and deliberately not marked done: scripts/deploy.sh aborted on its own gate with 3058 pass / 2 fail, and BOTH failures are in tests/c143-picked-option-shows-in-field-box.test.ts — C143's own test asserting C143's unlanded feature, left on master by the unverified checkpoint c45ff31. They are NOT caused by this row: the same 2 cases fail identically at c91e766 in a clean worktree, and the source-only assertion (/bind:value=\{qty\}[\s\S]{0,200}?bind:value=/) is false on the pre-change blob too, so the c45ff31 commit message's "suite is green with it in place" was not true. Fixing it means landing C143 (another row, and its work is in the conflicted set), skipping the test, or withdrawing a gate assertion — all three are forbidden, so the deploy gate stays shut and C145 stops at verify. e7b366d is committed on master and unpushed (deploy.sh is the only pusher). The blocker is named on the row's own notes, not in docs/HELD.md: that file is regenerated wholesale by queue-next.ts --sync, so a hand-written line there is wiped and would have hidden the stop.
C155 verify 2026-09-30 df3d312 supervisor-settled (PLANNING §307): the row was ALREADY BUILT and already merged — nothing was rebuilt. The work is ws1's own commit df3d312 ("lead focus-entry lifecycle"), which git branch --contains puts on master AND origin/master, and C155's target files are NOT in the ws1 conflict file list (.queue-conflicts/ws1.json names FOCUS-ENTRY.md, Combobox.svelte, OrderEntryForm.svelte, c143 and c144 — every one of them another row's), so the workstream-level conflicted flag was never about C155's code. --conflict-clear ws1 was deliberately NOT run: that record still covers 10 genuinely unlanded rows (C143,C144,C147,C149,C150,C153,C156,C159,C163,C165) and clearing it wholesale would state a falsehood about them — instead C155 alone was dropped from that local (gitignored) record, exactly as the C145 settlement did. Proof by OPENING, not by reading source (the row's test is entirely source-text, which is how C94/C96/C104 passed on broken pages): opened over HTTP from a boot of the current source as owner. /leads → 200 and it IS the table of previous records — a real daisyUI <table> with Date/Party/Quality alias/Qty columns, the live-filter ListToolbar, Add lead → /leads/new, the WhatsApp swipe handlers and the ?created= row-highlight row class (.row-highlight is in app.css:97, cleared at 4200ms). /leads/new → 200 with the wizard ALREADY open ("Step 1 of 6", "Speak the enquiry") and the real form mounted behind it in the SAME document: the hidden <form method="POST" action="?/create"> sits at byte 316322, the wizard at 317518, exactly one such form, with all seven original names present (partyId, quality, designAlias, dictateText, qty, rate, notes) — nothing lives only in the wizard and no POST field/action/method/hidden input/server validation changed (the create action still returns { ok: true, id, leadNo } and still reads the same fd.get names). The round trip was exercised for real, not asserted: POSTing that form returns {"ok":true,"id":"umrr77jcs9ia","leadNo":"LO-260930-XOIC"}, and /leads?created=umrr77jcs9ia renders that lead with its number — so the saved pop up's driver (result?.type === 'success' && result.data.ok) really fires, the pop up has a real lead number to show, and the 5000ms goto('/leads?created=…') lands on a real highlighted row. The draft offer is at the TOP of the table page (DraftOffer at line 127, before the ListToolbar and SmartTable), bound to draftKey="lead-new-draft" — one browser, one user — with Complete → /leads/new (values carried back by the restore effect) and Delete removing only that sessionStorage key; the back paths are the form's href="/leads" and the check-and-save pop up's ← Back to edit / aria-label="Back to the lead form" backdrop, both returning to the screen they came from. Tests: tests/c155-lead-focus-entry-lifecycle.test.ts 9/9, and all 17 lead test files together 142/142 (dictation, lead-understand, capture/OCR prefill, swipe, status dot, preview/search, wizard fill, validate) — the existing lead behaviour is intact. NOT LIVE, and deliberately not marked done: scripts/deploy.sh aborted on its own gate with 3181 pass / 14 fail. Every failure is in another row's order-form pin (c99-order-payment-dhara "the summary shows one payment row, not two", the order-record next-steps CREATE-next card) from the C143/C144 rewrite + OrderEntryForm repair that landed on master this round — the same class of blocker that stopped C145, and neither test is C155's. The live site is healthy but pre-C155: bun scripts/live-check.ts 80/80 with 75/75 screens open, against build/index.js stamped 14:32 while the C155 commit is 15:38 (grep -r lead-new-draft build/ finds nothing). Making it live means landing another row's work or weakening the suite gate — both forbidden — so the ship stays shut and the row stops at verify with the blocker named in its notes. One probe row ("C155 PROBE", LO-260930-XOIC) was left in the local dev data.db by the round-trip POST; it is uncommitted local dev data and was not deleted (deleting data is a hold, not a supervisor call).
C172 verify 2026-10-01 5013f77 supervisor-settled: the row was ALREADY BUILT and ALREADY ON MASTER — the merge never needed to happen, so nothing was rebuilt. git log swarm/ws2 --not master is exactly one commit (b6157a0, C172), but C172's work already reached master as 5013f77 ("§13b full-flow A1→C6 coverage table, §12 covered-line, PLANNING §340, regression test") via merge 8e46104 from swarm/ws3 — a parallel workstream built the same row. Merging b6157a0 would have been pure churn: git diff master swarm/ws2 on the three target files is 308 insertions / 339 deletions of an equally valid duplicate, and both branches rewrote the same §13b section, so it would have re-conflicted on the very files that conflicted the first time. ws2's copy was NOT merged and NOT cherry-picked. Acceptance, checked item by item: (1) docs/FOCUS-ENTRY.md §13b carries the A1→C6 table with form, route and state per flow row, and every one of the eight ⛔ no form to convert lines carries its reason read off the flow row — A5 SYSTEM-ONLY, B0b zero entry/guard taps, B3 derived ledger, B4 lives on the lot record page, B6 no dedicated form (gatepass inward covers receipts), B8 system-derived, C2 guard-tap only with a vehicle number and no other fields, C4 a register of automatic per-beam state entered through the beam card (C6); (2) the table's own preamble states the rule the acceptance asks for — "a queued row is never shown as live", with ⏳ queued — Cn defined as NOT live and turning into ✅ only on a C130 verification record — and tests/c172-focus-entry-flow-coverage.test.ts has a case named "the three states exist and queued never reads live" that enforces it; (3) §12 step 10 carries the "How to tell if a form is covered (C172)" line, defining covered as a static/full-flow.html row present in the §13b table with route AND state filled in, and stating a flow row with no table line is not covered; (4) the PLANNING log (§340) records the owner's instruction verbatim ("queue focus entry UI on all forms uptill watrp prep in full flow") and the row-per-form split table (C166/C167/C168/C169/C170/C171 | C162/C110/C173/C174/C175) plus the eight no-form reasons and the C6-not-C1 boundary; (5) the test file exists and FAILS PRE-FIX — proven, not asserted: reverting docs/FOCUS-ENTRY.md to the pre-5013f77 blob gives 3 pass / 7 fail (the doc had no §13b and no §12 step 10), and restoring it gives 10 pass / 0 fail. Proof by OPENING, since this row's test is entirely source-text and that is exactly how C94/C96/C104 passed on broken pages: every route the table names was opened on real data via the repo's own capability — bun run screens --only samples|production|gatepasses|bookings|inward|movements|winding|sizing|beams|tippans|lots|orders|leads|quote = 39/39 screens open, live-check whole (6/6–10/10) on every one of the 15 runs against http://127.0.0.1:4102 , so no table line names a screen that does not exist — including /lots/stocktake (B7, 4/4), /sizing (C3), /winding (C5), /beams ?/create (C6), /tippans (C1), /bookings (B1) and /gatepasses/new (B0/B5b). bun run check exit 0 (314 pre-existing svelte warnings, no errors). bash scripts/queue-next.ts --conflict-clear ws2 run so the board stops re-offering the same merge; no other row's work, ledger, schema or form was touched (MUST NOT honoured — the diff is docs and one test file, zero app code). Left at verify per the row brief so an independent verifier signs the landed copy off rather than the supervisor's own read of a workstream it did not author. The row's own acceptance REQUIRES the ten forms to read ⏳ queued, so they were deliberately NOT promoted to ✅ even though the ledger now reads C110/C162/C166–C170/C173–C175 done and C171 doing — the reverse error (a done row shown as live) is the one the row forbids, and each ✅ needs its own C130 verification record, which is that row's work and not C172's. The §340 number collides with C151's §340, but 37 section numbers already collide in PLANNING.md, so that is the doc's existing state, not a defect this row introduced, and renumbering would have churned a file this row is only allowed to append to.
C175 2026-10-01 7edba19 supervisor-settled: opened the LIVE /beams (200 — sectioned summary, '3 required to fill', wizard open at 'Step 1 of 3', tracking/status/rolls/kinari rows, all 14 POST names in the hidden ?/create form, no autofocus) and the LIVE beam record (200 — C6b 'Beam transfer intimation', TO contract/TO sizer/reason, hidden ?/transfer, no wizard on it); tests/c175-beam-card-focus-entry 13/13; live-check 80/80, 75/75 screens. The row's code was already merged and pushed by a swarm worktree; what was actually stuck was a stale interactive rebase in the main tree that aborted every deploy — recovered with git rebase --abort (no ref moved). PLANNING §343. Phone-width-with-keyboard walk not done (no touch browser here) and left on the owner's reverify list.
C180 done 2026-10-02 session-closed-by-operator (session killed with the old drain wrapper; work verified: own tests 15/15, c141/c151 green after re-pointing 2 stale PROD-rate pins to C179)
C179 done 2026-10-02 page-proof shipped: the A4b field scope is now proved by OPENING the real screens, not by reading source. The PROD wizard drops buyer/broker/rate/payment/brokerage/pass-on, the PROD background form + summary drop the 7 commercial fields, the prodorder ops side keeps only order + stockTrigger + stockTarget + the source note, and a stock order with no party and no rate saves. Added tests/c179-production-order-full-flow-fields.test.ts block (6): /orders/new/production-order asks no commercial question while /orders/new/trading and /orders/new/job-work still ask every one; /production/production-order renders no 'Buyer / contract' / 'Rate & terms' / 'Quantity & delivery' section while /production/trading renders all three; a broker-only SO posts its appendage and still gets 400 "Buyer is still pending". Proven fail-pre-fix by reverting the 8 C179 lines (SALES_ONLY_STEPS, the 6 kinds, PROD_CONTRACT_SIDES/PROD_TERMS_SIDES, buyerRequired, IMPORTANT_ONLY, partyMissing) -> 11 fail incl. all 3 page proofs, restored -> 30/30. c149/c103/c148/c147/c141/c167 83/83 green, unedited. tsc comparative: no new error on touched files.
C182 done 2026-10-02 (sha in the commit) the MODE flag is asked NOWHERE at order entry: off the Trading SO field spec (so the background select, the summary row and the check-and-save row go with it), off its prefill/badge/STEP_LESS_ENTERABLE line, and off the production operations 'trading' side + its MTO/STOCK field box; static/full-flow.html A4 loses the MODE flag clause and PLANNING §347 logs the decision. The order.mode COLUMN stays, ORDER_MODES + inSet('mode', …) stay (junk posted by hand is still rejected), the record page still shows Make / stock and still carries it through ?/complete, and the production form still posts the value the picked order carries as a hidden input (now declared in PRODUCTION_OP_INTENTIONALLY_HIDDEN with its reason). Pins re-pointed, never skipped: c167's field→mode→surface list is now pinned BY NAME without mode, and c14-orders/c143/c149/c179/fullflow-orders lose only the mode name. Regression tests/c182-no-mode-flag.test.ts proves it by OPENING /orders/new/trading, /orders/new/job-work, /production/trading and a real SO record with a stored mode — 189/189 across the nine touched-area files, tsc comparative clean. Pre-existing reds NOT from this row (same at HEAD): c144 body-lock pin, c176 rowStep(r) < 0 pin, and the C179-era PROD-step pins in c137/c138/c142. Suite + build + live deploy stay with the drain's ship gate.
C183 done 2026-10-02 the yarn master's GST is now the booking form's GST, prefilled like any carried value with its own chip, and the wizard no longer asks for it: yarn.gst_pct first, the linked order's design.gst_pct (the fabric) when the yarn's is null — the schema's own "null inherits the fabric GST" rule, not a new one. The wizard's gst step is gone (14 steps -> 13; payment term 12 -> 11, remark 13 -> 12), the field stays visible/summarised/editable from its own docs/FOCUS-ENTRY.md §4b popup (FIELD_META step -1, C180's step-less marker, so the summary row opens the GST's own box and never the rate step), and it is not locked — typing and the coins both write it. The last booking's GST stays a one-tap coin in that popup but is never the prefill. MONEY UNTOUCHED: +page.server.ts's derivation is byte-identical (basic = net × rate, gstAmt = basic × pct/100, total = basic + gstAmt, all IGST, sgst/cgst null, gstType not read), no column and no migration, no stored booking rewritten, and the POST name gstPct / action ?/create / every other field and step stay as they were. c104's wizard step list was updated ON THAT ONE LIST — every other step it names is still asserted and its POST-name pins are untouched (the field still posts). Regression tests/c183-booking-gst-prefilled-not-asked.test.ts proves it by OPENING the form over HTTP against fixtures with a yarn GST, a fabric-only GST and neither (9 of 11 cases fail before the row) plus two real ?/create POSTs that pin the stored amounts. Q20 answered by assumption: no linked order means no fabric master to inherit from, so the field stays blank and optional exactly as today. tsc comparative — no new error on the touched files. Suite + build + screens + live deploy stay with the drain's ship gate.
C184 done 2026-10-02 (sha in the commit) the yarn booking form no longer wears the three big section cards the owner spotted "at the bottom": grid grid-cols-2 gap-2 of "Yarn + supplier" / "Bags + weights" / "Rate + terms", numbered, done-ticked, each with its own status line and an Open →/Filling… affordance, sitting BELOW the summary and below the summary's own Clear/Save bar — a second, coarser index that jumped to a wizard STEP instead of to the field a row names, in the one place docs/FOCUS-ENTRY.md §2 has no place for a card. §3's sectioned summary was already the index: one tap per row to that field's own pop-up, so the cards went and nothing replaced them, and the doc now says so in §2 ("There is no section menu", any form, never added again — a "jump to section" shortcut would be a new §2 part agreed first). Dead with them: SECS, menu, secDone, yarnSummary, bagsSummary, rateSummary, the already-unused fieldsLeft, and openSec (only the cards' highlight and reset ever read it). WIZ_STEP_OF_SEC STAYS because the check-and-save sheet's jump-back still resolves through gotoSec(sec, step) to a field's own popup. The capture-draft hint moved from under the summary up beside the procure hint, where §2 part 3 puts a fill hint. UNTOUCHED: all 13 wizard steps and their indexes, every summary row/label/required mark, the hidden real <form> with byte-identical POST names/values/use:enhance and action="?/create", the C14 confirm gate, the GST maths, no stored booking rewritten; guided-gatepass.test.ts / guided-checking.test.ts are other screens and are read-only here — the row borrowed nothing from their menus. tests/c104-booking-focus-entry.test.ts needed no change at all (it never pinned the cards); tests/guided-bookings.test.ts lost only the case that pinned them and gained one that pins their absence plus the 14 summary rows that replace them. Regression tests/c184-booking-no-section-cards.test.ts proves it by OPENING the form over HTTP as an owner — 13 cases, 5 of them failing on the pre-fix source — asserting no card/label/affordance/grid anywhere, nothing at all between the Save bar and the hidden form, the §2 skeleton in order with the prefill hint above the summary, all fourteen fields one tap from their own row and none of them a live input, and all fourteen POST names still posting from the class="hidden" form. bun run screens -- --only bookings 2/2 PASS on live data. tsc comparative: no new error on the touched files (only the repo-wide bun:test module error every test file has). Pre-existing red NOT from this row, same at HEAD: c144's body-lock pin in OrderEntryForm.svelte. Suite + build + full screens + deploy stay with the drain's ship gate.
C185 done 2026-10-03 (sha in the commit) the yarn booking form's check-and-save no longer wears the C14 tick gate: the Needs your ✓ — save blocked (n) group is gone from the sheet and confirmReview() submits, so its Save books the booking even when carried values were never ticked. WHY (measured, not inferred — the list the row asked for): on a real prefill booking (procure ?yarnId&bags, order forward-link ?orderId=, last booking of the same product) the gate counted 13 of the 13 tracked fields — orderId "source order" (0), yarnId "procure" (1), warpWeftTag (2), supplier (3), broker (4), lotNoHint (5), deliveryDate "order SO-…" (6), bags "procure" (7), conesPerBag (8), bagWt (9), ratePerKg (10), gstPct "yarn master" (−1), paymentTerm (11) — and only 3 of them (orderId, bags, ratePerKg) were reachable AT their own field from the sheet, because a gate row carried no step and so jumped to the section's first step; the sheet itself had no ✓ at all (the mark-only chip lives on the summary, outside it). A dead end with a silent Save, which is the owner's "it is not letting me save the page". KEPT: the prefilled badges (every carried value still names its source and stays changeable), the three sheet field groups with each row's own step, the jump back to a field's own popup, and gate() — a bare Enter still passes through the sheet first, so nothing auto-saves. NOT IN THIS ROW: the three ORDER forms keep their C14 "To confirm" gate and /api/approve + /approvals are untouched. UNTOUCHED: all 14 hidden POST fields in order, method="POST", action="?/create", use:enhance, the 13 wizard steps, every summary row/label, the booking's server validation and its GST derivation (byte-identical), no stored booking rewritten. docs/FOCUS-ENTRY.md §18 carries the form as a NAMED EXCEPTION to §7.1's rule, with the reason and the boundary. Regression tests/c185-booking-no-tick-gate.test.ts: 16/16, 2 failing pre-fix, proving it by OPENING the real prefill form over HTTP as an owner and by booking through a real ?/create POST of the carried bytes (1,800 kg net × ₹210 = ₹3,78,000 + 5% IGST = ₹3,96,900). Q22 answered by assumption: the ✓ chip stays tappable and still marks only. tsc comparative — no new error on the touched files. Suite + build + full screens + live deploy stay with the drain's ship gate.
C186 done 2026-10-03 (sha in the commit) G0 — the YARN_IN inward gatepass now carries the SECOND photo static/full-flow.html names: Confirmation photo 【PH/OCR】, the sizer / weaver WhatsApp photo of what was confirmed, as its own summary row with its own popup, beside the existing Gatepass photo 【PH】 that stays exactly as it was. Before this row the form had ONE photo field for G0's TWO photos, so there was nowhere to put the evidence G0 itself names for the confirmed → reconciled legs of its own status ladder; the record could show what was received but not what confirmed it. image is NOT renamed, replaced or reused — two fields, two states, two POST names, two labels, and the two rows are distinguishable on the served summary. NOT required at entry and NOT a wizard step (the confirmation arrives after delivery), so it can never sit in the requiredMissing count that gates Save: a real ?/create POST with no evidence at all still creates the gatepass, and WIZARD_IDS.YARN_IN is still ['sourcePartyId', 'countYarn']. PERSISTENCE (Q23, by assumption): the evidence has no gatepass column, so it rides the creation event payload read off raw FormData — exactly the beamType precedent — meaning no zod change, no schema change and no migration, while the GP photo keeps gatepass.image. A second real defect fell out and was fixed here (Q24, by assumption): FocusEntry calls onfile(id, file) but the page passed a ONE-argument handler, so the existing GP-photo upload appended the string image as the file; the handler now routes on the row id (if (id === 'confirmPhoto') confirmPhoto else gpImage), which is what two photo fields require. UNTOUCHED: every other G0 field, the status ladder static row, the POST field names (the new one is added next to image, nothing renamed or removed), method="POST", action="?/create", use:enhance, the zod schema and every server validation, the seven other kinds (they share the one file and own their evidence in their own rows — only YARN_IN gains it here), nothing auto-commits and no stored gatepass rewritten. Regression tests/c186-gatepass-yarn-in-confirmation-evidence.test.ts proves it by OPENING ?kind=YARN_IN over HTTP as a signed-in owner (both photo rows served, the confirmation one badged 【PH/OCR】 and reading "Optional") and by two real ?/create POSTs that carry BOTH filenames and land — GP photo in gatepass.image, evidence on the creation event, neither overwriting the other — plus one with no evidence at all; 9 of its 11 cases fail on the pre-fix source. docs/FOCUS-ENTRY.md §5 gains step type 7 (photo / evidence file) stating the three rules so the next form copies them. tsc comparative: 28 pre-existing repo errors before and after, none on the touched files. Suite + build + screens + live deploy stay with the drain's ship gate.
C187 done 2026-10-03 (sha in the commit) G0b — the DIRECT delivery intimation now matches static/full-flow.html:33 on all three counts the recheck found. (1) DESTINATION: DIRECT offered G0's shared three (our-godown / premises / named sizer) where G0b lists only "destination premises|named-sizer 【T】" — a direct delivery never lands at our godown's own gate, the trader unloads at one of our places — so DIRECT now offers exactly those two and opens on premises, while the stored value and the destPlace zod enum are untouched (our-godown is still a legal value, and YARN_IN still offers all three): the form narrows what it OFFERS, never what may be STORED. (2) WEIGHTS: KIND_CFG.DIRECT.goods asked gross + net, which G0b does not list — the weights arrive on the inward leg, not on the precursor — so DIRECT's goods block is count + bags now, and YARN_IN / YARN_OUT / WINDING keep their weights byte-identical (both POST names, both columns, both zod messages intact). (3) CLOSE-OUT: G0b closes with "sizer=WhatsApp confirm+photo 【PH】 + post-delivery GP counter-copy signed 【T】" and the form had NO surface for either half. Both now exist as after-delivery summary rows on the DIRECT form: Confirmation photo 【PH/OCR】 (C186's own field — the same evidence, so reusing it beats a second field for the same thing; its caption names the after-delivery side on this kind) and GP counter-copy signed (after delivery) 【T】, a tap over signed / pending. Neither is required and neither is a wizard step, so a real ?/create POST with no close-out still creates the gatepass — the intimation is never blocked by a delivery that has not happened. WHERE IT LANDS and HOW IT PERSISTS were the row's two judgement calls, both Pareto (Q25: on this form, not /inward — C169 owns the premises=inward leg and nothing in src/lib/components/inward/ changes; Q26: one APPENDED POST name counterCopy, read off raw FormData onto the creation event exactly as confirmPhoto and beamType do — no zod field, no column, no migration, so no server validation moves). UNTOUCHED: every existing POST name in order, method="POST", action="?/create", use:enhance={enhanceGate}, the whole zod schema, all eight kinds (none added, none removed), the other seven kinds' own fields, nothing auto-commits, no stored gatepass rewritten. Regression tests/c187-gatepass-direct-delivery.test.ts proves it by OPENING ?kind=DIRECT over HTTP as a signed-in owner (destination reads premises and never our-godown; no gross/net rows; both close-out rows served, badged 【PH/OCR】 and 【T】, both reading "Optional"), by opening YARN_IN / YARN_OUT / WINDING to show their weights are still there, and by two real ?/create POSTs that carry both close-out fields and land them on the gatepass:DIRECT creation event — 10 of its 18 cases fail on the pre-fix source. docs/FOCUS-ENTRY.md §5 gains step type 8 (close-out tap 【T】). Two stale pins C186 left behind (uploadGpPhoto, renamed to the id-routing uploadPhoto) were re-pointed at the current name — same assertion, current text — in tests/statusact-forms.test.ts and tests/guided-gatepass.test.ts, and C186's own pinned POST-name list gained the one appended entry. tsc comparative: 28 pre-existing repo errors before and after, none on the touched files. Suite + build + screens + live deploy stay with the drain's ship gate.
C188 done 2026-10-03 (sha in the commit) B0b — the beam-outward gate tap (?kind=BEAM_OUT) was carrying TWO flow rows at once: B0b's own list is "tap beams from intimation 【SC/T】; actual date 【P】; transporter 【S】; send confirmation 【A】 — zero entry" , while its precursor B0 lists "planner picks the order, taps #beams, then taps the EMPTY-on-floor beam numbers 【T/SC】; consignee sizer 【S】; transport + VEHICLE NO 【S/N】; expected date 【N】" . The form asked the guard to RE-ENTER the planner's numbers before Save would even enable — beamType (width class) and beamCount (# beams) were required wizard steps, expectedDate and vehicle were asked too, all four on top of the flange multi-pick, which read as a free pick off the whole floor list rather than a reconfirmation of what the intimation pre-assigned. Zero entry was met nowhere. Now: BEAM_OUT asks B0b's list and nothing else — the beam/flange numbers from the intimation (tap or scan each, the guard reconfirms them; the label says "Flange nos (beams from the intimation)"), the actual date and the transporter — and the wizard is two steps deep (targetPartyId, beamIds) instead of five. B0's four numbers are B0's: #beams, beam type, expected date and vehicle are no longer asked at the gate, and a static row "Planned on the intimation (B0)" lists them so nobody hunts for them twice. B0b's 【A】 step is a static row, not a missing field: "Send confirmation — Automatic: saving this tap records that the beams were sent" ; nothing auto-commits, opening the page still writes nothing. THIS ROW DOES NOT BUILD THE B0 INTIMATION FORM — B0 sits in the beam card's territory (C175) and building it is that row's call. Q27 taken by Pareto: the mandatory consignee sizer stays the one required pick, because a gatepass with no destination is not a document (zod already refuses a record with neither source nor target party, schema.ts:139) and B0 names the sizer, so picking it at the gate is a one-tap reconfirmation — not the re-entry of a planner number. MUST NOT HELD: no gatepass_link write change, no change to the count-vs-tapped reconciliation (beamOutFlangeError(d.beamCount, d.beamIds, floorCodes) still runs and still rejects), no POST field name added/renamed/moved/removed (all 34 names in order, beamType/beamCount/expectedDate/vehicle included), no action/method/use:enhance change, no zod or server validation change, no gate-tap field removed (the tap list, the date and the transporter all stay and all still post), nothing auto-commits, no kind added or removed, and the other seven kinds keep their own fields byte-identical (YARN_IN / YARN_OUT / WINDING keep their weights and their vehicle, BEAM_IN its C3 step-1, BEAM_REPAIR / BEAM_RETURN their flat beam pickers, DIRECT its destinations, expected date, vehicle and close-out). Regression tests/c188-gatepass-beam-out-zero-entry.test.ts 15/15, 6 failing pre-fix: it OPENS ?kind=BEAM_OUT over HTTP as a signed-in owner (B0b's three rows served and badged 【T/SC】/【P】/【S】, none of the four planner fields anywhere, the send confirmation and the B0 row served as static text, "Step 1 of 2" not "Step 1 of 5"), opens all seven other kinds to show their own fields are still served, POSTs a real zero-entry BEAM_OUT (it lands, status='intimated', one gatepass_link beam row for the tapped flange, payload.beamCount/beamType null) and POSTs one with beamCount=3 against a single tap to show the reconciliation still refuses it. docs/FOCUS-ENTRY.md §5 gains step type 9 (zero-entry gate tap) and §13b's B0b row moves from ⛔ "no form to convert — guard taps only" to ✅ on the signed UI at /gatepasses/new?kind=BEAM_OUT : a zero-entry row IS a form, just the smallest one in the flow. Four stale pins this change invalidated were re-pointed at the current shape, never skipped — tests/beamout-roles.test.ts's planner-row block, tests/c168-gatepass-focus-entry.test.ts's B0 field list + BEAM_OUT wizard, tests/guided-gatepass.test.ts's fourth section title (photo-only on BEAM_OUT now) and tests/c172's B0b "no form to convert" reason, which gained a case asserting B0b is now live with its route. tsc comparative: 28 pre-existing repo errors before and after, none on the touched files. Suite + build + screens + live deploy stay with the drain's ship gate.
C189 done 2026-10-03 (sha in the commit) B5b — the yarn-outward gatepass (?kind=YARN_OUT) was carrying its neighbour's fields: B5b (static/full-flow.html:40) lists FOUR things — "planner SELECTS the yarn barcodes / beam numbers to outward 【T/SC】 + party/weaver 【S】 + vehicle 【N】; guard TAPS each as it exits + reconfirm 【SC】; receiver confirms like a GP 【A】" — while KIND_CFG.YARN_OUT.goods switched on countYarn + ticket + bags + cones + gross + net (with conesPerBag riding in on cones), so yarn GOING OUT to a party or weaver was asked the count, the mill ticket, bags, total cones, gross kg and net kg: six fields that are an INWARD receipt's, none of them B5b's. The form asked ten; the row lists four. NOW: YARN_OUT carries B5b's list and nothing else — the barcode selection (lotIds, already required, caption naming the guard's exit taps), the party/weaver, the vehicle and the taps, and goods: {}. The weights STAY on YARN_IN (G0) and WINDING (C5), byte-identical, where the flow lists them; DIRECT keeps count + bags (C187). A static row under "Which movement" — "Count, ticket and weights (not this gatepass)" — names the inward leg (yarn in, G0) and says that weighing stock which moves out is a MOVEMENT (B5, /movements), its own form, so nobody hunts for them twice. Two judgement calls, both Pareto: Q28 with the goods block gone goodsSectionShown is false, so the "From booking (expected delivery)" prefill row leaves YARN_OUT exactly as C188 left it off BEAM_OUT — it filled only the removed fields, and ?bookingId= forces YARN_IN anyway (resolveKind), so an outward gatepass can never arrive carrying a booking; the contract row stays pickable by hand. Q29 B5b's receiver-confirmation 【A】 gets NO new field: it is an act on the record, already carried by the shared Status static ladder (entered → picked → delivered → confirmed → reconciled), and a second field would store a competing meaning for one status (G0's confirmation PHOTO is C186's confirmPhoto, on the inward leg, untouched here). MUST NOT HELD: no lotIds/barcode handling change and no gatepass_link write change (the lot row for a tapped barcode is byte-identical), all 34 POST field names in the same order with action="?/create", method="POST" and use:enhance={enhanceGate}, the whole zod schema and every server validation (so a POST that still carries a ticket / bags / weights is still stored exactly as before — the form stopped asking, nothing stopped storing), no field B5b names removed (all three stay and all still post), nothing auto-commits (opening the page writes nothing), no kind added or removed, and the other seven kinds keep their own fields (opened over HTTP one by one to prove it). Regression tests/c189-gatepass-yarn-out-b5b.test.ts 14/14, 3 failing pre-fix , proving it by OPENING ?kind=YARN_OUT over HTTP as a signed-in owner (B5b's four rows served, each with its own flow badge; none of the six goods rows anywhere; the static row served; every other kind opened to show its own rows are still served) and by two real ?/create POSTs — a B5b-only one that lands with status='intimated', one gatepass_link lot row and payload.linkCount 1 and no goods invented, and one still carrying the six which is stored unchanged — plus an unknown-barcode POST that is still refused. One stale pin this change invalidated was re-pointed at the current shape: tests/c187-gatepass-direct-delivery.test.ts's "YARN_IN, YARN_OUT and WINDING keep their weights" case now names the two kinds the flow lists the weights on. docs/FOCUS-ENTRY.md §5 step type 9 gains the non-zero-entry half (a shared goods block is read against the row; a switched-off block says where its fields went; a prefill row that fills nothing visible leaves with it) and §13b splits B0b from B5b — B5b ✅ on the signed UI, B0 recorded honestly as not built yet. tsc comparative: no new error on the touched files (only the repo-wide bun:test/bun:sqlite module error every test file has). Suite + build + screens + live deploy stay with the drain's ship gate.
C190 done 2026-10-03 (sha in the commit) C3 step 1 — the sizing return gatepass (?kind=BEAM_IN) now carries the flow row's list and its MODES. THE THREE DEFECTS: (1) the guard's beam taps had no row on this kind — showBeamPick listed BEAM_OUT / BEAM_REPAIR / BEAM_RETURN only, so beamIds was a declared wizard step, a POST name and a gatepass_link write with nowhere to be typed, and the wizard rendered "Step 1 of 2" against the three steps the flow lists; (2) the three captured values were not on C3's modes — beamMtrs badged 【OCR】 with no camera affordance at all, beamEnds 【N】, beamQuality 【OCR】, i.e. free typing with a label on it; (3) FocusEntry calls onscan(id, file) and the page passed a handler that ignored the id, so scanning the quality wrote the sizing quality into the vehicle no . NOW: the taps ask for the physical ids (flangeNo first, beamCodes — the way B0b/B5b tap theirs) under a label that names where the beams come from; beamMtrs is 【OCR/N】+scan, beamEnds 【OCR】, beamQuality 【OCR/X】+scan, all three fed by ONE sizing-slip photo through /api/ocr → parseSizingSlipStep1 (the parser /sizing already uses) that only ever prefills — each row's caption flips to "Scanned from the sizing slip — check it", a slip the parser cannot read leaves the fields empty for typing, and the vehicle's plate read is untouched behind the same handler. THE HISHOB STAYS OUT: a static row "Full hishob (not this gate tap)" names C3 step 2 (the reconciliation, C173's screen), so the kind hint's "full hishob later" stays true and nothing here books yardage. TWO PARETO CALLS: Q30 quality is badged 【OCR/X】, not the C168 table's 【OCR→S】 — the widget is a free-text box with no option list, and the same three values now carry the same codes on both C3 step-1 surfaces; Q31 the hishob is stated as a static row (the C188/C189 pattern for fields a kind does not ask), which adds no POST name, no column and no booking. MUST NOT HELD: no hishob, no yardage booking, no costing/price field, all 34 POST field names in the same order with action="?/create", method="POST", use:enhance={enhanceGate}, the whole zod schema and every server validation (beamMtrs/beamEnds/beamQuality still ride the creation event payload unchanged), the auto-lot hook still ['YARN_IN','WINDING','DIRECT'] so a beam-in creates no lot, the sizing receipt screen (C173) untouched, nothing auto-commits, no kind added or removed, and the other seven kinds keep their own fields. Regression tests/c190-gatepass-beam-in-c3.test.ts 16/16, 8 failing on the pre-fix source , proving it by OPENING ?kind=BEAM_IN over HTTP as a signed-in owner (the three rows served on their C3 badges, the tap row served badged 【T/SC】 and required, "Step 1 of 3", the hishob static served as text), POSTing a real BEAM_IN (lands, status='intimated', one beam gatepass_link on the tapped flange, payload.beamMtrs 1250 / beamEnds 2400 / beamQuality set, linkCount 1, no lot), POSTing an unknown beam code (still refused) and opening /sizing (C173's screen still serves its own steps and POSTs). One stale pin this change invalidated was re-pointed at the current shape, never skipped — tests/c189-gatepass-yarn-out-b5b.test.ts's BEAM_IN row list. The five sibling gatepass suites (c168/c186/c187/c188/c189) re-run green, 66/66. tsc comparative: no new error on the touched files (only the repo-wide bun:test/bun:sqlite module error every test file has). Suite, build, screens and the live deploy stay with the drain's ship gate.
C191 done 2026-10-03 (sha in the commit) BEAM_REPAIR — the gatepass kind the flow never listed, now listed. The recheck: KIND_CFG.BEAM_REPAIR (?kind=BEAM_REPAIR, "Beam → repairer.", set no, no goods) has existed since §198 put it in the sidebar, while static/full-flow.html's beam rows are B0 (out intimation), B0b (out taps), C2 (outward, guard taps), C3 (sizing receipt), C4 (out-house ledger) and C6/C6b (card + reassign) — none of them "a beam goes out to a repairer" . So C165 had no list to check the form against, and the kind's beam-tap caption pointed at C2's pre-assignment, which is a tippan outward to a sizer, not a repair. THE ROW'S OWN QUESTION (gatepass / B5 movement / part of C6b / retire the kind) is settled Q32, by Pareto , on §28's own words: "BEAM OUT FOR REPAIR: new beam movement via the gatepass system (intimation → guard taps → GP; return after repair)" — the gatepass system, i.e. a doc. So not a movement (B5's list is yarn stock: barcodes, kg, cones, reason codes, owner/contract flips), not C6b (a contract/sizer reassign intimation), and not retired (the row's MUST NOT: nothing is deleted while the question is open). SHIPPED: static/full-flow.html gains C2b Beam out for repair (gatepass) , drafted FROM what the form already asks, each on the mode the form badges — to REPAIRER 【S】; beams / flange nos 【T/SC】 on the physical ids (the guard's exit taps, the way B0b and B5b tap theirs); sizing set no 【P】; order / contract (optional) 【S】; vehicle no 【SC/N】; transport 【S】; gatepass photo 【PH】; GP no + GP date 【A/P】; the status ladder 【A】 — and it says what the leg is NOT: no goods, no hishob, no yardage, no rate, with the mending and the beam's return a separate record. Placed beside C2 in stage C with nothing renumbered (C2, C3, C4, C5, C6, C6b byte-identical; C2b takes no number in use). The form moves by two lines of prose and one static row: the beam-tap caption names C2b for this kind instead of claiming C2's pre-assignment (the generic caption stays for BEAM_RETURN, whose own flow row is C192's open question — not this row's to settle), and "Repair and its return (not this gatepass)" says the mending and the return are elsewhere, the pattern C188/C189 set for a field a kind does not ask. MUST NOT HELD: all 34 POST field names in the same order with action="?/create", method="POST" and use:enhance={enhanceGate} (a static row posts nothing), the whole zod schema and every server validation untouched, KIND_CFG.BEAM_REPAIR byte-identical, the wizard's two steps (['targetPartyId','beamIds']), no kind added or removed, the auto-lot hook ['YARN_IN','WINDING','DIRECT'] (a repair books no lot), nothing auto-commits, no stored gatepass rewritten, and the other seven kinds keep their own rows (opened over HTTP one by one to prove it). Regression tests/c191-gatepass-beam-repair.test.ts 15/15, 6 failing pre-fix (flow-map + caption + static-row cases, proven by stashing this row's three source files), by OPENING ?kind=BEAM_REPAIR over HTTP as a signed-in owner (two compulsory steps, the repairer pick 【S】 and the taps 【T/SC】 on the physical ids, the static row served as text and not as a field, no goods / hishob / yardage / rate row on the kind) and by a real ?/create POST that lands the repairer, the tapped flange and the set no with status='intimated', one gatepass_link beam row, payload.linkCount 1, no lot — plus an unknown-beam-code POST still refused with 400 and an open that writes nothing. One stale pin this change invalidated was re-pointed at the current shape, not skipped: tests/c189-gatepass-yarn-out-b5b.test.ts's "the B5b static row leaks onto no other kind" asserted the loose phrase 'not this gatepass', which BEAM_REPAIR's own static row now also ends in — it now asserts the whole label, the stronger check. docs/PLANNING.md §358 logs the decision. tsc comparative: 983 pre-existing repo errors before and after, none on the touched files except the repo-wide bun:test/bun:sqlite import error every test file has. NOT fixed here, and pre-existing (proven by re-running it with this row's changes stashed): tests/c172-focus-entry-flow-coverage.test.ts's "the queued forms carry their route and their queue row" fails on B0 — docs/FOCUS-ENTRY.md §13b's B0 line was re-worded by C188 and no longer names the route; that file is not in this row's targets. Suite + build + screens + live deploy stay with the drain's ship gate.
C192 done 2026-10-03 (sha in the commit) BEAM_RETURN — the gatepass kind the flow had no row for, answered and re-pointed. Q33, answered by Pareto: it folds into B5's existing "returns to party" clause — no new flow row, and the kind is not retired (a live kind is not removed by a row, and this row's MUST NOT says nothing is deleted while the question is open; C170's movements form is DONE, so a second row would duplicate the clause the map already states). What was actually wrong on the page: the beam-tap caption told the guard this leg was "C2 pre-assign " — a tippan outward to a sizer — while a party-owned beam going back to its party is B5's return-to-party movement (no buy/sell doc), carried out on the gatepass by the guard's exit taps on the physical flange nos. Shipped: static/full-flow.html's B5 cell now names the beam leg and the gatepass kind that carries it (B5's own yarn fields, vehicle no, reason code and audit clause byte-identical, row not moved, nothing renumbered, C191's C2b untouched); the kind's served hint and its beam-tap caption name B5. NOT done, deliberately: no new flow row, no field / kind / POST name / action / method / zod / server-validation change (all 34 POST names in order), no change to /movements or its lot items, no lot booked, nothing deleted, the other seven kinds untouched. Proof: tests/c192-gatepass-beam-return.test.ts 13/13 (5 failing on the pre-fix source), opening ?kind=BEAM_RETURN over HTTP as owner and POSTing a real beam return (party + tapped flange + set no land; an unknown beam code is still refused; the page writes nothing on open); the five sibling gatepass suites re-run green (64/64) and bun run screens -- --only gatepasses 4/4. C191's loose pin on the leftover C2 caption string re-pointed at C2b's own caption. tsc comparative: no new error on the touched files. Suite, build and the live deploy stay with the drain's ship gate.
C193 done 2026-10-03 (sha in the commit) WINDING — the gatepass-batch row for the sizing-to-winder leg, in the two halves its own recheck called for. (1) The overlap, confirmed rather than assumed: the WINDING kind and C5 share exactly six fields — set no, winder, bags/cones, gross, net, year — and the form (?kind=WINDING) asks all six on C5's modes. It asks none of C5's receipt figures: no empty bags/cones, no ring wt, no received net wt, no net/gross difference, no set closing. Those are the winder's own report, weighed against what sizing sent, and they are asked once, on /winding, which is C174's screen. The hint already said so; the row makes the page say it too — a static row, "Empties, ring wt, received net (not this gatepass)", names the receipt's five figures and where they are recorded (the C188 / C189 / C191 pattern on this same file), and the hint now names the outward leg as C5b while keeping its promise true. (2) The flow question, settled Q34 by Pareto: the outward leg is its OWN row. The map was half silent, not silent: C5 exists and is entirely the receipt, while C3 step 2 already promises a different document — "after final hishob the system ALLOWS creating the WINDING-YARN GATEPASS → issued to the winder for pickup from sizing". So static/full-flow.html gains C5b Winding-yarn outward gatepass (sizing → winder) , placed immediately before C5 and drafted from what the form already asks: to winder 【S】; sizing/warping set no 【P】; bags/cones 【N】; gross wt + net wt 【N】 (weighed at the gate); transfer year 【P】; vehicle no 【SC/N】; transport 【S】; gatepass photo 【PH】; GP no + GP date 【A/P】; the status ladder 【A】 — and it says, in the map itself, that the empties / ring wt / received net wt / net-gr difference / set closing are the winding RECEIPT's (C5) and are asked once, there. Not part of C5 (one row cannot carry both a gatepass and a reconciliation), not a B5 movement (B5's items are yarn lots; C3 says gatepass), not retired (a live kind is not removed by a map row). Nothing renumbered (C1, C2, C2b, C3, C4, C5, C6, C6b all keep their labels and cells), C5's field cell byte-identical — two neighbours are named instead of rewritten: C3's WINDING-YARN GATEPASS carries the identity (C5b), C5's "when" cell says the yarn leaving sizing is C5b's doc. MUST NOT HELD: /winding byte-identical (its empties, ring wt, received net and auto diff/set/GP rows untouched), the winding receipt's amounts exactly where the flow puts them, the auto-lot hook ['YARN_IN','WINDING','DIRECT'] at src/routes/gatepasses/+page.svelte:103, KIND_CFG.WINDING's keys and values (label, dir, goods: { bags, cones, gross, net }, setNo, setLabel), the wizard's two steps, all 34 POST names in the same order with action="?/create" / method="POST" / use:enhance={enhanceGate}, the whole zod schema and every server validation, nothing auto-commits, no stored gatepass rewritten, no kind added or removed, and the other seven kinds keep their own fields (opened over HTTP one by one to prove it). Regression tests/c193-gatepass-winding-kind.test.ts 17/17, 8 failing on the pre-fix source (proven by stashing this row's four source files): the map cases, the two served-page cases (?kind=WINDING's hint and its static row) and the doc cases fail before, while the nine MUST NOT guards — the six-field overlap, no receipt field on the gatepass form, /winding still carrying all of them, the seven sibling kinds, the 34 POST names, KIND_CFG.WINDING, the lot hook, a real ?/create POST that lands the winder + set no + bags/cones/gross/net + the FY, and no write on open — pass before and after, which is the point. docs/FOCUS-ENTRY.md §5 gains the mirror-leg half of step type 9 (a receipt's figures are asked once, on the receipt screen; a static row says where they went; two flow rows may share a noun and still be two documents) and §13b gains C5b as ✅ on the signed UI at /gatepasses/new?kind=WINDING, placed after C5's line so a lookup for C5 still finds C5. docs/PLANNING.md §360 logs the decision. Sibling gatepass suites + C174 re-run: 75/76 — the one red is C172's pre-existing B0 pin (§13b's B0 line was re-worded by C188 and no longer names the route; recorded by C191, owned by C196, not this row's file line and not touched here). bun run screens 80/80. tsc comparative: no new error on the touched files (only the repo-wide bun:test/bun:sqlite lines every test file carries). Suite + build + live deploy stay with the drain's ship gate.
C194 done 2026-10-03 (sha in the commit) G2 "Transporter pickup" — the due-for-collection list the row was queued to BUILD was already shipped, so this row proved that and fixed its shape. Q35, answered by Pareto: fix the surface that is there, do not fork a second one — /transporter's load is every OUTWARD gatepass in intimated | due | partial, so an intimation lands on the board the moment it is created (no filing step, nothing for a person to set), it renders the beams/boxes to lift from gatepass_link, and ?/pick writes picked | partial + pickup_date / pickup_note / pickup_photo on G0's own ladder . The row's recheck ("no G2 anywhere in the code") had searched for a due-for-collection status ; the surface is the transporter board, and a second list on /gatepasses or /dispatch would have been exactly the second status vocabulary the row's own MUST NOT forbids (/dispatch keeps C161's shape and gained nothing; its pre-slip loading list already sits on the board as its own section). WHAT WAS GENUINELY MISSING is the shape the acceptance names: the pickup was a visible long form inside a per-row card — an inline checkbox, an inline date box, an inline note box, a phone form asking a transporter to TYPE. It is now the focus-entry pattern (docs/FOCUS-ENTRY.md §3/§4): a read-only sectioned summary ("Beams / boxes to lift" from gatepass_link + "Pickup" : pickup 【T】 · date 【P】 · note · photo 【PH】) over a HIDDEN POST form, one field per pop-up, no section cards , committed by the single Picked ✓ tap; no wizard, because no field on a labour screen is important enough to be a step, and the pop-up sits items-end so the phone keyboard never covers it. The per-row card chrome is gone from the list (which is now keyed by row id, so a refresh cannot carry one row's state into another's), and /gatepasses's footer sentence became real links to /guard and /transporter. FIXED ON THE WAY: the lot label lookup in the transporter load tried the lot id alone while B5b files gatepass_link under the picked barcode / lot no — so every box to lift on a yarn-outward intimation read lot: —; it now mirrors the beam lookup (id → lot no → barcode), read-only. static/full-flow.html's G2 cell keeps its whole list byte-identical and gains the two facts this row settled (built from every OPEN outward intimation, no filing step; rides G0's ladder — entered→picked(partial/all)→delivered→confirmed→reconciled — no second status); docs/FOCUS-ENTRY.md §13b gains the G2 Transporter pickup row as ✅ on the signed UI at /transporter ?/pick (§13's own table untouched, so C151's pin still holds). MUST NOT HELD: the eight kinds, all 34 POST field names on the gatepass form, action / method / use:enhance, both zod schemas and every server validation; the transporter's contract is still the same five names (id, partial, pickupDate, note, photo, the partial tap still posting on) and its three refusals (forged id, inbound row, already-delivered row) all still refuse; a pickup never edits the gatepass it lifted — kind, direction, GP no, party, bags, cones, net, vehicle and transport are asserted byte-equal before and after; nothing auto-commits (opening the board writes nothing); no gatepass deleted or re-numbered; /guard, /dispatch and /gatepasses/[id] untouched. Regression tests/c194-transporter-pickup.test.ts 16/16, 7 failing on the pre-fix source (the two flow-map cases, the served-row shape, the pop-up/no-card shape, the partial value, the partial POST value and the §13b row), proving it by OPENING /transporter and /gatepasses over HTTP as a signed-in owner and by real POSTs: a ?/create outward intimation carrying a beam code (B0) and a lot code (B5b) lands intimated with both gatepass_link rows and is served with both lines named (beam: BM-E2E-5001 / flange 99 · floor, lot: E2E-1 · available); a ?/pick tap lands picked + the date + the note + the photo; the partial tap lands partial and the row stays on the board while the picked row leaves it; every field of the gatepass is unchanged. Sibling suites re-run green (c165 + events + forms + gatepass-table + gatepass-kinds 47/47; c151 doc pin + airtight-money 98/98). bun run screens -- --only transporter 1/1. tsc comparative: no new error on the touched files (only the repo-wide bun:test / bun:sqlite lines every test file carries). Suite, build and the live deploy stay with the drain's ship gate.
C195 done 2026-10-03 (sha in the commit) G4 "Gate inward" — the plate read is now a FIELD MODE (camera primary, typed fallback) and the inward code got its own scan field, which is a lookup, so no POST name, column or migration moved. Landed on top of C169 , which had already shipped the /inward focus-entry receipt — this row corrects that shape and does not fork it. G4's entry is /inward (the gate arrival); the gatepass form is G0's intimation and gained nothing G4 owns. MUST NOT held: status vocabulary, eight kinds, POST names, action/method, both zod schemas, every server validation; no face/biometric (G4 is 【TBD】); no inward record rewritten; nothing auto-commits. Proof: tests/c195-gate-inward-g4.test.ts 17/17 (12 red pre-fix) by opening /inward + /gatepasses/new?kind=YARN_IN over HTTP; screens --only inward 1/1, --only gatepass 4/4. Two stale pins about this same field (onscan={ocrVehicle} in c14/statusact-forms, red since C190) corrected in passing.
C196 done 2026-10-03 (sha in the commit) The gatepass status table stops lying — docs/FOCUS-ENTRY.md §13's /gatepasses/new line still read "⏳ not migrated — a plain full form: no sectioned summary, no field pop-up, no wizard. It ships none of §2–§4" , which stopped being true when C168 shipped the shared shell (402ba69) and the batch then audited every kind field by field. A status table that lies is worse than no table: the next row reads it to decide what is left, and this one would have sent a worker to rebuild a shell that already exists. THE LINE NOW names what is there — §2 the title over the summary, §3 the sectioned summary, §4 the per-kind one-field wizard, every POST name byte-identical behind the hidden ?/create form, on the C168 shell — and lists the per-kind audit one row per kind rather than collapsing it into "the gatepasses are finished": YARN_IN C186, DIRECT C187, BEAM_OUT C188, YARN_OUT C189, BEAM_IN C190, BEAM_REPAIR C191, BEAM_RETURN C192, WINDING C193 , with C194 (G2 transporter pickup) and C195 (G4 gate inward) named as forms of their own, not kinds. Named rather than glossed: the one gate still open on this form is the §12 items 7–8 phone-width evidence (390 × 844, the keyboard actually open) — no gatepass row has recorded it, so the line says so instead of claiming the form is finished. Nothing of §2–§4 is missing: all eight kinds were OPENED over HTTP as a signed-in owner and each serves the title, the sectioned summary with its required-count line, the hidden <form method="POST" action="?/create" class="hidden"> and the wizard dialog open. TWO PARETO CALLS: Q36 the row's premise that C186–C195 was the remaining per-kind work was stale (all ten shipped) — the row's job is doc truth, not a rebuild, so the line states the audit as done and the still-open gate by name; Q37 tests/c172-focus-entry-flow-coverage.test.ts's red B0 pin (logged as owned by C196 by C191 and C193) is corrected TEST-side , never by rewriting another docs/FOCUS-ENTRY.md line, which this row's MUST NOT forbids — B0's own line is truthful today (the planner's intimation form is not built; the gate tap under it is C188's). While there: rowFor() matched flow ids by prefix , so rowFor('B5') had been returning the B5b gatepass row C189 added above B5 — a second red hidden behind B0's; it now matches the flow cell's own id. MUST NOT HELD: no other line of docs/FOCUS-ENTRY.md is rewritten (the five sibling §13 rows are asserted byte-equal by the new test), no form or component touched — src/routes/gatepasses/new/+page.svelte and src/lib/components/focus/FocusEntry.svelte are untouched, all 34 POST names, action / method / use:enhance, both zod schemas and every server validation unchanged, no kind added or removed, no stored gatepass rewritten, nothing auto-commits. Regression tests/c196-focus-entry-gatepass-status.test.ts 14/14, 4 failing pre-fix (the four doc cases; proven by stashing this row's doc change) with the eight page cases green before and after, which is the point — the doc may only claim what the page really serves. tests/c151-focus-entry-doc-copy-exact.test.ts's pin that required the §13 line to read ⏳ for the gatepass form (C151's own "a form only claims the wizard it ships" guard, red since C168) re-pointed at the shell that really ships it. tests/c172-focus-entry-flow-coverage.test.ts 12/12 (was 10/11 + one hidden red). bun run screens -- --only gatepasses 4/4. tsc comparative: no new error on the touched files (only the repo-wide bun:test / import.meta.dir lines every test file carries). Suite, build and the live deploy stay with the drain's ship gate.
C197 done 2026-10-03 (sha in the commit) "A lot of fields are carrying data instructions" — the summary value slot was the only place a sentence could go, so 30 static rows printed their prose where a value belongs (the owner named the beam-in gatepass's GP no: "Auto on save — the next GP number" ). Why, read from the code not guessed: FocusEntry.svelte resolves a row's value as staticValue ?? values[f.id], a mode: 'static' row is not tappable, and sub renders only inside the pop-ups — so staticValue did two jobs, a value and prose, and the instruction had one slot left. The fix, once, in the component that decides the slot: staticNote is a new prop that renders in that field's own read-only pop-up's sub line (§4b) and nowhere else; a static row with a note is tappable, one without stays a plain <div>; the value slot now reads a value, Auto, Automatic or the doc's own —. Nine call sites corrected (beam card 8 · inward 4 · gatepasses 4 · movements 4 · stock take 3 · samples 3 · sizing 2 · winding 3), every real computed value byte-identical (beam meter, party, cones, gross/net, kind, totals, set counts, variance, the carried-order line), no POST name / action / method / use:enhance / zod / event / field / row-count change , and the A/P/N/S/T badges with the red * / "Tap to add" / "Optional" rules untouched. Six rows keep their text on purpose , named in docs/FOCUS-ENTRY.md §18 with the row that pins each: C188–C193's five flow rows (beamPlanStatic, yarnGoodsStatic, repairStatic, hishobStatic, windReceiptStatic), whose sentence is the delivery and is proved over the served page by c188/c189/c190/c191/c193, and statusStatic's state ladder, which has no verb. Q38 and Q39, both Pareto and both on the record: the five flow rows stay (moving them redoes four completed rows' evidence, which this row's MUST NOT forbids); the carried-order line keeps every descriptive word and gives up only its instruction tail; no kind badge on static rows (four sibling tests locate a static row by its exact >Label</span><span class="truncate font-medium" markup, and a nested badge span breaks all four). Proof: tests/c197-no-instructions-in-field-rows.test.ts 30/30, 24 failing pre-fix with the sources stashed — the nine call sites AND the served pages opened over HTTP as owner; sibling suites 280/280 (c186 · c187 · c190 · c195 · c196 · c14 · c40 · fullflow · gatepass-kinds · beamout-roles · chip-suggest · revpicker-buy · guided · ui), with two stale staticValue: source pins in c186/c187 re-pointed at staticNote: (same sentence, same intent); bun run screens 75/75; tsc comparative clean on the touched files. Suite, build and the live deploy stay with the drain's ship gate.
C198 done 2026-10-05 (sha in the commit) The watcher wakes on a completed row — the C184-then-C185 5h37m stall, measured, not guessed. The loop's tick is extracted to scripts/queue-watch-lib.sh: the fingerprint gains git rev-parse HEAD and the stamps file (any committed row wakes the line, board write or not), the reap branch falls through to the same evaluation (a drain that exits with a runnable row behind it starts it on that tick), and the stall alarm + thermal tick run above the cheap skip with cheap-first ordering (drain/row liveness before the 86 ms board read). scripts/row-run.sh byte-identical, STALL_S 1800 and one-shot .queue-stall unchanged, systemctl restart queue-watch.service after the edit with a new watcher up line in the log. Proof: tests/c198-watcher-wakes-on-completed-row.test.ts 5/5, red pre-fix (0/5 with the lib moved aside), driving the real tick in a sandbox repo — stable fingerprint still fires thermal + .queue-stall + notify, quiet idle stays quiet on SLEEP 10, reap starts the drain with board bytes identical, triple failure backs off 900 s, a bare commit and a stamps touch both move the fingerprint. Q40/Q41 Pareto: the stale Oct-4 tree is left byte-identical and no deploy.sh runs from this session, so suite + build + live deploy stay with the ship gate once the owner settles that tree.
C199 done 2026-10-05 (sha in the commit) The order-form OCR read fails: every gateway body sent thinking: { type: 'disabled' } and the opencode-go gateway rejects that field outright — re-proved live with the real key (identical body: 400 with the field, 200 without). The field is deleted from all four call sites (orderDocRead, intake x2, order-understand); LLM_MAX_TOKENS = 4096 stays. New readDocumentWithReport sibling carries the last HTTP status while readDocumentWithLLM keeps its null contract, so every fallback order is byte-identical; the order-OCR route fails visibly WITH the status when the gateway answered >= 400 and nothing was read (photo with no transcript, or an empty fallback) instead of reporting "nothing matched" — a 200-empty answer still reads as nothing-matched, honestly. Proof: tests/c199-order-ocr-read-fails.test.ts 10/10 (7 red pre-fix: captured bodies carried the field; 400 came back unreachable/ok), driving the real route POST with a stubbed 400; siblings 144/144 (c114, c139, c112, c113, c154, c181, intake x2) so all four AI reads still answer. Two c114/c154 call-text pins re-pointed at the new call (same intent). MUST NOTs held: no POST name/action/method/validation change, C181 affordance and C113 parser untouched, no secret in git.
C200 done 2026-10-05 (sha in the commit) "the new tippan button does not work" — the anchor was never the fault; the page it opens was dead. Found by opening the running app, not by reading the button: a headless chromium (playwright's, over CDP) signed in through the app's own endpoint, tapped New tippan on /tippans, and followed it. The anchor at src/routes/tippans/+page.svelte:110 is served correctly, passes hit-testing and does navigate to /tippans/new — which then threw each_key_duplicateFault 1: TippanWizard.svelte's <datalist id="loom-types"> keyed its each on l.loomNo, and a loom NUMBER is not unique in the master (l-37 and lo-mt-37 are both loom 37; 24 duplicated numbers), so Svelte aborted hydration for the WHOLE screen — served HTML intact, live page empty: 0 summary rows, no dialog, no h1. That is what "the button does nothing" looks like. Fault 2, found by the same walk: the page binds bind:wizStep/bind:wizSearch (BookingWizard's names since C104) while the wizard declared step/search, so openWiz(n) never reached the component and every summary row opened step 1 — a form that looked right and sent you to the wrong field. Both fixed in the one component: the datalist offers each distinct suggestion once and is keyed on that (a native autocomplete list cannot use duplicates anyway), and the wizard's props carry the names the page already binds. The wizard is renamed to the page, not the page to the wizard — wizStep/wizSearch/openWiz/wizNext is the larger existing vocabulary. Live re-proof, on the running app: both /tippans buttons (header and empty state) land on the form; summary rows jump to their own field (Quality → Step 3 Which quality? , Beam req date → Step 4, Loom → Step 5); the design list search re-filters (40 → 14 options); the datalist serves 73 distinct suggestions; 2 required to fill disables Check the tippan exactly as it should; zero client exceptions . MUST NOT held and asserted: all 26 POST names, action="?/create", method, every server validation string, ?/solve, ?/assign, the 23-step list, the record page / print / amend, and light mode. src/routes/tippans/+page.svelte, +page.svelte (new) and TippanSummary.svelte were read and needed no change. Proof: tests/c200-tippans-new-button.test.ts 5/5, 2 red pre-fix with the fix stashed (duplicate-key datalist, then the dead wizStep binding); siblings 149/149 (c110 · c129 · p3-ux · chip-suggest · guided-tippans · c178 · revpicker-mid), with one c110 counter pin re-pointed from Step {step + 1} to Step {wizStep + 1} (same sentence, same intent — the counter still shows N of M); bun run screens -- --only tippans 4/4 with live-check 9/9; tsc comparative clean on the touched source. Q43 Pareto: the row was queued believing the fault was on the list page; the destination is what was broken, which the row's own acceptance covers, so both destination faults were fixed and the correct list-page anchor was left alone. Suite, build and the live deploy stay with the drain's ship gate.
C201 done 2026-10-05 (sha in the commit) "G0 and G0b of the full form not done properly. Fields don't match the full flow" — the last of the gatepass batch, and a correction of C186/C187 rather than a redo: both keep what they shipped (the confirmation evidence, the destination, the counter-copy), because those implement G0/G0b fields. Read cell-first, both cells in full. G0 lists no vehicle and no transporter (G4 reads the plate where the load arrives, C195; G2 takes the pickup, C194) and no total cones — with the bags and the cones per bag both asked, a typed total asks the same figure twice, and the cone count belongs to B6/C5b, balanced by B7. G0b is an intimation : it lists count/bags expected, destination, expected date, status and its close-out, so it asks no mill lot (a shade identity — G0's line and B2's lot no) and no cones per bag (G0's, and the booking's). Each displaced field leaves a static row naming the row that owns it (C189/C192's precedent) whose value slot carries that flow row (G4 · G2, B6 · C5b, G0 · B1) with the sentence in staticNote, so C197's rule holds and §18's six named value-slot sentences are unchanged. A field's mode is read off the cell that serves the form, per kind : countYarn is G0's 【S】 mill-master pick and G0b's 【N】 typed expectation; confirmPhoto is G0's 【PH/OCR】 and G0b's 【PH】. Nothing stops storing what it stopped asking — vehicle / transport / millLotNo / cones keep their hidden inputs, zod fields and columns, proved by a real ?/create POST that still carries and stores them. MUST NOTs held and asserted: static/full-flow.html itself (the form was wrong, not the signed map), the other six kinds, every POST name / action / method / zod field / server validation, the destPlace enum and its values, the one status ladder, no kind added or removed, no stored gatepass rewritten, nothing auto-commits, G2/G4 not rebuilt. Proof: tests/c201-gatepass-g0-g0b-flow-fields.test.ts 15/15, 11 red pre-fix , and it walks the flow's own field list — the G0/G0b cells are parsed out of the map at run time, so a field added to or dropped from a cell fails until the form follows; every assertion is over the page opened as a signed-in owner. Gatepass family re-run green (208/208 + 58/58) after nine prior-row pins that had frozen on the pre-C201 shape were re-pointed with their intent intact (the showVehicle/showMillLot flags, four served row lists, and C195's plate-field proof moved from YARN_IN to YARN_OUT, which still lists a vehicle). tsc comparative clean. Q44–Q48 Pareto and on the record. Suite, build, live deploy and bun run screens -- --only gatepasses stay with the drain's ship gate (a row session runs tsc only).
C201 deleted 2026-10-05 owner-deleted
C68 deleted 2026-10-05 owner-deleted
C71 deleted 2026-10-05 owner-deleted
C80 deleted 2026-10-05 owner-deleted
C94 deleted 2026-10-05 owner-deleted
C95 deleted 2026-10-05 owner-deleted
C96 deleted 2026-10-05 owner-deleted
C97 deleted 2026-10-05 owner-deleted
C98 deleted 2026-10-05 owner-deleted
C99 deleted 2026-10-05 owner-deleted
C100 deleted 2026-10-05 owner-deleted
C101 deleted 2026-10-05 owner-deleted
C102 deleted 2026-10-05 owner-deleted
C103 deleted 2026-10-05 owner-deleted
C104 deleted 2026-10-05 owner-deleted
C105 deleted 2026-10-05 owner-deleted
C106 deleted 2026-10-05 owner-deleted
C110 deleted 2026-10-05 owner-deleted
C111 deleted 2026-10-05 owner-deleted
C112 deleted 2026-10-05 owner-deleted
C113 deleted 2026-10-05 owner-deleted
C114 deleted 2026-10-05 owner-deleted
C115 deleted 2026-10-05 owner-deleted
C122 deleted 2026-10-05 owner-deleted
C124 deleted 2026-10-05 owner-deleted
C125 deleted 2026-10-05 owner-deleted
C127 deleted 2026-10-05 owner-deleted
C128 deleted 2026-10-05 owner-deleted
C129 deleted 2026-10-05 owner-deleted
C130 deleted 2026-10-05 owner-deleted
C131 deleted 2026-10-05 owner-deleted
C132 deleted 2026-10-05 owner-deleted
C133 deleted 2026-10-05 owner-deleted
C134 deleted 2026-10-05 owner-deleted
C135 deleted 2026-10-05 owner-deleted
C136 deleted 2026-10-05 owner-deleted
C137 deleted 2026-10-05 owner-deleted
C138 deleted 2026-10-05 owner-deleted
C159 deleted 2026-10-05 owner-deleted
C160 deleted 2026-10-05 owner-deleted
C158 deleted 2026-10-05 owner-deleted
C157 deleted 2026-10-05 owner-deleted
C156 deleted 2026-10-05 owner-deleted
C155 deleted 2026-10-05 owner-deleted
C154 deleted 2026-10-05 owner-deleted
C153 deleted 2026-10-05 owner-deleted
C152 deleted 2026-10-05 owner-deleted
C151 deleted 2026-10-05 owner-deleted
C150 deleted 2026-10-05 owner-deleted
C149 deleted 2026-10-05 owner-deleted
C148 deleted 2026-10-05 owner-deleted
C147 deleted 2026-10-05 owner-deleted
C146 deleted 2026-10-05 owner-deleted
C145 deleted 2026-10-05 owner-deleted
C144 deleted 2026-10-05 owner-deleted
C143 deleted 2026-10-05 owner-deleted
C142 deleted 2026-10-05 owner-deleted
C141 deleted 2026-10-05 owner-deleted
C140 deleted 2026-10-05 owner-deleted
C139 deleted 2026-10-05 owner-deleted
C162 deleted 2026-10-05 owner-deleted
C161 deleted 2026-10-05 owner-deleted
C163 deleted 2026-10-05 owner-deleted
C164 deleted 2026-10-05 owner-deleted
C165 deleted 2026-10-05 owner-deleted
C166 deleted 2026-10-05 owner-deleted
C167 deleted 2026-10-05 owner-deleted
C168 deleted 2026-10-05 owner-deleted
C169 deleted 2026-10-05 owner-deleted
C170 deleted 2026-10-05 owner-deleted
C171 deleted 2026-10-05 owner-deleted
C172 deleted 2026-10-05 owner-deleted
C173 deleted 2026-10-05 owner-deleted
C174 deleted 2026-10-05 owner-deleted
C175 deleted 2026-10-05 owner-deleted
C176 deleted 2026-10-05 owner-deleted
C177 deleted 2026-10-05 owner-deleted
C178 deleted 2026-10-05 owner-deleted
C179 deleted 2026-10-05 owner-deleted
C180 deleted 2026-10-05 owner-deleted
C181 deleted 2026-10-05 owner-deleted
C182 deleted 2026-10-05 owner-deleted
C183 deleted 2026-10-05 owner-deleted
C184 deleted 2026-10-05 owner-deleted
C185 deleted 2026-10-05 owner-deleted
C186 deleted 2026-10-05 owner-deleted
C187 deleted 2026-10-05 owner-deleted
C188 deleted 2026-10-05 owner-deleted
C189 deleted 2026-10-05 owner-deleted
C190 deleted 2026-10-05 owner-deleted
C191 deleted 2026-10-05 owner-deleted
C192 deleted 2026-10-05 owner-deleted
C193 deleted 2026-10-05 owner-deleted
C194 deleted 2026-10-05 owner-deleted
C195 deleted 2026-10-05 owner-deleted
C196 deleted 2026-10-05 owner-deleted
C197 deleted 2026-10-05 owner-deleted
C198 deleted 2026-10-05 owner-deleted
C199 deleted 2026-10-05 owner-deleted
C200 deleted 2026-10-05 owner-deleted
C62 added 2026-10-05 owner-created On the correction board (/queue), when the board has no rows at all, show a friendly empty state instead of an empty table: a centered message 'No corrections on the board — add one with + new correction.' Done = opening /queue with an empty board shows that message and no empty table.
C62 deleted 2026-10-05 owner-deleted
C62 added 2026-10-05 owner-created nothing happens on uploading slip image
C63 added 2026-10-05 owner-created in new correction, mention to submit url and not route. remove the priority field completely
C64 added 2026-10-05 owner-created always use deepseek v4.1 flash with opencode go as provider for everything
C65 added 2026-10-05 owner-created skip any UI tests for now, as they take insane amount of time. only perform them when absolutely necessary
C64 done 2026-10-05 row-watch default model -> opencode-go/deepseek-v4.1-flash
C65 done 2026-10-05 row-watch worker no longer forced to run bun run screens (UI proof) unless essential
C66 added 2026-10-05 owner-created UI tests should be done, only if there's no other option
C67 added 2026-10-05 owner-created uploading file for llm inference seems to take forever. use deepseek v4.1 flash through opencode provider
C68 added 2026-10-06 owner-created i feel in the sidebar — Orders / Trading SO / Job Work SO / Production Order — are properly not segregated. also, on each of those pages, UI is extremely difficult to comprehend
C69 added 2026-10-06 owner-created in sidebar — Orders / Trading SO / Job Work SO / Production Order — looks confusing. opening each page show extremely similar and unimportant infos
C70 added 2026-10-06 owner-created in sidebar, there is orders, and below it there are three types of orders. if, those 3 orders are again shown combined in orders, then orders can go away for better overall clarity
C71 added 2026-10-06 owner-created new orders section in sidebar is stupid. remove it completely
C72 added 2026-10-06 owner-created in sidebar, all orders need to be separated
C73 added 2026-10-06 owner-created remove all orders from sidebar. also, each type of order is showing New Trading SO instead of the respective order type creation
C74 added 2026-10-06 owner-created ok c73, i meant to only remove 'all orders'
C75 added 2026-10-06 owner-created kind column in each of the order pages can go away now
C76 added 2026-10-06 owner-created https://trading.tynolabs.com/bookings looks chaotic on a smartphone
C77 added 2026-10-06 owner-created https://trading.tynolabs.com/guard also looks chaotic on a smartphone
C78 added 2026-10-06 owner-created seems like build and deploy its running after each correction is completed. instead, run it once only after all corrections are completed. this will drastically improve our development speed
C79 added 2026-10-06 owner-created SIZING TIPPAN SHOULD ASK FOR PRODUCTION ORDER/TRADING SALE ORDER IN THE WIZAARD AND ALSO THE FIELD HAS TO BE THERE. COMPULSORY FILL BEFORE ANY OTHER FIELD IS ALLOWED TO BE FILLED. RELEVANT FIELDS TO BE FILLED FROM THE ORDER SELECTED
C80 added 2026-10-06 owner-created "We have zero real DOM tests. The 363 'source-text pin' tests checking {#if}/bind:value/disabled={...} as strings don't prove the UI works — they prove the code exists. Before writing or fixing any more forms:
Install @testing-library/svelte + vitest (or happy-dom) as a DOM test harness.
For the form I'm currently working on, convert its source-pin tests into real rendered tests — mount the component, assert on what's actually in the DOM, simulate clicks/input and check the result.
Going forward, any bug involving field visibility, enabling/disabling, or interactivity gets a real rendered DOM test as part of the fix — not a source-text pin. A source-pin test does not count as 'covered' for UI bugs.
Before telling me something is fixed, run the full suite (not just the touched file) and show me pass/fail counts, plus confirm whether a new rendered test was added for this specific bug."
C81 added 2026-10-06 owner-created in sizing tippan production order - do not show job work order in the list, also do not show by order number but quality and party, the user can also select multiple orders i.e. tippan issued for partial warp filling of multiple orders
C82 added 2026-10-06 owner-created yarn assignment field in sizing tippan - assign yarn from booking(against which no gatepasses/direct delivery intimation is received)/gatepasses (not picked up yet)/direct delivery intimation (not receievd yet), available stock to the tippan.
C83 added 2026-10-06 owner-created the yarn assignment could be partial. give an sub-field of no. of bags, loose cones and consequent weight (auto calculated) once yarn is assigned
C84 added 2026-10-06 owner-created the yarn can be chosed to be assigned later. the the assign later tab use this yarn assignment instead of gatepass given now
C85 added 2026-10-06 owner-created The sizing form UI is mess. Make it proper. Also yarn has to be assigned at the time of tippan creation and is a compulsory field. Do not keep it for later. For beams - the beams can be either our own or against job work outsourcing contract. No of beams to be specified along with mtr whether own or outsourced per beam individually at the time of tippan creation. But job work contract itself can be assigned later.
C111 added 2026-10-12 owner-created remove the horizontal scroll of tap chips from the gatepass creation screen which shows all the types of gatepasses. there is no commonality between the gatepasses and they should not be considered as types
C112 added 2026-10-12 owner-created queue direct delivery intimation should only require 4 fields direct delivery
select booking - Booking number + Yarn (Count+Type+mill name) + Trader + Rate
no of bags to be received - (the pop up should show Yarn name - Count+Type+Mill Name (fetched from booking)
Total Bags booked (fetched from booking), Already received bags date wise (auto fetched)) - suggestions from previous direct delivery bags received for the same yarn
location - factory premise/sizings (from masters)
expected date of delivery
C113 added 2026-10-12 owner-created for G0 (yarn in). Fields required: (1) OCR of gatepass + image storage of the same; (2) yarn booking / job-work number - booking number + Yarn (Count + Type + mill name for a yarn booking; Count + Type for job work) + Trader (yarn booking only) + Rate (yarn booking only); no of bags to be received (popup: Yarn name - Count+Type+Mill name, Total Bags booked (yarn booking) / to be received (job work), Already received bags date-wise, plus suggestions from previous direct-delivery bags for the same yarn); (3) Location of pickup (from godown master). After OCR the yarn booking field is compulsory before any other field.
C114 added 2026-10-12 owner-created Saves automatically after last field filled in wizard. Does not take to main for and save button
C115 added 2026-10-12 owner-created The background form does not show only those fields as specified. It has more fields. Correct that
C116 added 2026-10-12 owner-created Previous direct delivery records not needed in the new form button
C117 added 2026-10-13 owner-created Direct delivery form (G0b): once a direct delivery intimation is created, it must be shareable to the drop location (the sizing / premises target party) as a WhatsApp share link carrying the existing no-login confirmation link (/c/gp/). Reuse the WhatsAppLink component (wa.me deep link, no Business API) so the creator can send it straight from the direct delivery form or immediately after saving. The recipient opens the link with no login and uploads an acknowledgement (photo/file) plus free-text remarks, then confirms receipt; the acknowledgement file and remarks are recorded append-only on the gatepass (event + uploaded file) and move the intimation through delivered -> confirmed. The written remarks and the uploaded acknowledgement must be viewable on the gatepass record afterwards.
C118 added 2026-10-13 owner-created Direct delivery form (G0b): the status must have ONLY TWO states - 'Drop pending' and 'Drop completed'. A newly created direct delivery intimation is created as 'Drop pending'; when the receiver acknowledges it via the shared link (C117) it becomes 'Drop completed'. No other statuses (intimated / due / partial / picked / delivered / confirmed / reconciled) should show for this kind, on the form, the record or the list.
C119 added 2026-10-13 owner-created Direct delivery with drop location = factory premises (our own premises): the inbound intimation must appear in the guard login as 'to be received'. When the guard marks the boxes as received, yarn inward happens automatically (the lot/inward is created from the gatepass via createLotsFromGatepass) and the status moves to 'Drop completed' (C118) - no acknowledgement copy is needed in this internal-premises case (the C117 WhatsApp/external link is only for the named-sizer/other-party drop). Reuse the existing guard receipt action, not a new screen. The guard, while acknowledging any receipt, must enter the vehicle number and a driver photo - only those two are needed, as usual.
C120 added 2026-10-13 owner-created Direct delivery form (G0b): when the yarn booking is selected, show the yarn identity (count + type + mill name) as an AUTO read-only field derived from the picked booking. When it is a job work (job-work number, no yarn booking), the user must select count, type and mill name themselves, and those three must appear as wizard steps - ONLY in the job-work case, never for a yarn booking.
C121 added 2026-10-13 owner-created Direct delivery form (G0b): rename the 'GP no (Auto)' field to 'Direct delivery no' and move it to the TOP of the form, immediately after the Kind row.
C122 added 2026-10-13 owner-created Direct delivery form (G0b): move Status to the TOP of the form (after Kind) and show it as a colour-coded tag/badge, NOT as a field row - colour-code the tag by status value.
C124 added 2026-10-13 owner-created Direct delivery form (G0b): where the historic records table is shown on the form, change the header from 'Gatepass' to 'Direct delivery intimation' (the form/page title and the historic-table section heading should both read 'Direct delivery intimation', not 'gatepass').
C125 added 2026-10-13 owner-created Modify the historic table on the gatepasses LIST page (https://trading.tynolabs.com/gatepasses ) - NOT a table in the new-form window. Columns: expected date / delivered date, yarn name (count + type + mill name), trader (for a yarn booking) or job-work party (for job work). Status is shown as a dot: blinking yellow when Drop pending, stable green when Drop completed. Sort the table latest Drop pending first.
C126 added 2026-10-13 owner-created Direct delivery form (G0b): in the historic table, each Drop pending row against a yarn booking gets a Share button that sends the C117 WhatsApp confirmation link to the drop location.
C127 added 2026-10-13 owner-created Direct delivery form (G0b): in the historic table, each Drop completed row gets a 'Take to yarn inward entry' button that opens the yarn inward entry screen, auto-done against that drop (the inward is recorded against the direct delivery intimation it completes).
C128 added 2026-10-13 owner-created Direct delivery entry point: the button must be labelled 'New direct delivery intimation' (not 'New gatepass') and must open the direct delivery form directly (/gatepasses/new?kind=DIRECT) instead of showing the dropdown list of the eight gatepass types. The direct delivery form's own title/heading should also read 'New direct delivery intimation', not 'New gatepass'.
C129 added 2026-10-13 owner-created Gatepass forms must be PER KIND, not common: each gatepass kind (direct delivery, yarn in, yarn out, beam out, beam in, beam repair, beam return, winding) gets its own individual form page, each showing that kind's own historic-records table - instead of the single shared /gatepasses/new?kind= form and one common historic table. Direct delivery's individual page is the first.
C130 added 2026-10-13 owner-created Direct delivery form (G0b): the booking / job-work picker search must find BOTH yarn bookings AND job-work orders (today job work cannot be searched). It must show all bookings and job-work orders that are NOT closed/completed. The search must match on: party name, yarn count, yarn type, mill name, quality name (job work) and trader name.
C131 added 2026-10-13 owner-created Party master (masters/parties): the broker name field is not needed - remove it from the party form.
C1 deleted 2026-10-13 owner-deleted
C2 deleted 2026-10-13 owner-deleted
C3 deleted 2026-10-13 owner-deleted
C4 deleted 2026-10-13 owner-deleted
C5 deleted 2026-10-13 owner-deleted
C6 deleted 2026-10-13 owner-deleted
C7 deleted 2026-10-13 owner-deleted
C8 deleted 2026-10-13 owner-deleted
C9 deleted 2026-10-13 owner-deleted
C10 deleted 2026-10-13 owner-deleted
C11 deleted 2026-10-13 owner-deleted
C12 deleted 2026-10-13 owner-deleted
C13 deleted 2026-10-13 owner-deleted
C15 deleted 2026-10-13 owner-deleted
C16 deleted 2026-10-13 owner-deleted
C17 deleted 2026-10-13 owner-deleted
C18 deleted 2026-10-13 owner-deleted
C19 deleted 2026-10-13 owner-deleted
C20 deleted 2026-10-13 owner-deleted
C62 deleted 2026-10-13 owner-deleted
C63 deleted 2026-10-13 owner-deleted
C64 deleted 2026-10-13 owner-deleted
C65 deleted 2026-10-13 owner-deleted
C66 deleted 2026-10-13 owner-deleted
C67 deleted 2026-10-13 owner-deleted
C68 deleted 2026-10-13 owner-deleted
C69 deleted 2026-10-13 owner-deleted
C70 deleted 2026-10-13 owner-deleted
C71 deleted 2026-10-13 owner-deleted
C72 deleted 2026-10-13 owner-deleted
C73 deleted 2026-10-13 owner-deleted
C74 deleted 2026-10-13 owner-deleted
C75 deleted 2026-10-13 owner-deleted
C76 deleted 2026-10-13 owner-deleted
C77 deleted 2026-10-13 owner-deleted
C78 deleted 2026-10-13 owner-deleted
C79 deleted 2026-10-13 owner-deleted
C80 deleted 2026-10-13 owner-deleted
C81 deleted 2026-10-13 owner-deleted
C82 deleted 2026-10-13 owner-deleted
C83 deleted 2026-10-13 owner-deleted
C84 deleted 2026-10-13 owner-deleted
C85 deleted 2026-10-13 owner-deleted
C111 deleted 2026-10-13 owner-deleted
C112 deleted 2026-10-13 owner-deleted
C113 deleted 2026-10-13 owner-deleted
C114 deleted 2026-10-13 owner-deleted
C115 deleted 2026-10-13 owner-deleted
C116 deleted 2026-10-13 owner-deleted
C117 deleted 2026-10-13 owner-deleted
C118 deleted 2026-10-13 owner-deleted
C119 deleted 2026-10-13 owner-deleted
C120 deleted 2026-10-13 owner-deleted
C121 deleted 2026-10-13 owner-deleted
C122 deleted 2026-10-13 owner-deleted
C124 deleted 2026-10-13 owner-deleted
C125 deleted 2026-10-13 owner-deleted
C126 deleted 2026-10-13 owner-deleted
C127 deleted 2026-10-13 owner-deleted
C128 deleted 2026-10-13 owner-deleted
C129 deleted 2026-10-13 owner-deleted
C130 deleted 2026-10-13 owner-deleted
C132 added 2026-10-13 owner-created remove opening balance field
C133 added 2026-10-13 owner-created remove due days field
C134 added 2026-10-13 owner-created for mobile number and email id put relevant validation rules
C135 added 2026-10-13 owner-created add "Godown" in Category
C136 added 2026-10-13 owner-created Add country code selection list to mobile number
C137 added 2026-10-13 owner-created remove phone number field
C138 added 2026-10-13 owner-created add field "MSME (Udyam Aadhar)"number
C139 added 2026-10-13 owner-created remove the old unit toggle
C140 added 2026-10-13 owner-created put relevant field validation rules for PAN card and GSTIN
C141 added 2026-10-13 owner-created remove amend button after edit. Cancel and save should appear side by side. correction remark field should appear alongside other fields
C142 added 2026-10-13 owner-created REMOVE SUGGEST BUTTON IN ACRONYM
C143 added 2026-10-13 owner-created remove the whole rates and rolls section from the design master
C144 added 2026-10-13 owner-created weft wastage as 5% prefilled by default in any new record
C145 added 2026-10-13 owner-created warp and weft need a grid (due to multiple warp and weft if there in a quality). Columns: 1. Sr No. 2. Count 3. Unit 4. % 5. Permissible counts (multiple selection of permissible counts for e.g. 61 count inward is permissible against quality of 60 count). ask questions if the query is not clear
C146 added 2026-10-13 owner-created remove Warp rows — multi-warp (JSON, optional) and Weft rows — multi-weft (JSON, optional) fields
C147 added 2026-10-13 owner-created quality name and alias at the top. quality name to be derived from all other fields. Not manual
C148 added 2026-10-13 owner-created remove PPI field. In the quality name in place of pick write only "Pick"
C149 added 2026-10-13 owner-created remove GSM Target and UTL
C150 added 2026-10-13 owner-created instead of "Denting (ends per dent) — EPI = reed × denting ÷ 2" write only "Denting (ends per dent) — EPI = reed × denting ÷ 2"
C151 added 2026-10-13 owner-created Remove yarn counts section since we have already made grid
C152 added 2026-10-13 owner-created In the warp and weft grid, count comes from yarn master so drop down, percentage cannot be seen as typed the field is small (total of % to be 100%), auto divide 100% and prefill when a new row is added for e.g. for 2 warp rows the prefilled percentage is 50% for each, permissible count from yarn master to be shown as coin tags in the field as many selected.
C153 added 2026-10-13 owner-created Remove (104) in the label of L2L
C154 added 2026-10-13 owner-created Remove shifts field
C155 added 2026-10-13 owner-created Remove open button from the table of all masters. Clicking anywhere on the row should open the record
C156 added 2026-10-14 owner-created The warp and weft grid is not user friendly on phone. Revised the UI to suit a mobile screen in design master warp and weft grid
C157 added 2026-10-14 owner-created In the warp and weft grid permissible count drop down has to be searchable
C158 added 2026-10-14 owner-created Remove mode from design master
C159 added 2026-10-15 owner-created migrate to sveltekit 3
C160 added 2026-10-17 owner-created in design master, weave should be selected from the drop down coming from weave master. weave master need not be shown seperately but a sub-master of design master updated from the entries made in design master. a new weave can be typed straight into the weave field and it should get added to the weave master and to be shown in the drop down from next entry. also no duplicate weaves allowed. values should be unique, not case sensitive
C161 added 2026-10-17 owner-created new trading SO button showing 500 error
C162 added 2026-10-17 owner-created for warp and weft reed space, prefill the field by the last used RS for the quality in the quality field
C163 added 2026-10-17 owner-created for job work field, prefill the field by the last used job work for the quality in the quality field
C164 added 2026-10-17 owner-created warp sizing rate should prefill from the yarn master
C165 added 2026-10-17 owner-created for quality with multiple warp or weft, the second warp and weft fields are not appearing. correct that
C166 added 2026-10-17 owner-created remove sizing GST field
C167 added 2026-10-17 owner-created Remove mill/ticket
C168 added 2026-10-17 owner-created Create a new master of ticket/mill..to get h tickets/mill whenever called for...the entries in this master comes from rate board. If there is a new mill in the rate board, it auto enters this master. Accordingly whenever yarn (count+type+mill/ticket) is fetched, it shows all permutations of yarn and mills
C169 added 2026-10-17 owner-created The weave field is not showing a searchable drop down. Also weave master is not showing up in the masters
C170 added 2026-10-18 owner-created we must deliver in field is not opening up pop up for data entry
C171 added 2026-10-18 owner-created when mumbai dhara is selected brokerage is to be prefilled as 1% and for ahmedabad dhara 2%
C172 added 2026-10-18 owner-created brokerage should have slot scroll entry with suggestion coins of 1%, 2%
C173 added 2026-10-18 owner-created brokerage pass on should have suggestion coins 0.5%, 2% and should have slot scroll entry with per scroll change of 0.25%
C174 added 2026-10-18 owner-created order operations page shwing 500
C175 added 2026-10-18 owner-created we must deliver in field should have start date and end date. both showing suggestions of ready (which when tapped on selects today's date, +2 days, +7days, +15days, +30 days. +40 days and +/- button to add/less one date to selected date.
C176 added 2026-10-18 owner-created add button in mill/ticket master
C177 added 2026-10-18 owner-created add button in weave master
C178 added 2026-10-18 owner-created ANY ITEM IN THE TABLE LEADS TO ERROR 500
C179 added 2026-10-18 owner-created Re-merge the order-operations fields into the Trading SO form: the sales person may NON-COMPULSORILY fill the production/operations fields if he already has the data (including when he uses OCR of the contract copy). Anything he leaves blank is completed later by another (operations) user, append-only, from the operations queue — one field spec, stage-aware requiredness.
C180 added 2026-10-18 owner-created Re-merge the order-operations fields into the Job Work SO form: the sales person may NON-COMPULSORILY fill the production/operations fields if he already has the data (including when he uses OCR of the contract copy). Anything he leaves blank is completed later by another (operations) user, append-only, from the operations queue — one field spec, stage-aware requiredness.
C181 added 2026-10-18 owner-created Re-merge the order-operations fields into the Stock (Production) order form: the sales person may NON-COMPULSORILY fill the production/operations fields if he already has the data (including when he uses OCR of the contract copy). Anything he leaves blank is completed later by another (operations) user, append-only, from the operations queue — one field spec, stage-aware requiredness.
C182 added 2026-10-18 owner-created IN NEW JOB WORK ORDER ASK LOOM WIDTH AND PANNA FIRST IN THE WIZARD AND THE FORM
C183 added 2026-10-18 owner-created PAYMENT DHARA PREFILL FROM THE LAST USED OF THE PARTY. iF NONE, THEN ASK PAYMENT DHARA IN THE WIZRAD. OTHERIWSE PREFILL AND DO NOT ASK
C184 added 2026-10-18 owner-created PAYMENT DHARA FIELD KEEP IN THE END
C185 added 2026-10-18 owner-created WARP AND WEFT COST AND WEIGHT IN THE SECOND PAGE OF COSTING FORM SHOULD BE SHOWN FOR EACH WARP AND WEFT INCASE THERE ARE MULTIPLE
C186 added 2026-10-18 owner-created SHOW SCROLL ENTRY FOR ESTIMATED MTR WITH EACH STEP AS 1000 MTR AND SHOW SUGGESTION COINTS FROM PREVIOUS SALE ORDERS OF THE SAME QUALITY
C187 added 2026-10-18 owner-created DELIVERY END SHOW SUGGESTION COINS OF +10 DAYS, +20 DAYS, +30 DAYS, +40 DAYS, +
C188 added 2026-10-18 owner-created Orders list shows test-fixture order numbers like SO-C135-1791194656869 and SO-C111-1791195431185. These are leftover fixture rows the removed test suite inserted directly into the shared data.db (tests/c111, c135, c154 built orderNo as SO-C-Date.now()); the app's real number is makeDocNo = SO-YYMMDD-XXXX. Purge the fixture orders from data.db so the live list shows only real orders.
C189 added 2026-10-18 owner-created use official deepseek v4.1 flash for any llm (both text and vision) related stuff inside trading.tynolabs.com
use the following api key
sk-e59ab23552c44f4a8e0a9f875500314a
C190 added 2026-10-18 owner-created IN SAMPLE FORM RATE IS A SINGLE SCROLL WITH 0.25 INCREMENTS, NOT DUAL ONE FOR RUPEES AND ONE FOR DECIMAL. ALSO SHOW SUGGESTION COING BASED ON LAST RATE USED FOR THE QUALITY FROM ORDERS.
C191 added 2026-10-18 owner-created CHARGE/WAIVE SHOULD BE EITHER OR OPTION OF A SINGLE FORM. ONLY IF CHARGE IS SELECTED, RATE SHOULD BE ASKED. THIS FIELD SHOULD BE A PART OF WIZARD BEFORE RATE
C192 added 2026-10-18 owner-created REMOVE PURPOSE FIELD
C193 added 2026-10-18 owner-created EVERY SAMPLE HAS A AUTO ENTRY NUMBER LIKE ANY OTHER FORM. THIS NEED NOT BE A FIELD AND CAN BE SHOWN AT THE TOP OF THE FORM
C194 added 2026-10-18 owner-created REMOVE HISHOB AND ORDERS FROM ORDERS SECTION IN THE NAVIGATION PANE,THESE ARE REPORT
C195 added 2026-10-18 owner-created IN NEW BOOKING WHEN SELECTING A PRODUCTION ORDER, IT SHOULD SHOW A GRID SHOWING WARP/WEFT, YARN (cOUN+tYPE), ALREADY ASSIGNED (SHOWS THE TOTAL KGS OF YARN ALREADY ASSIGNED FOR THAT ROW - EXPANDABLE TO SEE THE DATE AND TICKET WHICH WAS PROCURED). tHE USER SHOULD ALSO BE ABLE TO SELECT MULTIPLE PRODUCTION ORDER IN WHICH CASE HOW MANY BAGS TO BE ASSIGNED TO WHICH ORDER HAS TO BE ASKED IN THE QTY FIELD
C196 added 2026-10-18 owner-created CONES PER BAG AND BAG WT. HAVE TO BE PREFILLED FROM LAST ENTRY OF THE SAME YARN (COUNT+TYPE+MILL)
C197 added 2026-10-18 owner-created RATE HAS TO BE A SINGLE SCROLL WITH INCREMENTS OF 0.25. SUGGESTION COING OF THE LAST USED FOR FOR THE YARN (COUNT+TYPE+MILL) AND ALSO THE RATE BOARD OF THAT DAY. oNCE SELECTED FROM SUGGESTIONS THE USER CAN ALSO THEN MOVE THE SCROLL TO ADJUST THE RATE. dO NOT IMMEDIATELY TAKE TO THE NEXT WIZARD BY JUST TAPPING ON A SUGGESTION. TAKE TO THE NEXT FIELD ONLY WHEN CLICKED ON NEXT IN THIS CASE
C198 added 2026-10-18 owner-created Reorder fields
System order no., buyer order no., booking date, system date at the top
System order no. And system date need not be shown as fields since they are auto
Then quote/lead. Single field. Not multiple
Then broker, buyer, quality and rate
Then qty and delivery
Then terms and papers except rate and yarn booking allocation.
Then remarks.
Then yarn booking allocation
C199 added 2026-10-18 owner-created Reorder fields for job work order
System order and system date (not shows as fields since auto)
Buyer order number, booking date
Loom width (only one field, form showing 2 fields) and no. If panna
Then broker, buyer, quality, picks, job rate
Then qty and delivery terms except city. Remove the city field
Then other terms
Remove sales promise field, broker/weaver confirmation,
C200 added 2026-10-18 owner-created Link a capture draft field is unresponsive. Allow to upload if not already done so in ocr
C201 added 2026-10-18 owner-created add a field of own firm name, to be selected from own party type of party master
C202 added 2026-10-18 owner-created when reusing a quote, the calculate button does not get active
C203 added 2026-10-18 owner-created L2L should be prefilled from the last used for the same quality. Suggestion coing should show the last actual L2L for the order of that quality which was finished
C204 added 2026-10-18 owner-created job rate should be fetched from the last job rate for teh same quality in the job work order/outsourced job work contract or last quote. suggestion coings should have that. In case there is nothing to pre-ill show the field in the wizard. same for L2L, in case there is nothing to pre-fill, show the field inthe wizard.
C206 added 2026-10-18 owner-created While entering buyer name in job work order or so trading or outsourcing order if the party is not there in the master, it should show an option of creating new in the drop down itself which opens the party master pop up where the user can enter the party and close and the wizard resumes back with the newly entered party. Same for broker
C207 added 2026-10-18 owner-created rate should be a single croll with 0.25 increments. also suggestions from rate board or last used rate for that yarn (count+type+mill)
C208 added 2026-10-18 owner-created gst % not needed
C209 added 2026-10-18 owner-created Booking no. system generated) and system date to be shown on top, trader's booking number as the first field along with booking date
C210 added 2026-10-18 owner-created reorder fields
booking number (trader's), booking date
broker and trader
product (count+type+mill)
bags and cones and wt. per bag
Rate (along with toggle of including/excluding GS
lot no., payment terms, delivery period, remark
chande delivery date field to delivery date with start date, interval period and no. of bags per interval
C211 added 2026-10-18 owner-created create a guard login
C212 added 2026-10-18 owner-created while selecting yarn booking clicking on the field should open the table of yarn bookings with (pending status i.e. booking against which deliveries are not yet fully received) and the user can select from the table. This would be better than a drop down
C213 added 2026-10-18 owner-created Status if auto. A field for that is not required. It can be shown in the table and while opening an existing inward
C214 added 2026-10-18 owner-created need OCR recognition field for uploading teh gatepass received. Also a upload document field where this gatepass is saved. Along with a dictation field.
C215 added 2026-10-18 owner-created Change the form name to Yarn Inward Intimation
C216 added 2026-10-18 owner-created yarn inward intimation number and systemd ate on the top
C217 added 2026-10-18 owner-created reorder
Booking number
Yarn (Count+Type+mill) prefilled from booking
GP No.
Location of pick up (from godwon master)
Bags to be received with suggestions based on previous bags received of the same product
remarks
C218 added 2026-10-18 owner-created remove kind. it is a standalonw form for yarn inward
C219 added 2026-10-18 owner-created Waive amount not needed. Waive would mean complete waive
C220 added 2026-10-18 owner-created Remove rate source
C221 added 2026-10-18 owner-created Remove from context complete section
C222 added 2026-10-18 owner-created In The rate scroll I am not able to type properly. The last digit doesnt get erased with backspace
C223 added 2026-10-18 owner-created In case broker not selected mark broker as direct while saving and prefill brokerage as 1 and pass on field as 1
C224 added 2026-10-18 owner-created The reuse button open edit form. It should just open a new form with the fields prefilled
C225 added 2026-10-18 owner-created For the sales user following fields are compulsory for saving
Buyer
Quality
Rate
Picks
Quantity
We must delivery in days
Payment dhara
Cd
Brokerage %
Pass on %
For production user the following fields are compulsory for the entry made by the sales user
Buyer order no
Send as
Mtr per roll
Rolls
C226 added 2026-10-18 owner-created Remove fields sales promise
Send to city
Move we must delivery in days at the place of sales promise
C227 added 2026-10-18 owner-created Booking no. Field after ocr in wizard
C228 added 2026-10-19 owner-created rate scroll increments of 0.25
C229 added 2026-10-19 owner-created rate field 2 decimal points
C230 added 2026-10-19 owner-created how many picks scroll of 1 increment. suggestions using past orders of the same quality + Party
C231 added 2026-10-19 owner-created lead/quote picker to be one field only. Either or. Also the picker not as a drop down but as the historic table like we did in bookings section SO selection with 2 tabs...one for lead, one for quote. Show only those leads whose quotes are not generated and have not expired. Show only those quotes whose SO is not generated and is not expired
C232 added 2026-10-19 owner-created remove the quote/lead picker from the OCR wizard screen and put it in the next screen. In case the OCr is provided for the SO and quote too, fields are to be prefilled from the OCr not the quote. at that time quote is just linked ot the SO. Other times quote also prefills fields
C233 added 2026-10-19 owner-created in brokerage use +/- button instead of scroll. With increment of 0.25
C234 added 2026-10-19 owner-created pass on to buyer use +/- button with 0.25 change instead of scroll
C235 added 2026-10-19 owner-created Orders list: tapping a record opens the record popup, but it has no cancel action (only the full record page's Delete does). Add a Cancel button to the record popup with a cancellation-remarks field, recording the cancellation append-only via /api/amend kind 'delete' with owner approval — the order is flagged cancelled, never erased, and stays openable with its history.
C236 added 2026-10-19 owner-created Production order (Stock) staged entry between sales and production. SALES must fill (compulsory, cannot save without): booking date; quote/lead selection (if applicable); buyer; broker; quality; rate; picks; quantity; payment dhara; cash discount; we must deliver in days; brokerage; pass on. Sales may also fill the remaining fields, but those stay optional for sales. If no quote/lead was selected and the sales user has filled the fields manually, the quote/lead picker must not allow a selection (it would conflict with the manually entered values). The sales entries then appear in the production user's to-dos and production must compulsorily fill: send as; mtr./roll or lump; no. of rolls/lumps; buyer PO no. All other fields remain optional. Enforce the split server-side and client-side (same field spec, role-aware requiredness), append-only as usual.
C237 added 2026-10-19 owner-created show send as field options (rolls/lumps) as two radio button rather than drop down
C238 added 2026-10-19 owner-created change the name of rolls field to rolls/lumps
C239 added 2026-10-19 owner-created for "How many picks" field show suggestion coins based on last pick for the same quality
C240 added 2026-10-19 owner-created show party and quality alias instead of quality and party in the table
C241 added 2026-10-19 owner-created need booking date as first column in the table
C242 added 2026-10-19 owner-created progress and status have to be short in the table. very long tests lead to long horizontal scroll on phone. make those concise
C243 added 2026-10-19 owner-created put the open details button within the pop up and remove from the horizontal scroll
C244 added 2026-10-19 owner-created the quote lead picker should open the table in a pop up with two tabs for leads and quotes. also it is not showing any lead or quotein the table whereas there are many leads and quotes opne. troubvleshoot that too
C245 added 2026-10-19 owner-created picks field to change by 1 with +/- button. Right now it is changing by 100. Also it is not showing any suggestion coins based on previous SO of the same quality. correct that
C246 added 2026-10-19 owner-created type and class of looms are not shown as seperate masters. If they are not masters yet, make them.
C247 added 2026-10-19 owner-created create a loom type master with columns as width (190 cm, 250 cm), loom type (Airjet, Rapier) and link this master to loom master rather than individual class and type field.
C248 added 2026-10-19 owner-created fro panna prefill it based on last used for loom type + quality.
C249 added 2026-10-19 owner-created loom type field drop down take from new created loom type master
C250 added 2026-10-19 owner-created Orders list production-stage marking and role actions: mark every order whose production/operations details are still incomplete with a secondary status (a second status chip beside the workflow status, derived from the same pending-ops field check so nothing stored can drift). For the production role, hide the New order button and instead give every pending row a Fill details button that opens that order directly in the production entry wizard, prefilled by order.
C251 added 2026-10-19 owner-created Order entry wizard, role-scoped fields: the sales user sees only his compulsory sales fields in the wizard and the production user only the production fields; one field spec with role-aware visibility and requiredness, enforced server-side and client-side. Covers the Trading SO, Job Work SO and Stock (Production) order new/view flows. Hidden fields keep any value already carried on the order; saving stays append-only.
C252 added 2026-10-19 owner-created Production entry wizard, role-scoped fields across all four production screens (trading, job-commercial, job-details, production-order): the production user sees only his own fields and the sales user only his; one field spec with role-aware visibility and requiredness, enforced server-side and client-side, append-only.
C253 added 2026-10-19 owner-created rate per meter is auto calculated in job work order and need not be in the wizard. Rate per meter = Job rate per pick*picks/100
C254 added 2026-10-19 owner-created switch the positions of job rate per pick and rate per mtr in the form
C255 added 2026-10-19 owner-created take "Beams:Whose?" field at the end in terms
C256 added 2026-10-19 owner-created show booking date, Then order no., Quality palias, Party alias, Mtr/beam, job rate, Status in this order
C257 added 2026-10-19 owner-created enable chat with party and share order button in job work order
C258 added 2026-10-19 owner-created remove book yarn button for job work order
C259 added 2026-10-19 owner-created remove new tippan button for job work order
C260 added 2026-10-19 owner-created picks field give +/- button with change of 1. Show suggestions based on picks of the same quality last used
C261 added 2026-10-19 owner-created Job work form is showing trading draft. Correct that
C262 added 2026-10-19 owner-created job rate per pick suggestions from previous used for same quality. give +/- button with change of 0.25
C263 added 2026-10-19 owner-created mtr/beam field make the active scroll as editable. Right now a seperate editable text box is shown for manual entry. correct it
C264 added 2026-10-19 owner-created All 4 order forms should show only their draft entries respectively. not each other's
C265 added 2026-10-19 owner-created remove efficiency linked rate, additional unconditional rate, weaver liability clause, delivery gatepass leg
C266 added 2026-10-19 owner-created shift Beam:Whose? to the end of terms
C267 added 2026-10-19 owner-created make outsourced form UI same as job work order form. Except instead of buyer's order no. it will be weaver;s order no.
C268 added 2026-10-19 owner-created remove brokerage
C269 added 2026-10-19 owner-created remove buyer, rate, send to city, all terms and papers fields (except yarn allocation and remarks)
C270 added 2026-10-19 owner-created remove quote, lead, broker, buyer order no., booking date
C271 added 2026-10-19 owner-created remove panna from wizard
C272 added 2026-10-19 owner-created remove loom class master. only one master of loom type is enough. In loom type width (in cm) has to be typable and not drop down
C273 added 2026-10-19 owner-created OCR and dictation field add in the wizard first pop up
C274 added 2026-10-19 owner-created put start wizard button
C275 added 2026-10-19 owner-created make delivery start date, delivery end date , delivery interval and bags per interval part of the same focus entry pop up . For delivery interval give suggestion coins of 3 days, 5 days, 7 days, 10 days. +/- button with change of 1 day. Total Bags divide based on no. of intervas and delivery period and let the user modify with plus or minus button with 1 bags change
C276 added 2026-10-19 owner-created Trader/supplier from party master - type supplier. If the entered supplier is not there in the master give an option in the drop down to add new record in the party master clicking on which opens the master in a new pop up and when saved the field pop up gets populated by that value
C277 added 2026-10-19 owner-created Add new broker option in broker drop down which opens party master in pop up.
C278 added 2026-10-19 owner-created Add yarn option in yarn drop down. This should open yarn master in pop ups over the field pop up for new yarn creation
C279 added 2026-10-19 owner-created Divide the yarn field into two fields
Yarn count and type (from yarn master)
Mill/ticket (from mill master.
Both drop down should have an option of creation of new which opens the master for new creation right there in a new pop up
C280 added 2026-10-19 owner-created Switch rate per mtr and job rate fields position in the form
C281 added 2026-10-19 owner-created The table of job work and yarn booking for picking has to be shown in a seperate pop up with tabs for both. UI LIKE quote/lead picker in so form
C282 added 2026-10-19 owner-created Yarn inward intimation number and system date to be shown above the form. Ui like as in booking form
C283 added 2026-10-19 owner-created Add gp no. Field
C284 added 2026-10-19 owner-created Beam scroll start from 1. Right now it is starting from 999
C285 added 2026-10-19 owner-created The table fields are cramped. Make them visible. Horizontal scroll allowed
C286 added 2026-10-20 owner-created improve UI ergonomics
C287 added 2026-10-20 owner-created improve UI ergonomics
C288 added 2026-10-22 owner-created color code of the complete erp is not ergonomic
C289 added 2026-10-22 owner-created we need a smartly designed scrollbar to make user instantly understand layout of dashboard https://trading.tynolabs.com/
C290 added 2026-10-23 owner-created draggable scrollbar on phone?
C291 added 2026-10-23 owner-created current draggable scrollbar in dashboard can hardly be grabbed by a finger. visually it must be very subtle. but, it should match system's scroll
C292 added 2026-10-25 owner-created strictly use daisyUI throughout https://trading.tynolabs.com/ . no other UI libraries should be used unless daisyUI can't do it
C293 added 2026-10-25 owner-created dashboard can be card swipes left and right on phones? current look seems to be too chaotic. decide and implement the best UI for the dashboard
C294 added 2026-10-26 owner-created remove the extra scrollbar in dashboard
C295 added 2026-10-26 owner-created keep only the og scrollbar in dashboard
C296 added 2026-10-27 owner-created UI of https://github.com/skpawar1305/drnanoinc-stores/tree/main/apps/billing is so simple. UI of this website is complication. I think we need strict organizational segregation for the UI, and have minimal options in the sidebar. maintain mobile and desktop first for this website
C297 added 2026-10-27 owner-created readibility and UI ergonomics needs an udpate throughout the website, maybe use cards more so that website can be used by less literate people as well and use icons wherever it feels necessary
C298 added 2026-10-27 owner-created boost lighthouse scores
C299 added 2026-10-27 owner-created dashboard is chaotic
C300 added 2026-10-27 owner-created show wizards or wizard options only if necessary for form filling
C301 added 2026-10-29 owner-created clcicking on new gatepass should not open a drop down of types of gatepasses. it should directly open the new record of the gatepass of which the screen is open
C302 added 2026-10-29 owner-created Add a field of whether the yarn is a warp or a weft. This is a loose link and can change later . I.e. a warp can be used as weft or vice versa later
C303 added 2026-10-29 owner-created for the pop up showing selection from all the order/job work order for which yarn is pending to be received. It is to be calculated as below. Fo SO Tradin and Production Order - Use the formula used in quote form for calculating the warp weight and weft weight (for costing) and use the same formula multiplies by the order mtrs. to calculate the total kgs required for the warp and weft (in case there are multiple warp or weft each requirement to be calculated seperately as in quotes). Note in docs, the formulas for conversion of fabric mtrs to yarn kgs is standard and when called upon should be used as given there. Now the table which shows the ordders for which yarn is pending for selection for yarn inward intimation should show kgs. received till date/kgs to be received (calculated as above).
C303 amended 2026-10-29 owner-created the picker's reference comes from 3 things: 1. SO Trading/productio order (requirement calculated in the above manner, for yarn sourced in ready delivery format) 2. Yarn booking - for yarn booked for future delivery against which delivry is received (total kgs. received/total kgs. booked to be shown) 3. Job work for which weft requirement is to be calculated just like above. Right now only 2 tables for yarn booking and job work are shown - correct that.
C304 added 2026-10-29 owner-created Yarn field is to be auto fetched incase of yarn bookingss. for SO order/production order and job work it is to be filled by the user
C305 added 2026-10-29 owner-created "Gatepass uploads & dictation (you can skip)". Remove this section completely except a field which shows the uploaded ghatepass photo or allows upload
C306 added 2026-10-29 owner-created for OCR detection the wizard pop up like in the New Orders screen
C307 added 2026-10-29 owner-created wizard flow
OCR
Warp/weft
No. of bags
SO/Production order/Booking/Job work order selection
Yarn
Pickup Location
Trader's GP No.
Any field automatically filled by OCR is not to be shown in wizard except 1, 2 and 4 no. points
C308 added 2026-10-29 owner-created Give a button `on top of the screen called "Verify fields". On clicking it the gatepas uploaded is shown on the top 1/3 of the page which the user can zxoom in and out in the same freezed pane while scrolling the rest of the form verifying each field against the actual gatepass photo. Give a small cross on top to close the photo and get back to the original layout of the form
C309 added 2026-10-29 owner-created in the table of the SO/booking/job work/production order for selection...show only one column of kgs pending/kgs required. In case of multiple warp/weft show it count wise in the same column. Multiple selection only allowed in SO/production order (containing records of Trading orders and production orders for which yarn is pending combined) and yarn bookings. for job work only single selection is allowed. Also mutiple selection allowed from SO/Production order table and yarn booking table i.e. a few from each table. But not for job work. For job work if a job work order is selected no other yarn booking or SO order or production order can be selected with it. When multiple are selected, a live grid of order, yarn count, kgs pending and a field equally dividing the total boxes amongst all the orders (but upto a maximum of their pending requirement). with a +/- button to change the no. of boxes by 1 bag, total kgs of the boxes approtioned to the order, further pending kgs of that order/booking
C310 added 2026-10-29 owner-created add mill name back into the yarn master with values from the mill/ticket master
C311 added 2026-10-29 owner-created Add a count master. This is to be linked to the yarn master count field
C312 added 2026-10-29 owner-created Add a Type master. This is to be linked to the yarn master type field
C313 added 2026-10-29 owner-created For SO Trading/Production order/Job work order too the yarn count+type+mill have to be shown as a single field only from the yarn master, not 3 different fields. Same in the wizard
C314 added 2026-10-29 owner-created Add fields of cones and bag weight along with no. of bags. Show this field right after the no. of bags in the wizard. show suggestions based on previous entries of the same yarn
C315 added 2026-10-29 owner-created the gatepass uploaded fro OCR is to be saved in the upload field by default.
C316 added 2026-10-29 owner-created The zoom on the photo after clicking on verify fields button is not happening by pinching in and out and scrolling left and right. It should happen like that. Like we use zoom feature on phones
C317 added 2026-10-29 owner-created Need a button of Start Wizard, Start OCR at the top
C314 doing 2026-10-29 cones + bag weight rows right after the bags on the yarn inward, with this yarn's own previous figures as chips and both validated on form + server
C329 added 2026-10-29 owner-created it is not "Cones in this delivery" but "Cones per bag"
C330 added 2026-10-29 owner-created All fields are compulsory except remarks
C331 added 2026-10-29 owner-created remove the long ass description from all the pages, focus entry pop-ups etc. foe e.g. "Pick the yarn booking / job-work no, the bags to be received and the location of pickup — the trader, the yarn and the rate come from the booking." at the top of the page and "Snap or upload the trader’s gatepass — the AI reads it and fills the yarn count, type, mill and bags; nothing is saved until you check the rows and tap save" on read the OCR gatepass wizard pop up
C341 added 2026-10-29 owner-created upgrade bun version
C342 added 2026-10-29 owner-created DB foundation, one additive migration: yarn.grade (A+/A/B/C/blank); order.role (so/po/fabric_purchase), planned_mtrs, trigger (so/stock), sale_kind (normal/damaged), parent_so_id, frozen_at, unit_cost; lot.quality_key and lot.pick; new cost_leg, cost_apportionment, pool_entry (tracks produced/purchased/yarn/salvage), substitution; dispatch_slip.apportionment_id. All nullable or defaulted with a legacy cost flag; run generate and push on a data.db copy, restore evt index and WAL. No behaviour change, no UI. Gate: typecheck clean and migration applies.
C343 added 2026-10-29 owner-created Costing engine, pure functions only (src/lib/server/costing/): WAC pools (yarn by count+type+grade, fabric produced by quality+pick, purchased by quality+pick, salvage zero-cost), leg freeze and accrual, apportion and release at locked cost, substitute quantity-only, SO P and L from locked apportionments plus salvage roll-up, PO P and L incurred divided by good mtrs, variance. No routes, no UI. Tests: WAC in and out, release at locked cost, shortfall re-price, salvage roll-up, zero-cost isolation. Gate: tests green.
C344 added 2026-10-29 owner-created Yarn pool wiring: yarn-in writes pool_entry in at WAC by count+type+grade; issue to a production order writes pool_entry out at WAC plus a cost_leg yarn row at that WAC; free versus apportioned-to-PO state. DB uses yarn.grade. UI: yarn master adds a grade select with server and client validation; yarn stock shows grade. Tests: issue cost equals WAC at issue and a later purchase changes only future issues.
C345 added 2026-10-29 owner-created Production order lifecycle: create with role po, planned mtrs = SO remaining rounded UP to 100, editable with a confirm prompt, trigger tag; cost legs by kind as rate commitments plus freeze; completion writes good mtrs at unit cost = incurred divided by good mtrs, unassigned output to the produced pool; shortfall shrinks assignment, re-prices the assigned mtrs, opens an exception and a dashboard todo (queue.ts) to apportion the gap; cancellation releases yarn unapportioned, produced fabric to the free pool, no conversion accrual. Backend plus PO record UI. Tests for completion, shortfall, cancellation.
C346 added 2026-10-29 owner-created SO with atomic cost coverage: sale_kind and parent_so_id with validation; one transaction writes the SO, the apportionments (fabric pool at WAC, existing PO output at PO cost, market fabric, new PO shell) and the auto PO; balance must equal the SO quantity exactly, no pending save, no over-coverage; coverage step in the existing order wizard (reuse FocusEntry) showing per-source pick and WAC plus order value and margin. Tests: rollback, round-up, exact balance.
C347 added 2026-10-29 owner-created SO amendment and cancellation: quantity up and down, rate and terms, quality and pick (release at locked cost then full reassignment), cancel (release all, the PO survives unassigned); PO cancel rules; append-only with events and a single rebalance action. Backend api/amend plus orders actions, UI on the SO record. Tests: release at locked cost, quality and pick reassignment, both cancellations.
C348 added 2026-10-29 owner-created Checking and mending grades: add X (absolutely non-usable, zero-cost salvage track, excluded from WAC, only damaged-SO sale) and make R a sellable cost-bearing FG grade; enum and validation on both surfaces; damaged SO marking gates X sales; salvage P and L rolls into the parent SO, else only in the damaged SO P and L. Backend checking route plus pool hook, UI grade buttons. Tests: X never enters produced WAC, R ships, salvage roll-up.
C349 added 2026-10-29 owner-created Market fabric purchase: entry form and commitment (supplier, quality, pick, mtrs, rate per m, freight, GST, date) writing a fabric_purchase order plus one cost_leg; purchased WAC by quality and pick, never blended with produced WAC; assignment to an SO or into the pool. DB, backend, UI form and coverage panel. Tests: separate WAC tracks.
C350 added 2026-10-29 owner-created Stock report: extend reports and lots to show yarn by count+type+grade, fabric by quality+pick+grade, produced versus purchased tracks, own versus party, WIP versus apportioned versus free, locations in-house/sizer/weaver/transit, valued at WAC; add pick, grade and track filters. Backend reports.ts, existing UI only. Test: a seeded scenario reconciles with pool entries.
C351 added 2026-10-29 owner-created Direct delivery to weaver: accept a Weaving-category party as a DIRECT destination (today only premises plus Godown/Sizing), set the stock location to weaver, no WAC change; server and client validation. Backend gatepasses/new and lots, UI location picker. Test: a DIRECT to weaver creates the record and the weaver stock location.
C352 added 2026-10-29 owner-created Yarn landed cost: booking gains freight and purchase brokerage inputs; receipt screen checks billed versus arrived kg and absorbs short receipt (billed amount divided by received kg); the landed rate feeds the yarn WAC by count+type+grade and the PO yarn leg. DB, backend, UI on bookings/new and inward. Tests: landed rate math, short receipt absorption.
C353 added 2026-10-29 owner-created Cost leg bases: warping at rupees per kg of warp; sizing at rupees per kg of warp sent, with the actual bill possibly stating a reverse-calculated billing kg from the received count (quantity variance); weaving at picks per metre times rupees per pick divided by 100 on good fabric mtrs, rate entered per booking with no master because the market varies and the rate is width-sensitive, internal rate for in-house looms; checking charged per fabric metre actually checked including X, rate per quality with a yearly default and editable; mending not charged; packing and loading direct. Backend PO legs, UI, tests.
C354 added 2026-10-29 owner-created Bill lifecycle and restatement: cost legs move from provisional to actual via a bill entry (manual plus import, vendor, bill no and date, kind, amount, GST) auto-allocated to POs by quantity; variance split into quantity and rate; recompute PO total and unit cost, restate the pool entry and every SO that drew from it; SO pnl_status provisional until all bills, auto-close on the last bill, manual close with a flag when bills are missing, and a bills-pending queue row. Tests: restatement cascade, allocation, close rules.
C355 added 2026-10-29 owner-created SO P and L lines on delivered mtrs: revenue from delivered mtrs; CD availed from the dhara slab; credit cost = max CD minus availed CD; brokerage; overhead 1 percent company-wide default and editable; freight-out, insurance, octroi and statutory, sample; each computed on the selling price via cost times p divided by 1 minus p so each is exactly its percentage of price; dhara master max-CD slab feeds the max; quote engine corrected to the same gross-up and the 1 percent overhead replaces the 6.5 percent other expenses. Tests: split, gross-up, quote parity.
C356 added 2026-10-29 owner-created Exceptional and non-standard costs: entry form allowing a one-off charge at PO level (capitalised, moves WAC) or SO level (direct P and L, default), with document ref and reason, append-only; included in P and L and in restatement. DB cost_leg kind exceptional, backend, UI, tests.
C357 added 2026-10-29 owner-created Opening stock at cutover: entry of opening quantities and values for yarn by count+type+grade and fabric produced and purchased by quality+pick, feeding pool_entry so the WAC starts from real stock; validation, optional import. DB, backend, UI, tests.
C358 added 2026-10-29 owner-created SO fulfilment marking: manual Order fulfilled action allowed only when delivered mtrs are within the order tolerance, blocked outside so the SO must be amended first; short within tolerance releases the remainder at locked cost; long within tolerance requires apportioning the excess from stock or an existing PO at current cost before marking; reversal only with owner approval, append-only. Backend orders/[id], UI action, tests.
C359 added 2026-10-29 owner-created The documents field should give an option of downloading the uploaded/ocr document or uploading new and uploading multiple.
C361 added 2026-10-29 owner-created Total cones not needed
C363 added 2026-10-29 owner-created Still can't pinch and zoon into the image. After 100% it does not zoom further.
C352 done 2026-10-30 owner-closed shipped in 7149bbe6, live-check 83/83; blocked only by the /reports 500 (costBasis missing from the load), fixed and proved
C353 done 2026-10-30 owner-closed shipped in 7149bbe6, live-check 83/83; same /reports 500 block, fixed
C354 done 2026-10-30 owner-closed shipped in 7149bbe6, live-check 83/83; same /reports 500 block, fixed
C355 done 2026-10-30 owner-closed already shipped in 7149bbe6, live 83/83 — re-closed after answering the stale watcher question
C364 added 2026-10-30 owner-created Docs log + test. Yarn pool: an earmarked purchase never enters the unapportioned pool WAC. A booking whose cost is apportioned to one or more production orders keeps its own per-order ledger at the booking landed rate (rate x received kg + freight + brokerage); the free pool balance and WAC count only entries with no order tag. An issue to a PO consumes its own earmark first at that locked rate, then free stock at the free pool WAC. The stock report shows free kg and earmarked kg separately. Validation: earmarked kg <= the booking received kg and the tag split sums to its net kg. Tests: a 100 kg receipt at Rs200 tagged to a PO does not move a 100 kg free pool at Rs150 (WAC stays 150) and that PO reads Rs200/kg.
C365 added 2026-10-30 owner-created Docs log + test. Yarn cost is a manual earmark, not a side-effect of the gatepass. YARN_OUT writes quantity only, with no yarn cost leg. The PO yarn leg is written when procurement earmarks a booking (or part of it) to the PO at the booking landed rate, or when the user explicitly draws free stock to the PO at that moment WAC. The booking form Against split writes the earmark (kg per PO) and the PO record shows its yarn bucket (source, kg, rate, value, still unbilled). Validation: earmark kg > 0 and <= the booking un-earmarked kg; the landed rate is read-only on the earmark; a free-stock draw <= the free balance for that count+type+grade.
C366 added 2026-10-30 owner-created Docs log + test. A production order is a program, not one spec: one quality ideally, but several picks, tippans and weavers. Add a po_segment costing unit (poOrderId, qualityKey, pick, weaverId, tippanId, plannedMtrs, weaving rate per pick, inHouse). order.picks and jobRate remain the default first segment. The weaving commitment leg is written per segment (picks/m x rate per pick / 100 on the segment planned mtrs) and an in-house segment uses the internal rate with no vendor bill. The PO record lists the segments and lets the user add one before any fabric-in against it (append-only amendment). Validation: pick 1-200, rate > 0, planned mtrs > 0, no segment change after fabric-in.
C367 added 2026-10-30 owner-created Docs log + test. Cost is per lot, not per PO. fabric_in carries the segment it came from, the quality key and the actual pick of the delivered fabric (not design.pick); the lot it creates takes that quality and pick. The lot cost is its segment yarn share + warping + sizing (pro rata by the beam mtrs it used) + weaving at the segment rate per pick x the actual picks/m + checking on its checked mtrs, divided by the lot sellable (A/B/C/R) mtrs; X mtrs carry zero and their costs stay in the numerator. Completion writes one pool entry per lot at that lot unit cost, not one PO unit cost, and apportions to the SO at that lot cost. Shortfall is per segment. Validation: a lot needs a pick > 0 and a segment; graded mtrs sum to the lot net.
C368 added 2026-10-30 owner-created Docs log + test. Within a lot the cost per sellable metre is grade-blind: A, B, C and R all carry the same Rs/m and a grade difference appears only in the selling price. X is zero cost and its yarn, weaving and checking share is pushed onto the lot sellable mtrs. Checking is charged per checked metre including X. Validation: graded mtrs sum to the lot net mtrs and a lot with no sellable mtrs refuses completion.
C369 added 2026-10-30 owner-created Docs log + test. A beam or part of one can move from one PO to another, even of another quality. The receiving PO books it at a market value typed by the user, composed leg by leg: warp kg x yarn rate + warp kg x warping rate + sizing kg x sizing rate. The form shows hints (the latest procurement rate for that count+type+grade, that day rate sheet for warping, the yarn master sizing rate) but the typed figures are the authority and are stored on the transfer with the hints shown. A partial beam splits pro rata by kg. The gap between the beam carried cost (yarn at issue + actual warping + sizing) and the typed market value is a transfer variance leg on the transferring PO, gain or loss, and the SO apportioned to it is re-apportioned. Validation: all three rates > 0, kg > 0 and <= the beam net, no transfer of a beam with no sizing bill.
C370 added 2026-10-30 owner-created Docs log + test. An SO-linked PO carries a budget: the accepted quote planned legs x the PO own planned quantities, snapshotted when the PO is created (a quote is never revised once an SO exists). A stock PO has no budget. The PO record shows budget vs actual per leg and the drift. Validation: a budget is written only when the PO has a parent SO and a quote; never for a stock PO.
C371 added 2026-10-30 owner-created Docs log + test. The SO cost is per leg at the rates of the PO it was apportioned against, over the fabric actually delivered: weaving is that PO rate per pick x the delivered lot actual picks/m, and the other legs follow the delivered lot quantities. A higher-pick lot delivered against a lower-pick SO shows the extra cost in the SO P&L and the SO committed rate never moves. Where the delivering PO own cost differs from the SO locked value the difference is a variance on the delivering PO (over or under), never a re-price of the SO. An apportionment row carries the committed leg rates, not only a unit cost. Until a leg is committed the SO provisional cost uses the PO budget (C370). Validation: an apportionment refuses a lot with no pick.
C372 added 2026-10-30 owner-created Docs log + test. Cancelling a PO returns its yarn to free stock at its carried cost, not at zero. The release out and in pair carries qty x the order yarn unit cost (the current code writes value 0, which deflates the free pool). Produced fabric stays in the free pool at its lot cost. An unstarted sizing or weaving commitment is not charged. Validation: the release value must equal qty x unit cost and the free pool value must rise by it.
C373 added 2026-10-30 owner-created Docs log + test. Every bill is apportioned to its PO by the user at entry: the bill names the PO and the share, and nothing is silently auto-allocated. The form suggests by open committed quantity and shows the remainder, but a bill with no allocation cannot be saved. Validation: shares > 0 and their sum equals the bill amount; an allocation cannot exceed the PO open committed leg.
C374 added 2026-10-30 owner-created Docs log + test. A quote carries the commercial terms the SO inherits: purchase brokerage % and pass-on %, and the freight/insurance term with its recovery basis (inside the rate or billed on top, default excluded and borne by the buyer). Add these to the quote schema and the quote form with validation (both percentages 0-100, a delivery-term enum, a recovery enum), and carry them into the SO read-only. The SO never asks for them again. See docs/ORDER-FORMS.md D17/D18.
C375 added 2026-10-30 owner-created Docs log + test. A normal SO must be created from a quote. Make quote_id required for a normal sale: the server refuses an SO with no quote, keeps one SO per quote, prefills buyer, broker, quality, picks and the delivery window from the quote, and lets sales overwrite the rate with the final negotiated figure (still greater than zero). Remove the SO owner-approval gate: a sales-booked SO is approved at creation and goes straight to PPC. Retire free entry of buyer, quality and broker on this form. See ORDER-FORMS D23/D24.
C376 added 2026-10-30 owner-created Docs log + test. The new-sale-order screen opens on the pending-quotes table (party, quality and alias, quantity, rate, validity, days open; searchable), not a blank form. Tapping a row opens the SO already filled. Back returns to the table with the choice cleared. A Change action on the quote chip re-inherits from the newly picked quote and resets everything typed against the old one (quantity from its estimate, rate from it, tolerance back to 5, remark cleared). See ORDER-FORMS D24.
C377 added 2026-10-30 owner-created Docs log + test. Replace the 14-step SO wizard with four focus steps: quantity, rate, tolerance, remark. Keep the quote facts pinned as a meta strip on every step (quote no, buyer, quality, delivery window, payment, rate) and delete the dead hidden section blocks. Each step keeps its own gesture and context coins: quantity a 1000-metre wheel with 100/1000 steppers and coins from the quote estimate, this buyer and this quality; rate a keypad with 0.25 steppers and coins from the quote and the quality history; tolerance chips 3/5/7/10; remark dictation plus past remarks for this buyer. Labels are short and the value owns the row. See ORDER-FORMS D25.
C378 added 2026-10-30 owner-created Docs log + test. Add tol_pct to the order (default 5, sales-editable, bounded 0 to 25) and delivery_start and delivery_end dates. The start date is the promise for the first delivery and the end date the promise for completion. Retire due_days and promised_days from the SO form and the ops completion; keep the columns for history only. Validation on both surfaces: tolerance between 0 and 25, start not before the booking date, end not before start. See ORDER-FORMS D2/D6/D13/D20.
C379 added 2026-10-30 owner-created Docs log + test. Dispatch is checked against the sale quantity with its tolerance band. Inside quantity plus or minus tol pct the dispatch proceeds; beyond the band the order needs an amendment and owner approval rather than a note. Only A, B, C and R metres count toward the sale quantity: X never counts toward the quantity or the tolerance. The buyer dispatch-lot size is a hint on the dispatch form and is never enforced. See ORDER-FORMS D2/D4/D5/D6.
C380 added 2026-10-30 owner-created Docs log + test. Cost cover is the PPC stage. Coverage lines may total anything inside the quantity plus or minus tolerance and must not be forced to equal it exactly. The order is ready to produce only when sales is done and the cover is complete within the band. A dispatch that exceeds what is apportioned still saves and raises a cost-not-covered item on the PPC board; a dispatch below the apportioned metres releases the excess at its locked cost. See ORDER-FORMS D3/D4/D20.
C381 added 2026-10-30 owner-created Docs log + test. Add a consignee to the SO as a party master link with a new Others category. It is optional at booking with an explicit decide-at-fulfilment state; dispatch refuses to save without a consignee. Validation: the consignee must exist and be an active party; when present at booking it is read-only for planning. See ORDER-FORMS D7.
C382 added 2026-10-30 owner-created Docs log + test. Store the broker as a party id (broker_id) instead of the typed broker_name. Migrate existing orders by matching broker_name to party.name where category is Broker and keep broker_name for history. The broker picker offers master brokers only; the quote already carries brokerId and the SO inherits it. See ORDER-FORMS D8.
C383 added 2026-10-30 owner-created Docs log + test. Store cd_pct and payment_days on the order, taken from the chosen payment slab at booking, alongside the dhara link. The ops completion prefills them instead of re-keying and the pending-ops flag no longer fires once they are set. See ORDER-FORMS D9.
C384 added 2026-10-30 owner-created Docs log + test. Tighten the order form rules on both surfaces: rate greater than zero for every role, picks an integer between 1 and 200 (picks per inch), quantity a multiple of 1000 metres, and no duplicate buyer PO number on the same buyer. Fix the picks placeholder, which still reads 4000 and must show a per-inch example such as 64. See ORDER-FORMS D10/D15.
C385 added 2026-10-30 owner-created Docs log + test. Server failures must be visible. The error banner and every field error are rendered inside the hidden form container, so a rejected save appears to do nothing. Render the banner in the visible summary, jump to the first field in fieldErrors and open that field step with the message under it. See ORDER-FORMS UI notes and the verified finding in the session log.
C386 added 2026-10-30 owner-created Docs log + test. One order record with three stages: Sales, Planning and PPC. Sales and PPC complete make the order ready to produce; planning complete gates weaving. Each stage shows its own fields open for its role and a read-only summary for the others. Add each stage to the per-role pending board with an age, and make the board that role landing page. See ORDER-FORMS D16/D27.
C387 added 2026-10-30 owner-created Docs log + test. Planning works a card: the buyer order image pinned in the top half (zoomable, collapsible), the planning fields below (buyer PO no, packing, cut size, rolls computed, consignee) prefilled from OCR and tappable to correct. The image is optional at SO creation; planning uploads it when sales did not. See ORDER-FORMS D28 and the planning stage in D16.
C388 added 2026-10-30 owner-created Docs log + test. Selecting a quality records that quality alias on the order, and a user not arriving from a lead or quote can type the alias to find the quality. The picker already searches name or alias. See ORDER-FORMS D14.
C389 added 2026-10-30 owner-created Docs log + test. Retire the legacy yarn cost basis path: remove the field from the order form, delete recordCostBasis and the order_cost writes, and point the Reports order-profitability table at the new cost engine (cost legs and apportionments). Keep the table for history but stop reading it. See ORDER-FORMS D26.
C390 added 2026-10-30 owner-created Docs log + test. A damaged (X) sale gets its own small form, exempt from the compulsory quote: buyer, the lot it comes from, metres, scrap rate, consignee and remark, with validation (metres greater than zero and not above the lot balance, rate greater than zero, the lot must be an X or damaged lot). It links to its source sale order where one exists. See ORDER-FORMS D21/D22.
C391 added 2026-10-30 owner-created Docs log + test. The order draft autosave snapshots only the fields this form actually shows. Today it restores dispatchCity and other hidden values, so a later form can inherit state the user never saw. Restrict the snapshot and the restore to the visible field set for this form type and role. See docs/ORDER-FORMS.md, verification pass item U8.
C392 added 2026-10-30 owner-created Docs log + test. Field ownership after the three-stage split: the ops completion form currently offers rate, cash discount and dispatch city, which sales and planning now own (C375, C383, C381). Make them read-only there or drop them, so two surfaces cannot disagree. See ORDER-FORMS D16 and the verification pass item F5.
C393 added 2026-10-30 owner-created Docs log + test. Split OrderEntryForm.svelte (about 3,460 lines) by stage: the sales identity and quote strip, the quantity and price steps, delivery and terms, planning, and the review sheet, each a small component under src/lib/components/orders. No behaviour change; the route stays a thin shell. See AGENTS.md UI rules and ORDER-FORMS.
C394 added 2026-10-31 owner-created Docs log + test. Every entry form gets a machine-readable contract under docs/contracts, read by one shared typed loader so the form, the test and the router cannot disagree. Ship the schema (form, kind, role, read-only strip, fields with order/owner role/required/rule/prefill, the actions the screen may offer, and an absent list naming where each omitted field lives instead) and wire the SO contract that already exists at docs/contracts/so-form.json (ORDER-FORMS D29) through it. Acceptance: the loader returns the SO contract typed; a malformed or missing contract fails loudly; no form-specific field list exists anywhere but the contract.
C395 added 2026-10-31 owner-created Docs log + test. Rebuild the sales SO screen to ORDER-FORMS D29 and docs/contracts/so-form.json: a read-only quote strip (quote no, buyer, quality, delivery window, payment, rate) followed by one flat list of four fields — quantity, rate, tolerance, remark. Delete for the SO: the four section blocks, the coverage/apportionment step (it belongs to PPC), the production-role fields (buyer order no, cut size, rolls — they move to planning), the consignee field (planning, owner 2026-10-31), the hidden duplicate sections, and the Create SO button on the quote-table screen. Keep the draft autosave, restricted to the four visible fields (withdrawn C391/C393). Acceptance: SSR shows exactly the four fields in order, no production field, no coverage, no Create SO button; saving still books the SO with the quote carried; job-work and production forms keep their sections.
C396 added 2026-10-31 owner-created Docs log + test. Enforce the contract in a test. For the SO: the form field spec must contain exactly the contract four fields, in contract order, owned by sales, and every name in the contract absent list must have no spec on this form. Adding, moving or re-owning a field without editing docs/contracts/so-form.json fails. Acceptance: green on the current contract; removing a field from the contract fails; re-adding rolls to the sales form fails; the message names the contract line that broke.
C397 added 2026-10-31 owner-created Docs log + test. Add scripts/form-contract-check.ts: sign in against the running app on 127.0.0.1:4102 with the session cookie, fetch the form, parse the HTML and assert the rendered screen matches its contract — the four fields in order, exactly one create action, no input or error markup inside a hidden container, and for the quote table a quote-no column, no horizontal clipping at 356 px and no second create action. Non-zero exit prints the offending element. Acceptance: green on the live build; a deliberately hidden error div fails it; the table check reports the clipped width when a column is added.
C398 added 2026-10-31 owner-created Docs log + test. One shell, one layer. Add src/lib/components/ScreenShell.svelte (background, header with title and a back control, max width, spacing) and one FocusLayer spec (width, backdrop, header, footer), then adopt both in the quote screen and the SO focus layer so the two stop reading as different apps. Replace the quote popups max-w-xs and bg-black/30 and the SO max-w-md plus blur with the shared spec. Acceptance: both screens render the same shell classes and the same layer width and backdrop; no popup defines its own width; the SO keeps a reachable page header.
C399 added 2026-10-31 owner-created Docs log + test. Android back unwinds one layer. Add src/lib/historyLayer.ts: opening a layer pushes one history entry, closing it by backdrop, button or back pops it, and the route popstate handler closes the top layer instead of leaving the page. Apply it to the SO focus layer and the quote popups, and add scripts/layer-audit.ts that fails on any role=dialog or fixed inset-0 layer that does not use it. Acceptance: with the SO layer open history.length grows by one and back closes the layer while the form stays; a second back leaves for the quote table; the audit is clean and fails when a layer is added without the helper.
C400 added 2026-10-31 owner-created Docs log + process. Supersede in the same commit. A row that moves or removes a field must update the form contract, delete the old markup, and add a negative assertion that the field is absent where it used to be. Record the rule in AGENTS.md and in the row prompt so a session cannot add the new placement and leave the old one behind. Acceptance: AGENTS.md and the row prompt both state it; a shared assertAbsent helper exists and the SO contract test uses it.
C401 added 2026-10-31 owner-created Docs log + process. One owner-row per screen until that screen is stable: two rows must not target the same component in one block. Add the rule to AGENTS.md and docs/QUEUE-AUTO.md, and make the board warn and hold a new row whose target equals an open row target in the same block. Acceptance: queue-next reports the clash instead of silently serialising; AGENTS and QUEUE-AUTO state the rule.
C402 added 2026-10-31 owner-created Docs log + process. Inventory before queue: no form block is queued until its contract exists and the owner has approved it. Record in AGENTS.md that docs/contracts/
C403 added 2026-11-04 owner-created the field sequence should be rate, qty, tolerance, delivery start, delivery end
C404 added 2026-11-04 owner-created when i tap rate or quantity, expand the portion below showing suggestions based on previous entries. on tapping a suggestion, close this portion
C405 added 2026-11-04 owner-created terms like brokerage (from quote) should be shown as well
C406 added 2026-11-04 owner-created delivery start and delivery end shoud be side by side. also show the days as time period. also, suggest different time periods based on previous selections. tapping it should autoupdate delivery end date
C407 added 2026-11-04 owner-created when i tap any fields, the suggestion portion should autoclose. for all the fields show suggestions like we see on rate and quantity
C408 added 2026-11-04 owner-created when i added ✓ Added — order SO-261104-U7IO, I instead want a popup notification, with the row highlighted
C409 added 2026-11-04 owner-created the suggestion and tap flow in http://127.0.0.1:5173/orders/new/trading?quoteId=5aincgag3zxm&type=SO seems to be ideal. instead of opening a popup for suggestion, use the above system throughout the website