Klaviyo payloads C01-C29, X01-X04, G1-G3 (готови локално, не качени)

Как се генерират (важно, прочети преди да редактираш ръчно)

От 25.09.2026 файловете в templates/ и campaigns/ НЕ се редактират на ръка. Генерират се детерминирано от build_payloads.py директно от актуалните copy decks (COPY-DECK-CAMPAIGNS-30D.md C01-C09, COPY-DECK-CAMPAIGNS-EXTRA.md X01/X01-FALLBACK/X02-X04, COPY-DECK-CAMPAIGNS-D31-90.md C10-C29/G1-G3) и CAMPAIGN-CALENDAR-90D-FULL.csv (дата/час, Europe/Sofia). Ако редактираш текст, редактирай copy deck-а и пусни отново скрипта:

python3 build_payloads.py

Това презаписва всички templates/*.json и campaigns/*.json (37 писма), обновява templates/MANIFEST.json (масив от всички 37 шаблона, същия формат като преди) и пише BUILD-REPORT.json с обобщение и евентуални несъответствия. python3 build_payloads.py --check прави само проверка, без да презаписва файлове.

Никакво извикване към Klaviyo API (дори GET/read) не се прави от build_payloads.py. Всичко е локално, offline, от файловете в тази папка и една папка нагоре.

Какво има вътре

• templates/C01.json ... C29.json, X01.json, X01-FALLBACK.json, X02.json..X04.json, G1.json..G3.json: 37 native drag and drop (SYSTEM_DRAGGABLE) шаблона. Блокова структура, стилове на секциите и VF Footer секцията са копирани 1:1 от оригиналните hand-built C01-C09 шаблони (виж templates/_footer_section.json и _base_styles.json, снапшот, зареждан от скрипта при всяко генериране, за да остане footer-ът байт по байт същият). Без code/HTML блокове, без id/data_id полета (Klaviyo ги слага сама при create). Subject вариант А, preheader и продуктовите карти идват директно от текущите copy decks. Всички [ПРОВЕРИ...], [РЕШЕНИЕ...] и [PLACEHOLDER: ...] бележки в текста остават видими нарочно, не са скрити. Когато няма потвърден реален асет за продукт (напр. Артро Плюс), се ползва общ placeholder асет с ясен [PLACEHOLDER: ... снимка] alt текст, вместо измислен URL.
• templates/MANIFEST.json: масив от всичките 37 генерирани шаблона (същия формат, в който беше преди за C01-C09), обновява се автоматично при всяко пускане на build_payloads.py.
• campaigns/C01.json ... G3.json: draft payload за POST /api/campaigns за всичките 37 писма. Аудитория по подразбиране: include QNyJe6 (Engaged 90D), exclude UBKsQt (NO Marketing), Wkf6ds (List cleaning), Wemjib (Unengaged 180D). Изключения по writeup: X01/X01-FALLBACK include само VVzXcp (купили Артро Плюс), VIP писма (напр. C18) include само VgiZyH. Дата/час от CAMPAIGN-CALENDAR-90D-FULL.csv в Europe/Sofia, smart sending включен, UTM tracking включен. Subject вариант Б (за A/B тест) е записан в subject_variant_b_for_ab_setup, готов за ръчно нанасяне при create на A/B message в Klaviyo. Кампанията сочи към шаблон по име, защото истинско template_id се появява чак след create.
• BUILD-REPORT.json: последният резултат от build_payloads.py, с брой откъси текст на писмо и списък на евентуални липсващи абзаци (в момента на последния run: 0 несъответствия за 37/37).
• upload_after_approval.py, скрипт, който би създал всичко идемпотентно (проверява по име, прескача ако вече съществува). Взима ВСИЧКИ .json файлове в templates//campaigns/ (без MANIFEST.json/CREATED-IDS.json/_footer_section.json/_base_styles.json), не само C0*. По подразбиране прави само dry run и НЕ пипа Klaviyo. Пуска се реално само с --i-have-owner-approval и нужен KLAVIYO_API_KEY в средата.

Как да качиш след одобрение

1. Прочети всеки templates/CXX.json и campaigns/CXX.json, провери текста и офертите.
2. python3 upload_after_approval.py (без флаг) за dry run, само показва какво ще направи (и за 37-те кода, не само C01-C09).
3. След одобрение: KLAVIYO_API_KEY=... python3 upload_after_approval.py --i-have-owner-approval. Може и само за едно писмо: --only C01.
4. Всяка кампания излиза DRAFT. Нищо не се насрочва и не се изпраща от скрипта.

Какво НЕ е проверено (провери преди push)

• C03: Артро Плюс наличност (~16 бр. към 25.09) не е потвърдена, затова CTA е мек линк, не оферта.
• C04: точната доза/мл по тегло трябва да дойде от живия PDP текст, не е преизчислена тук.
• C06: БЛОКИРАН, чака писмено съгласие за реален отзив; шаблонът е само placeholder структура.
• C08: реалната офертна наличност/дата не е препотвърдена в момента на писане.
• C09: коя количествена автоматика печели (8pcsb/16pcsb/15pcsb) и коя наличност по вкус (Диета, Енергия са 0 бр. към 25.09) трябва да се провери в живата количка непосредствено преди push.
• Продуктови снимки за C07 (балсам, пробиотик) и C09 (7 вкуса) използват налични IMG ключове или placeholder, не нови асети, реалните снимки не са проверени тук.
• Схемата на create_dnd_email_template/create_campaign е инспектирана само през стари реални payload-и в review-2026-09-15/visual-rollout-gpt25/footer-rollout-2026-09-15, не през жива Klaviyo схема в тази сесия (само get_email_template/create_* бяха достъпни като инструменти, без извикване).
• Нищо не е тествано с реален send/preview в Klaviyo от тази сесия.
• build_payloads.py е автоматичен парсер на markdown copy decks, не разбира изкуство/оформление: H1 заглавието на всяко писмо винаги е Subject вариант А (без ръчно скроен двуредов headline); секциите се редят по реда на "Секция/Hero/Bridge/Footer" етикетите в decka, редуват се цветове FFFFFF/FBF8E8. За писма без изричен продуктов ред (Продукт: ... | ... | Бутон: ... -> URL) и без [Продуктов блок ...] маркер, но с **CTA текст/URL:** в края, скриптът добавя отделен затварящ бутон в края (напр. C02, писмо от автора). Провери визуално всяко ново писмо (C10-C29, X02-X04, G1-G3) в Klaviyo preview след ъплоуд, преди да разчиташ на автоматичното оформление за финален вид.