0 of 9 decided

Review — CRM Activity Log, smart drafts, meetings, and reminders

Plan: /Users/agency/Documents/Agty/GHL funnel/action-plans/2026-08-17-crm-activity-log-smart-drafts-and-reminders.md

How to review this

What the current map says

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 plan converges those paths around one Activity timeline, Missive-first relationship drafts, and a narrow transactional scheduler.

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.

T-001 — Freeze the live contracts and execution baseline

Undecided
Task

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.

Problem solved

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.

Cost of inaction

Builders may modify the wrong revision, duplicate an existing runner, retire a still-owned app, or claim a provider outcome from static code.

Benefit

Every later task starts from the same verified system boundary and knows which unknowns require a gate instead of an assumption.

Done

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
Open questions
Decision

T-002 — Reconcile human email and CRM identity for 120 days

Undecided
Task

Make the existing real-time email ingestion and an emails-to-N-activity-log reconciliation skill on the existing 03:00 daily surface jointly prove that every relevant human email in the frozen 120-day window exists exactly once in Activity Log, retains its full body and provider identities, and relates to one verified Main CRM record.

Problem solved

Historical work covered selected Instantly replies, but it did not prove all relevant Missive mailboxes, identity aliases, full bodies, or current Activity Log completeness.

Cost of inaction

The CRM can recommend outreach from incomplete history, split one company across addresses, and miss replies or payment evidence.

Benefit

Main CRM becomes a trustworthy relationship index and Activity Log becomes a complete recent communication ledger.

Done

Done: A 120-day source manifest reconciles qualifying messages, exclusions, duplicates, full bodies in the Activity page notes, CRM relations, an Other emails multi-select property, unresolved identities, provider IDs, and Missive imported-to-activty-log tags after Notion readback. The emails-to-N-activity-log skill runs as reconciliation after the primary live lanes, ignores warmup, promotions, reports, and other evidenced non-human mail, and records Wise payment messages as invoice paid Activities with reminders canceled initially false. When no safe CRM or company match exists, it emails the owner mailbox with subject Email with not CRM contact match and body fields sender email, date, subject, and body, including the new Activity item link. 80/20: Prove exact-once coverage for all active pipeline contacts and every untagged human message, with ambiguity queued instead of guessed.

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 and Wise payment events]
  S2 --> S3
  S4[Produce a no write delta snapshot and unresolved queue]
  S3 --> S4
  S5[Apply only approved additive repairs and reread Notion and Missive metadata]
  S4 --> S5
  S5 --> D{Evidence complete}
  D -- yes --> OUT[Verified outcome]
  D -- no --> S4
Decision

T-003 — Build the Missive-first smart relationship draft skill

Undecided
Task

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.

Problem solved

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.

Cost of inaction

Suggested follow-ups remain unsafe, slow to review, and disconnected from the real conversation.

Benefit

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

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
Decision

T-004 — Unify scheduled meetings and transcripts in Activity Log

Undecided
Task

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.

Problem solved

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.

Cost of inaction

Smart drafts and CRM timelines can miss transcripts, duplicate meetings, or rely on two incompatible sources indefinitely.

Benefit

Every meeting has one durable Activity page from scheduling through transcript completion, with source evidence preserved and legacy retirement objectively gated.

Done

Done: Tests and a frozen 120-day manifest prove identity precedence, four-Type classification, ambiguous no-merge, 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
Decision

T-005 — Log every Calendar event as meeting scheduled

Undecided
Task

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.

Problem solved

Current booking and polling paths log legacy touchpoints, skip some internal or unmatched meetings, and do not prove complete event subscription or pagination.

Cost of inaction

Future meetings can remain invisible to the CRM until after the call or transcript, which weakens follow-up and reminder logic.

Benefit

The Activity Log reflects upcoming commitments quickly and gives every downstream reminder and transcript one stable meeting identity.

Done

Done: App booking, external create, patch, replace, cancel, internal, client-status, unmatched, pagination, checkpoint recovery, and duplicate notification tests pass. 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[Add red and green tests for all four meeting Types and ambiguous classification]
  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
Decision

T-006 — Build the shared Scheduled Emails control plane

Undecided
Task

Create one Scheduled Emails control plane related to Main CRM, with email type, source object, provider thread, planned time, template version, state, provider identity, cancellation reason, and immutable idempotency key, while reusing the existing send ledger and dispatcher patterns. Add cancel-reminders-for-paid-invoices after the 03:00 email reconciliation.

Problem solved

Invoice reminders, sales-call reminders, and provider cancellation were described across several skills and schedulers without one durable intent and state model.

Cost of inaction

The system can duplicate reminders, lose cancellation state, or create provider-scheduled messages that are difficult to revoke safely.

Benefit

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

Done: The Scheduled Emails database and six invoice template definitions exist with a Main CRM relation and invoice reminder type. State transitions cover planned, claimed, attempted, accepted, delivered, failed, cancelled, and superseded. The dispatcher sends at due time through the intended provider thread. After emails-to-N-activity-log, cancel-reminders-for-paid-invoices matches each new invoice paid Activity to one invoice, sets open Scheduled Emails rows to canceled-since-paid, cancels any provider intent that still exists, and sets the Activity's reminders canceled checkbox true. Cancellation wins against claim/send races in tests. 80/20: Build the schema, local repository, idempotent dispatcher, 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 and Notion contracts]
  S2[Define the minimal Scheduled Emails schema and state machine]
  S1 --> S2
  S3[Add red tests for duplicate claims cancellation races reschedule provider failure and readback]
  S2 --> S3
  S4[Implement the repository and dispatcher using existing low level primitives]
  S3 --> S4
  S5[Create the six reviewed invoice templates and verify schema state and provider thread fixtures]
  S4 --> S5
  S5 --> D{Evidence complete}
  D -- yes --> OUT[Verified outcome]
  D -- no --> S4
Decision

T-007 — Replace the Számlázz.hu create and cancel skills

Undecided
Task

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, Missive-thread transactional delivery, and precise ambiguity questions after invocation.

Problem solved

The current skill mixes lookup, invoice, proforma, cancellation, draft, send, and reminder behavior and previously routed client messages through Gmail instead of the intended Missive thread.

Cost of inaction

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.

Benefit

One intentional create or cancel invocation has a clear legal recipient check, exact document result, Activity history, same-thread delivery, and deterministic reminder lifecycle.

Done

Done: The old skill is archived and callers updated. Both new skills and the reminder subskill pass structural and fixture tests, ask factual ambiguity after invocation, require at least 96 percent recipient certainty, use the approved template source, write one Activity event through a Luna Max or Claude Sonnet Medium subagent contract, and achieve Mac Codex, Mac Claude, and devbox parity. Create does not ask a separate send approval after facts are resolved. Cancel follows the reviewed client-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 thread 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 Activity logging contract Mac mirrors and devbox parity]
  S4 --> S5
  S5 --> D{Evidence complete}
  D -- yes --> OUT[Verified outcome]
  D -- no --> S4
Open questions
Decision

T-008 — Add four Universal Sales Call reminders

Undecided
Task

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 provider-thread delivery.

Problem solved

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.

Cost of inaction

The requested reminder experience cannot be trusted, and rescheduling or a second sales call may suppress or duplicate the wrong messages.

Benefit

Eligible prospects receive a predictable four-message cadence that follows the actual Calendar event and stops safely when the event changes or closes.

Done

Done: Tests prove 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, no catch-up storm, reschedule, cancellation, completion, duplicate sweep, and provider failure recovery. 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 Missive thread identity and the send ledger]
  S3 --> S4
  S5[Verify owned event fixtures race handling delivery states and zero third call reminders]
  S4 --> S5
  S5 --> D{Evidence complete}
  D -- yes --> OUT[Verified outcome]
  D -- no --> S4
Open questions
Decision

T-009 — Run the controlled pilot, cutover, and automation cleanup

Undecided
Task

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.

Problem solved

Previous work claimed broad completion without one provider-grounded acceptance run, and several active, paused, historical, or overlapping runners remain hard to distinguish.

Cost of inaction

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.

Benefit

The user receives one verified operational system, one ownership map, a recoverable cutover, and clear evidence for every retained or retired automation.

Done

Done: A golden-path pilot covers one pipeline reply, one no-contact negative case, one invoice with payment cancellation, one first sales call, one second sales call, one reschedule, one cancellation, one Fireflies/Wispr ordering case, and one unmatched sender. Provider thread/domain, Notion readback, exact-once keys, reminder state, Calendar state, and delivery receipts pass. The 120-day manifest reaches zero unresolved rows before any legacy writer cutover. Historical 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 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 approved cutover steps once reread every provider and retain receipts]
  S4 --> S5
  S5 --> D{Evidence complete}
  D -- yes --> OUT[Verified outcome]
  D -- no --> S4
Open questions
Decision