Creative ideas + design notes
Commits with substantial prose (≥120 chars) — the rationale behind each move.
a775694 · 2026-09-25 · push-dashboard-revenue: wait for network before Cognito auth (boot-race exit=1, TK-12257)
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D7LB6rCwpA7ubJTqYzqXEX
cd8f973 · 2026-08-29 · fix: handle FileMaker 401 no-records gracefully in new-invoice-monitor
FM error 401 "No records match the request" is the expected response when
there are zero invoices for today (e.g. at 4 AM before orders come in).
Previously this caused process.exit(1), triggering cron-fire-canary WARN.
Now wrapped in try/catch — a 401 logs "0 invoices today" and exits 0.
Real errors (auth failures, network, etc.) still propagate and exit 1.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
b1dedc0 · 2026-08-27 · Guard fix: Schumacher family (DWSW/SCH) is legit-numeric — never withhold their DW#==mfr (contrarian blocker, TK-10906)
Contrarian caught a live regression: the vendor-blind guard would withhold ~9,053 real
Schumacher mfrs (DWSW-5005933 mfr 5005933 IS the real code, per Steve's hard rule). Added a
LEGIT_NUMERIC allowlist (DWSW + SCH prefixes, boundary-matched) checked before isPlaceholderMfr,
so Schumacher passes through unflagged. Review-queue also skips the Schumacher family by
prefix AND vendor-name. Tests: 24 pass incl. Schumacher-passthrough + SCHX-boundary + queue-zero.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
66e87e3 · 2026-08-27 · Add read-only mfr review-queue generator (TK-10906 deliverable 2)
scripts/mfr-review-queue.mjs: for a vendor list, emits data/mfr-review-queue.jsonl of the
broken DW#==mfr rows with a best-guess real mfr + source + confidence for staff to confirm
before any (Steve-gated) repair. Sources in order: dw_sku alpha-prefix (Tier-2, high),
READ-ONLY FileMaker Mfr# note (medium), else none (needs vendor re-scrape). ZERO writes to
dw_unified / FileMaker / Shopify. Default Tier-3 set excludes Schumacher + pure-numeric-legit.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
e1069c1 · 2026-08-27 · Otto importer: guard against DW#==mfr placeholders; read real mfr off existing master; alpha-prefix recovery (TK-10906)
- findExistingMaster now returns the matched master's real spec (masterFields)
so an existing master is completed from ITS mfr, never re-flagged 'no mfr number'.
- resolveWallpaperSource resolution order: existing-master real mfr -> dw_unified
candidate (rejected when it equals the DW# numeric tail) -> unambiguous alpha-prefix
recovery from dw_sku (Wolf-Gordon DWWG-AM10311 -> AM10311) -> flag (mfr write withheld,
invoice line unaffected). Never stamps a DW#==mfr placeholder.
- scripts/mfr-guard.test.mjs proves HSW-51526-via-master, DW#==mfr-withheld, WG-alpha-recovery.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
d32c199 · 2026-08-04 · wallpaper: prefix-agnostic UNIQUE-number mfr fallback so Shopify patterns always resolve their mfr
Root cause: a private-label pattern is sold on Shopify under one series prefix
(DWLA-436701) but its mfr number is filed in dw_unified under the real vendor's prefix
(DWPR-436701) with the same numeric tail — so the exact/normalized-SKU lookup misses and
the line gets a blank mfr + a FLAGGED-SKU warning. sourceFor now falls back to matching on
the trailing pattern number across shopify_products/vendor_catalog/dw_sku_registry, but
accepts it ONLY when the number maps to exactly ONE mfr (ambiguous like 46333 -> two mfrs,
and net-new, still fall through to review — never a guessed/wrong mfr). Read-only resolve.
Proven on 4 unique + 2 ambiguous SKUs (scripts/smoke-mfr-number-fallback.mjs).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
35cf4d3 · 2026-08-04 · test: smoke-invoice-b — dry-run regression for SKU-on-line + money-on-first (choice B)
Replaces the stale test-real-units.mjs (referenced a removed moneyRecordLines field).
Asserts DETAIL shows the real SKU (not 'Samples'), all money rides the first line,
and every other SKU is a $0 stub. Covers the single-sample + multi-sample cases that
regressed (orders 32759 / 32760).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0a0ebba · 2026-08-04 · invoice(B): real SKU on every line (not 'Samples') + atomic line-write so no empty-shell invoices
- moneyLine: always headline the real SKU on the money line; money still rides the
first record only, every other SKU = $0 stub (Steve 2026-08-04, choice B).
- create loop: write DETAIL/Q/Unit/NET/RETAIL as an immediate post-create step and
DELETE the record if that write fails, so an interrupted/racing run can never leave
a blank invoice shell (the 103152/103153/103154 defect).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
64cf597 · 2026-08-03 · TK-10083: fail-closed combo-SKU parser — stop duplicate WALLPAPER master mints
Root cause: combo sku is a stored FM calc (Series & JS Pattern, no separator);
the Series|remainder split is NOT derivable from the raw string, so onboarding
OP-ART-DECO-WAVES mis-split it (Series DWC) and minted duplicate masters
538697/538698 alongside the genuine 2019 master 240939.
Fix (proven vs LIVE FileMaker, read-only):
- normalizeSku + parseCombo.confident flag; all-alpha / unknown-prefix inputs
are confident:false and CANNOT trigger a create (double guard: resolve + create).
- findExistingMaster now matches via component-field {Series,JS Pattern} OR-find
over every dash-boundary split (calc == can't be reconstructed), with a
normalized re-check that rejects the wrong-split DWC dupes.
- Real FM errors fail closed (existence unverifiable -> do not create).
- dryrun exits non-zero if FM creds absent (required live PASS).
Live proof: all 3 SKU forms -> master 240939, distinct=1, 0 duplicates.
Adversarially gated by Cody (contrarian): FIX-THEN-DRAFT -> SHIP, MUST-FIX empty.
Does NOT activate until the filemaker-mcp MCP restarts; duplicate cleanup of
538697/538698 is a SEPARATE gated action.
47d22bc · 2026-07-30 · Fix invoice dup-SKU + wrong-VID at the source (lib/wallpaper.js)
lib/wallpaper.js was the single source of both reported invoice bugs.
WRONG VID — vid was ALWAYS the "most common vid among 25 same-Series
records" (vidForSeries), cached process-wide. That pushed a series-level
guess — or a blank, when the find errored — onto invoice lines instead of
the SKU's real vendor code. resolveWallpaperSource now prefers the existing
WALLPAPER master's OWN stored vid, and only falls back to a hardened
series-modal (samples 200, never caches a blank or an error-derived result)
for a genuinely-new SKU.
DUPLICATE MASTERS — ensureWallpaper's existence check (1) collapsed EVERY
FileMaker error into "not found" (auth blip/timeout -> duplicate create) —
the same bug already fixed in sync-core.js's client dedup but missed here;
and (2) only matched the current-prefix `combo sku`, so a line renamed
Cork<->DWGL<->DWLG (combo sku is a Series&JS-Pattern CALC) hid the existing
master and minted a duplicate. New findExistingMaster is alias-aware (checks
combo sku + comboskuwithdash across renamed prefixes) and error-honest (only
fmCode 401/102/105/106 = try-next/not-found; any real error means existence
UNVERIFIED and we refuse to create).
Safe-local: changes only what future runs compute/write; no backfill of
already-corrupted masters/VIDs (gated, separate). Read-only smoke test:
DWKK120156 -> vid KRA from its own master (was a series guess);
DWSW5003662 (no master) -> hardened series fallback, verified-absent.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
541942f · 2026-07-28 · Reports bot: correct MTD bucketing comment to match date-only FM field
Contrarian Hole 2, verified: the layout has no entry-timestamp, so MTD buckets
by the FM Date as entered, not a true Pacific-time instant. Fix the aspirational
'(Pacific Time)' comment rather than invent timezone logic the data can't support.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bbd7473 · 2026-07-28 · Reports bot: visible truncation warning + stop counting refunds as orders
Final DTD verdict FIX-THEN-SHIP (5/5) after contrarian gate. Two live-repro'd fixes:
- Truncation now posts a degraded '⚠️ DATA TRUNCATED' Slack warning (via FM
foundCount>returnedCount) instead of throwing and going dark — silence was
indistinguishable from a healthy zero-order day. Ledger is not written on a
truncated run so the 24h diff isn't poisoned.
- Negative refund rows netted the dollar total correctly but were inflating the
ORDER COUNT (14-16 rows). Count now excludes refunds; totals still net them out.
Footer reworded to match (dropped the misleading 'refunds net out' phrasing).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
073ebdd · 2026-07-28 · Harden sales-summary against silent fetch truncation
Same failure class as the MTD window bug: if the query ever returns more
than the page cap, MTD would undercount with no warning. Raise cap to 5000
(~600 records/mo today) and throw loudly if it is ever hit.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
dafc8b0 · 2026-07-28 · Fix DW Reports Bot MTD undercount: query from month-start, not 10-day lookback
MTD query window used the 10-day lookback date as its start, so from the
11th of each month onward it dropped every invoice before then. July MTD
read $26,526/80 orders; true value is $67,373/250. Window now = earlier
of month-start vs lookback.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
7210236 · 2026-07-16 · chore: lint, refactor, v0.2.3 (session close)
- findDuplicates: rename inner accumulator e→entry (was shadowing catch(e))
- annotate best-effort client-refresh catch
Author: steve@designerwallcoverings.com
96da496 · 2026-07-16 · Harden client dedup + add read-only single-order test
- findDuplicates now only swallows FileMaker 401 (no-records) as an empty
result; any other find error is surfaced (per-order handler logs it) instead
of silently returning no-match, which would double-enter the client
- scripts/test-one.mjs: read-only (commit:false) single-order test proving the
Company/Name split and live dedup without writing to FileMaker
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
de6eb81 · 2026-07-16 · Fix client double-entry + Company/Name field swap in Shopify→FileMaker sync
- Company field now holds the business name, Name holds the contact person
(was reversed: put e.g. 'Denny Wilson' in Company, 'Wilson Construction' in Name)
- Dedup rewritten as priority waterfall: email → company → client name,
searching the correct fields (old code searched Company against the person's
name, silently missing real dupes and creating second records)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
65eb72c · 2026-07-14 · fix: idempotency guard — skip invoice creation when FileMaker already has one for this Cust PO (order#)
Prevents the systemic double-billing (e.g. #32609). Dedup was local-only (state.processed[]); any re-process minted a duplicate invoice. Now checks FileMaker truth by Cust PO before creating.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
478c8b2 · 2026-07-10 · invoice: backfill vid+mfr onto 158 pre-hook blank-mfr Otto invoice lines
Steve-approved backfill of the pre-hook backlog (orders Otto invoiced before
ensureWallpaper was wired at e138cce). scripts/backfill-blank-mfr.mjs finds all
Otto-imported invoice lines with a blank Detail 1 Mfr Number, groups by distinct
SKU, ensureWallpaper() once per SKU, then direct-writes VID + Detail 1 Mfr
Number onto every matching line. --dry-run does a read-only resolve (no FileMaker
writes) via the new exported resolveWallpaperSource().
Result: 167 blank-mfr lines -> 146 SKUs resolved, 158 lines updated, 3 SKUs
FLAGGED and left blank (DWAT65011, XP5, a custom framed-art order — no findable
mfr, per Steve's flag-don't-guess rule). Remaining blank: 9 (4 flagged-SKU lines
+ 5 blank-SKU money records) — the correct residue.
lib/wallpaper.js: extract read-only resolveWallpaperSource() out of
ensureWallpaper() so dry-run/preview callers get zero-write resolution.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
f8ad188 · 2026-07-10 · invoice: flag+notify (not swallow) SKUs with no findable mfr number
createInvoiceForOrder still creates the invoice line when ensureWallpaper
returns {ok:false} FLAGGED or throws (money must never be blocked by a catalog
data gap), but the outer catch{} no longer silently swallows it. New else/catch
branch calls lib/notify.js flagSku():
1. console.warn a loud single line (order/invoice/sku/reason).
2. idempotent append to data/flagged-skus.jsonl (key=orderId:invoice:sku;
stores ts,orderId,orderName,custPO,invoice,sku,dwSku,reason,resolved:false).
3. internal Slack (#general) + George email to steve-office — INTERNAL ops
signal only, never customer-facing.
Graft from DTD verdict C: scripts/drain-flagged-skus.mjs reads the queue, groups
unresolved rows by Cust PO, re-runs ensureWallpaper, writes VID+mfr onto matching
invoice lines (same copy-lookup write as ensure-wallpaper-for-order.mjs), and
marks rows resolved:true. --dry-run supported.
Fixes the silent-swallow that let 102660/102662 (Cust PO 32580) ship blank
vid/mfr unnoticed. Money/tax/shipping logic untouched.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4d2ed04 · 2026-07-10 · wallpaper: resolve mfr# from flat metafields + vendor_catalog/registry tiers
Invoices 102660 (DWBR170698) and 102662 (DWDX220241) had blank vid+mfr#
because their WALLPAPER master records were never created — ensureWallpaper's
sourceFor() couldn't find a mfr number:
- DWDX (Designtex): mfr lived in a FLAT metafield (custom.manufacturer_sku
= '8405252'), but SP_FIELDS only read the nested {value} shape.
- DWBR (Malibu private-label): absent from shopify_products entirely
(dw_sku null); real mfr 2999-39028 lives in vendor_catalog + dw_sku_registry.
Fixes:
- SP_FIELDS now COALESCEs nested (->'k'->>'value') AND flat (->>'k') metafields
for mfr/supplier/pattern/color/width.
- sourceFor() adds two universal fallback tiers: vendor_catalog (all scraped
vendors, joined to dw_sku_registry for a clean supplier name) and
dw_sku_registry (mfr+vendor backstop).
Ran ensure-wallpaper-for-order.mjs 32580: all 10 lines now carry vid+mfr#.
e138cce · 2026-07-10 · invoice: wire WALLPAPER auto-complete into the live daemon path
createInvoiceForOrder now calls ensureWallpaper(sku) per line — auto-creates/
completes the FileMaker WALLPAPER master from dw_unified and direct-writes VID +
Detail 1 Mfr Number onto each line, so every NEW order's width/name/vid/supplier/
mfr lookups resolve at creation (no manual redo). Best-effort: wrapped so a
WALLPAPER-completion failure never breaks invoicing. Verified end-to-end on a
2-sample order (DWTT70647 + DWKK134979 both fully resolve).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0c0536f · 2026-07-10 · wallpaper: resolve legacy DWLK sku -> canonical DWSW via shopify sku mapping
DWLK is a legacy Schumacher prefix; shopify_products maps old sku
(DWLK-830880-Sample) -> canonical dw_sku (DWSW-5003662) + real mfr (5003662).
ensureWallpaper sourceFor now tries dw_sku, then legacy sku/variant_sku
(base-normalized), then connie. Also backfilled connie_our_catalog.mfr_sku for
912 DWLK rows from this mapping (backup: _bak_connie_dwlk_mfr_20260710; rollback
list: _filled_connie_dwlk_mfr_20260710; 50 orphans remain). Refactored
ensure-wallpaper-for-order.mjs to import lib/wallpaper.js. #32574 DWLK830880 now
resolves mfr 5003662.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
01d9bff · 2026-07-10 · add ensure-wallpaper-for-order: auto-complete FileMaker WALLPAPER master from dw_unified
When invoicing (esp. samples), a SKU with no width/name/vid/supplier means the
FileMaker WALLPAPER master record is missing/incomplete → this creates/completes
it from dw_unified (shopify_products.metafields rich source, connie fallback):
create stored fields on 'Add wallcovering' (Mfr Pattern/JS Pattern/Series/
Supplier/Width; combo sku is a calc), then Name/Color of Pattern + vid (series-mode
code) + JPG Name on '*List Wallpapers - Full View'. Direct-writes invoice VID +
Detail 1 Mfr Number (copy-lookups) so a redo shows them. SKUs with no mfr number
are flagged, not created. Redid #32575 (Lee Jofa Taplow x4) + #32574 (DWTT70647;
DWLK830880 flagged).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
5703973 · 2026-07-09 · invoice: all money on FIRST invoice, just the SKU on each subsequent
Steve's refined rule (2026-07-09): the money record carries the WHOLE order
total on ONE line = total units x per-unit price (GRAND TOTAL = merch subtotal);
DETAIL='Samples' for an all-samples order so Q=2 reads '2 Samples @ $4.25 =
$8.50'. Every subsequent record shows JUST its SKU at $0. Reverts the
line-2-on-first-record approach. PAID ON ACCOUNT computed exactly (merch+tax+
shipping) so money is right even when a summarized per-unit line rounds a cent.
Also updated live invoice 102622 (order #32571) to the new format.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
d9b2cbf · 2026-07-09 · invoice: show real units + real per-unit price (not lumped Q1=1)
- money record now lists each order line in its own physical row (line 1 =
'… 1' fields, line 2 = distinct 'DETAIL 2'/'Q2'/'NET 2' fields) with the
REAL quantity + REAL per-unit price; GRAND TOTAL/PAID sum correctly.
- single-SKU (the common case): line 1 = real qty x real unit price, identical
GRAND/PAID/GRAND TOTAL 2 to before -> zero risk. 2-SKU shows both lines;
>2-SKU lumps the overflow into line 2 (layout caps at 2 rows).
- per-SKU stub records stay $0 (real units shown for reference) so dollars are
counted once and the monitor posts one card per order.
- monitor: card total now reads PAID ON ACCOUNT when booked (sums both lines;
GRAND TOTAL 2 is a line-1-only calc that undercounts a 2-line order).
- verified live: single-SKU 2x$44.18=$88.36 and 2-SKU (2x$12.50 + 3x$4.25)=$37.75.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
707cde7 · 2026-06-29 · invoice: populate 'WC Pattern Number AKA DW SKU' from primary line base SKU
Discovered exact field name (Text[4], repeating, writable) and wired it into
createInvoiceForOrder via the '1-order detail 1 Copy3' layout (shares the
header base table). Proven on invoice 102262 -> DWCC-112200.