[{"_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":-5},"handle","amir5","name","dogsspot_puppy_path","path","holiday-deposits.ts","project",{"_22":45,"_11":12,"_33":46,"_47":-5,"_48":42,"_49":50,"_51":50,"_52":53,"_54":-5,"_55":56,"_57":58,"_59":32,"_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",{"_22":23,"_11":14,"_24":25,"_26":-5,"_27":28,"_29":30,"_31":32,"_33":34,"_35":36,"_37":38,"_39":40,"_41":42,"_43":-5,"_13":44},"permalink","https://www.val.town/x/amir5/dogsspot_puppy_path/code/holiday-deposits.ts","extension","id","b915f4d9-b531-4a8a-80fc-7aee0e4c0d03","fileId","2f043ab0-91ad-11f1-9dc1-1607ee4eb77e","parentId","branchId","551774fb-a850-4c9d-94a1-d3509ddcf1b0","branchVersion",1132,"latest",true,"createdAt",["D",1786832221229],"version",21,"fileType","script","content","// 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","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",{"_35":89,"_11":90,"_22":28,"_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":32,"_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"]