Папките на NOISY Lab

Цялото хранилище на един лист: какво има във всяка папка, защо я има, кой пише в нея, 2-3 истински примера и кое ваше изискване покрива (цитатите са от автоматичната транскрипция на срещите, леко изчистени). Отвори която ти трябва. Всичко е проверено срещу общата версия (main) на 11.11.2026.

Едно изречение, ако имаш само 10 секунди

Всичко е в една папка в GitHub и всяко нещо има точно едно място.Дизайнерът никога не пипа папки ръчно: казва на Claude какво иска, а Claude знае къде отива всяко нещо. Папките са за това екипът, програмистите и Claude да намират едно и също на едно и също място.

Картата: всичко в хранилището, нищо пропуснато

Всяко нещо от горното ниво на хранилището е тук: плочки. Натисни плочка, за да отвориш обяснението. Отметни „Минах през това“, когато си готов, и броячът показва какво остава.

работатаизточници и правилахоратамашинатапаметта и ръководствата

Една задача през папките (истински пример: Мила, тайм стампове на плейъра)

Мила казва „нова задача“. Claude отваря отделно копие (клон task/mila/taym-stampove-na-pleyara) и записва целта в tasks/taym-stampove-na-pleyara/mila.md.
Claude чете откъде тръгва: снимките на плейъра в design-sources/, правилата в design-system/ и DESIGN.md.
Прави вариантите в демото: prototype/public/demo/app/ (плейърът е player.html, css/player.css, js/player.js).
„Покажи ми“: снимки на 390 и 1440 px отиват в versions/theatre-player/20261111091441-mila-a/. От там ги чете Стената.
PM одобрява и задачата влиза в общото. Отхвърленият вариант отива в archive/ с причината.
Какво е научил Claude за вкуса ѝ остава в designers/mila/.

1. Работата: какво правим

prototype/самият прототип, тук се рисува

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

Примери

prototype/public/demo/app/player.html + css/player.css + js/player.js: плейърът от одобреното демо. Тук дизайнерите добавят варианти (?v=a, ?v=b).
prototype/sections/theatre/filters/v1.tsx и v2.tsx: две версии на секция „Филтри“ в Theater. Нова версия е нов файл, старата не се пипа.
prototype/app/atlas/: Атласът, страница за всеки компонент и стрелки между екраните.

Защо го поискахтеИскам да видя този прототип, който имаме, само че с моя фийчър вътре, и да си го цъкам. (среща 11.11, мин. 50:43. И мин. 55:22: прототипът „ще си вкарва това по едно и ще си ги събират“)

Кой пишеClaude, в задачата на дизайнера. Влиза в общото след одобрение.

Ако питат: „Защо две места, demo и sections?“ Demo е одобреното цяло приложение (HTML), където се добавя. Sections е по-новият начин за части от екран, където всяка версия е отделен файл.

Минах през това

versions/всичко, което се вижда на Стената

Защо я имаВсеки показан вариант остава завинаги с две снимки и бележка. Стената се строи само от тази папка, затова никой не губи версия и всеки вижда кой какво е предложил.

Примери

versions/theatre-player/20261111091441-mila-a/: 390.jpg, 1440.jpg, meta.json. Вариант „а“ на Мила.
versions/arena-arena-hero/osnova/: основата, тоест как изглежда екранът преди промяна.

Какво пише в meta.json (съкратено):

"screen": "arena-arena-blok-1",
"status": "одобрено",
"author": "Основа (демо)",
"path": "/demo/app/arena.html?mode=demo",
"history": [{ "status": "чернова", ... }]

Защо го поискахтеТрябва да е на един канвас за всички тези дизайни, защото иначе се търси линк по линк. (среща 11.11, мин. 45:46. И мин. 46:43: „прави 6, 7, 8, 10 версии и за всяка дава линкове“. И мин. 35:07: статус „одобрено, чернова, отхвърлено“ с филтри)

Кой пишеClaude при всяко „покажи ми“ (design-version.mjs save). Статусът (чернова, за одобрение, одобрено) се сменя от Стената.

Минах през това

tasks/бележките на всяка задача

Защо я имаАко дизайнерът затвори лаптопа, смени модела или задачата се поеме от друг, Claude продължава оттам, където е спряно, а не от нулата.

Примери

tasks/taym-stampove-na-pleyara/mila.md:

Кой работи: Мила Проверкова
Цел: Два варианта на тайм стампове...
## Какво е направено
## Какво остава
- Избор на вариант от Мила; после архив на другия.

tasks/nastroyka-na-kompyutara/georgi.md: задачата на Георги за настройката.

Защо го поискахтеПросто да влезе в Claude и да го пита докъде стигнахме. (среща 11.11, мин. 41:05. И мин. 42:00: „ето къде съм пипала, да не почне от старата версия“)

Кой пишеClaude след всеки етап. Празна „Цел:“ не може да се предаде.

Минах през това

specs/какво трябва да прави един екран

Защо я имаДизайнът отговаря на написани случаи (С1, С2...), а не на догадки. Програмистът вижда същите случаи.

Примери

specs/theatre/browse.md: единствената спецификация засега. Раздели: цел, аудитория, зона и екран, случаи.
specs/TEMPLATE.md: празният образец, по който PM пише нова.

Защо го поискахтеТрябва малко да го насочваш какво искаш с всяка итерация. Като му казваш много генерална задача, оверскипва. (среща 11.11, мин. 09:52)

Кой пишеPM, с помощта на skill-а spec-builder.

Честен отговор, ако питат: засега има само една. Следващите се пишат по образеца.

Минах през това

2. Източниците и правилата: откъде тръгваме

design-sources/откъде тръгва всеки екран

Защо я имаClaude никога не рисува „на сляпо“. Първо поглежда как екранът изглежда сега: одобрено, демо или живо при програмистите.

Примери

design-sources/screens.json: редът на източниците е approved (Стената и Figma For DEV), после demo, после live (uplay.noisy.net).
design-sources/snimki/uplay/ и snimki/demo/: снимки на всеки екран на 390 и 1440 px.
design-sources/figma-for-dev/frames/: извадените одобрени фреймове от Figma.

Защо го поискахтеНе мога да се ориентирам кое е финалният дизайн. Затова бях помолил за линковете: по този начин го насочваме. (среща 11.11, мин. 09:52)

Кой пишеClaude. Ако снимката е по-стара от 24 часа, сам прави нова.

Минах през това

design-system/цветове, шрифтове, компоненти с одобрение

Защо я имаЕдно място за всички стойности. Ако всеки измисля своите цветове и отстояния, след месец имаме 40 нюанса лилаво. Проверка спира всяка стойност, която не е от тук.

Примери

design-system/tokens.css: --n-violet: #B61DFF; --n-magenta: #CE13A8; и спектърът от лилаво към червено.
design-system/COMPONENTS.md и components.css: бутони, карти, полета.
design-system/brand/: логото, зоните, ръководството за бранда.

Защо го поискахтеКодът трябва да е силно по-консистентен в дизайните си. (среща 11.11, мин. 45:46)

Кой пишеДизайнерите, в задача. Промяната влиза само след одобрение от човек, различен от автора.

Минах през това

DESIGN.md · PRODUCT.md · docs/COPY.mdпосоката, продуктът, текстовете

Защо ги имаТри кратки документа, които Claude чете преди всяка задача. Затова дизайнът не прилича на AI шаблон и не измисля функции, които продуктът няма.

Примери

DESIGN.md: визуалната посока и какво е забранено. Още е чернова, докато дизайнерите не я прегледат (НЛ20).
PRODUCT.md: потвърдените факти за продукта.
docs/COPY.md: как звучат текстовете в интерфейса.

Кой пишеDESIGN.md: дизайнерите с одобрение. PRODUCT.md и COPY.md: само с одобрение от PM.

Минах през това

decisions/какво е решено и защо

Защо я имаЗа да не спорим два пъти за едно и също. Всяко решение има номер, дата и статус.

Примери

НЛ8 · 02.11.2026 · Retire old Theater variants · accepted
НЛ19 · Type scale to check against Figma · open
НЛ20 · Designer review of DESIGN.md · open

Кой пишеPM.

Минах през това

3. Хората: всеки има свое място

designers/ · pm/профил и вкус на всеки

Защо я имаClaude помни как работи всеки човек, без вкусът на един да става правило за всички. „Обичам въздушно“ на Мила не променя дизайна на Павлин.

Примери

designers/_template/profile.md: роля, име, Git имейл, зони (Discover, Theater, Arena...).
pm/kostadin-pavlov/taste/taste.md: референциите и вкусът ти.
.../learnings.md: къде се е спънал човекът, например повторен въпрос или отхвърлен вариант, за да не се повтори.

Защо го поискахтеДа си вземаме един от друг промптовете и да се учим един от друг. (среща 11.11, мин. 46:43)

Кой пишеClaude, само с това, което човекът е казал. Профилът се създава при първия старт.

Минах през това

4. Машината: правилата за Claude и проверките

AGENTS.md · CLAUDE.mdинструкцията на Claude с одобрение

Защо я имаВсеки Claude (и Codex) на всеки компютър в екипа чете едни и същи правила. Затова Мила и Павлин получават еднакво поведение.

Примери

„Когато дизайнерът поиска варианти, направи ги на един адрес с ?v=a, ?v=b...“
„Говори на човека с неговите думи: линк, вариант, Стената. Не споменавай клонове и папки.“
„Нищо не се трие, остарялото отива в archive/.“

Защо го поискахтеСтруктура на папките, така че каквото и да напишат, да не могат да счупят много. (среща 30.10, извлечено от бележките)

Кой пишеСамо с одобрение от PM (НЛ27). Ако някой се опита да го промени, Claude го спира.

Минах през това

.agents/skills · .claude/уменията на Claude

Защо я имаГотови процедури за честите неща, за да не ги обяснява всеки път наново.

Примери

design: входът за всяка дизайн задача (източник → вземи, добави или преработи → проверки).
clone-reference: „направи го като в Apple TV“. Мери референцията и я превежда на NOISY.
noisy-review: строгият преглед преди показване.

Кой пишеОбщите умения: с одобрение от PM. Личните: в папката на човека.

Минах през това

scripts/командите, които Claude пуска с одобрение

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

Примери

scripts/task.mjs: start, save, show, update, review. Целият живот на задачата.
scripts/design-version.mjs save: снима варианта и го слага в versions/, тоест на Стената.
scripts/check-design.mjs: спира цвят или размер, който не е от дизайн системата.
scripts/hooks/guard-foundation.mjs: пазачът, който не дава да се пипат основните правила без одобрение.

Кой пишеСамо с одобрение от PM.

Минах през това

.github/какво става сам в GitHub

Защо я имаСтената, линковете за преглед и проверките стават сами при всеки запис. Никой не пуска нищо на ръка.

Примери

workflows/pregled.yml → pregled-deploy.yml → stena.yml: при запис в задача прави линк за преглед и обновява Стената, за около 1 минута.
workflows/checks.yml: проверките преди сливане.
team.json, designers.json, approvers: кой е в екипа и кой одобрява.

Защо го поискахтеКато се логнеш като PM или developer, автоматично виждаш кое е For Dev. Одобри ли се, светва някъде и си стои. (среща 11.11, мин. 38:02)

Кой пишеСамо с одобрение от PM.

Минах през това

tests/автоматични проверки

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

Примери

tests/figma-for-dev/run.mjs: проверява извадените фреймове от Figma.
scripts/test-*.mjs: тестове на самите команди. Например „PM слива Ани, а обновяването на Павлин спира с конфликт и човек избира“.

Минах през това

.codex · .impeccable · .mcp.json · package.json · vercel.json · .gitignoreтехническите настройки с одобрение

Защо ги имаМалки файлове, които правят така, че всичко горе да работи еднакво на всеки компютър. Дизайнерът не ги вижда.

Примери

.codex/hooks.json: същите пазачи и за Codex (ChatGPT), не само за Claude. Работата не зависи от един модел.
.impeccable/config.json: настройката на проверката срещу „AI дизайн“.
.mcp.json: връзката на Claude с Figma, за „прати във Figma“.
package.json, vercel.json, .gitignore: командите на проекта, настройката за преглед и кое не се качва в GitHub.

Минах през това

5. Паметта: нищо не се губи

archive/отхвърленото и остарялото

Защо я имаНищо не се трие. Отхвърленият вариант остава с причината, за да не го предложим пак и за да може да се върне.

Примери

archive/2026-11-02-theatre-variants/: старите варианти на Theater, с README.md защо са махнати (решение НЛ8).
archive/2026-11-04-design-task/: старият начин за задачи, заменен от task.mjs.

Защо го поискахтеКазваш: харесва ми версия 3 и версия 5, останалите в архива. Да ви е чист канвас. (среща 11.11, мин. 42:00)

Кой пишеClaude, при „избирам вариант Б“: другите отиват тук.

Минах през това

README.md · ZA-ZHORKATA.md · TASK-HANDOFF.md · docs/ръководства за хора

Защо ги имаЗа човека, който отваря проекта за първи път, и за програмистите.

Примери

docs/FOR-DEV.md: какво получава програмистът.
docs/DESIGNER-WORKFLOW.md: работният ден на дизайнера.
docs/VERSIONS.md: как работят версиите и Стената.

Минах през това

Прототипът: как изглежда всичко това на живо

Три места, които показваш.

Стената: всички версии на всички екрани на един канвас, със статус. Отговорът на „линк по линк“.
Живият прототип на Стената: целият сайт, а за всяка секция избираш коя версия да е вътре. Изборът стои в адреса, значи нацъкваш и пращаш линка. Отговорът на мин. 50:43 и 59:12 („нацъкате настройките, копирате линка и пращате“). готов, чака сливане
Демото (prototype/public/demo/app): одобрената основа, върху която се добавя.

Следващи стъпки за имплементация

Сливане на живия прототип чака решениеСменяеми секции и линк, който пази избора. Готово и тествано в PR #44.
Записите в GitHub на английски чака решениеПазачът спира нов запис на кирилица, а в репото има речник за българските имена. Готово и тествано в PR #45. Старата история остава.
Двама на един екран без конфликтиВсеки вариант в свои файлове, предупреждение при старт „Ани също работи по плейъра“, отделна стъпка за вкарване в основата. Обяснено на noisy-dvama-edin-ekran.pages.dev.
Стената по пътя на зрителя и със състояниятаЕкраните подредени по реда, в който ги минава зрителят, и всеки компонент с hover, зареждане, грешка. Отговор на мин. 35:07.
Споделени промптове и уменияДобрият промпт на един дизайнер става умение за всички, с одобрение. Отговор на мин. 46:43. Започнато, още не е предложено за сливане.
Статусът на програмистите на всеки екранНе само „одобрено в дизайна“, а и докъде е в разработката. От срещата на 30.10.
Повече проекти на същата основаСъщите папки и команди за следващ продукт, без да се копира всичко на ръка.

Речник: българските имена в репото

Ако Митко пита „какво е stena, osnova, pregled“.Някои папки, автоматики и статуси са с български имена на латиница. Остават така, защото скриптовете и линковете сочат към тях. Пълният речник е в репото: docs/GLOSSARY.md. Старите записи в GitHub са частично на български и историята не се пренаписва. От 11.11 пазачът държи новите записи на английски.

В репото	На български	На английски
`stena`	Стената	the Wall
`osnova`	основа	base
`snimki`	снимки	screenshots
`pregled`	преглед	preview / review
`odobrenie`	одобрение	approval
`lichno`	лично	personal
`izvestie`	известие	notice
`ZA-ZHORKATA`	за Жорката	for Zhorkata
`чернова / за-одобрение / одобрено / върнато / архив`	статусите	draft / waiting for approval / approved / returned / archived
`Одобрено-от → Approved-by`	одобрено от	approved by (редът в записа)
`НЛ / Р / С`	решение / случай	decision / spec case

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

„Дизайнерът трябва ли да знае тези папки?“

Не. Пише „нова задача“, „покажи ми“, „избирам Б“. Правилото в AGENTS.md изрично казва на Claude да не споменава папки и клонове. Папките са за Claude, за програмистите и за теб.

Минах през това

„Какво става, ако двама пипнат един файл?“

Днес Git спира второто обновяване и Claude показва двете версии. Решението е отделни файлове за всеки вариант, за да не се засичат изобщо. Обяснено стъпка по стъпка: noisy-dvama-edin-ekran.pages.dev

Минах през това

„Кое е „официалното“, ако има много версии?“

Това, което е в общото (main). Само то отива при програмистите. Всичко в задачите и на Стената със статус „чернова“ е предложение.

Минах през това

„Кои папки са заключени?“

С одобрение: design-system/ и DESIGN.md (одобрява колега, различен от автора), а AGENTS.md, CLAUDE.md, scripts/, .github/, .claude/, .agents/, PRODUCT.md и docs/COPY.md само с PM. Всичко останало се пипа свободно в задача.

Минах през това

Източник: хранилището noisy-zhorkata, общата версия (main), 11.11.2026.