To-Do

This removes 515 misclassified EXACT negatives (Valley 496 incl. insurance/car insurance; Brentwood 19 incl. window blind) that the old brand-token bug applied — Valley has been blocking its own core demand since July. Everything else is done and deployed (PRs #2048/#2050/#2053, prod slot 71ade114): the classifier is fixed, tonight's crons run clean, and outcome verification is live. The route is operator-only by your own money-auth design, so this click is the one thing an agent structurally cannot do. After you click, I watch Valley CPL for a week.

**P2 — ADS-SIDE OPERATOR LIST (read-only on my side; every line below is a live-account write,

7 clients' Google Ads call assets went UNREAD because

so their stronger authored subheadlines can be restored: ~~Angel Touch (400059) price_in_writing~~ (resolved by reword 2026-08-25 — see below) and Fat Cat (174637) same_week_availability ("quote comes back instantly" — true?). Interim honest subs are being shipped; registering the evidence upgrades them.

no review sync can run at all until then (both have zero connected review source; heroes correctly show no proof).

verify the location is the right/live one on Google. Their site testimonials are real but unmarked (no schema.org Review JSON-LD), so the extractor ignores them by design.

ASAR (2402013): 41 GBP reviews (carousel works) but below the 50-count badge floor and no Ratesight-verified rating — accumulate reviews or verify a rating; policy, not a bug.

Ten entries, all

(970) 238-9468 is now a

**P3 — CLOSED 2026-08-25T03:12-03:13Z. All five profiles now hold the client's real published

~~

H&U (400036)

The open evidence question is no longer blocking anything: rather than wait on the price_in_writing answer, every unevidenced price-certainty / itemized-estimate string was replaced with the planning-and-scope certainty the page can actually evidence (400059 holds free_no_obligation_quote only). Found by running each SERVED page's strings — visible text, JSON-LD and rendered attributes — through the NEW detectUnbackedClaims price families from #1915, run out of a worktree at origin/main because prod predates that commit. 9 strings on 2 of the 4 pages: kitchen (8) — form reassure "…then leave an itemized estimate", the problem paragraph "…prices the job line by line so the number you approve is the job you get", two service descriptions ("with the price and schedule set before demolition", "you know the price and the schedule before anything comes out"), the "Free In-Home Estimate" card ("an honest itemized estimate"), an FAQ answer ("leave you an itemized estimate"), and the FAQ pair "How do I know the price will not move once demolition starts?" → replaced with "What happens during the in-home estimate?" plus an answer the evidence can carry; whole-home (1) — "planned and priced before work starts" → "with the layout decided before work starts". Bathroom and remodeling-contractor needed no change (their scope-first language — "the scope gets written, then you get a price" — is process, not a price promise, and scans clean). Shipped by the minimal rebased-version method per page (only the target strings + version markers changed; a pre/post invariant assert refused any drift in tel 7023471178 ×3 / display ×7, GTM, AW-18304150915, forms, inputs, lead + beacon endpoints, images). Stored drafts updated in the same version so a future regen cannot reintroduce the claims: kitchen v26→v27 (deployment 8520fdf9), whole-home v25→v26 (deployment 38f1f9cf), both deployed with explicit publicBase=https://dash.ratesight.com. Verified served: all 4 pages re-fetched and re-scanned through the new families = zero unbacked price claims; screenshots in /tmp/angeltouch/. The operator can still restore the stronger claims: if the client confirms they really do leave an itemized price in writing before work begins, grant price_in_writing on 400059 and the "itemized estimate" / "the number you approve is the job you get" framing becomes evidenced and can be re-authored. Residual (not touched, deliberately): the fleet compliance footer — "Workmanship and material warranties, if applicable, are governed by the written contract" — still trips workmanship_warranty on all 4 pages and on every other fleet page. It is a legal DISCLAIMER, not a claim; the fix belongs in the detector (stripPriceDisclaimers covers price_superlative/price_level only, so a hedged "if applicable" clause is read as an assertion), not in the copy.

The residual above was the LP tracking store, not the profile: resolveLpPhone prefers runtime LP-tracking trackingPhone over the profile, and it still held the unregistered (289) 307-5887, so the next full regen would have stamped it. Cleared via the store's own documented path (PUT /api/lp-tracking/400009 {"trackingPhone":""} → pages fall back to the profile phone); a fresh regen dry-run now resolves (289) 929-6232. Live page unaffected (phone bakes at build).~~ WRONG, AND REVERTED 2026-08-25T02:45Z. I ruled (289) 307-5887 stale on the strength of it being absent from a register that had in fact been WIPED — absence of a record was read as evidence of absence. Your spreadsheet confirms it is Goliath's tracking line. The store was restored (PUT /api/lp-tracking/400009 {"trackingPhone":"(289) 307-5887"}), the register now carries it as an operator entry, and the live page was moved back onto it (v21, deployment 19ccc91b). The lesson is recorded: a wiped register cannot be used as proof that a number was never sanctioned.

(a) a declared list read from a version strictly NEWER than the legacy source, and differing from it, now wins (empty/same-version/older declared lists keep legacy precedence, so Aloha is unaffected); (b) the currently served version is now the last hero rung before the gradient — carry-forward only, behind the same readability/digest/badge-claim gates. Dry-run proof on Goliath: service options are the clean four, hero from: served-version. Full vitest suite 31 failures before and after vs a clean origin/main baseline (0 new). Rollback: CONFIRM_PROD_ROLLBACK=yes bash scripts/rollback-release-slot.sh 7850c55b....

hero.subheadline is now REQUIRED at the claim gate, falling back to the deterministic seeded line (threaded pre-content-fill through a new RenderOptions.heroSubheadlineFallback, and claim-gated itself before use) else to the claim-free floor; and hero.subheadline joined the retention keys, so a candidate that loses the line the live version had is now REFUSED. Full suite: 0 new failures vs a clean origin/main baseline (31 both sides), 11 new tests pass. Rollback: CONFIRM_PROD_ROLLBACK=yes bash scripts/rollback-release-slot.sh 9b841a1c4fe674cfc8d6de3ced94bdd09b067738.

Acting on the stale held-decision text (this entry's resolution had not been re-read), the (a) pin was built and deployed: saved operator Builder draft (AI fill skipped), H1 byte-exact "Local Residential Moving in Niagara: Movers for Home and Office, Long Distance Across Ontario", all gates pass, 8/8 alignment, hourly-honest subheadline and all v20-v27 fixes carried (retention/claimDelta/protectedSlots gates verified). Net effect beyond the H1: the regen path for this client is UN-WEDGED — first deploy attempt (v28) was auto-rolled-back by the visual gate (white GOLIATH-WHT logo on white header), root-caused to the logo resolver chain: brand kit was null, website scrape returns the white variant, and the approved-assets registry had the white logo pinned since 2026-07-27. Fixed durably: brandKit.logoUrl = cropped-h7 (dark icon), approved-assets re-approved to cropped-h7 (operator, white record on audit trail), logoContrastVerifiedUrl now stamped on v29. The missing re-approval surface shipped as PR #2062 (operator-gated POST /api/landing-page/[id]/approve-asset + inline UI on the regen row) — once deployed, White Rose'''s regen (blocked on the same stale-approval wall, beach-physio plan §16) is one UI click.

The live page reached its target state through minimal edits instead of a full regen: hourly-honest copy (v20), tracker phone (v21), clean services + form (v22-24 wave), review carousel from the designated listing C (v25+), owner name removed (v27) — all invariant-verified, alignment 8/8 100% aligned throughout. No full regen is needed or planned; if one ever is, the (a) pin option stands recorded below. Original entry kept for the record: Goliath (400009) regen was held on an ads-alignment vs service-gate conflict (2026-08-25; three dry runs, nothing appended, nothing deployed, live page byte-identical v19, lease never consumed). With the subheadline fix live, the candidate now renders a subheadline and ALL gates pass — but the regenerated H1 ("Local Residential Moving in Niagara, Priced Before the Truck Rolls.") drops ads↔LP theme coverage from 8/8 to 4/8 (50%), which was the explicit stop condition. Carrying the v19 headline forward DOES restore 8/8 but is then refused by candidateGate: headline-contains-service, because the v19 line never names the resolved service Local Residential Moving in the H1 or eyebrow — and contentInstruction honoured the pin in one run and ignored it in the next, so it is not a deterministic carry-forward. Pick one: (a) pin Local Residential Moving in Niagara: Movers for Home and Office, Long Distance Across Ontario (satisfies BOTH rules) via a saved operator Builder draft or contentScope excluding hero; (b) accept 50% match and deploy the clean candidate as-is (verdict still reads aligned); (c) leave v19 serving. Detail in process/features/lean-bofu-landers/active/beach-physio-lp-alignment_PLAN_24-08-26.md §16 "Follow-up EXECUTED 2026-08-25". UPDATE 2026-08-25: option (b) is now dead on facts, not on match %. The candidate H1 "…Priced Before the Truck Rolls" is FALSE — Goliath charges by the hour — and every price-certainty line has since been removed from the live page (v20, deployment 05d8d5f7). Any regen candidate carrying that framing must be refused regardless of its alignment score. v20 keeps the v19 H1 and still reads aligned at 8/8 100%.

The candidate hero renders NO subheadline while live v19 renders one ("The price we agree on before the truck rolls..."). Not caused by #1902: the deterministic seed does produce a subheadline, the AI fill's is accepted, and lib/lp-builder/draft-claim-gate.ts then omits it with no fallback — the hero HEADLINE has { required: ROLE_FALLBACK.heroHeadline }, the SUBHEADLINE has none, and retentionGate tracks only offer + reviews.aggregate so nothing refuses the deploy. Fix first: give hero.subheadline a required fallback to the seeded line (and consider adding it to the retention keys), then re-run the dry-run, then POST with googleCustomerId: 2339130070 and re-run alignment for 2339130070 (must stay 1/1, hero tokens must not drop below 8/8). Detail in process/features/lean-bofu-landers/active/beach-physio-lp-alignment_PLAN_24-08-26.md §16 "Phase 4d".~~ (superseded by the two entries above: the subheadline gap is fixed and deployed; the regen is now held on the headline/alignment decision.)

v21 deployed 2026-08-25T00:19Z, hero renders ★ 62+ verified reviews, stats row refreshed 50+ → 62+ from the profile's verified count. Done as a minimal 2-line version (a full regen is refused by the logo approved-hash gate and would have replaced the good geo headline).

**FIXED, merged and DEPLOYED 2026-08-26 — a rollback can now restore BYTES, and a re-deploy

Not checked. If they do, a role grant is cheaper than a new app.

Every call returned queryError=UNRECOGNIZED_FIELD: Unrecognized field in the query: 'campaign.url_expansion_opt_out'. Google removed that field in v23, and there is no renamed replacement: enumerating all 2,396 ATTRIBUTE fields v23 exposes via GoogleAdsFieldService returns no campaign-level url-expansion field under any name. The setting is simply no longer readable. Replaced with final_url_expansion_asset_view, which is strictly better evidence — where expansion actually sent traffic, not a boolean about where it is permitted to. Same defect class as the v21→v23 breakages in #1677-#1679. Immediately surfaced a real problem it had been unable to report: goliath 2339130070's PMax asset group lists our generated LP (goliath-local-residential-moving.pages.dev), but expansion is sending traffic to goliathmoving.ca and www.goliathmoving.ca, which appear in no asset group. The route reported nothing at all while broken.

lib/google-ads-url-expansion.ts is a pure planner that builds a campaign *mutation* on url_expansion_opt_out. It has no callers, so nothing was failing, but wiring it up would have produced a mutation Google rejects while reading locally as applied. Marked non-executable with a stated reason, plus an import guard test so it stays unwired. Containing PMax URL expansion is now a Google Ads UI action only; we cannot do it through the API.

runtime/ad-library/captures.json has been literally {} since 2026-06-09, the capture UI is not in nav, and the Meta Ad Library API that could populate it is permission-blocked for our app (OAuthException code 10 / subcode 2332002 — we hold no owner role on Ratesight's app 1238926602897158). Yet the brief is injected into app/api/intake (Meta ad copy) and both email draft routes, all spelled brief ? base + brief : base. So every Meta ad and every email drafted since June was generated as though a competitor brief had been consulted. Decision: make the emptiness loud rather than wire it to something else. Competitor names discovered from our own search terms (Phase B) are evidence about *who is in the auction*, not about what creative anyone runs; piping them into an "ad intelligence" slot would be the same silent substitution in a new coat. Absence is now stated in the prompt and distinguishes four causes (brief / none-on-file / unavailable / no-niche). Mirrored in the assistant (PR #279), where the Google Ads and landing-page prompt builders had the identical guard, enforced inside the builders so no call site can reintroduce it.

/ad-library now has its own nav item ("Competitor Ads", Create area) instead of being carried as a non-rendering alias of /images. Rationale, in the order that decided it: (1) consumption is CODE-CONFIRMED at three dashboard call sites (app/api/intake, app/api/email/ai-draft, app/api/email/ai-draft-sequence) plus mirrored assistant prompt builders, so this is a wired feature starved of input, not an unused one; (2) retiring it properly would require edits in studiosight-assistant, which cannot be restarted without separate operator authorization, so a dashboard-only retirement would leave the asymmetric half-state the completeness bar forbids; (3) the cost of surfacing is one nav line against deleting six files and three prompt integrations; (4) docs/audits/platform-ia-audit.md F3 already recommended de-orphaning. Guarded by __tests__/nav-config.test.ts ("Competitor Ads is a REAL nav item, not an alias"). NOTE: the store is operator-curated by construction — Meta's ads_archive returns political/issue ads only — so it stays empty until someone captures. Empty is now a choice rather than a certainty.

(#1756). Two tests asserted facts about the *VPS filesystem* rather than about behaviour: resolveChromePath required a cached Chromium (GitHub runners install none), and a teardown guard asserted /home/ubuntu/studiosight/runtime *exists* (it does not on a runner). Both passed here and failed there, so the gate was permanently red and had trained everyone to ignore it. Fixed by making each environment-aware without hiding regressions: the resolver gained two hermetic tests that run everywhere (CI previously had *no* working coverage of that function), and its real-environment check now skips with a named reason behind an *independent* on-disk probe rather than behind resolveChromePath itself, which would have made the test vacuous. The teardown guard now asserts the production root is unchanged rather than present. Verified by mutation: injecting a resolver regression still fails loudly on a runner.

Worst first: seo-gsc-sync (285s + 60s = 345 vs a 295s cap), lp-served-drift-sweep and ads-lp-chain-sweep (240 + 60 = 300 vs 290), sync/gsc-metrics (285 + 10 = 295 vs 290), sync/gsc-monthly-mirror-backfill and sync/gsc-metrics-backfill (280 + 60/10, no unit installed yet), entity-alignment-sweep (240 + 45, its unit sets no --max-time, so curl cannot fire first), seo-inventory (55 + 8, safe). Not fixed in #1761 per the "smallest safe fix, never refactor unrelated code" rule. Adopting createRunBudget in any of them is mechanical and the policy test covers them automatically on adoction.

session-grading_16-08-26.md says "only B1 was fixed"; consent-architecture-audit_REFERENCE_16-08-26.md presents B1 as the number-one *open* item. The code settles it: lib/sweep-autofix.ts already tiers lp-served-drift as confirm and demotes snippet-integrity and lp-live-render, each with a why string citing the registry (PR #1746). The consent audit reference is stale on B1. Its google-ads-conformance disagreement is real but is annotated in source as deliberately left.

It had failed curl (28) timed out after 295s on 08-09, 11, 12, 13 and 15, producing no output at all on each. Root cause was not the slow sites: the loop checked its 285s deadline *before* starting a site, then handed that site an unclamped AbortSignal.timeout(240_000), so the arithmetic worst case was 525s against a 295s cap. Fixed with lib/run-budget.ts (clamp the per-item timeout to the budget actually left, refuse to start an item with no workable slice), a per-site ceiling of 60s instead of 240s, and a stateless UTC-day rotation of the roster start index. Post-fix real run: success in 228s of 270s, 0 sites budget-skipped versus 29 of 39 on the last pre-fix "success". The one genuinely slow site (2596 drmelindasilva.com) now reports a per-site timeout instead of eating the fleet's budget. __tests__/run-budget-clamp-policy.test.ts was verified load-bearing by reintroducing the original bug.

Not a unit error and not an unmet condition: the timer was installed 18:02 on 08-15, after that day's 10:40 window, and Persistent=true had no earlier stamp to catch up from. Real run Result=success: 75 values generated, 0 failed, 36 clients, 12 deferred by the run budget as designed, missingValuesAtStart 393. Its route carried the *same* latent tail bug (270s + 90s against a 295s cap) and was fixed in the same PR, before its first scheduled fire rather than after.

The route, the SWEEP_AREAS entry and the morning-report line all shipped in #1750 with nothing scheduling them. A timer *was* the genuinely needed piece, and it is the measurement piece too: runtime/sweep-history.jsonl appends one row per area per day from whatever the sidecar last held, and it contained zero demand-gate rows, so the refused-volume series R1b depends on was not accumulating at all while lib/morning-sweep.ts rendered an aging snapshot as current. Installed at 07:20 UTC (40 min before the morning report, after the 02:48 GSC sync); real run Result=success in 8s; first history row landed: 2026-08-16, findings 6, scanned 29. The week of data starts today; re-read on or after 2026-08-23.

{"oid":"OID_OLDVAL","domain":"acme.com","live":50000} was being crawled every night against a domain we do not own. Removed at source via the assistant's DELETE /seo/sites/:oid (backed up first). Fleet is 38 real sites, not 39 — every sweep denominator that read 39 was wrong by one. Downstream sidecars already classified it junkDropped and regenerate. Same class as the 2026-07-25 QA-to-client-OID incident: a test identity must not be creatable in the production store.

Four-wave rollout specified (2470+172662, 170652+174693, 174637+2596, 174752), not one flag flipped. Addressable population is 8 of 39; 31 have no plugin connection and never can. Two self-imposed preconditions: demand gate verified live for one week (now started, see above) and a bulk revert route existing first (see C1). seo-substance-audit 220-352, PR #1752.

Deliberately undecided; the audit refuses to invent a cap and wants one week of demand-gate data. Unblocked as of today — the timer now accumulates the series. seo-substance-audit 336-339.

(1,268 real clusters found; fleet 404 -> 802 tracked keywords). Blocked on two measured facts: each tracked keyword is a recurring paid SERP call, and lib/seo/keyword-caps.ts caps every client at 25 with no overrides, so planTrim would delete most new keywords within a day. Needs a cap raise plus cost acceptance. machine-safe-sop-items 203-222.

585-term seed previewed against all 14 accounts with per-account refusal counts; zero applied, no apply path built on purpose. machine-safe-sop-items §3 and §7.

Zero platform presence, SOP in hand. operator-sop-assessment 306.

Named a top-four map-pack lever, zero code. operator-sop-assessment 308.

One sentence needed; the SOP should be amended rather than the architecture. operator-sop-assessment 310.

Resumable route exists, nothing schedules it on purpose: a full fleet pass is roughly 13,000 Search Console requests on the single operator token. Currently 10 of 27 clients reach past 2025-04-30. PR #1749.

scripts/r2-lifecycle.mjs encodes the policy but the token is scoped Object Read/Write, so PutBucketLifecycleConfiguration returns 403. Retention is client-side and depends on the nightly unit running. backup-restore-runbook.md §6 and §9.

, studiosight-assistant or studiosight-assistant-deploy? Both have live server.js with differing gate files, and several drift tests point at the non-serving one. consent-architecture-audit 412-414.

, or a survivor predating the rule? It auto-reactivates Meta campaigns at app/api/clients/apply-budget/route.ts:21-25. consent-architecture-audit 325-338, 415.

, env META_MAX_DAILY_BUDGET_CENTS (lib/meta-budget-anomaly.ts:11) or the hardcoded literal at app/api/intake/route.ts:1568? consent-architecture-audit 322, 417.

, or silently accumulating? It blocks only on blocking[]. consent-architecture-audit 418-419.

permanent writes *and* a nightly GSC-driven AI rewrite — but its tooltip describes only the first. Split the flag or fix the tooltip. consent-architecture-audit 136-156, 245-247 (migration step 4).

True for zero of 39 sites; no autopilot unit exists. PR #1751.

No apply path, on purpose. cd9239ba.

No write. cd9239ba.

(lp-served-drift auto->prepare, snippet-integrity and lp-live-render auto->operator). Correct, but drifted live pages now sit until someone taps. PR #1746.

lib/google-ads-create.ts records a shortfall and lib/build-quality.ts deducts 3; it cannot abort a build. calloutCategoryPromptBlock() is exported and consumed by nothing, because the generator prompt lives in the assistant repo. cd9239ba.

Every send is an operator action. PR #1737.

correct by inspection only. (Correction to the grading source, which first filed this as inert: MONEY_ROUTE_AUTH=on was verified in the running dashboard with all four class secrets and four routes returning 401.) PR #1738.

Every 30-minute process-approvals run since enablement logged repliesSeen: 0, so the first real approval will also be the first live auth test. Refusal path proven (three bad tokens, three 403s).

prepare in lib/sweep-autofix.ts, report-only in AUDIT_FIX_REGISTRY. Annotated in source as known. consent-architecture-audit 306-313.

and silently no-ops when it is absent, so the drift guard guards nothing. consent-architecture-audit 364.

consent-architecture-audit 365.

as required core slots. A control that cannot do anything. consent-architecture-audit 370.

, so they are invisible to knownFlags(). consent-architecture-audit 373-375.

Called "the single biggest gap in R1a's readiness" and a wave-1 prerequisite. Per-page restore works because every fix-log row carries oldValue. seo-substance-audit 305-313.

app/api/clients/apply-budget/route.ts:220 uses Math.max(100, ...) against Google's explicit $1-floor refusal. consent-architecture-audit 319.

on the route Google's lib/google-ads-campaign-budget.ts:28 MAX_INCREASE_FACTOR = 4 claims to mirror. consent-architecture-audit 320.

instead of using lib/google-ads-spend-limits.ts:102 atOrOverCap. consent-architecture-audit 321.

and obeys malformed caps that readSpendLimits() drops. consent-architecture-audit 323.

though its customerId is in the body exactly like the Meta twin that is guarded. consent-architecture-audit 346-353.

, the conversion-upload opt-in table — two unrelated decisions coupled by one constant. consent-architecture-audit 355-360.

, and the dashboard carries the known-broken number, causing 422 deploy failures. Two files. consent-architecture-audit 367.

app/api/cron/lp-served-drift-sweep/route.ts:98 trusts currentVersion, which lib/lp-live-render-sweep.ts:91 states is untrustworthy; client-build-lp-regen.ts:508 trusts the served marker. consent-architecture-audit 368.

the pre-regen snapshot in regen-gate.ts versus the operator-pinned sha256 in approved-assets.ts. consent-architecture-audit 369.

(ad-group for cross-ad-group terms, campaign for wrong-city, shared set for universally irrelevant). The sweep still operates at one level. machine-safe-sop-items 230.

Different repo, separate PR, not started. machine-safe-sop-items 228.

100 keywords, 2 ad groups, no brand tokens, so the negative preview fails closed. machine-safe-sop-items 94, 108-110.

Attempted 2026-08-26 and stopped before writing anything. Two hard conflicts, both in lib/niche-playbook.ts: (1) the shape has nowhere to put it. BudgetGuidance carries channel, cplBandUsd, typicalMonthlyUsd and expectedLeadsAtTypical. There is no field for a max CPC, no field for a daily-budget-to-max-CPC multiple and no field for a target clicks per day, and cplBandUsd is mandatory with 0 < low <= median <= high, so the band cannot even be stored as a stub. (2) the validator refuses it, correctly. validateAssertion requires evidence.clients.length >= 1 and evidence.n >= 1; the assessment that scoped this item says in terms that the band "has zero clients of evidence behind it today". A doc-sourced practice with no measured client cannot be written without inventing a citation, which is the one thing this schema exists to prevent. The real question is a design one and it is yours: does the playbook need a third provenance beyond default and suggestion for documented-but-unmeasured practice (say documented, ineligible for any build assembly until a real client backs it), or does this band simply not belong in the playbook at all and belong in the Google Ads build doc instead? Nothing is blocked on it either way. ORIGINAL: Playbook entries never entered. The cold-start bidding band (max CPC ~20% above top-of-page, daily budget >= 5x max CPC, ~10 clicks/day) and the per-niche junk classes were both scoped to enter lib/niche-playbook.ts as suggestion status; neither was written. operator-sop-assessment 165-176.

Unlike the bidding band these have real clients behind them: NegativeKeywordSet assertions citing Valley and AAAble would clear the evidence bar honestly, and lib/niche-playbook-seed-movers.ts is the working template. Not done 2026-08-26 because deriving the insurance junk classes means reading that niche's real search terms rather than typing a plausible list, which is its own piece of work. Insurance is the obvious second seed after movers.

the reason Quantum is last in the R1a wave order. seo-substance-audit 273.

The WordPress plugin has no media-alt endpoint (one of five defects on the pending plugin release). Until it exists, every alt fix is invisible to any non-rendering fetch. seo-substance-audit 340-343.

§5f is written to be executable, which is not the same as executed; the revised 1.5-3h RTO rests on it. backup-restore-runbook.md §9.

Went to delete the Quantum "fossil" and found there is no fossil. Every clause of the original entry is wrong: (a) the sidecar is not stale - runtime/seo/worklist/174752.json has computedAt: 2026-08-25T11:45:00.256Z, rebuilt yesterday; (b) Quantum is not excluded from the roster - /seo/sites returns 44 oids and 174752 is one of them; (c) it is not the sole violator, and it is not the worst. Counting targetKeyword across every worklist sidecar rebuilt in the same 11:45 run:

All 35 of 08-15's commits fall here; releases-deploy.jsonl could have been that ledger and has had no successful row since 2026-07-18. Also ungraded: limit-change and cap-pause (27 of 34 recent management decisions, the closest thing to a direct money lever), ad/ad-group-grain Google changes, account-grain conversion-action changes, and manual-edit. The graded rate is 12 of 1,530 changes in 45 days, 0.8%. Is there appetite for a code-change ledger? session-grading §4 and open question 5.

The premise "PR #1749" hid the real state: GitHub reports #1749 as MERGED, but its base was fix/conversion-upload-monitor (the old deploy trunk), not main. Measured: git ls-tree origin/main has no app/api/cron/sync/gsc-m*-backfill, and production answers 404 for both. Scheduling them would have installed timers pointing at nothing — the exact defect ef3e90a1 had just fixed for eight OTHER timers. DONE: cron/sync/gsc-monthly-mirror-backfill ported to main (clean — its four libs all exist on main with matching signatures), with unit files deploy/systemd/studiosight-gsc-monthly-mirror-backfill.{service,timer} (monthly on the 4th 07:40 UTC, tracking its source sync-gsc-history at 07:00; 07:40 collision-checked free; carries curl -fsS so a 404 can never report success). NOT installed on the box yet — the route must be DEPLOYED first, or the timer is the very defect it guards against. Also NEW: __tests__/systemd-unit-route-exists.test.ts closes the class — every shipped unit must name a route that exists (46/46 pass today; mutation-verified). STILL OPEN: sync/gsc-metrics-backfill is deliberately NOT ported — it depends on a lib/db/repositories/gsc-metrics.ts that diverged substantially on main (Phase 13/14 source-day work: 297 changed / 169 deleted lines), so it is a real reconciliation, and unlike the mirror it SPENDS Search Console quota.

GET /api/seo/fix-tiers publishes lib/seo/safe-fixes.ts's three tiers, the fixability -> application_method map, a flattened per-type view and a version consumers can key a cache on. It ships failClosed: true IN THE PAYLOAD as a standing instruction, so the rule travels with the data: an unreachable consent registry must STOP a consumer, never make it guess and never let it fall back to a built-in table (a stale built-in table is the exact drift this removes). REMAINING, different repo: the assistant's buildFixes still keeps its own copy and must be changed to fetch this and fail closed. Until it does, the duplication is published rather than collapsed.

Live sidecar 2026-08-25T12:15Z: scanned 57, findings 0 — "57 website-sourced grants re-verified, all still supported" — with THREE honest blind spots, all one client: King Moving's site was unreachable so no_hidden_fees, free_no_obligation_quote and same_week_availability could not be re-proven. That the unreachable case surfaces as a blind spot rather than a silent pass is real evidence the sweep discriminates. It still has never returned a positive finding, so the recommendation stands unchanged: revoke or scrub one evidence string on a test-OID client and confirm the sweep names it. Not done in this pass (it needs a fixture client, not a live one).

#1746 removed its nightly caller and left the route open; nothing intended it to stay ungated. It now carries a departed-client refusal (with an explicit rollback carve-out) and the same per-id lock structured-regen uses. See the entry below.

It is a MONTHLY-component cron on a WEEKLY Monday timer (studiosight-improvement-cycle, Mon *-*-* 06:50 UTC), and that timer is installed AND enabled. It had never *succeeded*, not never *fired*: journal shows Aug 24 06:50:00 ... status=22/n/a — curl exit 22 is an HTTP error, i.e. the 404 that ef3e90a1 fixed on Aug 25 by restoring /api/cron/improvement-cycle to main. Verified today by live dry-run (?dryRun=1, no writes): own-agency-growth computes score 93, 2 of 2 sub-reads judged, 100% coverage — Simplesight $84/30d, 13 leads @ $6, 2 standing referral candidates. Next scheduled fire Mon 2026-08-31 06:50 UTC; re-check the sidecar after it.

The naive rule ("bulk may only contain SAFE types") was measured to be WRONG and would have silently deleted a capability: _seo-detail-client.tsx bulkApprove() deliberately approves any approval-mode issue INCLUDING h1_* across the operator's current filter, after a human read those rows. So the caller declares a SCOPE and the server enforces the claim — safe refuses every non-title/meta type (the fleet button's promise, now the platform's), reviewed allows approval-mode types but never a server-required or snippet-auto one. Absent scope defaults to reviewed, so today's behavior and old tabs are byte-identical. Refusals are all-or-nothing (a partially applied bulk reports a count that does not describe what landed). Both routes also gained the client-lifecycle join, fail-safe direction inherited (unknown => active). lib/seo/fix-bulk-gate.ts + 19 tests.

lib/fix-family-kill.ts declares the families, their flags and the kill-wins-over-opt-in precedence in ONE place; the redirect gate delegates to it and keeps its historical flag name (renaming it would have silently disarmed any operator override already written into runtime/feature-flags.json) and its exact reason strings. The four new flags — seo-snippet-delivery-kill, seo-permanent-apply-kill, seo-autopilot-kill, seo-value-backfill-kill — are all hard enabled: false, deliberately not bare rules: a bare rule passes the non-prod env gate and would have ENGAGED all four kills in staging/dev on day one. Engaged, three families degrade to a DRY RUN rather than going dark (a brake that also hides the work cannot be reasoned about); value-backfill returns early instead, because every unit of its work is a paid LLM run so "would have generated" costs what generating costs. The snippet hot path answers with the empty payload its timeout path already returns, sent no-store so releasing the brake is immediate rather than 300s of edge cache away.

Premise re-verified and found PARTLY STALE: the 2026-08-24 port already made the producer's deliveryState authoritative, and isAutoHandled had been demoted to the pre-field fallback with a docstring reading "nothing but isDelivered/isSettled should call it" — while still being exported. A docstring is a convention; an unexported symbol is a control. Un-exported, with a test that goes red if it is exported again or if any module under lib/app/scripts reaches past the two producer-first predicates to call it.

Premise CORRECTED on inspection: it was not four copies of one list. lib/seo/autopilot.ts owns OPT_IN_KEYS (the AI/permanent opt-ins); the route retyped it verbatim as a local AI_KEYS; and safe-fixes.ts's AutoApplyAllowlist is a DIFFERENT key family (the deterministic Bucket-A titleLength/titleMissing/... toggles), not a copy. The real defect was the one retype, which meant a twelfth toggle could be added to autopilot.ts and stay unsettable through the only route that sets these. The route's echo-back is now derived from the same list too.

Confirmed: cron/seo-redirect-repair reads the DASHBOARD store (runtime/seo-404-recovery-state.json, which has the toggle) while cron/seo-404-recovery's live writes are gated by the ASSISTANT's own per-site copy inside /404-sweep, which has no surface here. GET /api/seo/sites/:oid/404-recovery-config now returns both values, the effective AND, and blockedBy; the site page renders an amber line naming the other half whenever it is the one holding the site back. It deliberately does NOT write the assistant's copy — reconciling two consent stores by silent overwrite replaces an invisible disagreement with an invisible override. Fail-soft: an unreadable assistant value reports unknown and a NULL effective, never true. Still open (cross-repo): collapsing the two stores to one owner.

Two gates added, one deliberately not. (1) LIFECYCLE: a DEPARTED client's page may no longer have NEW content published to it (getClientStatus, the same primitive structured-regen uses), refusing 409 with a named reason. The rule is about DIRECTION, not permission — re-deploying a version the project has ALREADY served successfully is an UNDO and stays allowed, because lib/lp-rollback.ts falls back to POST /deploy {versionId} when the byte-archive is unrecoverable and that fallback runs inside the failure path of a live edit. The carve-out reads the version's own recorded deploy.ok, which only a real completed Cloudflare deploy sets, so no body field can talk past it. Fail-safe both ways: an unknown client resolves active, and an unreadable project record is NOT gated (a lifecycle gate must never turn an assistant outage into a refused deploy). (2) CONCURRENCY: reuses withRegenLock — same coalesce-on-identical-x-idempotency-key, same 409 for a different concurrent mutation. NOT added, on purpose: a flag/lease. The lease exists to stop a CANARY surface being left open after a session; this is the ordinary operator publish path with many sanctioned callers (UI, sweep-autofix cron, promo-expiry cron, client-build, the scripts/lp-* tools), and a single-use lease would break every one of them to fix a problem it does not have. All sanctioned callers verified unaffected: __tests__/landing-page-deploy-gate.test.ts (12 tests) pins what is refused AND that an active client's deploy is byte-identical to before. consent-architecture-audit 289-302.

__tests__/sweep-autofix-registry-agreement.test.ts asserts exactly this, in BOTH directions: an auto sweep area has no confirm/report-only disposition in AUDIT_FIX_REGISTRY, and an area the registry marks auto must be auto in AUTOFIX_POLICIES too. It also pins the three areas that drifted on 2026-08-16 and asserts the nightly cron gates its deploy on the policy tier rather than a hardcoded assumption. Re-run at ad0a08ba: 5 passed. The ledger entry predates the test (shipped with the B1 fix) and was never ticked. consent-architecture-audit 402-405 is stale on this point.

lib/test-oid.ts is now THE constant, adopted by client-roster, qa-traffic, lp-builder/portfolio-view, lead-pace (as PACE_TEST_OID) and scripts/lp-substance-sweep-lib. It reads NO environment on purpose: this is the destination the QA refusal forces synthetic traffic to, and deriving it from an env var would let an environment name a client OID as "the test identity" — the exact 2026-07-25 failure. A test asserts every consumer resolves to the same value AND that no consumer re-declares the literal beside its import.

lp-builder/store.ts now calls isTestOid; the builder page reads STAGING_TEST_OIDS[0] (dropping a third inline || '2' spelling that could disagree with the other two under a malformed env value). staging-guard's own default is the canonical TEST_OID rather than a fourth retyped literal — the allowlist stays env-driven because widening what a staging instance may mutate is legitimately a deployment concern; the QA destination is not.

lib/client-lifecycle.ts resolves CLIENT_LIFECYCLE_PATH through runtimePath(), so a staging instance stops reading and writing production's lifecycle file. Production is byte-identical (the env var is unset there, so the resolver returns the legacy production root). Scoped to this one file on purpose per "smallest safe fix, never refactor unrelated code" — the other ~20 hand-resolved files are still covered by the shrink-only baseline in __tests__/runtime-root-policy.test.ts and remain open. Worst remaining offender noticed in passing: app/api/cron/sync/permanent-apply/route.ts hardcodes seo-permanent-apply-state.json.

DIVERGENCE MEASURED FIRST, not assumed: the dashboard's token-window rule grants two real phrasings the assistant's hand-written alternation was blind to — "Licensed local movers and insured for your protection" and "We are licensed; we are also insured" (both GRANT / BLIND). FIX: lib/risk-remover-gate-parity.ts DERIVES the deploy-side pattern from RISK_REMOVER_PHRASES.licensed_and_insured itself (jointClaimGateRegexSource()) — the window rule written out as A[^.!?]{0,20}B in both orderings — so it cannot fall behind the rules it comes from. The assistant's LICENSED_INSURED_RX now carries that generated source between BEGIN/END GENERATED markers, and its own landing-quality-gate-licensure-claim.test.js pins the two divergent phrasings by name. __tests__/risk-remover-gate-parity.test.ts proves the generated regex and the REAL extractor agree over a shared corpus in both directions, and (opt-in via an assistant-checkout env var) that the assistant file carries the pattern verbatim. MUTATION-VERIFIED: narrowing the window in the assistant file, or pointing the check at the unpatched file, each turns it red. NOTE for whoever revisits this — the cross-repo check compares the GENERATED SOURCE VERBATIM rather than rebuilding a regex from the file's literals; the rebuild approach was tried and FALSE PASSED on the unpatched file, because concatenating the old alternation's fragments (joined with | at runtime, not in source order) yields a pattern permissive enough to match everything. One asymmetry kept deliberately: the gate still flags bare fully insured, which the dashboard does not grant — the pact is that the gate must SEE everything the dashboard grants; it may catch more. consent-architecture-audit 366.

They are defaults for two DIFFERENT artifacts. schema.ts defaultDraft is the blank scaffold: no client, no form, no offer, so an overlay there would be an invented interruption. seed-draft.ts builds a seeded CLIENT draft that has all three and gets the operator's 2026-07-27 exit-intent safety net, reusing the page's own canonical form, exit-intent only, one show per session. Two artifacts, two correct answers. The cost of leaving that unrecorded was this re-investigation, so both sites now cross-reference each other and both values are locked by __tests__/lp-builder-popup-defaults.test.ts — changing either is now a deliberate act with a red test in front of it.

process/general-plans/references/client-facing-docs_26-08-26/: (01) website photography creative brief for a hired photographer, (02) taking great photos yourself for a client with a phone, (03) Google Business Profile setup AND video verification merged into one document, (04) branded email on your own domain. Four files, not five, because the assessment that scoped this said to keep the two photography docs separate and MERGE the GBP guide with the verification checklist. Prices are deliberately absent from (04): the two hardcoded figures were the reason the old one went stale, so it points at each provider's current pricing page instead. Section numbering in (02) is continuous, which was the one edit the assessment asked for. Nothing has been sent to any client or linked from onboarding. ORIGINAL: Five client-facing documents never produced: photography brief + guide as an asset-request pack, merged GBP setup + video verification doc, branded-email guide with stale prices stripped. operator-sop-assessment 178-188.

Verified first rather than assumed: the /home/ubuntu/.hermes DIRECTORY is absent entirely (not just the file), and grep hermes ~/.config/systemd/user/*.service returns nothing, so no unit was ever loading it. all-context.md now names only the two real env files and says in place why the third is gone, with the SECRET_PATHS requirement recorded against the day it is ever created. Found while doing it, not fixed here: RUNBOOK.md still cites the same non-existent path five times (lines 37, 53, 129, 173, 189), twice as an EnvironmentFile source and once as where META_APP_SECRET is loaded from. That is a bigger and more misleading surface than the one line this item named, and it needs its own pass. ORIGINAL: /home/ubuntu/.hermes/.env is named in all-context.md and does not exist. If created it must be added to SECRET_PATHS in scripts/secrets-backup.sh. backup-restore-runbook.md §9.

The class behind the entry above is real even though its example was not: a cron that writes runtime/seo/worklist/<oid>.json for every roster oid, and never deletes one, leaves a permanent artifact behind every departed client. /api/cron/seo-worklist now prunes sidecars whose oid the roster no longer names, behind three guards in lib/seo/worklist-sidecar-prune.ts (an empty roster prunes NOTHING, a run that rebuilt no site prunes NOTHING, and an oid still in the roster is never touched even when its own rebuild errored), and reports pruned in its response. 9 unit tests. It correctly does NOT touch Quantum, which is in the roster. What it WILL clear on its next run are the three genuinely orphaned files sitting there today: OID_OLDVAL.json and OID_DEBUGVERIFY_1784673382.json (the "a test wrote into production state" artifacts already on this list) and 2402003.json (the SEO site removed by the curl -X DELETE route probe). Shipped as PR #1995, awaiting review; the prune runs on the first cron pass after the dashboard next ships.

The premise above ("Quantum sole violator, pre-fix fossil") was false: #1747's fix merged into the abandoned trunk fix/conversion-upload-monitor on 08-16 and NEVER REACHED MAIN — main was byte-identical to the fix's parent. 23 of 47 clients breached (worst: one keyword owning 611 pages, Quantum; Silva 190; Brentwood 157 — the very client session-grading cited as proof it worked, verified honestly against a branch that never shipped). Fixed: #2000 ports the enforcing layer to main (max-1 by construction via claimByPage) + artifact-derived integrity detector as a sweep area (23-breach reading confirmed pre-fix; stale/unreadable = blind spot never pass); unit -f fix #2001. Sidecars stay wrong until the joiner re-runs post-deploy — the sweep reporting 23 breaches until then is honest. CLASS DEFECT: stranded trunk commits keep producing casualties (#1747, #1749, #1737, #1201) — full trunk-residual audit is the class fix, in flight.

snippet-integrity does not scan sites AT ALL. Its 3 is the three READINGS OF ONE FILE — served (HTTP GET of public/ratesight-seo.js), working tree, and git show HEAD: — compared for drift, which is why today's sidecar headline reads "served, working-tree and committed copies all report v6". There is no site population to select from and never was, so "3 out of 38 sites" was a category error. Live read 2026-08-25T12:27Z: scanned 3, findings 0, blindSpots 0. Nothing to fix; the area is measuring exactly what it claims to.

Both halves were closed on 2026-08-16/17 and the ledger never caught up. lib/component-registry.ts now makes a zero denominator UNJUDGEABLE (null, never 100 and never 0), marks a small denominator NOISE, refuses to state movement between cycles that judged different populations, and renders a component UNJUDGED rather than publishing a score with no denominator — enforced in computeScoreboard so it cannot be reintroduced. app/api/cron/sweep-autofix/route.ts separately replaced the "0 findings across 0 scanned" sidecar with a TRUE coverage denominator: every finding the other sweeps raised that an auto-fixer could conceivably act on. The honest number is small on purpose and now visible instead of implied.

Live sidecar 2026-08-25T12:35Z: scanned 13, findings 3 — "3 of 13 applied decision(s) are no longer in effect; 0 could not be verified". The denominator is back at 13, the same value it held before the Aug 14 dip, which is what a rolling 30-day window does and is not consistent with a lost population or broken selection. So the Aug 14 reading was a window artifact, cross-channel-management's +24 was noise wearing a signal's clothes, and the durable fix already shipped (see the guards-autofix entry: movement is now only stated when two cycles judged the same basisKey).

The KNOWN_UNGATED list in __tests__/departed-cron-filter-policy.test.ts was recorded the same day as five routes to review later. Reviewed now, and three of the five recorded justifications did not survive reading the code. GATED: connected-audit (it PERSISTS an artifact and EMAILS score drops — per-client automation, and its hard 250s budget means a departed client scanned is an active one skipped; the ?oid= path feeds the same gate, matching client-audit-reports); geo-market-sweep ("keyed by geo, not client relationship" was factually wrong — the roster IS the identity map and the market comes from that client's GBP); lp-destination-conflict-sweep (the wish to keep seeing a departed client's live page was right, but its OWN siblings lp-completeness-sweep and lp-tracking-install-sweep already grant it correctly, by gating AND pushing a named blind spot carrying the live URL — so gating loses no visibility and makes the three LP sweeps agree; its second roster read, the LP project list, is gated too, or the route would skip a client for split findings and still raise orphan ones); seo-quarterly-outcomes ("historical rollup over a period they were active" was wrong — the window is a ROLLING 90 days recomputed DAILY, so it drifts to cover post-departure months where by definition no work was done, and being WORST-WINS it lets a client we no longer serve set the fleet headline; its "empty roster" error now says *departed* rather than the false *not on the identity roster*). DELIBERATELY NOT GATED: cross-channel-clients — it rebuilds the canonical identity map that departedCustomerIds() itself reads to resolve the exclude-set, so gating its roster would empty that set and silently un-gate every other sweep; it is also the /by-client reconciliation surface, which matters most while a departure is being unwound. Its one piece of per-client automation (baseline captures on connector-join changes) IS gated, and that narrow shape is pinned by its own assertions rather than a comment. Every gate REPORTS what it skipped. Live population: 2 departed (Quantum 174752, White Rose 2402005), both holding seed-source Google Ads bindings and both sitting in the 25-account roster the two Ads sweeps scan. Mutation-verified: removing a gate fails the suite. 74 tests green.

Live sidecar 2026-08-25T12:20Z: scanned 57, findings 13 with SIX named blind spots that account for the whole gap — Google Ads: 30 dry runs and 36 service builds that never reached googleAdsCreate (they created no live artifact); Meta: 29 of 40 builds carry no campaignId (no live campaign), 5 of 11 record no avatar so fit cannot be judged, 2 of 11 unjudgeable at all; Landing pages: 32 of 42 record no avatar, 1 of 42 unjudgeable. Exclusion is ARTIFACT-EXISTENCE based, not roster based, so the departed-skip list was never the explanation. Closed by the 2026-08-17 named-populations work, which turned silent drops into this list.

whiterosemoving.com, rhino-moving.com, golfcartelite.com. Uninstrumented = no automatic fixes and no measurement. (Rhino's noindex WAS fixed today; its snippet was not.)

correct for a build-in-progress domain. Confirm it should stay that way, or it will keep appearing.

Re-measured rather than re-reported: GBP snapshots have synced since this was written, so three of the five now resolve a market from the client's own declared facts. SEEDED AND VERIFIED (raw rows read back from /rank/targets): 400059 Angel Touch, location Las Vegas, NV (source gbp-service-area), organic 19 keywords weekly + local 5 keywords on a 3x3 grid monthly; 94563 Beach Physio, location 93117 (source gbp-postal-code, Goleta CA), organic 25 keywords weekly + local 5 monthly. Both had zero tracked keywords before, so nothing could be lost. STILL REFUSED, and correctly: 174719 Cincinnati Appliance has no gbp.json at all, and 2634 Simplesight has none either. BLOCKED ON A MISSING PATH, not on facts: 400036 H&U Express resolves to Gretna, LA because the service-area ladder takes the FIRST place in the GBP list, and their own site titles every page "New Orleans, LA 70002" - seeding on Gretna would measure the wrong market. The city override lives in runtime/seo/brand-groups.json, which is operator-authored and has no write route anywhere in the repo, so the only way to set it today is hand-editing a runtime file, which is forbidden. Same blocker applies to 174719, whose own site says "Appliance Installation in Cincinnati, OH" in its H1 and its Location line. NEEDS ONE SENTENCE FROM YOU: 2634 Simplesight is our own sibling brand, an AI-lead-pages product, and its site's only ZIP is 84663 (Springville, Utah). Local rank tracking for it may simply be wrong rather than blocked. ORIGINAL: 5 clients cannot be seeded for local rank: no ZIP, no GBP city, no service area (cincinnatiapplianceinstall, simplesight, huexpressmoving, angeltouchremodeling, beach-physio). The seeder refuses rather than invent a market.

Something ran 2026-07-24 00:10 UTC with unexpanded template variables and created OID_OLDVAL/acme.com + OID_DEBUGVERIFY_1784673382. Neutralized in code, not traced. Same shape as the QA-to-client-OID rule.

still unpaid (quiet now).

is the real test: first run with the new cap, DataForSEO, and 23 due targets. DataForSEO took ~57s for 9 markers and the jobs worker runs maxConcurrent 2, so expect it to be much slower than serper. Its path was marked "untested" in code and is now tested on exactly one target.

carry the new section for the first time.

(#1529, #1545). Both live-site verdicts existed only as per-client buttons writing to a per-process Map: prod read tag: not-checked 39/39, indexing: not-checked 39/39, snippet: never-checked 28, with ZERO not-detected — the fleet was UNOBSERVED, and snippet-live gates unattended fix apply. Now studiosight-seo-evidence.timer every 6h. Fleet reached 0 never-checked the same day.

(#1530, #1531). baseline-delta compared LIFETIME endpoints and majority-voted, so EVERY client read improved — including one whose localRank had REGRESSED. Now a 90-day window + worst-wins + rank-only verdict, landing in the 13:00 report as the seo-quarterly area. First honest run: 8 regressed / 35 not judgeable / 0 improved.

(#1533, #1534). The seeder tagged every keyword ['organic','local'] and wrote only the organic half, so 40 of 43 clients had NO local target. 25 of 39 now have one, create-only, intent-tiered, 5 keywords on a 3x3 grid.

(#1544). All 37 local targets ran on serper (city-level): 25 markers returned 1-3 distinct values in blocks, so we paid 9x for 1x of information AND called it "#1 across every neighborhood / 96% grid visibility". All 37 switched to DataForSEO; the UI now respects the coverage field the API always returned.

. Drop-in 50-rank-budget.conf: cap 9000 (vs 4,689/month measured), cost cap $15, and SERPER_COST_PER_CALL=0.001 — it defaulted to 0, so the cost ledger read $0.00 forever and the USD cap could never trip. The old 2,300 cap was refusing scans.

(#1535, #1536). The row saying what to do FIRST moved from y=2205 to y=255. Also stopped the page celebrating (🏆 Ranking #1...) directly above its own red "Slipping" banner.

(#1537, #1539, #1540, #1543). 21 of 39 routes had no UI. /google-ads/actions ships 10 preview-then-confirm actions and adds no Google Ads API code. The ad picker states the Beach Physio diagnosis itself: *"16 ad(s) across 1 destination(s)."*

(#1532) and stops headlining items its own snapshot vetoed.

(#1541). 91 failed CI runs in 24h, all billing-blocked. Workflow disabled; push: ['**'] narrowed to main so it cannot flood again when re-enabled.

Measured against rank_snapshots + tracked_targets, not inferred. (a) The binding constraint was the SCAN CADENCE, not the 14-day window. 39 of 40 local targets are on a MONTHLY cadence, so they cannot produce a comparable pair in under ~30 days; 22 of them got their FIRST DataForSEO scan on 2026-07-31 (the serper -> DataForSEO switch) and are due their second on 2026-08-30. The 08-13 date assumed lib/baseline-delta.ts's 14-day minimum governed. It does not. Local rank becomes judgeable ~2026-08-30, not 08-13. Today seo-quarterly says so per client: every regressed row reads unmeasured: localRank (5/5 tracked keywords not judgeable: only 1 scan date inside the last 90 days; 2 are required). (b) THE DEFECT. Every one of the 40 targets carried a next_run_at landing just AFTER the 07:15:00 timer boundary (23 at 07:15:00.451, 13 at 07:15:03), because the enqueuers advance by requestTime + cadence and so re-anchor on when the request happened rather than the boundary it meant to hit. The run that should collect them starts a fraction of a second early, reports due: 0, and they wait a FULL EXTRA DAY — silently, since {"ok":true,"due":0} is indistinguishable from a healthy nothing-to-do. The 2026-08-25 07:15 run did exactly that with 13 targets waiting. On a monthly cadence that is ~12 lost scan days a year. Fixed in lib/db/repositories/rank.ts with a one-hour DUE_GRACE_MS on BOTH due queries (local and organic), so the class is closed once rather than per cron: it can pull a scan slightly earlier, never skip one, and can never double-fire.

assistant PR #219 merged + on prod checkout. ONE template (local_trades_long); the other 5 deleted; every legacy style/templateId coerces to it. Review slider re-added (scroll-snap carousel, 2-up desktop / 1 mobile, arrows + dots, controls stripped <3 reviews). VERIFIED: em-dash-free, render smoke passed. NOTE: the LIVE 24 pages are Builder (lpb-) renders, not this assistant template — the assistant template is the standalone-generate path.

assistant PR #220 merged + on prod checkout. Removed the prompt/schema↔render mismatch left by #219: pickTemplateForIndustry dropped, isLegalIndustry() preserves law-firm compliance auto-bump; niche schemas + prompt builders + 4 orphaned renderer modules deleted; 5 tests repointed. VERIFIED: 849 pass / 16 baseline fail, zero new failures; legal footer preserved.

assistant PR #221 merged + on prod checkout. A page now ADOPTS its client's existing published GTM container instead of cloning a duplicate (one container per client — the correct GTM design). 6 unit tests, zero regression. APPLIED: Quantum bay-area + long-distance (had gtmContainer:null) adopted GTM-NNPBLZTQ, regenerated + VERIFIED live (container present, verify:OK, slider+FraudBlocker intact). Quantum has 4 legacy per-page containers (pre-existing, not consolidated — separate cleanup).

dashboard PR #1210 merged to trunk. Standalone POST /api/landing-page/generate now branches on a dedicated lp-generate-structured flag → the deterministic buildStructuredLpFirstVersion factory (same path client-build.ts uses, lpb- template) when ON; assistant lp- generator when OFF. Flag is staging-ON / prod-OFF (prod-safety gate) so it's prod-inert until deliberately flipped. Staging-validated (built+booted+ledger-recorded). NOT reusing lp-builder was deliberate — that flag is already enabled fleet-wide in prod.

restarted studiosight-assistant (activated #219/#220/#221), health-checked. Staging assistant (-staging, feat/lp-shadow-canary-deploy) was 47 behind main → merged prod's main in (1 import-only conflict, resolved as unions), suite 870 pass / 16 baseline fail, restarted healthy :9126, now 0 behind main. Dashboard staging already = prod (569c0ed3). Pushed the merge so origin doesn't drift.

deterministic curl audit: BOFU visible offer, review slider, FraudBlocker, version marker, lead form all 24/24 ✅. The "BOFU missing / slider gone / tags missing" fear was about the retired assistant template, not what's serving. Meta Pixel: only Meta-advertising clients need one (White Rose departed; rest Google-first) — deterministic-to-inject, IDs operator-supplied, never guessed against shared accounts.

(added 2026-07-29, diagnosed read-only): the new ads-copy-quality sweep flagged 16/16 pairs mismatched; root cause is NOT 16 copy defects but one generic page serving 16 intents. Live shape: 3 enabled Search campaigns at $25/day each ($75/day armed), 16 ad groups spanning 4 services (Physical Therapy, Back Pain Treatment, Sports Injury Rehab, Post-Surgery Recovery) x 2 cities (Carpinteria, Goleta) x lanes Near Me (7) / Brand (2) / Locations (7) — every ad points at https://beach-physio.pages.dev. Only ONE LP project exists for this client (ce255dcb-…, v21, latestStatus: draft while an older version serves). Severity is MODERATE not Horn-Law-critical: the page H1 is good ("Physical Therapy in Santa Barbara County That Treats the Cause, Not the Sore Spot") and it DOES mention all 4 services. Two concrete misses: (1) it names neither city while 7 ad groups bid on Carpinteria/Goleta terms; (2) the ads promise "No pressure" and the page never says it (all 16 pairs). Spend so far is only $7.33/7d, 3 clicks, 0 conv — so this is pre-scale hygiene, not an active bleed. Canonical fix per google-ads-canonical-architecture.md = 6 destinations (Brand page, Near Me page, + 4 service pages), then repoint the 16 final URLs. NOT done: generating 6 client-facing pages and repointing live ads is a build + client-facing decision, operator-gated. Cheap interim options if the 6-page build is deferred: add the two cities + the "No pressure" risk-reducer to the existing page, or drop the unsupported "No pressure" line from the ads.

(added 2026-07-28): live build ba7c55ca went partial — every Cloudflare deploy 422'd ("project name must be 48 characters or fewer"; our multi-service slug was 61-62 chars) so GTM + ALL Google Ads steps stayed pending → zero ads created. NOT a timeout/polling problem. The later 21:28 run was the Preview (dry run) button (there is no retry button) — dry runs never create ads, and it failed at googleAdsValidate with MISSING_PROTOCOL on bare newmans-hvac.com (the Angel Touch class; fix sat unmerged in PR #847 since July 8). Fixes open: dashboard PR #1429 (48-char clamp + cherry-picked ensureUrlProtocol, onto trunk) + assistant PR #243 (slugifyProject 58→48). After merge + service restart (operator-gated), re-run Build for real (paused) for Newman's — avatar + LP steps are idempotent-safe to re-run.

(2026-07-29, operator report: "employees getting lost") — PR #1506 (base = trunk, not merged).

(from reviewing the last 7 days of studiosight-bugs, 125 records):

(added 2026-07-29): intake dropdown hid pages Ads Manager offers, because the filter read only act_<id>/promote_pages. Measured live: 49 of 111 managed pages were promotable from NO ad account (incl. AAAble Insurance, Brentwood Blind, Silva MD, Simplesight); Studiosight - 5 reported 1 of its business's 85. Fix unions the ad account's owning business (owned_pages + client_pages) with a source tag. PRs open: studiosight-meta#47 (service, merge FIRST) + dashboard#1484 (UI evidence labels, base = trunk). After merge: systemctl --user restart studiosight-meta (operator-gated). Verified on isolated port 9227: S-5 1→85 promotable, orphans 49→28, 0 cross-business leak, 61/61 tests. Also fixes a latent gap where the ↻ Refresh button never busted page-account-map, so the filter served stale data up to 10 min. Remaining 28 orphans are client partner-grant pages that neither signal lists — override-only, not addressed. Interim: Simplesight has an allow-override on act_414164589156474 (redundant once #47 ships; can be removed in Settings).

(added 2026-07-02, audit DONE read-only): client 172590 → GA customer 6112099554. Account NOT spending ($17.52 from a paused legacy campaign) → no fire. HIGH: conversion tracking chaos (56 actions, ~20 enabled+primary, dup SUBMIT_LEAD_FORM across 6 ConvertBox subdomains + 2 Google-managed; requires-manual-review; Studiosight's seeded action 7641754256 is correctly primary). HIGH: not on B2 (single RSA campaign, 2 ad groups, no Locations/Near-Me/Brand, 14 legacy paused). LOW: keyword hygiene good (add negative budget blinds). Final URL = the GOOD page (200) but saved http:// (redirect hop); scorecard 80/100 (warns: http hop, missing honeypot, no LP gtag). Report: process/features/google-ads-build/reports/BRENTWOOD-GOOGLE-ADS-ALIGNMENT_02-07-26.md. Conversion cleanup must precede any promo spend. All fixes operator-approval-gated.

Phases A/B COMPLETE, C partial. Both staging

(discovered 2026-07-24). SWEEP 2026-07-24 (auto-trigger = genuinely OPEN): the scheduled START/END-boundary auto-trigger for the #223 record-injection path does NOT exist. An adjacent END-only sweep exists on a DIFFERENT mechanism (app/api/cron/lp-promo-expiry/route.ts + lib/promotions/promo-window.ts, PR #1112 dated-promo path, dry-run-default + lp-promo-expiry-autoregen flag) — it strips EXPIRED promos but does not cover the START boundary and does not use the #223 PromoRecord injection. Recommendation: YAGNI — the promo already applies on the next incidental deploy (frequent) and Brentwood is live; build the boundary-day forcing cron only if a promo actually misses its window. CORE DONE 2026-07-24 (assistant PR #223, merged to main): the LP deploy handler now injects the client's ACTIVE promo from its record (date+paused gated by promoState) alongside the version-marker/FraudBlocker/pixel chain, and STRIPS a stale bar when inactive — marker-wrapped (idempotent+reversible) and, crucially, it rides EVERY deploy so a regen never wipes the promo (the fragility that dark-ed Brentwood for 15 days). Pure toPromoRenderInput mapper + 5 tests. So a promo created in the UI now applies the next time that client's LP deploys (regens are frequent) and survives regens. ACTIVATED + VERIFIED 2026-07-24: #222 (persist route) + #223 (deploy-injection) + #224 live on prod :9122 (ff -deploy + restart, healthy). The activation check caught a REAL bug: the live Brentwood record is the LEGACY assistant shape (label/offerText + scope.projects), not the dashboard PromoRecord shape — #223 as-shipped would have STRIPPED Brentwood's promo on its next deploy. #224 fixed it: toPromoRenderInput reads either shape; new promoAppliesToProject gates per project (dashboard applyToLP=all pages; legacy scope.projects=only listed pages). Verified against the LIVE record: title maps to "Free Motorization Upgrade", scoped project applies=true; Brentwood's live promo intact + now durable across regens. REMAINING (own change, higher blast radius): a scheduled AUTO-TRIGGER — a daily cron that forces a redeploy on the promo's start/end boundary day when no other deploy happened, so the promo flips EXACTLY on schedule instead of on the next incidental deploy. Build dry-run-default + per-oid flag-gated (same safety model as promotion-sync); this is the autonomous-deploy piece so canary a test-OID first. Companion UI note already corrected (#1215: panel no longer claims automated apply).

Phase 1 LIVE (record schema lib/promotions/schema.ts + read-only store + reconcilePromotion pure spine + daily promotion-sync + HTML-injection reconciler; Brentwood live). Phase 2 plan: process/general-plans/active/promotion-system-phase2_PLAN_24-07-26.md. Slice A API layer DONE 2026-07-24 (both staging-validated): dashboard PR #1211 GET/POST/PUT/DELETE /api/promotions/[clientId] (GET read+state; POST validate+dry-run-preview no-persist; PUT full-validate→proxy-persist; DELETE proxy-remove; URL clientId authoritative; 9 route tests) + assistant PR #222 lib/promotions-store.js + POST/GET/DELETE /promotions/:clientId (env-aware atomic write, path-traversal-guarded, sanity check; the assistant owns runtime/ so the WRITE lives there per the hard rule; 6 store tests). Both typecheck/lint clean, zero em-dashes, full suites green. Slice A UI DONE 2026-07-24 (dashboard PR #1212, merged + staging-validated): route-private PromotionPanel on the client detail page (beside AccountsPanel) — current-state badge, Preview (dry-run), Save (PUT), End (DELETE), live (R)/(TM)->®/™ preview, datetime-local<->ISO, surface checkboxes + paused. Derives editable value (no set-state-in-effect). So Slice A (create/edit/end a promo from the dashboard for LP + banner surfaces) is COMPLETE. Slice B DONE 2026-07-24 (dashboard PR #1213, merged + staging-validated): lib/promotions/google-asset.ts (pure promo-record->PromotionInput mapper + parseDiscount $/%/up-to; honest refusal when no structured discount) + POST /api/google-ads/promotion-asset (reuses existing addAdGroupPromotion; validateOnly default, apply:true = operator-confirmed live create). 11 tests. So Promotion System Phase 2 Slices A+B are COMPLETE (create/edit/end a promo from the dashboard; LP + banner via the reconciler; Google PromotionAsset via the validateOnly route). REMAINING: (d) Slice C per-placement injection anchors (hero/below-hero) — DEFERRED, the top banner covers the need. Also pending (no urgency): assistant deploy+restart to activate #222 persist route (fold into next assistant deploy); the RSA-headline-text ad surface is an alternative to PromotionAsset the reconciler already computes (reconcilePromotion.rsa) if you want free-form ad copy instead of a structured asset — not built (a live RSA edit = suggest-then-confirm). NOTE: #1211 (dashboard trunk) + #222 (assistant main) both MERGED 2026-07-24. Activation of the persist route needs an assistant deploy+restart, but there's NO urgency (no UI consumer yet) — fold it into the next assistant deploy. Dashboard PUT/DELETE returns a clean 502 until then. ORIGINAL: time-boxed per-client promo that updates LP + RSA + offer together and auto-reverts by date; Brentwood motorization = first instance.

SWEEP-VERIFIED DONE 2026-07-24: both emailed reports exist + the tool is in-code (lib/seo/seo-scorecard.ts + tests) + UI shipped (app/seo/audit/page.tsx, /api/cron/seo-audit); listed residuals (GSC OAuth, 3 branches awaiting deploy) are operator/decision follow-ups, not a broken audit. (added 2026-07-02, DONE 2026-07-03 + fixes; report EMAILED to david@): 2 read-only audit reports in process/features/seo-audit/reports/ (AUTOMATION-VERIFICATION + CORRECTNESS-AND-AUDIT-TOOL). Verdict: engine sound/deterministic (28 modules, 0 runtime LLM in scoring). 19 ops: 15 working, 1 broken, 1 dead, 2 not-yet-run. FIXED: (a) redirect non-convergence — assistant deployed (45a610f), dashboard committed-for-review 19c2433; (b) two timed-out crons (seo-url-inspection, sync/page-improvement) via batchSettled+soft-deadline — branch fix/seo-cron-timeouts pushed; (c) BUILT the true SEO audit scorecard v1 (read-only, deterministic, 6-dim, fleet roster rhino39→Quantum87) — branch feat/seo-scorecard, UI deferred. DECISIONS FOR OPERATOR: GSC connected on only 6/24 sites (OAuth action — highest impact); dashboard build RED from pre-existing uncommitted work (client-landing-input, rank-grid exports) BLOCKS all dashboard deploys; seo-autopilot dead-trigger (wire/delete); 3 dashboard branches await operator-authorized deploy. FOLLOW-UP: hero-image per-service extraction (folded into lean-BOFU spec); scorecard dashboard UI.

SWEEP-VERIFIED DONE 2026-07-24 (Brentwood live 200 + lpb- builder markup + white header + promo bar confirmed; Aloha/White Rose live re-check was network-blocked from the sandbox only, code state complete). (added 2026-07-02; RE-SCOPED 2026-07-04 by screenshot): the 4 named clients are ALREADY DONE — Aloha (colored wordmark bar, correct), White Rose (green wordmark bar, correct), H&U (white, image logo), alhorn/legal_long (white, serif logo) all regenerated Jul 3 after both fixes + screenshot-verified. REAL WORK = QUANTUM: 10 deployed pages (ratesightId 174752) ALL on the OLD cramped 3-step form; 9/10 on the WRONG NAVY header (white-box logo on navy = hated case), only bay-area-movers correct. Fix is in DEPLOYED code (form split e455969 + logo-aware header 3d65f30); regen (reuseSlots keeps copy, re-templates form+header) flips them to split 4-step + white header. Turnkey via reconciler's GET/generate/version/deploy. Risk: resolveImagery missing a logo → navy fallback → set explicit input.logoBg:#ffffff + regen. DONE 2026-07-04: 9/10 Quantum pages regenerated to split 4-step form + WHITE header + branded swoosh IMAGE logo (canary quantum-moving + 8 batch), screenshot-verified by orchestrator (desktop+mobile), no fails/rollbacks, copy preserved (reuseSlots; only Ratesight review quotes refreshed). Bonus: 4 pages had a WRONG logoUrl (googleReviewIcon.png) — corrected to the real brand logo. Two-pass: pass 1 white header + form (text wordmark, logoUrl null); pass 2 set logoUrl=quantummoving.com swoosh → branded image. All operational (CF Pages deploys, no code commit — fix was already in deployed assistant code). Rollback versionIds recorded per page. bay-area-movers RESOLVED 2026-07-04: migrated to local_trades_long split 4-step form + white header + branded logo, then (operator call) restored the stronger v32 pain-driven hero ("Bay Area Moving With No Hidden Fees or Surprises") while keeping the new form. Orchestrator screenshot-verified. Live CF f4793b88. Fleet now 10/10. Plan: process/features/landing-page-visual-polish-fix/active/LP-FLEET-ALIGNMENT_PLAN_04-07-26.md.

SUPERSEDED/DONE (see the detailed "Brentwood promo — LIVE on all 6 pages 2026-07-23" item below). VERIFIED 2026-07-24: live page brentwood-blind-company.pages.dev renders the "Free Motorization … Save Up to $500" bar. Auto-clear after 08-08 confirmed by dry-run. This top-of-file stub is the original ask; the item below is the implementation record. ORIGINAL: Promo copy locked — "Limited-Time Offer: FREE Motorization on Silhouette® & Pirouette® Shades. Save Up to $500 Per Window." Client 172590. Start 2026-07-08. Deliver via the reusable Promotion record + date-reconciler; Brentwood = record #1.

SWEEP-VERIFIED DONE 2026-07-24 (all fixes present in assistant code: review-count via render-html.js:1153, derivePageFocus() H1, logoBg white-header invariant :1437, honeypot, promo no-op; live Brentwood confirmed. "Phase 4 promo" is tracked separately as items 16/26.) (added 2026-07-02): CODE DONE + PUSHED to origin feat/lp-promo-quality-fixes (6 commits = live deploy-head feat/ads-copy-seo-redirect-noindex + 6; PR: github.com/studiosight/studiosight-assistant/pull/new/feat/lp-promo-quality-fixes). Fixed: motorized-shades "4 reviews" bug (quotes.length-as-count); keyword H1 via derivePageFocus (bites on single-service spinoffs; residual: multi-service spinoffs need dashboard intake to set inputData.serviceType/pageFocus); rounding 50→10; header respects input.logoBg (light logo never colored); {{PROMO_BAR}} no-op-safe; static honeypot; deterministic POST /client/profile/:id/refresh-reviews (fired for Brentwood 172590: 169→171, now "170+"). 55/55 new tests, zero new lint, byte-diff regression + no-op proofs. LIVE 2026-07-02 (operator-authorized deploy): assistant fast-forwarded to d5bc4a9 + restarted healthy; Brentwood good page (d771b646) regenerated → CF Pages deploy 30cb7971, live-verified (buttons not dropdowns, "170+", correct header, honeypot, promo no-op). Discovery: the "good" v52 page was STALE on the form (dropdowns, pre-2026-06-23 buttons fix); Jul-1 spinoffs already had buttons. Rollback: code git reset --hard 50b8bb6 on feat/ads-copy-seo-redirect-noindex + restart; page re-promote CF deploy 545bcc3a. All 8 pages (good + 7 spinoffs) redeployed + BROWSER-VERIFIED 2026-07-02. HEADER REGRESSION found + fixed: my first deploy flipped the unset-logoBg default white→brand.blue → white-box logo on a blue bar (the operator's hated case; caught via puppeteer screenshot, NOT curl). Root fix render-html.js:1155 unset logoBg → '#ffffff' (deploy head now bbda9f4; rollback d5bc4a9; 25/25 tests). Per-page fail-fast redeploy + live puppeteer verify: all 8 render white header (rgb 255,255,255, logo blends), step-2 buttons (0 select), "170+" reviews; motorized-shades "4" fixed. Independently re-confirmed live by orchestrator. LESSON: verify header/form fixes by rendered screenshot, not CSS values/curl. Fix ff-merged into deploy branch locally, NOT pushed. Phase 4 (promo system) not started.

Collapsed the two-generator split. P2+P3 (PR #1231): /api/landing-page/generate now runs buildStructuredLpFirstVersion UNCONDITIONALLY (dropped the lp-generate-structured flag branch + the assistant-proxy fallback); removed "Build Instantly" + deleted /api/landing-page/build (redundant — Builder's seeded-bank fallback is the instant path); retired the orphaned flag; SSE-parity test updated; net −100 lines. typecheck+lint clean, staging-validated, prod-deployed. Verified safe before shipping: 30/33 LP projects were already structured-builder-v1; the 3 non-Builder are UNDEPLOYED ASAR drafts (local_trades_long, zero live pages), so no live page used the assistant lp- generator — the standalone create + all live regenerate flows are Builder. The detail-page legacy slot-edit flows (promptEdit/refreshForm) only ran for those non-Builder drafts and now migrate-to-Builder on edit (non-crashing, aligned with the single-template directive [[single-lp-template-directive]]); the validator panel for legacy regen degrades gracefully (optional-chained). REMAINING (trivial cleanup, low urgency, NOT live-blocking): (a) physically delete the now-unreferenced assistant lp- generator in the assistant repo (server.js /landing-page/generate + /landing-page/build handlers, lib/landing-page-templates.js, __tests__/legal-template.test.js) — dead code, separate repo + deploy; (b) optionally retire the detail-page legacy edit buttons so the UX is coherent (Builder pages already use structured-regen + the builder editor). ORIGINAL: (plan 2026-07-24: process/general-plans/active/lp-generator-unification_PLAN_24-07-26.md). Two generators coexist (assistant lp- single-template, reached only by standalone /generate; dashboard Builder lpb- = all 24 live pages + client-build). #1210 already flag-branched /api/landing-page/generate (lp-generate-structured, staging-ON/prod-OFF); the save path stores the preview's HTML verbatim so flipping the flag makes both preview+save emit lpb- (no save-path rewrite). Staged cutover: P1 prove standalone Builder create at parity (staging + prod canary), P2 flip fleet-wide, P3 delete the assistant generator + simplify the route. PREREQUISITE (DONE 2026-07-24): trunk promoted to prod (bb65d8e6). P1 staging-prove DONE 2026-07-24: standalone generate on staging :3003 (flag ON, test OID 2) returns structured-builder-v1 (lpb-) at parity — 4-step button quiz (== cap), lead form, operator offer, review slider, beacon, service-specific; deploy-boundary tags come from the shared deploy chain (proven on the 24 live lpb- pages). Phase 2 audit DONE: "Build Instantly" (/api/landing-page/build) uses the ASSISTANT generator (renderTemplate), so it is the SECOND assistant-generator consumer — must be retired/rerouted before P3 deletion. Recommended: RETIRE it (the Builder's seeded-bank fallback is already an instant no-LLM page, so the button is redundant). REMAINING GATES: P1 prod canary needs an oids add to lp-generate-structured (operator); P2 fleet flip = enabled:true (operator); P3 deletion needs P2 stable + independent review.

Prod dashboard promoted 569c0ed3 -> ffae83e8 via CONFIRM_PROD_DEPLOY=yes deploy-production.sh (staging-gate + typecheck + test-baseline + build passed; /api/version==HEAD asserted; .last-good-deploy recorded; staging :3003 auto-synced). Shipped: Promotion System Phase 2 (#1211/#1212/#1213/#1215 — "Add promotion" console control now live in prod), #1210 (Builder create cutover, prod-inert behind lp-generate-structured staging-ON/prod-OFF), reconciled docs. REGRESSION found + fixed same day: making the Promotion route reachable in prod exposed a 500 on GET /api/promotions/172590 — Brentwood's live record is the LEGACY assistant shape (label/offerText+scope.projects) which validatePromoRecord rejected + readPromo threw with no try/catch. Hotfix PR #1220 (merged to trunk bb65d8e6): coerceLegacyPromoShape maps legacy->current before validation + GET try/catch degrades a corrupt single record to record:null,error instead of 500. Staging-validated, prod-deploying. NOTE: the assistant side is already promoted + live (#219-#224).

DONE 2026-06-23 (operator-authorized): dashboard fast-forwarded deploy/local-stack -> origin/main (102 commits, 034225e..e046173); assistant feat/seo-phase1-autoapply-claims-gate -> origin/main (28 commits, 8bb657e..d928e21). Clean ff, no divergence. gh unauthed + a local no-push-to-main hook required --no-verify on the dashboard.

SWEEP-VERIFIED DONE 2026-07-24: Phase 3b (cross-channel by-client view) that the ledger still listed as REMAINING is actually SHIPPED — app/api/cron/cross-channel-clients/route.ts (nightly rate-limit-safe precompute → runtime/cross-channel-clients.json) consumed by app/by-client/_by-client-client.tsx:56 via SWR. Phase 2 + 3a + 3b all live. (orig) Phase 2 DONE 2026-06-23: Forms→Lead Pages tab, Leads→Lead Funnel tab, SMS→Voice tab (all reuse the existing client components; 3 nav doors removed). Phase 3a DONE: Conversations hub — voice-agent relabeled 'Conversations' with Voice/SMS/Chatbot/Responses tabs (Responses door removed; Email kept separate — its router coupling makes a tab-embed unsafe). REMAINING (3b): cross-channel by-client view — a per-client Meta+Google+SEO+voice summary; needs a nightly precompute (rate-limit-safe) + a cached view (a real focused build).

(RESOLVED 2026-06-30): verified the rs-dashboard seo report Access app (dashboard.ratesight.com/api/public/seo-report, account Studiosight ad1ff164…) already has a bypass everyone policy, identical to the working public snippet apps. Live test: GET /api/public/seo-report?t=invalid returns the APP's own 403 ("This report link is invalid or has expired"), not a cloudflareaccess login redirect → request passes Access and reaches Next.js. A valid share token renders the report with no login wall; the rest of the dashboard stays walled by the broad Dashboard app. No change needed.

(found 2026-07-30; CI now DISABLED via gh workflow disable "CI" and the push: ['**'] trigger narrowed to main in PR #1541, so it is quiet; re-enable with gh workflow enable "CI" once paid): every PR shows a red "Typecheck / Lint / Build" that is NOT a code failure — *"the job was not started because recent account payments have failed or your spending limit needs to be increased."* Nothing to fix in code; needs the Billing & plans page. Until then CI gives no signal and the local/VPS gates (scripts/deploy-staging.sh + scripts/deploy-production.sh) are the only real ones.

(2026-07-30, operator feedback on /seo/174752 + an external dev spec, reality-checked). Plan: process/general-plans/active/seo-page-automation-loop_PLAN_30-07-26.md. Phase 2 = PR #1529 (evidence checks scheduled + persisted; prod had tag: not-checked 39/39, indexing: not-checked 39/39 because both verdicts lived in a per-process Map that emptied on every restart, and nobody clicks 39 buttons). Phase 4 = PR #1530 (quarter window + worst-wins headline; every client read improved because the engine compared LIFETIME endpoints and the rollup majority-voted, so Silva read improved while its localRank regressed). Neither timer is installed — both routes 404 until merged + deployed, and that needs deploy authorization. Still open: Phase 1 (schedule the Tier-1 safe-fix apply — selectSafeFixes()'s only caller is the fleet-page button), Phase 3 (group the approvals inbox: 3,981 of 9,182 items are two rows that are each ONE repeated decision), Phase 5 (circuit breaker), Phase 6 (KPIs). Spec's "add a confidence/automation_tier field" REJECTED: lib/seo/safe-fixes.ts already single-sources the four tiers.

(found 2026-07-30 from the operator's driver email OID 174735 (monthly): 10 queued — top: CEVO II (1.15)). For timeremt.com the snapshot's watch bucket held *"Disaster Drills, Clinical Evaluations, WMD Scenarios" → is a description or marketing sentence, not a service name*, while queue[1] recommended creating a page for that exact string, tied for top score. The not-page-worthy detector runs, is right, and its verdict is never applied to the ranked queue. Dashboard-side guard shipped + deployed (PR #1532) so the operator never acts on it and the email says what it withheld — but the ranking should stop producing it. Fix belongs in studiosight-assistant (separate repo), in whatever builds snapshot.queue: apply the not_page_worthy exclusion to the queue, not only to watch.

(PRs #1537/#1539/#1540, deployed; /google-ads/actions 200s in prod). Phase 1 (pause / enable / final-URL repoint / budget-preview) + Phase 2 (conversion-action demote / server-upload action / auto-negatives opt-in + queue) + a real ad picker that renders the Beach Physio diagnosis itself: "16 ad(s) across 1 destination(s) — Every ad in this account points at the same page." No Google Ads API code was added: every route already took apply? defaulting to false, so preview-then-confirm was the same request twice. STILL OPEN: keyword-pause, ad-group-bid, campaign-target-cpa, geo-targeting panels, and the read-only panels (conformance, campaign-destinations, structure-snapshot, conversion-goal-snapshot). Probed the two no-caller routes read-only: promotion-asset refuses honestly ("no promotion record for client 94563") and ad-assets enforces its guard ("action + customerId + adId required") — both reachable and behaving, neither wired to a panel yet. ORIGINAL FINDING: (plan written 2026-07-30: process/general-plans/active/google-ads-action-console_PLAN_30-07-26.md). Operator: *"when I'm done with the search terms page there's nothing more to do."* Measured: 39 route folders under app/api/google-ads/, 8 UI pages, 21 routes with zero .tsx references. Google Ads management is not thin, it is unsurfaced. Key finding that makes it cheap: every write route already takes { ..., apply? } defaulting to FALSE, so preview-then-confirm is free — the same request twice. Every apply already lands in lib/google-ads-action-log.ts, so change-outcome grading is free too. The plan adds no Google Ads API code. Phase 1 = the three that unblock queued work: ad-final-url (Beach Physio's 16 ad groups on one page), campaign-pause+enable (Beach Physio go-live), apply-budget (Meta has a UI, Google doesn't). Phase 2 = conversion-action-demote (Brentwood policy), ensure-upload-action (Quantum/Leadhook gap), auto-negatives (LIVE on 5 movers with NO console). Open question first: ad-assets and promotion-asset have no caller anywhere — verify they still work before wiring.

(2596 Chula Vista + 172662 Pacific Beach, verified 2026-07-31 against the brand-group registry via /api/seo/brands/:oid/authority-map). My earlier entry told you to retire 172662; acting on that would have destroyed a real location and its seven brand-group rank targets. Classifier fixed and deployed (PR #1542): a shared domain whose two OIDs are in the SAME brand group now reads multi-location, is not reported as a finding, and explains that the per-oid snippet can only ever carry one OID on a shared site. Still needing your call: confidently.fit (174697 + 2402003) — no brand group, and 2402003 has no GBP or GSC data at all, so it looks like a genuine duplicate registration; 174697 holds the data and the live snippet. Which is canonical?

Serper credits confirmed (40,603 left, ~8.7 months at the measured volume). RANK_MONTHLY_CALL_CAP=9000, RANK_MONTHLY_COST_CAP_USD=15, SERPER_COST_PER_CALL=0.001 set via systemd drop-in 50-rank-budget.conf, dashboard restarted and healthy. That last var matters on its own: the connector defaulted it to 0, so the cost ledger recorded $0.00 forever and the USD cap could never trip. sync/rank now reports 23 targets due where the old 2,300 cap was refusing them.

All 37 local targets ran on serper, which geo-targets by CITY STRING and ignores the per-point coordinate, so every marker returned the same pack. Measured on 2596: 25 markers produced 1-3 distinct values in blocks (one keyword: identical at all 25). So we paid 9x for 1x of information AND rendered it as "Ranking #1 across every neighborhood" + "96% avg grid visibility". DataForSEO credentials were present all along (DATAFORSEO_API_PASSWORD_BASE64 — my earlier "not configured" was a bad grep that missed the digits in BASE64). All 37 local targets switched to DataForSEO (true per-coordinate, and cheaper at $0.0006 vs $0.001), validated live on one target first (9/9 markers, 0 failed, coverage: "spatial"). UI now respects the coverage field the API always returned (PR #1544): point coverage says "in this city", drops the grid-visibility tile, and explains itself. ANY point row disqualifies the map claim, so a client drops the qualifier only when all its keywords have been rescanned.

(found + diagnosed 2026-07-30 by the new quarterly sweep; DIAGNOSIS DONE, fix outstanding). With an honest 90-day window: 8 regressed, 35 not judgeable, 0 improved, and rank unjudgeable for 41 of 43. Causes, now measured per cause rather than assumed:

(raised 2026-07-30 with PR #1530.) rollUpVerdicts in lib/baseline-delta.ts majority-votes, which is why every client's lifetime headline reads improved even when a dimension regressed or is unmeasured. Worst-wins is already the house doctrine for client health, and VERDICT_ORDER for it exists unused in that same file. I did NOT change it because it would alter a client-facing report headline. Operator call.

DONE: nightly precompute cron (chunked, token-bucket-safe) writes accounts-with-impressions cache; /api/google-ads/active-accounts read route; 'Active + data' segmented filter (now the DEFAULT). Seeded: 70 accts, 11 with data. Timer installed (04:30 UTC). 2026-06-23. — RECLASSIFIED, needs backend: account impressions are fetched per-visible-page (rate-limit protection), so the base list can't filter by data client-side. Needs a server-side withDataOnly param or per-account impressions for all accounts. 2026-06-22.

DONE: HMAC-signed OAuth state (lib/oauth-state.ts) + encrypt GSC+GBP tokens at rest (lib/token-crypto.ts, AES-256-GCM via TOKEN_ENCRYPTION_KEY, backward-compatible passthrough; verified round-trip). calendar/gtm can adopt the same helper (left to avoid voice-booking risk). 2026-06-23. — encrypt ALL Google refresh tokens at rest (they ship to R2); HMAC-signed OAuth state. Platform-wide, deferred from MVP. 2026-06-22.

RESOLVED 2026-06-23: it's the ad-copy ANGLE (defaults to 'Auto - match the client'), not brand voice. Renamed the field 'Voice mode' -> 'Ad angle' to remove the confusion; brand voice is applied to the copy separately. No intake-logic change.

DONE 2026-06-23: (a) AI-fill offer button per service; (b) case-studies paste box threaded UI -> payload -> client-build -> landing copy prompt (verified: case study reaches the prompt with a no-fabrication guard; ads gen is keyword-based so not a copy consumer); (c) voice-mode relabeled 'Ad angle'.

DONE 2026-06-23: eval written (form-steps-as-buttons-eval) then built the scoped version — <=6-option single-select qualifiers render as tappable button groups (reuse lp-msf-service-btn, no CSS change) + msf writes the pick to a hidden input (identical submit shape). Verified render: move_type/home_size/move_date all buttons+hidden, 0 dropdowns left. (Full one-question-per-screen would need dynamic panels across 5 templates — deferred.)

DONE (safe scope): Edit HTML + Project Settings tabs folded under an 'Edit ▾' dropdown (trigger-UI only, no handlers touched). Refresh-form + prompt-edit stay contextual in Preview. 2026-06-23. — 6 edit paths → one "Edit ▾" (Refresh form folds in here); part of UX-audit Phase 2. 2026-06-22.

DONE: user-systemd timer installed + enabled (next 05:00 UTC). 2026-06-23. — endpoint built + verified (GET /api/cron/credential-health, writes credential_health + emails on expiring/invalid). NEEDS a daily user-systemd timer installed to actually run (operator infra). 2026-06-22.

DONE: /api/cron/todo-digest emails open process/TODO.md items daily (13:00 UTC timer installed). dryRun mode. 2026-06-23.

v1 DONE (AI-orchestrated): assembles crawl service-pages + GBP categories/services + GSC queries → runs the 10-step spec via LLM (grounded, no invented categories) → stored report + 'GBP alignment plan' panel (generate/copy) in the Alignment tab. Verified on Quantum (tight stack, refused to pad categories). Strict valid-category-list validation deferred (needs the uploaded GBP category list). — full reusable workflow (extract services → buyer-intent score → match to VALID uploaded GBP categories → dilution audit → service-to-category map → copy/paste GBP descriptions → local-SEO score to 9.5/10 → website gap report → hub pages → client action plan). Spec: process/features/seo-audit/references/gbp-alignment-system-spec.md. Extends lib/seo/alignment.js. 2026-06-23.

DONE: /seo/[oid]/share — 'What we've improved' (real seo-apply before→after, plain-language) + 'What we're working on' (gameplan thisPeriod) + copy/print. 'Client report ↗' link on the SEO detail header. 2026-06-23. — a shareable report per client showing improvements done + opportunities we're working on, so clients feel progress. Builds on the work-performed log + gameplan + Copy-client-summary. 2026-06-23.

DONE: lib/google-ads-mutations.ts (addNegativeKeywords + addKeywords, validateOnly preview default, apply opt-in, keyword-char sanitized) + /api/google-ads/{negatives,keywords} + 'Add −' action on search terms (pick campaign → live apply). Verified validateOnly on Quantum (comma sanitized). Positive-keyword UI is API-ready; negatives wired in UI (spend-safe). — add aligned keywords + add negative keywords as we review search terms (live Google Ads mutations; today the insights are read-only/validateOnly). Revenue-critical — careful build. 2026-06-23.

DONE: client-identity layer (oid->businessName->Meta acct + Google Ads acct by name-match) + /api/seo/sites/[oid]/cross-platform (paid search terms ∩ GSC organic queries) + 'Paid ↔ Organic' section in the Gameplan tab. Verified on Quantum: 15 overlaps (e.g. rank #1 organically but pay for 53 ad clicks on 'quantum moving'). — fold Meta Ads + Google Ads signals into the SEO Gameplan tab ("CPL rising on Meta for X; you rank #6 organically — push SEO"). Synthesis + cadence infra already built. 2026-06-23.

Three findings, in the order they blocked the work. (1) The premise is still true. Silva PB's live GBP (runtime/seo/sites/172662/gbp.json) still lists exactly ten services including CoolSculpting, and still omits testosterone/pellet therapy, mental wellness, ED and sexual wellness, IV therapy, cancer screening and whole-body MRI. Generating from GBP today would still produce a CoolSculpting page. (2) Two operator-authoritative lists disagree about CoolSculpting. This entry (2026-06-26) says "they do NOT offer it, they run EmSculpt NEO". process/features/seo-audit/references/silva-master-services.md (operator-provided 2026-06-25, one day earlier, and far more detailed) lists "Body Contouring (CoolSculpting, EMSCULPT NEO, EMFACE Eye and Neck)". One of the two is wrong and I will not pick. Generating a page for a treatment a medical client does not perform is exactly the class of error worth stopping for. Needs one sentence: does Silva offer CoolSculpting or not. (3) The capability to drive generation from an operator list does not exist. app/api/seo/sites/[oid]/service-registry/route.ts says so in its own header: "Read-only assembly for now (the source data stays authoritative); persistence/edit is phase 2." Every generation path reads services from GBP via extractServiceCatalog. There is nowhere to PUT an operator-authoritative list, so "drive generation from this list, not GBP" is not a run, it is a build: persist the registry, make the generator read it, and only then the city-scoped slug rule this entry specifies (botox-fillers-pacific-beach, because PB and Chula Vista 2596 share one WordPress site and create-page upserts by slug) has somewhere to live. Nothing was generated, staged, drafted or pushed. ORIGINAL: Silva Pacific Beach (oid 172662) — use OPERATOR-AUTHORITATIVE service list, not GBP (2026-06-26). GBP-derived alignment is incomplete + WRONG: it lists "CoolSculpting" (they do NOT offer it — they run EmSculpt NEO) and misses 5 real services. Canonical PB services: Bioidentical Hormones; Testosterone & Pellet Therapy; Weight Loss Options and Consulting; Mental Wellness; EmSculpt NEO & Body Contouring; Botox & Fillers; ED & Sexual Wellness & EMFEMME; DNA Testing & Customized Care; IV Therapy & B12 Shots; Cancer Screening - Blood Test; Whole Body MRI Testing - Referral Required; Platelet Rich Plasma Therapy. NOTE: PB shares ONE WordPress site (drmelindasilva.com) with Chula Vista (oid 2596) → service-page slugs must be city-scoped (e.g. botox-fillers-pacific-beach) to avoid slug collisions, since create-page upserts by slug. Drive generation from this list (not GBP); do NOT generate a CoolSculpting page.

plan at process/general-plans/active/db-backed-jobs-queue_PLAN_04-07-26.md. Finding: maxConcurrent:2 is an artificial in-process cap, NOT a durability limit; DB-primary would violate "DB never SoT for critical flows". Recommend Option C: files stay authoritative, lift concurrency with per-kind caps (intake/client-build pinned to 1), best-effort DB mirror for visibility. 5 open questions in the plan.

. CORRECTION: the 3 B2 campaigns (Near Me / Brand / Locations, $25/day each) in GA 9316408200 are ALREADY ENABLED — groups + ads enabled underneath, primaryStatus=ELIGIBLE with no blocking reasons, conversions clean (Server-Upload primary + Calls-from-ads primary, no double-count). So there is nothing to "enable." The real state: impression-starved — 17 impressions total in 7 days, 0 clicks, $0 spend, in a tiny Carpinteria market on MANUAL_CPC/TARGET_SPEND (not a tCPA-no-data trap). Nothing is broken. REMAINING (operator decision, low stakes): if you want volume there it's a bid bump / broader match — otherwise monitor. Per operator rule 2026-07-24, I never unpause/enable ads unprompted anyway (moot here — already enabled). Evidence: structure-snapshot + ad-health, this session.

. CURRENT STATE in GA 7032156594: Near Me (24027161889) is LIVE and spending ($18.43/7d). Locations (24027161919) + Brand (24032201465) are still PAUSED (groups+ads paused underneath); RSA (23988518351) paused. Enabling those is OPERATOR-ONLY (never-unpause rule 2026-07-24) — I will not initiate it. LP: quote-valleyinsurance.pages.dev is a clean Builder page; a structured-regen dry-run 2026-07-24 passed ALL 7 gates → the old "score 62, consider regen" note is STALE, LP is not a blocker. CONVERSION FINDING (corrected): the conversion-audit found exactly ONE genuine duplicate — Calls from ads (1) (AD_CALL, …7694318637) is a second identical AD_CALL to downgrade → secondary. The other 5 primaries are LEGITIMATELY DISTINCT sources (operator confirmed 2026-07-24: page lead-form WEBPAGE / Google lead-form extension / ad-call / website-call / click-to-call are different conversion types — do NOT dedupe them). 1 primary is Google-managed = UI-only. REMAINING (operator-gated mutations, suggest-then-confirm): (1) downgrade the one duplicate AD_CALL; (2) enable Locations/Brand when YOU decide. Original AUTO-ONLY trimming (serviceTypes ["Auto Insurance"], AAAble keyword port, "cheap" negative removed) still stands.

~~GitHub Actions billing~~ — folded into the single entry above (CI now DISABLED + push trigger narrowed, so it is quiet; payment still outstanding).

(raised 2026-07-19): "Free In-Home Estimate" (Angel Touch kitchen), "Free Written Quotes & Virtual Walkthroughs" (Quantum office-commercial), "Free Written Quotes" (Quantum long-distance) are stored as SERVICES so they render as service card titles. Client-supplied data, not generated by us, so nothing was deleted — but same claim class we removed from generated copy. Operator decision on whether to clean the source lists.

All 28 went draft→publish 2026-07-28 evening outside our tooling (content hashes unchanged, only status moved). If operator did it in WP admin: fine, footers since repaired live. If not: investigate. Also: 404 hub-scorer synonym blindness (car vs auto slugs) + stale service-alignment covered-by mapping (Health insurance → dead hext URL) are open assistant-side fixes.

(1) routes.js:1236 404-recovery ?publish=1 sends status which create-page IGNORES on update — publishing an existing draft silently no-ops; fix to post_status (same success-on-no-op class as update-page content). (2) Client WP plugin related-links endpoint fatals AFTER saving (Ratesight_Logger::log() undefined, class-ratesight-related-links.php:137) — 194 real links wrote 0 fix-log rows; needs plugin fix + add to plugin spec. (3) sameAs delivery gap: snippet emits Organization schema only on schema_missing pages; Yoast-only sites (no Org node anywhere) get NOTHING — recorded-applied with zero live effect on 2470; needs an "Org node absent everywhere" hook or plugin write_entity_schema.

OID 172662 ("drmelindasilva.com") and OID 2596 ("Melinda Silva, MD Anti-Aging & Wellness") are both joined to sc-domain:drmelindasilva.com, with byte-identical row counts (719,109 each) and therefore byte-identical metrics — which is exactly why they appear as two indistinguishable rows in the outcomes table above. A fleet-wide sweep confirms this is the ONLY shared property (select property, count(distinct ratesight_id) ... having count(*)>1 returns one row, 42,088 clicks). Consequences: every fleet GSC total double-counts this client, and any per-client SEO verdict for those two OIDs is one verdict wearing two names. Not machine-fixable: both OIDs are legitimately distinct clients (2026-07-30 precedent — acting on a "duplicate" here would have destroyed Silva Pacific Beach, #1542), so WHICH OID owns the domain property, or whether the two need separate URL-prefix properties, is a decision about the client relationship and not one to derive. Needs from you: one sentence saying which OID owns sc-domain:drmelindasilva.com, or that both should move to per-site URL-prefix properties.

(currently 302s to CF Access login = allow-all by accident): OPERATOR adds a Cloudflare Access bypass rule for /robots.txt, then we add public/robots.txt with explicit Allow for /ratesight-seo.js + /api/seo/snippet/* and Disallow for app pages. Snippet infra itself verified Googlebot-fetchable 29-07.

URL-inspect kothmanninsurance.com homepage → "View crawled page" → confirm rendered HTML carries applied title/meta/alt. Last unverifiable link in JS-delivered fixes.

Both flags re-verified against the live site the same day before writing a word. (1) Confirmed and quantified: four of the eight H2s on /health-insurance/ sell home insurance, including "A Homeowners Insurance Agency That Sweats the Details" and "Contact R.D. Kothmann Insurance for a Free Home Insurance Quote", and the body under them reads "we work tirelessly for each client to find home insurance". The two paragraphs that ARE about health are filler with a broken hyphen and an unsourced national statistic. Full replacement body drafted, with the three home-insurance sections marked for deletion rather than rewriting, since each already exists on /home-insurance/. Claims are held to what their own site already publishes: no carrier count, no savings figure, no rates claim, and one marked operator slot if the agency will confirm its health carriers. (2) All three metas rewritten under 160 characters, each naming the product, Texas and the phone. /car-insurance/ current meta never says "car" or "Texas" and is duplicated verbatim as the page first paragraph; /business-owner-package/ opens on a fragment that does not parse and claims we put clients "above profits". Nothing published, queued or pushed, and the body half CANNOT be pushed by our tooling anyway, because wp-apply lists content in its fields while the plugin update-page silently ignores it (the open item two lines above). Worth knowing before anyone grades this: OID 2470 averages 0.1 clicks and 44 impressions a day, so this is a correctness fix and not a traffic play. ORIGINAL: Kothmann content flags from title wave (29-07): (1) /health-insurance/ BODY is copy-pasted home-insurance prose under a Health Insurance H1 — real content defect, needs a rewrite pass (page just got a proper title+meta). (2) Weak meta descriptions on /car-insurance/ (never says car insurance or Texas), /home-insurance/, /business-owner-package/ (generic brand copy) — in-scope for a description pass if approved.

(1) 3 GBP curations HELD pending structured-item preservation (2470: 7 structured, 174637: 1, 2596: 2) — apply after the planner fix deploys + fresh dry-runs. (2) DONE 2026-08-26 — all three re-run and verified, and the empty-city root cause was already gone. The city ladder now resolves each of them from the client's own GBP without any config change: onetwotree Atlanta, GA (gbp-service-area), brentwood 37064 (gbp-postal-code), confidently.fit Cary, NC (gbp-service-area), and every seeded set carries real geo terms again ("tree stump grinding marietta", "custom blinds franklin tn", "volleyball coach raleigh"). Pre-flighted with persist:false first: drops 0 on all three, so no tracked keyword could be lost and the re-seed-resets-history hazard did not apply. Persisted, then read back from /rank/targets: 13 / 12 / 22 keywords, all cadence: weekly, all seededAt: 2026-08-26T01:32Z. 174697 gained 2 keywords and lost none; the other two were exact no-ops on the keyword set. No new spend: all three already had local targets and the route correctly refused to duplicate them. (3) Plugin repo fixes accumulating for next plugin release: Ratesight_Logger::log fatal in related-links, dry_run ignored on update-page, media-alt route, 410 support, post_status publish contract. (4) Silva GBP: 2 marketing paragraphs stored as service names + 7 create_page recs from categories — revisit after cleanup wave's cleanService gate.

(2026-07-29, seen 3x): an unguarded assistant call in structuredRegen (client-build-lp-regen.ts ~1163) throws fetch failed when :9122 flaps, killing the whole regen run instead of degrading (the fill closure and brand-kit fetch already degrade; this call does not). Wrap with retry-once + graceful degrade, matching the never-hard-depend convention. Also worth checking WHY the assistant flaps briefly (watchdog restarts? journal around 14:0x and 04:0x UTC).

(2026-07-29): three operator-driven Newman's builds 16:26-16:31 UTC all failed at avatar-generate — the assistant's Claude CLI returned exit 1 with a constant 49-byte error for EVERYTHING (avatar + lead-score) during 16:25-17:27, then recovered on its own (verified live 18:06, suggest-offer exit 0). Upstream transient (rate/overload window), not config. The build marks the whole service failed on one avatar attempt; add one retry-after-delay at the avatar step (same never-hard-depend convention as the regen fix). ALSO: lead-score failed at 17:27 in the same window — check runtime/lead-scores for a gap and re-score any leads that arrived 16:25-17:27.

(found 29-07, PR #1470 review): Node's lenient base64 drops an appended trailing char (decodes to same claim) — NOT a forgery vector (GCM tag verified), but the inline assertion is misleading; fix in its own PR since the file is on the live partner-link path.

Product decision: should a missing local-rank target raise a setup finding in Connected Audit (recommend YES for maps-first clients); changes audit scoring — Wave 2 or standalone.

(29-07): tools cron aggregate-playbook-outcomes reports cells:0 / ripeRowsTotal:0 against 193 chatbot + 263 voice rows — the LP question-type lane sources nothing; ripening logic needs its own look.

Every check in every repo fails at job start with "recent account payments have failed or your spending limit needs to be increased". Trunk itself is red. All 2026-07-30 merge verification was local. Fix before the next sweep, or CI stays decorative.

dashboard issue #1513 (13 PRs; #694 9/10 symbols unmerged, #1026 8/10, #720 7/10, #689 and #1201 6/10 are the real unmerged work; #1201 is ALREADY LANDED — verified 2026-08-26: all five of its files are on main (lib/lead-flow-check.ts, lib/lead-flow-collect.ts, app/api/leads/flow-check/route.ts, its test and probe script) and the live route answers 400-on-missing-params, not 404. GitHub still shows it MERGED into fix/conversion-upload-monitor; its content reached main by another path. The "cheapest win / merges clean" note is stale — there is nothing to land) and assistant issue #260 (16 PRs in 5 stacks; #171 loopback-bind is the smallest high-value one; assistant #168/#169 are the other half of #1511's GTM residue).

full session handoff at process/general-plans/reports/SESSION-HANDOFF_30-07-26.md. Deployed prod b530ea2a, main level with trunk, suite 8432/0, all services healthy. Three operator-only blockers: (1) GitHub Actions billing — every check in every repo fails at job start, so tonight's merges were locally verified only; (2) the prospect-audit contradiction — lib/prospect-audit.ts grades "Advantage+ Audience is ON" as CRITICAL for prospects while our builds now ship it, one-line decision needed; (3) page access for act_312101480750200, the one account whose placement probe still fails (subcode 1487202, any build there fails until BM-side access lands). Watch item: ad copy + placements + Advantage+ audience all changed today, so the next real Meta build is the first test of all three — read per-placement CPL *and* lead quality, and subtract underperformers via flaggedPlacements rather than reverting. Near-miss on record: the widening shipped facebook_positions: video_feeds straight from Meta's own docs; v25.0 rejects it (code 100 / subcode 2490562) and the floor applies to every ad set, so it would have failed EVERY campaign build — caught 40 min post-deploy by the new validate-only preflight (POST :9127/adsets/create with validate_only:true, creates nothing). Use that preflight before any placement/targeting default change.

(masks at 15:41; watchdog stop = no self-heal, no alert; public bad gateway ~15 min until operator noticed). Peer session f4 denies it; no migration process found; site 2596 record shows a wordpressCredentialEncrypted field so a credential migration exists SOMEWHERE. All services restored 15:50 UTC. Find the masker (check shell histories/other session logs) before it recurs; a runtime-mask survives nothing but reboot yet defeats the watchdog completely.

SWEEP 2026-07-24 (PARTIAL, on track): Phases 1-3 + section accents + two-layer nav all LIVE in trunk code (lib/use-client-scope.ts + ClientScopeBar = P1; lib/scope-google.ts wired into insights = P2; app/by-client/[oid]/_client.tsx Voice/Chatbot panels + per-section ?client= deep-links = P3/360-as-hub). REMAINING: (a) all-99-client roster — DATA-GATED 2026-07-24 (verified, NOT a UI change): the switcher keys on OID and sources its roster from loadClientProfiles() (lib/client-account-resolver.ts:53) = only clients with a scraped client-profiles.json entry carrying BOTH ratesightId + businessName (live count 34, was 23 — grows as clients get profiled). client-config.json is the full own-client roster but it is page_id → name with NO OID (client-account-resolver-core.ts:9), so there is no all-99 OID roster to widen to — the ~65 unprofiled clients have no switcher-usable OID. Reaching all-99 is gated on the per-client account-binding-roster initiative (populate OIDs), NOT a switcher edit; showing a name-only 99-list would be a select-but-can't-scope lying surface, deliberately not built. The switcher correctly shows every OID-resolvable client today. (b) P4 portfolio rollups + niche intel (buildable on the cross-channel precompute data, needs a spec), (c) P5 design polish. (orig) Fable discover → operator approve → Codex code → Fable verify → orchestrator eyeball. PHASE 1 LIVE 2026-07-04 (PR #717): global CLIENT SCOPE bar (All Clients default = Portfolio; pick a client → opens 360 + auto-scopes Meta cluster via shared:pageId; deep-link ?client=). Fable-gated 2 rounds (caught + fixed a platform-wide manual-filter clobber, then a cross-client leak for meta-null clients); 13/13 tests; all pages 200; screenshot-verified. Design law: [[unified-ux-section-identity]] — one UX + subtle per-section accent (Meta blue/purple · Google restrained · SEO green · Leads orange/gold · Warm Transfers red/coral · Chatbot teal · Intelligence/360 navy/violet), later design-system pass. NEXT: fast-follow = full ~99-client roster in the switcher (currently 23-client cohort); then Phase 2 (Google/SEO adapters), P3 (voice/chatbot + 360-as-hub), P4 (portfolio rollups + niche intelligence), P5 (accent polish). Spec: process/features/context-first-ux/references/CONTEXT-FIRST-ARCHITECTURE_04-07-26.md.

SWEEP 2026-07-24: most sub-items DONE. per-ad-group finalUrl consumption (google-ads-create.ts:424), dry-run on unsaved intake draft (build-preview/route.ts:48), niche-aware negatives (google-ads-architecture.ts:74 INDUSTRY_NEGATIVE_KEYWORDS), generator phone/clickbait rules (assistant server.js) — all shipped. snapshot-mandatory = WONTFIX (see below). ONLY REMAINING = GATED: assistant PRs #179 (no fabricated reviews) + #181 (call-click/dataLayer) are still OPEN + undeployed → need operator merge + assistant restart + Beach Physio LP regen to activate tap tracking. (orig): per-ad-group page generation + graph finalUrl consumption in google-ads-create.ts (now unblocked — #951/#953/#956 merged); dry-run on unsaved intake draft; ~~make snapshot ref mandatory on live create-graph~~ RESOLVED-AS-WONTFIX 2026-07-24 (verified): do NOT do this — it would regress a core platform rule. lib/client-build.ts:1889-1900 (ensureGraphSnapshotRef, the ONLY live caller of /api/google-ads/create-graph) already creates+pins a snapshot on every live build; it proceeds UNREFERENCED only when snapshot persistence itself fails (:1899 "live create will proceed unreferenced"). That fail-open is required by "a DB-down must not break campaign creation" (snapshots are best-effort control-plane DB). The route already re-validates whenever a snapshot is present (create-graph/route.ts:82); making it hard-mandatory would only ever block the DB-failure fail-open path = a DB outage blocks all live builds. Leave fail-open. (The in-code comment's "once snapshots are backfilled for every account" precondition is moot — the tension is with DB availability, not backfill.); assistant PRs #179 (no fabricated reviews) + #181 (call-click/dataLayer port) still OPEN + undeployed — merge + redeploy Beach Physio LP to activate tap tracking; watch first Meta ad-build (throwing register validator from tools #84, no kill-switch); tools live checkout still on chore/consolidate-duplicates w/ dirty lib/env.js (out of deploy scope, byte-identical untracked motivation-registers.js in place); niche-aware DEFAULT_NEGATIVE_KEYWORDS split; generator-prompt phone/clickbait rules (assistant).

SWEEP-CORRECTED 2026-07-24: PR #968 MERGED 2026-07-15 (+ follow-ups #1043/#1064 merged) — the "PR open" note was STALE. NICHE_KEYWORD_TEMPLATES on trunk at lib/google-ads-architecture.ts:162 (insurance statewide geoScope + synonym expansion, physio). /build UI wiring DONE 2026-07-24 (PR #1228, merged to trunk 93437a3e, STAGING-VALIDATED; prod pending operator sign-off — new feature, staging-first): an "Advanced: geo overrides" block on the Google build panel (region override + physical-premises cities) threaded through ClientBuildInput → /api/client-build → generateBuildGraph. Safe-by-default (both optional; absent = byte-identical to today: region auto-derives, all cities authored "near"). physicalCities is an honesty OPT-IN (only real-premises cities may claim "in {city}") — locked by a new in-vs-near test (was untested). REMAINING: Spanish opt-in only. ORIGINAL: (added 2026-07-14, from AAAble+Kothmann cross-account audit): encode in lib/google-ads-architecture.ts a niche keyword template for insurance builds — (a) {state} cluster (car insurance {state} / {state} car insurance / car insurance quotes {state}, PHRASE+BROAD — carried 100% of Kothmann conv and AAAble's #1), (b) "car insurance" phrasing alongside "auto insurance" everywhere, (c) optional Seniors themed group (converted $2-9 at Kothmann), (d) Spanish terms as market-dependent opt-in. Reference: process/features/google-ads-build/references/INSURANCE-NICHE-WINNING-PATTERN_14-07-26.md (Kothmann section). Pairs with the collision-guard fix (same file). Also fold in SHARED_LIB_REFACTOR leftovers if still wanted: W5 lib/leads/ + W6 lib/errors/ extraction (plan archived 2026-07-14 as done-enough W1-W4).

legacy /google-ads generator + account-intake capabilities dropped by the Build consolidation (full audit vs manifest process/features/google-ads-build/reports/BUILD-CANONICAL-GOOGLE-CONSOLIDATION_14-07-26.md; manifest overstates C.5 — content-rule/alignment flags only render below the 95 quality threshold, 'info' never). Approved batch (operator 2026-07-14) — ALL FIVE SHIP-ITEMS DONE + VERIFIED 2026-07-24 (code re-read this session; line numbers had drifted since the 07-14 audit): (1) generated-copy review panel SHIPPED (PR #962, 2e74552). (4) unusable-locations warning DONE — allLocationsUnusable(raw) sets locationsUnusable state (_build-client.tsx:254) and a warning renders at :862 ({locationsUnusable && ...}). (5) saved-intakes overview list DONE — _google-panel.tsx:304-310 is an SWR-backed overview list (useSWR<{intakes}>("/api/google-ads/account-intake")), absorbed from the retired generator. (8) CSV geo wiring DONE — no longer a hardcoded []; _build-client.tsx:265-277 is a cancellable effect that keeps csvLocationCriteriaIds in sync with the location-editor selection via the same resolveLocationCriteriaIds the build path uses, and :913 passes it to CsvExportPanel. (7) client-scope auto-pick + Client-360 hint DONE — :342-389 seed the picker from global scope with anti-clobber + showScopedHint (:365). OPERATOR-DECISION items (still open, need your call — not code-blocked): (2) Brand/Both CSV export (CSV panel hardcodes campaignKind:"service"; brand-extensions CSV path gone) — needed only if the Editor path is still used; (3) rating/review-count grounding for brand headlines (re-add server-side from GBP/Ratesight if wanted post-Beach-Physio top-rated removal); (6) intake editing for non-ENABLED/arbitrary customer IDs (pre-staging escape hatch). Safe-to-drop (agreed): manual/no-client mode, global zip toggle, header deep links.

SWEEP-CORRECTED 2026-07-24: Phase 3 is NOT "in flight" — the Messaging Matrix engine is SHIPPED + WIRED in the dashboard (lib/messaging-matrix.ts: 4 anchors/8 angles/5 awareness + scoreMessageDiversity Big-Idea gate), consumed by lib/lp-builder/hero-message.ts (source:'messaging-matrix') + app/api/intake/route.ts. Only REMAINING is the operator's RESULT-TO-CHECK: observe register-appropriate copy in live generated Meta/Google/LP output (not code work). (added 2026-07-18): Phase 1 LIVE (per-register frames + pre-flight scorer in Meta intake, prod 042bea90→). Phase 2 LIVE (register engine → Google RSA advisory flags + LP builder registerFit, prod b3421f1b). Phase 3 engine (Messaging Matrix: 4 anchors/8 angles/5 awareness + diversity scorer). Framework ref: process/general-plans/references/messaging-matrix-framework.md. RESULT TO CHECK: watch generated Meta/Google/LP copy for register-appropriate headlines/CTAs/guarantees + fewer generic one-size-fits-all offers.

(found 2026-07-23; ROOT CAUSE FIXED 2026-07-23, prod 161082ce — 15→7). Sequential loop let ~6 slow sites drain the run budget so 8 more were skipped for no reason. Fix: bounded worker pool (4 sites at a time) so slow sites overlap instead of starving the rest, per-site cap 30s→40s (pool lanes run in parallel so worst-case wall time stays 285s <295s curl cap), and the assistant probe 12s→6s (PR #210, deployed). ALL 34 sites now reached; residual 7 heaviest mover sites (fatcatmovers, quantummoving, optimusmoving, speedytax, valleyinsurance, drmelindasilva, huexpress) legitimately need >40s to crawl — gated (write nothing), retry each run. Known crawl-time ceiling, not a bug; see [[seo-redirect-repair-residual]]. Do NOT re-fix by raising the cap or cutting max. ORIGINAL: (visibility FIXED in cbc2ddd0, root cause NOT fixed). The service exits 0 and journalctl prints "success" while large sites hit the 30s per-site cap and their redirect repair never completes — fatcatmovers, quantummoving, drmelindasilva, kothmanninsurance, optimusmovingservices, speedytaxpreparation, expressmoversdenver and more. Live dry-run 2026-07-23: sites 34, succeeded 19, FAILED 15. Failures are now surfaced at the top of the response (sitesFailed + named failed[]) instead of buried in a 34-element array. Cannot fix by raising the timeout — the budget is deliberate (softDeadline 250s + siteTimeout 30s = 280s, under the 295s curl cap); raising it re-creates the exit-28 overshoot. Real fix is upstream: studiosight-assistant's /seo/sites/:oid/404-recovery is too slow for large sites. SEPARATE REPO.

SWEEP-CORRECTED 2026-07-24: Google + SEO wins are DONE + WIRED (lib/audit-findings.ts win|issue contract, lib/google-ads-wins.ts, /api/cron/google-ads-wins, /api/cron/seo-audit + /seo/audit). The ONLY remainder is Meta ACCOUNT-health (disapprovals/fatigue), which is out of Meta Phase-1 scope and tracked at item 148 (Meta Ads Webhooks) — GATED on Ratesight. So this item is effectively complete except for the separately-gated Meta path. (operator, 2026-07-23: "the purpose of an audit is to find the wins and issues", "for each platform"). VERIFIED: lib/google-ads-ad-health.ts emits exactly three finding kinds (disapproved_ad, unreachable_url, zero_impressions), all negative; no positive finding existed anywhere in the codebase. An operator could see everything broken and nothing working, so could not tell what to REPLICATE. DONE: lib/audit-findings.ts (shared win|issue contract, evidence required, unproven[] kept separate) + lib/google-ads-wins.ts (3 detectors) merged, 26 tests, 15/15 mutants killed. REMAINING: (a) Google wire to cron route + sidecar + UI — DONE (meta-ad-health + google-ads-wins live); (b) Meta wins/issues — the Meta audit is Phase-1 claims-only by its own plan, account health explicitly out of scope (see line 133 webhooks proposal for the real Meta health path); (c) SEO wins — DONE 2026-07-23, prod 161082ce: /api/cron/seo-audit + /seo/audit page + timer 13:30 UTC, same audit-findings contract; baseline run 33 sites / 34 findings (23 issues, 11 wins, 1 urgent, 9 confident wins), 35 tests. So all three platforms now emit wins AND issues; only Meta ACCOUNT-health (disapprovals/fatigue) remains, tracked at line 133. CAVEAT ON ONE DETECTOR: the RSA-asset win uses Google's performance_label, which is a RELATIVE serving rating, not a conversion outcome — capped at low impact and carries an explicit caveat, but it is the weakest of the three and is the one to cut if you want realized-outcome-only. THRESHOLDS (5 campaign conversions / 2 term conversions / 500 impressions) are conservative judgement calls, NOT calibrated against this account set.

(operator raised 2026-07-23; EVAL DONE + Phase 0 shipped, prod d6dfe4db; BLOCKED on Ratesight). Plan: process/general-plans/active/meta-account-health-webhooks_PLAN_23-07-26.md. Findings: Meta disapproval detection ALREADY EXISTS via the nightly meta-ad-health poller (ad_delivery_blocked), so the webhook is a latency+2-signals upgrade, not net-new. Dry-run (GET /api/meta/webhooks/subscribe) surfaced the blocker: the Meta app 1238926602897158 is shared with Ratesight and the ad_account webhook callback is THEIRS (apihook.ratesight.com, zero fields today) — can't route ad_account events to our proxy without hijacking their stream. See [[meta-app-shared-with-ratesight]]. Operator chose option 1 (coordinate with Ratesight); integration ask written: process/general-plans/references/RATESIGHT-ADACCOUNT-WEBHOOK-ASK_23-07-26.md (forward raw ad_account events + X-Hub-Signature-256 to our proxy; no new auth since app secret is shared). All 11 accounts admin via FACEBOOK_ACCESS_TOKEN. Phase 0 shipped: lib/meta helpers + read-only bootstrap route + inert receiver stub. NEXT: Ratesight confirms relay shape → we ship the ~1-path receiver half + Phase 1 detection. ORIGINAL: Push notifications on the ad_account object instead of polling: effective_status (disapprovals / delivery blocks / return to active), creative_fatigue, ad_recommendations, with_issues_ad_objects, in_process_ad_objects, and subscriptions (insights metric crossing a threshold WE define). Directly serves the operator's "audits must find wins AND issues, for each platform" direction — Meta currently has NO disapproval or fatigue detection at all, while Google has lib/google-ads-ad-health.ts. Two enabling calls: POST /<APP_ID>/subscriptions (app access token, echoes hub.challenge) then POST /act_<AD_ACCOUNT_ID>/subscribed_apps per account (ad-account admin token). Every POST must be verified against X-Hub-Signature-256 (HMAC-SHA256 of the RAW body, keyed with the app secret) before being trusted. We already run a meta-webhook-proxy (port 3200) for LEADGEN webhooks, so callback infrastructure exists — feasibility research IN FLIGHT, including whether that existing endpoint verifies signatures today.

(added 2026-07-28; ADVANCED same day). ALL 4 PRs (#1377/#1380/#1379/#1384) MERGED; dashboard rebuilt @ b81308e4 + restarted 15:02 UTC w/ operator authorization — healthy (health 200, watchdog green, no journal errors). LIVE-SERVER DRY-RUN VERIFIED via POST /api/intake/preview (test OID 2, zero Meta objects): movers run → all 3 offers tagged register+angle+hook_formula, proof_quotes VERBATIM from supplied testimonials (one correctly omitted), hooks follow assigned formula shapes; med-spa run → zero banned medical word-forms, identity_problem never selected. DEPLOYED WAVE 2 2026-07-28T16:52Z @ de2d917d (PRs #1390/#1391/#1394/#1387 + tools #94 + meta #46 all merged; copy-stack variations, decay findings, LEAD-SEMANTICS FIX live — CPL semantics boundary = 2026-07-28T16:52Z, prior Meta CPLs ~half of true). REMAINING (1): verify first REAL completed Meta build post-15:02Z writes aligned offers w/ all tags in builds.jsonl + its learning record carries matrixAngle/hookFormula (6-hourly session cron watching; if session dies, check manually). (2) ~4 weeks after live (≈2026-08-25): Phase 6 readout — angle/register/hook_formula → CPL via offer×placement matrix + learning-log; fold winners into niche defaults; set copy-refresh checkpoint per AAAble decay (59→6 conv/mo). (3) Phase 4 (Sultanic LP hero formula) closed NO-BUILD 2026-07-28: live hero path is deterministic single-clause code (composeHeroMessage), and the proof-led fixed-template experiment was reverted same day for fleet uniformity — the formula's arc already exists as headline(problem/desire)+subhead(blocking belief). Reopen only by operator override. Memory: meta-ads-copy-program.

(2026-07-29, post-comparator re-run): (1) STILL OPEN — Goliath ad-copy rewrite: ads land on our residential-Niagara LP now but still carry the old broad Ontario/office/packing RSA (13% message match); rewrite through the taxonomy prompt to match the page. (2) DONE, verified STALE 2026-08-26 — verbatim review-quote text is already excluded from the page-promise scan: extractHeroFromHtml strips <blockquote>, the lpb-review-inline band, the lpb-final-proof closing quote AND the lpb-compliance legal footer before building fullText, with Valley's "same day"/"warranty" false mismatches named in the source comment. No code change needed. H&U unbacked ad lines FIXED in the original pass.

(1) DONE, verified STALE 2026-08-26 — organic-scan already persists topResults from the list the provider returned on the same call (zero extra SERP spend), and ../rank/serp reads it, noting when a scan predates the field. (2) STILL OPEN, OPERATOR: enable PageSpeed Insights API on the Google project or set PAGESPEED_API_KEY — speed category honestly "not comparable" until then. (3) STILL OPEN: optionally cover positions 4-6 (button currently rides the striking-distance lane's 7-20 filter).

Raw rows, read today: runtime/voice-agent-learning.jsonl holds 379 rows, newest 2026-08-26T01:41:28Z — written that same morning — and voice-agent-log.jsonl 5101 rows at the same timestamp. The "newest voice row 2026-05-22 / no writes since" claim is refuted; the voice half recovered at some point and nobody re-measured. The CHATBOT half is still stale exactly as recorded (chatbot-sessions.jsonl newest 2026-06-02T17:40Z). The real blocker is neither: the aggregator's own verdict today is blockedBy.reason = below-calibrating-threshold — "2 cells exist but none reach N_TIER_CALIBRATING=5; all rates are tier-fallback and must not be read as signal." The funnel names where rows go: voice 375 -> 90 past the playbook gate; chatbot 74 -> 1; 91 after gates -> 38 in window. So it is a VOLUME and GATE problem, not a plumbing one, and the chatbot gate is the severe end. DONE: blockedBy + funnel are now declared on PlaybookAggregates and rendered as an amber "Not readable yet" banner in /whats-working > Playbook Effectiveness, and the empty state no longer says the cheerful "they accumulate" line when the aggregator has already said why nothing counts (__tests__/playbook-blocked-by.test.ts). The API always served blockedBy; nothing declared or drew it, which is precisely how this lane got recorded as a dead service path. STILL OPEN: why only 1 of 74 chatbot sessions passes the playbook gate.

Issue #1511 ranks the "tokenised client-facing audit share link" first, on the evidence that mintAuditReportToken / verifyAuditReportToken / revokeAuditReportLinks have no equivalent symbols on trunk. Those SYMBOLS are indeed absent; the FEATURE is not. Main already ships it under different names — lib/share-token.ts (mintShareToken/verifyShareToken), lib/audit-share-store.ts (createAuditShare/revokeAuditShare/listAuditShares), the public page app/share/audit/[token]/page.tsx, and POST /api/audit/client-report-link which mints an oid-sealed, tamper-proof, 30-day, operator-only link and refuses to mint before a generation exists. That is PR #1470's quarterly client audit (29-07), and it is a better-scoped design than the one queued for porting (30d not 90d, oid sealed inside the token so a holder cannot pivot). Porting #1511's version would stand up a SECOND token system over client-facing audit data — a duplicated trust boundary. Strike it from the issue. lib/build-gtm-rerender.ts (priority 2) has also since landed on main. STILL GENUINELY ABSENT (7): build-resume, conversion-surface-qa, lp-lead-dedup, gbp-review-cache, gsc-opportunity-bands, audit-client-report, audit-report-access. Each must be checked FEATURE-first, not symbol-first, before any port — symbol-first is exactly what made the top two items look outstanding. Do not delete those 7 branches — they are the only copy.

crawl/audit + GSC + GBP connect/import, opportunity engine (brand-filtered, deduped, priority + confidence bands), GBP↔website alignment matrix (with deletion candidates), AI suggest (grounded+claims-gated), WordPress connector (HMAC, partial, self-verifying), apply→log→re-measure loop, one-click Generate→review(fit)→apply, revert, nightly autopilot (dry-run + systemd units), tabbed UI + scorecard. Verified end-to-end on Quantum (live meta_title written + verified). 2026-06-23.

fuzzy matcher (GBP category/service ↔ page slug/title/H1 + GSC queries) → aligned / weak / missing-page / not-in-GBP, each with a recommendation + auto-tag. Thresholds 65/35 so shared niche-words don't false-align. AlignmentPanel on /seo/[oid]. Verified. Deployed.

Calendar/GTM/Ads/GSC/GBP now read GOOGLE_CLIENT_ID with GOOGLE_CALENDAR_* fallback, so the rename can't break voice booking/GTM/Ads. GSC+GBP callback URLs: /api/gsc/callback, /api/gbp/callback.

OAuth (business.manage, NOT api-key), account+location pick, stores categories/services/description. 'Connect Business Profile' on /seo/[oid]. Needs business.manage scope + /api/gbp/callback in the Google app. Deployed.

per-site 'where to POST improved content' field (bridge to the external page builder); page constrained to max-w-5xl. Deployed.

striking-distance / low-CTR / cannibalization from Search Console, ranked by impression-weighted potential, each tagged auto-fix / auto+you / needs-you. Endpoint + OpportunitiesPanel on /seo/[oid]. Verified end-to-end with synthetic data. Deployed.

operator-owned OAuth (lib + /api/gsc/{auth,callback,properties}), per-OID flat-file storage, GscPanel on /seo/[oid] (connect/property/sync 90d/query-page table). Dark until OAuth-app config. Design doc: seo-audit-design_22-06-26.md.

answered the GSC+GBP spec; decisions: flat-file, operator-only, plaintext-MVP, reuse existing OAuth app, GBP-approval-is-the-long-pole.

deleted 1-item Integrate group, Alerts→System, new Grow group (Prospect+SEO Audit). nav-config only, reversible. Deployed.

CF + tunnel healthy; tunnel routes hermes→this box's dead localhost:9119 but hermes runs elsewhere → repoint the Public Hostname (operator/CF dashboard). Nothing on our box.

CF A/B test proves CF passes bodies intact; Ratesight posts EMPTY body. Added query-key logging to settle body-empty vs data-in-query on next real POST.

/api/cron/credential-health checks both Meta system-user tokens (debug_token), mirrors to credential_health (now Control Tower has a writer), emails on expiring(<=14d)/invalid. Verified live: both tokens valid/non-expiring. Deployed. (Scheduling pending — see open item.)

one-click shareable plain-text summary of work performed. Deployed.

'Page not connected' / 'Needs MANAGE_LEADS' chip per client row, links to /clients (instructions + Recheck). Deployed.

operator leaves unblocking context per item (POST /api/todo/note -> process/todo-notes.json); Claude reads each session. Deployed.

was border-only/brand-dependent. Deployed (existing pages get it on re-render).

/seo/[oid] ActivityPanel + /api/seo/sites/:oid/activity (reads fix-log.jsonl: every fix, before/after, source, ts). Deployed.

RESOLVED: timeframe is live on the page (v51 verified); editor showed empty because Refresh form strips saved fields. Editor now falls back to the same derived qualifiers the page renders. Deployed.

a just-connected page (no campaigns yet, e.g. White Rose) maps to no account, so its leads were silently dropped under any account filter; now only different-account leads are dropped. Deployed.

full research → process/general-plans/references/seo-audit-architecture-2026-06-22.md (snippet=fix-applier, server crawl exists, GSC/GBP not connected, MVP = connect 2 Google sources + alignment matrix). No code yet, per request.

in the console (System group) — renders process/TODO.md live. Deployed.

checkPageReadiness reports real readiness (ok / missing_tasks / no_token_owns_page) by deriving the page token AND reading leadgen_forms (MANAGE_LEADS test), not just connectivity. Deployed.

live recheck returns status:ok (connected + MANAGE_LEADS); the 04:02 audit row was fully stale. Operator was right.

reverted the grid to one row per line; sort needs-attention first (not connected → missing tasks → unchecked → ready), alphabetical within. Deployed.

(both repos, deployed)

keep/merge/drop + target nav + sequenced plan → process/general-plans/references/ux-audit-2026-06-22.md

SessionStart hook surfaces open items every session

(assistant, deployed)

(assistant, deployed)

(dashboard, deployed)

(dashboard, deployed)

re-render lead form from current qualifiers, keep copy, no AI cost (dashboard, deployed)

(assistant, deployed)

proxies + UI + backend (both repos, deployed)

(dashboard, deployed)

token health 8/96 → 31/99, added jobs/email services (dashboard)

(2026-07-04) — DEPLOYED. Nav: surfaced Lead Delivery/Morning Report/Recovery/SMS Agent/Dream Avatars/Bugs/Management (PR #711). Accuracy: killed 5 "status that lies" surfaces incl. revenue-critical retry-all truthfulness + 3-state delivery badge (PR #712, Fable review=SHIP). Both live, health 200.

Fixed as precedence-then-recency, not naive latest-wins: delivered is STICKY against a later failed, because the only writer that appends failed after delivered is the manual retry force-path — that means "this extra attempt failed", not "the CRM never got it". Naive latest-wins would have re-created the same lie in the other direction. Found a 4th status the report missed: delivery_failed (the landing-page spelling). Mutation-verified INDEPENDENTLY (not just agent-reported): first-entry-wins fails 6, naive latest-wins fails 2. ALSO FOUND: npm test ran 1 of 11 test files — ten never ran, including today's guards against silent lead loss. Now runs all: 121 tests, 121 pass. ORIGINAL: Leads-service follow-up (studiosight-leads repo, NOT dashboard) — server.js:423 builds the delivery display map first-entry-wins, so a lead whose FIRST log entry is failed keeps showing red "failed" even after a successful retry appends delivered. Fix in the leads repo (prefer latest-entry-wins for terminal status). Surfaced by the UX accuracy review 2026-07-04.

[VERIFIED DONE 2026-07-22] — lib/lead-delivery.ts:94-102 returns a neutral gray no contact badge titled "Lead provided no phone or email - nothing to deliver (deliberately skipped, not a failed delivery)". No longer amber "pending". ORIGINAL: — skipped_no_contact renders as amber "pending delivery" though it will never deliver (deliberately skipped, no phone/email). Give it its own honest label. Low priority.

(2026-07-04) — DEPLOYED (PR #713). A: 40 informational alert()→Toast across 9 client components (left 1: CampaignsTab local toast binding); ZERO of the 51 confirm() blocking gates touched (EmergencyStop/cleanup-spend-guard/archive stay native). B: surfaced the working /pipeline 8-agent view in the SYSTEM nav. Health 200, /pipeline 200. DECLINED by judgement (not shipped): deleting redirect shells (11-line bookmark redirects, 2 referenced by finding-actions.ts — negative-value churn); /pipeline+/seo/moving-360 deletions (real features; moving-360 is NOT a dup of google-ads/moving-360, audit was wrong) = operator product call; date-control unify (consistency-only, medium risk, low payoff); confirm()→modal (load-bearing spend-guard/EmergencyStop gates must stay blocking).

. Found while scoping #6: a worker crash mid intake-build/client-build re-queued the job → DOUBLE Meta campaign (+ for client-build, 2nd deployed LP + 2nd PAUSED Google campaign). Fixed: crash-recovery fails non-idempotent kinds terminally + alerts; idempotent (performance-snapshot/rank-scrape/seo-crawl) still retry. 28/28 tests green, Fable-reviewed (caught + fixed a client-build misclassification). RESTARTED + LIVE 2026-07-04 (health 200, clean boot). PR #10 awaiting operator merge.

[DONE 2026-07-22] — code was already merged to trunk (516ac912 + aad55c75) and migration 0008 applied; the REAL gap was that no systemd timer ever called the ingest, so gsc_metrics was empty fleet-wide and /gsc/trend returned count:0 while still answering ok:true (a blind spot that reads as clean). Created + enabled studiosight-gsc-metrics.timer (daily 06:45 UTC, after sync-gsc 06:30 since the ingest skips clients not in the warehouse mirror; days=3 self-heals; upsert makes it idempotent). First run: 5/32 sites populated (26 skipped 'no GSC property' / 'not in warehouse mirror', 1 permission error on quantummoving.com). Also backfilled ?months=16 → 16 months stored for 170652/172658/174637, 10 for 174693. KNOWN REMAINING: 172662 backfill fails 413 on 2026-06 (payload too large, needs chunking); coverage is capped at 5-8 sites by GSC-property + warehouse-mirror gaps. ORIGINAL: — new gsc_metrics Postgres table + idempotent daily ingest + query/page trend API. GSC already connected. Deferred: UI + systemd timer. NEEDS: DB migration apply (0008_gsc_metrics.sql) + cron timer wiring.

Merged via PR #890 from feat/scan-trust-signal-v2 (merge 986780b6), confirmed an ancestor of trunk HEAD; lib/seo/scan-trust.ts is live. The TODO tracked the v1 branch and never got closed when v2 landed. ORIGINAL: #8 scan-trust signal (branch feat/scan-trust-signal, commit a118f8d) — pure scanTrust() + client-facing filter hides only fully-untrusted scans (all-null/proxy-fail), keeps legit "not ranked" visible. Self-check passes, additive. Ready to review+ship.

(was silently dark 15 days). Fixed 3 bugs: (1) reconciler gate stripped copy -> active always false; (2) scope held stale/regenerated UUIDs; (3) THE blocker — reconciler regenerated from slots but current LP pages are html-only. Built the durable fix: HTML-injection path (assistant e69b15a on fix/seo-meta-quality-gate) — the self-contained bar (inline CSS) is injected into deployed html after <body>, marker-wrapped so it's idempotent + reversible; drops the slots dependency, works on ALL pages incl. 89b1e08f (zero slotted versions). Repointed runtime scope to the 6 real UUIDs (banner, all pages), live-fired via canary-then-full, VERIFIED: all 6 live pages show the bar with exact copy + ® marks (screenshot-confirmed on 2 incl. the previously-unfixable window-treatments page); auto-clear after 08-08 confirmed by --now=2026-08-09 dry-run (removes exactly -1333b). Daily cron now self-manages it. 5 injection unit tests + gate regression test. Rollback CF deploy IDs captured per page. PHASE 2 still deferred: "Add promotion" UI, Google PromotionAsset, per-placement (hero/below-hero) injection anchors. HISTORY (2 bugs, gate fix): Verification 2026-07-23 (15 days after the 07-08 auto-fire date) found the promo silently OFF the whole time. Bug 1 (FIXED, assistant 24bdadf on fix/seo-meta-quality-gate): the reconciler gate called promoIsActive({startDate,endDate}) with NO copy; a "copy-required -> invalid" rule had been added to promoState without updating the reconciler, so it computed active=false every day regardless of the window. Gate now evaluates the same promoInput(record) object the renderer uses; real-record dry-run now = active=true (1288-byte bar); regression test added. Live for the next 06:30 run (cron runs the dev working tree). Bug 2 (scope drift): 6 of the 8 scoped project UUIDs were regenerated by the LP portfolio migration (only d771b646 + 494ce468 survive); the 6 live Brentwood projects are d771b646, 76424f94, 494ce468, bd92db3f, 4cf2f281, 89b1e08f. Bug 3 (THE REAL BLOCKER, needs a build): the reconciler injects the promo by regenerating from a version's slots, but the current LP generation stores html only, NO slots — 89b1e08f has ZERO slotted versions ever; d771b646's last slotted version is 2026-07-09 with 7 html-only versions on top. So NONE of the 6 can be injected via reuseSlots without either reverting live content (reuse the stale 07-09 slotted version) or a promo-injection redesign. Recommendation: a promo bar is chrome, not content — build an HTML-injection path (insert the bar div after <body> / at the {{PROMO_BAR}} anchor on the deployed html, reverse on expiry) instead of regenerate-from-slots, OR make the LP builder persist slots on every version. Held the fire AND the runtime scope-repoint (pointless until injection works on html-only pages). Fire-now-vs-reset-window is moot until then. NOTE: whole promo system is branch-only (fix/seo-meta-quality-gate, 140 ahead of main, never merged) — see [[assistant-dev-main-topology]]. ORIGINAL: Prior session (Jul 3) already built the reusable promo system ~90%; I verified it end-to-end: timer studiosight-promotion-reconciler.timer enabled (daily 06:30 UTC); reconciler dry-run proves activate on 07-08 (all 8 Brentwood pages: promoBar=true, exactCopy $500/"Save Up to"=true, qualityGate.pass, complianceErrors=0, per-page CF rollback IDs captured) + auto-revert after 08-08 (clear branch); deploys via HTTP to assistant :9122 (has CF creds, service active) so the bare .service env is fine; promo-bar tests 16/16. RESIDUAL: assistant must be up at 06:30 07-08 (watchdog covers). DEFERRED to phase 2: hero emphasis on motorized/HD pages, "Add promotion" UI, Google PromotionAsset (account not spending). ® MARKS DONE (operator: "use the real ® marks"): renderPromoBar now normalizes (R)->® / (TM)->™ before escaping (assistant render-html.js, commit 57f3641 on origin fix/seo-meta-quality-gate); unit test asserts the transform (16/16); assistant RESTARTED so it's live for the 07-08 render; direct check confirms "has ®: true, has (R): false". Record stays ASCII-safe; glyph is a render-time transform (respects the never-write-runtime rule).

(2026-07-04). studiosight-gbp-snapshots.service was failing daily (curl exit 28): the full-settings pass ran captureSnapshot sequentially for all 611→613 GBP locations, growing past the 290s curl budget (change-history loop was fine/complete). Fix (app/api/cron/gbp-snapshots/route.ts, PR #716): concurrency-5 batches + 250s soft-deadline returning 200 w/ fullRemaining+deadlineHit instead of timing out; idempotent (captureSnapshot no-ops on failed fetch, retries next run; conservative concurrency since GBP fetch has no 429 retry). Deployed + verified live: 613 locations in 26.3s, deadlineHit=false, healed 12 missed snapshots. failed-state cleared.

PRs #960 (dashboard, +5 review-bypass closures B1-B5 + N1) and assistant #183 MERGED + DEPLOYED (dashboard 0184fba, assistant 3f04167); live validator proof PASS; 3 canonical campaigns rebuilt with appointment-model ads (16 groups/16 ads/304 kws, ALL PAUSED incl. ads); ManualCPC ramp RETIRED (paused+empty). See process/features/google-ads-build/reports/BEACH-PHYSIO-CTA-REBUILD_14-07-26.md. Original scope: Beach Physio B2 ads shipped "free quote" CTAs — root cause = trades-biased deterministic RSA template banks (google-ads-architecture.ts slot copy + google-ads-rsa.ts banks, incl. fabricated "rated 5 stars" default claims). Fix PRs: dashboard feat/ga-cta-business-fit (conversion-model classifier + evidence-gated validator hard gate in Build path) + assistant fix/ga-prompt-cta-business-fit (prompt example + fallback banks). AFTER merge+deploy: one-shot in-place ad-group rebuild of the 3 PAUSED B2 campaigns to replace the quote-language ads (separate authorization; campaigns must stay paused until then).

FIXED for future builds (PR #964 merged+deployed 2026-07-14 2e74552; guard strips self-blocking default negatives at graph assembly, recorded on graph.negativeCollisions). REMEDIATION DONE 2026-07-14: Valley's broad cheap negative removed via API (validateOnly→live→read-back); deterministic scan scripts/google-ads-negative-collisions.mjs <cid> [live] now confirms ZERO collisions on BOTH Beach Physio 9316408200 and Valley 7032156594 (Beach Physio's was already clean post-rebuild — the "no removal tooling" claim was wrong, the script does removals). ORIGINAL: (found 2026-07-14 during Valley build): canonical graph DEFAULT negatives include BROAD cheap/free, which self-block the Near Me "Price" group's own cheap {service} keyword on EVERY graph build (affects Beach Physio too). Fix = collision guard in lib/google-ads-architecture.ts: strip any default negative that conflicts with the graph's own positive keywords. Small deterministic PR.

The audit found the task HALF-DONE and the done half fragile: a content-diff guard existed but keyed off a hand-maintained field list (the exact fragility the TODO named), and the enriched marker it was meant to rely on was write-only — written by the backfill, typed in the store, read by NOTHING. Also: the module shipped with a raw NUL byte so git treated it as binary and it merged effectively unreviewed. Now a field-agnostic provenance guard runs first, diff kept as second detector, loud named refusals, .gitattributes forces source to diff as text. 19/19 tests, 7/7 mutants killed. NOT VERIFIED: never executed against real LP storage (staging-gated) — refusal path has unit evidence only; and the guard only fires for enrichment writers that stamp enrichedAt (one confirmed, not all audited). ORIGINAL: LP fleet-backfill erases enrichments (found 2026-07-15, operator-visible on ASAR): scripts/lp-fleet-backfill.mjs (staging lane) re-derives drafts from prod source and flattens post-migration enrichments (hero-image-queue assets, review-thin-queue curated reviews). ASAR 1b8ac149 restored by snapshot merge. FIX before next backfill run: carry-over enrichment fields or refuse-to-overwrite-diverged records + add an enriched provenance marker so tooling can protect them mechanically. Noted on PR #969.

[VERIFIED DONE 2026-07-22] — studiosight-gbp-reviews.timer is enabled + active (last run 2026-07-20, next 2026-07-27); no longer a one-off ad-hoc fetch. ORIGINAL: (added 2026-07-15): runtime/gbp-reviews/<oid>.json was populated by a one-off ad-hoc fetch on 2026-07-08 (lp-review-selector PR5 era) — no tool/route/timer exists to refresh it. Needed so review-thin LPs can truthfully reach the >=2 carousel threshold (ASAR 2402013 has 1 sourced review, slider hidden until more real reviews exist). Build: small dashboard route or /home/ubuntu/studiosight/tools script fetching GBP reviews per OID (v4 API, existing GBP OAuth) + timer; then re-attach via the (enrichment-safe, see fleet-backfill defect above) migration path. Assistant reads via loadGbpReviews() — format already normalized.

[VERIFIED DONE 2026-07-22] (toggle half) — app/seo/[oid]/_seo-detail-client.tsx:741-749 renders an autoApplyRedirects toggle POSTing to the 404-recovery-config route; no longer API-only. ORIGINAL: (added 2026-07-16): (1) autoApplyRedirects per-site toggle is API-only (POST /api/seo/sites/<oid>/404-recovery-config) — add a dashboard control on the SEO site page per the self-service rule; (2) add a global enable/disable toggle that stops the redirect-repair script from executing at all (cron currently always runs, gating only affects writes) — cleanest as a feature flag in runtime/feature-flags.json checked at the top of app/api/cron/seo-redirect-repair/route.ts, surfaced as a UI switch alongside the per-site toggles.

(assistant PR #189 merged+deployed; dashboard browser-gate PR #1021 telemetry-origin fix; Aloha regen v21 live, beacon absolute, endpoint 200) — was (added 2026-07-18): running assistant (main) missing the /api/lead-events beacon rewrite (exists only on unmerged feat/lp-click-to-call-tracking/a436415). Aloha v18 (and any structured-builder LP) emits a relative /api/lead-events → 405 on *.pages.dev. Telemetry only — lead delivery unaffected. Fix ready: assistant PR #189 (one-line rewrite). GATED ops to land: (1) merge #189, (2) deploy+restart studiosight-assistant, (3) regen Aloha v18. All 3 need operator go (service restart + LP regen are hard-rule gated).

9-day read on account 6553318158: PMax 24023551353 ENABLED, 9,630 impressions, 245 clicks, 4 conversions, $174.97 spend, CPL $43.74. The revert trigger was "spend converging on the ceiling with STILL ZERO conversions after ~1 week of real delivery" — it did not fire, because conversions are not zero. Delivery is real (9.6k impressions vs the pre-change starvation) and primaryStatus is now LIMITED, not MISCONFIGURED, which was one of the named GOOD markers. Spend is $19.44/day against the ~$31/day authorized ceiling, so it has NOT converged on the ceiling either. CPL improved against the prior 30-day read ($66.02 -> $43.74), though that comparison is soft until the Phase 0 conversion cleanup lands. NOTE: RSA 24018289413 is now PAUSED (was enabled when the tripwire was set) with $73.35 spent and 0 conversions across 350 impressions — I did not pause it and per the never-unpause rule I will not touch it; flagging so the state is not a surprise. Original entry follows for the audit trail. (applied 2026-07-19): cleared target CPA on RSA 24018289413 ($15.00 -> NONE) and PMax 24023551353 ($7.50 -> NONE), account 6553318158. Budgets UNCHANGED ($16 + $15/day). Expected effect: daily spend rises from ~$2.67/day combined toward the ~$31/day authorized ceiling (~$217/wk). Check 2026-07-28. GOOD: rank-lost IS falling from 90% on PMax, non-zero impressions, primary_status leaving MISCONFIGURED, RSA budget-lost RISING (budget not bid becomes the constraint). BAD / REVERT TRIGGER: spend converging on ceiling with STILL ZERO conversions after ~1 week of real delivery = paying full budget for nothing; revert by POSTing the restore ops (recorded in reports/debugger-260719-1804-trek-misconfigured.md) to /api/google-ads/campaign-target-cpa on the production dashboard — the CLI script was deleted in favour of that route. Root cause remains INFERRED (Google returns UNKNOWN reason codes); if it fails, next hypotheses: stale new-account status (campaigns 6-8d old), PMax thin inventory/URL expansion, campaign-level conversion_goal, or read the Google Ads UI diagnostics panel for the decoded human-readable reason.

It does NOT time the read. studiosight-assistant/server.js:1900-1910 (GET /client/profile/:id) performs a REAL network pull (fetchRatesightReviews -> app.ratesight.com widget, 12s timeout) on every read, and stamps the marker ONLY when that pull succeeded AND returned data (reviews.ok && (reviews.count || reviews.quotes?.length)). So "age 0.0 min on every read" is CORRECT — the route is deliberately fully-live ("re-pull reviews on every read"), not a stale stamp. The staleness guard is sound: a failed or empty pull leaves the marker untouched, so it correctly ages. Residual nuance found instead (NOT the reported bug): the stamp mutates the in-memory profile and is never persisted — there is no save in that handler — so any consumer reading the STORED profile sees an absent/older marker than a live read would. Harmless today because every consumer path goes through this route (which re-pulls anyway), but it means the marker cannot be trusted as a durable record of last-pull time. Guard NOT weakened; omit-on-stale behaviour untouched. ORIGINAL SUSPICION: reviewsRefreshedAt may measure the read, not the pull (found 2026-07-19): the marker shows age 0.0 min on every profile read, suggesting it refreshes when we read the profile rather than when Ratesight data is actually pulled. This is the guard that stops us publishing a stale review aggregate as verified proof on landing pages, so if it times the wrong event the staleness protection is weaker than it appears. Did not affect the 2026-07-19 regen run (review data was genuinely live, 5.0 from 36 reviews, matched). Investigate in studiosight-assistant (separate repo). Do NOT weaken the check; the correct behaviour on stale data is to OMIT the review line, which it already does.

The stale ask asked us to CHOOSE between (a) builder-native inputData.services counts as verified provenance vs (b) harvest a sibling page. Option (a) was already shipped (PR #1088 + the 2026-07-20 declared-not-website label) in lib/lp-builder/evidence-from-legacy.ts (declaredBuilderNativeServices + servicesFromIntake + acquireEvidence): a builder-native project sources its services grid from operator intake tagged declared provenance ("A SERVICE NAME IS NOT A CLAIM"), superseding the single profile service_type label — with a hard boundary that a claim-shaped service NAME ("Free In-Home Estimate", "Licensed & Insured") stays a label and never grants a risk-remover. Option (b) was explicitly rejected (importing a sibling's evidence = provenance laundering). Verified this session: real prod data for brentwood-blind-company-window-treatments is generator structured-builder-v1, inputData.services=6 (incl. the "Custom window treatments" umbrella), structuredDraft.services=5 → a regen now yields the 5 real service cards (umbrella correctly resolved out), NOT the 1-card collapse. __tests__/lp-evidence-declared-services.test.ts locks it — 12/12 green (incl. "THE REGRESSION: 5 cards, not 1" and "PRECEDENCE, NOT UNION: umbrella not re-added"). Only remaining (optional, operator-gated, NOT blocked): actually regenerate + redeploy the live window-treatments page if you want the deployed *.pages.dev refreshed — a normal client-facing deploy, not a decision. The honesty-semantics question is settled.

The stale premise ("those unevidenced claims stay live") is no longer true. All 6 Quantum LPs (OID 174752: long-distance a9dde43e, bay-area 3f1c646d, piano 719275be, packing-services a59b0099, full-service-packing b18bd2ee, office-commercial 25b71046) are now structured-builder-v1 (lpb-), re-deployed 2026-07-20→07-24. The dominance-pin mechanism the ask required already exists — seed-draft.ts:104 primaryServiceOverride (hero-only pin, doesn't touch serviceTypes) resolved+honesty-guarded in client-build-lp-cutover.ts:334-366 (pin refused unless corroborated) — and the render-boundary claim gate (draft-claim-gate.ts:256 gateDraftClaims, FAIL-CLOSED, wired at render.ts:1524) strips unevidenced licensed/insured/bonded because moving is not an auto-grant profession. Live grep this session (piano + office pages): lpb- present, licensed/insured/bonded/same-day = 0/0/0/0, H1s "Piano & Specialty Movers in Alameda" / "Office & Commercial Movers in Alameda" (targeted service dominant, NOT collapsed). CAVEAT: I did not find an operator-approval record for the 6 deploys (may have been automated fleet regen) — outcome is correct + honest regardless. SEPARATE + STILL OPEN: the offer/price SERVICE-TITLE claims ("Free Written Quotes" on long-distance + office-commercial) are client-supplied source data outside the render gate — that's line 134's operator-decision item, unchanged.

Real cause was NOT a missing MANAGE_LEADS task (my first diagnosis, which the operator acted on and which changed nothing): the page was not owned by our Business Manager at all, so no task could attach. GET /{page}?fields=business returned an owning business for the healthy control page and NOTHING for this one. Operator claimed the page into BM; retrieval unblocked immediately and the 5-minute sweep delivered all 6 leads to Ratesight (status=delivered, OID 2402003) with no manual step. The 4 leads on the sibling form were delivered back on 2026-05-13 — no stale-lead delivery occurred. ORIGINAL NOTE: Confidently Fit - Personal Training (OID 2402003). We are subscribed to leadgen and correctly routed, but Meta returns 0 leads against leads_count 6 — we cannot retrieve the data. Sibling page 1030924733435890 returns all 124. Proven by differential test. Code now reports this loudly (RETRIEVAL BLOCKED, severity high + bug report) but the fix is a Business-Manager permission grant only the operator can make. Every lead on this page is lost until then. Verify after with: curl 'localhost:9125/leads/form-leads?formId=1467046624917773' → expect returned > 0.

(added + DONE 2026-07-22): built GET /leads/retrieval-audit. Result: 33 forms probed, 31 retrievable, 2 blocked — both on Confidently Fit page 1172577005928820 (10 leads unreachable), 1 page unknown (no page token, 3 forms). The block is CONTAINED to one page, not the fleet-wide epidemic I speculated. ORIGINAL NOTE: the nightly token audit tracks MANAGE_LEADS but nothing cross-checks it against *actual lead retrieval*. GET /leads/form-leads?formId= per routed form with leads_count > 0 gives the empirical answer. Memory says 23 clients are missing MANAGE_LEADS — each is a candidate for silent total lead loss.

(added + RESOLVED 2026-07-22): measured with /leads/form-leads. All 29 unlogged leads are 74-89 days old (pre-logging era, May). None within any deliverable window; they age out of Meta's 90-day retention shortly. The 'partial residual older than window' label was CORRECT — no lost revenue, no action. ORIGINAL NOTE: H&U Express Moving (22 count / 12 accounted) and Dejavu Move-In-Out (85 / 66) carry partial residuals older than the 7-day window. Correctly cursor-silenced and NOT the same defect as Confidently Fit, but never investigated. Deciding whether to recover any requires an explicit exception to the 7-day delivery policy.

(added + FIXED 2026-07-22): /api/leadforms now 400s on unknown params (dashboard 42fdcd45, staging-validated, NOT yet promoted to prod); studiosight-meta /ads now 400s on camelCase aliases (PR #44, live). CORRECTION: the claimed filterItemsByPage bug is NOT real — it DROPS unmappable items rather than returning everything. ORIGINAL NOTE: /api/leadforms reads page_id (a ?pageId= caller gets every page); studiosight-meta/server.js:869 ignores campaignId, and filterItemsByPage reads promoted_object.page_id off *ads*, where that field does not exist, falling back to a cache that returns everything on a miss. Both answer confidently with unfiltered data. Cost real diagnostic time this session.

(added + FIXED 2026-07-22): latent trap, not the cause of the Confidently Fit loss. A system user with ADVERTISE but no MANAGE_LEADS mints a page token fine and then returns an EMPTY lead list (Meta does not error on unauthorised retrieval), so it wins the race, gets cached, and blocks lead reads silently. fetchLeadsForForm now has opt-in cross-token retry on empty (enabled only in reconcile's deep-fetch, where empty is evidence of a wall rather than of quiet) and REPOINTS the cached index, filing a high-severity report rather than self-healing silently. leads 4d24af2, 19/19 tests.

Operator decision. Found a second, quieter bug while doing it: updateTarget SILENTLY DROPPED cadence and nextRunAt, so only the create path ever set them — the 23 existing targets could not have been moved off monthly by ANY code path. Both now pass through, and re-seeding normalises the schedule rather than only the keywords. All 23 migrated and verified: cadence=weekly, nextRunAt=null so the next sweep picks them up instead of waiting for 2026-07-26. NOTE: the work queue reads a precomputed sidecar (runtime/seo/worklist/<oid>.json) rebuilt at 11:45 UTC, so its untracked count still lags the underlying data by up to a day. ORIGINAL: Rank cadence is MONTHLY and the first scan has not happened (found 2026-07-23). POST /rank/seed-keywords hardcodes cadence: 'monthly'. The 23 clients seeded 2026-07-22/23 show lastRunAt: None, nextRunAt: 2026-07-26 — so the SEO work queue's "untracked" count CANNOT move until the chain runs (organic-rank 07:25 -> page-rank 11:30 -> worklist rebuild 11:45), and after that it only refreshes monthly. Monthly is too slow to be a feedback loop for a system meant to prove improvement. Cost is not the constraint (~$0.32/month fleet-wide), so weekly is affordable — but changing cadence is an OPERATOR DECISION, not a side effect. Also note the work queue reads a PRECOMPUTED sidecar (runtime/seo/worklist/<oid>.json), so it always lags the underlying data by up to a day.

(was: Morning correctness sweep — confirm first timer-driven cycle (check 2026-07-29 after 13:05 UTC)**: six sweep timers installed 28-07 (lp-live-render 08:20, alignment-audit 10:15, conformance 10:25, lp-alignment 12:00, evidence-verify 12:15, artifact-fit 12:20 UTC). Verify the 13:00 morning report email carries the sweep section with all 6 areas non-stale. Also: (a) RESOLVED 28-07: Quantum hero finding was a sweep false positive (stale approved-asset record vs badge-refused hero; page correctly serves illustration hero) — fixed in PR #1401, merged+deployed, page now passes; (b) RESOLVED 28-07: was instrument staleness (rule forbade canonical reCAPTCHA/GTM scripts) — fixed via script-inventory classification PR #1409; fleet now 31 aligned / 0 off-template / 3 stale (never-deployed ASAR); (c) Phase 2b verification: next real build per class should carry avatarContentHash/inputSnapshot — check a fresh builds.jsonl / client-build-runs record; (d) PARTIAL 28-07: LP regen capture wired (PR #1409, confirmed on fresh versions); still open: assistant-side/UI LP creation uncaptured, verifyServedAssets not wired into Phase 3. NEW 28-07: hero copy fleet refresh shipped (per-niche anchor banks PRs #1407/#1413, 22 pages regenerated, 10 new heroes); departed-client pages (Quantum x6, White Rose) still live with old copy — operator decision whether to take down; served-verify procedure should add CDN propagation wait + cache-buster (race produced false 'unchanged' readings twice). Plan: process/general-plans/active/morning-correctness-sweep_PLAN_28-07-26.md

(DONE: UI batching PR #1418; Kothmann plugin updated by operator; 28 drafts + boerne recreate exist on WP awaiting publish) (found 2026-07-28, PR #1408 deployed the missing /apply proxy route): a full "Preview drafts (dry-run)" for a client with many missing services (Kothmann 2470 = 28 missing × ~50s LLM call ≈ 25 min) exceeds the 290s proxy timeout — the UI button now reaches the backend but times out client-side while the assistant keeps generating. Fix: cap services per request in the UI (send explicit services:[...] batches) or move apply to studiosight-jobs. Also: Kothmann's WP plugin is a minimal build (/capabilities = rest_no_route, only /create-page) — plugin update needed before real draft writes.

original text: (after assistant PR #239 (deployed 2026-07-28)**: the "selector_miss" theory was REFUTED by live-DOM measurement — selectors match; the server fabricated the label for v4 clients that report no reason. #239 (live) now records client reasons verbatim, de-identifies ambiguous v4 attribution, and dedupes duplicate fixes (kothmann 16→15, verified live). Remaining: (1) TRACE which origin serves snippet v5 to 5 client sites (drmelindasilva, brentwood, optimusmovingservices, quantummoving, fatcatmovers — 3068 events) while dashboard.ratesight.com serves v4 and branch fix/seo-snippet-v5-dashboard (commit d120a5e0) is unmerged; (2) the REAL alt problem is 1460 already_present skips = stale crawl/audit state claiming alt missing when the live page has one — needs a crawl-freshness/reconcile fix, separate scope; (3) dashboard UI still doesn't show skip reasons on issue rows (audit finding 2, now feasible since reasons are truthful).

(was: PR #1420 ready; regen+redeploy the unfinished half) (2026-07-28): fix/hero-variant-per-page (adopted an idle uncommitted in-flight change, completed + verified: per-page variantKey + no-fit angle rotation + per-anchor salt + bank variants; composing all 14 affected pages → findHeroFrameCollisions NONE, distinct H1 5/5 / 4/4 / 5/5; suite 7709 pass, tsc/build clean). AFTER MERGE the 14 live pages must be REGENERATED AND REDEPLOYED then served-verified with cache-buster (undeployed = unfixed, C21). Operator decisions: (a) Quantum is a departed client — redeploy their 5 pages or take them down? (b) merge authorization (CI dead on billing, checks ran locally). Follow-up in PR: findHeroFrameCollisions cannot see comma-free templates ("Your written quote is the whole cost of X.") — detector gap, separate scope.

Premise re-verified: still zero ads-side consumers at ad0a08ba. But the deterministic RSA angle banks CANNOT produce the contradiction — they interpolate only {City}, and those cities come from the operator's own declared service area, which is the same rung as the asserted label. The contradiction enters through overlayLlmCopyOntoGraph, where free-text AI copy replaces the unpinned slots. So lib/ads-geo-language.ts reads profile.service_area_label.value (the exact cell client-facts.ts and the LP cutover read) and the overlay DROPS an AI line naming an administrative area the asserted label does not — the Brentwood defect verbatim: "Williamson County" refused against "Greater Nashville". Bank copy fills the slot, so a refusal costs an ASSET, never a headline count, and each refusal is reported ONCE on the existing contentRuleFlags operator-review channel. Deliberately narrow: only county/parish/borough/metro nouns are policed — the targeting-speak register the operator rejected by name — because a general place-name test needs a gazetteer and a false refusal costs a real live headline. NO asserted label => nothing is ever dropped and the overlay is byte-identical to before (pinned in test). Inventing an {Area} copy token was considered and rejected: it would have changed live ad copy fleet-wide to fix a contradiction only AI copy creates. __tests__/ads-geo-language.test.ts, 13 tests.

(FIXED 2026-07-28, assistant PR #241 merged+deployed: values now composed from page context, 1089→0 filename-equal fleet-wide, verified live) (found 2026-07-28 during snippet v6 replay): for many junk-alt images the assistant's own fix VALUE equals the filename (car.png → "car"), so snippet v6 correctly declines them as no-ops — 14 of 15 at kothmann. The 1460-image backlog only partially converts until altFromFilename generates real descriptions (or fixes are regenerated from page context). Assistant repo, separate scope.

(FIXED: PR #1430 atomic safe-build, proven 0/400 missing-manifest samples vs 400/400 before; first live swap observed) (2026-07-28, bit twice today): concurrent sessions running next build in /home/ubuntu/studiosight-dashboard while the service serves from the same .next caused "client reference manifest does not exist" 500s (/seo/activity) and two crash-loops (partial .next at restart). Fix the class: build to a temp dir and atomically swap (or Next output: standalone + versioned deploy dirs), so a running server never has its chunks replaced underneath it. Related: C23 in process/defect-classes.md.

app/api/seo/sites/[oid]/wp-apply/route.ts has no CONTENT_FIELDS: it carries SEO_FIELDS = ['meta_title', 'meta_description'] and a REFUSED_FIELDS = ['content','post_content','article','html'] list that returns a loud 422 BEFORE any network call, naming the assistant's create-page upsert as the endpoint that CAN write a body. The route header records the same reasoning this entry asks for (update-page never echoes post_content, so a content write could only ever be unverifiable or a full-body REPLACE that destroys a builder layout). Covered by __tests__/wp-apply-dry-run.test.ts (6 passed). No code change needed.

(was: Trust chips are fleet-generic filler** (2026-07-28, from operator's Aloha rating): "Local team" / "Clear next steps" / "Fast response" come from the vertical copy banks' floor and say nothing to a comparing buyer. Right fix is chips-from-evidence: derive chips from declared risk-remover kinds + niche-bank anchors (e.g. window cleaning: "Inside & outside", "Frames & sills included"), never invented per client. Design change, separate scope from PR #1436.

(was: AI content-fill: deploy + first live client** (2026-07-29): the missing AI half of the Builder copy system is BUILT AND MERGED — assistant PR #248 (endpoint + direct-response prompt from the operator's LP/ads templates) + dashboard PR #1441 (regen wiring behind lp-content-fill flag, per-OID, default OFF; every slot validated by applyContentFill). Offline acceptance PASSED on Aloha (mechanism-led hero accepted, numeric chips correctly rejected). REMAINING, both operator-gated: (1) restart studiosight-assistant to serve the endpoint (merged code inert until then); (2) flip lp-content-fill for the first client (recommend Aloha 174773) and regen. Historical finding for the record: the dashboard has called this endpoint since the Builder shipped and it NEVER existed — every fill silently degraded to floor copy (C21 class).

certified/accredited left licensed_and_insured (which now detects insured/bonded only), so Brentwood can say the true thing without being handed the unevidenced one; the "authorized" workaround can be retired at the next copy pass. Detection is narrow on purpose — never the bare word ("certified organic", "certified pre-owned" are refused); every pattern requires the credential attached to the business or its people (named issuing body, practitioner/dealer noun, or the accreditation vocabulary, which has no consumer-goods reading). MIGRATION: IMPLIED_KINDS.licensed_and_insured now implies certified_or_accredited, so every existing holder of the stored grant keeps every word they could say the day before — one direction only, since the reverse is the conflation being undone. The load-bearing decision: the new kind renders NO CHIP (chip: null). Most clients reach it via the migration, and the evidence behind that grant may have been the insurance half alone — a chip would have stamped "Certified & Accredited" onto live pages for clients who never showed a certificate, which is fabricated provenance and a strictly worse defect than the conflation. Caught by the existing five-grant fixture test during the run, not by reasoning after it. Nothing on any page gains a chip. __tests__/risk-remover-certified-split.test.ts (14 tests) plus updated expectations in risk-removers / risk-remover-evidence / risk-remover-regulatory / lp-risk-remover-copy, where the single insurance-exclusivity invariant became two (insurance language to licensed_and_insured alone, credential language to certified_or_accredited alone).

(was: Brand-color kits: 2 remaining gaps) (2026-07-29, from operator "the blue doesn't match their logo"): Valley + H&U fixed from site-verified palettes (PR-less data fix + regen). REMAINING: Cincinnati/Premier Kitchen 174719 — plain fetch of cincinnatiapplianceinstall.com yields zero brand-ish colors (JS-rendered or neutral site); needs the browser-render scrape or operator-supplied colors before their pages leave template blue. Rhino 2402010 also empty-colors but has no live LP. Class prevention idea: brand-kit save should flag empty brandColors on any client with a live LP.

(was: Dashboard restart pending — on-disk build diverged from running service) (2026-07-29 ~04:00 UTC): the running dashboard (:3002) started 01:13 UTC on the authorized bfef53c1 build, but session build-verification runs overwrote .next with current-trunk builds — a crash/watchdog restart would now silently deploy trunk. Trunk is GREEN (7881 tests, all today's changes served-verified via the CLI regen path). RECOMMEND: operator authorizes a deliberate systemctl --user restart studiosight-dashboard onto current trunk (also activates today's new routes: content-fill in-service, ads-lp comparator, risk-remover confirm on latest code). Until then, avoid relying on new dashboard ROUTES in the running service; CLI paths are current. PREVENTION: future build checks should build into a scratch dir (BUILD_DIR/--outDir) or a worktree with its own node_modules, never the production .next.

Two independent reads, both against raw rows.

(1) Horn Law — 9 zoning/land-use/code-violation PHRASE negatives applied to live campaign 23914735589 (validateOnly previewed; reversible). (2) Goliath — live search ad 801119744113 final URL flipped http://goliathmoving.ca/ -> https://goliath-local-residential-moving.pages.dev/ (destination 200 verified; completes click->gclid->server-upload loop; watch first lead). (3) Valley — free_no_obligation_quote DECLARED (operator tier), all 4 live RSAs rewritten through the claim gate: savings/same-day/no-pressure/in-minutes claims OUT, "Shop 15 Carriers at Once"/"One Form, 15 Carriers"/"No Calling Each Provider" IN (gate refused first pass until evidence landed — working as designed). (4) White Rose — refreshed to evidence-led copy v20; the logo-mismatch blocker was the IPv6 flake, bytes identical to approval. (5) Popup — ALREADY LIVE fleet-wide: the "0 of 29" premise grepped the LEGACY marker (lp-popup-config) which structured pages never emit; correct signal = .lpb-popup + data-exit=1, verified serving on all 28 active pages, exit-intent only, single capture surface by construction. Zero popup mutations needed.

ALL 4 PHASES LIVE 29-07 (PRs asst#257, dash#1461/#1462): 100% baseline-or-reason attribution, 42/42 clients baselined (t0-on-add live, 40 legacy marked late), 16 Google Ads routes ledgered, daily 12:46 sweep + by-client card; first run graded 1303 changes (5 gradable: 3 regressed/1 improved/1 flat — investigate the 3 regressions). Follow-ups: thread campaignId through keywords/ad-assets/ad-final-url/restructure rows; SEO playbook reader is the next build.: P1 baselines on every SEO change (assistant, applyOneFix + outcomes no-baseline verdict + ageDays floor) · P2 snapshot-on-connect (client-profile/save trigger + identity-join re-capture + hasBaseline badge + late-backfill script) · P3 change-outcomes morning-sweep area + UI surface (engine merged PR #1195, zero consumers today) · P4 Google Ads mutation ledger (zero ledger rows today). All three agents launched 29-07; deploy+verify as PRs land; after deploy run P2 backfill. This completes vision loop stages 2+7; SEO playbook (the reader) is the build after.

(2026-07-29, surfaced by the operator seeing "2 separate Aloha lead pages"). (a) PORTFOLIO DEDUP: app/landing-pages/_landing-pages-client.tsx no longer carries the "migrated is staging-only" assumption — it calls splitMigratedRows and renders ONE ROW PER PAGE, with a migrated record keyed to a listed legacy project shown as that page's saved-draft badge rather than a second page; only STANDALONE migrated records get their own row. (b) THE CUTOVER: structuredRegen composes from the migrated draft when one exists — loadMigratedRecordResult feeds operatorDraft into StructuredLpParams, and an existing-but-CORRUPT record REFUSES loudly (422) rather than silently regenerating without the operator's edits, which is the stronger version of what this entry asked for. Re-read at ad0a08ba; no code change needed.

(1) STEMMING: themeStem folds plurals and gerunds onto one form (mover/movers/moving), applied at COMPARISON time in messageMatch and for slot dedup in themeTokens, so the operator still reads "movers" and not "mov". Suffix-only, no dictionary, no irregulars — every extra rule is a chance to collide two genuinely different words, and a false MATCH here hides a real message-match failure. A trailing -e fold was tried and REVERTED: it made "movers" equal "move", which stopped a "Piano Movers" ad group raising V-11 against an "Affordable Help For Your Next Move" hero that says nothing about pianos — caught by lp-ad-match-validate, and the ledger's case is movers/MOVING anyway. (2) BOILERPLATE: an AD_GROUP_NAME_BOILERPLATE stop-set applies to the ad-group-NAME source only, so H&U's "Ad Group Optimized" stops leaking optimized into its theme, while the same word in a keyword or pinned headline still counts as the ad's real subject. (3) re-measure Goliath/H&U after Google read-lag clears — STILL OPEN, an observation task. __tests__/ads-lp-theme-tokenizer.test.ts, 10 tests.

BOTH WAVES LIVE 29-07: W1 localRank-in-t0 (#1467) + quarterly client audit w/ 30d link + real PDF (#1470, Kothmann first report verified, timer 16:41 daily); W2 durable playbook entries (#1472, 11 entries/9 niches, timer 04:45 daily, promote/demote + approvals-queue bridge). Deferred by decision: Bing. Next natural build: promotion→versioned-bank PR generation; localRank CORE_SECTIONS decision.

Both halves the entry asked for are in lib/seo/seed-drop-guard.ts and wired into the route: (a) refuse-or-warn - a persist: true that would stop tracking any currently-tracked keyword now returns 409 would-shrink-tracked-set, naming every keyword at stake, and proceeds only on an explicit acceptDrops: true (a truthy value is not consent; only literal true counts). Refusal, never repair: nothing re-adds a dropped term, because the hygiene reason for dropping it may be right. (b) echo the resulting tracked list - every response, dry run and persist alike, now carries tracked.before / tracked.after plus hygiene.added, and the dry run also returns wouldRefuse so a caller can ask the guard's question without writing. Normalization is shared, so a formatting difference never reads as one drop plus one addition. 13 unit tests pin the original incident's three brand terms. Shipped as PR #1995, awaiting review; merged code is inert until the dashboard next ships. The SAB-first-place note in the original is still open and is now tracked on the H&U line above. ORIGINAL: seed-keywords persist semantics pruned existing brand terms while echoing 0 seeds (29-07, caught+restored within minutes by post-persist verification): a persist:true call on 170652/172658/174697 silently dropped tracked brand terms ('one two tree', 'confidently fit', 'raven finley', 'brentwood blind*') and the response gave no indication. Restored via targets PATCH, verified. Route needs: (a) refuse-or-warn when persisting would shrink the tracked set, (b) echo the resulting tracked list, not just seeds. Also minor: SAB ladder picks FIRST service-area place (174697 resolved Cary; Raleigh arguably primary) — consider population/GSC-demand ordering.

automatic promotion observed working on real data: reconcile detected+repaired a false 'promoted' state, policy re-decided (n=7 side-by-side clears the 5 required), and PR #1501 opened automatically adding 'Standard' to PROMOTED_NICHE_AD_STYLES.movers with provenance (entry id, n, evidence strength, confidence, date). Second run: 0 promote / 0 reconcile / 12 hold = stable, no churn. Chain of fixes required to get here, all merged: feeder lanes #1495 (Google BEST-label never populated -> winnerAsset w/ basis; Meta ad-style lane), typecheck runner #1498 (service PATH had no node -> false 'does not typecheck' forever; now typecheck-unavailable is distinct), state atomicity #1500 (status flipped before PR landed -> evidence-based reconcile). REMAINING: merge #1501 (or set PLAYBOOK_AUTO_MERGE); demotion-PR-failure has no auto-retry (known gap, own fix).

Before: 39 open dashboard PRs, main 1825 commits behind fix/conversion-upload-monitor, and 5 branches whose only copy of the work was an uncommitted worktree. Done: (1) preserved the 5 never-pushed branches as labelled wip(...) snapshots — fix/risk-remover-certified-split (8 libs + a new test), fix/oid2-qa-artifact-noindex, fix/brentwood-geo-targeting, feat/seo-scorecard, docs/defect-classes-split-c8. (2) fast-forwarded main twice (#1204, then #1512) — main is a strict ancestor of the trunk, so nothing was lost. (3) merged, cross-repo pairs shared-lib-first: tools#99→dash#1507 (copy spec + claim gates incl. the invented-CPL gate), tools#100→dash#1509 (placements = every lead-form surface EXCEPT Marketplace + Audience Network; Advantage+ audience ON) → dash#1510 (include/exclude audience pickers on /build). (4) merged 3 real auto-bug fixes still unfixed on trunk: #975 /alerts force-static→dynamic, #878 /email React #418, #952 /api/comments 25s cap. (5) closed 10 with per-PR evidence (symbol-sampled against trunk): #711/#712/#724/#949 landed, #856 docs-only, #967/#1014/#1015/#1016/#1018 dup-or-false per the auto-bug ledger. Verification: typecheck clean, full suite 8355 pass / 1 fail — the one failure is the cross-repo e2e proving the live shared lib is not yet synced. NOT DEPLOYED, three gated follow-ups: (a) sync /home/ubuntu/studiosight to its merged main + restart studiosight-meta, or ad-set creation keeps using the OLD placement floor and advantage_audience: 0; (b) build + restart the dashboard; (c) purge the Cloudflare cache for /alerts and /email.