T
Sign in

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

All docs GitHub source

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

FILE OWNERSHIP: this file is written ONLY by the audit session, APPEND-ONLY (one line per reopen — never edit or delete existing lines). The docs session reads these lines and folds them back into the Pending table of docs/CORRECTIONS.md as new C-rows. One writer per file = overwrites are impossible.

Format

reopen C<n> <YYYY-MM-DD> <what is still wrong / what regressed>

Feed

  • reopen C123 2026-09-26 LIVE acceptance fails although the script/test layer is correct. scripts/thermal-governor.sh check-alert + tests/c123-pi-temp-alert.test.ts are green (10/10 at HEAD 7d2e730; 8/10 FAIL on parent e1c2d98) and mocked-temp behaviour is right (84C fires once, no repeats while hot, re-arm strictly below 78C). BUT the Done criterion 'with temp at/above 84C the owner receives one Telegram alert' is NOT happening live: the only check-alert tick is queue-watch.sh line 150, and the running queue-watch.service (MainPID 103260, ExecMainStartTimestamp Sat 2026-09-26 14:50:24 IST) started BEFORE the C123 commit d7bdb5e (14:57:27) and before queue-watch.sh mtime 15:08:58, so it still runs the pre-fix loop (repo C116 reopen note: the running watcher keeps the script it started with). deploy.sh's 15:10 deploy restarted project@trading (ActiveEnterTimestamp 15:10:28) but NOT queue-watch (still 14:50:24). Live vcgencmd sampled 83.4-86.2C; governor status temp_c=85.6 level=critical; .thermal-hot-alert is absent and no Telegram alert was sent. Fix: get the watcher restart to land (C121/C116 reopen lane) so the new tick loads, then re-verify at >=84C.
  • reopen C123 2026-09-26 LIVE acceptance STILL FAILS (re-verified 2026-09-26 15:49). Pi temp 84.0C sustained (vcgencmd 84.0/84.0/85.6/84.5), .thermal-hot-alert absent and no Telegram alert sent. Running queue-watch.service MainPID 103260 ExecMainStartTimestamp Sat 2026-09-26 14:50:24 IST; journalctl -u queue-watch since 14:50 shows NO restart; queue-watch.sh mtime 15:08:58 and C123 commit d7bdb5e 14:57:27 both later than start, so the running watcher has no check-alert tick (only tick is queue-watch.sh:150). ROOT CAUSE (C116/C121 lane, scripts/deploy.sh:71): with set -o pipefail the guard 'systemctl list-unit-files --type=service | grep -q ^queue-watch.service' returns 141 (SIGPIPE: grep -q exits on first match over 207 lines), so the if is ALWAYS false and the whole step-3b block (systemd-run detached restart + sleep 8) is SKIPPED on every deploy. Reproduced: without pipefail rc=0, with pipefail rc=141 (root too). The 15:42:16 deploy log line 62524 shows '==> 3b/6 restart queue watcher' then straight to 4/6 with no sleep and no queue-watch stop/start in the journal. Fix: make the guard pipefail-safe (pre-capture list-unit-files or use systemctl cat), deploy, confirm ExecMainStartTimestamp > queue-watch.sh mtime, then re-verify >=84C. Script/test layer IS green: bun test tests/c123-pi-temp-alert.test.ts 10/10; independent mocked run fired once at 84, silent at 85/80 while hot, re-armed at 77.9, fired again at 84.1, held at 78.

Archived 2026-09-22 (pre-fresh-start reopens — preserved, not deleted)

  • reopen C1 2026-09-12 Quote form field alignment is off, both logically and aesthetically — fields not aligned properly
  • reopen C1 2026-09-12 Quote lead picker should be primary at top as its own separate subsection; picking a lead autofills most fields, party asked only when no lead selected
  • reopen C62 2026-09-22 Live POST /quote/new?/calc with reference design shows sized warp 75.2567 rendered as 75.26 g/m, but acceptance requires 75.27; bases and costing line otherwise correct.
  • reopen C68 2026-09-22 FAIL: acceptance checks 1-4 are not proven on restarted live app. Authenticated GET https://trading.tynolabs.com/quote returned SSR payload with 16 quoteNo rows but 0 C68-DEMO markers; read-only service DB query against /home/fp/trading/data.db returned count 0 for quote ids like c68-%. Therefore live /quote does not show the required 10 demo rows or their party/quality/rate/quantity/validity/delivery/status values. Focused bun test tests/c68-quote-demo.test.ts passes (2 pass), but source test evidence cannot override missing live data.
  • reopen C67 2026-09-22 FAIL: live HTTP create and edit actions returned 200 and distinct quote IDs, but browser MCP/browser executable was unavailable; could not reproduce client-side draft clearing, timed navigation to /quote?created=, or hydrated created-row highlight on the restarted live app. HTTP SSR /quote?created=dhee6zhf4lm4 rendered the saved row but no row-highlight class in the server HTML. Acceptance checks 2-3 therefore remain unproven.
  • reopen C68 2026-09-22 FAIL: acceptance check 3 and check 4 failed on restarted live app after bun scripts/seed-demo.ts. Read-only data.db query found 10 unique C68 rows and all required scalar fields/statuses, but 10/10 referenced design_ids (d-satin-48, d-plain-63, d-plain-62, d-denim-87, d-2x1-62) had no matching design master, so quality/alias was null for every row. Authenticated GET https://trading.tynolabs.com/quote returned 200 and exactly C68-DEMO-01 through C68-DEMO-10, but SSR row C68-DEMO-01 rendered both Party and Quality alias cells as —; preview quality therefore cannot be visible. Focused bun test tests/c68-quote-demo.test.ts passed (1 pass, 95 expect), and a second seed preserved 10 IDs, but test/source evidence cannot override missing live design masters and quality display.
  • reopen C67 2026-09-22 Second consecutive verification FAIL: live new-save action returned HTTP 200 with exactly one new quote row (4rb49afqz6fy / QT-260922-AXV0), and live edit/re-quote returned HTTP 200 with distinct new quote 1pt6jnjsvz while source remained present; focused tests c67/c64/c62 pass (10/10). Browser MCP and browser executable are unavailable, so draft clear, saved-number client success view, timed navigation to /quote?created=, and hydrated created-row highlight could not be reproduced on the live app; SSR contained the created row but no row-highlight class. This is the second consecutive verification attempt and triggers runner stop condition.
  • reopen C68 2026-09-22 FAIL: focused bun test tests/c68-quote-demo.test.ts passes (1 pass, 116 expect), and authenticated live GET https://trading.tynolabs.com/quote returns exactly C68-DEMO-01 through C68-DEMO-10 with rate/status visible. However live SSR/table renders Party and Quality alias as — for every C68 row; /home/fp/trading/data.db has 10 unique C68 rows and party names, but all five referenced design masters (d-satin-48, d-plain-63, d-plain-62, d-denim-87, d-2x1-62) have null alias and quality_name. Therefore quote preview cannot visibly show required party/quality fields; acceptance check 4 fails despite source test passing.
  • reopen C68 2026-09-22 FAIL 2026-09-22: focused test passes, but authenticated live GET /quote returns only 1 unique C68 row (C68-DEMO-01), not exactly 10; its party KESHAV FABRIC/KESHAV, rate 38.5, qty 12000, validity/delivery scalars are serialized, but qualityName and designAlias are blank and the visible quality cell is —.
  • reopen C82 2026-09-22 FAIL independent live verification 2026-09-22: list expired QT-DEMO-1 and persisted quote:auto-expired, but /quote/edit load only auto-expires readQuoteHeads(20); stale open/approved quote outside newest 20 can bypass edit-load expiry. Focused test passes only source-string guards.
  • reopen C66 2026-09-23 live selling popup fails to open when two margin percentages round up to the same 0.25 coin: Svelte each_key_duplicate thrown rendering TermsPopup keyed each {#each s.sellingMarginCoins as coin (coin)} (src/lib/components/quote/TermsPopup.svelte:36). Reproduced on live https://trading.tynolabs.com /quote/new calc for design d-mt-1: margin table 18.02/18.20/18.38/18.56/18.74 -> coins 18.25,18.25,18.50,18.75,18.75 (duplicate keys) => no dialog/coins render, acceptance check 1 (popup opens with one coin per displayed margin %) FAILS. Distinct-value case (design d-mt-15, coins 56.75/57.25/57.75/58.25/59) passes all 5 checks, isolating the duplicate-key crash.
  • reopen C116 2026-09-25 C116 acceptance #1 is NOT live: the RUNNING watcher still enforces ONE shared hourly cap. queue-watch.service PID 58519 ExecMainStartTimestamp = Fri 2026-09-25 21:28:37 IST — it loaded scripts/queue-watch.sh BEFORE the C116 commit 39efaf2 (22:11:12). Proven from /proc/58519/mem: old tokens hour_count/needs_owner/starting swarm present, but QUEUE_MAX_SCOPE_PER_HOUR, QUEUE_MAX_WORK_PER_HOUR, cap_ok, next_kind, can-start, record_stamp, scoping are all absent (0 occurrences). No new-format log line exists (grep -c 'starting swarm (work|scope' = 0); last start 22:04 'starting swarm (5/12 this hour...)' is old format. Fresh CLI invocations pass (status 'scoping 3/12 · working 1/12', independent can-start scope/work, legacy fallback, 1h window; test 8/8) but the live watcher was never restarted, so a working run still cannot start once scoping exhausts the shared 12. Fix: restart queue-watch.service after the script change (make it part of the deploy) then re-verify.
  • reopen C116 2026-09-25 C116 acceptance #1 STILL NOT LIVE: the RUNNING watcher enforces ONE shared hourly cap. queue-watch.service MainPID 58519 ExecMainStartTimestamp=Fri 2026-09-25 21:28:37 IST, i.e. before C116 commit 39efaf2 (22:11:12) and before the split-caps drop-in (mtime 23:07:45). /proc/58519/environ has NO QUEUE_MAX_SCOPE_PER_HOUR / QUEUE_MAX_WORK_PER_HOUR. /proc/58519/mem scan: next_kind=0, record_stamp=0, cap_ok=0, QUEUE_MAX_SCOPE_PER_HOUR=0, QUEUE_MAX_WORK_PER_HOUR=0, 'starting swarm (scope|work'=0, while old hour_count=12 and needs_owner=12 are present. Live log has 0 new-format start lines vs 277 old-format 'starting swarm (N/12 this hour'; last start 22:56:49 '(4/12 this hour...)'. Only the shared .queue-watch.stamps is appended (54 stamps, mtime 22:56:49); .queue-watch.stamps.scope and .queue-watch.stamps.work do not exist. So once the shared 12 is used, a working run still cannot start. Why the deploy did not fix it: the new restart step was added by commit 823b31e at 23:06:42, i.e. DURING the 23:06:39 deploy, so that deploy ran the older deploy.sh and never restarted the watcher; and a restart issued from inside the queue-watch cgroup (the deploy is a descendant of PID 58519) would kill the deploy itself. Fix: make the restart actually land detached from the watcher cgroup, then confirm ExecMainStartTimestamp is after the script mtime, /proc token scan shows the split code, and a new-format log line appears. Fresh CLI status/can-start and bun test tests/c116-split-hour-caps.test.ts (10 pass) are green but are not the running daemon.
  • reopen C121 2026-09-26 C121 acceptance #3 FAILS live (and #4 cannot hold): deploy step 3b still kills the deploy itself. Repro on live host vps-d3go: created a real temporary queue-watch.service (default KillMode=control-group) whose ExecStart spawns a descendant that runs deploy.sh step 3b verbatim; that deploy cgroup is /system.slice/queue-watch.service. systemd-run schedules the restart at +5s, then the deploy sleeps 8s inside the same block, so the restart stops the whole cgroup at +5s and kills the deploy. Evidence over 4 runs: deploy log stops at the sleeping-8 line, 4/6 health and 5/6 commit+push never run, deploy-complete marker MISSING, deploy pid gone, ExecMainStartTimestamp advances (13:20:28 to 13:20:33; 13:22:34 to 13:22:39). systemd-run detaches only the restart command, not the deploy; the comment claims the restart lands after we exit but nothing waits for exit. Also the guard systemctl list-unit-files --type=service piped into grep -q is pipefail-unsafe (SIGPIPE gives rc 141, entire 3b block skipped; observed once here, and the C123 reopen documents it as always-false on the Pi), so the watcher is not reliably restarted either. The focused test is green and fails pre-fix but only greps deploy.sh source, so it cannot catch this runtime self-kill. Correct fix: schedule the queue-watch restart after commit+push, or escape the deploy process from the watcher cgroup, rather than launching it inside step 3b.
  • reopen C68 2026-09-25 put party and quality randomly from master in those dummy entries
  • reopen C71 2026-09-25 edit button is showing 500 error
  • reopen C80 2026-09-25 format is still not good, just one line written after another. Make ti professional msg. Each imp point on a new line. Spaces between imp sections of the msg, etc.
  • reopen C94 2026-09-25 FAIL on live: count changed -> Rate does NOT render the rate step. Repro: https://trading.tynolabs.com/quote/new?fresh=1 -> Steps -> Warp 1 (empty count) -> type 61 -> Rate -> subtitle flips to "Rate from today's board" but body stays on the Count branch (shows 61 stepper + 'Hold +/- to step fast' + 'Rate ->'), no board list, no +/-0.25 stepper, no star, no Done. Deterministic: count 40 works, count 61 fails; pageerror 'each_key_duplicate' (svelte.dev/e/each_key_duplicate). Cause: YarnPopup.svelte:97 keyed each uses product|ticket|rate but two board rows share '61 CCW|U2931|251.5' (NITIN MILLS vs NITIN SPINNERS) -> each key duplicate throws and Svelte aborts the rate block. First acceptance check fails; bun test tests/c94-yarn-count-rate.test.ts passes only because it greps source strings, not runtime.
  • reopen C96 2026-09-25 FAIL on live 2026-09-25: /masters?tab=payment-terms renders the C96 UI (Payment terms tab, 'Add payment terms', Dhara name/Slabs form) but lists no dharas — the SSR data payload is paymentTerms:[] (empty), and the 'Mumbai Dhara' string in the HTML is only the input placeholder. Root cause: the live app (systemd project@trading, WorkingDirectory /home/fp/trading, DATABASE_PATH=/home/fp/trading/data.db, no TURSO_* set) has NO payment_term table — migration drizzle/0026_fixed_tag.sql was never applied (deploy.sh does not run migrations and there is no runtime auto-migrate). scripts/seed-demo.ts guards on hasTable('payment_term') so it silently skips both demo dharas. bun test tests/c96-payment-terms.test.ts passes 9/9 (source-grep only) and cannot override the missing live table. First acceptance check fails; fix = apply migration 0026 to data.db (bun -e CREATE TABLE / drizzle push) and re-run seed, ideally add a migration step to deploy.sh.
  • reopen C97 2026-09-25 FAIL on live 2026-09-25: /quote/new renders the Payment dhara row but the picker lists no dharas (0 'Mumbai Dhara' in SSR) because the live data.db has no payment_term table (C96 reopen; migration 0026 never applied), and /masters?tab=payment-terms still shows 'No payment terms yet'. So picking Mumbai Dhara + 4%/15-day slab cannot render '4% – 15 days', and saving a dhara is rejected: resolveDhara queries the missing payment_term table (caught -> []) and returns 'Unknown payment dhara — pick one from the list'. Secondary: C97's commit added no migration/columns — live quote table has neither payment_dhara nor payment_slab (schema-foundation.ts untouched by b72daba); persistence currently relies only on the inputs_json fallback. Reopen once C96 (payment_term table + demo dharas) is live. bun test tests/c97-quote-payment-dhara.test.ts passes 10/10 (source-grep only, cannot override missing live master).
  • reopen C104 2026-09-25 FAIL live 2026-09-25: /bookings/new still renders the OLD guided form visibly alongside the new summary+wizard — SSR has
    with no hidden class plus sections sec-yarn/sec-bags/sec-rate and inputs name=bags/supplier/ratePerKg, 'Step 1 of 3', 'Check & save'. So the real POST form is NOT hidden and every field is NOT entered only via its popup (acceptance check 2), and the correction's 'summary over the hidden real POST form / exactly like quote-new' is unmet (quote-new/leads/new/orders/new all use class=hidden). Also +page.svelte is a 1038-line monolith that kept all old state/logic/markup — not the required thin shell composing src/lib/components/booking/* (mandate 12 component-first). Focused test 18/18 and full suite 2315 pass, but the test never asserts the form is hidden or the page is thin.
  • reopen C98 2026-09-25 it is implemented but there is a bug. after selecting one inthe wizard, when i try to add the other using the backgroung form, it oopens the same combo field of wizard consequently allowing me to add only one out of party/broker
  • reopen C98 2026-09-26 Live check (playwright vs https://trading.tynolabs.com, signed in as owner, GET /quote/new?fresh=1 = 200, no page errors). The reopen bug IS fixed: pick a party in the wizard, then the summary Broker row opens a broker-SCOPED picker ('Setting the broker — the party on file keeps its value.', placeholder 'Search broker…', broker-only coins) and both end up on one quote — Party 'BHARAT RATHI GROUP' (enquiry from) + Broker 'UMA TEXCOM'; reverse order also works. BUT the original acceptance regressed: the wizard's own 'Who's this for?' step is NO LONGER a combined list — it is Party-only. Typing real broker master records into that one search gives 'No match — add them under Masters first.': 'UMA TEXCOM', 'BALDEV TEXTILE (S A TEX)', 'JATHAR SIZING' (all category='Broker' rows in the party master); 'SHARMAJI' returns only the party MAHALAXMI GROUP - SHARMAJI, 'VISHNU' only VISHNU FABRICS (broker VISHNU SIZERS-JATHAR missing). Regulars coins are SDM TEXTILES / NITIN MILLS / SUPER SIZING / CHARBHUJA UNIT 04 — no broker, and two are not contacts at all (a Sizing house + an OwnUnit). The on-screen hint still says 'Parties and brokers together — picking sets the right field.' and the placeholder 'Search party or broker…'. Cause: d5fad85 replaced the combined wizContactList with partyOptions.filter(p => p.category === (contactScope === 'broker' ? 'Broker' : 'Party')), so contactScope='' (the wizard's own step) falls through to 'Party'; the same line also leaves the unscoped coins unfiltered by kind. Live bundle proves it: chunk 44.B6Lqzd68.js contains (e.category??'')===(r($)===broker?'Broker':'Party'). FAILED acceptance: 'contact step shows one combined Party/Broker list' and 'both parties and brokers reachable from the one search with combined recent coins'. Note bun test tests/c98-quote-party-broker-combined.test.ts passes 13/13 because it only reads source as text (it actually asserts the buggy line) — proof by opening the page is what catches it. Fix: unscoped step must list category Party + Broker (coins likewise, parties/brokers only, no Sizing/OwnUnit), scoped steps stay kind-filtered.
  • reopen C98 2026-09-27 Verifier 2026-09-27, live page proof (chromium/CDP vs https://trading.tynolabs.com, signed in as owner fresh@example.com, GET /quote/new?fresh=1 = 200, zero page errors). The 2026-09-25 scoped-picker fix is intact and the MUST NOTs hold, but the ORIGINAL acceptance is still broken exactly as the 2026-09-26 reopen said. (1) The wizard's own step 'Who's this for?' is Party-ONLY, not combined: walked the wizard by clicking Next/Skip to step 7 of 7, typed real Broker master names into that one search and read the rendered DOM list — 'UMA TEXCOM' -> 'No match — add them under Masters first.'; 'JATHAR SIZING' -> No match; 'VISHNU SIZERS' (broker VISHNU SIZERS-JATHAR) -> No match; 'RAJESHWARI STATIONERY' -> No match; 'MUNDA' (broker p-broker1) -> only fuzzy PARTY hits DHANSHRI TEX ( MANISH MUNDADA) / VG MUNDADA TEXTILES, the broker itself absent; 'SHARMAJI' (broker p-mt-33) -> only party MAHALAXMI GROUP - SHARMAJI; 'JATHAR' -> only party JATHAR, not broker JATHAR SIZING. Brokers are unreachable from the one search, so 'picking a broker name sets brokerId + initiator=broker' cannot be exercised from the contact step at all. (2) The on-screen hint still lies: 'Parties and brokers together — picking sets the right field.' with placeholder 'Search party or broker…' over a party-only list. (3) Coins are not combined: Regulars = SDM TEXTILES (Party), NITIN MILLS (Party), SUPER SIZING (category='Sizing'), CHARBHUJA UNIT 04 (category='OwnUnit') — no broker, and 2 of the 4 are not contacts at all. (4) What DOES work, for the record: picking party BHARAT RATHI GROUP from the wizard list -> summary row 'Party [enquiry from] BHARAT RATHI GROUP', and the summary's scoped Broker row opens the broker-scoped picker (placeholder 'Search broker…', coins UMA TEXCOM / JATHAR SIZING / BALDEV TEXTILE (S A TEX) / SHARMAJI) where 'UMA TEXCOM' is pickable; hidden POST form then reads partyId=p-mt-5, brokerId=p-mt-1, initiator=party — one quote with both, saved fields untouched. (5) Live bundle the page is running confirms the cause: the node chunk served at /_app/immutable/nodes/*.js contains jt=C(()=>{let e=r(Q).trim().toLowerCase(),t=r(Y).filter(e=>(e.category??)===(r($)===`broker`?`Broker`:`Party`));…}) and Mt=C(()=>r(Y).filter(e=>!r($)||(e.category??)===(r($)===broker?Broker:Party)).slice(0,4)) — contactScope='' falls through to 'Party' for BOTH the list and the coins. FAILED acceptance: 'contact step shows one combined Party/Broker list' and 'both parties and brokers reachable from the one search with combined recent coins'; 'picking a broker name sets brokerId + initiator=broker' is unverifiable from that step because no broker is listed. Note bun --smol test tests/c98-quote-party-broker-combined.test.ts passes 13/13 because it only reads source as text (it asserts the buggy filter line) — opening the page is what catches this. Fix: with contactScope === '' list category Party + Broker for the list AND the coins (parties/brokers only — no Sizing/OwnUnit), keep the scoped summary rows kind-filtered, and align the test with the combined behaviour instead of the current filter line.
  • reopen C96 2026-09-27 FAIL on live 2026-09-27: the 2026-09-25 blocker is FIXED (payment_term table now exists on /root/trading/data.db, 2 demo dharas list as real rows, add/edit/reopen/seed-idempotency/test all green) BUT the row's 'open-record dialog with edit-in-place + Amend' requirement is broken on the Payment terms tab. The live record dialog at /masters?tab=payment-terms&id=pt-mumbai renders , while src/routes/masters/+page.server.ts amend() looks the table up in a map keyed by schema names {party,yarn,design,loom,flange,defect,paymentTerm}. tabs=payment-terms therefore misses the map. Proof on the running app: POST /masters?/amend entity=payment-terms id=pt-mumbai -> 400 {"type":"failure","status":400,...,"unknown master - pick party, yarn, design, loom, flange, defect or payment terms"} and SELECT ... FROM amendment for that id returns 0 rows; control POST with entity=party (id p-mt-58) -> 200 {"type":"success"}. payment-terms is the ONLY tab id that mismatches the map key, so the defect is specific to C96's new tab, not pre-existing. Clicking Amend on a payment-terms record is a dead control that can never write an amendment. Fix = add a payment-terms alias in the amend tables map (or map tab id -> table).
  • reopen C71 2026-09-27 Live browser (chromium, https://trading.tynolabs.com, owner session) — preview Edit still opens the WRONG/BLANK record, so acceptance 'signed UI opens with the selected quote's quote number, party, quality, and values rather than blank/wrong data' FAILS. Repro A (blank): open /quote/new?fresh=1 (the Add quote button) in the same tab, go to /quote, tap C68-DEMO-06, tap Edit -> URL /quote/new?quoteId=c68-quote-06, banner 'Editing C68-DEMO-06 (sent) / Refilled from the saved quote' but the summary rows read Quality '—', Party ' —' (blank) and the wizard auto-opens at 'STEP 1 OF 7' instead of the summary. Repro B (wrong record): in one tab Edit C68-DEMO-06, go back, then Edit C68-DEMO-03 -> banner 'Editing C68-DEMO-03 (converted)' while Quality/Party show C68-DEMO-06's data (PAVAN MANTRI & SURAJ KABRA). Causal proof: on the SAME url/tab, sessionStorage.removeItem('quote-new-draft') + reload -> correct quality '48+4884/3,284/60100-misdent -A-L.H.SIDE', party 'PAVAN MANTRI & SURAJ KABRA', no wizard. Root cause: src/routes/quote/new/quoteNewState.svelte.ts restores the sessionStorage DRAFT_KEY snapshot over the ?quoteId= prefill (draftHad=true overwrites partyId/quality/designId/estQty/selling/...) and the C71 snap 'if (qp && !draftHad) phase = summary' is then skipped, so the quote prefill is discarded. tests/c71-quote-preview-edit.test.ts is green (4 pass) but only pins href strings in source text, so it cannot see this. PASSING: Edit href = /quote/new?quoteId= on every row (never /quote/edit), Reuse = /orders/new?quoteId= prefilled (buyer/quality/qty/rate carried), focus-entry summary+STEP n OF 7 wizard present, and the reported 500 is NOT reproducible (15 rows + 3 edge ids all HTTP 200, zero 5xx, no page errors).
  • reopen C133 2026-09-28 The C133 regression test is RED on the live database's own data — the acceptance check 'bun test tests/c133-requote-version-changes.test.ts passes' is not met. Observed: 'bun --smol test --timeout 180000 tests/c133-requote-version-changes.test.ts' = 13 pass / 3 fail against /root/trading/data.db (it was 16/0 before any re-quote row existed). Cause: tests/helpers/requote-probe.ts picks its source with 'order by q.rowid desc limit 1' (newest quote joined to a design with a quality name) — so the moment the live DB holds ANY re-quote row, the source is itself a versioned quote, and lines 201/248 assert the new number is exactly ${out.source.quoteNo} v2 (= 'QT-260928-LBEJ v4 v2') while line 237 expects the amendment reason to contain 'QT-260928-LBEJ v4'. The app is RIGHT: nextRequoteNo strips the version marker and appends the next one, so the save produced 'QT-260928-LBEJ v5' (original number kept) and the reason reads 'Re-quote of QT-260928-LBEJ — 9 changes' (the number the customer knows); the event payload still carries ofQuoteId/ofQuoteNo of the exact version re-quoted plus baseNo. Fix the TEST, not the app: derive the expected new number from quoteBaseNo(source.quoteNo) + the versions already in the DB (or pin the probe to a base quote that is not a re-quote), and assert the reason against the base number. This also blocks the deploy gate, since deploy.sh aborts on a red suite. DO NOT delete the evidence rows to make it green (append-only): base QT-260928-LBEJ id 360cey6nb0xa, v2 3ra00iouzptg, v3 hewwjm6vx0ih, v4 bm44qjooejh5. Everything else verified PASS on the live app with a real signed-in browser: re-quote opens fully editable (warp 30->36, weft 31->38, quality twill->plain with pick 70->86, party CTN->SDM TEXTILES, job 16->18, selling 60->63.5, qty 25000->28000, validity, delivery start/end all took), save keeps the original number with a version marker and records every change old->new in inputs.requote + amendment + evt quote:requoted, the quote screen shows the list per field (incl. Cost/m 16.53->18.91), v1 and v2 stay byte-for-byte identical (sha256 of the whole row and of their evt/amendment history unchanged) and are still openable, no /quote/edit link on the live quote list, C42 orders Reuse untouched.
  • reopen C137 2026-09-30 gate failed (exit 1): bun --smol test --timeout 60000 tests/c137-cost-control.test.ts — see screenshots/.gate-C137
  • reopen C139 2026-09-30 NOT IMPLEMENTED - verified on the LIVE app (trading.tynolabs.com), commit 5866a5e. (1) Live running process 374902 (bun run build/index.js) env still has CAPTURE_LLM_URL=https://api.deepseek.com, CAPTURE_LLM_MODEL=deepseek-flash (.env lines 18-20 unchanged), so DeepSeek is still the single gateway feeding all three reads. Live POST /api/order-understand returned HTTP 200 {"ok":true,"by":"deepseek-flash",...} and live POST /api/lead-understand returned HTTP 200 {"ok":true,"by":"deepseek-flash",...} - both reads still labelled deepseek, not space-bunny-free. (2) Zero occurrences of 'x-opencode-session' in src/ (grep) and zero in any live-served asset, so no call site sends a session id; also zero occurrences of 'opencode.ai' or 'space-bunny-free' in src/ (only in docs/ and .opencode/ agent config). (3) max_tokens unchanged at 500/500/600/700 (intake.ts:268,410, order-understand/+server.ts:90, orderDocRead.ts:393) - the budgets the correction measured as returning an EMPTY answer at finish_reason 'length' were not raised, so a real slip would still half-read. (4) 'no deepseek host/key/model default in src/' FAILS: 31 deepseek matches in src/, incl. LLM_MODEL_DEFAULT='deepseek-flash' in all three read paths (intake.ts:172, orderDocRead.ts:32, api/order-understand/+server.ts:21) and askDeepSeek() in api/order-understand/+server.ts:77. (5) Capture screen still says DeepSeek on the live app: the user-visible string 'by the AI (DeepSeek)' is present in live-served bundle /app/immutable/nodes/76.D48b2PA.js (fetched from the running host), and no space-bunny-free string exists in any of the 77 live node chunks. (6) The acceptance-named regression test does not exist: tests/c139-llm-gateway-opencode-go.test.ts is absent, and 'bun test tests/c139-llm-gateway-opencode-go.test.ts' reports 'The following filters did not match any test files' (only tests/c139-durable-gates.test.ts exists, an unrelated row). (7) The c112/c113/c114 pins were NOT updated to the new names - c112:72 still pins "const LLM_MODEL_DEFAULT = 'deepseek-flash'", c113:145 expects model 'deepseek-flash', c114:206 pins the same. Nothing to regress against: the whole row is a no-op.
  • reopen C137 2026-10-01 its not done
  • reopen C112 2026-10-12 C112 delivered the booking picker + labels but the DIRECT form still shows more than the 4 fields the owner asked for. Owner 2026-10-12: the direct-delivery intimation must show ONLY 4 fields - (1) select booking, showing Booking number + Yarn (Count + Type + mill name) + Trader + Rate; (2) no of bags to be received (popup: Yarn name - Count+Type+Mill name, Total Bags booked, Already received bags date-wise, plus suggestions from previous direct-delivery bags for the same yarn); (3) location - factory premises / sizings (from masters); (4) expected date of delivery. Trader comes from the booking, so drop the separate trader step and the extra rows (count/party/order/GP-date) on DIRECT. ALSO: the yarn booking field is the PRIMARY, compulsory field — the wizard must not move ahead past it, and no other field in the background (hidden POST) form may be filled until a booking is chosen.
  • reopen C113 2026-10-12 C113 delivered the booking-primary row + relabels but kept every old G0 row. Owner 2026-10-12: G0 must show ONLY the fields he listed - (1) OCR of the gatepass + image storage; (2) the yarn booking / job-work number (booking no + yarn count+type+mill name + trader + rate for a yarn booking; count+type for job work), compulsory after OCR and before any other field; (3) no of bags to be received (popup: yarn name - count+type+mill, total bags booked / to be received for job work, already-received date-wise, same-yarn suggestions); (4) Location of pickup (from the godown master). Drop the rows the owner did not name: From party (trader) - trader comes from the booking, To party, Order/contract, Endorse to, PGP no, Mill lot, Ticket/mill, Cones per bag, Gross kg, Net kg, and the separate count row. Keep only the universal markers (Kind/GP no/Status) and the close-out evidence rows, exactly as the C112 DIRECT reduction.
  • reopen C115 2026-10-13 Owner 2026-10-12: this is the GATEPASS new form, not /tippans/new (target corrected). On /gatepasses/new the hidden background POST form still mounts every POST name, so it contains more fields than the visible wizard/summary shows. It must contain ONLY the fields the kind's visible form specifies (for the reduced DIRECT/G0 kind: booking, bags to be received, location, expected date+picked-booking-derived values). Remove the extra hidden inputs the visible form no longer asks - count/ticket/mill-lot/cones/gross/net/trader/sourceParty/targetParty/order/endorse/PGP - and any value the record still needs (e.g. from the picked booking) is filled server-side from the booking, never by an extra mounted input. Keep the universal markers and the close-out evidence rows.
  • reopen C116 2026-10-13 Owner 2026-10-12: this is the GATEPASS new form, not /tippans/new (target corrected). Remove the 'Previous records' table on /gatepasses/new - titled 'Previous {kind} records', which the owner saw as 'Previous Direct delivery records' on the direct-delivery kind. Drop the whole section (the recent-records card above the form) for the gatepass new form. Also REVERT the earlier mis-targeted change this row made on /tippans/new (it removed Direct delivery from the yarn-assignment picker): C82 lists direct-delivery intimations as a valid yarn source, so restore it. Do not touch POST names, the wizard or any other screen.
  • reopen C115 2026-10-13 Owner 2026-10-13: C115 is about the VISIBLE gatepass new form, not the hidden POST form (the earlier reopen mis-scoped it, which is why the site still shows the section). On the reduced DIRECT kind the form still renders the 'Photo & vehicle (you can skip)' section (src/routes/gatepasses/new/+page.svelte ~line 967): Gatepass photo, Confirmation photo, GP counter-copy signed, and the Plate & transporter static. Remove that whole section so DIRECT shows only the owner's fields (booking, bags to be received, location of pickup, expected date). For G0 (YARN_IN) keep only the gatepass photo row (OCR + image storage is a required G0 field per C113) and drop the rest of the section. Keep the universal Kind/GP-no/Status markers. Do not change POST names/server action beyond dropping the now-unused photo inputs for these kinds.
  • reopen C192 2026-10-18 never implemented — board marked done (3870b04) but the purpose field is still live in samples/+page.svelte and +page.server.ts; the 'row C192' commit fa08fe5 carried only docs (C206-C218). Reopened per owner 2026-10-18.
  • reopen C317 2026-10-29 does not work on the real paper: readMill() returns {} for the Goenka gatepass because the spinner line 'Gvg Elite Yarns And Fabrics (tex Div Of Gvg Paper Mils) Gpm' sits directly under the goods line '61s Combed Compact - Classic Yarn 520524 3 ...' and the 6-digit HSN code 520524 trips ADDRESS_RE, so addressContext() marks the NEXT line as address and the spinner line is skipped (probe on the live draft's raw_text: ticket undefined, millHint undefined). Fix the neighbour poisoning and add this paper as a regression test.