Compare commits
17 Commits
99f08dbcd5
...
7611f2ec3c
| Author | SHA1 | Date | |
|---|---|---|---|
| 7611f2ec3c | |||
| 091b5f2d02 | |||
| 3f714d1b23 | |||
| 0f76613aee | |||
| 5af65948a0 | |||
| 291f8c6391 | |||
| 8764b32ee2 | |||
| 8059faf5a8 | |||
| f10a341afa | |||
| 1f471afa4e | |||
| 9b5cf9c70b | |||
| c874ba55a6 | |||
| 26e8749ea2 | |||
| f6b3e74cad | |||
| 390f938658 | |||
| 205ba78cf9 | |||
| 243c045170 |
1250
.archive/2026-05-05-meeting-room-redesign-plan.md
Normal file
1250
.archive/2026-05-05-meeting-room-redesign-plan.md
Normal file
File diff suppressed because it is too large
Load Diff
230
.archive/2026-05-05-meeting-room-redesign.md
Normal file
230
.archive/2026-05-05-meeting-room-redesign.md
Normal file
@@ -0,0 +1,230 @@
|
||||
---
|
||||
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`).
|
||||
178
.archive/2026-05-05-modulair-rag.md
Normal file
178
.archive/2026-05-05-modulair-rag.md
Normal file
@@ -0,0 +1,178 @@
|
||||
# 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-валидации)
|
||||
127
.claude/skills/meeting-room-promote-brainstorm/SKILL.md
Normal file
127
.claude/skills/meeting-room-promote-brainstorm/SKILL.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
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` — теряется история.
|
||||
84
.claude/skills/meeting-room-register-persona/SKILL.md
Normal file
84
.claude/skills/meeting-room-register-persona/SKILL.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: meeting-room-register-persona
|
||||
description: Use when user says "добавь персону", "новый агент в комнату", "register persona <role>", or wants to register a new persona for multi-agent meetings in .meeting-room. Updates config/config.yaml (single source of truth) AND generates .wiki/entities/persons/<role-id>.md. Only this skill writes to entities/persons/.
|
||||
---
|
||||
|
||||
# meeting-room-register-persona
|
||||
|
||||
Регистрирует новую persona-роль в meeting-room: пишет в `config/config.yaml` (рантайм SoT) и генерирует карточку в `.wiki/entities/persons/<role-id>.md`.
|
||||
|
||||
## When to use
|
||||
|
||||
- Пользователь говорит «добавь персону», «новый агент в комнату», «register persona <role>».
|
||||
- Пользователь вручную поправил `config/config.yaml` и хочет регенерировать карточку — тоже сюда.
|
||||
|
||||
## Inputs (collect interactively)
|
||||
|
||||
| Поле | Тип | Пример |
|
||||
|---|---|---|
|
||||
| `role-id` | snake_case, уникален в `config.yaml#roles` | `analyst` |
|
||||
| `name` | display name | `Analyst` |
|
||||
| `model` | строка | `glm-5.1` |
|
||||
| `provider` | ключ из `config.yaml#providers` | `ollama_cloud` |
|
||||
| `temperature` | число 0–1.5 | `0.5` |
|
||||
| `tools` | строка-категория | `discussion` / `web` / `none` |
|
||||
| `system_prompt` | многострочный текст | … |
|
||||
|
||||
Если данные уже есть в `config.yaml` (регенерация карточки) — не спрашивать, читать оттуда.
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Прочитать `config/config.yaml`.** Если `roles.<role-id>` уже существует:
|
||||
- Если поля совпадают со словами пользователя — это регенерация, идти к шагу 4.
|
||||
- Иначе спросить: **overwrite** / **abort** / **новый id**.
|
||||
2. **Записать в `config.yaml`** под ключом `roles.<role-id>` со всеми полями.
|
||||
- Использовать YAML-парсер с round-trip (`ruamel.yaml` для Python, или ручной insert по структуре). **Не** перезаписывать файл `yaml.dump`-ом без round-trip — порвёт комментарии и порядок ключей.
|
||||
3. **Сгенерировать `.wiki/entities/persons/<role-id>.md`:**
|
||||
|
||||
```markdown
|
||||
---
|
||||
role-id: <role-id>
|
||||
model: <model>
|
||||
provider: <provider>
|
||||
source: config/config.yaml
|
||||
---
|
||||
|
||||
# <name>
|
||||
|
||||
**Model:** <model> (<provider>), temperature <temperature>
|
||||
**Tools:** <tools>
|
||||
|
||||
## System prompt
|
||||
|
||||
<первые 500 символов system_prompt>...
|
||||
|
||||
## Source of truth
|
||||
|
||||
Полное определение — в `config/config.yaml#roles.<role-id>`. Эта карточка генерируется скилом `meeting-room-register-persona`; не редактировать вручную.
|
||||
```
|
||||
|
||||
4. **Дописать в `.wiki/log.md`:**
|
||||
|
||||
```
|
||||
<YYYY-MM-DD> registered <role-id>
|
||||
```
|
||||
|
||||
5. **Сообщить пользователю** созданные/обновлённые пути.
|
||||
|
||||
## Failure modes
|
||||
|
||||
- `config/config.yaml` отсутствует или невалидный YAML → abort, перечислить ошибки парсинга.
|
||||
- Конфликт `role-id` без выбора пользователя → abort.
|
||||
- Запись в `config.yaml` упала → abort до записи карточки (single-direction failure).
|
||||
|
||||
## Side effects
|
||||
|
||||
- Изменяет `config/config.yaml`.
|
||||
- Создаёт/обновляет `.wiki/entities/persons/<role-id>.md`.
|
||||
- Аппендит строку в `.wiki/log.md`.
|
||||
|
||||
## What NOT to do
|
||||
|
||||
- Не пиши в `entities/persons/` ничего, кроме как через эту последовательность.
|
||||
- Не редактируй `config.yaml` без round-trip парсера.
|
||||
- Не удаляй существующие роли без явной команды пользователя.
|
||||
85
.claude/skills/meeting-room-start-meeting/SKILL.md
Normal file
85
.claude/skills/meeting-room-start-meeting/SKILL.md
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
name: meeting-room-start-meeting
|
||||
description: Use when user says "запусти совещание <topic>", "start meeting <scenario>", "новое совещание <topic>", or wants to begin a multi-agent meeting from a scenarios/<topic>.md file in .meeting-room. Validates scenario frontmatter, creates skeleton transcript at .wiki/raw/transcripts/<date>-<topic>.md, opens working buffer at .brainstorm/<topic>.md, logs to .wiki/log.md.
|
||||
---
|
||||
|
||||
# meeting-room-start-meeting
|
||||
|
||||
Запускает совещание из `scenarios/<topic>.md`: валидирует frontmatter, создаёт skeleton-транскрипт в `.wiki/raw/transcripts/`, заводит рабочий буфер в `.brainstorm/`, логирует в `.wiki/log.md`.
|
||||
|
||||
## When to use
|
||||
|
||||
- Пользователь говорит «запусти совещание <topic>», «start meeting <scenario>», «новое совещание <topic>».
|
||||
- Пользователь указал scenario-файл и хочет подготовить артефакты под него.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Путь `scenarios/<topic>.md` или просто `<topic>` (тогда искать `scenarios/<topic>.md`).
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Прочитать `scenarios/<topic>.md`.** Распарсить YAML frontmatter.
|
||||
2. **Валидация:**
|
||||
- `name`, `problem` непустые;
|
||||
- `participants` — список, все элементы существуют как ключи `roles.*` в `config/config.yaml`;
|
||||
- `max_rounds` — целое (если присутствует).
|
||||
- При ошибке — перечислить, не создавать ничего.
|
||||
3. **Сегодняшняя дата** → `<date> = YYYY-MM-DD` (UTC локального компа).
|
||||
4. **Создать `.wiki/raw/transcripts/<date>-<topic>.md`** (skeleton):
|
||||
|
||||
```markdown
|
||||
---
|
||||
date: <date>
|
||||
scenario: scenarios/<topic>.md
|
||||
participants: [<participant1>, <participant2>, ...]
|
||||
problem: |
|
||||
<первая строка problem из scenario>
|
||||
---
|
||||
|
||||
# <name> — transcript <date>
|
||||
|
||||
<!-- runner будет дописывать сюда. Append-only после первой записи. -->
|
||||
```
|
||||
|
||||
5. **Создать `.brainstorm/<topic>.md`** (если ещё нет):
|
||||
|
||||
```markdown
|
||||
# <name> — working buffer
|
||||
|
||||
- **Scenario:** [scenarios/<topic>.md](../scenarios/<topic>.md)
|
||||
- **Transcript:** [.wiki/raw/transcripts/<date>-<topic>.md](../.wiki/raw/transcripts/<date>-<topic>.md)
|
||||
- **Started:** <date>
|
||||
|
||||
## Заметки
|
||||
|
||||
<!-- здесь черновик. Промочится скилом meeting-room-promote-brainstorm. -->
|
||||
```
|
||||
|
||||
Если файл уже существует — спросить: **append-skip**, **overwrite**, **abort**.
|
||||
|
||||
6. **Дописать в `.wiki/log.md`:**
|
||||
|
||||
```
|
||||
<date> started <topic> ([<participants comma-sep>])
|
||||
```
|
||||
|
||||
7. **Вернуть пользователю:** созданные пути и подсказку — как запустить runner (на сегодня запуск runner'а вне scope, скил готовит только артефакты).
|
||||
|
||||
## Failure modes
|
||||
|
||||
- `scenarios/<topic>.md` отсутствует → abort.
|
||||
- Frontmatter невалидный → перечислить ошибки, ничего не создавать.
|
||||
- Participant отсутствует в `config/config.yaml#roles` → abort с указанием отсутствующих ролей.
|
||||
- `.brainstorm/<topic>.md` уже есть и пользователь выбрал abort → exit без записи в `raw/transcripts/`.
|
||||
|
||||
## Side effects
|
||||
|
||||
- Создаёт `.wiki/raw/transcripts/<date>-<topic>.md`.
|
||||
- Создаёт `.brainstorm/<topic>.md` (или модифицирует с разрешения).
|
||||
- Аппендит строку в `.wiki/log.md`.
|
||||
|
||||
## What NOT to do
|
||||
|
||||
- Не запускать runner — это вне scope скила.
|
||||
- Не редактировать `scenarios/<topic>.md`.
|
||||
- Не пытаться угадать `participants` если их нет в `config.yaml`.
|
||||
68
.wiki/CLAUDE.md
Normal file
68
.wiki/CLAUDE.md
Normal file
@@ -0,0 +1,68 @@
|
||||
# .wiki — Schema (room-meta only)
|
||||
|
||||
Эта `.wiki/` — локальная и узко-доменная: **только знание о том, как работает meeting-room**. Доменное содержимое из совещаний промочивается в глобальную вики через `mcp__projects-meta__knowledge_ingest`, не сюда.
|
||||
|
||||
## Layout (Karpathy LLM Wiki canonical)
|
||||
|
||||
- `index.md` — навигация
|
||||
- `overview.md` — что такое meeting-room на одной странице
|
||||
- `log.md` — append-only хронологический лог: `<YYYY-MM-DD> <event-type> <topic> [details]`
|
||||
- `raw/research/<date>-<topic>.md` — внешние clippings, immutable
|
||||
- `raw/transcripts/<date>-<topic>.md` — транскрипты совещаний, immutable
|
||||
- `entities/persons/<role-id>.md` — карточки persona (генерируются скилом `meeting-room-register-persona` из `config/config.yaml`)
|
||||
- `entities/projects/<proj>.md` — pointer-карточки целевых проектов
|
||||
- `concepts/<topic>.md` — room-meta: методология, ретроспективы, паттерны фасилитации
|
||||
- `packages/<tool>.md` — инструменты комнаты (runner, framework, schema)
|
||||
- `sources/<title>.md` — внешняя литература
|
||||
|
||||
## Frontmatter requirements
|
||||
|
||||
**`entities/persons/<role-id>.md`:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
role-id: analyst
|
||||
model: glm-5.1
|
||||
provider: ollama_cloud
|
||||
source: config/config.yaml
|
||||
---
|
||||
```
|
||||
|
||||
**`raw/research/<date>-<topic>.md`:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
date: 2026-05-03
|
||||
source: <URL>
|
||||
topic: <topic>
|
||||
---
|
||||
```
|
||||
|
||||
**`raw/transcripts/<date>-<topic>.md`:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
date: 2026-05-03
|
||||
scenario: scenarios/<topic>.md
|
||||
participants: [moderator, skeptic, idea_generator, analyst]
|
||||
problem: <one-line>
|
||||
---
|
||||
```
|
||||
|
||||
**`concepts/<topic>.md`:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
date: 2026-05-05
|
||||
source: .brainstorm/<topic>.md
|
||||
status: promoted
|
||||
type: room-meta
|
||||
---
|
||||
```
|
||||
|
||||
## Hard rules
|
||||
|
||||
1. **Никакого доменного содержимого** в `concepts/`. Если контент пригодился бы в чужом проекте — он не room-meta, а domain → `mcp__projects-meta__knowledge_ingest` в целевой проект.
|
||||
2. `raw/` immutable: append-only, не редактируем после фиксации.
|
||||
3. `entities/persons/` пишет **только** скил `meeting-room-register-persona`. Source-of-truth — `config/config.yaml`.
|
||||
4. `log.md` append-only, формат строки: `<YYYY-MM-DD> <event> <topic> [details]`. Никаких удалений.
|
||||
0
.wiki/concepts/.gitkeep
Normal file
0
.wiki/concepts/.gitkeep
Normal file
231
.wiki/concepts/meeting-room-architecture.md
Normal file
231
.wiki/concepts/meeting-room-architecture.md
Normal file
@@ -0,0 +1,231 @@
|
||||
---
|
||||
date: 2026-05-05
|
||||
source: .brainstorm/meeting-room-redesign.md
|
||||
status: promoted
|
||||
type: room-meta
|
||||
---
|
||||
|
||||
# Meeting-Room Architecture — promoted spec
|
||||
|
||||
> Промочено 2026-05-05 из `.brainstorm/meeting-room-redesign.md`. Spec, который комната провалидировала на самой себе: первый прогон скила `meeting-room-promote-brainstorm` сделан именно над этим файлом. Implementation plan архивирован отдельно — `.archive/2026-05-05-meeting-room-redesign-plan.md`.
|
||||
|
||||
## 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`).
|
||||
185
.wiki/concepts/modulair-rag-brainstorm-trace.md
Normal file
185
.wiki/concepts/modulair-rag-brainstorm-trace.md
Normal file
@@ -0,0 +1,185 @@
|
||||
---
|
||||
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.
|
||||
0
.wiki/entities/persons/.gitkeep
Normal file
0
.wiki/entities/persons/.gitkeep
Normal file
27
.wiki/entities/persons/analyst.md
Normal file
27
.wiki/entities/persons/analyst.md
Normal file
@@ -0,0 +1,27 @@
|
||||
---
|
||||
role-id: analyst
|
||||
model: glm-5.1
|
||||
provider: ollama_cloud
|
||||
source: config/config.yaml
|
||||
---
|
||||
|
||||
# Analyst
|
||||
|
||||
**Model:** glm-5.1 (ollama_cloud), temperature 0.5
|
||||
**Tools:** discussion
|
||||
|
||||
## System prompt
|
||||
|
||||
You are an analyst participating in a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Start by expressing your position and analysis. Only AFTER
|
||||
stating your view, use tools sparingly to verify specific
|
||||
claims or look up a detail. Do NOT research the entire topic
|
||||
before speaking — this is a discussion, not a research project.
|
||||
Structure the discussion, highlight key arguments, assess risks
|
||||
and benefits of each option...
|
||||
|
||||
## Source of truth
|
||||
|
||||
Полное определение — в `config/config.yaml#roles.analyst`. Эта карточка генерируется скилом `meeting-room-register-persona`; не редактировать вручную.
|
||||
26
.wiki/entities/persons/idea_generator.md
Normal file
26
.wiki/entities/persons/idea_generator.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
role-id: idea_generator
|
||||
model: deepseek-v4-flash
|
||||
provider: ollama_cloud
|
||||
source: config/config.yaml
|
||||
---
|
||||
|
||||
# Idea Generator
|
||||
|
||||
**Model:** deepseek-v4-flash (ollama_cloud), temperature 1.0
|
||||
**Tools:** web
|
||||
|
||||
## System prompt
|
||||
|
||||
You are a creative idea generator participating in a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Start by proposing your ideas directly. Only use web search
|
||||
sparingly to find a specific analog or trend — do NOT research
|
||||
the entire topic before speaking. This is a discussion, not
|
||||
a research project.
|
||||
Propose unconventional solutions, think broader than the problem...
|
||||
|
||||
## Source of truth
|
||||
|
||||
Полное определение — в `config/config.yaml#roles.idea_generator`. Эта карточка генерируется скилом `meeting-room-register-persona`; не редактировать вручную.
|
||||
25
.wiki/entities/persons/moderator.md
Normal file
25
.wiki/entities/persons/moderator.md
Normal file
@@ -0,0 +1,25 @@
|
||||
---
|
||||
role-id: moderator
|
||||
model: glm-5.1
|
||||
provider: ollama_cloud
|
||||
source: config/config.yaml
|
||||
---
|
||||
|
||||
# Moderator
|
||||
|
||||
**Model:** glm-5.1 (ollama_cloud), temperature 0.7
|
||||
**Tools:** none
|
||||
|
||||
## System prompt
|
||||
|
||||
You are the moderator of a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Guide the conversation, make sure everyone speaks, summarize
|
||||
intermediate results, ask clarifying questions about the problem.
|
||||
Don't push your own opinion. Keep it concise and on-topic.
|
||||
Always respond in Russian.
|
||||
|
||||
## Source of truth
|
||||
|
||||
Полное определение — в `config/config.yaml#roles.moderator`. Эта карточка генерируется скилом `meeting-room-register-persona`; не редактировать вручную.
|
||||
26
.wiki/entities/persons/skeptic.md
Normal file
26
.wiki/entities/persons/skeptic.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
role-id: skeptic
|
||||
model: qwen3.5:397b
|
||||
provider: ollama_cloud
|
||||
source: config/config.yaml
|
||||
---
|
||||
|
||||
# Skeptic
|
||||
|
||||
**Model:** qwen3.5:397b (ollama_cloud), temperature 0.9
|
||||
**Tools:** discussion
|
||||
|
||||
## System prompt
|
||||
|
||||
You are a skeptic and critic participating in a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Start by expressing your critique and counter-arguments directly.
|
||||
Only use file-reading tools to verify a specific claim someone
|
||||
made — do NOT browse files before speaking. This is a discussion,
|
||||
not a research project.
|
||||
Find weaknesses in proposals, ask hard questions...
|
||||
|
||||
## Source of truth
|
||||
|
||||
Полное определение — в `config/config.yaml#roles.skeptic`. Эта карточка генерируется скилом `meeting-room-register-persona`; не редактировать вручную.
|
||||
0
.wiki/entities/projects/.gitkeep
Normal file
0
.wiki/entities/projects/.gitkeep
Normal file
19
.wiki/index.md
Normal file
19
.wiki/index.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Meeting-Room Wiki — index
|
||||
|
||||
> Knowledge about how this meeting-room itself works. Domain content lives in `~/projects/.wiki/`.
|
||||
|
||||
## Navigation
|
||||
|
||||
- [Overview](overview.md) — что такое meeting-room
|
||||
- [Log](log.md) — хронология встреч, промоушенов, изменений persona
|
||||
- [Schema](CLAUDE.md) — раскладка и frontmatter-требования
|
||||
|
||||
## Sections
|
||||
|
||||
- [Personas](entities/persons/) — карточки ролей (генерируются из `config/config.yaml`)
|
||||
- [Projects](entities/projects/) — pointer-карточки целевых проектов
|
||||
- [Concepts](concepts/) — методология, ретро, паттерны
|
||||
- [Raw research](raw/research/) — clippings и внешние транскрипты
|
||||
- [Raw transcripts](raw/transcripts/) — транскрипты совещаний
|
||||
- [Packages](packages/) — инструменты комнаты
|
||||
- [Sources](sources/) — внешняя литература
|
||||
17
.wiki/log.md
Normal file
17
.wiki/log.md
Normal file
@@ -0,0 +1,17 @@
|
||||
# Log
|
||||
|
||||
Append-only. Format: `<YYYY-MM-DD> <event> <topic> [details]`.
|
||||
|
||||
Events: `started`, `promoted`, `registered`, `archived`.
|
||||
|
||||
---
|
||||
|
||||
2026-05-05 bootstrapped meeting-room redesign (initial .wiki/ skeleton)
|
||||
2026-05-05 registered analyst
|
||||
2026-05-05 registered idea_generator
|
||||
2026-05-05 registered moderator
|
||||
2026-05-05 registered skeptic
|
||||
2026-05-05 started modulair ([moderator, skeptic, idea_generator, analyst])
|
||||
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)
|
||||
19
.wiki/overview.md
Normal file
19
.wiki/overview.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# Meeting-Room — overview
|
||||
|
||||
`.meeting-room/` — кросс-проектное рабочее пространство для брейнштормов и круглых столов агентов. Не код-проект.
|
||||
|
||||
## Зачем
|
||||
|
||||
Место, где агенты из разных проектов пересекаются ради задач, которые не помещаются в один backlog. Брейнсторм-зона: артефакты вызревают здесь и потом промочиваются — либо в локальный `.wiki/concepts/` (если это знание про саму комнату), либо в глобальную вики и `.tasks/` целевого проекта (если доменное).
|
||||
|
||||
## Что внутри
|
||||
|
||||
- `scenarios/` — frontmatter-сценарии для запуска multi-agent совещания
|
||||
- `config/config.yaml` — реестр persona (рантайм-конфиг)
|
||||
- `.brainstorm/` — рабочий буфер: черновики, single-agent capture
|
||||
- `.archive/` — буфер после промоушена
|
||||
- `.wiki/` — Karpathy-style room-meta wiki (этот раздел)
|
||||
|
||||
## Как пользоваться
|
||||
|
||||
См. корневой `CLAUDE.md` — там семантика и триггер-фразы скилов.
|
||||
0
.wiki/packages/.gitkeep
Normal file
0
.wiki/packages/.gitkeep
Normal file
8
.wiki/raw/README.md
Normal file
8
.wiki/raw/README.md
Normal file
@@ -0,0 +1,8 @@
|
||||
# raw/
|
||||
|
||||
Immutable, append-only. Никаких редактур после фиксации.
|
||||
|
||||
- `research/` — внешние clippings, pre-loaded материалы перед совещанием.
|
||||
- `transcripts/` — транскрипты прошедших совещаний.
|
||||
|
||||
При промоушене `concepts/<topic>.md` ссылается сюда через frontmatter `source:`.
|
||||
0
.wiki/raw/research/.gitkeep
Normal file
0
.wiki/raw/research/.gitkeep
Normal file
186
.wiki/raw/research/2026-05-03-code-review.md
Normal file
186
.wiki/raw/research/2026-05-03-code-review.md
Normal file
@@ -0,0 +1,186 @@
|
||||
---
|
||||
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
|
||||
1577
.wiki/raw/research/2026-05-03-modulair.md
Normal file
1577
.wiki/raw/research/2026-05-03-modulair.md
Normal file
File diff suppressed because it is too large
Load Diff
0
.wiki/raw/transcripts/.gitkeep
Normal file
0
.wiki/raw/transcripts/.gitkeep
Normal file
0
.wiki/sources/.gitkeep
Normal file
0
.wiki/sources/.gitkeep
Normal file
55
CLAUDE.md
Normal file
55
CLAUDE.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# .meeting-room — workspace contract
|
||||
|
||||
`.meeting-room/` — brainstorm-зона для кросс-проектных совещаний. **Не код-проект.**
|
||||
|
||||
## Семантика артефактов
|
||||
|
||||
| Папка | Что |
|
||||
|---|---|
|
||||
| `scenarios/` | runtime: сценарии запуска multi-agent совещания (frontmatter: `name`, `participants`, `problem`, `max_rounds`) |
|
||||
| `config/config.yaml` | runtime: реестр persona (single source of truth) |
|
||||
| `.brainstorm/<topic>.md` | рабочий буфер до промоушена |
|
||||
| `.archive/<date>-<topic>.md` | post-promotion: исходник из `.brainstorm/` |
|
||||
| `.wiki/raw/research/` | immutable: внешние clippings (бывший `source/`) |
|
||||
| `.wiki/raw/transcripts/` | immutable: транскрипты совещаний (бывший `sessions/`) |
|
||||
| `.wiki/entities/persons/` | карточки persona, генерируются из `config.yaml` |
|
||||
| `.wiki/concepts/` | room-meta: методология, ретро, паттерны |
|
||||
|
||||
**Перед предложением tooling/архитектуры — прочитать `.wiki/raw/research/` для текущего топика.** Это закрепляет урок из `feedback_read_source_transcripts.md` (память).
|
||||
|
||||
## Жёсткие правила
|
||||
|
||||
1. **Доменное содержимое никогда не оседает в локальном `.wiki/`** — всегда в глобал через `mcp__projects-meta__knowledge_ingest` в `~/projects/<proj>/.wiki/`.
|
||||
2. **Локальный `.wiki/concepts/` — только room-meta** (про саму комнату).
|
||||
3. **Локальные `.tasks/` не создавать** — экшены идут в `.tasks/` целевого проекта через `mcp__projects-meta__tasks_create`.
|
||||
4. **`entities/persons/` пишет только скил `meeting-room-register-persona`.** SoT — `config/config.yaml`.
|
||||
|
||||
## Триггеры скилов 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>`» |
|
||||
|
||||
## Override `project-discipline`
|
||||
|
||||
В этой комнате применяются:
|
||||
|
||||
- ✅ master-only (никаких feature-веток)
|
||||
- ✅ commit freely / push by permission
|
||||
|
||||
**Не применяются:**
|
||||
|
||||
- ❌ semver-bump — нет versioned-артефактов (`SKILL.md` без version в frontmatter, нет `package.json`/`pyproject.toml`)
|
||||
- ❌ локальный `.tasks/` — запрещён правилом §3 выше
|
||||
|
||||
## Persona registry
|
||||
|
||||
SoT — `config/config.yaml`. Карточки `.wiki/entities/persons/<role-id>.md` — производные. Ручные правки разрешены **только** в `config.yaml`. Регенерация карточки — снова `meeting-room-register-persona <role-id>`.
|
||||
|
||||
## Pointers
|
||||
|
||||
- Schema локальной вики: `.wiki/CLAUDE.md`
|
||||
- Текущий redesign-spec (до self-promotion): `.brainstorm/meeting-room-redesign.md`
|
||||
- После self-promotion: `.wiki/concepts/meeting-room-architecture.md`
|
||||
67
README.md
67
README.md
@@ -1,57 +1,36 @@
|
||||
# .meeting-room — Shared Workspace
|
||||
|
||||
> "Офис" для кросс-проектных совещаний агентов. Транзитная зона — не ведёт `.tasks`/`.wiki`, всё репортит в глобальный скоуп.
|
||||
> Кросс-проектные брейнстормы и круглые столы агентов. Brainstorm-зона: room-meta лежит локально в `.wiki/`, доменное промочивается в глобальную вики и `.tasks/` целевого проекта через `projects-meta`.
|
||||
|
||||
## Purpose
|
||||
## Quickstart
|
||||
|
||||
Место, где агенты из разных проектов пересекаются для решения кросс-проектных задач.
|
||||
- Прочитать `CLAUDE.md` — workspace contract (семантика, правила, триггеры скилов).
|
||||
- Прочитать `.wiki/index.md` — навигация по локальной вики.
|
||||
- Сценарии для multi-agent совещаний — в `scenarios/`.
|
||||
- Реестр persona — в `config/config.yaml` (карточки в `.wiki/entities/persons/` генерируются скилом).
|
||||
|
||||
## Structure
|
||||
## Skills v1
|
||||
|
||||
- `meeting-room-promote-brainstorm` — `.brainstorm/<topic>.md` → либо локальный `.wiki/concepts/`, либо глобальная вики; action-items → `.tasks/` целевого проекта; исходник → `.archive/`.
|
||||
- `meeting-room-start-meeting` — валидирует `scenarios/<topic>.md`, заводит skeleton-транскрипт и буфер.
|
||||
- `meeting-room-register-persona` — добавляет роль в `config.yaml` и генерирует карточку в `.wiki/entities/persons/`.
|
||||
|
||||
## Folder map
|
||||
|
||||
```
|
||||
.meeting-room/
|
||||
├── .brainstorm/ # "Кабинет": обсуждение сырых идей с доверенным агентом (CSO)
|
||||
├── .archive/ # "Черный ящик": история завершенных совещаний
|
||||
└── README.md # This file
|
||||
├── CLAUDE.md ← workspace contract
|
||||
├── README.md ← этот файл
|
||||
├── .wiki/ ← Karpathy room-meta wiki
|
||||
├── scenarios/ ← runtime: сценарии запуска
|
||||
├── config/ ← runtime: реестр persona
|
||||
├── .brainstorm/ ← рабочий буфер
|
||||
├── .archive/ ← post-promotion
|
||||
└── .claude/skills/ ← локальные скилы
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
### .brainstorm/ — Твой инкубатор идей
|
||||
|
||||
**Для работы с доверенным агентом (CSO):**
|
||||
|
||||
1. Создай файл идеи: `idea_001_name.md`
|
||||
2. Опиши свои тезисы
|
||||
3. Агент дописывает вопросы/критику
|
||||
4. Результат → в глобальные `.tasks` или `.wiki`
|
||||
|
||||
**Почему это круто:**
|
||||
- Markdown = структурированный артефакт
|
||||
- Версионность через Git
|
||||
- Готовый материал для митингов других агентов
|
||||
|
||||
### .archive/ — История совещаний
|
||||
|
||||
По завершении сессии → архив.
|
||||
В самой `.meeting-room` только **активные** обсуждения.
|
||||
|
||||
## Rules
|
||||
|
||||
- ❌ **NO** `.tasks` / `.wiki` внутри (транзитная зона)
|
||||
- ✅ Все задачи → в глобальный `../.tasks/`
|
||||
- ✅ Все выводы → в глобальный `../.wiki/`
|
||||
- ✅ Git для версионности идей
|
||||
|
||||
## Integration
|
||||
|
||||
- **Input**: Идеи из `.brainstorm/`
|
||||
- **Output**: Задачи в `.tasks/`, знания в `.wiki/`
|
||||
- **Context**: Доступ ко всем проектам
|
||||
|
||||
## Persona Registry
|
||||
|
||||
Твой доверенный агент для `.brainstorm/`:
|
||||
- **Role**: Chief Strategy Officer (CSO)
|
||||
- **Access**: Все глобальные папки (`.wiki`, `.tasks`)
|
||||
- **Job**: Обстучать идеи before линейной реализации
|
||||
- **Role:** Chief Strategy Officer (CSO)
|
||||
- **Job:** Обстучать идеи перед линейной реализацией.
|
||||
|
||||
85
config/config.yaml
Normal file
85
config/config.yaml
Normal file
@@ -0,0 +1,85 @@
|
||||
defaults:
|
||||
framework: custom
|
||||
max_rounds: 8
|
||||
language: ru
|
||||
workdir: ..
|
||||
|
||||
providers:
|
||||
routerai:
|
||||
api_key: ${MEETING_ROOM_ROUTERAI_API_KEY}
|
||||
base_url: ${MEETING_ROOM_ROUTERAI_BASE_URL}
|
||||
ollama_cloud:
|
||||
api_key: 02a8f6e9f9744088885982ac645f1ce1.HB1MFh4AlTpyic9oJGxQjNuA
|
||||
base_url: https://ollama.com/v1
|
||||
|
||||
roles:
|
||||
analyst:
|
||||
model: glm-5.1
|
||||
name: Analyst
|
||||
provider: ollama_cloud
|
||||
temperature: 0.5
|
||||
tools: discussion
|
||||
system_prompt: |
|
||||
You are an analyst participating in a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Start by expressing your position and analysis. Only AFTER
|
||||
stating your view, use tools sparingly to verify specific
|
||||
claims or look up a detail. Do NOT research the entire topic
|
||||
before speaking — this is a discussion, not a research project.
|
||||
Structure the discussion, highlight key arguments, assess risks
|
||||
and benefits of each option, summarize. Think logically and
|
||||
systematically. Propose concrete action plans.
|
||||
Always respond in Russian.
|
||||
|
||||
idea_generator:
|
||||
model: deepseek-v4-flash
|
||||
name: Idea Generator
|
||||
provider: ollama_cloud
|
||||
temperature: 1.0
|
||||
tools: web
|
||||
system_prompt: |
|
||||
You are a creative idea generator participating in a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Start by proposing your ideas directly. Only use web search
|
||||
sparingly to find a specific analog or trend — do NOT research
|
||||
the entire topic before speaking. This is a discussion, not
|
||||
a research project.
|
||||
Propose unconventional solutions, think broader than the problem,
|
||||
generate many options. Don't be afraid of crazy ideas — the best
|
||||
solutions come from them. Build on others' ideas.
|
||||
Always respond in Russian.
|
||||
|
||||
moderator:
|
||||
model: glm-5.1
|
||||
name: Moderator
|
||||
provider: ollama_cloud
|
||||
temperature: 0.7
|
||||
tools: none
|
||||
system_prompt: |
|
||||
You are the moderator of a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Guide the conversation, make sure everyone speaks, summarize
|
||||
intermediate results, ask clarifying questions about the problem.
|
||||
Don't push your own opinion. Keep it concise and on-topic.
|
||||
Always respond in Russian.
|
||||
|
||||
skeptic:
|
||||
model: qwen3.5:397b
|
||||
name: Skeptic
|
||||
provider: ollama_cloud
|
||||
temperature: 0.9
|
||||
tools: discussion
|
||||
system_prompt: |
|
||||
You are a skeptic and critic participating in a group discussion.
|
||||
You will be given a specific problem to discuss — do NOT ask
|
||||
what the topic is, it is provided in the message below.
|
||||
Start by expressing your critique and counter-arguments directly.
|
||||
Only use file-reading tools to verify a specific claim someone
|
||||
made — do NOT browse files before speaking. This is a discussion,
|
||||
not a research project.
|
||||
Find weaknesses in proposals, ask hard questions, offer
|
||||
counter-arguments. Be constructive but tough. Don't agree easily.
|
||||
Always respond in Russian.
|
||||
37
scenarios/example-problem.md
Normal file
37
scenarios/example-problem.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Example Problem Scenario
|
||||
|
||||
## Context
|
||||
|
||||
Описание проблемы или задачи для совещания с агентами.
|
||||
|
||||
## Problem
|
||||
|
||||
Чётко сформулируй проблему:
|
||||
- Что не работает?
|
||||
- Что нужно улучшить?
|
||||
- Какие есть ограничения?
|
||||
|
||||
## Goals
|
||||
|
||||
Чего хотим достичь:
|
||||
1. Первая цель
|
||||
2. Вторая цель
|
||||
3. Третья цель
|
||||
|
||||
## Participants
|
||||
|
||||
Кто участвует в совещании:
|
||||
- CSO (Chief Strategy Officer) — ведёт
|
||||
- Эксперты из конкретных проектов
|
||||
- Другие агенты по необходимости
|
||||
|
||||
## Expected Output
|
||||
|
||||
Что должно получиться в результате:
|
||||
- Конкретное решение
|
||||
- План действий
|
||||
- Артефакты (код, документы, схемы)
|
||||
|
||||
## Notes
|
||||
|
||||
Заметки в процессе обсуждения...
|
||||
48
scenarios/modulair.md
Normal file
48
scenarios/modulair.md
Normal file
@@ -0,0 +1,48 @@
|
||||
---
|
||||
name: "ModulAIr"
|
||||
participants:
|
||||
- moderator
|
||||
- skeptic
|
||||
- idea_generator
|
||||
- analyst
|
||||
max_rounds: 6
|
||||
problem: |
|
||||
Спроектировать AI-управляемый модуль для еврорэк на базе Pico 2 W.
|
||||
Модуль — секвенсор/контроллер с 8 CV и 8 Gate выходами, входами Clock/Reset,
|
||||
MIDI (USB + UART), Wi-Fi и аудиовходами для анализа.
|
||||
Управляется через MCP-сервер + LightRAG (база знаний по модулям и теории музыки).
|
||||
Оркестратор — Hermes Agent.
|
||||
Вопросы: какой ЦАП выбрать (DAC8568?), как организовать скриптовый движок
|
||||
(Teletype-стиль), как интегрировать RAG для доступа к мануалам модулей,Я за
|
||||
и как обеспечить точный тайминг при Wi-Fi задержках.
|
||||
---
|
||||
|
||||
# ModulAIr — AI EuroRack Controller
|
||||
|
||||
## Суть проекта
|
||||
|
||||
Модуль еврорэк на Pico 2 W, который работает как AI-секвенсор. Человек играет на модулях,
|
||||
AI (через MCP) управляет CV/Gate выходами, опираясь на базу знаний о модулях (LightRAG)
|
||||
и теорию музыки. Человек и AI ведут диалог о том, что играть и как патчить.
|
||||
|
||||
## Железо
|
||||
|
||||
- Pico 2 W (RP2350, 2 ядра, Wi-Fi, USB-C)
|
||||
- 8 CV выходов (через внешний ЦАП — кандидаты: DAC8568 16-bit 8-ch, MCP4728 12-bit 4-ch)
|
||||
- 8 Gate выходов
|
||||
- Входы: Clock, Reset, Start/Stop, 2-4 CV для «прослушки» (ADC)
|
||||
- MIDI: USB-MIDI + TRS-MIDI (UART)
|
||||
- Аудиовходы: через преамп → ADC для анализа (envelope follower, pitch detection)
|
||||
|
||||
## Софт
|
||||
|
||||
- Скриптовый движок в стиле Monome Teletype / ER-101 на Pico
|
||||
- MCP-сервер на компе как мост между LLM и Pico
|
||||
- LightRAG как база знаний (мануалы модулей, теория музыки, исходники VCV Rack)
|
||||
- Hermes Agent как оркестратор
|
||||
|
||||
## Ссылки на контекст
|
||||
|
||||
- Проект по железу: heart-and-mask
|
||||
- Open-source ER-101: https://github.com/odevices/er-101
|
||||
- Open-source Teletype: https://github.com/monome/teletype
|
||||
Reference in New Issue
Block a user