pelmen/kin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kin/DESIGN.md
johnfrum1234 f5a0e2f0b9 Add DESIGN.md — main architecture document for Kin agent orchestrator 
Copied from agent-orchestrator-research.md as the foundational design reference.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-15 13:10:10 +02:00

1291 lines
72 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Исследование мультиагентных оркестраторов и проект собственного
## Дата: 15 марта 2026
## Проект: Kin — виртуальная софтверная компания
---
## ЧАСТЬ 1: Анализ Ruflo (ex Claude Flow)
### 1.1 Общие сведения
- **Репо**: github.com/ruvnet/ruflo
- **Автор**: ruvnet (один разработчик)
- **Звёзды**: ~20K, форки: ~2.3K
- **Коммиты**: 5,800+, 55 alpha-итераций
- **Текущая версия**: v3.5.0 (февраль 2026) — первый "стабильный" релиз
- **Стек**: TypeScript/Node.js, WASM (Rust) для policy engine и embeddings
- **Пакеты**: @claude-flow/cli, claude-flow, ruflo — все три являются обёртками над @claude-flow/cli
### 1.2 Архитектура (заявленная)
```
User → Ruflo CLI/MCP → Router → Swarm → Agents → Memory → LLM Providers
↑ ↓
└──────────────── Learning Loop ←────────────────────────┘
```
**Ключевые компоненты:**
- **CLI/MCP интерфейс** — входная точка, 175+ MCP-тулов
- **Router** — маршрутизация задач к агентам, автоматический выбор модели (haiku/sonnet/opus)
- **Swarm Manager** — управление топологией (hierarchical, mesh, ring, star)
- **Agent System** — 60+ предопределённых агентов в 16 категориях
- **Memory** — SQLite (.swarm/memory.db), ReasoningBank с hash-based embeddings
- **Hive Mind** — queen/worker иерархия с "consensus" протоколами
### 1.3 Что РЕАЛЬНО работает (по issue tracker и коду)
**Механизм запуска агентов:**
- Ключевая функция: `launchClaudeCodeWithSwarm` в `src/cli/commands/swarm-new.ts`
- ЧТО ОНА ДЕЛАЕТ: формирует гигантский `swarmPrompt` (текстовую строку) и передаёт его в `claude` CLI
- ПО СУТИ: это prompt engineering — агенты "существуют" как инструкции в промпте одного Claude Code
- Файлы генерируются прямо в корень проекта (issue #398 — нет контроля output directory)
**Критический баг (issue #955):**
- `--claude` флаг в `hive-mind spawn` ДОКУМЕНТИРОВАН, но НЕ РЕАЛИЗОВАН
- Команда спавнит "worker agent" (запись в БД), но НЕ запускает Claude Code
- Флаг молча игнорируется
**Memory система:**
- SQLite-based, работает
- ReasoningBank использует hash-based embeddings (не требует API) — быстрые, но примитивные
- 2-3ms latency для поиска — это хорошо
- Persistent между сессиями
**GUI:**
- Web UI на порту 3000 (WebSocket)
- Терминальный эмулятор в браузере
- @liamhelmer/claude-flow-ui — отдельный npm-пакет для UI
### 1.4 Что МАРКЕТИНГ vs РЕАЛЬНОСТЬ
| Заявлено | Реальность |
|----------|-----------|
| 60+ специализированных агентов | Папки с CLAUDE.md промптами в .agents/skills/, по сути — шаблоны для system prompt |
| Byzantine consensus | Протокол описан, но по issue tracker - не используется в реальных сценариях |
| Neural pattern recognition | Hash-based embeddings + паттерн-матчинг, не нейросеть |
| 127 параллельных агентов (из issue #125) | Это wishlist/epic, не реализация. Реально — один claude процесс с большим промптом |
| Self-learning | Запись success/failure в SQLite + маршрутизация на основе прошлых результатов. Работает, но это не ML |
| WASM SIMD acceleration | Rust-based WASM для embeddings — реально работает, даёт скорость |
| Hive Mind | Queen = координирующий промпт, Workers = записи в БД, НЕ отдельные Claude процессы |
### 1.5 Что ВЗЯТЬ из Ruflo
**Сильные стороны (стоит перенять):**
1. **MCP-интеграция** — агент-оркестратор как MCP-сервер для Claude Code. Это позволяет Claude Code вызывать оркестратор как тулзу, а не наоборот. Элегантно.
2. **SQLite memory с namespace** — простая, надёжная, persistent. Key-value с namespace (architecture/, bugs/, decisions/) — хороший паттерн.
3. **Model routing** — автоматический выбор haiku для простых задач, opus для сложных. Экономит деньги.
4. **Anti-drift defaults** — `topology: hierarchical` + `maxAgents: 8` + `strategy: specialized`. Маленькие команды с чёткими ролями дрифтят меньше.
5. **ADR (Architecture Decision Records)** — spec-first подход, где архитектура описана в ADR-файлах и агенты обязаны следовать.
6. **Hook system** — pre-task/post-task хуки для автоматизации (pre: загрузить контекст, post: сохранить результат).
7. **Структура .agents/skills/** — каждый агент = директория с CLAUDE.md (system prompt) + tools + config. Модульно, расширяемо.
**Слабые стороны (НЕ повторять):**
1. **Fake parallelism** — агенты не являются отдельными процессами. Это один Claude Code с большим промптом, притворяющимся несколькими агентами. ГЛАВНАЯ ПРОБЛЕМА — контекст всё равно один, compaction убивает всех одновременно.
2. **Over-engineering** — 215 MCP tools, 87 в wiki, byzantine consensus — для одного разработчика это красные флаги. Много surface area, мало глубины.
3. **Размытие ответственности пакетов** — 3 npm-пакета (@claude-flow/cli, claude-flow, ruflo) — это один и тот же код. Ребрендинг создаёт путаницу.
4. **Нет реальной изоляции контекста** — это ключевое. Если агент-программист и агент-тестировщик живут в одном контексте, compaction убивает нюансы обоих.
5. **Документация как продукт** — README и Wiki описывают фичи, которые не реализованы (issue #955). Доверять нельзя.
---
## ЧАСТЬ 2: Анализ других фреймворков (ключевые выводы)
### 2.1 CrewAI (Python)
- **Модель**: Role-based crews + Event-driven Flows
- **Сильное**: Быстрое прототипирование, MCP + A2A поддержка, 44K+ GitHub stars
- **Слабое**: Ограниченный checkpointing, роли через prompt engineering (не настоящая изоляция)
- **Для нас**: Flows (event-driven оркестрация поверх crews) — хорошая концепция
### 2.2 LangGraph (Python)
- **Модель**: Directed graph с conditional edges, checkpointing
- **Сильное**: Лучшая в индустрии persistence/state, time-travel debug
- **Слабое**: Высокий порог входа, привязка к LangChain экосистеме
- **Для нас**: Концепция checkpointing + graph-based flow
### 2.3 Claude Agent SDK
- **Модель**: Tool-use chain с sub-agents
- **Сильное**: Нативная интеграция с Claude, safety-first
- **Слабое**: Только Claude модели, лёгкий на оркестрацию
- **Для нас**: Lifecycle hooks
### 2.4 Нативные субагенты Claude Code
- **Как работают**: `claude -p "task" --session-id "id"` запускает ОТДЕЛЬНЫЙ процесс
- **КЛЮЧЕВОЕ**: Это РЕАЛЬНАЯ изоляция контекста! Каждый субагент — отдельное контекстное окно
- **Ограничение**: Нет координации "из коробки", нет shared memory, нет PM-слоя
---
## ЧАСТЬ 3: Архитектура Kin (наш проект)
### 3.1 Ключевой принцип
> **Каждый агент = отдельный Claude Code процесс с изолированным контекстом.**
> Compaction в рамках одного агента не убивает нюансы, потому что его контекст маленький и специализированный.
> PM-агент держит мета-уровень, а не весь код.
### 3.2 Живая иерархия с динамической маршрутизацией
Не pipeline (A→B→C→D), а **живая организация**: каждый уровень понимает
свою зону ответственности и собирает нужную команду под задачу.
```
[Ты (Михаил)] ← человеческая речь, свободная форма:
│ "клиент пишет что фильтры глючат на айфоне когда быстро тыкаешь"
│ "нужен агрегатор туров, чтобы парсить предложения"
│ "что у меня горит?"
│ "посмотри что там с NeverDNS, давно не трогали"
▼
[Intake-менеджер] — УМНЫЙ агент (Sonnet), НЕ код на Python.
│ Почему агент, а не код:
│ - Клиент пишет "фильтры глючат на айфоне когда быстро тыкаешь"
│ → код не поймёт нюанс "быстро тыкаешь" = race condition
│ → агент переформулирует для команды
│ - Ты пишешь "посмотри что там с NeverDNS"
│ → это не задача, это запрос на статус + возможно ревью
│ → агент разберётся
│
│ Что делает:
│ 1. Понимает контекст (ты — директор и продажник, клиенты через тебя)
│ 2. Определяет проект, тип задачи, срочность
│ 3. Задаёт уточняющие вопросы если надо
│ 4. Формулирует задачу на языке команды
│ 5. Для простых запросов (статус) — SQL к БД, без агентов
│ 6. Для задач — маршрутизирует к нужному PM проекта
│ 7. Для новых проектов — запускает цепочку research → design → architecture
│
│ Его контекст: список проектов + статусы (из БД, маленький)
│ НЕ знает: код, архитектуру, детали — только "кто чем занимается"
│
├── [PM:vdolipoperek] ── знает проект ГЛУБОКО
│ │ Что знает: модули, tech stack, decisions, грабли, текущий статус
│ │ Что умеет: декомпозировать задачу, выбрать нужных специалистов
│ │ Его контекст: decisions + modules + текущие tasks (из БД)
│ │
│ │ Intake передаёт: "Баг: фильтры поиска не применяются при
│ │ быстром переключении на iOS Safari.
│ │ Источник: жалоба клиента. Приоритет: высокий."
│ │
│ │ PM думает: "фильтры — это модуль search. iOS Safari —
│ │ у нас уже была decision #15 про position:fixed.
│ │ Нужен дебагер на модуль search."
│ │
│ │ ┌─── [Дебагер] ← описание бага + код модуля + decision #15
│ │ │ │ ищет проблему
│ │ │ │ нашёл: "race condition в async фильтре"
│ │ │ ▼
│ │ │ [Тестировщик] ← найденный баг + модуль
│ │ │ │ regression test, подтверждает баг
│ │ │ ▼
│ │ │ [Фронтендер] ← баг + тест + spec модуля
│ │ │ │ фиксит, тест проходит
│ │ │ ▼
│ │ └─── [PM] ← результат. Записывает decision:
│ │ "race condition в SearchFilters — debounce + AbortController"
│ │ → Intake сообщает тебе → ты сообщаешь клиенту
│ │
│ │ Другой пример: "добавить оплату на сайт"
│ │ PM: "новый модуль, нужна полная команда"
│ │
│ │ ┌─── [Маркетолог] ← "платежи на сайте турагентства"
│ │ │ │ исследует: как конкуренты делают checkout,
│ │ │ │ какие conversion-паттерны, trust signals
│ │ │ ▼
│ │ │ [UX-дизайнер] ← research маркетолога + brief
│ │ │ │ проектирует: user flow оплаты, wireframes
│ │ │ ▼
│ │ │ [Архитектор] ← UX flow + brief + все decisions проекта
│ │ │ │ spec: модули, API, БД, интеграция с платёжкой
│ │ │ ▼
│ │ │ [Безопасник] ← spec (PCI DSS для платежей!)
│ │ │ │ security requirements
│ │ │ ▼
│ │ │ [Бэкендер] ← spec + security reqs (параллельно!)
│ │ │ [Фронтендер] ← spec + UX wireframes
│ │ │ ▼
│ │ │ [Ревьюер] + [Тестировщик] + [Безопасник]
│ │ └─── [PM] ← всё готово, decisions обновлены
│ │
├── [PM:sharedbox] ── знает свой проект так же глубоко
│ └── (своя динамическая команда)
│
├── [PM:neverdns] ── знает: готов, в маркетинг-фазе
│ └── (маркетолог, копирайтер, SEO — другая команда!)
│
└── ... (остальные проекты)
[Для НОВЫХ проектов — отдельная цепочка:]
Intake: "нужен агрегатор туров"
│
├── [Бизнес-аналитик] ← хотелки + контекст (турагентство)
│ │ исследует: бизнес-модель, монетизация, целевая аудитория
│ │ может спавнить:
│ │ [Исследователь рынка] ← конкуренты, ниша
│ │ [Исследователь API] ← какие API поставщиков туров есть
│ │ [Исследователь юридики] ← лицензии, договора
│ ▼
├── [UX-дизайнер] ← research + хотелки
│ │ user journey, wireframes ключевых страниц
│ │ смотрит конкурентов, лучшие практики
│ ▼
├── [Маркетолог] ← research + UX
│ │ стратегия продвижения, SEO, механики удержания
│ │ что учесть при разработке для маркетинга
│ ▼
├── [Архитектор] ← research + UX + marketing reqs
│ │ project_blueprint: модули, tech stack, план
│ │ учитывает существующий стек (Vue/Nuxt)
│ ▼
└── Создаётся проект в БД → назначается PM → работа начинается
```
### 3.3 Типы задач и маршруты (PM выбирает динамически)
PM проекта — это не тупой маршрутизатор, это агент, который ПОНИМАЕТ задачу.
Но чтобы понимал хорошо, ему нужны "шаблоны маршрутов" как подсказки:
```yaml
# В промпте PM: "ты знаешь эти типы задач и кого вызывать"
routes:
debug:
description: "Найти и исправить баг"
typical_flow:
- debugger: "найди причину, опиши"
- tester: "напиши regression test, подтверди баг"
- developer: "исправь, тест должен пройти"
pm_decides:
- какой модуль затронут (из знания проекта)
- frontend или backend баг
- нужен ли security review (если баг в auth/payments)
feature:
description: "Новая фича"
typical_flow:
- architect: "спроектируй"
- developer: "реализуй" (может быть несколько параллельно)
- reviewer: "проверь"
- tester: "протестируй"
pm_decides:
- масштаб (один компонент или новый модуль)
- нужен ли architect (мелкая фича → сразу developer)
- параллелить ли frontend/backend
refactor:
description: "Рефакторинг существующего кода"
typical_flow:
- architect: "оцени scope, предложи план"
- developer: "рефактори по плану"
- tester: "прогони существующие тесты"
pm_decides:
- затрагивает ли другие модули
- нужна ли миграция данных
security_audit:
description: "Проверка безопасности"
typical_flow:
- security: "проверь по OWASP"
- developer: "исправь найденное"
- security: "подтверди исправления"
new_project:
description: "Создание нового проекта с нуля"
typical_flow:
- analyst: "исследуй рынок, конкурентов, API"
- architect: "спроектируй на основе исследования"
- pm: "декомпозируй blueprint на задачи"
- # далее — обычные feature/debug задачи
hotfix:
description: "Срочное исправление в продакшене"
typical_flow:
- debugger: "найди причину"
- developer: "минимальный fix"
- tester: "smoke test"
constraints:
- максимум 1 час
- минимум изменений
- deploy сразу
```
### 3.4 Пул специалистов (агенты-рабочие)
Рабочие агенты — НЕ фиксированный набор. Это **пул ролей**, из которых PM
собирает команду под задачу. Каждый — отдельный Claude Code процесс.
```yaml
specialists:
# ═══════════════════════════════════════════════
# ИССЛЕДОВАНИЯ И АНАЛИТИКА
# ═══════════════════════════════════════════════
business_analyst:
prompt: prompts/business_analyst.md
context: "задание + бизнес-контекст проекта"
tools: [WebSearch, WebFetch, Read, Write]
model: opus # стратегические решения
description: >
Бизнес-аналитик. Исследует бизнес-модель, монетизацию, целевую
аудиторию, юридические аспекты. Может спавнить исследователей.
market_researcher:
prompt: prompts/market_researcher.md
context: "тема исследования + рамки"
tools: [WebSearch, WebFetch, Write]
model: sonnet
description: >
Исследователь рынка. Конкуренты, ниша, тренды, ценообразование.
Подчинённый аналитика — копает конкретную тему.
tech_researcher:
prompt: prompts/tech_researcher.md
context: "что исследовать + ограничения"
tools: [WebSearch, WebFetch, Read, Write]
model: sonnet
description: >
Технический исследователь. API поставщиков, библиотеки,
интеграции, бенчмарки. Знает где искать доки, changelog, issues.
# ═══════════════════════════════════════════════
# ДИЗАЙН И UX
# ═══════════════════════════════════════════════
ux_designer:
prompt: prompts/ux_designer.md
context: "brief + research + примеры конкурентов"
tools: [WebSearch, WebFetch, Read, Write]
model: opus # UX-решения критичны для продукта
description: >
UX-дизайнер. User journey, wireframes (текстовые/Mermaid),
information architecture, interaction patterns.
Смотрит на конкурентов, лучшие практики, accessibility.
ui_designer:
prompt: prompts/ui_designer.md
context: "wireframes + style guide проекта"
tools: [Read, Write]
model: sonnet
description: >
UI-дизайнер. Визуальный дизайн, компонентная система,
типографика, цвета, spacing. Описывает на уровне CSS tokens.
# ═══════════════════════════════════════════════
# МАРКЕТИНГ И КОНТЕНТ
# ═══════════════════════════════════════════════
marketer:
prompt: prompts/marketer.md
context: "research + продукт + целевая аудитория"
tools: [WebSearch, WebFetch, Read, Write]
model: sonnet
description: >
Маркетолог. Стратегия продвижения, SEO-требования для разработки,
conversion-паттерны, A/B тест гипотезы, trust signals.
Знает исследования по поведению пользователей.
Даёт требования разработчикам: что учесть в коде для маркетинга.
copywriter:
prompt: prompts/copywriter.md
context: "brief + tone of voice + целевая аудитория"
tools: [Read, Write]
model: sonnet
description: >
Копирайтер. Тексты для UI (кнопки, заголовки, ошибки),
лендинги, описания, meta-теги. Знает русский и английский.
seo_specialist:
prompt: prompts/seo_specialist.md
context: "сайт + ниша + текущие метрики (если есть)"
tools: [WebSearch, WebFetch, Read, Write, Bash]
model: sonnet
description: >
SEO-специалист. Техническое SEO, структура URL, meta-теги,
schema.org разметка, Core Web Vitals, sitemap.
Даёт конкретные требования фронтендеру и бэкендеру.
# ═══════════════════════════════════════════════
# ПРОЕКТИРОВАНИЕ
# ═══════════════════════════════════════════════
architect:
prompt: prompts/architect.md
context: "brief + ВСЕ decisions проекта + tech_stack + research (если есть)"
tools: [Read, Write]
model: opus # критические решения — максимум мозгов
description: >
Системный архитектор. Проектирует архитектуру, модули, API,
схему БД, интеграции. Выдаёт implementation spec.
Не пишет код — пишет спецификации.
db_architect:
prompt: prompts/db_architect.md
context: "spec + текущая схема БД"
tools: [Read, Write]
model: opus
description: >
Архитектор БД. Схема, миграции, индексы, нормализация.
Когда SQLite хватит, когда переходить на PostgreSQL.
# ═══════════════════════════════════════════════
# РАЗРАБОТКА
# ═══════════════════════════════════════════════
frontend_dev:
prompt: prompts/frontend_dev.md
context: "spec модуля + wireframes + relevant decisions (gotchas)"
tools: [Read, Write, Edit, Bash]
model: sonnet
working_dir: "{project_path}"
description: >
Фронтендер. Vue/Nuxt/React, CSS, анимации, responsive.
Работает в директории проекта.
backend_dev:
prompt: prompts/backend_dev.md
context: "spec модуля + API contracts + relevant decisions"
tools: [Read, Write, Edit, Bash]
model: sonnet
working_dir: "{project_path}"
description: >
Бэкендер. Node.js/Python, API, интеграции, бизнес-логика.
fullstack_dev:
prompt: prompts/fullstack_dev.md
context: "spec модуля + relevant decisions"
tools: [Read, Write, Edit, Bash]
model: sonnet
working_dir: "{project_path}"
description: >
Фулстекер. Для мелких задач, где нет смысла делить.
# ═══════════════════════════════════════════════
# КАЧЕСТВО
# ═══════════════════════════════════════════════
debugger:
prompt: prompts/debugger.md
context: "описание бага + код модуля + логи (если есть)"
tools: [Read, Bash, Write] # НЕТ Edit! Дебагер ищет, не чинит.
model: opus # дебаг требует глубокого reasoning
description: >
Дебагер. Ищет причину бага, описывает root cause, НЕ исправляет.
Предлагает решение, но не трогает код.
reviewer:
prompt: prompts/reviewer.md
context: "код + spec + conventions проекта"
tools: [Read] # ТОЛЬКО чтение! Ревьюер не правит.
model: sonnet
description: >
Ревьюер. Code review: соответствие spec, качество, паттерны,
naming, edge cases. Только читает, не правит.
tester:
prompt: prompts/tester.md
context: "код + spec"
tools: [Read, Write, Edit, Bash]
model: sonnet
working_dir: "{project_path}"
description: >
Тестировщик. Unit, integration, e2e тесты. Гоняет, ищет edge cases.
qa_analyst:
prompt: prompts/qa_analyst.md
context: "spec + UX flow + текущие тесты"
tools: [Read, Write]
model: sonnet
description: >
QA-аналитик. Тест-планы, тест-кейсы, acceptance criteria.
Не пишет код тестов — описывает ЧТО тестировать.
# ═══════════════════════════════════════════════
# ИНФРАСТРУКТУРА И БЕЗОПАСНОСТЬ
# ═══════════════════════════════════════════════
sysadmin:
prompt: prompts/sysadmin.md
context: "инфраструктура проекта + текущий стек"
tools: [Read, Write, Edit, Bash]
model: sonnet
description: >
Сисадмин. Docker, nginx, CI/CD, мониторинг, бэкапы.
Знает когда SQLite хватит и когда нужен PostgreSQL.
Настраивает фаерволы, SSL, деплой. Ставит пакеты/модули.
devops:
prompt: prompts/devops.md
context: "инфраструктура + pipeline + tech stack"
tools: [Read, Write, Edit, Bash]
model: sonnet
description: >
DevOps. CI/CD pipeline, автодеплой, blue-green, rollback.
Docker Compose, GitHub Actions / Forgejo CI.
security:
prompt: prompts/security.md
context: "код + security-relevant decisions"
tools: [Read, Bash]
model: opus # безопасность — не экономим
description: >
Безопасник. OWASP, CVE, auth, injection, secrets, dependencies.
Проверяет фаерволы, ставит ограничения. Знает актуальные уязвимости.
# ═══════════════════════════════════════════════
# ЮРИДИЧЕСКАЯ ПОДДЕРЖКА
# ═══════════════════════════════════════════════
legal:
prompt: prompts/legal.md
context: "описание задачи/модуля + юрисдикция + тип бизнеса"
tools: [WebSearch, WebFetch, Read, Write]
model: opus # юридические решения критичны
description: >
Юрист. Анализирует задачу с точки зрения законности:
- Можно ли так делать? (ЗоЗПП, 152-ФЗ, 54-ФЗ, GDPR...)
- Что нужно сделать чтобы было можно? (оферта, согласие, лицензия)
- Какие документы нужны? (политика конфиденциальности, договор)
- Какие риски? (штрафы, блокировки, претензии)
НЕ заменяет настоящего юриста — даёт направление и чеклист.
PM вызывает когда: коммерция, персональные данные, платежи,
пользовательский контент, трансграничные операции.
PM НЕ вызывает когда: внутренний инструмент без юрлица.
legal_researcher:
prompt: prompts/legal_researcher.md
context: "юридический вопрос + юрисдикция"
tools: [WebSearch, WebFetch, Read, Write]
model: sonnet
description: >
Юридический исследователь. Ищет актуальные нормативные акты,
судебную практику, разъяснения регуляторов.
Подчинённый юриста — копает конкретный вопрос.
# ═══════════════════════════════════════════════
# САППОРТ И ОБРАТНАЯ СВЯЗЬ
# ═══════════════════════════════════════════════
support:
prompt: prompts/support.md
context: "описание продукта + FAQ + known issues + decisions (gotchas)"
tools: [Read, Write]
model: sonnet
description: >
Саппорт-агент. Общается с пользователем (через тебя или напрямую).
Задаёт правильные вопросы, собирает анамнез:
- Что именно не работает? На каком устройстве/браузере?
- Воспроизводится ли стабильно? Когда началось?
- Скриншот/видео?
Формирует структурированный тикет для PM.
НЕ обещает сроки, НЕ принимает решения, НЕ выполняет просьбы.
support_guard:
prompt: prompts/support_guard.md
context: "бизнес-правила проекта + security policies"
tools: [Read]
model: sonnet
description: >
Фильтр саппорта (безопасник обратной связи).
Проверяет ВСЕ входящие от клиентов перед тем как они попадут в систему:
- "Дайте мне данные других пользователей" → REJECT + лог
- "Сделайте скидку 90%" → REJECT (не в компетенции системы)
- "Удалите мой аккаунт" → ESCALATE to human (Михаил решает)
- "Кнопка не работает" → PASS to support → PM
Классифицирует: bug / feature_request / question / abuse / escalate
```
### 3.4a Саппорт: от ручного к автоматическому (эволюция)
```
=== ФАЗА 1: Саппорт через тебя (сейчас) ===
[Клиент] → пишет тебе в WhatsApp/Telegram
│
▼
[Ты] → пересказываешь Intake-менеджеру:
│ "клиент пишет что фильтры глючат на айфоне"
▼
[Intake] → формулирует → [PM проекта] → команда работает
│
▼
[PM] → результат → [Intake] → тебе → ты отвечаешь клиенту
=== ФАЗА 2: Саппорт-агент общается с тобой (скоро) ===
[Клиент] → пишет тебе
│
▼
[Ты] → копируешь сообщение клиента в kin:
│ kin support vdol "текст клиента"
▼
[Support] → задаёт тебе уточняющие вопросы:
│ "Спросите клиента: на каком устройстве? В каком браузере?
│ Воспроизводится ли если обновить страницу?"
▼
[Ты] → спрашиваешь клиента → добавляешь ответы
▼
[Support] → формирует тикет → [Support Guard проверяет] → [PM]
│
▼
[PM] → результат → [Support] формулирует ответ клиенту
→ "Мы нашли и исправили проблему с фильтрами.
Обновите страницу — должно работать."
▼
[Ты] → отправляешь клиенту (можешь отредактировать)
=== ФАЗА 3: Telegram-бот для клиентов (перспектива) ===
[Клиент] → пишет в Telegram-бот проекта напрямую
│
▼
[Support Guard] → фильтрует:
│ abuse/manipulation → BLOCK + лог для тебя
│ escalation → NOTIFY тебя
│ нормальный запрос → PASS
▼
[Support Bot] → общается с клиентом:
│ задаёт вопросы, собирает анамнез, показывает FAQ
│ если FAQ решает проблему → закрывает
│ если нет → формирует тикет
▼
[PM] → принимает тикет, запускает команду
▼
[PM] → результат → [Support Bot] → отвечает клиенту
│
│ ВСЕ ответы клиентам проходят через Support Guard:
│ - не раскрывает внутреннюю архитектуру
│ - не обещает невозможное
│ - не подтверждает уязвимости
│ - вежливо, в стиле бренда
▼
[Ты] → получаешь summary: "Клиент X обратился с багом Y,
команда исправила, клиент получил ответ Z"
(можешь вмешаться в любой момент)
=== ФАЗА 4: Проект живёт сам (далёкая перспектива) ===
[Клиенты] → боты → [Support] → [PM] → [Команда] → [Deploy]
│ │
▼ ▼
[Аналитика использования] [Автодеплой фиксов]
│
▼
[Маркетолог] → "конверсия упала на 5% на странице X"
→ [PM] → [UX-дизайнер] → [Фронтендер] → [A/B тест]
[Ты] = стратегическое управление + финальное approve на крупные изменения
```
**Таблицы для саппорта (добавить в БД):**
```sql
-- Тикеты от пользователей
CREATE TABLE support_tickets (
id INTEGER PRIMARY KEY AUTOINCREMENT,
project_id TEXT NOT NULL REFERENCES projects(id),
source TEXT NOT NULL, -- 'manual', 'telegram_bot', 'email'
client_id TEXT, -- идентификатор клиента (telegram id, email...)
client_message TEXT NOT NULL, -- исходное сообщение клиента
classification TEXT, -- 'bug', 'feature_request', 'question', 'abuse', 'escalate'
guard_result TEXT, -- 'pass', 'reject', 'escalate'
guard_reason TEXT, -- почему отклонено/эскалировано
anamnesis JSON, -- собранная информация (устройство, шаги, скриншоты)
task_id TEXT REFERENCES tasks(id), -- связанная задача (если создана)
response TEXT, -- ответ клиенту
response_approved BOOLEAN DEFAULT FALSE, -- ты одобрил ответ?
status TEXT DEFAULT 'new', -- new, collecting_info, in_progress, resolved, rejected
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
resolved_at DATETIME
);
-- Настройки бота для каждого проекта
CREATE TABLE support_bot_config (
project_id TEXT PRIMARY KEY REFERENCES projects(id),
telegram_bot_token TEXT, -- токен Telegram-бота (encrypted)
welcome_message TEXT, -- приветствие
faq JSON, -- часто задаваемые вопросы
auto_reply BOOLEAN DEFAULT FALSE, -- автоматически отвечать клиентам?
require_approval BOOLEAN DEFAULT TRUE, -- требовать одобрение ответов?
brand_voice TEXT, -- стиль общения ("формальный", "дружелюбный")
forbidden_topics JSON, -- что нельзя обсуждать с клиентами
escalation_keywords JSON -- триггеры для эскалации к тебе
);
CREATE INDEX idx_tickets_project ON support_tickets(project_id, status);
CREATE INDEX idx_tickets_client ON support_tickets(client_id);
```
**Итого: ~24 специализации в 9 отделах:**
| Отдел | Роли | PM вызывает когда |
|-------|------|-------------------|
| Исследования | business_analyst, market_researcher, tech_researcher | Новый проект, новый модуль, выбор технологии |
| Дизайн | ux_designer, ui_designer | Новый модуль, редизайн, улучшение UX |
| Маркетинг | marketer, copywriter, seo_specialist | Запуск, лендинги, SEO, контент |
| Проектирование | architect, db_architect | Новый модуль, рефакторинг, масштабирование |
| Разработка | frontend_dev, backend_dev, fullstack_dev | Реализация |
| Качество | debugger, reviewer, tester, qa_analyst | Баги, ревью, тесты |
| Инфраструктура | sysadmin, devops, security | Деплой, CI/CD, безопасность |
| Юридическая | legal, legal_researcher | Коммерция, ПД, платежи, оферты, лицензии |
| Саппорт | support, support_guard | Обратная связь от клиентов |
PM не вызывает всех — он собирает команду под задачу:
- Мелкий баг от клиента: support → PM → debugger → tester → frontend_dev
- Новый модуль с платежами: legal → marketer → ux → architect → security → devs → review
- Новый коммерческий проект: analyst → researchers → legal → ux → marketer → architect
- Внутренний инструмент: architect → fullstack_dev → tester (без юриста и маркетолога)
**Разделение прав (КРИТИЧНО):**
- Исследователи/аналитики: WebSearch + Read + Write (документы). Не трогают код.
- Дизайнеры: Read + Write (спеки, wireframes). Не трогают код.
- Маркетологи: WebSearch + Read + Write. Не трогают код — дают требования.
- Архитектор: Read + Write (спеки). Не пишет код.
- Дебагер: Read + Bash. Ищет, НЕ правит.
- Ревьюер: ТОЛЬКО Read. Не трогает.
- Разработчики: полный доступ, но только к своему модулю.
- Сисадмин/DevOps: полный доступ к инфраструктуре.
- Безопасник: Read + Bash. Не правит — выдаёт требования.
- Саппорт: Read + Write (тикеты). Не трогает код, не принимает решений.
- Support Guard: ТОЛЬКО Read. Фильтр — пропускает/блокирует/эскалирует.
### 3.5 Протокол обмена между агентами
Агенты общаются ТОЛЬКО через структурированные артефакты в БД.
Никакого shared context. Каждый артефакт — JSON файл + запись в tasks.
**Универсальный формат передачи:**
```json
{
"task_id": "VDOL-042",
"from_role": "pm",
"to_role": "debugger",
"type": "debug_request",
"payload": {
"bug_description": "Фильтры поиска не применяются при быстром переключении",
"module": "search",
"affected_files": [
"src/components/search/SearchFilters.vue",
"src/composables/useSearch.ts",
"src/api/search.ts"
],
"known_context": [
"Фильтры используют async API вызовы",
"Раньше был похожий баг с debounce (decision #15)"
],
"reproduction_steps": "Быстро кликнуть 3 разных фильтра подряд"
}
}
```
**PM формирует payload, подтягивая из decisions:**
```python
# context_builder собирает для дебагера
context = {
"task": db.get_task("VDOL-042"),
"module_files": git.list_files("src/components/search/"),
"relevant_decisions": db.get_decisions(
project_id="vdol",
category="search",
types=["gotcha", "workaround"]
),
"recent_bugs": db.get_tasks(
project_id="vdol",
module="search",
status="done",
type="debug",
limit=5
)
}
```
### 3.6 Коммуникация между рабочими агентами
Рабочие агенты могут "общаться", но не напрямую — через PM как посредника,
или через артефакты в файловой системе:
```
[Дебагер] → пишет debug_report.json → [PM читает]
PM решает: "нужен фронтендер для фикса"
[PM] → формирует fix_request.json (debug_report + spec) → [Фронтендер]
[Фронтендер] → правит код → [Тестировщик] запускает тесты
[Тестировщик] → test_result.json → [PM]
PM решает: "тесты прошли, закрываю задачу" или "фейл, обратно фронтендеру"
```
**НО: для скорости можно разрешить прямую цепочку без PM:**
```
# PM заранее описывает pipeline
kin run VDOL-042 --pipeline "debugger → tester → frontend_dev → tester"
# Каждый агент передаёт результат следующему через файл
# PM получает только финальный результат + все промежуточные в логах
```
### 3.7 Механизм запуска (как это работает технически)
```bash
# Сценарий 1: ты пишешь в Telegram
"продебажь фильтры в vdolipoperek"
# Диспетчер (Python):
# 1. Парсит: проект=vdol, тип=debug, что=фильтры
# 2. Запускает PM проекта:
claude -p "$(cat prompts/pm.md)
ПРОЕКТ: vdolipoperek
TECH STACK: Vue 3, TypeScript, Nuxt
ТЕКУЩИЕ DECISIONS:
$(kin decisions vdol --category search --format brief)
ЗАДАЧА: продебажь фильтры — не применяются при быстром переключении
ДОСТУПНЫЕ СПЕЦИАЛИСТЫ: debugger, frontend_dev, backend_dev, tester, reviewer, security
ШАБЛОНЫ МАРШРУТОВ: $(cat routes.yaml)
Декомпозируй задачу и верни JSON с pipeline." \
--session-id "pm-vdol-$(date +%s)" \
--output-format json
# PM возвращает:
{
"task_id": "VDOL-043",
"pipeline": [
{"role": "debugger", "module": "search", "brief": "..."},
{"role": "tester", "depends_on": "debugger", "brief": "regression test"},
{"role": "frontend_dev", "depends_on": "tester", "brief": "fix"},
{"role": "tester", "depends_on": "frontend_dev", "brief": "verify fix"}
],
"decisions_to_load": [15, 23] # PM знает какие decisions релевантны
}
# Runner исполняет pipeline:
for step in pipeline:
context = context_builder.build(step.role, step.module, step.decisions)
result = claude_run(step.role, context, project_path)
save_result(step, result)
if not result.success:
escalate_to_pm(step, result) # PM решает что делать
```
```bash
# Сценарий 2: новый проект
"нужен агрегатор туров, чтобы парсить предложения и показывать клиентам"
# Диспетчер определяет: тип=new_project
# Запускает Аналитика (БЕЗ PM, потому что проекта ещё нет):
claude -p "$(cat prompts/analyst.md)
Исследуй тему: агрегатор туров для турагентства.
Контекст: существующий сайт vdolipoperek.com (Vue/Nuxt).
Нужно: конкуренты, доступные API поставщиков туров, ценообразование,
технические ограничения. Верни market_research.json" \
--session-id "analyst-new-$(date +%s)" \
--tools WebSearch,WebFetch,Write
# Аналитик может спавнить исследователей:
# - "исследователь API" — ищет API TUI, Pegas, Anex...
# - "исследователь конкурентов" — анализирует level.travel, onlinetours...
# После: Архитектор получает research + хотелки:
claude -p "$(cat prompts/architect.md)
ИССЛЕДОВАНИЕ: $(cat market_research.json)
ХОТЕЛКИ: агрегатор туров, парсинг предложений, отображение клиентам
СУЩЕСТВУЮЩИЙ СТЕК: Vue 3, Nuxt, Node.js
Спроектируй project_blueprint.json" \
--session-id "arch-new-$(date +%s)"
# Blueprint → создаётся проект в БД → назначается PM → работа начинается
```
### 3.5 State Management
**SQLite база — мультипроектная с рождения:**
```sql
-- Проекты (центральный реестр)
CREATE TABLE projects (
id TEXT PRIMARY KEY, -- 'vdol', 'sharedbox', 'neverdns', 'barsik', 'askai'
name TEXT NOT NULL, -- 'В долю поперёк', 'SharedBox', 'NeverDNS'
path TEXT NOT NULL, -- ~/projects/mailbox, ~/projects/vdolipoperek
tech_stack JSON, -- ["vue3", "typescript", "nuxt"]
status TEXT DEFAULT 'active', -- active, paused, maintenance, ready
priority INTEGER DEFAULT 5, -- 1=критический, 10=когда-нибудь
pm_prompt TEXT, -- путь к кастомному промпту PM для этого проекта
claude_md_path TEXT, -- путь к CLAUDE.md проекта
forgejo_repo TEXT, -- owner/repo для синхронизации issues
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- Задачи (привязаны к проекту)
CREATE TABLE tasks (
id TEXT PRIMARY KEY, -- VDOL-042, SB-015, NDNS-003
project_id TEXT NOT NULL REFERENCES projects(id),
title TEXT NOT NULL,
status TEXT DEFAULT 'pending', -- pending, decomposed, in_progress, review, done, blocked
priority INTEGER DEFAULT 5,
assigned_role TEXT, -- architect, developer, reviewer, tester, security
parent_task_id TEXT REFERENCES tasks(id), -- для подзадач
brief JSON, -- Task Brief от PM
spec JSON, -- Implementation Spec от архитектора
review JSON, -- Review Result
test_result JSON, -- Test Result
security_result JSON, -- Security Check Result
forgejo_issue_id INTEGER, -- связка с Forgejo issue
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- Решения и грабли (КЛЮЧЕВАЯ ТАБЛИЦА — то что теряется при compaction)
-- Это ВНЕШНЯЯ ПАМЯТЬ PM-агента для каждого проекта
CREATE TABLE decisions (
id INTEGER PRIMARY KEY AUTOINCREMENT,
project_id TEXT NOT NULL REFERENCES projects(id),
task_id TEXT REFERENCES tasks(id), -- может быть NULL для общепроектных решений
type TEXT NOT NULL, -- 'decision', 'gotcha', 'workaround', 'rejected_approach', 'convention'
category TEXT, -- 'architecture', 'ui', 'api', 'security', 'devops', 'performance'
title TEXT NOT NULL,
description TEXT NOT NULL,
tags JSON, -- ["ios-safari", "css", "bottom-sheet"] для поиска
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- Логи агентов (для дебага, обучения и cost tracking)
CREATE TABLE agent_logs (
id INTEGER PRIMARY KEY AUTOINCREMENT,
project_id TEXT NOT NULL REFERENCES projects(id),
task_id TEXT REFERENCES tasks(id),
agent_role TEXT NOT NULL, -- pm, analyst, architect, debugger, frontend_dev, etc.
session_id TEXT, -- claude --session-id
action TEXT NOT NULL, -- 'decompose', 'implement', 'review', 'test', 'fix', 'research'
input_summary TEXT, -- что получил (краткое описание, не полный текст)
output_summary TEXT, -- что выдал
tokens_used INTEGER,
model TEXT, -- haiku, sonnet, opus
cost_usd REAL, -- стоимость вызова
success BOOLEAN,
error_message TEXT,
duration_seconds INTEGER,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- Модули проекта (PM знает структуру)
-- Это "карта" проекта для PM: он знает какие модули есть и кого вызвать
CREATE TABLE modules (
id INTEGER PRIMARY KEY AUTOINCREMENT,
project_id TEXT NOT NULL REFERENCES projects(id),
name TEXT NOT NULL, -- 'search', 'auth', 'payments', 'ui-kit'
type TEXT NOT NULL, -- 'frontend', 'backend', 'shared', 'infra'
path TEXT NOT NULL, -- 'src/components/search/', 'src/api/search.ts'
description TEXT, -- 'Поиск и фильтрация туров'
owner_role TEXT, -- 'frontend_dev', 'backend_dev' — кого вызывать
dependencies JSON, -- ["auth", "api-client"] — зависимости между модулями
UNIQUE(project_id, name)
);
-- Pipelines (история запусков — для обучения и повторного использования)
CREATE TABLE pipelines (
id INTEGER PRIMARY KEY AUTOINCREMENT,
task_id TEXT NOT NULL REFERENCES tasks(id),
project_id TEXT NOT NULL REFERENCES projects(id),
route_type TEXT NOT NULL, -- 'debug', 'feature', 'refactor', 'hotfix', 'new_project'
steps JSON NOT NULL, -- pipeline JSON от PM
status TEXT DEFAULT 'running', -- running, completed, failed, cancelled
total_cost_usd REAL,
total_tokens INTEGER,
total_duration_seconds INTEGER,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
completed_at DATETIME
);
-- Кросс-проектные зависимости и связи
CREATE TABLE project_links (
id INTEGER PRIMARY KEY AUTOINCREMENT,
from_project TEXT NOT NULL REFERENCES projects(id),
to_project TEXT NOT NULL REFERENCES projects(id),
type TEXT NOT NULL, -- 'depends_on', 'shares_component', 'blocks'
description TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
-- Индексы для быстрого доступа PM-агентов
CREATE INDEX idx_tasks_project_status ON tasks(project_id, status);
CREATE INDEX idx_decisions_project ON decisions(project_id);
CREATE INDEX idx_decisions_tags ON decisions(tags); -- для JSON-поиска по тегам
CREATE INDEX idx_agent_logs_project ON agent_logs(project_id, created_at);
CREATE INDEX idx_agent_logs_cost ON agent_logs(project_id, cost_usd);
```
### 3.6 Контекст-билдер (КЛЮЧЕВОЙ КОМПОНЕНТ)
Перед запуском любого агента, система собирает контекст из БД:
```
kin run VDOL-042
│
▼
[context-builder]
│
├── Читает task VDOL-042 из tasks table → brief, spec
├── Читает decisions WHERE project_id='vdol' → релевантные грабли
│ (фильтрует по category и tags, не грузит ВСЕ решения)
├── Читает projects WHERE id='vdol' → tech_stack, claude_md_path
├── Формирует МИНИМАЛЬНЫЙ контекст для конкретной роли:
│
│ Для архитектора: brief + ALL decisions (он должен знать историю)
│ Для программиста: spec + decisions WHERE category IN ('gotcha','workaround')
│ Для ревьюера: spec + код + decisions WHERE type='convention'
│ Для тестировщика: spec + код (минимум)
│ Для безопасника: код + security conventions
│
└── Запускает claude -p с собранным контекстом
```
**Это решает проблему "раздувшихся CLAUDE.md":** контекст собирается динамически и фильтруется по роли.
### 3.7 Meta-PM: обзор всех проектов
Meta-PM — самый "тупой" но самый полезный агент. Он работает с VIEW-запросами к БД:
```sql
-- "Что горит?" — для Meta-PM
SELECT p.name, p.priority, p.status,
COUNT(CASE WHEN t.status = 'blocked' THEN 1 END) as blocked_tasks,
COUNT(CASE WHEN t.status = 'in_progress' THEN 1 END) as active_tasks,
COUNT(CASE WHEN t.status = 'pending' THEN 1 END) as pending_tasks,
MAX(t.updated_at) as last_activity
FROM projects p
LEFT JOIN tasks t ON t.project_id = p.id
WHERE p.status = 'active'
GROUP BY p.id
ORDER BY p.priority ASC, blocked_tasks DESC;
-- "Сколько трачу?" — cost tracking
SELECT p.name,
SUM(al.cost_usd) as total_cost,
SUM(al.tokens_used) as total_tokens,
COUNT(*) as agent_calls
FROM agent_logs al
JOIN projects p ON p.id = al.project_id
WHERE al.created_at > datetime('now', '-7 days')
GROUP BY p.id
ORDER BY total_cost DESC;
```
### 3.8 Компоненты
```
kin/
├── core/
│ ├── db.py -- SQLite init, migrations
│ ├── models.py -- Projects, Tasks, Decisions, Modules, Pipelines
│ ├── context_builder.py -- формирование контекста ПО РОЛИ из БД
│ └── api.py -- REST API для GUI (FastAPI, читает ту же SQLite)
│
├── agents/
│ ├── prompts/ -- ~24 промпта (pm.md, architect.md, debugger.md...)
│ ├── routes.yaml -- шаблоны маршрутов (debug, feature, refactor...)
│ ├── specialists.yaml -- пул ролей с tools, model, context rules
│ └── runner.py -- запуск claude -p, pipeline executor
│
├── cli/
│ └── main.py
│ # kin status — все проекты одним взглядом
│ # kin run VDOL-043 — PM декомпозирует + pipeline
│ # kin run VDOL-043 --dry-run — показать pipeline без запуска
│ # kin ask "что горит?" — Intake отвечает
│ # kin support vdol "текст" — тикет от клиента
│ # kin cost --last 7d — расходы
│ # kin new-project "агрегатор" — analyst → architect → PM
│
├── web/ -- GUI (Vue 3 + TypeScript — твой стек!)
│ ├── src/
│ │ ├── views/
│ │ │ ├── Dashboard.vue -- обзор всех проектов
│ │ │ ├── ProjectView.vue -- один проект: задачи, модули, decisions
│ │ │ ├── PipelineView.vue -- pipeline задачи: кто работает, где блокер
│ │ │ ├── CostView.vue -- расходы по проектам и задачам
│ │ │ └── SupportView.vue -- тикеты от клиентов
│ │ ├── components/
│ │ │ ├── ProjectCard.vue -- карточка проекта со статусом
│ │ │ ├── PipelineGraph.vue -- визуализация pipeline (граф агентов)
│ │ │ ├── AgentStatus.vue -- статус агента (idle/working/done/error)
│ │ │ ├── DecisionsList.vue -- decisions проекта с поиском по тегам
│ │ │ └── LiveLog.vue -- real-time лог текущего pipeline
│ │ └── App.vue
│ └── package.json
│
├── integrations/
│ ├── telegram_bot.py -- бот-интерфейс (для тебя + клиентские боты)
│ └── forgejo_sync.py -- двусторонняя синхронизация issues ↔ tasks
│
├── config/
│ └── projects.yaml -- начальная конфигурация проектов
│
└── kin.db -- SQLite база (единственный source of truth)
```
### 3.9 GUI: что нужно видеть
**Dashboard (главный экран):**
```
┌─────────────────────────────────────────────────────────────┐
│ Kin Dashboard Cost: $47/week │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🔴 vdolipoperek 3 active 1 blocked $12/week │
│ └─ VDOL-043: debug фильтров [████░░] debugger → tester │
│ └─ VDOL-044: mobile bottom-sheet [██████] done ✓ │
│ └─ VDOL-045: оплата [░░░░░░] blocked: ждёт юриста │
│ │
│ 🟡 sharedbox 1 active $8/week │
│ └─ SB-016: multi-tenant isolation [██░░░░] architect │
│ │
│ 🟢 neverdns 0 active $0/week │
│ └─ маркетинг-фаза, ждёт контент │
│ │
│ 🟢 barsik 1 active $5/week │
│ └─ BARS-007: RAG pipeline [████░░] backend_dev │
│ │
│ ⚪ askai 0 active $0/week │
│ ⚪ ddfo 0 active $0/week │
│ ⚪ stopleak 0 active $0/week │
│ │
│ ─── Support ─── │
│ 2 новых тикета (vdolipoperek) │
│ 1 ожидает твоего approve │
│ │
└─────────────────────────────────────────────────────────────┘
```
**Pipeline View (конкретная задача):**
```
┌─────────────────────────────────────────────────────────────┐
│ VDOL-043: Debug фильтров поиска Status: in_progress│
│ Priority: high Cost: $1.82 Duration: 12 min │
├─────────────────────────────────────────────────────────────┤
│ │
│ [PM] ──────► [Debugger] ──────► [Tester] ──────► [Frontend]│
│ ✓ 0.3s ✓ $0.45 ● working ○ pending│
│ decomposed found: writing │
│ pipeline race condition regression │
│ in useSearch.ts test │
│ │
│ Decisions добавлены: │
│ #47: "race condition в async фильтре — AbortController" │
│ │
│ ─── Live Log ─── │
│ 12:04:32 [tester] Запущен: session tst-VDOL043-1710... │
│ 12:04:33 [tester] Читает: src/composables/useSearch.ts │
│ 12:04:45 [tester] Пишет: tests/search.filter.spec.ts │
│ 12:05:01 [tester] Bash: npm run test -- search.filter │
│ │
└─────────────────────────────────────────────────────────────┘
```
**Почему Vue 3:** это твой стек, ты на нём строишь vdolipoperek.
GUI Kin — это тоже проект, который Kin может помогать разрабатывать.
Meta-moment: Kin строит свой собственный GUI.
**Архитектура GUI:**
```
[kin.db] ← SQLite (source of truth)
│
├── [core/api.py] ← FastAPI, REST endpoints
│ GET /projects — список проектов со статусами
│ GET /projects/{id} — детали проекта + задачи + modules
│ GET /tasks/{id} — задача + pipeline + agent logs
│ GET /tasks/{id}/live — SSE stream для live log
│ GET /pipelines/{id} — граф pipeline с статусами
│ GET /decisions?project=X — decisions с фильтрами
│ GET /support/tickets — тикеты от клиентов
│ GET /cost?period=7d — расходы
│ POST /tasks — создать задачу
│ POST /tasks/{id}/run — запустить pipeline
│ POST /support/approve/{id} — одобрить ответ клиенту
│
└── [web/] ← Vue 3 + TypeScript, Vite
Подключается к API
SSE для live обновлений pipeline
Responsive (работает с MacBook и с телефона)
```
**Ключевое:** GUI читает ту же SQLite что и CLI/runner.
Нет отдельной базы для GUI, нет sync проблем.
runner.py пишет в kin.db → API читает → Vue показывает.
Real-time через SSE (Server-Sent Events) — runner пишет лог → API стримит → Vue обновляет.
### 3.10 Интеграция с существующей инфраструктурой
- **Forgejo**: Двусторонний sync — issue создано в Forgejo → task в kin, task завершён → issue закрыт. Forgejo остаётся UI для ручного просмотра.
- **Obsidian**: Decisions из БД экспортируются как .md в vault. Kanban-доска читает задачи. Направление: kin → Obsidian (read-only зеркало).
- **Telegram бот**: Основной мобильный интерфейс. Свободная форма: "продебажь фильтры в vdolipoperek" → dispatcher парсит → PM → pipeline.
- **Mac Mini M4 Pro**: Основной хост. Агенты запускаются как процессы на нём.
- **MacBook**: Через SSH + Telegram бот. Или Syncthing синхронизирует kin.db (receive-only на MacBook).
- **CLAUDE.md per project**: Минимальный (30 строк), содержит ТОЛЬКО: "tech stack", "coding conventions", "ссылка на kin для контекста". Decisions НЕ дублируются.
### 3.10 Ключевые отличия от Ruflo
| Аспект | Ruflo | Kin |
|--------|-------|---------|
| Мультипроектность | Нет | Intake + Project PMs |
| Полнота команды | Только dev | ~22 роли: research, design, marketing, dev, QA, ops, support |
| Маршрутизация | Фиксированная | PM динамически собирает команду |
| Изоляция | Один промпт | Каждый агент = отдельный процесс |
| Обратная связь | Нет | Support → Guard → PM → команда → ответ клиенту |
| Клиентские боты | Нет | Telegram per project (перспектива) |
---
## ЧАСТЬ 4: План действий
### Фаза 1: Фундамент + один проект (2-3 дня)
- [ ] SQLite схема (все таблицы включая support)
- [ ] context-builder, runner.py, pipeline executor
- [ ] Intake-агент, PM, routes.yaml, specialists.yaml
- [ ] Базовые промпты: architect, frontend_dev, debugger, tester, reviewer
- [ ] CLI + тест на vdolipoperek.com
### Фаза 2: Полная команда ~22 роли (2-3 дня)
- [ ] Все промпты, разделение прав
- [ ] Тест полной цепочки marketer → ux → architect → dev → review
### Фаза 3: Все 10 проектов (1-2 дня)
### Фаза 4: Telegram интеграция (1-2 дня)
### Фаза 5: Саппорт + Support Guard (1-2 дня)
### Фаза 6: Forgejo + Obsidian sync (1 день)
### Фаза 7: Боевой прогон на vdolipoperek (1-2 недели)
### Фаза 8: Клиентские Telegram-боты (перспектива)
### Фаза 9: Самоподдерживающиеся проекты (далёкая перспектива)
---
## Заметки
**Архитектура:** Изоляция контекста через процессы. Decisions = внешняя память PM. PM тупой/памятливый, workers умные/забывчивые. context-builder фильтрует по роли. ~22 роли = полная софтверная компания.
**Бизнес:** Полнота > скорость. Продукт = коммерческий, не поделка. Саппорт замыкает цикл. Support Guard критичен. В перспективе проекты живут сами.
**Техника:** Python, SQLite (source of truth), cost tracking встроен, Forgejo sync, Obsidian read-only.
**Из Ruflo взять:** MCP, SQLite memory, model routing, ADR, hooks. **НЕ брать:** fake parallelism, over-engineering.
Reference in a new issue View git blame Copy permalink