CORRECTIONS.md — pending corrections shelf (owner-driven)
FILE OWNERSHIP — READ FIRST: this file is written ONLY by the docs session (owner's dictation). The worker session MUST NEVER edit this file — not even the Status column. To claim or close a row, the worker APPENDS one line to docs/CORRECTIONS-LOG.md (its own file). One writer per file = overwrites are impossible. (Lost-entry incident 2026-09-10: worker full-file rewrites wiped C22–C24 — hence this rule.)
The owner keeps supplying corrections; every correction is entered here first, then applied to the named document, then ticked off. Nothing on this shelf goes stale silently — each turn that supplies or applies a correction updates this file in the same commit.
Protocol: owner states corrections → docs session BREAKS DOWN every
message into one row per form (never one lumped row) → worker reads the
Pending table and applies rows → worker appends doing/done lines to
CORRECTIONS-LOG.md → docs session folds those lines into this sheet
(Status updates + Applied moves). Each turn updates this file in the
same commit.
Continuous-worker protocol (for the other session)
- Keep referring to the Pending table below and keep correcting the points CONTINUOUSLY, without stopping for the owner's prompt.
- Corrections that touch different forms/routes (no shared files) → run CONCURRENTLY via multiple agents, one agent per form (narrow brief, owned files only).
- Corrections where files overlap (shared component, schema, engine, stylesheet) → run SEQUENTIALLY, one after the other, to avoid clobbering.
- NEVER edit this file. Claim/close rows by APPENDING lines to
docs/CORRECTIONS-LOG.md, one line per status change:
C<n> doing <date> <note>when starting,C<n> done <date> <commit> <note>when deployed. Append-only — never edit or delete existing log lines (concurrent appends are safe; full-file rewrites are what caused the wipe). Never leave a claimed row hanging.
Pending
(live shelf — today's corrections only. Pre-2026-09-22 points C1–C61 were deleted from this file by owner request; the full history is in git.)
| # | Date | Form / Target doc + section | Correction (as told) | Status |
|---|---|---|---|---|
| C131 | 2026-10-13 | https://trading.tynolabs.com/masters | Party master (masters/parties): the broker name field is not needed - remove it from the party form. | pending |
| C132 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | remove opening balance field | pending |
| C133 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | remove due days field | pending |
| C134 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | for mobile number and email id put relevant validation rules | pending |
| C135 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | add "Godown" in Category | pending |
| C136 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | Add country code selection list to mobile number | pending |
| C137 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | remove phone number field | pending |
| C138 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | add field "MSME (Udyam Aadhar)"number | pending |
| C139 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | remove the old unit toggle | pending |
| C140 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | put relevant field validation rules for PAN card and GSTIN | pending |
| C141 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | remove amend button after edit. Cancel and save should appear side by side. correction remark field should appear alongside other fields | pending |
| C142 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | REMOVE SUGGEST BUTTON IN ACRONYM | pending |
| C143 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | remove the whole rates and rolls section from the design master | pending |
| C144 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | weft wastage as 5% prefilled by default in any new record | pending |
| C145 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | warp and weft need a grid (due to multiple warp and weft if there in a quality). Columns: 1. Sr No. 2. Count 3. Unit 4. % 5. Permissible counts (multiple selection of permissible counts for e.g. 61 count inward is permissible against quality of 60 count). ask questions if the query is not clear | pending |
| C146 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | remove Warp rows — multi-warp (JSON, optional) and Weft rows — multi-weft (JSON, optional) fields | pending |
| C147 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | quality name and alias at the top. quality name to be derived from all other fields. Not manual | pending |
| C148 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | remove PPI field. In the quality name in place of pick write only "Pick" | pending |
| C149 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | remove GSM Target and UTL | pending |
| C150 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=payment-terms | instead of "Denting (ends per dent) — EPI = reed × denting ÷ 2" write only "Denting (ends per dent) — EPI = reed × denting ÷ 2" | pending |
| C151 | 2026-10-13 | https://trading.tynolabs.com/tippans/new | Remove yarn counts section since we have already made grid | pending |
| C152 | 2026-10-13 | https://trading.tynolabs.com/tippans/new | In the warp and weft grid, count comes from yarn master so drop down, percentage cannot be seen as typed the field is small (total of % to be 100%), auto divide 100% and prefill when a new row is added for e.g. for 2 warp rows the prefilled percentage is 50% for each, permissible count from yarn master to be shown as coin tags in the field as many selected. | pending |
| C153 | 2026-10-13 | https://trading.tynolabs.com/tippans/new | Remove (104) in the label of L2L | pending |
| C154 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | Remove shifts field | pending |
| C155 | 2026-10-13 | https://trading.tynolabs.com/masters?tab=party | Remove open button from the table of all masters. Clicking anywhere on the row should open the record | pending |
| C156 | 2026-10-14 | https://trading.tynolabs.com/masters | The warp and weft grid is not user friendly on phone. Revised the UI to suit a mobile screen in design master warp and weft grid | pending |
| C157 | 2026-10-14 | https://trading.tynolabs.com/masters | In the warp and weft grid permissible count drop down has to be searchable | pending |
| C158 | 2026-10-14 | https://trading.tynolabs.com/masters | Remove mode from design master | pending |
| C159 | 2026-10-15 | — | migrate to sveltekit 3 | pending |
| C160 | 2026-10-17 | https://trading.tynolabs.com/masters | in design master, weave should be selected from the drop down coming from weave master. weave master need not be shown seperately but a sub-master of design master updated from the entries made in design master. a new weave can be typed straight into the weave field and it should get added to the weave master and to be shown in the drop down from next entry. also no duplicate weaves allowed. values should be unique, not case sensitive | pending |
| C161 | 2026-10-17 | https://trading.tynolabs.com/orders/new/trading | new trading SO button showing 500 error | pending |
| C162 | 2026-10-17 | https://trading.tynolabs.com/quote | for warp and weft reed space, prefill the field by the last used RS for the quality in the quality field | pending |
| C163 | 2026-10-17 | https://trading.tynolabs.com/quote | for job work field, prefill the field by the last used job work for the quality in the quality field | pending |
| C164 | 2026-10-17 | https://trading.tynolabs.com/quote | warp sizing rate should prefill from the yarn master | pending |
| C165 | 2026-10-17 | https://trading.tynolabs.com/quote | for quality with multiple warp or weft, the second warp and weft fields are not appearing. correct that | pending |
| C166 | 2026-10-17 | https://trading.tynolabs.com/quote | remove sizing GST field | pending |
| C167 | 2026-10-17 | https://trading.tynolabs.com/tippans/new | Remove mill/ticket | pending |
| C168 | 2026-10-17 | — | Create a new master of ticket/mill..to get h tickets/mill whenever called for...the entries in this master comes from rate board. If there is a new mill in the rate board, it auto enters this master. Accordingly whenever yarn (count+type+mill/ticket) is fetched, it shows all permutations of yarn and mills | pending |
| C169 | 2026-10-17 | https://trading.tynolabs.com/tippans/new | The weave field is not showing a searchable drop down. Also weave master is not showing up in the masters | pending |
| C170 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | we must deliver in field is not opening up pop up for data entry | pending |
| C171 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | when mumbai dhara is selected brokerage is to be prefilled as 1% and for ahmedabad dhara 2% | pending |
| C172 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | brokerage should have slot scroll entry with suggestion coins of 1%, 2% | pending |
| C173 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | brokerage pass on should have suggestion coins 0.5%, 2% and should have slot scroll entry with per scroll change of 0.25% | pending |
| C174 | 2026-10-18 | https://trading.tynolabs.com/orders?operations=1 | order operations page shwing 500 | pending |
| C175 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | we must deliver in field should have start date and end date. both showing suggestions of ready (which when tapped on selects today's date, +2 days, +7days, +15days, +30 days. +40 days and +/- button to add/less one date to selected date. | pending |
| C176 | 2026-10-18 | https://trading.tynolabs.com/masters | add button in mill/ticket master | pending |
| C177 | 2026-10-18 | https://trading.tynolabs.com/masters | add button in weave master | pending |
| C178 | 2026-10-18 | https://trading.tynolabs.com/orders?type=SO | ANY ITEM IN THE TABLE LEADS TO ERROR 500 | pending |
| C179 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | Re-merge the order-operations fields into the Trading SO form: the sales person may NON-COMPULSORILY fill the production/operations fields if he already has the data (including when he uses OCR of the contract copy). Anything he leaves blank is completed later by another (operations) user, append-only, from the operations queue — one field spec, stage-aware requiredness. | pending |
| C180 | 2026-10-18 | https://trading.tynolabs.com/orders/new/job-work | Re-merge the order-operations fields into the Job Work SO form: the sales person may NON-COMPULSORILY fill the production/operations fields if he already has the data (including when he uses OCR of the contract copy). Anything he leaves blank is completed later by another (operations) user, append-only, from the operations queue — one field spec, stage-aware requiredness. | pending |
| C181 | 2026-10-18 | https://trading.tynolabs.com/orders/new/production-order | Re-merge the order-operations fields into the Stock (Production) order form: the sales person may NON-COMPULSORILY fill the production/operations fields if he already has the data (including when he uses OCR of the contract copy). Anything he leaves blank is completed later by another (operations) user, append-only, from the operations queue — one field spec, stage-aware requiredness. | pending |
| C182 | 2026-10-18 | https://trading.tynolabs.com/orders/new/job-work | IN NEW JOB WORK ORDER ASK LOOM WIDTH AND PANNA FIRST IN THE WIZARD AND THE FORM | pending |
| C183 | 2026-10-18 | https://trading.tynolabs.com/quote/new | PAYMENT DHARA PREFILL FROM THE LAST USED OF THE PARTY. iF NONE, THEN ASK PAYMENT DHARA IN THE WIZRAD. OTHERIWSE PREFILL AND DO NOT ASK | pending |
| C184 | 2026-10-18 | https://trading.tynolabs.com/quote/new | PAYMENT DHARA FIELD KEEP IN THE END | pending |
| C185 | 2026-10-18 | https://trading.tynolabs.com/quote/new | WARP AND WEFT COST AND WEIGHT IN THE SECOND PAGE OF COSTING FORM SHOULD BE SHOWN FOR EACH WARP AND WEFT INCASE THERE ARE MULTIPLE | pending |
| C186 | 2026-10-18 | https://trading.tynolabs.com/quote/new | SHOW SCROLL ENTRY FOR ESTIMATED MTR WITH EACH STEP AS 1000 MTR AND SHOW SUGGESTION COINTS FROM PREVIOUS SALE ORDERS OF THE SAME QUALITY | pending |
| C187 | 2026-10-18 | https://trading.tynolabs.com/quote/new | DELIVERY END SHOW SUGGESTION COINS OF +10 DAYS, +20 DAYS, +30 DAYS, +40 DAYS, + | pending |
| C188 | 2026-10-18 | https://trading.tynolabs.com/orders | Orders list shows test-fixture order numbers like SO-C135-1791194656869 and SO-C111-1791195431185. These are leftover fixture rows the removed test suite inserted directly into the shared data.db (tests/c111, c135, c154 built orderNo as SO-C |
pending |
| C189 | 2026-10-18 | — | use official deepseek v4.1 flash for any llm (both text and vision) related stuff inside trading.tynolabs.com use the following api key sk-e59ab23552c44f4a8e0a9f875500314a | pending |
| C190 | 2026-10-18 | https://trading.tynolabs.com/samples | IN SAMPLE FORM RATE IS A SINGLE SCROLL WITH 0.25 INCREMENTS, NOT DUAL ONE FOR RUPEES AND ONE FOR DECIMAL. ALSO SHOW SUGGESTION COING BASED ON LAST RATE USED FOR THE QUALITY FROM ORDERS. | pending |
| C191 | 2026-10-18 | https://trading.tynolabs.com/samples | CHARGE/WAIVE SHOULD BE EITHER OR OPTION OF A SINGLE FORM. ONLY IF CHARGE IS SELECTED, RATE SHOULD BE ASKED. THIS FIELD SHOULD BE A PART OF WIZARD BEFORE RATE | pending |
| C192 | 2026-10-18 | https://trading.tynolabs.com/samples | REMOVE PURPOSE FIELD | pending |
| C193 | 2026-10-18 | https://trading.tynolabs.com/samples | EVERY SAMPLE HAS A AUTO ENTRY NUMBER LIKE ANY OTHER FORM. THIS NEED NOT BE A FIELD AND CAN BE SHOWN AT THE TOP OF THE FORM | pending |
| C194 | 2026-10-18 | https://trading.tynolabs.com/hishob | REMOVE HISHOB AND ORDERS FROM ORDERS SECTION IN THE NAVIGATION PANE,THESE ARE REPORT | pending |
| C195 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | IN NEW BOOKING WHEN SELECTING A PRODUCTION ORDER, IT SHOULD SHOW A GRID SHOWING WARP/WEFT, YARN (cOUN+tYPE), ALREADY ASSIGNED (SHOWS THE TOTAL KGS OF YARN ALREADY ASSIGNED FOR THAT ROW - EXPANDABLE TO SEE THE DATE AND TICKET WHICH WAS PROCURED). tHE USER SHOULD ALSO BE ABLE TO SELECT MULTIPLE PRODUCTION ORDER IN WHICH CASE HOW MANY BAGS TO BE ASSIGNED TO WHICH ORDER HAS TO BE ASKED IN THE QTY FIELD | pending |
| C196 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | CONES PER BAG AND BAG WT. HAVE TO BE PREFILLED FROM LAST ENTRY OF THE SAME YARN (COUNT+TYPE+MILL) | pending |
| C197 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | RATE HAS TO BE A SINGLE SCROLL WITH INCREMENTS OF 0.25. SUGGESTION COING OF THE LAST USED FOR FOR THE YARN (COUNT+TYPE+MILL) AND ALSO THE RATE BOARD OF THAT DAY. oNCE SELECTED FROM SUGGESTIONS THE USER CAN ALSO THEN MOVE THE SCROLL TO ADJUST THE RATE. dO NOT IMMEDIATELY TAKE TO THE NEXT WIZARD BY JUST TAPPING ON A SUGGESTION. TAKE TO THE NEXT FIELD ONLY WHEN CLICKED ON NEXT IN THIS CASE | pending |
| C198 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | Reorder fields System order no., buyer order no., booking date, system date at the top System order no. And system date need not be shown as fields since they are auto Then quote/lead. Single field. Not multiple Then broker, buyer, quality and rate Then qty and delivery Then terms and papers except rate and yarn booking allocation. Then remarks. Then yarn booking allocation | pending |
| C199 | 2026-10-18 | https://trading.tynolabs.com/orders/new/job-work | Reorder fields for job work order 1. System order and system date (not shows as fields since auto) 2. Buyer order number, booking date 3. Loom width (only one field, form showing 2 fields) and no. If panna 4. Then broker, buyer, quality, picks, job rate 5. Then qty and delivery terms except city. Remove the city field 6. Then other terms Remove sales promise field, broker/weaver confirmation, | pending |
| C200 | 2026-10-18 | https://trading.tynolabs.com/orders/new/job-work | Link a capture draft field is unresponsive. Allow to upload if not already done so in ocr | pending |
| C201 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | add a field of own firm name, to be selected from own party type of party master | pending |
| C202 | 2026-10-18 | https://trading.tynolabs.com/quote | when reusing a quote, the calculate button does not get active | pending |
| C203 | 2026-10-18 | https://trading.tynolabs.com/quote | L2L should be prefilled from the last used for the same quality. Suggestion coing should show the last actual L2L for the order of that quality which was finished | pending |
| C204 | 2026-10-18 | https://trading.tynolabs.com/quote | job rate should be fetched from the last job rate for teh same quality in the job work order/outsourced job work contract or last quote. suggestion coings should have that. In case there is nothing to pre-ill show the field in the wizard. same for L2L, in case there is nothing to pre-fill, show the field inthe wizard. | pending |
| C205 | 2026-10-18 | https://trading.tynolabs.com/orders | Order approval status is unfinished. C111 writes pending_approval / approved into the same order.status column as open/in-prod/delivered/closed, so (a) no screen lists pending orders for the owner to approve and (b) every downstream picker that filters status = 'open' (bookings, tippans, beams, planning, checking, dispatch, gatepasses, movements, lots) no longer sees newly created orders. Keep open as the workflow status and read approval from approvedBy/approvedAt (or accept approved everywhere), and give the owner a way to approve a pending order. |
pending |
| C206 | 2026-10-18 | https://trading.tynolabs.com/orders | While entering buyer name in job work order or so trading or outsourcing order if the party is not there in the master, it should show an option of creating new in the drop down itself which opens the party master pop up where the user can enter the party and close and the wizard resumes back with the newly entered party. Same for broker | pending |
| C207 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | rate should be a single croll with 0.25 increments. also suggestions from rate board or last used rate for that yarn (count+type+mill) | pending |
| C208 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | gst % not needed | pending |
| C209 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | Booking no. system generated) and system date to be shown on top, trader's booking number as the first field along with booking date | pending |
| C210 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | reorder fields 1. booking number (trader's), booking date 2. broker and trader 3. product (count+type+mill) 4. bags and cones and wt. per bag 5. Rate (along with toggle of including/excluding GS 6. lot no., payment terms, delivery period, remark chande delivery date field to delivery date with start date, interval period and no. of bags per interval | pending |
| C211 | 2026-10-18 | — | create a guard login | pending |
| C212 | 2026-10-18 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | while selecting yarn booking clicking on the field should open the table of yarn bookings with (pending status i.e. booking against which deliveries are not yet fully received) and the user can select from the table. This would be better than a drop down | pending |
| C213 | 2026-10-18 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Status if auto. A field for that is not required. It can be shown in the table and while opening an existing inward | pending |
| C214 | 2026-10-18 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | need OCR recognition field for uploading teh gatepass received. Also a upload document field where this gatepass is saved. Along with a dictation field. | pending |
| C215 | 2026-10-18 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Change the form name to Yarn Inward Intimation | pending |
| C216 | 2026-10-18 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | yarn inward intimation number and systemd ate on the top | pending |
| C217 | 2026-10-18 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | reorder 1. Booking number 2. Yarn (Count+Type+mill) prefilled from booking 3. GP No. 4. Location of pick up (from godwon master) 5. Bags to be received with suggestions based on previous bags received of the same product 6. remarks | pending |
| C218 | 2026-10-18 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | remove kind. it is a standalonw form for yarn inward | pending |
| C219 | 2026-10-18 | https://trading.tynolabs.com/samples | Waive amount not needed. Waive would mean complete waive | pending |
| C220 | 2026-10-18 | https://trading.tynolabs.com/samples | Remove rate source | pending |
| C221 | 2026-10-18 | https://trading.tynolabs.com/samples | Remove from context complete section | pending |
| C222 | 2026-10-18 | https://trading.tynolabs.com/bookings/new | In The rate scroll I am not able to type properly. The last digit doesnt get erased with backspace | pending |
| C223 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | In case broker not selected mark broker as direct while saving and prefill brokerage as 1 and pass on field as 1 | pending |
| C224 | 2026-10-18 | https://trading.tynolabs.com/quote/new?quoteId=aemxzq7f45xw | The reuse button open edit form. It should just open a new form with the fields prefilled | pending |
| C225 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | For the sales user following fields are compulsory for saving Buyer Quality Rate Picks Quantity We must delivery in days Payment dhara Cd Brokerage % Pass on % For production user the following fields are compulsory for the entry made by the sales user Buyer order no Send as Mtr per roll Rolls | pending |
| C226 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | Remove fields sales promise Send to city Move we must delivery in days at the place of sales promise | pending |
| C227 | 2026-10-18 | https://trading.tynolabs.com/orders/new/trading | Booking no. Field after ocr in wizard | pending |
| C228 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | rate scroll increments of 0.25 | pending |
| C229 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | rate field 2 decimal points | pending |
| C230 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | how many picks scroll of 1 increment. suggestions using past orders of the same quality + Party | pending |
| C231 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | lead/quote picker to be one field only. Either or. Also the picker not as a drop down but as the historic table like we did in bookings section SO selection with 2 tabs...one for lead, one for quote. Show only those leads whose quotes are not generated and have not expired. Show only those quotes whose SO is not generated and is not expired | pending |
| C232 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | remove the quote/lead picker from the OCR wizard screen and put it in the next screen. In case the OCr is provided for the SO and quote too, fields are to be prefilled from the OCr not the quote. at that time quote is just linked ot the SO. Other times quote also prefills fields | pending |
| C233 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | in brokerage use +/- button instead of scroll. With increment of 0.25 | pending |
| C234 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | pass on to buyer use +/- button with 0.25 change instead of scroll | pending |
| C235 | 2026-10-19 | https://trading.tynolabs.com/orders | Orders list: tapping a record opens the record popup, but it has no cancel action (only the full record page's Delete does). Add a Cancel button to the record popup with a cancellation-remarks field, recording the cancellation append-only via /api/amend kind 'delete' with owner approval — the order is flagged cancelled, never erased, and stays openable with its history. | pending |
| C236 | 2026-10-19 | https://trading.tynolabs.com/orders/new/production-order | Production order (Stock) staged entry between sales and production. SALES must fill (compulsory, cannot save without): booking date; quote/lead selection (if applicable); buyer; broker; quality; rate; picks; quantity; payment dhara; cash discount; we must deliver in days; brokerage; pass on. Sales may also fill the remaining fields, but those stay optional for sales. If no quote/lead was selected and the sales user has filled the fields manually, the quote/lead picker must not allow a selection (it would conflict with the manually entered values). The sales entries then appear in the production user's to-dos and production must compulsorily fill: send as; mtr./roll or lump; no. of rolls/lumps; buyer PO no. All other fields remain optional. Enforce the split server-side and client-side (same field spec, role-aware requiredness), append-only as usual. | pending |
| C237 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | show send as field options (rolls/lumps) as two radio button rather than drop down | pending |
| C238 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | change the name of rolls field to rolls/lumps | pending |
| C239 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | for "How many picks" field show suggestion coins based on last pick for the same quality | pending |
| C240 | 2026-10-19 | https://trading.tynolabs.com/orders | show party and quality alias instead of quality and party in the table | pending |
| C241 | 2026-10-19 | https://trading.tynolabs.com/orders | need booking date as first column in the table | pending |
| C242 | 2026-10-19 | https://trading.tynolabs.com/orders | progress and status have to be short in the table. very long tests lead to long horizontal scroll on phone. make those concise | pending |
| C243 | 2026-10-19 | https://trading.tynolabs.com/orders | put the open details button within the pop up and remove from the horizontal scroll | pending |
| C244 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | the quote lead picker should open the table in a pop up with two tabs for leads and quotes. also it is not showing any lead or quotein the table whereas there are many leads and quotes opne. troubvleshoot that too | pending |
| C245 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | picks field to change by 1 with +/- button. Right now it is changing by 100. Also it is not showing any suggestion coins based on previous SO of the same quality. correct that | pending |
| C246 | 2026-10-19 | https://trading.tynolabs.com/masters?tab=loom | type and class of looms are not shown as seperate masters. If they are not masters yet, make them. | pending |
| C247 | 2026-10-19 | https://trading.tynolabs.com/masters?tab=loom | create a loom type master with columns as width (190 cm, 250 cm), loom type (Airjet, Rapier) and link this master to loom master rather than individual class and type field. | pending |
| C248 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | fro panna prefill it based on last used for loom type + quality. | pending |
| C249 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | loom type field drop down take from new created loom type master | pending |
| C250 | 2026-10-19 | https://trading.tynolabs.com/orders | Orders list production-stage marking and role actions: mark every order whose production/operations details are still incomplete with a secondary status (a second status chip beside the workflow status, derived from the same pending-ops field check so nothing stored can drift). For the production role, hide the New |
pending |
| C251 | 2026-10-19 | https://trading.tynolabs.com/orders/new/trading | Order entry wizard, role-scoped fields: the sales user sees only his compulsory sales fields in the wizard and the production user only the production fields; one field spec with role-aware visibility and requiredness, enforced server-side and client-side. Covers the Trading SO, Job Work SO and Stock (Production) order new/view flows. Hidden fields keep any value already carried on the order; saving stays append-only. | pending |
| C252 | 2026-10-19 | https://trading.tynolabs.com/production/trading | Production entry wizard, role-scoped fields across all four production screens (trading, job-commercial, job-details, production-order): the production user sees only his own fields and the sales user only his; one field spec with role-aware visibility and requiredness, enforced server-side and client-side, append-only. | pending |
| C253 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | rate per meter is auto calculated in job work order and need not be in the wizard. Rate per meter = Job rate per pick*picks/100 | pending |
| C254 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | switch the positions of job rate per pick and rate per mtr in the form | pending |
| C255 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | take "Beams:Whose?" field at the end in terms | pending |
| C256 | 2026-10-19 | https://trading.tynolabs.com/orders?type=JW | show booking date, Then order no., Quality palias, Party alias, Mtr/beam, job rate, Status in this order | pending |
| C257 | 2026-10-19 | https://trading.tynolabs.com/orders?type=JW | enable chat with party and share order button in job work order | pending |
| C258 | 2026-10-19 | https://trading.tynolabs.com/orders?type=JW | remove book yarn button for job work order | pending |
| C259 | 2026-10-19 | https://trading.tynolabs.com/orders?type=JW | remove new tippan button for job work order | pending |
| C260 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | picks field give +/- button with change of 1. Show suggestions based on picks of the same quality last used | pending |
| C261 | 2026-10-19 | https://trading.tynolabs.com/orders?type=JW | Job work form is showing trading draft. Correct that | pending |
| C262 | 2026-10-19 | https://trading.tynolabs.com/orders?type=JW | job rate per pick suggestions from previous used for same quality. give +/- button with change of 0.25 | pending |
| C263 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | mtr/beam field make the active scroll as editable. Right now a seperate editable text box is shown for manual entry. correct it | pending |
| C264 | 2026-10-19 | https://trading.tynolabs.com/orders?type=OUTSOURCE | All 4 order forms should show only their draft entries respectively. not each other's | pending |
| C265 | 2026-10-19 | https://trading.tynolabs.com/orders/new?type=OUTSOURCE | remove efficiency linked rate, additional unconditional rate, weaver liability clause, delivery gatepass leg | pending |
| C266 | 2026-10-19 | https://trading.tynolabs.com/orders/new?type=OUTSOURCE | shift Beam:Whose? to the end of terms | pending |
| C267 | 2026-10-19 | https://trading.tynolabs.com/orders/new?type=OUTSOURCE | make outsourced form UI same as job work order form. Except instead of buyer's order no. it will be weaver;s order no. | pending |
| C268 | 2026-10-19 | https://trading.tynolabs.com/orders/new?type=OUTSOURCE | remove brokerage | pending |
| C269 | 2026-10-19 | https://trading.tynolabs.com/orders/new/production-order | remove buyer, rate, send to city, all terms and papers fields (except yarn allocation and remarks) | pending |
| C270 | 2026-10-19 | https://trading.tynolabs.com/orders/new/production-order | remove quote, lead, broker, buyer order no., booking date | pending |
| C271 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | remove panna from wizard | pending |
| C272 | 2026-10-19 | https://trading.tynolabs.com/masters?tab=loom | remove loom class master. only one master of loom type is enough. In loom type width (in cm) has to be typable and not drop down | pending |
| C273 | 2026-10-19 | https://trading.tynolabs.com/bookings/new | OCR and dictation field add in the wizard first pop up | pending |
| C274 | 2026-10-19 | https://trading.tynolabs.com/bookings/new | put start wizard button | pending |
| C275 | 2026-10-19 | https://trading.tynolabs.com/bookings/new | make delivery start date, delivery end date , delivery interval and bags per interval part of the same focus entry pop up . For delivery interval give suggestion coins of 3 days, 5 days, 7 days, 10 days. +/- button with change of 1 day. Total Bags divide based on no. of intervas and delivery period and let the user modify with plus or minus button with 1 bags change | pending |
| C276 | 2026-10-19 | https://trading.tynolabs.com/bookings/new | Trader/supplier from party master - type supplier. If the entered supplier is not there in the master give an option in the drop down to add new record in the party master clicking on which opens the master in a new pop up and when saved the field pop up gets populated by that value | pending |
| C277 | 2026-10-19 | https://trading.tynolabs.com/bookings/new | Add new broker option in broker drop down which opens party master in pop up. | pending |
| C278 | 2026-10-19 | https://trading.tynolabs.com/bookings/new | Add yarn option in yarn drop down. This should open yarn master in pop ups over the field pop up for new yarn creation | pending |
| C279 | 2026-10-19 | https://trading.tynolabs.com/bookings/new | Divide the yarn field into two fields 1. Yarn count and type (from yarn master) 2. Mill/ticket (from mill master. Both drop down should have an option of creation of new which opens the master for new creation right there in a new pop up | pending |
| C280 | 2026-10-19 | https://trading.tynolabs.com/orders/new?type=OUTSOURCE | Switch rate per mtr and job rate fields position in the form | pending |
| C281 | 2026-10-19 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | The table of job work and yarn booking for picking has to be shown in a seperate pop up with tabs for both. UI LIKE quote/lead picker in so form | pending |
| C282 | 2026-10-19 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Yarn inward intimation number and system date to be shown above the form. Ui like as in booking form | pending |
| C283 | 2026-10-19 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Add gp no. Field | pending |
| C284 | 2026-10-19 | https://trading.tynolabs.com/orders/new/job-work | Beam scroll start from 1. Right now it is starting from 999 | pending |
| C285 | 2026-10-19 | https://trading.tynolabs.com/orders?type=JW | The table fields are cramped. Make them visible. Horizontal scroll allowed | pending |
| C286 | 2026-10-20 | — | improve UI ergonomics | pending |
| C287 | 2026-10-20 | — | improve UI ergonomics | pending |
| C288 | 2026-10-22 | — | color code of the complete erp is not ergonomic | pending |
| C289 | 2026-10-22 | https://trading.tynolabs.com/ | we need a smartly designed scrollbar to make user instantly understand layout of dashboard https://trading.tynolabs.com/ | pending |
| C290 | 2026-10-23 | — | draggable scrollbar on phone? | pending |
| C291 | 2026-10-23 | — | current draggable scrollbar in dashboard can hardly be grabbed by a finger. visually it must be very subtle. but, it should match system's scroll | pending |
| C292 | 2026-10-25 | — | strictly use daisyUI throughout https://trading.tynolabs.com/. no other UI libraries should be used unless daisyUI can't do it | pending |
| C293 | 2026-10-25 | https://trading.tynolabs.com/ | dashboard can be card swipes left and right on phones? current look seems to be too chaotic. decide and implement the best UI for the dashboard | pending |
| C294 | 2026-10-26 | — | remove the extra scrollbar in dashboard | pending |
| C295 | 2026-10-26 | — | keep only the og scrollbar in dashboard | pending |
| C296 | 2026-10-27 | — | UI of https://github.com/skpawar1305/drnanoinc-stores/tree/main/apps/billing is so simple. UI of this website is complication. I think we need strict organizational segregation for the UI, and have minimal options in the sidebar. maintain mobile and desktop first for this website | pending |
| C297 | 2026-10-27 | — | readibility and UI ergonomics needs an udpate throughout the website, maybe use cards more so that website can be used by less literate people as well and use icons wherever it feels necessary | pending |
| C298 | 2026-10-27 | — | boost lighthouse scores | pending |
| C299 | 2026-10-27 | — | dashboard is chaotic | pending |
| C300 | 2026-10-27 | — | show wizards or wizard options only if necessary for form filling | pending |
| C301 | 2026-10-29 | https://trading.tynolabs.com/gatepasses | clcicking on new gatepass should not open a drop down of types of gatepasses. it should directly open the new record of the gatepass of which the screen is open | pending |
| C302 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Add a field of whether the yarn is a warp or a weft. This is a loose link and can change later . I.e. a warp can be used as weft or vice versa later | pending |
| C303 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | for the pop up showing selection from all the order/job work order for which yarn is pending to be received. It is to be calculated as below. Fo SO Tradin and Production Order - Use the formula used in quote form for calculating the warp weight and weft weight (for costing) and use the same formula multiplies by the order mtrs. to calculate the total kgs required for the warp and weft (in case there are multiple warp or weft each requirement to be calculated seperately as in quotes). Note in docs, the formulas for conversion of fabric mtrs to yarn kgs is standard and when called upon should be used as given there. Now the table which shows the ordders for which yarn is pending for selection for yarn inward intimation should show kgs. received till date/kgs to be received (calculated as above). ADDED 2026-10-29: for selecting reference for yarn inward it can be from 3 things. 1. SO Trading/productio order (in which case yarn requirement is calculated in the above manner) and this is for yarn that is sourced in ready delivery format. 2. Yarn booking - for yarn booked for future delivery against which delivry is received (for this total kgs. received/total kgs. booked is to be shown) 3. Job work for which weft requirement is to be calculated just like above. Right now only 2 tables for yarn booking and job work are shown correct that. | pending |
| C304 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Yarn field is to be auto fetched incase of yarn bookingss. for SO order/production order and job work it is to be filled by the user | pending |
| C305 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | "Gatepass uploads & dictation (you can skip)". Remove this section completely except a field which shows the uploaded ghatepass photo or allows upload | pending |
| C306 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | for OCR detection the wizard pop up like in the New Orders screen | pending |
| C307 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | wizard flow 1. OCR 2. Warp/weft 3. No. of bags 4. SO/Production order/Booking/Job work order selection 5. Yarn 6. Pickup Location 7. Trader's GP No. Any field automatically filled by OCR is not to be shown in wizard except 1, 2 and 4 no. points | pending |
| C308 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Give a button `on top of the screen called "Verify fields". On clicking it the gatepas uploaded is shown on the top 1/3 of the page which the user can zxoom in and out in the same freezed pane while scrolling the rest of the form verifying each field against the actual gatepass photo. Give a small cross on top to close the photo and get back to the original layout of the form | pending |
| C309 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | in the table of the SO/booking/job work/production order for selection...show only one column of kgs pending/kgs required. In case of multiple warp/weft show it count wise in the same column. Multiple selection only allowed in SO/production order (containing records of Trading orders and production orders for which yarn is pending combined) and yarn bookings. for job work only single selection is allowed. Also mutiple selection allowed from SO/Production order table and yarn booking table i.e. a few from each table. But not for job work. For job work if a job work order is selected no other yarn booking or SO order or production order can be selected with it. When multiple are selected, a live grid of order, yarn count, kgs pending and a field equally dividing the total boxes amongst all the orders (but upto a maximum of their pending requirement). with a +/- button to change the no. of boxes by 1 bag, total kgs of the boxes approtioned to the order, further pending kgs of that order/booking | pending |
| C310 | 2026-10-29 | https://trading.tynolabs.com/masters | add mill name back into the yarn master with values from the mill/ticket master | pending |
| C311 | 2026-10-29 | https://trading.tynolabs.com/masters | Add a count master. This is to be linked to the yarn master count field | pending |
| C312 | 2026-10-29 | https://trading.tynolabs.com/masters | Add a Type master. This is to be linked to the yarn master type field | pending |
| C313 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | For SO Trading/Production order/Job work order too the yarn count+type+mill have to be shown as a single field only from the yarn master, not 3 different fields. Same in the wizard | pending |
| C314 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Add fields of cones and bag weight along with no. of bags. Show this field right after the no. of bags in the wizard. show suggestions based on previous entries of the same yarn | pending |
| C315 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | The gatepass read must take the trader's printed Booking No. ("Booking No. : 1128") and PRE-SELECT that booking in the yarn-in's reference picker from the open list (yarn bookings + SO/production orders + job work, C303/C304), so trader, yarn, count, type and rate arrive from the booking instead of the reader. A number that matches nothing open shows as a chip to search with — never a guess. Nothing in the read extracts a booking number today (intake.ts, DOC_SYSTEM in captureOcr.ts, captureRouting.ts). | pending |
| C316 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Read the goods line as count + TYPE, not as a bare number: "61s Combed Compact - Classic Yarn" means count 61 and type CCW (combed compact), just as the shorthand 40 CW / 30s KW / 150 Dn reads. Karded / combed / combed compact / hank / denier words map to the type master (C312), and the resolved yarn is ONE entry from the yarn master (count + type + mill as one field, C313). The read must never require a literal "CW" on the paper — today's letters-only match finds no type here. | pending |
| C317 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Read the MILL from the mill/ticket master off the spinner line, not off an address: this paper prints "Gvg Elite Yarns And Fabrics (tex Div Of Gvg Paper Mills) Gpm" and the floor says "GVG" — that must resolve to the mill master entry (e.g. GVG Classic). Today the reader takes the word "Vishnu" out of "Vishnu Chambers, Shahu Corner" and reports mill VISHNU. | pending |
| C318 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | The gatepass read must ADAPT from its own corrections, like the New Orders screens do (form memory, PLANNING §397): add gatepass to MemoryForm in src/lib/server/formMemory.ts (kinds yarn, count, type, mill/ticket, godown, transporter), learn on save when the user changed or supplied a value the read missed, and resolve that word→master link on the NEXT read before the gateway is asked. The read transcript and the read fields already ride the draft and the form POST — wire them through. |
pending |
| C319 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | When the read matches no master entry, the field's popup offers the read value as a SUGGESTION chip. Where the value needs a master, tapping it OPENS that master's add form prefilled — the yarn master from the read count/type/mill; if the mill is new too, the yarn master's mill field carries the same chip into the mill/ticket master and back; saving returns to the yarn inward intimation with the new entry selected. Nothing is auto-created. | pending |
| C320 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Same create-on-the-go chain for EVERY master-backed field on the form: pickup godown/location → location master, party/trader → party master, transporter → transporter master — each prefilled from the read value and returning to the form with the entry selected. | pending |
| C321 | 2026-10-29 | https://trading.tynolabs.com/masters | Give the create entry in EVERY master-backed field's dropdown, with or without OCR: when the typed text matches no master value, the pick list ends with + <typed value>; tapping opens that master's add form prefilled with the typed text and the saved entry lands back in the field. Add the prefill hook this needs to /masters (?tab=<master>&new=<value>). |
pending |
| C322 | 2026-10-29 | https://trading.tynolabs.com/capture | A gatepass header is printed "GATE PASS" with a space, so the intent scan misses it: today's two uploads of this photo were stored as intent=booking and would open the yarn booking form. Match gate\\s*pass in src/lib/server/intake.ts, keeping the glued "gatepass" case that already works. |
pending |
| C323 | 2026-10-29 | https://trading.tynolabs.com/capture | Every OCR/dictation reader learns from its form's corrections: extend the form-memory learn/resolve loop (PLANNING §397) to the tippan, sample and quote reads — trading, job-work, production and booking already learn. Owner's rule, 2026-10-29: the OCR adapts in all forms, not just the orders ones. | pending |
| C324 | 2026-10-29 | https://trading.tynolabs.com/queue | A deploy must not break the running app while it builds. deploy.sh writes build/ in place (bash scripts/heavy.sh bun run build) and the OLD server keeps serving that mutating directory until systemctl restart — so every ship has a 3–6 minute window where a page load or a __data.json fails (owner hit exactly that on /queue at 15:22, mid-deploy; the same window also deletes the previous build's hashed chunks, so an open tab fails until it reloads). Build to a side directory and swap atomically: vite.config.ts passes adapter({ out: process.env.ADAPTER_OUT ?? 'build' }), deploy.sh builds ADAPTER_OUT=build.next, then mv build build.prev && mv build.next build immediately before the restart, and carries build.prev's hashed client chunks forward into the new build so a tab opened before the ship keeps working. |
pending |
| C325 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | the gatepass uploaded fro OCR is to be saved in the upload field by default. | pending |
| C326 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | The zoom on the photo after clicking on verify fields button is not happening by pinching in and out and scrolling left and right. It should happen like that. Like we use zoom feature on phones | pending |
| C327 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Need a button of Start Wizard, Start OCR at the top | pending |
| C328 | 2026-10-29 | https://trading.tynolabs.com/queue | A deploy must never commit conflict markers. At 15:22 today the deploy's git pull --rebase --autostash hit a conflict between the nine rows queued minutes earlier (C315-C323) and three rows added on the board at the same time (the same ids), and the watcher's git add -A swept the raw <<<<<<< / ======= / >>>>>>> markers into docs/CORRECTIONS.md with duplicate C315-C317 ids on top. Make the pull its own checked step: on a conflict it stops the deploy with a clear message and a conflicted mark instead of continuing; and before any commit + push, refuse to commit a file that contains a conflict marker (a tiny guard script with a test that fails on a marker line). |
pending |
| C329 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Read the trader's Gate Pass No. (printed "Gate Pass No. : GSL/5546") and prefill the yarn-in's Trader's GP no field (partnerGpNo), and list it in the read. Nothing extracts it today, so every yarn-in arrives with no trader reference. Format is letters/digits/slash, 24 chars max, validated exactly like the field. |
pending |
| C330 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | The read must show EVERY value it took, not six of them. On the Goenka paper the read produced count, type, bags, net, booking no, godown and date, but the badge row (gatepassReadLabels) lists only count / type / mill / bags / vehicle / transport — so the booking number that WAS read looked unread. Add the booking no, the trader's GP no and every other read value to that list. |
pending |
| C331 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | The yarn field must resolve the read structurally against the yarn master — the read gives count 61 + type CCW + mill, while master rows are names like "61/1" carrying their own count, type and mill — and when nothing matches it must show the read value as the suggestion chip that opens the yarn master prefilled (C319). On the 19:09 upload the yarn field stayed empty with no chip. | pending |
| C332 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | it is not "Cones in this delivery" but "Cones per bag" | pending |
| C333 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | All fields are compulsory except remarks | pending |
| C334 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | remove the long ass description from all the pages, focus entry pop-ups etc. foe e.g. "Pick the yarn booking / job-work no, the bags to be received and the location of pickup — the trader, the yarn and the rate come from the booking." at the top of the page and "Snap or upload the trader’s gatepass — the AI reads it and fills the yarn count, type, mill and bags; nothing is saved until you check the rows and tap save" on read the OCR gatepass wizard pop up | pending |
| C335 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | In the reference picker (SO / production order / yarn booking / job work), a booking number the read took and that matches nothing open is offered as a chip "Add Booking No. 1128" — tapping it opens the yarn booking form prefilled with that number (plus the read's count, type, mill and bags), and saving returns to the yarn inward intimation with the new booking selected. Same create-on-the-go shape as the master chips (C319/C320), for a reference instead of a master; nothing is created without the tap. | pending |
| C336 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Every gatepass must carry the identity of the FORMAT that printed it, so anything learned can be attached to that trader's layout: read the letterhead ("Goenka Syndicate Private Limited" on the top block, before any label) as docIssuer, show it on the read card, and key the learning below on it. Today the read has no issuer at all — partyHint is the buyer, not the printer of the paper — so there is nothing to remember a layout against. |
pending |
| C337 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Learn the FORMAT, not just the value. When the read misses a field and the user supplies it before saving (e.g. booking no 1128 chosen by hand), find the transcript line that carries the entered value and store, per docIssuer + field, the anchor that led to it — the label text in front of it ("Booking No.") or, when the value sits in an unlabelled box, its position hint (line index fraction + column) — plus the value's own shape (digits, letters/slash). On the NEXT gatepass of the same issuer run those learned anchors over the transcript as a deterministic pre-pass, before the model's answer is merged, so the booking no / GP no / mill of that format are filled with no manual step. New table doc_format_memory (issuer, field, anchor kind, anchor text, position, hits), written at save beside the existing form memory, never created without a user save. |
pending |
| C338 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Make the learned format visible and let it teach the model too: on a read whose issuer is already known, pass that issuer's learned anchors into the gateway prompt as a hint ("on a Goenka gatepass the booking number prints on the line 'Booking No. : …', under the date"), and show it on the read card ("Goenka — format known: booking no, GP no, mill"). A user who corrects the same field twice on the same issuer should see the second read get it right without touching anything. | pending |
| C339 | 2026-10-29 | https://trading.tynolabs.com/queue | The line is network-bound, not machine-bound: while a row runs the box sits at load 0.00 (5 cores, 4.1 of 7.3 GB used) because each agent turn is a remote model call (~15 s/turn measured on row C324: 15 messages in 0.9 min) and a feature row needs 30-60 turns. Run TWO row sessions at once, guarded so their target files do not overlap (the second skips any row whose targets intersect the running one; shared docs are already safe: PLANNING/BUILD-LOG union-merge and only the watcher writes QUEUE.md), and keep builds serial through heavy.sh. Expected ~1.8x rows/hour at the same RAM. | pending |
| C340 | 2026-10-29 | https://trading.tynolabs.com/queue | Cut the per-row preamble. Today every row session burns its first turns finding what it was told: it re-reads docs/QUEUE.md and docs/CORRECTIONS.md, STATUS.md, BUILD-LOG.md and greps PLANNING before touching a file. Pass the row's own text, acceptance and target files inline in the prompt and say plainly that the orientation reads are only needed when the row's work depends on them (a flow/decision change), not for a copy, label or badge row. Same result, fewer turns — the only cost the line pays twice per minute. | pending |
| C341 | 2026-10-29 | — | upgrade bun version | pending |
| C342 | 2026-10-29 | src/lib/server/schema-foundation.ts | DB foundation, one additive migration: yarn.grade (A+/A/B/C/blank); order.role (so/po/fabric_purchase), planned_mtrs, trigger (so/stock), sale_kind (normal/damaged), parent_so_id, frozen_at, unit_cost; lot.quality_key and lot.pick; new cost_leg, cost_apportionment, pool_entry (tracks produced/purchased/yarn/salvage), substitution; dispatch_slip.apportionment_id. All nullable or defaulted with a legacy cost flag; run generate and push on a data.db copy, restore evt index and WAL. No behaviour change, no UI. Gate: typecheck clean and migration applies. | pending |
| C343 | 2026-10-29 | src/lib/server/costing | Costing engine, pure functions only (src/lib/server/costing/): WAC pools (yarn by count+type+grade, fabric produced by quality+pick, purchased by quality+pick, salvage zero-cost), leg freeze and accrual, apportion and release at locked cost, substitute quantity-only, SO P and L from locked apportionments plus salvage roll-up, PO P and L incurred divided by good mtrs, variance. No routes, no UI. Tests: WAC in and out, release at locked cost, shortfall re-price, salvage roll-up, zero-cost isolation. Gate: tests green. | pending |
| C344 | 2026-10-29 | src/routes/lots | Yarn pool wiring: yarn-in writes pool_entry in at WAC by count+type+grade; issue to a production order writes pool_entry out at WAC plus a cost_leg yarn row at that WAC; free versus apportioned-to-PO state. DB uses yarn.grade. UI: yarn master adds a grade select with server and client validation; yarn stock shows grade. Tests: issue cost equals WAC at issue and a later purchase changes only future issues. | pending |
| C345 | 2026-10-29 | src/routes/orders/new | Production order lifecycle: create with role po, planned mtrs = SO remaining rounded UP to 100, editable with a confirm prompt, trigger tag; cost legs by kind as rate commitments plus freeze; completion writes good mtrs at unit cost = incurred divided by good mtrs, unassigned output to the produced pool; shortfall shrinks assignment, re-prices the assigned mtrs, opens an exception and a dashboard todo (queue.ts) to apportion the gap; cancellation releases yarn unapportioned, produced fabric to the free pool, no conversion accrual. Backend plus PO record UI. Tests for completion, shortfall, cancellation. | pending |
| C346 | 2026-10-29 | src/routes/orders/new | SO with atomic cost coverage: sale_kind and parent_so_id with validation; one transaction writes the SO, the apportionments (fabric pool at WAC, existing PO output at PO cost, market fabric, new PO shell) and the auto PO; balance must equal the SO quantity exactly, no pending save, no over-coverage; coverage step in the existing order wizard (reuse FocusEntry) showing per-source pick and WAC plus order value and margin. Tests: rollback, round-up, exact balance. | pending |
| C347 | 2026-10-29 | src/routes/orders/[id] | SO amendment and cancellation: quantity up and down, rate and terms, quality and pick (release at locked cost then full reassignment), cancel (release all, the PO survives unassigned); PO cancel rules; append-only with events and a single rebalance action. Backend api/amend plus orders actions, UI on the SO record. Tests: release at locked cost, quality and pick reassignment, both cancellations. | pending |
| C348 | 2026-10-29 | src/routes/checking | Checking and mending grades: add X (absolutely non-usable, zero-cost salvage track, excluded from WAC, only damaged-SO sale) and make R a sellable cost-bearing FG grade; enum and validation on both surfaces; damaged SO marking gates X sales; salvage P and L rolls into the parent SO, else only in the damaged SO P and L. Backend checking route plus pool hook, UI grade buttons. Tests: X never enters produced WAC, R ships, salvage roll-up. | pending |
| C349 | 2026-10-29 | src/routes/fabric-purchase | Market fabric purchase: entry form and commitment (supplier, quality, pick, mtrs, rate per m, freight, GST, date) writing a fabric_purchase order plus one cost_leg; purchased WAC by quality and pick, never blended with produced WAC; assignment to an SO or into the pool. DB, backend, UI form and coverage panel. Tests: separate WAC tracks. | pending |
| C350 | 2026-10-29 | src/routes/reports | Stock report: extend reports and lots to show yarn by count+type+grade, fabric by quality+pick+grade, produced versus purchased tracks, own versus party, WIP versus apportioned versus free, locations in-house/sizer/weaver/transit, valued at WAC; add pick, grade and track filters. Backend reports.ts, existing UI only. Test: a seeded scenario reconciles with pool entries. | pending |
| C351 | 2026-10-29 | src/routes/gatepasses/new | Direct delivery to weaver: accept a Weaving-category party as a DIRECT destination (today only premises plus Godown/Sizing), set the stock location to weaver, no WAC change; server and client validation. Backend gatepasses/new and lots, UI location picker. Test: a DIRECT to weaver creates the record and the weaver stock location. | pending |
| C352 | 2026-10-29 | src/routes/bookings/new | Yarn landed cost: booking gains freight and purchase brokerage inputs; receipt screen checks billed versus arrived kg and absorbs short receipt (billed amount divided by received kg); the landed rate feeds the yarn WAC by count+type+grade and the PO yarn leg. DB, backend, UI on bookings/new and inward. Tests: landed rate math, short receipt absorption. | pending |
| C353 | 2026-10-29 | src/lib/server/costing | Cost leg bases: warping at rupees per kg of warp; sizing at rupees per kg of warp sent, with the actual bill possibly stating a reverse-calculated billing kg from the received count (quantity variance); weaving at picks per metre times rupees per pick divided by 100 on good fabric mtrs, rate entered per booking with no master because the market varies and the rate is width-sensitive, internal rate for in-house looms; checking charged per fabric metre actually checked including X, rate per quality with a yearly default and editable; mending not charged; packing and loading direct. Backend PO legs, UI, tests. | pending |
| C354 | 2026-10-29 | src/routes/bills | Bill lifecycle and restatement: cost legs move from provisional to actual via a bill entry (manual plus import, vendor, bill no and date, kind, amount, GST) auto-allocated to POs by quantity; variance split into quantity and rate; recompute PO total and unit cost, restate the pool entry and every SO that drew from it; SO pnl_status provisional until all bills, auto-close on the last bill, manual close with a flag when bills are missing, and a bills-pending queue row. Tests: restatement cascade, allocation, close rules. | pending |
| C355 | 2026-10-29 | src/routes/orders/[id] | SO P and L lines on delivered mtrs: revenue from delivered mtrs; CD availed from the dhara slab; credit cost = max CD minus availed CD; brokerage; overhead 1 percent company-wide default and editable; freight-out, insurance, octroi and statutory, sample; each computed on the selling price via cost times p divided by 1 minus p so each is exactly its percentage of price; dhara master max-CD slab feeds the max; quote engine corrected to the same gross-up and the 1 percent overhead replaces the 6.5 percent other expenses. Tests: split, gross-up, quote parity. | pending |
| C356 | 2026-10-29 | src/routes/expenses | Exceptional and non-standard costs: entry form allowing a one-off charge at PO level (capitalised, moves WAC) or SO level (direct P and L, default), with document ref and reason, append-only; included in P and L and in restatement. DB cost_leg kind exceptional, backend, UI, tests. | pending |
| C357 | 2026-10-29 | src/routes/lots | Opening stock at cutover: entry of opening quantities and values for yarn by count+type+grade and fabric produced and purchased by quality+pick, feeding pool_entry so the WAC starts from real stock; validation, optional import. DB, backend, UI, tests. | pending |
| C358 | 2026-10-29 | src/routes/orders/[id] | SO fulfilment marking: manual Order fulfilled action allowed only when delivered mtrs are within the order tolerance, blocked outside so the SO must be amended first; short within tolerance releases the remainder at locked cost; long within tolerance requires apportioning the excess from stock or an existing PO at current cost before marking; reversal only with owner approval, append-only. Backend orders/[id], UI action, tests. | pending |
| C359 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | A normal trader gatepass must not open as a DIRECT delivery. Reproduced against the live API with the Goenka photo: the reader returns destination: "KRISHNANUNJ GODOWN - 1, Shahapur, Ichalkaranji 416115" (the godown ADDRESS printed on the paper) and captureRouting reads any destination at all as "direct delivery", so the read lands on ?kind=DIRECT — a form with only booking, bags, location and date, which ignores the count, type, mill, trader's GP no and booking no it just read. That is exactly "it detects but does not prefill". DIRECT must be chosen only on an explicit direct-delivery signal (destination exactly godown/premises/sizer, or the words "direct delivery"), and a read booking number must win as YARN_IN; a printed godown address is the receipt's location, not the intent. Carry the resolved yarn master id in the prefill too (the API already resolves it) so the single yarn field arrives filled. |
pending |
| C360 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Creating a master or a reference from inside a form must never cost the form. Today a chip opens the child route as a normal navigation (/masters?tab=yarn&new=…, /bookings/new?…), so the half-filled gatepass is gone and the operator starts again. Open the child in a modal over the form instead: the form keeps its exact state, the modal closes on save (and on cancel/back), and the new entry lands in the field it was opened from — yarn, mill, party, godown, transporter, and the "Add Booking No." reference alike. |
pending |
| C361 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Total cones not needed | pending |
| C362 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | The documents field should give an option of downloading the uploaded/ocr document or uploading new and uploading multiple. | pending |
| C363 | 2026-10-29 | https://trading.tynolabs.com/gatepasses/new?kind=YARN_IN | Still can't pinch and zoon into the image. After 100% it does not zoom further. | pending |
| C364 | 2026-10-30 | src/lib/server/costing/pool.ts,src/lib/server/lots.ts,src/lib/server/reports.ts | Docs log + test. Yarn pool: an earmarked purchase never enters the unapportioned pool WAC. A booking whose cost is apportioned to one or more production orders keeps its own per-order ledger at the booking landed rate (rate x received kg + freight + brokerage); the free pool balance and WAC count only entries with no order tag. An issue to a PO consumes its own earmark first at that locked rate, then free stock at the free pool WAC. The stock report shows free kg and earmarked kg separately. Validation: earmarked kg <= the booking received kg and the tag split sums to its net kg. Tests: a 100 kg receipt at Rs200 tagged to a PO does not move a 100 kg free pool at Rs150 (WAC stays 150) and that PO reads Rs200/kg. | pending |
| C365 | 2026-10-30 | src/lib/server/lots.ts,src/routes/bookings/new/+page.server.ts,src/routes/orders/[id]/+page.server.ts | Docs log + test. Yarn cost is a manual earmark, not a side-effect of the gatepass. YARN_OUT writes quantity only, with no yarn cost leg. The PO yarn leg is written when procurement earmarks a booking (or part of it) to the PO at the booking landed rate, or when the user explicitly draws free stock to the PO at that moment WAC. The booking form Against split writes the earmark (kg per PO) and the PO record shows its yarn bucket (source, kg, rate, value, still unbilled). Validation: earmark kg > 0 and <= the booking un-earmarked kg; the landed rate is read-only on the earmark; a free-stock draw <= the free balance for that count+type+grade. | pending |
| C366 | 2026-10-30 | src/lib/server/schema-foundation.ts,src/lib/server/poLifecycle.ts,src/routes/orders/[id]/+page.svelte | Docs log + test. A production order is a program, not one spec: one quality ideally, but several picks, tippans and weavers. Add a po_segment costing unit (poOrderId, qualityKey, pick, weaverId, tippanId, plannedMtrs, weaving rate per pick, inHouse). order.picks and jobRate remain the default first segment. The weaving commitment leg is written per segment (picks/m x rate per pick / 100 on the segment planned mtrs) and an in-house segment uses the internal rate with no vendor bill. The PO record lists the segments and lets the user add one before any fabric-in against it (append-only amendment). Validation: pick 1-200, rate > 0, planned mtrs > 0, no segment change after fabric-in. | pending |
| C367 | 2026-10-30 | src/routes/fabric-in/+page.server.ts,src/routes/checking/+page.server.ts,src/lib/server/poLifecycle.ts | Docs log + test. Cost is per lot, not per PO. fabric_in carries the segment it came from, the quality key and the actual pick of the delivered fabric (not design.pick); the lot it creates takes that quality and pick. The lot cost is its segment yarn share + warping + sizing (pro rata by the beam mtrs it used) + weaving at the segment rate per pick x the actual picks/m + checking on its checked mtrs, divided by the lot sellable (A/B/C/R) mtrs; X mtrs carry zero and their costs stay in the numerator. Completion writes one pool entry per lot at that lot unit cost, not one PO unit cost, and apportions to the SO at that lot cost. Shortfall is per segment. Validation: a lot needs a pick > 0 and a segment; graded mtrs sum to the lot net. | pending |
| C368 | 2026-10-30 | src/routes/checking/+page.server.ts,src/lib/server/costing/pnl.ts | Docs log + test. Within a lot the cost per sellable metre is grade-blind: A, B, C and R all carry the same Rs/m and a grade difference appears only in the selling price. X is zero cost and its yarn, weaving and checking share is pushed onto the lot sellable mtrs. Checking is charged per checked metre including X. Validation: graded mtrs sum to the lot net mtrs and a lot with no sellable mtrs refuses completion. | pending |
| C369 | 2026-10-30 | src/routes/beams/[id]/+page.server.ts,src/lib/server/schema-foundation.ts | Docs log + test. A beam or part of one can move from one PO to another, even of another quality. The receiving PO books it at a market value typed by the user, composed leg by leg: warp kg x yarn rate + warp kg x warping rate + sizing kg x sizing rate. The form shows hints (the latest procurement rate for that count+type+grade, that day rate sheet for warping, the yarn master sizing rate) but the typed figures are the authority and are stored on the transfer with the hints shown. A partial beam splits pro rata by kg. The gap between the beam carried cost (yarn at issue + actual warping + sizing) and the typed market value is a transfer variance leg on the transferring PO, gain or loss, and the SO apportioned to it is re-apportioned. Validation: all three rates > 0, kg > 0 and <= the beam net, no transfer of a beam with no sizing bill. | pending |
| C370 | 2026-10-30 | src/lib/server/poLifecycle.ts,src/routes/orders/[id]/+page.svelte | Docs log + test. An SO-linked PO carries a budget: the accepted quote planned legs x the PO own planned quantities, snapshotted when the PO is created (a quote is never revised once an SO exists). A stock PO has no budget. The PO record shows budget vs actual per leg and the drift. Validation: a budget is written only when the PO has a parent SO and a quote; never for a stock PO. | pending |
| C371 | 2026-10-30 | src/lib/server/soCoverage.ts,src/lib/server/costing/pnl.ts | Docs log + test. The SO cost is per leg at the rates of the PO it was apportioned against, over the fabric actually delivered: weaving is that PO rate per pick x the delivered lot actual picks/m, and the other legs follow the delivered lot quantities. A higher-pick lot delivered against a lower-pick SO shows the extra cost in the SO P&L and the SO committed rate never moves. Where the delivering PO own cost differs from the SO locked value the difference is a variance on the delivering PO (over or under), never a re-price of the SO. An apportionment row carries the committed leg rates, not only a unit cost. Until a leg is committed the SO provisional cost uses the PO budget (C370). Validation: an apportionment refuses a lot with no pick. | pending |
| C372 | 2026-10-30 | src/lib/server/poLifecycle.ts | Docs log + test. Cancelling a PO returns its yarn to free stock at its carried cost, not at zero. The release out and in pair carries qty x the order yarn unit cost (the current code writes value 0, which deflates the free pool). Produced fabric stays in the free pool at its lot cost. An unstarted sizing or weaving commitment is not charged. Validation: the release value must equal qty x unit cost and the free pool value must rise by it. | pending |
| C373 | 2026-10-30 | src/lib/server/bills.ts,src/routes/bills/+page.server.ts | Docs log + test. Every bill is apportioned to its PO by the user at entry: the bill names the PO and the share, and nothing is silently auto-allocated. The form suggests by open committed quantity and shows the remainder, but a bill with no allocation cannot be saved. Validation: shares > 0 and their sum equals the bill amount; an allocation cannot exceed the PO open committed leg. | pending |
| C374 | 2026-10-30 | src/lib/server/schema-foundation.ts,src/routes/quote/new/+page.server.ts | Docs log + test. A quote carries the commercial terms the SO inherits: purchase brokerage % and pass-on %, and the freight/insurance term with its recovery basis (inside the rate or billed on top, default excluded and borne by the buyer). Add these to the quote schema and the quote form with validation (both percentages 0-100, a delivery-term enum, a recovery enum), and carry them into the SO read-only. The SO never asks for them again. See docs/ORDER-FORMS.md D17/D18. | pending |
| C375 | 2026-10-30 | src/routes/orders/new/+page.server.ts,src/routes/orders/new/orderLogic.ts | Docs log + test. A normal SO must be created from a quote. Make quote_id required for a normal sale: the server refuses an SO with no quote, keeps one SO per quote, prefills buyer, broker, quality, picks and the delivery window from the quote, and lets sales overwrite the rate with the final negotiated figure (still greater than zero). Remove the SO owner-approval gate: a sales-booked SO is approved at creation and goes straight to PPC. Retire free entry of buyer, quality and broker on this form. See ORDER-FORMS D23/D24. | pending |
| C376 | 2026-10-30 | src/routes/orders/new/trading/+page.svelte,src/lib/components/orders/OrderEntryForm.svelte | Docs log + test. The new-sale-order screen opens on the pending-quotes table (party, quality and alias, quantity, rate, validity, days open; searchable), not a blank form. Tapping a row opens the SO already filled. Back returns to the table with the choice cleared. A Change action on the quote chip re-inherits from the newly picked quote and resets everything typed against the old one (quantity from its estimate, rate from it, tolerance back to 5, remark cleared). See ORDER-FORMS D24. | pending |
| C377 | 2026-10-30 | src/lib/components/orders/OrderEntryForm.svelte,src/routes/orders/new/orderLogic.ts | Docs log + test. Replace the 14-step SO wizard with four focus steps: quantity, rate, tolerance, remark. Keep the quote facts pinned as a meta strip on every step (quote no, buyer, quality, delivery window, payment, rate) and delete the dead hidden section blocks. Each step keeps its own gesture and context coins: quantity a 1000-metre wheel with 100/1000 steppers and coins from the quote estimate, this buyer and this quality; rate a keypad with 0.25 steppers and coins from the quote and the quality history; tolerance chips 3/5/7/10; remark dictation plus past remarks for this buyer. Labels are short and the value owns the row. See ORDER-FORMS D25. | pending |
| C378 | 2026-10-30 | src/lib/server/schema-foundation.ts,src/routes/orders/new/orderLogic.ts | Docs log + test. Add tol_pct to the order (default 5, sales-editable, bounded 0 to 25) and delivery_start and delivery_end dates. The start date is the promise for the first delivery and the end date the promise for completion. Retire due_days and promised_days from the SO form and the ops completion; keep the columns for history only. Validation on both surfaces: tolerance between 0 and 25, start not before the booking date, end not before start. See ORDER-FORMS D2/D6/D13/D20. | pending |
| C379 | 2026-10-30 | src/routes/dispatch/+page.server.ts,src/lib/server/soCoverage.ts | Docs log + test. Dispatch is checked against the sale quantity with its tolerance band. Inside quantity plus or minus tol pct the dispatch proceeds; beyond the band the order needs an amendment and owner approval rather than a note. Only A, B, C and R metres count toward the sale quantity: X never counts toward the quantity or the tolerance. The buyer dispatch-lot size is a hint on the dispatch form and is never enforced. See ORDER-FORMS D2/D4/D5/D6. | pending |
| C380 | 2026-10-30 | src/lib/server/soCoverage.ts,src/routes/orders/[id]/+page.server.ts | Docs log + test. Cost cover is the PPC stage. Coverage lines may total anything inside the quantity plus or minus tolerance and must not be forced to equal it exactly. The order is ready to produce only when sales is done and the cover is complete within the band. A dispatch that exceeds what is apportioned still saves and raises a cost-not-covered item on the PPC board; a dispatch below the apportioned metres releases the excess at its locked cost. See ORDER-FORMS D3/D4/D20. | pending |
| C381 | 2026-10-30 | src/lib/server/schema-foundation.ts,src/routes/dispatch/+page.server.ts | Docs log + test. Add a consignee to the SO as a party master link with a new Others category. It is optional at booking with an explicit decide-at-fulfilment state; dispatch refuses to save without a consignee. Validation: the consignee must exist and be an active party; when present at booking it is read-only for planning. See ORDER-FORMS D7. | pending |
| C382 | 2026-10-30 | src/lib/server/schema-foundation.ts,src/routes/orders/new/+page.server.ts | Docs log + test. Store the broker as a party id (broker_id) instead of the typed broker_name. Migrate existing orders by matching broker_name to party.name where category is Broker and keep broker_name for history. The broker picker offers master brokers only; the quote already carries brokerId and the SO inherits it. See ORDER-FORMS D8. | pending |
| C383 | 2026-10-30 | src/routes/orders/new/+page.server.ts,src/routes/orders/[id]/+page.server.ts | Docs log + test. Store cd_pct and payment_days on the order, taken from the chosen payment slab at booking, alongside the dhara link. The ops completion prefills them instead of re-keying and the pending-ops flag no longer fires once they are set. See ORDER-FORMS D9. | pending |
| C384 | 2026-10-30 | src/routes/orders/new/orderLogic.ts | Docs log + test. Tighten the order form rules on both surfaces: rate greater than zero for every role, picks an integer between 1 and 200 (picks per inch), quantity a multiple of 1000 metres, and no duplicate buyer PO number on the same buyer. Fix the picks placeholder, which still reads 4000 and must show a per-inch example such as 64. See ORDER-FORMS D10/D15. | pending |
| C385 | 2026-10-30 | src/lib/components/orders/OrderEntryForm.svelte | Docs log + test. Server failures must be visible. The error banner and every field error are rendered inside the hidden form container, so a rejected save appears to do nothing. Render the banner in the visible summary, jump to the first field in fieldErrors and open that field step with the message under it. See ORDER-FORMS UI notes and the verified finding in the session log. | pending |
| C386 | 2026-10-30 | src/lib/server/queue.ts,src/routes/orders/[id]/+page.svelte | Docs log + test. One order record with three stages: Sales, Planning and PPC. Sales and PPC complete make the order ready to produce; planning complete gates weaving. Each stage shows its own fields open for its role and a read-only summary for the others. Add each stage to the per-role pending board with an age, and make the board that role landing page. See ORDER-FORMS D16/D27. | pending |
| C387 | 2026-10-30 | src/routes/orders/[id]/+page.svelte,src/routes/orders/[id]/+page.server.ts | Docs log + test. Planning works a card: the buyer order image pinned in the top half (zoomable, collapsible), the planning fields below (buyer PO no, packing, cut size, rolls computed, consignee) prefilled from OCR and tappable to correct. The image is optional at SO creation; planning uploads it when sales did not. See ORDER-FORMS D28 and the planning stage in D16. | pending |
| C388 | 2026-10-30 | src/lib/components/orders/OrderEntryForm.svelte | Docs log + test. Selecting a quality records that quality alias on the order, and a user not arriving from a lead or quote can type the alias to find the quality. The picker already searches name or alias. See ORDER-FORMS D14. | pending |
| C389 | 2026-10-30 | src/lib/server/costBasis.ts,src/lib/server/reports.ts | Docs log + test. Retire the legacy yarn cost basis path: remove the field from the order form, delete recordCostBasis and the order_cost writes, and point the Reports order-profitability table at the new cost engine (cost legs and apportionments). Keep the table for history but stop reading it. See ORDER-FORMS D26. | pending |
| C390 | 2026-10-30 | src/routes/orders/new/+page.server.ts,src/lib/components/orders/OrderEntryForm.svelte | Docs log + test. A damaged (X) sale gets its own small form, exempt from the compulsory quote: buyer, the lot it comes from, metres, scrap rate, consignee and remark, with validation (metres greater than zero and not above the lot balance, rate greater than zero, the lot must be an X or damaged lot). It links to its source sale order where one exists. See ORDER-FORMS D21/D22. | pending |
| C391 | 2026-10-30 | src/lib/components/orders/OrderEntryForm.svelte | Docs log + test. The order draft autosave snapshots only the fields this form actually shows. Today it restores dispatchCity and other hidden values, so a later form can inherit state the user never saw. Restrict the snapshot and the restore to the visible field set for this form type and role. See docs/ORDER-FORMS.md, verification pass item U8. | pending |
| C392 | 2026-10-30 | src/routes/orders/[id]/+page.server.ts,src/routes/orders/[id]/+page.svelte | Docs log + test. Field ownership after the three-stage split: the ops completion form currently offers rate, cash discount and dispatch city, which sales and planning now own (C375, C383, C381). Make them read-only there or drop them, so two surfaces cannot disagree. See ORDER-FORMS D16 and the verification pass item F5. | pending |
| C393 | 2026-10-30 | src/lib/components/orders/OrderEntryForm.svelte | Docs log + test. Split OrderEntryForm.svelte (about 3,460 lines) by stage: the sales identity and quote strip, the quantity and price steps, delivery and terms, planning, and the review sheet, each a small component under src/lib/components/orders. No behaviour change; the route stays a thin shell. See AGENTS.md UI rules and ORDER-FORMS. | pending |
| C394 | 2026-10-31 | docs/contracts/so-form.json,src/lib/contracts.ts | Docs log + test. Every entry form gets a machine-readable contract under docs/contracts, read by one shared typed loader so the form, the test and the router cannot disagree. Ship the schema (form, kind, role, read-only strip, fields with order/owner role/required/rule/prefill, the actions the screen may offer, and an absent list naming where each omitted field lives instead) and wire the SO contract that already exists at docs/contracts/so-form.json (ORDER-FORMS D29) through it. Acceptance: the loader returns the SO contract typed; a malformed or missing contract fails loudly; no form-specific field list exists anywhere but the contract. | pending |
| C395 | 2026-10-31 | src/lib/components/orders/OrderEntryForm.svelte,src/routes/orders/new/trading/+page.svelte,src/routes/orders/new/orderLogic.ts | Docs log + test. Rebuild the sales SO screen to ORDER-FORMS D29 and docs/contracts/so-form.json: a read-only quote strip (quote no, buyer, quality, quoted delivery, payment, quoted rate) followed by one flat list of SIX fields — quantity, delivery start, delivery end, rate, tolerance, remark (D30: both promise dates are prefilled from the quote but editable and required at booking). Delete for the SO: the four section blocks, the coverage/apportionment step (it belongs to PPC), the production-role fields (buyer order no, cut size, rolls — they move to planning), the consignee field (planning, owner 2026-10-31), the hidden duplicate sections, and the Create SO button on the quote-table screen. Keep the draft autosave, restricted to the four visible fields (withdrawn C391/C393). Acceptance: SSR shows exactly the four fields in order, no production field, no coverage, no Create SO button; saving still books the SO with the quote carried; job-work and production forms keep their sections. | pending |
| C396 | 2026-10-31 | src/routes/orders/new/orderLogic.test.ts,src/lib/contracts.ts | Docs log + test. Enforce the contract in a test. For the SO: the form field spec must contain exactly the contract four fields, in contract order, owned by sales, and every name in the contract absent list must have no spec on this form. Adding, moving or re-owning a field without editing docs/contracts/so-form.json fails. Acceptance: green on the current contract; removing a field from the contract fails; re-adding rolls to the sales form fails; the message names the contract line that broke. | pending |
| C397 | 2026-10-31 | scripts/form-contract-check.ts,src/lib/contracts.ts | Docs log + test. Add scripts/form-contract-check.ts: sign in against the running app on 127.0.0.1:4102 with the session cookie, fetch the form, parse the HTML and assert the rendered screen matches its contract — the four fields in order, exactly one create action, no input or error markup inside a hidden container, and for the quote table a quote-no column, no horizontal clipping at 356 px and no second create action. Non-zero exit prints the offending element. Acceptance: green on the live build; a deliberately hidden error div fails it; the table check reports the clipped width when a column is added. | pending |
| C398 | 2026-10-31 | src/lib/components/ScreenShell.svelte,src/routes/quote/new/+page.svelte,src/lib/components/orders/OrderEntryForm.svelte | Docs log + test. One shell, one layer. Add src/lib/components/ScreenShell.svelte (background, header with title and a back control, max width, spacing) and one FocusLayer spec (width, backdrop, header, footer), then adopt both in the quote screen and the SO focus layer so the two stop reading as different apps. Replace the quote popups max-w-xs and bg-black/30 and the SO max-w-md plus blur with the shared spec. Acceptance: both screens render the same shell classes and the same layer width and backdrop; no popup defines its own width; the SO keeps a reachable page header. | pending |
| C399 | 2026-10-31 | src/lib/historyLayer.ts,src/lib/components/orders/OrderEntryForm.svelte,src/lib/components/quote/TermsPopup.svelte | Docs log + test. Android back unwinds one layer. Add src/lib/historyLayer.ts: opening a layer pushes one history entry, closing it by backdrop, button or back pops it, and the route popstate handler closes the top layer instead of leaving the page. Apply it to the SO focus layer and the quote popups, and add scripts/layer-audit.ts that fails on any role=dialog or fixed inset-0 layer that does not use it. Acceptance: with the SO layer open history.length grows by one and back closes the layer while the form stays; a second back leaves for the quote table; the audit is clean and fails when a layer is added without the helper. | pending |
| C400 | 2026-10-31 | AGENTS.md,scripts/row-watch.sh | Docs log + process. Supersede in the same commit. A row that moves or removes a field must update the form contract, delete the old markup, and add a negative assertion that the field is absent where it used to be. Record the rule in AGENTS.md and in the row prompt so a session cannot add the new placement and leave the old one behind. Acceptance: AGENTS.md and the row prompt both state it; a shared assertAbsent helper exists and the SO contract test uses it. | pending |
| C401 | 2026-10-31 | AGENTS.md,docs/QUEUE-AUTO.md,scripts/queue-next.ts | Docs log + process. One owner-row per screen until that screen is stable: two rows must not target the same component in one block. Add the rule to AGENTS.md and docs/QUEUE-AUTO.md, and make the board warn and hold a new row whose target equals an open row target in the same block. Acceptance: queue-next reports the clash instead of silently serialising; AGENTS and QUEUE-AUTO state the rule. | pending |
| C402 | 2026-10-31 | AGENTS.md | Docs log + process. Inventory before queue: no form block is queued until its contract exists and the owner has approved it. Record in AGENTS.md that docs/contracts/ | pending |
| C403 | 2026-11-04 | http://127.0.0.1:5173/orders/new/trading?quoteId=c68-quote-01 | the field sequence should be rate, qty, tolerance, delivery start, delivery end | pending |
| C404 | 2026-11-04 | http://127.0.0.1:5173/orders/new/trading?quoteId=c68-quote-01 | when i tap rate or quantity, expand the portion below showing suggestions based on previous entries. on tapping a suggestion, close this portion | pending |
| C405 | 2026-11-04 | http://127.0.0.1:5173/orders/new/trading?quoteId=c68-quote-01 | terms like brokerage (from quote) should be shown as well | pending |
| C406 | 2026-11-04 | http://127.0.0.1:5173/orders/new/trading?quoteId=c68-quote-01 | delivery start and delivery end shoud be side by side. also show the days as time period. also, suggest different time periods based on previous selections. tapping it should autoupdate delivery end date | pending |
| C407 | 2026-11-04 | http://127.0.0.1:5173/orders/new/trading?quoteId=c68-quote-01 | when i tap any fields, the suggestion portion should autoclose. for all the fields show suggestions like we see on rate and quantity | pending |
| C408 | 2026-11-04 | http://127.0.0.1:5173/orders?created=bw85qqhh6m | when i added ✓ Added — order SO-261104-U7IO, I instead want a popup notification, with the row highlighted | pending |
| C409 | 2026-11-04 | — | the suggestion and tap flow in http://127.0.0.1:5173/orders/new/trading?quoteId=5aincgag3zxm&type=SO seems to be ideal. instead of opening a popup for suggestion, use the above system throughout the website | pending |
Applied
| # | Date told | Target doc + section | Correction | Applied in |
|---|---|---|---|---|
| _(cleared 2026-10-13 at the owner's request — full history remains in | ||||
| docs/CORRECTIONS-LOG.md and git.)_ |