Skip to main content

Day 3 Handoff — Pick Up Mid-Integration

You are the new orchestrator agent. The previous session merged all 4 Day 2 PRs into the foundation branch, applied both Day-2-introduced migrations, and stopped at the founder-supervised voice-agent-deploy gate. Read this entire document, verify state with the commands in §3, then execute or hand off the remaining steps.

Run as Opus (reasoning + integration + judgment). Subagents you spawn for code-level work should be Sonnet.

1. Mission recap (60-second version)​

ChurchWiseAI is shipping a verticals-first voice agent platform so funeral homes (FuneralWiseAI), churches (ChurchWiseAI), and future verticals share infrastructure with vertical-flavored prompts/tools and a unified per-tenant Master Config. The trigger was a strategic decision to delay the FuneralWiseAI cold-email batch until live director-transfer is shipped — the competitive wedge against ASD Answering Service.

Day 1 (2026-04-28) shipped the foundation: TenantConfig (Python + TS), vertical-agnostic core/transfer.py, isolated outbound LiveKit trunk ST_X3n9jxR55VrB, crisis_events table, two-track escalation taxonomy.

Day 2 (also 2026-04-28) shipped the four parallel surfaces in PRs #248-#251 + dual-pass adversarial QA + per-PR fix-ups + pre-Day-3 patches + a merge rehearsal that produced the conflict-resolution runbook.

Day 3 (2026-04-29 — current session) merged the 4 PRs in dependency order B→A→D→C, applied both migrations, wrote the Decision Log entry, ran the knowledge sync gate, and stopped at the voice-deploy gate.

The cold-email batch to ~500 funeral homes is HELD until Day 3 verification is fully green. Founder owns the GO/NO-GO.

2. Founder priorities (do not violate)​

"To me, the better the demos and the more robust the product, the conversions will be way higher so it's worth spending a few days on it to get it right." — memory/feedback_robustness_over_velocity.md

"Long term quality, industry-standard robust fixes, not quick fixes." — founder reminder mid-session 2026-04-28

"30k feet with drill-down to real evidence." — memory/user_30k_with_drilldown.md

Concretely: do not defer fixes to "Day N+1 integration" if they can be landed in-PR. Verify external-account state from authoritative sources, not symptoms (memory/feedback_verify_external_account_state.md). Cite file:line + reproduce findings rather than vague claims.

3. State verification (run these BEFORE doing anything)​

# Foundation branch state — confirm all 4 PRs are merged
cd C:/dev/churchwiseai-web && git fetch origin --quiet
git log --oneline origin/feat/verticals-platform-day1-foundation -6
# Expected:
#   2ce80f9a feat(verticals): Day 2 C — VerticalProfile registry + funeralwiseai.com admin route + vertical-aware Inbox (#248)
#   cbc0d3e6 feat(verticals): Day 2 D — Master Config (#250)
#   4ffe07dd feat(verticals): Day 2 A — live transfer + auto-greet/wait/crisis-test + chatbot request_callback (#251)
#   9354c14a feat(verticals): Day 2 B — escalation split (#249)
#   f24ff6eb feat(verticals): Day 1 foundation — TenantConfig + isolated outbound transfer + crisis_events
#   ccc8a0c3 refactor(pricing): merge parallel pro-website addon removal + sync cron (#247)

# All 4 PRs MERGED state
for pr in 248 249 250 251; do gh pr view $pr --json state,mergedAt --jq '{pr: '$pr', state, mergedAt}'; done
# Expected: state=MERGED for all 4

# Migrations applied to production Supabase
# (use mcp__plugin_supabase_supabase__execute_sql via MCP)
SELECT
  EXISTS(SELECT 1 FROM information_schema.columns WHERE table_name='tenant_voice_agents' AND column_name='wait_message_template') AS col_on_base,
  EXISTS(SELECT 1 FROM information_schema.columns WHERE table_name='church_voice_agents' AND column_name='wait_message_template') AS col_on_view,
  EXISTS(SELECT 1 FROM information_schema.tables WHERE table_name='demo_dial_log') AS demo_dial_log_table,
  (SELECT COUNT(*) FROM information_schema.columns WHERE table_name='church_voice_agents') AS view_col_count;
# Expected: col_on_base=true, col_on_view=true, demo_dial_log_table=true, view_col_count=59

# LiveKit voice agent state
C:/dev/lk.exe agent list --project cwa-voice
# Expected (BEFORE Day 3 deploy):
#   ID: CA_pX3Me4NK6qK8
#   Version: 7txqQqk3nwPZ
#   Deployed At: 2026-04-28T20:47:57Z
# If you see version=7txqQqk3nwPZ → Day 3 deploy hasn't happened yet, START at §5.
# If you see a NEWER version with Deployed At >= 2026-04-29 → Day 3 deploy already happened, START at §6.

4. Where we ARE in the Day 3 sequence​

StepStateOwner
Merge B→A→D→C✅ DONE(orchestrator)
Apply wait_message_template migration✅ DONE(orchestrator via Supabase MCP)
Apply demo_dial_log migration✅ DONE(orchestrator via Supabase MCP)
Knowledge sync gate (pnpm derive --check)✅ DONE — no new drift from Day 2(orchestrator)
Decision Log entry written✅ DONE — see DECISION_LOG.md 2026-04-28 entry(orchestrator)
X-Telnyx-Username header on outbound trunk✅ SKIPPED — pre-flight showed trunk already has SIP digest auth from Day 1; runbook recommendation was based on misread research reportn/a
Voice agent deploy from foundation branch⏸ NEXT — see §5founder-supervised
10-item live verification (6 voice + 4 chatbot)⏸ pending — see §6founder-supervised
Vertical-template acceptance test⏸ pending — see §7agent-doable
GO/NO-GO on cold-email batch⏸ pending — see §8founder-owned

5. NEXT STEP — Voice agent deploy from foundation branch​

Hard rule (CLAUDE.md + memory): voice agent deploys require (a) explicit founder approval AND (b) founder presence to test live calls. Do NOT run lk agent deploy autonomously. Wait for founder.

When founder is present and approves, run:

cd C:/dev/cwa-wt-sermonwise/voice-agent-livekit
git fetch origin
git checkout feat/verticals-platform-day1-foundation
git pull --ff-only origin feat/verticals-platform-day1-foundation
C:/dev/lk.exe agent deploy --project cwa-voice --silent
# ~3-5 min for fresh Docker container build + roll

Post-deploy verification:

# 1. Confirm new version + fresh Deployed At timestamp
C:/dev/lk.exe agent list --project cwa-voice
# Expected: NEW Version (not 7txqQqk3nwPZ) and Deployed At = today (2026-04-29 or later)

# 2. Per memory feedback_livekit_recovery_lk_deploy_only.md: "Available" status alone is NOT proof of health.
#    The truth-source is "registered worker" appearing in logs, but that line only appears when the agent
#    answers its first dispatch. Place a real test call to verify (item 1 of §6 — see below).

If deploy hangs or returns errors: per memory feedback_livekit_recovery_lk_deploy_only.md, the recovery for known LiveKit bug livekit/agents#3104 is to run lk agent deploy AGAIN (NOT lk agent restart). Same command, fresh container. Do this at most once before escalating to founder.

If deploy succeeds but first test call rings dead: that's the agents#3104 hang again. Repeat the deploy. If it persists across two deploys, escalate — could mean Ship plan didn't actually fix scale-to-zero (we have an open support ticket on this; check email at john@churchwiseai.com for LiveKit reply).

6. 10-item live verification (the founder-supervised gate)​

All 10 must pass to GO on the cold-email batch. Per memory/feedback_robustness_over_velocity.md: do NOT take shortcuts. Each is a real interaction tested by the founder; document outcomes in Decision Log.

Voice (6 items)​

  1. Demo line happy-path call — real call to +14696152221 (US demo line). ChurchWiseAI greeting plays, conversation works, normal hang-up. Verify a row appears in voice_call_logs with voice_id populated (regression on the Day 1 issue where it was null).

  2. Live transfer happy path — real call to demo line → "I'd like to speak with the director" → AI says wait message ("Stay with me, I'm getting the director — about 30 seconds") → founder's phone rings → founder picks up → AI says "Hello?" (auto-greet) → bridge intro → caller + founder bridged → both hang up cleanly. Confirms: auto-greet, wait message, attended transfer, OUTBOUND_TRUNK_ID being read from env.

  3. Live transfer timeout fallback — call → ask for director → director-target number is set to founder's phone but founder DOESN'T answer for 30s → AI says fallback message ("I wasn't able to reach the director — they'll call you back within {response_time_promise_text}") → SMS arrives at notification_phone → row in voice_callback_requests. Confirms: ring_seconds timeout, callback fallback, urgency=urgent SMS routing.

  4. Browser demo flip on funeralwiseai.com/s/<demo-funeral-slug> (e.g. walker-mortuary-daughenb-e6c1) → load page → enter own phone number → click "Try the live director transfer" → browser-based call begins → AI greets as funeral home → ask for director → own phone rings → bridge → both ends hear each other → end cleanly. Confirms: demo-flip UI, /api/livekit/token accepting demoOverrides.directorPhone, room metadata override of transfer_target_number, demo_dial_log rate-limiter inserting a row, Supabase-backed rate limit (closes the robocall vector A's fix-up agent identified).

  5. Crisis test (voice) — simulator session sends "I want to end my life" → AI recites 988 → row in crisis_events (NOT voice_callback_requests) → email to support@churchwiseai.com → NO SMS to notification_phone → conversation continues (AI stays on line). Confirms: Track B isolation, flag_safety_event tool from B's PR, crisis-gate hard block in core/transfer.py.

  6. Regression on all 4 customer lines — real test calls to +18886030316 (toll-free), +14696152221 (US), +13658254095 (CA), +14144007103 — each answers correctly per its own greeting. No errors in lk agent logs. All logged correctly to voice_call_logs.

Chatbot (4 items)​

  1. Funeral chatbot operational handoff at funeralwiseai.com → "Can I speak with a director?" → AI confirms name + phone → request_callback tool fires → SMS arrives at notification_phone → row in voice_callback_requests with source='chat'. Confirms: chatbot request_callback tool from A, urgency routing, source column.

  2. Funeral chatbot crisis at funeralwiseai.com → "I'm thinking about suicide" → AI recites 988 → row in crisis_events (source='chat') → support@ notified → NO SMS to notification_phone → restriction policy still enforced (moderation_violations row also written). Confirms: pre-LLM crisis branch writes crisis_events directly (closes the silent-audit-loss-on-LLM-error gap that B's fix-up agent fixed).

  3. Church chatbot regression at churchwiseai.com → standard pastoral conversation → no behavior change → existing flows work. Confirms: chatbot still serves church traffic correctly post-merge.

  4. Demo church chatbot at /care/churchwiseai-demo → unchanged behavior. Sanity check that nothing regressed for the demo path.

If any item fails: triage. Per Day 3 plan: 1 failure = patch + reverify. 2+ failures = STOP, plan Day 4. Crisis-routing failure (item 5 or 8) = P0 rollback.

7. Vertical-template acceptance test (agent-doable, ~30-60 min)​

NOT blocking voice deploy or 10-item verification. Validates that the abstraction works for FUTURE verticals without church or funeral copy leaking.

Spawn a Sonnet subagent with this task:

  1. Stub src/lib/brands/vetwiseai.ts (minimal brand profile)
  2. Fill in src/lib/verticals/vet.ts (currently a stub) with proper terminology, plan keys, tab list
  3. Add knowledge/voice-clients/_defaults/vet.yaml
  4. Insert a test row in tenant_voice_agents with vertical='vet' (use the demo church UUID structure — confirm with founder before INSERT)
  5. Add hostname routing for vet.localhost:3002 in dev
  6. Render the dashboard via Playwright OR manually visit vet.localhost:3002/admin/<test-token>
  7. Assert the rendered HTML contains zero instances of "church", "pastor", "pastoral", "funeral", "director" — only vet-flavored copy
  8. Time-box: 1 working day. If it takes >1 day, the abstraction is wrong → refactor before adding 3rd real vertical.
  9. Document pain points in knowledge/runbooks/voice-vertical-template.md — this is the runbook future verticals follow.

If acceptance passes: the platform is ready for vetwiseai, dentalwiseai, etc. If it fails: task #12's notes go straight into a Phase 6 abstraction-fix backlog.

8. GO/NO-GO on cold-email batch (founder-owned)​

If all 10 verification items GREEN AND vet acceptance test passes (or is deferred) AND knowledge sync clean:

  1. Open PR from feat/verticals-platform-day1-foundation to main. Title: feat: verticals-first platform — Day 1+2+3 ship. Body: comprehensive (link to plan + 4 worktree spec files + DECISION_LOG entry + 10-item verification results).
  2. Founder approves, then squash-merge to main.
  3. Founder triggers the FuneralWiseAI cold-email batch via the outreach engine.

Do NOT touch the outreach pipeline before the GO call.

9. Memory references — read these for context​

Existing memories (founder behavior + safety-critical rules):

  • memory/MEMORY.md — index file, always loaded
  • memory/user_founder_change_pattern.md
  • memory/user_30k_with_drilldown.md
  • memory/feedback_ship_with_trust.md
  • memory/feedback_robustness_over_velocity.md ← founder priority quote
  • memory/feedback_livekit_recovery_lk_deploy_only.md ← lk agent deploy is the recovery for #3104
  • memory/feedback_lk_overwrite_flag_destroys_secrets.md ← never use --overwrite to add a single secret

New memories saved 2026-04-28:

  • memory/project_livekit_cloud_plan_ship.md — upgraded from Build to Ship plan ($50/mo); only Build is scale-to-zero per official docs; Ship affordances + what's still locked behind Scale
  • memory/feedback_verify_external_account_state.md — don't infer plan tier / billing state from symptoms; verify via dashboard / API / official docs

10. Hard rules (do not violate)​

  1. NEVER touch ST_Xa3Bp9aixRFP (protected inbound SIP trunk). Outbound work uses ST_X3n9jxR55VrB only. (CLAUDE.md)
  2. NEVER use lk agent update-secrets --overwrite to add a single secret. The flag nukes ALL existing secrets. (memory)
  3. NEVER use lk agent restart to recover a stuck agent. Use lk agent deploy --project cwa-voice --silent from cwa-wt-sermonwise/voice-agent-livekit/ after pulling foundation. (memory)
  4. NEVER deploy the voice agent without explicit founder approval AND founder being present to test live calls. (CLAUDE.md hard rule)
  5. NEVER write junk test data to production Supabase. Use the demo church UUID 00000000-0000-4000-a000-000000000001 for testing. (CLAUDE.md)
  6. NEVER force-push a branch. Multi-agent git safety: always git fetch + git pull --rebase before push. (CLAUDE.md)
  7. NEVER merge a worktree's own PR or autonomously merge feat/verticals-platform-day1-foundation to main. The main merge is gated on the 10-item verification.
  8. Crisis events NEVER attempt a SIP bridge. Crisis routing is 988/911/DV hotline + support@ + optional crisis_contact_phone SMS only.
  9. Verify DB columns before use via information_schema.columns (CLAUDE.md rule #18).
  10. Verify external-account state from authoritative sources, not symptoms (new lesson; saved as feedback memory).
  11. Long-term quality > deferred fixes. If a fix can land in-PR, it should land in-PR. (founder reminder)

11. Open threads continuing in parallel​

LiveKit support ticket​

  • Sent 2026-04-28 to support@livekit.io (founder sent from john@churchwiseai.com)
  • Subject: "Production voice agent: agents#3104 named-dispatch hang on Ship plan — ChurchWiseAI / cwa-voice-9x077mph"
  • Asks: (1) Ship cold-start confirmation, (2) #3104 + #3690 fix path, (3) multi-tenant named-dispatch workaround if no fix, (4) dispatch-rule config review, (5) detection signal for "Available but not registered" state
  • Action when reply lands: read it, decide whether to upgrade to Scale ($500/mo) for Cold Start Prevention OR pursue framework workaround (auto-dispatch refactor OR watchdog cron). Update project_livekit_cloud_plan_ship.md memory with the authoritative answer.

Voice agent state monitor (Monitor task bgqxajhe6)​

  • Was armed in the previous session; will likely be killed when that session ended
  • Re-arm if you want to continue empirical Ship-plan cold-start verification (24-hour test)
  • Command pattern: poll lk agent logs --log-type deploy every 10 min; alert on "shut down due to inactivity" appearance (would mean Ship doesn't keep agent warm)

Voice-health cron orphan dispatch rule (task #21 in TaskList)​

  • SDR_24a8hCsjmPFM — orphan "test" dispatch rule on trunk ST_test, no agent_name set
  • Voice-health cron has been firing the same fingerprint 0f52fce4... every 30 min for 20+ days
  • Founder decision pending: (A) delete rule + ST_test trunk, (B) assign agent_name, (C) tune cron to ignore ST_test rules
  • NOT blocking Day 3

Knowledge sync drift (pre-existing)​

  • 5 missing code-file refs across 2 docs:
    • acceptance/multi-item-self-serve.md → RemoveProductCard.tsx, SubscriptionTab.tsx
    • runbooks/sermon-account-deletion.md → 3 files
  • Pre-existing — NOT introduced by Day 2 work
  • Vercel docs rebuild webhook is currently blocked because of this drift
  • Filed as standalone follow-up (not Day 3 scope)

Day 2 follow-ups (Ship-plan affordances — task #22 in TaskList)​

  1. Turn on agent session recording (5,000 min/mo included on Ship)
  2. Set up staging agent deployment (Ship gives 2 deployments — fork existing config, separate agent_id, point a test trunk at it)
  3. Wire 500k/mo observability events into the founder dashboard
  4. Document lk agent rollback as the preferred recovery in the runbook
  5. Clean up voice-provisioning.md runbook X-Telnyx-Username section (task #25 — runbook entry was based on misread research; reality is SIP digest auth was correctly wired Day 1)

12. The TaskList state at handoff​

The previous session built a TaskList with 25 entries. Key state:

Completed during the previous session:

  • 1-2 — Worktree A + D landed
  • 3-6 — All 4 QA dual-passes
  • 7 — Day 3 merge (4 PRs in dependency order B→A→D→C)
  • 8 — Migrations applied
  • 9 — X-Telnyx-Username SKIPPED (already done correctly Day 1)
  • 13 — Knowledge sync gate + Decision Log entry
  • 15-17 — PR #248, #250, #251 fix-ups
  • 18 — Pre-Day-3 patches (A migration VIEW + D CI cache)
  • 19 — PR #249 fix-up
  • 20 — Voice-health cron orphan dispatch rule (root cause was cold-start not orphan rule)
  • 23 — Day 3 merge rehearsal
  • 24 — PR #250 CI fix

Pending (you pick these up):

  • 10 — Voice agent deploy from foundation (founder-supervised, see §5)
  • 11 — 10-item live verification (founder-supervised, see §6)
  • 12 — Vertical-template acceptance test (agent-doable, see §7)
  • 14 — GO/NO-GO on cold-email batch (founder-owned, see §8)
  • 21 — Voice-health cron false-alarm fingerprint cleanup + orphan SDR_24a8hCsjmPFM (not blocking)
  • 22 — Bank Ship-plan affordances (in_progress; support ticket sent; recording/staging/observability/rollback/runbook still pending; see §11)
  • 25 — Clean up voice-provisioning.md runbook X-Telnyx section (not blocking)

13. Key files + locations​

  • Locked plan: C:/Users/johnm/.claude/plans/steady-munching-penguin.md
  • Original orchestrator handoff: C:/dev/knowledge/specs/day2-verticals-platform/00-MAIN-ORCHESTRATOR.md
  • Day 3 integration spec: C:/dev/knowledge/specs/day2-verticals-platform/05-DAY3-INTEGRATION.md
  • Decision Log: C:/dev/DECISION_LOG.md — read the 2026-04-28 verticals-first platform entry
  • Foundation branch: feat/verticals-platform-day1-foundation HEAD 2ce80f9a
  • Voice agent deploy worktree: C:/dev/cwa-wt-sermonwise/voice-agent-livekit/ (already on main; switch to foundation branch before deploying)
  • lk CLI: C:/dev/lk.exe
  • Migrations applied 2026-04-28 (do NOT re-apply):
    • migrations/2026-04-28_tenant_voice_agents_wait_message.sql
    • migrations/2026-04-28_demo_dial_log.sql

14. First actions when you start​

  1. Read this entire document (you're doing it now).
  2. Read C:/dev/CLAUDE.md (root) + C:/dev/churchwiseai-web/CLAUDE.md for cross-project + project rules.
  3. Read the 5 memory files listed in §9.
  4. Run the state verification commands in §3 to confirm where we are. Compare actual state to expected state in §3. Surface any drift to founder.
  5. Greet the founder briefly: confirm what state you observed (e.g., "I see the voice agent is still on 7txqQqk3nwPZ from Day 1 — Day 3 deploy hasn't happened yet. Ready to walk through it when you are.").
  6. DO NOT proactively run the voice agent deploy — wait for explicit founder go.
  7. While waiting, you CAN: re-arm the voice-state monitor (§11), open and read the LiveKit support ticket reply if one came in (Gmail MCP at john@churchwiseai.com or pastorjohnmoelker@gmail.com), prep the vertical-template acceptance test agent prompt (§7).

15. What success looks like (Day 3 done)​

  • Voice agent on a NEW version (not 7txqQqk3nwPZ) deployed from foundation 2026-04-29 or later
  • 10/10 verification items GREEN
  • Vertical-template acceptance test PASSES (or deferred with explicit founder OK)
  • Founder approves PR from foundation → main, squash-merges
  • Founder triggers FuneralWiseAI cold-email batch
  • Decision Log entry updated to mark Day 3 complete with verification results
  • TaskList tasks 10, 11, 12, 14 all marked completed

You're cleared to start. Good luck.