Срещата за NOISY Lab: сценарий
Твоят сценарий за 60 минути и още 15 за обсъждане. Всяка тема: проблем → решение → пример → какво остава. Подробностите и снимките се отварят на място.
- 1Какво правим и за кого0–3 мин
- дизайнер → PM → програмист
- 2Как е организирано и защо3–20 мин
- едно дърво → всяка папка и за какво служи
- 3Кои искания на дизайнерите покриваме20–28 мин
- четири групи проблеми; какво е решено и какво остава
- 4Как работи на практика28–43 мин
- основа → варианти на Стената → жив прототип → предаване
- 5Какво остава да решим43–53 мин
- двама на един екран и останалите следващи стъпки
- 6Как Митко ще го провери53–60 мин; после обсъждане
- тестовата папка, пропуските и приоритетите
Преди срещата: разделите, входът и тестовата папка · 10 мин сам
Преди срещата
Всичко отворено, нищо не се търси по време на срещата.
- Тази страница.
- 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: въпросите и отговорите, само за теб, не го показвай.
- PR #44, живият прототип: слят. Показваш го направо на общата Стена.
- PR #45, записите в GitHub на английски: слят. Новите записи са само на английски, речникът е в
docs/GLOSSARY.md. - Отвори предварително прототипа на Стената и смени една версия, за да си сигурен, че тръгва.
Готова е тук: ~/ClaudeCodeFirst/.tmp/mitko-proba.zip (241 MB). Вътре е отделно копие на проекта, от което нищо не стига до GitHub. Първо се чете START-HERE.md. Проверено след разархивиране на чисто място.
Отваряне: какво е и защо го има
Митко трябва да разбере кой работи тук, какво произвежда и как стига до следващия човек.
Снимка за подготовката: noisy-lab-overview.pages.dev, горната част
„Правим обща работна среда за дизайнерите, PM и програмистите. Дизайнерът разработва варианти с агент върху прототипа, PM избира кое е одобрено, а програмистът получава конкретната версия за изпълнение.“
„Всичко е в една папка в GitHub и всяко нещо има точно едно място. Дизайнерът не пипа папки, но програмистите и агентът ги намират на едно и също място. Сега ще покажа къде се пазят работата и правилата.“
- Само заглавието и „What changes“. Не чети прегледа, той е за после.
Папките: за какво служи всяка
Къде пазим работата, правилата и решенията, така че нищо да не се губи.
„Всичко е в една обща папка на проекта. Вътре всяко нещо има свое място: дизайнът, задачите, правилата и решенията. Така всеки човек и агент намира едно и също, вместо да го търси по чатове и лични файлове.“
Следвай дървото отгоре надолу. Текстът пред всяка група е за разказване; редовете показват за какво служи всяка папка. Натисни ред за подробности.
noisy-zhorkata/Общата папка на проекта в GitHub.
1. Къде се прави дизайнът и се пази задачата
„Започваме с работата на дизайнера. Той получава задача и прави промяната върху работещия прототип. Пазим какво трябва да се направи, самия дизайн и вариантите за сравнение. Така при следващо отваряне продължаваме от същото място.“
Пример: променяме лентата на плейъра. Задачата е в tasks/, екранът е в prototype/, а показаните варианти са във versions/.
prototype/Самият прототип: жив сайт, не картинка.
public/demo/app/Екраните на одобреното приложение, върху които се правят промените.
Проблемът, който махаме: Всеки започва от празен лист и дизайнът се отклонява от одобреното.
Защо е така: Новото се добавя върху одобреното, затова остава консистентно.
Пример: 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 нюанса лилаво.
Защо е така: Един източник, а проверката спира всяка стойност, която не е оттук. По Р18: одобрение от PM или двама дизайнери; авторът не се брои.
Пример: 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. По Р18 промени в системата одобряват двама от PM, Митко, Жорката и Костадин. Локалните пазачи предпазват от грешка; задължителното одобрение се налага в GitHub.
Пример: „Говори с думи като линк, вариант, Стената. Не споменавай клонове и папки.“
.agents/ · .claude/Уменията и настройките на агента.
Проблемът, който махаме: Всяка процедура се обяснява наново и всеки път излиза различно.
Защо е така: Готови процедури: design, clone-reference, noisy-review. Добрият промпт става умение за всички.
.codex/Настройките и защитите при работа с Codex.
Проблемът, който махаме: Правилата важат само за единия модел.
Защо е така: Работата не зависи от един доставчик.
Пример: hooks.json
scripts/Командите, които агентът пуска.
Проблемът, който махаме: Моделът помни стъпките различно всеки път.
Защо е така: Каквото трябва да става еднакво, е код. Промените в системата следват одобрението по Р18.
Пример: task.mjs (start, save, show, update, review), design-version.mjs, check-design.mjs, hooks/guard-foundation.mjs
.github/Автоматичното публикуване на прегледи и правилата за одобрение.
Проблемът, който махаме: Ръчно пускане на прегледи и забравени стъпки. „Да светне кое е For Dev“ (мин. 38:02).
Защо е така: При всеки запис линк за преглед и обновена Стена за около минута, без човек.
Пример: workflows/pregled.yml → stena.yml, team.json, approvers
tests/Автоматичните проверки.
Проблемът, който махаме: Счупен инструмент стига до дизайнера.
Защо е така: Доказва, че инструментите работят, преди някой да ги ползва.
Пример: figma-for-dev/run.mjs и scripts/test-*.mjs
.impeccable/Настройки за проверката на визуалното качество.
Проблемът, който махаме: Шаблонен 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 казва докъде е проектът.
„Това е цялата организация: работата има място, агентът има общи правила, хората имат свои профили, а решенията се пазят. Сега ще покажа кои проблеми на дизайнерите решава това.“
Допълнително: снимка, отделна карта и пример с файловете
Снимка за подготовката: noisy-papkite.pages.dev: всяка плочка отваря обяснението си, броячът показва колко остават
Примерът с лентата на плейъра: точните файлове
- Мила казва „нова задача“. Агентът отваря отделно копие (клон
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/.
Кажи: „Мила не е видяла нито една от тези папки. Тя е казала три изречения.“
„Дизайнерът трябва ли да знае тези папки?“ Не. Пише „нова задача“, „покажи ми“, „избирам Б“. Папките са за агента, програмистите и PM.
„Кои са заключени?“ По Р18: версия към DEV одобрява PM, заместник е Митко. Дизайн системата: PM или двама дизайнери, без автора. Системните правила, умения и скриптове: двама от PM, Митко, Жорката и Костадин. Задължителните одобрения се налагат в GitHub; локалните пазачи са защита от грешка.
„Защо имената са на български?“ Скриптовете и линковете сочат към тях. Речникът е в docs/GLOSSARY.md, новите записи в GitHub са на английски.
Защо: дизайнерите го поискаха
За всяко искане различи какво покриваме днес и какво още трябва да изградим.
„Ето как тази организация отговаря на срещите с дизайнерите. Някои неща вече се показват, други още са следващи стъпки.“
- Да започваме от правилната основа. „Кое е финалното?“, прекалено общите задачи и непоследователният код: източници, конкретни случаи и дизайн система. Общите визуални правила още чакат преглед от дизайнерите.
- Да намираме, сравняваме и продължаваме работата. Статуси, бележка по задачата, архив и общо място за вариантите. Подреждането по пътя на зрителя и пълните състояния остават следваща стъпка.
- Да виждаме промяната в целия продукт. Живият прототип позволява избор на версия и споделяне на избора с линк. Отделен проблем остава безопасното събиране на работата на двама по един екран.
- Да работим като екип. Одобрение и предаване към програмистите, защита на общите правила и споделяне на добри промптове. Споделените умения са започнати; статусът при програмистите остава за добавяне.
Всичките 13 искания: цитати, минути и връзка с решението
| Казаха | Кога | Отговорът в системата |
|---|---|---|
| „Не мога да се ориентирам кое е финалният дизайн.“ | 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 Основата: откъде започва дизайнерът · 3 мин
Снимка за подготовката: prototype/public/demo/app/player.html?id=harry
prototype/public/demo/app/player.html?id=harry„Това е одобреното приложение 1:1. Дизайнерът не започва от празен лист, а добавя върху него.“
- Покажи
?data=edge: дълги текстове и липсващи данни. Програмистът вижда и неудобните случаи.
4.2 Стената: къде намираме и сравняваме вариантите · 5 мин
Снимка за подготовката: Стената: кой какво прави сега, какво чака избор, модулите
„Това е отговорът на „линк по линк“. Всеки вариант, на всеки екран, със статус и кой го е направил.“
- „Сега работят“: Мила, тайм стамповете на плейъра.
- Отвори един екран от „Модули“.
Снимка за подготовката: Един екран: снимки 1440 и 390, статус, „На канваса“, „Промпт за Figma“
„За всяка версия: снимки на телефон и компютър, бележка, статус. Оттук PM одобрява и оттук върви към Figma.“
4.3 Живият прототип: как промяната стои в продукта · 5 мин
Снимка за подготовката: Преди: плейърът с „Основа (както в main)“
Снимка за подготовката: След: избран „Мила, вариант b“, лентата става на глави
„Избирам варианта на Мила и виждам промяната вътре в прототипа. Изборът стои в адреса, така че мога да споделя точно тази комбинация.“
- Отвори „Прототипът“, таб „Плейър“.
- В „Секции на страницата“ смени „Основа“ на „Мила Проверкова, вариант b“. Плейърът се сменя на място.
- Покажи адреса:
?pp=player&pv=…mila-b. Този линк показва същото на всеки.
4.4 Предаването: какво получават PM и програмистът · 2 мин
Върни се към конкретната версия на Стената: автор, статус, снимки на телефон и компютър и връзката към Figma. Разграничи „одобрено в дизайна“ от „изпълнено от програмистите“: вторият статус още е следваща стъпка.
Преход: „Това можем да покажем днес. Остава да решим как няколко души работят безопасно и как проследяваме изпълнението.“
Резервен вариант при проблем с входа или интернет
node scripts/stena-build.mjs --worktree --out prototype/public/stena, после npm run dev и localhost:3210/stena/prototip.html?pp=player. Снимките горе са направени точно така.Следващи стъпки за имплементация
Какво е слято днес, какво е открито днес и какво идва след това.
| # | Стъпка | Какво значи |
|---|---|---|
| 1 | Живият прототип слято 11.11 | Сменяеми секции и линк, който пази избора. PR #44, вече е на общата Стена. |
| 2 | Записите в GitHub на английски слято 11.11 | Пазачът спира нов запис на кирилица, речник за българските имена. PR #45, тестове 332 от 332. |
| 3 | Двама на един екран без конфликти следващото | Всеки вариант в свои файлове, предупреждение „Ани също работи по плейъра“, отделна стъпка за вкарване в основата. Подробно отдолу. |
| 4 | Стената по пътя на зрителя и със състоянията | Екраните подредени по реда, в който ги минава зрителят, всеки компонент с hover, зареждане, грешка. Отговор на 35:07. |
| 5 | Споделени промптове и умения започнато | Добрият промпт на един дизайнер става умение за всички, с одобрение. Отговор на 46:43. |
| 6 | Статусът при програмистите на всеки екран | Освен „одобрено в дизайна“, и докъде е в разработката. От срещата на 30.10. |
| 7 | Повече проекти на същата основа | Същите папки и команди за следващ продукт, например Elemental, без копиране на ръка. |
Първите две стъпки са отбелязани като изпълнени в сценария от 11.11. Показа ги в демото. Тук ги спомени като отправна точка, после обясни оставащите пет: проблем → предложена промяна → как ще проверим, че работи.
Основният оставащ случай: двама на един екран · 6 от 10 мин
Проблем: отделните задачи още могат да променят едни и същи файлове на плейъра.
Предложение: отделни файлове за вариантите, видимост кой работи по екрана и отделно вкарване на избраното в основата.
Как да приемем решението: двама правят варианти на един екран; двата остават достъпни; PM избира единия; другият може да продължи след обновяване, без загуба на работа. Това е критерий за бъдеща проверка.
Подробното разиграване: как възниква конфликтът днес
Снимка за подготовката: noisy-dvama-edin-ekran.pages.dev: табове „Днес“ и „Решение“, стрелките минават по стъпките
- Ани и Павлин работят всеки в своя задача, но вариантите влизат в едни и същи файлове на плейъра.
- Никой не ги предупреждава: „и друг работи тук“ има само за една и съща задача, не за един и същ екран.
- На Стената, ако двете версии сменят един ред, по-късната тихо показва основата.
- PM одобрява Ани и нейната работа влиза в общото.
- Павлин обновява и спира с „Колега е променил същото място“ плюс до 60 реда git текст. Нищо не се губи, но изборът е по код, не по картинка.
„Щом няколко души добавят фийчъри в един прототип, двама на един екран е нормалният ден. Затова решението е вариантите изобщо да не се засичат.“
Преход: „Остава да уточним кои от тези стъпки са първи и как Митко ще провери средата сам.“
Въпроси и тестовата папка
Митко си тръгва с папка, в която може да чупи на воля, и знае откъде да започне.
- Попитай Митко дали пътят дизайнер → PM → програмист е ясен и къде вижда пропуск.
- Уточнете приоритета на оставащите стъпки и кой ще участва в пробата с двама дизайнери.
- Покажи откъде започва самостоятелният тест. Самото разиграване от 25 минути е след срещата, освен ако решите да отделите време за него.
Снимка за подготовката: noisy-mitko-qa.pages.dev: само за теб. Оранжевата линия е там, където честният отговор е „още не“.
„Ето ти отделно копие. Нищо от него не стига до GitHub или до екипа. Започни от START-HERE: 10 минути без агента, 15 минути както работи дизайнер.“
- Веднъж:
sh scripts/setup.sh,npm --prefix prototype ci. - Без агента:
npm run dev, демото, атласът, живият прототип, пакетът за програмистите. - Като дизайнер: „нов съм“ → „Направи 2 варианта на лентата за прогрес“ → „Покажи ми“ → „Избирам Б“.
- Къде е кодът: таблица по теми.