[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6,"_7":8},"actionData","errors","root",{"_107":108,"_109":110},"routes/embed.x.$handle.$name.$",{"_9":10,"_11":12,"_13":14,"_15":16,"_17":18,"_19":20,"_21":22},"handle","amir5","name","dogsspot_puppy_path","path","SOURCE-BUNDLE.part8.txt","project",{"_23":45,"_11":12,"_34":46,"_47":-5,"_48":42,"_49":50,"_51":50,"_52":53,"_54":-5,"_55":56,"_57":58,"_59":33,"_60":-5,"_61":-5,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71,"_72":-5,"_73":74,"_75":74,"_76":77,"_78":77,"_79":77,"_80":74,"_81":74,"_82":83,"_84":85,"_86":87,"_88":42},"file",{"_23":24,"_11":14,"_25":26,"_27":-5,"_28":29,"_30":31,"_32":33,"_34":35,"_36":37,"_38":17,"_39":40,"_41":42,"_43":-5,"_13":44},"permalink","https://www.val.town/x/amir5/dogsspot_puppy_path/code/SOURCE-BUNDLE.part8.txt","extension","txt","id","be1824eb-6783-4a03-a8b2-257067bd8d7a","fileId","7c8dcd00-91bc-11f1-8e89-1607ee4eb77e","parentId","branchId","551774fb-a850-4c9d-94a1-d3509ddcf1b0","branchVersion",1222,"latest",true,"createdAt",["D",1786982957659],"version",42,"fileType","content","THE DOGS SPOT — SOURCE BUNDLE (part 8 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 (4 of 129 files)\n engine/holiday-deposits.ts 50763 bytes 0f2bee44b101\n engine/kim-stories.ts 5461 bytes 66b22bd3d93d\n engine/money-match.ts 10281 bytes d18d5da616fe\n engine/noshow-messages.ts 8761 bytes 9ceeb969c5cb\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 * Seen live on a customer contact: a direct \"+payment\" note and a \"Till payment ... Matched from\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 on a repeat boarding customer:\n// two payments in the same period, both resolving to one opportunity, only the last one surviving.\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 figure already on the client's page is the correct one and it\n// is the 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\n=====FILE engine/noshow-messages.ts =====\n// THE \"BOOKED A PUP TALK AND DIDN'T SHOW\" PATH. v1.0, 15 Aug 2026.\n//\n// THE HOLE THIS CLOSES, MEASURED RATHER THAN ASSUMED.\n//\n// Read live from the account on 15 Aug 2026: across the two calendars that matter, most appointments\n// marked no-show or cancelled do NOT carry the tag that is supposed to accompany it — the tag is\n// applied a small single-digit percentage of the time.\n// The staff-booked appointment type loses a substantial share, and every one of those was booked by a\n// member of staff already in a conversation with the customer. The self-booked type loses a much\n// higher share again. Exact figures are held in the client record, not here.\n//\n// Seven published GoHighLevel workflows already have \"no show\" or \"cancelled\" in their names. None\n// of them is what this is. They fire on tags that are applied 2% of the time, and they are one-shot\n// messages rather than a sequence. This path is enrolled by a human applying `nurture - noshow`,\n// which is the same switch every other path uses, and it does not depend on the tag estate at all.\n//\n// THE TONE DECISION, AND IT IS THE WHOLE FILE.\n//\n// Somebody who booked a free call and did not turn up is not a lead who needs chasing. They are\n// usually a person whose week went wrong. The single most likely reason a dog owner misses a free\n// consultation is that the thing they wanted help with got worse, not better, and they are\n// embarrassed. So:\n//\n// * Not one message asks why they missed it. Not once, not gently, not implied.\n// * Not one message says \"we noticed you didn't attend\". They know.\n// * The first message is help with no ask attached, because the ask is what they dodged.\n// * The rebooking link is present every time and never the point of the sentence.\n// * Five touches across thirty days, and the gaps WIDEN: 20 hours, 2 days, 9 days, 16 days,\n// 30 days. Frequency that decays is the difference between a business that is still there and\n// a business that is nagging. The contracted minimum for this system is a 30-day journey, and\n// the validator enforces it — the first draft of this file stopped at day 16 and was caught.\n// Padding it with a fifth chase would have been the wrong fix, so the fifth touch is the same\n// shape as the second: something useful, with no ask attached, and it says out loud that it is\n// the last one. A sequence that stops without saying so leaves the person waiting to be chased.\n//\n// CONSTRAINTS THIS FILE IS WRITTEN AGAINST (engine/paths.ts validator, all enforced by test):\n// * never \"discovery call\" — Kim's word is Pup Talk\n// * never grooming, which they do not offer\n// * NEVER a price, because training prices are not ours to quote and this path has no exception\n// * only {{FIRST_NAME}} and {{DOG_NAME}} are wired up; any other token reaches a customer as\n// literal text\n// * SMS ceiling 320 characters\n// * every booking link must point at the Pup Talk calendar this account owns\n\nimport { PHONE_DISPLAY, SHORT_BOOKING_LINK } from \"./puppy-messages.ts\";\nimport type { Step } from \"./paths.ts\";\n\nexport const NOSHOW_STEPS: Step[] = [\n {\n id: \"main-1\",\n channel: \"sms\",\n offsetHours: 20,\n // TWENTY HOURS, NOT TWO. Two hours after a missed call reads as a system noticing. The next\n // morning reads as a person. It also clears the evening, which is when the reasons for missing\n // an appointment tend to still be happening.\n bodyTemplate:\n `Hi {{FIRST_NAME}}, it's Kim at The Dogs Spot. No problem at all about yesterday - life happens. ` +\n `If you'd still like to talk about {{DOG_NAME}}, grab any time that suits: ${SHORT_BOOKING_LINK}. ` +\n `Or just reply here, a real person reads these. Reply STOP to opt out.`,\n },\n {\n id: \"main-2\",\n channel: \"email\",\n offsetHours: 48,\n subject: \"The thing most people want to ask us first\",\n previewText: \"No booking needed to read this one.\",\n // NO ASK IN THIS EMAIL AT ALL beyond a link at the bottom. It is the only message in the path\n // whose job is to be useful to somebody who never speaks to us again.\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nI'll keep this one short and useful, and there's nothing you need to book to read it.\n\nThe question we get asked more than any other is some version of \"is it too late?\" - the dog is two, or five, or has been doing this for years, and the owner has been told the window closed. It didn't. Older dogs learn more slowly than puppies do in some ways and considerably faster in others, because they can already concentrate. What actually changes with age isn't whether a dog can learn. It's how consistent the humans have to be.\n\nThe second thing worth knowing: almost every problem people call us about - pulling, barking at the door, not coming back when called, going for other dogs - comes down to the dog never having been shown what to do *instead*. Telling a dog to stop doing something leaves them with nothing to do. That's why \"no\" stops working after a while.\n\nIf any of that sounds like {{DOG_NAME}}, a Pup Talk is a real conversation with our team about what's actually going on. No obligation to book anything afterwards, and it costs you nothing.\n\n${SHORT_BOOKING_LINK}\n\nOr call or text us on ${PHONE_DISPLAY} if that's easier.\n\nKim\nThe Dogs Spot`,\n },\n {\n id: \"main-3\",\n channel: \"email\",\n offsetHours: 216, // day 9\n subject: \"What actually happens on a Pup Talk\",\n previewText: \"In case the not knowing is the bit putting you off.\",\n // WHY THIS EMAIL EXISTS. The commonest unspoken reason a free consultation gets missed is not\n // knowing what it is and not wanting to be sold to. So this describes the call plainly,\n // including the part where nobody has to buy anything. It is the highest-intent message in the\n // path and it is deliberately the least salesy.\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nA few people have told me they weren't quite sure what they'd booked, so here's exactly what a Pup Talk is.\n\nIt's a phone call, about twenty minutes. Someone from our team asks what's going on with {{DOG_NAME}}, what you've already tried, and what you'd want to be different. Then they tell you honestly what they think would help.\n\nSometimes that's one of our programs. Often it isn't - it's a change to how something is being handled at home, and it costs nothing to try. We'd rather tell you that than sell you something you didn't need, because the people who send us their friends are the ones we were straight with.\n\nNobody is asked to decide anything on the call.\n\nIf that sounds worth twenty minutes: ${SHORT_BOOKING_LINK}\n\nAnd if the timing just isn't right, that's genuinely fine. We'll be here.\n\nKim\nThe Dogs Spot`,\n },\n {\n id: \"main-4\",\n channel: \"sms\",\n offsetHours: 384, // day 16\n // Deliberately the lightest message in the path. Two weeks after a missed call, the only honest\n // thing to say is that the offer is still open, so that is all it says.\n bodyTemplate:\n `Hi {{FIRST_NAME}}, Kim at The Dogs Spot. Still happy to talk about {{DOG_NAME}} whenever suits - ` +\n `${SHORT_BOOKING_LINK}, or ${PHONE_DISPLAY} if you'd rather just ring. No rush. Reply STOP to opt out.`,\n },\n {\n id: \"main-5\",\n channel: \"email\",\n offsetHours: 720, // day 30\n subject: \"One last thing, and then I'll leave you alone\",\n previewText: \"Useful whether or not you ever call us.\",\n // THE LAST ONE, AND IT SAYS SO IN THE SUBJECT LINE. Saying \"this is the last one\" is the single\n // line most likely to get a reply from somebody who has ignored four, and it is the only honest\n // way to end. Same shape as main-2: useful to a person who never speaks to us again, because\n // most of the people still reading at day 30 are exactly that person.\n bodyTemplate: `Hi {{FIRST_NAME}},\n\nThis is the last email I'll send, so I want it to be worth opening even if we never speak.\n\nThe one thing that changes most dogs fastest, and costs nothing: stop repeating the word. If {{DOG_NAME}} doesn't respond the first time, saying it four more times teaches them the word means nothing until the fourth time. Say it once. If nothing happens, help them do the thing, then reward it like they'd done it on their own. Most people find that alone changes recall inside a fortnight.\n\nThe second thing: whatever you want more of, catch them doing it. Dogs repeat what pays. Almost nobody rewards the dog who is lying quietly in the corner, which is exactly why the quiet doesn't last.\n\nThat's genuinely it. If you ever want a proper conversation about {{DOG_NAME}}, we're here and a Pup Talk is free: ${SHORT_BOOKING_LINK}, or call or text ${PHONE_DISPLAY}.\n\nGood luck with them either way.\n\nKim\nThe Dogs Spot`,\n },\n];\n\n","deleted",false,"label",[14],"1bfa6e81-74e1-4c6c-ab32-118304a4ffff",["D",1785429259053],"deletedAt","legacyEnvVars","privacy","public","httpPrivacy","description","Puppy path nurture engine v1.2 — The Dogs Spot","imageUrl","userId","d26e64e6-cd39-4be1-b5b4-1de11cc555f8","pinnedFileId","ad633fec-8e73-11f1-b800-1607ee4eb77e","pinPreview","pinMigrated","screenshotVersion","likeCount",0,"orgId","019f56fd-bd59-724f-8163-80ffcf8235dd","tursoName","1bfa6e8174e14c6cab32118304a4ffff","tursoHostname","1bfa6e8174e14c6cab32118304a4ffff-val-town.aws-us-east-2.turso.io","tursoMeasuredAt",["D",1789519842404],"pinned","userPerm","r","valPerm","blobPerm","rw","emailPerm","sqlitePerm","projectPerm","telemetryPerm","user",{"_9":10,"_106":102},"org",{"_9":10,"_99":100,"_101":102,"_55":56,"_103":104,"_105":42},"branch",{"_36":89,"_11":90,"_23":29,"_91":45,"_92":-5,"_93":-5,"_94":-5,"_95":-5,"_96":-5,"_97":12,"_98":10},"isOwned",1233,"main","projectId","forkedBranchId","forkedBranchVersion","forkedProjectPrivacy","forkedProjectId","forkedProjectOrgId","projectName","userHandle","displayName","Amir","avatar","https://lh3.googleusercontent.com/a/ACg8ocILk3bwhcvrzozUWm7gxlKoBm7ZGtsgIkesW3ysOOsJ1rSQuA=s96-c","tier","free","canRestrictVals","profileImageUrl","ctx",{"_82":-5,"_140":141,"_142":143,"_144":145,"_146":42,"_147":42,"_148":42,"_149":33,"_150":-5,"_151":-7,"_152":-7,"_153":63,"_154":42,"_155":42,"_156":-5,"_157":42,"_158":42,"_159":42,"_160":-5},"ENV",{"_111":112,"_113":114,"_115":90,"_116":117,"_118":119,"_120":121,"_122":123,"_124":125,"_126":127,"_128":129,"_130":131,"_132":133,"_134":135,"_136":137,"_138":139},"REACT_APP_SENTRY_DSN","https://586020d86f05489db63a554690acf1e9@o1398359.ingest.sentry.io/6724499","RENDER_GIT_COMMIT","e87eb04e707cf64e7e532c8e8ec395f209e17f15","RENDER_GIT_BRANCH","POSTHOG_API_TOKEN","phc_nmoyuAkStEZuUp69rYlg1DZgrIt19Gx0Y4Hwf8tGgJP","POSTHOG_API_HOST","https://wart.val.town","WEB_API_TEMPLATE","https://{val}.web.val.run","APP_URL","https://www.val.town","MODULE_URL","https://esm.town","VANITY_WEB_API_TEMPLATE","https://{label}.val.run/","DENOLS_URL","https://lsp.val.town","NODE_ENV","production","CLOUDFLARE_TURNSTILE_SITE_KEY","0x4AAAAAACtaIZJH7s9rBMZ6","GOOGLE_CLIENT_ID","875989696899-jtsqkhlbdv5jrlsk8631p7ipjg3c6o62.apps.googleusercontent.com","STRIPE_PUBLISHABLE_KEY","pk_live_51N2zvWEpZTTLipIkVEwXrUG9AT0yeOOEYxszarZT1jpsZV58Ly6wlg3SltZpHN26CUalOBmUSY7adQRQiSkCZz2500qSXNkf8Y","API_URL","https://api.val.town","orgs",[],"preferencesKeybindings","default","preferencesTheme","light","preferencesFixers","preferencesCopilot","preferencesSelectionAi","preferencesCloseBrackets","preferencesChatPanelState","preferencesDprint","preferencesDenofmt","notificationCount","flagDenols","isBusinessOrgMember","businessOrgHandle","isBusinessOrgAdmin","isHigherTownieTier","navCollapsed","currentOrgId"]