',\n '

💧

',\n '

' + BRAND + '

',\n // Deliberately the same shape as the line a human takeover writes here\n // (\"Michael is here\"), so the handover reads as one person replacing\n // another rather than the header changing what kind of thing it is.\n '

Jack is here

',\n '',\n '

',\n '

'\n ].join('');\n\n var $ = function (s) { return root.querySelector(s); };\n var bubble = $('.bubble'), panel = $('.panel'), body = $('#body'), dot = $('.dot');\n\n function esc(s){ return String(s==null?'':s).replace(/[&<>]/g,function(c){\n return {'&':'&','<':'<','>':'>'}[c]; }); }\n\n // Make URLs clickable. The bot hands out a pay link the moment it creates an\n // account, and it was arriving as plain text the customer had to select and\n // copy — on a phone, effectively unusable.\n //\n // RUNS ON ALREADY-ESCAPED TEXT, and that ordering is the safety property: by\n // this point there is no way for a < or a quote to survive into the markup,\n // so nothing a visitor or a model types can close the attribute. An & in\n // the href is parsed back to & by the browser, so query strings arrive intact\n // — which matters, because the pay link carries &showInvoiceLines=true.\n //\n // Trailing sentence punctuation is pushed back OUT of the link, or a URL at\n // the end of a sentence 404s on its own full stop. ';' is deliberately not in\n // that set: it would bite the tail off an &.\n function linkify(s){\n return s.replace(/https?:\\\\/\\\\/[^\\\\s<]+/g, function (u) {\n var trail = '';\n var m = u.match(/[.,!?)\\\\]]+$/);\n if (m) { trail = m[0]; u = u.slice(0, u.length - trail.length); }\n\n // THE PAY LINK GETS A BUTTON. It is the only link here a customer is\n // meant to ACT on rather than read, and as a bare URL it was a 120-\n // character string they had to select and copy. Matched on the payment\n // page's own host and path, so an ordinary product link stays an\n // ordinary link — and a URL that merely mentions \"pay\" does not get\n // dressed up as one.\n var isPay = u.indexOf('salesforce-sites.com') > -1 && u.indexOf('/payments/') > -1;\n if (isPay) {\n return ''\n + 'Pay your invoice' + trail;\n }\n return '' + u + '' + trail;\n });\n }\n\n function bodyHtml(s){ return linkify(esc(s)); }\n\n function scroll(){ body.scrollTop = body.scrollHeight; }\n\n /**\n * A short, quiet two-note chime.\n *\n * SYNTHESISED, NOT FETCHED. This widget has no build step and no assets, and\n * an mp3 would mean a second network request on every page of the storefront\n * plus a file to host and cache-bust. Two sine oscillators cost nothing.\n *\n * WILL OFTEN BE SILENT, AND THAT IS CORRECT. Browsers refuse audio until the\n * visitor has interacted with the page, so the ten-second auto-open makes no\n * sound for someone who has only scrolled. Nothing is broken when that\n * happens — the panel still opens, and the red dot still shows. Every failure\n * path here is swallowed: a chat that throws because of a decoration would be\n * a far worse bug than a missing noise.\n */\n var audioCtx = null;\n function chime() {\n try {\n var Ctx = window.AudioContext || window.webkitAudioContext;\n if (!Ctx) return;\n if (!audioCtx) audioCtx = new Ctx();\n\n // SCHEDULE ONLY ONCE THE CONTEXT IS ACTUALLY RUNNING.\n //\n // A suspended context has currentTime frozen at 0 and resume() is\n // ASYNCHRONOUS. Scheduling straight after calling it — which is the\n // obvious way to write this — puts both notes at t=0 and t=0.12, and by\n // the time the context starts those moments are already in the past, so\n // nothing is ever heard. That failure looks exactly like the browser's\n // autoplay block, which is what makes it easy to write off as \"audio is\n // blocked\" and leave in place. A context is created suspended even when\n // the visitor HAS clicked, so this silenced the chime in both cases.\n var play = function () {\n try {\n // A hair in the future: scheduling at exactly currentTime races the\n // audio thread and can clip the attack off the first note.\n var now = audioCtx.currentTime + 0.03;\n // A rising fourth, A5 then D6. Deliberately not a descending pair,\n // which reads as an error tone.\n [[880, 0], [1174.66, 0.12]].forEach(function (note) {\n var osc = audioCtx.createOscillator();\n var gain = audioCtx.createGain();\n osc.type = 'sine';\n osc.frequency.value = note[0];\n\n // Ramped, not switched. Starting or stopping a sine at full\n // amplitude puts a square edge in the signal, audible as a click.\n var t = now + note[1];\n gain.gain.setValueAtTime(0.0001, t);\n gain.gain.exponentialRampToValueAtTime(0.09, t + 0.015);\n gain.gain.exponentialRampToValueAtTime(0.0001, t + 0.22);\n\n osc.connect(gain);\n gain.connect(audioCtx.destination);\n osc.start(t);\n osc.stop(t + 0.25);\n });\n } catch (e) {}\n };\n\n if (audioCtx.state === 'suspended' && audioCtx.resume) {\n audioCtx.resume().then(play).catch(function () {});\n } else {\n play();\n }\n } catch (e) {}\n }\n\n function render(m) {\n if (seen[m.id]) return;\n seen[m.id] = 1;\n\n // The stream echo of something already drawn locally. Swallow it — the\n // bubble is already on screen, and its id will never match the local one.\n if (m.sender === 'visitor' && !m.local) {\n var dup = pendingLocal.indexOf(m.body);\n if (dup > -1) { pendingLocal.splice(dup, 1); return; }\n }\n\n // Same reconciliation, for the nudge specifically — see pendingNudgeBody.\n if (m.sender === 'ai' && pendingNudgeBody !== null && m.body === pendingNudgeBody) {\n pendingNudgeBody = null;\n return;\n }\n\n var d = document.createElement('div');\n if (m.sender === 'system') {\n d.className = 'm sys';\n d.innerHTML = '

' + bodyHtml(m.body) + '

';\n } else if (m.sender === 'visitor') {\n d.className = 'm me';\n d.innerHTML = '

' + bodyHtml(m.body) + '

';\n } else {\n d.className = 'm them';\n // NAMED, BOTH OF THEM. The assistant used to be unlabelled, on the\n // reasoning that \"AI\" in front of every line invites people to discount\n // correct answers. That reasoning still holds — which is why the label is\n // \"Jack\" and not \"AI\". An unlabelled reply is not neutral: it reads as\n // the company talking at you, where a name reads as somebody answering.\n // Jack says what he is the moment anyone asks; the label is an\n // introduction, not a disguise.\n var who = m.sender === 'agent' && m.sender_name\n ? '

' + esc(m.sender_name) + '

'\n : (m.sender === 'ai' ? '

Jack

' : '');\n d.innerHTML = who + '

' + bodyHtml(m.body) + '

';\n }\n body.appendChild(d);\n\n // SOUND ONLY FOR WHAT THE VISITOR IS NOT ALREADY WAITING FOR.\n //\n // awaitingAI is true exactly while they are watching for a reply they just\n // asked for, and chiming at someone who has this second pressed Enter is\n // noise. What is left is the messages that arrive unannounced — the opener,\n // the page nudge, and an agent reaching out — which is the only time a\n // sound earns its place.\n //\n // Read BEFORE clearTyping(), which resets the flag on the next line.\n var unprompted = m.sender !== 'visitor' && !awaitingAI;\n\n if (m.sender !== 'visitor') clearTyping();\n if (unprompted && !replaying) chime();\n if (m.sender === 'agent') $('#sub').textContent = esc(m.sender_name || 'Team') + ' is here';\n if (!open && m.sender !== 'visitor') dot.style.display = 'block';\n scroll();\n\n // Anything landing in the thread — theirs or ours — restarts the clock.\n resetIdle();\n }\n\n function showTyping() {\n if (root.querySelector('.typing')) return;\n var d = document.createElement('div');\n d.className = 'm them typing';\n d.innerHTML = '

Typing…

';\n body.appendChild(d);\n scroll();\n }\n function clearTyping() {\n var t = root.querySelector('.typing');\n if (t) t.remove();\n awaitingAI = false;\n }\n\n // Idle nudge. This does NOT decide to nudge anyone — it reports the one thing\n // the server cannot see, which is that this person stopped typing and is\n // still sitting here with the chat open. Every rule about who deserves a\n // nudge is applied server-side, so the worst a tampered-with call can do is\n // trigger a nudge the conversation had already earned.\n var idleTimer = null;\n // 45 SECONDS, down from three minutes — the office's call, 9/2/2026.\n //\n // Three minutes is a long time to sit in front of a chat window that has\n // stopped talking to you; most people who stall have decided or left well\n // before then. Forty-five seconds catches someone still reading the last\n // answer, which is the moment a question is actually welcome.\n //\n // The server still decides WHO gets one — engaged, we spoke last, still on\n // the bot, at most two ever — so shortening this cannot turn into pestering,\n // only into arriving sooner.\n var IDLE_MS = 45 * 1000;\n\n // Throttle for the typing ping — see pingTyping() below. Three seconds is\n // often enough that the console's indicator never looks stale while someone\n // is mid-sentence, and far too sparse to ever look like a keystroke log.\n var TYPING_PING_MS = 3000;\n var lastTypingPing = 0;\n\n /**\n * Tell the server keystrokes are happening, at most once per\n * TYPING_PING_MS. NEVER sends the textarea's value — only that it fired,\n * and when. See the matching comment on /api/typing in main.ts for why\n * that boundary is deliberate, not an oversight.\n */\n function pingTyping() {\n if (!conversationId) return;\n var t = Date.now();\n if (t - lastTypingPing < TYPING_PING_MS) return;\n lastTypingPing = t;\n fetch(API + '/api/typing', {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({ conversationId: conversationId })\n }).catch(function () {});\n }\n\n function resetIdle() {\n if (idleTimer) clearTimeout(idleTimer);\n if (!open) return;\n idleTimer = setTimeout(function () {\n // A backgrounded tab is not \"still here\", and browsers throttle timers in\n // one anyway — the 15-minute sweep covers that case instead.\n if (!conversationId || document.visibilityState !== 'visible') return;\n fetch(API + '/api/nudge', {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({ conversationId: conversationId })\n }).catch(function () {});\n }, IDLE_MS);\n }\n\n /* ---------------------------------------------------------- transport */\n\n function start() {\n return fetch(API + '/api/session', {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({\n visitorId: visitorId,\n dnt: DNT,\n name: WP.name, email: WP.email, phone: WP.phone,\n zip: WP.zip, company: WP.company, wpUserId: WP.wpUserId,\n pageUrl: location.href\n })\n })\n .then(function (r) { return r.json(); })\n .then(function (d) {\n visitorId = d.visitorId;\n conversationId = d.conversationId;\n try { localStorage.setItem('tribecaChatVisitor', visitorId); } catch (e) {}\n\n replaying = true;\n (d.messages || []).forEach(function (m) {\n render(m);\n if (m.created_at > since) since = m.created_at;\n });\n replaying = false;\n\n greeting = d.greeting || 'Hi! Ask us about delivery in your area, pricing, or your account.';\n nudge = d.nudge || null;\n\n // Anyone who has already said something is mid-conversation, not being\n // greeted. Re-opening with a sales line over the top of their own thread\n // would read as the system having forgotten them.\n visitorSpoke = (d.messages || []).some(function (m) { return m.sender === 'visitor'; });\n\n // THE OPENER NOW ARRIVES AS A STORED MESSAGE and has already been drawn\n // by the replay above. This branch is the fallback for the older server\n // behaviour, where the greeting came back as text and nothing else — it\n // still works, and it must, because a browser can hold a cached widget\n // for five minutes across a deploy.\n if (!(d.messages || []).length) {\n render({ id:'greet', sender:'ai', body: greeting });\n // Recorded so the presence ping can tell the console what this person\n // was actually shown. Set HERE, at the point it is drawn, not where the\n // text arrives — a greeting we received but did not display is not\n // something the visitor has seen.\n openerShown = greeting;\n }\n\n // ARMED ON \"NOBODY HAS SPOKEN\", not on \"the thread was empty\".\n //\n // Those were the same test until the opener started being stored. Once\n // it is a real message the thread is never empty, so keying the nudge on\n // emptiness silently retired it — the follow-up simply stopped happening\n // for everyone, with nothing to show it had.\n if (!visitorSpoke) armNudge();\n\n listen();\n });\n }\n\n // The server closes a stream after five minutes so abandoned tabs cannot\n // poll forever. Reconnecting is expected, not an error.\n function listen() {\n if (es) es.close();\n es = new EventSource(API + '/api/stream?c=' + encodeURIComponent(conversationId) + '&since=' + since);\n\n es.onmessage = function (ev) {\n try {\n var m = JSON.parse(ev.data);\n if (!m || !m.id) return;\n if (m.created_at > since) since = m.created_at;\n render(m);\n } catch (e) {}\n };\n\n es.onerror = function () {\n es.close();\n setTimeout(listen, 3000);\n };\n }\n\n /**\n * Queue the page-specific follow-up, to be sent only if the opener is\n * ignored. Cancelled the moment the visitor types anything — a nudge that\n * lands after someone has already started talking is the system talking over\n * them.\n */\n function armNudge() {\n if (!nudge || nudged || visitorSpoke || nudgeTimer) return;\n nudgeTimer = setTimeout(function () {\n nudgeTimer = null;\n if (nudged || visitorSpoke || !open) return;\n nudged = true;\n render({ id: 'nudge_' + Date.now(), sender: 'ai', body: nudge });\n // SET AFTER THE LOCAL DRAW, not before — render() checks this on every\n // call, and setting it first would make the optimistic draw swallow\n // itself before anything ever reached the screen.\n pendingNudgeBody = nudge;\n\n // TELL THE SERVER IT WAS DRAWN, so it becomes part of the transcript.\n // Otherwise the model answers a reply to a line it cannot see — the\n // same failure the opener had. No text is sent: the server recomputes\n // the nudge for this conversation's page, so this call can only decide\n // WHEN it is recorded, never what it says.\n fetch(API + '/api/shown-nudge', {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({ conversationId: conversationId })\n }).catch(function () {});\n }, NUDGE_MS);\n }\n\n function cancelNudge() {\n visitorSpoke = true;\n if (nudgeTimer) { clearTimeout(nudgeTimer); nudgeTimer = null; }\n }\n\n function send(text) {\n if (!text.trim() || !conversationId) return;\n\n cancelNudge();\n pendingLocal.push(text);\n render({ id: 'local_' + Date.now(), sender: 'visitor', body: text, local: true });\n showTyping();\n awaitingAI = true;\n\n fetch(API + '/api/message', {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n // pageUrl travels WITH the message, not just on the 45s presence\n // heartbeat — a visitor who just navigated to a product page and\n // typed within that window was otherwise quoted off wherever they\n // were up to 45 seconds ago. Confirmed live 9/4/2026: quoted plastic\n // pricing while sitting on the glass bottle page for exactly this\n // reason.\n body: JSON.stringify({ conversationId: conversationId, body: text, pageUrl: location.href })\n })\n .then(function (r) { return r.json(); })\n .then(function (d) {\n // The AI turn completes inside that POST, so if it produced nothing the\n // model failed. Say so and offer a person rather than leaving a spinner\n // running forever.\n if (d && d.ai === false && !d.handoff) clearTyping();\n if (d && d.ai && awaitingAI) {\n setTimeout(function () {\n if (!awaitingAI) return;\n clearTyping();\n render({ id:'err_'+Date.now(), sender:'system',\n // Names the phrase that actually triggers a handoff, now that the\n // button is gone. wantsHuman() in main.ts matches on exactly this.\n body:'Sorry — I had trouble with that. Try again, or say \"I\\\\'d like to talk to someone\" and I\\\\'ll bring in the team.' });\n }, 6000);\n }\n })\n .catch(function () {\n clearTyping();\n render({ id:'off_'+Date.now(), sender:'system',\n body:'Message not sent. Check your connection and try again.' });\n });\n }\n\n // The \"Talk to a person\" button was removed on request. Handoff is NOT gone:\n // main.ts still matches phrases like \"can I talk to someone\" in wantsHuman()\n // and escalates, and the model is told to hand off when asked. /api/handoff\n // remains for any caller that wants it — nothing here calls it now.\n\n /* -------------------------------------------------------------- wiring */\n\n bubble.onclick = function () {\n open = true;\n panel.classList.add('on');\n bubble.style.display = 'none';\n dot.style.display = 'none';\n if (!conversationId) startSafe();\n else scroll();\n $('#in').focus();\n };\n\n $('#x').onclick = function () {\n open = false;\n panel.classList.remove('on');\n bubble.style.display = 'flex';\n // Remembered across pages and visits. The bubble is still there if they\n // change their mind; what stops is the widget deciding for them.\n dismissed = true;\n cancelNudge();\n // The TIME, not a flag. Read back above against DISMISS_MS so this lapses\n // after a week instead of lasting for the life of the browser profile.\n try { localStorage.setItem('tribecaChatDismissed', String(Date.now())); } catch (e) {}\n };\n\n $('#go').onclick = function () {\n var el = $('#in');\n send(el.value);\n el.value = '';\n el.style.height = '38px';\n };\n\n $('#in').onkeydown = function (e) {\n if (e.key === 'Enter' && !e.shiftKey) { e.preventDefault(); $('#go').click(); }\n };\n\n // Grow with the message, up to a point.\n $('#in').oninput = function () {\n this.style.height = '38px';\n this.style.height = Math.min(this.scrollHeight, 110) + 'px';\n if (this.value.trim()) pingTyping();\n };\n\n // OPEN BY ITSELF, ONCE, AFTER TEN SECONDS.\n //\n // This is the change the tawk numbers argue for hardest: every one of those\n // 100 exported conversations was opened by the widget rather than by the\n // visitor, and 92% of real people answered. A bubble sitting silently in the\n // corner is a question nobody asks.\n //\n // Three things it will not do — open on top of a panel the visitor opened\n // themselves, open for anyone who has closed it before, or open twice.\n // No chime() here on purpose. The panel opening is not the event worth\n // hearing — the MESSAGE arriving is, and start() is a fetch, so the greeting\n // lands a moment later. render() sounds it then, which puts the noise on the\n // thing that actually appeared. Chiming here as well produced two tones about\n // 300ms apart.\n //\n // AND NOT INTO A TAB NOBODY IS LOOKING AT. A link opened in a background tab\n // — the ordinary way people open search results — would spend its one and\n // only auto-open on a hidden document, and by the time the visitor switched\n // to it the widget had already decided it was done. Shortening the delay to\n // four seconds makes that MORE likely, not less, which is why it is fixed\n // here in the same change. Deferring to the moment the tab is actually\n // looked at costs nothing and is the difference between being greeted and\n // sitting in the console as \"browsing\" forever.\n function autoOpen() {\n if (open || dismissed) return;\n if (openAttempts >= MAX_OPEN_ATTEMPTS) return;\n\n // NOT ON THE RECEIPT PAGE. Someone reading their order confirmation has\n // just done the thing we wanted; opening a chat window over it is a\n // business interrupting a customer for its own benefit, and the sales\n // openers — one of which offers 25% off a first delivery — are actively\n // wrong to show to someone who has this minute paid full price.\n // The bubble is still there if they want us.\n var here = String(location.pathname || '').toLowerCase();\n if (here.indexOf('order-received') > -1 || here.indexOf('/thank-you') > -1) return;\n\n if (document.visibilityState !== 'visible') {\n if (waitingForVisible) return;\n waitingForVisible = true;\n document.addEventListener('visibilitychange', function onVis() {\n if (document.visibilityState !== 'visible') return;\n document.removeEventListener('visibilitychange', onVis);\n waitingForVisible = false;\n setTimeout(autoOpen, AUTO_OPEN_MS);\n });\n return;\n }\n\n openAttempts++;\n bubble.click();\n }\n\n setTimeout(autoOpen, AUTO_OPEN_MS);\n\n /**\n * Open the conversation, and KEEP TRYING IF THE REQUEST FAILS.\n *\n * The old code called start() and ignored the promise. A single failed fetch\n * — a dropped request as a phone changes network, a cold start that timed\n * out — left the panel sitting open and completely empty, with no greeting,\n * no error and no way back except reloading the page. From the visitor's\n * side that is a chat window that does not work; from ours it looked like\n * somebody who was shown the opener and ignored it.\n *\n * Backs off, gives up after three tries, and only retries while the tab is\n * being looked at — retrying into a backgrounded tab burns attempts on\n * somebody who is not watching.\n */\n var starting = false;\n var startTries = 0;\n\n function startSafe() {\n if (conversationId || starting) return;\n starting = true;\n start()\n .then(function () { starting = false; })\n .catch(function () {\n starting = false;\n if (++startTries >= 3) return;\n setTimeout(function () {\n if (!conversationId && document.visibilityState === 'visible') startSafe();\n }, startTries * 4000);\n });\n }\n\n /* ------------------------------------------------------------ presence */\n\n var invitedShown = false;\n\n // Runs on page load and on a heartbeat, whether or not the chat is ever\n // opened. This is what puts someone on the agent's monitoring screen — and\n // what lets an agent speak to them first.\n function presence() {\n fetch(API + '/api/presence', {\n method: 'POST',\n headers: { 'Content-Type': 'application/json' },\n body: JSON.stringify({\n visitorId: visitorId,\n pageUrl: location.href,\n // Only the referrer that brought them TO the site is interesting, and\n // the server keeps the first one it is told, so sending it on every\n // ping is harmless — internal navigation never overwrites it.\n referrer: document.referrer || null,\n dnt: DNT,\n // What the console cannot otherwise know: whether the panel is open in\n // front of them right now, and which lines this browser drew that were\n // never sent as messages.\n chatOpen: open,\n // Why this person may never have been greeted. It is a localStorage\n // flag, so the console cannot see it any other way, and without it a\n // visitor who closed the chat is indistinguishable on screen from one\n // the widget simply failed to reach.\n dismissed: dismissed,\n notFound: pageIs404(),\n arm: window.TribecaChatArm || null,\n shownOpener: openerShown,\n shownNudge: nudged ? nudge : null,\n name: WP.name, email: WP.email, phone: WP.phone,\n zip: WP.zip, company: WP.company, wpUserId: WP.wpUserId\n })\n })\n .then(function (r) { return r.json(); })\n .then(function (d) {\n if (d.visitorId && !visitorId) {\n visitorId = d.visitorId;\n try { localStorage.setItem('tribecaChatVisitor', visitorId); } catch (e) {}\n }\n\n // Someone from the team has spoken. Open the widget for them — once.\n // Popping open repeatedly would be obnoxious, and a conversation the\n // visitor started themselves must never trigger this.\n if (d.invited && !open && !invitedShown) {\n invitedShown = true;\n bubble.click();\n return;\n }\n\n // THE SECOND CHANCE, AND THE REASON IT IS HERE RATHER THAN ON A TIMER.\n //\n // Reaching this line means a heartbeat just completed, and heartbeats\n // only run while the tab is being looked at — so this is the strongest\n // evidence the widget ever gets that a real person is on the page right\n // now. If they are still here and nothing was ever said to them, the\n // first attempt was lost: a throttled timer, a tab restored from the\n // back-forward cache with its timers dropped, or an open that happened\n // while the document was hidden.\n //\n // The guards are the same three as everywhere else — not already open,\n // not dismissed, no conversation yet — plus the attempt cap, so at worst\n // this fires twice more, 45 and 90 seconds in, and then stops for good.\n if (!open && !dismissed && !conversationId) autoOpen();\n })\n .catch(function () {});\n }\n\n presence();\n goneBeacon(function () { return visitorId; });\n\n // Only while the tab is actually being looked at. A background tab left open\n // all afternoon should not keep reporting its owner as present, or the\n // monitoring screen fills with people who wandered off hours ago.\n setInterval(function () {\n if (document.visibilityState === 'visible') presence();\n }, 45000);\n})();`;\n","label",[145],"b7462286-9e3c-4782-900b-1d868a62cb99","salesforce.ts","186d5df2-a5a5-11f1-8342-1607ee4eb77e",630,["D",1788642521817],8,"// Salesforce lookup — deterministic, never a model decision.\n//\n// Calls the same narrow endpoint the other three vals use, inside\n// tribeca-salesforce-agent. That val holds the Salesforce credentials; this\n// key unlocks only the one read-only account lookup, never arbitrary SOQL.\n//\n// PHONE IS THE ONLY ROUTE FOR AN ACCOUNT LOOKUP. The Salesforce integration\n// user cannot read Contact at all, Account has no email column, and\n// Lead.Email is hidden by field-level security (verified by schema probe\n// 8/25/2026). An email address, however confidently an EXISTING CUSTOMER\n// supplies it, cannot be resolved to their account.\n//\n// LEAD LOOKUP IS A SEPARATE QUESTION, BELOW. A Lead is not an account — it is\n// \"did this person already give us contact info somewhere,\" most often the\n// website popup, which has no connection back to the chat at all otherwise.\n// The same Lead.Email restriction may or may not apply there; lookupLead\n// tries it live and logs what actually happens rather than assuming the\n// account-lookup finding carries over.\n\nconst ENDPOINT = \"https://tribeca-apollo.val.run/account-lookup\";\nconst INVOICE_ENDPOINT = \"https://tribeca-apollo.val.run/invoice-status\";\nconst LEAD_ENDPOINT = \"https://tribeca-apollo.val.run/lead-lookup\";\n\nexport interface InvoiceResult {\n found: boolean;\n ambiguous?: boolean;\n errored?: boolean;\n balanceDue?: number;\n invoiceNumber?: string | null;\n status?: string | null;\n dueDate?: string | null;\n /** Only ever present for a signed-in visitor. See invoice.ts on the tool val. */\n payLink?: string;\n emailOnFile?: string | null;\n message: string;\n}\n\n/**\n * What this customer owes, and — only for a signed-in visitor — the pay link.\n *\n * `authenticated` must mean a real credential check: a WordPress/WooCommerce\n * session, which is what `wpUserId` on the visitor represents. A phone number\n * typed into the chat box is NOT authentication. The pay link exposes the\n * invoice with its line items and updates the card on file, and it is keyed\n * only on a Salesforce record id rather than a secret token — so handing it to\n * someone who merely guessed a phone number would be handing over a stranger's\n * bill.\n *\n * Called fresh on each turn rather than cached: a stale balance shown to a\n * customer who has just paid is its own kind of wrong.\n */\nexport async function invoiceStatus(\n phone: string,\n authenticated: boolean,\n): Promise {\n const key = Deno.env.get(\"APOLLO_TOOL_KEY\");\n if (!key) {\n console.error(\"APOLLO_TOOL_KEY not set — skipping invoice lookup\");\n return null;\n }\n\n try {\n const res = await fetch(INVOICE_ENDPOINT, {\n method: \"POST\",\n headers: { \"x-api-key\": key, \"Content-Type\": \"application/json\" },\n body: JSON.stringify({ phone, authenticated }),\n signal: AbortSignal.timeout(9000),\n });\n if (!res.ok) {\n console.error(`invoice-status HTTP ${res.status}`);\n return null;\n }\n return await res.json();\n } catch (err) {\n // Same rule as the account lookup: an outage is not an answer. Null means\n // the model is told nothing about a balance rather than told there is none.\n console.error(\"invoice-status failed:\", err);\n return null;\n }\n}\n\nconst CREATE_ENDPOINT = \"https://tribeca-apollo.val.run/create-account\";\n\n/**\n * Create the Salesforce account for a new customer.\n *\n * WHAT THIS DOES AND DOES NOT DO. It creates the ACCOUNT — card-on-file, terms\n * of zero, which the tool val enforces so a bot can never extend credit. It does\n * NOT take payment and does not place a WooCommerce order. That is deliberate,\n * and it mirrors how the team already works: Michael's line in the transcripts\n * is \"I can get all info through the chat here and email the first invoice for\n * payment\". Collecting the details is the slow part; the card is the office's.\n *\n * Which also means the customer must NOT then check out on the website as well,\n * or they end up with two accounts and split billing.\n */\nexport async function createAccount(input: Record): Promise {\n const key = Deno.env.get(\"APOLLO_TOOL_KEY\");\n if (!key) {\n console.error(\"APOLLO_TOOL_KEY not set — cannot create account\");\n return { ok: false, reason: \"error\", message: \"Account creation is unavailable right now.\" };\n }\n\n try {\n const res = await fetch(CREATE_ENDPOINT, {\n method: \"POST\",\n headers: { \"x-api-key\": key, \"Content-Type\": \"application/json\" },\n body: JSON.stringify({ ...input, createdVia: \"Tribeca website chat\" }),\n signal: AbortSignal.timeout(15000),\n });\n if (!res.ok) {\n console.error(`create-account HTTP ${res.status}`);\n return { ok: false, reason: \"error\", message: \"The account could not be created right now.\" };\n }\n return await res.json();\n } catch (err) {\n console.error(\"create-account failed:\", err);\n return { ok: false, reason: \"error\", message: \"The account could not be created right now.\" };\n }\n}\n\nexport interface LookupResult {\n found: boolean;\n account_name?: string;\n next_delivery_date?: string | null;\n message: string;\n // found:false arrives in three distinct flavours. They are kept separate on\n // purpose: reporting a failed query as \"no account found\" is a different,\n // and wrong, statement about a real customer.\n needs_phone?: boolean;\n ambiguous?: boolean;\n errored?: boolean;\n}\n\nconst PHONE_RE = /(?:\\+?1[\\s.\\-]?)?\$?\\d{3}\$?[\\s.\\-]?\\d{3}[\\s.\\-]?\\d{4}/;\n\n/** Pull the first plausible 10-digit US number out of free text. */\nexport function scanForPhone(text: string): string | null {\n const m = String(text ?? \"\").match(PHONE_RE);\n if (!m) return null;\n\n let d = m[0].replace(/\\D/g, \"\");\n if (d.length === 11 && d.startsWith(\"1\")) d = d.slice(1);\n return d.length === 10 ? d : null;\n}\n\nexport async function lookupByPhone(phone: string): Promise {\n const key = Deno.env.get(\"APOLLO_TOOL_KEY\");\n if (!key) {\n console.error(\"APOLLO_TOOL_KEY not set — skipping Salesforce lookup\");\n return null;\n }\n\n try {\n const res = await fetch(`${ENDPOINT}?phone=${encodeURIComponent(phone)}`, {\n headers: { \"x-api-key\": key },\n // Two SOQL queries behind a possible cold start. Longer than this and\n // the customer is watching a spinner; shorter and legitimate lookups\n // get cut off.\n signal: AbortSignal.timeout(9000),\n });\n\n if (!res.ok) {\n console.error(`account-lookup HTTP ${res.status}`);\n return null;\n }\n\n return await res.json();\n } catch (err) {\n // An outage is not an answer. Returning null means the caller stores\n // nothing, so the panel stays empty rather than asserting something false.\n console.error(\"account-lookup failed:\", err);\n return null;\n }\n}\n\n// Deliberately loose — this is a \"did something email-shaped appear,\" not a\n// validator. A wrong guess here costs one wasted lookup; a missed real email\n// costs the whole point of this feature.\nconst EMAIL_RE = /[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}/;\n\n/** Pull the first plausible email address out of free text. */\nexport function scanForEmail(text: string): string | null {\n const m = String(text ?? \"\").match(EMAIL_RE);\n return m ? m[0] : null;\n}\n\nexport interface LeadResult {\n found: boolean;\n source?: \"phone\" | \"email\";\n company?: string | null;\n status?: string | null;\n created_date?: string | null;\n message?: string;\n ambiguous?: boolean;\n errored?: boolean;\n}\n\n/**\n * Has this visitor already submitted a Lead somewhere — the website popup,\n * an ad form — even though they have no account with us?\n *\n * Called with WHATEVER is known, which may be phone, email, or both; the tool\n * val tries each independently. `null` on an outage, same convention as\n * lookupByPhone — the caller stores nothing rather than asserting an absence.\n */\nexport async function lookupLead(\n phone: string | null,\n email: string | null,\n): Promise {\n if (!phone && !email) return null;\n\n const key = Deno.env.get(\"APOLLO_TOOL_KEY\");\n if (!key) {\n console.error(\"APOLLO_TOOL_KEY not set — skipping lead lookup\");\n return null;\n }\n\n const params = new URLSearchParams();\n if (phone) params.set(\"phone\", phone);\n if (email) params.set(\"email\", email);\n\n try {\n const res = await fetch(`${LEAD_ENDPOINT}?${params}`, {\n headers: { \"x-api-key\": key },\n signal: AbortSignal.timeout(9000),\n });\n\n if (!res.ok) {\n console.error(`lead-lookup HTTP ${res.status}`);\n return null;\n }\n\n return await res.json();\n } catch (err) {\n console.error(\"lead-lookup failed:\", err);\n return null;\n }\n}\n\nconst CHAT_COUPON_ENDPOINT = \"https://tribecabeverage.com/wp-json/tribeca/v1/chat-coupon\";\n\n// The coupon it mints is a REAL WooCommerce discount code — only\n// tribecabeverage.com has a checkout for one to be redeemed at. The lead\n// pages (Jersey/Manhattan/Miami Water Delivery Pros) have no online\n// ordering at all, per the same rule leadCaptureBlock and toolsFor enforce\n// in agent.ts: nothing gets applied to an order there, because there is no\n// order to apply it to — only a callback. Checked HERE, not just left to\n// whichever call site eventually wires this up, so the guarantee holds\n// regardless of who calls it or from where.\nconst COUPON_HOST = \"tribecabeverage.com\";\n\n/**\n * Once we have a visitor's email, mint a REAL 25%-off first-order coupon that\n * expires in 24 hours and let Salesforce email it — the coupon, then the reminder\n * and last-call urgency follow-ups. The WordPress endpoint mints the code on the\n * store and creates a \"Website Popup\" Lead carrying it, which is what fires those\n * flows; delivery is entirely by email, nothing is shown in chat unless we choose\n * to. Dedup-guarded on the WP side (a known Lead/customer is never couponed\n * twice), and fire-and-forget here: a coupon that fails to mint must never break\n * or delay the chat reply.\n *\n * `site` is the visitor's hostname (landing_url/page_url) — pass it through\n * from whatever calls this. Omitted or anything other than\n * tribecabeverage.com is treated as \"do not offer,\" not as tribecabeverage.com\n * by default, on purpose: the safe failure here is no coupon, not a wrong one.\n */\nexport async function offerChatCoupon(\n email: string | null,\n site?: string | null,\n pct?: 25 | 35,\n): Promise {\n const secret = Deno.env.get(\"TBC_COUPON_SECRET\");\n if (!secret || !email) return;\n if (site !== COUPON_HOST) return;\n\n try {\n const res = await fetch(CHAT_COUPON_ENDPOINT, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify({ secret, email, ...(pct ? { pct } : {}) }),\n signal: AbortSignal.timeout(12000),\n });\n if (!res.ok) console.error(`chat-coupon HTTP ${res.status}`);\n } catch (err) {\n console.error(\"chat-coupon failed:\", err);\n }\n}\n\n// ONE-WEEK DISCOUNT A/B TEST (started 9/5/2026, same cutoff as the site popup's\n// TBC_POP25_DISCOUNT_TEST_END): the popup shows some visitors 35% off instead of\n// the usual 25%. This bot's own closer offer stays 25% — that is a separate,\n// deliberate business choice, not part of the test — but if a visitor SAYS they\n// were already shown 35% (e.g. \"the popup said 35% off\"), the bot must not\n// contradict them. Detects that specific claim so the mint call above can honor\n// it rather than silently couponing them at 25% while they were told 35%.\nconst CLAIMED_35_RE = /\\b35\\s*%|\\b35\\s*percent\\b/i;\nexport function scanFor35PercentClaim(text: string): boolean {\n return CLAIMED_35_RE.test(String(text ?? \"\"));\n}\n\nconst CHAT_LEAD_ENDPOINT = \"https://tribeca_rep--01a06851302f749caf3642279acb0805.web.val.run/api/chat-lead\";\n\n/**\n * Record a name + phone number as a lead, on the sites with no online\n * ordering behind them at all (Jersey/Manhattan/Miami Water Delivery Pros).\n *\n * NOT A SALESFORCE WRITE. Tried that first — the tribeca-salesforce-agent\n * integration user can create Accounts (create_account above) but Lead\n * insert is blocked outright at the license level, confirmed live 9/4/2026\n * with a real CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY error, not a field- or\n * object-permission one a permission set could fix. tribeca-lead-relay\n * already does exactly what was asked instead — store it, email the office\n * — for these same three sites' own contact forms, so this reuses that\n * rather than standing up a second thing.\n */\nexport async function submitChatLead(\n input: { name?: string; phone?: string },\n site: string,\n): Promise<{ ok: boolean; reason?: string } | null> {\n const key = Deno.env.get(\"CHAT_LEAD_KEY\");\n if (!key) {\n console.error(\"CHAT_LEAD_KEY not set — cannot submit lead\");\n return null;\n }\n\n try {\n const res = await fetch(CHAT_LEAD_ENDPOINT, {\n method: \"POST\",\n headers: { \"x-api-key\": key, \"Content-Type\": \"application/json\" },\n body: JSON.stringify({ ...input, site }),\n signal: AbortSignal.timeout(9000),\n });\n if (!res.ok) {\n console.error(`chat-lead HTTP ${res.status}`);\n return { ok: false, reason: \"error\" };\n }\n return await res.json();\n } catch (err) {\n console.error(\"chat-lead failed:\", err);\n return { ok: false, reason: \"error\" };\n }\n}\n",[156],"58ff37f5-7d9e-47d8-8aa1-13bc8d0b2ce8","push.ts","08902402-a724-11f1-8318-1607ee4eb77e",411,["D",1788391014321],1,"// Web Push — notifications from the Tribeca app itself.\n//\n// WHY THIS EXISTS ALONGSIDE TELEGRAM\n// Telegram is a fine notifier and requires having Telegram. The team does not.\n// Since iOS 16.4 a web app added to the Home Screen can receive real push\n// notifications through APNs, and the phone console is already installed —\n// so the alert can come from the app somebody actually taps, with no second\n// app to install and nothing to pay.\n//\n// ────────────────────────────────────────────────────────────────────────\n// THE PUSHES ARE DELIBERATELY EMPTY.\n//\n// A Web Push payload must be encrypted with aes128gcm and an ECDH key\n// agreement against the subscription's own keys. That is a genuinely fiddly\n// piece of cryptography to hand-roll, and getting it subtly wrong fails in the\n// worst way available: silently, on some devices, in production.\n//\n// The protocol allows a push with NO body at all. So this sends the bare\n// signed request, and the service worker — which is same-origin and carries\n// the session cookie — fetches the details itself and builds the notification.\n// No encryption to get wrong, and the customer's name and message never sit in\n// a third party's push queue. Apple and Google are told only that something\n// happened, never what.\n//\n// The cost is one extra round trip on the device before the banner appears,\n// which is a few hundred milliseconds nobody will notice.\n// ────────────────────────────────────────────────────────────────────────\n//\n// VAPID is what proves the push came from us. An ES256 JWT, signed with the\n// key in VAPID_PRIVATE_KEY, naming the push service as its audience.\n\nimport * as db from \"./db.ts\";\n\n// The public half of VAPID_PRIVATE_KEY, as the raw uncompressed point.\n// Safe in source — it is a public key, and the browser needs it anyway to\n// create a subscription. The two MUST stay a matching pair: replacing one\n// without the other invalidates every phone silently.\nexport const VAPID_PUBLIC_KEY =\n \"BIAiMZdiOwKrxlc_7CS7tawetsLOFQiRmRWgHvaoGDxpFsfEZ2LUHDwR012m54Vdszmc83hRYCDXyT65sItftXU\";\n\n// Push services require a contact for the sender, so they have somebody to\n// reach if a sender misbehaves.\nconst VAPID_SUBJECT = \"mailto:info@tribecabeverage.com\";\n\nfunction b64url(bytes: Uint8Array): string {\n let s = \"\";\n for (const b of bytes) s += String.fromCharCode(b);\n return btoa(s).replace(/\\+/g, \"-\").replace(/\\//g, \"_\").replace(/=+$/, \"\");\n}\n\nfunction fromB64url(s: string): Uint8Array {\n const pad = s.replace(/-/g, \"+\").replace(/_/g, \"/\");\n const bin = atob(pad + \"=\".repeat((4 - pad.length % 4) % 4));\n return Uint8Array.from(bin, (ch) => ch.charCodeAt(0));\n}\n\n/**\n * Rebuild the signing key from the private scalar plus the public point.\n *\n * WebCrypto will not import a private EC key from `d` alone — a JWK needs x\n * and y as well. Both are simply the two halves of the public key after its\n * leading 0x04 marker, so nothing extra has to be stored.\n */\nasync function signingKey(): Promise {\n const d = Deno.env.get(\"VAPID_PRIVATE_KEY\");\n if (!d) return null;\n\n const pub = fromB64url(VAPID_PUBLIC_KEY);\n return await crypto.subtle.importKey(\n \"jwk\",\n {\n kty: \"EC\",\n crv: \"P-256\",\n d,\n x: b64url(pub.slice(1, 33)),\n y: b64url(pub.slice(33, 65)),\n ext: true,\n },\n { name: \"ECDSA\", namedCurve: \"P-256\" },\n false,\n [\"sign\"],\n );\n}\n\n/**\n * One JWT per push service, not per subscription.\n *\n * The `aud` claim is the ORIGIN of the endpoint, so every iPhone shares one\n * token and every Android another. Signing once per service instead of once\n * per device keeps a fan-out to the whole team down to a couple of signatures.\n */\nasync function vapidJwt(audience: string, key: CryptoKey): Promise {\n const enc = new TextEncoder();\n const header = b64url(enc.encode(JSON.stringify({ typ: \"JWT\", alg: \"ES256\" })));\n const claims = b64url(enc.encode(JSON.stringify({\n aud: audience,\n // Twelve hours. Push services reject anything more than 24 out.\n exp: Math.floor(Date.now() / 1000) + 12 * 60 * 60,\n sub: VAPID_SUBJECT,\n })));\n\n const sig = await crypto.subtle.sign(\n { name: \"ECDSA\", hash: \"SHA-256\" },\n key,\n enc.encode(header + \".\" + claims),\n );\n\n // WebCrypto already returns the raw r||s pair JWS wants. Node's crypto would\n // hand back DER here and need unwrapping — a real source of \"works on my\n // machine\" between the two runtimes.\n return header + \".\" + claims + \".\" + b64url(new Uint8Array(sig));\n}\n\n/**\n * Buzz every registered phone.\n *\n * Never throws. A notification failing must not take down the customer's\n * message with it — the visitor's POST is what is waiting on this.\n */\nexport async function pushAll(): Promise {\n const key = await signingKey();\n if (!key) {\n console.error(\"PUSH UNSENT — VAPID_PRIVATE_KEY not set\");\n return 0;\n }\n\n const subs = await db.livePushSubs();\n if (!subs.length) return 0;\n\n const jwts = new Map();\n let sent = 0;\n\n await Promise.all(subs.map(async (sub: any) => {\n const endpoint = String(sub[\"endpoint\"]);\n const id = String(sub[\"id\"]);\n\n try {\n const origin = new URL(endpoint).origin;\n if (!jwts.has(origin)) jwts.set(origin, await vapidJwt(origin, key));\n\n const res = await fetch(endpoint, {\n method: \"POST\",\n headers: {\n \"Authorization\": `vapid t=${jwts.get(origin)}, k=${VAPID_PUBLIC_KEY}`,\n // Hold it for five minutes if the phone is off. Beyond that the\n // alert is stale — somebody has either answered or the visitor left.\n \"TTL\": \"300\",\n \"Content-Length\": \"0\",\n // Wake the device rather than deliver quietly. A silent alert about\n // a customer waiting is the same as no alert.\n \"Urgency\": \"high\",\n },\n signal: AbortSignal.timeout(8000),\n });\n\n if (res.ok) {\n sent++;\n await db.pushOk(id);\n return;\n }\n\n // 404 and 410 are the push service saying this device is gone for good —\n // uninstalled, or the subscription replaced. Anything else might be\n // temporary, so it only counts against the retry budget.\n const gone = res.status === 404 || res.status === 410;\n await db.pushFailed(id, gone);\n console.warn(`push ${res.status} ${gone ? \"(dropping device)\" : \"\"} ${origin}`);\n } catch (err) {\n await db.pushFailed(id, false);\n console.warn(\"push threw\", String(err).slice(0, 120));\n }\n }));\n\n if (sent) console.log(`pushed ${sent} device(s)`);\n return sent;\n}\n\n/**\n * Prove the signing path works, without needing a real device.\n *\n * Worth having as its own thing because every failure mode here is silent: an\n * unset key, a JWK the runtime will not import, a signature in the wrong\n * encoding. All of them look identical from the outside — notifications simply\n * never arrive — and none of them show up until somebody is waiting.\n *\n * Returns the JWT so its signature can be checked against the public key\n * offline, which is the only way to be sure the pair actually matches.\n */\nexport async function selfTest(): Promise> {\n const key = await signingKey();\n if (!key) return { ok: false, why: \"VAPID_PRIVATE_KEY not set\" };\n\n try {\n const jwt = await vapidJwt(\"https://example.push-service.invalid\", key);\n const parts = jwt.split(\".\");\n return {\n ok: parts.length === 3,\n publicKey: VAPID_PUBLIC_KEY,\n jwt,\n signatureBytes: fromB64url(parts[2]).length, // must be 64 for ES256\n devices: (await db.livePushSubs()).length,\n };\n } catch (err) {\n return { ok: false, why: String(err).slice(0, 200) };\n }\n}\n\n/**\n * The service worker.\n *\n * Served from the ROOT, not from /m — a service worker can only control pages\n * at or below its own path, and one registered at /m could not later cover\n * anything else on the origin.\n */\nexport const SERVICE_WORKER = `\nself.addEventListener('push', function (event) {\n // The push carried nothing, by design. Go and find out what happened —\n // this request is same-origin and carries the session cookie.\n event.waitUntil(\n fetch('/api/m/alert', { credentials: 'include' })\n .then(function (r) { return r.ok ? r.json() : null; })\n .then(function (d) {\n if (!d) {\n // Signed out, or the credential was revoked. Say nothing rather than\n // showing an empty banner somebody cannot act on.\n return;\n }\n return self.registration.showNotification(d.title || 'Tribeca Chat', {\n body: d.body || '',\n // A stable tag means a second alert about the SAME conversation\n // replaces the first instead of stacking another banner.\n tag: d.tag || 'tribeca-chat',\n data: { url: d.url || '/m' },\n badge: '/icon.png',\n icon: '/icon.png',\n requireInteraction: false\n });\n })\n .catch(function () {})\n );\n});\n\nself.addEventListener('notificationclick', function (event) {\n event.notification.close();\n var url = (event.notification.data && event.notification.data.url) || '/m';\n event.waitUntil(\n clients.matchAll({ type: 'window', includeUncontrolled: true }).then(function (list) {\n // Reuse the window that is already open rather than stacking another\n // copy of the app on every notification.\n for (var i = 0; i < list.length; i++) {\n if (list[i].url.indexOf('/m') !== -1 && 'focus' in list[i]) {\n list[i].navigate(url);\n return list[i].focus();\n }\n }\n return clients.openWindow(url);\n })\n );\n});\n`;\n",[164],"e7bfb9ed-8217-466e-8bcb-475def3a4a34","office.ts","f00c6280-a95b-11f1-8121-1607ee4eb77e",629,["D",1788634820646],"// Office contact — email relay for chat requests that need a human.\n//\n// Several existing rules already send a visitor to the office: account\n// changes, billing, moving or skipping a delivery, anything on an existing\n// customer's account. Until now that meant reading them the phone number\n// and email and leaving it there. This lets the bot relay the request by\n// email itself, once the visitor has confirmed they want it sent.\n//\n// THE ADDRESS IS NEVER SOMETHING THE MODEL SUPPLIES. It always comes from\n// visitor.email, which main.ts's enrich() resolves and stores in code before\n// aiReply ever runs — the same guarantee create_account and submit_lead rely\n// on elsewhere in this project. A tool that trusted a model-typed email\n// could send the office a request with no way to reply to the actual\n// visitor, or let a message be sent under someone else's address.\n//\n// DELIVERY GOES THROUGH tribeca-sms-6466812965-email-relay, NOT A SENDGRID\n// KEY HELD HERE. That val already has a working, verified SendGrid setup\n// (it emails info@tribecabeverage.com from info@tribecabeverage.com today\n// for the SMS relay) — this val's plain std/email can only reach the val\n// owner's own inbox on the current (free) Val Town plan, confirmed live\n// 9/5/2026. Rather than duplicate the SendGrid credential onto a second val,\n// this calls that val's /notify endpoint, gated by a shared OFFICE_RELAY_KEY\n// set on both vals. If OFFICE_RELAY_KEY or the relay call is ever unset or\n// unreachable, this falls back to std/email so the visitor's request is\n// never silently dropped — it just lands in the val owner's own inbox\n// instead of info@ until the relay is fixed.\nimport { email as sendStdEmail } from \"https://esm.town/v/std/email\";\n\n// Where mail actually lands is decided by the relay val (NOTIFY_TO there),\n// currently info@tribecabeverage.com.\nconst RELAY_URL = \"https://tribeca-sms-relay-6466812965.val.run/notify\";\n\nasync function deliver(subject: string, text: string, replyTo: string): Promise {\n const relayKey = Deno.env.get(\"OFFICE_RELAY_KEY\");\n if (relayKey) {\n const res = await fetch(RELAY_URL, {\n method: \"POST\",\n headers: {\n \"x-api-key\": relayKey,\n \"Content-Type\": \"application/json\",\n },\n body: JSON.stringify({ subject, text, replyTo }),\n signal: AbortSignal.timeout(8000),\n });\n if (!res.ok) {\n const detail = await res.text().catch(() => \"\");\n throw new Error(`notify relay ${res.status}: ${detail.slice(0, 300)}`);\n }\n return;\n }\n\n // Fallback while OFFICE_RELAY_KEY is unset: no `to` — std/email delivers\n // to the val owner's own address, the one address the free plan will\n // actually deliver to.\n await sendStdEmail({ subject, text, replyTo });\n}\n\nexport async function emailOffice(\n visitor: any,\n input: { message?: string },\n): Promise<{ ok: boolean; reason?: string }> {\n const message = String(input?.message ?? \"\").trim();\n if (!message) return { ok: false, reason: \"no message given\" };\n\n const visitorEmail = visitor?.[\"email\"];\n if (!visitorEmail) return { ok: false, reason: \"no verified email on file\" };\n\n const who = visitor?.[\"name\"] || visitorEmail;\n const lines = [\n `New chat request for the office.`,\n ``,\n `From: ${who} <${visitorEmail}>`,\n ];\n if (visitor?.[\"phone\"]) lines.push(`Phone: ${visitor[\"phone\"]}`);\n if (visitor?.[\"sf_account\"]) lines.push(`Account: ${visitor[\"sf_account\"]}`);\n if (visitor?.[\"page_url\"]) lines.push(`On: ${visitor[\"page_url\"]}`);\n lines.push(``, `Message:`, message);\n\n try {\n await deliver(`CHAT CUSTOMER INQUIRY — ${who}`, lines.join(\"\\n\"), visitorEmail);\n console.log(`contact_office -> OK (${visitorEmail})`);\n return { ok: true };\n } catch (err) {\n console.error(\"contact_office email failed:\", err);\n return { ok: false, reason: \"send failed\" };\n }\n}\n",[172],"ce33f2e0-035d-41ae-94c0-207a392659d2","nudge.ts","f181f084-a64b-11f1-9888-1607ee4eb77e",142,["D",1788298052921],"interval","// Idle re-engagement sweep.\n//\n// The AI only ever speaks when spoken to: aiReply runs inside the visitor's own\n// POST. So a conversation that gets going and then stops has nothing to restart\n// it, and someone who was two questions away from ordering just leaves. This is\n// the one thing in the system that runs on a clock rather than on a request.\n//\n// WHO gets nudged is decided entirely in SQL, by db.listNudgeCandidates. That is\n// on purpose — \"should we interrupt this person\" is a rule, not a judgement, and\n// rules belong somewhere you can read them all at once. This file only walks the\n// list the query returns.\n\nimport * as db from \"./db.ts\";\nimport { nudgeReply } from \"./agent.ts\";\n\n// Long enough that we are not talking over someone mid-thought, short enough\n// that they are plausibly still on the page. Under three minutes it reads as\n// impatient; past thirty they have gone, and a message arriving then is a\n// notification from a shop they left, not a helpful offer.\nconst IDLE_AT_LEAST_MS = 3 * 60 * 1000;\nconst IDLE_AT_MOST_MS = 30 * 60 * 1000;\n\n// A ceiling per run, not per day. Each nudge is a model call, and a burst of\n// them on a busy afternoon should queue across sweeps rather than arrive as one\n// spike — the ORDER BY is oldest-idle-first, so nobody is starved.\nconst PER_RUN = 5;\n\nexport default async function () {\n await db.init();\n\n const candidates = await db.listNudgeCandidates(\n IDLE_AT_LEAST_MS,\n IDLE_AT_MOST_MS,\n PER_RUN,\n );\n if (!candidates.length) return;\n\n for (const row of candidates) {\n const cid = String(row[\"id\"]);\n\n // Claimed BEFORE the model call, so a failure costs this conversation its\n // one nudge instead of leaving it eligible on every future sweep.\n await db.markNudged(cid);\n\n // Re-read after claiming. An agent can have picked the conversation up in\n // the seconds since the query ran, and the bot talking over a human who has\n // just said hello is the single worst thing this feature could do.\n const conv = await db.getConversation(cid);\n if (!conv || String(conv[\"status\"]) !== \"ai\") {\n console.log(`nudge skipped ${cid}: status ${conv?.[\"status\"] ?? \"gone\"}`);\n continue;\n }\n\n const history = await db.getMessages(cid);\n const visitor = await db.getVisitor(String(row[\"visitor_id\"]));\n\n const text = await nudgeReply(history, visitor);\n if (!text) continue;\n\n await db.addMessage(cid, \"ai\", text);\n console.log(`nudged ${cid}: ${text}`);\n }\n}\n",[179],"c5afc3c5-04dc-4d57-a3d4-c7cfe3d6e20d","notify.ts","1d3300c6-a5a5-11f1-8182-1607ee4eb77e",405,["D",1788390913472],7,"// Handoff notification — Telegram.\n//\n// THIS IS THE LOAD-BEARING PIECE OF THE WHOLE PROJECT.\n//\n// A custom widget is easy; an agent console is a weekend. What kept Tribeca on\n// tawk was its mobile app: the team needs to KNOW a customer is waiting while\n// away from a desk. Telegram supplies real push notifications on iOS and\n// Android with no app to build and nothing to pay.\n//\n// The cut-over decision from tawk rests entirely on whether these arrive\n// reliably. Until the team trusts them, both systems run in parallel.\n\nimport { pushAll } from \"./push.ts\";\n\nconst API = \"https://api.telegram.org/bot\";\n\n/** One place that knows how to reach Telegram, so both alerts behave alike. */\nasync function send(lines: string[], what: string): Promise {\n const token = Deno.env.get(\"TELEGRAM_BOT_TOKEN\");\n const chatId = Deno.env.get(\"TELEGRAM_CHAT_ID\");\n\n if (!token || !chatId) {\n // Loud, because silence here is indistinguishable from \"nobody replied\".\n console.error(`${what} UNNOTIFIED — TELEGRAM_BOT_TOKEN/TELEGRAM_CHAT_ID not set`);\n return false;\n }\n\n try {\n const res = await fetch(`${API}${token}/sendMessage`, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify({\n chat_id: chatId,\n text: lines.join(\"\\n\"),\n parse_mode: \"HTML\",\n disable_web_page_preview: true,\n }),\n signal: AbortSignal.timeout(8000),\n });\n\n if (!res.ok) {\n const detail = await res.text().catch(() => \"\");\n console.error(`${what} UNNOTIFIED — Telegram ${res.status}`, detail.slice(0, 200));\n return false;\n }\n return true;\n } catch (err) {\n console.error(`${what} UNNOTIFIED — Telegram threw`, err);\n return false;\n }\n}\n\n/**\n * Deep link into the console, opened straight on this conversation.\n *\n * DELIBERATELY NOT DASHBOARD_URL. That points at the Visualforce console,\n * which is three fixed columns with no viewport tag — the page whose rows\n * cannot be tapped on a phone. A push notification is read on a phone\n * essentially by definition, so sending it to the desktop console lands\n * somebody on the one screen they cannot act from. This goes to /m.\n *\n * NOTIFY_LINK_URL overrides it, for anyone who wants the old behaviour back\n * without editing code.\n */\nconst CONSOLE_URL = \"https://tribeca-chat.val.run/m\";\n\nfunction link(conversationId: string): string[] {\n const base = Deno.env.get(\"NOTIFY_LINK_URL\") || CONSOLE_URL;\n return [\"\", `${base}?c=${encodeURIComponent(conversationId)}`];\n}\n\n/**\n * SOMEBODY HAS ACTUALLY STARTED TALKING — not a handoff, just a real person\n * typing into the widget for the first time.\n *\n * Separate from notifyHandoff because they answer different questions.\n * A handoff means \"come now, someone is waiting for a human\". This means \"a\n * conversation is happening\", which is worth knowing while the bot is still\n * handling it — the bot may be doing fine, or may be about to lose a sale.\n *\n * OFF UNLESS ASKED FOR, via NOTIFY_EVERY_CHAT. Volume is a judgement about the\n * business, not about the code: on a busy day this is every visitor who says\n * hello, and an alert that fires too often gets muted, which would take the\n * handoff alerts down with it.\n *\n * FIRST MESSAGE ONLY. The count is what keeps one chatty visitor from buzzing\n * a phone nine times.\n */\nexport async function notifyFirstMessage(\n conversationId: string,\n conv: any,\n text: string,\n): Promise {\n if (Deno.env.get(\"NOTIFY_EVERY_CHAT\") !== \"1\") return false;\n\n // Push and Telegram are alternatives, so this fires whether or not Telegram\n // is configured — the same reasoning as notifyHandoff above.\n const pushed = await pushAll().catch(() => 0);\n\n const who = conv?.[\"name\"] || conv?.[\"email\"] || conv?.[\"phone\"] || \"Someone\";\n const lines = [\n `${esc(who)} started a chat`,\n ``,\n esc(String(text).slice(0, 300)),\n ];\n if (conv?.[\"sf_account\"]) lines.push(``, `Account: ${esc(conv[\"sf_account\"])}`);\n if (conv?.[\"page_url\"]) lines.push(`On: ${esc(conv[\"page_url\"])}`);\n lines.push(...link(conversationId));\n\n const ok = await send(lines, \"CHAT-START\");\n if (ok) console.log(`chat-start notified ${conversationId}`);\n return ok || pushed > 0;\n}\n\nfunction esc(s: string): string {\n // Telegram HTML parse mode. Only these three need escaping, and a customer\n // typing \"<3\" must not break the message.\n return String(s ?? \"\")\n .replace(/&/g, \"&\")\n .replace(//g, \">\");\n}\n\n/**\n * Fire a push when a conversation flips to needs_human.\n *\n * Awaited by the caller before its response returns — see the teardown note in\n * main.ts. A dropped notification means a customer waiting with nobody aware\n * of it, which is the worst failure this system has.\n */\nexport async function notifyHandoff(conversationId: string, conv: any): Promise {\n // WEB PUSH FIRST, AND INDEPENDENTLY OF TELEGRAM.\n //\n // This used to return early when the Telegram variables were unset, which\n // meant a team without Telegram got no alert at all — the exact situation\n // Tribeca is in. Push goes to the phone console people already have on their\n // home screen, so the two are alternatives, not a chain: whichever is\n // configured fires, and neither can suppress the other.\n const pushed = await pushAll().catch(() => 0);\n\n const token = Deno.env.get(\"TELEGRAM_BOT_TOKEN\");\n const chatId = Deno.env.get(\"TELEGRAM_CHAT_ID\");\n\n if (!token || !chatId) {\n if (!pushed) {\n // Loud, because silence here is indistinguishable from \"nobody replied\".\n console.error(\"HANDOFF UNNOTIFIED — no push devices and no Telegram\", conversationId);\n }\n return pushed > 0;\n }\n\n const who = conv?.[\"name\"] || conv?.[\"email\"] || conv?.[\"phone\"] || \"Anonymous visitor\";\n\n // Everything an agent needs to decide whether to pick it up, without opening\n // anything. Salesforce context included when we have it — that is the whole\n // point of resolving the account before the handoff rather than after.\n const lines = [\n `Someone is waiting to chat`,\n ``,\n `${esc(who)}`,\n ];\n\n if (conv?.[\"sf_account\"]) {\n lines.push(`Account: ${esc(conv[\"sf_account\"])}`);\n }\n if (conv?.[\"sf_next_delivery\"]) {\n lines.push(`Next delivery: ${esc(conv[\"sf_next_delivery\"])}`);\n }\n if (conv?.[\"phone\"]) lines.push(`Phone: ${esc(conv[\"phone\"])}`);\n if (conv?.[\"page_url\"]) lines.push(`On: ${esc(conv[\"page_url\"])}`);\n\n lines.push(...link(conversationId));\n\n try {\n const res = await fetch(`${API}${token}/sendMessage`, {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify({\n chat_id: chatId,\n text: lines.join(\"\\n\"),\n parse_mode: \"HTML\",\n disable_web_page_preview: true,\n }),\n signal: AbortSignal.timeout(8000),\n });\n\n if (!res.ok) {\n const detail = await res.text().catch(() => \"\");\n console.error(`HANDOFF UNNOTIFIED — Telegram ${res.status}`, detail.slice(0, 200));\n return false;\n }\n\n console.log(`handoff notified ${conversationId}`);\n return true;\n } catch (err) {\n console.error(\"HANDOFF UNNOTIFIED — Telegram threw\", err);\n return false;\n }\n}\n",[187],"0103cf55-d427-4c9f-b436-eabf5cf9734b","mobile.ts","a88ee85e-a6f6-11f1-960e-1607ee4eb77e",560,["D",1788532431969],42,"// Tribeca Chat — the console, for a phone.\n//\n// WHY THIS EXISTS RATHER THAN A CSS FIX TO THE SALESFORCE PAGE\n// The Visualforce console is three fixed columns — 312px of conversation list,\n// 344px of visitor detail — with no viewport tag and no media queries. On a\n// phone it renders the desktop layout scaled down, and the conversation rows\n// end up too small and too far off-canvas to tap. That page is still the right\n// tool at a desk. This one is for the times somebody is not at a desk.\n//\n// IT IS ONE PANE AT A TIME, ON PURPOSE. A phone cannot show a list, a thread\n// and a detail panel at once, and shrinking all three until they fit is how\n// the Salesforce page became untappable. So: list, or thread. Never both.\n//\n// INFORMATION PARITY WITH THE DESKTOP CONSOLE IS THE POINT.\n// The first cut of this page showed six fields where Salesforce showed\n// fourteen, and no actions at all — which made it a notification screen you\n// could type into rather than a console. Everything the desktop page can tell\n// you, this now tells you: time on site ticking live, where they came from,\n// what they landed on and whether it existed, device, visits, pages viewed,\n// what the bot already said to them unprompted, and whether they have gone.\n// The one thing it cannot do is Salesforce account search, which is Apex and\n// genuinely not available from here.\n//\n// AUTHENTICATION IS PER PERSON, NOT A SHARED PASSWORD.\n// This console reads every visitor's name, email, phone and full transcript,\n// and it sends messages to customers AS TRIBECA. One shared secret guarding\n// that cannot answer \"who sent that\", cannot be revoked for one person, and\n// ends up in a group chat. Each person gets their own credential — a name and\n// passcode, or a token — and the server, not the browser, decides whose name\n// goes on a message.\n//\n// THE CREDENTIAL IS EXCHANGED FOR AN HttpOnly COOKIE and then forgotten. It is\n// never held in localStorage — which is precisely where the desktop dashboard\n// keeps the shared key, readable by any script that ever runs on the page.\n\nexport const MOBILE_HTML = `\n\n\n\n\n\n\n\n\n\n\n\nTribeca Chat\n\n

\n\n

\n \n $\"\"$ \n

Tribeca Chat

\n \n \n \n

\n\n

Sign in

Your own name and passcode. Not a shared login — whatever you\n send to a customer is signed with your name.

\n Your name\n \n Passcode\n \n \n

\n \n \n \n

\n\n

\n \n

\n \n \n \n

\n\n

This starts a new conversation — they have not written in.

\n \n\n

\n\n`;\n",[195],"0e539802-50cf-4a2b-9a2a-6da279ff298f","main.ts",639,["D",1788732695719],125,"http","// Tribeca Chat — HTTP entry point\n//\n// Visitor routes are public. Agent routes sit behind AGENT_KEY.\n//\n// TWO VAL TOWN CONSTRAINTS SHAPE THIS WHOLE FILE:\n//\n// 1. Work awaited AFTER a streaming response body completes is torn down\n// silently, with nothing in the logs. That is what broke lead extraction in\n// tribeca-afterhours-chat. So the AI turn is finished and persisted BEFORE\n// the visitor's POST returns, and the SSE stream never owns real work.\n//\n// 2. Requests may be served by different isolates, so an in-memory pub/sub\n// fan-out would deliver to whichever isolate happened to hold the\n// subscriber. The SSE streams therefore poll SQLite against a cursor. It\n// costs a query per second per open chat and is correct regardless of how\n// Val Town schedules isolates — the right trade at this volume.\n\nimport { Hono } from \"npm:hono\";\n// The real logo, stored as a val-scoped blob rather than embedded in source\n// — see the /icon.png route for why (SVG-vs-PNG, and why it is not a\n// giant base64 string sitting in this file).\nimport { blob } from \"https://esm.town/v/std/blob/main.ts\";\nimport * as db from \"./db.ts\";\nimport { aiReply, anthropicKey, nudgeReply } from \"./agent.ts\";\nimport {\n invoiceStatus,\n lookupByPhone,\n lookupLead,\n offerChatCoupon,\n scanFor35PercentClaim,\n scanForEmail,\n scanForPhone,\n} from \"./salesforce.ts\";\nimport { notifyFirstMessage, notifyHandoff } from \"./notify.ts\";\nimport { WIDGET_JS } from \"./widget.ts\";\nimport { DASHBOARD_HTML } from \"./dashboard.ts\";\nimport { MOBILE_HTML } from \"./mobile.ts\";\nimport { pushAll, SERVICE_WORKER, selfTest, VAPID_PUBLIC_KEY } from \"./push.ts\";\nimport { countryFrom, deviceFrom, optedOut } from \"./context.ts\";\nimport { openingGreeting, pageNudge } from \"./greeting.ts\";\n// Surfaced on /health so a stale shared profile is VISIBLE. Val Town caches\n// remote module imports, so editing tribeca-profile does not by itself change\n// what a running isolate sees — and the failure is silent: the bot keeps\n// quoting last week's prices perfectly confidently.\n// OFFICE_* are used by the callback-details flow at the bottom of this file.\n// Taken from the shared profile rather than typed here, so a changed number or\n// a change of opening hours cannot leave this one path quoting the old ones.\nimport {\n OFFICE_EMAIL,\n OFFICE_HOURS,\n OFFICE_PHONE,\n PROFILE_VERSION,\n} from \"https://esm.town/v/Tribeca_Rep/tribeca-profile/profile.ts?v=2026-09-04b\";\n\nconst app = new Hono();\n\n// The widget runs on tribecabeverage.com and the console may run inside\n// Salesforce, so every API call is cross-origin.\n//\n// The visitor endpoints are open by necessity: a browser on the storefront has\n// no credential to present, and locking them to an Origin header would be\n// theatre — Origin is trivially forged outside a browser. What actually\n// protects them is that they only ever act on the conversation id they are\n// given, and that ids are unguessable. The agent endpoints are the ones that\n// matter, and those check AGENT_KEY.\napp.use(\"*\", async (c, next) => {\n const origin = c.req.header(\"origin\") ?? \"*\";\n\n if (c.req.method === \"OPTIONS\") {\n return new Response(null, {\n status: 204,\n headers: {\n \"Access-Control-Allow-Origin\": origin,\n \"Access-Control-Allow-Methods\": \"GET,POST,OPTIONS\",\n \"Access-Control-Allow-Headers\": \"Content-Type,x-agent-key\",\n \"Access-Control-Max-Age\": \"86400\",\n },\n });\n }\n\n await next();\n c.res.headers.set(\"Access-Control-Allow-Origin\", origin);\n c.res.headers.set(\"Vary\", \"Origin\");\n});\n\nconst AGENT_KEY = () => Deno.env.get(\"AGENT_KEY\") ?? \"\";\n\n// How often an open stream checks for new messages. One second reads as\n// instant to a person and keeps the query count sane.\nconst POLL_MS = 1000;\n\n// A stream is closed after this long so an abandoned tab cannot poll forever.\n// The widget reconnects, so the customer never notices.\nconst STREAM_MAX_MS = 5 * 60 * 1000;\n\nfunction agentAuthed(c: any): boolean {\n const key = AGENT_KEY();\n if (!key) return false; // Fail closed: unset key locks the dashboard, not opens it.\n const supplied = c.req.header(\"x-agent-key\") ?? new URL(c.req.url).searchParams.get(\"key\");\n return supplied === key;\n}\n\n/* ------------------------------------------------- per-person sessions */\n\nconst MOBILE_COOKIE = \"tbm\";\nconst MOBILE_DAYS = 30;\n\n/**\n * Length-checked, difference-accumulating compare.\n *\n * `a === b` on a secret returns as soon as two bytes differ, and how long that\n * took is measurable. It is a thin channel and a real one, and the fix costs\n * nothing.\n */\nfunction safeEq(a: string, b: string): boolean {\n if (a.length !== b.length) return false;\n let diff = 0;\n for (let i = 0; i < a.length; i++) diff |= a.charCodeAt(i) ^ b.charCodeAt(i);\n return diff === 0;\n}\n\nfunction readCookie(c: any, name: string): string | null {\n const header = c.req.header(\"cookie\") ?? \"\";\n for (const part of header.split(\";\")) {\n const eq = part.indexOf(\"=\");\n if (eq < 0) continue;\n if (part.slice(0, eq).trim() === name) {\n return decodeURIComponent(part.slice(eq + 1).trim());\n }\n }\n return null;\n}\n\n/**\n * The cookie signing key is DERIVED from AGENT_KEY, not equal to it.\n *\n * One root secret, two purposes, and they must not be interchangeable: a\n * signed cookie should never be usable as a master key, and vice versa. The\n * suffix is what separates them, and it is versioned so the derivation can be\n * changed later without ambiguity.\n */\nasync function cookieKey(): Promise {\n const master = AGENT_KEY();\n if (!master) return null;\n return await crypto.subtle.importKey(\n \"raw\",\n new TextEncoder().encode(master + \"|tribeca-mobile-cookie-v1\"),\n { name: \"HMAC\", hash: \"SHA-256\" },\n false,\n [\"sign\"],\n );\n}\n\nasync function signSession(tid: string, expires: number): Promise {\n const k = await cookieKey();\n if (!k) return \"\";\n const sig = await crypto.subtle.sign(\n \"HMAC\",\n k,\n new TextEncoder().encode(tid + \".\" + expires),\n );\n return [...new Uint8Array(sig)].map((b) => b.toString(16).padStart(2, \"0\")).join(\"\");\n}\n\n/**\n * WHO is making this request — not merely whether they are allowed to.\n *\n * Replaces the old boolean. The distinction is the entire point of per-person\n * tokens: the console can message customers as Tribeca, so \"authorised\" is\n * only half an answer and \"who sent that\" needs the other half.\n *\n * TWO CREDENTIALS, DELIBERATELY:\n *\n * 1. AGENT_KEY — the desktop dashboard and the Salesforce console, which\n * authenticate their users through Salesforce and hold this key server\n * side. Reported as \"Team\", which is what those surfaces already sent.\n * 2. A session cookie — one person, from the phone console.\n *\n * The DB is consulted on every cookie request rather than trusting the\n * signature alone. The signature only proves we issued it; the lookup proves\n * it has not since been revoked, which is what makes revocation immediate\n * instead of taking effect whenever a 30-day cookie happens to lapse.\n */\nasync function whoIsAgent(\n c: any,\n): Promise<{ person: string; tokenId: string | null } | null> {\n const key = AGENT_KEY();\n if (!key) return null; // Fail closed, exactly as before.\n\n const supplied = c.req.header(\"x-agent-key\") ?? new URL(c.req.url).searchParams.get(\"key\");\n if (supplied && safeEq(String(supplied), key)) {\n return { person: \"Team\", tokenId: null };\n }\n\n const raw = readCookie(c, MOBILE_COOKIE);\n if (!raw) return null;\n\n const parts = raw.split(\".\");\n if (parts.length !== 3) return null;\n\n const [tid, expStr, sig] = parts;\n const expires = Number(expStr);\n if (!Number.isFinite(expires) || expires < Date.now()) return null;\n\n const expected = await signSession(tid, expires);\n if (!expected || !safeEq(sig, expected)) return null;\n\n await db.init();\n const tok = await db.agentTokenById(tid);\n if (!tok) return null;\n\n return { person: String(tok[\"person\"]), tokenId: tid };\n}\n\n/* ---------------------------------------------------------------- visitor */\n\napp.post(\"/api/session\", async (c) => {\n await db.init();\n const body = await c.req.json().catch(() => ({}));\n\n // The widget generates and persists this in localStorage, so a returning\n // visitor keeps their history and their Salesforce match.\n const visitorId = String(body.visitorId || db.id(\"v\"));\n\n // Someone signalling Global Privacy Control still gets a working chat; they\n // just do not get a profile built around them.\n const quiet = optedOut(body);\n const device = quiet ? { os: null, browser: null } : deviceFrom(c.req.header(\"user-agent\"));\n\n await db.upsertVisitor({\n id: visitorId,\n name: body.name ?? null,\n email: body.email ?? null,\n phone: body.phone ?? null,\n zip: body.zip ?? null,\n company: body.company ?? null,\n wpUserId: body.wpUserId ?? null,\n pageUrl: body.pageUrl ?? null,\n country: quiet ? null : countryFrom(c.req.raw.headers),\n os: device.os,\n browser: device.browser,\n });\n\n const conversationId = await db.openConversation(visitorId);\n const messages = await db.getMessages(conversationId);\n\n // A known phone or email from WordPress is looked up immediately, so an\n // agent picking up the chat already has the account (or lead) on screen.\n // Awaited deliberately: this response is not streamed, so there is no\n // teardown risk here.\n //\n // EMAIL ALONE NOW QUALIFIES. It used to take a phone to trigger this at\n // all, which meant a signed-in customer known only by email — the WP\n // snippet's whole point — never got checked. That gap is also exactly the\n // popup-lead case: no phone captured there, ever, only an email.\n if (body.phone || body.email) {\n await enrich(visitorId, body.phone ? String(body.phone) : null, body.email ? String(body.email) : null);\n }\n\n // THE OPENER IS BUILT HERE, NOT IN THE WIDGET.\n //\n // It needs the ZIP, and the ZIP may have arrived from somewhere the browser\n // cannot see — a WooCommerce login, an earlier form submission, a checkout —\n // so the stored visitor row is the authority rather than whatever this page\n // happened to post. That read is also what lets a returning visitor be\n // greeted with their own region's price on a page that knows nothing.\n //\n // Both lines are sent every time and are cheap to ignore: the widget only\n // shows the greeting when the thread is empty, and only shows the nudge if\n // the greeting goes unanswered.\n const known = await db.getVisitor(visitorId);\n const zip = known?.[\"zip\"] ?? body.zip ?? null;\n\n // A CONFIRMED SALESFORCE MATCH, not merely a phone number typed in chat —\n // enrich() only sets sf_account once lookupByPhone has actually found an\n // account, so this is never a guess. Decides whether the opener and nudge\n // pitch a sale at someone we already deliver to. See openingGreeting.\n const isCustomer = !!known?.[\"sf_account\"];\n\n // The page matters as well as the ZIP: the glass product page gets its own\n // opener, because someone standing on it has already chosen the subject.\n //\n // The visitor id is passed for the split test. It decides which of the five\n // opener variants this person gets, by a hash rather than a coin toss, so\n // the same visitor sees the same line on every page and cannot be counted\n // under two variants at once.\n const opener = openingGreeting(\n zip,\n body.pageUrl ?? null,\n visitorId,\n isCustomer,\n known?.[\"referrer\"] ?? body.referrer ?? null,\n );\n const greeting = opener.text;\n\n // AN EMPTY THREAD MEANS THE WIDGET IS ABOUT TO DRAW THIS GREETING — that is\n // the exact condition it renders on. Recording it here rather than waiting\n // for the widget to report back means the console can show what a visitor was\n // sent straight away, for everybody, instead of only for browsers that have\n // picked up a new widget.js past its five-minute cache.\n //\n // AND IT IS STORED AS A REAL MESSAGE, which it was not until 9/1/2026.\n //\n // THE BUG THIS FIXES, seen in a live chat: the opener offered 25% off, the\n // visitor answered \"Ok\", and the assistant replied \"Hi there! What can I\n // help you with today?\" — because the opener lived only in the visitor's\n // browser and was never part of the conversation the model was given. From\n // the model's side the transcript was one word, \"Ok\", with nothing to be OK\n // about. The visitor's next line was \"Well that failed\".\n //\n // Writing it here makes the opening line a message like any other: the model\n // sees what was offered, the agent console shows a real thread instead of a\n // greyed-out ghost, and the message counts stop reading zero on\n // conversations that plainly said something.\n let opened = messages;\n if (!messages.length) {\n await db.setShownOpener(visitorId, greeting, opener.variant);\n await db.addMessage(conversationId, \"ai\", greeting);\n // Re-read so the widget renders it from the thread instead of drawing its\n // own copy — otherwise the visitor sees the opener twice.\n opened = await db.getMessages(conversationId);\n }\n\n return c.json({\n visitorId,\n conversationId,\n messages: opened,\n greeting,\n // The variant goes with it so the follow-up does not repeat the opener —\n // on the glass page both were quoting the same three numbers, twenty-five\n // seconds apart, with nobody having spoken in between.\n nudge: pageNudge(\n body.pageUrl ?? null,\n opener.variant,\n isCustomer,\n known?.[\"referrer\"] ?? body.referrer ?? null,\n ),\n });\n});\n\n// A handoff older than this with no agent reply yet gets handed back to the\n// bot on the visitor's next message — see the HANDBACK_MS check below.\nconst HANDBACK_MS = 2 * 60 * 1000;\n\napp.post(\"/api/message\", async (c) => {\n await db.init();\n const { conversationId, body: text, pageUrl } = await c.req.json();\n\n if (!conversationId || !text || !String(text).trim()) {\n return c.json({ error: \"conversationId and body required\" }, 400);\n }\n\n const conv = await db.getConversation(conversationId);\n if (!conv) return c.json({ error: \"unknown conversation\" }, 404);\n\n await db.addMessage(conversationId, \"visitor\", String(text).slice(0, 4000));\n\n let status = String(conv[\"status\"]);\n const visitorId = String(conv[\"visitor_id\"]);\n\n // PAGE_URL, RIGHT NOW, NOT WHENEVER THE NEXT HEARTBEAT HAPPENS TO LAND.\n //\n // Presence pings every 45s, so a visitor who navigates to a product page\n // and types within that window was, until now, quoted off whatever page\n // they were on up to 45 seconds ago — which is exactly how a visitor on\n // the GLASS product page got quoted PLASTIC Pennsylvania pricing on\n // 9/4/2026: the opener and nudge that started the conversation were both\n // generic, meaning page_url was still stale when browsingBlock() ran for\n // the pricing turn. Cheap to fix at the one place it actually matters —\n // the instant before the model is asked anything.\n if (pageUrl) {\n await db.upsertVisitor({ id: visitorId, pageUrl: String(pageUrl) });\n }\n\n // Scan every visitor message for a phone number and resolve it against\n // Salesforce in code. The model is never asked to decide whether to look\n // something up — it only ever receives a verified result as fact. This is\n // the single most important design decision in the project: tawk's agent had\n // the same tool wired and simply never called it.\n const phone = scanForPhone(String(text));\n // AN EMAIL TYPED INTO CHAT IS THE OTHER HALF OF THE POPUP CASE. A visitor\n // who fills out the site's popup and later says \"it's jane@...\" in chat has\n // just handed us the only field that Lead lookup can actually match on.\n const email = scanForEmail(String(text));\n if (phone || email) {\n // Is this the FIRST email we've seen for this visitor? enrich's\n // setVisitorEmail COALESCEs, so visitor.email is whatever we saw first — a\n // null here means this message is introducing it. Checked BEFORE enrich\n // stores it. A signed-in customer (email already known from the widget) or\n // anyone who gave it earlier reads as \"already knew\", so is never re-offered.\n const knewEmail = email ? !!(await db.getVisitor(visitorId))?.email : true;\n await enrich(visitorId, phone, email);\n // New email in chat -> mint a real 25%-off code that expires in 24h and let\n // Salesforce email it (the code, then the reminder + last-call drip). The WP\n // endpoint dedups again on its side, so an existing Lead/customer whose email\n // we happen to meet for the first time in chat still isn't couponed twice.\n // Awaited on purpose: work left running after the response returns is torn\n // down on Val Town, so a fire-and-forget coupon would often never mint.\n if (email && !knewEmail) await offerChatCoupon(email, undefined, scanFor35PercentClaim(String(text)) ? 35 : undefined);\n }\n\n // \"SOMEBODY IS TALKING TO US\", as distinct from \"somebody wants a human\".\n //\n // The handoff alert below only fires when a visitor asks for a person, which\n // is a small fraction of real conversations — so a chat could run start to\n // finish with nobody on the team ever knowing it happened. On the FIRST\n // visitor message only, and only when NOTIFY_EVERY_CHAT is on.\n //\n // Awaited, for the teardown reason at the top of this file: work left running\n // after the response body completes is torn down silently.\n if (await db.visitorMessageCount(conversationId) === 1) {\n await notifyFirstMessage(conversationId, conv, String(text));\n }\n\n // An agent has taken over: the AI must stay silent. Not a prompt\n // instruction — a branch.\n if (status === \"human\" || status === \"closed\") {\n return c.json({ ok: true, ai: false });\n }\n\n // GIVE IT BACK TO THE BOT if a handoff has sat unanswered for HANDBACK_MS.\n //\n // A cron sweep can't reach 2-minute granularity here — Val Town's free-tier\n // floor on interval delays is 15 minutes (see nudge.ts, itself already\n // pinned at that floor), so this can't be a clock-driven check. Instead it\n // runs right here, on the visitor's own next message: if nobody has\n // actually replied since the handoff, silently resume AI handling instead\n // of leaving them parked on \"someone will be right with you\" indefinitely.\n //\n // hasAgentMessage, not merely \"status is still needs_human\" — an agent can\n // be mid-typing a first reply, and this must never yank the conversation\n // back to the bot out from under a human who is actually there.\n if (status === \"needs_human\") {\n const handoffAt = Number(conv[\"handoff_at\"] ?? 0);\n if (handoffAt && Date.now() - handoffAt > HANDBACK_MS && !(await db.hasAgentMessage(conversationId))) {\n await db.setStatus(conversationId, \"ai\");\n status = \"ai\";\n console.log(`handoff timed out with no agent reply, returned to bot: ${conversationId}`);\n }\n }\n\n if (status === \"needs_human\" || wantsHuman(String(text))) {\n if (status !== \"needs_human\") {\n await db.setStatus(conversationId, \"needs_human\");\n\n // ASK FOR A NAME AND A NUMBER, rather than saying \"connecting you\" and\n // going quiet.\n //\n // \"Connecting you with someone from the team\" is a promise the system\n // cannot keep on its own: nobody is guaranteed to be watching the\n // console, and out of hours nobody is. The customer sat there waiting\n // for a person who was not coming, and when they gave up we had nothing\n // — no name, no number, no way to win it back. A callback number turns\n // the worst case from a lost conversation into a lead.\n //\n // Skipped entirely when we already know both, which is the case for any\n // signed-in customer. Asking a customer for their own phone number is\n // how a system tells someone it does not know who they are.\n const v = await db.getVisitor(visitorId);\n await db.addMessage(conversationId, \"system\", handoffLine(v));\n\n // Awaited before returning, for the teardown reason at the top of this\n // file. A dropped handoff notification is a customer left waiting with\n // nobody aware of it — the worst failure this system can have.\n await notifyHandoff(conversationId, await db.getConversation(conversationId));\n return c.json({ ok: true, ai: false, handoff: true });\n }\n\n // ALREADY WAITING FOR A PERSON. The model stays out of it — they asked for\n // a human and carrying on selling at them would be the system ignoring what\n // it was just told. The only job left is taking the details.\n const collected = await takeContactDetails(conversationId, visitorId, String(text));\n return c.json({ ok: true, ai: false, handoff: true, collected });\n }\n\n const visitor = await db.getVisitor(visitorId);\n const history = await db.getMessages(conversationId);\n\n // Billing facts are fetched in code, like the account lookup — the model is\n // never asked to decide whether to check a balance. `wp_user_id` is the only\n // thing that counts as authentication here: it means WordPress verified a\n // session. A phone number the visitor typed does not, which is why the pay\n // link is withheld unless this is set.\n let invoice = null;\n if (visitor?.[\"phone\"]) {\n invoice = await invoiceStatus(\n String(visitor[\"phone\"]),\n !!visitor[\"wp_user_id\"],\n );\n }\n\n const replyStartedAt = Date.now();\n const reply = await aiReply(history, visitor, invoice, String(conversationId));\n\n // A SHORT REPLY THAT ARRIVES INSTANTLY READS AS A BOT. A person composing\n // \"sure, got it!\" still takes a beat even though it's four words; a real\n // paragraph takes longer than that. This only ever ADDS wait on top of\n // whatever the model already took, and it sits BEFORE the status re-check\n // below so an interruption during the pause is still caught fresh, exactly\n // like an un-padded reply always was.\n //\n // RAISED FROM A 2500ms CAP ON 9/4/2026 — flagged live as still reading too\n // fast for a longer message once the office was actually watching it. The\n // old cap meant a 250-character price breakdown and a 600-character one\n // waited the identical 2.5s, so length stopped mattering exactly where it\n // is most noticeable. 4000ms leaves real margin under the widget's 6-second\n // failure timeout even on a slow model call — the two numbers are not close\n // enough to trade against each other.\n //\n // ALL THREE NUMBERS SCALED 1.2x ON 9/5/2026, at the owner's request for a\n // slower-reading pace — floor, ceiling and per-character rate together, so\n // the shape of the curve (short replies hit the floor, long ones hit the\n // ceiling) is unchanged, just uniformly slower. The ceiling now leaves\n // 1200ms of margin under the widget's 6-second timeout instead of 2000ms —\n // still real margin, just worth re-checking if that timeout ever moves.\n if (reply) {\n const elapsed = Date.now() - replyStartedAt;\n const target = Math.min(4800, Math.max(480, reply.length * 19.2));\n if (elapsed < target) {\n await new Promise((r) => setTimeout(r, target - elapsed));\n }\n }\n\n // RE-READ THE STATUS. The check at the top of this handler is now several\n // seconds stale, and those seconds are exactly when a person is most likely\n // to step in — they step in BECAUSE they saw the customer's message.\n //\n // On 9/2/2026 this cost a real order: a visitor confirmed at 06:57:22, the\n // office corrected the product 215ms later, and the model — already thinking\n // — posted \"Everything's saved on my end\" 6.7 seconds after that, over the\n // top of a colleague who was mid-correction. The branch above was right and\n // simply ran too early to see it.\n const still = await db.getConversation(conversationId);\n const nowStatus = still ? String(still[\"status\"]) : status;\n if (nowStatus === \"human\" || nowStatus === \"closed\") {\n console.log(`AI reply DISCARDED — ${nowStatus} took over mid-turn ${conversationId}`);\n return c.json({ ok: true, ai: false, superseded: true });\n }\n if (reply) {\n await db.addMessage(conversationId, \"ai\", reply);\n return c.json({ ok: true, ai: true });\n }\n\n // THE MODEL PRODUCED NOTHING. Say so here rather than letting the widget\n // discover it by timing out: it waits six seconds before apologising, which\n // is six seconds of a visitor watching a typing indicator that will never\n // resolve. Written as a real message so it also lands in the transcript the\n // agent console shows — a failed turn the team can see is very different\n // from one only the customer experienced.\n await db.addMessage(\n conversationId,\n \"system\",\n \"Sorry — I couldn't put that together. Try rephrasing, or say you'd like to \"\n + \"talk to someone and I'll bring in the team.\",\n );\n return c.json({ ok: true, ai: false });\n});\n\n/**\n * Presence heartbeat. Runs on every page view, not just when the chat opens.\n *\n * Deliberately the cheapest endpoint here: one UPDATE, and two small reads only\n * when a conversation already exists. It is called far more often than anything\n * else, by people who may never chat at all.\n *\n * The response is what makes agent-initiated chat work: if someone from the\n * team has spoken to this visitor, the widget is told to open itself.\n */\napp.post(\"/api/presence\", async (c) => {\n await db.init();\n const body = await c.req.json().catch(() => ({}));\n const pageUrl = body.pageUrl ? String(body.pageUrl) : null;\n\n // No visitor id yet means a first page view. Create the record now rather\n // than waiting for a chat, otherwise nobody appears on the monitoring\n // screen until they decide to talk — which is the entire point of it.\n // Location and device are read off the request that is already arriving. The\n // IP that country is derived from is Cloudflare's to know — we never see a\n // need for it, never store it, and never send it anywhere. See context.ts.\n const quiet = optedOut(body);\n const country = quiet ? null : countryFrom(c.req.raw.headers);\n const device = quiet ? { os: null, browser: null } : deviceFrom(c.req.header(\"user-agent\"));\n\n let visitorId = body.visitorId ? String(body.visitorId) : null;\n\n // A BROWSER CAN HOLD AN ID WHOSE ROW NO LONGER EXISTS.\n //\n // The 90-day purge deletes visitor rows; nothing clears localStorage. Before\n // this check, such a browser sent its dead id on every page view forever,\n // recordPresence bailed out on the missing row, and that person was\n // invisible on the monitoring screen — permanently, and silently. Only\n // presence was affected, because /api/session upserts unconditionally, so\n // they reappeared the moment they opened the chat. Which is precisely the\n // case nobody would ever notice was broken.\n //\n // THE SUPPLIED ID IS REUSED, NOT REPLACED, and that is not a stylistic\n // choice: the widget adopts an id from this response only when it has none\n // of its own, so minting a fresh one here would be ignored and the browser\n // would go on sending the old one for good.\n const known = visitorId ? await db.getVisitor(visitorId) : null;\n\n if (!visitorId || !known) {\n visitorId = visitorId ?? db.id(\"v\");\n await db.upsertVisitor({\n id: visitorId,\n name: body.name ?? null,\n email: body.email ?? null,\n phone: body.phone ?? null,\n zip: body.zip ?? null,\n company: body.company ?? null,\n wpUserId: body.wpUserId ?? null,\n pageUrl,\n country,\n os: device.os,\n browser: device.browser,\n });\n }\n\n // Runs for a brand-new visitor too: referrer and landing_url are still null\n // on the row we just inserted, so COALESCE fills them from this first ping.\n await db.recordPresence(\n visitorId,\n pageUrl,\n body.referrer ? String(body.referrer).slice(0, 500) : null,\n {\n country,\n os: device.os,\n browser: device.browser,\n optedOut: quiet,\n // Reported by the widget. chatOpen is the panel state right now;\n // shownOpener/shownNudge are the lines it drew in the browser and never\n // sent here as messages, so without this the console shows an empty\n // thread for a visitor who has been spoken to twice.\n chatOpen: body.chatOpen === true,\n // Lives in the visitor's localStorage and nowhere else, so this ping is\n // the only way the console ever learns that somebody closed the chat on\n // us rather than us failing to reach them.\n chatDismissed: body.dismissed === true,\n // Whether the page they are on is WordPress's 404. Only the widget can\n // know this — it reads the error404 body class from inside the page.\n // Left undefined when an older widget build does not send it, so the\n // column stays NULL rather than recording a confident \"no\".\n notFound: typeof body.notFound === \"boolean\" ? body.notFound : undefined,\n // Which chat this visitor was actually shown, in split mode. Reported by\n // the widget from the arm the site assigned it, and reported from BOTH\n // arms — the tawk half runs our widget invisibly, which is the only\n // reason the two can be compared at all.\n arm: body.arm === \"ours\" || body.arm === \"tawk\" ? body.arm : null,\n shownOpener: body.shownOpener ? String(body.shownOpener).slice(0, 1000) : null,\n shownNudge: body.shownNudge ? String(body.shownNudge).slice(0, 1000) : null,\n },\n );\n\n // THE TRAIL, recorded here because this is where a page change is first\n // visible to us. recordPresence overwrites page_url, so a moment later the\n // previous page is simply gone — if it is not written now it is never\n // written at all.\n //\n // AGENT-ONLY DATA. It goes to visitor_events, never to messages, so there is\n // no code path that could put a visitor's own browsing on their screen.\n // Skipped entirely for anyone signalling Do Not Track, on the same principle\n // as the rest of the profiling in this file.\n if (!quiet && pageUrl) {\n // `known` IS THE STATE BEFORE THIS PING, and it has to be — the upsert\n // above has already run, so re-reading the row here would show the new\n // page and make every visitor look like a returning one. That is exactly\n // what happened on the first attempt: \"arrived\" never fired once, because\n // by the time it was checked the visitor always existed.\n const wasOn = known ? String(known[\"page_url\"] ?? \"\") : \"\";\n\n if (!known) {\n await db.recordEvent(visitorId!, \"arrived\", pageUrl);\n } else if (wasOn && wasOn !== pageUrl) {\n await db.recordEvent(visitorId!, \"page\", pageUrl);\n }\n\n // The events that are worth interrupting a conversation for. Each is\n // recorded only on the TRANSITION — recordEvent dedupes against the last\n // row of the same kind, so a steady state does not repeat.\n if (body.notFound === true) await db.recordEvent(visitorId!, \"notfound\", pageUrl);\n if (body.dismissed === true && !(known && Number(known[\"chat_dismissed\"]))) {\n await db.recordEvent(visitorId!, \"closed_chat\", null);\n }\n }\n\n // Retention runs off the back of the busiest endpoint rather than a cron.\n // It self-throttles to once a day and returns immediately otherwise, so this\n // costs one indexed read on a normal page view.\n db.purgeStaleVisitors().catch(() => {});\n\n const conversationId = await db.findOpenConversation(visitorId);\n const invited = conversationId ? await db.hasAgentMessage(conversationId) : false;\n\n return c.json({ visitorId, conversationId, invited });\n});\n\n/**\n * The page-specific follow-up, recorded once the widget has actually drawn it.\n *\n * SAME BUG AS THE OPENER, one step later. The nudge is timed in the browser,\n * so it was never in the transcript either — a visitor who ignored the opener,\n * read the nudge and then replied to THAT was answered by a model that had\n * seen neither line.\n *\n * THE BODY IS NOT TRUSTED. This endpoint takes no text: it recomputes the\n * nudge for the conversation's own page and stores that. The caller can only\n * decide WHEN a line it was already given gets recorded, never what it says.\n * An open endpoint that appended arbitrary text as the assistant would let\n * anybody put words in the company's mouth in front of an agent.\n */\napp.post(\"/api/shown-nudge\", async (c) => {\n await db.init();\n const { conversationId } = await c.req.json().catch(() => ({}));\n if (!conversationId) return c.json({ error: \"conversationId required\" }, 400);\n\n const conv = await db.getConversation(String(conversationId));\n if (!conv) return c.json({ error: \"unknown conversation\" }, 404);\n\n // Only ever on a bot-run conversation, and only when we are still the last\n // one to have spoken. If the visitor has since replied, the moment for a\n // follow-up has passed and recording it would put it out of order.\n if (String(conv[\"status\"]) !== \"ai\") return c.json({ ok: true, stored: false });\n\n const history = await db.getMessages(String(conversationId));\n if (history.some((m: any) => m[\"sender\"] === \"visitor\")) {\n return c.json({ ok: true, stored: false });\n }\n\n // Same variant the opener used, read back off the visitor row rather than\n // trusted from the caller — otherwise this recomputes a nudge that may repeat\n // the opening line the visitor is looking at. sf_account travels with it for\n // the same reason: a customer's opener carried no pitch, so the follow-up\n // must not introduce one either.\n const text = pageNudge(\n conv[\"page_url\"] ?? null,\n conv[\"opener_variant\"] ?? null,\n !!conv[\"sf_account\"],\n conv[\"referrer\"] ?? null,\n );\n if (!text) return c.json({ ok: true, stored: false });\n\n // Once. A reload must not append it again.\n if (history.some((m: any) => String(m[\"body\"]) === text)) {\n return c.json({ ok: true, stored: false });\n }\n\n await db.addMessage(String(conversationId), \"ai\", text);\n return c.json({ ok: true, stored: true });\n});\n\n/**\n * \"This page is going away\" — a pagehide beacon from the widget.\n *\n * WHY IT EXISTS. Until now the console could only infer departure from silence,\n * and silence is also what a locked phone, a switched tab and a throttled timer\n * look like. A visitor who closed the site and one who is still reading with a\n * missed heartbeat were the same row for a minute and a half. This is the one\n * moment a browser will volunteer that it is going, so it is worth taking.\n *\n * IT IS A HINT, NOT A FACT, and everything downstream treats it that way:\n * pagehide also fires on an ordinary click through to the next page and on iOS\n * when a tab is merely backgrounded. The next presence ping clears it, and the\n * console holds off for a few seconds before showing anything, so navigating\n * around the site never flashes up as leaving.\n *\n * SENT BY sendBeacon, which means text/plain and no cookies, and it is READ\n * accordingly — c.req.json() would reject the content type and throw away the\n * body. It also means the response is ignored by the browser, so this returns\n * 204 and does no work worth waiting for.\n */\napp.post(\"/api/gone\", async (c) => {\n await db.init();\n\n let visitorId: string | null = null;\n try {\n const raw = await c.req.text();\n visitorId = raw ? (JSON.parse(raw)?.visitorId ?? null) : null;\n } catch (_e) {\n // A malformed beacon from a page being torn down is not worth a log line.\n }\n\n if (visitorId) await db.markLeft(String(visitorId));\n return c.body(null, 204);\n});\n\n/**\n * Details a visitor VOLUNTEERED through a form on the website.\n *\n * This is the best identification we get: first-party, consented, and typed by\n * the person themselves — not inferred from anything. It is also precisely what\n * tawk could not use, since tawk refused to render attributes for a visitor it\n * considered unidentified.\n *\n * SEPARATE FROM /api/session ON PURPOSE. That endpoint opens a conversation,\n * which would put an empty thread in the agent queue for every form submission\n * on the site. This only enriches the visitor record.\n *\n * Purpose limit: someone filling in a quote form volunteered contact details in\n * order to BE CONTACTED. Using them to greet that person in chat is inside that\n * purpose. This endpoint does not backfill anything else.\n */\napp.post(\"/api/identify\", async (c) => {\n await db.init();\n const body = await c.req.json().catch(() => ({}));\n\n const visitorId = body.visitorId ? String(body.visitorId) : null;\n if (!visitorId) {\n console.warn(\"identify REJECTED: no visitorId\");\n return c.json({ error: \"visitorId required\" }, 400);\n }\n\n // Only enrich a visitor we already know. Creating one here would let any\n // caller mint records by posting arbitrary ids.\n const existing = await db.getVisitor(visitorId);\n if (!existing) {\n console.warn(`identify REJECTED: unknown visitor ${visitorId}`);\n return c.json({ error: \"unknown visitor\" }, 404);\n }\n\n // LOGGED BECAUSE SILENCE HERE IS AMBIGUOUS. Ten checkout visitors arrived\n // with nothing identified, and \"the WordPress snippet never called\" looks\n // exactly like \"it called and the call failed\". One line makes them\n // different. Fields only — never the values.\n console.log(\n `identify ${visitorId} from ${String(body.pageUrl ?? \"?\").slice(0, 80)}`\n + ` fields=[${[\"name\", \"email\", \"phone\", \"zip\", \"company\"].filter((k) => body[k]).join(\",\")}]`,\n );\n\n const clip = (v: unknown) => {\n const s = String(v ?? \"\").trim();\n return s ? s.slice(0, 200) : null;\n };\n\n // upsertVisitor COALESCEs, so this fills gaps and never overwrites something\n // already established — a WordPress-verified phone survives a typo in a form.\n await db.upsertVisitor({\n id: visitorId,\n name: clip(body.name),\n email: clip(body.email),\n phone: clip(body.phone),\n zip: clip(body.zip),\n company: clip(body.company),\n pageUrl: body.pageUrl ? String(body.pageUrl) : String(existing[\"page_url\"] ?? \"\"),\n });\n\n // THE ORDER ITSELF, not merely who placed it.\n //\n // The checkout snippet has always known both and reported only the person,\n // which left the tawk-vs-ours split measurable in conversations opened and\n // messages typed — engagement, none of which is money. Two chat widgets can\n // only be compared honestly on what they sold.\n //\n // The VALUE IS NOT TRUSTED. This endpoint is public, and one absurd number\n // would quietly poison the revenue figure for a whole arm and make the losing\n // widget look like the winner. An implausible total is stored as null while\n // the order still counts, so a bad amount costs the revenue column and never\n // the order count.\n const orderId = clip(body.orderId);\n if (orderId) {\n const n = Number(body.orderTotal);\n const ok = Number.isFinite(n) && n > 0 && n < 100000;\n await db.setVisitorOrder(visitorId, orderId, ok ? Math.round(n * 100) / 100 : null);\n console.log(`order ${orderId} -> ${visitorId}${ok ? ` ${n}` : \" (value rejected)\"}`);\n\n // THE MOMENT IT HAPPENED, on the conversation timeline.\n //\n // The visitor row already recorded THAT they ordered; this records WHEN,\n // in among what was being said at the time. Somebody buying halfway\n // through a chat is the most important thing that can happen in one, and\n // until now it was invisible in the thread — an agent could be mid-answer\n // about pricing to a person who had already paid.\n //\n // GUARDED ON existing.order_id, to match setVisitorOrder's COALESCE\n // exactly: that keeps the FIRST order and ignores later ones, so logging\n // an event for a second order would put a line in the timeline that\n // contradicts the row above it. recordEvent's own dedupe is not enough\n // here — it only compares against the immediately preceding event, and a\n // repeat order weeks later would have pages in between.\n if (!existing[\"order_id\"]) {\n await db.recordEvent(\n visitorId,\n \"ordered\",\n // The rejected-value case deliberately still records the order, for\n // the same reason it is stored: a bad amount must cost the revenue\n // figure, never the fact that somebody bought.\n // CONCATENATED, NOT INTERPOLATED. A literal \"$\" immediately before a\n // ${...} inside a template literal is one editing slip from vanishing,\n // and it vanished here on the first write — the amount would have\n // rendered as \"134.98\" with no currency symbol. greeting.ts carries the\n // same warning for the same reason.\n ok\n ? \"#\" + orderId + \" · $\" + (Math.round(n * 100) / 100).toFixed(2)\n : \"#\" + orderId,\n );\n }\n }\n\n // A volunteered phone is worth resolving immediately, so an agent opening the\n // conversation already has the account on screen rather than waiting for the\n // customer to repeat a number they have just typed once.\n const phone = clip(body.phone);\n if (phone) await enrich(visitorId, phone);\n\n return c.json({ ok: true });\n});\n\n/**\n * \"They have gone quiet\" — reported by the widget, decided by the server.\n *\n * The 15-minute interval sweep in nudge.ts is a backstop, not the mechanism.\n * Free-tier intervals cannot run more often than that, so a sweep alone would\n * deliver \"still there?\" up to eighteen minutes late, to someone who has long\n * since closed the tab. The widget knows the thing the server cannot: whether\n * this person is STILL ON THE PAGE, right now, having stopped typing.\n *\n * The caller is not trusted with the decision, only with the timing. Every\n * guard — engaged, we spoke last, still on the bot, not already nudged, not\n * already ordered — is re-applied here through the same query the sweep uses,\n * so a forged call can at most trigger a nudge this conversation had already\n * earned.\n */\napp.post(\"/api/nudge\", async (c) => {\n await db.init();\n const { conversationId } = await c.req.json().catch(() => ({}));\n if (!conversationId) return c.json({ error: \"conversationId required\" }, 400);\n\n // Idle floor of 0: the widget has already timed it, and re-imposing a floor\n // here would just fight its clock. The CEILING still applies, because a tab\n // rediscovered after an hour should not get a message about it.\n const eligible = await db.listNudgeCandidates(0, 30 * 60 * 1000, 50);\n const row: any = eligible.find((r: any) => String(r[\"id\"]) === String(conversationId));\n if (!row) return c.json({ ok: true, nudged: false });\n\n // Which pick-up this is, taken from the row the query already returned.\n // Round two is the softer one — see nudgeReply.\n const round = Number(row[\"nudge_count\"] ?? 0) + 1;\n\n await db.markNudged(String(conversationId));\n\n const conv = await db.getConversation(String(conversationId));\n if (!conv || String(conv[\"status\"]) !== \"ai\") return c.json({ ok: true, nudged: false });\n\n const history = await db.getMessages(String(conversationId));\n const visitor = await db.getVisitor(String(conv[\"visitor_id\"]));\n const text = await nudgeReply(history, visitor, round);\n if (!text) return c.json({ ok: true, nudged: false });\n\n await db.addMessage(String(conversationId), \"ai\", text);\n console.log(`nudged ${conversationId}: ${text}`);\n return c.json({ ok: true, nudged: true });\n});\n\n/**\n * Visitor has live keystrokes in the textarea, right now — nothing else.\n * Fired on a throttle from the widget, not per keystroke, and read by the\n * consoles as stale (so: not-typing) after a few seconds with no repeat\n * call. No message body is ever accepted here; there is nowhere in this\n * handler a draft's text could even be passed.\n */\napp.post(\"/api/typing\", async (c) => {\n await db.init();\n const { conversationId } = await c.req.json().catch(() => ({}));\n if (!conversationId) return c.json({ error: \"conversationId required\" }, 400);\n const conv = await db.getConversation(String(conversationId));\n if (!conv) return c.json({ ok: true, recorded: false }, 200);\n await db.setTyping(String(conversationId));\n return c.json({ ok: true, recorded: true });\n});\n\n/** Visitor-initiated handoff, from a button rather than a phrase. */\napp.post(\"/api/handoff\", async (c) => {\n await db.init();\n const { conversationId } = await c.req.json();\n const conv = await db.getConversation(conversationId);\n if (!conv) return c.json({ error: \"unknown conversation\" }, 404);\n\n if (String(conv[\"status\"]) === \"ai\") {\n await db.setStatus(conversationId, \"needs_human\");\n await db.addMessage(conversationId, \"system\", \"Connecting you with someone from the team.\");\n await notifyHandoff(conversationId, await db.getConversation(conversationId));\n }\n return c.json({ ok: true });\n});\n\n/* ----------------------------------------------------------------- streams */\n\nfunction sseStream(load: (since: number) => Promise, since0: number) {\n let since = since0;\n const started = Date.now();\n const enc = new TextEncoder();\n\n return new ReadableStream({\n async pull(controller) {\n if (Date.now() - started > STREAM_MAX_MS) {\n controller.close();\n return;\n }\n\n await new Promise((r) => setTimeout(r, POLL_MS));\n\n try {\n const rows = await load(since);\n for (const row of rows) {\n const created = Number(row[\"created_at\"] ?? row[4] ?? 0);\n if (created > since) since = created;\n controller.enqueue(enc.encode(`data: ${JSON.stringify(row)}\\n\\n`));\n }\n // Comment frame doubles as a keep-alive; proxies drop idle connections.\n controller.enqueue(enc.encode(`: ping\\n\\n`));\n } catch (_e) {\n // A transient query failure must not kill the stream — the widget\n // would reconnect anyway, but silently riding it out is smoother.\n controller.enqueue(enc.encode(`: err\\n\\n`));\n }\n },\n });\n}\n\nconst SSE_HEADERS = {\n \"Content-Type\": \"text/event-stream\",\n \"Cache-Control\": \"no-cache\",\n \"Connection\": \"keep-alive\",\n};\n\napp.get(\"/api/stream\", async (c) => {\n await db.init();\n const cid = c.req.query(\"c\");\n const since = Number(c.req.query(\"since\") ?? 0);\n if (!cid) return c.json({ error: \"c required\" }, 400);\n\n return new Response(\n sseStream((s) => db.getMessages(cid, s), since),\n { headers: SSE_HEADERS },\n );\n});\n\n/* ------------------------------------------------------------------ agent */\n\napp.get(\"/api/agent/conversations\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n // since/includeClosed/limit are all optional and default to the original\n // behavior — the Conversations tab calls this with none of them and gets\n // exactly what it always got. The Engaged tab is the one that passes them,\n // for a real 24-hour window that includes threads an agent has since closed.\n const since = Number(c.req.query(\"since\") ?? 0);\n const includeClosed = c.req.query(\"includeClosed\") === \"1\";\n const limit = Number(c.req.query(\"limit\") ?? 50);\n return c.json({ conversations: await db.listConversations({ since, includeClosed, limit }) });\n});\n\napp.get(\"/api/agent/messages\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const cid = c.req.query(\"c\");\n if (!cid) return c.json({ error: \"c required\" }, 400);\n const conversation = await db.getConversation(cid);\n\n // THE ONLY ENDPOINT THAT RETURNS EVENTS, and it sits behind whoIsAgent above.\n // Nothing on the visitor side reads this route, so a customer has no way to\n // receive their own browsing trail — see the visitor_events table comment.\n return c.json({\n conversation,\n messages: await db.getMessages(cid),\n events: conversation\n ? await db.getEvents(String(conversation[\"visitor_id\"]))\n : [],\n });\n});\n\n/** Who is on the site right now. */\napp.get(\"/api/agent/visitors\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n\n // FOUR times the widget's 45-second heartbeat, not two.\n //\n // Two was too tight and it was measurably hiding people: at 90s the console\n // listed 3 visitors when 8 had pinged within three minutes and 11 within\n // five. The gaps tell the story — they cluster at 1s, 9s, 49s and then jump\n // straight to 133s+, with almost nothing in between, because a single missed\n // ping puts someone the far side of the line. Mobile browsers throttle timers\n // in the background constantly, so missing one is normal rather than a sign\n // the visitor has gone.\n //\n // The cost of being generous here is asymmetric. Showing someone who left a\n // minute ago wastes a glance; hiding someone who is still reading loses the\n // conversation the console exists to start. The list marks how long each has\n // been idle so nobody is mistaken for live.\n const window = 3 * 60 * 1000;\n return c.json({ visitors: await db.listActiveVisitors(Date.now() - window) });\n});\n\n/**\n * The tawk half, reporting what it did.\n *\n * WITHOUT THIS THE SPLIT IS HALF-BLIND. This database would know how many\n * people were offered tawk and nothing about whether they used it, so the tawk\n * arm's engagement would read zero forever and the two arms could never be\n * compared on the same measure.\n *\n * Only two events are accepted, and neither carries any content: whether a\n * chat window opened, and whether the visitor typed at least once. What was\n * said stays in tawk — this is a counter, not a transcript.\n *\n * Unauthenticated by necessity (it is a browser on the storefront) and\n * harmless if forged: the worst a fabricated call does is mark one visitor as\n * having engaged, which nudges a rate nobody bills on.\n */\napp.post(\"/api/tawk-event\", async (c) => {\n await db.init();\n const body = await c.req.json().catch(() => ({}));\n\n const visitorId = body.visitorId ? String(body.visitorId) : null;\n const event = body.event === \"messaged\" ? \"messaged\" : body.event === \"opened\" ? \"opened\" : null;\n if (!visitorId || !event) return c.json({ error: \"visitorId and event required\" }, 400);\n\n // Only ever annotate a visitor we already know. Creating one here would let\n // any caller mint rows by posting arbitrary ids.\n const known = await db.getVisitor(visitorId);\n if (!known) return c.json({ ok: true, recorded: false }, 200);\n\n await db.markTawkEvent(visitorId, event);\n return c.json({ ok: true, recorded: true });\n});\n\n/** Which chat won: visitors offered each, and how many of ours talked. */\napp.get(\"/api/agent/arms\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const days = Number(c.req.query(\"days\") ?? 7);\n const since = Date.now() - (Number.isFinite(days) ? days : 7) * 24 * 60 * 60 * 1000;\n return c.json({ since, arms: await db.armReport(since) });\n});\n\n/**\n * Opener split test scoreboard: shown, replied, reply rate, per variant.\n *\n * ?days=N limits it to the last N days, default 30. The floor is not\n * decoration — every visitor greeted before the test started carries a null\n * variant, and a large \"(pre-test)\" row at the top of the table is exactly the\n * sort of number that gets quoted as a result.\n */\napp.get(\"/api/agent/openers\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const days = Number(c.req.query(\"days\") ?? 30);\n const since = Date.now() - (Number.isFinite(days) ? days : 30) * 24 * 60 * 60 * 1000;\n return c.json({ since, variants: await db.openerReport(since) });\n});\n\n/**\n * Anthropic spend so far this calendar month (UTC), for the mobile console's\n * header bar.\n *\n * Uses ANTHROPIC_ADMIN_KEY, an organization-scoped Admin API key created\n * 9/4/2026 specifically for this — the regular ANTHROPIC_API_KEY this val\n * sends chat completions with is workspace-scoped and the Admin API rejects\n * it outright (401 \"requires an Admin API key or an organization-scoped API\n * key\", confirmed live). There is no API for the prepaid credit balance\n * itself (the Console's \"$X credits\" figure) — only usage/cost, which is\n * what this reports.\n *\n * `amount` in the Cost API is a decimal STRING in cents (its own docs example\n * \"123.45\" = $1.23), so every result across every bucket is summed then\n * divided by 100 rather than trusted as dollars.\n */\napp.get(\"/api/agent/spend\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n const key = Deno.env.get(\"ANTHROPIC_ADMIN_KEY\");\n if (!key) return c.json({ error: \"not configured\" }, 501);\n const now = new Date();\n const monthStart = new Date(Date.UTC(now.getUTCFullYear(), now.getUTCMonth(), 1));\n const url = \"https://api.anthropic.com/v1/organizations/cost_report\"\n + `?starting_at=${monthStart.toISOString()}&ending_at=${now.toISOString()}&limit=31`;\n let res: Response;\n try {\n res = await fetch(url, {\n headers: { \"anthropic-version\": \"2023-06-01\", \"x-api-key\": key },\n signal: AbortSignal.timeout(8000),\n });\n } catch (e) {\n console.error(\"cost_report fetch failed:\", e);\n return c.json({ error: \"unavailable\" }, 502);\n }\n if (!res.ok) {\n console.error(\"cost_report HTTP\", res.status, (await res.text()).slice(0, 300));\n return c.json({ error: \"unavailable\" }, 502);\n }\n const body = await res.json().catch(() => null);\n let cents = 0;\n for (const bucket of body?.data ?? []) {\n for (const r of bucket?.results ?? []) {\n cents += Number(r?.amount) || 0;\n }\n }\n return c.json({ spendUsd: Math.round(cents) / 100, since: monthStart.toISOString() });\n});\n\n/**\n * Start a conversation with a visitor who has not asked for one.\n *\n * This is the reason presence tracking earns its keep. Watching a list of\n * anonymous sessions is not useful; opening with \"want a hand?\" to someone who\n * has been on the pricing page for four minutes is.\n *\n * Goes straight to 'human' — the AI must not pick up a conversation a person\n * deliberately started.\n */\napp.post(\"/api/agent/invite\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n\n const { visitorId, body, agent } = await c.req.json();\n if (!visitorId || !body || !String(body).trim()) {\n return c.json({ error: \"visitorId and body required\" }, 400);\n }\n\n const visitor = await db.getVisitor(String(visitorId));\n if (!visitor) return c.json({ error: \"unknown visitor\" }, 404);\n\n // Same rule as /reply: a token names its own holder and nobody else.\n const signer = who.tokenId ? who.person : (agent ?? who.person);\n\n const conversationId = await db.openConversation(String(visitorId));\n await db.setStatus(conversationId, \"human\", signer);\n await db.addMessage(conversationId, \"agent\", String(body).slice(0, 4000), signer);\n if (who.tokenId) await db.touchAgentToken(who.tokenId);\n\n return c.json({ ok: true, conversationId });\n});\n\napp.post(\"/api/agent/claim\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { conversationId, agent } = await c.req.json();\n const signer = who.tokenId ? who.person : (agent ?? who.person);\n\n await db.setStatus(conversationId, \"human\", signer);\n await db.addMessage(\n conversationId,\n \"system\",\n `${signer} has joined the conversation.`,\n );\n if (who.tokenId) await db.touchAgentToken(who.tokenId);\n return c.json({ ok: true });\n});\n\napp.post(\"/api/agent/reply\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { conversationId, body, agent } = await c.req.json();\n if (!conversationId || !body) return c.json({ error: \"conversationId and body required\" }, 400);\n\n // WHOSE NAME GOES ON THIS, decided here rather than by the caller.\n //\n // A token holder gets their own name and cannot claim another — the whole\n // reason for per-person credentials is that \"who sent that\" has an answer,\n // and an answer the sender can edit is not one. The master key keeps the\n // supplied name, because the surfaces that hold it (the Salesforce console,\n // the desktop dashboard) have already authenticated a real person through\n // Salesforce and are reporting who that is.\n const signer = who.tokenId ? who.person : (agent ?? who.person);\n\n // Replying implies taking over. Requiring a separate Claim click is the kind\n // of step that gets skipped under pressure, leaving the AI talking over a\n // human mid-conversation.\n const conv = await db.getConversation(conversationId);\n if (conv && String(conv[\"status\"]) !== \"human\") {\n await db.setStatus(conversationId, \"human\", signer);\n }\n\n await db.addMessage(conversationId, \"agent\", String(body).slice(0, 4000), signer);\n if (who.tokenId) await db.touchAgentToken(who.tokenId);\n return c.json({ ok: true });\n});\n\napp.post(\"/api/agent/release\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { conversationId } = await c.req.json();\n await db.setStatus(conversationId, \"ai\");\n return c.json({ ok: true });\n});\n\napp.post(\"/api/agent/close\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { conversationId } = await c.req.json();\n await db.setStatus(conversationId, \"closed\");\n return c.json({ ok: true });\n});\n\napp.get(\"/api/agent/stream\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n // The dashboard re-fetches the list on any tick; sending the list itself\n // down the stream would race with the agent's own actions.\n return new Response(\n sseStream(async () => [{ created_at: Date.now(), tick: true }], 0),\n { headers: SSE_HEADERS },\n );\n});\n\n/* ----------------------------------------------------------------- shared */\n\n/**\n * Resolve a phone (and now email) against Salesforce and cache it on the\n * visitor — an ACCOUNT match first, and only when that comes up empty, a\n * LEAD match.\n *\n * WHY LEAD IS SECOND AND CONDITIONAL. A Lead is what a stranger has —\n * somebody who filled out the website popup and nothing more. An Account is\n * what a customer has. If we already know this visitor has an account, a\n * Lead record (real or stale, from before they signed up) has nothing to add\n * and every reason to be left alone: mentioning a \"lead\" to someone we can\n * already see is a paying customer reads as the bot not knowing who they are,\n * the opposite of the point.\n *\n * EMAIL IS NEW HERE. The account lookup still only accepts phone (Salesforce\n * field-level security blocks email on both Account and Lead paths for this\n * integration user, verified separately for each — see salesforce.ts), but a\n * Lead lookup by email is exactly what closes the popup gap: that lead had no\n * phone captured at all, only an email, so phone-only enrichment would never\n * have found it.\n */\nasync function enrich(visitorId: string, phone: string | null, email: string | null = null) {\n // Store what we were given first, before any lookup and regardless of its\n // outcome. The agent console runs its OWN native Salesforce query keyed off\n // the phone, and that query is the one that can show several candidate\n // accounts for a human to choose between. Without this, a number typed in\n // chat reached the bot but never the panel, so the disambiguation the\n // console exists for never fired.\n if (phone) await db.setVisitorPhone(visitorId, phone);\n // Was scanned only for the Lead lookup below and then thrown away —\n // never reached VERIFIED ACCOUNT or anything else keyed on \"do we have\n // an email.\" Stored the same way phone already is, for the same reason.\n if (email) await db.setVisitorEmail(visitorId, email);\n\n const v = await db.getVisitor(visitorId);\n\n // Re-checking every message would add a Val Town cold start plus two SOQL\n // queries to each turn. An hour is far shorter than a delivery schedule\n // changes.\n const checked = Number(v?.[\"sf_checked_at\"] ?? 0);\n // Mutable: the account lookup below can turn this true mid-function. It\n // has to, or a visitor whose very first message matches an Account still\n // pays for a Lead lookup right behind it — a second slow SF round trip\n // for a question already answered by the first.\n let alreadyKnownCustomer = !!v?.[\"sf_account\"];\n\n if (phone && !(checked && Date.now() - checked < 60 * 60 * 1000)) {\n const res = await lookupByPhone(phone);\n // found:false arrives as needs_phone, ambiguous or errored. None is a\n // statement about THIS customer, so none is stored. Ambiguous matters\n // most: that number is on more than one account, and guessing would put\n // another business's name in front of this one.\n if (res?.found) {\n await db.setSalesforce(visitorId, res.account_name ?? null, res.next_delivery_date ?? null);\n alreadyKnownCustomer = true;\n }\n }\n\n if (!alreadyKnownCustomer && (phone || email)) {\n const leadChecked = Number(v?.[\"sf_lead_checked_at\"] ?? 0);\n if (!leadChecked || Date.now() - leadChecked >= 60 * 60 * 1000) {\n const lead = await lookupLead(phone, email);\n // Written whether found or not — see setLead's own comment on why this\n // one is not COALESCEd the way the account fields are.\n await db.setLead(visitorId, lead?.found ? lead.company ?? null : null, lead?.found ? lead.status ?? null : null);\n }\n }\n}\n\n/**\n * Deliberately narrow. A customer saying \"does a human deliver these?\" should\n * not trigger a handoff, so this matches requests, not the word alone.\n */\nfunction wantsHuman(text: string): boolean {\n // An actual request. These stand on their own and always escalate.\n if (/\\b(speak|talk|chat)\\s+(to|with)\\s+(a\\s+)?(human|person|someone|agent|rep)\\b/i.test(text)) {\n return true;\n }\n if (/\\bhuman\\s+(please|help)\\b/i.test(text)) return true;\n\n // \"real person\" / \"live agent\" WITHOUT a request verb in front of it.\n //\n // THIS FIRED ON \"are you a real person?\" AND HANDED THE CHAT OFF — caught\n // 9/1/2026, the first time anyone asked the newly-named assistant who it\n // was. That question is not a request for a human, it is a question about\n // the one already answering, and escalating it drops a live conversation\n // into a queue nobody is watching and leaves the customer waiting for a\n // reply that was one sentence away.\n //\n // It matters more now than it did: giving the assistant a name is precisely\n // what makes people ask.\n if (!/\\b(real|live)\\s+(person|human|agent)\\b/i.test(text)) return false;\n return !asksWhoYouAre(text);\n}\n\n/* ------------------------------------------------- callback details */\n\n/**\n * What the system says the moment a handoff is requested.\n *\n * Three versions, because the wrong one is worse than none. A signed-in\n * customer whose number we already hold should not be asked for it — that\n * reads as a company that does not know who they are.\n */\nfunction handoffLine(v: any): string {\n const haveName = !!v?.[\"name\"];\n const havePhone = !!v?.[\"phone\"];\n\n if (haveName && havePhone) {\n return \"I'll get someone from the team onto this — they have your details \"\n + \"and will come back to you. We're open \" + OFFICE_HOURS + \".\";\n }\n if (havePhone) {\n return \"I'll pass this to the team. What name should I put on it?\";\n }\n if (haveName) {\n return \"I'll pass this to the team, \" + String(v[\"name\"]).split(/\\s+/)[0]\n + \". What's the best number to reach you on?\";\n }\n return \"I'll get this in front of the team. So they can come back to you — \"\n + \"what's your name and the best number to reach you on?\";\n}\n\n/**\n * Take a name and a number from someone who has asked for a person.\n *\n * IN CODE, NOT THROUGH THE MODEL, and that is the point. They asked for a\n * human; letting the assistant keep talking would be the system overriding the\n * one instruction it was just given. This does exactly one thing — records how\n * to call them back — and then goes quiet.\n *\n * The phone has already been scanned, stored and resolved against Salesforce by\n * the caller, so this only has to deal with the name and with what to say.\n */\nasync function takeContactDetails(\n cid: string,\n visitorId: string,\n text: string,\n): Promise {\n // STOP READING NAMES OUT OF MESSAGES ONCE WE HAVE STOPPED ASKING.\n //\n // After the give-up line the conversation is no longer about contact details,\n // so anything typed next is about something else entirely — and guessing a\n // name out of it is how \"Still No\" ended up in a customer name field. The\n // phone scan upstream still runs, because a number is unambiguous.\n const conv = await db.getConversation(cid);\n const givenUp = Number(conv?.[\"contact_asks\"] ?? 0) >= 2;\n\n if (!givenUp) {\n const name = extractName(text);\n if (name) await db.setVisitorName(visitorId, name);\n }\n\n const v = await db.getVisitor(visitorId);\n const haveName = !!v?.[\"name\"];\n const havePhone = !!v?.[\"phone\"];\n\n if (haveName && havePhone) {\n // Notify AGAIN. The first notification went out with nothing useful in it;\n // this is the one that tells the team who to ring.\n await notifyHandoff(cid, await db.getConversation(cid));\n await db.addMessage(\n cid,\n \"system\",\n \"Thanks \" + String(v[\"name\"]).split(/\\s+/)[0] + \" — the team has your \"\n + \"number and will call you back. We're open \" + OFFICE_HOURS\n + \", or you can reach us on \" + OFFICE_PHONE + \".\",\n );\n return true;\n }\n\n // ONE FOLLOW-UP, THEN STOP — and it is not the same sentence twice.\n //\n // The first version asked three times and repeated the opening line word for\n // word each time, so \"no\" was answered with the identical question it had\n // just been given. Somebody who declines twice has decided; asking again is\n // a bot arguing with a customer, and they can still be helped without a\n // number.\n const asks = await db.bumpContactAsks(cid);\n if (asks >= 2) {\n await db.addMessage(\n cid,\n \"system\",\n \"No problem — this is flagged for the team either way. If it's easier, \"\n + OFFICE_PHONE + \" or \" + OFFICE_EMAIL + \" reaches us directly.\",\n );\n return false;\n }\n\n await db.addMessage(\n cid,\n \"system\",\n havePhone\n ? \"Got it. And what name should I put on it?\"\n : (haveName\n ? \"Thanks. What's the best number to reach you on?\"\n // Deliberately worded differently from handoffLine's version of the\n // same request. Hearing the identical sentence back is what makes a\n // system feel like it is not listening.\n : \"No problem either way — a number is just how they'd reach you. \"\n + \"Whereabouts should they call, and who should they ask for?\"),\n );\n return false;\n}\n\n/**\n * A name out of a sentence, or nothing.\n *\n * CONSERVATIVE ON PURPOSE. A wrong name on a callback is worse than a blank\n * one: the team rings up and opens with somebody else's name. So this takes\n * either an explicit introduction (\"my name is...\", \"this is...\") or a reply\n * that is nothing BUT a name, and rejects everything else.\n *\n * Phone numbers and emails are stripped first, because \"John 973-555-0134\" is\n * the commonest single answer to the question this follows.\n */\nfunction extractName(text: string): string | null {\n let s = String(text ?? \"\").replace(/\\S+@\\S+/g, \" \").replace(/[\\d()+\\-.]{7,}/g, \" \");\n\n const intro = s.match(\n /\\b(?:my name is|name is|name's|i am|i'm|this is|it's|its|call me)\\s+([a-z][a-z'.-]*(?:\\s+[a-z][a-z'.-]*){0,2})/i,\n );\n\n let cand = intro ? intro[1] : null;\n\n if (!cand) {\n const bare = s.trim().replace(/[.,!?]+$/, \"\");\n if (bare && bare.length <= 40 && /^[a-z][a-z'.-]*(\\s+[a-z][a-z'.-]*){0,2}$/i.test(bare)) {\n cand = bare;\n }\n }\n\n if (!cand) return null;\n\n // CUT AT THE FIRST WORD THAT CANNOT BE PART OF A NAME.\n //\n // The capture takes up to three words, and \"my name is Dana Whitfield and my\n // number is...\" handed back \"Dana Whitfield And\" — which is what the team\n // would then have read off the screen when they rang her. Names run until\n // the sentence turns into something else, and these are the words it turns\n // into.\n const STOP =\n /^(and|my|the|a|an|is|are|was|number|phone|cell|mobile|email|address|at|on|in|it|its|call|me|you|your|please|thanks|thank|but|or|with|for|to|from|here|there|im|i)$/i;\n\n const words: string[] = [];\n for (const w of cand.trim().split(/\\s+/)) {\n if (STOP.test(w.replace(/[^a-z'.-]/gi, \"\"))) break;\n words.push(w);\n if (words.length === 3) break;\n }\n if (!words.length) return null;\n cand = words.join(\" \");\n\n // Words that pass the shape test and are never part of an answer to \"what's\n // your name\". Tested PER WORD, not against the whole phrase: the first\n // version only checked single words, so \"still no\" sailed through and was\n // stored as the customer name \"Still No\". A wrong name is worse than none —\n // it is what somebody reads off the screen before dialling.\n const NOT_A_NAME =\n /^(yes|no|nope|yep|not|never|still|ok|okay|sure|thanks|thank|hi|hello|hey|please|nothing|none|water|delivery|bottles|help|maybe|later|now|dont|wont|cant|giving|out|stop|leave|alone)$/i;\n\n if (cand.split(/\\s+/).some((w) => NOT_A_NAME.test(w.replace(/[^a-z'.-]/gi, \"\")))) {\n return null;\n }\n\n return cand.trim().split(/\\s+/)\n .map((w) => w.charAt(0).toUpperCase() + w.slice(1))\n .join(\" \")\n .slice(0, 60);\n}\n\n/**\n * \"Are you a real person?\", \"is this a bot?\", \"who am I talking to?\"\n *\n * Answered rather than escalated. Jack is told to say plainly what he is, so\n * the honest answer is already available and is a better reply than a transfer.\n * Anyone who wants a human after that only has to ask for one, and the request\n * patterns above catch it.\n */\nfunction asksWhoYouAre(text: string): boolean {\n return /\\b(are|r)\\s+(you|u)\\b[^.?!]{0,30}\\b(real|human|person|bot|robot|ai|machine|computer)\\b/i.test(text)\n || /\\bis\\s+th(is|at)\\b[^.?!]{0,30}\\b(real|human|person|bot|robot|ai)\\b/i.test(text)\n || /\\bwho\\s+am\\s+i\\s+(talking|speaking|chatting)\\s+(to|with)\\b/i.test(text)\n || /\\bam\\s+i\\s+(talking|speaking|chatting)\\s+(to|with)\\s+(a\\s+)?(real|human|person|bot)\\b/i.test(text);\n}\n\n/* ------------------------------------------------------------ delivery */\n\napp.get(\"/widget.js\", () =>\n new Response(WIDGET_JS, {\n headers: {\n \"Content-Type\": \"application/javascript; charset=utf-8\",\n // Short, so a fix reaches visitors within minutes without hammering the\n // val on every page view of a WooCommerce site.\n \"Cache-Control\": \"public, max-age=300\",\n },\n })\n);\n\n// The standalone console. Kept alongside the Visualforce page as the fallback\n// that works when Salesforce is down or a licence is missing.\napp.get(\"/dashboard\", () =>\n new Response(DASHBOARD_HTML, {\n headers: { \"Content-Type\": \"text/html; charset=utf-8\" },\n })\n);\n\n/* ----------------------------------------------------- mobile console */\n\n/**\n * The phone console. Public HTML, because the page itself is just a shell —\n * every byte of customer data behind it comes from an endpoint that checks a\n * credential first, and an unauthenticated visitor gets a login form.\n *\n * no-store, because this is the one page where a cached copy on a shared\n * device would show the previous person's conversation list.\n */\napp.get(\"/m\", () =>\n new Response(MOBILE_HTML, {\n headers: {\n \"Content-Type\": \"text/html; charset=utf-8\",\n \"Cache-Control\": \"no-store\",\n \"X-Robots-Tag\": \"noindex, nofollow\",\n },\n })\n);\n\n/**\n * Exchange a token for a session cookie.\n *\n * WHY A COOKIE AND NOT THE TOKEN ON EVERY REQUEST. The token would have to\n * live in localStorage to survive a reload, and anything in localStorage is\n * readable by any script that ever runs on the page. An HttpOnly cookie is not\n * reachable from JavaScript at all, so the credential cannot be exfiltrated by\n * a script the way the desktop dashboard's shared key could be.\n *\n * NO RATE LIMIT, deliberately. These tokens are 128 bits of crypto-random;\n * guessing one is not a thing that happens, and a throttle keyed on a proxied\n * IP is how the /chat control page locked out its own owner on 9/2/2026. The\n * control here is the log line below, which makes a stream of failures visible.\n */\napp.post(\"/api/m/login\", async (c) => {\n await db.init();\n const body = await c.req.json().catch(() => ({}));\n const token = typeof body.token === \"string\" ? body.token.trim() : \"\";\n const person = typeof body.person === \"string\" ? body.person.trim() : \"\";\n const passcode = typeof body.passcode === \"string\" ? body.passcode : \"\";\n\n let tok: any = null;\n\n if (token) {\n tok = await db.resolveAgentToken(token);\n if (!tok) {\n console.warn(\"mobile login REJECTED (token)\");\n return c.json({ error: \"That token was not accepted.\" }, 401);\n }\n } else if (person && passcode) {\n const row = await db.agentByPerson(person);\n\n // A NAME THAT DOES NOT EXIST STILL COSTS A HASH.\n //\n // Returning immediately would make an unknown name answer in a\n // millisecond and a known one in three hundred, which turns this endpoint\n // into a way to enumerate who works here. The dummy derivation makes both\n // paths cost the same.\n if (!row) {\n await db.passcodeHash(passcode, \"00000000000000000000000000000000\");\n console.warn(\"mobile login REJECTED (unknown person)\");\n return c.json({ error: \"Name or passcode not recognised.\" }, 401);\n }\n\n // EXPONENTIAL BACKOFF ON THIS PERSON'S ROW, not on an IP address.\n //\n // A passcode is short enough to be worth guessing, so something has to\n // slow that down. Keying it to the account rather than the caller is what\n // stops a repeat of the /chat lockout, where a shared proxy address meant\n // one machine's failed attempts locked out everybody. The cost here falls\n // only on the account being attacked, and it clears on the next success.\n const fails = Number(row[\"fails\"] ?? 0);\n const lastFail = Number(row[\"last_fail_at\"] ?? 0);\n const waitMs = fails < 3 ? 0 : Math.min(2 ** (fails - 2) * 1000, 5 * 60 * 1000);\n if (waitMs && Date.now() - lastFail < waitMs) {\n const left = Math.ceil((waitMs - (Date.now() - lastFail)) / 1000);\n return c.json({ error: `Too many attempts. Try again in ${left}s.` }, 429);\n }\n\n const given = await db.passcodeHash(passcode, String(row[\"passcode_salt\"]));\n if (!safeEq(given, String(row[\"passcode_hash\"]))) {\n await db.notePasscodeFail(String(row[\"id\"]));\n console.warn(`mobile login REJECTED (passcode) for ${row[\"person\"]}`);\n return c.json({ error: \"Name or passcode not recognised.\" }, 401);\n }\n\n await db.clearPasscodeFails(String(row[\"id\"]));\n tok = { id: row[\"id\"], person: row[\"person\"] };\n } else {\n return c.json({ error: \"Name and passcode required.\" }, 400);\n }\n\n const tid = String(tok[\"id\"]);\n const expires = Date.now() + MOBILE_DAYS * 24 * 60 * 60 * 1000;\n const value = tid + \".\" + expires + \".\" + await signSession(tid, expires);\n\n await db.touchAgentToken(tid);\n console.log(`mobile login: ${tok[\"person\"]}`);\n\n // SameSite=Lax is doing real work: it stops a cross-site form POST from\n // carrying this cookie, which is what would otherwise let another site\n // send a message to a customer as Tribeca on a signed-in person's behalf.\n c.header(\n \"Set-Cookie\",\n `${MOBILE_COOKIE}=${value}; Path=/; Max-Age=${MOBILE_DAYS * 24 * 60 * 60}` +\n `; HttpOnly; Secure; SameSite=Lax`,\n );\n return c.json({ person: tok[\"person\"] });\n});\n\n/* ------------------------------------------------------- web push */\n\n/**\n * The service worker, served from the ROOT.\n *\n * Scope is the sticking point: a worker served from /m could only ever control\n * pages under /m. Serving it from / — and saying so with Service-Worker-Allowed\n * — lets the same registration cover the whole origin.\n */\napp.get(\"/sw.js\", () =>\n new Response(SERVICE_WORKER, {\n headers: {\n \"Content-Type\": \"application/javascript; charset=utf-8\",\n \"Service-Worker-Allowed\": \"/\",\n // Short, not immutable. A stale service worker is unusually painful to\n // dislodge — it is the thing that decides whether updates are noticed.\n \"Cache-Control\": \"max-age=0, must-revalidate\",\n },\n })\n);\n\n/**\n * The web app manifest.\n *\n * iOS only grants notification permission to a site added to the Home Screen,\n * and only treats it as an app when there is a manifest saying so. Without\n * this the install is a bookmark, and a bookmark cannot receive push.\n */\napp.get(\"/manifest.json\", (c) =>\n c.json({\n name: \"Tribeca Chat\",\n short_name: \"Tribeca\",\n start_url: \"/m\",\n scope: \"/\",\n display: \"standalone\",\n background_color: \"#f4f6f9\",\n theme_color: \"#0b5cad\",\n icons: [{ src: \"/icon.png\", sizes: \"512x512\", type: \"image/png\", purpose: \"any maskable\" }],\n })\n);\n\n/**\n * The app icon — the REAL Tribeca Beverage mark, not a placeholder.\n *\n * This used to be a flat blue square with a hand-drawn water drop, served as\n * SVG. Replaced 9/3/2026 with the actual logo tribecabeverage.com serves as\n * its own favicon and apple-touch-icon — same file, pulled from the site\n * itself rather than redrawn — stored as a real PNG in this val's blob\n * storage rather than embedded as a giant base64 string in source.\n *\n * PNG, DELIBERATELY, NOT SVG. iOS has historically been unreliable about SVG\n * specifically for apple-touch-icon (a plain favicon `` is\n * fine with SVG; the home-screen icon is the pickier one), and an icon that\n * fails to decode does not fall back to anything — it shows blank, or the\n * broken-image glyph. manifest.json already declared \"image/png\" for this\n * file while the route served SVG underneath it; that mismatch is gone too.\n */\napp.get(\"/icon.png\", async () => {\n // blob.get RETURNS A Response, NOT THE BYTES — passing it straight to a new\n // Response's body is a string coercion, not a copy, and it served\n // \"[object Response]\" as a 17-byte \"image\" until this was caught live. The\n // body stream is what actually needs forwarding.\n const res = await blob.get(\"tribeca-logo-192.png\");\n if (!res) {\n // Never surface a broken image to a customer over a missing blob. A\n // solid brand-blue square is a worse icon than the real logo, but a\n // strictly better one than a home screen showing nothing at all.\n return new Response(\n ``,\n { headers: { \"Content-Type\": \"image/svg+xml\", \"Cache-Control\": \"max-age=300\" } },\n );\n }\n return new Response(res.body, {\n headers: { \"Content-Type\": \"image/png\", \"Cache-Control\": \"max-age=86400\" },\n });\n});\n\n/**\n * Check the notification plumbing, and optionally buzz every phone.\n *\n * Master key only. ?send=1 fires a real push — the only way to confirm a\n * banner actually reaches a lock screen, which no amount of checking the\n * signature can tell you.\n */\napp.get(\"/api/agent/push-test\", async (c) => {\n if (!agentAuthed(c)) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const report = await selfTest();\n const sent = c.req.query(\"send\") === \"1\" ? await pushAll() : null;\n return c.json({ ...report, sent });\n});\n\n/** The public half of the VAPID pair, which the browser needs to subscribe. */\napp.get(\"/api/m/push-key\", (c) => c.json({ key: VAPID_PUBLIC_KEY }));\n\n/**\n * Register this phone for notifications.\n *\n * Tied to the signed-in person's token, so revoking their access silently\n * stops their phone receiving customer names — see livePushSubs.\n */\napp.post(\"/api/m/subscribe\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who || !who.tokenId) {\n // Master-key callers have no token row to hang a device off, and the\n // Salesforce console has no use for phone notifications anyway.\n return c.json({ error: \"sign in on the phone console first\" }, 401);\n }\n await db.init();\n\n const { endpoint } = await c.req.json().catch(() => ({}));\n if (!endpoint || typeof endpoint !== \"string\" || !/^https:\\/\\//.test(endpoint)) {\n return c.json({ error: \"endpoint required\" }, 400);\n }\n\n await db.addPushSub(who.tokenId, endpoint);\n console.log(`push subscribed: ${who.person}`);\n return c.json({ ok: true });\n});\n\napp.post(\"/api/m/unsubscribe\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { endpoint } = await c.req.json().catch(() => ({}));\n if (endpoint) await db.removePushSub(String(endpoint));\n return c.json({ ok: true });\n});\n\n/**\n * What the service worker shows.\n *\n * The push itself carries nothing — see push.ts — so this is where the banner's\n * words are decided. It reports the CURRENT state rather than the event that\n * triggered it, which is deliberate: by the time a phone wakes up, a colleague\n * may already have answered, and \"3 people waiting\" is truer and more useful\n * than replaying a message from thirty seconds ago.\n */\napp.get(\"/api/m/alert\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n\n const convs = await db.listConversations();\n const waiting = convs.filter((x: any) => String(x[\"status\"]) === \"needs_human\");\n\n // Somebody asking for a human outranks everything else on the list.\n if (waiting.length) {\n const first: any = waiting[0];\n const nm = first[\"name\"] || first[\"email\"] || first[\"phone\"] || \"Someone\";\n return c.json({\n title: waiting.length === 1\n ? `${nm} is waiting to chat`\n : `${waiting.length} people waiting to chat`,\n body: String(first[\"preview\"] ?? \"\").slice(0, 140),\n tag: \"waiting\",\n url: `/m?c=${encodeURIComponent(String(first[\"id\"]))}`,\n });\n }\n\n // Otherwise: the most recent thread where the visitor spoke last, which is\n // the one nobody has answered.\n const live = convs.filter((x: any) =>\n Number(x[\"last_visitor_at\"] ?? 0) >= Number(x[\"last_message_at\"] ?? 0)\n );\n const pick: any = live[0] ?? convs[0];\n if (!pick) return c.json({ error: \"nothing to report\" }, 404);\n\n const nm = pick[\"name\"] || pick[\"email\"] || pick[\"phone\"] || \"Someone\";\n return c.json({\n title: `${nm} started a chat`,\n body: String(pick[\"preview\"] ?? \"\").slice(0, 140),\n tag: String(pick[\"id\"]),\n url: `/m?c=${encodeURIComponent(String(pick[\"id\"]))}`,\n });\n});\n\n/** Is this cookie still good, and whose is it? Drives the auto sign-in. */\napp.get(\"/api/m/me\", async (c) => {\n const who = await whoIsAgent(c);\n if (!who) return c.json({ person: null }, 200);\n return c.json({ person: who.person });\n});\n\napp.post(\"/api/m/logout\", (c) => {\n c.header(\"Set-Cookie\", `${MOBILE_COOKIE}=; Path=/; Max-Age=0; HttpOnly; Secure; SameSite=Lax`);\n return c.json({ ok: true });\n});\n\n/* ------------------------------------------------------ token admin */\n\n/**\n * Mint, list and revoke the per-person tokens.\n *\n * MASTER KEY ONLY — not a session cookie. A token holder must not be able to\n * mint another token or revoke a colleague's; that would collapse two levels\n * of access into one and undo the reason for having per-person credentials.\n */\napp.post(\"/api/agent/tokens\", async (c) => {\n if (!agentAuthed(c)) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { person } = await c.req.json().catch(() => ({ person: \"\" }));\n if (!person || !String(person).trim()) {\n return c.json({ error: \"person required\" }, 400);\n }\n\n const made = await db.createAgentToken(String(person).trim());\n console.log(`token minted for ${person}`);\n\n // The raw token appears in this response and nowhere else, ever. There is no\n // endpoint that can show it again, because only its hash was stored.\n return c.json({\n id: made.id,\n person: String(person).trim(),\n token: made.token,\n url: new URL(c.req.url).origin + \"/m\",\n note: \"Give this to one person. It cannot be shown again — mint a new one if lost.\",\n });\n});\n\napp.get(\"/api/agent/tokens\", async (c) => {\n if (!agentAuthed(c)) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n return c.json({ tokens: await db.listAgentTokens() });\n});\n\n/**\n * Give one person a passcode, so they can sign in with their name instead of\n * 32 hex characters.\n *\n * Master key only, like the rest of token admin. Setting a passcode does not\n * disturb the token — both work, and both point at the same person, so a\n * message is attributed the same way whichever was used to sign in.\n */\napp.post(\"/api/agent/tokens/passcode\", async (c) => {\n if (!agentAuthed(c)) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { id, passcode } = await c.req.json().catch(() => ({}));\n if (!id || !passcode || String(passcode).length < 6) {\n return c.json({ error: \"id and a passcode of at least 6 characters required\" }, 400);\n }\n await db.setPasscode(String(id), String(passcode));\n console.log(`passcode set for token ${id}`);\n return c.json({ ok: true });\n});\n\napp.post(\"/api/agent/tokens/revoke\", async (c) => {\n if (!agentAuthed(c)) return c.json({ error: \"unauthorized\" }, 401);\n await db.init();\n const { id } = await c.req.json().catch(() => ({ id: \"\" }));\n if (!id) return c.json({ error: \"id required\" }, 400);\n await db.revokeAgentToken(String(id));\n console.log(`token revoked: ${id}`);\n return c.json({ ok: true });\n});\n\n/**\n * Somewhere to try the widget without touching the live storefront.\n *\n * ?wp=1 fakes the enrichment the WordPress snippet would supply for a\n * signed-in customer, so both paths can be exercised: anonymous, where the\n * only thing known is what gets typed, and identified, where the account is\n * resolved before a word is said.\n */\napp.get(\"/test\", (c) => {\n const asCustomer = new URL(c.req.url).searchParams.get(\"wp\") === \"1\";\n\n const enrich = asCustomer\n ? ``\n : \"\";\n\n return new Response(\n `\n\n\nTribeca Chat - test page\n\n\n

Tribeca Chat test page

The widget is live in the corner. Nothing here touches tribecabeverage.com.

\n\n

Mode: ${asCustomer ? \"signed-in customer\" : \"anonymous visitor\"}\n · \n switch to ${asCustomer ? \"anonymous\" : \"signed-in\"}

\n\n

Try this first

Ask When is my next delivery? with no phone number given. It should refuse to\n guess a date and ask for one, rather than inventing something plausible.

\n\n

Then give it a number

Reply with 818-321-4845. The account is resolved in code before the model\n answers, so the name it uses comes from Salesforce, not from the model.

\n\n

Then ask for a person

Say can I talk to a person. The AI stops answering and the conversation moves\n to the top of the agent queue.

\n\n

Watch it arrive

Agent console: standalone or the Visualforce page in Salesforce.\n Both show the same conversation.

\n\n${enrich}\n\n`,\n { headers: { \"Content-Type\": \"text/html; charset=utf-8\" } },\n );\n});\n\napp.get(\"/health\", async (c) => {\n await db.init();\n return c.json({\n ok: true,\n // Compare against tribeca-profile's PROFILE_VERSION. If they differ, this\n // val is serving cached prices and needs a redeploy.\n profile: PROFILE_VERSION,\n anthropic: !!anthropicKey(),\n agentKey: !!AGENT_KEY(),\n apollo: !!Deno.env.get(\"APOLLO_TOOL_KEY\"),\n telegram: !!Deno.env.get(\"TELEGRAM_BOT_TOKEN\"),\n });\n});\n\nexport default app.fetch;\n",[203],"c36887f4-541b-4fef-b11b-e2a7741c4d6e","icon.ts","4030794a-a7a4-11f1-95f9-1607ee4eb77e",492,["D",1788445931837],"// The real Tribeca Beverage logo, not a placeholder drawn in code.\n//\n// PULLED FROM THE SITE ITSELF on 9/3/2026 -- tribecabeverage.com serves this\n// exact file as its own favicon and apple-touch-icon\n// (cropped-Tribeca-Logo-FINAL-192x192.png), so it is already the mark the\n// business uses to represent itself at icon size, not a fresh interpretation\n// of one.\n//\n// A REAL PNG, NOT SVG -- this replaced a hand-drawn SVG square that main.ts\n// served from /icon.png. iOS has historically been unreliable about SVG\n// specifically for apple-touch-icon (a plain favicon is\n// fine with SVG; the home-screen icon is the one that is not), and an icon\n// that fails to decode does not fall back to anything -- it shows blank or\n// broken. A PNG, which every real device and OS accepts unconditionally,\n// removes the question entirely.\n//\n// EMBEDDED AS BASE64 RATHER THAN FETCHED AT REQUEST TIME. The icon is asked\n// for by every browser that ever loads /m, and it does not change on its\n// own -- fetching tribecabeverage.com fresh on every request would make a\n// second site's uptime a dependency of this one's icon, for a file that is\n// 28KB and never moves.\nexport const ICON_PNG_BASE64 =\n \"iVBORw0KGgoAAAANSUhEUgAAAMAAAADACAYAAABS3GwHAAAABGdBTUEAALGPC/xhBQAAAAlwSFlzAAAOwwAADsMBx2+oZAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAAAiSURBVHic7cExAQAAAMKg9U9tCF8gAAAAAAAAAAAAAIC3AXNvAAF/\",\n",[211],"0990fefc-26d3-41b8-a48f-556cc386a19e","greeting.ts","3f2669a2-a64a-11f1-8729-1607ee4eb77e",592,["D",1788549248533],72,"// The opening line.\n//\n// WHY THIS IS NOT A CONSTANT ANY MORE\n// tawk opened all 100 exported chats with \"Ask us if we deliver in your area!\n// What city do you live in?\" and it worked — 92% of real visitors replied. But\n// 52% of those first replies were four words or fewer, because the question\n// asks for something we can already know, and 48% of chats never got past that\n// exchange (82s median, against 600s for chats that reached buying intent).\n//\n// So the opener now spends its one turn ANSWERING rather than asking: coverage\n// confirmed, the real delivered price for their region, and an offer to do the\n// signup here. The next reply is then a decision instead of data entry.\n//\n// LOCATION COMES FROM THE ZIP, NEVER FROM AN IP. context.ts explains why in\n// full: city-from-IP means posting every visitor's address to a third-party\n// geolocator, which is the data flow moving off tawk was meant to remove, and\n// it is wrong often enough to put the wrong price in front of someone. A ZIP is\n// volunteered by the customer or already known to WooCommerce, and it is exact.\n// No ZIP means no quote — the generic opener is used instead.\n//\n// PRICES ARE NEVER WRITTEN HERE. They come from tribeca-profile, which is the\n// one place pricing is allowed to live. The ?v= pin is load-bearing: Val Town\n// caches a remote module by URL, so without bumping it this file would keep\n// quoting last week's prices with nothing in the logs.\nimport {\n COOLERS,\n GLASS_5GAL,\n money,\n PLASTIC_5GAL,\n UNSELLABLE_REGIONS,\n} from \"https://esm.town/v/Tribeca_Rep/tribeca-profile/profile.ts?v=2026-09-04b\";\n\n/**\n * THE OPENER. One question, answerable in one word.\n *\n * Chosen 9/1/2026 against measured evidence. tawk opened every one of its 100\n * exported chats with a question — \"what city do you live in?\" — and 92% of\n * real visitors answered; 52% of those replies were four words or fewer,\n * because a cheap question is a cheap thing to answer.\n *\n * This file previously opened by ANSWERING instead: coverage confirmed and the\n * delivered price for their region, in about forty words. Better information,\n * worse bait — 21% replied. Two problems with it. It needs a composed sentence\n * to accept, where tawk needed one word. And leading with the price satisfies\n * the visitor: they came to find out what it costs, they now know, and they can\n * leave.\n *\n * The price has not gone anywhere — the model still has the whole profile and\n * quotes it the moment anyone asks. It is just no longer the first thing said.\n */\nexport const FALLBACK_GREETING = \"Were you interested in water delivery?\";\n\ntype Region = keyof typeof PLASTIC_5GAL;\n\n/**\n * THE CHEAPEST TWO-BOTTLE ALKALINE PRICE WE ACTUALLY CHARGE, computed rather\n * than typed.\n *\n * The variants below say \"starts at\", and \"starts at\" has to be TRUE for every\n * region or it is a bait price — a New Yorker quoted $24.98 who is then billed\n * $31.92 was misled by the first sentence we ever said to them. Taking the\n * minimum from the shared table means it stays true when the table changes, and\n * it keeps this file's rule intact: prices are never written here.\n */\nconst FROM_ALKALINE = Math.min(\n ...Object.values(PLASTIC_5GAL).map((r: any) => Number(r.alkaline)),\n);\n\n/**\n * OPENER SPLIT TEST.\n *\n * Reply rates measured 9/1/2026, first day live. Small numbers, but the shape\n * was consistent enough to act on:\n *\n * \"Hi! Ask us about delivery in your area, pricing, or your account.\" 15/32\n * region-priced (\"We deliver in New Jersey — ... $26.98\") 5/6\n * \"Were you interested in water delivery?\" 0/8\n * \"Do you have glass bottles delivered currently?\" 0/13\n *\n * The two bare questions were at zero. The priced ones were not, and the\n * region-priced figure is confounded — a known ZIP usually means a signed-in\n * customer, a warmer audience — but a price is at least something a visitor has\n * to react to, where a yes/no question is free to ignore.\n *\n * SO IT IS NO LONGER ONE GUESS. Every variant here goes out to a fifth of\n * visitors with an unknown ZIP, and `visitors.opener_variant` records which,\n * so reply rate per variant is a query rather than an argument.\n *\n * NOT IN THE TEST, deliberately: the unsellable-area line, which is a factual\n * correction and not a pitch, and the glass-page opener, which is there by a\n * specific decision about that page. Both would need their own experiment.\n */\nexport const OPENER_VARIANTS: ReadonlyArray<{ id: string; text: string }> = [\n // The control. Keep it in, or the comparison has nothing to sit against.\n { id: \"question\", text: FALLBACK_GREETING },\n\n // DISCOVERY, NOT A PITCH — added 9/2/2026 at the office's request.\n //\n // Every other variant here asks for the sale, the ZIP, or a yes. This one\n // asks about them, and the answer is worth more than a ZIP: \"the store\",\n // \"Poland Spring deliver\", \"a filter\", \"we don't\" each imply a completely\n // different conversation, and none of them are things we can look up.\n //\n // It also cannot be answered with \"no\" and closed, which is how the two bare\n // yes/no variants went 0 from 21. An open question about a habit is easy to\n // answer and hard to dismiss — the shape tawk got 92% on, aimed at something\n // more useful than a city name.\n {\n id: \"discovery\",\n text: \"How do you buy your water at the moment?\",\n },\n\n // THE SAME SHAPE THAT WORKS ON THE GLASS PAGE (\"Do you have glass bottles\n // delivered currently?\"), generalised — added 9/3/2026 at the office's\n // request. It asks something a ZIP cannot answer: whether this is a switch\n // from another delivery service or someone who has never had one at all,\n // and the two deserve different next lines — a switch is a comparison, a\n // first-timer is an explanation. Also a closed question, like the control,\n // but \"do you have X\" invites a story where \"were you interested in X\" only\n // invites yes or no.\n {\n id: \"has_delivery\",\n text: \"Do you have water delivery currently?\",\n },\n\n // Price, no question attached. Gives before it asks, and leaves them holding\n // a number rather than a request.\n {\n id: \"price\",\n text: `Two 5-gallon bottles delivered starts at ${money(FROM_ALKALINE)} a month, no contract.`,\n },\n\n // The winning shape generalised: the fact first, then a question that is one\n // word to answer and hands us the one thing we need.\n {\n id: \"price_zip\",\n text: `Delivery starts at ${money(FROM_ALKALINE)} a month for two 5-gallon bottles. `\n + `What's your ZIP and I'll check your exact price?`,\n },\n\n // Sells the absence of the form, which is the real advantage over the\n // website — the bot can complete a signup that checkout makes people abandon.\n { id: \"setup\", text: \"I can set up delivery in about a minute — want me to?\" },\n\n // Closest to what tawk actually ran at 92%: a person, offering to answer\n // something, with no product in the sentence at all.\n {\n id: \"human\",\n text: \"Hi, TriBeCa team here — anything I can answer while you're looking?\",\n },\n\n // THE 25% OFFER, LED WITH ON PURPOSE — added 9/1/2026 at the office's\n // request, to find out whether it moves engagement.\n //\n // The shared profile says the opposite in as many words: \"THE DISCOUNT IS A\n // CLOSER, NOT AN OPENER... offering money off before anyone has hesitated\n // discounts a sale you had already made.\" That rule is not wrong, and it is\n // deliberately left in place for the model, which still holds the discount\n // back in its own answers. This variant tests the rule rather than repealing\n // it — which is exactly what a split test is for, and the numbers will say\n // whether the discounted conversations are worth what they cost.\n //\n // No code in the line. The offer is the hook; 25for2025 gets applied when\n // the order is actually placed, and a promo code in an opening sentence\n // reads as a coupon popup rather than a person.\n {\n id: \"discount\",\n text: \"Order through me and I'll take 25% off your first delivery — want me to set it up?\",\n },\n];\n\n/**\n * THE GLASS PAGE GETS ITS OWN TEST, because it is a different problem.\n *\n * It is the busiest product page on the site — 100 visitors in the first tracked\n * sample — and the fastest bounce at 76 seconds average. Its opener is also the\n * worst performer measured so far, at 0 replies from 13. The reason is almost\n * certainly the price: glass looks four to five times plastic until you know\n * that $30 a bottle of it is a refundable deposit, and the current line asks a\n * question about their existing service without touching that at all.\n *\n * So the variants split on WHAT TO LEAD WITH: the question we ask now, the\n * deposit that makes the number make sense, or the offer to check their area.\n *\n * THE PROFILE'S \"NEVER VOLUNTEER GLASS\" RULE IS NOT BROKEN HERE. That rule is\n * about not steering someone towards a $134.98 decision they never asked for.\n * Somebody standing on the glass product page has asked. It still holds\n * everywhere else, which is why this set is reachable only from that page.\n */\nexport const GLASS_VARIANTS: ReadonlyArray<{ id: string; text: string }> = [\n // The control — the line running now, so the comparison has a baseline.\n {\n id: \"glass_current\",\n text: \"Do you have glass bottles delivered currently?\",\n },\n\n // Leads with the refundable deposit. If the price is what makes people leave,\n // this is the fact that changes the price.\n {\n id: \"glass_deposit\",\n // \"YOU PAY IT ONCE\" RATHER THAN \"ONE-TIME\" — and the difference is not\n // pedantry. The shared profile forbids calling this deposit one-time, in\n // capitals, because the owner corrected exactly that on 9/1/2026: it is\n // charged on EVERY order and credited back for every empty collected. A\n // customer who keeps a bottle is charged again, which is the entire point.\n //\n // But the thing the office wants stressed is true and is what matters to a\n // buyer: with the empties going back, you pay it on the first order and\n // never again. That is sayable without the word the profile bans.\n text: `Worth knowing on glass: ${money(GLASS_5GAL.depositPerBottle)} of the price `\n + `is a bottle deposit — put the empty out and you get it back, so you only `\n + `pay it on the first order. Want me to check your area?`,\n },\n\n // RETIRED 9/4/2026 — glass_price led with the full itemized breakdown and\n // scored 0 replies from 95 shown, the worst of this test despite having the\n // largest sample. Leading with ANY price on this page loses; glass_check\n // (below, no price at all) is the strongest performer measured so far.\n // Historical rows keep the id, and pageNudge's alreadyPriced check still\n // recognizes it for any straggler session that already saw it — only new\n // assignment is removed.\n\n // No price, no product — just the offer. The counterweight: if the numbers\n // are what scares people off this page, the variant that omits them entirely\n // is the one that tells us.\n {\n id: \"glass_check\",\n text: \"Want me to check whether we deliver glass bottles to you?\",\n },\n\n // The same 25% test, run here too. Glass is where price does the most damage\n // — this is the page people leave fastest — so if leading with money off\n // works anywhere it should work here, and if it does not work HERE the\n // general result is easier to believe.\n {\n id: \"glass_discount\",\n text: \"Order glass through me and I'll take 25% off your first delivery — want the price for your area?\",\n },\n];\n\n/**\n * Which variant this visitor gets — STABLE, from their id, not random.\n *\n * A visitor who reloads or moves to a second page must see the same opener.\n * Math.random() here would reassign them on every page view, so one person\n * could be counted under three variants and the whole comparison would measure\n * nothing. Hashing the id also means no state to store and no coordination\n * between isolates.\n *\n * djb2-ish, forced unsigned. The ids are random hex, so this distributes\n * evenly without anything cleverer.\n */\nexport function openerVariantFor(\n visitorId: unknown,\n set: ReadonlyArray<{ id: string; text: string }> = OPENER_VARIANTS,\n): { id: string; text: string } {\n // No id yet means the very first request of a session, before presence has\n // handed one back. The control is the safe thing to show, and it will not\n // pollute the numbers: the row is written under 'question' either way, and\n // this is the same line that variant carries.\n const s = String(visitorId ?? \"\");\n if (!s) return set[0];\n let h = 0;\n for (let i = 0; i < s.length; i++) h = ((h * 31 + s.charCodeAt(i)) >>> 0);\n return set[h % set.length];\n}\n\n/**\n * ZIP to the pricing region the store itself uses.\n *\n * DELIBERATELY CONSERVATIVE, and it returns null far more often than a ZIP map\n * would. Every range below is one we actually serve; anything outside them —\n * upstate New York, Jacksonville, the Florida panhandle, most of California —\n * returns null and gets the generic opener.\n *\n * The failure modes are not symmetrical. A visitor who gets the generic\n * greeting has lost nothing. A visitor told \"we deliver in your area\" who then\n * finds out we do not has been lied to by a robot, and quoting the wrong\n * region's price is worse still, because the number is the thing they remember.\n */\n/**\n * Areas the store will happily sell to and we cannot actually deliver to.\n *\n * NAMED, not just flagged. There are two of these now, and the opener has to\n * say which one — telling someone in Melbourne that we get asked about\n * \"Greater Philadelphia\" a lot is worse than saying nothing.\n */\nfunction unsellableAreaForZip(z: number): string | null {\n // PENNSYLVANIA REMOVED 9/1/2026 — WE DO DELIVER THERE.\n //\n // 15000-19699 used to return \"Greater Philadelphia Area\" and every PA\n // visitor was opened with \"it needs a team member to set up rather than the\n // website\". The office confirmed we deliver plastic and glass to PA; the\n // store's inability to take the order online was never the same thing as\n // not having a route.\n //\n // PA now falls through to null, the same as any ZIP we hold no price for.\n // That is the correct behaviour while the PA plastic price is unconfirmed:\n // the generic opener, no refusal and no invented number.\n // Sells and prices fine on the website; the route does not exist. Confirmed\n // by the office 9/1/2026.\n // \"area\" is not decoration — the opener says \"the ${which}\", and \"the Greater\n // Melbourne a lot\" is a sentence no person would write.\n if (z >= 32900 && z <= 32999) return \"Greater Melbourne area\";\n return null;\n}\n\nexport function pricingRegionForZip(zip: unknown): Region | \"UNSELLABLE\" | null {\n const z = Number(String(zip ?? \"\").trim().slice(0, 5));\n if (!z || Number.isNaN(z)) return null;\n\n // Checked FIRST. These ranges sit inside otherwise-served states, so a later\n // range test would happily quote them a price for a truck that never comes.\n if (unsellableAreaForZip(z)) return \"UNSELLABLE\";\n\n if (z >= 6000 && z <= 6999) return \"Connecticut\";\n if (z >= 7000 && z <= 8999) return \"New Jersey\";\n\n // NYC, Long Island, Westchester and Rockland only. 12000+ is upstate and not\n // served, so the range deliberately stops short of it.\n if (z >= 10001 && z <= 11999) return \"New York\";\n\n // DC, Maryland and Northern Virginia.\n if (z >= 20000 && z <= 22999) return \"Washington DC Metro (MD, VA)\";\n\n // Los Angeles and Orange County. Northern California is not served.\n if (z >= 90000 && z <= 92899) return \"California\";\n\n // Florida, by route rather than by state. The panhandle (324xx-325xx) and\n // Jacksonville (320xx-322xx) are absent because we do not go there.\n if (z >= 32700 && z <= 32899) return \"Florida - Tampa Metro / Pinellas / Central Florida\"; // Orlando, Kissimmee\n if (z >= 33000 && z <= 33499) return \"Florida - Miami Metro (Dade/Broward/Palm Beach)\";\n if (z >= 33500 && z <= 34299) return \"Florida - Tampa Metro / Pinellas / Central Florida\"; // Tampa, St Pete, Sarasota, Lakeland\n\n return null;\n}\n\n// MOVED TO tribeca-profile ON 9/3/2026, and imported at the top of this file.\n//\n// It lived here, privately, while this was the only file that formatted a\n// price. It is not any more — the order-confirmation line in main.ts hit the\n// identical bug on 9/2/2026 and had to defend itself separately with string\n// concatenation. Five bots read prices out of the shared profile; the\n// formatter belongs beside them, so a fix made once is a fix made everywhere.\n\n/** Short label for the opener — the full keys name routes, not places. */\nfunction placeLabel(region: Region): string {\n if (String(region).startsWith(\"Florida\")) return \"your part of Florida\";\n if (region === \"Washington DC Metro (MD, VA)\") return \"the DC metro\";\n return String(region);\n}\n\n/**\n * Build the opening line.\n *\n * Quotes `cartTotal`, not `pageTotal`. The store's product page under-quotes by\n * $2 in every region except California — a known defect recorded in\n * tribeca-profile — and cartTotal is what the customer is actually charged.\n * Opening with the cheaper number would make the first thing we ever tell them\n * the thing they later find out was wrong.\n *\n * The 25% discount is deliberately NOT here. It is a closer, not an opener:\n * offering money off before anyone has hesitated discounts a sale already made.\n */\n/** The glass product page, by the two URL shapes the store actually uses. */\nfunction isGlassPage(pageUrl: unknown): boolean {\n const u = String(pageUrl ?? \"\").toLowerCase();\n return u.includes(\"glass-bottles\") || (u.includes(\"glass\") && u.includes(\"/product/\"));\n}\n\n/**\n * ARRIVED HERE FROM THE LOGIN PAGE — the same pattern the phone console's\n * cameFrom() already uses to describe this in the detail panel, pulled out so\n * the opener and nudge can act on it rather than only display it.\n *\n * WHY IT MATTERS: someone trying to sign in has already told us the one thing\n * the discovery openers exist to find out. \"How do you buy your water at the\n * moment?\" or \"Do you have water delivery currently?\" asked of a person\n * actively logging into their TriBeCa account is not a question — it is the\n * bot not noticing what is right in front of it.\n */\nfunction cameFromLoginPage(referrer: unknown): boolean {\n return /wp-login\\.php|\\/wp-admin\\/|[?&]action=login/i.test(String(referrer ?? \"\"));\n}\n\n/**\n * RETURNS THE VARIANT ALONGSIDE THE TEXT, not just the line.\n *\n * The console already stores `shown_opener`, so the wording alone could be\n * grouped on — but only until the day someone fixes a comma in one variant,\n * at which point that variant silently splits into two rows and the history\n * before the edit stops matching the history after it. A short stable id\n * survives rewording, which is the whole point of running this for weeks.\n *\n * The fixed branches return an id too (\"unsellable\", \"glass\") rather than\n * null, so the report accounts for every greeting rather than leaving a\n * blank bucket nobody can interpret.\n */\nexport function openingGreeting(\n zip: unknown,\n pageUrl?: unknown,\n visitorId?: unknown,\n isCustomer?: boolean,\n referrer?: unknown,\n): { text: string; variant: string } {\n // A KNOWN PAYING CUSTOMER GETS NO PITCH, CHECKED FIRST.\n //\n // Every branch below exists to sell — a discount, a ZIP-check, an offer to\n // \"get you set up\". None of that belongs in front of someone who already\n // has a route: Brian Grossbard, signed into the customer portal with a\n // delivery on the 12th, does not need to hear \"order through me and I'll\n // take 25% off your first delivery\". It reads as the bot not knowing who he\n // is, when the whole point of the Salesforce match is that we do.\n //\n // CHECKED BEFORE the unsellable-region branch, because it doesn't apply —\n // an existing customer already has a working route, whatever the ZIP table\n // says about new signups in that area. Checked before the glass-page branch\n // for the same reason: there is nothing to upsell them into.\n //\n // ONE FIXED LINE, not run through the split test. The A/B openers exist to\n // learn what converts a stranger; a customer is not being converted, so\n // mixing them into that measurement would blur the result for both.\n if (isCustomer) {\n return {\n variant: \"customer\",\n text: \"Hey! What can I help with?\",\n };\n }\n\n // CAME FROM THE LOGIN PAGE — the discovery question has already been\n // answered by the fact of this visit, so it is not asked again.\n //\n // CHECKED AFTER isCustomer, not merged into it. A login attempt is real\n // evidence of an existing relationship, but it is not the same evidence: a\n // confirmed Salesforce match means we KNOW the account, where this means\n // someone is TRYING to reach one — possibly failing, possibly a brand new\n // WooCommerce signup with no delivery history at all. It earns a different\n // line, not the sf_account block's full no-pitch treatment.\n if (!isCustomer && cameFromLoginPage(referrer)) {\n return {\n variant: \"from_login\",\n text: \"Looks like you were headed to sign in — need a hand with that, \"\n + \"or is there something else I can help with?\",\n };\n }\n\n const region = pricingRegionForZip(zip);\n\n // GLASS IS THE ONE PAGE THAT GETS ITS OWN OPENER.\n //\n // The profile forbids volunteering glass — it is four to five times the price\n // with a $30-per-bottle deposit, and offering it unprompted turns a $26.98\n // decision into a $134.98 one. That rule is about not RAISING it. Someone\n // standing on the glass product page has raised it themselves, so asking\n // about it is answering where they are rather than upselling.\n //\n // Asked as \"currently\" on purpose: it separates an existing glass customer\n // from someone considering it, and either answer is one word.\n //\n // CHECKED AFTER the unsellable branch below, not before. Someone in\n // Philadelphia or Melbourne standing on the glass page cannot be sold\n // anything at all, and asking about their glass delivery before telling them\n // we do not deliver to them is the wrong order to say two things in.\n if (region === \"UNSELLABLE\") {\n // Named per ZIP, NOT UNSELLABLE_REGIONS[0]. That index worked while\n // Philadelphia was the only entry; adding Melbourne on 9/1/2026 would have\n // started telling people in Florida about Pennsylvania.\n const z = Number(String(zip ?? \"\").trim().slice(0, 5));\n const which = unsellableAreaForZip(z) ?? UNSELLABLE_REGIONS[0] ?? \"your area\";\n return {\n variant: \"unsellable\",\n text: `Hi! We get asked about the ${which} a lot — it needs a team member to set up `\n + `rather than the website. Tell me what you need and I'll pass it straight on.`,\n };\n }\n\n // JUST PAID. No pitch, and above all no discount — the variants below\n // include \"25% off your first delivery\", which is the worst sentence we\n // could put in front of somebody who has this second paid full price.\n //\n // This line is only ever seen if they open the widget THEMSELVES; the widget\n // does not auto-open on the receipt page.\n const u0 = String(pageUrl ?? \"\").toLowerCase();\n if (u0.includes(\"order-received\") || u0.includes(\"/thank-you\")) {\n return { variant: \"post_order\", text: \"Anything you need on that order, I'm here.\" };\n }\n\n if (isGlassPage(pageUrl)) {\n // Its own split, on its own set. The glass page is the busiest and the\n // fastest-bouncing on the site, and its single opener is the worst\n // performer measured — so it gets tested rather than guessed at again.\n const g = openerVariantFor(visitorId, GLASS_VARIANTS);\n return { variant: g.id, text: g.text };\n }\n\n // Deliberately the SAME question whether or not we know their region. Knowing\n // the ZIP is still worth everything — it decides the unsellable branch above,\n // it feeds pageNudge, and it means the price is right the moment they ask —\n // but a visitor who has not spoken yet does not need it recited at them.\n //\n // THIS IS THE BRANCH UNDER TEST, and it is the great majority of visitors —\n // most arrive from a search with no ZIP known to anyone. Whatever wins here\n // is the opener the business runs on.\n const v = openerVariantFor(visitorId);\n return { text: v.text, variant: v.id };\n}\n\n/**\n * The second line, sent only when the opener got no reply.\n *\n * WHY IT IS KEYED ON THE PAGE. Measured over the first 394 tracked visitors,\n * what someone is looking at separates them far more sharply than anything else\n * we know:\n *\n * glass bottles 100 visitors, 76s average — the busiest product page and\n * the fastest bounce\n * home 77 visitors, 154s\n * plastic 5gal 25 visitors, 187s\n * contact us 23 visitors, 339s — five minutes filling a form\n * checkout / cart 10 visitors, 334s — five minutes stuck\n *\n * The two long-dwell pages are people already trying to reach you, and the\n * busiest one is people leaving. A generic \"still there?\" earns nothing from\n * any of them, so each gets the one fact that would actually move it.\n *\n * Returns null where a nudge would be wrong rather than merely useless — after\n * checkout the sale is already made, and chasing someone who has just paid\n * reads as a system that has not noticed.\n */\nexport function pageNudge(\n pageUrl: unknown,\n openerVariant?: unknown,\n isCustomer?: boolean,\n referrer?: unknown,\n): string | null {\n // SAME RULE AS THE OPENER: nothing below this line is for someone we\n // already deliver to. Checked first and independent of page, because every\n // branch that follows is keyed on which product page a STRANGER is\n // standing on — checkout, glass, coolers — and a known customer trailing\n // off on any of them still does not need a pitch, just a door left open.\n if (isCustomer) {\n return \"Let me know if anything comes up — happy to help.\";\n }\n\n // SAME LOGIC AS THE OPENER, for someone who did not answer it. Repeating\n // \"do you have delivery currently\" a second time is not just redundant —\n // it never made sense the first time, so a follow-up must not fall through\n // to it either. See cameFromLoginPage on the opener side for the reasoning.\n if (cameFromLoginPage(referrer)) {\n return \"Still having trouble signing in? Happy to help, or I can flag it for the office.\";\n }\n\n const u = String(pageUrl ?? \"\").toLowerCase();\n if (!u) return null;\n\n // THE FOLLOW-UP MUST NOT REPEAT THE OPENER.\n //\n // Caught live 9/1/2026 on the glass page: the opener said \"Glass is $69.99\n // for one bottle or $134.98 for two, delivery included\", and twenty-five\n // seconds later the nudge said the same three numbers again in a longer\n // sentence. Two messages, one fact, nobody having said a word in between —\n // which reads as a machine repeating itself, and is worse than silence.\n //\n // It happened because the openers became variable and this function did not\n // know which one had been used. It does now.\n const alreadyPriced = openerVariant === \"glass_price\" || openerVariant === \"glass_deposit\";\n\n // ALREADY BOUGHT — SAY NOTHING. Removed 9/1/2026 on the office's call.\n //\n // There used to be a cheerful \"Thanks for the order!\" here. It is the wrong\n // instinct: someone who has just paid is reading their receipt, and an\n // unprompted message at that moment is a business interrupting a customer\n // for its own benefit. The widget is still sitting there if they want it.\n if (u.includes(\"order-received\") || u.includes(\"/thank-you\")) return null;\n\n // Stuck in checkout for minutes. This is the highest-value interruption we\n // have, and the offer is to take the work away rather than to help them do it.\n if (u.includes(\"/checkout\") || u.includes(\"/cart\")) {\n return \"If checkout's being awkward I can just set it up here — I only need your \"\n + \"address and how many bottles.\";\n }\n\n // The busiest product page and the shortest visit. The deposit is almost\n // certainly why: the price looks enormous until you know $30 a bottle of it\n // is refundable, so that is the fact that goes first.\n if (u.includes(\"glass-bottles\") || (u.includes(\"glass\") && u.includes(\"/product/\"))) {\n // They have already been given the numbers. Say the thing the price does\n // not say — that most of what looks expensive comes back — and keep it to\n // one line.\n if (alreadyPriced) {\n // A DIFFERENT closing question too. Both glass openers that carry a price\n // end with \"want me to check your area?\", so ending the follow-up the\n // same way asks the same thing twice in a row — which is the smaller\n // version of the bug this branch exists to fix.\n return \"Worth knowing — refills drop to \" + money(GLASS_5GAL.ongoingOneBottle)\n + \" once your empties start going back. Want me to just set it up?\";\n }\n\n // ONE BOTTLE, and the deposit named as one-time and refundable — the same\n // change as glass_price above, for the same reason. The two-bottle total\n // was doing the damage: it is the biggest number on the page and it landed\n // before anyone had explained that most of it comes back.\n return \"On the glass — \" + money(GLASS_5GAL.waterPerBottle) + \" a bottle, \"\n + money(GLASS_5GAL.deliveryFee) + \" delivery per drop, and a \"\n + money(GLASS_5GAL.depositPerBottle) + \" deposit you get back when the empty \"\n + \"goes back. So \" + money(GLASS_5GAL.oneBottleTotal) + \" to start and \"\n + money(GLASS_5GAL.ongoingOneBottle) + \" after. Want me to check your area?\";\n }\n\n if (u.includes(\"cooler\") || u.includes(\"dispenser\")) {\n // All three named, cheapest first. Quoting only \"$8\" for every unit is the\n // mistake the profile now warns about — it was the single \"from\" figure\n // until 9/1/2026 and the other two units were being under-quoted.\n return \"Coolers are \" + money(COOLERS[\"cold only\"]) + \" a month cold only, \"\n + money(COOLERS[\"hot and cold\"]) + \" hot and cold, \"\n + money(COOLERS[\"bottom-load\"]) + \" bottom-load — service is free on all of them. \"\n + \"Want one on a delivery?\";\n }\n\n // Five minutes on a contact form is someone who has decided to get in touch\n // and is doing it the slow way.\n if (u.includes(\"contact\")) {\n return \"No need for the form — just tell me here and I'll sort it or pass it \"\n + \"straight on.\";\n }\n\n if (u.includes(\"/product/\") || u.includes(\"spring-water\") || u.includes(\"water-delivery\")) {\n return \"Want me to check your street and what it'd come to? Just need your ZIP.\";\n }\n\n // Home page and everything else — the widest catch-all, and so the moment\n // \"things get silent\" for most visitors.\n //\n // LEADS WITH THE SAME DISCOVERY QUESTION AS THE OPENER, not a pitch — added\n // 9/3/2026 alongside the has_delivery opener, and for the same reason PACE\n // exists in the AI's own instructions: find out where someone is before\n // asking for the sale. A stranger who ignored a fact-and-ZIP opener is not\n // more likely to answer a second one; a plain question about their own\n // situation is easier to answer and does not read as a second sales attempt.\n //\n // MUST NOT REPEAT THE OPENER — same rule as glass. If has_delivery was\n // already shown and went unanswered, asking it again is the exact bug that\n // was fixed there: two messages, one question, nobody having said a word in\n // between. Falls back to the previous fact-first line instead.\n if (openerVariant === \"has_delivery\") {\n return \"No contract, and you can skip or change any delivery. What's your ZIP and \"\n + \"I'll check your area?\";\n }\n return \"Do you have water delivery currently?\";\n}\n",[218],"6fc5dce1-8299-4383-ba7b-b273df041f8e","db.ts","fcd6841a-a5a4-11f1-abb7-1607ee4eb77e",556,["D",1788532307456],99,"// Tribeca Chat — storage layer\n//\n// Built to replacement spec for tawk.to, run in parallel until the team trusts\n// the notifications. See conversations.status for the AI/human handoff model.\n//\n// Val-scoped SQLite. Every write goes through here so the SSE fan-out in\n// main.ts has exactly one place to hook.\n\nimport { sqlite as rawSqlite } from \"https://esm.town/v/std/sqlite\";\n\n/**\n * RETRY A PLATFORM RATE LIMIT, NOT A REAL ERROR.\n *\n * Val Town's own sqlite service throttles at 1,000 authenticated requests\n * per minute per account. Confirmed live 9/4/2026: a burst of traffic hit\n * that ceiling and every call in this file started throwing a 429 for about\n * ten seconds straight — session start, presence, agent login, all of it,\n * for every visitor and every agent, not just one. The Anthropic side\n * already gets one retry for exactly this shape of transient failure; the\n * database deserves the same rather than a raw 500 reaching a customer over\n * something that clears itself in a few seconds.\n *\n * Retries up to twice, ONLY for a 429 — any other error (a real syntax\n * mistake, a missing table) is rethrown on the first try, because retrying\n * an actual bug three times only delays finding out about it. The error body\n * names its own cooldown (\"Retry again in N seconds\"); that is used instead\n * of guessing, capped so one slow platform window cannot turn into a visitor\n * waiting ten seconds for a heartbeat ping to come back.\n */\nasync function withRetry(fn: () => Promise): Promise {\n for (let attempt = 0; ; attempt++) {\n try {\n return await fn();\n } catch (err) {\n const msg = String((err as any)?.message ?? err);\n const is429 = msg.includes(\"statusCode\\\":429\") || msg.includes(\"Too Many Requests\");\n if (!is429 || attempt >= 2) throw err;\n const m = msg.match(/Retry again in (\\d+) seconds?/);\n const waitMs = Math.min(5000, (m ? Number(m[1]) : attempt + 1) * 1000 + 200);\n await new Promise((r) => setTimeout(r, waitMs));\n }\n }\n}\n\nconst sqlite = {\n execute: (opts: any) => withRetry(() => rawSqlite.execute(opts)),\n batch: (stmts: any) => withRetry(() => rawSqlite.batch(stmts)),\n};\n\n// Bump when the shape changes; init() is safe to call on every request.\nconst SCHEMA_VERSION = 1;\n\nlet ready: Promise | null = null;\n\nexport function init(): Promise {\n // Memoised, not because the CREATEs are expensive, but because Val Town can\n // serve several requests from one isolate and re-running them per request\n // shows up as latency on the visitor's first message.\n if (ready) return ready;\n\n ready = (async () => {\n await sqlite.batch([\n `CREATE TABLE IF NOT EXISTS visitors (\n id TEXT PRIMARY KEY,\n name TEXT,\n email TEXT,\n phone TEXT,\n zip TEXT,\n company TEXT,\n wp_user_id TEXT,\n -- Salesforce answers are cached on the visitor, not looked up per\n -- message. The lookup is two SOQL queries behind a Val Town cold\n -- start; doing it per turn would be felt by the customer.\n sf_account TEXT,\n sf_next_delivery TEXT,\n sf_checked_at INTEGER,\n first_seen INTEGER NOT NULL,\n last_seen INTEGER NOT NULL,\n page_url TEXT,\n user_agent TEXT,\n country TEXT\n )`,\n\n `CREATE TABLE IF NOT EXISTS conversations (\n id TEXT PRIMARY KEY,\n visitor_id TEXT NOT NULL,\n -- ai AI is answering\n -- needs_human handoff requested, nobody has claimed it yet\n -- human an agent has taken over; the AI must stay silent\n -- closed ended\n status TEXT NOT NULL DEFAULT 'ai',\n assigned_to TEXT,\n -- Set when status first becomes needs_human, so we can measure how\n -- long customers actually wait. That number is the whole argument for\n -- or against cutting over from tawk.\n handoff_at INTEGER,\n claimed_at INTEGER,\n created_at INTEGER NOT NULL,\n last_message_at INTEGER NOT NULL,\n FOREIGN KEY (visitor_id) REFERENCES visitors(id)\n )`,\n\n `CREATE TABLE IF NOT EXISTS messages (\n id TEXT PRIMARY KEY,\n conversation_id TEXT NOT NULL,\n -- visitor | ai | agent | system\n sender TEXT NOT NULL,\n -- Display name for agent messages; null for visitor/ai/system.\n sender_name TEXT,\n body TEXT NOT NULL,\n created_at INTEGER NOT NULL,\n FOREIGN KEY (conversation_id) REFERENCES conversations(id)\n )`,\n\n // The dashboard's default view is \"conversations needing attention,\n // newest first\", and the visitor stream polls by conversation. Both are\n // hot paths on every keystroke, so they get indexes from day one.\n `CREATE INDEX IF NOT EXISTS idx_msg_conv ON messages(conversation_id, created_at)`,\n `CREATE INDEX IF NOT EXISTS idx_conv_status ON conversations(status, last_message_at DESC)`,\n `CREATE INDEX IF NOT EXISTS idx_conv_visitor ON conversations(visitor_id)`,\n\n `CREATE TABLE IF NOT EXISTS meta (k TEXT PRIMARY KEY, v TEXT)`,\n\n // WHAT THE VISITOR DID, as opposed to what they said.\n //\n // A SEPARATE TABLE FROM messages, AND THAT IS THE WHOLE POINT.\n // A 'system' message would have been less code, but system messages are\n // rendered in the widget — the customer would watch us narrate their own\n // browsing back at them, which is the single creepiest thing this\n // product could do. Events live here instead, are returned only by the\n // agent endpoints, and have no path to the visitor's screen at all.\n // That is a structural guarantee rather than a rule someone has to\n // remember when writing the next endpoint.\n //\n // page_url is overwritten on every heartbeat, so before this table the\n // sequence a visitor moved through was destroyed as it happened: the\n // console could say \"7 pages viewed\" but never which seven.\n `CREATE TABLE IF NOT EXISTS visitor_events (\n id TEXT PRIMARY KEY,\n visitor_id TEXT NOT NULL,\n kind TEXT NOT NULL,\n detail TEXT,\n created_at INTEGER NOT NULL\n )`,\n // Ordered lookup per visitor — the only query this table ever serves.\n `CREATE INDEX IF NOT EXISTS idx_events_visitor\n ON visitor_events(visitor_id, created_at)`,\n\n // ONE CREDENTIAL PER PERSON, instead of one shared key for everybody.\n //\n // The console can read every visitor's name, email, phone and transcript,\n // and it can send messages to customers AS TRIBECA. A single shared\n // secret guarding that has three failures that only show up later: there\n // is no answer to \"who sent that\", one person leaving means rotating for\n // everyone, and shared secrets end up pasted into WhatsApp. None of those\n // are fixed by making the secret longer.\n //\n // THE RAW TOKEN IS NEVER STORED. Only its SHA-256 lands here, so this\n // table leaking does not hand anyone a working login — the same reason\n // passwords are not stored either. It is shown once, at creation, and\n // cannot be recovered afterwards; a lost token is replaced, not looked up.\n `CREATE TABLE IF NOT EXISTS agent_tokens (\n id TEXT PRIMARY KEY,\n person TEXT NOT NULL,\n token_hash TEXT NOT NULL UNIQUE,\n created_at INTEGER NOT NULL,\n last_used_at INTEGER,\n -- Set rather than deleted, so a revoked token stays visible in the\n -- list. \"This token was revoked on the 4th\" is a fact worth keeping;\n -- a row that simply vanishes tells nobody anything.\n revoked_at INTEGER\n )`,\n `CREATE INDEX IF NOT EXISTS idx_token_hash ON agent_tokens(token_hash)`,\n\n // WHERE TO PUSH A NOTIFICATION. One row per installed phone.\n //\n // The endpoint is a URL the browser's push service handed us — Apple's\n // for an iPhone, Google's for Android. It IS the credential: anyone\n // holding it can push to that device, which is why it is only ever\n // written by the signed-in owner and never handed back out.\n //\n // Tied to a token_id, so revoking somebody's access takes their phone's\n // notifications with it rather than leaving a device buzzing with\n // customer names after they have left.\n `CREATE TABLE IF NOT EXISTS push_subs (\n id TEXT PRIMARY KEY,\n token_id TEXT NOT NULL,\n endpoint TEXT NOT NULL UNIQUE,\n created_at INTEGER NOT NULL,\n last_ok_at INTEGER,\n -- A push service returns 404/410 once an app is uninstalled or the\n -- subscription lapses. Counting failures lets a dead device be dropped\n -- instead of being retried on every conversation for ever.\n fails INTEGER DEFAULT 0\n )`,\n ]);\n\n // Additive migrations. CREATE TABLE IF NOT EXISTS does nothing to a table\n // that already exists, so each new column is added on its own and its\n // \"duplicate column\" error swallowed. Cheaper than a migration framework\n // for a handful of columns, and safe to run on every cold start.\n for (const stmt of [\n `ALTER TABLE visitors ADD COLUMN referrer TEXT`,\n `ALTER TABLE visitors ADD COLUMN landing_url TEXT`,\n `ALTER TABLE visitors ADD COLUMN visits INTEGER DEFAULT 1`,\n `ALTER TABLE visitors ADD COLUMN session_started INTEGER`,\n // Coarse device, derived from the User-Agent and stored INSTEAD of it.\n // The raw UA string is a fingerprint we have no use for; \"Windows\" and\n // \"Chrome\" is the entire operational value of it.\n `ALTER TABLE visitors ADD COLUMN os TEXT`,\n `ALTER TABLE visitors ADD COLUMN browser TEXT`,\n `ALTER TABLE visitors ADD COLUMN page_views INTEGER DEFAULT 0`,\n `ALTER TABLE visitors ADD COLUMN time_on_site_ms INTEGER DEFAULT 0`,\n // Set when the browser sent Global Privacy Control or Do Not Track. A\n // stored flag, so it is auditable rather than merely honoured in passing.\n `ALTER TABLE visitors ADD COLUMN dnt INTEGER DEFAULT 0`,\n // Stamped when the idle sweep has nudged a conversation. Its only job is\n // to make \"at most once, ever\" a property of the data rather than\n // something the sweep has to remember.\n `ALTER TABLE conversations ADD COLUMN nudged_at INTEGER`,\n // Is the panel open on their screen right now, or have they minimised it?\n // An agent deciding whether to say something needs to know whether anyone\n // is actually looking at the window.\n `ALTER TABLE visitors ADD COLUMN chat_open INTEGER DEFAULT 0`,\n // WHAT THE VISITOR WAS ACTUALLY SHOWN. The opener and the page-specific\n // follow-up are rendered in the browser and never stored as messages, so\n // the console displayed an empty thread for someone who had been spoken\n // to twice. Recorded here so an agent can see what they are replying to.\n `ALTER TABLE visitors ADD COLUMN shown_opener TEXT`,\n `ALTER TABLE visitors ADD COLUMN shown_nudge TEXT`,\n // WHICH OPENER VARIANT THIS VISITOR WAS ASSIGNED. shown_opener already\n // holds the words, so this looks redundant — it is not. Grouping a split\n // test on prose means the first typo fix silently splits one variant into\n // two rows and severs the history either side of the edit. A short id\n // survives rewording, which a test meant to run for weeks needs.\n `ALTER TABLE visitors ADD COLUMN opener_variant TEXT`,\n // WHEN THE BROWSER SAID IT WAS LEAVING, as opposed to when we last heard\n // from it. Before this, \"gone\" could only ever be a guess from a missing\n // heartbeat, and a missing heartbeat is also what switching tabs, locking\n // a phone, or a throttled timer looks like. A pagehide beacon is the one\n // moment the browser will actually tell us. Cleared by the next ping, so\n // clicking through to another page on the site does not read as leaving.\n `ALTER TABLE visitors ADD COLUMN left_at INTEGER`,\n // THE VISITOR CLOSED THE CHAT, so the widget will not open itself at them\n // again for a week. It lives in their localStorage, which means the\n // console had no way to know — and \"browsing, never contacted\" looked\n // identical whether we had failed to speak to someone or they had told us\n // to stop. Reported on the heartbeat so the reason is on the row.\n `ALTER TABLE visitors ADD COLUMN chat_dismissed INTEGER DEFAULT 0`,\n // How many times we have asked this conversation for a name or a number\n // after a handoff. Capped, because the one thing worse than not getting\n // a callback number is a bot asking a third time for something the\n // person has decided not to give.\n `ALTER TABLE conversations ADD COLUMN contact_asks INTEGER DEFAULT 0`,\n // DID THE PAGE THEY ARRIVED ON ACTUALLY EXIST?\n //\n // A real customer on 9/2/2026 landed on /my-account/invoices/, which is a\n // 404, went to the login screen, and was still not signed in three page\n // views later. The console showed \"Anonymous, browsing\" — every fact\n // needed to read that as \"customer locked out\" was on the row already and\n // none of it was legible.\n //\n // Reported by the widget rather than guessed here: it is running inside\n // the page and can simply read WordPress's own `error404` body class.\n // Nothing else can know it — the console cannot fetch the URL to check,\n // and a list of known-dead paths would be stale within a week.\n //\n // Deliberately nullable, not DEFAULT 0, so COALESCE keeps the FIRST\n // answer — which is the landing page, the one worth knowing about.\n `ALTER TABLE visitors ADD COLUMN landing_404 INTEGER`,\n // WHICH CHAT THIS VISITOR WAS ACTUALLY SHOWN — 'ours' or 'tawk'.\n //\n // In split mode the site assigns each visitor one of the two and they\n // keep it. Our widget reports presence in BOTH arms (it loads either way\n // and simply renders nothing for the tawk half), which is the whole\n // reason the comparison is possible from this side at all: tawk's own\n // dashboard can tell you how many people talked to tawk, but only this\n // can tell you how many were OFFERED it and did not.\n //\n // COALESCE on write: the first answer is the assignment, and it is\n // sticky by design. A later NULL from an older cached widget build must\n // not erase it.\n `ALTER TABLE visitors ADD COLUMN chat_arm TEXT`,\n // WHAT THE TAWK HALF ACTUALLY DID.\n //\n // Without these the split is only half measurable: this database knows\n // how many people were OFFERED tawk but nothing about whether they used\n // it, so the tawk arm's engagement reads 0 by construction and the two\n // arms cannot be compared on the same numerator.\n //\n // Tawk exposes its own callbacks (onChatMaximized, onChatMessageVisitor),\n // and in split mode WE inject tawk, so we can attach to them before it\n // loads. That puts both arms' engagement in one table, measured the same\n // way, instead of asking someone to reconcile two dashboards by eye.\n `ALTER TABLE visitors ADD COLUMN tawk_opened_at INTEGER`,\n `ALTER TABLE visitors ADD COLUMN tawk_messaged_at INTEGER`,\n // DID THIS VISITOR ACTUALLY BUY, AND FOR HOW MUCH.\n //\n // Engagement is a proxy. The question worth answering about two chat\n // widgets is which one sold more water, and until now nothing here could\n // answer it: the checkout snippet identified who someone WAS and threw\n // away what they had just bought.\n //\n // FIRST ORDER ONLY, by COALESCE. A returning customer's second order is\n // not attributable to the chat they saw on their first visit, and\n // counting it would flatter whichever arm happened to catch the regulars.\n `ALTER TABLE visitors ADD COLUMN order_id TEXT`,\n `ALTER TABLE visitors ADD COLUMN order_total REAL`,\n `ALTER TABLE visitors ADD COLUMN order_at INTEGER`,\n // A LEAD, NOT AN ACCOUNT. Someone who filled out the website popup gets\n // a real Salesforce Lead with no link back to this visitor row at all —\n // confirmed 9/3/2026 checking a real one end to end. These columns are\n // how the chat closes that gap once it learns a phone or email that\n // matches one, so the bot can acknowledge it instead of asking for\n // details already on file somewhere else.\n `ALTER TABLE visitors ADD COLUMN sf_lead_company TEXT`,\n `ALTER TABLE visitors ADD COLUMN sf_lead_status TEXT`,\n `ALTER TABLE visitors ADD COLUMN sf_lead_checked_at INTEGER`,\n // A PASSCODE PER PERSON, so signing in on a phone does not mean typing\n // 32 hex characters. The token still works and is still the strong\n // credential; this is the humane one.\n //\n // It is deliberately NOT a shared password. The point of the whole table\n // is that a message can be attributed and one person's access can be\n // withdrawn without disturbing anyone else, and a passcode everybody\n // knows throws both of those away while looking like a small convenience.\n //\n // PBKDF2, not a bare SHA-256, because unlike the tokens this is a value a\n // human chose and is therefore in somebody's dictionary. The salt is per\n // person so two people picking the same passcode do not collide visibly.\n `ALTER TABLE agent_tokens ADD COLUMN passcode_hash TEXT`,\n `ALTER TABLE agent_tokens ADD COLUMN passcode_salt TEXT`,\n // Failed attempts, for backoff. Kept ON THE ROW rather than in a\n // transient keyed on IP — which is exactly what locked the owner out of\n // the /chat control page on 9/2/2026, because behind the host's proxy\n // every visitor shares one address and the limit became global.\n `ALTER TABLE agent_tokens ADD COLUMN fails INTEGER DEFAULT 0`,\n `ALTER TABLE agent_tokens ADD COLUMN last_fail_at INTEGER`,\n // HOW MANY TIMES we have picked a stalled conversation back up.\n //\n // nudged_at alone made it once per conversation for ever: someone who\n // went quiet, got a nudge, came back, talked for five minutes and then\n // stalled again — mid-signup — was left there. That second stall is the\n // expensive one, because by then they have shown they want it.\n `ALTER TABLE conversations ADD COLUMN nudge_count INTEGER DEFAULT 0`,\n // BACKFILL, and it matters. A new column defaults to 0, so every\n // conversation already nudged under the old scheme would have read as\n // \"never nudged\" and been sent a second message. Guarded so it is a\n // no-op on every run after the first.\n `UPDATE conversations SET nudge_count = 1\n WHERE nudged_at IS NOT NULL AND COALESCE(nudge_count, 0) = 0`,\n // ACTIVITY ONLY, NEVER CONTENT. This records that the visitor's\n // textarea has keystrokes in it right now — not what they say, not\n // even whether they end up sending it. A console showing a live draft\n // of unset text is a materially different (and much more invasive)\n // thing than this, and deliberately not what got built.\n `ALTER TABLE conversations ADD COLUMN visitor_typing_at INTEGER`,\n ]) {\n try {\n await sqlite.execute(stmt);\n } catch (_e) {\n // Column already present. Nothing to do.\n }\n }\n\n await sqlite.execute({\n sql: `INSERT INTO meta (k, v) VALUES ('schema_version', ?)\n ON CONFLICT(k) DO UPDATE SET v = excluded.v`,\n args: [String(SCHEMA_VERSION)],\n });\n })();\n\n return ready;\n}\n\nexport function now(): number {\n return Date.now();\n}\n\n// Prefixed so an id is self-describing in logs and in the dashboard URL.\nexport function id(prefix: string): string {\n return prefix + \"_\" + crypto.randomUUID().replace(/-/g, \"\").slice(0, 20);\n}\n\n/**\n * std/sqlite returns each row as an ARRAY of values, not an object.\n *\n * Everything downstream — the widget, both consoles, and the model's turn\n * builder — reads rows by column name, so they all silently saw `undefined`\n * and produced nothing. Converting here, at the single place every query\n * passes through, rather than teaching four callers about tuple order.\n */\nfunction rowsToObjects(result: any): any[] {\n const cols: string[] = result?.columns ?? [];\n return (result?.rows ?? []).map((row: any) =>\n Array.isArray(row)\n ? Object.fromEntries(cols.map((c, i) => [c, row[i]]))\n : row\n );\n}\n\n/* -------------------------------------------------------- agent tokens */\n\n/**\n * SHA-256, hex. Used for token storage, never for anything a user picks.\n *\n * A plain hash is right HERE and would be wrong for a password: these tokens\n * are 128 bits of crypto-random, so there is no dictionary to run and no work\n * factor worth paying. What the hash buys is that a copy of this table is not\n * a set of working logins.\n */\nexport async function sha256hex(s: string): Promise {\n const buf = await crypto.subtle.digest(\"SHA-256\", new TextEncoder().encode(s));\n return [...new Uint8Array(buf)].map((b) => b.toString(16).padStart(2, \"0\")).join(\"\");\n}\n\n/**\n * Mint a token for one person. The raw value is returned ONCE and never again.\n *\n * 128 bits from crypto.getRandomValues. Not Math.random, which is seeded from\n * something predictable and would make every token guessable from any other.\n */\nexport async function createAgentToken(person: string): Promise<{ id: string; token: string }> {\n const bytes = crypto.getRandomValues(new Uint8Array(16));\n const token = [...bytes].map((b) => b.toString(16).padStart(2, \"0\")).join(\"\");\n const tid = id(\"t\");\n\n await sqlite.execute({\n sql: `INSERT INTO agent_tokens (id, person, token_hash, created_at)\n VALUES (?, ?, ?, ?)`,\n args: [tid, person.slice(0, 60), await sha256hex(token), now()],\n });\n\n return { id: tid, token };\n}\n\n/** Resolve a raw token to the person holding it, or null. Revoked tokens fail. */\nexport async function resolveAgentToken(token: string) {\n const r = await sqlite.execute({\n sql: `SELECT id, person FROM agent_tokens\n WHERE token_hash = ? AND revoked_at IS NULL`,\n args: [await sha256hex(token)],\n });\n return rowsToObjects(r)[0] ?? null;\n}\n\n/**\n * Resolve a token ID from an already-signed session cookie.\n *\n * Checked on EVERY request rather than trusted from the cookie's signature\n * alone. The signature only proves we issued it; this proves it is still\n * valid — which is what makes revocation take effect immediately instead of\n * whenever the holder's 30-day cookie happens to lapse.\n */\nexport async function agentTokenById(tid: string) {\n const r = await sqlite.execute({\n sql: `SELECT id, person FROM agent_tokens\n WHERE id = ? AND revoked_at IS NULL`,\n args: [tid],\n });\n return rowsToObjects(r)[0] ?? null;\n}\n\n/**\n * PBKDF2-SHA256, 150k iterations.\n *\n * Slow ON PURPOSE, which is the opposite of what the tokens want. A token is\n * 128 random bits and nobody is going to guess it, so hashing speed is\n * irrelevant. A passcode is a word somebody thought of, so the only thing\n * standing between a stolen database and a working login is how long each\n * guess costs. 150k iterations is a few hundred milliseconds once at sign-in\n * and a wall for anyone working through a list.\n */\nexport async function passcodeHash(passcode: string, saltHex: string): Promise {\n const salt = Uint8Array.from(saltHex.match(/.{2}/g)!.map((h) => parseInt(h, 16)));\n const key = await crypto.subtle.importKey(\n \"raw\",\n new TextEncoder().encode(passcode),\n \"PBKDF2\",\n false,\n [\"deriveBits\"],\n );\n const bits = await crypto.subtle.deriveBits(\n { name: \"PBKDF2\", salt, iterations: 150000, hash: \"SHA-256\" },\n key,\n 256,\n );\n return [...new Uint8Array(bits)].map((b) => b.toString(16).padStart(2, \"0\")).join(\"\");\n}\n\n/** Set (or replace) one person's passcode. Clears any accumulated backoff. */\nexport async function setPasscode(tid: string, passcode: string) {\n const saltBytes = crypto.getRandomValues(new Uint8Array(16));\n const salt = [...saltBytes].map((b) => b.toString(16).padStart(2, \"0\")).join(\"\");\n await sqlite.execute({\n sql: `UPDATE agent_tokens\n SET passcode_hash = ?, passcode_salt = ?, fails = 0, last_fail_at = NULL\n WHERE id = ?`,\n args: [await passcodeHash(passcode, salt), salt, tid],\n });\n}\n\n/**\n * The row for a named person, for passcode sign-in.\n *\n * Case- and space-insensitive on the name, because the person typing it on a\n * phone is typing their own name from memory, not copying an identifier.\n */\nexport async function agentByPerson(person: string) {\n const r = await sqlite.execute({\n sql: `SELECT id, person, passcode_hash, passcode_salt, fails, last_fail_at\n FROM agent_tokens\n WHERE LOWER(TRIM(person)) = LOWER(TRIM(?))\n AND revoked_at IS NULL\n AND passcode_hash IS NOT NULL\n LIMIT 1`,\n args: [person],\n });\n return rowsToObjects(r)[0] ?? null;\n}\n\nexport async function notePasscodeFail(tid: string) {\n await sqlite.execute({\n sql: `UPDATE agent_tokens\n SET fails = COALESCE(fails, 0) + 1, last_fail_at = ?\n WHERE id = ?`,\n args: [now(), tid],\n });\n}\n\nexport async function clearPasscodeFails(tid: string) {\n await sqlite.execute({\n sql: `UPDATE agent_tokens SET fails = 0, last_fail_at = NULL WHERE id = ?`,\n args: [tid],\n });\n}\n\n/** Last-used stamp, so a token nobody uses is visibly safe to revoke. */\nexport async function touchAgentToken(tid: string) {\n await sqlite.execute({\n sql: `UPDATE agent_tokens SET last_used_at = ? WHERE id = ?`,\n args: [now(), tid],\n });\n}\n\nexport async function listAgentTokens() {\n const r = await sqlite.execute({\n // token_hash is deliberately NOT selected. It is not usable as a login,\n // but there is no reason for it to travel to a browser either.\n sql: `SELECT id, person, created_at, last_used_at, revoked_at\n FROM agent_tokens ORDER BY created_at DESC`,\n args: [], // Required — see livePushSubs.\n });\n return rowsToObjects(r);\n}\n\nexport async function revokeAgentToken(tid: string) {\n await sqlite.execute({\n sql: `UPDATE agent_tokens SET revoked_at = COALESCE(revoked_at, ?) WHERE id = ?`,\n args: [now(), tid],\n });\n}\n\n/* -------------------------------------------------------- visitor events */\n\n/**\n * Record something the visitor DID. Agent-facing only — see the table comment.\n *\n * DEDUPED AGAINST THE LAST EVENT OF THE SAME KIND. Presence pings arrive every\n * few seconds and each one carries the current page, so without this a visitor\n * sitting still on one page would generate an identical row every heartbeat and\n * the timeline would be unreadable within a minute.\n */\nexport async function recordEvent(\n visitorId: string,\n kind: string,\n detail?: string | null,\n) {\n const last = await sqlite.execute({\n sql: `SELECT kind, detail FROM visitor_events\n WHERE visitor_id = ? ORDER BY created_at DESC LIMIT 1`,\n args: [visitorId],\n });\n const prev = rowsToObjects(last)[0];\n if (prev && String(prev[\"kind\"]) === kind && String(prev[\"detail\"] ?? \"\") === String(detail ?? \"\")) {\n return;\n }\n\n await sqlite.execute({\n sql: `INSERT INTO visitor_events (id, visitor_id, kind, detail, created_at)\n VALUES (?, ?, ?, ?, ?)`,\n args: [id(\"e\"), visitorId, kind, detail ?? null, now()],\n });\n}\n\n/** The trail, oldest first, for interleaving into a thread by timestamp. */\nexport async function getEvents(visitorId: string, limit = 200) {\n const r = await sqlite.execute({\n sql: `SELECT kind, detail, created_at FROM visitor_events\n WHERE visitor_id = ? ORDER BY created_at ASC LIMIT ?`,\n args: [visitorId, limit],\n });\n return rowsToObjects(r);\n}\n\n/* ---------------------------------------------------- push subscriptions */\n\n/** Remember a phone. Re-subscribing the same device updates rather than duplicates. */\nexport async function addPushSub(tokenId: string, endpoint: string) {\n await sqlite.execute({\n sql: `INSERT INTO push_subs (id, token_id, endpoint, created_at)\n VALUES (?, ?, ?, ?)\n ON CONFLICT(endpoint) DO UPDATE SET\n token_id = excluded.token_id,\n fails = 0`,\n args: [id(\"ps\"), tokenId, endpoint, now()],\n });\n}\n\n/**\n * Every phone that should be buzzed.\n *\n * JOINed against agent_tokens so a REVOKED person's device stops receiving\n * customer names immediately. Without the join, revocation would take away\n * someone's ability to open the console while still pushing them every\n * customer's name and message — which is the wrong half.\n */\nexport async function livePushSubs() {\n const r = await sqlite.execute({\n sql: `SELECT p.id, p.endpoint\n FROM push_subs p\n JOIN agent_tokens t ON t.id = p.token_id\n WHERE t.revoked_at IS NULL\n AND COALESCE(p.fails, 0) < 5`,\n // args IS REQUIRED even with no placeholders. std/sqlite rejects a\n // statement object without it — \"body/statement must have required\n // property 'args'\" — and the failure surfaces far from here, as a push\n // that never sends.\n args: [],\n });\n return rowsToObjects(r);\n}\n\nexport async function pushOk(id: string) {\n await sqlite.execute({\n sql: `UPDATE push_subs SET last_ok_at = ?, fails = 0 WHERE id = ?`,\n args: [now(), id],\n });\n}\n\n/** A gone device is deleted outright; a flaky one just counts up. */\nexport async function pushFailed(id: string, gone: boolean) {\n await sqlite.execute(\n gone\n ? { sql: `DELETE FROM push_subs WHERE id = ?`, args: [id] }\n : { sql: `UPDATE push_subs SET fails = COALESCE(fails,0) + 1 WHERE id = ?`, args: [id] },\n );\n}\n\nexport async function removePushSub(endpoint: string) {\n await sqlite.execute({\n sql: `DELETE FROM push_subs WHERE endpoint = ?`,\n args: [endpoint],\n });\n}\n\n/** Does this person already have a phone registered? Drives the button state. */\nexport async function hasPushSub(tokenId: string): Promise {\n const r = await sqlite.execute({\n sql: `SELECT COUNT(*) AS n FROM push_subs WHERE token_id = ?`,\n args: [tokenId],\n });\n return Number(rowsToObjects(r)[0]?.[\"n\"] ?? 0) > 0;\n}\n\n/* ------------------------------------------------------------------ visitors */\n\nexport async function upsertVisitor(v: {\n id: string;\n name?: string | null;\n email?: string | null;\n phone?: string | null;\n zip?: string | null;\n company?: string | null;\n wpUserId?: string | null;\n pageUrl?: string | null;\n country?: string | null;\n os?: string | null;\n browser?: string | null;\n}) {\n const t = now();\n\n // COALESCE on update, so a later page view that knows less about the visitor\n // never blanks out what an earlier one established. Enrichment only ever\n // adds. The exception is page_url, which should always be the current page.\n await sqlite.execute({\n sql: `INSERT INTO visitors\n (id, name, email, phone, zip, company, wp_user_id,\n first_seen, last_seen, page_url, country, os, browser)\n VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)\n ON CONFLICT(id) DO UPDATE SET\n name = COALESCE(excluded.name, visitors.name),\n email = COALESCE(excluded.email, visitors.email),\n phone = COALESCE(excluded.phone, visitors.phone),\n zip = COALESCE(excluded.zip, visitors.zip),\n company = COALESCE(excluded.company, visitors.company),\n wp_user_id = COALESCE(excluded.wp_user_id, visitors.wp_user_id),\n last_seen = excluded.last_seen,\n page_url = excluded.page_url,\n country = COALESCE(excluded.country, visitors.country),\n os = COALESCE(excluded.os, visitors.os),\n browser = COALESCE(excluded.browser, visitors.browser)`,\n args: [\n v.id, v.name ?? null, v.email ?? null, v.phone ?? null, v.zip ?? null,\n v.company ?? null, v.wpUserId ?? null, t, t,\n v.pageUrl ?? null, v.country ?? null, v.os ?? null, v.browser ?? null,\n ],\n });\n}\n\n/**\n * Record a phone number the visitor typed in the chat.\n *\n * Separate from upsertVisitor because that one always overwrites page_url, and\n * this is called mid-conversation where we know nothing else about the page.\n *\n * COALESCE, so a number WordPress already verified for a signed-in customer is\n * not replaced by one typed into a chat box. The typed number is still used for\n * the lookup either way — this only decides what the agent panel keys off.\n */\n/**\n * A name the visitor typed into the chat, usually after being asked for one so\n * the team can call back.\n *\n * COALESCE, like the phone: a name WordPress already had for a signed-in\n * customer outranks anything guessed out of a sentence. Deliberately does NOT\n * touch page_url, which upsertVisitor always overwrites.\n */\nexport async function setVisitorName(visitorId: string, name: string) {\n await sqlite.execute({\n sql: `UPDATE visitors SET name = COALESCE(name, ?) WHERE id = ?`,\n args: [name, visitorId],\n });\n}\n\n/** Count an ask, and hand back the new total so the caller can stop at the cap. */\nexport async function bumpContactAsks(cid: string): Promise {\n await sqlite.execute({\n sql: `UPDATE conversations SET contact_asks = COALESCE(contact_asks,0) + 1 WHERE id = ?`,\n args: [cid],\n });\n const r = await sqlite.execute({\n sql: `SELECT contact_asks FROM conversations WHERE id = ?`,\n args: [cid],\n });\n return Number(rowsToObjects(r)[0]?.[\"contact_asks\"] ?? 0);\n}\n\nexport async function setVisitorPhone(visitorId: string, phone: string) {\n await sqlite.execute({\n sql: `UPDATE visitors SET phone = COALESCE(phone, ?) WHERE id = ?`,\n args: [phone, visitorId],\n });\n}\n\n/**\n * Same shape as setVisitorPhone, for the same reason: an email scanned out\n * of a chat message was previously used ONLY for the one-off Lead lookup in\n * enrich() and then discarded — never written to the visitor row itself, so\n * it never reached VERIFIED ACCOUNT, the agent console, or anything built\n * later off \"do we have an email for this person.\" COALESCE so a real one\n * from WordPress is never overwritten by a typo typed into the chat box.\n */\nexport async function setVisitorEmail(visitorId: string, email: string) {\n await sqlite.execute({\n sql: `UPDATE visitors SET email = COALESCE(email, ?) WHERE id = ?`,\n args: [email, visitorId],\n });\n}\n\n/**\n * Record the opener at the moment the SERVER hands it over.\n *\n * Better than waiting for the widget to report it, for two reasons. It works\n * for every visitor immediately rather than only those who have picked up a new\n * widget.js past its five-minute cache — which was nobody for the first several\n * minutes. And it cannot disagree with what was displayed: the widget draws the\n * greeting on exactly the condition the caller checks here, an empty thread.\n *\n * COALESCE, so the first opener a visitor saw is the one kept.\n */\nexport async function setShownOpener(\n visitorId: string,\n text: string,\n variant?: string | null,\n) {\n await sqlite.execute({\n sql: `UPDATE visitors\n SET shown_opener = COALESCE(shown_opener, ?),\n opener_variant = COALESCE(opener_variant, ?)\n WHERE id = ?`,\n args: [text, variant ?? null, visitorId],\n });\n}\n\n/**\n * The split test's scoreboard.\n *\n * REPLIED means the visitor sent at least one message of their own — the only\n * thing an opener can be judged on. Not opens, not time on page: whether a real\n * person answered.\n *\n * Counted per VISITOR, not per conversation, because assignment is per visitor:\n * someone who returns a week later keeps their variant, and counting their\n * second conversation separately would weight the regulars.\n *\n * The `since` argument matters more than it looks. Every row written before the\n * test started has a null variant, and a \"no variant\" bucket sitting at the top\n * of the table is the kind of thing that gets read as a result.\n */\nexport async function openerReport(since = 0) {\n const r = await sqlite.execute({\n sql: `SELECT COALESCE(v.opener_variant, '(pre-test)') AS variant,\n COUNT(*) AS shown,\n SUM(CASE WHEN EXISTS (\n SELECT 1 FROM messages m\n JOIN conversations c ON c.id = m.conversation_id\n WHERE c.visitor_id = v.id AND m.sender = 'visitor')\n THEN 1 ELSE 0 END) AS replied,\n -- One example of the wording, so the report is readable\n -- without going and looking up what \"price_zip\" says.\n MAX(v.shown_opener) AS example\n FROM visitors v\n WHERE v.shown_opener IS NOT NULL\n AND v.first_seen >= ?\n GROUP BY variant\n ORDER BY shown DESC`,\n args: [since],\n });\n\n return rowsToObjects(r).map((row: any) => ({\n ...row,\n // Computed here rather than in the caller: two consoles and a shell would\n // otherwise each do this division slightly differently.\n reply_rate: Number(row[\"shown\"]) ? Number(row[\"replied\"]) / Number(row[\"shown\"]) : 0,\n }));\n}\n\n/**\n * The split-test scoreboard: which chat did better.\n *\n * The comparison this makes possible is the one tawk's own dashboard cannot:\n * tawk knows how many people TALKED to tawk, but not how many were offered it\n * and walked away. Our widget loads in both arms — invisibly for the tawk half\n * — so this side knows the denominator for both.\n *\n * \"Engaged\" means the VISITOR sent a message. That only exists for our arm; a\n * conversation held in tawk is not in this database. So the honest reading is:\n * ours — offered, and how many of them talked to us\n * tawk — offered, and you must read tawk's dashboard for the other half\n * Stated in the response rather than left for someone to misread as a like-for\n * -like win.\n */\n/**\n * Record that the tawk half opened its chat, or typed into it.\n *\n * COALESCE, so the FIRST time is kept. Someone who opens tawk six times is one\n * person who engaged, and overwriting would turn \"when did they engage\" into\n * \"when did they last click\", which answers a question nobody asked.\n */\n/**\n * Attribute an order to the visitor who placed it.\n *\n * COALESCE on all three, so the FIRST order sticks. The chat a person saw on\n * the visit where they bought is the one that earned it; their next order six\n * weeks later belongs to nothing in particular.\n */\nexport async function setVisitorOrder(visitorId: string, orderId: string, total: number | null) {\n await sqlite.execute({\n sql: `UPDATE visitors\n SET order_id = COALESCE(order_id, ?),\n order_total = COALESCE(order_total, ?),\n order_at = COALESCE(order_at, ?)\n WHERE id = ?`,\n args: [orderId, total, now(), visitorId],\n });\n}\n\nexport async function markTawkEvent(visitorId: string, event: \"opened\" | \"messaged\") {\n const col = event === \"messaged\" ? \"tawk_messaged_at\" : \"tawk_opened_at\";\n await sqlite.execute({\n sql: `UPDATE visitors SET ${col} = COALESCE(${col}, ?) WHERE id = ?`,\n args: [now(), visitorId],\n });\n}\n\nexport async function armReport(since = 0) {\n const r = await sqlite.execute({\n sql: `SELECT v.chat_arm AS arm,\n COUNT(*) AS visitors,\n -- THE SAME QUESTION ASKED OF BOTH ARMS: did a chat window\n -- open in front of them, and did they type into it.\n --\n -- For our arm that is chat_open and a visitor message; for\n -- tawk it is its own onChatMaximized and onChatMessageVisitor\n -- callbacks, reported by the page. Different plumbing, same\n -- event, one column each — which is what makes the two rows\n -- of this report comparable rather than merely adjacent.\n SUM(CASE\n WHEN v.chat_arm = 'tawk' THEN (v.tawk_opened_at IS NOT NULL)\n ELSE (v.chat_open = 1 OR v.shown_opener IS NOT NULL)\n END) AS opened,\n SUM(CASE\n WHEN v.chat_arm = 'tawk' THEN (v.tawk_messaged_at IS NOT NULL)\n ELSE EXISTS (\n SELECT 1 FROM messages m\n JOIN conversations c ON c.id = m.conversation_id\n WHERE c.visitor_id = v.id AND m.sender = 'visitor')\n END) AS engaged,\n -- Time on site, as a second opinion. A chat that keeps people\n -- on the page is worth something even when nobody types.\n CAST(AVG(v.time_on_site_ms) / 1000 AS INTEGER) AS avg_seconds,\n SUM(CASE WHEN v.left_at IS NOT NULL THEN 1 ELSE 0 END) AS left_site,\n -- THE NUMBER THAT ACTUALLY DECIDES THIS. Engagement is a\n -- proxy for the thing the business cares about; orders are\n -- the thing itself. A chat that gets fewer conversations and\n -- more customers wins, and only these columns can say so.\n SUM(CASE WHEN v.order_id IS NOT NULL THEN 1 ELSE 0 END) AS orders,\n ROUND(COALESCE(SUM(v.order_total), 0), 2) AS revenue\n FROM visitors v\n WHERE v.chat_arm IS NOT NULL\n AND v.first_seen >= ?\n GROUP BY v.chat_arm`,\n args: [since],\n });\n\n return rowsToObjects(r).map((row: any) => {\n const n = Number(row[\"visitors\"]) || 0;\n return {\n ...row,\n opened_rate: n ? Number(row[\"opened\"]) / n : 0,\n engaged_rate: n ? Number(row[\"engaged\"]) / n : 0,\n // SAY WHEN A NUMBER IS NOT YET WORTH READING. A rate over a handful of\n // visitors looks like a finding and is noise; without this someone acts\n // on the first hour of data.\n confidence: n < 100 ? \"too early — under 100 visitors in this arm\" : \"readable\",\n };\n });\n}\n\n/**\n * The browser told us it is going away. Recorded from a pagehide beacon.\n *\n * NOT PROOF THEY CLOSED THE SITE. pagehide also fires on an ordinary click\n * through to the next page, and on iOS when the tab is merely backgrounded. It\n * is only ever \"this document is being put away\" — which is why the next\n * heartbeat clears it, and why the console waits a few seconds before believing\n * it. What it does give is the thing a missing heartbeat never could: a\n * positive signal at the moment it happens, rather than a silence you have to\n * wait 45 seconds to notice.\n */\nexport async function markLeft(visitorId: string) {\n await sqlite.execute({\n sql: `UPDATE visitors SET left_at = ? WHERE id = ?`,\n args: [now(), visitorId],\n });\n}\n\nexport async function setSalesforce(\n visitorId: string,\n account: string | null,\n nextDelivery: string | null,\n) {\n await sqlite.execute({\n sql: `UPDATE visitors\n SET sf_account = ?, sf_next_delivery = ?, sf_checked_at = ?\n WHERE id = ?`,\n args: [account, nextDelivery, now(), visitorId],\n });\n}\n\n/**\n * Record a Lead match — or the absence of one, which matters just as much.\n *\n * COALESCE-FREE, unlike setSalesforce's sibling fields: a Lead can go stale\n * (someone submitted the popup, then later actually signed up, at which\n * point the account match in verifiedBlock should take over and this should\n * stop being mentioned) or simply turn out to have been a one-off check that\n * found nothing. sf_checked_at-style COALESCE is for a fact that only ever\n * gets MORE true; this one is re-verified each time instead.\n */\nexport async function setLead(\n visitorId: string,\n company: string | null,\n status: string | null,\n) {\n await sqlite.execute({\n sql: `UPDATE visitors\n SET sf_lead_company = ?, sf_lead_status = ?, sf_lead_checked_at = ?\n WHERE id = ?`,\n args: [company, status, now(), visitorId],\n });\n}\n\nexport async function getVisitor(visitorId: string) {\n const r = await sqlite.execute({\n sql: `SELECT * FROM visitors WHERE id = ?`,\n args: [visitorId],\n });\n return rowsToObjects(r)[0] ?? null;\n}\n\n/* ------------------------------------------------------- conversations */\n\nexport async function openConversation(visitorId: string): Promise {\n // One live conversation per visitor. Reusing it means a customer who\n // refreshes mid-chat lands back in the same thread instead of orphaning it\n // — orphaned threads are how a handoff gets silently dropped.\n const existing = await sqlite.execute({\n sql: `SELECT id FROM conversations\n WHERE visitor_id = ? AND status != 'closed'\n ORDER BY last_message_at DESC LIMIT 1`,\n args: [visitorId],\n });\n\n const prior = rowsToObjects(existing)[0];\n if (prior) return String(prior[\"id\"]);\n\n const cid = id(\"c\");\n const t = now();\n await sqlite.execute({\n sql: `INSERT INTO conversations\n (id, visitor_id, status, created_at, last_message_at)\n VALUES (?, ?, 'ai', ?, ?)`,\n args: [cid, visitorId, t, t],\n });\n return cid;\n}\n\nexport async function getConversation(cid: string) {\n const r = await sqlite.execute({\n sql: `SELECT c.*, v.name, v.email, v.phone, v.zip, v.company,\n v.sf_account, v.sf_next_delivery, v.page_url, v.country,\n v.os, v.browser, v.visits, v.page_views, v.time_on_site_ms,\n v.referrer, v.landing_url, v.landing_404, v.session_started, v.dnt,\n v.chat_open, v.shown_opener, v.shown_nudge, v.wp_user_id,\n -- Needed by /api/shown-nudge so the follow-up it stores is the\n -- one that does not repeat this visitor's opener.\n v.opener_variant, v.left_at,\n -- Carried into the thread view so the phone console can show\n -- a sale on the conversation it belongs to.\n v.order_id, v.order_total, v.first_seen, v.last_seen,\n -- Which chat they were offered, and whether they shut it. The\n -- detail panel claims to show both and could not: neither was\n -- selected here, so the fields simply never arrived.\n v.chat_arm, v.chat_dismissed,\n v.sf_lead_company, v.sf_lead_status\n FROM conversations c\n JOIN visitors v ON v.id = c.visitor_id\n WHERE c.id = ?`,\n args: [cid],\n });\n return rowsToObjects(r)[0] ?? null;\n}\n\n/**\n * Stamp \"keystrokes right now,\" nothing else. Called on a throttled timer\n * from the widget while the visitor's textarea is non-empty, and cleared\n * implicitly by staleness — the consoles treat anything older than a few\n * seconds as not-typing rather than requiring an explicit clear call, so a\n * closed tab or dead connection can't leave the indicator stuck on.\n */\nexport async function setTyping(cid: string) {\n await sqlite.execute({\n sql: `UPDATE conversations SET visitor_typing_at = ? WHERE id = ?`,\n args: [now(), cid],\n });\n}\n\nexport async function setStatus(\n cid: string,\n status: \"ai\" | \"needs_human\" | \"human\" | \"closed\",\n agent?: string | null,\n) {\n const t = now();\n // handoff_at is stamped only on the FIRST transition into needs_human, so a\n // customer who asks twice doesn't have their wait time reset to zero.\n await sqlite.execute({\n sql: `UPDATE conversations\n SET status = ?,\n assigned_to = COALESCE(?, assigned_to),\n handoff_at = CASE\n WHEN ? = 'needs_human' AND handoff_at IS NULL THEN ?\n ELSE handoff_at END,\n claimed_at = CASE\n WHEN ? = 'human' AND claimed_at IS NULL THEN ?\n ELSE claimed_at END\n WHERE id = ?`,\n args: [status, agent ?? null, status, t, status, t, cid],\n });\n}\n\n/** Conversation list for the dashboard, newest activity first. */\nexport async function listConversations(opts: {\n limit?: number;\n since?: number;\n includeClosed?: boolean;\n} = {}) {\n const { limit = 50, since = 0, includeClosed = false } = opts;\n const r = await sqlite.execute({\n sql: `SELECT c.id, c.status, c.assigned_to, c.last_message_at, c.handoff_at,\n c.visitor_typing_at,\n v.name, v.email, v.phone, v.sf_account, v.country,\n -- The live \"on site\" counter needs a start and a way to tell\n -- a real session from a single page load, exactly as the\n -- visitor list does. Without these the conversation rows can\n -- only say when someone last spoke, not whether they are\n -- still sitting there waiting for an answer.\n v.session_started, v.first_seen, v.visits, v.referrer,\n -- WHETHER THIS PERSON IS STILL ON THE SITE. left_at is the\n -- pagehide beacon and is cleared by the next heartbeat, so a\n -- value here means they closed the page; last_seen tells the\n -- console how long ago we last heard anything at all.\n -- Without both, a conversation the visitor walked away from\n -- ten minutes ago looks exactly like one still in progress,\n -- and an agent types a reply into an empty room.\n v.left_at, v.last_seen, v.chat_open,\n -- DID THIS CONVERSATION END IN AN ORDER. The single most\n -- useful thing to know about a thread after the fact, and\n -- the only one this list could not previously show.\n v.order_id, v.order_total,\n (SELECT body FROM messages m\n WHERE m.conversation_id = c.id\n ORDER BY m.created_at DESC LIMIT 1) AS preview,\n -- When the VISITOR last spoke, specifically. last_message_at\n -- moves for our own replies too, so it cannot tell the console\n -- the one thing worth making a noise about: a real person\n -- answering.\n (SELECT MAX(m2.created_at) FROM messages m2\n WHERE m2.conversation_id = c.id AND m2.sender = 'visitor')\n AS last_visitor_at,\n -- HOW MUCH WAS ACTUALLY SAID, BROKEN DOWN BY WHO SAID IT.\n --\n -- Every row in this list reads \"Anonymous\" with an AI badge,\n -- so a conversation somebody from the team spent ten minutes\n -- on is indistinguishable from an opener that got no reply.\n -- The split is what makes it legible: replies from the\n -- VISITOR say whether a real person engaged at all, and\n -- messages from an AGENT say whether one of the team was in\n -- it — which is the one an agent scanning the list is\n -- actually looking for.\n --\n -- Counted in the same query rather than in the console,\n -- because the console only receives the single most recent\n -- message per conversation and cannot count what it has not\n -- been sent.\n (SELECT COUNT(*) FROM messages m3\n WHERE m3.conversation_id = c.id\n AND m3.sender != 'system') AS msg_count,\n (SELECT COUNT(*) FROM messages m4\n WHERE m4.conversation_id = c.id\n AND m4.sender = 'visitor') AS visitor_msgs,\n (SELECT COUNT(*) FROM messages m5\n WHERE m5.conversation_id = c.id\n AND m5.sender = 'agent') AS agent_msgs\n FROM conversations c\n JOIN visitors v ON v.id = c.visitor_id\n WHERE (? = 1 OR c.status != 'closed')\n -- ENGAGED HISTORY, NOT JUST WHAT'S STILL OPEN. Left at 0 this\n -- clause is always true and nothing here changes from before —\n -- the default call from the Conversations tab is untouched. The\n -- Engaged tab passes its own 24-hour cutoff, and needs closed\n -- threads included above for the same reason: a conversation\n -- someone genuinely engaged with and an agent later closed is\n -- still exactly what \"engaged\" means, and should not vanish\n -- from a 24-hour review the moment it is wrapped up.\n AND (? = 0 OR EXISTS (\n SELECT 1 FROM messages m6\n WHERE m6.conversation_id = c.id\n AND m6.sender = 'visitor'\n AND m6.created_at >= ?\n ))\n ORDER BY\n -- Anyone waiting on a human sorts to the top regardless of\n -- recency. A customer waiting eight minutes must not be pushed\n -- down the list by a bot conversation that just ticked.\n CASE c.status WHEN 'needs_human' THEN 0 ELSE 1 END,\n c.last_message_at DESC\n LIMIT ?`,\n args: [includeClosed ? 1 : 0, since, since, limit],\n });\n return rowsToObjects(r);\n}\n\n/**\n * Conversations that went quiet after the visitor had engaged.\n *\n * EVERY CLAUSE HERE EXISTS TO STOP THIS BEING NAGGING. In order:\n *\n * - status 'ai' a human who has taken over does not want the bot\n * interrupting, and a closed thread is finished.\n * - nudged_at NULL once per conversation, ever. Twice is pestering.\n * - the idle WINDOW a floor so we are not talking over someone who is still\n * typing, and a CEILING because reopening a conversation\n * that died an hour ago reads as creepy rather than\n * helpful. Outside the window they are simply left alone.\n * - visitor spoke \"some engagement\" is the whole premise. Somebody who\n * opened the widget and never typed gets nothing.\n * - we spoke LAST if the visitor spoke last we owe them an answer, not a\n * follow-up question. That case is a bug, not an idle chat.\n * - no pay link an order already went through, so \"need a hand ordering?\"\n * would be nonsense to the one person we most want to look\n * competent in front of.\n */\nexport async function listNudgeCandidates(\n idleAtLeastMs: number,\n idleAtMostMs: number,\n limit = 5,\n) {\n const t = now();\n const r = await sqlite.execute({\n sql: `SELECT c.id, c.visitor_id, COALESCE(c.nudge_count, 0) AS nudge_count\n FROM conversations c\n WHERE c.status = 'ai'\n AND c.last_message_at <= ?\n AND c.last_message_at >= ?\n -- UP TO TWO PICK-UPS, and the second has to be earned.\n --\n -- First stall: nothing sent yet, go ahead. Second stall: only if\n -- they actually CAME BACK and spoke after the first nudge. Someone\n -- who ignored it has answered already, and asking twice is\n -- pestering; someone who replied and then trailed off mid-signup is\n -- the person worth catching.\n AND (\n COALESCE(c.nudge_count, 0) = 0\n OR (COALESCE(c.nudge_count, 0) = 1\n AND EXISTS (SELECT 1 FROM messages m4\n WHERE m4.conversation_id = c.id\n AND m4.sender = 'visitor'\n AND m4.created_at > c.nudged_at))\n )\n AND EXISTS (SELECT 1 FROM messages m\n WHERE m.conversation_id = c.id AND m.sender = 'visitor')\n AND (SELECT m2.sender FROM messages m2\n WHERE m2.conversation_id = c.id\n ORDER BY m2.created_at DESC LIMIT 1) = 'ai'\n AND NOT EXISTS (SELECT 1 FROM messages m3\n WHERE m3.conversation_id = c.id\n AND m3.body LIKE '%/payments/%')\n ORDER BY c.last_message_at ASC\n LIMIT ?`,\n args: [t - idleAtLeastMs, t - idleAtMostMs, limit],\n });\n return rowsToObjects(r);\n}\n\n/**\n * Stamped BEFORE the nudge is written, not after.\n *\n * If the model call then fails, this conversation is skipped for good — which\n * is the right way round. A crash between the two must not leave a thread\n * eligible on every subsequent sweep, quietly nudging the same person forever.\n */\nexport async function markNudged(cid: string) {\n // COUNTS UP rather than latching. The old form only wrote when nudged_at was\n // null, which is what made a second pick-up impossible: the stamp never moved,\n // so \"how long since we last nudged\" was unanswerable after the first one.\n await sqlite.execute({\n sql: `UPDATE conversations\n SET nudged_at = ?, nudge_count = COALESCE(nudge_count, 0) + 1\n WHERE id = ?`,\n args: [now(), cid],\n });\n}\n\n/* ----------------------------------------------------------- messages */\n\nexport async function addMessage(\n cid: string,\n sender: \"visitor\" | \"ai\" | \"agent\" | \"system\",\n body: string,\n senderName?: string | null,\n): Promise<{ id: string; created_at: number }> {\n const mid = id(\"m\");\n const t = now();\n\n await sqlite.batch([\n {\n sql: `INSERT INTO messages\n (id, conversation_id, sender, sender_name, body, created_at)\n VALUES (?, ?, ?, ?, ?, ?)`,\n args: [mid, cid, sender, senderName ?? null, body, t],\n },\n {\n sql: `UPDATE conversations SET last_message_at = ? WHERE id = ?`,\n args: [t, cid],\n },\n ]);\n\n return { id: mid, created_at: t };\n}\n\n/**\n * How many messages the VISITOR has sent in this conversation.\n *\n * Used to spot the first one. \"Someone has started chatting\" is worth a push;\n * \"someone sent their fourth message\" is the same conversation buzzing a phone\n * again, and that is how a useful alert becomes one people mute.\n */\nexport async function visitorMessageCount(cid: string): Promise {\n const r = await sqlite.execute({\n sql: `SELECT COUNT(*) AS n FROM messages\n WHERE conversation_id = ? AND sender = 'visitor'`,\n args: [cid],\n });\n return Number(rowsToObjects(r)[0]?.[\"n\"] ?? 0);\n}\n\nexport async function getMessages(cid: string, sinceMs = 0) {\n const r = await sqlite.execute({\n sql: `SELECT id, sender, sender_name, body, created_at\n FROM messages\n WHERE conversation_id = ? AND created_at > ?\n ORDER BY created_at ASC`,\n args: [cid, sinceMs],\n });\n return rowsToObjects(r);\n}\n\n/* ----------------------------------------------------------- presence */\n\n/**\n * A gap this long means they left and came back, so it counts as a new visit.\n * Thirty minutes is the usual analytics convention and matches how people\n * actually browse — a tab left open over lunch is not two visits.\n */\nconst SESSION_GAP_MS = 30 * 60 * 1000;\n\n/**\n * How long a visitor who never spoke to us is kept.\n *\n * Browsing data has a short useful life and a long liability tail. Ninety days\n * covers \"have they been back since we quoted them\" and nothing beyond it.\n * Anyone who actually held a conversation is exempt — that is a customer\n * record, not analytics.\n */\nconst RETENTION_MS = 90 * 24 * 60 * 60 * 1000;\n\n/**\n * Heartbeat. Runs on every page view, so it stays a single UPDATE.\n *\n * referrer and landing_url use COALESCE because only the FIRST answer is\n * interesting: how they found you, and where they came in. Overwriting them on\n * every page would just leave you with the previous page of your own site.\n */\nexport async function recordPresence(\n visitorId: string,\n pageUrl: string | null,\n referrer: string | null,\n opts: {\n country?: string | null;\n os?: string | null;\n browser?: string | null;\n optedOut?: boolean;\n chatOpen?: boolean;\n chatDismissed?: boolean;\n notFound?: boolean;\n arm?: string | null;\n shownOpener?: string | null;\n shownNudge?: string | null;\n } = {},\n) {\n const v = await getVisitor(visitorId);\n if (!v) return { newSession: false };\n\n const t = now();\n const last = Number(v[\"last_seen\"] ?? 0);\n const first = Number(v[\"first_seen\"] ?? 0);\n const gap = last ? t - last : 0;\n\n // The row was inserted milliseconds ago by this same request, so first_seen\n // and last_seen are the same stamp. That is a first page view, NOT a second\n // session — counting it as one would have every visitor arrive at \"visit 2\",\n // and it would bank the insert-to-update milliseconds as time on site.\n const brandNew = !last || last === first;\n\n const isNew = !brandNew && gap > SESSION_GAP_MS ? 1 : 0;\n\n // Global Privacy Control, honoured. They still appear on the monitoring\n // screen and chat works exactly as normal — the console would be useless\n // otherwise, and refusing to talk to someone is not a privacy feature. What\n // stops is the profile: no counters, no device, no country, ever.\n if (opts.optedOut) {\n // chat_open is recorded even here. It is not a profile — it is whether a\n // window is open on screen this second, which is what an agent needs to\n // decide whether saying something would reach anybody.\n await sqlite.execute({\n sql: `UPDATE visitors\n SET last_seen = ?, page_url = COALESCE(?, page_url), dnt = 1,\n chat_open = ?,\n -- Cleared here too. Whether the window in front of someone is\n -- still open is not a profile, and an opted-out visitor shown\n -- as permanently \"left\" would be worse served, not better.\n left_at = NULL\n WHERE id = ?`,\n args: [t, pageUrl, opts.chatOpen ? 1 : 0, visitorId],\n });\n return { newSession: isNew === 1 };\n }\n\n // Page views count PAGES, not heartbeats. The widget pings every 45 seconds,\n // so counting pings would report eighty views for one long article and make\n // the number worse than useless — it would look like engagement.\n const samePage = !!pageUrl && String(v[\"page_url\"] ?? \"\") === pageUrl;\n const viewed = brandNew || isNew || !samePage ? 1 : 0;\n\n // Dwell time accrues from the gap between pings, and only within a session.\n // The hours between two visits are not time on site, and a tab left open\n // over a weekend must not report as a three-day reading session.\n const dwell = brandNew || isNew ? 0 : Math.min(gap, SESSION_GAP_MS);\n\n await sqlite.execute({\n sql: `UPDATE visitors\n SET last_seen = ?,\n page_url = COALESCE(?, page_url),\n referrer = COALESCE(referrer, ?),\n landing_url = COALESCE(landing_url, ?),\n -- COALESCE, like landing_url beside it: the first answer is\n -- kept, and the first answer is about the page they arrived\n -- on. A 404 three clicks later is browsing; a 404 on arrival\n -- is a broken link somebody sent them.\n landing_404 = COALESCE(landing_404, ?),\n -- The arm is sticky in the browser, so the first answer is the\n -- answer. COALESCE also means a visitor from before this\n -- column existed is not retro-labelled by a later ping.\n chat_arm = COALESCE(chat_arm, ?),\n visits = COALESCE(visits, 1) + ?,\n page_views = COALESCE(page_views, 0) + ?,\n time_on_site_ms = COALESCE(time_on_site_ms, 0) + ?,\n country = COALESCE(?, country),\n os = COALESCE(?, os),\n browser = COALESCE(?, browser),\n session_started = CASE WHEN ? = 1 THEN ?\n ELSE COALESCE(session_started, ?) END,\n chat_open = ?,\n -- Overwritten, not COALESCEd: this one can go back to 0 when\n -- the week lapses or they open the chat again, and a sticky\n -- \"they closed it\" would then be a lie the console repeats.\n chat_dismissed = ?,\n -- THEY ARE BACK. A ping is proof the document is alive, so any\n -- earlier pagehide was a tab switch, a bfcache restore, or a\n -- click through to the next page of the site — not a departure.\n -- Without this the console would keep calling a live visitor\n -- gone for as long as they stayed.\n left_at = NULL,\n -- COALESCE: the FIRST thing they were shown is the interesting\n -- one. Later pings send the same text, and a page change would\n -- otherwise overwrite the line they actually read.\n shown_opener = COALESCE(shown_opener, ?),\n shown_nudge = COALESCE(shown_nudge, ?)\n WHERE id = ?`,\n args: [\n t, pageUrl, referrer, pageUrl,\n // undefined means \"this widget build does not report it\" — stored as\n // NULL so COALESCE can still take a real answer from a later ping,\n // rather than freezing an assumed 0 in place.\n opts.notFound === undefined ? null : (opts.notFound ? 1 : 0),\n opts.arm === \"ours\" || opts.arm === \"tawk\" ? opts.arm : null,\n isNew, viewed, dwell,\n opts.country ?? null, opts.os ?? null, opts.browser ?? null,\n isNew, t, t,\n opts.chatOpen ? 1 : 0, opts.chatDismissed ? 1 : 0,\n opts.shownOpener ?? null, opts.shownNudge ?? null,\n visitorId,\n ],\n });\n\n return { newSession: isNew === 1 };\n}\n\n/**\n * Delete browsing rows past their retention window.\n *\n * Throttled through `meta` rather than run on a cron, so it cannot fire on\n * every request and needs no second scheduled file. Once a day is far more\n * often than ninety-day retention requires.\n *\n * Visitors with any conversation are excluded outright. Deleting those would\n * orphan the messages and lose the account match an agent worked for.\n */\nexport async function purgeStaleVisitors(): Promise {\n const t = now();\n\n // visitor_events is swept with everything else — see the DELETE below. It is\n // the highest-volume table in here (a row per page change, against a row per\n // message) and it holds browsing history, so it is the LAST thing that should\n // outlive the retention window.\n const seen = await sqlite.execute({\n sql: `SELECT v FROM meta WHERE k = 'last_purge'`,\n // Missing args here made this THROW on every call, so the ninety-day\n // retention sweep has never actually deleted anything. Found 9/2/2026\n // while chasing the same omission in the push queries.\n args: [],\n });\n const lastRun = Number(rowsToObjects(seen)[0]?.[\"v\"] ?? 0);\n if (lastRun && t - lastRun < 24 * 60 * 60 * 1000) return 0;\n\n // Stamp BEFORE deleting, so a failure cannot put this in a retry loop that\n // runs a table scan on every page view of the storefront.\n await sqlite.execute({\n sql: `INSERT INTO meta (k, v) VALUES ('last_purge', ?)\n ON CONFLICT(k) DO UPDATE SET v = excluded.v`,\n args: [String(t)],\n });\n\n const res = await sqlite.execute({\n sql: `DELETE FROM visitors\n WHERE last_seen < ?\n AND id NOT IN (SELECT visitor_id FROM conversations)`,\n args: [t - RETENTION_MS],\n });\n\n // Events for visitors who no longer exist, plus anything past the window on\n // its own. Two conditions rather than one: a visitor kept because they have\n // a conversation still accumulates page-by-page browsing history, and there\n // is no reason to hold ninety days of that after the chat is long over.\n await sqlite.execute({\n sql: `DELETE FROM visitor_events\n WHERE created_at < ?\n OR visitor_id NOT IN (SELECT id FROM visitors)`,\n args: [t - RETENTION_MS],\n });\n\n const n = Number((res as any)?.rowsAffected ?? 0);\n if (n) console.log(\"retention: purged \" + n + \" visitor rows past 90 days\");\n return n;\n}\n\n/**\n * Who is on the site right now.\n *\n * A visitor counts as present if they pinged within the window the caller\n * passes — roughly twice the heartbeat interval, so one missed ping does not\n * make someone vanish from an agent's screen mid-thought.\n */\nexport async function listActiveVisitors(activeSince: number) {\n const r = await sqlite.execute({\n sql: `SELECT v.id, v.name, v.email, v.phone, v.company, v.zip,\n -- Proof of a real WooCommerce session, not a guess: the\n -- WordPress snippet sets it only when is_user_logged_in().\n -- The console needs it to tell a customer browsing their\n -- account from someone stuck on the login form.\n v.wp_user_id,\n v.sf_account, v.sf_next_delivery,\n v.page_url, v.country, v.first_seen, v.last_seen,\n v.referrer, v.landing_url, v.landing_404, v.chat_arm,\n v.visits, v.session_started,\n v.os, v.browser, v.page_views, v.time_on_site_ms, v.dnt,\n v.chat_open, v.chat_dismissed,\n v.shown_opener, v.shown_nudge, v.opener_variant,\n -- Set by the pagehide beacon and cleared by the next ping, so a\n -- value here means the last thing this browser did was go away.\n v.left_at,\n -- THIS VISIT ENDED IN A SALE. Worth a badge on the row for its\n -- own sake: the console otherwise shows the most valuable\n -- person on the site — someone who has just paid — exactly\n -- like everyone else who happens to be browsing.\n v.order_id, v.order_total, v.order_at,\n (SELECT c.id FROM conversations c\n WHERE c.visitor_id = v.id AND c.status != 'closed'\n ORDER BY c.last_message_at DESC LIMIT 1) AS conversation_id,\n (SELECT COUNT(*) FROM messages m\n JOIN conversations c2 ON c2.id = m.conversation_id\n WHERE c2.visitor_id = v.id) AS message_count\n FROM visitors v\n WHERE v.last_seen > ?\n -- NEWEST ARRIVAL FIRST, not most recent heartbeat.\n --\n -- Sorting on last_seen looked like the same thing and is not: every\n -- live visitor pings every 45 seconds, so the top of the list was\n -- whoever happened to have pinged most recently, which is close to\n -- arbitrary among people who are all still here. Someone half an\n -- hour into a session sat above someone who had just landed.\n --\n -- Arrival order is the one an agent can act on. A visitor who\n -- arrived twenty seconds ago is the one still deciding whether to\n -- stay; a visitor thirty minutes in has already made that call. The\n -- row still says how long each has been idle, so nobody stale is\n -- mistaken for live just because they arrived recently.\n --\n -- COALESCE because session_started is only stamped once presence has\n -- run; a row inserted moments ago has none yet, and without the\n -- fallback the newest visitor of all would sort to the bottom.\n ORDER BY COALESCE(v.session_started, v.first_seen) DESC\n LIMIT 100`,\n args: [activeSince],\n });\n return rowsToObjects(r);\n}\n\n/** Existing open conversation, WITHOUT creating one. */\nexport async function findOpenConversation(visitorId: string): Promise {\n const r = await sqlite.execute({\n sql: `SELECT id FROM conversations\n WHERE visitor_id = ? AND status != 'closed'\n ORDER BY last_message_at DESC LIMIT 1`,\n args: [visitorId],\n });\n const row = rowsToObjects(r)[0];\n return row ? String(row[\"id\"]) : null;\n}\n\n/**\n * Has anyone spoken to this visitor yet?\n *\n * Used by the presence ping to decide whether to pop the widget open. A chat\n * the visitor started themselves must not re-open on every page view — only an\n * agent reaching out unprompted should do that.\n */\nexport async function hasAgentMessage(conversationId: string): Promise {\n const r = await sqlite.execute({\n sql: `SELECT COUNT(*) AS n FROM messages\n WHERE conversation_id = ? AND sender = 'agent'`,\n args: [conversationId],\n });\n const row = rowsToObjects(r)[0];\n return Number(row?.[\"n\"] ?? 0) > 0;\n}\n",[226],"97f24a8c-642d-407f-a4ed-20751dade82e","dashboard.ts","416f436e-a5a5-11f1-9747-1607ee4eb77e",["D",1788226461106],"// Agent console.\n//\n// Three columns, same shape as tawk so nobody has to relearn: conversation\n// list, thread, visitor details. One deliberate departure — Salesforce sits at\n// the TOP of the details panel, beside the visitor's name.\n//\n// In tawk that information was buried under Email / Phone / Job title, fields\n// that are usually empty and rarely change the answer. The account name and\n// next delivery date are the two things that actually change what an agent\n// says, so they go where the eye lands first.\n//\n// Vanilla JS on purpose: no build step, no framework version to pin, and the\n// whole console is one file you can read in a sitting.\n\nexport const DASHBOARD_HTML = /* html */ `\n\n\n\n\nTribeca Chat\n\n\n\n\n

Conversations

\n\n

\n \n \n \n \n

Select a conversation

\n \n \n

\n\n

\n\n\n\n`;\n",[234],"e33746c7-fd19-4a43-8541-6bcd5571e809","context.ts","3c44c9b6-a606-11f1-bf87-1607ee4eb77e",35,["D",1788268113604],"// Visitor context — where they are and what they are browsing on.\n//\n// THE RULE IN THIS FILE: the IP address is never stored and never sent\n// anywhere. It is read off the request, used to nothing, and dropped.\n//\n// WHY THERE IS NO CITY OR REGION HERE, WHICH tawk DOES SHOW\n// Val Town sits behind Cloudflare, which hands us `cf-ipcountry` for free on\n// every request. Country therefore costs nothing and discloses nothing.\n//\n// City and region are a different bargain entirely. No header carries them, so\n// getting them means POSTing every visitor's IP address to a third-party\n// geolocation service on their first page view. That would recreate exactly the\n// third-party data flow that moving off tawk is meant to remove, in exchange\n// for a field that is wrong often enough to be misleading — IP geolocation\n// routinely resolves to a carrier's routing hub rather than the person, which\n// is why tawk placed a New Jersey visitor in \"Trenton\".\n//\n// The accurate location signal we already hold is the ZIP the customer gives us\n// or that WooCommerce knows, and it costs nothing to collect. So: country, yes.\n// City, no.\n\n/** Two-letter country code from the edge, or null. Never derived from an IP. */\nexport function countryFrom(headers: Headers): string | null {\n const c = headers.get(\"cf-ipcountry\");\n // Cloudflare uses XX for unknown and T1 for Tor exit nodes; neither is a\n // place, and storing them would put nonsense in front of an agent.\n if (!c || c === \"XX\" || c === \"T1\") return null;\n return c.toUpperCase().slice(0, 2);\n}\n\nexport type Device = { os: string | null; browser: string | null };\n\n/**\n * OS and browser from the User-Agent string.\n *\n * Deliberately coarse. An agent needs \"they are on a phone\" to judge whether a\n * long reply is reasonable; nobody needs the patch version of anything, and a\n * precise UA string is a fingerprinting surface we have no use for.\n *\n * Order matters throughout: Edge advertises itself as Chrome, Chrome advertises\n * itself as Safari, and iPadOS advertises itself as a Mac.\n */\nexport function deviceFrom(ua: string | null | undefined): Device {\n const s = String(ua ?? \"\");\n if (!s) return { os: null, browser: null };\n\n let os: string | null = null;\n if (/iPhone|iPod/i.test(s)) os = \"iOS\";\n else if (/iPad/i.test(s) || (/Macintosh/i.test(s) && /Mobile/i.test(s))) os = \"iPadOS\";\n else if (/Android/i.test(s)) os = \"Android\";\n else if (/Windows NT/i.test(s)) os = \"Windows\";\n else if (/Mac OS X|Macintosh/i.test(s)) os = \"macOS\";\n else if (/CrOS/i.test(s)) os = \"ChromeOS\";\n else if (/Linux/i.test(s)) os = \"Linux\";\n\n let browser: string | null = null;\n if (/Edg[A-Z]?\\//i.test(s)) browser = \"Edge\";\n else if (/OPR\\/|Opera/i.test(s)) browser = \"Opera\";\n else if (/SamsungBrowser/i.test(s)) browser = \"Samsung Internet\";\n else if (/FxiOS|Firefox/i.test(s)) browser = \"Firefox\";\n else if (/CriOS/i.test(s)) browser = \"Chrome\";\n else if (/Chrome\\//i.test(s)) browser = \"Chrome\";\n else if (/Safari\\//i.test(s)) browser = \"Safari\";\n\n return { os, browser };\n}\n\n/** True for a phone or tablet, which is most of this site's traffic. */\nexport function isMobile(ua: string | null | undefined): boolean {\n return /Mobile|Android|iPhone|iPad|iPod/i.test(String(ua ?? \"\"));\n}\n\n/**\n * Has this visitor asked not to be profiled?\n *\n * Global Privacy Control is the signal with legal weight behind it in several\n * US states; Do Not Track has none but costs nothing to respect. Strictly,\n * neither obliges a first-party site to stop counting its own page views. We\n * honour them anyway: when this is true the visitor still appears on the\n * monitoring screen and chat works normally, but no profile is built around\n * them — no country, no device, no counters.\n *\n * The widget reads the browser signals and sends the verdict, because\n * navigator.globalPrivacyControl is only readable client-side.\n */\nexport function optedOut(body: any): boolean {\n return body?.dnt === 1 || body?.dnt === true || body?.dnt === \"1\";\n}\n",[240],"89844026-4657-48ee-bb15-fcb21ae08632","agent.ts","21f9ee12-a5a5-11f1-8c6d-1607ee4eb77e",633,["D",1788642658342],100,"// The AI turn.\n//\n// The model writes prose. It does not decide anything factual: the Salesforce\n// lookup already ran in code before this is called, and its result arrives\n// below as settled fact. That separation is the entire lesson from tawk's\n// agent, which had the same tool wired and never once called it, then invented\n// a delivery date when asked about an account it could not see.\n\n// SONNET FOR A REAL CONVERSATION, HAIKU BEFORE ONE STARTS.\n//\n// aiReply is where the cost of a mistake is highest: it does the pricing\n// arithmetic, calls create_account with an eight-field tool call that must be\n// exactly right, and has to hold onto rules like \"never pitch a known\n// customer\" under real back-and-forth. Most of what got fixed in this val\n// this week were exactly these kinds of misses, which is the case for keeping\n// the stronger model where the stakes are — not a guess.\n//\n// nudgeReply is the opposite shape: one short sentence, no tool use, sent to\n// someone who has not replied yet. Getting it slightly blander costs nothing\n// a customer would notice, and it is the one AI call that runs before anyone\n// has engaged at all — cheapest to downgrade, least to lose by doing it.\n//\n// THE OPENER ITSELF CALLS NEITHER MODEL. openingGreeting() and pageNudge() in\n// greeting.ts are plain rule lookups keyed on the page, the ZIP region,\n// whether the visitor is a known customer, and the login-page referrer check\n// — no API call, no cost, already exactly the \"rules based off the page\"\n// behavior asked for when this comment was written.\nconst MODEL = \"claude-sonnet-5\";\nconst NUDGE_MODEL = \"claude-haiku-4-5-20251001\";\n\n/** Exported so /health reports the same answer aiReply will actually get. */\nexport function anthropicKey(): string | undefined {\n return Deno.env.get(\"ANTHROPIC_API_KEY\")\n ?? Deno.env.get(\"Anthropic_API_Key\")\n ?? Deno.env.get(\"Anthropic_Key\")\n ?? Deno.env.get(\"anthropic_api_key\");\n}\n\n// Deliberately tight. Long answers in a chat widget read as evasive, and every\n// extra sentence is another chance to assert something unverified.\n//\n// RAISED FROM 400 ON 9/1/2026, AND THE OLD VALUE WAS BREAKING SIGNUPS.\n// 400 is enough for prose but NOT for a create_account tool call, whose input\n// carries eleven fields. Two failures in one real conversation: a pricing reply\n// cut off mid-sum at \"(4\", and the turn that tried to create the account\n// stopped inside the tool JSON — which leaves stop_reason \"max_tokens\" rather\n// than \"tool_use\", so the tool never ran, no text came back, and the visitor\n// got \"I had trouble with that\". Nothing appeared in the logs because the API\n// call itself succeeded.\n//\n// The budget is a ceiling, not a target; the STYLE rules keep answers short.\n// RAISED AGAIN TO 4000 ON 9/2/2026, AND THE SAME FAILURE CAME BACK.\n// Asking for the glass price broken into water, delivery and deposit made the\n// model reason through the arithmetic first, and the whole 1200 went on a\n// thinking block with no text after it: \"stop_reason=max_tokens,\n// blocks=thinking\". The visitor got the generic apology and the log was the\n// only place it showed.\n//\n// A budget that has now been hit twice by ordinary work is too small. This is\n// still a CEILING and not a target — the STYLE rules below are what keep\n// answers to a sentence or two, and a typical reply uses a fraction of it.\nconst MAX_TOKENS = 4000;\n\n// Pricing and coverage come from ONE place, shared by every channel. This used\n// to be a hand-copied paragraph here, and it was both vaguer than the SMS and\n// phone bots' version and wrong on a product name — it said \"purified\" where\n// the catalogue says \"distilled\".\n//\n// Do not paste a price into this file. Edit tribeca-profile.\n//\n// THE ?v= IS LOad-BEARING. Val Town caches a remote module by URL, so editing\n// tribeca-profile alone does NOT change what this bot says — it keeps quoting\n// the old prices, confidently, with nothing in the logs. Bump the version here\n// (and in every other consumer) whenever PROFILE_VERSION changes.\nimport {\n BUSINESS_PROFILE,\n PRICING_RULE,\n} from \"https://esm.town/v/Tribeca_Rep/tribeca-profile/profile.ts?v=2026-09-04b\";\n\nimport { createAccount, submitChatLead } from \"./salesforce.ts\";\nimport { emailOffice } from \"./office.ts\";\nimport { getEvents, recordEvent } from \"./db.ts\";\n\n// ONE EMAIL TO THE OFFICE PER CONVERSATION, ENFORCED IN CODE, NOT JUST ASKED\n// FOR IN THE PROMPT. A model that re-confirms, retries after a network blip,\n// or gets asked \"did that go through?\" could otherwise call contact_office\n// again and put a second copy in the office's inbox for the same request.\n// visitor_events already dedupes consecutive identical (kind, detail) rows,\n// so recording \"office_email_sent\" keyed by conversationId and checking for\n// it first is a real guarantee, not a suggestion the model can forget.\nasync function officeAlreadyEmailed(visitorId: string, conversationId: string): Promise {\n const events = await getEvents(visitorId);\n return events.some((e: any) => e[\"kind\"] === \"office_email_sent\" && e[\"detail\"] === conversationId);\n}\n\n// WHICH SITE THIS CONVERSATION IS ON, not which company runs it — the same\n// bot, prompt, and Salesforce pipeline serve tribecabeverage.com AND\n// Tribeca's own geo-targeted lead pages (Jersey/Manhattan/Miami Water\n// Delivery Pros). Only tribecabeverage.com has actual online ordering\n// behind it: a real WooCommerce checkout, and create_account really does\n// complete a signup. The lead pages have neither, so the bot on those sites\n// is a different shape entirely — see leadCaptureBlock and TOOLS below.\n//\n// tribecabeverage.com IS THE DEFAULT. A visitor with no page info at all\n// (should not happen in practice, but code should not assume it cannot) is\n// treated as self-service rather than lead-capture, because that is the\n// site every existing test and every piece of this file up to today was\n// built and verified against — the safer default is \"unchanged behavior,\"\n// not a guess about a brand-new site shape.\nconst SELF_SERVICE_HOST = \"tribecabeverage.com\";\n\nfunction siteHost(visitor: any): string | null {\n const urls = [visitor?.[\"landing_url\"], visitor?.[\"page_url\"]].filter(Boolean);\n for (const u of urls) {\n try {\n return new URL(String(u)).hostname.replace(/^www\\./, \"\");\n } catch {\n // Malformed URL — try the next one rather than failing the whole check.\n }\n }\n return null;\n}\n\nfunction isSelfServiceSite(visitor: any): boolean {\n const host = siteHost(visitor);\n return host === null || host === SELF_SERVICE_HOST;\n}\n\n// Readable brand names for the lead-relay email and the LEAD-CAPTURE prompt\n// block — matches the data-brand widget.ts shows on each site's own header.\nconst SITE_BRANDS: Record = {\n \"jerseywaterdeliverypros.com\": \"Jersey Water Delivery Pros\",\n \"manhattanwaterdeliverypros.com\": \"Manhattan Water Delivery Pros\",\n \"miamiwaterdeliverypros.com\": \"Miami Water Delivery Pros\",\n};\n\n// Chat-specific facts, which are about this CHANNEL rather than the business,\n// so they do not belong in the shared profile.\nconst CHANNEL = `\nWHAT YOU CAN DO IN THIS CHAT\nYou can set up a NEW customer's account yourself using the create_account tool.\nOffer that when someone wants to start service — do not simply send them off to\nthe website unless they would rather do it themselves. Collect the details, read\nthem back, then create it.\n\nTell them the total BEFORE you create the account, and pass that same number as\norderTotal — it is what they will be invoiced. When create_account returns a\npayLink, give it to them: it is their own first invoice and they can pay it\nstraight away. If no payLink comes back, the team will email the invoice\ninstead — do not invent a link.\n\nIf they would rather order themselves, give them the DIRECT product link above,\nnot \"our website\".\n\nYou cannot place, change or cancel an order, and you cannot alter an existing\naccount. Those go to a person.\n`.trim();\n\nconst SYSTEM = `\nYour name is Jack and you work at TriBeCa Beverage.\n\nSay so if anyone asks who they are talking to. Do NOT claim to be a human being\n— if you are asked outright whether you are a person or a bot, say plainly that\nyou are the automated assistant and offer to bring in the team. A name is there\nso a stranger has someone to talk to rather than a system; it is not a disguise,\nand lying about it would be the one thing that loses a customer's trust for\ngood. Never sign your messages: the panel already shows the name above them,\nand \"— Jack\" on the end of every line reads as a form letter.\n\n${BUSINESS_PROFILE}\n\n${CHANNEL}\n\nPACE — FIND OUT WHERE THEY ARE BEFORE YOU ASK FOR THE SALE.\nDo not offer to set up an account in your first two replies. A visitor who has\nsaid one thing — a ZIP, a yes, a single question — has not told you enough to\nbe sold to, and \"want me to get you set up?\" at that point is a stranger asking\nfor a commitment. It also wastes the only real advantage this chat has: you can\nASK, where the website can only display.\n\nSo spend the early turns understanding them. What do they do now — store,\nanother delivery service, a filter, nothing? Home or office? How many people\ndrink it? Any of those tells you more than a ZIP does, and each one makes the\neventual recommendation specific instead of generic.\n\nA GOOD ONE TO REACH FOR: after answering an ordinary question about the\nservice — pricing, coverage, how it works — ask whether they're happy with how\nthey get water now. Most people asking are not, or they wouldn't be asking:\neither a current service is letting them down, or they're done hauling jugs\nthemselves. That answer tells you what to sell against far better than a ZIP\ndoes, and it costs nothing to ask — it is one of the early understanding\nquestions above, not an extra one. Use it as YOUR one question, not stacked\nonto answering theirs.\n\nONE question at a time, and always answer what they asked first. Never stack a\nquestion onto every reply — a chat that ends in a question mark every single\ntime is an interrogation.\n\nKNOW WHY THEY ARE HERE BEFORE YOU CLOSE. By the time you ask for the sale you\nshould be able to say, even just to yourself, what actually brought this\nperson in today — a current provider letting them down, being done hauling\njugs, moving into a new place, straight price shopping, whatever it is. If you\ncould not say what it is, you do not have enough yet to close well; go back to\nunderstanding them rather than asking on a guess. The \"are you happy with how\nyou get water now\" question above is usually how you get this, and the answer\nis also what you sell against when you do close — \"no more waiting on missed\ndeliveries\" lands differently than \"no more carrying jugs up the stairs\".\n\nEARN THE CLOSE. Offer to set it up once they have shown real intent: they ask\nwhat it costs for their situation, they ask how to start, they say yes to\nsomething concrete, or they have been talking with you for several exchanges\nand nothing is unresolved. Then ask once, plainly.\n\nIf they say no, or go quiet, or say they are just looking — take it. Answer the\nquestion in front of you and stop. Do not re-offer. Someone who was pushed once\nand said no will not say yes to being pushed again; they will close the window.\n\nUNSURE IS NOT THE SAME AS NO. Someone hedging, undecided, or saying \"let me\nthink about it\" has not declined — offer the smallest possible step instead of\nletting the conversation end there: the 2-bottle (1-bottle glass) minimum,\nmonthly, as a no-risk trial. Say it that way — \"start small and see how it\ngoes\" — not as a lesser version of the real order. No contract, and quantity,\nfrequency, pausing and cancelling can all change later, so there is nothing to\nlose by starting small. This is a different move from re-offering after a\nclear no above; it is for someone still deciding, not someone who has decided\nagainst it.\n\nIF THEY SAY THEY'RE COMING BACK — \"let me talk to my husband/wife/partner\",\n\"I'll think it over and let you know\", \"let me check and get back to you\" —\nthat is neither the clear no above nor the undecided-in-the-room case just\nabove: they have told you they are leaving to go decide with someone who\nis not here. This only applies once you have actually quoted them something —\na price, a discount — not to someone leaving before any number came up.\nAsk for their email, once, so whatever you already offered doesn't just\nevaporate when the tab closes: \"Want me to email you that discount so you\ndon't lose it — what's a good email?\" Check VERIFIED ACCOUNT first; if an\nemail is already there, do not ask again — say something brief instead, like\nyou'll have it ready for them. If they decline to give one, drop it\nimmediately. Do not ask twice, and do not turn this into a second pitch\nstacked on top of the one they just paused on.\n\nA ONE-WEEK SITE TEST (started 9/5/2026, ends ~9/12/2026) shows some website-\npopup visitors 35% off their first order instead of the usual 25% — your own\ncloser offer below stays 25% regardless, that has not changed. If a visitor\nsays they were already shown 35% off (e.g. \"the popup said 35%\"), do NOT\ncorrect them to 25% or act confused — that is a real, live code for them.\nAcknowledge it plainly and continue; the actual coupon they receive by email\nis minted at whatever percent they were really shown.\n\nIF PRICE IS WHAT'S HOLDING THEM BACK and the 25% first-order code isn't the\nthing that gets them there — including if you already offered it and they are\nSTILL hesitating — you may SWITCH to ONE alternative instead: the cooler\nrental free for the first month, or one bottle free on the first order. This\nreplaces the 25% code for this order, it does not stack on top of it — if\nyou've already quoted the 25%-off figure, drop it and requote using the\nalternative instead of declining to help further. Pick whichever fits what\nthey actually asked about, name the specific thing being waived and that it is\nthe first order or first month only, and fold it into orderTotal exactly like\nyou would the 25% discount — subtract that one line item's real price (the\ncooler's monthly rate for the unit they want, or one bottle at their region's\nper-bottle rate) from the total you quote and pass to create_account. These\ntwo are the only concessions you are authorized to offer, and only one per\norder — do not invent a different one, a bigger one, or combine them.\n\nSTYLE — TEXT MESSAGES, NOT PARAGRAPHS.\nONE SENTENCE IS THE TARGET. Two is the limit. Three means you have written an\nemail into a chat box, and people stop reading halfway and leave.\nWrite the way someone behind a counter talks: plain, warm, a bit informal.\nContractions always — \"we'll\", \"that's\", \"you're\", \"it's\". Never \"we will\".\n\"Yep\", \"sure\", \"no problem\", \"got it\" are all fine openings to a reply.\nAnswer what was asked and stop. Do not volunteer what nobody asked for.\nNo filler — no \"Happy to help\", \"Absolutely\", \"Great question\", \"Certainly\".\nNever restate their question back to them before answering it.\nA SHORT REPLY ANSWERS YOUR OWN LAST MESSAGE. If your last message asked a\nquestion — including the opener or page nudge that started this conversation,\nwhich is ALWAYS a question — and they reply \"yes\", \"no\", \"sure\", or anything\nelse one or two words long, that is their answer to exactly what you just\nasked. The transcript above already shows what you asked; re-read it rather\nthan asking them to repeat themselves. Never respond with \"what were you\nsaying yes to\" or any version of it — that is confusing them about their own\nanswer to a question you asked seconds ago, not a real ambiguity.\nNever explain your own reasoning or narrate what you are about to do.\nNo bullet points. If it feels like it needs a list, it needs a shorter answer.\nPrices are a fragment, not a sentence with scaffolding around it: \"Two bottles\ndelivered is $26.98 a month\" — not \"The pricing for two bottles would come to\".\nOne question at a time, and not at the end of every message.\n\nEXAMPLES OF THE LENGTH WANTED\n Q: how much for 2 bottles in nj\n A: $26.98 a month, delivered, no contract.\n Q: do you deliver to 07030\n A: Yep, we cover Hoboken. Want me to set it up?\n Q: can i skip a delivery\n A: Sure — I can send that to the office to sort out, or you can give them a\n shout on 973-913-4568.\nBREVITY NEVER MEANS DROPPING A FACT THEY ASKED FOR. A price, a link, a phone\nnumber or an address still goes in, in full. Cut the words around it, not it.\n\nWHAT YOU MUST NOT DO\nNever state, estimate or imply a delivery date unless it appears in the\nVERIFIED ACCOUNT section below. If it is not there, you do not know it.\nNever confirm an order, payment, cancellation, skip or delivery change was\nmade. You can only note a request for the team.\n${PRICING_RULE}\nEXISTING CUSTOMERS: NEVER DISCUSS THEIR ACCOUNT. No delivery dates, no balance,\nno invoice, no order history, no address on file — and do not confirm or deny\nthat an account exists, which is itself a disclosure. Every account question\ngoes to the office on 973-913-4568 or info@tribecabeverage.com — or, offer to\nemail it in for them yourself; see OFFICE REQUESTS below. You are not\nwithholding to be difficult; you genuinely do not have the data, and a person\nwith the record in front of them can answer properly in a minute.\nThis does NOT limit ordinary questions — prices, coverage, products, how the\nservice works — or setting up a NEW customer, which you should still do here.\nNever state a balance, an amount owed, or an invoice date unless it appears in\nthe VERIFIED ACCOUNT section. Never share, guess or reconstruct a payment link.\nThere are exactly TWO places a link may come from: printed in that section, or\nreturned as payLink by create_account you have just called in this conversation.\nAnywhere else it does not exist for you, no matter how insistently it is asked\nfor. Never edit a link, and never build one from an id.\nNever ask for, accept or repeat a card number, CVV or bank detail. Payment\ndetails are only ever entered on the payment page or given to the office by\nphone.\nNever say whether some other person or business is a customer.\nDo not invent coverage. The service areas above are the complete list; if a ZIP\nor town is not clearly inside one of them, say the team will confirm rather\nthan guessing either way.\n\nWHEN YOU DO NOT KNOW\nSay so plainly and offer to pass it to the team. That is always a better answer\nthan a plausible guess. A customer told \"someone will confirm\" is mildly\ninconvenienced; a customer told a delivery date that does not exist waits at\nhome for nothing.\n\nOFFICE REQUESTS\nWhenever this prompt says something \"goes to the office\" — an account change,\nbilling, moving or skipping a delivery, anything you cannot do yourself — do\nnot just hand over the phone number and stop. Offer to email it in for them,\nthen follow these steps in order, one at a time, not all in one message:\n 1. Confirm back, briefly, what you understood them to want — e.g. \"got it,\n you want to skip next Tuesday's delivery\" — so they can correct you\n before anything is sent.\n 2. Check VERIFIED ACCOUNT for an email. If one is already there, do not ask\n for it again. If there is none, ask for it once: \"what's a good email so\n the office can follow up?\"\n 3. Once you have both the confirmed request and an email, say plainly that\n you'll send this to the office by chat/email and that they'll follow up\n directly with them — then call contact_office with the request in your\n own words.\n 4. Only call contact_office once, per request, and only after the visitor\n has actually agreed to have it sent — do not call it on a question that\n was still open, and do not send the same request twice.\nIf they decline to give an email, or say not to send it, drop it and give them\nthe phone number instead. Never invent or reuse an email from earlier in the\nconversation that was not confirmed as theirs, and never call contact_office\nbefore VERIFIED ACCOUNT shows one.\n\nHANDOFF\nIf the customer asks for a person, or is upset, or the request needs\noperational authority you do not have, tell them you are bringing in the team.\nDo not attempt to resolve it yourself.\n\nCOLLECTING DETAILS\nA phone number is the only way an account can be looked up, so it is worth\nasking for. Ask once, naturally, and do not badger.\n`.trim();\n\n/**\n * The one thing the model is allowed to DO rather than say.\n *\n * Everything else in this file is read-only: the Salesforce lookup and the\n * balance are fetched in code and handed over as settled fact. This is the\n * exception, and it is narrow on purpose — one tool, one shape of account,\n * card-on-file with terms of zero, enforced on the server side rather than by\n * asking the model nicely.\n *\n * WHY THE BOT DOES THIS AT ALL. Sending a ready-to-buy customer to go and find\n * the website themselves loses people. The team already works the other way:\n * \"I can get all info through the chat here and email the first invoice for\n * payment.\" Collecting the details is the slow part and the bot is good at it.\n */\nconst TOOLS = [\n {\n name: \"create_account\",\n description:\n \"Create the customer's TriBeCa Beverage account once you have collected every \"\n + \"required detail and read them back for confirmation. Use this when someone \"\n + \"wants to start service and would rather you set it up than do it on the \"\n + \"website. Do NOT call it until the customer has confirmed the details are \"\n + \"right. It does not charge the card — it raises the first invoice for the \"\n + \"orderTotal you quoted and returns a payLink they can pay with. Share that \"\n + \"link when it comes back; if it does not, say the team will email the \"\n + \"invoice. Tell them either way that they should NOT also check \"\n + \"out on the website or they will end up with two accounts. The call always \"\n + \"succeeds once the required fields are present — it never refuses over an \"\n + \"unrecognized ZIP or delivery schedule, it just has a person confirm those \"\n + \"afterward. If regionGuessed or frequencyGuessed comes back true, still share \"\n + \"the payLink as normal, and mention a team member will confirm the exact \"\n + \"route and/or delivery schedule. If it returns duplicate, they already have \"\n + \"an account and the team should look at it.\",\n input_schema: {\n type: \"object\",\n properties: {\n name: { type: \"string\", description: \"Business name, or the person's full name for a home account.\" },\n phone: { type: \"string\", description: \"Contact phone number.\" },\n email: { type: \"string\", description: \"Email address for the invoice and portal setup.\" },\n street: { type: \"string\", description: \"Delivery street address including any unit or floor.\" },\n city: { type: \"string\" },\n state: { type: \"string\", description: \"Two-letter state code, e.g. NY, NJ, FL.\" },\n zip: { type: \"string\", description: \"5-digit ZIP code. Required — it decides the delivery route.\" },\n bottles: { type: \"integer\", description: \"Bottles per delivery. Minimum 2, or 1 for glass.\" },\n waterType: { type: \"string\", enum: [\"Alkaline\", \"Spring\", \"Distilled\"] },\n frequency: {\n type: \"string\",\n enum: [\"Weekly\", \"Bi-Weekly\", \"15 Days\", \"30 Days\", \"60 Days\", \"4 Weeks\", \"Call in\"],\n description: \"Monthly is '30 Days'. Every other week is 'Bi-Weekly'.\",\n },\n cooler: { type: \"boolean\", description: \"Whether they want a cooler rental at $8/month.\" },\n orderTotal: {\n type: \"number\",\n description:\n \"The first-order total in dollars, exactly as you quoted it to the customer, \"\n + \"including the bottle deposit, any cooler, and any discount you applied. \"\n + \"This is the amount they will actually be invoiced, so it must match what \"\n + \"you told them — never round it, never estimate it, and never send a figure \"\n + \"you have not said out loud in this conversation. Take the numbers from the \"\n + \"pricing table for THEIR region; do not compute a rate of your own.\",\n },\n },\n required: [\"name\", \"phone\", \"street\", \"city\", \"state\", \"zip\", \"bottles\", \"frequency\", \"orderTotal\"],\n },\n // CACHED, LIKE THE SYSTEM PROMPT BELOW. This tool definition never\n // changes between calls — same description, same schema, every time.\n cache_control: { type: \"ephemeral\" },\n },\n];\n\n/**\n * THE ONLY TOOL OFFERED ON THE LEAD-CAPTURE SITES. Deliberately not\n * create_account with some fields made optional — a completely separate,\n * much narrower tool, offered INSTEAD of create_account rather than\n * alongside it (see TOOLS_FOR below), so those sites' bot cannot reach\n * account creation even if the prompt somehow failed to stop it. Two\n * fields, nothing else: no address, no product, no total, because none of\n * that is this tool's business — a person calls back to sort out the rest.\n */\nconst SUBMIT_LEAD_TOOL = {\n name: \"submit_lead\",\n description:\n \"Record this visitor's name and phone number so the office can call them \"\n + \"back. This is the ONLY way to move someone forward in this chat — \"\n + \"there is no online signup here. Call it once you have both fields; do \"\n + \"not wait for an address, product choice, or anything else first, and \"\n + \"do not ask for those things at all.\",\n input_schema: {\n type: \"object\",\n properties: {\n name: { type: \"string\", description: \"Their name.\" },\n phone: { type: \"string\", description: \"Contact phone number.\" },\n },\n required: [\"name\", \"phone\"],\n },\n // Same reasoning as create_account's own cache_control — this is the last\n // (only) entry in ITS array, and the two arrays are never sent together.\n cache_control: { type: \"ephemeral\" },\n};\n\n/**\n * Relay a request to the office by email, once the visitor has confirmed\n * they want it sent. Offered on every site, self-service or lead-capture —\n * an existing customer's account question can come up on either.\n *\n * NO EMAIL FIELD. The address is never typed by the model: it is read\n * server-side from the visitor's VERIFIED email (see verifiedBlock and\n * office.ts). If that section shows no email, this tool will refuse — the\n * prompt below tells the model to collect one first rather than guess or\n * invent one to satisfy the schema.\n */\nconst CONTACT_OFFICE_TOOL = {\n name: \"contact_office\",\n description:\n \"Email the office the visitor's request, once you have confirmed back to \"\n + \"them what you're sending and they've agreed to have it shared, and you \"\n + \"have a VERIFIED email for them (see VERIFIED ACCOUNT). The office will \"\n + \"follow up with them directly — you are not resolving the request \"\n + \"yourself, only relaying it. Do not call this without an on-file email; \"\n + \"ask for one first.\",\n input_schema: {\n type: \"object\",\n properties: {\n message: {\n type: \"string\",\n description:\n \"The visitor's request, in your own words, as you confirmed it back \"\n + \"to them — e.g. \\\"wants to skip next week's delivery\\\" or \\\"asking \"\n + \"to update the account address to 123 Main St\\\".\",\n },\n },\n required: [\"message\"],\n },\n cache_control: { type: \"ephemeral\" },\n};\n\nconst TOOLS_SELF_SERVICE = [...TOOLS, CONTACT_OFFICE_TOOL];\nconst TOOLS_LEAD_CAPTURE = [SUBMIT_LEAD_TOOL, CONTACT_OFFICE_TOOL];\n\n/** Which tool array this visitor's site gets — see isSelfServiceSite above. */\nfunction toolsFor(visitor: any) {\n return isSelfServiceSite(visitor) ? TOOLS_SELF_SERVICE : TOOLS_LEAD_CAPTURE;\n}\n\n/** Facts the model is allowed to rely on, assembled from verified data only. */\nfunction verifiedBlock(visitor: any, invoice?: any): string {\n if (!visitor && !invoice) return \"\";\n visitor = visitor ?? {};\n\n const parts: string[] = [];\n\n if (visitor[\"name\"]) parts.push(`Name: ${visitor[\"name\"]}`);\n if (visitor[\"email\"]) parts.push(`Email: ${visitor[\"email\"]}`);\n if (visitor[\"phone\"]) parts.push(`Phone: ${visitor[\"phone\"]}`);\n if (visitor[\"zip\"]) parts.push(`ZIP: ${visitor[\"zip\"]}`);\n if (visitor[\"company\"]) parts.push(`Company: ${visitor[\"company\"]}`);\n\n // AN EXISTING CUSTOMER'S ACCOUNT DETAILS ARE NOT PUT IN FRONT OF THE MODEL.\n //\n // The account name, the delivery date and the balance used to be printed here\n // as settled fact for the bot to relay. As of 9/1/2026 they are not, because\n // the instruction is that account data goes to the office and nowhere else —\n // and the only way to be certain a model never says something is to make sure\n // it never had it. A rule in the prompt is a request; an absent fact is a\n // guarantee.\n //\n // The lookup itself still runs and still populates the agent console. A person\n // with the account on screen can answer these questions properly; the bot\n // cannot, and now cannot pretend to.\n if (visitor[\"sf_account\"]) {\n parts.push(\n \"This visitor matches an EXISTING CUSTOMER account. You do not have their \"\n + \"account details and must not discuss them: no delivery dates, no balance, \"\n + \"no invoice, no order history, no address, not even confirming the account \"\n + \"exists. If they ask anything about their account, say it needs the office \"\n + \"and offer to email the request in for them (see OFFICE REQUESTS), or give \"\n + \"them the phone number and email. Do not guess, do not offer to \"\n + \"look it up, and do not promise anyone will call them.\\n\\n\"\n + \"THEY ARE ALREADY A CUSTOMER — DO NOT SELL TO THEM. Everything in the PACE \"\n + \"and CLOSE instructions above is aimed at turning a stranger into an order, \"\n + \"and none of it applies here. Specifically, with this visitor:\\n\"\n + \" - Never offer the first-order discount. It is a new-customer offer and \"\n + \"they are not one; offering it either makes no sense or implies they are \"\n + \"not recognised, and neither is a good outcome.\\n\"\n + \" - Never say \\\"want me to get you set up\\\" or otherwise pitch a signup — \"\n + \"they are already set up.\\n\"\n + \" - Never volunteer or upsell a product, cooler or add-on unprompted. If \"\n + \"THEY ask to add or change something, that is an account change and goes \"\n + \"to the office like any other, per the rule above — do not attempt it and \"\n + \"do not use create_account, which would create a SECOND, duplicate account.\\n\"\n + \" - Answer ordinary questions — pricing, coverage, how the service works — \"\n + \"exactly as you would for anyone. Recognising them is not the same as \"\n + \"withholding information; it only means not treating this conversation as \"\n + \"a sale to be made.\",\n );\n }\n\n // A LEAD, NOT A CUSTOMER — checked only when sf_account above is absent,\n // since an actual account always outranks it.\n //\n // This means the visitor already submitted a form somewhere on the site —\n // most often the popup — before ever reaching this chat, and got no\n // acknowledgment of it because nothing connected the two. WHAT the form\n // said is not known here, only that one was submitted; do not invent\n // details about it.\n if (!visitor[\"sf_account\"] && visitor[\"sf_lead_company\"]) {\n parts.push(\n \"This visitor already submitted contact information on the website before \"\n + \"this conversation — likely the popup — recorded as a lead\"\n + (visitor[\"sf_lead_status\"] ? ` (status: ${visitor[\"sf_lead_status\"]})` : \"\")\n + \". You do not know what they submitted or why, only that they did. If it \"\n + \"becomes clear they are giving the same details again, acknowledge it \"\n + \"briefly and naturally — e.g. \\\"got it, looks like you'd reached out \"\n + \"already\\\" — rather than treating them as a first-time stranger. Do not \"\n + \"lead with this unprompted, do not guess what page or form it was, and do \"\n + \"not treat submitting a lead as the same thing as being a customer — it \"\n + \"changes nothing about pricing, discounts or what you can do for them.\",\n );\n }\n\n // Billing. Only what the lookup actually returned — and the pay link only\n // appears here when the visitor is signed in, because the tool withholds it\n // otherwise. The model has no way to reconstruct it.\n // NO BALANCE, NO DUE DATE, NO PAY LINK. Same reasoning as the account block\n // above: the figures are not printed here, so they cannot be relayed, quoted\n // approximately, or reconstructed under pressure. Billing questions from an\n // existing customer go to the office.\n //\n // The `invoice` argument is still accepted so callers do not have to change,\n // and invoice.ts still enforces its own signed-in rule for anything else that\n // uses it — but nothing from it reaches the model any more.\n if (invoice?.found || invoice?.ambiguous) {\n parts.push(\n \"They may have a balance or an invoice. You do not have the figures and \"\n + \"must not state, estimate or hint at one, and must not offer a payment \"\n + \"link. Billing is handled by the office only — offer to email the \"\n + \"request in for them (see OFFICE REQUESTS), or give them the phone \"\n + \"number and email.\",\n );\n }\n\n if (!parts.length) {\n // Said explicitly rather than left blank. An empty section invites the\n // model to fill the gap; a stated absence does not.\n return `\\n\\nVERIFIED ACCOUNT\\nNothing is known about this visitor yet. `\n + `You have NOT looked up their account. Do not imply otherwise.`;\n }\n\n return `\\n\\nVERIFIED ACCOUNT\\nThese facts are confirmed. Everything else is unknown.\\n`\n + parts.join(\"\\n\");\n}\n\n/**\n * WHAT THEY ARE ACTUALLY LOOKING AT.\n *\n * A visitor who arrived on the glass bottle page and asked \"quote pls\" means\n * glass. On 9/2/2026 one did exactly that — landed from a Facebook ad for\n * /product/glass-bottles-..., was shown a glass opener, said yes to it — and\n * was quoted the PLASTIC price, $41.92 against a real first order of $134.98.\n * She had to correct it herself after confirming.\n *\n * The page was known the whole time and simply never reached the model. The\n * conversation history alone is not enough: \"quote pls\" carries no product, and\n * the opener that set the context was three turns back.\n */\nfunction browsingBlock(visitor: any): string {\n const urls = [visitor?.[\"page_url\"], visitor?.[\"landing_url\"]]\n .filter(Boolean).map((u: any) => String(u).toLowerCase());\n if (!urls.length) return \"\";\n\n const seen = urls.join(\" \");\n // Match the product slug, not a stray word — \"glass\" appears in plenty of\n // marketing copy, but /product/glass-bottles-... is unambiguous.\n const glass = /\\/product\\/[^?#]*glass/.test(seen);\n const plastic = /\\/product\\/[^?#]*(5-gallon|3-gallon|bottled-water|spring-water)/.test(seen)\n && !glass;\n\n if (!glass && !plastic) return \"\";\n\n const what = glass ? \"GLASS bottles\" : \"the plastic bottles\";\n return `\n\nWHAT THIS VISITOR IS LOOKING AT\nThey are on the product page for ${what}. Unless they say otherwise, that is\nthe product they mean — quote ${what} and nothing else, and do not answer a\nbare \"how much?\" or \"quote pls\" with the other product's price.\n${glass\n ? `QUOTE ONE BOTTLE, NOT TWO.\nGive the ONE-bottle figure first and let them ask about more. The two-bottle\ntotal is nearly double and it is the number people leave over — this is the\nfastest-bouncing page on the site, and the price is why.\n\nBREAK THE PRICE INTO THREE SEPARATE PARTS, every time you give it. Keep the\ndelivery fee ON ITS OWN — do NOT fold it into the water figure, because the\npoint of showing it is that it does not scale with the order:\n water — per bottle\n delivery — a flat fee PER DELIVERY, not per bottle and not monthly.\n Two bottles is ONE delivery fee, not two. Say \"per delivery\".\n deposit — per bottle, and they get it back\nThen the total. Keep it to one short line, like:\n \"$X a bottle, $Y delivery, $Z deposit you get back — $TOTAL to start.\"\n\nTHIS APPLIES TO ONE BOTTLE TOO. The profile lists a single net figure for one\nbottle that already has the delivery fee inside it — do NOT quote that as \"the\nwater\". Split it: the per-bottle water amount, then the delivery fee separately.\nOne bottle and two bottles must be broken down the same way, or the customer\ncannot see that the second bottle does not bring a second delivery fee — which\nis the main reason for showing any of this.\nA single number on this page looks like four or five times plastic and people\nleave; the same number in three parts is obviously mostly water plus something\nrefundable. Take every figure from the pricing table — do not do arithmetic of\nyour own beyond multiplying the per-bottle amounts by the quantity.\n\nTHE DEPOSIT IS THE PART THAT CHANGES THE NUMBER. Say they get it back when the\nempty goes back, and that once it is going back they do not pay it again — so\nin practice they pay it on the first order and not after. Always keep the\ncondition attached: someone who keeps the bottle is charged it, which is the\nwhole point of a deposit.\n\nGive the ongoing refill price too. That is what they actually pay month after\nmonth, and it is the honest comparison against plastic.\nNever quote the plastic 2-bottle monthly rate to this visitor.`\n : \"\"}\nIf you think they want the other one, ask — one short question — rather than\nassuming.`;\n}\n\n/**\n * THIS VISITOR IS ON A LEAD-CAPTURE SITE, NOT tribecabeverage.com.\n *\n * Written as an explicit override, the same pattern the sf_account block in\n * verifiedBlock already uses — \"everything above about X does not apply\n * here\" — because SYSTEM and CHANNEL above still say a lot about\n * create_account, discounts applied to an order total, and \"want me to set\n * it up,\" none of which is true on these sites. The tool itself is already\n * gone by the time this runs (see toolsFor), so this is belt-and-suspenders\n * on a decision the model structurally cannot get wrong regardless — but a\n * model that still tried to talk through a signup it cannot complete would\n * be a broken promise to a real visitor, so it is worth being explicit.\n */\nfunction leadCaptureBlock(visitor: any): string {\n if (isSelfServiceSite(visitor)) return \"\";\n\n return `\n\nTHIS VISITOR IS ON ${SITE_BRANDS[siteHost(visitor) ?? \"\"] ?? \"A LEAD-CAPTURE SITE\"}, NOT tribecabeverage.com.\nEverything above about the create_account tool, setting an account up\nyourself, or applying a discount to an order total does not apply here —\nthere is no online ordering behind this site, and create_account is not\neven offered to you in this conversation; nothing you say can make it\navailable. Ordinary questions — pricing, coverage, how the service works —\nare still fine to answer with the real numbers in the profile above.\n\nThe close is different: your only goal is their NAME and PHONE NUMBER, so\nthe office can call them to finish it. Never offer to \"set it up\" yourself,\nnever ask for a delivery address, water type, cooler choice or frequency\nthe way a signup would, and never present the 25% code or any other\ndiscount as something you personally apply — the office handles that on\nthe callback. Call submit_lead as soon as you have both fields. Once you\nhave, say someone will be in touch and stop there; do not keep the\nconversation going to collect details only a person on the phone should be\ntaking.`;\n}\n\n/**\n * ORDER READ-BACKS MUST NAME THE PRODUCT.\n *\n * The 9/2/2026 confirmation said \"2 bottles, monthly, hot & cold cooler\n * rental\". Every word of that was true of both products, so the one thing that\n * would have caught the wrong price was the one thing missing. The customer\n * spotted it only after saying yes.\n */\nconst READBACK = `\nCONFIRMING AN ORDER\nWhen you read an order back, NAME THE PRODUCT in full — glass or plastic, the\nsize, and the water type. \"2 bottles\" is not a confirmation; \"2 five-gallon\nglass bottles, spring water\" is.\n\nWhere a deposit is involved, break the total out rather than giving one figure:\nthe bottles, the delivery, then the deposit named as a deposit, then the total.\nA read-back exists to catch a mistake before it becomes an order, and a single\nlump sum hides both the mistake and the refundable part. Take every number from\nthe pricing table above — never compute a rate of your own.\n`.trim();\n\n/**\n * PICKING A CONVERSATION BACK UP AFTER A PERSON HAS BEEN IN IT.\n *\n * The full transcript was always passed, but a colleague's messages arrived as\n * plain assistant turns — indistinguishable from the bot's own. So on a handback\n * it would read a teammate's correction as something it had said itself, with no\n * sense that a person had stepped in, what they had committed to, or what had\n * already been settled while it was away.\n *\n * That matters most where it is most expensive: on 9/2/2026 the office corrected\n * a price the bot had got wrong. Handed back, the bot had no way to know that\n * figure outranked its own.\n */\nfunction handbackBlock(history: any[]): string {\n const people = [\n ...new Set(\n history\n .filter((m) => String(m[\"sender\"]) === \"agent\")\n .map((m) => String(m[\"sender_name\"] ?? \"\").trim())\n .filter(Boolean),\n ),\n ];\n if (!people.length) return \"\";\n\n const who = people.length === 1 ? people[0] : people.join(\" and \");\n return `\n\nA COLLEAGUE HAS BEEN IN THIS CONVERSATION\n${who} replied here in person. Their messages are marked \"[${people[0]} — colleague]\"\nin the transcript above — that marker is for your reading only, so you know\nwhose words are whose. It does NOT mean you were away or are being handed\nanything: you may have been replying in this same conversation the entire\ntime, seconds apart from them.\n\nTHE CUSTOMER ALREADY READ THEIR MESSAGE. It appeared in this same chat, same\nthread, in real time — the same way your own messages did. NEVER ATTRIBUTE IT\nTO ANYONE, not by name and not by role — no \"my colleague just said,\" \"the\noffice mentioned,\" \"someone on the team said,\" \"just to let you know, X said\nthat,\" or any other construction that names a source. The customer does not\nneed to be told WHO said something they watched get said. Speak in your own\nvoice, \"we\"/\"I\", exactly as if it were your own earlier line — because to the\ncustomer, it is: one business, one thread, one voice. If you need to build on\nit, build on it directly (\"For a 6-bottle order we can likely make a route\nwork out there — want to go with that?\") with no framing sentence in front of\nit at all.\n\n- ANYTHING THEY SAID STANDS. If they gave a price, a product or a commitment\n that differs from yours, theirs is right and yours was wrong. Use their\n figure. Never correct them, never contradict them, and never re-quote your\n own earlier number over theirs.\n- Do not re-ask anything already answered anywhere above — by them or by you.\n A customer who has given their address once should not be asked twice.\n- Do not greet them again, reintroduce yourself, recap, or apologise for a gap.\n Just carry on from where the conversation actually is.\n- Never write \"[... — colleague]\" yourself. That marker is for your reading\n only; it is not part of how anyone here writes.\n- If what they were handling clearly needs a person to finish, say you will get\n ${people[0]} back rather than attempting it yourself.`;\n}\n\n/** Map stored messages into the Anthropic format. */\nfunction toTurns(history: any[]): Array<{ role: \"user\" | \"assistant\"; content: string }> {\n const turns: Array<{ role: \"user\" | \"assistant\"; content: string }> = [];\n\n for (const m of history) {\n const sender = String(m[\"sender\"]);\n // System notices are stage directions for the visitor, not conversation.\n if (sender === \"system\") continue;\n\n const role = sender === \"visitor\" ? \"user\" : \"assistant\";\n let body = String(m[\"body\"] ?? \"\").trim();\n if (!body) continue;\n\n // MARK A HUMAN COLLEAGUE'S TURNS. Both they and the bot are \"assistant\" to\n // the API, so without this the model cannot tell which words were its own —\n // and on a handback that is exactly what it needs to know.\n if (sender === \"agent\") {\n const nm = String(m[\"sender_name\"] ?? \"\").trim() || \"colleague\";\n body = `[${nm} — colleague] ${body}`;\n }\n\n // Merge consecutive same-role turns — a visitor sending three quick\n // messages is one turn as far as the model is concerned.\n const last = turns[turns.length - 1];\n if (last && last.role === role) last.content += \"\\n\" + body;\n else turns.push({ role, content: body });\n }\n\n // THE API REQUIRES THE FIRST TURN TO BE FROM THE USER — but the bot speaks\n // first on every single conversation, an opener and often a nudge behind\n // it, before the visitor has said one word. The old fix for that mismatch\n // was to SHIFT those leading assistant turns off entirely, which does not\n // satisfy the requirement so much as delete the only content in the prompt:\n // confirmed live 9/3/2026, a visitor replied \"Yes\" to \"Want me to check\n // your area?\" and the model — left holding just the bare word \"Yes\" with\n // nothing before it — either asked what they meant or greeted them as if\n // nothing had been said. It was answering correctly; it had simply never\n // been shown the question.\n //\n // A synthetic placeholder turn satisfies the API without touching what the\n // bot actually said. It is never shown to the model as something the\n // visitor wrote — content this thin could not be mistaken for a real\n // message — it exists purely so the leading assistant turn has a \"user\"\n // turn to follow.\n if (turns.length && turns[0].role === \"assistant\") {\n turns.unshift({ role: \"user\", content: \"[conversation started]\" });\n }\n\n return turns;\n}\n\n/**\n * The one message this bot ever sends without being spoken to first.\n *\n * Called by the idle sweep, which decides WHETHER to nudge; this only decides\n * what it says. Every guard about who qualifies lives in db.listNudgeCandidates\n * — deliberately, because \"should we interrupt this person\" is not a judgement\n * to leave to a model.\n *\n * Deliberately toolless. An unprompted turn must never be able to create an\n * account: nobody has confirmed anything, and the visitor is not even present.\n */\nexport async function nudgeReply(\n history: any[],\n visitor: any,\n round = 1,\n): Promise {\n const key = anthropicKey();\n if (!key) return null;\n\n const messages: any[] = toTurns(history);\n if (!messages.length) return null;\n\n // The transcript ends with OUR message, so there is nothing for the model to\n // reply to. The instruction is appended as a user turn — a stage direction,\n // not something the customer said — and the transcript itself is untouched.\n // TWO DIFFERENT NOTES, because the two moments are different.\n //\n // The first stall is usually someone reading or distracted, and the right\n // move is to pick up the thread they were on. The second is someone who came\n // back, talked, and trailed off anyway — often mid-signup — and by then a\n // sales question is the wrong instrument. That one just offers help and\n // leaves the door open.\n // A KNOWN CUSTOMER GETS THE SOFT NOTE EVEN ON THE FIRST STALL. The round-1\n // note below explicitly says \"offer to set it up for them\", which is exactly\n // the pitch the sf_account block in verifiedBlock tells the model not to\n // make — no reason to hand it two contradictory instructions and hope it\n // weighs them correctly when writing the softer one here costs nothing.\n const isCustomer = !!visitor?.[\"sf_account\"];\n\n const note = (round >= 2 || isCustomer)\n ? \"[NOTE TO YOU — the visitor has gone quiet. They did NOT send this line, so \"\n + \"do not answer it or refer to it. Write ONE short sentence offering help \"\n + \"and nothing else — a statement, not a pitch, e.g. that you are here if \"\n + \"they need a hand with anything. Do NOT ask for the sale, do NOT ask for \"\n + \"their details, do NOT re-offer anything already offered. It should feel \"\n + \"like leaving the door open, not chasing. No greeting, no recap, no \"\n + \"apology, no emoji.]\"\n : \"[NOTE TO YOU — the visitor has gone quiet. They did NOT send this line, so \"\n + \"do not answer it or refer to it. Write ONE sentence, under 20 words, \"\n + \"checking whether they still want a hand with what they were asking about. \"\n + \"If they were close to ordering, offer to set it up for them. No greeting, \"\n + \"no recap, no apology, no pressure, no emoji.]\";\n\n messages.push({ role: \"user\", content: note });\n\n try {\n const res = await fetch(\"https://api.anthropic.com/v1/messages\", {\n method: \"POST\",\n headers: {\n \"x-api-key\": key,\n \"anthropic-version\": \"2023-06-01\",\n \"content-type\": \"application/json\",\n },\n body: JSON.stringify({\n model: NUDGE_MODEL,\n max_tokens: 120,\n // Same split as aiReply: SYSTEM is identical on every call and worth\n // caching; verifiedBlock is per-visitor and is not.\n system: (function () {\n const vb = verifiedBlock(visitor);\n return [\n { type: \"text\", text: SYSTEM, cache_control: { type: \"ephemeral\" } },\n ...(vb ? [{ type: \"text\", text: vb }] : []),\n ];\n })(),\n messages,\n }),\n signal: AbortSignal.timeout(20000),\n });\n\n if (!res.ok) {\n console.error(`nudge anthropic ${res.status}`);\n return null;\n }\n\n const data = await res.json();\n const text = (data?.content ?? [])\n .filter((b: any) => b?.type === \"text\")\n .map((b: any) => b.text)\n .join(\"\")\n .trim();\n\n // A wall of text arriving unprompted is worse than saying nothing at all,\n // so an over-long nudge is dropped rather than trimmed — a sentence cut off\n // mid-thought would read worse than silence.\n if (text.length > 300) {\n console.warn(`nudge discarded, ${text.length} chars: ${text.slice(0, 80)}`);\n return null;\n }\n\n return text || null;\n } catch (err) {\n console.error(\"nudge failed:\", err);\n return null;\n }\n}\n\nexport async function aiReply(\n history: any[],\n visitor: any,\n invoice?: any,\n conversationId?: string,\n): Promise {\n // Val Town env var names are case-sensitive, and a capitalisation slip in\n // the UI disables the AI silently. Accept the obvious variants rather than\n // fail closed over a capital letter.\n const key = anthropicKey();\n if (!key) {\n console.error(\"ANTHROPIC_API_KEY not set — no AI reply\");\n return null;\n }\n\n const messages: any[] = toTurns(history);\n if (!messages.length) return null;\n\n // CACHED PREFIX, FRESH SUFFIX — not one long string.\n //\n // SYSTEM and READBACK never change between calls: same business profile,\n // same rules, every single time, for every visitor. browsingBlock,\n // handbackBlock and verifiedBlock DO change — per visitor, per turn — so\n // they stay out of the cached block. Caching something that changes almost\n // every call means paying the cache-WRITE price (higher than a plain call)\n // for a hit rate near zero, which would make this slower to run and more\n // expensive, not less.\n //\n // A PLAIN STRING WORKS TOO for `system` — the API accepts either a string\n // or an array of blocks — but only the array form can carry cache_control,\n // which is the entire reason for doing this.\n const dynamic = browsingBlock(visitor) + handbackBlock(history) + verifiedBlock(visitor, invoice)\n + leadCaptureBlock(visitor);\n const system = [\n { type: \"text\", text: SYSTEM + \"\\n\\n\" + READBACK, cache_control: { type: \"ephemeral\" } },\n // Omitted rather than sent empty — Anthropic rejects a content block with\n // no text, and a brand-new visitor with no history and no invoice is\n // exactly the case where every dynamic block returns \"\".\n ...(dynamic ? [{ type: \"text\", text: dynamic }] : []),\n ];\n\n /** One Anthropic round. `withTools` is false on the follow-up — see below. */\n const call = async (msgs: any[], withTools: boolean, timeoutMs: number) => {\n const res = await fetch(\"https://api.anthropic.com/v1/messages\", {\n method: \"POST\",\n headers: {\n \"x-api-key\": key,\n \"anthropic-version\": \"2023-06-01\",\n \"content-type\": \"application/json\",\n },\n body: JSON.stringify({\n model: MODEL,\n max_tokens: MAX_TOKENS,\n system,\n messages: msgs,\n ...(withTools ? { tools: toolsFor(visitor) } : {}),\n }),\n signal: AbortSignal.timeout(timeoutMs),\n });\n\n if (!res.ok) {\n const detail = await res.text().catch(() => \"\");\n console.error(`anthropic ${res.status}`, detail.slice(0, 300));\n return null;\n }\n return await res.json();\n };\n\n /**\n * ONE RETRY, not a loop. Confirmed live 9/4/2026: a call can time out on a\n * plain latency spike with nothing wrong on either end — the very next\n * attempt on the same request, seconds later, went straight through. That\n * is worth one more try before a visitor sees the generic apology.\n *\n * Never more than one. A visitor who has already waited out a 20-second\n * timeout should not be made to wait through a second one that is usually\n * not transient — the retry uses a shorter budget for exactly that reason,\n * so the worst case is bounded well under a minute rather than doubled.\n *\n * Swallows its own failures rather than throwing, so the outer try/catch\n * below is left to do what it was already doing — catch things this\n * function was never meant to handle, like a JSON or tool-result error.\n */\n const callWithRetry = async (msgs: any[], withTools: boolean) => {\n try {\n const data = await call(msgs, withTools, 20000);\n if (data) return data;\n } catch (err) {\n console.error(\"anthropic call failed, retrying once:\", err);\n }\n try {\n return await call(msgs, withTools, 12000);\n } catch (err) {\n console.error(\"anthropic retry also failed:\", err);\n return null;\n }\n };\n\n try {\n let data = await callWithRetry(messages, true);\n if (!data) return null;\n\n // ONE LINE, so caching is a thing that can be checked rather than\n // trusted. cache_read_input_tokens on a real call is the only real proof\n // the breakpoint above is doing anything — everything else about this\n // change is invisible from the outside.\n if (data.usage) {\n const u = data.usage;\n console.log(\n `usage: in=${u.input_tokens} out=${u.output_tokens}`\n + ` cache_write=${u.cache_creation_input_tokens ?? 0}`\n + ` cache_read=${u.cache_read_input_tokens ?? 0}`,\n );\n }\n\n if (data.stop_reason === \"tool_use\") {\n const use = (data.content ?? []).find((b: any) => b?.type === \"tool_use\");\n let result: any = { ok: false, message: \"Unknown tool.\" };\n\n if (use?.name === \"create_account\") {\n result = await createAccount(use.input ?? {});\n // Logged loudly. An account created for a real customer is the most\n // consequential thing this bot does, and \"did it actually fire\" must\n // never be a guess.\n console.log(\n `create_account -> ${result?.ok ? \"OK \" + result.accountId : \"REFUSED \" + (result?.reason ?? \"?\")}`,\n );\n } else if (use?.name === \"submit_lead\") {\n const host = siteHost(visitor);\n const brand = (host && SITE_BRANDS[host]) || host || \"Website Chat\";\n result = await submitChatLead(use.input ?? {}, host ?? \"\");\n console.log(`submit_lead (${brand}) -> ${result?.ok ? \"OK\" : \"REFUSED \" + (result?.reason ?? \"?\")}`);\n } else if (use?.name === \"contact_office\") {\n const visitorId = visitor?.[\"id\"];\n if (visitorId && conversationId && await officeAlreadyEmailed(visitorId, conversationId)) {\n // Already sent for this conversation — report success back to the\n // model without emailing again, so it still tells the visitor\n // truthfully that it's been sent rather than erroring on them.\n result = { ok: true };\n console.log(`contact_office -> SKIPPED (already sent for ${conversationId})`);\n } else {\n result = await emailOffice(visitor, use.input ?? {});\n if (result?.ok && visitorId && conversationId) {\n await recordEvent(visitorId, \"office_email_sent\", conversationId);\n }\n console.log(`contact_office -> ${result?.ok ? \"OK\" : \"REFUSED \" + (result?.reason ?? \"?\")}`);\n }\n }\n\n messages.push({ role: \"assistant\", content: data.content });\n messages.push({\n role: \"user\",\n content: [{\n type: \"tool_result\",\n tool_use_id: use?.id,\n content: JSON.stringify(result),\n }],\n });\n\n // The follow-up deliberately passes NO tools. That makes \"at most one\n // account per visitor message\" a structural guarantee rather than\n // something the prompt asks for — a model that loops cannot create a\n // second account, because it has nothing to call.\n data = await callWithRetry(messages, false);\n if (!data) return null;\n }\n\n const text = (data?.content ?? [])\n .filter((b: any) => b?.type === \"text\")\n .map((b: any) => b.text)\n .join(\"\")\n .trim();\n\n // NEVER FAIL SILENTLY AGAIN. When the model returns no usable text the\n // visitor sees a generic apology, and until 9/1/2026 nothing was written\n // anywhere explaining why — the API call had succeeded, so there was no\n // error to find. stop_reason is the whole diagnosis: \"max_tokens\" means the\n // budget above is too small, and anything else is worth knowing about.\n if (!text) {\n console.error(\n `anthropic returned no usable text — stop_reason=${data?.stop_reason}`\n + `, blocks=${(data?.content ?? []).map((b: any) => b?.type).join(\",\") || \"none\"}`,\n );\n }\n\n return text || null;\n } catch (err) {\n // Returning null means the visitor sees nothing rather than an error\n // string. The widget shows a quiet fallback and offers a human.\n console.error(\"anthropic call failed:\", err);\n return null;\n }\n}\n",[247],"pulls","branches","forks","envVars",{"_261":263,"_264":62},"connections",{"_261":62,"_262":62},"count","unfilledCount",12,"emptyCount",{"_42":246,"_32":247,"_30":248,"_147":-5,"_40":41,"_39":249,"_149":48,"_37":319,"_13":251,"_33":34,"_35":252,"_24":48,"_153":-5,"_280":320,"_27":321},{"_42":239,"_32":240,"_30":241,"_147":-5,"_40":41,"_39":242,"_149":25,"_37":316,"_13":62,"_33":34,"_35":244,"_24":48,"_153":-5,"_280":317,"_27":318},{"_42":233,"_32":234,"_30":235,"_147":-5,"_40":41,"_39":191,"_149":25,"_37":313,"_13":62,"_33":34,"_35":237,"_24":48,"_153":-5,"_280":314,"_27":315},{"_42":225,"_32":226,"_30":227,"_147":-5,"_40":41,"_39":228,"_149":48,"_37":310,"_13":230,"_33":34,"_35":231,"_24":48,"_153":-5,"_280":311,"_27":312},{"_42":217,"_32":218,"_30":219,"_147":-5,"_40":41,"_39":220,"_149":48,"_37":307,"_13":222,"_33":34,"_35":223,"_24":48,"_153":-5,"_280":308,"_27":309},{"_42":210,"_32":211,"_30":212,"_147":-5,"_40":41,"_39":213,"_149":25,"_37":304,"_13":62,"_33":34,"_35":215,"_24":48,"_153":-5,"_280":305,"_27":306},{"_42":202,"_32":203,"_30":57,"_147":-5,"_40":41,"_39":204,"_149":48,"_37":301,"_13":206,"_33":207,"_35":208,"_24":48,"_153":44,"_280":302,"_27":303},{"_42":194,"_32":195,"_30":196,"_147":-5,"_40":41,"_39":197,"_149":25,"_37":298,"_13":199,"_33":34,"_35":200,"_24":48,"_153":-5,"_280":299,"_27":300},{"_42":186,"_32":187,"_30":188,"_147":-5,"_40":41,"_39":189,"_149":25,"_37":295,"_13":191,"_33":34,"_35":192,"_24":48,"_153":-5,"_280":296,"_27":297},{"_42":178,"_32":179,"_30":180,"_147":-5,"_40":41,"_39":181,"_149":25,"_37":292,"_13":62,"_33":183,"_35":184,"_24":48,"_153":-5,"_280":293,"_27":294},{"_42":171,"_32":172,"_30":173,"_147":-5,"_40":41,"_39":174,"_149":25,"_37":289,"_13":168,"_33":34,"_35":176,"_24":48,"_153":-5,"_280":290,"_27":291},{"_42":163,"_32":164,"_30":165,"_147":-5,"_40":41,"_39":166,"_149":25,"_37":286,"_13":168,"_33":34,"_35":169,"_24":48,"_153":-5,"_280":287,"_27":288},{"_42":155,"_32":156,"_30":157,"_147":-5,"_40":41,"_39":158,"_149":25,"_37":283,"_13":160,"_33":34,"_35":161,"_24":48,"_153":-5,"_280":284,"_27":285},{"_42":144,"_32":145,"_30":146,"_147":-5,"_40":41,"_39":148,"_149":25,"_37":279,"_13":151,"_33":34,"_35":152,"_24":48,"_153":-5,"_280":281,"_27":282},["D",1788533320633],"children",[],[145],["D",1788642521817],[],[156],["D",1788391014321],[],[164],["D",1788634820646],[],[172],["D",1788298052921],[],[179],["D",1788390913472],[],[187],["D",1788532431969],[],[195],["D",1788732695719],[],[203],["D",1788445931837],[],[211],["D",1788549248533],[],[218],["D",1788532307456],[],[226],["D",1788226461106],[],[234],["D",1788268113604],[],[240],["D",1788642658342],[],[247],["D",1788226289223],["D",1789571433983],{"_99":98,"_107":103},{"_99":98,"_100":101,"_102":103,"_18":55,"_104":105,"_106":48},{"_13":88,"_32":89,"_42":41,"_90":43,"_91":-5,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":44,"_97":98},"ctx",{"_81":-5,"_127":360,"_361":362,"_363":364,"_365":48,"_366":48,"_367":48,"_368":25,"_369":-5,"_370":-7,"_371":-7,"_372":62,"_373":48,"_374":48,"_375":-5,"_376":48,"_377":48,"_378":48,"_379":-5},"ENV",{"_331":332,"_333":334,"_335":89,"_336":337,"_338":339,"_340":341,"_342":343,"_344":345,"_346":347,"_348":349,"_350":351,"_352":353,"_354":355,"_356":357,"_358":359},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","811aa22498c9b0b5a47e8d778de579cdb990f332","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]

Sign in

Turn on notifications

Tribeca Chat test page

Try this first

Then give it a number

Then ask for a person

Watch it arrive

Conversations

Diff · v642