Архітектура · перебудовано 21 серпня 2026
Стіну поставлено. Бренд розділено на продуктові контури, наявну інформацію перевірено файл за файлом, межу стереже гейт. Нижче: що було, що зроблено і що тепер заповнюєш ти.
Система живе трьома шарами. Проблема не в жодному з них окремо, а в тому, що сенси продукту розлиті по всіх трьох замість того, щоб сидіти в одному.
Рожевим позначено шлях, яким сенси старого продукту доходять до нового. Зеленим, те що можна лишити спільним без ризику.
Це не гіпотези. Кожен пункт я перевірив у файлах, доказ під текстом.
Оркестратор прямо наказує звіряти нову сторінку з broshky1 поблочно: хедер, геро, каталог, деталі, історія, ручна робота, медіа, упаковка, відгуки, акордеон, футер. Новий продукт з іншою логікою продажу автоматично отримує чужий скелет сторінки і чужий порядок аргументів.
Де: ~/.claude/skills/zarmilkas-orchestrator/SKILL.md, розділ QA-луп, пункт «Поблочне порівняння з оригіналом (broshky1)».
Товари живуть не в даних, а всередині логіки: window.SHIRTS на рядку 190 і window.MOTANKY на рядку 206 того самого файлу, що робить кошик і апсели. Скопіювати механіку воронки без товарів мотанок зараз технічно неможливо, вони їдуть разом.
Де: zarmilkas-test/public/broshky1/funnel.js, 58 КБ, 13 входжень слів «мотанка/оберіг» прямо в коді.
Правила «художній твір, не автентична мотанка», банліст слів, ЦА, тон, все це записано на бренд цілком. Щойно в задачі зʼявляється Zarmilkas, вони підтягуються в контекст і починають керувати копірайтингом нового продукту, хоча писались під брошки.
Де: memory/feedback_zarmilkas_*, серед них artwork_not_authentic, positioning_handmade_not_oberig, bags_language_scope. Останній вже довелось писати саме тому, що мова брошок лізла в сумки.
81 директорія в одному деплої, спільні assets, спільний _redirects, спільний чекліст. Новий продукт лягає сусідньою папкою і одразу успадковує сусідську спадщину: чужі стилі поруч, чужі шляхи до фото, ризик зачепити живу воронку своїм деплоєм.
Де: wrangler pages deploy public --project-name=zarmilkas-test, один проєкт на все.
Тут потрібна точність, бо частина цього має лишитись спільною. Підвал, юр-сторінки і реквізити, це юридична єдність бренду, її ділити не можна. А от типографіка, палітра, ритм блоків і мова інтерфейсу, це шкіра конкретного продукту, і зараз вона теж прописана на весь бренд.
Де: zarmilkas-test/FOOTER-CANON.md плюс хук zarmilkas-footer-guard.py, який блокує розходження підвалу. Це правильно і лишається. Розділяти треба те, що лежить поруч у CHECKLIST.md у розділі «Бренд / дизайн».
Помилка була б різати навпіл, «старе і нове». Різати треба поперек, за природою речей: те, що фізично одне на бренд, залишається спільним, а те, що є мовою продукту, отримує власний замкнений контур.
Контури не спілкуються між собою. Вони обидва спираються на спільну шину знизу, і саме тому екосистема лишається однією.
lpcrm-intake, D1, CRM, email, пікселі, BI_shared/footer.html) і юр-сторінки на корені?v=, reset кошикаСім кроків, усі виконані. Тепер новий сайт фізично не має звідки взяти сенси брошок, навіть якщо я захочу.
Кожен продукт тепер має власний паспорт і власний словник. Порожнє поле в паспорті лишається порожнім: заповнити його матеріалом сусіднього продукту заборонено.
zarmilkas-brand/
├── _platform/ спільне: техніка + юр-ядро
├── products/
│ ├── broshky/ PRODUCT.md + LEXICON.md
│ ├── sumky/ PRODUCT.md + LEXICON.md
│ └── _TEMPLATE/ порожній контур для наступного продукту
├── _quarantine/ вилучені забруднення
├── INVENTORY.md карта: що кому належить
└── tools/scope_check.pyУ паспорті сумок прямо написано, що слова «художній твір», «авторство», «канон власниці» тут заборонені, бо це мова брошок. У паспорті брошок так само заборонена мова сумок.
Технічна частина винесена в _platform/PLATFORM.md: воркер, D1, CRM, email, пікселі, BI, absImg, бамп версій, деплой. Юридична частина в BRAND-CORE.md: ФОП, підвал, юр-сторінки, контакти. У жодному з цих файлів немає ані слова про товар.
Тепер його крок нуль це «визнач продукт», а не «звіряй з broshky1». Пункт QA переписано: еталон береться з власного контуру, а якщо його ще нема, звіряємо з макетом від Назара і НЕ з чужим продуктом.
CLAUDE.md проєкту наказував першою дією читати MASTER-DNA, а в ній 16 згадок брошок проти однієї про сумки. Тепер перша дія це визначити продукт. У самій MASTER-DNA розмічено, які блоки спільні, а які написані під брошки.
Stop-хук product-scope-guard.py не дає завершити хід, якщо в контурі з'явилось чуже. Перевірка ловить три речі: однаковий файл у двох продуктів, фрази-маркери чужого продукту і читання чужих шляхів.
python3 zarmilkas-brand/tools/scope_check.py
SCOPE:PASS нових порушень нема (відомий борг: 12)Окремий режим підкладає в контур сумок фразу з мови брошок і переконується, що перевірка червоніє. Зелений тест, який нічого не ловить, гірший за відсутній.
python3 tools/scope_check.py --selftest
SELFTEST: ЛОВИТЬ ✅ (було 12, стало 13)Чому гейт ловить фрази, а не слова: словник бренду виявився омонімічним. «Архетип» у сумках означає архетип ЗАГОЛОВКА, «Берегиня» це назва колекції вишивки, а перелік асортименту законно згадує і брошки, і сумки. Правило на окремих словах червоніло б за правильний текст, а сторож, який блокує правильну роботу, гірший за відсутнього.
Просканував 125 текстових файлів бренду плюс продакшн-код і скіли. Головна новина хороша: система виявилась чистішою, ніж я очікував.
файлів належать брошкам і сумкам відповідно. Це мозок продуктів, для нового він не джерело.
табу-база брошок лежала в мозку сумок точною копією. Прибрано в карантин.
омоніми і законні згадки. Кожну перевірив у контексті, перш ніж чіпати.
window.MOTANKYБорг, який чекає твого рішення: у мозку сумок стоять посилання на базу брошок з поміткою «метод-донор, брати ЛИШЕ структуру». Формально це місток між контурами. Або лишаємо його з жорсткішим формулюванням, або рвемо. Плюс два файли лежать однаковими копіями в обох продуктів (роль медіабаєра і формат виводу): їх правильно винести в платформу. Обидва пункти в baseline, вони не блокують роботу, але й не зникнуть самі.
Порожній контур уже стоїть у products/_TEMPLATE/. Одинадцять полів, які я НЕ маю права заповнити за тебе, бо будь-яка моя вигадка тут стане мовою бренду. Можеш надиктувати голосом підряд, я розкладу по файлах.
| № | Поле | Що саме сказати | Навіщо це мені |
|---|---|---|---|
| 1 | Що це фізично | З чого зроблено, які форми і розміри, що входить у комплект | Основа всіх описів і фото |
| 2 | Чим це НЕ є | З чим плутають і що ми про нього НЕ кажемо | Головне поле захисту від змішування |
| 3 | Хто купує | Стать, вік ядра і межі, достаток, звідки трафік, географія, собі чи в подарунок | Тон і аргументи |
| 4 | Чому купують | Яку задачу людини це закриває. Причина, не характеристика | Хук і перший екран |
| 5 | Чим доводимо | Матеріал, час праці, унікальність, гарантія, відгуки, нагороди | Блок доказів, без нього копі порожнє |
| 6 | Позиціонування | Одне речення: чим продукт є для клієнта. Плюс як обґрунтовуємо ціну | Рамка, в яку лягає все інше |
| 7 | Ціна і економіка | Полиця, собівартість, середній чек, апсели | Воронка і апсели |
| 8 | Асортимент | Скільки позицій, як діляться, чим відрізняються | Каталог і структура сайту |
| 9 | Упаковка | Що бачить клієнт, коли відкриває. Лист, вкладка, оформлення | Блок упаковки і апсел |
| 10 | Що вже є | Фото, відео, відгуки, транскрипти, дослідження і де вони лежать | Щоб я не просив те, що вже маємо |
| 11 | Воронка | Як людина йде від оголошення до оплати, які сторінки потрібні | Технічна збірка |
Окремо і обов'язково: дизайн-напрямок у RULES/design.md. Яким має відчуватись сайт, який один шрифт, яка палітра і звідки вона взята, який тип кадру головний. Поки це поле порожнє, я не маю права починати дизайн: інакше візьму те, що вже бачив, а це і буде перефарбований broshky1.