NOISY Lab: техническо описание

Как дизайнът на NOISY стига от идеята до разработката. Документът описва защо има такава система, как минава една задача, какво вижда всеки човек, как е устроена системата, кой какво одобрява и какво получава разработката. Източникът е кодът в хранилището на проекта.

0. Накратко

• Какво е. Дизайнерите работят с AI агент (Claude или Codex), който пише истински код на прототипа на NOISY. Всеки вариант е жив екран в браузъра, не картинка. Всяка версия се пази със снимки и точен commit и се показва на обща Стена. PM избира на Стената. Кодът влиза в основния клон main през pull request с проверки. Разработката (DEV) получава пакет от точния одобрен commit: снимки, спецификация, критерии и изходния код на прототипа от одобрения commit.
• Защо. На срещата от 30.10 бяха изброени проблемите в досегашния начин на работа: бавно прототипиране, неконсистентни резултати с AI, DEV трудно разбира какво да направи, не се знае кое е последното, спецификации без всички случаи, дизайни, които не са навързани в едно цяло (раздел 1). Системата е отговорът на тях.
• Какво не е. Не е продуктовият код на NOISY и не е свързана с живи данни. Прототипът е симулатор с примерни данни. Не е и инструмент за управление на проекти.
• Достъп. Само с фирмени акаунти на фирмения имейл: GitHub, Claude, Figma. Стената и прегледите се затварят с вход с фирмен имейл (раздел 9).
• Без зависимост от един AI. Правилата, уменията и паметта са файлове в хранилището. Минаването към Codex или друг AI не губи нищо (раздел 7).
• Кратка версия за копиране в AI асистент: docs/NOISY-LAB-SUMMARY.md.
• Защита на main. Правилата са записани в хранилището и се включват с една команда (scripts/github-protect.mjs). Когато хранилището е във фирмен GitHub акаунт с план Team или Pro, нищо не влиза в main без зелени проверки и одобрение (раздел 6).

1. Защо: проблемите днес и какво решаваме

Как се работи днес

Дизайнът на NOISY се прави във Figma. Дизайнерът рисува екран, полира го, маркира го „Ready for development“ и DEV го реализира. Някои дизайнери вече ускоряват: правят wireframe във Figma, после генерират код с AI и пращат HTML файлове. Спецификациите се пишат отделно.

Какво не работи, откъде идва и как го решаваме

Проблемите са записани на срещата от 30.10.2026. За всеки е посочена причината, защото решението трябва да маха причината.

На срещата бяха поставени и три условия. Процесът трябва да е лесен, иначе няма да се ползва. Инструкциите и паметта не трябва да зависят от модела. Нужна е помощ при старта.

Защо точно този път

Защо живи прототипи в код. Бавното е, че AI помага само в отделни стъпки, а вариантите и пресъздаването от DEV остават ръчни. Жив прототип в код маха и двете: вариантите ги прави агентът, а DEV получава код, който разбира. Figma остава за полиш и за дизайн системата. Така работят и други екипи (docs/RESEARCH-2026-11-02-designer-setup.md).

Защо AI агент с правила. Свободният чат е причината за П2. Агентът в проекта чете правилата, дизайн системата и вкуса на човека преди всяка задача, а проверките спират грешките автоматично. Дизайнерът говори с обикновени думи; Git и командите са работа на агента.

Защо GitHub. Дава точна версия на всеки файл, паралелна работа без презаписване и одобрение преди приемане. DEV вече работи така.

Какво остава в ръцете на хората

• Не прави продуктовия код и не свързва живи данни. Това остава работа на DEV.
• Не замества вкуса на дизайнера. Агентът предлага, човекът избира.
• Не гарантира, че AI ще направи хубав дизайн от първия път. Проверките хващат грешки в токените и типичния „AI вид“, но не и слабата идея.

2. Какво прави всеки

Първи ден на дизайнер. Инсталира приложението Claude (или Codex), отваря папката на проекта и пише „здрасти“. Агентът разбира, че е нов, и пуска умението onboarding: един въпрос за името, ролята и зоните, останалото по желание. Създава профил в designers/<име>/ и го записва. Проверката на компютъра (node scripts/doctor.mjs) казва какво липсва. Подробно: docs/TEAM-SETUP.md и docs/GUIDE.md.

Двама дизайнери по един екран. Всеки работи в своя задача и своя клон. Вариантите им са на Стената един до друг. При застъпване системата спира с конфликт и показва двете версии; човек избира, агентът не избира сам.

3. Пътят на една задача

Задача. Човекът казва „нова задача“ с целта. scripts/task.mjs start прави клон от най-новия main, бележки (цел, направено, остава, решения), изпраща ги и отваря чернова на pull request. Екипът вижда кой по какво работи. В приложението Claude всяка сесия е в отделна работна папка; в Codex и терминала клонът се прави в текущата папка.

Варианти. Агентът пише в prototype/ по спецификацията, токените и компонентите. Вариантите запазват общата основа и се различават по назовани решения. При commit scripts/check-design.mjs спира цвят, шрифт или размер извън токените. Снимки от интернет са позволени в прототипа и всяка се записва в SOURCES.md с източник, дата, автор и „замени преди продукция“. Чужд интерфейс може да се копира 1:1 като експеримент; към DEV отива само версия с компонентите и токените на NOISY. Лога на конкуренти не се ползват.

Версия. scripts/design-version.mjs save изисква записани промени, снима екрана на 390 и 1440 px и записва meta.json с commit, автор, адрес, бележка и история. Вариант е друго решение на същия екран. Версия е запазено състояние на екрана в даден момент, със снимки. Подробности: docs/VERSIONS.md.

Записване. След всеки отговор на агента работата се записва и изпраща в GitHub сама (autosave), и в Claude, и в Codex. Ако изпращането не успее, агентът го казва. Тогава работата е само на лаптопа, докато не се изпрати.

4. Стената и живите прототипи

Стената (scripts/stena-build.mjs) е общият регистър на всички версии. Онлайн тя е на https://noisy-stena.pages.dev и се обновява сама след всяко изпращане в задача или в main. Всеки екран има своя страница с версиите една до друга, снимките на две ширини, автора, бележката и статуса.

• Локално (--worktree) Стената показва и неизпратената работа. В приложението Claude агентът я отваря вдясно след всяко „покажи ми“. В Codex тя се отваря в браузъра на компютъра, а линкът към онлайн Стената е същият.
• „Отвори“ пуска живия прототип на версията. Това е истинският екран, с превключвателя на вариантите и режимите на данните.
• „Във Figma“ дава фраза за чата. Агентът изнася версията във Figma през връзката с Figma, за полиш или за дизайн системата.
• Избраното. Версията със статус „одобрено“ е избраната. Когато PM одобри нова версия на същия екран, предишната одобрена става „върнато“ с бележка „заменено от“.

Живият прототип е Next.js приложение в prototype/, по зони: Discover, Theater, Arena, Newsroom, Showtime. Всеки екран се отваря на адрес, вариантът е параметър ?v=, режимът на данните е ?data=:

Картата (/atlas/) показва всеки компонент на отделна страница (състояния, къде води всеки клик, къде се ползва) и потока на зоната с живи екрани и стрелки.

Статусите и позволените преходи са в scripts/design-version.mjs:

Всяко връщане маха одобрението. Историята пази кой, кога и защо.

5. Какво получава DEV и как връща въпрос

Пакетът. PM (или агентът му) пуска node scripts/design-version.mjs handoff <екран>/<версия> и праща пакета на DEV. Командата работи само за версия, одобрена от PM. Кодът се вади от точния commit на версията, не от днешния main:

handoff/<екран>-<версия>/
  README.md      кой одобри и кога, точен commit, как се пуска екранът,
                 „Какво трябва да може“ (случаите и критериите от спецификацията),
                 как се задава въпрос
  SPEC.md        спецификацията към момента на одобрението
  meta.json      историята на статуса
  390.jpg        снимка на телефон
  1440.jpg       снимка на компютър
  source/
    design-system/   tokens.css, components.css, COMPONENTS.md
    prototype/       app, components, lib, data
handoff/<екран>-<версия>.zip

Правилото е пакетът да се прави след сливането в main. Живият прототип на одобрения commit се пуска от пълното хранилище (npm ci, после npm run dev в prototype/). Линкът за преглед на задачата показва последното състояние на клона, не непременно одобреното.

Въпрос от DEV. DEV пише на PM. PM поставя статус „върнато“ с въпроса като бележка. Одобрението пада, дизайнерът вижда бележката на Стената и в следващата сесия, поправя в нова версия, PM одобрява отново и DEV получава нов пакет.

Какво остава за DEV. Продуктовият код, живите данни и интеграциите. Прототипът дава подредбата, състоянията, анимациите и поведението от спецификацията.

6. Одобрение и защити

Кой одобрява

Хората, ролите и одобряващите са в .github/team.json. Проверката „Одобрение от PM“ (odobrenie.yml) чете правилата от main, не от кода на автора. Брои се само Approve в GitHub, даден след последната промяна и не от автора.

Когато в team.json няма резервен одобряващ, работата на PM минава с видимо предупреждение. Щом се добави такъв човек, правилото става задължително. Защитата на main иска и одобрение от собственика на кода (.github/CODEOWNERS), затова резервният одобряващ се записва и там; иначе работата на PM чака.

Изборът на Стената („одобрено“) е изборът на дизайна; скриптът го приема само с Git имейла на PM от .github/approvers, а в main влиза само с Approve на PM. Approve в GitHub приема кода и се брои само от GitHub акаунта на PM. Историята на задачата се пази цяла при сливането (merge commit, без squash), за да може всяка одобрена версия да се намери.

Защитата на main

node scripts/github-protect.mjs apply --repo <собственик>/<repo> включва наведнъж: задължителен pull request, две задължителни проверки (checks и „Одобрение от PM“), ако авторът промени нещо след одобрението, то пада и PM одобрява пак, правилата важат и за администратори, без force push и без изтриване. verify сравнява живите настройки с тези и изброява разликите. На безплатен частен план GitHub не позволява тази защита: скриптът казва, че тя чака платен план, и спира. Когато хранилището е във фирмен акаунт с план Team или Pro, една команда я включва.

Защитите на всяка стъпка

Отстъпи, ъгли, сенки и inline стилове се гледат и на око. Снимките на две ширини доказват конкретен преглед, не всички устройства.

7. Не зависи от един AI

Системата е направена така, че екипът да може да мине от Claude към Codex или към всеки следващ AI без да губи работа и правила.

• Правилата са в обикновени файлове. Всичко, което агентът трябва да знае, е в AGENTS.md: общ формат, който четат Codex, Claude, Cursor, GitHub Copilot, Gemini и други. CLAUDE.md само препраща към него.
• Уменията са в обща папка (.agents/skills/), като текстови инструкции. Claude ги вижда през връзка в .claude/skills/, Codex ги чете директно.
• Паметта е в хранилището, не в акаунта. Профилите, вкусът, поуките, бележките на задачите и решенията са файлове в GitHub. Смяна на акаунт или на AI не изтрива нищо.
• Командите са обикновени скриптове (scripts/*.mjs на Node.js). Пуска ги всеки агент или човек от терминала.
• Автоматичните стъпки работят и в двата. Записването в GitHub след всеки отговор, хващането на корекциите, новината за DESIGN.md и проверката за „AI вид“ имат настройка за Claude (.claude/settings.json) и за Codex (.codex/hooks.json). Проверките при запис на промяна (pre-commit, commit-msg) са на Git и важат за всеки AI. В Codex автоматичните стъпки тръгват, след като човекът ги разреши веднъж при първия старт.

Разликите са две. Панелът със Стената вдясно е на приложението Claude; в Codex Стената се отваря в браузъра, на същия линк. В Claude редакцията на основата се спира още при опита; в Codex се спира при записа на промяната. За нов AI се добавя само неговата настройка за автоматичните стъпки; правилата, уменията и паметта остават същите.

8. Архитектура

Три слоя, без собствен сървър:

1. Файлове (Git). Основата: PRODUCT.md, AGENTS.md, скриптове, CI, текстовете в docs/COPY.md. Дизайн системата: DESIGN.md и design-system/. Работата: prototype/, specs/, версиите. Хората: designers/<име>/ и pm/<име>/ с профил, вкус и поуки. Екипът: .github/team.json.
2. Агент и скриптове (локално, при всеки човек). scripts/task.mjs (start, save, list, continue, update, review), scripts/design-version.mjs (save, status, list, handoff), scripts/stena-build.mjs, hooks в .claude/settings.json и .codex/hooks.json, умения в .agents/skills/.
3. Споделяне и проверка (GitHub Actions и Cloudflare Pages).

Защо прегледът е безопасен. Кодът на задача може да е всякакъв, затова сглобяването и публикуването са разделени. Стъпката, която сглобява кода (pregled.yml), няма пароли. Стъпката с паролите (pregled-deploy.yml) само качва готовите файлове и не пуска кода.

Линкове за преглед. Всеки клон на задача има постоянен адрес в Cloudflare Pages (pm/preview.json), който се сглобява сам след изпращане.

Продължаване. task continue поема работата на колега в нов клон и оставя неговия непокътнат. task update внася приетото от main; при конфликт спира и човекът избира.

9. Достъп и сигурност

Правилото: всичко е само с фирмени акаунти. Всеки човек работи с фирмения си имейл (@mediahub.eu): фирмен GitHub акаунт, фирмено място в Claude, фирмен Figma акаунт. Лични акаунти и общ акаунт не се ползват. Одобрение се брои само от GitHub акаунта, записан в .github/team.json.

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

В прототипа не се слагат поверителни данни, договори, цени или неанонсирани партньори, защото той се показва и на хора извън екипа.

10. Управление

Отговорници.

Разходи (компонентите; числата зависят от плановете).

• Claude: място за всеки дизайнер и PM. За ежедневна работа с агента Standard място в Team вероятно не стига; вариантите са в docs/TEAM-SETUP.md.
• GitHub: фирмен акаунт с план Team или Pro, за защитата на main.
• Figma: връзката на агента работи и с място View или Collab, но с малко заявки; за ежедневна работа е нужно място Full или Dev.
• Cloudflare Pages: прегледите и Стената работят на безплатния план.

Спиране и връщане. Публикуването спира с изключване на pregled-deploy.yml и stena.yml в GitHub Actions; дизайнерите продължават локално. Грешно слята промяна се отменя с нов pull request (git revert). Версия се връща към дизайна със статус „върнато“. Ако екипът се откаже, хранилището остава архив на решенията и версиите, а работата продължава във Figma. Нищо в продукта не зависи от NOISY Lab.

11. Какво следва

• Изборът на PM става Approve в GitHub на pull request с по една предложена версия на екран, а Стената взима „прието“ от main. Така има една истина за статуса.
• Пакетът за DEV се прави от CI след всяко сливане, като GitHub Release, който стартира сам, а статусът на разработката е в GitHub Issues.
• Когато Cloudflare акаунтът е свързан: вход с фирмен имейл пред Стената и прегледите.

12. Чести въпроси

Защо не само Figma? Figma остава за полиш и дизайн системата. Защо вариантите са в код: раздел 1 (П1, П3).

Може ли екипът да мине изцяло на Codex или на друг AI? Да. Правилата, уменията и паметта са в хранилището и не зависят от Claude (раздел 7).

Какво става, ако свърши лимитът на Claude? Докато се работи в задача, работата се изпраща в GitHub след всеки отговор. Задачата продължава в Codex или в нова сесия от бележките ѝ.

Как другите разбират, че DESIGN.md е сменен? Щом pull request пипне DESIGN.md или дизайн системата, GitHub иска преглед от другите дизайнери и пише коментар с променените части; известието идва по имейл според настройките на човека. След като промяната влезе в main, агентът го казва с едно изречение при следващия старт.

Може ли дизайнер да счупи нещо? Основата (правила, скриптове, CI) се сменя само с одобрение от PM: агентът и компютърът спират опита, а след включването на защитата на main (раздел 6) и GitHub не я приема без PM. Всяка промяна в хранилището се връща от историята.

Какво става с екраните, които вече са във Figma? Остават валидни. Еталон на всеки екран е последният му дизайн, одобрен от PM: на Стената или като „Ready for development“ във Figma, по-новото от двете. Когато се работи по екран, одобреният Figma дизайн се пресъздава в прототипа.

Кой прави пакета за DEV и откъде го взима DEV? PM или агентът му го прави с една команда от одобрената версия и го праща на DEV. Когато се включи автоматичният пакет (раздел 11), той ще се появява сам в GitHub при всяко сливане.

Какво вижда AI доставчикът от нашата работа? Файловете, с които агентът работи, минават през Claude или Codex по условията на фирмения план. По условията на бизнес плановете на Anthropic и OpenAI данните не се ползват за обучение на моделите по подразбиране. Затова и тук важи правилото: без поверителни данни в прототипа.

Какво става, ако работата не стигне до GitHub, например без интернет? Агентът казва, че работата е само на лаптопа. Тя се изпраща сама при следващото записване с мрежа.

Какво вижда ръководството? Стената: всички екрани, вариантите, избраното и докъде е разработката. Входът ще е с фирмен имейл (раздел 9).

Защо PM одобрява на две места? Изборът на Стената е изборът на дизайна. Approve в GitHub приема кода, който стига до DEV.

Кой слага „в разработка“, „готово“ и „върнато“? Всеки от екипа. Само „одобрено“ е на PM.

Може ли дизайнер да промени дизайн системата? Да, в задача. Промяната се приема с одобрение от PM или от двама други дизайнери.

Какво става, когато кажа на агента „не така“? Агентът поправя работата и записва поуката в личната папка на човека, за да не я повтаря.

Какво става, ако PM отсъства? Дизайнът на екипа чака PM; изключение е дизайн системата, която могат да приемат двама дизайнери. Резервният одобряващ от .github/team.json покрива само собствената работа на PM.

Речник

Последна редакция: 05.11.2026.

Вътрешна документация на MediaHub. Тестов адрес, не е продукция.