Plan: /Users/agency/Documents/Agty/GHL funnel/action-plans/2026-08-17-crm-activity-log-smart-drafts-and-reminders-refined-v2.md
J/K, to open it.1 delegate, 2 drop, 3 idea, 4 ask first, 0 clear, J/K to move between tasks and open the selected task.!.Activity Log is already the shared communications ledger, but meeting storage is still split and the legacy transcript database remains active. Missive, Slack, Calendar, Modal, Codex, and Claude contain useful existing machinery, yet several live health and ownership claims still need read-only proof. This refined plan converges those paths around one Activity timeline, Missive relationship drafts, and Gmail-backed invoice and reminder transactions.
The locked boundary is 120 days. Relationship messages stay draft-only. Meeting records use four exact Types. Calendar events begin as meeting scheduled. Universal Reminders apply only to first and second sales calls at the four exact times supplied by the user.
Create one fresh, source-traceable baseline that identifies the deployed revision, live Notion schemas, Missive and Slack access state, Calendar subscription and reconciliation state, Modal functions and schedules, Codex automation history, LaunchAgent loaded state, and owner of each live Modal app.
The current map mixes live receipts, local code, local configuration, historical reports, and proposals. Implementation cannot safely start until those layers are tied to one timestamped baseline.
Builders may modify the wrong revision, duplicate an existing runner, retire a still-owned app, or claim a provider outcome from static code.
Every later task starts from the same verified system boundary and knows which unknowns require a gate instead of an assumption.
Done: A frozen baseline records evidence class, observation time, deployed source identity, schedule ownership, live health or explicit UNKNOWN, and non-mutating verification for every scoped system. 80/20: Verify deployed SHA, Notion schema identity, Modal schedule health, Missive access, Calendar ingestion health, and the exact 03:00 owner before any build.
flowchart LR A[Mixed evidence baseline] --> B[Fresh read only receipts] --> C[One trusted execution boundary]
flowchart TD
S1[Read applicable state files and the private 2026 08 17 system map]
S2[Collect fresh read only provider and runtime receipts]
S1 --> S2
S3[Label every fact live code only configured historical proposed or unknown]
S2 --> S3
S4[Map owners and durable keys for overlapping schedules and apps]
S3 --> S4
S5[Save a redacted baseline and independent validation receipt]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Make the existing real-time email ingestion and an emails-to-N-activity-log reconciliation skill on the existing 03:00 daily surface jointly account for every relevant human email across the authoritative Missive mailboxes in the frozen 120-day window, independent of pipeline stage. Each included message must have exactly one proposed Activity result, full body and provider identities, and one verified Main CRM relation or an explicit unresolved disposition.
Historical work covered selected Instantly replies, but it did not prove all relevant Missive mailboxes, identity aliases, full bodies, or current Activity Log completeness.
The CRM can recommend outreach from incomplete history, split one company across addresses, and miss replies or payment evidence.
Main CRM becomes a trustworthy relationship index and Activity Log becomes a complete recent communication ledger.
Done: A no-write 120-day source manifest covers every message in the authoritative mailbox set and records qualifying or excluded status, exact exclusion reason, duplicate identity, proposed full Activity body, proposed CRM relation, proposed Other emails change, provider IDs, proposed Missive imported-to-activty-log tag, and one disposition from apply, exclude, defer, approved-no-match, or needs-review. Wise evidence proposes an invoice paid Activity only when invoice ID or payment reference is exact. Amount, currency, and date may suggest a review match but can never cancel reminders automatically. The manifest contains immutable source IDs, exact proposed payloads, per-row disposition, approver field, approval timestamp, expiry, and before-state hashes. The emails-to-N-activity-log skill is implemented and fixture-tested but not activated here. Its unmatched-contact notification uses subject Email with not CRM contact match and body fields sender email, date, subject, and body, including the new Activity item link. 80/20: Prioritize active pipeline contacts for early review while withholding any complete-120-day claim until every authoritative mailbox row has a final manifest disposition.
flowchart LR A[Fragmented email and identity] --> B[Exact once 120 day reconciliation] --> C[Trustworthy CRM history]
flowchart TD
S1[Freeze mailbox and Activity inventories with provider IDs]
S2[Define deterministic human email exclusions and tiered identity matching]
S1 --> S2
S3[Write red and green tests for dedupe aliases full bodies tags exact payment identity and ambiguity]
S2 --> S3
S4[Produce a no write delta immutable proposed payloads and disposition queue]
S3 --> S4
S5[Validate complete mailbox accounting and the approval ready manifest without applying it]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Create an easily invoked skill for one contact, a pipeline segment, or a reply queue that loads the complete relevant Activity history, meeting context, Calendar state, and Missive thread, then recommends no action, reply, follow-up, break-up, or task and creates an editable Missive draft when appropriate.
Earlier drafting used incomplete CRM fields, produced Gmail drafts outside the original thread and domain, and even drafted into a thread with an explicit do-not-contact instruction.
Suggested follow-ups remain unsafe, slow to review, and disconnected from the real conversation.
The user can invoke one skill and immediately receive a grounded, editable draft in the correct thread with the evidence and suppression reason visible.
Done: The skill resolves the exact CRM record, assembles relevant Activity, transcript, Calendar, and Missive context, applies hard no-contact and no-action gates, writes a draft in the original Missive thread/domain, records its link and state, and never sends automatically. A real owned-thread draft test and a hostile-thread negative test pass. 80/20: One-contact invocation produces a safe Missive draft or an evidence-backed no-action result with zero Gmail leakage.
flowchart LR A[Unsafe disconnected drafts] --> B[Full context Missive draft skill] --> C[Reviewable reply in the right thread]
flowchart TD
S1[Archive and inspect the existing canonical skills and mirrors]
S2[Define the contact resolution history suppression recommendation and draft seams]
S1 --> S2
S3[Add red tests for do not contact booked meeting alias wrong thread and Gmail leakage]
S2 --> S3
S4[Implement one contact and segment invocation with Missive draft only output]
S3 --> S4
S5[Verify owned thread continuity sender identity readback logs parity and devbox sync]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Extend the existing meeting-unification plan into one canonical Activity meeting lifecycle that supports the four exact Types, Calendar schedule identity, Fireflies and Wispr source sections, reschedule and cancellation history, and a 120-day copy-verify-cutover.
Meeting history is split between the legacy Call Recordings database and Activity Log, and the earlier plan uses a superseded Type and broader historical scope.
Smart drafts and CRM timelines can miss transcripts, duplicate meetings, or rely on two incompatible sources indefinitely.
Every meeting has one durable Activity page from scheduling through transcript completion, with source evidence preserved and legacy retirement objectively gated.
Done: T-004 owns the single meeting Type and ambiguity contract suite. Tests and a frozen 120-day manifest prove identity precedence, four-Type classification, ambiguous no-merge, explicit needs-review or approved-deferred disposition, Fireflies/Wispr arrival in either order, verbatim source preservation, lifecycle history, property/body/hash parity, rolling-tail parity, and zero new legacy writes after an explicitly approved cutover. Older legacy history remains readable. 80/20: Implement the canonical repository and dry-run manifest without changing live writers.
flowchart LR A[Dual meeting stores] --> B[Canonical Activity meeting lifecycle] --> C[Parity gated legacy retirement]
flowchart TD
S1[Rebase the existing meeting unification plan on the live schema and 120 day decision]
S2[Define immutable meeting identity four Types lifecycle and source section contracts]
S1 --> S2
S3[Add red and green tests for dual source order ambiguity cancellation and late transcript]
S2 --> S3
S4[Build the canonical repository and dry run migration manifest]
S3 --> S4
S5[Prove baseline and rolling tail parity before proposing writer cutover]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Route app-created and externally created Google Calendar or Meet events into the canonical Activity meeting lifecycle at schedule time, using synchronous writes for app bookings, event/API notifications as primary ingestion, and a complete checkpointed reconciliation path no slower than every 15 minutes.
Current booking and polling paths log legacy touchpoints, skip some internal or unmatched meetings, and do not prove complete event subscription or pagination.
Future meetings can remain invisible to the CRM until after the call or transcript, which weakens follow-up and reminder logic.
The Activity Log reflects upcoming commitments quickly and gives every downstream reminder and transcript one stable meeting identity.
Done: App booking, external create, patch, replace, cancel, pagination, checkpoint recovery, and duplicate-notification integration tests pass. T-005 sends normalized events into the T-004-owned classifier contract and proves one meeting_scheduled Activity per event. It does not maintain a second four-Type or ambiguity case matrix. The existing ten-minute poll is upgraded as the fallback when possible, with a last-success checkpoint and a 15-minute breach alert. 80/20: Make all new sales calls idempotently create meeting_scheduled Activities and prove the fallback detects one missed event.
flowchart LR A[Calendar events arrive late or incompletely] --> B[Event first ingestion and complete fallback] --> C[Meeting scheduled appears promptly]
flowchart TD
S1[Verify the authoritative calendars event subscription path and existing ten minute poll]
S2[Normalize create update replace cancel and Meet link identities]
S1 --> S2
S3[Reuse the T 004 classifier contract and add only create update cancel pagination and recovery integration tests]
S2 --> S3
S4[Implement synchronous app writes plus event first ingestion and checkpointed reconciliation]
S3 --> S4
S5[Verify owned event readback latency pagination dedupe and breach alerting]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Create the user-requested Scheduled Emails Notion database as a narrow business-state adapter over the existing send ledger and dispatcher. It relates to Main CRM and stores email type, source invoice or meeting, planned time, template version, Gmail identity, state, cancellation reason, and immutable idempotency key. It does not create a second generic repository or dispatcher. Add cancel-reminders-for-paid-invoices after the 03:00 email reconciliation.
Invoice reminders, sales-call reminders, and provider cancellation were described across several skills and schedulers without one durable intent and state model.
The system can duplicate reminders, lose cancellation state, or create Gmail scheduled messages that are difficult to revoke safely.
Every transactional message has a visible Notion record, deterministic lifecycle, provider receipt, and cancellation path that multiple workflows can reuse without sharing business semantics.
Done: The Scheduled Emails database and six invoice template definitions exist with a Main CRM relation and invoice reminder type. The adapter reuses the existing dispatcher and send ledger while exposing planned, claimed, attempted, accepted, delivered, failed, cancelled, and superseded states. It creates and verifies real Gmail scheduled messages when the authenticated Gmail capability supports them. If that capability is unavailable, the task stops with evidence instead of silently substituting a different provider. After emails-to-N-activity-log, cancel-reminders-for-paid-invoices cancels only on an exact invoice ID or payment reference, sets open Scheduled Emails rows to canceled-since-paid, deletes the matching unsent Gmail scheduled messages, and sets the Activity's reminders canceled checkbox true. Ambiguous or partial payments enter ambiguous_payment and cancel nothing. Cancellation wins against claim/send races in tests. 80/20: Build the Notion schema, narrow adapter, Gmail capability proof, idempotency, and cancellation tests without enabling customer sends.
flowchart LR A[Separate reminder intents] --> B[Shared Scheduled Emails control plane] --> C[Visible deterministic transactions]
flowchart TD
S1[Compare existing sequence reminder send ledger Gmail and Notion contracts]
S2[Define the minimal Scheduled Emails schema as an adapter over existing delivery primitives]
S1 --> S2
S3[Add red tests for duplicate claims cancellation races reschedule provider failure and readback]
S2 --> S3
S4[Implement only the Notion adapter and missing Gmail scheduling seam over the existing dispatcher]
S3 --> S4
S5[Create the six reviewed invoice templates and verify schema state Gmail scheduling exact payment matching and deletion fixtures]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Retire the ambiguous szamlazz-invoice invocation in favor of szamlazz.hu-create-invoice and szamlazz.hu-cancel-invoice, with schedule-invoice-reminder and cancel-reminders-for-paid-invoices subskills, Activity Log logging, Drive artifact handling, immediate Gmail delivery with the invoice PDF attached and Drive URL included, and precise factual ambiguity questions after invocation.
The current skill mixes lookup, invoice, proforma, cancellation, send, and reminder behavior without one explicit invoice identity and runtime-specific Activity Log update contract.
Invoice operations remain hard to invoke safely, can use the wrong document or period, and can create reminders or messages without a durable invoice identity.
One intentional create or cancel invocation has a clear legal recipient check, exact document result, Activity history, requested Gmail delivery, and deterministic reminder lifecycle.
Done: The old skill is archived and callers updated. Both new skills and both reminder subskills pass structural and fixture tests, ask factual ambiguity after invocation, require at least 96 percent recipient certainty, use the exact copy source the approved private invoice copy source, attach the invoice PDF, include the Drive URL, and send through the owner mailbox Gmail without a second approval once facts are resolved. Each create and cancel invocation delegates the bounded Activity Log update to Luna Max in Codex and Sonnet Medium in Claude Code, then deterministically validates the Notion readback. Unavailable required models fail closed rather than silently substituting. Mac Codex, Mac Claude, and devbox parity is proved. Cancel follows the reviewed storno-notification decision. 80/20: Produce the two narrow skill contracts, offline fixtures, and parity proof without invoking Számlázz.hu on a live client.
flowchart LR A[Ambiguous invoice skill] --> B[Narrow create cancel and reminder skills] --> C[Safe repeatable billing operation]
flowchart TD
S1[Load writing for agents mechanics and archive the canonical old skill]
S2[Trace and update every active caller before renaming or retirement]
S1 --> S2
S3[Write red fixtures for recipient period proforma invoice storno Drive URL Gmail attachment and send model specific Activity logging and reminders]
S2 --> S3
S4[Implement the two top level skills and schedule invoice reminder subskill]
S3 --> S4
S5[Verify no customer provider fixtures exact copy Gmail receipt runtime specific Activity logging Mac mirrors and devbox parity]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Implement exactly four automatic Universal Reminders for first and second sales calls, using the exact Budapest wall-clock and 69-minute rules, meeting-instance identity, reschedule versioning, cancellation, completion, and the Gmail-backed Scheduled Emails adapter.
The current system has three different reminder times, no durable first-versus-second eligibility field, and deal-level keys that can collide across multiple calls.
The requested reminder experience cannot be trusted, and rescheduling or a second sales call may suppress or duplicate the wrong messages.
Eligible prospects receive a predictable four-message cadence that follows the actual Calendar event and stops safely when the event changes or closes.
Done: T-008 owns tests for U1 at 3 days 15:45, U2 at previous day 10:32, U3 at same day 06:49, U4 at exactly 69 minutes, Budapest DST behavior, first/second-only eligibility, third-call exclusion, immutable meeting and schedule-version keys, future-slots-only late booking, reschedule, cancellation, and completion. Elapsed slots are never sent as catch-up. The T-006 contract suite owns duplicate claims, cancellation races, Gmail state, and provider failure, while T-008 retains one end-to-end failure fixture proving the meeting adapter propagates that state correctly. 80/20: Calculate and persist four correct slots for owned first and second sales-call fixtures, then prove cancel and reschedule without any real send.
flowchart LR A[Wrong reminder cadence and keys] --> B[Four meeting scoped Universal Reminders] --> C[Predictable first and second call reminders]
flowchart TD
S1[Define a durable sales call ordinal and reminder profile]
S2[Add red tests for all four times DST eligibility late booking reschedule and cancellation]
S1 --> S2
S3[Extend the existing reminder calculator and meeting scoped marker contract]
S2 --> S3
S4[Route sends through Scheduled Emails Gmail identity and the existing send ledger]
S3 --> S4
S5[Verify owned event fixtures future slots only behavior one representative delivery failure and zero third call reminders]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4
Prove the combined system on owned examples, quarantine the historical Gmail draft queue, compare every potential automation overlap by effect and durable key, then perform only the separately approved production migration, activation, and legacy retirement steps with rollback receipts.
Previous work claimed broad completion without one provider-grounded acceptance run, and several active, paused, historical, or overlapping runners remain hard to distinguish.
A technically correct component can still duplicate live work, send from the wrong surface, leave the CRM partially migrated, or make the old meeting store impossible to retire.
The user receives one verified operational system, one ownership map, a recoverable cutover, and clear evidence for every retained or retired automation.
Done: A golden-path pilot covers one pipeline reply, one no-contact negative case, one Gmail-delivered invoice with PDF attachment and Drive URL, one exact payment cancellation, one ambiguous-payment no-cancel case, one first sales call, one second sales call, one late-created call, one reschedule, one cancellation, one Fireflies/Wispr ordering case, and one unmatched sender. Missive thread/domain is verified for relationship drafts. Gmail send and scheduled-message identity is verified for transactionals. Notion readback, exact-once keys, reminder state, Calendar state, and delivery receipts pass. Before any legacy writer cutover, the 120-day manifests reach zero unsafe or unclassified rows. Every remaining row has an explicit apply, exclude, defer, approved-no-match, or needs-review disposition, and needs-review blocks cutover. Historical relationship-follow-up Gmail drafts are inventoried and quarantined. Every schedule/app retirement has owner, dependency, last-use, retention, and rollback proof. 80/20: Complete the owned pilot and present the cutover delta without changing production.
flowchart LR A[Components and runners lack one proof] --> B[Owned pilot and approval gated cutover] --> C[One verified operational system]
flowchart TD
S1[Freeze production and provider baselines and define one way cutover gates]
S2[Run the owned golden path and negative path acceptance matrix]
S1 --> S2
S3[Quarantine historical relationship follow up Gmail drafts and compare all overlap candidates by effect and key]
S2 --> S3
S4[Present the exact production delta rollback and human approval checkpoint]
S3 --> S4
S5[Apply only exact approved manifest and cutover payloads once reread every provider and retain receipts]
S4 --> S5
S5 --> D{Evidence complete}
D -- yes --> OUT[Verified outcome]
D -- no --> S4