@Jerry Relth Great job on the presentation!

I am running this command a right now

ATLAS

Lessons learned from the using the public funnel QA pass: 1. Funnel UI is not proof. We had live cases where the frontend could report failure while GHL still created or matched the contact. Thank-you states, success toasts, and workflow fires are not enough to verify a funnel. 2. Duplicate-contact behavior must be tested explicitly.Both Apex /audit and /weekly-workflow-waste-finder had duplicate-contact false-failure behavior. If duplicate handling is not tested on purpose, a broken production funnel can look “mostly fine” until real traffic hits it. 3. Custom-field writes should not rely on guessed keys.The Weekly Workflow Waste Finder was silently dropping core worksheet answers because the handler was writing ambiguous field keys instead of verified Apex field IDs. Contact creation alone is not enough; field persistence has to be checked directly. 4. Production host of record matters.A fix is not done when code is patched locally or deployed “somewhere.” It is only done after deploy to the actual production host and live retest on the branded public URL. 5. Public form QA needs a minimum standard.For any GHL-connected public funnel, the baseline should be: 6. Booking wrappers need their own proof standard.A live wrapper page and reachable widget URL are not enough. A booking surface should not be called verified until there is at least one confirmed burner appointment or equivalent authenticated booking proof. What changed from this: - Apex /audit now passes happy path, validation, and duplicate-contact retest - Apex /weekly-workflow-waste-finder now passes happy path, validation, and duplicate-contact retest - backend GHL truth now matches frontend behavior on both forms - one remaining gap: Apex /booking still needs authenticated burner booking proof We turned this into a reusable rule by creating the ghl-funnel-qa skill so this process can be repeated instead of rediscovered.