T
Sign in

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

All docs GitHub source

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

FILE OWNERSHIP: written ONLY by scripts/queue-next.ts --ask and --answer (the runner asks; any session records your answer). Append-only — one line per question/answer, never edit or delete existing lines.

  • - Q<n> <date> <row> <question> — the runner asks instead of guessing, and answers it itself by the Pareto reading (rule 2, docs/OWNERSHIP.md). Asking never holds a row — the row keeps moving on the recorded call.
  • - A<n> <date> <answer> — your answer; the row is released back to the queue automatically.

A question with no matching answer is OPEN and appears on /queue (top banner + the row's "Needs your action" cell). While /queue is open, a new question also raises a browser alert if you granted permission.

Feed

  • (empty — questions appear here as the runner hits an ambiguity)
  • Q1 2026-09-27 C100 Build the one-field-per-popup split of the /orders/new sales wizard now, or wait for the payment-dhara change to land first? Your own wording says "land after C99", and C99 is not built yet, so the payment popup this row asks for does not exist: split it now and that popup can only hold today's "Buyer pays in (days)" box, which C99 then deletes and replaces with the dhara picker.
  • R1 2026-09-27 C100 resolved by assumption (PLANNING §307): proceeding on the reading recorded on the row — build the one-field-per-popup split now, leave the payment field to C99. No answer needed unless the owner disagrees; reopen C100 to change it.
  • Q2 2026-09-28 C113 On /drafts: should the one-tap 'Create SO / sample / booking / lead' buttons become links that open the form prefilled (the C113 reading of 'nothing auto-committed'), or stay as they are alongside the new prefill links? They are pre-existing, owner-visible behaviour with a test behind them (p4-commercial), so I did not remove them.
  • R2 2026-09-28 C113 resolved by assumption (PLANNING §307): keeping /drafts' one-tap Create buttons (a working, owner-visible screen with a test behind it) and adding the "Open the
    form filled in" link beside each, so the OCR path itself never commits. No answer needed unless the owner wants the buttons removed; reopen C113 to change it.
  • Q3 2026-09-30 C139 space-bunny-free is the free tier, so a busy capture hour can be rate-limited and reads then fall back to local OCR / typed entry. Should photo reads move to a paid model on the same gateway (same key, one setting change) so scanning never degrades? The row proceeds on the free-tier default meanwhile.
  • A3 2026-09-30 Owner 2026-09-30: use ONLY space-bunny-free (space-bunny). No paid model, one setting change never made. When space-bunny is not available (unset, unreachable, rate-limited, or the answer comes back empty), the read stops there and the user enters the order in by hand — the app must say so plainly and must never silently prefill from a weaker reader.
  • Q4 2026-09-30 C148 Two readings to confirm on the removal: (1) should the quote/lead carry stay working silently (form opens prefilled from a quote/lead and stores the reference, but the salesperson is no longer asked to pick one) — that is how the row reads it, because Reuse/Convert/dictation depend on it; (2) where should sales promise (promised days) and tolerance be asked now — production/ops completion (the row's reading, following C147), or nowhere at all? The row proceeds on both readings meanwhile.
  • A4 2026-09-30 Owner 2026-09-30: for the quote and lead, the TRADING SO keeps them; the PRODUCTION ORDER and JOB WORK SO do not need them (and the docs' per-form field list is the authority for what each form carries). Sales promise and tolerance are unchanged by this answer — the row keeps its reading that they are asked where production/ops completes the order (C147).
  • Q5 2026-09-30 C152 Delete is implemented as a RECORDED CANCELLATION appendage with owner approval (the signed rule says never overwrite or erase a committed document, so a true hard delete is not done). Is that right, or do you really want a hard delete that erases the row? Also: Edit opens the same order form prefilled from the saved order and saves as an appendage (before -> after per field + reason). The row proceeds on the appendage reading meanwhile.
  • A5 2026-09-30 Owner 2026-09-30: the UI may carry a DELETE button, gated on owner approval, but the DATABASE ONLY APPENDS — no record is ever deleted and everything has to stay in the system. So Delete writes a recorded cancellation appendage (the row remains, flagged cancelled/deleted, still listed and openable, with its full before/after history), and Edit writes a recorded before->after appendage. No hard delete anywhere.
  • Q6 2026-09-30 C163 When a field is NOT important (compulsory+no-default rule), where does the user change it? (a) it keeps its own single-field popup opened from the summary row, or (b) it stays inline on the page as it is today, or (c) it is not offered for change at all. I am taking (a): the one-at-a-time wizard holds only the important fields, and a non-important field still opens in its own small popup so nothing becomes un-editable. Also: does 'the wizard' mean only the one-field-at-a-time step sequence (my reading — the summary and popups stay), or the whole summary+popup screen?
  • Q7 2026-09-30 C163 Does a value that fills itself in count as 'a default value set'? Three common cases: (1) the system date, which is automatic and read-only — I treat it as a default, so no step; (2) a prefill the user must still confirm and can change, e.g. party carried from an enquiry or today's date prefilled — I currently treat it as STILL important, because the user has to confirm it; (3) a suggestion chip value like 'last used rate' that is only filled if tapped — I treat it as important. If you intended any prefill to drop the field out of the wizard, tell me which case and I will reword the rule.
  • A6 2026-09-30 C163 — confirmed (a). "The wizard" means ONLY the one-field-at-a-time step sequence; the read-only sectioned summary and the small single-field popups stay exactly as they are. A field that is not important (not compulsory, or a default fills it) is NOT a wizard step — its summary row still opens its own single-field popup so the user can change it, so nothing becomes un-editable.
  • Q8 2026-09-30 C164 If a pre-check finds a doubt and the question is still unanswered, does the row wait for your answer before a worker may start, or does it go to the worker on the written assumption (the existing rule that asking is not a stop)? I am taking: the pre-check RECORD is required, but an open question does not hold the row — it goes to the worker with the question and its assumption attached, and only the hard-stop list (deleting data, money or costing maths, breaking a MUST NOT, deploying to production, changing what a customer is charged) waits for you. If you want a genuine question to hold the row until you answer, say so and the builder will gate on it.
  • A7 2026-09-30 C163 — cases (1) system/automatic date, (2) a prefill the user must still confirm, and (3) a suggestion-chip value like 'last used rate' are all correct as stated (important / not important exactly as the question put them). Plus a fourth case the owner added 2026-09-30: a field the OWNER has instructed a standing default for — e.g. 'keep other cost as 5.5% by default in the quote form' — IS a default value set, so it needs no wizard step at all; where such a field currently has a wizard step, the rule means it comes out of the wizard (keeping its value and its own single-field popup so it stays changeable).
  • Q9 2026-09-30 C163 For a field that has an owner-instructed default (like other cost 5.5% in the quote form), does the new rule apply only from the next rollout onwards, or should the already-shipped forms be swept now to pull such fields out of their wizards? What I found while checking: in the quote form today Other exps 5.5% is NOT a wizard step — it is one of the ten rows inside the 'Adjust' popup, so that form already matches the rule; the tippan wizard's steps are all genuinely compulsory (sizer, weaver, quality). So a sweep may be a no-op. I am taking: the rule applies from the next rollout onwards (this row stays docs-only), and any specific shipped form you want a field pulled out of its wizard is its own small row so the shipped UI is not changed quietly.
  • Q10 2026-09-30 C165 Which document is 'the full flow doc' for this rule? I am taking src/static/full-flow.html — the exhaustive flow-by-form-by-field map, whose last column is 'ALL fields on the form — mode' and which your own audit crew (logged 2026-09-07) called the bible — as the per-form field checklist, with docs/YARN-FLOW.md (the prose flow: Trading SO, stock and sell, job work) read alongside it. If you meant a different document, tell me the name and the rule will point there instead.
  • Q11 2026-09-30 C165 If the full flow lists a field that the form has never had — so putting it on the form means a new column and a database change — do you want that added as part of the UI work, or as its own separate change afterwards? I am taking: the UI work only guarantees no field that already exists is lost, and every full-flow field is accounted for in the written list; a brand-new field needing its own database change is queued separately with its own migration, because the focus-entry work is UI-only and must not touch the database or the saved values. Say so if you want it added in the same go.
  • A8 2026-09-30 C164 — most things get an intelligent guess, taken in the checking session and written down, and the row keeps moving (asking is not a stop). Only when the checker genuinely cannot make a reasonable reading and needs the owner's approval does the row WAIT and is NOT sent to a worker. So: a pre-check record is required either way, but an open question is not itself a hold — the hold is a deliberate decision the checker makes when it cannot decide, not a side effect of the row's wording.
  • A9 2026-09-30 C163 — correct as assumed: the important-field rule applies from the next rollout onwards and this row stays docs-only; no shipped form's wizard is swept now. Any specific shipped form where the owner wants an owner-defaulted field pulled out of the wizard is its own small row, so a live UI is never changed quietly.
  • A10 2026-09-30 C165 — correct: the full flow doc is static/full-flow.html (at the repo root, served at /full-flow.html), the exhaustive flow-by-form-by-field map whose last column is 'ALL fields on the form — mode'; docs/YARN-FLOW.md (the prose flow) is read alongside it. (My question text said src/static/full-flow.html — the file is static/full-flow.html; the row already has the right path.)
  • A11 2026-09-30 C165 — add it in the same go. So when the full flow lists a field for a form and the form does not have it, the focus-entry work ADDS that field in the same change, with the database change it needs (the new column, its migration, and the server read/write of it) — it is not deferred to a later row. The field goes on with the mode the full flow lists (number pad, tap-select, text, suggestion, auto) and, where the flow says it is filled automatically or by default, that default is applied. Existing field names, existing validation and saved history stay exactly as they are.
  • Q12 2026-10-01 C154 C154 — the order form can now KEEP a contract PDF or photo with the order (per file: 'read it' for the form, or 'just attach'), and I opened both screens and they are right, but it is NOT on the live site: nothing can ship while the line's own checks are red, and the red is other work — the order-form focus-entry move now in flight (two order-form checks read markup that has already moved) plus two board/reaper checks. Do you want those checks brought back in line so the next release carries C154, or should C154 wait until the order-form work lands?
  • A12 2026-10-01 C154 waits for the order-form focus-entry work to land (C157); do not bring the checks forward for it. Worker moves on to the next row in the queue now. The two red order-form summary-row pins are stale reads of markup C151 already changed, so they are queued as their own row (C176) and fixed there, not inside C154.
  • Q13 2026-10-01 C178 Which control did you mean by 'queue beam slot starts decending from 999'? (a) the beam-quantity slot wheel on an order form - the 'Beams or metres' popup, 1 slot = 1 beam; (b) a numbered list/queue of beams stamped 999, 998, 997; or (c) a different wheel such as the rate wheel (0-999)?
  • A13 2026-10-01 Owner 2026-10-01: (a) — the beam-quantity slot wheel on an order form, the 'Beams or metres' popup where 1 slot = 1 beam. So the beam slots must read 1, 2, 3 ... upward, opening on slot 1 for a fresh order; the rate wheel (0-999) and every other wheel keep their ranges and their order.
  • Q14 2026-10-01 C175 C175 is built, live and verified — one thing only you can settle. The beam card's wizard has THREE steps (flange no, set no, cuts); contract, party and loom are summary rows you can tap into instead, because a floor-stock beam has no contract and the loom comes later. Is that the right split, or should the loom tap be a step too? And the C6b beam transfer stays a kept entry on the record (four fields, each opening a small popup) rather than a wizard of its own, as the correction described.
  • R4 2026-10-01 C175 resolved by assumption (PLANNING §307): the row ships as built — THREE wizard steps (flange no, set no, cuts), every other field (contract, party, loom, the mill lot, design, ends, total mtrs, warp/weft/weave) a changeable summary row with its own one-field popup, the flow's 【A】 fields (beam no, beam meter → woven → shrinkage → card mtr, status, rolls/pieces, kinari) read-only static rows with NO new column, and C6b a kept entry on the record rather than a wizard of its own. The step set is one line to change (WIZARD_IDS in src/lib/components/beam/BeamCardEntry.svelte) plus the PLANNING §336 C175 table; no answer needed unless the owner disagrees — reopen C175.
  • Q15 2026-10-02 C191 A beam going out to a REPAIRER has no row in the full flow (the beam rows are B0, B0b, C2, C3, C4, C6, C6b). Should it get its own flow row - and if so is it a gatepass, a movement (B5 covers returns from production), or part of C6b's reassign - or should the BEAM_REPAIR gatepass kind be removed?
  • Q16 2026-10-02 C192 A beam going back to its PARTY has no row in the full flow, but B5 movements already lists 'returns to party'. Should BEAM_RETURN fold into B5 movements, get its own flow row, or be removed as a gatepass kind?
  • Q17 2026-10-02 C193 The gatepass WINDING kind (yarn sizing -> winder) has no flow row of its own - C5 covers the winding in/out form on /winding. Is 'sizing -> winder' its own gatepass row in the flow, or part of C5's winding in/out?
  • Q18 2026-10-02 C180 Tapping a summary row that is not a wizard step should now open that field's own single-field box. I am doing this for every field you can actually type or choose. A few summary lines are deliberately not typable and I am leaving them as plain read-only lines: the System date (the server stamps it, so nobody can move it), Status (always reads 'open - auto'), the order kind itself, the Buyer's name on a production order (a stocking order has no buyer), the two Payment boxes on a job-work order (they are opened by their own Payment box, and the earlier correction C138 deliberately keeps them out), the Job-work brokerage % (also deliberate under C138), the attached slip file, and the draft link. Do you want any of THOSE to become editable in their own box, or is leaving them read-only right? Say which and each becomes its own small row.
  • A14 2026-10-02 Pareto call, no code change: keep the 3-step wizard (flange no, set no, cuts); loom stays a summary tap since the loom is not known at card-entry time and a forced step would block saving. C6b stays a kept entry. Reopen C175 if loom should become step 4.
  • A15 2026-10-02 Pareto call: keep BEAM_REPAIR as a B5 movement (beam out to repairer, back from repair); no new flow row, flow doc untouched. Removing a working kind would strand existing slips.
  • A16 2026-10-02 Pareto call: fold BEAM_RETURN into B5 returns-to-party; keep the kind, no new flow row.
  • A17 2026-10-02 Pareto call: WINDING stays part of C5 (the gatepass is C5's transport leg); no separate flow row.
  • A18 2026-10-02 Pareto call: leave all of them read-only for the reasons listed (server-stamped, auto, inapplicable, or deliberately excluded under C138). Any single one can become its own small row on request.
  • Q19 2026-10-02 C182 The MODE flag is asked in two places - the trading SO order form and the production operations 'trading' side popup. Taking it off the SO alone would leave the same question on the second form. Do you want it removed from BOTH, and does operations keep choosing it on the order RECORD page (where the value is recorded after the fact)?
  • A19 2026-10-02 Pareto call: BOTH entry faces go - the flag is literally the same question twice, and the row's own reading is that it decides nothing. The order RECORD page's operations completion KEEPS its mode control: that is where the value is recorded once it exists, it is not an order-entry question, and MUST NOT (nothing stored is cleared, the column keeps being written) forbids removing the control whose POST value is what populates it. If operations should never choose it either, that is a new row and it must land together with dropping put('mode', ...) on the record, never separately.
  • Q20 2026-10-02 C183 Which fabric master is the booking's fallback when the yarn master GST is blank and the booking has NO linked order (pending bucket)? The booking form picks a design only through the order.
  • A20 2026-10-02 No fabric, so the field stays blank — exactly today's behaviour (schema default 5 on save). The booking form's only route to a fabric is the linked order, so inventing one (last design, a setup default) would guess at money and touch nothing else. A booking later attached to an order can be corrected by the owner through an amendment.
  • Q21 2026-10-03 C198 Should the fix delete the cheap fingerprint entirely and evaluate the board on every POLL tick, instead of adding a HEAD term to it? And should the loop self-heal by force-touching a board file when it wakes, rather than relying on a detector at all?
  • A21 2026-10-03 Keep the detector and add the missing term. The fingerprint exists to stop this 2-vCPU/6 GB host re-reading the board every 10 s forever (C123 put the thermal ticks in this loop for exactly that host), so unconditional evaluation is a regression dressed as a fix. The correct reading of 'why did a completed row not wake the line' is that the detector was blind to the one thing a completed row always does - commit - so HEAD joins the four board docs, the reap tick stops swallowing the evaluation, and the stall alarm moves above the skip. No self-touch: touching a board file to wake one's own watcher makes the doc's mtime meaningless as a change signal and hides real drift. If the owner ever wants always-evaluate, that is the same three edits with the skip deleted.
  • Q22 2026-10-03 C185 with the save gate gone from the yarn booking, does the summary's '✓ ' chip stay tappable (marking the field as read, now that nothing waits on the mark), or does the chip become a plain source label with no tap? BookingSummary.svelte is a named target of this row.
  • A22 2026-10-03 The chip stays tappable and keeps marking the field read (confirmSrc writes okayed, never a value). Keeping it: existing behaviour, fewest files, trivially reversible; the mark still answers the owner's 'which of these did I look at?' and C184 pins that wiring on the summary's clear/save bar. BookingSummary.svelte therefore needed NO change - the row named it, the fix did not. If the owner wants a dead tap, that is a one-line follow-up row, not this one.
  • Q23 2026-10-03 C186 G0's confirmation evidence has no gatepass column of its own. Where does it persist?
  • Q24 2026-10-03 C186 FocusEntry calls onfile(id, file) but the page passed a one-arg handler, so the GP photo posted the field id as the file. Route by id as part of adding a second photo field?
  • A23 2026-10-03 Rides the creation event payload, read off raw FormData exactly as beamType (no zod change, no column, no migration). The record shows the GP photo in gatepass.image and the evidence beside it on the gatepass:YARN_IN creation event, which the detail page already reads for beamMtrs/beamEnds/beamQuality.
  • A24 2026-10-03 Yes — route by id. FocusEntry already passes (id, file); the handler ignored the id, so the existing GP-photo upload appended the string 'image' as the file. One handler, if (id === 'confirmPhoto') evidence else gpImage. Nothing else about the image field changes: same id, same state, same POST name, same column.
  • Q25 2026-10-03 C187 G0b's close-out has no home. Does it land on the DIRECT gatepass intimation form (this row), or on the inward screen, where the premises=inward leg lives?
  • Q26 2026-10-03 C187 The signed post-delivery GP counter-copy is a tap field 【T】 with no gatepass column. Add one new append-only POST name for it (read off raw FormData onto the creation event, as C186's confirmPhoto does), or carry it on a field that already posts?
  • A25 2026-10-03 Pareto call: on the DIRECT gatepass intimation form itself, DIRECT only, in its own after-delivery section beside the confirmation photo. G0b's close-out is named on the intimation row (the same row that carries count/bags/expected date), so the person who intimated it is the one who ticks the counter-copy signed when it comes back; C169's inward screen owns the premises=inward leg and is left untouched, so the two do not both claim it. Nothing in /inward or src/lib/components/inward/ changes.
  • A26 2026-10-03 Pareto call: one new append-only POST name, counterCopy, read off raw FormData and persisted on the creation event exactly as C186's confirmPhoto (no zod field, no column, no migration, so no server validation change). A value carried on an existing name would be stored under the wrong meaning and the tap would still vanish; the append-only list grows by one entry at the end, so no existing name moves or changes, and C186's pinned name list gains that one appended entry.
  • Q27 2026-10-03 C188 B0b's list names the taps, the actual date and the transporter — no consignee sizer — but a gatepass has to name a destination and B0 lists the sizer as B0's own field. Should 'To sizer' stay a required step on the beam-out gate tap, or is the tap meant to be strictly the three fields B0b writes?
  • A27 2026-10-03 KEEP 'To sizer' as the one required pick. A gatepass with no destination is not a document, and zod already refuses a record with neither source nor target party (schema.ts:139), so dropping the row would break creation, not simplify it. B0 lists the consignee sizer, so it is already known before the beams move — picking it at the gate is a one-tap reconfirmation, not the re-entry of a planner number, which is what this row removed. It stays a wizard step because it is compulsory and has no default; the four fields this row took off the tap (#beams, beam type, expected date, vehicle) all keep their POST names, zod fields and columns, so nothing stopped storing them.
  • Q28 2026-10-03 C189 With YARN_OUT's goods block gone, goodsSectionShown is false, so the 'From booking (expected delivery)' prefill row also disappears from the yarn-out form (it did the same for BEAM_OUT in C188). Keep that row on YARN_OUT with a caption trimmed to what it still fills, or let it go?
  • Q29 2026-10-03 C189 B5b's last clause is 'receiver confirms like a GP 【A】'. Does B5b need its own surface for that confirmation on this form, or is the shared static Status row already the answer?
  • A28 2026-10-03 Pareto: let it go, exactly as C188 let it go on BEAM_OUT. The booking picker fills party, count, ticket, mill lot, bags and cones/bag - i.e. precisely the six fields B5b never listed, so on this form it would fill nothing the user can see except the contract. It is also unreachable with a booking: ?bookingId= forces YARN_IN server-side (resolveKind), so an outward gatepass never arrives carrying one. No server change, no new field; the contract row (sourceOrderId) stays and is still pickable by hand.
  • A29 2026-10-03 Pareto: no new field. The receiver confirming like a GP is an act on the record, not a value typed at the gate, and the shared static Status row already carries it ('Entered - picked (partial/all) - delivered - confirmed - reconciled'). A separate confirmation field would store a second, competing meaning for one status, and G0's own confirmation PHOTO is C186's confirmPhoto on the inward leg, which this row leaves alone. So the only surface this row adds is the static row that names where the six removed fields went.
  • Q30 2026-10-03 C190 C3 step 1's quality field: PLANNING 336's C168 table lists it 【OCR→S】 (a suggestion/pick), but the widget is a free-text box with no option list, and the sibling C3 step-1 surface (/sizing, C173) already landed it as 【OCR/X】. Which code does the gatepass kind carry?
  • A30 2026-10-03 Answered by Pareto (C190): 【OCR/X】 — the badge must describe the widget the guard actually gets, and a free-text quality box has no suggestion list to offer; the same three values then carry the same codes on both C3 step-1 surfaces (/sizing and the BEAM_IN gatepass), which is what a second reader comparing the two screens needs. Mtrs stays 【OCR→N】 and ends plain 【OCR】 exactly as the C168 table lists them. If the owner wants a suggestion list on quality, that is a flow change first and a chips/options field after — not a badge.
  • Q31 2026-10-03 C190 BEAM_IN must keep the hishob out (the row's MUST NOT). The kind hint already says "full hishob later", which is prose only. Should the form also carry a static row naming C3 step 2 as the hishob's home, the way C188's B0b row and C189's B5b row name where the removed fields went?
  • A31 2026-10-03 Answered by Pareto (C190): yes — one static row, "Full hishob (not this gate tap)", naming C3 step 2. It is the pattern C188 and C189 already set on this same file for fields a kind does not ask, it adds no POST name, no column, no zod field and no yardage booking, it keeps the row's own MUST NOT true in the strongest available way (the screen itself says the hishob is elsewhere), and it is trivially reversible by deleting one object literal. Left alone: the hishob maths, the sizing receipt screen (C173's), every POST name and every stored value.
  • Q32 2026-10-03 C191 C191 The BEAM_REPAIR kind (?kind=BEAM_REPAIR — to repairer, beam taps, set no) has NO row in static/full-flow.html: the beam rows are B0 (out intimation), B0b (out taps), C2 (outward, guard taps), C3 (sizing receipt), C4 (out-house ledger) and C6/C6b (card + reassign), and none of them is 'a beam goes out to a repairer', so per C165 the form carries fields the flow does not list. Should a beam sent to a repairer be its own flow row — and if so is it a gatepass, a MOVEMENT (B5 covers yarn: returns from production, barcodes/kg/cones), or part of C6b's beam reassign — or should the kind be removed?
  • A32 2026-10-03 Pareto call: BEAM_REPAIR is its OWN flow row, and it is a GATEPASS — not a movement, not part of C6b. PLANNING §28 already settles it in the owner's own words: 'BEAM OUT FOR REPAIR: new beam movement via the gatepass system (intimation -> guard taps -> GP; return after repair)' — the gatepass system, i.e. a doc, not a B5 movement (B5's list is yarn stock: barcodes, kg, cones, reason codes, owner/contract flips) and not C6b (which is a CONTRACT/sizer reassign intimation, from contract to contract). So static/full-flow.html gains one row, C2b, drafted from what the form already asks, placed beside C2 (the other beam-outward leg) without renumbering anything; retiring the kind is not on the table — the row's MUST NOT says nothing is deleted while the question is open. Written into the map with the fields the form asks (repairer, beam/flange taps on the physical ids, set no, optional contract, vehicle + transport, gatepass photo, GP no/date, status ladder) and nothing else: no goods, no hishob, no yardage, no rate. The mirror leg (the beam coming back) is named as its OWN tap on this row's text without deciding C192's separate question.
  • Q33 2026-10-03 C192 should 'beam return to party' fold into B5 movements (where static/full-flow.html already lists 'returns to party'), get its own flow row, or be removed?
  • A33 2026-10-03 It folds into B5's 'returns to party' leg: the flow ALREADY lists that clause (static/full-flow.html:41) and PLANNING's own beam list calls it 'Beam returns to party / transfers (party-owned beams)', so a NEW flow row would duplicate C170's shipped movements row (C170 is DONE, not OPEN) and the kind is not retired — nothing may be deleted while the question is open. The kind stays a gatepass exactly as it is (no field, kind, POST name, action/method or server validation change): B5 records the return-to-party MOVEMENT, the gatepass records the outward leg's guard taps on the physical flange nos. The one fix in this row is that the beam-tap caption stopped claiming C2's tippan pre-assignment (C2 is beams/warp OUT to a sizer) and now names B5, and B5's cell says which gatepass kind carries the beam leg.
  • Q34 2026-10-03 C193 Is 'sizing → winder' (the WINDING gatepass kind, ?kind=WINDING — to winder, set no, bags/cones/gross/net, transfer year) its own flow row in static/full-flow.html, or part of C5's 'Winding in/out'?
  • A34 2026-10-03 Pareto call: it is its OWN flow row, C5b, placed immediately before C5 — drafted FROM what the gatepass form already asks (to winder, set no, bags/cones/gross/net, transfer year, vehicle/transport/photo/GP no + the status ladder), and C5 keeps its own list (empties, ring wt, rec net, diff net/gr, set closing) on /winding. C5 is the RECEIPT at the godown/winder; this kind is the OUTWARD leg that C3 step 2 already promises ('after final hishob the system ALLOWS creating the WINDING-YARN GATEPASS -> issued to the winder') and never gave a row. So C3's promise gets an identity, C5 is untouched as a receipt, and nothing is renumbered. Not part of C5 (C5's own fields are all receipt-side and none of them is a guard's exit doc); not a B5 movement (B5's items are yarn LOTS; this leg carries a set no + weights, and C3 names a gatepass); nothing deleted. The form changes by one hint sentence and one static row naming C5's receipt fields as not-this-gatepass — no POST name, no zod field, no validation, no change to /winding or the auto-lot hook.
  • Q35 2026-10-03 C194 The recheck says no due-for-collection surface exists anywhere in the app, but /transporter already ships one — its load lists every outward gatepass in intimated/due/partial with the beams/boxes to lift, and its ?/pick action records picked/partial + pickup date/note/photo on the existing gatepass ladder. Should this row build a SECOND list on /gatepasses, or fix the shape of the one that is already there?
  • A35 2026-10-03 Fix the surface that is already there. /transporter's due-for-collection list is the one the flow means (automatic, no filing step, outward intimations only), and the row's own MUST NOT forbids a second status vocabulary, so a second list would make the record unreadable. This row therefore lands on /transporter (PickCard + the row chrome) and its deliverable is the shape the acceptance names — read-only sectioned summary over a hidden POST form, one field per popup, NO section cards — plus an entry link from the gatepasses list and HTTP proof that the tap records picked/partial + date + photo on the existing ladder without touching the gatepass's own fields. No server action, zod schema, POST field name, kind or validation changes.
  • Q36 2026-10-03 C196 The per-kind gatepass audit the row points at (C186-C195) is already DONE, not remaining, and the B0/B5b line the row calls stale was already re-pointed by C189 - so what is left for this row, and is a doc that says 'C186-C193 audited every kind' a claim that collapses the per-kind work?
  • Q37 2026-10-03 C196 C172's pin for flow row B0 is red before this row starts (it expects the B0 line to name /gatepasses/new and C168; C188 re-worded that line to 'not built ... the gate tap under it is C188') and C191/C193 both logged it as owned by C196. Fixing the doc's B0 line is forbidden by this row's MUST NOT, so should C196 correct the stale test pin instead?
  • A36 2026-10-03 The row still has exactly one job and it is docs truth: rewrite ONLY the /gatepasses/new status line so it names the C168 shell (402ba69) as shipped, lists C186-C193 as the per-kind audit one row per kind (YARN_IN C186, DIRECT C187, BEAM_OUT C188, YARN_OUT C189, BEAM_IN C190, BEAM_REPAIR C191, BEAM_RETURN C192, WINDING C193 - all shipped, verified by opening all eight over HTTP), and names the one gate that is genuinely still open (the SS12 items 7-8 phone-width evidence with the keyboard actually open) instead of collapsing into 'the gatepasses are finished'. The row's premise that C186-C195 is remaining work was stale, not the row's purpose. C194/C195 are named as forms of their own, not gatepass kinds, so no kind is double-counted.
  • A37 2026-10-03 Correct the stale TEST pin, never the doc line: this row's MUST NOT forbids rewriting another FOCUS-ENTRY.md line, and B0's own line is truthful today (the planner's intimation form is not built; the gate tap under it is C188's, on the signed UI). tests/c172-focus-entry-flow-coverage.test.ts's 'the queued forms carry their route and their queue row' still expects B0 to name /gatepasses/new and C168 from before the C188 split, so C196 re-points that one pin at the truth - B0 not built, SS8b's tap row named, no route claimed for a form that does not exist - and leaves the doc line and every other row alone. Test-side, one file, trivially reversible, and it stops the drain's ship gate from tripping on a red C191 already recorded.
  • Q38 2026-10-03 C197 The five gatepass rows whose sentence IS the delivered evidence (beamPlanStatic, yarnGoodsStatic, repairStatic, hishobStatic, windReceiptStatic) still print a sentence in the value slot. Moving them into a tap-through pop-up would rewrite the served-HTML proof of four shipped rows (C188 beamout-roles 'a static row records exactly where the planner's numbers went', C189, C190, C191, C193 each assert the sentence in the served row) and this row's MUST NOT says it must not redo their work. Keep them, or move them and re-prove those rows?
  • A38 2026-10-03 Kept in the value slot. Those five rows are a signed pattern from C188-C193 whose sentence IS the delivery, and each one is proven over served HTML by a shipped row (c188/c189/c190/c191/c193 read the row out of the page). Moving them means redoing four completed rows' evidence, which the row's own MUST NOT forbids. Every other static row - all 30 of them, including every auto-number row the row names - is fixed. The five are recorded as a named exception in docs/FOCUS-ENTRY.md §18 with the rows that pin them, so this is one edit away if the owner wants them moved.
  • Q39 2026-10-03 C197 The MUST NOT names 'the carried-order line' as a value that must read exactly as today, yet that line ended in the instruction '— check every row'. Also: is the status ladder 'Entered - picked -> delivered -> confirmed -> reconciled' a value (kept whole) or prose (split), and should static rows gain the kind badge the row text assumes is already beside them?
  • A39 2026-10-03 Three calls. (1) The carried-order line keeps every descriptive word it reads today ('Order X - carried in as the contract, still changeable', 'Booking Y · supplier matched Z', 'KIND reconciliation · PARTY - set no carried in, still editable'); only the pure instruction tail ('- check every row', 'pick the contract below if this movement needs one') moves to the row's pop-up, so the value reads as it does and the sentence is not lost - the reading that keeps the value and satisfies the row's rule. (2) The status ladder stays one value: it has no verb and is the document's own state vocabulary, not an instruction, and three shipped tests pin it byte-for-byte. (3) No kind badge added to static rows: the row text assumed the A badge is already there, it is not, and four sibling tests locate a static row by the exact '>Label<span class="truncate font-medium"' markup, so adding a nested badge span would break all four. The 'Auto'/'-' markers are legible on their own; docs/FOCUS-ENTRY.md records the kinds vocabulary next to the rule.
  • Q40 2026-10-05 C198 20 files of uncommitted Oct-4 work (OrderEntryForm, dom harness, AGENTS.md, package.json...) sit in the tree with no live session; the drain refuses on it and deploy.sh git-add-As everything. Commit only my row paths and skip deploy, or fold that tree in?
  • Q41 2026-10-05 C198 C198 is doing with no session alive (STUCK alarm) and none of its targets are modified in the tree. Flip it to pending and work it first as P0, in engine order?
  • A40 2026-10-05 Pareto: leave the Oct-4 tree byte-identical (never sweep a dead session's half-work into a commit, and deploy.sh git-add-A would ship it live). Each row commits ONLY its own target/test/doc paths and pushes; no deploy.sh from this session. Ship gate + live deploy wait on the owner's call for that tree.
  • A41 2026-10-05 Pareto: yes. No C198 work exists in the tree (scripts/queue-watch.sh unmodified), so flip C198 to pending and take it first — P0 and engine order agree once the stale claim is cleared.
  • Q42 2026-10-05 C200 The Oct-4 dead-session tree (20 files) blocks the drain. Commit it as-is, park it in a named stash, or drop it?
  • A42 2026-10-05 Pareto: STASH in a named stash (reversible; the harness + half-done DOM migration stay a unit and pop back with one command if a row session needs them). Committing would ship half-done work live; dropping would delete a day of work. Drain unblocked the same turn.
  • Q43 2026-10-05 C200 C200 was queued on the belief that the fault was the New tippan anchor on the list page. Opening the app found the anchor fine and TWO faults on the destination component instead: (1) the loom datalist keyed each on loomNo, which is not unique in the loom master, so Svelte threw each_key_duplicate during boot and killed hydration for the whole screen - the reason the button looked dead; (2) the page binds wizStep/wizSearch on the wizard but the wizard's props were step/search, so the binding went nowhere and every summary row opened step 1. Is the row right to fix both on the destination?
  • A43 2026-10-05 Yes - shipped both, on the destination. The row's own acceptance says the cause must be found by opening the page and that if the destination is what is broken the row fixes that too and says so; a button that opens a dead or mis-aimed form has not delivered a working new-tippan form. Fix 1: the datalist offers each distinct loom suggestion once and is keyed on that (one line in TippanWizard; a native autocomplete list cannot use duplicates anyway). Fix 2: the wizard's props carry the names the page already binds, wizStep/wizSearch, matching BookingWizard since C104 - renaming the component to the page rather than the page to the component, because the page's wizStep/wizSearch/openWiz/wizNext vocabulary is the larger existing surface. Both are one-component changes, no POST name / action / method / server validation / step-list / solver / record / print / amend / ?/assign touched. The step/search prop rename is provably reversible (one identifier pair) and the page was already the side that named itself consistently.
  • Q44 2026-10-05 C201 G0b's cell badges 'count/bags expected' 【N】 (typed number) but the DIRECT form asks the count as a 【S】 pick off the yarn master (G0's own count vocabulary). Do I turn the DIRECT count into a typed number?
  • Q45 2026-10-05 C201 G0/G0b list no vehicle and no transporter, yet the form asks both on YARN_IN and DIRECT (showVehicle = kind !== 'BEAM_OUT'). G4 (C195) reads the plate at the gate and G2 (C194) takes the transporter's pickup. Do the two rows come off both kinds with a static row naming G4/G2?
  • Q46 2026-10-05 C201 G0 lists 'cones/bag 【P】' only, but the form asks cones per bag AND total cones on YARN_IN; G0b lists neither. Does the total-cones row come off YARN_IN?
  • Q47 2026-10-05 C201 showMillLot includes DIRECT, so the direct-delivery intimation asks a mill lot G0b never lists. Does that row come off DIRECT while staying on YARN_IN?
  • Q48 2026-10-05 C201 G0b's cell badges its close-out photo 【PH】 while G0 badges the same field 【PH/OCR】; the form serves one field. Which badge does DIRECT carry?
  • A44 2026-10-05 Keep the count a 【S】 pick on DIRECT. The DIRECT goods block is the same countYarn field G0 asks, sharing one row definition, and G0 badges the same field 【S】; a kind-split badge would put two vocabularies on one field. Count stays 【S】 on both inward kinds (countYarn's required flag already reads kind === 'YARN_IN' || kind === 'YARN_OUT', untouched).
  • A45 2026-10-05 Yes - the two rows come off YARN_IN and DIRECT, and a static row names G4 (/inward, C195) and G2 (/transporter, C194) as their real rows, the C189/C192 precedent. MUST NOT keeps C195/C194's own screens and the six other kinds untouched, which is what makes this the row's move: the inward kinds are the only two the flow leaves without a vehicle. Vehicle and transport keep their POST names and their zod fields, so nothing is stored differently.
  • A46 2026-10-05 Total cones comes off YARN_IN. G0 lists bags 【N】, gross/net 【N】 and cones/bag 【P】 and no total; the total is derivable from bags x cones/bag, and B2 reads cones off the gatepass. Keep the hidden 'cones' input mounted (POST name unchanged) so a booking-carried or OCR-prefilled total still lands, and a static row says the flow lists cones per bag and the total follows from it. WINDING (C5b) still lists cones outright and keeps the row.
  • A47 2026-10-05 The mill lot comes off DIRECT and stays on YARN_IN. G0b lists count/bags/destination/expected date/status and the close-out; a mill lot is a shade identity that belongs to the inward yarn receipt (G0) and to B2's lot no. A static row on DIRECT names G0 as its row. showMillLot narrows to kind === 'YARN_IN'; millLotNo, its POST name, its zod field and its column are untouched, so a stored DIRECT gatepass still shows whatever it carried.
  • A48 2026-10-05 DIRECT carries 【PH】, its own cell's badge (G0b: 'sizer=WhatsApp confirm+photo 【PH】'); YARN_IN keeps 【PH/OCR】, G0's badge. The badge is now read per kind off the same field, so each kind is badged with the mode its own flow cell lists. No POST name, zod field or column moves - both already exist from C186/C187.
  • Q49 2026-10-05 C63 C63 says remove the priority field completely — does that mean only the /queue new-correction form field, or also the queue engine's internal priority metadata (QUEUE.md 'priority:' line, --set --priority, planGroups sort)?
  • A49 2026-10-05 Pareto: remove the user-facing field only — the Priority select and the P0 badge are gone and --add no longer accepts --priority. The engine keeps its internal P1 because rows already run top-to-bottom of the sheet; ripping priority out of planGroups/parse/render is a flow change outside this row's /queue target and not needed to satisfy the correction.
  • Q50 2026-10-05 C66 C66 restates C65 almost verbatim (UI tests only when absolutely necessary) with target '-'; does it supersede C65's narrower 'purely visual' wording and where must the rule live -- watcher prompt only, or the governing docs too?
  • A50 2026-10-05 Pareto: C66 is the governing wording and supersedes C65's 'purely visual' narrowing. The rule goes where it can actually bind: the watcher's worker prompt (scripts/row-watch.sh step 3) AND AGENTS.md's Verification section, which C65 left still saying 'screen proof is a command / a change is proved by opening the page'. UI tests stay available, last resort only.
  • Q51 2026-10-05 C67 C67 names only the /orders/new/trading upload; does the deepseek-v4.1-flash switch apply to that upload alone or to every AI read on the one opencode gateway?
  • A51 2026-10-05 All AI reads. They share one gateway and one CAPTURE_LLM_MODEL; two models on one key would be surprising and drift. Matches C64 'everything'. Per-read override is still possible via env if ever needed.
  • Q52 2026-10-06 C68 The owner says the new-order pages' UI is 'extremely difficult to comprehend'. How far should this row redesign the order-entry form?
  • A52 2026-10-06 Keep it to the reversible 80/20: segregate the three type-fixed order-entry forms into their own sidebar group and add a one-line plain-language purpose under each form's title so the kind is obvious. Leave the wizard/summary flow, POST names and server validation untouched; a deeper form redesign is a separate owner-scoped row.
  • Q53 2026-10-06 C69 C69 names no target; its wording (sidebar confusing + pages show similar/unimportant info) overlaps C68 (sidebar segregation + purpose line, done) and C70 (merge the three kinds into Orders). What is C69's own scope?
  • A53 2026-10-06 C69 owns the always-visible dead content on the three type-fixed new-order forms: drop the redundant kind-code + derived open·auto status from the header and the fixed Kind/Status rows from the summary and save review. Sidebar stays with C68 (done), the merge with C70.
  • Q54 2026-10-06 C70 Does 'orders can go away' mean drop the separate 'New order' group and merge its three type-fixed links into the existing Orders group, or drop the Orders group (list + Leads/Hishob/Samples/Quote/Reports) instead?
  • A54 2026-10-06 Merge, do not delete: remove the separate 'New order' group and put Trading SO / Job Work SO / Production Order inside the existing Orders group, right after All Orders. C69's own note calls C70 'the merge of the three kinds into Orders'; deleting the Orders group would strand Leads/Hishob/Samples/Quote/Reports and break append-only reachability.
  • Q55 2026-10-06 C71 C70 already removed the standalone 'New order' group and moved Trading SO / Job Work SO / Production Order into the Orders group. C71 is a stronger restatement ('remove it completely') — does it mean delete those three type-fixed links from the sidebar too, and the now-orphaned active('/orders') special-case, or is C71 already satisfied by C70?
  • A55 2026-10-06 Remove them. 'New orders section ... remove it completely' is stronger than C70's merge: the three type-fixed order links (Trading SO / Job Work SO / Production Order) come out of the Orders sidebar group entirely, so the sidebar carries no new-order section at all. The /orders page already offers 'New Trading SO' / 'Add Trading SO' buttons and a drafts row with all three hrefs, so every creation route stays reachable; the pre-C68 active('/orders') yield for /orders/new is dropped with the entries it existed for. Display-only, one file, reversible.
  • Q56 2026-10-06 C72 C72 says 'in sidebar, all orders need to be separated'. Does it mean split the sidebar's single combined 'All Orders' entry into the order kinds as separate entries (Sale / Job-work / Outsource / Stock, linking the existing /orders?type= views), or restore the three type-fixed new-order creation links (Trading SO / Job Work SO / Production Order) that C71 just removed?
  • A56 2026-10-06 Split the combined 'All Orders' entry into its kinds as filtered list views (/orders?type=SO|JW|OUTSOURCE|PROD), mirroring the /orders page's own kind tabs (§117) and the /gatepasses 'All X yields to the kind' pattern; keep 'All Orders' as the catch-all. This is the literal reading of 'all orders need to be separated' (the orders, by kind), it does not resurrect the new-order create section C71 called stupid, keeps every order view reachable, and is display-only in one file.
    • 2026-11-04 (owner): Sale and Stock no longer ride a query — they own /sale and /prod (PLANNING 746). /orders keeps All / Job-work / Outsource; /orders?type=SO|PROD 308-redirects to the kind's own screen with the query carried, so A56's reachability still holds and the old addresses keep working.
  • Q57 2026-10-06 C73 remove all orders from sidebar: does it mean delete the entire Orders group (incl. Leads/Hishob/Samples/Quote/Reports), or remove the order-list entries (All Orders + Sale/Job-work/Outsource/Stock) and keep the rest reachable?
  • A57 2026-10-06 Remove the order-list entries only (All Orders + Sale/Job-work/Outsource/Stock) and rename the now-orderless group to Commercial, keeping Leads/Hishob/Samples/Quote/Reports reachable. Deleting the whole group would strand those five links (the A54/Q54 Pareto already refused exactly that) and violate append-only reachability; the correction's 'orders' are the order views, which the previous owner notes (C68-C72) always meant. Display-only, one file, reversible.
  • Q58 2026-10-06 C74 C74 corrects C73: does restoring the sidebar mean the pre-C73 'Orders' group name returns (minus All Orders), or keep the C73 rename 'Commercial' and just re-add the four kind entries?
  • A58 2026-10-06 The correction 'i meant to only remove all orders' scopes C73 to a single deletion, so the intended end-state is exactly pre-C73 minus the 'All Orders' entry: restore the group name 'Orders' and the four kind views (Sale/Job-work/Outsource/Stock), keep Leads/Hishob/Samples/Quote/Reports reachable, and keep the C73 create-button per-kind fix. Keep the orphaned active('/orders') branch removed since no plain /orders link exists. Display-only, one file, reversible.
  • Q59 2026-10-06 C75 C75 says 'kind column in each of the order pages can go away now' — does it mean only the list table's Kind column, or also the Kind field in the record popup and the order detail page; and should the All tab keep the column since it still mixes kinds?
  • A59 2026-10-06 Remove the orders-list table's Kind column on every wide tab (Sale/Outsource/Stock/All) unconditionally — 'column' is literally the table column and the owner said it can go away now that the sidebar segregates the kinds. Keep the Kind field in the record popup and the order detail page: those are fields, not columns, and retaining them means no information is lost if someone opens a record. Display-only, one file, reversible by restoring the column entry and its row value.
  • Q60 2026-10-06 C76 C76 says /bookings looks chaotic on a smartphone — what is the fix scope? The compact 5-column table still carries an actions column with up to three row buttons (Cancel, Record gatepass, Attach to order) that crowd a phone row: move those actions into the booking's record popup (where the fields already live) or redesign the page (headers, columns, toolbar)?
  • A60 2026-10-06 Move the per-row action buttons out of the table and into the booking's record popup — the intent C162 already declared ('every other field and every action is in the row popup') and the same move as the job-work order table (C140). The compact table then fits a phone with no action column; keep the page header, columns and toolbar as they are. Every destination survives, display-only, one file, reversible.
  • Q61 2026-10-06 C77 C77 says /guard looks chaotic on a smartphone — what is the fix scope? Each guard row packs its identity block (GP no, kind, party, Next badge) and the exit form (vehicle input w-28 + camera + Exited) into one justify-between line that overflows a phone: restack the row (identity block, then full-width action form, like the twin /transporter) or redesign the page or move the exit into a popup?
  • A61 2026-10-06 Restack the row: identity block on its own line, then the exit form full-width beneath it with a flex-1/min-w-0 input — the shape the twin /transporter row already uses. This is the same 80/20 as Q60/C76 ('crowded row, not a page redesign'): keep the header, the DISPATCH due-list, every field and every action; do not swap the inline camera for the PlateScan component (a behaviour change, not the crowding named). One file, display-only, reversible.
  • Q62 2026-10-06 C78 C78 defers build+deploy to when all corrections are done — while rows are still queued, should each finished row still be committed+pushed (tree clean, work safe) or left uncommitted until the end?
  • A62 2026-10-06 Commit+push each row with deploy.sh --commit-only (no build/restart/live-check); run the full build+deploy once when no runnable row remains. Uncommitted work across many serial rows would be autostashed by the next session's pull and risks loss; a commit is cheap and reversible, a deploy is not.
  • Q63 2026-10-06 C79 C79 says the order fill is compulsory — does that mean a hard server-side rejection (fail 400) of a tippan with no order, or the wizard/summary gating that stops any other field being entered until the order is picked, while the create action keeps accepting a null order for the existing assign-later card and curl paths?
  • A63 2026-10-06 Gate the entry, keep the server contract. The order becomes the wizard's first, compulsory-before-anything step: no other summary row opens, the wizard's Next is disabled, and Check-the-tippan/Save stays disabled until an order is picked. The create action still accepts a null weaverOrderId (assign-later card and existing POST/curl flows unchanged): the correction's words are about entry order ('before any other field is allowed to be filled'), and a new server validator would break the assign-later flow for no wording gain. Fewest files, reversible.
  • Q64 2026-10-06 C81 Does 'job work order' mean only JW, or also OUTSOURCE?
  • Q65 2026-10-06 C81 Should the multi-order selection persist on the tippan (new column) or stay UI-only?
  • Q66 2026-10-06 C81 Should the create action reject a job-work order id, or is the picker filter enough?
  • A64 2026-10-06 Exclude both JW and OUTSOURCE — orderLogic groups them as the job-work-style kinds and the picker is titled 'Production order / Trading sale order'.
  • A65 2026-10-06 Persist: add a nullable tippan.weaver_order_ids JSON array; keep weaver_order_id = first order so every existing reader/join/print is untouched.
  • A66 2026-10-06 Picker filter is enough (matches C79's UI-gate Pareto); the action still validates every id exists, as before.
  • Q67 2026-10-06 C82 Where should the yarn assignment persist — a new tippan column or the existing yarn_issue JSON?
  • Q68 2026-10-06 C82 Which records count as available for each source (booking/gatepass/direct/stock)?
  • Q69 2026-10-06 C82 Should the create action re-validate that the picked source is still available, or only that it exists?
  • A67 2026-10-06 Keep the existing yarn_issue JSON (add assignSource/assignRef/assignLabel): no migration, fewest files, fully reversible, and the detail/print already read that JSON.
  • A68 2026-10-06 Read it plainly: booking status open|partial (not yet received); YARN_IN/DIRECT gatepass status intimated|due (not picked up / not received); lot status available (free stock). Closed bookings, picked GPs and allocated lots stay excluded.
  • A69 2026-10-06 Existence-only, matching C81's order check: a source that moves on after the form opened must not block an entry already started; the picker is the gate.
  • Q70 2026-10-06 C83 C83 — 'consequent weight (auto calculated)': what is the formula and where does the weight come from? The assigned source has bags/cones/cones-per-bag/net, the form also has per-cone kg — is the weight (bags x cones-per-bag + loose cones) x per-cone kg, or scaled from the source's total net?
  • A70 2026-10-06 Auto-calculate weight = (bags x cones-per-bag + loose cones) x per-cone kg, read off the assigned source's own rates (booking perConeWt, else bagWt/conesPerBag, else net/(bags x conesPerBag); gatepass/lot net/cones), falling back to the form's Per-cone kg and packing when the source carries none. The create action recomputes it as the arbiter (a posted assignNet is ignored) and stores assignBags/assignCones/assignNet in the existing yarn_issue JSON — no migration, reversible, matches C82/A67. Partial draw is never validated against the source's totals (existence-only, C82/A69).
  • Q71 2026-10-06 C84 When assigning yarn later fills the whole yarn issue section, should it overwrite figures already on the tippan or only fill the fields the assigned source carries?
  • A71 2026-10-06 Only fill fields the assigned source actually carries; never wipe a value already on the tippan (bookings carry no count/mill, so those stay as they were). Reversible and matches the no-silent-overwrite spine.
  • Q72 2026-10-06 C85 What does 'the sizing form UI is a mess, make it proper' require beyond the two concrete asks (compulsory yarn, per-beam own/outsourced plan)?
  • Q73 2026-10-06 C85 Each beam line: is 'no. of beams' the count of beams in that line and 'mtr' the metres per beam, and is the line tagged own vs job-work, stored in the existing program JSON?
  • Q74 2026-10-06 C85 The job-work contract can be assigned later — where does that happen and where is the ref stored, given yarn is now compulsory at create?
  • A72 2026-10-06 Keep the C110 read-only summary + one-field wizard (the sanctioned focus-entry pattern). 'Proper' = tidy the yarn block (assignment is compulsory, no assign-later) and replace the single #Beams count with a per-line beam plan. Fewest files, reversible; no wholesale redesign.
  • A73 2026-10-06 Yes: one beam-plan line = {kind: own|job, beams: count of beams, mtr: metres per beam}; the sum of counts is the planned beam total; stored in the existing program JSON (no migration).
  • A74 2026-10-06 Optional JW/OUTSOURCE order picker at create plus the repurposed 'Assign the job-work contract later' card on /tippans/new; stored as program JSON jobWorkOrderId + jobWorkOrderLabel; no migration, no in-place edit of a committed doc.
  • Q75 2026-10-12 C111 The creation screen's kind chips were also the only on-page way to switch between the eight movements. Removing the horizontal scroller: drop the picker entirely (kind is chosen on the list page before the form), or keep a way to switch kind on the page?
  • A75 2026-10-12 Drop the picker entirely. The eight gatepasses are distinct movements, not types of one document, so a chip scroller misrepresents them exactly as the owner says. Kind is already chosen on the list page's New gatepass menu (each link goes to /gatepasses/new?kind=…, PLANNING §193) before the form, so nothing is lost; the header badge still names the fixed ?kind= and the Previous-records table still follows it. Fewest files, reversible.
  • Q76 2026-10-12 C112 C112 lists '4 fields: Booking number + Yarn (Count+Type+mill name) + Trader + Rate' plus a bags popup (already-received date-wise) and destination from masters, but a gatepass has no rate column and the booking link rides the creation event only. Reading taken: the DIRECT intimation is made booking-driven — the picked booking supplies booking no + yarn (count/type/mill) + trader + rate as read-only context, the wizard becomes booking → trader → expected date → bags, and 'already received date-wise' is matched by yarn count across prior DIRECT receipts. Rate/yarn type are DISPLAY-only (no new column). Is that right, or should rate/type be stored on the gatepass (its own migration)?
  • A76 2026-10-12 Safe 80/20 reading, per C165/Q11: the booking is the intimation's source, so booking no + yarn (count/type/mill) + trader + rate are shown read-only fetched from the booking and NOT stored — a new gatepass column is out of scope for a UI row (it would need its own migration). 'Already received date-wise' is derived read-only from prior DIRECT receipts matched by yarn count (the booking link is event-only, so per-booking attribution is a separate change). Wizard stays the four compulsory fields: booking → trader → expected date → bags. Fully reversible, no schema/zod/POST change.
  • Q77 2026-10-12 C112 C112 reopen says the DIRECT intimation must show ONLY 4 fields. Literally only four rows — which would also drop the C186/C187 close-out evidence rows (gatepass photo, confirmation photo, GP counter-copy) and the universal Kind/GP-no/Status markers — or the four editable fields with the flow's close-out evidence and universal static markers kept?
  • A77 2026-10-12 Keep the four editable fields exactly — booking, bags to be received, location, expected date. Remove every row the owner named (count, trader/party, order, GP-date) plus the now-redundant read-only rows (Booking says / Total bags booked / Already received / Prefilled by), folding their content into the booking pick label and the bags popup sub. The C186/C187 close-out evidence rows (gatepass photo, confirmation photo, GP counter-copy) stay — they are not fields, the owner did not name them, and removing them would break the signed flow. The universal Kind/GP-no/Status static markers stay as on every kind. No schema/zod/POST change.
  • Q78 2026-10-12 C113 On G0 (YARN_IN), should the form be stripped to ONLY booking + bags-to-receive + location (like C112's DIRECT, dropping C201's goods fields — count, ticket, mill lot, gross, net, cones/bag), or does C113 mean those fields are REQUIRED in addition (Fields required, not only), with the booking made primary? Also: 'location of pickup (from godown master)' — there is no godown master table; the only godown list is the existing destination picker (our godown / premises / named sizer) — is relabelling that picker the right reading, and is a booking with no purchase rate the 'job work' case that drops trader + rate and says 'to be received' instead of 'booked'?
  • A78 2026-10-12 Safe 80/20: keep G0's C201 goods fields (C113 says 'Fields required', not 'only'), and make the booking the primary/compulsory field on a fresh or OCR-opened yarn-in (BLOCK_NEXT + required), with the C112-style label (booking no + yarn count/type/mill + trader + rate) and the bags-to-receive popup (booked total, already-received date-wise, prior-bag suggestions). 'Location of pickup (from godown master)' = the existing godown destination picker, relabelled (no godown master table exists; its POST names destPlace/targetPartyId don't move). 'Job work' = a booking with no purchase rate: its label drops trader/rate and its bags popup says 'to be received' not 'booked'. Carried yarn-in (?bookingId=/?orderId=/?reconId=) keeps its carried flow and is never blocked. Fewest files (two), reversible, no schema/zod/POST/column change.
  • Q79 2026-10-12 C115 C115 targets /tippans/new but 'the background form has more fields than specified' also reads like /gatepasses/new?kind=DIRECT (C112). Which surface, and which fields are the extras?
  • A79 2026-10-12 Follow the row target: /tippans/new. Read 'the background form' as the tippan entry surface (sectioned summary + hidden POST), and the extras as the gatepass-given yarn-issue fields (Yarn GP/Source/Count/Mill/Packing/Bags/Cones/Net) that the C82/C85 compulsory yarn assignment supersedes per C84; remove those steps/rows and fill the issue from the assignment, keeping every POST name.
  • Q80 2026-10-12 C113 C113 reopen says G0 shows ONLY the owner's fields, exactly as the C112 DIRECT reduction. Two things it does not name: (a) does 'exactly as C112' also drop G0's GP-date row and its 'Prefilled by' static (DIRECT dropped both)? (b) 'Location of pickup (from godown master)' vs dropping the separate 'To party' row — should the one pickup-location picker carry our godown / premises / named sizers so a sizer is still pickable without a second row?
  • A80 2026-10-12 Safe 80/20, mirroring A77 for G0b: (a) yes — drop the GP-date row (the date still posts, defaulted to today) and the 'Prefilled by' static, as DIRECT did; (b) yes — the ONE 'Location of pickup' picker carries our godown / premises / the named sizers and posts the existing destPlace+targetPartyId names, so the 'To party' row the owner named is gone but a named sizer is still pickable. No schema/zod/POST/column change.
  • Q81 2026-10-12 C116 Does C116 remove only the DIRECT (direct-delivery intimation) options from the tippan yarn-assignment picker, or also the server's direct-assignment resolution (back-compat for carried/legacy POSTs)?
  • A81 2026-10-12 Remove only the picker options (the visible direct-delivery records) and narrow the availability query to YARN_IN; keep the server's direct-assignment resolution for carried/legacy POSTs so no existing flow breaks (reversible, fewest files).
  • Q82 2026-10-13 C115 The reopen's removal list names targetPartyId, but DIRECT's visible Location picker stores the sizer as targetPartyId (destPlace='sizer'), so removing it would drop the sizer; C201 also keeps vehicle/transport mounted for G0/G0b carries. Do we keep location's targetPartyId, drop vehicle/transport on the reduced kinds, and scope the hidden-form reduction to the booking-driven kinds only?
  • A82 2026-10-13 Keep targetPartyId: it IS the Location field's stored value (a named sizer posts destPlace='sizer' + targetPartyId), not an extra row. Drop vehicle/transport on DIRECT/G0 (the reopen says the hidden form holds ONLY the kind's visible fields). Scope the reduction to the booking-driven kinds (DIRECT/YARN_IN); every other kind's hidden transport set stays byte-identical (their reverse booking-picker legitimately fills count/ticket/mill-lot). The booking's own figures (trader, count, ticket, mill lot, contract) are read server-side from the picked booking, never mounted.
  • Q83 2026-10-13 C116 The reopen says drop the 'Previous {kind} records' section on /gatepasses/new. Does that also remove the now-unused server load that fed it (data.recent + its 40-row gatepass query), or keep the load untouched?
  • A83 2026-10-13 Remove the now-dead server load too: 'drop the whole section' plus its only consumer gone, so leaving the 40-row query is dead code. Fewest live lines, fully reversible (it is load-only, no action/POST/schema touched).
  • Q84 2026-10-13 C115 The reopen drops DIRECT's whole photo/vehicle section and reduces G0 to the gatepass photo only. Does the G0 section keep the 'Photo & vehicle (you can skip)' title (now naming a vehicle it no longer has), and should the G0 gatepass photo become a required field (C113 calls image storage a required G0 field)?
  • A84 2026-10-13 Safe 80/20: (a) title — use the photo-only 'Gatepass photo (you can skip)' for G0 as BEAM_OUT already does, so the section never promises a vehicle it no longer shows; (b) image stays optional at entry (not a wizard step): C113's 'required' means the field must exist and be OCR/image-storage-capable, not that it blocks the tap — making it required would change validation the reopen did not ask for. No POST/zod/column change.
  • Q85 2026-10-13 C117 On a DIRECT direct-delivery intimation, is the drop location's acknowledgement file compulsory before confirming, and does confirming move the intimation straight to confirmed (no separate delivered tap)?
  • A85 2026-10-13 Optional: acknowledgement file and remarks are both optional so a recipient on a weak phone/signal can still confirm; confirming a DIRECT intimation moves it straight to confirmed (event from intimated->confirmed) since the drop location's acknowledgement IS receipt. Existing out-bound delivered flip and generic inbound no-flip are untouched. Reversible.
  • Q86 2026-10-13 C118 Should a direct delivery's two states be stored as new values (drop_pending/drop_completed, migrating the four live 'intimated' rows) or collapse the existing intimated/confirmed only for display, and should DIRECT be dropped from the /inward intimated-chain queue?
  • A86 2026-10-13 Display-only collapse: gpStatusWords(kind,status) maps DIRECT's intimated|due|partial|picked -> 'Drop pending' and delivered|confirmed|reconciled -> 'Drop completed', leaving the stored status column, zod, POST names and every existing query untouched. This keeps existing behaviour (C117's ack already writes 'confirmed'), needs no migration for the four live DIRECT rows (they are intimated -> Drop pending), and is fully reversible; direct delivery is also dropped from the /inward intimated-chain queue because its two-state flow completes at the drop location's acknowledgement (C117) or the guard receipt (C119), not the G4 chain.
  • Q87 2026-10-13 C119 C119 says 'reuse the existing guard receipt action, not a new screen', but /guard had no receipt action — only exit (outbound) and beamConfirm. Reading taken: add a 'receive' action on the existing /guard page (no new screen/route) that reuses the C117 received-confirmed status move (DIRECT intimated->confirmed = Drop completed), logs the same gatepass:received-confirmed event carrying the guard's vehicle + driver photo, and fires the existing createLotsFromGatepass hook (yarn inward). Is that the intended 'existing guard receipt action', or did you mean the C117 no-login /c/gp confirm link used from the guard's phone?
  • A87 2026-10-13 Safe 80/20: add a receive action to the EXISTING /guard screen (no new route/screen), reusing the C117 received-confirmed semantics (DIRECT intimated->confirmed = Drop completed) plus the existing createLotsFromGatepass hook so the yarn inward is created on receipt; the guard enters vehicle no + driver photo (image, stored in the screenshots bin like the C117 ack). The C117 no-login link stays for the named-sizer/external drop only.
  • Q88 2026-10-13 C120 C120 says job work = 'job-work number, no yarn booking', while C130 (separate, pending) adds job-work ORDERS to the picker. Reading taken: job work here is the existing rate-less open booking (isJobBooking, A78) — not a new job-work-order picker — so no C130 overlap. Is that the intended job-work case?
  • A88 2026-10-13 Yes, safe 80/20: job work = a rate-less open booking (the one BK-MLP-1 row has yarn_id null, so it genuinely has no yarn identity). A rated booking shows the yarn identity auto read-only; a rate-less one makes count/type/mill user-picked wizard steps. Job-work-ORDER search stays C130's scope.
  • Q89 2026-10-13 C121 Does C121's rename+move apply only to the DIRECT form, or to the shared GP no row on all eight gatepass kinds?
  • A89 2026-10-13 DIRECT only — the correction and its target name the direct-delivery form; other kinds keep their 'GP no' row where it is (one .svelte, reversible).
  • Q90 2026-10-13 C122 Where exactly does the Status badge sit at the top, and does it keep an explanatory note (which would make the row tappable/field-like)?
  • A90 2026-10-13 Kind -> Direct delivery no -> Status; keep the badge as a non-tappable informational line (no note) so it is a tag, not a field row, per C122 wording
  • Q91 2026-10-13 C131 Removing the broker name field from the party form: should the underlying party.broker_name column and existing stored data also be dropped via migration, or only the form field removed?
  • A91 2026-10-13 Only the form field is removed. The party.broker_name column and any already-stored values stay (no migration, no data loss) — reversible, fewest files, and existing rows keep their history.
  • Q92 2026-10-13 C132 Does 'remove opening balance field' mean drop the party.opening_balance column and existing values, or only retire the form field?
  • A92 2026-10-13 Form-only retirement (mirrors C131): the field goes from the add/edit form, the record dialog and the printed field reference; party.opening_balance column + stored values stay. No migration, no data loss, smallest reversible file set.
  • Q93 2026-10-13 C133 Does 'remove due days field' mean also drop the Due days column from the party list table and the due_days column from the database, or only retire the party add/edit form field?
  • A93 2026-10-13 Form + display retirement (mirrors C132/C131): drop the due-days field from the add/edit form, the record dialog, the party-list column and the printed field reference; keep the party.due_days column and stored values. No migration, no data loss, smallest reversible file set.
  • Q94 2026-10-13 C134 C134 asks for mobile/email validation, but PartyForm.svelte already enforces mobile /^[6-9]\d{9}$/ (+91-aware) and email on the client, and +page.server.ts enforces both on the server (PLANNING 141). Does the row mean add live/typed input relevance on top of the existing rules, or only confirm them and change nothing?
  • A94 2026-10-13 Safe 80/20: keep every existing mobile/email rule and message byte-identical on both sides; add only additive input relevance in PartyForm.svelte - the mobile field strips characters outside its own pattern [0-9+ -] as you type so invalid input cannot be entered, and both fields clear their stale submit-time error on edit. One file, reversible, no POST name / schema / zod / server change.
  • Q95 2026-10-13 C135 Does adding a Godown party category also mean a Godown party should be excluded from the gatepasses trader picker (like Sizing/Weaver/Transport), or is the category purely a master label with downstream filters untouched?
  • A95 2026-10-13 Keep every downstream filter untouched — the correction names Category on /masters only. A Godown party is a new value with no prior rows, so nothing existing changes; excluding it from the gatepasses trader picker would be a separate behaviour change. Fewest files, reversible.
  • Q96 2026-10-13 C136 Should the picked country code be persisted with the mobile number (and how are non-India numbers stored/validated), or is the select display-only?
  • A96 2026-10-13 Persist it. +91 (India, default) stores byte-identical bare 10 digits as today; any other known code stores (digits only) so existing WhatsApp/quote helpers — which strip non-digits and only prefix 91 to a bare 10-digit — keep working. Non-+91 local numbers validate 4-15 digits. Add a short whitelist of known dial codes shared by form + server.
  • Q97 2026-10-13 C137 C137 says remove the phone number field on /masters?tab=party. Does that also drop the read-only Phone line from the record detail (MASTER_FIELDS in +page.svelte), and should existing party.phone values be preserved on edit?
  • A97 2026-10-13 Remove only the editable Phone input and its client/server validation on the party form. Keep the read-only Phone line in the record detail (MASTER_FIELDS) and keep party.phone data intact; carry the existing value through a hidden input on edit so saving other fields never nulls phone. Fewest files, reversible, no data loss.
  • Q98 2026-10-13 C138 Does the new MSME (Udyam Aadhar) field need a strict format validation rule, or just accept the number as free text?
  • A98 2026-10-13 Accept as free text (trimmed, stored as string). Udyam Aadhaar numbers mix letters+digits+dashes (UDYAM-XX-00-0000000) and genuine numbers vary, so a strict regex would reject valid entries; the row only asks to add the field. Validation can become its own row like C140 for PAN/GSTIN. No schema format constraint - a text column, reversible.
  • Q99 2026-10-13 C139 C139 says remove the old unit toggle on /masters?tab=party. Does that also drop the 'Own unit' list column, the record-detail row and the party.is_own_unit field/data, or only retire the visible form toggle?
  • A99 2026-10-13 Retire only the visible 'Own unit' toggle in the party form (mirrors C137/C131). Keep the party.is_own_unit column, the party-list column and the record-detail row, and carry the existing value through a hidden round-trip input on edit so saving other fields never flips a legacy unit off. No migration, no data loss, fewest files, reversible.
  • Q100 2026-10-13 C140 PAN/GSTIN rules already exist on both sides (PartyForm.svelte + partyErrors, PLANNING 141) and are server-proven; does the row want new/changed rules, or only live input relevance on top of the existing ones?
  • A100 2026-10-13 Safe 80/20: keep every existing PAN/GSTIN rule and server message byte-identical (PAN 5 letters+4 digits+1 letter; GSTIN 15-char with Z at 11); add only additive input relevance in PartyForm.svelte so the fields normalise as you type (uppercase, strip non-alphanumerics, cap at 10/15) and clear their stale submit error on edit. Mirrors C134/A94. No server/schema/POST-name change.
  • Q101 2026-10-13 C141 Does 'remove amend button after edit' mean drop the standalone Amend control entirely on the party tab (folding the correction remark into the edit form so Save records it), or only hide Amend while the edit form is open?
  • A101 2026-10-13 Drop the standalone Amend control on the party tab: the correction remark becomes a field of the edit form and Save records it as an appendage (amendment). Other master tabs keep their existing Amend control unchanged (the target is ?tab=party).
  • Q102 2026-10-13 C142 Does C142 remove only the visible Suggest button in the Acronym field, or also the auto-suggest-on-typing behaviour that fills the acronym from the party name until the user edits it?
  • A102 2026-10-13 Remove only the visible Suggest button. The correction names the button, not the prefill; keep the existing auto-suggest-on-typing ($effect) byte-for-byte so Add/Edit keep filling the acronym from the name until the user types their own. Fewest files, reversible, moves no stored value.
  • Q103 2026-10-13 C143 Target says masters?tab=payment-terms but the wording says 'design master' — which record does C143 remove the rates & rolls section from?
  • A103 2026-10-13 Design master (masters?tab=design) — the wording names the section and C144–C150 all edit design-master fields (weft wastage, warp/weft grid, PPI, GSM/UTL, Denting); the payment-terms URL is a batch mislabel.
  • Q104 2026-10-13 C144 Does 'any new record' also require the quote edit/requote Weft Waste % field to prefill 5, or is the design-master new-record form enough?
  • A104 2026-10-13 Design-master only. C144 is part of the C144-C150 batch that edits design-master fields (PLANNING 426) and the target tab is a known batch mislabel. The design form is the one new-record screen that left weft waste blank; /quote/new already prefills 5 via EFF_DEF and /quote/edit's server builder already defaults 5. Keep existing behaviour and touch the fewest files.
  • Q105 2026-10-13 C145 C145 Permissible counts — where may the allowed substitute counts come from (a picker over the yarn master's counts, or free entry), and does the new warp/weft grid replace the raw JSON textareas that row C146 targets?
  • A105 2026-10-13 Permissible counts are free per-row entry (comma-separated positive numbers) shown as removable badges — the row names no candidate source and a picker would need a new yarn-master dependency and another file; the grid replaces the two raw JSON textareas (C146's target), since a visible JSON blob is exactly what C145 replaces. Fewest files, reversible, stores nothing new that the JSON row shape cannot carry.
  • Q106 2026-10-13 C146 C146 orders removing the warp/weft rows fields, but C145 (just shipped) rebuilt those same fields as the Sr No./Count/Unit/Percent/Permissible grid. Does C146 mean delete multi-warp/weft entirely (removing C145's grid) or remove the raw-JSON field presentation it names?
  • A106 2026-10-13 Keep C145's grid; C146 removes only the raw-JSON presentation it names. A visible JSON blob was exactly what C145 replaced, and deleting the grid would undo a row the owner asked for one sitting earlier (A105). Fewest files, reversible: drop the JSON wording/labels and the field reference's JSON claim; nothing stored is touched.
  • Q107 2026-10-13 C147 C147 says quality name to be derived from all other fields, not manual. Which string should the derived name take, and does deriving mean the stored name is recomposed on every save (normalising legacy names)?
  • A107 2026-10-13 Derive the name with one shared pure helper on both surfaces, canonical format widthreed/denting*pick/warp*weft-weave (e.g. 6384/370/3232-2/1-TWILL) matching the dominant stored convention; the server builder composes it and ignores any posted quality_name, so legacy names normalise to this format on their next edit (append-only audited diff, no data loss). The alias stays manual and moves beside the name at the top.
  • Q108 2026-10-13 C148 C148 remove the PPI field and write the literal Pick in the quality name: the pick column still feeds the costing engine (weft weight), so does the stored pick stay silently (hidden carry on edit), or is it dropped entirely?
  • A108 2026-10-13 Pareto: remove the visible Pick (PPI) input and put the literal Pick where the number was; carry the stored pick through a hidden field on edit so the costing weights are not zeroed and no committed value is overwritten. A new record legitimately has no PPI. Reversible.
  • Q109 2026-10-13 C149 C149 (batch target ?tab=payment-terms) = design master, per Q103/A103 — remove the visible GSM target and UTL inputs. Does the stored gsm_target/utl value need preserving on edit (checking/report reads design.gsm_target), or is dropping it intended?
  • A109 2026-10-13 Remove the fields from the form only. Keep the DB columns and existing stored values — the safe 80/20: dropping gsmTarget/utl from buildDesignValues makes an edit OMIT those columns (drizzle skips absent keys), so committed gsm_target/utl survive and the /checking/report GSM-target column keeps working; new designs simply have none. No schema migration, no hidden carry, fully reversible (re-add two builder lines + two inputs).
  • Q110 2026-10-13 C150 C150's correction text shows the same string on both sides (a paste typo): does 'write only' mean drop the '— EPI = reed × denting ÷ 2' hint from the Denting field label and keep 'Denting (ends per dent)'?
  • A110 2026-10-13 Yes — the string is duplicated by a paste typo; the only reading that makes 'instead of X write only Y' true is to drop the EPI formula hint and keep the label 'Denting (ends per dent)'. Safe 80/20: the wording already lived on the design master (C143-C150 batch mislabel), one label text only, reversible.
  • Q111 2026-10-13 C152 The row target names /tippans/new (corrections sheet) / /masters?tab=party (queue), but the \u201cwarp and weft grid\u201d with count / % / permissible counts exists only on the design master (/masters?tab=design, DesignRowsGrid). Is the design master the intended surface?
  • A111 2026-10-13 Design master (/masters?tab=design) is the surface: \u201cwarp and weft grid\u201d + count / % / permissible counts exist only in DesignRowsGrid there. ?tab=party and /tippans/new are the C143-C152 batch mislabel (Q103-Q110), same as C145-C151. No tippan screen renders a warp/weft grid.
  • Q112 2026-10-13 C152 The correction only says prefill percentages when a NEW row is added. Should deleting a row also re-share the 100% (else 3 rows at 33.33/33.33/33.34 minus one leaves 66.66), or leave typed values untouched?
  • A112 2026-10-13 Delete also re-shares via distribute() — \u201ctotal of % to be 100%\u201d would otherwise break on delete; fewest files, reversible, values stay editable.
  • Q113 2026-10-13 C153 The row names only L2L, but the same design-master block tags siblings with legacy codes (Lasa (110), Size add-on % (10), Weft waste % (5)). Does 'Remove (104) in the label of L2L' mean drop only the L2L tag, or every sibling code too?
  • A113 2026-10-13 Only the L2L tag: the correction names one field and one code, so scope is that single label; sibling codes are their own corrections if wanted. Fewest files, reversible.
  • Q114 2026-10-13 C154 Remove shifts field: does it mean only the masters Loom entry field, or the shifts column and every screen that uses it (movements/weft-issue shift pickers, capacity board) too?
  • A114 2026-10-13 Only the masters Loom entry/display: drop the Shifts select from LoomForm, the Shifts column + record-dialog field + tab description, the server validation and the builder read, and the fields-reference row. Keep the loom.shifts DB column (default 2) and the movements/weft-issue shift pickers and capacity board untouched — the data still drives those, and keeping the column is the reversible 80/20.
  • Q115 2026-10-13 C155 The row says 'the table of all masters' — does it mean only the /masters page tables, or also the Open links on other list screens (/tippans, /reconciliations)?
  • A115 2026-10-13 Only the /masters page tables (all 7 tabs). 'All masters' means every master tab; /tippans and /reconciliations are not master tables and keep their Open links.
  • Q116 2026-10-14 C156 Only the phone layout is named: should the desktop warp/weft table also change shape, or is the change mobile-only?
  • A116 2026-10-14 Mobile-only: render one stacked card per warp/weft row below the sm breakpoint (640px) and keep the existing table at sm+; the modal already becomes a full-width bottom sheet on phones, so the grid is the only wide element. Keeps desktop density, fewest surprises, reversible (drop the breakpoint classes).
  • Q117 2026-10-14 C157 C157 says the permissible count drop down has to be searchable — should search REPLACE the multi-select checkbox picker with a single-pick Combobox, or filter the existing multi-select list, and is there a minimum query length?
  • A117 2026-10-14 Keep the C152 multi-select (checkboxes + removable tags): the field stores a list. Add a search box inside the dropdown that filters the count list as you type; empty query shows all. No minimum length — counts are 2-3 digits and a short list should narrow on the first character.
  • Q118 2026-10-14 C158 Does 'Remove mode from design master' mean drop the mode_pref column entirely, or remove only the visible Mode field from the master (form/table/validation/builder) while keeping the column + BOTH default so the sales-order mode prefill (orders/[id] reads design.modePref) keeps working?
  • A118 2026-10-14 Remove only the visible Mode field from the design master: the form select, client + server validation, the record-detail field row, the table column, and buildDesignValues. Keep the design.mode_pref column and its BOTH default (no migration) so the sales-order mode prefill at src/routes/orders/[id]/+page.server.ts:229 is untouched — fewest files, reversible, preserves existing orders behaviour. New designs default to BOTH exactly as the old blank submit did.
  • Q119 2026-10-15 C159 SvelteKit 3 migration: which readings? (a) official @sveltejs/adapter-bun vs keep community svelte-adapter-bun; (b) rewrite deprecated json()/text() or leave them; (c) add .js extensions to #lib imports
  • A119 2026-10-15 Q119/A119 (a) switch to official @sveltejs/adapter-bun: the community 1.0.1 peers Kit 2 and uses the removed Kit-3 Adapter API, so it cannot build; output build/index.js is identical so the service unit is untouched. Q120/A120 (b) keep json()/text() — deprecated, not removed in 3.1.0, so leave byte-identical (fewest files, zero behaviour change, reversible). (c) add .js extensions to every #lib path (official migrator convention; Vite/TS map them to the .ts sources).
  • Q120 2026-10-17 C161 No acceptance recorded and the wording is bare: does 'new trading SO button showing 500 error' mean the Trading SO form's own Save/check-and-save flow, or a different control? The page's GET is 200 for every role/param tried; the only 500 in its flow is the post-save read-back GET /api/orders/[id].
  • A120 2026-10-17 The Trading SO page GET renders 200 for owner/sales/planner/accounts/production and for junk query params, so the page itself is not throwing; the only 500 in the form's own flow is the C157 post-save read-back GET /api/orders/[id], which 500s on every call because it selects the non-existent order.quality column. Fix that endpoint, keep its response shape, touch one file.
  • Q121 2026-10-17 C162 For C162, is the 'last used RS' the latest quote saved for that quality (design_id), and should it override the quality master only when it differs so the summary's 'edited' badge stays honest?
  • A121 2026-10-17 Yes — the latest quote for the design (newest created_at whose inputs_json carries it); carry it as an adjustment only when it differs from the design master, else fall through to the master. No new field, so no new validation.
  • Q122 2026-10-17 C163 For the quote wizard's job-rate field, should it prefill from the last used job rate for the quality (falling back to the design master), or keep the master only?
  • A122 2026-10-17 Last used job rate for the quality wins, design master as fallback — matches the owner's wording and C162's reed-space pattern.
  • Q123 2026-10-17 C164 Does 'warp sizing rate should prefill from the yarn master' override a sizing rate the row already carries from quote/design history, and should the prefill follow a count changed in the warp popup?
  • A123 2026-10-17 Keep the existing precedence: a sizing rate already carried by the row (last quote / design master) wins, and a rate the user typed is never overwritten. The yarn master fills a blank row and re-prefills when the row's count is changed to another master count (tracked as an auto-filled value), so the warp popup's count is the trigger. Missing master count clears only a rate this prefill wrote.
  • Q124 2026-10-17 C165 Quality with multiple warp/weft: which carrier counts — a legacy warp_count/weft_count string joined with '+' (e.g. 34+30SLUB), or the design's warp_rows/weft_rows JSON grid rows?
  • A124 2026-10-17 The JSON grid rows already prefill every row (proved: the quote wizard's designData and edit resolveQuoteInput both render all warp_rows/weft_rows entries), so the only quality master that still loses a second warp/weft is a legacy count string, which joins counts with '+' (25 designs: 34+30SLUB, 20S+20S Lycra, 40/1+40Lycra ...). Split masterCountRows on '+' into one row per count, sharing 100% evenly like the design grid — the user confirms every auto-filled field.
  • Q125 2026-10-17 C166 Does 'remove sizing GST field' mean only the new-quote wizard summary (/quote → /quote/new, where the 'Warp n siz GST' tap-row sits), or also the per-warp 'Siz GST %' input on /quote/edit's warp rows?
  • A125 2026-10-17 Only the /quote (new-quote wizard) surface the correction names — remove the 'Warp n siz GST' tap-row from NewSummary.svelte and drop the sizGst branch from the wizard's openYarnField, keeping the stored sizGst value (yarn-master prefill + costing) untouched and /quote/edit's per-warp Siz GST input as-is, since the row targets /quote alone. Fewest files, reversible.
  • Q126 2026-10-17 C167 C167 says 'Remove mill/ticket' on /tippans/new. The only mill/ticket there is the tippan's yarn-issue mill field (yMill) — hidden from the wizard since C115 but still carried in the hidden POST form and read by the create action. Does the row mean remove that entry field only, or also drop the stored mill from the tippan's yarn issue (record + print)?
  • A126 2026-10-17 Remove the mill/ticket entry field from the new-tippan surface only — the yMill page state, hidden POST input, TippanWizard prop/binding, the gatepass ticket carry, the PREFILLABLE entry and the create action's raw(fd,'yMill') read. Keep the tippan's stored mill derived from the assigned yarn/gatepass (r.issue.mill || gpRow.ticket), so the record, print and every existing row are byte-identical. Fewest files, reversible, matches C168 (mill/ticket arrives from the new master, never typed on the tippan).
  • Q127 2026-10-17 C168 C168 says 'create a new master of ticket/mill' whose entries 'come from the rate board' and auto-update, and that fetching yarn shows 'all permutations of yarn and mills'. Is the master a NEW table/tab, or a derived projection of the rate board, and which rate column is the mill source?
  • A127 2026-10-17 Derive, don't create a second entity (mirrors C160's weave sub-master): the mill/ticket master is the distinct rate-board 'ticket' values, de-duped case-insensitively (first spelling canonical) and sorted, projected live from the rate table — no new table/tab/migration, and a new rate ticket auto-appears with no extra entry. Source = rate.ticket, because the yarn master's own field is 'ticket' and matchBoardRate already pairs yarn.ticket with rate.ticket. Consumed as a pick-or-type datalist on the yarn master's Ticket/mill field, so any count+type shows every mill available (the permutations). Fewest files, reversible, keeps stored yarns untouched.
  • Q128 2026-10-17 C169 ?tippans/new has no weave field (weave comes from the picked design); the only weave input is the design master's form. Is the row's surface the design master, and should the weave master be a sub-master panel on the design tab or a separate masters tab?
  • A128 2026-10-17 Design master is the surface (the /tippans/new target is the C143–C157 batch mislabel); keep the weave master as a read-only sub-master panel on the design tab (C160's 'sub-master of design master, never a separate tab'), not a new tab.
  • Q129 2026-10-18 C171 When a market dhara is tapped, should its brokerage prefill overwrite a brokerage already prefilled from the direct-order convention or order history, or only an empty field? (also: do history/quote dhara carries trigger the mapping, or only an explicit dhara tap?)
  • A129 2026-10-18 Explicit dhara tap only, and it overrides a non-touched earlier prefill (direct convention / history / quote): the row says 'when the dhara is selected, prefill X', and a value the user typed (touched) is never overwritten. A dhara carried by history/quote is left alone — it already carries its own brokerage. Case/space-insensitive name match, closed map so an unmapped dhara (Job Dhara, new market) leaves brokerage as-is.
  • Q130 2026-10-18 C174 The same inherited-property sort 500 (SORT_COLS[rawSort] truthy for proto/constructor/toString) exists on the nine sibling list pages (hishob, bookings, tippans, gatepasses, lots, beams, samples, drafts). Fix just the reported orders page, or all of them in this row?
  • A130 2026-10-18 Fix only the reported page (src/routes/orders/+page.server.ts): the row's target names one page, fewest files, reversible. The identical one-line guard on the sibling list pages is a separate, reversible follow-up, not this row's file.
  • Q131 2026-10-18 C175 Should the deliver window persist a start and an end date as new columns, or keep the field's existing integer dueDays as the one stored value with the two dates UI-only?
  • A131 2026-10-18 Keep dueDays as the one persisted value (the field the row targets); the start/end dates are a UI-only window over it, the start defaulting to the booking day already stored as orderDate. No new columns, no migration; a start past the end clamps to 0. Reversible, fewest files.
  • Q132 2026-10-18 C176 C176 says add button in mill/ticket master, but C168/§457 made that master a read-only projection of the rate board (no add form, never a table). Does the Add button only seed the rate board, or persist a manual mill somewhere?
  • A132 2026-10-18 Persist a small mill master table; the master is the UNION of the board's distinct rate.ticket values (C168's auto-entry) and the mills entered by hand, de-duped case-insensitively (board spelling wins on a case-only collision). The Add is insert-only (append-only UX: no edit/delete), name required, format-checked on both surfaces, and refused as a case-insensitive duplicate against either source — so neither the board nor the manual list can carry a second spelling. Reversible: drop the table + button + form and the master collapses back to the board projection. A hand-added mill has no rate, so it stays a reference entry: the quote popup still lists only board rows (which carry the rate).
  • Q133 2026-10-18 C177 C177 says add button in weave master, but C160/PLANNING §448 made that master a read-only projection of the design master's weave column (no add form, never a table). Does the Add button persist a manual weave somewhere?
  • A133 2026-10-18 Persist a small weave master table; the master is the UNION of the designs' distinct weave values (C160's auto-entry) and the weaves entered by hand, de-duped case-insensitively (design spelling wins on a case-only collision). The Add is insert-only (append-only UX: no edit/delete), name required and format-checked on both surfaces with the same WEAVE_RE the design Weave field uses, and refused as a case-insensitive duplicate against either source. Reversible: drop the table + button + form and the master collapses back to the design projection.
  • Q134 2026-10-18 C180 C148 removed the wizard source step (and its contract-copy OCR/dictation) from the Job Work SO; C180 requires OCR of the contract copy to prefill the ops fields on that same form. Do I restore OCR reachability on the JW form, and can I keep C148's no-quote/lead-picker decision?
  • A134 2026-10-18 Restore the source step for JW as a contract-copy READ only: wizardStepsFor keeps 'source' for SO and JW, JOB_SOURCE_STEP titles it 'Read the contract copy?' for JW, and OrderEntryForm hides the quote/lead picker block unless t==='SO'. Fewest files (orderLogic + OrderEntryForm), reversible (one filter, one gate), keeps C148's picker decision, and makes OCR/dictation reachable so fillFromDictation prefills the ops fields.
  • Q135 2026-10-18 C181 C148 removed the wizard source step (and its contract-copy OCR/dictation) from the Stock (Production) order; C181 requires OCR of the contract copy to prefill the ops fields on that same form. Do I restore OCR reachability on the PROD form, and can I keep C148's no-quote/lead-picker decision?
  • A135 2026-10-18 Restore the source step for PROD as a contract-copy READ only: wizardStepsFor keeps 'source' for SO, JW and PROD, the existing JOB_SOURCE_STEP titles it 'Read the contract copy?' for both non-trading kinds, and OrderEntryForm hides the quote/lead picker block unless t==='SO'. Fewest files (orderLogic + OrderEntryForm), reversible (one filter, one gate), keeps C148's picker decision, and makes OCR/dictation reachable so fillFromDictation prefills the ops fields.
  • Q136 2026-10-18 C182 C182 says ask loom width and panna FIRST in the wizard and the form. Does 'first' mean literally the first popup (ahead of the job-work source/contract-read step), and does the reorder also apply to the job-work-style OUTSOURCE form that shares these steps?
  • A136 2026-10-18 Yes — the loom width/panna popup is literally the first step of the job-work wizard (ahead of the contract-read source step) and loomWidth/panna lead the form's kind section. The OUTSOURCE form shares the same job-work wizard steps and ORDER_FIELD_SPEC, so it takes the same order; Trading SO and Production Order have no loom step/fields and are untouched (proven by the pure-logic check).
  • Q137 2026-10-18 C184 C184 'payment dhara field keep in the end' on /quote/new: does 'the end' mean the summary/full form's Payment dhara row (now the second section, after Enquiry) should move last, or the wizard's dhara step (already last among steps)? And should the wizard also skip the dhara step when C183 prefilled it (quoteCarry never sets dharaReady)?
  • A137 2026-10-18 The field the owner sees on the /quote/new form is the summary's 'Payment dhara' row; 'keep in the end' = make it the last section of the full form, after Construction, just above the actions. The wizard's dhara step is already last among steps, so it needs no reposition. The C183 prefill/skip wiring is C183's own scope, not touched here; fewest files (NewSummary.svelte), reversible (move the block back), no behaviour change.
  • Q138 2026-10-18 C185 Which screen is the 'second page of costing form' — the summary (phase=summary, shows no cost/weight) or the calc screen (phase=calc, the only place showing warp/weft cost and weight)?
  • A138 2026-10-18 The calc screen (NewCalc.svelte, phase='calc') is the 'second page of costing form' — it is the only screen that shows warp/weft cost and weight (the summary shows neither). Keep totals as-is and add a per-yarn breakdown when a side has more than one valid row.
  • Q139 2026-10-18 C186 C186's coins come 'from previous sale orders of the same quality' — the order table rows of type SO (real sales orders, design_id + metre qty), or the quote history the form itself already reads? And the 1000-mtr slot scroll: cap it at the server's own 1,000,000-mtr estQty limit, or run higher?
  • A139 2026-10-18 Pareto: the literal wording wins — coins are the order table's type='SO' rows for the same design_id with a positive metre qty (the real sales orders), read most-recent-first, de-duplicated, capped at four; the browser's last-used estimate is only the fallback. The quote history is not re-used because the row names sale ORDERS, and the two can disagree. The slot scroll is capped at the same 1,000,000-mtr ceiling the server already enforces on estQty, so the picker can never offer a value the save would reject; it is a scroll range only and a typed figure is still kept as typed.
  • Q140 2026-10-18 C187 The Delivery end coins are +10/+20/+30/+40 days (the list continues) — measured from today, or from the chosen Delivery start date? And how many steps does the trailing '+' mean?
  • A140 2026-10-18 Measure from the chosen Delivery start when one is set, else today: a delivery END is the close of its own start->end window, so start+N keeps every suggested end on or after its start (today+N can land before a later start). With no start it degrades to the same 'today + N' reading the wording implies. The trailing '+' continues the step of ten to +50 and +60 (six coins) — the window lengths the ladder names, bounded and reversible. Suggestions only: the date input and its existing isDate validation are untouched; the dStart coins are left as C105 shipped them.
  • Q141 2026-10-18 C188 Acceptance conflict: 'the list shows no fixture order number' vs 'none referenced is removed'. 196 of 344 fixture orders have linked children (evt/amendment/attachment/roll/dispatch). Leave referenced fixtures (list stays dirty) or purge parent + its linked children?
  • A141 2026-10-18 Purge the whole fixture subtree: delete the fixture order AND its linked child rows (evt/amendment/order_attachment/roll/dispatch_slip/lot...) in one transaction, after backing up data.db. A fixture parent's children are fixture too (verified: e2e-probe events, C111 ops-complete amendments, SO-E2E-2701 rolls/dispatch). Accepting 1 wins: the list must show only real orders; the protection clause is read as 'no referenced child is left dangling', not 'referenced fixtures stay'.
  • Q142 2026-10-18 C189 The correction hands over a DeepSeek API key — should it be committed to the repo so every checkout/deploy host inherits it, or kept only in the host .env?
  • A142 2026-10-18 Host .env only. The repo rule is 'never commit secrets', and the live checkout IS the deploy host (/root/trading), so editing .env here switches the live app; .env.example documents the endpoint + model with an empty key. Fewest files, reversible (old opencode-go values kept commented).
  • Q143 2026-10-18 C190 C190 rate scroll: what wheel range/step and how many quality-rate suggestion coins?
  • A143 2026-10-18 step 0.25, wheel 0-999 typeable (a higher rate is typed, not scrolled) like the leads/orders rate range; coins = up to 6 distinct recent order rates of the selected quality
  • Q144 2026-10-18 C193 C193 samples auto entry number: does 'shown at the top of the form' mean a new first summary section ("Sample") holding the read-only 'Sample no · Auto' row before 'From (context)', and should the value stay the neutral marker 'Auto' (as every other form's doc-number row) rather than a computed next number?
  • A144 2026-10-18 Yes — move the existing read-only 'Sample no' row (label 'Sample no', value 'Auto', note 'Auto on save — the next sample number') out of the 'Charge or waive' section to a new first section titled 'Sample', so it is the top of the form; keep the value 'Auto', exactly as the GP-no / Movement-no / Direct-delivery-no rows read on the other forms. Display-only: no field added, no POST name/schema/column/action moves, one file, reversible.
  • Q145 2026-10-18 C194 C194 wording 'REMOVE HISHOB AND ORDERS FROM ORDERS SECTION ... THESE ARE REPORT': the Orders group has no 'Orders' child (removed in C74), so which second item is meant, and where do the report links go after leaving Orders?
  • A145 2026-10-18 Read 'ORDERS' as the Reports link (both Hishob and Reports are reports; 'these are report[s]' names exactly those two). The Orders group's only non-order report entries are Hishob and Reports, so both leave Orders. Kept reachable by a new Reports group (same roles) so no screen is stranded — fewest files (one), reversible.
  • Q146 2026-10-18 C195 C195: what counts as 'already assigned' yarn, and does spreading one booking over several production orders change the cost ledger or which order is primary?
  • A146 2026-10-18 Already assigned = the net kg of open bookings already linked to that order, matched to a design warp/weft row by count+system+type and side (the only order-yarn link the app holds; date + mill ticket shown on expand). For several orders, the first stays the primary booking.orderId and keeps the one existing cost-basis link; the per-order bag split is stored additively (order_split) and no extra order touches the cost ledger — money left alone, fewest files, reversible.
  • Q147 2026-10-18 C196 For 'same yarn (COUNT+TYPE+MILL)', is the count SYSTEM (Ne/D/Tex) part of the identity, or only the numeric count + type + mill?
  • Q148 2026-10-18 C196 Does the same-yarn history matching apply to the other history-owned booking fields (supplier, broker, lot, payment term, rate), or only to cones per bag and bag wt?
  • A147 2026-10-18 Include the count system: identity = count|countSystem|typeCode|ticket. A yarn count is meaningless without its system (61 Ne != 61 D), so the system is part of the standard count format; it never splits a real duplicate in practice and is trivially reversible.
  • A148 2026-10-18 Cones per bag and bag wt only (this row). They are physical packaging properties of the yarn, so they follow the yarn identity; supplier/broker/rate/lot are commercial and stay keyed to the exact master row (rate's own same-yarn suggestion is C197's row). Fewest-change, reversible.
  • Q149 2026-10-18 C197 The correction gives no rate-wheel range or typed-value rule. Is a single 0-999 wheel stepping 0.25 (mirroring the FOCUS-ENTRY rate mode) right, or must the old 0-4999.99 reach survive, and may a typed rate still be any value?
  • A149 2026-10-18 Mirror the documented FOCUS-ENTRY rate mode: one wheel 0-999, step 0.25 (max booking rate on live data is 450, so 999 is ample); typed values stay as typed (NumberWheel's contract), only the scroll snaps to 0.25 slots.
  • Q150 2026-10-18 C197 Should the rate auto-prefill also move to the count+type+mill identity, or only the suggestion coins the correction names?
  • A150 2026-10-18 Only the suggestion coins move to identity matching (the correction names the coins); the auto-prefill keeps its existing board-then-exact-last order, unchanged bytes.
  • Q151 2026-10-18 C198 Does 'terms and papers except rate and yarn booking allocation' and 'system date need not be shown' mean the wizard steps only, the whole summary form, or both — and should the read-only system date be dropped?
  • A151 2026-10-18 Both faces (the ONE ORDER_FIELD_SPEC drives the summary and the wizard), and keep the system date as the C135 read-only top row — never an input, never dropped. Fewest files, reversible, no field/value/POST change.
  • Q152 2026-10-18 C199 job-work reorder: (a) does 'loom width (only one field, form showing 2 fields)' mean retire the legacy loomType class and keep the master-driven loomWidth? (b) should the derived rate (jobRate x picks) stay on the job-work summary/wizard since the owner's list names only picks + job rate? (c) do the removals (city, sales promise, broker/weaver confirmation) and the reorder also apply to the legacy OUTSOURCE form, or JW only?
  • A152 2026-10-18 Pareto-safe reading: (a) keep the master-driven loomWidth (C146/C182) and retire the duplicate legacy loomType from job work; (b) keep the derived rate field/wizard step — it is not in the owner's explicit remove list and C142 makes it an editable auto value; (c) apply the reorder+removals to JW only and leave the legacy OUTSOURCE form untouched — fewest files, keep existing behaviour, reversible.
  • Q153 2026-10-18 C200 C200 job-work 'Link a capture draft' is unresponsive: which upload should the field offer, and where should it show? Today it sits inside the OUTSOURCE-only contractFile block (so it vanished on the job-work form) and its only control is a select of existing capture drafts.
  • A153 2026-10-18 Show 'Link a capture draft' wherever the kind carries sourceDraftId (JW + OUTSOURCE), decoupled from contractFile. Add an upload beside it that posts to /api/capture-ocr, so a real capture DRAFT is written and instantly linked (sourceDraftId) — the field's literal job; party/quality prefill from the read's resolved masters, and the wizard's existing order-OCR upload stays the full field-prefill path. One file, reversible.
  • Q154 2026-10-18 C201 C201 own firm on /bookings/new: is 'own party type' the party master category 'OwnUnit' (not the isOwnUnit flag), and should the new own-firm field be required on every booking or optional?
  • A154 2026-10-18 Safe 80/20: 'own party type' = party.category 'OwnUnit' (the category IS the type; the isOwnUnit flag is a separate boolean and both live OwnUnit rows carry category OwnUnit). The own-firm field is OPTIONAL (blank allowed), and when present it is validated to be an OwnUnit party name from the master; stored as a new nullable booking.firm_name text column. Optional keeps every existing/draft/carried booking saveable and is reversible.
  • Q155 2026-10-18 C192 Should the removed purpose field also stop being written from the capture-draft confirmation path and the schema purpose column be dropped?
  • A155 2026-10-18 No — remove the field from /samples only (form, prefill and create action). The capture-draft insert keeps writing purpose from the slip and the nullable schema column stays, so existing rows and captured text are untouched; dropping the column would be irreversible.
  • Q156 2026-10-18 C203 Which L2L should prefill a new quote for a quality: the last quote's L2L for that design, or only a quote whose order was actually finished? L2L is not stored on order rows, only on design master + quote inputs_json.
  • A156 2026-10-18 Use the last quote's L2L for that design (the existing lastQuoteRows source) — it is the most recent actual value used for the same quality. 'Finished order' cannot be read separately because L2L lives only on design master + quote inputs_json, never on order rows.
  • Q157 2026-10-18 C206 After creating a missing buyer/broker from the picker popup, should the new row be auto-selected and the wizard continue, or only be added to masters for a manual pick?
  • A157 2026-10-18 Auto-select the just-created row. For a buyer the wizard continues exactly like a normal pick (onParty + next); for a broker the step stays (same as a broker coin). Fewest taps, reversible by clearing the pick.
  • Q158 2026-10-18 C209 Trader's booking no + booking date on /bookings/new: required or optional, and should booking date default to the system date?
  • A158 2026-10-18 Required
  • Q159 2026-10-18 C211 "create a guard login": is this an owner-only screen that creates staff logins with a role (durable), or a one-off seeded guard account?
  • A159 2026-10-18 Owner-only /users screen that creates a login (name+email+password+role); guard is a role option. Generalises to any staff login and is reversible; a seeded account would not be reproducible by the owner.
  • Q160 2026-10-18 C215 Does 'form name' include the sidebar nav 'Yarn in' and the generic h1 'New gatepass', or just the YARN_IN form's kind label?
  • A160 2026-10-18 Rename only the YARN_IN form's kind label (badge, list dropdown, FocusEntry title); leave the generic h1 'New gatepass' and the sidebar nav entry untouched — the row targets the form and C216/C218 handle the header and the kind chip.
  • Q161 2026-10-18 C216 Should the top show the intimation number as the doc-no shape (GP-YYMMDD-XXXX) or the plain 'Auto' marker, and should 'system date' be the server system date or the client's today?
  • A161 2026-10-18 Doc-no shape (GP-YYMMDD-XXXX) + server system date: mirrors the DIRECT top strip and booking C209 'system no + system date' pattern the same owner asked for; server date avoids browser-clock drift; fewest files, reversible.
  • Q162 2026-10-18 C217 The row lists 'remarks' but the YARN_IN form has no remark row (only the separate dictation field). Should remarks be a new optional free-text field, and does the 1-6 order cover only those six rows (the optional uploads section stays after them)?
  • A162 2026-10-18 Read 'remarks' as a NEW optional free-text Remark row (not the dictation field): add it last, trim, max 200 chars on both surfaces, persisted on the append-only creation event payload (no migration, mirroring dictateText/confirmPhoto). Apply the 1-6 order to the six named entry rows only; keep Kind/system-date static meta and leave the optional uploads section after them. Reason: fewest files, reversible, keeps existing behaviour for every other kind.
  • Q163 2026-10-18 C218 "remove kind" on /gatepasses/new?kind=YARN_IN: does it mean only the Kind row/chip in the form (plus its saved-summary line), or also the top-right kind badge + direction marker + the hidden POST marker?
  • A163 2026-10-18 Only the Kind row/chip in the form (and its after-save summary line) goes; the top-right badge stays because C215 made it the form's name, and the hidden POST kind/direction markers stay because resolveKind + the record still need them. Fewest files, reversible, no other kind touched.
  • Q164 2026-10-18 C219 C219 'waive amount not needed' on /samples: a complete waive has no amount, so which approval path — auto-approve the user's tap (like the old ≤₹1000 branch), or still route every complete waive to the owner even without an amount?
  • A164 2026-10-18 Auto-approve the user's tap: with no amount the existing >₹1000 owner gate cannot be evaluated, and the old ≤₹1000 branch was already a user tap. Store waiverAmt=0, waiverBy/waiverApprovedBy='user'; keeps approvals/queue/board untouched and is reversible. Fewest files.
  • Q165 2026-10-18 C220 Does removing the Rate source row also drop the stored rateFromOrder provenance flag?
  • A165 2026-10-18 No — remove only the visible Rate source row; the hidden rateFromOrder input and the stored column stay (existing behaviour/data, one file, reversible).
  • Q166 2026-10-18 C221 Does 'Remove from context complete section' mean remove the entire 'From (context)' block on /samples — the From lead picker, the From order picker AND the read-only Capture draft row — plus the now-unreachable lead/order prefill plumbing and its server queries? Or keep the Capture draft indicator?
  • A166 2026-10-18 Remove the whole 'From (context)' section (all three rows) and its now-unreachable lead/order picker plumbing + server queries. Keep the draftId hidden POST and the query-param prefill, so the capture-draft save path is byte-identical — only the visible reminder goes. Fewest files (samples page + server), reversible.
  • Q167 2026-10-18 C222 Scope: the rate wheel bug lives in the shared NumberWheel typeable input; fix it once in the shared component (all typeable wheels) or only the rate instance?
  • A167 2026-10-18 Fix in the shared NumberWheel: same defect for every typeable wheel (rate, qty, money), fewest files, reversible; no per-instance fork. The rate target /bookings/new uses the shared component.
  • Q168 2026-10-18 C223 C223 says 'pass on field as 1' for a direct order, but the existing C101 convention prefilled pass-on 100% ('the entire brokerage passed on'). Which pass-on value should a direct order prefill/store: 1% or 100%?
  • A168 2026-10-18 1% — C223 names 1 explicitly, and C173's own pass-on wheel (coins 0.5%/2%) shows pass-on is an absolute %, not a % of brokerage, so a direct order is brokerage 1% + pass-on 1%. Change the C101 convention from pass-on 100 to 1 on both surfaces and set the server defaults to 1.
  • Q169 2026-10-18 C225 C225 names two field sets 'for the sales user' and 'for production user' on the same /orders/new/trading form - does the form require a different compulsory set by the logged-in user's role, or are all listed fields required for every user?
  • A169 2026-10-18 Role-based: a 'production' user saves the Trading SO with the production set (Buyer's order no, Send as, Mtr per roll, Rolls); a 'sales' user saves with the sales set (Quality, Rate, Picks, Quantity, We must deliver in days, Payment dhara, Cd, Brokerage %, Pass on %). Buyer stays buyer-or-broker (the C250 broker-only booking), and every other role/kind is unchanged - the owner named exactly those two roles.
  • Q170 2026-10-18 C226 Remove fields 'Sales promise' and 'Send to city' on /orders/new/trading: do they leave the Trading SO only (the target form), or every form that carries them including the Stock (Production) order? And does 'move we must deliver in days to the place of sales promise' mean the summary/terms position?
  • A170 2026-10-18 Trading SO only: the correction names /orders/new/trading, so 'dispatchCity' and 'promisedDays' leave the SO spec (kinds become ['PROD']) and stay on the Production order untouched; dueDays moves from the Quantity & delivery section to the Terms & papers slot the sales promise occupied (terms/order 30), matching the section form which already renders it under Price. Fewest files, reversible, existing records untouched.
  • Q171 2026-10-18 C227 Does 'Booking no.' mean the buyer's booking/order number already stored as partyContractNo ("Buyer's order no"), or the yarn booking (cost-basis picker, costBookingId)? And is it the Trading SO wizard step right after the OCR/source step?
  • A171 2026-10-18 The buyer's booking/order number = the existing partyContractNo field ("Buyer's order no"), surfaced as a Trading SO wizard step immediately after the OCR/source step; the yarn cost-basis booking (costBookingId) is a different, optional field and is left as it is. Fewest files, reversible, no new column.
  • Q172 2026-10-19 C228 Does the 0.25 increment apply to the wizard rate wheel only, or also to the desktop Price section rate input and the operations rate wheel on the order page?
  • A172 2026-10-19 Wizard rate wheel only: the complaint is the new-order wizard scroll (it stepped 1 and floored typed decimals); the section input already accepts any decimal and the ops popup wheel is a different screen left unchanged. Fewest files, reversible.
  • Q173 2026-10-19 C229 Does 'rate field 2 decimal points' mean the trading order rate should display/store at two decimals (rounding extra decimals), or reject entries with more than two decimals?
  • A173 2026-10-19 Display and store two decimal points: normalise typed and prefilled rates to 2 dp on the trading order form and round the server-side rate to 2 dp. Empty stays empty; non-numeric input still fails validation. Reversible, no rejection.
  • Q174 2026-10-19 C230 Does the picks step-by-1 apply to the trading SO wizard's ± stepper only (job work keeps C142's bare input), and are the existing C142 suggestion coins (same quality + party first, quality-only fallback) enough for the 'suggestions' half of the row?
  • A174 2026-10-19 Trading SO/PROD wizard picks ± steps by 1; job work keeps its C142 bare picks input and its job-rate × picks maths unchanged (safer, fewer files). Keep the C142 suggestion ladder exactly as it ships — same quality + party first, that quality alone as fallback — because the row asks for suggestions from the same quality + party and the fallback only appears when the pair has no history.
  • Q175 2026-10-19 C231 C231 'have not expired': leads carry no validity field — does it mean anything beyond excluding lost/converted leads?
  • A175 2026-10-19 Leads: exclude any lead that already has a quote, a convertedOrderId, or a non-open status. Quotes: exclude validity before now and any quote already linked to an order. Fewest files, reversible.
  • Q176 2026-10-19 C231 C231: should the trading wizard's source step also become the two-tab historic table, or only the full form's two dropdowns?
  • A176 2026-10-19 Both surfaces use the same one-field two-tab historic table, so the trading SO has one picker pattern; the wizard keeps its dictation/OCR above it.
  • Q177 2026-10-19 C232 Where should the lead/quote picker land after leaving the OCR wizard screen: a new wizard step right after the OCR step, or the form's Kind section behind the wizard (where the same picker already exists)?
  • A177 2026-10-19 A new wizard step immediately after the OCR step (sourceLink), trading-SO only. 'Next screen' reads literally: the screen right after the upload reads the slip, the next screen links a lead/quote. The same picker stays in the form's Kind section too, so either path works.
  • Q178 2026-10-19 C234 Does the +/- 0.25% stepper apply only to the wizard pass-on scroll, or also to the summary popup's plain pass-on input and the 0.5%/2% coins?
  • A178 2026-10-19 Wizard pass-on scroll only. Mirror C233's brokerage stepper: keep the 0.5%/2% coins and the summary popup's plain input as they are (fewest files, reversible, matches the row's target = the scroll).
  • Q179 2026-10-19 C236 C236's target is /orders/new/production-order (PROD), whose A4b spec (C179) has no buyer/rate/payment. Do we re-adopt the A4b commercial block on the production order and require the owner's sales/production sets there?
  • A179 2026-10-19 Yes: the target IS the Production Order (Stock) route; the owner's staged reading supersedes C179, so PROD re-adopts the sales commercial block and the sales/production required sets apply by role.
  • Q180 2026-10-19 C238 Does the Rolls/Lumps rename apply only to the Trading SO or everywhere the shared rolls field is asked?
  • A180 2026-10-19 One shared ORDER_FIELD_SPEC label, so trading, job-work and stock-production entry all read Rolls/Lumps; the production-completion wizard's own label is left as-is (fewest files, reversible).
  • Q181 2026-10-19 C242 Which exact short words for the table's Status column (currently full phrases like 'waiting for owner approval'), and which progress fact should lead the Progress cell?
  • A181 2026-10-19 Take the safe 80/20: short badge words Open / In Prod / Delivered / Closed / Pending / Confirmed / Cancelled, and the Progress cell leads with one abbreviated fact (rolls count + the sent/ready metres), full detail stays in the row popup.
  • Q182 2026-10-19 C243 Does 'remove from the horizontal scroll' remove only the Open link, or the whole trailing actions column (Open/Complete, Reuse, Requote)?
  • A182 2026-10-19 Remove the whole trailing actions column on every orders table tab. Every one of those destinations already lives in the row popup (dialogActions: Open full record / Complete operations, Reuse, Requote), so nothing is lost and the column no longer forces a sideways swipe.
  • Q183 2026-10-19 C244 The picker is empty because the live data has no 'open' leads (all are auto-lost) and its 2 open quotes are past their printed validity, while the Leads screen still lists lost leads and the Quote screen still lists those open quotes. Should the picker match those list screens (offer lost leads and open quotes past validity), or keep only strictly-open records and show an empty state?
  • A183 2026-10-19 Match the list screens, because the owner's report is that rows he sees as open are missing. Offer lost leads (the Leads default pipeline lists them until converted) and quotes in open/approved/draft/sent with no generated SO, regardless of a printed validity date (the lists treat status as the arbiter and auto-expire). Update the create action to accept the same set, so a shown row never fails on save. Fewest files, reversible.
  • Q184 2026-10-19 C245 which picks surface does 'picks field to change by 1 with +/- button' mean — the wizard 'How many picks?' step or the background Price section input; and do the quality coins already satisfy 'suggestion coins based on previous SO of the same quality'?
  • A184 2026-10-19 Both faces are the same field, so give the background Price-section picks input the same ±1 stepper the wizard step already has (non-job-work only; job work keeps its bare input and rate = jobRate × picks). The coins were already widened to the quality alone by C239, so no coin change is needed.
  • Q185 2026-10-19 C246 C246 asks for separate class and type masters, while the queued C247 asks for one combined loom type master (width + type). Should C246 create two separate reference masters now, or go straight to the combined master?
  • A185 2026-10-19 Implement C246 literally as two separate insert-only reference masters (loom class + loom type) now; C247 will consolidate them into one combined loom type master later. Keeps the two rows independent and reversible.
  • Q186 2026-10-19 C247 C247 wants one combined loom type master (width + type), but C246 just shipped separate Loom class and Loom type masters. Should the separate Loom class master/tab be removed, or kept as the width source for the combined master?
  • A186 2026-10-19 Keep the Loom class master and its tab as the width source; the Loom type tab becomes the combined width+type master and the loom form gets one Loom type select. No table/data is dropped, fewest files, reversible.
  • Q187 2026-10-19 C248 Does 'loom type' mean the job-work loom width (loomWidth) field, and should panna fall back to the old quality+party history when that width has no prior panna?
  • A187 2026-10-19 Yes: on job-work the visible loom field is loomWidth (C199), so panna keys off quality + loomWidth across parties; when no width is chosen yet, keep the old quality+party panna as the fallback so existing behaviour is preserved.
  • Q188 2026-10-19 C250 For which order kinds does Fill details open a production wizard, and which wording/placement should the secondary status use?
  • A188 2026-10-19 Pareto reading: SO opens /production/trading, OUTSOURCE opens /production/job-commercial (it carries every field the pending check looks at), PROD opens /production/production-order; JW has no production screen in PRODUCTION_TYPES, so it opens the order record's own operations wizard (/orders/#operations). The secondary status reads 'Details pending' in a chip beside the workflow Status (a separate Ops column on the compact job-work table, which has no Status column), and only role === 'production' gets Fill details and loses the New button.
  • Q189 2026-10-19 C251 Role-scoped order entry: does the visibility filter apply to the whole new-order form (summary + section form) or only the wizard carousel, and are the universal core fields (buyer, qty, type, system date, remark) shown to both roles?
  • A189 2026-10-19 Apply C251 visibility on BOTH faces of the new-order form (check-and-save summary + background/section form) plus the wizard, driven by one role-aware ORDER_FIELD_SPEC: sales sees the sales fields, production sees the four physical fields (buyer order no, send as, mtr/roll, rolls). Treat buyer, qty, kind/status, system date and remark as universal core fields shown to both roles (qty is already always required and buyer is the existing buyer-or-broker rule), so each role can still book. A role-hidden field keeps any carried value because it is posted by a hidden input. Production role's compulsory set is the same four physical fields on SO, JW and PROD; sales sets unchanged; other roles and kinds untouched.
  • Q190 2026-10-19 C252 On the four production screens, which fields belong to sales vs production, and should production keep the fields these screens exist to complete?
  • A190 2026-10-19 Production keeps the completion mandate fields (partyContractNo, job rate/picks, terms/T&Cs, loom/beams/tolerance/gatepass, stock, cut size/rolls/send-as); sales keeps the commercial booking fields (rate, cash discount, payment days, due/promise days, brokerage, pass-on, send-to city). Hidden fields carry via the always-posted hidden form; owner/planner and other roles are unchanged.
  • Q191 2026-10-19 C253 Does the job-work rate-per-metre field stay on the background Price section as a derived (read-only) value, or does it leave the form too; and does the derived ÷100 formula also apply to the legacy OUTSOURCE form?
  • A191 2026-10-19 Keep the field on the background Price section as a derived read-only value (C254 later refers to its position in the form, so it stays visible); the wizard no longer asks it. Apply the ÷100 formula to the shared job-work maths (JW + legacy OUTSOURCE, per docs/COSTING §3) but scope the wizard-step removal and read-only rendering to JW only, leaving the legacy OUTSOURCE form otherwise untouched.
  • Q192 2026-10-19 C254 Does 'switch the positions' mean swap only the job-rate and rate-per-metre blocks (leaving Picks between, so the Price section becomes rate → picks → job rate and matches the summary spec), or should Picks move as well?
  • A192 2026-10-19 Swap only the two named blocks and keep Picks in the middle: the Price section reads rate per metre → picks → job rate per pick, which is exactly the ORDER_FIELD_SPEC party order the check-and-save summary already uses. Fewest files, reversible, and the shared component keeps OUTSOURCE consistent with its own summary.
  • Q193 2026-10-19 C255 Does "at the end in terms" mean move the Beams: whose? field to the end of the Price/terms section on the job-work form (rather than keep it in Order & source)?
  • A193 2026-10-19 Yes — move Beams: whose? out of Order & source and to the end of the Terms section; value, POST name and validation unchanged.
  • Q194 2026-10-19 C256 The JW table spec lists seven columns but not the C250 Ops 'Details pending' marker — drop it or keep it, and does 'job rate' mean order.jobRate (₹/pick) rather than the derived ₹/m rate?
  • A194 2026-10-19 Keep the C250 Ops marker at the end (losing a prior owner feature is the riskier reading); show jobRate as ₹/pick because the row explicitly says 'job rate' and C254/C253 treat job rate and rate/m as different values. Mtr/beam = the order qty with its own unit.
  • Q195 2026-10-19 C257 C257: most live JW orders have no mobile on the party master, so C153's chat/share render disabled. Should the buttons open WhatsApp's contact picker when no number is on file, or stay disabled?
  • A195 2026-10-19 Open WhatsApp's own contact picker (wa.me/?text=) for both buttons when no number is on file; a known mobile still goes straight to that chat. Nothing is sent automatically; the party master stays the source of truth. Fewest files, reversible, no schema.
  • Q196 2026-10-19 C261 On the All-orders tab (no type filter), should the per-form draft offers all still show, or does the draft offer appear only on its own kind tab?
  • A196 2026-10-19 Keep the All tab showing every draft offer (existing behaviour); a kind tab (e.g. ?type=JW) now shows only its own form's draft. Fewest files, reversible.
  • Q197 2026-10-19 C262 Target says /orders?type=JW but the job rate is only entered (not editable) in the job-work order form. Confirm the +/-0.25 stepper and same-quality suggestions go on the job rate field in the order form (popup + wizard), not on the read-only list?
  • A197 2026-10-19 Put it on the job rate field in the job-work order form (popup + wizard), because the list only displays job rate (append-only, no edit surface). Same ±0.25 stepper and quality-only history coins as C260's picks control. Keeps the list read-only, fewest files, reversible.
  • Q198 2026-10-19 C264 The four order forms share one draft mechanism keyed order-new-draft[-TYPE]; the generic OUTSOURCE form (null fixedType) keys order-new-draft but had no draft offer. Should the OUTSOURCE draft be offered as a fourth entry, and on the All tab keep showing every form's draft?
  • A198 2026-10-19 Add the fourth draft offer for the generic OUTSOURCE form (key order-new-draft, type OUTSOURCE, href /orders/new?type=OUTSOURCE); keep the existing tab filter so each kind tab shows only its own draft and the All tab keeps all four. Client-side on data.fType — fewest files, reversible, no server/DB change, no new field so no new validation.
  • Q199 2026-10-19 C265 does the removal also apply to the OUTSOURCE operations/production face (PRODUCTION_OP_FIELD_SPEC + ProductionOpForm), or only the /orders/new?type=OUTSOURCE booking form?
  • A199 2026-10-19 only the booking form named by the row; the operations face keeps its fields so a past OUTSOURCE order's booked T&C/gatepass stays visible and append-only, and no other screen changes
  • Q200 2026-10-19 C266 C266 asks to move 'Beams: whose?' to the end of terms on the OUTSOURCE form; C255 already moved the shared beamsSource field to the last slot of the Terms section for both JW and OUTSOURCE. Does C266 need a further move (e.g. inside the Outsource terms block), or is the C255 position the intended end?
  • A200 2026-10-19 The C255 position is the intended end: beamsSource stays the last field of the Terms (Price) section, after the Outsource terms block. OUTSOURCE shares ORDER_FIELD_SPEC and OrderEntryForm.svelte with JW, so C255 already satisfies C266; keep the same POST name, options and validation with no further move.
  • Q201 2026-10-19 C267 Does 'make outsourced form UI same as job work order form' include treating the OUTSOURCE kind as fixed (no kind picker) and keeping the party field as 'Buyer', changing only the order-no label to Weaver's order no?
  • A201 2026-10-19 Yes: OUTSOURCE renders the job-work form with its kind fixed by the URL (no kind picker, same title/wizard/spec), and only the party's order-no label changes to Weaver's order no; the party stays the existing buyer/weaver picker because the row names only the order no.
  • Q202 2026-10-19 C270 After removing quote/lead/broker/buyer-order-no/booking-date from the production-order form, should a ?quoteId=/ ?leadId= deep link still post the reference, and should a production-role create still require the buyer's order no?
  • A202 2026-10-19 No and no. A field removed from the form must not ride back as an invisible hidden POST, so the quote/lead hidden inputs are gated by shows() and the removed names are in PROD_DROPPED; and a production-role create must not demand a field the form no longer shows, so the PROD production-required set drops partyContractNo while the order-record completion keeps requiring all four via TRADING_PRODUCTION_REQUIRED. Fewest files, reversible.
  • Q203 2026-10-19 C271 Does 'remove panna from the wizard' keep the panna field editable (its own summary popup) or remove it from the job-work order form entirely?
  • A203 2026-10-19 Keep the field; remove only the wizard step. A field the wizard stops asking stays editable in its own single-field summary popup (FOCUS-ENTRY §4b), and the hidden form still posts panna exactly as before.
  • Q204 2026-10-19 C272 Does 'remove loom class master' mean drop the loom_class table and its stored data, or retire only the master tab/form and keep the loom_class column values already on looms (beams/board still read them)?
  • A204 2026-10-19 Retire only the Loom class master UI/form/action; keep the loom_class table, the loom.loomClass column and every stored value (beams, board and print still read it). Dropping data is irreversible and the row is about the master surface, not the spine.
  • Q205 2026-10-19 C273 C273: does the first-popup OCR/dictation fill only the trader's booking no., or every booking field the slip/note carries?
  • A205 2026-10-19 Fill every booking field the read understands (trader no/date, party/broker, product, bags, cones, bag wt, rate, lot, payment term, remark) as prefill only; nothing auto-saves, and the existing form validation + check-and-save gate still decide what is stored.
  • Q206 2026-10-19 C274 Should the booking wizard keep opening by default with a Start the wizard button appearing only after it is closed, or should /bookings/new open on the summary with the button always shown?
  • A206 2026-10-19 Keep the signed FOCUS-ENTRY lifecycle: the wizard still opens by default, and the header shows Start the wizard only once it is closed, exactly as the order form does (C141). It reopens at the first popup (the trader-slip capture step).
  • Q207 2026-10-19 C275 Is the delivery end date a new stored booking field or derived from start+interval?
  • Q208 2026-10-19 C275 How should bags per interval be divided across the period by default?
  • Q209 2026-10-19 C275 Is the delivery end date required whenever a delivery interval and bags per interval are set?
  • A207 2026-10-19 Store it as a new optional booking column delivery_end (ms date); blank keeps every existing row and save path unchanged.
  • A208 2026-10-19 Deliveries = floor((end-start)/interval)+1 (both ends inclusive); suggest ceil(total bags/deliveries) until the user edits bags per interval, then their -/+ or typed value wins.
  • A209 2026-10-19 No — keep C210's rule (start+interval+bags own the period); the end date is optional metadata, but when given it must be a real date on/after the start and it requires the start.
  • Q210 2026-10-19 C279 C279 splits the booking yarn field in two; the mill/ticket is not otherwise on the booking. Store it on the booking itself (new mill_ticket column) or only resolve it into the existing yarn row?
  • A210 2026-10-19 Store the picked mill on the booking as mill_ticket, because a new yarn row no longer carries a ticket; keep old bookings reading yarn.ticket as the fallback, accept the mill from the mill master or the selected yarn's legacy ticket, and leave the field optional so legacy data still saves.
  • Q211 2026-10-19 C280 C280 says switch the rate-per-mtr and job-rate positions on /orders/new?type=OUTSOURCE. Should the swap apply only to OUTSOURCE (JW keeps C254's rate -> picks -> job rate, SO unchanged) and to the background Price form plus its check-and-save summary, leaving the wizard unchanged?
  • A211 2026-10-19 Yes: swap only OUTSOURCE to job rate -> picks -> rate, keep JW at C254's rate -> picks -> job rate and SO unchanged; reorder the background Price form and the summary spec, leave the wizard untouched (it has no rate step). Fewest files, reversible.
  • Q212 2026-10-19 C283 Does 'Add gp no. Field' mean the trader/party's physical gatepass number (stored in the existing partnerGpNo / PGP no column), or an override of our auto-generated intimation GP number?
  • A212 2026-10-19 The trader/party gatepass no. It is stored in the existing partnerGpNo column (shown as PGP no on the record); the auto intimation number keeps generating on save and keeps feeding barcodes/lots.
  • Q213 2026-10-20 C287 C287 says improve UI ergonomics with no screen named. Which screen should change?
  • A213 2026-10-20 No screen named, so apply the app-wide navigation reading: every screen opens at its own top after a normal navigation, hash targets still work, back/forward unchanged; no data or form behaviour changes.
  • Q214 2026-10-22 C288 Does 'color code of the complete erp' mean the palette/status hues (the shared token layer), or per-module colour coding?
  • A214 2026-10-22 The shared palette/status-hue token layer: keep the owner's monochrome decision, make the state colour code readable. Per-module colour coding would be a new design language and is reversible later.
  • Q215 2026-10-22 C289 row-watch: 2 integrations of C289 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?
  • A215 2026-10-23 Not a code question: both C289 runs died on a DNS outage (getaddrinfo EAI_AGAIN api.deepseek.com) and both deploys failed at step 0 (Could not resolve host: github.com). Network is back — re-run the row.
  • Q216 2026-10-23 C289 C289 names only 'a smartly designed scrollbar' for the dashboard: restyle the app scrollbar only, or also add a dashboard section map rail (one tick per board section, active tick follows the reader, click to jump) so the layout itself is visible?
  • A216 2026-10-23 both, because the row asks to understand the layout, not just the position: keep one app-wide scrollbar skin in src/app.css and add a desktop-only section rail on the dashboard whose ticks sit on the same track as the thumb (one tick per board section, active tick follows the reader, click jumps). The skin alone stands if the rail is rejected — delete ScrollMap.svelte and its two lines in +page.svelte.
  • Q217 2026-10-23 C290 C289's rail was desktop-only (lg:block) and Android draws an untouchable overlay bar, so a phone had no scrollbar to grab. Should the rail show on phones as a draggable thumb?
  • A217 2026-10-23 yes — one rail for every width: the same 56vh monochrome track, now a pointer/touch drag that moves main.scrollTop (thumb centres on the finger, clamped at both ends), ticks still click to jump; desktop unchanged in look.
  • Q218 2026-10-23 C291 C291 says the draggable scrollbar can hardly be grabbed by a finger, must look very subtle, and should match the system's scroll: widen the invisible grab lane while shrinking the ink to the system width, or make the whole rail bar thicker?
  • A218 2026-10-23 Widen the lane, not the ink: a 44px invisible grab lane on phones (24px from sm up) at the right edge, with the visible bar shrunk to the 6px system width in the app's zinc-400 (hover zinc-600, dragging zinc-900), transparent track — it reads as the phone's own bar while the finger gets a real target.
  • Q219 2026-10-25 C292 C292 says no other UI libraries unless daisyUI can't do it — does that also ban lucide-svelte, which 63 files use for icon glyphs? daisyUI ships no icon component.
  • A219 2026-10-25 Icons stay. daisyUI has no icon set, which is exactly the row's carve-out; lucide-svelte draws glyphs only (no layout, no components), so the allow-list keeps it and the audit still fails on any second UI kit.
  • Q220 2026-10-25 C292 Printed paper sheets (src/routes//print/ and the checking report) hand-roll their own .tbl grid and print CSS — must their tables become daisyUI table too?
  • A220 2026-10-25 Paper stays on its own grid. daisyUI has no paper/print component; its table is a screen table (hover, row borders, base-100 fill) and applying it to an A5/thermal sheet would fight the print CSS. Paper is a named exception in scripts/daisy-audit.ts (PAPER_SHEETS + /print/), so app screens are still strictly daisyUI.
  • Q221 2026-10-25 C292 Many buttons are list rows, keypad keys, chips and backdrop dismissers styled with utilities rather than btn — must every one carry btn?
  • A221 2026-10-25 No. daisyUI's btn is a control (fixed height, padding, radius); a table row, a card grid tile, a keypad key or a backdrop dismisser is layout the kit cannot express, and forcing btn on them would resize the forms. Rule kept narrow and enforceable: no
  • Q222 2026-10-25 C293 does 'card swipes left and right' mean the sections become swipe pages, or the cards inside one section swipe sideways?
  • A222 2026-10-25 cards inside one section swipe sideways; the nine sections stay in one vertical page (the C289/C290 rail already maps them). Fewest files, reversible, and it kills the 29-card phone stack without hiding any figure.
  • Q223 2026-10-26 C294 The dashboard shows two vertical bars at the right edge: the shell's native main scrollbar (skinned in app.css, C289) and the ScrollMap rail (C289-C291). Which one is the 'extra' one - hide the native bar under the rail, or drop the rail?
  • A223 2026-10-26 Keep the rail. Since C289/C291 the owner calls the rail 'the scrollbar in dashboard', it is the only bar a finger can grab on a phone (C290) and it carries the section map; the plain native bar lying under it is the duplicate. Hide the native bar on the dashboard only, while the rail is mounted.
  • Q224 2026-10-26 C295 C295 says keep only the og scrollbar — is the dashboard to keep the app-wide skinned bar (and lose the rail's ink), not the rail as its scrollbar (C294)?
  • A224 2026-10-26 Keep the og bar. C294 hid the app-wide bar so the rail's ink was the only bar; C295 asks for the original back, so the ink goes instead — the ink is what C294 added over the skin and the cheapest thing to drop. Reversible: both files are 2 small edits.
  • Q225 2026-10-27 C296 Does 'strict organizational segregation' mean the existing eight work groups (Intake/Orders/Reports/Yarn/Gatepasses/Production/Guard & transport/Admin) are the right segregation, shown one at a time, or should the groups themselves be re-cut by production stage (yarn → beams → weaving → checking → dispatch)?
  • Q226 2026-10-27 C296 Should the flow screens with no sidebar row today (sizing, winding, beam-end, inward, fabric-in, pending, queue, search, signin) each get a sidebar option, or stay opened from the screen that owns the flow?
  • A225 2026-10-27 Keep the existing eight groups (each is already one org unit + one role set) and make the segregation structural: one group open at a time, one home per screen, machine-checked. Re-cutting the taxonomy moves every screen for no gain the owner can feel, and is not reversible in one row.
  • A226 2026-10-27 Keep them off the sidebar: they are flow steps opened from their parent screen (a beam, an order, the queue). Declare each one HIDDEN with its reason so 'which group owns this screen?' still has an answer, and the sidebar stays minimal.
  • Q227 2026-10-27 C297 C297 names no screen and no measure: 'readability and UI ergonomics throughout the website, use cards more, icons wherever necessary'. Which surfaces does one row cover?
  • A227 2026-10-27 Shared surfaces first, then the one outlier: the list toolbar (19 list screens), the row popup (RecordDialog, ~20 screens), the plain-table row action (SmartTable) and /pending (last action screen still on dense tables). Icons always ship with their word, never icon-only; a per-screen card rewrite stays later rows' work.
  • Q228 2026-10-27 C298 C298 says only 'boost lighthouse scores' — no category, no page, no score. Which lighthouse categories does one row own, and how is that measured on a host with no Chrome? (Chrome/Lighthouse cannot run here: no DevTools runtime.)
  • A228 2026-10-27 The search/SEO + best-practices + first-paint performance items that a server-rendered app can decide in its own head and headers: a per-screen (every screen was nameless — only the print/docs routes set one, so SEO failed on 'document has a title'), a meta description, a theme-color matching the manifest, a light-only color-scheme, the third-party Inter stylesheet off the critical path, and a cache policy for the static files that had none. Measured by a new scripts/lighthouse-audit.ts (22 checks) instead of Lighthouse, since no Chrome exists on this host; the browser-measured items (contrast, CLS, tap targets, LCP) stay for later rows.</li> <li>Q229 2026-10-27 C299 Which dashboard surface and which kind of chaos — the home board at / (nine sections, 29 cards), the /board/[slug] component pages, or missing data? And may a section be collapsed if a closed row still shows its red/watch tally?</li> <li>A229 2026-10-27 The home board at /. 'Chaotic' is hierarchy and reach, not missing data: keep every card and number, but draw the nine sections as one-open collapse rows, put the single typed New menu in the header and the needs-action strip first. A closed row keeps its N red / N watch / N cards tally, so nothing is hidden — only folded. /board/[slug] pages are out of scope (they already follow the component-page pattern).</li> <li>Q230 2026-10-27 C300 Does 'show wizards or wizard options only if necessary for form filling' mean the shared entry wizard opens only on the first step that still needs a value (and not at all when every step is answered), while the signed booking/tippan/order/quote step splits stay as they are?</li> <li>A230 2026-10-27 Yes — a wizard step is only shown while its field is empty (the FOCUS-ENTRY §11 rule 5 test), so the wizard starts at the first unanswered step and does not open when nothing is left to ask; signed step lists (booking/tippan/order/quote) are not re-split by this row; fewest files (one shared shell + one pure helper), reversible.</li> <li>Q231 2026-10-29 C301 The All gatepasses screen has no single kind, so its New control opens the plain form (YARN_OUT default): is dropping the kind menu there acceptable, given the eight kinds stay reachable from the sidebar kind rows (/gatepasses?kind=…)?</li> <li>A231 2026-10-29 Yes. The New control opens the form of the kind the screen is on; on the unfiltered All screen it opens the default form. The eight movements stay one tap away as the sidebar kind rows, so no kind becomes unreachable and no dropdown returns.</li> <li>Q232 2026-10-29 C302 Where does the warp/weft tag live and what words does it use? The gatepass has no warp/weft column; the yarn lot it creates on delivery already has a soft warp_weft tag (default weft) shown on /lots, and bookings already carry warp|weft|both.</li> <li>A232 2026-10-29 Reuse the repo's existing warp|weft|both vocabulary on both surfaces and add no gatepass column: the YARN_IN form asks one optional Yarn use row, the value rides the creation event (like beamType/destPlace/mill lot) and is stamped onto the lot the delivery creates, where /lots and the lot record already show it. Fewest files (no schema/migration), fully reversible, and 'both' keeps a mixed batch honest.</li> <li>Q233 2026-10-29 C303 Is 'kgs received till date' the sum of yarn-in receipts against the booking (their net when weighed, else bags × the booking's per-bag weight), and 'kgs to be received' the order's FULL requirement from the quote formula × order mtrs (not the remaining balance)?</li> <li>A233 2026-10-29 Yes: 'received till date' is the receipt side of the same booking (a receipt's net kg when it carries one, else its bags weighed at the booking's per-bag weight — this form asks bags, not kg); 'to be received' is the order's total requirement (order mtrs × the quote form's warp/weft kg-per-metre, the side(s) the booking's warp/weft tag names), shown as a pair, not as a remaining balance.</li> <li>Q234 2026-10-29 C304 C304 — is the yarn field the identity the form already shows (count + type + mill name) or a new yarn-master picker, and what is 'job work' here?</li> <li>A234 2026-10-29 The yarn field is the yarn identity this form already carries (countYarn + yarnTypeCode + ticket), not a new picker; job work is the existing rate-less open booking (A78/C120), so C303's three sources are unchanged. Auto from a rated yarn booking, user-picked for an SO/production order row, a job-work booking and an ?orderId= carry; both surfaces required on the manual branch.</li> <li>Q235 2026-10-29 C307 Point 5 'Yarn' — one step or the three yarn rows (count / type / mill name); and does 'except 1, 2 and 4' mean points 3, 5, 6 and 7 are skipped only while OCR already answered them, or removed from the wizard entirely?</li> <li>A235 2026-10-29 Point 5 stays the yarn identity's own rows (one static row when a yarn booking answers it, the three count/type/mill picks for an SO order or a job work) — the shell asks one field per step and merging them would change how they post. The OCR exemption is C300's skip: points 3, 5, 6 and 7 are not asked while already answered (by the read or a pick), points 1, 2 and 4 always show because nothing fills them.</li> <li>Q236 2026-10-29 C309 the reference table's single kg column: the system tracks received kg per order/booking, not per yarn count, so a multi-warp/weft row can show each count's required kg but not a per-count pending; and the SO tab keeps listing every open SO/PROD order rather than only rows still short of yarn</li> <li>A236 2026-10-29 single kg column shows pending / required for the row, and when a quality has several warp/weft yarns the same cell lists each count's required kg followed by the row's total pending / required — never an invented per-count pending; the SO tab keeps every open SO/PROD order (the pending column already says what is left, hiding rows would change what C303 shipped)</li> <li>Q237 2026-10-29 C310 Is the yarn master's mill / ticket a picker from the mill master or a free-typed name, and must it be filled?</li> <li>A237 2026-10-29 Picker: a daisyUI select whose options are the mill/ticket master values (rate-board tickets + mill rows), plus the yarn's own current mill so an edit never drops a historic spelling. The booking wizard already picks the mill from that master on its own step, so no free typing returns.</li> <li>Q238 2026-10-29 C311 Should the yarn Count field become a strict picker (only counts on the count master) or keep accepting a typed number while offering the master?</li> <li>A238 2026-10-29 Offer, do not restrict: the count stays a typed number with the count master as one-tap suggestions (a datalist), and the yarns themselves project into the master. A strict picker would block the first yarn on a fresh DB and the booking wizard quick-add, while an offer is reversible and keeps every current flow working — same call C310 made for the mill field.</li> <li>Q239 2026-10-29 C311 Do the design master warp/weft counts also project into the count master, or only the yarn master counts?</li> <li>A239 2026-10-29 Yarn master counts only — the row links the count master to the yarn master count field. Design rows carry counts from the yarn master already (their picker), so projecting them would widen the master without a request; left out, and reversible in one projection line.</li> <li>Q240 2026-10-29 C312 Does the type master hold only the eight standard codes (KW/CW/CCW/KCW/Dn/Ly/Sl/Other), or may a new type (CPT, TFO, OE) be added and used on a yarn — and if so must the gatepass yarn-inward type rule follow it?</li> <li>A240 2026-10-29 New types are allowed — that is what a master is for (the yarn master already carries CPT/TFO/OE-style codes in the imported data), so the master holds the eight built-ins plus anything added with a label. The yarn form's Type select offers the union and resolves a typed variant to the master's spelling; the gatepass yarn-inward field (C304's enum) now carries the same shared code rule instead of a frozen list, so a type the master was just taught never 400s the inward. Reversible: the eight built-ins are always offered, so a fresh DB and the booking wizard behave exactly as before.</li> <li>Q241 2026-10-29 C313 When the inward's reference is an SO trading order, a production order or a job work (nothing to inherit), is the single yarn field one yarn-master row (count + type + mill as one line), and does the recent direct-delivery job-work pick use the same field?</li> <li>A241 2026-10-29 One yarn-master row per yarn, its label reading count + type + mill; the pick fills the three POST names in one tap. The same field serves the direct-delivery job-work pick so both inward legs read alike. A yarn booking keeps inheriting its yarn and asks nothing new.</li> <li>Q242 2026-10-29 C315 When a read prints a booking number AND a destination (a direct-delivery note), which form wins — the direct delivery or the yarn-in reference picker?</li> <li>A242 2026-10-29 DIRECT wins: the destination already decides the kind (captureRouting C113), and that form has no reference picker, so the number rides unused. Keeps today's direct-delivery behaviour untouched and is reversible.</li> <li>Q243 2026-10-29 C315 How close must the printed number be to an open booking to pre-select it — exact stored value only, or normalised/fuzzy?</li> <li>A243 2026-10-29 Normalised letters+digits compare (spacing and punctuation ignored, case-insensitive) against the open/partial rows the picker already lists; no fuzzy or partial match. A number nobody holds pre-selects nothing and rides as a search chip.</li> <li>Q244 2026-10-29 C316 The owner's type words include 'hank', but the type master (C312) ships no hank code. Should the reader add one ('Hk' hank) to the built-in vocabulary, or leave a hank read untyped?</li> <li>A244 2026-10-29 Add Hk (label 'Hk hank') to the built-in vocabulary in src/lib/yarnTypes.ts, beside Dn/Ly/Sl. It is additive and reversible (a fresh DB simply offers one more type), and it makes every 'hank' read resolve to one code the type master can rename, instead of an untyped read the operator must fix by hand.</li> <li>Q245 2026-10-29 C316 C316 says the read value that matches no yarn-master entry is 'a suggestion chip'. Does that chip have to open the yarn-master add form and come back (C319's create-on-the-go chain), or does C316 only owe a visible read chip naming count · type · mill?</li> <li>A245 2026-10-29 C316 owes the read resolution (one yarn-master entry when count+type+mill match) and a visible chip naming what was read when nothing matches — the tap-to-create-and-return chain is C319's row, so this change only states the read value and leaves the pick to the operator; nothing is created.</li> <li>Q246 2026-10-29 C317 When the printed spinner line names a mill that is NOT in the mill/ticket master, should the read fill the mill field with the printed words, or leave the field empty and offer the printed name as a chip (tap to create the master, C319)?</li> <li>A246 2026-10-29 Leave the field empty and carry the printed spinner name as a hint the user is offered (<code>millHint</code>), never as the field's value: a mill the master does not know must not be invented, and the tap-to-create chain that turns the hint into a master entry is C319. Reversible: if the owner prefers the printed words in the field, it is the one <code>put(out,'ticket', …)</code> line in <code>prefillParams</code>.</li> <li>Q247 2026-10-29 C317 A mill the master knows, printed in prose rather than on a spinner line (a WhatsApp forward 'Sanathan rate 40 CW'), should still read as that master — but only a KNOWN master, never an unknown word. Right?</li> <li>A247 2026-10-29 Yes: a master entry named in the read still fills the mill, off any line that is not (and does not sit beside) an address; an unknown word only ever reads off a spinner line (a yarn/spinning/mill/tex-div/fabrics line) into the hint, so no unknown mill is resolved or invented from prose. Assumed as the safe 80/20: the alternative (spinner line only) would regress today's WhatsApp mill reads.</li> <li>Q248 2026-10-29 C319 When the yarn master is opened from a read, what does ?new= carry and how does a new mill get back to the inward? (reading: new=count+type, mill=separately, returnTo=the form, id returned as ?yarnId=)</li> <li>A248 2026-10-29 Pareto: ?tab=yarn&new=<count type>&mill=<ticket>&returnTo=<the form>; the yarn form splits count/type from new and takes the mill from mill=, offering it as + <mill> when the mill/ticket master lacks it (that chip opens ?tab=mill-ticket&new=<mill>&returnTo=<the yarn link> and returns); the save goes back to returnTo with ?yarnId=<id>&ticket=<mill> and the inward selects that yarn row. Fewest files, reversible (a link and a param, no column, no POST name), nothing created without the tap.</li> <li>Q249 2026-10-29 C320 C320 names a read value for the pickup godown/location and for the party/trader, but the gatepass read carries neither (gatepassReadFields hands over count/type/mill/bags/vehicle/transport only). What value does each chip stand on, which master row does a location belong to, and does the created entry have to land on the saved gatepass?</li> <li>A249 2026-10-29 Pareto: the chip is offered from the value the form already carries — the read's transporter (the one read field that is master-backed), the picked reference's printed supplier when it matched no party (C40's 'pick the party by hand'), and a named pickup place that is not a location-master row. The location master is the party rows of category Godown or Sizing (a Godown added on the go is offered next time; a Godown is no longer listed as a trader), the trader chip is a plain Party row and the transporter chip is a Transport row. Each 'new' is just the typed/printed name; a save returns ?field=<transport|trader|location>&partyId=<id>&party=<name> and the form selects it — the created trader rides the yarn-in / direct-delivery sourcePartyId, which the server already reads first (str(d.sourcePartyId) || the booking's), so it becomes the record's trader. Fewest files (the three the row names + the C319 link builder), reversible (a link and URL params, no column, no new zod field, nothing created without the tap).</li> <li>Q250 2026-10-29 C321 Does the + <typed> create row reach every focus pick in the app, or only the masters the row names (yarn, mill/ticket, party faces, count, type)?</li> <li>A250 2026-10-29 The row names yarn, mill/ticket, party (godown/transport/trader), count and type — the matches FOCUS-ENTRY §20 lists — so the create row is declared on exactly those master-backed fields (gatepass, sizing, winding, samples, movements, stocktake). Design/loom/weave/flange/defect/payment-term picks keep their own tabs and gain the row when their row lands.</li> <li>Q251 2026-10-29 C322 C322's acceptance asks for a regression test named for the spaced header, but this checkout carries no tests/ suite (removed in 7668c583; deploy.sh runs --no-suite). Where does the regression live?</li> <li>A251 2026-10-29 Pareto: the durable regression lands in the existing intake script scripts/mill-read-audit.ts as a check named for the spaced header (its PAPER already prints GATE PASS + Booking No. : 1128); it fails pre-fix (intent=booking) and passes post-fix, and the glued GATEPASS case plus a plain booking are pinned beside it. Rebuilding tests/ would resurrect a suite this checkout deliberately removed, and bunfig's preload (tests/setup.ts) no longer exists.</li> <li>Q252 2026-10-29 C323 The tippan, sample and quote forms have no OCR endpoint of their own (only the shared /capture draft hand-off). Where is 'the read' these forms must learn from?</li> <li>A252 2026-10-29 The read is the capture draft each form is opened with (?draftId=): the form resolves that draft's transcript from this form's memory at load (memory wins over the read's own answer, validated against the form's masters) and learns the user's corrections at save, exactly the C318 gatepass loop. The quote wizard's dictate step is its second read and is covered by a ?/memory action that answers memory before the fuzzy matcher. No new endpoint, no new intent, no schema.</li> <li>Q253 2026-10-29 C323 A tippan read's partyHint is a single name — which tippan field does it fill, the sizer or the weaver?</li> <li>A253 2026-10-29 The sizer: a tippan is the sizing programme, and the sizer is the party the note is addressed to. A remembered party therefore fills sizerId and never the weaver; the weaver still comes from the order/gatepass history as it does today.</li> <li>Q254 2026-10-29 C317 The goods line prints a 6-digit HSN code (520524). Is a bare 6-digit number on any line still an address mark, or do only the address words count?</li> <li>A254 2026-10-29 Keep it as a weak own-line mark (a bare PIN line is still an address) but let only the address WORDS spread to neighbours, and never spread over a line that names a mill/spinner — the spinner keeps its own line. Fewest changes to addressContext(), reversible, and the Vishnu cases stay address.</li> <li>Q255 2026-10-29 C324 adapter-bun serves only the assets listed in its build-time table, so copying the previous build's hashed chunks into build.next does not make them reachable after the restart. Should the swap also register the carried files in the new build's asset table (build.next/adapter-bun.js), or leave them on disk only?</li> <li>Q256 2026-10-29 C324 which build do the carried chunks come from: the one currently served (build) or the older build.prev?</li> <li>A255 2026-10-29 Register them: build-swap.ts appends each carried file to the new build's generated asset table with the adapter's own meta (blake2b256 digest sliced to 16 hex + file mtime), so the open tab's chunk URL is served by the new build too. Additive and reversible (a table the script cannot find aborts the swap before anything served changes); a file left on disk but unregistered would still 404 after the restart, which is exactly the bug C324 is closing.</li> <li>A256 2026-10-29 From the build being replaced (build), not build.prev: those are the chunks an already-open tab asks for. build.prev stays as the rollback copy only.</li> <li>Q257 2026-10-29 C325 Does the read's saved gatepass photo become the form's Gatepass photo by COPYING the file into the screenshots upload drop (the draft keeps its own copy), and does it also overwrite a photo the operator already snapped before the read?</li> <li>A257 2026-10-29 Copy, never move: the read's file is written to screenshots/capture as before (the draft's rawImage keeps /capture-img/<name>), and a second copy goes to the screenshots upload drop under the SAME name so the form's existing <code>image</code> field and /upload-file/<name>?bin=screenshots resolve it with no schema/route change; the two copies are independent files, so a later upload never touches the draft's copy. Only a gatepass read does it (other intents unchanged) and only for an image (a PDF read leaves the photo field empty — the pane still shows the PDF). The read sets the photo only when the field is empty or still holds the previous read's file, so a snap the operator took first is never overwritten and the row's own Replace still wins.</li> <li>Q258 2026-10-29 C326 does the pinch also have to apply to a PDF gatepass in the verify pane, and does the photo box take over page scrolling while a finger is on it?</li> <li>A258 2026-10-29 Image only: the PDF branch keeps its own iframe viewer, since a pointer layer over a PDF fights the browser's reader which already pinches and pans (fewest files, reversible). And yes — touch-action:none lives on the photo box alone, so the rows outside the pane still scroll natively; the box owns touch only while the pane is open</li> <li>Q259 2026-10-29 C327 Are the two new top buttons shown only while the wizard is closed (the C141/C274 Start-the-wizard pattern) or always at the top of the yarn-in screen?</li> <li>A259 2026-10-29 Always render them for YARN_IN: the wizard overlay covers the screen while it is open, so they are visible exactly when they can be tapped; no wizOpen state has to be exported out of the shared FocusEntry.</li> <li>Q260 2026-10-29 C327 What does Start OCR open - the wizard step that carries the read card (gatepassRead), or the read card alone in its own popup?</li> <li>A260 2026-10-29 Start OCR opens the wizard's own gatepassRead step (the same read card the walk starts on); on a carried yarn-in where that id is not in the walk it opens the same field's popup, which renders that identical read card. Nothing new is built behind either button.</li> <li>Q261 2026-10-29 C328 C328 asks for a regression test but this checkout carries no tests/ suite (removed in 7668c583); where does the marker guard's test live, and does a marker line in prose count?</li> <li>A261 2026-10-29 The test lives in the guard itself: scripts/check-conflict-markers.sh --self-test replays the 2026-10-29 incident in a throwaway repo (6/6), and deploy.sh runs it as step 0a so it keeps running. Resurrecting tests/ would undo 7668c583 and bunfig's preload no longer exists — same reading as A251. Markers are line-anchored, so a marker named mid-sentence in prose is not one; a real marker line in any tracked file refuses the commit.</li> <li>Q262 2026-10-29 C329 The row says the trader's GP no format is letters/digits/slash, 24 chars max, 'validated exactly like the field' — but the live partnerGpNo field allows letters/digits/space/hyphen/slash up to 64. Should the field itself be tightened to 24, or only the read?</li> <li>A262 2026-10-29 Keep the field's existing 64-char rule untouched (a live field must not tighten silently) and cap only the read at the row's 24 with letters/digits plus the field's own space/hyphen and slash — every read value then passes the field's rule; reversible in one line if the owner wants 24 on the field.</li> <li>Q263 2026-10-29 C330 Does 'every other read value' include the weights (gross/net) and the expected date, which the YARN_IN form shows no row for?</li> <li>Q264 2026-10-29 C330 Should an in-page read of a booking number that DOES match an open reference pre-select that reference (like the page-load carry does), or leave the pick to the operator?</li> <li>A263 2026-10-29 Yes — list them. The read card is a report of everything the paper gave, not only this kind's rows; a value read and invisible is the exact complaint. Nothing is posted for a value the kind has no row for.</li> <li>A264 2026-10-29 Leave the pick to the operator. Only a number that names no open reference rides as the chip and seeds the search; preselecting client-side would silently inherit a trader/yarn/rate the page-load carry resolves on the server.</li> <li>Q265 2026-10-29 C332 the yarn-in packing row is now labelled 'Cones per bag' — should it also be ENTERED per bag (with the delivery total derived) or is the label alone the fix while the guard still types the delivery total?</li> <li>A265 2026-10-29 enter it per bag: a yarn delivery is counted as cones per bag (the same figure the booking already carries), so the row now takes the one-bag count, the delivery total is bags × cones/bag and is stored in the existing cones column (the lot's bag grain and every report keep reading one total), and the per-bag figure lands in the existing cone_per_bag column. Label-only would have written 60 into a field the ledger reads as a delivery total, so the safe reading is the one that keeps the stored total exact.</li> <li>Q266 2026-10-29 C333 Does 'every row the yarn-in wizard shows is required except remark' include the 'Read the gatepass' OCR card row (wizard step 1)? Making it required would force a photo read before Save, so manual entry could no longer be used.</li> <li>A266 2026-10-29 No — the read card stays optional: a guard must still be able to type a gatepass in by hand. The Gatepass photo row the read fills IS compulsory, so every saved yarn-in still carries a photo; only the automatic read is a convenience, never a gate.</li> <li>Q267 2026-10-29 C333 Does 'compulsory' mean a number must be entered (0 is a value) or that it must be greater than 0?</li> <li>A267 2026-10-29 Compulsory means the row was filled — a posted 0 counts as filled (bags 0 also posts an empty receipt today, and the bags rule stays '0 or more'; cones/bag and bag weight already refuse 0 by their own >0 rule). No new range rule is added by this row, so nothing that worked before is refused.</li> <li>Q268 2026-10-29 C334 Do the long field-pop-up lines go away for every screen or only the gatepass page, and do short source markers ('today', 'Auto — from the picked booking') stay?</li> <li>A268 2026-10-29 Owner ruled on reading: the explanation line goes from every FocusEntry step/pop-up (one shell, reversible), and this row sweeps the gatepass page only; the short source markers are values of the field, not explanations, so they stay in the summary rows and the pop-up carries just the label + the field. Nothing is removed from other screens' own components in this row.</li> <li>Q269 2026-10-29 C335 The read's Booking No. is the trader's own slip number (C315) — does the chip open the booking form's Trader booking no. field with it (this build), or should it instead match/consume it as the system booking number (BK-…)?</li> <li>A269 2026-10-29 The trader's booking no. field — the paper's number IS the trader's own reference (C209's first field), so the booking is created carrying it; the system number stays system-generated. Return link is ?returnTo= validated like every master carry, and the booking's save returns to the yarn-in as ?bookingId=<id> so the picker selects the new row.</li> <li>Q270 2026-10-29 C336 Which top-block line counts as the docIssuer when the letterhead carries no firm suffix (e.g. a bare 'GOENKA'), and what validation rule does the new field take?</li> <li>A270 2026-10-29 Only a line that reads like a firm (a company suffix: Private Limited / Pvt Ltd / Ltd / LLP / Syndicate / Industries / Mills / Textiles / Traders / & Sons, on the top block before the first label and outside an address line) is the issuer; a bare one-word top line is not, so nothing is keyed to a guess. The model may fill it when the text read misses. Rule on both surfaces: letters, digits and a firm's punctuation (& . , ' ( ) -), 3-80 chars, blank stays blank.</li> <li>Q271 2026-10-29 C337 Which fields does a learned gatepass FORMAT cover — every readable field, or only the identity fields the row names?</li> <li>A271 2026-10-29 Only the row's own three identity fields — booking no, the trader's GP no, the mill/ticket. Count/type/transport already resolve through the word memory (form_memory) and adding them here would duplicate that rule in a second table.</li> <li>Q272 2026-10-29 C337 Does a learned anchor override a value the regex read or the model answered?</li> <li>A272 2026-10-29 Never. The deterministic pre-pass runs after the regex parse and before the model's answer is merged; it only fills a field the parse left empty, and the model/merge only fills what is still empty. A value the reader already produced wins, so nothing the paper was read as is silently replaced.</li> <li>Q273 2026-10-29 C338 How is the issuer known before the gateway prompt when a read starts from a photo only?</li> <li>Q274 2026-10-29 C338 Should the read card show the format line even when the hinted call could not run?</li> <li>A273 2026-10-29 The read's own first pass names the letterhead, so the issuer is known one step later without a second look at the photo: the hint rides a follow-up call over the same transcript (text only, no image again), asked only when the read is a gatepass and that issuer already has learned rows. A first read of a new trader spends nothing.</li> <li>A274 2026-10-29 Yes. The line states what is known about the issuer's layout, not a promise about this answer, so it is drawn whenever the gatepass read's issuer has learned rows — even if the hinted call returned nothing.</li> <li>Q275 2026-10-29 C339 With two lanes, may a lane claim only its own pid so a dead lane is detected per lane (never masked by a busy one), and does a docs-only target count as a conflict?</li> <li>Q276 2026-10-29 C339 Which measure counts as the rows/hour before, and is the after figure allowed to be read later with the same command instead of inside this row?</li> <li>A275 2026-10-29 Yes: each lane's claim is its own pid file (.row-claims/<n>: pid, row, targets), so a dead lane is pruned by pid alone and one busy lane never masks it; --unstick --keep names only the live lanes' rows. Every finish also keeps the other lane's live session out of the sweep.</li> <li>A276 2026-10-29 The before figure is the log's own window right before the change (12h = 4.25 rows/h, 51 rows; 24h = 2.12), and the after figure is read later with the same 'bash scripts/row-watch.sh rate <h>' command once the two-lane watcher is actually live — this row does not deploy, so measuring it here would be fiction.</li> <li>Q277 2026-10-29 C341 This host already runs Bun 1.4.4, which is the newest stable release (bun-v1.4.4, published 2026-10-22) — there is no newer version to install. What should the row deliver?</li> <li>A277 2026-10-29 Pin the runtime in the repo instead of leaving it to whatever each host installed: .bun-version = 1.4.4 (Bun and CI read it) plus scripts/bun-upgrade.sh that upgrades a host to the pin, never downgrades, backs the binary up and rolls back on failure — and prove this host is at the pin. Upgrading becomes one repeatable command for the Pi, the VPS and the phone.</li> <li>Q278 2026-10-29 C342 The row asks for 'a legacy cost flag' without naming its table: is it one flag on order, or a flag on each new cost table?</li> <li>A278 2026-10-29 One flag where legacy meaning lives: order.legacy_cost (boolean, default 0) marks a pre-WAC order so the costing engine never re-costs it, and cost_leg/cost_apportionment carry the same defaulted flag for a row carried in from legacy data. No new-table row exists today, so nothing needs a second switch.</li> <li>Q279 2026-10-29 C343 The row's gate says 'tests green', but this checkout has no test suite (tests/ and its bunfig root were removed 2026-10-05). Where should the costing engine's tests live?</li> <li>Q280 2026-10-29 C343 Does a WAC average count out-entries and zero-cost/salvage entries, and is salvage sale proceeds revenue in the SO P&L rather than a fabric cost?</li> <li>A279 2026-10-29 Co-locate the tests with the engine as src/lib/server/costing/costing.test.ts and run them standalone with bun run (bun test cannot discover anything while bunfig's root ./tests is missing); one file inside the row's target, reversible, and it can be adopted by the suite unchanged when tests/ returns.</li> <li>A280 2026-10-29 A WAC is SUM(value) of the inward entries divided by SUM(qty) of the inward entries: out entries are valued at the average of their own moment and never move it, and zero-cost entries (salvage track, or any entry worth zero) are excluded from the average while their quantity stays in stock. Salvage carries no fabric value at all (zero-cost track) and its sale proceeds are revenue rolled into the parent SO P&L; a damaged SO's own sale is that SO's revenue, not an extra roll-up.</li> <li>Q281 2026-10-29 C344 Where does a yarn receipt's ₹/kg come from — the booking behind the gatepass, the order's locked cost basis, or the yarn supplier default? And should a receipt with no priced booking stay out of the WAC?</li> <li>A281 2026-10-29 Take the booking's ratePerKg as the receipt's ₹/kg (the figure the inward already reads through the gatepass's booking carry); a receipt with no priced booking writes a zero-cost pool entry — its kg is stock, it never moves the average, so a free/opening lot cannot drag the WAC and a later purchase changes only future issues. Fewest files, reversible: the pool row can be re-read but is never rewritten.</li> <li>Q282 2026-10-29 C345 Where does a production order's sale-order link live, and what does a shortfall shrink against, given no cost_apportionment row exists before completion?</li> <li>A282 2026-10-29 Keep it in the event ledger: the create stamps po:planned with the soId, the plan is the SO remaining rounded up to 100 (own qty when nothing is left), and the assignment a shortfall shrinks is the PO's planned metres until a cost_apportionment row exists.</li> <li>Q283 2026-10-29 C345 Does cancelling a production order need to move stock, or only the apportionment tag, and how are cost legs treated?</li> <li>A283 2026-10-29 Only the tag: append an out tagged to the PO plus a free in at zero value, so kg and WAC never move; the conversion legs stay provisional and nothing is accrued. Produced fabric is already free (completion writes no order tag).</li> <li>Q284 2026-10-29 C346 Is cost coverage mandatory on every new sale order, and where does market fabric's WAC come from before C349's purchase form exists?</li> <li>A284 2026-10-29 Coverage stays OPTIONAL: a sale that posts no coverage books exactly as it always has (no apportionment, no auto PO), and only a started coverage must balance exactly to the sale quantity — reversible and it cannot break the SOs the owner raises today. Market fabric is read from the purchased pool track C342 already gives us (keyed quality+pick, its own WAC, never blended with produced), so the row needs no new source of truth and C349's purchase form will simply feed the same track.</li> <li>Q285 2026-10-29 C346 What cost does a new-production-order line lock at save, and is parent_so_id required on a damaged sale?</li> <li>A285 2026-10-29 A new production order's line locks at zero cost and provisional — C345's completion already re-prices the assigned metres to incurred ÷ good mtrs, so nothing is invented at booking and the margin shows as provisional. parent_so_id stays optional but validated when present (an existing, non-cancelled SO; refused on a normal sale): a damaged lot can be sold without its parent named yet, and C348 is what gates X-grade sales.</li> <li>Q286 2026-10-29 C347 When a sale order's quality or pick changes, does the full reassignment happen in the same save as the release, or as the separate rebalance action?</li> <li>A286 2026-10-29 Release in the amend save, reassign through the single rebalance action — one place prices coverage, no half-priced in-between state</li> <li>Q287 2026-10-29 C347 Should a production order that is already complete (cost frozen) be cancellable, and should a sale-order quantity rise be refused while it is uncovered?</li> <li>A287 2026-10-29 A completed PO is never cancelled (its unit cost is frozen and its output already sits in the produced pool); a quantity rise is accepted and leaves a visible gap for the rebalance action, so nothing is silently refused</li> <li>Q288 2026-10-29 C348 Does an X roll keep status reject (so only the damaged-SO path can ever ship it), or should it be FG with the sale gated by the damaged marking?</li> <li>A288 2026-10-29 X keeps status reject: the FG dispatch gate (status FG only) then refuses it, which is today's behaviour for a non-usable roll, and the only door for X is a damaged sale order — enforced where the roll names its order on the checking form. Reversible, no dispatch change.</li> <li>Q289 2026-10-29 C349 Is GST part of the landed fabric cost (capitalised into the purchased WAC) or an input credit excluded from it, and with only one cost leg does the leg carry the landed ₹/m (rate + freight) or the invoice rate?</li> <li>Q290 2026-10-29 C349 When a market purchase is assigned to a sale order, does the purchased pool also get an out entry, or only the market apportionment C346 already writes?</li> <li>Q291 2026-10-29 C349 Should a market fabric purchase be owner-approved (C111) like other orders, or recorded approved at entry?</li> <li>A289 2026-10-29 GST is input credit, so it is excluded from the landed cost and recorded as cost_leg.gst_pct; freight is capitalised. With one leg, the leg carries the landed ₹/m (amount ÷ qty) and order.rate keeps the invoiced fabric ₹/m — reversible, and the pool and the leg then agree to the paisa.</li> <li>A290 2026-10-29 Only the market apportionment, exactly as C346 writes a market line: the fabric is still physically in stock until dispatch, and C346's release path does not give a pool out entry back, so writing one here would invent an imbalance. Fewest files, reversible.</li> <li>A291 2026-10-29 No new gate: the purchase records approved at entry with the signed-in user, like the other cost entries; C111's order approval stays on the sale/job/production orders it already covers. A gate can be added later without touching the write.</li> <li>Q292 2026-10-29 C350 What does the stock report mean by free vs apportioned vs WIP?</li> <li>Q293 2026-10-29 C350 Live lots predate the pool wiring (pool_entry is empty on data.db) - should the stock report go blank until new receipts land?</li> <li>Q294 2026-10-29 C350 Does own vs party apply to the fabric tracks too?</li> <li>A292 2026-10-29 The report splits the pool balance: total = free + apportioned (apportioned = kg on entries a still-live production order still holds), and WIP is yarn already issued to a live order — it has left the pool, so it is shown beside the balance, never inside it. Same rule on both surfaces.</li> <li>A293 2026-10-29 No. A lot with no pool receipt is its own 'opening' line at blank WAC — kg counts as stock, no price is invented (the rule C344 already applies to an unpriced receipt). Today that keeps the live screen populated; each new receipt moves its kg onto the pool line at WAC.</li> <li>A294 2026-10-29 Own/party stays a yarn dimension (lot.owner). Fabric on the produced/purchased tracks is always ours — job-work cloth never enters a pool — so the fabric table omits the split instead of printing a fake zero.</li> <li>Q295 2026-10-29 C351 A DIRECT delivery to a weaver: does the destination post its own word (destPlace 'weaver') or keep reusing 'sizer'?</li> <li>A295 2026-10-29 its own word: destPlace gains 'weaver' beside 'sizer' — the creation event and the detail page must say where the yarn actually is, and the stock location is read from the party's category, so no WAC or pool code moves; the enum change is one word and reversible</li> <li>Q296 2026-10-29 C352 Do the new freight and purchase brokerage enter the booking's GST and total amount, and is the landed ₹/kg built on the basic (GST-excluded) amount or the inclusive total? And what is the received kg when the receipt carries no weight of its own?</li> <li>A296 2026-10-29 Both are add-ons beside the yarn amount: they never enter basic/gstAmt/totalAmt (GST is input credit, it rides the invoice, not the stock) and the landed amount is the basic amount + freight + brokerage divided by the arrived kg. A receipt with no weight of its own bills the booked kg (a full receipt), so every already-saved booking lands at its own ₹/kg.</li> <li>Q297 2026-10-29 C352 row-watch: 2 integrations of C352 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q298 2026-10-29 C353 C353 leaves three things open: what 'packing and loading direct' means, how a sizing bill's billing kg reverses out of the received count, and where the checking rate's 'yearly default' is stored (there is no checking-rate master table).</li> <li>A298 2026-10-29 'Direct' = a lump rupee amount with no per-unit base (qty 1, rateUnit job) capitalised at PO level, because packing, loading and freight are part of what the produced metre cost — C342's 'so' level stays for one-off charges that belong to a sale order, not to conversion. The sizing billing kg = kg sent x count sent / count received (a kg is inversely proportional to the count for the same length), and when the bill states it, that kg is the leg's qty with the gap kept as the quantity variance and written into the row's reason. No checking-rate table exists, so the rate is typed per leg (editable, as the row says) and the engine's checkingRateFor resolves quality + year with the yearly default (null-year row) and the global default the moment such rows exist — no migration, no master screen.</li> <li>Q299 2026-10-30 C353 row-watch: 2 integrations of C353 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q300 2026-10-30 C354 A bill covers several orders of its kind: does it allocate pro rata to the quantity each order committed, and what does a bill that states no quantity mean?</li> <li>A300 2026-10-30 Pro rata to the committed quantity, one line per open leg grouped by order, the last line absorbing the rounding so the lines add back to the bill; a bill with no stated quantity counts as the committed quantity, so it is all rate variance and no phantom quantity gap. Fewest files (one pure allocateBill), reversible.</li> <li>Q301 2026-10-30 C354 A settled bill moves the order's unit cost, its produced pool entry and every sale-order hold. Should the pool entry and the holds be rewritten in place, or should a new pool/hold row be written?</li> <li>A301 2026-10-30 In place: the bill is the correction of the same document, so the same pool entry and holds are restated with the new unit cost, with an amendment row plus a po:restated event keeping the before/after. No second pool/hold row means no double counting and nothing to learn to release. Reversible.</li> <li>Q302 2026-10-30 C354 Where does a sale order's P&L status live, and how is the last-bill auto-close vs a manual close with bills missing kept apart?</li> <li>A302 2026-10-30 Derived from the ledger, not a new column: no so:pnl:closed event = provisional, one = closed. The last bill auto-closes; a manual close needs a reason and that reason is the flag carried on the close. No migration, reversible.</li> <li>Q303 2026-10-30 C354 Does the bill header need a new table, and how does a pasted vendor bill list behave when a line cannot be read?</li> <li>A303 2026-10-30 No table: the bill header is the bill:recorded event (vendor, no, date, kind, amount, GST, allocations, variances), and the bills-pending row is an exceptions row on the existing queue board. An import reads one bill per line, comma/tab separated, and a bad line is reported by number and never guessed. No migration, reversible.</li> <li>Q304 2026-10-30 C354 row-watch: 2 integrations of C354 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q305 2026-10-30 C355 Where do the SO P&L charge percentages (freight-out, insurance, octroi & statutory, sample, overhead) live?</li> <li>A305 2026-10-30 The four outgoings and the overhead are shares read per sale: the company-wide default is the 1% constant (<code>SO_PNL_DEFAULTS.overhead</code>, and the quote engine's fallback), and this sale's own reading of the five shares is an append-only so:pnl:lines event, edited from a Change the shares form on the order record. No column, no migration, reversible: the defaults stand when no event exists. C355 re-check: the quality master's Other expense % never feeds either surface (owner §252) — the old stored 6.5 cannot pull the overhead back; a quote's own saved reading still wins.</li> <li>Q306 2026-10-30 C355 All 627 designs still store the sheet's 6.5% other expenses and both quote screens read it as the fallback, so quotes still price 6.5% overhead. Rewrite the stored values to 1, or stop reading the master?</li> <li>A306 2026-10-30 Stop reading the master on both quote surfaces (owner §252 already rules Other % quote-only, never the master): /quote/new prefills null and /quote/edit passes null, so both fall to the 1% company constant and a quote's own saved reading still wins. No stored value rewritten — reversible with git, old designs keep their history, and the seeds now write 1.</li> <li>A297 2026-10-30 Cause fixed: the deploy abort was /reports returning 500 (C350 removed costBasis from the load but the page still rendered it). Restored costBasis in the load; load returns openPos, costBasis, soDelivery, stock, fabricStock. The row work is in the tree and proven — ship it, do not re-run.</li> <li>A299 2026-10-30 Same cause as Q297: the /reports 500 aborted every deploy. Fixed in the load (costBasis restored). Do not re-run C353; the leg-basis work is in the tree and proven — ship it.</li> <li>A304 2026-10-30 Same cause as Q297: the /reports 500 aborted every deploy. Fixed in the load (costBasis restored). Do not re-run C354; the bills/restatement work is in the tree and proven — ship it.</li> <li>Q307 2026-10-30 C355 row-watch: 2 integrations of C355 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>A307 2026-10-30 Same /reports 500 that blocked C352-C354. Fixed in the load (costBasis restored) and shipped: C355 is done and live in 7149bbe6 (live-check 83/83). Do not re-run.</li> <li>A1 2026-10-30 Moot: C99 and C100 both landed long ago; the per-field popup split is live. No action.</li> <li>A2 2026-10-30 Keep as shipped: the one-tap Create buttons stay beside the prefill links. No change.</li> <li>Q308 2026-10-30 C357 Opening stock is entered once at cutover — should a pool key that already has an opening line accept a second one (a re-count, or the same count held at two godowns)?</li> <li>A308 2026-10-30 No second line per pool key: the key already entered refuses it, and the paste import is all-or-nothing, so a re-run of the same sheet can never double the stock. A later re-count adjusts the pool with its own entry, not by re-opening the cutover line.</li> <li>Q309 2026-10-30 C357 Should an opening line require a value, or may it book unpriced stock (blank ₹) at zero cost?</li> <li>A309 2026-10-30 Value is optional: a blank ₹ books the quantity as unpriced stock (its kg/mtrs counts, the pool average never moves) — the same rule an unpriced receipt already follows, so no price is ever invented. A line with a value stores qty and ₹, and the pool reads its WAC from them.</li> <li>Q310 2026-10-30 C356 Must every exceptional charge carry a document ref and a reason, or may a charge be booked without paper?</li> <li>A310 2026-10-30 Both are required. The row itself says the charge comes 'with document ref and reason'; a charge nobody can tie to a paper is not answerable later, and the append-only model has no edit to add one. One rule table refuses blank on both surfaces, so nothing extra is written and the rule is reversible by relaxing the regex.</li> <li>Q311 2026-10-30 C356 At PO level the charge is capitalised — does it also restate the order's ₹/m immediately, or only at the next bill?</li> <li>A311 2026-10-30 Immediately. 'Capitalised, moves WAC' is the row's own words; waiting for a bill would mean an exceptional charge sits in cost_leg but not in the order's cost, and the sale orders holding it would keep a stale margin. The booking runs the same restateOrder cascade a bill runs, inside the same transaction, so the leg and the new ₹/m cannot disagree.</li> <li>Q312 2026-10-30 C358 What counts as the delivered metres a manual fulfilment is judged on, which status word does 'fulfilled' write, and what is the tolerance when the order has none?</li> <li>A312 2026-10-30 Delivered metres are the dispatch slips of this order in status loaded or delivered (the same measure dispatch's own auto-delivery already uses), and 'fulfilled' writes the existing status word delivered so no reader learns a new one. The tolerance is order.diff_mtr, and a blank tolerance reads 0 — nothing is invented, so a delivery one metre off without a stated tolerance is blocked and names the amendment.</li> <li>Q313 2026-10-30 C358 An excess inside the tolerance must be apportioned before marking. May a new production order carry it, and at what cost does the extra land?</li> <li>Q314 2026-10-30 C358 What does reversing a fulfilment undo, given a shortfall's holds were already released at locked cost?</li> <li>A313 2026-10-30 Only free stock (produced or market pool) or an existing open production order may carry the extra, at that source's current cost (pool WAC, or the PO's committed cost per planned metre) — exactly what the coverage card already offers. A new production order is refused here: the row says stock or an existing PO, and a new PO would lock the extra at zero and price it later.</li> <li>A314 2026-10-30 A reversal returns the status only (delivered back to in-prod), recorded as an amendment and an event. The holds a shortfall released stay released and the extra apportionment stays written — append-only, so the answer to them is the coverage card's rebalance, not an undo. The reversal rides C152's order_change rail, so a non-owner's press leaves a pending item on /approvals and nothing moves until the owner decides.</li> <li>Q315 2026-10-30 C357 row-watch: 2 integrations of C357 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q316 2026-10-30 C358 row-watch: 2 integrations of C358 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q317 2026-10-30 C359 A read gatepass that prints a godown address but no booking number and no explicit 'direct delivery' words — which kind should the link open? (taken as: none carried, so the form keeps its own default YARN_OUT)</li> <li>Q318 2026-10-30 C359 Should the printed godown ADDRESS prefill the yarn-in's 'Location of pickup' row (destPlace)? (taken as: no — the address is the trader's own godown, not one of our four place words, so the existing our-godown default stays)</li> <li>A317 2026-10-30 Pareto, reversible: no kind is carried without an explicit signal. A booking number means YARN_IN, an exact godown/premises/sizer word or the words 'direct delivery' mean DIRECT, everything else leaves ?kind= off so /gatepasses/new keeps its existing YARN_OUT default. Never guess a movement from a printed address.</li> <li>A318 2026-10-30 No. The address names the trader's godown, which is not our-godown/premises/sizer/weaver — writing it into destPlace would mislabel the receipt's location. The row keeps its our-godown default; the address itself is dropped by the reader (destinationSane), so it never becomes a movement or a place word.</li> <li>Q319 2026-10-30 C360 The child form (masters / bookings-new) is a full route: does the modal re-render it as a native in-page Svelte modal, or open the same route in a same-origin iframe and let it post its save back?</li> <li>A319 2026-10-30 Same-origin iframe of the existing child route, one postMessage back on save — no second copy of the masters / booking forms.</li> <li>Q320 2026-10-30 C360 A booking created in the modal is not in the page's open-bookings read: what does the reference table show for it before a reload?</li> <li>A320 2026-10-30 The number and the yarn the read carried, remainder '—' — never an invented kg; the server resolves the real booking from the DB on save.</li> <li>Q321 2026-10-30 C359 row-watch: 2 integrations of C359 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q322 2026-10-30 C361 The row says 'Total cones not needed' on the yarn-in: drop only the read-only 'Total cones in this delivery' row (and its arithmetic in the cones-per-bag sub), or also stop storing the derived total in the gatepass's cones column?</li> <li>A322 2026-10-30 Display only: the yarn-in asks one bag's cones and one bag's weight and shows no total; the derived figure (bags × cones/bag) still posts as cones so the lot's bag grain, the reports and the prints keep reading one total, and the gatepass record's own read-only line stays as it is. Fewest files, nothing to migrate, reversible.</li> <li>Q323 2026-10-30 C360 The drain's build is red from HEAD (C357's browser module src/lib/openingStock.ts imports #lib/server/costing/pool.ts, which SvelteKit's server_only_import guard refuses): fix it inside this row, or leave C360 unshippable and let another row carry it?</li> <li>A323 2026-10-30 Fix it here, the narrowest reversible way. The key is one rule and both the engine and the opening-stock entry must build it, so yarnKey/fabricKey move to client-safe src/lib/poolKey.ts and costing/pool.ts imports and re-exports them; PoolTrack aliases KeyTrack. Key strings are byte-identical, no costing behaviour moves, three files plus one new, reversible. Leaving it red would cap C360 at its second failed deploy and stop the line.</li> <li>Q324 2026-10-30 C362 Which documents field does this row mean? C305 removed the yarn-in's uploads section (OCR doc / saved document / dictation), so the form now carries only the GP photo row and the OCR read card.</li> <li>A324 2026-10-30 The gatepass's documents on /gatepasses/new?kind=YARN_IN: one field listing what was uploaded or read (GP photo, OCR read, added papers) each with a download, and taking new files — several at once. The uploads are the gatepass's papers, not a separate screen.</li> <li>Q325 2026-10-30 C362 Where do several documents live when there is no documents column — a new column/table, or the existing append-only creation event?</li> <li>A325 2026-10-30 The creation event's payload, one saved name per line (max 10) — no migration, nothing committed is ever rewritten, and removing the field later drops the values with it.</li> <li>A315 2026-10-30 yes, re-run</li> <li>A321 2026-10-30 yes, re-run</li> <li>A316 2026-10-30 yes, re-run</li> <li>Q326 2026-10-30 C357 the opening paste takes the type as the cutover sheet wrote it ('ccw'), while the pool key keeps the master's spelling ('CCW') — should a paste be refused when the type is not in the yarn type master, or accepted as typed?</li> <li>A326 2026-10-30 Resolve the type against the yarn type master case-insensitively and store the master's spelling; refuse a line whose type is not in the master, naming its line. Reason: the pool key is count|type|grade, so a stray 'ccw' beside 'CCW' would open a second bucket and the cutover stock would be invisible to the WAC — exactly the failure the row exists to prevent. It is the same rule the fabric quality already follows on this screen, and it is reversible (a new type is added in the masters first).</li> <li>Q327 2026-10-30 C363 Does the verify pane's zoom cap stay at 4x now that zoom works past 100%?</li> <li>A327 2026-10-30 Keep 4x. The wall at 100% was a CSS clamp, not the cap; 400% of a phone-wide pane already reads a gatepass line, and the cap is one constant if the guard needs more.</li> <li>Q328 2026-10-30 C366 Should the existing order.picks/jobRate be stored as a po_segment row, or read as a synthetic default segment?</li> <li>Q329 2026-10-30 C366 Does an in-house segment carry any vendor bill party?</li> <li>A328 2026-10-30 Keep order.picks and jobRate as a synthetic default segment (seq 1) read from the order, never copied into po_segment: existing POs need no backfill, no migration row is lost if the order is re-planned, and only genuinely added segments are stored. Added segments start at seq 2.</li> <li>A329 2026-10-30 No vendor bill: the in-house leg is provisional with billPartyId null and a reason naming the internal rate; out-house legs carry the weaver as billPartyId.</li> <li>Q330 2026-10-30 C364 Which split fixes the per-order earmark: the booking's own bags split (C195 orderSplit) or the receipt's box split across orders (C309 allocation)?</li> <li>A330 2026-10-30 The booking's own bags split wins (the split is fixed at booking, ARCHITECTURE 9.3); the receipt's order-tagged boxes are the fallback when the booking carries no split, and the single carried order is the last fallback. Proportional to the received kg, so the tags can never exceed it.</li> <li>Q331 2026-10-30 C364 How does the stock report treat a pre-C364 tagged issue that has no earmark to draw (a negative per-order ledger), and over-drawn WIP?</li> <li>A331 2026-10-30 A negative ledger is folded back into free kg (and its value), so free + earmarked = total always equals the physical stock; WIP stays the earmarked kg already issued to a live order, shown beside the balance, exactly the old column's meaning.</li> <li>Q332 2026-10-30 C367 A lot's yarn share: yarn is earmarked on the PO with no segment tag — how is it split across lots?</li> <li>Q333 2026-10-30 C367 When a PO has several lots, how is the SO assignment split and how do pre-C367 lots (no pick/segment) complete?</li> <li>A332 2026-10-30 Pro rata by the lot's delivered mtrs over the PO's delivered mtrs — the earmark carries no segment tag, and a new tag column would be a schema change the row did not ask for; reversible, fewest files.</li> <li>A333 2026-10-30 Assign pro rata by each lot's sellable mtrs, each apportionment at that lot's own unit cost; a pre-C367 lot with no pick/segment falls back to the old single PO pool row so old orders still complete.</li> <li>Q334 2026-10-30 C365 The booking picker only offers open SO / JW orders, so which target carries the yarn earmark leg — any order the booking is against, or only a production order?</li> <li>A334 2026-10-30 Only a production order (role 'po' or type PROD) carries the yarn bucket. An SO / JW target keeps its own cost basis (orderCost, recordCostBasis) as today — a JW order is customer yarn and never takes a cost leg, an SO's yarn cost stays on its locked basis; the PO is priced when procurement earmarks a booking to it from the PO record.</li> <li>Q335 2026-10-30 C365 The Against split posts bags per order (C195, parts must add to the total bags). Should the earmark add a kg input per order, or derive the kg from bags x bag weight?</li> <li>A335 2026-10-30 Keep the split in bags (one owner per number, the existing C195 rule that the parts add to the total bags stays true) and derive the earmark kg = part bags x bag weight on the server, so the earmark always adds back to the booking's net kg.</li> <li>Q336 2026-10-30 C365 Does a free-stock draw also move the physical kg (a pool out entry), or write the cost leg only?</li> <li>A336 2026-10-30 The draw writes the cost leg only, at the free WAC that moment; the physical kg still leave on the gatepass / weft issue, which moves quantity and prices nothing (one writer per book). This is reversible: the leg is append-only and a draw never re-prices an earlier one.</li> <li>Q337 2026-10-30 C368 On a fabric-in lot the rolls carry no beam, so which traceability does the checking screen accept for a lot roll — the beam, or the lot?</li> <li>A337 2026-10-30 The lot is the traceability: a roll that came in on a fabric-in lot (fabric_in_id set) grades with no beam, and keeps its WIP location; a roll off a loom still needs its beam.</li> <li>Q338 2026-10-30 C368 Does the checked-mtrs figure on the grading record count the lot's still-WIP rolls, which have not been checked yet?</li> <li>A338 2026-10-30 Only graded (non-WIP) rolls count as checked, plus the roll being saved; a WIP roll has not been checked yet, so the figure is the checked metres of the lot at that moment — X rolls included.</li> <li>Q339 2026-10-30 C369 A beam row carries no tippan link, so what proves the sizing bill the row refuses to transfer without?</li> <li>A339 2026-10-30 The transferring PO's own sizing cost leg (kind sizing, any status) is the bill: a beam whose PO carries no sizing leg has no carried cost to compare a market value against, and the transfer is refused with that reason. Reversible: the leg is the costing record, not a new field.</li> <li>Q340 2026-10-30 C369 The existing C6b form can transfer a beam to the SAME contract (a sizer-to-sizer intimation). Should that path now demand the three typed market rates too?</li> <li>A340 2026-10-30 No. A same-contract move stays the C6b intimation it is today: no cost legs, no rates, no sizing-bill gate. The typed market value applies only when the receiving contract differs — the row's PO-to-PO move. Existing behaviour kept, no new required fields on the old path.</li> <li>Q341 2026-10-30 C369 The row names 'that day rate sheet for warping', but the rate board (rate_sheet/rate) carries yarn ₹/kg only. Where does the warping hint come from?</li> <li>A341 2026-10-30 The latest warping cost leg on a live PO (₹/kg, amount ÷ kg) is the day's warping market; the rate board supplies the yarn hint (latest row for the beam's count + type) and the yarn master the sizing hint (siz_rate). All three are labelled with their source beside the field and the typed figures are stored as the authority.</li> <li>Q342 2026-10-30 C370 There is no in-place quote edit in this app (Reuse and Re-quote both save a NEW quote) — where must the 'quote cannot be revised after the SO exists' refusal live?</li> <li>A342 2026-10-30 Keep the freeze where a second SO would re-link the same quote: the order action refuses a quoteId a live (non-cancelled) SO already carries, with quoteRevisionError naming the SO. In-place quote edits do not exist, so nothing else needs a guard — Reuse/Re-quote already save a new quote. Fewest files, reversible, no new surface.</li> <li>Q343 2026-10-30 C370 Where does the budget snapshot live — a new po_budget table/migration, or the existing po:planned event payload?</li> <li>A343 2026-10-30 Snapshot into the existing po:planned event payload (soOrderId already lives there, it is the PO birth record and append-only) rather than a new table: no migration, no schema drift, and a later quote edit can never move a budget already taken. poRecord reads the same payload back; old POs simply have no budget.</li> <li>Q344 2026-10-30 C371 Where do the apportionment row's committed leg rates live — a new column on cost_apportionment, or read from the delivering PO's own cost legs?</li> <li>A344 2026-10-30 Read live from the delivering PO's cost_leg rows plus its own ₹/pick (order.jobRate) — no schema change, no migration. A later bill then moves the PO's own cost and lands as a variance on that PO instead of re-pricing the sale that is already locked, which is exactly 9.5.</li> <li>Q345 2026-10-30 C371 When a delivering PO has several fabric-in lots at different picks, which pick prices the sale's weaving leg?</li> <li>A345 2026-10-30 The fabric-in lots' own picks weighted by their metres (the fabric actually delivered), falling back to the order's planned pick and then to the line's stored pick. One rate per line keeps the reading explainable; a per-lot split waits for a row that needs it.</li> <li>Q346 2026-10-30 C372 A cancelled PO's cost legs — should the provisional yarn leg (and any provisional sizing/weaving commitment) be reversed or zeroed so the cancelled order carries no cost, or do the legs stay as posted?</li> <li>Q347 2026-10-30 C372 What does the cancellation's conversionAccrued figure report — nothing at all (as today), or the cost already posted as actual against the order (a beam transfer variance, a bill), with provisional commitments excluded?</li> <li>A346 2026-10-30 The legs stay exactly as posted: cancelling adds the pool pair and the status change only, never an edit or a reversal of a committed leg (append-only). Reversing the yarn earmark is a separate correction if the owner wants it, so the safe 80/20 is to leave cost legs untouched.</li> <li>A347 2026-10-30 conversionAccrued reports the cost already posted as actual against the order (a beam transfer variance leg, a bill), yarn excluded because the yarn goes back to free stock at its own cost; a provisional leg is a commitment that never started and is not charged. This is the existing event field, now filled from the order's own legs instead of a hardcoded 0.</li> <li>Q348 2026-10-30 C373 An allocation cannot exceed the PO open committed leg — does that forbid recording a vendor invoice higher than the commitment (a rate-hike bill, today a rate variance)?</li> <li>A348 2026-10-30 Literal: a share may not exceed the leg's open committed amount. An invoice above the commitment is committed first (supplementary leg / amendment) and billed after; the bill screen never raises a commitment silently. Append-only has no in-place raise, and the row states the cap.</li> <li>Q349 2026-10-30 C373 Paste-a-bill-list has no way to name orders — does the bulk import keep auto-spreading, or must each pasted line carry its shares?</li> <li>A349 2026-10-30 Each pasted line carries its own shares after the (optional) quantity: 'M-1042, 2026-10-01, Sizing Mills, sizing, 50000, 5, 300, PO-1:30000, PO-2:20000'. A line with no share is reported and skipped, never spread — one manual rule for every entry path.</li> <li>Q350 2026-10-30 C373 Is an allocation keyed by PO (one row per order, summed over its open legs of the kind) or by the open committed leg (two rows for a PO carrying two legs of one kind)?</li> <li>A350 2026-10-30 Keyed by the open committed leg, which is the row's own wording: each leg row shows its PO, open quantity and committed ₹, and a PO carrying two open legs of one kind is two commitments and gets two inputs. Amounts are then exact per leg with no hidden split.</li> <li>Q351 2026-10-30 C373 Acceptance says the unallocated bill is refused by the action — is a test through recordBill (which the action calls) enough, or does the test have to drive the route action itself?</li> <li>A351 2026-10-30 recordBill is the refusal: actions.create only forwards its error to fail(400). A route-level test would need a better-auth session for zero extra coverage, so the test drives recordBill — the same code the action calls — and reads the leg table back.</li> <li>Q352 2026-10-30 C374 D18 named no enum values: which delivery terms and which letter for 'inside the rate'?</li> <li>A352 2026-10-30 Four standard terms — ex-mill (buyer collects), FOB, CIF (freight + insurance inside), DDP (delivered, duty paid) — and two recoveries, on-top (excluded, buyer bears, the default) and in-rate (inside the quoted rate). Slugs stored as-is so both surfaces and the SO print the same list.</li> <li>Q353 2026-10-30 C374 Does a quote-carried SO still demand brokerage/pass-on from sales when the quote carries none?</li> <li>A353 2026-10-30 No — a quote settles them, so the quote-carried SO skips their requiredness and takes the quote's value (blank stays blank; the SO never invents a commercial term). Non-quote orders keep the existing required pair and the direct 1%/1% convention.</li> <li>Q354 2026-10-30 C379 C378 (tolerance % field on the SO form) is still pending, but this row needs the band now — where does the tolerance live?</li> <li>A354 2026-10-30 Add the column now as order.tolerance_pct (one additive migration, blank reads 5%) so the band can be enforced this row; C378 then only adds the form field, its validation (soTolerancePctError, 0-20%) and the two delivery dates — no rename, no second migration for the tolerance.</li> <li>Q355 2026-10-30 C376 Should the 'days open' column measure from quote creation (used here) or from the quote's last follow-up?</li> <li>A355 2026-10-30 Days open = whole days since the quote was created (created_at): it is the quote's age on the board, already stored, and needs no new column. Additive reading added to the shared order load.</li> <li>Q356 2026-10-30 C380 When a dispatch leaves less covered than apportioned, is the excess measured against the apportioned metres or against the ordered quantity?</li> <li>A356 2026-10-30 Against the apportioned metres: released = apportioned - dispatched, at each line's locked cost. Measuring against the ordered quantity would now over-release up to the band's width, because cover may sit below the quantity and still be complete.</li> <li>Q357 2026-10-30 C377 D25 replaces the SO wizard with four focus steps but the sale also needs a cost cover plan (C346) and payment terms — does the sale keep a slip-OCR step, and where do cover/payment live now?</li> <li>A357 2026-10-30 Four focus steps exactly (D25): the SO asks quantity, rate, tolerance, remark and nothing else. The quote is the SO's only source (D24/C375), so the slip-OCR/lead-link steps retire for the sale; D28's buyer-order image returns with C387. The cost cover plan (C346) is not one field, so it moves out of the wizard into its own card on the SO screen — nothing is lost. Payment terms are not on the quote, so the pinned strip's payment cell opens the existing dhara/slab pickers.</li> <li>Q358 2026-10-30 C383 D9 stores cd_pct + payment_days at booking, but the pending-ops flag's payment leg was due_days (a delivery deadline, D13). Should the flag read the stored payment pair instead of due_days?</li> <li>Q359 2026-10-30 C383 The row asks for a test, but the repo's Bun suite was removed (7668c583) and bunfig.toml still roots at the absent tests/, so no tests/ file can run. Is an action-level proof script the accepted substitute until the suite returns?</li> <li>A358 2026-10-30 Read the stored pair: the ops-pending payment leg is isNull(cdPct) OR isNull(paymentDays), never due_days (a delivery deadline, D13). Stored by booking from the slab; the /orders filter now delegates to the one condition.</li> <li>A359 2026-10-30 Yes: the action-level proof script is the substitute. The suite was deleted upstream and its bunfig root is gone, so a tests/ file cannot run; re-adding the suite is its own row.</li> <li>Q360 2026-10-30 C387 Which field carries the planning card's consignee before C381 links it to the party master?</li> <li>A360 2026-10-30 The existing dispatch_city field carries it on the planning card (free city/depot text, blank = decide at fulfilment); C381 replaces it with the Others party link, so nothing new is added now.</li> <li>Q361 2026-10-30 C378 Does the record's ops completion ask the two delivery dates instead of the day counts?</li> <li>A361 2026-10-30 No — retire the two day counts from the completion and show the booking window read-only. The SO form is where sales sets the promise; a completion that re-asks it would be a second source of truth (D13). A wrong window is corrected through the existing append-only amend path, not by a second entry.</li> <li>Q362 2026-10-30 C389 Does the Reports order-profitability table keep a row per PROD (production) order now that it reads the sale-order cost engine, and is salvage rolled into its margin?</li> <li>A362 2026-10-30 The table is sale-order profitability: rows are live SOs only, a PROD order is a production P&L (poPnl) not a sale, and its qty x rate is not revenue. Salvage stays out of this report's margin for now: the row asks for cost legs and apportionments, and rolling a damaged child sale in would double-count that child's own revenue row.</li> <li>Q363 2026-10-30 C381 How is the explicit decide-at-fulfilment state stored, and who may be a consignee?</li> <li>A363 2026-10-30 One nullable consignee party link is the whole fact: a blank link IS decide-at-fulfilment (derived, printed on every surface) so no state flag can drift; receiving categories are Others (added) plus Godown and Transport, D7's depot/godown/hub, active parties only; a consignee named at booking is fixed for planning and dispatch, corrections go through the append-only amend path.</li> <li>Q364 2026-10-31 C384 D10/D15 as rules: does the 1,000 m quantity step also bind a damaged (X) sale cut from a parent order, and where does the duplicate-buyer-PO check run (the form carries no list of other orders' PO numbers)?</li> <li>A364 2026-10-31 A damaged (X) sale is exempt from the 1,000 m step — it is cut from a parent sale's stock and its metres are whatever the cut is (the same reading C375 uses to exempt it from the compulsory quote, D21). The duplicate buyer PO is checked server-side at save (create action, plus the record's planning card where the buyer and its PO are filled together), compared case- and space-insensitively with a cancelled order releasing its number; the error already renders on both faces of the form.</li> <li>Q365 2026-10-31 C384 Does the 1,000 m quantity step and the 1-200 picks range also gate the record page's ops completion (validateOpsFields), or only the new-order form?</li> <li>A365 2026-10-31 Only the new-order form. The record's ops completion keeps its legacy leniency (a stated rate above zero, picks a whole positive number) so an order booked before the rule can still be completed; the booking is where D10/D15 bite, and a wrong stored value is corrected through the append-only amend path.</li> <li>Q366 2026-10-31 C381 row-watch: 2 integrations of C381 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q367 2026-10-31 C384 row-watch: 2 integrations of C384 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>A366 2026-10-31 Re rub</li> <li>A367 2026-10-31 Re run</li> <li>Q368 2026-10-31 C392 Does the ops completion drop the send-to city on job-work / outsource / stock orders too, where there is no planning card at all?</li> <li>A368 2026-10-31 Keep the city on the ops card for non-SO orders: D7's consignee and the planning card are sale-order only, so a job-work/outsource/stock order would otherwise have no surface that sets its send-to city at all. On a sale the city is planning's alone and the card shows the consignee instead.</li> <li>Q369 2026-11-02 C386 What counts as the sales stage's pending work, and does the Orders list need its own planning-pending chip?</li> <li>A369 2026-11-02 Keep the existing queue reading: the sales board is SOs still awaiting owner approval (D23 means an ordinary booked SO never sits there), and the Orders list keeps its plain status filter — the stage boards are the work surface (fewest files, reversible).</li> <li>Q370 2026-11-02 C395 Does the SO screen still open a blank form from ?new=1 / a capture draft / a bare lead or party carry, and where does the payment term come from once the six fields no longer ask it?</li> <li>A370 2026-11-02 A normal SO must start from a quote (D23/D24), so the pending-quotes table is the only way in: ?new=1, a capture draft, a lead or a bare party/rate/design/qty carry no longer opens a blank six-field form (a draft still restores once its quote is picked). The payment term is a read-only quote fact: the load hands its dhara id + slab to the form from the quote's own costing snapshot, and a quote with no dhara books none (sales-role bookings then see the route's own payment field error, never an invented term).</li> <li>Q371 2026-11-02 C396 row-watch: 2 integrations of C396 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q372 2026-11-02 C397 The row says the form's four fields, but the SO contract (D29/D30) now has six (qty, deliveryStart, deliveryEnd, rate, tolerancePct, remark) — and which screen is 'the quote table'?</li> <li>A372 2026-11-02 Use the contract's own field list and order (six fields after C395's D29/D30 six-field form); the row's 'four' is pre-C395 wording. 'The quote table' is the pending-quotes table the form route renders without a quoteId — the same screen C395's acceptance calls the table screen — so the quote-no column and the 356 px rule are asserted there.</li> <li>Q373 2026-11-02 C397 row-watch: 2 integrations of C397 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q374 2026-11-02 C398 Scope: the row names the quote screen and the SO focus layer; does 'no popup defines its own width' also cover the damaged (X) sale card, the shared SavedPopup, QuotePreview and the booking/production wizards?</li> <li>A374 2026-11-02 No — only the quote screen's popups (NewWizard, TermsPopup, DharaPopup, YarnPopup, AdjustPopup, QualityPopup, NewSavedPopup) and the sale form's own (wizard, payment dhara, payment slab, single-field popup). The damaged X card is a six-fact form from C390, and SavedPopup/QuotePreview/booking/production belong to other screens the row does not name; converting them adds files without changing either named screen. Reversible: the spec is one file, so a later row converts them by swapping the frame for FocusLayer.</li> <li>Q375 2026-11-02 C398 row-watch: 2 integrations of C398 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q376 2026-11-02 C399 row-watch: 2 integrations of C399 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q377 2026-11-02 C400 row-watch: 2 integrations of C400 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q378 2026-11-02 C401 What is a 'block' for the one-row-per-screen rule — the rows the line works in one pass, or the whole open board?</li> <li>A378 2026-11-02 The open board: the line is serial and works top-to-bottom, so an earlier open row owns the screen and a later pending row on the same component is held until it closes. Reversible, no status invented.</li> <li>Q379 2026-11-02 C401 row-watch: 2 integrations of C401 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>Q380 2026-11-02 C402 A form-block row queued before this rule carries no contract reference in the owner's text (docs/CORRECTIONS.md is not ours to rewrite): may the pre-check note carry the reference, or must such a row be parked until the owner re-texts it?</li> <li>A380 2026-11-02 The note may carry it: refuse only when no docs/contracts/*.json is named in the row text, targets, acceptance or the check's note, and refuse again when the named file is not on disk — so a legacy row is recorded against a real, owner-approved contract instead of parked, and the gate still cannot be satisfied by prose alone.</li> <li>Q381 2026-11-02 C402 row-watch: 2 integrations of C402 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>R371 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>R373 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>R375 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>R376 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>R377 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>R379 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>R381 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>Q382 2026-11-03 C396 row-watch: 3 integrations of C396 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>R382 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>Q383 2026-11-03 C400 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C400?</li> <li>R383 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q384 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?</li> <li>Q385 2026-11-03 C400 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C400?</li> <li>R384 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>R385 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q386 2026-11-03 C400 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C400?</li> <li>R386 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q387 2026-11-03 C400 Which file is 'the SO contract test' that must use assertAbsent?</li> <li>A387 2026-11-03 Both files that assert over the SO contract: orderLogic.test.ts (the screen's spec) already uses it, and src/lib/contracts.test.ts (the contract itself) now imports and calls it directly - no third checker.</li> <li>Q388 2026-11-03 C397 row-watch: 2 integrations of C397 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?</li> <li>R388 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt</li> <li>Q389 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?</li> <li>R389 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q390 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?</li> <li>R390 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q391 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?</li> <li>Q392 2026-11-03 C396 row-watch: 3 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?</li> <li>Q393 2026-11-03 C396 row-watch: 4 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?</li> <li>R391 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>R392 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>R393 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q394 2026-11-03 C401 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C401?</li> <li>R394 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q395 2026-11-03 C402 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C402?</li> <li>R395 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q396 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?</li> <li>R396 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour</li> <li>Q397 2026-11-04 C404 does the suggestion portion also need to close on blur, and should tolerance/remark get the same treatment?</li> <li>A397 2026-11-04 close on a suggestion tap or its own Close, never on blur - blur fires before a chip tap on a phone, and the row names only rate and quantity, so tolerance and remark keep the inline chips they already show</li> <li>Q398 2026-11-04 C408 is the wanted popup the app-wide toast, and does it replace the inline banner or sit beside it?</li> <li>A398 2026-11-04 the app-wide toast, the notify store rendered by Toasts in the root layout (C25 precedent), and it replaces the inline banner - one confirmation, not two</li> </ul> <!----></div></article></div></div><!--]--><!--]--><!--]--><!----></div></main> <!--[-1--><!--]--><!----></div></div><!--]--><!--]--><!--]--><!----> <!--[-1--><!--]--><!--]--> <script> { __sveltekit_1ib7f33 = { base: new URL("..", location).pathname.slice(0, -1), version: "1793797649325" }; const element = document.currentScript.parentElement; import("../_app/immutable/entry/start.DrcVuqU3.js").then(async (kit) => { kit.init(__sveltekit_1ib7f33); const app = await import("../_app/immutable/entry/app.Aj3X7NZp.js"); kit.start(app, element, { node_ids: [0, 19], data: [{type:"data",data:{session:null,path:"/docs/QUESTIONS",search:""},uses:{url:1}},{type:"data",data:{title:"QUESTIONS.md — questions for the owner (append-only)",file:"QUESTIONS.md",html:"\u003Ch1>QUESTIONS.md — questions for the owner (append-only)\u003C/h1>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>FILE OWNERSHIP:\u003C/strong> written ONLY by \u003Ccode>scripts/queue-next.ts --ask\u003C/code> and\n\u003Ccode>--answer\u003C/code> (the runner asks; any session records your answer). Append-only —\none line per question/answer, never edit or delete existing lines.\u003C/p>\n\u003Cul>\n\u003Cli>\u003Ccode>- Q<n> <date> <row> <question>\u003C/code> — the runner asks \u003Cstrong>instead of guessing\u003C/strong>,\nand answers it itself by the Pareto reading (rule 2, \u003Ccode>docs/OWNERSHIP.md\u003C/code>).\n\u003Cstrong>Asking never holds a row\u003C/strong> — the row keeps moving on the recorded call.\u003C/li>\n\u003Cli>\u003Ccode>- A<n> <date> <answer>\u003C/code> — your answer; the row is released back to the\nqueue automatically.\u003C/li>\n\u003C/ul>\n\u003Cp>A question with no matching answer is \u003Cstrong>OPEN\u003C/strong> and appears on \u003Ccode>/queue\u003C/code>\n(top banner + the row's "Needs your action" cell). While \u003Ccode>/queue\u003C/code> is open,\na new question also raises a browser alert if you granted permission.\u003C/p>\n\u003C/blockquote>\n\u003Ch2>Feed\u003C/h2>\n\u003Cul>\n\u003Cli>(empty — questions appear here as the runner hits an ambiguity)\u003C/li>\n\u003Cli>Q1 2026-09-27 C100 Build the one-field-per-popup split of the /orders/new sales wizard now, or wait for the payment-dhara change to land first? Your own wording says "land after C99", and C99 is not built yet, so the payment popup this row asks for does not exist: split it now and that popup can only hold today's "Buyer pays in (days)" box, which C99 then deletes and replaces with the dhara picker.\u003C/li>\n\u003Cli>R1 2026-09-27 C100 resolved by assumption (PLANNING §307): proceeding on the reading recorded on the row — build the one-field-per-popup split now, leave the payment field to C99. No answer needed unless the owner disagrees; reopen C100 to change it.\u003C/li>\n\u003Cli>Q2 2026-09-28 C113 On /drafts: should the one-tap 'Create SO / sample / booking / lead' buttons become links that open the form prefilled (the C113 reading of 'nothing auto-committed'), or stay as they are alongside the new prefill links? They are pre-existing, owner-visible behaviour with a test behind them (p4-commercial), so I did not remove them.\u003C/li>\n\u003Cli>R2 2026-09-28 C113 resolved by assumption (PLANNING §307): keeping /drafts' one-tap Create buttons (a working, owner-visible screen with a test behind it) and adding the "Open the \u003Cform> form filled in" link beside each, so the OCR path itself never commits. No answer needed unless the owner wants the buttons removed; reopen C113 to change it.\u003C/li>\n\u003Cli>Q3 2026-09-30 C139 space-bunny-free is the free tier, so a busy capture hour can be rate-limited and reads then fall back to local OCR / typed entry. Should photo reads move to a paid model on the same gateway (same key, one setting change) so scanning never degrades? The row proceeds on the free-tier default meanwhile.\u003C/li>\n\u003Cli>A3 2026-09-30 Owner 2026-09-30: use ONLY space-bunny-free (space-bunny). No paid model, one setting change never made. When space-bunny is not available (unset, unreachable, rate-limited, or the answer comes back empty), the read stops there and the user enters the order in by hand — the app must say so plainly and must never silently prefill from a weaker reader.\u003C/li>\n\u003Cli>Q4 2026-09-30 C148 Two readings to confirm on the removal: (1) should the quote/lead carry stay working silently (form opens prefilled from a quote/lead and stores the reference, but the salesperson is no longer asked to pick one) — that is how the row reads it, because Reuse/Convert/dictation depend on it; (2) where should sales promise (promised days) and tolerance be asked now — production/ops completion (the row's reading, following C147), or nowhere at all? The row proceeds on both readings meanwhile.\u003C/li>\n\u003Cli>A4 2026-09-30 Owner 2026-09-30: for the quote and lead, the TRADING SO keeps them; the PRODUCTION ORDER and JOB WORK SO do not need them (and the docs' per-form field list is the authority for what each form carries). Sales promise and tolerance are unchanged by this answer — the row keeps its reading that they are asked where production/ops completes the order (C147).\u003C/li>\n\u003Cli>Q5 2026-09-30 C152 Delete is implemented as a RECORDED CANCELLATION appendage with owner approval (the signed rule says never overwrite or erase a committed document, so a true hard delete is not done). Is that right, or do you really want a hard delete that erases the row? Also: Edit opens the same order form prefilled from the saved order and saves as an appendage (before -> after per field + reason). The row proceeds on the appendage reading meanwhile.\u003C/li>\n\u003Cli>A5 2026-09-30 Owner 2026-09-30: the UI may carry a DELETE button, gated on owner approval, but the DATABASE ONLY APPENDS — no record is ever deleted and everything has to stay in the system. So Delete writes a recorded cancellation appendage (the row remains, flagged cancelled/deleted, still listed and openable, with its full before/after history), and Edit writes a recorded before->after appendage. No hard delete anywhere.\u003C/li>\n\u003Cli>Q6 2026-09-30 C163 When a field is NOT important (compulsory+no-default rule), where does the user change it? (a) it keeps its own single-field popup opened from the summary row, or (b) it stays inline on the page as it is today, or (c) it is not offered for change at all. I am taking (a): the one-at-a-time wizard holds only the important fields, and a non-important field still opens in its own small popup so nothing becomes un-editable. Also: does 'the wizard' mean only the one-field-at-a-time step sequence (my reading — the summary and popups stay), or the whole summary+popup screen?\u003C/li>\n\u003Cli>Q7 2026-09-30 C163 Does a value that fills itself in count as 'a default value set'? Three common cases: (1) the system date, which is automatic and read-only — I treat it as a default, so no step; (2) a prefill the user must still confirm and can change, e.g. party carried from an enquiry or today's date prefilled — I currently treat it as STILL important, because the user has to confirm it; (3) a suggestion chip value like 'last used rate' that is only filled if tapped — I treat it as important. If you intended any prefill to drop the field out of the wizard, tell me which case and I will reword the rule.\u003C/li>\n\u003Cli>A6 2026-09-30 C163 — confirmed (a). "The wizard" means ONLY the one-field-at-a-time step sequence; the read-only sectioned summary and the small single-field popups stay exactly as they are. A field that is not important (not compulsory, or a default fills it) is NOT a wizard step — its summary row still opens its own single-field popup so the user can change it, so nothing becomes un-editable.\u003C/li>\n\u003Cli>Q8 2026-09-30 C164 If a pre-check finds a doubt and the question is still unanswered, does the row wait for your answer before a worker may start, or does it go to the worker on the written assumption (the existing rule that asking is not a stop)? I am taking: the pre-check RECORD is required, but an open question does not hold the row — it goes to the worker with the question and its assumption attached, and only the hard-stop list (deleting data, money or costing maths, breaking a MUST NOT, deploying to production, changing what a customer is charged) waits for you. If you want a genuine question to hold the row until you answer, say so and the builder will gate on it.\u003C/li>\n\u003Cli>A7 2026-09-30 C163 — cases (1) system/automatic date, (2) a prefill the user must still confirm, and (3) a suggestion-chip value like 'last used rate' are all correct as stated (important / not important exactly as the question put them). Plus a fourth case the owner added 2026-09-30: a field the OWNER has instructed a standing default for — e.g. 'keep other cost as 5.5% by default in the quote form' — IS a default value set, so it needs no wizard step at all; where such a field currently has a wizard step, the rule means it comes out of the wizard (keeping its value and its own single-field popup so it stays changeable).\u003C/li>\n\u003Cli>Q9 2026-09-30 C163 For a field that has an owner-instructed default (like other cost 5.5% in the quote form), does the new rule apply only from the next rollout onwards, or should the already-shipped forms be swept now to pull such fields out of their wizards? What I found while checking: in the quote form today Other exps 5.5% is NOT a wizard step — it is one of the ten rows inside the 'Adjust' popup, so that form already matches the rule; the tippan wizard's steps are all genuinely compulsory (sizer, weaver, quality). So a sweep may be a no-op. I am taking: the rule applies from the next rollout onwards (this row stays docs-only), and any specific shipped form you want a field pulled out of its wizard is its own small row so the shipped UI is not changed quietly.\u003C/li>\n\u003Cli>Q10 2026-09-30 C165 Which document is 'the full flow doc' for this rule? I am taking src/static/full-flow.html — the exhaustive flow-by-form-by-field map, whose last column is 'ALL fields on the form — mode' and which your own audit crew (logged 2026-09-07) called the bible — as the per-form field checklist, with docs/YARN-FLOW.md (the prose flow: Trading SO, stock and sell, job work) read alongside it. If you meant a different document, tell me the name and the rule will point there instead.\u003C/li>\n\u003Cli>Q11 2026-09-30 C165 If the full flow lists a field that the form has never had — so putting it on the form means a new column and a database change — do you want that added as part of the UI work, or as its own separate change afterwards? I am taking: the UI work only guarantees no field that already exists is lost, and every full-flow field is accounted for in the written list; a brand-new field needing its own database change is queued separately with its own migration, because the focus-entry work is UI-only and must not touch the database or the saved values. Say so if you want it added in the same go.\u003C/li>\n\u003Cli>A8 2026-09-30 C164 — most things get an intelligent guess, taken in the checking session and written down, and the row keeps moving (asking is not a stop). Only when the checker genuinely cannot make a reasonable reading and needs the owner's approval does the row WAIT and is NOT sent to a worker. So: a pre-check record is required either way, but an open question is not itself a hold — the hold is a deliberate decision the checker makes when it cannot decide, not a side effect of the row's wording.\u003C/li>\n\u003Cli>A9 2026-09-30 C163 — correct as assumed: the important-field rule applies from the next rollout onwards and this row stays docs-only; no shipped form's wizard is swept now. Any specific shipped form where the owner wants an owner-defaulted field pulled out of the wizard is its own small row, so a live UI is never changed quietly.\u003C/li>\n\u003Cli>A10 2026-09-30 C165 — correct: the full flow doc is static/full-flow.html (at the repo root, served at /full-flow.html), the exhaustive flow-by-form-by-field map whose last column is 'ALL fields on the form — mode'; docs/YARN-FLOW.md (the prose flow) is read alongside it. (My question text said src/static/full-flow.html — the file is static/full-flow.html; the row already has the right path.)\u003C/li>\n\u003Cli>A11 2026-09-30 C165 — add it in the same go. So when the full flow lists a field for a form and the form does not have it, the focus-entry work ADDS that field in the same change, with the database change it needs (the new column, its migration, and the server read/write of it) — it is not deferred to a later row. The field goes on with the mode the full flow lists (number pad, tap-select, text, suggestion, auto) and, where the flow says it is filled automatically or by default, that default is applied. Existing field names, existing validation and saved history stay exactly as they are.\u003C/li>\n\u003Cli>Q12 2026-10-01 C154 C154 — the order form can now KEEP a contract PDF or photo with the order (per file: 'read it' for the form, or 'just attach'), and I opened both screens and they are right, but it is NOT on the live site: nothing can ship while the line's own checks are red, and the red is other work — the order-form focus-entry move now in flight (two order-form checks read markup that has already moved) plus two board/reaper checks. Do you want those checks brought back in line so the next release carries C154, or should C154 wait until the order-form work lands?\u003C/li>\n\u003Cli>A12 2026-10-01 C154 waits for the order-form focus-entry work to land (C157); do not bring the checks forward for it. Worker moves on to the next row in the queue now. The two red order-form summary-row pins are stale reads of markup C151 already changed, so they are queued as their own row (C176) and fixed there, not inside C154.\u003C/li>\n\u003Cli>Q13 2026-10-01 C178 Which control did you mean by 'queue beam slot starts decending from 999'? (a) the beam-quantity slot wheel on an order form - the 'Beams or metres' popup, 1 slot = 1 beam; (b) a numbered list/queue of beams stamped 999, 998, 997; or (c) a different wheel such as the rate wheel (0-999)?\u003C/li>\n\u003Cli>A13 2026-10-01 Owner 2026-10-01: (a) — the beam-quantity slot wheel on an order form, the 'Beams or metres' popup where 1 slot = 1 beam. So the beam slots must read 1, 2, 3 ... upward, opening on slot 1 for a fresh order; the rate wheel (0-999) and every other wheel keep their ranges and their order.\u003C/li>\n\u003Cli>Q14 2026-10-01 C175 C175 is built, live and verified — one thing only you can settle. The beam card's wizard has THREE steps (flange no, set no, cuts); contract, party and loom are summary rows you can tap into instead, because a floor-stock beam has no contract and the loom comes later. Is that the right split, or should the loom tap be a step too? And the C6b beam transfer stays a kept entry on the record (four fields, each opening a small popup) rather than a wizard of its own, as the correction described.\u003C/li>\n\u003Cli>R4 2026-10-01 C175 resolved by assumption (PLANNING §307): the row ships as built — THREE wizard steps (flange no, set no, cuts), every other field (contract, party, loom, the mill lot, design, ends, total mtrs, warp/weft/weave) a changeable summary row with its own one-field popup, the flow's 【A】 fields (beam no, beam meter → woven → shrinkage → card mtr, status, rolls/pieces, kinari) read-only static rows with NO new column, and C6b a kept entry on the record rather than a wizard of its own. The step set is one line to change (WIZARD_IDS in src/lib/components/beam/BeamCardEntry.svelte) plus the PLANNING §336 C175 table; no answer needed unless the owner disagrees — reopen C175.\u003C/li>\n\u003Cli>Q15 2026-10-02 C191 A beam going out to a REPAIRER has no row in the full flow (the beam rows are B0, B0b, C2, C3, C4, C6, C6b). Should it get its own flow row - and if so is it a gatepass, a movement (B5 covers returns from production), or part of C6b's reassign - or should the BEAM_REPAIR gatepass kind be removed?\u003C/li>\n\u003Cli>Q16 2026-10-02 C192 A beam going back to its PARTY has no row in the full flow, but B5 movements already lists 'returns to party'. Should BEAM_RETURN fold into B5 movements, get its own flow row, or be removed as a gatepass kind?\u003C/li>\n\u003Cli>Q17 2026-10-02 C193 The gatepass WINDING kind (yarn sizing -> winder) has no flow row of its own - C5 covers the winding in/out form on /winding. Is 'sizing -> winder' its own gatepass row in the flow, or part of C5's winding in/out?\u003C/li>\n\u003Cli>Q18 2026-10-02 C180 Tapping a summary row that is not a wizard step should now open that field's own single-field box. I am doing this for every field you can actually type or choose. A few summary lines are deliberately not typable and I am leaving them as plain read-only lines: the System date (the server stamps it, so nobody can move it), Status (always reads 'open - auto'), the order kind itself, the Buyer's name on a production order (a stocking order has no buyer), the two Payment boxes on a job-work order (they are opened by their own Payment box, and the earlier correction C138 deliberately keeps them out), the Job-work brokerage % (also deliberate under C138), the attached slip file, and the draft link. Do you want any of THOSE to become editable in their own box, or is leaving them read-only right? Say which and each becomes its own small row.\u003C/li>\n\u003Cli>A14 2026-10-02 Pareto call, no code change: keep the 3-step wizard (flange no, set no, cuts); loom stays a summary tap since the loom is not known at card-entry time and a forced step would block saving. C6b stays a kept entry. Reopen C175 if loom should become step 4.\u003C/li>\n\u003Cli>A15 2026-10-02 Pareto call: keep BEAM_REPAIR as a B5 movement (beam out to repairer, back from repair); no new flow row, flow doc untouched. Removing a working kind would strand existing slips.\u003C/li>\n\u003Cli>A16 2026-10-02 Pareto call: fold BEAM_RETURN into B5 returns-to-party; keep the kind, no new flow row.\u003C/li>\n\u003Cli>A17 2026-10-02 Pareto call: WINDING stays part of C5 (the gatepass is C5's transport leg); no separate flow row.\u003C/li>\n\u003Cli>A18 2026-10-02 Pareto call: leave all of them read-only for the reasons listed (server-stamped, auto, inapplicable, or deliberately excluded under C138). Any single one can become its own small row on request.\u003C/li>\n\u003Cli>Q19 2026-10-02 C182 The MODE flag is asked in two places - the trading SO order form and the production operations 'trading' side popup. Taking it off the SO alone would leave the same question on the second form. Do you want it removed from BOTH, and does operations keep choosing it on the order RECORD page (where the value is recorded after the fact)?\u003C/li>\n\u003Cli>A19 2026-10-02 Pareto call: BOTH entry faces go - the flag is literally the same question twice, and the row's own reading is that it decides nothing. The order RECORD page's operations completion KEEPS its mode control: that is where the value is recorded once it exists, it is not an order-entry question, and MUST NOT (nothing stored is cleared, the column keeps being written) forbids removing the control whose POST value is what populates it. If operations should never choose it either, that is a new row and it must land together with dropping put('mode', ...) on the record, never separately.\u003C/li>\n\u003Cli>Q20 2026-10-02 C183 Which fabric master is the booking's fallback when the yarn master GST is blank and the booking has NO linked order (pending bucket)? The booking form picks a design only through the order.\u003C/li>\n\u003Cli>A20 2026-10-02 No fabric, so the field stays blank — exactly today's behaviour (schema default 5 on save). The booking form's only route to a fabric is the linked order, so inventing one (last design, a setup default) would guess at money and touch nothing else. A booking later attached to an order can be corrected by the owner through an amendment.\u003C/li>\n\u003Cli>Q21 2026-10-03 C198 Should the fix delete the cheap fingerprint entirely and evaluate the board on every POLL tick, instead of adding a HEAD term to it? And should the loop self-heal by force-touching a board file when it wakes, rather than relying on a detector at all?\u003C/li>\n\u003Cli>A21 2026-10-03 Keep the detector and add the missing term. The fingerprint exists to stop this 2-vCPU/6 GB host re-reading the board every 10 s forever (C123 put the thermal ticks in this loop for exactly that host), so unconditional evaluation is a regression dressed as a fix. The correct reading of 'why did a completed row not wake the line' is that the detector was blind to the one thing a completed row always does - commit - so HEAD joins the four board docs, the reap tick stops swallowing the evaluation, and the stall alarm moves above the skip. No self-touch: touching a board file to wake one's own watcher makes the doc's mtime meaningless as a change signal and hides real drift. If the owner ever wants always-evaluate, that is the same three edits with the skip deleted.\u003C/li>\n\u003Cli>Q22 2026-10-03 C185 with the save gate gone from the yarn booking, does the summary's '✓ \u003Csource>' chip stay tappable (marking the field as read, now that nothing waits on the mark), or does the chip become a plain source label with no tap? BookingSummary.svelte is a named target of this row.\u003C/li>\n\u003Cli>A22 2026-10-03 The chip stays tappable and keeps marking the field read (confirmSrc writes okayed, never a value). Keeping it: existing behaviour, fewest files, trivially reversible; the mark still answers the owner's 'which of these did I look at?' and C184 pins that wiring on the summary's clear/save bar. BookingSummary.svelte therefore needed NO change - the row named it, the fix did not. If the owner wants a dead tap, that is a one-line follow-up row, not this one.\u003C/li>\n\u003Cli>Q23 2026-10-03 C186 G0's confirmation evidence has no gatepass column of its own. Where does it persist?\u003C/li>\n\u003Cli>Q24 2026-10-03 C186 FocusEntry calls onfile(id, file) but the page passed a one-arg handler, so the GP photo posted the field id as the file. Route by id as part of adding a second photo field?\u003C/li>\n\u003Cli>A23 2026-10-03 Rides the creation event payload, read off raw FormData exactly as beamType (no zod change, no column, no migration). The record shows the GP photo in gatepass.image and the evidence beside it on the gatepass:YARN_IN creation event, which the detail page already reads for beamMtrs/beamEnds/beamQuality.\u003C/li>\n\u003Cli>A24 2026-10-03 Yes — route by id. FocusEntry already passes (id, file); the handler ignored the id, so the existing GP-photo upload appended the string 'image' as the file. One handler, if (id === 'confirmPhoto') evidence else gpImage. Nothing else about the image field changes: same id, same state, same POST name, same column.\u003C/li>\n\u003Cli>Q25 2026-10-03 C187 G0b's close-out has no home. Does it land on the DIRECT gatepass intimation form (this row), or on the inward screen, where the premises=inward leg lives?\u003C/li>\n\u003Cli>Q26 2026-10-03 C187 The signed post-delivery GP counter-copy is a tap field 【T】 with no gatepass column. Add one new append-only POST name for it (read off raw FormData onto the creation event, as C186's confirmPhoto does), or carry it on a field that already posts?\u003C/li>\n\u003Cli>A25 2026-10-03 Pareto call: on the DIRECT gatepass intimation form itself, DIRECT only, in its own after-delivery section beside the confirmation photo. G0b's close-out is named on the intimation row (the same row that carries count/bags/expected date), so the person who intimated it is the one who ticks the counter-copy signed when it comes back; C169's inward screen owns the premises=inward leg and is left untouched, so the two do not both claim it. Nothing in /inward or src/lib/components/inward/ changes.\u003C/li>\n\u003Cli>A26 2026-10-03 Pareto call: one new append-only POST name, counterCopy, read off raw FormData and persisted on the creation event exactly as C186's confirmPhoto (no zod field, no column, no migration, so no server validation change). A value carried on an existing name would be stored under the wrong meaning and the tap would still vanish; the append-only list grows by one entry at the end, so no existing name moves or changes, and C186's pinned name list gains that one appended entry.\u003C/li>\n\u003Cli>Q27 2026-10-03 C188 B0b's list names the taps, the actual date and the transporter — no consignee sizer — but a gatepass has to name a destination and B0 lists the sizer as B0's own field. Should 'To sizer' stay a required step on the beam-out gate tap, or is the tap meant to be strictly the three fields B0b writes?\u003C/li>\n\u003Cli>A27 2026-10-03 KEEP 'To sizer' as the one required pick. A gatepass with no destination is not a document, and zod already refuses a record with neither source nor target party (schema.ts:139), so dropping the row would break creation, not simplify it. B0 lists the consignee sizer, so it is already known before the beams move — picking it at the gate is a one-tap reconfirmation, not the re-entry of a planner number, which is what this row removed. It stays a wizard step because it is compulsory and has no default; the four fields this row took off the tap (#beams, beam type, expected date, vehicle) all keep their POST names, zod fields and columns, so nothing stopped storing them.\u003C/li>\n\u003Cli>Q28 2026-10-03 C189 With YARN_OUT's goods block gone, goodsSectionShown is false, so the 'From booking (expected delivery)' prefill row also disappears from the yarn-out form (it did the same for BEAM_OUT in C188). Keep that row on YARN_OUT with a caption trimmed to what it still fills, or let it go?\u003C/li>\n\u003Cli>Q29 2026-10-03 C189 B5b's last clause is 'receiver confirms like a GP 【A】'. Does B5b need its own surface for that confirmation on this form, or is the shared static Status row already the answer?\u003C/li>\n\u003Cli>A28 2026-10-03 Pareto: let it go, exactly as C188 let it go on BEAM_OUT. The booking picker fills party, count, ticket, mill lot, bags and cones/bag - i.e. precisely the six fields B5b never listed, so on this form it would fill nothing the user can see except the contract. It is also unreachable with a booking: ?bookingId= forces YARN_IN server-side (resolveKind), so an outward gatepass never arrives carrying one. No server change, no new field; the contract row (sourceOrderId) stays and is still pickable by hand.\u003C/li>\n\u003Cli>A29 2026-10-03 Pareto: no new field. The receiver confirming like a GP is an act on the record, not a value typed at the gate, and the shared static Status row already carries it ('Entered - picked (partial/all) - delivered - confirmed - reconciled'). A separate confirmation field would store a second, competing meaning for one status, and G0's own confirmation PHOTO is C186's confirmPhoto on the inward leg, which this row leaves alone. So the only surface this row adds is the static row that names where the six removed fields went.\u003C/li>\n\u003Cli>Q30 2026-10-03 C190 C3 step 1's quality field: PLANNING 336's C168 table lists it 【OCR→S】 (a suggestion/pick), but the widget is a free-text box with no option list, and the sibling C3 step-1 surface (/sizing, C173) already landed it as 【OCR/X】. Which code does the gatepass kind carry?\u003C/li>\n\u003Cli>A30 2026-10-03 Answered by Pareto (C190): 【OCR/X】 — the badge must describe the widget the guard actually gets, and a free-text quality box has no suggestion list to offer; the same three values then carry the same codes on both C3 step-1 surfaces (/sizing and the BEAM_IN gatepass), which is what a second reader comparing the two screens needs. Mtrs stays 【OCR→N】 and ends plain 【OCR】 exactly as the C168 table lists them. If the owner wants a suggestion list on quality, that is a flow change first and a chips/options field after — not a badge.\u003C/li>\n\u003Cli>Q31 2026-10-03 C190 BEAM_IN must keep the hishob out (the row's MUST NOT). The kind hint already says "full hishob later", which is prose only. Should the form also carry a static row naming C3 step 2 as the hishob's home, the way C188's B0b row and C189's B5b row name where the removed fields went?\u003C/li>\n\u003Cli>A31 2026-10-03 Answered by Pareto (C190): yes — one static row, "Full hishob (not this gate tap)", naming C3 step 2. It is the pattern C188 and C189 already set on this same file for fields a kind does not ask, it adds no POST name, no column, no zod field and no yardage booking, it keeps the row's own MUST NOT true in the strongest available way (the screen itself says the hishob is elsewhere), and it is trivially reversible by deleting one object literal. Left alone: the hishob maths, the sizing receipt screen (C173's), every POST name and every stored value.\u003C/li>\n\u003Cli>Q32 2026-10-03 C191 C191 The BEAM_REPAIR kind (?kind=BEAM_REPAIR — to repairer, beam taps, set no) has NO row in static/full-flow.html: the beam rows are B0 (out intimation), B0b (out taps), C2 (outward, guard taps), C3 (sizing receipt), C4 (out-house ledger) and C6/C6b (card + reassign), and none of them is 'a beam goes out to a repairer', so per C165 the form carries fields the flow does not list. Should a beam sent to a repairer be its own flow row — and if so is it a gatepass, a MOVEMENT (B5 covers yarn: returns from production, barcodes/kg/cones), or part of C6b's beam reassign — or should the kind be removed?\u003C/li>\n\u003Cli>A32 2026-10-03 Pareto call: BEAM_REPAIR is its OWN flow row, and it is a GATEPASS — not a movement, not part of C6b. PLANNING §28 already settles it in the owner's own words: 'BEAM OUT FOR REPAIR: new beam movement via the gatepass system (intimation -> guard taps -> GP; return after repair)' — the gatepass system, i.e. a doc, not a B5 movement (B5's list is yarn stock: barcodes, kg, cones, reason codes, owner/contract flips) and not C6b (which is a CONTRACT/sizer reassign intimation, from contract to contract). So static/full-flow.html gains one row, C2b, drafted from what the form already asks, placed beside C2 (the other beam-outward leg) without renumbering anything; retiring the kind is not on the table — the row's MUST NOT says nothing is deleted while the question is open. Written into the map with the fields the form asks (repairer, beam/flange taps on the physical ids, set no, optional contract, vehicle + transport, gatepass photo, GP no/date, status ladder) and nothing else: no goods, no hishob, no yardage, no rate. The mirror leg (the beam coming back) is named as its OWN tap on this row's text without deciding C192's separate question.\u003C/li>\n\u003Cli>Q33 2026-10-03 C192 should 'beam return to party' fold into B5 movements (where static/full-flow.html already lists 'returns to party'), get its own flow row, or be removed?\u003C/li>\n\u003Cli>A33 2026-10-03 It folds into B5's 'returns to party' leg: the flow ALREADY lists that clause (static/full-flow.html:41) and PLANNING's own beam list calls it 'Beam returns to party / transfers (party-owned beams)', so a NEW flow row would duplicate C170's shipped movements row (C170 is DONE, not OPEN) and the kind is not retired — nothing may be deleted while the question is open. The kind stays a gatepass exactly as it is (no field, kind, POST name, action/method or server validation change): B5 records the return-to-party MOVEMENT, the gatepass records the outward leg's guard taps on the physical flange nos. The one fix in this row is that the beam-tap caption stopped claiming C2's tippan pre-assignment (C2 is beams/warp OUT to a sizer) and now names B5, and B5's cell says which gatepass kind carries the beam leg.\u003C/li>\n\u003Cli>Q34 2026-10-03 C193 Is 'sizing → winder' (the WINDING gatepass kind, ?kind=WINDING — to winder, set no, bags/cones/gross/net, transfer year) its own flow row in static/full-flow.html, or part of C5's 'Winding in/out'?\u003C/li>\n\u003Cli>A34 2026-10-03 Pareto call: it is its OWN flow row, C5b, placed immediately before C5 — drafted FROM what the gatepass form already asks (to winder, set no, bags/cones/gross/net, transfer year, vehicle/transport/photo/GP no + the status ladder), and C5 keeps its own list (empties, ring wt, rec net, diff net/gr, set closing) on /winding. C5 is the RECEIPT at the godown/winder; this kind is the OUTWARD leg that C3 step 2 already promises ('after final hishob the system ALLOWS creating the WINDING-YARN GATEPASS -> issued to the winder') and never gave a row. So C3's promise gets an identity, C5 is untouched as a receipt, and nothing is renumbered. Not part of C5 (C5's own fields are all receipt-side and none of them is a guard's exit doc); not a B5 movement (B5's items are yarn LOTS; this leg carries a set no + weights, and C3 names a gatepass); nothing deleted. The form changes by one hint sentence and one static row naming C5's receipt fields as not-this-gatepass — no POST name, no zod field, no validation, no change to /winding or the auto-lot hook.\u003C/li>\n\u003Cli>Q35 2026-10-03 C194 The recheck says no due-for-collection surface exists anywhere in the app, but /transporter already ships one — its load lists every outward gatepass in intimated/due/partial with the beams/boxes to lift, and its ?/pick action records picked/partial + pickup date/note/photo on the existing gatepass ladder. Should this row build a SECOND list on /gatepasses, or fix the shape of the one that is already there?\u003C/li>\n\u003Cli>A35 2026-10-03 Fix the surface that is already there. /transporter's due-for-collection list is the one the flow means (automatic, no filing step, outward intimations only), and the row's own MUST NOT forbids a second status vocabulary, so a second list would make the record unreadable. This row therefore lands on /transporter (PickCard + the row chrome) and its deliverable is the shape the acceptance names — read-only sectioned summary over a hidden POST form, one field per popup, NO section cards — plus an entry link from the gatepasses list and HTTP proof that the tap records picked/partial + date + photo on the existing ladder without touching the gatepass's own fields. No server action, zod schema, POST field name, kind or validation changes.\u003C/li>\n\u003Cli>Q36 2026-10-03 C196 The per-kind gatepass audit the row points at (C186-C195) is already DONE, not remaining, and the B0/B5b line the row calls stale was already re-pointed by C189 - so what is left for this row, and is a doc that says 'C186-C193 audited every kind' a claim that collapses the per-kind work?\u003C/li>\n\u003Cli>Q37 2026-10-03 C196 C172's pin for flow row B0 is red before this row starts (it expects the B0 line to name /gatepasses/new and C168; C188 re-worded that line to 'not built ... the gate tap under it is C188') and C191/C193 both logged it as owned by C196. Fixing the doc's B0 line is forbidden by this row's MUST NOT, so should C196 correct the stale test pin instead?\u003C/li>\n\u003Cli>A36 2026-10-03 The row still has exactly one job and it is docs truth: rewrite ONLY the /gatepasses/new status line so it names the C168 shell (402ba69) as shipped, lists C186-C193 as the per-kind audit one row per kind (YARN_IN C186, DIRECT C187, BEAM_OUT C188, YARN_OUT C189, BEAM_IN C190, BEAM_REPAIR C191, BEAM_RETURN C192, WINDING C193 - all shipped, verified by opening all eight over HTTP), and names the one gate that is genuinely still open (the SS12 items 7-8 phone-width evidence with the keyboard actually open) instead of collapsing into 'the gatepasses are finished'. The row's premise that C186-C195 is remaining work was stale, not the row's purpose. C194/C195 are named as forms of their own, not gatepass kinds, so no kind is double-counted.\u003C/li>\n\u003Cli>A37 2026-10-03 Correct the stale TEST pin, never the doc line: this row's MUST NOT forbids rewriting another FOCUS-ENTRY.md line, and B0's own line is truthful today (the planner's intimation form is not built; the gate tap under it is C188's, on the signed UI). tests/c172-focus-entry-flow-coverage.test.ts's 'the queued forms carry their route and their queue row' still expects B0 to name /gatepasses/new and C168 from before the C188 split, so C196 re-points that one pin at the truth - B0 not built, SS8b's tap row named, no route claimed for a form that does not exist - and leaves the doc line and every other row alone. Test-side, one file, trivially reversible, and it stops the drain's ship gate from tripping on a red C191 already recorded.\u003C/li>\n\u003Cli>Q38 2026-10-03 C197 The five gatepass rows whose sentence IS the delivered evidence (beamPlanStatic, yarnGoodsStatic, repairStatic, hishobStatic, windReceiptStatic) still print a sentence in the value slot. Moving them into a tap-through pop-up would rewrite the served-HTML proof of four shipped rows (C188 beamout-roles 'a static row records exactly where the planner's numbers went', C189, C190, C191, C193 each assert the sentence in the served row) and this row's MUST NOT says it must not redo their work. Keep them, or move them and re-prove those rows?\u003C/li>\n\u003Cli>A38 2026-10-03 Kept in the value slot. Those five rows are a signed pattern from C188-C193 whose sentence IS the delivery, and each one is proven over served HTML by a shipped row (c188/c189/c190/c191/c193 read the row out of the page). Moving them means redoing four completed rows' evidence, which the row's own MUST NOT forbids. Every other static row - all 30 of them, including every auto-number row the row names - is fixed. The five are recorded as a named exception in docs/FOCUS-ENTRY.md §18 with the rows that pin them, so this is one edit away if the owner wants them moved.\u003C/li>\n\u003Cli>Q39 2026-10-03 C197 The MUST NOT names 'the carried-order line' as a value that must read exactly as today, yet that line ended in the instruction '— check every row'. Also: is the status ladder 'Entered - picked -> delivered -> confirmed -> reconciled' a value (kept whole) or prose (split), and should static rows gain the kind badge the row text assumes is already beside them?\u003C/li>\n\u003Cli>A39 2026-10-03 Three calls. (1) The carried-order line keeps every descriptive word it reads today ('Order X - carried in as the contract, still changeable', 'Booking Y · supplier matched Z', 'KIND reconciliation · PARTY - set no carried in, still editable'); only the pure instruction tail ('- check every row', 'pick the contract below if this movement needs one') moves to the row's pop-up, so the value reads as it does and the sentence is not lost - the reading that keeps the value and satisfies the row's rule. (2) The status ladder stays one value: it has no verb and is the document's own state vocabulary, not an instruction, and three shipped tests pin it byte-for-byte. (3) No kind badge added to static rows: the row text assumed the A badge is already there, it is not, and four sibling tests locate a static row by the exact '>Label\u003C/span><span class="truncate font-medium"' markup, so adding a nested badge span would break all four. The 'Auto'/'-' markers are legible on their own; docs/FOCUS-ENTRY.md records the kinds vocabulary next to the rule.\u003C/li>\n\u003Cli>Q40 2026-10-05 C198 20 files of uncommitted Oct-4 work (OrderEntryForm, dom harness, AGENTS.md, package.json...) sit in the tree with no live session; the drain refuses on it and deploy.sh git-add-As everything. Commit only my row paths and skip deploy, or fold that tree in?\u003C/li>\n\u003Cli>Q41 2026-10-05 C198 C198 is doing with no session alive (STUCK alarm) and none of its targets are modified in the tree. Flip it to pending and work it first as P0, in engine order?\u003C/li>\n\u003Cli>A40 2026-10-05 Pareto: leave the Oct-4 tree byte-identical (never sweep a dead session's half-work into a commit, and deploy.sh git-add-A would ship it live). Each row commits ONLY its own target/test/doc paths and pushes; no deploy.sh from this session. Ship gate + live deploy wait on the owner's call for that tree.\u003C/li>\n\u003Cli>A41 2026-10-05 Pareto: yes. No C198 work exists in the tree (scripts/queue-watch.sh unmodified), so flip C198 to pending and take it first — P0 and engine order agree once the stale claim is cleared.\u003C/li>\n\u003Cli>Q42 2026-10-05 C200 The Oct-4 dead-session tree (20 files) blocks the drain. Commit it as-is, park it in a named stash, or drop it?\u003C/li>\n\u003Cli>A42 2026-10-05 Pareto: STASH in a named stash (reversible; the harness + half-done DOM migration stay a unit and pop back with one command if a row session needs them). Committing would ship half-done work live; dropping would delete a day of work. Drain unblocked the same turn.\u003C/li>\n\u003Cli>Q43 2026-10-05 C200 C200 was queued on the belief that the fault was the New tippan anchor on the list page. Opening the app found the anchor fine and TWO faults on the destination component instead: (1) the loom datalist keyed each on loomNo, which is not unique in the loom master, so Svelte threw each_key_duplicate during boot and killed hydration for the whole screen - the reason the button looked dead; (2) the page binds wizStep/wizSearch on the wizard but the wizard's props were step/search, so the binding went nowhere and every summary row opened step 1. Is the row right to fix both on the destination?\u003C/li>\n\u003Cli>A43 2026-10-05 Yes - shipped both, on the destination. The row's own acceptance says the cause must be found by opening the page and that if the destination is what is broken the row fixes that too and says so; a button that opens a dead or mis-aimed form has not delivered a working new-tippan form. Fix 1: the datalist offers each distinct loom suggestion once and is keyed on that (one line in TippanWizard; a native autocomplete list cannot use duplicates anyway). Fix 2: the wizard's props carry the names the page already binds, wizStep/wizSearch, matching BookingWizard since C104 - renaming the component to the page rather than the page to the component, because the page's wizStep/wizSearch/openWiz/wizNext vocabulary is the larger existing surface. Both are one-component changes, no POST name / action / method / server validation / step-list / solver / record / print / amend / ?/assign touched. The step/search prop rename is provably reversible (one identifier pair) and the page was already the side that named itself consistently.\u003C/li>\n\u003Cli>Q44 2026-10-05 C201 G0b's cell badges 'count/bags expected' 【N】 (typed number) but the DIRECT form asks the count as a 【S】 pick off the yarn master (G0's own count vocabulary). Do I turn the DIRECT count into a typed number?\u003C/li>\n\u003Cli>Q45 2026-10-05 C201 G0/G0b list no vehicle and no transporter, yet the form asks both on YARN_IN and DIRECT (showVehicle = kind !== 'BEAM_OUT'). G4 (C195) reads the plate at the gate and G2 (C194) takes the transporter's pickup. Do the two rows come off both kinds with a static row naming G4/G2?\u003C/li>\n\u003Cli>Q46 2026-10-05 C201 G0 lists 'cones/bag 【P】' only, but the form asks cones per bag AND total cones on YARN_IN; G0b lists neither. Does the total-cones row come off YARN_IN?\u003C/li>\n\u003Cli>Q47 2026-10-05 C201 showMillLot includes DIRECT, so the direct-delivery intimation asks a mill lot G0b never lists. Does that row come off DIRECT while staying on YARN_IN?\u003C/li>\n\u003Cli>Q48 2026-10-05 C201 G0b's cell badges its close-out photo 【PH】 while G0 badges the same field 【PH/OCR】; the form serves one field. Which badge does DIRECT carry?\u003C/li>\n\u003Cli>A44 2026-10-05 Keep the count a 【S】 pick on DIRECT. The DIRECT goods block is the same countYarn field G0 asks, sharing one row definition, and G0 badges the same field 【S】; a kind-split badge would put two vocabularies on one field. Count stays 【S】 on both inward kinds (countYarn's required flag already reads kind === 'YARN_IN' || kind === 'YARN_OUT', untouched).\u003C/li>\n\u003Cli>A45 2026-10-05 Yes - the two rows come off YARN_IN and DIRECT, and a static row names G4 (/inward, C195) and G2 (/transporter, C194) as their real rows, the C189/C192 precedent. MUST NOT keeps C195/C194's own screens and the six other kinds untouched, which is what makes this the row's move: the inward kinds are the only two the flow leaves without a vehicle. Vehicle and transport keep their POST names and their zod fields, so nothing is stored differently.\u003C/li>\n\u003Cli>A46 2026-10-05 Total cones comes off YARN_IN. G0 lists bags 【N】, gross/net 【N】 and cones/bag 【P】 and no total; the total is derivable from bags x cones/bag, and B2 reads cones off the gatepass. Keep the hidden 'cones' input mounted (POST name unchanged) so a booking-carried or OCR-prefilled total still lands, and a static row says the flow lists cones per bag and the total follows from it. WINDING (C5b) still lists cones outright and keeps the row.\u003C/li>\n\u003Cli>A47 2026-10-05 The mill lot comes off DIRECT and stays on YARN_IN. G0b lists count/bags/destination/expected date/status and the close-out; a mill lot is a shade identity that belongs to the inward yarn receipt (G0) and to B2's lot no. A static row on DIRECT names G0 as its row. showMillLot narrows to kind === 'YARN_IN'; millLotNo, its POST name, its zod field and its column are untouched, so a stored DIRECT gatepass still shows whatever it carried.\u003C/li>\n\u003Cli>A48 2026-10-05 DIRECT carries 【PH】, its own cell's badge (G0b: 'sizer=WhatsApp confirm+photo 【PH】'); YARN_IN keeps 【PH/OCR】, G0's badge. The badge is now read per kind off the same field, so each kind is badged with the mode its own flow cell lists. No POST name, zod field or column moves - both already exist from C186/C187.\u003C/li>\n\u003Cli>Q49 2026-10-05 C63 C63 says remove the priority field completely — does that mean only the /queue new-correction form field, or also the queue engine's internal priority metadata (QUEUE.md 'priority:' line, --set --priority, planGroups sort)?\u003C/li>\n\u003Cli>A49 2026-10-05 Pareto: remove the user-facing field only — the Priority select and the P0 badge are gone and --add no longer accepts --priority. The engine keeps its internal P1 because rows already run top-to-bottom of the sheet; ripping priority out of planGroups/parse/render is a flow change outside this row's /queue target and not needed to satisfy the correction.\u003C/li>\n\u003Cli>Q50 2026-10-05 C66 C66 restates C65 almost verbatim (UI tests only when absolutely necessary) with target '-'; does it supersede C65's narrower 'purely visual' wording and where must the rule live -- watcher prompt only, or the governing docs too?\u003C/li>\n\u003Cli>A50 2026-10-05 Pareto: C66 is the governing wording and supersedes C65's 'purely visual' narrowing. The rule goes where it can actually bind: the watcher's worker prompt (scripts/row-watch.sh step 3) AND AGENTS.md's Verification section, which C65 left still saying 'screen proof is a command / a change is proved by opening the page'. UI tests stay available, last resort only.\u003C/li>\n\u003Cli>Q51 2026-10-05 C67 C67 names only the /orders/new/trading upload; does the deepseek-v4.1-flash switch apply to that upload alone or to every AI read on the one opencode gateway?\u003C/li>\n\u003Cli>A51 2026-10-05 All AI reads. They share one gateway and one CAPTURE_LLM_MODEL; two models on one key would be surprising and drift. Matches C64 'everything'. Per-read override is still possible via env if ever needed.\u003C/li>\n\u003Cli>Q52 2026-10-06 C68 The owner says the new-order pages' UI is 'extremely difficult to comprehend'. How far should this row redesign the order-entry form?\u003C/li>\n\u003Cli>A52 2026-10-06 Keep it to the reversible 80/20: segregate the three type-fixed order-entry forms into their own sidebar group and add a one-line plain-language purpose under each form's title so the kind is obvious. Leave the wizard/summary flow, POST names and server validation untouched; a deeper form redesign is a separate owner-scoped row.\u003C/li>\n\u003Cli>Q53 2026-10-06 C69 C69 names no target; its wording (sidebar confusing + pages show similar/unimportant info) overlaps C68 (sidebar segregation + purpose line, done) and C70 (merge the three kinds into Orders). What is C69's own scope?\u003C/li>\n\u003Cli>A53 2026-10-06 C69 owns the always-visible dead content on the three type-fixed new-order forms: drop the redundant kind-code + derived open·auto status from the header and the fixed Kind/Status rows from the summary and save review. Sidebar stays with C68 (done), the merge with C70.\u003C/li>\n\u003Cli>Q54 2026-10-06 C70 Does 'orders can go away' mean drop the separate 'New order' group and merge its three type-fixed links into the existing Orders group, or drop the Orders group (list + Leads/Hishob/Samples/Quote/Reports) instead?\u003C/li>\n\u003Cli>A54 2026-10-06 Merge, do not delete: remove the separate 'New order' group and put Trading SO / Job Work SO / Production Order inside the existing Orders group, right after All Orders. C69's own note calls C70 'the merge of the three kinds into Orders'; deleting the Orders group would strand Leads/Hishob/Samples/Quote/Reports and break append-only reachability.\u003C/li>\n\u003Cli>Q55 2026-10-06 C71 C70 already removed the standalone 'New order' group and moved Trading SO / Job Work SO / Production Order into the Orders group. C71 is a stronger restatement ('remove it completely') — does it mean delete those three type-fixed links from the sidebar too, and the now-orphaned active('/orders') special-case, or is C71 already satisfied by C70?\u003C/li>\n\u003Cli>A55 2026-10-06 Remove them. 'New orders section ... remove it completely' is stronger than C70's merge: the three type-fixed order links (Trading SO / Job Work SO / Production Order) come out of the Orders sidebar group entirely, so the sidebar carries no new-order section at all. The /orders page already offers 'New Trading SO' / 'Add Trading SO' buttons and a drafts row with all three hrefs, so every creation route stays reachable; the pre-C68 active('/orders') yield for /orders/new is dropped with the entries it existed for. Display-only, one file, reversible.\u003C/li>\n\u003Cli>Q56 2026-10-06 C72 C72 says 'in sidebar, all orders need to be separated'. Does it mean split the sidebar's single combined 'All Orders' entry into the order kinds as separate entries (Sale / Job-work / Outsource / Stock, linking the existing /orders?type= views), or restore the three type-fixed new-order creation links (Trading SO / Job Work SO / Production Order) that C71 just removed?\u003C/li>\n\u003Cli>A56 2026-10-06 Split the combined 'All Orders' entry into its kinds as filtered list views (/orders?type=SO|JW|OUTSOURCE|PROD), mirroring the /orders page's own kind tabs (§117) and the /gatepasses 'All X yields to the kind' pattern; keep 'All Orders' as the catch-all. This is the literal reading of 'all orders need to be separated' (the orders, by kind), it does not resurrect the new-order create section C71 called stupid, keeps every order view reachable, and is display-only in one file.\u003Cul>\n\u003Cli>\u003Cstrong>2026-11-04 (owner):\u003C/strong> Sale and Stock no longer ride a query — they own \u003Ccode>/sale\u003C/code> and \u003Ccode>/prod\u003C/code> (PLANNING 746). \u003Ccode>/orders\u003C/code> keeps All / Job-work / Outsource; \u003Ccode>/orders?type=SO|PROD\u003C/code> 308-redirects to the kind's own screen with the query carried, so A56's reachability still holds and the old addresses keep working.\u003C/li>\n\u003C/ul>\n\u003C/li>\n\u003Cli>Q57 2026-10-06 C73 remove all orders from sidebar: does it mean delete the entire Orders group (incl. Leads/Hishob/Samples/Quote/Reports), or remove the order-list entries (All Orders + Sale/Job-work/Outsource/Stock) and keep the rest reachable?\u003C/li>\n\u003Cli>A57 2026-10-06 Remove the order-list entries only (All Orders + Sale/Job-work/Outsource/Stock) and rename the now-orderless group to Commercial, keeping Leads/Hishob/Samples/Quote/Reports reachable. Deleting the whole group would strand those five links (the A54/Q54 Pareto already refused exactly that) and violate append-only reachability; the correction's 'orders' are the order views, which the previous owner notes (C68-C72) always meant. Display-only, one file, reversible.\u003C/li>\n\u003Cli>Q58 2026-10-06 C74 C74 corrects C73: does restoring the sidebar mean the pre-C73 'Orders' group name returns (minus All Orders), or keep the C73 rename 'Commercial' and just re-add the four kind entries?\u003C/li>\n\u003Cli>A58 2026-10-06 The correction 'i meant to only remove all orders' scopes C73 to a single deletion, so the intended end-state is exactly pre-C73 minus the 'All Orders' entry: restore the group name 'Orders' and the four kind views (Sale/Job-work/Outsource/Stock), keep Leads/Hishob/Samples/Quote/Reports reachable, and keep the C73 create-button per-kind fix. Keep the orphaned active('/orders') branch removed since no plain /orders link exists. Display-only, one file, reversible.\u003C/li>\n\u003Cli>Q59 2026-10-06 C75 C75 says 'kind column in each of the order pages can go away now' — does it mean only the list table's Kind column, or also the Kind field in the record popup and the order detail page; and should the All tab keep the column since it still mixes kinds?\u003C/li>\n\u003Cli>A59 2026-10-06 Remove the orders-list table's Kind column on every wide tab (Sale/Outsource/Stock/All) unconditionally — 'column' is literally the table column and the owner said it can go away now that the sidebar segregates the kinds. Keep the Kind field in the record popup and the order detail page: those are fields, not columns, and retaining them means no information is lost if someone opens a record. Display-only, one file, reversible by restoring the column entry and its row value.\u003C/li>\n\u003Cli>Q60 2026-10-06 C76 C76 says /bookings looks chaotic on a smartphone — what is the fix scope? The compact 5-column table still carries an actions column with up to three row buttons (Cancel, Record gatepass, Attach to order) that crowd a phone row: move those actions into the booking's record popup (where the fields already live) or redesign the page (headers, columns, toolbar)?\u003C/li>\n\u003Cli>A60 2026-10-06 Move the per-row action buttons out of the table and into the booking's record popup — the intent C162 already declared ('every other field and every action is in the row popup') and the same move as the job-work order table (C140). The compact table then fits a phone with no action column; keep the page header, columns and toolbar as they are. Every destination survives, display-only, one file, reversible.\u003C/li>\n\u003Cli>Q61 2026-10-06 C77 C77 says /guard looks chaotic on a smartphone — what is the fix scope? Each guard row packs its identity block (GP no, kind, party, Next badge) and the exit form (vehicle input w-28 + camera + Exited) into one justify-between line that overflows a phone: restack the row (identity block, then full-width action form, like the twin /transporter) or redesign the page or move the exit into a popup?\u003C/li>\n\u003Cli>A61 2026-10-06 Restack the row: identity block on its own line, then the exit form full-width beneath it with a flex-1/min-w-0 input — the shape the twin /transporter row already uses. This is the same 80/20 as Q60/C76 ('crowded row, not a page redesign'): keep the header, the DISPATCH due-list, every field and every action; do not swap the inline camera for the PlateScan component (a behaviour change, not the crowding named). One file, display-only, reversible.\u003C/li>\n\u003Cli>Q62 2026-10-06 C78 C78 defers build+deploy to when all corrections are done — while rows are still queued, should each finished row still be committed+pushed (tree clean, work safe) or left uncommitted until the end?\u003C/li>\n\u003Cli>A62 2026-10-06 Commit+push each row with deploy.sh --commit-only (no build/restart/live-check); run the full build+deploy once when no runnable row remains. Uncommitted work across many serial rows would be autostashed by the next session's pull and risks loss; a commit is cheap and reversible, a deploy is not.\u003C/li>\n\u003Cli>Q63 2026-10-06 C79 C79 says the order fill is compulsory — does that mean a hard server-side rejection (fail 400) of a tippan with no order, or the wizard/summary gating that stops any other field being entered until the order is picked, while the create action keeps accepting a null order for the existing assign-later card and curl paths?\u003C/li>\n\u003Cli>A63 2026-10-06 Gate the entry, keep the server contract. The order becomes the wizard's first, compulsory-before-anything step: no other summary row opens, the wizard's Next is disabled, and Check-the-tippan/Save stays disabled until an order is picked. The create action still accepts a null weaverOrderId (assign-later card and existing POST/curl flows unchanged): the correction's words are about entry order ('before any other field is allowed to be filled'), and a new server validator would break the assign-later flow for no wording gain. Fewest files, reversible.\u003C/li>\n\u003Cli>Q64 2026-10-06 C81 Does 'job work order' mean only JW, or also OUTSOURCE?\u003C/li>\n\u003Cli>Q65 2026-10-06 C81 Should the multi-order selection persist on the tippan (new column) or stay UI-only?\u003C/li>\n\u003Cli>Q66 2026-10-06 C81 Should the create action reject a job-work order id, or is the picker filter enough?\u003C/li>\n\u003Cli>A64 2026-10-06 Exclude both JW and OUTSOURCE — orderLogic groups them as the job-work-style kinds and the picker is titled 'Production order / Trading sale order'.\u003C/li>\n\u003Cli>A65 2026-10-06 Persist: add a nullable tippan.weaver_order_ids JSON array; keep weaver_order_id = first order so every existing reader/join/print is untouched.\u003C/li>\n\u003Cli>A66 2026-10-06 Picker filter is enough (matches C79's UI-gate Pareto); the action still validates every id exists, as before.\u003C/li>\n\u003Cli>Q67 2026-10-06 C82 Where should the yarn assignment persist — a new tippan column or the existing yarn_issue JSON?\u003C/li>\n\u003Cli>Q68 2026-10-06 C82 Which records count as available for each source (booking/gatepass/direct/stock)?\u003C/li>\n\u003Cli>Q69 2026-10-06 C82 Should the create action re-validate that the picked source is still available, or only that it exists?\u003C/li>\n\u003Cli>A67 2026-10-06 Keep the existing yarn_issue JSON (add assignSource/assignRef/assignLabel): no migration, fewest files, fully reversible, and the detail/print already read that JSON.\u003C/li>\n\u003Cli>A68 2026-10-06 Read it plainly: booking status open|partial (not yet received); YARN_IN/DIRECT gatepass status intimated|due (not picked up / not received); lot status available (free stock). Closed bookings, picked GPs and allocated lots stay excluded.\u003C/li>\n\u003Cli>A69 2026-10-06 Existence-only, matching C81's order check: a source that moves on after the form opened must not block an entry already started; the picker is the gate.\u003C/li>\n\u003Cli>Q70 2026-10-06 C83 C83 — 'consequent weight (auto calculated)': what is the formula and where does the weight come from? The assigned source has bags/cones/cones-per-bag/net, the form also has per-cone kg — is the weight (bags x cones-per-bag + loose cones) x per-cone kg, or scaled from the source's total net?\u003C/li>\n\u003Cli>A70 2026-10-06 Auto-calculate weight = (bags x cones-per-bag + loose cones) x per-cone kg, read off the assigned source's own rates (booking perConeWt, else bagWt/conesPerBag, else net/(bags x conesPerBag); gatepass/lot net/cones), falling back to the form's Per-cone kg and packing when the source carries none. The create action recomputes it as the arbiter (a posted assignNet is ignored) and stores assignBags/assignCones/assignNet in the existing yarn_issue JSON — no migration, reversible, matches C82/A67. Partial draw is never validated against the source's totals (existence-only, C82/A69).\u003C/li>\n\u003Cli>Q71 2026-10-06 C84 When assigning yarn later fills the whole yarn issue section, should it overwrite figures already on the tippan or only fill the fields the assigned source carries?\u003C/li>\n\u003Cli>A71 2026-10-06 Only fill fields the assigned source actually carries; never wipe a value already on the tippan (bookings carry no count/mill, so those stay as they were). Reversible and matches the no-silent-overwrite spine.\u003C/li>\n\u003Cli>Q72 2026-10-06 C85 What does 'the sizing form UI is a mess, make it proper' require beyond the two concrete asks (compulsory yarn, per-beam own/outsourced plan)?\u003C/li>\n\u003Cli>Q73 2026-10-06 C85 Each beam line: is 'no. of beams' the count of beams in that line and 'mtr' the metres per beam, and is the line tagged own vs job-work, stored in the existing program JSON?\u003C/li>\n\u003Cli>Q74 2026-10-06 C85 The job-work contract can be assigned later — where does that happen and where is the ref stored, given yarn is now compulsory at create?\u003C/li>\n\u003Cli>A72 2026-10-06 Keep the C110 read-only summary + one-field wizard (the sanctioned focus-entry pattern). 'Proper' = tidy the yarn block (assignment is compulsory, no assign-later) and replace the single #Beams count with a per-line beam plan. Fewest files, reversible; no wholesale redesign.\u003C/li>\n\u003Cli>A73 2026-10-06 Yes: one beam-plan line = {kind: own|job, beams: count of beams, mtr: metres per beam}; the sum of counts is the planned beam total; stored in the existing program JSON (no migration).\u003C/li>\n\u003Cli>A74 2026-10-06 Optional JW/OUTSOURCE order picker at create plus the repurposed 'Assign the job-work contract later' card on /tippans/new; stored as program JSON jobWorkOrderId + jobWorkOrderLabel; no migration, no in-place edit of a committed doc.\u003C/li>\n\u003Cli>Q75 2026-10-12 C111 The creation screen's kind chips were also the only on-page way to switch between the eight movements. Removing the horizontal scroller: drop the picker entirely (kind is chosen on the list page before the form), or keep a way to switch kind on the page?\u003C/li>\n\u003Cli>A75 2026-10-12 Drop the picker entirely. The eight gatepasses are distinct movements, not types of one document, so a chip scroller misrepresents them exactly as the owner says. Kind is already chosen on the list page's New gatepass menu (each link goes to /gatepasses/new?kind=…, PLANNING §193) before the form, so nothing is lost; the header badge still names the fixed ?kind= and the Previous-records table still follows it. Fewest files, reversible.\u003C/li>\n\u003Cli>Q76 2026-10-12 C112 C112 lists '4 fields: Booking number + Yarn (Count+Type+mill name) + Trader + Rate' plus a bags popup (already-received date-wise) and destination from masters, but a gatepass has no rate column and the booking link rides the creation event only. Reading taken: the DIRECT intimation is made booking-driven — the picked booking supplies booking no + yarn (count/type/mill) + trader + rate as read-only context, the wizard becomes booking → trader → expected date → bags, and 'already received date-wise' is matched by yarn count across prior DIRECT receipts. Rate/yarn type are DISPLAY-only (no new column). Is that right, or should rate/type be stored on the gatepass (its own migration)?\u003C/li>\n\u003Cli>A76 2026-10-12 Safe 80/20 reading, per C165/Q11: the booking is the intimation's source, so booking no + yarn (count/type/mill) + trader + rate are shown read-only fetched from the booking and NOT stored — a new gatepass column is out of scope for a UI row (it would need its own migration). 'Already received date-wise' is derived read-only from prior DIRECT receipts matched by yarn count (the booking link is event-only, so per-booking attribution is a separate change). Wizard stays the four compulsory fields: booking → trader → expected date → bags. Fully reversible, no schema/zod/POST change.\u003C/li>\n\u003Cli>Q77 2026-10-12 C112 C112 reopen says the DIRECT intimation must show ONLY 4 fields. Literally only four rows — which would also drop the C186/C187 close-out evidence rows (gatepass photo, confirmation photo, GP counter-copy) and the universal Kind/GP-no/Status markers — or the four editable fields with the flow's close-out evidence and universal static markers kept?\u003C/li>\n\u003Cli>A77 2026-10-12 Keep the four editable fields exactly — booking, bags to be received, location, expected date. Remove every row the owner named (count, trader/party, order, GP-date) plus the now-redundant read-only rows (Booking says / Total bags booked / Already received / Prefilled by), folding their content into the booking pick label and the bags popup sub. The C186/C187 close-out evidence rows (gatepass photo, confirmation photo, GP counter-copy) stay — they are not fields, the owner did not name them, and removing them would break the signed flow. The universal Kind/GP-no/Status static markers stay as on every kind. No schema/zod/POST change.\u003C/li>\n\u003Cli>Q78 2026-10-12 C113 On G0 (YARN_IN), should the form be stripped to ONLY booking + bags-to-receive + location (like C112's DIRECT, dropping C201's goods fields — count, ticket, mill lot, gross, net, cones/bag), or does C113 mean those fields are REQUIRED in addition (Fields required, not only), with the booking made primary? Also: 'location of pickup (from godown master)' — there is no godown master table; the only godown list is the existing destination picker (our godown / premises / named sizer) — is relabelling that picker the right reading, and is a booking with no purchase rate the 'job work' case that drops trader + rate and says 'to be received' instead of 'booked'?\u003C/li>\n\u003Cli>A78 2026-10-12 Safe 80/20: keep G0's C201 goods fields (C113 says 'Fields required', not 'only'), and make the booking the primary/compulsory field on a fresh or OCR-opened yarn-in (BLOCK_NEXT + required), with the C112-style label (booking no + yarn count/type/mill + trader + rate) and the bags-to-receive popup (booked total, already-received date-wise, prior-bag suggestions). 'Location of pickup (from godown master)' = the existing godown destination picker, relabelled (no godown master table exists; its POST names destPlace/targetPartyId don't move). 'Job work' = a booking with no purchase rate: its label drops trader/rate and its bags popup says 'to be received' not 'booked'. Carried yarn-in (?bookingId=/?orderId=/?reconId=) keeps its carried flow and is never blocked. Fewest files (two), reversible, no schema/zod/POST/column change.\u003C/li>\n\u003Cli>Q79 2026-10-12 C115 C115 targets /tippans/new but 'the background form has more fields than specified' also reads like /gatepasses/new?kind=DIRECT (C112). Which surface, and which fields are the extras?\u003C/li>\n\u003Cli>A79 2026-10-12 Follow the row target: /tippans/new. Read 'the background form' as the tippan entry surface (sectioned summary + hidden POST), and the extras as the gatepass-given yarn-issue fields (Yarn GP/Source/Count/Mill/Packing/Bags/Cones/Net) that the C82/C85 compulsory yarn assignment supersedes per C84; remove those steps/rows and fill the issue from the assignment, keeping every POST name.\u003C/li>\n\u003Cli>Q80 2026-10-12 C113 C113 reopen says G0 shows ONLY the owner's fields, exactly as the C112 DIRECT reduction. Two things it does not name: (a) does 'exactly as C112' also drop G0's GP-date row and its 'Prefilled by' static (DIRECT dropped both)? (b) 'Location of pickup (from godown master)' vs dropping the separate 'To party' row — should the one pickup-location picker carry our godown / premises / named sizers so a sizer is still pickable without a second row?\u003C/li>\n\u003Cli>A80 2026-10-12 Safe 80/20, mirroring A77 for G0b: (a) yes — drop the GP-date row (the date still posts, defaulted to today) and the 'Prefilled by' static, as DIRECT did; (b) yes — the ONE 'Location of pickup' picker carries our godown / premises / the named sizers and posts the existing destPlace+targetPartyId names, so the 'To party' row the owner named is gone but a named sizer is still pickable. No schema/zod/POST/column change.\u003C/li>\n\u003Cli>Q81 2026-10-12 C116 Does C116 remove only the DIRECT (direct-delivery intimation) options from the tippan yarn-assignment picker, or also the server's direct-assignment resolution (back-compat for carried/legacy POSTs)?\u003C/li>\n\u003Cli>A81 2026-10-12 Remove only the picker options (the visible direct-delivery records) and narrow the availability query to YARN_IN; keep the server's direct-assignment resolution for carried/legacy POSTs so no existing flow breaks (reversible, fewest files).\u003C/li>\n\u003Cli>Q82 2026-10-13 C115 The reopen's removal list names targetPartyId, but DIRECT's visible Location picker stores the sizer as targetPartyId (destPlace='sizer'), so removing it would drop the sizer; C201 also keeps vehicle/transport mounted for G0/G0b carries. Do we keep location's targetPartyId, drop vehicle/transport on the reduced kinds, and scope the hidden-form reduction to the booking-driven kinds only?\u003C/li>\n\u003Cli>A82 2026-10-13 Keep targetPartyId: it IS the Location field's stored value (a named sizer posts destPlace='sizer' + targetPartyId), not an extra row. Drop vehicle/transport on DIRECT/G0 (the reopen says the hidden form holds ONLY the kind's visible fields). Scope the reduction to the booking-driven kinds (DIRECT/YARN_IN); every other kind's hidden transport set stays byte-identical (their reverse booking-picker legitimately fills count/ticket/mill-lot). The booking's own figures (trader, count, ticket, mill lot, contract) are read server-side from the picked booking, never mounted.\u003C/li>\n\u003Cli>Q83 2026-10-13 C116 The reopen says drop the 'Previous {kind} records' section on /gatepasses/new. Does that also remove the now-unused server load that fed it (data.recent + its 40-row gatepass query), or keep the load untouched?\u003C/li>\n\u003Cli>A83 2026-10-13 Remove the now-dead server load too: 'drop the whole section' plus its only consumer gone, so leaving the 40-row query is dead code. Fewest live lines, fully reversible (it is load-only, no action/POST/schema touched).\u003C/li>\n\u003Cli>Q84 2026-10-13 C115 The reopen drops DIRECT's whole photo/vehicle section and reduces G0 to the gatepass photo only. Does the G0 section keep the 'Photo & vehicle (you can skip)' title (now naming a vehicle it no longer has), and should the G0 gatepass photo become a required field (C113 calls image storage a required G0 field)?\u003C/li>\n\u003Cli>A84 2026-10-13 Safe 80/20: (a) title — use the photo-only 'Gatepass photo (you can skip)' for G0 as BEAM_OUT already does, so the section never promises a vehicle it no longer shows; (b) image stays optional at entry (not a wizard step): C113's 'required' means the field must exist and be OCR/image-storage-capable, not that it blocks the tap — making it required would change validation the reopen did not ask for. No POST/zod/column change.\u003C/li>\n\u003Cli>Q85 2026-10-13 C117 On a DIRECT direct-delivery intimation, is the drop location's acknowledgement file compulsory before confirming, and does confirming move the intimation straight to confirmed (no separate delivered tap)?\u003C/li>\n\u003Cli>A85 2026-10-13 Optional: acknowledgement file and remarks are both optional so a recipient on a weak phone/signal can still confirm; confirming a DIRECT intimation moves it straight to confirmed (event from intimated->confirmed) since the drop location's acknowledgement IS receipt. Existing out-bound delivered flip and generic inbound no-flip are untouched. Reversible.\u003C/li>\n\u003Cli>Q86 2026-10-13 C118 Should a direct delivery's two states be stored as new values (drop_pending/drop_completed, migrating the four live 'intimated' rows) or collapse the existing intimated/confirmed only for display, and should DIRECT be dropped from the /inward intimated-chain queue?\u003C/li>\n\u003Cli>A86 2026-10-13 Display-only collapse: gpStatusWords(kind,status) maps DIRECT's intimated|due|partial|picked -> 'Drop pending' and delivered|confirmed|reconciled -> 'Drop completed', leaving the stored status column, zod, POST names and every existing query untouched. This keeps existing behaviour (C117's ack already writes 'confirmed'), needs no migration for the four live DIRECT rows (they are intimated -> Drop pending), and is fully reversible; direct delivery is also dropped from the /inward intimated-chain queue because its two-state flow completes at the drop location's acknowledgement (C117) or the guard receipt (C119), not the G4 chain.\u003C/li>\n\u003Cli>Q87 2026-10-13 C119 C119 says 'reuse the existing guard receipt action, not a new screen', but /guard had no receipt action — only exit (outbound) and beamConfirm. Reading taken: add a 'receive' action on the existing /guard page (no new screen/route) that reuses the C117 received-confirmed status move (DIRECT intimated->confirmed = Drop completed), logs the same gatepass:received-confirmed event carrying the guard's vehicle + driver photo, and fires the existing createLotsFromGatepass hook (yarn inward). Is that the intended 'existing guard receipt action', or did you mean the C117 no-login /c/gp confirm link used from the guard's phone?\u003C/li>\n\u003Cli>A87 2026-10-13 Safe 80/20: add a receive action to the EXISTING /guard screen (no new route/screen), reusing the C117 received-confirmed semantics (DIRECT intimated->confirmed = Drop completed) plus the existing createLotsFromGatepass hook so the yarn inward is created on receipt; the guard enters vehicle no + driver photo (image, stored in the screenshots bin like the C117 ack). The C117 no-login link stays for the named-sizer/external drop only.\u003C/li>\n\u003Cli>Q88 2026-10-13 C120 C120 says job work = 'job-work number, no yarn booking', while C130 (separate, pending) adds job-work ORDERS to the picker. Reading taken: job work here is the existing rate-less open booking (isJobBooking, A78) — not a new job-work-order picker — so no C130 overlap. Is that the intended job-work case?\u003C/li>\n\u003Cli>A88 2026-10-13 Yes, safe 80/20: job work = a rate-less open booking (the one BK-MLP-1 row has yarn_id null, so it genuinely has no yarn identity). A rated booking shows the yarn identity auto read-only; a rate-less one makes count/type/mill user-picked wizard steps. Job-work-ORDER search stays C130's scope.\u003C/li>\n\u003Cli>Q89 2026-10-13 C121 Does C121's rename+move apply only to the DIRECT form, or to the shared GP no row on all eight gatepass kinds?\u003C/li>\n\u003Cli>A89 2026-10-13 DIRECT only — the correction and its target name the direct-delivery form; other kinds keep their 'GP no' row where it is (one .svelte, reversible).\u003C/li>\n\u003Cli>Q90 2026-10-13 C122 Where exactly does the Status badge sit at the top, and does it keep an explanatory note (which would make the row tappable/field-like)?\u003C/li>\n\u003Cli>A90 2026-10-13 Kind -> Direct delivery no -> Status; keep the badge as a non-tappable informational line (no note) so it is a tag, not a field row, per C122 wording\u003C/li>\n\u003Cli>Q91 2026-10-13 C131 Removing the broker name field from the party form: should the underlying party.broker_name column and existing stored data also be dropped via migration, or only the form field removed?\u003C/li>\n\u003Cli>A91 2026-10-13 Only the form field is removed. The party.broker_name column and any already-stored values stay (no migration, no data loss) — reversible, fewest files, and existing rows keep their history.\u003C/li>\n\u003Cli>Q92 2026-10-13 C132 Does 'remove opening balance field' mean drop the party.opening_balance column and existing values, or only retire the form field?\u003C/li>\n\u003Cli>A92 2026-10-13 Form-only retirement (mirrors C131): the field goes from the add/edit form, the record dialog and the printed field reference; party.opening_balance column + stored values stay. No migration, no data loss, smallest reversible file set.\u003C/li>\n\u003Cli>Q93 2026-10-13 C133 Does 'remove due days field' mean also drop the Due days column from the party list table and the due_days column from the database, or only retire the party add/edit form field?\u003C/li>\n\u003Cli>A93 2026-10-13 Form + display retirement (mirrors C132/C131): drop the due-days field from the add/edit form, the record dialog, the party-list column and the printed field reference; keep the party.due_days column and stored values. No migration, no data loss, smallest reversible file set.\u003C/li>\n\u003Cli>Q94 2026-10-13 C134 C134 asks for mobile/email validation, but PartyForm.svelte already enforces mobile /^[6-9]\\d{9}$/ (+91-aware) and email on the client, and +page.server.ts enforces both on the server (PLANNING 141). Does the row mean add live/typed input relevance on top of the existing rules, or only confirm them and change nothing?\u003C/li>\n\u003Cli>A94 2026-10-13 Safe 80/20: keep every existing mobile/email rule and message byte-identical on both sides; add only additive input relevance in PartyForm.svelte - the mobile field strips characters outside its own pattern [0-9+ -] as you type so invalid input cannot be entered, and both fields clear their stale submit-time error on edit. One file, reversible, no POST name / schema / zod / server change.\u003C/li>\n\u003Cli>Q95 2026-10-13 C135 Does adding a Godown party category also mean a Godown party should be excluded from the gatepasses trader picker (like Sizing/Weaver/Transport), or is the category purely a master label with downstream filters untouched?\u003C/li>\n\u003Cli>A95 2026-10-13 Keep every downstream filter untouched — the correction names Category on /masters only. A Godown party is a new value with no prior rows, so nothing existing changes; excluding it from the gatepasses trader picker would be a separate behaviour change. Fewest files, reversible.\u003C/li>\n\u003Cli>Q96 2026-10-13 C136 Should the picked country code be persisted with the mobile number (and how are non-India numbers stored/validated), or is the select display-only?\u003C/li>\n\u003Cli>A96 2026-10-13 Persist it. +91 (India, default) stores byte-identical bare 10 digits as today; any other known code stores \u003Cdial>\u003Clocal> (digits only) so existing WhatsApp/quote helpers — which strip non-digits and only prefix 91 to a bare 10-digit — keep working. Non-+91 local numbers validate 4-15 digits. Add a short whitelist of known dial codes shared by form + server.\u003C/li>\n\u003Cli>Q97 2026-10-13 C137 C137 says remove the phone number field on /masters?tab=party. Does that also drop the read-only Phone line from the record detail (MASTER_FIELDS in +page.svelte), and should existing party.phone values be preserved on edit?\u003C/li>\n\u003Cli>A97 2026-10-13 Remove only the editable Phone input and its client/server validation on the party form. Keep the read-only Phone line in the record detail (MASTER_FIELDS) and keep party.phone data intact; carry the existing value through a hidden input on edit so saving other fields never nulls phone. Fewest files, reversible, no data loss.\u003C/li>\n\u003Cli>Q98 2026-10-13 C138 Does the new MSME (Udyam Aadhar) field need a strict format validation rule, or just accept the number as free text?\u003C/li>\n\u003Cli>A98 2026-10-13 Accept as free text (trimmed, stored as string). Udyam Aadhaar numbers mix letters+digits+dashes (UDYAM-XX-00-0000000) and genuine numbers vary, so a strict regex would reject valid entries; the row only asks to add the field. Validation can become its own row like C140 for PAN/GSTIN. No schema format constraint - a text column, reversible.\u003C/li>\n\u003Cli>Q99 2026-10-13 C139 C139 says remove the old unit toggle on /masters?tab=party. Does that also drop the 'Own unit' list column, the record-detail row and the party.is_own_unit field/data, or only retire the visible form toggle?\u003C/li>\n\u003Cli>A99 2026-10-13 Retire only the visible 'Own unit' toggle in the party form (mirrors C137/C131). Keep the party.is_own_unit column, the party-list column and the record-detail row, and carry the existing value through a hidden round-trip input on edit so saving other fields never flips a legacy unit off. No migration, no data loss, fewest files, reversible.\u003C/li>\n\u003Cli>Q100 2026-10-13 C140 PAN/GSTIN rules already exist on both sides (PartyForm.svelte + partyErrors, PLANNING 141) and are server-proven; does the row want new/changed rules, or only live input relevance on top of the existing ones?\u003C/li>\n\u003Cli>A100 2026-10-13 Safe 80/20: keep every existing PAN/GSTIN rule and server message byte-identical (PAN 5 letters+4 digits+1 letter; GSTIN 15-char with Z at 11); add only additive input relevance in PartyForm.svelte so the fields normalise as you type (uppercase, strip non-alphanumerics, cap at 10/15) and clear their stale submit error on edit. Mirrors C134/A94. No server/schema/POST-name change.\u003C/li>\n\u003Cli>Q101 2026-10-13 C141 Does 'remove amend button after edit' mean drop the standalone Amend control entirely on the party tab (folding the correction remark into the edit form so Save records it), or only hide Amend while the edit form is open?\u003C/li>\n\u003Cli>A101 2026-10-13 Drop the standalone Amend control on the party tab: the correction remark becomes a field of the edit form and Save records it as an appendage (amendment). Other master tabs keep their existing Amend control unchanged (the target is ?tab=party).\u003C/li>\n\u003Cli>Q102 2026-10-13 C142 Does C142 remove only the visible Suggest button in the Acronym field, or also the auto-suggest-on-typing behaviour that fills the acronym from the party name until the user edits it?\u003C/li>\n\u003Cli>A102 2026-10-13 Remove only the visible Suggest button. The correction names the button, not the prefill; keep the existing auto-suggest-on-typing ($effect) byte-for-byte so Add/Edit keep filling the acronym from the name until the user types their own. Fewest files, reversible, moves no stored value.\u003C/li>\n\u003Cli>Q103 2026-10-13 C143 Target says masters?tab=payment-terms but the wording says 'design master' — which record does C143 remove the rates & rolls section from?\u003C/li>\n\u003Cli>A103 2026-10-13 Design master (masters?tab=design) — the wording names the section and C144–C150 all edit design-master fields (weft wastage, warp/weft grid, PPI, GSM/UTL, Denting); the payment-terms URL is a batch mislabel.\u003C/li>\n\u003Cli>Q104 2026-10-13 C144 Does 'any new record' also require the quote edit/requote Weft Waste % field to prefill 5, or is the design-master new-record form enough?\u003C/li>\n\u003Cli>A104 2026-10-13 Design-master only. C144 is part of the C144-C150 batch that edits design-master fields (PLANNING 426) and the target tab is a known batch mislabel. The design form is the one new-record screen that left weft waste blank; /quote/new already prefills 5 via EFF_DEF and /quote/edit's server builder already defaults 5. Keep existing behaviour and touch the fewest files.\u003C/li>\n\u003Cli>Q105 2026-10-13 C145 C145 Permissible counts — where may the allowed substitute counts come from (a picker over the yarn master's counts, or free entry), and does the new warp/weft grid replace the raw JSON textareas that row C146 targets?\u003C/li>\n\u003Cli>A105 2026-10-13 Permissible counts are free per-row entry (comma-separated positive numbers) shown as removable badges — the row names no candidate source and a picker would need a new yarn-master dependency and another file; the grid replaces the two raw JSON textareas (C146's target), since a visible JSON blob is exactly what C145 replaces. Fewest files, reversible, stores nothing new that the JSON row shape cannot carry.\u003C/li>\n\u003Cli>Q106 2026-10-13 C146 C146 orders removing the warp/weft rows fields, but C145 (just shipped) rebuilt those same fields as the Sr No./Count/Unit/Percent/Permissible grid. Does C146 mean delete multi-warp/weft entirely (removing C145's grid) or remove the raw-JSON field presentation it names?\u003C/li>\n\u003Cli>A106 2026-10-13 Keep C145's grid; C146 removes only the raw-JSON presentation it names. A visible JSON blob was exactly what C145 replaced, and deleting the grid would undo a row the owner asked for one sitting earlier (A105). Fewest files, reversible: drop the JSON wording/labels and the field reference's JSON claim; nothing stored is touched.\u003C/li>\n\u003Cli>Q107 2026-10-13 C147 C147 says quality name to be derived from all other fields, not manual. Which string should the derived name take, and does deriving mean the stored name is recomposed on every save (normalising legacy names)?\u003C/li>\n\u003Cli>A107 2026-10-13 Derive the name with one shared pure helper on both surfaces, canonical format width\u003Ccode>reed/denting*pick/warp*weft-weave (e.g. 63\u003C/code>84/3\u003Cem>70/32\u003C/em>32-2/1-TWILL) matching the dominant stored convention; the server builder composes it and ignores any posted quality_name, so legacy names normalise to this format on their next edit (append-only audited diff, no data loss). The alias stays manual and moves beside the name at the top.\u003C/li>\n\u003Cli>Q108 2026-10-13 C148 C148 remove the PPI field and write the literal Pick in the quality name: the pick column still feeds the costing engine (weft weight), so does the stored pick stay silently (hidden carry on edit), or is it dropped entirely?\u003C/li>\n\u003Cli>A108 2026-10-13 Pareto: remove the visible Pick (PPI) input and put the literal Pick where the number was; carry the stored pick through a hidden field on edit so the costing weights are not zeroed and no committed value is overwritten. A new record legitimately has no PPI. Reversible.\u003C/li>\n\u003Cli>Q109 2026-10-13 C149 C149 (batch target ?tab=payment-terms) = design master, per Q103/A103 — remove the visible GSM target and UTL inputs. Does the stored gsm_target/utl value need preserving on edit (checking/report reads design.gsm_target), or is dropping it intended?\u003C/li>\n\u003Cli>A109 2026-10-13 Remove the fields from the form only. Keep the DB columns and existing stored values — the safe 80/20: dropping gsmTarget/utl from buildDesignValues makes an edit OMIT those columns (drizzle skips absent keys), so committed gsm_target/utl survive and the /checking/report GSM-target column keeps working; new designs simply have none. No schema migration, no hidden carry, fully reversible (re-add two builder lines + two inputs).\u003C/li>\n\u003Cli>Q110 2026-10-13 C150 C150's correction text shows the same string on both sides (a paste typo): does 'write only' mean drop the '— EPI = reed × denting ÷ 2' hint from the Denting field label and keep 'Denting (ends per dent)'?\u003C/li>\n\u003Cli>A110 2026-10-13 Yes — the string is duplicated by a paste typo; the only reading that makes 'instead of X write only Y' true is to drop the EPI formula hint and keep the label 'Denting (ends per dent)'. Safe 80/20: the wording already lived on the design master (C143-C150 batch mislabel), one label text only, reversible.\u003C/li>\n\u003Cli>Q111 2026-10-13 C152 The row target names /tippans/new (corrections sheet) / /masters?tab=party (queue), but the \\u201cwarp and weft grid\\u201d with count / % / permissible counts exists only on the design master (/masters?tab=design, DesignRowsGrid). Is the design master the intended surface?\u003C/li>\n\u003Cli>A111 2026-10-13 Design master (/masters?tab=design) is the surface: \\u201cwarp and weft grid\\u201d + count / % / permissible counts exist only in DesignRowsGrid there. ?tab=party and /tippans/new are the C143-C152 batch mislabel (Q103-Q110), same as C145-C151. No tippan screen renders a warp/weft grid.\u003C/li>\n\u003Cli>Q112 2026-10-13 C152 The correction only says prefill percentages when a NEW row is added. Should deleting a row also re-share the 100% (else 3 rows at 33.33/33.33/33.34 minus one leaves 66.66), or leave typed values untouched?\u003C/li>\n\u003Cli>A112 2026-10-13 Delete also re-shares via distribute() — \\u201ctotal of % to be 100%\\u201d would otherwise break on delete; fewest files, reversible, values stay editable.\u003C/li>\n\u003Cli>Q113 2026-10-13 C153 The row names only L2L, but the same design-master block tags siblings with legacy codes (Lasa (110), Size add-on % (10), Weft waste % (5)). Does 'Remove (104) in the label of L2L' mean drop only the L2L tag, or every sibling code too?\u003C/li>\n\u003Cli>A113 2026-10-13 Only the L2L tag: the correction names one field and one code, so scope is that single label; sibling codes are their own corrections if wanted. Fewest files, reversible.\u003C/li>\n\u003Cli>Q114 2026-10-13 C154 Remove shifts field: does it mean only the masters Loom entry field, or the shifts column and every screen that uses it (movements/weft-issue shift pickers, capacity board) too?\u003C/li>\n\u003Cli>A114 2026-10-13 Only the masters Loom entry/display: drop the Shifts select from LoomForm, the Shifts column + record-dialog field + tab description, the server validation and the builder read, and the fields-reference row. Keep the loom.shifts DB column (default 2) and the movements/weft-issue shift pickers and capacity board untouched — the data still drives those, and keeping the column is the reversible 80/20.\u003C/li>\n\u003Cli>Q115 2026-10-13 C155 The row says 'the table of all masters' — does it mean only the /masters page tables, or also the Open links on other list screens (/tippans, /reconciliations)?\u003C/li>\n\u003Cli>A115 2026-10-13 Only the /masters page tables (all 7 tabs). 'All masters' means every master tab; /tippans and /reconciliations are not master tables and keep their Open links.\u003C/li>\n\u003Cli>Q116 2026-10-14 C156 Only the phone layout is named: should the desktop warp/weft table also change shape, or is the change mobile-only?\u003C/li>\n\u003Cli>A116 2026-10-14 Mobile-only: render one stacked card per warp/weft row below the sm breakpoint (640px) and keep the existing table at sm+; the modal already becomes a full-width bottom sheet on phones, so the grid is the only wide element. Keeps desktop density, fewest surprises, reversible (drop the breakpoint classes).\u003C/li>\n\u003Cli>Q117 2026-10-14 C157 C157 says the permissible count drop down has to be searchable — should search REPLACE the multi-select checkbox picker with a single-pick Combobox, or filter the existing multi-select list, and is there a minimum query length?\u003C/li>\n\u003Cli>A117 2026-10-14 Keep the C152 multi-select (checkboxes + removable tags): the field stores a list. Add a search box inside the dropdown that filters the count list as you type; empty query shows all. No minimum length — counts are 2-3 digits and a short list should narrow on the first character.\u003C/li>\n\u003Cli>Q118 2026-10-14 C158 Does 'Remove mode from design master' mean drop the mode_pref column entirely, or remove only the visible Mode field from the master (form/table/validation/builder) while keeping the column + BOTH default so the sales-order mode prefill (orders/[id] reads design.modePref) keeps working?\u003C/li>\n\u003Cli>A118 2026-10-14 Remove only the visible Mode field from the design master: the form select, client + server validation, the record-detail field row, the table column, and buildDesignValues. Keep the design.mode_pref column and its BOTH default (no migration) so the sales-order mode prefill at src/routes/orders/[id]/+page.server.ts:229 is untouched — fewest files, reversible, preserves existing orders behaviour. New designs default to BOTH exactly as the old blank submit did.\u003C/li>\n\u003Cli>Q119 2026-10-15 C159 SvelteKit 3 migration: which readings? (a) official @sveltejs/adapter-bun vs keep community svelte-adapter-bun; (b) rewrite deprecated json()/text() or leave them; (c) add .js extensions to #lib imports\u003C/li>\n\u003Cli>A119 2026-10-15 Q119/A119 (a) switch to official @sveltejs/adapter-bun: the community 1.0.1 peers Kit 2 and uses the removed Kit-3 Adapter API, so it cannot build; output build/index.js is identical so the service unit is untouched. Q120/A120 (b) keep json()/text() — deprecated, not removed in 3.1.0, so leave byte-identical (fewest files, zero behaviour change, reversible). (c) add .js extensions to every #lib path (official migrator convention; Vite/TS map them to the .ts sources).\u003C/li>\n\u003Cli>Q120 2026-10-17 C161 No acceptance recorded and the wording is bare: does 'new trading SO button showing 500 error' mean the Trading SO form's own Save/check-and-save flow, or a different control? The page's GET is 200 for every role/param tried; the only 500 in its flow is the post-save read-back GET /api/orders/[id].\u003C/li>\n\u003Cli>A120 2026-10-17 The Trading SO page GET renders 200 for owner/sales/planner/accounts/production and for junk query params, so the page itself is not throwing; the only 500 in the form's own flow is the C157 post-save read-back GET /api/orders/[id], which 500s on every call because it selects the non-existent order.quality column. Fix that endpoint, keep its response shape, touch one file.\u003C/li>\n\u003Cli>Q121 2026-10-17 C162 For C162, is the 'last used RS' the latest quote saved for that quality (design_id), and should it override the quality master only when it differs so the summary's 'edited' badge stays honest?\u003C/li>\n\u003Cli>A121 2026-10-17 Yes — the latest quote for the design (newest created_at whose inputs_json carries it); carry it as an adjustment only when it differs from the design master, else fall through to the master. No new field, so no new validation.\u003C/li>\n\u003Cli>Q122 2026-10-17 C163 For the quote wizard's job-rate field, should it prefill from the last used job rate for the quality (falling back to the design master), or keep the master only?\u003C/li>\n\u003Cli>A122 2026-10-17 Last used job rate for the quality wins, design master as fallback — matches the owner's wording and C162's reed-space pattern.\u003C/li>\n\u003Cli>Q123 2026-10-17 C164 Does 'warp sizing rate should prefill from the yarn master' override a sizing rate the row already carries from quote/design history, and should the prefill follow a count changed in the warp popup?\u003C/li>\n\u003Cli>A123 2026-10-17 Keep the existing precedence: a sizing rate already carried by the row (last quote / design master) wins, and a rate the user typed is never overwritten. The yarn master fills a blank row and re-prefills when the row's count is changed to another master count (tracked as an auto-filled value), so the warp popup's count is the trigger. Missing master count clears only a rate this prefill wrote.\u003C/li>\n\u003Cli>Q124 2026-10-17 C165 Quality with multiple warp/weft: which carrier counts — a legacy warp_count/weft_count string joined with '+' (e.g. 34+30SLUB), or the design's warp_rows/weft_rows JSON grid rows?\u003C/li>\n\u003Cli>A124 2026-10-17 The JSON grid rows already prefill every row (proved: the quote wizard's designData and edit resolveQuoteInput both render all warp_rows/weft_rows entries), so the only quality master that still loses a second warp/weft is a legacy count string, which joins counts with '+' (25 designs: 34+30SLUB, 20S+20S Lycra, 40/1+40Lycra ...). Split masterCountRows on '+' into one row per count, sharing 100% evenly like the design grid — the user confirms every auto-filled field.\u003C/li>\n\u003Cli>Q125 2026-10-17 C166 Does 'remove sizing GST field' mean only the new-quote wizard summary (/quote → /quote/new, where the 'Warp n siz GST' tap-row sits), or also the per-warp 'Siz GST %' input on /quote/edit's warp rows?\u003C/li>\n\u003Cli>A125 2026-10-17 Only the /quote (new-quote wizard) surface the correction names — remove the 'Warp n siz GST' tap-row from NewSummary.svelte and drop the sizGst branch from the wizard's openYarnField, keeping the stored sizGst value (yarn-master prefill + costing) untouched and /quote/edit's per-warp Siz GST input as-is, since the row targets /quote alone. Fewest files, reversible.\u003C/li>\n\u003Cli>Q126 2026-10-17 C167 C167 says 'Remove mill/ticket' on /tippans/new. The only mill/ticket there is the tippan's yarn-issue mill field (yMill) — hidden from the wizard since C115 but still carried in the hidden POST form and read by the create action. Does the row mean remove that entry field only, or also drop the stored mill from the tippan's yarn issue (record + print)?\u003C/li>\n\u003Cli>A126 2026-10-17 Remove the mill/ticket entry field from the new-tippan surface only — the yMill page state, hidden POST input, TippanWizard prop/binding, the gatepass ticket carry, the PREFILLABLE entry and the create action's raw(fd,'yMill') read. Keep the tippan's stored mill derived from the assigned yarn/gatepass (r.issue.mill || gpRow.ticket), so the record, print and every existing row are byte-identical. Fewest files, reversible, matches C168 (mill/ticket arrives from the new master, never typed on the tippan).\u003C/li>\n\u003Cli>Q127 2026-10-17 C168 C168 says 'create a new master of ticket/mill' whose entries 'come from the rate board' and auto-update, and that fetching yarn shows 'all permutations of yarn and mills'. Is the master a NEW table/tab, or a derived projection of the rate board, and which rate column is the mill source?\u003C/li>\n\u003Cli>A127 2026-10-17 Derive, don't create a second entity (mirrors C160's weave sub-master): the mill/ticket master is the distinct rate-board 'ticket' values, de-duped case-insensitively (first spelling canonical) and sorted, projected live from the rate table — no new table/tab/migration, and a new rate ticket auto-appears with no extra entry. Source = rate.ticket, because the yarn master's own field is 'ticket' and matchBoardRate already pairs yarn.ticket with rate.ticket. Consumed as a pick-or-type datalist on the yarn master's Ticket/mill field, so any count+type shows every mill available (the permutations). Fewest files, reversible, keeps stored yarns untouched.\u003C/li>\n\u003Cli>Q128 2026-10-17 C169 ?tippans/new has no weave field (weave comes from the picked design); the only weave input is the design master's form. Is the row's surface the design master, and should the weave master be a sub-master panel on the design tab or a separate masters tab?\u003C/li>\n\u003Cli>A128 2026-10-17 Design master is the surface (the /tippans/new target is the C143–C157 batch mislabel); keep the weave master as a read-only sub-master panel on the design tab (C160's 'sub-master of design master, never a separate tab'), not a new tab.\u003C/li>\n\u003Cli>Q129 2026-10-18 C171 When a market dhara is tapped, should its brokerage prefill overwrite a brokerage already prefilled from the direct-order convention or order history, or only an empty field? (also: do history/quote dhara carries trigger the mapping, or only an explicit dhara tap?)\u003C/li>\n\u003Cli>A129 2026-10-18 Explicit dhara tap only, and it overrides a non-touched earlier prefill (direct convention / history / quote): the row says 'when the dhara is selected, prefill X', and a value the user typed (touched) is never overwritten. A dhara carried by history/quote is left alone — it already carries its own brokerage. Case/space-insensitive name match, closed map so an unmapped dhara (Job Dhara, new market) leaves brokerage as-is.\u003C/li>\n\u003Cli>Q130 2026-10-18 C174 The same inherited-property sort 500 (SORT_COLS[rawSort] truthy for \u003Cstrong>proto\u003C/strong>/constructor/toString) exists on the nine sibling list pages (hishob, bookings, tippans, gatepasses, lots, beams, samples, drafts). Fix just the reported orders page, or all of them in this row?\u003C/li>\n\u003Cli>A130 2026-10-18 Fix only the reported page (src/routes/orders/+page.server.ts): the row's target names one page, fewest files, reversible. The identical one-line guard on the sibling list pages is a separate, reversible follow-up, not this row's file.\u003C/li>\n\u003Cli>Q131 2026-10-18 C175 Should the deliver window persist a start and an end date as new columns, or keep the field's existing integer dueDays as the one stored value with the two dates UI-only?\u003C/li>\n\u003Cli>A131 2026-10-18 Keep dueDays as the one persisted value (the field the row targets); the start/end dates are a UI-only window over it, the start defaulting to the booking day already stored as orderDate. No new columns, no migration; a start past the end clamps to 0. Reversible, fewest files.\u003C/li>\n\u003Cli>Q132 2026-10-18 C176 C176 says add button in mill/ticket master, but C168/§457 made that master a read-only projection of the rate board (no add form, never a table). Does the Add button only seed the rate board, or persist a manual mill somewhere?\u003C/li>\n\u003Cli>A132 2026-10-18 Persist a small mill master table; the master is the UNION of the board's distinct rate.ticket values (C168's auto-entry) and the mills entered by hand, de-duped case-insensitively (board spelling wins on a case-only collision). The Add is insert-only (append-only UX: no edit/delete), name required, format-checked on both surfaces, and refused as a case-insensitive duplicate against either source — so neither the board nor the manual list can carry a second spelling. Reversible: drop the table + button + form and the master collapses back to the board projection. A hand-added mill has no rate, so it stays a reference entry: the quote popup still lists only board rows (which carry the rate).\u003C/li>\n\u003Cli>Q133 2026-10-18 C177 C177 says add button in weave master, but C160/PLANNING §448 made that master a read-only projection of the design master's weave column (no add form, never a table). Does the Add button persist a manual weave somewhere?\u003C/li>\n\u003Cli>A133 2026-10-18 Persist a small weave master table; the master is the UNION of the designs' distinct weave values (C160's auto-entry) and the weaves entered by hand, de-duped case-insensitively (design spelling wins on a case-only collision). The Add is insert-only (append-only UX: no edit/delete), name required and format-checked on both surfaces with the same WEAVE_RE the design Weave field uses, and refused as a case-insensitive duplicate against either source. Reversible: drop the table + button + form and the master collapses back to the design projection.\u003C/li>\n\u003Cli>Q134 2026-10-18 C180 C148 removed the wizard source step (and its contract-copy OCR/dictation) from the Job Work SO; C180 requires OCR of the contract copy to prefill the ops fields on that same form. Do I restore OCR reachability on the JW form, and can I keep C148's no-quote/lead-picker decision?\u003C/li>\n\u003Cli>A134 2026-10-18 Restore the source step for JW as a contract-copy READ only: wizardStepsFor keeps 'source' for SO and JW, JOB_SOURCE_STEP titles it 'Read the contract copy?' for JW, and OrderEntryForm hides the quote/lead picker block unless t==='SO'. Fewest files (orderLogic + OrderEntryForm), reversible (one filter, one gate), keeps C148's picker decision, and makes OCR/dictation reachable so fillFromDictation prefills the ops fields.\u003C/li>\n\u003Cli>Q135 2026-10-18 C181 C148 removed the wizard source step (and its contract-copy OCR/dictation) from the Stock (Production) order; C181 requires OCR of the contract copy to prefill the ops fields on that same form. Do I restore OCR reachability on the PROD form, and can I keep C148's no-quote/lead-picker decision?\u003C/li>\n\u003Cli>A135 2026-10-18 Restore the source step for PROD as a contract-copy READ only: wizardStepsFor keeps 'source' for SO, JW and PROD, the existing JOB_SOURCE_STEP titles it 'Read the contract copy?' for both non-trading kinds, and OrderEntryForm hides the quote/lead picker block unless t==='SO'. Fewest files (orderLogic + OrderEntryForm), reversible (one filter, one gate), keeps C148's picker decision, and makes OCR/dictation reachable so fillFromDictation prefills the ops fields.\u003C/li>\n\u003Cli>Q136 2026-10-18 C182 C182 says ask loom width and panna FIRST in the wizard and the form. Does 'first' mean literally the first popup (ahead of the job-work source/contract-read step), and does the reorder also apply to the job-work-style OUTSOURCE form that shares these steps?\u003C/li>\n\u003Cli>A136 2026-10-18 Yes — the loom width/panna popup is literally the first step of the job-work wizard (ahead of the contract-read source step) and loomWidth/panna lead the form's kind section. The OUTSOURCE form shares the same job-work wizard steps and ORDER_FIELD_SPEC, so it takes the same order; Trading SO and Production Order have no loom step/fields and are untouched (proven by the pure-logic check).\u003C/li>\n\u003Cli>Q137 2026-10-18 C184 C184 'payment dhara field keep in the end' on /quote/new: does 'the end' mean the summary/full form's Payment dhara row (now the second section, after Enquiry) should move last, or the wizard's dhara step (already last among steps)? And should the wizard also skip the dhara step when C183 prefilled it (quoteCarry never sets dharaReady)?\u003C/li>\n\u003Cli>A137 2026-10-18 The field the owner sees on the /quote/new form is the summary's 'Payment dhara' row; 'keep in the end' = make it the last section of the full form, after Construction, just above the actions. The wizard's dhara step is already last among steps, so it needs no reposition. The C183 prefill/skip wiring is C183's own scope, not touched here; fewest files (NewSummary.svelte), reversible (move the block back), no behaviour change.\u003C/li>\n\u003Cli>Q138 2026-10-18 C185 Which screen is the 'second page of costing form' — the summary (phase=summary, shows no cost/weight) or the calc screen (phase=calc, the only place showing warp/weft cost and weight)?\u003C/li>\n\u003Cli>A138 2026-10-18 The calc screen (NewCalc.svelte, phase='calc') is the 'second page of costing form' — it is the only screen that shows warp/weft cost and weight (the summary shows neither). Keep totals as-is and add a per-yarn breakdown when a side has more than one valid row.\u003C/li>\n\u003Cli>Q139 2026-10-18 C186 C186's coins come 'from previous sale orders of the same quality' — the order table rows of type SO (real sales orders, design_id + metre qty), or the quote history the form itself already reads? And the 1000-mtr slot scroll: cap it at the server's own 1,000,000-mtr estQty limit, or run higher?\u003C/li>\n\u003Cli>A139 2026-10-18 Pareto: the literal wording wins — coins are the order table's type='SO' rows for the same design_id with a positive metre qty (the real sales orders), read most-recent-first, de-duplicated, capped at four; the browser's last-used estimate is only the fallback. The quote history is not re-used because the row names sale ORDERS, and the two can disagree. The slot scroll is capped at the same 1,000,000-mtr ceiling the server already enforces on estQty, so the picker can never offer a value the save would reject; it is a scroll range only and a typed figure is still kept as typed.\u003C/li>\n\u003Cli>Q140 2026-10-18 C187 The Delivery end coins are +10/+20/+30/+40 days (the list continues) — measured from today, or from the chosen Delivery start date? And how many steps does the trailing '+' mean?\u003C/li>\n\u003Cli>A140 2026-10-18 Measure from the chosen Delivery start when one is set, else today: a delivery END is the close of its own start->end window, so start+N keeps every suggested end on or after its start (today+N can land before a later start). With no start it degrades to the same 'today + N' reading the wording implies. The trailing '+' continues the step of ten to +50 and +60 (six coins) — the window lengths the ladder names, bounded and reversible. Suggestions only: the date input and its existing isDate validation are untouched; the dStart coins are left as C105 shipped them.\u003C/li>\n\u003Cli>Q141 2026-10-18 C188 Acceptance conflict: 'the list shows no fixture order number' vs 'none referenced is removed'. 196 of 344 fixture orders have linked children (evt/amendment/attachment/roll/dispatch). Leave referenced fixtures (list stays dirty) or purge parent + its linked children?\u003C/li>\n\u003Cli>A141 2026-10-18 Purge the whole fixture subtree: delete the fixture order AND its linked child rows (evt/amendment/order_attachment/roll/dispatch_slip/lot...) in one transaction, after backing up data.db. A fixture parent's children are fixture too (verified: e2e-probe events, C111 ops-complete amendments, SO-E2E-2701 rolls/dispatch). Accepting 1 wins: the list must show only real orders; the protection clause is read as 'no referenced child is left dangling', not 'referenced fixtures stay'.\u003C/li>\n\u003Cli>Q142 2026-10-18 C189 The correction hands over a DeepSeek API key — should it be committed to the repo so every checkout/deploy host inherits it, or kept only in the host .env?\u003C/li>\n\u003Cli>A142 2026-10-18 Host .env only. The repo rule is 'never commit secrets', and the live checkout IS the deploy host (/root/trading), so editing .env here switches the live app; .env.example documents the endpoint + model with an empty key. Fewest files, reversible (old opencode-go values kept commented).\u003C/li>\n\u003Cli>Q143 2026-10-18 C190 C190 rate scroll: what wheel range/step and how many quality-rate suggestion coins?\u003C/li>\n\u003Cli>A143 2026-10-18 step 0.25, wheel 0-999 typeable (a higher rate is typed, not scrolled) like the leads/orders rate range; coins = up to 6 distinct recent order rates of the selected quality\u003C/li>\n\u003Cli>Q144 2026-10-18 C193 C193 samples auto entry number: does 'shown at the top of the form' mean a new first summary section ("Sample") holding the read-only 'Sample no · Auto' row before 'From (context)', and should the value stay the neutral marker 'Auto' (as every other form's doc-number row) rather than a computed next number?\u003C/li>\n\u003Cli>A144 2026-10-18 Yes — move the existing read-only 'Sample no' row (label 'Sample no', value 'Auto', note 'Auto on save — the next sample number') out of the 'Charge or waive' section to a new first section titled 'Sample', so it is the top of the form; keep the value 'Auto', exactly as the GP-no / Movement-no / Direct-delivery-no rows read on the other forms. Display-only: no field added, no POST name/schema/column/action moves, one file, reversible.\u003C/li>\n\u003Cli>Q145 2026-10-18 C194 C194 wording 'REMOVE HISHOB AND ORDERS FROM ORDERS SECTION ... THESE ARE REPORT': the Orders group has no 'Orders' child (removed in C74), so which second item is meant, and where do the report links go after leaving Orders?\u003C/li>\n\u003Cli>A145 2026-10-18 Read 'ORDERS' as the Reports link (both Hishob and Reports are reports; 'these are report[s]' names exactly those two). The Orders group's only non-order report entries are Hishob and Reports, so both leave Orders. Kept reachable by a new Reports group (same roles) so no screen is stranded — fewest files (one), reversible.\u003C/li>\n\u003Cli>Q146 2026-10-18 C195 C195: what counts as 'already assigned' yarn, and does spreading one booking over several production orders change the cost ledger or which order is primary?\u003C/li>\n\u003Cli>A146 2026-10-18 Already assigned = the net kg of open bookings already linked to that order, matched to a design warp/weft row by count+system+type and side (the only order-yarn link the app holds; date + mill ticket shown on expand). For several orders, the first stays the primary booking.orderId and keeps the one existing cost-basis link; the per-order bag split is stored additively (order_split) and no extra order touches the cost ledger — money left alone, fewest files, reversible.\u003C/li>\n\u003Cli>Q147 2026-10-18 C196 For 'same yarn (COUNT+TYPE+MILL)', is the count SYSTEM (Ne/D/Tex) part of the identity, or only the numeric count + type + mill?\u003C/li>\n\u003Cli>Q148 2026-10-18 C196 Does the same-yarn history matching apply to the other history-owned booking fields (supplier, broker, lot, payment term, rate), or only to cones per bag and bag wt?\u003C/li>\n\u003Cli>A147 2026-10-18 Include the count system: identity = count|countSystem|typeCode|ticket. A yarn count is meaningless without its system (61 Ne != 61 D), so the system is part of the standard count format; it never splits a real duplicate in practice and is trivially reversible.\u003C/li>\n\u003Cli>A148 2026-10-18 Cones per bag and bag wt only (this row). They are physical packaging properties of the yarn, so they follow the yarn identity; supplier/broker/rate/lot are commercial and stay keyed to the exact master row (rate's own same-yarn suggestion is C197's row). Fewest-change, reversible.\u003C/li>\n\u003Cli>Q149 2026-10-18 C197 The correction gives no rate-wheel range or typed-value rule. Is a single 0-999 wheel stepping 0.25 (mirroring the FOCUS-ENTRY rate mode) right, or must the old 0-4999.99 reach survive, and may a typed rate still be any value?\u003C/li>\n\u003Cli>A149 2026-10-18 Mirror the documented FOCUS-ENTRY rate mode: one wheel 0-999, step 0.25 (max booking rate on live data is 450, so 999 is ample); typed values stay as typed (NumberWheel's contract), only the scroll snaps to 0.25 slots.\u003C/li>\n\u003Cli>Q150 2026-10-18 C197 Should the rate auto-prefill also move to the count+type+mill identity, or only the suggestion coins the correction names?\u003C/li>\n\u003Cli>A150 2026-10-18 Only the suggestion coins move to identity matching (the correction names the coins); the auto-prefill keeps its existing board-then-exact-last order, unchanged bytes.\u003C/li>\n\u003Cli>Q151 2026-10-18 C198 Does 'terms and papers except rate and yarn booking allocation' and 'system date need not be shown' mean the wizard steps only, the whole summary form, or both — and should the read-only system date be dropped?\u003C/li>\n\u003Cli>A151 2026-10-18 Both faces (the ONE ORDER_FIELD_SPEC drives the summary and the wizard), and keep the system date as the C135 read-only top row — never an input, never dropped. Fewest files, reversible, no field/value/POST change.\u003C/li>\n\u003Cli>Q152 2026-10-18 C199 job-work reorder: (a) does 'loom width (only one field, form showing 2 fields)' mean retire the legacy loomType class and keep the master-driven loomWidth? (b) should the derived rate (jobRate x picks) stay on the job-work summary/wizard since the owner's list names only picks + job rate? (c) do the removals (city, sales promise, broker/weaver confirmation) and the reorder also apply to the legacy OUTSOURCE form, or JW only?\u003C/li>\n\u003Cli>A152 2026-10-18 Pareto-safe reading: (a) keep the master-driven loomWidth (C146/C182) and retire the duplicate legacy loomType from job work; (b) keep the derived rate field/wizard step — it is not in the owner's explicit remove list and C142 makes it an editable auto value; (c) apply the reorder+removals to JW only and leave the legacy OUTSOURCE form untouched — fewest files, keep existing behaviour, reversible.\u003C/li>\n\u003Cli>Q153 2026-10-18 C200 C200 job-work 'Link a capture draft' is unresponsive: which upload should the field offer, and where should it show? Today it sits inside the OUTSOURCE-only contractFile block (so it vanished on the job-work form) and its only control is a select of existing capture drafts.\u003C/li>\n\u003Cli>A153 2026-10-18 Show 'Link a capture draft' wherever the kind carries sourceDraftId (JW + OUTSOURCE), decoupled from contractFile. Add an upload beside it that posts to /api/capture-ocr, so a real capture DRAFT is written and instantly linked (sourceDraftId) — the field's literal job; party/quality prefill from the read's resolved masters, and the wizard's existing order-OCR upload stays the full field-prefill path. One file, reversible.\u003C/li>\n\u003Cli>Q154 2026-10-18 C201 C201 own firm on /bookings/new: is 'own party type' the party master category 'OwnUnit' (not the isOwnUnit flag), and should the new own-firm field be required on every booking or optional?\u003C/li>\n\u003Cli>A154 2026-10-18 Safe 80/20: 'own party type' = party.category 'OwnUnit' (the category IS the type; the isOwnUnit flag is a separate boolean and both live OwnUnit rows carry category OwnUnit). The own-firm field is OPTIONAL (blank allowed), and when present it is validated to be an OwnUnit party name from the master; stored as a new nullable booking.firm_name text column. Optional keeps every existing/draft/carried booking saveable and is reversible.\u003C/li>\n\u003Cli>Q155 2026-10-18 C192 Should the removed purpose field also stop being written from the capture-draft confirmation path and the schema purpose column be dropped?\u003C/li>\n\u003Cli>A155 2026-10-18 No — remove the field from /samples only (form, prefill and create action). The capture-draft insert keeps writing purpose from the slip and the nullable schema column stays, so existing rows and captured text are untouched; dropping the column would be irreversible.\u003C/li>\n\u003Cli>Q156 2026-10-18 C203 Which L2L should prefill a new quote for a quality: the last quote's L2L for that design, or only a quote whose order was actually finished? L2L is not stored on order rows, only on design master + quote inputs_json.\u003C/li>\n\u003Cli>A156 2026-10-18 Use the last quote's L2L for that design (the existing lastQuoteRows source) — it is the most recent actual value used for the same quality. 'Finished order' cannot be read separately because L2L lives only on design master + quote inputs_json, never on order rows.\u003C/li>\n\u003Cli>Q157 2026-10-18 C206 After creating a missing buyer/broker from the picker popup, should the new row be auto-selected and the wizard continue, or only be added to masters for a manual pick?\u003C/li>\n\u003Cli>A157 2026-10-18 Auto-select the just-created row. For a buyer the wizard continues exactly like a normal pick (onParty + next); for a broker the step stays (same as a broker coin). Fewest taps, reversible by clearing the pick.\u003C/li>\n\u003Cli>Q158 2026-10-18 C209 Trader's booking no + booking date on /bookings/new: required or optional, and should booking date default to the system date?\u003C/li>\n\u003Cli>A158 2026-10-18 Required\u003C/li>\n\u003Cli>Q159 2026-10-18 C211 "create a guard login": is this an owner-only screen that creates staff logins with a role (durable), or a one-off seeded guard account?\u003C/li>\n\u003Cli>A159 2026-10-18 Owner-only /users screen that creates a login (name+email+password+role); guard is a role option. Generalises to any staff login and is reversible; a seeded account would not be reproducible by the owner.\u003C/li>\n\u003Cli>Q160 2026-10-18 C215 Does 'form name' include the sidebar nav 'Yarn in' and the generic h1 'New gatepass', or just the YARN_IN form's kind label?\u003C/li>\n\u003Cli>A160 2026-10-18 Rename only the YARN_IN form's kind label (badge, list dropdown, FocusEntry title); leave the generic h1 'New gatepass' and the sidebar nav entry untouched — the row targets the form and C216/C218 handle the header and the kind chip.\u003C/li>\n\u003Cli>Q161 2026-10-18 C216 Should the top show the intimation number as the doc-no shape (GP-YYMMDD-XXXX) or the plain 'Auto' marker, and should 'system date' be the server system date or the client's today?\u003C/li>\n\u003Cli>A161 2026-10-18 Doc-no shape (GP-YYMMDD-XXXX) + server system date: mirrors the DIRECT top strip and booking C209 'system no + system date' pattern the same owner asked for; server date avoids browser-clock drift; fewest files, reversible.\u003C/li>\n\u003Cli>Q162 2026-10-18 C217 The row lists 'remarks' but the YARN_IN form has no remark row (only the separate dictation field). Should remarks be a new optional free-text field, and does the 1-6 order cover only those six rows (the optional uploads section stays after them)?\u003C/li>\n\u003Cli>A162 2026-10-18 Read 'remarks' as a NEW optional free-text Remark row (not the dictation field): add it last, trim, max 200 chars on both surfaces, persisted on the append-only creation event payload (no migration, mirroring dictateText/confirmPhoto). Apply the 1-6 order to the six named entry rows only; keep Kind/system-date static meta and leave the optional uploads section after them. Reason: fewest files, reversible, keeps existing behaviour for every other kind.\u003C/li>\n\u003Cli>Q163 2026-10-18 C218 "remove kind" on /gatepasses/new?kind=YARN_IN: does it mean only the Kind row/chip in the form (plus its saved-summary line), or also the top-right kind badge + direction marker + the hidden POST marker?\u003C/li>\n\u003Cli>A163 2026-10-18 Only the Kind row/chip in the form (and its after-save summary line) goes; the top-right badge stays because C215 made it the form's name, and the hidden POST kind/direction markers stay because resolveKind + the record still need them. Fewest files, reversible, no other kind touched.\u003C/li>\n\u003Cli>Q164 2026-10-18 C219 C219 'waive amount not needed' on /samples: a complete waive has no amount, so which approval path — auto-approve the user's tap (like the old ≤₹1000 branch), or still route every complete waive to the owner even without an amount?\u003C/li>\n\u003Cli>A164 2026-10-18 Auto-approve the user's tap: with no amount the existing >₹1000 owner gate cannot be evaluated, and the old ≤₹1000 branch was already a user tap. Store waiverAmt=0, waiverBy/waiverApprovedBy='user'; keeps approvals/queue/board untouched and is reversible. Fewest files.\u003C/li>\n\u003Cli>Q165 2026-10-18 C220 Does removing the Rate source row also drop the stored rateFromOrder provenance flag?\u003C/li>\n\u003Cli>A165 2026-10-18 No — remove only the visible Rate source row; the hidden rateFromOrder input and the stored column stay (existing behaviour/data, one file, reversible).\u003C/li>\n\u003Cli>Q166 2026-10-18 C221 Does 'Remove from context complete section' mean remove the entire 'From (context)' block on /samples — the From lead picker, the From order picker AND the read-only Capture draft row — plus the now-unreachable lead/order prefill plumbing and its server queries? Or keep the Capture draft indicator?\u003C/li>\n\u003Cli>A166 2026-10-18 Remove the whole 'From (context)' section (all three rows) and its now-unreachable lead/order picker plumbing + server queries. Keep the draftId hidden POST and the query-param prefill, so the capture-draft save path is byte-identical — only the visible reminder goes. Fewest files (samples page + server), reversible.\u003C/li>\n\u003Cli>Q167 2026-10-18 C222 Scope: the rate wheel bug lives in the shared NumberWheel typeable input; fix it once in the shared component (all typeable wheels) or only the rate instance?\u003C/li>\n\u003Cli>A167 2026-10-18 Fix in the shared NumberWheel: same defect for every typeable wheel (rate, qty, money), fewest files, reversible; no per-instance fork. The rate target /bookings/new uses the shared component.\u003C/li>\n\u003Cli>Q168 2026-10-18 C223 C223 says 'pass on field as 1' for a direct order, but the existing C101 convention prefilled pass-on 100% ('the entire brokerage passed on'). Which pass-on value should a direct order prefill/store: 1% or 100%?\u003C/li>\n\u003Cli>A168 2026-10-18 1% — C223 names 1 explicitly, and C173's own pass-on wheel (coins 0.5%/2%) shows pass-on is an absolute %, not a % of brokerage, so a direct order is brokerage 1% + pass-on 1%. Change the C101 convention from pass-on 100 to 1 on both surfaces and set the server defaults to 1.\u003C/li>\n\u003Cli>Q169 2026-10-18 C225 C225 names two field sets 'for the sales user' and 'for production user' on the same /orders/new/trading form - does the form require a different compulsory set by the logged-in user's role, or are all listed fields required for every user?\u003C/li>\n\u003Cli>A169 2026-10-18 Role-based: a 'production' user saves the Trading SO with the production set (Buyer's order no, Send as, Mtr per roll, Rolls); a 'sales' user saves with the sales set (Quality, Rate, Picks, Quantity, We must deliver in days, Payment dhara, Cd, Brokerage %, Pass on %). Buyer stays buyer-or-broker (the C250 broker-only booking), and every other role/kind is unchanged - the owner named exactly those two roles.\u003C/li>\n\u003Cli>Q170 2026-10-18 C226 Remove fields 'Sales promise' and 'Send to city' on /orders/new/trading: do they leave the Trading SO only (the target form), or every form that carries them including the Stock (Production) order? And does 'move we must deliver in days to the place of sales promise' mean the summary/terms position?\u003C/li>\n\u003Cli>A170 2026-10-18 Trading SO only: the correction names /orders/new/trading, so 'dispatchCity' and 'promisedDays' leave the SO spec (kinds become ['PROD']) and stay on the Production order untouched; dueDays moves from the Quantity & delivery section to the Terms & papers slot the sales promise occupied (terms/order 30), matching the section form which already renders it under Price. Fewest files, reversible, existing records untouched.\u003C/li>\n\u003Cli>Q171 2026-10-18 C227 Does 'Booking no.' mean the buyer's booking/order number already stored as partyContractNo ("Buyer's order no"), or the yarn booking (cost-basis picker, costBookingId)? And is it the Trading SO wizard step right after the OCR/source step?\u003C/li>\n\u003Cli>A171 2026-10-18 The buyer's booking/order number = the existing partyContractNo field ("Buyer's order no"), surfaced as a Trading SO wizard step immediately after the OCR/source step; the yarn cost-basis booking (costBookingId) is a different, optional field and is left as it is. Fewest files, reversible, no new column.\u003C/li>\n\u003Cli>Q172 2026-10-19 C228 Does the 0.25 increment apply to the wizard rate wheel only, or also to the desktop Price section rate input and the operations rate wheel on the order page?\u003C/li>\n\u003Cli>A172 2026-10-19 Wizard rate wheel only: the complaint is the new-order wizard scroll (it stepped 1 and floored typed decimals); the section input already accepts any decimal and the ops popup wheel is a different screen left unchanged. Fewest files, reversible.\u003C/li>\n\u003Cli>Q173 2026-10-19 C229 Does 'rate field 2 decimal points' mean the trading order rate should display/store at two decimals (rounding extra decimals), or reject entries with more than two decimals?\u003C/li>\n\u003Cli>A173 2026-10-19 Display and store two decimal points: normalise typed and prefilled rates to 2 dp on the trading order form and round the server-side rate to 2 dp. Empty stays empty; non-numeric input still fails validation. Reversible, no rejection.\u003C/li>\n\u003Cli>Q174 2026-10-19 C230 Does the picks step-by-1 apply to the trading SO wizard's ± stepper only (job work keeps C142's bare input), and are the existing C142 suggestion coins (same quality + party first, quality-only fallback) enough for the 'suggestions' half of the row?\u003C/li>\n\u003Cli>A174 2026-10-19 Trading SO/PROD wizard picks ± steps by 1; job work keeps its C142 bare picks input and its job-rate × picks maths unchanged (safer, fewer files). Keep the C142 suggestion ladder exactly as it ships — same quality + party first, that quality alone as fallback — because the row asks for suggestions from the same quality + party and the fallback only appears when the pair has no history.\u003C/li>\n\u003Cli>Q175 2026-10-19 C231 C231 'have not expired': leads carry no validity field — does it mean anything beyond excluding lost/converted leads?\u003C/li>\n\u003Cli>A175 2026-10-19 Leads: exclude any lead that already has a quote, a convertedOrderId, or a non-open status. Quotes: exclude validity before now and any quote already linked to an order. Fewest files, reversible.\u003C/li>\n\u003Cli>Q176 2026-10-19 C231 C231: should the trading wizard's source step also become the two-tab historic table, or only the full form's two dropdowns?\u003C/li>\n\u003Cli>A176 2026-10-19 Both surfaces use the same one-field two-tab historic table, so the trading SO has one picker pattern; the wizard keeps its dictation/OCR above it.\u003C/li>\n\u003Cli>Q177 2026-10-19 C232 Where should the lead/quote picker land after leaving the OCR wizard screen: a new wizard step right after the OCR step, or the form's Kind section behind the wizard (where the same picker already exists)?\u003C/li>\n\u003Cli>A177 2026-10-19 A new wizard step immediately after the OCR step (sourceLink), trading-SO only. 'Next screen' reads literally: the screen right after the upload reads the slip, the next screen links a lead/quote. The same picker stays in the form's Kind section too, so either path works.\u003C/li>\n\u003Cli>Q178 2026-10-19 C234 Does the +/- 0.25% stepper apply only to the wizard pass-on scroll, or also to the summary popup's plain pass-on input and the 0.5%/2% coins?\u003C/li>\n\u003Cli>A178 2026-10-19 Wizard pass-on scroll only. Mirror C233's brokerage stepper: keep the 0.5%/2% coins and the summary popup's plain input as they are (fewest files, reversible, matches the row's target = the scroll).\u003C/li>\n\u003Cli>Q179 2026-10-19 C236 C236's target is /orders/new/production-order (PROD), whose A4b spec (C179) has no buyer/rate/payment. Do we re-adopt the A4b commercial block on the production order and require the owner's sales/production sets there?\u003C/li>\n\u003Cli>A179 2026-10-19 Yes: the target IS the Production Order (Stock) route; the owner's staged reading supersedes C179, so PROD re-adopts the sales commercial block and the sales/production required sets apply by role.\u003C/li>\n\u003Cli>Q180 2026-10-19 C238 Does the Rolls/Lumps rename apply only to the Trading SO or everywhere the shared rolls field is asked?\u003C/li>\n\u003Cli>A180 2026-10-19 One shared ORDER_FIELD_SPEC label, so trading, job-work and stock-production entry all read Rolls/Lumps; the production-completion wizard's own label is left as-is (fewest files, reversible).\u003C/li>\n\u003Cli>Q181 2026-10-19 C242 Which exact short words for the table's Status column (currently full phrases like 'waiting for owner approval'), and which progress fact should lead the Progress cell?\u003C/li>\n\u003Cli>A181 2026-10-19 Take the safe 80/20: short badge words Open / In Prod / Delivered / Closed / Pending / Confirmed / Cancelled, and the Progress cell leads with one abbreviated fact (rolls count + the sent/ready metres), full detail stays in the row popup.\u003C/li>\n\u003Cli>Q182 2026-10-19 C243 Does 'remove from the horizontal scroll' remove only the Open link, or the whole trailing actions column (Open/Complete, Reuse, Requote)?\u003C/li>\n\u003Cli>A182 2026-10-19 Remove the whole trailing actions column on every orders table tab. Every one of those destinations already lives in the row popup (dialogActions: Open full record / Complete operations, Reuse, Requote), so nothing is lost and the column no longer forces a sideways swipe.\u003C/li>\n\u003Cli>Q183 2026-10-19 C244 The picker is empty because the live data has no 'open' leads (all are auto-lost) and its 2 open quotes are past their printed validity, while the Leads screen still lists lost leads and the Quote screen still lists those open quotes. Should the picker match those list screens (offer lost leads and open quotes past validity), or keep only strictly-open records and show an empty state?\u003C/li>\n\u003Cli>A183 2026-10-19 Match the list screens, because the owner's report is that rows he sees as open are missing. Offer lost leads (the Leads default pipeline lists them until converted) and quotes in open/approved/draft/sent with no generated SO, regardless of a printed validity date (the lists treat status as the arbiter and auto-expire). Update the create action to accept the same set, so a shown row never fails on save. Fewest files, reversible.\u003C/li>\n\u003Cli>Q184 2026-10-19 C245 which picks surface does 'picks field to change by 1 with +/- button' mean — the wizard 'How many picks?' step or the background Price section input; and do the quality coins already satisfy 'suggestion coins based on previous SO of the same quality'?\u003C/li>\n\u003Cli>A184 2026-10-19 Both faces are the same field, so give the background Price-section picks input the same ±1 stepper the wizard step already has (non-job-work only; job work keeps its bare input and rate = jobRate × picks). The coins were already widened to the quality alone by C239, so no coin change is needed.\u003C/li>\n\u003Cli>Q185 2026-10-19 C246 C246 asks for separate class and type masters, while the queued C247 asks for one combined loom type master (width + type). Should C246 create two separate reference masters now, or go straight to the combined master?\u003C/li>\n\u003Cli>A185 2026-10-19 Implement C246 literally as two separate insert-only reference masters (loom class + loom type) now; C247 will consolidate them into one combined loom type master later. Keeps the two rows independent and reversible.\u003C/li>\n\u003Cli>Q186 2026-10-19 C247 C247 wants one combined loom type master (width + type), but C246 just shipped separate Loom class and Loom type masters. Should the separate Loom class master/tab be removed, or kept as the width source for the combined master?\u003C/li>\n\u003Cli>A186 2026-10-19 Keep the Loom class master and its tab as the width source; the Loom type tab becomes the combined width+type master and the loom form gets one Loom type select. No table/data is dropped, fewest files, reversible.\u003C/li>\n\u003Cli>Q187 2026-10-19 C248 Does 'loom type' mean the job-work loom width (loomWidth) field, and should panna fall back to the old quality+party history when that width has no prior panna?\u003C/li>\n\u003Cli>A187 2026-10-19 Yes: on job-work the visible loom field is loomWidth (C199), so panna keys off quality + loomWidth across parties; when no width is chosen yet, keep the old quality+party panna as the fallback so existing behaviour is preserved.\u003C/li>\n\u003Cli>Q188 2026-10-19 C250 For which order kinds does Fill details open a production wizard, and which wording/placement should the secondary status use?\u003C/li>\n\u003Cli>A188 2026-10-19 Pareto reading: SO opens /production/trading, OUTSOURCE opens /production/job-commercial (it carries every field the pending check looks at), PROD opens /production/production-order; JW has no production screen in PRODUCTION_TYPES, so it opens the order record's own operations wizard (/orders/\u003Cid>#operations). The secondary status reads 'Details pending' in a chip beside the workflow Status (a separate Ops column on the compact job-work table, which has no Status column), and only role === 'production' gets Fill details and loses the New button.\u003C/li>\n\u003Cli>Q189 2026-10-19 C251 Role-scoped order entry: does the visibility filter apply to the whole new-order form (summary + section form) or only the wizard carousel, and are the universal core fields (buyer, qty, type, system date, remark) shown to both roles?\u003C/li>\n\u003Cli>A189 2026-10-19 Apply C251 visibility on BOTH faces of the new-order form (check-and-save summary + background/section form) plus the wizard, driven by one role-aware ORDER_FIELD_SPEC: sales sees the sales fields, production sees the four physical fields (buyer order no, send as, mtr/roll, rolls). Treat buyer, qty, kind/status, system date and remark as universal core fields shown to both roles (qty is already always required and buyer is the existing buyer-or-broker rule), so each role can still book. A role-hidden field keeps any carried value because it is posted by a hidden input. Production role's compulsory set is the same four physical fields on SO, JW and PROD; sales sets unchanged; other roles and kinds untouched.\u003C/li>\n\u003Cli>Q190 2026-10-19 C252 On the four production screens, which fields belong to sales vs production, and should production keep the fields these screens exist to complete?\u003C/li>\n\u003Cli>A190 2026-10-19 Production keeps the completion mandate fields (partyContractNo, job rate/picks, terms/T&Cs, loom/beams/tolerance/gatepass, stock, cut size/rolls/send-as); sales keeps the commercial booking fields (rate, cash discount, payment days, due/promise days, brokerage, pass-on, send-to city). Hidden fields carry via the always-posted hidden form; owner/planner and other roles are unchanged.\u003C/li>\n\u003Cli>Q191 2026-10-19 C253 Does the job-work rate-per-metre field stay on the background Price section as a derived (read-only) value, or does it leave the form too; and does the derived ÷100 formula also apply to the legacy OUTSOURCE form?\u003C/li>\n\u003Cli>A191 2026-10-19 Keep the field on the background Price section as a derived read-only value (C254 later refers to its position in the form, so it stays visible); the wizard no longer asks it. Apply the ÷100 formula to the shared job-work maths (JW + legacy OUTSOURCE, per docs/COSTING §3) but scope the wizard-step removal and read-only rendering to JW only, leaving the legacy OUTSOURCE form otherwise untouched.\u003C/li>\n\u003Cli>Q192 2026-10-19 C254 Does 'switch the positions' mean swap only the job-rate and rate-per-metre blocks (leaving Picks between, so the Price section becomes rate → picks → job rate and matches the summary spec), or should Picks move as well?\u003C/li>\n\u003Cli>A192 2026-10-19 Swap only the two named blocks and keep Picks in the middle: the Price section reads rate per metre → picks → job rate per pick, which is exactly the ORDER_FIELD_SPEC party order the check-and-save summary already uses. Fewest files, reversible, and the shared component keeps OUTSOURCE consistent with its own summary.\u003C/li>\n\u003Cli>Q193 2026-10-19 C255 Does "at the end in terms" mean move the Beams: whose? field to the end of the Price/terms section on the job-work form (rather than keep it in Order & source)?\u003C/li>\n\u003Cli>A193 2026-10-19 Yes — move Beams: whose? out of Order & source and to the end of the Terms section; value, POST name and validation unchanged.\u003C/li>\n\u003Cli>Q194 2026-10-19 C256 The JW table spec lists seven columns but not the C250 Ops 'Details pending' marker — drop it or keep it, and does 'job rate' mean order.jobRate (₹/pick) rather than the derived ₹/m rate?\u003C/li>\n\u003Cli>A194 2026-10-19 Keep the C250 Ops marker at the end (losing a prior owner feature is the riskier reading); show jobRate as ₹/pick because the row explicitly says 'job rate' and C254/C253 treat job rate and rate/m as different values. Mtr/beam = the order qty with its own unit.\u003C/li>\n\u003Cli>Q195 2026-10-19 C257 C257: most live JW orders have no mobile on the party master, so C153's chat/share render disabled. Should the buttons open WhatsApp's contact picker when no number is on file, or stay disabled?\u003C/li>\n\u003Cli>A195 2026-10-19 Open WhatsApp's own contact picker (wa.me/?text=) for both buttons when no number is on file; a known mobile still goes straight to that chat. Nothing is sent automatically; the party master stays the source of truth. Fewest files, reversible, no schema.\u003C/li>\n\u003Cli>Q196 2026-10-19 C261 On the All-orders tab (no type filter), should the per-form draft offers all still show, or does the draft offer appear only on its own kind tab?\u003C/li>\n\u003Cli>A196 2026-10-19 Keep the All tab showing every draft offer (existing behaviour); a kind tab (e.g. ?type=JW) now shows only its own form's draft. Fewest files, reversible.\u003C/li>\n\u003Cli>Q197 2026-10-19 C262 Target says /orders?type=JW but the job rate is only entered (not editable) in the job-work order form. Confirm the +/-0.25 stepper and same-quality suggestions go on the job rate field in the order form (popup + wizard), not on the read-only list?\u003C/li>\n\u003Cli>A197 2026-10-19 Put it on the job rate field in the job-work order form (popup + wizard), because the list only displays job rate (append-only, no edit surface). Same ±0.25 stepper and quality-only history coins as C260's picks control. Keeps the list read-only, fewest files, reversible.\u003C/li>\n\u003Cli>Q198 2026-10-19 C264 The four order forms share one draft mechanism keyed order-new-draft[-TYPE]; the generic OUTSOURCE form (null fixedType) keys order-new-draft but had no draft offer. Should the OUTSOURCE draft be offered as a fourth entry, and on the All tab keep showing every form's draft?\u003C/li>\n\u003Cli>A198 2026-10-19 Add the fourth draft offer for the generic OUTSOURCE form (key order-new-draft, type OUTSOURCE, href /orders/new?type=OUTSOURCE); keep the existing tab filter so each kind tab shows only its own draft and the All tab keeps all four. Client-side on data.fType — fewest files, reversible, no server/DB change, no new field so no new validation.\u003C/li>\n\u003Cli>Q199 2026-10-19 C265 does the removal also apply to the OUTSOURCE operations/production face (PRODUCTION_OP_FIELD_SPEC + ProductionOpForm), or only the /orders/new?type=OUTSOURCE booking form?\u003C/li>\n\u003Cli>A199 2026-10-19 only the booking form named by the row; the operations face keeps its fields so a past OUTSOURCE order's booked T&C/gatepass stays visible and append-only, and no other screen changes\u003C/li>\n\u003Cli>Q200 2026-10-19 C266 C266 asks to move 'Beams: whose?' to the end of terms on the OUTSOURCE form; C255 already moved the shared beamsSource field to the last slot of the Terms section for both JW and OUTSOURCE. Does C266 need a further move (e.g. inside the Outsource terms block), or is the C255 position the intended end?\u003C/li>\n\u003Cli>A200 2026-10-19 The C255 position is the intended end: beamsSource stays the last field of the Terms (Price) section, after the Outsource terms block. OUTSOURCE shares ORDER_FIELD_SPEC and OrderEntryForm.svelte with JW, so C255 already satisfies C266; keep the same POST name, options and validation with no further move.\u003C/li>\n\u003Cli>Q201 2026-10-19 C267 Does 'make outsourced form UI same as job work order form' include treating the OUTSOURCE kind as fixed (no kind picker) and keeping the party field as 'Buyer', changing only the order-no label to Weaver's order no?\u003C/li>\n\u003Cli>A201 2026-10-19 Yes: OUTSOURCE renders the job-work form with its kind fixed by the URL (no kind picker, same title/wizard/spec), and only the party's order-no label changes to Weaver's order no; the party stays the existing buyer/weaver picker because the row names only the order no.\u003C/li>\n\u003Cli>Q202 2026-10-19 C270 After removing quote/lead/broker/buyer-order-no/booking-date from the production-order form, should a ?quoteId=/ ?leadId= deep link still post the reference, and should a production-role create still require the buyer's order no?\u003C/li>\n\u003Cli>A202 2026-10-19 No and no. A field removed from the form must not ride back as an invisible hidden POST, so the quote/lead hidden inputs are gated by shows() and the removed names are in PROD_DROPPED; and a production-role create must not demand a field the form no longer shows, so the PROD production-required set drops partyContractNo while the order-record completion keeps requiring all four via TRADING_PRODUCTION_REQUIRED. Fewest files, reversible.\u003C/li>\n\u003Cli>Q203 2026-10-19 C271 Does 'remove panna from the wizard' keep the panna field editable (its own summary popup) or remove it from the job-work order form entirely?\u003C/li>\n\u003Cli>A203 2026-10-19 Keep the field; remove only the wizard step. A field the wizard stops asking stays editable in its own single-field summary popup (FOCUS-ENTRY §4b), and the hidden form still posts panna exactly as before.\u003C/li>\n\u003Cli>Q204 2026-10-19 C272 Does 'remove loom class master' mean drop the loom_class table and its stored data, or retire only the master tab/form and keep the loom_class column values already on looms (beams/board still read them)?\u003C/li>\n\u003Cli>A204 2026-10-19 Retire only the Loom class master UI/form/action; keep the loom_class table, the loom.loomClass column and every stored value (beams, board and print still read it). Dropping data is irreversible and the row is about the master surface, not the spine.\u003C/li>\n\u003Cli>Q205 2026-10-19 C273 C273: does the first-popup OCR/dictation fill only the trader's booking no., or every booking field the slip/note carries?\u003C/li>\n\u003Cli>A205 2026-10-19 Fill every booking field the read understands (trader no/date, party/broker, product, bags, cones, bag wt, rate, lot, payment term, remark) as prefill only; nothing auto-saves, and the existing form validation + check-and-save gate still decide what is stored.\u003C/li>\n\u003Cli>Q206 2026-10-19 C274 Should the booking wizard keep opening by default with a Start the wizard button appearing only after it is closed, or should /bookings/new open on the summary with the button always shown?\u003C/li>\n\u003Cli>A206 2026-10-19 Keep the signed FOCUS-ENTRY lifecycle: the wizard still opens by default, and the header shows Start the wizard only once it is closed, exactly as the order form does (C141). It reopens at the first popup (the trader-slip capture step).\u003C/li>\n\u003Cli>Q207 2026-10-19 C275 Is the delivery end date a new stored booking field or derived from start+interval?\u003C/li>\n\u003Cli>Q208 2026-10-19 C275 How should bags per interval be divided across the period by default?\u003C/li>\n\u003Cli>Q209 2026-10-19 C275 Is the delivery end date required whenever a delivery interval and bags per interval are set?\u003C/li>\n\u003Cli>A207 2026-10-19 Store it as a new optional booking column delivery_end (ms date); blank keeps every existing row and save path unchanged.\u003C/li>\n\u003Cli>A208 2026-10-19 Deliveries = floor((end-start)/interval)+1 (both ends inclusive); suggest ceil(total bags/deliveries) until the user edits bags per interval, then their -/+ or typed value wins.\u003C/li>\n\u003Cli>A209 2026-10-19 No — keep C210's rule (start+interval+bags own the period); the end date is optional metadata, but when given it must be a real date on/after the start and it requires the start.\u003C/li>\n\u003Cli>Q210 2026-10-19 C279 C279 splits the booking yarn field in two; the mill/ticket is not otherwise on the booking. Store it on the booking itself (new mill_ticket column) or only resolve it into the existing yarn row?\u003C/li>\n\u003Cli>A210 2026-10-19 Store the picked mill on the booking as mill_ticket, because a new yarn row no longer carries a ticket; keep old bookings reading yarn.ticket as the fallback, accept the mill from the mill master or the selected yarn's legacy ticket, and leave the field optional so legacy data still saves.\u003C/li>\n\u003Cli>Q211 2026-10-19 C280 C280 says switch the rate-per-mtr and job-rate positions on /orders/new?type=OUTSOURCE. Should the swap apply only to OUTSOURCE (JW keeps C254's rate -> picks -> job rate, SO unchanged) and to the background Price form plus its check-and-save summary, leaving the wizard unchanged?\u003C/li>\n\u003Cli>A211 2026-10-19 Yes: swap only OUTSOURCE to job rate -> picks -> rate, keep JW at C254's rate -> picks -> job rate and SO unchanged; reorder the background Price form and the summary spec, leave the wizard untouched (it has no rate step). Fewest files, reversible.\u003C/li>\n\u003Cli>Q212 2026-10-19 C283 Does 'Add gp no. Field' mean the trader/party's physical gatepass number (stored in the existing partnerGpNo / PGP no column), or an override of our auto-generated intimation GP number?\u003C/li>\n\u003Cli>A212 2026-10-19 The trader/party gatepass no. It is stored in the existing partnerGpNo column (shown as PGP no on the record); the auto intimation number keeps generating on save and keeps feeding barcodes/lots.\u003C/li>\n\u003Cli>Q213 2026-10-20 C287 C287 says improve UI ergonomics with no screen named. Which screen should change?\u003C/li>\n\u003Cli>A213 2026-10-20 No screen named, so apply the app-wide navigation reading: every screen opens at its own top after a normal navigation, hash targets still work, back/forward unchanged; no data or form behaviour changes.\u003C/li>\n\u003Cli>Q214 2026-10-22 C288 Does 'color code of the complete erp' mean the palette/status hues (the shared token layer), or per-module colour coding?\u003C/li>\n\u003Cli>A214 2026-10-22 The shared palette/status-hue token layer: keep the owner's monochrome decision, make the state colour code readable. Per-module colour coding would be a new design language and is reversible later.\u003C/li>\n\u003Cli>Q215 2026-10-22 C289 row-watch: 2 integrations of C289 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>A215 2026-10-23 Not a code question: both C289 runs died on a DNS outage (getaddrinfo EAI_AGAIN api.deepseek.com) and both deploys failed at step 0 (Could not resolve host: github.com). Network is back — re-run the row.\u003C/li>\n\u003Cli>Q216 2026-10-23 C289 C289 names only 'a smartly designed scrollbar' for the dashboard: restyle the app scrollbar only, or also add a dashboard section map rail (one tick per board section, active tick follows the reader, click to jump) so the layout itself is visible?\u003C/li>\n\u003Cli>A216 2026-10-23 both, because the row asks to understand the layout, not just the position: keep one app-wide scrollbar skin in src/app.css and add a desktop-only section rail on the dashboard whose ticks sit on the same track as the thumb (one tick per board section, active tick follows the reader, click jumps). The skin alone stands if the rail is rejected — delete ScrollMap.svelte and its two lines in +page.svelte.\u003C/li>\n\u003Cli>Q217 2026-10-23 C290 C289's rail was desktop-only (lg:block) and Android draws an untouchable overlay bar, so a phone had no scrollbar to grab. Should the rail show on phones as a draggable thumb?\u003C/li>\n\u003Cli>A217 2026-10-23 yes — one rail for every width: the same 56vh monochrome track, now a pointer/touch drag that moves main.scrollTop (thumb centres on the finger, clamped at both ends), ticks still click to jump; desktop unchanged in look.\u003C/li>\n\u003Cli>Q218 2026-10-23 C291 C291 says the draggable scrollbar can hardly be grabbed by a finger, must look very subtle, and should match the system's scroll: widen the invisible grab lane while shrinking the ink to the system width, or make the whole rail bar thicker?\u003C/li>\n\u003Cli>A218 2026-10-23 Widen the lane, not the ink: a 44px invisible grab lane on phones (24px from sm up) at the right edge, with the visible bar shrunk to the 6px system width in the app's zinc-400 (hover zinc-600, dragging zinc-900), transparent track — it reads as the phone's own bar while the finger gets a real target.\u003C/li>\n\u003Cli>Q219 2026-10-25 C292 C292 says no other UI libraries unless daisyUI can't do it — does that also ban lucide-svelte, which 63 files use for icon glyphs? daisyUI ships no icon component.\u003C/li>\n\u003Cli>A219 2026-10-25 Icons stay. daisyUI has no icon set, which is exactly the row's carve-out; lucide-svelte draws glyphs only (no layout, no components), so the allow-list keeps it and the audit still fails on any second UI kit.\u003C/li>\n\u003Cli>Q220 2026-10-25 C292 Printed paper sheets (src/routes/\u003Cstrong>/print/\u003C/strong> and the checking report) hand-roll their own .tbl grid and print CSS — must their tables become daisyUI table too?\u003C/li>\n\u003Cli>A220 2026-10-25 Paper stays on its own grid. daisyUI has no paper/print component; its table is a screen table (hover, row borders, base-100 fill) and applying it to an A5/thermal sheet would fight the print CSS. Paper is a named exception in scripts/daisy-audit.ts (PAPER_SHEETS + /print/), so app screens are still strictly daisyUI.\u003C/li>\n\u003Cli>Q221 2026-10-25 C292 Many buttons are list rows, keypad keys, chips and backdrop dismissers styled with utilities rather than btn — must every one carry btn?\u003C/li>\n\u003Cli>A221 2026-10-25 No. daisyUI's btn is a control (fixed height, padding, radius); a table row, a card grid tile, a keypad key or a backdrop dismisser is layout the kit cannot express, and forcing btn on them would resize the forms. Rule kept narrow and enforceable: no \u003Cbutton> may be left unstyled (except daisyUI's own modal-backdrop close snippet), and anything that reads as an action uses btn.\u003C/li>\n\u003Cli>Q222 2026-10-25 C293 does 'card swipes left and right' mean the sections become swipe pages, or the cards inside one section swipe sideways?\u003C/li>\n\u003Cli>A222 2026-10-25 cards inside one section swipe sideways; the nine sections stay in one vertical page (the C289/C290 rail already maps them). Fewest files, reversible, and it kills the 29-card phone stack without hiding any figure.\u003C/li>\n\u003Cli>Q223 2026-10-26 C294 The dashboard shows two vertical bars at the right edge: the shell's native main scrollbar (skinned in app.css, C289) and the ScrollMap rail (C289-C291). Which one is the 'extra' one - hide the native bar under the rail, or drop the rail?\u003C/li>\n\u003Cli>A223 2026-10-26 Keep the rail. Since C289/C291 the owner calls the rail 'the scrollbar in dashboard', it is the only bar a finger can grab on a phone (C290) and it carries the section map; the plain native bar lying under it is the duplicate. Hide the native bar on the dashboard only, while the rail is mounted.\u003C/li>\n\u003Cli>Q224 2026-10-26 C295 C295 says keep only the og scrollbar — is the dashboard to keep the app-wide skinned bar (and lose the rail's ink), not the rail as its scrollbar (C294)?\u003C/li>\n\u003Cli>A224 2026-10-26 Keep the og bar. C294 hid the app-wide bar so the rail's ink was the only bar; C295 asks for the original back, so the ink goes instead — the ink is what C294 added over the skin and the cheapest thing to drop. Reversible: both files are 2 small edits.\u003C/li>\n\u003Cli>Q225 2026-10-27 C296 Does 'strict organizational segregation' mean the existing eight work groups (Intake/Orders/Reports/Yarn/Gatepasses/Production/Guard & transport/Admin) are the right segregation, shown one at a time, or should the groups themselves be re-cut by production stage (yarn → beams → weaving → checking → dispatch)?\u003C/li>\n\u003Cli>Q226 2026-10-27 C296 Should the flow screens with no sidebar row today (sizing, winding, beam-end, inward, fabric-in, pending, queue, search, signin) each get a sidebar option, or stay opened from the screen that owns the flow?\u003C/li>\n\u003Cli>A225 2026-10-27 Keep the existing eight groups (each is already one org unit + one role set) and make the segregation structural: one group open at a time, one home per screen, machine-checked. Re-cutting the taxonomy moves every screen for no gain the owner can feel, and is not reversible in one row.\u003C/li>\n\u003Cli>A226 2026-10-27 Keep them off the sidebar: they are flow steps opened from their parent screen (a beam, an order, the queue). Declare each one HIDDEN with its reason so 'which group owns this screen?' still has an answer, and the sidebar stays minimal.\u003C/li>\n\u003Cli>Q227 2026-10-27 C297 C297 names no screen and no measure: 'readability and UI ergonomics throughout the website, use cards more, icons wherever necessary'. Which surfaces does one row cover?\u003C/li>\n\u003Cli>A227 2026-10-27 Shared surfaces first, then the one outlier: the list toolbar (19 list screens), the row popup (RecordDialog, ~20 screens), the plain-table row action (SmartTable) and /pending (last action screen still on dense tables). Icons always ship with their word, never icon-only; a per-screen card rewrite stays later rows' work.\u003C/li>\n\u003Cli>Q228 2026-10-27 C298 C298 says only 'boost lighthouse scores' — no category, no page, no score. Which lighthouse categories does one row own, and how is that measured on a host with no Chrome? (Chrome/Lighthouse cannot run here: no DevTools runtime.)\u003C/li>\n\u003Cli>A228 2026-10-27 The search/SEO + best-practices + first-paint performance items that a server-rendered app can decide in its own head and headers: a per-screen \u003Ctitle> (every screen was nameless — only the print/docs routes set one, so SEO failed on 'document has a title'), a meta description, a theme-color matching the manifest, a light-only color-scheme, the third-party Inter stylesheet off the critical path, and a cache policy for the static files that had none. Measured by a new scripts/lighthouse-audit.ts (22 checks) instead of Lighthouse, since no Chrome exists on this host; the browser-measured items (contrast, CLS, tap targets, LCP) stay for later rows.\u003C/li>\n\u003Cli>Q229 2026-10-27 C299 Which dashboard surface and which kind of chaos — the home board at / (nine sections, 29 cards), the /board/[slug] component pages, or missing data? And may a section be collapsed if a closed row still shows its red/watch tally?\u003C/li>\n\u003Cli>A229 2026-10-27 The home board at /. 'Chaotic' is hierarchy and reach, not missing data: keep every card and number, but draw the nine sections as one-open collapse rows, put the single typed New menu in the header and the needs-action strip first. A closed row keeps its N red / N watch / N cards tally, so nothing is hidden — only folded. /board/[slug] pages are out of scope (they already follow the component-page pattern).\u003C/li>\n\u003Cli>Q230 2026-10-27 C300 Does 'show wizards or wizard options only if necessary for form filling' mean the shared entry wizard opens only on the first step that still needs a value (and not at all when every step is answered), while the signed booking/tippan/order/quote step splits stay as they are?\u003C/li>\n\u003Cli>A230 2026-10-27 Yes — a wizard step is only shown while its field is empty (the FOCUS-ENTRY §11 rule 5 test), so the wizard starts at the first unanswered step and does not open when nothing is left to ask; signed step lists (booking/tippan/order/quote) are not re-split by this row; fewest files (one shared shell + one pure helper), reversible.\u003C/li>\n\u003Cli>Q231 2026-10-29 C301 The All gatepasses screen has no single kind, so its New control opens the plain form (YARN_OUT default): is dropping the kind menu there acceptable, given the eight kinds stay reachable from the sidebar kind rows (/gatepasses?kind=…)?\u003C/li>\n\u003Cli>A231 2026-10-29 Yes. The New control opens the form of the kind the screen is on; on the unfiltered All screen it opens the default form. The eight movements stay one tap away as the sidebar kind rows, so no kind becomes unreachable and no dropdown returns.\u003C/li>\n\u003Cli>Q232 2026-10-29 C302 Where does the warp/weft tag live and what words does it use? The gatepass has no warp/weft column; the yarn lot it creates on delivery already has a soft warp_weft tag (default weft) shown on /lots, and bookings already carry warp|weft|both.\u003C/li>\n\u003Cli>A232 2026-10-29 Reuse the repo's existing warp|weft|both vocabulary on both surfaces and add no gatepass column: the YARN_IN form asks one optional Yarn use row, the value rides the creation event (like beamType/destPlace/mill lot) and is stamped onto the lot the delivery creates, where /lots and the lot record already show it. Fewest files (no schema/migration), fully reversible, and 'both' keeps a mixed batch honest.\u003C/li>\n\u003Cli>Q233 2026-10-29 C303 Is 'kgs received till date' the sum of yarn-in receipts against the booking (their net when weighed, else bags × the booking's per-bag weight), and 'kgs to be received' the order's FULL requirement from the quote formula × order mtrs (not the remaining balance)?\u003C/li>\n\u003Cli>A233 2026-10-29 Yes: 'received till date' is the receipt side of the same booking (a receipt's net kg when it carries one, else its bags weighed at the booking's per-bag weight — this form asks bags, not kg); 'to be received' is the order's total requirement (order mtrs × the quote form's warp/weft kg-per-metre, the side(s) the booking's warp/weft tag names), shown as a pair, not as a remaining balance.\u003C/li>\n\u003Cli>Q234 2026-10-29 C304 C304 — is the yarn field the identity the form already shows (count + type + mill name) or a new yarn-master picker, and what is 'job work' here?\u003C/li>\n\u003Cli>A234 2026-10-29 The yarn field is the yarn identity this form already carries (countYarn + yarnTypeCode + ticket), not a new picker; job work is the existing rate-less open booking (A78/C120), so C303's three sources are unchanged. Auto from a rated yarn booking, user-picked for an SO/production order row, a job-work booking and an ?orderId= carry; both surfaces required on the manual branch.\u003C/li>\n\u003Cli>Q235 2026-10-29 C307 Point 5 'Yarn' — one step or the three yarn rows (count / type / mill name); and does 'except 1, 2 and 4' mean points 3, 5, 6 and 7 are skipped only while OCR already answered them, or removed from the wizard entirely?\u003C/li>\n\u003Cli>A235 2026-10-29 Point 5 stays the yarn identity's own rows (one static row when a yarn booking answers it, the three count/type/mill picks for an SO order or a job work) — the shell asks one field per step and merging them would change how they post. The OCR exemption is C300's skip: points 3, 5, 6 and 7 are not asked while already answered (by the read or a pick), points 1, 2 and 4 always show because nothing fills them.\u003C/li>\n\u003Cli>Q236 2026-10-29 C309 the reference table's single kg column: the system tracks received kg per order/booking, not per yarn count, so a multi-warp/weft row can show each count's required kg but not a per-count pending; and the SO tab keeps listing every open SO/PROD order rather than only rows still short of yarn\u003C/li>\n\u003Cli>A236 2026-10-29 single kg column shows pending / required for the row, and when a quality has several warp/weft yarns the same cell lists each count's required kg followed by the row's total pending / required — never an invented per-count pending; the SO tab keeps every open SO/PROD order (the pending column already says what is left, hiding rows would change what C303 shipped)\u003C/li>\n\u003Cli>Q237 2026-10-29 C310 Is the yarn master's mill / ticket a picker from the mill master or a free-typed name, and must it be filled?\u003C/li>\n\u003Cli>A237 2026-10-29 Picker: a daisyUI select whose options are the mill/ticket master values (rate-board tickets + mill rows), plus the yarn's own current mill so an edit never drops a historic spelling. The booking wizard already picks the mill from that master on its own step, so no free typing returns.\u003C/li>\n\u003Cli>Q238 2026-10-29 C311 Should the yarn Count field become a strict picker (only counts on the count master) or keep accepting a typed number while offering the master?\u003C/li>\n\u003Cli>A238 2026-10-29 Offer, do not restrict: the count stays a typed number with the count master as one-tap suggestions (a datalist), and the yarns themselves project into the master. A strict picker would block the first yarn on a fresh DB and the booking wizard quick-add, while an offer is reversible and keeps every current flow working — same call C310 made for the mill field.\u003C/li>\n\u003Cli>Q239 2026-10-29 C311 Do the design master warp/weft counts also project into the count master, or only the yarn master counts?\u003C/li>\n\u003Cli>A239 2026-10-29 Yarn master counts only — the row links the count master to the yarn master count field. Design rows carry counts from the yarn master already (their picker), so projecting them would widen the master without a request; left out, and reversible in one projection line.\u003C/li>\n\u003Cli>Q240 2026-10-29 C312 Does the type master hold only the eight standard codes (KW/CW/CCW/KCW/Dn/Ly/Sl/Other), or may a new type (CPT, TFO, OE) be added and used on a yarn — and if so must the gatepass yarn-inward type rule follow it?\u003C/li>\n\u003Cli>A240 2026-10-29 New types are allowed — that is what a master is for (the yarn master already carries CPT/TFO/OE-style codes in the imported data), so the master holds the eight built-ins plus anything added with a label. The yarn form's Type select offers the union and resolves a typed variant to the master's spelling; the gatepass yarn-inward field (C304's enum) now carries the same shared code rule instead of a frozen list, so a type the master was just taught never 400s the inward. Reversible: the eight built-ins are always offered, so a fresh DB and the booking wizard behave exactly as before.\u003C/li>\n\u003Cli>Q241 2026-10-29 C313 When the inward's reference is an SO trading order, a production order or a job work (nothing to inherit), is the single yarn field one yarn-master row (count + type + mill as one line), and does the recent direct-delivery job-work pick use the same field?\u003C/li>\n\u003Cli>A241 2026-10-29 One yarn-master row per yarn, its label reading count + type + mill; the pick fills the three POST names in one tap. The same field serves the direct-delivery job-work pick so both inward legs read alike. A yarn booking keeps inheriting its yarn and asks nothing new.\u003C/li>\n\u003Cli>Q242 2026-10-29 C315 When a read prints a booking number AND a destination (a direct-delivery note), which form wins — the direct delivery or the yarn-in reference picker?\u003C/li>\n\u003Cli>A242 2026-10-29 DIRECT wins: the destination already decides the kind (captureRouting C113), and that form has no reference picker, so the number rides unused. Keeps today's direct-delivery behaviour untouched and is reversible.\u003C/li>\n\u003Cli>Q243 2026-10-29 C315 How close must the printed number be to an open booking to pre-select it — exact stored value only, or normalised/fuzzy?\u003C/li>\n\u003Cli>A243 2026-10-29 Normalised letters+digits compare (spacing and punctuation ignored, case-insensitive) against the open/partial rows the picker already lists; no fuzzy or partial match. A number nobody holds pre-selects nothing and rides as a search chip.\u003C/li>\n\u003Cli>Q244 2026-10-29 C316 The owner's type words include 'hank', but the type master (C312) ships no hank code. Should the reader add one ('Hk' hank) to the built-in vocabulary, or leave a hank read untyped?\u003C/li>\n\u003Cli>A244 2026-10-29 Add Hk (label 'Hk hank') to the built-in vocabulary in src/lib/yarnTypes.ts, beside Dn/Ly/Sl. It is additive and reversible (a fresh DB simply offers one more type), and it makes every 'hank' read resolve to one code the type master can rename, instead of an untyped read the operator must fix by hand.\u003C/li>\n\u003Cli>Q245 2026-10-29 C316 C316 says the read value that matches no yarn-master entry is 'a suggestion chip'. Does that chip have to open the yarn-master add form and come back (C319's create-on-the-go chain), or does C316 only owe a visible read chip naming count · type · mill?\u003C/li>\n\u003Cli>A245 2026-10-29 C316 owes the read resolution (one yarn-master entry when count+type+mill match) and a visible chip naming what was read when nothing matches — the tap-to-create-and-return chain is C319's row, so this change only states the read value and leaves the pick to the operator; nothing is created.\u003C/li>\n\u003Cli>Q246 2026-10-29 C317 When the printed spinner line names a mill that is NOT in the mill/ticket master, should the read fill the mill field with the printed words, or leave the field empty and offer the printed name as a chip (tap to create the master, C319)?\u003C/li>\n\u003Cli>A246 2026-10-29 Leave the field empty and carry the printed spinner name as a hint the user is offered (\u003Ccode>millHint\u003C/code>), never as the field's value: a mill the master does not know must not be invented, and the tap-to-create chain that turns the hint into a master entry is C319. Reversible: if the owner prefers the printed words in the field, it is the one \u003Ccode>put(out,'ticket', …)\u003C/code> line in \u003Ccode>prefillParams\u003C/code>.\u003C/li>\n\u003Cli>Q247 2026-10-29 C317 A mill the master knows, printed in prose rather than on a spinner line (a WhatsApp forward 'Sanathan rate 40 CW'), should still read as that master — but only a KNOWN master, never an unknown word. Right?\u003C/li>\n\u003Cli>A247 2026-10-29 Yes: a master entry named in the read still fills the mill, off any line that is not (and does not sit beside) an address; an unknown word only ever reads off a spinner line (a yarn/spinning/mill/tex-div/fabrics line) into the hint, so no unknown mill is resolved or invented from prose. Assumed as the safe 80/20: the alternative (spinner line only) would regress today's WhatsApp mill reads.\u003C/li>\n\u003Cli>Q248 2026-10-29 C319 When the yarn master is opened from a read, what does ?new= carry and how does a new mill get back to the inward? (reading: new=count+type, mill=separately, returnTo=the form, id returned as ?yarnId=)\u003C/li>\n\u003Cli>A248 2026-10-29 Pareto: ?tab=yarn&new=\u003Ccount type>&mill=\u003Cticket>&returnTo=\u003Cthe form>; the yarn form splits count/type from new and takes the mill from mill=, offering it as + \u003Cmill> when the mill/ticket master lacks it (that chip opens ?tab=mill-ticket&new=\u003Cmill>&returnTo=\u003Cthe yarn link> and returns); the save goes back to returnTo with ?yarnId=\u003Cid>&ticket=\u003Cmill> and the inward selects that yarn row. Fewest files, reversible (a link and a param, no column, no POST name), nothing created without the tap.\u003C/li>\n\u003Cli>Q249 2026-10-29 C320 C320 names a read value for the pickup godown/location and for the party/trader, but the gatepass read carries neither (gatepassReadFields hands over count/type/mill/bags/vehicle/transport only). What value does each chip stand on, which master row does a location belong to, and does the created entry have to land on the saved gatepass?\u003C/li>\n\u003Cli>A249 2026-10-29 Pareto: the chip is offered from the value the form already carries — the read's transporter (the one read field that is master-backed), the picked reference's printed supplier when it matched no party (C40's 'pick the party by hand'), and a named pickup place that is not a location-master row. The location master is the party rows of category Godown or Sizing (a Godown added on the go is offered next time; a Godown is no longer listed as a trader), the trader chip is a plain Party row and the transporter chip is a Transport row. Each 'new' is just the typed/printed name; a save returns ?field=<transport|trader|location>&partyId=\u003Cid>&party=\u003Cname> and the form selects it — the created trader rides the yarn-in / direct-delivery sourcePartyId, which the server already reads first (str(d.sourcePartyId) || the booking's), so it becomes the record's trader. Fewest files (the three the row names + the C319 link builder), reversible (a link and URL params, no column, no new zod field, nothing created without the tap).\u003C/li>\n\u003Cli>Q250 2026-10-29 C321 Does the + \u003Ctyped> create row reach every focus pick in the app, or only the masters the row names (yarn, mill/ticket, party faces, count, type)?\u003C/li>\n\u003Cli>A250 2026-10-29 The row names yarn, mill/ticket, party (godown/transport/trader), count and type — the matches FOCUS-ENTRY §20 lists — so the create row is declared on exactly those master-backed fields (gatepass, sizing, winding, samples, movements, stocktake). Design/loom/weave/flange/defect/payment-term picks keep their own tabs and gain the row when their row lands.\u003C/li>\n\u003Cli>Q251 2026-10-29 C322 C322's acceptance asks for a regression test named for the spaced header, but this checkout carries no tests/ suite (removed in 7668c583; deploy.sh runs --no-suite). Where does the regression live?\u003C/li>\n\u003Cli>A251 2026-10-29 Pareto: the durable regression lands in the existing intake script scripts/mill-read-audit.ts as a check named for the spaced header (its PAPER already prints GATE PASS + Booking No. : 1128); it fails pre-fix (intent=booking) and passes post-fix, and the glued GATEPASS case plus a plain booking are pinned beside it. Rebuilding tests/ would resurrect a suite this checkout deliberately removed, and bunfig's preload (tests/setup.ts) no longer exists.\u003C/li>\n\u003Cli>Q252 2026-10-29 C323 The tippan, sample and quote forms have no OCR endpoint of their own (only the shared /capture draft hand-off). Where is 'the read' these forms must learn from?\u003C/li>\n\u003Cli>A252 2026-10-29 The read is the capture draft each form is opened with (?draftId=): the form resolves that draft's transcript from this form's memory at load (memory wins over the read's own answer, validated against the form's masters) and learns the user's corrections at save, exactly the C318 gatepass loop. The quote wizard's dictate step is its second read and is covered by a ?/memory action that answers memory before the fuzzy matcher. No new endpoint, no new intent, no schema.\u003C/li>\n\u003Cli>Q253 2026-10-29 C323 A tippan read's partyHint is a single name — which tippan field does it fill, the sizer or the weaver?\u003C/li>\n\u003Cli>A253 2026-10-29 The sizer: a tippan is the sizing programme, and the sizer is the party the note is addressed to. A remembered party therefore fills sizerId and never the weaver; the weaver still comes from the order/gatepass history as it does today.\u003C/li>\n\u003Cli>Q254 2026-10-29 C317 The goods line prints a 6-digit HSN code (520524). Is a bare 6-digit number on any line still an address mark, or do only the address words count?\u003C/li>\n\u003Cli>A254 2026-10-29 Keep it as a weak own-line mark (a bare PIN line is still an address) but let only the address WORDS spread to neighbours, and never spread over a line that names a mill/spinner — the spinner keeps its own line. Fewest changes to addressContext(), reversible, and the Vishnu cases stay address.\u003C/li>\n\u003Cli>Q255 2026-10-29 C324 adapter-bun serves only the assets listed in its build-time table, so copying the previous build's hashed chunks into build.next does not make them reachable after the restart. Should the swap also register the carried files in the new build's asset table (build.next/adapter-bun.js), or leave them on disk only?\u003C/li>\n\u003Cli>Q256 2026-10-29 C324 which build do the carried chunks come from: the one currently served (build) or the older build.prev?\u003C/li>\n\u003Cli>A255 2026-10-29 Register them: build-swap.ts appends each carried file to the new build's generated asset table with the adapter's own meta (blake2b256 digest sliced to 16 hex + file mtime), so the open tab's chunk URL is served by the new build too. Additive and reversible (a table the script cannot find aborts the swap before anything served changes); a file left on disk but unregistered would still 404 after the restart, which is exactly the bug C324 is closing.\u003C/li>\n\u003Cli>A256 2026-10-29 From the build being replaced (build), not build.prev: those are the chunks an already-open tab asks for. build.prev stays as the rollback copy only.\u003C/li>\n\u003Cli>Q257 2026-10-29 C325 Does the read's saved gatepass photo become the form's Gatepass photo by COPYING the file into the screenshots upload drop (the draft keeps its own copy), and does it also overwrite a photo the operator already snapped before the read?\u003C/li>\n\u003Cli>A257 2026-10-29 Copy, never move: the read's file is written to screenshots/capture as before (the draft's rawImage keeps /capture-img/\u003Cname>), and a second copy goes to the screenshots upload drop under the SAME name so the form's existing \u003Ccode>image\u003C/code> field and /upload-file/\u003Cname>?bin=screenshots resolve it with no schema/route change; the two copies are independent files, so a later upload never touches the draft's copy. Only a gatepass read does it (other intents unchanged) and only for an image (a PDF read leaves the photo field empty — the pane still shows the PDF). The read sets the photo only when the field is empty or still holds the previous read's file, so a snap the operator took first is never overwritten and the row's own Replace still wins.\u003C/li>\n\u003Cli>Q258 2026-10-29 C326 does the pinch also have to apply to a PDF gatepass in the verify pane, and does the photo box take over page scrolling while a finger is on it?\u003C/li>\n\u003Cli>A258 2026-10-29 Image only: the PDF branch keeps its own iframe viewer, since a pointer layer over a PDF fights the browser's reader which already pinches and pans (fewest files, reversible). And yes — touch-action:none lives on the photo box alone, so the rows outside the pane still scroll natively; the box owns touch only while the pane is open\u003C/li>\n\u003Cli>Q259 2026-10-29 C327 Are the two new top buttons shown only while the wizard is closed (the C141/C274 Start-the-wizard pattern) or always at the top of the yarn-in screen?\u003C/li>\n\u003Cli>A259 2026-10-29 Always render them for YARN_IN: the wizard overlay covers the screen while it is open, so they are visible exactly when they can be tapped; no wizOpen state has to be exported out of the shared FocusEntry.\u003C/li>\n\u003Cli>Q260 2026-10-29 C327 What does Start OCR open - the wizard step that carries the read card (gatepassRead), or the read card alone in its own popup?\u003C/li>\n\u003Cli>A260 2026-10-29 Start OCR opens the wizard's own gatepassRead step (the same read card the walk starts on); on a carried yarn-in where that id is not in the walk it opens the same field's popup, which renders that identical read card. Nothing new is built behind either button.\u003C/li>\n\u003Cli>Q261 2026-10-29 C328 C328 asks for a regression test but this checkout carries no tests/ suite (removed in 7668c583); where does the marker guard's test live, and does a marker line in prose count?\u003C/li>\n\u003Cli>A261 2026-10-29 The test lives in the guard itself: scripts/check-conflict-markers.sh --self-test replays the 2026-10-29 incident in a throwaway repo (6/6), and deploy.sh runs it as step 0a so it keeps running. Resurrecting tests/ would undo 7668c583 and bunfig's preload no longer exists — same reading as A251. Markers are line-anchored, so a marker named mid-sentence in prose is not one; a real marker line in any tracked file refuses the commit.\u003C/li>\n\u003Cli>Q262 2026-10-29 C329 The row says the trader's GP no format is letters/digits/slash, 24 chars max, 'validated exactly like the field' — but the live partnerGpNo field allows letters/digits/space/hyphen/slash up to 64. Should the field itself be tightened to 24, or only the read?\u003C/li>\n\u003Cli>A262 2026-10-29 Keep the field's existing 64-char rule untouched (a live field must not tighten silently) and cap only the read at the row's 24 with letters/digits plus the field's own space/hyphen and slash — every read value then passes the field's rule; reversible in one line if the owner wants 24 on the field.\u003C/li>\n\u003Cli>Q263 2026-10-29 C330 Does 'every other read value' include the weights (gross/net) and the expected date, which the YARN_IN form shows no row for?\u003C/li>\n\u003Cli>Q264 2026-10-29 C330 Should an in-page read of a booking number that DOES match an open reference pre-select that reference (like the page-load carry does), or leave the pick to the operator?\u003C/li>\n\u003Cli>A263 2026-10-29 Yes — list them. The read card is a report of everything the paper gave, not only this kind's rows; a value read and invisible is the exact complaint. Nothing is posted for a value the kind has no row for.\u003C/li>\n\u003Cli>A264 2026-10-29 Leave the pick to the operator. Only a number that names no open reference rides as the chip and seeds the search; preselecting client-side would silently inherit a trader/yarn/rate the page-load carry resolves on the server.\u003C/li>\n\u003Cli>Q265 2026-10-29 C332 the yarn-in packing row is now labelled 'Cones per bag' — should it also be ENTERED per bag (with the delivery total derived) or is the label alone the fix while the guard still types the delivery total?\u003C/li>\n\u003Cli>A265 2026-10-29 enter it per bag: a yarn delivery is counted as cones per bag (the same figure the booking already carries), so the row now takes the one-bag count, the delivery total is bags × cones/bag and is stored in the existing cones column (the lot's bag grain and every report keep reading one total), and the per-bag figure lands in the existing cone_per_bag column. Label-only would have written 60 into a field the ledger reads as a delivery total, so the safe reading is the one that keeps the stored total exact.\u003C/li>\n\u003Cli>Q266 2026-10-29 C333 Does 'every row the yarn-in wizard shows is required except remark' include the 'Read the gatepass' OCR card row (wizard step 1)? Making it required would force a photo read before Save, so manual entry could no longer be used.\u003C/li>\n\u003Cli>A266 2026-10-29 No — the read card stays optional: a guard must still be able to type a gatepass in by hand. The Gatepass photo row the read fills IS compulsory, so every saved yarn-in still carries a photo; only the automatic read is a convenience, never a gate.\u003C/li>\n\u003Cli>Q267 2026-10-29 C333 Does 'compulsory' mean a number must be entered (0 is a value) or that it must be greater than 0?\u003C/li>\n\u003Cli>A267 2026-10-29 Compulsory means the row was filled — a posted 0 counts as filled (bags 0 also posts an empty receipt today, and the bags rule stays '0 or more'; cones/bag and bag weight already refuse 0 by their own >0 rule). No new range rule is added by this row, so nothing that worked before is refused.\u003C/li>\n\u003Cli>Q268 2026-10-29 C334 Do the long field-pop-up lines go away for every screen or only the gatepass page, and do short source markers ('today', 'Auto — from the picked booking') stay?\u003C/li>\n\u003Cli>A268 2026-10-29 Owner ruled on reading: the explanation line goes from every FocusEntry step/pop-up (one shell, reversible), and this row sweeps the gatepass page only; the short source markers are values of the field, not explanations, so they stay in the summary rows and the pop-up carries just the label + the field. Nothing is removed from other screens' own components in this row.\u003C/li>\n\u003Cli>Q269 2026-10-29 C335 The read's Booking No. is the trader's own slip number (C315) — does the chip open the booking form's Trader booking no. field with it (this build), or should it instead match/consume it as the system booking number (BK-…)?\u003C/li>\n\u003Cli>A269 2026-10-29 The trader's booking no. field — the paper's number IS the trader's own reference (C209's first field), so the booking is created carrying it; the system number stays system-generated. Return link is ?returnTo= validated like every master carry, and the booking's save returns to the yarn-in as ?bookingId=\u003Cid> so the picker selects the new row.\u003C/li>\n\u003Cli>Q270 2026-10-29 C336 Which top-block line counts as the docIssuer when the letterhead carries no firm suffix (e.g. a bare 'GOENKA'), and what validation rule does the new field take?\u003C/li>\n\u003Cli>A270 2026-10-29 Only a line that reads like a firm (a company suffix: Private Limited / Pvt Ltd / Ltd / LLP / Syndicate / Industries / Mills / Textiles / Traders / & Sons, on the top block before the first label and outside an address line) is the issuer; a bare one-word top line is not, so nothing is keyed to a guess. The model may fill it when the text read misses. Rule on both surfaces: letters, digits and a firm's punctuation (& . , ' ( ) -), 3-80 chars, blank stays blank.\u003C/li>\n\u003Cli>Q271 2026-10-29 C337 Which fields does a learned gatepass FORMAT cover — every readable field, or only the identity fields the row names?\u003C/li>\n\u003Cli>A271 2026-10-29 Only the row's own three identity fields — booking no, the trader's GP no, the mill/ticket. Count/type/transport already resolve through the word memory (form_memory) and adding them here would duplicate that rule in a second table.\u003C/li>\n\u003Cli>Q272 2026-10-29 C337 Does a learned anchor override a value the regex read or the model answered?\u003C/li>\n\u003Cli>A272 2026-10-29 Never. The deterministic pre-pass runs after the regex parse and before the model's answer is merged; it only fills a field the parse left empty, and the model/merge only fills what is still empty. A value the reader already produced wins, so nothing the paper was read as is silently replaced.\u003C/li>\n\u003Cli>Q273 2026-10-29 C338 How is the issuer known before the gateway prompt when a read starts from a photo only?\u003C/li>\n\u003Cli>Q274 2026-10-29 C338 Should the read card show the format line even when the hinted call could not run?\u003C/li>\n\u003Cli>A273 2026-10-29 The read's own first pass names the letterhead, so the issuer is known one step later without a second look at the photo: the hint rides a follow-up call over the same transcript (text only, no image again), asked only when the read is a gatepass and that issuer already has learned rows. A first read of a new trader spends nothing.\u003C/li>\n\u003Cli>A274 2026-10-29 Yes. The line states what is known about the issuer's layout, not a promise about this answer, so it is drawn whenever the gatepass read's issuer has learned rows — even if the hinted call returned nothing.\u003C/li>\n\u003Cli>Q275 2026-10-29 C339 With two lanes, may a lane claim only its own pid so a dead lane is detected per lane (never masked by a busy one), and does a docs-only target count as a conflict?\u003C/li>\n\u003Cli>Q276 2026-10-29 C339 Which measure counts as the rows/hour before, and is the after figure allowed to be read later with the same command instead of inside this row?\u003C/li>\n\u003Cli>A275 2026-10-29 Yes: each lane's claim is its own pid file (.row-claims/\u003Cn>: pid, row, targets), so a dead lane is pruned by pid alone and one busy lane never masks it; --unstick --keep names only the live lanes' rows. Every finish also keeps the other lane's live session out of the sweep.\u003C/li>\n\u003Cli>A276 2026-10-29 The before figure is the log's own window right before the change (12h = 4.25 rows/h, 51 rows; 24h = 2.12), and the after figure is read later with the same 'bash scripts/row-watch.sh rate \u003Ch>' command once the two-lane watcher is actually live — this row does not deploy, so measuring it here would be fiction.\u003C/li>\n\u003Cli>Q277 2026-10-29 C341 This host already runs Bun 1.4.4, which is the newest stable release (bun-v1.4.4, published 2026-10-22) — there is no newer version to install. What should the row deliver?\u003C/li>\n\u003Cli>A277 2026-10-29 Pin the runtime in the repo instead of leaving it to whatever each host installed: .bun-version = 1.4.4 (Bun and CI read it) plus scripts/bun-upgrade.sh that upgrades a host to the pin, never downgrades, backs the binary up and rolls back on failure — and prove this host is at the pin. Upgrading becomes one repeatable command for the Pi, the VPS and the phone.\u003C/li>\n\u003Cli>Q278 2026-10-29 C342 The row asks for 'a legacy cost flag' without naming its table: is it one flag on order, or a flag on each new cost table?\u003C/li>\n\u003Cli>A278 2026-10-29 One flag where legacy meaning lives: order.legacy_cost (boolean, default 0) marks a pre-WAC order so the costing engine never re-costs it, and cost_leg/cost_apportionment carry the same defaulted flag for a row carried in from legacy data. No new-table row exists today, so nothing needs a second switch.\u003C/li>\n\u003Cli>Q279 2026-10-29 C343 The row's gate says 'tests green', but this checkout has no test suite (tests/ and its bunfig root were removed 2026-10-05). Where should the costing engine's tests live?\u003C/li>\n\u003Cli>Q280 2026-10-29 C343 Does a WAC average count out-entries and zero-cost/salvage entries, and is salvage sale proceeds revenue in the SO P&L rather than a fabric cost?\u003C/li>\n\u003Cli>A279 2026-10-29 Co-locate the tests with the engine as src/lib/server/costing/costing.test.ts and run them standalone with bun run (bun test cannot discover anything while bunfig's root ./tests is missing); one file inside the row's target, reversible, and it can be adopted by the suite unchanged when tests/ returns.\u003C/li>\n\u003Cli>A280 2026-10-29 A WAC is SUM(value) of the inward entries divided by SUM(qty) of the inward entries: out entries are valued at the average of their own moment and never move it, and zero-cost entries (salvage track, or any entry worth zero) are excluded from the average while their quantity stays in stock. Salvage carries no fabric value at all (zero-cost track) and its sale proceeds are revenue rolled into the parent SO P&L; a damaged SO's own sale is that SO's revenue, not an extra roll-up.\u003C/li>\n\u003Cli>Q281 2026-10-29 C344 Where does a yarn receipt's ₹/kg come from — the booking behind the gatepass, the order's locked cost basis, or the yarn supplier default? And should a receipt with no priced booking stay out of the WAC?\u003C/li>\n\u003Cli>A281 2026-10-29 Take the booking's ratePerKg as the receipt's ₹/kg (the figure the inward already reads through the gatepass's booking carry); a receipt with no priced booking writes a zero-cost pool entry — its kg is stock, it never moves the average, so a free/opening lot cannot drag the WAC and a later purchase changes only future issues. Fewest files, reversible: the pool row can be re-read but is never rewritten.\u003C/li>\n\u003Cli>Q282 2026-10-29 C345 Where does a production order's sale-order link live, and what does a shortfall shrink against, given no cost_apportionment row exists before completion?\u003C/li>\n\u003Cli>A282 2026-10-29 Keep it in the event ledger: the create stamps po:planned with the soId, the plan is the SO remaining rounded up to 100 (own qty when nothing is left), and the assignment a shortfall shrinks is the PO's planned metres until a cost_apportionment row exists.\u003C/li>\n\u003Cli>Q283 2026-10-29 C345 Does cancelling a production order need to move stock, or only the apportionment tag, and how are cost legs treated?\u003C/li>\n\u003Cli>A283 2026-10-29 Only the tag: append an out tagged to the PO plus a free in at zero value, so kg and WAC never move; the conversion legs stay provisional and nothing is accrued. Produced fabric is already free (completion writes no order tag).\u003C/li>\n\u003Cli>Q284 2026-10-29 C346 Is cost coverage mandatory on every new sale order, and where does market fabric's WAC come from before C349's purchase form exists?\u003C/li>\n\u003Cli>A284 2026-10-29 Coverage stays OPTIONAL: a sale that posts no coverage books exactly as it always has (no apportionment, no auto PO), and only a started coverage must balance exactly to the sale quantity — reversible and it cannot break the SOs the owner raises today. Market fabric is read from the purchased pool track C342 already gives us (keyed quality+pick, its own WAC, never blended with produced), so the row needs no new source of truth and C349's purchase form will simply feed the same track.\u003C/li>\n\u003Cli>Q285 2026-10-29 C346 What cost does a new-production-order line lock at save, and is parent_so_id required on a damaged sale?\u003C/li>\n\u003Cli>A285 2026-10-29 A new production order's line locks at zero cost and provisional — C345's completion already re-prices the assigned metres to incurred ÷ good mtrs, so nothing is invented at booking and the margin shows as provisional. parent_so_id stays optional but validated when present (an existing, non-cancelled SO; refused on a normal sale): a damaged lot can be sold without its parent named yet, and C348 is what gates X-grade sales.\u003C/li>\n\u003Cli>Q286 2026-10-29 C347 When a sale order's quality or pick changes, does the full reassignment happen in the same save as the release, or as the separate rebalance action?\u003C/li>\n\u003Cli>A286 2026-10-29 Release in the amend save, reassign through the single rebalance action — one place prices coverage, no half-priced in-between state\u003C/li>\n\u003Cli>Q287 2026-10-29 C347 Should a production order that is already complete (cost frozen) be cancellable, and should a sale-order quantity rise be refused while it is uncovered?\u003C/li>\n\u003Cli>A287 2026-10-29 A completed PO is never cancelled (its unit cost is frozen and its output already sits in the produced pool); a quantity rise is accepted and leaves a visible gap for the rebalance action, so nothing is silently refused\u003C/li>\n\u003Cli>Q288 2026-10-29 C348 Does an X roll keep status reject (so only the damaged-SO path can ever ship it), or should it be FG with the sale gated by the damaged marking?\u003C/li>\n\u003Cli>A288 2026-10-29 X keeps status reject: the FG dispatch gate (status FG only) then refuses it, which is today's behaviour for a non-usable roll, and the only door for X is a damaged sale order — enforced where the roll names its order on the checking form. Reversible, no dispatch change.\u003C/li>\n\u003Cli>Q289 2026-10-29 C349 Is GST part of the landed fabric cost (capitalised into the purchased WAC) or an input credit excluded from it, and with only one cost leg does the leg carry the landed ₹/m (rate + freight) or the invoice rate?\u003C/li>\n\u003Cli>Q290 2026-10-29 C349 When a market purchase is assigned to a sale order, does the purchased pool also get an out entry, or only the market apportionment C346 already writes?\u003C/li>\n\u003Cli>Q291 2026-10-29 C349 Should a market fabric purchase be owner-approved (C111) like other orders, or recorded approved at entry?\u003C/li>\n\u003Cli>A289 2026-10-29 GST is input credit, so it is excluded from the landed cost and recorded as cost_leg.gst_pct; freight is capitalised. With one leg, the leg carries the landed ₹/m (amount ÷ qty) and order.rate keeps the invoiced fabric ₹/m — reversible, and the pool and the leg then agree to the paisa.\u003C/li>\n\u003Cli>A290 2026-10-29 Only the market apportionment, exactly as C346 writes a market line: the fabric is still physically in stock until dispatch, and C346's release path does not give a pool out entry back, so writing one here would invent an imbalance. Fewest files, reversible.\u003C/li>\n\u003Cli>A291 2026-10-29 No new gate: the purchase records approved at entry with the signed-in user, like the other cost entries; C111's order approval stays on the sale/job/production orders it already covers. A gate can be added later without touching the write.\u003C/li>\n\u003Cli>Q292 2026-10-29 C350 What does the stock report mean by free vs apportioned vs WIP?\u003C/li>\n\u003Cli>Q293 2026-10-29 C350 Live lots predate the pool wiring (pool_entry is empty on data.db) - should the stock report go blank until new receipts land?\u003C/li>\n\u003Cli>Q294 2026-10-29 C350 Does own vs party apply to the fabric tracks too?\u003C/li>\n\u003Cli>A292 2026-10-29 The report splits the pool balance: total = free + apportioned (apportioned = kg on entries a still-live production order still holds), and WIP is yarn already issued to a live order — it has left the pool, so it is shown beside the balance, never inside it. Same rule on both surfaces.\u003C/li>\n\u003Cli>A293 2026-10-29 No. A lot with no pool receipt is its own 'opening' line at blank WAC — kg counts as stock, no price is invented (the rule C344 already applies to an unpriced receipt). Today that keeps the live screen populated; each new receipt moves its kg onto the pool line at WAC.\u003C/li>\n\u003Cli>A294 2026-10-29 Own/party stays a yarn dimension (lot.owner). Fabric on the produced/purchased tracks is always ours — job-work cloth never enters a pool — so the fabric table omits the split instead of printing a fake zero.\u003C/li>\n\u003Cli>Q295 2026-10-29 C351 A DIRECT delivery to a weaver: does the destination post its own word (destPlace 'weaver') or keep reusing 'sizer'?\u003C/li>\n\u003Cli>A295 2026-10-29 its own word: destPlace gains 'weaver' beside 'sizer' — the creation event and the detail page must say where the yarn actually is, and the stock location is read from the party's category, so no WAC or pool code moves; the enum change is one word and reversible\u003C/li>\n\u003Cli>Q296 2026-10-29 C352 Do the new freight and purchase brokerage enter the booking's GST and total amount, and is the landed ₹/kg built on the basic (GST-excluded) amount or the inclusive total? And what is the received kg when the receipt carries no weight of its own?\u003C/li>\n\u003Cli>A296 2026-10-29 Both are add-ons beside the yarn amount: they never enter basic/gstAmt/totalAmt (GST is input credit, it rides the invoice, not the stock) and the landed amount is the basic amount + freight + brokerage divided by the arrived kg. A receipt with no weight of its own bills the booked kg (a full receipt), so every already-saved booking lands at its own ₹/kg.\u003C/li>\n\u003Cli>Q297 2026-10-29 C352 row-watch: 2 integrations of C352 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q298 2026-10-29 C353 C353 leaves three things open: what 'packing and loading direct' means, how a sizing bill's billing kg reverses out of the received count, and where the checking rate's 'yearly default' is stored (there is no checking-rate master table).\u003C/li>\n\u003Cli>A298 2026-10-29 'Direct' = a lump rupee amount with no per-unit base (qty 1, rateUnit job) capitalised at PO level, because packing, loading and freight are part of what the produced metre cost — C342's 'so' level stays for one-off charges that belong to a sale order, not to conversion. The sizing billing kg = kg sent x count sent / count received (a kg is inversely proportional to the count for the same length), and when the bill states it, that kg is the leg's qty with the gap kept as the quantity variance and written into the row's reason. No checking-rate table exists, so the rate is typed per leg (editable, as the row says) and the engine's checkingRateFor resolves quality + year with the yearly default (null-year row) and the global default the moment such rows exist — no migration, no master screen.\u003C/li>\n\u003Cli>Q299 2026-10-30 C353 row-watch: 2 integrations of C353 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q300 2026-10-30 C354 A bill covers several orders of its kind: does it allocate pro rata to the quantity each order committed, and what does a bill that states no quantity mean?\u003C/li>\n\u003Cli>A300 2026-10-30 Pro rata to the committed quantity, one line per open leg grouped by order, the last line absorbing the rounding so the lines add back to the bill; a bill with no stated quantity counts as the committed quantity, so it is all rate variance and no phantom quantity gap. Fewest files (one pure allocateBill), reversible.\u003C/li>\n\u003Cli>Q301 2026-10-30 C354 A settled bill moves the order's unit cost, its produced pool entry and every sale-order hold. Should the pool entry and the holds be rewritten in place, or should a new pool/hold row be written?\u003C/li>\n\u003Cli>A301 2026-10-30 In place: the bill is the correction of the same document, so the same pool entry and holds are restated with the new unit cost, with an amendment row plus a po:restated event keeping the before/after. No second pool/hold row means no double counting and nothing to learn to release. Reversible.\u003C/li>\n\u003Cli>Q302 2026-10-30 C354 Where does a sale order's P&L status live, and how is the last-bill auto-close vs a manual close with bills missing kept apart?\u003C/li>\n\u003Cli>A302 2026-10-30 Derived from the ledger, not a new column: no so:pnl:closed event = provisional, one = closed. The last bill auto-closes; a manual close needs a reason and that reason is the flag carried on the close. No migration, reversible.\u003C/li>\n\u003Cli>Q303 2026-10-30 C354 Does the bill header need a new table, and how does a pasted vendor bill list behave when a line cannot be read?\u003C/li>\n\u003Cli>A303 2026-10-30 No table: the bill header is the bill:recorded event (vendor, no, date, kind, amount, GST, allocations, variances), and the bills-pending row is an exceptions row on the existing queue board. An import reads one bill per line, comma/tab separated, and a bad line is reported by number and never guessed. No migration, reversible.\u003C/li>\n\u003Cli>Q304 2026-10-30 C354 row-watch: 2 integrations of C354 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q305 2026-10-30 C355 Where do the SO P&L charge percentages (freight-out, insurance, octroi & statutory, sample, overhead) live?\u003C/li>\n\u003Cli>A305 2026-10-30 The four outgoings and the overhead are shares read per sale: the company-wide default is the 1% constant (\u003Ccode>SO_PNL_DEFAULTS.overhead\u003C/code>, and the quote engine's fallback), and this sale's own reading of the five shares is an append-only so:pnl:lines event, edited from a Change the shares form on the order record. No column, no migration, reversible: the defaults stand when no event exists. C355 re-check: the quality master's Other expense % never feeds either surface (owner §252) — the old stored 6.5 cannot pull the overhead back; a quote's own saved reading still wins.\u003C/li>\n\u003Cli>Q306 2026-10-30 C355 All 627 designs still store the sheet's 6.5% other expenses and both quote screens read it as the fallback, so quotes still price 6.5% overhead. Rewrite the stored values to 1, or stop reading the master?\u003C/li>\n\u003Cli>A306 2026-10-30 Stop reading the master on both quote surfaces (owner §252 already rules Other % quote-only, never the master): /quote/new prefills null and /quote/edit passes null, so both fall to the 1% company constant and a quote's own saved reading still wins. No stored value rewritten — reversible with git, old designs keep their history, and the seeds now write 1.\u003C/li>\n\u003Cli>A297 2026-10-30 Cause fixed: the deploy abort was /reports returning 500 (C350 removed costBasis from the load but the page still rendered it). Restored costBasis in the load; load returns openPos, costBasis, soDelivery, stock, fabricStock. The row work is in the tree and proven — ship it, do not re-run.\u003C/li>\n\u003Cli>A299 2026-10-30 Same cause as Q297: the /reports 500 aborted every deploy. Fixed in the load (costBasis restored). Do not re-run C353; the leg-basis work is in the tree and proven — ship it.\u003C/li>\n\u003Cli>A304 2026-10-30 Same cause as Q297: the /reports 500 aborted every deploy. Fixed in the load (costBasis restored). Do not re-run C354; the bills/restatement work is in the tree and proven — ship it.\u003C/li>\n\u003Cli>Q307 2026-10-30 C355 row-watch: 2 integrations of C355 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>A307 2026-10-30 Same /reports 500 that blocked C352-C354. Fixed in the load (costBasis restored) and shipped: C355 is done and live in 7149bbe6 (live-check 83/83). Do not re-run.\u003C/li>\n\u003Cli>A1 2026-10-30 Moot: C99 and C100 both landed long ago; the per-field popup split is live. No action.\u003C/li>\n\u003Cli>A2 2026-10-30 Keep as shipped: the one-tap Create buttons stay beside the prefill links. No change.\u003C/li>\n\u003Cli>Q308 2026-10-30 C357 Opening stock is entered once at cutover — should a pool key that already has an opening line accept a second one (a re-count, or the same count held at two godowns)?\u003C/li>\n\u003Cli>A308 2026-10-30 No second line per pool key: the key already entered refuses it, and the paste import is all-or-nothing, so a re-run of the same sheet can never double the stock. A later re-count adjusts the pool with its own entry, not by re-opening the cutover line.\u003C/li>\n\u003Cli>Q309 2026-10-30 C357 Should an opening line require a value, or may it book unpriced stock (blank ₹) at zero cost?\u003C/li>\n\u003Cli>A309 2026-10-30 Value is optional: a blank ₹ books the quantity as unpriced stock (its kg/mtrs counts, the pool average never moves) — the same rule an unpriced receipt already follows, so no price is ever invented. A line with a value stores qty and ₹, and the pool reads its WAC from them.\u003C/li>\n\u003Cli>Q310 2026-10-30 C356 Must every exceptional charge carry a document ref and a reason, or may a charge be booked without paper?\u003C/li>\n\u003Cli>A310 2026-10-30 Both are required. The row itself says the charge comes 'with document ref and reason'; a charge nobody can tie to a paper is not answerable later, and the append-only model has no edit to add one. One rule table refuses blank on both surfaces, so nothing extra is written and the rule is reversible by relaxing the regex.\u003C/li>\n\u003Cli>Q311 2026-10-30 C356 At PO level the charge is capitalised — does it also restate the order's ₹/m immediately, or only at the next bill?\u003C/li>\n\u003Cli>A311 2026-10-30 Immediately. 'Capitalised, moves WAC' is the row's own words; waiting for a bill would mean an exceptional charge sits in cost_leg but not in the order's cost, and the sale orders holding it would keep a stale margin. The booking runs the same restateOrder cascade a bill runs, inside the same transaction, so the leg and the new ₹/m cannot disagree.\u003C/li>\n\u003Cli>Q312 2026-10-30 C358 What counts as the delivered metres a manual fulfilment is judged on, which status word does 'fulfilled' write, and what is the tolerance when the order has none?\u003C/li>\n\u003Cli>A312 2026-10-30 Delivered metres are the dispatch slips of this order in status loaded or delivered (the same measure dispatch's own auto-delivery already uses), and 'fulfilled' writes the existing status word delivered so no reader learns a new one. The tolerance is order.diff_mtr, and a blank tolerance reads 0 — nothing is invented, so a delivery one metre off without a stated tolerance is blocked and names the amendment.\u003C/li>\n\u003Cli>Q313 2026-10-30 C358 An excess inside the tolerance must be apportioned before marking. May a new production order carry it, and at what cost does the extra land?\u003C/li>\n\u003Cli>Q314 2026-10-30 C358 What does reversing a fulfilment undo, given a shortfall's holds were already released at locked cost?\u003C/li>\n\u003Cli>A313 2026-10-30 Only free stock (produced or market pool) or an existing open production order may carry the extra, at that source's current cost (pool WAC, or the PO's committed cost per planned metre) — exactly what the coverage card already offers. A new production order is refused here: the row says stock or an existing PO, and a new PO would lock the extra at zero and price it later.\u003C/li>\n\u003Cli>A314 2026-10-30 A reversal returns the status only (delivered back to in-prod), recorded as an amendment and an event. The holds a shortfall released stay released and the extra apportionment stays written — append-only, so the answer to them is the coverage card's rebalance, not an undo. The reversal rides C152's order_change rail, so a non-owner's press leaves a pending item on /approvals and nothing moves until the owner decides.\u003C/li>\n\u003Cli>Q315 2026-10-30 C357 row-watch: 2 integrations of C357 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q316 2026-10-30 C358 row-watch: 2 integrations of C358 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q317 2026-10-30 C359 A read gatepass that prints a godown address but no booking number and no explicit 'direct delivery' words — which kind should the link open? (taken as: none carried, so the form keeps its own default YARN_OUT)\u003C/li>\n\u003Cli>Q318 2026-10-30 C359 Should the printed godown ADDRESS prefill the yarn-in's 'Location of pickup' row (destPlace)? (taken as: no — the address is the trader's own godown, not one of our four place words, so the existing our-godown default stays)\u003C/li>\n\u003Cli>A317 2026-10-30 Pareto, reversible: no kind is carried without an explicit signal. A booking number means YARN_IN, an exact godown/premises/sizer word or the words 'direct delivery' mean DIRECT, everything else leaves ?kind= off so /gatepasses/new keeps its existing YARN_OUT default. Never guess a movement from a printed address.\u003C/li>\n\u003Cli>A318 2026-10-30 No. The address names the trader's godown, which is not our-godown/premises/sizer/weaver — writing it into destPlace would mislabel the receipt's location. The row keeps its our-godown default; the address itself is dropped by the reader (destinationSane), so it never becomes a movement or a place word.\u003C/li>\n\u003Cli>Q319 2026-10-30 C360 The child form (masters / bookings-new) is a full route: does the modal re-render it as a native in-page Svelte modal, or open the same route in a same-origin iframe and let it post its save back?\u003C/li>\n\u003Cli>A319 2026-10-30 Same-origin iframe of the existing child route, one postMessage back on save — no second copy of the masters / booking forms.\u003C/li>\n\u003Cli>Q320 2026-10-30 C360 A booking created in the modal is not in the page's open-bookings read: what does the reference table show for it before a reload?\u003C/li>\n\u003Cli>A320 2026-10-30 The number and the yarn the read carried, remainder '—' — never an invented kg; the server resolves the real booking from the DB on save.\u003C/li>\n\u003Cli>Q321 2026-10-30 C359 row-watch: 2 integrations of C359 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q322 2026-10-30 C361 The row says 'Total cones not needed' on the yarn-in: drop only the read-only 'Total cones in this delivery' row (and its arithmetic in the cones-per-bag sub), or also stop storing the derived total in the gatepass's cones column?\u003C/li>\n\u003Cli>A322 2026-10-30 Display only: the yarn-in asks one bag's cones and one bag's weight and shows no total; the derived figure (bags × cones/bag) still posts as cones so the lot's bag grain, the reports and the prints keep reading one total, and the gatepass record's own read-only line stays as it is. Fewest files, nothing to migrate, reversible.\u003C/li>\n\u003Cli>Q323 2026-10-30 C360 The drain's build is red from HEAD (C357's browser module src/lib/openingStock.ts imports #lib/server/costing/pool.ts, which SvelteKit's server_only_import guard refuses): fix it inside this row, or leave C360 unshippable and let another row carry it?\u003C/li>\n\u003Cli>A323 2026-10-30 Fix it here, the narrowest reversible way. The key is one rule and both the engine and the opening-stock entry must build it, so yarnKey/fabricKey move to client-safe src/lib/poolKey.ts and costing/pool.ts imports and re-exports them; PoolTrack aliases KeyTrack. Key strings are byte-identical, no costing behaviour moves, three files plus one new, reversible. Leaving it red would cap C360 at its second failed deploy and stop the line.\u003C/li>\n\u003Cli>Q324 2026-10-30 C362 Which documents field does this row mean? C305 removed the yarn-in's uploads section (OCR doc / saved document / dictation), so the form now carries only the GP photo row and the OCR read card.\u003C/li>\n\u003Cli>A324 2026-10-30 The gatepass's documents on /gatepasses/new?kind=YARN_IN: one field listing what was uploaded or read (GP photo, OCR read, added papers) each with a download, and taking new files — several at once. The uploads are the gatepass's papers, not a separate screen.\u003C/li>\n\u003Cli>Q325 2026-10-30 C362 Where do several documents live when there is no documents column — a new column/table, or the existing append-only creation event?\u003C/li>\n\u003Cli>A325 2026-10-30 The creation event's payload, one saved name per line (max 10) — no migration, nothing committed is ever rewritten, and removing the field later drops the values with it.\u003C/li>\n\u003Cli>A315 2026-10-30 yes, re-run\u003C/li>\n\u003Cli>A321 2026-10-30 yes, re-run\u003C/li>\n\u003Cli>A316 2026-10-30 yes, re-run\u003C/li>\n\u003Cli>Q326 2026-10-30 C357 the opening paste takes the type as the cutover sheet wrote it ('ccw'), while the pool key keeps the master's spelling ('CCW') — should a paste be refused when the type is not in the yarn type master, or accepted as typed?\u003C/li>\n\u003Cli>A326 2026-10-30 Resolve the type against the yarn type master case-insensitively and store the master's spelling; refuse a line whose type is not in the master, naming its line. Reason: the pool key is count|type|grade, so a stray 'ccw' beside 'CCW' would open a second bucket and the cutover stock would be invisible to the WAC — exactly the failure the row exists to prevent. It is the same rule the fabric quality already follows on this screen, and it is reversible (a new type is added in the masters first).\u003C/li>\n\u003Cli>Q327 2026-10-30 C363 Does the verify pane's zoom cap stay at 4x now that zoom works past 100%?\u003C/li>\n\u003Cli>A327 2026-10-30 Keep 4x. The wall at 100% was a CSS clamp, not the cap; 400% of a phone-wide pane already reads a gatepass line, and the cap is one constant if the guard needs more.\u003C/li>\n\u003Cli>Q328 2026-10-30 C366 Should the existing order.picks/jobRate be stored as a po_segment row, or read as a synthetic default segment?\u003C/li>\n\u003Cli>Q329 2026-10-30 C366 Does an in-house segment carry any vendor bill party?\u003C/li>\n\u003Cli>A328 2026-10-30 Keep order.picks and jobRate as a synthetic default segment (seq 1) read from the order, never copied into po_segment: existing POs need no backfill, no migration row is lost if the order is re-planned, and only genuinely added segments are stored. Added segments start at seq 2.\u003C/li>\n\u003Cli>A329 2026-10-30 No vendor bill: the in-house leg is provisional with billPartyId null and a reason naming the internal rate; out-house legs carry the weaver as billPartyId.\u003C/li>\n\u003Cli>Q330 2026-10-30 C364 Which split fixes the per-order earmark: the booking's own bags split (C195 orderSplit) or the receipt's box split across orders (C309 allocation)?\u003C/li>\n\u003Cli>A330 2026-10-30 The booking's own bags split wins (the split is fixed at booking, ARCHITECTURE 9.3); the receipt's order-tagged boxes are the fallback when the booking carries no split, and the single carried order is the last fallback. Proportional to the received kg, so the tags can never exceed it.\u003C/li>\n\u003Cli>Q331 2026-10-30 C364 How does the stock report treat a pre-C364 tagged issue that has no earmark to draw (a negative per-order ledger), and over-drawn WIP?\u003C/li>\n\u003Cli>A331 2026-10-30 A negative ledger is folded back into free kg (and its value), so free + earmarked = total always equals the physical stock; WIP stays the earmarked kg already issued to a live order, shown beside the balance, exactly the old column's meaning.\u003C/li>\n\u003Cli>Q332 2026-10-30 C367 A lot's yarn share: yarn is earmarked on the PO with no segment tag — how is it split across lots?\u003C/li>\n\u003Cli>Q333 2026-10-30 C367 When a PO has several lots, how is the SO assignment split and how do pre-C367 lots (no pick/segment) complete?\u003C/li>\n\u003Cli>A332 2026-10-30 Pro rata by the lot's delivered mtrs over the PO's delivered mtrs — the earmark carries no segment tag, and a new tag column would be a schema change the row did not ask for; reversible, fewest files.\u003C/li>\n\u003Cli>A333 2026-10-30 Assign pro rata by each lot's sellable mtrs, each apportionment at that lot's own unit cost; a pre-C367 lot with no pick/segment falls back to the old single PO pool row so old orders still complete.\u003C/li>\n\u003Cli>Q334 2026-10-30 C365 The booking picker only offers open SO / JW orders, so which target carries the yarn earmark leg — any order the booking is against, or only a production order?\u003C/li>\n\u003Cli>A334 2026-10-30 Only a production order (role 'po' or type PROD) carries the yarn bucket. An SO / JW target keeps its own cost basis (orderCost, recordCostBasis) as today — a JW order is customer yarn and never takes a cost leg, an SO's yarn cost stays on its locked basis; the PO is priced when procurement earmarks a booking to it from the PO record.\u003C/li>\n\u003Cli>Q335 2026-10-30 C365 The Against split posts bags per order (C195, parts must add to the total bags). Should the earmark add a kg input per order, or derive the kg from bags x bag weight?\u003C/li>\n\u003Cli>A335 2026-10-30 Keep the split in bags (one owner per number, the existing C195 rule that the parts add to the total bags stays true) and derive the earmark kg = part bags x bag weight on the server, so the earmark always adds back to the booking's net kg.\u003C/li>\n\u003Cli>Q336 2026-10-30 C365 Does a free-stock draw also move the physical kg (a pool out entry), or write the cost leg only?\u003C/li>\n\u003Cli>A336 2026-10-30 The draw writes the cost leg only, at the free WAC that moment; the physical kg still leave on the gatepass / weft issue, which moves quantity and prices nothing (one writer per book). This is reversible: the leg is append-only and a draw never re-prices an earlier one.\u003C/li>\n\u003Cli>Q337 2026-10-30 C368 On a fabric-in lot the rolls carry no beam, so which traceability does the checking screen accept for a lot roll — the beam, or the lot?\u003C/li>\n\u003Cli>A337 2026-10-30 The lot is the traceability: a roll that came in on a fabric-in lot (fabric_in_id set) grades with no beam, and keeps its WIP location; a roll off a loom still needs its beam.\u003C/li>\n\u003Cli>Q338 2026-10-30 C368 Does the checked-mtrs figure on the grading record count the lot's still-WIP rolls, which have not been checked yet?\u003C/li>\n\u003Cli>A338 2026-10-30 Only graded (non-WIP) rolls count as checked, plus the roll being saved; a WIP roll has not been checked yet, so the figure is the checked metres of the lot at that moment — X rolls included.\u003C/li>\n\u003Cli>Q339 2026-10-30 C369 A beam row carries no tippan link, so what proves the sizing bill the row refuses to transfer without?\u003C/li>\n\u003Cli>A339 2026-10-30 The transferring PO's own sizing cost leg (kind sizing, any status) is the bill: a beam whose PO carries no sizing leg has no carried cost to compare a market value against, and the transfer is refused with that reason. Reversible: the leg is the costing record, not a new field.\u003C/li>\n\u003Cli>Q340 2026-10-30 C369 The existing C6b form can transfer a beam to the SAME contract (a sizer-to-sizer intimation). Should that path now demand the three typed market rates too?\u003C/li>\n\u003Cli>A340 2026-10-30 No. A same-contract move stays the C6b intimation it is today: no cost legs, no rates, no sizing-bill gate. The typed market value applies only when the receiving contract differs — the row's PO-to-PO move. Existing behaviour kept, no new required fields on the old path.\u003C/li>\n\u003Cli>Q341 2026-10-30 C369 The row names 'that day rate sheet for warping', but the rate board (rate_sheet/rate) carries yarn ₹/kg only. Where does the warping hint come from?\u003C/li>\n\u003Cli>A341 2026-10-30 The latest warping cost leg on a live PO (₹/kg, amount ÷ kg) is the day's warping market; the rate board supplies the yarn hint (latest row for the beam's count + type) and the yarn master the sizing hint (siz_rate). All three are labelled with their source beside the field and the typed figures are stored as the authority.\u003C/li>\n\u003Cli>Q342 2026-10-30 C370 There is no in-place quote edit in this app (Reuse and Re-quote both save a NEW quote) — where must the 'quote cannot be revised after the SO exists' refusal live?\u003C/li>\n\u003Cli>A342 2026-10-30 Keep the freeze where a second SO would re-link the same quote: the order action refuses a quoteId a live (non-cancelled) SO already carries, with quoteRevisionError naming the SO. In-place quote edits do not exist, so nothing else needs a guard — Reuse/Re-quote already save a new quote. Fewest files, reversible, no new surface.\u003C/li>\n\u003Cli>Q343 2026-10-30 C370 Where does the budget snapshot live — a new po_budget table/migration, or the existing po:planned event payload?\u003C/li>\n\u003Cli>A343 2026-10-30 Snapshot into the existing po:planned event payload (soOrderId already lives there, it is the PO birth record and append-only) rather than a new table: no migration, no schema drift, and a later quote edit can never move a budget already taken. poRecord reads the same payload back; old POs simply have no budget.\u003C/li>\n\u003Cli>Q344 2026-10-30 C371 Where do the apportionment row's committed leg rates live — a new column on cost_apportionment, or read from the delivering PO's own cost legs?\u003C/li>\n\u003Cli>A344 2026-10-30 Read live from the delivering PO's cost_leg rows plus its own ₹/pick (order.jobRate) — no schema change, no migration. A later bill then moves the PO's own cost and lands as a variance on that PO instead of re-pricing the sale that is already locked, which is exactly 9.5.\u003C/li>\n\u003Cli>Q345 2026-10-30 C371 When a delivering PO has several fabric-in lots at different picks, which pick prices the sale's weaving leg?\u003C/li>\n\u003Cli>A345 2026-10-30 The fabric-in lots' own picks weighted by their metres (the fabric actually delivered), falling back to the order's planned pick and then to the line's stored pick. One rate per line keeps the reading explainable; a per-lot split waits for a row that needs it.\u003C/li>\n\u003Cli>Q346 2026-10-30 C372 A cancelled PO's cost legs — should the provisional yarn leg (and any provisional sizing/weaving commitment) be reversed or zeroed so the cancelled order carries no cost, or do the legs stay as posted?\u003C/li>\n\u003Cli>Q347 2026-10-30 C372 What does the cancellation's conversionAccrued figure report — nothing at all (as today), or the cost already posted as actual against the order (a beam transfer variance, a bill), with provisional commitments excluded?\u003C/li>\n\u003Cli>A346 2026-10-30 The legs stay exactly as posted: cancelling adds the pool pair and the status change only, never an edit or a reversal of a committed leg (append-only). Reversing the yarn earmark is a separate correction if the owner wants it, so the safe 80/20 is to leave cost legs untouched.\u003C/li>\n\u003Cli>A347 2026-10-30 conversionAccrued reports the cost already posted as actual against the order (a beam transfer variance leg, a bill), yarn excluded because the yarn goes back to free stock at its own cost; a provisional leg is a commitment that never started and is not charged. This is the existing event field, now filled from the order's own legs instead of a hardcoded 0.\u003C/li>\n\u003Cli>Q348 2026-10-30 C373 An allocation cannot exceed the PO open committed leg — does that forbid recording a vendor invoice higher than the commitment (a rate-hike bill, today a rate variance)?\u003C/li>\n\u003Cli>A348 2026-10-30 Literal: a share may not exceed the leg's open committed amount. An invoice above the commitment is committed first (supplementary leg / amendment) and billed after; the bill screen never raises a commitment silently. Append-only has no in-place raise, and the row states the cap.\u003C/li>\n\u003Cli>Q349 2026-10-30 C373 Paste-a-bill-list has no way to name orders — does the bulk import keep auto-spreading, or must each pasted line carry its shares?\u003C/li>\n\u003Cli>A349 2026-10-30 Each pasted line carries its own shares after the (optional) quantity: 'M-1042, 2026-10-01, Sizing Mills, sizing, 50000, 5, 300, PO-1:30000, PO-2:20000'. A line with no share is reported and skipped, never spread — one manual rule for every entry path.\u003C/li>\n\u003Cli>Q350 2026-10-30 C373 Is an allocation keyed by PO (one row per order, summed over its open legs of the kind) or by the open committed leg (two rows for a PO carrying two legs of one kind)?\u003C/li>\n\u003Cli>A350 2026-10-30 Keyed by the open committed leg, which is the row's own wording: each leg row shows its PO, open quantity and committed ₹, and a PO carrying two open legs of one kind is two commitments and gets two inputs. Amounts are then exact per leg with no hidden split.\u003C/li>\n\u003Cli>Q351 2026-10-30 C373 Acceptance says the unallocated bill is refused by the action — is a test through recordBill (which the action calls) enough, or does the test have to drive the route action itself?\u003C/li>\n\u003Cli>A351 2026-10-30 recordBill is the refusal: actions.create only forwards its error to fail(400). A route-level test would need a better-auth session for zero extra coverage, so the test drives recordBill — the same code the action calls — and reads the leg table back.\u003C/li>\n\u003Cli>Q352 2026-10-30 C374 D18 named no enum values: which delivery terms and which letter for 'inside the rate'?\u003C/li>\n\u003Cli>A352 2026-10-30 Four standard terms — ex-mill (buyer collects), FOB, CIF (freight + insurance inside), DDP (delivered, duty paid) — and two recoveries, on-top (excluded, buyer bears, the default) and in-rate (inside the quoted rate). Slugs stored as-is so both surfaces and the SO print the same list.\u003C/li>\n\u003Cli>Q353 2026-10-30 C374 Does a quote-carried SO still demand brokerage/pass-on from sales when the quote carries none?\u003C/li>\n\u003Cli>A353 2026-10-30 No — a quote settles them, so the quote-carried SO skips their requiredness and takes the quote's value (blank stays blank; the SO never invents a commercial term). Non-quote orders keep the existing required pair and the direct 1%/1% convention.\u003C/li>\n\u003Cli>Q354 2026-10-30 C379 C378 (tolerance % field on the SO form) is still pending, but this row needs the band now — where does the tolerance live?\u003C/li>\n\u003Cli>A354 2026-10-30 Add the column now as order.tolerance_pct (one additive migration, blank reads 5%) so the band can be enforced this row; C378 then only adds the form field, its validation (soTolerancePctError, 0-20%) and the two delivery dates — no rename, no second migration for the tolerance.\u003C/li>\n\u003Cli>Q355 2026-10-30 C376 Should the 'days open' column measure from quote creation (used here) or from the quote's last follow-up?\u003C/li>\n\u003Cli>A355 2026-10-30 Days open = whole days since the quote was created (created_at): it is the quote's age on the board, already stored, and needs no new column. Additive reading added to the shared order load.\u003C/li>\n\u003Cli>Q356 2026-10-30 C380 When a dispatch leaves less covered than apportioned, is the excess measured against the apportioned metres or against the ordered quantity?\u003C/li>\n\u003Cli>A356 2026-10-30 Against the apportioned metres: released = apportioned - dispatched, at each line's locked cost. Measuring against the ordered quantity would now over-release up to the band's width, because cover may sit below the quantity and still be complete.\u003C/li>\n\u003Cli>Q357 2026-10-30 C377 D25 replaces the SO wizard with four focus steps but the sale also needs a cost cover plan (C346) and payment terms — does the sale keep a slip-OCR step, and where do cover/payment live now?\u003C/li>\n\u003Cli>A357 2026-10-30 Four focus steps exactly (D25): the SO asks quantity, rate, tolerance, remark and nothing else. The quote is the SO's only source (D24/C375), so the slip-OCR/lead-link steps retire for the sale; D28's buyer-order image returns with C387. The cost cover plan (C346) is not one field, so it moves out of the wizard into its own card on the SO screen — nothing is lost. Payment terms are not on the quote, so the pinned strip's payment cell opens the existing dhara/slab pickers.\u003C/li>\n\u003Cli>Q358 2026-10-30 C383 D9 stores cd_pct + payment_days at booking, but the pending-ops flag's payment leg was due_days (a delivery deadline, D13). Should the flag read the stored payment pair instead of due_days?\u003C/li>\n\u003Cli>Q359 2026-10-30 C383 The row asks for a test, but the repo's Bun suite was removed (7668c583) and bunfig.toml still roots at the absent tests/, so no tests/ file can run. Is an action-level proof script the accepted substitute until the suite returns?\u003C/li>\n\u003Cli>A358 2026-10-30 Read the stored pair: the ops-pending payment leg is isNull(cdPct) OR isNull(paymentDays), never due_days (a delivery deadline, D13). Stored by booking from the slab; the /orders filter now delegates to the one condition.\u003C/li>\n\u003Cli>A359 2026-10-30 Yes: the action-level proof script is the substitute. The suite was deleted upstream and its bunfig root is gone, so a tests/ file cannot run; re-adding the suite is its own row.\u003C/li>\n\u003Cli>Q360 2026-10-30 C387 Which field carries the planning card's consignee before C381 links it to the party master?\u003C/li>\n\u003Cli>A360 2026-10-30 The existing dispatch_city field carries it on the planning card (free city/depot text, blank = decide at fulfilment); C381 replaces it with the Others party link, so nothing new is added now.\u003C/li>\n\u003Cli>Q361 2026-10-30 C378 Does the record's ops completion ask the two delivery dates instead of the day counts?\u003C/li>\n\u003Cli>A361 2026-10-30 No — retire the two day counts from the completion and show the booking window read-only. The SO form is where sales sets the promise; a completion that re-asks it would be a second source of truth (D13). A wrong window is corrected through the existing append-only amend path, not by a second entry.\u003C/li>\n\u003Cli>Q362 2026-10-30 C389 Does the Reports order-profitability table keep a row per PROD (production) order now that it reads the sale-order cost engine, and is salvage rolled into its margin?\u003C/li>\n\u003Cli>A362 2026-10-30 The table is sale-order profitability: rows are live SOs only, a PROD order is a production P&L (poPnl) not a sale, and its qty x rate is not revenue. Salvage stays out of this report's margin for now: the row asks for cost legs and apportionments, and rolling a damaged child sale in would double-count that child's own revenue row.\u003C/li>\n\u003Cli>Q363 2026-10-30 C381 How is the explicit decide-at-fulfilment state stored, and who may be a consignee?\u003C/li>\n\u003Cli>A363 2026-10-30 One nullable consignee party link is the whole fact: a blank link IS decide-at-fulfilment (derived, printed on every surface) so no state flag can drift; receiving categories are Others (added) plus Godown and Transport, D7's depot/godown/hub, active parties only; a consignee named at booking is fixed for planning and dispatch, corrections go through the append-only amend path.\u003C/li>\n\u003Cli>Q364 2026-10-31 C384 D10/D15 as rules: does the 1,000 m quantity step also bind a damaged (X) sale cut from a parent order, and where does the duplicate-buyer-PO check run (the form carries no list of other orders' PO numbers)?\u003C/li>\n\u003Cli>A364 2026-10-31 A damaged (X) sale is exempt from the 1,000 m step — it is cut from a parent sale's stock and its metres are whatever the cut is (the same reading C375 uses to exempt it from the compulsory quote, D21). The duplicate buyer PO is checked server-side at save (create action, plus the record's planning card where the buyer and its PO are filled together), compared case- and space-insensitively with a cancelled order releasing its number; the error already renders on both faces of the form.\u003C/li>\n\u003Cli>Q365 2026-10-31 C384 Does the 1,000 m quantity step and the 1-200 picks range also gate the record page's ops completion (validateOpsFields), or only the new-order form?\u003C/li>\n\u003Cli>A365 2026-10-31 Only the new-order form. The record's ops completion keeps its legacy leniency (a stated rate above zero, picks a whole positive number) so an order booked before the rule can still be completed; the booking is where D10/D15 bite, and a wrong stored value is corrected through the append-only amend path.\u003C/li>\n\u003Cli>Q366 2026-10-31 C381 row-watch: 2 integrations of C381 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q367 2026-10-31 C384 row-watch: 2 integrations of C384 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>A366 2026-10-31 Re rub\u003C/li>\n\u003Cli>A367 2026-10-31 Re run\u003C/li>\n\u003Cli>Q368 2026-10-31 C392 Does the ops completion drop the send-to city on job-work / outsource / stock orders too, where there is no planning card at all?\u003C/li>\n\u003Cli>A368 2026-10-31 Keep the city on the ops card for non-SO orders: D7's consignee and the planning card are sale-order only, so a job-work/outsource/stock order would otherwise have no surface that sets its send-to city at all. On a sale the city is planning's alone and the card shows the consignee instead.\u003C/li>\n\u003Cli>Q369 2026-11-02 C386 What counts as the sales stage's pending work, and does the Orders list need its own planning-pending chip?\u003C/li>\n\u003Cli>A369 2026-11-02 Keep the existing queue reading: the sales board is SOs still awaiting owner approval (D23 means an ordinary booked SO never sits there), and the Orders list keeps its plain status filter — the stage boards are the work surface (fewest files, reversible).\u003C/li>\n\u003Cli>Q370 2026-11-02 C395 Does the SO screen still open a blank form from ?new=1 / a capture draft / a bare lead or party carry, and where does the payment term come from once the six fields no longer ask it?\u003C/li>\n\u003Cli>A370 2026-11-02 A normal SO must start from a quote (D23/D24), so the pending-quotes table is the only way in: ?new=1, a capture draft, a lead or a bare party/rate/design/qty carry no longer opens a blank six-field form (a draft still restores once its quote is picked). The payment term is a read-only quote fact: the load hands its dhara id + slab to the form from the quote's own costing snapshot, and a quote with no dhara books none (sales-role bookings then see the route's own payment field error, never an invented term).\u003C/li>\n\u003Cli>Q371 2026-11-02 C396 row-watch: 2 integrations of C396 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q372 2026-11-02 C397 The row says the form's four fields, but the SO contract (D29/D30) now has six (qty, deliveryStart, deliveryEnd, rate, tolerancePct, remark) — and which screen is 'the quote table'?\u003C/li>\n\u003Cli>A372 2026-11-02 Use the contract's own field list and order (six fields after C395's D29/D30 six-field form); the row's 'four' is pre-C395 wording. 'The quote table' is the pending-quotes table the form route renders without a quoteId — the same screen C395's acceptance calls the table screen — so the quote-no column and the 356 px rule are asserted there.\u003C/li>\n\u003Cli>Q373 2026-11-02 C397 row-watch: 2 integrations of C397 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q374 2026-11-02 C398 Scope: the row names the quote screen and the SO focus layer; does 'no popup defines its own width' also cover the damaged (X) sale card, the shared SavedPopup, QuotePreview and the booking/production wizards?\u003C/li>\n\u003Cli>A374 2026-11-02 No — only the quote screen's popups (NewWizard, TermsPopup, DharaPopup, YarnPopup, AdjustPopup, QualityPopup, NewSavedPopup) and the sale form's own (wizard, payment dhara, payment slab, single-field popup). The damaged X card is a six-fact form from C390, and SavedPopup/QuotePreview/booking/production belong to other screens the row does not name; converting them adds files without changing either named screen. Reversible: the spec is one file, so a later row converts them by swapping the frame for FocusLayer.\u003C/li>\n\u003Cli>Q375 2026-11-02 C398 row-watch: 2 integrations of C398 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q376 2026-11-02 C399 row-watch: 2 integrations of C399 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q377 2026-11-02 C400 row-watch: 2 integrations of C400 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q378 2026-11-02 C401 What is a 'block' for the one-row-per-screen rule — the rows the line works in one pass, or the whole open board?\u003C/li>\n\u003Cli>A378 2026-11-02 The open board: the line is serial and works top-to-bottom, so an earlier open row owns the screen and a later pending row on the same component is held until it closes. Reversible, no status invented.\u003C/li>\n\u003Cli>Q379 2026-11-02 C401 row-watch: 2 integrations of C401 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>Q380 2026-11-02 C402 A form-block row queued before this rule carries no contract reference in the owner's text (docs/CORRECTIONS.md is not ours to rewrite): may the pre-check note carry the reference, or must such a row be parked until the owner re-texts it?\u003C/li>\n\u003Cli>A380 2026-11-02 The note may carry it: refuse only when no docs/contracts/*.json is named in the row text, targets, acceptance or the check's note, and refuse again when the named file is not on disk — so a legacy row is recorded against a real, owner-approved contract instead of parked, and the gate still cannot be satisfied by prose alone.\u003C/li>\n\u003Cli>Q381 2026-11-02 C402 row-watch: 2 integrations of C402 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>R371 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>R373 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>R375 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>R376 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>R377 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>R379 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>R381 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>Q382 2026-11-03 C396 row-watch: 3 integrations of C396 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>R382 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>Q383 2026-11-03 C400 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C400?\u003C/li>\n\u003Cli>R383 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q384 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?\u003C/li>\n\u003Cli>Q385 2026-11-03 C400 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C400?\u003C/li>\n\u003Cli>R384 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>R385 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q386 2026-11-03 C400 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C400?\u003C/li>\n\u003Cli>R386 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q387 2026-11-03 C400 Which file is 'the SO contract test' that must use assertAbsent?\u003C/li>\n\u003Cli>A387 2026-11-03 Both files that assert over the SO contract: orderLogic.test.ts (the screen's spec) already uses it, and src/lib/contracts.test.ts (the contract itself) now imports and calls it directly - no third checker.\u003C/li>\n\u003Cli>Q388 2026-11-03 C397 row-watch: 2 integrations of C397 failed in a row (deploy/commit error — see screenshots/row-watch.log). Re-run this row once the cause is fixed?\u003C/li>\n\u003Cli>R388 2026-11-03 auto (Pareto): yes — re-run the row unchanged: the failure was the integration (deploy/commit), not the row's work, so the safe reading is another attempt\u003C/li>\n\u003Cli>Q389 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?\u003C/li>\n\u003Cli>R389 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q390 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?\u003C/li>\n\u003Cli>R390 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q391 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?\u003C/li>\n\u003Cli>Q392 2026-11-03 C396 row-watch: 3 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?\u003C/li>\n\u003Cli>Q393 2026-11-03 C396 row-watch: 4 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?\u003C/li>\n\u003Cli>R391 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>R392 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>R393 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q394 2026-11-03 C401 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C401?\u003C/li>\n\u003Cli>R394 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q395 2026-11-03 C402 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C402?\u003C/li>\n\u003Cli>R395 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q396 2026-11-03 C396 row-watch: 2 row session(s) in a row never ran (last rc=1 — see screenshots/row-watch.log). Fix the cause, then release C396?\u003C/li>\n\u003Cli>R396 2026-11-03 auto (Pareto): do the row exactly as written; anything it does not name keeps its current behaviour\u003C/li>\n\u003Cli>Q397 2026-11-04 C404 does the suggestion portion also need to close on blur, and should tolerance/remark get the same treatment?\u003C/li>\n\u003Cli>A397 2026-11-04 close on a suggestion tap or its own Close, never on blur - blur fires before a chip tap on a phone, and the row names only rate and quantity, so tolerance and remark keep the inline chips they already show\u003C/li>\n\u003Cli>Q398 2026-11-04 C408 is the wanted popup the app-wide toast, and does it replace the inline banner or sit beside it?\u003C/li>\n\u003Cli>A398 2026-11-04 the app-wide toast, the notify store rendered by Toasts in the root layout (C25 precedent), and it replaces the inline banner - one confirmation, not two\u003C/li>\n\u003C/ul>\n"},uses:{params:["slug"]}}], form: null, error: null }); }); } </script> </div> </body> </html>