Rule: Before drafting/teeing up ANY deal outbound, two primary sources gate it and BOTH must be read first, every time, per recipient: (1) the Gmail Sent folder + the actual thread (is a reply even owed / did Joseph already send?), and (2) the verbatim last-meeting transcript for that deal in Call Transcripts/transcripts/ (read it word-for-word, not the Gemini/Otter notes, not the project memo). gmail-deep-scan insights, pending_drafts entries, and project memory files are NOT sufficient and are routinely stale or flat wrong.
Why: 2026-05-19 — I teed up an Eric Bishop "got the listings, let's set a call time" draft. Joseph had ALREADY sent essentially that email on 2026-05-18 ("Erick — Got the listings, thanks… availability tomorrow afternoon or Thursday"). I'd leaned on project_inbound_eric_bishop.md ("Joseph to set up the formal call") + scan insights and skipped the Sent-folder gate. The memory was stale; the Sent folder was ground truth. This is the exact failure R-23 (memory ≠ primary source) and the external-draft SOP no-stacking gate exist to prevent. Joseph caught it and was right.
Devine inversion (2026-05-19, same batch): I teed up an abject apology to Ryan Devine for a "missed meeting." Reading the verbatim 2026-05-14_devine-granby-ranch-2nd-meeting_full-transcript.txt word-for-word showed the meeting HAPPENED and went ~50 min well — the "are we meeting now?" line was Ryan waiting to be let in ("Ryan texted me and said he's just waiting to be let in"). Joseph recced Lot 100, held 30%, decision target "by early next week," next step is the Devines sending in-person dates. The apology premise was inverted. The memo summary alone did not catch this; the verbatim transcript did. Lesson: the last-meeting transcript is non-optional primary source for deal context.
Also learned (compounding): the system's own already_handled_in_gmail no-stacking gate is unreliable while the Gmail MCP connector is down (dead since 2026-05-13). On 2026-05-19 it returned already_handled: true with identical false-positive garbage evidence for unrelated recipients (echoed the Bill Smith delivery-failure row). Gmail DOM-scraping via cloud_bridge is too flaky to substitute for the MCP here. So until the Gmail MCP is re-authorized, treat automated Sent-reconciliation as NOT trustworthy and surface drafts as "verify-first," never "clean to send."
How to apply:
- For ANY deal draft: read the verbatim last-meeting transcript word-for-word AND reconcile the Sent folder/thread BEFORE composing. Notes/Gemini summaries and project memos are starting points, never the basis for an outbound claim.
- Never present a draft as send-ready based on insights/memory alone. Either confirm via a reliable primary-source Sent/thread read, or explicitly mark it "⚠ verify your own Sent/thread first" and say why.
- If the Gmail MCP is down, state that the no-stacking gate is unreliable and that the durable fix is operator re-auth of the Gmail MCP connector — don't quietly proceed as if the gate passed.
- The Eric retraction pattern (move to _RETRACTED/ with a header explaining the miss, mark the queue entry
superseded) is the correct way to walk back a bad draft honestly.