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

---
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 (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-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/` — multi-agent runtime для срежиссированных круглых столов: тематических совещаний с ролями (analyst, skeptic, idea_generator, moderator …), сценарием и транскриптом. Не код-проект.

Зона выделена под темы, которые выигрывают от **многопозиционного спора** (architect vs implementer vs PM, или иные оппозиции). Single-agent + user брэйнсторм без режиссуры — другой режим, живёт в `.workshop/`. Дистилляция транскрипт → концепт — отдельный явный handoff в `.workshop/`.

## 2. Принятые решения

| # | Развилка | Решение |
|---|---|---|
| 1 | Wiki/Tasks семантика | локальный `.wiki/` есть (room-meta), локальный `.tasks/` нет (запрещён §3 в `CLAUDE.md`) |
| 2 | Folder-миграция | Karpathy-канон: всё «сырое» в `.wiki/raw/`, скилы — в `~/projects/claude-skills/` |
| 3 | Skills v1 | `meeting-room-start-meeting`, `meeting-room-register-persona` (boss-скил `workshop-promote-brainstorm` выделен в workshop-зону) |
| 4 | Persona sync | писать в `entities/persons/` имеет право только `register-persona`; `config/config.yaml` — SoT |
| 5 | Project-discipline | master-only ✅, push-by-permission ✅, semver — N/A, локальные tasks — N/A (запрет §3) |

## 3. Целевая структура

```
.meeting-room/
├── CLAUDE.md                  корневой контракт зоны
├── README.md
│
├── scenarios/<topic>.md       runtime: frontmatter сценариев multi-agent
├── config/config.yaml         runtime: реестр persona (SoT)
│
└── .wiki/                     Karpathy-canonical, room-meta only
    ├── CLAUDE.md              wiki-схема
    ├── index.md
    ├── overview.md
    ├── log.md                 append-only хроника
    ├── raw/
    │   ├── README.md
    │   └── transcripts/<date>-<topic>.md   immutable: транскрипты совещаний
    ├── entities/
    │   ├── persons/<role-id>.md            карточки персон (генерируются)
    │   └── projects/<proj>.md              pointer-карточки целевых проектов
    └── concepts/<topic>.md                  room-meta: методология, ретро runtime'а
```

**Boss-артефакты (`.brainstorm/`, `.archive/`, дистилляция, методология одиночного мышления) — в `.workshop/`, не здесь.**

## 4. Lifecycle (runtime-only)

```
PRE-MEETING
  user clip          → .meeting-room/.wiki/raw/research/<date>-<topic>.md
                       (если research-материал, релевантный совещанию)
  user writes        → scenarios/<topic>.md  (frontmatter: name, participants, problem, max_rounds)

MEETING
  meeting-room-      → создаёт .wiki/raw/transcripts/<date>-<topic>.md (skeleton)
    start-meeting       логирует в .wiki/log.md
  multi-agent run    → дописывает транскрипт в .wiki/raw/transcripts/<date>-<topic>.md

POST-MEETING (handoff в .workshop/)
  user явно:         «дистиллируй транскрипт <topic>»
  → boss создаёт .workshop/.brainstorm/<topic>-distill.md
  → workshop-promote-brainstorm дальше
```

**Без автоматического hop'а в workshop.** Транскрипт остаётся как primary артефакт runtime'а; распаковка в концепт — явный шаг человека.

## 5. Skills v1

Скилы живут в `~/projects/claude-skills/skills/`, не локально. Триггер-фразы — в SKILL.md frontmatter.

### 5.1 `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`, `participants`, `problem`).
5. Дописать в `.wiki/log.md`: `<date> started <topic> ({participants})`.
6. Вернуть пользователю созданный путь и подсказку, как запустить multi-agent runner.

**Failure modes:**
- Frontmatter невалидный → перечислить ошибки, ничего не создавать.
- `.wiki/raw/transcripts/<date>-<topic>.md` уже есть → спросить: продолжить (append-skip) или прервать.

### 5.2 `meeting-room-register-persona`

**Триггеры:** «добавь персону», «новый агент в комнату», «register persona `<role>`».

**Интерактивный сбор полей:**
- `role-id` (snake_case, уникальный)
- `name`, `model`, `provider`, `temperature`, `tools`, `system_prompt`

**Шаги:**
1. Прочитать `config/config.yaml`. Если `roles.<role-id>` существует — спросить: overwrite, abort, новый id.
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`.
4. Дописать в `.wiki/log.md`: `<date> registered persona <role-id>`.

**Sync-правило:** все автоматические записи в `entities/persons/` идут только через этот скил. Ручные правки разрешены только в `config.yaml`; для пере-генерации карточки — снова `register-persona <role>`.

## 6. Корневой `CLAUDE.md`

Полный текст — см. `.meeting-room/CLAUDE.md`. Outline:

1. Идентичность: «multi-agent runtime для круглых столов, не код-проект».
2. Семантика артефактов (таблица).
3. Жёсткие правила: доменное содержимое — в global wiki через `projects-meta`, локальный `.wiki/concepts/` — только room-meta, локальный `.tasks/` запрещён, `entities/persons/` пишет только `register-persona`, domain-промоушен с импл-тасками авто-создаёт review-чекпоинт (но сам промоушен теперь — workshop'а, не отсюда).
4. Триггеры скилов v1 (только `start-meeting`, `register-persona`).
5. Override `project-discipline`.
6. Persona registry: SoT — `config/config.yaml`.

## 7. `.wiki/CLAUDE.md` (схема)

Karpathy-канон + 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 runtime'а (методология совещаний, ретро). Frontmatter: `date`, `source`, `status`, `type: room-meta`.
- `raw/research/<date>-<topic>.md` — внешний clipping, frontmatter: `date`, `source` (URL), `topic`.
- `raw/transcripts/<date>-<topic>.md` — транскрипт встречи, frontmatter: `date`, `scenario`, `participants`, `problem`.
- `log.md` — append-only, `<date> <event-type> <topic> [details]`.

## 8. Handoff с `.workshop/`

См. `.workshop/.wiki/concepts/workshop-architecture.md` §8. Кратко: транскрипт в `.meeting-room/.wiki/raw/transcripts/` → boss создаёт дистилляционный буфер в `.workshop/.brainstorm/<topic>-distill.md` → `workshop-promote-brainstorm` → нужный target. Никакой автоматизации, явный шаг человека.

## 9. Открытые вопросы (не блокируют реализацию)

- **Что писать в `entities/projects/<proj>.md`** — формат карточки утрясём после первой реальной встречи (сейчас нет данных).
- **Регистрация `.meeting-room` в `mcp__projects-meta`** — после split'а возможно понадобится для cross-project aggregation сценариев. Open вопрос из split-плана.