chore(retire): zone dissolved 2026-06-08 — round-table moved to consult-tier

Additive retire (файлы сохранены как исторический record). Multi-agent
round-table = K локальных read-only coworker-спавнов в worktree воркера
(consult-tier рантайма), не центральная зона. Несовместима с
federation-per-machine (Q9). Размотка: .workshop/.brainstorm/meeting-room-dissolve.md

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.archive/2026-05-05-meeting-room-redesign.md

@@ -1,230 +0,0 @@
----
-date: 2026-05-05
-topic: meeting-room-redesign
-status: draft
-type: room-meta
-promotes_to: .wiki/concepts/meeting-room-architecture.md
----
-
-# Meeting-Room Redesign — design spec
-
-## 1. Контекст
-
-`.meeting-room/` сейчас объявлена транзитной зоной (`README.md`: «❌ NO `.tasks`/`.wiki` внутри»). На практике:
-
-- В `.brainstorm/modulair-rag.md` уже копится содержательный артефакт прошедшей сессии — ему некуда уехать кроме `.archive/` или ручного копирования в глобал.
-- Реестр персон (`config/config.yaml`) — операционный конфиг без человекочитаемого вики-слоя.
-- Два типа сырья (pre-loaded research в `source/` и транскрипты в `sessions/`) разнесены по плоским папкам без общей семантики.
-- В памяти `MEMORY.md` есть открытый todo `project_extend_discipline_for_meeting_room.md` — `project-discipline` молчит про brainstorm-workspace.
-
-Цель редизайна — достроить комнату как **«микро-проект про методологию совещаний»** без превращения её в полноценный проект с локальным backlog. Опереться на Karpathy LLM Wiki pattern для структуры знаний и на `projects-meta` для связи с глобальным скоупом.
-
-## 2. Принятые решения
-
-| # | Развилка | Решение |
-|---|---|---|
-| 1 | Wiki/Tasks семантика | **B**: локальный `.wiki/` есть, локальных `.tasks/` нет |
-| 2 | Folder-миграция | **1 (чистый Karpathy)**: всё «сырое» централизовано в `.wiki/raw/` |
-| 3 | Промоушен | **C**: локальный `.wiki/concepts/` зарезервирован под room-meta; доменное идёт сразу в глобал, без hop |
-| 4 | Судьба буфера после промоушена | **(ii)**: `.brainstorm/<topic>.md` → `.archive/<date>-<topic>.md` |
-| 5 | Skill v1 | `promote-brainstorm`, `start-meeting`, `register-persona` |
-| 6 | Persona sync | **α**: писать в обе стороны имеет право только `register-persona`; `config.yaml` — SoT |
-| 7 | Project-discipline | master-only ✅, push-by-permission ✅, semver — N/A, локальные tasks — N/A |
-| 8 | Spec этого редизайна | живёт здесь, после сборки промоутим своей же системой в `.wiki/concepts/meeting-room-architecture.md` |
-
-## 3. Целевая структура
-
-```
-.meeting-room/
-├── CLAUDE.md                  ← корневой контракт работы в комнате (см. §6)
-├── README.md                  ← обновлённый, ссылка на CLAUDE.md и .wiki/
-│
-├── .wiki/                     ← Karpathy-canonical, room-meta only
-│   ├── CLAUDE.md              ← вики-схема (см. §7)
-│   ├── index.md               ← навигация
-│   ├── overview.md            ← что такое meeting-room
-│   ├── log.md                 ← хронологический лог: meetings, promotions, persona changes
-│   ├── raw/
-│   │   ├── README.md
-│   │   ├── research/          ← бывший source/: pre-loaded clippings, транскрипты внешних чатов
-│   │   └── transcripts/       ← бывший sessions/: транскрипты прошедших совещаний
-│   ├── entities/
-│   │   ├── persons/           ← карточки persona (генерируются из config.yaml)
-│   │   └── projects/          ← pointer-карточки для целевых проектов (modulair-rag, books, …)
-│   ├── concepts/              ← room-meta: методология, ретроспективы, паттерны
-│   ├── packages/              ← инструменты комнаты (runner, framework, schema)
-│   └── sources/               ← внешняя литература (Karpathy gist, фасилитация, multi-agent)
-│
-├── scenarios/                 ← runtime: frontmatter-сценарии для запуска multi-agent
-├── config/                    ← runtime: config.yaml — single source of truth для persona
-├── .brainstorm/               ← рабочий буфер: черновики, single-agent capture
-├── .archive/                  ← post-promotion: исходники из .brainstorm/, старые сценарии
-└── .claude/                   ← локальные скилы и settings.local.json
-    └── skills/
-        ├── meeting-room/
-        │   ├── promote-brainstorm/SKILL.md
-        │   ├── start-meeting/SKILL.md
-        │   └── register-persona/SKILL.md
-```
-
-**Различие `.wiki/raw/` ↔ `.brainstorm/`:** raw — immutable, append-only, сырое. `.brainstorm/` — рабочий, редактируемый, чистится промоушеном.
-
-**Различие `.wiki/concepts/` ↔ `~/projects/.wiki/concepts/`:** локальный — только про **то, как комната работает**. Глобал — доменное содержимое, рождённое в комнате.
-
-## 4. Lifecycle
-
-```
-PRE-MEETING
-  user clip          → .wiki/raw/research/<date>-<topic>.md
-  user writes        → scenarios/<topic>.md  (frontmatter: name, participants, problem)
-
-MEETING
-  start-meeting <s>  → создаёт .wiki/raw/transcripts/<date>-<topic>.md (skeleton)
-                       создаёт .brainstorm/<topic>.md (shell)
-                       логирует в .wiki/log.md
-  multi-agent run    → дописывает транскрипт в .wiki/raw/transcripts/<date>-<topic>.md
-  single-agent CSO   → ведёт активный диалог в .brainstorm/<topic>.md
-
-POST-MEETING
-  promote-brainstorm → парсит .brainstorm/<topic>.md
-                       спрашивает: room-meta или domain?
-                         room-meta → .wiki/concepts/<topic>.md
-                         domain    → ~/projects/<proj>/.wiki/concepts/<topic>.md
-                                    via mcp__projects-meta__knowledge_ingest
-                       парсит action-items, создаёт в .tasks/ target-проекта
-                                    via mcp__projects-meta__tasks_create
-                       git mv .brainstorm/<topic>.md → .archive/<date>-<topic>.md
-                       логирует в .wiki/log.md
-```
-
-## 5. Skills v1
-
-Каждый скил живёт в `.claude/skills/meeting-room/<name>/SKILL.md`. Триггер-фразы — в frontmatter `description`, чтобы автодиспетчер их подхватывал.
-
-### 5.1 `meeting-room:promote-brainstorm`
-
-**Триггеры:** «промоутни брейнсторм», «finalize `<topic>`», «выкати в вики», «promote `<topic>`».
-
-**Аргумент:** путь к файлу `.brainstorm/<topic>.md` или topic-name.
-
-**Интерактивные шаги:**
-1. Прочитать файл, показать summary (1–2 абзаца).
-2. Спросить: **room-meta** или **domain**?
-3. Если domain — спросить целевой проект; валидация `~/projects/<proj>/` существует и виден `projects-meta`.
-4. Распарсить action-items (checkbox `- [ ]`, секции «TODO», «следующие шаги», «next steps»). Показать список, дать отредактировать.
-
-**Действия (в порядке, atomic-ish):**
-1. **Промоушен контента:**
-   - room-meta: `Write` → `.wiki/concepts/<topic>.md` с frontmatter (`date`, `source: .brainstorm/<topic>.md`, `status: promoted`).
-   - domain: `mcp__projects-meta__knowledge_ingest` с target-проектом и контентом.
-2. **Создание тасок:** для каждого action-item — `mcp__projects-meta__tasks_create` с target-проектом, title, description.
-3. **Архивация:** `git mv .brainstorm/<topic>.md .archive/<YYYY-MM-DD>-<topic>.md`.
-4. **Лог:** дописать строку в `.wiki/log.md`: `<date> promoted <topic> → <destination>; created N tasks in <proj>`.
-
-**Failure modes:**
-- Целевой проект не найден / `projects-meta` недоступен → abort до любых записей.
-- Промоушен прошёл, `tasks_create` упал на N-м экшене → продолжить, в логе зафиксировать частичный успех; `.brainstorm/` **не** перемещать пока пользователь не подтвердит.
-- Файла `.brainstorm/<topic>.md` нет → abort, ничего не делать.
-
-### 5.2 `meeting-room:start-meeting`
-
-**Триггеры:** «запусти совещание `<topic>`», «start meeting `<scenario>`», «новое совещание `<topic>`».
-
-**Аргумент:** путь `scenarios/<topic>.md` или topic-name.
-
-**Шаги:**
-1. Прочитать `scenarios/<topic>.md`, распарсить YAML frontmatter.
-2. Валидация:
-   - `name`, `problem` непустые;
-   - все `participants` присутствуют как роли в `config/config.yaml`;
-   - `max_rounds` — целое (если есть).
-3. Сегодняшняя дата → `<date> = YYYY-MM-DD`.
-4. Создать `.wiki/raw/transcripts/<date>-<topic>.md` со скелетом (frontmatter: `date`, `scenario: scenarios/<topic>.md`, `participants`, `problem`).
-5. Создать `.brainstorm/<topic>.md` со skeleton (заголовок, ссылки на сценарий и транскрипт).
-6. Дописать в `.wiki/log.md`: `<date> started <topic> ({participants})`.
-7. Вернуть пользователю созданные пути и подсказку, как запустить multi-agent runner.
-
-**Failure modes:**
-- Frontmatter невалидный → перечислить ошибки, ничего не создавать.
-- `.brainstorm/<topic>.md` уже есть → спросить: продолжить (append-skip) или прервать.
-
-### 5.3 `meeting-room:register-persona`
-
-**Триггеры:** «добавь персону», «новый агент в комнату», «register persona `<role>`».
-
-**Интерактивный сбор полей:**
-- `role-id` (snake_case, уникальный)
-- `name` (display)
-- `model`, `provider`, `temperature`, `tools`, `system_prompt`
-
-**Шаги:**
-1. Прочитать `config/config.yaml`. Если `roles.<role-id>` существует — спросить: overwrite, abort, новый id.
-2. Обновить `config.yaml`, **сохраняя YAML-форматирование** (использовать YAML-парсер с round-trip — иначе комментарии и порядок ключей побьются).
-3. Сгенерировать `.wiki/entities/persons/<role-id>.md` с frontmatter (`role-id`, `model`, `provider`, `source: config/config.yaml`) и body — summary поведения роли, цитата `system_prompt`, ссылка на `config.yaml`.
-4. Дописать в `.wiki/log.md`: `<date> registered persona <role-id>`.
-
-**Sync-правило (α):** все автоматические записи в `entities/persons/` идут только через этот скил. Ручные правки разрешены только в `config.yaml`; для пере-генерации карточки — снова `register-persona <role>` (он определит, что роль уже есть, и пере-сгенерирует).
-
-## 6. Корневой `CLAUDE.md`
-
-Содержание (outline):
-
-1. **Идентичность:** «Это `.meeting-room` — workspace для кросс-проектных брейнштормов и круглых столов. Не код-проект.»
-2. **Семантика артефактов** (короткая шпаргалка из §3 + §4).
-3. **Жёсткие правила:**
-   - Доменное содержимое **никогда** не оседает в локальном `.wiki/` — всегда в глобал через `projects-meta`.
-   - Локальный `.wiki/` — только room-meta (методология, persona-карточки, лог встреч, ретро).
-   - Локальные `.tasks/` **не создавать** — экшены идут в `.tasks/` целевого проекта через `projects-meta__tasks_create`.
-   - Перед любым предложением tooling/архитектуры — прочитать `.wiki/raw/research/` для текущего топика (закрепляет `feedback_read_source_transcripts.md` из памяти).
-4. **Триггеры скилов v1:** перечень фраз → скил.
-5. **Override `project-discipline`:**
-   - master-only ✅
-   - commit freely / push by permission ✅
-   - semver-bump — N/A (нет versioned-артефактов в комнате)
-   - локальные `.tasks/` — N/A (запрещены §6.3)
-6. **Persona registry:** SoT — `config/config.yaml`. Карточки `.wiki/entities/persons/` — производное, пишется только скилом `register-persona`.
-
-## 7. `.wiki/CLAUDE.md` (схема)
-
-Karpathy-канон от `setup-wiki` + meeting-room-специфика:
-
-- `entities/persons/<role-id>.md` — frontmatter обязателен (`role-id`, `model`, `provider`, `source`); body — summary и цитата system_prompt.
-- `entities/projects/<proj>.md` — pointer-карточка к глобальному проекту (минимум: путь, краткая роль в контексте комнаты, ссылки на встречи где он фигурировал).
-- `concepts/<topic>.md` — room-meta: методология, ретро. Frontmatter: `date`, `source: .brainstorm/<topic>.md` (или `.archive/...`).
-- `raw/research/<date>-<topic>.md` — внешний clipping. Frontmatter: `date`, `source` (URL), `topic`.
-- `raw/transcripts/<date>-<topic>.md` — транскрипт встречи. Frontmatter: `date`, `scenario`, `participants`.
-- `log.md` — append-only, формат: `<date> <event-type> <topic> [details]`.
-
-## 8. Migration plan
-
-### 8.1 Существующие папки
-
-| Источник | Назначение | Способ |
-|---|---|---|
-| `source/2026-05-03-modulair.md` | `.wiki/raw/research/2026-05-03-modulair.md` | `git mv` |
-| `source/2026-05-03-code-review.md` | `.wiki/raw/research/2026-05-03-code-review.md` | `git mv` |
-| `sessions/` (пусто) | `.wiki/raw/transcripts/` (пусто) | создать новую |
-| `.archive/` (пусто) | остаётся `.archive/` | без изменений |
-| `scenarios/` | остаётся `scenarios/` | без изменений |
-| `config/` | остаётся `config/` | без изменений |
-| `.brainstorm/modulair-rag.md` | особый кейс — см. §8.2 | через `promote-brainstorm` (первый прогон) |
-| `README.md` | обновить: ссылки на `CLAUDE.md`, `.wiki/`, удалить устаревшее правило «❌ NO `.wiki` внутри» | edit |
-
-### 8.2 `modulair-rag.md` — особый кейс
-
-Содержимое — process trace прошедшей single-agent сессии. Финальный design уже лежит в `~/projects/.wiki/concepts/modulair-rag-design.md` (упомянут в шапке самого файла). То есть **доменный layer уже промочен**, что осталось в `.brainstorm/` — это методологический след: «как развивался брейнсторм, какие развилки выбрали, что отвергнуто и почему».
-
-Это room-meta. Назначение при промоушене — `.wiki/concepts/modulair-rag-brainstorm-trace.md` (или похожее имя). Тасок не порождает (всё доменное уже зафиксировано). Исходник → `.archive/2026-05-05-modulair-rag.md`.
-
-Использовать как первый end-to-end тест `promote-brainstorm`.
-
-### 8.3 Spec этого редизайна
-
-После сборки структуры и v1-скилов — прогнать `meeting-room:promote-brainstorm` на самом этом файле. Назначение: `.wiki/concepts/meeting-room-architecture.md`. Тасок не порождает (план реализации идёт через `writing-plans` отдельно). Исходник → `.archive/2026-05-05-meeting-room-redesign.md`.
-
-## 9. Открытые вопросы (не блокируют реализацию)
-
-- **Имя файла промо для `modulair-rag.md`** — `modulair-rag-brainstorm-trace.md` рабочая идея, финальное при первом прогоне.
-- **Парсер action-items в `promote-brainstorm`** — начнём с regex по `- [ ]` и явным секциям; LLM-парсер только если regex окажется недостаточным.
-- **Что писать в `entities/projects/<proj>.md`** — формат карточки утрясём после первой реальной встречи post-redesign (сейчас нет данных).
-- **Расширение `project-discipline` для brainstorm-workspaces** — после стабилизации этой комнаты подать как PR в сам `project-discipline` (закрытие memory-todo `project_extend_discipline_for_meeting_room.md`).

.archive/2026-05-05-modulair-rag.md

@@ -1,178 +0,0 @@
-# ModulAIr RAG — brainstorm capture
-
-> Captured 2026-05-05 in single-agent session inside `.meeting-room/`.
-> Source scenario: `scenarios/modulair.md` (4-agent meeting frontmatter, не запускалось — пользователь предпочёл одного собеседника).
-> Prior multi-agent transcript: `source/2026-05-03-modulair.md` — там пользователь с другим ассистентом прошёл первый круг и накопил пул tooling-кандидатов (Marker, Repomix, ArchiveBox, Memos, Hermes-agent, и др.).
-> Mature design: `~/projects/.wiki/concepts/modulair-rag-design.md` — этот файл фиксирует процесс, не финальное решение.
-
----
-
-## Контекст ModulAIr
-
-ModulAIr — AI-управляемый секвенсор/контроллер для еврорэка на Pico 2 W. Декомпозирован на 6 sub-projects:
-
-- `modulair-hw` — KiCad PCB (Pico 2 W + DAC + Gate-drivers + ADC + MIDI TRS + audio preamp + eurorack-питание)
-- `modulair-fw` — прошивка Pico 2 W
-- `modulair-script` — Teletype-style DSL + интерпретатор
-- `modulair-mcp` — MCP-мост между LLM и Pico
-- **`modulair-rag`** — база знаний ◄ предмет этого брейнсторма
-- `modulair-agent` — Hermes-агент как top-level orchestrator
-
-**Сквозная архитектурная развилка решена: Variant A — Pico-autonomous, LLM-conductor.** Pico исполняет скрипты sample-accurate, LLM через MCP мутирует паттерны/скрипты, но не сидит в горячем audio-пути. Wi-Fi latency перестаёт быть проблемой.
-
-## RAG-решения и почему
-
-### Стратегия — c-tiered (а не плоский vector RAG)
-
-Чисто вектор-RAG плох на factual-лукапах в синт-домене:
-- Эмбеддинги "0–8V" / "±5V" / "0V to 10V" близки в семантическом пространстве, но это разные факты
-- Отрицание ("у X нет Reset-входа") не работает — ретривер тащит чанки где есть "Reset" и "X" рядом
-- Сравнения требуют JOIN, а не top-k retrieval
-- Чанкинг ломает таблицы datasheet'ов
-
-→ **Tier 1** vector (manuals / theory / VCV source / forum threads) — recall-heavy, fuzzy.
-→ **Tier 2** structured Postgres (module specs из ModularGrid + vendor parsers) — precision-heavy, точные ответы.
-→ **Tier 3** ручные аннотации (~50 модулей личного рэка, calibration quirks, undocumented behavior).
-
-### Storage
-
-- **Postgres (cloud, существующий)** для Tier 2/3. **Не MariaDB:** JSONB для переменной формы jack-списков, pgvector как открытая дверь, recursive CTE + lateral joins зрелее, array-типы родные, MCP/ORM-экосистема Postgres-first.
-- **LightRAG #2 (новый instance с `working_dir=modulair-rag`)** для Tier 1. Текущий LightRAG-корпус не трогаем — он для других задач.
-- **Не pgvector unified** — это потребовало бы миграцию текущего LightRAG.
-- **Не Neo4j** — overkill для тысяч модулей; relations моделируются плоскими таблицами.
-
-### Scope первой итерации — (II) MVP на full-scrape ModularGrid
-
-~15k модулей, ~1 месяц. Альтернативы: (I) Top-50 за 2 недели — учиться на знакомом; (III) всё сразу за 1.5–2 мес. Выбрано (II) — компромисс между амбицией и сроками.
-
-Что меняется при этом скоупе:
-- **Per-field provenance обязательна** — без неё не отличить достоверный ±5V от LLM-угадки
-- **LLM-extraction как этап pipeline** — jacks/polarity/range живут в свободном тексте описаний и manual PDF, нужен LLM-проход по 15k
-- **Validation gates first-class** — voltage standards становятся правилами (audio типично ±5V, anomaly → флаг)
-
-### Pipeline — immutable layered (L1-L4)
-
-```
-L1  raw HTML        → MinIO bucket, content-addressed (sha256)
-L2  DOM extracts    → JSONL/run, структурные поля (HP, manufacturer, current_ma)
-L3  LLM extracts    → JSONL/run, jacks/polarity/range из свободного текста
-L4  Postgres        → "current state", собран из L2+L3+Tier-3
-```
-
-Зачем слоями: на MVP схема меняется ~5×, LLM-промпт ~10×. Без immutable слоёв каждое изменение = повторный scrape (медленно, rate-limit) + LLM-проход (дорого). С immutable — пере-extract из L2/L3 за минуты.
-
-### Source стратегия — multi-source
-
-```
-1. Vendor-side parsers (top-10):
-   pichenettes/eurorack (canonical Mutable), Make Noise, Intellijel,
-   Doepfer, ALM, Noise Engineering, Befaco, 4ms, Erica, Tiptop
-2. ModularGrid scrape (HTML, ≤1 RPS, weekly cron)
-   robots.txt allow модули и .json; их официальный API паузнут из-за EU copyright reform
-3. Tier 3 — ручные аннотации (~50 модулей личного рэка)
-```
-
-Не зависимы от ModularGrid одного — фрагильно (DOM может смениться, anti-scrape, юр. неопределённость).
-
-### Extractor LLM — Ollama Cloud sample first, не Haiku
-
-Решение: первый прогон через Ollama Cloud (GLM-5.1 / qwen) на golden set, валидация против Haiku 4.5 как benchmark. Если разница <5pp на ключевых метриках — Ollama, бесплатно. Если ≥10pp — Haiku-tiered с Sonnet 4.6 на flagged записях.
-
-**Golden set protocol** (1–2 дня ручной работы):
-- ~40 модулей: 20 Mutable (pichenettes/eurorack), 10 Doepfer, 5 Make Noise/Intellijel, 5 edge-case
-- JSON-эталон per модуль: `{name, direction, signal_type, polarity, range_v_min, range_v_max}`
-- Метрики/пороги: F1 signal_type ≥0.85, Acc polarity ≥0.85, MAE range ≤0.5V, hallucination ≤5%, miss ≤15%
-- Артефакты в git: `golden/`, `runs/<model>/`, `metrics/`
-
-### Provenance — module_facts + materialized consensus view
-
-```sql
-module_facts (
-  module_id, field, value JSONB, confidence REAL,
-  source_layer  -- 'L2-dom' | 'L3-llm-haiku' | 'L3-llm-sonnet' | 'tier3-manual'
-  source_ref,   -- 'scrape-2026-05-05/mutable-rings.json#desc-jacks'
-  scraped_at
-)
-```
-
-Плоские `modules` / `jacks` — materialized view "consensus" поверх highest-confidence values. MCP читает плоский view, валидатор/админка — `module_facts` напрямую. Альтернатива (`<col>_confidence`/`<col>_source` рядом) отвергнута — на 30+ полях шум.
-
-### Tier 1 corpus — phased
-
-**Phase 1 (MVP):** ModularGrid descriptions всех 15k (из L1) + top-100 vendor manuals + VCV Rack Fundamental/Library source + 30–50 hand-curated theory статей.
-**Phase 2 post-MVP:** vendor manuals top-500, YouTube whisper-транскрипты топ-creator'ов, selected forum threads.
-**Phase 3:** long-tail manuals, full forum scrape с quality filter.
-
-### Deploy shape — Docker compose, своё железо
-
-Existing: Postgres, Traefik, Portainer, kicad-mcp (для других sub-projects).
-
-5 новых контейнеров для modulair-rag:
-1. `lightrag-modulair` — Tier 1 vector, working_dir отдельный
-2. `minio` — L1 raw HTML cache, content-addressed
-3. `modulair-pipeline` — scraper + extractor + loader, cron внутри
-4. `tier1-converter` — Marker + Repomix + Firecrawl batch jobs
-5. `modulair-mcp` — MCP-сервер для Hermes (`module_spec`, `concept_search`, `module_compare`, `module_pairs`, `module_text`, `rack_modules`, `provenance`)
-
-### Orchestration — Hermes, не n8n
-
-Hermes-agent живёт в отдельном sub-project и через MCP зовёт наш `modulair-mcp` + (будущий) `firmware-mcp` + собственные Python-skills для batch (`run_repomix`, `run_marker`). n8n из плана убран — дублирует Hermes.
-
-Phases:
-- Phase 1 — cron внутри контейнеров
-- Phase 2 — Changedetection.io webhooks → Hermes scheduled-automations
-- Phase 3 — расширение Hermes skills (multi-source priorisation, feedback-loop из Memos/Obsidian, vendor-парсеры как skills)
-
-## Что отвергнуто и почему
-
-| Отвергнуто | Причина |
-|---|---|
-| Pure vector RAG (c-flat) | Factual-лукапы галлюцинируют; embeddings не различают voltage ranges |
-| Postgres + pgvector unified (α) | Заставит мигрировать существующий LightRAG-корпус |
-| MariaDB | JSONB и pgvector будущего — типпинг-пойнт за Postgres |
-| Neo4j | Overkill для тысяч модулей; relations плоско моделируются |
-| n8n | Дублирует Hermes-agent |
-| markitdown как primary | Marker лучше PDF, Repomix лучше код, Firecrawl лучше JS-сайты |
-| tree-sitter primary chunking | Repomix даёт structure-aware MD из коробки |
-| DVC | pg_dump + content-addressed MinIO покрывают provenance |
-| kicad-mcp в modulair-rag | Out of scope; живёт в modulair-agent / modulair-hw |
-| ArchiveBox в MVP | Heavy (Docker+Chrome+Node), своя scraper-реализация дешевле для targeted-scrape |
-
-## Открытые вопросы (не блокируют MVP)
-
-- Финальный размер golden-set (40 принято; ужесточение MAE до 0.2V для CV-модулей — после первого прогона)
-- Music theory sources — конкретный список 30–50 статей не зафиксирован (упомянуты Allen Strange, Whitwell, SoS Synth Secrets, Eno strategies)
-- Phasing для feedback-loop (Memos / Obsidian #feedback) — Phase 2, конкретная реализация позже
-- Где физически живёт kicad-mcp (host stdio vs Docker) — релевантно для modulair-agent / modulair-hw, не для modulair-rag
-
-## Tooling из исходного транскрипта 2026-05-03
-
-Я провалил первый проход — не прочитал транскрипт перед тем как предлагать стэк. Память записана: `feedback_read_source_transcripts.md`. Финальный мерж stack'ов:
-
-| Категория | Что взято | Что отвергнуто |
-|---|---|---|
-| PDF→MD | **Marker** (primary), **LlamaParse** (fallback) | markitdown как primary, Docling (только если Marker не установится) |
-| Web→MD | **Firecrawl** (batch), **Jina Reader** (одноразовый) | Trafilatura |
-| Code→MD | **Repomix** | tree-sitter с нуля |
-| Web archive | **Wallabag** в Phase 2 | ArchiveBox в MVP, Linkwarden, Shiori |
-| Change detection | **Changedetection.io** в Phase 2 | (alone, без n8n) |
-| Orchestration | **Hermes-agent** | n8n, Huginn |
-| Data versioning | `pg_dump` + content-addressed MinIO | DVC |
-| Feedback loop | **Memos** или **Obsidian** в Phase 2 | (одно из двух) |
-| Container UI | **Portainer** (existing) | Dockge |
-| Vector store | **LightRAG** (existing для других, новый instance для modulair) | ChromaDB, Pinecone, GraphRAG |
-| Algo composition | **music21** — для modulair-agent, не RAG | — |
-| Embedded DSP | Pure Data + hvcc / Faust — для modulair-fw audio sub-project, не RAG | — |
-| EDA → MD | **kicad-mcp** существующий, для modulair-hw / modulair-agent | KiCad-CLI / KiBot — out of scope для modulair-rag |
-
-## Меморики, появившиеся за сессию
-
-- `feedback_meeting_room_workspace.md` — `.meeting-room` это brainstorm-зона, артефакты идут в `.brainstorm/` или global wiki, не через "transit-zone autopilot"
-- `project_extend_discipline_for_meeting_room.md` — открытый todo расширить project-discipline под brainstorm-workspaces
-- `feedback_read_source_transcripts.md` — `.meeting-room/source/<date>-<topic>.md` это pre-loaded user research, читать до предложения стэка
-
-## Следующие шаги
-
-1. Брейнсторм per остальным 5 sub-projects (`modulair-hw`, `modulair-fw`, `modulair-script`, `modulair-mcp`, `modulair-agent`)
-2. Когда RAG-implementation начнётся — поднять структуру репозитория `modulair-rag` где-то в `~/projects/`, скелет compose.yml, `.tasks/STATUS.md` под фактический проект
-3. Заведение golden-set (1–2 дня ручной работы — это первое что нужно сделать; в MVP это блокирующая зависимость для extractor-валидации)

.claude/skills/meeting-room-promote-brainstorm/SKILL.md

@@ -1,127 +0,0 @@
----
-name: meeting-room-promote-brainstorm
-description: Use when user says "промоутни брейнсторм", "finalize <topic>", "выкати в вики", "promote <topic>", or wants to finalize a .brainstorm/<topic>.md buffer. Asks routing (room-meta vs domain), writes to local .wiki/concepts/ OR ingests into target project's wiki via mcp__projects-meta__knowledge_ingest, extracts action-items into target project's .tasks via mcp__projects-meta__tasks_create, archives buffer to .archive/<date>-<topic>.md.
----
-
-# meeting-room-promote-brainstorm
-
-Финализирует созревший брейнсторм-буфер. По правилу C+ii из spec'а: room-meta → локальный `.wiki/concepts/`, domain → глобал через `projects-meta`; буфер уезжает в `.archive/`.
-
-## When to use
-
-- «промоутни брейнсторм», «finalize <topic>», «выкати в вики», «promote <topic>».
-- Пользователь явно ссылается на `.brainstorm/<topic>.md` как на готовый к промоушену.
-
-## Inputs
-
-- Путь `.brainstorm/<topic>.md` или просто `<topic>`.
-
-## Decision flow
-
-```
-.brainstorm/<topic>.md
-        │
-        ▼
-   read + summarize (1–2 paragraphs)
-        │
-        ▼
-ask: room-meta or domain?
-   │              │
-   │              ▼
-   │       ask: target project (validate ~/projects/<proj>/ exists)
-   │              │
-   ▼              ▼
-write to       ingest via
-.wiki/concepts mcp__projects-meta__knowledge_ingest
-   │              │
-   └──────┬───────┘
-          ▼
-   parse action-items, show, allow edit
-          │
-          ▼
-   for each: mcp__projects-meta__tasks_create
-          │
-          ▼
-   git mv .brainstorm/<topic>.md .archive/<date>-<topic>.md
-          │
-          ▼
-   append to .wiki/log.md
-```
-
-## Steps
-
-1. **Прочитать `.brainstorm/<topic>.md`.** Показать summary (≤2 абзаца).
-2. **Спросить тип:** room-meta (методология самой комнаты) или domain (доменное содержимое для какого-то целевого проекта)?
-3. **Если domain:**
-   - Спросить целевой проект (имя папки в `~/projects/`).
-   - Валидация: вызвать `mcp__projects-meta__meta_status`, убедиться что проект известен; иначе — abort с сообщением «зарегистрируй проект через setup-projects-meta».
-4. **Парсинг action-items:**
-   - regex по строкам вида `- [ ] ...`, `- [ ]`, секции после `## Следующие шаги`/`## TODO`/`## Next steps`/`## Action items`.
-   - Показать список, дать редактировать/удалять/добавлять.
-   - Если 0 action-items — продолжить, не блокировать.
-5. **Промоушен контента:**
-   - **room-meta:** `Write` → `.wiki/concepts/<topic>.md` с frontmatter:
-
-     ```yaml
-     ---
-     date: <YYYY-MM-DD>
-     source: .brainstorm/<topic>.md
-     status: promoted
-     type: room-meta
-     ---
-     ```
-
-     Тело — содержимое буфера (можно слегка причесать заголовки, секции типа TODO убрать — они уже сепарированы в action-items).
-
-   - **domain:** `mcp__projects-meta__knowledge_ingest` с параметрами:
-     - `project: <target>`
-     - `path: concepts/<topic>.md` (внутри target wiki)
-     - `content: <тело буфера с frontmatter>`
-
-     Если `knowledge_ingest` падает → abort до tasks_create и до `git mv`. Сообщить пользователю.
-
-6. **Создание тасок:** для каждого action-item:
-   - `mcp__projects-meta__tasks_create` с `project: <target>` (для domain) или с `project: <inferred-from-buffer>` (для room-meta это может быть `meeting-room` или конкретный проект упомянутый в action-item — спросить пользователя если неоднозначно).
-   - Title — первая строка action-item; description — остальное.
-   - Если N-я таска упала — продолжить остальные, в конце сообщить какие созданы / какие нет.
-7. **Архивация:**
-
-   ```bash
-   git mv .brainstorm/<topic>.md .archive/<YYYY-MM-DD>-<topic>.md
-   ```
-
-   **Только** если шаги 5 и 6 прошли (или прошли с допустимым partial — пользователь подтвердил). Иначе — оставить буфер на месте, чтобы можно было ретраиить.
-
-8. **Лог:** дописать в `.wiki/log.md`:
-
-   ```
-   <date> promoted <topic> → <destination> [created N tasks in <proj>]
-   ```
-
-9. **Финальный отчёт пользователю:**
-   - Куда промочено (полный путь).
-   - Какие таски созданы (id, title, проект).
-   - Куда уехал исходник.
-
-## Failure modes
-
-- `.brainstorm/<topic>.md` отсутствует → abort.
-- `mcp__projects-meta` недоступен → abort до записей.
-- Целевой проект (для domain) не найден в `meta_status` → abort.
-- `knowledge_ingest` упал → abort до `tasks_create` и `git mv`. Буфер остаётся.
-- `tasks_create` упал на N-й таске → продолжить остальные. Сообщить partial. **Не делать** `git mv` без подтверждения пользователя.
-
-## Side effects
-
-- room-meta: создаёт `.wiki/concepts/<topic>.md`.
-- domain: создаёт запись в target wiki через MCP.
-- Создаёт N тасок в target `.tasks/` через MCP.
-- Перемещает `.brainstorm/<topic>.md` → `.archive/<date>-<topic>.md`.
-- Аппендит строку в `.wiki/log.md`.
-
-## What NOT to do
-
-- Не писать доменное содержимое в локальный `.wiki/concepts/` (правило #1 из root `CLAUDE.md`).
-- Не создавать локальный `.tasks/` (правило #3).
-- Не делать `git mv` буфера до успеха ingest+tasks.
-- Не удалять буфер вместо `git mv` — теряется история.

.gitignore

@@ -0,0 +1 @@
+/.claude/settings.local.json

.wiki/concepts/meeting-room-architecture.md

@@ -3,131 +3,83 @@ date: 2026-05-05
 source: .brainstorm/meeting-room-redesign.md
 status: promoted
 type: room-meta
+amended: 2026-05-08 (split-rewrite — runtime only, boss-зона выделена в .workshop/.wiki/concepts/workshop-architecture.md)
 ---
 
-# Meeting-Room Architecture — promoted spec
+# Meeting-Room Architecture — promoted spec (runtime-only post-split)
 
-> Промочено 2026-05-05 из `.brainstorm/meeting-room-redesign.md`. Spec, который комната провалидировала на самой себе: первый прогон скила `meeting-room-promote-brainstorm` сделан именно над этим файлом. Implementation plan архивирован отдельно — `.archive/2026-05-05-meeting-room-redesign-plan.md`.
+> Промочено 2026-05-05 из `.brainstorm/meeting-room-redesign.md`. Spec, который комната провалидировала на самой себе: первый прогон скила `meeting-room-promote-brainstorm` сделан над этим файлом. Implementation plan архивирован отдельно — `.archive/2026-05-05-meeting-room-redesign-plan.md`.
+>
+> **2026-05-08 split-rewrite:** комната разделена на multi-agent runtime (`.meeting-room/`, эта зона) и single-agent boss-zone (`.workshop/`). Из текущего документа удалены boss-секции (`.brainstorm/`, `.archive/`, `promote-brainstorm`-скил, single-agent CSO в lifecycle, room-meta concepts) — они переехали в `.workshop/.wiki/concepts/workshop-architecture.md`. Полная исходная версия доступна в git-истории (см. commit перед 2026-05-08). Мотивация и протокол split'а: `.workshop/.wiki/concepts/meeting-room-split.md` (после step #12 миграции).
 
 ## 1. Контекст
 
-`.meeting-room/` сейчас объявлена транзитной зоной (`README.md`: «❌ NO `.tasks`/`.wiki` внутри»). На практике:
+`.meeting-room/` — multi-agent runtime для срежиссированных круглых столов: тематических совещаний с ролями (analyst, skeptic, idea_generator, moderator …), сценарием и транскриптом. Не код-проект.
 
-- В `.brainstorm/modulair-rag.md` уже копится содержательный артефакт прошедшей сессии — ему некуда уехать кроме `.archive/` или ручного копирования в глобал.
+Зона выделена под темы, которые выигрывают от **многопозиционного спора** (architect vs implementer vs PM, или иные оппозиции). Single-agent + user брэйнсторм без режиссуры — другой режим, живёт в `.workshop/`. Дистилляция транскрипт → концепт — отдельный явный handoff в `.workshop/`.
-- Реестр персон (`config/config.yaml`) — операционный конфиг без человекочитаемого вики-слоя.
-- Два типа сырья (pre-loaded research в `source/` и транскрипты в `sessions/`) разнесены по плоским папкам без общей семантики.
-- В памяти `MEMORY.md` есть открытый todo `project_extend_discipline_for_meeting_room.md` — `project-discipline` молчит про brainstorm-workspace.
-
-Цель редизайна — достроить комнату как **«микро-проект про методологию совещаний»** без превращения её в полноценный проект с локальным backlog. Опереться на Karpathy LLM Wiki pattern для структуры знаний и на `projects-meta` для связи с глобальным скоупом.
 
 ## 2. Принятые решения
 
 | # | Развилка | Решение |
 |---|---|---|
-| 1 | Wiki/Tasks семантика | **B**: локальный `.wiki/` есть, локальных `.tasks/` нет |
+| 1 | Wiki/Tasks семантика | локальный `.wiki/` есть (room-meta), локальный `.tasks/` нет (запрещён §3 в `CLAUDE.md`) |
-| 2 | Folder-миграция | **1 (чистый Karpathy)**: всё «сырое» централизовано в `.wiki/raw/` |
+| 2 | Folder-миграция | Karpathy-канон: всё «сырое» в `.wiki/raw/`, скилы — в `~/projects/claude-skills/` |
-| 3 | Промоушен | **C**: локальный `.wiki/concepts/` зарезервирован под room-meta; доменное идёт сразу в глобал, без hop |
+| 3 | Skills v1 | `meeting-room-start-meeting`, `meeting-room-register-persona` (boss-скил `workshop-promote-brainstorm` выделен в workshop-зону) |
-| 4 | Судьба буфера после промоушена | **(ii)**: `.brainstorm/<topic>.md` → `.archive/<date>-<topic>.md` |
+| 4 | Persona sync | писать в `entities/persons/` имеет право только `register-persona`; `config/config.yaml` — SoT |
-| 5 | Skill v1 | `promote-brainstorm`, `start-meeting`, `register-persona` |
+| 5 | Project-discipline | master-only ✅, push-by-permission ✅, semver — N/A, локальные tasks — N/A (запрет §3) |
-| 6 | Persona sync | **α**: писать в обе стороны имеет право только `register-persona`; `config.yaml` — SoT |
-| 7 | Project-discipline | master-only ✅, push-by-permission ✅, semver — N/A, локальные tasks — N/A |
-| 8 | Spec этого редизайна | живёт здесь, после сборки промоутим своей же системой в `.wiki/concepts/meeting-room-architecture.md` |
 
 ## 3. Целевая структура
 
 ```
 .meeting-room/
-├── CLAUDE.md                  ← корневой контракт работы в комнате (см. §6)
+├── CLAUDE.md                  корневой контракт зоны
-├── README.md                  ← обновлённый, ссылка на CLAUDE.md и .wiki/
+├── README.md
 │
-├── .wiki/                     ← Karpathy-canonical, room-meta only
+├── scenarios/<topic>.md       runtime: frontmatter сценариев multi-agent
-│   ├── CLAUDE.md              ← вики-схема (см. §7)
+├── config/config.yaml         runtime: реестр persona (SoT)
-│   ├── index.md               ← навигация
-│   ├── overview.md            ← что такое meeting-room
-│   ├── log.md                 ← хронологический лог: meetings, promotions, persona changes
-│   ├── raw/
-│   │   ├── README.md
-│   │   ├── research/          ← бывший source/: pre-loaded clippings, транскрипты внешних чатов
-│   │   └── transcripts/       ← бывший sessions/: транскрипты прошедших совещаний
-│   ├── entities/
-│   │   ├── persons/           ← карточки persona (генерируются из config.yaml)
-│   │   └── projects/          ← pointer-карточки для целевых проектов (modulair-rag, books, …)
-│   ├── concepts/              ← room-meta: методология, ретроспективы, паттерны
-│   ├── packages/              ← инструменты комнаты (runner, framework, schema)
-│   └── sources/               ← внешняя литература (Karpathy gist, фасилитация, multi-agent)
 │
-├── scenarios/                 ← runtime: frontmatter-сценарии для запуска multi-agent
+└── .wiki/                     Karpathy-canonical, room-meta only
-├── config/                    ← runtime: config.yaml — single source of truth для persona
+    ├── CLAUDE.md              wiki-схема
-├── .brainstorm/               ← рабочий буфер: черновики, single-agent capture
+    ├── index.md
-├── .archive/                  ← post-promotion: исходники из .brainstorm/, старые сценарии
+    ├── overview.md
-└── .claude/                   ← локальные скилы и settings.local.json
+    ├── log.md                 append-only хроника
-    └── skills/
+    ├── raw/
-        ├── meeting-room/
+    │   ├── README.md
-        │   ├── promote-brainstorm/SKILL.md
+    │   └── transcripts/<date>-<topic>.md   immutable: транскрипты совещаний
-        │   ├── start-meeting/SKILL.md
+    ├── entities/
-        │   └── register-persona/SKILL.md
+    │   ├── persons/<role-id>.md            карточки персон (генерируются)
+    │   └── projects/<proj>.md              pointer-карточки целевых проектов
+    └── concepts/<topic>.md                  room-meta: методология, ретро runtime'а
 ```
 
-**Различие `.wiki/raw/` ↔ `.brainstorm/`:** raw — immutable, append-only, сырое. `.brainstorm/` — рабочий, редактируемый, чистится промоушеном.
+**Boss-артефакты (`.brainstorm/`, `.archive/`, дистилляция, методология одиночного мышления) — в `.workshop/`, не здесь.**
 
-**Различие `.wiki/concepts/` ↔ `~/projects/.wiki/concepts/`:** локальный — только про **то, как комната работает**. Глобал — доменное содержимое, рождённое в комнате.
+## 4. Lifecycle (runtime-only)
-
-## 4. Lifecycle
 
 ```
 PRE-MEETING
-  user clip          → .wiki/raw/research/<date>-<topic>.md
+  user clip          → .meeting-room/.wiki/raw/research/<date>-<topic>.md
-  user writes        → scenarios/<topic>.md  (frontmatter: name, participants, problem)
+                       (если research-материал, релевантный совещанию)
+  user writes        → scenarios/<topic>.md  (frontmatter: name, participants, problem, max_rounds)
 
 MEETING
-  start-meeting <s>  → создаёт .wiki/raw/transcripts/<date>-<topic>.md (skeleton)
+  meeting-room-      → создаёт .wiki/raw/transcripts/<date>-<topic>.md (skeleton)
-                       создаёт .brainstorm/<topic>.md (shell)
+    start-meeting       логирует в .wiki/log.md
-                       логирует в .wiki/log.md
   multi-agent run    → дописывает транскрипт в .wiki/raw/transcripts/<date>-<topic>.md
-  single-agent CSO   → ведёт активный диалог в .brainstorm/<topic>.md
 
-POST-MEETING
+POST-MEETING (handoff в .workshop/)
-  promote-brainstorm → парсит .brainstorm/<topic>.md
+  user явно:         «дистиллируй транскрипт <topic>»
-                       спрашивает: room-meta или domain?
+  → boss создаёт .workshop/.brainstorm/<topic>-distill.md
-                         room-meta → .wiki/concepts/<topic>.md
+  → workshop-promote-brainstorm дальше
-                         domain    → ~/projects/<proj>/.wiki/concepts/<topic>.md
-                                    via mcp__projects-meta__knowledge_ingest
-                       парсит action-items, создаёт в .tasks/ target-проекта
-                                    via mcp__projects-meta__tasks_create
-                       git mv .brainstorm/<topic>.md → .archive/<date>-<topic>.md
-                       логирует в .wiki/log.md
 ```
 
+**Без автоматического hop'а в workshop.** Транскрипт остаётся как primary артефакт runtime'а; распаковка в концепт — явный шаг человека.
+
 ## 5. Skills v1
 
-Каждый скил живёт в `.claude/skills/meeting-room/<name>/SKILL.md`. Триггер-фразы — в frontmatter `description`, чтобы автодиспетчер их подхватывал.
+Скилы живут в `~/projects/claude-skills/skills/`, не локально. Триггер-фразы — в SKILL.md frontmatter.
 
-### 5.1 `meeting-room:promote-brainstorm`
+### 5.1 `meeting-room-start-meeting`
-
-**Триггеры:** «промоутни брейнсторм», «finalize `<topic>`», «выкати в вики», «promote `<topic>`».
-
-**Аргумент:** путь к файлу `.brainstorm/<topic>.md` или topic-name.
-
-**Интерактивные шаги:**
-1. Прочитать файл, показать summary (1–2 абзаца).
-2. Спросить: **room-meta** или **domain**?
-3. Если domain — спросить целевой проект; валидация `~/projects/<proj>/` существует и виден `projects-meta`.
-4. Распарсить action-items (checkbox `- [ ]`, секции «TODO», «следующие шаги», «next steps»). Показать список, дать отредактировать.
-
-**Действия (в порядке, atomic-ish):**
-1. **Промоушен контента:**
-   - room-meta: `Write` → `.wiki/concepts/<topic>.md` с frontmatter (`date`, `source: .brainstorm/<topic>.md`, `status: promoted`).
-   - domain: `mcp__projects-meta__knowledge_ingest` с target-проектом и контентом.
-2. **Создание тасок:** для каждого action-item — `mcp__projects-meta__tasks_create` с target-проектом, title, description.
-3. **Архивация:** `git mv .brainstorm/<topic>.md .archive/<YYYY-MM-DD>-<topic>.md`.
-4. **Лог:** дописать строку в `.wiki/log.md`: `<date> promoted <topic> → <destination>; created N tasks in <proj>`.
-
-**Failure modes:**
-- Целевой проект не найден / `projects-meta` недоступен → abort до любых записей.
-- Промоушен прошёл, `tasks_create` упал на N-м экшене → продолжить, в логе зафиксировать частичный успех; `.brainstorm/` **не** перемещать пока пользователь не подтвердит.
-- Файла `.brainstorm/<topic>.md` нет → abort, ничего не делать.
-
-### 5.2 `meeting-room:start-meeting`
 
 **Триггеры:** «запусти совещание `<topic>`», «start meeting `<scenario>`», «новое совещание `<topic>`».
 
@@ -135,97 +87,59 @@ POST-MEETING
 
 **Шаги:**
 1. Прочитать `scenarios/<topic>.md`, распарсить YAML frontmatter.
-2. Валидация:
+2. Валидация: `name`, `problem` непустые; все `participants` — роли в `config/config.yaml`; `max_rounds` целое (если есть).
-   - `name`, `problem` непустые;
+3. `<date> = YYYY-MM-DD`.
-   - все `participants` присутствуют как роли в `config/config.yaml`;
+4. Создать `.wiki/raw/transcripts/<date>-<topic>.md` (frontmatter: `date`, `scenario`, `participants`, `problem`).
-   - `max_rounds` — целое (если есть).
+5. Дописать в `.wiki/log.md`: `<date> started <topic> ({participants})`.
-3. Сегодняшняя дата → `<date> = YYYY-MM-DD`.
+6. Вернуть пользователю созданный путь и подсказку, как запустить multi-agent runner.
-4. Создать `.wiki/raw/transcripts/<date>-<topic>.md` со скелетом (frontmatter: `date`, `scenario: scenarios/<topic>.md`, `participants`, `problem`).
-5. Создать `.brainstorm/<topic>.md` со skeleton (заголовок, ссылки на сценарий и транскрипт).
-6. Дописать в `.wiki/log.md`: `<date> started <topic> ({participants})`.
-7. Вернуть пользователю созданные пути и подсказку, как запустить multi-agent runner.
 
 **Failure modes:**
 - Frontmatter невалидный → перечислить ошибки, ничего не создавать.
-- `.brainstorm/<topic>.md` уже есть → спросить: продолжить (append-skip) или прервать.
+- `.wiki/raw/transcripts/<date>-<topic>.md` уже есть → спросить: продолжить (append-skip) или прервать.
 
-### 5.3 `meeting-room:register-persona`
+### 5.2 `meeting-room-register-persona`
 
 **Триггеры:** «добавь персону», «новый агент в комнату», «register persona `<role>`».
 
 **Интерактивный сбор полей:**
 - `role-id` (snake_case, уникальный)
-- `name` (display)
+- `name`, `model`, `provider`, `temperature`, `tools`, `system_prompt`
-- `model`, `provider`, `temperature`, `tools`, `system_prompt`
 
 **Шаги:**
 1. Прочитать `config/config.yaml`. Если `roles.<role-id>` существует — спросить: overwrite, abort, новый id.
-2. Обновить `config.yaml`, **сохраняя YAML-форматирование** (использовать YAML-парсер с round-trip — иначе комментарии и порядок ключей побьются).
+2. Обновить `config.yaml`, **сохраняя YAML-форматирование** (round-trip парсер — иначе комментарии и порядок ключей побьются).
-3. Сгенерировать `.wiki/entities/persons/<role-id>.md` с frontmatter (`role-id`, `model`, `provider`, `source: config/config.yaml`) и body — summary поведения роли, цитата `system_prompt`, ссылка на `config.yaml`.
+3. Сгенерировать `.wiki/entities/persons/<role-id>.md` с frontmatter (`role-id`, `model`, `provider`, `source: config/config.yaml`) и body: summary поведения, цитата `system_prompt`, ссылка на `config.yaml`.
 4. Дописать в `.wiki/log.md`: `<date> registered persona <role-id>`.
 
-**Sync-правило (α):** все автоматические записи в `entities/persons/` идут только через этот скил. Ручные правки разрешены только в `config.yaml`; для пере-генерации карточки — снова `register-persona <role>` (он определит, что роль уже есть, и пере-сгенерирует).
+**Sync-правило:** все автоматические записи в `entities/persons/` идут только через этот скил. Ручные правки разрешены только в `config.yaml`; для пере-генерации карточки — снова `register-persona <role>`.
 
 ## 6. Корневой `CLAUDE.md`
 
-Содержание (outline):
+Полный текст — см. `.meeting-room/CLAUDE.md`. Outline:
 
-1. **Идентичность:** «Это `.meeting-room` — workspace для кросс-проектных брейнштормов и круглых столов. Не код-проект.»
+1. Идентичность: «multi-agent runtime для круглых столов, не код-проект».
-2. **Семантика артефактов** (короткая шпаргалка из §3 + §4).
+2. Семантика артефактов (таблица).
-3. **Жёсткие правила:**
+3. Жёсткие правила: доменное содержимое — в global wiki через `projects-meta`, локальный `.wiki/concepts/` — только room-meta, локальный `.tasks/` запрещён, `entities/persons/` пишет только `register-persona`, domain-промоушен с импл-тасками авто-создаёт review-чекпоинт (но сам промоушен теперь — workshop'а, не отсюда).
-   - Доменное содержимое **никогда** не оседает в локальном `.wiki/` — всегда в глобал через `projects-meta`.
+4. Триггеры скилов v1 (только `start-meeting`, `register-persona`).
-   - Локальный `.wiki/` — только room-meta (методология, persona-карточки, лог встреч, ретро).
+5. Override `project-discipline`.
-   - Локальные `.tasks/` **не создавать** — экшены идут в `.tasks/` целевого проекта через `projects-meta__tasks_create`.
+6. Persona registry: SoT — `config/config.yaml`.
-   - Перед любым предложением tooling/архитектуры — прочитать `.wiki/raw/research/` для текущего топика (закрепляет `feedback_read_source_transcripts.md` из памяти).
-4. **Триггеры скилов v1:** перечень фраз → скил.
-5. **Override `project-discipline`:**
-   - master-only ✅
-   - commit freely / push by permission ✅
-   - semver-bump — N/A (нет versioned-артефактов в комнате)
-   - локальные `.tasks/` — N/A (запрещены §6.3)
-6. **Persona registry:** SoT — `config/config.yaml`. Карточки `.wiki/entities/persons/` — производное, пишется только скилом `register-persona`.
 
 ## 7. `.wiki/CLAUDE.md` (схема)
 
-Karpathy-канон от `setup-wiki` + meeting-room-специфика:
+Karpathy-канон + meeting-room-специфика:
 
 - `entities/persons/<role-id>.md` — frontmatter обязателен (`role-id`, `model`, `provider`, `source`); body — summary и цитата system_prompt.
-- `entities/projects/<proj>.md` — pointer-карточка к глобальному проекту (минимум: путь, краткая роль в контексте комнаты, ссылки на встречи где он фигурировал).
+- `entities/projects/<proj>.md` — pointer-карточка к проекту (минимум: путь, краткая роль в контексте комнаты, ссылки на встречи).
-- `concepts/<topic>.md` — room-meta: методология, ретро. Frontmatter: `date`, `source: .brainstorm/<topic>.md` (или `.archive/...`).
+- `concepts/<topic>.md` — room-meta runtime'а (методология совещаний, ретро). Frontmatter: `date`, `source`, `status`, `type: room-meta`.
-- `raw/research/<date>-<topic>.md` — внешний clipping. Frontmatter: `date`, `source` (URL), `topic`.
+- `raw/research/<date>-<topic>.md` — внешний clipping, frontmatter: `date`, `source` (URL), `topic`.
-- `raw/transcripts/<date>-<topic>.md` — транскрипт встречи. Frontmatter: `date`, `scenario`, `participants`.
+- `raw/transcripts/<date>-<topic>.md` — транскрипт встречи, frontmatter: `date`, `scenario`, `participants`, `problem`.
-- `log.md` — append-only, формат: `<date> <event-type> <topic> [details]`.
+- `log.md` — append-only, `<date> <event-type> <topic> [details]`.
 
-## 8. Migration plan
+## 8. Handoff с `.workshop/`
 
-### 8.1 Существующие папки
+См. `.workshop/.wiki/concepts/workshop-architecture.md` §8. Кратко: транскрипт в `.meeting-room/.wiki/raw/transcripts/` → boss создаёт дистилляционный буфер в `.workshop/.brainstorm/<topic>-distill.md` → `workshop-promote-brainstorm` → нужный target. Никакой автоматизации, явный шаг человека.
-
-| Источник | Назначение | Способ |
-|---|---|---|
-| `source/2026-05-03-modulair.md` | `.wiki/raw/research/2026-05-03-modulair.md` | `git mv` |
-| `source/2026-05-03-code-review.md` | `.wiki/raw/research/2026-05-03-code-review.md` | `git mv` |
-| `sessions/` (пусто) | `.wiki/raw/transcripts/` (пусто) | создать новую |
-| `.archive/` (пусто) | остаётся `.archive/` | без изменений |
-| `scenarios/` | остаётся `scenarios/` | без изменений |
-| `config/` | остаётся `config/` | без изменений |
-| `.brainstorm/modulair-rag.md` | особый кейс — см. §8.2 | через `promote-brainstorm` (первый прогон) |
-| `README.md` | обновить: ссылки на `CLAUDE.md`, `.wiki/`, удалить устаревшее правило «❌ NO `.wiki` внутри» | edit |
-
-### 8.2 `modulair-rag.md` — особый кейс
-
-Содержимое — process trace прошедшей single-agent сессии. Финальный design уже лежит в `~/projects/.wiki/concepts/modulair-rag-design.md` (упомянут в шапке самого файла). То есть **доменный layer уже промочен**, что осталось в `.brainstorm/` — это методологический след: «как развивался брейнсторм, какие развилки выбрали, что отвергнуто и почему».
-
-Это room-meta. Назначение при промоушене — `.wiki/concepts/modulair-rag-brainstorm-trace.md` (или похожее имя). Тасок не порождает (всё доменное уже зафиксировано). Исходник → `.archive/2026-05-05-modulair-rag.md`.
-
-Использовать как первый end-to-end тест `promote-brainstorm`.
-
-### 8.3 Spec этого редизайна
-
-После сборки структуры и v1-скилов — прогнать `meeting-room:promote-brainstorm` на самом этом файле. Назначение: `.wiki/concepts/meeting-room-architecture.md`. Тасок не порождает (план реализации идёт через `writing-plans` отдельно). Исходник → `.archive/2026-05-05-meeting-room-redesign.md`.
 
 ## 9. Открытые вопросы (не блокируют реализацию)
 
-- **Имя файла промо для `modulair-rag.md`** — `modulair-rag-brainstorm-trace.md` рабочая идея, финальное при первом прогоне.
+- **Что писать в `entities/projects/<proj>.md`** — формат карточки утрясём после первой реальной встречи (сейчас нет данных).
-- **Парсер action-items в `promote-brainstorm`** — начнём с regex по `- [ ]` и явным секциям; LLM-парсер только если regex окажется недостаточным.
+- **Регистрация `.meeting-room` в `mcp__projects-meta`** — после split'а возможно понадобится для cross-project aggregation сценариев. Open вопрос из split-плана.
-- **Что писать в `entities/projects/<proj>.md`** — формат карточки утрясём после первой реальной встречи post-redesign (сейчас нет данных).
-- **Расширение `project-discipline` для brainstorm-workspaces** — после стабилизации этой комнаты подать как PR в сам `project-discipline` (закрытие memory-todo `project_extend_discipline_for_meeting_room.md`).

.wiki/concepts/modulair-rag-brainstorm-trace.md

@@ -1,185 +0,0 @@
----
-date: 2026-05-05
-source: .brainstorm/modulair-rag.md
-status: promoted
-type: room-meta
----
-
-# ModulAIr RAG — brainstorm trace
-
-> Promoted 2026-05-05 from `.brainstorm/modulair-rag.md` (single-agent session inside `.meeting-room/`). Process trace — фиксирует **как развивался брейнсторм**, какие развилки выбрали, что отвергнуто и почему. Доменный design финализирован отдельно в `~/projects/.wiki/concepts/modulair-rag-design.md`.
-
-> Source scenario: `scenarios/modulair.md` (4-agent meeting frontmatter, не запускалось — пользователь предпочёл одного собеседника).
-> Prior multi-agent transcript: `.wiki/raw/research/2026-05-03-modulair.md` — там пользователь с другим ассистентом прошёл первый круг и накопил пул tooling-кандидатов (Marker, Repomix, ArchiveBox, Memos, Hermes-agent, и др.).
-
----
-
-## Контекст ModulAIr
-
-ModulAIr — AI-управляемый секвенсор/контроллер для еврорэка на Pico 2 W. Декомпозирован на 6 sub-projects:
-
-- `modulair-hw` — KiCad PCB (Pico 2 W + DAC + Gate-drivers + ADC + MIDI TRS + audio preamp + eurorack-питание)
-- `modulair-fw` — прошивка Pico 2 W
-- `modulair-script` — Teletype-style DSL + интерпретатор
-- `modulair-mcp` — MCP-мост между LLM и Pico
-- **`modulair-rag`** — база знаний ◄ предмет этого брейнсторма
-- `modulair-agent` — Hermes-агент как top-level orchestrator
-
-**Сквозная архитектурная развилка решена: Variant A — Pico-autonomous, LLM-conductor.** Pico исполняет скрипты sample-accurate, LLM через MCP мутирует паттерны/скрипты, но не сидит в горячем audio-пути. Wi-Fi latency перестаёт быть проблемой.
-
-## RAG-решения и почему
-
-### Стратегия — c-tiered (а не плоский vector RAG)
-
-Чисто вектор-RAG плох на factual-лукапах в синт-домене:
-- Эмбеддинги "0–8V" / "±5V" / "0V to 10V" близки в семантическом пространстве, но это разные факты
-- Отрицание ("у X нет Reset-входа") не работает — ретривер тащит чанки где есть "Reset" и "X" рядом
-- Сравнения требуют JOIN, а не top-k retrieval
-- Чанкинг ломает таблицы datasheet'ов
-
-→ **Tier 1** vector (manuals / theory / VCV source / forum threads) — recall-heavy, fuzzy.
-→ **Tier 2** structured Postgres (module specs из ModularGrid + vendor parsers) — precision-heavy, точные ответы.
-→ **Tier 3** ручные аннотации (~50 модулей личного рэка, calibration quirks, undocumented behavior).
-
-### Storage
-
-- **Postgres (cloud, существующий)** для Tier 2/3. **Не MariaDB:** JSONB для переменной формы jack-списков, pgvector как открытая дверь, recursive CTE + lateral joins зрелее, array-типы родные, MCP/ORM-экосистема Postgres-first.
-- **LightRAG #2 (новый instance с `working_dir=modulair-rag`)** для Tier 1. Текущий LightRAG-корпус не трогаем — он для других задач.
-- **Не pgvector unified** — это потребовало бы миграцию текущего LightRAG.
-- **Не Neo4j** — overkill для тысяч модулей; relations моделируются плоскими таблицами.
-
-### Scope первой итерации — (II) MVP на full-scrape ModularGrid
-
-~15k модулей, ~1 месяц. Альтернативы: (I) Top-50 за 2 недели — учиться на знакомом; (III) всё сразу за 1.5–2 мес. Выбрано (II) — компромисс между амбицией и сроками.
-
-Что меняется при этом скоупе:
-- **Per-field provenance обязательна** — без неё не отличить достоверный ±5V от LLM-угадки
-- **LLM-extraction как этап pipeline** — jacks/polarity/range живут в свободном тексте описаний и manual PDF, нужен LLM-проход по 15k
-- **Validation gates first-class** — voltage standards становятся правилами (audio типично ±5V, anomaly → флаг)
-
-### Pipeline — immutable layered (L1-L4)
-
-```
-L1  raw HTML        → MinIO bucket, content-addressed (sha256)
-L2  DOM extracts    → JSONL/run, структурные поля (HP, manufacturer, current_ma)
-L3  LLM extracts    → JSONL/run, jacks/polarity/range из свободного текста
-L4  Postgres        → "current state", собран из L2+L3+Tier-3
-```
-
-Зачем слоями: на MVP схема меняется ~5×, LLM-промпт ~10×. Без immutable слоёв каждое изменение = повторный scrape (медленно, rate-limit) + LLM-проход (дорого). С immutable — пере-extract из L2/L3 за минуты.
-
-### Source стратегия — multi-source
-
-```
-1. Vendor-side parsers (top-10):
-   pichenettes/eurorack (canonical Mutable), Make Noise, Intellijel,
-   Doepfer, ALM, Noise Engineering, Befaco, 4ms, Erica, Tiptop
-2. ModularGrid scrape (HTML, ≤1 RPS, weekly cron)
-   robots.txt allow модули и .json; их официальный API паузнут из-за EU copyright reform
-3. Tier 3 — ручные аннотации (~50 модулей личного рэка)
-```
-
-Не зависимы от ModularGrid одного — фрагильно (DOM может смениться, anti-scrape, юр. неопределённость).
-
-### Extractor LLM — Ollama Cloud sample first, не Haiku
-
-Решение: первый прогон через Ollama Cloud (GLM-5.1 / qwen) на golden set, валидация против Haiku 4.5 как benchmark. Если разница <5pp на ключевых метриках — Ollama, бесплатно. Если ≥10pp — Haiku-tiered с Sonnet 4.6 на flagged записях.
-
-**Golden set protocol** (1–2 дня ручной работы):
-- ~40 модулей: 20 Mutable (pichenettes/eurorack), 10 Doepfer, 5 Make Noise/Intellijel, 5 edge-case
-- JSON-эталон per модуль: `{name, direction, signal_type, polarity, range_v_min, range_v_max}`
-- Метрики/пороги: F1 signal_type ≥0.85, Acc polarity ≥0.85, MAE range ≤0.5V, hallucination ≤5%, miss ≤15%
-- Артефакты в git: `golden/`, `runs/<model>/`, `metrics/`
-
-### Provenance — module_facts + materialized consensus view
-
-```sql
-module_facts (
-  module_id, field, value JSONB, confidence REAL,
-  source_layer  -- 'L2-dom' | 'L3-llm-haiku' | 'L3-llm-sonnet' | 'tier3-manual'
-  source_ref,   -- 'scrape-2026-05-05/mutable-rings.json#desc-jacks'
-  scraped_at
-)
-```
-
-Плоские `modules` / `jacks` — materialized view "consensus" поверх highest-confidence values. MCP читает плоский view, валидатор/админка — `module_facts` напрямую. Альтернатива (`<col>_confidence`/`<col>_source` рядом) отвергнута — на 30+ полях шум.
-
-### Tier 1 corpus — phased
-
-**Phase 1 (MVP):** ModularGrid descriptions всех 15k (из L1) + top-100 vendor manuals + VCV Rack Fundamental/Library source + 30–50 hand-curated theory статей.
-**Phase 2 post-MVP:** vendor manuals top-500, YouTube whisper-транскрипты топ-creator'ов, selected forum threads.
-**Phase 3:** long-tail manuals, full forum scrape с quality filter.
-
-### Deploy shape — Docker compose, своё железо
-
-Existing: Postgres, Traefik, Portainer, kicad-mcp (для других sub-projects).
-
-5 новых контейнеров для modulair-rag:
-1. `lightrag-modulair` — Tier 1 vector, working_dir отдельный
-2. `minio` — L1 raw HTML cache, content-addressed
-3. `modulair-pipeline` — scraper + extractor + loader, cron внутри
-4. `tier1-converter` — Marker + Repomix + Firecrawl batch jobs
-5. `modulair-mcp` — MCP-сервер для Hermes (`module_spec`, `concept_search`, `module_compare`, `module_pairs`, `module_text`, `rack_modules`, `provenance`)
-
-### Orchestration — Hermes, не n8n
-
-Hermes-agent живёт в отдельном sub-project и через MCP зовёт наш `modulair-mcp` + (будущий) `firmware-mcp` + собственные Python-skills для batch (`run_repomix`, `run_marker`). n8n из плана убран — дублирует Hermes.
-
-Phases:
-- Phase 1 — cron внутри контейнеров
-- Phase 2 — Changedetection.io webhooks → Hermes scheduled-automations
-- Phase 3 — расширение Hermes skills (multi-source priorisation, feedback-loop из Memos/Obsidian, vendor-парсеры как skills)
-
-## Что отвергнуто и почему
-
-| Отвергнуто | Причина |
-|---|---|
-| Pure vector RAG (c-flat) | Factual-лукапы галлюцинируют; embeddings не различают voltage ranges |
-| Postgres + pgvector unified (α) | Заставит мигрировать существующий LightRAG-корпус |
-| MariaDB | JSONB и pgvector будущего — типпинг-пойнт за Postgres |
-| Neo4j | Overkill для тысяч модулей; relations плоско моделируются |
-| n8n | Дублирует Hermes-agent |
-| markitdown как primary | Marker лучше PDF, Repomix лучше код, Firecrawl лучше JS-сайты |
-| tree-sitter primary chunking | Repomix даёт structure-aware MD из коробки |
-| DVC | pg_dump + content-addressed MinIO покрывают provenance |
-| kicad-mcp в modulair-rag | Out of scope; живёт в modulair-agent / modulair-hw |
-| ArchiveBox в MVP | Heavy (Docker+Chrome+Node), своя scraper-реализация дешевле для targeted-scrape |
-
-## Открытые вопросы (не блокируют MVP)
-
-- Финальный размер golden-set (40 принято; ужесточение MAE до 0.2V для CV-модулей — после первого прогона)
-- Music theory sources — конкретный список 30–50 статей не зафиксирован (упомянуты Allen Strange, Whitwell, SoS Synth Secrets, Eno strategies)
-- Phasing для feedback-loop (Memos / Obsidian #feedback) — Phase 2, конкретная реализация позже
-- Где физически живёт kicad-mcp (host stdio vs Docker) — релевантно для modulair-agent / modulair-hw, не для modulair-rag
-
-## Tooling из исходного транскрипта 2026-05-03
-
-| Категория | Что взято | Что отвергнуто |
-|---|---|---|
-| PDF→MD | **Marker** (primary), **LlamaParse** (fallback) | markitdown как primary, Docling (только если Marker не установится) |
-| Web→MD | **Firecrawl** (batch), **Jina Reader** (одноразовый) | Trafilatura |
-| Code→MD | **Repomix** | tree-sitter с нуля |
-| Web archive | **Wallabag** в Phase 2 | ArchiveBox в MVP, Linkwarden, Shiori |
-| Change detection | **Changedetection.io** в Phase 2 | (alone, без n8n) |
-| Orchestration | **Hermes-agent** | n8n, Huginn |
-| Data versioning | `pg_dump` + content-addressed MinIO | DVC |
-| Feedback loop | **Memos** или **Obsidian** в Phase 2 | (одно из двух) |
-| Container UI | **Portainer** (existing) | Dockge |
-| Vector store | **LightRAG** (existing для других, новый instance для modulair) | ChromaDB, Pinecone, GraphRAG |
-| Algo composition | **music21** — для modulair-agent, не RAG | — |
-| Embedded DSP | Pure Data + hvcc / Faust — для modulair-fw audio sub-project, не RAG | — |
-| EDA → MD | **kicad-mcp** существующий, для modulair-hw / modulair-agent | KiCad-CLI / KiBot — out of scope для modulair-rag |
-
-## Меморики, появившиеся за сессию
-
-- `feedback_meeting_room_workspace.md` — `.meeting-room` это brainstorm-зона, артефакты идут в `.brainstorm/` или global wiki, не через "transit-zone autopilot"
-- `project_extend_discipline_for_meeting_room.md` — открытый todo расширить project-discipline под brainstorm-workspaces
-- `feedback_read_source_transcripts.md` — `.meeting-room/source/<date>-<topic>.md` это pre-loaded user research, читать до предложения стэка
-
-## Deferred actions (не созданы как таски)
-
-Целевые проекты `modulair-rag`/`meeting-room` пока не зарегистрированы в `projects-meta` (на 2026-05-05 в `meta_status` — 12 проектов, ни один из них). `tasks_create` в скиле `meeting-room-promote-brainstorm` пропущен. Перевести в backlog при появлении проектов:
-
-1. Брейнсторм per остальным 5 sub-projects (`modulair-hw`, `modulair-fw`, `modulair-script`, `modulair-mcp`, `modulair-agent`) — owner: meeting-room.
-2. Когда RAG-implementation начнётся — поднять структуру репозитория `modulair-rag` где-то в `~/projects/`, скелет compose.yml, `.tasks/STATUS.md` под фактический проект — owner: modulair-rag.
-3. Заведение golden-set (1–2 дня ручной работы — это первое что нужно сделать; в MVP это блокирующая зависимость для extractor-валидации) — owner: modulair-rag.

.wiki/log.md

@@ -15,3 +15,23 @@ Events: `started`, `promoted`, `registered`, `archived`.
 2026-05-05 promoted modulair-rag → .wiki/concepts/modulair-rag-brainstorm-trace.md (tasks_create skipped: target projects modulair-rag/meeting-room not yet registered in projects-meta; 3 actions deferred in trace)
 2026-05-05 promoted meeting-room-redesign → .wiki/concepts/meeting-room-architecture.md (no tasks; plan executed during this same session — implementation plan archived separately as 2026-05-05-meeting-room-redesign-plan.md)
 2026-05-05 archived meeting-room-redesign-plan (post-execution)
+2026-05-05 designed interns (.brainstorm/interns.md — domain spec, target promote: claude-skills)
+2026-05-05 promoted interns → claude-skills/.wiki/concepts/interns-design.md (commits 30c329fd+035e4dd5+3deaa357); tasks created: claude-skills#interns-skills-mvp (ready), common#interns-mcp-mvp (ready), projects-meta-mcp#migrate-to-common-lib (blocked), common#unify-llm-secrets (blocked)
+2026-05-05 archived interns → .archive/2026-05-05-interns.md
+2026-05-05 designed interns-repo-read (.brainstorm/repo-read.md — domain spec, target promote: claude-skills, parent: interns)
+2026-05-05 promoted interns-repo-read → claude-skills/.wiki/concepts/interns-repo-read-design.md (commits 34001022+b7943a3c+93a45007); tasks created: common#interns-repo-read-impl (ready), claude-skills#interns-repo-read-skill-updates (ready)
+2026-05-05 archived interns-repo-read → .archive/2026-05-05-repo-read.md
+2026-05-06 designed factory-bootstrap (.brainstorm/factory-bootstrap.md — domain spec, target promote: factory; field-test on Win11 laptop)
+2026-05-06 bootstrapped factory project (.tasks/STATUS.md + .wiki/ canonical layout, commit ecddcdf — fixed projects-meta sync indexing prerequisite)
+2026-05-06 promoted factory-bootstrap → factory/.wiki/concepts/factory-bootstrap.md (commits 549fe2ea+d26da137+b79be591); tasks created: factory#factory-bootstrap-script (ready), factory#factory-l1-design (blocked-by factory-bootstrap-script); also claude-skills#project-creation-lifecycle-skill (ready, gap surfaced during this promote)
+2026-05-06 archived factory-bootstrap → .archive/2026-05-06-factory-bootstrap.md
+2026-05-06 designed hermes-skills-rollout (.brainstorm/hermes-skills-rollout.md — domain spec, target promote: claude-skills)
+2026-05-06 promoted hermes-skills-rollout → claude-skills/.wiki/concepts/hermes-skills-rollout-design.md (commits b3dc1251+5ae14fd6+0f65e057); tasks created: claude-skills#hermes-converter-mvp (ready), claude-skills#hermes-flavour-mcp-setups (blocked), claude-skills#hermes-installer-skill (blocked), claude-skills#hermes-mvp-coverage (blocked), claude-skills#hermes-converter-ci (blocked, deferred), common#tasks-close-normalize-body (ready, discipline pre-req), claude-skills#using-tasks-close-coverage-gate (ready, discipline pre-req)
+2026-05-06 archived hermes-skills-rollout → .archive/2026-05-06-hermes-skills-rollout.md
+2026-05-07 designed tdd-criteria (.brainstorm/tdd-criteria.md — domain spec, target promote: claude-skills; 6-round arc with cross-project research via projects-meta)
+2026-05-07 promoted tdd-criteria → claude-skills/.wiki/concepts/tdd-criteria-design.md (commits a03d2804+2ad6f4ce+5fb648d4); tasks created: claude-skills#tdd-criteria-skill-write (ready), claude-skills#tdd-criteria-hermes-mapping (blocked), claude-skills#tdd-criteria-build-install (blocked), claude-skills#tdd-criteria-review (blocked, umbrella per §5)
+2026-05-07 archived tdd-criteria → .archive/2026-05-07-tdd-criteria.md
+2026-05-07 amended tdd-criteria post-promotion: anti-loophole rule 4 (test-immutability + [test-modify: was X; is Y] marker + separate-commit-from-impl) added; user surfaced symmetric vandalism risk on tests after initial promotion. Patches landed: claude-skills#tdd-criteria-skill-write description updated (commit b7819b17), claude-skills#tdd-criteria-precommit-hook task created (commit d440bb52). Design-doc amendment NOT applied directly (knowledge_ingest is create-only — overwrite blocked); amendment text embedded in skill-write task description for impl session to apply via direct git edit.
+2026-05-08 split meeting-room into multi-agent runtime (this zone) + .workshop/ boss-zone; remote workshop repo created at git.kzntsv.site/OpeItcLoc03/workshop.git
+2026-05-08 amended meeting-room-architecture.md: split-rewrite (runtime-only); boss sections moved to .workshop/.wiki/concepts/workshop-architecture.md
+2026-05-08 split-done cleanup: removed .archive/, .brainstorm/, .wiki/concepts/modulair-rag-brainstorm-trace.md, .wiki/raw/{naming,research}/, .claude/skills/meeting-room-promote-brainstorm/. All artifacts migrated to .workshop/ (commits 4608ba9..f8f6f1a in workshop repo). Promoted concept: .workshop/.wiki/concepts/meeting-room-split.md.

.wiki/raw/research/2026-05-03-code-review.md

@@ -1,186 +0,0 @@
----
-title: "Хочу обсудить, как подключить другую  LLM  к ревью кода, написанного КЛодом. Как это организовать? Наверняка ты знаешь, как другие это делают?"
-source: "https://www.google.com/search?sourceid=chrome&aep=42&source=chrome.crn.rb&q=%D0%A5%D0%BE%D1%87%D1%83+%D0%BE%D0%B1%D1%81%D1%83%D0%B4%D0%B8%D1%82%D1%8C%2C+%D0%BA%D0%B0%D0%BA+%D0%BF%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B8%D1%82%D1%8C+%D0%B4%D1%80%D1%83%D0%B3%D1%83%D1%8E++LLM++%D0%BA+%D1%80%D0%B5%D0%B2%D1%8C%D1%8E+%D0%BA%D0%BE%D0%B4%D0%B0%2C+%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D0%BE%D0%B3%D0%BE+%D0%9A%D0%9B%D0%BE%D0%B4%D0%BE%D0%BC.+%D0%9A%D0%B0%D0%BA+%D1%8D%D1%82%D0%BE+%D0%BE%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%3F+%D0%9D%D0%B0%D0%B2%D0%B5%D1%80%D0%BD%D1%8F%D0%BA%D0%B0+%D1%82%D1%8B+%D0%B7%D0%BD%D0%B0%D0%B5%D1%88%D1%8C%2C+%D0%BA%D0%B0%D0%BA+%D0%B4%D1%80%D1%83%D0%B3%D0%B8%D0%B5+%D1%8D%D1%82%D0%BE+%D0%B4%D0%B5%D0%BB%D0%B0%D1%8E%D1%82%3F&mstk=AUtExfD5EFxgCPzN9i00Xb6Sng7oox3R0MLA9REWp9DPMJQl5bRyt_-vjx-aF_OLAdQQteu-vj8I7bVGjoD-a114g5-BOzZtyq0bSXcimbBbeakgHNjFiWOnFqNZ3MfdmwJwTKjGzkXXMCEsfvlWcg2J_AmBHzsuH60i3HjfHo2qSI148skiOz50PggUYfyARIMggD2xAPIent3dfljllT5pubb9vjJJXyKarGgn_uz-iiExDVpuL0wstNe7d1uUxyRS3-af17X_So2j8KnM83XZJxHLZcwUqz_l-pk&csuir=1&mtid=aof3aaPIFv_97_UPusiA6Qo&udm=50"
-fetched: "2026-05-03"
-published:
-fetched_via: "obsidian-web-clipper"
-tags:
-  - "wiki-raw"
-  - "clipping"
----
-
-## Результаты поиска
-
-Здравствуйте, Victor! Что вас интересует?
-
-Хочу обсудить, как подключить другую LLM к ревью кода, написанного КЛодом. Как это организовать? Наверняка ты знаешь, как другие это делают?
-
-Подключение сторонней LLM для ревью кода, написанного Claude (или любой другой моделью), — это отличная практика «перекрестной проверки» (cross-review), которая помогает отловить галлюцинации и специфические баги.
-
-Вот как это обычно организуют на практике:
-
-1\. Автоматизация через CI/CD (Самый популярный путь)
-
-Большинство команд не копипастят код вручную, а встраивают проверку прямо в GitHub/GitLab.
-
-- **Инструменты:** Используются готовые экшены или скрипты (например, `coderabbit.ai`, `pr-agent` от Codium или опенсорсные аналоги).
-- **Процесс:** Claude пишет код и создает Pull Request. Скрипт в CI ловит это событие, отправляет диф (diff) в API другой модели (например, **GPT-4o** или **Llama 3**) с системным промптом: «Ты — эксперт по безопасности, проверь этот код на уязвимости».
-- **Результат:** Вторая LLM оставляет комментарии прямо в PR.
-
-2\. Подход «Разделение ролей»
-
-Чтобы проверка была качественной, другой модели дают узкую специализацию. Не просите её просто «проверить». Дайте конкретный фокус:
-
-- **Модель A (Claude):** Пишет функционал и логику.
-- **Модель B (например, GPT-4o):** Ищет только ошибки в типах, потенциальные утечки памяти или несоответствие стилю (Style Guide).
-- **Модель C (например, DeepSeek Coder):** Пишет модульные тесты на этот код. Если тесты не проходят — значит, в коде Claude была ошибка.
-
-3\. Использование локальных моделей (для приватности)
-
-Если код чувствительный, многие разворачивают локальную LLM через **Ollama** или **vLLM**.
-
-- Вы можете настроить локальную **Llama 3 (70B)** или **Phind-CodeLlama**, которая будет «подглядывать» за тем, что генерирует Claude, и сигнализировать, если код выглядит подозрительно.
-
-4\. Промпт-инжиниринг для ревьюера
-
-Важно, чтобы «ревьюер» не знал, что код написала другая нейронка (это убирает предвзятость). Типовой промпт для второй модели:
-
-> "Перед тобой PR от разработчика. Проанализируй изменения. Найди логические ошибки, проблемы с производительностью и предложи 3 улучшения. Будь строг, но конструктивен."
-
-С какими моделями лучше «спаривать» Claude?
-
-- **Claude + GPT-4o:** Классика. У них разный «стиль мышления», и они часто находят ошибки друг за другом.
-- **Claude + DeepSeek V3:** Отличное сочетание для Python/C++, так как DeepSeek очень силен именно в кодинге и часто дешевле.
-- **Claude + Sonar (Perplexity):** Если код завязан на свежих библиотеках, которые вышли месяц назад (Sonar умеет ходить в интернет и проверять актуальность API).
-
-**С какого стека технологий (язык программирования, гит-хостинг) ты хочешь начать настройку такой связки?**
-
-В ответах искусственного интеллекта могут быть ошибки. [Learn more](https://support.google.com/websearch?p=aimode)
-
-Создание общедоступной ссылки…
-
-Показать все
-
-Автоматизация через CI/CD (Самый популярный путь) - а еще пути есть? ЧТобы без пулл-реквестов?
-
-Если мы убираем этап Pull Request и CI/CD, значит, мы переносим взаимодействие на уровень **IDE** (среды разработки) или **локальных скриптов**. Это делает цикл обратной связи мгновенным: вы еще не отправили код в репозиторий, а «второе мнение» уже получено.
-
-Вот основные способы организовать это «на лету»:
-
-1\. Расширения для IDE с поддержкой разных моделей (Continue.dev / Void)
-
-Это самый удобный «ручной» способ.
-
-- **Как это работает:** Вы устанавливаете плагин (например, **Continue** для VS Code или JetBrains). В нем можно настроить сразу несколько API-ключей.
-- **Процесс:** Вы просите Claude (через встроенный чат или автодополнение) написать функцию. Затем выделяете этот код, нажимаете горячую клавишу, переключаете модель на **GPT-4o** или **DeepSeek** прямо в выпадающем списке и выбираете команду `/verify` или `/review`.
-- **Плюс:** Не нужно переключаться между вкладками браузера, код проверяется мгновенно.
-
-2\. Локальные CLI-утилиты (скрипты «надсмотрщики»)
-
-Вы можете написать простой Python-скрипт или использовать готовые CLI-инструменты (например, **Aider**), которые работают в терминале.
-
-- **Процесс:** Вы сохраняете код, написанный Клодом, в файл. В терминале запускаете команду: `check-code --file logic.py --model gpt4`.
-- **Автоматизация:** Можно настроить **Git Hooks** (pre-commit hook). Когда вы пытаетесь сделать `git commit`, скрипт автоматически отправляет изменения во вторую LLM. Если она находит критические баги, коммит блокируется до тех пор, пока вы не подтвердите, что всё ок.
-
-3\. "Multi-Agent" системы (CrewAI / AutoGen)
-
-Это более продвинутый уровень, где вы создаете «чат» между двумя нейронками прямо у себя на компьютере.
-
-- **Организация:** Вы запускаете локальный оркестратор.
-- **Роли:** Одной модели (Claude) дается задача «Напиши код», а второй (например, Llama 3 локально) — задача «Ты суровый техлид, критикуй каждый символ».
-- **Результат:** В консоли вы видите диалог двух моделей. Они спорят, пока код не станет идеальным, и только финальный вариант сохраняется в файл.
-
-4\. Использование платформ-агрегаторов (Poe / TypingMind)
-
-Если не хочется возиться с плагинами, используются веб-интерфейсы, где несколько моделей доступны в одном окне.
-
-- **Процесс:** В **TypingMind** можно создать чат, где подключены обе модели. Вы отправляете промпт, Claude генерирует ответ, а вы одной кнопкой пересылаете этот ответ в соседнюю ветку чата для GPT-4 с просьбой провести аудит.
-
-Резюме по инструментам:
-
-- **Continue.dev** — если хотите проверять код прямо в процессе написания в VS Code.
-- **Aider** — если любите работать через терминал и хотите, чтобы LLM сама правила файлы.
-- **Git Hooks** — если хотите «мини-CI» прямо на своей машине, чтобы не пропускать плохой код в историю правок.
-
-Какой из этих вариантов ближе к твоему привычному рабочему процессу — **редактор кода** или **терминал**?
-
-В ответах искусственного интеллекта могут быть ошибки. [Learn more](https://support.google.com/websearch?p=aimode)
-
-Создание общедоступной ссылки…
-
-Показать все
-
-Git Hooks интересно
-
-Git Hooks — это скрипты, которые Git запускает автоматически при определенных действиях (например, перед каждым коммитом). Это идеальная «точка контроля», чтобы плохой код даже не попадал в вашу локальную историю.
-
-Для ревью кода лучше всего подходит хук **`pre-commit`**. Вот как это организовать по шагам:
-
-1\. Как это работает технически
-
-Когда вы пишете `git commit -m "feat: add logic"`, Git запускает скрипт. Скрипт берет ваш измененный код, отправляет его по API во вторую LLM (например, GPT-4o или DeepSeek) и ждет ответа. Если LLM находит ошибки — коммит прерывается.
-
-2\. Реализация (простой пример на Python)
-
-Вам понадобится скрипт-прослойка. Можно использовать библиотеку `pre-commit` (наиболее стандартный путь в индустрии).
-
-**Файл `.pre-commit-config.yaml` в корне проекта:**
-
-```
-repos:
--   repo: local
-    hooks:
-    -   id: llm-code-review
-        name: LLM Code Review
-        entry: python scripts/llm_check.py
-        language: python
-        stages: [commit]
-        types: [python] # или другие языки
-```
-
-**Скрипт `scripts/llm_check.py` (логика):**  
-Скрипт должен:
-
-1. Получить список измененных строк (`git diff --cached`).
-2. Отправить их в API (через `openai` или `anthropic` SDK).
-3. Если в ответе от LLM есть ключевое слово (например, "FAIL" или "CRITICAL"), скрипт делает `sys.exit(1)`, и коммит не проходит.
-
-3\. Готовые инструменты
-
-Чтобы не писать всё с нуля, можно использовать существующие обертки:
-
-- **Llint:** Специальная утилита, которая работает как линтер, но на базе LLM. Её легко добавить в хуки.
-- **[Aider](https://aider.chat/):** Хотя это полноценный AI-программист, его можно вызвать из скрипта для проверки текущих изменений перед фиксацией.
-
-4\. Плюсы и минусы такого подхода
-
-**Плюсы:**
-
-- **Гарантия чистоты:** В репозиторий не попадет код, который не прошел «вторую пару глаз».
-- **Локальность:** Вы узнаете об ошибке через 5 секунд, а не через 5 минут после прогона CI на сервере.
-
-**Нюансы:**
-
-- **Задержка:** Коммит будет занимать чуть больше времени (пока ждем ответ от API).
-- **Стоимость:** Каждый `git commit` будет тратить несколько центов (токенов).
-- **Ложные срабатывания:** Если LLM ошиблась и заблокировала коммит, вам придется использовать флаг `git commit --no-verify`, чтобы обойти проверку.
-
-С чего лучше начать?
-
-Если хочешь попробовать «на коленке», я могу набросать **готовый Python-скрипт**, который будет брать твои изменения и отправлять их на проверку в OpenAI или любую другую модель через LiteLLM.
-
-**Нужен пример такого скрипта или помочь настроить сам механизм Git Hooks?**
-
-В ответах искусственного интеллекта могут быть ошибки. [Learn more](https://support.google.com/websearch?p=aimode)
-
-Создание общедоступной ссылки…
-
-Показать все
-
-Приложения Google
-
-Аккаунт Google
-
-Victor Kuznetsov
-
-vitya.kuznetsov@gmail.com

CLAUDE.md

@@ -1,37 +1,42 @@
 # .meeting-room — workspace contract
 
-`.meeting-room/` — brainstorm-зона для кросс-проектных совещаний. **Не код-проект.**
+> ⚠️ **RETIRED 2026-06-08.** Зона распущена. НЕ запускать `meeting-room-start-meeting` / `register-persona` и не заводить совещания здесь. Multi-agent round-table теперь — тир consult-лестницы рантайма: **K локальных read-only coworker-спавнов через SpawnAdapter в worktree воркера** (federation-native, не центральная зона). Причина: несовместимость с federation-per-machine вердиктом (`agent-orchestration-without-user` Q9) + механическое дублирование `consult-arbiter-spawn`. Решение/размотка: `.workshop/.brainstorm/meeting-room-dissolve.md`. Дизайн: общая вики `concepts/consult-tier-escalation.md`. Контракт ниже сохранён как исторический record.
+
+`.meeting-room/` — multi-agent runtime для кросс-проектных круглых столов: тематических совещаний с ролями, сценарием, транскриптом. **Не код-проект.**
+
+Single-agent брэйнсторм + дистилляция — это `.workshop/` (отдельная зона после split'а 2026-05-08, см. `.wiki/concepts/meeting-room-architecture.md` §1, и `.workshop/.wiki/concepts/meeting-room-split.md` после промоушена).
 
 ## Семантика артефактов
 
 | Папка | Что |
 |---|---|
-| `scenarios/` | runtime: сценарии запуска multi-agent совещания (frontmatter: `name`, `participants`, `problem`, `max_rounds`) |
+| `scenarios/<topic>.md` | runtime: сценарии запуска multi-agent совещания (frontmatter: `name`, `participants`, `problem`, `max_rounds`) |
 | `config/config.yaml` | runtime: реестр persona (single source of truth) |
-| `.brainstorm/<topic>.md` | рабочий буфер до промоушена |
+| `.wiki/raw/research/` | immutable: внешние clippings, релевантные совещанию |
-| `.archive/<date>-<topic>.md` | post-promotion: исходник из `.brainstorm/` |
+| `.wiki/raw/transcripts/` | immutable: транскрипты прошедших совещаний |
-| `.wiki/raw/research/` | immutable: внешние clippings (бывший `source/`) |
-| `.wiki/raw/transcripts/` | immutable: транскрипты совещаний (бывший `sessions/`) |
 | `.wiki/entities/persons/` | карточки persona, генерируются из `config.yaml` |
-| `.wiki/concepts/` | room-meta: методология, ретро, паттерны |
+| `.wiki/entities/projects/` | pointer-карточки целевых проектов |
+| `.wiki/concepts/` | room-meta: методология совещаний, ретро runtime'а |
 
-**Перед предложением tooling/архитектуры — прочитать `.wiki/raw/research/` для текущего топика.** Это закрепляет урок из `feedback_read_source_transcripts.md` (память).
+**Перед предложением tooling/архитектуры — прочитать `.wiki/raw/research/` для текущего топика** (если research-материалы для совещания загружены).
 
 ## Жёсткие правила
 
-1. **Доменное содержимое никогда не оседает в локальном `.wiki/`** — всегда в глобал через `mcp__projects-meta__knowledge_ingest` в `~/projects/<proj>/.wiki/`.
+1. **Доменное содержимое никогда не оседает в локальном `.wiki/`** — всегда в global через `mcp__projects-meta__knowledge_ingest` в `~/projects/<proj>/.wiki/`. Промоушен делается **из `.workshop/`** на основании дистилляционного буфера (см. handoff ниже).
-2. **Локальный `.wiki/concepts/` — только room-meta** (про саму комнату).
+2. **Локальный `.wiki/concepts/` — только room-meta** (про runtime: methodology совещаний, ретро, паттерны фасилитации).
-3. **Локальные `.tasks/` не создавать** — экшены идут в `.tasks/` целевого проекта через `mcp__projects-meta__tasks_create`.
+3. **Локальные `.tasks/` не создавать** — workshop-meta таски (миграции, апгрейды скилов) живут в `.workshop/.tasks/`. Если runtime'у понадобятся свои таски — открыть отдельным решением.
-4. **`entities/persons/` пишет только скил `meeting-room-register-persona`.** SoT — `config/config.yaml`.
+4. **`entities/persons/` пишет только скил `meeting-room-register-persona`.** SoT — `config/config.yaml`. Ручные правки только в `config.yaml`; регенерация карточки — снова `register-persona`.
+5. **Boss-режим (single-agent + user) сюда не приезжает.** Если возник полу-структурированный диалог требующий running-record `.brainstorm/<topic>.md` — переехать в `.workshop/`. Workshop делает дистилляцию транскриптов отсюда — пользовательским явным запросом, не автоматически.
 
 ## Триггеры скилов v1
 
 | Скил | Триггер-фразы |
 |---|---|
-| `meeting-room-promote-brainstorm` | «промоутни брейнсторм», «finalize `<topic>`», «выкати в вики», «promote `<topic>`» |
 | `meeting-room-start-meeting` | «запусти совещание `<topic>`», «start meeting `<scenario>`», «новое совещание `<topic>`» |
 | `meeting-room-register-persona` | «добавь персону», «новый агент в комнату», «register persona `<role>`» |
 
+Скил `workshop-promote-brainstorm` — в зоне `.workshop/`, не здесь. Дистилляция transcripts → концепт делается там.
+
 ## Override `project-discipline`
 
 В этой комнате применяются:
@@ -41,15 +46,31 @@
 
 **Не применяются:**
 
-- ❌ semver-bump — нет versioned-артефактов (`SKILL.md` без version в frontmatter, нет `package.json`/`pyproject.toml`)
+- ❌ semver-bump — нет versioned-артефактов (`SKILL.md` скилов живут в `~/projects/claude-skills/`, у них свой semver)
-- ❌ локальный `.tasks/` — запрещён правилом §3 выше
+- ❌ локальный `.tasks/` — запрещён правилом §3
+
+## Handoff с `.workshop/`
+
+```
+.meeting-room/.wiki/raw/transcripts/<date>-<topic>.md   ← runtime артефакт
+       │
+       │ user явно: «дистиллируй транскрипт <topic>»
+       ▼
+.workshop/.brainstorm/<topic>-distill.md
+       │
+       │ workshop-promote-brainstorm
+       ▼
+   target (workshop-meta / domain via projects-meta / skill)
+```
+
+Никакого автоматического hop'а. Multi-agent runtime производит сырьё (транскрипт), workshop производит дистилляты. Два разных режима, не смешиваются.
 
 ## Persona registry
 
-SoT — `config/config.yaml`. Карточки `.wiki/entities/persons/<role-id>.md` — производные. Ручные правки разрешены **только** в `config.yaml`. Регенерация карточки — снова `meeting-room-register-persona <role-id>`.
+SoT — `config/config.yaml`. Карточки `.wiki/entities/persons/<role-id>.md` — производные.
 
 ## Pointers
 
 - Schema локальной вики: `.wiki/CLAUDE.md`
-- Текущий redesign-spec (до self-promotion): `.brainstorm/meeting-room-redesign.md`
+- Архитектура runtime'а: `.wiki/concepts/meeting-room-architecture.md`
-- После self-promotion: `.wiki/concepts/meeting-room-architecture.md`
+- Архитектура boss-зоны: `.workshop/.wiki/concepts/workshop-architecture.md`

README.md

@@ -1,5 +1,7 @@
 # .meeting-room — Shared Workspace
 
+> ⚠️ **RETIRED 2026-06-08.** Эта зона распущена. Multi-agent round-table НЕ привязан к отдельной зоне-назначению: он переехал в consult-tier рантайма оркестрации как **K локальных read-only coworker-спавнов в worktree воркера** (тот же SpawnAdapter, что одиночный арбитр). Причина роспуска: зона была бы единственным централизованным компонентом в системе, специально сделанной federation-per-machine (`agent-orchestration-without-user` Q9), и механически дублировала `consult-arbiter-spawn`. Полная размотка: `.workshop/.brainstorm/meeting-room-dissolve.md`. Дизайн round-table: общая вики `concepts/consult-tier-escalation.md` §«Round-table тир». Файлы ниже сохранены как исторический record, не запускаются.
+
 > Кросс-проектные брейнстормы и круглые столы агентов. Brainstorm-зона: room-meta лежит локально в `.wiki/`, доменное промочивается в глобальную вики и `.tasks/` целевого проекта через `projects-meta`.
 
 ## Quickstart

config/config.yaml

@@ -9,7 +9,7 @@ providers:
     api_key: ${MEETING_ROOM_ROUTERAI_API_KEY}
     base_url: ${MEETING_ROOM_ROUTERAI_BASE_URL}
   ollama_cloud:
-    api_key: 02a8f6e9f9744088885982ac645f1ce1.HB1MFh4AlTpyic9oJGxQjNuA
+    api_key: ${OLLAMA_CLOUD_API_KEY}
     base_url: https://ollama.com/v1
 
 roles: