Срещата за NOISY Lab: сценарий
Чернова само за теб, Костадин. Срещата върви в реда, който ти предложи: папките с примери и защо ги има, после защо дизайнерите ги поискаха, после прототипът и накрая следващите стъпки. За всяка стъпка: какво отваряш, какво казваш, снимка как изглежда и какво да отговориш, ако питат. Отметни стъпката, когато я минеш. Около 45 минути.
- 0Преди срещата10 мин, сам
- отвори 6 раздела
- реши ЖП1 и ЖП2
- тестовата папка за Митко
- 1Отваряне2 мин
- едно изречение: какво е и защо
- 2Папките12 мин
- една задача през 6 папки (Мила)
- дървото: 5 групи, 29 неща, за всяко проблем и причина
- 3Защо: дизайнерите го поискаха8 мин
- 13 изречения от срещите → къде е отговорът
- 4Прототипът на живо10 мин
- 4.1 демото: основата
- 4.2 Стената: всички версии
- 4.3 живият прототип: смени версия, прати линка
- 5Следващи стъпки8 мин
- 7 стъпки по важност
- подробно: двама на един екран
- 6Въпроси и тестовата папка5 мин
- START-HERE: 10 мин без агента, 15 мин като дизайнер
Преди срещата
Всичко отворено, нищо не се търси по време на срещата.
- Тази страница.
- noisy-lab-overview.pages.dev: общият преглед на английски, с който отваряш.
- noisy-papkite.pages.dev: картата на папките, основата на стъпки 2 и 3.
- noisy-designlab.pages.dev: Стената. Влез предварително, защото пита за вход през Cloudflare.
- noisy-dvama-edin-ekran.pages.dev: двама на един екран, за стъпка 5.
- noisy-mitko-qa.pages.dev: въпросите и отговорите, само за теб, не го показвай.
- ЖП1, PR #44 (живият прототип). Слеем ли го довечера, утре го показваш направо на общата Стена. Ако не, го показваш от тестовата папка на компютъра (стъпка 4 казва как).
- ЖП2, PR #45 (записите в GitHub на английски). Не е нужен за срещата, но е добре да е слят, ако Митко отвори историята.
Готова е тук: ~/ClaudeCodeFirst/.tmp/mitko-proba.zip (241 MB). Вътре е отделно копие на проекта, от което нищо не стига до GitHub. Първо се чете START-HERE.md. Проверено след разархивиране на чисто място.
Отваряне: какво е и защо го има
Едно изречение и картината, преди детайлите.
„Дизайнерите правят екраните направо в продукта, с агент до тях. Казват какво искат, избират вариант, агентът прави останалото.“
„Всичко е в една папка в GitHub и всяко нещо има точно едно място. Дизайнерът не пипа папки, но програмистите и агентът ги намират на едно и също място. Затова започвам с тях.“
- Само заглавието и „What changes“. Не чети прегледа, той е за после.
Папките: по 2-3 примера и защо я има
Митко вижда цялото хранилище на един лист и нищо не е пропуснато (29 от 29).
- Покажи картата: петте цвята са петте групи отдолу.
- Мини през „Една задача през папките“: задачата на Мила за тайм стамповете минава през 6 папки. Това е най-бързият начин да се разбере.
- После отваряй групите. За всяка: защо я има и един пример. Останалото е на страницата.
Една задача през папките: Мила, тайм стамповете на плейъра
- Мила казва „нова задача“. Агентът отваря отделно копие (клон
task/mila/taym-stampove-na-pleyara) и записва целта вtasks/taym-stampove-na-pleyara/mila.md. - Агентът чете откъде тръгва: снимките на плейъра в
design-sources/, правилата вdesign-system/иDESIGN.md. - Прави вариантите в демото:
prototype/public/demo/app/player.html,css/player.css,js/player.js. - „Покажи ми“: снимки на 390 и 1440 отиват във
versions/theatre-player/…-mila-a/. От там ги чете Стената. - PM одобрява и задачата влиза в общото. Отхвърленият вариант отива в
archive/с причината. - Какво е научил агентът за вкуса ѝ остава в
designers/mila/.
Кажи: „Мила не е видяла нито една от тези папки. Тя е казала три изречения.“
Дървото на хранилището
Всичките 29 неща от горното ниво, подредени в петте групи от картата. Натисни ред, за да видиш проблема, който махаме, и защо е направено така. „С одобрение“ значи, че промяната минава през PM или колега.
noisy-zhorkata/Цялото хранилище в GitHub. Едно място за всичко.
Проблемът, който махаме: Дизайни в Figma, линкове в чата, бележки при всеки отделно: никой не знае кое е последното.
Защо е така: Всяко нещо има точно едно място. Дизайнерът не пипа папки, агентът и програмистите намират едно и също на едно и също място.
1. Работата: какво правим
prototype/Самият прототип: жив сайт, не картинка.
Проблемът, който махаме: Макет в картинка, който програмистът тълкува, и ръчно прехвърляне на състоянията.
Защо е така: Дизайнът е работещ екран с всички състояния. Програмистът получава поведение, не догадка.
public/demo/app/Одобреното приложение 1:1: начало, каталог, заглавие, плейър, абонамент, арена, мач.
Проблемът, който махаме: Всеки започва от празен лист и дизайнът се отклонява от одобреното.
Защо е така: Новото се добавя върху одобреното, затова остава консистентно.
Пример: player.html + css/player.css + js/player.js, вариантите са на ?v=a, ?v=b
sections/Версии на части от екран, всяка в нов файл.
Проблемът, който махаме: Нова версия презаписва старата и няма как да се сравнят.
Защо е така: Нова версия е нов файл, старата не се пипа.
Пример: theatre/filters/v1.tsx и v2.tsx
app/atlas/ · app/design-system/Атласът: всеки компонент със състоянията му и стрелки между екраните.
Проблемът, който махаме: Програмистът не вижда hover, зареждане и грешка, а ги измисля сам.
Защо е така: Състоянията са нарисувани и проверими на едно място.
Пример: /atlas/, /design-system/
versions/Всичко, което се вижда на Стената.
Проблемът, който махаме: Варианти, разпилени линк по линк, които се губят (мин. 45:46).
Защо е така: Всяко „покажи ми“ остава завинаги: снимки 390 и 1440 и meta.json. Стената се строи само оттук.
Пример: theatre-player/20261111091441-mila-a/ и arena-arena-hero/osnova/ (основата)
tasks/Бележката на всяка задача: цел, направено, остава.
Проблемът, който махаме: Затворен лаптоп, смяна на модела или друг човек и всичко започва от нулата (мин. 41:05).
Защо е така: Агентът продължава оттам, където е спряно. Празна „Цел:“ не може да се предаде.
Пример: taym-stampove-na-pleyara/mila.md
specs/Какво трябва да прави един екран: случаи С1, С2.
Проблемът, който махаме: Генерална задача и агентът „оверскипва“ (мин. 09:52).
Защо е така: Дизайнът отговаря на написани случаи, които вижда и програмистът.
Пример: theatre/browse.md и TEMPLATE.md
2. Източниците и правилата: откъде тръгваме
design-sources/Откъде тръгва всеки екран: одобрено, демо или живо.
Проблемът, който махаме: „Не мога да се ориентирам кое е финалният дизайн“ (мин. 09:52).
Защо е така: Агентът никога не рисува на сляпо. Редът е одобрено → демо → живо, снимка по-стара от 24 ч. се прави наново.
Пример: screens.json, snimki/uplay/, figma-for-dev/frames/
design-system/Цветове, шрифтове, компоненти, бранд. с одобрение
Проблемът, който махаме: Всеки измисля свои стойности и след месец имаме 40 нюанса лилаво.
Защо е така: Един източник, а проверката спира всяка стойност, която не е оттук. Промяна само с одобрение от колега.
Пример: tokens.css: --n-violet #B61DFF, --n-magenta #CE13A8
DESIGN.mdВизуалната посока и какво е забранено. с одобрение
Проблемът, който махаме: Дизайн, който изглежда като AI шаблон.
Защо е така: Агентът го чете преди всяка задача. Още е чернова до прегледа на дизайнерите (НЛ20).
PRODUCT.mdПотвърдените факти за продукта. с одобрение
Проблемът, който махаме: Агентът измисля функции, които продуктът няма.
Защо е така: Само проверени факти, промяна само с PM.
decisions/Какво е решено, кога и защо.
Проблемът, който махаме: Спорим два пъти за едно и също.
Защо е така: Всяко решение има номер, дата и статус.
Пример: НЛ8 стари варианти на Theater (прието), НЛ20 преглед на DESIGN.md (отворено)
3. Хората: всеки има свое място
designers/Профилът и вкусът на всеки дизайнер.
Проблемът, който махаме: Вкусът на един става правило за всички, или агентът не помни човека.
Защо е така: „Обичам въздушно“ на Мила не сменя дизайна на Павлин. Профилът се прави при първия старт.
Пример: _template/profile.md, …/learnings.md
pm/Същото за PM.
Проблемът, който махаме: Агентът не знае референциите и вкуса на PM.
Защо е така: Вкусът на PM е записан и се ползва при преглед.
Пример: kostadin-pavlov/taste/taste.md
4. Машината: правилата на агента и проверките
AGENTS.md · CLAUDE.mdИнструкцията на агента, еднаква на всеки компютър. с одобрение
Проблемът, който махаме: Всеки агент се държи различно, или някой без да иска счупва правилата (среща 30.10).
Защо е така: Едни правила за Claude и Codex, заключени: промяна само с PM (НЛ27), пазачът спира опит.
Пример: „Говори с думи като линк, вариант, Стената. Не споменавай клонове и папки.“
.agents/ · .claude/Уменията и настройките на агента. с одобрение
Проблемът, който махаме: Всяка процедура се обяснява наново и всеки път излиза различно.
Защо е така: Готови процедури: design, clone-reference, noisy-review. Добрият промпт става умение за всички.
.codex/Същите пазачи за Codex. с одобрение
Проблемът, който махаме: Правилата важат само за единия модел.
Защо е така: Работата не зависи от един доставчик.
Пример: hooks.json
scripts/Командите, които агентът пуска. с одобрение
Проблемът, който махаме: Моделът помни стъпките различно всеки път.
Защо е така: Каквото трябва да става еднакво, е код. Промяна само с PM.
Пример: task.mjs (start, save, show, update, review), design-version.mjs, check-design.mjs, hooks/guard-foundation.mjs
.github/Какво става само в GitHub. с одобрение
Проблемът, който махаме: Ръчно пускане на прегледи и забравени стъпки. „Да светне кое е For Dev“ (мин. 38:02).
Защо е така: При всеки запис линк за преглед и обновена Стена за около минута, без човек.
Пример: workflows/pregled.yml → stena.yml, team.json, approvers
tests/Автоматичните проверки.
Проблемът, който махаме: Счупен инструмент стига до дизайнера.
Защо е така: Доказва, че инструментите работят, преди някой да ги ползва.
Пример: figma-for-dev/run.mjs и scripts/test-*.mjs
.impeccable/Настройката на проверката срещу AI дизайн. с одобрение
Проблемът, който махаме: Шаблонен AI вид минава незабелязано.
Защо е така: Автоматична проверка при всеки преглед.
Пример: config.json
.mcp.jsonВръзката на агента с Figma. с одобрение
Проблемът, който махаме: Ръчно прехвърляне на екрани към Figma.
Защо е така: „Прати във Figma“ работи с една команда.
package.json · vercel.json · .gitignoreКомандите на проекта, сглобяването на прототипа и кое не се качва. с одобрение
Проблемът, който махаме: Различно поведение на всеки компютър, лични и тежки файлове в GitHub.
Защо е така: npm test и npm run dev са еднакви навсякъде, .env и node_modules не се качват.
5. Паметта и ръководствата: нищо не се губи
archive/Отхвърленото и остарялото.
Проблемът, който махаме: Изтрито значи загубено, а после някой го предлага пак.
Защо е така: Нищо не се трие. „Избирам Б“ прибира другите с причината (мин. 42:00).
Пример: 2026-11-02-theatre-variants/ + README защо
docs/Ръководствата за хора.
Проблемът, който махаме: Всеки обяснява системата по своему.
Защо е така: Едно описание за дизайнери, PM и програмисти.
Пример: FOR-DEV.md, DESIGNER-WORKFLOW.md, VERSIONS.md, GLOSSARY.md (в PR #45), COPY.md
README.md · ZA-ZHORKATA.md · TASK-HANDOFF.mdВходът за нов човек, пробната папка за дизайнер и статусът на проекта.
Проблемът, който махаме: Нов човек не знае откъде да започне.
Защо е така: README казва какво да прочете според ролята, ZA-ZHORKATA води пробата с Figma, TASK-HANDOFF казва докъде е проектът.
„Дизайнерът трябва ли да знае тези папки?“ Не. Пише „нова задача“, „покажи ми“, „избирам Б“. Папките са за агента, програмистите и PM.
„Кои са заключени?“ design-system/ и DESIGN.md одобрява колега, различен от автора. AGENTS.md, scripts/, .github/, уменията, PRODUCT.md само PM.
„Защо имената са на български?“ Скриптовете и линковете сочат към тях. Речникът е в docs/GLOSSARY.md, новите записи в GitHub са на английски.
Защо: дизайнерите го поискаха
Нищо не е измислено от нас: всяка папка отговаря на изречение от срещата с дизайнерите.
„Това не е наша архитектура заради архитектурата. Ето какво казаха дизайнерите на срещата днес и къде е отговорът.“
| Казаха | Кога | Отговорът в системата |
|---|---|---|
| „Не мога да се ориентирам кое е финалният дизайн.“ | 11.11, 09:52 | design-sources/: агентът тръгва от одобреното, после демото, после живото. |
| „Като му казваш много генерална задача, оверскипва.“ | 09:52 | specs/: случаи С1, С2, на които дизайнът отговаря. |
| Статус „одобрено, чернова, отхвърлено“ с филтри. | 35:07 | Статусите на Стената, записани в meta.json. |
| „Като се логнеш като PM или developer, виждаш кое е For Dev.“ | 38:02 | .github/: одобреното светва само, без ръчна работа. |
| „Просто да влезе в Claude и да го пита докъде стигнахме.“ | 41:05 | tasks/: бележка за всяка задача, продължава се оттам. |
| „Харесва ми версия 3 и 5, останалите в архива.“ | 42:00 | archive/: „избирам Б“ прибира другите с причината. |
| „Трябва да е на един канвас, иначе се търси линк по линк.“ | 45:46 | versions/ + Стената: всички версии на едно място. |
| „Кодът трябва да е силно по-консистентен.“ | 45:46 | design-system/ и проверката за стойности. |
| „Да си вземаме един от друг промптовете.“ | 46:43 | designers/ и споделените умения. |
| „Искам да видя прототипа с моя фийчър вътре и да си го цъкам.“ | 50:43 | Живият прототип на Стената (стъпка 4). |
| „Прототипът ще си вкарва това по едно и ще си ги събират.“ | 55:22 | Сменяеми секции и вкарване в основата. |
| „Не знаем колко често всяка секция ще се работи заедно.“ | 59:12 | Двама на един екран (стъпка 5). |
| Структура, така че каквото и да напишат, да не могат да счупят много. | 30.10 | AGENTS.md и пазачите на основата. |
Цитатите са от автоматичната транскрипция, леко изчистени. Минутите са от записа на 11.11.
Прототипът на живо
От „ето основата“ през „ето всички версии“ до „ето целия продукт с избраната версия вътре“.
4.1 Демото: основата, върху която се добавя
prototype/public/demo/app/player.html?id=harry„Това е одобреното приложение 1:1. Дизайнерът не започва от празен лист, а добавя върху него.“
- Покажи
?data=edge: дълги текстове и липсващи данни. Програмистът вижда и неудобните случаи.
4.2 Стената: всички версии на едно място
„Това е отговорът на „линк по линк“. Всеки вариант, на всеки екран, със статус и кой го е направил.“
- „Сега работят“: Мила, тайм стамповете на плейъра.
- Отвори един екран от „Модули“.
„За всяка версия: снимки на телефон и компютър, бележка, статус. Оттук PM одобрява и оттук върви към Figma.“
4.3 Живият прототип: целият продукт, избираш версия за всяка секция
„Това е отговорът на 50:43. Минаваш по пътя на зрителя, за всяка секция избираш версия, изборът стои в адреса. Нацъкваш и пращаш линка.“
- Отвори „Прототипът“, таб „Плейър“.
- В „Секции на страницата“ смени „Основа“ на „Мила Проверкова, вариант b“. Плейърът се сменя на място.
- Покажи адреса:
?pp=player&pv=…mila-b. Този линк показва същото на всеки.
git switch sistema/live-prototype, после node scripts/stena-build.mjs --worktree --out prototype/public/stena, npm run dev и localhost:3210/stena/prototip.html?pp=player. Снимките горе са направени точно така.Следващи стъпки за имплементация
Какво е готово и чака решение, какво е открито днес и какво идва след това.
| # | Стъпка | Какво значи |
|---|---|---|
| 1 | Живият прототип чака решение | Сменяеми секции и линк, който пази избора. Готов и тестван, PR #44. |
| 2 | Записите в GitHub на английски чака решение | Пазачът спира нов запис на кирилица, речник за българските имена. PR #45, тестове 332 от 332. |
| 3 | Двама на един екран без конфликти следващото | Всеки вариант в свои файлове, предупреждение „Ани също работи по плейъра“, отделна стъпка за вкарване в основата. Подробно отдолу. |
| 4 | Стената по пътя на зрителя и със състоянията | Екраните подредени по реда, в който ги минава зрителят, всеки компонент с hover, зареждане, грешка. Отговор на 35:07. |
| 5 | Споделени промптове и умения започнато | Добрият промпт на един дизайнер става умение за всички, с одобрение. Отговор на 46:43. |
| 6 | Статусът при програмистите на всеки екран | Освен „одобрено в дизайна“, и докъде е в разработката. От срещата на 30.10. |
| 7 | Повече проекти на същата основа | Същите папки и команди за следващ продукт, например Elemental, без копиране на ръка. |
Подробно за стъпка 3: двама на един екран
- Ани и Павлин работят всеки в своя задача, но вариантите влизат в едни и същи файлове на плейъра.
- Никой не ги предупреждава: „и друг работи тук“ има само за една и съща задача, не за един и същ екран.
- На Стената, ако двете версии сменят един ред, по-късната тихо показва основата.
- PM одобрява Ани и нейната работа влиза в общото.
- Павлин обновява и спира с „Колега е променил същото място“ плюс до 60 реда git текст. Нищо не се губи, но изборът е по код, не по картинка.
„Щом няколко души добавят фийчъри в един прототип, двама на един екран е нормалният ден. Затова решението е вариантите изобщо да не се засичат.“
Въпроси и тестовата папка
Митко си тръгва с папка, в която може да чупи на воля, и знае откъде да започне.
„Ето ти отделно копие. Нищо от него не стига до GitHub или до екипа. Започни от START-HERE: 10 минути без агента, 15 минути както работи дизайнер.“
- Веднъж:
sh scripts/setup.sh,npm --prefix prototype ci. - Без агента:
npm run dev, демото, атласът, живият прототип, пакетът за програмистите. - Като дизайнер: „нов съм“ → „Направи 2 варианта на лентата за прогрес“ → „Покажи ми“ → „Избирам Б“.
- Къде е кодът: таблица по теми.