SKILL: don't loop search-then-update in HubSpot; collect IDs first

Job: fill one dropdown on contacts from their email domain. No enrichment credits, just a rule. Client details stripped. Pass one, the mistake: "search contacts where the property is blank and the domain matches, batch-update those 100, repeat until search returns nothing." CRM search reads an index that lags batch updates. Records I had just written kept coming back blank for several more pages, so I wrote them again. Result: 24,860 writes on 8,070 unique records. Same value each time, so no damage, just about 3x the API calls and a log that overstated the work. Second trap: `hs_email_domain` with `CONTAINS_TOKEN` and a leading wildcard is token matching, not a suffix test. It returned domains that merely contained the token. Filter client-side on the actual email before writing anything. Pass two, the shape I'd ship: 1. Page the whole search (limit 200, sort `hs_object_id` ascending, follow `paging.next.after`). Don't filter on the property you're about to write. 2. Filter client-side: strict suffix match on the email, property still blank, ID not already in the written log. 3. Dedupe the IDs, then batch update in chunks of 100. On 429 or any non-2xx, wait and retry that chunk; append its IDs to an append-only JSONL log only after a 2xx. 4. Count from the log's unique IDs, never from write calls. Pass two: 9,483 IDs collected, 9,483 written, once each. Receipts: the log line per record doubles as the rollback list. My KPI for the day was stamped from unique IDs only (14,638), not from 34k write calls. The search result is a rumour; the log is the guard.