changedInput schema / properties / where_clause / description
Previous value: -"SQL WHERE clause (without WHERE keyword). Use ONLY these\ncolumns: provider, chat_id, sender_name, sender_provider_id,\nrecipient_name, recipient_provider_id, content, message_datetime,\nreply_outcome (inbound replies only; '' / 'interested' /\n'meeting_booked' / 'not_interested' — the reply's classified outcome).\nTo check whether a prior conversation exists before firing a\ntemplated message, match on\n`sender_provider_id`/`recipient_provider_id` first; if that returns\nzero rows, run a second pass matching the person's full name (first\nAND last) as a substring, e.g. `sender_name ILIKE '%Jane%Doe%' OR\nrecipient_name ILIKE '%Jane%Doe%'`, before concluding there's no\nhistory — a stored provider_id is often blank or wrong, so an\nexact-match zero is indistinguishable from \"never messaged.\" Never\nmatch on first name alone (it pulls every same-first-name person in\nthe inbox and risks dropping a cold message onto a stranger's live\nthread). The full-name pass is a substring match, so if it spans\nmore than one person (different provider_ids), use only the thread\nwhose counterpart is your recipient — don't merge look-alike names\nor reuse a mismatched `chat_id`. Even both passes empty isn't proof\nof no prior contact: this local store holds only a bounded initial\nbackfill from around when the account was connected, forward, so an\nolder or pre-connection thread may never have been ingested — and\nthe same person may be stored under a variant name a substring match\nmisses. When you have the counterpart's `provider_id` and need\ncertainty, call `fetch_linkedin_messages_with_person` — it reads\nLinkedIn's full synced history live and writes it back here; if that\nalso returns empty, treat \"no history\" as confirmed, otherwise flag\nthe uncertainty when a cold-open template goes to approval."New value: +"SQL WHERE clause (without WHERE keyword). Use ONLY these\ncolumns: provider, chat_id, sender_name, sender_provider_id,\nrecipient_name, recipient_provider_id, content, message_datetime,\nreply_outcome (inbound replies only; '' / 'interested' /\n'meeting_booked' / 'not_interested' — the reply's classified outcome).\nTo read your thread with a person, match their provider_id alone:\n`sender_provider_id = '<id>' OR recipient_provider_id = '<id>'`.\nKeep their name out of that clause: a name ILIKE is a substring\nmatch, so it pulls in other people's threads (`'%Ana%Li%'` also\nmatches \"Diana Lim\"). Match on a name only to find someone whose\nprovider_id you don't have; when a hit's counterpart name is their\nfull name, take it as theirs and re-read by that counterpart's\nprovider_id. An empty result isn't proof of no prior\ncontact: this local store holds only a bounded initial backfill\nfrom around when the account was connected, forward. When you need\ncertainty, call `fetch_linkedin_messages_with_person` with their\nprovider_id — it reads LinkedIn's full synced history live and\nwrites it back here."