Lead Dashboard

v6.10.67 — UNDER 5 SECONDS (owner 2026-11-09: "It's 14 seconds now. It has to be under 5 seconds"). Database connections open while the scripts load; the first paint reads two small docs (~25 KB, was ~325 KB); the pack comes in one request (was two round trips); the live listeners' first snapshot no longer re-runs the whole ~1 s recompute when nothing changed. v6.10.66 — EVERYTHING LOADS FAST (owner 2026-11-09: "If I refresh the page, I expect it to load everything in a split second"). The page no longer streams ~70 MB of revenue, deals and resolutions on every load: ad-intel dash-pack-precompute.mjs packs the fields the page reads (~2.2 MB gzip) into dash_pack hourly on business days and at 5 AM; the page loads it, renders every tab with the same math, then listens live only to today, yesterday and newly ingested revenue. A pack older than 26 h is ignored (full load as before). Per-tab memory cache; background tabs wait until viewed. v6.10.65 — FAST FIRST PAINT (owner 2026-11-09: the board took minutes to show anything; "Yes, build it"). Each past day's deals and cash are added up once by ad-intel dash-rollup-precompute.mjs into dash_rollup/{YYYY-MM}; the Deals and Revenue cards and Daily CPA paint from those days plus today, which is watched live, while the full load runs. The full load then takes over exactly as before and checks itself against the stored days (window.__rollupCheck). v6.10.63 — QUICK WINDOWS (owner 2026-11-05: "Can I get another option for yesterday, last 7 days, last 30 days, last month? ... a dropdown. Beside range"). A dropdown between Monthly and Range picks Yesterday, Last 7 days, Last 30 days or Last month. Complete days only (today left out); each one is a Range with its dates filled in, compared against the same number of days just before it. · v6.10.62 — MAIN OVERFLOW → HIRES NEEDED (owner 2026-11-02: "Is there a way to have that as a monitor on the leads dashboard so I can look at the staffing and capacity? I would know how much to hire based on a time frame or recent activities."). The Staffing & Capacity page opens with a new block: pick last 7 / 14 / 30 days, all history or any dates, and it says how many to hire for Main from the calls that spilled from Main to Secondary, split into what lunch and the 7 AM start explain (scheduling) and what the rest of the day needs (hiring), with the average weekday by hour and each day of overflow to Main, to Secondary and missed. Written by overflow-capacity-precompute.mjs (hourly + nightly) to staffing_capacity/overflow. · v6.10.61 — PERSONAL ACCOLADES (owner 2026-11-02: "Let's have the personal bests on the dashboard ... personal accolades below the company accolades"). The Accolades page now has a Personal Accolades section under the company records: last month's personal bests (every agent whose revenue beat their own best month; October 2026: 35 agents) stay up all of the next month, followed by this month so far. Written by company-records-precompute.mjs as personalBestsPrev. · v6.10.60 — NO PROJECTION UNDER THE CASH ALREADY IN (owner 2026-10-30, Revenue per Team: every team's Proj. EOM was below what it had already collected, Kingpins $1,197,372 vs $1,206,813). The month forecast counted cash through yesterday plus an AVERAGE day for today; on a month-end Friday that had already beaten the average, the whole forecast fell under the money in the bank and every team and agent row scaled to it fell too. Today now counts at least what it has already collected (cash and deals), and each team/agent projection is at least its own cash while the rows still add up to the Forecast card. Pure helpers in the EOMSPLIT block, tests/eom.test.mjs. · v6.10.59 — THE URL FOLLOWS YOU (owner 2026-10-30: "shouldn't it change the URL based on where I am at? When I share the URL, it goes directly to where I am at."). The address bar now carries the sidebar page and, on Dashboard / Revenue per Agent / Revenue per Team / Deals per Agent, the window too (#revenue-per-agent?view=monthly&month=2026-09; range links carry start and end). A shared link opens that page and window; Back and Forward walk the pages you visited; the bare address still opens the Dashboard. A bad or unknown link falls back to the Dashboard defaults and never breaks the board. Pure helpers in the ROUTE block, tests/route.test.mjs. · v6.10.58 — ROI HISTORY + FULLER "DATA AS OF" STRIP (owner 2026-10-26: "Ideally, I just want to go with ad spend versus revenue"; "Go ahead. Make them live"). The board forgot every night; a new nightly job (ad-intel perdeal-history-precompute.mjs, checked 13/13 months against this table before its first write) now saves each month's Lifetime ROI and Forecast ROI. Per-Deal Economics gains 30-day change, Path, Status and Forecast 60d ago, and clicking a month opens its history. Cash history starts 2026-10-26, so those columns read "new" until late November; Forecast history was rebuilt from the nightly log back to 2026-05-29. The freshness strip gains Forecast, Records and History chips, and a line under it names the figures that are short when a chip goes amber · v6.10.57 — LIFETIME ROI ON REAL CASH (owner 2026-10-26: "You can have a forecast, but I also need to look at the lifetime ROI as it grows."). Per-Deal Economics gets a Lifetime ROI column = revenue collected per deal ÷ cost per deal, the cash actually collected from the month's deals so far against what they cost; it climbs with every payment. The old column, signed contracts × the mature collection rate ÷ cost, is now labelled Forecast ROI and keeps the SCALE/FIX CPA verdict · v6.10.56 — PER-DEAL ECONOMICS SORTS (owner 2026-10-26: "make this from latest to oldest, and then I'll be able to filter out by pressing the headers"). The table now lists the newest month first. Click any header to sort by that column; click it again to flip the order. The arrow marks the sorted column, blanks go last, and the order stays put when the board refreshes · v6.10.55 — RECORDS AND ROI REFRESH EVERY 30 MINUTES (second independent audit 2026-10-22). A tab left on Records or ROI was meant to re-read them every 30 minutes, on every second 15-minute refresh. That refresh usually came a few seconds short of 30 minutes after the last read, so the re-read slipped to the next one and the real gap was often 45 minutes. They now re-read once the last read is 25 minutes old, which lands on every second refresh · v6.10.54 — ROI PAGE KEEPS YOUR PICKS (second independent audit 2026-10-22). Since v6.10.43 a tab left on ROI re-reads the nightly figures on the board's refresh, and every re-read redrew the page: From/To months picked but not yet applied went back, and every opened source closed, even when the figures had not changed. The page now redraws only when the nightly figures are new, or after a read that failed · v6.10.53 — RANGE "VS PRIOR" PAST TODAY (full board audit 2026-10-22). A range that ended after today compared its days so far with a prior window as long as the whole range: Oct 1-31 viewed on Oct 22 read revenue "▼ 39% $2,283,184 vs $3,757,289" (22 days against 31), and Oct 15 to Nov 15 read deals "▼ 73% 432 vs 1,589". Such a range now compares exactly as the same range ending today does, and a range that starts after today shows "—" instead of "▼ 100%" · v6.10.52 — CAMPAIGN ROWS FROM PART OF A WINDOW (third independent review 2026-10-22). Campaign-level data starts Aug 1, 2026. A By Campaign range that started earlier still offered the campaign drill-down, whose rows held only Aug 1 onward under source rows that cover the whole range: Feb 15 to Oct 22 showed no spend on any source row, yet expanding Google showed TI (Rebuilt) $3,362,622.90, its Aug 1-Oct 22 figure, and Jun 1 to Oct 22 showed the same. Such ranges now have no drill-down and the leads and calls badge says why; it no longer says spend covers every day when the range starts before Mar 3 · v6.10.51 — MONTHLY-ONLY SPEND NOTE (third independent review 2026-10-22). The v6.10.50 note quoted a month's whole undated amount for any window that touched the month: Apr 1-2 read "leaves out $40,915" beside $185,854 of spend. It also pointed to the Monthly view, which shows only the current month. A window covering part of a month now says an unknown share of that month's amount is not included, a whole month gives the amount, and the note names Month-by-Month as the view that counts it · v6.10.50 — SPEND RECORDED ONLY AS A MONTHLY TOTAL (full board audit 2026-10-22). March and April 2026 hold spend in their monthly records that no daily record splits by day: "Unallocated (pending breakdown)" $38,605 and Bing $759 in March, $40,915 in April. Date ranges and Daily CPA add up the daily records, so Apr 1-30 read $1,458,988 against Monthly April's $1,499,811 with no word why. Their headers now name the amount left out; the Monthly view counts it · v6.10.49 — DAILY CPA PLATFORM LIST (full board audit 2026-10-22). Daily CPA has added Bing's daily spend since Oct 20 (DAILY_SPEND_DOCS), but its header still listed seven platforms without Bing. It now names Bing · v6.10.48 — SUB-TAB HEADERS (full board audit 2026-10-22). Trends, Daily CPA and Daily Spend each write their own header and do not follow the date filter. A filter click, Apply or a revenue update replaced it with the Sources header, so the Daily CPA table could sit under "October 2026 month-to-date · 37 sources" and Trends lost "ignores the date filter". The dashboard now writes that header only while By Campaign or Sources Individually is showing · v6.10.47 — DAILY SPEND COMPARISON MONTHS (full board audit 2026-10-22). Spend by day starts Mar 3, 2026, but the Daily Spend tab offered March 2026 as a comparison month. It showed $0 spend on Mar 1 and Mar 2, so every month-to-date difference against March ran high. The list now ends at April 2026, the first month with spend for every day · v6.10.46 — DAILY CPA BEFORE MAR 9 (full board audit 2026-10-22). Spend by day starts Mar 3, 2026. A 7-day CPA whose week reached before it divided part of the week's spend by all of the week's deals: Mar 3 read $449.01 beside its own day's $2,004.13, and Mar 4-8 were low too. A Daily CPA range that started before Mar 3 put part of its spend over every deal in the TOTAL: Feb 20 to Mar 12 read CPA $1,058.67 from 10 of its 21 days. Those now show "—", and the header says spend by day starts Mar 3, 2026 and 7-day CPA starts Mar 9, 2026 · v6.10.45 — NO SPEND FROM PART OF A WINDOW (full board audit 2026-10-22). Spend by day starts Mar 3, 2026, but a date range can start as early as Sep 1, 2025. A range that crossed Mar 3 counted spend for only its later days against every day's deals and revenue: Feb 15 to Mar 15, 2026 read spend $785,494 (13 of its 29 days), CPA $846, ROAS 2.14x and cost per qualified call $227, about half the real cost. A range that starts before Mar 3 now shows no spend, CPA, ROAS or cost per call, and the cards, the Ad Spend header and the Sources header say spend by day starts Mar 3, 2026. Month-by-Month has every earlier month's spend · v6.10.44 — CHANGELOG CORRECTION (code review 2026-10-22). The v6.10.30 entry said closed months were unchanged. Four moved by 0.1-0.3% (March, April, June and July 2026), because their projections count one to three more deals than the board's TIs, and each per-deal figure now divides by its own projection's count. That entry now says so. No figure changes in this version · v6.10.43 — RECORDS AND ROI REFRESH WHILE YOU WATCH THEM (code review 2026-10-22). v6.10.28 said both pages re-read after 30 minutes in an open tab, but they only re-read when their menu button was clicked, so a screen left on Records or ROI kept the figures it first loaded. They now re-read on the board's own 15-minute refresh while their page is open, once 30 minutes have passed · v6.10.42 — RANGE "VS PRIOR" COUNTS CALENDAR DAYS (code review 2026-10-22). A Range is compared with the same number of days just before it, but the window was measured in milliseconds, and the day a clock change happens has 23 or 25 hours. Any comparison touching one came out a day long: Mar 9-15, 2026 was compared with Mar 1-8 (8 days), Nov 2-8, 2025 with Oct 25 to Nov 1, and Sep 1, 2025 to Mar 31, 2026 (212 days) with 213. The prior window is now exactly as many calendar days, ending the day before the range · v6.10.41 — NOTHING FROM THE LAST VIEW STAYS ON SCREEN (code review 2026-10-22). Switching to Range with no dates picked left the six spend cards on the Monthly figures (for example $2,826,498 spend, CPA $2,278, ROAS 0.81x) beside blank deals and revenue. That case, and a range starting before the loaded months, also kept the Monthly Forecast ("1,605", where every Range shows "—"), the Monthly pace notes and the month in the Sources and Ad Spend labels. Month-by-Month, Budget Pacing, Pace, Staffing and the freshness strip stopped refreshing while such a range stayed selected. Both now blank every figure that depends on the dates and keep the other panels live · v6.10.40 — TRENDS PIF % SAYS ITS RULE (full board audit 2026-10-22). In Daily view the PIF % note read "PIF = cumulative paid-in-full to date", the rule from v5.88.0. Since v6.10.22 the column counts a deal as paid in full when its fee is paid within its sale month, the same rule as every other tab. Daily and Monthly now both say so, and that the newest days or this month can still rise · v6.10.39 — PAID IN FULL STOPS WHERE ITS LIST STARTS (code review 2026-10-22). The paid-in-full list is rebuilt hourly and moves its start forward a month on the 1st, while an open tab keeps the deals it loaded. After that refresh, Deals per Agent could still step back to the oldest loaded month and read every agent at 0 paid in full (August 2025 in the test: 49 TIs, 0, 0%), and Trends PIF % showed that month at 0%. Deals per Agent now stops at the list's own start, and Trends shows "—" for a month it cannot answer · v6.10.38 — RANGE "VS PRIOR" NEVER DIVIDES BY A HALF-LOADED WINDOW (code review 2026-10-22). A Range compares against the same number of days just before it, and that window could start before the data the page loads even when the range did not. 9/10-9/30/2025 read revenue "▲ 173%, $1,201,433 vs $440,851", but revenue loads from 9/1/2025, so the $440,851 held only 9/1-9/9 of 8/20-9/9. Deals (loaded from 8/1/2025) and qualified calls (recorded from 5/1/2025) did the same on longer ranges. Those cards now show "—" and say which part of the prior window is missing. Ranges with a fully loaded prior window are unchanged · v6.10.37 — ROI UNALLOCATED NOTE FOLLOWS THE WINDOW (independent audit 2026-10-22). The ROI by Source note always printed the full $287,347.59 of spend that belongs to no source (Jan-Apr 2026), so in "Last 6 months" the source rows plus the note did not add up to the Company row (the window holds $40,915.07) and "Last 3 months" showed it with none in the window. The note now states the window's own amount. Also corrects the v6.10.32 entry: the $63,813.12 moved out of Same-Month was March-August (April-August $63,713.12) · v6.10.36 — TRENDS MONTHLY STARTS WHERE THE METRIC HAS DATA (full board audit 2026-10-22). Monthly listed 22 months, but deals load from August 2025 and revenue from September 2025, so January-July 2025 were columns of "—" on every metric (and August 2025 on Revenue and ROAS), which reads like months with no deals or revenue. Each metric now starts at its first month with a value; Month-by-Month has the full history · v6.10.35 — DEALS PER AGENT: RESOLUTIONS SAY WHEN THEIR FEED BEGAN (full board audit 2026-10-22). The resolutions panel counts the CRM resolution feed, which began the evening of 3/31/2026. For earlier months it read "No resolutions in this window." (August 2025 to February 2026) or a partial count (March 2026: 15 vs 347 in the Reso Log). It now says the feed starts Apr 1, 2026 and points to Month-by-Month for earlier counts. The TI panel is unchanged · v6.10.34 — AGENT, TEAM AND DEALS-PER-AGENT STAY INSIDE THE LOADED MONTHS (full board audit 2026-10-22). Their month steppers walked back past the data: Revenue per Agent and per Team said "No revenue in this window." for August 2025 and earlier, and a custom range starting before the loaded window summed only the part it had (from 8/18/2025: September only). The steppers now stop at the oldest complete month (September 2025 for revenue; August 2025 for Deals per Agent, whose TIs and paid-in-full set load one month earlier), the date pickers start there, and an earlier start shows no figures and says why · v6.10.33 — "COMPARE TO" OFFERS ONLY LOADED MONTHS (full board audit 2026-10-22). The Monthly benchmark picker listed 18 months but this view loads revenue for 13. Picking Apr-Aug 2025 showed "—" for revenue and a blank forecast comparison, and August 2025 compared its deals (loaded) with no revenue. The picker now lists the 13 loaded months; Month-by-Month has the full history · v6.10.32 — SAME-MONTH VS RECURRING USES THE TRUE FIRST SALE (full board audit 2026-10-22). Month-by-Month splits each month's cash into Same-Month (deals sold that month) and Recurring. This page loads TIs from 14 months back, so a case first sold before that and sold a resolution in the window looked new: its payments went to Same-Month. Mar-Aug 2026 Same-Month read $63,813.12 high and Recurring as much low (Mar $100, Apr $11,274.60, May $18,385.83, Jun $8,562.35, Jul $6,280.93, Aug $19,209.41). The nightly job now publishes those cases' real first-sale month and the table uses it. Total revenue was never affected · v6.10.31 — NO NUMBERS FROM A HALF-LOADED RANGE (full board audit 2026-10-22). This view loads deals and revenue for the last 13 months, but a custom range could start earlier: June 2025 read 0 deals and $0.00 revenue, and a range from 8/18/2025 showed only September's revenue. The date picker now starts at the first loaded day, and a range that starts earlier shows no figures and says why (Month-by-Month has the full history) · v6.10.30 — PER-DEAL FIGURES USE THE DEALS THEY COVER (full board audit 2026-10-22). The lifetime projection is computed around 6:27 AM and cash per cohort every ~20 minutes, but Per-Deal Economics and the Month-by-Month per-deal lines divided those totals by the live deal count. For October at noon that put 1,213 deals' projection over 1,241 deals: lifetime/deal $1,499 instead of $1,533, sliding lower all day. Each per-deal figure now divides by its own total's deals, Lifetime ROI is Lifetime/deal ÷ Cost/deal, and Month-by-Month Projected ROAS uses the same rule so the two tabs agree. Four closed months moved by 0.1-0.3%, because their projections count one to three more deals than the board's TIs: March 950 against 949, April 1,016 against 1,015 (earned only), June 922 against 921 and July 1,013 against 1,010 (corrected in v6.10.44; this entry first said closed months were unchanged) · v6.10.29 — DAILY, WEEKLY AND RANGE COMPARE LIKE MONTHLY (full board audit 2026-10-22). (1) Daily read "▼ 61% vs yesterday" at noon: a running today against a complete day, with nothing saying so. Daily, Weekly and Range now say "today still running", the note Monthly already carries. (2) A Sat-Sun range read "▼ 100%" on calls and deals and "calls not yet synced": the calls were synced and the closer teams were off. A window with 0 selling days is no longer scored as a % (cash still is, it posts on weekends), and a synced zero reads 0. (3) Weekly's label said "vs last week"; it compares the same days of last week and now says so · v6.10.28 — FRESHNESS YOU CAN TRUST (full board audit 2026-10-22). (1) The Spend chip checked Google, Meta, TikTok, Taboola and ChatGPT for a pull that fell behind, but never StackAdapt or Reddit (Reddit writes nothing on most evening runs), and never Bing. It now names any of them; Bing, pulled once a day at 6 PM, is flagged only when that pull is over a day old. (2) The Ad Spend header said refreshed hourly; it runs hourly 7:15 AM-8:15 PM on weekdays, at 6 AM daily, and Bing at 6 PM. On a date range it also said Google spend was in Total only, false since v6.10.24 (every Google day is split by campaign). (3) Deals per Agent now says when it last read the CRM deals table (every 20 minutes), which explains a one-deal gap against the hero card. (4) Records shows when it was computed, and Records and ROI by Source re-read their data after 30 minutes in an open tab instead of keeping the first load forever · v6.10.27 — ROI BY SOURCE ADDS UP (full board audit 2026-10-22). For deals sold Jan-Sep the source rows held $15,987,237 of spend while the Company row held $16,307,953; only the $287,348 Unallocated was explained. The other $33,368 was spend in months a source sold no deals (StackAdapt $13,582, so no row at all; DG $9,111; Bing's February $1,689) and Reddit's $8,987, which the nightly job bucketed but never gave a row. Every month with spend now counts toward its source (it bought nothing, so it lowers that source's back per $1), and Reddit has its own row. Months with deals but no spend still stay out (v6.4.2) · v6.10.26 — LIVE TRAFFIC SHOWS THE LAST TEN MINUTES (full board audit 2026-10-22). The per-minute chart's newest ten bars were always empty and labelled not reported yet. GA4 had reported them: the writer (syncGa4Realtime) read GA4's two-digit minute keys as 0-9, so it stored zeros (fixed and deployed 2026-10-22; at 1:30 PM those minutes held 98 users). The chart now draws every minute GA4 reports, mutes only the current minute, and labels each bar with its real minute (they read one minute too old) · v6.10.25 — FOUR LABELS THE NUMBERS DID NOT SUPPORT (full board audit 2026-10-22). (1) Year to Date printed Qualified Calls +13.0% vs last year in green, but the closer teams changed in 2026 (the TI team is 2026-only) and the teams both years share were down 7.2%; that row, Cost per QC and Closing % are no longer compared year over year, the rule the Qualified Calls card already follows. (2) Sources leads and calls start 2026-08-01, so a range like 7/25-8/10 showed 2,409 leads and a $422.32 CPL from 10 of its 17 days; the Total now says how many days are covered and shows no CPL or CPC on a partial window. (3) The Sources CPL/CPC tooltips said Spend / Leads; on Sources Individually they use the campaign's whole spend, and the Calls tooltip claimed the feed runs ~19h behind (it is minutes). (4) The Staffing wall heading said drops rise as calls pile up while its table showed them falling · v6.10.24 — SOURCES ROWS ADD UP TO THE TOTAL (full board audit 2026-10-22). Sources Individually left $17,609.37 of October's spend, 49 leads and 6 calls off every row: rows came from deals only, so ChatGPT, Reddit, StackAdapt and CST TikTok spend had nowhere to land, and the ChatGPT form row owned no campaign. On any date range both views put every Google dollar on a label no row owns: a September range showed $801,883 of $3,051,536 on the By Campaign rows. Google days are now split by campaign from the daily per-campaign pull, every paid campaign with spend, leads or calls gets a row in both views, and Individually maps sources to campaigns with the same rule as By Campaign · v6.10.23 — SMALL TRUTH FIXES (full board audit 2026-10-22): Revenue per Agent's footer counts distinct cases like Revenue per Team (2,869 vs 2,824 for the same window); Trends > Spend names the Taboola row Taboola, not Yahoo; the Daily Spend tab gives Bing its own row instead of folding it into Other · v6.10.22 — ONE PAID-IN-FULL NUMBER (owner 2026-10-22, full board audit): June 2026 read 470 paid in full on Month-by-Month, 497 on Sources, 503 on Daily CPA and Deals per Agent (and 486 on Company Accolades). Every tab now asks one question, isPaidInFull, answered hourly from the Auto-QA tracker's inputs (pif_monthly/paid_in_full): the investigation fee at the sale, paid by Investigation-type payments dated in the sale month, less a sale-month PIF credit of at most $200, with no investigation refund. That drops resolution cash (871188: $11,000 in its sale month counted as an investigation PIF), refunded deals and resolution discounts (874954: $197.50 paid on $595 read PIF after a $3,886 credit) · v6.10.21 — ONE DEAL COUNT ON EVERY TAB (full board audit 2026-10-22). (1) Doc 839533_dup_1, marked by the feed itself as the CRM trigger firing the same case twice within a minute, counted as a second April 2026 deal everywhere; docs flagged _duplicate_fire are left out. (2) Month-by-Month skipped the four April 2026 TIs whose docs carry no case number (1,012 vs the hero's 1,016). (3) Per-Deal Economics divided closed months by the invoice precompute's own count (Mar/Jun/Jul 2026: 950/922/1,013 vs 949/921/1,010). The hero, Month-by-Month and Per-Deal now show the same Deals (TI) for every month · v6.10.20 — ONE END-OF-MONTH NUMBER ON THE REVENUE TABS TOO (owner 2026-10-22, full board audit): Revenue per Agent's footer read $3,135,225 and Revenue per Team's $3,116,940 while the Forecast card and the Pace tab read $3,256,781, because each table added up its own per-row projections. Both footers are now the Forecast card's number; each row's hist_blend projection is scaled by one factor, so the ranking is unchanged · v6.10.19 — ONE END-OF-MONTH NUMBER (CMO 2026-10-22, screenshots: the Forecast card read $3,198,395 and the Pace tab $3,249,412 for the same October). The Pace tab now shows the Forecast card's projection, and the Forecast no longer counts today's half-posted revenue as a finished day: complete days + today and the days left at their 90-day day-of-week averages, so it holds steady through the day. This month's biz-day pace stays as the cross-check on both. · v6.10.18 — DEALS PER AGENT SORTING (CMO 2026-10-21). Click any column header on the Investigations or Resolutions table to sort by it (names A→Z, numbers high→low); click again to flip. # follows the current order, TOTAL stays at the bottom, and the sort holds through live updates and window changes. · v6.10.17 — BING SPEND (Microsoft Ads live again 10/20). Daily CPA and date ranges now read the bing_{date} spend docs; the month view gets Bing through the hourly autofill. Bing spend is entered daily from the Microsoft Ads screen until the API pull exists ($211.94 on 10/20). · v6.10.16 — DEALS PER AGENT: PAID IN FULL + PIF % on the Investigations side (CMO 2026-10-20). Same rule as Daily CPA and Sources: the TI fee (net of any PIF credit) collected within the sale month; recent sales can still rise until the month ends. Resolutions side pending a definition. · v6.10.15 — BING FORM DEALS (Bing live again 10/20 after the strike). Logics writes Bing form cases as "IRS Fresh Start Bing Form"; it now maps to the Bing row in every view, so Bing spend is charged to Bing form deals too. Bing spend is $0 until the Microsoft Ads API (or a daily number) is wired. · v6.10.14 — YEAR TO DATE TABLE on Month-by-Month (CMO 2026-10-15: "I need a year-to-date type of table"). This year to date, this year vs last year over the same complete months with the change, and each full prior year back to 2023. Every figure sums the month rows below it; rates are worked out from the totals. · v6.10.13 — DAILY CPA SHOWS PAID IN FULL (CMO 2026-10-14: "after deals, let's put deals paid in full and then paid-in-full percentage"). Two new columns after Deals: how many of that day\u2019s deals were paid in full, and the percentage, with both in the total row. Same rule as the Sources tab\u2019s PIF column (fee paid within the sale month, net of any PIF credit), so the tabs agree; recent days can still rise until the month ends. · v6.10.12 — CAMPAIGN ROWS NOW COUNT CALL DEALS (CMO 2026-10-08: "attach each call to the proper campaign... so we can see the cost per acquisition per campaign"). A Google deal that came in by phone, not by form, now reaches its campaign row when the caller\u2019s phone appears in Google\u2019s Call details report (which names the campaign for every ad and website-number call; ingested daily into google_call_details). Before this, those deals (144 of 327 October Google deals) counted only on the source row, so every TI campaign read about $4,400 per deal while the source read $2,464. Each campaign\u2019s Deals cell shows how many came by phone, and the parent\u2019s TRACED note splits form vs call. Still untraced: callers the report has not matched (manual download, so the newest days lag) and calls Google never recorded. · v6.10.11 — DAILY SPEND TAB (CMO 2026-10-06: "we need a daily spend and somewhat of a comparison from this month versus last month ... What's the delta?"). New Sources tab next to Daily CPA: each day of this month next to the same day of a chosen earlier month (Oct 1 vs Sep 1), the difference in dollars and percent, running month-to-date totals through the same day, and a platform table with each one's share. Same daily spend data as Budget Pacing. · v6.10.10 — DEALS PER AGENT COUNTS TIs FROM THE CRM (Motion task, CMO 2026-10-06). The Investigations panel counted the live deal feed, which misses some sales and can carry a different agent name: September read 1,163 TIs against the CRM's 1,168, with 8 of 62 agents off by 1 or 2. It now reads the CRM deal records, refreshed every 20 minutes. ADServe sales are still left out. Resolutions are unchanged. · v6.10.9 — 18 MORE ACCOLADES (CMO 2026-10-05: "i feel like there's more KPIs we are not looking into" ... "add all of them"). Resolutions sold (day, month, agent, team), resolution revenue by agent, revenue in a day, paid-in-full rate (company, agent, team), TIs paid in full by agent, tax debt signed up (company, team), lowest cost per deal, best return on ad spend, qualified calls in a day, calls an agent talked through in a day, and the longest same-day paid-in-full streak. The page now shows percentages, return on ad spend, streak days and lower-is-better records. · v6.10.8 — ACCOLADES IN THREE SECTIONS (CMO 2026-10-05: "We need company records, individual records, group records"). Company Accolades now groups its cards under Company records, Individual records and Team records. New: Most paid in full in one day counts SAME-DAY payoffs like the tracker (the month version keeps its own card), plus agent and team versions, highest revenue in a month for an agent and for a team, and team records for most investigations in a day and a month. · v6.10.7 — LEADS AND CALLS ON SOURCES INDIVIDUALLY (CMO 2026-10-02: "add leads and calls to this tab"). The four columns only filled in on By Campaign. Leads now show on each campaign's Form row and answered calls on its call row (both on the one row when a campaign has only one), and CPL and CPC use the campaign's whole spend, the same numbers By Campaign shows. The footer totals show on both tabs. · v6.10.6 — NEW VERSIONS LOAD BY THEMSELVES (CMO 2026-09-30: "I have to do a new tab or duplicate the tab, and then delete the old one or deep refresh it"). A tab left open kept the old page code after every deploy. The page now checks the server for a new version every 5 minutes and whenever you come back to the tab (a HEAD request, no download) and reloads itself when there is one, but never while you are typing in a field. · v6.10.5 — BUDGET PACING ON THE LAST BUSINESS DAY (CMO 2026-09-30: "what the heck is going on with the dashboard"). With 1h 24m of business time left, the card divided the $103,743 left by 0.16 of a day and showed "$666,920 per full business day" with "on track". When less than one full business day is left, the card now reads "Left for today: $103,743 · last 1h 24m of 8 AM-5 PM · your pace would spend about $23,000", and the header warns if the pace would spend more than what is left. Every other day is unchanged. · v6.10.4 — THE BOARD NOW SAYS WHEN REVENUE IS BEHIND (CMO 2026-09-30: "I never want to keep on refreshing the dashboard. It should always refresh by itself."). Revenue and deals already stream live; the problem was that the Logics revenue report came back empty to every pull from 2:25 to 3:15 PM, so there was nothing new to show and the board still read "current as of 2:15 PM". The SOComm pull now writes a heartbeat on every run and keeps retrying through its 10-minute slot; the board listens to it live, so the line by the Sync button turns amber with "Logics hasn't answered since 2:15 PM (40 min), so revenue may be behind" and the Revenue chip goes amber after 30 minutes without a good pull. Coming back to the tab after 5+ minutes re-reads spend, calls and the precomputes immediately. · v6.10.3 — BUDGET PACING COUNTS TODAY'S REMAINING HOURS (CMO 2026-09-25: "since today is also a day that I'm going to spend, might as well add the hours there too. 8 to 5 is the time when I spend most of my budget"). Business days left now reads like "3 days 8h 23m": the full business days after today plus what is left of today's 8 AM–5 PM Pacific window, ticking every minute. Spend per day divides the remaining budget by that time (per full business day). The pace beside it now uses COMPLETED business days only (spend through yesterday ÷ business days through yesterday): it used to count today as a whole elapsed day, so it read low every morning. Today is split on the clock, never counted as both spent and available. · v6.10.2 — PIF AGAINST THE NET FEE (CMO 2026-09-24 audit: "is this accurate?"). The Sources and Trends PIF compared same-month cash with investigations_sold.total_fees, the gross fee written at the sale. When Logics adds a discount days later (a $200 "PIF Credit") and the client pays the net amount in full, the deal read "not PIF". A deal with an investigation PIF credit now uses the net fee from pif_monthly/net_fees (refreshed hourly): the Discount lines dated in the SALE MONTH, each at most $200 and capped at $200 in total, from the Logics invoice mirror. Later or larger credits are resolution/tax-prep concessions and are ignored; a first cut that netted every discount on the case was caught in review before shipping (it would have flipped deals like 818468 on an August resolution credit). Never raises a fee and leaves 2025 (no fee data) untouched. Checked: only ever flips TO PIF (Jan-Sep 2026: 8/26/35/24/34/24/22/20/12), the reviewer's 6 false flips stay put, 5 of 5 sampled Feb-Jun flips confirmed in Logics as PIF credits paid net in the sale month; Sept PIF 406 → 418 of 909 (45% → 46%), the 13th deal (879915) follows its next invoice sync. Same audit, fixed upstream in campaign_metrics_daily: calls were filed a day early (Sept -216 calls, every cost per call ~6% high), Clear Start Tax Meta/TikTok leads were counted as Fresh Start (CST Meta 18 → 307 leads, CPL $1,377 → ~$81), and the Facebook overflow + Reddit queues were unmapped. · v6.10.1 — RESOLUTION OPPORTUNITIES CARD OFF THE DASHBOARD (CMO 2026-09-24, after the Month-by-Month columns shipped: "This is still on the dashboard."). The number lives in the Month-by-Month table now (Resolution Opportunities · This Month, same oppByDay series). The scoreboard is back to the v6.9.1 three cards, markup and CSS identical, and the v6.9.2 four-card sizing goes with it. Its stacked-layout stretch stays: on a 390px phone it is what keeps the Month-by-Month table scrolling inside its box instead of making the page 3,849px wide. · v6.10.0 — RESOLUTION COLUMNS ON MONTH-BY-MONTH (CMO 2026-09-24: "a column for resolution opportunities and resolution sold, so two columns for this month and then two columns for cohort"). THIS MONTH: Resolution Opportunities (cases that first hit Ready To Present that month, any cohort; the series the headline card sums) beside Resolution Sold. LIFETIME · COHORT: of the month's TIs, how many ever became an opportunity and how many were ever sold a resolution, each with its share of the TIs. Resolution Sold now reads the LIVE Reso Log sheet (the frozen CSV was an export of it): same counts to the row 2023-07..2026-01, May 484 → 530 (the CSV was taken May 29), Jun-Sep from the Reso Log instead of the resolutions_sold stand-in (June 553 → 596), and Revenue Per Resolution fills again from June. The opportunity history also takes the Reso Log's Ready To Present rows: April 2026 +101 (events MySQL holds without a case ID), September 788 → 789. Column manager: header tags derived from the leaf list, new columns land beside their neighbour in a saved order, and Resolution Sold is un-hidden once. · v6.9.3 — DAILY SPEND NOW FOOTS TO THE MONTH (CMO 2026-09-24: "It says the 7-day CPA is 2,400. But over at the dashboard, it's still 2,700. Is that right?"). The two windows were right (Sept 18-24 = $2,410; Sept 1-17 ran $2,913), but the check found every daily-spend view short: the Meta gross→billed scaling compared BOTH brands' daily Meta against the Fresh Start billed figure alone, so the Clear Start Tax Meta spend was scaled away as a "credit" ($20,271 in August, $24,688 in Sept 1-24), and the Reddit + StackAdapt daily docs were never read ($16,391 in Sept 1-24). Hit: the Daily CPA tab (daily, 7-day, total), Daily/Weekly/Range spend, CPA and ROAS, the CPQC "thru" card in every mode, and the cohort MTD CPQC. One shared reader now: every platform, spend on its brand, Meta scaled per brand. Sept 1-24 daily total $2,467,666 → $2,508,746, matching the Ad Spend card. · v6.9.2 — NEW HEADLINE CARD: RESOLUTION OPPORTUNITIES (CMO 2026-09-24, relaying Stephanie Holland: "total opportunities sent back this month?"). Cases sent back to sales as a resolution opportunity — the case hit "Resolution Pending: Ready To Present (Appt. Pending)" — each counted once on its first day, summed over the same window as the other three cards and compared with the same days last month. Same event the Month-by-Month "TI → Reso Opp %" column uses; that column is a cohort RATE, this is the COUNT by the day it happened, which the board did not show. Refreshed hourly by reso-conversion-precompute (oppByDay). Verified against an independent MySQL count, every one of 727 days: Sept 1-24 = 788 vs Aug 1-24 = 538. Dates checked against Logics' own activity log (same day, no sync lag; the 9/8 spike of 186 is a real batch moved at 7:19 AM PT). Month-over-month only: 2025 exists only in a backfill that may be incomplete, so a year-over-year would compare two different sources. Scoreboard is four across when the board is wide enough and two by two when it is not, decided on the board's own width (side nav included), and each headline number sizes to its card, so the penny-exact revenue never runs into the next card. · v6.9.1 — ADSERVE ON THE REVENUE PER TEAM TAB (CMO 2026-09-23: "I think we need to add ad serve there too"). ADServe Team has been excluded from every company figure since 2026-05-20, so it is NOT a sortable team row: it sits under the company total as "+ ADServe Team", followed by "Gross incl. ADServe" — the same convention as the headline cards' "+ ADServe → total" line. Every company number, Share included, is unchanged and still equals the hero card and Revenue per Agent. The row reads the same array and the same window as the hero card, and carries its own agents, payments, cases, forecast and YTD. · v6.9.0 — NEW TAB: REVENUE PER TEAM (CMO 2026-09-23: "I also need a revenue per team tab"). Revenue per Agent, grouped by team: same source (company revenue, ADServe excluded, net of refunds, the hero card's figure) and the same Daily / Weekly / Monthly / Range picker with the month stepper, so for any window the team total equals the agent total to the dollar. Team is the team SOComm credits each payment to, i.e. the Team column already on Revenue per Agent. Columns: Revenue, Share, Agents, Payments, Cases, Avg revenue per case, Revenue per agent (so teams of different sizes compare fairly), Proj. EOM (the agent tab's hist_blend keyed by team, which that tab's own note puts at ~12% median error at team level vs ~25% per agent) and YTD. Peak Performers is folded into Money Mafia so the YTD column cannot split the team across its 2026-06-26 rename. Footer agent and case counts are distinct across teams. ALSO FIXED on Revenue per Agent: its YTD footer summed only the agents shown in the selected window, so every rep with nothing that month fell out of it. Measured 2026-09-23: it read $19,142,923.50 against a true 2026 YTD of $19,562,555.31, short $419,631.81 across 150 reps with no September revenue. Both tabs now total the whole calendar year, and agree. Filter buttons got their own CSS rule on day one (the v5.91.0 Deals-tab miss). · v6.8.4 — THE DRILL-DOWN NOW RECONCILES ITSELF ON THE PARENT ROW (CMO 2026-09-17: "Total is 361, but on the dropdown, it's only around 171"). Measured before changing anything, Sept 1-17, IRS Fresh Start Google: 365 deals on the source row, 171 on the campaign rows, gap 194. Classified all 194 — 180 (93%) have NO form lead at all, 7 have a form lead carrying no campaign_id, 6 are TikTok/Meta form leads the CRM labelled Google, 1 tied to HVT and renders under that source instead. Cross-checked against the CRM's own labels, which already split call from form: 154 deals labelled "…Google Form" of which 143 are on the campaign rows, and 211 labelled inbound-call of which only 29 tie (callers who had filled a form earlier). So the campaign rows are not missing deals — they are the traceable subset, and the untraceable rest is the phone. The Deals cell on a source WITH a drill-down now carries that subtotal as a small "N TRACED" sub-line plus a tooltip stating the split. It renders only where campaign rows exist, which is structurally why it cannot repeat the v6.8.3 mistake of appearing under Meta, TikTok and Taboola. · v6.8.3 — REMOVED THE "Call-origin — no campaign" ROW (CMO 2026-09-17: "I don't need this call original campaign. It's too dirty."). It was also plainly broken: the row was appended OUTSIDE the campaign map, so it rendered under EVERY source — Meta, TikTok, Taboola, CST Tiktok and the rest, none of which have campaigns or a drill-down at all — each one claiming every deal it had was call-origin. Even where it was correct (the four Google buckets) it bought a reconciliation nobody asked for at the cost of a repeated italic row down the whole table. Gone, along with its CSS. The fact it was carrying — that a campaign row counts only deals traceable through a form lead, so campaign rows always total less than their source — now lives in the Deals cell tooltip, which is where it belongs. v6.8.2's real fix (a single missing Google Ads pull no longer voids a whole window of spend) and the single-campaign dropdown removal are untouched. · v6.8.2 — THE DRILL-DOWN LOOKED LIKE IT CONTRADICTED ITS OWN PARENT (CMO 2026-09-17: "I'm confused here. Why are the numbers different?"). Three separate causes, only one of them a bug. (1) THE BUG: a single day with no Google Ads pull voided the spend for the WHOLE window. This morning's hourly run hit the Explorer-tier cap, so 2026-09-17 was written null and TI Rebuilt rendered "n/a" against $1,014,717 of real spend, while newer campaigns whose every day happened to land in a good pull showed figures — which is why some rows had spend and others did not. Now the known days are summed and the missing ones are counted: the cell shows the figure with a small "+Nd" marker meaning N days in this window had no pull. (2) DIFFERENT DEAL POPULATIONS, not a disagreement: a source row counts every deal with that CRM label; a campaign row can only count deals traceable to it through a form lead, and 56% of Google deals are inbound-call deals with no lead record. Measured on HVT: parent 7 deals and child 7 deals, but only SIX are the same case — the parent holds 892774 (an inbound-call deal labelled "- 2HVT") and the child holds 892475 (tied by form to the HVT campaign but labelled another source in the CRM). Same count, different deals, so PIF 57% vs 71% and avg debt $33,354 vs $32,640 are both right about different sets. CST is the extreme: 6 deals on the source, 1 traceable, the other 5 all inbound-call. The drill-down now ends with a "Call-origin — no campaign" row carrying the untraceable remainder, so the Deals column adds up to the source total instead of looking like the campaigns disagree. (3) REVENUE MEASURES DIFFERENT THINGS AT THE TWO LEVELS and always will: a source row shows cash collected IN the window from every case with that label, including deals sold months ago still paying (HVT $120,257); a campaign row shows cohort cash TO DATE from the deals it can claim in this window ($2,580). Neither is wrong and no relabelling makes them sum, so the campaign cells now carry a visible "TO DATE" / "COH" marker rather than sitting silently under a header that means something else one row up. ALSO: a source with only ONE campaign no longer offers a dropdown (CMO: "I don't think we need to have a dropdown if there's only one campaign") — HVT and CST Google are each a single campaign, so the parent row IS the campaign and a disclosure that restates it only invited the comparison. Active campaign count for the record: 15 enabled, of which 7 are the ones you think of as the account — TI Rebuilt, R1, Advertorial-AH, Landingpage-AH, HVT, Demand Gen, CST Search TI — plus CST CTV at $0, six Demand Gen channel tests created 9/16, and a system-generated Local Services campaign. · v6.8.1 — CAMPAIGN ROWS CARRY THE FULL KPI SET (CMO 2026-09-16: "we should be able to track paid in full, paid something, paid nothing, the revenue, the average tax debt"). Each campaign row under Google / HVT / DG / CST now fills Avg Tax Debt, PIF, PS, PN, Revenue and ROAS over its form-origin deals, computed in the precompute with the BOARD'S OWN RULES so a campaign reads the same way its parent does: Avg Tax Debt = investigations_sold.tax_liability where > 1; PS = any cumulative cash; PIF = same-month cash >= total_fees - 0.01; PN = no cash; cash = revenue docs under the board gate (canonical id + _from_report, ADServe team excluded); PIF/PN cells use the same colour thresholds. ONE DEFINITION DIFFERS, ON PURPOSE AND ON THE CELL: a campaign's Revenue and ROAS are COHORT cash to date from its deals (payments carry a source, not a campaign, so in-window cash cannot be split per campaign), while the source row shows cash collected IN the window from all deals — the tooltip says so, and the two are not meant to add up. Coverage on September: 371 of 374 Google deals have an investigations_sold doc, 347 a tax liability above the sentinel, 371 a fee. CALLS PER CAMPAIGN, investigated: answered calls cannot be split (the TI search campaigns share T#_FSI_GOOGLE), but click-to-call CAN — phone_click_leads.campaign_id is 98% populated (Sept: Rebuilt 1,438, R1 56, Advertorial-AH 18, Landingpage-AH 4). It is now stored per campaign as call_clicks in the day docs but deliberately NOT rendered: putting "call clicks" under the Calls header would put two different things under one label. Rendering it, or splitting answered calls with per-campaign phone numbers, is the CMO's call. · v6.8.0 — LEADS / CPL and CALLS / CPC on every Sources row, and a CAMPAIGN DRILL-DOWN under Google (CMO 2026-09-16: "add leads cost per lead and then calls cost per call, right in between spend and deals" and "click on the source, and it would have a dropdown of the variations of the campaigns"). The Sources table had no per-source leads or calls at all; calls existed only company-wide (team_call_counts_daily) and leads nowhere. Both now come from a new per-day precompute, ad-intel campaign-metrics-precompute.mjs, writing campaign_metrics_daily/{date} (hourly + nightly), so any Time Filter window is a plain sum of day docs. LEADS = form submissions (lead_compliance) resolved to the board source: Google by campaign_id into its Google / HVT / DG / CST buckets, everything else by landing path, utm_source or click id, nothing left stranded. CALLS = inbound calls on the source-tagged Ytel queues (T1-T4 + the overflow queues), with the qualified count in the tooltip; the call feed is processed ~19 hours behind the phone (avg 1,132 min), so each doc carries calls_watermark and the cell says which day the feed has reached rather than showing a false zero for today. DRILL-DOWN: sources with campaigns under them get a small triangle; clicking it reveals one row per Google Ads campaign (TI Rebuilt / R1 / Advertorial-AH / Landingpage-AH / HVT / DG / CST) with spend, leads, CPL, calls, CPC, form-origin deals and CPA. WHAT IT CAN AND CANNOT SAY, measured on September: per-campaign LEADS are complete (2,213 of 2,213 Google leads carry a numeric campaign_id); per-campaign DEALS are FORM-ORIGIN ONLY, because 56% of Google deals are inbound-call deals with no lead record and cannot be tied to a campaign by anything we hold, and the column tooltip says so; per-campaign CALLS exist only where a campaign has its own phone queue (HVT, Demand Gen, CST) and read "—" for the four TI search campaigns that share T#_FSI_GOOGLE, never 0. TWO THINGS FOUND ON THE WAY: (1) the Google landing-page template sends camp={campaignname}, which is not a Google ValueTrack macro, so campaign_name is the literal string "{campaignname}" on every Google lead — attribution keys on campaign_id (campid={campaignid} expands correctly); (2) the Google Ads developer token is Explorer tier with a daily operation cap, tripped at 2:30 PM PT on 9/16 by the day's probing (429 RESOURCE_EXHAUSTED, retry in 66,774 s), and searchStream returns that error INSIDE the array where (chunk.results||[]) reads as zero rows — the precompute now surfaces it and writes per-campaign spend as NULL (rendered "n/a"), never as $0, until the pull recovers; per-SOURCE spend is unaffected because it still comes from ad_spend. Leads and calls render only in the By Campaign view; Sources Individually splits by CRM label, which these feeds do not carry. · v6.7.0 — THE END-OF-MONTH PROJECTION WAS LAST MONTH'S SHAPE, NOT THIS MONTH'S RATE (CMO 2026-09-13: "is that right? ... i need the projected to be in the area of what its projecting, its simple math"). The card read "Projected September EOM $4,288,721" off `curCum[aP] * (lastTotal / lastCum[aPl])` — September-to-date multiplied by August's front-to-total ratio. That does not extend September's pace; it assumes September finishes the same MULTIPLE of its opening that August finished of its opening, so a strong start gets amplified by a ratio that describes a different month. September 1-12 ran $136,445 per selling day, 42% above the strongest opening any month on file has posted, and the formula multiplied that elevated base by August's 3.757x to reach $4,288,721 — which required the remaining 13 selling days to average $242,099 against a best-ever back half of $159,299 (August 13-31). It was projecting a month 52% better than anything the company has ever done and labelling it "projected", not "best case". Now it is the run rate, split weekday vs weekend/holiday the way the hero card already splits it because a Saturday and a Tuesday are not interchangeable: revenue to date + remaining selling days x the observed rate per selling day + remaining weekend/holiday days at their own rate. September reads $2,977,558 against August's $2,821,931 — still ahead, and reachable rather than aspirational. DELIBERATELY NOT BAKED IN: revenue back-loads every month (rate in days 13+ vs days 1-12 was 1.52x May, 1.70x Jun, 1.10x Jul, 1.70x Aug, average 1.50x), so a flat run rate reads LOW. That multiplier is a forecast rather than a measurement, so it is surfaced in the stat's tooltip ("at the average this month finishes nearer $3,864,454") instead of the headline. The verdict banner, the percentage and the too-early guard from v6.0.1 are untouched. Verified before shipping by lifting the new formula verbatim and running it over the real September documents: it reproduced the OLD $4,288,719 from the old expression (confirming the right line was found), returned $2,977,558 from the new one, and its day arithmetic footed — 8+4 elapsed, 13+5 remaining, 30 total, 21 selling days. · v6.6.0 — REDDIT IS ITS OWN SOURCE (CMO 2026-09-08: "need the reddits on the sources"). Logics created four Reddit sources — 97 "Clear Start Tax Reddit Form", 98 "IRS Fresh Start Reddit Form", 99 "Clear Start Tax Reddit", 100 "IRS Fresh Start Reddit" — and the board handled NONE of them: the word "reddit" appeared zero times in this file. Every FSI Reddit deal would have fallen through the whole normalizeSource chain unchanged, missed CANONICAL_CAMPAIGNS, and landed in "Other (non-paid)" with the call and form labels sitting on two separate spend-less rows; isPaidDealSource returned false so they would also have been counted as organic in the hero card's paid/organic split; and platformForSpendSource sent any future Reddit spend to "Unallocated". Fixed the way Bing and StackAdapt were: "IRS Fresh Start Reddit" is now a SPEND_SOURCE (so a canonical row) and is PINNED into the Sources table — with 0 deals and $0 spend the row would otherwise not render at all, which is the precise invisibility the pin list was added for on 2026-06-11; drop the pin once Reddit has steady data — "IRS Fresh Start Reddit Form" folds to it via FORM_TO_PARENT — deliberately NOT LEGACY_COLLAPSE, which runs in every view mode and would have destroyed the call/form split exactly as it nearly did for StackAdapt in v6.5.1 — normalizeSource gains a /reddit/i branch, isPaidDealSource counts it paid, and Reddit joins SPEND_PLATFORM_ORDER. Position of the new branch is not load-bearing (nothing else matches "reddit" and "reddit" matches nothing else), which is the opposite of the stackadapt/native ordering trap. THE CST PAIR IS DELIBERATELY LEFT ORGANIC: the Reddit ad account (jjrvo13jjgjo) sits under the FSI business and there is no CST Reddit campaign, so "Clear Start Tax Reddit" keeps routing to "Clear Start Tax (organic)" alongside CST's other community surfaces (Quora, YouTube, LinkedIn, Medium, Pinterest). One line in the CST guard flips it if a paid CST Reddit campaign ever launches. Verified before shipping by running the EDITED normalizeSource/isPaidDealSource over all four CRM labels in both view modes. State at wiring: 0 Reddit deals in MySQL deals, 0 Reddit spend keys in ad_spend m_2026_07/08/09, 0 Reddit revenue docs — the sources were created ahead of launch. ⚠ Spend is NOT auto-pulled: GSM holds no Reddit OAuth app, so the row shows deals against $0 until the Ads API v3 developer app exists; add the sync-daily-spend pull and autofill platMap entry together at that point. lifetime-roi-precompute's bucket() gained the same branch so the ROI by Source page splits Reddit out instead of dropping it into Other. · v6.5.1 — StackAdapt keeps its call/form split. "IRS Fresh Start Native - Form" was in LEGACY_COLLAPSE, which runs in EVERY view mode, so the form label folded into the parent even on "Sources Individually" and StackAdapt would have been the one paid channel with no call/form split. Moved to FORM_TO_PARENT only (campaign/trends), matching "IRS Fresh Start Yahoo Form". Found by running the DEPLOYED normalizeSource over every label the CRM can now write, after n8n created "IRS Fresh Start Bing Form" (SourceID 102) at 10:37 AM: that same test proved Bing Form and Chatgpt Form already fold correctly in campaign mode and split correctly in individual mode via the 2026-07-17 durable fallback, so neither needed a change. · v6.5.0 — STACKADAPT IS ITS OWN SOURCE; BING SEPARATED FROM GOOGLE (CMO 2026-09-04: "need stack adapt here now · We have bing now too"). StackAdapt native went live 2026-09-03 (campaign group 406207, account 38208). Until today its CRM sources — "IRS Fresh Start Native" and "IRS Fresh Start Native - Form" — COLLAPSED INTO the Yahoo/Taboola bucket, which was right while Taboola was the only native vendor and wrong the moment a second one launched: StackAdapt deals were credited to Taboola and both rows' CPA was wrong. Native now maps to its own "IRS Fresh Start StackAdapt" row (the 2 legacy 2025 "Native" deals move with the label); advertorial "Articles" stay with Taboola, which is what they are. The normalizeSource chain tests stackadapt/native BEFORE the yahoo|taboola|article line, because that line still matches the word "native". Spend now flows: sync-daily-spend pulls campaignDelivery per day and autofill rolls it into m_YYYY_MM ($403.54 on 2026-09-03, 451,402 impressions, 245 clicks). 🔴 THE STACKADAPT TRAP, verified before wiring: a SINGLE-DAY window returns $0.00 — from=2026-09-03&to=2026-09-03 gives $0.00/0 impressions while from=2026-08-01&to=2026-09-04 gives the full $403.54 all bucketed on 09-03. A per-day loop, the obvious way to build daily docs, would have written a silent zero for every StackAdapt day. The sync queries a RANGE and reads records.nodes[].granularity.time, refuses a from==to window outright, and asserts the day sum foots to the API total before writing. (Two more shape notes: the granularity enum is DAILY not DAY, and the time-series dataType is GRAPH not CHART — TABLE+DAILY returns one row per CAMPAIGN with no date, which looks like daily data and is not.) Bing was already a first-class row here but lifetime-roi was folding its spend into Google; it now stands alone ($759 / 2 deals). ⚠ Bing spend is NOT auto-pulled: GSM holds MICROSOFT_ACCOUNT_ID / ACCOUNT_NUMBER / CUSTOMER_ID / DEVELOPER_TOKEN but no OAuth client id, secret or refresh token, which the Microsoft Ads API requires. · v6.4.3 — ROI by Source: the headline box is hidden until it has text (an empty green bar showed while the document loaded). · v6.4.2 — ROI by Source: the window aggregate now counts only months that carried both spend and deals toward cost per deal and "back per $1" (the precompute's own rule). Months with deals but no recorded spend, a source's organic/legacy months, were inflating the ratio: Clear Start Tax Meta read $471 per deal and $3.60 back on 43 deals when its only paid month is August ($2,027 per deal, $1.39 back); Taboola's spend-less April did the same in a smaller way. Seen on the first capture of v6.4.1. · v6.4.1 — ROI by Source polish, from the first capture of v6.4.0: the window filter now reads "Deals sold in · This year / Last 6 months / Last 3 months · or from … to …" (was "Cohorts · YTD / Last 6 / Last 3 · Range"), and the table's Trend column is compact ("▲ Improving $1.33 → $1.55") with the month spans in the tooltip so the last column no longer scrolls off screen. · v6.4.0 — ROI by Source, EXECUTIVE LAYOUT (CMO: "make it simpler so my executives understand it right away"). The page now leads with one question — for every $1 spent on ads, how much cash comes back over the customer's life? — answered in one headline sentence computed from the data, then big-number cards ("$1 → $1.37") for the company and the biggest sources with a plain verdict (Strong $2+, Good $1.50–2, Thin $1–1.50, Losing under $1) and an arrow that says Improving / Worsening / Flat, the cost per deal, the cost per deal that would give $2 back, and this month's cost per deal as a green/orange pill against that number. The table below uses the same plain words (Ad spend · Deals · Cost per deal · Cash per deal over life · Back per $1 · Trend · Cost per deal for $2 back · This month's cost per deal). The window filter now reads "Deals sold in: This year / Last 6 months / Last 3 months / or From–To". Everything analytical (cash per deal at equal age by month, other sources by month, best/worst cohort, board ROAS vs flat spend, curve provenance, methodology notes) moved under two collapsed sections: "Details by month (for analysts)" and "How this is calculated". Nav label shortened to "ROI by Source". · v6.3.0 — Lifetime ROI page: DIRECTION + COHORT WINDOW (CMO, same afternoon: "where is it going up or down? … a time filter like the dashboard"). Direction column per source = lifetime cash ÷ spend of the most recent cohorts in the window that have at least one month of collections, against the cohorts before them (▲ improving / ▼ worsening / → within ±0.05x, with both values and the month spans printed); a cohort with no +1-month read is listed but never used for direction, because its lifetime estimate rests on ~34% of its cash. Second indicator: the running month's CPA against the last complete cohort's CPA (CPA is the leading indicator; up is coloured bad). Cohort-window filter above the table: YTD / Last 6 / Last 3 / From–To over cohort months; every column, the best/worst cohort, the trajectory tables and the per-source detail recompute from the window client-side (the nightly doc carries every cohort). First read, YTD: Google 1.29x → 1.53x ▲ (Feb–Apr → May–Jul) while Sep MTD CPA runs +35% over August. · v6.2.1 — Lifetime ROI page hotfix: the "computed at" stamp called fmtDay/fmtT, which are scoped inside the freshness-strip function, so renderRoi threw "fmtDay is not defined" after the Firestore read and the page sat on "Loading…" (caught on the live page 8 minutes after v6.2.0 shipped, via the console warning). Formats the timestamp locally. · v6.2.0 — LIFETIME ROI BY SOURCE (new left-nav page). The CMO asked whether ROI would "catch up to 2x" if spend were held flat. The board's monthly ROAS divides this month's cash by this month's spend, so growing spend depresses it (Aug 2026 Google: 1.26x on the board, 1.80x over the year's average spend); but under FLAT spend it converges to each source's LIFETIME CASH ÷ SPEND, which is what this page shows. Per source and per cohort (TIs sold that month, MySQL deals bucketed like the Sources table; spend keys folded the same way, incl. the spring's "Google - 2"/"Google Form"/"2HVT" keys): cash = every SOComm payment those cases have made to date, any team; lifetime = a 14-month estimate from the source's own two most recent mature cohorts (cash so far ÷ the share they had collected at the same age; company curve where a source lacks mature cohorts); M = lifetime cash ÷ spend; CPA for 2x = lifetime cash per deal ÷ 2. Trajectory tables show cash per deal at EQUAL AGE (sale month, +1, +3) beside CPA, so "are we heading the right way" is answerable cohort by cohort. Fed by ad-intel/scripts/adperf/lifetime-roi-precompute.mjs → lifetime_roi/current, nightly. First read (Jan–Aug 2026 cohorts): Google 1.37x at CPA $1,876 (2x needs ≤ $1,284), HVT 1.62x, Meta 1.65x, TikTok 1.59x, Taboola 2.32x, company 1.51x. Cash is not margin; Unallocated spend keys ($287k, Jan–Apr) are listed but assigned to no source. · v6.1.1 — CASH MOVES ON WEEKENDS. The revenue card withheld its month-over-month percentage whenever the benchmark window had no selling days, the same rule the deals and calls cards use. The CMO read the dash as "still blank, still not comparing to anything" and he was right: Aug 1-2 2026 was Sat/Sun with 0 calls and 1 deal, but it booked $40,808.33 in-house and $58,855.28 across all teams (his Logics Set. Officer Commission report, Team = All, for the same two days). A weekend is a real base for money. Revenue now always compares (Sep 1-2 $190,051 vs Aug 1-2 $40,808 = ▲366% in-house), and the context line prints BOTH bases so the card reconciles against Logics either way: in-house (what the hero shows) and all teams incl. ADServe ($58,855 = $40,808 + $18,047). Deals and calls keep the withheld % (a % against a weekend's 0-1 deals is noise) with the wording "benchmark days were Sat/Sun". · v6.1.0 — FULL-BOARD ACCURACY AUDIT (CMO: "each aspect, each feature, fan out"). Six read-only departments recomputed every figure from its source with commands and raw output; the board reproduced its own formulas to the dollar everywhere, and five things were genuinely wrong. FIXED IN THIS VERSION: (1) Year-over-year and older-month DEALS were deflated by the ADServe rule: "exclude any case that ever received ADServe cash" retro-erased year-old company TIs ("vs last yr 1-2" read 37, truth 41; every 2025 month's deals and CPA quietly low). A sale is now ADServe's only when ADServe cash lands around the sale itself (7 days before to 45 after). (2) Spend, calls and every precompute were ONE-SHOT reads at login while revenue and deals streamed live, so an open tab showed the 2:16 PM spend and 3:19 PM calls at 4:27 PM. The one-shot sets now re-read every 15 minutes while the tab is visible and when a hidden tab returns. (3) Labor Day (Sep 7) was a full selling day in the forecast (+$106,907 revenue, +49 deals), the biz-day pace, "1 of 22 biz days" and Budget "days left"; a US-holiday table now excludes observed federal holidays and projects a weekday holiday at the Saturday rate (Memorial Day 2026 collected $30k against a $107k Monday average). (4) The Spend chip stamped the monthly rewrite time even when a platform's pull had failed (Taboola timed out 3-5 runs a day); it now names the laggard platform and its real time, and the Deals chip prints when the last investigation landed. (5) Per-Deal "② Revenue Collected" header said "cleared"; the code sums cohort cash (reso_conversion.ltv), the header now says so. FIXED IN THE DATA THE SAME AFTERNOON: August platform spend was frozen at the last hourly run of Aug 31 ($2,247,259.20; platforms $2,248,095.65) because autofill refuses closed months; re-finalized, and the script now re-pulls the previous month for the first 7 days of a new month. August REVENUE flipped by $1,410.00 every hour: the API reconcile deleted three payments Logics re-booked and the hourly CSV step re-ingested a stale Aug-31 export from Downloads and re-created them; the export is archived, the ingest now refuses an unchanged file, and August holds at $2,828,547.51 = SOComm. May/Jun/Jul re-pulled for late refunds ($0.00 drift). Month-by-Month qualified calls May 2025-Jan 2026 and Mar 2026 were frozen docs older than the 90-day sync window and read HIGH by 1-92; re-synced from MySQL (Jan 2026 4,177 → 4,093). Company Accolades had captured the dirty August and compared April 2025 against the tracker's count of the same month; rebuilt ($2,828,548 beat June $2,726,833; 1,221 beat 1,020). Case 889239's TI mirrored to Cameron Rutherford in investigations_sold. VERIFIED AND LEFT ALONE: September revenue penny-exact to SOComm at every stamp; MySQL deals = Firestore investigations_sold case-for-case (73 Sep 1-2, 961 Aug); qualified-call definition reproduces every month Apr-Aug 2026 exactly (Aug 3,539; naive 4,241 = + two transfer desks); forecast, pace, budget arithmetic exact; Live Traffic live. · v6.0.2 — "NO SELLING DAYS IN THAT WINDOW YET" WAS FALSE, AND THE CEO CAUGHT IT. The hero card withheld the month-over-month percentage when the benchmark window had zero business days, which is correct: Sep 1-2 (Tue/Wed, 323 payments) against Aug 1-2 (Sat/Sun) produced arithmetically valid, meaningless percentages. But the sentence printed in its place said there were "no selling days in that window yet", which reads as "the benchmark is empty". It was not empty. Aug 1-2 2026 booked $40,808.33 across 112 payments. Payments post on weekends; what those days had none of was BUSINESS days, a fact about the calendar and not about the money. Same failure class as the unlabelled windows fixed in v6.0.0 — the number was right and the words beside it were wrong. The card now prints both real figures and the actual reason the percentage is withheld: "$185,416 vs $40,808 · benchmark window is weekend-only (0 business days), so a % would mislead". The reader can do the division and see for themselves. Verified against Firestore `revenue` under the live gate (canonical id + _from_report, ADServe excluded): Aug 1 Sat 89 pays $33,018.58, Aug 2 Sun 23 pays $7,789.75, Sep 1 Tue 130 pays $90,751.91, Sep 2 Wed 193 pays $94,663.69. · v6.0.1 — PACE TO BEAT LAST MONTH PROJECTED $7.77 MILLION. Swept the other pages for the window fault fixed in v6.0.0 and found a worse one here. On 2026-09-02 the card read AHEAD OF PACE +174.9% and projected September at $7,770,417 against August actual $2,827,138 — because it scaled ONE Tuesday (Sep 1, $90,751.91) by ONE Saturday (Aug 1, $33,018.58) and then multiplied that ratio by the whole of August. The thinnest possible evidence producing the most confident-looking number on the board. A ratio across one or two days is not a pace, and if the two windows fall on different parts of the week they are not comparable at all. The verdict, the percentage and the end-of-month projection are now withheld until there are at least 3 complete days AND at least one selling day on both sides; the card reads TOO EARLY TO CALL and names the weekday mismatch. The revenue figures themselves are untouched and still shown — the money is real, only the extrapolation was not. Mid-month behaviour is unchanged. v6.0.0 — THE COMPARISON NOW SPANS THE SAME DAYS AS THE HEADLINE. It cut on the last COMPLETE day, so on 2026-09-02 the headline read "Sep 1-2, 62 deals" while the comparison read "vs Aug 2026 1-1, 47 vs 1". The two numbers on screen were not the two numbers being divided. That rule existed for a good reason (a half-finished today should not be scored against a full prior day) but it reintroduced the exact fault v5.90.0 was written to remove, just in a different corner of the same card. Per the CMO: it should be the same amount of days last month. The comparison now cuts on TODAY, the printed figure equals the headline, the label names the days, and the part-day is DISCLOSED ("today still running") rather than silently corrected away. The weekday hazard that rule also masked is handled properly by the zero-selling-day suppression added in v5.99.5. v5.99.5 — A PERCENTAGE AGAINST A WINDOW WITH NO SELLING DAYS IS NOT A COMPARISON. Measured 2026-09-02: the card compared Sep 1-1 (a Tuesday, 47 deals) against Aug 1-1 (a Saturday, 1 deal) and printed DEALS up 4600%, REVENUE up 175%. Both arithmetically correct, both meaningless — the benchmark window contains zero working days. Early in a month the day-of-month match can land the two windows on different weekdays, and Aug 1 2026 was a Saturday. The row now reads a dash plus "no selling days in that window yet" instead of a number nobody should act on. Also fixed the guard that would have hidden this: "sells" was built with "momB.curSell && momB.priorSell", so priorSell === 0 — the exact case that matters — was discarded as falsy. It now tests for finite numbers. v5.99.4 — HOTFIX to v5.99.3: the Resolution Sold fallback never fired. loadResoConversion returns ONLY snap.data().months, so resoConv IS the months map and resoConv.soldByMonth was always undefined. v5.99.3 deployed clean, passed its parse test, and the cells stayed blank on the live board. soldByMonth now loads into its own variable instead of being read off a map whose every other key is a month. Caught by re-reading the rendered cells in the browser rather than treating a successful deploy as proof the fix worked — the same lesson as the v5.90.1 style bug and the Accolades permission denial. v5.99.3 — RESOLUTION SOLD was blank for four months. That column reads reso_sold_log/current, fed by a manual "Reso Log" CSV drop, and that feed FROZE on 2026-05-29 — it holds 2023-07 through 2026-05 and nothing since. June, July, August and September rendered "—" on a board people make decisions from, while resolutions_sold had been recording events the whole time (531 in August). The column now falls back to a live event count (reso_conversion.soldByMonth, ADServe excluded) for months the log does not cover, marked "live feed" in the cell so the basis is visible. Deliberately FILL-FORWARD ONLY: the two sources disagree where they overlap (April log 417 vs live 453, May 484 vs 502), so back-filling would silently restate months already reported to the board. The frozen CSV feed itself still needs fixing or retiring. v5.99.2 — THE REVENUE FRESHNESS CHIP HAD BEEN CRYING WOLF FOR 28 DAYS. It picked the newest _report_filename by raw STRING comparison, but two naming formats coexist: "SOCommOnDemand_20260901092532_api" (the headless hourly API pull) and the older "SOCommOnDemand_ondemand_20260803215539" (manual CSV drop). Lexicographically "o" (0x6F) beats "2" (0x32), so the Aug-3 ondemand file outranked every later API pull permanently. The chip read "Revenue feed is 683h old — no fresh SOComm export since Aug 3" and sat red all month while soc-api-ingest was running fine and had written changed docs that same morning at 9:25. Now compares the extracted 14-digit timestamp instead of the filename. A warning nobody can trust is worse than no warning: this one trained everyone to ignore a red chip. v5.99.1 — A STALE SPEND FIGURE NOW ANNOUNCES ITSELF. The Spend freshness chip derived its age from which DAILY spend document existed, which says nothing about when the MONTHLY total was last pulled from the platforms — so a figure hours out of date still rendered "thru Aug 31" and was indistinguishable from a fresh one. Measured 2026-09-01: the board showed $2,247,259.20 for August while Google/Meta/TikTok/Taboola returned $2,248,089.65, and the CMO found the $830.45 gap by pulling the platform APIs himself. autofill-monthly-spend now stamps _synced_at and the chip reads "synced 9:14 AM", turning red past 2h during business hours with a tooltip saying how old it is and what to re-run. _synced_at is a Firestore TIMESTAMP, deliberately not an ISO string: spendForMonthKey sums every value in the document with parseFloat, so "2026-09-01T…" would have added $2,026 to the month. v5.99.0 — Source labelling. (1) The row shown as "Yahoo" is TABOOLA. Its spend is pulled from the Taboola API and reconciles to Taboola's own $39,152.25 for August 2026; there is no Yahoo spend at all. Anyone cutting "Yahoo" would have cut Taboola, and anyone told to scale Yahoo would have had nowhere to spend it. The bucket KEY stays "IRS Fresh Start Yahoo" so ad_spend history is not orphaned — only the display changes, with a tooltip naming the Yahoo-network origin. (2) DEFENSIVE ONLY: the Demand Gen branch now matches /DG|demands*gen/i instead of /DG/. NOTE, because an earlier note here claimed otherwise: this fixes nothing today. Every DG-labelled deal on file reads "IRS Fresh Start Google Form - DG" — uppercase — which the old pattern already matched. Checked against live data: zero August deals mention dg or demand gen in any case, and the new pattern moves no deal and produces no false positive. The DG row reading $9,094.27 against 0 deals in August is therefore a REAL RESULT, not a display fault: Demand Gen has spent about $22,640 since June for 4 deals total. The looser pattern only guards a future lowercase or spelled-out label. v5.98.2 — Accolades correctness, found by testing the page in a real browser rather than a stub. (1) The Firestore read was DENIED in production: company_records is a new collection and no security rule covered it, so the page rendered "could not load (Missing or insufficient permissions.)". Rule added and published by hand via the Rules API — nothing in CI deploys rules, so this class of bug ships silently. (2) A TIE rendered as a win: "7 by Alan Hurtado beat 7 by Stephanie Hughes". Now reads matched / beat / behind by sign. (3) Dropped the tracker seed "Evaeh Lorenz 66" — a misspelling of Nevaeh Lorenz, whose same 66 is already in live data, so the card read as one person beating herself. v5.98.1 — Accolades: added a PRODUCTIVITY record (deals per WORKING agent per day) and taught the renderer to keep decimals on it — Math.round turned 1.81 into 2. The divisor is agents who handled calls that day, NOT agents who sold: the 2025-10-15 announcement divided 60 deals by 26 SELLERS and compared that to 2025-04-14 100 deals over 55 WORKING agents, producing a 27% productivity gain that was not real. On one basis Apr-14 is 1.72 and Oct-15 is 1.08, so October was never a record. Dividing by sellers is self-limiting, since an agent who sells nothing leaves the denominator. A 25-agent floor keeps skeleton days out. v5.98.0 — New COMPANY ACCOLADES page, under Live Traffic in the left nav. Records the company actually celebrates — highest revenue month, most investigations in a day / month / by an agent, most paid-in-full in a day, largest single transaction — each shown NEXT TO THE MARK IT BEAT, because a record with nothing to compare it to cannot be checked (CMO: "revenue record was $3, and then we made $5, that's a record"). Categories are taken from the CMO's own manually-kept Company Accolades sheet rather than invented, and that sheet's pre-2024 marks are seeded in so history predating our tables is not lost; a live figure supersedes a seed the moment it exceeds it. Also lists every officer who beat their own personal best this month. Source: company_records/current ← ad-intel company-records-precompute.mjs. v5.97.0 — Two fixes. (1) The "Compare to" dropdown could DISPLAY one month while the cards computed another. benchMonthOffset defaults to 1 (last month) and is persisted nowhere, but the select had no autocomplete=off, so Chrome restored the previously chosen option on reload without firing a change event. Measured 2026-08-31: the control read "June 2026" while every hero row computed July ($2,577,453 vs $2,103,521, labelled "vs Jul 2026 1-30"). Same failure class as the unlabelled windows fixed in v5.90.0 and v5.95.0 — a label disagreeing with its number. The select now opts out of restoration, and buildBenchOptions reconciles the variable to whatever the control actually shows. (2) The v5.96.0 per-selling-day figures rendered with mismatched precision on Deals — "45.8 vs 44.273" — because fmt() does not round. Per-day values now round to the dollar for money and one decimal for counts. v5.96.0 — The selling-day note now states the RATE, not just the divisor. It has been printing "20 vs 22 selling days" under a percentage computed on raw totals, leaving the reader to divide. Against Jun 2026 that concealed a sign flip: Aug 1-30 showed ▼6% ($2,577,453 vs $2,728,618) while per selling day it was ▲4% ($128,873 vs $124,028), because August had 20 selling days to June's 22 — the board said "behind" on the record month while production per working day was ahead. Identical to the DEALS card bug fixed in v5.91.0, which added the disclosure but never used it. Revenue and Deals now append "▲ 4% per selling day" with both sides shown. Qualified Calls is deliberately excluded: its MoM window is re-capped to the calls watermark, so those day counts do not describe it. v5.95.0 — The three headline numbers now NAME their own window. The headline runs through today while the comparison rows stop at the last complete day, so on 2026-08-31 a 1-31 figure sat directly above rows labelled 1-30 and only the small rows said which window they meant. The CMO read $2,640,954.61 off the board against his own $2,577,453 book, concluded the board was wrong, and reported the month incorrectly — both numbers were right, they were different windows. Each hero card now prints its window under the value, e.g. "Aug 1-31 · through today", cut on the real data boundary so mid-month reads "Aug 1-26" and a finished month reads "Jun 1-30". Numbers, queries and gates unchanged. v5.94.0 — Trends now includes Spend grouped by platform, with This Month MTD, Last Month, Last 2 Months, 6 Months, 1 Year, and All Time windows. Completed-month windows exclude the current partial month. Total spend is shown back to the historical tracker floor; platform rows begin in Jan 2026, with older platform cells left blank because no defensible split exists.

v5.93.0 — The hero comparison rows now print BOTH sides of the division, not just the benchmark. The headline is month-to-date through TODAY while the comparison runs through the last COMPLETE day, so on 2026-08-26 the card showed $2,059,988 beside $2,055,836 and said "down 5%" — the compared figure (Aug 1-25 = $1,955,882) was nowhere on screen and the percentage looked wrong. Rows now read "$1,955,882 vs $2,055,836" so the arithmetic is checkable at a glance. v5.92.0 — Audit fixes, wave 1. (1) BUDGET PACING treated today as spent AND as remaining: the run-rate divided 18 days of spend by 17 days, while "days left" still counted today as available even though its spend was already subtracted. Both errors pushed toward the red ABOVE warning. Measured 2026-08-26: card claimed 11,999/day pace vs 1,504/day left (1.82x over); honest figures are 05,777 vs 2,005 (1.29x). Today is now ELAPSED on both sides. (2) REVENUE and DEALS headlines rendered /usr/bin/bash.00 and 0 when their feed failed to load, making a total outage look like the worst month in company history; Spend already guarded this. Both now show a dash when nothing loaded, while a genuinely empty window still reads zero. (3) PACE TO BEAT LAST MONTH compared this month INCLUDING today against last month COMPLETE and printed "same days". July 26 was a Sunday, so the headline swung ~5 points across one day with nothing changing underneath and the verdict could walk BEHIND -> ON -> AHEAD. Both sides now end on the last complete day, matching the hero card, and every label names the real window instead of printing a day the prior month may not have. v5.91.0 — Diagnostic sweep fixes. (1) The selling-day note now appears on ALL THREE hero cards, not just Revenue. Measured 2026-08-26: the DEALS card read "▼6% vs Jun 1-25" (789 vs 839) while deals per selling day were 46.4 vs 44.2, UP 5.1% — August had 17 selling days against June's 19. The sign flipped, and the disclosure was on the one card least affected, since deals land Mon-Fri. (2) The YoY row now names its window ("vs last yr 1-25") instead of a bare "vs last year" beside a row that names its bounds. (3) .da-filter-btn had NO css rule at all, so the Deals-per-Agent Daily/Weekly/Monthly/Range buttons rendered as raw OS buttons with nothing marking the active one. (4) .rt-stale lost a specificity contest to .section-head .meta, so the "GA4 feed stopped" warning painted the same muted grey as the healthy state. (3) and (4) are the same ancestor-chain bug class as the v5.90.0 .ctx miss. v5.90.1 — HOTFIX to v5.90.0: the "17 vs 19 selling days" note rendered as a HEADING. `.ctx` was only ever styled under `.hero-yoy`, but renderCompare writes into `.hero-compare`, so the note inherited 14px full-white body text and read louder than the numbers it annotates. Now styled under `.hero-cmp-row` as an 11.5px muted footnote. The pre-deploy layout check missed it because the probe markup was wrapped in `.hero-yoy` rather than the container the card actually uses — a test that did not reproduce the real DOM. Numbers unaffected. v5.90.0 — Hero comparisons now run BOTH sides through the last COMPLETE day, matched on DAY OF MONTH. CMO 2026-08-26: the card read "▲3% vs Jun 2026" while his own book had Aug 1-25 $1,955,882 BEHIND Jun 1-25 $2,055,836 — both figures were right, they were just different windows, which is the worst kind of wrong. Two causes. (1) The numerator was the through-TODAY headline, so a half-booked today was scored against a complete prior-month day. (2) The benchmark matched on BUSINESS DAYS ELAPSED, which is defensible but is not the comparison the business makes; it put June's cut at the 24th while the label just said "vs Jun 2026". Now: numerator = same window as the benchmark (Aug 1-25), benchmark = prior month 1-25, and the label SAYS the window ("vs Jun 2026 1-25") so it can be reconciled against anyone's own numbers. August correctly reads ▼5%. The reason business-day matching existed is kept, not discarded — when the two windows hold a different number of selling days the card now says so ("17 vs 19 selling days") instead of silently correcting for it. The REVENUE headline itself is unchanged: it still shows every dollar booked so far this month. v5.89.2 — Column reorder is now drag-and-drop: grab the ⠿ handle and drop a column anywhere (the ▲▼ arrows still work for fine moves). Much faster than clicking arrows to move a column across the table. v5.89.1 — Columns dropdown now also REORDERS: ▲▼ arrows next to each column set the order (first→last), persisted; Reset restores defaults. The 6 same-month/recurring columns move as one block; Revenue Month stays pinned first. v5.89.0 — Month-by-Month table: new "⚙ Columns" dropdown to show/hide any column (persisted across reloads); replaces the single PS/PN toggle, which is migrated in. Column reorder is the next step. v5.88.6 — Reverted the v5.88.5 global zoom (0.8) back to 100% — it made the dashboard hard to read. v5.88.5 — Collapsed the on-page changelog (it was rendering the full version history as a wall of text at the bottom of the page) down to just the version number; full history kept in a hidden element so nothing is lost. Also added a global zoom (0.8) so more of the dashboard fits on one screen. v5.88.4 — Sources table Spend column is now penny-exact ($XXX,XXX.XX) — both the per-source rows and the Total — so it reconciles to each ad platform's UI (Google Ads, Meta, TikTok, Taboola) to the cent. v5.88.3 — Sources table column reorder: Spend now sits right after the Source name (before Deals), so the row reads Source → Spend → Deals → … → CPA → ROAS. Applies to both the By-Campaign and Sources views and the Total row. v5.88.2 — REVENUE headline is now penny-exact ($X,XXX,XXX.XX): the value, the ADServe/total sub-line, and the weekday-rate breakdown all show cents so it reconciles to the SOComm total. (EOM forecast stays whole — it's a projection, not a reconciled figure.) v5.88.1 — Trends table: the Source column is now frozen (sticky-left) so it stays visible when scrolling the day/month columns horizontally. v5.88.0 — Trends now has a granularity selector (Daily / Monthly / 6 Months / 1 Year) — trend ANY metric (CPA, ROAS, Deals, Avg Debt, PIF%, Revenue) per source at any resolution, same green/red heatmap. Daily uses its own window chips (This Month / 30d / 60d / 90d) and scrolls horizontally. Daily CPA & ROAS per source are powered by a NEW daily per-source spend feed (Google campaign-split-by-day → ad_spend_daily_source, refreshed hourly + nightly, reconciled to the monthly m_ doc to the dollar). Daily PIF% = cumulative paid-in-full to date (same-day cash is ~always 0, so a same-day rate would read 0%). v5.87.0 — Forecast + headline now speak the same business-day language. The Revenue Forecast card splits "days remaining" into biz vs weekend days and adds an "at this month's biz-day pace" cross-check (weekday-rate × remaining weekdays + weekend-rate × weekend days) so it reconciles with the headline instead of reading low next to it. The headline's $/biz-day is now a TRUE weekday rate — weekday cash only (weekends stay in the TOTAL but not the per-weekday velocity); it was folding weekend cash in, which inflated the rate. All three reads of the month (headline pace, biz-day pace, DoW forecast) now land within ~3% of each other, all a few points under May's record. v5.86.0 — Revenue freshness chip now flags RED if the latest SOComm export is more than 14h old during business hours (Mon–Fri, 8 AM–7 PM) — it was a flat 30h, which let a 15h-stale feed sit un-flagged on a Friday morning and read as "stuck". Off-hours/weekends keep the looser 30h guard so it doesn't nag overnight. Hover the Revenue chip when red for the data age + a "drop a fresh export" reminder. v5.85.0 — Toggle on the Month-by-Month table to collapse the Paid Something + Paid Nothing columns (keeps Paid In Full). Checkbox in the legend bar; preference remembered across reloads (localStorage). v5.84.0 — Avg Debt (Resolved) is now the tax debt AT the resolution sale (POINT-IN-TIME), not the current value. Per CMO: it's what the debt was when we sold the resolution. Computed from the IRS Logics CaseActivity "Tax Liability changed to X" history, anchored to the "Zapier Resolution Sold" date — reverting any later correction (e.g. case 102019: sold Nov-2024 at $50k, corrected to $42,764 in Oct-2025 → the column shows $50k). Source: cohort_resolved_debt/current ← cohort-resolved-debt-precompute.mjs. v5.83.0 — New column: Avg Tax Debt (Resolved) — the average IRS debt of the deals that converted to a resolution, next to Resolution Rate. Confirms the quality signal: resolvers carry meaningfully more debt than the cohort overall (e.g. Oct 2024 $34.7k resolved vs $27.2k all; sub-line shows the % delta). Same source as Avg Tax Debt: MySQL deals.Amount_Owed (2024-10+) + IRS Logics CaseInfo.TaxLiability (2023-2024, re-pulled). Small-sample guarded (≥10 resolvers). v5.82.0 — The LAST two columns for 2023–2024: Paid In Full and TI Sold→Reso Opp %. Paid In Full (+ Paid Something/Nothing, now all coherent) from IRS Logics SUCCESS payments per TI Log case vs the Investigation invoice fee — same method as 2025+ (PIF ~16–25%, PS ~59–71%). Reso Opp % (same-month) from MySQL caseStatusTimeline "Ready To Present" events joined to the TI Log cases — same source the live metric uses (~4–13% same-month). The 2023–24 cohort table now matches the 2026 rows column-for-column (only Jun 2023 stays sparse — PARTIAL). Sources: cohort_pif/current ← cohort-pif-precompute.mjs · resoOppSame in cohort_ltv. v5.81.0 — Avg Tax Debt + Contracted / % Collected / Projected / Projected ROAS for 2023–2024, pulled from IRS Logics per TI Log case (23,100 API calls): CaseInfo.TaxLiability → Avg Tax Debt, Billing/CaseInvoice → Contracted (company, excl AdServe), joined to cleared revenue. Avg debt runs ~$23k–$35k; ~40–53% collected (matching the ~50% mature rate). Avg Tax Debt falls back to this pre-Oct-2024 (MySQL debt_summary wins where present); Contracted/Projected fall back pre-2025. Jun 2023 skipped (PARTIAL). Source: cohort_irslogics/current ← cohort-irslogics-precompute.mjs (nightly). v5.80.1 — HOTFIX: v5.80.0's Scale Score still read pm.pif directly when pmTotal>0, but pre-2025 now sets pmTotal from cohort_ltv with pm undefined → render threw "cannot read pif", blanking the board. Guarded the pm reference. v5.80.0 — More 2023–2024 cohort columns from the TI Log × all-time revenue: Paid Something, Paid Nothing, Resolution Rate, and Avg Reso Fee now populate for Jul 2023–Dec 2024 (mature cohorts run ~35–44% resolution rate, ~$3.0k–5.3k avg reso fee). Paid Something/Nothing = cohort cases that paid any / no all-time company revenue; Resolution Rate + Avg Reso Fee = cases with a resolution-type payment and their reso revenue. Paid In Full stays blank pre-2025 (needs per-case fee data); Avg Tax Debt + Contracted/Projected coming next from IRS Logics. v5.79.0 — Real LTV + Cohort ROAS for 2023–2024. Joined the CMO's TI Log (11,550 investigations sold Jun 2023–Dec 2024, by Case ID) to all-time company revenue → per-cohort lifetime value, filling the previously-blank LTV and Cohort ROAS columns. The mature 2023–24 cohorts run ~5–6x Cohort ROAS (LTV ÷ ad spend). June 2023 is skipped — the log starts 6/20 so it only covers 22% of the month (PARTIAL), which would understate ROAS. ~37–42% of cases have no revenue on file (didn't convert), so LTV is a realized floor. Sources: ti_log_sold/current ← ti-log-ingest.mjs · cohort_ltv/current ← cohort-ltv-precompute.mjs (TI Log × revenue). v5.78.2 — Filled the Jan–Apr 2025 gap in Qualified Calls / Cost-per-Call / Closing %: live call-counts only begin May 2025, and the tracker fallback was bounded to pre-2025, so those four months showed blanks. Loosened the rule — the Trend Tracker now fills ANY funnel cell the live feed is missing (deals still stay live for 2025+). v5.78.1 — Reverted the v5.77.2 column reorder: the Month-by-Month columns are back in their ORIGINAL order (Revenue Month · Ad Spend · Qualified Calls · Cost/Call · Closing % · Deals (TI) · Reso Opp % · Resolution Sold · CPA · Avg Debt · PIF/PS/PN · Revenue Per TI · … · Total Revenue · blue/green split · … · Scale Score). The reorder only existed to hide the pre-2025 blanks; now that the Trend Tracker backfill (v5.78.0) fills those leading columns back to 2023, the familiar order is restored AND fully populated. v5.78.0 — Pre-2025 history filled from the CMO's manual "Trend Tracker". The Month-by-Month funnel columns (Deals · Ad Spend · Qualified Calls · Cost/Call · Closing % · CPA · Resolutions) were blank before 2025 because ad spend (Jan 2025+), call counts (mid-2025+) and the deals/debt table (Oct 2024+) don't reach back. The tracker does — funnel to 2023, spend to 2022 — and (verified) its Investigations count is MORE complete than the live feed, which undercounts ~3% and is empty Jan–May 2023. Per CMO decision the tracker is the deal + funnel source for pre-2025; live stays authoritative 2025+. Cost/Call, Closing %, CPA are DERIVED from the tracker's deals/spend/calls so they reproduce its numbers exactly. Revenue still comes from the live system. Source: funnel_history/current ← ad-intel funnel-history-ingest.mjs (re-run on a fresh tracker export). v5.77.2 — Month-by-Month columns reordered so the data that goes back to 2023 LEADS: Deals (TI), Total Revenue, the same-month vs recurring split, Revenue Per TI, Resolution Sold, LTV — then the spend-derived / recent-only columns (Ad Spend, CPA, Cost/Call, Closing %, Avg Tax Debt, PIF) follow on the right. Old rows no longer open onto a wall of blanks; nothing was removed, just resequenced. The pre-2025 blanks are real data gaps, not a display bug: ad spend only exists from Jan 2025 and the deals/debt table starts Oct 2024 (verified — no debt source reaches 2023; Avg Tax Debt precompute pinned to its true Oct-2024 floor so it never ages off). v5.77.1 — Wider tables: inside the tabbed layout the content container kept the global 1200px max-width + auto-centering, so on wide monitors it floated in the middle, leaving a big gap between the left nav and the table. Now the container fills the space next to the sidebar (max-width removed, flush-left), so the Month-by-Month and Per-Deal tables get the full width. v5.77.0 — Left-nav tabs: the page is split into Dashboard (headline → forecast → ad spend → sources), Staffing & Capacity, Per-Deal Economics, and Month-by-Month Revenue. Each is its own page; hard refresh always lands on Dashboard. All sections still render on load (just hidden until selected), so nothing slows down. v5.76.1 — fix: cohort window boundary was off by one (May 2025 fell in a gap between the precompute and the live window). Now contiguous — every month from Jan 2023 to now. v5.76.0 — Month-by-Month cohort table now shows back to January 2023 BY DEFAULT, fast: deals + revenue + same/recurring split for older months come from the nightly `cohort_history` precompute (verified to match the live computation to the penny), so no slow client load and no button. CPA / Avg Debt / LTV / Cohort ROAS stay blank before 2025 (no ad-spend / precompute data that far back). Per-Deal Economics table stays at 13 months. (Replaces the v5.75 on-demand "Extend to 2023" button.) on demand, loads deals + revenue back to Jan 2023 (rolling 13-month window otherwise, kept fast by default). CPA / Cohort ROAS stay blank before 2025 — ad-spend data only exists from Jan 2025; deal+LTV columns populate from 2023 (investigations_sold + revenue). v5.74.0 — Staffing panel now leads with the ANSWER: a hero banner stating the action + how many + how soon (e.g. "HIRE ~8 · start now · ~4/month after"), computed in the precompute (net seats to clear the peak-drop, grossed up for ramp wash-out + throttled demand). The capacity wall, deals/agent dial, and per-agent table collapse under a "show the evidence" toggle so the read is clean. v5.73.0 — Staffing & Capacity panel: Hire/Hold/Cut decision lights from MySQL (Processed_call + deals → staffing_capacity/current, nightly). Shows TIs/agent/day vs the 3 target, the capacity wall (drop rate rises with call load while agents-live max out + peak concurrency + live-vs-callback), the deals/agent stop-hiring dial, the 3-TI/day lead gap, and per-agent production with non-producer flags. Fully guarded render (can't break the board). v5.72.0 — Demand Gen on the board: "IRS Fresh Start Google - DG" gets its own pinned Sources row + spend bucket ("FSR - Demand Gen - TI (rebuilt)" 23881397484, landing /google-gettaxreliefnow/, phone 888-800-9013, queue 1_FSI_Google_DG — forms AND calls attribute distinctly; "Google Form - DG" no longer folds into plain Google). v5.71.1 — HOTFIX: v5.71.0's dead-collection removal missed one reference to the removed `call` variable in loadAll's partial-load check — ReferenceError after data load, dashboard never rendered (caught by CMO 2026-06-12 08:20, prod down ~14h). v5.71.0 — Label-truth batch: cohort Ad Spend tooltip no longer claims "Manual entry" (auto, hourly) · static header says "refreshed hourly" not "nightly" · hardcoded "~52%" collection rate and "$259→$641" narrative removed from tooltips (live rate is computed nightly) · Daily CPA date picker no longer hides pre-Mar-9 data (fixed 2026-03-03 start) · Calls freshness chip no longer cries wolf every afternoon (staleness measured from end of synced day) · dead call_counts_daily collection no longer downloaded on every page load. (v5.70.0 one projection per metric.)