VP LLC Build — Complete the Build + End-to-End Test

Objective: Finish every buildable item in Vision Play LLC (AeLkfZi8pLeWwG9xxGmt), enroll a test contact, verify live SMS/email delivery to a real handset for each workflow, then publish every workflow whose content is fully resolved — leaving a clean punch-list of only the items genuinely blocked on Akash (video URLs, ConvoAI router, review/referral links).

What changed from the prior plan

The prior pass was report-only (reconfirm the build vs the published build-plan page). Paul's note — "complete the build and test end to end" — flips it to execution. The 2026-09-07 audit already confirmed the spine is solid (all 12 workflows assembled, triggers bound, pipelines/tags/foundation resolve, WF 7 legacy defect already fixed, WF 7.1 design change applied, booking link resolved in WF 1.1). So this plan does not re-audit; it closes the audit's PENDING list, runs the live delivery test that was NOT-TESTED, publishes what is clear, and isolates the BLOCKED items so nothing false is marked live. This is a write build — VisionPlay rule 0 approval gate applies: nothing gets written until Paul approves this plan.

Sources of truth (confirmed live 2026-09-07)

Account AeLkfZi8pLeWwG9xxGmt (Vision Play LLC own sub-account). Confirm active before every write batch (rule 2).
VP v2 folder 764f790b = 11 draft workflows + WF 7 982f33a1 (published, trigger correct).
FRS pipeline JLt0xNPGyRuVFzd6uK85 (8 stages; "Client Won" 4cba2f36). Client Onboarding pipeline j6gx6BZlwGabztOyTZky (4 stages).
37 tags exist; 8 core trigger tags confirmed. A2P approved, 786 number provisioned (+1 786-420-6584). Booking link https://calendar.app.google/S1Q23g9GybwoErwr8.

The Plan

Phase 1 — Close the buildable PENDING items (writes)

WF 7.0 Referral Ask (bb074e54) — rewrite referral copy. Current SMS copy is a generic ask. Rewrite the SMS steps to state the 5-tier, two-sided ladder explicitly: 1 referral → 1 month free · 3 → steak dinner · 10 → Four Seasons spa · 20 → Bahamas trip · Partnership tier (terms TBC by Akash) — and add the two-sided line: referred party gets waived setup fee. Apply via MCP get_workflow → auto_save_workflow (SMS content under body, preserve version + triggersChanged:false). Leave [REFERRAL_LINK] as-is (Akash-gated — see Phase 4).
WF 5.0 Pre-Call Primer (e0ed8f42) — add the 30-min-before-call confirmation SMS. This is appointment-relative (wait = "30 min before appointment"), which the API cannot write — build it on the GHL builder canvas via playwright-visionplay (new tab only, never touch pinned tabs). Add: appointment-relative wait step → SMS confirmation. Verify the step renders on canvas (API read-back is not sufficient per feedback_ghl_api_readback_is_not_verification).
WF 1.2 Event QR Scan (762ab6a1) — resolve the static-email decision. Per the build plan, the Day-4/Day-8 static emails are meant to be replaced by the ConvoAI router (unbuilt, Akash-blocked). Recommendation: KEEP the static Day-4/Day-8 cadence as a working fallback so WF 1.2 can function now; wire the ConvoAI hand-off later when Akash delivers the phrase/objection maps. (Decision flagged in Risks — proceeding on "keep as fallback" unless Paul says strip.)
Confirm WF 1.1 booking link is applied. Audit says resolved; re-read the Day-5 SMS to confirm https://calendar.app.google/S1Q23g9GybwoErwr8 is in place, not a placeholder.

Phase 2 — Wire real lead intake (writes)

Build the New Inquiry form so real leads actually flow into WF 1.1 (currently tag-trigger only, no form feeds lead-new-inquiry). Create a native GHL form (Full Name, Phone [required], Email [required], TCPA consent [terms_and_conditions, required]) in AeLkfZi8pLeWwG9xxGmt, set the on-submit to add tag lead-new-inquiry (via a form-submission action or a thin WF that tags on submit). Verify submitting the form applies the tag and enrolls WF 1.1. Embed/host per Paul's call (VP LLC funnel page or standalone) — flag if a page is needed.

Phase 3 — End-to-end delivery test (the core of "test end to end")

Create ONE test contact (Paul's real mobile + a test email he supplies) in AeLkfZi8pLeWwG9xxGmt. Use a clearly-named test contact so it is easy to delete.
Temporarily publish + fire each workflow whose content is resolved, one at a time, and confirm the SMS/email actually lands on the handset/inbox (not just a 200 — per feedback_verify_live_send_before_bulk_enroll). Trigger each by its real mechanism:

WF 1.1 — submit the new inquiry form (Phase 2) → expect welcome SMS + booking link.
WF 1.3 Missed Call Text-Back (4d0e1998) — place a missed call to the 786 number → expect text-back.
WF 3.1 Onboarding 21-Day (029b4a78) — move test opp to FRS "Client Won" (4cba2f36) → expect Day-0 onboarding send.
WF 4.1 Check-In (9f8bab87) — add tag onboarding-complete → expect send.
WF 5.0 Pre-Call Primer (e0ed8f42) — book a test appointment (status confirmed) → expect primer + the new 30-min SMS.
WF 6.0 Cold Reactivation (71afa542) — add tag lead-cold-no-response → expect first reactivation SMS.
WF 2.1 Discovery No-Show (75d57c5e) — mark a test appointment no-show → expect no-show sequence.
WF 7.1 Community Invite (42a2ba88) — move test opp to "Client Won" → confirm it fires alongside WF 3.1 (verify the intended double-fire, not a collision).

Record per workflow: trigger fired ✓, message delivered to handset ✓, content correct ✓. Any failure → fix and re-test (do not mark tested on a 200 alone).
Tear down the test: delete the test contact/opportunity/appointment and set back to draft any workflow that should not stay live (see Phase 4). No test artifacts left in the account.

Phase 4 — Publish what is clear; isolate what is Akash-blocked

Publish (leave live) the workflows with fully-resolved content and passed delivery test: WF 1.1, WF 1.3, WF 3.1, WF 4.1, WF 5.0, WF 6.0, WF 2.1, WF 7.1 — subject to Paul's go-ahead per workflow. (These carry no unfilmed-video dependency.)
Hold in draft (content-gated), with the exact blocker named:

WF 4.2 Review Request (677d68f0) — needs real [REVIEW_LINK] (Akash/Nathania). Copy + delivery testable, but do not publish with a placeholder link.
WF 7.0 Referral Ask (bb074e54) — copy now complete (Phase 1) but needs real [REFERRAL_LINK] before publish.
WF 1.2 Event QR Scan (762ab6a1) — static fallback works, but the 12-video matrix + ConvoAI routing are unfilmed/unbuilt. Publish the fallback only if Paul wants QR live before video; otherwise hold.

Build Primitives (changed/created this pass)

New form: "VP LLC New Inquiry" — Full Name, Phone (req), Email (req), TCPA consent (terms_and_conditions, req). On-submit applies tag lead-new-inquiry.
Tags: no new taxonomy — reuse existing lead-new-inquiry, onboarding-complete, lead-cold-no-response, event-qr-scan.
Test contact: one temporary contact (Paul's mobile + test email), deleted at end of Phase 3.

Workflows (touched this pass)

WF 7.0 Referral Ask — Trigger: tag onboarding-complete (+30-day wait, unchanged) · Action: rewrite SMS to 5-tier two-sided ladder · Gate: [REFERRAL_LINK] (Akash).
WF 5.0 Pre-Call Primer — Trigger: appointment status confirmed · Action: ADD appointment-relative (30-min-before) confirmation SMS on canvas.
WF 1.2 Event QR Scan — Decision applied: keep static Day-4/Day-8 emails as fallback; ConvoAI hand-off deferred.
WF 1.1 New Lead Inquiry — Now fed by the new inquiry form (tag lead-new-inquiry); booking link confirmed.
WF 1.3 / 2.1 / 3.1 / 4.1 / 6.0 / 7.1 — no content change; publish after passing the live delivery test.

Definition of Done

WF 7.0 SMS copy contains the full 5-tier ladder + two-sided (waived-setup-fee) line; read-back confirmed under body.
WF 5.0 30-min-before-appointment confirmation SMS visible on the GHL builder canvas (screenshot-verified, not just API).
WF 1.2 static-email decision applied (keep-as-fallback, unless Paul overrides).
New Inquiry form live; a test submission applies lead-new-inquiry and enrolls WF 1.1.
Every listed workflow passed a real delivery test: trigger fired → message landed on Paul's handset/inbox → content correct. Per-workflow pass/fail recorded.
Test contact + all test artifacts deleted from AeLkfZi8pLeWwG9xxGmt.
WF 1.1, 1.3, 3.1, 4.1, 5.0, 6.0, 2.1, 7.1 published (per Paul's per-workflow go-ahead); WF 4.2, 7.0, 1.2 held in draft with the exact blocker named.
Closing punch-list states, for each of the 12 workflows: Live / Held (why) / Blocked-on-Akash (what) — no workflow reported live that still carries a placeholder link or unfilmed video.

Risks & decisions

Approval gate (rule 0): this is a write build. No object is created/edited/published until Paul approves this plan. The MCP allowlist is capability, not permission.
Live publish + test on a real account. The test enrolls a real contact and sends real SMS/email. Test to Paul's own handset only — no client or third-party numbers. A2P is approved so sends are legal; still keep the test contact singular and delete it after.
Genuine hard blockers (cannot be completed this pass — Akash/Focus required): all 12 video URLs (library unfilmed), the ConvoAI Video Router (needs Akash's phrase-to-video + objection-to-video maps), the post-call objection matrix, and the [REVIEW_LINK] / [REFERRAL_LINK] URLs. "Complete the build" therefore means complete everything not gated on these; these stay a named punch-list, not silently marked done.
WF 1.2 decision needed: proceeding on "keep static Day-4/Day-8 as fallback." If Paul wants them stripped in favor of waiting for ConvoAI, say so before Phase 1.
Quadruple-fire on onboarding-complete / "Client Won" (WF 3.1, 4.1, 4.2, 7.0, 7.1): the E2E test must confirm the intended cadence (immediate vs 30-day wait, and the intended WF 3.1 + 7.1 simultaneous fire on "Client Won"), not an accidental collision — surface to Paul if the test shows overlap he did not intend.
WF 7 (982f33a1) is published and untouched — trigger already correct (survey MKBskfCwsyQ1RxukWhlk). Do not edit.
Publish is per-workflow, on Paul's go-ahead. Recommend publishing the 8 clear workflows only after each passes its delivery test; hold the 3 content-gated ones.
Browser hygiene: all canvas/form/booking work via playwright-visionplay in a NEW tab; never navigate, click, or close Paul's pinned tabs.