Goal: One standard modular snapshot we load for every client — a core that's always on, optional modules shipped as drafts we toggle per client, cruft removed. Built so every account is identical and we can sync canonically.

Full report + build plan: https://firerock-subaccount-audit.pages.dev/snapshot.html (Standard Snapshot tab)

Folder structure

01 · Core — Lead Capture 02 · Core — Reviews 03 · Core — Utility 10 · Optional — Appointments 11 · Optional — Nurture 12 · Optional — Calls 13 · Optional — Ads & Tracking 14 · Optional — Reviews+

CORE (publish on load)

Workflows: All Leads Captured → Tag Sources → GA4 Events · Forms → Create Opportunity → Auto Response · Forms → GA4 → Add Tags → Send Notification · Review Requests · Mark All As Read Pipelines: Main (New Lead) · Fixed (9-stage sales) Custom values: GA4 Measurement ID · GA4 API Secret Custom fields: Service Requested · Referred By · Referrer Email Calendar: Discovery Call with {{location.name}} Tags: source / review-sequence / lost reason taxonomy · Google Review link

MODULAR (draft, prefix [OPT], toggle per client)

Appointment Reminders (confirmation + no-show rebooking) · Inbound Nurture (Day 1–3, 5-Week) · Incoming Call → Tag · Facebook Lead Form / Messenger Tag · Lead Engagement Meta Conversion API · Review Request With Intent Check · Google Review Campaign – Past Clients

STRIP

LinkedIn/ICP ScoreCard custom fields + ScoreCard form Duplicate fields (Website, State, City, Email, Phone) Lead Engagement pipeline (fleet uses Main + Fixed)

Build steps

Clone Z Automation Snapshot to a fresh account: FireRock Standard v1 Strip the cruft (above) Create the 8 folders; move + rename the 13 workflows to canonical names Publish the core 5; keep modules as [OPT] drafts Per-client activation runbook (toggle by client capability) Save as agency snapshot FireRock Standard v1; smoke-test from a throwaway sub-account Roll into onboarding (load → set GA4 IDs + calendar owner + phone → toggle modules → publish)

Naming / sync

Core folders publish on load; optional stay draft. Names are the contract — the audit sweep diffs every account against this spec to flag drift. Versioned (v1 → v1.1); client-specific work lives outside Core folders so it is never overwritten.

I have complete context. The task spec is self-contained, and the project files confirm the account IDs, snapshot mechanics, API surface (including the Cloudflare bot-wall constraint that forces browser-side execution for services.* writes), and the standing "verify location identity before writes" rule. The MCP read needed a permission grant that isn't available in this headless run, so the source→canonical workflow mapping is proposed from the spec and flagged for live reconciliation against the already-built audit data.

Here is the complete build plan.

Build FireRock Standard v1 — Canonical Snapshot Structure

Objective: Produce one modular agency snapshot ("FireRock Standard v1") with an always-on core (published) and toggleable optional modules ([OPT] drafts), built in a dedicated build sub-account, stripped of cruft, canonically named, then saved and smoke-tested so every future client account is identical and diffable against the spec.

Steps

0. Reconcile the source→canonical mapping (read-only, do first)

1. Confirm identity of the MCP-scoped location HMm03ltwkS40J4YWI0De before any write (standing rule feedback_verify_mcp_scope_before_writes). Determine whether it is meant to be the new build account or an existing client account. Do NOT write to it until confirmed.
2. Pull the live source inventory from Z Automation Snapshot dSBv9R8HBSsGUiAh0GEo (list_workflows, tags, pipelines, custom fields/values, calendars, forms) — or reuse audit/all-subaccounts.json + audit/workflow-maps.json already generated. Build the exact source-name → canonical-name table for all 13 workflows before touching anything. The audit report's "Standard Snapshot" tab (firerock-subaccount-audit.pages.dev/snapshot.html, gated paulai/paulai26) is the canonical spec.

1. Create the build account

1. Create a new sub-account "FireRock Standard v1 [BUILD]" via POST backend.leadconnectorhq.com/locations/ with prospectInfo.snapshotId = the current live boilerplate cZeuZimeVcxKsVq1VAxd (FireRock 4.x, the version 14 clients run), isAgencySubAccount:false, status:"account" (payload shape per ghl-api-reference.md lines 100–125). This gives an editable working copy of today's canonical state. Wait for async snapshot load to finish, then verify counts match the source.

2. Strip the cruft (build account only — never a client account)

1. Delete LinkedIn / ICP ScoreCard custom fields and the ScoreCard form.
2. Delete duplicate custom fields only: any custom "Website / State / City / Email / Phone" fields that duplicate GHL STANDARD fields. Leave GHL standard fields untouched (they cannot be deleted).
3. Delete the Lead Engagement pipeline (fleet standard is Main + Fixed only).
4. Execute these deletes inside the logged-in playwright-firerock browser via browser_evaluate against the documented services/backend endpoints — server-side node calls to services.leadconnectorhq.com hit the Cloudflare 1010 bot wall (per ghl-api-reference.md). UI is the fallback.

3. Create folders + rename/move the 13 workflows to canonical names

1. Create the 8 workflow folders exactly (names are the contract): 01 · Core — Lead Capture, 02 · Core — Reviews, 03 · Core — Utility, 10 · Optional — Appointments, 11 · Optional — Nurture, 12 · Optional — Calls, 13 · Optional — Ads & Tracking, 14 · Optional — Reviews+.
2. Rename + move workflows to canonical names/folders (proposed mapping — reconcile names in Step 0):

1. Rename via get_workflow → save_workflow_from_spec (or internal-API PUT). Folder create + move endpoint is not yet captured — do folder create/assignment in the UI via playwright-firerock, and capture the XHR for the maintenance reference while doing it.

4. Set publish/draft states

1. Publish the core 5 with publish_workflow; force every [OPT] module to draft with draft_workflow. GHL snapshots preserve per-workflow publish state, so this is what "core on load / modules as drafts" depends on.

5. Normalize the rest of the canonical payload

1. Confirm pipelines are exactly Main (New Lead) and Fixed (9-stage sales).
2. Confirm custom values GA4 Measurement ID and GA4 API Secret exist but are blank (per-client fill). Confirm custom fields Service Requested / Referred By / Referrer Email exist.
3. Confirm calendar "Discovery Call with {{location.name}}" exists (owner will be set per client at onboarding — user assignments do not transfer between accounts).
4. Confirm tag taxonomy (source / review-sequence / lost-reason) + the Google Review link trigger link are present and clean.

6. Save the agency snapshot

1. In Agency → Settings → Snapshots (via playwright-firerock), create a new agency snapshot "FireRock Standard v1" from the build account. Record its new snapshotId in MEMORY.md and ghl-api-reference.md.

7. Smoke-test

1. Create a throwaway sub-account loading FireRock Standard v1 (prospectInfo.snapshotId = new id). Verify: 8 folders present, core 5 published, 8 [OPT] modules draft, correct pipelines/custom values/fields/calendar/tags, and that stripped items are gone. Run scripts/ghl-audit.mjs inventory <throwaway> + regenerate the audit report to confirm zero drift vs spec. Delete the throwaway after.

8. Per-client activation runbook + onboarding roll-in

1. Write the runbook (client-facing tone, no internal-tooling mentions): load snapshot → set GA4 Measurement ID + GA4 API Secret → assign Discovery Call calendar owner → set phone/A2P → toggle applicable [OPT] modules to published by client capability → publish. Add a capability→module matrix (books appointments → Appointments; runs ads → Ads & Tracking + Meta CAPI; takes inbound calls → Calls; past-client list → Reviews+).
2. Add "FireRock Standard v1" to the onboarding SOP and note the versioning rule: canonical work lives only in Core/Optional folders; any client-specific workflow must live outside these folders so a future snapshot push never overwrites it. Version bumps go v1 → v1.1.

Risks & decisions

• Verify HMm03ltwkS40J4YWI0De before any write. If it is a live client account, editing/stripping it is destructive. All strip/rename/delete work must happen in the dedicated [BUILD] sub-account, never a client account. Needs Paul's confirmation of what this location is.
• Seed source decision (Paul's call): build from the live boilerplate cZeuZimeVcxKsVq1VAxd (what 14 clients actually run today) vs. a fresh snapshot of dSBv9R8HBSsGUiAh0GEo (Z Automation source). Recommended: cZeuZimeVcxKsVq1VAxd, so the standard reflects production reality, then reconcile against Z.
• GA4 API Secret in a shared snapshot: it is a secret. Ship the custom value empty, filled per client at onboarding — do not bake any real key into the canonical snapshot (security rule; would leak across all accounts).
• Canonical "sync" is diff-and-flag, not auto-push. GHL's snapshot "push updates to accounts" can overwrite name-matched assets and clobber client customizations. Recommend the existing audit sweep (which diffs every account against this spec) as the drift detector; any push is a separate, sign-off-gated decision. Confirm intent with Patrick/Jet.
• Uncaptured endpoints: workflow folder create/move, custom-field/value delete, and agency-snapshot create XHRs are not yet in ghl-api-reference.md. These steps run through the logged-in playwright-firerock browser (UI or browser_evaluate) because services.leadconnectorhq.com blocks non-browser callers (Cloudflare 1010). Capture them during the build to wire future automation.
• Workflow count/mapping (13): the exact source names and the confirmation/no-show and Day 1–3/5-Week splits must be reconciled against the live Z inventory in Step 0 before renaming; the table above is the proposed target, not a verified 1:1 yet.
• Destructive actions requiring sign-off: deleting ScoreCard fields/form, duplicate fields, and the Lead Engagement pipeline. Safe in the [BUILD] account; get Patrick/Jet confirmation that these are truly cruft fleet-wide before finalizing the snapshot.
• Per-client, non-transferable items (set at onboarding, not in snapshot): calendar owner/user assignment, phone number + A2P registration, GA4 IDs.