Compare commits

..

13 Commits

Author SHA1 Message Date
c2369db808 tester(ET): auto-commit from tester run_id=539
All checks were successful
CI / test (push) Successful in 45s
CI / test (pull_request) Successful in 43s
2026-06-10 01:26:24 +03:00
4fbc8d99e3 reviewer(ET): auto-commit from reviewer run_id=538 2026-06-10 01:26:24 +03:00
78b6cdb3f1 docs(changelog): repair duplicated ORCH-095 entry body
Reviewer P1 (ORCH-027 attempt 2): inserting the ORCH-027 changelog
block duplicated the adjacent ORCH-095 entry — its paragraph body was
repeated verbatim, corrupting a golden-source doc and another work
item's artifact (CLAUDE.md §3). Remove the duplicate half, leaving a
single ORCH-095 body. ORCH-027 entry untouched (already correct).

Refs: ORCH-027

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-10 01:26:24 +03:00
feb8bc188b reviewer(ET): auto-commit from reviewer run_id=536 2026-06-10 01:26:24 +03:00
9647fe1ffb fix(coverage): use sys.executable for the pytest --cov subprocess (ORCH-027)
measure_coverage hardcoded "python" for the coverage subprocess; the prod container
and the CI runner expose "python3" (a bare "python" may be absent), and pytest-cov
lives in exactly the running interpreter's environment. Use sys.executable so the
measurement always runs under the same interpreter as the orchestrator.

Refs: ORCH-027
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-10 01:26:24 +03:00
eadfd8419b feat(coverage): deterministic test-coverage gate on deploy-staging->deploy edge (ORCH-027)
Introduce a deterministic (no-LLM) coverage sub-gate that blocks coverage
degradation before a task branch merges into `main`. Existing gates judge only by
the FACT of passing (check_ci_green / check_tests_passed / merge-gate re-test), not
by completeness — so a batch autonomous run (ORCH-088) silently erodes coverage.

Pattern mirrors the security-gate (ORCH-022): leaf src/coverage_gate.py (never-raise)
+ thin check_coverage_gate in QG_CHECKS + _handle_coverage_gate splice in advance_stage,
run AFTER merge-gate (measured on the caught-up HEAD that lands in main) and BEFORE
image-freshness (fail before the expensive docker rebuild).

- measure_coverage: pytest --cov=src --cov-report=json in the per-branch worktree ->
  line coverage %; None on tool error -> fail-open + WARNING by default (FR-6).
- compute_coverage_verdict (pure): absolute | baseline | both + epsilon (NFR-4 anti-flap);
  baseline None -> bootstrap (absolute-only).
- coverage_baseline DB table (additive, CREATE TABLE IF NOT EXISTS) + ratchet-up in
  _handle_merge_verify (deploy->done): atomic compare-and-set under merge-lease, never
  decreases; bootstrap on first merge.
- Artefact 18-coverage-report.md (coverage_status: frontmatter, single source of truth);
  GET /queue `coverage` block; FAIL -> Telegram; optional POST /coverage/baseline override.
- Flags ORCH_COVERAGE_* (kill-switch + self-hosting-only scope) -> enduro untouched;
  STAGE_TRANSITIONS / existing check_* / verdict keys byte-for-byte unchanged (NFR-5/AC-8).
- pytest-cov==5.0.0 added to requirements.txt.

Tests: tests/test_coverage_gate.py (TC-01..TC-15). Frozen QG-registry anti-regress
tests + deploy-staging edge tests updated for the new sub-gate. Full suite green.

Docs: README / adr-0029 / PIPELINE_DOCS / 18-coverage-report.md template (architecture
stage) + CHANGELOG / CLAUDE.md / .env.example (this PR).

Refs: ORCH-027
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-10 01:26:24 +03:00
1f9c128a48 architect(ET): auto-commit from architect run_id=534 2026-06-10 01:26:24 +03:00
e9e8b1e246 architect(ET): auto-commit from architect run_id=533 2026-06-10 01:26:24 +03:00
9953275eed analyst(ET): auto-commit from analyst run_id=532 2026-06-10 01:26:24 +03:00
a37de1d890 docs: init ORCH-027 business request 2026-06-10 01:26:24 +03:00
9e10bea500 Merge pull request 'docs(ORCH-027): staging gate log — SUCCESS' (#110) from docs/ORCH-027-staging-log into main 2026-06-10 01:25:57 +03:00
2f72390dba docs(ORCH-027): staging gate log — SUCCESS (8/10, C9a/C9b infra-waived)
All checks were successful
CI / test (pull_request) Successful in 43s
2026-06-10 01:25:47 +03:00
9c522e9f76 docs(epic): концепция автономного саморазвития платформы (домены/вертикали/архрамки наблюдаемости) 2026-06-10 00:54:54 +03:00

View File

@@ -0,0 +1,287 @@
# 🧬 ЭПИК: Автономное саморазвитие платформы оркестратора
> **Статус:** концепция v2 (структура согласована Славой 09.06 → ждёт финального апрува → декомпозиция)
> **Автор:** Стрим · **Дата:** 2026-06-09 · **Заказчик:** Слава
> **Связанные:** ORCH-8 (петля самообучения), ORCH-83 (наблюдаемость), ORCH-54 (автономное внедрение, done)
> **Источники:** память орка (инциденты 0609.06), инвентаризация 94 задач Plane, мировые практики (STRATUS NeurIPS'25, ChaosEater ASE'25, self-healing LLM-agents arXiv'26, agentic AIOps, FinOps token-economics).
---
## 0. Зачем это (vision)
Оркестратор уже **автономно внедряет** (ORCH-54: задача проходит analysis→prod без человека). Но автономность исполнения ≠ автономное **развитие**. Сегодня платформу развивает связка Слава+Стрим вручную: ловим инциденты → формулируем уроки → заводим задачи → апрувим.
**Цель эпика:** управляемый самоподдерживающийся контур, где платформа сама замечает свои слабые места И возможности роста, предлагает улучшения как готовые задачи, проводит их через собственный конвейер (ORCH-7 self-hosting) — **под контролем человека на ключевых развилках** (safety > автономность).
**Принцип баланса (коррекция Славы 09.06):** саморазвитие — это НЕ только «не падать и не косячить». Стабильная платформа, которая не растёт в возможностях, — тупик. **Рост функционала (новые фичи, стеки, удобства для заказчиков) — равноценный домен, а не следствие надёжности.** Платформа развивается по двум рукам одновременно: крепнет (надёжность/качество/экономика) И раздаётся вширь (возможности/масштаб).
---
## 1. Архитектура эпика: фундамент + 5 доменов + 2 вертикали
```
┌─────────────────────────────────────────────────────────────┐
│ ВЕРТИКАЛЬ-ДВИГАТЕЛЬ 🧠 ВЕРТИКАЛЬ-ТОРМОЗ 🛑 │
│ 🔄 уроки (крепнем) + governance / safety L0-L3 │
│ 💡 генератор идей (растём) (ограничивает, апрувы) │
│ ░░░░░░░░░░░░ проходят СКВОЗЬ все домены ░░░░░░░░░░░░░░░░░░░░░ │
├─────────────────────────────────────────────────────────────┤
│ ДОМЕНЫ РАЗВИТИЯ (равноценные, две руки роста) │
│ │
│ КРЕПНЕТ ───────────────────► РАЗДАЁТСЯ ВШИРЬ ────────► │
│ 🛡️ D1 Надёжность 🚀 D4 Возможности (фичи) │
│ ✅ D2 Качество/Доверие 📈 D5 Масштаб │
│ 💰 D3 Экономика │
├─────────────────────────────────────────────────────────────┤
│ ФУНДАМЕНТ (слой 0): 👁️ Наблюдаемость + 📒 Журнал уроков │
│ глаза и память — без них всё слепо │
└─────────────────────────────────────────────────────────────┘
Общая метрика-объединитель: 🌡️ ГРАДУСНИК АВТОНОМНОСТИ
(каждый домен двигает её вверх контролируемо)
```
### Что изменилось против v1 (мои же правки по критике)
- **Наблюдаемость вынесена в фундамент** (была внутри M1) — она питает ВСЁ.
- **M0 разбит на 2 вертикали:** двигатель (петля) и тормоз (governance) — у них противоположная логика, нельзя в одну коробку.
- **Добавлен домен D2 Качество/Доверие** — была дыра: надёжная платформа может стабильно генерить говнокод. Надёжность инфры ≠ корректность результата.
- **Рост (D4+D5) — равноценные домены, не «второй эшелон»** (коррекция Славы).
- **Градусник автономности** — сквозная измеримая цель вместо абстракции.
---
## 🏗️ АРХИТЕКТУРНЫЕ РАМКИ наблюдаемости (решено Славой 09.06 — constraints для архитектора)
> Это НЕЗЫБЛЕМЫЕ границы (заказчик). Конкретные ADR (стек, формат метрик, точки врезки) — зона архитектора внутри этих рамок.
**Принцип:** наблюдатель ОТДЕЛЁН от наблюдаемого. Мониторинг НЕ живёт внутри орка — иначе орк упал/завис/съел память → мониторинг ляжет вместе с ним, и мы слепы в самый критичный момент.
**Решения Славы:**
- **С-1. Sidecar-контейнер на том же хосте** (вариант A). Отдельный процесс/память/рестарт — орк падает, наблюдатель жив и РЕПОРТИТ это.
- **С-1б. КОД sidecar — В РЕПО орка** (отдельная папка `watchdog/`), рантайм — ОТДЕЛЬНЫЙ контейнер. Изоляция — на уровне КОНТЕЙНЕРА, не репозитория. Плюсы: (1) конвейер орка пилит свой мониторинг сам (self-hosting ORCH-7); (2) контракт `/metrics`↔sidecar в одном репо — не разъедется (один PR/тесты); (3) один CI. Сборка: ОТДЕЛЬНЫЙ `watchdog/Dockerfile` + сервис `orchestrator-watchdog` в docker-compose.yml. Разовое инфра-действие: добавить сервис в compose + первый запуск (Слава/Стрим на хосте), дальше код watchdog катится через конвейер.
- **С-2. Без внешнего плеча (L2).** Не усложняем второй площадкой. (Принятый риск: падёнвесь хост/Docker → наблюдатель тоже молчит; осознанно.)
- **С-3. Тонкий стек.** НЕ Grafana+Prometheus (+5-6 контейнеров на забитый хост). Тонкий Python/Go sidecar. **Факт хоста 09.06: RAM 171Mi free / 7.7Gi, диск 92%** — ресурсы впритык, наблюдатель обязан быть лёгким.
**Разделение ответственности:**
- **Орк отдаёт только сырьё:** лёгкий read-only `/metrics` (свои внутренние данные — стадии/очередь/agent-liveness/cost, что знает только он). БЕЗ логики мониторинга/алертов/хранения. Орк лёг → endpoint недоступен = САМ сигнал тревоги.
- **Sidecar — мозг мониторинга:** читает `/metrics` орка + хост (диск/память/CPU) + контейнеры (docker.sock read-only) + пинг Plane/Gitea/Anthropic; хранит пороги, шлёт Telegram-алерты СО СВОИМ каналом (не зависит от кода орка).
- **Журнал уроков (F2)** — исключение: это НЕ realtime-мониторинг, а историческая память петли → допустимо в БД орка (аддитивная таблица). Не критично к падению орка в момент (запись best-effort).
---
## 2. ФУНДАМЕНТ (слой 0) — 👁️ Глаза и 📒 Память
Без данных нечем ни чинить, ни считать, ни приоритизировать, ни учиться. Строится первым.
- **F1 Наблюдаемость** (ORCH-83 [ЭПИК]): метрики agent-liveness + очередь + стадии + хост (диск/память/CPU) + контейнеры + внешние деп (Plane/Gitea/Anthropic). Эндпоинты /health /status /queue → расширить до /metrics + дашборд.
- **F2 Журнал уроков** (ORCH-8 шаг 1): машинная структурированная таблица отклонений (тип, контекст, корень, предложение, статус) — формализовать то, что сейчас в memory/. Это «топливо» для вертикали-двигателя.
---
## 3. ДОМЕН D1 — 🛡️ Надёжность (Self-Repairing)
**Есть:** reconciler (53), post-deploy monitor+rollback (21), merge-verify (71/73), reaper (65), disk-watchdog (63), build-prune (62).
**Уроки:** фантом-merge, deploy-петли, транзиенты, флапп-статусы, зомби-jobs.
- **D1.1** Предиктивный мониторинг (causal, не порог): «диск заполнится через N ч».
- **D1.2** Авто-ремедиация рантайма: каталог типовых фиксов (зомби-job→requeue, stale-lease→reclaim, флапп→форс-терминал).
- **D1.3** Транзиент-резилентность everywhere (обобщение ORCH-93): единый retry+backoff для всех внешних вызовов.
- **D1.4** Zero-downtime деплой платформы (blue-green/canary): резервное плечо вместо окна недоступности.
- **D1.5** Авто-rollback по SLO (расширение 21): откат по деградации latency/error-rate, не только health.
- **D1.6** Deep agent-liveness (self-healing LLM): «думает / завис / зациклился» по reasoning+CPU+прогрессу.
- **D1.7** Backup/restore БД+worktree (recovery после краша хоста).
---
## 4. ДОМЕН D2 — ✅ Качество / Доверие результата
> Новый домен. Закрывает дыру: платформа может надёжно и дёшево производить плохой результат. Надёжность инфры ≠ корректность кода/аналитики.
**Есть:** security-гейт (22), reviewer/tester стадии, промпт-аудит (92).
- **D2.1** Code-coverage гейт (ORCH-27): защита от деградации покрытия.
- **D2.2** Регресс-страж результата: не только «тесты зелёные», но «не сломали соседнюю фичу» (расширение regression-guard ORCH-73).
- **D2.3** Качество аналитики: метрика «BRD не пришлось переделывать», сверка факт vs ТЗ (как сегодня ловила ложное P0).
- **D2.4** Доверие к выходу: provenance артефактов, воспроизводимость, «деплой OK = прод реально работает» (урок ET-8).
- **D2.5** Опциональная человеческая приёмка важных фич (ORCH-28).
- **D2.6** Само-оценка агентов: уверенность в результате → эскалация при низкой.
---
## 5. ДОМЕН D3 — 💰 Экономика
**Боль (ORCH-38):** developer сжёг **$13.68 на мелочь** (cache_read 18.98M — слепое сканирование src/).
- **D3.1** Model-routing cascade (мир: 87%): классификатор сложности → дешёвая модель на простое, opus на сложное (ORCH-20+13).
- **D3.2** Бюджет circuit-breaker (ORCH-23): хард-лимит $/токенов/времени → пауза+алерт.
- **D3.3** Оценка задачи ДО старта (ORCH-20): прогноз $/время по истории.
- **D3.4** Целевые файлы в задании (ORCH-38): analyst даёт точный список из TRZ → нет слепого сканирования. **Самый дешёвый высокий impact.**
- **D3.5** Fast-track простых задач (ORCH-19): багфикс → урезанный цикл без architect, дешёвая модель.
- **D3.6** Semantic caching / prompt compression (мир: 31%).
- **D3.7** Cost-дашборд + детект аномалий.
---
## 6. ДОМЕН D4 — 🚀 Возможности (рост функционала)
> **Равноценный домен (акцент Славы).** Это то, ради чего платформой ПОЛЬЗУЮТСЯ. Без новых возможностей надёжность бессмысленна — нечего надёжно делать. Развивается параллельно с D1-D3, а не после.
**Backlog-зародыши:** ORCH-12/13/14/15/18/24/25.
- **D4.1** Стеки-плагины: профили стека (web/mobile/data/ML/embedded) → агенты адаптируют процесс. Расширяемо без правки ядра. **Открывает заказчикам новые типы проектов.**
- **D4.2** Android/мобильный стек (ORCH-15): полноценная разработка приложений.
- **D4.3** UX/UI-дизайнер (ORCH-14): дизайнер-агент генерит макеты на аналитике, согласование с BRD.
- **D4.4** Интерактивный аналитик (ORCH-18): живой диалог Слава↔analyst — уточнение BRD, обсуждение вариантов до старта. Удобство + качество постановки.
- **D4.5** Тяжёлые вычисления (ORCH-12): воркер/стадия для долгих расчётов (ML-обучение, миграции данных).
- **D4.6** База знаний проекта (ORCH-24): RAG-контекст решений/архитектуры — агенты умнее (+экономия).
- **D4.7** Декомпозиция эпиков (ORCH-25): эпик→задачи→сборка автоматически (этот документ — кандидат №1).
- **D4.8** Новые роли-агенты: data-engineer, ML-инженер, DevOps — по мере типов проектов.
- **D4.9** Мультипровайдерность моделей (ORCH-13): не только Claude — выбор под задачу/стек/бюджет.
---
## 7. ДОМЕН D5 — 📈 Масштаб
> Вторая «рука роста»: способность делать БОЛЬШЕ и ШИРЕ. Сейчас потолок — `max_concurrency=1`.
**Backlog-зародыши:** ORCH-9/10; done: ORCH-6 (multi-repo), ORCH-88 (serial-batch).
- **D5.1** Параллельная разработка (снять max_concurrency=1): безопасный N>1 (изоляция worktree есть, нужна merge-orchestration FIFO + защита main). **Много фич параллельно = быстрее растём.**
- **D5.2** Turnkey-онбординг проекта (ORCH-9): команда → Plane+Gitea+агенты+инфра за минуты.
- **D5.3** Тиражирование на новый хост (ORCH-10): перенос платформы на инфру нового заказчика (IaC-bundle).
- **D5.4** Горизонтальный воркер-пул: очередь jobs (ORCH-1) → несколько воркеров/хостов.
- **D5.5** Per-project лимиты ресурсов (concurrency/бюджет на проект).
- **D5.6** Мультитенантность (отложено — SaaS-сценарий, по спросу).
---
## 8. ВЕРТИКАЛЬ-ДВИГАТЕЛЬ 🧠 — две турбины: реактивная + проактивная
> Двигатель питается из ДВУХ источников (коррекция Славы 09.06). Реактивная турбина (уроки из боли) кормит «крепнем» (D1-D3). Проактивная (генератор идей) кормит «растём» (D4-D5). Без второй турбины рост фич зависит только от Славы — бутылочное горлышко.
### 8A. Реактивная турбина 🔄 — петля самообучения из уроков (ORCH-8)
```
ДЕТЕКЦИЯ → ЖУРНАЛ урока → АНАЛИЗ/паттерны → ПРЕДЛОЖЕНИЕ задачи → [governance-гейт] → конвейер ORCH-7 → проверка эффекта → журнал
```
- **Детекция:** провал гейта, **ручное вмешательство (самый ценный сигнал — каждый ручной пинок = дыра автономности)**, ретраи/откаты/таймауты, ложные срабатывания, «деплой OK / прод сломан».
- **Анализ (гибрид):** машина копит и предлагает черновик → Стрим фильтрует/оформляет → Слава апрувит.
- **E1** Журнал уроков (=F2). **E2** Агент-ретроспективщик (анализ→предложение).
### 8B. Проактивная турбина 💡 — генератор идей новых возможностей (НОВОЕ — запрос Славы)
> Отдельный источник идей роста функционала — НЕ только требования от Славы. Проактивно предлагает новые фичи/возможности/удобства. Та же воронка: машина/агент генерит черновики → Стрим фильтрует → Слава решает.
**Источники идей (вход генератора):**
- **I1 Гэпы реализации:** чего НЕ хватило для запрошенных проектов (enduro-trails, snowbike — что было тяжело/невозможно сделать платформой → кандидат в фичу).
- **I2 Паттерны ручного труда:** что Слава/заказчики часто делают руками ВНЕ платформы → кандидат на автоматизацию/фичу.
- **I3 Тренды и новые технологии:** сканирование новых моделей/стеков/инструментов (web-поиск, release-notes провайдеров) → «вышла модель X / фреймворк Y — даёт новую возможность».
- **I4 Конкурентный/рыночный анализ:** что умеют другие AI-платформы разработки (Devin, Cursor, Copilot Workspace…) → чего нет у нас.
- **I5 Анализ собственного бэклога/истории:** паттерны типов задач → «часто просят X → стоит сделать шаблон/фичу».
- **I6 Обратная связь заказчиков:** явные пожелания/жалобы по реализованным проектам.
- **I7 Саморефлексия Стрим:** я вижу работу платформы изнутри каждый день — предлагаю удобства/фичи из опыта ведения.
**Компоненты:**
- **E4 Агент-идеатор (product-discovery):** по расписанию сканирует I1-I7 → генерит бэклог идей-черновиков фич (с обоснованием «зачем/кому/из какого источника»).
- **E5 Банк идей:** отдельный реестр (не путать с журналом уроков): идея, источник, предполагаемая ценность, статус (new/отклонена/в работе).
### 8C. Общий выход двигателя
- **E3 Приоритизатор RICE:** сводит ОБА потока (уроки из 8A + идеи из 8B) в единый ранжированный бэклог по impact/cost/risk — что брать первым по всем доменам. Баланс «крепнем vs растём» — настраиваемый (квота слотов на надёжность vs фичи).
---
## 9. ВЕРТИКАЛЬ-ТОРМОЗ 🛑 — Governance / Safety
> «Контроль и управление саморазвитием» (требование Славы). Двигатель жмёт газ — этот контур держит руль и тормоз.
**Принцип (ORCH-8, незыблемо):** самомодификация платформы (промпты/скиллы/конфиги агентов/ядро) — ТОЛЬКО через PR+ревью+апрув Славы. Орк ПРЕДЛАГАЕТ, ПРИМЕНЯЕТ через свой конвейер с гейтами.
**Уровни автономии (agentic AIOps maturity):**
| Уровень | Что авто | Гейт |
|---------|----------|------|
| L0 reactive | только алерт | человек делает всё |
| L1 assistive | предложить задачу+ТЗ | человек апрувит запуск |
| L2 autonomous-bounded | гонит безопасные классы (бэкенд-фиксы) до прода | safety-гейты CI/staging/regression |
| L3 self-modifying | менять агентов/ядро | **всегда** PR+апрув Славы, НИКОГДА не авто |
- **G1** Safety-политика L0-L3 + per-class правила (что можно само, что только через Славу). Лейблы autoApprove/autoDeploy (ORCH-89) = уже зародыш.
- **G2** Бюджет на саморазвитие: лимит $/мес, чтобы контур не жёг бесконтрольно.
- **G3** Дашборд эволюции: метрики 5 доменов в динамике — видно, КУДА развивается платформа.
- **G4** Kill-switch петли: остановить самогенерацию задач одним флагом.
---
## 10. 🌡️ Градусник автономности (сквозная метрика)
Объединяющая измеримая цель эпика. Каждый домен двигает её вверх:
- **% задач без ручного пинка** (сегодня было ~5 вмешательств: апрувы, домерж 063, sync 061).
- **Ручных вмешательств / неделю** (тренд вниз).
- **MTBF / MTTR** платформы (D1).
- **$/задача, токены/задача, время/задача** (D3).
- **Типов проектов/стеков поддержано** (D4).
- **Задач параллельно** (D5).
- **% уроков, ставших задачами** (двигатель).
---
## 11. Связь с Backlog (ничего не теряем)
| Backlog | Домен/вертикаль |
|---------|-----------------|
| ORCH-8 петля | 🧠 Двигатель (ядро) |
| ORCH-83 наблюдаемость | Фундамент F1 |
| ORCH-20/23/38/19 | 💰 D3 |
| ORCH-27/28 | ✅ D2 |
| ORCH-12/13/14/15/18/24/25 | 🚀 D4 |
| ORCH-9/10 | 📈 D5 |
| ORCH-94 флапп | 🛡️ D1.2 |
| ORCH-89 авто-лейблы | 🛑 G1 |
~18 backlog-задач ложатся в структуру. Эпик их систематизирует и достраивает.
---
## 12. Дорожная карта (предложение)
1. **Фаза 0 (фундамент):** F1 наблюдаемость + F2 журнал. Без них рулить нечем.
2. **Фаза 1 (две руки параллельно):**
- крепнем: D3.4 целевые файлы + D3.2 бюджет-breaker (дешёвый impact)
- растём: D4.1 стеки-плагины ИЛИ D4.4 интерактив-аналитик (по спросу)
3. **Фаза 2:** D1 надёжность (транзиент-резилентность, авто-ремедиация) + D2 качество + D5.1 параллелизм.
4. **Фаза 3 (мозг):** E2 ретроспективщик + E3 приоритизатор + G1 safety-политика → петля замыкается, дальше платформа предлагает сама.
---
## ⛓️ Реализация в Plane (решено 09.06)
**Ось ДОМЕНА → модули Plane** (1 задача = 1 модуль; slug в `external_id`, name с эмодзи для человека):
| Модуль (name) | slug (external_id) | module_id |
|---|---|---|
| 👁️ Фундамент | `foundation` | 74dee25a-a44b-4c3b-ab55-1b5638b8cc1f |
| 🧠 Мозг | `brain` | ab1afa08-14ce-4b7d-8ebc-e45ac19b2ba7 |
| 🛡️ Надёжность | `reliability` | abd7479e-4f9b-4a56-a926-cb2ece7558ca |
| ✅ Качество | `quality` | cbf5f8ca-dc1a-4dee-9d35-555459de2b30 |
| 💰 Экономика | `economy` | 9b4bbab3-95d6-4b8a-8d72-379a618ea2f3 |
| 🚀 Возможности | `features` | baa6936c-6a39-4935-ad57-31ef5ffc3041 |
| 📈 Масштаб | `scale` | 18373528-14fa-4627-a0f6-32497ff22177 |
**Ось ВЕРТИКАЛЬ → лейблы** (могут быть несколько, список короткий):
- `engine` (36f398f7-5a1c-4eeb-847a-56c457e1da6b) — задача пришла от петли/идеатора.
- `governance` (9eea4dd8-0fe7-473a-8c40-630fc3ab0d25) — требует апрува L3 / safety-внимания.
- (+ существующие `autoApprove`/`autoDeploy` — ортогональны, режим автономности.)
**Правило раскладки:** каждая задача эпика = 1 модуль-домен (по slug) + 0..N вертикаль-лейблов. Орк ищет/привязывает по `external_id` (не по русскому имени).
⚠️ **Порядок модулей на доске:** Plane API игнорирует `sort_order` на запись (только drag-and-drop в UI). Сейчас порядок перевёрнут (Масштаб сверху) — Славе поправить мышкой (фундамент→мозг→надёжность→качество→экономика→возможности→масштаб). На машинную логику не влияет (орк по slug).
---
## 13. Открытые вопросы Славе
1. **Структура Plane:** мега-эпик с фундаментом+5 доменами+2 вертикалями? Или эпик на каждый домен?
2. **D4 (возможности):** какой стек/фича приоритетны для тебя/заказчиков — Android, UX/UI, тяжёлые расчёты, интерактив-аналитик? С чего рост начинать?
3. **Баланс «крепнем vs растём»:** идти строго параллельно обеими руками, или в каждой фазе перевес в одну сторону?
4. **Safety L3:** подтверждаешь — самомодификация ядра/агентов всегда через твой апрув?
5. **Двигатель (E2/E4):** ретроспективщик + агент-идеатор сразу как агенты, или сначала Стрим ведёт журнал/банк идей вручную?
8. **Генератор идей (8B):** какие из источников I1-I7 тебе ценнее (гэпы проектов / тренды-технологии / конкуренты / саморефлексия Стрим)? Генерить автономно или только по твоему запросу?
6. **Бюджет на эпик (G2):** лимит $/мес?
7. **Первая задача** после апрува: F1 наблюдаемость, быстрая победа D3.4, или сразу рост D4.*?