AWS Motor Club App — Breakdown (LIVING DOC)

THIS FILE is the portable breakdown — the one that travels. It is what docs.appolis.app renders (the hub renders markdown at build time, so a published page can no longer lag the doc), what git diffs, and what anyone without an app login can read. Keep it current: it is the only version of this document the outside world ever sees.

/breakdown in the running app is a LIVE TWIN, not a mirror — it cannot be published. It fetches /api/config, /api/stats, /api/products and /api/dealers at runtime and its theme + term-rule editors write back (config/app-config.json / the term_rules table), so it is always true inside the app and worthless outside it: hosted anywhere else those relative fetches hit the wrong origin and the page renders as an empty shell whose write-back buttons POST into the void. That is exactly what happened when it was copied to docs.appolis.app; the published copy has been pulled and docs-hub/build.js now carries a ⛔ DELIBERATELY NOT COPIED note next to it. Two ways back onto the hub, both fine: (a) this markdown in the hub's renders list — the chosen route, and the prerequisite is met; or (b) a static snapshot export that bakes the API values in at build time (not built; see §9). Do not add web/breakdown.html to the hub's copies list.

Same rule as Flip CMS: this document is updated on every app change.

What it is: customer-service command center for AWS Motor Club (AWS = Addendum & Warranty Solutions) vehicle protection products: TireGuard — tire repair/replacement program; GlassGuard — windshield protection; ScreenGuard — a touchscreen-radio screen protector; more products to come. ✅ The old GlassGuard naming exception is resolved (v0.10.0): at Mercedes-Benz of South Orlando an employee had sold the touchscreen protector under the GlassGuard name, so every one of that dealership's GlassGuard registrations was really ScreenGuard. The owner decided (in writing) to rename them all, and the owner-clicked fix in #/imports › Data fixes moves them (dry run first, an audit row, a stored list of exactly which rows moved, and an Undo button). From then on that dealership's "GG" statements file as ScreenGuard; everywhere else GlassGuard means windshield and "GG" still means GlassGuard. Product copy, decks and new dealer setups keep the two names apart. Replaces the Google AppSheet + spreadsheet-pipeline setup: instead of dealership sheets being copy-pasted through staging spreadsheets into a master sheet, dealership data goes straight into a real database and every derived number (term, expiry, dealer profit) is computed by code.

Status: v0.18.0 — LIVE ON CLOUDFLARE at aws-motor-club.pages.dev (deployed 2026-08-17, migration first, then code). Real data: 8,136 customers, 10,733 registrations — 10,717 live plus 16 recorded as cancelled — after the Dec-2025 → Jul-2026 statement backfill (1,141 added, 144 repaired) and the 2026-08-18 AppSheet enrichment: 1,331 VIN-less legacy rows matched back to their AppSheet source (999 by contract number), every recovered VIN decoded to year/make/model, December-2025 cleared of its 123 double-counted placeholders, and 570 duplicate customer records merged so each person holds ALL their products on one profile. Remaining known specks: 8 rows whose AppSheet match was ambiguous, 4 VINs NHTSA cannot decode, 44 vehicles whose two products carry different surnames (family members or resales — left for human review). The live app is behind per-person login (§1.5): approved people only, each with their own password. Default theme is the ✨ New look (gloss-black shield, v0.5.0); ↩ Classic is one click away in the sidebar foot. Every registration carries a decoded year/make/model (v0.5.3). 30 claims ($9,831.10 paid — the AppSheet claims history landed 2026-08-18: 11 new claims imported, 12 legacy claims corrected for a doubling bug in the old master workbooks where the same amount sat in two columns, and 12 claims now correctly showing in progress per the dealer), 1 dealership (Mercedes-Benz of South Orlando), 14 F&I managers, 19 note activities carried over from AppSheet.

Version is single-sourced here. APP_VERSION in web/index.html (the badge + refresh prompt), package.json, this Status line, the top of §10, the deck (web/features.html), and the Program Numbers deck (web/present.html) must all read the same number. They drifted five ways once (badge v0.5.2 / Status v0.5.0 / changelog v0.5.3 / package.json 0.4.0 / deck v0.4.1) — if you bump one, bump all five. Two things only land after a command: the badge reaches users after npm run deploy, and the hub copy of the doc + deck only refreshes after node build.js && npx wrangler deploy in F:\Claude Code\docs-hub.

Brand palette (from the AWS logo): gloss black #101214/#17191c, silver #9ba1a6, bright green #63b32e (accents/active states), white cards.

1. Run / develop

• Run: cd "F:\Claude Code\AWS Motor Club"; npm start → http://localhost:8788 (zero deps, needs Node ≥22.5 for node:sqlite; Node 24.18 at C:\Program Files\nodejs\node.exe, not on PATH in some shells — use full path)
• Tests: npm test (87 tests across five files, node:test — node --test --test-reporter=tap test/<file> per file gives the pass/fail line)
• DB: SQLite at data/aws-motor-club.db (WAL). AWS_DB env overrides; seed only loads into an empty DB, so real data is never overwritten.
• Preview launch config: aws-app in F:\Claude Code\.claude\launch.json (port 8788; Flip CMS owns 8787).
• Cloudflare (v0.4.1, LIVE at aws-motor-club.pages.dev) — Flip CMS pattern, but deployed as a Pages project, not a plain Worker: Pages URLs carry only the project name (no account subdomain), which keeps "flipmylife" out of the AWS Motor Club URL (Tyler's requirement 2026-07-03; the old aws-motor-club.flipmylife.workers.dev worker was deleted after cutover).
• Async db facade server/lib/dbwrap.js (wrapNodeSqlite locally / wrapD1 in prod); server/api.js is runtime-agnostic (no node imports) and shared by server/server.js (node) and server/worker.js (fetch handler + APP_KEY cookie gate; app config lives in the app_config D1 table there, in config/app-config.json locally — injected via handleApi hooks).
• Deploy: npm run deploy (gate on green npm test first) = esbuild-bundle server/worker.js → web/_worker.js (Pages advanced mode; excluded from static upload) + wrangler pages deploy --branch main. Bindings (D1 + APP_KEY) come from wrangler.jsonc (pages_build_output_dir form).
• Do NOT rewrite / or /breakdown paths in worker.js — Pages pretty-URLs 308-redirect .html paths, which loops against rewrites; env.ASSETS.fetch(req) pass-through is correct.
• D1 aws-motor-club id 4b687ecd-7c0b-41f1-94ca-ec7719d8381d (ENAM), account tyler@spartanstudios.com (shared account is fine; only the URL needed separating). Data refresh: npm run export-data → npx wrangler d1 execute aws-motor-club --remote --file deploy/out/schema.sql -y then --file deploy/out/data.sql -y (data.sql is idempotent: defers FKs, wipes children→parents, re-inserts).
• Known nuance: the Worker computes "today" in UTC, so coverage flips at UTC midnight (can differ from local by a few registrations near the boundary).
• npx needs node on PATH in this shell: $env:Path = "C:\Program Files\nodejs;$env:Path".

1.5 🔐 Who can get in (v0.6.0, todo_1095)

The app used to sit behind ONE shared device key: anyone holding it was in, and the app could never tell who did what. That is gone. Access is now per person, and the account list is a closed allowlist — there is no self-registration anywhere in the app, so a stranger with a valid-looking email cannot create anything.

• Approved accounts live in the users table, seeded from ALLOWLIST in server/db.js: tyler@spartanstudios.com (Tyler Bradford) and matt@awsmotorclub.com (Matt Dunkle), both role admin. Adding a third person = add a row there AND run the same INSERT ... ON CONFLICT against prod D1. Seeding never touches an existing password_hash, so re-running it cannot wipe someone's password.
• First sign-in sets the password. A seeded account starts with password_hash = NULL ("unclaimed"); the first successful login for that email stores whatever password was typed, permanently. Nobody — including us — sets it for them.
• Passwords are PBKDF2-HMAC-SHA256, per-user 16-byte random salt, 100,000 iterations, 256-bit key. Only the derived key is stored, and verification uses a constant-time compare so response timing leaks nothing. ⚠️ 100,000 is a hard Cloudflare Workers ceiling, not a preference — Workers throws at runtime above it (a bare "error code: 1101") while Node happily runs any number, so a higher value passes every local test and fails ONLY in production. That shipped once, at 210k, on 2026-07-26. MAX_WORKERS_PBKDF2_ITERATIONS in server/lib/auth.js pins it and a regression test asserts stored iterations never exceed it. More work factor cannot come from raising this number.
• The only password rule is length: at least 10 characters. No required digits or symbols — that follows NIST SP 800-63B, which recommends against composition rules because they push people toward predictable shapes like Password1 while blocking strong passphrases.
• Sessions: 32 random bytes in an HttpOnly; SameSite=Lax; Secure cookie (aws_sess), 30 days. Only the SHA-256 of the token is stored, so a database leak cannot be replayed as a login. Signing out deletes the row; changing your password signs out every OTHER device.
• Wrong email and wrong password return the identical message, so the allowlist itself can't be enumerated.
• The gate (isOpenPath in server/lib/auth.js) leaves exactly the login surface open — /login, /api/auth/login, /api/auth/me, the icon and the manifest. Everything else, including /breakdown, /features and every /api/* route, needs a session: HTML redirects to /login, API returns 401.
• Everyone on the allowlist is admin and sees exactly the same app (Tyler's call, 2026-07-26). The role column exists for a future ladder, but nothing reads it today except the reset permission.
• The Account screen (#/account, reached by clicking your name in the sidebar) does two things: change your own password (needs the current one; signs out every other device) and reset a teammate's when they're locked out. A reset clears their password and kills their sessions, so their next sign-in runs the same claim flow they used originally. You cannot reset yourself — a hijacked session could otherwise lock the real owner out — and a reset can never create an account.
• Why an admin reset instead of a "forgot password" email link: there is no email provider wired up yet. Once the comms backbone is chosen (§6, Twilio/Telnyx), a real emailed one-time link becomes possible. Break-glass if BOTH admins are ever locked out at once: npx wrangler d1 execute aws-motor-club --remote -y --command "UPDATE users SET password_hash=NULL WHERE email='someone@example.com'". There is deliberately no standing bypass key.
• Secrets are no longer in the repo. ID_SECRET and GOOGLE_PLACES_KEY are encrypted Pages secrets; APP_KEY and ACCESS_KEY.txt were deleted outright. Set or rotate one from bash (never PowerShell — it appends CRLF and the value silently never matches): printf 'value' | npx wrangler pages secret put NAME --project-name aws-motor-club.
• The local dev server is no longer wide open. npm start binds to 127.0.0.1 only and runs the same login gate. It previously listened on every interface with no auth at all, publishing the whole member database to the LAN. HOST=0.0.0.0 still allows a deliberate device test and prints a warning.

2. Business rules (the important numbers)

Term length comes from what the product cost the DEALER (term_rules table):

• expires_on = deal_date + term_years. Coverage is active through the expiry date itself, expired the day after. Feb-29 deals roll to Mar-1.
• term_source: rule (price matched), default (product has no price rules — normal for GlassGuard), unmatched (product HAS rules but the price matched none → UI shows a "verify" badge).
• Product price is set at the DEALERSHIP level (dealer_products table, editable on the dealer page): what we charge that dealer per unit. The dealer sells at whatever price they choose; dealer profit = sale price − dealer cost. New registrations default their dealer cost from dealer_products when left blank (and term follows from it). Import backfilled MBSO: TireGuard $299, GlassGuard $185 (dominant observed costs) — after the v0.10.0 relabel MBSO's $185 is its ScreenGuard price (the GlassGuard price row stays, for any windshield sold later).
• GlassGuard vs ScreenGuard (v0.10.0): GlassGuard = windshield protection, ScreenGuard = touchscreen screen protector. dealer_product_aliases says what a sheet's "GG"/"TG" means AT a given dealer (effective dates honoured); the importer asks it through resolveProductCode() in server/lib/imports.js, so a dealer with no alias row behaves exactly as before. The relabel never changes money: dealer profit, sale price, dates and expires_on of every moved row are identical before and after (pinned by sum, per product and in total).
• Money stored as integer cents everywhere.
• Deal dates: future-dated cells in the sheets were month/day transpositions (12/1/2026 meant 1/12/2026) — fixDateSwap() in deploy/lib/xlsx-lite.js corrects them at import; zero future deal dates remain.

3. Data model (SQLite, server/db.js)

• products (code, name, default_term_years) + term_rules (product, dealer_cost_cents → term_years) — new products/prices are rows, not code.
• dealerships (name, city/state, phone, contact_name) + v0.9.0 slug (unique, the URL name), link_key (32-char private key printed on the dealer's QR sticker; Rotate key retires every old sticker), address/zip/lat/lng (geocoded through Nominatim), glass_program (1 = on the GlassGuard drive; defaults 0 for every dealer, an admin flags them on the dealer page), glass_contact_email, active.
• customers (first/last name, phone, email, address/city/state/zip, lat/lng) — dealership registration often arrives with LAST NAME + VIN only; full contact info is usually captured at claim time. UI treats missing fields as normal.
• registrations — customer × product × vehicle: deal_date, vin, year/make/model, fi_manager, dealer_cost_cents, sale_price_cents, dealer_profit_cents (derived), term_years / term_source / expires_on (derived via insertRegistration()).
• claims — registration_id, status pipeline new → in_progress → awaiting_customer → approved → closed_paid | closed_denied, issue, resolution, opened_at/closed_at. Status changes auto-log to activity.
• claim_items — the "what was actually done" ledger: action (repair/replace/roadside/reimburse/other), description, tire_position (LF/RF/LR/RR/SPARE), amount_cents, vendor, date. Claim payout = SUM(items).
• activity — timestamped notes/calls/texts/emails per customer and/or claim (replaces the AppSheet notes blob).
• roadside_vendors — vendor directory: phones, city/state/zip, lat/lng, coverage radius, services, our 1–5 rating, times_used, notes, and category: 'ranger' (on-location operator who goes TO the customer — Tyler's definition of a Road Ranger) vs 'shop' (fixed drop-off location). The two categories are separate sections in the UI.
• v0.9.0 foundation tables (the windshield leg stands on these; P0 creates them all, later phases fill them):
• media — metadata of record for every stored photo/sketch/licence image (kind, mime, bytes, sha256, sensitive, purge_after, who/what it belongs to); the BYTES live in R2 (MEDIA binding, bucket aws-motor-club-media) in production and in data/media/ locally. media_access — one row per admin view of a sensitive (licence) image.
• outbox — every email/SMS the app wants to send: recipient, subject, text + HTML body, attachments (media ids), status queued | held | sent | sent_by_hand | failed, provider fields for when a delivery provider exists.
• public_hits (rate-limit counters, hashed IPs only) · vin_cache (one NHTSA vPIC lookup per VIN, ever).
• glass_inspections (a glass pro's drive-by inspection) · glass_leads (a customer's own claim start) · appointments · dealer_product_aliases (what a statement code like "GG" means AT a given dealer) · customer_sessions (the customer-portal cookie, filled since v0.13.0). Empty until P1–P4 (P1 / v0.10.0 puts the MBSO "GG" → ScreenGuard row in dealer_product_aliases).
• New columns: claims.source / lead_id / inspection_id, import_batches.rollback / external_source. New product row SCREENGUARD (ScreenGuard, 1-year default) — the touchscreen protector MBSO's sheets call "GG"; v0.10.0 moved MBSO's former GlassGuard registrations onto it (see §2).
• v0.11.0 uses, no schema change: glass_inspections is now written by POST /api/public/glass (one row per submission: dealership, pro, customer, VIN/vehicle, damage_types = JSON list of the six fixed codes four_plus_chips · line_of_sight · through_and_through · delamination · frit_band · failed_prior_repair, sketch_media_id, photo_media_ids, service repair|replacement, walk_in always 1 today, oem Y|N filled from At Home's returned sheet, registration_id + claim_id only when GlassGuard coverage matched). media rows of kind sketch, photo (ref_kind glass_inspection, purge 400 days) and csv (the weekly sheet, ref_kind glass_week); outbox rows with ref_kind glass_inspection / glass_week; claims.source = 'glass_pro' with inspection_id; a matched inspection adds ONE claim_items row (action = repair for Repair, replace for Replacement, amount 0, item_date today).
• The 2-repairs rule (I7) counts claim_items.action = 'repair' on claims whose registration has the same VIN and a GLASSGUARD product, item_date inside the current CALENDAR year, skipping claims in status closed_denied; must_replace when the count is 2 or more.
• v0.12.0 uses, no schema change: glass_leads is now written by POST /api/public/claim (token = a 32-character random link key for /appt; dealership_id = the dealership the customer bought from, NULL for "Other / not sure"; registration_id only when GlassGuard coverage matched the VIN AND last name; damage_media_ids = JSON list of 1–3 photo ids; licence_media_id; nearest_dealership_id + nearest_miles; repair_count_year + must_replace as they stood at submission; status runs new → hot_lead_queued → called → appointment_set → closed | rejected; closed_at is stamped when a request is closed or rejected and cleared if it is reopened). media rows of kind photo (ref_kind glass_lead, purge 400 days) and licence (sensitive = 1, purge_after NULL while the request is open, closed_at + 90 days once it is closed or rejected); outbox rows with ref_kind = 'glass_lead' (the HOT LEAD to config.atHomeInsideSalesEmail, the customer's "we got your request", the customer's appointment confirmation); claims.source = 'funnel' with lead_id; appointments rows (set_by = the signed-in email, or "At Home (appointment link)"). The GlassGuard network is the dealerships with glass_program = 1, active, and coordinates — none are flagged yet (the owner supplies the list), so no nearest dealer is offered today. New config key glassRerouteMiles (default 25; POST /api/config accepts 1–500).
• v0.13.0 uses, no schema change: customer_sessions is now written by POST /api/public/portal/login (token_hash = SHA-256 of the random cookie token, never the token; customer_id = the ONE customer the sign-in matched; expires_at = 7 days; rows past their week are deleted on every sign-in). The portal also reads registrations.contract_no (the number printed on the customer's AWS paperwork, e.g. MBSO-TG2022-0002) as a sign-in fact. claims.source may carry portal in future; nothing writes it yet.
• feed_contracts (id, source, external_id, registration_id, created_at, UNIQUE(source, external_id)) — v0.14.0: the idempotency key of the dealer-feed landing; one (sending system, its contract id) maps to exactly one registration, so a re-send can never file a second one. import_batches gains rows with mode='feed' (external_source = the sending system; rollback = JSON lists of the registration / customer / feed_contract ids it added and the ids it updated).

4. API (all JSON, server/api.js)

• GET /api/search?q= — one box searches first/last name, phone, email, VIN, address/city/state/zip, dealership name, make, model, year, contract #.
• GET /api/customers?q&sort&dir&coverage&product&claims&page&per — the full list: server-side sort (name/city/regs/last_deal/next_expiry/open_claims/ coverage), filters, pagination, totals.
• GET/POST/PATCH /api/customers/:id, POST /api/customers — card = customer + registrations (+coverage) + claims (+items, payouts) + activity + totals.
• POST /api/registrations — derives term/expiry/profit on insert; dealer cost defaults from dealer_products when omitted.
• GET /api/dealers/:id/report?group=month|quarter|year|manager|product|manager_product &from&to&products&managers — the report engine behind the dealer drill-down.
• POST /api/dealers/:id/pricing — upsert per-product dealer cost.
• GET /api/roadside/discover?customer_id|city,state,zip|lat,lng[&radius][&kind=shops|mobile] — auto-discovery: Nominatim geocode (customer coords persisted back) + distance-ranked results with in-directory flags. kind=shops = tire/repair shops (Overpass tags). kind=mobile = Road Rangers, TWO engines merged: (a) Overpass tag pull (tyres/car_repair/towing tag + craft/car_parts/ truck_repair/office=company for mobile) filtered by MOBILE_RE in code — Overpass case-insensitive name regexes are unusably slow, don't reinstate; (b) bounded Nominatim free-text ("mobile tire", "roadside assistance", "towing", "mobile mechanic", sequential w/ 400ms gaps per usage policy), gated by MOBILE_STRICT_RE to keep fuzzy junk out. Duplicate names merge, filling missing phone/website across sources. Default radius is 20 mi for BOTH kinds (user report 2026-07-31; was 60 mobile / 40 shops — a wide default buried the closest help, which is the whole point when someone is stranded). The picker still offers 20/40/60/100 for rural gaps. kumi.systems Overpass mirror fallback. GET/POST /api/roadside take category (ranger|shop); near filters by it.
• GET /api/comms — recent conversation threads. POST /api/activity takes direction (in/out).
• GET /api/claims[?open=1], POST /api/claims, PATCH /api/claims/:id (status/issue/resolution), POST /api/claims/:id/items.
• POST /api/activity — log note/call/text/email.
• GET /api/dealers, POST /api/dealerships, GET /api/dealers/:id/report?granularity=month|year — Program Overview data.
• GET/POST/PATCH /api/roadside, GET /api/roadside/near?customer_id=|city=&state=&zip= — haversine when both sides have lat/lng, else state→city→zip-closeness fallback (server/lib/geo.js).
• GET /api/products, GET /api/stats (dashboard; by_product now has three rows).
• v0.10.0 POST /api/maintenance/relabel-screenguard {dry_run, dealership_id, cutover} (admin only) — dry_run:true (the default) returns {registrations, batches, dealer_products, first_deal, last_deal, profit_cents, active, unwound, already_applied} and writes nothing; dry_run:false moves exactly those registrations GlassGuard → ScreenGuard, moves that dealer's statement batches, copies its GlassGuard price to ScreenGuard, adds the alias, and files one import_batches row mode='relabel' whose rollback JSON holds the exact id lists — all in one all-or-nothing db.batch (D1 batch() in production, BEGIN…COMMIT locally); a second commit is 409 already applied. cutover:"YYYY-MM-DD" (null = every row) limits it to earlier deals and ends the alias the day before. POST /api/maintenance/relabel-screenguard/rollback {batch_id} puts the stored ids back and refuses (409, naming the ids) if any was changed to something else since. Id lists travel as one JSON parameter read with json_each(), so the move is five statements however many rows. server/lib/relabel.js.
• v0.11.0 the glass pro's public routes (all need the sticker's d slug + k key; a wrong pair is 403, and a dealership does NOT need glass_program = 1 — the key is the authority): GET /api/public/dealer?d=&k= → {name} only · POST /api/public/coverage {d,k,vin,last_name} → {found, product, repairs_this_year, must_replace} and nothing else (found only when the VIN AND last name match a live GlassGuard registration; ScreenGuard, expired and unwound contracts are "not found"; rides the vin rate counter and spends no Turnstile token) · POST /api/public/glass → 201 {reference:"GI-<id>", coverage, claim_id?} — validates everything first (VIN rules, ≤ 6 distinct damage types from the fixed six, sketch PNG/JPEG ≤ 300 KB, 1–6 photos each ≤ 1.5 MB, repair|replacement, consent Y/N with phone + email required on Y), refuses Repair when must_replace, then writes media + inspection + claim + the two outbox rows in one request; any failure undoes that request's own rows and fails the request (500), a refusal is a 4xx sentence naming the field.
• v0.11.0 admin (signed-in): GET /api/glass/inspections (newest 300 + the current week's walk-in count and last-queued time) · GET /api/glass/inspections/:id (all fields, damage labels, 1-day signed links for the sketch and photos, the claim, the registration, the two outbox rows) · PATCH /api/glass/inspections/:id {oem:"Y"|"N"|null} · GET /api/glass/walkins?from&to (default: this Monday–Sunday) → {rows, count, csv, last_queued} with the CSV header Inspection,Date,Dealership,Pro,VIN,Year,Make,Model,Service,OEM (Y/N) (replacement + walk-in inspections only; text cells starting = + - @ are defused) · POST /api/glass/walkins/queue {from?,to?} → stores the CSV as media kind csv, queues an Outbox email to atHomeInsideSalesEmail with the CSV as a 30-day signed link (400 when the week is empty).
• v0.11.0 static (open, no login): /glass (the form), /glass/manifest.webmanifest and /glass/sw.js (the installable app — the service worker is served with Service-Worker-Allowed: /glass, added by server/lib/pwa.js in both server.js and worker.js, and caches only the page shell, never API traffic), plus the PNG home-screen icons under /glass/.
• v0.12.0 the customer's public routes (no login; every POST is honeypot-checked and rate-limited like the glass pro's): GET /api/public/dealers → {dealers:[{id,name}]} — active dealerships by name only, for the /claim and /appt dropdowns (never slugs, keys or addresses) · POST /api/public/claim {dealership_id|'other', vin, first_name, last_name, phone, email, zip?, consent:true, damage_photos:[1–3], licence_photo} → 201 {reference:"GL-<id>", coverage:{found, repairs_this_year, must_replace}, nearest:{name, miles}|null} — validates everything first (VIN rules, phone of at least 10 digits, email, 5-digit ZIP, the consent box, 1–3 damage photos and exactly one license photo, each ≤ 1.5 MB JPEG/PNG), then writes the lead + media (the license sensitive = 1) + the claim when covered + the HOT LEAD and customer outbox rows in one request; any failure undoes that request's own rows (I6). The ZIP is geocoded server-side (Nominatim) only when the network has a dealer; a failed lookup is not a failed submit — the HOT LEAD email says the nearest dealer "could not be worked out" · GET /api/public/appt?t=<token> → first name, vehicle, purchasing dealer, coverage + counter, nearest dealer, used, and the dealer dropdown — never phone, email, VIN or license; a bad token is 404 · POST /api/public/appt {t, kind:'repair'|'replace', location_kind:'dealer'|'mobile', dealership_id | mobile_address, scheduled_for:'YYYY-MM-DDTHH:MM', notes?} → 201 (appointment + the claim item dated that day + the customer's confirmation in the outbox + the request moves to appointment_set); bad token 404, an appointment already set (or the request closed) 409, repair when must_replace 400 with the reason, a date in the past 400. The token is the credential, so this route spends no Turnstile token (it is still rate-limited).
• v0.12.0 admin (signed-in): GET /api/leads · GET /api/leads/:id (fields, live coverage, nearest dealer, 1-day signed damage-photo links, the license as an id only — NO link —, the claim, the appointment, the outbox rows and the appointment link) · PATCH /api/leads/:id {status} (any stage except appointment_set, which only an appointment reaches; closed / rejected stamp closed_at and set the license purge_after 90 days out, reopening clears both) · POST /api/leads/:id/appointment (the same write as /appt, signed in, set_by = your email). The license photo is read only through GET /api/media/:id (admin session; one media_access row per view).
• v0.12.0 static (open, no login): /claim (Start a claim) and /appt?t=<token> (set the appointment) — plain pages, not installable apps. /claims and /api/claims stay closed (pinned).
• v0.13.0 the customer portal (no login; cookie aws_cust, a SEPARATE trust boundary from the admin aws_sess: sessionUser() never reads it and the portal never reads aws_sess; pinned in test/portal.test.js): POST /api/public/portal/login {vin, last_name, contract_no | phone_last4 | zip | proof} — the VIN, the last name AND one more fact: the contract number on one of that customer's registrations for that VIN (compared ignoring case, spaces and dashes), the last 4 digits of the phone on file, or the first five digits of the ZIP on file (proof is the page's single box and may be any one of the three; a wrong extra fact fails the whole sign-in). Every miss — unknown VIN, wrong name, wrong fact, or a customer with nothing on file to check against — is the SAME 401 {error:"We could not confirm those details — call AWS or start a claim."}; missing pieces are 400; unwound registrations never match. Rate limits: portal_login 8 per 10 min per connection (the 9th is 429) plus a ceiling of 20 attempts per VIN per hour across every connection; honeypot → silent 204; Turnstile is required when TURNSTILE_SECRET is set. Success sets aws_cust (random token, only its SHA-256 stored, 7 days, HttpOnly, SameSite=Lax, Path=/, Secure over https). config.portalAuth = 'knowledge' (default) or 'otp': with 'otp' and no text/email provider the sign-in answers 503 naming todo_684 — it never falls back to the weaker road (any other value is 503 too). POST /api/public/portal/logout deletes the row and clears the cookie. GET /api/public/portal/me → ONLY that customer: customer, products (product, VIN, vehicle, dealership name, deal date, expires_on, coverage active | expiring (inside 60 days of the end) | expired | unknown, contract number, and on GlassGuard products repairs_this_year / repair_limit 2 / must_replace), claims (number, status, issue, product, VIN and items with action, date and — unless config.portalShowAmounts === false — amount_cents), start_claims / start_claim (the prefill for /claim: VIN, name, phone, email, ZIP, dealership id; GlassGuard vehicles only, live contracts first) and contact. Unwound registrations and their claims are left out; no row id of anyone else's is ever present. New config keys portalAuth and portalShowAmounts (defaults 'knowledge' and true).
• v0.13.0 static (open, no login): /portal (the customer's page); /claim?prefill=1 reads the portal session (GET /api/public/portal/me) to fill its own form — no personal detail ever goes into a URL.
• POST /api/contracts/import — v0.14.0 dealer-feed landing. Auth: an admin session OR header x-feed-key = DMS_FEED_KEY (constant-time compare; key unset → 503; wrong/missing → 401). The session gate has exactly one exception: a POST of this exact path carrying a non-empty x-feed-key header is let through to the handler (any other method/path/no header is gated as always). Body {source, adapter, dry_run, contracts[]} (≤ 500 contracts, ≤ 8 MB → 413); only an explicit dry_run:false writes. Response {ok, dry_run, source, adapter, plan:{inserts, updates, unwinds, skipped_duplicates, unmatched_terms}, errors:[{index, external_id, field, path, message}], rows, batch_id}. Idempotent on (source, external_id), then (vin, product, deal_date). Adapters in server/lib/feed.js: generic-json live; pen, fi-menu → 501. Spec: FEED-CONTRACT.md.
• GET /api/feeds/status (signed in) → {endpoint, key_set, max_contracts, adapters} — never the key itself. POST /api/contracts/rate and /api/contracts/void — signed-in only, 501 "not built yet" (PEN-shaped slots).
• v0.9.0 GET /api/outbox[?status=] · GET /api/outbox/summary (queued/held/failed counts, turnstile and provider flags — feeds the sidebar badge and the amber line) · GET /api/outbox/:id (full row + signed attachment links) · PATCH /api/outbox/:id {status:"sent_by_hand"} · POST /api/outbox/:id/retry (503 "no delivery provider is configured — todo_684" until an adapter exists; never a silent queue) · POST /api/maintenance/purge-media (admin; deletes media past purge_after, returns the list; runs when #/outbox opens).
• v0.9.0 POST /api/dealerships now takes address, zip, glass_program, glass_contact_email, geocodes, and issues slug + link_key; PATCH /api/dealerships/:id edits them ({rotate_key:true} issues a new key, {geocode:true} re-runs the lookup); GET /api/dealers/:id and the report carry slug, link_key, glass_url (/glass?d=<slug>&k=<key>, relative).
• v0.9.0 the PUBLIC boundary — the only paths reachable without a login are the login surface plus /api/public/, /glass, /claim, /portal, /appt and the signed media links /m/<id>/<expiry>.<sig> (/api/stats, /api/media/, /api/outbox, /api/maintenance/, /claims and /api/claims stay closed; pinned in test/foundation.test.js). Every public POST is honeypot-checked (field website → silent 204), rate-limited per connection (submit 6 per 10 min; vin 12; portal_login 8; IPs stored only as keyed hashes), Turnstile-verified when TURNSTILE_SECRET is set (fail-visible amber line in #/outbox when it is not), and capped at 8 MB (413). GET /api/public/vin/:vin → year/make/model (cached, check-digit validated), GET /api/public/config → the Turnstile site key. GET /api/media/:id (admin) serves stored images; a sensitive one needs an admin and writes a media_access row first. Config adds opsEmail and atHomeInsideSalesEmail (both default info@awsmotorclub.com) and turnstileSiteKey, editable on /breakdown.

5. UI tour (web/index.html, vanilla JS, hash-routed)

• Dashboard — customers, registrations, active coverage, open claims, total claims paid, dealer profit generated, per-product active/expired.
• Customers — the FULL master list, always visible: sortable column headers (▲▼), coverage/product/open-claims filters, search box (state lives in the hash, so views are linkable), 50/page pagination; new-customer form.
• Customer card — expired = UNMISSABLE (full-width red banner; green banner when active), coverage panels with contract #, VIN/deal/term/F&I/costs, Google Maps embed when an address exists ("no address yet" is normal), claims with item tables (tire position!), status dropdown, add repair/replace item, Communications & notes chat thread + composer (text/call/email/note, in/out — everything stays in-app, no tel:/sms: bounce; Grasshopper send/receive pending), and a green Find roadside help button.
• Claims — open-claims pipeline table (toggle to all); click-through to customer.
• Comms — recent conversation threads across all customers.
• Dealerships — list with units + profit; click → the report builder: group by month/quarter/year/manager/product/manager×product, date range, product + F&I manager filters, sortable columns, totals row, avg profit/unit, print → PDF, 📊 Present (the Program Numbers deck at /present?dealer=<id>) · ⬇ CSV. Includes the Program pricing panel (per-product dealer cost, drives registration defaults + term rules).
• Imports › Data fixes (v0.10.0) — under the upload box: pick the dealership (Mercedes-Benz of South Orlando is pre-selected), Check what would change shows "2,379 registrations · first deal → last deal · $ dealer profit · N active · M import batches" and saves nothing; Move them to ScreenGuard only unlocks after a check, asks a styled confirm that repeats the count, then shows the result and an Undo this relabel button (which also reappears whenever the page is opened while a relabel stands). Customers › Product filter and badges, the dashboard, reports and the Program Numbers deck all show ScreenGuard as the third product.
• Import statements now has two tabs: Statements (as before) and Dealer feeds (data-tab="feeds"): the endpoint URL, "Feed key: set / not set" (never the key), a paste-JSON "Check this payload" box (dry run only — it cannot save), and a "Contracts received" table of feed batches.
• Outbox (v0.9.0) — sidebar item with a count badge (queued + held + failed). Tabs Queued / Held / Sent / Failed; open a message to read the text and see how the HTML version looks; 📋 Copy (subject + body + attachment links), ✅ Mark sent by hand, ✉ Retry (greyed until a provider exists). An amber line says when public forms run without Turnstile; opening the page also runs the media-retention sweep and reports what it removed.
• Glass inspections (v0.11.0) — sidebar item after Outbox. A line at the top: "Week of Mon Oct 26 — N walk-in replacements — last queued <date>" (amber with "due" when the week has walk-ins and nothing was queued for 7 days) with ⬇ CSV and ✉ Queue this week's sheet to At Home. Below it the inspections table (inspection, when, dealership, glass pro, customer/vehicle, service, claim opened or "no coverage", and an inline OEM Y/N box on replacements); click a row for the detail page: pro and customer, coverage and the claim, damage types, the drawing and photos (click to enlarge), and the two emails it created.
• /glass — the glass pro's page (v0.11.0), phone-first, not part of the admin app: dealership shown as text with a "change" link, the pro's name/email remembered on the phone, the form in Lithia's order (customer + consent, VIN with Decode and the live coverage banner, six damage chips, the windshield drawing with Undo / Clear all, camera photos with thumbnails, Repair / Replacement with the warnings), a progress bar while it uploads, and a "Submitted — reference GI-n" screen. With no sticker link it says "Scan the GlassGuard QR at your dealership" and lets the pro paste the link instead.
• Leads (v0.12.0) — sidebar item after Glass inspections. Tabs by stage (All · New · HOT LEAD sent · Called · Appointment set · Closed · Rejected, each with a count) over a table of request, when, customer and VIN, bought at, coverage ("covered" with "n of 2 repairs", or "no coverage"), nearest network dealer and status; click a row for the detail page: stage buttons (a line says closing starts the 90-day clock on the license photo), customer and vehicle, coverage and claim, damage photos, the license behind View licence (logged) (it says how many views are logged and when the photo will be deleted), the appointment — or the staff form (Repair / Replace, dealer or mobile, date and time, notes; Repair is greyed with the reason when two repairs are used) plus a "copy that link" for At Home's version — and the emails the request created.
• /claim — Start a claim (v0.12.0), phone-first, same look as /glass: a dealership dropdown (every active dealership by name, plus "Other / not sure"), name, phone, email, ZIP, VIN with a Look up button, 1–3 damage photos, one driver's-license photo with a plain "why we ask and who sees it" box, the consent tick-box, a progress bar while it uploads, and a "We got your request — AWS will call you to set the appointment" screen with the reference, the coverage sentence and, when there is one, the nearest GlassGuard dealer. /appt (v0.12.0) is At Home's page: the request's facts, Repair / Replace, dealer or mobile, date and time, notes.
• /portal — My coverage (v0.13.0), phone-first, same look as /claim: a sign-in card (VIN, last name, and ONE box labelled "Contract number (on your AWS paperwork) — or the last 4 of your phone, or your ZIP"), then My products (each with a green Active, amber Expiring or unmistakable red EXPIRED badge, the dealership, the contract number, and on GlassGuard "1 of 2 repairs used this year" — amber when both are used), My claims (status and what was done, with amounts unless the owner switches them off), Start a claim (one button per GlassGuard vehicle, opening /claim already filled in) and Sign out; AWS's contact is plain text only (no tel:/mailto: links). Why the contract number: read-only counts of production on 2026-10-26 found that of 8,261 customers only 4 have a usable phone, none has a ZIP and 1 has an email (registrations arrive with name + VIN only), so a phone/ZIP-only sign-in would work for almost nobody; 9,470 of 10,978 registrations carry a contract number, which is printed on the customer's paperwork. A customer with none of the three on file cannot sign in by design and is told to call AWS or start a claim.
• Dealer page → "GlassGuard on the drive" (v0.9.0) — program toggle, service contact email, address/ZIP with 📍 Geocode, the dealership's QR code (drawn in the browser by web/lib/qr.js, a zero-dependency encoder), the link in a copyable box, 🔁 Rotate key (the confirm says every printed sticker stops working) and 🖨 Print sticker sheet (six stickers, "GlassGuard — scan to start a repair or replacement"). /glass is a placeholder page until P2.
• Road Rangers — ON-LOCATION operators only (Tyler 2026-07-03: "people that will go on location to the person and help them get the repair facilitated and bring what they need to them"): curated directory + find-near + auto-discovery in mobile mode (towing/mobile/roadside operators). OSM under-maps one-man mobile outfits, so Google Maps hunt links + Tyler's phone contacts are first-class sources here.
• Tire Shops — separate tab for fixed drop-off shops (driveable vehicles): same find-near + auto-discovery (shops mode) + its own directory (category='shop'). Cross-links between the two sections preserve the customer/location being searched.
• List ↔ Map toggle (both vendor sections, when a target is set): Leaflet + OSM tiles (CDN, lazy-loaded, no API key). Red = customer/target, green = saved vendors, blue = discovered, dashed ring = search radius; popups carry phone (tel:), distance, and a save-to-directory button. View state lives in the hash (&view=map).

6. Integration seams (not built yet)

• Comms backbone — ⛔ GRASSHOPPER IS OUT. Confirmed 2026-07-17 (board todo_684): Grasshopper has no API at all, so the in-app calls + texting hub needs a different provider. Candidates: Twilio (reliability-first, ~$1.15/mo per number, ~$0.008/SMS, ~$0.014/min voice) or Telnyx (same capabilities, roughly 30–50% cheaper). Both can port the existing Grasshopper numbers (1–2 weeks, zero downtime if scheduled) and both handle A2P 10DLC registration, which is required for business-texting deliverability. Middle path if staff also want a normal phone app alongside the in-app hub: OpenPhone (~$15–23/user/mo, API is shallower). Blocked on Tyler picking a provider and opening the account. Since v0.9.0 every outgoing message is an outbox row (#/outbox: copy it, send it from your own mail, mark it sent), and the delivery slot is hooks.mailAdapter in server/server.js / server/worker.js — an adapter is one file in server/lib/providers/ (contract in its README), written when todo_684 is decided; until then Retry says so instead of pretending.
• Google Places (LIVE 2026-07-05, key configured) — third discovery engine in server/lib/places.js: Text Search (New) with rankPreference: DISTANCE (surfaces small independents over prominent chains) + per-kind query sets (rangers: mobile tire repair / towing service / roadside assistance / mobile mechanic; shops: tire shop / used tires / tire repair shop). Returns verified phone, website, hours, rating + review count (Enterprise SKU fields — ~1k free calls/mo, then ~3.5¢/call; ~4-7 calls per discovery click). Key lookup (lazy, no restart needed): local = GOOGLE_PLACES_KEY env or config/secrets.json.googlePlacesKey; cloud = Pages secret GOOGLE_PLACES_KEY (npx wrangler pages secret put GOOGLE_PLACES_KEY --project-name aws-motor-club). Without a key everything falls back to OSM and the UI says so. GOTCHA: pipe the secret via bash printf (PowerShell piping appends CRLF → "API key not valid" 400s); worker also trims the value defensively.
• Category gates (v0.4.5) — EVERY discovery result from EVERY engine must pass rangerAccept / shopAccept (places.js): NEGATIVE_RE kills computer/phone/appliance/car-wash/mobile-home/etc. (Tyler saw a mobile computer repair shop in Road Rangers); rangers additionally require a towing type/tag or an on-location vehicle-service name; shops require tire/auto signals. Gate cases are unit-tested — extend the tests when adding patterns.
• Geocoding — Nominatim with full→coarse→zip fallback; customer coords persisted on first discovery.
• VIN decode (SHIPPED v0.5.3) — deploy/decode-vins.js backfills year/make/model from the VIN via the free NHTSA vPIC batch API (50 VINs per POST, polite gaps). It only touches rows missing BOTH year and make, so re-runs never clobber hand-entered vehicles, and one decode fans out to every registration sharing that VIN. All 9,715 registrations now carry a vehicle.

7. Spreadsheet import (DONE 2026-07-03)

Both master lists (intake/*.xlsx, sheet "MASTER For APP") imported by deploy/import-masters.js using deploy/lib/xlsx-lite.js (zero-dep xlsx reader; needs the file expanded as a zip first). Columns are located by header title, not position. Actual layout (identical in both files): Dealership · Deal Date · Deal Number · VIN · F&I Manager · Customer Name (one full-name column, ALL CAPS, sometimes company or bare last name) · Dealer Cost · Sale Price · Dealer Profit · Term · "TG Customer #" (→ contract_no) · Status · Date of Last Claim or Service · Customer Email/Phone/Address · Notes · 1st–5th Service or Claim Amount · Total Amount Paid · Claim In Progress (· Front/Rear Tires, TireGuard only, empty).

Import rules that matter:

• Rows with no name+VIN+date are skipped (arrayformula artifacts: 238 TG, 4,196 GG).
• Customers merge by VIN always; by name only when multi-word (a bare "LEE" must not fuse different people). Fleet LLCs legitimately hold up to 8 vehicles.
• Names parsed to first/last via server/lib/names.js (companies kept verbatim).
• Term/profit recomputed from §2 rules; sheet values cross-checked. Results: 0 profit mismatches, 0 term mismatches, 586 status mismatches (sheet says EXPIRED where live math says active — same-day-expiry boundary + stale sheet formulas; the app's computed status is authoritative). 1 row ($299.30 cost) fell back to the sheet's term (term_source='sheet').
• Claim amounts → one claim per row with per-amount claim_items; "Claim In Progress" → status in_progress (3 open). Notes → activity.
• Re-run: expand both xlsx to folders, then node deploy/import-masters.js --tire <dir> --glass <dir> --wipe (refuses to touch a non-empty db without --wipe). node deploy/check-import.js prints a sanity report.

Known source-data quirks (imported faithfully, worth cleaning over time): junk contact cells (e.g. an email of "51"), a handful of future deal dates (e.g. 2026-12-01), GlassGuard dealer costs vary ($185 dominant, $399/$599 strays — all 1-yr by product default, so harmless).

8. OPEN ITEMS FOR TYLER

1. Pick the comms provider (Twilio or Telnyx — Grasshopper has no API, see §6) and open the account. The comms hub is built and logging; wiring real send/receive is the next big piece, and everything stays in-app with no tel:/sms: bouncing.
2. The roadside contacts currently "saved to phones" — send them in any format.
3. ~~AppSheet-only notes~~ DONE v0.5.3 — Tyler supplied the export and all 17 notes matched in (6 new). Still outstanding: photos. None are embedded in the AppSheet export, so any per-customer images still live only in AppSheet and need their own route out.
4. Auth model before hosting: single shared access key (Flip CMS style) or per-user logins?
5. The 586 sheet-vs-computed status mismatches + future-dated deals: the app shows computed truth; flag any specific contract that looks wrong.

9. TODO board

Done items are deleted, not left sitting here looking open. Shipped and gone: real-data import (v0.3), the Cloudflare Pages + D1 port (v0.4/v0.4.1), geocoding (v0.4/v0.4.3), VIN decode and the AppSheet notes import (v0.5.3), and the styled breakdown mirror — superseded by the live /breakdown twin.

• P1 — wire the comms backbone (§6). The comms hub logs everything today but cannot yet send or receive; this is the biggest open piece and it is blocked on Tyler choosing Twilio vs Telnyx and opening the account. Grasshopper is ruled out — no API.
• P2 — auth follow-ons now that per-person login exists (§1.5): a self-serve password reset (today Tyler re-arms it with one D1 command), an in-app "change my password" screen (the POST /api/auth/password endpoint is built and tested but has no UI yet), and per-role permissions — both accounts are admin today, so the role column exists but nothing reads it. Also: this app still has no Appolis ID identity, so it cannot join the suite's signed identity envelope until it does.
• P1 — claim-time intake flow polish: one form that captures address + updates customer + opens claim in one step (current flow is edit-then-claim).
• P2 — static breakdown snapshot export (the alternative route named at the top of this file): a build step that fetches /api/config, /api/stats, /api/products and /api/dealers once and bakes the values into a flat HTML file, so the rendered breakdown could be published without the live twin's runtime fetches. Not built — the hub renders this markdown instead, which covers the need. Only worth building if a stakeholder needs the twin's exact rendered look outside the app.
• P2 — seed the Road Ranger directory from the operators saved on the team's phones (§8.2); email/send the dealer report directly (currently print → PDF).
• P3 — CSV/xlsx upload screen so future dealership sheets are imported through the UI instead of scripts.
• P3 — the 3 imported "in progress" claims dating to 2022/2023 need closing or resolving in-app (ops task, not code).

10. Changelog

Newest first. Every entry is ONE source line on purpose — the hub's renderer is line-based and a wrapped bullet shreds the list (see the note at the top of this file).

• v0.18.0 (2026-10-26) — 📇 THE DESK CARD, THE SMALL STICKER, THE INSTALL LINK, THE DEMO EXAMPLES. The quick items from Tyler and Matt's call (Zoom recap, 2026-10-26): (1) Smaller door-jamb sticker — 2 × 2.75 in, the logo and the QR only (no text, no AWS logo); still one per product, same at every dealership. (2) F&I desk card, one per dealership — a 4 × 6 in card for the finance manager's desk (#/brand → pick the dealership → download). Its QR opens /portal?welcome=<slug>&w=<key>: a welcome that names the dealership and walks the customer through putting AWS on their home screen, says their coverage can take up to 24 hours to show up, and how to sign in (VIN, last name, contract number). The key is an HMAC of the server secret and the slug (nothing stored; a slug alone cannot list AWS's dealerships). The portal is now installable (web/portal/manifest.webmanifest) and its sign-in says "up to 24 hours" too. New routes: GET /api/public/welcome (the dealership's name only), GET /api/glass/desk-cards (signed in). (3) Glass pros install from the one link — the GlassGuard link now stays in the address bar, and /glass/manifest.webmanifest?p=… answers with start_url /glass?p=…, so the installed app opens on the link (an installed iPhone app does not share the browser's storage). The pick screen shows how to add it to the home screen (shared helper web/glass/install.js: Android gets an Install button, iPhone gets the Share → Add to Home Screen steps). (4) Demo — on /glass in demo mode, three sample vehicles fill a made-up customer and car and show each coverage answer (covered · both repairs used, replacement only · no coverage); the 🎬 Demo tour gains the desk-card step and every email the app sends, rendered by the real templates with made-up people (GET /api/glass/demo-emails — nothing queued). (5) 📋 Dealership checklist (#/checklist) — what Matt finds out from the dealership on Wednesday (people, systems, getting each sale to AWS the same day, the drive and desks, ACH, the 60-day proof of concept) plus the questions for the PCMI "API meeting"; answers stay on that device, "Copy answers" turns them into text. 6 new tests (test/welcome.test.js); 155 pass.
• v0.17.0 (2026-10-26) — 🏷 ONE STICKER PER PRODUCT, ONE GLASSGUARD LINK, THE DEMO TOUR. Tyler's picks from the Mercedes meeting sheet (chat, 2026-10-26): (1) Brand — his GlassGuard logo, the GlassGuard wordmark and the new AWS logo are in the app (public: web/glass/brand/ — the logo now heads the glass pro's page; signed-in only: web/lib/brand/ with full-size logos, the GlassGuard dealer sheet with its $299 / PAC numbers, the Glass Protect application instructions and the two bi-fold PDFs). (2) Stickers — the blue v0.16.0 sticker is gone; a new admin page Stickers & brand (#/brand) draws ONE 3 × 4 in sticker per product in AWS black + lime: GlassGuard carries Tyler's logo, TireGuard and ScreenGuard a matching shield + chrome/lime wordmark, every one with the AWS logo at the foot; each downloads as one self-contained SVG for the printer. GlassGuard's QR is the one link below; TireGuard and ScreenGuard have no claim page of their own yet, so their QR opens the customer portal. (3) One GlassGuard link for every dealership — the sticker opens /glass?p=…, the pro picks the dealership from the ones on the GlassGuard drive, and when the phone is within half a mile of a dealership's map pin it is picked for them (the phone asks permission for its location; no permission = they pick). The key is an HMAC of the server secret and a version number, so nothing new is stored; 🔁 Make a new link on #/brand bumps the version and retires every printed GlassGuard sticker. The server still accepts each dealership's own link (slug + key). New routes: GET /api/public/glass/dealers (names + map pins only), GET /api/glass/program, POST /api/glass/program/rotate; /api/public/dealer, /coverage and /glass accept p + d. (4) At Home's walk-in list by service — #/glass picks Replacements / Repairs / All for the CSV and the emailed sheet (GET /api/glass/walkins?service=…, queue body {service}); each service keeps its own "last queued". It stays empty until real inspections arrive. (5) 🎬 Demo tour (#/demo) — the meeting's 7 steps in order on one page: admin steps open the real page, phone steps open in demo mode (nothing saved) and show a QR so the room can follow on their own phones. 6 new tests (test/onelink.test.js: program key, picker refusals, no-secret 503, rotate retires the old link, service filter, page pins); D6 updated; 149 pass.
• v0.16.0 (2026-10-26) — 🎬 DEMO MODE + THE GLASSGUARD STICKER. Open /glass, /claim or /portal with ?demo=1 (the dealer page's new 🎬 Copy demo link button does it for the glass link) and a purple banner says DEMO MODE: the glass inspection and the claim request finish with a pretend reference (GI-DEMO-… / CL-DEMO-…) and nothing is uploaded, saved or queued; the portal signs in to a made-up customer (Jordan, a 2025 GLC 300) without touching the server. Look-ups (the dealer link, VIN decode, coverage) still read live data, so the demo is real. The tab stays in demo until Leave demo (?demo=0) or the tab closes (web/glass/demo.js). 🏷 Sticker design replaces the print-a-sheet button: a 3 × 4 in vector sticker — GlassGuard shield mark and wordmark, "Chip or crack in your windshield?", the dealership's own QR, "Scan to start your repair" — shown in the app with Download sticker file (SVG) for a sticker printer or the dealership. 🪟 The windshield drawing on /glass is now as seen standing in FRONT of the car (Tyler's call): PASSENGER on the left, DRIVER on the right, and the hint says so. Data: Mercedes-Benz of South Orlando got its address (4301 Millenia Blvd, Orlando, FL 32839, Tyler's message), map point 28.48668, -81.43881 (OpenStreetMap) and "On the GlassGuard drive" switched on — one row, dealership id 1. 7 new tests (test/demo.test.js, D7 parses every inline page script after a broken string blanked the admin for two minutes on the first v0.16.0 deploy); 143 pass.
• v0.15.0 (2026-10-26) — 📷 SCAN THE VIN. The glass-pro inspection form (/glass), Start a claim (/claim) and the customer portal sign-in (/portal) each get a green Scan the VIN barcode button: the phone camera reads the VIN barcode on the door jamb or windshield label (Code 39, Code 128, Data Matrix, QR, and PDF417 on registration cards), checks the VIN's own check digit so a misread is refused, fills the box and runs the usual look-up. Phones with a built-in barcode reader (Chrome on Android) use it; iPhones load the open-source ZXing reader (Apache 2.0, kept at /glass/zxing.min.js) the first time. No camera or no permission → Take a photo instead reads a still picture the same way; a light button appears where the phone has a torch. Nothing leaves the phone. Also: 🧱 layering fixes found by a page-by-page overlap sweep of all 12 admin screens — the 🐛 button and the version badge no longer sit on the sidebar's sign-out footer (and the badge moves into the top bar on phones), toasts and the bug-report sheet now open above the phone top bar, and the small maps keep their zoom buttons inside the map instead of floating over the top bar. Data: the ScreenGuard move ran on Tyler's press at 15:28 UTC (2,379 Mercedes-Benz of South Orlando rows, one audit row, undo kept). 4 new tests (test/vinscan.test.js); 136 pass.

Renumbering note (reconciled 2026-07-26, todo_1086): two releases had been given numbers that were already taken. v0.5 (2026-07-04, mobile build-out) collided with v0.5.0 (2026-07-17, the New Look), and v0.5.1 was held by both the 2026-07-05 Google Places release and the 2026-07-17 bug-button sweep. The 2026-07-17 numbers are baked into shipped code (web/index.html comments read "NEW LOOK (v0.5.0, todo_682)") and into board todos 682/727/731, so they kept their numbers; the two earlier releases moved down into the v0.4.x line, where they also sit correctly by date. v0.5 → v0.4.4 and Google Places v0.5.1 → v0.4.5. No release was deleted and none changed content.

• v0.14.0 (2026-10-26) — 🔌 THE DEALER-FEED LANDING SPOT. A dealership's system (or PEN, or an F&I menu) can now send contracts straight to the app at POST /api/contracts/import, with a private access key instead of a login; every contract is checked first (VIN, dealer, product, money in whole cents, dates), a dry run shows exactly what would happen, a real send files each good contract once (sending the same one again adds nothing), bad contracts are skipped and listed by field, and each send leaves an audit row on Import statements → Dealer feeds. Nothing is wired to a real system yet: the generic-json format works today; pen and fi-menu are documented empty slots (they answer "not built yet") until PEN's spec is in hand. Production needs one new table (deploy/migrate-v0.14.0.sql, safe before or after the deploy) and the DMS_FEED_KEY Pages secret (until it is set, key callers get 503 and admins can still test).
• v0.13.0 (2026-10-26) — 🔑 THE CUSTOMER PORTAL. Customers can now look after themselves at /portal. They type their VIN, their last name and one more detail they hold — the contract number printed on their AWS paperwork, or the last 4 digits of their phone, or their ZIP — and they see only their own page: every product with a clear Active, Expiring or red Expired badge, the dealership and end date, their claims with what was done on each (amounts can be switched off with one setting), and for GlassGuard how many windshield repairs they have used this year ("1 of 2"). A Start a claim button opens the claim page already filled in from what AWS has on file, so they only add photos. There is no password and no account to create; 8 wrong tries in 10 minutes from one connection locks that connection out for a while, and every wrong answer gets the same "call AWS or start a claim" message so nobody can use the form to find out which VINs exist. The portal sign-in is completely separate from the AWS staff login (one can never open the other), and signing out ends it at once. A later setting (portalAuth) switches to texted one-time codes once a text provider is chosen (todo_684); until then that setting refuses rather than quietly falling back. Nothing is emailed or texted yet. 115 tests.
• v0.12.0 (2026-10-26) — 📣 START A CLAIM, HOT LEADS AND APPOINTMENTS. A customer with a cracked or chipped windshield now has a front door: the new Start a claim page (/claim) works on any phone. They pick the dealership they bought from, type their VIN, name, phone, email and ZIP, photograph the damage (up to three photos) and their driver's license, and tick a box agreeing to be contacted. The page says plainly why the license is asked for: to confirm who is on the contract, only signed-in AWS staff can open it, every look is logged, it is never emailed, and it is deleted 90 days after the request is closed. AWS's At Home inside-sales team gets a HOT LEAD email in the Outbox — VIN, dealership, whether GlassGuard coverage was found, how many of the two repairs this year are used, damage-photo links and a private appointment link, never the license — and the customer gets a "we got your request, AWS will call you" email in the Outbox too. The app checks the VIN and last name against GlassGuard contracts (ScreenGuard does not count), opens a claim when they match, and enforces the two-repairs-a-year limit (a third must be a replacement). It also looks for the nearest GlassGuard network dealer within 25 miles of the customer's ZIP — no dealership is in the network yet, so today the HOT LEAD says "no network dealer within 25 mi". At Home then opens the private appointment page (/appt) from the email and picks repair or replace, a dealer or mobile, the date and time; that is written back onto the claim and confirmed to the customer in the Outbox. The new sidebar page Leads follows every request from new to HOT LEAD sent to called to appointment set to closed or rejected, with the photos, the coverage, the license behind a "View licence (logged)" button and the same appointment form for AWS staff; closing a request starts the 90-day countdown on the license photo. No emails are actually sent yet. 107 tests.
• v0.11.0 (2026-10-26) — 🪟 THE GLASSGUARD INSPECTION FORM. The /glass page is now the real windshield inspection form. A glass pro scans the sticker on the dealership's page (or taps the link the dealership sends), and that phone remembers the dealership — and can install the page as an app on the home screen. They fill in who they are, the customer (with a Yes/No for "agreed to be contacted"), the VIN (a Decode button fills in year, make and model), tap which of the six damage types they see, draw the damage on a windshield outline, take up to six photos, and choose Repair or Replacement. The page checks the VIN and the customer's last name against GlassGuard contracts as they type (a ScreenGuard contract does not count): when it matches, AWS opens a claim automatically; a vehicle that has already had two GlassGuard repairs this calendar year can only be a replacement. Each submission queues two emails in the Outbox — the AWS copy (to info@awsmotorclub.com, copying the pro) and the customer's own "Your Complimentary Glass Inspection" copy, held with a visible reason when the customer said No. New sidebar page Glass inspections lists every submission and opens the drawing, photos, claim and emails; replacement inspections form the weekly walk-in sheet (⬇ CSV, an OEM Y/N box At Home's answer goes into, and ✉ Queue this week's sheet to At Home — the line turns amber when a week with walk-ins goes more than 7 days without one). No emails are actually sent yet. The public-form limits per connection were raised (a whole dealership shares one wifi): 20 submissions and 60 VIN/coverage checks per 10 minutes. 101 tests.
• v0.10.0 (2026-10-26) — 🏷 SCREENGUARD. GlassGuard means windshield protection, but at Mercedes-Benz of South Orlando a touchscreen-radio screen protector had been sold under that name, so all of that dealership's "GlassGuard" sales were really a different product. There is now a Data fixes box on the Imports page: it first shows, without saving anything, exactly how many sales, which dates, how much dealer profit and how many monthly statements would move; then one confirmed click moves them to the new ScreenGuard product, leaves every date, price and coverage end date exactly as it was, writes a log line listing exactly which records moved, and offers an Undo button. The same dealership's future "GG" statements now file as ScreenGuard automatically, while every other dealership's "GG" still means GlassGuard. The product filter, dashboard, reports and the Program Numbers deck show ScreenGuard as a third product, and the deck no longer claims windshield sales that were really touchscreen protectors. 95 tests.
• v0.9.0 (2026-10-26) — 🧱 FOUNDATION FOR THE WINDSHIELD LEG. Nothing new is open to the public yet; this release lays the ground the glass-pro and customer pages will stand on. There is now an Outbox in the sidebar where every email the app wants to send waits until a delivery provider is connected — open one, copy it, send it from your own mail, mark it sent; a photo store with a locked, logged place for driver's-licence images that can be wiped on a schedule; a guard for the coming public forms (bot check, per-connection limits, upload size caps); a private link and printable QR sticker for each dealership on its page, with address lookup and a Rotate key button; a VIN decoder for those forms; the ScreenGuard product row (no data moved yet); and a placeholder /glass page. Mercedes-Benz of South Orlando's sticker link is issued by the upgrade itself. 87 tests.
• v0.8.3 (2026-09-21) — 📅 A GLASSGUARD-LESS YEAR SHOWS CLEAN BARS. On the Program Numbers deck, a window with no GlassGuard at all (2023, for instance) no longer stamps "no GlassGuard rows" under every month bar; the Month-by-month sub line says "TireGuard only — GlassGuard began Nov '24" once, and the bars stay clean. Windows that have GlassGuard in some months keep the per-month marker.
• v0.8.2 (2026-09-21) — 📅 ALL TIME STILL COMPARES THE YEAR IN PROGRESS. On the Program Numbers deck, the All-time window's comparison slide now reads "2026 vs 2025 — year to date · January–August 2026 against January–August 2025" (it had compared the last two full years); the months follow the last statement loaded, so it moves to January–September when September lands. Picker default is All time. August-2026 statements were loaded the same day (245 registrations, both products, reconciled to the dealership's cheque totals).
• v0.8.1 (2026-09-21) — 📅 DECK WINDOW PICKER AND A TIGHTER DECK. The Program Numbers deck (/present?dealer=<id>) gained a window picker in its top bar — Last 12 months (the default), All time, or any single year back to 2023 — and every figure on the at-a-glance, this-year-vs-last, month-by-month, by-product and F&I-manager slides follows it: the comparison shows a full year against the year before (year to date for the year in progress), the month chart shows twelve bars for a year and one bar per year for all time, a year before GlassGuard existed (Nov-2024) shows TireGuard with the GlassGuard card reading "no GlassGuard rows", and the window rides in the link (&win=2024) so a saved link opens on the same view. Per the owner, the claims figures left the at-a-glance slide and the Claims and Data-notes slides are gone — seven slides. No API change; the manager ranking per window is one extra report call per window, fetched with the rest before the deck shows.
• v0.8.0 (2026-09-21) — 📊 PROGRAM NUMBERS DECK + dealer-report fixes. A second cinematic deck at /present?dealer=<id> (📊 Present on the dealer report; behind the login; aggregate figures only, never a customer row) — at a glance, this year vs last, month by month, by product, F&I managers, claims, and a data-notes slide that says which months are statement-verified (Dec-2025 → Jul-2026) and which come from AWS records. The dealer report gained ⬇ CSV (the breakdown as filtered and sorted), a filled Dealer-cost total (it printed blank), honest labels (coverage "as of" its date; claims counted on contracts sold in the range; "Still active" explained), and a print that no longer carries the bug button and version badge. The report API now returns statements, unwound and claimsByStatus (additive). Data audit filed on the board: no Aug/Sep-2026 rows; Apr-2025 GlassGuard empty; June-2025/2026 F&I managers blank; TireGuard Nov-2024 → Mar-2025 pricing anomaly.
• v0.7.1 (2026-08-18) — 🔒 Security-audit fixes (both from the five-point machine-door audit; findings first, fixes after agreement). (1) The roadside-discovery GET no longer writes. It used to persist a freshly geocoded customer's coordinates inline, so a pasted link or a browser prefetch performed a database write; the geocode now comes back flagged in the response and the UI persists it through the normal customer PATCH — same caching, method-honest routes. (2) The dev server's static-path guard is stricter and extracted for testing (server/lib/staticpath.js): traversal attempts are now REJECTED rather than silently re-rooted inside the web folder, and containment requires the web root plus a path separator, so a sibling folder whose name merely starts with "web" can never be served. Neither hole was exploitable in practice (the write was session-gated and idempotent; no sibling folder exists) — these close them on principle. Both fixes carry behaviour tests that fail if reverted: the discovery test stubs the network and asserts the GET leaves coordinates NULL; the path test feeds the guard traversal and sibling-escape paths. Also refreshed the deck's headline numbers to post-backfill reality. 72/72 tests.
• v0.7.0 (2026-08-17) — 📥 IMPORT STATEMENTS: the dealership's monthly sheet becomes customer data, in the app. New #/imports screen: pick the .xlsx the dealer sends, see exactly what it will do to every row, then commit. Nothing is written by the preview, and the commit re-reads the file server-side rather than trusting anything the browser reports. Built on a new zero-dependency .xlsx reader (server/lib/xlsx.js) that runs in the Worker as well as locally — the existing deploy/lib/xlsx-lite.js needs a pre-expanded archive on disk and can only ever serve the import scripts. Eight months of real statements (Dec-2025 → Jul-2026, 1,921 rows) drove every rule: day-first dates repaired (workbooks saved under a day-first locale turned days 1-12 into real date cells with month and day transposed while days 13-31 stayed text — the December and January sheets are both affected and were silently wrong); cancelled deals recognised in all five shapes the dealers use (a FLAT CXL banner, an UNWIND/CANCEL heading, a per-row note column, a negative cost, and an accounting $(185.00)) and stored as registrations.unwound so they exist as history but are excluded from every count, report and coverage total; columns matched by header name because the layout moves month to month (June drops FI-WIP, July's GlassGuard sheet carries a spare column) and because the June GlassGuard sheet is headed TGRGCOST/TGRGSALE — trusting that would file a month of GlassGuard as TireGuard. The dealer's own cheque total is used as an independent audit: our arithmetic must reproduce it to the penny (live cost above the line, minus refunds above it) and the import refuses to write when it does not. That check earned its place immediately — it caught a live March deal being deleted because the customer's surname is CANCELLIERI and the cancellation pattern was unanchored. Re-uploading a statement is a no-op, a corrected sheet shows its changes for approval rather than duplicating, a blank F&I manager never erases one already recorded, and a re-bought vehicle gets a second registration instead of overwriting the first (deal number is the identity — a VIN can carry several deals over time). 68/68 tests, 18 of them new. Two further defects were caught by generating the production SQL and reading it before running it, rather than importing blind: a statement row only has to carry what the dealer printed, and a December refund line names just a VIN and a clawback amount — writing its blanks over the matched registration would have erased that deal's sold date, sale price and expiry, so every field a statement may omit is now COALESCEd and only the cancellation flag is written unconditionally; and dealer_profit_cents / expires_on, although derived, are now COMPARED, because production held rows whose profit was never computed (NULL, so February and March reported $0.00 profit against real six-figure sales) and a re-upload previously skipped them as "unchanged". Deployed 2026-08-17 in the required order — deploy/migrate-v0.7.0.sql against D1 first, then the code — followed by the Dec-2025 → Jul-2026 backfill: 1,141 registrations added, 144 repaired, 502 customers created, 16 cancellations recorded, all eight months reconciling to the figure the importer predicted, with 0 unmatched terms and 0 future-dated deals. 69/69 tests.
• v0.6.3 (2026-07-31) — 📍 Roadside discovery now defaults to 20 miles for both Road Rangers and Tire Shops (user report via the 🐛 reporter; was 60 / 40). A stranded customer wants the nearest help first, and the wide default pushed it down the list. The radius picker still reaches 100 mi for rural gaps. Both accounts are claimed and in use — Tyler 2026-07-29, Matt 2026-07-30.
• v0.6.2 (2026-07-26) — 🚑 HOTFIX: nobody could actually sign in. Tyler hit "failed" on two passwords. Root cause: PBKDF2 was set to 210,000 iterations, and Cloudflare Workers refuses PBKDF2 above 100,000 — it throws at runtime, so every valid password died as a bare error code: 1101 while every invalid one returned a clean 400. Node has no such cap, so all 49 tests passed. The verification gap was mine: to avoid claiming Tyler's account I had only ever tested prod with deliberately-invalid passwords, which never reach the hashing call. Fixes: iterations pinned to 100k behind MAX_WORKERS_PBKDF2_ITERATIONS with a regression test asserting stored iterations never exceed the ceiling; the login page now distinguishes a server fault from a bad password instead of blaming your connection; and password rules dropped composition requirements for length-only per NIST SP 800-63B (the "must contain a number" rule was also rejecting reasonable passphrases). New verification standard: prove the real hashing path in prod with a TEMPORARY account, then delete it — done here, then removed, leaving both real accounts untouched and unclaimed. 50/50 tests.
• v0.6.1 (2026-07-26) — 🔑 ACCOUNT SCREEN: self-serve password reset + change password. #/account (click your name in the sidebar): change your own password (requires the current one, signs out every other device) and — since no email provider exists yet for a "forgot password" link — any admin can re-arm a locked-out teammate so their next sign-in sets a new password. Guards: reset needs a session, refuses self-targeting, rejects unknown emails, and can never create an account; the team list is session-gated and never ships salts or hashes to the browser. Also added the house-standard styled askConfirm() (this app was still missing it) so the reset confirmation is not a bare browser dialog. Tyler confirmed Matt has the same access level as Tyler — both admin, same app. 49/49 tests.
• v0.6.0 (2026-07-26) — 🔐 PER-PERSON LOGIN (closes todo_1095). The shared device key is gone; the app now knows WHO, not just "somebody with the key". Closed allowlist (Tyler + Matt, seeded unclaimed), first-sign-in-sets-your-password, PBKDF2-210k hashed passwords, hash-only session storage, identical error text for bad email and bad password, and a gate that leaves only the login surface open. Also closed three holes the credential audit found: the local dev server used to serve all 28 API routes unauthenticated on every network interface — the whole member/vehicle database to the LAN — and now binds to 127.0.0.1 behind the same gate; APP_KEY + ID_SECRET came out of wrangler.jsonc (ID_SECRET is an encrypted Pages secret, APP_KEY and ACCESS_KEY.txt deleted as dead); and wrangler.jsonc left .gitignore since it no longer holds credentials. Sidebar shows who is signed in with a sign-out. 46/46 tests (12 new auth tests incl. the allowlist being un-registerable and a weak claim leaving the account unclaimed). Verified on prod: old key cookie now 401, both accounts still unclaimed and waiting for their owners.
• v0.5.3 (2026-07-17) — 📤 AppSheet notes landed (closes todo_685). Tyler supplied the AppSheet export (intake/AWS MANUAL INPUT LIST FOR APP.xlsx, tab "MASTER For APP" — 10,135 rows, combined TG+GG with a product column); new deploy/import-appsheet-notes.js matches notes by contract # → VIN and dedupes by body, so re-runs are safe. Result: the AppSheet universe holds 17 notes total — all 17 matched, 6 were new (11 already imported from the masters), 0 unmatched; prod D1 synced idempotently (19 note activities live). No photos are embedded in the export. The "missing notes" perception was mostly the missing VEHICLES (fixed in this same release — item 1 below) — the notes data was always this small. (1) VEHICLES EXIST NOW: every one of the 9,715 imported registrations lacked year/make/model (the sheets only carried VINs) — new deploy/decode-vins.js backfills them via the free NHTSA vPIC batch API (50 VINs/POST, polite gaps, only touches rows missing BOTH year+make so re-runs never clobber hand-entered vehicles; one decode fans out to every registration sharing the VIN). vehicleStr() lights up across the app automatically. (2) junk contact cells: 17 junk emails (the "29"/"51" artifacts) nulled in data, and the UI now renders phone/email only when they look real (okPhone/okEmail — customers list, card header, comms; the edit form still shows raw values so junk stays correctable). (3) NOTES ROOT-CAUSED (the "notes not imported" half of todo_682): the import was NOT at fault — both master workbooks contain only ~12 notes across every tab, and all imported. The real per-customer notes/photos live ONLY in AppSheet's backing data → Tyler exports it (board todo_685), then a matcher-importer lands them as activity. Stale finding for ops: 2 of the 3 imported "in progress" claims date to 2022/2023 — close or resolve in-app. 34/34 tests.
• v0.5.2 (2026-07-17) — 📸 REPORTER SCREENSHOTS (todo_731): the 🐛 popup takes an image now — attach + passthrough to the intake.
• v0.5.1 (2026-07-17) — 🐛 BUG-BUTTON SWEEP (todo_727): the user reporter lands here — bottom-left 🐛 button + styled popup (🐛 broken / 💡 feature, auto device basics), POST /api/bug-report forwards over the new KOSMOS_HUB service binding (works in both looks; the whole app sits behind the device key).
• v0.5.0 (2026-07-17) — ✨ THE NEW LOOK (todo_682): gloss-black shield theme — the design language the Appolis suite proved out (depth, glow, chrome-gradient stat numbers, glass panels, green-gradient primary buttons), rendered entirely in AWS's OWN brand palette. Ships as an html.v2 CSS layer gating every rule, so ↩ Classic look is one click away in the sidebar foot (persisted per device, total revert — the /breakdown palette editor still drives Classic and is untouched by the new theme). Default = New look. Verified live on both themes: dark cards/inputs/dialogs/comms bubbles, badges re-tuned for dark, banners keep the unmissable expired-red.
• v0.4.5 (2026-07-05) — 🔎 GOOGLE PLACES, the third discovery engine, plus strict category gates. server/lib/places.js: Text Search (New), DISTANCE-ranked, per-kind queries incl "used tires" for indie shops; results carry rating/review count (shown in list + map popups). rangerAccept/shopAccept gate ALL engines — mobile computer repair etc. can no longer appear (Tyler's report). Key plumbing local (env/secrets.json) + cloud (Pages secret), lazy-read, graceful OSM-only fallback with "not configured" surfaced in UI. Key landed the same day and was verified live: rangers came back 40/40 with a phone number, and indie tire shops (Sandlake Tire Shop 4.8★, 1.1 mi) now surface ahead of the chains. 34/34 tests. (Renumbered from v0.5.1 — see the note above.)
• v0.4.4 (2026-07-04) — MOBILE BUILD-OUT (Tyler uses it from his phone). ≤840px: fixed top bar + hamburger → off-canvas drawer nav (overlay, closes on navigate); tables shed low-value columns via .hide-sm (customers/claims/comms/dealers/vendors/discovery keep the essentials; anything still wide scrolls inside .panel { overflow-x:auto }); 16px inputs (kills iOS focus-zoom), ≥40px touch targets, 2-col stat cards, 62vh map, scrollable dialogs, safe-area insets. PWA basics: manifest + SVG icon + theme-color → "Add to Home Screen" runs standalone. Discovered phones are now tel: links. Desktop layout untouched (all scoped to the media query). Verified at 375×812: zero horizontal overflow on every page, drawer + map + card OK. (Renumbered from v0.5 — see the note above.)
• v0.4.3 (2026-07-03) — deeper Road Ranger discovery + map view. Mobile discovery = dual engine (wider Overpass tag net + bounded Nominatim free-text, merged/deduped; 1 result → 10 near Orlando test customer; strict name filter keeps fuzzy junk out; default 60 mi). List↔Map toggle on both vendor sections (Leaflet/OSM tiles, customer pin + radius ring + saved/discovered markers w/ save-from-popup). 32/32 tests.
• v0.4.2 (2026-07-03) — Road Rangers vs Tire Shops split. Road Rangers = on-location operators only (discovery kind=mobile: towing tag + mobile/roadside-named, filtered in code — Overpass ,i name regexes are unusably slow, don't reinstate them); new Tire Shops tab holds the fixed drop-off shops. roadside_vendors.category (ranger|shop) separates the directories (remote D1 ALTERed). Overpass mirror fallback added. 32/32 tests.
• v0.4.1 (2026-07-03) — moved to aws-motor-club.pages.dev (Pages project = no account subdomain in the URL; Tyler didn't want "flipmylife" in the AWS Motor Club address). Same D1 database; old workers.dev worker deleted; deploy script now bundles web/_worker.js.
• v0.4 (2026-07-03) — CLOUDFLARE LIVE + report builder + discovery. Whole stack async (dbwrap facade node:sqlite/D1); deployed with D1 + assets + APP_KEY cookie gate (17,991 rows imported). Customers tab = full sortable/filterable paged list. Dealer drill-down rebuilt as a report builder (6 group-bys, date/product/manager filters, print). Road Ranger auto-discovery via Nominatim + Overpass with save-to-directory. dealer_products per-dealership pricing (backfilled MBSO TG $299 / GG $185; registration default + editable panel). Date-swap fix: future deal dates were month/day transpositions — corrected at import (0 remain). 31/31 tests.
• v0.3 (2026-07-03) — REAL DATA + comms hub. Imported both master lists (header-mapped, §7): 8,204 customers / 9,715 registrations / 19 claims. New: Comms tab + chat-style per-customer thread with in-app logging composer (text/call/email/note, in/out direction; tel:/sms: links removed — Grasshopper send integration pending creds). F&I manager performance rollups on the dealer Program Overview (per-manager totals + product split, profit-ranked). Expired made unmissable: red full-width banner on expired customers, red-tinted coverage panels, uppercase EXPIRED badges. Schema: registrations.contract_no (searchable) + deal_number, activity.direction; idempotent addColumn migrations; nullable deal_date. 27/27 tests. Verified live on real data in preview.
• v0.2 (2026-07-03) — rebrand: GuardHQ → AWS Motor Club app (company = AWS Motor Club / Addendum & Warranty Solutions). Logo color scheme (black / silver / green), folder renamed to F:\Claude Code\AWS Motor Club, db file data/aws-motor-club.db, env override AWS_DB, launch entry aws-app. Import plan rewritten: read ALL master-list column headers and carry claim notes/payout history over (§7).
• v0.1 (2026-07-03) — initial build from verbal spec. Zero-dep Node + node:sqlite + vanilla JS UI. Master search, customer cards w/ coverage + claims + notes + map, open-claims pipeline, dealer Program Overview (MoM/YoY, printable), Road Ranger finder w/ proximity ranking + discovery links, term/expiry/profit engines w/ rule tables. Seed data (12 customers, 14 registrations, 6 claims, 5 vendors). 21/21 tests. Verified live in preview.