split: cleanup migrated artifacts (step 13 — split done)

Removed (now lives in .workshop/, see commits 4608ba9..f8f6f1a there):
- .archive/* (8 archived buffers from 2026-05-05..2026-05-07)
- .brainstorm/* (6 untracked brainstorm buffers — never tracked here, just on disk)
- .wiki/concepts/modulair-rag-brainstorm-trace.md (workshop-meta methodology trace)
- .wiki/raw/naming/* (untracked, naming research clipping)
- .wiki/raw/research/* (modulair, code-review, tokens-economy/, hermes-agent-skills/)
- .claude/skills/meeting-room-promote-brainstorm/SKILL.md (renamed → workshop-promote-brainstorm in workshop repo)

Kept: scenarios/, config/, .wiki/raw/transcripts/, .wiki/entities/, .wiki/concepts/meeting-room-architecture.md (runtime-only rewrite),
.claude/skills/{meeting-room-start-meeting,meeting-room-register-persona}/.

Promoted history of the split decision: .workshop/.wiki/concepts/meeting-room-split.md.
This commit is contained in:
2026-05-08 07:00:09 +03:00
parent 2fc99dc2a2
commit 5f800f0d96
17 changed files with 1 additions and 11877 deletions

View File

@@ -1,164 +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, creates a [<topic>-review] umbrella task in the target project blocked by impl-tasks for cross-project review handoff, 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 (12 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
if domain && N≥1: tasks_create [<topic>-review] (blocked-by impl)
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-я таска упала — продолжить остальные, в конце сообщить какие созданы / какие нет.
- Запомнить slug'и созданных импл-тасок для шага 6.5.
6.5. **Review-чекпоинт** (только для domain-промоушена с N≥1 импл-тасок; для room-meta или N=0 — skip с пометкой в логе):
- `mcp__projects-meta__tasks_create`:
- `target_project: <target>`
- `slug: <topic>-review`
- `status: blocked`
- `blocker:` `«impl-tasks: <comma-separated slugs из шага 6>»`
- `description:` шаблон ниже.
- `next_action:` «Дождаться 🟢 у всех blocker-тасок. Прочитать спецификацию (см. путь в description). Для каждой импл-таски: `git show <commit>`, прогнать тесты в её scope'е, сверить с acceptance criteria. Findings → новые follow-up tasks через `mcp__projects-meta__tasks_create`.»
- Description шаблон:
```
Code-review checkpoint для брейнсторма <topic> (промоушен <YYYY-MM-DD>).
**Спецификация:** <путь к промоушенному design-документу — concepts/<topic>.md в target-wiki или claude-skills/.wiki/concepts/<topic>-design.md, в зависимости от того куда ушёл ingest>.
**Импл-таски (review против их acceptance criteria):** <list slug'ов из шага 6>.
**Кто делает:** **не имплементер.** Следующая сессия в этом проекте (другая модель / другой день / другой агент) поднимает таску с чистым контекстом. «Я только что это написал» bias = главный риск.
**Чек-лист ревью:**
- Прочитать спецификацию (acceptance criteria каждой импл-таски).
- `git log --oneline` shipped-коммитов (по slug или scope в commit-message).
- Для каждой импл-таски: прогнать соответствующие тесты, реально проверить что они доходят до своих веток (не coverage-illusion).
- Сверить дизайн-decisions со shipped-кодом (signature, params, error-paths, безопасность).
- Findings — отдельные follow-up tasks (`<topic>-<gap>-fix` или подобное) через `tasks_create`.
**Закрытие:** только когда все findings зафайлены ИЛИ ревьюер подтвердил «нет findings» в close-note.
```
- Если `tasks_create` review-таски упала — сообщить пользователю, **продолжить** к шагу 7 (архивация буфера). Review-таску можно создать вручную позже из `.archive/<date>-<topic>.md`.
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` без подтверждения пользователя.
- `tasks_create` упал на review-таске (шаг 6.5) → не блокировать; перейти к архивации, сообщить пользователю чтобы создал вручную из `.archive/`.
## Side effects
- room-meta: создаёт `.wiki/concepts/<topic>.md`.
- domain: создаёт запись в target wiki через MCP.
- Создаёт N тасок в target `.tasks/` через MCP.
- Для domain с N≥1: создаёт зонтичную `<topic>-review` таску (status=blocked, blocker=impl-slugs) в том же target.
- Перемещает `.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` — теряется история.