[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8,"_9":10},"actionData","errors","root",{"_1186":1187,"_1188":1189},"routes/_app.x.$handle.$name",{"_99":98,"_33":45,"_108":89,"_28":109,"_13":14,"_110":-5,"_11":111,"_112":113,"_114":115,"_116":117,"_118":119,"_20":-5,"_120":-5,"_121":-5,"_122":27,"_123":124,"_125":25,"_126":-5,"_127":-5,"_128":129},"routes/_app.x.$handle.$name.branch.$branch.version.$version.diff",{"_11":12,"_13":14,"_15":16,"_17":-5,"_18":-5},"project",{"_43":44,"_33":45,"_38":46,"_47":-5,"_48":27,"_49":50,"_51":50,"_52":53,"_54":-5,"_18":55,"_56":57,"_58":25,"_59":-5,"_60":-5,"_61":62,"_63":64,"_65":66,"_67":68,"_69":70,"_71":-5,"_72":73,"_74":73,"_75":76,"_77":76,"_78":76,"_79":73,"_80":73,"_81":82,"_83":84,"_85":86,"_87":27},"version",1186,"changes",[19],"aiChatInfo","userId",{"_20":21,"_22":23,"_24":25,"_26":27,"_28":29,"_30":29},"file",{"_31":32,"_33":29,"_34":20,"_35":37,"_38":39,"_40":14,"_41":42,"_24":27},"previous",{"_31":32,"_33":29,"_34":20,"_35":36},"deleted",true,"deletedHere",false,"path","SOURCE-BUNDLE.part18.txt","latestPath","fileId","d2eb3952-94f1-11f1-a59c-1607ee4eb77e","name","fileType","content","THE DOGS SPOT — SOURCE BUNDLE (part 18 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (2 of 116 files)\n tests/gads-feed.test.mjs 20841 bytes 76278a3b8831\n tests/harness.mjs 32191 bytes a9990ab8d0e1\n\n================================================================================================\n=====FILE tests/gads-feed.test.mjs =====\n// THE SCHEDULED CONVERSION FEED. v1.0, 15 Aug 2026.\n//\n// WHAT THIS SUITE IS FOR. engine/gads-feed.ts exists so that Google Ads can fetch the offline\n// conversion file itself, weekly, forever, with nobody remembering to do it. That means the one\n// thing it must never do is the one thing nobody will be there to notice: serve a file Google\n// rejects. Google fails a scheduled run on a CSV that has headers and no data rows, and it fails\n// on a column set that is not exactly its template's. Both failures look, from Kim's side, exactly\n// like the situation we are in today — Google seeing none of the real outcomes.\n//\n// So these tests drive the REAL exported handler out of build/, with the network and the blob\n// store replaced, and assert on the BYTES it serves. Not on source text: a structural grep would\n// walk straight past a handler that returns a perfectly well-formed empty file.\n//\n// THE THREE FAKES, same technique as wiring.test.mjs:\n// blob — the handler does `await import(\"https://esm.town/v/std/blob\")`, which Node cannot\n// resolve. A module-resolution hook redirects that one specifier to an in-memory Map.\n// fetch — a router standing in for GoHighLevel. Nothing here can reach the real CRM, and every\n// call is counted, because \"did it read the CRM at all?\" is an assertion in four tests.\n// Deno — `Deno.env.get` exists on val.town and not in Node.\nimport { register } from \"node:module\";\nimport { readFileSync } from \"node:fs\";\nimport { suite, ok, eq, scoped, codeOnly } from \"./_harness.mjs\";\n\nconst { at, t, done, header } = suite(\"gads-feed\");\n\nconst FAKE_BLOB = \"data:text/javascript,\" + encodeURIComponent(`\nconst store = () => (globalThis.__GADS_BLOB__ ??= new Map());\nexport const blob = {\n getJSON: async (k) => { const s = store(); if (!s.has(k)) throw new Error(\"no such blob: \" + k); return s.get(k); },\n setJSON: async (k, v) => { store().set(k, JSON.parse(JSON.stringify(v))); },\n};\n`);\nregister(\"data:text/javascript,\" + encodeURIComponent(`\nconst FAKE = ${JSON.stringify(FAKE_BLOB)};\nexport async function resolve(spec, ctx, next) {\n if (spec === \"https://esm.town/v/std/blob\") return { url: FAKE, shortCircuit: true };\n return next(spec, ctx);\n}\n`));\n\nglobalThis.Deno = { env: { get: () => undefined } };\n\nconst feed = (await import(\"../build/gads-feed.js\")).default;\nconst ROWS = await import(\"../build/gads-rows.js\");\n\n// The token is not in the tree — only its sha256 is, in engine/gads-feed.ts. This suite therefore\n// carries the token the same way Google Ads will: as an opaque string in a URL.\nconst TOKEN = \"tdsfeed_JZm7bL6Vn6ZTC1CfkBIhYqI1nrBtonvF\";\nconst ADMIN = \"tds_nrt_KAsDYDXNi5mw4gKHNTrSyAyRlx9ZbpZGZZrl\";\nconst BASE = \"https://amir5--feed.web.val.run\";\nconst DAY = 86_400_000;\n\nconst store = () => (globalThis.__GADS_BLOB__ ??= new Map());\nlet calls = [];\n\n/** UTC \"YYYY-MM-DD HH:MM:SS\", written differently from engine/gads-rows.ts's gTime on purpose:\n * an expectation computed by the code under test is not an expectation. */\nconst gt = (ms) => new Date(ms).toISOString().replace(\"T\", \" \").slice(0, 19);\n\n/** A CRM with these contacts, and these appointments per contact id. */\nfunction crm({ contacts = [], appts = {}, fail = false, apptFail = new Set() } = {}) {\n globalThis.fetch = async (url) => {\n calls.push(String(url));\n if (fail) throw new Error(\"CRM unreachable (fake)\");\n const s = String(url);\n if (s.includes(\"/contacts/?\")) {\n return { ok: true, json: async () => ({ contacts, meta: { nextPageUrl: null } }) };\n }\n const m = s.match(/\\/contacts\\/([^/]+)\\/appointments/);\n if (m) {\n if (apptFail.has(m[1])) return { ok: false, status: 500, json: async () => ({}) };\n return { ok: true, json: async () => ({ events: appts[m[1]] ?? [] }) };\n }\n return { ok: false, status: 404, json: async () => ({}) };\n };\n}\n\nfunction reset(opts) {\n store().clear();\n store().set(\"puppy_config\", { ghlToken: \"fake-token\" });\n calls = [];\n crm(opts);\n}\n\nconst contact = (id, agoDays, gclid, extra = {}) => ({\n id,\n firstName: id.toUpperCase(),\n lastName: \"Test\",\n dateAdded: new Date(Date.now() - agoDays * DAY).toISOString(),\n ...(gclid ? { attributionSource: { url: `https://thedogsspotga.com/boarding?gclid=${gclid}` } } : {}),\n ...extra,\n});\nconst showedAt = (agoDays, title = \"Boarding\") => ({\n appointmentStatus: \"showed\",\n startTime: new Date(Date.now() - agoDays * DAY).toISOString(),\n title,\n});\n\nconst GCLID_A = \"CjwKCAjw1IHTBhAaEiwA4AYNFrtiXrMjIA4mE-eDCyNAcIZT4vfD1NHBMNHpa2bYdV14mAxzGzSBXxo\";\nconst GCLID_B = \"Cj0KCQjw7eXTBhDBARIsAKF-w44RZ3M74-YXA25B7sExfZRFN3nLvmtjmZ6Ih0Q4FRhTft-cC6yIdbg\";\n\nconst get = (path, init) => feed(new Request(BASE + path, init));\nconst csvOf = async (r) => (await r.text()).trim().split(\"\\n\");\nconst dataRows = (lines) => lines.slice(2);\n\n// ---------------------------------------------------------------------------------------------\nheader(\"THE DOOR: only the right URL opens it, and a miss costs the CRM nothing\");\n\nawait at(\"F1 no key at all is a 404 and does not touch the CRM\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n const r = await get(\"/\");\n eq(r.status, 404, \"an unkeyed request was answered\");\n eq(calls.length, 0, \"an unkeyed request reached the CRM\");\n return scoped(2, \"assertions\");\n});\n\nawait at(\"F2 a wrong key is a 404, and it is a 404 rather than a 401\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n const r = await get(`/${TOKEN}x.csv`);\n eq(r.status, 404, \"a near-miss key was accepted or announced as unauthorised\");\n eq(calls.length, 0, \"a wrong key reached the CRM\");\n return scoped(2, \"assertions\");\n});\n\nawait at(\"F3 the URL Google gets — /KEY/name.csv — returns a CSV\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n const r = await get(`/${TOKEN}/dogsspot-google-conversions.csv`);\n eq(r.status, 200, \"the shape of URL that is going into Google Ads did not work\");\n ok(/text\\/csv/.test(r.headers.get(\"content-type\") ?? \"\"), \"not served as text/csv\");\n ok(/\\.csv/.test(r.headers.get(\"content-disposition\") ?? \"\"), \"no .csv filename offered\");\n return scoped(3, \"assertions\");\n});\n\nawait at(\"F4 /KEY.csv and ?k=KEY reach the same file\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n const a = await (await get(`/${TOKEN}.csv`)).text();\n store().delete(\"gads_feed_cache\");\n const b = await (await get(`/?k=${TOKEN}`)).text();\n eq(a, b, \"the two entry shapes disagree\");\n ok(a.includes(GCLID_A), \"the click id is not in the file\");\n return scoped(2, \"assertions\");\n});\n\nawait at(\"F5 the admin key also opens it, so nobody has to carry two secrets to check on it\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n const r = await get(`/${ADMIN}.csv`);\n eq(r.status, 200, \"the admin key was refused\");\n return scoped(1, \"assertion\");\n});\n\nt(\"F6 the feed key is NOT the admin key — the URL lives in Google Ads forever\", () => {\n // NOT codeOnly() here. Its decoy rule blanks the contents of a whole-line string constant, which\n // is precisely what these two are, so the hashes would both read as \"\". Comment lines are\n // dropped by hand instead, which is the part of codeOnly that matters for this assertion.\n const lines = readFileSync(new URL(\"../engine/gads-feed.ts\", import.meta.url), \"utf8\")\n .split(\"\\n\").filter((l) => !l.trim().startsWith(\"//\"));\n const hashOf = (name) => lines.map((l) => l.match(new RegExp(`${name}\\\\s*=\\\\s*\"([0-9a-f]{64})\"`))?.[1]).find(Boolean);\n const feedHash = hashOf(\"FEED_KEY_SHA256\");\n const adminHash = hashOf(\"ADMIN_KEY_SHA256\");\n ok(feedHash, \"no feed key hash in the source\");\n ok(adminHash, \"no admin key hash in the source\");\n ok(feedHash !== adminHash, \"the feed URL would carry the admin key into a Google Ads screen\");\n return scoped(3, \"assertions\");\n});\n\n// ---------------------------------------------------------------------------------------------\nheader(\"THE FILE: exactly Google's template, or the schedule fails every week\");\n\nawait at(\"F7 the header and the Parameters line are Google's, and every line has seven columns\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A), contact(\"b\", 10, GCLID_B)], appts: { b: [showedAt(2)] } });\n const lines = await csvOf(await get(`/${TOKEN}.csv`));\n eq(lines[0], \"Parameters:TimeZone=+0000,,,,,,\", \"the Parameters line changed\");\n eq(lines[1], \"Google Click ID,Conversion Name,Conversion Time,Conversion Value,Conversion Currency,Ad User Data,Ad Personalization\", \"the column set changed\");\n // Seven columns on EVERY line. The consent pair is the pair whose absence Google reports as the\n // useless \"The selected file is missing data columns\".\n for (const l of lines) eq(l.split(\",\").length, 7, `wrong column count: ${l.slice(0, 60)}`);\n ok(lines.length >= 5, \"expected a params line, a header and three data rows\");\n return scoped(lines.length + 3, \"lines and assertions\");\n});\n\nawait at(\"F8 a lead row is dateAdded + 5 minutes, $5, USD, consent UNSPECIFIED\", async () => {\n const c = contact(\"a\", 3, GCLID_A);\n reset({ contacts: [c] });\n const rows = dataRows(await csvOf(await get(`/${TOKEN}.csv`)));\n eq(rows.length, 1, \"expected exactly one lead row\");\n const want = `\"${GCLID_A}\",\"CRM Lead (Google)\",\"${gt(Date.parse(c.dateAdded) + 5 * 60_000)}\",5,USD,UNSPECIFIED,UNSPECIFIED`;\n eq(rows[0], want, \"the lead row is not what Google's template wants\");\n // The +5 is not cosmetic: the conversion must be AFTER the click, and the click precedes the\n // contact record. A conversion at or before its click is dropped as CONVERSION_PRECEDES_GCLID.\n ok(Date.parse(rows[0].split('\",\"')[2].slice(0, 19).replace(\" \", \"T\") + \"Z\") > Date.parse(c.dateAdded), \"the conversion is not after the click\");\n return scoped(3, \"assertions\");\n});\n\nawait at(\"F9 a showed appointment adds one $150 row at the FIRST attended start time\", async () => {\n const c = contact(\"b\", 20, GCLID_B);\n reset({ contacts: [c], appts: { b: [showedAt(2, \"second stay\"), showedAt(15, \"first stay\")] } });\n const rows = dataRows(await csvOf(await get(`/${TOKEN}.csv`)));\n eq(rows.length, 2, \"expected a lead row and exactly one showed row\");\n ok(rows[1].includes(\"CRM Booking Showed (Google)\"), \"no showed row\");\n ok(rows[1].includes(gt(Date.now() - 15 * DAY).slice(0, 16)), \"the showed row used the later stay, inventing a second sale\");\n ok(rows[1].endsWith(\",150,USD,UNSPECIFIED,UNSPECIFIED\"), \"the showed row is not valued at 150 USD\");\n return scoped(4, \"assertions\");\n});\n\nawait at(\"F10 a contact older than the window is not in the file\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A), contact(\"old\", 84, GCLID_B)] });\n const body = await (await get(`/${TOKEN}.csv`)).text();\n ok(body.includes(GCLID_A), \"the recent contact is missing\");\n ok(!body.includes(GCLID_B), \"a contact past the 80-day window was emitted; Google drops conversions uploaded more than 90 days after the click\");\n return scoped(2, \"assertions\");\n});\n\nawait at(\"F11 a contact with no click id is not in the file at all\", async () => {\n reset({ contacts: [contact(\"nogclid\", 2, null), contact(\"a\", 3, GCLID_A)] });\n const rows = dataRows(await csvOf(await get(`/${TOKEN}.csv`)));\n eq(rows.length, 1, \"a contact with no Google click was uploaded as a Google conversion\");\n return scoped(1, \"assertion\");\n});\n\nawait at(\"F12 a URL-encoded gclid is still found — it is how GHL usually stores it\", async () => {\n reset({ contacts: [{ id: \"enc\", firstName: \"Enc\", dateAdded: new Date(Date.now() - DAY).toISOString(), lastAttributionSource: { url: `https://x.com/?utm=1%26gclid%3D${GCLID_A}` } }] });\n const body = await (await get(`/${TOKEN}.csv`)).text();\n ok(body.includes(GCLID_A), \"a %3D-encoded gclid was missed\");\n return scoped(1, \"assertion\");\n});\n\nawait at(\"F13 two builds over unchanged data are byte-identical, which is what makes weekly re-fetching free\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A), contact(\"b\", 10, GCLID_B)], appts: { b: [showedAt(2)] } });\n const first = await (await get(`/${TOKEN}.csv`)).text();\n store().delete(\"gads_feed_cache\");\n const second = await (await get(`/${TOKEN}.csv`)).text();\n eq(first, second, \"the same data produced two different files, so Google would count them twice\");\n // Google: \"the same conversion won't be imported more than once\" for the same click id,\n // conversion name and time. Identical bytes are what that guarantee is keyed on.\n ok(first.split(\"\\n\").length === second.split(\"\\n\").length, \"row counts differ\");\n return scoped(2, \"assertions\");\n});\n\nawait at(\"F14 one contact whose appointments will not load costs that row, not the file\", async () => {\n reset({\n contacts: [contact(\"a\", 3, GCLID_A), contact(\"b\", 10, GCLID_B)],\n appts: { b: [showedAt(2)] },\n apptFail: new Set([\"b\"]),\n });\n const rows = dataRows(await csvOf(await get(`/${TOKEN}.csv`)));\n eq(rows.length, 2, \"an unreadable appointments call took out more than its own row\");\n ok(rows.every((r) => r.includes(\"CRM Lead (Google)\")), \"expected both leads to survive\");\n return scoped(2, \"assertions\");\n});\n\n// ---------------------------------------------------------------------------------------------\nheader(\"RELIABILITY: what it serves on a bad night, when nobody is watching\");\n\nawait at(\"F15 a second fetch inside the freshness window serves the cache and never reads the CRM\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n await get(`/${TOKEN}.csv`);\n const readsAfterFirst = calls.length;\n ok(readsAfterFirst > 0, \"the first fetch did not read the CRM at all\");\n calls = [];\n const r = await get(`/${TOKEN}.csv`);\n eq(calls.length, 0, \"the cache was ignored and the CRM read twice in a minute\");\n eq(r.headers.get(\"x-feed-served\"), \"cache-fresh\", \"not served from cache\");\n return scoped(3, \"assertions\");\n});\n\nawait at(\"F16 CRM down + a warm cache = last week's file, 200, not a failed run\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n const good = await (await get(`/${TOKEN}.csv`)).text();\n // Age the cache past the freshness window so the handler is forced to try a rebuild.\n const c = store().get(\"gads_feed_cache\");\n c.builtAt = new Date(Date.now() - 30 * 3_600_000).toISOString();\n store().set(\"gads_feed_cache\", c);\n crm({ fail: true });\n const r = await get(`/${TOKEN}.csv`);\n eq(r.status, 200, \"a CRM outage turned into a failed scheduled run\");\n eq(await r.text(), good, \"the last good file was not what was served\");\n eq(r.headers.get(\"x-feed-served\"), \"cache-build-failed\", \"the fallback was not recorded\");\n return scoped(3, \"assertions\");\n});\n\nawait at(\"F17 a clean scan that finds nothing does NOT overwrite the good file with headers\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n const good = await (await get(`/${TOKEN}.csv`)).text();\n const c = store().get(\"gads_feed_cache\");\n c.builtAt = new Date(Date.now() - 30 * 3_600_000).toISOString();\n store().set(\"gads_feed_cache\", c);\n crm({ contacts: [] });\n const r = await get(`/${TOKEN}.csv`);\n const body = await r.text();\n eq(r.status, 200, \"an empty window became a failed run\");\n eq(body, good, \"a header-only file was served; Google fails the run with a schema error\");\n eq(store().get(\"gads_feed_cache\").csv, good, \"the good file was overwritten by an empty build\");\n return scoped(3, \"assertions\");\n});\n\nawait at(\"F18 no cache and no CRM is a loud 503, never a file with headers and no rows\", async () => {\n reset({ fail: true });\n const r = await get(`/${TOKEN}.csv`);\n eq(r.status, 503, \"a request that could not be answered was answered anyway\");\n const body = await r.text();\n ok(!body.includes(\"Google Click ID\"), \"a header-only CSV was served: Google reports that as a schema error, not as 'no data'\");\n ok(!/text\\/csv/.test(r.headers.get(\"content-type\") ?? \"\"), \"an error was labelled as a CSV\");\n return scoped(3, \"assertions\");\n});\n\nawait at(\"F19 no response on any path is ever a header-only CSV\", async () => {\n const shapes = [];\n reset({ contacts: [] }); // clean scan, nothing found, no cache\n shapes.push(await get(`/${TOKEN}.csv`));\n reset({ fail: true }); // CRM down, no cache\n shapes.push(await get(`/${TOKEN}.csv`));\n for (const r of shapes) {\n const body = await r.text();\n const lines = body.trim().split(\"\\n\").filter(Boolean);\n ok(!(r.status === 200 && lines.length <= 2), `served ${lines.length} lines with status ${r.status}: that is a header-only file`);\n }\n return scoped(shapes.length, \"empty-source cases\");\n});\n\n// ---------------------------------------------------------------------------------------------\nheader(\"VISIBILITY: an automation nobody watches must be able to say when it last ran\");\n\nawait at(\"F20 ?status=1 answers without reading the CRM\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n await get(`/${TOKEN}.csv`);\n calls = [];\n const r = await get(`/${TOKEN}/status`);\n const j = await r.json();\n eq(calls.length, 0, \"opening the status page cost seven seconds of CRM reads\");\n eq(j.file.rows, 1, \"the status view does not know how many rows are in the file\");\n ok(j.how.once.includes(\"Schedules\"), \"the status view does not carry the click path that set it up\");\n ok(j.how.needs.includes(\"CRM Lead (Google)\"), \"the status view does not name the conversion actions it feeds\");\n return scoped(4, \"assertions\");\n});\n\nawait at(\"F21 every fetch is recorded with its user-agent and its time\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n await get(`/${TOKEN}.csv`, { headers: { \"user-agent\": \"Google-Ads-Conversion-Upload/1.0\" } });\n const j = await (await get(`/${TOKEN}?status=1`)).json();\n ok(j.fetches.length >= 1, \"nothing was recorded\");\n ok(j.fetches.some((f) => f.ua.includes(\"Google-Ads\")), \"the fetcher's user-agent was not kept, so 'did Google collect it?' has no answer\");\n ok(j.lastFetch && Date.now() - Date.parse(j.lastFetch.at) < 60_000, \"the fetch time is not usable\");\n eq(j.daysSinceLastFetch < 1, true, \"days-since is wrong\");\n return scoped(4, \"assertions\");\n});\n\nawait at(\"F22 a schedule that stopped nine days ago is visibly stalled\", async () => {\n reset({ contacts: [contact(\"a\", 3, GCLID_A)] });\n await get(`/${TOKEN}.csv`);\n const c = store().get(\"gads_feed_cache\");\n c.fetches[0].at = new Date(Date.now() - 12 * DAY).toISOString();\n store().set(\"gads_feed_cache\", c);\n // Read the flag out of the blob directly rather than through a request, because a status request\n // is itself a fetch and would reset the very clock under test.\n const stalled = Date.now() - Date.parse(store().get(\"gads_feed_cache\").fetches[0].at) > 9 * DAY;\n ok(stalled, \"twelve days without a fetch is not being treated as stalled\");\n const src = codeOnly(readFileSync(new URL(\"../engine/gads-feed.ts\", import.meta.url), \"utf8\"));\n ok(/scheduleLooksStalled/.test(src), \"the status view has no stalled flag at all\");\n ok(/9 \\* 86_400_000/.test(src), \"the stall threshold is not the weekly-schedule-plus-slack one\");\n return scoped(3, \"assertions\");\n});\n\n// ---------------------------------------------------------------------------------------------\nheader(\"THE CONTRACTS THAT LIVE OUTSIDE THIS FILE\");\n\nt(\"F23 the window keeps a real margin under Google's 90-day rule\", () => {\n ok(ROWS.FEED_DAYS <= 80, `the feed window is ${ROWS.FEED_DAYS} days; Google drops conversions uploaded more than 90 days after the click and the click precedes the contact record`);\n ok(ROWS.MAX_DAYS <= 85, \"the hard cap is at or past Google's limit\");\n ok(90 - ROWS.FEED_DAYS >= 10, \"less than ten days of margin between the window and Google's cut-off\");\n return scoped(3, \"assertions\");\n});\n\nt(\"F24 deploy.mjs registers gads-feed.ts as an http file — otherwise there is no URL at all\", () => {\n const src = codeOnly(readFileSync(new URL(\"../scripts/deploy.mjs\", import.meta.url), \"utf8\"));\n ok(/\"gads-feed\\.ts\":\\s*\"http\"/.test(src), \"gads-feed.ts is not typed http in deploy.mjs: it would deploy as a module with no endpoint, and the schedule would point at a URL that never existed\");\n return scoped(1, \"assertion\");\n});\n\nt(\"F25 gads.ts and the feed still agree on Google's column set and the two conversion names\", () => {\n const src = codeOnly(readFileSync(new URL(\"../engine/gads.ts\", import.meta.url), \"utf8\"));\n ok(src.includes(ROWS.CSV_HEADER), \"the hand-driven endpoint and the scheduled feed no longer emit the same columns\");\n ok(src.includes(ROWS.PARAMS_LINE), \"the Parameters lines have drifted apart\");\n ok(src.includes(ROWS.LEAD_NAME) && src.includes(ROWS.SHOW_NAME), \"the two conversion action names have drifted apart; Google rejects rows whose name it does not know\");\n return scoped(3, \"assertions\");\n});\n\nawait done();\n\n\n=====FILE tests/harness.mjs =====\n// NURTURE ENGINE TEST HARNESS — runs the real engine functions, offline, no network, no sends.\n// Every test states: what it proves, the input, the expectation. Failures are loud and non-zero-exit.\n// Run: node tests/harness.mjs\nimport * as E from \"../build/engine.js\";\n\nlet pass = 0, fail = 0;\nconst results = [];\n// LIVE ASSERTIONS, counted inside ok() and eq() themselves. This suite reports no scope and no\n// check count, so before this a test could be emptied of every assertion and still print PASS.\n// The v2 harness (_harness.mjs) grew the same guard on 7 August after H1 was hollowed out and the\n// whole runner stayed green; this file runs 25 tests on the same terms and needed it too.\nlet live = 0;\nfunction t(name, proves, fn) {\n let ok = false, detail = \"\";\n const before = live;\n try {\n detail = fn() ?? \"\";\n if (live === before) throw new Error(\"this test executed ZERO assertions: it cannot fail, so it is not a test\");\n ok = true;\n }\n catch (e) { detail = String(e && e.message || e).slice(0, 300); }\n ok ? pass++ : fail++;\n results.push({ name, proves, ok, detail });\n console.log(`${ok ? \"PASS\" : \"FAIL\"} ${name}${detail ? `\\n ${detail}` : \"\"}`);\n}\nfunction eq(a, b, m) { live++; if (JSON.stringify(a) !== JSON.stringify(b)) throw new Error(`${m || \"\"} expected ${JSON.stringify(b)}, got ${JSON.stringify(a)}`); }\nfunction ok(c, m) { live++; if (!c) throw new Error(m || \"expected truthy\"); }\n\nconst KIM_CAL = \"qHuYJ0NEqzibnoqf5Cw3\";\nconst ALL = [...E.MAIN_SEQUENCE, ...E.BRANCH_A, ...E.BRANCH_B];\n\nconsole.log(\"\\n=== A. THE COPY ITSELF ===\\n\");\n\nt(\"A1 booking link points at Kim's own Pup Talk calendar\",\n \"a lead who clicks the link lands on the same calendar the engine watches for conversions\",\n () => {\n ok(E.REAL_BOOKING_URL.includes(KIM_CAL), `REAL_BOOKING_URL=${E.REAL_BOOKING_URL}`);\n ok(!E.REAL_BOOKING_URL.includes(\"pbe-\"), \"still points at the agency widget\");\n return E.REAL_BOOKING_URL;\n });\n\nt(\"A2 no customer-visible message contains a banned term\",\n \"Kim banned 'discovery call'; grooming is not a service; training prices are never quoted\",\n () => {\n const banned = [/discovery/i, /grooming/i, /\\$\\s?\\d/];\n const hits = [];\n for (const s of ALL) {\n const text = `${s.subject || \"\"}\\n${s.previewText || \"\"}\\n${s.bodyTemplate}`;\n for (const b of banned) if (b.test(text)) hits.push(`${s.id} ~ ${b}`);\n }\n eq(hits, [], \"banned terms found:\");\n return `${ALL.length} templates clean`;\n });\n\nt(\"A3 every SMS is inside carrier-safe length after merge fields resolve\",\n \"an over-length SMS silently splits into two billed segments and reads broken\",\n () => {\n const over = [];\n for (const s of ALL.filter((x) => x.channel === \"sms\")) {\n const r = E.renderStep(s, { firstName: \"Bartholomew\", companyName: \"Wolfgang-Maximilian\" }, { testMode: false });\n const txt = r.text ?? \"\"; if (txt.length > 320) over.push(`${s.id}=${txt.length}`);\n }\n eq(over, [], \"SMS over 320 chars:\");\n return `${ALL.filter((x) => x.channel === \"sms\").length} SMS templates, worst case under 320`;\n });\n\nt(\"A4 no unresolved merge token survives rendering\",\n \"a customer receiving 'Hi {{FIRST_NAME}}' is worse than no message at all\",\n () => {\n const bad = [];\n for (const s of ALL) {\n const r = E.renderStep(s, { firstName: null, companyName: null }, { testMode: false });\n const blob = `${r.subject || \"\"} ${r.html ?? \"\"} ${r.text ?? \"\"}`;\n if (/\\{\\{|\\}\\}|\\[link\\]|\\[phone\\]|INSERT|TODO|LOREM/i.test(blob)) bad.push(s.id);\n }\n eq(bad, [], \"templates with unresolved tokens on NULL contact data:\");\n return `${ALL.length} templates render clean with every field null`;\n });\n\nt(\"A5 a nameless contact still gets a sentence that reads like English\",\n \"GHL contacts created from Messenger frequently have no first name and no dog name\",\n () => {\n const r = E.renderStep(E.MAIN_SEQUENCE[0], { firstName: null, companyName: null }, { testMode: false });\n const out = r.html ?? r.text ?? \"\"; ok(!/Hi ,/.test(out), \"produced 'Hi ,'\");\n ok(!/[A-Za-z] [A-Za-z]/.test(out.replace(/\\n/g, \" \")), \"double spaces from an empty substitution\");\n return `fallbacks: firstName -> ${JSON.stringify(E.resolveFirstName(null))}, dogName -> ${JSON.stringify(E.resolveDogName(null))}`;\n });\n\nconsole.log(\"\\n=== B. TIMING AND QUIET HOURS ===\\n\");\n\nconst at = (iso) => new Date(iso).getTime();\n\nt(\"B1 no SMS lands before 9am or after 7pm Eastern\",\n \"a 03:00 text to a dog owner is the message that gets a business reported, not replied to\",\n () => {\n const cases = [\n [\"2026-08-03T06:00:00Z\", false, \"02:00 ET\"],\n [\"2026-08-03T12:00:00Z\", false, \"08:00 ET\"],\n [\"2026-08-03T14:00:00Z\", true, \"10:00 ET\"],\n [\"2026-08-03T22:00:00Z\", true, \"18:00 ET\"],\n [\"2026-08-04T00:00:00Z\", false, \"20:00 ET\"],\n ];\n const bad = [];\n for (const [iso, want, label] of cases) {\n const got = E.inSendWindow(\"sms\", at(iso)).ok;\n if (got !== want) bad.push(`${label}: expected ${want}, got ${got}`);\n }\n eq(bad, [], \"send-window failures:\");\n return \"boundaries hold at 09:00 and 19:00 America/New_York\";\n });\n\nt(\"B2 the window is computed in Eastern time, not the server's UTC\",\n \"the scheduler runs in UTC; if the window were computed there, every send would be 4-5h off\",\n () => {\n const p = E.businessLocalParts(at(\"2026-08-03T14:00:00Z\"));\n eq(p.hour, 10, \"14:00 UTC in August should be 10:00 EDT;\");\n const w = E.businessLocalParts(at(\"2026-01-05T14:00:00Z\"));\n eq(w.hour, 9, \"14:00 UTC in January should be 09:00 EST (DST handled);\");\n return \"EDT and EST both correct — daylight saving is handled by the timezone database, not arithmetic\";\n });\n\nt(\"B3 due-ness is anchored to the contact's own entry time\",\n \"two contacts who entered a week apart must not receive step 3 on the same day\",\n () => {\n const anchor = \"2026-08-01T12:00:00Z\";\n ok(E.isDue(0, anchor, at(\"2026-08-01T12:00:00Z\")), \"step at +0h should be due immediately\");\n ok(!E.isDue(72, anchor, at(\"2026-08-03T11:00:00Z\")), \"day-3 step due early\");\n ok(E.isDue(72, anchor, at(\"2026-08-04T13:00:00Z\")), \"day-3 step not due after 3 days\");\n return \"offsets are relative, never absolute calendar dates\";\n });\n\nconsole.log(\"\\n=== C. THE SAFETY LADDER (decideAction) ===\\n\");\n\nconst baseFacts = (over = {}) => ({\n now: at(\"2026-08-03T15:00:00Z\"),\n contact: { id: \"c1\", firstName: \"Ann\", companyName: \"Rex\", dnd: false },\n opportunities: [],\n pupTalkAppt: null,\n declinedSignal: false,\n hasUnansweredInboundReply: false,\n conversationCheckFailed: false,\n foreignOutboundAt: null, // v1.5 R27 — no other system has messaged this contact\n channelBlocked: { email: false, sms: false }, // v1.6 R28 — no per-channel opt-out\n ...over,\n});\nconst stateMain = () => ({ ...E.freshState(\"2026-08-01T12:00:00Z\"), status: \"main\", lastMainStepSent: 0 });\n\nt(\"C1 do-not-contact outranks a scheduled send\",\n \"a contact who opted out must never receive the next step, whatever the calendar says\",\n () => {\n const d = E.decideAction(baseFacts({ contact: { id: \"c1\", firstName: \"Ann\", companyName: null, dnd: true } }), stateMain());\n ok(d.kind !== \"send\", `engine chose to ${d.kind}`);\n return `DND -> ${d.kind}${d.nextStatus ? ` (${d.nextStatus})` : \"\"}`;\n });\n\nt(\"C2 a failed reply-check blocks the send instead of assuming silence\",\n \"if the engine cannot tell whether someone wrote back, sending is the unrecoverable choice\",\n () => {\n const d = E.decideAction(\n baseFacts({ conversationCheckFailed: true }),\n stateMain(),\n );\n ok(d.kind !== \"send\", `engine chose to ${d.kind} despite not knowing if they replied`);\n return `check-failed -> ${d.kind} (fails closed)`;\n });\n\nt(\"C3 an inbound reply pauses the sequence and hands it to a human\",\n \"nobody should get a marketing text while mid-conversation with the front desk\",\n () => {\n const d = E.decideAction(\n baseFacts({ hasUnansweredInboundReply: true }),\n stateMain(),\n );\n ok(d.kind !== \"send\", `engine chose to ${d.kind}`);\n return `inbound reply -> ${d.kind}${d.nextStatus ? ` (${d.nextStatus})` : \"\"}`;\n });\n\nt(\"C4 someone who booked a Pup Talk stops receiving 'book a Pup Talk' messages\",\n \"this is the exact defect the wrong booking link would have caused invisibly\",\n () => {\n const appt = { id: \"a1\", startTime: at(\"2026-08-10T15:00:00Z\"), endTime: at(\"2026-08-10T15:30:00Z\"), appointmentStatus: \"confirmed\", deleted: false };\n ok(E.apptIsLiveBooked(appt), \"a confirmed future appointment should read as live-booked\");\n const d = E.decideAction(baseFacts({ pupTalkAppt: appt }), stateMain());\n ok(d.kind !== \"send\", `engine chose to ${d.kind} to someone already booked`);\n return `live booking -> ${d.kind}${d.nextStatus ? ` (${d.nextStatus})` : \"\"}`;\n });\n\nt(\"C5 a terminal contact is never re-sent to, on any later run\",\n \"the loop runs every 15 minutes forever; an un-terminal terminal state is an infinite message source\",\n () => {\n const bad = [];\n for (const st of E.TERMINAL_STATUSES) {\n const d = E.decideAction(baseFacts(), { ...E.freshState(\"2026-08-01T12:00:00Z\"), status: st });\n if (d.kind === \"send\") bad.push(st);\n }\n eq(bad, [], \"terminal statuses that still sent:\");\n return `${E.TERMINAL_STATUSES.size} terminal statuses, none sends`;\n });\n\nt(\"C6 a cancelled appointment does not read as a booking\",\n \"cancelling and then being treated as converted means the lead is dropped in silence\",\n () => {\n ok(!E.apptIsLiveBooked({ id:\"a2\", startTime: at(\"2026-08-10T15:00:00Z\"), endTime: at(\"2026-08-10T15:30:00Z\"), appointmentStatus: \"cancelled\", deleted:false }), \"cancelled read as booked\");\n ok(!E.apptIsLiveBooked(null), \"null appointment read as booked\");\n return \"cancelled and missing appointments both read as not-booked\";\n });\n\nconsole.log(\"\\n=== D. BULK AND SURGE BEHAVIOUR ===\\n\");\n\nt(\"D1 a bulk tagging of hundreds does not become hundreds of sends\",\n \"someone selecting 800 old contacts and applying the tag must not blast 800 people\",\n () => {\n const many = Array.from({ length: 800 }, (_, i) => ({ id: `c${i}` }));\n const sel = E.selectEnrollable(many, 25, false);\n ok(sel.surgeHeld === true && sel.enroll.length === 0, `surge guard let ${sel.enroll.length} through`);\n const ack = E.selectEnrollable(many, 25, true);\n ok(ack.enroll.length === 800, \"acknowledged surge should pass through deliberately\");\n return `800 candidates -> surgeHeld=${sel.surgeHeld}, enrolled=${sel.enroll.length}; with explicit acknowledgement ${ack.enroll.length}`;\n });\n\nt(\"D2 state pruning keeps finished contacts from growing the store forever\",\n \"an unbounded blob eventually fails to write and takes the whole engine down with it\",\n () => {\n const old = { a: { status: \"done_booked\", enteredAt: \"2025-01-01T00:00:00Z\", lastSentAt: \"2025-01-02T00:00:00Z\" },\n b: { status: \"main\", enteredAt: \"2026-08-01T00:00:00Z\", lastSentAt: \"2026-08-01T00:00:00Z\" } };\n const r = E.pruneState(old, at(\"2026-08-03T00:00:00Z\"));\n ok(Object.keys(r.kept).includes(\"b\"), \"pruned an active contact\");\n return `pruned ${r.prunedIds.length}, kept ${Object.keys(r.kept).length}`;\n });\n\nconsole.log(\"\\n=== E. SOURCE-LEVEL GUARANTEES ===\\n\");\nimport { readFileSync } from \"node:fs\";\nconst mainSrc = readFileSync(new URL(\"../engine/puppy_path_v1.1.ts\", import.meta.url), \"utf8\");\nconst apiSrc = readFileSync(new URL(\"../engine/api.ts\", import.meta.url), \"utf8\");\n\nt(\"E1 the kill switch is checked before any contact is examined\",\n \"a stop control that only takes effect after the batch has sent is not a stop control\",\n () => {\n const kill = mainSrc.indexOf('getJSON(\"nurture_kill\")');\n const load = mainSrc.indexOf(\"await loadAllState()\");\n ok(kill > 0, \"kill switch not present\");\n ok(kill < load, `kill check at ${kill} comes after state load at ${load}`);\n return `kill check at char ${kill}, first contact read at ${load}`;\n });\n\n// [E2 DELETED, 14 Aug 2026. It was `ok(/TEST_MODE\\s*=\\s*\$Deno\\.env\\.get\\(\"TEST_MODE\"\$...` — a grep\n// for a line of source that no longer exists. Mode resolution moved into `resolveMode(envVal,\n// blobVal)` and the guarantee is intact; the ASSERTION was stale, and a stale grep is a check that\n// reports on the absence of a string rather than on the behaviour. It was also RED on correct\n// input, which by this project's own rule is worse than no check at all.\n// Its guarantee is covered strictly better by consent-guard.test.mjs CG-7, which CALLS resolveMode\n// in all four polarities — no env/no blob is practice, only boolean `true` arms live, a STRING\n// \"true\" does not, and env beats blob — and which actually runs in the suite. Deleting a grep in\n// favour of a live call is not a loss of coverage.]\n\nt(\"E3 the control panel never returns the credential it tests with\",\n \"a dashboard link is going to end up in a text message to Kim; it must not carry a CRM token\",\n () => {\n const ret = apiSrc.slice(apiSrc.indexOf(\"return { credentialFrom\"), apiSrc.indexOf(\"return { credentialFrom\") + 120);\n ok(ret.includes(\"credentialFrom: from\"), \"self-test return shape changed\");\n ok(!/\\btoken\\b/.test(ret), `self-test return exposes a token: ${ret}`);\n ok(apiSrc.includes(\"status: r.status\"), \"self-test does not report status codes only\");\n return \"self-test returns credentialFrom + endpoint + HTTP status only; the token itself never leaves the function\";\n });\n\nt(\"E4 an unauthenticated request leaks nothing at all\",\n \"the panel URL is guessable-adjacent; a 401 must not differ between wrong-key and no-key\",\n () => {\n // v1.5, 2 Aug: this assertion used to search for \"safeEq(k, KEY)\", a string deleted when auth\n // moved to SHA-256. indexOf returned -1, so -1 < anything passed vacuously and E4 proved nothing\n // for several runs. Now it locates the real guard and fails loudly if either marker disappears.\n const guard = Math.max(apiSrc.indexOf(\"if (!(await authorised(k)))\"), apiSrc.indexOf(\"const isAdmin = await authorised(k);\"));\n const firstRead = apiSrc.indexOf(\"await collect()\");\n ok(guard > -1, \"auth guard `if (!(await authorised(k)))` not found — did the guard get renamed?\");\n ok(firstRead > -1, \"`await collect()` not found — did the data gather get renamed?\");\n ok(guard < firstRead, \"data gathered before auth check\");\n ok((apiSrc.match(/Not found/g) || []).length >= 1, \"no uniform 401 body\");\n return `auth guard at char ${guard} precedes first blob read at ${firstRead}; identical body for absent and wrong keys`;\n });\n\n\nconsole.log(\"\\n=== F. OPT-OUT FURNITURE (added after the adversarial pass) ===\\n\");\n\nt(\"F1 every rendered SMS carries a STOP instruction\",\n \"the adversarial pass found not one of the five shipped SMS said STOP — an earlier risk register wrongly claimed it did\",\n () => {\n const missing = [];\n for (const s of ALL.filter((x) => x.channel === \"sms\")) {\n const r = E.renderStep(s, { firstName: \"Ann\", companyName: \"Rex\" }, { testMode: false });\n if (!/\\bSTOP\\b/.test(r.text ?? \"\")) missing.push(s.id);\n }\n eq(missing, [], \"SMS with no STOP instruction:\");\n return `${ALL.filter((x) => x.channel === \"sms\").length} SMS, all carry it`;\n });\n\nt(\"F2 every rendered email carries an unsubscribe line and a physical location\",\n \"a bulk email with neither is the one that gets a sending domain blacklisted\",\n () => {\n const missing = [];\n for (const s of ALL.filter((x) => x.channel === \"email\")) {\n const r = E.renderStep(s, { firstName: \"Ann\", companyName: \"Rex\" }, { testMode: false });\n const h = r.html ?? \"\";\n if (!/UNSUBSCRIBE/i.test(h) || !/Ellabell/i.test(h)) missing.push(s.id);\n }\n eq(missing, [], \"emails missing unsubscribe or postal identity:\");\n return `${ALL.filter((x) => x.channel === \"email\").length} emails, all carry both`;\n });\n\nt(\"F3 the opt-out line cannot push an SMS over the carrier limit\",\n \"compliance furniture that breaks the message into two segments defeats itself\",\n () => {\n const over = [];\n for (const s of ALL.filter((x) => x.channel === \"sms\")) {\n const r = E.renderStep(s, { firstName: \"Bartholomew\", companyName: \"Wolfgang-Maximilian\" }, { testMode: false });\n if ((r.text ?? \"\").length > 320) over.push(`${s.id}=${(r.text ?? \"\").length}`);\n }\n eq(over, [], \"SMS over 320 WITH furniture appended:\");\n const worst = Math.max(...ALL.filter((x) => x.channel === \"sms\").map((s) =>\n (E.renderStep(s, { firstName: \"Bartholomew\", companyName: \"Wolfgang-Maximilian\" }, { testMode: false }).text ?? \"\").length));\n return `worst case ${worst}/320 including the STOP line`;\n });\n\nt(\"F4 the copy module itself is untouched\",\n \"the furniture is appended by the renderer so the client-approved wording stays byte-for-byte hers\",\n () => {\n const inTemplates = ALL.filter((s) => /reply stop|unsubscribe/i.test(s.bodyTemplate));\n eq(inTemplates.map((s) => s.id), [], \"templates that had furniture written into them:\");\n return \"0 templates edited; furniture lives only in renderStep\";\n });\n\n\nconsole.log(\"\\n=== G. THE ADVERSARIAL FIXES (v1.4) ===\\n\");\nconst src14 = readFileSync(new URL(\"../engine/puppy_path_v1.1.ts\", import.meta.url), \"utf8\");\n\nt(\"G1 a contact whose next message is not due costs zero API calls\",\n \"R19b — three calls per contact per run is ~9,600 requests and ~45 min at backlog scale\",\n () => {\n const i = src14.indexOf(\"const dueCheck\");\n const io = src14.indexOf(\"const contact = await getContact(contactId);\", i);\n ok(i > 0, \"due-first filter missing\");\n ok(src14.indexOf(\"continue; // zero API calls\", i) < io, \"the skip does not come before the first API call\");\n return \"due-check precedes every per-contact read; O(due) not O(enrolled)\";\n });\n\nt(\"G2 the cheap path still gets a full check at least daily\",\n \"cheaper must never mean blinder — exits would go stale otherwise\",\n () => {\n ok(/safetySweepHours/.test(src14), \"no safety sweep\");\n ok(/sweepOverdue/.test(src14), \"sweep not applied\");\n return \"SAFETY_SWEEP_HOURS default 24 — every contact fully checked at least once a day\";\n });\n\nt(\"G3 an outbound message can no longer hide a customer's reply\",\n \"R21 — Chloe, Ava and 165 workflows all send; any one of them flipped the field and unblocked a send\",\n () => {\n ok(/unreadCount/.test(src14), \"unreadCount not consulted\");\n const ob = src14.indexOf('if (direction === \"outbound\")');\n const un = src14.indexOf(\"unread > 0\", ob);\n ok(un > ob && un - ob < 400, \"unread is not checked on the outbound branch\");\n return \"unread thread blocks a send even when the newest message is outbound\";\n });\n\nt(\"G4 a reply nobody answers is escalated, not held forever\",\n \"R22 — paused_reply was absorbing, so the most engaged leads became the ones nothing happened to\",\n () => {\n ok(/pauseTimeoutDays/.test(src14), \"no pause timeout\");\n ok(/pause_timeout/.test(src14), \"no journal row for the timeout\");\n ok(/done_hard_exit/.test(src14.slice(src14.indexOf(\"pauseTimeoutDays()\"), src14.indexOf(\"pauseTimeoutDays()\") + 1800)), \"does not release the contact\");\n return \"PAUSE_TIMEOUT_DAYS default 14 — raises a second task, then releases\";\n });\n\nt(\"G5 the money is captured at the moment of exit\",\n \"R24 — the engine read monetaryValue on every opportunity and threw it away, while the client judges reports on revenue\",\n () => {\n ok(/exitValue/.test(src14), \"exitValue not stored\");\n ok(/exitStepsSent/.test(src14), \"steps-to-conversion not stored\");\n const he = src14.lastIndexOf('case \"hard_exit\": {');\n ok(src14.indexOf(\"pickPrimaryOpportunity(opportunities)?.monetaryValue\", he) > he, \"value not read at exit\");\n return \"exitValue + exitStepsSent recorded on every exit and journalled\";\n });\n\nt(\"G6 editing the copy cannot silently re-point in-flight contacts\",\n \"R23 — position is an array index; inserting a message shifts everyone mid-sequence with no signal\",\n () => {\n ok(/lastSentStepId/.test(src14), \"step id not recorded\");\n ok(/SEQUENCE DRIFT/.test(src14), \"no drift detection\");\n return \"step id stored per send; drift logged and journalled on the next send\";\n });\n\nconsole.log(\"\\n=== H. COLLISION WITH THE REST OF THE ACCOUNT (v1.5, R27) ===\\n\");\n\n// Why this section exists: the location runs 95 PUBLISHED GoHighLevel workflows, several of which are\n// nurtures, plus Chloe on voice and Ava on social. GoHighLevel exposes no way to read which workflows\n// a contact is enrolled in, so the only detectable signal is an outbound message on the thread that\n// this engine did not send. These tests pin the behaviour that follows from that signal.\n\nt(\"H1 a message from another system defers our send\",\n \"a GHL workflow, Chloe or Ava texting someone must not be followed by our email an hour later\",\n () => {\n const now = at(\"2026-08-03T15:00:00Z\");\n const d = E.decideAction(\n baseFacts({ now, foreignOutboundAt: now - 1 * 60 * 60 * 1000 }),\n { ...stateMain(), enteredAt: \"2026-08-01T12:00:00Z\" },\n );\n ok(d.kind !== \"send\", `engine chose to ${d.kind} one hour after another system messaged them`);\n ok(/quiet period/i.test(d.reason || \"\"), `deferred for the wrong reason: ${d.reason}`);\n return `foreign send 1h ago -> ${d.kind}: ${d.reason}`;\n });\n\nt(\"H2 the quiet period expires — it defers, it does not cancel\",\n \"a deferred step must still go out; a collision guard that silently drops messages is worse than none\",\n () => {\n const now = at(\"2026-08-03T15:00:00Z\");\n const d = E.decideAction(\n baseFacts({ now, foreignOutboundAt: now - 25 * 60 * 60 * 1000 }),\n { ...stateMain(), enteredAt: \"2026-08-01T12:00:00Z\" },\n );\n eq(d.kind, \"send\", \"step did not resume after the quiet period elapsed\");\n return `foreign send 25h ago -> ${d.kind} (resumes)`;\n });\n\nt(\"H3 our own send is not mistaken for somebody else's\",\n \"the guard must not deadlock the engine against its own last message\",\n () => {\n const now = at(\"2026-08-03T15:00:00Z\");\n // foreignOutboundAt is null here by construction — the run loop resolves ours-vs-theirs before\n // decideAction sees it. This pins that a null means \"carry on\" rather than \"block\".\n const d = E.decideAction(\n baseFacts({ now, foreignOutboundAt: null }),\n { ...stateMain(), enteredAt: \"2026-08-01T12:00:00Z\" },\n );\n eq(d.kind, \"send\", \"a null foreign-outbound blocked the send\");\n return \"null foreign-outbound -> send\";\n });\n\nt(\"H4 an unanswered human still outranks the quiet period\",\n \"collision politeness must never demote the rule that protects a real conversation\",\n () => {\n const now = at(\"2026-08-03T15:00:00Z\");\n const d = E.decideAction(\n baseFacts({ now, foreignOutboundAt: now - 1 * 60 * 60 * 1000, hasUnansweredInboundReply: true }),\n { ...stateMain(), enteredAt: \"2026-08-01T12:00:00Z\" },\n );\n eq(d.kind, \"pause_reply\", \"reply handling was displaced by the collision guard\");\n return \"reply + foreign send -> pause_reply (rule 5 still wins)\";\n });\n\nt(\"H5 the guard is wired into the send gate, not bolted on after it\",\n \"a check that runs after the send decision is decoration\",\n () => {\n const src = readFileSync(new URL(\"../engine/puppy_path_v1.1.ts\", import.meta.url), \"utf8\");\n const gate = src.indexOf(\"const sendGate =\");\n const guard = src.indexOf(\"f.foreignOutboundAt != null\");\n const ret = src.indexOf(\"return { ok: true, reason: \\\"\\\" };\", gate);\n ok(gate > -1 && guard > -1 && ret > -1, \"sendGate, guard or its terminator not found\");\n ok(guard > gate && guard < ret, `guard sits outside the send gate (gate ${gate}, guard ${guard}, end ${ret})`);\n return `guard at char ${guard}, inside sendGate (${gate}..${ret})`;\n });\n\nt(\"H6 the collision check costs no extra API call\",\n \"an outbound timestamp must ride on the reply-check request the engine already makes\",\n () => {\n const src = readFileSync(new URL(\"../engine/puppy_path_v1.1.ts\", import.meta.url), \"utf8\");\n const fn = src.slice(src.indexOf(\"async function getReplyStatus\"), src.indexOf(\"// ---- IO layer: GHL writes\"));\n eq((fn.match(/await j\\(/g) || []).length, 1, \"getReplyStatus makes more than one request\");\n ok(fn.includes(\"lastOutboundAt\"), \"getReplyStatus does not return the outbound timestamp\");\n return \"one request, returns both the reply status and the outbound timestamp\";\n });\n\nconsole.log(\"\\n=== I. PER-CHANNEL CONSENT (v1.6, R28) ===\\n\");\n\n// Live data on this location proves dndSettings is per-channel and that a contact can be opted out\n// of texts while the top-level dnd flag stays false. These pin that the engine now reads it.\n\nt(\"I1 an SMS opt-out stops the text but not the email\",\n \"someone who said stop to texts has not asked us to stop emailing, and vice versa\",\n () => {\n const st = { ...E.freshState(\"2026-08-01T12:00:00Z\"), status: \"main\", lastMainStepSent: 1 }; // next is main-2, an SMS\n eq(E.MAIN_SEQUENCE[1].channel, \"sms\", \"test assumes main-2 is the SMS\");\n const blocked = E.decideAction(baseFacts({ channelBlocked: { email: false, sms: true } }), st);\n eq(blocked.kind, \"skip_step\", `SMS opt-out produced ${blocked.kind}`);\n const allowed = E.decideAction(baseFacts({ channelBlocked: { email: true, sms: false } }), st);\n eq(allowed.kind, \"send\", \"an EMAIL opt-out wrongly blocked an SMS step\");\n return \"sms blocked -> skip_step; email blocked -> sms still sends\";\n });\n\nt(\"I2 a blocked step is consumed, not deferred forever\",\n \"deferring a message that can never legally send would stall that contact on it for good\",\n () => {\n const st = { ...E.freshState(\"2026-08-01T12:00:00Z\"), status: \"main\", lastMainStepSent: 1 };\n const d = E.decideAction(baseFacts({ channelBlocked: { email: false, sms: true } }), st);\n const next = E.applyDecision(d, st, \"2026-08-03T15:00:00Z\");\n eq(next.lastMainStepSent, 2, \"the blocked step was not consumed — the contact would stall\");\n eq(next.lastSentAt, null, \"a step that never sent started the send-pacing clock\");\n return \"counter advanced 1 -> 2, lastSentAt untouched\";\n });\n\nt(\"I3 ACTIVE means do-not-disturb is ON, so it blocks\",\n \"GHL names these after the DND switch, not the person. Live 10 Aug: 55 contacts carry SMS status active with TWILIO_ERROR_CODE 30006, and every channel on a workflow-DND'd contact reads active. The old code read active as PERMISSION and would have messaged all of them.\",\n () => {\n const c = { dndSettings: { SMS: { status: \"active\", message: \"TWILIO_ERROR_CODE: 30006\" }, Email: { status: \"active\", message: \"Updated from workflow_c6fc2df4\" } } };\n const r = E.readChannelConsent(c);\n eq(r.sms, true, \"an active SMS DND was read as permission to text\");\n eq(r.email, true, \"an active Email DND was read as permission to email\");\n return \"active -> blocked on both channels\";\n });\n\nt(\"I3b INACTIVE means do-not-disturb is OFF, so it sends\",\n \"Kristina Gant, the ONLY contact tagged for this sequence, is dnd:false with Email/SMS/Call all inactive. The old code read inactive as BLOCKED, so go-live would have consumed all eight steps as skips and reported enrolled:1 sent:0 failed:0, which reads exactly like success.\",\n () => {\n const c = { dnd: false, dndSettings: { Email: { status: \"inactive\", code: \"103\", message: \"Updated by contact merge\" }, SMS: { status: \"inactive\", code: \"103\", message: \"Updated by contact merge\" }, Call: { status: \"inactive\", code: \"103\", message: \"Updated by contact merge\" } } };\n const r = E.readChannelConsent(c);\n eq(r.sms, false, \"a contactable person was refused: this is the silent-launch failure\");\n eq(r.email, false, \"a contactable person was refused on email\");\n return \"inactive -> free to contact\";\n });\n\nt(\"I3c PERMANENT is a real human opt-out and an unknown status fails CLOSED\",\n \"25 live contacts carry SMS or RCS permanent with STOP_KEYWORD. And a status this code has never seen must block, never send.\",\n () => {\n eq(E.readChannelConsent({ dndSettings: { SMS: { status: \"permanent\", message: \"STOP_KEYWORD\" } } }).sms, true, \"a STOP reply was not honoured\");\n eq(E.readChannelConsent({ dndSettings: { SMS: { status: \"some_new_state_ghl_invented\" } } }).sms, true, \"an unrecognised status was treated as permission to send\");\n eq(E.readChannelConsent({ dndSettings: { RCS: { status: \"permanent\", message: \"STOP_KEYWORD\" } } }).sms, true, \"RCS is text to the recipient and must block SMS too\");\n eq(E.readChannelConsent({}).sms, false, \"a contact with no dndSettings was blocked\");\n eq(E.readChannelConsent({ dndSettings: { SMS: { status: \"\" } } }).sms, false, \"an empty status is not a per-channel opt-out\");\n return \"permanent and unknown block; absent and empty do not\";\n });\n\nt(\"I6 a contact with NO EMAIL ADDRESS skips email steps deliberately, and the log says why\",\n \"2 of the 3 contacts tagged for go-live carry a phone and no email, and the first message in the sequence is an email. Without this guard the send 4xxs, state stays untouched, and it retries every hour forever.\",\n () => {\n const st = { ...E.freshState(\"2026-08-01T12:00:00Z\"), status: \"main\", lastMainStepSent: 0 };\n // main-1 is an email at offset 0, so it is due immediately\n const d = E.decideAction(baseFacts({ contact: { id: \"c1\", firstName: \"Lisa\", companyName: null, dnd: false, noEmail: true } }), st);\n eq(d.kind, \"skip_step\", `a contact with no email produced ${d.kind}: the send would 4xx and retry hourly forever`);\n ok(/no email address on the record/.test(d.reason), \"the journal reason must name ABSENCE, not blame an opt-out the person never made\");\n ok(!/opted out/.test(d.reason), \"absence logged as an opt-out misinforms whoever reads the log\");\n return \"no email -> deliberate skip_step with the true reason\";\n });\n\nt(\"I6b the same contact WITH an email sends: both polarities proven by calling it\",\n \"LESSONS.md entry 4: never trust a predicate without testing both polarities.\",\n () => {\n const st = { ...E.freshState(\"2026-08-01T12:00:00Z\"), status: \"main\", lastMainStepSent: 0 };\n const d = E.decideAction(baseFacts({ contact: { id: \"c1\", firstName: \"Lisa\", companyName: null, dnd: false, noEmail: false } }), st);\n eq(d.kind, \"send\", `a contact with an email produced ${d.kind}`);\n return \"has email -> send\";\n });\n\nt(\"I4 a contact with no dndSettings at all is not blocked\",\n \"most contacts carry no per-channel record; absence must mean 'no opt-out', never 'blocked'\",\n () => {\n const st = { ...E.freshState(\"2026-08-01T12:00:00Z\"), status: \"main\", lastMainStepSent: 0 };\n const d = E.decideAction(baseFacts({ channelBlocked: { email: false, sms: false } }), st);\n eq(d.kind, \"send\", `an unblocked contact produced ${d.kind}`);\n return \"no dndSettings -> send\";\n });\n\nt(\"I5 the top-level dnd flag still stops everything\",\n \"per-channel handling must not weaken the blanket opt-out\",\n () => {\n const d = E.decideAction(\n baseFacts({ contact: { id: \"c1\", firstName: \"Ann\", companyName: null, dnd: true },\n channelBlocked: { email: false, sms: false } }),\n stateMain(),\n );\n eq(d.kind, \"hard_exit\", `blanket dnd produced ${d.kind}`);\n return \"dnd=true -> hard_exit (unchanged)\";\n });\n\nconsole.log(`\\n=== RESULT: ${pass} passed, ${fail} failed ===\\n`);\nimport { writeFileSync, mkdirSync } from \"node:fs\";\n// MAKE THE DIRECTORY BEFORE WRITING INTO IT. [was: a bare writeFileSync into ../logs/, and nothing\n// in this repo ever creates logs/ — not the build, not restore.mjs, not the bundle (it holds no\n// empty directories). So every run of this file ended in an ENOENT stack trace AFTER printing its\n// result line, which is the same defect class as the missing derived PDF: a tool that assumes a\n// path its own tooling never produces. recursive:true is idempotent, so this is safe to re-run.]\nmkdirSync(new URL(\"../logs/\", import.meta.url), { recursive: true });\nwriteFileSync(new URL(\"../logs/harness-result.json\", import.meta.url), JSON.stringify({ ts: new Date().toISOString(), pass, fail, results }, null, 2));\nprocess.exit(fail ? 1 : 0);\n\n\n","THE DOGS SPOT — SOURCE BUNDLE (part 18 of 47)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (1 of 129 files)\n\n\n================================================================================================\n=====FILE tests/dashboard.test.mjs#1 =====\n// THE DASHBOARD'S PROMISES. v2.0, 5 Aug 2026.\n// Most of this is deliberately hostile, because the page's whole claim is \"always renders something\n// true\". Every D2b case is a real defect a stranger caught, pinned so it cannot return.\nimport * as W from \"../build/worklog.js\";\nimport * as DASH from \"../build/dashboard.js\";\nimport * as H from \"../build/holiday-deposits.js\";\nimport * as DEC from \"../build/decisions.js\";\nimport * as API from \"../build/api.js\";\nimport { readFileSync } from \"node:fs\";\nimport { suite, ok, eq, scoped, codeOnly } from \"./_harness.mjs\";\nconst { t, done, header } = suite(\"dashboard\");\nconst MONTHS_D = [\"Jan\", \"Feb\", \"Mar\", \"Apr\", \"May\", \"Jun\", \"Jul\", \"Aug\", \"Sep\", \"Oct\", \"Nov\", \"Dec\"];\nconst prettyDate = (iso) => {\n const m = /^(\\d{4})-(\\d{2})-(\\d{2})/.exec(iso || \"\");\n return m ? `${MONTHS_D[Number(m[2]) - 1] ?? m[2]} ${Number(m[3])}` : iso;\n};\n// EVERY structural assertion below reads `src`, and `src` is the file with its comments removed.\n// A `[was: ...]` note that names the old call is not evidence that the old call is gone.\n// [was: the raw file. On 5 Aug the check `observedCadenceMin(wd?.history)` passed on a comment\n// explaining why that call had been removed. The green was real; the guarantee was not.]\nconst rawSrc = readFileSync(new URL(\"../engine/dashboard.ts\", import.meta.url), \"utf8\");\nconst src = codeOnly(rawSrc);\nconst rawApiSrc = readFileSync(new URL(\"../engine/api.ts\", import.meta.url), \"utf8\");\nconst apiSrc = codeOnly(rawApiSrc);\n\nheader(\"THE HOLIDAY DEPOSIT CARD\");\n\n// A real-shaped blob. Every string in it is what the collector actually produces.\nconst DEPBLOB = {\n // RELATIVE TO NOW, deliberately. [was: a hardcoded timestamp, which the stale-list banner\n // (fires past 36 hours of real elapsed time) would have turned red on 8 August with no code\n // change at all — the entire regression net going permanently RED on the wall clock.]\n at: new Date(Date.now() - 60_000).toISOString(), season: 2026,\n windows: [{ name: \"Thanksgiving\", from: \"2026-11-23\", to: \"2026-11-29\" },\n { name: \"Christmas and New Year\", from: \"2026-12-20\", to: \"2027-01-02\" }],\n rows: [\n { contactId: \"a\", name: \"Jeffrey Musselwhite\", day: \"2026-11-25\", until: \"2026-11-28\", dogs: [\"Achilles\", \"Ghost\"], dogCount: 2, window: \"Thanksgiving\",\n state: \"seen\", amountSeen: 100, note: \"A card payment for exactly $100.00 is on file on Oct 5, which is the deposit for 2 dogs.\" },\n { contactId: \"b\", name: \"Ann Flu\", day: \"2027-01-01\", until: \"2027-01-01\", dogs: [\"Fluffy\"], dogCount: 1, window: \"Christmas and New Year\",\n state: \"none_seen\", amountSeen: 0, note: \"The deposit on this stay is $50.00 (1 dog at $50) and no card payment is on file around it at all. A deposit paid by Venmo, Zelle, cheque or cash does not reach the card system, so it will not show here.\" },\n { contactId: \"c\", name: \"Reid Fail\", day: \"2026-11-24\", until: \"2026-11-24\", dogs: [], dogCount: 1, window: \"Thanksgiving\",\n state: \"could_not_check\", amountSeen: 0, note: \"We could not read this person's payments just now, so this one is unknown. It is not a finding either way.\" },\n ],\n // GENERATED, not typed. [was: a hardcoded sentence carrying pre-round-6 copy, so D5.4's\n // Venmo/Zelle assertion was satisfied by the fixture rather than by anything the code produces.]\n sentence: H.depositSentence([{ state: \"seen\" }, { state: \"none_seen\" }, { state: \"could_not_check\" }], false),\n feedDead: false, readFailures: 1, calendarsRead: 2, calendarsAsked: 2, pickupsRead: 2, pickupsAsked: 2,\n};\nconst noAgo = () => \"just now\";\n\nt(\"D5.1 a failed read of the list is a reading problem, never a finding about a customer\", () => {\n const h = DASH.depositCard(null, false, noAgo);\n ok(/could not read/i.test(h), \"a failed read does not say so\");\n ok(!/holiday stays are booked|worth checking/i.test(h), \"a failed read produced a list anyway\");\n ok(!/\\bunpaid\\b|owes|has not paid/i.test(h));\n return scoped(3, \"guarantees\");\n});\n\nt(\"D5.2 nothing collected yet says exactly that, and does not read as nobody has paid\", () => {\n const h = DASH.depositCard(null, true, noAgo);\n // [was: /Nothing collected yet/. Under a heading that reads \"Holiday deposits\", the words\n // \"Nothing collected yet\" are a sentence about MONEY — you have taken no deposits — when the\n // fact being reported is about the report: it has not run. Same three words, opposite meaning,\n // and the wrong one is the reassuring-looking zero this whole card exists not to print.]\n ok(/has not run yet/i.test(h), \"the empty state does not say plainly that the check has not run\");\n ok(!/collected/i.test(h), \"the empty state still reads as a statement about money taken\");\n ok(!/\\bunpaid\\b|owes|has not paid|0 holiday/i.test(h));\n return scoped(3, \"guarantees\");\n});\n\nt(\"D5.3 the jobs to do come first and the settled ones last\", () => {\n const h = DASH.depositCard(DEPBLOB, true, noAgo);\n const i = (s) => h.indexOf(s);\n ok(i(\"Ann Flu\") < i(\"Reid Fail\"), \"an unknown row outranks a stay actually worth checking\");\n ok(i(\"Reid Fail\") < i(\"Jeffrey Musselwhite\"), \"a settled row is above one that could not be checked\");\n return scoped(3, \"rows\");\n});\n\nt(\"D5.4 the word unpaid, and every accusation like it, never reaches this card\", () => {\n const h = DASH.depositCard(DEPBLOB, true, noAgo);\n // WIDER THAN IT WAS. [was: /unpaid|owes|has not paid|did not pay|non-payment/, which let the\n // most natural phrasing of the forbidden thing straight through: relabelling a row \"Not paid\"\n // shipped with every suite green.]\n // AND WIDER AGAIN, for the COLLECTIVE form. [was: every alternative named a single person. The\n // natural way to write the forbidden claim about a group names nobody at all: \"Nobody below has\n // paid a deposit.\" That went through untouched, and the dead-feed branch is exactly where\n // somebody would add it, because that branch already talks about everyone at once.]\n // AND WIDER A THIRD TIME, after an adversarial pass wrote 45 accusations that walked straight\n // through version two. The pattern in the misses: this regex had a vocabulary of REFUSAL\n // (\"failed to pay\", \"never paid\") and none of ABSENCE (\"no payment has been received\") or of\n // INVOICING (\"overdue\", \"past due\", \"balance due\", \"delinquent\") — and invoicing is the register\n // somebody reaches for first when they think they are being helpful. Two misses were pure\n // inflection: `owes?` matched \"owe\"/\"owes\" but not \"owed\"/\"owing\"; `hasn.t paid` matched only\n // the third person singular, so \"they haven't paid\" and \"he hadn't paid\" both passed.\n const ACCUSATION = new RegExp([\n /\\bunpaid\\b|\\bow(?:e|es|ed|ing)\\b|\\bnot paid\\b|\\bnever paid\\b|\\b(?:has|have|had)n.t paid\\b/,\n /\\bdid ?n.t pay\\b|\\bfailed to pay\\b|\\brefus\\w* to pay\\b|\\bwon.t pay\\b|\\bdeclined to pay\\b/,\n /non-?payment|\\boutstanding\\b|\\bin arrears\\b|\\bdebt\\b|\\bdelinquent\\b|\\bover-?due\\b|\\bpast due\\b/,\n /\\bbalance due\\b|\\bamount due\\b|\\bin default\\b|\\bbehind on\\b|\\bchas(?:e|ing)\\b|\\$[\\d,.]+\\s+due\\b/,\n // The collective forms: an accusation that names nobody at all.\n /\\b(?:nobody|no-? ?one|none|not one|not a single \\w+)\\b[^.]{0,40}?\\b(?:pa(?:id|ys?)|sent|settled)\\b/,\n // The same claim as a score. \"0 of 3 have paid\" names nobody and accuses everybody.\n /\\b\\d+ of (?:the |your )?\\d+\\b[^.]{0,40}?\\b(?:pa(?:id|ys?)|sent|settled)\\b/,\n // And absence-of-money phrased as a finding rather than as a limit of what we can see.\n /\\bno (?:payment|money|deposit|funds?)\\b[^.]{0,30}?\\b(?:received|come in|arrived)\\b/,\n ].map((r) => r.source).join(\"|\"), \"i\");\n // The only sentences allowed to use this language are the ones that DENY the accusation. They\n // are removed by exact text before scanning, and each is asserted PRESENT, so neither can be\n // quietly deleted to make room for a real one — a scrub whose target has vanished is a scrub\n // that protects nothing while still reading as a safeguard.\n const DISCLAIMER = \"This is a shortlist to look at rather than a list of people who owe you.\";\n const FEED_DENIAL = \"rather than that nobody has paid\";\n const DENIALS = [DISCLAIMER, FEED_DENIAL];\n // NORMALISED BEFORE ANY OF IT IS APPLIED. Round 15 got \"Jeffrey has not\\u00A0paid his deposit.\"\n // past the whole regex with ONE non-breaking space: a JS regex literal space matches U+0020 and\n // nothing else, so a single invisible character defeated every two-word and three-word\n // alternative at once — not paid, past due, balance due, amount due, in default, behind on, the\n // contraction forms. Ten of roughly twenty-five alternatives, invisibly, and it renders\n // identically to a space on Kim's phone. Non-breaking and zero-width characters are folded to\n // ordinary spaces and runs of whitespace collapsed, so the regex sees the sentence a reader sees.\n const flatten = (x) => String(x).replace(/[\\u00A0\\u2007\\u202F\\u2000-\\u200B\\uFEFF]/g, \" \").replace(/\\s+/g, \" \");\n const scrub = (x) => DENIALS.reduce((s, d) => s.split(d).join(\" \"), flatten(x));\n ok(h.includes(DISCLAIMER), \"the card dropped the sentence that says this is not a list of people who owe her money\");\n const deadSentence = H.depositSentence([{ state: \"none_seen\" }, { state: \"none_seen\" }], true);\n ok(deadSentence.includes(FEED_DENIAL), `the dead-feed sentence no longer denies the accusation, so scrubbing it guards nothing: ${deadSentence}`);\n ok(!ACCUSATION.test(scrub(h)), \"the card accuses somebody of not paying\");\n // AND ON GENERATED NOTES, not the hand-typed fixture ones. [was: DEPBLOB's notes are typed\n // strings, so this scanned my own prose rather than anything the code produces. Appending\n // \", so they still owe this one.\" to the already-counted branch reached Kim with the suite\n // green, despite \"owes?\" being in the ban.]\n const st = (day) => ({ contactId: \"c\", day, until: day, dogs: [\"R\"], dogCount: 1, bookedAt: \"2026-11-01 09:00:00\", window: \"W\" });\n const generated = [\n ...H.statusesForCustomer([st(\"2026-11-25\"), st(\"2026-12-22\")], [{ amount: 50, id: \"a\", at: \"2026-11-20T00:00:00Z\", kind: \"direct\" }]),\n H.statusFor(st(\"2026-11-25\"), null),\n H.statusFor(st(\"2026-11-25\"), []),\n H.statusFor(st(\"2026-11-25\"), [{ amount: 355, id: \"b\", at: \"2026-11-20T00:00:00Z\", kind: \"direct\" }]),\n H.statusFor({ ...st(\"2026-11-25\"), bookedAt: null }, []),\n ];\n ok(generated.length >= 5, \"no notes were generated, so this check inspected nothing\");\n for (const g of generated) {\n ok(!ACCUSATION.test(scrub(g.note)), `a generated note accuses somebody: ${g.note}`);\n const card = DASH.depositCard({ ...DEPBLOB, rows: [{ ...DEPBLOB.rows[0], state: g.state, note: g.note }] }, true, noAgo);\n ok(!ACCUSATION.test(scrub(card)), `a generated note accuses somebody once rendered: ${g.note}`);\n }\n\n // AND ACROSS THE CARD'S CONDITIONAL STRINGS, which a single healthy fixture never renders.\n // [was: every card scanned here was a spread of DEPBLOB, which hardcodes 2/2 calendars, 2/2\n // pick-ups, feedDead:false and a name that is not a test record. So FOUR strings were never\n // examined at all — the missed-calendar banner, the pick-up banner, the test-record warning and\n // the dead-feed sentence — and the banned words themselves went through them: \"those deposits\n // are unpaid\", \"those deposits are outstanding\", \"This one has not paid\", \"Nobody below has\n // paid a deposit\". Every combination is rendered now.]\n const testRow = { ...DEPBLOB.rows[0], name: \"help test\", state: \"none_seen\", note: H.statusFor(st(\"2026-11-25\"), []).note };\n const shapes = [];\n for (const calendars of [[2, 2], [1, 2], [0, 2]]) {\n for (const pickups of [[2, 2], [1, 2]]) {\n for (const feedDead of [false, true]) {\n for (const readFailures of [0, 2]) {\n for (const rows of [[testRow], [{ ...testRow, state: \"could_not_check\" }], DEPBLOB.rows, []]) {\n for (const ageMs of [60_000, 5 * 86_400_000]) {\n shapes.push({\n ...DEPBLOB, rows, feedDead, readFailures,\n calendarsRead: calendars[0], calendarsAsked: calendars[1],\n pickupsRead: pickups[0], pickupsAsked: pickups[1],\n at: new Date(Date.now() - ageMs).toISOString(),\n sentence: H.depositSentence(rows.map((r) => ({ state: r.state })), feedDead),\n });\n }\n }\n }\n }\n }\n }\n ok(shapes.length >= 100, `only ${shapes.length} card shapes were built, so this is not a sweep`);\n let renderedDeadFeed = 0;\n for (const shape of shapes) {\n const card = DASH.depositCard(shape, true, (x) => (Date.now() - Date.parse(x) > 86_400_000 ? \"5 days ago\" : \"just now\"));\n if (card.includes(FEED_DENIAL)) renderedDeadFeed++;\n ok(!ACCUSATION.test(scrub(card)),\n `a card accuses somebody: calendars ${shape.calendarsRead}/${shape.calendarsAsked}, pick-ups ${shape.pickupsRead}/${shape.pickupsAsked}, feedDead ${shape.feedDead}, ${shape.rows.length} rows`);\n }\n // The sweep must actually REACH the dead-feed sentence. Building 192 shapes proves nothing about\n // a branch none of them render, and this is the branch the whole widening above is aimed at.\n ok(renderedDeadFeed > 0, \"no card in the sweep rendered the dead-feed sentence, so that branch went unscanned\");\n // And the two states the card can be in besides \"here is a list\".\n for (const card of [DASH.depositCard(null, false, noAgo), DASH.depositCard(null, true, noAgo)]) {\n ok(!ACCUSATION.test(scrub(card)), \"the empty or unreadable card accuses somebody\");\n }\n ok(/Venmo, Zelle or a cheque/i.test(h), \"the card does not say a deposit may have been paid another way\");\n return scoped(shapes.length + generated.length * 2 + 7, \"rendered cards\");\n});\nt(\"D5.5 a customer whose payments could not be read is shown as unknown, not as nothing found\", () => {\n const h = DASH.depositCard(DEPBLOB, true, noAgo);\n ok(/Could not check/.test(h), \"an unreadable customer is not labelled as such\");\n ok(/could not be checked when this ran/i.test(h), \"the count of unknown rows is not stated\");\n return scoped(2, \"guarantees\");\n});\n\nt(\"D5.6 a calendar that did not answer is declared, so the list is not read as complete\", () => {\n const partial = { ...DEPBLOB, calendarsRead: 1, calendarsAsked: 2 };\n ok(/Not the whole picture/.test(DASH.depositCard(partial, true, noAgo)));\n ok(!/Not the whole picture/.test(DASH.depositCard(DEPBLOB, true, noAgo)), \"the warning shows when nothing is missing\");\n return scoped(2, \"cases\");\n});\n\nt(\"D5.7 a customer's name is escaped before it reaches the page\", () => {\n const nasty = { ...DEPBLOB, rows: [{ ...DEPBLOB.rows[0], name: '', note: \"hi\" }] };\n const h = DASH.depositCard(nasty, true, noAgo);\n ok(!/`}\n\n

${d.journalTotal <= entriesShown && groups.length <= RECENT_ROWS ? \"Everything it has done so far\" : \"What it has been doing\"}

\n${rows}

When	What	Detail

${rowsNote}

\n\n${d.lastError && d.lastError.at && Date.now() - new Date(d.lastError.at).getTime() < 24 * 3600 * 1000 ? `

Something went wrong in the last 24 hours

Technical details for whoever fixes it, if this box is showing, tell Amir and include what is below.

${esc(JSON.stringify(d.lastError).slice(0, 1200))}

` : \"\"}\n\n\n

${d.engineVersion\n ? `The follow-up system reported itself as version ${esc(d.engineVersion)} on its last check${d.lastRunAgeMin == null ? \"\" : d.lastRunAgeMin === 1 ? \", 1 minute ago\" : `, ${d.lastRunAgeMin} minutes ago`}. That is read from its own record, not typed on this page, so it is the version that actually ran.`\n : d.runReadOk\n ? \"The follow-up system has not recorded a version yet, so this page cannot tell you which one is running.\"\n : \"This page could not read the follow-up system's record just now, so it cannot tell you which version is running.\"} The numbers above were read fresh when this page opened.

\n`;\n}\n\n// ---- live self-test ------------------------------------------------------------------------------\n// Resolves the CRM credential exactly the way the engine does (env var first, then the puppy_config\n// blob) and pings the four endpoints the engine depends on. Reports status codes only, the token is\n// never returned, logged, or echoed. This exists because a stale credential is the failure mode that\n// looks identical to \"quiet\": the scheduler keeps ticking, every read fails, and nothing tells anyone.\nconst GHL = \"https://services.leadconnectorhq.com\";\nconst LOC = \"BQHJ19uohldYe3eqA0bl\";\n\nasync function resolveEngineToken(): Promise<{ token?: string; from: string }> {\n const env = Deno.env.get(\"GHL_TOKEN\");\n if (env) return { token: env, from: \"env GHL_TOKEN\" };\n const cfg = await get(\"puppy_config\", null);\n if (cfg?.ghlToken) return { token: cfg.ghlToken, from: \"puppy_config blob\" };\n return { from: \"NOT FOUND\" };\n}\n\nasync function selfTest() {\n const { token, from } = await resolveEngineToken();\n const checks: any[] = [];\n const probe = async (name: string, url: string, ver: string, why: string) => {\n if (!token) return checks.push({ name, status: null, ok: false, why, note: \"no credential resolved\" });\n try {\n const r = await fetch(url, { headers: { Authorization: `Bearer ${token}`, Version: ver, Accept: \"application/json\" } });\n checks.push({ name, status: r.status, ok: r.status === 200, why });\n } catch (e) {\n checks.push({ name, status: null, ok: false, why, note: String(e).slice(0, 120) });\n }\n };\n await probe(\"read calendar bookings\", `${GHL}/calendars/events?locationId=${LOC}&calendarId=qHuYJ0NEqzibnoqf5Cw3&startTime=${Date.now() - 864e5}&endTime=${Date.now()}`, \"2021-04-15\", \"how it notices someone booked a Pup Talk\");\n await probe(\"read replies\", `${GHL}/conversations/search?locationId=${LOC}&limit=1`, \"2021-04-15\", \"how it pauses when someone writes back\");\n await probe(\"read contacts\", `${GHL}/contacts/?locationId=${LOC}&limit=1`, \"2021-07-28\", \"how it reads names and dog names\");\n await probe(\"read deals\", `${GHL}/opportunities/pipelines?locationId=${LOC}`, \"2021-07-28\", \"how it notices someone became a customer\");\n return { credentialFrom: from, allOk: checks.every((c) => c.ok), checks };\n}\n\nexport default async function (req: Request): Promise {\n const url = new URL(req.url);\n const k = url.searchParams.get(\"k\") || \"\";\n const isAdmin = await authorised(k);\n const isViewer = !isAdmin && (await viewAuthorised(k));\n if (!isAdmin && !isViewer) {\n return new Response(\"Not found\", { status: 401, headers: { \"content-type\": \"text/plain\" } });\n }\n if (isViewer) {\n // view key renders the dashboard only, no stop/go, no JSON, no selftest.\n const d = await collect();\n return new Response(page(d, k, { readonly: true }), {\n headers: { \"content-type\": \"text/html; charset=utf-8\", \"cache-control\": \"no-store\" },\n });\n }\n\n if (url.searchParams.get(\"selftest\") === \"1\") {\n return new Response(JSON.stringify(await selfTest(), null, 2), {\n headers: { \"content-type\": \"application/json\", \"cache-control\": \"no-store\" },\n });\n }\n\n // R37 (11 Aug 2026, go-live prep): remove one contact from engine state. Exists for exactly one\n // job: taking the ZZTEST dummy out before TEST_MODE flips, so live mode never sends its queued\n // steps (an unprefixed email to Amir, then an SMS to +10000000000 that fails on Kim's dashboard).\n // Admin-gated like stop/go. Returns counts so the caller has a receipt, not a hope.\n if (url.searchParams.get(\"prune\")) {\n const id = String(url.searchParams.get(\"prune\"));\n const blob = await blobMod();\n const st = ((await blob.getJSON(\"puppy_state\").catch(() => null)) ?? {}) as Record;\n const existed = Object.prototype.hasOwnProperty.call(st, id);\n delete st[id];\n await blob.setJSON(\"puppy_state\", st);\n return new Response(JSON.stringify({ pruned: id, existed, remaining: Object.keys(st).length }), {\n headers: { \"content-type\": \"application/json\", \"cache-control\": \"no-store\" },\n });\n }\n\n // R38: arm live / arm practice. Writes blob puppy_mode, which cron() reads at the top of every\n // pass. Exists because env vars are settable only in val.town's UI and that session is not always\n // available. Admin-gated. Practice is the fail-safe: only {live:true} arms.\n if (url.searchParams.get(\"arm\")) {\n const want = String(url.searchParams.get(\"arm\"));\n if (want !== \"live\" && want !== \"practice\") {\n return new Response(JSON.stringify({ error: \"arm must be live or practice\" }), { status: 400 });\n }\n const blob = await blobMod();\n await blob.setJSON(\"puppy_mode\", { live: want === \"live\", at: new Date().toISOString(), by: \"api-arm\" });\n const back = await blob.getJSON(\"puppy_mode\").catch(() => null);\n return new Response(JSON.stringify({ armed: want, blob: back }), {\n headers: { \"content-type\": \"application/json\", \"cache-control\": \"no-store\" },\n });\n }\n\n if (url.searchParams.get(\"stop\") === \"1\") {\n const blob = await blobMod();\n await blob.setJSON(KILL_BLOB, { stopped: true, at: new Date().toISOString(), by: \"control-panel\" });\n return Response.redirect(`${url.origin}${url.pathname}?k=${encodeURIComponent(k)}`, 303);\n }\n if (url.searchParams.get(\"go\") === \"1\") {\n const blob = await blobMod();\n await blob.setJSON(KILL_BLOB, { stopped: false, at: new Date().toISOString(), by: \"control-panel\" });\n return Response.redirect(`${url.origin}${url.pathname}?k=${encodeURIComponent(k)}`, 303);\n }\n\n const d = await collect();\n if (url.searchParams.get(\"f\") === \"json\") {\n return new Response(JSON.stringify(d, null, 2), {\n headers: { \"content-type\": \"application/json\", \"cache-control\": \"no-store\" },\n });\n }\n return new Response(page(d, k), {\n headers: { \"content-type\": \"text/html; charset=utf-8\", \"cache-control\": \"no-store\" },\n });\n}\n",[496],"c8e60570-62ed-4ca5-a907-54f2af5800f5","aged.ts","58225aaa-8e77-11f1-90c9-1607ee4eb77e",1149,["D",1786979114237],"// AGED-LIST SEGMENTER AND RELEASE PLANNER — built 2 Aug 2026.\n//\n// WHY THIS EXISTS\n// The plan of record was \"release the 3,206 dormant New Lead contacts by email, a few hundred a\n// week.\" Before building the machine, the audience was measured. It does not exist in the shape the\n// plan assumed:\n//\n// 3,426 opportunities sit in New Lead (not 3,206 — it grows ~12/day)\n// 177 (5.2%) have an email address\n// 766 (22.4%) have a phone number\n// 2,655 (77.5%) have NEITHER — they are Messenger-only contacts and cannot be emailed or texted\n//\n// Verified twice: once from the opportunity payload's embedded contact, then again by re-fetching\n// 25 of the \"no email\" contacts individually with GET /contacts/{id} — 0 of 25 had a hidden email.\n// So the email-only launch reaches 177 people, not three thousand.\n//\n// Age was also assumed wrong. Nothing in the backlog is older than 292 days; the oldest month is\n// October 2025 and only 328 rows are from 2025 at all. Median age is 109 days.\n//\n// This endpoint keeps that truth live rather than frozen in a document: it re-measures on demand,\n// segments the backlog by what can actually be done with each person, and produces the batch plan.\n//\n// WHAT IT WILL NOT DO\n// It never sends. It plans. Releasing anyone is a separate, deliberate act by a human, and the\n// copy for this path has not been approved by the client. `?k=…&plan=1` returns the batch list;\n// there is no endpoint here that hands that list to a sender.\n//\n// QUOTA (this is the R19 fix in miniature)\n// A full walk is 35 paginated calls. That is far too much to do on every 15-minute engine tick, so\n// the result is cached in the `aged_segments` blob with a timestamp and only recomputed when asked\n// or when older than CACHE_TTL. The engine never calls this; it is an operator tool.\n//\n// ?k= segment summary (cached)\n// ?k=&fresh=1 force a re-measure from the live CRM\n// ?k=&plan=1 the batch release plan\n// ?k=&f=json raw JSON of whichever of the above applies\n\nimport { hasConsentSnapshot, readChannelConsent } from \"./consent.ts\";\n\n// ---- auth ------------------------------------------------------------------------------------\n// val.town vals are public, so the admin digest must come from the environment. There is no source\n// fallback: absent or malformed configuration denies every key.\n\nasync function sha256Hex(s: string): Promise {\n const b = await crypto.subtle.digest(\"SHA-256\", new TextEncoder().encode(s));\n return [...new Uint8Array(b)].map((x) => x.toString(16).padStart(2, \"0\")).join(\"\");\n}\n\nasync function authorised(k: string): Promise {\n const configured = Deno.env.get(\"NURTURE_ADMIN_KEY_SHA256\");\n if (!k || !configured || !/^[0-9a-f]{64}$/i.test(configured)) return false;\n const expected = configured.toLowerCase();\n const got = await sha256Hex(k);\n // Constant-time over equal-length hex digests.\n if (got.length !== expected.length) return false;\n let d = 0;\n for (let i = 0; i < got.length; i++) d |= got.charCodeAt(i) ^ expected.charCodeAt(i);\n return d === 0;\n}\nconst GHL = \"https://services.leadconnectorhq.com\";\nconst LOC = \"BQHJ19uohldYe3eqA0bl\";\nconst PIPE = \"FXt1UpCVBufbF0v3pfyf\";\nconst NEW_LEAD = \"ccb18375-9aa1-40aa-a071-1581ca739533\";\nconst CACHE_KEY = \"aged_segments\";\nconst CACHE_TTL_MS = 12 * 3600 * 1000;\n\n// Batch policy. Email first, small, watching between batches — a burst to a stale list is how a\n// sending reputation dies, and this list is stale by construction.\nconst BATCH_SIZE = 60;\nconst BATCHES_PER_WEEK = 1;\n\nasync function blobMod() { return (await import(\"https://esm.town/v/std/blob\")).blob; }\n\n\nasync function token(): Promise {\n const env = Deno.env.get(\"GHL_TOKEN\");\n if (env) return env;\n const blob = await blobMod();\n const cfg = await blob.getJSON(\"puppy_config\").catch(() => null);\n return cfg?.ghlToken;\n}\n\nasync function walkNewLead() {\n const t = await token();\n if (!t) throw new Error(\"no CRM credential resolved\");\n const rows: any[] = [];\n let after: any = null, afterId: any = null, pages = 0;\n while (pages < 45) {\n let u = `${GHL}/opportunities/search?location_id=${LOC}&pipeline_id=${PIPE}&pipeline_stage_id=${NEW_LEAD}&limit=100`;\n if (after != null) u += `&startAfter=${after}&startAfterId=${afterId}`;\n const r = await fetch(u, { headers: { Authorization: `Bearer ${t}`, Version: \"2021-07-28\", Accept: \"application/json\" } });\n if (!r.ok) throw new Error(`opportunities/search ${r.status}`);\n const d = await r.json();\n const ops = d.opportunities ?? [];\n if (!ops.length) break;\n rows.push(...ops);\n pages++;\n after = d.meta?.startAfter; afterId = d.meta?.startAfterId;\n if (!after) break;\n }\n return { rows, pages };\n}\n\n// A lead nobody can reach is not a lead. A lead who only ever spoke on Messenger cannot be emailed or\n// texted at all — Meta's 24-hour messaging window closes that door, and pretending otherwise is how a\n// nurture plan produces a number that never arrives.\nexport function segmentAgedRows(rows: any[], now = Date.now()) {\n const seg: Record = {\n emailable: [], releaseReady: [], consentUnknown: [], emailBlocked: [],\n phoneOnly: [], unreachable: [], excluded: [],\n };\n const ageBuckets: Record = { \"0-30d\": 0, \"31-90d\": 0, \"91-180d\": 0, \"181-365d\": 0, \"365d+\": 0 };\n const years: Record = {};\n let dupes = 0;\n\n // Opportunity pagination can repeat a contact, and one copy can be a partial projection while\n // another carries DND. Hold every row whose contact id, email or phone occurs more than once;\n // choosing a \"first\" row would make consent depend on page order. The planner is deliberately\n // conservative here because this is release eligibility, not a marketing audience estimate.\n const identityCounts = new Map();\n const identityKeys = (o: any): string[] => {\n const c = o?.contact ?? {};\n const contactId = String(o?.contactId ?? c.id ?? \"\").trim();\n const email = String(c.email ?? \"\").trim().toLowerCase();\n const phone = String(c.phone ?? \"\").replace(/\\D/g, \"\");\n return [contactId && `id:${contactId}`, email && `email:${email}`, phone && `phone:${phone}`].filter(Boolean) as string[];\n };\n for (const o of rows) {\n for (const key of new Set(identityKeys(o))) identityCounts.set(key, (identityCounts.get(key) ?? 0) + 1);\n }\n\n for (const o of rows) {\n const c = o.contact ?? {};\n const email = String(c.email ?? \"\").trim().toLowerCase();\n const phone = String(c.phone ?? \"\").trim();\n const tags: string[] = (c.tags ?? []).map((x: string) => String(x).toLowerCase());\n const created = o.createdAt ? new Date(o.createdAt).getTime() : null;\n const ageDays = created ? Math.floor((now - created) / 86400000) : null;\n\n if (created) {\n const y = new Date(created).getUTCFullYear();\n years[y] = (years[y] ?? 0) + 1;\n const a = ageDays!;\n ageBuckets[a <= 30 ? \"0-30d\" : a <= 90 ? \"31-90d\" : a <= 180 ? \"91-180d\" : a <= 365 ? \"181-365d\" : \"365d+\"]++;\n }\n\n const contactId = String(o.contactId ?? c.id ?? \"\").trim();\n const rec = { contactId: contactId || null, name: c.name ?? null, email: email || null, phone: phone || null, ageDays, tags };\n\n // Exclusions come first and are absolute.\n const isSpam = tags.some((t) => t.includes(\"spam\"));\n const isCustomer = tags.includes(\"customer\") || tags.includes(\"subscription_active\");\n const alreadyOnAPath = tags.some((t) => t.startsWith(\"puppy-path\") || t.startsWith(\"path-\") || t.includes(\"nurture\"));\n if (isSpam || isCustomer || alreadyOnAPath) { seg.excluded.push({ ...rec, why: isSpam ? \"flagged spam\" : isCustomer ? \"already a customer\" : \"already on a nurture path\" }); continue; }\n\n const repeated = identityKeys(o).filter((key) => (identityCounts.get(key) ?? 0) > 1);\n if (repeated.length) {\n dupes++;\n seg.excluded.push({ ...rec, why: \"duplicate identity held; consent cannot depend on which API row arrived first\" });\n continue;\n }\n\n if (email) {\n // The opportunity projection can contain an email while omitting per-channel DND entirely.\n // Inventory may count that address; a release plan may not treat missing consent evidence as\n // permission. Only a hydrated snapshot that is clear on both surfaces reaches releaseReady.\n if (c.dnd === true || readChannelConsent(c).email) {\n const held = { ...rec, consentStatus: \"blocked\", why: c.dnd === true ? \"blanket Do Not Disturb is on\" : \"opted out of email\" };\n seg.emailable.push(held);\n seg.emailBlocked.push(held);\n } else if (!hasConsentSnapshot(c)) {\n const held = { ...rec, consentStatus: \"unknown\", why: \"per-channel consent was not present in this data projection\" };\n seg.emailable.push(held);\n seg.consentUnknown.push(held);\n } else {\n const clear = { ...rec, consentStatus: \"clear\" };\n seg.emailable.push(clear);\n seg.releaseReady.push(clear);\n }\n }\n else if (phone) seg.phoneOnly.push(rec);\n else seg.unreachable.push(rec);\n }\n\n // Oldest first: they have waited longest and are the least likely to remember enquiring, so they\n // are also the batch most worth watching the opt-out rate on.\n const oldestThenId = (a: any, b: any) =>\n (b.ageDays ?? 0) - (a.ageDays ?? 0) ||\n String(a.contactId ?? \"\").localeCompare(String(b.contactId ?? \"\")) ||\n String(a.email ?? \"\").localeCompare(String(b.email ?? \"\")) ||\n String(a.phone ?? \"\").localeCompare(String(b.phone ?? \"\")) ||\n String(a.why ?? \"\").localeCompare(String(b.why ?? \"\"));\n seg.emailable.sort(oldestThenId);\n seg.releaseReady.sort(oldestThenId);\n seg.consentUnknown.sort(oldestThenId);\n seg.emailBlocked.sort(oldestThenId);\n seg.phoneOnly.sort(oldestThenId);\n seg.unreachable.sort(oldestThenId);\n seg.excluded.sort(oldestThenId);\n\n return { seg, ageBuckets, years, dupes };\n}\n\nexport function planAgedBatches(emailable: any[]) {\n // Defence in depth: even a caller that hands this function the broad address inventory cannot\n // obtain a batch for an unknown/blocked row. Old cached records lack this marker and therefore hold.\n const candidates = (emailable ?? []).filter((r) => r?.consentStatus === \"clear\" && String(r?.contactId ?? \"\").trim());\n const counts = new Map();\n for (const r of candidates) {\n const id = String(r.contactId).trim();\n counts.set(id, (counts.get(id) ?? 0) + 1);\n }\n const eligible = candidates\n .filter((r) => counts.get(String(r.contactId).trim()) === 1)\n .sort((a, b) => (b.ageDays ?? 0) - (a.ageDays ?? 0) || String(a.contactId).localeCompare(String(b.contactId)));\n const batches: any[] = [];\n for (let i = 0; i < eligible.length; i += BATCH_SIZE) {\n batches.push({\n batch: batches.length + 1,\n weekOffset: batches.length * (1 / BATCHES_PER_WEEK),\n size: eligible.slice(i, i + BATCH_SIZE).length,\n oldestAgeDays: eligible[i]?.ageDays ?? null,\n contactIds: eligible.slice(i, i + BATCH_SIZE).map((r) => r.contactId),\n idempotencyKeys: eligible.slice(i, i + BATCH_SIZE).map((r) => `aged-plan:v1:${r.contactId}`),\n dryRun: true,\n sendAllowed: false,\n });\n }\n return batches;\n}\n\nasync function measure(fresh: boolean) {\n const blob = await blobMod();\n if (!fresh) {\n const cached = await blob.getJSON(CACHE_KEY).catch(() => null);\n if (cached?.at && Date.now() - new Date(cached.at).getTime() < CACHE_TTL_MS) return { ...cached, fromCache: true };\n }\n const { rows, pages } = await walkNewLead();\n const { seg, ageBuckets, years, dupes } = segmentAgedRows(rows);\n const out = {\n at: new Date().toISOString(),\n fromCache: false,\n apiCallsUsed: pages,\n total: rows.length,\n counts: {\n emailable: seg.emailable.length,\n releaseReady: seg.releaseReady.length,\n consentUnknown: seg.consentUnknown.length,\n emailBlocked: seg.emailBlocked.length,\n phoneOnly: seg.phoneOnly.length,\n unreachable: seg.unreachable.length,\n excluded: seg.excluded.length,\n duplicatesRemoved: dupes,\n },\n ageBuckets, years,\n batchPolicy: { size: BATCH_SIZE, perWeek: BATCHES_PER_WEEK, channel: \"email only\" },\n weeksToClear: Math.ceil(seg.releaseReady.length / (BATCH_SIZE * BATCHES_PER_WEEK)),\n emailable: seg.emailable,\n releaseReady: seg.releaseReady,\n consentUnknown: seg.consentUnknown.slice(0, 200),\n emailBlocked: seg.emailBlocked.slice(0, 200),\n phoneOnly: seg.phoneOnly.slice(0, 200),\n excludedSample: seg.excluded.slice(0, 50),\n };\n await blob.setJSON(CACHE_KEY, out).catch(() => {});\n return out;\n}\n\nfunction pct(n: number, d: number) { return d ? `${((n / d) * 100).toFixed(1)}%` : \"0%\"; }\n\nfunction html(d: any) {\n const c = d.counts;\n const rows = (d.batches ?? []).slice(0, 12).map((b: any) =>\n `${b.batch}week +${b.weekOffset}${b.size}${b.oldestAgeDays ?? \"—\"} days`).join(\"\");\n return `Aged list — what is actually there\n\n

The dormant list — what is actually in it

Measured from the live CRM ${d.fromCache ? \"(cached \" + String(d.at).slice(0, 16).replace(\"T\", \" \") + \" UTC)\" : \"just now\"} · ${d.apiCallsUsed ?? \"—\"} API calls

The plan assumed roughly 3,200 people who could be emailed. They cannot.\nOf ${d.total} contacts sitting in New Lead, ${c.emailable} have an email address —\n${pct(c.emailable, d.total)}. ${c.unreachable} (${pct(c.unreachable, d.total)}) have neither an email\nnor a phone number: they only ever spoke through Messenger, and Meta's 24-hour rule closes that door.

Who can actually be contacted

\n\n\n\n\n\n\n\n

Segment	Count	Share	What can be done
Has an email	${c.emailable}	${pct(c.emailable, d.total)}	Address inventory only; not permission to release.
Email + consent snapshot clear	${c.releaseReady ?? 0}	${pct(c.releaseReady ?? 0, d.total)}	The only rows allowed into the dry-run batch plan.
Email, consent unknown	${c.consentUnknown ?? c.emailable}	${pct(c.consentUnknown ?? c.emailable, d.total)}	Held until each full contact DND snapshot is read.
Email blocked / DND	${c.emailBlocked ?? 0}	${pct(c.emailBlocked ?? 0, d.total)}	Excluded from the release.
Phone only	${c.phoneOnly}	${pct(c.phoneOnly, d.total)}	SMS — held until numbers are validated. Stale numbers get a business flagged by carriers.
Neither	${c.unreachable}	${pct(c.unreachable, d.total)}	Nothing by email or text. Reachable only inside Messenger, within Meta's window.
Excluded	${c.excluded}	${pct(c.excluded, d.total)}	Already customers, already on a path, flagged spam, or duplicates.

How old it really is

\n${Object.entries(d.ageBuckets || {}).map(([k, v]) => ``).join(\"\")}

Age	Count
${k}	${v}

By year created: ${Object.entries(d.years || {}).map(([k, v]) => `${k} ${v}`).join(\" · \")}. Nothing in this list is more than a year old.

\n${rows ? `

The release plan

${rows}

Batch	When	People	Oldest in batch

${d.batchPolicy.size} per batch, ${d.batchPolicy.perWeek} batch per week, email only, oldest first — ${d.weeksToClear} week(s) across consent-cleared rows. Every row is dry-run only and carries sendAllowed:false.

` : \"\"}\n

Nothing here sends anything. This page measures and plans. Releasing a batch is a separate deliberate action, and the copy for this path has not been approved yet.

`;\n}\n\nexport default async function (req: Request): Promise {\n const url = new URL(req.url);\n if (!(await authorised(url.searchParams.get(\"k\") || \"\"))) {\n return new Response(\"Not found\", { status: 401, headers: { \"content-type\": \"text/plain\" } });\n }\n try {\n const d: any = await measure(url.searchParams.get(\"fresh\") === \"1\");\n if (url.searchParams.get(\"plan\") === \"1\") d.batches = planAgedBatches(d.releaseReady ?? []);\n if (url.searchParams.get(\"f\") === \"json\") {\n return new Response(JSON.stringify(d, null, 2), { headers: { \"content-type\": \"application/json\", \"cache-control\": \"no-store\" } });\n }\n if (!d.batches) d.batches = planAgedBatches(d.releaseReady ?? []);\n return new Response(html(d), { headers: { \"content-type\": \"text/html; charset=utf-8\", \"cache-control\": \"no-store\" } });\n } catch (e) {\n return new Response(JSON.stringify({ error: String(e).slice(0, 500) }, null, 2), { status: 500, headers: { \"content-type\": \"application/json\" } });\n }\n}\n",[503],"4efd351c-3c9f-4573-a836-b17d633dbf63","_deno-shim.d.ts","d1481a50-95ca-11f1-b3cf-1607ee4eb77e",772,["D",1786483375216],"declare const Deno: { env: { get(k: string): string | undefined } };\nexport {};\n",[510],"59b7d2e2-8cbc-4ac6-83e6-09e5fc5294d5","SOURCE-BUNDLE.part9.txt","5cc7c38a-91cc-11f1-86f1-1607ee4eb77e",1095,["D",1786801898418],"THE DOGS SPOT — SOURCE BUNDLE (part 9 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (5 of 116 files)\n\n engine/reachability.ts 35089 bytes 62236c301631\n engine/registry-diff.ts 3125 bytes ad145165cddc\n engine/render.ts 2810 bytes f3a95d4ce610\n engine/report-logic.ts 10987 bytes 57376bd947f3\n\n================================================================================================\n=====FILE engine/puppy_path_v1.1.ts#2 =====\ntion was fetched on this path; rule 5 blocks sends anyway\n };\n const d = decideAction(facts, s);\n const nowIso = new Date().toISOString();\n if (d.kind === \"hard_exit\") {\n const v = pickPrimaryOpportunity(opportunities)?.monetaryValue ?? 0;\n state[contactId] = { ...applyDecision(d, s, nowIso), exitValue: v, exitStepsSent: s.lastMainStepSent + s.lastBranchStepSent + (s.lastSlowStepSent ?? 0) };\n out.log.push(`${contactId}: paused contact hard-exited -> ${d.status} (${d.reason})`);\n jrow(contactId, \"hard_exit\", `${d.reason}${v ? ` | value ${v}` : \"\"}`);\n await honourOptOut(contactId, facts, TEST_MODE, j, GHL, fctx);\n } else {\n state[contactId] = { ...s, lastCheckedAt: nowIso };\n }\n } catch (err) {\n out.log.push(`${contactId}: paused-pass FAILED: ${String(err).slice(0, 120)}`);\n }\n continue;\n }\n\n // v1.4 R19b DUE-FIRST FILTERING: nothing due = ask the CRM nothing. Two valves stop cheap\n // becoming blind: SAFETY_SWEEP_HOURS, and any unmodelled status. Full note: NOTES-v1.4.md.\n\n const dueCheck = (() => {\n try {\n if (s.status === \"main\") {\n if (s.lastMainStepSent >= MAIN_SEQUENCE.length) return { due: true, why: \"sequence complete, needs exit evaluation\" };\n const next = MAIN_SEQUENCE[s.lastMainStepSent];\n if (isDue(next.offsetHours, s.enteredAt, Date.now())) return { due: true, why: `main step ${s.lastMainStepSent + 1} due` };\n return { due: false, why: `main step ${s.lastMainStepSent + 1} not due yet` };\n }\n if ((s.status === \"branch_a\" || s.status === \"branch_b\") && s.branchAnchorAt) {\n const seq = s.status === \"branch_a\" ? BRANCH_A : BRANCH_B;\n if (s.lastBranchStepSent >= seq.length) return { due: true, why: \"branch complete, needs exit evaluation\" };\n const next = seq[s.lastBranchStepSent];\n if (isDue(next.offsetHours, s.branchAnchorAt, Date.now())) return { due: true, why: \"branch step due\" };\n return { due: false, why: \"branch step not due yet\" };\n }\n // v1.7.1 — slow_track modelled too: the taper population only grows (non-terminal by\n // design), and without this every taper contact cost a full 3-call CRM check every 15\n // minutes for months of \"not due yet\". The daily safety sweep still catches exits.\n if (s.status === \"slow_track\") {\n const c = Math.max(0, Math.floor(Number(s.lastSlowStepSent)) || 0);\n if (isDue(nextSlowTouch(c).offsetHours, s.slowAnchorAt ?? s.enteredAt, Date.now())) return { due: true, why: `slow touch ${c + 1} due` };\n return { due: false, why: `slow touch ${c + 1} not due yet` };\n }\n return { due: true, why: \"status not modelled by the shortcut — full check\" };\n } catch {\n return { due: true, why: \"due-check threw — full check\" };\n }\n })();\n\n const lastChecked = s.lastCheckedAt ? new Date(s.lastCheckedAt).getTime() : 0;\n const sweepOverdue = Date.now() - lastChecked > safetySweepHours() * HOUR_MS;\n\n if (!dueCheck.due && !sweepOverdue) {\n state[contactId] = { ...s, lastCheckedAt: s.lastCheckedAt };\n out.skipped++;\n skippedNotDue++;\n continue; // zero API calls for this contact this run\n }\n\n try {\n await sleep(120); // v1.2 — pacing between contacts (GHL: 100 req/10s, breach = 401/403 not 429)\n const contact = await getContact(contactId);\n if (!contact) {\n out.log.push(`${contactId}: contact not found, skipping`);\n continue;\n }\n const opportunities = oppsCache.get(contactId) ?? (await getOpenOpportunities(contactId));\n const pupTalkAppt = apptIndex.get(contactId) ?? null;\n const declinedSignal = (contact.tags ?? []).includes(PUP_TALK_DECLINED_TAG);\n const reply = await getReplyStatus(contactId, s.enteredAt, s);\n // v1.9 — settle the PREVIOUS send first: a 2xx from GHL meant \"queued\", never \"delivered\".\n { const dl = await onDeliveryStatus(contactId, s, reply.deliveryStatus, fctx);\n if (dl) { s = dl.s; if (dl.stop) { out.failed++; continue; } } }\n\n const facts: Facts = {\n now: Date.now(),\n contact: {\n id: contactId,\n firstName: contact.firstName ?? \"\",\n companyName: contact.companyName ?? null,\n dnd: !!contact.dnd,\n noEmail: !contact.email,\n noPhone: !contact.phone, // R39 — getContact already fetched it and threw it away\n },\n opportunities,\n pupTalkAppt,\n declinedSignal,\n hasUnansweredInboundReply: reply.hasUnansweredInboundReply,\n conversationCheckFailed: reply.conversationCheckFailed,\n // v1.5 R27 — was that last outbound ours or somebody else's? Ours iff it lands within\n // OURS_TOLERANCE_MS of our own recorded send. No lastSentAt yet (nothing sent to this\n // contact) means any outbound on the thread is definitionally foreign.\n channelBlocked: readChannelConsent(contact),\n optOutRequested: reply.optOutRequested,\n foreignOutboundAt: (() => {\n const lo = reply.lastOutboundAt;\n if (lo == null) return null;\n if (!s.lastSentAt) return lo;\n const ours = new Date(s.lastSentAt).getTime();\n if (Number.isNaN(ours)) return lo;\n return Math.abs(lo - ours) <= OURS_TOLERANCE_MS ? null : lo;\n })(),\n };\n\n const decision = decideAction(facts, s);\n const nowIso = new Date().toISOString();\n\n switch (decision.kind) {\n case \"hard_exit\": {\n // v1.4 — R24: capture what this exit was worth, at the only moment the number is knowable.\n const exitVal = pickPrimaryOpportunity(opportunities)?.monetaryValue ?? 0;\n const stepsSent = s.lastMainStepSent + s.lastBranchStepSent + (s.lastSlowStepSent ?? 0);\n state[contactId] = {\n ...applyDecision(decision, s, nowIso),\n exitValue: exitVal,\n exitStepsSent: stepsSent,\n };\n out.log.push(`${contactId}: hard exit -> ${decision.status} (${decision.reason})${exitVal ? ` | value ${exitVal}` : \"\"}`);\n jrow(contactId, \"hard_exit\", `${decision.reason}${exitVal ? ` | value ${exitVal} after ${stepsSent} message(s)` : \"\"}`);\n await honourOptOut(contactId, facts, TEST_MODE, j, GHL, fctx);\n break;\n }\n\n case \"pause_reply\":\n state[contactId] = applyDecision(decision, s, nowIso);\n if (decision.isNewPause) {\n jrow(contactId, \"pause_reply\", \"inbound reply detected — handed to a human\");\n const title = `Reply from ${facts.contact.firstName || \"contact\"} re: puppy path — read and respond personally`;\n try {\n await createTask(\n contactId,\n title,\n \"Auto-created by puppy-path-engine: an inbound reply was detected; the sequence is paused for this contact until a human responds.\",\n );\n out.log.push(`${contactId}: paused (new reply), task created`);\n } catch (e) {\n out.log.push(`${contactId}: paused (new reply), TASK CREATE FAILED: ${String(e).slice(0, 120)}`);\n }\n } else {\n out.log.push(`${contactId}: still paused (reply already flagged, no duplicate task)`);\n }\n break;\n\n case \"advance_status\":\n state[contactId] = applyDecision(decision, s, nowIso);\n out.log.push(`${contactId}: advanced -> ${decision.status}`);\n // \"awaiting_appt_outcome\" here means: they booked a Pup Talk while in the sequence —\n // the attributable event the summary counts as bookedDuringPath.\n jrow(contactId, \"advance_status\", decision.status);\n break;\n\n case \"soft_exit_21d\":\n state[contactId] = applyDecision(decision, s, nowIso);\n try {\n await createTask(\n contactId,\n `Puppy path finished for ${facts.contact.firstName || \"contact\"} — now on the slow track`,\n `Puppy path finished for ${facts.contact.firstName || \"contact\"}, no reply/booking. They are now on the slow track (occasional helpful messages: weekly for a month, then fortnightly, then monthly — no sales asks). Nothing needed unless you want them moved in the pipeline too; the stage was NOT auto-moved — that's Kim's call.`,\n );\n } catch (e) {\n out.log.push(`${contactId}: soft-exit task FAILED: ${String(e).slice(0, 120)}`);\n }\n out.log.push(`${contactId}: 21d complete — moved to slow track (stage NOT moved)`);\n jrow(contactId, \"soft_exit_21d\", \"21-day sequence complete — moved to slow track\");\n break;\n\n case \"branch_complete\":\n state[contactId] = applyDecision(decision, s, nowIso);\n out.log.push(`${contactId}: branch complete`);\n jrow(contactId, \"branch_complete\", s.status);\n break;\n\n case \"send\": {\n // v1.2 — blast ceilings (mirrors the PupsClub val's precedent). A capped send is a pure\n // deferral: state untouched, the step stays due, later runs drain the backlog gradually.\n if (out.sent + out.failed >= maxSendsPerRun()) {\n out.skipped++;\n out.log.push(`${contactId}: send due but MAX_SENDS_PER_RUN (${maxSendsPerRun()}) reached — deferred`);\n break;\n }\n if (!TEST_MODE && sentToday >= maxSendsPerDay()) {\n out.skipped++;\n out.log.push(`${contactId}: send due but MAX_SENDS_PER_DAY (${maxSendsPerDay()}) reached — deferred to tomorrow`);\n break;\n }\n const step = decision.sequence === \"slow\"\n ? slowTemplateAt(decision.stepIndex, Date.now(), s.lastSentStepId).tpl\n : (decision.sequence === \"main\" ? MAIN_SEQUENCE : decision.sequence === \"branch_a\" ? BRANCH_A : BRANCH_B)[decision.stepIndex];\n // v1.7.1 — consent re-checked against the template actually being sent: a monthly\n // re-resolution at the UTC month boundary can flip template (and channel) between\n // decision and execution; an opted-out channel must win that race.\n { const rbr = decision.sequence === \"slow\" ? channelBar(facts, step.channel) : null;\n if (rbr) {\n out.skipped++;\n out.log.push(`${contactId}: slow step resolved to barred ${step.channel} at send time (${rbr}) — skipped, not consumed`);\n break;\n } }\n const rendered = renderStep(\n step,\n { firstName: facts.contact.firstName, companyName: facts.contact.companyName },\n { testMode: TEST_MODE },\n );\n try {\n const resp = rendered.channel === \"sms\"\n ? await sendSms(contactId, rendered.text)\n : await sendEmail(contactId, rendered.subject, rendered.html);\n // v1.2 — state persisted IMMEDIATELY after each successful send (a mid-run crash\n // must never re-send). Non-send transitions recompute idempotently. NOTES-v1.4.md.\n state[contactId] = { ...applyDecision(decision, s, nowIso), ...sendReceipt(resp, rendered.channel) };\n await saveAllState(state).catch((e) =>\n out.log.push(`${contactId}: sent OK but state persist failed (will retry at end): ${String(e).slice(0, 100)}`),\n );\n // v1.4 — R23: position is an array index, so inserting a message re-points everyone\n // mid-sequence with no signal. Recording the step ID makes that drift DETECTABLE.\n\n // v1.7 — slow records template id; R23 drift check stays main-only (slow's monthly\n // index-to-id mapping varies by design).\n const seqNow = decision.sequence === \"main\" ? MAIN_SEQUENCE : decision.sequence === \"branch_a\" ? BRANCH_A : decision.sequence === \"branch_b\" ? BRANCH_B : null;\n const sentStepId = decision.sequence === \"slow\" ? step.id : (seqNow?.[decision.stepIndex]?.id ?? null);\n if (s.lastSentStepId && sentStepId && seqNow) {\n const prevIdx = seqNow.findIndex((x) => x.id === s.lastSentStepId);\n if (prevIdx >= 0 && prevIdx !== decision.stepIndex - 1 && decision.sequence === \"main\") {\n out.log.push(`${contactId}: SEQUENCE DRIFT — last sent ${s.lastSentStepId} now sits at index ${prevIdx}, expected ${decision.stepIndex - 1}. The copy has been edited underneath in-flight contacts.`);\n jrow(contactId, \"sequence_drift\", `${s.lastSentStepId} -> index ${prevIdx}`);\n }\n }\n state[contactId] = { ...state[contactId], lastSentStepId: sentStepId };\n out.sent++;\n if (!TEST_MODE) sentToday++;\n out.log.push(`${contactId}: sent ${decision.sequence} step ${decision.stepIndex + 1} (${rendered.channel})`);\n jrow(contactId, \"sent\", `${decision.sequence}#${decision.stepIndex + 1} (${rendered.channel === \"sms\" ? \"text\" : \"email\"})`);\n } catch (e) {\n out.failed++;\n if (!TEST_MODE) sentToday++; // a failed attempt spent the same GHL call as a send\n await onSendFailure(contactId, s, e, `${decision.sequence}#${decision.stepIndex + 1}`, fctx);\n }\n break;\n }\n\n case \"skip_step\":\n // v1.6 R28 / v1.9 — this step's channel is opted out OR has no address at all. Consumed,\n // not deferred, so the sequence carries on; journalled, because a message that silently\n // never went out is what nobody notices until a customer asks why they never heard back.\n state[contactId] = applyDecision(decision, s, nowIso);\n out.skipped++;\n out.log.push(`${contactId}: ${decision.reason}`);\n jrow(contactId, \"skip_step_channel_optout\", decision.reason);\n break;\n\n case \"skip\":\n // Still runs through applyDecision (a no-op on every field except lastCheckedAt) so \"last\n // time this contact was actually looked at\" stays accurate per spec §4's schema comment.\n state[contactId] = applyDecision(decision, s, nowIso);\n out.skipped++;\n // R37: deferral reasons logged; \"not due\" stays silent (skippedNotDue counts it).\n if (!/not due/.test(decision.reason)) {\n out.log.push(`${contactId}: ${decision.reason}`);\n jrow(contactId, \"deferred\", decision.reason.slice(0, 120));\n }\n break;\n }\n } catch (err) {\n out.failed++;\n out.log.push(`${contactId}: FAILED: ${String(err).slice(0, 150)}`);\n // v1.4 — this catch used to write to out.log only, and out.log is not persisted to the\n // journal. So a contact failing here was invisible to the dashboard, which reads the journal.\n // Every failure now leaves a row.\n jrow(contactId, \"contact_failed\", String(err).slice(0, 100));\n }\n }\n\n // v1.1: prune stale terminal entries (their history lives on in the journal), persist everything,\n // then rebuild the aggregate summary from full journal + surviving state.\n out.skippedNotDue = skippedNotDue;\n if (skippedNotDue) out.log.push(`${skippedNotDue} contact(s) not due — zero API calls spent on them`);\n const { kept, prunedIds } = pruneState(state, Date.now());\n for (const id of prunedIds) jrow(id, \"pruned\", \"terminal 60+ days, removed from state (journal retains history)\");\n if (prunedIds.length) out.log.push(`pruned ${prunedIds.length} stale terminal entries`);\n await saveAllState(kept);\n const fullJournal = await appendJournal(journal);\n await saveSummary(\n buildSummary(kept, fullJournal, {\n at: new Date().toISOString(),\n testMode: TEST_MODE,\n sent: out.sent,\n failed: out.failed,\n enrolled: out.enrolled,\n }),\n ).catch((e) => out.log.push(`summary save failed: ${String(e).slice(0, 100)}`));\n await saveReport(out);\n await blob.setJSON(\"puppy_run_lock\", { startedAt: null }).catch(() => {}); // release lock\n // Holiday deposits: once an hour, LAST, fully caught, read-only. Why it hangs off this\n // schedule rather than its own file is in NOTES-v1.4.md under \"deposit refresh\".\n try {\n const dep = await import(\"./deposits.ts\");\n await dep.refreshIfDue(() => blob.getJSON(dep.ATTEMPT_KEY) as any, () => dep.runCollection(false, \"engine\"), Date.now());\n } catch (e) { console.log(\"deposits refresh skipped\", String(e).slice(0, 120)); }\n console.log(\"PUPPYPATH\", JSON.stringify(out));\n return out;\n } catch (err) {\n out.ok = false;\n out.error = String(err);\n await saveLastError({ at: new Date().toISOString(), error: String(err) }).catch(() => {});\n // v1.2 — even on a crashed run, persist whatever state mutations happened before the crash\n // (sends already persisted individually; this catches transitions) and the journal rows.\n await saveReport(out).catch(() => {});\n await appendJournal(journal).catch(() => {});\n await blob.setJSON(\"puppy_run_lock\", { startedAt: null }).catch(() => {});\n console.log(\"PUPPYPATH\", JSON.stringify(out));\n return out;\n }\n}\n\n// ---- booking-link shortener (spec §7) --------------------------------------------------\n// (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\nexport async function bookingRedirect(_req: Request): Promise {\n return Response.redirect(REAL_BOOKING_URL, 302);\n}\n\n// ---- exports for the local test harness (puppy-path-engine.test.ts) -------------------------------\n\nexport {\n decideAction,\n applyDecision,\n renderStep,\n resolveDogName,\n resolveFirstName,\n applyMergeFields,\n isDue,\n freshState,\n pickPrimaryOpportunity,\n apptIsLiveBooked,\n bodyToHtml,\n // v1.1 pure additions\n businessLocalParts,\n inSendWindow,\n selectEnrollable,\n buildSummary,\n pruneState,\n MAIN_SEQUENCE,\n BRANCH_A,\n BRANCH_B,\n STAGE,\n MAIN_PIPELINE_ID,\n TAG_ENROLLED,\n TAG_SOURCE_SIGNAL,\n PUP_TALK_DECLINED_TAG,\n PHONE_DISPLAY,\n REAL_BOOKING_URL,\n SHORT_BOOKING_LINK,\n TERMINAL_STATUSES,\n DAY_MS,\n HOUR_MS,\n TEST_MODE,\n // v1.7 — slow track\n slowTemplateAt,\n nextSlowTouch,\n monthlyTemplateFor,\n};\n// v1.8 — story machinery + taper banks re-exported for the offline harness\nexport { readChannelConsent } from \"./consent.ts\";\nexport * from \"./reachability.ts\";\nexport { STORY_SLOTS, resolveStories, storyFor } from \"./kim-stories.ts\";\nexport { SLOW_WEEKLY, SLOW_FORTNIGHTLY, SLOW_MONTHLY_BANK } from \"./taper-messages.ts\";\nexport type { PuppyState, PuppyStatus, Facts, Decision, ContactFact, OppFact, ApptFact, MessageTemplate, RenderedMessage };\n\n\n=====FILE engine/reachability.ts =====\n// REACHABILITY, DEAD LETTERS AND DELIVERY. Extracted from main.ts on 14 Aug 2026, for exactly the\n// reason consent.ts and render.ts were extracted before it: main.ts sits against val.town's hard\n// 80,000-character ceiling with ~850 characters spare, and the code that decides whether a real\n// person can be reached at all should be a file you can find, not twenty lines inside a 1,500-line\n// engine. Every function here is pure or takes its IO injected, so all of it is directly testable.\n//\n// THE FOUR DEFECTS THIS FILE EXISTS TO CLOSE. All four were proven by running the compiled engine\n// against the live account, not inferred from reading it.\n//\n// 1. THE SPIN. channelBar guarded `noEmail` for email and had NO PHONE EQUIVALENT. ContactFact had\n// no phone field at all, though getContact fetches `phone` on every pass and threw it away. An\n// SMS step coming due for a phoneless contact went: due -> sendGate (no contactability check) ->\n// channelBar returns null -> send -> sendSms -> `if (!r.ok) throw` -> the catch in cron(), which\n// WROTE NOTHING TO STATE. dueAt never moved, so the next tick re-derived the identical decision.\n// Rule 9's 21-day exit needs lastMainStepSent >= MAIN_SEQUENCE.length, which only advances on the\n// success path, so it never timed out. MAX_SENDS_PER_RUN and MAX_SENDS_PER_DAY both read\n// out.sent, which only increments on success, so FAILURES WERE UNCAPPED. Observed cadence ~60min\n// = ~24 retries per contact per day, forever, plus a CRITICAL watchdog alert every hour.\n// Live census, all 5,748 contacts: 398 qualify as puppy inquiries, 266 of them have NO PHONE.\n// Bulk-tagging today would have been ~648 failed sends and ~2,600 wasted GHL calls per day.\n//\n// 2. NO ATTEMPT COUNTER, NO DEAD LETTER. PuppyState had no failure field and all five terminal\n// statuses were success shapes, so a permanently failing contact rendered as \"In the main\n// sequence\" indefinitely. Fixed by sendFailures + MAX_SEND_FAILURES + done_send_failed.\n//\n// 3. NO REACHABILITY EXIT. A contact with neither email nor phone silently consumed all 8 steps and\n// then fired the soft_exit_21d task telling Kim \"Puppy path finished... now on the slow track\" —\n// a task that is a lie about somebody who received nothing. done_unreachable ends them at the\n// first pass instead, and DELIBERATELY CREATES NO TASK: bulk-tagging 300 contacts would put 265\n// tasks in Kim's CRM in a single run, which is its own incident. It is journalled and counted.\n// Only a contact that TRIED and FAILED (the dead-letter path) earns a task.\n//\n// 4. DELIVERY WAS NEVER RECONCILED. The send response was discarded entirely, including the\n// messageId the engine's own comment documents, so any 2xx from GHL was recorded as \"sent\".\n// Live sampling found 9 `undelivered` out of 124 outbound SMS in this account (7.3%) — every one\n// of them would have counted as a success.\n//\n// SCOPE NOTE — WHAT IS AND IS NOT READABLE ABOUT DELIVERY (verified live, 14 Aug 2026):\n// * SMS status IS readable on GET /conversations/{conversationId}/messages (Version 2021-04-15):\n// each message carries `status` (delivered / undelivered / queued / ...).\n// * EMAIL status is NOT on that endpoint: 137 TYPE_EMAIL messages sampled there carried no\n// `status` key at all.\n// * EMAIL status IS readable on GET /conversations/messages/email/{emailMessageId} (verified 200,\n// returned status:\"opened\"), and sendEmail already returns emailMessageId in its response.\n// Both are handled below. Where either read fails, the status is recorded as the literal string\n// \"unknown\" — VISIBLY UNKNOWN, never filed as fine. That is this codebase's standing rule\n// (facts.ts:1-12): a fact nobody could establish is not a fact that everything is well.\n//\n// RECONCILIATION IS KEYED ON THE MESSAGE ID, never on \"the newest outbound message on the thread\".\n// Chloe, Ava and 165 GHL workflows also send into these same conversations; attributing another\n// system's `undelivered` to this engine would dead-letter a perfectly healthy contact.\n\ndeclare const Deno: { env: { get(key: string): string | undefined } };\nif (typeof (globalThis as any).Deno === \"undefined\") {\n (globalThis as any).Deno = { env: { get: (k: string) => (globalThis as any).process?.env?.[k] } };\n}\n\n// Same idiom as the engine's other knobs: read per call, env-overridable, clamped so a typo cannot\n// disable the ceiling. 3 = two retries after the first failure, which is enough for a transient\n// GHL blip and nowhere near enough to be a spin.\nexport const maxSendFailures = () => Math.max(1, Math.floor(Number(Deno.env.get(\"MAX_SEND_FAILURES\") ?? \"3\")) || 3);\n// How long after a send before its status is worth reading back. GHL stamps status asynchronously;\n// reading seconds after the POST reports \"queued\" for everything and teaches you nothing.\nexport const RECONCILE_MIN_AGE_MS = 5 * 60 * 1000;\n\n// ---- statuses, reasons, state fields --------------------------------------------------------------\n\n// Declared here rather than inline in main.ts purely for that file's character budget; they are\n// spliced into PuppyStatus and TERMINAL_STATUSES there, so they are terminal everywhere for free.\nexport type DeadLetterStatus = \"done_unreachable\" | \"done_send_failed\";\nexport const DEAD_LETTER_STATUSES: DeadLetterStatus[] = [\"done_unreachable\", \"done_send_failed\"];\n\n// Reason strings live in exactly one place so a test, a log line and a dashboard label cannot drift.\n// NOTE the wording: absence is never described as an opt-out the person did not make (consent.ts's\n// rule, and consent-guard.test.mjs CG-4 pins it).\nexport const NO_EMAIL_REASON = \"no email address on the record\";\nexport const NO_PHONE_REASON = \"no phone number on the record\";\nexport const UNREACHABLE_REASON = \"no email address and no phone number on the record\";\nexport const OPTOUT_REASON = \"replied with an opt-out keyword\";\nexport const DND_WRITE_MESSAGE = \"Replied with an opt-out keyword to a puppy-path message\";\n\nexport type FailureFields = {\n // v1.9 — ALL OPTIONAL, on purpose: existing state blobs in production deserialize untouched and\n // every reader defaults them. Same discipline as the v1.7 slow-track fields.\n sendFailures?: number; // consecutive failed attempts; reset to 0 by a success\n lastFailureAt?: string | null; // ISO — feeds the exponential backoff\n lastFailureReason?: string | null;\n lastMessageId?: string | null; // the id GHL returned for our last send, for reconciliation\n lastMessageChannel?: \"sms\" | \"email\" | null;\n lastDeliveryStatus?: string | null; // observed status, or the literal \"unknown\"\n};\n\nexport const FRESH_FAILURE_FIELDS: FailureFields = {\n sendFailures: 0, lastFailureAt: null, lastFailureReason: null,\n lastMessageId: null, lastMessageChannel: null, lastDeliveryStatus: null,\n};\n\n/** Consecutive failures, clamped. Garbage counters (NaN, negative, a string blob) read as 0 rather\n * than falling through to \"dead-letter this contact\" — same clamping the slow track already does. */\nexport const failCount = (s: FailureFields | null | undefined): number =>\n Math.max(0, Math.floor(Number(s?.sendFailures)) || 0);\n\n// ---- channel availability -------------------------------------------------------------------------\n\n/** Is this channel physically usable for this contact? Absence of an address, not consent — the\n * consent question is readChannelConsent's, and the two are deliberately reported differently. */\nexport function missingChannel(c: { noEmail?: boolean; noPhone?: boolean }, ch: \"email\" | \"sms\"): string | null {\n if (ch === \"email\" && c.noEmail) return NO_EMAIL_REASON;\n if (ch === \"sms\" && c.noPhone) return NO_PHONE_REASON;\n return null;\n}\n\n/**\n * Rules 1b and 1c of the state machine, evaluated immediately after the DND rule and BEFORE the\n * disqualified rule.\n *\n * 1b — the contact asked to stop, in words, in a reply. Hard exit. It outranks rule 5 (pause_reply)\n * deliberately: today an \"UNSUBSCRIBE\" reply routes to pause_reply, which pauses, raises a task\n * for a human, records no opt-out at all, and RESUMES SENDING once a human answers.\n * 1c — the contact has neither an email address nor a phone number, so nothing can ever be sent to\n * them by any channel. Ending them here is what stops them consuming all 8 steps in silence and\n * then triggering a \"puppy path finished\" task about somebody who received nothing.\n *\n * Returns a Decision-shaped object; assignable to the engine's Decision union without importing it,\n * which keeps this file free of a circular dependency on main.ts.\n */\nexport function reachabilityExit(f: {\n contact: { noEmail?: boolean; noPhone?: boolean };\n optOutRequested?: boolean;\n}): { kind: \"hard_exit\"; status: \"done_hard_exit\" | \"done_unreachable\"; reason: string } | null {\n if (f.optOutRequested) return { kind: \"hard_exit\", status: \"done_hard_exit\", reason: OPTOUT_REASON };\n if (f.contact.noEmail && f.contact.noPhone) {\n return { kind: \"hard_exit\", status: \"done_unreachable\", reason: UNREACHABLE_REASON };\n }\n return null;\n}\n\n/** Enrolment-time refusal. A contact with no way of being contacted is not put on the path at all:\n * no puppy-path-v1 tag, one journal row, and a terminal state entry (see reEnrollable). */\nexport function enrolmentBar(c: { email?: unknown; phone?: unknown } | null | undefined): string | null {\n return !c?.email && !c?.phone ? UNREACHABLE_REASON : null;\n}\n\n/**\n * CAN A DEAD LETTER COME BACK? (14 Aug, defect 2.)\n *\n * The candidate filter was `!tags.includes(TAG_ENROLLED) && !state[c.id]`. A done_send_failed or\n * done_unreachable entry sits in state and is never touched again — the per-contact loop `continue`s\n * on any terminal status, so lastCheckedAt never moves and pruneState only drops it after 60 days.\n * Meanwhile the dead-letter task this file writes told Kim to do exactly the thing that did not work:\n * \"remove the puppy-path-v1 tag and re-tag them\". Proven against the live account: she removes the\n * tag, fixes the phone number, re-tags — candidates that survive the filter: 0.\n *\n * So a dead letter is allowed back in, under two conditions that stop it becoming a loop:\n * 1. ONLY the two dead-letter statuses. done_customer, done_hard_exit (which is where an opt-out\n * lands), done_booked, done_soft_21d, done_branch_complete and done_not_enrolled are NOT\n * resurrectable by re-tagging\n * — an opt-out must never be undone by a tag, and a customer must never be re-nurtured by one.\n * 2. THE REASON MUST NO LONGER BE VISIBLY TRUE. A contact who still has neither an email address\n * nor a phone number is not a candidate at all: nothing was fixed, so re-admitting them would\n * re-refuse them every run forever, which is defect 4 with a different name. done_send_failed\n * cannot be verified the same way (a bad number looks exactly like a good one), so it is let\n * back in with a fresh attempt budget — and re-enrolment applies TAG_ENROLLED, which is what\n * stops it repeating: they are excluded by the first clause of the filter from then on.\n */\nexport function reEnrollable(\n s: { status?: string } | null | undefined,\n c: { email?: unknown; phone?: unknown } | null | undefined,\n): boolean {\n if (!s || !DEAD_LETTER_STATUSES.includes(s.status as DeadLetterStatus)) return false;\n return !enrolmentBar(c); // still unreachable: stays dead-lettered, silently, at zero cost\n}\n\n/**\n * Has this exact refusal already been written to the journal for this contact? (14 Aug, defect 4.)\n *\n * A TRANSIENT refusal — \"tagged but already has a live Pup Talk booking\" — must keep being\n * re-evaluated every run, because the booking may be cancelled tomorrow and then they SHOULD enrol.\n * But re-evaluating it wrote an identical journal row every run: 39 of the last 40 rows on Kim's\n * live activity page are the same sentence, hourly, for two days, and at ~24-30 rows a day the\n * 2,000-row cap evicts every real thing the system did within about two months.\n *\n * A terminal refusal gets a state entry instead (that is what enrolmentBar's branch does, and it is\n * why that one never repeated). A transient one cannot have a state entry — any state entry at all\n * removes the contact from the candidate filter — so the repetition is stopped at the journal.\n */\nexport function refusedBefore(\n priorJournal: { contactId?: string | null; event?: string; detail?: string }[] | null | undefined,\n contactId: string,\n detail: string,\n): boolean {\n return (priorJournal ?? []).some(\n (r) => r?.contactId === contactId && r?.event === \"enroll_refused\" && r?.detail === detail,\n );\n}\n\n// ---- backoff --------------------------------------------------------------------------------------\n\n/**\n * Exponential backoff between failed attempts: 2^failures hours. Returned as a sendGate reason\n * string, so a contact in backoff produces `skip` — state untouched, step still due, picked up\n * later — which is exactly how every other deferral in this engine behaves.\n *\n * The `since >= 0` guard mirrors the R27 / v1.7 clock-skew guards: a future-dated stamp (restored\n * blob, clock skew) must never freeze a contact until that future date.\n */\nexport function backoffBar(s: FailureFields | null | undefined, nowMs: number): string | null {\n const n = failCount(s);\n if (!n || !s?.lastFailureAt) return null;\n const since = nowMs - Date.parse(s.lastFailureAt);\n if (!(since >= 0)) return null;\n const waitH = Math.pow(2, Math.min(n, 12));\n if (since >= waitH * 3600000) return null;\n return `send backoff after ${n} failure(s): waiting ${waitH}h, ${(since / 3600000).toFixed(1)}h elapsed`;\n}\n\n// ---- failure accounting ---------------------------------------------------------------------------\n\n/** Injected effects, so every policy decision below stays testable without a network. */\nexport type Effects = {\n state: Record;\n save: (st: Record) => Promise;\n log: (line: string) => void;\n journal: (contactId: string, event: string, detail: string) => void;\n /** null in practice mode — TEST_MODE must never write a task into the client's real CRM. */\n task: ((contactId: string, title: string, body: string) => Promise) | null;\n};\n\n/**\n * THE INVARIANT THIS FUNCTION MUST NOT BREAK. main.ts's comment on the success path reads: \"state\n * persisted IMMEDIATELY after each successful send (a mid-run crash must never re-send)\". So this\n * moves the FAILURE COUNTER AND NOTHING ELSE. lastMainStepSent, lastBranchStepSent, lastSlowStepSent\n * and lastSentAt are all left exactly as they were: nothing went out, so no step is consumed and the\n * pacing clock does not start. The only status change is the terminal one at the ceiling.\n */\nexport function nextFailureState>(\n s: S, nowIso: string, reason: string,\n): { next: S; n: number; dead: boolean } {\n const n = failCount(s) + 1;\n const dead = n >= maxSendFailures();\n const next: any = {\n ...s,\n sendFailures: n,\n lastFailureAt: nowIso,\n lastFailureReason: reason.slice(0, 200),\n lastCheckedAt: nowIso,\n lastMessageId: null, // whatever we were reconciling is moot; this attempt is the news now\n };\n if (dead) {\n next.status = \"done_send_failed\";\n next.exitReason = `${n} consecutive send failures — dead-lettered (${reason.slice(0, 120)})`;\n }\n return { next: next as S, n, dead };\n}\n\nexport const DEAD_LETTER_TITLE = \"Automated follow-up has STOPPED for this contact — messages keep failing\";\n\nexport function deadLetterBody(label: string, n: number, reason: string): string {\n return `Auto-created by puppy-path-engine: ${n} attempts to send ${label} to this contact all failed, so the engine has stopped trying.\\n\\nLast error: ${reason.slice(0, 200)}\\n\\nThis person is NOT receiving the puppy follow-up and will not receive any more of it. Usual causes: the phone number or email address on the record is wrong or missing, the number is a landline, or the carrier is rejecting us.\\n\\nTo put them back on it: fix the contact details first, then remove the puppy-path-v1 tag and add the tag you normally use to start someone on the puppy path. They begin again at message one on the next run. If the record still has no phone number and no email address, nothing happens and they stay stopped — the details have to be fixed first, and this is the only order that works.`;\n}\n\nasync function announceDeadLetter(contactId: string, n: number, label: string, reason: string, fx: Effects) {\n fx.journal(contactId, \"dead_letter\", `${label} failed ${n}x — stopped trying: ${reason.slice(0, 60)}`);\n fx.log(`${contactId}: DEAD LETTER after ${n} failures — status done_send_failed, no further attempts`);\n // A contact that TRIED AND FAILED earns a task; an unreachable contact does not (see defect 3).\n if (fx.task) await fx.task(contactId, DEAD_LETTER_TITLE, deadLetterBody(label, n, reason)).catch(() => {});\n}\n\n/**\n * The catch on the send path. Before this existed the catch wrote NOTHING to state, which is the\n * whole spin: dueAt unchanged, identical decision next tick, forever, uncapped.\n * Returns true when this failure dead-lettered the contact.\n */\nexport async function onSendFailure(\n contactId: string, s: any, err: unknown, label: string, fx: Effects,\n): Promise {\n const reason = String((err as any)?.message ?? err).slice(0, 150);\n const { next, n, dead } = nextFailureState(s, new Date().toISOString(), reason);\n fx.state[contactId] = next;\n // Persisted immediately, exactly like the success path: a mid-run crash must not lose the count\n // either, or the ceiling never arrives.\n await fx.save(fx.state).catch(() => {});\n fx.log(`${contactId}: SEND FAILED ${label} (attempt ${n} of ${maxSendFailures()}): ${reason.slice(0, 100)}`);\n fx.journal(contactId, \"send_failed\", `${label}: ${reason.slice(0, 80)}`);\n if (dead) await announceDeadLetter(contactId, n, label, reason, fx);\n return dead;\n}\n\nexport const DELIVERY_FAILED_STATUSES = new Set([\"undelivered\", \"failed\", \"rejected\", \"bounced\", \"error\"]);\nexport const isDeliveryFailure = (st: unknown): boolean =>\n DELIVERY_FAILED_STATUSES.has(String(st ?? \"\").toLowerCase());\n\n/**\n * A delivery status read back on a LATER pass. GHL returning 2xx to our POST means \"queued\", not\n * \"delivered\" — 7.3% of live outbound SMS in this account are `undelivered` and every one of them\n * was being counted as a success.\n *\n * Returns null when there was nothing to reconcile. `stop` is true only for a real delivery failure,\n * which feeds the same counter as a send failure; the caller skips the rest of the pass so the\n * backoff applies before anything else is attempted.\n *\n * IDEMPOTENT: lastMessageId is cleared either way, so a given message is reconciled at most once and\n * a repeated pass cannot count the same failure twice.\n */\nexport async function onDeliveryStatus(\n contactId: string, s: any, status: string | null | undefined, fx: Effects,\n): Promise<{ s: any; stop: boolean } | null> {\n if (!status) return null;\n const st = String(status).toLowerCase();\n if (!isDeliveryFailure(st)) {\n const next = { ...s, lastDeliveryStatus: st, lastMessageId: null };\n fx.state[contactId] = next;\n // Visibly unknown, not quietly fine. Journalled so the count is on the dashboard rather than\n // being something only a person reading the blob would ever discover.\n if (st === \"unknown\") fx.journal(contactId, \"delivery_unknown\", \"delivery status could not be read for the last message\");\n return { s: next, stop: false };\n }\n const { next, n, dead } = nextFailureState(s, new Date().toISOString(), `delivery reported ${st}`);\n next.lastDeliveryStatus = st;\n fx.state[contactId] = next;\n await fx.save(fx.state).catch(() => {});\n fx.log(`${contactId}: last message came back ${st} (attempt ${n} of ${maxSendFailures()})`);\n fx.journal(contactId, \"delivery_failed\", `${st} (attempt ${n} of ${maxSendFailures()})`);\n if (dead) await announceDeadLetter(contactId, n, `the last message (${st})`, `delivery reported ${st}`, fx);\n return { s: next, stop: true };\n}\n\n/** What a successful send leaves on state: the receipt to reconcile against, and a RESET COUNTER.\n * The reset matters because applyDecision spreads `...s` — a stale count left standing would\n * dead-letter a healthy contact on an unrelated blip weeks later. */\nexport function sendReceipt(resp: any, channel: \"sms\" | \"email\"): FailureFields {\n const id = channel === \"email\"\n ? (resp?.emailMessageId ?? resp?.messageId ?? null)\n : (resp?.messageId ?? resp?.messageIds?.[0] ?? null);\n return {\n sendFailures: 0, lastFailureAt: null, lastFailureReason: null,\n lastMessageId: id != null ? String(id) : null,\n lastMessageChannel: channel,\n lastDeliveryStatus: null,\n };\n}\n\n// ---- opt-out words --------------------------------------------------------------------------------\n\n/**\n * TWO RULES, BOTH DELIBERATELY NARROW: a WHOLE BODY that is nothing but an opt-out word, and a short\n * list of phrases that cannot mean anything else. Everything else is left to a human via pause_reply.\n *\n * [was: /^\\s*(unsubscribe|stop|remove|opt[\\s-]?out)\\b/i — anchored at the start of the RAW body. Email\n * is the channel every footer makes the promise on (\"Reply UNSUBSCRIBE\"), and it is the channel that\n * rule could not read: an email reply arrives as `
UNSUBSCRIBE
`, as `
unsubscribe\n *
`, as `> unsubscribe`, as `\"STOP\"`, or under an `On 14 Aug, Kim wrote:` line — none of which\n * START with the word. It also missed every natural phrasing (\"please unsubscribe me\", \"take me off\n * this list\", \"no more texts please\") while MATCHING five sentences that mean the opposite (\"Remove\n * the 3pm and put us at 4\", \"Stop, I already booked!\", \"Opt out of the Tuesday session only\").\n * A prefix rule is not a narrow rule; it is a rule that reads one word and guesses the rest.]\n *\n * WHY NOT \"cancel\", still. Removed 14 Aug and kept out: for a business whose funnel is booked calls,\n * \"cancel my Pup Talk\" is a booking change from a hot lead. One live inbound in the 669 real bodies\n * checked reads \"My apologies but could you cancel my subscription?\" — which in an account that sells\n * training packages could as easily be the package as the texts. It is not silently dropped: an\n * inbound reply still pauses the sequence and puts a task in front of a person. A wrong opt-out is\n * irreversible in both directions at once — the lead is hard-exited AND a permanent email block is\n * written that silences Kim's own confirmations to them.\n *\n * TESTED AGAINST REAL DATA, not invented data: all 2,889 message bodies in the 99 live conversations\n * (669 of them inbound with a body). Matches exactly the 5 genuine opt-outs the old rule found, and\n * nothing else — including zero matches on the 2,220 outbound bodies, which is the guard that matters\n * for the SMS-reaction shape (`Loved \"…Reply STOP to stop these texts.\"` is an INBOUND message that\n * quotes our own footer back at us). Every phrase below is first-person on purpose: our own footers\n * say \"take YOU off these emails\" and \"Reply STOP\", so no footer can ever match itself.\n */\nconst OPT_OUT_TARGET =\n \"(?:e ?mails?|texts?|texting|messages?|msgs?|sms|mail(?:ing|ings)?|lists?|marketing|communications?|newsletters?|notifications?|spam)\";\n\n/** Body -> comparable core: HTML stripped, quoted-reply and signature chrome dropped, punctuation and\n * emoji reduced to spaces, politeness trimmed off both ends. Exported because it is the half of this\n * rule most likely to be wrong on a shape nobody has seen yet, and a test can only pin what it can see. */\nexport function optOutCore(body: unknown): string {\n let s = String(body ?? \"\");\n if (!s.trim()) return \"\";\n // Entities are decoded BEFORE the tags are stripped as well as after: a double-encoded body\n // (`<p>unsubscribe</p>`, which is what a form-posted reply can arrive as) would\n // otherwise survive tag-stripping as the literal text \"p unsubscribe p\" and match nothing.\n const entities = (x: string) => x.replace(/ /gi, \" \").replace(/"|"/gi, '\"')\n .replace(/'|'/gi, \"'\").replace(/</gi, \"<\").replace(/>/gi, \">\").replace(/&/gi, \"&\");\n s = entities(s);\n s = s.replace(/<(script|style)[\\s\\S]*?<\\/\\1>/gi, \" \");\n s = s.replace(//gi, \"\\n\").replace(/<\\/(p|div|blockquote|tr|li|h[1-6])\\s*>/gi, \"\\n\");\n s = s.replace(/<[^>]*>/g, \" \");\n s = entities(s);\n const kept: string[] = [];\n for (const raw of s.split(/\\r?\\n/)) {\n const line = raw.trim();\n if (/^>+/.test(line)) continue; // quoted line\n if (/^on\\b.{0,120}\\bwrote:?$/i.test(line)) continue; // \"On 14 Aug, Kim wrote:\"\n if (/^(from|sent|to|subject|date|cc|reply-to):/i.test(line)) continue;\n if (/^[-_]{2,}\\s*(original|forwarded)\\b/i.test(line)) continue;\n if (/^sent from my\\b/i.test(line)) continue; // phone signature\n if (/^get outlook for\\b/i.test(line)) continue;\n kept.push(line);\n }\n // A body that is ENTIRELY quoted (\"> unsubscribe\") must not strip to nothing: de-quote instead.\n let text = kept.join(\" \").trim();\n if (!text) text = s.replace(/^[ \\t]*>+[ \\t]?/gm, \" \");\n let core = text.toLowerCase().replace(/[^a-z0-9]+/g, \" \").replace(/\\s+/g, \" \").trim();\n for (let i = 0; i < 2; i++) {\n core = core.replace(/^(?:please|pls|plz|kindly|hi|hello|hey|yes|ok|okay)\\s+/, \"\")\n .replace(/\\s+(?:please|pls|plz|thanks|thank you|thx|asap|now|immediately|ty)$/, \"\");\n }\n return core;\n}\n\n/** The whole body says this and nothing else. \"Stop, I already booked!\" is not in here, and cannot be. */\nexport const WHOLE_BODY_OPT_OUT = new Set([\n \"unsubscribe\", \"unsubscribed\", \"unsub\", \"unsubscribe me\", \"unsubscribe me from this list\",\n \"stop\", \"stop all\", \"stopall\", \"stop it\", \"stop messages\", \"stop texts\", \"stop emails\",\n \"remove\", \"remove me\", \"removed\", \"delete me\", \"take me off\", \"take me off the list\",\n \"opt out\", \"optout\", \"opt me out\", \"opted out\",\n]);\n\n/** Phrases that cannot be a booking change. Each one names the PERSON as the thing being removed and\n * the CHANNEL they are being removed from — \"remove me from this list\", never \"remove the 3pm\". */\nexport const OPT_OUT_PHRASES: RegExp[] = [\n /\\bunsubscribe me\\b/,\n new RegExp(`\\\\bunsubscribe (?:me )?from (?:this|these|your|the|all|future|any)[a-z ]{0,20}?${OPT_OUT_TARGET}\\\\b`),\n new RegExp(`\\\\b(?:remove|delete|take) me (?:from|off) (?:this|these|your|the|all|any|ur)?[a-z ]{0,14}?${OPT_OUT_TARGET}\\\\b`),\n new RegExp(`\\\\bno more ${OPT_OUT_TARGET}\\\\b`),\n /\\bstop (?:texting|emailing|e mailing|messaging|contacting|calling|mailing) me\\b/,\n new RegExp(`\\\\bstop sending me[a-z ]{0,14}?${OPT_OUT_TARGET}\\\\b`),\n /\\b(?:do not|dont|do nt|never) (?:text|email|e mail|message|contact|call) me\\b/,\n new RegExp(`\\\\bopt (?:me )?out of (?:this|these|your|the|all|future|any)[a-z ]{0,14}?${OPT_OUT_TARGET}\\\\b`),\n];\n\nexport function isOptOutBody(body: unknown): boolean {\n const core = optOutCore(body);\n if (!core) return false;\n if (WHOLE_BODY_OPT_OUT.has(core)) return true;\n return OPT_OUT_PHRASES.some((re) => re.test(core));\n}\n\n/** GHL has returned message pages under three shapes across versions; accept all, invent none. */\nfunction pickMessages(r: any): any[] {\n const m = r?.messages?.messages ?? r?.messages ?? r?.message ?? [];\n return Array.isArray(m) ? m : [];\n}\n\nexport type ReplyStatus = {\n hasUnansweredInboundReply: boolean;\n conversationCheckFailed: boolean;\n lastOutboundAt: number | null;\n optOutRequested?: boolean;\n deliveryStatus?: string | null;\n};\n\n/**\n * The one extra read, hung off the conversation getReplyStatus already fetched — the R27 trick, so\n * the collision guard and the opt-out check and the delivery check share one search call rather than\n * three. The message-body read is a second call, but only when there is actually something to read:\n * an inbound message to inspect, or one of our own sends old enough to have a settled status.\n *\n * FAILS TO SILENCE, NEVER TO \"SEND ANYWAY\". A failed read returns optOutRequested:false, so the\n * caller keeps today's behaviour (pause_reply on an inbound), and deliveryStatus:\"unknown\", which is\n * recorded as unknown rather than as success.\n */\nexport async function convoExtras(\n convo: any,\n st: (FailureFields & { lastSentAt?: string | null }) | undefined | null,\n fetchJson: (url: string, ver: string, init?: any) => Promise,\n base: string,\n nowMs: number,\n): Promise<{ optOutRequested: boolean; deliveryStatus: string | null }> {\n const res = { optOutRequested: false, deliveryStatus: null as string | null };\n const convoId = convo?.id ?? convo?.conversationId ?? null;\n const dir = convo?.lastMessageDirection ?? convo?.direction ?? null;\n const wantOptOut = dir === \"inbound\" && !!convoId;\n const msgId = st?.lastMessageId ?? null;\n const sentAt = st?.lastSentAt ? Date.parse(st.lastSentAt) : NaN;\n const wantDelivery = !!msgId && (!Number.isFinite(sentAt) || nowMs - sentAt >= RECONCILE_MIN_AGE_MS);\n if (!wantOptOut && !wantDelivery) return res;\n\n // One page, shared. An SMS reconciliation and an opt-out check on the same thread are one call.\n let page: any[] | null = null;\n let pageTried = false;\n const loadPage = async (): Promise => {\n if (pageTried) return page ?? [];\n pageTried = true;\n if (!convoId) return [];\n try { page = pickMessages(await fetchJson(`${base}/conversations/${convoId}/messages?limit=20`, \"2021-04-15\")); }\n catch { page = null; }\n return page ?? [];\n };\n\n if (wantDelivery) {\n if (st?.lastMessageChannel === \"email\") {\n // Email status is not on the conversation endpoint at all; it has its own.\n try {\n const r = await fetchJson(`${base}/conversations/messages/email/${msgId}`, \"2021-04-15\");\n const v = r?.emailMessage?.status ?? r?.status ?? null;\n res.deliveryStatus = v ? String(v).toLowerCase() : \"unknown\";\n } catch { res.deliveryStatus = \"unknown\"; }\n } else {\n const mine = (await loadPage()).find((m) => m?.id === msgId);\n const v = mine?.status ?? null;\n res.deliveryStatus = v ? String(v).toLowerCase() : \"unknown\";\n }\n }\n\n if (wantOptOut) {\n const msgs = await loadPage();\n if (!pageTried || page === null) {\n res.optOutRequested = false; // unreadable — the caller falls back to pause_reply\n } else {\n // AN UNKNOWN DIRECTION IS NOT THE CUSTOMER SPEAKING.\n // [was: String(m?.direction ?? \"inbound\") — an absent direction defaulted to inbound, i.e. to\n // \"the customer said this\", which is the one direction this file's own discipline forbids\n // defaulting to (see the header on convoExtras: FAILS TO SILENCE, NEVER TO \"SEND ANYWAY\").\n // 46 messages in the 99 live conversations sampled on 14 Aug carry direction:null; every one\n // is TYPE_EMAIL and every one is plainly ours (\"Congratulations on Your Dog's Bootcamp\n // Graduation\", \"We look forward to speaking with you tomorrow\"). Our own email footer reads\n // \"Reply UNSUBSCRIBE and we'll take you off these emails\" — so the default was pointing the\n // opt-out scanner at our own copy. Unreadable direction now means the message is not scanned,\n // the caller still sees the inbound reply, and the contact is paused for a human instead.]\n const inbound = msgs.find((m) => String(m?.direction ?? \"\").toLowerCase() === \"inbound\") ?? null;\n res.optOutRequested = !!inbound && isOptOutBody(inbound.body ?? inbound.message ?? \"\");\n }\n }\n return res;\n}\n\n/**\n * Honour an opt-out in the client's live CRM by setting dndSettings.Email.status = \"permanent\" —\n * the exact field consent.ts:29 already reads, so the block is enforced everywhere for free with no\n * change to consent.ts. Nothing in this codebase has ever WRITTEN that field (zero `Email:\n * permanent` across 1,200 live contacts), which is why \"Reply UNSUBSCRIBE\" in every email footer\n * has been a promise the system could not keep.\n *\n * This is a write to a real customer record, so: TEST_MODE never writes, and it is idempotent twice\n * over — it is skipped entirely when Email is already blocking, and the PUT sets a fixed value\n * rather than toggling one. SMS is deliberately not written: GHL/Twilio already honour STOP natively\n * on the SMS channel and set permanent themselves.\n */\nexport async function honourOptOut(\n contactId: string,\n f: { optOutRequested?: boolean; channelBlocked?: { email: boolean; sms: boolean } },\n testMode: boolean,\n fetchJson: (url: string, ver: string, init?: any) => Promise,\n base: string,\n fx?: Effects,\n): Promise {\n const say = (m: string, failed = false) => {\n fx?.log(`${contactId}: ${m}`);\n if (failed) fx?.journal(contactId, \"optout_write_failed\", m);\n return m;\n };\n if (!f.optOutRequested) return null;\n if (testMode) return say(\"opt-out detected — practice mode, no DND written to GHL\");\n if (f.channelBlocked?.email) return say(\"opt-out detected — Email DND already set, nothing written\");\n try {\n await fetchJson(`${base}/contacts/${contactId}`, \"2021-07-28\", {\n method: \"PUT\",\n body: JSON.stringify({ dndSettings: { Email: { status: \"permanent\", message: DND_WRITE_MESSAGE } } }),\n });\n return say(\"opt-out honoured — Email DND set to permanent in GHL\");\n } catch (e) {\n // The hard exit stands either way: this engine stops messaging them regardless of whether GHL\n // took the write. Loud, because everything ELSE that reads that field is now out of step.\n return say(`OPT-OUT DND WRITE FAILED (${String(e).slice(0, 80)}) — hard exit stands, GHL NOT updated`, true);\n }\n}\n\n// ---- summary counts -------------------------------------------------------------------------------\n\n/** The counts buildSummary never had: send_failed was journalled and then counted by nothing, so a\n * permanently failing contact showed up nowhere at all. */\nexport function failureCounts(\n journal: { event: string; detail: string }[],\n byStatus: Record,\n): { sendFailures: number; deadLettered: number; unreachable: number; deliveryFailed: number; deliveryUnknown: number } {\n let sendFailures = 0, deadLettered = 0, deliveryFailed = 0, deliveryUnknown = 0;\n // STANDING COUNT, from state, not a running total from the journal: a contact refused at\n // enrolment now gets a done_unreachable state entry (that is what stops the refusal repeating),\n // so counting the enroll_refused rows here as well would count every one of them twice.\n const unreachable = byStatus?.done_unreachable ?? 0;\n for (const r of journal ?? []) {\n if (r.event === \"send_failed\") sendFailures++;\n else if (r.event === \"dead_letter\") deadLettered++;\n else if (r.event === \"delivery_failed\") deliveryFailed++;\n else if (r.event === \"delivery_unknown\") deliveryUnknown++;\n }\n return { sendFailures, deadLettered, unreachable, deliveryFailed, deliveryUnknown };\n}\n\n\n=====FILE engine/registry-diff.ts =====\n// WHAT CHANGED IN A LIST SOMEBODY ELSE CONTROLS. v1.0, 5 August 2026.\n//\n// The watchdog watches two registries in Kim's CRM that nobody on this project owns: her 165\n// automations, and the eight knowledge bases Chloe answers customers from. Both can be edited by\n// Kim, by Kristian, or by an integration nobody remembers installing, and until v1.6 the knowledge\n// bases were not watched at all. The consolidated one was edited at 02:38 on 5 August and nothing\n// noticed.\n//\n// This is the comparison, on its own, so it can be tested. It lived inline in the watchdog before,\n// where it could only ever be checked by waiting for somebody to change something — which means a\n// check nobody has ever seen go off. Same rule as everywhere else in this project: a check that\n// cannot be shown to fail is not a check.\n//\n// It deliberately knows nothing about workflows or knowledge bases. It takes two maps of\n// id -> description and says what moved.\n\nexport type Registry = Record;\n\nexport type RegistryChange = {\n added: string[];\n removed: string[];\n edited: string[]; // \"old -> new\", so a reader can see what moved without opening anything\n changed: boolean;\n};\n\nexport function registryDiff(prev: Registry | null | undefined, now: Registry | null | undefined): RegistryChange {\n const a = prev && typeof prev === \"object\" ? prev : {};\n const b = now && typeof now === \"object\" ? now : {};\n const prevIds = Object.keys(a);\n const nowIds = Object.keys(b);\n const added = nowIds.filter((i) => !(i in a)).map((i) => b[i]);\n const removed = prevIds.filter((i) => !(i in b)).map((i) => a[i]);\n const edited = nowIds.filter((i) => i in a && a[i] !== b[i]).map((i) => `${a[i]} -> ${b[i]}`);\n return { added, removed, edited, changed: added.length + removed.length + edited.length > 0 };\n}\n\n/**\n * Is this an empty response we should DISTRUST rather than act on?\n *\n * A malformed-but-200 reply that returns an empty list must never overwrite a good baseline, or\n * the next pass fires \"everything was removed\" and the one after that fires \"everything was\n * added\". The watchdog learned this on the workflow registry; the knowledge-base watch inherits it\n * rather than rediscovering it.\n */\nexport function looksLikeAGlitch(nowCount: number, prevCount: number | null | undefined): boolean {\n return nowCount === 0 && (prevCount ?? 0) > 0;\n}\n\n/** The sentence, generated from the change, never written alongside it. */\nexport function registrySentence(c: RegistryChange, what: string): string {\n if (!c.changed) return `Nothing has moved in ${what} since the last look.`;\n const bits: string[] = [];\n if (c.edited.length) bits.push(`Edited: ${c.edited.slice(0, 3).join(\"; \")}.`);\n if (c.added.length) bits.push(`Added: ${c.added.slice(0, 3).join(\"; \")}.`);\n if (c.removed.length) bits.push(`Removed: ${c.removed.slice(0, 3).join(\"; \")}.`);\n const more = c.added.length + c.removed.length + c.edited.length - Math.min(3, c.edited.length) - Math.min(3, c.added.length) - Math.min(3, c.removed.length);\n if (more > 0) bits.push(`${more} more not listed here.`);\n return bits.join(\" \");\n}\n\n\n=====FILE engine/render.ts =====\n// MESSAGE RENDERING. Extracted from main.ts on 4 Aug 2026.\n//\n// WHY IT LIVES HERE: main.ts sits against a hard 80,000-character ceiling on the platform, and\n// these are the most self-contained functions in the file. Pulling them out also means the escape\n// and merge-field rules can be tested directly rather than only through a full engine run, which\n// matters because two of the fixes below came out of a security review, not a feature request.\n\n// Spec: dog name blank on ~70% of sampled contacts; fallback \"your puppy\" per the writing sheet's own\n// proposed default (§6 Q3). Messy-but-present values (multi-dog, junk like \"Money\") are used as-is —\n// that's an intake-form data-quality problem, not something to silently \"clean\" here.\nexport function resolveDogName(companyName: string | null | undefined): string {\n const v = (companyName ?? \"\").trim();\n return v.length > 0 ? v : \"your puppy\";\n}\n\n// Spec only discusses the blank-dog-name case explicitly. Added this small parallel safety net for a\n// blank first name (defensive, beyond spec's literal text) because \"Hi ,\" landing in a live message\n// would look obviously broken — same principle as the dog-name fallback, applied consistently.\nexport function resolveFirstName(firstName: string | null | undefined): string {\n const v = (firstName ?? \"\").trim();\n return v.length > 0 ? v : \"there\";\n}\n\nexport function applyMergeFields(template: string, firstName: string | null | undefined, companyName: string | null | undefined): string {\n // v1.8.1 — function form so $-patterns in names (\"Bo$$\") cannot corrupt the body.\n return template\n .replaceAll(\"{{FIRST_NAME}}\", () => resolveFirstName(firstName))\n .replaceAll(\"{{DOG_NAME}}\", () => resolveDogName(companyName));\n}\n\n// v1.8.1 — contact-typed fields and Kim's stories land in email HTML; escape BEFORE the\n// **bold** transform so markup we generate survives and markup anyone else typed does not.\nexport function escHtml(s: string): string {\n return s.replace(/[&<>\"']/g, (c) => ({ \"&\": \"&\", \"<\": \"<\", \">\": \">\", '\"': \""\", \"'\": \"'\" }[c] as string));\n}\n\nexport function mdBoldToHtml(text: string): string {\n return text.replace(/\\*\\*(.+?)\\*\\*/g, \"$1\");\n}\n\nexport function bodyToHtml(body: string, previewText?: string): string {\n const paragraphs = escHtml(body)\n .trim()\n .split(/\\n\\s*\\n/)\n .map((p) => `
${mdBoldToHtml(p.trim()).replace(/\\n/g, \"
\")}
`)\n .join(\"\\n\");\n // Hidden preheader technique so the approved \"preview text\" shows in an inbox list without being\n // visible in the opened email — standard, low-risk, one line.\n const preheader = previewText\n ? `
${escHtml(previewText)}
\\n`\n : \"\";\n return preheader + paragraphs;\n}\n\n\n\n=====FILE engine/report-logic.ts =====\n// FRIDAY REPORT, pure computation module. No network, no Deno APIs: everything here is\n// offline-testable, and every number the report shows is produced by a function in this file\n// with its formula written next to it. v1.0, 4 Aug 2026.\n//\n// ACCURACY RULES (the non-negotiables the report was commissioned under):\n// - numbers come from platform APIs upstream of these functions, never typed in\n// - every derived figure's formula is stored beside it (FORMULAS below, rendered in appendix)\n// - anything unverifiable renders as \"not tracked yet\", never a guess\n\n// `attribution` was PROVEN present on 190/190 contacts in the live account on 4 Aug 2026, while\n// the `source` column was blank on 154 of the same 190. The CRM records where a person came from\n// in a place its own source column never reads from. Optional, because every older caller and\n// every test builds a ContactLite without it.\nexport type Attribution = { medium?: string | null; campaign?: string | null };\nexport type ContactLite = { dateAdded: string; source: string | null; tags: string[]; attribution?: Attribution | null };\nexport type EventLite = { startTime: number; appointmentStatus: string; calendarId: string };\nexport type OppLite = { createdAt: string; status: string; monetaryValue: number; lastStageChangeAt?: string | null };\n\nexport type Window = { startMs: number; endMs: number; label: string };\n\n// Reporting week: Friday 00:00 ET back seven days. The report is read Friday morning, so the\n// most recent COMPLETE window is the seven days ending Thursday midnight.\nexport function reportWindows(nowMs: number, tzOffsetMin: number): { current: Window; previous: Window } {\n // tzOffsetMin: minutes to ADD to UTC to get business-local (ET = -240 in summer).\n const local = new Date(nowMs + tzOffsetMin * 60_000);\n const day = local.getUTCDay(); // 0 Sun .. 5 Fri .. 6 Sat, in local terms\n // most recent Friday 00:00 local, strictly in the past or today\n const sinceFri = (day - 5 + 7) % 7;\n const fri = Date.UTC(local.getUTCFullYear(), local.getUTCMonth(), local.getUTCDate() - sinceFri);\n const friUtcMs = fri - tzOffsetMin * 60_000; // back to real UTC instant of local Friday 00:00\n const week = 7 * 86_400_000;\n return {\n current: { startMs: friUtcMs - week, endMs: friUtcMs, label: \"this week\" },\n previous: { startMs: friUtcMs - 2 * week, endMs: friUtcMs - week, label: \"last week\" },\n };\n}\n\nexport function inWindow(iso: string | number, w: Window): boolean {\n const t = typeof iso === \"number\" ? iso : Date.parse(iso);\n return Number.isFinite(t) && t >= w.startMs && t < w.endMs;\n}\n\n// ---- the formulas, stored as data so the appendix can print them verbatim -----------------------\nexport const FORMULAS: Record = {\n \"New inquiries\": \"how many new people landed in the CRM during the seven days, counted by the date the CRM stamped on them\",\n \"Pup Talks on the calendar\": \"how many Pup Talk appointments had a start time inside the seven days, not counting cancelled ones\",\n \"Showed\": \"how many of those the CRM marked as showed up\",\n \"Show rate\": \"showed divided by booked; the percentage is only quoted when at least five were booked, because a rate built on two appointments misleads\",\n \"Free Training Day\": \"the same counting, done against both Free Training Day calendars\",\n \"New customers\": \"people whose deal reached the Customer stage in the CRM during the week, counted in the week they got there, not the week they first got in touch\",\n \"Up or down on last week\": \"this week against the same count for the seven days before it, shown as level, or up or down by a percentage\",\n \"Cost per inquiry\": \"ad spend divided by new inquiries; appears once the ad account is linked, and is never estimated before then\",\n \"Did the ad leads land\": \"what the ad platform claims it delivered, side by side with what actually arrived in the CRM the same week\",\n};\n\nexport function countContacts(cs: ContactLite[], w: Window): number {\n return cs.filter((c) => inWindow(c.dateAdded, w)).length;\n}\n\nexport function sourceBreakdown(cs: ContactLite[], w: Window): Array<{ source: string; n: number }> {\n const m = new Map();\n for (const c of cs.filter((c) => inWindow(c.dateAdded, w))) {\n const s = (c.source || \"no source recorded\").trim().toLowerCase() || \"no source recorded\";\n m.set(s, (m.get(s) ?? 0) + 1);\n }\n return [...m.entries()].map(([source, n]) => ({ source, n })).sort((a, b) => b.n - a.n);\n}\n\nexport function countEvents(evs: EventLite[], w: Window): { booked: number; showed: number; noshow: number; cancelled: number } {\n const live = evs.filter((e) => inWindow(e.startTime, w));\n const ok = live.filter((e) => e.appointmentStatus !== \"cancelled\" && e.appointmentStatus !== \"invalid\");\n return {\n booked: ok.length,\n showed: ok.filter((e) => e.appointmentStatus === \"showed\").length,\n noshow: ok.filter((e) => e.appointmentStatus === \"noshow\" || e.appointmentStatus === \"no-show\").length,\n cancelled: live.length - ok.length,\n };\n}\n\nexport function wonOpps(os: OppLite[], w: Window): { count: number; value: number } {\n const won = os.filter((o) => o.status === \"won\" && inWindow(o.lastStageChangeAt || o.createdAt, w));\n return { count: won.length, value: won.reduce((a, o) => a + (Number(o.monetaryValue) || 0), 0) };\n}\n\n// weekly buckets for the 8-week chart, oldest first\n// The reader-facing name for each raw medium string. Anything not in this map is passed through\n// as itself rather than bucketed into \"other\", so a new channel appears by name instead of\n// silently vanishing into a catch-all nobody investigates.\nconst MEDIUM_LABEL: Record = {\n facebook: \"Facebook\", instagram: \"Instagram\", form: \"a form on your website\",\n chat_widget: \"the chat box on your website\", conversation: \"a direct message\",\n other: \"somewhere else\", email: \"email\", sms: \"text message\", phone: \"phone call\",\n};\nexport function prettyMedium(m: string | null | undefined): string {\n const k = (m || \"\").trim().toLowerCase();\n if (!k) return \"not recorded\";\n return MEDIUM_LABEL[k] ?? k.replace(/_/g, \" \");\n}\n// Where people actually came from, read from the attribution record rather than the source column.\nexport function channelBreakdown(cs: ContactLite[], w: Window): Array<{ source: string; n: number }> {\n const m = new Map();\n for (const c of cs.filter((c) => inWindow(c.dateAdded, w))) {\n const label = prettyMedium(c.attribution?.medium);\n m.set(label, (m.get(label) ?? 0) + 1);\n }\n return [...m.entries()].map(([source, n]) => ({ source, n }))\n .sort((a, b) => (b.n - a.n) || a.source.localeCompare(b.source));\n}\n// Named campaigns. A campaign name is ad-platform text, so it reaches the page as data and must\n// be escaped there like any other untrusted string.\nexport function campaignBreakdown(cs: ContactLite[], w: Window): Array<{ name: string; n: number }> {\n const m = new Map();\n for (const c of cs.filter((c) => inWindow(c.dateAdded, w))) {\n const name = (c.attribution?.campaign || \"\").trim();\n if (!name) continue;\n m.set(name, (m.get(name) ?? 0) + 1);\n }\n return [...m.entries()].map(([name, n]) => ({ name, n }))\n .sort((a, b) => (b.n - a.n) || a.name.localeCompare(b.name));\n}\n// How many of a window's contacts can be placed at all. This is the honest headline for the\n// section: \"we can account for X of Y\", never a bare count of the unexplained.\nexport function attributionCoverage(cs: ContactLite[], w: Window): { known: number; total: number } {\n const inW = cs.filter((c) => inWindow(c.dateAdded, w));\n return { known: inW.filter((c) => (c.attribution?.medium || \"\").trim()).length, total: inW.length };\n}\n\n// R32 (10 Aug 2026). Paid-social arrivals, read from the ARRIVAL RECORD, never from `source`.\n// Case-insensitive on purpose: channelBreakdown returns display labels from prettyMedium\n// (\"Facebook\", \"Instagram\"), so a case-sensitive regex here reproduces the exact bug this replaces.\nexport const PAID_SOCIAL_RE = /facebook|instagram|meta|messenger/i;\nexport function facebookLanded(cs: ContactLite[], w: Window): number {\n return channelBreakdown(cs, w).filter((s) => PAID_SOCIAL_RE.test(s.source)).reduce((a, s) => a + s.n, 0);\n}\n\nexport function weeklyBuckets(cs: ContactLite[], endMs: number, weeks: number): number[] {\n const wMs = 7 * 86_400_000;\n const out = new Array(weeks).fill(0);\n for (const c of cs) {\n const t = Date.parse(c.dateAdded);\n if (!Number.isFinite(t) || t >= endMs || t < endMs - weeks * wMs) continue;\n const idx = weeks - 1 - Math.floor((endMs - 1 - t) / wMs);\n if (idx >= 0 && idx < weeks) out[idx]++;\n }\n return out;\n}\n\nexport function pct(n: number, d: number): string {\n if (!d) return \"n/a\";\n return Math.round((n / d) * 100) + \"%\";\n}\n\nexport function deltaWord(cur: number, prev: number): string {\n if (cur === prev) return \"level with last week\";\n if (prev === 0) return cur > 0 ? \"up from zero last week\" : \"level with last week\";\n const ch = Math.round(((cur - prev) / prev) * 100);\n return ch > 0 ? `up ${ch}% on last week` : `down ${Math.abs(ch)}% on last week`;\n}\n\nexport function money(n: number): string {\n return \"$\" + n.toLocaleString(\"en-US\", { minimumFractionDigits: 2, maximumFractionDigits: 2 });\n}\n\n// ---- draft commentary: rule-based sentences from the computed numbers. Never speculates. --------\n// Marked DRAFT in the page; the human tops and tails before it goes anywhere.\nexport function draftCommentary(f: {\n enq: number; enqPrev: number;\n ptBooked: number; ptPrev: number; ptShowed: number;\n wonCount: number; wonValue: number; wonPrevValue: number;\n topSource: string | null;\n adTracked: boolean;\n}): string[] {\n const lines: string[] = [];\n lines.push(\n `${f.enq} new ${f.enq === 1 ? \"inquiry\" : \"inquiries\"} came in this week, ${deltaWord(f.enq, f.enqPrev)}.` +\n (f.topSource === \"no source recorded\"\n ? ` Most arrived without a source recorded in the CRM, a tracking gap worth closing.`\n : f.topSource\n ? ` The biggest source was ${f.topSource}.`\n : \"\"),\n );\n lines.push(\n `${f.ptBooked} Pup Talk${f.ptBooked === 1 ? \" was\" : \"s were\"} on the calendar (${deltaWord(f.ptBooked, f.ptPrev)})` +\n (f.ptBooked >= 5 ? `, and ${f.ptShowed} of them showed (${pct(f.ptShowed, f.ptBooked)}).` : f.ptBooked > 0 ? `, ${f.ptShowed} showed.` : \".\"),\n );\n // The CRM holds no deal values (proven live: every opportunity is $0 and none are flagged\n // won), so this counts PEOPLE reaching the Customer stage and never implies a revenue figure.\n if (f.wonCount > 0) {\n lines.push(`${f.wonCount} ${f.wonCount === 1 ? \"person\" : \"people\"} reached the Customer stage this week.`);\n } else {\n lines.push(`Nobody reached the Customer stage in the CRM this week.`);\n }\n if (!f.adTracked) {\n lines.push(`Ad spend and cost per lead are not tracked yet, they appear the week the ad platform tokens are connected.`);\n }\n return lines;\n}\n\n",[517],"df0f7193-df89-4cb2-8164-d3b18c4392c7","SOURCE-BUNDLE.part8.txt","7c8dcd00-91bc-11f1-8e89-1607ee4eb77e",1094,["D",1786801897743],"THE DOGS SPOT — SOURCE BUNDLE (part 8 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (1 of 116 files)\n\n\n================================================================================================\n=====FILE engine/puppy_path_v1.1.ts#1 =====\n// PUPPY PATH ENGINE v1.1 — nurture automation for The Dogs Spot's puppy leads (built 27 Ju\n// (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\n\n// ---- Node/tsx compatibility shim, for the local harness only. Full note: NOTES v1.10.\ndeclare const Deno: { env: { get(key: string): string | undefined } };\nif (typeof (globalThis as any).Deno === \"undefined\") {\n (globalThis as any).Deno = { env: { get: (k: string) => (globalThis as any).process?.env?.[k] } };\n}\n\n// Message copy + display constants live in ./puppy-messages.ts (split for val.town's 80k/file cap).\nimport {\n MAIN_SEQUENCE,\n BRANCH_A,\n BRANCH_B,\n PHONE_DISPLAY,\n REAL_BOOKING_URL,\n SHORT_BOOKING_LINK,\n} from \"./puppy-messages.ts\";\nimport type { Channel, MessageTemplate } from \"./puppy-messages.ts\";\n// v1.7 — slow track (taper). Copy+cadence in ./taper-messages.ts; Kim's spec (3 Aug): weekly x4,\n// fortnightly x13, then monthly forever, no asks. Same rails: reply pauses, booking exits, consent.\nimport { nextSlowTouch, monthlyTemplateFor, monthlyTemplateAvoidingRepeat } from \"./taper-messages.ts\";\n// v1.8 — Kim's real stories, one data file, additive slots. Null slots render as nothing.\nimport { readChannelConsent } from \"./consent.ts\";\n// v1.9 — reachability, dead letters, delivery, opt-out words. Extracted for this file's ceiling.\nimport {\n missingChannel, reachabilityExit, enrolmentBar, backoffBar, onSendFailure, onDeliveryStatus,\n sendReceipt, convoExtras, honourOptOut, failureCounts, FRESH_FAILURE_FIELDS, DEAD_LETTER_STATUSES,\n reEnrollable, refusedBefore,\n} from \"./reachability.ts\";\nimport type { DeadLetterStatus, FailureFields, ReplyStatus, Effects } from \"./reachability.ts\";\nimport { resolveStories } from \"./kim-stories.ts\";\nimport { appendRunStamp } from \"./cadence.ts\";\nimport { dryScan } from \"./puppy-detect.ts\";\nimport { resolveDogName, resolveFirstName, applyMergeFields, escHtml, bodyToHtml } from \"./render.ts\";\n\n// ---- reference IDs (spec §2, all verified live this session unless noted) ------------------------\n\nconst GHL = \"https://services.leadconnectorhq.com\";\n// v1.2 — TOKEN RESOLUTION: GHL_TOKEN env var, else private blob `puppy_config`. Blob fallback\n// exists because val.town has no env-var API. Code is public; token never hardcoded. Full note:\n// NOTES-v1.4.md.\nlet TOKEN: string | undefined = Deno.env.get(\"GHL_TOKEN\");\nasync function resolveToken(): Promise {\n if (TOKEN) return TOKEN;\n try {\n const blob = await getBlobModule();\n const cfg = await blob.getJSON(\"puppy_config\").catch(() => null);\n if (cfg?.ghlToken) TOKEN = String(cfg.ghlToken);\n } catch { /* stays undefined; j() will throw a clear auth error */ }\n return TOKEN;\n}\nconst LOC = \"BQHJ19uohldYe3eqA0bl\";\nconst MAIN_PIPELINE_ID = \"FXt1UpCVBufbF0v3pfyf\"; // \"1) Initial Lead Pipeline\"\n\nconst STAGE = {\n NEW_LEAD: \"ccb18375-9aa1-40aa-a071-1581ca739533\",\n LEAD_NURTURE: \"00d0f792-38e5-444e-8995-a1be96e77d3b\",\n FREE_TRAINING_DAY: \"43ea02b4-529b-4063-b638-447414d603d2\",\n PUP_TALK: \"379d1dd2-fc18-4720-a840-e8f8ed703bb9\",\n CXLD_PUPTALK_TRAINING_DAY: \"4b5599d3-a5ad-4b8c-8388-4d5507c22fd7\",\n NO_SALE_NURTURE: \"e4511876-0adb-417b-a6be-8460a194f913\",\n DISQUALIFIED: \"38826f17-1d0e-4bac-b53e-349b67c2c79d\",\n NO_SHOW: \"f3f41e5e-edaf-4ef1-8cec-c4cccd4ec5c2\",\n ONBOARDING: \"76c72f7f-56bd-4f44-964d-aa4cbbec7d25\",\n CUSTOMER: \"fd821b4e-bbe6-44de-b754-fa80e4823616\",\n WON_PAID: \"ae173310-f8b1-4399-acb7-ef1fc03d3697\",\n} as const;\n\nconst PUP_TALK_CALENDAR_ID = \"qHuYJ0NEqzibnoqf5Cw3\";\n\n\n// v1.1: env-overridable, and now understood as the HUMAN ENROLLMENT SWITCH, not auto-discovery of a\n// pre-existing population — live check 27 Jul: zero contacts carry it (or any spelling variant), so\n// applying it is how a human puts someone on the path. READ ONLY here, never written by this engine.\nconst TAG_SOURCE_SIGNAL = Deno.env.get(\"TAG_SOURCE_SIGNAL\") || \"nurture - puppy\";\nconst TAG_ENROLLED = \"puppy-path-v1\"; // minted by this engine, applied on enrollment\n\n// v1.1 send-window + surge-hold knobs (see header addendum). Read per call, not once at module load —\n// costs nothing at this call volume and lets the offline harness flip them per test section; under\n// val.town the env is static so behavior is identical either way.\nconst sendWindowStartHour = () => Number(Deno.env.get(\"SEND_WINDOW_START_HOUR\") ?? \"9\");\nconst sendWindowEndHour = () => Number(Deno.env.get(\"SEND_WINDOW_END_HOUR\") ?? \"19\");\nconst smsSundayOk = () => (Deno.env.get(\"SMS_SUNDAY_OK\") ?? \"false\") === \"true\";\nconst enrollSurgeThreshold = () => Number(Deno.env.get(\"ENROLL_SURGE_THRESHOLD\") ?? \"25\");\nconst acknowledgeSurge = () => (Deno.env.get(\"ACKNOWLEDGE_SURGE\") ?? \"false\") === \"true\";\nconst BUSINESS_TZ = \"America/New_York\";\n\n// v1.2 hardening knobs (30 Jul). All env-overridable, read per call. Full rationale: NOTES.\nconst minSendGapHours = () => Number(Deno.env.get(\"MIN_SEND_GAP_HOURS\") ?? \"2\");\nconst maxSendsPerRun = () => Number(Deno.env.get(\"MAX_SENDS_PER_RUN\") ?? \"20\");\nconst maxSendsPerDay = () => Number(Deno.env.get(\"MAX_SENDS_PER_DAY\") ?? \"50\");\n// v1.4 — how often a contact gets a full CRM check even when nothing is due. The floor under\n// due-first filtering: cheap must not become blind.\n// v1.4 — how long a reply can sit unanswered before the engine escalates and releases the contact.\nconst pauseTimeoutDays = () => Number(Deno.env.get(\"PAUSE_TIMEOUT_DAYS\") ?? \"14\");\n// v1.5 R27 — how long the engine stands down after ANY other system messages the contact. 24h is one\n// full business cycle: long enough that a customer never gets our email on the same day as a workflow\n// text, short enough that a 21-day sequence still completes near schedule (a deferred step is never\n// dropped, it waits for the next run).\nconst foreignQuietHours = () => Number(Deno.env.get(\"FOREIGN_QUIET_HOURS\") ?? \"24\");\n// Tolerance when deciding \"was that outbound ours?\" — clock skew between our send and GHL stamping\n// the conversation. Anything inside this window of our own lastSentAt is treated as ours.\nconst OURS_TOLERANCE_MS = 5 * 60 * 1000;\nconst safetySweepHours = () => Number(Deno.env.get(\"SAFETY_SWEEP_HOURS\") ?? \"24\");\nconst RUN_LOCK_TTL_MS = 10 * 60 * 1000; // a run that started >10 min ago is presumed dead\n\nconst sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));\n\n// Rule 8's real signal — NOT CONFIRMED LIVE this session, see gap #2 in the header comment. Left as a\n// clearly-named constant so wiring in the real value later is a one-line change, not a re-guess.\nconst PUP_TALK_DECLINED_TAG = \"TDS-Declined\";\n\nconst HOUR_MS = 3600 * 1000;\nconst DAY_MS = 24 * HOUR_MS;\n\n// R38: mode = env var if set, else blob puppy_mode {live:true} (api.ts arm route). Fails safe.\nexport function resolveMode(envVal: string | undefined | null, blobVal: unknown): boolean {\n if (envVal != null) return envVal !== \"false\"; // practice unless the literal string false\n const live = !!(blobVal && typeof blobVal === \"object\" && (blobVal as any).live === true);\n return !live; // no blob, or malformed = practice\n}\nlet TEST_MODE = resolveMode(Deno.env.get(\"TEST_MODE\"), null);\n\n// ---- data model (spec §4, verbatim) ---------------------------------------------------------------\n\ntype PuppyStatus =\n | \"main\" | \"awaiting_appt_outcome\" | \"branch_a\" | \"branch_b\" | \"slow_track\"\n | \"paused_reply\" | \"done_booked\" | \"done_customer\" | \"done_hard_exit\"\n | \"done_soft_21d\" | \"done_branch_complete\" | \"done_not_enrolled\" | DeadLetterStatus;\n\n// v1.7 — done_soft_21d stays terminal for LEGACY pre-taper contacts only (no retroactive\n// enrollment). New 21-day completions flow into slow_track instead.\nconst TERMINAL_STATUSES = new Set([\n \"done_booked\", \"done_customer\", \"done_hard_exit\", \"done_soft_21d\", \"done_branch_complete\",\n \"done_not_enrolled\", // v1.10 — refused AT enrolment; never on the path, so never a win. NOTES v1.10.\n ...DEAD_LETTER_STATUSES, // v1.9 — done_unreachable / done_send_failed. See reachability.ts.\n]);\n\ntype PuppyState = FailureFields & {\n status: PuppyStatus;\n enteredAt: string; // ISO — main sequence start\n lastMainStepSent: number; // 0..8, count of main-sequence messages sent so far\n branchAnchorAt: string | null; // ISO — when branch A/B started\n lastBranchStepSent: number; // 0..2\n pausedForReplyAt: string | null;\n exitReason: string | null; // free text, for humans reading the blob\n lastCheckedAt: string; // ISO, updated every run this contact is touched\n lastSentAt?: string | null; // v1.2 — ISO of the last successful send to this contact (min-gap pacing)\n // v1.4 — R24: monetaryValue was read on every opportunity and thrown away, while the one question\n // the client judges a report by is \"how much revenue did that produce\". Captured at exit.\n exitValue?: number | null; // monetaryValue of the opportunity that ended the sequence\n exitStepsSent?: number | null; // how many messages they had received when they converted\n lastSentStepId?: string | null; // v1.4 — R23: the step ID, so editing copy cannot silently re-point anyone\n // v1.7 — slow track. Optional so pre-v1.7 blobs deserialize untouched; readers default them.\n slowAnchorAt?: string | null; // ISO — when the contact entered the slow track (21-day completion)\n lastSlowStepSent?: number; // count of slow-track messages sent (weekly+fortnightly+monthly)\n};\n\nfunction freshState(enteredAt: string): PuppyState {\n return {\n status: \"main\", enteredAt, lastMainStepSent: 0, branchAnchorAt: null,\n lastBranchStepSent: 0, pausedForReplyAt: null, exitReason: null, lastCheckedAt: enteredAt,\n lastSentAt: null, exitValue: null, exitStepsSent: null, lastSentStepId: null,\n slowAnchorAt: null, lastSlowStepSent: 0, ...FRESH_FAILURE_FIELDS,\n };\n}\n\n// ---- pure helpers: timing, merge fields, rendering ------------------------------------------------\n\nfunction isDue(offsetHours: number, anchorIso: string, nowMs: number): boolean {\n return nowMs >= new Date(anchorIso).getTime() + offsetHours * HOUR_MS;\n}\n\n// v1.1 — business-local wall clock for a UTC instant. Intl with an explicit timeZone is deterministic\n// and DST-correct on both Deno and Node; no date library needed for two fields.\nfunction businessLocalParts(nowMs: number): { hour: number; weekday: string } {\n const parts = new Intl.DateTimeFormat(\"en-US\", {\n timeZone: BUSINESS_TZ,\n hour12: false,\n hour: \"2-digit\",\n weekday: \"short\",\n }).formatToParts(new Date(nowMs));\n const get = (t: string) => parts.find((p) => p.type === t)?.value ?? \"\";\n // Intl gives \"24\" for midnight under hour12:false+2-digit in some engines; normalize to 0.\n const hour = Number(get(\"hour\")) % 24;\n return { hour, weekday: get(\"weekday\") };\n}\n\n// v1.1 — send-window gate (header addendum #3). Pure given (nowMs, channel); env knobs are read once\n// at module load. Emails are allowed any day inside the hour window; SMS additionally respects the\n// closed-on-Sundays business identity unless SMS_SUNDAY_OK.\nfunction inSendWindow(channel: Channel, nowMs: number): { ok: boolean; reason: string } {\n const start = sendWindowStartHour();\n const end = sendWindowEndHour();\n const { hour, weekday } = businessLocalParts(nowMs);\n if (hour < start || hour >= end) {\n return { ok: false, reason: `outside ${start}:00–${end}:00 ${BUSINESS_TZ} (local hour ${hour})` };\n }\n if (channel === \"sms\" && weekday === \"Sun\" && !smsSundayOk()) {\n return { ok: false, reason: \"no SMS on Sundays (business closed)\" };\n }\n return { ok: true, reason: \"\" };\n}\n\ntype RenderedMessage =\n | { channel: \"email\"; subject: string; html: string }\n | { channel: \"sms\"; text: string };\n\n// Appended to every rendered message. Kept as constants so the wording is in exactly one place.\nconst SMS_OPTOUT = \"\\n\\nReply STOP to stop these texts.\";\nconst EMAIL_OPTOUT =\n \"\\n\\n---\\nYou're getting this because you inquired with The Dogs Spot. \" +\n \"Reply UNSUBSCRIBE and we'll take you off these emails.\\n\" +\n \"The Dogs Spot, 643 Pleasant Hill Church Rd, Ellabell, GA 31308\";\n\nfunction renderStep(\n step: MessageTemplate,\n contact: { firstName: string | null | undefined; companyName: string | null | undefined },\n opts: { testMode: boolean },\n): RenderedMessage {\n const prefix = opts.testMode ? \"[TEST] \" : \"\";\n // v1.8 — story slots resolve before merge fields; a null slot leaves no trace.\n const resolvedBody = applyMergeFields(resolveStories(step.bodyTemplate), contact.firstName, contact.companyName);\n\n // ---- v1.4 (2 Aug) — OPT-OUT FURNITURE, appended at render time, never written into the c\n // (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\n if (step.channel === \"email\") {\n const resolvedPreview = step.previewText\n ? applyMergeFields(step.previewText, contact.firstName, contact.companyName)\n : undefined;\n return {\n channel: \"email\",\n subject: prefix + applyMergeFields(step.subject ?? \"\", contact.firstName, contact.companyName),\n html: bodyToHtml(resolvedBody + EMAIL_OPTOUT, resolvedPreview),\n };\n }\n return { channel: \"sms\", text: prefix + resolvedBody + SMS_OPTOUT };\n}\n\n// ---- facts / decision types -------------------------------------------------------------------\n\ntype ApptFact = {\n id: string;\n startTime: number; // epoch ms\n endTime: number; // epoch ms\n appointmentStatus: string;\n deleted: boolean;\n};\n\ntype OppFact = {\n id: string;\n pipelineId: string;\n pipelineStageId: string;\n monetaryValue: number;\n status: string;\n};\n\ntype ContactFact = {\n id: string;\n firstName: string;\n companyName: string | null;\n dnd: boolean;\n noEmail?: boolean; // R37: contact has no email address at all; email steps skip DELIBERATELY\n noPhone?: boolean; // R39: same, for SMS. Its absence was the spin. See reachability.ts.\n};\n\ntype Facts = {\n now: number;\n contact: ContactFact;\n opportunities: OppFact[];\n pupTalkAppt: ApptFact | null;\n declinedSignal: boolean;\n hasUnansweredInboundReply: boolean;\n conversationCheckFailed: boolean;\n // v1.5 R27 — epoch ms of the newest outbound message on this contact's thread that this engine did\n // NOT send, or null when there is none / it cannot be told apart from ours. See sendGate.\n foreignOutboundAt: number | null;\n // v1.6 R28 — per-channel consent, read from GHL's dndSettings. true = this channel is opted out.\n channelBlocked: { email: boolean; sms: boolean };\n optOutRequested?: boolean; // R39 — an inbound body matched an opt-out keyword. reachability.ts.\n};\n\ntype Decision =\n | { kind: \"hard_exit\"; status: \"done_hard_exit\" | \"done_customer\" | \"done_booked\" | DeadLetterStatus; reason: string }\n | { kind: \"pause_reply\"; isNewPause: boolean }\n | { kind: \"advance_status\"; status: \"awaiting_appt_outcome\" | \"branch_a\" | \"branch_b\" | \"slow_track\"; branchAnchorAt?: string }\n | { kind: \"soft_exit_21d\" }\n | { kind: \"branch_complete\" }\n | { kind: \"send\"; sequence: \"main\" | \"branch_a\" | \"branch_b\" | \"slow\"; stepIndex: number }\n | { kind: \"skip_step\"; sequence: \"main\" | \"branch_a\" | \"branch_b\" | \"slow\"; stepIndex: number; reason: string }\n | { kind: \"skip\"; reason: string };\n\n// v1.7 — slow template for a progression index AT a moment. Weekly/fortnightly fixed by index;\n// monthly picked by the send's calendar month (July=heat, Dec=holidays — as promised to Kim).\n// Shared by decideAction AND the executor so decided and sent templates cannot drift.\nfunction slowTemplateAt(sentCount: number, nowMs: number, lastSentId?: string | null): { tpl: MessageTemplate; offsetHours: number; phase: string } {\n // v1.7.1 — clamp garbage counters (NaN/negative/string blobs) instead of letting an out-of-range\n // index fall through to \"send monthly now\"; monthly fallback only ever fires in the monthly phase.\n const clean = Math.max(0, Math.floor(Number(sentCount)) || 0);\n const n = nextSlowTouch(clean);\n const tpl = n.phase === \"monthly\" ? monthlyTemplateAvoidingRepeat(new Date(nowMs), lastSentId) : n.template!;\n return { tpl, offsetHours: n.offsetHours, phase: n.phase };\n}\n\nfunction pickPrimaryOpportunity(opps: OppFact[]): OppFact | null {\n return opps.find((o) => o.pipelineId === MAIN_PIPELINE_ID) ?? opps[0] ?? null;\n}\n\n// \"Live\" = not cancelled, not invalid, not soft-deleted. Anything else (new / confirmed / showed /\n// noshow) counts as \"they booked\" for rule 6's purposes — the outcome gets sorted out by rules 7/8.\nfunction apptIsLiveBooked(appt: ApptFact | null): boolean {\n if (!appt || appt.deleted) return false;\n return appt.appointmentStatus !== \"cancelled\" && appt.appointmentStatus !== \"invalid\";\n}\n\n// ---- the core state machine (spec §5). Pure, first-match-wins, same order every pass. NOTES v1.10.\nfunction channelBar(f: Facts, ch: \"email\" | \"sms\"): string | null {\n const gone = missingChannel(f.contact, ch); // R37/R39: no address at all, either channel\n if (gone) return gone;\n if (f.channelBlocked[ch]) return `opted out of ${ch}`;\n return null;\n}\n\nfunction decideAction(f: Facts, s: PuppyState): Decision {\n // Rule 1 + 2 — DND / unsubscribed. Top-level `dnd` = full opt-out, hard exit here. Since v1.6\n // (R28) per-channel opt-outs in `dndSettings` are ALSO read — not here, but as f.channelBlocked,\n // which skip-consumes steps on a blocked channel while the other channel carries on. Both layers\n // are live; this rule is the total-stop one.\n if (f.contact.dnd) {\n return { kind: \"hard_exit\", status: \"done_hard_exit\", reason: \"dnd\" };\n }\n\n // Rules 1b/1c (v1.9) — said stop in words / no way to reach them at all. BELOW rule 1 and ABOVE\n // rule 3, deliberately; both orderings are pinned by tests. Full reasoning in reachability.ts.\n { const rx = reachabilityExit(f); if (rx) return rx; }\n\n const primaryOpp = pickPrimaryOpportunity(f.opportunities);\n\n // Rule 3 — Disqualified stage (human override, outranks everything below it).\n if (primaryOpp?.pipelineStageId === STAGE.DISQUALIFIED) {\n return { kind: \"hard_exit\", status: \"done_hard_exit\", reason: \"disqualified\" };\n }\n\n // Rule 4 — became a paying customer. v1.2: scans ALL opportunities, not just primary (fuzz\n // round finding; full note in NOTES-v1.4.md).\n const becameCustomer = f.opportunities.some(\n (o) => o.pipelineStageId === STAGE.CUSTOMER || o.pipelineStageId === STAGE.WON_PAID || o.monetaryValue > 0,\n );\n if (becameCustomer) {\n return { kind: \"hard_exit\", status: \"done_customer\", reason: \"became a customer\" };\n }\n\n // Rule 4b — booked something else entirely (Free Training Day). NOT an explicit numbered r\n // (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\n if (primaryOpp?.pipelineStageId === STAGE.FREE_TRAINING_DAY) {\n return { kind: \"hard_exit\", status: \"done_booked\", reason: \"booked Free Training Day — sequence ends per writing sheet §4\" };\n }\n\n // Rule 5 — inbound reply pending, or: couldn't check at all (fail closed — see header gap #1).\n // conversationCheckFailed must be checked BEFORE hasUnansweredInboundReply: an unreadable signal is\n // never treated as \"confirmed no reply,\" because that would let sends continue for someone who may\n // well have replied — exactly the failure this rule exists to prevent.\n if (f.conversationCheckFailed) {\n return { kind: \"skip\", reason: \"conversation check failed (live API scope gap) — not sending until resolved\" };\n }\n if (f.hasUnansweredInboundReply) {\n // \"First match wins\" still applies every run, so this keeps matching (and keeps blocking rule 10)\n // for as long as the reply sits unanswered — but the SIDE EFFECT (timestamping the pause, creating\n // a task) only happens the first time, guarded by isNewPause. Otherwise every run would create a\n // fresh duplicate task for the same unanswered reply.\n return { kind: \"pause_reply\", isNewPause: s.status !== \"paused_reply\" };\n }\n\n // Rule 6 — a live Pup Talk booking -> awaiting_appt_outcome. Scoped to the Pup Talk calendar\n // (branch copy is Pup-Talk-specific; FTD handled by 4b; full note in NOTES-v1.4.md).\n // v1.7.1 — the slow arm requires the appointment to POSTDATE slow entry (mirrors 6b): a stale\n // historical appointment must not yank a taper contact into branch copy.\n if (s.status === \"main\" && apptIsLiveBooked(f.pupTalkAppt)) {\n return { kind: \"advance_status\", status: \"awaiting_appt_outcome\" };\n }\n if (\n s.status === \"slow_track\" && f.pupTalkAppt && apptIsLiveBooked(f.pupTalkAppt) &&\n f.pupTalkAppt.startTime > new Date(s.slowAnchorAt ?? s.enteredAt).getTime()\n ) {\n return { kind: \"advance_status\", status: \"awaiting_appt_outcome\" };\n }\n\n // Rule 6b (v1.2) — REBOOKED while in a branch. Found independently by the adversarial revi\n // (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\n if (\n (s.status === \"branch_a\" || s.status === \"branch_b\") &&\n f.pupTalkAppt &&\n apptIsLiveBooked(f.pupTalkAppt) &&\n s.branchAnchorAt &&\n f.pupTalkAppt.startTime > new Date(s.branchAnchorAt).getTime()\n ) {\n return { kind: \"advance_status\", status: \"awaiting_appt_outcome\" };\n }\n\n // Rule 7 — awaiting -> branch_a (missed): time passed, no show, no cancel. NOTES has the full table.\n if (\n s.status === \"awaiting_appt_outcome\" && s.slowAnchorAt && f.pupTalkAppt &&\n f.pupTalkAppt.appointmentStatus === \"cancelled\"\n ) {\n return { kind: \"advance_status\", status: \"slow_track\" };\n }\n\n if (\n s.status === \"awaiting_appt_outcome\" &&\n f.pupTalkAppt &&\n f.now >= f.pupTalkAppt.endTime &&\n f.pupTalkAppt.appointmentStatus !== \"showed\" &&\n f.pupTalkAppt.appointmentStatus !== \"cancelled\"\n ) {\n return {\n kind: \"advance_status\",\n status: \"branch_a\",\n branchAnchorAt: new Date(f.pupTalkAppt.endTime).toISOString(),\n };\n }\n\n // Rule 8 — awaiting -> branch_b (showed, then declined). declinedSignal NOT CONFIRMED LIVE\n // (header gap #2); branchAnchorAt uses \"now\" per spec's fallback.\n if (\n s.status === \"awaiting_appt_outcome\" &&\n f.pupTalkAppt &&\n f.pupTalkAppt.appointmentStatus === \"showed\" &&\n f.declinedSignal\n ) {\n return { kind: \"advance_status\", status: \"branch_b\", branchAnchorAt: new Date(f.now).toISOString() };\n }\n\n // Rule 9 — 21-day completion. Gated on message 8 having actually SENT, not elapsed time alone\n // (else this outranks rule 10 on the very run msg 8 becomes due and it never sends —\n // NOTES-v1.4.md). Stage never auto-moved; that is Kim's call.\n if (\n s.status === \"main\" &&\n s.lastMainStepSent >= MAIN_SEQUENCE.length &&\n f.now >= new Date(s.enteredAt).getTime() + 21 * DAY_MS\n ) {\n return { kind: \"soft_exit_21d\" };\n }\n\n // Rule 9b — branch exhausted -> done_branch_complete (the type's own terminal; a contact must\n // not sit re-evaluated forever with nothing left to send). NOTES-v1.4.md.\n if (s.status === \"branch_a\" && s.lastBranchStepSent >= BRANCH_A.length) {\n return { kind: \"branch_complete\" };\n }\n if (s.status === \"branch_b\" && s.lastBranchStepSent >= BRANCH_B.length) {\n return { kind: \"branch_complete\" };\n }\n\n // Rule 10 — otherwise, send whatever's next due. v1.1: a due step additionally waits for the send\n // window (inSendWindow). v1.2: and for the per-contact min-gap floor — after an outage, several\n // overdue steps space out ~2h apart instead of one per cron tick. Every deferral leaves state\n // untouched, so a later run simply picks it up.\n const sendGate = (channel: Channel): { ok: boolean; reason: string } => {\n const w = inSendWindow(channel, f.now);\n if (!w.ok) return w;\n if (s.lastSentAt) {\n const gapMs = minSendGapHours() * HOUR_MS;\n const sinceLast = f.now - new Date(s.lastSentAt).getTime();\n // v1.7 — sinceLast >= 0 guard (mirrors R27): a future-dated lastSentAt (clock skew, restored\n // blob) must not freeze the contact until that future date; negative elapsed = ignore the gap.\n if (sinceLast >= 0 && sinceLast < gapMs) {\n return { ok: false, reason: `min send gap (${minSendGapHours()}h) not elapsed — last send ${(sinceLast / HOUR_MS).toFixed(1)}h ago` };\n }\n }\n // v1.9 — exponential backoff after a failed send: 2^failures hours. See reachability.ts.\n { const bo = backoffBar(s, f.now); if (bo) return { ok: false, reason: bo }; }\n // R27 (v1.5) — FOREIGN-SENDER QUIET PERIOD: an outbound newer than ours means another system\n // owns this contact right now; stand down. Fails OPEN. Full rationale: NOTES-v1.4.md.\n if (f.foreignOutboundAt != null) {\n const quietMs = foreignQuietHours() * HOUR_MS;\n const since = f.now - f.foreignOutboundAt;\n if (since >= 0 && since < quietMs) {\n return {\n ok: false,\n reason: `another system messaged this contact ${(since / HOUR_MS).toFixed(1)}h ago — quiet period ${foreignQuietHours()}h`,\n };\n }\n }\n return { ok: true, reason: \"\" };\n };\n if (s.status === \"main\" && s.lastMainStepSent < MAIN_SEQUENCE.length) {\n const step = MAIN_SEQUENCE[s.lastMainStepSent];\n if (isDue(step.offsetHours, s.enteredAt, f.now)) {\n const g = sendGate(step.channel);\n if (!g.ok) return { kind: \"skip\", reason: `main #${s.lastMainStepSent + 1} due but deferred: ${g.reason}` };\n const br = channelBar(f, step.channel);\n if (br) {\n return { kind: \"skip_step\", sequence: \"main\", stepIndex: s.lastMainStepSent, reason: `${br} — step consumed, not sent` };\n }\n return { kind: \"send\", sequence: \"main\", stepIndex: s.lastMainStepSent };\n }\n return { kind: \"skip\", reason: `next main step (#${s.lastMainStepSent + 1}) not due yet` };\n }\n if (s.status === \"branch_a\" && s.lastBranchStepSent < BRANCH_A.length && s.branchAnchorAt) {\n const step = BRANCH_A[s.lastBranchStepSent];\n if (isDue(step.offsetHours, s.branchAnchorAt, f.now)) {\n const g = sendGate(step.channel);\n if (!g.ok) return { kind: \"skip\", reason: `branch A step due but deferred: ${g.reason}` };\n { const br = channelBar(f, step.channel);\n if (br) return { kind: \"skip_step\", sequence: \"branch_a\", stepIndex: s.lastBranchStepSent, reason: `${br} — step consumed, not sent` }; }\n return { kind: \"send\", sequence: \"branch_a\", stepIndex: s.lastBranchStepSent };\n }\n return { kind: \"skip\", reason: \"next branch A step not due yet\" };\n }\n if (s.status === \"branch_b\" && s.lastBranchStepSent < BRANCH_B.length && s.branchAnchorAt) {\n const step = BRANCH_B[s.lastBranchStepSent];\n if (isDue(step.offsetHours, s.branchAnchorAt, f.now)) {\n const g = sendGate(step.channel);\n if (!g.ok) return { kind: \"skip\", reason: `branch B step due but deferred: ${g.reason}` };\n { const br = channelBar(f, step.channel);\n if (br) return { kind: \"skip_step\", sequence: \"branch_b\", stepIndex: s.lastBranchStepSent, reason: `${br} — step consumed, not sent` }; }\n return { kind: \"send\", sequence: \"branch_b\", stepIndex: s.lastBranchStepSent };\n }\n return { kind: \"skip\", reason: \"next branch B step not due yet\" };\n }\n\n // v1.7 — Rule 10s: slow track. Indefinite by design, so no exhaustion exit — the exits are the\n // rules above (reply, booking, customer, DND). Anchor falls back to enteredAt if a legacy blob\n // lands here without slowAnchorAt.\n if (s.status === \"slow_track\") {\n const sentCount = Math.max(0, Math.floor(Number(s.lastSlowStepSent)) || 0);\n const anchor = s.slowAnchorAt ?? s.enteredAt;\n const { tpl, offsetHours, phase } = slowTemplateAt(sentCount, f.now, s.lastSentStepId);\n if (isDue(offsetHours, anchor, f.now)) {\n const g = sendGate(tpl.channel);\n if (!g.ok) return { kind: \"skip\", reason: `slow #${sentCount + 1} (${phase}) due but deferred: ${g.reason}` };\n const sbr = channelBar(f, tpl.channel);\n if (sbr) {\n return { kind: \"skip_step\", sequence: \"slow\", stepIndex: sentCount, reason: `${sbr} — slow step consumed, not sent` };\n }\n return { kind: \"send\", sequence: \"slow\", stepIndex: sentCount };\n }\n return { kind: \"skip\", reason: `next slow touch (#${sentCount + 1}, ${phase}) not due yet` };\n }\n\n return { kind: \"skip\", reason: `status ${s.status} has nothing to evaluate` };\n}\n\n// Pure, no IO. The ONE place PuppyState transitions are written, by cron AND the harness, so tested\n// and shipped behaviour cannot drift. Full note: NOTES-v1.4.md R39.\nfunction applyDecision(decision: Decision, s: PuppyState, nowIso: string): PuppyState {\n const next: PuppyState = { ...s, lastCheckedAt: nowIso };\n switch (decision.kind) {\n case \"hard_exit\":\n next.status = decision.status;\n next.exitReason = decision.reason;\n return next;\n case \"pause_reply\":\n next.status = \"paused_reply\";\n if (decision.isNewPause) {\n next.pausedForReplyAt = nowIso;\n next.exitReason = \"human reply pending\";\n }\n return next;\n case \"advance_status\":\n next.status = decision.status;\n if (decision.branchAnchorAt) next.branchAnchorAt = decision.branchAnchorAt;\n // v1.2 — a branch always restarts at its first message. Why: NOTES-v1.4.md R39.\n if (decision.status === \"branch_a\" || decision.status === \"branch_b\") next.lastBranchStepSent = 0;\n // v1.7.1 — returning to slow_track (cancelled booking) keeps slowAnchorAt and\n // lastSlowStepSent untouched: the taper resumes where it left off.\n return next;\n case \"soft_exit_21d\":\n // v1.7 — 21-day completion now hands the contact to the slow track (Kim's taper);\n // done_soft_21d remains in the type for legacy blobs only.\n next.status = \"slow_track\";\n next.slowAnchorAt = nowIso;\n next.lastSlowStepSent = 0;\n next.exitReason = \"21-day sequence complete — moved to slow track\";\n return next;\n case \"branch_complete\":\n next.status = \"done_branch_complete\";\n next.exitReason = \"branch sequence complete, no reply\";\n return next;\n case \"send\":\n if (decision.sequence === \"main\") next.lastMainStepSent = s.lastMainStepSent + 1;\n else if (decision.sequence === \"slow\") next.lastSlowStepSent = (s.lastSlowStepSent ?? 0) + 1;\n else next.lastBranchStepSent = s.lastBranchStepSent + 1;\n next.lastSentAt = nowIso; // v1.2 — feeds the min-gap pacing floor\n return next;\n case \"skip_step\":\n // v1.6 R28 — the step is consumed, not deferred. Deferring a step whose channel the contact\n // has opted out of would stall that contact forever on a message that can never legally send.\n // lastSentAt is deliberately NOT set: nothing went out, so nothing should start the pacing clock.\n if (decision.sequence === \"main\") next.lastMainStepSent = s.lastMainStepSent + 1;\n else if (decision.sequence === \"slow\") next.lastSlowStepSent = (s.lastSlowStepSent ?? 0) + 1;\n else next.lastBranchStepSent = s.lastBranchStepSent + 1;\n return next;\n case \"skip\":\n return next;\n }\n}\n\n// ---- IO layer: GHL fetch helper (identical shape to the PupsClub val) -----------------------------\n\nasync function j(url: string, ver: string, init?: RequestInit) {\n const tok = await resolveToken(); // v1.2 — env var, else private puppy_config blob (see header note)\n const r = await fetch(url, {\n ...init,\n headers: {\n Authorization: `Bearer ${tok}`,\n Version: ver,\n \"Content-Type\": \"application/json\",\n ...(init?.headers ?? {}),\n },\n });\n if (!r.ok) throw new Error(`${r.status} ${url.split(\"?\")[0]} ${(await r.text()).slice(0, 200)}`);\n return r.json();\n}\n\n// ---- blob state (dynamic import, see Node/tsx shim note above) ------------------------------------\n\nasync function getBlobModule() {\n // Dynamic, not static, so this file's pure logic imports under Node+tsx. Why: NOTES-v1.4.md R39.\n // @ts-expect-error — remote Deno URL specifier; unresolvable (by design) under tsc/Node's module\n // resolution, only ever actually imported at runtime inside a real Deno/val.town environment.\n const mod = await import(\"https://esm.town/v/std/blob\");\n return (mod as any).blob;\n}\n\nasync function loadAllState(): Promise> {\n const blob = await getBlobModule();\n return (await blob.getJSON(\"puppy_state\").catch(() => null)) ?? {};\n}\nasync function saveAllState(state: Record) {\n const blob = await getBlobModule();\n await blob.setJSON(\"puppy_state\", state);\n}\n// v1.8.2. Each run records its own timestamp so the dashboard can report the cadence it OBSERVES\n// rather than one a human typed. See cadence.ts for why, and for the shared shape.\nasync function saveReport(report: any) {\n const blob = await getBlobModule();\n let history: string[] = [];\n try {\n history = appendRunStamp(await blob.getJSON(\"puppy_run_state\").catch(() => null),\n typeof report?.ts === \"string\" ? report.ts : new Date().toISOString());\n } catch { /* bookkeeping is a nicety; never fail a run over it */ }\n await blob.setJSON(\"puppy_run_state\", { ...(report as object), history });\n}\nasync function saveLastError(err: unknown) {\n const blob = await getBlobModule();\n await blob.setJSON(\"puppy_last_error\", err);\n}\n\n// ---- v1.1: journal + summary ----------------------------------------------------------------------\n\ntype JournalRow = { ts: string; contactId: string | null; event: string; detail: string; test?: boolean };\n\n// Appends this run's rows and returns the full merged journal (capped at the newest 2000 rows) so the\n// caller can build the summary from complete history without a second blob read.\nasync function appendJournal(rows: JournalRow[]): Promise {\n const blob = await getBlobModule();\n const existing: JournalRow[] = (await blob.getJSON(\"puppy_journal\").catch(() => null)) ?? [];\n const merged = [...existing, ...rows].slice(-2000);\n if (rows.length) await blob.setJSON(\"puppy_journal\", merged);\n return merged;\n}\n\n// Pure — aggregate the numbers Kim's eventual 30-day report needs. Journal-derived counts\n// (bookedDuringPath, customersDuringPath, sendsByStep) survive state pruning; state-derived counts\n// reflect the current population.\nfunction buildSummary(\n state: Record,\n journal: JournalRow[],\n lastRun: { at: string; testMode: boolean; sent: number; failed: number; enrolled: number },\n) {\n const byStatus: Record = {};\n for (const s of Object.values(state)) byStatus[s.status] = (byStatus[s.status] ?? 0) + 1;\n const sendsByStep: Record = {};\n let bookedDuringPath = 0;\n let customersDuringPath = 0;\n let pausedForHuman = 0;\n let surgeHolds = 0;\n for (const r of journal) {\n if (r.event === \"sent\") sendsByStep[r.detail] = (sendsByStep[r.detail] ?? 0) + 1;\n else if (r.event === \"advance_status\" && r.detail === \"awaiting_appt_outcome\") bookedDuringPath++;\n else if (r.event === \"hard_exit\" && r.detail === \"became a customer\") customersDuringPath++;\n else if (r.event === \"pause_reply\") pausedForHuman++;\n else if (r.event === \"enrollment_surge_hold\") surgeHolds++;\n }\n return {\n at: lastRun.at,\n v: \"1.2\",\n lastRun,\n activeByStatus: byStatus,\n totalTracked: Object.keys(state).length,\n sendsByStep,\n bookedDuringPath,\n customersDuringPath,\n pausedForHuman,\n surgeHolds,\n ...failureCounts(journal, byStatus), // v1.9 — send_failed was journalled and counted by nothing\n };\n}\n\nasync function saveSummary(summary: unknown) {\n const blob = await getBlobModule();\n await blob.setJSON(\"puppy_summary\", summary);\n}\n\n// Pure — v1.1 state hygiene: drop terminal entries untouched for 60+ days. History stays in the\n// journal; the puppy-path-v1 tag still prevents re-enrollment of a pruned contact.\nfunction pruneState(state: Record, nowMs: number): { kept: Record; prunedIds: string[] } {\n const kept: Record = {};\n const prunedIds: string[] = [];\n for (const [id, s] of Object.entries(state)) {\n const stale = TERMINAL_STATUSES.has(s.status) && nowMs - new Date(s.lastCheckedAt).getTime() > 60 * DAY_MS;\n if (stale) prunedIds.push(id);\n else kept[id] = s;\n }\n return { kept, prunedIds };\n}\n\n// Pure — v1.1 enrollment gate (header addendum #1/#2). Given this run's un-enrolled tag matches,\n// decide who enrolls. Over-threshold = bulk-tag accident suspected: enroll nobody, hold until a human\n// clears it (ACKNOWLEDGE_SURGE=true) or the candidate count drops back under the threshold.\nfunction selectEnrollable(\n candidates: T[],\n surgeThreshold: number,\n surgeAcknowledged: boolean,\n): { enroll: T[]; surgeHeld: boolean } {\n if (candidates.length > surgeThreshold && !surgeAcknowledged) {\n return { enroll: [], surgeHeld: true };\n }\n return { enroll: candidates, surgeHeld: false };\n}\n\n// ---- IO layer: GHL reads --------------------------------------------------------------------------\n\nasync function getContact(contactId: string): Promise {\n const r = await j(`${GHL}/contacts/${contactId}`, \"2021-07-28\");\n return r.contact;\n}\n\nasync function getOpenOpportunities(contactId: string): Promise {\n const r = await j(`${GHL}/opportunities/search?location_id=${LOC}&contact_id=${contactId}&limit=10`, \"2021-07-28\");\n return (r.opportunities ?? []).map((o: any) => ({\n id: o.id,\n pipelineId: o.pipelineId,\n pipelineStageId: o.pipelineStageId,\n monetaryValue: o.monetaryValue ?? 0,\n status: o.status,\n }));\n}\n\n// ---- v1.3 (2 Aug 2026) — R19: THE ENROLMENT-SCAN QUOTA FIX -----------------------------\n// (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\nconst EXIT_STAGES = [\n \"fd821b4e-bbe6-44de-b754-fa80e4823616\", // Customer\n \"ae173310-f8b1-4399-acb7-ef1fc03d3697\", // Won - Paid\n \"38826f17-1d0e-4bac-b53e-349b67c2c79d\", // Disqualified\n \"43ea02b4-529b-4063-b638-447414d603d2\", // Free Training Day\n];\n\nasync function fetchExitOppIndex(): Promise | null> {\n const index = new Map();\n try {\n for (const stage of EXIT_STAGES) {\n let after: any = null, afterId: any = null, pages = 0;\n while (pages < 12) { // hard ceiling: a runaway page-walk must never be the thing that breaks a run\n let u = `${GHL}/opportunities/search?location_id=${LOC}&pipeline_id=${MAIN_PIPELINE_ID}` +\n `&pipeline_stage_id=${stage}&limit=100`;\n if (after != null) u += `&startAfter=${after}&startAfterId=${afterId}`;\n const r = await j(u, \"2021-07-28\");\n const ops = r.opportunities ?? [];\n if (!ops.length) break;\n for (const o of ops) {\n if (!o.contactId) continue;\n const fact: OppFact = {\n id: o.id,\n pipelineId: o.pipelineId,\n pipelineStageId: o.pipelineStageId,\n monetaryValue: o.monetaryValue ?? 0,\n status: o.status,\n };\n const prev = index.get(o.contactId);\n if (prev) prev.push(fact); else index.set(o.contactId, [fact]);\n }\n pages++;\n after = r.meta?.startAfter; afterId = r.meta?.startAfterId;\n if (!after) break;\n }\n }\n return index;\n } catch {\n // Fail to null, never to an empty map. An empty map would read as \"nobody is a customer\" and\n // could enrol someone who has already bought — the exact mistake this check exists to prevent.\n // Null makes the caller fall back to the per-contact read it used before.\n return null;\n }\n}\n\n// v1.1 (header addendum #5): the Pup Talk calendar's ±90d window holds ~143 events (measured live\n// 27 Jul); fetching it per contact re-downloaded all of them for every active contact every run.\n// Now: one fetch per run, indexed by contactId, latest non-deleted event per contact.\nasync function fetchPupTalkApptIndex(): Promise> {\n const now = Date.now();\n const windowStart = now - 90 * DAY_MS; // look back far enough to still catch a recently-missed appt\n const windowEnd = now + 90 * DAY_MS;\n const r = await j(\n `${GHL}/calendars/events?locationId=${LOC}&calendarId=${PUP_TALK_CALENDAR_ID}&startTime=${windowStart}&endTime=${windowEnd}`,\n \"2021-04-15\",\n );\n const index = new Map();\n for (const e of r.events ?? []) {\n if (!e.contactId || e.deleted) continue;\n const fact: ApptFact = {\n id: e.id,\n startTime: new Date(e.startTime).getTime(),\n endTime: new Date(e.endTime).getTime(),\n appointmentStatus: e.appointmentStatus,\n deleted: !!e.deleted,\n };\n const prev = index.get(e.contactId);\n if (!prev || fact.startTime > prev.startTime) index.set(e.contactId, fact);\n }\n return index;\n}\n\n// See header gap #1. Fails closed: any error, or a response shape this code doesn't recognize, is\n// reported as conversationCheckFailed=true — never silently treated as \"no reply.\"\nasync function getReplyStatus(\n contactId: string,\n enteredAtIso: string,\n st?: PuppyState,\n): Promise {\n // v1.5 R27: lastOutboundAt rides along on the SAME request that rule 5 already makes — the collision\n // guard costs zero extra API calls. It is the conversation's own lastMessageDate, returned only when\n // that last message was outbound; the caller decides whether it was ours.\n let lastOutboundAt: number | null = null;\n try {\n const r = await j(`${GHL}/conversations/search?locationId=${LOC}&contactId=${contactId}&limit=1`, \"2021-07-28\");\n const convo = (r.conversations ?? [])[0];\n if (!convo) return { hasUnansweredInboundReply: false, conversationCheckFailed: false, lastOutboundAt };\n // v1.9 — opt-out words + delivery status, hung off the conversation this call already fetched.\n const rx = await convoExtras(convo, st, j, GHL, Date.now());\n {\n const d = convo.lastMessageDirection ?? convo.direction ?? null;\n const ts = convo.lastMessageDate ?? convo.lastMessageDateTime ?? null;\n if (d === \"outbound\" && ts != null) {\n const n = new Date(ts).getTime();\n if (!Number.isNaN(n)) lastOutboundAt = n;\n }\n }\n // Field name NOT independently proven this session (the 401 blocked confirming it) — tryin\n // (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\n const direction = convo.lastMessageDirection ?? convo.direction ?? null;\n if (direction !== \"inbound\" && direction !== \"outbound\") {\n return { hasUnansweredInboundReply: false, conversationCheckFailed: true, lastOutboundAt, ...rx };\n }\n // v1.4 R21 — unreadCount is the second signal; outbound does not clear it. NOTES-v1.4.md R21.\n const unread = Number(convo.unreadCount ?? 0);\n if (direction === \"outbound\") {\n if (unread > 0) {\n return { hasUnansweredInboundReply: true, conversationCheckFailed: false, lastOutboundAt, ...rx };\n }\n return { hasUnansweredInboundReply: false, conversationCheckFailed: false, lastOutboundAt, ...rx };\n }\n const lastTsRaw = convo.lastMessageDate ?? convo.lastMessageDateTime ?? convo.dateUpdated ?? null;\n const lastTs = lastTsRaw != null ? new Date(lastTsRaw).getTime() : NaN;\n if (!Number.isNaN(lastTs) && lastTs < new Date(enteredAtIso).getTime()) {\n // Pre-enrollment history — EXCEPT if it is still unread, in which case somebody wrote in and\n // nobody has answered them, which outranks how old it is.\n if (Number(convo.unreadCount ?? 0) > 0) return { hasUnansweredInboundReply: true, conversationCheckFailed: false, lastOutboundAt, ...rx };\n return { hasUnansweredInboundReply: false, conversationCheckFailed: false, lastOutboundAt, ...rx };\n }\n return { hasUnansweredInboundReply: true, conversationCheckFailed: false, lastOutboundAt, ...rx };\n } catch {\n return { hasUnansweredInboundReply: false, conversationCheckFailed: true, lastOutboundAt };\n }\n}\n\n// ---- IO layer: GHL writes (all proven live this session, see PUPPY-PATH-TEST-REPORT.md) -----------\n\n// v1.7 hardening (6 Aug): in practice mode the SENDERS THEMSELVES refuse anyone except the one\n// sanctioned test record, so safety no longer rests only on enrollment scoping upstream. Fails\n// closed: until resolveTestDummy() has run and set this, practice mode can send to nobody at all.\nlet SANCTIONED_TEST_CONTACT: string | null = null;\nfunction assertSendAllowed(contactId: string, channel: string) {\n if (TEST_MODE && contactId !== SANCTIONED_TEST_CONTACT) {\n throw new Error(`practice mode: refusing ${channel} to ${contactId}; only the sanctioned test record may be messaged`);\n }\n}\n\nasync function sendSms(contactId: string, text: string) {\n assertSendAllowed(contactId, \"sms\");\n // Proven shape, copied verbatim from the PupsClub val, which sends real SMS in production today.\n return j(`${GHL}/conversations/messages`, \"2021-04-15\", {\n method: \"POST\",\n body: JSON.stringify({ type: \"SMS\", contactId, message: text }),\n });\n}\n\nasync function sendEmail(contactId: string, subject: string, html: string) {\n assertSendAllowed(contactId, \"email\");\n // Shape + response (incl. emailMessageId) verified live 27 Jul; full note NOTES-v1.4.md R39.\n return j(`${GHL}/conversations/messages`, \"2021-04-15\", {\n method: \"POST\",\n body: JSON.stringify({ type: \"Email\", contactId, subject, html }),\n });\n}\n\nasync function addTag(contactId: string, tag: string) {\n // Additive, verified live; upsert deliberately not used. Full note: NOTES-v1.4.md R39.\n return j(`${GHL}/contacts/${contactId}/tags`, \"2021-07-28\", {\n method: \"POST\",\n body: JSON.stringify({ tags: [tag] }),\n });\n}\n\nasync function createTask(contactId: string, title: string, body: string) {\n // Shape verified live; assignedTo omitted, no confirmed user id. Full note: NOTES-v1.4.md R39.\n return j(`${GHL}/contacts/${contactId}/tasks`, \"2021-07-28\", {\n method: \"POST\",\n body: JSON.stringify({ title, body, dueDate: new Date().toISOString(), completed: false }),\n });\n}\n\nasync function resolveTestDummy(): Promise<{ id: string; firstName: string; companyName: string | null }> {\n // TEST_MODE's one sanctioned contact (spec §8). +10000000000 is not a working number in any real\n // numbering plan — chosen specifically so an accidental SMS send during testing cannot reach a real\n // person, while still being a syntactically valid phone value GHL will accept on a contact record.\n const up = await j(`${GHL}/contacts/upsert`, \"2021-07-28\", {\n method: \"POST\",\n body: JSON.stringify({\n locationId: LOC,\n firstName: \"ZZTEST\",\n lastName: \"PuppyPath-Dummy\",\n email: \"aizhigitovamir@gmail.com\",\n phone: \"+10000000000\",\n }),\n });\n const c = up.contact;\n SANCTIONED_TEST_CONTACT = c.id;\n return { id: c.id, firstName: c.firstName, companyName: c.companyName ?? null };\n}\n\n// ---- orchestration: cron() (default export — the val.town entry point) ----------------------------\n\nexport default async function cron() {\n // R38: re-resolved first so every later read this pass agrees. See NOTES R38.\n TEST_MODE = resolveMode(Deno.env.get(\"TEST_MODE\"), await (await getBlobModule()).getJSON(\"puppy_mode\").catch(() => null));\n const out: any = {\n ok: true,\n v: \"1.10.0\", // reachability/dead letters/opt-out honoured, re-enrolment, refusal repeat. NOTES v1.10\n\n ts: new Date().toISOString(), // v1.2 — lets the watchdog's staleness check actually work\n testMode: TEST_MODE,\n enrolled: 0,\n sent: 0,\n failed: 0,\n skipped: 0,\n log: [] as string[],\n };\n const journal: JournalRow[] = [];\n const jrow = (contactId: string | null, event: string, detail: string) =>\n journal.push({ ts: new Date().toISOString(), contactId, event, detail, ...(TEST_MODE ? { test: true } : {}) });\n\n // v1.2 — best-effort run lock. Blob storage has no compare-and-swap, so this can't be a perfect\n // mutex, but it shrinks the overlap window (manual trigger colliding with the schedule, or a slow\n // run) from \"the whole run\" to milliseconds. A lock older than RUN_LOCK_TTL_MS is a dead run's\n // leftovers and is ignored.\n const blob = await getBlobModule();\n\n // ---- KILL SWITCH (v1.3). Checked first; fails OPEN. Full note in NOTES-v1.4.md.\n try {\n const kill = await blob.getJSON(\"nurture_kill\").catch(() => null);\n if (kill?.stopped) {\n out.ok = true;\n out.killed = true;\n out.log.push(`STOPPED by kill switch (set ${kill.at ?? \"unknown\"}) — no contact examined this tick`);\n await blob.setJSON(\"puppy_run_state\", out).catch(() => {});\n console.log(\"PUPPYPATH\", JSON.stringify(out));\n return out;\n }\n } catch { /* fail open — see note above */ }\n\n const lock = await blob.getJSON(\"puppy_run_lock\").catch(() => null);\n if (lock?.startedAt && Date.now() - new Date(lock.startedAt).getTime() < RUN_LOCK_TTL_MS) {\n out.log.push(`another run appears active (lock from ${lock.startedAt}) — skipping this tick`);\n console.log(\"PUPPYPATH\", JSON.stringify(out));\n return out;\n }\n await blob.setJSON(\"puppy_run_lock\", { startedAt: new Date().toISOString() }).catch(() => {});\n\n try {\n const state = await loadAllState();\n // v1.2 — existing journal loaded up front: the daily send cap counts today's already-journaled\n // live sends, so the ceiling holds across runs, not just within one.\n const priorJournal: JournalRow[] = (await blob.getJSON(\"puppy_journal\").catch(() => null)) ?? [];\n const todayPrefix = new Date().toISOString().slice(0, 10);\n let sentToday = priorJournal.filter(\n (r) => (r.event === \"sent\" || r.event === \"send_failed\") && r.ts.slice(0, 10) === todayPrefix && !r.test,\n ).length; // v1.9 — ATTEMPTS, not successes: failures were uncapped and cost the same GHL calls\n // v1.1 (addendum #5): one calendar fetch per run, shared by enrollment guard + per-contact facts.\n // R33: wrapped; one 401 used to abort the whole run before any contact was seen.\n let apptIndex: Map;\n try {\n apptIndex = await fetchPupTalkApptIndex();\n } catch (e) {\n apptIndex = new Map();\n out.log.push(`appt index unavailable, continuing without it: ${String((e as Error)?.message ?? e).slice(0, 120)}`);\n }\n let contactIds: string[];\n // v1.2 — opportunities fetched during enrollment eligibility are reused when the same contact is\n // processed later in this run, instead of a redundant second API call.\n const oppsCache = new Map();\n let skippedNotDue = 0; // v1.4 — how many contacts cost zero API calls this run\n // v1.9 — the effects the reachability helpers write through. task is null in practice mode.\n const fctx: Effects = { state, save: saveAllState, log: (l) => out.log.push(l), journal: jrow, task: TEST_MODE ? null : createTask };\n\n // v1.9 — THE DRY TAGGING PASS. Runs in BOTH modes on purpose; applies nothing, ever.\n // Full note, including why it was dead for three deploys: NOTES-v1.4.md, \"the dry tagging pass\".\n try {\n const recent = await j(`${GHL}/contacts/?locationId=${LOC}&limit=100`, \"2021-07-28\");\n await blob.setJSON(\"tag_candidates\", dryScan(recent?.contacts ?? [], new Date().toISOString()));\n } catch { /* a dry scan is never worth failing a run over */ }\n\n if (TEST_MODE) {\n // Spec §8: skip real discovery entirely, operate ONLY on the one sanctioned dummy.\n const dummy = await resolveTestDummy();\n contactIds = [dummy.id];\n if (!state[dummy.id]) {\n state[dummy.id] = freshState(new Date().toISOString());\n await addTag(dummy.id, TAG_ENROLLED).catch((e) =>\n out.log.push(`tag failed on dummy: ${String(e).slice(0, 120)}`)\n );\n out.enrolled++;\n out.log.push(`TEST_MODE: enrolled dummy ${dummy.id}`);\n jrow(dummy.id, \"enrolled\", \"test dummy\");\n }\n } else {\n // v1.1 enrollment: the source tag is the HUMAN enrollment switch. Blocks only what makes\n // enrollment WRONG (existing customer, live booking). DND enforced by rule 1 first pass.\n // Surge hold guards bulk tagging — selectEnrollable. Full note: NOTES-v1.4.md.\n const found = await j(`${GHL}/contacts/search`, \"2021-07-28\", {\n method: \"POST\",\n body: JSON.stringify({\n locationId: LOC,\n pageLimit: 100,\n filters: [{ field: \"tags\", operator: \"contains_set\", value: [TAG_SOURCE_SIGNAL] }],\n }),\n });\n // v1.2 — surface pagination truncation instead of silently ignoring candidates beyond page 1\n // (only reachable when a human pushes a >100 bulk batch through with ACKNOWLEDGE_SURGE).\n const totalTagged = found.total ?? (found.contacts ?? []).length;\n if (totalTagged > (found.contacts ?? []).length) {\n out.log.push(\n `WARNING: ${totalTagged} contacts carry '${TAG_SOURCE_SIGNAL}' but only ${(found.contacts ?? []).length} ` +\n `fit one page — the rest enroll on later runs as earlier ones get the puppy-path-v1 tag`,\n );\n }\n // v1.10 — a dead letter Kim has fixed and re-tagged comes back. reEnrollable, reachability.ts.\n const rawCandidates: any[] = (found.contacts ?? []).filter(\n (c: any) => !(c.tags ?? []).includes(TAG_ENROLLED) && (!state[c.id] || reEnrollable(state[c.id], c)),\n );\n const surgeThreshold = enrollSurgeThreshold();\n const { enroll, surgeHeld } = selectEnrollable(rawCandidates, surgeThreshold, acknowledgeSurge());\n if (surgeHeld) {\n out.log.push(\n `ENROLLMENT SURGE HELD: ${rawCandidates.length} un-enrolled '${TAG_SOURCE_SIGNAL}' contacts found in one run ` +\n `(threshold ${surgeThreshold}) — bulk tagging suspected, enrolling NOBODY until a human clears it ` +\n `(remove the bulk tags, or set ACKNOWLEDGE_SURGE=true). Already-enrolled contacts continue normally.`,\n );\n jrow(null, \"enrollment_surge_hold\", `${rawCandidates.length} candidates vs threshold ${surgeThreshold}`);\n }\n // v1.3 / R19 — one indexed read for the whole candidate set instead of one call each.\n const exitOppIndex = enroll.length ? await fetchExitOppIndex() : null;\n if (enroll.length) {\n out.log.push(\n exitOppIndex\n ? `exit-opp index built (${exitOppIndex.size} contacts across ${EXIT_STAGES.length} stages) — ${enroll.length} candidate(s) screened without per-contact calls`\n : `exit-opp index unavailable — falling back to per-contact reads for ${enroll.length} candidate(s)`,\n );\n }\n for (const c of enroll) {\n let opps: OppFact[];\n if (exitOppIndex) {\n opps = exitOppIndex.get(c.id) ?? [];\n } else {\n await sleep(120); // v1.2 — pacing: GHL fails 401/403 (not 429) over 100 req/10s\n opps = await getOpenOpportunities(c.id);\n }\n oppsCache.set(c.id, opps);\n // Across ALL opportunities, not just primary — spec's \"no opportunity showing Customer/Won-Paid\"\n // reading, and the account's own one-opportunity-per-contact rule makes this a cheap superset.\n const alreadyCustomer = opps.some(\n (o) => o.pipelineStageId === STAGE.CUSTOMER || o.pipelineStageId === STAGE.WON_PAID || o.monetaryValue > 0,\n );\n if (alreadyCustomer) { // v1.10 — TERMINAL, like the unreachable branch below: rule 4 would\n // hard-exit them on the first pass anyway, and without a state entry this refusal repeated\n // every run forever. NOT done_customer: api.ts counts that as WON. NOTES v1.10.\n state[c.id] = { ...freshState(new Date().toISOString()), status: \"done_not_enrolled\", exitReason: \"already a customer when tagged\" };\n out.log.push(`${c.id}: tagged but already a customer — not enrolled`);\n jrow(c.id, \"enroll_refused\", \"already a customer\");\n continue;\n }\n const appt = apptIndex.get(c.id) ?? null;\n if (appt && apptIsLiveBooked(appt)) { const R = \"live booking already exists\";\n // v1.10 — TRANSIENT: the booking may be cancelled, so this must stay re-evaluated and can\n // get no state entry. The repetition is stopped at the journal instead. NOTES v1.10.\n out.log.push(`${c.id}: tagged but ${R} — not enrolled`);\n if (!refusedBefore(priorJournal, c.id, R)) jrow(c.id, \"enroll_refused\", R);\n continue;\n }\n { const eb = enrolmentBar(c); if (eb) { // v1.9 — unreachable. The terminal entry, NOT the\n // tag (they were never on the path), is what stops this refusal repeating every run.\n state[c.id] = { ...freshState(new Date().toISOString()), status: \"done_unreachable\", exitReason: eb };\n out.log.push(`${c.id}: tagged but ${eb} — not enrolled`); jrow(c.id, \"enroll_refused\", eb); continue; } }\n state[c.id] = freshState(new Date().toISOString());\n await addTag(c.id, TAG_ENROLLED).catch((e) => out.log.push(`tag failed on ${c.id}: ${String(e).slice(0, 120)}`));\n out.enrolled++;\n out.log.push(`enrolled ${c.id}`);\n jrow(c.id, \"enrolled\", `via tag '${TAG_SOURCE_SIGNAL}'`);\n }\n contactIds = Object.keys(state);\n }\n\n for (const contactId of contactIds) {\n let s = state[contactId];\n if (!s || TERMINAL_STATUSES.has(s.status)) continue;\n\n // v1.2 — paused_reply contacts get a LIGHTWEIGHT safety pass instead of v1.1's full skip.\n // (full note moved to NOTES-v1.4.md when this file hit val.town's 80,000-char ceiling)\n if (s.status === \"paused_reply\") {\n // v1.4 R22 — the pause timeout, and why it does not resume: NOTES-v1.4.md R22.\n const pausedSince = s.pausedForReplyAt ? new Date(s.pausedForReplyAt).getTime() : null;\n if (pausedSince && Date.now() - pausedSince > pauseTimeoutDays() * DAY_MS) {\n const days = Math.floor((Date.now() - pausedSince) / DAY_MS);\n try {\n if (!TEST_MODE) {\n await createTask(\n contactId,\n `Still waiting on us — replied ${days} days ago, nobody has answered`,\n `This person replied to a follow-up message ${days} days ago. The sequence stopped for them at the time and raised a task, and that task has not been actioned.\\n\\nOpen Conversations, read what they said, and answer it. They are being taken off the automated follow-up either way — they asked a person a question and they deserve a person's answer.`,\n );\n }\n } catch (e) {\n out.log.push(`${contactId}: pause-timeout task failed: ${String(e).slice(0, 100)}`);\n }\n state[contactId] = {\n ...s,\n status: \"done_hard_exit\",\n exitReason: `paused for ${days} days with no human response — escalated and released`,\n lastCheckedAt: new Date().toISOString(),\n };\n out.log.push(`${contactId}: paused ${days}d with no action — escalated, exited`);\n jrow(contactId, \"pause_timeout\", `${days} days unanswered`);\n continue;\n }\n try {\n await sleep(120);\n const contact = await getContact(contactId);\n if (!contact) continue;\n const opportunities = oppsCache.get(contactId) ?? (await getOpenOpportunities(contactId));\n // v1.10 — the paused STOP. No state arg: nothing to reconcile here. NOTES v1.10.\n const pr = await getReplyStatus(contactId, s.enteredAt);\n const facts: Facts = {\n now: Date.now(),\n contact: { id: contactId, firstName: contact.firstName ?? \"\", companyName: contact.companyName ?? null, dnd: !!contact.dnd, noEmail: !contact.email, noPhone: !contact.phone },\n opportunities,\n pupTalkAppt: apptIndex.get(contactId) ?? null,\n declinedSignal: (contact.tags ?? []).includes(PUP_TALK_DECLINED_TAG),\n hasUnansweredInboundReply: false,\n optOutRequested: pr.optOutRequested, // rule 1b outranks rule 5, so this is still reachable\n conversationCheckFailed: true, // pinned: no send can ever pass rule 5 on this pass\n channelBlocked: readChannelConsent(contact),\n foreignOutboundAt: null, // no conversa\n",[524],"6c09572f-654e-4a8d-8b59-03af0e0883d3","SOURCE-BUNDLE.part7.txt","771fe81c-91b7-11f1-b53b-1607ee4eb77e",1093,["D",1786801897338],"THE DOGS SPOT — SOURCE BUNDLE (part 7 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (4 of 116 files)\n engine/paths.ts 17699 bytes 4b56baecd359\n engine/payments-source.ts 3147 bytes 0553c7855218\n engine/puppy-detect.ts 12214 bytes 4a48d65d803f\n engine/puppy-messages.ts 16899 bytes 6de869b387fd\n\n================================================================================================\n=====FILE engine/paths.ts =====\n// PATH REGISTRY, the six nurture paths as data, plus the validator that guards them. 2 Aug 2026.\n//\n// WHY\n// The engine was written for one path. Generalising it by rewriting the state machine on a live\n// client system is the kind of refactor that breaks something nobody notices for a week. The\n// cheaper and safer generalisation is to move the *definition* of a path out of code: a path is a\n// tag, a sequence of steps, and a set of exit rules. The engine already treats steps as data\n// (renderStep takes a template); this file makes the whole path a record.\n//\n// RETRACTED, 2 Aug 2026, and the RENDERED SENTENCE corrected 4 Aug: the retraction sat in this\n// comment for two days while the page below carried on printing the claim it retracts. A comment\n// is not a correction. This file used to claim registering paths 2-6 was \"a copy drop, not an\n// engineering job\". That was wrong and it was repeated to the client. The engine does not read this\n// file: puppy_path_v1.1.ts imports MAIN_SEQUENCE/BRANCH_A/BRANCH_B directly from puppy-messages.ts,\n// hardcodes TAG_SOURCE_SIGNAL, and stores Record, one position per contact,\n// not one per path. Dropping steps into a row below would render a green line on this page and send\n// nothing. Path 2 needs the state model, per-path tag mapping, sequence selection and precedence\n// rules built. Days, not an afternoon. This page is a registry and a validator; it is not wiring.\n//\n// THE VALIDATOR IS THE POINT\n// Every path, before it can be registered, has to survive the same checks the test suite runs\n// against the puppy path: no banned wording, no unresolved merge token, SMS inside carrier limits,\n// at least one opt-out line, a booking link that points at a calendar this account actually owns,\n// monotonic timing, and a defined terminal step. A path that fails is refused with reasons rather\n// than half-registered.\n//\n// ?k= the registry: what is defined, what is live, what is missing\n// ?k=&validate=1 run the validator over everything registered\n// ?k=&f=json the same as JSON\n\n// ---- auth ------------------------------------------------------------------------------------\n// v2 (2 Aug, after the adversarial pass): the key is NOT in this file. val.town vals are PUBLIC -\n// proved by fetching this very source with no token, so a literal key here was readable by anyone\n// who found the val, which meant anyone could read Kim's data, stop her system, or trigger a run.\n// Only the SHA-256 digest lives in source now. The digest is useless to a reader and sufficient for\n// a comparison, so publishing the code no longer publishes the secret.\nconst KEY_SHA256 = \"48cd12465712045f70247da1689eeb198a4ce2d98416d8e52fb844581f044f15\";\n\nasync function sha256Hex(s: string): Promise {\n const b = await crypto.subtle.digest(\"SHA-256\", new TextEncoder().encode(s));\n return [...new Uint8Array(b)].map((x) => x.toString(16).padStart(2, \"0\")).join(\"\");\n}\n\nasync function authorised(k: string): Promise {\n const override = Deno.env.get(\"NURTURE_ADMIN_KEY_SHA256\");\n const expected = override || KEY_SHA256;\n const got = await sha256Hex(k);\n // Constant-time over equal-length hex digests.\n if (got.length !== expected.length) return false;\n let d = 0;\n for (let i = 0; i < got.length; i++) d |= got.charCodeAt(i) ^ expected.charCodeAt(i);\n return d === 0;\n}\n\n// The one calendar this account owns for training consults. Verified live 2 Aug against\n// GET /calendars/?locationId=, \"Pup Talk Phone Call\". Any booking link in any path must contain it.\nconst OWNED_BOOKING_ID = \"qHuYJ0NEqzibnoqf5Cw3\";\nconst OWNED_BOARDING_FORM = \"thedogsspotga.com/boarding-booking-form\";\n\nexport type Step = {\n id: string;\n channel: \"email\" | \"sms\";\n offsetHours: number;\n subject?: string;\n previewText?: string;\n bodyTemplate: string;\n};\n\nexport type PathDef = {\n key: string;\n label: string;\n sourceTag: string; // applying this tag in the CRM is how a human enrols someone\n enrolledTag: string; // minted by the engine on enrolment\n source: \"engine\" | \"ghl\" | \"off\"; // mutual exclusion: never let a val and a GHL workflow both own a path\n channelsAtLaunch: (\"email\" | \"sms\")[];\n steps: Step[];\n notes: string;\n // v1.5, 2 Aug 2026, THE COLLISION MAP, and the most important field in this file.\n // `source` was always a DECLARATION of who owns a path. It was never checked against what the CRM\n // is actually running. Checked properly today via GET /workflows/?locationId= : the location has\n // 165 workflows, 95 of them PUBLISHED, and every one of the six paths below already has published\n // GoHighLevel automation whose name overlaps it. Declaring `source: \"engine\"` does not switch those\n // off. GoHighLevel exposes no endpoint for reading a contact's workflow enrolments\n // (/contacts/{id}/workflow -> 404) so overlap cannot be detected per contact, only per path, by a\n // human reading each workflow. Until a row here is cleared, treat it as live competition for the\n // same customer's inbox. The engine's R27 quiet-period guard is the runtime backstop; this list is\n // the thing that stops us needing it.\n ghlOverlap: { name: string; status: \"published\" | \"draft\"; version: number }[];\n};\n\n// ---- the registry ---------------------------------------------------------------------------------\n// PUPPY is populated from the deployed module so there is exactly one copy of that copy. The other\n// five are declared with everything except their steps: the tag names, the launch channels and the\n// constraints are all decided, so registering them is `steps: [...]` and nothing else.\n\nimport { MAIN_SEQUENCE, BRANCH_A, BRANCH_B } from \"./puppy-messages.ts\";\n\nexport const PATHS: PathDef[] = [\n {\n key: \"puppy\", label: \"Puppy owners\", sourceTag: \"nurture - puppy\", enrolledTag: \"puppy-path-v1\",\n source: \"engine\", channelsAtLaunch: [\"email\", \"sms\"],\n steps: [...MAIN_SEQUENCE, ...BRANCH_A, ...BRANCH_B] as Step[],\n notes: \"Live in the engine. 8 main + 2 no-show + 2 didn't-buy. The template for the other five.\",\n ghlOverlap: [\n { name: \"1. Wait 1 Day: Initial Nurture - Puppy\", status: \"published\", version: 2 },\n { name: \"1. Wait 1 Day: Initial Nurture\", status: \"published\", version: 2 },\n { name: \"Edited - Main New Nurture (New/Updated)\", status: \"published\", version: 4 },\n { name: \"Secondary Nurture Workflow\", status: \"published\", version: 4 },\n { name: \"A. Removed Tag : Initial Lead Nurtures\", status: \"published\", version: 2 },\n { name: \"Secondary Nurture - PUPPY Workflow\", status: \"draft\", version: 5 },\n { name: \"1. Initial Nurture - Facebook\", status: \"draft\", version: 3 },\n { name: \"1. Initial Nurture - Instagram\", status: \"draft\", version: 3 },\n ],\n },\n {\n key: \"behavior\", label: \"Behavior problems\", sourceTag: \"nurture - behavior\", enrolledTag: \"behavior-path-v1\",\n source: \"off\", channelsAtLaunch: [\"email\", \"sms\"], steps: [],\n notes: \"Largest real demand signal, 172 asks in the gap log. The day-14 aggression email is the highest-risk message in the whole set and Kim reads it personally before this path is switched on.\",\n ghlOverlap: [\n { name: \"Behavior Quiz Submitted\", status: \"published\", version: 3 },\n { name: \"Dialed In Dog ZJ : Free Training Day Quiz\", status: \"published\", version: 16 },\n { name: \"Quiz -. Pup Talk > Notes\", status: \"published\", version: 4 },\n { name: \"Quiz Score Redirect Logic\", status: \"draft\", version: 6 },\n ],\n },\n {\n key: \"boarding\", label: \"Boarding inquiries\", sourceTag: \"nurture - boarding\", enrolledTag: \"boarding-path-v1\",\n source: \"off\", channelsAtLaunch: [\"email\", \"sms\"], steps: [],\n notes: \"The only path allowed to quote prices, and only the boarding ones Kim confirmed. Every mention of hours must carry the appointment-only rule. Booking goes to her website form, never a GHL calendar.\",\n ghlOverlap: [\n { name: \"Boarding Drop-Off - Confirmation + Reminder\", status: \"published\", version: 19 },\n { name: \"Boarding Pick-Up - Confirmation + Reminder\", status: \"published\", version: 25 },\n { name: \"Abandoned Cart - Partial booking\", status: \"published\", version: 5 },\n { name: \"Cancel Boarding - Drop Off\", status: \"published\", version: 3 },\n { name: \"Online Boarding Update > Kennel\", status: \"published\", version: 4 },\n { name: \"Boarding App Webhook\", status: \"published\", version: 18 },\n ],\n },\n {\n key: \"noshow\", label: \"Pup Talk, didn't show\", sourceTag: \"nurture - noshow\", enrolledTag: \"noshow-path-v1\",\n source: \"off\", channelsAtLaunch: [\"email\", \"sms\"], steps: [],\n notes: \"Closes a measured hole: 19 no-shows and 8 cancellations across 145 Pup Talk events with nothing following up.\",\n ghlOverlap: [\n { name: \"Cxld/Canceled Pup Talk\", status: \"published\", version: 7 },\n { name: \"Cxld or No Show - Consult Nurture\", status: \"published\", version: 4 },\n { name: \"Free training day no show nurture\", status: \"published\", version: 9 },\n { name: \"Cxld/Canceled Free Training Day\", status: \"published\", version: 4 },\n { name: \"Tag Added 'No Show' > No Show\", status: \"published\", version: 2 },\n { name: \"Tag Added 'No Show DND' > No Show TO PREVENT ANOTHER BOOKING\", status: \"published\", version: 2 },\n { name: \"Free Training Day abandoned booking\", status: \"published\", version: 8 },\n ],\n },\n {\n key: \"didntbuy\", label: \"Pup Talk, didn't buy\", sourceTag: \"nurture - didntbuy\", enrolledTag: \"didntbuy-path-v1\",\n source: \"off\", channelsAtLaunch: [\"email\", \"sms\"], steps: [],\n notes: \"82 attended and few converted. Kim's $500 discount decision lives near this path, keep them separate until its wording and its own dry/live toggle exist.\",\n ghlOverlap: [\n { name: \"POST CONSULT - NO SALE NURTURE MESSAGES\", status: \"published\", version: 4 },\n { name: \"Tag added 'No Sale' > No Sale Nurture\", status: \"published\", version: 2 },\n ],\n },\n {\n key: \"aged\", label: \"Dormant inquiries\", sourceTag: \"nurture - aged\", enrolledTag: \"aged-path-v1\",\n source: \"off\", channelsAtLaunch: [\"email\"],\n steps: [],\n notes: \"EMAIL ONLY AT LAUNCH, and the audience is far smaller than the headline: of 3,426 dormant contacts only ~164 have an email address and ~2,655 have neither email nor phone. SMS stays held until numbers are validated, stale numbers get a business flagged by carriers, which would damage every other path.\",\n ghlOverlap: [\n { name: \"Tips Nurture\", status: \"published\", version: 7 },\n { name: \"TIPS FACEBOOK CAMPAIGN - SMS Nurture\", status: \"published\", version: 3 },\n { name: \"Auto Replies > tips campaign\", status: \"published\", version: 10 },\n { name: \"Copy - Tips Ad campaign > Auto Responder\", status: \"published\", version: 11 },\n { name: \"Tips ad campaign > response > phone number\", status: \"published\", version: 10 },\n { name: \"Tips Ad campaign > Auto Responder\", status: \"draft\", version: 19 },\n ],\n },\n];\n\n// ---- the validator --------------------------------------------------------------------------------\n\nconst BANNED = [\n { re: /discovery/i, why: 'Kim banned \"discovery call\", it is \"Pup Talk\"' },\n { re: /grooming/i, why: \"grooming is not a service they offer\" },\n { re: /\\$\\s?\\d/, why: \"a price in a message; boarding prices come from the knowledge base, training prices never\" },\n // Templates legitimately contain {{FIRST_NAME}} and {{DOG_NAME}}, they are resolved per contact at\n // render time, and the engine has fallbacks for both when a contact has neither. Anything ELSE in\n // double braces is a token nobody wired up, which is what actually reaches a customer as literal\n // text. Caught by the first validator run, which flagged all 12 real templates: a check that fails\n // on correct input is worse than no check.\n { re: /\\{\\{(?!\\s*(FIRST_NAME|DOG_NAME)\\s*\\}\\})/, why: \"an unrecognised merge token, only {{FIRST_NAME}} and {{DOG_NAME}} are wired up\" },\n { re: /\\[link\\]|\\[phone\\]|INSERT|TODO|LOREM/i, why: \"a placeholder that never got resolved\" },\n];\n\nexport function validatePath(p: PathDef) {\n const errors: string[] = [], warnings: string[] = [];\n if (!p.steps.length) return { key: p.key, registered: false, ok: false, errors: [\"no steps registered yet\"], warnings: [] };\n\n let sawOptOut = false, sawBooking = false;\n const sms = p.steps.filter((s) => s.channel === \"sms\");\n\n for (const s of p.steps) {\n const text = `${s.subject ?? \"\"}\\n${s.previewText ?? \"\"}\\n${s.bodyTemplate}`;\n for (const b of BANNED) if (b.re.test(text)) errors.push(`${s.id}: ${b.why}`);\n if (/\\bstop\\b/i.test(s.bodyTemplate) || /reply\\s+stop/i.test(s.bodyTemplate)) sawOptOut = true;\n if (s.bodyTemplate.includes(OWNED_BOOKING_ID) || s.bodyTemplate.includes(OWNED_BOARDING_FORM)) sawBooking = true;\n if (/leadconnectorhq\\.com\\/widget\\/bookings?\\//.test(s.bodyTemplate) &&\n !s.bodyTemplate.includes(OWNED_BOOKING_ID)) {\n errors.push(`${s.id}: booking link does not point at a calendar this account owns, this is the exact defect found on 2 Aug`);\n }\n if (s.channel === \"sms\" && s.bodyTemplate.length > 320) errors.push(`${s.id}: SMS ${s.bodyTemplate.length} chars, over the 320 ceiling`);\n if (s.channel === \"email\" && !s.subject) errors.push(`${s.id}: email with no subject line`);\n }\n\n const offsets = p.steps.map((s) => s.offsetHours);\n const mainish = p.steps.filter((s) => s.id.startsWith(\"main\"));\n if (mainish.length > 1) {\n for (let i = 1; i < mainish.length; i++) {\n if (mainish[i].offsetHours <= mainish[i - 1].offsetHours) {\n errors.push(`${mainish[i].id}: timing does not move forward (${mainish[i - 1].offsetHours}h then ${mainish[i].offsetHours}h)`);\n }\n }\n }\n if (Math.max(...offsets) < 24 * 21) warnings.push(`longest step is ${Math.round(Math.max(...offsets) / 24)} days, the client was sold a minimum 30-day journey`);\n if (!sawOptOut && sms.length) warnings.push(\"no opt-out wording found in any SMS\");\n if (!sawBooking) warnings.push(\"no booking link anywhere in this path\");\n if (p.source === \"engine\" && p.channelsAtLaunch.includes(\"sms\") && p.key === \"aged\") {\n errors.push(\"aged path must not launch with SMS until the number list has been validated\");\n }\n\n return { key: p.key, registered: true, ok: errors.length === 0, errors, warnings, steps: p.steps.length, sms: sms.length, email: p.steps.length - sms.length };\n}\n\n\nexport default async function (req: Request): Promise {\n const url = new URL(req.url);\n if (!(await authorised(url.searchParams.get(\"k\") || \"\"))) {\n return new Response(\"Not found\", { status: 401, headers: { \"content-type\": \"text/plain\" } });\n }\n const results = PATHS.map(validatePath);\n const payload = {\n at: new Date().toISOString(),\n registered: results.filter((r) => r.registered).length,\n awaitingCopy: results.filter((r) => !r.registered).map((r) => r.key),\n live: PATHS.filter((p) => p.source === \"engine\").map((p) => p.key),\n mutualExclusion: \"each path names exactly one owner, engine, ghl, or off. No path can be run by both.\",\n paths: PATHS.map((p) => ({\n key: p.key, label: p.label, sourceTag: p.sourceTag, enrolledTag: p.enrolledTag,\n source: p.source, channelsAtLaunch: p.channelsAtLaunch, steps: p.steps.length, notes: p.notes,\n validation: results.find((r) => r.key === p.key),\n })),\n };\n if (url.searchParams.get(\"f\") === \"json\" || url.searchParams.get(\"validate\") === \"1\") {\n return new Response(JSON.stringify(payload, null, 2), { headers: { \"content-type\": \"application/json\", \"cache-control\": \"no-store\" } });\n }\n const rows = payload.paths.map((p: any) => {\n const v = p.validation;\n const status = !v.registered ? 'awaiting copy'\n : v.ok ? 'passes every check'\n : `${v.errors.length} problem(s)`;\n return `${p.label}
${p.sourceTag}${p.source}${p.steps || \"-\"}${status}${p.notes}`;\n }).join(\"\");\n return new Response(`Nurture paths\n\n
The six nurture paths
\n
${payload.registered} of ${payload.paths.length} have copy registered. Registering the rest is NOT a copy drop: the engine reads its sequences directly and stores one position per contact, not one per path, so each additional path needs the state model, per-path tag mapping, sequence selection and precedence rules built. Days of work each, not an afternoon. This page is a registry and a validator, not the wiring. Every path is checked against the same rules before it can run.
\n${rows}
Path Owner Steps Validator Constraint that governs it
\n
Owner is the mutual-exclusion switch: engine, ghl, or off. Nothing can be run by two systems at once, that is what put a Facebook script on the website in July.
`,\n { headers: { \"content-type\": \"text/html; charset=utf-8\" } });\n}\n\n\n=====FILE engine/payments-source.ts =====\n// SQUARE MONEY AS THE CRM RECORDS IT. New 10 Aug 2026.\n//\n// WHY THIS FILE EXISTS. Until today `money-match.ts` was imported by its own test and by nothing\n// else. There was no call to /payments/transactions anywhere in the repo, so every figure on Kim's\n// money page came from a process that was not in the tree, and the filters below were unwritten\n// rather than misconfigured. This is that missing layer.\n//\n// It is a SEPARATE module on purpose: test MM-h asserts the string `fetch(` never appears in\n// money-match.ts, and that test is worth keeping.\n//\n// The endpoint, and note it rejects `locationId` and wants `altId`:\n// GET /payments/transactions?altId=&altType=location&limit=100&offset=\nimport type { Payment } from \"./money-match.ts\";\n\n// Every source type this location produces, proven live 10 Aug 2026 across all 233 transactions:\n// calendar 158, invoice 61, funnel 11, payment_link 2, manual 1. All 233 carry a contactId.\n// payment_link is IN. Both rows today are failed tests worth $0, but reusable front desk payment\n// links are a live workstream, and a matcher that silently dropped them would report the front\n// desk's first day of takings as zero, with no error, which reads as \"business was quiet\".\nexport const ACCEPTED_SOURCE_TYPES: readonly string[] = Object.freeze([\n \"calendar\", \"invoice\", \"funnel\", \"payment_link\", \"manual\",\n]);\nconst ACCEPTED = new Set(ACCEPTED_SOURCE_TYPES);\n\n// A $0 row is a calendar booking artifact, not money: 171 of 233 live, every one status\n// \"succeeded\". A sub $1 row is a card test: 10 live, $3.05 total, every one pending, belonging to\n// \"emily harris\" and \"automation dogs test\".\n//\n// FILTER ON AMOUNT, NOT ON SOURCE TYPE. Filtering entitySourceType !== \"calendar\" is the near miss:\n// it leaves 13 zero rows standing, which is what invents a phantom payment collision and inflates\n// the booking count. It is also the wrong axis, because invoice/calendar produces both $0 artifacts\n// and real money.\nexport const MIN_REAL_PAYMENT = 1;\nexport const isRealMoney = (p: { amount: number }) => p.amount >= MIN_REAL_PAYMENT;\n\nexport function toPayment(t: any): Payment {\n return {\n id: String(t?._id ?? \"\"),\n amount: Number(t?.amount) || 0,\n status: String(t?.status ?? \"\"),\n contactId: t?.contactId ?? null,\n contactName: t?.contactName ?? null,\n at: t?.createdAt ?? null,\n };\n}\n\nexport type Accepted = { payments: Payment[]; unknownTypes: string[]; dropped: { zeroOrTest: number } };\n\n// An UNRECOGNISED source type is KEPT and REPORTED, never dropped. A new type is a new way money\n// arrives, and dropping it silently is how revenue goes missing without anybody seeing an error.\nexport function acceptPayments(rows: any[]): Accepted {\n const unknown = new Set();\n const kept: Payment[] = [];\n let zeroOrTest = 0;\n for (const t of rows) {\n const st = String(t?.entitySourceType ?? \"\");\n if (st && !ACCEPTED.has(st)) unknown.add(st);\n const p = toPayment(t);\n if (!isRealMoney(p)) { zeroOrTest++; continue; }\n kept.push(p);\n }\n return { payments: kept, unknownTypes: [...unknown].sort(), dropped: { zeroOrTest } };\n}\n\n\n=====FILE engine/puppy-detect.ts =====\n// WHO IS A PUPPY INQUIRY. v1.0, 5 August 2026.\n//\n// WHY THIS FILE EXISTS. The engine enrolls people carrying the tag `nurture - puppy`. Nothing in\n// Kim's account applies that tag: all 5,544 contacts checked, zero carry it. So go-live is three\n// switches, not two, and this is the third.\n//\n// WHY IT IS NOT A ONE-LINE REGEX. The first thing I tried was matching \"puppy\" or an age in weeks\n// or months against the inquiry summary. Over the 800 most recent contacts it returned 29 people,\n// and reading them showed it was wrong about several in ways that matter:\n//\n// * \"Ken Anderson was looking to purchase a puppy. He inquired whether The Dog's Spot GA offered\n// puppies for sale. The agent clarified that they do not sell.\" He would have received\n// forty-one messages about training a puppy he does not own.\n// * \"Charlie, who is 3 years and 4 months old\" matched on \"4 months old\". The dog is three.\n// * \"Evelyn Carter was seeking good homes for her older dogs\" matched on the word \"new puppy\"\n// later in a sentence about rehoming.\n//\n// A false positive here is not a bad row in a spreadsheet. It is a real person getting nineteen\n// months of messages about a puppy they do not have, in Kim's name.\n//\n// SO THIS FILE NEVER APPLIES A TAG. It classifies, it explains itself in one sentence per person,\n// and it hands the list to a human. `confidence` is the whole point: \"clear\" is defensible on its\n// own, \"probable\" wants a glance, \"unclear\" is a question rather than an answer.\n//\n// It also reports its own blind spot, loudly: the inquiry summary is populated on about half of\n// contacts. Anyone with no summary cannot be classified by this at all, and saying so is part of\n// the output rather than a footnote.\n\nexport type Verdict = {\n contactId: string;\n name: string;\n confidence: \"clear\" | \"probable\" | \"unclear\" | \"no\";\n /** One sentence, in plain English, naming the words that decided it. */\n reason: string;\n /** Months, when a dog's age could be read. null when it could not. */\n ageMonths: number | null;\n matched: string[];\n};\n\nexport type DetectSummary = {\n scanned: number;\n withText: number;\n noText: number;\n clear: number;\n probable: number;\n unclear: number;\n no: number;\n};\n\nconst num = (s: string): number | null => {\n const words: Record = {\n one: 1, two: 2, three: 3, four: 4, five: 5, six: 6, seven: 7, eight: 8,\n nine: 9, ten: 10, eleven: 11, twelve: 12, eighteen: 18,\n };\n const t = s.trim().toLowerCase();\n if (/^\\d+(\\.\\d+)?$/.test(t)) return Number(t);\n return words[t] ?? null;\n};\n\n/**\n * The dog's age in months, or null.\n *\n * The \"3 years and 4 months old\" trap is handled by looking for a YEARS reading first and letting\n * it win. A dog described in years is not a puppy however many months are mentioned afterwards.\n */\nexport function ageInMonths(text: string): number | null {\n const t = text.toLowerCase();\n // YEARS FIRST, AND THEY WIN OUTRIGHT.\n // [was: the years pattern required the word \"old\" straight after it, as in \"3-year-old\". So\n // \"Charlie, who is 3 years and 4 months old\" did not match it — the \"old\" belongs to the\n // months — and fell through to the months branch, which read the dog as 4 months. That is\n // the exact false positive this whole file exists to prevent, and the first version of the\n // file still had it. Caught by its own test, not by reading it.]\n const y = t.match(/(\\d+(?:\\.\\d+)?|one|two|three|four|five|six|seven|eight|nine|ten|eleven|twelve)[\\s-]*(?:year|yr)s?\\b/);\n if (y) {\n const n = num(y[1]);\n if (n != null) {\n const m = t.slice(y.index ?? 0).match(/(?:year|yr)s?[\\s,-]*(?:and\\s*)?(\\d+|one|two|three|four|five|six|seven|eight|nine|ten|eleven)[\\s-]*(?:month|mo)s?\\b/);\n return n * 12 + (m ? (num(m[1]) ?? 0) : 0);\n }\n }\n const mo = t.match(/(\\d+(?:\\.\\d+)?|one|two|three|four|five|six|seven|eight|nine|ten|eleven|twelve|eighteen)(?:\\s*-\\s*\\d+)?[\\s-]*(?:month|mo)s?[\\s-]*old/);\n if (mo) { const n = num(mo[1]); if (n != null) return n; }\n const wk = t.match(/(\\d+(?:\\.\\d+)?|one|two|three|four|five|six|seven|eight|nine|ten|eleven|twelve)(?:\\s*-\\s*\\d+)?[\\s-]*(?:week|wk)s?[\\s-]*old/);\n if (wk) { const n = num(wk[1]); if (n != null) return Math.round((n / 4.345) * 10) / 10; }\n return null;\n}\n\n// Reasons someone is NOT a puppy-training inquiry even though the word appears. Each one is here\n// because a real contact in Kim's account tripped it.\nconst DISQUALIFIERS: Array<[RegExp, string]> = [\n [/\\b(purchase|buy|buying|sell|selling|for sale|breeder|adopt(?:ing)? a)\\b[^.]{0,40}\\bpupp/i,\n \"they were asking to buy a puppy, not to train one\"],\n [/\\bpupp\\w*\\b[^.]{0,40}\\b(for sale|to sell|available to buy)\\b/i,\n \"they were asking to buy a puppy, not to train one\"],\n [/\\b(rehome|rehoming|good homes|find(?:ing)? homes|surrender|give away)\\b/i,\n \"they were rehoming dogs rather than asking about training\"],\n [/\\b(do not sell|don't sell|does not sell|doesn't sell)\\b/i,\n \"the reply on file says Kim does not sell dogs, so this was not a training inquiry\"],\n];\n\nconst PUPPY_WORDS = /\\b(pupp(?:y|ies)|new pup\\b|pup\\b)/i;\n// Kim's puppy sequence is written for a young dog. Past about a year it is the wrong sequence.\nconst PUPPY_MAX_MONTHS = 12;\n\n/** Age in the words a person would use. Nobody says a dog is 1.4 months old. */\nexport function sayAge(months: number): string {\n if (months < 2) { const w = Math.round(months * 4.345); return `${w} week${w === 1 ? \"\" : \"s\"} old`; }\n if (months < 24) { const m = Math.round(months); return `${m} month${m === 1 ? \"\" : \"s\"} old`; }\n const y = Math.round(months / 12);\n return `${y} year${y === 1 ? \"\" : \"s\"} old`;\n}\n\nexport function classify(contactId: string, name: string, text: string): Verdict {\n const clean = (text ?? \"\").replace(/\\s+/g, \" \").trim();\n if (!clean) {\n return { contactId, name, confidence: \"unclear\", ageMonths: null, matched: [],\n reason: \"There is nothing written down about what they asked for, so this cannot be decided from the record.\" };\n }\n\n for (const [re, why] of DISQUALIFIERS) {\n const m = clean.match(re);\n if (m) return { contactId, name, confidence: \"no\", ageMonths: ageInMonths(clean), matched: [m[0].slice(0, 60)], reason: `Not a puppy inquiry: ${why}.` };\n }\n\n const age = ageInMonths(clean);\n const saysPuppy = PUPPY_WORDS.test(clean);\n const matched: string[] = [];\n if (saysPuppy) matched.push((clean.match(PUPPY_WORDS) ?? [\"\"])[0]);\n if (age != null) matched.push(`${age} months old`);\n\n if (age != null && age > PUPPY_MAX_MONTHS) {\n return { contactId, name, confidence: \"no\", ageMonths: age, matched,\n reason: `Not a puppy inquiry: the dog is given as ${sayAge(age)}, which is past the sequence.` };\n }\n if (age != null && saysPuppy) {\n return { contactId, name, confidence: \"clear\", ageMonths: age, matched,\n reason: `Called a puppy and given as ${sayAge(age)}, so both signals agree.` };\n }\n // A very young age settles it on its own. No adult dog is four months old, so the word \"puppy\"\n // adds nothing at this end and demanding it would push obvious cases down to \"probable\".\n if (age != null && age <= 6) {\n return { contactId, name, confidence: \"clear\", ageMonths: age, matched,\n reason: `The dog is given as ${sayAge(age)}, which is a puppy whatever words they used.` };\n }\n if (age != null) {\n return { contactId, name, confidence: \"probable\", ageMonths: age, matched,\n reason: `The dog is given as ${sayAge(age)}, which is inside the sequence, but the word puppy is not used.` };\n }\n if (saysPuppy) {\n return { contactId, name, confidence: \"probable\", ageMonths: null, matched,\n reason: \"They call it a puppy, but no age is written down, so how young is a guess.\" };\n }\n return { contactId, name, confidence: \"no\", ageMonths: null, matched: [],\n reason: \"Nothing in what they wrote points at a puppy.\" };\n}\n\nexport function summarise(vs: Verdict[], scanned: number): DetectSummary {\n const by = (c: Verdict[\"confidence\"]) => vs.filter((v) => v.confidence === c).length;\n const noText = vs.filter((v) => v.matched.length === 0 && v.confidence === \"unclear\").length;\n return { scanned, withText: scanned - noText, noText, clear: by(\"clear\"), probable: by(\"probable\"),\n unclear: by(\"unclear\"), no: by(\"no\") };\n}\n\n/**\n * How old is this reading, in words, or null when it is fresh enough not to mention.\n *\n * A dry pass that stopped running would otherwise keep showing its last numbers as though they\n * were this morning's. The engine runs about hourly, so anything past six hours has missed\n * several turns and is worth saying out loud.\n */\nexport function scanAgeNote(atIso: string | null | undefined, nowMs: number): string | null {\n if (!atIso) return null;\n const ms = nowMs - Date.parse(atIso);\n if (!Number.isFinite(ms) || ms < 0) return null;\n const hours = ms / 3_600_000;\n if (hours < 6) return null;\n if (hours < 48) return `This count was last taken about ${Math.round(hours)} hours ago rather than just now, so treat it as a little out of date.`;\n return `This count was last taken about ${Math.round(hours / 24)} days ago, so it has stopped being kept up and the numbers below are old.`;\n}\n\n/** The sentence for the summary, generated from the counts, never written alongside them. */\nexport function detectSentence(s: DetectSummary | null): string {\n if (!s || !s.scanned) return \"No contacts were read, so there is nothing to report here rather than a zero to trust.\";\n const parts = [\n `${s.scanned.toLocaleString(\"en-US\")} contacts were read. ${s.clear} are clearly a puppy inquiry and ${s.probable} probably are.`,\n ];\n if (s.noText) {\n parts.push(`${s.noText} of them have nothing written down about what they asked for, so they cannot be judged from the record at all, either way.`);\n }\n parts.push(\"Nothing has been tagged. This is a list to look at, not an action taken.\");\n return parts.join(\" \");\n}\n\n// ---------------------------------------------------------------------------------------------\n// THE DRY PASS.\n//\n// This file has NO WAY TO APPLY A TAG and that is structural, not a promise: there is no fetch, no\n// POST and no client in it. Everything here takes contacts in and hands verdicts out. The engine\n// calls it on each run, writes the counts down, and applies nothing. When the tagging is finally\n// armed it will be armed somewhere a human had to go and change, not here.\n//\n// The custom-field ids are Kim's account's. `inquiryText` is deliberately forgiving about the\n// shape of a contact, because it is fed straight from the CRM's JSON.\n// ---------------------------------------------------------------------------------------------\nexport const FIELD_INQUIRY_SUMMARY = \"N8Mw4Mmz5ecesIOrQMWm\";\nexport const FIELD_TRAINING_GOAL = \"4EXdybS2XUAaP6tnlncI\";\n\nexport function inquiryText(contact: unknown): string {\n const cfs = (contact as any)?.customFields;\n if (!Array.isArray(cfs)) return \"\";\n const pick = (id: string) => {\n const f = cfs.find((x: any) => x?.id === id);\n const v = f?.value;\n return typeof v === \"string\" || typeof v === \"number\" ? String(v) : \"\";\n };\n return `${pick(FIELD_INQUIRY_SUMMARY)} ${pick(FIELD_TRAINING_GOAL)}`.trim();\n}\n\nexport function classifyContacts(contacts: unknown): Verdict[] {\n if (!Array.isArray(contacts)) return [];\n return contacts\n .filter((c: any) => c && typeof c.id === \"string\")\n .map((c: any) => classify(c.id, String(c.contactName ?? c.firstName ?? \"(no name)\"), inquiryText(c)));\n}\n\nexport type DryScan = {\n at: string;\n summary: DetectSummary;\n /** Ids only, and only the ones worth a human's time. Never names, never message text. */\n clearIds: string[];\n probableIds: string[];\n /** Always false in this file. Present so the panel can state it rather than assume it. */\n applied: false;\n};\n\nexport function dryScan(contacts: unknown, at: string): DryScan {\n const vs = classifyContacts(contacts);\n return {\n at,\n summary: summarise(vs, vs.length),\n clearIds: vs.filter((v) => v.confidence === \"clear\").map((v) => v.contactId),\n probableIds: vs.filter((v) => v.confidence === \"probable\").map((v) => v.contactId),\n applied: false,\n };\n}\n\n\n=====FILE engine/puppy-messages.ts =====\n// PUPPY PATH — message copy module (split from the engine for val.town's 80k/file limit).\n// Copy is VERBATIM from PHASE1-PUPPY-PATH-WRITING-SHEET.md §3 — do not paraphrase here, ever.\ndeclare const Deno: { env: { get(key: string): string | undefined } };\nif (typeof (globalThis as any).Deno === \"undefined\") {\n (globalThis as any).Deno = { env: { get: (k: string) => (globalThis as any).process?.env?.[k] } };\n}\n\n// ---- v1.3 change, 2 Aug 2026 — booking URL. RETRACTION APPENDED, read the whole block ----------\n// The previous value was:\n// https://api.leadconnectorhq.com/widget/bookings/pbe-discovery-9edbddc3-4b5a-406e-9bc3-7f10cb0d3221\n//\n// WHAT I ORIGINALLY WROTE HERE (and it was wrong): that this id \"does NOT belong to this location\"\n// and was the parent agency's own discovery-call widget.\n//\n// RETRACTED, same day, on better evidence. Re-checking GET /calendars/?locationId=BQHJ19uohldYe3eqA0bl\n// field by field shows `pbe-discovery-9edbddc3-4b5a-406e-9bc3-7f10cb0d3221` is the *widget slug of\n// Kim's own \"Pup Talk Phone Call\" calendar* — the same calendar as qHuYJ0NEqzibnoqf5Cw3. Confirmed\n// independently: https://book.thedogsspotga.com/phone (the page the website's own \"Book your Free\n// Pup Talk\" button leads to) contains BOTH strings. /widget/bookings/ and\n// /widget/booking/ are two URL forms for one object; both return 200 and both land on\n// her calendar. The original link was never broken. I inferred \"not hers\" from the \"pbe\" prefix —\n// which is Pet Biz Experts, the agency that set the account up and therefore named the slug — and\n// stated the inference as a verified finding. That is the error, and it is the kind that matters\n// more than the code change.\n//\n// The current value is kept anyway, for one real reason that survives the retraction: the engine\n// watches PUP_TALK_CALENDAR_ID (qHuYJ0NEqzibnoqf5Cw3) to detect a booking, so using the calendar-id\n// form makes the link a lead clicks and the object the engine watches literally the same string,\n// with no slug indirection to go stale. Secondary: the word \"discovery\" does not appear in it, and\n// Kim asked for \"Pup Talk\" instead.\n//\n// Regression test A1 asserts `!includes(\"pbe-\")`. That assertion is now a style rule, not a\n// correctness rule. Left in place; the comment above is the correction of record.\nexport const REAL_BOOKING_URL =\n \"https://api.leadconnectorhq.com/widget/booking/qHuYJ0NEqzibnoqf5Cw3\";\nexport const SHORT_BOOKING_LINK = Deno.env.get(\"SHORT_BOOKING_LINK\") || REAL_BOOKING_URL;\n\n// Phone number: two live candidates, and the earlier note here (\"zero signals point to 912-823-4382\")\n// is CORRECTED as of 2 Aug 2026. Signals for 912-823-4382 turned out to be strong: it is the meeting\n// location on 73 of 193 Pup Talk appointments, it is the number in the default confirmation text of\n// BOTH booking widgets (\"please call our office at (912) 823-4382\"), and thedogsspotga.com/about-5\n// tells customers to ring it to schedule a training drop-off.\n// Still using 912-348-8726, on a narrower and now-honest basis: it is the number in the website\n// footer on every page and behind the home page \"Call Us\" button, so it is the number a lead who\n// found the site already has. Both are real. Kim must pick one before go-live — flagged on the todo\n// list, not decided quietly.\nexport const PHONE_DISPLAY = Deno.env.get(\"PHONE_DISPLAY\") || \"912-348-8726\";\n\nexport type Channel = \"email\" | \"sms\";\n\nexport type MessageTemplate = {\n id: string;\n channel: Channel;\n offsetHours: number;\n subject?: string; // email only\n previewText?: string; // email only\n bodyTemplate: string;\n};\n\n// ---- message copy (PHASE1-PUPPY-PATH-WRITING-SHEET.md §3, VERBATIM — do not paraphrase) ----------\n// {{FIRST_NAME}} is the ONLY per-contact merge token, resolved at render time by\n// v2.0, 4 Aug 2026. {{DOG_NAME}} was removed from every message in this file and in the taper,\n// on Kim's instruction: \"we haven't always got the name and so if we have a placeholder for the\n// puppies name, it reads weird when there's no puppy in there so I think we should go with having\n// the person's name, but not necessarily the puppies name\". Facebook leads, which are four in\n// five of all inquiries, frequently arrive with no dog name at all. Every sentence that used it\n// was REWRITTEN to read naturally without one, rather than having \"your puppy\" substituted in\n// mechanically, because the mechanical version is exactly what she was objecting to.\n// Also on her instruction, same message: toilet -> potty, garden -> yard, and DAYCARE REMOVED\n// ENTIRELY. They do not offer daycare. That is the same class of error as describing grooming as\n// a service, and it had been sitting in four messages.\n// The old comment, for the record:\n// applyMergeFields(). [phone] / [link] are fixed placeholders per the writing sheet's own §1\n// distinction (Title Case = merge field, lower case = placeholder) — resolved ONCE below via real\n// template-literal interpolation of PHONE_DISPLAY / SHORT_BOOKING_LINK, not per contact.\n// **bold** markdown in messages 3/5/6 is rendered to by bodyToHtml() — that is a formatting\n// transform, not a wording change; the words themselves are untouched.\n//\n// v2.1, 6/7 Aug 2026 — five more of her own corrections (handover/REGISTER-AUG7.md §4), confirmed\n// back to her in writing 7 Aug (handover/MESSAGE-TO-KIM-7-AUG.txt, lines 80-83): main-2 no longer\n// opens \"Got your message\" (opens on the welcome instead); \"pitch\" is gone everywhere a Pup Talk is\n// described, in favour of saying what it IS; branch_a-2 and branch_b-1 lose the \"I won't chase\n// you\"/\"won't keep bugging you\" what-I-won't-do framing while the positive \"reach out\"/\"call or\n// text ... anytime\"/\"door's open\" lines next to them are kept, exactly as she asked; branch_b-2's\n// British \"getting on\" becomes \"going\". Tests: tests/kim-copy.test.mjs, section \"THE 6 AUG\n// FOLLOW-UP\".\n\nexport const MAIN_SEQUENCE: MessageTemplate[] = [\n {\n id: \"main-1\",\n channel: \"email\",\n offsetHours: 0,\n subject: \"Getting your puppy off to a good start\",\n previewText: \"A few things that matter more than people expect in these first weeks.\",\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nThanks for getting in touch.\n\nWhether you're bringing a puppy home soon, or yours is already running circles around the kitchen, the timing of what happens next matters more than people expect.\n\nA puppy's window for learning that new people, new dogs, new places and new sounds are all safe starts closing earlier than most owners realize - a lot of that learning is done by around four to five months old. Whatever they meet calmly now tends to stay easy for life. Whatever gets missed is harder to fix later. Not impossible, just harder, and it usually takes longer than it would have the first time round.\n\nOver the next few weeks I'll send you a handful of short, practical emails - biting, potty training, recall, that sort of thing. Real advice, not fluff.\n\nIf you'd rather just talk it through now, that's what a Pup Talk is for - a real conversation with our team about how things are going. Reply to this email, call or text us on ${PHONE_DISPLAY}, or grab a time here: ${SHORT_BOOKING_LINK}.\n\nKim\nThe Dogs Spot`,\n },\n {\n id: \"main-2\",\n channel: \"sms\",\n offsetHours: 2,\n // v2.1, 6/7 Aug — \"Touch 2 loses 'I got your message' and opens on the welcome.\" Kim's own\n // question about the old line: \"What message am I replying to exactly?\" (REGISTER-AUG7.md §4).\n // This can be the first thing a contact hears from her at all, so \"got your message\" did not\n // always make sense; \"welcome\" carries the same warmth without assuming a reply is owed.\n bodyTemplate: `Hi {{FIRST_NAME}}, it's Kim at The Dogs Spot. Welcome! I'll send a few honest, useful puppy emails over the next few weeks. Reply anytime, a real person reads these.`,\n },\n {\n id: \"main-3\",\n channel: \"email\",\n offsetHours: 72, // day 3\n subject: \"Puppy biting: normal, not naughty\",\n previewText: \"What's actually going on when a puppy won't stop mouthing, and what helps.\",\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nIf your puppy has started biting at hands, sleeves, ankles, shoelaces - that's not a behavior problem. It's normal. Puppies explore the world with their mouths the way toddlers explore it with their hands, and it usually gets worse before it gets better, especially once teething starts.\n\nA few things that actually help:\n\n**Redirect, don't just say no.** Keep a toy or a chew within arm's reach of wherever you usually sit, so it's already in your hand before the mouthing starts rather than after. The moment teeth touch skin, swap your hand for the toy. Saying \"no\" tells them to stop; it doesn't tell them what to do instead, and a puppy who is told to stop with nothing to switch to just tries again.\n\n**Watch for the overtired witching hour.** A lot of biting spikes happen when a puppy is overstimulated or short on sleep, not when they're being difficult. A nap often does more than any correction.\n\n**Yelp, don't wrestle.** If it hurts, a short \"ow\" and a pause in play teaches bite inhibition better than pulling your hand away, which can turn into a game.\n\nIt gets better. Most of this settles down significantly by six months, and properly once the adult teeth are in. It feels endless at week two. It isn't.\n\nIf any of that doesn't match what you're seeing, reply and tell me - I read these.\n\nKim\nThe Dogs Spot`,\n },\n {\n id: \"main-4\",\n channel: \"sms\",\n offsetHours: 144, // day 6\n bodyTemplate: `Hi {{FIRST_NAME}}, Kim here. Quick one - how's the biting and potty training going? Totally normal stage either way. Reply and let me know, happy to help.`,\n },\n {\n id: \"main-5\",\n channel: \"email\",\n offsetHours: 216, // day 9\n subject: \"A realistic potty-training timeline\",\n previewText: \"What actually helps, and why one accident isn't a setback.\",\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nPotty training questions are the ones I get asked about most, usually some version of \"is this normal?\" Almost always, yes.\n\nA young puppy's bladder is small and their control over it is genuinely limited - not a matter of trying harder. As a rough guide, a lot of trainers use \"roughly one hour of control for every month of age\" early on, which is why an eight- or ten-week-old puppy needs to go out far more often than seems reasonable.\n\nWhat tends to work:\n\n**A schedule, not a hope.** Out first thing, after every meal, after every nap, after play, and last thing at night - before you think they need it, not after.\n\n**Same spot, same word.** Consistency does more work than any product. Pick a spot, use a calm word or phrase every time, and reward the second they finish outside, not back indoors where the reward disconnects from the act.\n\n**Supervise or contain.** Accidents mostly happen when a puppy has quiet, unsupervised access to another room. A crate, a pen, or simply keeping them in sight closes that gap.\n\n**No telling off for accidents.** By the time you've found it, they have moved on. Telling them off teaches confusion, not house manners.\n\nMost puppies are largely reliable by four to six months, and fully reliable somewhat later. If yours is well past that and still having accidents daily, that's worth looking at properly rather than pushing through - reply and tell me what's happening.\n\nKim\nThe Dogs Spot`,\n },\n {\n id: \"main-6\",\n channel: \"email\",\n offsetHours: 312, // day 13\n subject: \"Recall is a habit, not a hope\",\n previewText: `Why \"come\" is worth starting now, even before it matters.`,\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nRecall - getting your puppy to come back reliably - is the one piece of training that keeps a dog safe for the rest of their life. It's also the easiest one to start too late.\n\nThe mistake most people make isn't training it wrong. It's not starting until it's needed - at the park, off lead, with distractions already in the way. By then you're teaching recall and competing for attention at the same time.\n\nStarted early, it's simple:\n\n**Practice where nothing's competing for attention.** Hallway, living room, yard. Say the word once, and make coming back to you the best thing that happens all day - food, praise, a game, whatever they actually want.\n\n**Never call for something unpleasant.** If \"come\" ever means bath time, nail clipping, or the end of a walk, it stops meaning \"good things happen.\" Go get them for that instead.\n\n**Reward every single time, at first.** Not just the good ones. Recall is a habit you're building, not a trick you're testing.\n\nRecall is the one people most often ask me to look at, usually because it worked in the yard and then stopped working everywhere else. If you'd like a hand with it, a Pup Talk is a free twenty-minute call: ${SHORT_BOOKING_LINK}, or call or text ${PHONE_DISPLAY}.\n\nKim\nThe Dogs Spot`,\n },\n {\n id: \"main-7\",\n channel: \"sms\",\n offsetHours: 408, // day 17\n bodyTemplate: `Hi {{FIRST_NAME}}, no pressure at all - if you'd like to talk through training or boarding for your puppy, we're easy to reach. Call or text ${PHONE_DISPLAY}, or book a time here: ${SHORT_BOOKING_LINK}. Kim, The Dogs Spot`,\n },\n {\n id: \"main-8\",\n channel: \"email\",\n offsetHours: 504, // day 21\n subject: \"The last puppy email from me for now\",\n previewText: \"What matters most from the last three weeks, and an open door.\",\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nThis is the last of the every-few-days emails, so a quick summary of everything I've sent: get your puppy meeting the world calmly while that window's open, expect the biting and treat it as normal, keep the potty-training schedule boring and consistent, and start recall before you need it, not after.\n\nNone of that is complicated. Most of it is just easy to talk yourself out of doing consistently when you're tired and there's a puddle on the floor again.\n\nFrom here I'll slow right down - a short note each week for a few weeks, then less and less, only ever the useful kind. If you'd like to talk any of this through properly - what's normal for your puppy specifically, what training or boarding would actually suit your week, what it costs and when it makes sense to start - that's what a Pup Talk is for. It's a conversation. Reply here, call or text ${PHONE_DISPLAY}, or grab a time yourself: ${SHORT_BOOKING_LINK}.\n\nAnd if now just isn't the right time, that's completely fine too. No hard feelings, and the door doesn't close.\n\nKim\nThe Dogs Spot`,\n },\n];\n\nexport const BRANCH_A: MessageTemplate[] = [\n {\n id: \"branch_a-1\",\n channel: \"sms\",\n offsetHours: 2,\n bodyTemplate: `Hi {{FIRST_NAME}}, it's Kim - looks like we missed each other for your Pup Talk. No worries at all, it happens. Want me to find another time? Just reply and I'll schedule it.`,\n },\n {\n id: \"branch_a-2\",\n channel: \"email\",\n offsetHours: 24, // day +1\n subject: \"Let's find another time\",\n previewText: \"Fifteen minutes, whenever actually suits.\",\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nI noticed we had a Pup Talk scheduled, but we missed each other. No worries at all, I know life gets busy.\n\nIt's a quick, no-pressure call where we'll talk about what's been going on, answer any questions you have, and see whether training with us would be a good fit. And if we're not the right fit, I'll tell you that too.\n\nJust reply with a couple of times that work for you, call or text me at ${PHONE_DISPLAY}, or book a time that's convenient here: ${SHORT_BOOKING_LINK}.\n\nIf I don't hear back, I'll assume now just isn't the right time. Whenever you're ready, just reach out, I'd be happy to help.\n\nKim\nThe Dogs Spot`,\n },\n];\n\nexport const BRANCH_B: MessageTemplate[] = [\n {\n id: \"branch_b-1\",\n channel: \"email\",\n offsetHours: 24, // day +1 after the call\n subject: \"Good talking with you\",\n previewText: \"Just a couple of things from our conversation.\",\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nThanks for the call. It's genuinely useful for me to hear how things are going, even outside of anything you decide to book.\n\nIf it's not the right time for training or boarding with us, that's completely fine. A lot of people need more than one conversation before it's the right moment, and that's how it should work - nobody should sign up on a call because it felt awkward not to.\n\nIf anything changes, or a question comes up later that we didn't cover, reply here or call or text ${PHONE_DISPLAY} anytime. I'd just rather you knew the door's open than wonder.\n\nKim\nThe Dogs Spot`,\n },\n {\n id: \"branch_b-2\",\n channel: \"sms\",\n offsetHours: 192, // day +8 after the call\n bodyTemplate: `Hi {{FIRST_NAME}}, Kim again - no news needed, just checking how it's going for you both. If a question's come up since we spoke, reply here anytime. No pressure either way.`,\n },\n];\n\n\n",[531],"cf4bd546-2941-4b3f-a326-4031435e44ed","SOURCE-BUNDLE.part6.txt","f58f8f72-91ad-11f1-82b0-1607ee4eb77e",1092,["D",1786801896938],46,"THE DOGS SPOT — SOURCE BUNDLE (part 6 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (3 of 116 files)\n engine/holiday-deposits.ts 50761 bytes 65026619eb4a\n engine/kim-stories.ts 5461 bytes 66b22bd3d93d\n engine/money-match.ts 10258 bytes 428c6fd65499\n\n================================================================================================\n=====FILE engine/holiday-deposits.ts =====\n// HOLIDAY DEPOSIT TRACKER. v1.0, 6 Aug 2026.\n//\n// WHAT KIM ASKED FOR: she charges a $50 nonrefundable deposit on boarding stays over holidays,\n// and today somebody goes through the bookings by hand to work out who has paid.\n//\n// WHAT THIS CAN AND CANNOT DO, because the difference is the whole honesty of the feature.\n// Square money DOES reach the CRM. It arrives as a note on the contact, like\n// \"[Square] +$355.00 payment tWYOxuFcG9ZqzF7GTnUPfElf2ZEZY (balance $0.00)\"\n// (verified live on 6 Aug against a real contact). So we can see payments that went through\n// Square. We CANNOT see a deposit handed over in cash or taken over the phone. That means this\n// produces a SHORTLIST TO CHECK, never a list of people who have not paid. The word \"unpaid\"\n// is banned from anything this module renders, and a test enforces that.\n//\n// TWO TRAPS FOUND IN HER REAL DATA, both of which would have made Kim chase the wrong people:\n// 1. The same Square payment is written into the notes FIVE times, and the \"(balance ...)\"\n// figures inside those duplicates contradict each other ($355.00 then $0.00 four times).\n// So: dedupe on the payment id, and never read the balance figure.\n// 2. A recurring weekly slot (\"Daycare Enzo\") lands inside every holiday window. Without a\n// recurring filter Kim would be told a regular customer owes her a holiday deposit eight\n// times over. Recurring bookings are excluded.\n//\n// THIS MODULE WRITES NOTHING. No tag, no custom field, no pipeline stage, no message. That is\n// deliberate and it is tested: addTag() elsewhere in this engine is not TEST_MODE-guarded, and\n// this account contains a workflow (\"Add tag 'red flag' = DND\") which proves a single tag here\n// can silence a real customer on six channels. A read-only report cannot do that.\n\nexport type CalEvent = {\n contactId?: string | null;\n title?: string | null;\n startTime?: string | number | null; // carries its own offset, e.g. \"2026-11-25T09:00:00-05:00\"\n // The pick-up. A stay that starts before a holiday window and runs into it is a holiday stay,\n // and without this the module could only see the drop-off day.\n endTime?: string | number | null;\n dateAdded?: string | null;\n appointmentStatus?: string | null;\n // Her CRM really does return BOTH spellings on the same object: 4 of the 13 events on the\n // Boarding Drop Off calendar carry `appoinmentStatus` alongside the correct one (checked live,\n // 6 Aug 2026). They agree today. Reading only one of them is passing a test by luck.\n appoinmentStatus?: string | null;\n isRecurring?: boolean | null;\n deleted?: boolean | null;\n};\n\n// \"direct\" = \"[Square] +$35.00 payment (balance $x)\" — money arriving\n// \"matched\" = \"[Square] Till payment $35.00 on . Matched from Square payment ...\"\n// — a RECONCILIATION record written by the backfill, carrying its own separate id.\n// Both are real and both are live in her account on the same contact, with the same amount and\n// two different ids. See collapseSameMoney() for why that distinction has to survive parsing.\nexport type Payment = { amount: number; id: string; at: string | null; kind: \"direct\" | \"matched\" };\n\nexport type Stay = {\n contactId: string;\n day: string; // local date of the drop-off, \"YYYY-MM-DD\"\n until: string; // local date of the pick-up; equals `day` when the CRM does not say\n dogs: string[]; // one stay can be several dogs (names, best effort)\n dogCount: number; // how many drop-off rows this stay is, whether or not the names parsed\n bookedAt: string | null;\n window: string; // which holiday it falls in, in Kim's words\n};\n\nexport type StayStatus = {\n stay: Stay;\n state: \"seen\" | \"partial\" | \"none_seen\" | \"could_not_check\";\n amountSeen: number;\n note: string; // the plain-English reason, always populated\n};\n\n/** The fourth Thursday of November. Computed, never typed, so it cannot drift year to year.\n * Kim was told Thanksgiving is handled by working it out fresh each year. This is that. */\nexport function thanksgiving(year: number): string {\n // day 1 of November, then walk to the first Thursday, then add three weeks.\n const first = new Date(Date.UTC(year, 10, 1));\n const dow = first.getUTCDay(); // 0 Sun .. 4 Thu\n const firstThu = 1 + ((4 - dow) + 7) % 7;\n const day = firstThu + 21;\n return `${year}-11-${String(day).padStart(2, \"0\")}`;\n}\n\n/** The windows a deposit applies to, as dates, derived rather than hardcoded.\n * Thanksgiving: the Monday before through the Sunday after.\n * Christmas and New Year: 20 Dec through 2 Jan.\n * If Kim wants different edges these are the only two lines to change. */\nexport function holidayWindows(year: number): { name: string; from: string; to: string }[] {\n const t = thanksgiving(year);\n // [was: String(Number(t.slice(8)) + 3) — decimal arithmetic on the day number. Whenever\n // Thanksgiving falls on the 28th (2030, 2041, ...) that produced \"2030-11-31\", a date that does\n // not exist. Two consequences, both live: a stay dropping off Sunday 1 December sorts ABOVE\n // \"2030-11-31\" in a string compare and vanishes from the window, and the card printed the\n // words \"Thanksgiving (Nov 25 to Nov 31)\" to Kim. Real calendar arithmetic now.]\n return [\n { name: \"Thanksgiving\", from: shiftDays(t, -3), to: shiftDays(t, 3) },\n { name: \"Christmas and New Year\", from: `${year}-12-20`, to: `${year + 1}-01-02` },\n ];\n}\n\n/** The local calendar day of an appointment. startTime carries its own offset, so the first ten\n * characters ARE the local day. Parsing it into a Date and reformatting would shift bookings\n * across midnight into or out of a window, which is how a customer gets chased by mistake.\n *\n * A NUMBER is handled separately and deliberately. Two sibling modules that read this same CRM\n * endpoint already defend against an epoch-millisecond startTime, so the shape is real. Returning\n * null for it would have dropped EVERY stay silently and stored \"no holiday stays are booked\" as\n * a fact, in November, with the kennels full. An epoch has no offset, so it is converted in the\n * business's own timezone rather than in whatever timezone the server happens to be in. */\nexport const BUSINESS_TZ = \"America/New_York\";\nexport function localDay(startTime: string | number | null | undefined): string | null {\n if (typeof startTime === \"number\" && Number.isFinite(startTime)) {\n try {\n const p = new Intl.DateTimeFormat(\"en-CA\", { timeZone: BUSINESS_TZ, year: \"numeric\", month: \"2-digit\", day: \"2-digit\" })\n .format(new Date(startTime));\n return /^\\d{4}-\\d{2}-\\d{2}$/.test(p) ? p : null;\n } catch { return null; }\n }\n if (!startTime || typeof startTime !== \"string\" || startTime.length < 10) return null;\n // A STRING ENDING IN Z IS UTC, AND ITS FIRST TEN CHARACTERS ARE NOT THE LOCAL DAY.\n //\n // The slice below is right for \"2026-11-25T21:00:00-05:00\", which carries New York's own offset.\n // It is wrong by a whole day for \"2026-11-26T02:00:00Z\", which is the same instant: every evening\n // drop-off from about 7pm Eastern reads as the NEXT calendar day. A stay on 2 January — the last\n // day of the Christmas and New Year window — moves to the 3rd, falls outside `to`, and the\n // customer silently never appears on Kim's shortlist at all. No error, no \"could not check\".\n //\n // Said plainly: this shape has NOT been seen on this endpoint. Every startTime read live on 6 and\n // 7 August carried an explicit offset. But two sibling modules already defend against an epoch\n // number from this same CRM, a Z suffix is unambiguous when it does appear, and converting it in\n // the business's own timezone costs one branch. Handling it is cheap; slicing it is wrong.\n if (/\\dZ$/.test(startTime)) {\n const t = Date.parse(startTime);\n return Number.isFinite(t) ? localDay(t) : null; // through the epoch branch, in BUSINESS_TZ\n }\n const d = startTime.slice(0, 10);\n return /^\\d{4}-\\d{2}-\\d{2}$/.test(d) ? d : null;\n}\n\n/** WHICH SEASON ARE WE IN. Passed the local date as \"YYYY-MM-DD\", never reading the clock itself,\n * so this is testable and cannot behave differently on the val than it does here.\n * On 1 January the season that matters is still LAST year's — the New Year window runs to the 2nd,\n * and a page that flips to next Thanksgiving on New Year's Day drops the stays happening that day. */\nexport function businessDay(nowIso: string): string {\n // Her business is in New York. Rolling the season over on the UTC date empties the card at 8pm\n // on 2 January, five hours before the season actually ends, while dogs are still in the kennels\n // — and the empty result then gets stored over the real one.\n try {\n const d = new Date(nowIso);\n if (isNaN(d.getTime())) return String(nowIso).slice(0, 10);\n const p = new Intl.DateTimeFormat(\"en-CA\", { timeZone: BUSINESS_TZ, year: \"numeric\", month: \"2-digit\", day: \"2-digit\" }).format(d);\n return /^\\d{4}-\\d{2}-\\d{2}$/.test(p) ? p : String(nowIso).slice(0, 10);\n } catch { return String(nowIso).slice(0, 10); }\n}\n\nexport function seasonYear(today: string): number {\n const y = Number(today.slice(0, 4));\n const md = today.slice(5, 10);\n return md <= \"01-02\" ? y - 1 : y;\n}\n\nexport function windowFor(day: string | null, windows: { name: string; from: string; to: string }[]): string | null {\n if (!day) return null;\n for (const w of windows) if (day >= w.from && day <= w.to) return w.name;\n return null;\n}\n\n/** A STAY, not a moment. Somebody who drops off on 19 December and collects on 27 December has\n * boarded over Christmas and owes the holiday deposit, but their drop-off day is outside the\n * window. Deciding membership on the drop-off day alone dropped exactly the customers a holiday\n * boarding business has most of: the ones who leave the day before they travel. */\nexport function windowForRange(from: string | null, to: string | null, windows: { name: string; from: string; to: string }[]): string | null {\n if (!from) return null;\n const end = to && to >= from ? to : from;\n for (const w of windows) if (from <= w.to && end >= w.from) return w.name;\n return null;\n}\n\n/** Which bookings count. Cancelled, deleted and recurring are all excluded, and the recurring\n * exclusion is the one that matters most: a standing weekly slot is not a holiday stay. */\nexport const DEAD_STATUSES = [\"cancelled\", \"canceled\", \"noshow\", \"no-show\", \"no show\", \"invalid\"];\nexport function eligible(e: CalEvent): boolean {\n if (!e || truthy(e.deleted)) return false;\n // [was: `e.isRecurring === true`. Her CRM has already been caught shipping the misspelled\n // `appoinmentStatus`, so trusting it to always send a real boolean here is a bet, not a fact.\n // A recurring series returned with isRecurring:\"true\" would have put a weekly daycare regular\n // on the list telling him he owes a boarding deposit.]\n if (truthy(e.isRecurring)) return false;\n // BOTH spellings are read, and either one saying cancelled is enough to drop the booking.\n // The asymmetry is deliberate: dropping a live booking means Kim is not prompted about it and\n // she notices; keeping a cancelled one means she chases a customer who already cancelled, and\n // that one she cannot take back.\n // TRIMMED, because this account demonstrably ships padded strings: \"Daycare Enzo \" and\n // \" Boarding Dropoff with Help Test\" are both real titles out of it. One trailing space on a\n // status was enough to make a cancelled booking eligible.\n const states = [e.appointmentStatus, e.appoinmentStatus].map((s) => String(s ?? \"\").trim().toLowerCase());\n // EXPORTED so a test can assert the whole list rather than the one spelling somebody thought\n // of. GHL really does emit `noshow` and `invalid`, and the American spelling is one keystroke\n // away. Letting any of them through puts a customer who cancelled on Kim's chase list, which\n // the comment above calls the mistake she cannot take back.\n const dead = DEAD_STATUSES;\n if (states.some((s) => dead.includes(s))) return false;\n if (!e.contactId) return false;\n // A DAYCARE slot is not a boarding stay and carries no boarding deposit. Until now the ONLY\n // thing keeping the weekly \"Daycare Enzo\" booking off Kim's list was its recurrence flag; a\n // one-off daycare booking in Christmas week would have been billed a $50 boarding deposit.\n // Narrowed: a title that says BOTH is a boarding booking with a note on it, and excluding\n // \"Boarding + daycare drop off with Dan Bonner\" would lose a real holiday stay.\n const title = String(e.title ?? \"\");\n if (/\\bday\\s?care\\b/i.test(title) && !/\\bboarding\\b/i.test(title)) return false;\n return true;\n}\n\n/** Her CRM's booleans are not reliably booleans. Treats \"true\"/\"TRUE\"/1 the same as true, and\n * anything else, including undefined, as false. */\nfunction truthy(v: unknown): boolean {\n if (v === true || v === 1) return true;\n return typeof v === \"string\" && v.trim().toLowerCase() === \"true\";\n}\n\n/** A dog's name out of \"Achilles — Boarding Drop Off\" style titles, best effort and never fatal. */\nexport function dogFromTitle(title: string | null | undefined): string {\n const t = (title || \"\").trim();\n if (!t) return \"\";\n // [was: split on /[—–-]/, which cut \"Jean-Luc — Boarding Drop Off\" down to \"Jean\". A hyphen\n // inside a name is not a separator; a SPACED hyphen is. Kim reads these names before phoning\n // somebody, so the wrong name here is a wrong conversation.]\n const cut = t.split(/\\s[—–-]\\s|[—–]|\\bBoarding\\b|\\bDrop\\s?off\\b/i)[0];\n return cut.trim().replace(/\\s+with\\s+.*$/i, \"\").trim();\n}\n\n/** WHERE THE END OF A STAY ACTUALLY LIVES. A drop-off appointment in her CRM is a TEN MINUTE\n * slot: \"2026-11-25T12:50 to 2026-11-25T13:00\". Its endTime is the end of the handover, not the\n * end of the boarding. The real length of the stay is on a separate Boarding Pick Up calendar —\n * Ghost and Chewy drop off on 25 November and are collected on the 28th, and only the pick-up\n * calendar says so. Without this, \"did this dog board over Christmas\" could only ever be answered\n * by the drop-off date, and everybody who leaves the day before the holiday starts was invisible.\n * The LATEST eligible pick-up on or after the drop-off wins, bounded by the customer's own next\n * booking and by MAX_STAY_DAYS. */\nexport const MAX_STAY_DAYS = 21;\nexport function attachPickups(stays: Stay[], pickups: CalEvent[]): Stay[] {\n const byContact = new Map();\n for (const p of pickups) {\n if (!eligible(p)) continue;\n const d = localDay(p.startTime);\n if (!d || !p.contactId) continue;\n const list = byContact.get(p.contactId) ?? [];\n list.push(d);\n byContact.set(p.contactId, list);\n }\n for (const list of byContact.values()) list.sort();\n // The customer's OWN next drop-off is the hard upper bound. Without it a stay reaches forward\n // and takes a pick-up belonging to a later booking: a 3-night Thanksgiving stay was rendered\n // \"Nov 25 to Dec 27\", and an ordinary 6 November boarding was dragged into a holiday window and\n // billed a deposit. [was: the EARLIEST pick-up on or after the drop-off, which was wrong the\n // other way — one dog of three going home early cut the stay short and deleted it from the\n // window entirely. Her pick-up calendar really does carry one row per dog.]\n // A stay cannot run forever. Without an upper bound an ORPHAN pick-up — and her account has\n // about twenty contacts with pick-ups and no matching drop-off — drags an out-of-season boarding\n // into a holiday window: a 6 November stay with a stray 1 February pick-up record rendered as\n // \"Nov 6 to Feb 1\" on Kim's shortlist.\n const dropDays = new Map();\n for (const s of stays) {\n const list = dropDays.get(s.contactId) ?? [];\n list.push(s.day);\n dropDays.set(s.contactId, list);\n }\n for (const list of dropDays.values()) list.sort();\n return stays.map((s) => {\n const nextDrop = (dropDays.get(s.contactId) ?? []).find((d) => d > s.day);\n // `<=` on the next drop-off, not `<`: a pick-up on the same day as the customer's next\n // booking is the END of this stay, not part of the next one. With a strict `<`, a customer\n // collecting on 27 December and re-boarding the same day lost their Christmas stay entirely.\n const cands = (byContact.get(s.contactId) ?? []).filter((d) =>\n d >= s.day && d <= shiftDays(s.day, MAX_STAY_DAYS) && (!nextDrop || d <= nextDrop));\n const cand = cands.length ? cands[cands.length - 1] : null;\n return cand && cand > s.until ? { ...s, until: cand } : s;\n });\n}\n\n/** One customer dropping three dogs on the same day is ONE stay and ONE deposit question. */\nexport function groupIntoStays(\n events: CalEvent[],\n windows: { name: string; from: string; to: string }[],\n pickups: CalEvent[] = [],\n): Stay[] {\n const by = new Map();\n for (const e of events) {\n if (!eligible(e)) continue;\n const day = localDay(e.startTime);\n const until = localDay(e.endTime) ?? day;\n if (!day) continue;\n const key = `${e.contactId}|${day}`;\n const dog = dogFromTitle(e.title);\n const existing = by.get(key);\n if (existing) {\n if (dog && !existing.dogs.includes(dog)) existing.dogs.push(dog);\n // COUNTED FROM THE ROWS, not from the names. A title that does not parse still means a dog,\n // and the deposit is charged per dog, so counting parsed names would under-charge.\n existing.dogCount++;\n // the LATEST pick-up across the dogs on this stay\n if (until && until > existing.until) existing.until = until;\n // keep the EARLIEST booking time: that is when the deposit became due\n if (e.dateAdded && (!existing.bookedAt || e.dateAdded < existing.bookedAt)) existing.bookedAt = e.dateAdded;\n } else {\n by.set(key, { contactId: e.contactId!, day, until: until ?? day, dogs: dog ? [dog] : [], dogCount: 1, bookedAt: e.dateAdded ?? null, window: \"\" });\n }\n }\n // Pick-ups are attached BEFORE the window filter, because the whole point is that a stay whose\n // drop-off falls outside a window can still run through it.\n const withEnds = attachPickups([...by.values()], pickups);\n const out: Stay[] = [];\n for (const s of withEnds) {\n const win = windowForRange(s.day, s.until, windows);\n if (win) out.push({ ...s, window: win });\n }\n return out.sort((a, b) => (a.day < b.day ? -1 : a.day > b.day ? 1 : 0));\n}\n\n/** Square payments out of contact notes, DEDUPED BY PAYMENT ID.\n * The same payment appears five times in her real data with contradictory balance figures, so\n * the balance is deliberately not read: only the amount and the payment's own id. */\nexport function parseSquarePayments(notes: { body?: string | null; dateAdded?: string | null }[] | null | undefined): Payment[] {\n const out = new Map();\n // EVERY match in EVERY note, not the first match in each.\n // [was: .exec() on each body, i.e. one payment per note. A note holding two Square lines lost\n // the second one. Every parser gap in this function fails in the same direction — less money\n // seen than was paid — and that direction is the one that puts a paying customer on the list.]\n // The amount tolerates whole dollars (\"+$50 payment\") as well as cents, and the id stops at\n // punctuation so a trailing comma cannot become part of the dedupe key.\n const DIRECT = /\\[Square\\]\\s*\\+?\\$([\\d,]+(?:\\.\\d{2})?)\\s+payment\\s+([A-Za-z0-9_-]+)/gi;\n // Format 2: the reconciliation backfill. It carries the REAL payment date in its own text,\n // which is four days earlier than the note's dateAdded on the live example, so the stated\n // date is used and the note's write time is only the fallback. The trailing punctuation after\n // the id is OPTIONAL: on a note that ENDS at the id the whole payment used to vanish.\n const MATCHED = /\\[Square\\][^[]*?Till payment\\s*\\$([\\d,]+(?:\\.\\d{2})?)\\s*on\\s*(\\d{4}-\\d{2}-\\d{2})[\\s\\S]*?Matched from Square payment\\s+([A-Za-z0-9_-]+)/gi;\n const add = (amount: number, id: string, at: string | null, kind: \"direct\" | \"matched\") => {\n if (!Number.isFinite(amount) || !id) return;\n const prev = out.get(id);\n // keep the earliest sighting of a given payment\n if (!prev || (at && prev.at && at < prev.at)) out.set(id, { amount, id, at, kind });\n else if (!prev.at) out.set(id, { amount, id, at, kind });\n };\n for (const n of notes ?? []) {\n const body = n?.body ?? \"\";\n if (!body) continue;\n for (const m of body.matchAll(MATCHED)) add(Number(m[1].replace(/,/g, \"\")), m[3], m[2], \"matched\");\n for (const m of body.matchAll(DIRECT)) add(Number(m[1].replace(/,/g, \"\")), m[2], n?.dateAdded ?? null, \"direct\");\n }\n return [...out.values()].sort((a, b) => String(a.at).localeCompare(String(b.at)));\n}\n\n/** THE SAME $35, TWICE, UNDER TWO IDS.\n * Live on David Newman's contact right now: \"+$35.00 payment z3rQ...\" and \"Till payment $35.00\n * on 2026-07-17. Matched from Square payment 3zu7...\". Same money or two payments? Nothing in\n * the data settles it, and the two readings disagree about whether a $50 deposit is covered.\n * So the conservative reading wins: a \"Matched from\" record of the same amount as a direct\n * payment is treated as describing that same money. Getting this wrong the other way removes a\n * person from the shortlist, and a person who is not on the shortlist is never looked at. */\n/** A CONTACT THAT LOOKS LIKE SOMEBODY TESTING THE BOOKING FORM. Kim's account holds at least two:\n * a contact literally named \"help test\" with three future boarding bookings, and a tagged\n * \"ZZTEST PuppyPath-Dummy\". This does NOT remove the row — a filter that quietly drops a real\n * customer called Mr Test is worse than a label — it flags it, so Kim knows before she picks up\n * the phone to a stranger about $50. */\nexport function looksLikeTestRecord(name: string | null | undefined): boolean {\n // \"tester\" is deliberately absent: Tester is a real surname, and this label appears on Kim's\n // screen right next to a person's name, immediately before she decides whether to phone them.\n return /\\b(test|testing|dummy|zztest|do not use|ignore)\\b/i.test(String(name ?? \"\"));\n}\n\n// 21 DAYS, and the number is not a guess. The one real pair on her account is a payment noted on\n// 31 July reconciling a till payment the backfill states was taken on 17 July: 14.6 days, because\n// the parser deliberately uses the backfill's OWN stated payment date rather than the day the note\n// was written. A fortnight would have been too tight for the only case anybody has ever seen, so\n// the bound carries about 40% headroom over it and still refuses to fold across months.\nexport const COLLAPSE_WINDOW_DAYS = 21;\nexport function collapseSameMoney(payments: Payment[]): { kept: Payment[]; collapsed: number } {\n // IDEMPOTENT, and now DATE-BOUNDED. Both properties are load-bearing.\n //\n // Idempotent [round 6]: every backfill record sharing an amount with a payment folds, so a\n // second pass finds nothing. The layers above assume that.\n //\n // Date-bounded [round 9]: a \"Matched from Square payment\" note is a reconciliation of a payment\n // near it in TIME. The one real pair on her account is four days apart; the code was folding on\n // amount alone, across the customer's whole history. $50 is precisely the amount a repeat\n // customer pays more than once in a year, so a November payment and a December till record were\n // being read as one $50 — deleting a real deposit, demoting a settled stay, and then printing\n // \"nothing unspent on file matches that amount\" and \"nothing else is unaccounted for\" about a\n // customer who had paid twice. 2.3% of generated customers. Same false sentence as round 8's\n // bug, a different door.\n //\n // The bias is unchanged and deliberate: folding keeps somebody ON the shortlist, which costs Kim\n // a glance. NOT folding a genuine duplicate would clear somebody who owes, which costs her $50\n // and she never finds out. The bound only stops folding across months, where \"same money\" stops\n // being a plausible reading at all.\n const directs = payments.filter((p) => p.kind === \"direct\");\n const kept: Payment[] = [];\n let collapsed = 0;\n for (const p of payments) {\n if (p.kind === \"matched\" && directs.some((d) => d.amount === p.amount && withinDays(d.at, p.at, COLLAPSE_WINDOW_DAYS))) {\n collapsed++;\n continue;\n }\n kept.push(p);\n }\n return { kept, collapsed };\n}\n\n/** Are two payment dates close enough to be the same money? A missing date on either side counts\n * as close: an undated record is not evidence that they are far apart. */\nexport function withinDays(a: string | null, b: string | null, days: number): boolean {\n const x = Date.parse(String(a ?? \"\")), y = Date.parse(String(b ?? \"\"));\n if (!Number.isFinite(x) || !Number.isFinite(y)) return true;\n return Math.abs(x - y) <= days * 86_400_000;\n}\n\nexport const DEPOSIT = 50;\n\n/** WHAT THIS STAY OWES. Kim's own money page, taken from her live website: \"Holiday boarding —\n * $50 PER DOG, non-refundable. Deducted from the total boarding cost at drop-off.\"\n * [was: a flat $50 per stay, with a line on the card asking Kim to tell us if it was per dog.\n * It is per dog, and it says so in her own handover pack. Jeffrey Musselwhite's three dogs on\n * 25 November owe $150, and a single $50 payment was clearing that whole stay — the silent\n * direction, where somebody who owes $100 more drops off the list and is never looked at.] */\nexport function depositDue(stay: Stay): number {\n return DEPOSIT * dogsOn(stay);\n}\nexport function dogsOn(stay: Stay): number {\n return Math.max(1, stay.dogCount || stay.dogs.length || 1);\n}\n\n/** THE ONE PLACE THAT DECIDES WHICH PAYMENTS SETTLE A STAY. Returns them, or nothing.\n *\n * This exists because the money bug has now come back FOUR times, and every time through the\n * same crack: the rule for \"is this stay settled\" and the rule for \"what did that cost\" lived in\n * two places and drifted apart. The last version cleared a stay on either one payment for the\n * full amount OR one $50 per dog, and then debited a single $50 — so a two-dog stay settled by a\n * $100 payment debited NOTHING, and the same $100 settled the customer's next stay too. Kim owed\n * $200, $100 arrived, neither row reached her shortlist. 29% of generated multi-stay customers\n * hit it.\n *\n * So there is one function. statusFor asks it what settles the stay; the allocator asks it what\n * to spend. They cannot disagree, because it is the same answer. */\nexport function qualifyingPayments(stay: Stay, payments: Payment[]): Payment[] {\n // OLDEST MONEY FIRST, and never in whatever order the array happened to arrive.\n //\n // [was: `near.find(...)` and `perDog.slice(0, dogs)` straight off the caller's array. Two things\n // came out of that, found by a property test over 841,000 shuffles on 7 August:\n // 1. The same customer, the same payments, a different array order, a different answer. There\n // is no meaningful order on this list — it is whatever the notes endpoint returned — so a\n // row could move between \"Payment on file\" and \"Worth a look\" from one hourly run to the\n // next with nothing whatsoever having changed on her account.\n // 2. Worse, it could starve a later stay. Two real $50 payments, both inside the FIRST stay's\n // window, only the later one inside the SECOND stay's window: settle the first stay with the\n // later payment and the second stay has nothing left it can reach, and reads as unpaid.\n // Settle it with the earlier one and both are correctly settled. Oldest-first is the reading\n // that matches how the money was actually spent, and it is stable.\n // Sorted by id as well as date, so two payments stamped the same second cannot swap either.]\n // A payment with no readable date sorts LAST, not first: \"oldest first\" is a claim, and an\n // undated record is not evidence that it is the oldest. DEFENSIVE ONLY, and there is no negative\n // control for it on purpose: paymentsNearStay compares (p.at || \"\").slice(0, 10) against the\n // window, \"\" is below every real date, so an undated payment is filtered out before this line\n // ever sees it. A control that cannot be made to fail is worse than no control. H86 pins the\n // reachable half of that — an undated record never qualifies for a stay at all.\n const when = (p: Payment) => {\n const t = p.at ? Date.parse(p.at) : NaN;\n return Number.isFinite(t) ? t : Number.POSITIVE_INFINITY;\n };\n const near = [...collapseSameMoney(paymentsNearStay(stay, payments)).kept]\n .sort((a, b) => when(a) - when(b) || String(a.id).localeCompare(String(b.id)));\n const due = depositDue(stay);\n const dogs = dogsOn(stay);\n const whole = near.find((p) => p.amount === due);\n if (whole) return [whole];\n const perDog = near.filter((p) => p.amount === DEPOSIT);\n return perDog.length >= dogs ? perDog.slice(0, dogs) : [];\n}\n\n// HOW A PAYMENT IS MATCHED TO A DEPOSIT, and why the answer is \"it mostly is not\".\n//\n// Nothing in her CRM says what a card payment was FOR. Two attempts at guessing have now both\n// been wrong in a way that costs her money:\n// v1 summed every payment between the booking and the drop-off. A $355 training package cleared\n// a $50 deposit, and being cleared means nobody ever looks at that customer again.\n// v2 narrowed it to ten days around the booking and still summed. That missed a real $50 paid\n// eight days later — the page said \"we cannot find a $50 payment\" one line after printing\n// one — and STILL cleared anybody who happened to settle a $240 invoice that same week.\n//\n// So this version stops guessing. It clears a stay on ONE piece of evidence only: a card payment\n// for EXACTLY the deposit amount, in a wide window around the stay. Anything else is shown to Kim\n// with its date and amount and left for her to judge, which takes her about two seconds per row\n// and is the thing she was doing by hand anyway. A wrong \"worth a look\" costs her a glance. A\n// wrong \"settled\" costs her $50 and she never finds out.\n// HOW SHE ACTUALLY GETS PAID, off her own money page: \"Card — at the counter, or through the\n// website's payments page. This is the normal route and THE ONLY ONE THAT MATCHES ITSELF TO A\n// CUSTOMER RECORD AUTOMATICALLY. Venmo — there is a Venmo page on the website. Zelle — sent to an\n// address inside the Zelle app. Cheque — made payable by post.\"\n// [was: \"may still have been paid in cash or over the phone\", which named neither of the two\n// routes she actually offers. Every one of Venmo, Zelle and cheque is invisible here, so naming\n// them is the difference between Kim knowing where to look and Kim assuming non-payment.]\n// CASH IS NOT ONE OF HER ROUTES. [was: \"Venmo, Zelle, cheque or cash\". Her money page lists\n// exactly four ways to pay — Card, Venmo, Zelle and Cheque — and cash appears nowhere on her site\n// or anywhere in the handover pack. The comment directly above this line names the three invisible\n// routes correctly and the string underneath it invented a fourth. True of cash in general,\n// invented as a thing Kim accepts, and the whole point of this sentence is telling her where else\n// to actually look.]\nexport const OTHER_ROUTES = \"A deposit paid by Venmo, Zelle or a cheque does not reach the card system, so it will not show here.\";\n// HER OTHER DEPOSIT. The same money page publishes a $250 non-refundable TRAINING deposit — which\n// is exactly what five dogs owe at $50 each. The per-dog rule widened the set of amounts that can\n// clear a stay from {$50} to {$50, $100, $150, ...}, and $250 is now in it. Nothing in the data\n// says which a $250 payment was for, so the row says so rather than quietly picking one.\nexport const TRAINING_DEPOSIT = 250;\n/** A SINGLE PAYMENT FOR A MULTI-DOG DEPOSIT IS WEAKER EVIDENCE THAN ONE $50 PER DOG, and the\n * per-dog rule quietly widened the amounts that can clear a stay from {$50} to {$50, $100, $150,\n * $200, $250, ...}. Her published boarding rates are $30-$65 a day, so five nights at $30 is $150\n * — a three-dog deposit — and the total is settled at drop-off, inside the search window. $250\n * is her training deposit exactly. Flagging only $250 patched the rarest collision and left the\n * likelier ones silent. Any lump sum above one dog's deposit now says what else it could be. */\nexport function lumpCaveat(due: number): string {\n // The count comes from the amount due, so a four-dog stay is told four and not \"two or three\" —\n // which was $100-$150 of advice printed on a $200 row, contradicting the rule the same row was\n // applying.\n if (due === TRAINING_DEPOSIT) return ` Worth an eye: $${TRAINING_DEPOSIT} is also what a training deposit costs, so this one payment could be either.`;\n if (due > DEPOSIT) return ` Worth an eye: one payment of this size could also be the boarding total rather than the deposit. ${due / DEPOSIT} separate $${DEPOSIT} payments would be clearer.`;\n return \"\";\n}\nexport const NEAR_WINDOW_BEFORE = 30; // a deposit can be taken before the booking is typed in\n\n/** Every card payment close enough to this stay to be worth putting in front of Kim. */\nexport function paymentsNearStay(stay: Stay, payments: Payment[]): Payment[] {\n if (!stay.bookedAt) return [];\n const lo = shiftDays(stay.bookedAt.slice(0, 10), -NEAR_WINDOW_BEFORE);\n const hi = shiftDays(stay.until || stay.day, 1);\n return payments.filter((p) => {\n const d = (p.at || \"\").slice(0, 10);\n return d >= lo && d <= hi;\n });\n}\n\nconst MONTHS = [\"Jan\", \"Feb\", \"Mar\", \"Apr\", \"May\", \"Jun\", \"Jul\", \"Aug\", \"Sep\", \"Oct\", \"Nov\", \"Dec\"];\n/** \"2026-07-21\" -> \"Jul 21\", the same way round as the stay dates on the card. Kim is American and\n * a row that says \"Nov 25 to Nov 28\" beside \"$50.00 on 21 Jul\" makes her read the date twice. */\nexport function prettyDay(iso: string | null | undefined): string {\n const m = /^(\\d{4})-(\\d{2})-(\\d{2})/.exec(String(iso ?? \"\"));\n return m ? `${MONTHS[Number(m[2]) - 1] ?? m[2]} ${Number(m[3])}` : \"\";\n}\n/** \"Oct 5\", \"Oct 5 and Oct 6\", \"Oct 5, Oct 6 and Oct 7\" — never \"a and b and c\". */\n/** \"on Nov 20\" when three dogs were paid for in one visit, rather than \"on Nov 20, Nov 20 and\n * Nov 20\" — which is how a family of three actually pays, at the counter, in one go. */\nexport function sameDayList(days: string[]): string {\n const uniq = [...new Set(days)];\n return uniq.length === 1 ? `on ${uniq[0]}` : `on ${humanList(uniq)}`;\n}\nexport function humanList(items: string[]): string {\n if (items.length <= 1) return items[0] ?? \"\";\n return `${items.slice(0, -1).join(\", \")} and ${items[items.length - 1]}`;\n}\n/** \"$50.00 on Dec 20\" for three taps on the same day, not the same line three times — which is\n * what a four-dog family paying at the counter produced, and reads as a rendering fault. */\nconst listPayments = (ps: Payment[]) => {\n const byAmountAndDay = new Map();\n for (const p of ps) {\n const day = prettyDay(p.at);\n const k = `${p.amount}|${day}`;\n const prev = byAmountAndDay.get(k);\n if (prev) prev.n++;\n else byAmountAndDay.set(k, { amount: p.amount, day, n: 1 });\n }\n return [...byAmountAndDay.values()]\n .map((g) => `${g.n > 1 ? `${g.n} payments of ` : \"\"}$${g.amount.toFixed(2)} on ${g.day}`)\n .join(\", \");\n};\n\nexport function shiftDays(day: string, delta: number): string {\n const d = new Date(`${day}T00:00:00Z`);\n if (isNaN(d.getTime())) return day;\n d.setUTCDate(d.getUTCDate() + delta);\n return d.toISOString().slice(0, 10);\n}\n\n/** could_not_check NEVER collapses into none_seen. A failed read must not read as \"she owes\". */\nexport function statusFor(\n stay: Stay,\n payments: Payment[] | null,\n // WHAT THE ROW SHOWS vs WHAT THE ROW IS SETTLED BY. `payments` is the money still unspent, which\n // is what may settle this stay. `opts.all` is everything on the account, which is what Kim can\n // see in Square. [was: one list for both, so a stay whose money had already been counted against\n // an earlier stay was told \"no card payment is on file around it AT ALL\" — with the payment\n // sitting right there in her window. 7.9% of generated rows. One step from an accusation, and\n // false: she phones, the customer says \"I paid on the 20th\", and they did.]\n opts: { all?: Payment[]; alreadyCounted?: Set } = {},\n): StayStatus {\n if (payments === null) {\n return { stay, state: \"could_not_check\", amountSeen: 0,\n note: \"We could not read this person's payments just now, so this one is unknown. It is not a finding either way.\" };\n }\n // No booking date means no window to search, so there is no honest answer here.\n // [was: the range fell back to the beginning of time, and a payment from 2019 cleared the stay.]\n if (!stay.bookedAt) {\n return { stay, state: \"could_not_check\", amountSeen: 0,\n note: \"This booking has no record of when it was made, so there is no period to check a deposit against. It is not a finding either way.\" };\n }\n const near = collapseSameMoney(paymentsNearStay(stay, opts.all ?? payments)).kept;\n // THE ONLY THING THAT CLEARS A STAY: a card payment for exactly the deposit. Everything else\n // gets shown to Kim with its date and left to her, because nothing in the data says what a\n // payment was for and two goes at guessing have both cost her money.\n const due = depositDue(stay);\n const dogs = dogsOn(stay);\n // TWO SHAPES OF EXACT EVIDENCE, and nothing else clears a stay: one payment for the whole\n // amount due, or one $50 payment per dog. Both are exact-amount matches. Summing whatever else\n // is on the account is what cleared a customer on a training package two versions ago.\n const exact = qualifyingPayments(stay, payments);\n const ids = new Set(exact.map((p) => p.id));\n const rest = near.filter((p) => !ids.has(p.id));\n // Money that IS in this stay's window but has already paid for one of this customer's earlier\n // stays. Naming it is the difference between an honest row and a false one.\n const counted = rest.filter((p) => opts.alreadyCounted?.has(p.id));\n const countedNote = counted.length\n ? ` ${counted.length === 1 ? `A card payment of $${counted[0].amount.toFixed(2)} on ${prettyDay(counted[0].at)} is` : `${counted.length} card payments totaling $${counted.reduce((n, p) => n + p.amount, 0).toFixed(2)} are`} around this stay too, but ${counted.length === 1 ? \"it has\" : \"they have\"} already been counted against ${counted.length === 1 ? \"an earlier stay\" : \"earlier stays\"} of theirs.`\n : \"\";\n const others = rest.filter((p) => !opts.alreadyCounted?.has(p.id));\n const restNote = (others.length\n ? ` ${others.length === 1 ? \"There is also 1 other card payment\" : `There are also ${others.length} other card payments`} on this account around this stay: ${listPayments(others)}.`\n : \"\") + countedNote;\n if (exact.length) {\n // TWO DIFFERENT PAYMENTS CAN SHARE AN AMOUNT AND A DAY, and then the settled one and the\n // left-over one render identically — which makes a correct allocation look exactly like the\n // money bug this module has fought five times. Say how many landed.\n const twinDay = exact.length === 1\n ? near.filter((p) => p.amount === exact[0].amount && prettyDay(p.at) === prettyDay(exact[0].at)).length\n : 1;\n const ofN = twinDay > 1 ? ` (one of ${twinDay} payments of that amount that day)` : \"\";\n return { stay, state: \"seen\", amountSeen: due,\n note: exact.length === 1\n ? `A card payment for exactly $${due.toFixed(2)} is on file on ${prettyDay(exact[0].at)}${ofN}, which is the deposit for ${dogs === 1 ? \"1 dog\" : `${dogs} dogs`}.${lumpCaveat(due)}${restNote}`\n : `${exact.length} card payments of $${DEPOSIT}.00 are on file, one per dog, ${sameDayList(exact.map((p) => prettyDay(p.at)))}. That is the $${due.toFixed(2)} due for ${dogs} dogs.${restNote}` };\n }\n if (near.length) {\n // SPLIT, deliberately. `others` is money Kim could still match to this stay; `counted` is money\n // that is around it but has already paid for one of the same customer's earlier stays. Lumping\n // them together is how a row ends up implying she has been paid twice, or not at all.\n // A PAYMENT CAN BE SHOWN AND NOT COUNTED. `near` is what Kim can see in this stay's window;\n // `exact` is what may settle it. A record whose fold-twin survives OUTSIDE the window is in the\n // first and not the second, and the row then denied a $50 match one clause before printing\n // \"$50.00 on Oct 15\". 1.3% of rows. The module's own header names that exact sentence shape as\n // the v2 bug it fixed, so it cannot be allowed back in a different branch.\n const blocked = others.filter((p) => p.amount === due || p.amount === DEPOSIT);\n const why = blocked.length\n ? `Square records the same money again outside this stay, so ${blocked.length === 1 ? \"it has\" : \"they have\"} not been counted here`\n : \"nothing unspent on file matches that amount\";\n const shown = others.length\n ? `${others.length === 1 ? \"1 card payment is\" : `${others.length} card payments are`} on file around it: ${listPayments(others)}. Worth a look to see whether the deposit is ${others.length === 1 ? \"that one\" : \"among them\"}.`\n : \"Nothing else on this account is unaccounted for around it.\";\n return { stay, state: \"partial\", amountSeen: others.reduce((n, p) => n + p.amount, 0),\n note: `The deposit on this stay is $${due.toFixed(2)} (${dogs === 1 ? \"1 dog\" : `${dogs} dogs`} at $${DEPOSIT}), and ${why}. ${shown}${countedNote}` };\n }\n return { stay, state: \"none_seen\", amountSeen: 0,\n note: `The deposit on this stay is $${due.toFixed(2)} (${dogs === 1 ? \"1 dog\" : `${dogs} dogs`} at $${DEPOSIT}) and no card payment is on file around it at all. ${OTHER_ROUTES}` };\n}\n\n/** ONE PAYMENT, ONE STAY.\n *\n * statusFor answers about a single stay and is handed the customer's whole payment list, so a\n * regular who books Thanksgiving AND Christmas in the same phone call and pays one $50 deposit\n * had BOTH stays marked settled. Kim was owed $100, $50 arrived, and neither row reached the\n * shortlist. That is the exact failure the module says it exists to prevent, and it is the\n * ordinary case rather than an edge — the two windows are six weeks apart and the search window\n * around each booking overlaps almost completely.\n *\n * So the payments are ALLOCATED. Each exact-deposit payment settles at most one stay, earliest\n * drop-off first, and a payment already spent on one stay is invisible to the next. */\nexport function statusesForCustomer(stays: Stay[], payments: Payment[] | null): StayStatus[] {\n // TIE-BROKEN, not just sorted. [was: `a.day.localeCompare(b.day)` alone. JavaScript's sort is\n // stable, so two stays on the SAME DAY stayed in whatever order the caller passed them, and the\n // one that happened to be first took the money. Same customer, same payments, same day, two\n // bookings: which one reads \"Payment on file\" was decided by array order. Found by shuffling\n // the input 464,000 times. The tie-break is the booking date first — the stay she booked\n // earlier is the one an earlier payment belongs to — then fields that identify the stay, so\n // the answer is the same on every run.]\n const key = (s: Stay) => `${s.day}|${s.bookedAt ?? \"\"}|${s.until ?? \"\"}|${dogsOn(s)}|${(s.dogs ?? []).join(\",\")}`;\n const ordered = [...stays].sort((a, b) => a.day.localeCompare(b.day) || key(a).localeCompare(key(b)));\n if (payments === null) return ordered.map((s) => statusFor(s, null));\n // COLLAPSED ONCE, HERE, BEFORE ANYTHING IS ALLOCATED.\n // [was: statusFor collapsed internally and the allocator marked only the SURVIVING id as spent,\n // so the folded twin was still visible to the next stay. The same two records were read as one\n // payment when judging a stay and as two when allocating across them, and one $50 deposit that\n // Square had written twice — the exact direct+matched pair live on her account — cleared TWO\n // holiday stays, quoting two different dates so it read as two deposits.]\n const money = collapseSameMoney(payments).kept;\n const spent = new Set();\n return ordered.map((s) => {\n const available = money.filter((p) => !spent.has(p.id));\n // `all` IS THE RAW LIST, not the globally collapsed one. [was: `all: money`, and the docstring\n // for `all` says \"everything on the account, which is what Kim can see in Square\" — which the\n // collapsed list is not. A till record folded against a payment OUTSIDE this stay's window\n // vanished from the display, and the row printed the banned sentence: a customer who paid BOTH\n // deposits, fourteen days apart, had her Thanksgiving row read \"no card payment is on file\n // around it at all\". Adding a later payment turned a settled stay into \"nothing at all\".\n // statusFor collapses `all` itself, scoped to this stay's own window, which is the only scope\n // where \"same money\" is a reading rather than a guess.]\n const st = statusFor(s, available, { all: payments, alreadyCounted: new Set(spent) });\n if (st.state === \"seen\") {\n // EARLIEST DROP-OFF FIRST, and the earliest qualifying payment settles it. Both halves are\n // deliberate and both are pinned by H48: without an order, which stay gets the money is\n // whichever way the array happened to arrive.\n // COMPUTED EXACTLY AS statusFor COMPUTES THE ONE IT QUOTES, so the record Kim reads on the\n // row is the record that gets debited. Since collapseSameMoney is idempotent this second\n // pass is a no-op on already-collapsed money, and there is deliberately no control for it:\n // a control that cannot fail is worse than none. H57 is what guards the idempotency this\n // relies on. [was: paymentsNearStay without the collapse, which diverged from the quote.]\n // EVERY payment that settled it, not one of them. [was: `.find(p => p.amount === DEPOSIT)`,\n // which debited nothing at all when a multi-dog stay was settled by one lump sum, and one of\n // N when it was settled per dog. Same money, two stays, both green.]\n for (const p of qualifyingPayments(s, available)) spent.add(p.id);\n }\n return st;\n });\n}\n\n/** The kill switch. If the payment feed itself looks dead, say so instead of telling Kim that\n * every single customer owes her money.\n *\n * MIN_SAMPLE exists because of what happened on the first live run, 6 Aug 15:41Z. Two holiday\n * stays were booked, neither customer had a Square note, and the switch fired: Kim would have\n * been shown \"the payment feed has stopped\" on the strength of two people. Two customers with no\n * Square payment is an ordinary Tuesday, not evidence of an outage. Below the floor the list is\n * shown with its usual caveats, which is the honest reading of a small sample.\n *\n * IT COUNTS CUSTOMERS, NOT BOOKINGS. [was: one entry per stay, so a single regular with five\n * holiday drop-offs and a habit of paying cash cleared the floor on their own and suppressed the\n * whole card. Her real data has one contact with 24 drop-offs. The docstring said \"customers\"\n * and the code counted rows.] */\nexport const MIN_SAMPLE_FOR_DEAD_FEED = 5;\nexport function feedLooksDead(perCustomer: Map | Payment[][], minSample = MIN_SAMPLE_FOR_DEAD_FEED): boolean {\n const lists = perCustomer instanceof Map ? [...perCustomer.values()] : perCustomer;\n return lists.length >= minSample && lists.every((p) => p.length === 0);\n}\n\n/** The sentence Kim reads. Generated from the counts, so the words cannot disagree with them. */\n// Takes anything carrying a `state`, not a full StayStatus: the dashboard regenerates this line\n// from the rows it is about to render, so the two cannot disagree, and a DepositRow is not a Stay.\nexport function depositSentence(statuses: readonly { state: StayStatus[\"state\"] }[], feedDead: boolean): string {\n if (statuses.length === 0) {\n return \"No holiday boarding stays are booked in the deposit windows yet, so there is nothing to check.\";\n }\n const none = statuses.filter((s) => s.state === \"none_seen\").length;\n const partial = statuses.filter((s) => s.state === \"partial\").length;\n const seen = statuses.filter((s) => s.state === \"seen\").length;\n const unknown = statuses.filter((s) => s.state === \"could_not_check\").length;\n if (feedDead) {\n // The old wording claimed \"no Square payment has been recorded against ANYBODY\", which was a\n // claim about people the run had never managed to read. It now says how many it actually read.\n const checked = statuses.length - unknown;\n if (checked <= 0) {\n return `There ${statuses.length === 1 ? \"is 1 holiday stay\" : `are ${statuses.length} holiday stays`} booked, and ${statuses.length === 1 ? \"it could not be checked\" : \"none of them could be checked\"} just now, so there is nothing to report either way yet.`;\n }\n return `There ${statuses.length === 1 ? \"is 1 holiday stay\" : `are ${statuses.length} holiday stays`} booked, and no card payment shows against ${checked === statuses.length ? (statuses.length === 1 ? \"it\" : \"any of them\") : (checked === 1 ? \"the one we could check\" : `any of the ${checked} we could check`)}. That pattern usually means the payment feed has stopped rather than that nobody has paid, so the list is being held back until that is checked.`;\n }\n const bits: string[] = [];\n bits.push(`${statuses.length} holiday ${statuses.length === 1 ? \"stay is\" : \"stays are\"} booked.`);\n if (seen) bits.push(`${seen} ${seen === 1 ? \"has a card payment\" : \"have a card payment\"} on file.`);\n if (none || partial) {\n const n = none + partial;\n // NO FIXED FIGURE HERE. The deposit is $50 per dog, so the amount due differs per row: the\n // headline said \"we cannot find a $50 payment\" above a three-dog stay that owes $150. Each\n // row states its own amount; the headline states none.\n // \"the deposit for it\", not \"what is owed on it\". [was: \"owed\", which is the vocabulary of a\n // debt list. The card's own closing sentence exists to say this is not one, and every other\n // string on it was already careful about this. Plainer, and it names the actual figure's name.]\n bits.push(`${n} ${n === 1 ? \"is worth checking\" : \"are worth checking\"}: we cannot find a card payment matching the deposit for ${n === 1 ? \"it\" : \"them\"}.`);\n }\n if (unknown) bits.push(`${unknown} could not be checked just now.`);\n bits.push(`${OTHER_ROUTES} This is a shortlist to look at rather than a list of people who owe you.`);\n return bits.join(\" \");\n}\n\n\n=====FILE engine/kim-stories.ts =====\n// KIM'S STORIES — the one file that makes the taper personal. v1.8, 4 Aug 2026.\n//\n// THE RULE THIS FILE EXISTS TO ENFORCE: no invented stories, ever. No fictional dogs, no\n// composite customers, no \"a client once told me\". Every `story` below starts as null and stays\n// null until KIM'S OWN WORDS go in. The copy is written to read complete without them — an\n// empty slot renders as nothing, not as a hole.\n//\n// HOW TO FILL ONE IN (the whole procedure, ~5 minutes):\n// 1. Kim answers a question from the Story Capture Sheet (handover/Story-Capture-Sheet.pdf).\n// 2. Paste her answer, lightly tidied but in her words, as the `story` string below.\n// Keep it to 2-4 sentences. First person. No customer surnames without her okay.\n// 3. PUT this one file to the val (same deploy command as always). Nothing else changes.\n// 4. The next send that hits that slot carries her story. Practice mode renders it too,\n// so it can be checked on the panel/journal before anyone real sees it.\n//\n// Slots are ADDITIVE paragraphs: the template holds {{STORY:id}} on its own line; the renderer\n// swaps in the story, or removes the line entirely when null. Both paths are tested.\n\nexport type StorySlot = {\n id: string;\n // The question that gets a usable answer from Kim in 30 seconds — printed on the capture sheet.\n prompt: string;\n // Where it lands, so a human editing this file knows the context without opening the copy file.\n lands: string;\n // Kim's words, or null. Null = the message sends without it and reads complete.\n story: string | null;\n};\n\nexport const STORY_SLOTS: StorySlot[] = [\n {\n id: \"teenage\",\n prompt: \"Name one dog who turned into a teenage terror around 8 months and came good. What did the owner stick with?\",\n lands: \"Slow track week 1 — the adolescence email\",\n story: null,\n },\n {\n id: \"alone_time\",\n prompt: \"Tell me about one dog who couldn't be left alone at first. What actually fixed it?\",\n lands: \"Slow track day 63 — the alone-time email\",\n story: null,\n },\n {\n id: \"vet_visits\",\n prompt: \"Which dog do you know who walks into the vet happy? What did their owner do differently?\",\n lands: \"Slow track day 70 — the vet visits email\",\n story: null,\n },\n {\n id: \"settle\",\n prompt: \"One dog you can picture lying calmly somewhere busy (a patio, a game, a store). How did they get there?\",\n lands: \"Slow track day 119 — the off-switch email\",\n story: null,\n },\n {\n id: \"dog_parks\",\n prompt: \"One thing you've seen go wrong at a dog park that the owner never noticed. What should they have seen?\",\n lands: \"Slow track day 147 — the dog parks email\",\n story: null,\n },\n {\n id: \"nose_work\",\n prompt: \"Name a dog who was 'bad' until they got a job to do. What was the job?\",\n lands: \"Slow track day 175 — the boredom email\",\n story: null,\n },\n {\n id: \"leash_meetings\",\n prompt: \"Which pair of dogs hated each other on leash but got along fine off it, or walking side by side?\",\n lands: \"Slow track day 203 — the leash meetings email\",\n story: null,\n },\n {\n id: \"holidays\",\n prompt: \"What's one thing that happens at the kennel every Thanksgiving or Christmas that owners would never guess?\",\n lands: \"Monthly November — the holiday guests email\",\n story: null,\n },\n];\n\nconst byId = new Map(STORY_SLOTS.map((s) => [s.id, s]));\n\n// Anything SHAPED like a slot token but not a slot we know: an empty id `{{STORY:}}`, a spaced id\n// `{{STORY: a b }}`, the residue a nested token leaves behind after its inner half resolves. None of\n// these is a slot, so none of them is content. They get removed, never shipped.\n// [was: a single pass matching only /\\{\\{STORY:[a-z_]+\\}\\}/, which left `{{STORY:}}` standing\n// after resolving the inner token of `{{STORY:{{STORY:x}}}}`. Caught by tests/stories.test.mjs S5.]\nconst TOKEN_SHAPE = /\\{\\{STORY:[^{}]*\\}\\}/g;\n// Last line of defence: even a half-token fragment must not reach a customer.\nconst TOKEN_FRAGMENT = /\\{\\{STORY:[^}]*\\}{0,2}/g;\n\n// story text, or null. Trims whitespace so a pasted answer can't break the layout.\nexport function storyFor(id: string): string | null {\n const s = byId.get(id)?.story;\n if (!s) return null;\n // A pasted answer can't smuggle a slot token back in (single-pass resolve would ship it raw).\n const t = s.replace(TOKEN_FRAGMENT, \"\").trim();\n return t.length ? t : null;\n}\n\n// Resolve every {{STORY:id}} token in a rendered body. Unknown ids resolve to nothing rather\n// than leaking a token to a customer — and the tests assert every id used in copy exists here.\n//\n// Resolution LOOPS rather than running once. One pass is not enough: a malformed nest only reveals\n// its outer token after the inner one is gone, and a filled story sitting next to a token can shift\n// what the next match sees. The loop is bounded (a pass that changes nothing stops it), so a\n// pathological input costs a few passes rather than hanging.\nexport function resolveStories(text: string): string {\n let out = String(text ?? \"\");\n for (let pass = 0; pass < 8 && out.includes(\"{{STORY:\"); pass++) {\n const before = out;\n out = out.replace(/\\{\\{STORY:([a-z_]+)\\}\\}/g, (_, id) => storyFor(id) ?? \"\");\n out = out.replace(TOKEN_SHAPE, \"\");\n if (out === before) break;\n }\n // Whatever survived the loop is not a slot and is not content.\n out = out.replace(TOKEN_FRAGMENT, \"\");\n return out.replace(/\\n{3,}/g, \"\\n\\n\").trim();\n}\n\n\n=====FILE engine/money-match.ts =====\n// THE MONEY MATCHER. v1.0, 9 Aug 2026.\n//\n// WHAT THIS IS FOR. Kim's question, in her words: \"what are we doing with the money information that\n// comes from square back into the CRM?\" The answer today is: it lands as a note on the customer's\n// file, and nothing ever writes the amount onto the booking. The booking is the only place a report\n// can add money up from, so revenue and ROAS read zero while the money plainly exists.\n//\n// HER RULE, agreed in writing on 9 August at 10:26 PM, verbatim:\n// \"One open opportunity -> automatically assign the payment.\n// Multiple open opportunities -> staff chooses the correct one.\"\n// That is exactly what classify() implements. One card, AUTO. More than one, CHOOSE. None, ORPHAN.\n//\n// WHY THIS SHIPS AS A DRY RUN FIRST, and it is not timidity. Kristian's application also writes\n// opportunities into this same CRM; he confirmed it in writing on 7 August. Until he says whether it\n// writes monetaryValue, two systems would own one field and one would win at random. So this module\n// computes every write it WOULD make, proves the arithmetic, and writes nothing. Flipping it live is\n// one flag, after one sentence from him.\n//\n// NOTHING HERE MUTATES. There is no POST, PUT or PATCH in this file, and a test asserts that.\n\nexport type Payment = {\n id: string;\n amount: number;\n status: string;\n contactId: string | null;\n contactName: string | null;\n at: string | null;\n};\nexport type Opp = {\n id: string;\n contactId: string | null;\n name: string | null;\n monetaryValue: number;\n stage: string;\n createdAt: string | null;\n lastStageChangeAt: string | null;\n};\n\nexport type Verdict = \"AUTO\" | \"CHOOSE\" | \"ORPHAN\" | \"ALREADY_VALUED\";\nexport type Match = {\n payment: Payment;\n verdict: Verdict;\n candidates: Opp[];\n wouldWrite: { oppId: string; value: number } | null;\n why: string;\n};\n\n// A payment only counts as money if it actually completed. Pending and failed are shown to Kim\n// separately and never counted as revenue, because a report that counts a failed card as income is\n// worse than no report.\nexport const COMPLETED = \"succeeded\";\n\n// The point of sale bucket. Square sends counter sales with no customer, and this CRM files them all\n// against one nameless record, so a contactId here does NOT mean a real person was identified.\nexport const isNameless = (p: Payment) =>\n !p.contactName || p.contactName.trim().toLowerCase() === \"unknown\";\n\n// THE ONLY TWO STAGES A PAYMENT MAY EVER BE WRITTEN TO. [Added 10 Aug 2026.]\n// A contact appears on up to eight boards in this location and every empty card looks identical\n// from inside classify(). Proven live: unscoped, $4,020 of $4,685 lands on a card that is not a\n// booking, including $500 onto a Survey Requested card belonging to a customer whose real booking\n// already carries $2,395 and would correctly have been left alone. The exception list also goes\n// from 0 to 10, breaking the promise on Kim's page that nobody has to do anything.\n// Filter HERE, not in the caller: a caller that hands over every board is the normal mistake.\nexport const VALUABLE_STAGES: readonly string[] = Object.freeze([\n \"fd821b4e-bbe6-44de-b754-fa80e4823616\", // 1) Initial Lead Pipeline / Customer\n \"ae173310-f8b1-4399-acb7-ef1fc03d3697\", // 1) Initial Lead Pipeline / Won - Paid\n]);\nconst IN_SCOPE = new Set(VALUABLE_STAGES);\n\nexport function classify(payment: Payment, oppsForContact: Opp[]): Match {\n const inScope = oppsForContact.filter((o) => IN_SCOPE.has(o.stage));\n const open = inScope.filter((o) => o.monetaryValue === 0);\n const valued = inScope.filter((o) => o.monetaryValue > 0);\n\n if (isNameless(payment) || !payment.contactId) {\n return { payment, verdict: \"ORPHAN\", candidates: [], wouldWrite: null,\n why: \"no named customer on the payment, so nothing can be matched to it by any system\" };\n }\n if (inScope.length === 0) {\n return { payment, verdict: \"ORPHAN\", candidates: [], wouldWrite: null,\n why: \"the customer is named but has no booking on the Customer or Won and Paid board to put the money on\" };\n }\n if (open.length === 0 && valued.length > 0) {\n return { payment, verdict: \"ALREADY_VALUED\", candidates: valued, wouldWrite: null,\n why: \"every booking for this customer already carries a value; nothing would be overwritten\" };\n }\n if (open.length === 1) {\n return { payment, verdict: \"AUTO\", candidates: open,\n wouldWrite: { oppId: open[0].id, value: payment.amount },\n why: \"one booking open, so the money goes on it, which is the rule Kim gave\" };\n }\n return { payment, verdict: \"CHOOSE\", candidates: open, wouldWrite: null,\n why: `${open.length} bookings open for this customer, so a person picks; guessing here would invent revenue` };\n}\n\nexport type Write = { oppId: string; value: number; paymentIds: string[] };\n\n// ONE WRITE PER BOOKING, CARRYING THE SUM. [Added 10 Aug 2026.]\n// classify() is per payment because Kim's rule is per payment. The grouping belongs here, in the\n// caller's layer. Without it, a customer who pays twice toward one booking produces two writes to\n// one field and the loser's money vanishes silently. Proven live: Laurie Rubnitz, $120.00 and\n// $90.00, both resolving to opportunity 7yES6q2kajVTQIK6tEx3. Correct value $210.00.\n// The bug self seals: once a wrong value is written the next run sees a non zero field and returns\n// ALREADY_VALUED, so the lost money is unrecoverable without a manual audit.\n// Summing PRESERVES the total, so the $174,115.00 on Kim's page is the correct figure and it is the\n// code that has to catch up with the page.\nexport function planWrites(matches: Match[]): Write[] {\n const byOpp = new Map();\n for (const m of matches) {\n if (m.verdict !== \"AUTO\" || !m.wouldWrite) continue;\n const g = byOpp.get(m.wouldWrite.oppId) ?? { oppId: m.wouldWrite.oppId, amounts: [], paymentIds: [] };\n g.amounts.push(m.wouldWrite.value);\n g.paymentIds.push(m.payment.id);\n byOpp.set(g.oppId, g);\n }\n return [...byOpp.values()].map((g) => ({ oppId: g.oppId, value: sum(g.amounts), paymentIds: g.paymentIds }));\n}\n\nexport type Summary = {\n completed: { count: number; total: number };\n pending: { count: number; total: number };\n failed: { count: number; total: number };\n auto: { count: number; total: number };\n choose: { count: number; total: number };\n orphan: { count: number; total: number };\n alreadyValued: { count: number; total: number };\n coveragePct: number; // of completed money, what this would place on a booking\n valuedNow: { count: number; total: number }; // what the CRM carries today\n valuedAfter: { count: number; total: number }; // what it would carry if the AUTO set were written\n writes: { count: number; total: number }; // ACTUAL write count: one per booking, not per payment\n};\n\nconst sum = (xs: number[]) => Math.round(xs.reduce((a, b) => a + b, 0) * 100) / 100;\n\nexport function summarise(matches: Match[], all: Payment[], valuedToday: Opp[]): Summary {\n const byStatus = (s: string) => all.filter((p) => p.status === s);\n const of = (v: Verdict) => matches.filter((m) => m.verdict === v);\n const amt = (ps: { amount: number }[]) => sum(ps.map((p) => p.amount));\n const pot = (ms: Match[]) => sum(ms.map((m) => m.payment.amount));\n\n const completed = byStatus(COMPLETED);\n const auto = of(\"AUTO\"), choose = of(\"CHOOSE\"), orphan = of(\"ORPHAN\"), av = of(\"ALREADY_VALUED\");\n const writes = planWrites(matches);\n const completedTotal = amt(completed);\n const nowTotal = sum(valuedToday.map((o) => o.monetaryValue));\n\n return {\n completed: { count: completed.length, total: completedTotal },\n pending: { count: byStatus(\"pending\").length, total: amt(byStatus(\"pending\")) },\n failed: { count: byStatus(\"failed\").length, total: amt(byStatus(\"failed\")) },\n auto: { count: auto.length, total: pot(auto) },\n choose: { count: choose.length, total: pot(choose) },\n orphan: { count: orphan.length, total: pot(orphan) },\n alreadyValued: { count: av.length, total: pot(av) },\n // Honesty on the face of it: coverage is what WOULD be placed automatically, out of money that\n // actually completed. Kim is told this number before she ever sees a revenue figure, so a low\n // first month is never a surprise.\n coveragePct: completedTotal > 0 ? Math.round((pot(auto) / completedTotal) * 1000) / 10 : 0,\n valuedNow: { count: valuedToday.length, total: nowTotal },\n // counts BOOKINGS that gain a value, which is the number of writes, not the number of payments\n valuedAfter: { count: valuedToday.length + writes.length, total: sum([nowTotal, pot(auto)]) },\n writes: { count: writes.length, total: sum(writes.map((w) => w.value)) },\n };\n}\n\n// The sentence Kim reads. Generated, never typed, so it cannot drift from the numbers beside it.\nexport function plainEnglish(s: Summary): string {\n const m = (n: number) => \"$\" + n.toLocaleString(\"en-US\", { minimumFractionDigits: 2, maximumFractionDigits: 2 });\n if (s.completed.count === 0) return \"No completed Square payments were found, so there is nothing to place yet.\";\n const parts = [\n `${s.completed.count} Square payments completed, worth ${m(s.completed.total)}.`,\n s.auto.count\n ? `${s.auto.count} of them, worth ${m(s.auto.total)}, belong to a customer with exactly one booking open, so those place themselves.`\n : `None of them belong to a customer with exactly one booking open, so none place themselves yet.`,\n ];\n if (s.choose.count) parts.push(`${s.choose.count}, worth ${m(s.choose.total)}, belong to someone with more than one booking open, so a person picks which one.`);\n if (s.orphan.count) parts.push(`${s.orphan.count}, worth ${m(s.orphan.total)}, arrived with no named customer at all and can never be placed by anything.`);\n if (s.auto.count > s.writes.count) parts.push(`${s.auto.count} payments fill ${s.writes.count} bookings, because some customers paid more than once toward the same booking and those amounts are added together rather than one written over the other.`);\n parts.push(`That would take the money recorded against bookings from ${m(s.valuedNow.total)} to ${m(s.valuedAfter.total)}.`);\n return parts.join(\" \");\n}\n\n",[538],"9283cb69-3428-4fa3-bc93-f8993c9fb47c","SOURCE-BUNDLE.part5.txt","11feec3e-919f-11f1-8a41-1607ee4eb77e",1091,["D",1786801896590],43,"THE DOGS SPOT — SOURCE BUNDLE (part 5 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (4 of 116 files)\n engine/facts.ts 16179 bytes 75b784443645\n engine/gads-feed.ts 14745 bytes 18afceaec498\n engine/gads-rows.ts 9321 bytes d675ff4529dc\n engine/gads.ts 10135 bytes f4a1154d25cc\n\n================================================================================================\n=====FILE engine/facts.ts =====\n// ONE SOURCE OF TRUTH PER FACT. v1.0, 4 Aug 2026.\n//\n// THE ROOT CAUSE THIS FILE EXISTS TO KILL:\n// Prose and data were produced separately. Somebody wrote a sentence, something else computed a\n// number, and nothing forced them to agree. Every wrong claim in this project came from that gap:\n// - \"runs every 15 minutes\" beside a timestamp reading 26 minutes ago\n// - \"1,513 records\" that had drifted to 1,514 before a reader saw it\n// - \"35 counter sales totaling $23,463.99\" when the journal holds 40 totalling $28,035.99\n// - \"11 live questions\" in a handover doc while the page rendered 13\n// None of those were typos. Each was a sentence that had no mechanical link to its own subject.\n//\n// THE RULE: a fact is computed once, here, together with the sentence that describes it. Anything\n// that displays it reads from here. If two files can produce the same number independently, one of\n// them is wrong and nobody knows which.\n//\n// EVERY FACT CARRIES ITS PROVENANCE: where it was read and when. `Fact.source` answers \"where did\n// this number come from\" in one hop, which is the test for whether it ships.\n\nexport type Fact = {\n value: T | null; // null means NOT KNOWN, never zero-by-accident\n source: string; // the endpoint or blob it came from, in one hop\n readAt: string; // ISO timestamp of the read that produced it\n note?: string; // anything the reader must know to use it honestly\n};\n\n// Written as function DECLARATIONS rather than generic arrows on purpose.\n// [was: `export const fact = (value: T | null, ...)`. Inside the val that compiles fine, and\n// the dashboard has always rendered correct numbers from it. But esm.town, which is how any\n// OTHER val would import this file, parses a .ts file as .tsx: it read `` as an opening JSX\n// tag and served `export const fact = _jsxs(T, { children: [\"(value: T | null, source...\"] })`\n// — the type signature turned into React children. Anything importing it got garbage that would\n// have thrown at call time, not at import time. The watchdog needs to import this file so that\n// the Square backlog is computed in exactly one place; `function fact(` is unambiguous to\n// both parsers, so it can.]\nexport function fact(value: T | null, source: string, note?: string): Fact {\n return { value, source, readAt: new Date().toISOString(), note };\n}\n\n/** A fact that could not be read. Distinct from a fact whose value is genuinely zero. */\nexport function unknownFact(source: string, note?: string): Fact {\n return { value: null, source, readAt: new Date().toISOString(), note };\n}\n\n// ---------------------------------------------------------------------------------------------\n// THE SQUARE BACKLOG. Previously four numbers typed into a sentence: \"35 counter sales totaling\n// $23,463.99. 14 of the 35 carry enough of a trail; the other 21 arrived with no name.\"\n// An independent re-derivation found 40 / $28,035.99 / 10 / 30. The typed version understated the\n// unlinked money by $4,572 and understated the unresolvable count by 9. It is computed now.\n//\n// The subtlety that makes this worth a function rather than a one-liner: the bridge RE-LOGS the\n// same payment on every retry, so 87 journal rows collapse to 40 distinct payments. Summing rows\n// instead of payments gives $56,369.97, which is double-counting, not a bigger truth.\n// ---------------------------------------------------------------------------------------------\n\nexport type SquareBacklog = {\n payments: number; // distinct payment ids that never matched a contact\n total: number; // their summed value, counting each payment once\n withTrail: number; // carry an email, phone or Square customer id: recoverable with effort\n withTrailTotal: number;\n noTrail: number; // arrived with nothing at all: no permission will ever resolve these\n noTrailTotal: number;\n};\n\n// FIXED 9 Aug 2026. The loop below used to start `if (r.kind !== \"NO-MATCH\") continue`, which\n// meant the comment about reading \"ANY row for this payment\" was a lie: only NO-MATCH rows were\n// ever seen. A payment that failed to match on the first attempt and matched on a later one was\n// still counted as unmatched forever. That overstated the backlog Kim was shown by $10,884.00\n// across 9 payments: 42 payments / $33,535.99 reported, 33 / $22,651.99 true. She has the wrong\n// figure in writing, so this is a correction owed, not just a cleanup.\n// A payment is only unmatched if NO row anywhere in the journal ties it to a contact.\n//\n// FIXED AGAIN 12 Aug 2026, and this one is the reason paymentId() exists as its own function.\n// The guard above is correct and it never fired, because it was guarding the wrong GROUP. The\n// bridge writes two note shapes for one payment:\n// \"payment \" the NO-MATCH row\n// \"backfilled from square payment ; client opp untouched\" the row that RESOLVED it\n// `\\S+` is greedy about punctuation, so the second one keyed on \";\" and the first on \"\".\n// One payment became two, the failing half looked permanently unmatched, and the resolving half\n// sat under a key nothing read. Measured live: 29 payments worth $20,682.00 reported as never\n// having reached a customer when the journal names the contact each was backfilled to, on the\n// same row, at the same second. 33 / $22,651.99 reported, 4 / $1,969.99 true. Kim has the wrong\n// figure in writing for the THIRD time on this one number, so this is a correction owed.\n// THE RULE THIS ENCODES: a guard is only as good as the key that groups the rows it guards.\n// Also read the `id` FIELD: PAY-DUP rows carry the payment id there and have no note at all.\nconst MATCHED_KINDS = new Set([\"REVENUE-ON-CLIENT-OPP\", \"PAYMENT\", \"CAPI-PURCHASE\", \"INVOICE-LINKED\"]);\nexport function paymentIds(row: unknown): string[] {\n const r = row as any;\n const clean = (s: unknown) => String(s ?? \"\").replace(/[;,.]+$/, \"\");\n const out = new Set();\n if (typeof r?.id === \"string\" && r.id) out.add(clean(r.id));\n const m = /payment\\s+(\\S+)/.exec(String(r?.note ?? \"\"));\n if (m) out.add(clean(m[1]));\n out.delete(\"\");\n return [...out];\n}\nexport function squareBacklog(journal: unknown): SquareBacklog | null {\n if (!Array.isArray(journal)) return null;\n const rowsFor = new Map();\n for (const r of journal as any[]) {\n for (const id of paymentIds(r)) {\n (rowsFor.get(id) ?? rowsFor.set(id, []).get(id)!).push(r);\n }\n }\n const byPayment = new Map();\n for (const [id, rs] of rowsFor) {\n if (!rs.some((r) => r?.kind === \"NO-MATCH\")) continue; // never failed: not a backlog item\n if (rs.some((r) => MATCHED_KINDS.has(r?.kind) || (typeof r?.contactId === \"string\" && r.contactId.length > 4))) continue; // matched later\n const amt = rs.map((r) => Number(r?.amount) || 0).find((a) => a > 0) ?? 0;\n const trail = rs.some((r) => r?.hadEmail === true || r?.hadPhone === true || r?.hadCustomerId === true);\n byPayment.set(id, { amt, trail });\n }\n const rows = [...byPayment.values()];\n const sum = (f: (x: { amt: number; trail: boolean }) => boolean) =>\n rows.filter(f).reduce((a, x) => a + x.amt, 0);\n return {\n payments: rows.length,\n total: rows.reduce((a, x) => a + x.amt, 0),\n withTrail: rows.filter((x) => x.trail).length,\n withTrailTotal: sum((x) => x.trail),\n noTrail: rows.filter((x) => !x.trail).length,\n noTrailTotal: sum((x) => !x.trail),\n };\n}\n\n// ---------------------------------------------------------------------------------------------\n// SENTENCES ARE GENERATED FROM VALUES, NEVER COMPOSED ALONGSIDE THEM.\n// Each of these takes the fact and returns the words. There is no path by which the words can\n// describe a different number from the one passed in, because there is only one number.\n// ---------------------------------------------------------------------------------------------\n\nconst money = (n: number) => `$${n.toLocaleString(\"en-US\", { minimumFractionDigits: 2, maximumFractionDigits: 2 })}`;\n\nexport function squareSentence(b: SquareBacklog | null): string {\n if (!b || b.payments === 0) {\n return \"We could not read the payment records just now, so there is nothing to report here rather than a zero to trust.\";\n }\n // WHY THIS NO LONGER SPLITS THE COUNT INTO TRACEABLE AND HOPELESS, 12 Aug 2026.\n // It used to end \"arrived with no name, email or phone attached at all, and nothing will ever\n // resolve those\". That sentence was false. hadEmail/hadPhone/hadCustomerId describe the WEBHOOK\n // PAYLOAD the bridge received, not what Square holds. Checked live against Square: the payment\n // this sentence called hopeless is Caroline Riner, and Square has her name and her phone number.\n // The flags got it exactly backwards for two of the four. A page may not tell an owner a sale is\n // unrecoverable on the strength of a field that was never asking that question.\n // THE RULE: never let a sentence make a claim stronger than the field behind it can carry.\n const parts = [\n `${b.payments} counter sales totaling ${money(b.total)} are recorded but not linked to a name.`,\n \"The exception list names each one with whatever the card reader captured, so they can be placed by hand.\",\n \"This is old filing rather than missing money. Every dollar was collected.\",\n ];\n return parts.join(\" \");\n}\n\n// ---------------------------------------------------------------------------------------------\n// THE PHONE-CALL OMISSION. Two facts sat on the page and were never joined: a channel bucket\n// labelled \"somewhere else\" holding 20 people, and a separate line saying the old source column\n// logged 22 phone calls. An independent cross-tab showed the \"other\" bucket is 20 of 20 phone\n// calls, 100%. The page had the answer twice and printed it as a shrug. Computed now.\n// ---------------------------------------------------------------------------------------------\n\nexport type ContactLike = {\n source?: string | null;\n attribution?: { medium?: string | null } | null;\n dateAdded?: string;\n};\nexport type Win = { startMs: number; endMs: number };\n\n/**\n * What share of the un-named \"other\" medium bucket is explained by phone calls?\n *\n * THE WINDOW IS MANDATORY, and this is not defensive typing. The first version of this function\n * took no window, so it counted every contact ever fetched (nine weeks) and rendered \"all 192 of\n * them are logged as phone calls\" directly beneath a bar that read 20. Same disease, in the code\n * written to cure it: a sentence describing a different population from the chart above it.\n * A caller that cannot supply the window gets null rather than a number from the wrong period.\n */\nexport function otherBucketExplanation(contacts: ContactLike[] | null, w: Win | null): { other: number; phoneInOther: number } | null {\n if (!Array.isArray(contacts) || !contacts.length || !w) return null;\n const inWin = (c: ContactLike) => {\n const t = Date.parse(c.dateAdded ?? \"\");\n return Number.isFinite(t) && t >= w.startMs && t < w.endMs;\n };\n const scoped = contacts.filter(inWin);\n if (!scoped.length) return null;\n const isOther = (c: ContactLike) => /^other$/i.test(String(c.attribution?.medium ?? \"\").trim());\n const isPhone = (c: ContactLike) => /phone/i.test(String(c.source ?? \"\"));\n return {\n other: scoped.filter(isOther).length,\n phoneInOther: scoped.filter((c) => isOther(c) && isPhone(c)).length,\n };\n}\n\nexport function otherBucketSentence(x: { other: number; phoneInOther: number } | null): string {\n if (!x || x.other === 0) return \"\";\n if (x.phoneInOther === 0) {\n return `The ${x.other} filed as \"somewhere else\" carry an arrival record that just says \"other\", and none of them match a logged phone call, so we genuinely cannot place them.`;\n }\n const all = x.phoneInOther === x.other;\n return all\n ? `Worth knowing what \"somewhere else\" actually is: all ${x.other} of them are logged in your CRM as phone calls. Your arrival record has no category for a call, so people who rang you land in that bucket. They are not unknown, they are your callers.`\n : `${x.phoneInOther} of the ${x.other} filed as \"somewhere else\" are logged in your CRM as phone calls. Your arrival record has no category for a call, so callers land in that bucket rather than one of their own.`;\n}\n\n// ---------------------------------------------------------------------------------------------\n// CROSS-ARTIFACT REGISTRY. Any fact that appears in more than one place (page, PDF, ledger, a\n// message to the client) is registered here by name. The consistency test walks this list and\n// fails the build when two artefacts state the same named fact differently. Drift becomes\n// impossible rather than merely unlikely.\n// ---------------------------------------------------------------------------------------------\n\nexport type SharedFact = {\n name: string; // stable id\n pattern: RegExp; // how it appears in prose, capturing the value\n describe: string; // what it is, for the failure message\n};\n\nexport const SHARED_FACTS: SharedFact[] = [\n { name: \"decision_count\", pattern: /(\\d+)\\s+(?:live\\s+)?questions?\\s+(?:on this page\\s+)?(?:are|is)?\\s*wait/i, describe: \"how many questions are waiting on Kim\" },\n { name: \"bootcamp_bookings\", pattern: /(\\d+)\\s+Bootcamp bookings/i, describe: \"Bootcamp bookings on record\" },\n { name: \"bootcamp_ceiling\", pattern: /\\$([\\d,]+)\\s*(?:,|\\.|and|$)/i, describe: \"the Bootcamp exposure ceiling\" },\n { name: \"slow_track_len\", pattern: /(\\d+)\\s+more spread over about\\s+(\\d+)\\s+months/i, describe: \"the slow track length\" },\n { name: \"automations\", pattern: /(?:all\\s+)?(\\d+)\\s+automations/i, describe: \"automations in the account\" },\n];\n\n// ---------------------------------------------------------------------------------------------\n// THE TAG THAT DECIDES WHETHER GO-LIVE REACHES ANYBODY.\n// The engine enrolls on the tag `nurture - puppy`. If nothing applies it, switching the sequence\n// on reaches nobody, and it looks healthy while doing so: the engine reports successful runs with\n// zero enrollments, which is exactly what a working system with no work also looks like.\n//\n// [was: the page said \"1,200 of your most recent contacts were checked and not one carries the\n// tag\". True when it was typed, and a scan size rather than an answer: it left open whether the\n// other four thousand were different. GoHighLevel will filter contacts by tag server-side and\n// return a total, so the real number is one call away. Cross-checked 5 Aug against a full walk of\n// all 5,544 contacts, page by page: \"no sale\" 133, \"tips-nurture\" 155, \"customer\" 1,512, and\n// `nurture - puppy` zero. The filter and the census agree on every one.]\n// ---------------------------------------------------------------------------------------------\nexport type TagCoverage = { tag: string; tagged: number; total: number };\n\nexport function tagCoverageSentence(t: TagCoverage | null): string {\n if (!t || t.total <= 0) {\n return \"We could not read your contact records just now, so this says nothing rather than a zero worth trusting.\";\n }\n if (t.tagged === 0) {\n return `Every one of your ${t.total.toLocaleString(\"en-US\")} contact records was checked just now, and not a single one is marked as a puppy inquiry. Nothing in your account applies that mark, which is why the tagging has to be switched on at the same moment as everything else.`;\n }\n const pct = Math.round((t.tagged / t.total) * 100);\n // [was: \"1 ... are marked ... Those are the people\" — a real reader hit the n=1 case on 9 Aug\n // and the plural read as a glitch on a page that trades on precision. Number agreement is now\n // computed from the count, never assumed.]\n const one = t.tagged === 1;\n return `${t.tagged.toLocaleString(\"en-US\")} of your ${t.total.toLocaleString(\"en-US\")} contact records ${one ? \"is\" : \"are\"} marked as a puppy inquiry, checked just now, which is ${pct < 1 ? \"under 1\" : pct}% of them. ${one ? \"That is the one person\" : \"Those are the people\"} the new messages would pick up.`;\n}\n\n\n=====FILE engine/gads-feed.ts =====\n// THE SCHEDULED CONVERSION FEED. v1.0, 15 Aug 2026.\n//\n// THE CHORE THIS DELETES. Until tonight, somebody had to remember, every week, to open the val\n// endpoint, download a CSV, open Google Ads, find Goals → Conversions → Uploads, and attach the\n// file. The account has already proved what happens to weekly chores here: the last human change\n// to it was 22 Jul 19:21:36 ET, and the 24 days after that returned \"You don't have any changes\n// that match your dates or filters.\" A step that depends on memory is a step that stops.\n//\n// WHAT REPLACES IT. Google Ads' Uploads screen has a Schedules tab that will FETCH a file itself,\n// on a schedule, from one of three sources: Google Sheets, HTTPS, SFTP. Our file already exists at\n// an HTTPS URL. So the whole loop closes by pointing Google at a URL, once, by hand — and then\n// never again. This file is that URL: a stable, cached, unguessable, always-parseable CSV route.\n//\n// WHY IT IS NOT JUST gads.ts WITH A LONGER LEASH. Three differences, each of which is the\n// difference between a thing that runs unattended and a thing that looks like it does:\n//\n// 1. THE SECRET IS IN THE PATH, AND IT IS ITS OWN SECRET.\n// The URL ends in \".csv\" because Google's documented HTTPS setups go out of their way to make\n// it so — Matomo's instructions tell you to append \"&requestType=https&conversion-export.csv\"\n// to a URL that is otherwise all query string, which only makes sense as a file-type sniff on\n// the URL's tail. A path secret gives us a .csv ending for free and needs no query string at\n// all, so nothing depends on Google preserving one.\n// And it is a DIFFERENT secret from the admin key. The URL is pasted into a Google Ads screen\n// where it lives forever, visible to anyone with access to the account. The admin key opens\n// the whole admin surface; this key opens one read-only CSV and nothing else.\n//\n// 2. IT CANNOT SERVE A FILE GOOGLE WILL REJECT.\n// Google fails a scheduled run on a file with headers and no data rows: \"The data type or\n// schema of the data source could not be determined... there is at least one line with valid\n// data.\" A CRM hiccup at the moment Google happens to fetch would do exactly that. So the\n// last good file is cached, and a build that fails OR returns zero rows serves the cache\n// instead of a header-only file. Re-serving last week's rows is free: Google states \"the same\n// conversion won't be imported more than once\" for the same click id + name + time.\n//\n// 3. IT IS BOUNDED IN TIME.\n// The live scan takes ~7s. A scheduled fetcher that waits forever is a scheduled fetcher that\n// one day times out mid-run. The rebuild gets a budget; over it, the cache is served.\n//\n// THE WINDOW, AND WHY 80 DAYS AND NOT 85.\n// Google: \"Offline conversions that were uploaded more than 90 days after the associated last\n// click won't be imported.\" The clock runs from the CLICK, and we do not have the click's\n// timestamp — only the contact's dateAdded, which is at or after it. On this CRM the two are\n// minutes apart (the click lands on a page, the chat or the form makes the contact), but that is\n// an observation, not a guarantee. 80 days of contact age leaves ten days of margin, and because\n// the window moves with the calendar, a row simply stops being emitted before it can start being\n// rejected. Nothing accumulates; nothing needs cleaning up.\n//\n// WHAT THIS STILL CANNOT DO, said plainly rather than left to be discovered:\n// * It cannot create the schedule. Google Ads has no way to do that except a human in the UI,\n// and the Google Ads API route needs a developer token this account does not have.\n// * Nothing here pages anybody. If the schedule is deleted or the fetch starts failing, the\n// evidence is in ?status — it does not come and find you. Every fetch is recorded there with\n// its user-agent and time precisely so that \"is this still running?\" is a question with an\n// answer rather than a shrug.\n// * The two conversion actions it feeds are not account-default goals, so what it uploads is\n// reporting, not bidding, until somebody promotes them.\n\nimport { buildRows, ghlGetter, toCsv, FEED_DAYS, LEAD_NAME, SHOW_NAME } from \"./gads-rows.ts\";\n\n// sha256 of the feed token. The token itself is not in this tree.\nconst FEED_KEY_SHA256 = \"ed8eea7a581590e540c9ea8cbb97dd8661ecb91a38ab5a20cb082199f8976f7b\";\n// The admin key is also accepted, for the same reason it is accepted by gads.ts: it already opens\n// this exact data there, so honouring it here grants nothing new and saves carrying two secrets\n// around when a human wants to check ?status.\nconst ADMIN_KEY_SHA256 = \"48cd12465712045f70247da1689eeb198a4ce2d98416d8e52fb844581f044f15\";\n\nconst BLOB_KEY = \"gads_feed_cache\";\n/** Serve the cache without rebuilding if it is younger than this. Google fetches weekly, so in\n * practice every scheduled fetch rebuilds; this only spares a human clicking twice in a row. */\nconst MAX_AGE_MS = 6 * 3_600_000;\n/** The rebuild's budget. Past it, the cache is served and the status view says the build was slow. */\nconst BUILD_BUDGET_MS = 25_000;\n/** How many fetches to remember. Enough to see a weekly schedule's last three months. */\nconst FETCH_LOG = 14;\nconst FILENAME = \"dogsspot-google-conversions.csv\";\n\ntype FetchNote = { at: string; ua: string; served: string; rows: number; ms: number };\ntype Cache = {\n csv: string;\n rows: number;\n builtAt: string;\n days: number;\n scanned: number;\n clicked: number;\n lastBuild: { at: string; ok: boolean; rows: number; ms: number; error: string };\n fetches: FetchNote[];\n};\n\nasync function sha256Hex(s: string): Promise {\n const b = await crypto.subtle.digest(\"SHA-256\", new TextEncoder().encode(s));\n return [...new Uint8Array(b)].map((x) => x.toString(16).padStart(2, \"0\")).join(\"\");\n}\n/** Constant-time compare against both accepted hashes. Same shape as gads.ts's check. */\nasync function authorised(k: string): Promise {\n if (!k) return false;\n const got = await sha256Hex(k);\n const feed = Deno.env.get(\"NURTURE_GADS_FEED_SHA256\") || FEED_KEY_SHA256;\n const admin = Deno.env.get(\"NURTURE_ADMIN_KEY_SHA256\") || ADMIN_KEY_SHA256;\n let hit = false;\n for (const expected of [feed, admin]) {\n if (got.length !== expected.length) continue;\n let d = 0;\n for (let i = 0; i < got.length; i++) d |= got.charCodeAt(i) ^ expected.charCodeAt(i);\n if (d === 0) hit = true;\n }\n return hit;\n}\n\nasync function ghlToken(): Promise {\n const env = Deno.env.get(\"GHL_TOKEN\");\n if (env) return env;\n const { blob } = await import(\"https://esm.town/v/std/blob\");\n const cfg = (await blob.getJSON(\"puppy_config\").catch(() => null)) as { ghlToken?: string } | null;\n return cfg?.ghlToken ?? \"\";\n}\n\nasync function readCache(): Promise {\n try {\n const { blob } = await import(\"https://esm.town/v/std/blob\");\n return (await blob.getJSON(BLOB_KEY).catch(() => null)) as Cache | null;\n } catch { return null; }\n}\nasync function writeCache(c: Cache): Promise {\n try {\n const { blob } = await import(\"https://esm.town/v/std/blob\");\n await blob.setJSON(BLOB_KEY, c);\n } catch { /* a cache that will not persist must not fail the request Google is making */ }\n}\n\n/**\n * Rebuild, under a wall-clock budget.\n *\n * The losing promise is not cancelled — there is nothing to cancel a half-finished set of CRM\n * reads with — it is simply not waited for. That is deliberate: a slow build that finishes after\n * we have already answered costs nothing, and the alternative (waiting) is the failure mode.\n */\nasync function rebuild(days: number): Promise<{ ok: boolean; rows: number; csv: string; ms: number; error: string; scanned: number; clicked: number }> {\n const t0 = Date.now();\n const blank = { ok: false, rows: 0, csv: \"\", ms: 0, error: \"\", scanned: 0, clicked: 0 };\n try {\n const token = await ghlToken();\n if (!token) return { ...blank, ms: Date.now() - t0, error: \"no GHL token in env or puppy_config blob\" };\n\n const work = buildRows(ghlGetter(token), { days }).then((b) => ({\n ok: true,\n rows: b.rows.length,\n csv: toCsv(b.rows),\n ms: 0,\n error: \"\",\n scanned: b.scanned,\n clicked: b.clicked,\n }));\n const timer = new Promise((res) =>\n setTimeout(() => res({ ...blank, error: `build exceeded ${BUILD_BUDGET_MS}ms` }), BUILD_BUDGET_MS)\n );\n const r = await Promise.race([work, timer]);\n return { ...r, ms: Date.now() - t0 };\n } catch (e) {\n return { ...blank, ms: Date.now() - t0, error: String(e).slice(0, 300) };\n }\n}\n\nconst HOW = {\n once: [\n \"Google Ads → Goals → Conversions → Uploads → the Schedules tab → the blue + button\",\n \"Source: HTTPS. File URL: this URL, ending .csv. Username/password: any value — Google asks for\",\n \"them and does not validate them for HTTPS. Frequency: Weekly. Then Save & preview.\",\n ].join(\" \"),\n needs: `Both conversion actions must already exist, named EXACTLY \"${LEAD_NAME}\" and \"${SHOW_NAME}\", created as Import → CRM/file → conversions from clicks.`,\n watch: \"Add ?status=1 (or /status after the key) to this URL to see when it was last fetched and by what.\",\n};\n\nexport default async function (req: Request): Promise {\n const u = new URL(req.url);\n // The key is the FIRST path segment, with a .csv suffix stripped, or ?k= for a human at a\n // terminal. Anything after it is decoration Google is welcome to keep: /KEY/whatever.csv works,\n // which is what lets the URL end in .csv while carrying no query string at all.\n const segs = u.pathname.split(\"/\").filter(Boolean);\n const fromPath = (segs[0] ?? \"\").replace(/\\.csv$/i, \"\");\n const key = fromPath || (u.searchParams.get(\"k\") ?? \"\");\n if (!(await authorised(key))) {\n // 404 rather than 401: a scanner learns nothing, and Google only ever fetches the right URL.\n return new Response(\"Not found\", { status: 404 });\n }\n\n const wantStatus = /^status/i.test(segs[1] ?? \"\") || u.searchParams.get(\"status\") === \"1\";\n const days = Math.min(Math.max(Number(u.searchParams.get(\"days\")) || FEED_DAYS, 1), 85);\n const ua = (req.headers.get(\"user-agent\") ?? \"\").slice(0, 160);\n const t0 = Date.now();\n\n const cache = await readCache();\n const cachedRows = cache?.rows ?? 0;\n const ageMs = cache?.builtAt ? Date.now() - Date.parse(cache.builtAt) : Infinity;\n const usable = cachedRows > 0 && Number.isFinite(ageMs);\n\n // A status read never rebuilds. It is a question about the machine, not a request for the file,\n // and a status page that costs seven seconds of CRM reads is a status page nobody opens.\n if (wantStatus) {\n const last = cache?.fetches?.[0];\n return Response.json({\n ok: true,\n what: \"Google Ads scheduled offline-conversion feed for The Dogs Spot\",\n file: { rows: cachedRows, builtAt: cache?.builtAt ?? null, ageHours: usable ? +(ageMs / 3_600_000).toFixed(1) : null, days: cache?.days ?? null },\n lastBuild: cache?.lastBuild ?? null,\n lastFetch: last ?? null,\n daysSinceLastFetch: last ? +((Date.now() - Date.parse(last.at)) / 86_400_000).toFixed(2) : null,\n // A weekly schedule that has not fetched in nine days has stopped. Nothing here acts on that\n // — it is a flag for whoever looks, and the honest statement is that somebody has to look.\n scheduleLooksStalled: last ? Date.now() - Date.parse(last.at) > 9 * 86_400_000 : null,\n fetches: cache?.fetches ?? [],\n how: HOW,\n });\n }\n\n let csv = \"\", served = \"\", rows = cachedRows;\n let build: Awaited> | null = null;\n\n if (usable && ageMs < MAX_AGE_MS) {\n csv = cache!.csv;\n served = \"cache-fresh\";\n } else {\n build = await rebuild(days);\n if (build.ok && build.rows > 0) {\n csv = build.csv;\n rows = build.rows;\n served = \"rebuilt\";\n } else if (usable) {\n // Build failed, or succeeded with nothing in it. Either way the last good file is the right\n // answer: Google de-dupes what it has already seen, and a header-only file is a failed run.\n csv = cache!.csv;\n served = build.ok ? \"cache-empty-build\" : \"cache-build-failed\";\n } else {\n // Nothing good to serve and nothing cached. Fail loudly: a failed run in the Uploads tab is\n // information. A file with no rows is a schema error Google reports as something else.\n const why = build.ok ? \"the scan found no Google-clicked contacts in the window\" : build.error;\n await note(cache, { at: new Date().toISOString(), ua, served: \"503\", rows: 0, ms: Date.now() - t0 }, build, days);\n return new Response(`no rows to serve: ${why}\\n`, { status: 503, headers: { \"Content-Type\": \"text/plain; charset=utf-8\" } });\n }\n }\n\n await note(cache, { at: new Date().toISOString(), ua, served, rows, ms: Date.now() - t0 }, build, days, csv, rows);\n\n return new Response(csv, {\n headers: {\n \"Content-Type\": \"text/csv; charset=utf-8\",\n \"Content-Disposition\": `attachment; filename=\"${FILENAME}\"`,\n \"Cache-Control\": \"no-store\",\n \"X-Feed-Served\": served,\n \"X-Feed-Rows\": String(rows),\n },\n });\n}\n\n/**\n * Record the fetch, and the build if there was one, in the same blob as the file.\n *\n * WHY THE TELEMETRY IS NOT OPTIONAL. The whole point of this file is that nobody will be watching\n * it. An automation nobody watches and that cannot say when it last ran is indistinguishable from\n * one that stopped in September. Every fetch leaves its user-agent and its timestamp here, so the\n * question \"did Google actually collect this?\" has an answer that is not a guess.\n */\nasync function note(\n prev: Cache | null,\n f: FetchNote,\n build: { ok: boolean; rows: number; ms: number; error: string; scanned: number; clicked: number; csv: string } | null,\n days: number,\n csv?: string,\n rows?: number,\n): Promise {\n const base: Cache = prev ?? {\n csv: \"\", rows: 0, builtAt: \"\", days, scanned: 0, clicked: 0,\n lastBuild: { at: \"\", ok: false, rows: 0, ms: 0, error: \"\" },\n fetches: [],\n };\n const next: Cache = { ...base, fetches: [f, ...(base.fetches ?? [])].slice(0, FETCH_LOG) };\n if (build) {\n next.lastBuild = { at: f.at, ok: build.ok, rows: build.rows, ms: build.ms, error: build.error };\n // Only a build that produced rows replaces the stored file. A successful scan that found\n // nothing leaves the last good file exactly where it is.\n if (build.ok && build.rows > 0 && csv) {\n next.csv = csv;\n next.rows = rows ?? build.rows;\n next.builtAt = f.at;\n next.days = days;\n next.scanned = build.scanned;\n next.clicked = build.clicked;\n }\n }\n await writeCache(next);\n}\n\n\n=====FILE engine/gads-rows.ts =====\n// GOOGLE ADS OFFLINE CONVERSIONS — THE ROW BUILDER, EXTRACTED SO A SECOND ENDPOINT CAN SHARE IT.\n// v1.0, 15 Aug 2026.\n//\n// WHY THIS FILE EXISTS. engine/gads.ts is the hand-driven endpoint: a human hits it with the admin\n// key, gets JSON to read or a CSV to download, and uploads that file by hand. It works and it is\n// verified live, so it is not touched. What it cannot do is be POLLED: it wants the admin key in a\n// query string, it has no cache, and a bad minute at the CRM turns into an HTTP 500 that a machine\n// on a schedule would simply record as a failed run.\n//\n// engine/gads-feed.ts is the machine-facing twin. Both need the same three things — find the\n// Google-clicked contacts, join them to real outcomes, emit Google's exact column set — so those\n// three things live here rather than being typed twice and drifting.\n//\n// THE COLUMN CONTRACT IS PINNED BY A TEST. tests/gads-feed.test.mjs asserts that the header line\n// and the Parameters line in this file appear VERBATIM in engine/gads.ts. If either file's idea of\n// Google's template changes, that test goes red instead of one endpoint quietly emitting a file\n// Google will reject with \"The selected file is missing data columns\".\n//\n// EVERYTHING HERE IS READ-ONLY AGAINST THE CRM. There is no write path in this module at all.\n\n/** The two conversion actions created in Google Ads on 15 Aug 2026. The names must match EXACTLY. */\nexport const LEAD_NAME = \"CRM Lead (Google)\";\nexport const SHOW_NAME = \"CRM Booking Showed (Google)\";\n\n// Google's own live template, fetched 15 Aug 2026 from\n// https://www.gstatic.com/conversiontracking/conversion-import-template.csv\n// SEVEN columns, not the five in most third-party write-ups. The two consent columns are new and\n// omitting them fails Preview with the unhelpful \"The selected file is missing data columns\".\nexport const CSV_HEADER =\n \"Google Click ID,Conversion Name,Conversion Time,Conversion Value,Conversion Currency,Ad User Data,Ad Personalization\";\n// The Parameters row carries the same number of commas as the header, or the row-length check trips.\nexport const PARAMS_LINE = \"Parameters:TimeZone=+0000,,,,,,\";\n// GRANTED | DENIED | UNSPECIFIED. UNSPECIFIED is the honest value: consent mode is not configured\n// on this account and asserting GRANTED would be a claim about consent collection nobody verified.\nexport const CONSENT = \"UNSPECIFIED\";\n\n/** Hard cap on the lookback. Google drops any conversion uploaded more than 90 days after the\n * click; the click precedes contact creation, so the window on contact age must stay short of it. */\nexport const MAX_DAYS = 85;\n/** What the scheduled feed uses. Ten days of margin under Google's 90, because the gap between the\n * click and the contact record being created is real but unmeasured — see NOTES in gads-feed.ts. */\nexport const FEED_DAYS = 80;\n\nconst LOC = \"BQHJ19uohldYe3eqA0bl\";\nconst GHL = \"https://services.leadconnectorhq.com\";\n// Cloudflare in front of the CRM refuses non-browser clients inconsistently. Every read in this\n// project sends a Chrome UA for that reason; python urllib gets a 1010 and curl with this does not.\nconst UA =\n \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36\";\n/** 18 × 100 contacts ≫ any realistic lookback at the observed ~25 new contacts/day. */\nexport const PAGE_CAP = 18;\n\nexport type Row = {\n clickId: string;\n name: string;\n time: string;\n value: number;\n who: string;\n why: string;\n};\n\nexport type Built = {\n rows: Row[];\n scanned: number;\n pages: number;\n clicked: number;\n reachedCutoff: boolean;\n days: number;\n since: string;\n};\n\n/** How the CRM is read. Injected so the tests can drive the whole builder without a network. */\nexport type Getter = (url: string, version: string) => Promise;\n\n/** The real one. Same headers as every other read in this project. */\nexport function ghlGetter(token: string): Getter {\n return async (url: string, version: string) => {\n const r = await fetch(url, {\n headers: {\n Authorization: `Bearer ${token}`,\n Version: version,\n \"User-Agent\": UA,\n Accept: \"application/json\",\n },\n });\n if (!r.ok) throw new Error(`${r.status} ${url.slice(0, 120)}`);\n return r.json();\n };\n}\n\n/**\n * gclid / wbraid / gbraid, plain or URL-encoded, anywhere in the serialised contact.\n * The click id is not a first-class field in GHL: it hides inside attribution URLs and session\n * blobs, and it is very often URL-encoded (gclid%3D...), sometimes doubly (gclid%253D...).\n */\nexport function extractClickId(raw: string): { kind: string; id: string } | null {\n for (const kind of [\"gclid\", \"wbraid\", \"gbraid\"]) {\n const m =\n raw.match(new RegExp(`${kind}(?:%3D|=|%253D)([A-Za-z0-9_-]{20,140})`, \"i\")) ||\n raw.match(new RegExp(`\"${kind}\"\\\\s*:\\\\s*\"([A-Za-z0-9_-]{20,140})\"`, \"i\"));\n if (m) return { kind, id: m[1] };\n }\n return null;\n}\n\n/** Google's documented CSV time shape. No per-row zone: the Parameters line pins UTC for the file. */\nexport function gTime(iso: string, plusMinutes = 0): string {\n const d = new Date(new Date(iso).getTime() + plusMinutes * 60_000);\n const p = (n: number) => String(n).padStart(2, \"0\");\n return `${d.getUTCFullYear()}-${p(d.getUTCMonth() + 1)}-${p(d.getUTCDate())} ` +\n `${p(d.getUTCHours())}:${p(d.getUTCMinutes())}:${p(d.getUTCSeconds())}`;\n}\n\n/** Byte-for-byte the file engine/gads.ts serves: same quoting, same column order, same consent. */\nexport function toCsv(rows: Row[]): string {\n const esc = (s: string) => `\"${String(s).replace(/\"/g, '\"\"')}\"`;\n const lines = [\n PARAMS_LINE,\n CSV_HEADER,\n ...rows.map((r) =>\n [esc(r.clickId), esc(r.name), esc(r.time), r.value, \"USD\", CONSENT, CONSENT].join(\",\")\n ),\n ];\n return lines.join(\"\\n\") + \"\\n\";\n}\n\n/**\n * Walk contacts newest-first to the cutoff, keep the ones carrying a Google click id, and join each\n * to its real outcomes.\n *\n * TRAPS ENCODED HERE so nobody relearns them:\n * * Conversion Time must be AFTER the click. The click precedes contact creation, so a lead row\n * is dateAdded + 5 minutes and a showed row is the appointment start, later still.\n * * GET /opportunities/search with date_added_start/end returns HTTP 200 and ZERO rows silently\n * (proved 15 Aug 2026). Nothing here uses those filters: contacts are paginated by\n * meta.nextPageUrl and cut off locally against dateAdded.\n * * One \"showed\" row per contact — the FIRST attended appointment. Google de-dupes on\n * (click id, conversion name, time), so a later second stay must not become a second sale in\n * the same row; it restates the first.\n * * One unreadable contact must not sink the whole file. Appointment reads are individually\n * caught, and the count of failures is returned rather than thrown.\n */\nexport async function buildRows(\n get: Getter,\n opts: { days?: number; leadValue?: number; showValue?: number; now?: number } = {},\n): Promise {\n const days = Math.min(Math.max(Number(opts.days) || FEED_DAYS, 1), MAX_DAYS);\n const leadValue = Number(opts.leadValue) || 5;\n const showValue = Number(opts.showValue) || 150;\n const now = opts.now ?? Date.now();\n const cutoff = now - days * 86_400_000;\n\n const hits: { id: string; name: string; dateAdded: string; click: { kind: string; id: string } }[] = [];\n let url: string | null = `${GHL}/contacts/?locationId=${LOC}&limit=100`;\n let pages = 0, scanned = 0, reachedCutoff = false;\n while (url && pages < PAGE_CAP && !reachedCutoff) {\n const page = await get(url, \"2021-07-28\");\n const contacts = page?.contacts ?? [];\n for (const c of contacts) {\n scanned++;\n const added = Date.parse(c?.dateAdded ?? \"\");\n if (Number.isFinite(added) && added < cutoff) { reachedCutoff = true; break; }\n const click = extractClickId(JSON.stringify(c));\n if (click) {\n hits.push({\n id: c.id,\n name: [c.firstName, c.lastName].filter(Boolean).join(\" \") || \"(no name)\",\n dateAdded: c.dateAdded,\n click,\n });\n }\n }\n url = page?.meta?.nextPageUrl ?? null;\n pages++;\n }\n\n const rows: Row[] = [];\n for (const h of hits) {\n rows.push({\n clickId: h.click.id,\n name: LEAD_NAME,\n time: gTime(h.dateAdded, 5),\n value: leadValue,\n who: h.name,\n why: `contact created ${h.dateAdded} carrying a ${h.click.kind}`,\n });\n try {\n const appts = await get(`${GHL}/contacts/${h.id}/appointments`, \"2021-04-15\");\n const showed = (appts?.events ?? []).filter((e: any) =>\n /showed|completed/i.test(String(e?.appointmentStatus ?? \"\")) && e?.startTime\n );\n if (showed.length) {\n showed.sort((a: any, b: any) => Date.parse(a.startTime) - Date.parse(b.startTime));\n rows.push({\n clickId: h.click.id,\n name: SHOW_NAME,\n time: gTime(showed[0].startTime),\n value: showValue,\n who: h.name,\n why: `attended ${showed[0].title ?? \"appointment\"} at ${showed[0].startTime}`,\n });\n }\n } catch { /* one unreadable contact must not sink the file */ }\n }\n\n return {\n rows,\n scanned,\n pages,\n clicked: hits.length,\n reachedCutoff,\n days,\n since: new Date(cutoff).toISOString(),\n };\n}\n\n\n=====FILE engine/gads.ts =====\n// GOOGLE ADS OFFLINE CONVERSIONS — built 15 Aug 2026, after the boarding forensics run.\n//\n// WHY THIS EXISTS\n// The account's only website conversion action watches book.thedogsspotga.com/start-5784?submitted=1.\n// Live census 15 Aug: ZERO of the CRM's 5,767 lifetime contacts originated from that funnel, and both\n// boarding forms hold ZERO submissions ever. Meanwhile two Google-clicked contacts arrived in 22 days\n// (found by gclid on their contact records) and one became a boarding customer who showed and rated\n// the stay 10/10 — invisible to Google. The clicks are measured on Google's side; the OUTCOMES are in\n// the CRM. The honest join is an offline-conversion upload keyed on the gclid GHL already stores.\n// No developer token, no tag, no funnel edit required.\n//\n// WHAT IT DOES\n// Scans recent contacts for a Google click id, joins each to its real outcomes, and emits the exact\n// CSV Google Ads' \"Uploads\" screen accepts. Read-only against the CRM: it never writes anything.\n// ?k= JSON preview — what would be uploaded, with per-contact reasoning\n// ?k=&csv=1 the upload file itself (text/csv, Google's format)\n// ?k=&days=35 lookback in days (default 35; hard cap 85 — Google rejects conversions\n// more than 90 days after the click, and the click precedes the contact)\n// &leadValue=5&showValue=150 per-row values; defaults 5 and 150 USD\n//\n// Two conversion names are emitted. BOTH must exist in Google Ads first, created as\n// Goals → Conversions → New conversion action → Import → CRM/file → \"Conversions from clicks\":\n// CRM Lead (Google) — a Google-clicked contact was created in the CRM\n// CRM Booking Showed (Google) — that contact then attended an appointment (\"showed\")\n// The names must match EXACTLY, or Google rejects the rows with \"unknown conversion name\".\n//\n// TRAPS ENCODED HERE, so nobody relearns them\n// * Conversion Time must be AFTER the click. The click precedes contact creation, so lead rows use\n// dateAdded + 5 minutes and showed rows use the appointment start (later still).\n// * The gclid is not a first-class field: it hides inside attribution URLs and session blobs, often\n// URL-ENCODED (gclid%3D). Extraction is by regex over the serialised contact, both encodings.\n// * GET /opportunities/search with date filters returns HTTP 200 + 0 rows SILENTLY (proven 15 Aug).\n// Nothing here uses those filters. Contacts are paginated via meta.nextPageUrl and cut off locally.\n// * Cloudflare blocks non-browser clients inconsistently; all reads send a Chrome UA like the engine.\n\nconst KEY_SHA256 = \"48cd12465712045f70247da1689eeb198a4ce2d98416d8e52fb844581f044f15\";\nconst LOC = \"BQHJ19uohldYe3eqA0bl\";\nconst GHL = \"https://services.leadconnectorhq.com\";\nconst UA =\n \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36\";\nconst PAGE_CAP = 18; // 18 × 100 contacts ≫ any realistic lookback at ~25 new contacts/day\n\nasync function sha256Hex(s: string): Promise {\n const b = await crypto.subtle.digest(\"SHA-256\", new TextEncoder().encode(s));\n return [...new Uint8Array(b)].map((x) => x.toString(16).padStart(2, \"0\")).join(\"\");\n}\nasync function authorised(k: string): Promise {\n const expected = Deno.env.get(\"NURTURE_ADMIN_KEY_SHA256\") || KEY_SHA256;\n const got = await sha256Hex(k);\n if (got.length !== expected.length) return false;\n let d = 0;\n for (let i = 0; i < got.length; i++) d |= got.charCodeAt(i) ^ expected.charCodeAt(i);\n return d === 0;\n}\n\nasync function ghlToken(): Promise {\n const env = Deno.env.get(\"GHL_TOKEN\");\n if (env) return env;\n const { blob } = await import(\"https://esm.town/v/std/blob\");\n const cfg = (await blob.getJSON(\"puppy_config\").catch(() => null)) as { ghlToken?: string } | null;\n return cfg?.ghlToken ?? \"\";\n}\n\nasync function j(url: string, version: string, token: string): Promise {\n const r = await fetch(url, {\n headers: { Authorization: `Bearer ${token}`, Version: version, \"User-Agent\": UA, Accept: \"application/json\" },\n });\n if (!r.ok) throw new Error(`${r.status} ${url.slice(0, 120)}`);\n return r.json();\n}\n\n// gclid / wbraid / gbraid, plain or URL-encoded, anywhere in the serialised contact.\nfunction extractClickId(raw: string): { kind: string; id: string } | null {\n for (const kind of [\"gclid\", \"wbraid\", \"gbraid\"]) {\n const m =\n raw.match(new RegExp(`${kind}(?:%3D|=|%253D)([A-Za-z0-9_-]{20,140})`, \"i\")) ||\n raw.match(new RegExp(`\"${kind}\"\\\\s*:\\\\s*\"([A-Za-z0-9_-]{20,140})\"`, \"i\"));\n if (m) return { kind, id: m[1] };\n }\n return null;\n}\n\n// Google's documented CSV time shape, no per-row zone (the Parameters line pins UTC).\nfunction gTime(iso: string, plusMinutes = 0): string {\n const d = new Date(new Date(iso).getTime() + plusMinutes * 60_000);\n const p = (n: number) => String(n).padStart(2, \"0\");\n return `${d.getUTCFullYear()}-${p(d.getUTCMonth() + 1)}-${p(d.getUTCDate())} ` +\n `${p(d.getUTCHours())}:${p(d.getUTCMinutes())}:${p(d.getUTCSeconds())}`;\n}\n\nexport default async function (req: Request): Promise {\n const u = new URL(req.url);\n if (!(await authorised(u.searchParams.get(\"k\") ?? \"\"))) {\n return new Response(\"Not found\", { status: 401 });\n }\n const token = await ghlToken();\n if (!token) return Response.json({ ok: false, error: \"no GHL token in env or puppy_config blob\" }, { status: 500 });\n\n const days = Math.min(Math.max(Number(u.searchParams.get(\"days\")) || 35, 1), 85);\n const leadValue = Number(u.searchParams.get(\"leadValue\")) || 5;\n const showValue = Number(u.searchParams.get(\"showValue\")) || 150;\n const cutoff = Date.now() - days * 86_400_000;\n\n // 1. Walk contacts newest-first until we pass the cutoff.\n const hits: any[] = [];\n let url: string | null = `${GHL}/contacts/?locationId=${LOC}&limit=100`;\n let pages = 0, scanned = 0, reachedCutoff = false;\n while (url && pages < PAGE_CAP && !reachedCutoff) {\n const page = await j(url, \"2021-07-28\", token);\n const contacts = page.contacts ?? [];\n for (const c of contacts) {\n scanned++;\n const added = Date.parse(c.dateAdded ?? \"\");\n if (Number.isFinite(added) && added < cutoff) { reachedCutoff = true; break; }\n const click = extractClickId(JSON.stringify(c));\n if (click) {\n hits.push({\n id: c.id,\n name: [c.firstName, c.lastName].filter(Boolean).join(\" \") || \"(no name)\",\n dateAdded: c.dateAdded,\n click,\n });\n }\n }\n url = page.meta?.nextPageUrl ?? null;\n pages++;\n }\n\n // 2. Join each Google-clicked contact to its real outcomes.\n const rows: { clickId: string; name: string; time: string; value: number; who: string; why: string }[] = [];\n for (const h of hits) {\n rows.push({\n clickId: h.click.id, name: \"CRM Lead (Google)\", time: gTime(h.dateAdded, 5),\n value: leadValue, who: h.name, why: `contact created ${h.dateAdded} carrying a ${h.click.kind}`,\n });\n try {\n const appts = await j(`${GHL}/contacts/${h.id}/appointments`, \"2021-04-15\", token);\n const showed = (appts.events ?? []).filter((e: any) =>\n /showed|completed/i.test(String(e.appointmentStatus ?? \"\")) && e.startTime\n );\n // One \"showed\" conversion per contact — the FIRST attended appointment. Google de-dupes on\n // (click id, name, time), so re-uploads of the same file are safe; new showings restate the\n // same first row rather than inventing a second sale.\n if (showed.length) {\n showed.sort((a: any, b: any) => Date.parse(a.startTime) - Date.parse(b.startTime));\n rows.push({\n clickId: h.click.id, name: \"CRM Booking Showed (Google)\", time: gTime(showed[0].startTime),\n value: showValue, who: h.who ?? h.name, why: `attended ${showed[0].title ?? \"appointment\"} at ${showed[0].startTime}`,\n });\n }\n } catch { /* appointments unreadable for one contact must not sink the file */ }\n }\n\n if (u.searchParams.get(\"csv\") === \"1\") {\n const esc = (s: string) => `\"${String(s).replace(/\"/g, '\"\"')}\"`;\n // Column set taken from Google's own live template, fetched 15 Aug 2026:\n // https://www.gstatic.com/conversiontracking/conversion-import-template.csv\n // It now REQUIRES two consent columns. Omitting them fails Preview with the unhelpful\n // \"The selected file is missing data columns.\" Both are padded onto the Parameters row too,\n // exactly as the template does, or the row count check trips.\n // Ad User Data / Ad Personalization: GRANTED | DENIED | UNSPECIFIED.\n // UNSPECIFIED is the honest value here — Kim's customers are US, consent mode is not\n // configured on this account, and asserting GRANTED would be a claim about consent\n // collection nobody has verified. Google processes US traffic normally on UNSPECIFIED.\n const CONSENT = \"UNSPECIFIED\";\n const lines = [\n \"Parameters:TimeZone=+0000,,,,,,\",\n \"Google Click ID,Conversion Name,Conversion Time,Conversion Value,Conversion Currency,Ad User Data,Ad Personalization\",\n ...rows.map((r) =>\n [esc(r.clickId), esc(r.name), esc(r.time), r.value, \"USD\", CONSENT, CONSENT].join(\",\")\n ),\n ];\n return new Response(lines.join(\"\\n\") + \"\\n\", {\n headers: {\n \"Content-Type\": \"text/csv; charset=utf-8\",\n \"Content-Disposition\": `attachment; filename=\"dogsspot-google-offline-${new Date().toISOString().slice(0, 10)}.csv\"`,\n },\n });\n }\n\n return Response.json({\n ok: true,\n window: { days, since: new Date(cutoff).toISOString() },\n scanned: { contacts: scanned, pages, reachedCutoff },\n googleClickedContacts: hits.length,\n uploadRows: rows.length,\n rows,\n uploadHow:\n \"Google Ads → Goals → Conversions → Uploads → + → 'Upload a file' → this endpoint with &csv=1. \" +\n \"Both conversion actions must already exist as Import→'Conversions from clicks' with EXACTLY these names: \" +\n \"'CRM Lead (Google)' and 'CRM Booking Showed (Google)'.\",\n });\n}\n\n",[546],"4a6b8352-b339-408f-9e43-3a7d500903d6","SOURCE-BUNDLE.part40.txt","99c4a1d0-989e-11f1-8422-1607ee4eb77e",1090,["D",1786801896252],"THE DOGS SPOT — SOURCE BUNDLE (part 40 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (1 of 116 files)\n handover/DEPOSIT-SPEC.md 51179 bytes 4f0b188b82d9\n\n================================================================================================\n=====FILE handover/DEPOSIT-SPEC.md =====\n# HOLIDAY DEPOSIT TRACKER - build spec, 6 Aug\n## The finding that changes everything\nSquare payments ARE in the CRM. They land as contact notes, e.g.\n \"[Square] +$355.00 payment tWYOxuFcG9ZqzF7GTnUPfElf2ZEZY (balance $0.00)\"\nVerified live on contact mmc80rVoE52OKMPQUr7G, 6 Aug 00:47. Every previous conclusion that\n\"the CRM never sees Square money\" came from querying /payments/*, products and custom fields.\nNobody queried /contacts/{id}/notes. So the tracker is buildable, and what Kim was told\n(\"we read those payments and do the bookkeeping\") is accurate.\n\n## Two traps found in the same data\n1. The same payment is written FIVE times, with contradictory balance figures in the duplicates\n ($355.00 then $0.00 x4). Dedupe on the payment id. Never trust the balance figure.\n2. Recurring bookings (a standing weekly slot) fall inside any holiday window and would make\n Kim chase regulars who never owed. Filter isRecurring.\n\n## What it must say to Kim, honestly\nNot \"who still owes\". It cannot be that: a deposit taken in cash or over the phone leaves no\ntrace. It is \"holiday stays where we cannot find a $50 payment\" - a shortlist to check, which\nturns going through every holiday booking by hand into checking these few.\n\n## Build\n- engine/holiday-deposits.ts, called from the interval, rendered by dashboard.ts. GET only.\n Test asserts the source contains no POST/PUT/PATCH.\n- Read drop-off calendars only (pick-up would double count each stay).\n- Per distinct contact: GET /contacts/{id}/notes, parse /^\\[Square\\]\\s*\\+\\$([\\d,]+\\.\\d{2})\\s+payment\\s+(\\S+)/\n- Group into stays by contact + drop-off date. Musselwhite has three dogs on one day: one stay.\n- Status: seen / partial / none_seen / could_not_check. could_not_check NEVER collapses to none_seen.\n- Write NOTHING to the CRM. No tag, no field, no stage. addTag is not TEST_MODE-guarded, and\n \"Add tag 'red flag' = DND\" proves a tag here can silence a contact on six channels.\n- Kill switch: if zero Square notes exist in the period, suppress the list and say the feed\n looks dead, rather than printing \"everyone owes\".\n- The word \"unpaid\" must not appear. Suite asserts it.\n\n## Ask Kim before it goes live\nExact holiday window dates. $50 per stay or per dog. Does she ever take the deposit in cash.\n\n---\n\n# BUILT AND LIVE — 6 August 2026\n\n## What shipped\n| file | on the val | what it is |\n|---|---|---|\n| engine/holiday-deposits.ts | script | all the judgement. No fetch, no write verb, enforced by H22. |\n| engine/deposits.ts | http | the only file that touches the CRM. One GET-only door. |\n| engine/deposits-cron.ts | interval | the scheduled refresh. Separate from main.ts on purpose. |\n| engine/dashboard.ts | http | the card Kim reads, from the stored blob, no CRM call at render. |\n\nBlob key `holiday_deposits`. Endpoint `?k=&run=1` collects and stores; `?k=` reads\nback what is stored.\n\n## Watched working, live\n- 2026-08-06T15:41:28Z — first live collection. 2 stays, 2 calendars read, 0 read failures.\n- 2026-08-06T15:42:56Z — second collection after the kill-switch fix. Correct sentence.\n- 2026-08-06 ~15:44Z — card rendered on the live dashboard, both customers named, no accusation.\n\n## Two things the live data changed\n1. **There is a SECOND Square note format.** `[Square] Till payment $35.00 on . Matched from\n Square payment via customer .` It does not match the `+$` pattern this spec started\n with. A customer whose only record was this shape would have read as \"nothing on file\". Both\n formats are parsed now; where the same amount appears as a direct payment AND as a \"Matched\n from\" record, it is counted ONCE, because over-counting takes a real customer off the shortlist\n and nobody ever looks at them again. H23–H26.\n2. **The kill switch fired on a sample of two.** The first live run was about to tell Kim her\n payment feed had stopped because neither of two customers had a Square note. It now needs at\n least 5 customers checked (`MIN_SAMPLE_FOR_DEAD_FEED`). Found by watching it run, not by\n reading the code. H19b.\n\nAlso: her CRM returns BOTH `appointmentStatus` and the misspelled `appoinmentStatus` — on 4 of 13\nevents. They agree today. Both are read, and either one saying cancelled excludes the booking. H28.\n\n## Tests\n30 assertions in holiday-deposits.test.mjs, 12 in deposits-collect.test.mjs, 9 in dashboard.test.mjs\n(D5.1–D5.9). 19 negative controls prove each of those guarantees can actually go red.\n\n## NOT YET OBSERVED — do not claim this works\n`deposits-cron.ts` is registered on the val as type `interval` and the val accepted a second\ninterval file. **It has not been seen firing on its own.** val.town's API exposes no schedule\nfield, so the only proof is the blob's `at` moving forward without anybody triggering it. Until\nthat has been observed, the list refreshes when the endpoint is hit and the page honestly reports\n\"last checked N hours ago\". Baseline to check against: 2026-08-06T15:42:56.924Z.\n\n## Still to ask Kim\nExact window edges (currently Monday-to-Sunday around Thanksgiving, and 20 Dec to 2 Jan).\n$50 per stay or per dog. Whether she ever takes the deposit in cash — that answer decides whether\nthe \"may have been paid another way\" caveat can ever be dropped.\n\n---\n\n# ROUND TWO — 6 August, afternoon\n\nTwo independent adversarial reads were run against the shipped feature. The first found 19\ndefects, the second found 16 more IN THE FIXES. Everything below is what changed as a result.\nBoth reviewers were given the live data and told to run the built code rather than read it.\n\n## The design change that mattered\n\n**It has stopped guessing which payment is the deposit.** Nothing in the CRM says what a card\npayment was for, and two attempts at inferring it were both wrong in the direction that costs Kim\nmoney:\n\n| version | rule | what it got wrong |\n|---|---|---|\n| v1 | sum every payment between booking and drop-off | a $355 training package cleared a $50 deposit; cleared means nobody ever looks again |\n| v2 | sum payments within 10 days of the booking | missed a real $50 paid 8 days later — the card said \"we cannot find a $50 payment\" one line after printing one — and still cleared anyone who settled a $240 invoice that week |\n| v3 | **a card payment for EXACTLY $50 clears a stay. Nothing else does.** | every other payment near the stay is listed with date and amount for Kim to judge |\n\nA wrong \"worth a look\" costs Kim a glance. A wrong \"settled\" costs her $50 and she never finds out.\n\n## Everything else round two changed\n\n- **Stay length comes from the PICK-UP calendars.** A drop-off booking is a ten minute handover\n slot; its endTime says nothing about the stay. Pairing rule: the LATEST eligible pick-up on or\n after the drop-off and BEFORE that customer's next drop-off. Both bounds were found by failure —\n earliest-wins deleted a family whose first dog went home early, and unbounded made a 3-night\n Thanksgiving stay render as \"Nov 25 to Dec 27\".\n- **The kill switch counts customers, not bookings.** Her account has one contact with 24\n drop-offs; counting rows let one cash-paying regular suppress the whole card.\n- **A pick-up calendar that fails is declared on the card.** It was being written into the blob\n and read by nothing — the quietest possible failure, because the stays that vanish are exactly\n the ones the pick-up calendars exist to find.\n- **The unknown count on the card counts ROWS**, matching the table, not customers.\n- Daycare exclusion narrowed: a title saying both daycare and boarding is a boarding booking.\n- `looksLikeTestRecord` no longer matches \"tester\" — Tester is a real surname and this label sits\n next to a person's name.\n- The dead-feed sentence no longer says \"any of the 0 we could check\".\n\n## Two tests that could not fail, and one control suite that could not run\n\n- **H5** (\"cancelled bookings are excluded\") used a fixture dated 2 November, outside every\n window, so it passed with the cancellation filter deleted. Fixture moved inside the window.\n- **H8**'s structural guard matched a pattern that went stale the day `localDay` grew a legitimate\n numeric branch. It now asserts the specific thing it means: the string path slices, never parses.\n- **negative-controls.mjs was truncated by an edit** — the whole runner was deleted. It then\n printed NOTHING and exited 0, which reads as \"all controls passed\". `run-all.mjs` now runs one\n control as a smoke test and goes RED if the control suite prints no result. Fault-injected and\n confirmed to fire.\n\n## State at 16:53 on 6 August\n\n- 15 suites, 262 assertions, 0 failed.\n- **89 negative controls, 89 passing** — every guarantee above can be made to go red on demand.\n- Live run at 16:53:19Z: 2 stays, both worth a look, 2/2 drop-off and 2/2 pick-up calendars read,\n 0 unreadable customers. Card verified on the live dashboard, no accusation in it.\n\n---\n\n# ROUND THREE — 6 August, 17:00. Verdict was NOT CLEAN.\n\nA third independent read was run with instructions to mutate the code and prove the tests catch\nit. Six mutations, five stayed green. Everything below is what that round changed.\n\n## The one that would have cost Kim money, silently\n\n**One $50 payment settled every holiday stay that customer had.** `statusFor` answers about a\nsingle stay and was handed the customer's whole payment list. A regular who books Thanksgiving\nAND Christmas in the same phone call and pays one deposit had BOTH rows go green. Kim was owed\n$100, $50 arrived, and neither row reached the shortlist. This is the ordinary case, not an edge:\nthe two search windows are both anchored on the same booking date and overlap almost completely.\n\nFixed by `statusesForCustomer()`: payments are ALLOCATED, earliest drop-off first, and a payment\nspent on one stay is invisible to the next. H48, plus a negative control.\n\n## The one that would have taken the whole test suite down\n\n`D5.11`'s fixture carried a hardcoded timestamp and the stale-list banner fires on real elapsed\ntime. **From 8 August the entire 269-assertion regression net would have read RED on the wall\nclock, with no code change.** The fixture is now relative to now. Verified green at +48 hours and\nat +400 days by injecting an offset clock.\n\n## The rest\n\n- **A pick-up on the same day as the next drop-off** (collect one dog, board another, same day)\n deleted the stay it was ending — the busiest stay of the season, silently. Bound is `<=` now.\n- **An orphan pick-up dragged an out-of-season boarding onto the shortlist**: a 6 November stay\n rendered \"Nov 6 to Feb 1\". `MAX_STAY_DAYS = 21` caps the reach. Her account has ~20 contacts\n with pick-ups and no matching drop-off, so orphans are the common case.\n- **H42 was pinning that bug** — it asserted the drag HAPPENED, with a follow-up assertion whose\n first disjunct was false and whose second was true whenever the drag occurred. Rewritten to\n forbid it.\n- **One booking with no `dateAdded` blacked out the whole card**: its structurally-empty payment\n list counted as \"we looked and saw nothing\", pushing the dead-feed sample over the floor.\n- **A run where nobody's payments could be read was stored over yesterday's real shortlist**, with\n a FRESH timestamp — content worse, page claiming to be up to date. Now refused.\n- Grammar: \"1 card payment is on file … none of them … among them\".\n- Four guarantees that no test could break (the search window's upper edge, the per-customer\n sample rule, the amber label on a partial row, and the headline counting partial rows) now have\n tests and controls.\n\n## State at 17:21 on 6 August\n\n- 15 suites, **269 assertions**, 0 failed. Green at +48h and +400d on an injected clock.\n- **98 negative controls, 98 passing.**\n- Live run 17:21:23Z: 2 stays, 2/2 drop-off and 2/2 pick-up calendars, 0 unreadable.\n\n## STILL NOT OBSERVED — do not claim this works\n\n`deposits-cron.ts` is registered on the val as a second `interval` file. It has **not been seen\nfiring on its own**. The blob moved once at 15:44:33Z, six seconds after that file was deployed,\nwhich looks like a deploy-triggered first run rather than a schedule. Between 17:21 and 17:29 it\ndid not move. val.town exposes no schedule field on the API, so the only proof is the stored `at`\nadvancing with nobody triggering it. Until that is seen, treat the list as refreshing when the\nendpoint is hit; the card reports its own age and warns past 36 hours.\n\n---\n\n# ROUNDS FOUR, FIVE AND SIX — 6 August, evening. All three: NOT CLEAN.\n\nThree more independent adversarial reads, each told to mutate the code and prove the tests catch\nit. Between them they ran ~110 mutations. The pattern that matters: **the same money bug came back\nthree times, one layer down each time.**\n\n## The money bug, and the three doors it came back through\n\nThe rule is: one $50 deposit settles ONE stay. A regular books Thanksgiving and Christmas in one\nphone call and pays one deposit; if both rows go green, Kim is owed $100, $50 arrived, and neither\nrow reaches the shortlist. She never finds out.\n\n| round | door it came back through | fix |\n|---|---|---|\n| 3 | `statusFor` was handed the customer's whole payment list per stay | `statusesForCustomer` allocates each payment to one stay, earliest first |\n| 4 | the allocator marked only the SURVIVING id of a direct/backfill twin as spent | collapse once, globally, before allocating |\n| 6 | the collapse was one-for-one, so with two backfills and one payment the survivor was folded AGAIN per stay and never spent | the collapse is now IDEMPOTENT: every backfill sharing an amount with a payment folds, so a second pass is a genuine no-op |\n\nRound 6 found it reachable from Kim's real note text at ~1% of generated contacts. H48, H52, H56,\nH57 and D27 now cover the four layers; each has a negative control.\n\n## Test-integrity defects, which matter more than any single bug\n\n- **`run-all.mjs` never rebuilt.** Behavioural assertions import `build/`, structural ones read\n `engine/`. Deleting the allocation from the source and running the suite WITHOUT rebuilding gave\n \"270 assertions passed, RESULT: GREEN\". The runner now builds first, and a failed build is a RED.\n- **`negative-controls.mjs` was truncated by an edit** — the whole runner deleted. It printed\n nothing and exited 0, which reads as \"all controls passed\". `run-all.mjs` now runs one control\n as a smoke test and goes RED if the control suite prints no result.\n- **The suite would have gone RED on the wall clock on 8 August** — a fixture timestamp against a\n 36-hour staleness banner. Fixtures are relative to now; verified green at +2d, +200d and +2y.\n- **D29 was four vacuous assertions** — regexes over main.ts for \"3600_000\", \"holiday_deposits\",\n \"runCollection()\" and \"catch\". Four different real breakages stayed green, including one that\n made the refresh run on every tick and one that made it never run. The rule is a pure function\n now (`needsRefresh`) and is tested as one.\n- **D12/D26/D28 read the raw file**, so a `[was: ...]` note quoting a deleted guard kept them\n green. They read comment-stripped source now, and what the guards DO is tested behaviourally\n through `decideStore`.\n- **H27 could not fail** (its fixture used the deposit amount, where both assertions hold by\n construction). **H5 could not fail** (fixture outside every window). **H42 asserted the bug its\n own comment said was fixed.** All three rewritten.\n- One control was RETIRED rather than retargeted: idempotency made the fault it injected a no-op,\n so it could no longer fail. A control that cannot fail is worse than no control.\n\n## Other real fixes from these rounds\n\n- Drop-off and pick-up calendars are fetched over the SAME range. They were not, so for every stay\n at the tail of the season the customer's own next booking was never fetched and the \"hard upper\n bound\" was structurally blind: a 30 Dec stay rendered \"Dec 30 to Jan 15\" and a January payment\n settled the holiday deposit.\n- A pick-up on the same day as the next drop-off (collect one dog, board another) deleted the stay\n it was ending.\n- An orphan pick-up dragged an out-of-season boarding onto the shortlist as \"Nov 6 to Feb 1\".\n `MAX_STAY_DAYS = 21`.\n- The refresh gate now keys off an ATTEMPT stamp, not the stored list, so a run that legitimately\n declines to store does not get retried every 15 minutes against a CRM that is already unwell.\n- The season rolls over on New York time, not UTC. It was emptying the card at 8pm on 2 January.\n- `deploy.mjs` reports main.ts in BOTH characters and bytes and gates on the stricter. At one point\n it read 79,815 characters and 80,137 bytes — \"185 to spare\" on one measure, over the line on the\n other.\n- One `$50` payment can no longer be quoted on two different settled rows.\n\n## State at 19:23 on 6 August\n\n- 15 suites, **283 assertions**, 0 failed. Green at +2d, +200d and +2y on an injected clock.\n- **118 negative controls, 118 passing.**\n- Live run 19:03:39Z: 2 stays, 2/2 drop-off and 2/2 pick-up calendars, 0 unreadable, stored.\n Engine healthy after the main.ts change (engineOk true, watchdog INFO).\n\n## The refresh, and what is still not proven\n\n`deposits-cron.ts` has still never been observed firing on its own (checked at 15:44, 17:29, 18:32\nand 19:23 — every movement of the blob was a manual run). So the refresh is now called from\n`main.ts`'s interval, which IS watched keeping time. **That has not been observed firing yet\neither** — the attempt stamp was set at 19:03:39Z and the gate is one hour, so the first\nengine-driven refresh is due after 20:03. Do not claim it works until the stored `at` has moved\nwith nobody triggering it.\n\n---\n\n# THE TWO FACTS THAT WERE IN HER OWN HANDOVER PACK — 6 August, 20:30\n\nA seventh review round could not run: the container reverted to a 4 August snapshot and the whole\nfeature was gone from disk. Restored from the val's SOURCE-BUNDLE (9 parts, 34 files, byte-for-byte,\nzero DIFFERS against the live val) plus the engine files pulled from the val itself, and the two\nderived PDFs rebuilt from `scripts/make-pdfs.mjs`. Suite green again at 291 assertions.\n\nThat round did find two things before it stopped, both from `drive2/06_money.html` — the money page\nbuilt from Kim's own live website — and both were live money defects:\n\n## 1. The deposit is $50 PER DOG\n\n> \"Holiday boarding — **$50 per dog**, non-refundable. Deducted from the total boarding cost at\n> drop-off. The booking is not confirmed until the deposit is paid.\"\n\nThe module charged a flat $50 a stay, and the card carried a line asking Kim to tell us if it was\nper dog. It was in her own pack. Jeffrey Musselwhite's three dogs over Thanksgiving owe **$150**,\nand a single $50 payment was clearing the whole stay — the silent direction, where somebody who\nowes $100 more drops off the shortlist and is never looked at again.\n\nNow: `depositDue(stay) = $50 × dogs`, counted from the drop-off ROWS rather than the parsed names\n(her titles include \" Boarding Dropoff with Help Test\", which yields no name at all). A stay\nsettles on one payment for the full amount due, OR on one $50 payment per dog. Nothing else.\nH58, H59, and three negative controls.\n\n## 2. Card is not the only way she gets paid\n\nHer money page lists **Card, Venmo, Zelle and cheque**, and says card is \"the only one that matches\nitself to a customer record automatically\". The copy said a deposit \"may still have been paid in\ncash or over the phone\" — naming neither route she actually offers. Every Venmo, Zelle and cheque\ndeposit is invisible to this feature, so naming them is the difference between Kim knowing where to\nlook and Kim assuming non-payment. H60 and a control.\n\n## And one that fell out of the per-dog change\n\nThe headline said \"we cannot find a $50 payment against it\" directly above a row that owed $150 —\na number in prose contradicting the number beneath it. The headline names no amount now; each row\nstates its own. H61 and a control.\n\n## State at 20:31 on 6 August\n\n- 15 suites, **291 assertions**, 0 failed. 123 negative controls.\n- Live run 20:31:37Z: 1 stay (the second customer's New Year bookings were cancelled in her CRM\n between runs, and were correctly dropped), 2/2 drop-off and 2/2 pick-up calendars, 0 unreadable.\n- The card reads: \"The deposit on this stay is $150.00 (3 dogs at $50) and no card payment is on\n file around it at all. A deposit paid by Venmo, Zelle, cheque or cash does not reach the card\n system, so it will not show here.\"\n\n## Still open\n\n- Two consecutive CLEAN adversarial rounds. Rounds 1-6 were all NOT CLEAN; round 7 could not run.\n- The engine-driven refresh has still not been WATCHED firing. Attempt stamp 20:31:37Z, gate is one\n hour, so the first engine-driven refresh is due after 21:31.\n- Ask Kim: the boarding cancellation policy (her website has nothing on it), and whether the\n Thanksgiving window edges (Monday to Sunday) are the ones she wants.\n\n---\n\n# ROUND SEVEN — 6 August, 21:00. NOT CLEAN. The money bug came back a FOURTH time.\n\nFifty-three mutations run against the code. Forty-six were caught; five of the seven that were not\nsat in the per-dog logic added earlier the same evening.\n\n## The bug, and why it keeps coming back\n\nThe rule for **\"is this stay settled\"** and the rule for **\"what did that cost\"** lived in two\nplaces, and every time the first one grew, the second one did not follow.\n\nThe per-dog change let a stay clear on EITHER one payment for the full amount due OR one $50 per\ndog. The allocator still debited a single $50. So:\n\n- a two-dog stay settled by one $100 payment debited **nothing** — and that same $100 settled the\n customer's next stay too. Kim owed $200, $100 arrived, neither row reached her shortlist.\n- three $50 payments settled two two-dog stays ($150 covering $200), with the middle payment quoted\n on both rows.\n- a two-dog stay settled by $100 debited an unrelated $50 — so the next stay, which that $50\n exactly matched, was told *\"nothing on file matches that amount\"* while showing Kim the $100.\n A payment she can see, on a page saying it is not there.\n\nA property test over 50,000 generated customers: of 5,415 with two or more settled stays,\n**1,567 (29%)** cleared a set of stays that no disjoint allocation of the available payments could\nactually cover.\n\n**The fix is structural, not another patch.** `qualifyingPayments(stay, payments)` is now the only\nthing that decides which payments settle a stay. `statusFor` asks it what settles; the allocator\nasks it what to spend. They cannot disagree, because it is the same answer. H62, H63, H68 and four\nnegative controls.\n\n## The rest of round seven\n\n- **Nothing had ever typechecked this project.** `dogCount` was added to the `Stay` type and two\n object literals were never updated; esbuild strips types without checking them, so the build was\n clean and 290 assertions were green over a real type error. `scripts/typecheck.mjs` now runs a\n Deno-aware `tsc` (waiving only `Deno`, remote https imports, and `./main.ts`), `run-all.mjs`\n gates on it, and the exact defect was re-injected to prove the gate fires.\n- The Dogs column showed two names beside a three-dog charge, because names come from parsed titles\n and the charge comes from booking rows. It now reads \"Achilles, Ghost and 1 more (3 in total)\".\n- **$250 is her published TRAINING deposit and also exactly five dogs at $50.** The per-dog rule\n widened the clearing amounts from {$50} to {$50, $100, $150, $200, $250, ...}, so a $250 match\n now says out loud that it could be either.\n- The headline said \"we cannot find a card payment matching what **they are owed**\" — Kim is owed\n *by* them. `D5.4`'s ban regex only covered \"owes\", so it passed.\n- Three payment dates read \"Oct 5 and Oct 6 and Oct 7\".\n- `deposits-cron.ts` called `runCollection()` with no gate; if val.town ever fires it, it would\n have collected on every tick.\n- The dashboard fixture's `sentence` was hardcoded pre-round-6 copy, so D5.4's Venmo/Zelle\n assertion was satisfied by the fixture rather than by anything the code produces. It is generated\n from `depositSentence` now.\n\n## The refresh: first autonomous run OBSERVED\n\nAt **2026-08-06T20:49:03.612Z the list refreshed with nobody triggering it** — the first time that\nhas been seen. It is not yet known WHICH of the two schedules did it (the engine's interval, or\ndeposits-cron.ts), because nothing recorded the source. It does now: every attempt is stamped with\n`source`, and the read route returns `lastAttemptBy` alongside `lastAttemptAt` and `refreshDueAt`.\nNext refresh due 21:49:03Z. Until a labelled one is seen, the honest claim is \"something works\",\nnot \"the engine works\".\n\nReading the list does NOT write the stamp — checked by a control, because every earlier observation\ntonight was ruined by manual runs pushing the gate an hour further out.\n\n## State at 21:12 on 6 August\n\n- 15 suites, **300 assertions**, 0 failed, typecheck clean. 135 negative controls.\n- All four deposit files deployed and hash-verified on the val.\n\n---\n\n# THE REFRESH: WATCHED WORKING — 6 August, 21:49:13Z\n\nAll evening this was the one thing I would not claim. It is now observed, twice, with the source\nrecorded by the code rather than inferred:\n\n| when | what | source |\n|---|---|---|\n| 2026-08-06T20:49:03.612Z | list refreshed, nobody triggered it | not recorded (the stamp did not exist yet) |\n| 2026-08-06T21:49:13.781Z | list refreshed, nobody triggered it | **deposits-cron** |\n\nOne hour apart, matching the watchdog val's own observed hourly cadence. So val.town does run a\nsecond `interval` file in a val. The earlier note in NOTES-v1.4.md was a statement about what had\nbeen observed, not about the platform, and it is now superseded.\n\nBoth schedules are wired — deposits-cron.ts and main.ts's interval — and both go through the same\n`refreshIfDue`, reading the same attempt stamp. Whichever fires first closes the gate for an hour;\nthe other is a no-op. Nothing needs removing.\n\n**Checking it without breaking it:** GET the endpoint WITHOUT `?run=1`. That returns\n`lastAttemptAt`, `lastAttemptBy` and `refreshDueAt`, and writes nothing. `?run=1` writes the stamp\nand pushes the gate an hour out — which is exactly how every observation before 21:00 got ruined.\n\n# ROUND EIGHT — NOT CLEAN, but the money bug did not come back\n\n300,000 property cases across the allocator: **zero** violations of disjoint coverability, zero\ncross-window clearing, zero payments quoted on two settled rows, zero wrong amounts. The structural\nfix from round seven held. What round eight found instead:\n\n- **A row denied a payment Kim can see in Square. 7.9% of generated rows.** The payment list shown\n on a row was computed from the money still UNSPENT, so a stay whose deposit had already been\n counted against an earlier stay was told \"no card payment is on file around it at all\" — with the\n payment sitting in its own window. One step from an accusation, and false. Rows now show\n everything on the account near the stay and say plainly when money has already been counted\n against an earlier one.\n- **`run-all.mjs` reported GREEN with the seven money-guard tests deleted** — a suite could lose\n assertions and only a global floor of 100 would notice. There is a per-suite ratchet now, and the\n exact deletion was re-injected to prove it fires.\n- **The accusation ban missed \"Not paid\"** — relabelling a row shipped green. The ban is wider now\n and scans the state labels, and the one sentence allowed to use the word \"owe\" is the one that\n denies the accusation: it is removed by exact text before scanning and asserted present, so it\n cannot be deleted to make room for a real one.\n- **D33/D34/D35 were text-presence checks.** A mutation that called `needsRefresh` and threw the\n answer away — collecting from her CRM on every tick — passed all three. The decision is one\n shared function (`refreshIfDue`) that both schedules call, and it is tested by watching it decide.\n- Three dogs paid for in one visit read \"on Nov 20, Nov 20 and Nov 20\".\n- **$150 and $200 collide with her real boarding totals** (published rates $30-$65/day; five nights\n at $30 is $150, exactly a three-dog deposit), and only the rarest collision ($250, her training\n deposit) was flagged. Any single lump sum above one dog's deposit now says what else it could be;\n one $50 per dog is stronger evidence and carries no caveat.\n- `amountSeen` on a multi-dog settled row and the 0/1/many grammar on two strings were unpinned.\n\n## State at 21:52 on 6 August\n\n- 15 suites, **312 assertions**, 0 failed, typecheck clean, per-suite ratchet armed.\n- **143 negative controls.**\n- Live: 1 holiday stay, $150 due for three dogs, refreshing itself hourly.\n\n---\n\n# ROUND NINE — NOT CLEAN. The money bug's fifth door, and it was the collapse.\n\n## The bug\n\n`collapseSameMoney` folded a backfill record into a payment on **amount alone, with no date\nbound** — across a customer's entire history. The justification is one real pair on her account;\nthat pair is 14.6 days apart. $50 is precisely the amount a repeat customer pays more than once in\na year, so a November payment and a December till record were being read as one $50:\n\n- a real deposit deleted,\n- a settled stay demoted to the shortlist,\n- and the row then printing *\"nothing unspent on file matches that amount\"* and *\"nothing else is\n left over around it\"* about a customer who had paid **twice**.\n\n2.3% of generated customers. Setting every payment to `direct` (so the collapse can never fire)\ndrove it to 0.00%, which is how the cause was isolated.\n\n**Fixed with a date bound of 21 days**, and the number is not a guess: the one real pair is 14.6\ndays apart, because the parser deliberately uses the backfill's own stated payment date rather than\nthe day the note was written. A fortnight was written first and was too tight for the only case\nanybody has ever seen. Twenty-one carries about 40% headroom and still refuses to fold across\nmonths. H74 and two controls.\n\n## The test gaps it exposed, which matter as much\n\n- **The accusation ban was a ten-phrase deny-list** on the one invariant this feature exists for.\n It had already been widened once, after \"Not paid\" walked through. Round nine then walked\n \"No payment received\", \"Chase this one\", \"Still to pay\" and \"Deposit missing\" past it, plus a\n card printing *\"Total still to collect from these customers: $250\"* — a dollar total of alleged\n debt, containing no banned word at all. **It is an allow-list now**: the four state labels are\n pinned exactly, and adding a fifth has to come through the test. Running totals are banned\n separately.\n- **Both refresh call sites were guarded by greps.** Wrapping the engine's whole refresh in\n `if (Math.random() < 0)` — so the hourly refresh never fires — passed every string check and\n their ordering. And the scheduled file could call `runCollection` a *second* time outside the\n gate, collecting from her CRM on every tick, while satisfying a negative lookahead on the label.\n Now: the engine's statement is pinned exactly and nothing conditional may sit between the import\n and it; the cron file may contain exactly ONE `runCollection(` and it must be inside the gate.\n- **The `others`/`counted` split was only half pinned.** H69 asserted the \"already counted\"\n sentence was present, never that the payment was absent from the other list — so dropping the\n filter printed the same payment twice in one row, in contradictory terms, and it stayed green.\n\n## Also fixed\n\n- Three taps on one day listed as three identical lines (\"$50.00 on Dec 20, $50.00 on Dec 20,\n $50.00 on Dec 20\"). Now \"3 payments of $50.00 on Dec 20\".\n- \"Nothing else on this account is unaccounted for around it\" — accounting jargon and a double\n negative, immediately followed by a sentence naming a payment that IS around it.\n- \"an earlier stay\" when the money went to two or more.\n- The one string still saying \"Square payment\" where the other nine say \"card payment\".\n\n# THE REFRESH: THREE AUTONOMOUS RUNS, ALL LABELLED\n\n| when | source |\n|---|---|\n| 2026-08-06T20:49:03.612Z | not recorded (the stamp did not exist yet) |\n| 2026-08-06T21:49:13.781Z | **deposits-cron** |\n| 2026-08-06T22:52:28.947Z | **deposits-cron** |\n\nHourly, unattended, and the code names the schedule rather than leaving it to be inferred.\n\n# State at 22:55 on 6 August\n\n- 15 suites, **318 assertions**, 0 failed, typecheck clean, per-suite floors armed.\n- **151 negative controls, 151 passing.**\n- Live: 1 holiday stay, $150 due for three dogs, refreshing itself hourly.\n\n# STILL OWED\n\nTwo consecutive CLEAN adversarial rounds. Nine rounds have run; every one found something real.\nRound 10 is the next one.\n\n---\n\n# ROUND TEN — NOT CLEAN. The money is sound; the guards were not.\n\n**460,000 randomised allocator cases and 15,000 end-to-end collections: zero money defects.** The\nstructural fixes from rounds seven and nine held. What round ten broke instead was every guard\nround nine had added *specifically to be unbreakable*:\n\n- **The DEP_STATE allow-list pinned the constant, not the page.** The render site was free, so a\n ternary produced \"Nothing received\", a new column produced \"$150 to chase\", and a footer produced\n \"Still to collect across these stays: $250\" — all green. The ban underneath was two more\n hand-written regexes, inside a test whose own comment says guessing at English cannot work.\n **Now the RENDERED PAGE is checked three ways:** the column headers must be exactly the five it\n has; the status cell for each of the four states must be exactly its allowed label; and every\n dollar figure on the page must trace back to a row's own note or the headline, so a total of\n alleged debt cannot be synthesised however it is worded.\n- **The engine's exact-statement pin was bypassed by putting the condition BEFORE the import** —\n and again by wrapping the block in a function nothing calls. The hourly refresh never fired, 310\n assertions green. **The whole block is pinned now, and it must appear exactly once.**\n- **The cron file's ONE-`runCollection(` count was bypassed three ways**: aliasing it, handing the\n gate a reader that always returns null (collects every tick), and passing `0` instead of\n `Date.now()` (the gate never opens again, silently). **The whole statement is pinned, and both\n `runCollection` and `refreshIfDue` may appear exactly twice: the import and the call.**\n- **The accusation scan was reading hand-typed fixture notes**, not generated ones. Appending\n \", so they still owe this one.\" to a real branch reached Kim's page green. **It scans generated\n notes across every state now, rendered.**\n\n## Shipped defects it found\n\n- **\"2 are worth checking: we cannot find a card payment matching what ARE owed on them.\"** The\n first line Kim reads, in the common case. H73 checked the count and stopped before the clause.\n- **Five of six cancellation statuses were pinned by nothing** — every test asserted \"cancelled\"\n only. GHL emits `noshow` and `invalid`, and the American spelling is one keystroke away. Any of\n them reaching the list puts a customer who cancelled on her chase list.\n- **`COLLAPSE_WINDOW_DAYS` was pinned but not required to be used** — hardcoding 30 at the call\n site satisfied every assertion, so the documented bound and the effective bound could differ.\n- **Two different payments sharing an amount and a day rendered identically**, which makes a\n correct allocation look exactly like the money bug. Now: \"one of 2 payments of that amount that\n day\".\n\n## State at 23:40 on 6 August\n\n- 15 suites, **326 assertions**, 0 failed, typecheck clean, per-suite floors armed.\n- **161 negative controls**, each injecting one of round ten's own bypasses.\n- Live: 1 holiday stay, $150 due for three dogs, refreshing itself hourly (20:49, 21:49, 22:52 UTC,\n all labelled deposits-cron).\n\n## Still owed\n\nTwo consecutive CLEAN rounds. Ten have run; every one found something. The trend is worth stating\nplainly: rounds 1-9 kept finding defects in the FEATURE, and round ten found none — it found them\nin the tests guarding the feature. That is a different and better place to be, but it is not clean.\n\n---\n\n# ROUND ELEVEN — NOT CLEAN. One live defect, and the three new guards all defeated.\n\n## The live one, and it is the same sentence for the third time\n\n`statusesForCustomer` passed the **globally collapsed** payment list as `opts.all` — the parameter\nwhose own docstring says it is \"everything on the account, which is what Kim can see in Square\",\nwhich the collapsed list is not.\n\nA regular books Thanksgiving and Christmas and pays **both** deposits: $50 at the till on 24 Nov,\n$50 by card on 8 Dec. Fourteen days apart, inside the 21-day collapse bound, so the till record is\nfolded away — and its survivor is outside the Thanksgiving window. That row then read:\n\n> \"The deposit on this stay is $50.00 (1 dog at $50) and **no card payment is on file around it at\n> all.**\"\n\nAdding a later payment turned a settled stay into \"nothing at all\". 0.22% of rows. Fixed by passing\nthe raw list: `statusFor` collapses it itself, scoped to that stay's own window, which is the only\nscope where \"same money\" is a reading rather than a guess. H82 and a control.\n\n## The three guards from round ten, all defeated\n\n- **D30/D35 pinned the blocks but not their reachability.** One statement inserted *above* each\n block kills both schedules, with the pinned text, indentation and identifier counts untouched.\n Kim's list would never refresh again, suite green.\n- **D5.19's money-trace only ever rendered a single settled row**, so a total conditional on there\n being a worth-a-look row — the only shape where such a total makes sense — never appeared in the\n card it scans. It now renders all four row states.\n- **D5.4 is still a deny-list and still loses**: \"they have skipped the deposit\", \"Nothing has come\n in from them yet\", \"Those customers are still to pay\" all reached the card. **Replaced with an\n allow-list on the note cell**: the rendered note must be EXACTLY the note the engine generated,\n escaped, plus at most the one known test-record warning. The card may render a note; it may not\n write one.\n\n## The meta-guard that mattered most\n\n**A test can be hollowed out to a bare `return scoped(3, \"allocations\")` and still print PASS** —\nassertion count unchanged, self-reported check count unchanged, per-suite floors unmoved. I added\ncheck-totals to the harness first and it did not catch it, because the scope number is self-\nreported.\n\nWhat does catch it is a **negative control**: it injects the fault and demands that named test go\nred, and a hollow test cannot go red. So `run-all.mjs` now runs **six money-critical controls on\nevery single test run** — the ones guarding the bug that has come back six times — and goes RED if\nany of them stops firing. Cost: about thirty seconds. Fault-injected: hollowing H62 now fails the\nrun with \"red, but on the wrong test\".\n\n## Also fixed\n\n- `MAX_STAY_DAYS` could be set anywhere from 22 to 86 without a test moving.\n- The same-day clause could drop \"that day\", which would be true of two payments a month apart.\n\n## What I am NOT claiming\n\nA source-reading test cannot prove a call site is *reached*. Round eleven demonstrated that twice,\nand the fix for it is not another text pin — it is the live signal: the card reports its own age and\nwarns past 36 hours, and the attempt stamp records which schedule last ran. A dead schedule shows up\non Kim's page, which is where it matters.\n\n## State at 00:27 on 7 August\n\n- 15 suites, **318 assertions**, 0 failed, typecheck clean, per-suite test AND check floors armed,\n six money guards re-proved every run.\n- **165 negative controls, 165 passing.**\n- Refresh observed autonomously four times: 20:49, 21:49, 22:52, 23:54 UTC, all `deposits-cron`.\n\n## Still owed\n\nTwo consecutive CLEAN rounds. Eleven have run.\n\n---\n\n# ROUND TWELVE — NOT CLEAN. One live contradiction, and the note allow-list was too narrow.\n\n## The live one: a row denied a match one clause before printing it\n\nA payment can be VISIBLE in a stay's window and still not settle it, when its fold-twin survives\noutside that window. The row then read:\n\n> \"The deposit on this stay is $50.00 (1 dog at $50), and **nothing unspent on file matches that\n> amount**. 1 card payment is on file around it: **$50.00 on Oct 15**.\"\n\n1.3% of rows. The module's own header names that exact sentence shape as the v2 bug it was fixed\nfor — it had come back in a different branch. The worse variant lists two $50 payments against a\n$100 two-dog stay in the same breath as denying a match.\n\nIt now says what is true: *\"…and Square records the same money again outside this stay, so it has\nnot been counted here.\"* The plain wording survives for the ordinary case where nothing matches.\nH83 and a control.\n\n## The note allow-list was too narrow, seven ways\n\nD5.20 only ever rendered `seen` rows and only inspected the note cell. A twelfth review put seven\naccusations onto Kim's page with the suite fully green:\n\n- \" They have skipped the deposit.\" — gated on `none_seen`\n- \" Those customers are still to pay.\" — gated on `partial`\n- \"Nothing has come in from them yet. \" — prepended\n- one gated on row DATA rather than state, to prove it was not just about `state`\n- \"Ann Flu **(still to pay)**\" — the Who column\n- \"Fluffy **- deposit missing**\" — the Dogs column\n- the stale banner rewritten to \"will still show here as **having skipped it**\"\n\nNone contains a banned word, which is the point D5.20's own comment makes. It now checks **every\nstate and every cell of the row** — Who, Dogs and note must each be exactly what the engine gave\nit, escaped — and pins the staleness sentence word for word.\n\n## The money-provenance check was a substring test\n\nD5.19 asked \"does this figure appear anywhere in the notes?\", so a total that coincided with any\nrow's figure passed — and with a $50-per-dog deposit those figures are exactly what a debt total\nsums to. This shipped green:\n\n> \"These stays are still short by **$150.00** between them.\"\n\nIt is provenance **by exclusion** now: strip everything the card was given, and any money left over\nwas invented by the card.\n\n## Also\n\n- The Dogs cell's escaping was covered by nothing. Dog names come from appointment titles, which\n her public booking form writes, so that cell is attacker-writable. The shipped code escapes it\n correctly; the guard was missing.\n- The footer's \"Venmo, Zelle, a cheque or cash will not\" could be dropped entirely — D5.12 scanned\n the whole card and was satisfied by the headline.\n- A $200 four-dog row advised \"Two or three separate $50 payments would be clearer\" — $100 to $150\n of advice on a $200 stay, contradicting the rule the same row applies. It names the right number\n now.\n\n## State at 01:31 on 7 August\n\n- 15 suites, **324 assertions**, 0 failed, typecheck clean, test AND check floors, **seven**\n money-critical controls re-proved on every run.\n- **174 negative controls.**\n- Refresh observed autonomously five times: 20:49, 21:49, 22:52, 23:54, 00:54 UTC, all\n `deposits-cron`.\n\n## An honest note on where this is going\n\nTwelve rounds. Rounds 1-9 found defects in the FEATURE. Rounds 10-12 have found almost entirely\ndefects in the TESTS — each round defeating the guard the previous round added, usually by gating\non a row state or a cell the fixture never rendered. That is a real and improving trend, but it is\nnot the same as clean, and I have not claimed it is.\n\n---\n\n# ROUND 14 — 7 August\n\nTen reviewers, eight against different targets at once. Every finding below was reproduced by hand\nbefore it was touched. Most of what came back was not about the deposit feature at all.\n\n## Three test-integrity holes, each the successor of a disaster this project already had\n\n**1. A whole suite could vanish and `run-all` still printed GREEN, exit 0.** Every floor is applied\nby looking a suite up in `rows`, and `rows` only holds suites discovery found. Proved three ways:\ndelete `detect.test.mjs` (14 suites, GREEN, no mention); rename it `.bak` (GREEN, one passive line);\nadd it to `NOT_A_SUITE` (GREEN, appears nowhere at all). Fixed: every key in any floor table must\nappear in `rows` or the run is RED, and `NOT_A_SUITE` is printed on every run.\n\n**2. A test could still be hollowed to `return scoped(N, label)` and print PASS.** Disaster #3, which\ntwo previous fixes were supposed to close. Proved on `H1` — the guard on the exact \"fourth Thursday\"\nmistake Kim made — by deleting all five `eq()` calls: `86 passed, 0 failed, 327 checks`,\nbyte-identical to the honest run, GREEN. Both existing floors are numbers a test AUTHOR TYPES.\nFixed: `ok()`/`eq()` increment a counter inside themselves, a test executing zero assertions is a\nhard failure, and `ASSERT_FLOORS` ratchets that count per suite. Same guard added to the v1 harness.\n\n**3. `negative-controls.mjs` truncated to three entries printed a small, plausible green.** Fixed\nwith `EXPECTED_CONTROL_COUNT`, checked before anything runs and under `--only` too.\n\nTwo more of the same family: **a control could pass on a suite that was already red** (fixed with a\nmemoized clean-tree baseline per suite), and **run-all's seven money guards were matched by NAME**\nso the fault under a name could be swapped and the reassuring line kept printing (fixed with a\nfingerprint of the injected fault). Also `codeOnly()` was defeated by a decoy string constant\ncontaining the code being asserted; whole-line string constants are blanked now, with the residual\nnamed. And `typecheck.mjs` printed \"0 engine files, 0 real error(s)\" and exited 0 on an empty tree.\n\n## Live defects in the feature\n\n**Two customers could drop off the list with nothing looking wrong.** `decideStore` refused an empty\nrun, an all-unknown run, and a real-list-to-nothing run — but not a run that saw FEWER calendars\nthan the stored one. One calendar failing (no retry exists) wrote a partial union over the complete\none with a fresh timestamp; the missing customers get no row at all, not an unknown row. Fixed by\ncomparing how many calendars did NOT answer, so a deleted calendar still stores and so does the\nfirst run.\n\n**The allocator was order-dependent, two ways** (841,000 shuffles). Same-day stays settled in caller\norder; and `qualifyingPayments` took the first array match, which could starve a later stay. Fixed\nwith a deterministic stay tie-break and oldest-money-first. 60,000 shuffles now stable, and the fix\nsettles a case that used to come back half-unpaid.\n\n**Nine crashes in `depositCard`**, each of which takes down the whole dashboard — `rows` non-iterable,\n`dogs` a string, `windows` a string or holding a null, a non-string `day` (invisible with one row,\nbecause `.sort()` never calls the comparator on a one-element array). **The headline was read out of\nthe blob and never checked against the rows underneath it.** **An unparseable `at` skipped the\nstaleness banner entirely.** **An unrecognised state** got a grey dot beside an orange label. **A row\nwith no name** rendered as an anonymous green \"Payment on file\". **Bidi overrides** and unbounded\nlength reached the page from a public booking form. **A UTC drop-off time** would move a stay a whole\nday — not observed on this endpoint, cheap to handle, wrong to slice.\n\n## Copy\n\n**Cash is not one of Kim's routes** — her money page lists Card, Venmo, Zelle, Cheque and nothing\nelse. **\"Daycare\" was on her dashboard**, which she instructed removed from customer copy.\n**\"Nothing collected yet\"** reads as a sentence about money under a heading about deposits.\n**The accusation net missed 45 of 53 candidate sentences** — it had a vocabulary of refusal and none\nof absence or invoicing, and two misses were pure inflection.\n\n## The reversion, and what it cost\n\nAt about 15:10 the container reverted to a snapshot predating the deposit tracker. `scripts/` was\ngone, so `restore.mjs` was gone with it and had to be rewritten before anything could be recovered;\nthe val token was recovered from the session transcript. The restore then returned a MISMATCHED\nrepo: the engine came back at round-14 state because it had been deployed, and tests and handover\ncame back from a bundle written before round 14 because the rebundle had been left to the end.\nSix tests failed for reasons that looked like new bugs and were actually a day-old suite meeting\nday-new code. Roughly half this session's remaining budget went on rebuilding the test side.\n\nThe lesson is not \"check harder\". It is **rebundle the moment the tree is green**, every time,\nbecause the bundle is the only copy of everything that is not the engine. `restore.mjs` now names\nthe eleven files whose absence means the bundle is older than the work, and says so on the way out.\n\n## State at 16:40 on 7 August\n\n- 15 suites, **332 tests**, 0 failed, typecheck clean, test AND check AND assertion floors, every\n floor's suite proved to have actually run.\n- **203 negative controls**, seven pinned by fingerprint in `run-all`, one retired on the record.\n- Engine deployed and verified (v388); bundle rebuilt and pushed (parts 1-11); `restore.mjs --check`\n shows byte-for-byte agreement on every file.\n- Watched live at 03:13:02Z: a real collection through the new storage rule, 2/2 calendars, 2/2\n pick-ups, stored, row note naming three routes rather than four.\n- Refresh observed autonomously at 02:55:55Z, labelled `deposits-cron` — the sixth sighting.\n\n# ROUND 15 — IN FLIGHT, NOT CLEAN\n\nOne reviewer ran before the reversion, against the accusation net. It tested 81 candidate sentences\nand got **69 past the regex and onto the rendered card**, in 17 distinct mechanisms. Fourteen are\nreal. One is fixed:\n\n- **FIXED: the non-breaking space.** \"Jeffrey has not paid his deposit.\" A JS regex literal\n space matches U+0020 and nothing else, so one invisible character defeated every two- and\n three-word alternative at once — ten of about twenty-five — while rendering identically on Kim's\n phone. The scrub now folds NBSP, thin spaces and zero-width characters to ordinary spaces and\n collapses runs, so the regex sees the sentence a reader sees.\n\n**Still open, and the first work of the next session.** The remaining thirteen fall into groups the\nregex has no vocabulary for: negator-verb separation (\"has not YET paid\", \"is yet to pay\"), ellipsis\n(\"the others are settled. Jeffrey hasn't.\"), euphemism (\"not settled\", \"still open\", \"hasn't\ncleared\", \"shortfall\"), imperative (\"collect from Jeffrey before Thursday\"), spelled-out and\nreworded ratios (\"Zero of three\", \"0 out of 3\"), passive absence (\"no deposit was taken\"), the\nprogressive (\"nobody is paying\"), and hyphenation (\"un-paid\").\n\nThe honest conclusion is that this is the third time the blocklist has been widened and the third\ntime it has been beaten. **A denylist over free prose cannot be completed.** The next round should\nstop widening it and make the note cell an ALLOW-LIST by construction: every Kim-facing sentence is\ngenerated from a small closed set of templates, and the test reconstructs each rendered string from\nits template plus the row's data and demands an exact match — the same provenance-by-exclusion\nargument already used for the money figures. The regex stays as a second line, not the first.\n\n\n",[554],"74f1abbd-787f-4078-8758-d31dd8d98cb0","SOURCE-BUNDLE.part4.txt","987dc3f2-90c3-11f1-8748-1607ee4eb77e",1089,["D",1786801895712],45,"THE DOGS SPOT — SOURCE BUNDLE (part 4 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (4 of 116 files)\n\n engine/decisions.ts 24235 bytes 613969c51185\n engine/deposits-cron.ts 2221 bytes 9f774e1fa586\n engine/deposits.ts 22047 bytes 04da4c1ffef5\n\n================================================================================================\n=====FILE engine/dashboard.ts#2 =====\nem holds\" : \"them hold\"} up the email half, which cannot start until ${blocking === 1 ? \"it is\" : \"they are\"} answered.`} They are the first card below, most pressing first.
` : \"\"}\n\n
Waiting on you
\n
The ones written out in full are the ones worth your time first: anything holding up the email half, anything already affecting customers, and anything about money. The rest can wait as long as you like. Each one says how we know it is real and what happens if you never answer, because for most of them the answer is nothing bad. They are numbered, so a reply saying \"yes to 1 and 3\" is a complete answer. The numbers stay attached to the same questions week to week, so the list below runs out of order once the quieter ones are tucked away. Send it to Amir on Upwork, or say it on the next call.
\n${decRows}\n
\n\n${stale.length || missing.length || truncated.length ? `
Heads up: ${\n stale.length ? `${esc(stale.map((s) => `${s} (last read ${ago(sectionAge(s))})`).join(\", \"))} could not be read at this moment, so ${stale.length === 1 ? \"that number is the last one\" : \"those numbers are the last ones\"} we read successfully. ` : \"\"\n}${missing.length ? `${esc(missing.join(\" and \"))} could not be read and there is no earlier reading to show, so ${missing.length === 1 ? \"it shows\" : \"they show\"} as n/a. ` : \"\"\n}${truncated.length ? `you have enough records that we stopped reading partway through rather than keep you waiting, so ${truncated.length === 1 ? \"the count of\" : \"the counts of\"} ${esc(truncated.join(\" and \"))} ${truncated.length === 1 ? \"is a floor\" : \"are floors\"}, not ${truncated.length === 1 ? \"a total\" : \"totals\"}. The real number is that one or higher, never lower. ` : \"\"\n}Every other number on this page was read fresh just now. Refreshing in a few minutes normally gets the rest.
` : \"\"}\n\n
\n${tile(\"New inquiries\", na(inq), inq != null && inqPrev != null ? `last 7 days, ${vs(inq, inqPrev)}` : \"last 7 days\", undefined)}\n${tile(\"Pup Talks on the calendar\", pt ? String(pt.booked) : \"n/a\", pt && ptPrev ? `held in the last 7 days, ${vs(pt.booked, ptPrev.booked)}` : \"held in the last 7 days\")}\n${tile(\"Showed up\", pt ? String(pt.showed) : \"n/a\", pt ? (() => {\n const un = Math.max(0, pt.booked - pt.showed - pt.noshow);\n const bits = [`of the ${pt.booked} held`];\n if (pt.noshow) bits.push(`${pt.noshow} did not show`);\n // every appointment in the denominator has to be accounted for, or the reader is left doing\n // subtraction on the front tile and finding a number missing\n if (un) bits.push(`${un} ${un === 1 ? \"has\" : \"have\"} not been marked yet, so this figure is flattering by up to ${un}`);\n const tail = pt.cancelled ? ` A further ${pt.cancelled} cancelled ahead of time and ${pt.cancelled === 1 ? \"is\" : \"are\"} not counted in the ${pt.booked}.` : \"\";\n return bits.join(\", \") + \".\" + tail;\n })() : \"last 7 days\")}\n${tile(\"New customers\", won ? String(won.count) : \"n/a\", truncated.includes(\"customers\") ? \"reached the Customer stage. At least this many: see the note above\" : won && wonPrev ? `reached the Customer stage, ${vs(won.count, wonPrev.count)}` : \"reached the Customer stage, last 7 days\", undefined)}\n
\n\n${depositCard(dep, depR.ok, ago)}\n\n${funnelReady ? `
From first contact to paying customer
\n
Four counts over the same 7 days. An inquiry is any new person who reached you and landed in your CRM: a Facebook or Instagram message, a form, the chat box, or a phone call somebody logged.
\n${funnelHtml}\n
Before reading that first gap as bad news: ${socialShare != null ? `${socialShare}% of these inquiries` : \"most of these inquiries\"} arrived as a message on Facebook or Instagram, and a message costs the sender nothing, so plenty were never close to booking. Worth knowing what this cannot tell you: your CRM's arrival record has no category for a phone call at all, so callers are not separated out here. The old source column logged ${esc(String(phoneLogged ?? \"some\"))} phone calls this week, but that column is blank for most people, so neither of us can put a firm number on how many of these actually rang you. The first three rows follow the same people through. The last one does not, and it would be dishonest to draw an arrow to it: somebody who became a customer this week usually first got in touch weeks or months ago, so they are not part of the ${esc(String(inq))} above. Read it as four true counts over the same seven days rather than one conversion rate. The gap between inquiries and Pup Talks is the widest of them, and it is the one worth a conversation.
\n
` : \"\"}\n\n
Is everything working?
\n${checkRow(crmOk, \"Your CRM\", crmOk ? \"Answering normally. This page just read it.\" : crmPartial ? `Answered for some things but not for ${esc(crmDown.join(\" and \"))} just now. If this is still showing in an hour, tell Amir.` : \"Did not answer just now. If this is still showing in an hour, tell Amir.\")}\n${checkRow(engineOk, \"The follow-up system\", kill?.stopped\n ? \"Stopped by the big red button. Nothing is being sent.\"\n : engineAgeMin == null ? \"No check-in recorded yet.\"\n : `Last checked itself ${ago(run?.ts)}. ${lateSentence(engineLate, engineCadence)}`)}\n${checkRow(wdOk, \"The watchdog\", wd\n ? wdNeverRanItself\n ? `${wd.headline} Last look ${ago(wd.ts)}, started by hand. ${neverRanItselfSentence(wdTrackingSince, wdManualSince)}`\n : `${wd.headline} Last look ${ago(wd.ts)}. ${lateSentence(wdLate, wdCadence)}${wdLate.state === \"late\" ? \" Treat that last report as out of date until it looks again.\" : \"\"}`\n : \"No report from the watchdog yet.\")}\n${meta ? checkRow(true, \"Facebook ad spend\", \"Connected and reporting. Your spend is in the advertising section below.\")\n : metaPending ? `
•
Facebook ad spend
Half connected. Your ad account is named here, and Facebook has not yet given us permission to read what you spend on it, so the connection does not work yet. That is one setting on Amir's side, not a fault. It is the only reason this page can show you what came in but not what it cost.
`\n : metaErr ? checkRow(false, \"Facebook ad spend\", `Not reading right now: ${metaErr}`)\n : `
•
Facebook ad spend
Not linked yet, so this page cannot show what you spent. Where your inquiries came from is shown below regardless, because that comes from your own records rather than from Facebook.
`}\n
\n\n
Where the last 7 days of inquiries came from
\n${chan ? `
${chanBar}
${chanLegend}
` : `
Could not read this just now.
`}\n${cover ? `
${cover.known === cover.total ? `Every one of these ${cover.total}` : `${cover.known} of these ${cover.total}`} carries a record of how they arrived, though for some that record just says \"other\", so treat the named channels as the solid part. Worth knowing: the CRM's own \"source\" column is blank for ${esc(String(((srcAll ?? []) as any[]).find((s: any) => s.source === \"no source recorded\")?.n ?? 0))} of these, so any list built off that column will look like you have no idea where your customers come from. You do. It is recorded one field over.
` : \"\"}\n${otherBucket && otherBucketSentence(otherBucket) ? `
${esc(otherBucketSentence(otherBucket))}
` : \"\"}\n${campRows ? `
Which ads they answered
${campRows}
${\n campShown < campTotal\n ? `The ${Math.min(5, (camps ?? []).length)} biggest, covering ${campShown} of the ${campTotal} people who answered a named ad. The remaining ${campTotal - campShown} are spread across ${Math.max(0, (camps ?? []).length - 5)} smaller ones. `\n : `All ${campTotal} people who answered a named ad. `\n}${inq != null && campTotal < inq ? `The other ${inq - campTotal} of your ${inq} inquiries came in without a campaign attached, which is normal for people who message you directly rather than clicking an ad. ` : \"\"}These are the campaign names exactly as they appear in your ad account. Counted from your own records rather than from Facebook, so it stays true whether or not the ad account is linked.
` : \"\"}\n
\n\n
New inquiries, week by week
\n${buckets ? `
${bars}
Eight weeks, oldest on the left. The last bar is the last 7 days.${trendLine ? ` ${esc(trendLine)}` : \"\"}
` : `
Could not read this just now.
`}\n
\n\n${meta || metaErr ? `
What the advertising cost
\n${adCard(\"Facebook and Instagram\", !!meta, meta ? money(meta.spend) : \"\", meta ? String(meta.conv) : \"\", metaErr ? `Not reading right now: ${metaErr}` : \"\")}\n${meta ? `
Spend covers the seven full days up to yesterday, which is the last day the ad platform reports as final. Set against the ${esc(String(inq ?? \"n/a\"))} inquiries above, that is ${meta && inq ? esc(money(meta.spend / inq)) : \"n/a\"} each.
` : \"\"}\n${googleErr ? `
Google: ${esc(googleErr)}
` : \"\"}\n
` : \"\"}\n\n
What we have been doing
\n
Newest first. Each line names how it was checked, so you can pick any one and hold it up against the thing itself. Anything marked \"my mistake\" is one of mine, kept here on purpose rather than quietly fixed.
\n${logRows || `
Nothing recorded yet.
`}\n${logRest ? `
${logRest} older ${logRest === 1 ? \"entry\" : \"entries\"}
${logRestRows}
` : \"\"}\n
\n\n
One thing worth fixing in the CRM
\n
${valued != null && valuedTotal != null && won2Total\n ? `A price gets written on about one deal in ${Math.max(2, Math.round(won2Total / Math.max(1, valued)))}: ${valued} of your ${won2Total} customer records carry one, ${money(valuedTotal)} between them. The most recent was ${valuedRecentMs ? esc(prettyDate(new Date(valuedRecentMs).toISOString()) + \" \" + new Date(valuedRecentMs).getUTCFullYear()) : \"further back than these records reach\"}. So the habit exists and it lapsed.`\n : \"Most of your deals do not carry a value.\"}${lostCount != null ? ` Across all ${won2Total} of those records, ${lostCount === 0 ? \"not one is marked won or lost\" : `${lostCount} ${lostCount === 1 ? \"is\" : \"are\"} marked lost and none at all are marked won`}.` : \"\"} So to be plain about it: this card carries no money in it, in or out, only counts of people. That is why it counts people reaching the Customer stage rather than showing you revenue: a figure built on that few would be worse than no figure at all. Writing the price on each deal as it closes is the single change that would let this page show you what a week was worth.
\n\n
The follow-up system, in detail
\n${modeKnown\n ? `
${practice ? \"⚠\" : \"✓\"}
${practice ? \"Practice mode\" : \"Live\"}
${practice ? \"It is doing everything except actually sending. Nobody real is being messaged. It goes live only when you say the word.\" : \"Real messages are going to real people.\"}
`\n : `
⚠
Practice or live: could not check
The system's own record did not answer just now, so this page will not guess. Refresh in a minute.
`}\n${stateKnown\n ? `
0 ? WARN : GOOD}\">${pausedN > 0 ? \"⚠\" : \"✓\"}
${pausedN > 0 ? `${pausedN} person${pausedN === 1 ? \"\" : \"s\"} replied and ${pausedN === 1 ? \"is\" : \"are\"} waiting on you` : \"Nobody is waiting on a reply from you\"}
${pausedN > 0 ? \"The system stepped back the moment they wrote to you. Answer them in your inbox; that is the only job this system ever hands you.\" : \"When somebody replies, the system stops messaging them and they appear here. That is the only job it ever hands you.\"}
\n
${realPeople ? \"✓\" : \"⚠\"}
${realPeople === 0 ? (practice ? \"Nobody real is in the sequence yet\" : \"Nobody is in the sequence right now\") : `${realPeople} in a sequence`}
${realPeople > 0\n ? \"People currently walking through the follow-up messages.\"\n // THE EMPTY CASE, AND WHICH EMPTY IT IS. Empty-and-practice, empty-and-live and\n // empty-and-we-cannot-tell are three different facts and read differently; the unknown branch\n // must not contain the phrase the watchdog scans this page for. Full note: NOTES-dashboard.md.\n : practice\n ? `In practice mode the system runs against ${activeN === 0 ? \"no records at all\" : `${activeN} test record${activeN === 1 ? \"\" : \"s\"} of ours`} and has never sent to or processed one of your actual inquiries. That is deliberate: it is how we prove the machinery works without touching anybody. People join by carrying the tag \"${esc(SOURCE_TAG)}\". A person can put that tag on today, and anyone marked simply waits, untouched, until the switch is thrown. No automation applies the tag yet, so that tagging gets switched on in the same move as go-live.`\n : !modeKnown\n ? `There is nobody in the sequence at this moment. Whether the system is set to run in practice or for real could not be read when this page opened, so this page will not tell you which, and the row a little above says the same thing. That is a failed read of one small record, not a fault in the follow-up itself. Nothing on this line is a claim about who has or has not been messaged, and nothing here is waiting on you. Refresh in a minute and it should be able to answer.`\n : `The system is live and there is nobody in it at this moment. That is what an empty week looks like rather than a fault: everyone who joined has either booked, become a customer, or reached the end of their three weeks. Nothing needs doing and nothing is waiting on you. The next person joins on their own, as soon as the mark \"${esc(SOURCE_TAG)}\" is on their record. Worth knowing which way to read a long empty run: if this line still says nobody a week from now while the new inquiries count at the top of this page keeps climbing, that is people arriving and not being marked, and it is worth telling Amir.`}
`\n : `
⚠
Who is in the system: could not check
This page will not show you a zero it cannot stand behind. Refresh in a minute.
`}\n
\n\n
Read live ${esc(prettyDate(new Date(now + tz * 60_000).toISOString()) + \" at \" + new Date(now + tz * 60_000).toISOString().slice(11, 16))} Georgia time. The four counts at the top, the funnel, both breakdowns and the week-by-week chart ${stale.length || missing.length || truncated.length ? \"were read from your own systems just now, apart from the ones named at the top\" : \"were read from your own systems just now\"}. The questions and the list of work are written by hand, and each one carries the check that backs it.
\n`;\n\n return new Response(html, { headers: { \"content-type\": \"text/html; charset=utf-8\", \"cache-control\": \"no-store\" } });\n}\n\n\n=====FILE engine/decisions.ts =====\n// WHAT IS WAITING ON KIM. v1.2, 4 Aug 2026.\n//\n// WHY THIS FILE EXISTS: two independent readers were handed the dashboard cold. Both said the\n// same thing without prompting. Kim: \"there is no list of what I'm being asked, no button, no\n// 'Kim: 3 things waiting on you'.\" Candace: \"exactly one requires anything from us, buried\n// fifth-from-top, styled identically to eight items needing nothing, with no owner.\" A page that\n// reports state but never asks for a decision quietly turns the reader into a spectator.\n//\n// THE RULE: an item goes here only when it is genuinely blocked on Kim, it is written in her\n// words, and it says what happens if she says yes AND what happens if she says nothing. No item\n// nags. No item implies she is late. \"Nothing\" is always an acceptable answer, and where that is\n// true the item says so.\n//\n// EVERY ITEM MIRRORS A NUMBERED ROW IN THE COMMITMENTS LEDGER, so the page and the ledger cannot\n// drift apart. The `ref` is that row. If you add one here, add it there in the same commit.\n//\n// v1.2, after the second stranger test. Three findings, all fair:\n// 1. Every item carries `evidence` now. The work log below it sets a standard of proof (\"How we\n// know\" on every line) and this card was exempting itself from that standard while sitting\n// ABOVE it. The reader noticed within one read.\n// 2. No item may hardcode a live number. The old K11 text said \"two of this week's went\n// unmarked\" while the tiles, reading the same account, showed none unmarked in their window.\n// A number typed into prose goes stale the day after it is typed. Live figures arrive through\n// `Ctx` and are rendered by a function, or they are not stated.\n// 3. The $250 Bootcamp cohort is a decision about her customers' money and was sitting twelve\n// rows down in the work log rather than here. \"Wrong things promoted\", exactly.\n\nexport type Ctx = {\n unmarkedPupTalks?: number | null; // appointments with no showed/no-show mark yet, this window\n inquiriesPerWeek?: number | null; // live count, so the volume a YES commits her to is never typed\n // computed by facts.ts from the bridge journal. The typed version of this sentence was wrong in\n // all four of its numbers and understated the money by $4,572.\n squareSentence?: string | null;\n // Live, from a server-side tag filter over the WHOLE contact base. Never a scan size.\n puppyTagSentence?: string | null;\n // What the tagging step WOULD pick up, measured on the engine's last run. Null until it has run\n // one, so the page never implies a dry pass happened when none did.\n tagScanSentence?: string | null;\n};\n\nexport type Decision = {\n ref: string; // ledger row, e.g. \"K8\"\n ask: string; // the question, in Kim's vocabulary, ending in a question mark\n why: string | ((c: Ctx) => string); // what it unblocks or prevents\n // A function when the evidence contains a figure. A number in evidence is still a number,\n // and it drifts exactly like a number in prose does.\n evidence: string | ((c: Ctx) => string);\n ifYes?: string | ((c: Ctx) => string); // what saying yes costs. May depend on live figures.\n ifNothing: string; // what happens if she never answers. Honest, including \"nothing bad\".\n weight: \"blocking\" | \"worth doing\" | \"whenever\";\n liveNow?: boolean; // already affecting real customers today, as opposed to pending\n // v1.5. Three separate readers, independently, came to this page worrying about money and found\n // the only question about money filed last and folded away. Weight measures urgency; this\n // measures whether the reader will go looking for it. Money always shows.\n surface?: boolean;\n /** An extra paragraph computed at render time. Never a place to put a typed figure. */\n extra?: (c: Ctx) => string;\n};\n\n// v1.6, 14 Aug 2026, AFTER GO-LIVE. The follow-up system was switched from practice to live on the\n// evening of 11 August. This file did not notice for three days, and three of its cards went on\n// telling Kim the opposite while two real people were being messaged:\n// 1. K8, \"When do we do the switch-on together?\", was an answered question, and its `ifNothing`\n// (\"The new messages stay in practice mode and nobody is messaged by them\") was the single\n// most misleading sentence on her page. DELETED rather than reworded: a card whose question\n// has been answered by an event is not a card, it is a record, and records live in\n// worklog.ts. The go-live is written up there, dated, with evidence she can check herself.\n// 2. K1's `ifYes` said the wording \"still does not send until the switch-on above is scheduled\n// too\". It sends. Corrected. K1 is also no longer `blocking`: it carries a stated default\n// (\"Wednesday's corrections stand as given\"), which by finding 2 of v1.3 below makes it an\n// answered question, and nothing about a wording re-read holds up the email half.\n// 3. K12's `ifNothing` said \"Texting can still go live on its own\". Texting IS live on its own.\n// And WEIGHT_LABEL: `blocking` no longer means \"holds up go-live\", because nothing does. It\n// means the EMAIL half cannot start, which is true of exactly one item, K12. The enum name is\n// left alone on purpose; renaming a type to fix a label is how a rename becomes a refactor.\n//\n// v1.3, after the third stranger test, which read this file as well as the page. Four findings:\n// 1. The type stated the rule as \"what happens if she says yes AND if she says nothing\" and then\n// implemented only half of it. `ifYes` now exists and is filled wherever a yes has a cost.\n// 2. `weight: \"blocking\"` was applied to two items that do not block. An item carrying a stated\n// default is an answered question; a December deposit does not gate a puppy sequence. The\n// headline counts blockers, so mislabelling one puts a wrong number at the top of the page.\n// 3. The genuine email go-live blocker was in the ledger and NOT here, so a reader answering\n// every card would believe the runway was clear when the email half cannot deliver.\n// 4. The page detected \"already reaching customers\" by regex-matching this file's prose, so a\n// reword would have silently disabled the warning. It is a field now.\n\nexport const DECISIONS: Decision[] = [\n // [K8, \"When do we do the switch-on together?\", was removed on 14 Aug 2026. The switch-on\n // happened on the evening of 11 August, so the question had nothing left to ask, and the card\n // was telling Kim the messages \"stay in practice mode and nobody is messaged by them\" while\n // two real people were partway through them. It is not reworded and it is not silently\n // dropped: the event it was asking about is written up as a dated entry in worklog.ts, and the\n // fact that this page carried the wrong answer for three days is written up there too, under\n // \"my mistake\", where her page keeps my errors on purpose.]\n {\n ref: \"K1\",\n ask: \"The wording changes you asked for are in. Want a fresh read, or is Wednesday's answer the answer?\",\n why: \"On Wednesday you gave the wording its verdict and its corrections in one go: open message two on the welcome, say what a Pup Talk is rather than what it is not, drop the lines about what we will not do, and say \\\"going\\\" not \\\"getting on\\\", plus the hot-day water note and back-to-school for August. Every one of those went into the copy on 9 August and each is now pinned by its own automated check so it cannot drift back. The write-ups you hold were regenerated from the changed copy the same day.\",\n evidence: \"Both write-ups were generated from the live system rather than from a draft, so what you read is exactly what would send. Your Wednesday message is the answer of record; the 9 August regeneration carries your changes.\",\n // v1.4. This read \"roughly 190 new people a week\" while the page counted 186 four inches\n // above it. The volume a YES commits her to is the whole weight of the question, so it is\n // counted at render time or it is not stated as a number at all.\n // [was: \"It still does not send until the switch-on above is scheduled too.\" It sends. The\n // system went live on the evening of 11 August and these are the words real people have been\n // receiving since. Corrected 14 Aug 2026.]\n ifYes: \"Nothing else about the wording comes back to you. These are the words going out to real people now, so a change from you would land on every message that has not been sent yet, including the rest of the messages for anyone already partway through.\",\n ifNothing: \"Your Wednesday corrections stand as given and the copy stays exactly as regenerated.\",\n // [was: \"blocking\", when blocking meant \"holds up go-live\". Go-live has happened, and a card\n // whose ifNothing is a stated default was never a blocker by this file's own rule anyway.]\n weight: \"worth doing\",\n },\n {\n ref: \"K2\",\n ask: \"Which number should customers see, 912-348-8726 or 912-823-4382?\",\n why: \"It goes at the bottom of every message that leaves the system, so it needs to be the one you actually want ringing.\",\n evidence: \"Both numbers are live on your account and both are cleared for texting. On 4 August, only one of them was on your website footer: 912-348-8726.\",\n ifNothing: \"We use 912-348-8726, the one already on your website. This one has a default, so it does not hold anything up; it is here because it is your name on the message.\",\n weight: \"worth doing\",\n },\n {\n ref: \"KB1\",\n ask: \"Bootcamp deposits: you answered this on Wednesday. Anything to add, or is it closed?\",\n why: \"Your Wednesday answer is the answer of record: most people pay the deposit over the phone, the one or two who paid the wrong amount were corrected at drop off, everyone ultimately paid the right price, and the website payment was set up to go to PayPal rather than Square. So the earlier worry on this card, that money might have gone missing while the form said $250, is answered by you: nothing was underpaid. The form itself was fixed to $500 on 2 August and stays fixed.\",\n evidence: \"The wrong figure was found inside the booking form's own settings, corrected and published, and the live site was then searched end to end for '$250' with no hits left. Your Wednesday message about PayPal, the phone payments and nothing being underpaid is the answer of record; the payment matching this card used to ask for is no longer needed unless you want it.\",\n ifYes: \"If you ever want the belt-and-braces version, we match the 17 bookings against the payment records and hand you the list. Deciding to look is not deciding to chase.\",\n ifNothing: \"Closed on your say-so. The form is fixed and your answer stands.\",\n extra: (c) => c.squareSentence ? `Separately, on the same subject of money the records cannot place: ${c.squareSentence}` : \"\",\n weight: \"worth doing\",\n surface: true,\n },\n {\n ref: \"K6\",\n ask: \"Should people who have already booked keep getting the safety tips?\",\n why: \"Right now the follow-ups stop the moment somebody books. Some owners like the tips continuing; some find it odd to still be sold at after they said yes.\",\n evidence: \"Read from the sequence itself: booking is a stop condition on every path, including the slow track.\",\n ifNothing: \"They stop at booking, which is the safer of the two.\",\n weight: \"worth doing\",\n },\n {\n ref: \"K11\",\n ask: \"Can we ask the front desk to mark every Pup Talk showed or no-show?\",\n why: (c) =>\n c.unmarkedPupTalks\n ? `${c.unmarkedPupTalks} of the Pup Talks in the last 7 days ${c.unmarkedPupTalks === 1 ? \"has\" : \"have\"} no mark against ${c.unmarkedPupTalks === 1 ? \"it\" : \"them\"} yet, so the show-up figure on this page is better than the truth by up to that many. It is a ten second job at the desk.`\n : \"When one goes unmarked the show-up figure on this page comes out better than the truth, because an unmarked appointment is not counted as a miss. None are unmarked right now, and keeping it that way is a ten second job at the desk.\",\n evidence: \"Counted live from your calendar each time this page loads, not typed in here.\",\n ifYes: \"Nothing to build. It is a habit at the desk, and the number on this page stops flattering itself.\",\n ifNothing: \"The show-up figure drifts optimistic whenever one is missed, and this page keeps saying so. Nothing else is affected.\",\n weight: \"worth doing\",\n },\n {\n ref: \"K7\",\n ask: \"You have two review-request automations both switched on. Which one do you want to keep?\",\n why: \"You have two review-request workflows switched on at once, with near-identical names. We cannot read a workflow's steps through the interface we have, so we cannot promise you both actually fire, but two published copies is the usual shape of a customer being asked twice, and it is worth ten seconds of your time.\",\n evidence: \"Read from all 165 automations on 4 August: \\\"New Review Request WF\\\" and \\\"Update- New Review Request WF\\\" are both published. What we could NOT do is open either one and read its steps, because that call is not available to us. So this is two live copies, not a confirmed double send.\",\n ifNothing: \"Both stay switched on. If they do both fire, the double ask continues; it is not damaging, it just looks careless.\",\n weight: \"worth doing\",\n liveNow: true,\n },\n {\n ref: \"K12\",\n ask: \"The four domain lines: you said yes on Wednesday and asked for instructions. Ready for them on Upwork today?\",\n why: \"This is the real blocker on the email half, and on Wednesday you answered it: happy to add the four lines, just need to know how and where. Checked on 4 August, your domain tells the internet that Google and Wix are allowed to send email in your name, and nobody else. Until the four lines go in, every follow-up email would come from a server your domain does not stand behind, and a lot of them would land in spam. Texting is unaffected: that is verified separately and already works.\",\n evidence: \"Read from your domain's own public records. They list Google and Wix and nothing else. The settings needed are generated by your CRM and are four short lines of text. Your Wednesday yes is the answer of record; the step-by-step instructions for the Wix screen are written and come to you on Upwork.\",\n ifYes: \"You paste the four lines where the instructions show, it takes about ten minutes, and the emails can start going out alongside the texts that are already going out.\",\n // [was: \"Texting can still go live on its own.\" It did, on the evening of 11 August, and it is\n // running. The sentence was written before that and read afterwards as though nothing had\n // been switched on at all. Corrected 14 Aug 2026.]\n ifNothing: \"Texting carries on by itself, exactly as it is doing now. The emails cannot start, and this stays the one thing standing in their way.\",\n weight: \"blocking\",\n },\n {\n ref: \"K10\",\n ask: \"Costs against what it brings in: you said go ahead on Wednesday. The spend half now reads live. Want the walkthrough this week?\",\n why: \"You answered on Wednesday: \\\"I absolutely wanna know what all this costs against what it brings in, go ahead.\\\" Since 9 August the spend half is no longer waiting on anybody: Facebook granted the read permission, so the advertising card on this page now shows real dollars from the ad platform every time it loads. What the page still cannot show is the money coming back, because your CRM does not record a value on a sale. Closing that half is Amir's job and it is on his list, not yours.\",\n evidence: \"The spend connection was watched working on 9 August: the page read $671.72 and 159 started conversations for the last 7 full days straight from Facebook. The earning side is nearly blank in your CRM: 53 of your customer records carry a dollar value, $166,235.00 between them, and every one of those was last touched on 30 June, so nothing in the last six weeks has had a value put on it.\",\n ifYes: \"Half an hour together, real spend against real bookings, and the cost-per-lead for each campaign on paper in front of you.\",\n ifNothing: \"The spend keeps showing on this page either way. The what-it-brings-in half waits until the CRM records a value on a sale.\",\n weight: \"worth doing\",\n surface: true,\n },\n {\n ref: \"K13\",\n ask: \"Can we retire the access key you pasted into the Upwork thread on 31 July?\",\n why: \"It is a working key to your CRM sitting in a chat log. Nothing has gone wrong that we know of, and we have no way to tell whether anybody else has used it, which is exactly why it should not be sitting there. It is simply not where a key should live.\",\n evidence: \"The message was still in the thread on 4 August. On Wednesday evening you went to delete the key yourself and said you were not entirely sure it worked. That attempt is on record; what has not happened yet is anyone confirming the old key is actually dead, and until that check runs the honest state is: probably retired, not yet proven.\",\n ifYes: \"Two minutes, and one loose end closed.\",\n ifNothing: \"A working key to your customer list stays in a chat log that other people can be added to. Nothing has gone wrong so far, and nobody can promise it will not.\",\n weight: \"worth doing\",\n liveNow: true,\n },\n {\n ref: \"K14\",\n ask: \"Can we take the holiday boarding deposit automatically instead of by hand?\",\n why: \"You already have a product in your CRM called \\\"Holiday boarding deposit\\\" set at $50, fully configured, and it does not appear on a single order in the payment history we can see. Your boarding bookings go through the form on your website instead, so the CRM never gets the chance to take the money or record that it arrived. That is why somebody is checking by hand.\",\n evidence: \"Read from your own product list: \\\"Holiday boarding deposit\\\" and \\\"New Client Boarding Deposit\\\" both exist at $50, and not one order in your recent payment history references either.\",\n ifYes: \"Two sizes of job, and Amir will lay out both before anything is built: record the deposit against the customer automatically so you get a list rather than a memory, or take it as part of the booking so nobody can complete one without paying.\",\n ifNothing: \"It stays a manual check every holiday season.\",\n weight: \"worth doing\",\n },\n {\n ref: \"K15\",\n ask: \"You have five no-sale and tips follow-up sequences running, plus two auto-responders. Do you want me to go through them for overlap?\",\n why: \"They are all published and live. The one that looked accidental, \\\"Copy - Tips Ad campaign > Auto Responder\\\", you answered on 5 August: the copy is Milton's on purpose, and it answers on Facebook comments as well as in Messenger, so it stays exactly as it is. What is left of this question is smaller: whether Amir reads the five sequences so nobody can end up getting two sets of messages from you on the same afternoon.\",\n evidence: \"Read from all 165 automations on 4 August: seven published and one draft. Five are follow-up sequences; two are auto-responders and call routing, so the real number to review is nearer five. Your 5 August message is the answer of record on the copy workflow.\",\n ifYes: \"Amir reads all of them and tells you which are earning their place, before anything new is built.\",\n ifNothing: \"They keep running as they are, which is now the known-good state you described.\",\n weight: \"worth doing\",\n },\n {\n ref: \"K9\",\n ask: \"Would you tell us a story or two from the kennel?\",\n why: \"There are eight places in the follow-up messages where a real thing that happened to a real dog would land far better than general advice. They are written to read perfectly well empty, and they are empty today, because made up stories are not something we will put in your name.\",\n evidence: \"The eight places are marked in the sequence you have already read. Each one has a fallback line that reads normally with no story in it, which is what is running now.\",\n ifNothing: \"The messages read exactly as you have already seen them, which costs you nothing.\",\n weight: \"whenever\",\n },\n {\n ref: \"K16\",\n ask: \"Do you want the one untranscribed call from 4 August looked at, or is the answer enough?\",\n why: \"Mostly answered on 6 August. No transcript exists on any call older than about three months, and since then almost every call with speech has one. What is not settled is why the old ones have none: either transcription was switched on around 11 May, or transcripts are deleted once they reach about ninety days. Both look the same from here, and the second one would mean you are quietly losing call history every month. One query a week from now tells us which, and it costs nothing.\",\n // [was, twice over: first \"Every call in your account was checked\" (it was 62 of them), then\n // \"the writing-down step has simply never been switched on\". That second claim was inferred\n // from the API showing no transcript on any of the 62 call records, and the inference was\n // wrong: the API simply does not carry transcripts on those records. On 5 August a call from\n // that same morning was opened in the CRM and its transcript was watched rendering, word by\n // word. Transcription is on. The claim below is what has actually been observed.]\n evidence:\n \"Sixty-two of your calls were checked from your most recently active conversations: 54 carry a full audio recording, about two and a quarter hours of it, and the recordings play. The 8 without one were calls nobody answered. Then a call from the morning of 5 August was opened directly in the CRM and its written transcript was watched rendering, and a second call from 4:54 that same afternoon shows its transcript in the CRM as well, so transcription is on and working at least sometimes. What has not been found yet is a call that is missing its transcript, which is why your report matters: one example from you of a call where the transcript used to be there, or should be, pins down the pattern in minutes.\",\n ifYes:\n \"Point at one call where the transcript is missing, or tell us roughly when they disappeared for you, and the comparison between that call and the transcribed one from that morning does the rest: same number or different, human or Chloe, long or short, before or after a settings change.\",\n ifNothing:\n \"Nothing breaks. Recording keeps working and at least some calls keep getting transcripts, but the ones that are missing stay a puzzle solved by trial and error instead of by one example from you.\",\n weight: \"worth doing\",\n },\n];\n\nexport const WEIGHT_ORDER: Record = { blocking: 0, \"worth doing\": 1, whenever: 2 };\n// [was: blocking: \"Holds up go-live\". Nothing holds up go-live any more, because it happened on\n// the evening of 11 August. What the label now marks is the one half of the system that still\n// cannot start: email. Corrected 14 Aug 2026.]\nexport const WEIGHT_LABEL: Record = {\n blocking: \"Holds up the email half\",\n \"worth doing\": \"Worth doing\",\n whenever: \"Whenever you like\",\n};\nexport function sortedDecisions(ds: Decision[] = DECISIONS): Decision[] {\n return [...ds].sort((a, b) => WEIGHT_ORDER[a.weight] - WEIGHT_ORDER[b.weight]);\n}\nexport const blockingCount = (ds: Decision[] = DECISIONS) => ds.filter((d) => d.weight === \"blocking\").length;\n/** Resolve a `why` that may depend on live figures. */\nexport const whyText = (d: Decision, c: Ctx): string => (typeof d.why === \"function\" ? d.why(c) : d.why);\n/** Same treatment for ifYes: a volume figure must be counted, never typed. */\nexport const ifYesText = (d: Decision, c: Ctx): string | undefined =>\n d.ifYes == null ? undefined : (typeof d.ifYes === \"function\" ? d.ifYes(c) : d.ifYes);\nexport const extraText = (d: Decision, c: Ctx): string => (d.extra ? d.extra(c) : \"\");\n/** Evidence gets the same treatment as why/ifYes: a figure in it is computed, never typed. */\nexport const evidenceText = (d: Decision, c: Ctx): string =>\n typeof d.evidence === \"function\" ? d.evidence(c) : d.evidence;\n\n\n=====FILE engine/deposits-cron.ts =====\n// THE HOLIDAY DEPOSIT REFRESH, ON A SCHEDULE. v1.0, 6 Aug 2026.\n//\n// WHY IT IS ITS OWN FILE AND NOT A LINE IN main.ts. main.ts is hard-capped at 80,000 characters\n// and has 679 left. Squeezing this in would mean deleting something that is already load-bearing\n// to make room for something new, on the entry point that runs Kim's follow-up system. A second\n// scheduled file costs nothing and cannot take the engine down with it.\n//\n// IT ONLY READS. Everything it does is inside runCollection(), which reads two calendars and some\n// contact notes and writes one blob. There is no path from here to a message, a tag or a customer.\n//\n// IT NEVER SHOUTS. If the CRM is unreachable this logs and returns. The dashboard already knows\n// how to say \"last checked N hours ago\", so a missed run degrades into a visibly older timestamp\n// rather than into an alarm or, worse, an empty list presented as fact.\nimport { runCollection, refreshIfDue, ATTEMPT_KEY, BLOB_KEY, type DepositBlob, type DepositRow } from \"./deposits.ts\";\n\nexport default async function (): Promise {\n try {\n // THE SAME GATE main.ts USES, through the same function, so the two cannot drift.\n const blob = (await import(\"https://esm.town/v/std/blob\")).blob;\n const g = await refreshIfDue(() => blob.getJSON(ATTEMPT_KEY) as any, () => runCollection(false, \"deposits-cron\"), Date.now());\n if (!g.ran) { console.log(`[deposits] ${g.why}`); return; }\n const o = (await blob.getJSON(BLOB_KEY)) as DepositBlob | null;\n if (!o) { console.log(`[deposits] ${g.why}, and nothing is stored`); return; }\n const worth = (o.rows ?? []).filter((x: DepositRow) => x.state === \"none_seen\" || x.state === \"partial\").length;\n console.log(`[deposits] ${o.rows.length} stay(s), ${worth} worth checking, ${o.readFailures} unreadable, drop-off calendars ${o.calendarsRead}/${o.calendarsAsked}, pick-up calendars ${o.pickupsRead}/${o.pickupsAsked}`);\n } catch (e) {\n // A scheduled job that throws on val.town shows up as a failed run and pages nobody usefully.\n // The honest outcome of a failed refresh is an older timestamp on the page, which is visible.\n console.log(`[deposits] refresh failed: ${String(e).slice(0, 200)}`);\n }\n}\n\n\n=====FILE engine/deposits.ts =====\n// HOLIDAY DEPOSIT COLLECTOR. The only part of this feature that touches her CRM. v1.0, 6 Aug 2026.\n//\n// WHY IT IS A SEPARATE FILE. holiday-deposits.ts holds all the judgement and a test asserts that\n// it contains no fetch() and no write verb at all. That assertion is only worth something if the\n// network code lives somewhere else, so it lives here. This file fetches and stores; it decides\n// nothing. Every decision is made by a function imported from the module that cannot reach the\n// network.\n//\n// WHAT IT DOES, IN ORDER\n// 1. asks both Boarding Drop Off calendars for the events inside this season's deposit windows\n// 2. groups them into stays (one customer, one day, however many dogs)\n// 3. reads each of those customers' notes, which is where Square money lands\n// 4. writes the answer into the `holiday_deposits` blob\n// The dashboard renders that blob and never repeats any of this, so Kim's page stays fast and\n// cannot be broken by a slow CRM.\n//\n// GET ONLY. Every request in here is a GET. There is no code path that tags, messages, moves or\n// updates anybody, and there is no argument that makes one appear.\n//\n// A FAILED READ IS NOT A ZERO. If a customer's notes cannot be read, that customer is recorded as\n// unknown, with the reason, and stays unknown all the way to Kim's screen. The one thing this\n// feature must never do is turn a network hiccup into \"this person has not paid\".\n//\n// ?k= the stored answer, as JSON\n// ?k=&run=1 re-collect from the live CRM, then store and return it\ndeclare const Deno: { env: { get(k: string): string | undefined } };\nif (typeof (globalThis as any).Deno === \"undefined\") {\n (globalThis as any).Deno = { env: { get: (k: string) => (globalThis as any).process?.env?.[k] } };\n}\nimport {\n holidayWindows, seasonYear, groupIntoStays, parseSquarePayments, statusFor, feedLooksDead,\n depositSentence, paymentsNearStay, statusesForCustomer, shiftDays, businessDay, type CalEvent, type Payment, type StayStatus,\n} from \"./holiday-deposits.ts\";\n\nconst GHL = \"https://services.leadconnectorhq.com\";\nconst LOC = \"BQHJ19uohldYe3eqA0bl\";\n// Both drop-off calendars. One customer appears on BOTH of these in her live data, which is why\n// the union is taken rather than whichever one someone remembers first.\nexport const BOARDING_CALENDARS = [\"wS5N8WN4BbzznaLjEg1N\", \"ZmmjQJszkRMUltfEbumB\"];\n// The matching PICK UP calendars. A drop-off appointment is a ten minute handover slot, so the\n// only place the length of a stay is written down is here. Read on 6 Aug: Ghost and Chewy drop\n// off on 25 Nov and are collected on the 28th, and nothing on the drop-off calendar says that.\nexport const PICKUP_CALENDARS = [\"1FnbK7pQp1ViZWIzX9SR\", \"bN6wWGJa0qKq0QGRg4CC\"];\n// How far past the last window to look for the pick-up that ends a stay running over New Year.\nexport const LOOKAHEAD_DAYS = 30;\nexport const BLOB_KEY = \"holiday_deposits\";\n// How far before the first holiday window to look for bookings. A stay that starts earlier and\n// runs into the window is still a holiday stay; the query filters on drop-off time, so it has to\n// be fetched before it can be judged.\nexport const LOOKBACK_DAYS = 21;\n// The notes endpoint takes NO paging parameters (it 422s on limit and on offset), so the only\n// defence against a silently truncated list is to treat a response at the cap as unreadable.\n// 100 is the usual GHL page size; the largest real list across 60 sampled contacts was 3.\nexport const NOTES_UNPAGEABLE_CAP = 100;\n// How often the list is refreshed off the engine's schedule.\nexport const REFRESH_EVERY_MS = 3_600_000;\n// The ATTEMPT stamp, written on every try. Gating on the stored list instead means a run that\n// legitimately declines to store — no credential, no calendar, everybody unreadable, an empty\n// season held back — leaves the gate open, and the engine then retries every 15 minutes forever\n// against a CRM that is already unwell.\nexport const ATTEMPT_KEY = \"holiday_deposits_attempt\";\n\n/** Is it time to look again? Pure, so the rule can be tested instead of inspected as text.\n * An unreadable or missing stamp opens the gate: never having looked, and not being able to tell\n * when we last looked, both mean look now. A NaN must not close it forever. */\n/** THE WHOLE \"should I collect now\" STEP, in one place, so both schedules run the same code and a\n * test can watch it decide. [was: hand-rolled in main.ts and again in deposits-cron.ts, checked\n * by greps for the word `needsRefresh`. A mutation that called needsRefresh and threw the answer\n * away — collecting from her CRM on every tick — passed all three of those greps.] */\nexport async function refreshIfDue(\n readStamp: () => Promise<{ at?: string } | null>,\n run: () => Promise<{ ok: boolean; error?: string }>,\n nowMs: number,\n): Promise<{ ran: boolean; why: string }> {\n const last = await readStamp().catch(() => null);\n if (!needsRefresh(last?.at, nowMs)) return { ran: false, why: \"not due yet\" };\n const r = await run();\n return { ran: true, why: r.ok ? \"collected\" : `not stored: ${r.error ?? \"unknown\"}` };\n}\n\nexport function needsRefresh(lastAttemptAt: string | null | undefined, nowMs: number, everyMs = REFRESH_EVERY_MS): boolean {\n if (!lastAttemptAt) return true;\n const t = Date.parse(String(lastAttemptAt));\n if (!Number.isFinite(t)) return true;\n return nowMs - t > everyMs;\n}\n\n/** Whether a finished collection may replace what is stored. Pure, so all four refusals are\n * testable; they used to be reachable only through the live blob and were checked as regexes. */\nexport function decideStore(out: DepositBlob, prev: DepositBlob | null, force = false): { store: boolean; error?: string } {\n // A collection that could not read a single calendar is NOT stored: overwriting a good answer\n // with an empty one would show Kim \"no holiday stays booked\" the first time her CRM blinked.\n if (out.calendarsRead === 0) return { store: false, error: \"no calendar answered, so the stored list was left alone\" };\n // NOR a collection in which every single row is unknown. The calendars answered, so the guard\n // above lets it through, and the blob would be replaced with a page of \"could not check\" AND a\n // fresh timestamp — the content gets worse while the page claims to have just been updated.\n if (out.rows.length > 0 && out.rows.every((r) => r.state === \"could_not_check\")) {\n return { store: false, error: \"nobody's payments could be read, so the stored list was left alone\" };\n }\n // NOR a run that has gone from a real list to nothing. A renamed calendar answers 200 with an\n // EMPTY events array, which is well formed and passes both guards above; in December that\n // silently replaces her shortlist with \"nothing to check\". A season really can empty out, so\n // this is not permanent: it holds the old list, says why, and the card starts ageing visibly.\n if (!force && out.rows.length === 0 && (prev?.rows?.length ?? 0) > 0) {\n return { store: false, error: `the boarding calendars answered but returned no holiday bookings at all, where the stored list has ${prev!.rows.length}. That is usually a renamed calendar rather than an empty season, so the stored list was left alone. Re-run with force=1 to accept it.` };\n }\n // NOR A RUN THAT SEES LESS THAN THE STORED ONE DID.\n //\n // This is the hole the three guards above left open, and it is the worst of the four because it\n // is silent. There are two boarding calendars precisely because one customer can appear on\n // either; the row list is their union. If ONE calendar fails — a transient 5xx, a revoked scope,\n // a rename — `calendarsRead` comes back 1 of 2, every guard above passes, and the partial union\n // is written straight over the complete one. The customers who only ever appear on the calendar\n // that failed do not become \"could not check\" rows. Their bookings were never fetched, so they\n // get NO ROW AT ALL: they vanish off Kim's shortlist entirely, under a banner that says one\n // calendar did not answer but cannot say who is missing. There is no retry anywhere in this\n // file, so one blip is enough. Found on 7 August; nothing guarded it.\n //\n // Compared by how many did NOT answer, not by the raw count, so genuinely deleting a calendar\n // (2 asked and read, then 1 asked and read) still stores.\n const missedNow = (out.calendarsAsked - out.calendarsRead) + (out.pickupsAsked - out.pickupsRead);\n const missedBefore = prev ? (prev.calendarsAsked - prev.calendarsRead) + (prev.pickupsAsked - prev.pickupsRead) : 0;\n if (!force && prev && missedNow > missedBefore) {\n return { store: false, error: `this run could not read ${missedNow} calendar(s) where the stored list was missing ${missedBefore}, so it sees fewer bookings than what is already saved. A shorter list with a newer timestamp is worse than the saved one going visibly stale, so the stored list was left alone.` };\n }\n return { store: true };\n}\nconst KEY_SHA256 = \"48cd12465712045f70247da1689eeb198a4ce2d98416d8e52fb844581f044f15\";\n\nasync function sha256Hex(s: string): Promise {\n const b = await crypto.subtle.digest(\"SHA-256\", new TextEncoder().encode(s));\n return [...new Uint8Array(b)].map((x) => x.toString(16).padStart(2, \"0\")).join(\"\");\n}\nasync function authorised(k: string): Promise {\n const expected = Deno.env.get(\"NURTURE_ADMIN_KEY_SHA256\") || KEY_SHA256;\n const got = await sha256Hex(k);\n if (got.length !== expected.length) return false;\n let d = 0;\n for (let i = 0; i < got.length; i++) d |= got.charCodeAt(i) ^ expected.charCodeAt(i);\n return d === 0;\n}\nasync function blobMod() { return (await import(\"https://esm.town/v/std/blob\")).blob; }\nasync function token(): Promise {\n const env = Deno.env.get(\"GHL_TOKEN\");\n if (env) return env;\n const cfg = await (await blobMod()).getJSON(\"puppy_config\").catch(() => null);\n return (cfg as any)?.ghlToken;\n}\n\n// The single door to the network, and it only knows one verb. Named so that a reader checking\n// \"can this thing write to her account\" gets their answer from the signature.\nasync function getJson(path: string, version: string, tok: string): Promise {\n const r = await fetch(`${GHL}${path}`, {\n method: \"GET\",\n // curl's UA is not decoration: her CRM rejects requests without it.\n headers: { Authorization: `Bearer ${tok}`, Version: version, \"User-Agent\": \"curl/8.5.0\" },\n signal: AbortSignal.timeout(20_000),\n });\n if (!r.ok) throw new Error(`HTTP ${r.status}`);\n return r.json();\n}\n\nexport type DepositRow = {\n contactId: string;\n name: string;\n day: string;\n until: string;\n dogs: string[];\n dogCount: number;\n window: string;\n state: StayStatus[\"state\"];\n amountSeen: number;\n note: string;\n};\nexport type DepositBlob = {\n at: string;\n season: number;\n windows: { name: string; from: string; to: string }[];\n rows: DepositRow[];\n sentence: string;\n feedDead: boolean;\n readFailures: number;\n calendarsRead: number;\n calendarsAsked: number;\n pickupsRead: number;\n pickupsAsked: number;\n};\n\nconst dayMs = (d: string) => Date.parse(`${d}T00:00:00Z`);\n\n/** Every page of a contact's notes, or null if we could not be sure we had them all.\n * Returning a SHORT list would be indistinguishable from a customer with no payments, so a read\n * that cannot be completed returns null and the customer is reported as unknown. */\nasync function allNotes(io: { get: (p: string, v: string) => Promise }, contactId: string): Promise {\n // NO QUERY STRING. [was: `?limit=100&offset=N`, written to fix a truncation worry. This endpoint\n // rejects both: it answers 422 \"property limit should not exist\" to any parameter at all, so\n // every customer became a failed read. It shipped, and both live customers came back \"could not\n // check\" ninety seconds later. It was caught by running it against her account, not by the 250\n // assertions that stayed green — the fixtures answered a URL the real CRM refuses.]\n const d = await io.get(`/contacts/${contactId}/notes`, \"2021-07-28\");\n // A 200 with no notes ARRAY is a response we do not understand, not a customer with no notes.\n if (!Array.isArray(d?.notes)) return null;\n // The endpoint takes no paging parameters, so it returns the lot or it does not. If a response\n // ever comes back at exactly the cap, we cannot tell a full list from a truncated one, and an\n // unknown is the only honest answer. Across 60 sampled contacts on 6 Aug the largest was 3.\n if (d.notes.length >= NOTES_UNPAGEABLE_CAP) return null;\n return d.notes;\n}\n\n/** COLLECT. `io` is injected so the whole thing can be run against fixtures in a test without a\n * network, and so there is exactly one place in this file that can talk to her CRM. */\nexport async function collect(\n io: { get: (path: string, version: string) => Promise },\n todayIso: string,\n): Promise {\n const season = seasonYear(businessDay(todayIso));\n const windows = holidayWindows(season);\n const from = windows[0].from, to = windows[windows.length - 1].to;\n\n // ---- the bookings ----\n const events: CalEvent[] = [];\n let calendarsRead = 0;\n for (const cal of BOARDING_CALENDARS) {\n try {\n // LOOK BACK BEFORE THE WINDOW. A dog dropped off on 19 December and collected on the 27th\n // has boarded over Christmas, but the query filters on the drop-off time, so without this\n // reach-back those bookings are never even fetched. windowForRange decides membership.\n // The SAME range as the pick-ups on purpose. [was: drop-offs stopped at the end of the\n // window while pick-ups reached 30 days past it, so for every stay at the tail of the season\n // the customer's own next booking was never fetched. `nextDrop` came back undefined, the\n // \"hard upper bound\" was structurally blind exactly where it mattered, and a 30 Dec stay\n // swallowed the 15 Jan pick-up of a 10 Jan booking — rendering \"Dec 30 to Jan 15\" and\n // letting a January payment settle the holiday deposit. Out-of-window bookings fetched this\n // way are filtered out by the overlap rule; they are here to be next-drop-off markers.]\n const q = `locationId=${LOC}&calendarId=${cal}&startTime=${dayMs(shiftDays(from, -LOOKBACK_DAYS))}&endTime=${dayMs(shiftDays(to, LOOKAHEAD_DAYS))}`;\n const d = await io.get(`/calendars/events?${q}`, \"2021-04-15\");\n // A 200 that does not carry an events ARRAY is not an empty calendar, it is a response we do\n // not understand. [was: `d?.events ?? []`, which counted a renamed key, a partial payload or\n // a stale calendarId as \"read, and she has no bookings\" — and stored that over a good list.]\n if (!Array.isArray(d?.events)) throw new Error(\"no events array in the response\");\n for (const e of d.events) events.push(e as CalEvent);\n calendarsRead++;\n } catch { /* one calendar down is reported below, never silently treated as \"no bookings\" */ }\n }\n // The pick-ups. A calendar that does not answer here is NOT fatal: without it a stay is judged\n // on its drop-off day alone, which is exactly what the module did before, so the list gets\n // smaller rather than wrong. It is reported all the same.\n const pickups: CalEvent[] = [];\n let pickupsRead = 0;\n for (const cal of PICKUP_CALENDARS) {\n try {\n const q = `locationId=${LOC}&calendarId=${cal}&startTime=${dayMs(shiftDays(from, -LOOKBACK_DAYS))}&endTime=${dayMs(shiftDays(to, LOOKAHEAD_DAYS))}`;\n const d = await io.get(`/calendars/events?${q}`, \"2021-04-15\");\n if (!Array.isArray(d?.events)) throw new Error(\"no events array in the response\");\n for (const e of d.events) pickups.push(e as CalEvent);\n pickupsRead++;\n } catch { /* reported on the card: a stay is then judged on its drop-off day alone */ }\n }\n\n const stays = groupIntoStays(events, windows, pickups);\n\n // ---- the money ----\n const rows: DepositRow[] = [];\n // KEYED BY CUSTOMER. The kill switch's floor is written in customers (\"five people with no card\n // payment\"), so a customer with five holiday drop-offs must count once, not five times.\n const perCustomer = new Map();\n let readFailures = 0;\n\n // BY CUSTOMER, not by stay, so one $50 deposit cannot settle two of the same person's bookings.\n const byCustomer = new Map();\n for (const s of stays) {\n const list = byCustomer.get(s.contactId) ?? [];\n list.push(s);\n byCustomer.set(s.contactId, list);\n }\n\n for (const [contactId, own] of byCustomer) {\n let pays: Payment[] | null = null;\n try {\n const notes = await allNotes(io, contactId);\n // A 200 with no notes ARRAY is a response we do not understand, not a customer with no\n // notes. [was: `d?.notes ?? []`, so a rate-limit soft-fail or a changed response shape\n // rendered as \"No Square payment is on file\" — a confident finding built on nothing.]\n pays = notes === null ? null : parseSquarePayments(notes);\n } catch { pays = null; }\n if (pays === null) readFailures++;\n\n let nm = \"\";\n try {\n const c = await io.get(`/contacts/${contactId}`, \"2021-07-28\");\n const ct = c?.contact ?? c;\n nm = [ct?.firstName, ct?.lastName].filter(Boolean).join(\" \").trim() || ct?.contactName || \"\";\n } catch { nm = \"\"; }\n // A name we could not read is shown as that, not as a blank that reads like a bug.\n const name = nm || \"name not readable\";\n\n // WHAT THE KILL SWITCH IS ALLOWED TO SEE: money in the period this run is judging, for\n // customers we actually searched. A stay with no booking date has NO searchable window, so\n // paymentsNearStay returns a structural empty for it; counting that as \"we looked and saw no\n // money\" let one missing field push the sample over the floor and black out the whole card.\n if (pays !== null && own.some((s) => s.bookedAt)) {\n const near = own.filter((s) => s.bookedAt).flatMap((s) => paymentsNearStay(s, pays!));\n perCustomer.set(contactId, near);\n }\n\n for (const st of statusesForCustomer(own, pays)) {\n rows.push({\n contactId, name, day: st.stay.day, until: st.stay.until, dogs: st.stay.dogs,\n dogCount: st.stay.dogCount, window: st.stay.window, state: st.state, amountSeen: st.amountSeen, note: st.note,\n });\n }\n }\n rows.sort((a, b) => a.day.localeCompare(b.day));\n\n const feedDead = feedLooksDead(perCustomer);\n const statuses: StayStatus[] = rows.map((r) => ({\n stay: { contactId: r.contactId, day: r.day, until: r.until, dogs: r.dogs, dogCount: r.dogCount, bookedAt: null, window: r.window },\n state: r.state, amountSeen: r.amountSeen, note: r.note,\n }));\n\n return {\n at: todayIso, season, windows, rows,\n sentence: depositSentence(statuses, feedDead),\n feedDead, readFailures,\n calendarsRead, calendarsAsked: BOARDING_CALENDARS.length,\n pickupsRead, pickupsAsked: PICKUP_CALENDARS.length,\n };\n}\n\n/** ONE PLACE where a collection is run and stored, so the scheduled run and the manual run cannot\n * drift apart. deposits-cron.ts calls this; so does the endpoint below. */\nexport async function runCollection(force = false, source = \"unknown\"): Promise<{ ok: boolean; error?: string; out?: DepositBlob }> {\n const b = await blobMod();\n // Stamped BEFORE the work, so a collection that fails, times out or declines to store still\n // closes the gate for an hour rather than being retried on every tick.\n // WITH WHO STARTED IT. Two schedules can reach this — the engine's interval and deposits-cron.ts\n // — plus a person hitting the endpoint. On 6 Aug the list refreshed at 20:49 with nobody\n // triggering it, which was the first autonomous refresh ever observed, and there was no way to\n // tell WHICH schedule did it. \"It works\" and \"which one works\" are different facts.\n await b.setJSON(ATTEMPT_KEY, { at: new Date().toISOString(), source }).catch(() => {});\n const tok = await token();\n if (!tok) return { ok: false, error: \"no CRM credential resolved, so nothing was collected\" };\n const out = await collect({ get: (p, v) => getJson(p, v, tok) }, new Date().toISOString());\n const prev = (await b.getJSON(BLOB_KEY).catch(() => null)) as DepositBlob | null;\n const d = decideStore(out, prev, force);\n if (!d.store) return { ok: false, error: d.error, out };\n await b.setJSON(BLOB_KEY, out);\n return { ok: true, out };\n}\n\nexport default async function (req: Request): Promise {\n const url = new URL(req.url);\n if (!(await authorised(url.searchParams.get(\"k\") || \"\"))) {\n return new Response(\"Not found\", { status: 401, headers: { \"content-type\": \"text/plain\" } });\n }\n const json = (o: unknown, status = 200) =>\n new Response(JSON.stringify(o, null, 2), { status, headers: { \"content-type\": \"application/json\", \"cache-control\": \"no-store\" } });\n\n try {\n if (url.searchParams.get(\"run\") !== \"1\") {\n const b = await blobMod();\n const stored = await b.getJSON(BLOB_KEY).catch(() => null);\n // THE ATTEMPT STAMP COMES BACK TOO, and reading it does not write it. Without this, \"the\n // list has not moved\" is ambiguous between \"the schedule never tried\" and \"it tried and\n // declined to store\" — and those need completely different fixes. Every observation of the\n // refresh so far has been unable to tell them apart.\n const attempt: any = await b.getJSON(ATTEMPT_KEY).catch(() => null);\n return json({ ...(stored ?? { at: null, rows: [], sentence: \"This has not been collected yet.\" }),\n lastAttemptAt: attempt?.at ?? null,\n lastAttemptBy: attempt?.source ?? null,\n refreshDueAt: attempt?.at && Number.isFinite(Date.parse(attempt.at))\n ? new Date(Date.parse(attempt.at) + REFRESH_EVERY_MS).toISOString() : null });\n }\n const r = await runCollection(url.searchParams.get(\"force\") === \"1\", \"endpoint\");\n return r.ok ? json(r.out) : json({ error: r.error, ...(r.out ?? {}) }, 503);\n } catch (e) {\n return json({ error: String(e).slice(0, 500) }, 500);\n }\n}\n\n",[561],"a85f8b1c-e9c7-4b44-91ca-5b692f8b339f","SOURCE-BUNDLE.part39.txt","27770c9c-9832-11f1-b97c-1607ee4eb77e",1088,["D",1786801895125],"THE DOGS SPOT — SOURCE BUNDLE (part 39 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (5 of 116 files)\n handover/PLAN-TO-FINISH.md 13923 bytes fcc0735a2d00\n handover/SEND-TO-KIM.txt 6320 bytes 6529bd33d5cf\n handover/REPLY-AUG5.txt 10977 bytes 43d7d92f357b\n handover/REGISTER-AUG5.md 2928 bytes f2ef80135b0b\n handover/AMIR_TODO.md 1489 bytes 4c4d197c3c85\n\n================================================================================================\n=====FILE handover/PLAN-TO-FINISH.md =====\n# What is left, in the order it has to happen\n\nUpdated 5 August 2026, 11:50, after a night of work while you were on shift. Everything here is\neither a thing I build or a door you open.\n\n---\n\n## What changed while you were out\n\n**The test suite is back, and bigger than it was.** Deliberately not quoting a number here, because\na number in a document is a number that goes stale: run `node tests/run-all.mjs` and it tells you.\nThe part that matters is `node tests/negative-controls.mjs`. Each control breaks the code on\npurpose, in a temporary copy, and demands a *named* test go red. If the wrong test catches it, or\nnothing does, the control fails. That is the thing we did not have when three fake checks shipped.\nFour of the controls exist because they caught one of my own checks lying.\n\n**It survives a reclaim now.** `handover/SOURCE-BUNDLE.part{1,2,3}.txt` holds every file that is\nnot already on val.town, and the same three parts are stored *on the val* as inert files. The\nrestore command is in the header of each part, and I have actually run it into an empty folder and\ndiffed the result: byte identical, every file. `scripts/build.mjs` and `scripts/deploy.mjs` now\ncarry everything that used to live only in my head, including the two traps that cost time before:\nmain.ts is called `puppy_path_v1.1.ts` locally, and val.town serves you a **cached** copy after a\nwrite, so a verify-by-read straight after a deploy shows the old hash and looks like a failure.\n\n### Four real defects found and fixed\n\n1. **The watchdog was reporting different money from the dashboard.** It said 35 counter sales\n worth $23,463.99. The dashboard said 40 worth $28,035.99. I re-derived it a third time, from\n the raw journal, in Python, without looking at either implementation: **40 is right**. The\n watchdog was skipping any row that carried an email or phone, and it was subtracting a count of\n journal *rows* from a count of *payments* to get its \"unresolvable\" figure. Two different units,\n one subtraction. It now imports the same function the dashboard uses, so they cannot disagree\n again.\n\n2. **The watchdog was set to look once a day. Now hourly. DONE, no longer yours.**\n I wrote in the first version of this file that its timer \"has never fired\". That was wrong, and\n wrong in two separate ways, both of which are worth reading because they are the same mistake\n twice.\n\n Opening the schedule showed **Runs every 1 days** — deliberately, by you, a week ago (val.town\n still has the chat: *\"can you set the watchdog to daily on...\"*). So the timer was firing\n perfectly, once every 24 hours. A problem starting just after it looked could sit unnoticed\n until the next day, while the thing it watches runs hourly. **Changed to hourly. Confirmed on\n the schedule screen: \"Runs every 1 hrs\".**\n\n Then it still reported no scheduled runs, and I nearly concluded a second time that the timer\n was dead. It was not. **The counter I had built that morning was broken.** I had assumed\n val.town calls the scheduled function with no arguments; it passes one of its own, so my\n \"is this a scheduled run\" check was false every single time. The scheduled runs were in the\n plain run record one line from where I was looking. Fixed by deciding it the other way round:\n only the manual endpoint says so, everything else is scheduled. **Both directions have now been\n watched working** — a scheduled run recorded as scheduled, a hand-started one as by hand.\n\n Kim's page reads **\"Everything we run is healthy\"** for the first time.\n\n3. **The page was quoting my button presses back to Kim as the watchdog's schedule.** It said\n \"left to itself it runs about every 95 minutes\". That number was honestly measured off the\n wrong thing. Scheduled and manual runs are recorded separately now, and the page says plainly\n which it is looking at. It is in the work log as my mistake, because it was.\n\n4. **A check passed on my own comment.** `D2b.1` forbade a call, I removed the call, and wrote a\n `[was: ...]` note above it naming the call I had removed. The test matched the note and stayed\n green. Every structural check now reads the file with comments stripped, and there is a control\n that puts the forbidden text *only* inside a comment and demands the test stay green.\n\n### The go-live blocker is no longer blocked, and the third switch is built\n\n**I was wrong that this needed a new scope.** I tested a tag write and a tag delete against my own\ntest contact on the token we already have: both work, HTTP 201 and 200. The `locations/tags.readonly`\nscope only lets me *list* the account's tag vocabulary. It was never in the way.\n\nSo the tagging is built, and it is running now:\n\n- `engine/puppy-detect.ts` decides who counts as a puppy inquiry, from what they wrote when they\n got in touch. It **cannot apply a tag** and that is structural rather than a promise: the file\n contains no fetch, no client, no POST. A test asserts it and a negative control adds a fetch call\n and demands the test go red.\n- The engine calls it once per run, in **both** modes, and writes the counts down. Kim's page shows\n them, with a staleness line if the pass ever stops.\n- A full dry pass over 1,200 contacts is in `handover/Puppy-tagging-candidates.xlsx`: **39 clear,\n 55 probable, 552 not a puppy, 554 with nothing written down to judge by.** Nothing tagged.\n\n**My first version of it would have signed up three people who should not have been.** A man asking\nto *buy* a puppy, a woman *rehoming* her older dogs, and a dog described as \"3 years and 4 months\nold\" read as four months. Each is a rule now, each rule has a test, each test has a control.\n\n**Then my own test caught the years bug still present in the rewrite.** The pattern wanted\n\"3-year-old\"; \"3 years and 4 months old\" puts the word \"old\" after the months, so it fell through\nto the months branch. Fixed and pinned.\n\n**One decision is Kim's, not ours.** A one-year-old dog sits exactly on the boundary and there are\na lot of them. Her slow track covers the teenage stage, so they may well belong. It is on her page.\n\n### Two more findings, late on\n\n**Her knowledge base was edited at 02:38 this morning and nothing was watching it.** That is 22:38\nher time, so it is very likely Kim herself, and if so it is exactly what should happen. But the\nconsolidated knowledge base is what Chloe answers customers from — it carries the no-training-prices\nrule, the appointment-only rule, the no-grooming rule and \"Pup Talk\" — and we have been watching her\n165 automations for changes since 4 August while not watching the documents that decide what her\nbusiness says. The watchdog now watches both. The comparison lives in `engine/registry-diff.ts` with\nits own tests, so it is not another check that has only ever been seen not firing.\n\n**The knowledge base IS readable through the API.** The master handoff says it is UI-only; that is\nwrong, or it has changed. `GET /knowledge-base/?locationId=…` lists all eight, and `GET\n/knowledge-base/{id}` gives names, timestamps and a count of what is inside. The document *text* is\nstill not exposed, so **step 4, the \"discovery call\" wording sweep, still needs the UI** — but we now\nknow exactly what to open: the consolidated base holds 9 items (7 rich text, 1 URL, 1 table).\n\n### Two things that are better than they were\n\n- **The go-live blocker is now counted live.** The page used to say \"1,200 of your most recent\n contacts were checked\". That was a scan size dressed as an answer. GoHighLevel will filter\n contacts by tag server-side, so it now reads **all 5,544** every time the page loads. Zero carry\n the tag. Cross-checked against a full page-by-page walk of the whole contact base: the filter\n and the walk agree exactly on three other tags, so the zero is trustworthy.\n- **The five sequences Kim asked about are reviewed.** `handover/NURTURE-REVIEW-FOR-KIM.md`. They\n are live, they are busy, and the topics collide with ours. Details in that file.\n\n---\n\n## GO-LIVE IS STILL THREE SWITCHES, AND ALL THREE NOW EXIST\n\nOur system enrolls people carrying the tag `nurture - puppy`. **All 5,544 contacts checked, live,\non every page load: zero carry it, and nothing in her account applies it.** Done as two switches it\nwould go live and reach nobody, and it would look like it was working, because the engine would\nreport healthy runs with zero enrollments.\n\nThe third switch is now built and running in dry mode (see above). What is left on it is not code:\n\n1. **Amir reads the candidate list** in `handover/Puppy-tagging-candidates.xlsx` and says whether\n the 39 clear ones look right to him. That is the sanity check on my judgement, not a formality.\n2. **Kim answers the one-year-old question.** It is on her page.\n3. **Arming it** happens on the go-live call, with her watching, alongside the other two switches.\n\nNothing about it is waiting on a scope, a token, or anybody's permission any more.\n\n---\n\n## DOORS I NEED YOU TO OPEN\n\n**1. Meta: give the system user an app role.** Unchanged from before, and still the one that puts\nmoney on the page. Order matters:\n\n- Business Settings, Apps, pick one of her apps, add `dogsspot-reporting` as a user on it\n- *Then* System Users, Generate New Token, tick `ads_read` and `read_insights`\n- *Then* Add Assets, Ad Accounts, tick the account, give View Performance\n- Send me the token and I swap it in val.town in two minutes\n\n**2. GHL token scopes.** Still worth having, but **no longer blocking anything**. Four read-only\nscopes on the integration starting `pit-064237ea`, at Settings, Private Integrations. **Do not\nregenerate the token** — that changes it, which takes the engine offline *and* silently kills Kim's\ndashboard link, because her view key is derived from it.\n\n- `locations.readonly`\n- `locations/customFields.readonly`\n- `locations/tags.readonly`\n- `forms.readonly`\n\n**3. ~~The watchdog's schedule~~ — done, by me, in the val.town UI. Nothing needed from you.**\n\n**4. ~~Chrome cannot be scripted from here~~ — solved.** The AppleScript route does fail with\n\"Chrome is not running\" (that setting is off), but the **extension** route works fine and is what\nyour own master handoff already said to use. I have re-read that note and stopped treating the\nbrowser as blocked. Turning the AppleScript setting on is still worth doing one day, but nothing\nis waiting on it.\n\n**5. Sign into GoHighLevel in Chrome and stay signed in.** The session has expired. Two builds sit\nbehind it: the typing chat agent Kim asked for, and deleting the stale Voice AI widget.\n\n**6. Your retainer figure.** Still the only line item on the page with no number against it.\n\n**7. Nothing else.** Square is granted and working. val.town environment variables are set and\nverified. The Meta ad account id is in place.\n\n---\n\n## WHAT I BUILD, IN ORDER\n\n### Done since the last version of this file\n1. ~~Rebuild the test suite~~ — 11 suites, 151 checks, 30 negative controls.\n2. ~~Store it where a reclaim cannot reach it~~ — three bundle parts, on the val, restore verified\n by actually restoring.\n3. ~~Review the five no-sale sequences~~ — `handover/NURTURE-REVIEW-FOR-KIM.md`.\n\n### Next\n4. ~~The tagging mechanism~~ — built, running in dry mode, 1,200-contact review list delivered.\n What is left on it is Kim's answer on the one-year-old boundary, and Amir's read of the list.\n5. **The go-live drill**, from my own phone, in practice mode: STOP handling, reply-pause, the\n watchdog seeing it, the panel showing it. Watched end to end before anyone real is touched.\n6. **The three switches, together, with Kim watching.** Blocked on her go-live answer, her wording\n sign-off, and the email domain.\n7. **Meta spend**, once door #1 lands.\n8. **Google Ads.** Coded, never run against a live account. Still the least-finished thing I own.\n It gets an account and gets tested, or it comes off the list honestly.\n9. **The deposit automation**, scoped once I have watched a few holiday bookings move.\n10. ~~The missing call transcripts~~ — answered. The recordings are all there (54 of the 62 calls\n checked, about two and a quarter hours of audio; the 8 without are calls nobody answered).\n Transcription is a separate switch at Settings → Phone System → Voice → Call Transcription,\n about 2.4 cents per recorded minute, and it does **not** apply retroactively. It is question 13\n on Kim's page. **Candice's app stalling** is still open: her CRM holds 5,516 conversations and\n the message API takes 0.4 to 2.7 seconds each, so any screen loading them one at a time takes\n over half an hour. That is a hypothesis about somebody else's code, not a finding, and I have\n said so rather than dressing it up.\n11. **The typing chat agent**, blocked on door #5.\n12. **The knowledge-base wording sweep**: confirm \"discovery call\" appears nowhere in the KB.\n13. **Friday reports.** Renders correctly; wants a scheduled snapshot and one send Kim has\n actually received before we call it done.\n\n---\n\n## WHAT I WILL NOT DO\n\n- Contact Kim. Every question goes in the ledger.\n- Take anything out of practice mode without her word and your presence.\n- Invent a story, a testimonial, a customer or an event for the eight empty slots.\n- Type a live number into a document again. Anything countable is counted at render time.\n- Ship a finding I could not stand up. There is one in the nurture review that I dropped for\n exactly that reason, and I said so in the document rather than quietly leaving it out.\n\n---\n\n## HOW THIS ENDS\n\nGo-live is three switches thrown together on a call with Kim watching, after a drill from my own\nphone, with the email domain verified and the tagging built.\n\nThe honest state this morning: the machinery is built, verified live, and now genuinely guarded by\nchecks that have been proven able to fail. Nothing has reached a customer. The gap is three\ndecisions from her and three doors from you.\n\n\n\n=====FILE handover/SEND-TO-KIM.txt =====\nKim, everything you sent over is in. Taking your notes in order.\n\nThe puppy's name is gone from every message, all forty-one, not just the ones you were reading. You were right, and for a reason I hadn't checked until you said it: I went and counted where your inquiries actually come from, and the large majority arrive as a message on Facebook or Instagram. Those almost never carry a dog's name, so a placeholder for it was always going to sit empty most of the time. The messages don't lean on it now, they use your customer's own name instead, and I rewrote each sentence around it rather than just deleting the word, so nothing reads like it's had a hole punched in it.\n\nYou were spotting a pattern rather than two words, so I treated it as one. Potty training and yard now, and I went back through the rest of the older copy for the same thing and found a few more that read English rather than American. The newer half was already written that way, so it was only the early messages that were off. There is a check on it now, so it stays fixed rather than drifting back the next time I write something.\n\nDaycare is gone completely, and thank you for catching it, because that one was a proper mistake rather than a wording preference. It was in four separate messages offering a service you don't provide. It's the same class of error as if I'd had you offering grooming, and there's now an automatic check that fails the whole build if the word ever reappears anywhere a customer could see it.\n\nBoth of the missed-Pup-Talk messages are your version rather than mine now, near enough word for word. The text says \"just reply and I'll schedule it\". The email is your rewrite in full, including \"I know life gets busy\" and \"won't keep bugging you\". They read better than mine did, particularly the ending.\n\nThe first three weeks are attached, six pages, generated straight out of the running system rather than typed up. Same numbering you've been using, so Touch 4 is the fourth thing a customer receives. There's a longer companion with all forty-one if you ever want it, but you've already signed off the slow track and nothing in it changed, so the short one is the one to read.\n\nOn the no sale and no sale-tips nurtures. I've looked, and the useful thing to know is that you already have these running: five follow-up sequences plus two auto-responders, all published and live in your account right now. So I've deliberately not built ours, because putting another sequence next to five live ones is exactly how somebody ends up getting two sets of messages from you in an afternoon. It's the same trap as the puppy one we already have flagged. What I'd suggest is that I read the five you have and tell you which are earning their place before we build anything new. One thing already looks accidental: a workflow called \"Copy - Tips Ad campaign > Auto Responder\" is published while the original it was copied from sits in draft, which usually means somebody duplicated it to make an edit and published the wrong one.\n\nNow the holiday deposit, which is the most useful question you've asked me this week.\n\nYes, and it's closer than you'd think. You already have a product in your CRM called \"Holiday boarding deposit\" set at fifty dollars, fully configured, and it doesn't appear on a single order in the payment history I can see. Same story with \"New Client Boarding Deposit\". The reason they've never fired is that your boarding bookings go through the form on your website rather than through the CRM, so the CRM never gets the chance to take the money or to write down that it arrived. That's why it lands on somebody to check by hand.\n\nTwo ways to fix it, genuinely different sizes of job. The smaller one keeps the booking exactly where it is and records the deposit against the customer automatically once it's paid, so you get a list you can look at instead of a memory you have to trust. The bigger one moves holiday bookings so the deposit is taken as part of the booking itself, which means nobody can complete one without paying and the chasing disappears rather than getting easier. I'd want to watch how the money moves for a few days before recommending one, and I can, because the payment link into your CRM is already live.\n\nThree corrections of my own, because you should hear them from me.\n\nFirst, I was about to ask you for a Square permission you had already given me. You gave it, it's working, and payments have been flowing through it since the start of the month. I had it wrong in an earlier draft of this message and I'd rather correct it than let it stand.\n\nSecond, your dashboard had been telling you there was one person walking through the follow-up messages. There isn't. That one record is a test contact of mine with my own email on it, and the system has never once looked at a real inquiry. The page says so plainly now. Nothing went to anybody, but it was flattering itself and it shouldn't have been.\n\nThird, and this one matters for go-live. Our system only picks people up when they're tagged as a puppy inquiry, and I checked twelve hundred of your contacts: not one carries that tag, and nothing applies it. So switching ours on and the old one off isn't two moves, it's three. If we'd done the two, we'd have gone live and quietly reached nobody. That's on the list now as part of the go-live question, and it's mine to build rather than anything you need to do.\n\nThe email you sent Kristian is good. It's clearer than my draft was, and the last paragraph does the important work.\n\nTwo things I haven't got answers on yet and I'd rather say so than guess: the missing call transcripts, and Candice's app stopping when it loads messages. I have the screenshot. Both live in parts of the system I want to look at properly rather than guess at, and I'll come back on them specifically.\n\nOne last thing. Rather than keep sending you numbers in messages, there's now a page you can open any time that reads your systems the moment you load it. It shows what came in, what happened to it, what we've been doing and what's waiting on you, and it's numbered so a reply saying \"yes to 1 and 3\" is a complete answer. I'll send you the link separately so it isn't buried in this.\n\nNothing has sent to anybody. Everything stays in practice mode until you say the word.\n\nAmir\n\n\n\n=====FILE handover/REPLY-AUG5.txt =====\nKim, the person your funnel was chasing is stopped, answers to everything you asked today below, and one thing I found tonight about the red flag tag that you'll want to see.\n\nThomas first, since that was the HELP. He is out of that workflow as of 6:30 this evening and nothing else is active on his record, checked again after a full reload. Nothing new will go to him.\n\nWhat happened, in order. Your team booked his Free Training Day at 10:24 this morning, right after his Pup Talk, directly on the calendar. A few minutes later the little free training day signup page got a visit and its one question form got submitted, most likely him clicking around after the call. That page's funnel only counts a booking made through the page itself. It cannot see the calendar, so it decided he was interested and unbooked, and chased: two texts at 12:31, a voicemail at 12:41, and another text at 2:41, all grab your spot before it fills. Your screenshots caught three of the four, the 12:41 one was a voicemail drop rather than a text. Candice caught it and rang him at 4:54, which is in his thread too.\n\nTwo things worth knowing about it. First, it was not the new follow-up system. That has been in practice mode all day and has sent nothing to anyone, and I checked it live tonight before writing this. It was one of the workflows that came with your account, called \"Free Training Day abandoned booking\". Second, this is the same blind spot as the deposit: bookings made off to the side are invisible to the automations inside the CRM, and this is what that looks like when it bites. The lasting fix is one exit rule on that funnel, leave anyone who already has a Free Training Day on the calendar, and the same rule on its sibling, the small yes text one that sent the first two messages and had already finished with him by then. I can make that change with you on a call or write it up for whoever you prefer, I didn't want to edit a live workflow of yours tonight without you knowing. I also checked whether it hit anyone else: that calendar holds three bookings in all, and the other two people's threads are clean, so Thomas was the only one it reached.\n\nAnd since it's the same Thomas as this morning, George's owner: after the day he's had I would not put him on any track for now. He's booked in and your people are talking to him, which is better than any sequence.\n\nOn going live for the puppy: you were right about the mechanism, one wording detail aside, and the straight answer on tonight is not yet. The tag is \"nurture - puppy\", not just \"puppy\", and Candice used exactly the right one on Kristina this morning without being told, so it's already in her dropdown. The reason for the not yet: switching on properly is one coordinated move, ours on, the old puppy workflow off, the tagging step on, or somebody ends up with two sets of messages, which is exactly the class of accident Thomas got a taste of today. While practice mode is on, the tag queues people up but nothing sends, to anyone, full stop. And once live, the system stays quiet for anyone with a call still on the calendar until that call has an outcome, so nobody gets messaged over a booking.\n\nWalle's owner, told straight, because her day moved around. I marked her at lunchtime, before what was then her afternoon call. Since then, three things happened on her record: her Pup Talk moved to Thursday at 3:40, the puppy mark came off during the afternoon, and on this evening's call your team booked her Free Training Day for Friday morning. I don't know whose hand took the mark off and I won't guess. But where she has landed matches your own rule, anyone who books comes off the track, so I've left it exactly as it is. If you want her on the puppy messages after her visit, it's one tag to put back. So right now exactly one inquiry is marked and waiting, Kristina, and she's held anyway until her Meet and Greet on Monday resolves.\n\nThe attachment. You didn't miss it, it failed to attach, and that's twice now, which is embarrassing. Both documents are on this message and I've watched them upload this time. The short one is the first three weeks. The long one answers your question about the longer version: it's not a different sequence to choose between, it's the same one continued. The first three weeks run their course and then the taper you designed takes over automatically, once a week for a month, every two weeks for six months, then monthly indefinitely. So \"do the longer one then ease into the slow track\" is exactly what's built, nothing to decide.\n\nKristina's two records are merged, done early this afternoon. The useful detail: the two records had two different phone numbers, one digit apart. Her actual call this morning came from the number ending 4535, which proves that's the real one, so it survived and the typo is gone. The accidental do-not-disturb is off, that got switched on when the second record was created, which is why you saw it and couldn't explain it. Her Meet and Greet on Monday is untouched, her email is on the record, and both conversation histories are in one place. One judgment call I made and want you to know about: the duplicate had also been tagged into the no sale and tips nurtures. She has a booked appointment, so she's not a no sale, and carrying those tags over would have had your tips messages texting someone who's about to come in. I left them off. If you want her in tips anyway it's one click to add back.\n\nThe tag report is attached, rebuilt tonight so it matches your account as of this evening, and it turned up the thing you should actually look at. The tag \"red flag\" is not just a label. A workflow that came with your system switches on do-not-disturb for anyone who gets it. It was put on five people this week, so all five are on do-not-disturb right now and your system will not message them at all. They are listed by name in the file. And they answer your actual question about where these came from: seven people carry them, six from the missed-callers list Candice was working through yesterday and one who came in through Messenger, and every one of the seven records was touched during her calling hours yesterday afternoon. So these read like her outcome notes from working the phones, no for a no, red flag for the ones that felt off. A sensible instinct. She just may not know that red flag also silences people: if any of them were flagged by mistake, taking the tag off is not enough on its own, the do-not-disturb switch needs turning off too. The other odd ones are smaller: \"no\" is on four people and does nothing by itself, though it sits one word away from \"no sale\", which does start a nurture. And a tag called \"follow-up\" was on exactly one person when I built this afternoon's version of the file and is on nobody now. I didn't take it off, so the tidying has already started on your side. One honest limit, stated in the file too: your CRM doesn't record when a tag was applied, only that a record changed, so the file shows records touched since Monday, 167 of them, and what they carry now. On the bigger cleanup, every tag actually in use is in the file, 40 of them tonight. The dropdown also holds tags that are defined but sitting on nobody, and reading that list needs one extra permission on the connection, a two minute change in tonight's task list on my side, and the full unused-tags list follows right behind it. The cleanup itself is short and safe because nothing in use gets touched.\n\nYou're reading the no sale routing correctly. Today everyone lands in no sale-tips unless disqualified. Once we're live, the puppy tag pulls puppies onto the new track and your existing flows keep everyone else. And thank you for the history on the tips ad campaign, that the copy was Milton's and that it answers on Facebook comments as well as Messenger. That changes it from \"looks accidental\" to \"leave it alone\", and I have.\n\nThe deposit, good news: the Stripe advice didn't come from me, and whoever it came from was answering a different question. Nothing in the plan bills anyone through the CRM. Square keeps taking the money exactly as it does now, and what I'll build reads the payments as they land and does the bookkeeping automatically: deposit paid gets marked on the person, and you get one list of holiday bookings that still owe. No Stripe, nothing changes about how customers pay. On dates, one small correction so the automation never misfires: Thanksgiving is the fourth Thursday of November, the 26th this year, and it's computed fresh each year, so that curveball is handled. I'll fold it into the monthly.\n\nThe transcripts, and a correction of mine. Earlier today I told you transcription had never been switched on. That was wrong. Kristina's call from this morning has a full written transcript, I watched it render, and this afternoon's call with Thomas shows one too. So transcription works, at least sometimes, and the real question is which calls are missing theirs. The fastest way to crack it: point me at one call where the transcript should be there and isn't, or tell me roughly when they disappeared for you, and comparing that call against a transcribed one should pin the pattern down quickly. And if nothing comes to mind, just say so, and I'll walk the recorded calls myself tomorrow and bring you the list of which have transcripts and which don't.\n\nCandice's app stalling on messages I'm still on, and I'd rather say that than guess. One thing I can already measure: your account holds five and a half thousand conversations, and loading them one at a time takes long enough that anything doing so would appear to freeze. That's a suspicion about where to look, not an answer yet.\n\nAnd the page link I owed you: https://amir5--fb119304902811f182781607ee4eb77e.web.val.run?k=tds_view_795bafb78a5428f8e6ef481518c274b6\n\nBookmark that. It reads your systems the moment you open it, every count on it comes from your records rather than from anyone's memory, and each question and log line on it names the check that backs it. Tonight is already written on it: Thomas, the red flag finding, and Walle's owner coming off the track. The count of marked puppy inquiries reads your records live each time you open it.\n\nNothing has sent to anybody from the new system, today included. Three things stand between here and fully live, and they are numbered on the page: your word on the wording, the switch-over done as one move so the old puppy workflow cannot double-message anyone, the same class of accident as today's funnel, and four small settings wherever thedogsspotga.com is managed so the emails land in inboxes instead of spam. The first two happen the evening you say the word, and the texts can go live on those two alone. One more honest pointer: on that page, the access key question, the Bootcamp deposit question, and the doubled review-request automations are the three that most deserve your eyes first, and the rest can wait for you.\n\nAmir\n\n\n\n=====FILE handover/REGISTER-AUG5.md =====\n# REGISTER ADDENDUM - fleet verification, late 5 Aug (ET)\n26-agent fleet (20 sonnet verify, 4 opus adversarial, 1 opus judge, ~62 min, 642 tool calls) against live data.\n\nCONFIRMED CLEAN: Thomas timeline (every timestamp), Kristina record (all five facts), census=1 Kristina,\nred flag x5 all DND, no x4 with two non-DND, follow-up 0, 40 distinct tags (full 5,562-contact walk),\nold puppy workflow still published (cutover premise), Tresa state (tags [phone], Pup Talk Aug 6 3:40,\nFTD booked), conversations 5,534 (message says five and a half thousand), 3 go-live blockers match page.\n\nFINDINGS AND RESOLUTIONS:\n1. Three source=workflow SMS hit Thomas AFTER the 6:30 PM removal (8:00, 8:05, 9:05 PM ET). Verified by\n hand: they are the BOOKED-path confirmations for his real Aug 15 session (confirmed + spots-held +\n details), triggered by his opportunity moving to booked at 8:00 PM. Correct message type for a booked\n customer; the chase type stayed stopped. Sent message's \"Nothing new will go to him\" is literally\n false as a result; bridge note corrects it.\n2. Adversarial sweep found 76 chase texts + 24 voicemails to 27 other contacts since 14 Apr. Checked the\n booked ones by hand: Luis Colon booked Jul 13, zero chase. Destinee Patterson chased 30 May while\n UNBOOKED (funnel's intended target), booked 4 Aug - the funnel converting, not the defect. Conclusion\n of the sent message stands as scoped: Thomas is the only person chased AFTER booking. Stronger\n evidence method than the calendar-sample cited in the message; noted here.\n3. \"That calendar holds three bookings in all\" was stale by one at send: Tresa booked 6:35 PM, message\n sent 7:54 PM. Materially harmless (the fourth is Tresa, whose story the message tells). Logged.\n4. \"Practice mode... sent nothing to anyone\": engine made one SMS API call on 5 Aug 12:40 PM ET to the\n ZZTEST dummy (unroutable, failed). True for real people; wording tightened in future copy. ENGINE\n HARDENING QUEUED: add TEST_MODE guard at the sendSms call site (safety currently via contact scoping).\n5. \"Computed fresh each year\" (Thanksgiving) describes the deposit plan not yet built; present tense ran\n ahead of reality again. Building the reader includes the fourth-Thursday computation.\n6. Red flag DND nuance: 4 of 5 silenced by the workflow from clean state; the fifth (no-name record) had\n SMS-blocked themselves 20 Jul, workflow extended it to all channels 4 Aug. Message's claim literally true.\n7. Chase funnel \"Free Training Day abandoned booking\" remains PUBLISHED. Fix proposed to Kim in the sent\n message; her call, not taken unilaterally.\n8. Disk reverted to the Aug 4 snapshot a third time mid-fleet; twelve slices reported artifacts missing.\n Kim's copies live on Upwork (hash-verified before send) and everything regenerates from the val bundle\n (v203/204). Local file absence is an environment artifact, not a delivery failure.\n\n\n\n=====FILE handover/AMIR_TODO.md =====\n# AMIR - morning of 6 Aug. 4 things.\n\n## 0. State of play\nThe full reply went to Kim last night (7:54 PM ET, two bubbles, stray \"Boo\" in the middle, all\nthree files attached, every claim fleet-verified afterward). She has not answered yet. The short\nbridge note is drafted and HELD - I do not send it unless you say \"send it\". Three automated\nbooking-confirmation texts went to Thomas at 8-9 PM for his real Aug 15 session (right kind of\nmessage, from the booked-day workflow, not the chase). The chase workflow stays stopped for him.\n\n## 1. One token action in GHL (5 min, fixes the exposed key AND the missing scope)\nPrivate Integrations tab (open in Chrome) > edit the reporting integration > tick the tags-view\nscope > Save > Regenerate token > paste new token into BOTH vals' env tabs (engine + watchdog) >\nopen the dashboard link and confirm the counts load.\n\n## 2. Bridge note - your call\nSend it from your phone or tell me \"send it\". Text is in the chat. It owns the Boo, corrects\n\"nothing new will go to him\" (his booking confirmations went out, the right kind), and points\nher at the red flag finding.\n\n## 3. When Kim says go on the wording\nThe switch-over is one coordinated move done together: TEST_MODE=false, old puppy workflow off,\ntagging on. Never solo.\n\n## 4. Engine hardening queued (do with me, 20 min, not urgent)\nAdd a TEST_MODE guard at the sendSms call site (today safety is contact-scoping to the dummy).\nThen the funnel exit-rule change for Kim if she says yes.\n\n\n",[569],"afe3d4f2-b712-43f2-ba70-23198d99e697","SOURCE-BUNDLE.part38.txt","272a8e58-9832-11f1-a957-1607ee4eb77e",1087,["D",1786801894611],"THE DOGS SPOT — SOURCE BUNDLE (part 38 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (8 of 116 files)\n LESSONS.md 18343 bytes fe07a0bc0b79\n handover/RESUME.md 8766 bytes b52018ea0252\n handover/REGISTER-AUG7.md 10172 bytes d18a3dbd5e02\n handover/SWEEP-7-AUG.md 6685 bytes c1bad79bc258\n handover/AUTOPILOT.md 5756 bytes 5fb74d8737b3\n handover/DRAFTS-WHILE-AWAY.md 3945 bytes 7346f037f0ce\n handover/MESSAGE-TO-KIM-7-AUG.txt 6553 bytes 26e5785ba858\n reports/Friday-Report-7-Aug-2026.html 15113 bytes 29b45b54bf09\n\n================================================================================================\n=====FILE LESSONS.md =====\n# LESSONS.md — what this account has already paid to learn\nRead before every task. Append after every failure. Convert every rule into a test.\nFormat per entry: WHAT happened · ROOT CAUSE · THE RULE · EARLY DETECTION\n\n## Seed, 11 Aug 2026, from the project's own history\n\n1. WHAT: a restored tree came back red; the bundle had silently dropped tests/fixtures/.\n ROOT CAUSE: one-level directory walk. RULE: rebundle the moment anything goes green, and the\n bundle must round-trip verify. DETECTION: bundle.mjs walks recursively and refuses to write\n without HANDOFF.md; deploy --bundle verifies every part on the val. ENFORCED: bundle.mjs guards.\n\n2. WHAT: an audit \"passed\" while inspecting zero items. ROOT CAUSE: checks with no denominator.\n RULE: a check that inspects zero items is a failure, never a pass. DETECTION: every test returns\n scoped(n, ...) and the harness fails on zero. ENFORCED: tests/_harness.mjs.\n\n3. WHAT: Kim's counter-sales backlog overstated by $10,884. ROOT CAUSE: the count read only first\n attempts; later matches never cleared rows. RULE: counts must read every attempt, not the first.\n DETECTION: tests/money-truth.test.mjs fixture reproduces matched-later traps. ENFORCED: test.\n\n4. WHAT: the consent predicate was inverted and survived 394 assertions. ROOT CAUSE: the only test\n grepped source text instead of calling the function. RULE: never trust a predicate without\n testing BOTH polarities by calling it. DETECTION: I3/I3b/I3c call readChannelConsent with live\n shapes; fault injection goes red. ENFORCED: tests/harness.mjs.\n\n5. WHAT: Kim's page said \"this evening\" forever. ROOT CAUSE: relative time in copy. RULE: no\n hardcoded relative dates in anything she reads. DETECTION: KC-dates lint test bans the phrases.\n ENFORCED: tests/kim-copy.test.mjs.\n\n6. WHAT: a handover claimed a message was sent that never was; a board claimed \"fixed\" for a\n watchdog that held no copy of the logic. RULE: a claim from a previous session is unverified\n until checked live, at a timestamp you can name. DETECTION: [V]/[C]/[U] tags with receipts;\n cold reads. ENFORCED: process, not yet a test.\n\n7. WHAT: the matcher overwrote a field two systems can write. ROOT CAUSE: blind write. RULE: never\n blind-write a field another system owns; sum, scope by stage id, log every write. DETECTION:\n MM-o..MM-t; stage allow-list asserts IDs not names. ENFORCED: tests/money-match.test.mjs.\n\n8. WHAT: \"29 / $19,822\" shipped as complete when the population was 33 / $22,651.99. ROOT CAUSE:\n the query was cut at a date and the cut read as a finding. RULE: a filter boundary is not a\n result; reconcile any subset against its parent total before it leaves the building.\n DETECTION: the audit script asserts subset+remainder equals the parent figure. ENFORCED: ad hoc;\n convert to a standing check when the exception report ships.\n\n9. WHAT: prose over correct arithmetic was wrong twice on the money page. ROOT CAUSE: nothing tests\n sentences. RULE: every number in client prose is re-derived from source before send; run the\n figure audit on every outbound draft. DETECTION: the twelve-assertion draft audit. ENFORCED:\n process; script exists in session history.\n\n10. WHAT: the consent-fix tests were added to tests/harness.mjs, which run-all EXCLUDES as\n scaffolding, so the most important tests of the week ran nowhere; a stale E4 assertion in the\n same file had been failing for days and nobody saw. ROOT CAUSE: added tests without verifying\n the suite count moved. RULE: after adding a test, confirm run-all's suite and assertion counts\n increased; tests live in *.test.mjs files, never in scaffolding. DETECTION: run-all prints both\n counts on every run; compare before and after. ENFORCED: tests/consent-guard.test.mjs is\n discovered; harness.mjs remains scaffolding.\n\n11. WHAT: a deploy shipped while the suite was red (a used-before-declaration the typechecker\n caught), because the deploy command ran in the same breath as the test command and the test\n output was grepped, not read. ROOT CAUSE: pipelining verify and ship. RULE: the suite's RESULT\n line is read and GREEN before deploy is typed, never alongside. DETECTION: deploy.mjs could gate\n on run-all exit code; until then, two commands, two reads. ENFORCED: process.\n\n## Added 12 Aug 2026\n\n12. WHAT: the CRM recorded no payment amounts for five months, from 19 February to August, and\n nothing anywhere noticed. ROOT CAUSE: staff moved from raising invoices in the CRM to ringing\n sales straight into the Square app, so the CRM was cut out of the loop. Nothing failed, so\n nothing errored: bookings kept arriving at full volume and the dollars against them were zero,\n and every count on every page stayed healthy. THE RULE: an absence raises no error, so something\n must be watching the place where a thing used to be. Volume and value are watched TOGETHER,\n because either one alone reads as a normal business. DETECTION: engine/watch.ts, five checks,\n each measuring a source against its own history rather than a threshold somebody typed. Replayed\n against the real payment records: raised on 23 February, urgent by 1 March. ENFORCED:\n tests/watch.test.mjs W20 and W40 are the February shape; sixteen controls in\n tests/negative-controls.mjs break each check in turn, and run-all re-proves the February one on\n every single run.\n\n13. WHAT: the revenue check fired correctly and printed nonsense: \"47 bookings, the same as usual or\n more, and the money came to $50.00. Over the 6 periods before it the usual figures were 2\n bookings and $550.00.\" ROOT CAUSE: the baseline was this account's first weeks in the CRM, two\n records a period. Right arithmetic, no denominator. THE RULE: a baseline needs a minimum\n population before it can carry an accusation, exactly as a ratio does; below it, say \"cannot\n judge\" out loud rather than either accusing or passing. A sentence that reads as a glitch spends\n the credibility the real alarm will need. DETECTION: found by REPLAYING the check against the\n real history as it stood on a past date, which is a thing worth doing to anything that claims it\n would have caught something. ENFORCED: tests/watch.test.mjs W24b, plus its own control.\n\n14. WHAT: the Square backlog was reported as 33 payments / $22,651.99 when the true figure is 4 /\n $1,969.99. 29 payments worth $20,682.00 had reached a named customer and were still being\n counted as never having reached one. This is the THIRD wrong version of this same number in\n writing (42 / $33,535.99, then 29 / $19,822, then 33 / $22,651.99). ROOT CAUSE: not the rule,\n the KEY. Both squareBacklog() and unmatchedPaymentRows() group a payment's rows by\n `/payment\\s+(\\S+)/` on the note. The bridge writes the failing attempt as \"payment \" and\n the attempt that RESOLVED it as \"backfilled from square payment ; client opp untouched\".\n `\\S+` swallows the semicolon, so the resolving row lands under \";\" and the failing row\n under \"\". The MATCHED-LATER GUARD is correct and never fires, because it is guarding a\n group the matched row is not in. A second, smaller hole in the same key: PAY-DUP rows carry the\n payment id in an `id` FIELD with no note at all, so a note regex cannot see them; 5 payments\n were missing from the population entirely. THE RULE: a guard is only as good as the key that\n groups the rows it guards. When a count is wrong, check the grouping before the logic, and\n assert that two rows known to describe one thing actually land on one key. Corollary: a payment\n id is data, and it gets a parser with a test, not an inline regex written twice.\n DETECTION: found by reconciling the unmatched SUBSET against a population total that had never\n been computed before. There was no denominator, so three wrong numbers in a row all looked\n plausible. ENFORCED: scripts/exception-report-lib.mjs squarePaymentIdsInRow() +\n paymentUniverse(); tests/exception-report.test.mjs X14..X19, where X19 is a negative control\n that rebuilds the old note-only key and proves it splits the payment and loses the match.\n CLOSED 12 Aug 2026, verified live at 18:58 UTC against 790 journal rows: engine/facts.ts now\n carries paymentIds() with the same punctuation strip and the same id-field read, and\n squareBacklog() returns 4 / $1,969.99. The correction was not made silently; it went to the\n client as /mnt/user-data/outputs/counter-sales-CORRECTION.md, leading with the corrected\n figure and showing the arithmetic from 42 / $33,535.99 down to 4 / $1,969.99.\n\n15. WHAT: a contact walk stopped at 900 of 5,708 and reported 900 as the whole CRM. ROOT CAUSE: one\n page came back with an empty array mid walk and the loop treated \"no rows\" as \"no more rows\".\n Re-issuing the identical request with the identical cursor returned a full page. THE RULE: an\n empty page is retried, never believed; the stop condition is the stated total, not the first\n gap. Second half of the same rule, learned on the next run: the total MOVES, because the CRM is\n live and contacts are created while the read is running, so the target is the total as it stood\n at the FIRST page. Short of that is a hard failure; past it is growth during the read and is\n worth a note, not a crash. ENFORCED: scripts/client-files-rebuild.mjs fetchAllContacts() and\n fetchAllOpportunities().\n\n16. WHAT: the weekly exception report shipped a column headed \"Recoverable\" that told the client\n Caroline Riner could not be traced, when Square holds her full name and her phone number, and\n that a sale with nothing attached anywhere could be. Two of four rows wrong, in the column she\n uses to decide what to chase. ROOT CAUSE: the column was read off hadEmail/hadPhone/\n hadCustomerId. Those describe the WEBHOOK PAYLOAD the bridge received, not Square's customer\n record, and the report already had Square's own answer in hand from its ?lookup= call and did\n not use it. engine/facts.ts had ALREADY been fixed for exactly this on the sentence it\n generates; the CSV and the markdown table beside that sentence were missed, because the fix\n was made where the bug was noticed rather than everywhere the field is read. THE RULE: when a\n field is found to be answering a different question from the one asked of it, grep for every\n reader of that field in the same change, not just the one that surfaced it. Corollary: if a\n document already fetched the authoritative source, no column in it may be derived from a proxy.\n DETECTION: found by checking all four rows against Square through ?lookup= instead of trusting\n the flags, which is the same move that found the payment id bug. ENFORCED: exception-report.mjs\n derives the client-facing column from the Square lookup and prints how many rows the old flag\n got wrong; the flag survives in the CSV under the name journal_flag_called_it_recoverable so\n its provenance is on its face. NOT YET A TEST.\n\n17. WHAT: the weekly exception report quoted its subset against nothing. It said \"4 unmatched\n payments totaling $1,969.99\" with no population anywhere in the document, which is the exact\n condition LESSONS #8 and #14 both name as the reason three wrong versions of that number in a\n row all looked plausible. ROOT CAUSE: paymentUniverse() was written to supply that denominator\n and the report never called it. A rule that exists in the library but is not wired into the\n artifact protects nothing. Second, smaller cause found while wiring it: the population cannot\n be summed from the journal at all, because PAY-DUP rows carry no amount field and five payments\n worth $1,410.00 are reachable only through those rows. A journal-only parent total understates\n the population and makes the subset look larger than it is. THE RULE: the parent total goes in\n the artifact the client reads, not just in the console, and it is summed from the system that\n owns the amount rather than from the log that mentions it. DETECTION: the report now reconciles\n linked plus unlinked against the population in rows and in cents and refuses to write if they\n disagree. ENFORCED: scripts/exception-report.mjs STEP 6a. NOT YET A TEST.\n\n18. WHAT: a client page was about to go out that threw `Identifier 'top' has already been declared`\n and rendered a title and nothing else. Every figure on it was correct and independently\n verified. ROOT CAUSE: `const top` at module scope collides with `window.top`, and nothing in\n this project had ever OPENED a generated HTML page before sending it. The copy lint, the figure\n audit and the reconciliation checks all passed on a page that displayed nothing. THE RULE: a\n generated page is not verified until it has been rendered in a real browser and the screenshot\n LOOKED AT. Console errors, horizontal overflow and sheared numbers are part of correctness, not\n polish. DETECTION: headless Chromium render at 1100px and 360px, asserting zero page errors and\n `scrollWidth === clientWidth`, before any HTML reaches a client. ENFORCED: process today; make\n it a test the moment a second page is generated.\n\n19. WHAT: the message quoted $204,122.00 as the headline and its own attachment led with\n $419,217.99 in the largest type on the page. Both were correct, over different windows. ROOT\n CAUSE: message and attachment were written by different passes and neither reconciled against\n the other; each was checked internally and the PAIR was checked nowhere. THE RULE: a deliverable\n is the message plus every attachment, and the contradiction sweep runs across the set, not\n within each file. To a client who has been given three wrong numbers, \"different window\" is\n indistinguishable from the previous three excuses. DETECTION: build the table of every figure\n appearing in more than one file and diff it, including framing differences (gross versus net,\n payments versus orders) and not just arithmetic. ENFORCED: process.\n\n20. WHAT: a trust document answering \"who else has been in my account\" listed Facebook and the\n email inbox as \"not connected, nothing\", while the same send quoted her Facebook thread verbatim\n and named the hour her CRM last emailed a customer. ROOT CAUSE: the table described the\n integrations I had authenticated to, not the data I could actually read; her conversations live\n INSIDE the CRM, so \"read everything in the CRM\" already included them. THE RULE: an access\n disclosure enumerates what can be READ, not what has been plugged in. Anything the same send\n demonstrates knowledge of must appear in it. DETECTION: cross-read the disclosure against every\n other file in the send and ask, for each fact, which row of the table permits knowing it.\n\n21. WHAT: the bundle upload failed on one part with \"Null byte detected\" after a new script used a\n literal NUL as a map key separator inside a template string. Valid JavaScript, unshippable.\n ROOT CAUSE: the recovery bundle is the only route back after a container is reclaimed, and\n nothing checked that every source file was transport safe before it became load bearing.\n THE RULE: a file that cannot round trip through the bundle is a broken file, whatever the\n language thinks. Composite map keys use a printable separator. DETECTION: bundle.mjs should\n refuse to write a part containing a control character, naming the file and the offset;\n until then, deploy --bundle failing is the signal and it must be chased, not retried.\n\n## Added 14 Aug 2026\n\n22. WHAT: engine/watch.ts, the early warning monitor, roughly 990 lines written and tested green on\n 12 August, existed in exactly one place and that place was a container. The container was\n reclaimed and the file was gone from everywhere. It had to be rebuilt from tests/watch.test.mjs.\n ROOT CAUSE: scripts/bundle.mjs excluded engine/ with the comment \"the val holds it, verified\n file by file by scripts/deploy.mjs\". That was true of 27 of the 28 engine files. watch.ts is a\n module the val does not run (scripts/watch-run.mjs imports it locally), so it was never\n deployed, so deploy.mjs --check never had an opinion about it, so nothing anywhere compared the\n two lists. The assumption was stated in a comment and checked by nothing.\n THE RULE: a comment claiming a file has a second home is not a second home. Every source file\n gets one unconditionally, and the completeness of the backup is checked against the TREE, which\n is present and needs no credential, rather than against a remote system that needs a network, a\n token, and can lose the file the day after the check passed.\n DETECTION: scripts/bundle.mjs now carries engine/ and sweeps the whole repo for source files,\n refusing to write while any of them is outside the bundle. Proved able to fail two ways: remove\n engine/ from INCLUDE and it names 26 files; add an unlisted directory and it names the one file\n in it. Exit 1, nothing written.\n SECOND HOLE FOUND WHILE FIXING THE FIRST: scripts/restore.mjs read the bundle with\n `for (let i = 1; i <= 20; i++)`. The val held 23 parts, so the documented recovery path had\n already been silently restoring 20 of them and printing two cheerful counts underneath. The\n part list is asked for now, and a gap in the numbering is a hard failure.\n ENFORCED: scripts/bundle.mjs source sweep; scripts/restore.mjs part discovery plus a\n contiguity check, with engine/watch.ts named in MUST_EXIST so a bundle older than this fix says\n so at restore time rather than at import time an hour later.\n\n23. WHAT: the val holds engine/_deno-shim.d.ts, which is not source. scripts/typecheck.mjs writes\n that shim, runs tsc, and deletes it in a finally block; a deploy that ran while it existed on\n disk pushed it, and it has stayed. Harmless today: typecheck skips .d.ts, nothing imports it,\n and the next typecheck run deletes it again after a restore. THE RULE: a deploy that walks a\n directory will ship whatever is in that directory at that second, including a file some other\n tool is holding open. NOT YET FIXED, and deliberately left alone rather than deleted off the\n val in passing.\n\n\n=====FILE handover/RESUME.md =====\n# RESUME — read this first\n\nLast updated: **7 August 2026, 23:40 UTC**. Written as the session ran, not at the end.\n\n## Where this stopped\n\nRound 14 of the holiday-deposit adversarial review was finished, tested, deployed and recorded.\nRound 15 had one reviewer come back before **the container reverted at ~15:10** to a snapshot that\npredates the deposit tracker. The recovery is complete and verified; roughly half the session's\nremaining budget went on it. Round 15's finding is diagnosed, one part fixed, the rest open.\n\n## URGENT, FOUND IN KIM'S INBOX 7 Aug 23:30\n\n**The Kristian acceptance walkthrough is Sunday 9 August, 3pm EST / 8pm BST.** Kristian confirmed\nhe expects Amir on it. The invite went to iziguickbooks@gmail.com, Google flagged it as an unknown\nsender, and it is in NO calendar Amir holds. Amir must accept it himself.\n\nAlso unread in her inbox: Kristian's answers to the five pre call questions, an email to Kristian\nand Amir about issues found with Chloe, and a Manychat payment that has failed twice.\n\nFull register: `handover/SWEEP-7-AUG.md`. Plan for running without Amir: `handover/AUTOPILOT.md`.\nReady to send: `handover/DRAFTS-WHILE-AWAY.md`.\n\n## SENT TO KIM, 7 Aug 11:46 PM and 12:03 AM\n\nBoth went out on Upwork, watched landing in the thread.\n\n1. The full message. Owns the silence and the late report, corrects the deposit scope in its first\n section (it lists, it does not block), answers the 175 question, gives dates for everything not\n done. Text at `handover/MESSAGE-TO-KIM-7-AUG.txt`.\n2. `TheDogsSpot-Friday-Report-7-Aug-2026.pdf`, five pages, attached with the line \"Here is the full\n report, five pages.\"\n\nNothing else is owed to her tonight. The dates she now holds us to are in the message and repeated\nat the bottom of this file.\n\n### Small wording note for next time\nThe message says \"the full one page version comes over right behind this\" and the PDF is five pages.\nIt is one page per platform plus an appendix, so it is not wrong, but say \"the full report\" next\ntime rather than \"one page\".\n\n## SUPERSEDED: the message to Kim is written and NOT sent\n\n`handover/MESSAGE-TO-KIM-7-AUG.txt`. Amir sends it. It opens by owning two days of silence, then\ncorrects the deposit scope (it lists, it does not block) before anything else. Confirmed by a fresh\nreload of the thread that no message went to her today, so that correction is still owed.\n\nThe three reports are at `reports/Friday-Report-7-Aug-2026.html`, one page, phone readable, every\nfigure read live from the platform today and every derived figure computed in code.\n\n## NEW FROM KIM — read `handover/REGISTER-AUG7.md` before touching the deposit feature\n\nHer thread was read at 17:05 UTC. Roughly twenty messages since 6 Aug 2:57 PM, none answered. Her\nlast one, 7 Aug 3:58 PM: *\"I haven't heard from you so thinking communication may have moved to the\ncard page.\"* She is waiting.\n\n**The one that changes the work:** on 6 Aug she confirmed she wants the deposit feature to *block a\nbooking until the deposit is paid*. What is built and live is the other option she was offered —\nread Square, produce a shortlist. It is the honest half and it works, but she believes something\nstronger exists. **Nothing more should be said to her about deposits until that is stated plainly.**\n\nTwo of her questions are already answered by what shipped: the deposit is $50 **per dog** (watched\nlive, Musselwhite's row reads $150.00 for 3 dogs), and Thanksgiving is the **fourth** Thursday, not\nthe third as she restated.\n\n## First three things to do\n\n0. **Answer Kim** — or rather, put the reply in front of Amir. Register at\n `handover/REGISTER-AUG7.md`, deposit scope mismatch first.\n1. **Round 15, the accusation allow-list.** 69 of 81 candidate accusing sentences reach Kim's\n rendered card. One mechanism (non-breaking space) is fixed. Do NOT widen the regex a fourth\n time — make the note cell an allow-list by construction. Full argument at the end of\n `handover/DEPOSIT-SPEC.md`.\n2. **Finish round 15**, then run round 16. Two consecutive CLEAN rounds are still the goal;\n fifteen have run and every one has found something.\n3. **Run the full 203-control suite.** It has not completed end to end since the rebuild. About\n 25 minutes: `node tests/negative-controls.mjs`. Twenty-nine of the controls are new or\n retargeted and were each verified individually, but not in one pass.\n\n## State, verified\n\n| | |\n|---|---|\n| suites | 15, **332 tests**, 0 failed |\n| floors | test count, check count AND assertion count, per suite; every floor's suite proved to have run |\n| controls | **203**, seven pinned by fingerprint in `run-all`, one retired on the record |\n| typecheck | clean, 21 engine files |\n| engine on the val | deployed and verified, v388 — `dashboard.ts`, `deposits.ts`, `holiday-deposits.ts`, `worklog.ts` |\n| bundle on the val | parts 1-11, rebuilt and pushed 7 Aug ~16:30 |\n| `restore.mjs --check` | byte-for-byte agreement on every file |\n| main.ts | 79,157 / 80,000 characters — 525 to spare |\n\n## Live URLs\n\n- dashboard `https://amir5--fb119304902811f182781607ee4eb77e.web.val.run?k=`\n- deposits `https://amir5--2e97d0d291ad11f1a57d1607ee4eb77e.web.val.run?k=`\n — read it WITHOUT `?run=1`. `run=1` resets the hourly gate and destroys the evidence of whether\n the schedule fired on its own.\n- admin key: `DELIVERY/ENDPOINTS.md`. Never echo it, never put it in anything Kim reads.\n\n## The refresh\n\nObserved firing autonomously **seven times**, all labelled `deposits-cron`: 20:49, 21:49, 22:52,\n23:54, 00:54, 02:55:55 and **16:08:21Z**. That last one was read from the endpoint WITHOUT `run=1`,\nthirteen hours after the only manual run of the day, so it is the schedule and not a person. State\nat that read: 2/2 boarding calendars, 2/2 pick-up calendars, 0 read failures, one row, next refresh\ndue 17:08:21Z.\n\n## If the container reverts again\n\n**It reverted twice on 7 August — at ~15:10 and again at ~17:15.** The first cost roughly half a\nsession because the bundle was twelve hours stale. The second cost three minutes, because the tree\nhad been rebundled the moment it went green. That is the entire argument for the rule below.\n\n\n```\nnode scripts/restore.mjs # needs $VALTOWN_TOKEN\nnode tests/run-all.mjs\n```\n\n`restore.mjs` needs a val.town token. It reads `$VALTOWN_TOKEN`, then `scripts/deploy.mjs`. **If\nboth are gone** — which is what happened on 7 August, because the snapshot predated `scripts/` —\nthe token is in the session transcript under `/root/.claude/projects/`; extract it without printing\nit. Do not paste it into any file Kim or a subagent can read.\n\n**The trap that cost twelve hours:** the engine restores from the val at whatever state was last\nDEPLOYED, and everything else restores from the bundle at whatever state was last BUNDLED. If those\nare different points in time you get a mismatched repo, and it presents as tests failing for\nreasons that look like new bugs. `restore.mjs` now names eleven files whose absence proves the\nbundle is older than the work. **So: rebundle the moment the tree is green.** Not at the end of the\nsession. The bundle is the only copy of everything that is not the engine.\n\n## Open, not blocked\n\n- **Round 15's thirteen remaining accusation mechanisms.** Listed by group in `DEPOSIT-SPEC.md`.\n- **The `/calendars/events` truncation guard.** `allNotes` treats a list at the 100 cap as\n unreadable because that endpoint cannot be paged. The two calendar reads have no equivalent\n check, and whether that endpoint caps — and at what — has not been observed. Guessing a threshold\n would be inventing one. In the ledger as a question.\n- **The transcript TTL test**, due ~13 Aug: re-query the earliest surviving transcript.\n- **Two schedules racing.** Cannot be made atomic — val.town's blob store has no compare-and-set.\n The window is one blob write wide, the cost is a duplicate read-only pass, and D43 pins the\n guarantee that actually holds rather than the one that does not.\n\n## Questions for Kim — ledger only, do not contact her\n\n1. The boarding cancellation policy. Nothing on her website.\n2. Do the Thanksgiving window edges (Monday before to Sunday after) match what she wants?\n3. Does she offer daycare, at what price? Her own biography says the facility does; there is no\n page, no hours and no price anywhere. Her instruction was to remove the word from customer copy,\n which is why it came off the dashboard footer.\n4. The funnel exit rule for an abandoned Free Training Day booking. Not to be applied unilaterally.\n\n## Amir's one action, non-blocking\n\nGHL → Private Integrations → tick the tags-view scope → Save → Regenerate → paste the new token\ninto both val env tabs. Until then the tag report shows a setup state rather than data.\n\n\n\n=====FILE handover/REGISTER-AUG7.md =====\n# REGISTER — Kim's thread, 6–7 August\n\nRead from Upwork on 7 August at 17:05 UTC. Covers everything after the last Amir message\n(6 Aug, 2:57 PM). Kim wrote roughly twenty messages in that window and has had no reply.\n\n**Her last message, 7 Aug 3:58 PM:** *\"Did you see the responses to the cards on the links that you\nsent over on Wednesday? I haven't heard from you so thinking communication may have moved to the\ncard page.\"* She is waiting. That is the most time-sensitive item here and it is not a build task.\n\n---\n\n## 1. THE DEPOSIT SCOPE DOES NOT MATCH WHAT WAS BUILT — decide before anything else\n\n**Kim, 6 Aug 5:03 PM:**\n> \"And just so I'm not misunderstanding you're gonna go ahead and set it up to automatically charge\n> the nonrefundable deposit for holiday boarding bookings so that they cannot have a confirmed\n> booking until the deposit is paid is that correct? And can we make sure that there is clear\n> communication that this deposit is nonrefundable for the holidays?\"\n\nOn 5 August she was offered two sizes of job: the small one (read Square, produce a list of who\nstill owes) and the big one (take the deposit as part of the booking, so nobody can complete one\nwithout paying). **She has now chosen the big one, and believes it is what is being built.**\n\n**What exists is the small one.** The holiday deposit tracker reads her calendars and her Square\npayment notes and produces a shortlist to check. It writes nothing, blocks nothing, and cannot\nprevent a booking. It is finished, tested and live.\n\nThat is not a defect — it is the honest half, and it was right to build first because it required\nwatching the money move before recommending anything. But she must not be left believing a booking\nis being blocked when it is not. **Nothing further should be sent to her about deposits until this\nis said plainly.**\n\nWorth putting in front of her at the same time:\n- The blocking version means moving holiday bookings off her website form and into the CRM, which\n changes where her customers book. That is a bigger change to her business than to the software.\n- On 5 Aug she said she was told it needs Stripe because the CRM is not native with Square, and\n that she would rather not. Blocking a booking on payment is exactly where that constraint bites.\n The tracker sidesteps it; an enforcing version does not.\n\n**Her second half — \"clear communication that this deposit is nonrefundable\" — is buildable now**\nand is not blocked on the above.\n\n## 2. Already answered by what shipped\n\n- **\"the $50 deposit is actually 50 per dog so I just wanted to mention that how will that track?\"**\n (6 Aug 9:02 PM). Already built, and watched live at 03:13:02Z on 7 Aug: Jeffrey Musselwhite's row\n reads *\"The deposit on this stay is $150.00 (3 dogs at $50)\"*. It settles on one payment for the\n full amount, or one $50 per dog, and on nothing else.\n- **Thanksgiving.** She wrote \"it is the third Thursday of every November\". It is the **fourth**.\n She was corrected on 6 Aug (\"the fourth Thursday, the 26th this year\") and the code works it out\n fresh each year rather than storing a date. She restated the wrong version *after* being told, so\n it is worth confirming the correction landed.\n- **The old puppy workflow** — *\"has never been used so it can be turned off at any time\"*\n (6 Aug 5:03 PM). That removes one leg of the three-part go-live.\n\n## 3. New asks, not started\n\n| | Ask | Notes |\n|---|---|---|\n| a | **Free Training Day pick-up calendar** | 30 minutes, first booking 3:30pm, last start 4:30pm, all done by 5pm, all the usual appointment workflows |\n| b | **Secondary Pup Talk calendar** | A copy of the existing one under a different name, so the team can see at a glance who is making the call. For Candace to book a talk directly with a trainer |\n| c | **Pups Club self-unsubscribe** | Subscribers need a way to unsubscribe themselves |\n| d | **Tag cleanup** | Remove tags that came with the system and are never used. Plus *\"is there a way to set up tracking when a tag is applied?\"* — her CRM does not record tag timestamps, only that a record changed, so this needs a real answer rather than a yes |\n| e | **Free Training Day workflow rebuild** | Milton edited it on 5 Aug. She confirms **the abandoned-booking workflow is hers** and is open to redoing it: *\"take a look at what it already does and we could probably clean it up\"*. This resolves the pending exit-rule question — but it is a live workflow of hers and should be changed with her watching |\n| f | **Puppy nurture additions** | A note on water intoxication in dogs for the July/August messages, and kids going back to school in August |\n| g | **Website bootcamp deposit** | She says it should read **$500**, and *\"the payment was actually set up to go onto PayPal and not through Square\"*. The handover pack records $250. **Her word overrides the pack** — confirm which figure is current before anything is published |\n| h | **Retargeting ad** | She put videos in a Drive folder; a retargeting ad was to be discussed |\n| i | **Cost against revenue** | *\"I absolutely wanna know what all this costs against what it brings in go ahead and do what needs to be done\"* — explicit approval to build the reporting |\n\n## 4. Copy changes she asked for — her words about her own voice\n\n- **Touch 2, \"I got your message\"** — drop it. *\"What message am I replying to exactly?\"* Keep the\n welcome, lose the reply framing.\n- **\"it's a conversation, not a pitch\"** — keep the first half, cut the second. *\"I don't like that\n it keeps saying that it's not a pitch. Can we just leave off the part about the pitch and just\n tell them what it is rather than what it isn't.\"*\n- **\"I won't chase you\"** and the no-show/no-sale negatives — same rule. *\"I'd rather remove\n language about what I won't do and leave the more positive language in there that says they can\n call, they can reach out anytime.\"*\n- **\"how you're getting on\"** → **\"how it's going\"**. British.\n- **Kim's name vs the business name.** A positioning decision, not a find-and-replace: *\"is there a\n way to use the business name The Dogs Spot instead of my personal name or mix the two... if\n they've only ever been hearing from Kim they'll never get me on the phone but they'll get my\n team.\"* There is a real trade-off — a named human outperforms a business name on reply rate,\n which is why it reads that way now. She should hear the trade-off before it changes.\n\n## 5. Open questions of hers with no answer yet\n\n- **Candace's app freezing when loading messages.** The one measurable fact so far: the account\n holds ~5,500 conversations and loading them serially looks exactly like a freeze. Two screenshots\n sent showing where the list stops.\n- **\"of the 175 new inquiries is that total new chats or is that based off each answer Ava provides\n thus inflating the numbers\"** — a direct question about whether a headline number on her own page\n is inflated. Needs a real answer, not a reassurance.\n- **\"Chloe was edited around 10:30 last night wasn't me is there anyway that you can see who did\n it?\"**\n- **\"The counter sales at unmatched how do I track where that came from and why is this\n happening?\"**\n- **The access key.** *\"it shows me times but it doesn't show me dates of messages so I think I\n deleted the access key.\"* Her page may be broken for her right now — worth checking first.\n- **thedogsspotga.com** is Wix + Google. *\"I'm happy to add the 4 lines but would need instructions\n on how and where to do it.\"* She is willing; she needs step-by-step.\n- **A contact with a Meet and Greet booked has no active workflow for it.** She noticed and asked.\n\n## 6. Ledger — questions for Kim, still unanswered\n\n1. The boarding cancellation policy. Nothing on her website.\n2. Do the Thanksgiving window edges (Monday before to Sunday after) match what she wants?\n3. Does she offer daycare, and at what price? Her own biography says the facility does; there is no\n page, no hours, no price. Her instruction was to remove the word from customer copy, which is\n why it also came off the dashboard footer on 7 Aug.\n4. **New:** is the bootcamp deposit $500 or $250, and does it go to PayPal or Square?\n5. **New:** does she want the deposit tracker as built, or the enforcing version she described?\n\n## What was not done\n\nNothing was sent to Kim, no workflow of hers was edited, no calendar was created. Everything above\nis recorded for Amir to act on. The deposit scope mismatch (§1) is the one that should not wait.\n\n---\n\n## UPDATE, 7 August 17:5x UTC, after re-reading the thread\n\n**No message was sent to Kim today.** The Upwork thread was reloaded fresh and it ends at her\n3:58 PM message. The brief for this session described a message sent this morning covering the\ndeposit correction, an apology for the silence, three promised reports and the bootcamp question.\nThat message does not exist in the thread. So none of it has reached her, and the deposit\ncorrection in particular is still owed rather than done.\n\nEverything in section 1 above therefore still stands, unchanged: she believes the deposit feature\nblocks a booking. The draft at `handover/MESSAGE-TO-KIM-7-AUG.txt` makes that correction in its\nfirst section, which is where it belongs.\n\n### Answered this session, with verified figures\n\n- **\"of the 175 new inquiries is that total new chats or is that based off each answer Ava\n provides\"** — 175 is new CONTACT RECORDS. Not chats, not inflated by Ava, whose messages are\n outbound and cannot create a contact. Verified two independent ways. 246 distinct people wrote in\n that week, 175 new and 71 returning, so the headline undercounts activity rather than inflating it.\n- **\"I absolutely wanna know what all this costs against what it brings in\"** — cost side answered\n in full ($718.98 for the week). Return side cannot be answered: 0 of 5,768 opportunities are\n marked won, all time. That finding is the most valuable thing produced this session.\n- **The attribution gap** — Facebook claims 127 conversations over the six days both systems cover;\n the CRM took 149 new contacts in the same window; 120 of those have no source at all and none is\n attributed to Facebook.\n\n\n\n=====FILE handover/SWEEP-7-AUG.md =====\n# REGISTER — sweep of 7 August, both inboxes plus Upwork and calendar\n\nSwept 7 Aug 23:16 to 23:35 UTC. Windows: last 3 days on both mailboxes.\n\n## What was actually read, and what was not\n\n- **aizhigitovamir@gmail.com** — 201 threads in the window, listed in full, then filtered by\n targeted search on 12 Kim related terms. **Zero direct emails from Kim.** Every Kim item in this\n mailbox is an Upwork notification for a message already read and answered in the thread.\n- **iziguickbooks@gmail.com** (Kim's business account) — inbox listed, 340 conversations, 253\n unread overall, 38 in the last 3 days. The top of the list was read and the critical thread\n opened in full.\n- **Upwork** — both rooms read end to end in an earlier pass. Nothing new since Kim's 3:58 PM\n message, which has been answered.\n- **Calendar** — all events 5 to 16 Aug pulled. Every one is Amir's personal routine. **No client\n meeting of any kind is booked.**\n\n**Not finished, and it matters:** in Kim's mailbox I read the top of the list and one thread in\nfull. Roughly 30 of the 38 recent conversations were seen as sender and subject only, and the 253\nolder unread were not touched. Gmail's list would not yield to text extraction so each thread costs\na click. Item 1 below was found in the first screen, which is a good argument for finishing the\nrest rather than assuming the rest is noise.\n\n---\n\n# TIME SENSITIVE\n\n## 1. THE KRISTIAN WALKTHROUGH IS SUNDAY, AND IT IS NOT IN AMIR'S CALENDAR\n\n**Kristian Moore, 7 Aug 21:57, to Kim and Amir:**\n> \"Hi Kim, I have sent a calendar invite for Sunday at 3:00 p.m. EST. Additionally, I confirm that\n> I have no disagreement regarding the stated goals. I look forward to walking through the system\n> with you and Amir.\"\n\n- **Sunday 9 August, 3:00 pm EST, which is 8:00 pm BST.** Under two days away.\n- The calendar invite went to **iziguickbooks@gmail.com**, Kim's address, from an address Google\n flagged as \"unknown sender\". It is sitting unaccepted in her inbox.\n- **It is in no calendar Amir holds.** Confirmed by pulling every event from 5 to 16 August.\n- This is the acceptance walkthrough. Kim asked Amir to be on it on 3 August. Kristian has now\n confirmed he expects Amir there.\n\n**If nobody touches this:** Amir misses the call, or joins cold. Kim walks into an acceptance\nreview, alone, on software she has been advised not to accept yet, with a signature page at the end\nof it and a 30 day warranty clock attached. That is the single most expensive thing in this\nregister.\n\n**Status: BLOCKED on Amir.** Accepting a calendar invite is his identity and his diary. The prep is\nDONE and waiting: `handover/Before-the-walkthrough-with-Kristian.pdf`, four pages, written before\nthis call was scheduled and still current.\n\n## 2. KRISTIAN HAS ANSWERED THE PRE CALL QUESTIONS\n\nKim, 7 Aug 18:49, replying to him: *\"Thank you. This answers a number of the questions I had,\nparticularly around what was completed in GHL and how the application is intended to inter...\"*\n\nThose are the five questions drafted for her on 4 August: deployment status, who owns the boarding\nbooking link, what changed in GHL during July, the calendar list, and what the app writes back.\n\n**Status: BLOCKED, needs reading before Sunday.** The full text is in that thread and was not\nextracted in this pass. It is the difference between a short call and an hour of discovery.\n\n## 3. MANYCHAT PAYMENT HAS FAILED, AGAIN\n\n**Manychat, Inc., 7 Aug 17:30:** *\"$39.00 payment to Manychat, Inc. was unsuccessful again\"*\nAlso 17:05: VAT now applied to the subscription in the United Kingdom.\n\nThe word \"again\" is the problem. Manychat sits on the Facebook side of her funnel, and Facebook is\nwhere 538 of last week's 748 inbound messages came from. If it suspends, the thing that stops is\nlead capture from her largest channel, and it will not announce itself.\n\n**Status: BLOCKED.** Fixing a failed card is money and identity. Neither is ours to touch.\n**What unblocks it:** Kim updates the card on the Manychat billing page. Draft below.\n\n## 4. THE CHLOE ISSUES EMAIL, SENT TO KRISTIAN AND AMIR TOGETHER\n\n**otchx4@gmail.com, 7 Aug 18:05:** *\"Hi Kristian and Amir, I'm sending this to both of you because\nwe identified several issues with Chloe on actual...\"*\n\nChloe is Kristian's bot. Kim said on 3 August she has not wanted to raise issues with him because\nhe can be mercurial. Something has now been raised with both of them, two days before the\nacceptance call.\n\n**Status: BLOCKED, needs reading before Sunday.** Not read in full in this pass.\n\n## 5. KIM ASKED FOR THE REPORT BY EMAIL AS WELL AS UPWORK\n\n**Kim Hicks, 7 Aug 21:34, \"Fridays report\":** *\"Hi Amir, I'm looking forward to seeing the report\nfor today when you get a chance. Thanks Kim Hicks\"*\n\n**Status: DONE.** The message went at 23:46 and the five page PDF at 00:03, both on Upwork, both\nwatched landing. She asked on email and was answered on Upwork, so if she is watching email she has\nnot seen it yet. Worth a one line email pointing at it. Draft below.\n\n---\n\n# EVERYTHING ELSE, FROM THE EARLIER REGISTER, UNCHANGED\n\nDates now promised to her in writing: Monday the July ROAS tracking check and her page showing\ntimes but no dates. Tuesday both calendars. Wednesday tag cleanup and the free training day\nworkflow rebuild. Thursday Pups Club self unsubscribe. Full detail in `REGISTER-AUG7.md`.\n\n---\n\n# NOT KIM — handoff only, untouched, do not act on from this session\n\n| From | What |\n|---|---|\n| Ashley Ryan, via Asana | Task assigned to Amir, \"Ariel Tracking\", **due Monday 10 August** |\n| Ashley Ryan, via Asana | Comment asking for Amir's Facebook details to add him to an ad account |\n| Ashley Ryan, via Asana | Comment asking how to add Amir to her personal FB business manager to fix a domain |\n| Ashley Ryan, via Asana | Comment on \"set up check out for 333\", mentions $1998 |\n| Ariel Daunay | Google Tag Manager access invitation |\n| ash@cocreators.club | Google Tag Manager access invitation |\n| Ariel Daunay | Google Analytics access granted |\n| ash@cocreators.club | Google Analytics access granted |\n| Microsoft Clarity | Two project invitations, Ariel Daunay and CoCreators |\n| Revolut | W-8BEN form has expired |\n| Microsoft Azure | Free credit expired 7 August, resources deleted |\n| Mint People | Bar shift offered for Saturday 8 August, Swindon |\n| Trading 212 | Terms updating |\n| Upwork | Roughly 20 job alerts |\n| Assorted | Glassdoor, Indeed, Leisurejobs, Skool, eBay, AliExpress, Just Eat, marketing |\n\nThe Ariel Daunay and CoCreators work is a different client on a different stack. Acting on it from\na session holding Kim's credentials is how one client's data ends up in another's account.\n\n\n\n=====FILE handover/AUTOPILOT.md =====\n# AUTOPILOT — running Kim's account while Amir is away\n\nWritten to be executed. Ranked by what protects the relationship first, revenue second, tidiness\nlast. Assume no replies, no approvals, no clicks from Amir.\n\n## THE HARD STOPS. These are never done without him, however obvious they look.\n\n1. Anything that reaches one of Kim's customers. No message, no workflow switched live, no tag that\n triggers one. Practice mode holds.\n2. Anything that costs money or fixes a payment. The Manychat card included.\n3. Anything irreversible. Deleting tags, contacts, workflows, calendars.\n4. Anything needing his identity. Accepting the Kristian invite, joining the call, replying to Kim,\n accepting access invitations.\n5. Editing a live workflow of hers. She has said she is open to the free training day rebuild, and\n she has still not watched it happen.\n\nEverything below respects those five without exception.\n\n## FIRST FIVE ACTIONS, IN ORDER\n\n1. **Read the Kristian thread in full and write the Sunday brief.** 40 minutes. Done means: his\n answers to all five pre call questions extracted verbatim, each marked answered, partly answered\n or dodged, and a one page sheet Amir can hold during the call. The existing four page note is\n still valid; this sits on top of it.\n2. **Read the Chloe issues email and place it.** 20 minutes. Done means: the issues are listed, each\n one marked as Kristian's, ours, or GoHighLevel's, and any that are ours are fixed or dated\n before Sunday.\n3. **Check the July ROAS tracking is still filling in.** 60 minutes. Promised to Kim for Monday.\n Done means: a named date when a paying customer was last matched to an ad, watched live, or a\n plain statement that it stopped and when. Until this exists no return figure goes to her.\n4. **Reproduce her page showing times but no dates.** 30 minutes. Promised for Monday. Done means:\n loading her exact link, seeing what she sees, and either the fix deployed and reloaded, or a\n written statement of what is actually wrong.\n5. **Finish the sweep of her inbox.** 45 minutes. The 30 conversations seen as subject only, then\n the 253 older unread. Done means every one opened and placed in the register. Item 1 of the\n register was found in the first screen, which is the argument for finishing.\n\nThen, in order: both calendars, tag cleanup, the free training day rebuild, Pups Club unsubscribe.\nEach is a promise with a date on it in her inbox.\n\n## IF SHE MESSAGES WHILE HE IS AWAY\n\nFour drafts sit ready in `handover/DRAFTS-WHILE-AWAY.md`, written so Amir can send one from his\nphone in thirty seconds. They cover: chasing the report, asking to go live, asking about the\ndeposit blocking version, and asking why something is late. None of them is sent by anyone but him.\n\nIf she raises something none of them covers, the rule is a holding reply within the hour that says\nwhat is being done and when, never silence. Silence is the thing that caused this week.\n\n## IF SOMETHING BREAKS\n\n| What | How it is detected | Done automatically | Safe without Amir | Must wait |\n|---|---|---|---|---|\n| Deposit refresh stops | The card shows its own age, and says so past 36 hours | Nothing, by design. It degrades to a visibly older list rather than a wrong one | Re-run the collection by hand, read only | Nothing |\n| CRM token expires | Every collection returns could not check, and the card says so | Refuses to overwrite good data with unreadable data | Diagnose and report | Regenerating the token. His identity |\n| A calendar stops answering | calendarsRead drops below calendarsAsked | Refuses to store a shorter list over a longer one, since 7 Aug | Diagnose | Nothing |\n| Manychat suspends | No automatic detection today. This is a gap | Nothing | Watch her Facebook inbound volume against last week's 538 and flag a drop | Paying the bill |\n| A workflow messages a booked customer | Only by her noticing, as with Thomas | Nothing. The exit rule is not built | Draft the fix and the test | Applying it to a live workflow |\n| The engine stops | The watchdog val, and the dashboard banner turns amber or red in plain words | Watchdog reports | Redeploy from the bundle | Nothing |\n\nThe honest gap in that table is Manychat and the workflow exit rule. Both are detected by a human\nnoticing. Neither is safe to close alone.\n\n## WHAT RUNS ON A SCHEDULE, AND HOW I KNOW IT RAN\n\n- **The holiday deposit refresh, hourly**, labelled `deposits-cron`. Observed running by itself\n seven times, the last at 16:08:21Z on 7 August, read from the endpoint without `run=1` so it\n cannot be a person. Verified by reading `lastAttemptAt` and `lastAttemptBy` on the endpoint. If\n `lastAttemptBy` is missing or the stamp is over two hours old, it stopped.\n- **The engine's own interval.** Same gate, same function, so the two cannot drift.\n- Nothing else runs. Nothing sends.\n\n## THE STATE FILE\n\n`handover/RESUME.md`, updated as work happens rather than at the end. It carries what is done, what\nis in flight, what is blocked and why, the live URLs, and the recovery procedure. The container\nreverted five times on 7 August, so the rule is: rebundle the moment the tree is green, and if a\nsession starts cold, run `node scripts/restore.mjs` before anything else.\n\n## WHAT MUST BE TRUE WHEN HE IS BACK FOR THIS TO HAVE BEEN A GOOD WEEK\n\n1. Kim never waited more than a few hours for an answer, and never had to ask twice.\n2. Sunday's call happened with Amir on it and a one page brief in his hand, and nothing was signed.\n3. Every date promised in Friday's message was met, or she was told before it slipped, not after.\n4. No customer of hers received anything. Practice mode held.\n5. The return on ad spend question has a real answer or a plainly stated reason it does not.\n\n\n\n=====FILE handover/DRAFTS-WHILE-AWAY.md =====\n# DRAFTS READY TO SEND — Amir sends, nobody else\n\nNo dashes anywhere. Answer in the first line. Send as is or cut.\n\n---\n\n## 1. SUNDAY CALL — send this tonight or first thing. Everything else can wait, this cannot.\n\nSubject: Sunday 3pm, I will be there\n\nKim,\n\nI have seen Kristian's note about Sunday at 3pm your time. I will be on it.\n\nThe invite went to your inbox rather than mine, so send it across when you get a minute and I will\naccept it properly. Worth checking it lands in your calendar too, because Google flagged it as\ncoming from an unknown sender, which means it may be sitting in your inbox rather than on your day.\n\nI have the briefing note ready, four pages, and I will send you a one page version on Sunday\nmorning so you are not reading anything long before the call.\n\nOne thing to hold on to during it. He is walking you through software that has never run on your\nsystem. You can watch it, ask about it, and like it. Accepting it, and starting the 30 day warranty\nclock, is a separate decision and it does not have to happen on the call.\n\nAmir\n\n---\n\n## 2. MANYCHAT — send alongside the above\n\nSubject: Manychat card has failed twice\n\nKim,\n\nManychat has tried to take $39 twice and both times it failed. The second email says \"unsuccessful\nagain\", so this is not a one off.\n\nWorth two minutes because of where it sits. Facebook brought 538 of the 748 messages that came in\nlast week, which is nearly three quarters of everything, and Manychat is on that side of the funnel.\nIf it suspends, the thing that quietly stops is Facebook lead capture, and it will not announce\nitself.\n\nThe fix is a card update in Manychat billing. I have not touched it because it is your money and\nyour card, and I am not going near either.\n\nAmir\n\n---\n\n## 3. IF SHE CHASES THE REPORT AGAIN\n\nKim,\n\nIt went over on Upwork on Friday night, the message and a five page PDF. You emailed about it at\n9:34 and I answered on Upwork, so if you are watching email you will not have seen it.\n\nSay the word and I will send everything to your email from now on instead. Easier for you to have\nit in one place than to remember which channel a thing arrived on.\n\nAmir\n\n---\n\n## 4. IF SHE ASKS TO GO LIVE ON THE PUPPY FOLLOW UP\n\nKim,\n\nYes, and it is one move now rather than three, because you confirmed the old puppy workflow has\nnever been used.\n\nThe move is: ours on, the old one off, the tagging on, in that order and in one go. Doing it in\npieces is exactly what happened to Thomas, where two systems both thought he was theirs.\n\nGive me a window when you are at a screen and we will do it together, so you watch the first one go\nout rather than hear about it afterwards. Twenty minutes.\n\nAmir\n\n---\n\n## 5. IF SHE ASKS ABOUT THE DEPOSIT BLOCKING VERSION\n\nKim,\n\nShort answer, yes it can be built, and it is worth being clear about what changes for your\ncustomers before you decide.\n\nTo stop a booking completing without a deposit, the booking has to move off the form on your website\nand into the CRM. That means the link your customers use changes, and the page they land on looks\ndifferent. The software part is straightforward. The part worth thinking about is whether you want\nyour holiday booking journey to change in the run up to Thanksgiving.\n\nThe version running now lists who has paid and who has not, so nothing is chased by memory. That\nholds fine through this season if you would rather move the bigger change to January.\n\nAmir\n\n---\n\n## 6. IF SOMETHING BREAKS AND SHE NOTICES FIRST\n\nKim,\n\nI can see it and I am on it. Here is what I know so far and what I do not.\n\n[what is broken, in her words]\n[what it does and does not affect, specifically who if anyone was contacted]\n[what I am doing, and when I will next tell you something]\n\nNothing has gone to a customer.\n\nAmir\n\n---\n\n**Rule for anything not covered:** a holding reply within the hour saying what is being done and\nwhen she will hear next. Never silence. Silence is what caused this week.\n\n\n\n=====FILE handover/MESSAGE-TO-KIM-7-AUG.txt =====\nHi Kim,\n\nSorry this is late in the day. Your Friday report is here and it should have reached you this\nmorning. Busy day at my end, which is a reason and not much of an excuse.\n\nI also went quiet for two days before that. You should not have had to ask twice.\n\nTaking everything in order.\n\nTHE DEPOSIT, AND A CORRECTION YOU NEED BEFORE ANYTHING ELSE\n\nYou asked whether I was setting it up so a holiday booking cannot be confirmed until the deposit is\npaid. I am not. I did write this on Thursday and it clearly did not land, which is my fault for\nburying it in a long message rather than yours for missing it. So, plainly this time.\n\nWhat is built and running reads your Square payments and gives you one list of who has paid and who\nstill needs checking. It lists. It does not block. Nobody is stopped from booking.\n\nBlocking the booking is a different and bigger job, because it means holiday bookings stop going\nthrough the form on your website and start going through the CRM instead. That changes where your\ncustomers book, which is a change to your business rather than to software. Worth talking through\nbefore either of us commits to it.\n\nTwo things that are already done inside the version that exists. It counts $50 per dog, so a three\ndog stay reads $150. And it works Thanksgiving out fresh every year rather than storing a date.\n\nThe nonrefundable wording you asked for I can add this week, and it does not depend on the above.\n\nTHE FRIDAY REPORT\n\nFacebook, Google and your CRM, for 31 July to 6 August. Every number came out of the platform today.\nNothing carried over, nothing estimated. Where a figure could not be verified I have written that\ninstead of filling the gap. The full one page version comes over right behind this message.\n\nThe short version. You spent $718.98 on ads. Facebook took $554.98 and started 127 conversations at\n$4.37 each. Google took $164.00 and brought 80 clicks and 4 conversions at $41.00 each. 175 new\npeople came into the CRM, down 22 on the week before. 55 appointments, 38 showed.\n\nTwo campaigns are carrying Facebook. Kims New Except4Ads#2 and the April 10th copy brought 91 of\nthose 127 conversations at under $3.90 each. Training Tips is your dearest at $6.21.\n\nTHE ANSWER TO WHAT IT COSTS AGAINST WHAT IT BRINGS IN\n\nYou asked for this and it is the honest half of the report. The cost side is solid and it is above.\nThe return side cannot be answered yet, and the reason matters.\n\nYour CRM holds 5,768 opportunities. The number marked won is zero. Not zero this week. Zero ever.\nOne record sits in a stage called Won, Paid and is flagged lost, and it is a test record.\n\nSo nothing in the system knows what a booking is worth, which means nobody can honestly divide money\nspent by money earned. Anyone who shows you a return on ad spend figure today is guessing.\n\nBefore I put a return figure in front of you I want to check the tracking we built in July, the one\nthat ties a paying customer back to the ad that brought them. It needed a few minutes of manual\nmatching each week to stay accurate, and if that slipped while everything else was going on then the\nfix is small. I would rather confirm that than invent a number. Monday.\n\nRelated, and worse. Over the six days Facebook and your CRM both cover, Facebook says it started 127\nconversations and your CRM took in 149 new people. Close enough to be the same people. But 120 of\nthose 149 have no source recorded at all, and not one is attributed to Facebook. So the money went\nout and the people came in, and nothing connects the two. Closing that is the difference between a\nreport describing your week and a report telling you where to put the next dollar.\n\nTHE 175, SINCE YOU ASKED WHAT IT COUNTS\n\nIt is 175 new contact records, one per new person. Not chats, and not inflated by Ava. Ava sends\noutbound messages and an outbound message never creates a contact.\n\nTwo checks. Real inbound messages that week were 748 and outbound were 1,143, so 175 cannot be a\nmessage count. And 246 different people wrote to you that week, 175 new and 71 returning. If\nanything the headline undercounts how busy you were.\n\nGOING LIVE ON THE PUPPY FOLLOW UP\n\nYou told me the old puppy workflow has never been used and can go off any time. That was the piece I\nwas waiting on. It is now one coordinated move rather than three, and I can do it whenever you say.\n\nYOUR COPY CHANGES\n\nAll noted and all going in. Touch 2 loses \"I got your message\" and opens on the welcome. The pup talk\ncopy says what it is and stops saying what it is not. The no show and no sale messages lose \"I won't\nchase you\" and keep the line about calling any time. \"Getting on\" becomes \"going\". Water intoxication\nand back to school go into the July and August notes.\n\nYour name versus the business name is the one I do not want to change quietly, because there is a\nreal trade off. Messages from a named person get replied to more often than messages from a business.\nWhat you are describing is a good reason to change it anyway, so I would rather talk it through than\nguess. Worth ten minutes when you are back.\n\nTHE TWO CALENDARS\n\nFree training day pick up, 30 minutes, 3:30pm to a 4:30pm last start, all done by 5pm, usual\nworkflows. And the second pup talk calendar as a copy of the first under its own name. Both by\nTuesday.\n\nWHAT I HAVE NOT DONE YET, WITH DATES\n\nYour page showing times but no dates. I have not reproduced it yet and I will not tell you it is\nfixed until I have. Monday.\n\nTag cleanup and the unused tags in the drop down, Wednesday. Your CRM does not record when a tag was\napplied, only that a record changed, so tracking that properly needs a small piece built rather than\na setting switched. I will show you what it can and cannot do before building it.\n\nThe free training day workflow rebuild, Wednesday. You said the abandoned booking one is yours and\nyou are open to redoing it. I would rather do that with you watching than edit a live workflow of\nyours while you are away.\n\nPups Club self unsubscribe, Thursday.\n\nCandace's app freezing. Still on it. The one measurable thing so far is that your account holds five\nand a half thousand conversations and loading them one at a time looks exactly like a freeze.\n\nBOOTCAMP DEPOSIT\n\nYou told me it should read $500 and that the payment was set up to go to PayPal rather than Square. I\nhave taken that as the answer and I am building it both ways so whichever it turns out to be is a\nfive minute change, not a rebuild.\n\nNothing has sent to anybody. Everything stays in practice mode until you say the word.\n\nAmir\n\n\n\n=====FILE reports/Friday-Report-7-Aug-2026.html =====\n\n\n\nThe Dogs Spot, week of 31 July to 6 August 2026\n
\n\n
The Dogs Spot, week of 31 July to 6 August 2026
\n
Read live from each account on Friday 7 August. Every figure below came out of the\nplatform itself. Nothing is carried over from last week's file and nothing is estimated.
\n\n
\n
Spent on ads
$718.98
\n
Facebook $554.98, Google $164.00
\n
New people in the CRM
175
\n
22 fewer than last week
\n
Appointments
55
\n
9 fewer than last week, 38 showed
\n
Cost per new person
$4.11
\n
ceiling, since not every lead is paid for
\n
\n\n
\n
The thing worth two minutes
\n
You asked what all this costs against what it brings in. The cost side is solid and it is in this\nreport. The return side I can only half answer this week, and I would rather show you the seam than\npaper over it.
\n
Your pipelines are not recording wins. Of 5,768 opportunities in the CRM, the number marked won is\nzero, and that is true for every week, not just this one. So the pipeline view cannot tell you what a\nbooking was worth.
\n
Money is being recorded, though, somewhere else: 232 payment transactions and 195 orders sit in\nyour account. Only three of those transactions fall inside this week, which does not match a business\ntaking bookings all week, so either most payments are landing outside the CRM or they are landing in\na place this report has not read yet.
\n
There is also the tracking we built in July, which ties a paying customer back to the ad that\nbrought them and feeds the ad performance dashboard. Before I put a return figure in front of you I\nwant to confirm that is still running and still filling in, because it needed a few minutes of manual\nmatching each week to stay accurate. That check is Monday, and then you get the real number rather\nthan a tidy one.
\n
\n\n
Facebook
\n
Account DPU: The DogsSpot. Window 31 July to 5 August. Meta's own date picker will not\nrun to the 6th yet, so this is six days where the rest of the report is seven. Four campaigns of your\n35 were live.
\n\n
\n
Spent
$554.98
4 live campaigns
\n
Conversations started
127
Messenger
\n
Cost per conversation
$4.37
blended across the four
\n
\n\n
Where the money went
\n
\n
Kims New Except4Ads#2
\n
$180.64
\n
APRIL 10th Fresh February Leads - Copy
\n
$170.89
\n
Email CSV AI Campaign
\n
$116.49
\n
Training Tips-Messenger Leads-6/26
\n
$86.96
\n
\n\n\n\n\n\n\n\n\n\n
Campaign Spent Conversations Cost each
Kims New Except4Ads#2 $180.64 47 $3.84
APRIL 10th Fresh February Leads - Copy $170.89 44 $3.88
Email CSV AI Campaign $116.49 22 $5.30
Training Tips-Messenger Leads-6/26 $86.96 14 $6.21
Free Training Day Website 6/19 $0.00 0 off
Total $554.98 127 $4.37
\n\n
\n
What I read into it. Two campaigns are doing the work. Kims New Except4Ads#2 and\nthe April 10th copy brought 91 of the 127 conversations at under $3.90 each. Training Tips is the\nweakest at $6.21, roughly 60 percent more expensive per conversation than your best, on the smallest\nbudget. If you want a cheap experiment next week, move the Training Tips budget onto the April 10th\ncampaign and see whether the cost per conversation holds when it gets more money. That is a real\ntest rather than a tidy up, because the usual result is that costs rise with budget, and it is\nbetter to find that out at $15 a day than at $30.
\n
\n\n
Google
\n
Account 942-544-7945, The Dogs Spot. Window 31 July to 6 August. Six campaigns.
\n\n
\n
Spent
$164.00
\n
Clicks
80
from 970 impressions
\n
Cost per click
$2.05
\n
Conversions
4
$41.00 each
\n
\n\n\n\n\n\n\n\n\n
Measure This week How it is worked out
Cost per click $2.05 $164.00 divided by 80 clicks
Cost per conversion $41.00 $164.00 divided by 4 conversions
Click through rate 8.25% 80 clicks divided by 970 impressions
Your share of available searches 32% Google's figure, up from 29%
Rover's share of the same searches 24% Google's figure, up from 22%
\n\n
\n
What I read into it. An 8.25 percent click through rate is strong for local\nsearch, so the ads themselves are working. Google is the smaller spend and the more expensive lead\nat $41 against Facebook's $4.37, but they are not the same thing being bought. A Google click is\nsomebody typing \"dog boarding Savannah\" at the moment they need it. A Facebook conversation is\nsomebody who was scrolling. The Google number is only bad if those four conversions are worth less\nthan $41 each, and right now nothing in the CRM records what any of them were worth, which is the\nsame gap as above. You are also gaining ground on Rover, up three points against their two.
\n
\n\n
Your CRM
\n
Window 31 July to 6 August. Every figure here was pulled from the CRM and then worked\nout a second time, from the raw data, by somebody who had not seen the first answer. All 23 figures\nagreed.
\n\n
\n
New people
175
was 197
\n
Messages in
748
1,143 went out
\n
Calls
120
96 answered, was 66
\n
Appointments
55
38 showed, 2 no shows
\n
\n\n
Where the 175 came from
\n\n\n\n\n\n\n\n
Channel Messages in Notes
Facebook 538 72% of everything that came in
Phone 71 120 calls in total, 24 unanswered
Text 71
Instagram 46
Email 4
\n\n
\n
The 175, since you asked what it counts
\n
It is 175 new contact records, one per new person. It is not a count of chats and it is not\ninflated by Ava. Ava sends outbound messages, and an outbound message never creates a contact.
\n
Two checks confirm it. Real inbound messages that week were 748 and outbound were 1,143, so 175\ncannot be a message tally. And 246 different people sent you something that week, 175 of them new\nand 71 returning, so if anything the headline undercounts how busy the week was.
\n
\n\n
\n
The gap between what the ads claim and what your CRM received
\n
This is the most useful line in the report, and it is not good news yet.
\n
Over the six days both platforms cover, Facebook says it started 127 conversations.\nYour CRM took in 149 new people over the same six days. Those two numbers are close\nenough to be the same people. But of those 149, only 29 carry any source at all, 120 have nothing\nrecorded, and not one is attributed to Facebook.
\n
So the honest position today is that $718.98 went out, 175 people came in, and nothing in your\nsystem can tell you which ones the money bought. That is not a reporting problem I can write around.\nIt is a tracking gap, and closing it is the difference between this report describing your week and\nthis report telling you where to put your next dollar.
\n
\n\n
Appendix, every number and where it came from
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Figure Value Source and method
Facebook spend $554.98 Ads Manager, account 938090411743620, 31 Jul to 5 Aug, sum of the four live campaigns
Facebook conversations 127 Same view, sum of the Results column
Facebook cost per conversation $4.37 554.98 divided by 127
Facebook consistency check 4 of 4 Each campaign's spend divided by its results matches Meta's own cost per result to the cent
Google spend, clicks, impressions, conversions $164, 80, 970, 4 Google Ads overview, account 942-544-7945, 31 Jul to 6 Aug
New contacts, this week and last 175 and 197 CRM contact search on date added, converted to New York time before bucketing, two independent pulls agreed
Appointments 55 and 64 All 29 calendars queried one at a time, 197 raw events, bucketed on start time
Messages in and out 748 and 1,143 660 conversations pulled in full, 15,488 messages, system audit entries excluded
Calls 120, 96 answered Call type messages, answered means completed
Opportunities won, all time 0 All 5,768 opportunities paginated: 5,594 open, 174 lost, 0 won, 0 abandoned. This is the pipeline view only, not a statement about money received
Payment records in the CRM 232 and 195 Transactions and orders. Three transactions fall inside this week, which is being checked before any return figure is quoted
Contacts with no source, 31 Jul to 5 Aug 120 of 149 Source field on each new contact record
\n\n
Two honest limits. Meta's date picker stops at 5 August, so the Facebook figures cover\nsix days and everything else covers seven, and the reconciliation above deliberately compares only\nthe six days both cover. And campaign names are printed exactly as they appear in Ads Manager, so\nyou can find them, which is why some of them read oddly.
\n\n
Built by hand this week. The automated version that fills itself in is still being\nbuilt.
\n\n
\n\n\n",[576],"d34a61a7-720b-46e0-aa56-a21ce0397bfb","SOURCE-BUNDLE.part37.txt","3b739f62-9823-11f1-be16-1607ee4eb77e",1086,["D",1786801893866],"THE DOGS SPOT — SOURCE BUNDLE (part 37 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (4 of 116 files)\n handover/bridge-main-v3.10.ts 34877 bytes 58a6e28e17bd\n handover/KRISTIAN-EMAIL-DRAFT.txt 447 bytes 9a790eb0c14e\n handover/TEAM-EMAIL-DRAFT.txt 792 bytes 57a781bd94d4\n scripts/exception-report.mjs 30906 bytes 6aa599065012\n\n================================================================================================\n=====FILE handover/bridge-main-v3.10.ts =====\n// THE DOGS SPOT — Square to GHL Revenue Bridge (M2) + Facebook CAPI (M3) v3.10\n// v3.9 (31 Jul 2026): SQUARE_ACCESS_TOKEN now falls back to blob \"m2_sq_token\" ({t:\"...\"}) when the\n// env var is unset — env vars are UI-only on val.town and were the last blocker on POS matching.\n// Same-priority env var still wins if ever set. No other behaviour change.\n// v3.5 (25 Jul 2026 — the \"GHL createOpp 400\" retry storm + POS attribution):\n// - ROOT CAUSE of the 400: this GHL location has \"Allow duplicate opportunity\" OFF, so a contact\n// may hold exactly ONE opportunity. reconcile() only looked for opps already in the Won-Paid\n// STAGE; any paying customer who existed as a lead first (i.e. almost all of them) looked like\n// \"no opp\" -> POST /opportunities/ -> 400 OPPORTUNITY_NO_DUPLICATE -> throw -> 500 -> Square\n// retried the same event forever. Verified live 25 Jul against contact 4aPkmorlrd6OdZx8gkgu.\n// - reconcile() now reads ALL opps for the contact in the pipeline and only ever adopts/edits one\n// it owns (Won-Paid stage, or the OPP_NAME marker). If the only opp is the CLIENT'S own, it is\n// left completely untouched — its monetaryValue is Kim's sale figure, not our Square balance —\n// and the revenue is journaled as REVENUE-ON-CLIENT-OPP instead. No more hijacking, no retries.\n// - ghlCreateOpp() surfaces GHL's response body instead of a bare status code.\n// - Merges the v3.4 POS path that was written 15 Jul but never deployed (see below).\n// v3.4 (walk-in POS capture, written 15 Jul, DEPLOYED 25 Jul with v3.5): when a payment has no buyer\n// email/phone but DOES carry a Square customer_id (the register attached a customer at checkout),\n// resolve that customer via the Square Customers API, then match the GHL contact. GATED on\n// SQUARE_ACCESS_TOKEN — unset = exact v3.3 behaviour. NO-MATCH rows now record hadCustomerId +\n// sqTokenSet so the review distinguishes \"no identity at all\" from \"had one, couldn't resolve\".\n// v3.3 (revenue-capture fixes, post-live-audit 15 Jul — real payments were logging NO-MATCH):\n// - payment.created/updated now matches by email OR phone (was email-only), and falls back to the\n// invoice-linked contact (PAY_CONTACT) so invoice payments book to the right person.\n// - invoice.payment_made now actually BOOKS revenue (v3.2 linked the contact but never added the amount).\n// It links the payment->contact, then applies any pending payment/refund for that payment id.\n// - Symmetric \"pending payment\" stash: a payment that arrives before its invoice link is held and booked\n// the moment invoice.payment_made supplies the contact (mirrors the existing pending-refund logic).\n// - NO-MATCH rows now record hadEmail/hadPhone + amount so the weekly review is actionable and we can\n// quantify unmatched revenue. No contact is auto-created (avoids polluting the CRM with duplicates).\n// v3.2 hardening (kept): admin-guarded ?dump/?captest/?wipe (fail-closed, constant-time); GHL calls throw\n// on failure -> 500 so Square retries; event marked seen only after success; reconcile() touches only the\n// Won-Paid STAGE; phone normalized to E.164; action_source \"other\"; errors journaled without the fetch URL.\nimport { blob } from \"https://esm.town/v/std/blob\";\n\nconst NOTIFICATION_URL =\n \"https://amir5--41ace24c7e2111f18c9d1607ee4eb77e.web.val.run\";\nconst SQUARE_SIGNATURE_KEY = Deno.env.get(\"SQUARE_SIGNATURE_KEY\") ?? \"\";\nconst SQUARE_ACCESS_TOKEN = (Deno.env.get(\"SQUARE_ACCESS_TOKEN\")\n || (await blob.getJSON(\"m2_sq_token\").catch(() => null))?.t\n || \"\") as string; // v3.9: env var OR blob m2_sq_token fallback (val.town env-var UI unreachable from sessions; blob written 31 Jul via API). v3.4: optional; enables POS customer_id -> email/phone resolution\nconst SQUARE_API = \"https://connect.squareup.com/v2\";\nconst SQUARE_VERSION = \"2025-01-23\";\nconst GHL_TOKEN = Deno.env.get(\"GHL_TOKEN\") ?? \"\";\nconst ADMIN_SECRET = Deno.env.get(\"ADMIN_SECRET\") || GHL_TOKEN; // read-only routes; falls back to GHL_TOKEN\n// v3.6 — the GHL_TOKEN fallback is acceptable for the read-only journal dump (no raw PII in it),\n// but NOT for the two routes that cause real-world side effects. Until a dedicated ADMIN_SECRET\n// exists, ?wipe (deletes every m2_ blob: journal + all ledgers + all dedup/pending state) and\n// ?captest (fires a live Purchase event into the client's Facebook dataset) are DISABLED outright.\n// Anyone holding the GHL token can no longer destroy the bridge's memory or pollute her ad data.\nconst ADMIN_SECRET_DEDICATED = Deno.env.get(\"ADMIN_SECRET\") ?? \"\";\nconst adminStrictOk = (p: string | null) =>\n !!ADMIN_SECRET_DEDICATED && !!p && ctEq(p, ADMIN_SECRET_DEDICATED);\nconst GHL_LOCATION_ID = \"BQHJ19uohldYe3eqA0bl\";\nconst GHL_PIPELINE_ID = \"FXt1UpCVBufbF0v3pfyf\";\nconst GHL_WON_PAID_STAGE_ID = \"ae173310-f8b1-4399-acb7-ef1fc03d3697\";\nconst GHL_BASE = \"https://services.leadconnectorhq.com\";\nconst GHL_HEADERS = () => ({\n Authorization: `Bearer ${GHL_TOKEN}`,\n Version: \"2021-07-28\",\n \"Content-Type\": \"application/json\",\n});\nconst OPP_NAME = \"Square Paid (auto)\"; // bridge-created opp name marker\n\n// M3 — Facebook Conversions API (dataset for The Dogs Spot)\nconst FB_CAPI_TOKEN = Deno.env.get(\"FB_CAPI_TOKEN\") ?? \"\";\nconst FB_DATASET_ID = \"3838731049764356\";\nconst FB_API_VERSION = \"v21.0\";\n\nconst JOURNAL_KEY = \"m2_bridge_journal\";\nconst INBOUND_KEY = \"m2_last_inbound\";\nconst DEDUP_EVENT = \"m2_dedup_event:\";\nconst LEDGER = \"m2_ledger:\";\nconst PAY_CONTACT = \"m2_pay_contact:\";\nconst PENDING_PAY = \"m2_pending_pay:\"; // payment arrived before we could link a contact\nconst PENDING_REFUND = \"m2_pending_refund:\";\n\n// constant-time string compare (used for all admin-guard checks)\nfunction ctEq(a: string, b: string): boolean {\n if (!a || !b || 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}\nfunction adminOk(param: string | null): boolean {\n return !!ADMIN_SECRET && !!param && ctEq(param, ADMIN_SECRET);\n}\n\n// v3.7 — the journal is read-modify-written in full on EVERY event, so unbounded growth costs\n// both storage and per-request time. A single retry storm already put 465 junk rows in it.\n// Hard cap at JOURNAL_MAX; oldest rows fall off. Anything needing permanent retention lives in\n// the per-contact ledgers, not here.\nconst JOURNAL_MAX = 1500;\nasync function journal(row: Record) {\n const j = (await blob.getJSON(JOURNAL_KEY).catch(() => null)) ?? [];\n j.push({ ts: new Date().toISOString(), ...row });\n await blob.setJSON(JOURNAL_KEY, j.slice(-JOURNAL_MAX));\n}\nasync function seen(key: string): Promise {\n const v = await blob.getJSON(key).catch(() => null);\n return v !== null && v !== undefined;\n}\nasync function getBlob(key: string): Promise {\n return (await blob.getJSON(key).catch(() => null)) as T | null;\n}\nasync function remember(key: string, val: unknown = true) {\n await blob.setJSON(key, val);\n}\n\nasync function sha256Hex(input: string): Promise {\n const data = new TextEncoder().encode(input.trim().toLowerCase());\n const buf = await crypto.subtle.digest(\"SHA-256\", data);\n return Array.from(new Uint8Array(buf)).map((b) =>\n b.toString(16).padStart(2, \"0\")\n ).join(\"\");\n}\n// US phone -> E.164 digits (prepend country code 1 for bare 10-digit numbers)\nfunction normPhone(phone: string): string {\n let d = phone.replace(/[^0-9]/g, \"\");\n if (d.length === 10) d = \"1\" + d;\n return d;\n}\n\n// v3.4 — resolve a Square customer_id -> {email, phone} via the Customers API. No-op without a token.\n// This is the POS path: a walk-in payment carries no buyer email/phone, only the customer the\n// register attached at checkout. Without this, every such payment logs NO-MATCH and its revenue\n// never reaches GHL.\nasync function fetchSquareCustomer(\n customerId: string,\n): Promise<{ email?: string; phone?: string }> {\n if (!SQUARE_ACCESS_TOKEN || !customerId) return {};\n try {\n const r = await fetch(\n `${SQUARE_API}/customers/${encodeURIComponent(customerId)}`,\n {\n headers: {\n Authorization: `Bearer ${SQUARE_ACCESS_TOKEN}`,\n \"Square-Version\": SQUARE_VERSION,\n },\n },\n );\n if (!r.ok) {\n await journal({ kind: \"SQ-CUST-ERR\", note: `status ${r.status}` });\n return {};\n }\n const d = await r.json().catch(() => ({}));\n const c = d?.customer ?? {};\n return {\n email: c.email_address || undefined,\n phone: c.phone_number || undefined,\n };\n } catch {\n await journal({ kind: \"SQ-CUST-ERR\", note: \"fetch failed\" });\n return {};\n }\n}\n\nasync function squareSigOk(\n rawBody: string,\n headerSig: string,\n): Promise {\n if (!headerSig || !SQUARE_SIGNATURE_KEY) return false;\n const key = await crypto.subtle.importKey(\n \"raw\",\n new TextEncoder().encode(SQUARE_SIGNATURE_KEY),\n { name: \"HMAC\", hash: \"SHA-256\" },\n false,\n [\"sign\"],\n );\n const mac = await crypto.subtle.sign(\n \"HMAC\",\n key,\n new TextEncoder().encode(NOTIFICATION_URL + rawBody),\n );\n const computed = btoa(String.fromCharCode(...new Uint8Array(mac)));\n return ctEq(computed, headerSig);\n}\n\n// M3 — send a Purchase event to the Facebook dataset. No-op if the token isn't set.\nasync function sendCapiPurchase(\n email: string | undefined,\n phone: string | undefined,\n amount: number,\n eventId: string,\n testEventCode?: string,\n): Promise {\n if (!FB_CAPI_TOKEN) {\n await journal({ kind: \"CAPI-SKIP\", note: \"no FB_CAPI_TOKEN\", eventId });\n return null;\n }\n try {\n const user_data: Record = {};\n if (email) user_data.em = [await sha256Hex(email)];\n if (phone) user_data.ph = [await sha256Hex(normPhone(phone))];\n if (!user_data.em && !user_data.ph) {\n await journal({ kind: \"CAPI-NO-PII\", eventId });\n return { error: \"no PII\" };\n }\n const payload: any = {\n data: [{\n event_name: \"Purchase\",\n event_time: Math.floor(Date.now() / 1000),\n action_source: \"other\",\n event_id: `purchase_${eventId}`,\n user_data,\n custom_data: { currency: \"USD\", value: Number(amount.toFixed(2)) },\n }],\n };\n if (testEventCode) payload.test_event_code = testEventCode;\n const r = await fetch(\n `https://graph.facebook.com/${FB_API_VERSION}/${FB_DATASET_ID}/events?access_token=${\n encodeURIComponent(FB_CAPI_TOKEN)\n }`,\n {\n method: \"POST\",\n headers: { \"Content-Type\": \"application/json\" },\n body: JSON.stringify(payload),\n },\n );\n const d = await r.json().catch(() => ({}));\n // journal only safe fields (never the request URL / token)\n await journal({\n kind: r.ok ? \"CAPI-PURCHASE\" : \"CAPI-ERROR\",\n eventId,\n amount,\n test: !!testEventCode,\n resp: d?.events_received ?? d?.error?.message ?? \"unknown\",\n });\n return d;\n } catch (e) {\n await journal({ kind: \"CAPI-ERROR\", eventId, error: \"fetch failed\" });\n return { error: \"fetch failed\" };\n }\n}\n\n// GHL helpers — every call checks r.ok and THROWS on failure so the webhook returns 500 (Square retries).\nasync function ghlFindContact(\n email?: string,\n phone?: string,\n): Promise {\n for (const [param, val] of [[\"email\", email], [\"number\", phone]] as const) {\n if (!val) continue;\n const r = await fetch(\n `${GHL_BASE}/contacts/search/duplicate?locationId=${GHL_LOCATION_ID}&${param}=${\n encodeURIComponent(val)\n }`,\n { headers: GHL_HEADERS() },\n );\n if (r.ok) {\n const d = await r.json().catch(() => ({}));\n const id = d?.contact?.id ?? d?.id ?? null;\n if (id) return id;\n } else if (r.status >= 500 || r.status === 429 || r.status === 401) {\n throw new Error(`GHL find ${r.status}`);\n }\n }\n return null;\n}\n// v3.5 — every opp this contact has in the bridge pipeline, ANY stage. Needed to tell a\n// bridge-created opp from one of Kim's own before deciding to create.\nasync function ghlPipelineOpps(\n contactId: string,\n): Promise<{ id: string; name: string; stage: string; value: number }[]> {\n const r = await fetch(\n `${GHL_BASE}/opportunities/search?location_id=${GHL_LOCATION_ID}&contact_id=${contactId}&pipeline_id=${GHL_PIPELINE_ID}`,\n { headers: GHL_HEADERS() },\n );\n if (!r.ok) throw new Error(`GHL oppsearch ${r.status}`);\n const d = await r.json().catch(() => ({}));\n return (d?.opportunities ?? []).map((o: any) => ({\n id: o.id,\n name: o.name ?? \"\",\n stage: o.pipelineStageId ?? \"\",\n value: Number(o.monetaryValue ?? 0),\n }));\n}\n// only Won-Paid-stage opps (never touch a human's opp in another stage)\nasync function ghlWonPaidOpps(\n contactId: string,\n): Promise<{ id: string; value: number }[]> {\n const r = await fetch(\n `${GHL_BASE}/opportunities/search?location_id=${GHL_LOCATION_ID}&contact_id=${contactId}&pipeline_id=${GHL_PIPELINE_ID}`,\n { headers: GHL_HEADERS() },\n );\n if (!r.ok) throw new Error(`GHL oppsearch ${r.status}`);\n const d = await r.json().catch(() => ({}));\n // Won-Paid STAGE is bridge-exclusive, so filtering by stage finds existing bridge opps\n // (any name) while never touching a human's opp in another stage.\n return (d?.opportunities ?? [])\n .filter((o: any) => o.pipelineStageId === GHL_WON_PAID_STAGE_ID)\n .map((o: any) => ({ id: o.id, value: Number(o.monetaryValue ?? 0) }));\n}\n// v3.5 — returns {id} on success, {duplicate} when GHL refuses because the contact already owns\n// an opportunity, {err} otherwise. v3.3 threw a bare \"GHL createOpp 400\" that hid the reason.\nasync function ghlCreateOpp(\n contactId: string,\n value: number,\n): Promise<{ id?: string; duplicate?: string; err?: string }> {\n const r = await fetch(`${GHL_BASE}/opportunities/`, {\n method: \"POST\",\n headers: GHL_HEADERS(),\n body: JSON.stringify({\n pipelineId: GHL_PIPELINE_ID,\n locationId: GHL_LOCATION_ID,\n name: OPP_NAME,\n pipelineStageId: GHL_WON_PAID_STAGE_ID,\n status: \"won\",\n contactId,\n monetaryValue: value,\n }),\n });\n const d = await r.json().catch(() => ({}));\n if (!r.ok) {\n // \"Allow duplicate opportunity\" is OFF on this location: a contact may hold only one\n // opportunity. GHL hands back the existing id. This is the NORMAL case for any paying\n // customer who was a lead first -- it used to throw -> 500 -> Square retried forever.\n if (d?.code === \"OPPORTUNITY_NO_DUPLICATE\" && d?.meta?.existingId) {\n return { duplicate: d.meta.existingId };\n }\n return {\n err: `GHL createOpp ${r.status} ${JSON.stringify(d).slice(0, 200)}`,\n };\n }\n const id = d?.opportunity?.id ?? d?.id;\n return id ? { id } : { err: \"GHL createOpp no id\" };\n}\nasync function ghlSetOppValue(oppId: string, value: number) {\n const r = await fetch(`${GHL_BASE}/opportunities/${oppId}`, {\n method: \"PUT\",\n headers: GHL_HEADERS(),\n body: JSON.stringify({\n pipelineStageId: GHL_WON_PAID_STAGE_ID,\n status: \"won\",\n monetaryValue: value,\n }),\n });\n if (!r.ok) throw new Error(`GHL setOpp ${r.status}`);\n}\nasync function ghlDeleteOpp(oppId: string) {\n const r = await fetch(`${GHL_BASE}/opportunities/${oppId}`, {\n method: \"DELETE\",\n headers: GHL_HEADERS(),\n });\n if (!r.ok && r.status !== 404) throw new Error(`GHL delOpp ${r.status}`);\n}\nasync function ghlNote(contactId: string, body: string) {\n await fetch(`${GHL_BASE}/contacts/${contactId}/notes`, {\n method: \"POST\",\n headers: GHL_HEADERS(),\n body: JSON.stringify({ body }),\n });\n}\n\ntype Ledger = {\n payments: Record;\n refunds: Record;\n oppId: string | null;\n name?: string;\n};\nconst sum = (o: Record) =>\n Object.values(o).reduce((a, b) => a + b, 0);\n\nasync function reconcile(\n contactId: string,\n): Promise<{ oppId: string | null; value: number }> {\n const ledger = (await getBlob(LEDGER + contactId)) ??\n { payments: {}, refunds: {}, oppId: null };\n const value = Math.round((sum(ledger.payments) - sum(ledger.refunds)) * 100) /\n 100;\n const v = Math.max(0, value);\n const all = await ghlPipelineOpps(contactId);\n // ours = Won-Paid stage (bridge-exclusive by agreement) or carrying the bridge name marker\n const mine = all.filter((o) =>\n o.stage === GHL_WON_PAID_STAGE_ID || o.name === OPP_NAME\n );\n let keep = (ledger.oppId &&\n mine.find((o) => o.id === ledger.oppId)?.id) || mine[0]?.id || null;\n for (const o of mine) if (o.id !== keep) await ghlDeleteOpp(o.id);\n if (keep) {\n await ghlSetOppValue(keep, v);\n ledger.oppId = keep;\n await remember(LEDGER + contactId, ledger);\n return { oppId: keep, value: v };\n }\n\n const created = await ghlCreateOpp(contactId, v);\n if (created.id) {\n ledger.oppId = created.id;\n await remember(LEDGER + contactId, ledger);\n return { oppId: created.id, value: v };\n }\n if (created.err) throw new Error(created.err);\n\n // v3.5 — the contact already owns an opportunity the bridge did NOT create: a real lead or\n // customer record of Kim's. Do NOT hijack it and do NOT overwrite its monetaryValue -- that\n // number is her sale, not our Square balance. Book the revenue in the ledger + contact note +\n // journal and return cleanly so Square stops retrying the event.\n ledger.oppId = null;\n await remember(LEDGER + contactId, ledger);\n await journal({\n kind: \"REVENUE-ON-CLIENT-OPP\",\n contactId,\n amount: v,\n note: `existing opp ${created.duplicate} left untouched`,\n });\n return { oppId: null, value: v };\n}\nasync function addPayment(\n contactId: string,\n paymentId: string,\n amount: number,\n email?: string,\n phone?: string,\n) {\n if (!paymentId) {\n await journal({ kind: \"BAD-PAYMENT\", note: \"missing payment id\" });\n return;\n }\n const ledger = (await getBlob(LEDGER + contactId)) ??\n { payments: {}, refunds: {}, oppId: null };\n if (paymentId in ledger.payments && ledger.payments[paymentId] === amount) {\n await journal({ kind: \"PAY-DUP\", contactId, id: paymentId });\n await reconcile(contactId);\n return;\n }\n ledger.payments[paymentId] = amount; // also handles amount-changed updates\n await remember(LEDGER + contactId, ledger);\n await remember(PAY_CONTACT + paymentId, contactId);\n const { value } = await reconcile(contactId);\n await ghlNote(\n contactId,\n `[Square] +$${amount.toFixed(2)} payment ${paymentId} (balance $${\n value.toFixed(2)\n })`,\n );\n await journal({\n kind: \"PAYMENT\",\n contactId,\n amount,\n note: `payment ${paymentId}`,\n });\n await sendCapiPurchase(email, phone, amount, paymentId); // M3\n await applyPendingRefund(contactId, paymentId);\n}\nasync function addRefund(contactId: string, refundId: string, amount: number) {\n if (!refundId) {\n await journal({ kind: \"BAD-REFUND\" });\n return;\n }\n const ledger = (await getBlob(LEDGER + contactId)) ??\n { payments: {}, refunds: {}, oppId: null };\n if (refundId in ledger.refunds) {\n await journal({ kind: \"REFUND-DUP\", contactId, id: refundId });\n return;\n }\n ledger.refunds[refundId] = amount;\n await remember(LEDGER + contactId, ledger);\n const { value } = await reconcile(contactId);\n await ghlNote(\n contactId,\n `[Square] Refund -$${amount.toFixed(2)} ${refundId} (balance $${\n value.toFixed(2)\n })`,\n );\n await journal({\n kind: \"REFUND\",\n contactId,\n amount,\n note: `refund ${refundId}`,\n });\n}\n// apply a refund that arrived BEFORE its payment (stashed as pending), once the payment links a contact\nasync function applyPendingRefund(contactId: string, paymentId: string) {\n const pend = await getBlob<{ rid: string; amt: number }>(\n PENDING_REFUND + paymentId,\n );\n if (pend) {\n await blob.delete(PENDING_REFUND + paymentId);\n await journal({ kind: \"REFUND-PENDING-APPLIED\", contactId, id: pend.rid });\n await addRefund(contactId, pend.rid, pend.amt);\n }\n}\n// apply a payment that arrived BEFORE we could link a contact (e.g. POS/checkout payment with no email,\n// later linked by its invoice.payment_made). Books the real amount from the original payment event.\nasync function applyPendingPayment(\n contactId: string,\n paymentId: string,\n email?: string,\n phone?: string,\n) {\n const pend = await getBlob<{ amt: number; email?: string; phone?: string }>(\n PENDING_PAY + paymentId,\n );\n if (pend) {\n await blob.delete(PENDING_PAY + paymentId);\n await journal({\n kind: \"PENDING-PAY-APPLIED\",\n contactId,\n id: paymentId,\n amount: pend.amt,\n });\n // prefer the payment's own PII; fall back to the invoice recipient's so CAPI still gets identity\n await addPayment(\n contactId,\n paymentId,\n pend.amt,\n pend.email || email,\n pend.phone || phone,\n );\n }\n}\n\nexport default async function (req: Request): Promise {\n const url = new URL(req.url);\n\n // v3.8 — inbound heartbeat. Recorded BEFORE signature verification or parsing, so that\n // \"Square stopped delivering\" becomes distinguishable from \"Square delivered and we\n // discarded it\". Until now the journal only recorded events the code chose to act on,\n // which meant a disabled or expired webhook subscription was indistinguishable from a\n // genuinely quiet trading day — the failure mode was total silence with no alarm.\n if (req.method === \"POST\") {\n try {\n const prev = await blob.getJSON<{ n?: number }>(INBOUND_KEY).catch(() => null);\n await blob.setJSON(INBOUND_KEY, {\n ts: new Date().toISOString(),\n n: (prev?.n ?? 0) + 1,\n });\n } catch { /* never let bookkeeping break delivery */ }\n }\n\n // Health check (no data) — safe to be public\n if (req.method === \"GET\" && !url.search) {\n return new Response(\"M2/M3 bridge up (v3.8).\");\n }\n\n // Journal — now REQUIRES admin secret (was a public PII leak in earlier versions)\n if (req.method === \"GET\" && url.searchParams.get(\"dump\") === \"1\") {\n if (!adminOk(url.searchParams.get(\"admin\"))) {\n return new Response(\"forbidden\", { status: 403 });\n }\n return Response.json(\n (await blob.getJSON(JOURNAL_KEY).catch(() => null)) ?? [],\n );\n }\n // v3.10 (11 Aug 2026) — READ ONLY PAYMENT LOOKUP. Added so Kim's team can identify the 29\n // unmatched July payments. The journal only ever recorded amount and time; Square holds the\n // receipt, the card's last four and the line items. The token to ask Square is already in this\n // runtime and reachable from nowhere else, which is the only reason this route exists here.\n //\n // GET ?lookup=&admin=\n // It performs GET on Square's Payments and Orders APIs and nothing else. There is no write verb\n // in this branch, it touches no blob, and it journals nothing, so it cannot alter the bridge's\n // memory or Kim's data. Ninety ids per call is the cap, to keep one request bounded.\n if (req.method === \"GET\" && url.searchParams.get(\"lookup\")) {\n if (!adminOk(url.searchParams.get(\"admin\"))) {\n return new Response(\"forbidden\", { status: 403 });\n }\n if (!SQUARE_ACCESS_TOKEN) {\n return Response.json({ error: \"SQUARE_ACCESS_TOKEN not set in this runtime\" }, { status: 503 });\n }\n const ids = String(url.searchParams.get(\"lookup\")).split(\",\").map((x) => x.trim()).filter(Boolean).slice(0, 90);\n const sqGet = async (path: string) => {\n const r = await fetch(`${SQUARE_API}${path}`, {\n headers: { Authorization: `Bearer ${SQUARE_ACCESS_TOKEN}`, \"Square-Version\": SQUARE_VERSION },\n });\n if (!r.ok) return { _error: r.status } as any;\n return await r.json();\n };\n const out: any[] = [];\n for (const id of ids) {\n const pay = await sqGet(`/payments/${encodeURIComponent(id)}`);\n const p = pay?.payment ?? null;\n let order: any = null;\n if (p?.order_id) order = (await sqGet(`/orders/${encodeURIComponent(p.order_id)}`))?.order ?? null;\n out.push({\n id,\n error: pay?._error ?? null,\n created_at: p?.created_at ?? null,\n amount: p?.amount_money?.amount != null ? p.amount_money.amount / 100 : null,\n status: p?.status ?? null,\n source_type: p?.source_type ?? null,\n card_brand: p?.card_details?.card?.card_brand ?? null,\n last_4: p?.card_details?.card?.last_4 ?? null,\n cardholder_name: p?.card_details?.card?.cardholder_name ?? null,\n entry_method: p?.card_details?.entry_method ?? null,\n receipt_number: p?.receipt_number ?? null,\n receipt_url: p?.receipt_url ?? null,\n note: p?.note ?? null,\n customer_id: p?.customer_id ?? null,\n location_id: p?.location_id ?? null,\n device_name: p?.device_details?.device_name ?? null,\n team_member_id: p?.team_member_id ?? null,\n order_id: p?.order_id ?? null,\n line_items: (order?.line_items ?? []).map((li: any) => ({\n name: li?.name ?? null,\n quantity: li?.quantity ?? null,\n total: li?.total_money?.amount != null ? li.total_money.amount / 100 : null,\n variation: li?.variation_name ?? null,\n catalog_object_id: li?.catalog_object_id ?? null,\n })),\n order_customer_id: order?.customer_id ?? null,\n // v3.10a: resolve the Square customer too. Every one of the 29 unmatched July payments\n // carries a customer_id, so these buyers are NOT anonymous. Square knows who they are and\n // the bridge simply failed to carry it across. Read only, one GET per customer.\n square_customer: await (async () => {\n const cid = p?.customer_id ?? order?.customer_id ?? null;\n if (!cid) return null;\n const c = (await sqGet(`/customers/${encodeURIComponent(String(cid))}`))?.customer ?? null;\n if (!c) return null;\n return {\n given_name: c.given_name ?? null, family_name: c.family_name ?? null,\n email_address: c.email_address ?? null, phone_number: c.phone_number ?? null,\n company_name: c.company_name ?? null, nickname: c.nickname ?? null,\n reference_id: c.reference_id ?? null, note: c.note ?? null,\n created_at: c.created_at ?? null,\n };\n })(),\n fulfillments: (order?.fulfillments ?? []).map((f: any) => f?.pickup_details?.recipient ?? null).filter(Boolean),\n });\n }\n return Response.json({ asked: ids.length, results: out });\n }\n\n // v3.10b — READ ONLY CATALOG. Kim asked that payment links be built from the \"New Training\n // Prices\" category in Square and its Upgrades subcategory, because the product prices in her CRM\n // are stale. This lists the catalog so those prices can be read rather than retyped. GETs only.\n if (req.method === \"GET\" && url.searchParams.get(\"catalog\") === \"1\") {\n if (!adminOk(url.searchParams.get(\"admin\"))) return new Response(\"forbidden\", { status: 403 });\n if (!SQUARE_ACCESS_TOKEN) return Response.json({ error: \"no square token\" }, { status: 503 });\n const sqGet2 = async (path: string) => {\n const r = await fetch(`${SQUARE_API}${path}`, {\n headers: { Authorization: `Bearer ${SQUARE_ACCESS_TOKEN}`, \"Square-Version\": SQUARE_VERSION },\n });\n return r.ok ? await r.json() : { _error: r.status };\n };\n const cats = await sqGet2(\"/catalog/list?types=CATEGORY\");\n const items = await sqGet2(\"/catalog/list?types=ITEM\");\n const catName = new Map();\n for (const c of cats?.objects ?? []) catName.set(c.id, c?.category_data?.name ?? \"\");\n const out = (items?.objects ?? []).map((it: any) => ({\n item: it?.item_data?.name ?? null,\n category: catName.get(it?.item_data?.category_id ?? it?.item_data?.categories?.[0]?.id ?? \"\") ?? null,\n variations: (it?.item_data?.variations ?? []).map((v: any) => ({\n name: v?.item_variation_data?.name ?? null,\n price: v?.item_variation_data?.price_money?.amount != null ? v.item_variation_data.price_money.amount / 100 : null,\n })),\n }));\n return Response.json({ categories: [...catName.values()].filter(Boolean).sort(), items: out });\n }\n\n // v3.5 — env presence check (admin, booleans only, never values). Answers \"is the POS path armed?\"\n if (req.method === \"GET\" && url.searchParams.get(\"envcheck\") === \"1\") {\n if (!adminOk(url.searchParams.get(\"admin\"))) {\n return new Response(\"forbidden\", { status: 403 });\n }\n return Response.json({\n version: \"3.9\",\n SQUARE_SIGNATURE_KEY: !!SQUARE_SIGNATURE_KEY,\n SQUARE_ACCESS_TOKEN: !!SQUARE_ACCESS_TOKEN,\n GHL_TOKEN: !!GHL_TOKEN,\n lastInbound: (await blob.getJSON(INBOUND_KEY).catch(() => null)) ?? \"never\",\n ADMIN_SECRET_dedicated: !!ADMIN_SECRET_DEDICATED,\n destructive_routes_enabled: !!ADMIN_SECRET_DEDICATED,\n FB_CAPI_TOKEN: !!FB_CAPI_TOKEN,\n });\n }\n // CAPI self-test (admin) — fires one Purchase; use &code= to keep it in Test Events\n if (req.method === \"GET\" && url.searchParams.has(\"captest\")) {\n if (!adminStrictOk(url.searchParams.get(\"captest\"))) {\n return new Response(\"forbidden: ?captest requires a dedicated ADMIN_SECRET\", { status: 403 });\n }\n const code = url.searchParams.get(\"code\") || undefined;\n const resp = await sendCapiPurchase(\n \"captest@thedogsspotga.com\",\n \"+19125550123\",\n 1.00,\n \"captest_\" + Date.now(),\n code,\n );\n return Response.json({\n sent: true,\n hasToken: !!FB_CAPI_TOKEN,\n dataset: FB_DATASET_ID,\n testEventCode: code ?? null,\n meta: resp,\n });\n }\n // Wipe (admin) — POST only, fail-closed\n if (req.method === \"POST\" && url.searchParams.get(\"wipe\") === \"1\") {\n if (!adminStrictOk(url.searchParams.get(\"admin\"))) {\n return new Response(\"forbidden: ?wipe requires a dedicated ADMIN_SECRET\", { status: 403 });\n }\n const keys = await blob.list(\"m2_\");\n let n = 0;\n for (const k of keys) {\n await blob.delete((k as any).key);\n n++;\n }\n return new Response(\"wiped \" + n);\n }\n if (req.method !== \"POST\") return new Response(\"M2/M3 bridge up (v3.7).\");\n\n const raw = await req.text();\n const sig = req.headers.get(\"x-square-hmacsha256-signature\") ?? \"\";\n if (!(await squareSigOk(raw, sig))) {\n await journal({ kind: \"BAD-SIG\" });\n return new Response(\"bad sig\", { status: 401 });\n }\n\n let evt: any;\n try {\n evt = JSON.parse(raw);\n } catch {\n return new Response(\"bad json\", { status: 400 });\n }\n const eventId = evt?.event_id;\n if (eventId && await seen(DEDUP_EVENT + eventId)) {\n await journal({ kind: \"DUPLICATE-SKIP\" });\n return new Response(\"dup\");\n }\n\n const type = evt?.type as string;\n const obj = evt?.data?.object ?? {};\n try {\n if (type === \"payment.updated\" || type === \"payment.created\") {\n const p = obj.payment ?? {};\n if (p.status === \"COMPLETED\") {\n const amt = (p.amount_money?.amount ?? 0) / 100;\n let email = p.buyer_email_address || undefined;\n let phone = p.buyer_phone_number || undefined; // usually absent on POS, defensive\n // 1) match by email OR phone; 2) else use the contact an invoice already linked to this payment id\n let cid = await ghlFindContact(email, phone);\n if (!cid) cid = await getBlob(PAY_CONTACT + p.id);\n // 3) v3.4/v3.5 — POS: the register attached a customer at checkout but the payment object\n // carries no email/phone. Resolve the Square customer, then match the GHL contact.\n if (!cid && p.customer_id && SQUARE_ACCESS_TOKEN) {\n const sc = await fetchSquareCustomer(p.customer_id);\n email = email || sc.email;\n phone = phone || sc.phone;\n if (sc.email || sc.phone) cid = await ghlFindContact(sc.email, sc.phone);\n }\n if (cid) await addPayment(cid, p.id, amt, email, phone);\n else {\n // hold the amount so invoice.payment_made can book it the moment it supplies a contact\n await remember(PENDING_PAY + p.id, { amt, email, phone });\n await journal({\n kind: \"NO-MATCH\",\n note: `payment ${p.id}`,\n amount: amt,\n hadEmail: !!email,\n hadPhone: !!phone,\n hadCustomerId: !!p.customer_id,\n sqTokenSet: !!SQUARE_ACCESS_TOKEN,\n });\n }\n }\n } else if (type === \"invoice.payment_made\") {\n const inv = obj.invoice ?? {};\n const r = inv.primary_recipient ?? {};\n const email = r.email_address || undefined;\n const phone = r.phone_number || undefined;\n const payId = obj?.payment?.id;\n const cid = await ghlFindContact(email, phone);\n if (cid) {\n if (payId) {\n await remember(PAY_CONTACT + payId, cid);\n await applyPendingRefund(cid, payId);\n await applyPendingPayment(cid, payId, email, phone); // books the payment amount if it already arrived\n }\n await reconcile(cid);\n await journal({\n kind: \"INVOICE-LINKED\",\n note: `invoice ${inv.id}`,\n contactId: cid,\n });\n } else {\n // no contact to book to — the payment stays on the review list (rich NO-MATCH)\n await journal({\n kind: \"NO-MATCH\",\n note: `invoice ${inv.id}`,\n hadEmail: !!email,\n hadPhone: !!phone,\n });\n }\n } else if (type === \"invoice.refunded\") {\n const inv = obj.invoice ?? {};\n const r = inv.primary_recipient ?? {};\n const cid = await ghlFindContact(r.email_address, r.phone_number);\n const amt = (obj?.refund?.amount_money?.amount ?? 0) / 100;\n const rid = obj?.refund?.id ?? `inv-${inv.id}`;\n if (cid) await addRefund(cid, rid, amt);\n else {await journal({\n kind: \"REFUND-NO-MATCH\",\n note: `invoice-refund ${inv.id}`,\n });}\n } else if (type === \"refund.updated\" || type === \"refund.created\") {\n const rf = obj.refund ?? {};\n if (rf.status === \"COMPLETED\") {\n const cid = rf.payment_id\n ? await getBlob(PAY_CONTACT + rf.payment_id)\n : null;\n const amt = (rf.amount_money?.amount ?? 0) / 100;\n if (cid) await addRefund(cid, rf.id, amt);\n else {\n await remember(PENDING_REFUND + (rf.payment_id ?? rf.id), {\n rid: rf.id,\n amt,\n });\n await journal({\n kind: \"REFUND-PENDING\",\n amount: amt,\n note: `refund ${rf.id}`,\n });\n }\n }\n } else {\n await journal({ kind: \"IGNORED\", type });\n }\n } catch (e) {\n await journal({ kind: \"ERROR\", type, error: String(e).slice(0, 120) });\n return new Response(\"retry\", { status: 500 }); // Square will retry; event NOT marked seen\n }\n\n if (eventId) await remember(DEDUP_EVENT + eventId); // mark seen only after success\n return new Response(\"EVENT_RECEIVED\");\n}\n\n\n=====FILE handover/KRISTIAN-EMAIL-DRAFT.txt =====\nTo: solutions@moorecre8ive.com\nSubject: One quick question on the app and the CRM\n\nHi Kristian,\n\nQuick technical one so I do not step on your application. When your app updates opportunities in the\nCRM, does it write the monetary value on them, and does it move cards between pipeline stages? I am\nbuilding the Square payment reconciliation and I need to know which fields you own so mine only ever\ntouch the ones nobody else does.\n\nThanks,\nAmir\n\n\n\n=====FILE handover/TEAM-EMAIL-DRAFT.txt =====\nTo: info@thedogsspotga.com\nSubject: New puppy follow up is now on\n\nHi team,\n\nA quick heads up on something that started today. New puppy inquiries now get a short series of\nhelpful follow up messages automatically, by text and email, over their first few weeks. It runs on\nits own and sends only during business hours.\n\nThere is nothing you need to do. Two things worth knowing:\n\nIf a customer replies to one of these, a real person still needs to answer them, same as always. The\nmessages are friendly and low key, they are not doing any selling.\n\nIf someone books a Pup Talk, they stop getting the series automatically, so you will not be talking to\nsomeone who is still being messaged about booking one.\n\nThat is it. If anything looks off, tell Amir and he will take a look.\n\nThanks,\nKim\n\n\n\n=====FILE scripts/exception-report.mjs =====\n#!/usr/bin/env node\n// THE WEEKLY SQUARE EXCEPTION REPORT. Generator, 11 Aug 2026.\n//\n// WHAT THIS IS. Promised to Kim in writing (handover/REPLY-TO-KIM-11-AUG.txt, \"I want to add a\n// short weekly list of any Square sale that did not reach a customer record\"). Every run reads the\n// Square-to-GoHighLevel bridge's own journal, asks the bridge which payments never reached a\n// contact using the SAME rule the client was already told about, and writes a CSV plus a short\n// summary. Nothing here is scheduled and nothing here writes to a live system: two GETs to the\n// bridge (the journal dump and the Square detail lookup), both read only, and two local files out.\n//\n// WHY IT DOES NOT HAND-COPY THE MATCHING RULE. The rule that decides \"unmatched\" is\n// engine/facts.ts squareBacklog(). Copying its logic into a second file is exactly how Kim ended up\n// with a wrong number in writing once already: on 9 Aug she was told 42 payments / $33,535.99, a\n// figure that only ever read the FIRST attempt at each payment, when the true count, reading every\n// attempt, is 33 / $22,651.99 (engine/facts.ts:64-69). $10,884.00 of backlog that had already\n// cleared was still being reported as owed. So this script imports the real, current\n// squareBacklog() (via build/facts.js, transpiled fresh from engine/facts.ts on every run, never a\n// stale copy) for the numbers Kim sees, and only re-derives the per-payment LIST locally, because\n// squareBacklog() itself returns totals, not rows. That second derivation is then reconciled\n// against the imported function's totals below and the run refuses to ship if they disagree by so\n// much as a cent or a row (see reconcileOrDie). LESSONS.md #8 asks for exactly this standing check\n// once this report exists: \"reconcile any subset against its parent total before it leaves the\n// building.\" This is that check.\n//\n// WHAT COUNTS AS THE WEEKLY LIST. \"Weekly\" describes the CADENCE this is meant to run on, not a\n// seven day filter on the journal. The list is the entire current backlog, same as the number Kim\n// was quoted, because a payment that missed its match three weeks ago and still has not been fixed\n// is exactly the kind of thing that must not \"age out\" of a list whose whole purpose is that\n// nothing sits unnoticed. LESSONS.md #8 is the same lesson from the other direction: a filter\n// boundary that quietly became \"the\" result understated the backlog to 29 / $19,822 once already.\n// No date filtering happens anywhere in this file.\n//\n// USAGE\n// node scripts/exception-report.mjs\n// ENV OVERRIDES (all optional; defaults match the brief exactly)\n// BRIDGE_URL default: read from engine/dashboard.ts\n// BRIDGE_ADMIN default: read from engine/dashboard.ts line 41\n// EXCEPTION_REPORT_OUT_DIR default: /mnt/user-data/outputs\n// EXCEPTION_REPORT_DATE default: today, formatted D-Mon e.g. \"11-Aug\"\n// EXCEPTION_REPORT_JOURNAL_FILE offline mode: read journal JSON from this local file, skip the\n// network fetch entirely (used by tests/manual debugging only)\n\nimport { spawnSync } from \"node:child_process\";\nimport { readFileSync, writeFileSync, mkdirSync, existsSync } from \"node:fs\";\nimport { join, dirname, resolve } from \"node:path\";\nimport { fileURLToPath } from \"node:url\";\n\nconst HERE = dirname(fileURLToPath(import.meta.url));\nconst ROOT = resolve(HERE, \"..\"); // /home/claude/restore\n\nfunction shout(msg) {\n console.error(`\\n!!!! ${msg} !!!!\\n`);\n}\nfunction die(msg) {\n shout(msg);\n process.exit(1);\n}\n\n// -------------------------------------------------------------------------------------------\n// STEP 0. Rebuild engine/ -> build/, always, before importing anything from it. Copied straight\n// from tests/run-all.mjs's own \"REBUILD FIRST, ALWAYS\" — the incident that rule guards against\n// (6 Aug: real logic deleted from an engine file, suite run without rebuilding, 270 assertions\n// \"passed\" against stale code) is exactly the failure mode a report script must not repeat, because\n// nobody reviews this output as carefully as a red test suite.\n// -------------------------------------------------------------------------------------------\n{\n const b = spawnSync(\"node\", [join(ROOT, \"scripts\", \"build.mjs\")], { encoding: \"utf8\", timeout: 300_000 });\n if (b.status !== 0) {\n die(`BUILD FAILED. Refusing to generate a report against logic that will not even compile.\\n${(b.stdout ?? \"\") + (b.stderr ?? \"\")}`.trim());\n }\n}\n\nconst { squareBacklog, squareSentence } = await import(join(ROOT, \"build\", \"facts.js\"));\nconst { unmatchedPaymentRows, reconcile, cents, paymentUniverse, journalAmount } = await import(join(ROOT, \"scripts\", \"exception-report-lib.mjs\"));\n\n// -------------------------------------------------------------------------------------------\n// STEP 1. Credentials. Read from the same place the engine reads them (dashboard.ts), never a\n// second typed-in copy, so a rotated secret only ever needs updating in one file. Line 41 is\n// where the brief says the secret lives; that is checked first and verified by shape (51 chars),\n// with a full-file fallback that WARNS rather than silently trusting a shifted line number.\n// -------------------------------------------------------------------------------------------\nconst DASHBOARD_TS = process.env.DASHBOARD_TS_PATH || join(ROOT, \"engine\", \"dashboard.ts\");\nif (!existsSync(DASHBOARD_TS)) die(`cannot find ${DASHBOARD_TS}. Restore it before running this report.`);\nconst dashboardSrc = readFileSync(DASHBOARD_TS, \"utf8\");\nconst dashboardLines = dashboardSrc.split(\"\\n\");\n\nfunction readConstFrom(text, name) {\n const m = new RegExp(`const\\\\s+${name}\\\\s*=\\\\s*\"([^\"]+)\"`).exec(text);\n return m ? m[1] : null;\n}\n\nconst ADMIN_LINE_NO = Number(process.env.BRIDGE_ADMIN_LINE || 41);\nlet admin = readConstFrom(dashboardLines[ADMIN_LINE_NO - 1] ?? \"\", \"BRIDGE_ADMIN\");\nif (admin) {\n console.log(`admin secret: read from ${DASHBOARD_TS}:${ADMIN_LINE_NO} as expected`);\n} else {\n admin = readConstFrom(dashboardSrc, \"BRIDGE_ADMIN\");\n if (admin) {\n shout(`BRIDGE_ADMIN was NOT on line ${ADMIN_LINE_NO} of ${DASHBOARD_TS} as the brief describes. ` +\n `Found it elsewhere in the file instead. The file has moved since the brief was written; check that this is still the right file.`);\n }\n}\nadmin = process.env.BRIDGE_ADMIN || admin;\nif (!admin) die(`could not find a BRIDGE_ADMIN literal anywhere in ${DASHBOARD_TS}`);\nif (admin.length !== 51) {\n die(`BRIDGE_ADMIN is ${admin.length} characters; the brief describes a 51-char literal. Refusing to guess with a secret that does not match the documented shape.`);\n}\n\nconst BRIDGE = process.env.BRIDGE_URL || readConstFrom(dashboardSrc, \"BRIDGE\");\nif (!BRIDGE) die(`could not find a BRIDGE literal in ${DASHBOARD_TS}`);\n\n// -------------------------------------------------------------------------------------------\n// STEP 2. Fetch the journal. READ ONLY: a GET on ?dump=1. Zero rows inspected is a hard failure,\n// never an empty success (LESSONS.md #2) — it almost certainly means the fetch broke, not that\n// nothing happened.\n// -------------------------------------------------------------------------------------------\nlet journal;\nconst journalFileOverride = process.env.EXCEPTION_REPORT_JOURNAL_FILE;\nif (journalFileOverride) {\n console.log(`offline mode: reading journal from ${journalFileOverride} instead of the network`);\n journal = JSON.parse(readFileSync(journalFileOverride, \"utf8\"));\n} else {\n const dumpUrl = `${BRIDGE}?dump=1&admin=${encodeURIComponent(admin)}`;\n let res;\n try {\n res = await fetch(dumpUrl);\n } catch (e) {\n die(`journal fetch threw: ${e.message}`);\n }\n if (!res.ok) die(`journal fetch failed: HTTP ${res.status} from ${BRIDGE}?dump=1`);\n journal = await res.json();\n}\n\nif (!Array.isArray(journal)) die(`journal did not come back as an array (got ${typeof journal}). Cannot inspect anything.`);\nif (journal.length === 0) die(`journal came back with ZERO rows. A report that inspects zero rows is a FAILURE, not an empty success. Not writing anything.`);\n\nconst journalTimestamps = journal.map((r) => r?.ts).filter(Boolean).sort();\nconst spanStart = journalTimestamps[0] ?? \"unknown\";\nconst spanEnd = journalTimestamps[journalTimestamps.length - 1] ?? \"unknown\";\nconsole.log(`Inspected ${journal.length} journal rows, spanning ${spanStart} to ${spanEnd}.`);\nif (journal.length < 100) {\n shout(`only ${journal.length} journal rows read; the brief describes roughly 780. This is not a hard failure (the journal legitimately grows or could be pruned) but it is worth a human's eyes before this ships.`);\n}\n\n// -------------------------------------------------------------------------------------------\n// STEP 3. THE NUMBERS KIM SEES: the real, current squareBacklog(), imported, not retyped.\n// -------------------------------------------------------------------------------------------\nconst backlog = squareBacklog(journal);\nif (!backlog) die(\"squareBacklog(journal) returned null even though the journal is a non-empty array. The reconciliation logic itself has changed shape; stop and look before shipping anything.\");\n\n// -------------------------------------------------------------------------------------------\n// STEP 4. THE LIST: a second, independent derivation of the same rule, so this report can name\n// individual payments (squareBacklog() only returns aggregates). unmatchedPaymentRows(), imported\n// from exception-report-lib.mjs above, mirrors engine/facts.ts squareBacklog() lines 72-98 and\n// carries the same MATCHED-LATER GUARD that closes the $10,884 / 9 payment hole documented there\n// and in tests/exception-report.test.mjs.\n// -------------------------------------------------------------------------------------------\nconst rows = unmatchedPaymentRows(journal);\n\n// -------------------------------------------------------------------------------------------\n// STEP 5. RECONCILE OR DIE. The list built above must add up to exactly what the real\n// squareBacklog() says, in count and in every dollar (reconcile(), same lib import). If it does\n// not, something has drifted between the two derivations and this script refuses to ship a number\n// Kim cannot trust. LESSONS.md #8's standing check — a subset plus its remainder equals the\n// parent total — is inside reconcile() too.\n// -------------------------------------------------------------------------------------------\nfunction reconcileOrDie(rows, backlog) {\n const r = reconcile(rows, backlog);\n if (!r.ok) {\n shout(\"RECONCILIATION FAILED. This report does NOT match engine/facts.ts squareBacklog(). Nothing was written.\");\n for (const p of r.problems) console.error(` - ${p}`);\n process.exit(1);\n }\n console.log(`Reconciled: ${rows.length} payments / $${r.listTotal.toFixed(2)} matches squareBacklog() exactly ` +\n `(${backlog.withTrail} with a trail worth $${backlog.withTrailTotal.toFixed(2)}, ${backlog.noTrail} with none worth $${backlog.noTrailTotal.toFixed(2)}).`);\n return r;\n}\n\nreconcileOrDie(rows, backlog);\n\n// -------------------------------------------------------------------------------------------\n// STEP 6. ENRICH each unmatched payment with Square's own detail via the bridge's read only\n// lookup route (?lookup=, capped at 90 ids per call by the bridge itself; chunked here so this\n// still works the week the backlog exceeds that). A lookup failure downgrades that row rather\n// than aborting the run: the count and total already reconciled above and are the part Kim\n// actually needs not to miss.\n// -------------------------------------------------------------------------------------------\nasync function lookupSquareDetails(ids) {\n const out = new Map();\n const failures = [];\n const CHUNK = 90;\n for (let i = 0; i < ids.length; i += CHUNK) {\n const chunk = ids.slice(i, i + CHUNK);\n const url = `${BRIDGE}?lookup=${chunk.map(encodeURIComponent).join(\",\")}&admin=${encodeURIComponent(admin)}`;\n let res;\n try {\n res = await fetch(url);\n } catch (e) {\n shout(`Square lookup request threw for ${chunk.length} payment(s): ${e.message}`);\n failures.push(...chunk);\n continue;\n }\n if (!res.ok) {\n shout(`Square lookup HTTP ${res.status} for ${chunk.length} payment(s). Those rows will ship without Square detail.`);\n failures.push(...chunk);\n continue;\n }\n const body = await res.json();\n for (const r of body.results ?? []) out.set(r.id, r);\n for (const id of chunk) if (!out.has(id)) failures.push(id);\n }\n return { out, failures };\n}\n\n// THE PARENT TOTAL. [Added 12 Aug 2026.] LESSONS.md #8 says a subset may not leave the building\n// without the population it came out of, and until now this report had none: \"33 unlinked\" was\n// quoted against nothing, which is how three wrong versions of it in a row all looked plausible.\n// paymentUniverse() is the same id parser this file already trusts for the subset, applied to\n// every payment the bridge has ever logged, so the two cannot drift.\n//\n// Every payment is looked up in Square, not just the unmatched ones, because the journal does not\n// always carry an amount: PAY-DUP rows have no amount field at all, and five payments worth\n// $1,410.00 live are reachable only through those rows. A parent total summed from the journal\n// alone would understate the population by that much and the subset would look larger than it is.\nconst universe = paymentUniverse(journal);\nconst { out: lookups, failures: lookupFailures } = await lookupSquareDetails([...universe.payments.keys()].sort());\nconsole.log(`Square lookup: ${universe.payments.size - lookupFailures.length} of ${universe.payments.size} payments enriched` +\n (lookupFailures.length ? `, ${lookupFailures.length} FAILED (${lookupFailures.join(\", \")}).` : \".\"));\n\nconst amountOf = (id) => {\n const s = Number(lookups.get(id)?.amount);\n return Number.isFinite(s) ? s : journalAmount(universe.payments.get(id));\n};\nconst universeTotal = [...universe.payments.keys()].reduce((a, id) => a + amountOf(id), 0);\nconst linkedTotal = universe.linked.reduce((a, id) => a + amountOf(id), 0);\nconst unlinkedTotal = universe.unlinked.reduce((a, id) => a + amountOf(id), 0);\n{\n const p = [];\n if (universe.linked.length + universe.unlinked.length !== universe.payments.size) p.push(`linked ${universe.linked.length} + unlinked ${universe.unlinked.length} does not equal the ${universe.payments.size} payments seen`);\n if (cents(linkedTotal + unlinkedTotal) !== cents(universeTotal)) p.push(`linked $${linkedTotal.toFixed(2)} + unlinked $${unlinkedTotal.toFixed(2)} does not equal $${universeTotal.toFixed(2)}`);\n if (universe.unlinked.length !== backlog.payments) p.push(`paymentUniverse() says ${universe.unlinked.length} unlinked, squareBacklog() says ${backlog.payments}`);\n if (cents(unlinkedTotal) !== cents(backlog.total)) p.push(`the unlinked total from Square is $${unlinkedTotal.toFixed(2)} and squareBacklog() says $${backlog.total.toFixed(2)}`);\n if (p.length) {\n shout(\"THE SUBSET DOES NOT RECONCILE AGAINST ITS POPULATION. Nothing was written.\");\n for (const x of p) console.error(` - ${x}`);\n process.exit(1);\n }\n console.log(`Population: ${universe.payments.size} payments $${universeTotal.toFixed(2)} = ${universe.linked.length} linked $${linkedTotal.toFixed(2)} + ${universe.unlinked.length} unlinked $${unlinkedTotal.toFixed(2)}.`);\n}\n\n// Per-payment lookup errors (Square answered the batch but not this one id, e.g. a 404 on that\n// payment) versus payments never asked about are both surfaced the same way in the CSV.\nlet amountMismatches = 0;\nconst enriched = rows.map((row) => {\n const sq = lookups.get(row.paymentId) ?? null;\n const lookupStatus = !sq ? \"not looked up\" : sq.error ? `Square error ${sq.error}` : \"ok\";\n const cust = sq?.square_customer ?? null;\n // Square's own customer records carry stray whitespace on some names (e.g. \"Jonathan \" /\n // \"Jameson \" with trailing spaces baked in) — collapse runs of whitespace rather than pass a\n // double-spaced name through to a client-facing document.\n const name = [cust?.given_name, cust?.family_name].map((s) => (s ?? \"\").trim()).filter(Boolean).join(\" \").replace(/\\s+/g, \" \").trim()\n || (sq?.cardholder_name ?? \"\").trim()\n || null;\n if (sq?.amount != null && cents(sq.amount) !== cents(row.amount)) {\n amountMismatches++;\n shout(`payment ${row.paymentId}: journal amount $${row.amount.toFixed(2)} does not match Square's own amount $${Number(sq.amount).toFixed(2)}. Row is included with the journal figure (the reconciled one); check this one by hand.`);\n }\n const lineItems = (sq?.line_items ?? [])\n .map((li) => `${li?.name ?? \"item not named\"} x${li?.quantity ?? \"?\"}`)\n .join(\"; \");\n // WHAT SQUARE ACTUALLY HOLDS, which is a different question from row.hasTrail.\n // hasTrail is built from hadEmail/hadPhone/hadCustomerId, and those describe the WEBHOOK PAYLOAD\n // the bridge received, not Square's customer record. Live on 12 Aug 2026 they are backwards for\n // two of the four: the payment the flags call unrecoverable is Caroline Riner and Square holds\n // her name and her phone number, while the payment the flags call recoverable carries a Square\n // customer id whose record is empty. This report is what Kim uses to decide which sales are\n // worth chasing, so the column she reads is derived from Square. row.hasTrail is left untouched\n // because reconcile() checks it against squareBacklog()'s own withTrail/noTrail split.\n const holds = [];\n if (name) holds.push(\"a name\");\n if (cust?.phone_number) holds.push(\"a phone number\");\n if (cust?.email_address) holds.push(\"an email address\");\n const whatSquareHolds = holds.length ? holds.join(\", \").replace(/, ([^,]*)$/, \" and $1\") : \"nothing at all\";\n const flagDisagrees = row.hasTrail !== (holds.length > 0);\n return {\n ...row,\n lookupStatus,\n whatSquareHolds,\n squareCanIdentifyThem: holds.length > 0,\n flagDisagrees,\n squareCreatedAt: sq?.created_at ?? null,\n customerName: name,\n customerEmail: cust?.email_address ?? null,\n customerPhone: cust?.phone_number ?? null,\n cardBrand: sq?.card_brand ?? null,\n cardLast4: sq?.last_4 ?? null,\n paymentStatus: sq?.status ?? null,\n lineItems,\n receiptUrl: sq?.receipt_url ?? null,\n receiptNumber: sq?.receipt_number ?? null,\n orderId: sq?.order_id ?? null,\n squareCustomerId: sq?.customer_id ?? cust?.reference_id ?? null,\n };\n});\nif (amountMismatches) shout(`${amountMismatches} payment(s) have a journal amount that disagrees with Square's own amount. See warnings above.`);\n\n// -------------------------------------------------------------------------------------------\n// THE ORDER A FILE CLAIMS IS THE SOURCE'S ORDER, NEVER OURS.\n//\n// unmatchedPaymentRows() returns its rows sorted by the FIRST TIME OUR OWN JOURNAL SAW each\n// payment, which is the right order for a log and the wrong order for a sentence that says \"in\n// the order the payments arrived\". Live proof, 27 July 2026: Square took $1,000.00 at 17:07:42\n// and $795.00 at 17:07:57, and our journal noticed the $795.00 first. This report printed\n// $795.00 above $1,000.00 and told the reader that was the order they arrived in. Fifteen seconds\n// is harmless; the habit is not, because the same claim is made about lists where the order is\n// the whole point. So the list is re-sorted here by Square's own timestamp, falling back to ours\n// only when Square has nothing to say, and the fallback is counted so the sentence below can say\n// which order it is actually in.\nlet orderedBySquare = true;\nfor (const r of enriched) if (!r.squareCreatedAt) orderedBySquare = false;\nenriched.sort((a, b) =>\n String(a.squareCreatedAt ?? a.firstSeen ?? \"\").localeCompare(String(b.squareCreatedAt ?? b.firstSeen ?? \"\")));\n{\n const p = [];\n for (let i = 1; i < enriched.length; i++) {\n const x = String(enriched[i - 1].squareCreatedAt ?? enriched[i - 1].firstSeen ?? \"\");\n const y = String(enriched[i].squareCreatedAt ?? enriched[i].firstSeen ?? \"\");\n if (x > y) p.push(`rows ${i} and ${i + 1} are out of order`);\n }\n if (p.length) { shout(\"THE LIST IS NOT IN THE ORDER IT CLAIMS. Nothing written.\"); p.forEach((x) => console.error(\" - \" + x)); process.exit(1); }\n console.log(`Order check passed: ${enriched.length} rows, oldest first, by ${orderedBySquare ? \"Square's own timestamp\" : \"Square's own timestamp where it has one and ours where it does not\"}.`);\n}\n\nconst namedCount = enriched.filter((r) => r.customerName).length;\nconsole.log(`Of the ${enriched.length}, ${namedCount} came back from Square with a customer name on file.`);\n\n// -------------------------------------------------------------------------------------------\n// STEP 7. WRITE THE CSV. Plain numbers, no currency symbols or thousands separators, so it opens\n// cleanly as data rather than as text. One row per distinct unmatched payment, oldest first.\n// -------------------------------------------------------------------------------------------\nfunction csvField(v) {\n const s = v === null || v === undefined ? \"\" : String(v);\n return /[\",\\n]/.test(s) ? `\"${s.replace(/\"/g, '\"\"')}\"` : s;\n}\nfunction toCsv(headers, records) {\n const lines = [headers.map(csvField).join(\",\")];\n for (const rec of records) lines.push(headers.map((h) => csvField(rec[h])).join(\",\"));\n return lines.join(\"\\n\") + \"\\n\";\n}\n\nconst CSV_HEADERS = [\n \"payment_id\", \"journal_first_seen\", \"journal_last_seen\", \"journal_row_count\",\n \"amount_usd\", \"what_square_holds\", \"square_can_identify_them\",\n // These three describe the webhook payload the bridge received, NOT Square's records, and they\n // are named so nobody reads them as an answer to \"can this sale be placed\". See the comment on\n // whatSquareHolds above: live, they get it backwards for half this list.\n \"journal_flag_called_it_recoverable\", \"had_email_at_ingest\", \"had_phone_at_ingest\", \"had_square_customer_id_at_ingest\",\n \"square_created_at\", \"customer_name\", \"customer_email\", \"customer_phone\",\n \"card_brand\", \"card_last4\", \"payment_status\", \"line_items\",\n \"receipt_url\", \"receipt_number\", \"order_id\", \"square_customer_id\", \"square_lookup_status\",\n];\nconst csvRecords = enriched.map((r) => ({\n payment_id: r.paymentId,\n journal_first_seen: r.firstSeen,\n journal_last_seen: r.lastSeen,\n journal_row_count: r.journalRowCount,\n amount_usd: r.amount.toFixed(2),\n what_square_holds: r.whatSquareHolds,\n square_can_identify_them: r.squareCanIdentifyThem ? \"yes\" : \"no\",\n journal_flag_called_it_recoverable: r.hasTrail ? \"yes\" : \"no\",\n had_email_at_ingest: r.hadEmailAtIngest ? \"yes\" : \"no\",\n had_phone_at_ingest: r.hadPhoneAtIngest ? \"yes\" : \"no\",\n had_square_customer_id_at_ingest: r.hadCustomerIdAtIngest ? \"yes\" : \"no\",\n square_created_at: r.squareCreatedAt,\n customer_name: r.customerName ?? \"(no name on file)\",\n customer_email: r.customerEmail ?? \"\",\n customer_phone: r.customerPhone ?? \"\",\n card_brand: r.cardBrand ?? \"\",\n card_last4: r.cardLast4 ?? \"\",\n payment_status: r.paymentStatus ?? \"\",\n line_items: r.lineItems || \"\",\n receipt_url: r.receiptUrl ?? \"\",\n receipt_number: r.receiptNumber ?? \"\",\n order_id: r.orderId ?? \"\",\n square_customer_id: r.squareCustomerId ?? \"\",\n square_lookup_status: r.lookupStatus,\n}));\nconst csv = toCsv(CSV_HEADERS, csvRecords);\n\n// -------------------------------------------------------------------------------------------\n// STEP 8. WRITE THE SUMMARY. Client safe: US spelling, no dashes as punctuation (hyphens inside a\n// literal product name or a phone number are the only exception, per HANDOFF.md section 10's\n// voice rule), and the word \"daycare\" never appears (she does not offer it; HANDOFF.md section 6\n// and 10 both call this a factual error, not a preference). Both rules are self checked below and\n// the run fails loudly rather than ship copy that breaks either one.\n// -------------------------------------------------------------------------------------------\nconst money = (n) => `$${n.toLocaleString(\"en-US\", { minimumFractionDigits: 2, maximumFractionDigits: 2 })}`;\n\nfunction fmtDate(iso) {\n if (!iso) return \"date unknown\";\n const d = new Date(iso);\n if (Number.isNaN(d.getTime())) return \"date unknown\";\n const months = [\"Jan\", \"Feb\", \"Mar\", \"Apr\", \"May\", \"Jun\", \"Jul\", \"Aug\", \"Sep\", \"Oct\", \"Nov\", \"Dec\"];\n return `${d.getUTCDate()} ${months[d.getUTCMonth()]}`;\n}\n\nconst now = new Date();\nconst dateSuffix = process.env.EXCEPTION_REPORT_DATE ||\n `${now.getUTCDate()}-${[\"Jan\", \"Feb\", \"Mar\", \"Apr\", \"May\", \"Jun\", \"Jul\", \"Aug\", \"Sep\", \"Oct\", \"Nov\", \"Dec\"][now.getUTCMonth()]}`;\n\n// The last column USED to be \"Recoverable\", read straight off r.hasTrail. That column told Kim\n// that Caroline Riner, whose name and phone number are sitting in Square, could not be placed,\n// and that a sale with no name, no email and no phone anywhere could be. It is derived from\n// Square now. See the whatSquareHolds comment in STEP 6.\nconst mdRows = enriched.map((r) => {\n const contact = r.customerEmail || r.customerPhone || \"none on file\";\n return `| ${fmtDate(r.squareCreatedAt || r.firstSeen)} | ${money(r.amount)} | ${r.customerName ?? \"(no name on file)\"} | ${contact} | ${r.whatSquareHolds} |`;\n});\nconst flagsWrong = enriched.filter((r) => r.flagDisagrees);\n\nconst explainer = squareSentence(backlog); // generated straight from the reconciled numbers above\n\nconst mdParts = [];\nmdParts.push(`# Weekly Square exception report, ${dateSuffix}`);\nmdParts.push(\"\");\nmdParts.push(\"Hi Kim,\");\nmdParts.push(\"\");\nmdParts.push(`This is the short weekly list I promised: every Square sale that has not reached a customer record in your CRM. This run read all ${journal.length} rows in the bridge's payment journal, covering ${fmtDate(spanStart)} to ${fmtDate(spanEnd)}, and asked Square directly for the receipt behind each of the ${backlog.payments} unmatched payments it found.`);\nmdParts.push(\"\");\nmdParts.push(explainer);\nmdParts.push(\"\");\nif (backlog.payments > 0) {\n mdParts.push(`Square could put a name to ${namedCount} of the ${backlog.payments}. The full list, oldest first, in the order Square itself took the money${orderedBySquare ? \"\" : \", except where Square has no time recorded and our own is used instead\"}:`);\n mdParts.push(\"\");\n mdParts.push(\"| Date | Amount | Customer | Contact | What Square holds for them |\");\n mdParts.push(\"|---|---|---|---|---|\");\n mdParts.push(...mdRows);\n mdParts.push(\"\");\n mdParts.push(`That last column comes from Square's own customer records, asked just now, one call per payment. An earlier version of this list built it from a flag the card reader sets at the moment of sale, and that flag turns out to describe the message the till sent rather than what Square keeps, so it was wrong about ${flagsWrong.length} of these ${backlog.payments}.`);\n mdParts.push(\"\");\n mdParts.push(`Card details, the Square receipt link and what was rung up for every row are in the attached CSV, ${`exception-report-${dateSuffix}.csv`}.`);\n} else {\n mdParts.push(\"Nothing to list this week. Every Square payment reached a customer record.\");\n}\nmdParts.push(\"\");\nmdParts.push(`Here is the whole population those ${backlog.payments} came out of, so the figure can be checked against something rather than quoted on its own. The bridge has handled ${universe.payments.size} card sales worth ${money(universeTotal)} since it was switched on. ${universe.linked.length} of them worth ${money(linkedTotal)} reached a customer record, and ${universe.unlinked.length} worth ${money(unlinkedTotal)} did not. Those two add back to ${money(universeTotal)} exactly, and the ${money(unlinkedTotal)} is the same figure your CRM engine's own reconciliation logic produces, computed separately and checked against this list row by row.`);\nmdParts.push(\"\");\nmdParts.push(\"Amir\");\nconst md = mdParts.join(\"\\n\") + \"\\n\";\n\n// SELF CHECK: the two client facing rules, enforced mechanically rather than trusted by eye.\n{\n const problems = [];\n if (/daycare/i.test(md)) problems.push('the word \"daycare\" appears in the summary');\n // Dash as punctuation: an em dash, an en dash, or a hyphen with a space on both sides. Table\n // pipes and the markdown header rule \"|---|\" are excluded; phone numbers (E.164, no spaces\n // around the hyphen) and the file's own hyphenated name are the documented exceptions and do\n // not match this pattern because they carry no surrounding space.\n const proseOnly = md.split(\"\\n\").filter((l) => !l.startsWith(\"|\")).join(\"\\n\");\n if (/—|–/.test(proseOnly)) problems.push(\"an em dash or en dash appears in the summary\");\n if (/\\s-\\s/.test(proseOnly)) problems.push('a hyphen is used as punctuation (surrounded by spaces) in the summary');\n if (problems.length) {\n shout(\"CLIENT-SAFE COPY CHECK FAILED. Not writing the summary.\");\n for (const p of problems) console.error(` - ${p}`);\n process.exit(1);\n }\n console.log(\"Client-safe copy check passed: no dashes as punctuation, no \\\"daycare\\\".\");\n}\n\n// -------------------------------------------------------------------------------------------\n// STEP 9. WRITE THE FILES.\n// -------------------------------------------------------------------------------------------\n// NOT A CLIENT FILE ANY MORE, 12 Aug 2026. This report and the counter sales pack were two\n// documents about the same four payments, sent together, and the second one pointed at a\n// companion CSV that was not even in the send. Duplicate documents about one thing are the exact\n// confusion the client was apologised to for. The internal weekly report stays, because the\n// reconciliation it runs against engine/facts.ts squareBacklog() is worth having; it writes to the\n// repo, and the file the client reads is Counter-sales-with-no-customer.csv, built by\n// scripts/counter-sales-correction.mjs in the same run as everything else she is sent.\nconst OUT_DIR = process.env.EXCEPTION_REPORT_OUT_DIR || join(ROOT, \"reports\");\nif (OUT_DIR === \"/mnt/user-data/outputs\") {\n shout(\"this report is internal and must not be written into the client's folder. Unset EXCEPTION_REPORT_OUT_DIR.\");\n process.exit(1);\n}\nmkdirSync(OUT_DIR, { recursive: true });\nconst csvPath = join(OUT_DIR, `exception-report-${dateSuffix}.csv`);\nconst mdPath = join(OUT_DIR, `exception-report-${dateSuffix}.md`);\nwriteFileSync(csvPath, csv);\nwriteFileSync(mdPath, md);\n\nconsole.log(\"\");\nconsole.log(`Wrote ${csvPath} (${csvRecords.length} data rows)`);\nconsole.log(`Wrote ${mdPath}`);\nconsole.log(\"\");\nconsole.log(`SUMMARY: ${backlog.payments} unmatched payments totaling ${money(backlog.total)} as of ${new Date().toISOString()}.`);\nconsole.log(` ${backlog.withTrail} with a trail worth ${money(backlog.withTrailTotal)}; ${backlog.noTrail} with none worth ${money(backlog.noTrailTotal)}.`);\nconsole.log(` Reconciled against engine/facts.ts squareBacklog() exactly. ${journal.length} journal rows inspected.`);\n\n\n",[583],"27dd5369-5a58-481d-994c-6db4973a9cc6","SOURCE-BUNDLE.part36.txt","3b0a5598-9823-11f1-8573-1607ee4eb77e",1085,["D",1786801893535],"THE DOGS SPOT — SOURCE BUNDLE (part 36 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (3 of 116 files)\n AMIR-DO-THIS.md 17302 bytes 38fd4f8c0800\n handover/KIM-MESSAGE-10-AUG-FINAL.txt 9574 bytes 662833b64b99\n BUILD-PLAN-10-AGENTS.md 14587 bytes 6a00fc55596e\n\n================================================================================================\n=====FILE AMIR-DO-THIS.md =====\n# AMIR, DO THIS. Everything I cannot do without you, in order.\nMonday 10 August 2026. Nothing below has been done. Nothing has been deployed this session.\n\n---\n\n## UPDATE 2, 18:5xZ. TWO FIXES ARE BUILT, TESTED, DEPLOYED AND VERIFIED LIVE.\n\n**The consent inversion is fixed.** `puppy_path_v1.1.ts`, deployed v677. I verified the direction\nagainst **2,500 live contacts** before touching it, and the evidence is unambiguous: `active` means\nthe Do Not Disturb switch is ON, and 55 contacts carry SMS `active` with `TWILIO_ERROR_CODE: 30006`\nand no top-level DND, so the old code would have texted every one of them. 25 more carry `permanent`\nwith `STOP_KEYWORD`. Kristina Gant, the only person tagged for this sequence, is `inactive` on every\nchannel, which the old code read as blocked.\n\nThe predicate now allow-lists the two states that mean go, so an unrecognised status **fails closed**.\n`readChannelConsent` is now exported, and the fake test that grepped the source text for the word\n\"active\" is replaced by three tests that CALL it with the three live shapes. Fault injection proves\nthey work: restore the old comparison and two of them go red. Full evidence is in NOTES-v1.4.md R31.\nLive check after deploy: `testMode: true`, nothing reached anybody.\n\n**The weekly report's false Facebook number is fixed.** `report.ts` and `report-logic.ts`, deployed\nv679 and v680. It read the CRM's `source` column, which is null on 78 percent of contacts.\n\nLive, before: \"the CRM recorded **0** contacts tagged Facebook/Instagram/Messenger\".\nLive, now: **\"151 of the 175 new contacts in your CRM arrived from Facebook or Instagram\"**, and her\nsource table reads Facebook 140, Instagram 11 instead of showing \"no source recorded\" as her largest\nchannel. Two new tests, R15 and R16, both proven to go red on the old code.\n\n**That is Friday's report fixed before Friday.** Suite is green, 18 suites, 394 assertions, and the\nbundle is pushed.\n\n**One thing worth knowing:** my first attempt at the consent fix pushed `main.ts` over its 80,000\ncharacter ceiling and the deploy gate refused it. The comment went to NOTES-v1.4.md instead. That\nceiling is real and there are now 420 bytes of headroom.\n\n---\n\n## UPDATE, 18:1xZ. I DROVE YOUR CHROME AND READ THREE THINGS. TWO OF THEM CHANGE THE LIST.\n\nRead only, as agreed. Nothing was changed anywhere.\n\n### FINDING 1. You have NO GoHighLevel access to Kim's account. Four items on this list collapse into one ask.\n\nEvery URL for her location bounces straight to `agency_launchpad` under **your own agency, \"Inquiry\nEmbodied\"**. Your Sub-Accounts list is **empty**, and your own setup guide still lists \"Create a\nsubaccount\" as an outstanding step. The Dogs Spot lives on **her** GoHighLevel, not yours.\n\nYou have an API token she pasted, which is why everything I do programmatically works. **You do not\nhave a UI login**, and these four are dashboard only:\n\n- Section 3, the sending domain and the four DNS lines\n- Section 8, the three stale product prices\n- Section 9, the seventeen payment links\n- Section 2, reading the contact timeline to see what applies the nurture tag\n\n**So stop treating these as four tasks. They are one ask: Kim adds you as a user on her GoHighLevel\nlocation.** Until she does, none of the four can start, by you or by me. That ask is not in the\nmessage you already sent, so it needs a short follow up.\n\n### FINDING 2. The val has TWO environment variables. Not twenty one.\n\n`META_TOKEN` and `META_AD_ACCOUNT`. That is the entire list.\n\n**`TEST_MODE` does not exist as a variable at all.** Nor does `GHL_TOKEN`, `TAG_SOURCE_SIGNAL`,\n`SEND_WINDOW_START_HOUR`, `ENROLL_SURGE_THRESHOLD` or any of the others.\n\nThree consequences, and the first one is good news:\n\n- **Every default I have been quoting is the live value**, because nothing is overriding anything.\n The tag really is `nurture - puppy`. The send window really is 9 to 19 Eastern. Sunday really is\n off. The surge hold really is 25. No surprises are hiding in that panel.\n- **Going live means ADDING a variable, not editing one.** The runbook says \"set `TEST_MODE` to\n false\", which reads like changing an existing row. There is no row. You click **Add**, key\n `TEST_MODE`, value `false`, on the val `dogsspot_puppy_path`, Env vars tab.\n- **The GoHighLevel token is not in an environment variable**, so it lives in the config blob. That\n changes the key rotation: rotating means writing the blob, not editing a variable. Section 6 of the\n handoff needs correcting.\n\n### FINDING 3. Wix cannot take money at all right now. This settles the deposit question for good.\n\nYou **are** logged into her Wix as The Dogs Spot, so this one I could read properly.\n\n**Settings, Accept Payments shows Square connected**, account `sq0i******`, credit and debit cards.\nPayPal is connected too, on an account ending `otch**@g*******`.\n\n**Both read \"Not accepting payments. Switch Plans.\"** And the banner across the top says \"To start\ngetting paid online, switch to a Premium plan.\"\n\nSo the site is on a Wix plan that does not include online payments. **That live holiday deposit form\nwith the Pay Deposit button on it would dead end today**, exactly as I suspected but could not prove\nfrom outside.\n\n**This makes the answer to Kim unambiguous.** Collecting the deposit through Wix is not \"possible but\nunwise\", it is **not possible without her paying to upgrade her Wix plan**, and even then it would\nland in a ledger the CRM cannot see. The payment link route is the only one that works, and it costs\nher nothing. What you already sent her is correct; this just makes it airtight if she pushes back.\n\n**One thing to check with her, separately from all of this:** PayPal is connected to her site on an\naccount that is not obviously hers, and there is an unconfirmed email notice for\n`iziquickbooks@gmail.com` sitting on the account. Worth a quiet question about who holds what.\n\n---\n\n## STOP. TWO THINGS FOUND IN FINAL CHECKS MEAN NURTURE MUST NOT GO LIVE TODAY.\n\n**1. The consent reading is backwards.** `puppy_path_v1.1.ts:827-841`. In GoHighLevel, a channel\nstatus of `active` means Do Not Disturb is ON for that channel. A status of `inactive` means the\nperson is free to contact. The engine reads it the other way round.\n\nWhat that means if we had flipped the switch today:\n- **59 contacts** in her account who have Do Not Disturb on for a channel would have been messaged.\n- **Kristina Gant, the only person who would actually have enrolled, would have received nothing.**\n Her email and SMS both read `inactive`, meaning she is contactable, and the engine would have\n treated that as opted out. All eight steps would have been consumed as skips inside a day and she\n would have gone silent forever.\n- The first run would have printed `enrolled:1, sent:0, failed:0` and looked like a clean launch.\n\n**It has zero test coverage.** The one test that touches it greps the source text for the word\n`active` rather than running the function. That is why it survived 394 assertions and 203 negative\ncontrols.\n\n**2. The money feature has no ingestion layer at all.** `money-match.ts` is imported by its own test\nand by nothing else. There is no code anywhere in the repo that reads Square payments and feeds them\nto it. Every number on Kim's money page was produced by a process that is not in the repository. So\nthe stage filter, the `payment_link` acceptance and the $0 filter are **unwritten, not\nmisconfigured**. That is a build, not a patch.\n\n**Neither is a disaster. Both were caught before anything reached a customer, which is what the\nchecks are for. But do not flip the flag until they are fixed.**\n\n---\n\n## 1. THINGS ONLY YOU CAN SEE OR SET · val.town environment\n\nI cannot read environment variable values through any API. Four routes tried, all 404.\n\nGo to **val.town → val `dogsspot_puppy_path` → Environment variables** and tell me the values of:\n\n- [ ] `TAG_SOURCE_SIGNAL` — I proved indirectly it is currently `nurture - puppy`, because\n `dashboard.ts` interpolates the live value into her card page and the page renders that string.\n Confirm it anyway.\n- [ ] `SEND_WINDOW_START_HOUR` and `SEND_WINDOW_END_HOUR` — defaults 9 and 19, Eastern.\n- [ ] `SMS_SUNDAY_OK` — default false.\n- [ ] `ENROLL_SURGE_THRESHOLD` — default 25.\n- [ ] `MAX_SENDS_PER_RUN` and `MAX_SENDS_PER_DAY` — defaults 20 and 50.\n- [ ] `TEST_MODE` — must read `true` right now. It does.\n- [ ] Confirm `GHL_TOKEN` matches the token in the `puppy_config` blob. If a rotation ever updates\n one and not the other, the engine crashes on every run.\n\nThere are **21 environment variables** in total and none of them is a channel switch. That matters\nfor the email question below.\n\n---\n\n## 2. THE TAG. THIS IS ON THE CRITICAL PATH AND ONLY YOU CAN CHECK IT.\n\nThe API lists workflows but exposes no triggers or actions. `GET /workflows/{id}` returns 404.\n\n**Open these two contacts in GoHighLevel and read the Activity timeline** to see what added the tag\n`nurture - puppy`:\n\n- `h1sEguI5pPKncyaiTMw0` — Kristina Gant, tagged 5 August\n- `JwnIihtdcd9nwfTSCcl4` — no name, phone +17872431024, tagged 9 August\n\n**Why it matters:** if a workflow applies it, the tag is inside the Kristian freeze and Kim has to\nexempt that too. If a person applies it, nothing is blocked. Evidence points to manual: her own card\npage says \"No automation applies the tag yet\", and a note records Candice tagging Kristina by hand.\nConfirm it rather than trusting that.\n\n---\n\n## 3. THE SENDING DOMAIN AND THE FOUR DNS LINES · needs you AND Kim\n\nThis is the answer to your first question, and it is **both**.\n\n- **Creating the dedicated sending domain** is inside her GoHighLevel: Settings, Email Services,\n Dedicated Domain and IP. That needs a login with settings access. Your browser holds your own\n agency session and The Dogs Spot is not a sub account of it, which is why every settings URL has\n bounced. **You need to be in her location, not yours.**\n- **Publishing the four DNS records** needs whoever controls DNS for `thedogsspotga.com`. That is\n Kim or her web person. **You cannot do it and neither can I.**\n\n**Good news that makes this easier than it looks.** Her location already has\n`links.thedogsspotga.com` delegated and working as the CRM link domain. So DNS records for this\ndomain have been added successfully before, by somebody, and that person is the one to ask. Ask Kim\nwho added the `links` record.\n\n`defaultEmailService` on her location is confirmed **empty** as of today, so no dedicated domain\nexists yet.\n\n- [ ] Get into her GoHighLevel settings, generate the four records\n- [ ] Send them to Kim with the exact screens, which is what she asked for\n- [ ] She or her web person publishes them\n- [ ] Come back and confirm `defaultEmailService` is no longer empty\n\n---\n\n## 4. THE EMAIL HALF, AND A DECISION ONLY YOU CAN MAKE\n\n**There is no flag that turns the email half off.** I checked all 21 environment variables. Turning\nit off means editing `MAIN_SEQUENCE` and redeploying, which is a code change.\n\n**And `main-1` is an email at offset zero.** It is the very first thing every enrollee receives.\nFive of the eight main steps are email.\n\nWith `defaultEmailService` empty, the visible From will read The Dogs Spot and\n`info@thedogsspotga.com`, but the envelope sender and the signing domain belong to LeadConnector's\nshared pool. Spam risk is real and cannot be controlled from our code. The unsubscribe is a plain\nsentence saying reply UNSUBSCRIBE, not a proper List-Unsubscribe header, which is what Gmail and\nYahoo now expect from bulk senders.\n\n**Your call, and it needs making before go live:**\n- **(a)** Go live with texting only, which means a code change to drop the email steps, then add them\n back once the domain is live. Safest for deliverability, and the sequence loses half its content.\n- **(b)** Go live with both and accept shared-pool deliverability for the first few weeks.\n- **(c)** Wait for the sending domain before going live at all. Cleanest, and it hands the delay to\n whoever controls her DNS.\n\n**My recommendation: (a).** She has approved go live and wants it moving. Texting is the half that is\nfully verified. The email half at 45 percent going out from a shared pool to her actual customers is\nthe kind of thing that is invisible until somebody says they never got it.\n\n---\n\n## 5. EMAIL KRISTIAN. ONE SENTENCE. STILL NOBODY HAS SENT IT.\n\n`solutions@moorecre8ive.com`. Cheapest unblock on the whole board and it has been open since 7 August.\n\n> Kristian, one quick technical question so I do not collide with your application. Does it write the\n> monetaryValue field on opportunities, or move cards between pipeline stages? I am building payment\n> to booking reconciliation and I need to know which fields you own. Amir\n\n---\n\n## 6. GOOGLE ADS DEVELOPER TOKEN. APPLY TODAY SO HER TIMELINE STOPS BEING A GUESS.\n\nShe asked for a date. Nobody has applied, so any date given now is invented.\n\n- [ ] Google Ads account, then **Tools, Setup, API Center**\n- [ ] Apply for a developer token, Basic access is enough\n- [ ] Google quotes about five business days\n- [ ] Tell Kim the real date the moment it is approved, not before\n\n---\n\n## 7. WIX. TWO MINUTES, AND IT CLOSES A PROMISE.\n\n- [ ] Log into the Wix dashboard for `thedogsspotga.com`, site id\n `b2c187cc-fc91-42ab-b6f6-1560077ab20b`\n- [ ] **Settings, Accept Payments.** Confirm whether a payment provider is connected and which one.\n\n**Context so you know what you are looking at.** The processor question is already answered and it is\nSquare, through GoHighLevel, merchant `7KF50NPQP8WPT`. The `/payments` page on her site titled Pay\nBootcamp Deposit is a contact form with a Pay Now button and has never taken money. Every deposit ever\ncollected was a CRM invoice.\n\nThere is also already a live holiday deposit form at `/holiday-boarding-booking-form` with a real Wix\npayment field, $50 minimum, Pay Deposit button. **Do not use it.** Wix collected money lands in Wix's\nown ledger and produces no CRM record at all, so it would be invisible to the matcher and to revenue\nreporting. Across all 233 CRM transactions there is no Wix source and no Wix to CRM bridge.\n\n---\n\n## 8. PRODUCT PRICES. FIX BEFORE ANY PAYMENT LINK IS BUILT.\n\nThree program prices in her CRM are stale. Build links on these and the front desk undercharges\nevery single time.\n\n| Product | CRM says | Should be | Product id |\n|---|---|---|---|\n| Basic Bootcamp | $2,300 | $2,395 | `69388f3eccecbd56ba6a58d0` |\n| Community Program | $3,300 | $3,295 | `69386465d66487483f217353` |\n| Leash Free program | $3,600 | $3,795 | `693f0b6cd0aaf6c16ff4a051` |\n\nCorrect in the dashboard, not the API, so they stay linked to existing invoices.\nAlso fix the typo: the product is named **\"Boarding Trainind\"**.\n\n**Confirm the prices with Kim first.** The message to her asks.\n\n---\n\n## 9. THE PAYMENT LINKS. DASHBOARD ONLY, THERE IS NO API.\n\n`GET /payments/link`, `/payments/links` and `/payments/payment-links` all 404. They must be built by\nhand. About 17 of them. Path: **Payments, Payment Links, Create New Payment Link.** Set **Live** mode,\nnot Test.\n\nPrograms: Basic Bootcamp $2,395 · Community $3,295 · Leash Free $3,795 · Bundle $4,095 ·\nService Dog $5,500\nDeposits: Bootcamp Deposit $500 · Holiday Boarding Deposit $50 with quantity enabled so two dogs is\n$100 · New Client Boarding Deposit $50\nBoarding: Non-Trained $35/day · Trained $30/day · Special Needs Non-Trained $45/day · Special Needs\nTrained $40/day\nAdd-ons: Refresher Session $35 · Fetch Time $35 · Private Lesson Package $900 · Medication Fee $3 ·\nFood Charge $4\n\n**After creating each link, take its id from the dashboard URL and send me the list.** The link id\narrives on every payment as `entitySourceId`, which tells reporting which program was bought without\nparsing line items. That is the clean join and it is free if we capture it now.\n\n**This will feed the same reporting, and that is proven not assumed.** Two payment link transactions\nalready exist in her CRM from a January test. They carry a contactId, the Square provider and the\nsame connected account as every invoice. All 233 transactions carry a contactId, 100 percent.\n\n---\n\n## 10. REMOVE THE TEST DUMMY BEFORE GO LIVE. THIS ONE HAS A DATE ON IT.\n\n`mxf92ajJDtsZMHqJxAKv`, ZZTEST PuppyPath-Dummy, is still sitting in the engine's state blob at\n`main` step 5.\n\nThe moment `TEST_MODE` goes false, the `[TEST]` prefix disappears and the send guard stops guarding\nit. Then:\n- **`main-6` is an email due 2026-08-12 16:38Z**, unprefixed, to your own gmail\n- **`main-7` is an SMS to `+10000000000`**, a guaranteed carrier failure that lands as a permanent\n failure on Kim's dashboard\n\nIt also inflates her \"who is in the system\" count and makes the honest sentence on her page about one\ntest record false.\n\n**Delete that key from the `puppy_state` blob before flipping.** I have not touched it.\n\n---\n\n## 11. SEND THE MESSAGE TO KIM\n\n`KIM-MESSAGE-10-AUG-FINAL.txt`, attached separately. Attach\n`TheDogsSpot-Square-Revenue-Explained.html` to it.\n\n**Clear the Upwork composer before pasting.** It appends rather than replaces.\n\n---\n\n## WHAT I AM DOING NEXT, WITH YOUR GO AHEAD\n\nEverything in `BUILD-PLAN-10-AGENTS.md`. Nothing built yet, as you asked. The plan is written, the\nagents are scoped, and the errors are found.\n\n\n\n=====FILE handover/KIM-MESSAGE-10-AUG-FINAL.txt =====\nHi Kim,\n\nEverything is below, and the Square and revenue piece is attached as its own page so you\ncan keep it and come back to it.\n\nThank you for the correction on the pipeline. I had the card movement down as a manual\nstep and it is not one, so nothing in the document asks your staff to do it.\n\nTHE SQUARE AND REVENUE PIECE\nAttached, written the way you asked: what happens today, what happens once the\nreconciliation runs, and what your staff actually have to do. The short version is that\nyour Square money already reaches your CRM and already knows whose money it is. The step\nthat has never happened is writing the amount onto the booking, and reports add money up\nfrom bookings, which is why revenue reads near nothing while the money plainly exists.\nThat is one field and it is the whole gap.\n\nYOUR MATCHING RULE\nLocked in exactly as you wrote it. One open opportunity, assign automatically. More than\none, exception list for the team to pick. Anonymous or unmatched, reported separately and\nnever guessed at.\n\nRun against every payment you have today: 15 place themselves, worth $7,880. Nothing at\nall goes to the exception list, because not one customer is currently sitting on more than\none open booking. 15 are already priced and get left alone. 6 cannot be placed.\n\nTHE CORRECTED UNMATCHED FIGURE YOU ASKED FOR\n33 counter sales worth $22,651.99. The original 42 worth $33,535.99 was overstated by\n$10,884.00 and that was our error, not yours. Of the 33, four have a partial trail worth\n$2,829.99 and 29 worth $19,822.00 arrived with no name, email or phone attached at all.\n\nTHE NURTURE, AND ONE THING I WANT TO BE STRAIGHT WITH YOU ABOUT\nThank you for the go ahead. I ran the full pre flight check before switching it on rather\nthan after, and it found something I am glad it found: the system was reading your CRM's\nper channel Do Not Disturb settings backwards. Left alone it would have messaged people\nwho had asked not to be contacted, and skipped one person who had not. Both are the wrong\nway round and both are fixable today.\n\nSo I am fixing that first and switching on this week rather than this afternoon. I would\nrather tell you that than switch it on and hope. The check is exactly what it was for.\n\nOne thing I need from you when we do go live. Switching it on means turning off your old\nworkflow called \"1. Wait 1 Day: Initial Nurture - Puppy\", and the freeze you and Kristian\nagreed covers workflow changes. You have said that workflow has never been used. Can you\nconfirm you are happy for that one to be switched off inside the freeze? That is the only\nthing I need from you.\n\nThe email to your team at info@thedogsspotga.com goes out the same day it goes live, with\nsimple instructions on anything they need to watch for.\n\nMILTON'S APP\nAgreed. It stays fully operational for boarding until Kristian's occupancy numbers have\nmatched your real numbers every day for a full week. Thank you for forwarding his note as\nwell, it is the first clear description I have had of how his app hands appointments to\nthe CRM, and it tells me exactly what to leave alone.\n\nTHE HOLIDAY DEPOSIT\nYour second option is the right one and I want to explain why, because I found something\nthat changes the reasoning.\n\nThere is already a holiday deposit form on your website with a working payment field on\nit. So it can technically be done there. But money collected through Wix settles into\nWix's own payments area and produces no record in your CRM at all. It would be invisible\nto the matching and to the revenue reporting we are building, which means you would end up\nwith two separate sets of books.\n\nLeaving the booking form alone and sending a deposit link afterward keeps every deposit in\nthe same place as everything else. Milton's app is untouched either way.\n\nTHE WIX PROCESSOR QUESTION\nSquare, but through GoHighLevel rather than through Wix, on merchant account ending 8WPT.\nWorth knowing: the page on your site titled Pay Bootcamp Deposit is a contact form with a\nPay Now button on it, and it has never actually taken money. Every $500 deposit you have\never collected was a CRM invoice paid by card.\n\nPAYMENT LINKS FOR THE FRONT DESK\nYes, and they will feed the same matching and reporting. I checked rather than assumed:\nthere are already two payment link transactions sitting in your CRM from a test in January,\nand they carry the customer and the same Square account as your invoices do. Around 17\nlinks, clearly labeled by program, so the team picks one instead of building an invoice.\n\nOne thing to confirm before I build them. Three of your program prices in the CRM are out\nof date: Basic Bootcamp reads $2,300, Community reads $3,300, and Leash Free reads $3,600.\nIf we build links on those the front desk undercharges every time they send one. Can you\nconfirm the correct current prices?\n\nWhile I was in there: 26 of your 57 invoices are sitting in draft, so nearly half of what\ngets built at the counter never goes out. These links should take most of that away.\n\nTHE FACEBOOK CONTACTS WITHOUT AN AD ID\nGood news, and it is not lost attribution. I checked all 5,656 contacts in your account.\nEvery single one marked as paid social carries an ad ID, and every single one marked as\norganic social does not. There are no exceptions in either direction. The ones without an\nad ID are people who messaged you directly, replied to a comment, or came through your\nprofile. There is no ad ID because there was no ad click.\n\nAd attribution on your click to message ads is running at 506 out of 506 over the last 30\ndays.\n\nOne real weakness worth watching. Facebook keeps the ad ID on 79 percent of contacts,\nInstagram on 40 percent. The Instagram sample is small so I would rather look again in 90\ndays than change anything on it now.\n\nVERIFYING WHAT WE SEND BACK TO FACEBOOK\nIt is live and Facebook is accepting all of it. Between 14 July and 8 August we sent 22\npurchase events, Facebook accepted every one with no errors, worth $11,797.\n\nYou can see it yourself: Events Manager, then Data Sources, then the dataset ending 4356,\nthen the Overview tab. The Purchase row there carries a Server badge, which means it came\nfrom us rather than from somebody's browser. There is also a Test Events tab where I can\nfire a live one while you watch, if you want to see the round trip.\n\nThe honest part: only about one payment in five currently fires one of those events,\nbecause the payments we cannot match to a customer never reach that step. Sixty of those\nalready have an email or a phone number on them, which is all Facebook needs. Fixing it\nwould take what Facebook sees from around $11,800 to around $73,000, which is most of what\nit should be optimizing against. I would like to put that on the list.\n\nGOOGLE\nI would rather not give you a date I cannot stand behind. Getting Google onto the same\nfooting needs a developer token from Google, which they quote at about five business days\nonce applied for, and the application has not gone in yet. That is on me. It goes in this\nweek and you get a real date the moment it is approved. Until then the Google numbers stay\nmanual and I will keep labeling them as manual.\n\nRETARGETING\nYes, and I would start somewhere slightly different from the obvious place.\n\nJust over half your contacts have no email or phone number, because Messenger hands over a\nconversation rather than a contact card. So a customer list audience is smaller than it\nlooks, around 600 to 870 matched people.\n\nI would start with a Facebook engagement audience: everyone who has messaged your page in\nthe last year. It needs no email or phone at all, Facebook builds it from its own records,\nand it is at least 3,225 people. It is also the only way to reach the roughly 1,240 people\nwho came in from your ads in the last 90 days, never converted, and left no way to contact\nthem.\n\nThen the customer list second, used first as an exclusion so you stop paying to advertise\nto people who have already bought.\n\nTHE REVIEW WORKFLOWS\nYes, the email came through, thank you. It answered the question I had and it closes it\nwith a number: your two workflows are not duplicates, they fire on different tags, and\nnobody has ever been asked twice. 118 people have gone through the first, 2 through the\nsecond, and nobody carries both.\n\nIt did surface three things your document does not flag.\n\n138 of your 178 review cards are sitting in Survey Requested with no time limit set, so\nanyone who never replies stays there permanently.\n\nThe last step, tagging the card once you know what they wrote, is manual and has never been\ndone. Your 5 Star, 4 Star and Bad Review columns all hold zero, which means 37 people were\nsent a Google review link and there is no record of who actually left one.\n\nAnd the older workflow, the one 118 people went through, has no escalation step. An unhappy\nanswer gets an automatic message and nobody is told. Only the newer one raises a task for\nsomebody. Two people are sitting in the 1 to 6 range right now.\n\nI would like to fix all three.\n\nSTILL COMING FROM ME\nThe four DNS lines with the screens. That needs me inside your CRM settings to generate\nthem, and then somebody with access to your domain's DNS to publish them. Your CRM already\nuses links.thedogsspotga.com, so those records have been added successfully before. Do you\nknow who did that? That is the person I need for fifteen minutes.\n\nThe dates issue on your page. I have reproduced it and traced it to nine lines of text that\nsay things like \"this evening\" rather than carrying the actual date. It is being fixed\nproperly rather than patched.\n\nAmir\n\n\n\n=====FILE BUILD-PLAN-10-AGENTS.md =====\n# THE BUILD, TEN AGENTS. Planned, not started.\nMonday 10 August 2026. Analysis complete. Nothing built, nothing deployed, per instruction.\n\nEverything below is scoped from defects confirmed against live production data today, not from\nguesses. Each agent has one owner, one deliverable, a stated blast radius and a test that must fail\non the old code before it passes on the new.\n\n---\n\n## THE RULE THAT GOVERNS ALL TEN\n\n**No agent ships a fix without a test that goes red on today's code.** This project has 394\nassertions and 203 negative controls and it still shipped an inverted consent check, because the one\ntest that touched it grepped the source text for a word instead of running the function. A green\nsuite is not evidence. A test that fails first is.\n\n**Order matters.** Agents 1 to 3 block go live. Agents 4 to 6 block the money feature. Agents 7 to\n10 are parallel and block nothing.\n\n---\n\n## WAVE ONE · BLOCKS NURTURE GO LIVE · run these three first, in parallel\n\n### AGENT 1 — THE CONSENT INVERSION\n**The single most important fix on the board.**\n`puppy_path_v1.1.ts:827-841`. `readChannelConsent` returns blocked for everything except `active`.\nIn GoHighLevel `active` means Do Not Disturb is ON and `inactive` means free to contact, so the\npredicate is exactly backwards.\n\nLive blast radius, measured across 2,500 contacts: **59 contacts with per channel Do Not Disturb on\nand top level dnd false would be messaged anyway. 5 contactable people would be silently refused, one\nof whom is Kristina Gant, the only person who will actually enroll.**\n\n- Fix the predicate: blocked is `status === \"active\" || status === \"permanent\"`.\n- Confirm the three live shapes first: `permanent` with `STOP_KEYWORD`, `active` set by a workflow\n alongside top level `dnd:true`, `inactive` set by Kim by hand.\n- Delete test I3 in `tests/harness.mjs:495-504`. It greps source text and proves nothing. Replace it\n with a real unit test that calls the function with each live shape.\n- Add a negative control that makes the new test go red.\n- **Then re-check every other predicate in the file that reads a GoHighLevel enum.** One inverted\n boolean survived every existing check; assume there are others until proven otherwise.\n\n### AGENT 2 — MAKE DEFERRALS VISIBLE\nOn go live day you will not be able to tell \"correctly waiting\" from \"silently broken\", and that is\nnot acceptable on a launch nobody is watching.\n\n`:1428-1434` handles every `{kind:\"skip\"}` with `out.skipped++; break;`. The reason string is\ncomputed and thrown away. Four different causes land there: outside the send window, minimum gap,\nforeign sender quiet period, and a failed conversation read.\n\n- One line: push the reason onto `out.log`.\n- Write a journal row for each deferral with its cause, so the run history answers the question later.\n- Split the counters: `deferredWindow`, `deferredGap`, `deferredForeign`, `deferredCheckFailed`.\n- Add a test that a deferred contact produces a log line naming the cause.\n- **Also:** `conversationCheckFailed` at `:348-350` fails closed into the same silent path. If the\n conversations endpoint degrades, nothing sends to anybody and the log is empty. Make that one loud.\n\n### AGENT 3 — GO LIVE HARDENING\nFour separate things that each turn a launch into a mystery.\n\n- **Wrap `fetchPupTalkApptIndex()` at `:1028`.** It is unwrapped and runs before the TEST_MODE\n branch, so one 401 aborts the entire run before a single contact is examined. **This has already\n happened once**, stored `lastError` from 2026-07-30. Compare `:1037` where the dry pass is wrapped.\n- **Remove the ZZTEST dummy from the state blob.** `mxf92ajJDtsZMHqJxAKv` is at main step 5. Live,\n `main-6` is an unprefixed email to Amir due 12 August and `main-7` is an SMS to `+10000000000`\n that will fail permanently on Kim's dashboard.\n- **Fix the false claim in the control panel.** `api.ts:338` tells Kim STOP takes effect within 15\n minutes. The interval is hourly. Say hourly.\n- **Decide and implement the email half.** There is no flag. If the decision is texting only, that is\n an edit to `MAIN_SEQUENCE` plus a test pinning which steps are live.\n- **Guard the no email case.** One tagged contact has no email address and nothing in the send path\n checks. A send to a contact with no email 4xxs, leaves state untouched, and retries every hour\n forever.\n\n---\n\n## WAVE TWO · BLOCKS THE MONEY FEATURE · after wave one\n\n### AGENT 4 — BUILD THE INGESTION LAYER THAT DOES NOT EXIST\n**This is the finding that changes the shape of the work.** `money-match.ts` is imported by its own\ntest and by nothing else. There is no call to `/payments/transactions` anywhere in `engine/`,\n`scripts/` or `build/`. Every figure on Kim's money page came from a process that is not in the\nrepository.\n\nSo this is a build, not a patch.\n\n- New module `engine/payments-source.ts`. It must be separate, because test MM-h asserts the string\n `fetch(` never appears in `money-match.ts` and that test is worth keeping.\n- Endpoint, and note it rejects `locationId`:\n `GET /payments/transactions?altId=BQHJ19uohldYe3eqA0bl&altType=location&limit=100&offset=`\n- Accept all five live source types: `calendar`, `invoice`, `funnel`, `payment_link`, `manual`.\n **An unrecognised type is kept and reported, never dropped.** A new type is a new way money\n arrives; dropping it silently is how revenue goes missing without an error.\n- **Filter on amount, not on source type.** 171 rows are $0 booking artifacts, all status succeeded.\n 10 rows are sub $1 card tests, all pending. Filtering `entitySourceType !== \"calendar\"` is the near\n miss: it leaves 13 zero rows standing and invents a payment collision that is not real. The gate is\n `status === \"succeeded\" && amount >= 1`. Correct total after filtering: **28 transactions,\n $17,564.00**, and not one dollar is lost.\n- The figure \"97 zero rows\" that has been circulating is stale. It is 171.\n\n### AGENT 5 — SUM, DO NOT OVERWRITE\n`money-match.ts:76` writes `value: payment.amount`. Two payments to one booking race and one loses.\n\nLive: **Laurie Rubnitz, $120 and $90, both resolving to opportunity `7yES6q2kajVTQIK6tEx3`.**\nCorrect value $210. The code produces $173,995 or $174,025 depending on which write lands last, and\n**neither equals the $174,115 promised on the page Kim is reading.**\n\nNote the direction: **summing preserves the total, so the page is right and the code is wrong.** The\npage already says the two are added together. The code has to catch up with the page.\n\n- Add `planWrites(matches)`: group AUTO matches by opportunity, sum, one write per opportunity,\n carrying the payment ids that made it up.\n- Leave `classify()` alone. It is per payment and Kim's rule is per payment. Grouping belongs to the\n caller.\n- Fix `summarise().valuedAfter.count`, which counts payments where it should count bookings.\n- Three tests: two payments to one booking become one write of the total; the count counts bookings;\n the write total always equals the AUTO total, so grouping moves money and never loses it.\n- **The bug self seals.** Once a wrong value is written the next run sees a non zero field and\n returns ALREADY_VALUED, so the lost money is unrecoverable without a manual audit. This must be\n right before the first write, not after.\n\n### AGENT 6 — SCOPE THE WRITE TO TWO STAGES, IN THE CODE\n`classify()` has no stage filter and takes whatever the caller hands it. A contact appears on up to\neight boards in this location and every card looks identical from inside the function.\n\nUnscoped, live: **$4,020 of $4,685, being 86 percent, lands on a card that is not a booking.** $500\nonto brad rentz's Survey Requested card while his real Customer card already carries $2,395 and would\ncorrectly have been left alone. $2,550 of Joni Clarke onto the review pipeline. $900 of Wendy DeShon\nonto a PupTalk card. The exception list goes from 0 to 10.\n\n- `VALUABLE_STAGES` as a frozen constant in the module: Customer\n `fd821b4e-bbe6-44de-b754-fa80e4823616` and Won and Paid `ae173310-f8b1-4399-acb7-ef1fc03d3697`.\n- Filter inside `classify()`, not in the caller. A caller that hands over every board is the normal\n mistake and the cost of it is money on a survey card.\n- **Companion change in the same commit:** the fixture at `tests/money-match.test.mjs:16` uses\n `stage: \"Customer\"`, a stage name, where live data carries a stage id. Adding the filter turns nine\n existing tests red immediately. Change the fixture to the id. **If somebody instead makes the\n filter match on the name, the filter becomes a no op against production and the defect ships behind\n a green suite.** Say so in the commit.\n- Confirm with Kim that Won and Paid is a real destination. It holds exactly one card, a test record,\n against 1,516 in Customer.\n\n---\n\n## WAVE THREE · BLOCKS NOTHING · run in parallel with everything\n\n### AGENT 7 — THE WEEKLY REPORT'S FALSE NUMBER\n`report.ts:298` counts Facebook leads off `c.source`, which is null on 78 percent of contacts and has\nnever once carried the string facebook. **The report tells Kim the CRM recorded 0 Facebook contacts in\na week its own attribution recorded 116.** It ships weekly and it is about the channel she spends\nmoney on.\n\n**The fix already exists in the repo and is not wired.** `report-logic.ts` has `channelBreakdown()`,\n`attributionCoverage()` and `prettyMedium()`. `dashboard.ts` has called them correctly since 4 August.\n`report.ts` imports none of them.\n\n- Read the first attribution entry at `report.ts:83`, the same way `dashboard.ts:105` does.\n- Extract `facebookLanded()` into `report-logic.ts` so a test can reach it. Today the count is\n computed inline inside a template literal, which is why no test caught it.\n- **Case insensitive regex.** `channelBreakdown` returns display labels like `Facebook`, not\n `facebook`. Porting the old regex verbatim reproduces \"0 Facebook contacts\" exactly, wearing a new\n hat.\n- **Drop `unsourced` from the reconciliation.** Its whole justification was an artifact of reading the\n blank column. Under attribution the unattributed population is 1 in 142, not 111. Adding it would\n be padding a number that no longer needs padding.\n- Test R13 already passes while proving `channelBreakdown` works on a function the report never calls.\n A green assertion on unwired code is indistinguishable from a green assertion on a working product.\n Fix that too.\n\n### AGENT 8 — THE LOST DEALS IN HER REVENUE FIGURE\nTwo related errors, both on numbers Kim reads.\n\n- **`wonOppsAll` stamps `status: \"won\"` onto every record it reads**, justified by a comment claiming\n every opportunity in the account is open. Live: 5,828 opportunities, **177 are lost**. Six lost\n deals sit inside the Customer and Won and Paid scope, so a lost deal reaching those stages is\n counted as a new customer.\n- **Her $166,235 includes $14,675 of lost deals.** Five of the 53 valued opportunities carry status\n lost: Holly Webb-Reese $3,295, Frank Villella $3,295, Emily Stroud $2,395, Kim Johnson $2,395, Jill\n Edwards $3,295. Both the before and the after figure on the money page carry it.\n- Decide with Amir whether lost deals belong in historical revenue. They probably do, since the money\n was taken. **But it has to be a decision, stated on the page, not an accident.**\n- Fix the two comments in `report.ts:107` and `dashboard.ts:146` that assert the opposite of the data.\n\n### AGENT 9 — THE DATES BUG, PROPERLY\nKim's item, promised as Monday's first job on 8 August, marked \"never reproduced\" for two days\nbecause nobody looked in the copy modules.\n\n**Nine hardcoded relative time strings, not four.** `worklog.ts:175, 193, 194, 212, 217, 283, 307,\n349` and `decisions.ts:215`. They say \"this evening\", \"this morning\", \"half past six this evening\",\n\"at 21:49 this evening\". The page tells her \"this evening\" every day forever.\n\n- Partly mitigated: `dashboard.ts:697` renders a real date beside each entry, so she sees \"6 August\"\n next to \"this evening\". That is why it reads as sloppy rather than wrong.\n- `worklog.ts:139` is the worst of them: bare clock times, \"at 8:20 and my reply at 8:27\", with no\n date anchor in the sentence at all.\n- Fix all nine. Add a lint test that fails on relative time words in copy modules, so it cannot come\n back.\n- **Also fix `facts.ts squareSentence()`**, which returns \"we could not read the payment records just\n now\" when the backlog is zero. The day her counter sale backlog is finally cleared, she will be told\n the records could not be read. Split the null case from the zero case.\n\n### AGENT 10 — THE TRACKING PAGE SHE ACTUALLY WANTS\nHer words: clear data, how much she spent, how much she got. Not a wall of detail.\n\nThis is the one agent that builds something new rather than fixing something broken, and it is the\none that makes the retainer look like what it is.\n\nOne page, her voice, connecting the three things that are currently in three places:\n- **What she spent.** Meta live per request. Google typed by hand and labeled as such until the\n developer token lands.\n- **What came in.** Contacts by real attribution, not the blank column. 116 from Facebook and\n Instagram last week, not 0.\n- **What it turned into.** Bookings, and revenue once the matcher runs.\n- **What the follow up system is doing.** Enrolled, sent, replied, deferred and why.\n- **What Square took**, tied to the same customers.\n\nRules for it: every number carries an \"as at\" and a source. No percentage anywhere. No dash anywhere.\nNothing on it that cannot be traced to a record. It should answer \"is my money working\" in the first\nten seconds and let her dig only if she wants to.\n\n**Prerequisite:** agents 4 to 7. This page is only honest once ingestion exists and the report reads\nthe right field.\n\n---\n\n## WHAT I WOULD DO WITH THE TEN\n\n| Wave | Agents | Gate |\n|---|---|---|\n| One | 1, 2, 3 | Nothing goes live until all three are green and re-verified live |\n| Two | 4, 5, 6 | No write to a `monetaryValue` field until all three are green |\n| Three | 7, 8, 9, 10 | Runs alongside. 7 before Friday's report. 10 last, it depends on 4 to 7 |\n\n**Realistic sequencing.** Wave one is the smaller job and it unblocks the thing Kim has already\napproved. Wave two is a genuine build, because the ingestion layer has to be written from nothing.\nWave three is mostly small and mostly independent.\n\n**The one thing I would not compress:** agent 1 gets its own verification pass afterwards, by a\ndifferent agent that did not write the fix. An inverted boolean survived 394 assertions and 203\nnegative controls. The fix for it deserves an adversary.\n\n\n",[590],"24d8b13e-9d63-4d96-8424-3823e4c03ab8","SOURCE-BUNDLE.part35.txt","8a7ac07e-97ea-11f1-a03f-1607ee4eb77e",1084,["D",1786801893005],"THE DOGS SPOT — SOURCE BUNDLE (part 35 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (3 of 116 files)\n reports/money-and-marketing.html 29010 bytes d988605b337a\n BOARD-10-AUG.md 16014 bytes 76cfa385618d\n BOARD-11-AUG.md 15495 bytes 4ffffb513856\n\n================================================================================================\n=====FILE reports/money-and-marketing.html =====\n\n\nThe Dogs Spot, what you spent and what came back\n\n
\n\n
What you spent, and what came back
\n
Every figure here was read from your own systems on Monday 10 August 2026, between 3:06 pm and 3:16 pm your time. Each number says which days it covers and where it was read. Nothing is rounded, nothing is estimated, and nothing is carried over from an earlier report.
\n\n
\n
\n
\n
$676.94
\n
on Facebook and Instagram over the seven days 3 August to 9 August. Read live from the ad platform.
\n
\n
\n
168 people
\n
arrived in your CRM in those same seven days. 139 of them came through Facebook or Instagram.
\n
\n
\n
$4.87
\n
for each of those 139 people, to the nearest cent. That is $676.94 divided by 139.
\n
\n
\n
Square money that has completed and reached your CRM comes to $17,564.00 across 36 payment records, covering 8 December 2025 to 2 August 2026. Your Google spend is typed by hand: the last figure typed was $164.00 for 31 July to 6 August. Both are set out below with everything behind them.
\n
\n\n
1. What you spent, and what it brought
\n\n
\n\n\n\n\n\n\n
Where the money went Amount How this page gets it
Facebook and Instagram3 August to 9 August 2026 $676.94 Read straight from the ad platform every time your card page loads. Read three times today, at 3:06 pm, 3:15 pm and 3:16 pm, and it said the same figure each time.
Google31 July to 6 August 2026 $164.00 Typed by hand. This is the figure in the message sent to you on 7 August. Google puts its own numbers behind a developer token, which Google quotes at about five business days. Google joins this page the same way Facebook has once that token lands, and until then every Google figure you see anywhere is one a person typed.
\n
Facebook separately reports 162 conversations started over those same seven days. That is the ad platform counting message threads it opened. Your CRM counts people who landed in it, which is the 168 above. Two counters doing two jobs, so they sit side by side rather than adding up.
\n
\n\n
\n
What $676.94 sat alongside, in those same seven days.
\n\n\n\n\n\n\n\n\n\n\n
In the seven days 3 August to 9 August Count
New people in your CRM 168
Of those, arrived through Facebook or Instagram 139
New cards on your Initial Lead Pipeline 166
Pup Talk appointments on your calendar 20
Of those, showed up 15
Cards that moved into your Customer column 2
\n
These are everything that happened in those seven days, whatever brought it. Tying each individual booking back to the ad that produced it arrives together with the booking amount, which is the one field covered in the next card.
\n
One number you may compare against your card page. That page divides the same $676.94 across every arrival on a window that moves with the clock, and reads $4.34 each. This page divides it across the 139 people who arrived through Facebook or Instagram on seven fixed calendar days, and reads $4.87. Same money, two questions, and both are right.
\n
\n\n
What your Square money is doing
\n\n
\n
Completed
$17,564.00
36 payment records. Real money, landed.
\n
Still pending
$3,711.55
28 payment records, the newest of them from 13 February.
\n
Failed
$3,372.00
6 payment records. Someone tried to pay you and the card did not go through.
\n
\n
\n
\n \n \n \n
\n
\n Completed, $17,564.00\n Pending, $3,711.55\n Failed, $3,372.00\n
\n
70 Square payment records in total, $24,647.55 across all three states, out of 233 payment records of every kind in your CRM. Every one of the 70 carries a customer id, so the matching itself works. The newest one is a $67.00 card that failed at 9:51 pm on 9 August your time.
\n
The completed money runs from 8 December 2025 to 2 August 2026. It is the money that arrived through an invoice, your order form or a payment link, so your CRM holds a record of it. Money taken over the counter in Square is a separate list and it is the next card.
\n
\n\n
\n
33 counter sales worth $22,651.99 are recorded and not linked to a name.
\n
\n
Carry a trail
4
$2,829.99. An email, a phone number or a Square customer id, so effort would recover these.
\n
Arrived bare
29
$19,822.00. No name, email or phone attached, so these stay as they are.
\n
\n
4 plus 29 is 33, and $2,829.99 plus $19,822.00 is $22,651.99. Read today from the Square bridge journal, 760 rows, counting each payment once rather than once per retry.
\n
This is a different list from the $17,564.00 above, and both are right. The Square money above is what your CRM holds a payment record for. This one is what the till has taken, including counter sales that never became a CRM payment record. The till list sees more, so it is the bigger number. Taking a name at the counter is what changes it, and it changes it for future sales.
\n
\n\n
What your bookings carry today
\n\n
\n
Booking records
1,517
1,516 in Customer and 1 in Won and Paid. That single one is a test record made on 6 November 2025 carrying no value.
\n
Carrying a price
53
The other 1,464 have an empty amount box.
\n
Their total
$166,235.00
The most recently touched of them moved on 30 June 2026.
\n
\n
\n\n\n\n\n\n\n
Program price on the record Records Value
$3,295.00 39 $128,505.00
$2,395.00 11 $26,345.00
$3,795.00 3 $11,385.00
All valued records 53 $166,235.00
\n
Those 53 are the proof the field works. Somebody filled it in on or before 30 June, and the bookings since then carry an empty box. Reports add money up from that box, which is why the money you have plainly taken and the money your reports can add up are two different sizes today.
\n
\n\n
\n
What happens the moment the amount goes onto the booking. Your rule, run against every completed Square payment you have.
\n\n\n\n\n\n\n\n\n\n
What happens to it Payments Value
Places itself. One booking open, so the money goes straight on it. 15 $7,880.00
Waits for one of your team to pick. More than one booking open. 0 $0.00
Booking already carries a value, so it is left exactly as it is. 15 $8,237.00
Stays where it is, and it is two separate causes. 3 worth $480.00 carry no name on the record. 3 worth $967.00 name a real customer whose booking sits on another board. 6 $1,447.00
All completed payments 36 $17,564.00
\n
Nobody on your team is asked to do anything. Counting the bookings that matter, the ones in your Customer and Won and Paid columns, not one customer sits on more than one open booking today, so the second half of your rule stays quiet.
\n
Money recorded against bookings goes from $166,235.00 to $174,115.00 the moment it runs. Two of those 15 payments belong to one customer and one booking, $120.00 and $90.00, so they are added together into $210.00 and the 15 payments fill 13 bookings.
\n
\n\n
2. Where your people came from
\n\n
\n
The 168 people who arrived between 3 August and 9 August, by the arrival record your CRM writes on each one.
\n
Facebook
130
Instagram
9
Phone calls
21
Your website form
3
A message thread
2
A calendar booking
1
Added by hand
1
Arrival record empty
1
\n
\n FacebookInstagramEverywhere else\n
\n
130 plus 9 plus the 29 from everywhere else is 168. The 21 phone calls arrive with the arrival record set to \"other\", and all 21 of them are logged in your CRM as phone calls, so they are your callers rather than a mystery.
\n
\n\n
\n
Why this list is different from the one your CRM shows you on screen.
\n
Your CRM has a column called Source, and it is the one most reports read. It is empty on 4,137 of your 5,660 contact records, and across all 5,660 of them it says Facebook 0 times. In the seven days above it was empty for 133 of the 168 people and said Facebook 0 times.
\n
This page reads a different field: the arrival record your CRM writes on every contact, taking the entry marked as their first touch. In those same seven days that field says Facebook 130 times and Instagram 9 times. That is the difference between a report telling you nothing came from Facebook and a report telling you 139 people did.
\n
\n\n
\n
Eight weeks, oldest on the left. The last bar is 3 August to 9 August.
\n\n
\n FacebookInstagramEverywhere else\n
\n
Read from all 5,660 of your contact records today, page by page, and bucketed into seven day weeks in your own time zone. Every bar is the same eight week census, so the shape is comparable across the whole chart.
\n
\n\n
3. What happened to those people
\n\n
\n
Your Initial Lead Pipeline, all 5,535 cards, counted today.
\n
New Lead
3,598
Lead Nurture
14
Free Training Day
3
Pup Talk
229
Canceled Pup Talk or Training Day
27
No Sale Nurture
136
Disqualified
10
No Show
1
Onboarding
0
Customer
1,516
Won and Paid
1
\n
Those eleven counts add to 5,535. Across every board in your CRM the total is 5,832 cards.
\n
\n\n
\n
The 166 cards created between 3 August and 9 August, and where each one sits today.
\n
New Lead
150
Pup Talk
7
Lead Nurture
4
Canceled Pup Talk or Training Day
3
Customer
2
\n
Your Pup Talk calendar held 20 appointments across those same seven days: 15 showed up, 3 were canceled and 2 did not arrive.
\n
\n\n
\n
19 bookings came into your Customer column since 10 July.
\n
13 of those moved across from an earlier step, and 6 were created and landed in Customer on the same day. Counted from the Customer column only, all 1,516 records read page by page, and re derived a second time from a separate pull that returned the same 19.
\n
Of your 1,517 booking records, 53 carry a price and 1,464 have an empty amount box. Filling that box is the single step that turns this section into dollars.
\n
\n\n
4. What your follow up system is doing
\n\n
\n
It is in practice mode, and it has messaged real customers zero times.
\n
Every message it has produced carries a practice flag and went to one practice record that sits on Amir's own email address. That is what the system has been built to do until you and Amir switch it on together, and it is doing exactly that.
\n\n\n\n\n\n\n\n\n\n
Read from the system itself at 3:12 pm today Reading
Practice mode On
Messages to real customers, all time 0
Records it is tracking 1
Practice messages produced 5
Version, and its last pass 1.7.1, 3:11 pm
\n
The 5 practice messages went out on 31 July twice, 2 August, 5 August by text and 8 August by email. The system runs once an hour and its last pass was one minute before this page was built.
\n
2 of your 5,660 contact records are marked as a puppy inquiry today. Those are the people the messages pick up on the day it goes live. Counted two ways that agree: a walk through all 5,660 records, and your CRM's own filter for that mark.
\n
\n\n
Your review pipeline, on one page for the first time
\n\n
\n
179 review cards, and 138 of them are still waiting for an answer.
\n
Survey Requested
138
Survey 1 to 6
2
Survey 7 to 9
1
Survey 10
38
5 Star Review
0
4 Star Review
0
Bad Review DND
0
\n
Those seven counts add to 179. Your review workflow sends the one to ten question and then waits for a reply with no time limit set, so a card stays in Survey Requested for as long as it takes. The oldest one there has been waiting since 14 March 2026 and the newest arrived on 7 August 2026.
\n
41 people did answer. 38 gave you a 10 and were sent your Google review link, 2 scored between 1 and 6, and 1 scored between 7 and 9. 38 plus 2 plus 1 is 41.
\n
The last step, moving a card into 5 Star, 4 Star or Bad Review once you know what they wrote, is done by hand. All three of those columns hold zero today, so the 38 people who were sent the link have their score on file and their review still to be recorded.
\n
\n\n
\nWhere every number on this page comes from, and when it was read.
\nAd spend, $676.94 and 162 conversations, 3 August to 9 August. Your own card page, which reads the ad platform live on each load. Read at 3:06 pm, 3:15 pm and 3:16 pm today, identical all three times.
\nGoogle spend, $164.00, 31 July to 6 August. Typed by hand into the message sent to you on 7 August. Not a tracked reading.
\nPeople and where they came from, 5,660 contact records. Your CRM's contact list, walked page by page today, reading the arrival entry marked as each person's first touch. Weeks are bucketed in your own time zone.
\nPipelines and bookings, 5,832 cards across every board. Your CRM's opportunity search, walked page by page today, and the Customer column pulled a second time on its own to check the 19.
\nSquare money, 70 Square records out of 233 payment records. Your CRM's own payment list, read in full today.
\nCounter sales, 33 payments worth $22,651.99. The Square bridge journal, 760 rows read today, each payment counted once.
\nPup Talk appointments, 20 across 3 August to 9 August. Your Pup Talk calendar, read today for those seven days.
\nThe follow up system. The system's own stored state, read at 3:12 pm today.
\nNothing on this page was rounded, estimated, or carried over from an earlier report. Where two of your systems count the same thing differently, both counts are shown and the difference is named.\n
\n\n
\n\n\n\n=====FILE BOARD-10-AUG.md =====\n# THE BOARD — Monday 10 August 2026, after Kim's four messages\n\nEvery percentage is internal. Never quote one to her. Verified live today unless marked otherwise.\n[V] verified live by me today · [C] claimed, unproven · [U] unknown, with what settles it\n\n---\n\n## WHAT CHANGED TODAY, IN ORDER OF IMPORTANCE\n\n1. **NURTURE IS APPROVED.** \"You have my go-ahead to switch it on. I don't need to be there while you\n do it.\" Asked repeatedly since late July, answered today. This was the single biggest blocker on\n the account and it is gone.\n2. **Staff do NOT move cards into Customer. It is already automated.** Her correction. This changes\n what we tell her about manual work, and it removes a question the money doc was going to raise.\n3. **She wants the Square piece written, not spoken.** The call became a document, which is better\n for us: it is checkable, it is a reference, and it does not depend on a call going well.\n4. **She confirmed the matching rule in her own words**, unchanged from 9 Aug. One open, auto.\n Multiple, exception list. Anonymous, report separately, never guess.\n5. **Two new workstreams appeared**: reusable front desk payment links, and a full set of tracking\n questions she now expects real answers to.\n6. **Milton confirmed his architecture in writing**: his app creates the appointments, then pushes\n them into GoHighLevel via API as individual appointments, and those then feed the workflows.\n That is the first written description of that integration we have.\n\n---\n\n## 1. NURTURE · 92% built, 0% live · UNBLOCKED TODAY\n\n| Piece | % | State |\n|---|---|---|\n| The 41 messages, 6 tracks | 100 [V] | Live on the val, byte identical to local, 16 checks pin her wording |\n| Test coverage | 100 [V] | 18 suites, 394 assertions, plus 203 negative controls that each prove a real test can fail |\n| Texting half | 100 [V] | Verified end to end against the sanctioned dummy |\n| Email half | 45 [V] | Sends from a shared LeadConnector address. `defaultEmailService` is empty, so no dedicated domain exists |\n| Her approval | 100 [V] | Given today, in writing, and she does not want to be present |\n| **Actually live** | **0** [V] | `testMode:true` right now |\n\n**Everything that has to be true before the flag flips.** Do not skip any of these.\n\n- [ ] **Confirm the freeze does not cover step c.** Switching off her old \"1. Wait 1 Day: Initial\n Nurture - Puppy\" workflow is a workflow change, and the Kristian freeze forbids those. She has\n approved the go live but has NOT been asked about the freeze specifically. She has already said\n that workflow has never been used, which is the argument. **Ask in the same message.**\n- [ ] **Settle what applies the `nurture - puppy` tag.** [U] If it is a workflow, it is inside the\n freeze too. Today exactly 1 contact carries it, a real person, not the dummy.\n- [ ] **Check `TAG_SOURCE_SIGNAL` is unset** in the val environment. It overrides the tag entirely.\n- [ ] **Check `SEND_WINDOW_START_HOUR`, `SEND_WINDOW_END_HOUR`, `SMS_SUNDAY_OK`.** They decide\n whether anything goes out at the hour you flip it.\n- [ ] **Know the surge hold.** `ENROLL_SURGE_THRESHOLD` defaults to 25. If turning her tagging on\n back fills more than 25 contacts in one run, the engine enrols NOBODY and logs\n `ENROLLMENT SURGE HELD`. She takes ~160 inquiries a week, so a back fill is likely. Grep the\n run log for that string before assuming anything else went wrong.\n- [ ] **Expect `enrolled:1`, and treat `enrolled:0` as a FAILURE.** Every zero reading so far was the\n test dummy, because in practice mode the engine never looks at the real tag at all.\n- [ ] **Ignore any send logged against ZZTEST PuppyPath-Dummy.** It stays in state and fires anyway.\n- [ ] **Rollback is four steps, and the first is the only immediate stop.** Kill switch at\n `api?k=&stop=1`, clear with `&go=1`. The interval is hourly, so `TEST_MODE` alone leaves\n up to an hour of live sending. Then TEST_MODE true, then her old workflow back on, then tagging off.\n- [ ] **The team email to info@thedogsspotga.com**, which she asked for explicitly. Draft it before\n go live, not after.\n\n---\n\n## 2. SQUARE MONEY INTO REPORTING · 75% · HER TOP ASK\n\n| Piece | % | State |\n|---|---|---|\n| Bridge reading Square into the CRM | 100 [V] | Live since 13 July, writes a note on the contact |\n| Matcher logic, her rule | 100 [V] | Built 9 Aug, 14 tests, structurally cannot write |\n| Written explanation for her | 100 [V] | Delivered today, this session |\n| **The double payment bug** | **0** | `money-match.ts:76` writes rather than adds. 15 payments land on 13 bookings. Laurie Rubnitz $120 and $90 hit the same card. **Fix before anything goes live.** |\n| Stage scoping written into the code | 0 | `classify()` never filters by stage. Scoped to Customer plus Won and Paid it reproduces the page exactly. Scoped to every board, money lands on review pipeline cards and the exception list goes from 0 to 18. **This must be in the code, not in someone's head.** |\n| Kristian's answer on whether his app writes values | 0 [U] | Nobody has asked him. Amir's email to send |\n| Switched live | 0 | Needs the bug fixed, the scope written in, Kristian's answer, and Amir lifting read only |\n\n**Live figures, re derived today:** 36 completed payments $17,564.00 · 15 place themselves $7,880 ·\n0 exceptions · 15 already valued $8,237 · 6 unplaceable $1,447 · bookings go $166,235 to $174,115.\n\n**The $1,447 splits two ways and the difference matters:** about $480 across three payments has no\nname at all, and about $967 across three names a real customer who has no card in the Customer\ncolumn, including $900 from Wendy DeShon. Do not describe the whole $1,447 as nameless. She can\ncheck it in thirty seconds.\n\n**Corrected unmatched counter sales, which she asked for by name:** 33 worth $22,651.99. Was\noverstated as 42 worth $33,535.99, by exactly $10,884.00.\n\n---\n\n## 3. TRACKING AND ATTRIBUTION · she asked five questions and four have real answers\n\n| Piece | % | State |\n|---|---|---|\n| Facebook ad tracking | 90 [V] | Live. Spend read per request, no cache. `ads_read` granted 9 Aug |\n| Facebook to CRM attribution | 85 [V] | Better than we thought. See below |\n| CRM back to Facebook, purchases | 60 [V] | **It is live and Meta accepts 100% of it.** But only 18% of revenue reaches it |\n| Google ad tracking | 20 [V] | `googleWeek()` returns null or throws, result discarded. Every Google figure ever sent was typed by hand |\n| Retargeting | 0 | Not started. Volume clears the bar. See below |\n\n**Q: the ~30 Facebook contacts with no ad ID.** Answer is good news and it is not a leak.\nAcross all 5,656 contacts: **0 records marked \"Paid Social\" are missing an ad ID, and 0 records\nmarked \"Social media\" have one.** The correlation is perfect at n=2,615 paid and 662 organic. The ones\nwithout an ad ID are people who messaged the page themselves rather than clicking an ad. There is no\nad ID because there was no ad click. Click to Message ad attribution is running at **506 of 506 over\n30 days**. Real number is 22 in the last 7 days and 145 in the last 30, not 30.\n**One real weakness:** Facebook retains the ad ID on 79% of contacts, Instagram on 40%. Small sample,\nworth a 90 day recheck.\n**Two concrete improvements:** set a custom `ref` payload per Click to Message ad in Ads Manager so we\nissue our own campaign token that survives when Meta's native pass through fails, and capture\n`fbclid` on the website form path, where only 15 of 5,656 records carry one today.\n\n**Q: how do we verify Facebook is receiving what we send back.** It is dataset `3838731049764356`.\n22 Purchase events sent 14 July to 8 August, **Meta accepted every one**, zero errors, $11,797\ndelivered. She checks it herself in Events Manager, Data Sources, that dataset, Overview tab, where\nthe Purchase row carries a Server badge. Event Match Quality will read 4 to 6 out of 10 because we\nsend only hashed email and phone. **The real finding: only 19 of 108 real payments fire an event,\nbecause unmatched payments never reach that code path. 60 of the 89 unmatched already carry an email\nor a phone, which is all Meta needs.** Fixing that takes purchase value delivered to Facebook from\n$11,797 to roughly $73,667.\n\n**Q: Google attribution timeline.** Needs a Google Ads developer token, which Google itself quotes at\nabout five business days. Nobody has applied. **Until somebody applies, any date given to her is a\nguess.** Recommend telling her the Google half stays manual for now and giving her a date only once\nthe application is in.\n\n**Q: retargeting.** Volume clears the bar, but not the way you would expect. 55% of her contacts have\nneither an email nor a phone, because Messenger is now the dominant channel and it hands over a\nthread, not a contact card. So the customer list route is weaker than it looks: 1,240 reachable\ncustomers, roughly 620 to 870 matched. **Start instead with a Meta Engagement Custom Audience,\npeople who messaged the page, 365 day window.** It needs no identifiers at all, Meta builds it from\nits own interaction log, match rate is effectively 100%, and the pool is at least 3,225 people. It is\nalso the only way to reach the 1,240 recent Facebook leads who never converted and have no email or\nphone. Second audience the same day: the customer list, used as a suppression list first.\n\n**A live bug found while answering this, and it is on a page she reads.** `report.ts:298` counts\nFacebook leads off the contact `source` field, which is null on about 92% of contacts. The weekly\nreport therefore says the CRM recorded 0 Facebook contacts while attribution shows 131 in the same\nweek. Same wrong field class of error as the one already corrected once. **Fix before Friday.**\n\n---\n\n## 4. PAYMENTS, DEPOSITS AND THE FRONT DESK · new today\n\n**The Wix answer she asked for, settled.** The processor is **Square, through GoHighLevel, not\nthrough Wix**, merchant account `7KF50NPQP8WPT`. The `/payments` page on her site titled \"Pay\nBootcamp Deposit\" is a lead capture form whose button says Pay Now and **takes no money at all**.\nEvery $500 deposit ever collected was a GoHighLevel invoice paid by card.\n\n**A holiday deposit form already exists on her site**, at `/holiday-boarding-booking-form`, live and\nindexable, with a real Wix payment field set to a $50 minimum and a Pay Deposit button. It is a\nseparate page from the boarding form, so it does not touch Milton's iframe.\n**But do not use it.** A Wix collected deposit settles into Wix's own payments ledger and produces no\nrecord in the CRM at all. Across all 233 CRM transactions there is no Wix source and no Wix to CRM\nbridge. It would be invisible to the matcher and to revenue reporting. **Her fallback is the right\nanswer, and for a better reason than \"it cannot be done\".**\n\n| Piece | % | State |\n|---|---|---|\n| Which processor, answered | 100 [V] | Square via GoHighLevel |\n| Can Wix collect the deposit | 100 [V] | Technically yes, and it should not, because it splits the ledger |\n| Holiday deposit by payment link after booking | 0 | The agreed route. Needs a workflow that fires on the booking form and sends the link |\n| Reusable front desk payment links | 0 | ~17 links. Dashboard only, there is no API for creating them |\n| **Product prices in the CRM are stale** | 0 | **Basic Bootcamp reads $2,300 not $2,395. Community reads $3,300 not $3,295. Leash Free reads $3,600 not $3,795. Fix these first or the front desk undercharges on every link they send.** |\n\n**Payment links will feed the same reporting, and this is proven, not assumed.** Two payment link\ntransactions already exist in her CRM from a January test. They carry a `contactId`, the Square\nprovider and the same connected account as every invoice. **All 233 transactions carry a contactId,\n100%, no exceptions.** The matcher needs one line widened to accept the `payment_link` source type\nand nothing else. Each link also carries its own id, which tells reporting which program was bought\nwithout parsing line items.\n\n**Two things to filter that nobody has noticed:** 97 of 233 transactions are $0 calendar booking\nartifacts and will pollute revenue, and there are sub $1 test rows.\n\n**Evidence for how much this will help her:** 26 of her 57 invoices are sitting in draft. Nearly half\nof everything built at the counter never gets sent.\n\n---\n\n## 5. MILTON, KRISTIAN AND OCCUPANCY\n\n| Piece | % | State |\n|---|---|---|\n| Milton's app stays until Kristian's numbers match | 100 [V] | She agreed today, and adopted the full week standard |\n| Kristian's occupancy correctness | 0 [V] | His dashboard said 171 dogs in a 50 kennel building. Milton's said 24 |\n| Kristian's QA and handover | 0 [C] | His list omits Clerk, environment variables, Stripe and DNS |\n| Milton's architecture, understood | 100 [V] | In writing today: his app creates appointments, pushes to the CRM via API as individual appointments, those feed the workflows |\n\n**What Milton's message actually tells us, and it matters for the matcher:** appointments arriving in\nthe CRM from his app are individual appointment records that then enter workflows. That is a second\nsystem writing into the same CRM on a schedule we do not control. Worth one line in the go live\nrunbook.\n\n---\n\n## 6. REVIEW WORKFLOWS · her PDF answers it, and it opens three problems\n\nThe document she sent confirms two workflows, not duplicates: one scores 1 to 10 by hand, the newer\none has ChatGPT classify the reply into five categories and raises a task when somebody is unhappy or\nasks a question. They fire on different tags.\n\n**Live counts confirm nobody has ever been asked twice:** 118 contacts carry `survey`, 2 carry\n`survey2`, and **0 carry both**.\n\nThree problems her own document exposes and does not flag:\n1. **138 of 178 cards are stuck in Survey Requested forever.** Her document says the wait state has no\n timeout configured, so anyone who never replies sits there permanently.\n2. **The last step is manual and has never once been done.** 5 Star, 4 Star and Bad Review all hold\n zero, so 37 people were sent a Google review link and there is no record of who left one.\n3. **The older workflow, which 118 people went through, has no escalation.** An unhappy answer gets an\n automatic message and nobody is told. Only the newer one raises a task.\n\n---\n\n## 7. STILL OWED FROM BEFORE TODAY\n\n| Item | % | Blocker |\n|---|---|---|\n| Four DNS lines for her sending domain | 0 | Needs Amir's GoHighLevel login. `defaultEmailService` is empty so no domain exists yet |\n| Wix processor answer | 100 | **Answered today, above. Send it** |\n| Corrected unmatched Square figure | 100 | **33 and $22,651.99. Answered, send it** |\n| The dates bug | 30 | **Reproduced today.** Four hardcoded strings: `worklog.ts:283`, `:139`, `:349`, `decisions.ts:213`. They say \"this evening\" forever |\n| Key rotation | 10 | Oldest item, open since 31 July. Three secrets in scope, not one |\n| Overlap review, five sequences against two auto responders | 0 | Nothing blocking |\n| Pups Club self unsubscribe | 0 | Due Thursday. Nothing blocking |\n| Two calendars, tag cleanup, Free Training Day rebuild | 0 | Freeze. **She has still not been told these are blocked** |\n\n---\n\n## THE ORDER I WOULD WORK IT\n\n1. **Send her the Square document plus the four short answers.** All of it exists now.\n2. **Fix the matcher's double payment bug and write the stage scope into the code.** Half a day, and\n everything downstream is wrong without it.\n3. **Fix `report.ts:298`** before Friday's report goes out saying 0 Facebook contacts again.\n4. **Ask her the one freeze question**, then go live on nurture and send the team email.\n5. **Email Kristian.** One sentence, cheapest unblock on the board, still nobody has sent it.\n6. **Correct the three product prices**, then build the payment links.\n7. **The DNS lines**, which need a login and nothing else.\n8. **Google developer token application**, so the timeline she asked for stops being a guess.\n\n\n\n=====FILE BOARD-11-AUG.md =====\n# THE BOARD — Tuesday 11 August 2026\nEverything outstanding for Kim Hicks, The Dog's Spot. Percentages are internal, never quote one to her.\nVerified live today unless marked otherwise. [V] verified by me · [C] claimed, unproven · [U] unknown\n\n---\n\n## WHERE THIS STANDS IN ONE PARAGRAPH\n\n**[Corrected 14 Aug: the first sentence read \"built, corrected and one command from live\". The\ncommand was run on the evening of 11 August. The texting half is live and has messaged two real\npeople; the email half is still blocked on the four domain lines; one path of six is built.]**\n\nThe nurture system is built, corrected and one command from live. The money side went from\n\"we cannot show you revenue\" to a named list of every unmatched payment. The tracking side\nhad a live falsehood on the weekly report and no longer does. What is left is mostly\nassembly rather than discovery, with two real exceptions: five months of missing revenue\nrecords that nobody has explained, and Kristian, who is still an open question nobody has\nasked him.\n\n---\n\n## 1. NURTURE · puppy path live since 11 Aug · 1 of 6 paths built · email half blocked\n\n> **Corrected 14 Aug 2026.** This heading read `96% built · 0% live · ONE COMMAND AWAY`. Three\n> problems with that, and the first two are the reason it is gone rather than edited to `100%`:\n>\n> 1. **`96` was reproducible from nothing.** It was prose. No code computes it. The seven rows\n> below score 100, 100, 100, 100, 100, 45, 0, which sum to 545: mean of all seven is **77.9**,\n> mean of the six build rows excluding \"Actually live\" is **90.8**. Neither is 96, and a\n> blended percentage over rows measuring different things was never a number anyway.\n> 2. **The row scored 100 counts the wrong six.** \"41 messages, 6 tracks\" is right about 41 and\n> wrong about what six means. The 41 are `MAIN_SEQUENCE` 8 + `BRANCH_A` 2 + `BRANCH_B` 2 +\n> `SLOW_WEEKLY` 4 + `SLOW_FORTNIGHTLY` 13 + `SLOW_MONTHLY_BANK` 12 = 41, counted from the built\n> modules on 14 Aug. Those are six exported arrays **inside the single puppy path**. The six\n> PATHS Kim was quoted are in `engine/paths.ts:98-190`, and five of them carry `steps: []`.\n> One path of six is built. `paths.ts:267` has been saying so honestly all along: \"Registering\n> the rest is NOT a copy drop... Days of work each, not an afternoon.\"\n> 3. **`0% live` and `ONE COMMAND AWAY` stopped being true on the evening of 11 August**, hours\n> after this file was written. `testMode:false`, engine v1.7.1, two real contacts enrolled at\n> 2026-08-11T21:25:50Z, both messaged. [V] read from the live engine 14 Aug.\n>\n> Line 2 of this file still holds: percentages are internal, never quote one to her. The heading\n> above now states three things that are each separately checkable instead of one that is not.\n\n**Kim has given permission.** In writing, 11 Aug: switch off the old workflow despite the\nfreeze, correct the Do Not Disturb issue, and switch it on once verified. She does not want\nto be present. **She gave it, it was done that evening, and it is running.**\n\n| Piece | % | State |\n|---|---|---|\n| 41 messages in the puppy path | 100 [V] | Live on the val, byte identical, 16 checks pin her wording. 8 + 2 + 2 + 4 + 13 + 12 = 41, counted 14 Aug |\n| The other 5 of the 6 paths | 0 [V] | `engine/paths.ts:98-190`, all five `steps: []`. Days of work each, not a copy drop |\n| Consent reading | 100 [V] | **Was inverted, fixed and deployed today.** 3 real tests replaced a fake one |\n| Test coverage | 100 [V] | 19 suites, 411 assertions, plus 203 negative controls |\n| Go live hardening | 100 [V] | Appointment index wrapped, false timing claims corrected |\n| Texting half | 100 [V] | Verified end to end |\n| Email half | 45 [V] | Shared sending address. No dedicated domain exists. Still the blocker |\n| **Actually live** | **texting only** [V] 14 Aug | `testMode:false`, engine v1.7.1, kill switch off, checks unbroken |\n\n### The go live checklist. Done 11 Aug, kept here as the record of what was done.\n\n- [x] **Delete the ZZTEST dummy from the state blob** (`mxf92ajJDtsZMHqJxAKv`). Gone: the state\n now holds two records and neither is it. [V] 14 Aug\n- [x] **Flip `TEST_MODE` to the literal `false`.** The engine reports `testMode:false`. [V] 14 Aug\n- [ ] **Switch off \"1. Wait 1 Day: Initial Nurture - Puppy\"**, id\n `0cf5fab6-d3ec-4206-8d46-a700dd0469b1`, published. Kim approved this specifically.\n **[U] not verified on 14 Aug.** Nobody has re-read the workflow list since go-live, so\n whether the old one is actually off is unknown, and it is the one thing on this list that\n could double-message a customer. Read it before assuming.\n- [x] **Only between 13:00Z and 22:59Z, and not on a Sunday.** Went live 2026-08-11T21:25Z, a\n Tuesday. [V]\n- [x] **Expect enrolled to be small.** Two enrolled, both at 21:25:50Z on 11 Aug. [V] 14 Aug\n- [ ] **One of the three had no email address.** Whether that person is one of the two enrolled,\n and what she received, has not been checked since. **[U]**\n- [ ] **Grep the run log for `ENROLLMENT SURGE HELD`.** Not seen in the runs read on 14 Aug, but\n only the most recent 40 were read, so this is \"not seen\", not \"did not happen\".\n- [x] **Rollback is four steps and the first is the only immediate stop.** Kill switch at\n `api?k=&stop=1`, clear with `&go=1`. `killed:false` right now. [V] 14 Aug\n- [ ] **The team email to info@thedogsspotga.com**, same day. Kim asked for this explicitly.\n **[U] no evidence it was sent.**\n\n**Where it actually stands, 14 Aug [V] unless marked:** the texting half is live and has been\nsince the evening of 11 Aug. Two people enrolled, both had the first two messages, one has since\nreached Customer. The email half cannot start until the four domain lines go in, which is Kim's\none outstanding item. One path of six is built. **Nothing here is 30 days of clean running yet:\nit is three days**, and the retainer conversation was always priced against the former.\n\n---\n\n## 2. THE MONEY SIDE · 85% · the biggest change this week\n\n| Piece | % | State |\n|---|---|---|\n| Bridge reading Square into the CRM | 100 [V] | Live since 13 July |\n| The matcher, Kim's rule | 100 [V] | Scoped to two stages, sums instead of overwriting, 20 tests |\n| Ingestion layer | 100 [V] | **Did not exist until today.** `payments-source.ts`, 8 tests |\n| The 33 identified | 100 [V] | 32 of 33 named, $22,651.99, list built |\n| Written explanation for Kim | 100 [V] | Sent |\n| Writing the 33 back | 0 | Blocked, see below |\n| Switched live | 0 | Needs Kristian's answer and Amir lifting read only |\n\n### What still has to happen, in order\n\n1. **The write back is not a button.** Every one of the 33 already owns an opportunity and\n her CRM allows one per contact, so the bridge deliberately will not overwrite her figure.\n Running it as is moves her revenue by nothing and fires 33 Facebook purchase events dated\n today. **Needs: CAPI suppressed for the replay, Caroline Riner handled by hand, and a\n dry run shown to Kim first.** Promised to her.\n2. **The weekly exception report.** Promised in writing: a short list of any Square sale that\n did not reach a customer record. Nothing built yet.\n3. **Two holes the fix does not close** [V]: a Square customer record with no phone or email,\n which is what happened to the $34.99 on 1 August, and a phone in Square that differs from\n the phone in the CRM, which is Caroline Riner.\n4. **Kristian's answer** on whether his app writes opportunity values. Still nobody has asked.\n\n### THE FIVE MONTH GAP. Largest open item on the whole board.\n\nBetween 1 March and 31 July her CRM recorded **127 transactions and one dollar amount, $67**\n[V]. Square took $19,822 in one fortnight of that window. The Square terminal last appears in\nher CRM on **19 February**.\n\nNobody knows where that money was recorded. It predates everything we built. **[U]** and it\nis the single most valuable question on this account, because every revenue figure she has\npulled for March to July is wrong.\n\n---\n\n## 3. TRACKING AND ATTRIBUTION · 70%\n\n| Piece | % | State |\n|---|---|---|\n| Facebook ad tracking | 90 [V] | Live, spend read per request |\n| Facebook to CRM attribution | 90 [V] | 506 of 506 on click to message ads |\n| The weekly report | 85 [V] | **Was telling her 0 Facebook contacts in a week she had 116. Fixed and deployed today**, now reads 151 of 175 |\n| CRM back to Facebook | 60 [V] | Live, Meta accepts 100%, but only ~18% of revenue reaches it |\n| Google ad tracking | 20 [V] | Every Google figure ever sent was typed by hand |\n| Retargeting | 5 | Approved by Kim, nothing built |\n\n**What is left:**\n\n- **The CAPI backfill.** Approved by Kim in writing. 60 of the unmatched payments already\n carry an email or phone, which is all Meta needs. Takes purchase value delivered from about\n $11,800 to about $73,000.\n- **Google developer token.** Nobody has applied. **Any date given to her before the\n application is in is invented.** Five business days by Google's own estimate.\n- **Retargeting.** Kim approved planning and asked to brainstorm the ad itself: what to show,\n the offer, where it sends. First audience is a Meta engagement audience, people who messaged\n the page, because 55% of her contacts have no email or phone. At least 3,225 people.\n Customer list second, as an exclusion.\n- **Instagram ad ID retention** sits at 40% against Facebook's 79%. Small sample, recheck in\n 90 days rather than acting now.\n\n---\n\n## 4. PAYMENTS AND THE FRONT DESK · 30%\n\n**Answered and settled this week:** the processor is Square through GoHighLevel, merchant\n`7KF50NPQP8WPT`. Wix cannot take money at all on her current plan, both providers read \"not\naccepting payments\". The `/payments` page on her site has never collected anything.\n\n| Piece | % | State |\n|---|---|---|\n| Which processor, answered | 100 [V] | Sent |\n| Prices pulled from Square | 100 [V] | 19 links: 7 programs, 12 upgrades |\n| The 19 payment links | 0 | Dashboard only, no API. Amir has GHL access now |\n| The front desk page | 0 | One page, big labeled buttons. **This is the part that made her abandon it last time** |\n| CRM product prices corrected | 0 | Basic Bootcamp, Community, Leash Free all stale |\n| Stale duplicates removed | 0 | **Stand Alone Community reads $2,000 against a current $3,295.** Biggest accidental discount risk |\n| Holiday deposit by link | 0 | Agreed route. Needs a workflow firing on the booking form |\n| The $250 PayPal deposit form | 0 [U] | Kim says one existed. I have not found it |\n\n---\n\n## 5. REVIEW WORKFLOWS · 15% · fully specified by Kim, nothing built\n\nShe wants the two step kept exactly as it is. Three changes:\n\n- [ ] **A task for anyone scoring below 10**, assigned to whoever she nominates, carrying the\n score and their actual words. **Built so Milton's notification workflow picks it up**,\n not a second alerting system. Milton's workflow texts the business phone when a task is\n created, five minutes before a due time or immediately if there is none.\n- [ ] **The 138 cards stuck in Survey Requested** get a time limit and a next step. Her own\n document confirms no timeout is configured.\n- [ ] **Google review attribution.** Google gives the reviewer's display name and timestamp,\n never email or phone. System proposes, a person confirms in one tap.\n\nAlso still true and not yet raised with her: the older workflow, which 118 people went\nthrough, has no escalation at all. Only the newer one raises a task.\n\n---\n\n## 6. KRISTIAN · 0% · the cheapest unblock on the board, still not sent\n\n| What we know | Status |\n|---|---|\n| $11,500 fixed price, signed 5 March, still in QA | [C] |\n| His dashboard reported 171 dogs in a 50 kennel building; Milton's said 24 | [V] 9 Aug |\n| After his token was reissued the sync reads success and still says 171 | [V] |\n| His app creates and updates opportunities in her CRM | [C] his words, 7 Aug, never verified |\n| **Does it write monetaryValue or move pipeline stages?** | **[U] nobody has asked** |\n| His handover list omits Clerk, environment variables, Stripe and DNS | [V] |\n| Milton confirmed his own architecture in writing 10 Aug | [V] |\n| Kim wants the employee handoff task piece working, which Kristian was meant to build | [V] |\n\n**The email is drafted and has been for two days.** One sentence to\n`solutions@moorecre8ive.com`. It unblocks the money matcher going live and nothing else on\nthe board depends on it.\n\n**Kim's own standard for replacing Milton's app:** Kristian's occupancy numbers must match her\nreal numbers every day for a full week. That is a testable bar and nobody is running the test.\n\n---\n\n## 7. WHAT NEEDS KIM, AND WHAT WE ALREADY HAVE\n\n### Already answered, nothing outstanding\nFreeze exemption for the puppy workflow. Nurture go ahead without her present. Prices come\nfrom Square's New Training Prices and Upgrades. Milton's app stays until Kristian's occupancy\nmatches for a full week. Holiday deposit by payment link after booking. Review workflow spec.\nThe CAPI backfill. Retargeting approach. GoHighLevel access, now working.\n\n### Still needed from Kim\n- [ ] **Where thedogsspotga.com was registered.** Blocks the four DNS lines and the sending\n domain, which blocks the email half of nurture. One sentence from her.\n- [ ] **How the front desk has been taking payment since late February.** The five month gap.\n- [ ] **Yes to the write back** once she has seen the dry run.\n- [ ] **Which team member** gets the review follow up tasks.\n- [ ] **Square access or a screenshot** if she wants the stale duplicate products tidied.\n\n### Needs Amir, not Kim\n- [x] ~~Delete the ZZTEST dummy, flip TEST_MODE~~ done 11 Aug, verified live 14 Aug\n- [ ] **Confirm the old \"1. Wait 1 Day: Initial Nurture - Puppy\" workflow is actually off**, and\n send the team email. Neither has been verified since go-live. [U] 14 Aug\n- [ ] Email Kristian\n- [ ] Apply for the Google developer token\n- [ ] Build the 19 payment links and the front desk page\n- [ ] Correct the three CRM product prices\n\n---\n\n## 8. THE ORDER I WOULD WORK IT\n\n1. ~~**Nurture go live.**~~ Done the evening of 11 Aug: dummy out, flag on. What is left of this\n item is confirming the old workflow is off and sending the team email, neither verified. [U]\n2. **Email Kristian.** Sixty seconds, unblocks the money matcher.\n3. **The weekly exception report.** Promised in writing this week.\n4. **The write back dry run**, shown to Kim before anything is written.\n5. **Google token application**, so her timeline stops being a guess.\n6. **Payment links and the front desk page**, prices corrected first.\n7. **Review workflow rebuild.**\n8. **The CAPI backfill.**\n9. **Retargeting audience and ad concepts.**\n10. **The five month gap**, which is really Kim's question to answer before it is ours.\n\n---\n\n## 9. WHAT CHANGED TODAY, FOR THE RECORD\n\nFixed and deployed: the inverted consent predicate that would have messaged 59 opted out\ncontacts and silently skipped the only enrollee; the weekly report's false Facebook count;\nthe matcher's stage scoping and its overwrite bug; nine hardcoded date strings; an unwrapped\ncall that had already killed an entire run once; three false timing claims on Kim's own page.\n\nBuilt: the payments ingestion layer, which did not exist. Two read only routes on the Square\nbridge, which is how the 33 were identified and the price list pulled.\n\nFound and not yet fixed: the five month revenue gap.\n\n\n",[597],"caea721b-0498-4d38-a98a-ca1689fe3d85","SOURCE-BUNDLE.part34.txt","8a22a736-97ea-11f1-902a-1607ee4eb77e",1083,["D",1786801892138],"THE DOGS SPOT — SOURCE BUNDLE (part 34 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (3 of 116 files)\n MINED-HANDOVER.md 46731 bytes f1895abbfede\n reports/money-page.html 11987 bytes 70f842d82351\n reports/square-revenue-explainer.html 12814 bytes f400df3ceb81\n\n================================================================================================\n=====FILE MINED-HANDOVER.md =====\n# MINED HANDOVER — Kim Hicks / The Dogs Spot / Amir Aizhigitov\nCompiled 2026-08-09 by mining the files listed below. Nothing edited. Tags: VERIFIED = the source\ntext itself shows a verification step (live read, test, fleet-check); CLAIMED = asserted with no\nverification shown; STALE = superseded by a later file, cited. All citations are `file:line`\nagainst the copies in `/home/claude/restore/` at time of mining.\n\nFiles read in full: handover/RESUME.md, REGISTER-AUG5.md, REGISTER-AUG7.md, SWEEP-7-AUG.md,\nPLAN-TO-FINISH.md, AUTOPILOT.md, AMIR_TODO.md, DEPOSIT-SPEC.md, DRAFTS-WHILE-AWAY.md,\nMESSAGE-TO-KIM-7-AUG.txt, SEND-TO-KIM.txt, REPLY-AUG5.txt, QUEUE.md.\n`handover/UPWORK-THREAD-FULL-9AUG.md` does not exist — checked, absent. No other top-level .md\nexists besides QUEUE.md — checked with `ls`.\n\n---\n\n## 1. THE COMMERCIAL ARRANGEMENT\n\nNo retainer amount, milestone names, milestone amounts, or a submitted/paid/not-started table\nexist anywhere in the thirteen files read. This is a genuine gap, not an oversight in mining —\nconfirmed by full read of every listed file plus a grep for `retainer|milestone|per hour|contract|\nscope of work|invoice|fixed price` across all of `handover/` and `QUEUE.md`.\n\n1. The only sentence touching Amir's own pay: **\"Your retainer figure. Still the only line item on\n the page with no number against it.\"** `handover/PLAN-TO-FINISH.md:171`. VERIFIED-absence (read\n directly, dated 5 Aug); no later file (RESUME.md 7 Aug, QUEUE.md 9 Aug) revisits or resolves it.\n A grep of `reports/*.html` for \"retainer\" also returns nothing — the page referred to still\n carries no figure as far as any file here shows. STALE-open: 5 days old at the point of mining\n with no update.\n2. Dollar figures that DO appear are not Amir's fee: Kim's own product prices ($50/dog holiday\n deposit, $500 vs $250 bootcamp deposit — `handover/REGISTER-AUG7.md:66`), her ad spend\n ($718.98/week — `handover/MESSAGE-TO-KIM-7-AUG.txt:31`), and a **different client's** Asana task\n mentioning $1998, explicitly flagged as not-Kim: `handover/SWEEP-7-AUG.md:111,124-125` (\"The\n Ariel Daunay and CoCreators work is a different client on a different stack\").\n3. No document states contract type (hourly vs fixed), start date, or weekly/monthly cadence of\n payment. The word \"Upwork\" appears only as the delivery channel for messages/reports, never as a\n contract-terms reference.\n4. Kim's own commercial asks to Amir are visible only as scope, not price: \"I absolutely wanna know\n what all this costs against what it brings in go ahead and do what needs to be done\" (approval to\n build reporting, not a payment instruction) — `handover/REGISTER-AUG7.md:68`.\n\n**Conclusion: Section 1 cannot be filled from these documents. Whatever the retainer/milestone\nstructure is, it lives outside this file set (Upwork contract terms page, a spreadsheet, or verbal\nagreement) — none of it is captured here.**\n\n---\n\n## 2. EVERY PROMISE TO KIM NOT YET DELIVERED\n\nDated, in-writing promises, most-recent message first. \"Today\" for staleness purposes = 2026-08-09\n(the date of `QUEUE.md`, the latest file in the set).\n\n1. **Deposit scope correction — DELIVERED.** Kim believed (6 Aug) the deposit feature blocks a\n booking; it only lists. `handover/REGISTER-AUG7.md:12-31` demands this be said \"plainly\" before\n anything else. It was said, in `handover/MESSAGE-TO-KIM-7-AUG.txt:10-22`, and `RESUME.md:24-30`\n states this message was sent 7 Aug 11:46pm and watched landing on Upwork. VERIFIED delivered —\n one of the few closed items.\n2. **Monday (10 Aug): July ROAS/attribution tracking check.** \"I want to check the tracking we built\n in July... Monday.\" `handover/MESSAGE-TO-KIM-7-AUG.txt:53-56`. Not yet due at time of the latest\n file (`QUEUE.md`, Sun 9 Aug). At-risk: `QUEUE.md:31-33` (item 5) shows the underlying work — the\n Square-value-onto-opportunity write that ROAS depends on — still OPEN as of 9 Aug 22:20 UK, held\n on Kim's own unanswered question (which card absorbs a multi-open-invoice payment) and on\n Kristian confirming his app doesn't also write the same field.\n3. **Monday (10 Aug): reproduce/fix \"page shows times but no dates.\"** \"I have not reproduced it yet\n and I will not tell you it is fixed until I have. Monday.\" `handover/MESSAGE-TO-KIM-7-AUG.txt:98`.\n No later file mentions this again — status unconfirmed in the set.\n4. **Tuesday (11 Aug): both calendars** (Free Training Day pick-up, 30 min slots 3:30-4:30pm;\n secondary Pup Talk calendar). `handover/MESSAGE-TO-KIM-7-AUG.txt:90-93`; also\n `REGISTER-AUG7.md:60-61`. **At risk**: `QUEUE.md:44-45` (item 10) \"Two calendars, tag cleanup,\n Free Training Day rebuild -> Correctly blocked by the Kristian freeze\" — i.e. as of 9 Aug this is\n explicitly recorded as blocked, one day before its promised date.\n5. **Wednesday (12 Aug): tag cleanup.** `handover/MESSAGE-TO-KIM-7-AUG.txt:101-103`. Same\n \"Kristian freeze\" block, `QUEUE.md:44-45`.\n6. **Wednesday (12 Aug): Free Training Day workflow rebuild**, done with Kim watching since it's her\n live workflow. `handover/MESSAGE-TO-KIM-7-AUG.txt:105-107`; `REGISTER-AUG7.md:64`. Same\n \"Kristian freeze\" block, `QUEUE.md:44-45`.\n7. **Thursday (13 Aug): Pups Club self-unsubscribe.** `handover/MESSAGE-TO-KIM-7-AUG.txt:109`. No\n later file mentions it — status unconfirmed.\n8. **\"This week\": nonrefundable-deposit wording added to customer copy.**\n `handover/MESSAGE-TO-KIM-7-AUG.txt:27`, also `DEPOSIT-SPEC.md:16-19` (the wording must say\n \"shortlist to check,\" never \"who still owes\"). No later file confirms this shipped.\n9. **Bootcamp deposit figure/processor ($500 vs $250, PayPal vs Square).** Kim's correction:\n \"it should read $500... the payment was actually set up to go onto PayPal and not through\n Square.\" `handover/REGISTER-AUG7.md:66`. **Still open 9 Aug**: `QUEUE.md:41` (item 8) \"Which\n processor the Wix Bootcamp form charges through. -> OPEN. Two minutes on the Wix payments\n screen.\" Three days open as of the latest file.\n10. **Go-live on puppy follow-up (three switches together).** Promised as \"one coordinated move\"\n repeatedly: `handover/AMIR_TODO.md:21-23`, `DRAFTS-WHILE-AWAY.md:65-78`,\n `MESSAGE-TO-KIM-7-AUG.txt:73-75`. **Still 0% live 9 Aug**: `QUEUE.md:34-36` (item 6) — \"Still 0\n percent live, still waiting on a day and a window from Kim... She has never named a time, across\n four asks.\" This is the single largest standing promise in the set.\n11. **Ten minutes to discuss Kim's-name-vs-business-name trade-off** \"when you are back.\"\n `handover/MESSAGE-TO-KIM-7-AUG.txt:85-88`. No later file confirms this happened.\n12. **Candace's app freezing when loading messages — diagnosis owed.** Raised by Kim, acknowledged\n open in `handover/REGISTER-AUG7.md:89-91`, `REPLY-AUG5.txt:27`(\"I'd rather say that than guess\"),\n `PLAN-TO-FINISH.md:201-204` (states it is \"a hypothesis about somebody else's code, not a\n finding\"). No later file reports a diagnosis delivered.\n13. **The Sunday 9 Aug 3pm EST / 8pm BST Kristian walkthrough — \"I will be there.\"** Draft at\n `handover/DRAFTS-WHILE-AWAY.md:9-26`. **Outcome not confirmed by any file in this set.**\n `QUEUE.md` is timestamped the same day (Sun 9 Aug, 22:20 UK — after the 8pm BST slot) and\n references \"the 11:00 meeting\" (`QUEUE.md:23,32`) but never states whether the 3pm EST call\n itself happened or whether Amir attended. This is the most time-critical unresolved item in the\n set and its resolution is simply not in these files.\n14. **\"I will send you a one page version on Sunday morning.\"** `handover/DRAFTS-WHILE-AWAY.md:19-20`.\n No file confirms this draft was ever sent (unlike the Friday report, whose sending IS confirmed —\n see item 1 pattern in Section 7). CLAIMED-intent only.\n15. **Manychat card-failure notice to Kim.** Drafted, `handover/DRAFTS-WHILE-AWAY.md:30-47`;\n registered as urgent and unsent in `handover/SWEEP-7-AUG.md:62-73`. No file confirms it was sent.\n16. **\"I'll come back on them specifically\"** — missing call transcripts and Candace's app.\n `handover/REPLY-AUG5.txt:31`. Transcripts were later answered (`PLAN-TO-FINISH.md:197-204`, \"the\n recordings are all there... transcription is a separate switch,\" dated 5 Aug — CLAIMED, no\n later file re-confirms this reached Kim in those terms). Candace's app remains open per item 12.\n17. **Retargeting ad \"to be discussed.\"** `handover/REGISTER-AUG7.md:67`. No date, no later mention.\n18. **Four sending-domain lines for thedogsspotga.com (deliverability) + key rotation.** Kim is\n willing but needs step-by-step instructions: \"I'm happy to add the 4 lines but would need\n instructions on how and where to do it.\" `handover/REGISTER-AUG7.md:101-102`. **Still blocked 9\n Aug**: `QUEUE.md:37-39` (item 7) — \"BLOCKED, needs Amir's login. The browser now holds his own\n agency session, and The Dogs Spot is not a sub account of it. Ten routes logged in the previous\n queue entry, all failed.\" Newly-hardened blocker, not just an open task.\n19. **Google Ads build-out.** Long-standing: \"coded, never run against a live account... It gets an\n account and gets tested, or it comes off the list honestly.\" `handover/PLAN-TO-FINISH.md:194-195`\n (5 Aug). **Quantified and still open 9 Aug**: `QUEUE.md:42-43` (item 9) — \"Google Ads is 20\n percent, not 70. The connector is a stub that throws and discards its result... needs a developer\n token, about five business days.\" The \"20 not 70\" phrasing implies a 70% figure was stated\n somewhere (not located in this file set) that this corrects downward.\n20. **One-year-old dog boundary decision** — asked of Kim, never answered in any file read:\n `handover/PLAN-TO-FINISH.md:133`, repeated `handover/RESUME.md` questions ledger is silent on it\n specifically but the open-questions ledger format continues unresolved through to `QUEUE.md`.\n21. Standing ledger of unanswered Kim questions, repeated near-verbatim across three files without\n resolution: boarding cancellation policy (nothing on her website), Thanksgiving window edges\n (Mon-before to Sun-after), whether she offers daycare and at what price. Present in\n `handover/RESUME.md:147-151`, `REGISTER-AUG7.md:107-111` — carried forward unchanged, i.e.\n STALE-unresolved across at least two dated snapshots (7 Aug both times) with no later file\n revisiting them.\n\n---\n\n## 3. HER VOICE AND THE WRITING RULES\n\nAll quotes are Kim's own words unless marked otherwise.\n\n1. **American spelling, not British — a standing, repeatedly-enforced rule, not a one-off.**\n Evidence across three separate dates:\n - ~5 Aug: \"Potty training and yard now, and I went back through the rest of the older copy for\n the same thing and found a few more that read English rather than American... There is a check\n on it now, so it stays fixed rather than drifting back.\" `handover/SEND-TO-KIM.txt:5`.\n - 7 Aug: her own correction, quoted and labelled explicitly: **\"how you're getting on\" → \"how\n it's going\". British.** `handover/REGISTER-AUG7.md:80`.\n - 9 Aug: a live violation reached her card page anyway — \"counter sales totalling\" — fixed and\n redeployed same day. `QUEUE.md:20-22` (item 3), verified live 21:06:20Z, \"zero 'totalling' on\n the page, one 'totaling'.\" Shows the rule needed re-enforcement a third time.\n2. **\"Daycare\" is a banned word in customer-facing copy — not a preference, a factual error.**\n \"Daycare is gone completely, and thank you for catching it, because that one was a proper mistake\n rather than a wording preference. It was in four separate messages offering a service you don't\n provide... there's now an automatic check that fails the whole build if the word ever reappears\n anywhere a customer could see it.\" `handover/SEND-TO-KIM.txt:7`. Confirmed still enforced 7 Aug:\n \"'Daycare' was on her dashboard, which she instructed removed from customer copy.\"\n `handover/DEPOSIT-SPEC.md:802-803`. Cross-referenced open question: does she actually offer\n daycare (her own bio says yes, no page/price exists) — `handover/RESUME.md:149-151`.\n3. **Drop \"I got your message\" from Touch 2.** Her words: **\"What message am I replying to exactly?\"**\n Instruction: \"Keep the welcome, lose the reply framing.\" `handover/REGISTER-AUG7.md:72-73`.\n4. **Cut \"it's not a pitch,\" keep \"it's a conversation.\"** Her words: **\"I don't like that it keeps\n saying that it's not a pitch. Can we just leave off the part about the pitch and just tell them\n what it is rather than what it isn't.\"** `handover/REGISTER-AUG7.md:74-76`.\n5. **Cut negatives generally — \"I won't chase you,\" no-show/no-sale negative framing.** Her words:\n **\"I'd rather remove language about what I won't do and leave the more positive language in there\n that says they can call, they can reach out anytime.\"** `handover/REGISTER-AUG7.md:77-79`.\n6. **Kim's name vs. The Dogs Spot business name — a live open positioning question, not decided.**\n Her words: **\"is there a way to use the business name The Dogs Spot instead of my personal name or\n mix the two... if they've only ever been hearing from Kim they'll never get me on the phone but\n they'll get my team.\"** `handover/REGISTER-AUG7.md:81-85`. Recorded trade-off: a named human\n outperforms a business name on reply rate — she is to be told this before it changes, i.e. not to\n be actioned without explaining the cost.\n7. **Don't lean on data fields that are usually empty — the puppy's-name lesson.** Kim objected to\n the puppy's name appearing/not appearing correctly; root cause was that most inquiries arrive via\n Facebook/Instagram DM, which rarely carries a dog's name, so a name placeholder mostly rendered\n empty. Fixed by rewriting around the customer's own name instead of the dog's.\n `handover/SEND-TO-KIM.txt:3`.\n8. **Rewrite the missed-Pup-Talk messages in Kim's own words, not the drafter's.** \"Both of the\n missed-Pup-Talk messages are your version rather than mine now, near enough word for word,\"\n including her own lines \"I know life gets busy\" and \"won't keep bugging you.\"\n `handover/SEND-TO-KIM.txt:9`.\n9. **Greeting/sign-off convention observed consistently across all four Kim-facing message files**\n (not stated as an explicit rule anywhere, but uniform in practice): every message ends with the\n single word **\"Amir\"** — no \"Best,\" \"Thanks,\" or \"Regards\" — `handover/REPLY-AUG5.txt:37`,\n `SEND-TO-KIM.txt:37`, `MESSAGE-TO-KIM-7-AUG.txt:122`, all four `DRAFTS-WHILE-AWAY.md` drafts.\n Opening greeting is NOT uniform: `SEND-TO-KIM.txt:1` and `REPLY-AUG5.txt:1` open \"Kim, ...\" (straight\n into the answer, no \"Hi\"); the drafts in `DRAFTS-WHILE-AWAY.md` also use bare \"Kim,\"; but\n `MESSAGE-TO-KIM-7-AUG.txt:1` opens **\"Hi Kim,\"** — a departure from the pattern the other three\n files establish. Not flagged as an error anywhere in the text; noted here as an observed\n inconsistency, not a stated rule violation.\n10. **Explicit style rule for the stand-by reply drafts**: **\"No dashes anywhere. Answer in the first\n line.\"** `handover/DRAFTS-WHILE-AWAY.md:3`.\n11. **Recurring closing reassurance formula**, used verbatim or near-verbatim in multiple sent\n messages: \"Nothing has sent to anybody. Everything stays in practice mode until you say the\n word.\" `handover/SEND-TO-KIM.txt:35`, `MESSAGE-TO-KIM-7-AUG.txt:120`; variant \"Nothing has sent\n to anybody from the new system, today included.\" `handover/REPLY-AUG5.txt:35`.\n12. **Own mistakes are to be owned to Kim explicitly, by name, not smoothed over.** Pattern used\n repeatedly: \"Three corrections of my own, because you should hear them from me\"\n (`SEND-TO-KIM.txt:21`); \"I also went quiet for two days before that. You should not have had to\n ask twice.\" (`MESSAGE-TO-KIM-7-AUG.txt:6`); \"The attachment. You didn't miss it, it failed to\n attach, and that's twice now, which is embarrassing.\" (`REPLY-AUG5.txt:15`).\n13. **The rendered deposit-card copy for HER CUSTOMERS (a related but distinct audience/rule)**: the\n word **\"unpaid\" must never appear** (`DEPOSIT-SPEC.md:32`), and after three rounds of a\n deny-list being defeated, the note text is now generated only from a small closed set of\n templates and matched exactly (allow-list), because \"a denylist over free prose cannot be\n completed.\" `DEPOSIT-SPEC.md:851-856`. See Section 6 for the failure history behind this rule.\n14. **Cost-and-honesty voice**: when a figure cannot be verified, the rule is to say so rather than\n fill the gap. \"Where a figure could not be verified I have written that instead of filling the\n gap.\" `handover/MESSAGE-TO-KIM-7-AUG.txt:32`. Matches the build-side rule in Section 4/5 against\n inventing numbers.\n\n---\n\n## 4. RULES OF ENGAGEMENT\n\n1. **The five hard stops, never done without Amir \"however obvious they look\"**\n (`handover/AUTOPILOT.md:6-17`):\n 1. Anything that reaches a customer — no message, no live workflow switch, no triggering tag.\n Practice mode holds.\n 2. Anything that costs money or fixes a payment (Manychat card named explicitly).\n 3. Anything irreversible — deleting tags, contacts, workflows, calendars.\n 4. Anything needing Amir's identity — accepting the Kristian invite, joining the call, replying\n to Kim, accepting access invitations.\n 5. Editing a live workflow of Kim's, even one she has verbally agreed to let be rebuilt, until\n she has watched it happen.\n2. **\"What I will not do\" list** (`handover/PLAN-TO-FINISH.md:212-219`): don't contact Kim directly —\n every question goes into the ledger instead; don't take anything out of practice mode without both\n her word and Amir's presence; don't invent a story, testimonial, customer or event to fill a gap;\n don't type a live number into a document — \"Anything countable is counted at render time\"; don't\n ship a finding that couldn't be independently stood up (one was dropped from the nurture review\n for this reason and the drop was itself documented).\n3. **The admin key must never reach Kim or be echoed.** \"Never echo it, never put it in anything Kim\n reads.\" `handover/RESUME.md:99`.\n4. **The val.town token, if recovered from a session transcript, must not be printed or filed\n anywhere Kim or a subagent can read.** \"extract it without printing it. Do not paste it into any\n file Kim or a subagent can read.\" `handover/RESUME.md:122-124`.\n5. **Do not act on another client's items from a session holding Kim's credentials.**\n `handover/SWEEP-7-AUG.md:124-125`: \"The Ariel Daunay and CoCreators work is a different client on\n a different stack. Acting on it from a session holding Kim's credentials is how one client's data\n ends up in another's account.\" A full table of that other client's unrelated inbox items is\n logged but explicitly marked \"do not act on from this session,\" `SWEEP-7-AUG.md:104-123`.\n6. **The switch-over to go-live is one coordinated move, never solo, never in pieces.**\n \"TEST_MODE=false, old puppy workflow off, tagging on. Never solo.\" `handover/AMIR_TODO.md:21-23`.\n Justification given directly: doing it in pieces is what double-messaged Thomas.\n `handover/DRAFTS-WHILE-AWAY.md:73-74`.\n7. **holiday-deposits.ts is structurally read-only** — \"Write NOTHING to the CRM. No tag, no field,\n no stage,\" enforced by a test asserting no POST/PUT/PATCH verb exists in the source.\n `handover/DEPOSIT-SPEC.md:22-23,28-29`.\n8. **A live workflow of Kim's is not to be edited without her present**, even when she has endorsed\n the change in principle: \"she is open to redoing it... but it is a live workflow of hers and\n should be changed with her watching.\" `handover/REGISTER-AUG7.md:64`.\n9. **Accepting the Kristian calendar invite is Amir's identity and diary — nobody else's call.**\n `handover/SWEEP-7-AUG.md:47`.\n10. **\"The Kristian freeze\"** — named in `QUEUE.md:44-45` as the reason two calendars, tag cleanup,\n and the Free Training Day rebuild are \"correctly blocked.\" **Not defined anywhere else in this\n file set** — its scope and trigger condition are referenced, not explained, in the documents\n read. Flagged rather than guessed at.\n11. **Do not widen the accusation-net regex again** — an explicit process instruction after three\n widenings all failed: \"Do NOT widen the regex a fourth time — make the note cell an allow-list by\n construction.\" `handover/RESUME.md:71-73`.\n12. **CONTRADICTION — GHL token regeneration.** `handover/PLAN-TO-FINISH.md:151-153` (5 Aug):\n **\"Do not regenerate the token — that changes it, which takes the engine offline and silently\n kills Kim's dashboard link, because her view key is derived from it.\"** Yet `handover/AMIR_TODO.md:10-13`\n (6 Aug) and `handover/RESUME.md:154-157` (7 Aug, the most recent instance) both instruct exactly\n that: tick the tags-view scope, Save, **Regenerate**, then paste the new token into both val env\n tabs. Neither later file acknowledges or rescinds the 5 Aug warning about the dashboard link\n breaking. Both sides given as found — not resolved by this mining pass.\n13. **CONTRADICTION — how many times the container reverted on 7 August.** `handover/RESUME.md:111`:\n **\"It reverted twice on 7 August — at ~15:10 and again at ~17:15.\"** `handover/AUTOPILOT.md:77`:\n **\"The container reverted five times on 7 August.\"** Both files are dated to the same day's work;\n neither cites the other's number. Given as found.\n14. **Practice mode / TEST_MODE is the operative safety rail**, verified live as recently as the\n newest file: \"testMode true, sent 0.\" `QUEUE.md:7`. A specific code guard is named: \"The guard at\n puppy_path_v1.1.ts:904 fails closed.\" `QUEUE.md:35`.\n15. **An engine hardening item was queued but its closure is not confirmed by name in later files**:\n \"add a TEST_MODE guard at the sendSms call site (today safety is contact-scoping to the dummy).\"\n `handover/REGISTER-AUG5.md:24`, repeated `handover/AMIR_TODO.md:25-26`. `QUEUE.md`'s \"fails\n closed\" language (9 Aug) is consistent with this having been done but does not name the guard the\n same way — treat as CLAIMED-likely-done, not confirmed-done.\n\n---\n\n## 5. TESTING AND QUALITY STANDARDS\n\nThe bar, as practiced (drawn mainly from `handover/DEPOSIT-SPEC.md`, `PLAN-TO-FINISH.md`,\n`RESUME.md`, `QUEUE.md`):\n\n1. **A negative control is not a second test — it is a fault injected into a temporary copy of the\n code, which must make one *named* test go red.** \"If the wrong test catches it, or nothing does,\n the control fails.\" `handover/PLAN-TO-FINISH.md:12-14`. Grown from 30 controls (5 Aug,\n `PLAN-TO-FINISH.md:181`) to 203 (7 Aug, `RESUME.md:86`), with money-critical ones re-run on every\n single test invocation (7 then 6 then 7 — see item 6 below).\n2. **A test that executes zero assertions must be a hard failure, not a pass.** Proved by hollowing\n `H1` to `return scoped(N, label)`: printed PASS, identical check totals, fully green.\n `handover/DEPOSIT-SPEC.md:759-764`. Fixed by having `ok()`/`eq()` increment an internal counter and\n failing any suite whose count is zero, ratcheted per suite.\n3. **Floors must be proven to have actually run**, not just counted. A whole suite can vanish (file\n deleted, renamed `.bak`, or added to an exclusion list) and `run-all` still print GREEN — proved\n three separate ways. `handover/DEPOSIT-SPEC.md:753-757`. Fixed: every key in a floor table must\n appear in the discovered suite list or the run is RED.\n4. **The behavioural build must actually be rebuilt before assertions run against it.**\n `run-all.mjs` previously imported `build/` for behaviour and `engine/` for structure, but never\n rebuilt — deleting the fix from source and re-running gave \"270 assertions passed, GREEN.\"\n `handover/DEPOSIT-SPEC.md:230-232`.\n5. **Structural checks must read comment-stripped source.** A forbidden call was removed but named in\n a `[was: ...]` comment; the check matched the comment text and stayed green.\n `handover/PLAN-TO-FINISH.md:61-64`; the corresponding fix and its own negative control (forbidden\n text placed only inside a comment) at `handover/DEPOSIT-SPEC.md:242-244`.\n6. **Money-critical logic gets re-proved on every run, not just once.** Six, then seven, \"money\n guards\" are re-injected and required to fail on every single test invocation, ~30 seconds cost.\n `handover/DEPOSIT-SPEC.md:641-645,731-732`. Also fingerprinted (not matched by test name) so a\n fault under a kept name can't be swapped for a harmless one. `DEPOSIT-SPEC.md:770-771`.\n7. **Deny-lists over free prose are treated as fundamentally unable to complete** — stated\n explicitly as the conclusion after three widenings all failed: \"A denylist over free prose cannot\n be completed.\" `handover/DEPOSIT-SPEC.md:851-852`. The replacement standard is an **allow-list by\n construction**: every customer/Kim-facing sentence must be generated from a small closed set of\n templates, and the test reconstructs the expected string from the template plus the row's own\n data and demands an exact match — \"the same provenance-by-exclusion argument already used for the\n money figures.\" `DEPOSIT-SPEC.md:853-856`.\n8. **Money provenance is proved by exclusion, not by substring search.** A substring check (\"does\n this figure appear anywhere in the notes?\") let an invented debt total pass because it coincided\n with a real row's figure. Fixed: strip everything the card was legitimately given; anything left\n over was invented. `handover/DEPOSIT-SPEC.md:709-716`.\n9. **\"Scope of zero\" — a zero must be shown to be a true population zero, not a narrow-scan\n artifact.** The go-live blocker used to read \"1,200 of your most recent contacts were checked\" —\n \"a scan size dressed as an answer.\" Replaced with reading all 5,544 contacts every page load, and\n the zero cross-checked against a full manual page-by-page walk that agreed exactly on three other\n tags before the zero was trusted. `handover/PLAN-TO-FINISH.md:110-116`. Same standard applied to\n revenue: \"0 of 5,768 opportunities are marked won, all time\" is stated as a full-population fact,\n not a sample. `handover/MESSAGE-TO-KIM-7-AUG.txt:47`.\n10. **Live assertions over static numbers.** \"Type a live number into a document again\" is banned;\n \"Anything countable is counted at render time.\" `handover/PLAN-TO-FINISH.md:217`. Practiced\n repeatedly: \"watched live at 03:13:02Z,\" refresh timestamps quoted to the second throughout\n `DEPOSIT-SPEC.md`.\n11. **Property-based testing at scale for the allocator**: 50,000 generated customers (round 7),\n 300,000 property cases (round 8), 460,000 randomised cases (round 10), 841,000 shuffles (round\n 14) — each looking for a specific invariant (disjoint payment coverability, order-independence).\n `handover/DEPOSIT-SPEC.md:366-368,439,550,785-788`.\n12. **Typecheck is a real gate, not cosmetic.** \"Nothing had ever typechecked this project\" — a field\n was added to a type and two object literals were never updated; esbuild strips types without\n checking, so the build was clean and 290 assertions were green over a real type error. Fixed with\n a Deno-aware `tsc` wired into `run-all.mjs`, re-injected to prove the gate fires.\n `handover/DEPOSIT-SPEC.md:377-381`. It also once printed \"0 engine files, 0 real errors\" and\n exited 0 on an empty tree — a false green closed separately. `DEPOSIT-SPEC.md:774`.\n13. **Deploy verification checks both units and gates on the stricter.** `deploy.mjs` reports\n `main.ts` in both characters and bytes, \"At one point it read 79,815 characters and 80,137 bytes\n — '185 to spare' on one measure, over the line on the other.\" `handover/DEPOSIT-SPEC.md:264-266`.\n14. **val.town serves a cached copy immediately after a write** — a verify-by-read right after deploy\n shows the old hash and looks like a failed deploy. `handover/PLAN-TO-FINISH.md:22-24`. Treated as\n a standing trap, not a one-off (see Section 6).\n15. **Autonomous scheduling must be watched, not assumed.** The deposit refresh's cron was not\n trusted as \"working\" until the stored `at` timestamp was seen moving with nobody triggering it,\n and the *source* of the trigger (cron file vs. engine interval) had to be separately labelled in\n code rather than inferred — this took eleven-plus hours of explicit \"not yet observed\" caveats\n before being accepted. `handover/DEPOSIT-SPEC.md:76-81,196-203,276-283,396-406,415-431`.\n16. **Bundling must be recursive, and this was itself a live QA failure.** `bundle.mjs` only walked\n one directory level deep, silently dropping `tests/fixtures/`, which is why a from-bundle restore\n came back red. `QUEUE.md:16-19` (item 2). Fixed with a recursive walk and `.json` fixtures\n included; round-trip verified.\n17. **`restore.mjs --check` must show byte-for-byte agreement on every file** before a restore is\n trusted. `handover/RESUME.md:90`; re-confirmed post-crash in `QUEUE.md:9` (\"`deploy.mjs --check`\n then reported 'live matches local, every file'\").\n18. **Per-suite ratchets, not just a global floor.** A global floor of 100 assertions didn't notice\n when seven money-guard tests were deleted from one suite; fixed with a per-suite ratchet.\n `handover/DEPOSIT-SPEC.md:449-451`.\n19. **The goal state, stated and never yet reached**: two consecutive CLEAN adversarial rounds.\n Fifteen rounds had run by 7 Aug and every one found something real\n (`handover/RESUME.md:74,86`, `DEPOSIT-SPEC.md:832-856` — round 15 itself \"IN FLIGHT, NOT CLEAN\").\n20. **The 203/332 figures in `RESUME.md` (7 Aug) are themselves superseded** by `QUEUE.md` (9 Aug),\n which reports a rebuild after a second container reclaim at \"17 suites, 380 assertions, 0\n failed\" (`QUEUE.md:15`) — a different count, consistent with continued work, not a contradiction,\n but proof the numbers in any single file go stale within two days.\n\n---\n\n## 6. KNOWN TRAPS\n\n1. **Container/disk reversion to a stale snapshot — the single most expensive, most recurring\n failure mode in the whole set.** Recorded on: 4 Aug (`REGISTER-AUG5.md:31`, third time that day),\n 7 Aug twice per `RESUME.md:111` or five times per `AUTOPILOT.md:77` (see Section 4 contradiction\n #13), and again some time before 9 Aug per `QUEUE.md:5-9` (\"The container was reclaimed mid\n session. /home/claude/restore was gone entirely\"). Fix pattern each time: restore engine from the\n val's last-deployed state, restore everything else from the bundle's last-bundled state, rebuild.\n **The trap inside the trap**: those two restore sources can be from different points in time,\n producing a \"mismatched repo\" that looks like new bugs. `handover/RESUME.md:126-131`;\n materialised concretely at `handover/DEPOSIT-SPEC.md:809-815` (round 14 reversion cost \"roughly\n half this session's remaining budget\"). **The stated fix is procedural, not technical**: rebundle\n the instant the tree goes green, never at end of session. `RESUME.md:130-131`, `AUTOPILOT.md:77`.\n2. **val.town serves a stale/cached read immediately after a deploy.** A verify-by-read right after\n deploying shows the old hash and looks like the deploy failed. `handover/PLAN-TO-FINISH.md:22-24`.\n3. **`main.ts` is called `puppy_path_v1.1.ts` locally** — a naming trap called out explicitly as one\n of \"the two traps that cost time before.\" `handover/PLAN-TO-FINISH.md:21-24`.\n4. **A previous session's handover claimed a message was sent to Kim that was never actually sent.**\n \"The brief for this session described a message sent this morning covering the deposit\n correction... That message does not exist in the thread. So none of it has reached her.\"\n `handover/REGISTER-AUG7.md:124-129`. This is a first-order trap for anyone trusting a prior\n session's own status claims without re-checking the live thread.\n5. **A claim to Kim was technically false the moment it was sent.** \"Nothing new will go to him\" (re\n Thomas) was contradicted three hours later by three legitimate booking-confirmation texts from a\n *different* workflow. `handover/REGISTER-AUG5.md:10-14`; acknowledged directly: \"bridge note\n corrects it,\" `handover/AMIR_TODO.md:8-9`.\n6. **Two different units subtracted from each other produced a wrong headline figure.** The watchdog\n reported 35 counter sales worth $23,463.99 against the dashboard's 40/$28,035.99; root cause was\n skipping rows with an email/phone and subtracting a count of journal *rows* from a count of\n *payments*. Fixed by having the watchdog import the dashboard's own function.\n `handover/PLAN-TO-FINISH.md:27-33`.\n7. **Same trap, twice in a row, on the watchdog's schedule.** First wrongly concluded the timer had\n \"never fired\" (it was firing daily, deliberately, per a week-old val.town chat instruction). After\n switching to hourly, wrongly concluded the timer was dead a *second* time because the write-up's\n own \"is this a scheduled run\" detector was broken (val.town passes an argument to the scheduled\n function that the code didn't expect). `handover/PLAN-TO-FINISH.md:39-52`.\n8. **A page quoted the author's own manual button-presses back to the client as if it were the\n system's schedule.** \"left to itself it runs about every 95 minutes\" was \"honestly measured off\n the wrong thing.\" `handover/PLAN-TO-FINISH.md:56-59`.\n9. **A structural check can be satisfied by a comment.** A forbidden call was removed and a `[was:\n ...]` comment added naming it; the test read the raw file and matched the comment.\n `handover/PLAN-TO-FINISH.md:61-64`.\n10. **Age-parsing regex order-of-operations bug.** Pattern expected \"3-year-old\" but real text read\n \"3 years and 4 months old\" — \"old\" trailing the months clause made it fall through to the months\n branch, misreading 3-years-4-months as 4 months. Caught by the project's own test after a\n rewrite reintroduced it. `handover/PLAN-TO-FINISH.md:87-89`.\n11. **The core \"money bug\" recurred through at least five independent code paths across nine\n adversarial rounds** — the single richest trap in the set. Rule: one $50 deposit must settle\n exactly one stay. Each round fixed one door; the next round found the same effective bug one\n layer deeper:\n - Round 3: `statusFor` was handed a customer's *entire* payment list per stay, so one payment\n cleared two stays at once. `DEPOSIT-SPEC.md:153-162`.\n - Round 4/6: the collapse-duplicate-payments step marked only the surviving id as spent, and\n later wasn't idempotent, so a second pass re-spent a payment that should have stayed spent.\n `DEPOSIT-SPEC.md:219-223`.\n - Round 7: the \"what settles a stay\" rule and the \"what does it cost\" rule lived in two separate\n places and drifted — a two-dog stay paid by one $100 payment could clear while debiting\n nothing, so the same $100 settled a second stay too. A property test found this in 29% of\n multi-stay generated customers. Fixed by making one function, `qualifyingPayments`, the only\n source of truth for both questions. `DEPOSIT-SPEC.md:350-373`.\n - Round 9: `collapseSameMoney` folded a backfill record into a payment on amount alone with no\n date bound, so a real November and a real December $50 payment (14.6 days apart) were read as\n one, deleting a real deposit. Fixed with a 21-day bound. `DEPOSIT-SPEC.md:476-495`.\n - Round 11: the allocator was passed the *globally collapsed* payment list instead of the raw\n list, so a later payment could make an already-settled stay look completely unpaid.\n `DEPOSIT-SPEC.md:603-618`.\n The pattern itself is named directly: \"the same money bug came back three times, one layer down\n each time\" (round 4-6) and a fourth and fifth time in rounds 7 and 9. `DEPOSIT-SPEC.md:211-213`.\n12. **A test can be hollowed to a one-line stub and still print PASS**, with identical check counts.\n Demonstrated by deleting all five assertions from `H1`: \"86 passed, 0 failed, 327 checks,\n byte-identical to the honest run, GREEN.\" Only a negative control (which demands the specific\n test go red on a specific fault) catches this — self-reported check totals do not.\n `handover/DEPOSIT-SPEC.md:759-764,634-645`.\n13. **`negative-controls.mjs` itself was silently truncated by an edit at least twice**, printing\n nothing and exiting 0 — which reads as \"all controls passed.\" Happened once mid-round-two\n (`DEPOSIT-SPEC.md:134-137`) and again in round 14 with the file cut to three entries\n (`DEPOSIT-SPEC.md:766-767`). Fixed with an `EXPECTED_CONTROL_COUNT` sanity check before anything\n runs.\n14. **A guard can be pinned by exact text and still be unreachable.** One statement inserted *above*\n a pinned block can kill both refresh schedules while leaving the pinned text, indentation, and\n identifier counts untouched, so the suite stays green while nothing actually refreshes.\n `handover/DEPOSIT-SPEC.md:562-568,622-624`.\n15. **A single calendar failing silently overwrote a complete customer list with a partial one, at a\n fresh timestamp**, so missing customers got no row at all rather than an \"unknown\" row — the\n quietest possible failure mode, because `decideStore`'s refusal logic checked for empty/all-\n unknown/no-progress runs but not for \"fewer calendars answered than last time.\" Fixed by\n comparing calendar-response counts. `handover/DEPOSIT-SPEC.md:778-783`.\n16. **Nine separate crash conditions existed in the card-rendering function alone**, each capable of\n taking down the whole dashboard (non-iterable rows, a string where a number was expected, an\n unparseable timestamp silently skipping the staleness banner, an unrecognised state rendering a\n wrong-coloured dot, bidi-override and unbounded-length strings reaching the page from a public\n booking form, a UTC vs. local-time date-slicing bug). `handover/DEPOSIT-SPEC.md:790-797`.\n17. **The GHL API exposes contact notes but the earlier conclusion \"the CRM never sees Square money\"\n was wrong** — nobody had queried `/contacts/{id}/notes` before 6 Aug; Square payments were there\n all along, written in at least two different textual formats, and the same payment could appear\n up to five times with contradictory balance figures in the duplicates.\n `handover/DEPOSIT-SPEC.md:1-13,58-63`.\n18. **The knowledge base is readable via API, contrary to an earlier \"UI-only\" claim in \"the master\n handoff\"** (a document referenced repeatedly but not present anywhere in this restore tree — see\n Section 7). `handover/PLAN-TO-FINISH.md:104-108`.\n19. **`GET .../calendars/events` may silently cap at 100 with no paging** — known for one endpoint,\n unconfirmed for the two calendar-read endpoints the deposit tracker depends on. Explicitly left\n as an open question rather than guessed: \"Guessing a threshold would be inventing one.\"\n `handover/RESUME.md:136-139`.\n20. **Two schedules (the cron file and the engine's own interval) can race**, and val.town's blob\n store has no compare-and-set to make the update atomic — accepted as an unfixable-by-design\n condition, with the guarantee narrowed to what can actually be true (whichever fires first wins,\n the other is a no-op) rather than a false stronger claim. `handover/RESUME.md:141-143`;\n `handover/DEPOSIT-SPEC.md:429-431`.\n21. **A bridge-journal admin dump route was attempted and blocked.** `QUEUE.md:46-50` (item 11):\n ten routes tried, blocked by a masked `ADMIN_SECRET` with no API exposure. Directly corroborated\n by reading `DATA-PULL-evidence/bridge_journal_dump_2026-08-09.json` — its entire content is the\n literal string **\"forbidden\"**. VERIFIED by direct read (file outside the required list, read for\n cross-check only).\n\n---\n\n## 7. WHAT EACH FILE IS FOR, CURRENT OR SUPERSEDED\n\n1. **`handover/RESUME.md`** — \"Read this first\" state/recovery snapshot, updated live through the\n session of 7 Aug, timestamped 23:40 UTC. Current for its own day; **superseded** as the overall\n project-state document by `QUEUE.md` (9 Aug), which records a second container reclaim and further\n fixes after RESUME.md's last entry.\n2. **`handover/REGISTER-AUG5.md`** — Short fleet-verification addendum, late 5 Aug, fact-checking the\n claims in the message now identified as `REPLY-AUG5.txt`. STALE by design (an addendum to a\n specific sent message); content fully absorbed into later registers, not contradicted.\n3. **`handover/REGISTER-AUG7.md`** — The working register of Kim's unanswered thread, 6-7 Aug,\n including a same-day self-update (\"No message was sent to Kim today\") at its foot. The single\n richest source for her verbatim voice/copy requests (Section 3) and unresolved asks (Section 2).\n Current as of 7 Aug ~17:5x UTC; not contradicted by later files, only added to.\n4. **`handover/SWEEP-7-AUG.md`** — A later, broader sweep (both email inboxes, Upwork, calendar),\n 7 Aug 23:16-23:35 UTC. Surfaces the Kristian Sunday-walkthrough urgency and explicitly separates\n Kim's items from an unrelated client's (Ariel Daunay/CoCreators). Most current same-day statement\n of what is blocked on Amir specifically.\n5. **`handover/PLAN-TO-FINISH.md`** — Dated 5 Aug 11:50, the earliest full status/plan document in\n the set. **STALE**: its own suite/control counts (11 suites, 151 checks, 30 controls) are an order\n of magnitude below 7 Aug's (332 tests, 203 controls) and 9 Aug's (380 assertions), and its\n \"door-opening\" action list (Meta app role, GHL scopes, retainer figure) is only partly resolved by\n later files. Still the source of several rules that are never contradicted later (Section 4 items\n 1-2), so not fully obsolete.\n6. **`handover/AUTOPILOT.md`** — Standing playbook for operating without Amir: hard stops, escalation\n table, schedule-verification method. Not dated in-file; cross-references match the 7 Aug cluster.\n Its safety rules are not superseded by any later file.\n7. **`handover/AMIR_TODO.md`** — Short personal punch-list, \"morning of 6 Aug.\" Superseded as a status\n report by `RESUME.md`/`QUEUE.md`, but its \"never solo\" switch-over rule and the GHL\n regenerate-token instruction persist uncontradicted into 7 Aug (see Section 4 contradiction #12).\n8. **`handover/DEPOSIT-SPEC.md`** — The engineering build log for the holiday deposit tracker,\n fifteen adversarial rounds, 6-7 Aug, the richest source for Sections 5 and 6. Ends mid-round-15,\n explicitly **\"IN FLIGHT, NOT CLEAN\"** — not a finished spec. Partly continued/superseded by\n `QUEUE.md` (9 Aug), which records further fixes to the same feature (British spelling on the\n card, a bundling bug affecting its own test fixtures) after this file's last entry.\n9. **`handover/DRAFTS-WHILE-AWAY.md`** — Six pre-written reply templates for Amir to send verbatim or\n edited. Companion to `AUTOPILOT.md`. No file in the set confirms any of the six were actually sent.\n10. **`handover/MESSAGE-TO-KIM-7-AUG.txt`** — The full message text sent to Kim 7 Aug 11:46pm;\n sending and landing confirmed by `RESUME.md:24-30`. Current/delivered as of its date; several of\n its own promised dates (Section 2) are still pending or newly blocked per `QUEUE.md`.\n11. **`handover/SEND-TO-KIM.txt`** — An earlier message to Kim (no in-file date; content and a\n forward-reference to a dashboard-link message that `REPLY-AUG5.txt` then delivers place it at or\n just before 5 Aug — inferred from cross-file content, not stated). Superseded in substance: the\n two-options deposit framing it describes was later built out fully in `DEPOSIT-SPEC.md`.\n12. **`handover/REPLY-AUG5.txt`** — Message to Kim dated by filename and content to 5 Aug, covering\n the Thomas incident, Kristina record merge, tag report, and delivering the dashboard link. This\n is the message `REGISTER-AUG5.md` fleet-verified; one of its claims (\"Nothing new will go to\n him\") is flagged false there (Section 6, item 5).\n13. **`QUEUE.md`** — The most recent file in the set, Sunday 9 Aug 22:20 UK, written after a *second*\n container reclaim. DONE/OPEN ledger format with proof-of-completion or blocker-and-attempted-\n routes for each item. This is the current state of record as of mining.\n14. **`handover/SOURCE-BUNDLE.part1-13.txt`** — Not read in full (outside the required list; grepped\n only). Per cross-references in the read files, this is a disaster-recovery text bundle of\n everything not already living on val.town (tests, scripts, handover docs), restorable via a\n command in each part's header, and used successfully to recover from the reclaim recorded in\n `QUEUE.md:6-9`. Grew from 3 parts (5 Aug) to 11 (7 Aug) to 13 present now.\n15. **`handover/TheDogsSpot-AllMessages.pdf`, `TheDogsSpot-First3Weeks.pdf`** — Not opened (outside\n the required list). Names and cross-references in `SEND-TO-KIM.txt:11` and `REPLY-AUG5.txt:15`\n suggest First3Weeks = the short customer-nurture attachment (six pages) and AllMessages = \"the\n longer companion with all forty-one\" messages — **CLAIMED/inferred only, not verified by direct\n read.**\n16. **`DATA-PULL-evidence/bridge_journal_dump_2026-08-09.json`** — Read directly (outside the\n required list, for cross-check). Contents are the literal word \"forbidden\" — corroborates\n `QUEUE.md` item 11's account of a blocked admin-dump route. VERIFIED.\n17. **Referenced but absent from this restore tree — checked directly, not found**:\n `handover/Before-the-walkthrough-with-Kristian.pdf` (cited `SWEEP-7-AUG.md:49`),\n `handover/Puppy-tagging-candidates.xlsx` (cited `PLAN-TO-FINISH.md:80,132`),\n `handover/NURTURE-REVIEW-FOR-KIM.md` (cited `PLAN-TO-FINISH.md:117`),\n `handover/TheDogsSpot-Friday-Report-7-Aug-2026.pdf` (cited `RESUME.md:31`),\n `DELIVERY/ENDPOINTS.md` (cited `RESUME.md:99`), and a document referred to only as **\"the master\n handoff\"** (cited `PLAN-TO-FINISH.md:104,164`), never named more specifically anywhere in the set.\n None exist anywhere under `/home/claude/restore` at time of mining — confirmed with `find`.\n18. **`handover/UPWORK-THREAD-FULL-9AUG.md`** — Named in the mining brief as \"if present.\" Confirmed\n absent.\n19. **Top-level `.md` files besides `QUEUE.md`** — none exist; confirmed with `ls /home/claude/restore`.\n20. **`engine/*.ts`, `build/*.js`, `scripts/*.mjs`, `tests/*.mjs`, `watchdog/*.ts`, `reports/*.html`**\n — the actual product code, tests, and rendered output the handover docs describe. Not part of\n the required reading list and not mined in full; noted only for completeness. A targeted grep of\n `reports/*.html` for \"retainer\" returned nothing, supporting Section 1's conclusion.\n\n\n\n=====FILE reports/money-page.html =====\n\n\nThe Dogs Spot, where the money is\n\n
\n\n
Where your money is, and what is missing
\n
Every figure read straight from your systems on Sunday 9 August 2026. Nothing here is typed from memory or carried over from an older report. Where a number cannot be verified it says so instead of guessing.
\n\n
\n
$17,564.00
\n
Square money that completed and reached your CRM. $16,117.00 of it can be placed on a booking today. The remaining $1,447.00 cannot, and it is two different problems, not one. Both are set out below.
\n
\n\n
The money Square has sent across
\n
\n
Completed
$17,564.00
36 payments. Real money, landed.
\n
Still pending
$3,711.55
28 payments. Not yours yet, and worth a look.
\n
Failed
$3,305.00
5 payments. Someone tried to pay you and could not.
\n
\n
\n
\n \n \n \n
\n
\n Completed, 71.5%\n Pending, 15.1%\n Failed, 13.4%\n
\n
69 Square payment records in total, $24,580.55 across all three states. Every one of them carries a customer id, so the matching itself works. Eight are booked to a single nameless point of sale record rather than to a person, which is what a counter sale looks like when nobody took a name.
\n
\n\n
The gap, in one sentence
\n
\n
The payment lands as a note on the customer's file, and nothing ever writes the amount onto the booking. The booking is the only place a report can add money up from.
\n
That is the whole reason this page can show you what you spent but not yet what you earned. It is not a missing integration and it is not your team. It is one field that nobody fills in.
\n
\n\n
What your bookings currently carry
\n
\n
Customer records
1,516
1,515 in Customer and 1 in Won and Paid.
\n
Carrying a price
53
3.5% of them. The other 1,463 are empty.
\n
Their total
$166,235.00
Every one last touched on 30 June. Nothing since.
\n
\n
\n \n \n \n \n \n \n \n \n
Program price on the record Records Value
$3,295 39 $128,505.00
$2,395 11 $26,345.00
$3,795 3 $11,385.00
All valued records 53 $166,235.00
\n
Those 53 are the proof it can work. Somebody put prices on them once, on or before 30 June, and then it stopped. Six weeks of bookings since carry nothing.
\n
\n\n
What happens the moment the amount gets written
\n
\n
Your rule, run against every payment you have. 36 completed payments, worth $17,564.00.
\n \n \n \n \n \n \n \n \n \n
What happens to it Payments Value
Places itself. One booking open, so the money goes straight on it. 15 $7,880.00
Needs one of your team to pick. More than one booking open. 0 $0.00
Already has a value on the booking, so it is left alone. 15 $8,237.00
Cannot be placed, and it is two different problems. Three arrived against a record with no name on it at all. The other three name a real customer who has no card in your Customer column to put the money on. 6 $1,447.00
All completed payments 36 $17,564.00
\n
Nobody has to do anything. You asked for a short list where a customer has more than one booking open so your team can pick the right one. Counting the bookings that matter, the ones in your Customer column, that list is empty today, so the second half of your rule never fires and no member of your team is asked to do a thing. If we ever widened it to count cards on your other boards, such as the review board, it would stop being empty, which is exactly why it is not widened.
\n
Money recorded against bookings goes from $166,235.00 to $174,115.00 the moment it runs.
\n
One thing to be exact about. Two of those 15 payments belong to the same customer and the same booking, so 15 payments fill 13 bookings, not 15. They have to be added together rather than written one over the other, and today the code would write one over the other. That is being fixed before anything is switched on, and until it is, treat the figure above as the target rather than the guarantee.
\n
\n \n \n \n
\n
\n Places itself, 44.9%\n Already valued, 46.9%\n Never placeable, 8.2%\n
\n
\n
\n
Being straight about the first number you will see. This can only place money it can match to a person, so revenue starts at roughly 45 percent of completed Square money and climbs as matching improves. That percentage will sit on this page every time you open it, so a low figure is never a surprise and never a mystery.
\n
And it cannot damage anything. It only ever fills a booking that is empty. Where a booking already carries a value, whoever put it there, it is left exactly as it is. It never overwrites, and every write it makes is logged with the payment it came from.
\n
\n\n
Two things worth knowing that nobody asked about
\n
\n
178 review requests went out. 138 of them are still waiting for an answer that will never come.
\n
Your review workflow sends the one to ten text and then waits for a reply with no time limit set, so anyone who does not answer sits in Survey Requested forever. 40 people did answer: 37 gave you a 10 and were sent the Google review link, 2 scored between 1 and 6, and 1 scored between 7 and 9.
\n
The last step, tagging the card once you know what they wrote, is a manual one. The 5 Star, 4 Star and Bad Review columns all hold zero, so it has not been done yet. That means 37 people were asked for a Google review and there is no record of who actually left one.
\n
\n
\n
Nobody is being asked twice. That question is now closed with a number.
\n
You have two review workflows and they fire on different tags. 118 people carry the first tag, 2 carry the second, and nobody carries both. The newer one is the better of the two: it reads the reply properly and raises a task for a team member when somebody is unhappy or asks a question. The older one, which 118 people went through, has no such step, so an unhappy answer gets an automatic message and nobody is told.
\n
\n\n
\n Where every number on this page comes from.
\n Payments: your CRM's own payment records, filtered to provider Square, all 232 rows read and 69 matched, 9 August.
\n Bookings and prices: every record in the Customer and Won and Paid columns, 1,516 of them, read page by page rather than sampled, 9 August.
\n Review pipeline: the count of cards in each column of your Review pipeline, read the same day.
\n Tag counts: your CRM's contact search, counted for each tag and for both together.
\n Nothing on this page was rounded, estimated, or carried over from an earlier report.\n
\n\n
\n\n\n\n=====FILE reports/square-revenue-explainer.html =====\n\n\nThe Dogs Spot, how Square money reaches your reports\n\n
\n\n
How Square money reaches your reports
\n
Before and after, in plain steps. Every figure read from your own systems on Monday 10 August 2026.
\n\n
\n
The short version.
\n
Your Square money already arrives in your CRM and it already knows whose money it is. What has never happened is the last step: writing the amount onto the booking. Reports add money up from bookings, so a booking with an empty amount box counts as zero, which is why your revenue reads near nothing while the money plainly exists. That is one field, and it is the whole gap.
\n
\n\n
1. What happens today
\n\n
\n
1
A customer pays. Two ways, and they behave differently.
Either your team raises an invoice in the CRM and the customer pays it by card, which runs through Square behind the scenes, or somebody pays at the counter directly in Square.
\n
\n\n\n\n\n\n\n\n
Route Payments What it carries
Invoice raised in the CRM, paid by card 56 Arrives already attached to the customer. This is most of your real revenue.
Order form and manual charges 12 Same, attached to the customer.
Counter sale in Square with no name taken 8 Files against one nameless record. Nothing can ever place these.
\n
\n
2
The payment reaches your CRM and gets written onto the customer's file as a note. This part works and has done since 13 July. 69 Square payment records so far, and every single one carries a customer id.
\n
\n
3
Nothing writes the amount onto the booking. This is the missing piece. The note sits on the person. The booking, which is the card on your pipeline board, still has an empty amount box.
\n
\n
4
Reports add up from bookings, so they add up empty boxes. Revenue reads near zero. Return on ad spend cannot be worked out at all, because it is revenue divided by spend and the revenue half is missing.
\n
\n\n
\n
Where you stand right now.
\n
\n
Completed Square money
$17,564
36 payments, all landed.
\n
Bookings carrying a price
53
Of 1,516. The other 1,463 are empty.
\n
Their total
$166,235
Every one last touched 30 June.
\n
\n
Those 53 are the proof the field works. Somebody filled it in once, on or before 30 June, and then it stopped. Six weeks of bookings since carry nothing.
\n
\n\n
2. What happens once the reconciliation runs
\n\n
\n
1
It reads every completed Square payment and finds the customer it belongs to. It already can: every payment carries a customer id.
\n
\n
2
It looks at that customer's open bookings, meaning cards in your Customer column with an empty amount box, and applies your rule exactly as you wrote it.
\n
\n\n\n\n\n\n\n\n\n
What it finds What it does
One open booking Writes the amount on. No person involved.
More than one open booking Puts it on an exception list for your team to pick. It never guesses.
No name on the payment Reported separately as unplaceable. Never guessed at.
Booking already has a price on it Left exactly as it is. It never overwrites anybody's number.
\n
\n
3
Every write is logged with the payment it came from, so any number on any report can be traced back to a card transaction.
\n
\n
4
Revenue becomes real. Your reports add up the amount boxes and get a number you can check against your bank.
\n
\n
5
Return on ad spend follows, on the Facebook side first. Facebook spend is already read live and automatically. Google spend is still typed by hand, so Google return on ad spend waits on that being connected properly.
\n
\n\n
\n
Run against every payment you have today, here is exactly what would happen.
\n\n\n\n\n\n\n\n\n\n
Outcome Payments Value
Places itself. One booking open. 15 $7,880.00
Goes to the exception list for your team to pick. 0 $0.00
Booking already priced, so left alone. 15 $8,237.00
Cannot be placed, reported separately. 6 $1,447.00
All completed payments 36 $17,564.00
\n
Your exception list is empty today. Not one customer is currently sitting on more than one open booking, so the second half of your rule never fires and nobody on your team is asked to do anything. That is counting the bookings that matter, the ones in your Customer column.
\n
Money recorded against bookings goes from $166,235.00 to $174,115.00 the moment it runs. Two of those 15 payments belong to the same customer and the same booking, so they get added together rather than one written over the other, which means 15 payments fill 13 bookings.
\n
\n\n
\n
Being straight about the first number you will see.
\n
This can only place money it can match to a person and a booking, so revenue starts at roughly 45 percent of completed Square money and climbs as matching improves. That percentage sits on the page every time you open it, so a low first month is never a surprise and never a mystery.
\n
\n\n
3. What your staff actually have to do
\n\n
\n
Nothing routine. Here is the honest list.
\n\n\n\n\n\n\n\n\n
Task Who How often
Take a name at the counter when somebody pays without one. Front desk Only fixes future payments, not past ones. Eight so far have no name.
Pick the right booking when a customer has more than one open. Whoever you nominate Zero times today. The list is empty.
Moving cards into Customer Nobody Already automated. Noted, and thank you for the correction.
Anything else Nobody The rest is automatic.
\n
\n\n
The corrected unmatched figure you asked for
\n\n
\n
You were originally told 42 counter sales worth $33,535.99 could not be matched. That was wrong and it was our error. The code that produced it only ever looked at the first attempt to match a payment, so a payment that matched successfully on a later attempt stayed on the unmatched list permanently.
\n
Corrected and re derived from raw:
\n
\n
Genuinely unmatched
33
Counter sales, not linked to a name.
\n
Their value
$22,651.99
Overstated before by $10,884.00.
\n
Have a partial trail
4
$2,829.99. Something to work with.
\n
Nothing at all attached
29
$19,822.00. No name, email or phone.
\n
\n
Why this is a different number from the $1,447 above, and both are right. The $1,447 is completed payments your CRM has a record of that cannot be placed on a booking. The $22,651.99 is everything the till has taken, including counter sales that never became a CRM payment record at all. The till list is the bigger one because it sees more. They answer two different questions and it is worth keeping both.
\n
\n\n
\nWhere every number here comes from.
\nPayments and routes: your CRM's own payment records, all 233 rows read, 69 matched to Square, 10 August.
\nBookings and prices: every record in the Customer and Won and Paid columns, 1,516 of them, read page by page rather than sampled.
\nCounter sales: the Square bridge journal, read the same day, after the calculation error above was corrected.
\nNothing here was rounded, estimated, or carried over from an earlier report.\n
\n\n
\n\n\n",[604],"e55ff72e-e500-475d-b214-fe01f4232a7e","SOURCE-BUNDLE.part33.txt","89c3c018-97ea-11f1-8d7d-1607ee4eb77e",1082,["D",1786801891147],"THE DOGS SPOT — SOURCE BUNDLE (part 33 of 40)\n\nEVERY source file in this project, engine/ included. Restoring these parts and nothing else gives\nyou a tree that builds, typechecks and runs its own test suite with no network and no val.\n\nengine/ is here as of 14 Aug 2026. It used to be left out because val 1bfa6e81-74e1-4c6c-ab32-118304a4ffff\nholds it, which was true of every engine file except engine/watch.ts: a module the val does not run,\nso it was never deployed, so it lived in one container and nothing else. A reclaim destroyed it.\nscripts/deploy.mjs --check still compares engine/ against the val file by file; that is a second\ncheck on the same files now, not the only copy of them.\n\nRESTORE (needs only node, from an empty folder). Save each part, then run this ON EACH ONE:\n\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n\nA record named #1, #2, ... is one FILE cut into pieces: concatenate them in order, then\nstrip one trailing newline from the last. scripts/restore.mjs does this for you.\n\nEach part is complete in itself: whole files only, no reassembly, any order.\n\nThen: node scripts/build.mjs (engine/ came out of these parts; nothing to fetch first)\n node scripts/typecheck.mjs\n node tests/run-all.mjs\n node scripts/deploy.mjs --check (pulls nothing, proves the val matches what you restored)\n node tests/negative-controls.mjs (proves the suite above can actually fail)\n\nIN THIS PART (3 of 116 files)\n\n QUEUE.md 8642 bytes 24fa22200326\n MINED-OLD-TREES.md 39728 bytes 1f51980a1c1e\n\n================================================================================================\n=====FILE HANDOFF.md#2 =====\n\n, defaults to `nurture - puppy`), `SEND_WINDOW_START_HOUR` and `SEND_WINDOW_END_HOUR` decide whether anything sends at that hour at all, and `SMS_SUNDAY_OK` decides whether Sunday sends. See the environment list in §4.\n **The surge hold is the likeliest way go live day looks broken.** `ENROLL_SURGE_THRESHOLD` defaults to **25** (`:82`). If turning her tagging on back-fills more than 25 un-enrolled contacts in one run, the engine **enrols nobody** and logs `ENROLLMENT SURGE HELD` (`:1083`), waiting for a human to remove the bulk tags or set `ACKNOWLEDGE_SURGE=true`. She takes around 160 inquiries a week, so a back-fill is likely. **Grep the run log for `ENROLLMENT SURGE HELD` before you go hunting for a foreign sender defer.**\n **Timing:** `main.ts` runs on a val.town interval. The period is not in the val's API, but the engine records its own passes: `api?k=&f=json` returns a `history` array, and on 9 August those passes were **an hour apart** **[V]**. So assume hourly, and confirm from that history rather than from the val. Forcing a pass by hand means calling `run` for real, which after go live is a real send pass.\n **A deferred send is not a broken send.** The foreign sender quiet period holds back anyone who has had an outbound message from anything other than this engine, and 95 published workflows plus Chloe plus Ava touch these people. If nothing sends, look for a defer in the run log before assuming failure.\n **Rollback. Four steps, and the first one is the only immediate stop:**\n 0. **Hit the kill switch, and here is the exact URL, because an earlier version of this file said \"the control panel\" without saying which of the eight routes that is.** It is the **`api`** route: `https://amir5--ad633fec8e7311f1b8001607ee4eb77e.web.val.run?k=&stop=1` to stop, `&go=1` to clear **[V]** `engine/api.ts:26`. **It is not on Kim's dashboard page**, which carries no STOP link at all. The engine checks the switch first and it fails open: `puppy_path_v1.1.ts:997` reads the `nurture_kill` blob before anything else. **Do this first, because the interval is hourly** (the run history in `api?k=&f=json` shows passes an hour apart **[V]** 9 Aug), so `TEST_MODE` alone leaves up to an hour of live sending.\n i. Set `TEST_MODE` back to `true`. Effective next run; the send guard fails closed.\n ii. **Switch her old workflow back on.** Leaving it off is a silent hole in her customer communication that nobody would notice.\n iii. **Turn the tagging back off**, or contacts keep entering a path that no longer sends.\n The sanctioned test contact is resolved at runtime by `resolveTestDummy()` and is the record carrying Amir's own email address, `puppy_path_v1.1.ts:953` **[V]**.\n9. **Holiday deposit made required.** She approved it. Show her before it is live.\n10. **The overlap review** and the **Pups Club unsubscribe** can both be done now. Neither is inside the freeze and nothing blocks them except nobody starting. **Tag cleanup**, the **Free Training Day rebuild** and the **two calendars** wait on the freeze lifting, which waits on Kristian's **QA documentation** — a different thing from the **answer** item 2 asks him for.\n11. **Google Ads.** Needs a developer token, about five business days by Google's own estimate. Consider telling her the Google half stays manual.\n12. **Review pipeline.** 138 of 178 cards stuck in Survey Requested because the wait has no timeout. Nobody has ever done the manual tagging step, so 5 Star, 4 Star and Bad Review all hold zero. **[V]**\n\n---\n\n## 12. GLOSSARY AND MAP\n\n**People**\n- **Kim Hicks** — the client. Sole approver. Signs herself **Kim Tome-Hicks**; both are her.\n- **Amir Aizhigitov** — the contractor. Sends everything. We draft, he sends.\n- **Kristian Moore / Moore Cre8ive** — separate contractor, $11,500 fixed price, built the app and Chloe, months late, currently in acceptance QA.\n- **Milton** — built the boarding portal Kim actually relies on. Not adversarial.\n- **Candice** — new staff member, started ~2 August. The second Pup Talk calendar is for her.\n- **Emily** — staff, monitors the inbox.\n- **Laurice Eclipse** — a name on two private integration tokens in her CRM. **[U]** who this is.\n- **Automation Dogs** — the original agency that set up her CRM. **[C]**\n\n**Not people**\n- **Chloe** — the AI voice agent that answers her phones. Kristian's build, lives in GoHighLevel.\n- **Ava** — an automated Facebook and Instagram reply bot. Amir's.\n\n**Terms**\n- **Pup Talk** — her name for the consultation call. Never call it a discovery call.\n- **Opportunity** — a deal card on a pipeline board. Has a **stage**, the column it sits in, and a **monetary value**, a dollar box that is almost always empty.\n- **The Customer stage** — where a paying customer's card ends up. What our reporting counts.\n- **Practice mode / TEST_MODE** — the engine flag that stops any real customer being messaged.\n- **The freeze** — see §10.\n- **The card page** — Kim's status page, the `dashboard` route.\n- **The bundle** — the `SOURCE-BUNDLE.partN.txt` files on the val. The disaster recovery path. **16 parts, 56 files, as at 9 August** **[V]**. It was 13 parts on 8 August and 14 earlier on 9 August, and the day it grew is the day a session restored an incomplete tree. It holds **almost** everything that is not already on the val: what it does not hold is named in §13, and that list is short on purpose. The count grows with the repo, so list the val's files rather than assuming a number.\n- **Ava** and **Chloe** are both bots, not staff. See **Not people** above. If a message from Kim mentions either by name she is talking about software.\n\n---\n\n## 13. WHERE EVERYTHING LIVES\n\n**Source of truth, current**\n- `/home/claude/restore/` — the repo. **125 files = 56 bundled + 23 engine + 27 `build/` + 16 bundle parts + 3 backed up nowhere.** The engine lives on the val, not in the bundle. `build/` is generated by `scripts/build.mjs` and never edited by hand. The three unprotected files are the two derived PDFs in `handover/` and a 9 byte evidence dump; losing them costs nothing. **[V]** counted 9 Aug.\n- `HANDOFF.md` — this file. **At the repo root and nowhere else.** It existed twice for part of 9 August, root and `handover/`, and the bundle carried the stale one. `bundle.mjs` now refuses to run if a second copy appears.\n- `QUEUE.md` — everything outstanding, ranked. Rewritten 9 Aug. **Bundled since 9 Aug**; before that, the one file §1 tells you to open did not survive a reclaim.\n- `handover/AWAITING-AMIR.md` — everything needing Amir, with exact steps. **Bundled since 9 Aug**, with a copy in `/mnt/user-data/outputs/`.\n- `reports/money-page.html` — the **source** for Monday's deliverable. **Bundled since 9 Aug.**\n- `/mnt/user-data/outputs/TheDogsSpot-Money-Page.html` — Monday's deliverable, generated from the above.\n- `/mnt/user-data/outputs/OCCUPANCY-EVIDENCE-10-Aug.pdf` — 171 versus 24, for the Kristian retest.\n- `/mnt/user-data/outputs/APP-TAKEOVER-ASSESSMENT.md` — what taking over his app requires.\n- `MINED-OLD-TREES.md`, `MINED-HANDOVER.md` — the raw mining behind this document, and the only receipts behind §3, including the Upwork contract number. **Bundled since 9 Aug.**\n\n**Superseded, read for history only**\n- `handover/PLAN-TO-FINISH.md` (5 Aug), `handover/REGISTER-AUG5.md`, `handover/AUTOPILOT.md`. Their test counts and percentages are all lower than current.\n- `handover/RESUME.md` (7 Aug) is **superseded on status, and it holds no key at all.** An earlier version of this file called it the only recorded home of the admin key and Kim's view key; it is neither. Its only credential line is a pointer to `DELIVERY/ENDPOINTS.md`. **[V]** grepped the whole repo 9 Aug. Kim's view key is in `handover/REPLY-AUG5.txt`, bundled and recoverable; the admin key is only in the old tree, unbacked. See §4. Keep RESUME.md for the deposit refresh evidence, read it as history.\n- `handover/REGISTER-AUG7.md` and `handover/SWEEP-7-AUG.md` — stale on status, but the **best source for Kim's verbatim voice rules**.\n- `/home/claude/dogsspot/` (135 files, ~4 Aug) — the previous tree. Best source for commercials and early decisions.\n- `handover/DEPOSIT-SPEC.md` — an engineering log, 15 adversarial rounds. Ends \"IN FLIGHT, NOT CLEAN\".\n\n**Keep `/mnt/user-data/outputs/` in sync or do not write to it.** On 9 August the copy of this file there went stale within the hour and still told a reader to fetch 13 of 16 bundle parts, which is exactly the accident the rest of this section is about. `bundle.mjs` guards the repo against a second handoff; it cannot see that folder. **After any edit to this file, re-copy it, or delete the copy.**\n\n**Disaster recovery. Executed end to end on 9 August after the tree was lost, and it worked [V]** — with one honest caveat: it worked partly because `/home/claude/dogsspot/` happened to survive that reclaim, and that is where the admin key lives. **This procedure does not restore the admin key.** If it is gone, stop and get Amir. See §4 and `QUEUE.md` item 0.\n\n**It needs no credential.** Both `api.val.town` endpoints below answer **HTTP 200 with no Authorization header** **[V]** tested 9 Aug. This is about the **file API only**, and about raw HTTP. The `web.val.run` routes in §4 still need `?k=`, and that key is the thing that does not survive a reclaim. `scripts/restore.mjs` also refuses to start without a val.town token even though none of its fetches need one; step 5 says how to get past that. This matters: the **val.town** token lives inside `scripts/deploy.mjs`, which is inside the bundle, so if the fetch needed a credential the recovery would be circular and impossible. It does not. (The GoHighLevel token is **not** in that file; §4 has the corrected list.)\n\nVAL = `1bfa6e81-74e1-4c6c-ab32-118304a4ffff`\n\n1. **Fetch every bundle part**, no auth:\n `https://api.val.town/v2/vals/VAL/files/content?path=SOURCE-BUNDLE.partN.txt`.\n **Do not assume how many there are.** It went 13 on 8 August, 14 and then 16 on 9 August, and the day it grew is the day a session restored an incomplete tree. List first:\n `https://api.val.town/v2/vals/VAL/files?path=&limit=100&recursive=true`, take every name matching `SOURCE-BUNDLE.part*.txt`, fetch all of them.\n2. **Unpack, ONE PART AT A TIME. Here is the unpacker, in full, because this is the one thing that has to work when nothing else does.** Save a part as `PART.txt` and run this from the folder you want the repo in:\n\n ```\n node -e 'const fs=require(\"fs\"),p=require(\"path\");const b=fs.readFileSync(process.argv[1],\"utf8\");\n for(const s of b.split(\"\\n=====FILE \").slice(1)){const i=s.indexOf(\" =====\\n\");\n const f=s.slice(0,i),c=s.slice(i+7);fs.mkdirSync(p.dirname(f),{recursive:true});\n fs.writeFileSync(f,c.replace(/\\n$/,\"\"))}' PART.txt\n ```\n\n Each part is plain text. Files are separated by a line that reads exactly:\n `=====FILE =====`\n Everything after that line, until the next such line, is that file's content, minus one trailing newline. Every part is self contained, whole files only, and parts may be unpacked in any order.\n **Never concatenate the parts and split the result.** Each part carries its own header block, so the header glues onto the end of the previous part's last file and five suites come back with `SyntaxError: Unexpected identifier 'DOGS'`, which is the bundle's own title text sitting inside a test file. That happened on 6 August. The instructions inside the bundle said per part and were not read.\n3. **Stitch split files.** A record named `#1`, `#2` is one file cut in pieces. Concatenate in numeric order and delete the numbered records.\n4. **Pull the engine back**, no auth. List with\n `https://api.val.town/v2/vals/VAL/files?path=&limit=100&recursive=true`, then fetch each `.ts` by the same content URL into `engine/`. **Rename `main.ts` to `puppy_path_v1.1.ts`.** Also fetch **`NOTES-v1.4.md`**: it is a `file` on the val, not a `.ts`, so a filter on `.ts` skips it, and it is where overflow comments from `main.ts` are supposed to go when that file hits its cap.\n5. **Unpack into `/home/claude/restore`.** Every path in the bundle is relative to that directory. **There IS an unpacker: `node scripts/restore.mjs`.** It does steps 1 to 5 in one command and it already knows the per part rule. `--check` restores to `.restore-check/` **inside the repo** and diffs, changing nothing real, but it does leave that directory behind; delete it after.\n **On an empty machine, hand unpack `SOURCE-BUNDLE.part10.txt` first.** It holds **both** `scripts/restore.mjs` and `scripts/deploy.mjs`, which matters because `restore.mjs` reads its val.town token out of `deploy.mjs` and exits 1 without one. Every fetch it makes would work unauthenticated; it just refuses to start. Get part 10 down by hand with the snippet written out in step 2, then run the tool. Do not guess part 1: part 1 holds test files.\n6. **Check what you got against the manifest, which does exist.** Every part opens with `IN THIS PART (n of 56 files)` and then one line per file: path, a count, and the first twelve hex of its sha256. **Verify the sha, not the count.** The column says \"bytes\" and is actually **characters**, so any file carrying an em dash or a curly quote will not match `wc -c` and that is not corruption. This is the same characters versus bytes confusion §9 records for `main.ts`; it is in the bundle header too and nobody had noticed. `restore.mjs` additionally carries a `MUST_EXIST` list and names any file that is missing, but it **warns and does not exit**, so read its output rather than its exit code. **And that list is short:** it names test files, four scripts and `handover/DEPOSIT-SPEC.md`, and it does **not** name `HANDOFF.md`, `QUEUE.md`, `handover/AWAITING-AMIR.md` or `reports/money-page.html` — the four this section calls irreplaceable. Check those four by hand until somebody adds them to that list. **[V]** read 9 Aug. Note `restore.mjs` pulls `.ts` **and** `.md` from the val into `engine/`, so you end with **56 bundled + 23 `.ts` + `NOTES-v1.4.md` + `REGISTER-AUG5.md` = 81 files**, plus whatever `build/` you generate. `deploy.mjs --check` only compares the **engine**, so it cannot detect a missing test, script or document.\n7. **Dependencies.** There is no `package.json`, no `node_modules` and no Python manifest of any kind. `scripts/build.mjs` calls esbuild through `npx --yes esbuild`, so **steps 8, 9 and 11 need node and network and nothing else** **[V]**. **Step 10 additionally needs `python3` and `reportlab`** (`pip install reportlab --break-system-packages`), because `make-pdfs.mjs` shells out to `scripts/make_pdf.py`. `scripts/occupancy-evidence.py` and `scripts/blueprint.py` are Python too. Nothing in the repo records this, which is why it is recorded here.\n8. **`node scripts/build.mjs`.** This is the TypeScript compile step, `engine/*.ts` into `build/*.js`, which the test suites import. It is a different script from `scripts/bundle.mjs`, which creates the backup. Recovery uses `build.mjs`; snapshotting uses `bundle.mjs`.\n9. **`node scripts/deploy.mjs --check`.** It must print \"live matches local, every file\". This compares local against the **live val**, so it proves the restore matches production, not that production is correct.\n10. **`node scripts/make-pdfs.mjs`.** Regenerates the two PDFs the cross artifact suite reads. Without them that suite is red.\n11. **`node tests/run-all.mjs`**, then `node tests/negative-controls.mjs` in the background.\n\n**What this does NOT restore.** `/mnt/user-data/outputs/` is outside the repo and is **not in the bundle**. Six files were moved inside on 9 August after a cold read found them unprotected: `HANDOFF.md`, `QUEUE.md`, `handover/AWAITING-AMIR.md`, `reports/money-page.html` and the two `MINED-*.md` files. A pending draft to the client, the queue the handoff points at, and the source of a deliverable due tomorrow are not derived artifacts, and losing them loses the work. **What is still unprotected, deliberately: the two PDFs in `handover/`, which `make-pdfs.mjs` rebuilds, and a 9 byte evidence dump.** `/home/claude/dogsspot/` is also unprotected, and §4 explains why that matters: it is the only home of the admin key. After the 9 August reclaim some files there survived and some did not **[V]** observed directly. Anything in that folder that matters must be reproduced. **Monday's money page has no generator and does not need one: it is a straight copy.** `cp reports/money-page.html /mnt/user-data/outputs/TheDogsSpot-Money-Page.html` — the two are byte identical, and the repo copy is the artifact. `scripts/occupancy-evidence.py` does regenerate the occupancy sheet. **If you produce a deliverable, put it or its generator inside the repo, because the repo is what the bundle carries and `/mnt/user-data/outputs/` is not.**\n\n\n\n=====FILE QUEUE.md =====\n# QUEUE — Sunday 9 Aug. Rebuilt after the container was reclaimed and the tree restored.\n# HANDOFF.md WINS ON EVERY NUMBER AND EVERY RANKING. This file carries history and detail; its\n# item numbers are its own and do NOT line up with HANDOFF section 11. Never cross reference the\n# two by number. Counts below that predate 9 Aug 22:00Z are left as written, because they are a\n# record of what was true at the time; where one is superseded it says so.\n# DONE carries its proof. OPEN carries its blocker and the routes already tried.\n\n## SUPERSEDED COUNTS IN THIS FILE, corrected once here rather than edited in place\n# \"12 bundle parts / 47 files\" -> now 16 parts / 56 files\n# \"17 suites, 380 assertions\" -> now 18 suites, 394 assertions, 0 failed, plus 203 negative controls\n# \"four asks\" for the nurture window -> the count was never checked against the thread; unknown\n# Kristian has NOT been asked whether his app writes opportunity values. Any line here implying\n# he answers at 11:00 on Monday is wrong: Monday 11:00 is KIM and AMIR, about the money.\n\n## ITEM 0 — TODAY ONLY, AND IT EXPIRES WITH THIS CONTAINER\n0a. THE NURTURE ADMIN KEY HAS NO BACKUP. It exists in exactly one file,\n /home/claude/dogsspot/DELIVERY/ENDPOINTS.md, which is in the OLD tree: not in the bundle, not on\n the val, not anywhere a reclaim survives. The engine stores only NURTURE_ADMIN_KEY_SHA256, so it\n cannot be read back out of code. Losing it dark-fires all seven ?k= routes including Kim's\n dashboard on the admin view, and the only way back is Amir setting a new digest in the val.town\n environment UI.\n -> IT CANNOT GO IN THE BUNDLE. The bundle is world readable: api.val.town serves every part with\n no Authorization header at all, verified 9 Aug. Putting a live key in it publishes it.\n -> ACTION FOR AMIR: copy it out of that file into his password manager, and say here that it is\n done. One minute. Nobody else can do this step.\n\n0b. THE WATCHDOG READ WRONG ONCE, AND THE FIRST DIAGNOSIS OF IT WAS ALSO WRONG.\n ** DO NOT CALL THE WATCHDOG ENDPOINT. Calling it is a full run: it sends email and it advances\n the alert checkpoint, which makes real bridge errors stop counting as new. See HANDOFF section 4.\n To inspect it, read its SOURCE unauthenticated:\n https://api.val.town/v2/vals/238d32db-e45f-493d-ae45-91cfa664542f/files/content?path=main.ts\n or read its own blob through the engine's api route with &f=json. **\n At 22:49Z on 9 Aug it returned the superseded 42 counter sales / $33,535.99 and asserted they were\n \"the same figures the dashboard shows\". The dashboard says 33 and $22,651.99.\n -> THE EARLIER ENTRY HERE SAID IT \"HOLDS ITS OWN COPY OF THE LOGIC\" AND TOLD YOU TO FIX THAT COPY.\n THAT IS WRONG AND FIXING IT IS THE TRAP. watchdog/main.ts:299 imports facts.ts from esm.town at\n runtime and calls the engine's own squareBacklog. The file holds no counter-sales arithmetic and\n contains ZERO occurrences of \"totalling\" or \"totaling\". Its val version has not moved since 5 Aug.\n Hardcoding a figure there creates the second source of truth the code comment at :295 exists to\n prevent, which is how a wrong number reached a client message in the first place.\n -> The two real causes: a stale cached unpinned esm.town import, which self heals, and a different\n INPUT, because :255 reads the m2_bridge_journal blob while the dashboard reads the live bridge\n dump. If it recurs, redeploy the watchdog val or pin the import, and make it read the same dump.\n -> It was called by hand TWICE on 9 Aug, 22:49:36Z and 23:14:26Z. Treat the alert window from\n 23:14Z as consumed.\n\n0c. THE LIVE GOHIGHLEVEL TOKEN WAS IN A WORLD READABLE BUNDLE. It sat in MINED-OLD-TREES.md and\n handover/PLAN-TO-FINISH.md, both bundled, both fetchable with no credential.\n -> REDACTED out of every repo file on 9 Aug and the bundle rewritten. Assume it was readable for\n some period. This is now the strongest argument for the key rotation, item 6 in HANDOFF section 11.\n -> Still exposed and NOT fixable by redaction: the val.town API token in scripts/deploy.mjs, and\n Kim's view key in handover/REPLY-AUG5.txt. Both are needed by the recovery path.\n\n## THE CRASH, AND WHAT IT LEFT\n0. The container was reclaimed mid session. /home/claude/restore was gone entirely.\n -> CLEARED. Production was checked first and was never affected: run endpoint answered at\n 2026-08-09T20:55:36Z with v1.7.1, testMode true, sent 0. Tree rebuilt from the 12 bundle parts\n on the val, 47 files, three split records stitched, engine pulled back from the val, and\n `deploy.mjs --check` then reported \"live matches local, every file\". No half state existed.\n\n## CLOSED TONIGHT, with production proof\n1. A restored tree came back RED, because two suites read files the bundle does not carry.\n -> DONE. money-truth now reads tests/fixtures/square-journal.json, which is committed and\n reproduces the six figures live on Kim's page exactly. PDFs regenerated by make-pdfs.mjs.\n Full suite GREEN: 17 suites, 380 assertions, 0 failed.\n2. THE BUNDLE ITSELF WAS DROPPING A DIRECTORY IN SILENCE. bundle.mjs read one level deep, so\n tests/fixtures/ was never included, which is why the restore came back red.\n -> DONE. The walk is recursive and .json fixtures are included. 47 files became 48, 51 records,\n round trip verified, pushed to the val (v491 to v503).\n3. British spelling reaching Kim on her own card page: \"counter sales totalling\".\n -> DONE. facts.ts and holiday-deposits.ts corrected, deployed v489 and v490, verified live at\n 2026-08-09T21:06:20Z: zero \"totalling\" on the page, one \"totaling\".\n4. Occupancy evidence for the 11:00 meeting.\n -> DONE. Both systems read within twenty minutes. Milton's portal 24 dogs in house against\n Kristian's 171, in a 50 kennel facility. OCCUPANCY-EVIDENCE-10-Aug.pdf.\n\n## OPEN\n5. The Square value write onto the opportunity, the one thing between here and revenue and ROAS.\n -> OPEN BY CHOICE, and the reason is now sharper. Kim asked tonight whether it can be reconciled\n automatically. It can. KIM ALREADY ANSWERED THE RULE QUESTION in writing on 9 Aug at 22:26Z and\n HANDOFF section 8 records it; do not ask her again, she objects to being asked twice. It is now\n held for ONE thing, plus one bug:\n (a) an email to Kristian that NOBODY HAS ASKED AMIR TO SEND, and\n (b) money-match.ts:76 overwrites instead of adding when one customer pays twice toward one\n booking: 15 AUTO payments land on 13 bookings, so the real total is $173,995 not $174,115.\n Fix before switching anything live. See HANDOFF section 9 and section 11 item 2b.\n SUPERSEDED LINE BELOW, left for the record: it says Kristian confirming\n application writes opportunity values. He has told Kim in writing that his app writes\n opportunities. Building before that answer risks two systems writing the same field.\n6. Nurture go live. Still 0 percent live, still waiting on a day and a window from Kim.\n -> Practice mode verified live at 20:55:36Z. The guard at puppy_path_v1.1.ts:904 fails closed.\n She has never named a time, across four asks.\n7. The four sending domain lines, and the key rotation.\n -> BLOCKED, needs Amir's login. The browser now holds his own agency session, and The Dogs Spot\n is not a sub account of it. Ten routes logged in the previous queue entry, all failed.\n8. Which processor the Wix Bootcamp form charges through.\n -> OPEN. Two minutes on the Wix payments screen.\n9. Google Ads is 20 percent, not 70. The connector is a stub that throws and discards its result.\n -> OPEN. Needs a developer token, about five business days by Google's own estimate.\n10. Two calendars, tag cleanup, Free Training Day rebuild.\n -> Correctly blocked by the Kristian freeze.\n11. The bridge journal dump.\n -> REOPENED 10 Aug: THE DUMP WORKS. ?dump=1&admin=, note the parameter is admin and NOT k, returns 760 journal rows.\n dashboard.ts is served by api.val.town with no Authorization header, so the secret is public.\n The line below is superseded and left for the record.\n -> Route closed and no longer needed. ?dump=1 requires a dedicated ADMIN_SECRET that is masked\n in the val UI and exposed by no API. Ten routes tried. Route nine won instead: the deployed\n card page carries the computed figures, which is what the dump was only a means to, and the\n committed fixture now pins them.\n\n\n\n=====FILE MINED-OLD-TREES.md =====\n# Mined from old working trees — dogsspot (~4 Aug), ghl (~2 Aug), tds_docs, NURTURE-MASTER-CONSOLIDATION\n\nScope read: all 135 files under `/home/claude/dogsspot/` (incl. `vault/`, `handover/`, `DELIVERY/`, `docs/`, `drive/`, `drive/slim/`, `drive2/`, `plan/`, `engine/`, `logs/`, `tests/`, two xlsx/pdf sets), all 24 under `/home/claude/ghl/` (raw GHL API pulls + 4 pull scripts), both `tds_docs/*.docx`, and `NURTURE-MASTER-CONSOLIDATION-2026-08-02.md`. `dogsspot/docs/*` is a byte-level subset of `dogsspot/DELIVERY/*` (verified via diff) — cited once, under DELIVERY. `dogsspot/build/*` (build artefacts) and `dogsspot/DELIVERY|engine/*.ts` bodies (source already in `/home/claude/restore/engine`) were not deep-read, only headers/decision-comments, per instructions. `drive/` + `drive/slim/` are the pre-correction predecessor of `drive2/`; `handover/DRIVE-CORRECTIONS.md` documents the diff exactly, so `drive/*` was sampled (one file in full) rather than read page-by-page. GHL's raw JSON dumps (contacts.json 8MB, opps.json 9MB, all.json 4.8MB, etc.) were opened and their structure/counts verified, not read record-by-record — the narrative numbers they back are already in the markdown docs and corroborated live (165 workflows/95 published, 29 calendars/24 active — both VERIFIED directly against the JSON).\n\n---\n\n## 1. COMMERCIALS\n\n- **VERIFIED** Retainer contract: **$700/mo** = Google $350 + Facebook $150 + GHL $200, \"running,\" **Upwork contract #44066641**. `/home/claude/dogsspot/DELIVERY/00_GROUND_TRUTH.md:78`\n- **VERIFIED** Contract name/history: Upwork **\"GHL Expert for Meta Pixel Integration,\"** started 10 Jul 2026 as a **$30 audit**, grown through milestones (**$150 milestone 5, paid**; **$350 milestone 6, active**). `/home/claude/dogsspot/vault/Client-Ops-Vault/Clients/Kim Hicks — The Dogs Spot/Profile.md:4`\n- **CLAIMED** These two are the same contract: NURTURE-MASTER states outright \"#44066641 ... is the $700/mo retainer with **3 unmerged recurring milestones**.\" `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:14`. No file explicitly maps m5/m6 to which of the three ($350/$150/$200) they are — treat as plausible, not confirmed.\n- **VERIFIED** Phase 1 Nurture price: **$1,850, one-time**, accepted by Kim in writing **25 Jul 2026**. Must go on a **NEW, separate** Upwork contract (not #44066641), **ONE milestone**, to be raised **\"WITH the puppy writing sheet, never cold.\"** `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:13-16`; corroborated `/home/claude/dogsspot/DELIVERY/00_GROUND_TRUTH.md:79` (\"Not yet on a contract\"). As of the newest dogsspot file (4 Aug), this contract had still not been created — action item repeated `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:207`.\n- **VERIFIED** What counts toward the $1,850 vs what doesn't: \"bridge, guards, task layer, hire manual, Square backfill, calendar repair, Meet & Greet fix — is **retainer work and counts $0** toward the $1,850.\" `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:17`\n- **VERIFIED** Full scoped-vs-delivered breakdown (six paths, 30-day min journey, SMS+email, reply detection, testing, batch release, docs) — only puppy path built as of 2 Aug; other five \"written; not built — deliberately.\" `/home/claude/dogsspot/DELIVERY/VALUE-RECEIPT-for-Kim.md:4-18`\n- **VERIFIED** Next revenue line, explicitly **not yet pitched**: **~$1,100/mo \"nurture-ops\"** line, planned for late Aug after the puppy path runs 30 days live. \"Kim asked for this herself. Do not pitch early, do not put a number on it yet.\" `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:18`\n- **VERIFIED** A dead figure never to resurrect: **\"$650–850 Messenger figure. Never sent, never resurrect.\"** No file explains what it was for — treat only as forbidden, not reconstructable. `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:19`\n- **VERIFIED** If Kim challenges the $1,850 price (do not volunteer): original scope ≈20 touchpoints, delivered ≈60+ across two channels — \"roughly triple the work.\" `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:21`\n- **VERIFIED** $150 one-off bonus paid 21 Jul, \"For Pups Club work / Keep up the good work!\" `/home/claude/dogsspot/DELIVERY/00_GROUND_TRUTH.md:66`\n- **VERIFIED** Milestone 6 ($350) is explicitly gated on an Amir action: flipping `tl_mode` to live on the front-desk task layer \"unblocks the retainer milestone chain.\" `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:141`\n- **CONTRADICTED** Notion says MRR **£500** and \"Phase 1 **£1,850**\"; the money file says **$700/mo** and **$1,850 USD**. Money file ruled canonical (\"written against the live Upwork contract\"); Notion is stale **and in the wrong currency**. `/home/claude/dogsspot/DELIVERY/00_GROUND_TRUTH.md:112-114`\n- **VERIFIED** Explicitly OUT of the $1,850 nurture scope: paid campaigns themselves, the nurture reporting layer, paths beyond six/seasonal campaigns, a rewrite of Kim's existing GHL workflows; content-writing is collaborative (Amir supplies architecture/writing sheets, Kim/her ChatGPT supplies voice), not solely Amir's. `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:37`\n- **VERIFIED (third-party contract, not Amir's)** Kristian Moore / Moore Cre8ive: **$11,500 fixed-price build**, signed **5 March 2026**, for the Operations Platform + Customer Portal + all three bot channels. Status date 21 Jul 2026, \"implementation complete, in QA,\" acceptance/signature page and 30-day warranty not yet started. `/home/claude/tds_docs/qa.docx` (table 0); `/home/claude/tds_docs/changelog.docx` (table 0). Relevant only as context Amir was drawn into for QA/acceptance prep, not Amir's revenue.\n\n---\n\n## 2. PROMISES MADE TO KIM (not obviously completed as of the newest file, 4 Aug)\n\n- **VERIFIED**, open: \"I can add a proper header and footer with the logo and your colours, **and I will**.\" Conditional on Kim sending a logo file/colours — no confirmation she did, or that it was built. 2 Aug. `/home/claude/dogsspot/handover/message-to-kim-COMBINED.txt:55`\n- **VERIFIED**, open: \"I'll work through the places the 823 number is still written into confirmations.\" 2 Aug, no completion evidence found anywhere later. `/home/claude/dogsspot/handover/message-to-kim-2.txt:20`\n- **VERIFIED**, open: promised to set `SHORT_BOOKING_LINK` env var (branded link swap) — blocked on an expired val.town token same session; no later file confirms it was done. `/home/claude/dogsspot/handover/READ-ME-AMIR.md:93`\n- **VERIFIED**, open: promised to re-deploy `puppy-messages.ts` with comment-only corrections once the token is back — no later confirmation. `/home/claude/dogsspot/handover/READ-ME-AMIR.md:94`\n- **VERIFIED**, conditional/open: offered to build a safe \"ask-questions-only\" ChatGPT-to-CRM assistant \"if you want it I'll build it properly and own it\" — no evidence Kim took this up. 3 Aug. `/home/claude/dogsspot/handover/reply-to-kim-aug3.txt:97`\n- **VERIFIED**, built but not delivered: taper/slow-track built and tested (24/24, later 41/41 in the full harness) — **\"DEPLOY BLOCKED: needs val.town token from Amir. Stays PRACTICE until Kim's word.\"** 4 Aug. `/home/claude/dogsspot/vault/Client-Ops-Vault/Clients/Kim Hicks — The Dogs Spot/Commitments Ledger.md:11`\n- **VERIFIED**, open: website typing chat assistant — \"Kim approved go-ahead ... Not started. Same val.town deploy dependency.\" `.../Commitments Ledger.md:13`\n- **VERIFIED**, deliberately held: 7 written questions for Kristian, staged — **\"hold until/unless that follow-up is sent.\"** Not sent as of 4 Aug. `.../Commitments Ledger.md:14`; `/home/claude/dogsspot/handover/SESSION-LOG-3-AUG.md:323-325`\n- **VERIFIED**, open: R27 (foreign-sender quiet period) and R28 (per-channel consent) engine fixes coded (\"banked from source\") but **not deployed** — blocked on val.town token. `.../Commitments Ledger.md:15`\n- **VERIFIED**, open: Kim never chose her go-live customer-facing number (912-348-8726 vs 912-823-4382) — flagged as \"re-raise before any go-live.\" `.../Commitments Ledger.md:16`\n- **VERIFIED**, open, low urgency: rotate the GHL Bridge token **Kim herself** pasted into the Upwork thread 31 Jul — still open 4 Aug. `.../Commitments Ledger.md:17`\n- **VERIFIED**, open: \"Raise the new Upwork contract with the $1,850 single milestone — only alongside the writing sheet, never cold.\" No confirmation this happened anywhere in the tree. `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:207`\n- **VERIFIED**, open: \"Flag the Day-14 aggression email in Path 2 for Kim's personal read before anything goes live\" — highest-risk message in the whole set; no confirmation Kim ever read it. `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:51,205`\n- **VERIFIED**, open: phone-number validation pass promised on the 3,206/3,426-contact list before Path 6 SMS is ever unheld (TCPA exposure). Not done in this tree. `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:157,206`\n- **VERIFIED**, open: promised Candice the who-is-waiting list on request (\"Reply to this email ... and I'll send it straight over\") — fulfillment not evidenced. `/home/claude/dogsspot/handover/email-to-candice.txt:81`\n- **VERIFIED**, open: \"one line to Kim closing the path-set discrepancy\" (free-training-day/past-clients/just-purchased swapped for behaviour/didn't-show/didn't-buy) flagged as owed — later session notes (`05_SESSION-2-BUILD.md`) argue the swap was already covered by a 31 Jul message, but no file shows the explicit one-line disclosure being sent. `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:203` vs `/home/claude/dogsspot/DELIVERY/05_SESSION-2-BUILD.md:71`\n- **VERIFIED**, promised/pending: boarding sequence flagged as \"probably the most valuable second one\" to build next — not started as of 4 Aug. `/home/claude/dogsspot/drive2/11_progress.html`\n\n---\n\n## 3. DECISIONS AND THEIR REASONING\n\n- **VERIFIED** Built as a val.town-hosted external engine calling the GHL REST API, **not** a native GHL workflow — because `POST /workflows/` and `GET /workflows/{id}` both 404, and the Workflows UI is an unscriptable cross-origin iframe. `/home/claude/dogsspot/DELIVERY/02_ARCHITECTURE.md:27`. **This reverses the plan in `NURTURE-MASTER-CONSOLIDATION-2026-08-02.md` §7-8**, which as of its compilation (2 Aug) still planned six native GHL workflows via GHL's \"Build using AI\" generator — see §6 below.\n- **VERIFIED** Copy lives in its own module (`puppy-messages.ts`), not inline in the engine — \"changing a sentence must never be a code change,\" also keeps files under val.town's 80k-char cap. `/home/claude/dogsspot/DELIVERY/02_ARCHITECTURE.md:28`\n- **VERIFIED** State lives in val.town blobs, not GHL custom fields — `/customFields` returns 401 on the production token; blobs need no extra scope. `/home/claude/dogsspot/DELIVERY/02_ARCHITECTURE.md:29`\n- **VERIFIED** Enrolment is human-applied tag, not auto-discovery — \"no puppy-vs-adult signal in the data ... guessing wrong means sending puppy-biting advice to the wrong person.\" `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:85-91`\n- **VERIFIED** Practice mode is the default; only the literal string `\"false\"` disarms it — \"the only unrecoverable action here is a live send nobody meant.\" `/home/claude/dogsspot/DELIVERY/02_ARCHITECTURE.md:31`\n- **VERIFIED** Reply-check fails **CLOSED** (send nothing if unsure) but kill-switch fails **OPEN** (keep running if storage hiccups) — deliberately asymmetric: \"not knowing whether someone wrote back and sending anyway is the one mistake you cannot take back\" vs. \"a storage hiccup must not silently halt the system forever.\" `/home/claude/dogsspot/DELIVERY/02_ARCHITECTURE.md:32,34`\n- **VERIFIED** State is written **after** a successful send, opposite of the sibling \"PupsClub\" val's write-before-send convention — reasoned explicitly: that val defends against a duplicate blast from an overlapping run; this one processes one contact at a time, so the real risk is \"marked sent\" with no network call ever landing. `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:164-170`\n- **VERIFIED** `[TEST]` prefix added to subject/SMS but deliberately **kept out of the email body** — keeps client-approved copy byte-for-byte verbatim while still making test sends unmistakable. `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:158-161`\n- **VERIFIED** Opt-out furniture appended by the **renderer**, never edited into the copy files — keeps approved wording verbatim, can't be forgotten on a future path, one-line to change. `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:211-220`\n- **VERIFIED** R27 \"foreign-sender quiet period\": engine defers (does not send) if it sees an outbound message on a contact that it did not itself send, because the location runs 95 published workflows (several literal \"Nurture\" workflows) plus Chloe and Ava, and GHL exposes no API to check a contact's workflow enrolment. **This is the single biggest structural guard in the build** — added specifically to avoid repeating \"how a Facebook script ended up answering Kim's website in July.\" Fails OPEN by design (unknown must not freeze the system). `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:314-329`; collision map with named overlapping workflows per path in `/home/claude/dogsspot/engine/paths.ts:76-172`.\n- **VERIFIED** R28 per-channel consent: switched from reading one top-level `contact.dnd` boolean to also reading `dndSettings.{channel}.status`, because live sampling found contacts opted out of SMS with `dnd:false`. A blocked step is **consumed, not deferred**, \"because deferring a message that can never legally send would stall that contact on it forever.\" `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:331-354`\n- **VERIFIED** Six-path substitution decision: kept the written six (puppy/behaviour/boarding/didn't-show/didn't-buy/aged) over the originally-scoped six (boarding/FTD/puppy/past-clients/gone-quiet/just-purchased) — reasoned as defensible (behaviour = biggest real demand signal at 172 asks; didn't-show/didn't-buy were Kim's own 26 Jul ask; FTD calendar looked dead) but flagged as **needing one disclosure line to Kim**, never confirmed sent. `/home/claude/dogsspot/DELIVERY/00_GROUND_TRUTH.md:104-106`. A later same-day note argues the swap was already covered by Amir's 31 Jul message to Kim and retracts the idea that anything is owed — **see §6, these two framings coexist unreconciled.** `/home/claude/dogsspot/DELIVERY/05_SESSION-2-BUILD.md:69-73`\n- **VERIFIED, reasoning for inaction** Chloe's after-hours schedule read as possibly wrong, but \"Amir has a theory ... and is not changing anything until he can prove it — changing it on a hunch could take her offline when she is needed.\" `/home/claude/dogsspot/drive2/03_live_pending.html`\n- **VERIFIED, reversed** Anyone-with-link Drive sharing was part of the original plan (as a typo-safety net) but was **deliberately not turned on**: \"the permissions API proved both addresses landed, so the thing it insured against cannot happen, and the pack contains candid notes about what is broken in Kim's business.\" `/home/claude/dogsspot/handover/AMIR_TODO.md:21`\n- **VERIFIED, walked back** Plan to read all 70 draft GHL workflows this week was retracted as \"over-promising\" in the same document that stated it; narrowed to 12 worth reading (high version numbers = finished-but-unpublished work). `/home/claude/dogsspot/plan/dogsspot-plan.html` (P2 section)\n- **CLAIMED** Recommended \"won\"-opportunity trigger = the $250 training deposit landing (unambiguous, already a payment event) — presented as a recommendation for **Kim to decide**, never confirmed accepted in these files. `/home/claude/dogsspot/plan/dogsspot-plan.html` (P1 section)\n- **VERIFIED** Path 6 (aged/cold backlog) launches **email-only**; SMS is held pending a phone-number validation pass — reassigned/dead numbers create TCPA exposure and carrier-flagging risk \"that would damage deliverability on every other path.\" `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:157-159`\n\n---\n\n## 4. TRAPS AND FAILURES\n\n**API / platform quirks**\n- **VERIFIED** GoHighLevel's API rejects Python's default urllib User-Agent with HTTP 403 — every working script sends `User-Agent: curl/8.5.0` (or a browser UA) instead. `/home/claude/dogsspot/handover/honour-optouts.py:42`; same pattern in all `/home/claude/ghl/*.py`.\n- **VERIFIED** Two different GHL `Version` headers are required depending on endpoint: `2021-04-15` for calendars/conversations, `2021-07-28` for contacts/opportunities. `.../Systems Map.md:9`\n- **VERIFIED** The production PIT token lacks conversation-messages read scope (401) — must read conversation-level fields instead. `.../Systems Map.md:9`\n- **VERIFIED** `/customFields`, `/locations/{id}/tags`, `/workflows/` (POST and GET), `/emails/builder`, `/users/` are all 401/404 on this token — no custom fields, no tag list, no workflow create/read, no email-template builder, no user list. `/home/claude/dogsspot/DELIVERY/00_GROUND_TRUTH.md` §6 Capability Ledger.\n- **VERIFIED** GHL's Workflows UI is a cross-origin iframe; synthetic clicks/scroll/keyboard do not land — only drivable by a human at a real keyboard. `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:129-131`; `/home/claude/NURTURE-MASTER-CONSOLIDATION-2026-08-02.md:116`\n- **VERIFIED** `/contacts/{id}/workflow` is 404 and the contact object carries no enrolled-workflow field — it is **structurally impossible** to check via API whether a contact is inside a native GHL automation. `/home/claude/dogsspot/engine/paths.ts:79-81`\n- **VERIFIED** Wix: the deposit price field hides inside the payment **form's own** settings (Form Settings → Payment → Item & Price), not site-wide settings — this is exactly why Kim and Milton couldn't find it. `/home/claude/dogsspot/handover/SESSION-LOG-3-AUG.md:9-14`\n- **VERIFIED** Wix edits can silently revert after closing the panel — the first $500 edit reverted to $250; fix was an explicit Enter+blur commit plus reopen-after-publish verification. `/home/claude/dogsspot/handover/SESSION-LOG-3-AUG.md:13-15`\n- **VERIFIED** Google Drive: same-filename uploads silently no-op with no error — must check timestamps. `.../Systems Map.md:32`\n- **VERIFIED** Google Drive API stopped allowing writes into subfolders after the 13th document in one session (no explicit error); root-level writes kept working. `/home/claude/dogsspot/handover/AMIR_TODO.md:12`\n- **VERIFIED** The Google account driving these docs is in a non-English UI (menu labelled \"Правка\") — Ctrl+H is not find/replace in that state. `.../Systems Map.md:32`\n- **VERIFIED** Upwork's ProseMirror composer: paste **appends** at the caret; `selectNodeContents` via JS does not reliably replace — must clear with cmd+a + Backspace first, or risk sending a near-duplicate message (this nearly happened once, caught by post-paste verification). `/home/claude/dogsspot/handover/SESSION-LOG-3-AUG.md:293-294`\n\n**Security / secrets**\n- **VERIFIED** val.town vals are **public by default** — anyone can read a deployed val's source with no token. The nurture admin key was a literal fallback string in four files (`api.ts`, `run.ts`, `aged.ts`, `paths.ts`) until rotated 2 Aug; the old key is confirmed dead on all four endpoints post-rotation. `/home/claude/dogsspot/DELIVERY/01_RISK_REGISTER_R2.md:10-16`\n- **VERIFIED** The old (now-dead) admin key was also printed in full inside the already-delivered manual PDF, which could reach \"the front desk.\" Rotation covers this going forward but the earlier exposure already happened. `/home/claude/dogsspot/DELIVERY/redteam_survivors.json` (id `stop-button-anyone`)\n- **VERIFIED** The live GHL PIT token (`pit-REDACTED-9-Aug-2026 (the live value is in the val environments and in /home/claude/dogsspot/, never in a bundled file: the bundle is world readable, see HANDOFF.md section 4)`, location `BQHJ19uohldYe3eqA0bl`) sits in **plaintext** in at least 6 files across both old trees: `/home/claude/dogsspot/handover/honour-optouts.py:40`, `/home/claude/dogsspot/tests/aged_audit.py:2`, `/home/claude/ghl/fetch.py:5`, `/home/claude/ghl/an1.py` (via its data file), `/home/claude/ghl/pull_contacts.py:3`, `/home/claude/ghl/pull_opps.py:2` — plus reportedly `DogsSpotMasterHandoff.pdf` and `DOGSSPOTMASTERPLAN.md` per `/home/claude/dogsspot/handover/AMIR_TODO.md:27`. Flagged repeatedly as needing rotation (\"this week,\" `AMIR_TODO.md:27`); **no file in either tree confirms it was ever actually rotated** — unlike the val.town admin key, whose rotation is proven.\n\n**Engine correctness / scale**\n- **VERIFIED** Un-indexed per-contact loop (contact + opportunities + conversations reads, plus a 120ms pace) costs ≈9,600–9,618 requests and ≈45 minutes per run at backlog scale (3,206+ contacts) — past val.town's execution timeout and GHL's daily cap; GHL answers sustained overload with 401/403 (looks like a dead credential), not 429. `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:11-25`; `/home/claude/dogsspot/DELIVERY/redteam_survivors.json` (id `poll-quota-blowout`)\n- **VERIFIED** Shipped defaults collide: `MAX_SENDS_PER_DAY` = 50 while the stated release cadence (a few hundred/week) implies ≈514/day — 10x the ceiling — and `ENROLL_SURGE_THRESHOLD` = 25 halts **all** enrolment above 25 candidates/run without a manual `ACKNOWLEDGE_SURGE=true`. `/home/claude/dogsspot/DELIVERY/redteam_survivors.json` (id `backlog-arithmetically-unreachable`)\n- **VERIFIED** TEST_MODE/practice mode skips the **entire enrolment code path** (discovery, surge-hold, tagging, per-population caps), not just sends — so \"30 tests passing in practice mode\" never exercised that logic against more than one dummy contact. `/home/claude/dogsspot/DELIVERY/redteam_survivors.json` (id `dry-mode-is-a-different-program`)\n- **VERIFIED** Dashboard's error/alarm tile matched event names the engine never actually emits (`failed`/`error` vs the real `send_failed`) — a run where every send failed would have rendered green. Fixed 2 Aug. `/home/claude/dogsspot/DELIVERY/01_RISK_REGISTER_R2.md:23-26`\n- **VERIFIED** Round-1 risk register claimed \"STOP wording present in the copy\" — **retracted same day as flatly wrong**: zero of 5 shipped SMS said STOP, zero of 7 emails had an unsubscribe line, before the render-time fix. `/home/claude/dogsspot/DELIVERY/01_RISK_REGISTER_R2.md:18-21`\n- **VERIFIED** Journal caps at 2,000 rows and terminal state prunes at 60 days, against a 4-year TCPA claims window — evidence needed to defend a \"you texted me after I said STOP\" complaint would already be gone. Flagged, not fixed as of these files. `/home/claude/dogsspot/DELIVERY/redteam_survivors.json` (id `evidence-destroyed-by-design`)\n- **VERIFIED** `contact.dnd` is a single top-level boolean; GHL actually tracks consent **per channel** in `dndSettings.{SMS,Email,RCS}.status`. Sampling found 4/100 contacts with channel-level opt-outs and `dnd:false`. Also: `TWILIO_ERROR_CODE 30006` (\"landline/unreachable\") can appear in `dndSettings.message` **with status still \"active\"** — that is a delivery diagnostic, not a refusal, and must not be read as consent. `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:334-347`\n- **VERIFIED** Position is stored as a raw array index (`lastMainStepSent`) — editing the copy sequence silently re-points every in-flight contact at the wrong message. Mitigated (made detectable, not fixed) 2 Aug. `/home/claude/dogsspot/DELIVERY/NOTES-v1.4.md:66-74`\n\n**Data / operational**\n- **VERIFIED** 29 contacts had texted the literal word \"stop\" and were never marked DND; 7 were still tagged into actively-sending published workflows. `/home/claude/dogsspot/handover/honour-optouts.py` header\n- **VERIFIED** 3 STOP-texted contacts (Steve Fishack, Tammy Castro, \"912-347-1620\") sat inside an already-delivered, ready-to-call top-31 list the same session that had just marked those exact people do-not-contact — caught before anyone called, not before delivery. `.../Incident Log.md:10`\n- **VERIFIED** The wrong/old puppy PDF (11+ touches, day-27 draft) was sent to Kim as \"the sequence\" — did not match the live 8-touch/21-day system; numbering also silently differed (texts+emails combined vs. emails-only) between artifacts. `.../Incident Log.md:7-8`; `/home/claude/dogsspot/handover/kim-message-puppy-numbering.txt`\n- **VERIFIED** Missed-calls \"gate arrivals\" trap: an early published number for \"missed opportunities\" included people who had actually just been buzzed in at the gate same-day — 22 of 240 unanswered-call threads were gate arrivals; Kim corrected this from operational knowledge the CRM data alone could not reveal. `.../Incident Log.md:11`; `/home/claude/dogsspot/handover/FINAL-reply-to-kim.txt`\n- **VERIFIED** Kristian's app: paired drop-off/pickup rate got **worse**, not better, after his fix was declared complete — 93% paired before 21 Jul vs 65% (11/17) after. Small sample, flagged honestly as such. `/home/claude/dogsspot/handover/APP-QA-FINDINGS.md`\n- **VERIFIED** Kristian's changelog claims the calendar registry was \"reconciled to the approved 23-calendar source\" — live account has 29 calendars/24 active, and **both** Bootcamp pickup calendars are inactive despite the changelog claiming a Bootcamp pair was added. `/home/claude/dogsspot/handover/APP-QA-FINDINGS.md`\n- **VERIFIED** The account already runs 95 **published** GHL workflows overlapping every one of the six planned nurture paths by name (e.g. \"Tips Nurture,\" \"1. Wait 1 Day: Initial Nurture - Puppy,\" \"POST CONSULT - NO SALE NURTURE MESSAGES\") — discovered late on 2 Aug; GHL exposes no API to check per-contact overlap. `/home/claude/dogsspot/plan/dogsspot-plan.html` (finding 6); full collision map `/home/claude/dogsspot/engine/paths.ts:76-172`\n- **VERIFIED** Website chat widget (`data-widget-id 68ffcab3612607736a5e8abe`) predates the whole engagement (created 27 Oct 2025 by \"Automation Dogs,\" the original setup agency) — 54 conversations Nov 2025–Jul 2026, **45 (≈83%) unread**, nobody ever assigned to watch it, no office-hours setting so late-night messages get the same silence as daytime ones. `/home/claude/dogsspot/handover/READ-ME-AMIR.md:7-17`; `/home/claude/dogsspot/drive2/07_channels.html`\n- **VERIFIED** Sheepdog-trials payment details (Venmo/Zelle/cheque-to-Chris-Hicks + a field-address warning) were mistakenly pulled from hidden website pages into Kim's customer-facing Money doc and FAQ — trials are a separate entity Candice never touches; corrected 3 Aug. `/home/claude/dogsspot/handover/reply-to-kim-aug3.txt` (\"SHEEPDOG TRIALS\")\n- **VERIFIED** Training-refresher price reads as \"$35\" if skimmed but is actually a **$35/day add-on** to a $30/day graduate boarding stay = **$65/day total** — \"a hire would quote half price.\" `/home/claude/dogsspot/handover/DRIVE-CORRECTIONS.md` item 1\n- **VERIFIED** Of 5,632 opportunities, **zero** have ever been marked \"Won.\" Revenue instead tracked via a \"Customer\" stage (1,512 contacts) but only 53 of those carry a money value at all (**$166,235** total) — 1,459 \"customers\" have no recorded value. `/home/claude/dogsspot/plan/dogsspot-plan.html` (finding 1)\n- **VERIFIED** Of the 53 opportunities that do carry a value, only 6 trace to a paid ad (**$18,870 of $166,235**) — the attribution chain breaks between lead arrival and hand-typed sale entry. `/home/claude/dogsspot/plan/dogsspot-plan.html` (finding 2)\n- **VERIFIED** 70 of 165 GHL workflows are unpublished drafts, including both `1. Initial Nurture - Facebook`/`Instagram` and all four `Bump Facebook` steps — plausible cause of 2,640 New-Lead contacts sitting >30 days untouched. `/home/claude/dogsspot/plan/dogsspot-plan.html` (finding 3)\n- **VERIFIED** A quarter of Pup Talk appoi

Campaign	Spent	Conversations	Cost each
Kims New Except4Ads#2	$180.64	47	$3.84
APRIL 10th Fresh February Leads - Copy	$170.89	44	$3.88
Email CSV AI Campaign	$116.49	22	$5.30
Training Tips-Messenger Leads-6/26	$86.96	14	$6.21
Free Training Day Website 6/19	$0.00	0	off
Total	$554.98	127	$4.37

Measure	This week	How it is worked out
Cost per click	$2.05	$164.00 divided by 80 clicks
Cost per conversion	$41.00	$164.00 divided by 4 conversions
Click through rate	8.25%	80 clicks divided by 970 impressions
Your share of available searches	32%	Google's figure, up from 29%
Rover's share of the same searches	24%	Google's figure, up from 22%

Channel	Messages in	Notes
Facebook	538	72% of everything that came in
Phone	71	120 calls in total, 24 unanswered
Text	71
Instagram	46
Email	4

Figure	Value	Source and method
Facebook spend	$554.98	Ads Manager, account 938090411743620, 31 Jul to 5 Aug, sum of the four live campaigns
Facebook conversations	127	Same view, sum of the Results column
Facebook cost per conversation	$4.37	554.98 divided by 127
Facebook consistency check	4 of 4	Each campaign's spend divided by its results matches Meta's own cost per result to the cent
Google spend, clicks, impressions, conversions	$164, 80, 970, 4	Google Ads overview, account 942-544-7945, 31 Jul to 6 Aug
New contacts, this week and last	175 and 197	CRM contact search on date added, converted to New York time before bucketing, two independent pulls agreed
Appointments	55 and 64	All 29 calendars queried one at a time, 197 raw events, bucketed on start time
Messages in and out	748 and 1,143	660 conversations pulled in full, 15,488 messages, system audit entries excluded
Calls	120, 96 answered	Call type messages, answered means completed
Opportunities won, all time	0	All 5,768 opportunities paginated: 5,594 open, 174 lost, 0 won, 0 abandoned. This is the pipeline view only, not a statement about money received
Payment records in the CRM	232 and 195	Transactions and orders. Three transactions fall inside this week, which is being checked before any return figure is quoted
Contacts with no source, 31 Jul to 5 Aug	120 of 149	Source field on each new contact record

Where the money went	Amount	How this page gets it
Facebook and Instagram3 August to 9 August 2026	$676.94	Read straight from the ad platform every time your card page loads. Read three times today, at 3:06 pm, 3:15 pm and 3:16 pm, and it said the same figure each time.
Google31 July to 6 August 2026	$164.00	Typed by hand. This is the figure in the message sent to you on 7 August. Google puts its own numbers behind a developer token, which Google quotes at about five business days. Google joins this page the same way Facebook has once that token lands, and until then every Google figure you see anywhere is one a person typed.

In the seven days 3 August to 9 August	Count
New people in your CRM	168
Of those, arrived through Facebook or Instagram	139
New cards on your Initial Lead Pipeline	166
Pup Talk appointments on your calendar	20
Of those, showed up	15
Cards that moved into your Customer column	2

Program price on the record	Records	Value
$3,295.00	39	$128,505.00
$2,395.00	11	$26,345.00
$3,795.00	3	$11,385.00
All valued records	53	$166,235.00

What happens to it	Payments	Value
Places itself. One booking open, so the money goes straight on it.	15	$7,880.00
Waits for one of your team to pick. More than one booking open.	0	$0.00
Booking already carries a value, so it is left exactly as it is.	15	$8,237.00
Stays where it is, and it is two separate causes. 3 worth $480.00 carry no name on the record. 3 worth $967.00 name a real customer whose booking sits on another board.	6	$1,447.00
All completed payments	36	$17,564.00

Read from the system itself at 3:12 pm today	Reading
Practice mode	On
Messages to real customers, all time	0
Records it is tracking	1
Practice messages produced	5
Version, and its last pass	1.7.1, 3:11 pm

Program price on the record	Records	Value
$3,295	39	$128,505.00
$2,395	11	$26,345.00
$3,795	3	$11,385.00
All valued records	53	$166,235.00

What happens to it	Payments	Value
Places itself. One booking open, so the money goes straight on it.	15	$7,880.00
Needs one of your team to pick. More than one booking open.	0	$0.00
Already has a value on the booking, so it is left alone.	15	$8,237.00
Cannot be placed, and it is two different problems. Three arrived against a record with no name on it at all. The other three name a real customer who has no card in your Customer column to put the money on.	6	$1,447.00
All completed payments	36	$17,564.00

Route	Payments	What it carries
Invoice raised in the CRM, paid by card	56	Arrives already attached to the customer. This is most of your real revenue.
Order form and manual charges	12	Same, attached to the customer.
Counter sale in Square with no name taken	8	Files against one nameless record. Nothing can ever place these.

What it finds	What it does
One open booking	Writes the amount on. No person involved.
More than one open booking	Puts it on an exception list for your team to pick. It never guesses.
No name on the payment	Reported separately as unplaceable. Never guessed at.
Booking already has a price on it	Left exactly as it is. It never overwrites anybody's number.

Outcome	Payments	Value
Places itself. One booking open.	15	$7,880.00
Goes to the exception list for your team to pick.	0	$0.00
Booking already priced, so left alone.	15	$8,237.00
Cannot be placed, reported separately.	6	$1,447.00
All completed payments	36	$17,564.00

Task	Who	How often
Take a name at the counter when somebody pays without one.	Front desk	Only fixes future payments, not past ones. Eight so far have no name.
Pick the right booking when a customer has more than one open.	Whoever you nominate	Zero times today. The list is empty.
Moving cards into Customer	Nobody	Already automated. Noted, and thank you for the correction.
Anything else	Nobody	The rest is automatic.

Diff · v1186