Въпросите, които Митко най-вероятно ще зададе

Не. Прототипът е справка за подредба, състояния, движение и поведение. Production кодът, живите данни и интеграциите са негова работа.

Има две части. prototype/public/demo/app е демото на приложението: чист HTML, CSS и JS модули, 7 страници (начало, каталог, заглавие, плейър, абонамент, арена, мач). Това е основата 1:1, върху която дизайнерите правят версии. prototype/ е Next.js 15 + React 19 със static export, който държи /atlas/, /design-system/ и /lab/.

Демото е копие на реалното приложение, за да се променя „върху одобреното“. Next.js частта е витрината на дизайн системата: атлас на компонентите и страница с токените.

Живият прототип на Стената вече ползва демото, не /lab/. В /lab/ имаше само Theater макет (hero, филтри, ред).

Един източник: design-system/tokens.css (CSS променливи) и components.css. DESIGN.md е генериран от тях. Те са чист CSS, така че ги превеждате в каквото ползвате.

Шрифтове: Manrope за текст, Unbounded за заглавия; размерите са само от скалата --t-*. Проверка при всеки commit (check-design.mjs) спира нова стойност извън токените.

Скалата --t-* още не е сверена докрай с Figma променливите, а DESIGN.md е чернова, докато дизайнерите не го прегледат.

Няма API и няма живи данни. Има снимка на данни и превключвател ?data=demo|today|future|edge; edge показва липсващи метаданни, дълги текстове и бавно зареждане.

Веригата „програма → запис → каталог“ в Theater е хипотеза, докато техническият екип не я потвърди. Няма EPG, плащане и TV навигация.

Замразена карта: точният commit, автор, бележка, статус, история и снимки на 390 и 1440 px. Пази се във versions/<екран>/<версия>/meta.json.

Статусите: чернова → за-одобрение → одобрено → в-разработка → готово, плюс „върнато“ от всяка стъпка. „Одобрено“ слага само PM, проверено по Git имейла в .github/team.json.

Всяка версия е git diff на демото между merge-base с main и нейния commit. На Стената service worker прилага избраните патчове в браузъра с jsdiff, върху копие на демото от main.

Изборът стои в адреса: ?pp=player&pv=theatre-player/…-mila-a, така че линкът се праща. Две версии в различни редове се показват заедно. Ако пипат един и същ ред, по-късната пада към основата и панелът го казва. Двоични и изтрити файлове не се патчват. Кодът е в scripts/lib/stena-proto.mjs.

Към 11.11 е PR, още не е в main. Проверено локално: тестове, wall-qa 52/52 и ръчно на каталога и плейъра.

На Стената: виж горното, конфликтът се показва, нищо не се чупи. В Git: task.mjs update спира при конфликт и човек избира.

Предложението за „двама на един екран“: общо проучване, всеки прави своя вариант в отделен файл, в main влиза само избраният. То още е решение за среща.

При всеки push към task/** или main, без таймер. Днес (11.11) веригата от push до готова Стена е около 1 минута: билд ~40 с, публикуване ~10 с, Стената ~10 с. Отворена Стена проверява на всеки 10 с и предлага „Покажи“.

Дизайнерът не трябва да прави push ръчно: скритият бекъп стига до GitHub поне на 30 минути, а „покажи ми“ записва веднага. Локалната Стена е готова мигновено.

Одобрението сочи точен commit. Пакетът за програмиста се строи от този commit, не от днешния main. Сливането е само с --merge, без squash, точно за да не изчезнат commit-ите, към които сочат версиите.

Force push и сливане без зелени проверки се спират от hooks и от правилата, но задължителната защита на main в GitHub иска платен план. Дотогава умишлено заобикаляне е възможно.

node scripts/design-version.mjs handoff <екран>/<версия> прави папка и zip: README (кой одобри, кога, commit, какво трябва да прави екранът), SPEC.md към момента на одобрението, снимките 390 и 1440, source/prototype, source/design-system и meta.json с историята.

Работи само за одобрени версии. Списъкът на одобреното е docs/FOR-DEV.md или филтърът „За DEV“ на Стената.

Към 11.11 има една: specs/theatre/browse.md. Пакетът взема SPEC.md и случаите „какво трябва да прави екранът“ от там. Без спецификация README-то казва „питай PM“.

Основните версии (osnova) са снимки на текущото приложение и нямат спецификация. Спецификациите ги пише PM със spec-builder; това е работата, която липсва, преди пакетите да са пълни.

Днес в /atlas/: всеки компонент със състоянията и къде се ползва, плюс ?data=edge за крайните случаи.

Не са пълни за всеки компонент и още не влизат в пакета. Това е в плана, следващото по ред след живия прототип.

Слага статус „върнато“ с бележка. Това маха одобрението; дизайнерът прави нова версия, PM одобрява отново. В началото на работата слага „в-разработка“, QA слага „готово“.

Снимките и проверките са само на 390 и 1440 px. Таблет и TV не се проверяват. Достъпността се гледа в прегледа (noisy-review), но няма автоматичен axe. Няма бюджет за производителност. Ако той има изисквания тук, това е точно мястото да ги добави като проверка.

Билдът и публикуването са разделени. pregled.yml билдва кода на задачата без никакви тайни. pregled-deploy.yml тръгва през workflow_run, проверява произхода и само качва готовите файлове, без да пуска кода. Стената се строи с генератора от main.

Всеки, който знае адреса: Cloudflare Pages без вход. Ограничаването до фирмени имейли (Cloudflare Access) иска карта в акаунта. В данните няма имейли, само имена.

По Git имейла на компютъра (design-task.mjs whoami), не по Claude или GitHub акаунта. Затова работи и с общ акаунт.

Да, Git имейлът се сменя на ръка. Надеждната проверка е прегледът преди сливане. Защитата пази от грешки, не от умишлено заобикаляне от човек с достъп.

Два слоя. guard-foundation.mjs в Claude Code спира редакция на защитените пътища без изречението на PM. commit-msg спира commit към тях без ред „Одобрено-от“ и пази и Codex, и терминала.

Codex няма проверка преди редакция, само при commit.

npm test пуска всички проверки, включително 35 тестови файла в scripts/tests/, и върви и в GitHub. npm run qa:wall отваря Стената headless на 390 и 1440 и търси преливане, грешки в конзолата и счупени снимки. npm run qa:flow пуска истински агент през целия път на дизайнера в чисто копие, с локален origin, и оценява записа.

Тест с двама души на два компютъра още не е правен. Windows не е тестван.

Figma остава за референции и одобрени екрани. Разликата е, че вариантите се правят в истинския продукт, със състояния и данни, и програмистът получава код от точния одобрен commit, не картинка.

Планът е отделно хранилище за всеки проект, общ комплект за механиката (скриптове, hooks, умения) и общо място за профилите. Още нищо не е преподредено. Дотогава нов проект тръгва като копие на основата без дизайн системата, прототипа и личните папки.