Software Updates

stamp which generation wrote each lead, and grade the book against today's standard

• The machine's standard has moved several times — the claim ledger arrived,
• then the free-value gate, then the voice spec, then the per-arm link rules
• — and each time everything already in the pipeline stayed exactly as it
• was. A deck written before the ledger existed is still a DRAFT, still
• sendable, and looks identical in the console to one written this morning.
• The console's only staleness signals were two ad-hoc predicates ("no claim
• ledger", "fact-check failed"), which caught two of the ways an artifact
• goes stale and none of the others: a deck that gives away nothing usable,
• an email whose words disagree with what is actually attached, an arm-A
• email that picked up a link.
• This answers the question two ways on purpose, because they are two
• different questions.
• WHICH GENERATION WROTE IT — a stamp recorded at write time, on every path
• that produces an email (first touch, follow-up, rewrite), along with which
• adaptive guidance was steering. Unstamped rows get a generation inferred
• from what their deck satisfies, and `generationStamped` is reported next
• to the number rather than hiding the difference: inference can only ever
• place a lower bound, because it cannot distinguish "written before the
• free-value gate existed" from "written after it and failed it".
• WOULD IT PASS TODAY — every current check re-run against the stored
• artifact, including the actual first-touch validator over the actual body.
• This is what decides whether something needs reprocessing, and it is
• deliberately NOT derived from the stamp. A version number is a promise
• someone remembered to keep; the validator is a fact. An email stamped
• current that nonetheless fails today's rules is a real defect, and a
• stamp-based check would have hidden it — so there is a test for exactly
• that case.
• The panel leads with the only genuinely urgent bucket: drafted or approved
• emails, sitting in the send queue, failing a check we enforce today. A
• SENT email is never counted — it is the outreach record, there is nothing
• left to fix, and counting it would make the urgent number permanently
• non-zero and therefore ignorable.
• Each defect is offered with the single action that clears it, ranked so a
• prospect needing several gets told the one that subsumes the rest:
• rewriting the email of a pre-ledger deck is wasted work, because the
• reassessment replaces it anyway.
• ── The bulk buttons ──
• "Regen all emails" told the operator that APPROVED drafts would be reset
• to DRAFT. They were not: the guard returned skipped_approved, and the

the send calendar was hiding most of what it sends

• The console's "N queued" calendar built its queue from step-1 emails
• only, so every follow-up was invisible — and a follow-up is a real send
• against the same sender reputation, which is exactly the number the daily
• cap is about. It also carried no indication of which experiment arm a
• send belonged to, on a page whose central question is what the arms are
• doing differently.
• It now covers every step and every arm, badges each chip with its arm and
• step, and measures each day against the RIGHT cap: first touches and
• follow-ups draw on separate budgets, so a mixed day is checked against
• both rather than against one blended number.
• The lane filter (All / A / B / C / Pre-test / Follow-ups) is deliberately
• separate state from the board's arm filter below it. The calendar answers
• "what is actually going out", and that question should not silently
• narrow because you filtered the list to one arm.
• The full calendar page had the same problem in a worse form: three hard-
• coded views that DEFAULTED to variant A, so opening it showed one third
• of the first touches, no arm C at all, and no follow-ups, with nothing on
• screen saying so. Six lanes now, defaulting to Everything — the only lane
• whose day totals equal the machine's real volume. Pre-experiment rows are
• badged rather than left blank, since in a combined view an unbadged row
• is ambiguous.

diagnose why outbound isn't working, with a sample-size gate in front

• "Why aren't we getting results?" is the right question and the dangerous
• one. Forty emails go out, three replies come back unevenly across the
• arms, and the temptation is to rewrite the pitch, re-price the offer and
• re-target the list at once — on evidence that cannot distinguish a real
• effect from a coin flip. Every change made that way also destroys the
• experiment that was about to answer the question.
• So the diagnosis runs in two halves, in this order.
• DETERMINISTIC (experiment-stats.ts, 19 tests). Wilson intervals rather
• than the normal approximation, because at these counts the textbook
• interval is simply wrong: 1 reply in 40 gives a negative lower bound, and
• 0 in 40 gives [0, 0] — "proven never to work", from forty emails. Pooled
• two-proportion tests. And the number that makes "wait" actionable rather
• than annoying: how many more sends per arm, and how many days that is at
• the current rate.
• It also reports what a test of this size COULD have detected. A bare
• "p = 0.42, not significant" reads as "the arms are the same"; at n = 40
• it means the test could not have seen a 15-point difference if one
• existed.
• INTERPRETIVE (Claude Opus 5, adaptive thinking, structured output). Given
• those numbers plus the funnel in absolute counts, per-step outcomes, deck
• fact-check health, the cost ladder and the ACTUAL COPY of recent sends:
• where is the funnel really losing people. Absolute defects — a 30% bounce
• rate, decks that never shipped, approved emails that never sent — are
• fair game at any sample size, because those are not experimental results.
• Under NO_DATA or TOO_EARLY the model may not name a winning arm or
• propose a strategy pivot; its recommendations may only increase the
• information available. That is enforced three times: in the prompt, by
• nulling any guidance it returns anyway, and again at the activate
• endpoint for older rows.
• Guidance is a reviewed artifact, not an auto-applied one. Proposals sit

rebuild the signing domain and put signed copies behind an account

• Three changes to sign.katura1999.com and what happens after someone signs.
• ELEGANCE. The landing page introduced a fine-jewelry house with an eight-
• card SaaS feature grid, each card led by an emoji. Emoji are someone
• else's icon set rendered at whatever size the OS decides; a house that
• sets stones by hand does not introduce itself with a gem emoji. The grid
• is now a typographic index — rules, numerals, and the display face the
• rest of the brand uses.
• LANGUAGE. The page was English for everyone, and not because nobody had
• translated it: the proxy rewrites the signing subdomain and returns
• before intlMiddleware runs, so getLocale() there always answered "en".
• Rather than reorder a rewrite every signing link in the wild depends on,
• lib/signatures/locale.ts negotiates directly — saved choice, then the
• device's Accept-Language (quality-ranked, region tags folded to the base
• language), then the edge's country header. Device before country on
• purpose: a Brazilian in Paris on a pt-BR phone wants Portuguese, and a
• configured language says more about what someone can READ than the
• country their IP resolves to. All 24 locales carry the namespace.
• The switcher deliberately shows language names, not flags. A flag is a
• country, not a language — Portuguese is not Brazil, Arabic is not Saudi
• Arabia — and flag emoji were half of what the page needed rid of.
• RETENTION. The completion email attached the executed PDF. That leaves a
• legal document sitting in an inbox forever: forwardable, searchable by
• anyone who later gets into that mailbox, impossible to withdraw. It now
• links to /account/documents, reachable only by signing in as the address
• the document was sent to.
• Matching is on EMAIL rather than user id because the QR flow mints
• documents for people with no account at the moment they sign — asking a
• stranger at a counter to register before agreeing to be filmed would kill
• the flow. Registering later with the same address claims everything

self-serve signing from a QR code

• PLACEHOLDERS accept both {name} and {{name}}. Refusing single braces made the template editor a transcription exercise — every field had to be re-typed with doubled braces before a pasted Word document would render.
• The FORM IS DERIVED from the wording, never configured beside it: every placeholder, minus the operator's business constants, minus the ones the system fills. Add {instagram_handle} to the body and the form asks for it; delete it and it disappears. The form cannot drift from the document in either direction.
• A BLANK BUSINESS CONSTANT does not fall through to the signer's form — the key exists, so it reads as provided, and it prints as empty space in the signed copy. Publishing is refused while any is blank.
• {signature_datetime} cannot be known at mint time. Rather than refuse the placeholder or ship a visible blank, creation leaves a marked span and markSigned fills it in place, idempotently.
• CPF is checksum-validated, not length-checked. On a Brazilian image release the number IS the identification; one that identifies nobody is worth nothing at the moment you need it.

record the built workspace tree and the two API limits hit

• Renaming the owner-created default space returns a permission error — the token is a workspace member, not the owner. Creating new spaces works.
• PUT /space accepts a statuses array, returns 200 with no error, and silently ignores it (verified by re-fetch). Statuses are UI-only. Until all six exist, two-way sync would collapse BACKLOG/REVIEW/BLOCKED, so Phase 3 stays blocked.

bulk-regenerate decks blocked by a failed fact-check

• The existing "Reassess pre-gate decks" action only targets decks with no claim
• ledger (hasClaimLedger === false). The 38 currently-blocked decks DO have a
• ledger — they were audited and rejected — so that action reports "none found"
• and leaves them stranded.
• Adds a sibling action for that case. It appears only when the active tab
• actually contains fact-check-failed decks, states the AI cost in the confirm
• dialog, and points at /admin/usage for running spend.
• Regeneration rather than re-audit is required, and the reason is worth stating:
• the fix in c7561efd changed how the claim ledger is BUILT, and the ledger is
• built at generation time. These decks still carry the old classification in
• storage, where the sender's own self-description sits as a factual claim about
• the prospect with zero citations. Re-running the auditor over that ledger would
• reproduce the same verdict.

manual per-category export of minutes into ClickUp

• src/lib/integrations/clickup.ts — minimal API client. Notes worth keeping: personal tokens use a BARE Authorization header (only OAuth uses "Bearer"), the markdown field is `markdown_content` not `markdown_description`, due dates are epoch MILLISECONDS, and priority is 1..4 with 1 = Urgent.
• Task creation is sequential, not parallel, and stops on the first hard failure. The rate limit is 100 req/min per token, and a half-applied export is worse than a refused one — duplicates in a shared workspace are a social problem, not just a data one. Stopping early gives an accurate report of what landed.
• Due dates resolve relative to the MEETING, not now(). Minutes are often exported days later, so "Friday" means the Friday after the call. Unparseable values stay null and the task is tagged needs-date rather than being given an invented deadline. Same for unowned items: tagged needs-owner.
• Only actionItems and followUps carry owner/due/priority. Decisions, open questions and risks are statements rather than assignments, so those fields are left empty instead of fabricated.
• Duplicate protection is honest about its absence. There is no ClickupTaskLink table yet, so this cannot prove an item was already exported. Each task carries a katura-<meetingId> tag and a backlink to the minutes, and the confirm dialog states plainly that re-exporting a category creates duplicates. An unprovable silent dedup would be worse than a visible warning.
• Scoped to OWNER/MANAGER — this writes into a shared external workspace.

stop the auditor rejecting the email's own sender voice

• New ClaimKind APPROVED_SENDER_CONTEXT for first-person statements about Zachary or Katura. Excluded from the factual-claim gate for the same reason HYPOTHESIS and RECOMMENDATION already are: it asserts nothing about the prospect, so absent prospect evidence is not a defect. Judged against founderStatement by the auditor and by detectForbiddenLeaps, which still runs on every claim regardless of kind.
• isSenderContextSentence() — deliberately narrow. Requires first person AND a Katura/Zachary anchor AND no second-person reference. A loose match here would let unevidenced claims about a real business ride along in first person, which is a worse failure than the one being fixed. Tests pin both directions.
• email-body-* restatements now carry the deck's evidence ids, so the auditor has the citations it was already told to judge them against.
• founderStatement now names the role, closing the writer/auditor disagreement.
• v3-integrity and generate-gates pin the invariant that was missing: both FIRST_TOUCH_EMAIL_RULES and founderStatement must name the role, and no factual email claim may carry zero evidence.

conversion integrity audit and ClickUp integration plan

• The external consultant's audit is largely stale against the repo. The storefront is built; the recovery and measurement layer behind it is not.
• The return-policy contradiction it flags was already resolved on 2026-08-21, and the canonical policy is stricter than the consultant's suggested wording (lab-grown and custom pieces are final sale).
• Only 1 of 132 eligible carts has a consented user. Consent is not captured at cart time, so cart recovery has almost no addressable audience. That, not the plumbing, is the real constraint.
• User.adminLocale does not exist as a column; admin/layout.tsx raw-SELECTs it inside a try/catch and has always fallen through to null.

store test console, shared email shell, and email gallery

• Two new pages under /admin/under-development, plus the email design system
• behind them.
• ── Store Test Console ──────────────────────────────────────────────────
• /admin/under-development/test-console
• Test-fires any store email or operational function against an operator-supplied
• address. Every email test takes its recipient from the request and never from a
• lookup, so no code path here can reach a customer inbox.
• It reports FIDELITY per test, which is the point of building it rather than
• reusing the existing one. The pre-existing /api/admin/marketing/system-emails/test
• sends hand-written HTML that duplicates the real templates — passing it proves
• only that Brevo can deliver a string, and cannot catch a broken template, a bad
• merge variable, or a sender that was never wired at all. A console that hides
• that distinction manufactures false confidence, which is worse than no console.
• live -> invokes the real production sender (abandoned-cart, employee-invite)
• template -> stand-in; proves Brevo delivery ONLY
• missing -> catalogued in the admin email list, implemented nowhere
• Four emails are marked missing after repo audit: welcome-series-1,
• welcome-series-2, anniversary-email, and review-request. review-request is the
• acquisition half of the review system — display, moderation, aggregate ratings
• and verified-purchase logic all exist, but nothing ever asks a customer for a
• review.
• Read-only function checks cover cart-recovery readiness, a cart-recovery dry run,
• Brevo connectivity, and Meta pixel/CAPI configuration. One non-read-only action,
• Cart Recovery — Enable, is gated behind a to_regclass check and REFUSES unless
• CartAbandonment exists. That refusal is the reason the action exists; it must not
• be softened into a warning.
• Scoped to OWNER/MANAGER at both page and API. requireKaturaAdmin() defaults to
• including EMPLOYEE, which is too broad for a surface that sends real mail and
• mints real, redeemable discount codes.
• ── Email design system ─────────────────────────────────────────────────

fail closed, and add the CartAbandonment table it needs

• frequency cap .catch(() => [{count: 0}]) -> always "nothing sent recently"
• record lookup .catch(() => []) -> every cart looks brand new
• MAX_REMINDERS (undefined || 0) + 1 -> permanently 1, never reached
• REMINDER_INTERVALS -> lastReminderAt undefined, skipped
• Every guard now FAILS CLOSED. If we cannot prove we are under the frequency cap, we assume we are over it. If the record lookup throws, the cart is skipped rather than re-sent blind.
• Record-before-send ordering. The reminder row is written FIRST; if that write fails the send is suppressed. A lost reminder is recoverable, a reminder loop against a real customer is not.
• New CartAbandonment table, including the recovery-attribution columns (recovered/recoveredAt/recoveredOrderId/recoveredValue) the original code referenced but had nowhere to store.
• tenantId carries DEFAULT 'tenant_katura'. The currently-deployed cron INSERTs without a tenantId; with a NOT NULL and no default that INSERT would fail, be swallowed by the old .catch(), and the send would proceed with no record written — reopening the same loop by a different route. Keep the default until the hardened cron is confirmed live everywhere.
• Added ?dryRun=1, which evaluates every gate against real carts and reports who WOULD be emailed without sending or writing anything.
• Corrected the docstring, which claimed a 30-minute schedule that never matched the 4-hour registration in vercel.json.

deduplicate gift-balance purchases in Conversions API

• Gift-balance-only orders fired trackCapiPurchase() without an eventId,
• while every other purchase path passes the deterministic `pur-${orderNumber}`.
• Meta deduplicates a browser pixel hit against a server CAPI hit only when both
• carry the same event ID. Without one, the gift-balance server event could not be
• matched to the client pixel event, so a single sale was counted twice —
• inflating Purchase volume and ROAS on exactly the reports used to judge ad spend.
• The other three emitters (checkout/success client pixel, /api/tracking/purchase,
• and the Stripe webhook) were already consistent; this brings the fourth in line.

credit placements were charged and never issued

• The credit branch now runs FIRST, before anything order-shaped, and returns.
• An issuance failure now THROWS instead of being logged and swallowed, so Stripe retries. A charge with no credit issued is the worst silent failure available here.
• houseCredit is carried through to issuance.

gift-cards: one continuous placement flow — no scroll, no second click

• Owner found it live: choosing an amount, scrolling UP to press 'Establish
• House Credit', then scrolling back DOWN to reach the checkout. My mistake —
• I moved the ledger above the fold in the last change but left the amount
• picker in its own section further down, splitting a single action across two
• scroll positions. Nobody completes that at 10pm on a phone.
• Now one section: amounts on the left, ledger and checkout on the right,
• visible together. A default amount is preselected, so the checkout is present
• on load and the intermediate 'Establish' click is gone entirely — it bought
• nothing and cost a scroll in each direction. Choosing a different amount just
• updates the panel beside it.
• $10,000+ still swaps that panel for 'Speak with Lee' rather than a bigger
• Stripe button.
• +4 tests pinning the regression: the checkout renders with no intermediate
• click, no gating 'Establish' button exists, and the choices and the checkout
• live in the SAME section — the last one is what actually failed before.

gift-cards: make the Private Credit Event actually able to take money

• Stripe Payment Element rather than a bare card field, so Apple Pay, Google Pay and Link appear automatically. For an email opened on iPhones at night, Face ID versus a 16-digit number IS the conversion rate.
• /gift-cards/house-credit/confirmed handles the Stripe return, and deliberately does not restate a balance — the credit is issued by the webhook and this page can render a beat earlier.
• The ledger is ABOVE THE FOLD. The email creates desire; the page closes.
• Ladder anchors at $500-$5,000 (never $100 first — that teaches the reader that small is normal), each rung carrying a reason rather than a 'most popular' badge: a future gift / a future Katura creation / a significant commission.
• Defaults to 'for me'. Recipient details are an optional tick — asking who it is for during an impulse placement is admin work at the worst moment.
• Checkout is inline; no redirect to a second page.
• Scarcity stated as a fact: a finite House allocation, closing 28 August, whichever comes first. No countdown timer.
• $10,000+ routes to 'Speak with Lee' rather than a bigger Stripe button.

gift-cards: non-refundable credit, $9,999 ceiling, guest placement

• Three owner decisions (2026-08-25), all for the same reason — this event
• exists to bring cash in.
• NON-REFUNDABLE, both balances. Purchased credit and House Credit are now
• stated as not refundable and not exchangeable for cash, on the page, in the
• terms constant, and in the certificate email. One distinction kept
• deliberately: non-refundable does NOT mean expiring. Under the federal CARD
• Act a purchased balance may not expire for at least five years, so it carries
• no expiry at all; the promotional portion is exempt from that floor precisely
• because it is labelled promotional, which is what its separate record makes
• it, so twelve months stands.
• CEILING 1,000 → 9,999. The old cap would have rejected every tier above the
• first. It stops just below $10,000 on purpose: Private Client placements are
• arranged by a person, so the self-service path ends where that begins.
• GUEST PLACEMENT. Sign-in is no longer required — asking someone to create an
• account before placing $5,000 is friction we cannot justify. A guest supplies
• their own details and is emailed a redemption code; a signed-in client still
• gets the balance on their account with nothing to redeem, and the certificate
• says so either way.
• HOUSE CREDIT IS NOW ACTUALLY ISSUED, as its own GiftCard record with its own
• code and a twelve-month expiry, rather than only appearing in the email. The
• contribution is recomputed SERVER-SIDE from the amount at intent creation and
• never read from the request, so a crafted call cannot mint credit.

gift-cards: the Katura Private Credit Event + credit certificate email

• NEW PAGE /gift-cards/house-credit — 'The Katura Private Credit Event'.
• A client places credit with the house; Katura contributes on top. Same
• economics as a gift-card promotion, deliberately different register: the
• words 'gift card', 'sale', 'bonus', 'free' and '% off' appear nowhere, and a
• test enforces that. Dollars, never percentages — the ledger reads
• $1,000 / +$500 / $1,500 so nobody does arithmetic. No red, no struck-through
• prices, no countdown.
• Public ladder is 25% / 50% / by-request. The 75% Private Client rate exists
• as a constant for whoever negotiates and is rendered on NO public surface —
• a house publicly offering 75% reads as needing cash; the same offer made
• quietly reads as a velvet rope. A test asserts the public tiers contain only
• 0.25 and 0.5.
• TWO SEPARATE BALANCES, not one number. Purchased credit is the client's own
• money: no expiry, spendable anywhere, refundable. House Credit is
• promotional: eligible creations and commissions only, twelve months, never
• cash, and applied FIRST at checkout so the client's own credit survives.
• Merging them would mean refunding promotional value as cash. Exclusions
• (taxes, shipping, further credit, already-reduced goods, pass-through stones)
• are on the page in full, because $10k → $17.5k is a 42.9% discount against
• selling price — survivable on house work, ruinous on a thin-margin stone. A
• test pins that arithmetic.
• CERTIFICATE EMAIL (src/lib/emails/katura-credit-email.ts) replaces the old
• gift-card emails on both paths. Sent the moment credit is placed: the balance
• ledger, the redemption code set as a hallmark, and the promotional terms in
• plain words. Registered to the account already — an existing user's balance
• lands on their account and the email says there is nothing to redeem.
• On animation, honestly: CSS animation, video and script are stripped by
• Gmail, Outlook and Apple Mail. Only an animated GIF survives, so the template
• accepts an optional motionImageUrl as progressive enhancement and carries the
• whole certificate without it. Nested tables with inline styles because
• Outlook renders through Word.
• +20 tests. One of them caught a real leak: 'rather than a coupon' sat in an

plain-English findings, $8.4k goal panel, variant C, scoring page, 9 autopilots

• findingSchema gains a REQUIRED plainEnglish field — two sentences saying what the technical fact means for their shop, with an everyday analogy only where it earns its place
• Writer prompt carries worked examples ('a sitemap is the index at the back of a book — Google has to wander the shelves without one')
• checkPlainEnglish is deterministic, because a prompt alone does not hold a rule here: it rejects condescension ('as you may not know', 'put simply', 'most business owners don't realize'), blame ('you should have', 'leaving money on the table'), and jargon that was never actually translated — repeating 'sitemap.xml returned 404' is not an explanation

separate B2B jewelers from the D2C audience

• src/lib/prospecting/brevo-segment.ts + POST /api/admin/prospecting/brevo-sync
• scripts/infra/sync-b2b-brevo.ts (standalone; lib/prisma is server-only). Needs pgbouncer=true — Supabase's pooled connection is pgBouncer in transaction mode and Prisma otherwise dies on 'prepared statement s0 already exists'.

follow-up sequence, A/B + follow-up calendars, analytics build-out

• Own spec, a SIBLING of the first-touch rules rather than a mode of them: 20-80 words, 1-5 sentences, no greeting, no re-introduction, no bump language, no link, no dollar figure, and NO ask at all on touch 4
• Own validator (validateFollowUp) wired into send.ts — before this, 75% of a four-touch sequence would have shipped through no validator whatsoever
• Writer sources only from the already-fact-checked deck and must hand over a finding the earlier touches did NOT use; no canned fallback, because an identical filler note to every prospect is worse than sending nothing
• Deliverability rules enforced in code: RFC-5322 threading (In-Reply-To + References, so Gmail groups it), greeting suppressed after touch 1, weekday 9-11am in the RECIPIENT's timezone, separate daily lane (FOLLOWUP_DAILY_CAP) drawn first so a sequence can never quietly eat top-of-funnel
• Master switch PROSPECTING_FOLLOWUPS_ENABLED, defaulting OFF and deliberately inverted from this repo's usual convention
• stampOutreach matched on recipient and stamped the newest THREE sent rows, so one delivery webhook stamped up to three emails and delivery rate could exceed 100%. Now matches brevoMessageId, falling back to one row.
• The events panel counted test-mode rehearsals despite the page promising it excluded them. ProspectingEvent has no testMode column and no email relation, so they're now excluded by id.

assign A/B after scoring, lock legacy prospects out, fix arm-B approval

• Owner instruction: "we're only going to do this fifty-fifty split on future
• prospects that come in — I don't wanna go back and alter emails that have
• already been written that are good to go."
• ASSIGNMENT MOVED discovery-create → generation time, after research and the
• deterministic lead score and immediately before the writer runs (the arm
• decides what the email says, so the final score must decide the arm).
• Stratified on campaign x lead-score TIER, recorded in outreachVariantTier so
• arms can later be compared at equal tier.
• An adversarial review of the guarantee found three real defects, all fixed:
• 1. LEGACY LOCK-OUT (the requirement violation). The email-based guard was not
• sufficient: ~136 of the 288 existing prospects had no email row yet, so the
• every-10-minutes autopilot would have enrolled them with no operator action
• and written arm-B paid-offer emails for half. All 288 are now stamped
• outreachVariant='LEGACY' (migration 20260824_experiment_legacy_lock.sql) —
• a stored fact, refused by assignment, filtered out of every comparison.
• The email guard also tightened: ANY email row blocks enrolment, cancelled
• included.
• 2. ARM B WAS DEAD ON ARRIVAL. The approve route and the rewrite path both
• called validateFirstTouch WITHOUT the variant options, so the arm-A rules
• rejected the offer link — every arm-B draft failed approval, and a bulk
• rewrite silently replaced it with an arm-A fallback that could then never
• pass the send gate. New firstTouchOptionsFor() resolver; both call sites
• fixed; the rewrite writer now receives the arm-B rules too.
• 3. BULK REWRITE ATE APPROVALS. rewriteFirstTouchEmail overwrote APPROVED
• bodies in place and demoted them to DRAFT, discarding the approval and its
• send slot. It now returns skipped_approved.
• UI: an experiment-arm filter (All / A / B) that applies to whichever tab and
• sort is active — so "Ready to email, arm B" and a per-arm send schedule are

the phone-call test — impressions, never data recitation

• Owner, reading the first live send: "for any actual human does listing a
• full address like that look natural? … in a real meeting I won't look like
• a jackass if I don't know something."
• The email quoted scraped data verbatim — "the Branson address shown right on
• the site: 219 West Pacific Street, Branson, MO, USA", "5.0 from 9 reviews on
• Birdeye as of 2026-08-22". That register turns "I looked at your site" into
• "my crawler filed a report on you", and it commits Zachary to specifics no
• person retains.
• New governing rule, deterministic: every factual sentence must survive the
• owner ringing back tomorrow — the claim level of a person who spent five
• minutes on the site. Banned outright: full street addresses (street names
• without numbers stay fine — "the shop on West Pacific"), ISO dates ("when I
• looked this week" instead), country suffixes (nobody tells an American their
• shop is in the USA), and tool/vendor vocabulary (Birdeye, ad library, title
• tag, meta description, schema, sitemap.xml — say "the name in the browser
• tab", "your Google reviews"; the precise technical version lives in the
• attached PDF, which is exactly where Zachary would look during a call).
• "A perfect 5.0 from just 9 reviews" survives; its provenance does not.
• 257/257 tests (9 new).

rank by the score the operator SEES; stop paying to re-plow dry ground

placeholder contacts purged, send queue visible, approve arms the slot

• The owner's screenshot surfaced four problems, one of them urgent now that
• PROSPECTING_TEST_MODE is off:
• 1. FOURTEEN prospects carried fake contact addresses stamped as verified —
• example@domain.com / user@domain.com (website-template placeholders that
• theme footers really do "publish" in mailto: links), your@email.com, and a
• Wix Sentry DSN (605a7b…@sentry-next.wixpress.com) on three rows. One was
• Monday's 8 AM flagship send. Live mail to these bounces and burns the new
• sender reputation. isPlaceholderEmail() now rejects them at all three choke
• points — normalizeEmail (discovery), site-fetch extraction (the adoption
• path that created these), and the live-send gate — with tests for each
• observed fake. All fourteen demoted to mail-only with an audit note; the
• queue reassigned cleanly: 53 scheduled, 3 CASL-skipped.
• 2. "Approve & send" sent IMMEDIATELY, bypassing the schedule — with live mode
• on, one click = one real email right now. Approving now ARMS the scheduled
• slot instead ("Approve for slot", confirm names the exact send time in the
• prospect's zone); the cron does the sending. Immediate send survives as the
• explicit exception: "Send now (skip schedule)" on approved rows, and the
• red Send LIVE in the card.
• 3. The weekend queue was invisible. New "Send queue" strip above the tabs:
• Today / Tomorrow chips in ET order, green = approved (will send), amber =
• "needs approval" (will hold). Directly answers "what goes out today?"
• 4. Row layout wrapped business names word-by-word once the schedule badge
• joined the action cluster. Names now truncate on their own line with the
• location/reviews/email meta on a second truncating line.
• 249/249 tests (13 new), scoped tsc clean.