PLANNING.md — flow-first planning before any production

Gate: no production features are built until this plan — the working flow, the form map, and the per-field validation — is reviewed and signed off by the owner.

Method (one step at a time, exactly as agreed):

1. Working flow (this doc) — the real operational process, end to end, both profit centres (trading + job-work) on one spine.
2. Flow → form map — every flow step ↔ the existing software's forms ↔ the new mobile/office screens, with who taps what.
3. Per-form deep dive — every input field of every form, validated for necessity, sourcing (auto/select/scan/number/text), and who/when. Labour-facing screens end selection-only; text dies on mobile.
4. Data model & events — the schema + event types + numbering + tenancy, derived from the validated forms.
5. Owner signs off the flow diagram and the screen inventory → then Phase 0 (ROADMAP) begins.

Reports keep arriving (this drive is non-exhaustive) — they feed step 3 and the report/dashboard catalogue (docs/DASHBOARDS.md), not the flow itself.

Input-mode policy (mobile-first, labour-friendly)

Rule of thumb for labour screens: zero free-text fields. A field that needs typing on the floor is either auto-filled, a selection, a scan, or moved to an office screen. Office screens keep full forms (rate, GST, terms) where typing is natural on a desktop/keyboard.

1. The working flow

Two profit centres, one flow — the module difference (trading vs job-work) is a flag on the order/contract and the ownership (own/party) on the lots; no form is duplicated. In-house and out-house work are the same steps with a different unit.

STAGE A — COMMERCIAL (two different paths by order type)
 A1 (trading only) Lead/enquiry ──► Quote (costing engine + yarn-rate board) ──► SO
 A1b (job-work only) DIRECT contract entry — no enquiry/quote/sample           [owner-confirmed]
 A2 Requirement calc ──(auto: design kg/m factors)──► need = demand − free − in-transit
 A3 Samples/strike-offs (trading, new designs only; parallel)
 A4 Confirm: order created — type = trading | job-work; design + design ALIAS;
    smart-prefills from past transactions (party+broker → CD%, payment terms, brokerage)
 A5 Hand-off: open order → requirement calc (trading) / party-yarn expected (job-work);
    if yarn arrives BEFORE the contract → "park-lot" (unmarked material) placeholder,
    assigned to the contract later
 A6 Status moves — event-driven (open → in-prod → delivered → closed) +
    job-work HISHOB statement per party (yarn given vs fabric delivered), generated with
    the last dispatch: hishob-pending → hishob-sent → hishob-accepted

STAGE B0-B2 — YARN MOVEMENTS & GATEPASS (before any stock entry)
 G0 GATEPASS (dispatch note): planning enters GP + uploads image (GP comes
    on WhatsApp + physical; physical stamped → transporter/weaver/sizer)
 G1 endorsement legs: trader→us (own/YJ), us→transporter(pickup), us→sizer
    (warp), us→weaver (weft/out-house), direct-to-premises delivery
 G2 transporter login: my-pickups, mark picked (partial/all) against GP
 G3 sizer/weaver confirmations (not in system): our WhatsApp msg with
    answer options + photo → planning uploads reply screenshot → ack
 G4 gate guard: scan transporter's INWARD code (from GP) → partial/all →
    system PRINTS yarn barcodes → guard tags boxes while unloading
STAGE B — YARN (kgs; bags & cones; own | party; warp | weft)
 B0 job-work: EMPTY-BEAM OUT intimation (planning) → guard taps outward;
    no yarn booking for job-work (yarn comes via gatepass)
 B1 Yarn Booking [TRADING ONLY] — count + TICKET (mill) via suggestions,
    bags × packaging (cones/bag, bag wt → per-cone wt prefilled from
    history; warp bag-count in SIZING-SET multiples from construction×ends)
 B2 Yarn Inward — warp|weft tag is a soft label (changeable until usage);
    marked to CONTRACT (JW contract / SO / internal production order);
    set-no NOT at inward (assigned at sizing-set issue or JW beam inward)
 B3 Stock ledger states (own/party; per-bag barcode)       [system]
 B4 Allocations (soft) + VERBAL-COMMIT reservations (soft tag, expiry)
 B5 Movements: party↔factory ▪ contract→contract ▪ short ▪ weft-out/+
    RETURNS FROM PRODUCTION (machine source, re-barcode, reconciled cones)
 B6 Weft inward (job-work, parts) ▪ B7 stock take (scan bag → cone count,
    unmarked list) ▪ B8 yarn hishob later
    job-work weft: 5% allowance over requirement; saved weft → weaver
    account via yarn-stock-transfer (weaver sells later)

STAGE C — WARP PREP (beams; empty ↔ filled; warping BEFORE sizing)
 C0 EMPTY-beam OUT: intimation (planning) → guard taps outward; actual send
 C1a WARPING: cones unwound onto beams — krill (creel) size × parts;
    ends per warp = EPI × width (+ weaving width-shrink estimate);
    parts = ends ÷ krill (soft slack); cone measure = per-cone wt × count
 C1b SIZING TIPPAN (planning/suggested by system): construction intimation +
    which yarn (at sizer | gatepass to pick) + which weaver + pick-up
    intimation + number of beams; set-no assigned here (trading)
 C1c Warp + empty beams → sizing
 C2 Sizing receipt: FILLED beams in (parts) — guard selects sizer + beam nos
    from OUTWARD list + clicks GP photo (mtrs entered later by planning;
    OCR prefills with manual check); beams + leftover cones inwarded
 C3 OUT-HOUSE: sizing returns beams WITH a gatepass copy → saved in system
    (per-beam production tracked separately — never mixes in-house beam
    stock); weaver takes weft from us
 C4 Winding (out-house): bottoms/fresh cones → winder → re-wound single cones
    → INWARDED again (usable warp/weft); reconciliation later (deferred)
 C5 Beam card: construction + details, travels with beam on machine,
    tracks mtrs produced until beam ends (flange no = physical identity;
    beam no = system production identity)
 C6 Returns/transfers: intimation before every movement

STAGE C — WARP PREP (beams)
 C1 Warp → sizing (construction intimation: design, reed space, set no, type of sizing)   [out-house]
 C2 Sizing receipt ◄─ beams (mtrs, cuts, ends, cut-mark), used kgs, leftover/winding yarn
 C3 Winding (out-house auto-spinner): yarn→winder; reconciliation (empty bags/cones, ring wt, diff net/gr wt)
 C4 Beam card: beam ↔ loom ↔ flange ↔ frames; beam status (getting frames → on loom → finished)
 C5 Beam returns to party / transfers (party-owned beams)

STAGE D — WEAVING (mtrs; in-house looms + out-house weaver contracts)
 D1 PRODUCTION PLANNING (core board — currently Excel; system automates):
    drag-drop floor beams→looms; running beams, filled beams on floor, next-beam
    plan AUTO-proposed + confirm; calendar plotting; out-house charted by
    planner on intimation (beam started, loom, date) → packing/dispatch planning
    and next-contract visibility; knotting>gatting preference baked into planning
 D2 WEFT ISSUE (scan bag → cones shown remaining → tap count; loom+shift):
    AUTO-assigned to the beam's contract/fabric on the loom; PARTY LOAN when a
    party's weft hasn't arrived (scan-led: bag party ≠ beam party → loan, netted
    at close); sold yarn = separate form (JW saved / trading excess)
 D3 OUT-HOUSE: fabric-in — slip OCR + per-roll/lump user confirm while
    unloading; stock inwarded even when packed/dispatched FROM WEAVER (stock
    location = weaver); rounder's daily collect (machine meters, mended mtrs)
    entered; links out-house beam ledger (C3)
 D4 IN-HOUSE TELEMETRY: loomgate utility (machine vendor SQL Server → their
    Supabase) → our ADAPTER pulls loom analytics (picks/RPM/breaks/stops/doffs,
    serial↔machine map, beam info) into our event log — manual entry
    eliminated; roll DOFF → auto WIP barcode printed at checking gate
 D5 BEAM-END: reason required (warped-out via machine data | cut mid:
    emergency plan change / dispatch priority / defect); dispositions for
    half-cut beams (empty-return, re-size then return, renegotiated job-rate
    and resume, defective warp removed→returned to party→resume); new-beam
    start marked KNOTTED or GATTED (prefill, confirm) → changeover-time &
    downtime reports

STAGE E — CHECKING & PACKING
 E1 Checking rolls: mtrs, kg, gsm, grade (A/B/C/…), barcode, tag          ──► checking report (in-system)
 E2 Lumps (short pieces/seconds) ──► bales (grade F)
 E3 Folding/mending many-to-one joining (as needed)

STAGE F — DISPATCH & DELIVERY
 F1 SO delivery planning (tags vs order, balance qty)
 F2 Fabric dispatch slip (packing slip, party, order, balance, vehicle, LR no; customer/office/transport copies)
 F3 Delivery vs SO by grade; delivery shortfall tracked

STAGE G — FINANCIAL HOOKS (Tally, later phase)
 G1 Vouchers from: yarn booking GST, receipts, dispatch, job-work billing ── auto-export (BRIDGE contract, FIELDMAP trading §Yarn Booking)

2. Flow → form map (existing software → new screens)

3. Per-form deep-dive method (field-level validation template)

Applied to every form (old + new) before any schema is finalised. Each field gets a row:

Decision rules: a field is kept only if something downstream consumes it (a state change, a computed value, a report, an accounting hook); a field is merged if it is a duplicate view of another field (e.g. the same party repeated on several forms); drops go to FIELDMAP.md with a reason. Office-only fields are removed from labour screens even when kept on office screens.

The first deep-dives (done in this phase, below) are the floor screens where labour taps; office forms follow the same template once the floor set is agreed.

3.1 Yarn Inward (godown receipt) — deep dive

Purpose: record yarn arriving against a Booking (PO): lot identity + kgs so stock/allocations move. Fields:

Automation summary: ~80% of the floor receipt is scan + select; only bag/cone counts and weights are numbers; cal/net computed.

3.2 Beams received from sizing — deep dive

Purpose: close the sizing leg — beams enter stock with mtrs/cuts/used-kgs, leftover yarn returns. Fields:

3.3 Checking & packing entry (rolls) — deep dive (labour screen)

Purpose: per-roll grade + measures; the checking report and grade stock consume this. Fields:

3.4 Daily efficiency register → IoT (the automation case)

The old form's columns (picks, RPM, warp/weft breaks + times, stops, start attempts, efficiency, sessions A/B/C, electrical-failure minutes) are exactly what loom sensors emit. New design: loom-telemetry events are ingested automatically (PLATFORM.md §4); the mobile fallback is a per-loom tap screen (select loom → tap "warp break ×1", "stop 10 min", end shift). The register screen becomes a read-only runtime table, not an entry form → this is the single biggest duplicate-entry removal.

4. What "planned" means before production

• Flow diagram (this doc, §1) reviewed and corrected by the owner.
• Form map (§2) confirmed — every planned screen named, role + mode set.
• All labour screens pass the zero-free-text rule (§ policy).
• Field deep-dives done for every screen (template §3); outcomes recorded in FIELDMAP.md (keep/merge/drop/auto + reason).
• Open questions (§10 of FIELDMAP.md + those raised here) resolved.
• Numbering + tenancy + period rules decided (FIELDMAP §10 q.17).
• Report uploads mapped: exportable report vs live dashboard tile (docs/DASHBOARDS.md).
• Sign-off → Phase 0 of ROADMAP starts (conversion engine + masters + tenancy seams + event log + realtime board on bun:sqlite).

Each new report/screenshot upload feeds [FIELDMAP.md §"Reports"] and the deep-dives above — the plan absorbs them; none changes the flow silently.

5. Agreed revisions log (living — owner adds changes anytime, even to reviewed stages)

Commercial (2026-08-31 review)

1. Two commercial paths — job-work: direct contract entry (no enquiry/ quote/sample); trading: lead → quote → SO. Quote is effectively mandatory for trading orders (good costing UX required).

2. Design alias is an order/inquiry field (masters already carry it).

3. Smart-prefill, no term masters — CD%, payment terms, brokerage are editable but prefill from past transactions + context (party+broker combo → e.g. 4% CD / 0.5% brokerage); every auto-filled field is highlighted and requires an explicit confirm tap.

4. Park-lot (unmarked raw material) — yarn arriving before its contract (frequent, both types) goes to a "pending contract / unmarked" placeholder and is assigned to a contract later (godown receipt works without a contract).

5. Promised date is provisional — overcommit & soft-push is reality; the order carries the promise, the runtime board shows promise vs plan drift; system records soft-pushes with history.

6. Job-work hishob statement — PER CONTRACT (owner correction 2026-09-01): reconciliation of that contract's yarn given vs fabric delivered, generated with the contract's last dispatch; contract-level flags hishob-pending → hishob-sent → hishob-accepted; format to be shared by owner; treated as a statement object (+ report) attached to the contract, not only a status.

7. Delivery form & terminology (2026-09-01, round 2) — Taga = lump (generally 100 m pieces); fabric ships in rolls (party-defined mtr) or lumps; the ORDER carries dispatch form + per-roll/per-lump mtr. CD% = cash discount tied to payment days, from market dhara per dispatch city (prefill, editable); later mtr changes = amendment log; Less Meter/Less Taga dropped. Global prefill rule: every field prefills from context except order-defining fields (party) — quality = party's top 2–3, rate = same-quality same-period, etc., all editable with confirm taps.

8. Yarn stage corrections (2026-09-01, round 4) — beam-out INTIMATION form (planning picks beam nos per contract) precedes the OUTWARD form where the gate guard taps-and-confirms from the intimated list (zero entry). Yarn is warp|weft: warp needs sizing + beam filling; weft is direct. job-work: filled beams + weft received in parts, simultaneous, no strict chronology. Trading: warp+weft yarn inwarded; warp→sizing WITH empty beams; filled beams back; weft as-is. Out-house weaving: sizing picks the weaver's empty beams, fills, returns to weaver; weaver takes weft yarn from us. receipt classifies warp/weft at entry.

9. B-series & production-context corrections (2026-09-01, round 3): quantity unit mtrs OR beams (brim-filled assumption); C.No = party contract no; loom class = e.g. Airjet 190/250; job-work pricing = ₹/pick × picks, market-based (no costing); tolerance/amendments structured as amendment objects + auto flag on extra sizing beams; quality=name vs design=construction (versioned designs, production maps to design); trading two modes — against-order SO vs stock-driven (FG stock with FIFO/avg lot valuation, method TBD); brokerage pass-on/kept split with bill-CD composition; status changes fully automated (system-derived); job-work starts contract → empty beams→sizing + weft received; sample = separate small-order path + sample stock, explicit waive; sales-promise (SO days) vs production target dates separated.

10. **Commercial acceleration capabilities (feasibility in refl):

    • Yarn-rate ingestion: upload WhatsApp rate-list images/PDFs (+ text) → OCR → today's rates per yarn with clarification prompts (incl/excl GST, mills, spellings) → yarn rate board with trend history. Feeds costing/quotes (Phase 1-2) and yarn-trend analytics.
    • Voice-assisted entry: sales person speaks (party, broker, rate, quality alias) → auto-fill + confirm taps (Web Speech API on Android Chrome; feasibility high).
    • WhatsApp/document intake (owner refinement 2026-09-01): the user UPLOADS the raw evidence — screenshots (full context often spans msgs), broker contract photo/PDF, or a copied text message — and the system extracts + prefills from it. It LEARNS per-sender layouts: a broker sending contract confirmations in a fixed format each time is recognized, which itself signals the party/broker the message pertains to; extracted fields prefill and the user confirms. Official WhatsApp Business API remains a later option for push-inbound; upload-first is the baseline (works with the existing /upload + OCR pipeline).

6. Yarn stage designs (rounds 4–5, signed-in-principle by owner)

Gatepass pipeline (before yarn inward)

• Entity gatepass: source trader → target (our godown | our premises | named sizer godown), items (count, ticket, bags, gross/net, cones), image, status: entered → endorsed → picked(partial/all) → delivered → confirmed → reconciled. Planning enters it (WhatsApp copy + physical, physical stamped for the carrier). Transporter gets a minimal mobile view: today's pickups → tap-picked. Direct delivery in our premises or sizer's: we issue the onward gatepass (to weaver/sizer); sizer-direct confirmations come back via WhatsApp answers + photo, planning uploads the reply image to the GP record and acknowledges (interim; official WhatsApp Business API later automates send+collect — see feasibility note in reply).
• Entity direct-delivery intimation (direct deliveries, NO gatepass): planning raises it as the PRECURSOR — expected count/bags + destination (our premises | named sizer godown) + expected date. Arrival then closes it: premises → normal inward; sizer-godown → sizer WhatsApp confirmation (answer options + photo, uploaded + acknowledged by planning) + post-delivery gatepass counter-copy signature = delivery confirmation. Intimations are the "expected events" that confirmations close — same record family as gatepass (source/items/destination/status/evidence).
• Feasibility: WhatsApp send/collect is fully feasible via the official Business Platform API (approved templates for the question, webhook for replies + media). It needs Meta registration (lead time + per-conversation cost). Interim (zero new infra): planning sends the question from their WhatsApp; the sizer's reply screenshot/photo is uploaded to the GP confirmation tab. Design keeps both paths identical at the record level.

B5 partial-cone reconciliation (design)

Every bag keeps declaredWt, conesAtLastCount, derived perConeWt. On ANY partial move (issue/return), the moving side re-measures the bag: kgs + cone count → issue wt = Δkgs (weighed), and the bag recalibrates perConeWt =(remaining kg / remaining cones). Variance between cone-count math and weighing accumulates as the bag's unaccounted and settles at bag end into shortage/difference (feeds Yarn Hishob Difference). Mirrors the existing ring/empty-cone logic — no extra device needed beyond the station scale.

Verbal-commit reservation (soft tag)

reservation: lot → order (verbal), qty, by whom, when, expiry (default next working day, auto-drop if not converted). Shown as "held (verbal)" distinct from hard allocation; converts to allocation on confirm; never blocks floor moves.

Job-work weft allowance & weaver stock transfer

Weaver contract issues weft at calculated requirement × 1.05; at fabric-in reconciliation, saved weft (efficiency) is offered as a yarn-stock-transfer to weaver account event — weaver-owned thereafter (sells later). Trading excess/winded-unusable yarn → yarn sold movement.

7. Stage C updates (round 6, owner): warping & sizing tippan

• Sizing tippan: the plan/intimation to sizing — construction + how to use available yarn (at sizer | gatepass-to-pick), target weaver, pick-up intimation + beam count. SET-NO anchored here (trading).
• Warping precedes sizing: cones → beams; krill size = winder creel min/max cones; ends = EPI × width (+ width-shrink); parts = beams a single finished beam's ends are split into = f(total ends, warp mtrs, krill, cone measure). ENDS SOFT + WARP MEASURE SOFT → constraint problem. Decision: system PROPOSES the tippan; planner reviews/edits & confirms (see reply for design).
• Two beam identities: FLANGE no = physical beam id (movements); BEAM no (system) = production identity, inward → fabric.
• Gatepass photos at relevant forms: beam-receive = guard selects sizer
  • beam nos from outward list + clicks GP photo (minimal); mtrs/fields entered later by planning; OCR prefills with manual check (handwritten GPs → learn). Owner to send sample GP photos (yarn, sizing-return…).
• Out-house beams: sizing's returns include a gatepass copy → saved; per-beam production tracked in a SEPARATE out-house space — never mixed with in-house beam stock; architecture feeds out-house fabric-in (D3).
• Stock location: yarn stock statement shows LOCATION (our godown / sizer / weaver / in-transit) — stock tracked across the whole value chain, not just premises.
• Reconciliations (sizing/winding/weaving): DEFERRED to the conversions/calculations/reports freeze (this workflow's C4); entered back into system to re-verify calcs, check tolerance, flag exceptions, message parties for justification.
• Beam card: construction + details; travels with the beam on the machine; tracks mtrs produced until beam ends. Owner uploading a copy.
• C signs: C0 ✓; C1 as above; C2 ✓ w/ photos+OCR; C3 ✓; C6 ✓ (intimation first); Q2 flange-vs-beam fixed; Q3 sizing challan; Q4 per set; Q5 per sizing set; Q6 master list; Q7 ✓.

8. Stage D agreements (round 7)

• Planning is today 100% EXCEL (sheet to be shared; upload now accepts .xlsx); the system replaces it: drag-drop floor beams → looms, running/ floor/next-beam views, calendar plotting, AUTO next-beam proposal (user confirms), out-house charts mirror on intimation (beam started/loom/date) feeding checking-packing-plan + next-contract/sale planning. Knotting preferred over gatting is a planning objective (dispatch commitments vs downtime balance: target knotting/gatting times tracked).
• Weft issue: scan bag → system shows remaining cones → tap count; loom's beam auto-selects contract/fabric for consumption tracking (prod vs weft wastage within targets — yarn saved = income). PARTY LOAN (loan from party-2 when party-1's weft not arrived; same count; system nets inter-party owed amounts by barcode+loom context). Sold yarn = separate form (JW saved yarn / trading excess).
• In-house telemetry: loomgate_analytics (their utility: machine vendor's SQL Server → Supabase: order analytics, serial↔machine map, beam info) → our ADAPTER (Supabase REST, idempotent) writes loom events to our log; manual entry eliminated. Roll-doff events → WIP barcode printed at the checking-gate printer; helper sticks per-machine sticker (roll tracks checking→FG→dispatch; reconciles beam warp mtrs vs fabric mtrs).
• Out-house: daily ROUNDER collect (machine meters, mended mtrs) entered; fabric-in slip OCR + confirm each roll/lump during unload; stock inwarded with LOCATION = weaver even when packed/dispatched from weaver.
• Beam-end: reason mandatory (warped-out auto from machine data, else planning marks reason + disposition); knotting/gatting marked at new-beam start (prefill by plan, confirm); machine-display feeds the previous-beam-ended signal; system computes stop→restart changeover vs planning estimate, corroborated for gaps.
• Answers: 2 shifts × 12 h (modifiable to 3); out-house = separate board section; in-house fabric is NOT checked — GRADED at MENDING (primary checking); job-work graded at CHECKING (Stage E confirms).

9. D1 planning-sheet study + photo intake (2026-09-01)

• Excel (Daily MIS — Data sheet, 16 sheets total): the plan board row = contract no (incl. FY) · set no · beam no · design · grey order mtrs · party · reed space/rate · weave · reed · picks · total ends · SIZING flange no · SIZED MTR · beam inward date · loom no · loom type (250/190) · sizing name+set no · RPM · loom-in date · WEAVING MTRS · CALC B/F date · EXP B/F date · BALANCE WARP · STATUS (A)On Loom / B)Floor / c)cut beam) · NEXT BEAM KTG/GTG · next-beam plan-1 + fall date · plan-2. Finish dates are Excel serials; balance = sized − woven; next-beam rows embed KTG/GTG + "same" vs new design + plan refs. Top row = per-contract calc template; bottom block = yarn cons/stock numbers. 'Planning' (1145 rows), 'Close Beam' (6228), 'Beam Stock' (951), 'Stiker', 'Under Sizing', 'Dispatch', 'Party Con. No.', 'Mending Checking report' etc. are sibling views (to study next pass).
• Sizing tippan (photo): Warping & Sizing Instruction Slip — tipan no, sizer, beam req. date, yarn gatepass no; Yarn Issue (count, mill, bags, cones, net wt, cone packing); Program: Ends per part × parts = total ends (verified: 1504 × 9 = 13536 ✓), Measure (warp mtrs), Tasa/DBR, Quality (width/reed/pick/weave/reed space), Beam instruction (weaver, loom type, no. of beams × mtrs), notes (lot no check; job-work yarn).
• Sizer return/weight slip: set no, customer, GP, count, CNo, creel (krill) count, ends per beam, length, breaks-per-million, re-winding cones & wt, damage cones, paper-cone wt, empty-bag wt, bottom net wt, inward/outward nos — feeds the C2 receipt + quality.
• Kharad (resolved): sizer's slip shows YARN OUTWARD rows labelled Kharad (remnant/partial cone batches sent to machines) — "Kharad" is a yarn-outward lot marking, not a party. (To confirm final wording.)
• Beam start/end statuses (screenshot of the dropdown): at least Getting (frames) · Knotting · Re Knotting · PicChange · Quality Change · Beam Transfer · ReGetting · CutBeam — mapped to D5/C5 (knot/gat + cut-beam) and the Data sheet's A/B(/c) statuses.

10. D1/D5 confirmations (2026-09-01)

• G (Data sheet) = REED SPACE (inches; can exceed design width for combined panels); DBR/DBF = distance between flanges (beam width capacity — determines what fits a flange); breaks-per-million is a real KEEP: yarn-quality metric predicting weaving efficiency (recorded on sizer slips → sizing receipt).
• Beam-END reasons: beam end (warped out) vs cut beam — cut beam has PROCESSES that must be modelled & affect reconciliation:
  • manual warp DRAWING (gatting by hand) → separate FORM capturing the drawn warp's WEIGHT + RETURN;
  • re-sizing return (beam out for re-size, back in);
  • defective warp top removed → weighed → returned to party → resume;
  • JOB-RATE RENEGOTIATION → must update the CONTRACT (amendment object, Stage A4) and flow back into costing/completion.

11. E2/E5 + checking confirmations (2026-09-01)

• Grading NOW (manual): grades A, B, C, R; 4-point + defect-by-metre marking is the MENDING-IoT system's scope (integrated later); a DEFECT MASTER exists now (defect list selectable at grading time).
• L2L (resolved): lasa = the sizer's warp-length marks (every ~110 m of warp); L2L = distance between lasa marks IN THE FABRIC (e.g. 107 m); warp shrinkage = (lasa - L2L)/lasa (3/110 ≈ 2.7%). Checked per roll, NOT mandatory — a few rolls per batch, recorded on the checking report. This locks the costing allowance K = Lasa/L2L (COSTING.md).
• RS on loom: reed space measured LOOM-WISE by the checker, noted on the checking report.
• Checking report (out-house): Piece No (roll or fold no), defects (defect master), grade — minimal entry; signed by WEAVER + our PRODUCTION head + MENDING head; mobile/tab first. Sample (manual) to come. Later: movable mending-IoT fabric-map on out-house rolling machines (portable, install-in-seconds) — later adapter.
• Bales (E5): 5–6 lumps tied + POLY BAG = one bale; bale barcode (separate code); bales = lump/seconds stock.

12. F close + bale dispatch + hishob-close (2026-09-01)

• F1–F3 signed. F4 (Tally: inventory + commercial integration; job-work hishob detail with reports) shelved — later phase, discussed with reports/reconciliation freeze.
• JOB-WORK OUTSIDE HISHOB: we RECEIVE the sizer's/weaver's hishob statement → entered into our system → closes the contract; OCR useful there (handwritten hishob slips) — same intake pattern as gatepasses.
• BALE dispatch by mode: job-work lumps go out WITHOUT baling; TRADING lumps are baled and dispatched; OUT-HOUSE lumps are inwarded AS-IS (even if the weaver already packed) → bales are CREATED INSIDE the system → bale barcodes scanned → dispatch. Never re-created from the weaver's packing.

13. Pending inputs from the owner (SHELVED — provided after full-flow review)

1. Sample MANUAL CHECKING REPORT (out-house, current format).
2. Sample JOB-WORK HISHOB STATEMENT (current format) + the received hishob slips to OCR. — STATEMENT RECEIVED 2026-09-02 and decoded (REPORTS.md §2.1); the received slips to OCR still pending.
3. Sample photos: yarn gatepasses, sizing-beam-return gatepasses, transporter/weaver variants (some already received 2026-09-01 — confirm the remaining ones).
4. Beam card copy (form screen exists; owner's physical copy pending).
5. All slips and their current formats (general batch — converted into form samples as they arrive).
6. Reconciliation formats received from sizer/winder/weaver (enter into the calc/report freeze).
7. Costing/valuation method decision (FIFO vs weighted-avg for stock-mode P&L + avg stock cost).
8. GST config per supplier (IGST vs SGST+CGST) for the Tally bridge.
9. Numbering sequences decision (per-tenant, per-module, shared?) for Contract/Booking/GP/PS/Inward numbers.
10. LTOL/UTL meaning; cal-weight need; "Booking Entries" menu meaning; promised-completion-days vs production target-date definition.
11. E-stage leftovers: defect master values; reject(≥24/tolerance) path → bale/seconds; WIP-remainder sticker rule; grade A/B/C/R pricing meanings for dispatch.

14. Full-flow overview artifact (2026-09-01)

• complete flow × form × actor × location × trigger map, with the form deep-dive fields (prefill/input-type) — generated HTML: src/static/full-flow.html served at /full-flow.html (A3-landscape print CSS); rendered PDF screenshots/FULL-FLOW-A3.pdf (downloadable from /upload). Regenerate with the generator script as the flow evolves.

15. A1 lead capture design (2026-09-01) — feasibility verdict

• ANDROID companion (Phase 4, internal sideload APK): (1) ACCESSIBILITY service + floating "capture lead" bubble over any app → reads the ACTIVE WhatsApp chat bubbles as TEXT (no OCR needed for chat) → parse → deep-link into PWA /leads/new?draft=… with prefills → confirm taps; (2) NOTIFICATION listener → incoming-message pattern → AUTO-draft a lead (sender + text + media flag) → user opens & confirms; (3) MediaProjection SNIP overlay (user's original vision) for IMAGES (price lists, slips) — OCR + clarify flow; per-use consent prompt on modern Android.
• iOS: no public cross-app screen capture → native screenshot + SHARE SHEET to the app (image never lands in the gallery) — acceptable fallback.
• WhatsApp WITHOUT Business API: OCR-free paths above need NO API. unofficial libs (whatsapp-web.js) REJECTED for the company number (ban/loss-of-history risk; only ever on a throwaway number). Business API only when lead volume/outbound automation justifies (per-conversation cost is low at low volume — the overhead is setup, not pricing).
• Draft+confirm is the universal pattern: capture → detect type (enquiry/confirmation/…) → ask "use this message?" → prefill → confirm.

16. DESIGN PHILOSOPHY + A1–A4 refinements (2026-09-01, round 16)

Philosophy (applies to EVERY design)

• The system must BE part of the work — entry happens IN the work, at the moment of work; a user who does the work and records it separately (before/after) stops doing it. A screen's value to the USER comes first; its management-report value is derived, never the reason the user enters data. If a step in the real work can only COMPLETE through the system, adherence is automatic ("user cannot finish their work without it").
• Leads are the canonical case: capture must be FULLY automatic — the user has no entry role; anything less leaves the lead form dormant.

A1 — AUTOPILOT capture (always-on, zero user action)

• Companion (Android, company device — no privacy concern): NOTIFICATION LISTENER always-on (system restarts it): new WhatsApp message → pattern detect → auto-draft lead. No screenshots, no polling, no button. The a11y floating reader stays for full-chat context + images (manual, rare). "Always reading the screen periodically" is NOT needed — the notification event IS the trigger (reactive, not polling).
• Limits to design around: notification text = first line(s); media in notifications has no content → image-forward path (share target) still exists; full thread context enriched via a11y read when the draft is opened; multi-SIM/profiles noted.

A2 — costing/quote/rates

• Costing app screenshot PENDING (owner to upload) — sheet already decoded (COSTING.md). Costing must support MULTIPLE warps + MULTIPLE wefts in one construction (W1/W2… with % split — sheet has the rows).
• YARN RATE BOARD entry form (procurement manager): upload rate lists + WhatsApp msgs (share target) → OCR → CLARIFY confused rates (excl/incl GST, mills, spellings) → approved rates per count/ticket per day → feeds quote prefill + trend. (Phase 1.)
• UPLOAD HASSLE fix — Web Share Target: the PWA registers as a share target, so FORWARDING from WhatsApp/photos shows "our app" in the share sheet; chosen with a destination FORM (rate board / quote / gatepass / checking slip…). No file browsing, no filename memory. Desktop: drag & drop plus PASTE-from-clipboard. (PWA manifest share_target + /attach route.)
• QUOTE output: printable + SHAREABLE AS MESSAGE and PDF (WhatsApp share via Web Share API; PDF server-side via weasyprint). LAST-QUOTE panel on the quote form: previous quotes for this design AND this party (date, rate, the exact costing inputs, then-current yarn prices) — cross-check to prevent costing mistakes. NUMBER FIELDS use suggestive TAP-TAGS (common values) first; typing is the last resort (global rule).

A3 — append-only, no edit/delete (APPLIES SYSTEM-WIDE)

• No edit/delete UIs. Corrections and all updates happen through APPENDAGE forms (new event; e.g., sample follow-up is its OWN form days later, order amendment is its own record, returns/movements are events). Audit log of every entry; backend may collapse into one table with history, but front-end NEVER exposes edit/delete. Only genuine-mistake corrections via a logged appendage (reverse event), never a silent overwrite.

A4 — order from the quote (natural flow)

• Quote screen carries "CREATE ORDER" — all fields prefilled from the quote (design, rates, party, terms). The quote is shareable as msg/PDF containing an IN-APP LINK (auth-gated) that opens the quote for any authorized user → one tap "create order". The party/customer has no system access; the link is for internal staff closing the deal.

17. A4 corrections + costing app decode (2026-09-02)

• TRADING SO: qty ALWAYS IN MTRS (beams only for job-work); DROP total- mtrs + total-taga fields from the order form; amendments via appendage.
• JOB-WORK intake: NO quote; the BROKER'S CONTRACT CONFIRMATION is forwarded (share-target) → OCR extract → prefill → confirm; tolerance and amendments via appendage. (A5 = confirm-time handoff: requirement calc / yarn-expected / park-lot; A6 = event-driven status + hishob flags — both SYSTEM-ONLY, no entry, no manual status.)
• Costing app decoded: 4 warps × 4 wefts (count/%/rate/GST/incl toggle), Majuri (weaving labour) line, margin table 1–20%, per-warp sizing rate, warp-division Pr/Me ? — same engine; COSTING.md §6b.

18. A/B refinements (2026-09-02)

• STAGE A: add the PRODUCTION ORDER (stock & sell) — an SO-shaped order with NO customer; drives yarn/beams/looms; sells later from FG stock.
• B0: pending-references-first UX (order/JW/prod-order + approx beams pending → planner taps) → select #beams → tap EMPTY-on-floor beam nos; transport + VEHICLE NO. Beam REASSIGNMENT (cancelled order → different contract) and SIZER→SIZER TRANSFER: intimation forwarded to receiving sizer (like yarn GP); receiving sizer collects empty beam; beams then received under new contract/new sizer/both.
• B1 booking: one PRODUCT selector (e.g. a count+type+ticket combo in a single field; backend splits); LOT NO (from gatepass) on inward; warp| weft tag moved HERE (not inward); inward = INTERNAL/AUTOMATIC form (generated when gatepass picked + barcodes applied, or on external receipt confirmation for direct deliveries — user touches only LOT NO).
• ALL goods movements in/out carry VEHICLE NO (now: guard camera OCR of the number plate, typed fallback; driver FACE/biometric = future door access control — guard eliminated; very-later phase).
• G4: partial/all dropped (already covered by pickup in G2). GLOBAL UX rule: on NEW ENTRY the screen lists PENDING REFERENCES first (contracts for beam-out, GPs for gate-in, ...). G0/G0b/G2 signed.
• B6 weft inward mirrors B2 (internal, from GP/confirmation, lot no).
• B5 = movements of stock WITHOUT buy/sell documents (ownership flips, re-marking between contracts, returns, weft-out) — the exception ledger.
• SIZING SHADE RULE: a sizing set's warp must come from a SINGLE yarn LOT (no shade variation) — enforced at tippan/sizing-issue.

19. Outward & sizing-receipt unification (2026-09-02)

• New form: YARN OUTWARD GATEPASS (premises → external party) — planner selects barcodes/beam numbers, guard taps exits, receiver confirms.
• C1 tippan ALSO serves as the OUTWARD INTIMATION for beams + warp (when warp is at factory premises).
• C2 simplified/summarized: outward is UNIFIED — planner PRE-ASSIGNS the beams/barcodes (in the tippan/outward GP); the GUARD ONLY TAPS each as it exits + reconfirms; no other fields.
• All outward intimations marked DUE-FOR-COLLECTION appear instantly on the TRANSPORTER screen (beam numbers + boxes to lift).
• C3 sizing receipt = TWO steps: (1) beams-in gatepass (mtrs/beam, ends, quality — OCR assisted); (2) full sizing reconciliation + winding-yarn details (arrives later — OCR assisted). After the FINAL hishob, the system ALLOWS creating the WINDING-YARN GATEPASS → issued to the winder to pick up yarn from the sizing.

20. Printing/share + confirm-links + beam card (2026-09-02)

• GLOBAL: every goods-movement document (gatepasses, intimations, outward/ inward slips, checking report, quotes) is PRINTABLE and shareable as a soft-copy PDF. ALL goods movements get EXTERNAL CONFIRMATION via WhatsApp — a TOKENIZED CONFIRM-LINK in the message (/confirm/): the external party opens, sees the summary, taps confirm (optional photo); NO login/account needed. Interim = plain link in any WhatsApp msg; Business API later formalizes the channel.
• BEAM CARD (physical photo decoded): Beam No · Flange No · Sizing Set No
  • Sizing Name · Contract No · Party · Loom No · Warp Count · Weft Count · Weave · Cuts · Total Mtrs, with TRACKING columns: Beam Meter → Woven Fabric → Shrinkage → Card MTR (balance). (Screen fields were already in FIELDMAP/Beam Card; physical print confirms + adds tracking columns.)

21. D-scope + AIRTIGHT + mobile standard (2026-09-02)

• D1: planning-board details DEFERRED to production-time design (heavy back-and-forth there); not locked now.
• D3: OUT-HOUSE SECTION on the planning board (separate, mirroring ours) — per weaver-machine: loom nos; ROUNDER captures DAILY directly: remaining warp on beam (machine display), mended mtrs READY FOR CHECKING; checking report references those mtrs; whole loom captured daily by rounder or planner. Leak-plugging by design (every out-house meter has an owner).
• CLOSURE DISCIPLINE (airtight): every mention/idea/pending point is logged and CLOSED — the shelf (§13) is the ledger; items move to closed as they are answered; nothing disappears. New standards: MOBILE-FIRST for everything (owner flags anything not), EVERYTHING WhatsApp-shareable.
• Next inputs from owner: (1) THIS session — all gatepasses & dispatch slips from the current system (format samples — OCR intake); (2) NEW session — all existing reports + discussion of new reports & live dashboards.

22. Reports & dashboards plan (2026-09-02, round 22) — the reports freeze begins

• New working doc: docs/REPORTS.md — the full report catalogue + the valuation decision brief. Report groups:
  • Operational documents (R): booking/PO, gatepass + in-out challans, sizing tippan, beam card, checking report (out-house; in-house graded at MENDING), dispatch slip (role-based copies), quote, contract/SO print.
  • Hishob & reconciliation (RL): yarn hishob (ledger = statement), yarn hishob difference (B5 partial-cone settlement), job-work hishob per contract (A6 flags), sizer/winder/weaver reconciliations, stock-take difference. Reconciliation formats still PENDING from owner.
  • Stock/planning/production (L + export): yarn stock statement with LOCATION, FG by grade, beam in-flight, Daily MIS migration (16 sheets → tiles + CSV), daily efficiency register (read-only live table), beam-end changeover/downtime, open POs/SOs + delivery position, procurement need, order book vs capacity, party-wise delivery performance.
  • Financial hooks (later): Tally voucher exports (G1, per BRIDGE contract; GST config per supplier pending) + broker kept-brokerage statement.
• Valuation decision brief (REPORTS.md §7) — prepared, owner signs the default:
  • Scope: stock & sell trading FG lots only; against-order = direct P&L per SO; job-work = service on party material (never valued into our stock).
  • Lane cost = yarn actual (booking/gatepass + freight) + conversion actual (sizing + weaving + checking/mending), stored per lot, never aggregated away.
  • Recommendation: implement both FIFO and weighted-avg as computed views over per-lot lane costs (the method is a report choice, not an architecture decision); formal P&L defaults to weighted-avg per design-quality (Tally-aligned, safe day-one), FIFO as the comparison view. Seconds/bales valuation waits on the grade-pricing decision (§13 p.11).
• STATUS.md NEXT AREA now points here; DASHBOARDS.md §3 catalogue seeded (was "uploads pending"); each catalogue point is signed off as owner input lands.

23. Reports philosophy + step-by-step review (2026-09-02, round 23)

• Owner's binding rules (rewrote REPORTS.md §1):
  1. No report silo — every report/dashboard is placed at the workflow step whose decision it supports; no separate Reports menu.
  2. A report is the finished product — anything needing further processing (Excel pivot/calc) is a dump, not a report; dumps exist only as labelled utility exports (form listings + filters).
  3. Exceptions are reported where they occur (in-system queues, tiles, diff columns at the step's own screen).
  4. All approvals happen in-system — hishob accept/object, amendments, reconciliation acceptances, waivers, rate renegotiations; the user leaves the system only to communicate with external parties, and confirmations return via tokenized confirm-links (round 20).
• Two uploaded reports decoded (reports/, also downloadable):
  • Job-work hishob — "In/Out/Consumption Statement" (REPORTS.md §2.1): per-contract sections beam-inward (with knotting-less + shrinkage%), yarn opening/inward, colth outward, yarn consumption at STANDARD rate (mtrs × engine per-mtr req; verified 3710×0.095139 = 352.97), per-set SUMMARY → balance = the hishob difference; its "inform within a week = accepted" remark becomes the in-system hishob-pending → sent → party accept/object → accepted flow at the contract (A6).
  • Actual vs standard yarn consumption (REPORTS.md §2.2): proves why every weft cone is barcode-issued (actual per-design consumption is otherwise unknowable); rebuilt differently — a live per-loom/ per-beam consumption tile at D2/D3 (issue wt vs engine standard, diff), exceptions flagged in-system (mtrs-without-issue, issue-without-mtrs, standard=0 = design-master gap, stock-take diff); period rollup = download of the tile, never a 4-page dump.
• Step-by-step cadence confirmed: per workflow step we settle (a) reports/dashboards placed there, (b) exceptions, (c) approvals. Stage A reviewed in REPORTS.md §3 (A1 leads → A6 hishob: procurement-need tile at A2, amendment approvals at A4, park-lot aging at A5, hishob accept/object at A6); stages B–F carry initial placements only, each to be reviewed at its step.
• Shelf §13 p.2: job-work hishob statement sample RECEIVED (format decoded); the received hishob slips for OCR intake still pending.

24. F1/F2 — dispatch pre-slip & loading (2026-09-02)

• CONFIRMED owner assumption: the DISPATCH PLAN (F1) IS the pre-slip — created EARLIER (e.g. previous day), the office MARKS which graded rolls/lumps go out against the order (balance visible). The pre-slip appears on the TRANSPORTER's and GUARD's due-lists instantly — they LOAD against it (tap-load each item 【SC/T】); on load COMPLETE + confirmation the FINAL DISPATCH SLIP is generated (actual rolls/lumps, per-piece mtrs & weights, vehicle/LR, copies, status). Deviations vs the plan are reflected in ACTUALS with the tolerance check. Same pattern as every outward: plan → due-list → tap → final document.

25. Paper vs system approval + physical templates (2026-09-02)

• RULE: printed gatepass + physical (stamped/signed) approvals exist ONLY when goods cross OUR boundary to/from EXTERNAL parties (trader, sizer, weaver, buyer). INTERNAL movements (between departments, godown↔gate, transporter while goods are in our custody) use SYSTEM approval only — intimation → due-list → tap → confirm; NO paper gatepass. (Supersedes the round-20 blanket "every movement prints": scope = external boundary.) Such external docs also share as PDF + tokenized WhatsApp confirm-link.
• PHYSICAL TEMPLATES decoded (7 PDFs — REFERENCES; we design BETTER versions, not copies): job-weaving contract (T&Cs: job rate subject to 93-95% beam-running efficiency; additional unconditional job rate on warp/sizing problem; sizing/warp complaints handled by trader; weaver not liable for sizing/warp damage; Wastage 5%; Reed On-Loom / Pick On-Table; Selvedge Type per design paper) · beam-out sizing GP + beam return GP (2 copies office/customer, GSTIN header, GP no+date, party/ sizer/transport/vehicle, FLANGE nos, By/Remark, receiver signature) · yarn return GP (set no, ticket, count, wt, bags, cones) · job-work packing slip (per-piece: piece no beam-piece, L No = loom, roll no, meter, weight, grams/kg-m; P.Contract No) · trading bale dispatch slip (bale no + party ADDRESS printed on bale label, roll rows, totals) · bale insert slip (bale no, quality, roll rows, totals, signature).
• VERIFIED: Rate = JobRate(paisa) × Pick — real print: 8 paise × 84 = ₹6.72/m ✓ (also matches the costing sheet's 64×9ps=5.76).

26. Universal dumps + buggy-source caveat (2026-09-02, round 24)

• Standing caveat: the existing inventory system is buggy and haphazardly built — its numbers and formats are taken with a grain of salt; everything derived from it (incl. the two report uploads) is indicative; verify before trusting; ask the owner when unsure.
• Universal dump station is a MUST (new doc docs/DUMPS.md): EVERY form dumps its raw records to Excel/CSV with filters drawn from the form's own fields (date range always; party, quality/design, status, and per-form keys — set/beam/lot/loom/vehicle…). One Dump section indexes all forms; an Export action also sits on each form's list screen (no-silo rule). Dumps ≠ reports (raw, labelled "DUMP — not a report") — they cover the long tail of analysis without prebuilt reports.
• The dump loop: a recurring dump export signals a missing in-system analysis → build it as a placed tile/report → the recurring export retires (raw dump stays available). Dumps are the sensor for what the team needs next.
• A form without its dump is not done (build checklist item); role-gated (office/owner full; floor roles their own forms' dumps); as-of stamps + filter echo on every export.

27. Section-A dashboard design v1 — the BOARDS pattern (2026-09-02)

• Pattern (owner's brief, applies to every section): each workflow section gets ONE main dashboard; each component shows major points and links to a sub-dashboard; sub-dashboard components link to the dump export of that step (filters inherited from the component context) and a WhatsApp share with an in-app link to that view; exceptions needing approval get the approval flow, other items get a reasoning thread (append-only, @mentions); every action is triggered from the dashboard; users never leave the system (external parties: confirm-links only).
• docs/BOARDS-A.md v1 (new) — Commercial board: main components = Pipeline · Order book · Procurement need · Job-work & hishob · Samples · Hand-off risks; Attention bar on top (everything needing action today = the trigger surface). Sub-dashboards A.1–A.6 with analytics, exceptions
  • approvals (amendment beyond tolerance, hishob send/accept/object, sample waiver, PO spend threshold), dump + share per component.
• Brain-jog extras staged (§5): promise-drift timeline, rate-trend sparklines, quote-accuracy KPI, hishob response stats, brokerage split, dhara prefill coverage, order-book what-if slider.
• v1 is a jog — owner fine-tunes must-haves, then Section B follows the same pattern. Blocked-on decisions noted (§4): numbering, promise-vs- target definition, grade pricing, valuation, Tally dues.

30. Dashboard standards wave (2026-09-02, round 30) — what changed

• Table standard: every dashboard table = click-to-sort any column, per-column search, filters (DASHBOARDS §5.1).
• Period control: every dashboard has from–to dates; tiles state their period; stats are period-bound (§5.2).
• Status axiom: NO manual statuses anywhere. Workflow-derived / aging-derived / system-prompted (a personal-dashboard task "no update in N days — reply with reason"; the reply IS the status + logged reasoning) (§5.3). Leads/samples get prompted tasks, never manual dropdowns.
• Personal dashboard per role: components from all sections + todos strip on top (approvals, chats, OCR confirmations, prompted replies, hishob actions) (§5.4).
• Record chat: the "Reason" button becomes an inbuilt per-record chat thread (@mentions, attachments, append-only); mentions surface in the member's personal dashboard (§5.5).
• Report AI bot: ever-present on every screen; queries all historical data, generates custom reports, save as reusable template (§5.6; Phase 4/5, dump loop feeds it).
• Three mindsets: job-work / SO / stock-&-sell = tabs of the same commercial screen (own context, own KPIs); function boards (procurement, stock, capacity, check-dispatch) stay common (§5.7).
• Drill-down UX endorsed (owner asked): one common dashboard set with 2–3 layer drill-down that ends at the form/entry — bird's-eye → section → row → work. No per-flow silo dashboards (§5.8).
• Working-capital cycle board: stock pipeline (beam-on-floor → … → ready-dispatch) with avg days per stage, total days, vs target, good/bad diff + system-identified candidate reasons, employee-KPI hook (§5.9; mock A.7).
• Order-book must-shows (§5.10): sold → delivered + pending; ready- but-not-dispatched by stage (under mending/checked/packed/ready); dead stock w/ aging; no-order stock. No approval on delivery release (owner: no micromanaging — release is a workflow action).
• Mock → v3 (/board-a.html): period bar, #me personal dashboard, #dump dump-station screen, #a7 stock cycle, AI bot bubble; A.1 margin potential; A.2 redesigned (ready-by-stage, dead stock, Promise-vs-Plan); Reason → Chat.
• Removed from mock/UI: "delivery release approval", "83% load" jargon (replaced by defined "capacity booked %" advisory), "drift" (→ Promise vs Plan = overdue days).

31. Yarn identity = count/denier + TYPE + ticket (2026-09-02)

• YARN TYPE field everywhere (booking, inward, movements, tippan, cones): cotton = KW (karded), CW (combed), CCW (combed compact), KCW (karded compact); POLYESTER = denier (Dn) instead of count; other yarns extend the enum. Natural phrase = "61 CCW Sanathan" (count + type + ticket) and "150 Dn Bhilosa" (denier + Dn + ticket). The single product selector is built FROM these three parts (backend splits), and the type travels with the yarn through all stages.
• count-system flag: cotton → Ne count; polyester → denier. Costing adds the denier branch (kg per 1000 m = denier/9000).

32. Master dashboard + data-provenance comments (2026-09-02, round 31)

• Load (capacity booked %) is a KEEP — owner confirmed after the explanation (advisory: stop over-committing beyond a set %).
• Data-provenance comments are binding (DASHBOARDS §5.11): every dashboard component carries What · Data · Who enters or System-calculated, on hover and pinned via ⓘ; every mock ships with them (review aid + future help text).
• Master dashboard review: section-wise review stopped — the whole dashboard is built in ONE file (static/board.html, /board.html): company + working-capital cycle + all sections A–F + per-user personal dashboards (owner + role examples) + dump station + AI bot + one example dashboard→form drill (dispatch pre-slip). Owner reviews it at once and finally picks each user's composition.
• UX question raised (owner thinking): is data entry done only from this dashboard tree? Recommendation pending confirmation (DASHBOARDS §5.12): one dashboard tree whose deepest drill IS the form (scan/tap/approve/chat); no separate menus; personal dashboard = landing.
• Anti-overload rule added (DASHBOARDS §5.13, binding): staff must not be overwhelmed — default surface = 3–4 obvious numbers per component, everything else behind "Details ▸"; short explainers on hover, full text behind ⓘ; personal dashboards minimal; master dashboard is owner/superuser review view only. Applies to every mock and screen.

33. Migration planning (2026-09-02, round 35) — new doc docs/MIGRATION.md

• New working doc: docs/MIGRATION.md — the migration plan from the existing myTextile Inventory System (job-work + trading modules) into this platform. Planning layer only (per the session's NOT-TO-DO): no schema work, no production build, no direct DB/API access to the old software — the ONLY intake is the owner's own backup file, uploaded to /upload-backup (round 34 drop; lands in backups/, gitignored), scraped read-only; raw SQL allowed only inside migration/extraction tooling, never application code.
• What MIGRATION.md contains: (1) the old system as known today (menu/Utility catalogue, document spine GP/PS/Booking/Contract/ Inward-Outward + Transfer-Year FY tag, ledgers already present — yarn hishob, cal/cone math, winding reconciliation, used-kgs — and the known cruft: double-entry across modules, manual statuses, Less Meter/Taga dropped, N.PartyName, Excel date serials, print-duplicate sheets); (2) phased migration per ROADMAP slices with S/B/H planning defaults (masters S; yarn stock ledger S — the heart, opening balance printed+signed; PO/SO B first, then S; beams/WIP B/S mix; FG stock + dispatch S; weaver ERP B; samples/leads greenfield); (3) old→new data-mapping tables per domain incl. the drop list; (4) opening-balance items at cutover (yarn own+party with location, open POs/SOs/job-work contracts, in-flight beams, WIP, FG by grade, yarn/weaver accounts, ₹ party balances = Tally-side only, numbering continuation); (5) backup-scrape workplan — what the sample backup yields (tables/columns/volumes, form→table map, cruft list, numbering evidence, cal-wt proof, GST config, FG date span); (6) migration dependencies = the parked decisions (valuation, numbering, GST, LTOL/UTL, cal-wt, grade pricing, "Booking Entries", reconciliations, D1, promise-vs-target) — listed as gates, not decided here; (7) open questions for the owner.
• Owner asks (shelf → §13 additions): (a) upload the sample backup to /upload-backup (zip if folder) so the scrape can fill the mapping with evidence; (b) history depth — live state + current FY vs full history (recommended: live state + current FY, older years archived); (c) is the Daily MIS workbook app-generated or parallel manual Excel? (decides migrate vs retire); (d) numbering continuation; (e) party ₹ opening balances migrate or start clean; (f) parallel-run start point — suggested yarn stock ledger first (highest duplication pain); (g) old systems read-only→archive expectation.
• Standing caveat applies: old-system numbers/formats are indicative — every mapping is verified against the real backup before any import.

37. Capacity calendar + planning-based cover (2026-09-02, round 37)

• Capacity & delivery commitment page (mock /board.html #cap): "14/18" clarified → explicit "booked / free" per loom class; outsourced loom capacity included; calendar (weeks/months) of in-house vs outsourced capacity vs committed (SO + stock-&-sell); over-committed week → "+ Outsourced JW contract" button (quick contract page #ojc: weaver, machines, mtrs prefilled, expected production-start days — floor 15 days from today when no contract exists; delivery tolerance ±N days asked at contract creation). Next-order fit calculator: mtrs + lot/tag size → production-start week, first-dispatch, delivery frequency by lot size, end week — so delivery can be committed BEFORE taking an order. Dispatch plan vs actual variance table vs the order section.
• Cover days v2 (#cov): full yarn names (30 CCW, 60 CW, 80 CCW, 20S OE); click a yarn → contract-wise consumption sub-rows; cover uses PLANNED daily use (rise + date shown, e.g. 327→520 kg/d from 12-Sep when SO-221 starts); Create PO button per yarn.
• Every sub-dashboard carries a from–to period bar (JS-injected on all component pages).

25. Contract/outsource/SO/sample refinements (2026-09-02)

• OUTSOURCED-WEAVING CONTRACT = its own order kind, intake via the SAME drill as the broker contract: forward → OCR → prefill → confirm (T&Cs modelled from the contract sample: efficiency-linked job rate, additional unconditional rate, liability clauses). Shows up in PLANNING (out-house section, D3/D1) and drives the SIZING TIPPAN (weaver + beams, C1).
• SO MODE flag: make-to-order | stock & trade — PREFILLED per QUALITY (quality master carries the typical mode; user confirms).
• SO LOT SIZE: mtr per roll/bale + number of rolls → lots per contract (computed); remembered per PARTY + QUALITY and prefilled on the next order (context memory).
• SAMPLE REQUEST form: captured by the capture UTILITY (forward/ notification) → PREFILLED → user approves → sample issued against it (from sample stock or woven on order); follow-up stays its own form.

38. Capacity Gantt + WhatsApp follow-ups + sample requests (2026-09-02, round 38)

• Capacity (#cap) → horizontal BAR chart (Gantt): X = days with weekly ticks, toggle days/months; rows = 190-class / 250-class / outsourced weavers; committed blocks as bars, free = empty; click a 190/250 bar → machine-wise drill-down bars. Over-run weeks keep the "+ Outsourced JW contract" path (#ojc: weaver, machines, mtrs, expected start days, floor 15d, tolerance).
• Next-order plan = pick a QUOTE from the pipeline (L-195/L-192/L-188): plan draws the full chain on the calendar — production start (≥15d) → weaving (9.8d avg) → mending/checking ≈3d → packing 1d → first dispatch date, then weekly lots (tag size) until end. Order-section comparison stays in the ORDER dashboard (removed from capacity).
• Pipeline (#pl): 📲 Follow up opens WhatsApp straight to customer/broker's number (wa.me/) on every row; leads without a quote get 🧮 Quote (costing) → #quote page (engine lines verified, margin table 1–20%, share quote on WhatsApp, Create Order).
• Procurement (#proc): yarn rows expand → contract-wise demand sub-rows (same drill as cover days), Create PO per yarn.
• Samples (#samp): requested-but-not-yet-sent bucket (R-06/R-07, "📦 Mark sent" + 📲 follow-up), sent/awaiting, results; charge waiver is the team's right — direct action, no owner approval (owner).

26. Sample → courier dispatch leg + charge rules (2026-09-02)

• Sample REQUEST auto-creates a DISPATCH INTIMATION (sample leg of the dispatch pattern): packed → RUNNER due-list (picks up from factory) → courier to party with party details PRINTABLE as a courier STICKER; the courier-office RECEIPT is OCR'd (receipt no + courier name) → tracking on the sample record.
• SAMPLE RATE prefilled from the quality's RECENT ORDER rate (user confirms); new quality/no history → the user is asked.
• CHARGE rules: user can waive up to ₹1000; beyond that requires OWNER approval, else the charge goes to BILLING (Tally adapter).

39. Samples/samples + hishob L2L + prod-start promise + SS vs stock + interest (2026-09-02, round 39)

• Samples: "Mark sent" button removed — the send flow lives in the sample dispatch form (courier intimation → runner due-list → receipt OCR); samples page only shows statuses + 📲 WhatsApp follow-up; waiver is the team's right.
• Hishob (is a REPORT — answered): it is a generated statement, not an entry form — nothing is typed; Download PDF / Print / Send-confirm-link live on the statement screen and at the contract. Added L2L/lasa (sampled), beam mtr (sizing/production), knotting-less + shrinkage % to each contract row (the decoded upload format). Auto-remove rule: a contract leaves the list when nothing is pending (yarn received/given/transferred to next contract and statement balances).
• Production start promise vs expected (#pd): per order/contract — promised start (at confirm) vs expected start (plan/capacity/readiness), delay + system-flagged reason (planning backlog, sizer delay, looms, party weft not given blocks JW start); delays drive #cap + order variance. Card on D·Weaving.
• Stock & sell (#fg): SS SOs ↔ assigned FG (short/excess), plus free-floating FG ready-but-not-dispatched by stage (mending/checked/packed/ready) — the idle-ready leak.
• Sell list (#sl): dead-stock table now carries running interest cost — 1% per month of working capital on the value, and Resultant cost; total column shows the monthly burn — the sales tipping point (what discount to accept before holding costs more).

40. Migration backup scrape — first pass (2026-09-03, round 40) — docs/MIGRATION.md §10

• The sample backup arrived and was scraped read-only (backups/, never committed): myTextile-Data-20260826-181752.zip → one … .bak, 392 MB raw.
• Format verdict: it is a Microsoft SQL Server backup — logical DB MY_Textile, originally the vendor demo CB4Demo on 32-bit SQL Server 2005 (Windows box). SQL Server does not run on this ARM Pi → a .bak cannot be parsed here; the only practical intake is file exports from the Windows machine (SSMS/bcp table exports, or the app's own Excel export) — consistent with BRIDGE.md, no new integration. The .bak is kept as the archive record.
• What the read-only scrape extracted (object names + data fragments from the DB pages — no credentials involved):
  1. The app's forms bind through usp_BIND_* procs → the real form→table map (FIELDMAP screens confirmed field-for-field: Booking/BookingEntriDetail = yarn PO, SOMain/SODetail = SO, ContactMaster = parties, QualityMaster/DesignMaster = quality + construction, Gatepass, YarnInward/Outward/Transfer, WeftIssue/ InwardWeft, SizingRegister/Receipt/Tippen, WarpingTippen, InwardBeam/ReturnBeam/BeamCard, ProductionDetail, DailyEfficiency Register, Rolling/Mending/Folding, BaleSlip, OutwardPackingSlip, FabricPhysicalStock, YarnHishobDifference, accountLedger + Cash/Cheque/PaymentReceiveByCheque…). Full table in MIGRATION §10.2.
  2. Cruft confirmed (skip at import): tmpbale, tmpSizingStock, XtmpLastYearBalance, Table_1, *Old tables, person-named procs (ProductionPlanningSawant, OutwardPackingSlipBhoje, Hawal, Vadinge), payroll/incentives/mill-store tables (out of fabric scope).
  3. Data facts: FY history 2015-16 → 2026-27; column spine camelCase …Id/No/Wt/Per/Amt incl. igst/sgst/cgstPer/Amt, tagaNo, setNo, beamNo; dominant mill SANATHAN; payment modes NEFT/RTGS + bank list; machine-flange combos in rolling rows.
  4. 120+ usp_rpt_* report procs = the old Reports menu, as catalogue evidence for the reports session (not touched here).
• "Booking Entries" evidence (parked decision, NOT decided): the menu maps to the Booking/BookingEntriDetail/BookingQualityMaster table family (= yarn booking/PO) — owner confirmation still pending.
• Next ask (owner): table-level exports for the MIGRATION §10.5 priority set (masters, bookings, SOs, gatepasses, yarn physical stock, hishob difference, beams/beam cards, FG stock, bales, weft issues — current FY OK for movements), zipped, to /upload-backup → then row counts, column types, and opening-balance extracts become exact.
• No parked decision was finalised; reports/dashboards docs untouched; the file itself stays out of git.

40. Day-end weft consumption + JW weft cover + saved-weft transfer (2026-09-02, round 40)

• Actual vs standard weft consumption (#wc): NOT live — updates AFTER DAY-END (weft issued once daily to all looms; window = 24 h from issue). Count-wise summary at the bottom exactly like the uploaded sample (page 4: 60S +410.90, 20S +379.45, 20S-SLUB std=0 gap, total −3,594.47 saved) with sub-row drill per count → party/design rows (the reusable drill pattern).
• To-buy card removed from B·Yarn (procurement covers it).
• JW weft receipt cover (#wf): per PARTY — weft stock, daily use of RUNNING qualities, days of cover, danger level (<5d), 📲 WhatsApp replenish (pre-typed message to party incl. "0d — blocked" for C-14); sub-rows per party → quality-wise running consumption.
• Contract-end saved-weft transfer (#py): at contract end, target vs actual saving + variance; the system suggests the transfer (yarn + kg) netting CROSS-PARTY usage (this party's yarn ran on other party's looms and vice-versa); user confirms → system executes the logged yarn-stock-transfer to factory (owner) account. Reasoning thread per contract (target vs actual discuss).
• Previous hishob PDFs: dump station gains "hishob statements — PDF ARCHIVE" with filters (party, contract, status history incl. closed/accepted/objected-resolved, period) + PDF format; old statements downloadable for records. Current statements are one-click from #hi.

41. C/B detail pass (2026-09-02, round 41) — "reports were lacklustre"

• Beam book (#bi): position counts — EMPTY 12 · FILLED on floor 9 · AT SIZING 9 · AT WEAVING 6 · SENT FOR REPAIR 3 · PARTY-TO-EMPTY 2; plus pending outward intimations (planner-assigned → guard tap from due-list; transporter sees them instantly).
• Sizing (#sj): two tracks — pending sizing tippans against SO/prod-order where warp yarn is assigned (draft → confirm), and sizing done but reconciliation pending (beams-in gatepass OCR vs full recon + winding-yarn slip; used-kgs = issued − returned − leftovers).
• Yarn (#ys): direct deliveries pending confirmation (intimation → sizer/premises confirm, WhatsApp "ask confirm") and gatepass endorsed/issued pending external confirmation (GP-85/84 delivered → confirm-link reminders), until reconciled.
• Winding (#wd) detailed: per lot — bags/cones sent, re-wound cones received, empty bags + ring weight, WASTAGE % vs target (2%), diff net/gr, recon status; over-target lots stay flagged until the winder explains; monthly wastage card.
• Owner: "the further down I go the reports were lacklustre" — depth standard raised for C/B; pattern applies everywhere (each sub-dashboard carries its full operational detail + exceptions + actions).

27. One-go build + dashboard-first UX (2026-09-02)

• STRATEGY: whole system built in one go (no feature-phased releases); stage lists in ROADMAP become internal build order only. Guardrail: internal RUN-TEST window on real data via bridges BEFORE the single cutover; then one flip.
• UX PHILOSOPHY: no Master/Transactions/Reports menu grid. Home = dashboard, attention-driven — the user's PENDING QUEUE per role: drafts-to-confirm (capture funnel), approvals (waiver>1000, tolerance, reservations, cut-beam), intimations due (guard/transporter tap-outs), park-lots, exceptions (reconciliations). Every action opens with its pending references; confirming a step CREATES the next-step card. Role homes; global one-tap jump/search; Forms section + dump station + report station kept as power-user shortcuts; context "ready-to-print/ share" buttons (hishob at last dispatch, etc.) appear in place.

42. Approval gates + beam drills + prod-mtr + loomgate (2026-09-02, round 42)

• Actual vs standard weft: added Production mtr (per count and per party/design drill rows; TOTAL 764,226 m matches the uploaded sample).
• Beam book: every position row drills beam-wise (empty/floor/at-sizing/at-weaving/repair/party-to-empty → individual beams); pending outward is SIZING-OUTWARD-wise (OS-31/32/33 = one load, many beams) with beam-wise drill inside.
• Hishob final approval gate: EVERY hishob — job-work, sizing, winding — needs the owner's final approval before print/send; approval releases the bill-hold, so an unapproved hishob blocks payment. Sizing hishob (PURLBEE/SAIRAM) + Winding hishob (ROYAL/SURAJ) tables added with locked/unlocked print.
• Sizing: new track — tippan issued but outward GP / delivery intimation NOT assigned (T-120/T-121 → assign outward).
• Loom efficiency: header now links the loomgate utility dashboard (machine-vendor analytics) directly; our aggregated + per-loom rows stay (adapter = D4).
• Planning board: details deferred to production-time design (owner).

43. Checking/mending/grade analytics + dispatch depth (2026-09-02, round 43)

• Packing % (fresh-goods share) KPI on mending, checking and grade.
• Mending (#mn): C/R rolls of the last 24 h WITH defect-master reasons + dispositions (mending→re-grade · wash · C→lumps · R→reject).
• Checking (#cq): queue (with source: in-house/weaver) · C/R 24 h with reasons · checking reports last 24 h — WEAVER-wise (report no, weaver, quality, rolls, mtrs, signatures incl. mending-head pending) and CUSTOMER/SO-wise (per SO, party, grade split).
• Fabric quality dashboard (#gm): grade distribution + packing% + C/R 24h; most frequent damages (TOP list with mtrs and share); LOOM-wise frequent damages (loom 11 hole/warp, loom 14 slub, loom 17 oil-stain…) and QUALITY-wise frequent damages (C/R% per quality) — damage lanes from the same defect-master chips.
• Dispatch depth: pre-slips carry rolls/kg/grade-split/vehicle; ready-not-out carries kg+grade; delivery-vs-SO carries m·kg by grade.
• Yarn (#ys): "Today's yarn movements (24 h)" — each doc (GP/DD/weft-issue) with yarn lot, qty, to/from, status.
• Owner: "from yarn make every sub-dashboard more detailed; I'll keep suggesting" — richness bar lifted; batch continues.

44. Dashboard spec frozen — production starts next (2026-09-02)

• Owner: "mota-mota we are there" — the dashboard design is SET after rounds 27–43 (all sections, all component pages, per-user dashboards, global rules). Consolidated docs/BOARDS-A.md = the DASHBOARD SPECIFICATION (pattern, inventory, rules, approval flows, metrics, per-user compositions, open decisions §8); the interactive reference is /board.html (mock = spec mirror).
• Production begins NEXT session per ROADMAP Phase 1 (foundation: masters, conversion engine, tenancy seams, event backbone, realtime board shell on bun:sqlite), built slice-by-slice with the dashboards as the entry surface (BOARDS-A §1, DASHBOARDS §5.12/5.8).
• Docs updated: STATUS (freeze + production), BOARDS-A (spec), REPORTS + DUMPS (new boards / hishob PDF archive / approval gates), and this log.

28. PRODUCTION-START requirements (2026-09-02, round 28)

• TIPPAN: may be created WITHOUT assigning GP/direct-delivery/outsourced- weaver contract — those references are OPTIONAL at creation, assignable LATER (draft-state tippan).
• APPENDAGE FORMS for ALL updates/deletes: no in-place edit/delete on any screen; every update/delete is an APPENDAGE (new record w/ before/after + reason + who/when). Includes dedicated update-appendage and delete-reverse-appendage forms per entity family.
• BEAM OUT FOR REPAIR: new beam movement via the gatepass system (intimation → guard taps → GP; return after repair).
• RECONCILIATIONS (given OR received: sizing/winding/weaver/hishob- difference): ALL require OWNER APPROVAL before they are applied/closed.
• JOB-WORK HISHOB: needs OWNER APPROVAL; ONLY after approval does the PRINT button activate (print + send to customer).

45. UI pass 01 — GrayFabric ERP reference shell (2026-09-03)

• Owner directive: "refer https://github.com/skpawar1305/gray_fabric_erp for UI". Scope agreed: shell + theme pass now (per-screen conversion to the reference component language in later passes), light sidebar (owner: no dark surfaces — Rule 1 theme rule untouched).
• Delivered: app shell (src/routes/+layout.svelte + +layout.server.ts) — grouped light sidebar (Intake / Orders / Yarn / Production / Desk / Tools) with lucide icons + blue active states, mobile hamburger overlay, user chip + sign-out in the sidebar footer; per-page duplicate chrome (home navbar identity/sign-out/quick links) removed into the shell.
• Theme re-skin (src/app.css, daisyUI pinned light --default intact): blue-600 primary, slate neutrals (cards white on slate-100), crisp 0.5rem radii, text bump (xs 13px / sm 15px), table row hover = muted wash + 3px inset primary bar (reference signature).
• Deferred (next passes): per-screen conversion to the gferp card/table/ form language, dedicated /login page, sonner toasts, component kit port (bits-ui etc.) if the owner wants pixel-parity later.

46. UI mandate — daisyUI for everything (2026-09-03)

• Owner: "add in documents that using daisyui components for everything is a must (only if it's possible)".
• Agreed: Repo rule 4 — every UI element uses daisyUI components (btn, card, input, select, table, badge, alert, collapse, tabs, modal, toggle, stats, timeline, …). Raw utility classes are allowed ONLY where daisyUI has no fitting component: app-shell sidebar/drawer scaffolding (+layout.svelte), icon rows, custom grids. Utility-styled UI that daisyUI can express is a defect — converted in the same change it is found.
• Written into: README (Rule 4), docs/STACK.md (house rules), AGENTS.md (mandate 8), this log.

47. Masters screen converted (2026-09-03)

• First screen moved to the reference component language (PLANNING §45 deferred work): /masters now matches the gferp masters pattern — page header, tabs, table-not-list, empty states with guided first-entry, labeled collapsible add-forms, live counts. All daisyUI (Repo rule 4); append-only untouched. Pattern to repeat on every list screen: header → tabs → table/empty-state → add-form collapse.

48. All screens converted to the reference language (2026-09-03)

• Owner: convert ALL screens (follow-up to §45/§47), with the correction that each page is designed per what it serves — not cloned from one template (docs/UIPATTERN.md "Design for the job").
• Delivered in one pass (§47 pattern + UIPATTERN doc as the spec, 6 parallel agents + direct work): every route now has the reference page header (h1 + subtitle) and no page-level navbar chrome; list screens (orders, bookings, lots, beams, gatepasses, samples, approvals, masters, checking) got tables in bordered cards + empty states + count badges; entry screens (orders/new, bookings/new, gatepasses/new, tippans/new) are form-first labeled cards with sections; queue screens (drafts, guard, transporter) are tap-friendly cards with big action buttons; docs = index card list + pure reading container. Append-only, light-only, daisyUI-only held everywhere (Repo rules 1/4, mandate 3).
• Bug fixed en route (pre-existing): /tippans/new crashed with a 500 — the assign-later card read data.tips[0] while the load never returns tips (latent since the solver round; the route was not re-verified). Fixed with optional chaining (data.tips?.[0]) — behaviour unchanged when tips exists; the "create a draft tippan first" guard now shows its alert instead of throwing. Verified: route 200 before/after on a fresh build. (The deeper question — whether the load should provide the latest draft tippan — is open; see §13 shelf.)
• Docs: UIPATTERN.md (the pattern spec), BUILD-LOG rev 8, STATUS. 44/44 tests green; build clean; 24/24 routes DOM-verified (h1, no navbar, table-vs-form structure per job).

49. Migration: docker restore attempt blocked + schema-grounded mapping (2026-09-03, docs/MIGRATION.md §11-12)

• Docker attempt (owner granted): mcr.microsoft.com/azure-sql-edge (SQL Server 2019 engine) exists for linux/arm64 — pulled and started — but SQL Server cannot run on this Pi: the machine boots a 16 KB page-size kernel (getconf PAGESIZE = 16384) and SQLPAL/jemalloc requires 4 KB pages ("Unsupported system page size"). Kernel-level property; no container/runtime/userspace workaround; emulation (qemu x86) rejected (startup risk, impractical on 4 GB ARM). Docker or not, the .bak cannot be restored on this machine.
• Consequence: table-level exports from the Windows box remain the only intake (SSMS/bcp, or the app's own Excel export) — zipped to /upload-backup; a 4K-page machine with SQL Server can also restore the .bak directly (logical DB MY_Textile, MOVE to MY_Textile.mdf/_log.ldf). The .bak stays as the archive record.
• Schema-grounded mapping (MIGRATION.md §11, new): old MY_Textile tables mapped against the built Phase-1 schema (schema-foundation.ts, 24 tables): ContactMaster/SupplierMaster → party; Quality/Design masters → design (+kg/m engine seed); YarnType/Item → yarn; Loom/Flange masters → loom/flange; Booking* + POMain → booking; SOMain → order(SO); ClothPurchase → order(OUTSOURCE); Gatepass → gatepass; YarnInward/Outward/Transfer + CompanyMaterial → gatepass + movement + lot (opening stock = lot rows); Weft → movement/lot; YarnPhysicalStock → lot; YarnHishobDifference → reconciliation; Sizing/Warping Tippen + Register/Receipt + InwardBeam/ReturnBeam + BeamCard + ProductionDetail → tippan/beam/evt; Rolling/Mending/Folding → roll; BaleSlip → roll(F); OutwardPackingSlip → dispatch_slip; FabricPhysicalStock → roll (FG opening); accounts/payroll/mill-store/ tmp* → H/archive. Old Main/Detail split → new header + JSON-lines pattern.
• Nothing finalised that is parked; no reports/dashboards/docs-of-other- sessions touched; only MIGRATION.md + this log + STATUS pointers changed (commit+push follows).

50. Dashboard slice — BOARDS-A finally implemented as the real home (2026-09-03)

• Gap (agent-diagnosed, owner delegated "you decide everything"): the dashboard-as-home was still the Phase-0 "Overview" scaffold (emoji sections, hard-coded cards, quick-entry strip). The frozen BOARDS-A spec (rounds 27–43) + its interactive reference (/board.html) were never built into the app — the biggest UI shortcoming left.
• Decision: build the BOARDS-A dashboard as the home slice, honest-first: every number comes from a real query; components that need later-phase data are visibly flagged ("data in Phase N") with the spec's What-Data-Who line — no fake numbers anywhere.
• Delivered: src/lib/server/board.ts (period parse + component queries
  • per-role composition); home = master dashboard (period bar · attention strip · section card grids · drill); /board/[slug] component pages (depth bar · ⓘ What·Data·Who · KPI stats · SmartTable · CSV dump); /api/dump?slug= CSV export per component; SmartTable.svelte (click-to-sort any column · per-column search · filter selects on enum columns); seed extended (graded rolls + a dispatch slip so E/F boards show life).
• Data-backed now: pipeline (drafts + open SOs), order book (delivered via slips), procurement-lite (bookings + free stock), samples, hishob (owner gate), party yarn, SS-vs-stock, sell-list (FG idle), yarn stock (own|party), park-lots, gate in/out (period-bound), beam book, sizing (tippans), recon register, check queue (rolls), grade mix, pre-slips, ready-not-out, delivery-vs-SO, capacity-lite (looms × beams on loom).
• Flagged not-ready (card present, shows spec line + phase): stock cycle, cover days, party weft cover (Phase 1.2 profiles), planning board, loom efficiency (loomgate D4), weft consumption (day-end issues), prod-start promise (calendar open), mending (defects data).
• Deferred (open): realtime SSE/WebSocket hub (board shell is snapshot-live on view now; realtime hub is the next Phase-1 slice); SmartTable standard rollout to the older list screens (adopted on board tables first); sidebar menu consolidation (BOARDS §1 no-fragmentation — shell still has Approvals/Dumps links); dump STATION UI (single-file dumps shipped); AI report bot.

51. Work-surface pass — UI for actual ERP use (2026-09-04)

• Owner feedback: "current UI is useless for an actual ERP". Agreed diagnosis (agent, from reading the shipped screens): the UI is a read-only document browser + KPI dashboard — list screens dump every row with no search/filter/ sort/pagination and rows are not clickable; entry screens use plain <select> party/design pickers; the append-only data model exists but the amend/approve/print verbs are not surfaced on records; the home page is a glance, not a work queue.
• Agreed scope (owner chose "All of the above — full work-surface pass"):
  • A. Finding records — per-list search/filter/sort/pagination (SmartTable standard rollout from /board/[slug] to the older list screens), click- through record detail pages (orders, beams, lots, tippans, gatepasses, parties, designs, rolls…), then a shell global search (/search?q=).
  • B. Work verbs on records — amend via the existing /api/amend from the record page, approval status + approve action where owner-gated, status transitions, print gatepass/challan/beam-card where the boundary is EXTERNAL (mandate 4); internal steps stay system-approval taps.
  • C. Desk density — compact list mode, totals footers (qty/amount sums, tabular-nums), batch select → print/approve where the flow allows, per-list CSV export.
  • D. Entry ergonomics — party/design typeahead combobox (code + name, not <select>), prefill-review summary before booking, duplicate detection (same party+design+date) as a confirm-tap, never a blocker.
• Constraints (unmoved): append-only data (updates happen only via amendment/approval/append events — no edit/delete UI, mandate 3); daisyUI-only (Repo rule 4); light-only (Rule 1); mobile-first with desktop density; per-point sign-off before each item ships; BUILD only via bun --bun node_modules/.bin/vite build; deploy only via deploy.sh.
• Order of work (each item = BUILD-LOG revision + build green + deploy + live-verify):
  1. List standard — shared ListToolbar (search input, filter selects, sort, pagination, totals footer, CSV) + SmartTable rollout to the list screens (orders, beams, lots, tippans, gatepasses, bookings, samples, hishob, approvals, drafts).
  2. Record pages + verbs — /orders/[id], /beams/[id], /lots/[id], /tippans/[id], /gatepasses/[id]: header (number/chips) + sections (terms · linked docs · events · amendments) + amend/approve/print actions wired to the existing append-only endpoints.
  3. Global search — /search?q= across party/order/beam/lot/tippan/ gatepass/roll numbers + names, reusing the list-search plumbing.
  4. Entry ergonomics — party/design combobox on all entry screens, prefill-review summary, duplicate confirm.
  5. Density + batch — compact mode, totals everywhere, batch print/approve, list CSV export.
• Written into: docs/UIPATTERN.md ("The work surface" section + hard-rule scope note), docs/STATUS.md (resume point), BUILD-LOG revisions per item.

29. Global UX rules (owner, round 29 — journeys brief)

• DASHBOARD-FIRST: every user logs into his dashboard; TODOS = topmost card (desktop) / first item in the mobile sidebar; section grids beneath. System TELLS the user what to do next — no free-floating initiative. Vision: near-paperless office, all work on phone.
• CAPTURE-first with instant OCR: whatsapp-screenshot/forward, OCR, or VOICE → opens the NEW-LEAD/order screen prefilled; the system HIGHLIGHTS each field and asks confirm (guided "next-next" spotlight). OCR runs inline (~1s on the Pi) — NO "come back later to confirm OCR" queue (same flow: sample request, Trading SO (MTO/stock&trade), JW contract, outsource-weave contract).
• GLOBAL EXPLORER: search + dropdown OR app-explorer grid (each form/ report as an app button, favourites first) — every form reachable outside the dashboard drill path. Also used for masters.
• MASTERS INLINE: on OCR miss, prompt "create new party?" or suggest existing (selection list); same for quality/yarn/etc. Never leave the entry flow to open a master — masters are created in-course.
• COSTING = the commercial card right under TODOS: lists pending LEADS to quote → prefills costing → margin select → round-off prompt (either direction) → share quote (PDF + msg) on WhatsApp. Quote button also on the PIPELINE card. All follow-up surfaces carry a WhatsApp button that opens that party's chat.
• FEED-FORWARD: each step auto-creates the NEXT-STEP button on the relevant card + in TODOS; forms also reachable in REVERSE (e.g. costing shows pending leads). Access principle: via dashboard card (if important) + global explorer — for ALL forms.
• QUOTE → CONTRACT via confirm-link: quote msg carries a link; sales-role users can open & modify/reshare; the CUSTOMER's click on the confirm link CREATES the contract in-system (2nd SO path). Broker/party contract copy can later attach to the SO as a supporting document.
• PARTY SPOCs: parties carry phone numbers + an app SPOC per department; the system prompts for these during party creation (WhatsApp follow-up
  • confirm-links depend on them).

30. RBAC profiles + owner-approval matrix + dashboard/recon refinements

• PROFILES = PACKAGES OF ROLES (designations): a profile carries one or more role-buckets (e.g. owner+sales); journeys are the role buckets. Custom access: per-form/per-report grants for org changes that don't fit buckets. If one holder holds ≥2 interdependent roles, their interdependent approvals are AUTO-DONE at creation (no separate step).
• OWNER APPROVAL MATRIX (accumulating — keep appending): · creation: SO · Yarn Booking · Job-work contract · (as-remembered: more) · modifications/cancellations of orders/bookings (amendments, tolerance beyond, removals) — sales marks → owner todo → owner approves → system creates the APPENDAGE update form · rate renegotiation: JW (party gives work) AND job-work-given- outsourced — sales marks → owner todo → owner confirms revised rates → system creates the update (appendage) · exceptions: adverse actual-vs-standard consumption (e.g. per count per week), reconciliation variances, and other exceptions surfacing across the flow
• OWNER'S THREE DUTIES: (1) approvals, (2) report & analytics monitoring, (3) exception approval/correction.
• DASHBOARD ORDER (every user): TODOS (top) → COSTING card (commercial users; usable WITH or WITHOUT selecting a lead) → other section cards.
• TODOS behaviour: each todo DEEP-LINKS to the relevant ROW of the sub-dashboard (not just the page); every todo carries an AGING column (days waiting/overdue).
• RECONCILIATIONS / HISHOB: the row table shows only key variables; a "View full reconciliation" button on the relevant sub-dashboard opens a FULL-PAGE PDF-EXPORTABLE version of the whole document alongside the original photo (scanned GP/statement) — full check before approval.

31. Planner = central role (round 31 clarifications)

• JW & JW-given (outsourced-weaving sale) contracts → COMMERCIAL staff at creation; the PLANNER is NOT their intake. Planner receives the OUT-HOUSE WEAVER / SIZER / WINDER contracts (service arrangements) into the system.
• PLANNER purview (central): gatepass receipt of yarn & DIRECT-DELIVERY intimation (his to create); every step visible in TODOS AND in the relevant card (step-prior triggers the next-step prompt on the card).
• YARN CARD (planner's warp/godown view): bookings pending GP reception · unassigned inwarded yarn · warp waiting for tippan (Generate-tippan button on the row) · outsourced weft-out GPs pending · transfers/ returns pending barcode fills · hishob prep rows.
• ALLOCATION granularity = BAGS or CONES (partial bag allowed), NEVER kgs on the floor — physical units only; partial-cone impossible, hence a small TOLERANCE between GP "sent" and "to-be-sent" is accepted (filled by godown with actual barcodes).
• He CREATES: yarn outward GP (outsourced weaving pending weft issue) · yarn return GP · contract-to-contract yarn transfers (to clear a JW hishob's given/received) · beam outward intimation · winding outward GP (button on the sizing hishob/receipt card) · sizing reassignment of beam GPs · sizer-to-sizer transfer GP · beam card. GODOWN FILLS the outward/return/transfer GPs with barcodes.
• YARN STOCK TRANSFER (party→factory) is AUTO-CREATED by the system; when godown fills the stock-transfer GP, the system PRINTS NEW barcodes (physical re-identification), godown places them on the boxes/bags.
• He APPROVES: physical yarn stock count (B7) and godown entries needing approval (he is head of godown).
• He PRE-APPROVES everything before owner approval: checks the JW hishob, makes required yarn movements, pre-approves, then issues for the owner.
• NEW FLOW STEP (missed earlier): planner creates the DISPATCH PLAN (party, quality, approx rolls/taga/bales/mtrs) → dispatch person makes the PRE-SLIP (F1) → loading → final slip (F2).

32. Confirms (round 32)

• (a) CONFIRMED: JW / JW-given SALE contracts → commercial staff; planner intake = out-house WEAVER/SIZER/WINDER service contracts.
• (b) CONFIRMED: planner sees BOTH — requirement in kgs AND allocation in physical units (bags/cones).

33. Guard scope · RUNNER role · external comms (round 33)

• GUARD SCOPE (clarified): guard only INS/OUTS of the premises based on INTIMATION. The yarn return/outward gatepasses ARE the intimation to the actual outward; the guard executes that outward together with the transporter. Fills, movements, stock counts = GODOWN's execution; planning = PLANNER. Guard's job = tap it in/out, nothing else.
• RUNNER (new role): physical paper movement (GPs, approvals, statements between office/godown/units), small-goods movement, SAMPLE COURIER, and errands. His screen = an errand/delivery due-list; he scans a QR on physical documents to log the handover; sample courier: pickup from factory → courier office → receipt → OCR receipt no (round 26).
• ACCOUNTS USER (Tally-related): later — not yet journeyed.
• EXTERNAL COMMS (UI principle): MOST external interaction is with the PLANNER and SALES — wherever their flows involve a party, show a WhatsApp button to that party's (SPOC) chat with a PRE-WRITTEN reference message for the work (GP no / order no / hishob no) and the relevant confirmation link (external, no login). Confirmation links ride the same messages.

52. UI re-skin — Textile ERP NextJS reference (2026-09-04, owner directive)

• OWNER CHANGED THE UI REFERENCE: the app shell + theme tokens now follow github.com/skpawar1305/textile-erp-nextjs (replacing gray_fabric_erp, §45-48). Scope = chrome + design tokens only; the per-screen patterns in UIPATTERN.md (lists/tables/forms/queues/ dashboards) are unchanged, daisyUI-only stays (Repo rule 4), light-only pin intact (Rule 1).
• Shell (src/routes/+layout.svelte): white sidebar w-72 with rounded-xl items, indigo-100 active pill + left indicator line, 10px uppercase zinc group headers, indigo→sky gradient brand block, desktop collapse to a w-20 icon rail, sticky glassy header (bg-white/80 backdrop-blur) with menu toggle + user chip (name/role + gradient initials avatar), Logout back in the sidebar footer (red hover), subtle sky glow, main content capped at max-w-7xl.
• Theme (src/app.css): zinc workspace (base-200 #f4f4f5), white cards, primary = indigo-600 (links/pills/CTAs), accent = sky-500, radii selector/field/box 0.5/0.5/1.25rem, Inter loaded in app.html, thead zinc-50 strip, tbody hover keeps the inset bar re-tinted indigo. daisyUI light --default pin + ui.test.ts guards untouched.
• BUILD-LOG rev 12; build green; tests green; deployed.

34. Physical-doc lifecycle · pickup codes · count-check loop · PRODUCTION HEAD

• PHYSICAL-DOC STATUSES: every document with physical movement carries: ready → picked-up-by-runner → delivered → received-signed-counter-copy. Runner has a form to UPLOAD the SIGNED COUNTER COPY (photo). The yarn GP received is collected by the runner, who SIGNS + STAMPS it and hands it to the transporter for pickup (godowns won't issue an unsigned/unstamped GP). A gatepass receipt triggers BOTH the runner and the transporter dashboards.
• PICKUP-CODE LOGISTICS: planner's screen shows a PICKUP CODE; the runner enters it when collecting (one combined daily code = all documents; partial → runner ticks which docs he collected after the code). The same code handover happens runner→transporter (transporter screen shows the code). Applies to ALL runner work; anything hand-dispatched goes through the runner. At every drop: ACKNOWLEDGEMENT PHOTO (signed hishob, LR copy, courier receipt, etc.).
• COUNT-CHECK LOOP (yarn count dispute): when actual-vs-standard consumption shows an adverse difference and the basis suspects count < claimed (yarn shortage): PRODUCTION HEAD raises the count-check request → godown manager ISSUES 5 CONES of the contested yarn → RUNNER picks up + sends to the LAB for count testing → when the report is ready the RUNNER picks up the cones + the report and returns them → if problematic, PLANNER issues the cones + report copy to the JOB-WORK PARTY or YARN BROKER → closure requires OWNER involvement; closure modes: further discounts · debit note · excess-yarn issues by the job-work party, etc.
• NEW ROLE: PRODUCTION HEAD — approves all CHECKING REPORTS and PRE-APPROVES the weekly ACTUAL-VS-STANDARD yarn consumption; raises count-check requests. (Receives Exception/approval todos, not sales.)

35. Role corrections (round 35)

• WEFT ISSUE (D2) is done by the GODOWN MANAGER (not a floor role).
• BEAM START (knot/gat, changeover) and BEAM END (reasons/dispositions) are PLANNER tasks.
• SHIFT boundaries (start/end shift) happen AUTOMATICALLY from loom data — no manual shift taps/entries.
• There is NO "floor weaver" user; the role is removed.

36. Journeys phase COMPLETE — UI build order

• All 12 journeys reviewed & consistent with A3 (rounds 29–35). Next phase: BUILD the UI per the gap ledger (GAP-1..28). Recommended build order:
  1. COSTING/QUOTE screen (GAP-2; engine ready) + round-off + share + confirm-link → contract + attach copy
  2. Global EXPLORER (GAP-6) + TODOS aging + row deep-links
  3. Physical-doc lifecycle statuses (picked-by-runner/delivered/counter- copy photo) + PICKUP CODES (GAP-26) + count-check loop (GAP-27)
  4. Runner screen (GAP-23/24) · Production Head board (GAP-28)
  5. F0 dispatch plan (GAP-19) · stock-transfer new-barcode (GAP-20)
  6. Rest per ledger (voice, D1 drag-drop, vehicle OCR, trip view…)
• Reads against BOARDS-A + UIPATTERN (parallel-session UI language); all screens stay daisyUI, mobile-first, append-only.

53. Declutter pass — plain language, less on screen (2026-09-05, owner)

• OWNER (2026-09-05): "all the pages look too confusing" + approved a FULL declutter pass, explicitly Pareto: highest-visibility surfaces first, fewest changes that remove the most confusion ("overall wording / amount of stuff").
• Sidebar (+layout.svelte): the Tools grab-bag (Masters/Docs/Demo/ Screenshots/Backup/Reports) is gone from the work nav — Masters is now a standalone item; the five dev/owner utilities became tiny muted links under a "Utility" label in the sidebar footer (still reachable, no icon noise). Group "Desk" → "Guard & transport" (what the group actually is). 22 links → 17, one group fewer, every remaining item is a work screen.
• Home dashboard (/+page.svelte + board.ts SECTIONS): section titles are plain language — stage codes dropped ("🧶 B — Yarn" → "Yarn", "🏷️ Commercial · SO" → "Sales orders", …), badges shortened; h1 "Main dashboard" → "Dashboard" with a one-line plain subtitle; attention strip label "attention — act today" → "Needs action"; period-bar explainer text moved to a tooltip; per-card "open page →" noise removed; dev footer tagline removed; section <h2> bumped to text-lg so sections visually separate.
• Scope discipline (Pareto): list screens, forms and board component pages untouched — their structure is the ERP work surface, and rewording every table was the low-value 80%. BUILD-LOG rev 13; build green; tests green; deployed. Next candidates if confusion persists: column-header wording on the top lists, /board index grouping.

54. All-pages declutter + DESIGN.md (2026-09-05, owner)

• Owner: "go through all pages" — the §53 Pareto slice extends to the full surface. An audit pass read all 29 +page.svelte files and flagged wording: cross-cutting issues killed — internal refs ("round 28", "appendage", "BOARDS/DUMPS" mentions), arrow flow-speak in subtitles and button labels ("Repair out → GP", "Capture → draft", "Check → FG roll", "Approve → enable print", "→ Create SO"), ALLCAPS clauses ("EXTERNAL boundaries"), roadmap placeholders ("OCR later"), dev output on screen (raw parsed JSON in drafts, "LLM/heuristic" chips in capture, gsm-wt, "engine converts on"). Renames applied page by page (dir → direction, intent → type, tipan → tippan, PS no → pre-slip no, yarn src → yarn source, beam req → beam due, count yarn → yarn count, partial → partial pickup, value @ rate → value at rate, OUT → Outsource, add beam (floor)/create gatepass (intimated)/create order {t} → plain). Duplicate panel h2 headings removed (beams, lots, tippans, gatepasses). Print sheet: "print unlocked" internal wording dropped. UploadDropp / upload-bins: "Pi", "Scratched read-only →", "(tables → which survive…)" flow-speak trimmed.
• DESIGN.md created (owner: "create design.md by referring to github.com/skpawar1305/textile-erp-nextjs and follow it"): the design system spec — principles, colour tokens (zinc workspace / indigo-600 primary / sky accent), Inter typography scale, shell layout metrics, component inventory (sidebar, brand block, buttons, cards, tables, forms, alerts, empty states, progress, motion, responsive), the auth pattern, the implementation map onto this repo (app.css tokens, shell, known deviations), and a conformance checklist for every new screen. Linked from STATUS.md (#9) and UIPATTERN.md. The /demo sign-in section restyled to the DESIGN.md §6 auth pattern (gradient brand block, centered max-w-md card, full-width indigo CTA).
• Wording only; no wiring (name/action/method/id) touched anywhere; tests green; BUILD-LOG rev 14.

55. UI updated to DESIGN.md (owner: "then update our ui", 2026-09-05)

• UI conformance pass against docs/DESIGN.md after the doc was adopted:
• Home dashboard cards (/+page.svelte): section cards now follow the DESIGN §5 stat card — emoji in a zinc icon tile (h-9 w-9 rounded-xl bg-zinc-100), hairline border-base-300, the reference's hover top highlight line (indigo gradient hairline, group-hover), KPI chip labels uppercase micro (11px semibold uppercase); title below the tile.
• List CTAs (orders/gatepasses/bookings/tippans page headers): "+ New X" buttons now btn-neutral — the reference's black New-button flavour (DESIGN §5: black CTAs map to btn-neutral); form submits, queue tap actions and inline add buttons stay indigo btn-primary.
• Board component pages (/board/[slug]): KPI stats restyled from the daisyUI stats strip to DESIGN §5 stat cards — uppercase micro-title + big tabular number in white bordered cards (grid 2/4).
• BUILD-LOG rev 15; tests green; deployed.

56. Overnight full build + Trading Capture APK decisions (2026-09-05, owner)

• OWNER: "build the WHOLE system, no phase-wise nothing. WhatsApp, OCR everything. The screencapture utility also — separate APK linked to the system. Use the new UI design. Follow everything instructed till now. Leave nothing." Overnight continuous build; single go-live cutover (ROADMAP one-go decision already agreed).
• APK decisions (owner answers): Everything mode (notification listener + overlay + share) · Android 8+ · user login via better-auth · identity "Trading Capture"/com.tynolabs.tradingcapture · no WhatsApp Business API anywhere (share/forward + notification-driven only).
• android-capture/ scaffolded (full Gradle/Kotlin project): notification listener (WhatsApp → /api/capture drafts, debounced/deduped/offline queue), floating overlay capture (MediaProjection → base64 draft), share- sheet receiver (text+image), settings+login screen. Built on any machine with Android Studio (no toolchain here); APK = ./gradlew assembleRelease.
• Server contract the APK needs (next deployable slices): /api/capture auth-gated with session user + base64 image support; /drafts image thumbnails.
• Valuation: owner deferred to go-live — reports carry the placeholder.

57. Realtime hub + global search (overnight build, slice 1)

• Realtime hub (SSE): /api/live streams a light snapshot every 10s — the attention strip items (today) + live counters (drafts/approvals/gps due/parked lots/hishob pending/FG rolls/beams repair) via board.ts liveSnapshot() (same queries as the dashboard — one source of truth). The home dashboard subscribes: needs-action strip refreshes in place with a "live" chip; no reload, no stale batch (ROADMAP: realtime hub — "they always show the current picture, never a batch").
• Global search (work-surface item 3): /search?q= across parties, designs, orders, gatepasses, beams, lots, tippans, rolls — grouped results; the shell header now carries the search box (desktop). Links point at list screens pre-filtered until record pages land (slice 2).

58. Record detail pages + amend/approve/print verbs (overnight build, slice 2)

• Record pages land (work-surface item 2): /orders/[id] and /gatepasses/[id] — crumb ← list, header (number + badges + party/ design), Amend verb in the header opens an append-only modal (note → amendment row + evt via appendAmendment; never edits fields), Terms card, Events card (evt, newest first), Amendments card. Actions record the correction journal; the modal notes "nothing is edited in place" (UIPATTERN record-page spec).
• Print verb at the external boundary: /gatepasses/[id]/print — the paper gatepass (company head + grid + signatures, print CSS), per mandate 4 (paper only at EXTERNAL boundaries).
• Search results for orders/gatepasses now deep-link to record pages; orders + gatepasses list rows link to their records.
• Approve verb (owner-gated) already exists on /approvals; fine for this slice.
• Next: rate board, OCR (vehicle/slips/rate lists + /api/capture images + drafts thumbnails), procurement suggestion, reports, loomgate adapter, leads, comboboxes, voice, gate-inward automation, tenancy seams.

59. OCR everywhere + APK server contract (overnight build, slice 3)

• /api/capture auth-gated (§56 contract): better-auth session required; createdBy from the session (never request body); accepts text AND image drafts (base64 data URL) — the Trading Capture APK posts here.
• /api/ocr (tesseract CLI, gotcha 8): multipart or base64 image → text. Vehicle-plate OCR buttons (📷) on guard exit, dispatch vehicle and new-gatepass vehicle — photo fills the plate, zero typing (OCR "later" roadmap items land now).
• /drafts renders image drafts as thumbnails (rawImage data URLs).

60. Yarn rate board (overnight build, slice 4)

• rate table (migration 0004): product (count+ticket), supplier, ₹/kg, gstIncluded, source (manual|capture|ocr), createdBy.
• /rates screen: latest-per-product chips (today's book), add-rate form (manual), full rate book table (source, GST, date). Sidebar Yarn group gains Rates; home Yarn section gains the 💹 Yarn rates card (products/entries/latest ₹/kg, links to /rates).
• Booking prefill: bookings/new shows "latest for {product}: ₹x — Use" under the rate field when a rate matches the selected yarn; capture/OCR ingestion for rate lists hooks into this slice next.

61. Procurement suggestion (overnight build, slice 5)

• /procure (sidebar: Yarn → Procure): per yarn — SO demand (open SO mtrs × design kg/m via computeDesignWeights, attributed to warp/weft count rows), free stock (own available/parked lots), in-transit (location), suggested buy = demand − free − in-transit; honest-first note that demand is keyed by count and must be verified before ordering; "Book" deep-links to /bookings/new.

62. Reports slice (overnight build, slice 6)

• src/lib/server/reports.ts: labelled report tables (open POs, SO vs delivery, yarn stock & allocation) + the universal dump edge (DUMPS.md) — /api/dump?slug=openpos|sodlv|stock now streams CSV.
• /reports screen (sidebar Orders → Reports): three print-ready sheets (print CSS hides shell chrome), ⬇ CSV buttons, hishob link card + Tally card (F4 export lands at go-live; valuation method = go-live decision §56 — ₹ columns show latest-rate × kg flagged "indicative only").

63. Loomgate telemetry adapter (overnight build, slice 7)

• /api/loomgate (D4): device ticks {device, loomNo, meters, runtimeSec} → event backbone (source iot:loomgate-), clientEventId-idempotent, accepts device-token header OR session.
• /loomgate screen (sidebar Production): recent ticks + an honest simulator posting test ticks through the same intake (the real utility dashboard device uses this endpoint).
• Weaving board live: the 📡 Loom efficiency card now reads the last 24h of ticks — looms reporting / metres / ticks, zeros when no device reports (never fabricated). The mending (M) card stays flagged until its floor data source lands (mending = grade source per journey — rolls data flows once the mending room enters).

64. WhatsApp share + external confirmation links (overnight build, slice 8)

• External confirmation (/c/[entity]/[id], PLANNING §33): no-login pages — gatepass receipt ("Received ✓" → event + delivered status for out-docs) and hishob acceptance ("Accept statement" → hishobStatus accepted + event). Record ids are random 12-char tokens (the secret).
• WhatsAppLink component (no Business API — owner §56): wa.me button with pre-written message + confirmation link, shown when the party has a mobile. Wired on: gatepass record ("Send to party" → receipt link), hishob rows ("statement ready → accept link"), order record (share the contract).

65. Leads pipeline (overnight build, slice 9)

• lead table (0005): leadNo (LO-), party, quality, qty, rate, status (new→quoted→followup→order|lost), source, convertedOrderId.
• /leads (sidebar Orders → Leads): add lead, pipeline table with tap status moves (events on the spine), Convert to SO — one tap creates the SO (linked + event) and lands on the order record.

66. Entry combobox + duplicate confirm + voice (overnight build, slice 10)

• Combobox (work-surface item 4): party picker on orders/new is now a type-to-filter combobox (≥2 chars, tap picks, value confirmed visibly); reusable component (hidden input keeps the form wiring).
• Duplicate hint: /api/dup-orders?partyId=&designId= → orders/new shows "same party + quality already open: {orderNo} — confirming creates a new order" (append-only, no merge).
• Voice-assisted order entry (ROADMAP Phase 4): 🔊 voice button on the party field — say the party name (fills the picker) or "rate 33.5" (fills the rate); Android Chrome Web Speech API, guarded where unsupported.

67. Tenancy seams + overnight-build close (2026-09-05)

• Tenancy seams completed (migration 0006): tenantId ('trading') + setupId ('setup-4') columns now exist on every business table (24 tables; party already had them). Enforcement stays staged per PLATFORM §3 (single tenant for go-live; RLS/session-context middleware triggers only when a second tenant goes live — the seams make the shift cheap).
• Gate-inward / lot automation: verified already landed in earlier rounds (rounds 31–32: YARN_IN kind, park-lot intake, contract assignment, stock-transfer with barcodes) — no gap left.
• Overnight build delivered in one continuous pass (revs 16–26): realtime hub · global search · record pages + amend/print · OCR everywhere + APK contract · rate board · procurement suggestion · reports slice · loomgate telemetry · WhatsApp share + confirmation links · leads · combobox + duplicate hint + voice. Trading Capture APK scaffolded (android-capture/, builds on any machine with Android Studio).
• Left only what genuinely needs the owner or hardware: valuation method (deferred to go-live, §56), F4 Tally wiring (go-live), party phone/real accounts + real device seeding, Android keystore/signing, OCR accuracy tuning on real slips/plates, loomgate physical device ids.

68. Prints rebuilt to the provided formats + journey runner (QA round 1)

• gatepass print FIXED (was a 500 — no +page.server.ts): now renders the owner's GP format — company head + GSTIN, doc title per kind (SIZING GATE PASS (BEAM OUT) etc.), GP no/date, party/address/set/ transport/vehicle rows, yarn goods table (count/ticket/R.Count/wt/bag/ cone + totals) or beam block with checked-by, signature blocks.
• hishob statement rebuilt to REPORTS.md §2.1 — In/Out/Consumption: YARN OPENING · YARN INWARD (live GPs w/ totals) · CLOTH OUTWARD (live dispatch slips) · YARN CONSUMPTION at the STANDARD engine rate · WEFT YARN REQ · SUMMARY → balance = hishob difference · the party approval clause ("Any complaint in report…"). Pending legs marked, never fabricated.
• New prints: /dispatch/[id]/print (packing-slip layout: per-piece roll rows, totals, P.Contract no) and /beams/[id]/print (BEAM CARD with loom/flange/ends/sizing + tracking Beam Meter → Woven → Shrinkage → Card MTR balance); links added on beams + slip lists.
• scripts/journey-test.ts walks 34 live flows with a real owner session (form actions with Origin + cookie per gotcha 6/7), DB asserts + print marker checks; scripts/seed-e2e.ts supplies the document-flow dataset. CSRF gotcha documented: actions POST to path?/action with the ORIGIN header matching env.ORIGIN.

69. Role-aware boards/nav + auth gate (QA round 2)

• Every login lands on its own board: ROLE_CARDS extended for the dummy users (runner: gt/ys/pk, transporter: gt/rn/dv, accounts: hi/py/fg/cyc/cov); the attention strip is role-filtered (owner sees all; staff only their own queue — ROLE_ATTN map); the sidebar nav only shows each role's screens (roles per group).
• Auth gate: the work screens now require a session (+layout.server.ts redirects to /demo); public surfaces stay public — /demo, /c/* (external confirm), /api/*, /docs. Guard/transporter due-lists are server-filtered (direction out + intimated|due).
• Harness: +2 steps (anon gate redirect, planner board) — suite re-run.

71. Status writers + reconciliation entry/detail (QA round 3)

• Statuses can now advance (dead-end writers added): gatepass intimated→ due (markDue verb on the GP record — guard/transporter due-lists are server-filtered to intimated|due); tippan draft→issued (Issue verb + evt); reconciliation pending→approved/exception via the new detail flow.
• Reconciliation built (closes GAP-11): /reconciliations list + entry form (kind/direction/party/set/expected/actual → variance computed), /reconciliations/[id] with Expected-vs-Actual-vs-Variance cards, events, and owner verbs Approve / Flag exception (appendage + event); approvals rows deep-link to the detail; sidebar Intake group gains Reconciliations.
• Harness: +3 steps — suite rerun (39 total).

72. Operation-simulation findings — security + correctness fixes (QA round 4)

• 11-role live simulation (workflow op-simulation) walked the system as each user; 60+ evidence-backed findings. Fixed this round:
• Anonymous writes sealed (CRITICAL): SvelteKit form actions had no auth — /guard?/exit, /transporter?/pick, markDue, drafts?/confirm were writable without a session. hooks.server.ts now requires a session for every form-content-type POST on work screens (public: /api/, /c/, /demo).
• Role-sensitive routes gated (+layout.server.ts ROLE_PAGES): every page load checks the role allowlist (planner/owner/… per PLANNING §30) — guards, transporter, approvals, recons, loomgate, order/booking/ yarn/production screens; wrong role → own board.
• dispatch roll transition real: loop used r.rollId (never matches) → rolls stayed FG; now r.id + explicit .run(); .run() added to every update chain (transporter/guard/markDelivered/drafts/beams/lots/ tippan/samples) for explicitness.
• Loomgate meters fixed: payload is TEXT json — board ef + loomgate page now parse it (meters/runtime read correct).
• Confirm links: /c/hi shows a statement number (not "undefined"); /c/gp on an INBOUND doc acknowledges without falsely claiming 'delivered'.
• Approvals: hishob rows show the contract number (join orderNo).
• Transportser due-list includes 'partial' (a partial pickup no longer vanishes; completion is possible).
• Search: newest-first ordering + cap 20 for doc-number domains.
• Home quick-add filtered by role (no more cross-role CTAs like 'New SO' for a godown).
• Recorded open gaps for later rounds: multi-warp/weft design master, /beams·lots·tippans record pages, costing/quote screen, dispatch F1→F2 with planned→loaded→dispatched flow + no-redispatch guard, reject path for R rolls, WIP bucket, beam-scoped roll numbering, lot yarn_id mapping + procure count-key matching, per-list CSV (DUMPS), runner screen, party field gaps, print GSTIN config.

73. Planning correctness + F1→F2 + record pages + checking depth (QA round 5)

• Lot→yarn mapping: createLotsFromGatepass resolves yarn_id from the GP count line (count-first master match) — lots now show as stock for the right yarn.
• Procure count-key: demand and stock both key by the numeric count (61, 40…) — the suggested-buy number now matches real yarns.
• Dispatch F1→F2: create = plan (rolls untouched, validations: order exists, party required, no-redispatch guard per roll) · load = rolls leave stock (dispatched) · deliver = final; Load/Delivered buttons on the slips table.
• Record pages for beams/lots/tippans (+ events/amendments, beam card print link); list rows + search deep-link to them.
• Checking depth: R grade → status 'reject' (not FG → cannot ship, off 'Ready, not out'); beam-scoped roll numbers (BM-x-01 style); required beam + positive mtrs; checking report print (/checking/ report — grade split + roll detail + measured vs GSM target).

74. Quote/costing screen + dump edge + GSTIN + party fields (QA round 6)

• /quote (Orders → Quote; the documented P1 calculator / #quote screen): construction × mtrs → the COSTING sheet in-system — weight ladder (warp/sized warp/weft/fabric/costing wt, GLM, GSM, per-1,000 m), cost ladder (material × rates, sizing, job, subtotal, other %, ex/incl GST), margin table 1–20%, "Create order with these numbers" deep-links to orders/new with designId+qty prefilled (orders/new now prefills from ?designId&qty); print CSS applies.
• Universal dump edge (DUMPS.md): /api/dump now serves per-form CSV slugs — beams · lots · gatepasses · orders · tippans · samples · drafts · leads · recons (+ existing openpos/sodlv/stock) — and every ListToolbar list page passes csvHref (⬇ CSV on all 9 lists).
• Company identity: src/lib/company.ts — one place for the mill name/ address/GSTIN; the gatepass, hishob and dispatch prints render "GSTIN No:" from it (placeholder until the owner fills the number).
• Party master fields (FIELDMAP §1): phone, taluka, district, state, PIN, email, broker name, PAN, opening balance added to the add form and the create action (schema already had the columns).

75. Remaining prints + runner screen + multi-warp design (QA round 7)

• Tippan print (/tippans/[id]/print — sizing program sheet: design, sizer, weaver, contract, warp mtrs, yarn source, loom type, kril plan, beams list, signatures) + Print button on the tippan record.
• Contract/SO print (/orders/[id]/print — party/address, contract no, design + reed/pick, terms table incl. value, discount, payment, brokerage; amendment history, T&C clause, broker line) + Print verb on the order record.
• Reconciliation print (/reconciliations/[id]/print — expected/actual/ variance + status/approved + signatures) + Print on the recon detail.
• Runner screen (/runner + sidebar under Guard & transport): the physical-document day — docs-to-pick list with pickup codes, sample courier runs (recordCourier). Full pickup-code/ack-photo ledger + count- check loop remain §34 GAPs (documented).
• Multi-warp/weft design master (FIELDMAP + A2): JSON row inputs on the design add form; createDesign parses rows, computes per-row weights, stores warpRows/weftRows (single-count fallback kept).

76. Final QA close (2026-09-05)

• JW/OUTSOURCE contract fields land (migration 0007: order.loom_type + broker_name; loom-type select + broker on the JW/outsource form).
• WIP bucket in checking: doff → WIP roll (beam-scoped), WIP queue on the page, "Grade now" grades the WIP roll IN PLACE (grade/status → FG or reject).
• docs/QA-GAPS.md committed — the consolidated overnight ledger: every audit/simulation finding with status (DONE / OWNER / HW / DEF), the open-owner gates clearly listed (GSTIN, valuation, numbering, BRIDGE formats, keystore, phones), and the harness path for the owner's own per-role walk. STATUS.md refreshed; BUILD-LOG rev 28.

77. Work-surface usability pass (2026-09-05 — owner: "nothing is usable")

• Human audit of all ~30 pages vs DESIGN.md §8 + UIPATTERN.md work-surface: two-tier lists (9 with ListToolbar vs 14 without), errors invisible on the 7 highest-volume forms (no form?.error + return {ok:false} never rendered), Combobox used once (orders/new party only), entry buried in collapse on 6 pages, record dead-ends (lots zero verbs; beams/tippans Print-only; no Linked docs anywhere), density overload (beams 15 / lots 13 / gatepasses 12 cols, no compact toggle), ID/code leaks (draft id hash, beamId slice, inline JSON.parse, iot:loomgate-*), btn-xs + w-24/28 row inputs unusable with gloves, mobile header search hidden, prefill islands not chained (dispatch order/party unlinked, lots-assign unfiltered).
• Agreed fix order: 1 Unblock (error banners + fail(), form-first cards, guard per-row vehicle state, mobile search, record Amend/Approve-print gates, human variance table) → 2 List standard rollout + compact/label-map → 3 Entry (Combobox everywhere, prefill chain, progressive masters, warp/weft row-builder) → 4 Flow (Linked docs, drillable SmartTable, search deep-links) → 5 Polish (plain language, DESIGN §8 per screen). Constraints intact: daisyUI-only, light-only, append-only, docs-first, build green, deploy via deploy.sh.

78. Demo scaffold removed — /signin becomes the app auth entry (2026-09-04 — owner: "remove demo completely")

• The /demo dev scaffold (DEMO-branded auth card + todos) is deleted entirely — route folder gone, no nav entry. Anonymous traffic no longer lands on "Demo"; the root layout, hooks POST gate and shell "Sign in" buttons now aim at the new /signin route (same better-auth client calls, DESIGN §6 pattern, sign-in/sign-up tabs, no todos, no demo branding; after auth it lands on /; a signed-in visitor sees a signed-in card with "Open the app" + Sign out).
• Public surfaces are now /signin, /c/*, /api/*, /docs — updated in +layout.server.ts (PUBLIC_PREFIXES + redirect), hooks.server.ts (isPublicPost + 401 location) and journey-test.ts (gate assertion + smoke page). The inert dev todos table stays in the schema (no UI, no migration churn — dropped later only if it accumulates cruft).
• App-level sign-in REMAINS mandatory (roles + owner approvals, §68/§72) — the Caddy door authenticates the network, not per-user roles. If the owner wants the door to be the only gate, that is a separate RBAC decision, not part of this removal.

79. myTextile data migration — wipe + real-data import (2026-09-04 — owner: "delete all the existing data. fill up with data from the backed up .bak file; if any of the info from it is missing then modify our database accordingly")

• Source: the owner's backup backups/20260902-bc7c1f16-myTextile-Data-20260826-181752.zip → myTextile-Data-20260826-181752.bak — a SQL Server (CB4Demo) full database backup (created 2026-03-27, backed up 2026-08-26). The Pi's kernel uses 16KB pages so SQL Server cannot run here (Azure SQL Edge refuses to boot); extraction ran on the owner's Ubuntu PC (skpawar1305@192.168.1.19, x86_64): SQL Server 2022 in Docker, RESTORE → mt_restore, sqlcmd dumped every user table to |-delimited UTF-8 CSVs (169 tables; catalog 2,520 columns). Dump zip archived at backups/mytextile-dump-all.zip (gitignored); copy of the .bak stays in /tmp/mt-bak/ on the Pi.
• Data reality: the old app's REAL data lives in schemas gen (masters) / trans (ledgers) / Recover / utility — NOT dbo (which is near-empty temp tables). Masters: CompanyMaster 460 (parties) · ItemMaster 88 (yarn) · QualityMasterMain 390 + DesignMasterMain 601 + Detail 674 (constructions with precomputed kg/m factors) · LoomMaster 71 · FlangeMaster 205 · cityMaster 399. Transactions: BeamCardMain 6,685 · BookingEntriesMain 912 (JW contracts) · YarnPhysicalStockDetail 286,490 (cone-level stock) · ProductionPlanning 37 (live Aug-2026 rows) · plus big archive histories (BeamCardDetail 196k, ProductionDetail 236k, TMPPackingSlip 325k, DailyEfficiency 141k, InwardDepartment 66k, WeftIssue 88k/65k, OutwardPackingSlip 8.5k…).
• Import scope (MIGRATION §3 S-slices; archive history does NOT ride over): party 464 (companies + non-bank ledgers; broker post-pass; city via cityMaster) · yarn 89 (ItemMaster; OE/SLUB/Ly/denier heuristics; ticket 'IMP') · design 602 (quality+design merged; warp_kg_per_m = old precomputed factor seeds the costing engine — owner verifies per COSTING §5 before it locks) · order 909 (BookingEntries → JW contracts: orderNo JW-MT-, tolerance diffMtr/diffBeam, status Hishob-Settled→closed) · beam 6,686 (BeamCardMain; on-loom marks from ProductionPlanning by ext beam no; status G/P/S ambiguity → onLoom/floor/finished by remaining) · production_plan 36 (live plan rows — board wiring lands later) · lot 2,047 (open stock from YarnPhysicalStockDetail, net>0, aggregated per item/party/booking/set).
• Schema extensions ("modify accordingly"): party.address + external_id; yarn/design/beam/order external_id; order.diff_mtr/diff_beam; beam ext_record_no/ext_beam_no/main_beam_no/remaining_mtr/selvedge/kinari/frames; NEW production_plan + import_log (BRIDGE ledger). Migration 0008.
• Idempotency: deterministic mt-* ids; insert or replace; --wipe clears business tables (auth never touched — 13 users kept, owner intact). Pre-import snapshots: backups/data.db.pre-migration-* + backups/data.db.pre-import-*.
• Verified: journey suite 53/53 on the imported DB; e2e fixtures reseeded via seed-e2e.ts (e2e- ids coexist). Re-run import = refresh.
• Open items (owner): kg/m factor sign-off · old status G/P/S meaning · order↔beam link is loose (beam.contract_id null — beam numbers match per party only informally) · warp/weft kg split not carried (single factor) · hsn column holds odd values (889921…) · planning board wiring (D1) later · city master not a table (inlined into party).

80. Door auth vs PWA assets — manifest/favicon public on the tunnel door (2026-09-04)

• Browser console showed manifest.webmanifest 401 on trading.tynolabs.com: the Caddy tunnel door (:4103) put basic auth on EVERY request, and browsers fetch the PWA manifest as a no-credential fast-fetch resource → 401 → app not installable. favicon.ico was missing entirely (404).
• Fix: :4103 now uses a matcher'd basic_auth @private — public static fast-fetch paths /manifest.webmanifest /manifest.json /favicon.svg /favicon.ico /robots.txt skip the door password; everything else unchanged (door root still 401 without creds). LAN doors (4104/4106) untouched. Caddyfile backup in /etc/caddy/Caddyfile.bak-*.
• App: generated static/favicon.ico (32×32 indigo T tile) + static/ favicon.svg; app.html now links both before the manifest.
• content-script.js: failed to get subsystem status … (console) is a browser-extension error, NOT this app — no file named content-script.js exists in this repo; it is injected by an installed extension (verify in DevTools → Sources → content scripts, or disable extensions).

81. Masters follow-up — looms + flanges imported (2026-09-04)

• §79 imported beam references to flanges/looms but not the master rows — /masters showed only the 1 e2e fixture flange. Importer now upserts loom 71 (LoomMaster; quirk: loomId is a constant 1, the real loom number is column loomNo — keyed on that; loom_type from LoomTypeMaster Airjet/Rapier; shifts 2/3) and flange 205 (FlangeMaster; flange_no + beam_size e.g. '190 CM'). loom_class defaulted '250' — owner to flip per loom in masters (old loomTypeId semantics ambiguous).

82. Loom count reconciliation (2026-09-04 — owner: "incorrect number of looms")

• The 73rd loom was the retired e2e test fixture (e2e-loom-1, loom_no '47') colliding with the imported loom 47 — masters/loomgate listed 47 twice. Root cause: the import is not "old data left behind" — the fixture was re-added by seed-e2e.ts after the wipe. Fixed: e2e loom/flange master inserts removed from seed-e2e.ts (journey suite doesn't need them; beams keep loom_no/flange_no as free text), rows deleted.
• Bonus fidelity: the source's trailing loomtype column (36 rows) carries the REAL class (18×'190', 18×'250') — importer now maps it (loom 47 = AIRJET/190 as the .bak says); 36 NULLs default '250'.
• Final reconciled counts (vs .bak): looms 72 (loomNo 1..72, unique) · flanges 206 (FlangeMaster 206 rows) · journey 53/53.

83. Full-table audit after migration (2026-09-04 — owner: "check all tables")

• scripts/audit-migration.ts — per-table reconciliation (counts: total / mt- import / e2e fixture / other) run against data.db + the source dump.
• Verdict: every real myTextile record is in the DB; the remaining count deltas are junk that existed INSIDE the old system's own data and is preserved in the archive dump only:
  • orders 913 source → 909 imported: id 181 duplicated (2 rows) + three rows whose KEY column is junk text ("CONTRACT CANCCELED", "230922-KU230001", "02 beam decrease due to order late") — 909 valid unique contracts all imported.
  • production_plan 37 → 36: one row has a NULL recordId (no key).
  • lot: 286,490 stock rows → 2,047 aggregate lots (net>0) by design.
• Residue cleanup (scripts/clean-journey-residue.ts): journey-run rows (random newId ids) removed from all business tables after each QA run — app shows only mt-* (real) + e2e-* (sanctioned fixtures) rows. Auth users + import_log untouched.
• Seed bug found+fixed: seed-e2e's design insert lacked created_at/updated_at → insert or ignore silently dropped e2e-design-1; timestamps added, fixture now present.
• Final state per table: beam 6,688 (6,686 real + 2 fixtures) · order 911 (909 real + 2) · design 603 (602 real + 1) · lot 2,048 (2,047 real + 1) · party 468 (464 real + 4) · loom 72 · flange 206 · yarn 89 · plan 36 · and the remaining tables hold only sanctioned e2e fixtures or are empty (amendment/evt/movement/todos/hishob/lead/rate cleaned to 0).

84. Closing the UI gaps — planning board, imports page, movements, allocations (2026-09-04 — owner: "all")

• Four previously staged screens are built now (tables already exist from §79/round-28; no schema change):
  1. /planning (Production nav) — the D1 planning board: production_plan (36 imported live rows) × loom × last loomgate tick; dates/progress/ remaining from the migration data. D1 "details" beyond the board stay deferred (owner).
  2. /imports (Utility footer) — import_log ledger + per-entity mt-* counts (audit-migration summary), so the migration is verifiable on screen.
  3. /movements (Yarn nav) — yarn movement/transfer docs (party↔factory, contract→contract, short, return, weft_out): create + list, append-only (B0-B2 stage), items as lot/bags/cones/kg rows.
  4. /lots/[id] — allocate (soft) + reserve (verbal-commit, next-working- day expiry) against open orders (B4) with event log.
• All append-only (no edit/delete), daisyUI, mobile-first; roles via ROLE_PAGES (/planning production-family, /movements yarn-family, /imports owner+planner).

85. In-depth verification of the imported data (2026-09-04 — owner: "check in depth")

• scripts/deep-check-migration.ts — random-row field compares vs the source dump (numeric-aware) + semantic distributions. Results:
  • party: all 432 company rows checked, 0 mismatches (36 nominal diffs = trailing spaces the importer trims — better in DB).
  • design 0/5 · beam 0/5 · order 0/5 · lot aggregation 3/3 exact · production_plan 0 missing / 0 mismatched.
  • Semantic: beam status 6,563 finished · 123 on-loom (loom marks) · 1 repair · 1 floor (from old G/P/S + remaining logic); order 612 closed / 299 open; party category Party 378 · Sizing 79 · Broker 6 · OwnUnit 1.
• Functional depth of new screens (§84): movement create (2 item rows) → row + event ✓, invalid → failure payload ✓, reserve → row + 24 h expiry ✓, role gates (/imports owner+planner; /planning, /movements godown OK; godown blocked from /imports & /loomgate) ✓.
• Open items (owner) — data semantics, not errors: kg/m factor is the old system's totalWeight (≈95.24% of the Σ detail weights — constant ratio, presumably a yield/loss factor; verify before costing locks) · design.hsn column holds old design codes (889921/998821 — NOT GST HSNs) · yarn typeCode is heuristic (OE→KW, SLUB→Sl, Lycra→Ly, denier→Dn, else CW) · loom_class defaults '250' where the old source had no class marker.

77. Masters rebuilt — row detail + full field capture (owner-led, screen by screen)

• Owner: "Everything is off — not all fields are taken; clicking a row doesn't open into the detailed fields. All fields to be taken per the specs + old-software screenshots. Take one master at a time."
• Row-click detail (all six tabs): every master row now opens /masters?tab=X&id=Y and renders a detail card with EVERY field of that record (FIELDMAP §1 labels — party 18 fields, yarn 6, design 27, loom 4, flange 2, defect 3) plus an Amend verb (append-only correction → amendment row + event; entity/id/note). Clicking a row finally opens the full record.
• Design master gaps filled (spec + Master_Design screenshot): UTL, HSN code and GSM target inputs added (schema columns existed) — createDesign now stores gsm_target/utl/hsn. Multi warp/weft rows and rates were already in.
• Next masters: yarn type codes list per old Master_yarn, party address (Gate/Unit no) field, loom shifts/class per Master_Loom — on the owner's next look.

78. Master fields reference + OCR guidance (owner)

• static/masters-fields.html — printable PDF/HTML reference of every master and every field (label + DB column) + the entry trigger for each (the Add form on its Masters tab). Linked from the Masters page header ("Fields reference (print / PDF)"); File → Print → Save as PDF since the sheet has print CSS.
• OCR beyond plates (owner question): the three OCR paths are the Capture photo tab (any photo/PDF → text → parsed draft), the vehicle camera buttons, and /api/ocr; WhatsApp forwards already land in /capture via the share target. Tesseract PSM retry shipped (§77). Rate-list/contract OCR ingestion is next once the owner drops sample contract/GP photos.

86. Masters: every filled item editable with the SAME form code (owner)

• Owner: "each filled item should be editable by the same initial form code. Also, if there are more fields in documentation, they must appear in the forms."
• Same form for Add + Edit: each master tab's Add form was extracted into one reusable component per master (src/routes/masters/{Party,Yarn, Design,Loom,Flange,Defect}Form.svelte); clicking a row → Edit fields renders that same component pre-filled, and saving calls the paired update action (updateParty/updateYarn/updateDesign/updateLoom/ updateFlange/updateDefect) which updates the row in place. Value builders (src/lib/server/masters.ts) are shared by create and update so the two can never drift; every edit is audited in the event journal with a before/after diff of only the changed fields (evt payload). This is a deliberate masters-only exception to the append-only default (Repo mandate 3): reference-data rows get corrected with real updates, still fully traceable; the append-only Amend-note box is kept.
• **Documented-field gaps closed (FIELDMAP §1 / static/masters-fields.html): party Address + Active; yarn Active; design GSM target / UTL / HSN (createDesign already read them but no input existed); flange Status (available/on_beam/repair/scrap). Detail card field lists updated (party 19, flange 3).
• Bonus the edit form now enables: loom class/shift flip per §81 (the "owner to flip" item), imported free-text warp/weft counts cleaned via the same form (numeric + system prefill parses "60S"/"75 DENIER").
• Regression suite: tests/masters.test.ts (15 cases — every builder's field mapping incl. the doc-gap fields, JSON row parsing, diff).

87. Type checks moved to svelte-fast-check (owner)

• bun run check now runs svelte-fast-check (svelte2tsx + tsgo, drop-in for svelte-check; bun --bun svelte-fast-check --incremental) — cold ~3s vs svelte-check's ~25s, and it's the package.json check script (svelte-check dependency removed). Docs updated: AGENTS.md Commands, docs/STACK.md (new "Type checks" section), docs/DEPLOY.md pre-deploy loop.
• Note: tsgo's diagnostics set is still being completed — check is the fast manual gate; bun test remains the deploy gate (deploy.sh).

88. Manifest share_target enctype + extension-console note (owner console logs)

• Chrome's manifest validator warned: Manifest: Enctype should be set to either application/x-www-form-urlencoded or multipart/form-data. It currently defaults to application/x-www-form-urlencoded. static/ manifest.webmanifest share_target (GET share → /capture) now declares "enctype": "application/x-www-form-urlencoded" explicitly — matches the GET behavior, silences the warning, no behavior change.
• Second console line the owner saw — content-script.js:104 Failed to get subsystem status for purpose Object — is the browser-extension error already noted in §80 (no content-script.js exists in the app; it is injected by an installed extension, e.g. a reader/AI extension). If it persists after disabling extensions, capture DevTools → Sources → content-scripts to identify the injecting extension.

89. Masters record opens at the TOP of the page (§86 follow-up, owner)

• Owner: /masters?tab=party&id=p-mt-58 "doesn't open up". The detail card rendered BELOW the whole list + Add form (468 party rows, ~900 KB HTML), so opening a record looked like nothing happened. The detail card now renders FIRST, right under the tabs, with a ← Back to list verb; row-click and deep links land with the full record + Edit fields on screen immediately.

90. UI principle — ergonomics first (owner)

• Agreement logged: ergonomics is the most fundamental UI principle. DESIGN.md §1 now leads with it — every other principle (calm workspace, indigo/zinc, one action per screen, plain words, mobile-first) exists to serve the person working: fewer taps, less typing, less hunting, less re-checking; a pretty-but-awkward screen is a failed screen. UIPATTERN.md carries the same line at the top ("choose the pattern that gets the user to the result fastest"). Doc-only change — /docs reads the markdown at runtime, no build/deploy needed.

91. Masters rows open in a dialog (owner; supersedes the §89 layout)

• Owner: "opening a row should open a dialog box". Row click (and deep links like /masters?tab=party&id=…) now opens a daisyUI modal dialog with the full record — fields grid, Edit fields (same form code as Add), Amend box; close via Esc / backdrop / ✕ / tab switch. The §89 inline detail-at-top card is replaced by the modal; the URL ?tab=&id= is kept as the shareable deep link (openRecord/closeRecord use goto with keepFocus; close uses replaceState). SSR renders the dialog open so JS-less/deep links still show the record.

92. Fixed: tabs reverted when a tab param is in the URL (owner)

• Owner: on /masters?tab=party, tapping the Yarns tab did nothing. Root cause: the URL-sync $effect read tab in its t !== tab comparison, so it re-ran on every tab-state change and reverted tab to the URL's value. Fix: the effect now reads only page.url and wraps the state reads in untrack() — it syncs on URL changes (deep links, row open, back) but never fights a user's tab tap. Same 1-line pattern review done for selId in the same effect.

93. Follow the textile-erp-nextjs layout — ergonomics (owner)

• Owner: "can you follow the design layout of github.com/skpawar1305/textile-erp-nextjs — it's very ergonomic". Reference studied (layout files read directly); its ergonomics are now the list-screen standard (UIPATTERN.md "Design for the job"):
  • compact panel header — text-xl font-semibold title + count + the create CTA ("+ Add …") on the right;
  • search box per list — input input-bordered input-sm with Search icon, filtering the active list client-side across ALL fields (one tap to find a party among 468 by name/GSTIN/city);
  • plain bordered table — overflow-x-auto rounded-box border (no card wrapper), daisyUI table (not table-sm: text-sm + roomy py-2/px-4 cells), gray thead, — nulls, enum badges;
  • text-link action per row — right-aligned "Open" (link link-primary link-hover) that opens the record dialog; rows stay clickable.
• Applied to /masters (all six tabs); tabs + record dialog + add-forms retained. Other list screens (beams, orders, lots…) can be converted to the same recipe on the owner's go (each is the same 4-step pattern).

94. Orders showed absurd dates — timestamp unit mismatch (owner)

• Owner: "so many orders in /orders have weird dates" — they rendered as years 58,000–76,000. Root cause (two layers):
  1. Schema unit contract: integer(_, { mode: 'timestamp' }) stores/ reads unix seconds, but the migration importers wrote milliseconds (Date.parse / $defaultFn new Date()). Drizzle read ms values ×1000 → 2021 bookings displayed as year ~53k–77k. Fix: app tables switched to { mode: 'timestamp_ms' } (schema-foundation. ts, 46 cols + todos) and scripts/normalize-timestamps-ms.ts normalized 4,395 stored second-epoch values to ms (idempotent; backup before/after in backups/data.db.pre-datefix-*). Better-Auth tables (user/session/account/verification) keep timestamp — internally consistent, sessions untouched.
  2. Old-system junk booking dates: 6 orders (ids 240465, 181, 251429, 260053, 260708, 261290) have bookingDate literally "45" in the source → Date.parse("45") → year 2045 (2044-12-31 in IST). Shared guard src/lib/server/dateGuard.ts (saneYearMs) rejects any date outside 2000…current+2 — used by the importer's iso() (re-imports can't recreate junk) and the orders list/detail/print fmtDate (junk shows as "—", honest "unknown"). The 6 rows keep their source value in the DB.
• Regression suite: tests/timestamps.test.ts (mode-unit contract + junk-date guard); 73 tests green.

95. sveltekit-superforms adopted for plain entry forms (dev)

• Asked: "would it help to use sveltekit-superforms? if yes, do it". Assessed honestly: it helps plain entry forms (typed form data, shared client+server validation, field-level errors, numeric coercion, no per-file request.formData()/num() boilerplate), but NOT the bespoke forms (orders/new combobox+voice+prefill, capture OCR loop, movements multi-row) — those stay on the existing use:enhance pattern where prefill/derive logic dominates over validation. So: adopted as the standard for plain entry forms, converted form-by-form.
• First slice converted (the three cleanest record forms):
  • /gatepasses/new — schema: src/routes/gatepasses/new/schema.ts; "source or target party" is now a zod .refine (renders in errors._errors as the daisyUI alert); junk bags/cones/gross/net are visible field errors instead of the old silent || null.
  • /bookings/new — schema: src/routes/bookings/new/schema.ts; bags/ bagWt/ratePerKg required > 0 with friendly messages; gstPct bounded 0–100 with default 5 (today's ?? 5, now visible in the field); junk numbers error instead of the silent || 0.
  • /rates — schema: src/routes/rates/schema.ts; product trimmed + required, rate positive; the old return { error } without fail() (a 200-with-error bug) is now a proper fail(400, { form }).
• The pattern (documented in UIPATTERN.md "Entry forms"):
  • route-local schema.ts (zod) → superValidate(zod4(schema)) in load; superValidate(request, zod4(schema)) in the action, invalid → fail(400, { form }); client superForm(data.form, { validators: zod4Client(schema) }) + use:enhance from superforms; field errors under inputs (text-xs text-error), form-level refine errors in errors._errors as the alert.
  • zod v4 ⇒ the adapters are zod4/zod4Client from sveltekit-superforms/adapters (zod is the v3 adapter — schemaShape throws "No shape could be created" under zod 4).
  • Numeric fields: z.coerce.number() — empty → undefined (optional) / required-0-fail; junk text → NaN → zod field error. This is the deliberate behavior change: junk input is no longer silently swallowed; if the old soft behaviour is ever wanted for a field, that field stays a plain string and converts in the action.
  • Boolean-from-select footgun: superforms' boolean coercion maps the POSTed string '0' → true. Selects that are really flags stay string enums (z.enum(['0','1'])) and map to a real boolean in the action (rates.gstIncluded).
• Remaining plain forms (hishob, transporter, samples, quotes, …) convert to the same recipe as touched; never rewrite bespoke forms to fit it.
• Regression suite: tests/forms.test.ts (10 cases through real superValidate: refine error, junk-number errors, defaults, trim, gstIncluded enum guard); 83 tests green; build green; deploy via deploy.sh.

96. Superforms slice 2: hishob + transporter (dev)

• hishob (generate form) — route schema src/routes/hishob/schema.ts: orderId required. Business checks (contract exists, statement already generated) now route through setError(form, 'orderId', …) → the error renders under the contract picker, not as a page-wide alert. The picker gained a "— pick a contract —" placeholder: the old markup auto-selected the first contract (an accidental generate was one tap away); per mandate 4 the selection must be explicit.
• transporter (per-row pick tap) — route schema src/routes/transporter/schema.ts: id required + partial boolean. Each row card is its own superForm instance over the single load-provided form via a small child component (src/routes/transporter/PickCard.svelte); the gatepass id rides the DOM (hidden input) so every card submits its own row. The form: any prop on the page is gone.
• Pattern notes added to §95's bullet (UIPATTERN "Entry forms"):
  • business checks in an action → setError(form, path, msg) + fail(400, { form }); never a bare { error } return.
  • multiple per-row forms → one load form + one child component per row.
  • checkboxes with superforms coerce: z.boolean().default(false) — posted 'on' → true, absent → false (verified in source: Boolean('on') === true).
• Regression suite extended (tests/forms.test.ts: hishob required contract, transporter id-required + partial-on mapping); 87 tests green; build green; deploy via deploy.sh.

97. Agreed operating course — complete-to-spec build program (this session, owner)

Owner-agreed — "Let's go. Do the first bit." Started execution. Tracking checklist: docs/COMPLETION.md.

1. Model decision: deepseek-v4-flash ONLY for all development work (catalog verified: flash $0.14/$0.28, pro $0.435/$0.87, Claude Haiku 4.5 $1/$5, Opus 4.5 $5/$25, Opus 4.1 $15/$75 per M tokens; DeepSeek cached reads ~50x cheaper; catalog date 2026-07-25). Historical failures were process (one-go builds), not model capability — no other provider unless a concrete under-delivery is raised and approved first.
2. Build stance — not from scratch, not patchwork: REBUILD TO SPEC. Verified assets stay (engine ~0.002% vs the owner sheet, the schema holding the real imported data, the journey harness). Per phase/slice every existing piece is classified KEEP vs REBUILD by evidence, recorded in COMPLETION.md.
3. Ordering — technically dependency-correct phases: 0 foundations & invariants → 1 database complete → 2 engine & services → 3 shared platform layer → 4 transactional spine (dependency order) → 5 read models → 6 capture & OCR → 7 integrations → 8 hardening & cutover.
4. Definition of Done (6 checks) — see COMPLETION.md; owner tests each slice with a real document the same day; mismatch → slice reopens.
5. Verification for non-UI phases — 3-layer contract: automated checks + plain-language Verification Sheet per phase (What/Why/ How-proven/Owner-5-min-spot-check/Unlocks) + observable spot-checks; owner signs the sheet, never the code.
6. Phase-0 audit pre-computed before start (read-only): security seals verified (hooks POST gate, ROLE_PAGES), 39 in-place update sites paired with the event log; six verified silent-mutation findings (F0-1 guard exit, F0-2 transporter pick, F0-3 draft discard, F0-4 /api/approve no own event, F0-5 dispatch roll dispatched, F0-6 rate create — file+line evidence in COMPLETION.md) → each gets a fix + invariant regression test; plus F0-7 role-gate coverage gaps (/reports /quote /drafts /runner /masters /search) → intent decision from owner, gates untouched until decided.
7. F0-7 role-gate decision MADE (2026-09-06, owner): "temporarily, till the project is done, we defer roles" — the six screens (/reports /quote /drafts /runner /masters /search) stay open to all logged-in roles for the duration of the build. No role gating now; revisit the per-role composition at Phase 8 hardening (the role-by-role journey run), where the owner walks every screen and the gates are set for cutover. This unblocks Phase 0's last open item (COMPLETION.md F0-7); the only remaining Phase-0 gate is the owner's Verification-Sheet signature.

98. F0-7 role gates deferred to project end (owner, 2026-09-06)

• Decision: "temporarily, till the project is done, we defer roles". Role-gate coverage gaps F0-7 (/reports /quote /drafts /runner /masters /search open to all logged-in roles) are accepted as-is for the build — no role restrictions on those screens until the project is complete. Rationale: the build's focus is flow correctness on real data; premature role locking adds owner decisions no screen needs yet and risks blocking the demo/user walkthroughs mid-build.
• Effect: gates untouched (all logged-in roles can reach all six screens); hooks.server.ts anonymous-write refusal and ROLE_PAGES (Phase-0 security seals) remain exactly as verified in §97.6.
• Revisit point: Phase 8 (hardening & cutover) — the role-by-role journey run sets the final per-role composition with the owner before the single flip to production. Until then, roles never block a work-screen demo.
• Status impact: COMPLETION.md F0-7 row moves from blocked-owner to deferred-owner; Phase 0's only remaining gate is the owner's Verification-Sheet signature (10-min check, see docs/PHASES-GUIDE.md).

99. Client validators removed — dead-submit hang (owner report, 2026-09-06)

• Report: "create gatepass button in /gatepasses/new doesn't do anything". Reproduced in a real headless Chromium against live https://trading.tynolabs.com: clicking submit fired the event, but no POST, no error, no alert — and the same on /bookings/new. Server action + schema were healthy (direct POST → 200 redirect).
• Layer 1 — the door: all of https://trading.tynolabs.com flows through Caddy's :4103 tunnel door, which had HTTP Basic Auth on every path but four static files. A browser fetch POST without the cached Authorization header gets a silent 401 (empty body, no dialog). Per owner: the org-password door is removed completely (the app has its own auth — Better Auth sessions + hooks + ROLE_PAGES). Caddy reloaded; verified 200/303 through the door with no Authorization; LAN doors 4104/4106 un-gated too. Backup: /etc/caddy/Caddyfile.bak-no-basic-auth-20260906.
• Layer 2 — the hang (the actual dead click): after the door was gone, the button STILL did nothing. Interception test (removing validators: from the page bundle): valid submit → POST + redirect to /gatepasses; empty submit → POST + server fail. Conclusion: superForm(data.form, { validators: zod4Client(schema) }) — the client validator — hangs the enhanced submit silently in the bundled runtime (the underlying safeParseAsync/zod bundle path never resolves; no error, no rejection). Affects every page that passed a client validator: /gatepasses/new, /bookings/new, /hishob, /rates, /transporter PickCard.
• FIX: drop validators: zod4Client(schema) (+ the now-unused client adapter/schema imports) from those 5 screens. Validation is and stays server-side only: the action's superValidate(zod4(schema)) runs the exact same schema and returns the exact same messages through fail(400, { form }); field errors and the errors._errors refine alert render through the same superforms machinery one round-trip later. Zero round-trip client validation is banned until the bundle issue is root-caused and proven with a real-browser pass — pinned by regression test tests/no-client-validators.test.ts (94 tests green). UX loss: ~1 request before field errors show; on a LAN that is imperceptible.
• Verification: headless-Chromium E2E (fresh@example.com): fill party + set no → Create → record created, redirected to /gatepasses; empty submit → server error surfaces. BUILD-LOG rev 48.

100. Plain entry forms → kit-native enhance (PLANNING §99 follow-up)

• After §99 the create button WORKED, but two defects remained on the superforms client recipe (verified live, headless Chromium):
  1. Validation errors from the server never rendered — a failed submit was a silent no-op (the form HTML didn't change, no console errors). Cause: superforms' failure display depends on kit's applyAction → $page store propagation (root.$set-driven), which is inert on this Svelte 5 + SvelteKit 2.63 bundle; even superforms' own direct-update path (applyAction: false → Form_updateFrom- ActionResult) produced no re-render. kit's NATIVE use:enhance + the action-result form prop (the orders/new pattern) renders errors correctly (proved in-browser: orders/new error alert appears).
  2. (from §99) the client validator hang.
• FIX — the five plain entry forms switch to the kit-native pattern: /gatepasses/new, /bookings/new, /hishob, /rates, /transporter PickCard. import { enhance } from '$app/forms'; use:enhance on the form; errors read from the action result via the Svelte 5 form $props — const errs = $derived(form?.form?.errors) (field errors under inputs, _errors as the alert). Server actions are UNCHANGED: same route schemas, same superValidate(zod4(schema)), same fail(400, { form }), same setError business checks (hishob). Transporter per-row targeting: the failed result's form.data.id selects which card shows its error.
• Superforms client machinery is banned on these forms (regression pin tests/no-client-validators.test.ts now also asserts no superforms import on the five + no validators: anywhere; 99 tests green).
• Behavioral notes: bindings are now plain DOM inputs (values ride the FormData); kind/direction/weft/GST defaults marked selected in markup; bookings' per-cone/net previews and the rate-hint "Use" now bind to local $state. On invalid submit kit's enhance re-renders in place — typed values are preserved (uncontrolled inputs).
• Verification: E2E headless Chromium — gatepasses/new: valid create → /gatepasses with the new record; empty submit → red alert "Source or target party is required" + no junk row. BUILD-LOG rev 49.

101. Gatepass form is kind-driven (owner, 2026-09-06)

• Ask: "when we select kind, the form fields should change according to full-flow.html". Implemented on /gatepasses/new (existing schema only — no migration).
• Per-kind config (KIND_CFG in the page; mirrors full-flow G0/B0b/C5
  • FIELDMAP §3–§5 + Trading module):
  • YARN_IN — from trader, to our godown/premises/sizer; count, ticket, bags, cones, gross, net + logistics.
  • YARN_OUT — from our godown, to party/weaver; same goods fields.
  • BEAM_OUT — to sizer only; NO goods fields (beam numbers = guard taps from intimation 【SC/T】 at the gate).
  • BEAM_IN — from sizer; sizing set no + warp count; beam grid (BeamNo/Meter/kg, cut-mark, ends, cuts) deferred to the sizing receipt screen (FIELDMAP §3.98).
  • BEAM_REPAIR / BEAM_RETURN — to repairer/party; set no; no goods.
  • WINDING — to winder; sizing/warping set no; bags/cones/gross/net; empties/ring-wt/diff (FIELDMAP §5 / C5) deferred to the winding receipt screen.
  • DIRECT — from trader, to premises/sizer godown; count + bags; expected date deferred (intimation screen later).
• Direction is auto-derived from kind (hidden input; the manual direction select is gone — spec forms each imply a direction).
• Hidden inputs post empty values for hidden fields so one server action (unchanged) keeps working for all kinds; the party-required refine still applies (source OR target).
• Deferred-by-design (not part of this slice): per-kind deep detail — beam grids, cut-mark/ends, winding empties/ring-weight, direct-delivery expected date, GP photo (image field exists) — these land with their owning Phase-4 screens (sizing receipt, winding receipt, beam intimation). Docs: BUILD-LOG rev 51.

102. Phase 2 round 1 — engine verified to sheet + high-severity fixes (2026-09-06, program run)

Owner: "start phase 2. it will be very crucial to get this right. here full flow will be your guide along with all other docs." Audit verdicts and dispositions in COMPLETION.md §Phase-2 ledger. This round:

1. yarnMath — the crucial core. The warp leg was +0.25% off the owner's sheet: the l2l default was 104 → K=110/104=1.0577, while the sheet's verified pair is 110/104.25 → K≈1.05516 (the seeds already said 104.25; the §5 trace's K=1.055 was the rounded form). Corrected defaults (schema, masters, yarnMath fallback) + data-fixed 58 live design rows. Trace re-run: C31/C33/D33 ≤0.003%, ladder ≤0.007% — the known sub-0.01% residual on C20 is the K constant the owner's own sheet-check arbitrates. Also: warping-cost line implemented (spec §3, was hardcoded 0); count≤0/NaN rows skip instead of poisoning the ladder with Infinity.
2. tippanSolver: krill=0 previously LOOPED FOREVER (Infinity parts); guarded + throws. Soft end-slack was unreachable dead code — slack now proposes the slack-reduced part count. Open: cone-measure must also bound parts (BUSINESS.md) — semantics need the owner's winding-process confirmation; ends derivation needs the FIELDMAP width-shrink term (schema column is a Phase-1 item).
3. intake/capture: "please make GP…" forwards parsed as intent=order — gatepass|pickup scanned before the generic order pattern (pin added). Draft images stored the literal junk string ${CAPTURE_DIR}?name — now persisted + served by a whitelisted GET route /capture-img/<name> (draft thumbnails finally render). /capture actions were NOT session- gated (multipart slips past the urlencoded-only hook) — session check + createdBy now. Open: G0/G0b field extraction (bags/gross/net/vehicle/ transport/destination/expected-date) — next slice.
4. ops: no code change this round — findings recorded: sequential numbering (tied to the pending owner numbering decision), role-enforcement into the service layer + reconcile route consolidation, amendments that actually apply (with owner-approval stage per spec §30), mutation+event transactionality (Phase-0 invariant). Each gets its round with regression pins.

• Regression suite 111/111 green; deployed 8d05ddb; COMPLETION ledger + BUILD-LOG rev 52 updated. Verification contract for the phase: PHASES-GUIDE §Phase 2 checks (quote == costing sheet; margin/GST toggles; krill solver; procurement numbers).

103. Phase 2 round 2 — ops service guarantees (program run)

• Role gate INTO the service (was caller-side only — a future caller could bypass it): approveReconciliation/approveHishob now take the session role and THROW unless owner/admin; all three callers (api/approve, approvals page, reconciliations/[id]) pass it through.
• One implementation: reconciliations/[id]'s approve action no longer reimplements the update+event inline — it routes through ops.approveReconciliation (404 pre-check kept).
• Re-approval is a no-op: a second approve on an already-approved record returns false and writes NO second event (audit LOW finding).
• Transactional update+event: each approval's status flip + its event insert are inside ONE db.transaction — the Phase-0 invariant can no longer split on a mid-write failure (audit MED finding).
• api/amend actor from session: by is always session.user.id; anonymous POST → 401. A client-supplied by is never trusted (audit MED finding).
• Still open (tracked): sequential doc-numbering (needs the owner's numbering decision), amendments that APPLY values + the owner-approval stage for tolerance/rate/cancel (spec §30 — needs the owner's amendment-semantics confirmation), /api/events dedupe (client_event_id unique index — schema item), per-row GST toggles, tippan cone-measure coupling (owner process question) + width-shrink column. Regression pins: tests/ops-role.test.ts (6 static pins). Suite 117/117 green; deployed (BUILD-LOG rev 53).

104. Phase 2 round 3 — intake G0/G0b field extraction (program run)

• The capture parser now extracts the gatepass/direct-delivery fields the full-flow G0/G0b forms require: bags · gross kg · net kg · vehicle no · transport · destination (godown/premises/sizer) · expected date — heuristics AND the LLM JSON contract (numeric coercion, never strings). "direct delivery" is also an intent trigger for gatepass. The /capture confirm line shows the goods/logistics summary for gatepass intents (sample buttons include GP + DD forwards).
• Behind-the-scenes: mtrs now actually returned (was declared in the type but never in the return — ReferenceError), a couple of regex capture traps fixed on the way (gross/net pair, transporter name vs vehicle number).
• Regression pins: tests/intake.test.ts (+9: GP goods/logistics, bav variant, DD destination+date, LLM coercion). Suite 122/122 green; deployed; BUILD-LOG rev 54.

105. Phase 2 round 4 — row-aware costing + per-row GST toggles (program run)

• Spec 6b (the Android costing app) models up to 4 warp + 4 weft rows, each with Count · % · Rate · GST% · Incl.GST toggle, plus per-warp sizing rate (GST%, toggle). The engine now supports exactly that: computeCosting takes a row-aware path (per-row rates honouring the incl/excl GST toggles; base = rate/(1+g/100) when inclusive) and computeDesignWeights returns per-row kg/m. Result adds gstTotal + per-row cost breakdown; totalInclGst = totalExGst + gstTotal.
• Backward compatibility is deliberate and pinned: rows WITHOUT rates keep the verified single-rate trace path byte-identical (all 31 yarnMath pins, incl. the COSTING §5 trace, green).
• UI note: no entry screen feeds per-row rates yet (the design form uses count/system/pct tuples) — engine-first per the phase order; the row-aware entry UI belongs to Phase 3/4 (worth a 10-min owner look at spec 6b's per-row toggles then). Suite 126/126; deployed; BUILD-LOG rev 55.

106. Phase 2 round 5 — bounds, dedupe, honest amendments (program run)

• Intake numeric sanity bounds (dateGuard precedent, PLANNING §94): count/qty/mtrs/rate/bags/gross/net outside generous realistic ranges are treated as unknown — an absurd parse artifact never lands in a draft.
• OCR retention: the tesseract exit code is now checked; a failed run keeps the photo in the draft for manual fixing (was: could silently produce an empty-text draft whose image was already stored but the text path misbehaved).
• /api/events dedupe: the ingestion boundary now checks clientEventId before insert — retries/double-forwards answer dedupe:true and store ONCE (live-verified). The unique index on evt.client_event_id is deferred to the Phase-1 migration pass so migrations stay Phase-1's capture.
• Honest amendments: note-only amends (orders/gatepasses) no longer write byte-identical before/after snapshots — the reason IS the note; appendAmendment gains a genuine fields: {field: {before, after}} diff path for the Phase-3 field-level amend form; the APPLY + owner-approval stage for tolerance/rate/cancel (spec §30) still awaits the owner's amendment-semantics decision (recorded blocked-owner).
• Regression pins: tests/phase2-round5.test.ts (7). Suite 133/133 green; deployed 760d5f3; ledger refreshed (0339198); BUILD-LOG rev 56.

107. Phase 2 round 6 — quote job line + the owner's one-link check (program run)

• Verification-sheet prep caught a real bug on the Quote screen: its computeCosting call never passed pick, so the Job-work ₹/m line was always ₹0 (the costing sheet's C28 5.76 was missing from every quote). Fixed (pick: d.pick) + pinned. BUILD-LOG rev 57.
• One-link spot-check: seeded a "COSTING SHEET EXAMPLE" design (e2e-design-costing: the exact §5 construction — reed 120 · 65" · 41/41 Ne · K 110/104.25, rates 330.25/305, sizing 23, job 9). The owner's 10-minute Phase-2 check: open /quote?designId=e2e-design-costing&mtrs=1000 and compare the ladder to C21/C25/C30/C28/C31/C33/D33 (39.15/19.19/2.73/5.76/66.82/71.16/74.72). Live-verified the ladder renders those exact cells.

108. Phase 2 round 7 — ticket false-positives + LLM-path bounds (program run)

• 'super'/'gold' dropped from the mill-ticket list (audit: prose like 'super quality' produced ticket SUPER; 'ssm gold' stays). LLM-coerced numbers now honour the same sanity bounds as the heuristics.
• Phase-2 autonomous work is now exhausted — all audit findings fixed and pinned (138 tests). Remaining: the owner's one-link 10-minute check (quote == costing sheet) + signature, and the four flagged decisions. BUILD-LOG rev 58.

109. Sequencing correction — Phase 1 is the intended phase (owner, 2026-09-06)

• Owner: "what I meant by phase 2 was phase 1. it was a misread on my side." The engine/services run executed under the Phase-2 label stands as-is (spec-audited, verified, deployed — COMPLETION ledger §Phase-2; its Verification Sheet remains open for the owner's sign alongside). Phase 1 (Database complete — the filing cabinet) is now the ACTIVE phase: every table/column and every form's fields per FIELDMAP.md and the paperwork-derived specs; status/dropdown value sets formalized (order.status open→in-prod→delivered→closed · gatepass.status incl partial/due · roll grade/status A/B/C/R/+reject, lumps · bale entity decision); tenancy seams on all 27 tables; migration series 0000–0008 vs live data.db (drift); company identity/GSTIN; gaps via migration 0009+ (warp_shrinkage_pct …); imported-data integrity (909 contracts · 6,688 beams · 2,048 lots · 468 parties intact). Status in COMPLETION.md → in-progress. Audit fan-out with field-family agents; findings land in the COMPLETION Phase-1 ledger; Verification Sheet at phase end.

110. Phase 1 round 1 — audit consolidation + schema expansion (program run)

• Audits (4 agents + direct verification): tenancy 27/27 PASS · migrations 0000–0008 valid, zero push-vs-generate drift (live DDL == snapshot; series applies clean on scratch) · imported data intact (909 contracts · 6,686 beams +2 fixtures · 2,047 lots +1 · 464 parties +4) · masters 5/5 KEEP: Party/Yarn/Loom/Flange complete; Design gaps fixed below.
• Masters fixes: warpingRatePaise (was never written — the quote's warping leg was always ₹0), glm, gstPct, warpShrinkagePct authorable from the DesignForm; multi-row JSON now carries [count,system,pct,rate,gstPct, inclusive] through parse+store (spec-6b rows); PartyForm Transport.
• Migration 0009 (applied; corrected rebuild — drizzle's generated INSERT-SELECT read new cols from the old table; fixed + manual apply, 609 design rows preserved): design.gst_pct · design.warp_shrinkage_pct · beam.kg · booking.gross · gatepass.partner_gp_no · gatepass.transfer_year · movement.transfer_year · dispatch_slip delivery_address/bill_no/tag_nos · UNIQUE idx evt_client_event_id_idx (dedupe collision-safe).
• Ledger: COMPLETION §Phase-1 + BUILD-LOG rev 59. Suite 141 green, journey 53/53, deployed 4724e0d.
• Open (owner-gated / deferred): GSTIN (decision ①) · bale/lump entity (③) · sizing-receipt/weft-issue/winding-receipt screens+columns (Phase-4 spines) · contract_lines per-beam grid · fabric-inward screen · status text({enum}) formalization · journey-residue cleanup (§83).

111. Phase 1 round 2 — value-set formalization + Verification Sheet (program run)

• Value-set sweep: the write-site census (grep of all status/kind/type writes) showed the live sets extend some documented lists (beam.status carries TWO lifecycles: tippan draft/intimated/issued + floor/getting/ onLoom/finished/repair…; roll.grade includes WIP 'W'; amendment.kind gains 'allocate') — so a DB CHECK/text-enum sweep would have been wrong-footed. Instead: docs/VALUE-SETS.md formalizes every enum column (formal set + live range + governance), app-layer contract (owner-approved in the sheet); the beam-status split and roll-grade W are recorded as owner/Phase-4 mapping items.
• docs/VERIFICATION-PHASE1.md drafted (What/Why/How-proven/5-min spot-check: party/yarn/design fields, create one of each, imported counts; the two owner gates GSTIN · bale/lump; deferred list). STATUS pointer updated. Deployed 7597756 (BUILD-LOG 60).

112. Row-click detail dialog — app-wide standard (owner, 2026-09-06)

• Owner: "for all the forms when a row is clicked it should open the entry in a dialogue box like in masters. Document that this UI applied across."
• Built: shared RecordDialog.svelte (+ SmartTable rowClick prop with control-tap guard) → tap any list row opens the entry's key fields in a modal with an "Open full record" action; masters keeps its richer edit-inline dialog as the reference. Documented in UIPATTERN.md ("Row-click detail dialog — APP-WIDE STANDARD") — every list screen must follow it; orders is the live reference, the remaining list screens wire the same recipe. Mobile-first (bottom-sheet + internal scroll).

113. Orders UI clarity pass (owner, 2026-09-07 — "highly confused")

• Owner: the /orders list + new form + detail record are confusing. Agreed pareto fix, owner delegated all decisions: plain language everywhere, real progress, shorter-feeling form, scannable detail. No schema change, no flow change, append-only intact.
• List: Kind shows plain labels (Sale · Job-work · Outsource · Stock) with a one-line legend; Mode hidden when unset; Date → Booked; Rate → ₹/m; full status pills (open/in-prod/delivered/closed); totals split by unit (mtrs vs beams never summed); new Progress column (rolls ready / sent from roll + dispatch aggregates, read-only).
• New form: 4 numbered sections (Kind → Party+Quality → Qty+delivery → Price & terms, last one collapsible-optional); single type select (hidden+typeSelect pair removed); Design becomes a Combobox like Party; every jargon field gets a plain hint (CD/dhara, 3 day-fields disambiguated); only Party + Qty marked required (matches server).
• Detail: 19-row flat Terms → 3 grouped cards (Contract / Quantity & delivery / Price & terms, null rows hidden); header shows order value (qty × rate) + progress line; designName bug fixed (d.name → qualityName); Events + Amendments merged into one newest-first History timeline with humanized payloads; new Linked documents card (lots, beams, tippans, rolls, dispatches, hishob — read-only, capped).

114. ALWAYS deploy — governance rule (owner, 2026-09-07)

• Owner: "add in docs to always deploy" — every turn that touches code or docs ends in a deploy.sh run (or a doc-only commit + push). A change that is not live + pushed is not done; never leave a fix built-but-undeployed or committed-but-unpushed.
• Parallel sessions do not excuse holding a deploy (deploy.sh commits the whole tree via git add -A — coordinate via git status + pull-rebase, never by skipping the deploy). Recorded in AGENTS.md Mandate 1, docs/DEPLOY.md deploy loop, docs/STATUS.md Rule 0.
• Same turn also fixed the each_key_duplicate crash: keyed {#each ... (key)} blocks used label/day/JSON keys that repeat (dashboard KPI labels, reports identical rows, SmartTable object keys). All risky keys now carry the list index (label + '|' + i), so a duplicate value can never crash the page again.

115. each_key_duplicate root cause — orders ListToolbar totals (2026-09-07)

• The §114 key-hardening did NOT stop the crash: the live /orders page still threw each_key_duplicate (stack pointed at orders:35/36).
• Root cause: the §113 split totals build TWO entries with the same label ({label:'ordered'} for mtrs + {label:'ordered'} for beams whenever both are nonzero), and ListToolbar.svelte keyed its totals row by (t.label) — a guaranteed duplicate key, not a data edge case.
• Fix in the shared component (not the caller): ListToolbar keys totals, filters, and filter-options by label + '|' + index, so no caller can crash it again whatever labels it passes.

116. UI uniformity pass (owner: "uniformly styled throughout", 2026-09-07)

• Audited all 70 Svelte files vs DESIGN.md/UIPATTERN.md: site is ~90% uniform already (no dark mode, no rogue navbars, tables/forms/modals share one language; print sheets + external confirm page deliberately distinct). Three deviations fixed, markup-only, no behavior change:
• (a) Create CTAs were split indigo/black — now ALL btn btn-primary btn-sm + Plus icon (orders, gatepasses, tippans, bookings, rates, leads, reconciliations; masters/beams already matched). Print/reveal and secondary nav buttons untouched. Standard: indigo = interact.
• (b) Masters headers sized up to the standard (h1 text-2xl font-bold, section h2 text-lg font-bold).
• (c) Redundant thead bg-base-200/60 classes removed (checking, hishob, approvals, tippans) — the zinc-50 strip comes from app.css globally, same as SmartTable and every other list.
• Left alone: board-page emoji headers (owner-frozen BOARDS-A data), shell search + combobox raw classes (allowed shell/dropdown chrome).

117. Orders segregated by kind (owner: "get lost seeing the orders", 2026-09-07)

• One flat table mixed four businesses (Sale / Job-work / Outsource / Stock) — now tabbed by kind with live counts (All + 4 tabs, daisyUI tabs-boxed). Tabs share the search/status scope; switching kind resets the page. Server adds one GROUP BY count query (kindCounts, same scope minus the kind filter).
• The Kind dropdown is gone from the toolbar (tabs replace it — one mechanism, not two); Status filter stays. Heading reads "Sale orders" etc. under a tab; the kind legend stays as the teacher. Empty kind → "No Sale orders" + "Show all orders" instead of the misleading first-order prompt.

118. Segregation tabs on five more lists (owner: "proceed", 2026-09-07)

• Same §117 pattern rolled out: beams by status (Finished/On loom/Floor/ Repair), lots by owner (Own yarn/Party yarn), gatepasses by direction (In/Out), tippans by status (Draft/Issued), bookings by warp/weft. Each screen gets one GROUP BY count query (same scope minus the tabbed filter) and the tabbed dropdown leaves the toolbar — one mechanism.
• Labels are plain words with raw-value fallback, so new future values still render. Tabs are data-driven (All + live values), counts share the search/other-filter scope.

119. Full-flow form audit crew (owner: "full flow is your bible", 2026-09-07)

• Owner: every form in static/full-flow.html must carry every listed field with the listed input mode (S/T/N/X/…) plus the listed auto-calc/autofill behavior — no deviation. Example gap: lead form missing source, broker, follow-up date, status.
• Method: 12 parallel audit agents (one per form-family), spec-vs-code, read-only. Each returns per-field verdicts classified OK / MISSING-UI / WRONG-TYPE / NEEDS-SCHEMA / NEEDS-LOGIC / NEEDS-OWNER. Fixes fan out afterwards per form; schema gaps batched once first.

120. Fix crew GO (owner: "no need for the list. fix it", 2026-09-07)

• 12/12 audits in. Schema batched into ONE migration 0010 (lead channel/ broker/follow-up/alias/tags; order date/remark/jobRate/picks/beams- source/trigger/target/terms/tcs/gp-leg; GP date/endorse/expected/ cones-per-bag/pickup trio; lot booking/parts; movement machine-source/ barcode; tippan notes; roll mended/doff/machine/parent/location/L2L/ shrink/RS; slip variant/actuals; hishob loans/photo; new tables gatepass_link, fabric_in, quote, stocktake). Backup: backups/data.db.pre-phase1fix-20260907.
• 12 fix agents on disjoint route dirs in parallel; shared libs (lots.ts/queue.ts/board.ts/c-route/intake/ops/engine) hands-off — NEED-HOOKs batched by coordinator. NEEDS-OWNER skipped everywhere (bale/lump entity, Tally, calendar, net auto-vs-manual, IoT).

121. Quote screen gets the costing-app input fields (owner, 2026-09-07)

• (Numbered 121 — the fix crew's "Fix crew GO" took §120 in parallel.)
• Owner: "/quote has no input fields — refer the app screenshot and the yellow cells in the Google sheet for what inputs are needed." Found in repo: the Fabric Costing app screenshots (screenshots/20260902-50566843… 11:38 series) show the full input set — Construction (Reed, Pick, Warp/ Weft Reed Sp., Warping Rate Ps/Mtr + GST%, Job Rate Ps + GST%, Siz. Wajan Vaad %, Lasa, L2L, Weft Waste %, Other Expense %, Warp Division Pr/Me) + Warp Details rows (Count, Warp %, Rate, GST %, Incl toggle + Siz. Rate, GST %, Incl toggle, ADD WARP ×4) + Weft Details rows (same shape ×4). The sheet's yellow cells are the same set (COSTING §1).
• Build: /quote becomes input-first — all of the above editable on the screen, prefilled from the picked design, outputs unchanged in math (Majuri output row = the job line). Engine gaps closed in the same slice: per-warp Siz. Rate rows + per-line GST% on Job/Warping rates (legacy single-rate path byte-identical, pinned). Warp Division rides as a sticky select only — its math meaning is still the open COSTING §6b question (Pr/Me = per-meter basis?), asked of the owner.
• Recovery note (same day): the fix crew committed orders/new (854a4a4) via a full-tree stash, sweeping this slice into stash@{0}; the crew's own quote rebuild (bible A2, quote table, save action) had already absorbed this slice's engine fields (jobGstPct/warpingGstPct/siz rows) and its indexed-rows/prefill pattern. Restored from the stash ONLY the crew-independent files (yarnMath + 2 test files + docs); the quote screen itself stays with the crew's rebuild. Crew note: the stashed quote server has a fatal export function resolveQuoteInput / calcQuote (SvelteKit allows only load/actions/etc. — every /quote visit 500s until unexported/moved to lib). And do NOT stash pop blindly — restored paths will conflict; check out remaining crew files selectively.

122. Interruption recovery (2026-09-07, coordinator)

• The "fix it" fan-out was interrupted mid-flight: 4 fix agents reported (lead/sample/order/gatepass), 8 never ran; uncommitted crew files were lost from the tree — but the order agent's full-tree stash (stash@{0}, 64 files) held the killed crews' work and was checked out selectively (route dirs only; docs/drizzle/engine/tests left alone).
• Repaired after checkout: quote server fatal value-exports (unexported in place), same flaw in hishob legsForContract, movements REASONS, loomgate shiftOf, lots effectiveHolds, planning RESTART_PREFERENCE / expFinishOf / proposeNextBeam; reconstructed 3 lost helper libs (leadLogic, dispatchLogic, hishobLegs) + their test pins; fixed the red schema pin (stale /home/fp/sites/trading DB path); restored the dropped evt dedupe unique index.
• Schema foundation re-applied to match live DB (migration 0010 objects survived in data.db); regenerated as drizzle/0010_first_amazoness. Orphan beams dialog fragment (dead data.contracts ref) removed; C6 warp/weft/weave wired into the beams pick instead.

123. Verification pass over the recovered tree (owner: "go ahead", 2026-09-07)

• Journey suite (53 steps, live) + 6 lane verifiers, one per area (commercial / yarn / warp / weave / check / dispatch). Each fix is checked end-to-end: form input name → action reads it → column written → display reads it. Small breaks fixed in-lane; bigger ones come back as FAIL items with file:line.
• Result: 6/6 lanes PASS (with in-lane fixes: drafts stray markup, sample rate flag, gatepass chain strip, movements modal rewrite, guard per-beam taps, stocktake + sizing + winding + fabric-in + beam-end new routes, tippan/beams/transfer/outhouse, checking orderId/WIP-grade, dispatch Part badge + hishob print shape + exports). Journey caught 4 stale expectations (not regressions) — hishob now generates as sent, quote outputs read Basic/With-GST, dispatch load needs confirm+vehicle, record page marker is Contract — journey updated, 53/53 green.

124. What Phase 1 acceptance covers (owner question, 2026-09-07)

• Owner: for Phase 1, check only that fields exist — or also that they function as intended? Answer from the program contract: BOTH, but scoped. COMPLETION.md Definition of Done (all six, per slice): (1) fields present + right entry mode, (2) flow works end to end (a completed step creates the next step's record, no dead-ends), (3) prints at external boundaries, (4) dump works, (5) real data sane, (6) checks green.
• Phase map for functioning: Phase 1 = structure (fields save correctly); Phase 2 = engine math (quote == costing sheet, verified); Phase 3 = platform behaviors (search/filter/amend/approve consistency); Phase 4 = transactional spine — THE functioning phase (each step creates the next, statuses move by the work itself). Owner signs the sheet, not the code; a slice that fails on real paper REOPENS.
• Rule: Phase 1 sign-off needs (a) bible fields + modes, (b) create/save
  • basic move flows working (spot-check + journey 53/53), (c) counts intact. Cross-step postings/closes (amendment apply, ledger postings, hishob close postings, Tally) are Phase-4 acceptances — failing ones go to the Phase-4 ledger, never block Phase 1.

125. Guided-form pilot: orders/new + gatepasses/new (owner: "pilot", 2026-09-07)

• Pattern (Enter → Verify → Review): one section open at a time with Next buttons; sticky context bar (tally facts) + section chips (✓/•/○ bird's-eye, tap to jump); prefilled inputs carry a badge until touched; auto values grouped under "For checking (auto)"; sticky bottom bar (fields-left + Review & create); review bottom-sheet lists every value (auto-tagged, tap row to jump back) and only its Confirm submits. New shared primitives: GuideChips, ContextBar, ReviewSheet.
• Behavior unchanged: every POST name/action/handler identical; review is UI-only (server accepts direct posts, journey unaffected). Provenance badges are touch-based (history-filled until typed over).
• Scope cut (owner: "orders only for demo"): gatepasses/new reverted to its classic form; the pilot lives on /orders/new alone. §126 compacts the sticky bar (one card, autohide on scroll-down) and makes jumps real buttons (primary/outline/ghost) vs plain-text facts, with chevrons on section headers.

126. Compact guided header (owner feedback, 2026-09-07)

• Banner ate the screen + clicks looked like info. Fix: GuideHeader — facts one truncated text-xs line (info, untappable) + btn-xs jump buttons (primary current, outline+✓ done, ghost todo); whole bar auto-hides scrolling down, returns scrolling up; section headers got rotating chevrons. GuideChips/ContextBar removed.

127. Menu-cards instead of a sticky bar (owner: "still not good", 2026-09-07)

• Two complaints: bar cost screen space + sat oddly low; tabs never looked tappable. Fix: NO sticky top element at all. A static 2×2 menu of big section cards (number badge, title, live summary, explicit "Open →"; active = primary tint, done = green ✓) scrolls away naturally; the sticky bottom bar now carries position (2/4), live facts (party · qty · rate), Back, and Review & create. Tappability comes from card borders + buttons, not tab styling. GuideHeader removed; sections/review/prefill badges unchanged.

128. Simplicity pass for non-tech-savvy users (owner, 2026-09-07)

• Words over symbols: headers read "Step N of 4 · …", menu labels are Kind/Buyer/Quantity/Price; empty summaries direct ("Needs: buyer name", "Needs: quantity", "Can skip") instead of reporting state.
• Clearer action words: "Review & create" → "Check & save", confirm "Save order"; subtitle counts four steps.
• Forgiveness: ghost "Clear" button in the bottom bar resets every typed value (keeps URL context), back at step 1. Nothing else changed.

129. Guided rollout to every form (owner, 2026-09-07)

• Demo approved on /orders/new. Rollout: one agent per form — leads, bookings/new, tippans/new, quote, samples, checking, dispatch, movements, gatepasses/new (re-apply), hishob+reconciliations, stocktake+sizing+winding+fabric-in+beam-end. Same pattern: section menu cards + sticky bottom bar (position+facts+back/review) + review sheet + prefilled badges. UI-only: POST names/actions/handlers identical; sections CSS-hide (never unmount inputs); no server value exports. UIPATTERN entry standard follows the rollout.

130. Phases 2→3→4 sequential program (owner, 2026-09-08)

• Owner: fields are ~all there; checking now means functioning, which lands after Phase 4. Refer full-flow + docs throughout, phases sequentially, multiple agents (never overload one), sign 1–4 at once.
• Phase 2 (parallel session owns engine): my lane verifies engine CONSUMERS after the guided rebuild (quote/tippan/procure outputs vs pinned traces) + collects the 4 owner-blocked decisions. Engine files hands-off.
• Phase 3 (mine, 3 agents): record verbs (amend/approve/print on every record page) · list-standard gaps + dumps · error banners + combobox sweep. Phase 4 (mine, after 3): spine slices in dependency order with per-slice DoD (fields · flow · print · dump · real data · green).
• Joint sign-off: 6 owner calls (Phase-1 GSTIN + bale/lump; Phase-2 numbering + cone-measure + amendment-apply + per-row-GST-UI) + the four Verification Sheets + one real document per slice.

131. No raw ids on screen (owner, 2026-09-08)

• Owner: some pages show data ids, meaningless to any user (even admin). Rule: screens show doc numbers / names / dates only; ids ride hidden inputs + URLs, never visible text. Unresolvable links render '—'.
• Fixes: drafts table drops the id column · masters toast drops the id · transporter due-slips show roll marking (rollNo in DueSlip) + PickCard uses beam/lot labels (new server maps) · guard gains lotLabels, all id-slice fallbacks gone · gatepass detail fallbacks '—' · sizing + winding recon rows fall back to date + Expected/Actual parse kg out of the stored JSON (no JSON dumps) · dispatch roll fallback '—' · orders/new draft options fall back to capture date · beam-end event list shows words (Ended/Restarted/…) + reason/mode/kg instead of JSON.

132. Ergonomics round 1 — toasts + de-jargoning (owner, 2026-09-08)

• Owner compares us to textile-erp-nextjs + gray_fabric_erp and finds ours heavy. Read both: their edge is workspace pages (one contract = one screen, inline sheets), sheets+toasts instead of wizards, visual status (kanban/gantt), scan/print bridging, plain words. Their cost: no append-only audit, no approval gates — we keep ours; heaviness moves into the machinery, not the user's face.
• SHIPPED now: app-wide toast infra (src/lib/toast.svelte.ts + Toasts.svelte in layout, daisyUI only) wired on guard (exit + reconfirm) + transporter pickup · all bible markers (【T】/(N)/…) stripped from rendered text (beam-end, planning, fabric-in, loomgate, tippans/new, quote, beams detail, winding); comments keep them for traceability · UIPATTERN tap-feedback standard. Home already has the attention strip + KPIs, so no new owner strip.
• DEFERRED for owner sign-off (change signed UX): removing ReviewSheet gates on small acts · 360° object workspaces · scan/print bridging.

133. Reference color language — near-black CTAs (owner, 2026-09-08)

• Owner asks about layout + colors vs the two reference ERPs. Tokens already match textile-erp-nextjs (§52: zinc-100, white 20px cards, Inter, indigo pills in sidebar) — the gap is USAGE: our ~80 btn-primary made every action shout indigo, while both references use near-black buttons and reserve color for status.
• SHIPPED (light-only; theme pin + ui.test guard untouched): main CTAs app-wide Save/New/Check/Confirm/Pick/Post → btn-neutral (incl. the ReviewSheet Confirm); indigo stays for selection states, auth CTAs, links, active nav, focus, xs toolbar utilities · list status badges render statusWords() (src/lib/labels.ts: in-prod → In production) via SmartTable · DESIGN.md button rule updated. Indigo links/badges/ pills unchanged.

134. Table reading ergonomics (owner, 2026-09-08)

• Owner: readability + data tables need ergonomic reading. Date columns were rendering raw ISO timestamps (createdAt passed straight through); headers scrolled away on long lists; numbers/text had no discipline.
• SHIPPED in SmartTable (one component → every list, light-only): sticky thead in a max-h-[75vh] region (thead bg moved to th so it occludes) · semibold first column · tabular-nums numerics · ISO → "08 Sep 2026" · long text 2-line clamp + tooltip · filter popover values formatted the same way · badges already via statusWords(). UIPATTERN list standard updated.

153. Quote single-form rebuild (owner, 2026-09-10)

• Owner: quote tabs don't suit it — one continuous form; save 500s; no share button; calculator fields illogical; lead→quote must prefill everything; previous-quote prefill (sizing rate, L2L, reed, pick); party→top-qualities→select fills all but warp/weft rates; yarn picked as whole name (61 CCW Sanathan) with rate-board confirm; ticket preference carried forward. One agent owns the whole form.

152. Continuous-task protocol (owner, 2026-09-10)

• Owner keeps writing tasks/corrections here while work runs. Rules: (1) one agent per task — narrow brief, owned files only, so no context burden and nothing hallucinated or missed; (2) overlap check on every new task vs running lanes — risky ones queue and run sequentially, never in parallel; (3) coordinator integrates (verify + deploy + journey) between waves. Queue is visible in chat.

151. Status-to-action wave (owner thumb rule, 2026-09-10)

• 6 agents: every tap audited; bare flips converted (lead move → evidence details, quote accept/expire confirm gates + notes, approvals note-gated, bookings/GP/inward evidence inline, planning next-beam picker, fabric confirm + resize gates, checking attestation, dispatch receiver+POD+confirm, samples/runner notes, quote accept/expire confirm gates). Server persists every evidence field into its event (leads/quote/approvals/bookings/GP/inward/signoff/deliver/samples/ runner); recon approve + waiver notes logged without touching ops. Skipped with visibility: recon applied effects, weft-issue route, RB→lot linkage, beam ?lotId, folding screen.

150. Thumb rule: no status-only buttons (owner, 2026-09-10)

• Owner: no action button may merely flip a status. Every button leads to an action (opens the work form/screen prefilled, or captures the work evidence); the status update is the action's consequence, never the action itself. Applies to all forms, incl. taps (guard exit, transporter pick, grade, load) which must carry their evidence (vehicle/photo/counts) or open the next step.

147. Modal mixing fix (owner: lead dialog, 2026-09-09)

• Owner: dialogue box mixed with the background page. Root cause: native <dialog class="modal" open> never enters the modal top-layer (no backdrop/dim). RecordDialog converted to div-based modal-open (ReviewSheet parity) + Escape close; all 7 amend modals gained modal-open bottom-sheet classes. P3 pins updated.

131. Quote app-parity: dynamic warp/weft rows + per-row Incl (owner, 2026-09-08)

• Owner: costing engine not done right — warp 2,3,4 must expand, not sit expanded; same weft. Compared the 11:38 Fabric Costing screenshots row by row: Warp1/Weft1 always shown, ADD WARP/ADD WEFT appends to 4, X removes, per-row Count/%/Rate/GST%/Incl (+ Siz Rate/GST/Incl per warp).
• Built exactly that on /quote (UI): rows render 1..n only; X splices (indices renumber, server reads by position — consistent); ADD caps at 4; per-row Incl. GST checkboxes (wix/wsix/fix) incl. save-form mirrors. Server (route-owned, engine untouched): checkbox ticks force inclusive per leg; unticked rows follow the toggle byte-identically (legacy pinned traces green). Engine files hands-off (parallel lane).

144. Booking → gatepass → inward chain (owner, 2026-09-09)

• Owner: yarn bookings never led anywhere; booking → gatepass/DD → inward (internal/external) didn't flow. Fixed: bookings rows/dialog link /gatepasses/new?bookingId= (form defaults to YARN_IN + fires the booking prefill); DIRECT lots take location from the target (sizer-category → sizer/external, else godown/internal).

135. Order–quote link (owner, 2026-09-08)

• Owner: orders aren't linked to quotes; while creating an order the open quote list should show (link optional — orders live without quotes too). Built: order.quoteId (migration 0011) + open-quote picker on /orders/new (design + final rate prefill, still editable, linked banner) + review row + quote accepted on create + quote shown on the order record. Stale-quote submit fails with a plain message.

132. Phase-4 NEED-HOOKs closed by coordinator (2026-09-08)

• lots.ts: DIRECT gatepasses now create lots on delivered (setNo ?? gpNo, party/parked rule, lot:created carries direct:true).
• Guard due-list: imports listDueSlips + renders pre-slip rolls (F1 reaches guard, not just transporter).
• A5 on order create: requirementKg (qty × design kg/m, non-OUTSOURCE)
  • yarnExpected (JW) ride the order:created payload.
• C3 gate on recon approve: approved sizing recons with winding kg fire one WINDING GP (idempotent via sizing:winding-gate event).
• Dump edge: hishob + rates + movements slugs added (reports.ts).

136. OCR: open-source only, handwriting-capable (owner, 2026-09-09)

• Owner: OCR must be open-source, no subscription. Server (4GB RAM, docker, no GPU) had tesseract eng-only — installed hin+mar packs (apt) so printed Marathi/Hindi slips read; handwriting still weak.
• Agreed two-tier, all free: (1) tesseract eng+hin+mar now (offline, zero cost); (2) self-hosted vision model (Ollama qwen2-vl/moondream class, local docker, no per-page fee) for handwritten beam tables, tesseract stays as fallback. Test pending: owner uploads the Radhakrishna beam gatepass via /capture photo tab; raw OCR + parse compared against manual read (PLANNING test: gist = intent gatepass ok, beam table/customer/set-PO missed by current heuristics).

137. Beam-gatepass OCR test results + first hardening (owner, 2026-09-09)

• Test: owner uploaded the Radhakrishna beam gatepass via /capture (draft h0zou1hvhand, image kept). Old pipeline (psm-3 eng-only) stored intent=unknown + fragment text.
• Manual re-runs: eng psm-6 reads the printed header (sizer, address, BEAM GATEPASS, 29-08-26, CHARBHUJA inward stamp); handwriting (customer, quality, 4-row beam table, set/PO) lost in ALL configs; hin/mar packs add noise on English slips (kept for Devanagari ones).
• Fixes shipped: capture OCR now eng+hin+mar × psm 6/3 vote (longest wins, image always kept); intake gatepass intent matches glued "BEAMIGATEPASS)" (bare-substring + beam-no cues). Re-run on the uploaded photo: intent=gatepass (was unknown). Handwritten rows + date ("vate. 29-08-26" D-misread) stay for the self-hosted vision tier (§136) — no subscription path.

138. Reverse pickers everywhere (owner rule, 2026-09-09)

• Rule: dependant forms offer upstream records and carry every available field forward. 5 agents, disjoint lanes: quote (lead picker
  • estQty col, migration 0013) · orders (lead picker + convert on create, estQty→qty) · bookings/gatepass (procure/rate verified; order→booking assessed-out 0 fields; booking→GP picker added) · mid-flow (tippan contract context, dispatch party/city/tolerance, checking beam panel; hishob/samples verified, samples-lead fuzzy skipped) · small screens (sizing/winding carry buttons; rest assessed-out). Prefill-only where no link column exists; no silent overwrites (empty-only fills).

139. Full-field prefill pass, per form (owner, 2026-09-09)

• Owner: quote-picked party showed in the header but never filled the field; redo reverse pickers per form missing NO field, full-flow as guide. Root cause was shared: Combobox snapshotted label once and never re-synced — fixed with a label-change effect (typing never clobbered since typing doesn't alter label).
• 11 agents, one form each: full-field audit (every field × full-flow mode × every upstream source incl. leads/quotes/drafts/bookings/ gatepasses/designs/rates/history) then implement ALL gaps.

140. Coordinator NEED-HOOKs batch 2 (2026-09-09)

• Movements: lotOptions + yarnOptions + order party/quality labels + per-loom shift options (2-shift Day/Night, 3-shift M/E/N).
• Dispatch: copies multi-select on load-confirm, persisted to actualJson, print defaults from stored (was customer-only).
• Hishob H1: legsPreview per open contract. Recon R1/R2: setNo datalist from gatepasses + expected hints from prior recons.
• Checking A/B/C: design lasa/L2L targets, order party/quality labels, checkin returns beamId/orderId (grade jump needs no fallback).
• Deferred with owner visibility: recon receipt persist (no column), lot.bookingId link (needs GP booking ref), folding screen, Tally, bales, slip-OCR parse, warped-out machine suggest.

142. Forward linkages (owner, 2026-09-09)

• Owner: every record must show the button to its next step (e.g. every lead shows Quote). 7 agents, one area each: audit current next-links vs full-flow, add missing create-next buttons prefilled via query params (existing ?designId= pattern), tests, no commits.

141. Field validation pass, per form (owner, 2026-09-09)

• Owner: while checking, put relevant validation on each field — numerics reject alphabets, mobile 10 digits, GSTIN format, etc., full-flow per field per form. 12 agents, one form each: client (inputmode/pattern/maxlength) + server (visible field errors, never silent ||0) + tests. Reference formats: mobile /^[6-9]\d{9}$/, GSTIN 15-char, PAN, PIN-6, % 0–100, qty/counts > 0, dates sane.

143. List-screen ergonomics pass — toolbar + empty states (owner, 2026-09-10)

• Owner: "real people will use this — more ergonomy + professional look on each page, mobile/desktop." Full-screen visual audit (39 routes × desktop 1280 + mobile 390, screenshots) found ONE cross-cutting defect and two consistency gaps.
• Defect — ListToolbar renders as a centred vertical column. The shared src/lib/components/ListToolbar.svelte (used by ~13 list screens: orders, lots, beams, bookings, gatepasses, tippans, samples, leads, drafts, movements, hishob, rates, reconciliations) put the filter row inside a daisyUI card-body, whose CSS sets flex-direction: column — the Tailwind flex class only sets display, so the search input + filters + Search/CSV buttons stack and centre into a 176px-tall column on desktop instead of one compact horizontal toolbar row. Fix: replace card-body with a plain flex flex-wrap row, and merge the totals line + pagination into a single justified footer row (saves ~1 row). Markup-only; all names/method/GET behaviour unchanged.
• Consistency — SmartTable empty cell (27 screens): the bare "Nothing here yet / No matching rows" line becomes a centred icon + title + hint so empty lists read like the rest of the app, not a stray text line.
• Consistency — movements empty state: the page-level bare <div class="alert">No movements recorded yet.</div> becomes the standard centred icon card (icon + "No movements yet" + one-line hint) so it matches the other list screens' empty states.

146. Broker strictly from masters (owner, 2026-09-09)

• Owner: broker fields allowed manual entry; must come only from masters — leads, orders, bookings. All three broker inputs are now Broker-category selects (empty allowed); server rejects non-master names; history prefills carry only masters-listed names.

149. Lead save feedback (owner: save looked dead, 2026-09-09)

• Owner: review closed but the form stayed — looked unsaved. Truth: saves WORKED (two "Jam" dupes today prove the retaps landed).
• Fix: create returns {ok, id, leadNo}; enhance shows ✓ toast with the lead no + resets the form; failures toast the error. Same toast pattern as guard taps (§132).

154. Pending-corrections shelf (owner, 2026-09-10)

• Owner: "create a list of pending corrections in the documents. I will keep supplying you the corrections and you will keep entering it into the documents."
• New shelf: docs/CORRECTIONS.md — Pending table (owner's words, target doc + section) + Applied log. Protocol: every supplied correction is entered on the shelf first, then applied to the named document, then ticked off — same commit updates the shelf so nothing goes stale.

155. Corrections shelf rules: per-form breakdown + continuous worker (owner, 2026-09-10)

• One owner message can carry multiple corrections → break down INDIVIDUALLY, one shelf row per form-correction, never lumped.
• The other session keeps referring to the sheet and keeps correcting continuously without stopping for the owner's prompt: non-overlapping corrections run CONCURRENTLY (one agent per form, owned files only); overlapping ones run SEQUENTIALLY. Claim with doing, close with done + commit reference.

156. Quote corrections batch 1 (owner, 2026-09-10)

• Owner's message broken into 9 per-form rows (CORRECTIONS.md C1–C9, all quote form): C1 single continuous form, no tabs · C2 save-500 fix · C3 Share-Quote WhatsApp msg (thanks + no./party/quality/rate/est qty/delivery-timeline/validity) · C4 new delivery-timeline field · C5 calculator order (reed/pick → width → job → sizing incl. wt. vaad → warp → weft → shrinkage) · C6 lead→quote full prefill · C7 previous-quote prefill (sizing rate, L2L, reed, pick) · C8 party→ most-ordered quality suggest, all filled but warp/weft rates · C9 whole-yarn-name pick (61 CCW Sanathan) with rate-board confirm, same for weft, ticket preference carried forward.
• Overlap note: §153 rebuild already covers much of C1/C2/C6–C9 — the worker converges on one implementation rather than duplicating.

157. Follow-up button: quote only, not lead (owner, 2026-09-10)

• CORRECTIONS.md C10: no follow-up button on the lead form — it lives only on the quote form. Remove from lead, keep/add on quote.

158. Quote/lead button + approval corrections (owner, 2026-09-10)

• C11: Print Quote button not required — remove.
• C12: new approval layer on quotes — a generated quote needs owner approval first; the Share button (C3) activates only after approval (existing /api/approve + /approvals pattern). C12 gates C3.
• C13: no Lost button on the lead — lost status is automatic, set by the system. (Open: the auto-lost rule itself — e.g. quote accepted elsewhere / expiry — needs defining; worker to flag if no rule exists.)

159. Prefill "navigator" — agreed variant (owner, 2026-09-10)

• Owner accepted the recommended variant (CORRECTIONS.md C14): guided confirmation applies ONLY to prefilled/low-confidence fields via inline ✓ chips with source labels (from lead / from last quote); no-skip enforced at the save gate (no save until every prefilled field is confirmed or edited); fast path "confirm all from ". Full forced spotlight-tour rejected (blind-tapping + mobile fragility). Applies to every prefilled form, quote first.

160. Quote table + row actions (owner, 2026-09-10)

• CORRECTIONS.md C15–C20: quote table gets leads parity in search and retrieval (C15); quotes table below the quote calculator (C16); row actions = Follow-up → party WhatsApp (C17), Convert to SO (C18), Lost automatic after 7 days, no manual button (C19 — also proposes the answer to C13's open rule if leads share it), Duplicate requote with current rates (C20).

161. Stable review copy for the owner (owner, 2026-09-10)

• Owner wants a second copy of the app to review the last good version while main is mid-dev (broken screens block review). Entered as CORRECTIONS.md C21 (pending, awaiting go-ahead): separate checkout + service + address with own snapshot database; promotion-on-green updates announced explicitly.
• Session rule restated: THIS session is docs-only (pending-work doc entries); all builds/fixes belong to the other session.

162. List/entry separation for all forms (owner, 2026-09-10)

• CORRECTIONS.md C22 (leads) + C23 (quotes) + C24 (general rule for EVERY form): list table and entry form never share one page — Add opens a separate page, popup, or slider; list pages keep tables only.

163. Save feedback + post-save landing, all forms (owner, 2026-09-10)

• CORRECTIONS.md C25: every new-record Save shows a "Saved ✓" tick-animation popup. C26: post-save lands on the records table with the new record highlighted at the top.

164. No-overwrite rule: one writer per file (owner, 2026-09-10)

• Worker full-file rewrites of CORRECTIONS.md wiped rows (C22–C24 lost once). New rule: the docs session OWNS CORRECTIONS.md (worker must never edit it); the worker owns docs/CORRECTIONS-LOG.md (append-only status feed, one line per doing/done); the docs session folds log lines into the sheet. Banner + protocol updated in the sheet.

165. Slim headers on all forms (owner, 2026-09-10)

• CORRECTIONS.md C27: form headers take too much space everywhere — make them small and sleek, no wasted screen space.

166. Quote row-action cleanup (owner, 2026-09-10)

• CORRECTIONS.md C28–C34: remove Expire button (auto, C19) · remove the reason text box · remove follow-up button (chase covers it — supersedes C17) · Duplicate must exist (reaffirms C20) · Re-quote broken — fix, rate-change-only · "Create SO" instead of "To Order" (refines C18) · remove approve button (supersedes C12 — confirm whether the gate itself goes or only the button).

166. C14 navigator confirm-chips on all prefilled forms (owner, 2026-09-10)

• Agreed variant (§159): inline ✓ chip per prefilled field showing its source; tap confirms (never alters value); editing counts as handled; review/save gate blocks until every prefilled field is confirmed-or-edited; "Confirm all from " fast path per source; empty fields get no chips.
• Rolled out to 17 screens via 11 parallel lanes: leads, quote, orders/new, bookings/new, gatepasses/new, tippans/new, checking, dispatch, movements, hishob+reconciliations, small batch (stocktake/sizing/winding/fabric-in/beam-end/samples). 142 new C14 tests green; full suite green.

167. C25/C26 save-feedback + post-save-landing wave (owner, 2026-09-10)

• Gap found by worker verification: the "C25-C26" commit was docs-only; in code only orders/new→/orders?created + leads toast + labour taps had it.
• Now: every create redirects to its list with ?created= (bookings, gatepasses, tippans, dispatch; orders already did) and every list honors it (highlight + "✓ Added" toast ~4s, orders pattern). Single/stay-on-page screens toast via notify() + highlight the new row (quote, leads top-up, samples, sizing, winding, fabric-in, beam-end, stocktake, checking, movements, hishob, reconciliations, masters top-up incl. YarnForm id fix).
• C27: all 31 remaining list/detail h1s slimmed text-2xl→text-lg (entry forms already slim). No CORRECTIONS.md edits (§164).

168. C27 redo: headers actually compact (owner: "still too big", 2026-09-11)

• The font-only slim wasn't enough — every header still carried a subtitle line + mb-4. Now: descriptive subtitles DELETED on ~30 list/utility/home/ board/docs pages (static text, no data — RecordDialog/ⓘ blocks keep their own context); header wrappers mb-4→mb-2 everywhere; detail pages (orders, gatepasses, lots, beams, tippans, reconciliations) compressed to number+badges on one line + a single text-xs data line (all values kept: party/design, order value + progress, status/location); entry pages tightened to mb-2. No CORRECTIONS.md edits (§164) — status via CORRECTIONS-LOG.md for the docs session to fold in.

168. Add opens a popup on every list+entry page (owner, 2026-09-10)

• CORRECTIONS.md C22/C24 refined: inline collapses pushing the table down are messy — Add opens the entry form in a NEW POPUP (always-mounted modal, CSS-hide so drafts survive close; bottom sheet on phones).
• Converted: leads, samples, hishob-generate. Quote: calculator moved into an Add-quote popup (auto-opens on ?leadId=/?quoteId=/?reuse=); the saved-quotes table stays on the page — C23 hereby SUPERSEDES C16's "table below calculator" layout on the quote screen.
• Assessed-done (already popup or entry-only): masters (6 modal dialogs), movements (modal), checking/dispatch (workbenches), floor screens, reconciliations (collapsed one-liner), bookings/gatepasses/tippans (separate /new pages). No CORRECTIONS.md edits (§164).

167. Remove GST % header + Rate GST toggle from quote (owner, 2026-09-10)

• CORRECTIONS.md C35 (GST % header — per-row GST wins where set) + C36 (Rate GST excl/incl toggle): remove from the quote screen.
• Owner's question (are they used in any calculation?) recorded as a VERIFY-FIRST guard on both rows: worker confirms zero calculation use before removing; if either IS used, report back instead of deleting.

168. Quote calculate flow + standalone quotes + share excludes costing (owner, 2026-09-10)

• CORRECTIONS.md C37: Calculate button before the Final Rate terms (validity, qty, delivery, party, …) — cost first, then final rate + terms. C38: standalone (no-lead) quotes carry lead-form fields too (party, quality, etc.). C39: shared customer quote excludes the cost calculation entirely (refines C3).

169. Stable review copy live (C21, owner go-ahead 2026-09-11)

• /home/fp/stable: git clone of master, own .env (PORT 4107, ORIGIN https://stable.trading.tynolabs.com, own data.db snapshot via VACUUM INTO), systemd project@stable + override drop-in, tunnel CNAME stable.trading.tynolabs.com → door 4103, Caddy @stable → 4107.
• scripts/promote-stable.sh: pull --ff-only + install + test (red aborts)
  • build + fresh snapshot + restart + health. Promotion-on-green only, announced explicitly each refresh. First promotion: 5cb3c1c.

170. C13 auto-lost truly implemented + C28–C39 quote wave (owner, 2026-09-11)

• C13: the "implemented" auto-lost never existed (only the manual reject). Now: load() flips >7-day stale new/quoted/followup leads to lost + lead:auto-lost event (quote:auto-expired parity).
• C28 expire button out, C29 reason box out, C30 follow-up button out (chase stays), C31 duplicate/re-quote verified present, C32 re-quote rate-only lock, C33 To Order → Create SO, C34 approve button out BUT approval gate on Share stays (no UI grants approval now — OWNER CALL pending: owner-only approve path or drop the gate).
• C35/C36 VERIFY-FIRST: gstPct + gstMode feed computeCosting/yarnMath — KEPT, not removed. C37 Calculate above Final-Rate terms. C38 standalone verified. C39 share-rate leak (calc total fallback) fixed.

171. C34 resolved: owner-only quote approval on /approvals (2026-09-11)

• Removing the quote-row Approve button left open quotes with no path to approved, so Share/Accept (both gated) were unreachable. Fix keeps the gate and moves approval to /approvals (owner/admin only): new Quotes queue listing open quotes → approveQuote (open→approved + quote:approved event with decision note). Four queues now: recon, hishob, quotes, waivers. 3-queue pins trued to 4.

172. Stable URL moved to one-level subdomain (2026-09-12)

• stable.trading.tynolabs.com failed in browsers with ERR_SSL_VERSION_OR_CIPHER_MISMATCH: Cloudflare Universal SSL covers one level (.tynolabs.com), not nested stable.trading.. New canonical address: https://trading-stable.tynolabs.com (tunnel CNAME + ingress + Caddy @stable + stable ORIGIN all moved; old nested name kept routed but uncertified). promote-stable.sh health check updated.

173. Booking → gatepass party prefill (owner, 2026-09-12)

• CORRECTIONS.md C40: party name carried forward from booking to gatepass (prefill on the gatepass form).

174. C40 booking → gatepass party prefill (owner, 2026-09-12)

• Booking carry now resolves supplier text to a party master (exact, then case-insensitive): match preselects From-party with a ✓-from-booking chip in the save gate; no match leaves party manual with a "booking says: X" caption. Untouched-only fills; manual pick counts as edited. No CORRECTIONS.md edits (§164).

175. Orders requote vs reuse (owner, 2026-09-12)

• CORRECTIONS.md C41: requote opens THAT quote asking only new rate + validity (not a new order screen). C42: reuse opens the new order screen fully prefilled from the previous quote.

175. Carry root-fix: navigation + context-keyed remount (owner, 2026-09-12)

• CORE REASON for reuse-opening-empty (and the family of partial-prefill complaints): prefill has two engines — server load() merges ?quoteId=/ ?reuse=/?leadId= into data.form (runs on load), and client $state(data.form.x) snapshots run ONCE at mount. Reuse/Re-quote only set the id client-side + opened the popup, triggering neither — and even a same-route goto would not have refilled, because mount initializers do not re-run. Arrival path decided the outcome: full loads worked, in-app buttons did not. Other forms were clean (their carries set VALUES directly: pickBooking/onDraft/supplier cascade).
• FIX on /quote: reuseQuote/requoteFresh navigate (goto ?quoteId=/?reuse=), form remounts on {#key ctxKey} (quoteId|requoteId|leadId) so every initializer re-runs from merged data; Add quote drops context via goto('/quote') for a true blank form; Stop buttons navigate plain. Verified: all 28 save-form fields init from data.form. No CORRECTIONS.md edits (§164).

176. Airtight carry contracts execute the flows (owner, 2026-09-12)

• CORE REASON inconsistencies survived thorough docs: docs describe INTENT, and the 1600-test suite only greps SOURCE — nothing ever EXECUTED a carry end-to-end, so a button that set an id without refilling fields stayed green. Correction-at-a-time rows + parallel-session clobbers compounded it.
• FIX: tests/airtight-carry.test.ts CALLS the real load() of quote, orders/new, gatepasses/new, bookings/new, tippans/new, samples with real carry URLs against self-seeded air- fixtures and asserts MERGED OUTPUT fields (12 contracts). Any carry that stops filling fails the deploy at step 1/5. Stub pattern inside for $env/$app virtuals. Fixtures carry full NOT NULL columns (quote/booking/order/party/design/yarn updated_at, booking date) — raw inserts must supply DB-level defaults drizzle normally adds. No CORRECTIONS.md edits (§164).

177. Whole-software flaw sweep, execution-style (owner, 2026-09-12)

• Four lanes executed every load (plain + carry + junk URLs) and every action failure path, fixing ~25 real flaws: junk-row writes on empty creates (samples, gatepass-list, beams), phantom-id ok:true + false events (courier, lots, guard, transporter), state regressions (sample pack/dispatch backwards), thrown-500-instead-of-400 (orders broker), negative amends, phantom amends, unvalidated echoes (type/designId/yarnId/draftId), two movements 500s (kinds TDZ), junk-date 500 (checking report), ignored ?rollId/?rolls/?orderId (dispatch server now merges), wrong-kind recon party (fabric-in weaver-gate), 500-cap bagMap (stocktake), dangling transfers/allocations, dropped loan lines, sideways direction, forged beamConfirms, terminal-state rewrites, capped-list ?beamNo drops (planning + same pattern noted in checking/ gatepasses-new/orders-new/winding/dispatch). Locked by 145 new execution asserts (airtight-commercial/floor/money/read). No CORRECTIONS.md edits.

178. Whole-software flaw sweep executed (owner, 2026-09-12)

• Four lanes executed every load + every action failure path: ~25 real flaws fixed (junk writes, phantom ok:true, state regressions, thrown 500s, ignored/echoed params, capped-list drops). Journey test retargeted via JOURNEY_BASE/JOURNEY_ORIGIN env; stale 'Costing & quote' pin trued to 'Cost per metre'. LEDGER: 53/53 on stable. 145 new execution asserts hold the gate in bun test. No CORRECTIONS.md edits (§164).

179. Lot means mill lot; system unit is Yarn Inward Number (owner, 2026-09-12)

• Owner ruling: "lot" = the MILL's cotton batch (shade identity; one sizing set = one lot). The system inward batch is renamed in ALL UI strings to "Yarn Inward Number" ("Yarn Inward No." labels, "Parked stock" for park-lot); mill-lot fields read "Mill lot". DB identifiers untouched. Finished-cloth "lots/lumps" deliberately unchanged.
• Shade guard (warn-only): sizing shows "Mixed mill lots L1 + L2 — shade will vary" when a set mixes lots; empties never warn; never blocks.
• Chain wired (migration 0015: gatepass/lot/beam mill_lot_no): booking hint → gatepass Mill-lot field → lot → beam; booking suggestions now from mill-lot history (were polluted with inward numbers). Pure helper src/lib/millLot.ts. No CORRECTIONS.md edits (§164).

180. Tap-first numerics sample on /orders/new (owner, 2026-09-12)

• Step 3 Quantity is the sample for idea 4: qty gets a −/+ stepper join (step switcher ±100/500/1000) + preset chips (lot-size×rollsPerLot lots, then recent qtys, then 1000/2000/5000); cut size gets preset chips (design mtrPerRoll, recent, 50/100/120); rolls gets −/+1 plus "+1 lot" and "recalc from qty". UI-only: POST names/actions/server untouched; taps mark touched + recompute rolls. Roll out to other forms on sign-off.

181. Masters missing save feedback + highlight (owner, 2026-09-12)

• CORRECTIONS.md C43: yarn-master add shows no Saved ✓ popup and no highlight — apply C25+C26 behaviour to yarn + every other master.

182. Yarn bookings clutter query (owner, 2026-09-12)

• Owner asks why yarn bookings has so many action buttons/fields. Entered as CORRECTIONS.md C44 (trim to essentials). OPEN: owner to name the excess buttons/fields or order a full simplify pass.

183. Yarn bookings: 2 buttons only (owner, 2026-09-12)

• Decision on C44: yarn bookings keeps ONLY Record Gatepass + Cancel — everything else goes.

184. "Chip suggestion" — the tap-instead-of-type standard (owner, 2026-09-12)

• Term of record: a "chip suggestion" = previous values + contextual suggestions shown as tappable pills at an input, so data entry is taps not typing. The owner will use this exact term to order corrections to other sessions' screens ("add chip suggestions to X").
• Reference sample: the qty example agreed this turn (context lot-multiples → recent → fallback commons, horizontal-scroll row, active highlight, tap fills + marks touched, never auto-submits).
• Canonical spec: docs/UIPATTERN.md "Chip suggestion" section (same turn). Rollout = other sessions apply the spec field by field; only the source list changes per field.

185. Chip Suggestions UI for past-entry suggestions (owner, 2026-09-12)

• CORRECTIONS.md C45: every system suggestion from past entries (rate, qty, etc.) uses Chip Suggestions UI. NOTE: worker already wrote a "Chip suggestion" spec in UIPATTERN.md (§184) — C45 rollout should follow that spec field by field.

184. C43 already fixed + C44 two buttons (owner, 2026-09-12)

• C43 (yarn-master Saved popup + highlight): verified end-to-end against stable — createYarn returns {ok,id}, onSaved fires notify + highlight. Symptom predates the YarnForm id fix (live since c4aa1d0); no change.
• C44: bookings list/dialog keep ONLY Record gatepass + Cancel; Mark partial + Close step buttons removed (arrival is recorded via the gatepass). Server setStatus untouched. phase1-gatepass pin trued. No CORRECTIONS.md edits (§164).

186. Yarn booking fields + payment terms (owner, 2026-09-12)

• CORRECTIONS.md C46 (remove GST type) + C47 (remove delivery term) + C48 (payment terms fixed at three: Super Second Day 2–3 days/1.25% off · Second Day 7 days/1% off · Regular no discount).

187. C45 chip rollout + C46–C48 booking fields (owner, 2026-09-12)

• C45: past-entry suggestions converted to the chip recipe app-wide (movements/dispatch/bookings/recon/beams/orders/leads/quote/fabric-in/ tippans/gatepass/sizing/hishob); board Fill + C14 excluded. NEED-HOOKs for server lists: leads rate-history + recent brokers, movements machine-source ranking.
• C46/C47 VERIFY-FIRST: gstType + deliveryTerm had no downstream consumer → removed from form/validation/store (amounts gstPct-only; IGST default recorded). C48: payment terms exactly the 3 labels, zod-enum enforced. 20 stale pins trued. No CORRECTIONS.md edits (§164).

188. Voice-note corrections inbox (owner, 2026-09-12)

• Owner wants to dictate corrections by voice note; this session extracts rows from transcripts. Entered as CORRECTIONS.md C49: audio upload bin (ogg/opus/m4a/mp3/wav) + open-source server transcription (whisper, §136) into a text inbox. Honest constraint recorded: this session cannot hear audio — transcript is mandatory. Interim: owner pastes transcribed/voice-typed text here until C49 ships.

189. Done-list audit loop (owner, 2026-09-12)

• Owner opens a separate audit session that asks per done-correction whether it is truly done; failures return to Pending. New files: docs/CORRECTIONS-AUDIT.md (audit-owned checklist of all 19 done-claims C1–C13/C15–C20) + docs/CORRECTIONS-REOPEN.md (audit-owned append-only reopen feed, folded into Pending by the docs session). Ownership map: CORRECTIONS.md = docs · CORRECTIONS-LOG.md = worker · CORRECTIONS-AUDIT.md + REOPEN = audit — no shared writable files.
• Also cleaned stash-conflict marker lines left in CORRECTIONS.md and PLANNING.md (both sides' content already merged; markers only).

189. C42 orders Reuse + C49 voice-note inbox (owner, 2026-09-12)

• C42: order rows with a quote show Reuse → /orders/new?quoteId= (existing prefill); needs quoteId in the list pick (added). No-quote rows: no button.
• C49: /api/voice (multipart audio ogg/opus/m4a/mp3/wav ≤25MB → ffmpeg 16kHz → faster-whisper base → draft source voice-note, never auto-commit; auth-gated) + Voice-note tab on /capture + audio exts on /capture-img. faster-whisper installed via pip; weights (~150MB) download on first use. /drafts Source column already shows voice-note. No CORRECTIONS.md edits.

190. C49 voice-note via dictate + paste (owner, 2026-09-12)

• Owner ruling: no on-server AI on this VPS. faster-whisper uninstalled, partial weights + pip cache cleared (~230MB reclaimed). /api/voice endpoint + its tests removed. Voice-note tab rewired: dictate with the phone keyboard mic (Gboard, free/offline, Gujarati/Hindi/English), paste text → /api/capture with source 'voice-note' → drafts inbox, never auto-committed. capture-img keeps audio exts reserved. No CORRECTIONS.md edits (§164).

191. Yarn booking + gatepass table simplification (owner, 2026-09-12)

• CORRECTIONS.md C50–C56: drop the needs/progress table on yarn booking (C50) and gatepass (C54); Cancel + Record Gatepass become row-level buttons in the table below (C51); cancel opens a dialog for reason + bags-to-cancel incl. partial (C52, no inline textbox); New Booking button broken — fix (C53); gatepass actions detailed individually later (C55, do not guess); gatepass-split request recorded verbatim as NEEDS CLARIFICATION (C56).

192. Voice-note inbox withdrawn (owner, 2026-09-12)

• CORRECTIONS.md C49 marked WITHDRAWN — owner does not want it; corrections continue by text only. Row kept for history, not deleted.

193. Separate form per gatepass (owner, 2026-09-12)

• CORRECTIONS.md C57: every gatepass gets its own separate form, not part of one single form — per-gatepass corrections follow individually.

194. Design conformance fix pass (owner, 2026-09-12)

• Audit of all 59 pages vs DESIGN.md: main CTAs must be btn-neutral (indigo reserved for selection/auth/xs toolbar); tables scroll inside overflow-x-auto cards; pages use the bg-base-200 wrapper; tokens via daisyUI (no raw indigo/zinc). Fixes: neutral-CTA sweep (leads, quote, hishob, samples, pending, checking/report, dispatch print), overflow wrappers (planning, beam-end, checking/report), upload shell, home token cleanup. Print routes exempt (UIPATTERN).

195. Monochrome UI — indigo removed (owner, 2026-09-12)

• Owner: indigo looks ugly; decision delegated. Full monochrome: primary token #4f46e5→#18181b (near-black), accent #0ea5e9→#52525b (zinc-600); raw indigo/sky classes gone (sidebar active pill, focus rings, brand/avatar tiles → zinc gradients, home chart bars → zinc gradients, row-hover inset bar → zinc-900). Status hues (success/warning/error) untouched — the only colour, reserved for state. DESIGN.md retokened (source of truth); reference layout/radii kept.

196. Phone-queue ergonomics (owner, 2026-09-12)

• Thumb-sized targets on the three phone queues: approvals (all 4 approve forms btn-xs→btn-sm, note input-xs→input-sm — decision note stays required, mandate 5 intact), inward (all gate fields input-xs→input-sm), runner (all tap fields/buttons xs→sm).
• Runner courier field: datalist of transporters from the loaded run list — tap instead of retyping (UI-only, zero server change).

194. Gatepass type drives the records table (owner, 2026-09-12)

• CORRECTIONS.md C58: New Gatepass offers all gatepass types and the previous-records table follows the selected type (per-type table). Per-gatepass corrections follow individually after this lands.

197. Beam-out roles corrected: planner types, godown flanges, QR (owner, 2026-09-12)

• CORRECTIONS.md C59–C61: planner picks beam TYPE + count only (C59 — corrects the earlier planner-picks-flange flow); godown picks actual flange numbers at dispatch (C60); QR scan shows floor-available beams/plans for tap-to-send with flange capture (C61).

198. Sidebar: gatepass kinds as their own category (owner, 2026-09-14)

• The single Yarn → Gatepasses button is gone; a new Gatepasses sidebar category lists every kind (labels mirror KIND_CFG on /gatepasses/new): All gatepasses (/gatepasses) + Yarn in/out, Beam out (sizing), Beam in (return), Beam repair, Beam return, Winding yarn, Direct delivery — each a kind-filtered /gatepasses?kind= link. Same roles as before (owner/planner/godown). Active-pill logic now matches query params so the current kind highlights; "All" yields while a kind filter is on (no double highlight).

199. C59–C61 beam-out roles on BEAM_OUT form (owner, 2026-09-12)

• Planner section: beam TYPE (190/250 width class from design widths, corroborated by order loom_type/flange beam_size/loom class) + count only — no flanges. Godown section: actual flange numbers against the plan (count must match, floor-only) + scan-ready input with floor-available tap list capturing flangeNo. Type vocabulary data-proven in lane. No CORRECTIONS.md edits (§164).

199. COMPLETION phase table refreshed (owner, 2026-09-14)

• Owner asked which phase we are at; the COMPLETION.md phase table was untouched since 2026-09-06 (still showing Phases 1–2 in-progress and 3–8 pending). Re-verified every phase against the code and rewrote the statuses: Phase 0 stays done-verified (suite ~1750+, journey 53/53); 1–2 near/code-complete with owner-blocked close-outs (numbering ①, GSTIN, amendment semantics, lumps/bales ③); 3 built-never-verified; 4 in-progress (missing: weft-issue route, folding, lumps→bales, contract_lines); 5–7 partial; 8 the only fully-pending phase.

200. Weft-issue route D2 — build contract (owner, 2026-09-14)

• Owner: complete the weft-issue route in Phase 4. Contract (from JOURNEYS Step 3b + Stage D §8 + FIELDMAP + REPORTS §2.2):
• New weft_issue table (FIELDMAP model): issueNo · issueDate · type-of-issue (PRODUCTION to loom | SOLD to party — only SOLD seen on the old form; owner to confirm further types) · lot/barcode + yarn snapshot · cones + weighed net kg · loom + shift · beam auto (loom's onLoom beam → contract/design) · from/to party + from/to set · paymentMode + refNo (SOLD) · loanAuto flag.
• Flow: scan bag barcode → lot card (yarn, total/issued/remaining; remaining = lot.cones − SUM(weft_issue.cones); pre-screen movement weft_out rows NOT counted) → tap issued cones (≤ remaining) + net → pick loom (beam/contract/design auto-fill, overridable) + shift → confirm. PRODUCTION with bag-party ≠ beam-party auto-marks a party loan on the row + event (netting view stays a hishob-prep step).
• REPORTS §2.2 placement: live per-loom/beam tile on the page (issued cones/kg vs engine standard from beam mtrs × design weft kg/m where known); period rollups = dump download (weft-issues slug, DUMPS.md).
• No lot mutation (append-only: issues are the consumption record); every issue logs a weft-issue:* event. Sidebar: Production → Weft issue (same roles; floor clerk = production).

201. Weft-issue: Sold-to-party removed (owner, 2026-09-14)

• Owner: no selling on the weft-issue screen. SOLD type deleted from /weft-issue (helper enum, server branches, buyer + payment-mode fields, weft-issue:sold event) — production-to-loom only; type column stays defaulting to PRODUCTION (no migration). Sold yarn stays a separate form per §8. Docs: FIELDMAP model line + open-Q #2 and the MIGRATION mapping row corrected; §200/BUILD-LOG rev 96 are append-only logs and stand as history (this entry supersedes their SOLD part).

202. Complete yarn intake & stock — contract (owner, 2026-09-14)

• Owner: complete the yarn intake & stock slice. Audit found it lot-level only: gate-in evidence collected but never persisted (inward NEED-HOOKs), one barcode per gatepass (barcode = gpNo), nothing printed, no per-bag rows — while the spec basis is bag barcode + cones-moved (YARN-FLOW) with gate-printed labels (G4) into a per-bag ledger (B3). Contract:
• (a) Gate-in persisted: inward markPicked writes vehicle + pickupDate
  • arrived_bags (new col, planned bags untouched); markDelivered writes actual bags/net/vehicle + pickupPhoto. Record-page step() takes the same evidence (due: transport+vehicle; picked: vehicle+note+date; delivered: bags+cones+net+vehicle+photo) into columns + event payloads. DIRECT delivered fires the lot hook like other kinds.
• (b) Bag grain: new bag table (lot, seq, barcode UNIQUE, cones, net, gross) created with the lot — N = lot.bags (0 → single bag), cones remainder-first, net 2dp remainder-last; code format LOTNO-Bnn (Code39-safe); self-heal for pre-existing lots; remaining always derived from the issues ledger (no mutation, append-only intact).
• (c) Gate print: /lots/[id]/print-bags label sheet with real Code39 SVG barcodes (new lib/server/barcode.ts, no dependency); linked from lots/[id], inward delivered rows, GP record lot card.
• (d) Bag-grain consume: weft_issue.bag_id; bag-barcode scan → bag card (per-bag remaining + lot context), lot-barcode fallback stays; stocktake validates barcodes against bag/lot masters + unmarked- barcode list (JOURNEYS Step 6); movements lot field resolves bag barcodes (bag ref rides items JSON).
• (e) GAP-9 answered (lotRef/PGP inputs exist on the GP form); GAP-21/22 outward-fill + stock-transfer print stay open (device flow, owner call).

203. Periodic git pull --rebase reminder in docs (2026-09-18)

• Parallel sessions land constantly, so AGENTS.md (top banner, Mandate 1, Gotcha 12) and docs/STATUS.md (How to resume) now say: pull at the start of every turn, re-pull every now and then while you work, and always pull again right before committing — no commit without a pull first.

204. Deploy-host gate — only dsh deploys to prod (owner, 2026-09-18)

• Owner: only the deploy host — the Pi checkout at /home/fp/sites/trading, reached as dsh.tynolabs.com (tunnel dsh) — may build + deploy to trading.tynolabs.com. On any other host (dev box / localhost) do not build or deploy; run bun --bun run dev instead and leave the change committed
  • pushed only. On the deploy host the "ALWAYS deploy" rule still holds.
• Enforced in scripts/deploy.sh: refuses to run unless the repo root resolves to /home/fp/sites/trading (logical or physical), exit 3; bypass only if intentional via DEPLOY_HOST_FORCE=1.
• Docs updated: AGENTS.md mandate 1 + Commands, DEPLOY.md "Where a deploy may run", STATUS.md Rule 0.

205. Pull-before-deploy + auto-resolve (owner, 2026-09-18)

• Owner: before deploying we do git pull every time; auto-resolve is a must. So scripts/deploy.sh now starts with git pull --rebase --autostash (step 0/6) — every deploy builds on latest remote, and autostash carries uncommitted work across the pull.
• New .gitattributes: docs/PLANNING.md + docs/BUILD-LOG.md use the union merge driver — concurrent appends from parallel sessions auto-resolve keeping both sides. Verified in a scratch repo: rebase over append-append clashes exits 0 with both sides kept; pull with a dirty tree stashes, fast-forwards/rebases, and reapplies cleanly.
• Same-line conflicts anywhere else still stop the pull/rebase for a human — never force-pick a side (AGENTS.md Gotcha 12).

206. On dev hosts, drive the UI through the browser MCP (owner, 2026-09-18)

• Owner: in the bun --bun run dev case (non-deploy host) the UI must be driven and verified through the browser MCP server (browser-control) — highly prioritise it over curl / static inspection. Navigate the real dev URL, click/type, read the ARIA snapshot, screenshot.
• Docs updated: AGENTS.md mandate 1 + Commands, DEPLOY.md "Where a deploy may run", STATUS.md Rule 0.

207. Auto-resolve git conflicts after a pull (owner, 2026-09-18)

• Owner: after a git pull (rebase), if there are conflicts the agent must resolve all conflicts automatically — never hand them back to the user, and never abort/skip. Pull first every turn and right before every commit.
• Docs updated: AGENTS.md top banner + mandate 1 + Gotcha 12, DEPLOY.md deploy loop, STATUS.md "How to resume".

208. Kill processes with pkill -9, never pkill -f (owner, 2026-09-18)

• Owner: always use pkill -9 <name>; never pkill -f — pkill -f matches the whole command line and can kill unrelated processes (including the agent's own shell/tooling).
• Docs updated: AGENTS.md Gotcha 15.

209. Dev sign-in credential documented (owner, 2026-09-18)

• Owner: the dev login skpawar1305@gmail.com / parag123 is documented alongside the existing dev owner login fresh@example.com / supersecret123.
• Docs updated: AGENTS.md (What this is + Gotcha 5), APP.md.

210. Shared DB on libSQL/Turso; app migrated sync→async (owner, 2026-09-18)

• Owner: local dev must use the prod database. The prod host's SQLite file is not reachable from a dev box (app binds loopback; only the cloudflared tunnel is exposed), so the DB moves to Turso (hosted libSQL) — one shared DB for the hosted app and local dev.
• src/lib/server/db.ts now uses @libsql/client + drizzle-orm/libsql: Turso when TURSO_DATABASE_URL/TURSO_AUTH_TOKEN are set, else a local file:<DATABASE_PATH> fallback (offline dev + tests). drizzle.config.ts targets Turso (dialect: 'turso') when the URL is set.
• All DB access is async now (libSQL has no sync handling): every .get()/.all()/.run() and every transaction callback is awaited; the sync bun:sqlite sqlite export is gone (raw SQL via client.execute). The conversion touched 66 files; build + type-check + 2011 tests green.
• Tests are forced off Turso (tests/setup.ts + bunfig.toml preload clear TURSO_*); scripts/seed-demo.ts now honours DATABASE_PATH.
• Turso schema pushed. Prod data import into Turso is an owner-run one-way step (prod keeps its local file until TURSO_* is set in the host .env).
• Also fixed a pre-existing /dispatch 500 (spreading an absent ?rolls=).
• Docs updated: AGENTS.md (What this is, Commands, Gotcha 2, architecture), docs/STACK.md, docs/DEPLOY.md, .env.example.

211. Focus-wizard form UX demo on /orders/new (owner, 2026-09-19)

• Owner: forms still look like forms, not good on phone. Ask: New Order opens the form blurred-but-visible behind a one-field popup carousel — first step asks lead/quote reference with searchable list + coin tabs of latest leads/orders for fast pick; picking auto-advances; Next/Back through steps; backdrop tap dismisses to the full scrollable form; tapping any form field re-enters the carousel at that field's step.
• Answer: yes, doable inside mandates — UI-only overlay, same POST names/validation/server, daisyUI modal + badges + btn coins, append-only untouched. Demo live on /orders/new only: 5 steps (source → buyer → quality → qty → rate), coins = latest leads / recent parties / recent rates, progress bar, bottom-sheet on phones, "See full form" dismiss, form onfocusin re-opens at the mapped step. If signed off, roll out per-form.

212. Focus-wizard rollout: leads form + centered card + reliable field-tap (owner, 2026-09-19)

• Owner follow-ups: (1) popup was blurry (fixed — moved overlay outside the blurred wrapper, §211); (2) tapping form fields reopened the carousel only sometimes; (3) popups opened as bottom-sheets, wanted a centered card; (4) drop the "Focus mode" / "See full form" buttons; (5) roll the same wizard onto the leads form now.
• Wizard now renders OUTSIDE the blurred wrapper, centered card on every breakpoint (items-center justify-center p-4, rounded-2xl), not a bottom-sheet. Removed the two extra buttons (✕ + backdrop dismiss only).
• Field-tap reliability: replaced form onfocusin with an onpointerdown delegation that resolves a tap to a field via [name]/[data-name] or its wrapping <label>, guards buttons/links so ✓-chips/steppers/Next keep working, preventDefault()s so no native picker flashes, then reopens the carousel at that field's step. All fields now map to a step.
• The background form now shows EVERY section expanded once the wizard is dismissed (allOpen = !wizOpen → secOpen()), so the user scrolls the whole form and taps any field to jump back in — their original vision.
• Leads form gets the same wizard (5 steps: buyer → quality → qty → rate → channel; coins = regulars, party history, last rates) over the blurred add-lead modal; "Add lead" opens both. UI-only: every pick writes the same $state the POST reads; server untouched.
• Tests: popup-leads.test.ts pins updated for the centered card + wizard open; suite 2011/0 green. Deployed.

213. Focus-wizard polish: sleek compact card, visible backdrop, wrapped coins (owner, 2026-09-19)

• Owner: (1) remove the always-visible column of options — keep the popup clean; (2) popup was stuck to the top; (3) the form behind was invisible; (4) coins scrolled horizontally off-screen; (5) fonts were too loud.
• Wizard card is now a compact centered card (max-w-md, rounded-2xl, border, shadow-xl), not a full-height sheet — it sits mid-screen. The always-visible result list is gone: a search input shows a compact dropdown (menu, max-h-48) only when ≥2 chars are typed; coins show when the field is empty.
• Backdrop is light + blurs the form (bg-black/15 backdrop-blur-[2px]) and the form's own blur-[2px] filter was removed — the form behind is now clearly visible (blur-but-visible per the original ask), the popup sharp.
• Coins wrap within the card (flex flex-wrap, btn-sm rounded-full, short labels — party/quality name only, full detail in a title tooltip) instead of overflow-x-auto scrolling off-screen.
• Fonts tightened: title text-base, sub text-xs, rows text-sm, qty/rate inputs text-lg, step label text-[11px].
• Applied to both /orders/new and /leads. Tests 2011/0 green. Deployed.

214. Focus-wizard: read-only background summary + keyboard/dropdown fixes (owner, 2026-09-19)

• Owner: keyboard opened the moment the popup/Next appeared; search results dropped below the field and were hidden by the keyboard; the background was touch-hypersensitive (any scroll-touch on a field reopened the popup); and the background should look like the "Check & save" review — read-only, no searchable fields — each field reopening the popup on tap.
• Removed autofocus from every wizard input → the keyboard only opens when the user taps a field (coins/Next never summon it).
• Search dropdown now floats ABOVE the input (absolute bottom-full, solid card + shadow) instead of below, so results stay clear of the keyboard.
• The background form is now a READ-ONLY summary in the review format: a card ("Order/Lead so far") of tappable field:value rows, one per wizard step. Tapping a row reopens the wizard at that step. The editable form is kept mounted but hidden (display:none) so POST names/values and the ReviewSheet FormData snapshot stay byte-identical. No editable inputs in the background → scrolling no longer collides with field taps.
• Applied to /orders/new and /leads. Tests 2011/0 green. Deployed.

215. Leads form → /leads/new page + qty/rate auto-advance (owner, 2026-09-19)

• Owner: the leads entry opened as a popup (modal) — it should be a full page like New Order; and the qty/rate wizard steps didn't auto-advance on a coin tap or typed value.
• The add-lead form moved out of the /leads modal into its own route /leads/new (page: header → read-only summary → hidden editable form → focus wizard → ReviewSheet). /leads is now the pipeline list only (SmartTable, convert-to-SO, RecordDialog, "Add lead" → /leads/new, ?created= highlight via page.url — mirrors /orders). Server split: /leads/new/+page.server.ts owns load (party/quality/rate/draft memories) + create (redirects to /leads?created=); /leads/+page.server.ts keeps the list load + move/ convert.
• Wizard qty/rate steps now auto-advance: tapping a coin calls wizNext(), and pressing Enter in the qty/rate input advances (both /orders/new and /leads/new). Party/quality/lead/quote picks already advanced.
• POST names/actions/validation byte-identical; tests updated for the split (2007/0 green). Deployed.

216. Leads: single party/broker field + auto category, direct Save + success popup, sectioned summary (owner, 2026-09-19)

• Owner: leads should have ONE "party/broker" field (auto-detected broker vs party from the master) — drop the channel toggle + separate broker name; drop the "Check & save" review popup for a plain Save that shows a tick + lead no
  • details popup, auto-closes in 3s, then lands on the list with a temporary highlight; and the new-lead screen should show sections (Party/Broker, Quality, Quantity, Rate).
• /leads/new rewritten: one party/broker field (search all parties incl. brokers, "Broker"/"Party" badge from the master), 4-step wizard (party/broker → quality → qty → rate), sectioned read-only summary, and a Save button. No ReviewSheet / C14 confirm-chips / channel-broker UI.
• Save returns { ok, id, leadNo } (no redirect); the client shows a success popup (CheckCircle2 + lead no + party/quality/qty/rate) then goto('/leads? created=') after 3000ms; the list highlights via page.url (C26 pattern).
• Server derives channel/brokerName from the picked party's category (Broker → channel='broker' + its name, else direct). parseLeadForm + ranges unchanged; POST names now partyId/quality/designAlias/qty/rate.
• Tests rewritten for the new contract (1985/0 green). Deployed.

217. Leads success tick animation + haptic/sound feedback + 1.5s (owner, 2026-09-19)

• Owner: make the success tick animated (GPay-style), add a sound + vibration (haptic), extend haptic/sound to all data entry, and shorten the success popup to 1.5s.
• Added src/lib/feedback.ts: tap() (8ms vibrate + short 540Hz blip) and success() (double pulse + two-tone 660/880Hz ding), both browser-guarded (Web Audio + navigator.vibrate, no-ops off-device/SSR).
• Success tick is now a stroke-drawn SVG (circle + check mark draw themselves, classic GPay-style, check-circle/check-mark keyframes); replaces the static CheckCircle2. Auto-close + navigate now 1500ms (was 3000).
• Wired tap() into the leads wizard (party/quality picks, coins, qty/rate coins, Next/Back, summary rows) and success() on save.
• Tests updated (1986/0 green). Deployed.

218. Leads form: match check-&-save header exactly + notes/remarks field (owner, 2026-09-19)

• Owner: the new-lead screen still didn't match the "Check & save" look; use exactly the same heading style, and add a Notes/Remarks field.
• Title changed to the ReviewSheet heading (h3 text-lg font-bold, dropped the extra tracking-tight + h1) so it matches the check-&-save screen exactly; the row's kind badge now sits beside the label like the ReviewSheet "auto" badge, and the value is a plain truncate font-medium span.
• Added a Notes / Remarks field: 5th wizard step (textarea, maxlength 2000), a "Notes / Remarks" section in the summary, POST name notes, and it shows in the success popup when non-empty. Server already parsed/validated notes.
• Tests green (1986/0). Deployed.

219. Leads: grouped sections + data-entry affordance + louder taps (owner, 2026-09-19)

• Owner: put Quality + Quantity in one section and Rate + Remarks in one; make the form feel like a data-entry screen (needs filling + saving), not an info display; and make the tap/click sound a bit louder.
• Summary sections now: "Party / Broker" · "Quality & Quantity" (Quality, Quantity) · "Rate & Remarks" (Rate, Notes/Remarks).
• Data-entry affordance: required fields show a red * on the label and an amber "Tap to add" when empty (optional fields show a muted "Optional"); a subtitle shows "{n} required to fill" in amber until done, then "All required fields filled"; Save is disabled (btn-disabled) until party+quality are present, then flips to btn-primary.
• feedback.ts: tap/success tones raised (default gain 0.05→0.1, success 0.16).
• Tests updated (1986/0 green). Deployed.

220. Leads qty stepper + rate slot-machine wheel + absurd-value guards (owner, 2026-09-19)

• Owner: rate entry as a slot-machine carousel (2 digits rupee + 2 digits paise, like alarm-clock apps); qty as ±1,000 m buttons with long-press acceleration; and guards so rate/qty can't be mistaken for absurd values (e.g. ₹10,000).
• New src/lib/components/DigitWheel.svelte: a scroll-snap spinning digit column (0–9) with a centered selection band; 4 wheels compose ₹ XX.YY.
• Qty step is now a ±1,000 m stepper (big − / + buttons, touch-none, long-press accelerates 400ms→~70ms); coin chips (500/1000/2000/5000) remain as quick sets. Rate step replaces the input + coins with the 4-digit wheel.
• Absurd-value guards: the wheel hard-caps rate at ₹99.99 and the stepper caps qty at 500,000 m client-side; the server checkLeadRanges now rejects qty > 10,00,000 m and rate > ₹99.99 with plain-word errors.
• Tests updated (1987/0 green). Deployed.

221. Leads rate/qty: single wheels, typeable, subtle fonts, faster hold (owner, 2026-09-20)

• Owner follow-ups: add a 3rd rupee digit; rate should be TWO wheels (one rupee 0–999 stepping ₹1, one paise 0–99) not five digit columns; make the wheel scroll more touch-sensitive; make the mtr hold-to-repeat accelerate faster; let both rate and mtr be typed directly; and tone the fonts down.
• Replaced DigitWheel with NumberWheel.svelte (min/max/pad, free-scroll + snap-to-nearest on scrollend, -webkit-overflow-scrolling: touch, overscroll-y-contain). Rate = ₹ [0–999] . [00–99] two wheels + a typeable input-sm decimal field; mtr = typeable input-sm numeric field + ±1000 buttons. Both values stay typeable alongside the wheel/stepper.
• Subtle fonts: wheel items text-base font-medium text-base-content/70, mtr and rate inputs input-sm text-base font-semibold, hints text-[11px].
• Hold-to-repeat now starts at 250ms and accelerates 0.7× down to 50ms (was 400ms/0.9×/70ms). Rate cap widened to ₹999.99 (server + wheel).
• Tests updated (1988/0 green). Deployed.

222. Leads qty/rate polish: smaller buttons, no leading zeros, keyboard-safe (owner, 2026-09-20)

• Owner: +/- buttons were bigger than the mtr and tapping them opened the keyboard / shifted the card; wheels showed leading zeros ("001"–"099"); functionality was fine but the look was bad.
• qty step: buttons shrunk to btn-outline min-h-12 w-14 (was btn-lg), value is now a medium input-bordered text-lg field (no longer dwarfed); +/− got tabindex="-1" + stopPropagation and inputs got an onfocus scrollIntoView so tapping a button never summons the keyboard and the layout doesn't jump. rate step: same treatment for its ₹ input.
• Removed leading zeros from the number wheels (rupee 0–999, paise 0–99 now render bare — no pad).
• Tests updated (1988/0 green). Deployed.

223. Leads wheel/stepper polish: typeable centre, faint sides, keyboard blur (owner, 2026-09-20)

• Owner: pressing +/− after typing re-opened the keyboard; the wheel showed too many numbers around the active one; typing should happen in the wheel's active band; mtr +/− too big; rate scroll needs sound; mtr suggestions back as a scroll row.
• NumberWheel now shows the active value plus ONE faint value each side (3-item window + top/bottom gradient fades), is typeable right in its centre band (typeable → an inline input over the band), free-scrolls, snaps on release and plays a tap() tick on settle.
• Rate step is now ₹ [typeable rupee wheel] . [typeable paise wheel] /m (separate input removed). Mtr +/− shrunk to min-h-11 w-12 text-lg; its suggestion chips are back as a horizontal scroll row. startHold blurs the focused input so +/− never re-opens the keyboard.
• Tests updated (1988/0 green). Deployed.

224. Leads: live wheel + slot-machine tick + mtr alignment (owner, 2026-09-20)

• Owner: the mtr box and +/− buttons were misaligned; the wheel's active number stayed static while the list scrolled behind it (only updating on stop); and the scroll should sound like a slot machine.
• Mtr stepper: items-stretch so input and +/− share one height; the "metres" caption moved out of the row so the three controls align.
• NumberWheel now updates the active number LIVE on onscroll (no more static centre), and ticks a slot-machine reel click (tick() — a short noise burst) each time a value passes; the settle tap() was removed.
• feedback.ts gains tick() (Web Audio noise burst, ~30ms decay).
• Tests green (1988/0). Deployed.

225. Leads: softer slot tick + lock page scroll behind the wizard (owner, 2026-09-20)

• Owner: the slot tick was sharp/loud; and spinning the wheel sometimes chained into page scroll.
• feedback.tick() changed from a noise burst to a soft short 300Hz tone (gain 0.06), matching the other tap/success sounds.
• The wizard now locks the page (document.body.style.overflow = 'hidden' while wizOpen) and the wizard body + wheel carry overscroll-y-contain, so wheel scrolling can no longer chain into the page.
• Tests green (1988/0). Deployed.

226. Leads wheel: tap-to-type + mid-scroll sensitivity, mid tick, rate coins (owner, 2026-09-20)

• Owner: the wheel wasn't touch-sensitive mid-scroll; the tick was too quiet; and the rate suggestion coins should come back.
• NumberWheel is now touch-sensitive mid-scroll: the typeable input is pointer-events-none unless typing, so dragging anywhere spins the wheel (including grabbing it mid-momentum); a tap on the wheel opens the typeable centre (focus + pointer-events on), blur returns it to scroll mode. Live value update only fires when the rounded value changes (less churn).
• tick() moved to a middle ground: 400Hz / 0.05s / gain 0.09.
• Rate step regains the "Last used" suggestion coins (wizRateCoins from rateMemory), tap sets the rate and advances.
• Tests green (1988/0). Deployed.

227. Signed pattern documented: FOCUS-ENTRY.md + UIPATTERN/STATUS/AGENTS wiring (owner, 2026-09-20)

• Owner: the new-lead form is done and approved; before moving on, document everything so "change the UI of other forms like this" can be executed to the last detail.
• New docs/FOCUS-ENTRY.md = the complete replication recipe: page skeleton, the sectioned read-only summary (check-&-save look), the centred one-field wizard (exact classes + body-scroll lock), the four field-step types (search+coins, ±hold-to-repeat stepper, typeable NumberWheel, text), the NumberWheel contract (3-item window, faint sides, live active value, snap-on-release, slot-machine tick(), tap-to-type touch safety), the save→animated-tick popup→1.5s→goto(?created=)→list-highlight flow, #lib/feedback.js (tap/tick/success), the mobile/keyboard rules, the required/optional affordance, the UI-only contract and a per-form rollout checklist. Live status table: /leads/new live; other forms pending go-ahead.
• Cross-wired: UIPATTERN.md (Focus-entry app-wide standard, supersedes the guided-section look for entry forms), STATUS.md (source-of-truth list #11), AGENTS.md (repo map).
• Docs-only turn — no code change. Committed + pushed.

228. Slot tick: restore the sharp reel click at low volume (owner, 2026-09-20)

• Owner: the soft 400Hz tone didn't sound right — use the ORIGINAL sharp slot-machine click for the scroll, just quieter.
• feedback.tick() restored to the short noise-burst reel click (30ms quadratic decay) with gain dropped 0.12 → 0.05.
• Tests green (1988/0). Deployed.

229. Party acronym + leads table redesign (preview popup, 3-state status, gestures, edit/delete) (owner, 2026-09-20)

• Owner: add an acronym/alias tag to the party master (default = initials of the words, unique, editable); redesign the leads table to fit mobile: columns Date · Lead · Party(acronym) · Quality · Qty · Rate · Status(small tag), with ALL action buttons moved into the row preview popup (Lead No + Rate + Edit / Delete / Quote / Convert to SO / Follow up WhatsApp / status change); status reduced to open · quoted · lost (converted leaves the pipeline into its own filter); swipe a row left → quote screen (prefilled), right → WhatsApp follow-up; and the slot tick even quieter.
• Party acronym: new party.acronym column (migration drizzle/0019_clean_genesis.sql, evt dedupe index re-created after push), pure helper src/lib/acronym.ts (initials, stops dropped, parens/punct stripped), rerunnable backfill scripts/backfill-acronym.ts (470 parties), masters PartyForm gains an Acronym input with a live "Suggest" default, and create/update ensure uniqueness (uniqueAcronym). EDIT/Delete are append-only in the data: appendAmendment + evt record before/after.
• Leads status (3-state): GROUP_TO_DB maps open→new, quoted→quoted, lost→lost; ?/move changes status (audited); converted (order) and deleted are filtered out of the active pipeline; loaded role gates the UI.
• Leads list: SmartTable columns Date/Lead/Party/Qty/Rate/Status (no action column), rowClick → a custom preview popup with the actions + status change; Added swipe support to SmartTable (swipeLeft/swipeRight, row tint feedback). WhatsApp = wa.me/<party mobile> deep link (no automation).
• Edit = /leads/new?edit=<id> (wizard prefilled) → server amends (role- gated, diff to appendAmendment); Delete = soft delete (status='deleted', role-gated, appendAmendment kind delete). Slot tick gain 0.05 → 0.03.
• Tests updated (1988/0 green). Deployed.

230. Leads table: quality alias, drop lead no + rate (owner, 2026-09-20)

• Owner: in the historical leads table show the quality alias instead of quality, remove rate from the table, remove action buttons from the table, remove the lead number from the table.
• Columns are now Date · Party(acronym) · Quality alias (designAlias) · Qty · Status (no action column — actions already live in the row preview popup; default sort moved from leadNo to Date). Check green, 1988/0 tests. Deployed.

231. Leads table mobile-fit: compact rows, tiny tags, no h-scroll (owner, 2026-09-20)

• Follow-up to §230: status tags down to badge-xs, dates as short "20 Sep" (column still sorts by the full ISO date via a new SmartTable sortBy key), compact density (table-xs, truncated cells) through a new SmartTable compact prop, card overflow-x-auto → overflow-hidden.
• Pinned by tests/leads-compact.test.ts (3 tests). Check green, 1991/0 tests. Deployed.

232. Swipe cards: row follows the finger over WhatsApp/Quote reveal (owner, 2026-09-20)

• Owner: swiping a lead row should feel like moving the card — the empty space shows green WhatsApp on a right swipe, blue Quote on a left swipe.
• SmartTable rows now translateX with the touch (clamped ±140px, labels fade in with distance) over an absolutely-positioned reveal layer sized to the row rect (green bg-success WhatsApp left, blue bg-info Quote right, labels overridable via swipeLeftLabel/swipeRightLabel); past 60px the quote/WhatsApp action fires on release and the row eases back (180ms); touch-action: pan-y keeps horizontal drags on the row.
• Pinned by tests/leads-swipe.test.ts (3 tests). Check green, 1994/0 tests. Deployed.

232b. Leads status as a dot symbol; table fits without scrolling (owner, 2026-09-20)

• Follow-up: the badge-xs word tag still cost a whole column, and the table still scrolled sideways. Status is now a dot symbol (new SmartTable dot column: blue open · indigo quoted · grey lost · green converted, word in the tooltip + preview popup); compact headers may wrap (the whitespace-nowrap pin now applies to non-compact tables only).
• tests/leads-status-dot.test.ts (3 tests); fwd-leadsquote daisyUI pin updated (badge lives in SmartTable + quote screen). Check green, 1997/0 tests. Deployed.

232c. Compact rows to touch size; fixed table fit (owner, 2026-09-20)

• Follow-up: rows were too short for fingers, and a sliver of horizontal scroll remained. Compact tables move table-xs → table-sm (taller rows) and gain table-fixed w-full (columns share the screen width — nothing can push past it), with text cells clipping to their column (max-w-full). Check green, 1997/0 tests. Deployed.

233. Preview mirrors check-&-save card; search filters live (owner, 2026-09-20)

• Owner: (1) the row preview popup should look like the check-&-save popup; (2) the top search bar should filter the table live — matching party, broker, quality, quality alias, date, lead no, party/broker alias.
• Preview rebuilt in the success-popup language (centred rounded-2xl card, title + divide-y details box with quality alias/rate/status word, centred status + action rows); all actions unchanged.
• ListToolbar gains autosubmit (debounced keystrokes re-submit the GET form in place via use:enhance — no reload, ?page= resets) — leads opts in; leads server search is now every-word-must-match across leadNo, party, acronym, broker, quality, designAlias, ISO + short dates, status. shortDateLabel moved into leadLogic (shared by page + server).
• Pinned by tests/leads-preview-search.test.ts (5 tests). Check green, 2002/0 tests. Deployed.

233b. Fixed: search Enter did nothing; status dot legend (owner, 2026-09-20)

• Bug (my §233): the debounced "live" submit only looked in-place — SvelteKit's use:enhance ignores GET forms (returns before preventDefault; throws in dev), so every pause fully reloaded the page and stole focus; typing went nowhere and Enter did nothing.
• Fix: toolbar back to a plain GET form (Enter/Search = full server search, honoring ?q= across all data) with an onSearchInput keystroke hook; leads filters its loaded rows 100% client-side (instant, focus stays), count/pagination reflect the filtered set while typing.
• Also shipped the §233-status legend request: a quiet ● open ● quoted ● lost ● converted line beside the swipe tip.
• Pinned by updated tests/leads-preview-search.test.ts + p3-lists live-filter allowance. Check green, 2003/0 tests. Deployed.

234. Touch rows; wizard shows the pick; coins fill-and-stay (owner, 2026-09-20)

• Owner: (1) the new (first) record's row still feels small — bigger touch rows; (2) picking a party/quality leaves the popup field blank — show it; (3) tapping a mtr/rate suggestion jumps on — fill it and stay.
• Compact tables gain roomy vertical cell padding ([&_td]:py-3, ~45px rows; daisyUI has no between-size). Wizard search steps prefill the box from the current pick (wizSearchFor: party name / quality) on open, advance and back. Qty + rate coins set the field/wheel, highlight, and stay — the user continues with Next. FOCUS-ENTRY.md amended (search-box rule, fill-and-stay coins, rollout checklist).
• Pinned by tests/leads-wizard-fill.test.ts (4 tests). Check green, 2007/0 tests. Deployed.

230. Slot tick: back to the previous (0.05) volume (owner, 2026-09-20)

• Owner: the previous scroll sound was better — restore it. tick() gain 0.03 → 0.05.
• Tests green (1988/0). Deployed.

231. Slot tick: restore the muffled tone (character, not volume) (owner, 2026-09-20)

• Owner clarified: the earlier complaint was about the sound CHARACTER — the muffled clicks were preferred over the mechanical (noise-burst) ones, not a volume change. tick() restored to the soft muffled tone tone(400, 0.05, 0, 0.09).
• Tests green. Deployed.

234b. Wizard pick as a chip, search box stays free (owner, 2026-09-20)

• Correction to §234: prefilling the search box with the pick was wrong — it duplicated the value below, hid the suggestion coins, and tapping the field couldn't reopen search. Now the pick shows as a removable green chip above the box (party / quality, ✕ clears); the box stays empty so coins stay visible and tapping it always searches again. FOCUS-ENTRY amended. Check green, 2007/0 tests. Deployed.

234c. Wizard collapses chrome when the keyboard opens (owner, 2026-09-20)

• Owner: with the keyboard open, headers + titles crowd out the search box and options. The wizard now watches window.visualViewport: when it shrinks (keyboard), the step header + title/sub + progress hide, the card pins to the top, and the backdrop goes opaque — search + options keep half the screen. Footer (Back/Next) stays. FOCUS-ENTRY amended. Check green, 2008/0 tests. Deployed.

234d. Fixed: collapse never fired (owner, 2026-09-20)

• Owner: nothing changed on screen. Root cause: app.html sets interactive-widget=resizes-content, so window.innerHeight shrinks together with the keyboard — comparing the visual viewport against it could never fire. Detection now tracks the tallest viewport seen and fires when the current height drops >150px below it (touch devices only; orientation resets the baseline). FOCUS-ENTRY amended. Check green, 2008/0 tests. Deployed.

234e. Wizard docks at the keyboard; shell nav hides (owner, 2026-09-20)

• Owner: the top nav bar still shows, and dead space sits between the keyboard and the popup. Now the card docks just above the keyboard (items-end, no gap) so the freed space above shows the page, and the shell nav hides the whole time the wizard is open (wizard-open on <html> + one app.css rule — the overlay covers navigation anyway). FOCUS-ENTRY amended. Check green, 2009/0 tests. Deployed.

235. Dictate-first wizard step on /leads/new (owner, 2026-09-20)

• Owner-built: step 0 is a dictation board — Gboard mic transcript box, Enter (or "Fill from speech") heuristically prefills party/quality/qty/ rate, reports what it understood, then advances; each later step is still checked by hand (old steps shift to 1–5). Found committed+p pushed but undeployed — shipped via the standard loop. FOCUS-ENTRY amended (step type 0). Check green, tests green. Deployed.

236. Dictation hears aliases (owner, 2026-09-20)

• Owner: rate + meters captured, but party/quality spoken as aliases missed. Matcher now also tries the party acronym (whole-word, so short codes never match inside ordinary words) and design aliases (resolving to their quality name). Check green, 2011/0 tests. Deployed.

237. Intelligent dictation matcher + correction memory (owner, 2026-09-20)

• Owner: predict what the user meant; remember corrections to predict better. Deliberately NOT the gateway LLM (deepseek-v4-flash stays on capture parsing only) — dictation is on-device: leadLogic fuzzy core (normalize + singularize, substring, ≥60% token coverage with 1–2 typos allowed per word) plus a per-device correction memory (lead-dictate-mem, 100 latest transcripts → corrected picks, exact then ≥0.5-overlap recall) that wins over heuristics and reports "Remembered". Picks made while a transcript is active are recorded. Instant, offline, zero cost; LLM-assist stays a future option (needs connectivity + sends master names out — owner's call). Pinned by tests/lead-dictate-smart.test.ts (10 tests) + wizard memory pins. Check green, 2022/0 tests. Deployed.

238. Dictation accuracy: partial names, suffix rates (owner, 2026-09-20)

• Owner: highly inaccurate. Two real gaps: (1) "Balaji" never matched "Shree Balaji Textiles" (coverage demanded most of the master) — now score-ranked (fuzzyScore: substring wins big, else 2/exact-word or 1/typo-word, single-word names match on any hit, filler words like "new/enquiry/rate" can never fire a master); (2) "42 rupees [meter]" captured nothing (only "Rs 42" existed) — amount parsing moved into tested parseQtyFromText/parseRateFromText with suffix + per-meter forms (money-with-meter is a rate, never qty). 15 smart tests. Check green, 2027/0 tests. Deployed.

239. Dictation misfires on a real sentence (owner, 2026-09-20)

• Owner typed "Charbhuja at 51 for 50000 M germ certain", got A B ENTERPRISES + a numeric twill + rate missed. Three precise bugs, all traced against the live masters: (1) single letters typo-matched ordinary words (a→at, b→m) — letters and pure numbers are now exact-or-nothing; (2) numeric design codes fuzzy-hit amounts (50≈51) — same fix; (3) no pattern for trade "at 51" — added (range-guarded, so "at 50000 meters" can't misfire). The example is now a regression test. Note: "germ certain" (Gboard mangling "jam satin") is beyond fuzzy — correct it once by hand and the memory learns it. Check green, 2031/0 tests. Deployed.

240. Quote rebuilt leads-style: list + wizard + calc + share (owner, 2026-09-20)

• Owner: quote screen + table exactly like leads, with exceptions. Agreed shape (leads parity): /quote = compact list table (Date · Quote · Party · Quality alias · Rate · Status dot + legend, swipe left → edit, right → WhatsApp, row-tap preview card, live search, status filter); /quote/new = wizard (0 dictate → 1 lead, skippable → 2 quality unless lead → 3 warp rate → 4 weft rate → 5 job rate → 6 party unless lead → summary with tap-to-edit popups for prefilled construction (no step nav) → calc screen (cost read-only, selling editable defaulting to cost, validity default tomorrow, qty, delivery start/end dates) → save → success popup → /quote?created=); current full form moves untouched to /quote/edit (reuse/re-quote/approve/accept/chase/C14 all stay).
• Rates = legacy singles (₹/kg warp/weft, paise job) over design rows; everything else prefilled design → last-quote → typed (existing precedence); GST default 5% (already the engine default).
• Schema: quote.delivery_start/_end (timestamp_ms) via migration; inputs/outputs JSON carry the rest. Engine runs client-side for live calc preview AND server-side on save (single truth, no drift).
• Share keeps the approved-gate (signed C34): success popup + preview offer Share when approved, owner sees one-tap Approve; Chase always. WhatsApp text extended with delivery dates.
• SHIPPED: sveltekit-guard bans $lib/server in browser code, so the live calc preview is a debounced ?/calc fetch (tippan-solve pattern), not a client engine — server recomputes on save, one truth. Row-level approve was NOT added to the list (C34 keeps approval in /approvals; preview links there). Live-verified 2026-09-20: /quote + /quote/new render, ?/calc returns computed W/C. Check green, 2040/0 tests.
• §240b: the full quote form (enquiry/rates/construction + cost card) lives behind the wizard from the start, leads parity — dismissing the wizard lands on it instead of a near-blank page. Check green, 2040/0 tests. Deployed.
• §240c: wizard now covers every old-form scalar — warp/weft reed spaces, job + warping GST (passed to the engine, null falls back to global), plus read-only warp/weft mix lines (row composition stays master data; full row editing on /quote/edit). Verified live masters carry no row rates, so wizard rates always apply. Check green, 2042/0 tests. Deployed.
• §240d+e: adjust popups are wizard-grade (master-typical coins, keyboard collapse); warp/weft steps are ADD-row editors (count/%/rate/GST/incl + per-warp sizing, up to 4, board hint) per COSTING §6b + full-flow A2; calc screen speaks the sheet (Warp/Weft/Siz./Majuri/Warping/Other/Basic/ With-GST + weights/GSM + margin table). Server validates row JSON; legacy singles stay as gap-fillers. Live-verified ?/calc on the row contract. Check green, 2045/0 tests. Deployed.
• §240g: party/buyer optional (server accepts null, step appears when no lead or no party, save never blocked on it); calc failures now show the server's reason + a Calculating state instead of a dead-end warning. Check green, 2049/0 tests. Deployed.
• §240h: yarn popup holds ONLY count/rate/Excl-Incl (my §240f wrongly left GST/sizing homeless — they are now per-yarn extras rows in the main form: GST%, share%, warp sizing rate+GST, via a spec-driven multi-field adjust popup with GST coins). Full field audit: every old-form field now resolves in popup ∨ main form ∨ server ∨ engine. Check green, 2049/0 tests. Deployed.
• §240i: yarn extras split into individual rows — Warp n GST / share / sizing / siz GST, Weft n GST / share — each opening a single-field popup. Check green, 2049/0 tests. Deployed.
• §240j: lasa displays 110 by default (engine already did).
• §240k: all GST master-owned — yarn.gst_pct column + YarnForm field (blank inherits fabric GST), wizard resolves row GST from the yarn master by count (+system), fabric GST adjust + yarn GST rows removed from the form, job GST field hidden (fixed 5). Sizing GST stays (no master for sizer rates). Check green, 2050/0 tests. Deployed.
• §240l: sizing rate master — siz_rate (+siz_gst_pct) on the yarn entry, YarnForm fields, autopopulated in quote by warp count (last-quote and design values win when set; blank stays overridable). Sizing GST likewise master-owned and hidden in quote.
• §240m: "Could not calculate" dead-end fixed — root cause: SvelteKit devalue-encodes action results, which bare res.json() cannot read, so the client never saw success (a plain-JSON Response return 500s — actions must return serializable results). ?/calc (?/solve in tippans, same latent bug) returns plain action objects; clients decode with deserialize() from $app/forms. Missing yarn.siz migration (0022) caught by the suite before deploy. Live-verified both endpoints return computed data. Check green, 2064/0 tests. Deployed.

241. Weft reed space defaults to warp space (owner, 2026-09-20)

• Field existed but defaulted to width. Now blank weft space = warp space (create + update; form hints it); 602 existing designs backfilled live, 0 nulls left. Check green. Deployed.

242. /leads/new dictate is DeepSeek-understood: mic + photo, no heuristics (owner, 2026-09-21)

• Owner supersedes §237 (on-device fuzzy + correction memory): step 0 now sends the transcript to DeepSeek (deepseek-flash on https://api.deepseek.com, per api-docs.deepseek.com — the opencode gateway key 401s, the DeepSeek platform key works) with the party + quality master lists; the model returns exact-list party/quality, qty, rate, notes and the form fills. NO heuristic fallback — unreachable or unmatched fills nothing and says so. New POST /api/lead-understand (auth-gated, resolves partyId + designAlias server-side).
• Step 0 also has an in-browser mic (Web Speech API; Gboard 🎤 still works) and a camera button (capture="environment", client-downscaled to ≤1600px JPEG): the enquiry chit/message photo goes to DeepSeek vision, which returns the read text as transcript plus the same fields — no typing or speaking needed.
• extractLeadEnquiryJson + no-gateway-null pinned by tests/leadUnderstand.test.ts (live shape verified against the real API: clean JSON, unknown parties → null, never invented). Check green; 15 unrelated failures in the tree are another session's mid-work GST schema change (yarn.gst_pct missing in test DB) — untouched.

240f. Per-yarn popups, last-quote counts, inline quality-add (owner, 2026-09-20)

• Warp/weft steps show one button per master yarn — no ADD (rows come from the master). Each yarn popup: Count, Rate, Sizing (warp), Excl/ Incl segmented + GST% (5% default). Counts show on the summary too, and counts drive weights → cost (verified: 40s ₹98.17 vs 60s ₹86.08 on the same design). Row counts prefill from the last quote for that quality, else the master.
• Quality step has ＋ New quality → the Design master form in a popup (new actionBase prop, backwards compatible); saving auto-picks it.
• Job step carries its GST% (no incl toggle — the engine has no legacy job-incl flag; documented); warping rate/GST + sizRate/jobGst leave the adjust list (warping stays master-prefilled); GST adjust is "Fabric GST"; weft wastage defaults 5%, other exps 5.5%. Yarn + adjust popups center like the wizard. Check green, 2048/0 tests. Deployed.

243. Always-deploy rule in AGENTS.md (owner, 2026-09-21)

• Owner: whenever something feels like it should be live, deploy it in the same turn — do not wait to be asked. Recorded as the rule-of-thumb line in AGENTS.md mandate 1 (deploy host runs deploy.sh; a change not live
  • pushed is not done).

244. Lead-understand: recency-ranked party + retry (owner, 2026-09-21)

• Owner: "Charbhuja at 51 for 50000 M jam" filled nothing. Traced live: (a) the reasoning model sometimes returns an empty message on the big prompt (first attempt empty, retry fine); (b) "Charbhuja" matches 9 master rows, so the strict exact-only prompt returned null — while ALL recent Charbhuja business (64 orders + 10 leads) is CHARBHUJA FABRICS PVT LTD; (c) no master quality/alias resembles "jam", so it arrives raw for the user to confirm in step 2.
• Fix: parties sent to the model most-traded-first ("prefer the earlier entry" on ambiguity) + server resolveLeadParty (leadLogic, tested): exact first, else substring candidates by recent-order/lead weight; quality also matches design aliases (else raw words kept). Same-model single retry on empty/unparseable; max_tokens 2500 for reasoning headroom. Verified live: party CHARBHUJA FABRICS PVT LTD, qty 50000, rate 51, quality "jam".

245. Lead-understand goes cheap: short menu + non-thinking + JSON mode (owner, 2026-09-21)

• Owner: API cost too high. Measured: every call sent all 470 parties + 500 qualities (~12.6k input tokens) plus ~1k thinking tokens.
• Verified live against the docs (api-docs.deepseek.com): thinking low still burns 1200 reasoning tokens and starves the answer; full prompt + non-thinking misreads (rate 51 → quality). Winner: shortlist the menu (transcript-matched names first, regulars fill — 60 parties / 80 qualities, recent order aliases lead qualities) + non-thinking + response_format json_object → 2125 in / 41 out, fully correct on the Charbhuja case. ~₹0.06/enquiry peak (was ~₹0.42), half that off-peak; cache hits cut repeats further. Same treatment for /capture parsing. Shortlist only narrows the menu — misses still return null, no heuristic guess. Pinned in tests/leadUnderstand.test.ts.

240q-s. Quote calc/GST fixes, margin coins, back + draft (owner, 2026-09-21)

• §240q: calc rates fixed — blank row GST followed nothing and read as 0%, so materials escaped GST (traced vs the Calcn sheet: 71.16/74.72 now exact). buildCalc backfills null row/sizing GST from global.
• §240r: selling coins snap margins to nearest ₹0.25.
• §240s: Back goes to the Quotes list (header ←); entries survive browser-back via a sessionStorage draft (cleared on save).
• §240t (engine, UI next): dhara + brokerage % lines in the costing engine (null/0 = today's numbers, suite green); dhara master UI + quote coins pending. Check green, 2067/0 tests. Deployed.

246. Enquiry memory: confirmed words → party/quality, zero-API repeats (owner, 2026-09-21)

• Owner: remember word associations (a word linked to a quality/party), adaptive + cheaper. New enquiry_memory table (word|kind|partyId|text| hits, migration 0023, evt dedupe index recreated after push).
• Learn: on lead save, the confirmed dictate words link to the saved party + quality (hits count up, capped, pruned). Recall: understand checks memory first — a party hit fills party (+ remembered quality, regex qty/rate) with NO api call (by: memory, "Remembered" label); misses take the LLM path as before. Pure resolvers tested.

247. Quote yarn popup: count + rate + share in one tap (owner, 2026-09-22)

• Owner: warp/weft rate + count + share must sit in the warp/weft popup itself, not one click deeper. Re-applies §240n (a later merge re-introduced the hide-when-single guard): Share % now always renders in yarnPop for warp AND weft; openYarnField narrows to sizing-only. Pinned: no {#if yrows.length > 1} guard.

248. Quote calc vs owner sheet (owner, 2026-09-22; FIXED + DEPLOYED)

• Owner photo (Calcn: reed 137.5 / pick 65 / spaces 50 / lasa 110 / L2L 107 / 61s @450.25 / sizing 30 / job 7ps / 5% GST): sheet says warp 30.73 / weft 14.87 / sizing 2.05 / job 4.55 / total 52.20 + 5.5% = 55.07; engine agreed everywhere EXCEPT warp (30.81, +0.08).
• Root cause from the shared sheet's formulas (C20): warpKg = ends × pct × 120/1852 / count / L2L — Lasa is displayed but has NO term in the sheet's warp math. The engine's lasa/l2l×0.5905 allowance ran ~0.25% high on every warp line. Fix: engine follows C20 verbatim — reconciles to 6 decimals on BOTH the §5 trace (120×65/41s/ L2L104 → 0.1185271032 exact) and the photo (→ 30.73/52.20/55.07). COSTING.md §2/§5/Q1 corrected; photo case + L2L-0 guard pinned in tests/yarnMath.test.ts. L2L ≤ 0 now falls back (was ÷0 → Infinity).
• Owner ruling 2026-09-22 (final): the ENGINE was right all along — the sheet's 120/1852 warp shortcut is wrong (it drops Lasa). Reverted the same turn: engine back to lasa/l2l×0.5905, COSTING.md + tests restored, L2L-0 guard and jobGst fixes kept. Photo case reads 55.16 on the correct math ( sheet's 55.07 stands as its own error).
• §249 (owner, 2026-09-22): the 62" satin screenshot (Basic 34.67 / With GST 35.04) verified line-by-line — all ex-GST lines reconcile (warp 12.32 / weft 14.87 / siz 0.82 / majuri 4.55 / other 2.12). But With GST 35.04 exposed a lost §240q fix: blank row GST fell to 0% instead of inheriting global, so materials escaped GST whenever the yarn master carried no GST. Re-applied in the engine (row/sizing fallback = global %): same quote now reads With GST 36.42. Basic unchanged.

250. Denting: reed is per 2", ends need ends-per-dent (owner, 2026-09-22)

• Owner: 55/5 reed = 55 dents/2" with 5 ends per dent → EPI 137.5. The engine did ends = reed × space (2750) instead of 6875 — every dented quality costed ~2.5× low on warp (satin showed warp 12.32, correct is 30.81). Fix: design.denting (default 2, keeps EPI-form masters byte-identical) — ends = reed × space × denting / 2; master field + quote adjust; name parser (reed/denting*pick) prefills it for user confirmation; migration 0024; all 622 live designs backfilled from their names (582 parsed, 40 default 2). Pinned: 55/5 → 6875 ends, warp 30.81.

251. Quote popups get the leads keyboard treatment + popup spec doc (owner, 2026-09-22)

• Owner: typing in any quote popup had the old header-crowding bug, already solved in leads. Root causes (both fixed in /quote/new): (a) yarn/adjust/quality-add popups used plain items-center, so the keyboard covered them — now dock {kbOpen ? 'items-end pb-2' : 'items-center'} like the wizard; (b) the wizard-open header-hide only ran on wizard steps, so popups opened from the summary landed under the header — now a chromeHidden derived keeps it hidden while ANY popup is up; plus scrollIntoView on every popup input.
• Owner rule recorded: the reusable shape now lives as FOCUS-ENTRY §4b (exact copy-paste snippet + 7 rules: z-scale, docking, header-hide, chrome-hiding, card scroll, input focus, widths). Next popup in any form copies §4b — no new shapes.

252. Other % is quote-only, never the master (owner, 2026-09-22)

• Owner: Other cost % belongs in the quote, not the quality master. Removed the master field (form + builder default); the wizard uses the typed adjust value or 5.5 — the stored master 6.5 can no longer leak into quotes. Also explains the "typed 5.5 but showed 3.4" report: the calc had used the master's 6.5 — always tap Set (edited badge) after typing, then Calculate.- Real bug fixed meanwhile: buildCalc had a duplicate jobGstPct key — the second (g('jobGst', null), always null) wiped the fixed-5 first, so job GST silently followed the fabric GST (§240k says fixed 5).

249. Order screen shows every full-flow A4 field (owner, 2026-09-22; READY)

• Gap: /orders/new ran the §211–215 focus wizard with only 5 steps (source/party/quality/qty/rate) — ~15 bible fields (mode, cut size, rolls, send-as, city, CD, payment/due/promise days, brokerage, pass-on, broker, buyer order no, date, remark, tolerance, job rate/picks, papers, outsource terms) lived in the hidden form with no summary row and no wizard control, so they could never be entered. perPieceMtr had no input at all (server validated+stored it, record page displays it); promisedDays/deliveryForm/partyContractNo/ outsource T&Cs were uncontrolled (reset/progress blind to them).
• Fix (FOCUS-ENTRY pattern kept: read-only summary + wizard + hidden form, POST names/server byte-identical): sectioned summary with one row per A4 field (Reference & setup / Buyer & fabric / Quantity & delivery / Price, terms & papers); wizard step 0 gains kind setup (MTO/STOCK · trigger/target · loom/beams), step 1 broker search+coins, step 2 nickname/buyer-no/date/remark, step 3 cut size/rolls/per-piece/ send-as/city/tolerance, step 4 full terms + papers + outsource T&Cs; wizard body scrolls. Pinned in tests/order-fields-visible.test.ts; the c14 POST-contract pin gains perPieceMtr (server contract unchanged).

250b. Order form split in 2 parts: sales booking + operations completion (owner, 2026-09-22; AGREED)

(numbering note: parallel session's denting entry took §250 first — this is the second §250, labelled b.)

• Owner: a fabric sale / job-work order has two parts. Sales books buyer and/or broker (broker ALONE allowed — production fills the buyer later when the contract copy arrives — or buyer, or both), quality, quantity, rate, payment terms, brokerage + pass-on %. Everything else is filled later by production/operations staff.
• Agreed shape: PART 1 = slimmed /orders/new (sales fields only; buyer-or-broker required, broker-only bookings stay buyer-pending). PART 2 = operations completion on the order record page as an appendage (?/complete: buyer, buyer order no, mode, cut size/rolls/per-piece, send-as, city, CD, due/promise days, job economics, loom/beams, tolerance, papers, outsource T&Cs + contract file) — full before→after diff in the amendment + event, never a silent edit. Broker-only rows read "via {broker}" on the orders list; the record shows a buyer-pending banner + missing-fields list.

253. Order wizard skips lead/quote-carried steps (owner, 2026-09-22; AGREED)

(numbering note: parallel session's other-% entry took §252 first.)

• Owner: in an order, when a lead/quote is picked, the fields it carries need no wizard popups.
• Agreed shape: pure isWizardStepCarried in orderLogic (a step skips when its key field arrived with src quote/lead — broker-alone counts for the party step; history/design carries never skip) + firstOpenWizardStep. Wired into /orders/new: Next jumps over carried steps, first open snaps to the first step that still needs a popup (all-carried dismisses to the summary, no forced review), Back still steps back for edits and summary rows reopen anything.

254. Quote wizard skips lead-prefilled steps (owner, 2026-09-22)

• Owner: once a lead is picked for a quote, the other wizard popups that were prefilled from it need not show. Quote twin of §253 (orders).
• Agreed shape: pure isQuoteWizardStepCarried + firstOpenQuoteWizardStep in quoteLogic (a step skips only while a lead is in play AND its value already arrived — an unmatched design or an empty warp/weft rate keeps its popup so it can still be filled; dictate never carries). Wired into /quote/new: pickLead and the one-time ?leadId=/draft snap land on the first open step (all-carried → summary), wizNext jumps carried steps, quality/party still drop out of steps as before. Summary rows and Back still reopen any step for edits.

255. Quote counts fall back to the master count (owner, 2026-09-22)

• Owner: warp/weft count, when there is no previous quote, must come from the master. Root cause: 602/622 designs store only the legacy single warp_count/weft_count string ("32/1", "40PC", "40S") and a null warp_rows/weft_rows JSON, so the prefill (lq?.warpRows ?? D?.warpRows) fell to a blank row and the counts never showed.
• Fix: pure masterCountRows in masters.ts derives a one-row list from the single count (leading number; a den/tex suffix picks the system, else Ne). /quote/new designData normalizes it into warpRows/weftRows when the JSON is absent (masterRowsJson); /quote/edit uses the same fallback in resolveQuoteInput. Precedence unchanged: previous quote → else master. Rate still comes from the row/master and stays editable.

256. New quote always starts blank (owner, 2026-09-22)

• Owner: the New quote button was showing the previous quote prefilled. Cause: the §240s sessionStorage draft auto-restored on every /quote/new mount, so an earlier (unsaved) entry reappeared.
• Fix: the list button links /quote/new?fresh=1; the page clears the draft and skips restore when fresh, then replaceStates to /quote/new so a later reload still keeps the new entry's draft. Draft survival for browser-back/accidental exit is unchanged on the bare URL. Lead carries (/quote/new?leadId=) unaffected.

257. Optional quote fields can be cleared to none (owner, 2026-09-22)

• Owner: once an optional field (lead / party, also quality) is picked in the quote wizard, there was no way to clear it and select nothing. Cause: §254 filtered the carried steps out of steps, so the summary rows' gotoStep(...) hit a missing index and the ✕ clear inside the step became unreachable (party only cleared when no lead).
• Fix: steps always lists all seven (dictate/lead/quality/warp/weft/job/ party) and carried ones are SKIPPED on Next — the §253 orders pattern — so every summary row reopens its step and the existing ✕ clears lead, quality (also its rates) or party. Quality/party summary rows now call gotoStep('quality')/gotoStep('party') directly. Forward flow is unchanged (still skips lead-prefilled steps).

258. Android back on the quote calc returns to the summary (owner, 2026-09-22)

• Owner: after Calculate, the phone's back button left the new-quote screen instead of showing the summary to revise the calculation. The wizard phases are component state, not history entries, so Back popped the route (→ /quote).
• Fix: beforeNavigate in /quote/new cancels a popstate while phase === 'calc' and sets phase = 'summary' — SvelteKit's history.go(-delta) keeps the user on the page. A second Back (now on the summary) leaves as normal.

259. Deploy host clarified: the Pi is dsh.tynolabs.com; live checkout /home/fp/trading (owner, 2026-09-22)

• Owner: dsh.tynolabs.com runs on the Pi, and from that same box trading.tynolabs.com is hosted — so an agent whose shell is on it can always run the deploy directly (no SSH).
• Reality checked: systemd project@trading has WorkingDirectory=/home/fp/trading (the app moved there 2026-09-07; not /home/fp/sites/trading, which is now a leftover dir with a 0-byte data.db), DATABASE_PATH=/home/fp/trading/data.db, hostname fp (Raspberry Pi 5), cloudflared tunnel dsh fronting both hostnames.
• Bug: scripts/deploy.sh's host gate only accepted /home/fp/sites/trading, so it refused (exit 3) on the real host. Gate now accepts both /home/fp/trading (live) and the legacy path.
• Docs updated with the dsh=Pi fact + true paths: AGENTS.md (mandate 1 + "Where it runs"), docs/DEPLOY.md (architecture, gate, DATABASE_PATH, .env, backup), README.md (scp path; dev command → bun --bun run dev).
• Verified by a real deploy dec66ee: pull → bun test green → build → restart → health (Caddy: 303 anon → /signin, 200 authed) → commit → push.

260. Correction queue becomes a self-running, verified loop (owner, 2026-09-22)

• Owner pain: one change at a time is tedious; each change brings new bugs or misses, and corrections pile up between sessions with no engine to drain them.
• Decision: keep CORRECTIONS.md as the owner's shelf (unchanged, single writer), and add a machine layer on top:
  • scripts/queue-next.ts — parses the Pending table + reopen feed into docs/QUEUE.md (its only writer), auto-holds ambiguous rows as blocked-owner, and computes non-overlapping batches (hot files never share a batch). Commands: --sync, --list, --next [n], --set, --reopen. Targets/acceptance are enriched by lanes, not guessed.
  • .opencode/agent/runner.md (primary) — supervisor: triage → run one batch → gate → deploy once → verify → append ledger.
  • .opencode/agent/lane.md (subagent) — one row, test-first, owned files only; triage lane writes observable acceptance checks.
  • .opencode/agent/verifier.md (subagent) — independent acceptance check against the running app (browser MCP + DB/tests), never the implementer's word; FAIL appends a reopen that re-queues at P0.
  • /next and /queue commands; docs/OWNERSHIP.md (lane/file map); docs/PROMPTING.md (the five-slot correction contract).
• Rationale: the same agent writing code and its own test is why misses slip through — an independent verifier is the fix. Batching by file ownership removes the manual one-at-a-time coordination.
• tests/queue-next.test.ts (13) locks parsing, reopen folding, blocked-owner detection, batching/hot-file serialization, and the placeholder round-trip. Suite 2117/0, check clean.

261. Quote yarn popup: count stepper + board rate list (owner, 2026-09-22)

• Owner: warp/weft count should step by 1 (hold to repeat) and allow one decimal; count still rides the same quality's previous quote (else the master). The rate should come from the daily rate board — a searchable list of every mill's rate for that yarn (e.g. 61 CCW), a suggestion coin from the last ticket picked for the same quality, and a ± stepper at 0.25 per tap that accelerates on hold. Split the popup: count (+ share) first, rate next; show Share % only when that side has >1 warp/weft (reverses §247).
• Fix: popup gains step: 'count' | 'rate'; count uses the FOCUS-ENTRY hold-to-repeat pattern (±1, blur rounds to 1 dp); rate uses ±0.25 with the same hold, an Excl/Incl toggle, and a board list from rateBoardAll (all mills, deduped) filtered by the row's count and the yarn-master type token via pure boardEntriesForYarn; the last ticket picked is remembered per quality+yarn in localStorage and shown as a ★ coin. Load now returns yarnList + rateBoardAll.

262. Runner is continuous — one start drains the whole board (owner, 2026-09-22)

• Owner asked why they must prompt /next after every task; wants an assembly line: pin corrections, runner keeps working, verifier sends failures back automatically.
• Change: .opencode/agent/runner.md now loops — after each batch is deployed + verified + closed it re-syncs and starts the next batch with no owner prompt. Stop conditions are explicit: board drained, blocked-owner needs a decision, the same row fails verification twice, a red gate after a real fix attempt, or the turn budget. A full auto-watcher (starts on its own when new slips are pinned) is deferred — it needs the opencode launcher path and a kill switch.
• Owner's remaining role: answer blocked-owner rows and review results.

263. Watcher: the runner starts itself when the board has work (owner, 2026-09-22)

• Owner: an agent should re-prompt the runner whenever it stops with tasks still pending, without the owner typing /next each time.
• Reality: an agent cannot self-trigger (its turn ends when it stops), but opencode exposes session.idle + session.prompt, so a helper can. Chose an external watcher over an in-opencode plugin: stoppable, testable (the plugin couldn't be verified without restarting opencode), no startup risk.
• Built: scripts/queue-watch.sh (start|stop|status|run|once), driven by queue-next.ts --has-work (exit 0/1; hasWork() unit-tested). While armed (.queue-auto) it peeks every 60s and starts opencode run --agent runner --auto --attach http://127.0.0.1:4100. Guards: no run when disarmed/empty, 6 starts/rolling-hour cap, 1h per-run timeout, one-command kill switch. /auto-on /auto-off commands; docs/QUEUE-AUTO.md; runtime files (.queue-auto, pid, stamps) gitignored. blocked-owner rows are not runnable, so the watcher never spins on a held row.
• Owner's role unchanged: answer blocked-owner rows, accept results.

264. Queue intake: ask the owner at pin time (owner, 2026-09-22)

• Owner put two corrections on the shelf (C62/C63) and the runner correctly reported TRIAGE FIRST — but nothing in the chain ever asked the owner what was needed. scripts/queue-next.ts is a deterministic parser: it cannot ask. The asking lives in the triage lane, which is only dispatched by the runner — so a report-only turn surfaced triage but no question.
• Change (owner rule): the moment a slip is pinned, the agent asks the owner right then for whatever is needed to make the row runner-go — exact file target(s), observable acceptance check, reference design/base to verify against, and whether it batches with a sibling. Never just relay --list/--next output.
• Recorded in AGENTS.md → Workflow conventions so it survives sessions.

265. Intake questions: plain language, only real business decisions (owner, 2026-09-22)

• Owner feedback after §264: questions came back in code terms (files, fields, localStorage, "queue numbers") and some were obvious. The owner does not code.
• Change: intake questions are asked in the owner's language, about the outcome (what should happen on screen, which real case/data to check, whether two slips are one job). Minor/technical details are NOT asked — the agent makes the safe assumption from the docs and states it in one line. Only genuine owner-only business decisions get a question; never ask an obvious one, never relay --list/--next output as the ask.
• Recorded in AGENTS.md → Workflow conventions (§264–265).

266. Watcher holds for the owner; reopens were invisible (owner, 2026-09-22)

• Owner: "why is the watcher doing so — correct it", and asked how they will be told when something needs them.
• Root cause: the verifier's --reopen appended to the END of docs/CORRECTIONS-REOPEN.md, which is after the "Archived" heading — but parseReopens only reads the ## Feed heading. So a failed verification was invisible; the row never flipped to reopen, the "same row fails twice" stop condition could never fire, and the watcher (which only asked --has-work) relaunched the runner on the same stuck row forever.
• Fixes: (1) --reopen now inserts inside ## Feed (appendReopen), with --resolve-reopen C<n> to archive a row's reopens once it finally passes; (2) new ownerNeeds() + --needs-owner (exit 0 when the owner must decide: a blocked-owner row, or a row reopened ≥2 times and still open); (3) queue-watch.sh checks --needs-owner before starting the runner and HOLDS instead of looping; (4) notification — the engine writes .queue-needs.json + docs/NEEDS-OWNER.md (both gitignored), and the home attention strip shows a "Corrections need you" card; the correction board /queue gains that count in its "Needs your decision" column (a row held or twice-failed is forced there with the reason shown).
• Regression pins in tests/queue-owner-needs.test.ts.

267. Correction board = table + questions feed + alerts (owner, 2026-09-22)

• Owner: wants /queue as a table — each item a row, its status in the next column, and a third "needs your action" column; and asked how the system will actively ask for clarification without the owner prompting.
• Board: /queue reworked from kanban columns to a table (Item · Status · Needs your action · Ref), ordered needs-you-first; keeps §266's .queue-needs.json reason logic and the 10s self-refresh.
• Questions feed: new append-only docs/QUESTIONS.md. The runner asks with queue-next.ts --ask C<n> --text "…" (records the question, holds the row blocked-owner — which §266's ownerNeeds already surfaces) and the owner answers with --answer Q<n> --text "…" (releases the row back to the queue). Open questions show in the board banner + the row's action cell; a new question while /queue is open raises a browser notification (opt-in "alerts" button). Composes with, does not replace, §266.
• Parser in src/lib/server/queueBoard.ts (parseQuestions); regression pins in tests/queue-board.test.ts; runner told to --ask, never guess.

268. Watcher never starts a second runner; board is a table + questions (owner, 2026-09-22)

• Two concurrent runners collided: the watcher can fire while a runner started earlier is still working (§266 keeps runs independent). Guard: before starting, queue-watch.sh now skips if opencode run --agent runner is already active — one runner at a time, always.
• The /queue correction board is now a table (Item · Status · Needs your action · Ref) with the questions feed (§267), so the owner can glance at what is done, what is running, and what needs them.

269. Model pinned to muse-spark-1.3-contributor; Luna retired (owner, 2026-09-22)

• Owner: gpt-5.6-luna exhausted the opencode-go credits. Use ONLY opencode-go/muse-spark-1.3-contributor.
• Pinned everywhere (nothing left to inherit): global ~/.config/opencode/opencode.jsonc (model + small_model + built-in agents), project opencode.json, every .opencode/agent/* (model: on runner/lane/verifier/focus-entry), every .opencode/command/*, and the watcher's headless run (--model, overridable via QUEUE_MODEL).
• Recovery: the in-flight runner was stopped to end Luna spend; its half-written C83 edit had broken orders/[id]/+page.svelte (unexpected block close), so that page + its test + the run's ledger lines were reverted to the last green commit. C83 stays on the board to be redone. Suite 2166/0, check clean.

270. Standing rule: Muse Spark only, assumed by default (owner, 2026-09-22)

• Owner: everything uses opencode-go/muse-spark-1.3-contributor from now on — assume that only.
• Recorded as AGENTS.md mandate 11 so it survives new sessions, new agents and new commands. The §269 config pins (global + project + every agent/command + the watcher --model) already enforce it at runtime; mandate 11 is the standing default every future agent reads.

271. Provider gate: opencode-go only, not Zen (owner, 2026-09-22)

• Owner: use the opencode-go provider only — never opencode (Zen).
• Added enabled_providers: ["opencode-go"] to the global and project configs. opencode models now lists opencode-go/* only; the opencode/* (Zen) models are gone, so no agent or session can fall back to them. AGENTS.md mandate 11 updated to state the provider gate.

272. Model split decision: agents = Muse, owner sessions = their choice (owner, 2026-09-22)

• Owner considered a two-tier split (DeepSeek planner/verifier, Muse coder) and chose Muse everywhere for agents/commands/background (kept as-is).
• Owner will keep their own prompting/reasoning sessions on DeepSeek by choice. Mandate 11 clarified: it governs agents/commands/background runs; the owner's interactive session model is theirs. Provider stays opencode-go only.

273. Runner forced to use lane/verifier, not the general agent (owner, 2026-09-22)

• Audit for "is the verifier running": verifier and lane had never run (0 log entries); the runner dispatched the built-in general agent (5,616 calls) instead, so independent verification never happened.
• Fix: runner.md now names the Task subagent_type explicitly — "lane" for triage/implementation and "verifier" for checking — and forbids routing a queue row through general; a row cannot be marked done without a verifier's reproduced evidence. All agents stay on Muse.

274. Verifier runs DeepSeek v4.1 Flash (model-independent verification) (owner, 2026-09-22)

• Owner: put the verifier on DeepSeek v4.1 Flash. Implementers/runner stay on Muse; the verifier is a different model so it does not share the implementer's blind spots (PLANNING §273 made the lane/verifier handoff mandatory in runner.md).
• verifier.md → model: opencode-go/deepseek-v4.1-flash; AGENTS.md mandate 11 amended (Muse by default, verifier exception). Provider stays opencode-go only.

275. Audit pass: verifier re-checks the pre-verifier done rows (owner, 2026-09-22)

• Owner: the 9 rows marked done before the verifier was wired (§273) must be re-checked by the verifier — not re-implemented.
• Added a verify-only path: queue-next --audit-done flips every done row to status: verify; verify rows are runnable but audit-only — runner.md skips the lane and the deploy and sends them straight to the verifier (DeepSeek). PASS → back to done with an "audited" note; FAIL → --reopen (row returns to P0). /audit command triggers it. Regression pin in tests/queue-next.test.ts (verify rows runnable + count as work).

276. Pass model: group same-file rows, one deploy per pass (owner, 2026-09-22)

• Owner: speed things up; the board had many rows but a single runner deploys once per row. Measured bottleneck: rows overlap on the same files — quote/new/+page.svelte is touched by 10 rows, quote/+page.svelte by 8 — so even infinite batch size yields 10 sequential batches. Runners cannot parallelise overlapping files.
• Change: queue-next --groups clusters overlapping rows into lane-sized groups (connected components of the target-overlap graph; big clusters chunked). Groups in different components are disjoint → parallel; groups in one component → sequential; hot groups run alone. The runner now implements a whole pass (every group) then does one gate + one deploy for it, instead of one deploy per row. This removes ~9 of 10 build/restart/commit cycles.
• Also fixed the restart-kills-the-follow-up problem: post-restart steps now run via systemd-run (a transient unit outside the opencode cgroup), so they survive the restart. Tests: planGroups pins in tests/queue-next.test.ts.

277. Swarm: shell-orchestrated parallel workers, one integrator (owner, 2026-09-22)

• Owner: the whole ERP (quote is only form #2) — need speed at scale with optimum token use. Bottlenecks: one shared workbench + one deploy door; monolithic screens force file collisions; provider rate limits cap throughput.
• Built: queue-next --workstreams (one workstream per file-disjoint component), scripts/swarm.sh (plan|dry|run), .opencode/agent/worker.md. Design: shell does all deterministic orchestration (planning, worktrees, merges, gate, deploy, ledger) at zero tokens; tokens are spent only on ONE lean worker session per workstream (all its rows — not per row) plus parallel verifier sessions. Each workstream = its own git worktree on branch swarm/<id>; the integrator (the script) merges them, runs the full gate + ONE deploy, then verifies each row.
• Token guards: lean worker prompt, targeted tests only (no full suite in the worker), no full docs re-read, concurrency cap SWARM_MAX=3 to avoid rate-limit retries. --max-rows caps rows per lane.
• Works today but only pays off when >1 component exists: the current backlog is a single quote component, so swarm.sh plan shows 1 workstream. New modules (yarn, sizing, weaving, checking, dispatch, …) become separate components → parallel workstreams. Existing watcher/runner keeps running until we switch; /wt/ gitignored.

278. Swarm mode on by default; component-first standard; Stage-1 split queued (owner, 2026-09-23)

• Owner: switch the live line to the token-efficient swarm, and do Stage 1.
• queue-watch.sh gained QUEUE_MODE — default swarm (runs SWARM_YES=1 scripts/swarm.sh run, no LLM orchestrator) with runner kept as a fallback; the active-agent guard now also catches worker.
• Stage 1 scope clarified: the standard (AGENTS.md mandate 12 — component-first, no monoliths) applies to every form going forward, not just quote. The retrofit is quote-first because it is the current bottleneck and the template; other existing monolithic pages get retrofitted as they become collision hotspots (C88 = the quote split).
• Queued C88 (quote component split) so the swarm picks it up as its first parallel-ready task.

279. Scale-up toolkit: hotspots, adaptive swarm, component standard (owner, 2026-09-23)

• Owner: scale the build up, fast; and asked whether every existing (crude) form must be reworked. Answer: no — only collision hotspots, on demand.
• Added:
  • queue-next --hotspots [--min N] — target files with >= N queued rows (which file to split next). Measured now: quote/new 10, quote/+page 8, quote/edit 4.
  • C88 widened to the whole quote flow (new + edit + list).
  • swarm.sh scale-safety: flock (one integrator only), adaptive concurrency (backs off on rate_limit/service_overloaded), per workstream status (a failed/ratelimited worker is skipped and its rows stay queued), and metrics to screenshots/swarm-metrics.jsonl (duration + counts) so we optimize the real cost.
  • docs/COMPONENTS.md — component-first standard, split rules, new-form checklist (backs AGENTS.md mandate 12).
• Rule: split a form only when --hotspots flags it; new forms are born split.

280. Self-healing collisions: --suggest-splits + /hotspots (owner, 2026-09-23)

• Follow-on to §279: queue-next --suggest-splits [--min N] prints ready-to-paste split rows for route-page hotspots; /hotspots command runs the report for the owner. OWNERSHIP.md points at COMPONENTS.md. So when a form starts colliding, the system names it and offers the split row instead of silently serialising.

281. Correction-builder reliability hardening (owner, 2026-09-25)

• Owner asked why the builder was unreliable; a day of real failures fixed: worktree had no data.db (~25 DB tests failed → gate red forever — the C92/C93 multi-hour loop); missing #lib sync; no auto-triage (all-day "nothing runnable" stall); stranded doing rows (line idle); merge-before-gate
  • destructive git reset --hard (wiped concurrent edits → safe_reset); empty-array crash; no retry cap (multi-hour loops); worker seeded the LIVE DB (now sandboxed to the worktree DB).
• Added a tested invariant layer: queue-next --reconcile (missing/stranded/ triage/stall) + regression tests; auto-triage lane; gear gate in-worktree; retry cap; stall alarm (.queue-stall → home strip + /queue banner + status.sh); Telegram notifications (scripts/notify.sh, gitignored token).
• Proven: fresh worktree full suite 0 fail/2242. Operations: scripts/status.sh.
• Recommended next: the supervisor is still shell and only partly tested — move orchestration into the tested TS engine and add behavioural (DOM/DB) verification before scaling further.

282. Requested: visible worker sessions (owner, 2026-09-25)

• Owner wants to SEE where a worker is stuck → run workers as VISIBLE sessions.
• Preferred: launch workers attached to the running server — opencode run --attach http://127.0.0.1:4100 --dir <worktree> --agent worker … so each worker = a real session in the opencode web UI (live turns/tools). MUST handle: attached runs execute tools via the server, so the per-worktree DB sandbox (DATABASE_PATH=<wt>/data.db) must be re-established server-side (or --dir must make the server cwd the worktree); and confirm the server resolves the worker agent from the worktree's .opencode/agent.
• Fallback: a read-only "current workers" panel on /queue showing the tail of each wt/<id>/worker.log (keeps the headless sandbox, raw log view).
• Noted while context was full; implement in the next session.

282a. Implemented: visible worker sessions (2026-09-25)

• Preferred path shipped (fallback not needed). scripts/swarm.sh now launches each worker as opencode run --dir <wt> --attach <server> --agent worker … (new knobs SWARM_ATTACH default 1 · SWARM_SERVER default http://127.0.0.1:4100 · SWARM_SERVER_USER/PASS), so every worker is a live session in the opencode web UI (title swarm <ws>). If the server is unreachable (or SWARM_ATTACH=0) it falls back to the old headless run, so a dead server never strands the line.
• DB sandbox proven server-side: --dir <wt> makes the server run each tool with cwd = the worktree (verified via POST /session/{id}/shell: pwd = the worktree, data.db = the worktree copy). On top of that, each worktree gets a gitignored .env pinning DATABASE_PATH=<wt>/data.db + empty TURSO_*, so the sandbox holds even if the server process env changes.
• Worker agent resolution: the server resolves worker from the directory's .opencode/agent (confirmed with GET /agent?directory=<wt> + a live run) — worker.md is mode: primary.
• Fixed two blockers found while proving the end-to-end run (both had made every gate red): (a) a fresh worktree had no BETTER_AUTH_SECRET, so vite build always failed — the worktree .env now supplies it; (b) every worktree shared one node_modules dir symlink, so one node_modules/.vite-temp was shared and a failed build poisoned the next with “Cannot find module …/.vite-temp/vite.config.ts.timestamp-.mjs”* — worktrees now get a real node_modules of per-package symlinks (own .vite-temp), cleared before each build. Also stopped tracking status/worker.log/.swarm-brief.md (gitignored; a checked-out stale status=ok could fake a finished worker).
• Regression guard: tests/swarm-visible-workers.test.ts. E2E: a real attached worker session ran its tools in wt/probe, used the worktree DB, created and committed its file.

283. Smaller batches, small-first (owner, 2026-09-25)

• Owner: the runner should work the board in smaller batches, small fixes first, so a quick win is not held behind one big row (the C103 pain) — but only after the current batch completes; do not disturb the running flow.
• Shipped: scripts/queue-next.ts gained a total batch cap and a small-first order (priority → fewest touched targets → id) in planGroups/planWorkstreams. Cap resolves --max-total flag → QUEUE_BATCH_MAX env → repo file .queue-batch-max (set to 3). Rows beyond the cap stay pending for the next run, so each pass deploys a smaller batch. Regression guard: tests/queue-next.test.ts ("cap … smallest first" + "cap defers the larger rows").
• Safe to apply mid-run: the running swarm had already computed its plan and never re-plans after the workers launch, so the cap takes effect from the next run only — no disturbance. Documented in docs/QUEUE-AUTO.md.

284. New default: "do it" = queue it (never hand-apply) + offer reprioritise (owner, 2026-09-25)

• Owner rule for every future session: whenever the owner says "do it" (or any "just do it" phrasing), the default action is to QUEUE a correction row for it in docs/CORRECTIONS.md + docs/QUEUE.md — do NOT apply/implement it by hand, even when it looks trivial (this supersedes the earlier play-by-play handling of C109 / the verify-max knob).
• After queuing, ask the owner whether they want to reprioritise the queue (move the new row up/down / set its order) — the runner then works it in the normal flow.
• Rationale: the builder owns all implementation + verification + deploy; a hand-applied change bypasses the verifier/ledger and disturbs the flow. The session's job is to translate the owner's words into a well-formed row and keep the queue honest.
• Exceptions stay only where the builder literally cannot act (e.g. a step that must not run inside a swarm run) — and even then it is queued first and flagged, not silently hand-done.

285. Owner approves C108 + C116 — line released (owner, 2026-09-26)

• Owner said yes to both needs-owner items: C108 (quote left-swipe label → "Orders") and C116 (split hourly caps scoping 12 + working 12).
• Session released both via queue-next --set <id> --status pending --notes "owner approved …" + --sync (sanctioned writers only, no hand-edit). --needs-owner now empty, NEEDS-OWNER.md = "Nothing needs you", watcher guard needs owner: no.
• Side effect: C68 returned to reopen — its reopen-feed defect lines are still open, so --sync re-asserted runnable status (by design, not a manual unblock).
• Board after release: 31 rows · reopen 8 · pending 23 · blocked-owner 0. Watcher picks up the next batch on its own tick (batch cap 3, small-first per §283).

286. Builder stays light on the Pi: --smol tests + serial builds (owner, 2026-09-26)

• Owner rule (prompted by 85.6 °C throttling during a 3-worker round): the test suite runs with the small-footprint runtime (bun --smol test) and the production build runs one at a time — at most one heavy step (test / check / build) on the host at any moment.
• Recorded durably in docs/QUEUE-AUTO.md ("Heavy steps stay light and serial"); implementation rides the matching queued rows — C119 (shared-lock serialisation) + C120 (--smol/--parallel/--bail, single suite run per round) + C117 (thermal governor). No new row needed.

287. Never two heavy jobs at once (owner, 2026-09-26)

• Owner sharpening of §286: simultaneity is for thinking, never for burning — while one worker runs test/check/build, the others do light work or wait. Recorded in docs/QUEUE-AUTO.md; enforced by C119 (shared lock).

288. Temporary 1-worker cooldown cap (owner, 2026-09-26)

• Pi sat at 84–85.6 °C throttled during 3-worker rounds. Owner: cap to 1 worker until cool.
• Live as /etc/systemd/system/queue-watch.service.d/zz-cooldown-cap.conf (SWARM_MAX=1, sorts after workers.conf; watcher restarted, verified). Applies to future runs only — the in-flight C118 round untouched. Remove the file + restart to restore 3. Permanent fix: C117 governor.

289. C118 fixed BY HAND — owner-ordered exception to §284 (2026-09-26)

• Situation: 4+ consecutive swarm rounds failed at the gate with no commits (poisoned env: watcher-pinned split knobs leaked into every bun test, C116 legacy cases 8/10). Line thrashing on a throttled 85 °C Pi. Owner: "stop everything. do c118 manually first."
• Stopped: queue-watch service + manual swarm run + all worker/lane agents (live app untouched, still 303-healthy).
• Fix (3 files): tests/setup.ts deletes QUEUE_MAX_SCOPE_PER_HOUR/WORK_PER_HOUR from process.env at preload (gates need no change — one place covers worktree/integration/deploy); new tests/c118-queue-test-env-isolation.test.ts (scrub pinned · legacy applies under poisoned outer env · explicit split still independent · stamp files ignored; fails 2/4 pre-fix with knobs, mirrors C116's 8/10→10/10). .gitignore already covered the stamp files (verified via check-ignore, no change).
• Proof: c116 10/10 + c118 4/4 with knobs present AND absent · bun run check 0 errors · full suite 2335/0 with knobs present · deploy.sh green end-to-end (build→restart→health 303→commit 8d45c10→push).
• C118 left pending for the verifier to close on proof (no hand-close per ledger rule); deploy's step-3b resurrected the watcher, so it was stopped again — line stays stopped until the owner says go.

290. Heat emergency: fail-loop root-caused + fixed by hand (owner, 2026-09-26)

• Situation: Pi at 85–86 °C, throttled=0xe0008 (under-voltage + thermal). Acute since Sep-25 18:53 (3dbe31e removed the thermal guard, back to 2 workers). Owner: "go ahead right away… sort this out first" — hand-fix authorised, queue may run or stop as needed.
• Root causes (evidence, not guesses): (1) swarm runs gatefailed every 3–8 min (143 worker starts, 24MB swarm.log) — heat slowed the box so probes tripped Bun's default 5s test timeout (airtight-money hook flake, green standalone) → no merge → rows stayed queued → watcher refired; the 15-min backoff never triggered because each gatefail run still exited through paths the watcher counted as non-consecutive, and overlapping runs (see 3) scrambled the counter. (2) Overlap blind spot: the watcher's "agent active" guard matched --agent runner|worker but NOT --agent verifier — a new swarm started while the previous run was still in its verify phase (two swarm.sh run + workers alive at once, seen live). (3) Every worker ran VISIBLE (--attach, §282): 25–40% CPU each in server polling alone, before any test/build. (4) scripts/thermal-governor.sh (C117/C123 target) did not exist, so those rows could never clear the gate.
• Fixes (this turn, all in repo unless noted): watcher guard also matches --agent verifier (queue-watch.sh); all three suite gates run bun --smol test --timeout 30000 (per §286 --smol + 30s flake headroom; swarm.sh workstream + integration gates, deploy.sh step 1/6); new scripts/thermal-governor.sh (status|temp|max-workers, THERMAL_TEMP_C-mockable; ok<70/warm<80/hot<85/critical, 2/1/1/0 workers) wired into queue-watch.sh status; log rotation caps screenshots/swarm.log + metrics at 5MB per run start; /etc/systemd/system/queue-watch.service.d/attach-off.conf pins SWARM_ATTACH=0 on the Pi (headless workers; delete + restart to restore §282 visible). Stale worktrees removed (branches kept), stranded doing rows (C108/C116/C123) reset to pending.
• Proof: full suite 2335/0 in 17s (no competing workers) · bun run check 0 errors · governor status live · temp 86.2 → 83.4 °C and falling with the line paused. Deploy (below) re-arms the line: next run is one headless worker under SWARM_MAX=1 + 12/h caps.

291. Pareto --smol sweep: agents stop running bare bun test (owner, 2026-09-26)

• Owner saw agents still running bun test without --smol. Gates were already --smol since §290 (swarm.sh worktree + integration, deploy.sh step 1) — the bare form agents copied came from prompts/docs, not scripts.
• Pareto cut (3 files, the ~80% of executions): .opencode/agent/worker.md (full suite per group × parallel workers = the bulk of Pi load) + AGENTS.md Commands/mandate-10 + docs/TESTS.md Run/Rule-3 — all now canonical bun --smol test --timeout 30000, worker brief adds a "never bare bun test" line.
• Deliberately out: runner/lane/verifier/focus-entry briefs (once-per-pass or single-file, light), package.json, promote-stable.sh, swarm log strings, C119 heavy.sh + C120 single-run (stay in their queued rows); ledger history untouched (append-only).
• Pinned by tests/smol-gate.test.ts (fails pre-fix on the bare forms, passes post-fix).

292. Prod moves Pi → VPS vps-d3go (owner, 2026-09-26)

• Why: Pi thermally throttling (85–86 °C, §290) + owner ordered VPS as new prod: dsh.tynolabs.com = opencode server, trading.tynolabs.com = bun-built app, both via a NEW cloudflared tunnel (old dsh tunnel retired with the Pi).
• VPS layout (mirrors Pi DEPLOY.md): project@trading (template /etc/systemd/system/project@.service, root-owned, WorkingDirectory=/root/%i) on 127.0.0.1:4102 · opencode.service (opencode serve --port 4096 --hostname 127.0.0.1) · Caddy :4103 with shared Basic Auth org/parag123, host-routed (trading. → 4102, dsh. → 4096) · new named tunnel → http://127.0.0.1:4103.
• scripts/deploy.sh host gate now also accepts /root/trading (was Pi-only); queue-watch steps are no-ops here until the watcher is installed (graceful skip already in script).
• .env on VPS carries the shared Turso DB + fresh BETTER_AUTH_SECRET (gitignored, never committed). Fresh checkout needed drizzle-kit push + seed-demo.ts before the suite went 2352/0.

293. C106 — Quote 500s under concurrency: ALS-free session read (2026-09-26, VPS)

• Root cause: all 39 request-path session reads called auth.api.getSession({ headers }), which runs through better-auth 1.7.2's AsyncLocalStorage request state (getCurrentRequestState via should-session-refresh). svelteKitHandler never wraps page loads in runWithRequestState, and under concurrent Bun requests the ALS context is intermittently lost → No request state found → 500 on /quote (/leads, /).
• Fix (not a per-page patch): new src/lib/server/session.ts getSessionUser(headers) — verifies the signed session cookie (HMAC-SHA256, better-call shape) and reads session+user via Drizzle directly. No ALS anywhere. Same { session, user } shape; expiry enforced; sliding refresh mirrored (7d expiry / 24h update-age). All 25 files / 39 call sites swapped (hooks keeps auth for svelteKitHandler). src/lib/server/db.ts now reads process.env instead of $env/dynamic/private (identical server-side values) so the helper is importable under bun test.
• Proof: tests/c106-auth-request-state.test.ts (9: zero-direct-call gate + helper behaviour + 50× concurrent reads + refresh; gate failed pre-fix) · tests/quote-package.test.ts updated to the new import · full suite 2361/0 · bun run check 0 errors · scratch dev server (local DB, prod untouched): 20 concurrent authed GET /quote → all 200, zero No request state found, anon → 303 /signin, non-owner /approvals → 303.

294. Browser password off trading.tynolabs.com — app login is the door (owner, 2026-09-26)

• Owner: "disable browser auth, as there is already login". /etc/caddy/Caddyfile on VPS had site-wide basicauth on :4103 (shared org/parag123 over both hosts) — every trading visitor hit the browser password before the app.
• Safe to remove because the app gates itself: +layout.server.ts redirects anon page loads to /signin (public: /signin, /c/*, /api/*, /docs), hooks.server.ts 401s anon form POSTs, and every /api/* endpoint self-gates via getSessionUser (spot-checked: capture/ocr/loomgate/amend/lead-understand/approve all 401 unsigned). Only intentionally-public surfaces stay open (/c/* confirmation links, /docs viewer).
• Change (host-local, not in repo): basicauth moved from the :4103 site block into the @dsh handle only; @trading proxies bare to 127.0.0.1:4102. caddy validate green + systemctl reload caddy (pre-existing basicauth-vs-basic_auth deprecation warning, untouched).
• Proof: loopback Host: trading.tynolabs.com / no creds → 303 to /signin (was 401), /signin → 200; Host: dsh.tynolabs.com no creds → 401, with creds → 200; public https://trading.tynolabs.com/ no creds → 303 to /signin, /signin → 200.
• Repo follows: docs/DEPLOY.md (diagram, Caddy line, Credentials, health-check curl) + AGENTS.md + docs/APP.md + docs/STATUS.md no longer teach the trading door; scripts/deploy.sh health check drops -u org:parag123 (still warns-not-fails, so Pi-era Caddy stays non-breaking).

295. VPS builder line: leanness audit + autonomous go-live (owner, 2026-09-26)

• Owner order: verify the pipeline is lean on CPU/RAM/tokens, optimise first, then run the queue autonomously (queue when free, review verified work later), with as many builders/verifiers as the VPS safely holds, to finish the ERP fast. Host: vps-d3go, 2 vCPU / 6GB RAM (5.2G avail) / load ~0.5 — weaker CPU than the Pi-4 but more RAM, and no thermal sensor.
• Audit: tokens already lean (shell does planning, one worker per file-disjoint workstream, verifier on cheap deepseek-v4.1-flash). CPU/RAM drags found: (1) thermal-governor.sh double-printed unknown with no sensor → status misparsed to level=critical/max_workers=0 (VPS-only; Pi unaffected). (2) Verifier loop missed its & — VERIFY_MAX never capped anything because verifiers ran serially. (3) scripts/ defaults still point at Pi's :4100; the VPS opencode server is :4096, so workers silently fell back to headless. (4) data.db.bak-* untracked (gitignore *.db misses it) — swarm.sh refuses a dirty tree, so one stray backup would block every run. scripts/heavy.sh (C119) still absent — queued row, not taken here.
• Fixes (this turn): governor silent on no-sensor (VPS status now unknown/unknown/1; c123 10/10 still green); verifier truly backgrounded + VERIFY_MAX default 1→2 (verifiers are I/O-bound, safe on 2 cores); stale default 3 comment corrected to 2; gitignore gains data.db.bak*.
• Safe concurrency on this box: 2 workers + 2 verifiers (workers edit-bound, gates saturate both cores; verifiers cheap). Raising workers further waits on C119's heavy-step lock — the queue itself unlocks the next step. Launch env: SWARM_ATTACH=0 (Pi §290 evidence: visible workers burn 25–40% CPU each in server polling), SWARM_SERVER=http://127.0.0.1:4096, batch 3, caps 12/12. Watcher armed via queue-watch.sh start; first swarm.sh run drains workstreams (3 pending at launch).
• Blocker (environmental): no GitHub credentials on this fresh VPS (git pull/push fail could not read Username; remote skpawar1305/trading), so deploy.sh step 0 cannot pass here — changes committed locally, push pending creds. App needed no restart (no app code touched).
• Follow-up fix (same turn): first two watcher-started runs failed in ~4s with zero commits — swarm.sh hardcoded the Pi binary /home/fp/.opencode/bin/opencode (QUEUE_OPENCODE only fed the watcher, not the workers). Fails counter reached 2/3 before the catch — one more bogus run would have wrongly held rows blocked-owner. Both scripts now probe /root/... then /home/fp/... then PATH (no test pins the old path); run_timeout no longer errors when .queue-run-timeout is absent; .swarm-fails reset to 0 and stale worktrees cleared before relaunch.

296. Queue audit: drop dev-system rows with no VPS value (owner, 2026-09-26)

• Owner order: audit the board for dev/queue-system rows that are unneeded or buy no further optimisation, and remove them. Reviewed all 9 system rows (C107/C115/C117–C122/C124): kept C115 (work-order serves the queue-and-review workflow), C118 (fixed, awaiting verifier), C119 (heavy lock = unlocks >2 workers), C120 (single gate run), C121 (in flight), C122 (noop→done protects the fail counter), C124 (build-command hygiene).
• Removed via owner-delete (queue-next.ts --delete, precedent C109/C123): C117 (thermal-adaptive governor — Pi-only, meaningless on sensor-less VPS) and C107 (queue live-timer cosmetics — status + 10s refresh already show doing vs pending). Board 32 → 30 rows. Neither was in an active workstream, so the running pass is unaffected.

297. C119 + C120 fast-tracked by hand: 3 builders safe, one suite per round (owner, 2026-09-26)

• Owner question: is the full suite per worker necessary/overkill, and can builders increase if optimised? Measured on vps-d3go: full suite ~6s, check ~5s wall, single row test ~ms, build 11–27s. Verdict: the suite is cheap insurance (zero tokens — plain CPU), the repetition was the waste — up to 5 full-suite runs per round (worker gate ×N, integration, deploy).
• C119 (new scripts/heavy.sh): one flock on $(git rev-parse --git-common-dir)/heavy.lock so the main checkout and every worktree contend on the SAME lock. Wired into the swarm worktree gate, the integration gate, deploy.sh steps 1–2, and the worker brief. Fail-open by design: no flock, unwritable lock dir, or HEAVY_LOCK_TIMEOUT exceeded ⇒ the command still runs (never deadlocks the line).
• C120 (one suite per round): the worktree gate now runs only that workstream's own row test files (derived from row targets, new ws_test_files) + check + build; the integration gate is the single authoritative full-suite run with capped flags (--parallel=2 --max-concurrency=4 --bail=1); it stamps HEAD into .git/swarm-suite-green and passes --skip-suite to deploy.sh, which skips only when that marker equals the commit being deployed — absent/stale/mismatched ⇒ deploy runs the suite itself, so a red suite is still a hard stop.
• Worker brief updated (no more per-worker full suite), including the stale closing line that still claimed the opposite.
• Proof: tests/c119-heavy-serial.test.ts (8) + tests/c120-test-gate.test.ts (7) — 15 pass post-fix, 9 fail pre-fix (verified by stashing the script changes). Live lock proof: with A holding the lock 3s, B waited 2715ms. Full suite 2386/0, check 0 errors. smol-gate.test.ts kept green (canonical bun --smol test --timeout 30000 stays contiguous in the brief).
• Concurrency raised: SWARM_MAX 2 → 3 (build+check now lock-serialised, so 3 workers' thinking overlaps while their ~30s heavy bursts queue). Verifiers stay at 2.

301. C126 by hand: one worker per feature area + batch cap 3→6 (owner, 2026-09-26)

• Owner asked for the queue-cost fix by hand rather than waiting for the line. Done in-session (planWorkstreams now folds every overlap cluster of a feature area into ONE workstream, with areaOf picking the area and phaseRank ordering each session's groups schema/data → logic → screens → tests).
• Safety invariant preserved: overlap clusters are pairwise file-disjoint before area-merging, so areas still never share files — pinned by a test that asserts pairwise-disjoint target sets, plus a same-workstream check for two rows sharing schema-foundation.ts.
• Measured honestly (same board, old vs new planner): cap 12 → 6 sessions instead of 8 (C80 folded into quote, C103 into orders); cap 20 → 7 vs 7, i.e. no gain where rows already shared files. So C126 is worth ~0–25% fewer sessions, not the 4× first claimed. The real throughput lever was .queue-batch-max = 3 (only 3 rows were ever planned per round), now 6 — with heavy steps locked (C119) and one suite per round (C120) this is affordable.
• Trade-off stated to owner: a red integration gate reverts the whole batch, so a bigger batch risks losing more rows' work in one failure; the per-area worktree gate is what keeps that small.
• Proof: tests/c126-area-batching.test.ts (7) — passes post-fix, fails pre-fix (old planner lacks the area grouping); existing tests/queue-next.test.ts 30/30 unchanged; full suite 2394/0, check 0 errors.

299. C118 completed by hand + heavy.sh swallowed gate output (owner, 2026-09-26)

• Owner: "what is C118, complete it by hand and fix what needs fixing". C118 is the row that made every gate red: the C116 split-cap test's "legacy fallback" cases assume QUEUE_MAX_SCOPE_PER_HOUR/QUEUE_MAX_WORK_PER_HOUR are unset, but the watcher pins them in its service env, so they leaked into every bun test the builder ran (2/10 failures → the worktree gate, the integration gate and deploy.sh all red → nothing deploys).
• C118 acceptance re-verified live, all five: c116 11/11 with the knobs present; c118-queue-test-env-isolation 4/4; full suite green with the knobs present (run twice, 2397/0); git check-ignore confirms .queue-watch.stamps.scope + .queue-watch.stamps.work ignored via /.queue-watch.stamps*; split-vs-legacy behaviour intact (c116 file covers both). An earlier 6-failure run was not the env leak — it was a race with a still-running worker changing files mid-suite (2341 vs 2397 tests); clean re-runs are green.
• Real bug found and fixed (surfaced by C118's worker, on my own C119 wrapper): scripts/heavy.sh ran exec 9>"$LOCK" 2>/dev/null as a bare exec, so both redirections became permanent — stderr stayed /dev/null for the rest of the script, and bun test writes its results to stderr, so a gated run looked like it had printed nothing but the banner. Fixed by grouping the exec ({ exec 9>"$LOCK"; } 2>/dev/null) so only exec's own error is suppressed while fd 9 stays the lock and stderr is restored. Verified: results visible through the wrapper, failing command's stderr surfaces, exit code preserved, lock still serialises (B waited 1714ms behind a 2s holder).
• Proof: tests/c119-heavy-serial.test.ts 8 → 13 (3 new: stderr survives, real test run reports its result line, exit code + stderr survive failure) — 13 pass post-fix, 3 fail pre-fix (verified by restoring the old heavy.sh). Suite 2397/0 with the split knobs present, check 0 errors.

300. Why workers feel slow: measured, and the wasted work removed (owner, 2026-09-26)

• Owner: "still taking a lot of time by worker, you do it fast by hand, 3 rows show doing a long time". Measured the round rather than guessing: of the 5 workstreams, ws2/ws3/ws5 finished and passed their gates (16:47–16:54) while ws1 was still running. Actual heavy commands in the workers' own logs: ws1 ran the full suite 7×, ws5 5× (0 and 1 builds respectively), ws2/ws3 built 1–3×. So the per-row cost was dominated by workers re-running the whole suite — the exact thing C120 removed from the gate but which lived on only as prose in agent/worker.md, which the model does not reliably obey.
• Two structural reasons rows sit in doing for a long time, both by design and both worth stating plainly: (1) doing means "claimed by the current round", not "being edited right now" — a round marks all its rows up front and closes them only after every workstream finishes → merge → one suite → deploy → verify, so finished rows wait on the slowest worker; (2) one row still costs two fresh sessions (worker + independent verifier) plus its share of gates.
• Fixes: the no-waste rule now lives where a worker actually reads it — top of the generated .swarm-brief.md (hard-rules block: own row tests only, no full suite, no production build, no check) and AGENTS.md (the authority every agent reads), not only in the agent file. The redundant per-worker production build is removed (the workstream gate already builds once) and the worktree gate is now the sole build. Pinned by 2 new c120 tests (8 total) so neither location can silently lose the rule.
• C115 bumped to P0 — the board cannot distinguish "claimed" from "being edited", which is what made a healthy round look stalled. That row already carries the work-order numbers and the worker-vs-verification phases.
• Proof: tests/c120-test-gate.test.ts 7 → 8; smol-gate + c119 + c120 25/25; full suite 2399/0, check 0 errors.

298. Every agent, watcher and verifier on space-bunny-free (owner, 2026-09-26)

• Owner order: make opencode-go/space-bunny-free the model for everything — every agent, command, the swarm worker, the verifier, the queue watcher. One model, no exceptions.
• Swapped every pin: opencode.json (model + small_model), all 5 agents in .opencode/agent/ (runner, worker, verifier, lane, focus-entry) and all 7 commands in .opencode/command/, plus the shell defaults SWARM_MODEL, SWARM_VERIFY_MODEL (swarm.sh) and QUEUE_MODEL (queue-watch.sh) so the watcher and both gates start on it without an env override.
• The old split is gone: verifier used to be the one agent on deepseek-v4.1-flash while everything else ran muse-spark-1.3-contributor. Verifier independence was never the model — it is prompt-enforced (blind to the implementer's summary, evidence per acceptance check, reopen-on-fail, edit: deny). Same model, same rules; the C109 primary-mode pins and the c109 test keep the mechanics honest.
• tests/c109-agent-modes.test.ts second case rewritten: it used to pin verifier=DeepSeek / lane=Muse, so it now pins all five agents to model: opencode-go/space-bunny-free — a future one-agent drift fails the suite instead of passing silently. Prose mentions of "DeepSeek" in runner.md / audit.md corrected so no doc teaches a model that is no longer wired.
• AGENTS.md mandate line updated: one model everywhere, and verifier independence is prompt-enforced. Existing wt/ws* worktrees need no touch — swarm.sh recreates them from master (worktree add -B swarm/<id> … master) each round, so they inherit the new pin.
• Proof: tests/c109-agent-modes.test.ts 2 pass; no muse-spark / deepseek-v4 reference survives in .opencode/, opencode.json, scripts/, AGENTS.md or tests/.

302. Correction 1 (owner, 2026-09-26): tests can finally OPEN A PAGE

• Owner, in their own words: "our tests must be able to open a page at all. Today none of them do — all 194 test plain logic or just read the text of a code file. Build that ability first, on its own, before correction 2 is possible."
• Built tests/helpers/page.ts: from any test, openPage('/quote', { as: 'owner' }) boots the CURRENT source once per run, signs in through the app's own /api/auth/sign-in/email, and fetches the route over HTTP — so the page's server load, auth, database and markup are all really exercised. Also postForm() (real urlencoded POST with the CSRF Origin the app demands), signIn(), localDb(), looksLikePage(), stopServer().
• Four things had to be true for a test to open a page, each found by doing rather than assuming:
  1. the dev server's output goes to a FILE, never an undrained pipe — a piped stdout filled its buffer and BLOCKED the child, turning a 6s boot into 30s (it looked like a hang);
  2. bun --bun node_modules/.bin/vite dev instead of bunx (no resolution step);
  3. ORIGIN must be set to the dev server's own URL — auth.ts pins better-auth's baseURL to env.ORIGIN, so without it the dev host is rejected and /api/auth/* answers 404, i.e. a test could never sign in;
  4. the first /signin request pays SvelteKit's lazy route compile (~20s), so readiness is probed on a real page and the page tests carry a 120s timeout while the suite default stays 30s.
• tests/page-open.test.ts pins the capability itself: anonymous /signin renders; a protected page 303s an anonymous visitor to the door (auth is real, not stubbed); the owner can open /, /quote, /orders, /leads, /masters, /queue; a bogus route is a 404 not a crash; a real form POST reaches the server with its CSRF origin. 6 pass.
• A page test that cannot open a page FAILS — it never silently skips, because "a test that quietly did nothing" is the exact failure mode this correction removes. PAGE_TEST_BASE substitutes an already-running app when one exists.
• Cost, stated honestly: the suite goes from ~9s to ~36s (one boot + lazy compiles per run, reused by every page test). Full suite 2457/0, check clean. The spawned server shares the local data.db with the other tests and caused no lock contention.

303. Corrections 2 + 3 by hand: proof by opening, and a deploy that knows the DB (owner, 2026-09-26)

• Owner, in their own words: (2) "A finished change must prove itself by actually opening the page it changed, not by reading the code and finding a sentence in it... Also show me on the board which waiting changes still rely only on a test that reads code." (3) "Our deploy never applies pending database changes. That is the real reason the live site fell behind the tests. Make deploy apply them, and then have it check the live site is actually whole afterwards — the new table is there, the changed page loads, the demo data is present. A quick automatic check, not an agent." The independent live check stays — the owner wants the numbers first.
• Correction 2 — src/lib/server/queueEvidence.ts classifies what kind of proof a test gives: page (it opens a real page), code-only (it reads source text or only calls logic) or none. Checked against the real corpus, it calls C94, C96 and C104 code-only — the three the owner named — and page-open.test.ts page. Every /queue card now shows that verdict, and a screen-bound row whose evidence is code-reading is badged "needs page proof". verifier.md rewritten: opening the page is the PRIMARY proof, a missing table is a FAIL not a warning, and a code-reading test may not close a screen change. 15 tests, 3 fail pre-fix; deployed.
• Correction 3 — new scripts/apply-db.sh (deploy step 1b, before the new code serves, through the heavy lock): drizzle-kit push with stdin closed so a destructive change aborts rather than auto-dropping, then the evt dedupe index re-created, then WAL re-asserted. New scripts/live-check.ts (deploy step 4b, after the restart): every drizzle-snapshot table exists + the dedupe index, every REAL page (+page.svelte derived from the filesystem, ≤24) opens 200 with markup for a signed-in owner, and party/design/user rows are non-empty. No model, exit-code contract. The defect was real and is now fixed: the live database was missing payment_term — the table the masters screen queries, which is exactly why C96 "passed" while the screen would throw. After the apply: 29/29 whole. 13 tests, including one that runs the check live.
• A trap this exposed (and fixed). The first full-suite run after the push failed 40 tests with SQLITE_BUSY: database is locked. Cause: a local drizzle-kit push handed data.db back in SQLite's default delete journal mode, and in that mode the running app and bun test — which share that one file — cannot coexist. apply-db.sh now re-asserts PRAGMA journal_mode=WAL after every apply, the trap is written into AGENTS.md's DB gotchas, and a test pins it. Suite after: 2508/0, zero lock errors.
• Two of my own mistakes worth naming: I used pkill -f (repo rule forbids it — it matches the tool's own shell) and killed my own commands; and a hand-written smoke list named /suppliers and /production, which have no page of their own, so the check now derives routes from the filesystem.
• Suite 2508/0, check clean.

304. The board froze for hours: ONE held row stopped ALL work (owner, 2026-09-27)

• Owner: "the queue hasn't budged the whole night. Clearly something isn't working." True, and the cause was a design fault, not a worker failure.
• Evidence: screenshots/queue-watch.log carried the same line every minute for hours — owner decision needed (1) — HOLDING — and the board froze. The held row was C98, "failed independent verification 2 times". Meanwhile queue-watch.sh refused to start the runner while ANY row needed a decision, so one ambiguous row stopped all development — the exact opposite of the owner's standing requirement that work continues while they are away.
• Fix, both halves needed. (1) planWorkstreams/planGroups now take the owner-held set (heldSet() = explicitly held + twice-failed-verification, terminal rows never count) and exclude those rows from planning — the held row waits, everything else is planned and worked. (2) queue-watch.sh notifies once and keeps building instead of halting; its status line no longer claims "runner held". Held rows stay visible on /queue for the owner's decision.
• Proof: tests/c132-held-row-no-freeze.test.ts (8) — heldSet correctness, a twice-failed row excluded from the plan, the other rows still workable (the actual regression), order of the rest unchanged, terminal rows never held, and the watcher's no-halt/notify-once behaviour. 2 fail pre-fix, 8 pass post-fix. With C98 held right now, the plan went from frozen to 6 workable rows (C68, C80, C94, C101, C103, C104). Full suite 2517/0.
• Also fixed on the way: my AGENTS.md DB note introduced a bare test-suite command that the --smol guard correctly rejected (the guard did its job).
• C98 itself is still unproven and stays held for the owner — see the report. It is now waiting as ONE row, not stopping the other 28.

305. Held rows hand off to the interactive session; a stale failure is not a hold (owner, 2026-09-27)

• Owner: "Can the watcher not prompt you (this session) to do held rows by hand?" — There is no channel that pushes a prompt into an interactive TUI session, so a watcher cannot literally wake this session. The useful version of the request is a self-contained hand-off, which is what now exists.
• queue-next.ts --hold-brief (also run by --sync) writes docs/HELD.md + .queue-held.json: for every held row, its own wording, its acceptance checks, its target files, its commits and — the part that matters — the verifier's own failure evidence (its most recent reopen notes verbatim). The new **/held command** drives it: open the page (correction 1 capability), check the database (live-check.ts`), then either close the row as already-correct or fix it here; only a judgement the owner must make stays held, stated in one line. Acting on a held row is now one word, with no re-investigation.
• A stale failure is not a hold (the C98 class). The hold rule counted LIFETIME reopens, so C98 sat held for ~13 hours even though its own later reopen said "Live check … 200, no page errors. The reopen bug IS fixed" and commit bb80725 had already re-worked it. New staleFailures() uses git as the evidence: a row with ≥2 reopens that has a commit naming it dated on/after its latest reopen is no longer held — it is routed to verify, i.e. independent re-proof, which is what it actually needed. The rule lives in buildQueue so every view agrees (--list, --next, --workstreams, the board, the ledger).
• Today this cleared C98 and C68 (and 4 terminal rows), so needs owner: no — the line is working the whole board again with nothing parked.
• Proof: tests/c132-held-row-no-freeze.test.ts 9 → 12 (stale-vs-hold, one-reopen never held, verify routing, the brief's completeness, the /held command). Full suite 2521/0.

306. The workaround: a stuck-row supervisor that never needs the owner (owner, 2026-09-27)

• Owner: "Can you do a work around? Wherein you watch the queue when something is stuck and take that up. Not involving me?" — A watcher cannot push a prompt into an interactive session (no such channel), but the capability is now entirely in the repo, so it does not need this conversation: open the page (tests/helpers/page.ts), check the database (scripts/live-check.ts), fix or close. That procedure became an agent.
• Detection (mechanical, no guessing). stuckRows() reports only rows with evidence of being stuck: explicitly held, or claimed doing with no commit naming it for 45 min (a worker died mid-row). A row being worked right now is never flagged (that mistake would double-book live work), verify rows are not "stalled", stale failures are excluded, terminal rows never qualify.
• The supervisor (.opencode/agent/unblocker.md, run by scripts/unblock.sh) takes one row with a self-contained brief — the owner's own wording, its acceptance, its targets, and the verifier's last failure note — and settles it by opening the page. Already correct → closed as verified with the evidence recorded. Genuinely broken → fixed, tested, deployed, live-checked, then closed. A judgement only the owner can make → it does not guess: it appends one line to docs/HELD.md and moves on.
• Rails: one row at a time; the attempt is recorded before dispatch (so a crash still burns a try) and a row over QUEUE_UNBLOCK_MAX_TRIES (default 2) is never handed out again; it never starts while another agent works; it may not push, re-point git, weaken a gate, or touch the owner's docs/CORRECTIONS.md. The watcher runs unblock.sh once every 15 ticks by default (QUEUE_UNBLOCK=0 disables).
• Proven live, with no involvement from the owner. It picked C100 (claimed doing, no commit for 45 min), opened the page, found a real product ambiguity — C100 says "land after C99", and C99 is not built — and escalated in one line: "C100 needs an owner decision: build the one-field-per-popup split now, or wait for the payment-dhara change first." C100 is now blocked-owner (waiting alone; the other 6 rows keep building), and the attempt is logged so it cannot churn.
• Proof: tests/c133-stuck-supervisor.test.ts (15) — including an end-to-end check that the detector and the script report the SAME stuck rows, so the supervisor can never act on a different picture than the owner sees. Full suite 2539/0.

307. Policy: ask in a batch, but GUESS intelligently — never park a row (owner, 2026-09-27)

• Owner: "But why does it or any worker not guess. Let them take intelligent guesses for things. While queuing you ask me all the questions necessary. Even if after that there are a few things, let them take a smart guess."

• This overrides the old runner rule ("if a row needs an owner decision, ask, do not guess") and the blanket no-guess rule in the verifier/unblocker briefs. New rule, in force everywhere:

  1. Ask in a batch. Ambiguities are recorded as questions (docs/QUESTIONS.md + docs/HELD.md) and surfaced together, so the owner answers them in one pass rather than one interruption at a time.
  2. Never park on an ambiguity. A question is not a stop: the agent states the most reasonable reading, records it as the row's assumption (auditable, revisable), and finishes the row.
  3. A narrow hard-stop list survives, because some guesses are not recoverable: deleting or overwriting data, money/GST/costing maths, anything contradicting a row's explicit MUST NOT, deploying to production, or a choice between two readings that would change what a customer is charged or promised. Those still ask — and are asked in the same batch, not silently.
  4. An assumption is a first-class note: the board shows "assumed: …" with the pending question beside it, so a wrong guess is visible and correctable rather than buried.

• Why this is right for this board: parking is what froze the line for 13 hours, and a held row is invisible progress. A documented, reversible guess that ships behind a gate plus an independent verifier is strictly better than a row that never moves — and if the guess is wrong, the reopen path already exists.

• Concretely, C100 (which the supervisor escalated one minute earlier) is the first test of the new rule: its wording says "land after C99", and C99 is not built. The smart reading is to build C100's one-field-per-popup split now and leave the payment field for C99 to own — not to park the row.

• Follow-up (same day, owner): "The board still showing c100 question" — a question only closed on - A<n> (an answer), so a row that proceeded on an assumption was advertised as "waiting for your answer" forever. Fixed in two places: - R<n> (resolved by assumption) now closes a question in parseQuestions, and a card shows a question only while it is held (the mapped column key blocked) — a building row shows its assumption instead. The supervisor is now required to write the - R<n> line itself, so the feed cannot drift stale again. Q1 (C100) closed this way. Suite 2552/0.

308. C98 reopen: the UNSCOPED contact picker is combined, a SCOPED one is not (2026-09-27)

• One picker, two scopes. The wizard's own "Who's this for?" step is unscoped and must show parties and brokers in one search (brokers are category = 'Broker' rows of the same party master; picking one sets brokerId + initiator = 'broker', a party sets partyId + initiator = 'party'). The summary form's Party/Broker rows open the same picker scoped to their own field, so a quote can carry both and the other keeps its value.

• The rule that keeps both true: filter on scope, never on "is a scope set" collapsed to one kind. contactScope === '' used to fall through the ternary to 'Party', which silently made the combined step party-only. Scope kinds now come from one pure helper (contactPickerKinds / contactPickerRows) so the behaviour is unit-testable, and only contact masters (Party/Broker) are ever listed — a Sizing house or an OwnUnit is not a contact.

• Lesson carried to the verifier contract: a test that asserts the buggy line as source text is a gate that certifies the bug. C98's file passed 13/13 three rounds running while the page was party-only.

• No-op bookkeeping, made honest (owner: "Sort the noop issue", 06:43). Measured first: there was no live no-op loop — the three no-ops in the whole log were from 04:45–04:59, before the retire fix; what remained was residue. Lanes keep status and .swarm-noop markers from their last run, so ws2/ws3 were still advertising 04:45 verdicts at 06:43 and read like the exact fault just fixed. Lanes are now cleared once per round (cmd_run), and every run writes fresh ones. Separately, a repeated no-op is now counted per row in .swarm-noops (one root ledger, because the same row can noop in different lanes), logged as a WARNING on the second occurrence, and the count travels into the row's notes so the verifier sees the history. A row and the code disagreeing is a fact the verifier must judge, not something to retry silently. Suite 2580/0.

309. Swarm pinned serial after the 2026-09-27 OOM (2026-09-27)

• Measured: opencode.service consumed 5h21m CPU with a 5.6G memory peak on the 6G / 2-vCPU VPS (sar 07:40: 97.9% mem, load 40), OOM-killed 07:24, box rebooted 08:21. Pareto: opencode alone was ~84% of all CPU; the rest was swarm-driven builds/gates.
• Fix in scripts/swarm.sh: SWARM_MAX default 2 → 1, and record_gate no longer scales to MAX+1 on green gates (never above MAX). .swarm-workers clamped to 1 0 0. opencode.service also capped (MemoryHigh=2G, MemoryMax=3G, CPUQuota=200%) so systemd restarts it before host OOM.
• Not done: opencode.db vacuum — freelist_count 0, zero reclaimable. opencode.log rotated (12M).
• Regression: tests/c136-swarm-serial-cap.test.ts pins the default and the no-scale-above-MAX rule.

310. Survival pass: the gates were never the cost — CONTEXT re-read was (2026-09-27)

Owner: "it seems to be inflated wherein a single small task is killing the cpu. something is an overkill... if we were to start over how do we do it which balances speed with cost." Then, on being shown the evidence: "all this is build by you... i am non technical. do not know coding."

Measured, from the agent session store (/root/.local/share/opencode/opencode.db):

The gates were never the problem. Measured on this host: full suite 54 s wall / 10 s CPU (2,614 tests, 203 files); check 7 s; build 15 s. One round's deterministic work is ~2 min of CPU on 2 cores. The C118–C128 work (heavy.sh, --smol, serial builds, measured worker cap) all landed and worked — and none of it touched the layer that cost 420 M tokens.

The real leak: unwrapped gate output enters agent context and is re-sent every later turn. bun run build prints 5,120 lines, bun run check 2,047 — almost all the same pre-existing svelte a11y/state warnings, once per route. One build inside a 100-turn session is therefore ~5 M tokens of pure re-reading.

Two corrections to the earlier read, recorded so the record is honest:

1. worker.md does not mandate reading QUEUE.md/CORRECTIONS*.md (26 k tokens) — line 16 says the worker must not touch them. The brief is the source of truth and is already small (817–1,913 tokens).
2. The 213 M-token session ("Swarm max for builders") was one exploratory session, not a recurring pipeline stage. Steady state is 79 worker sessions ≈ 207 M. So the win is the per-turn and per-session cost, not "delete an orchestrator".

Changes (all small, all reversible):

• scripts/quiet.sh — run a command, keep the exit code and the error lines, drop the rest. 5,120 → 31 lines (build), 2,047 → 31 (check). Verified: exit code identical on pass AND on failure, and the real error is still shown. It changes what is DISPLAYED, never what is RUN or what PASSES.
• AGENTS.md + worker.md + the rendered .swarm-brief.md — wrap check/ build in quiet.sh; never read PLANNING.md (~93 k tokens) or BUILD-LOG.md (~25 k) whole, grep them; take a whole feature area's rows per session.
• reap_stray_dev_servers() in swarm.sh — kills orphaned vite dev servers on round start. Measured: two were holding 1.07 GB of 6 GB with swap at 507/512 MB, left by an agent that started a dev server to look at a page and never stopped it. That is the "one small task kills the CPU" symptom.
• Budget billed on shipped work, not attempts (queue-watch.sh + .swarm-ships). Measured: 05:32–05:37 started six rounds in six minutes, every one logged "another swarm run is active — skipping", shipped nothing, and every one still consumed a slot (13/18 → 18/18).

The reaper's danger is real, and was hit for real: cleaning up during this work, pkill -9 -x bun killed the production server, because the live app is bun run build/index.js and also has ppid 1. Restarted in under a minute, no data impact. Hence the reaper excludes *build/index.js* before any other check, only reaps ppid 1, and kills by explicit PID (never pkill -f).

Latent bug found and fixed: .gitignore had /.swarm-lock (hyphen) for a file that is actually .swarm.lock. Untracked + unignored ⇒ git status dirty ⇒ swarm.sh refuses to run (refusing: working tree not clean). It would have blocked every round.

Deliberately NOT done: no shared-agent-server / --attach (it has 0 successful attaches ever, and with SWARM_MAX=1 there is no concurrency to amortise — so the win is ~0 and the risk is a new untested service); no PLANNING split (a 370 KB refactor is not a survival action — the grep rule gets the benefit for one line); no change to any business rule, gate, or the queue's append-only model.

Regression: tests/c135-board-immortal-rows.test.ts +6 tests (reaper excludes the live site, reaps only orphans, never pkill -f, runs after the flock; budget billed only when the ship count grew; .swarm-ships ignored). Mutation-checked: deleting the build/index.js exclusion turns the suite red.

311. The build was the hog, and a reused session needs a fence (2026-09-27)

Owner, after §310: "is the checks and built ...huge number of it still relevant? Do they suck on compute unnecessary?" and then the sharpest question of the day: "if a single session will be reused, won't the large context be a problem?"

Correction to §310's "the gates were never the problem." That was measured on a build that FAILED and aborted at 15 s. A successful build on this host:

The build burns 6.4x the CPU of the entire 2,620-test suite, and it ran once per workstream AND again inside deploy.sh — every row paid to build the same 4,181 modules twice. The suite is not the waste: of 206 test files only 18 touch the database, and 2,620 tests for 9.5 s of CPU is how cross-cutting damage is caught at all. It stays, once per ship.

Build removed from the workstream gate. Blast radius is unchanged: ship_ready merges every ready workstream and then deploy.sh builds, and a build failure already reverts the whole merge via safe_reset. It is now found at deploy time rather than worktree time — and deploy.sh builds BEFORE systemctl restart, so a break aborts with no restart and no downtime.

On reusing one session — the owner is right, and I was wrong to propose it unfenced. The single most expensive thing ever run here was ONE session of 1,011 turns / 213 M tokens. So the shape is: reuse the session (stop paying ~850 MB process start-up + a fresh context read per row) but BOUND it. SWARM_STEP_BUDGET=40, stated in the brief and in worker.md, and — the part that makes it a rule rather than a hope — measured after every worker from the session store, logging step budget ok / EXCEEDED. Measured past workers ran 168 and 97 steps, so the fence would have fired on both. Purely observational: any failure to read the store returns 0 and can never fail a round.

Deliberately not done: no shared-agent-server / --attach (0 successful attaches ever; with SWARM_MAX=1 there is no concurrency to amortise, so the win is ~0 against the risk of a new untested service); no PLANNING split; no change to any business rule, gate, or the append-only model.

Regression: tests/c137-cost-control.test.ts (+11) — worktree gate builds nothing, the deploy still builds, the budget is in the brief AND measured, the suite and integration typecheck still run. tests/c119 and tests/c120 updated to check INTENT rather than the old literal wording (both rules preserved and strengthened, not weakened). Mutation-checked: restoring the build to the gate and removing the measurement call both turn the suite red.

312. C99 finished: payment terms as ONE input, and check does not catch a redeclaration (2026-09-27)

C99 was shelved on stash@{0} during the §310 survival pass. Restored, and the cause of "does not build" is now understood exactly.

What was actually broken — three faults, not one. The row was described as having "a duplicate paymentDays declaration around line 132", and it did (RolldownError: Identifier 'paymentDays' has already been declared), but that was only the fault the compiler reached first. Reading the diff shows the real story: the author had deleted let cdPct = $state(''), kept the old let paymentDays, and then pasted a second paymentDays into the new C99 block. The duplicate hid two silent faults behind it:

• cdPct = ''; in the clear-form function — an assignment to a deleted variable. In a Svelte instance script this does not throw; it silently creates a phantom global, so it would have shipped.
• two dead string keys — 'cdPct' in the PREFILLABLE set and row('terms', 'Cash discount', 'cdPct') in the review summary — neither is a type error, both would have rendered an empty "Cash discount" row in the review sheet forever.

All three are fixed. The owner-facing shape of the form is unchanged from the signed design: one tappable Payment dhara row, then its slab coins, one combined "4% – 15 days" field; delivery fields (dueDays, promisedDays, brokerage, pass-on) untouched, per the row's stated safe assumption.

The finding worth keeping: bun run check is green on code that bun run build rejects. AGENTS.md says the gates are "bun run check + suite green", and §310/§311 measured the build as the expensive gate (61 s CPU vs 9.5 s for the whole suite) — so the obvious cost move is to stop paying for it per row. But a redeclaration inside a .svelte file is invisible to svelte-check and fatal to the Svelte compiler: check exited 0 with 291 warnings on exactly the file that could not compile. Any cheap-gate plan that drops the build must keep the build for the row that changes a .svelte script's top-level bindings, or it will ship dead form resets and empty review rows. This is also the honest caveat on §310's "the gates were never the cost": they were cheap because they were being run on rows that had already been edited, and the one gate that would have caught this row was the one being skipped.

Board note: the work is done and the row is still status: pending. docs/QUEUE.md is runner-owned and forbids hand-editing a status to done — the verifier agent does that on proof, and the watcher is disarmed, so nothing has marked it. Left for the owner's call rather than faked.

313. The gates are not the cost — the SHIP GATE was, and two defects each ate a whole round (2026-09-27)

Owner, after the §310–312 measurements: "make this system fine so that we can actually build the ERP this week." Two builder batches were run to get a real number. Both shipped zero rows, for two different reasons, and both reasons were defects rather than bad luck.

The measurement (the number actually asked for)

So the cost work is working: ~5.5× cheaper per row, and "many rows per session" is visibly landing (one session did C100+C102+C112). The honest caveat stands: this is the cost of work produced, not rows delivered — the row is still 0 until the blockers below are cleared.

The load-bearing fact is 98.5%. Every token of that is context re-read: the agent re-sends its whole accumulated conversation on each turn. quiet.sh stopped build output from polluting context; it cannot touch this. And note the trap in the obvious next fix: reusing one session across many rows makes this worse, not better — row N carries rows 1..N-1. "One long session per feature area" is right for orchestration and wrong for context growth; it needs a reset between rows, which is a design item for the queue rewrite, not something to assume.

Defect A — deploy.sh silently discarded conflict resolution

git pull --rebase drops merge commits and replays only the side commits, so a conflict resolution living in the merge is lost. Reproduced in a scratch repo: a resolved file reverted to its base under plain rebase, and survived --rebase-merges. In production this turned a repaired test file back into its broken pre-merge state, so the deploy failed on failures that were already fixed locally, and the 20-minute worker round that built the work was lost. Fixed: pull --rebase --rebase-merges --autostash. This is the worst class of bug in this repo — it destroys work and reports success.

Defect B — the cheap gates pass on code the build rejects

Now measured twice, and this is the generalisable finding:

svelte-check does not parse blocks or redeclarations the way the compiler does. The build only runs at the ship gate, so every template typo costs a whole round: the worker passes its own gate, the ship build goes red, the round is reverted. That is exactly what a stray {/if} in the batch's OrderEntryForm did — 20 minutes and 14.3M tokens for one brace.

The fix is cheap and does not re-introduce the expensive build (tests/c137 removed the per-workstream build on purpose, 61 s CPU): scripts/svelte-syntax.ts runs the same compiler over only the changed .svelte files — 1.4 s on 6 files, wired into the worktree gate ahead of the row tests. Verified both ways: check exits 0 on the injected bug, svelte-syntax exits 1.

The honest lesson, and what it costs to admit

Both of today's rounds were lost to defects that a gate should have caught. The first (Defect B, §312) I fixed and pushed after check + a targeted test without running the full suite — and a pre-existing test was asserting the buggy line verbatim, so my correct fix turned the suite red and reverted 20 minutes of work. A test named for a bug that asserts the bug is worse than no test: it launders the defect. tests/c137 was that test; its assertion is now correct.

The rule this earns: a .svelte change is not verified until bun run build is green, and no fix ships on check + a targeted test alone. With svelte-syntax.ts in the worker gate the round no longer pays 61 s of CPU to learn this, but the ship still builds, and it should.

Sustainability, for the ERP phase (owner's ask)

The board is nearly drained — 22 done, 4 verify, 4 pending (C113, C114, plus C71/C80/C103/C104 in verification). At that size the builder no longer pays for itself: a round costs ~4.2M tokens/row and the orchestration is the majority of the spend. Recommendation, unchanged from the earlier advice and now with evidence: finish the last rows in-session (as C99 and the ws1 merge were done), and spend the queue rewrite on the ERP work rather than on 4 rows. The rewrite's design must start from the measurement, not from the original plan: context reset between rows, the cheap template gate, and a ship gate that keeps the build because the cheap gates provably cannot see what it sees.

314. Why the re-read is 98.5%: context grows ~940 tokens a turn and nothing prunes it (2026-09-27)

Owner: "what about the high reread token usage?" Measured on the 12:07 batch's ws1 worker (12,458,855 tokens, 3 rows — the best result so far) instead of guessed, and the guess would have been wrong.

The instruction files are not the problem. worker.md ~1.2k, AGENTS.md ~2.7k, the generated brief ~1.1k — about 5k tokens, re-sent 143 times is 1.28M, i.e. 10% of the 12.3M. Trimming them (the obvious first move, and the one §310's "grep don't read" already half-did) cannot reach this number.

The cost is turns × context size. Context grows ~940 tokens per turn and is re-sent whole every turn: assistant prose, reasoning blocks and tool results all accumulate and nothing ever resets. 142 turns for 3 rows is ~47/row, against the 40-step budget in worker.md — the fence exists and was not enforced.

The lever was shipped switched off. opencode documents compaction: { auto, prune, reserved }; auto defaults true but never fires because a 142k context does not fill a modern window, and prune — "remove old tool outputs to save tokens" — defaults to false. So this repo was paying, in full, for every tool result and every reasoning block, forever. opencode.json now sets prune: true (model and provider pin untouched). tests/c140-context-cost.test.ts fails if it is ever dropped — mutation-checked both ways (prune: false ⇒ 1 fail, block removed ⇒ 3 fail).

What this does and does not prove. prune is the documented mechanism and it targets exactly the measured cause, but it is not yet measured end to end — that needs one more batch to re-run, and the honest expectation is a large fall with the same work. Do not book the saving until a run shows it.

Consequence for the queue rebuild. "One long session per feature area" is the right shape for orchestration and the wrong shape for context: row N carries rows 1..N-1, so cost per row rises along the batch. With prune on that growth is bounded rather than linear, which is what makes session-per-area defensible at all. The rebuild should therefore be specified as: prune on, the 40-step budget enforced not merely stated, and a measured re-run before any saving is claimed.

315. The screen check now opens all 75 screens, on real records (2026-09-27)

Owner: "scripts/live-check.ts already derives routes from the filesystem, but caps at MAX_PAGES=24 and skips dynamic routes (those with [id] in the path). There are 75 real pages. Make it check all 75, looking up a real id for the dynamic ones, runnable on demand, with a plain pass/fail list. Replaces per-row agent verification at zero token cost."

The defect, measured

The list was capped at 24 and stepped over every route with an [id] in it, so 51 of the 75 real screens were never opened by anything, on any deploy. They are not the obscure ones: every "open this order / this beam / this lot / this statement" page is one of them, and that is exactly where a missing join, a renamed column or a dropped table bites a real person. C96/C97 shipped green with a whole table missing from the live database (§313) precisely because nobody opened the screen.

What the check does now

• Nothing capped, nothing skipped — the filesystem walk lists all 75.
• A dynamic screen is opened on a real record, and the record is found by reading the route's own loader (eq(beam.id, params.id) ⇒ a beam id), then mapping the name through the app's schema (order as orders ⇒ the order table, via getTableName). A new dynamic route therefore needs no entry anywhere, and one the derivation cannot read is reported loudly (NO ID SOURCE) instead of being quietly left unchecked.
• Three screens are not "a record of a table" and are derived from what they really serve: /docs/<slug> from a real docs/*.md, /board/<slug> from a real dashboard card, and /c/<entity>/<id> from a real gatepass or statement.
• A door is followed, a session failure is not. /orders/new forwards to /orders/new/trading (C102) and is judged on where it lands — but a redirect to the sign-in page is a FAIL, because "it redirected" must never be mistaken for "it opened".
• A state rule is stated, not worked around. A job-work statement's print is locked until the owner approves it (hishob/[id]/print, the only 403 in the app); the check opens an approved statement, and only if there is none does it report "nothing to open" instead of a broken screen on every deploy.
• SKIP is a real third answer (nothing in the database to open) and never counts as a pass; FAIL still fails the run and still blocks a deploy.

Measured on this host: 75/75 open, 80/80 checks, 4.3 s, zero tokens. Owner-runnable at any time — bun run screens, or bun run screens -- --only orders for one row's screens. It runs on every deploy as before; the cost went from 24 requests to 75.

The proof it can fail (tests/c141, mutation-checked both ways)

A stub site is served in-process that answers 200 for everything except one chosen screen, which throws 500. The check must exit 1, name that screen and print THE PAGE IS THROWING. Injecting const ok = true ⇒ 1 fail; restoring the old e.startsWith('[') skip ⇒ 4 fail. The test also proves no screen is dropped (75 on disk = 75 opened) and that no token is spent: nothing in it starts a model.

Consequence for the board. Per-row "verify" no longer needs an agent to open pages: bun run screens -- --only <path> is the row's own proof, free, and it is now the first thing a verifier should reach for. Suite 2722 pass / 0 fail.

316. A state factory is now EXECUTED in tests, so a "the screen shows X" claim can be closed (2026-09-27)

Board: C71 (quote preview Edit) was the first row to sit in verify with a reopen that named a value, not a marker: "Edit opens the WRONG/BLANK record — summary rows read Quality '—', Party ' —'". The shipped fix (ce417ec, carried quote outranks the session draft) was pinned by a test that greps source text (expect(wizState).toContain(...)) — which, by the verifier's own rule, proves only that someone wrote the line. So the row could not be closed honestly, and the same is true of every other row whose claim is behaviour.

The gap, stated

bun test can import a *.svelte.ts module but does not compile it: $state is an undefined global. Every claim about a screen's behaviour has therefore been pinned in source text, and text pins are exactly what the verifier was told not to accept (C94/C96/C97/C104 all shipped on a text pin and came back reopened).

What changed

tests/helpers/runes.ts runs the real thing in the same order vite does: esbuild strips the types (runes are ordinary identifiers, they pass through), svelte/compiler's compileModule compiles the runes, and the output is imported from node_modules/.cache so bare specifiers still resolve. $app/* and #lib/feedback.js are pointed at generated stubs; every other import is pointed at the real file, so the case exercises the code the app runs. The factory is called inside Svelte's own effect_root and flushed — so the once-only snaps (draft restore, wizard landing screen) have happened before a case reads a value, and destroy() tears the root down so a late async effect cannot leak into the next test file.

A DOM stub is deliberately small: sessionStorage, element class lists, resize listeners — and dom.errors records anything it could not answer, so a stub gap fails a case instead of quietly reading undefined.

C71 closed on evidence, both halves

• Executed (tests/c71-quote-preview-edit.test.ts, 6 new cases): with a stale draft in sessionStorage, /quote/new?quoteId= shows the carried quote's quality/party/design/qty/rate and lands on the summary; a second Edit shows the second quote (repro B); the other entry's draft is left untouched; ?fresh=1 still starts blank. A control case pins that the draft is the entry when no quote is carried, so "the draft was dropped" can never pass as a fix. Mutation-checked both ways: restoring the pre-fix draftAppliesToEntry ⇒ 4 fail; removing the summary snap ⇒ 2 fail (the text pins alone catch neither).
• Live (the running app, real session, real records): three quotes opened at /quote/new?quoteId= — all HTTP 200, banner + quality + party match the database row, two quotes sharing a quality show different parties, and the wizard is not on screen (summary). /orders/new?quoteId= for two quotes: 200, carrying that quote's party and quality. /quote carries no /quote/edit?quoteId= link. bun run screens: 75/75, 80/80.
• Suite 2728 pass / 0 fail / 0 errors, check clean.

Rule for the rest of the board: a verify row whose claim is a value gets an executed case on the real factory (or a real HTTP/browser read of the running app) before it can close. A text pin alone is not evidence and never was. The other three verify rows (C80, C103, C104) are next; tests/helpers/runes.ts is the tool for all three.

317. C80 verified — and the customer's WhatsApp message said Quote Ref: draft (2026-09-27)

C80 (quote share) sat in verify with "reopen satisfied". Running the real surfaces over the real rows found three defects the format pins could not see, one of them customer-visible on a plain page open.

How it was checked (no browser on this host, so the code ran instead)

tests/helpers/share-surfaces.ts runs the three surfaces that exist — the quote list (quoteListUtils.waHref/shareTextOf), the edit screen (its compiled quoteEditState factory) and the wizard (its shareBase) — over the real loaders and real rows, in a child process against a VACUUM INTO snapshot. A child process because the list and edit loaders AUTO-EXPIRE stale quotes on read: a test that called them against data.db would have written to the live database. The snapshot is why this could be done honestly at all.

What was wrong

1. Quote Ref: draft. formShareText read form?.quoteNo ?? 'draft', and form is the last POST's echo — undefined on a plain open. The edit screen's Share button therefore sent the customer the literal word draft instead of the quote number. Now: the quote on screen (data.quoteCtx).
2. The edit screen lost its Quality line — and, worse, its quality field opened empty. The loader read ?quoteId= for every header field but computed designId before it read that row (q.get('designId') || matchedDesignId || requoteRow?.designId), so the opened quote's design was never preselected. ?reuse= always had; ?quoteId= never did. The executed factory showed designId === '' for a quote opened from the approvals screen. Fixed by reading the quote first and letting its design ride. (The served HTML cannot confirm it afterwards — the quality <select> is bind:value, so its selection exists only in the DOM — which is exactly why this needed an executed check rather than a page read.)
3. The same quote read two ways. The list formatted its dates; the edit form and the wizard passed the raw YYYY-MM-DD a form field holds, so the same quote reached WhatsApp as Valid till: 04 Oct 2026 from one screen and Valid till: 2026-10-04 from another. Dates are now printed once, in the one builder.
4. (found while checking, fixed in passing) the ?quoteId= prefill read estQty from inputs_json only — the SQL did not even select the est_qty column — so a seeded or migrated row reached the wizard, and its share message, with no quantity. The column is now the fallback (it is guarded by PRAGMA table_info, so a pre-migration database still reads).

The proof, and that it can fail

Nine new cases in tests/c80-quote-share.test.ts read the message each surface would actually send: greeting/terms/sign-off shape, no internal costing, no junk, no dangling separator, the wa.me prefill decoded and compared with the text, and one spelling of every date across all three. Mutation-checked one fix at a time: raw ISO dates ⇒ 3 fail · form?.quoteNo ?? 'draft' ⇒ 1 fail · dropping quoteRow?.designId ⇒ 1 fail · dropping the est_qty fallback ⇒ 1 fail. Live: /quote/edit?quoteId=… 200 with 20 wa.me prefills decoded on that page (chase texts, no costing), bun run screens 75/75. Suite 2738 pass / 0 fail.

Also worth the owner knowing: the quote list sends the chase text for any quote that is not approved (waHref branches on status) — by design, and the acceptance says "quote-list approved Share", but a glance at the list can look like the wrong text. 298 of 300 rows in the live database have no party on file, so most share links have no number to send to; that is master data, not code.

318. C103 verified live; the four production entries are real, role-filtered forms (2026-09-27)

C103 sat in verify with verify: - and the note "already satisfied" — the whole row was six source-text pins, so nothing had ever opened the screens.

Live, on the running app with real sessions and real orders: the Production nav group shows all four entries (Trading production · Job Work Commercial · Job Work Details · Production-Order production) to owner and production, and to nobody else — checker sees none, so the role filter is live and not decorative. Each entry opens 200 on a real record with its own heading: /production/ trading?orderId=e2e-so-1, /production/job-commercial?orderId=o-4, /production/job-details?orderId=o-4, /production/production-order?orderId=o-5. The job-work outsource contract block is on Commercial and Details and on neither of the other two. The order record page carries all four links. bun run screens 75/75.

Now in the suite (executed, not pinned): the four loadProductionForm calls run against the real database and each side is checked on the rows that come back — every row it offers is a kind it is allowed to offer, and the four sides between them claim every kind with OUTSOURCE claimed by exactly two (Commercial

• Details, never once). Mutation-checked: pointing Details at SO instead of OUTSOURCE ⇒ 3 fail.

One finding, deliberately not "fixed" (owner call, not a C103 failure): a ?orderId= naming an order that is already past the pending-ops condition opens the form blank — the form completes production entry for orders still missing it, and e2e-so-1 is in-prod. The order's links from the record page therefore land on a form that ignores them, silently. It is out of this row's acceptance (the entry does open its form), so it is recorded rather than changed: either the form should say "already complete, showing pending orders", or the record page should not offer the link. That is a queue row when the owner wants it.

319. C104 answered: /bookings/new was still shipping the old guided form under the new summary (2026-09-27)

The reopen (2026-09-25) was right, and it is worth writing down exactly how it was right, because the row's own test passed while every word of it was true.

What was live: /bookings/new rendered BookingSummary (read-only rows) + BookingWizard (one field at a time) and then, visibly, the entire old guided form — <form method="POST" action="?/create"> with no hidden, sections sec-yarn/sec-bags/sec-rate, Step 1 of 3 · Yarn + supplier, every input typed straight into it and a sticky Check & save bar. So the acceptance "every field entered via its popup" was false on the page a person opens, and the correction's own comparison (quote-new, leads/new, orders/new all carry class="hidden") was the tell.

Fixed the way the sibling screens do it. The POST form is now class="hidden" and carries the same fourteen field names with the same values — the transport for what the popups set, nothing more. The 264 lines of guided markup are gone, not hidden. Then the consequences of removing it, one at a time, because each one was a real affordance that had to land somewhere else:

• The error alert lived inside the form. It now sits under the page heading and lists every server error, not just the first.
• The review sheet's "tap a row to jump back and edit" scrolled to a section that no longer exists. Every review row now carries the wizard step of the field it names (FIELD_META[k].step), so it opens that field's popup.
• The three section cards open their group's first field instead of scrolling.
• The C14 "prefilled from procure / last booking" chip had its only call site in the deleted markup. It now hangs off the summary row that shows the value (src: srcFor(…)), and one tap still checks every field from that source — the fast path the old form's Confirm all from X button provided.
• Per-field keyboards, maxlength, datalists and error lines were all on the removed inputs. The wizard is the only place a field is edited now, so it carries them: inputmode/maxlength on every typed field, the supplier-list/lotno-list datalists again (fed from the full masters, not the four chips), the field's own text-xs text-error line, the warp sizing-multiple warning, and the rate board's provenance ("₹253 latest for …") above the rate chips.

The pin suite, honestly. 32 tests across 11 files described the removed markup, and a red suite blocks a deploy, so every one was re-read: the pin was re-pointed at the surface the behaviour moved to (tests/helpers/bookingSrc.ts plays the quoteSrc trick from C88 — the shell plus its components), or rewritten to assert the new equivalent ("the guided sections are gone and the real POST form is hidden", "one tap checks every field from a source"). Nothing was deleted to make a suite green: the two pins that lost their subject (the sticky bar, the per-input pre( badges) now assert what replaced them.

A second defect, found by the live check the reopen asked for. Hiding the form hid the error alert with it — and superValidate puts most messages under the field name, so the alert's _errors list was empty for exactly the rejections that happen. A bad save was silent, and enhanceGate closed the popup on failure, so the user was left on a summary that said nothing. The alert now renders on the summary, lists form-level and per-field messages under the field's own label, and a failed save keeps the popup open on the field the server rejected. Proven live by POSTing a bad booking: 400, and the page reads "Product: Selected product is not in the yarn master — pick it from the list". Mutation-checked both halves (alert back to _errors only ⇒ 1 fail; popup closes on failure again ⇒ 1 fail).

(One measurement worth keeping: a raw fetch POST without Accept: text/html gets SvelteKit's JSON action result, not the page — so a curl-based check of "is the error visible" reports a false failure. Send the header.)

Verified: check clean, suite 2744 pass / 0 fail, and the served page checked for the reopen's own markers (below). C104's mandate-12 complaint — a 1,038-line page — is answered in part (1,038 → 561 lines, dead guided machinery removed); the rest is state + prefill effects, which is where it belongs.

320. C95 needed no build — it needed proof (2026-09-27)

C95 (re-quote from the quote preview) sat on the board as pending with the note "round killed by owner before merge; nothing shipped". The code was in fact there and correct; what nobody had done was run it. The row's test is five source-text pins, so it proved nothing about behaviour.

Run for real (tests/helpers/requote-probe.ts, a child process on a VACUUM INTO snapshot because the save path writes): the real loader with ?quoteId=&requote=1, the real compiled state factory, and the real create action. All three acceptance checks, on a real quote (QT-260927-4EH7, quality 63"84/3*70/32*32-2/1-TWILL, party CHARBHUJA FABRICS):

• Prefilled, on the summary — isRequote, phase: summary, wizard shut, quality/party/design/quantity/4 warp + 4 weft rows all carried from that quote.
• Only rate + validity editable — asked to change the quality, the party and the yarn rows, the factory changed none of them and refused to reopen the wizard; selling and validity moved to 77.25 / 2027-03-31.
• A new distinct quote, source untouched — create returned a new QT-260927-5WV4 with the same design, party and quantity at the new rate, the quote count went 898 → 899, and every field of the source row (quote_no, status, final_rate, validity, est_qty, inputs_json) compared equal afterwards.
• No /quote/edit?reuse= from the preview, live and in the pins.

Mutation-checked both ways: isRequote forced off (the locks release) ⇒ 2 fail; the insert turned into an UPDATE of the source ⇒ 2 fail. Live: the re-quote URL returns 200 with the "Re-quote QT-…" banner and the "Only the final rate, validity + payment dhara can change" line, the wizard closed, and no /quote/edit?reuse= anywhere on the site. Suite 2749 pass / 0 fail.

One data note, not a code fault: a handful of quotes in the database point at a design_id that no longer exists (left by earlier test rows), so those quotes re-quote with a blank quality. Real quotes are unaffected; the probe deliberately picks a quote whose design exists, because a dangling id proves nothing about a customer-facing screen.

321. C110 built: /tippans/new is a summary + a one-field popup (2026-09-27)

The third entry form to leave the guided pattern, and the first one with no test file at all — the row was pending with "round killed before merge; nothing shipped", and nothing had ever been written about it. Same shape as the bookings conversion (§319), because the pattern is the pattern:

• src/lib/components/tippan/TippanSummary.svelte — the landing screen: four sections (Who & quality · Program · Yarn issue · Beams & notes) of read-only rows, "N required to fill", Clear + Check the tippan, and the C14 source chip on any prefilled value.
• src/lib/components/tippan/TippanWizard.svelte — the popup, and the part worth writing down: its 23 steps are DATA, not 23 hand-written blocks. A step says which field it edits and how (text / int / dec / date / type-ahead list / coins / solver locked), with get/set closing over the bindable props. So every field is one tap from its summary row, the component stays one screen long, and a new field is one array entry. The numbers carry inputmode + pattern + steppers + a NumberWheel; long masters type ahead; the beams step is the floor-beam picker; the solver's three answers share one step with Calculate on it, and editing one of them drops the "auto" flag (so its C14 chip and gate row go with it).
• The page keeps what belongs to it — the prefills (last program, gatepass, design, solver), the C14 confirm gate, the solver wiring, ?/assign, and the hidden POST form carrying all 25 field names. The solver, the record page, the print and the amend are untouched.
• Two gaps found while wiring, both closed: the page had no shell-header hide or body lock while a popup was open (bookings has it; the tippan page never did), and the server's fail(400, { error }) had nowhere to land once the inputs were hidden — the message is now mapped to the step that owns the field and shown there.

Live, on the running app: /tippans/new serves <form method="POST" action="?/create" class="hidden"> with all 25 names, sec-program/sec-yarn/sec-quality/"Step 1 of 3"/the sticky bar are gone, the summary rows render, the popup opens with its step counter, and the only non-hidden named inputs on the page are the two selects of the separate "Assign later" card. bun run screens 75/75, check clean, suite 2759 pass / 0 fail.

Pins, honestly: 26 tests across 11 files described the removed guided markup. Each was re-read and either re-pointed at the surface the behaviour moved to (tests/helpers/bookingSrc.ts → tippanEntrySrc(), the quoteSrc/C88 trick) or rewritten to assert the new equivalent. The pins that caught real gaps while being moved — the pattern/inputmode hints, the C14 chip gates, the datalist, the loom chip row, the quality master block — were satisfied by adding the capability to the popup, not by loosening the assertion.

323. Pre-round scoping for C113/C114 — read before building them (2026-09-28)

Recorded for the round, not worked by hand. C113 (drafts/OCR prefill) looks like a wiring job because its targets include /api/ocr and intake.ts. It is not.

Already there, and working (bun run screens passes): /capture has an OCR mode that saves the file under screenshots/capture and creates a draft (rawText + rawImage + intent + parsedJson); intake.ts already speaks the gateway (CAPTURE_LLM_URL/KEY/MODEL) and already builds an image_url data-URL message; /api/lead-understand + /api/order-understand are the precedents to copy.

Four gaps, one of which is a behaviour change a person may rely on:

1. PDF is accepted and silently yields nothing. The input says accept="image/*,application/pdf", the file is saved, and then tesseract is handed a PDF — which it cannot read — so the text comes back empty and the draft looks like a blank capture. This host has no PDF renderer: no pdftoppm, pdftocairo, convert, magick, gs. Rendering pages to images (which both C113 and C114 require) needs either a system package on the host or a new runtime dependency. Needs an owner decision — do not silently pick one.
2. The capture path is tesseract-only. The gateway image_url path exists in intake.ts but the upload never calls it.
3. /drafts auto-commits, which this row's own acceptance forbids. A draft with intent=order|sample|booking gets a button that posts to ?/createOrderFromDraft and writes the record. The acceptance says "routes to the correct form prefilled … nothing auto-committed", and capture-first is a domain rule. Those buttons become links that open the right form prefilled. This is a behaviour change on a working screen: flag it, do not slip it.
4. Six intents, three destinations, no picker. The parser knows lead | quote | order | booking | gatepass | sample | unknown; only three are handled and nothing exists for unknown/low-confidence (the acceptance's form-picker drop-down). Each destination needs a documented prefill contract.

Order is not optional: C114's acceptance says it reuses the C113 OCR pipeline, so C114 cannot be built in parallel — it has nothing to reuse. Build C113 → C114, and the PDF decision lands in C113 and is inherited.

Standing gap in the mechanism, for the record: the round's verifier is a server-render check (HTTP + served HTML), not a browser, so a client-only defect is structurally invisible to it. Any row in this round whose acceptance mentions a value or an interaction needs an executed check on real data (tests/helpers/runes.ts and the real-surface probes make that possible) before anyone calls it verified.

324. OCR route decided: the LLM reads the image, tesseract is the fallback (owner, 2026-09-28)

Owner: "we are using DeepSeek api (llm directly) for ocr rather than tesseract. The api key is already there." Recorded so the round does not re-litigate it:

• Extraction order is now: gateway first, local tesseract as fallback — which is what C113/C114's acceptance already asked for. No local PDF renderer is to be installed for this.
• intake.ts already speaks the gateway (CAPTURE_LLM_URL/KEY/MODEL) and already builds an image_url data-URL message, so the capture path's job is to call it and keep tesseract behind it.

Two facts found while confirming, both of which change what "working" means:

1. The key is empty on this host. CAPTURE_LLM_URL=https://api.deepseek.com and CAPTURE_LLM_MODEL=deepseek-flash are set, but CAPTURE_LLM_KEY is zero-length in .env, in .env.bak-20260926-114446, and in the running app's own environment (/proc/<pid>/environ). So today the gateway path cannot succeed and tesseract is silently doing all the work. A worker that wires the gateway and reports "the LLM reads the image" has proved nothing until a key is present. Needs the real value in .env (gitignored) — and it must not be committed.
2. A PDF still has to become an image. The DeepSeek chat endpoint takes image parts, not PDF documents, so a PDF cannot be sent as-is however willing the gateway is. Without a local rasteriser the honest options are: accept the PDF, save it, and let the user enter the text (the file is kept for the draft, nothing is lost, and the row's "PDF → image" clause stays open), or add a client-side rasteriser (pdf.js) so the browser sends page images. Both are owner decisions. I could not test the gateway's actual PDF behaviour without a key, and I am not going to guess at it.

Consequence for this round: C113 and C114 are in doing in parallel (the planner filed them as two workstreams). §323 already recorded that C114 says it reuses C113's pipeline — so C114 has nothing to reuse yet and will either wait or end up duplicating the pipeline. Whoever merges second should re-point C114 at C113's helper rather than shipping a second copy.

325. The gateway answered both questions (2026-09-28)

The owner supplied the DeepSeek key (into .env, gitignored, never committed) and the app was restarted so it is live in the running process. Probed the gateway directly, three shapes, same key/model (deepseek-flash):

So both open questions are now settled with evidence rather than opinion:

1. The LLM reads images. C113/C114's "gateway first, tesseract fallback" is real and works today, for the image case. Nothing needs to change in intake.ts's message shape.
2. A PDF cannot go to this gateway as a document — it must be a raster image. That is the provider's rule, not ours, and no local renderer exists here. The choice is therefore the owner's: a system package on the host, a client-side rasteriser, or accept-and-save the PDF with manual entry (the file stays on the draft). Until then a PDF lands on the draft with the original attached and no text — which is the existing behaviour, so nothing regresses.

Security note worth keeping in the record: the key is now in this host's .env and in the running process's environment, and nowhere else. Anyone with read access to /root/trading/.env or /proc/<pid>/environ on this box can use it, so the key belongs to this host only — if it is shared, rotate it and put it in one place with restricted permissions.

326. C113 built: the OCR ingestion screen, the six forms, and one honest hop (2026-09-28)

The row's own wording, in the order it happens. /capture grows a fourth tab, Scan slip / PDF (photo or PDF), which posts the file to /api/capture-ocr and then does exactly one thing: offer a LINK.

The pipeline (src/lib/server/captureOcr.ts, pure node so the unit suite runs it for real): save the file under screenshots/capture first and keep it → a PDF's pages become images (system renderer if the host ever has one, else the page's embedded raster lifted straight out, §325) → read it with the dictation board's gateway, CAPTURE_LLM_URL/KEY/MODEL, deepseek-flash, the file as an image_url data URL exactly like /api/lead-understand → local tesseract (or a PDF's own text layer) only as the fallback when the gateway is unset, dead, or answers junk. It reuses C114's orderDocRead.ts rather than shipping a second copy of it; the only change there is saveDoc(bytes, ext, prefix), defaulting to order-ocr.

The intent is the intake parser's, over whatever text was read. The model's own intent only counts when the parser found nothing (it is the stricter reader), and a model that says it is unsure is believed: confidence < 0.5 is a picker, never a guess.

The hop (/drafts/open?draft=…[&form=…]) is the only place the six forms are named. The draft's intent picks the form unless the user picks one; the parsed values are re-resolved against the masters and handed over as each form's own query parameters, which that form validates (phantom id, junk number, "12 Feb" where the field wants YYYY-MM-DD → empty, never echoed). §303: prefillParams in captureRouting.ts is that contract, one map per form:

Only values the read actually produced are sent, so the rest of every form arrives blank for the user, and the order form's sourceDraftId NEED-HOOK (C113's target list) is finally wired — the SO carries its source draft and the read fields show a "draft" chip in the existing confirm gate.

Two behaviours worth naming, because both are visible:

1. /capture-img now serves the repo's screenshots/capture first and the legacy /home/fp/sites/trading/… path second. The old constant was the pre-cutover host path, which does not exist on this box, so a capture's file was being written outside the tree the app is served from. PDFs are served as application/pdf, so the draft's attachment reopens in the browser.
2. The OCR card is always in the document (CSS-hidden, never unmounted — the guided-form rule) so its file field survives a tab switch and a server-render check can see it. The three existing tabs are untouched.

/drafts: asked, not slipped (Q2/R2). The one-tap Create SO / sample / booking / lead buttons auto-commit a record from a draft, which is what this row's acceptance argues against — but they are pre-existing, owner-visible and gated by p4-commercial, so they STAY, with an Open the

09:51:58 merge swarm/ws1
09:51:58 MERGE CONFLICT on ws1 — leaving it; resolve manually
09:51:58 ship: nothing merged