auto-sync: 2026-06-09 21:00:01

memory/2026-06-09.md

@@ -211,3 +211,18 @@
 - Закрыла brd-clock → PATCH In Review→Approved (200) → architect job 1183 running, stage=architecture.
 - Очередь движется: 090(arch running)→091→093 (062 ушла вперёд, в очереди её нет).
 - Скоуп STOP: G1 остановка (SIGTERM+отмена job+исчерпание ретраев+снятие таймеров) / G2 полный сброс (ветка+worktree+durable cancelled, docs сохранить) / G3 единственный вход To Analyse / G4 закрыть дыру релонча / G5 идемпотентность+fail-safe merge/deploy. never-raise/kill-switch/restart-safe. 14 TC, 10 AC.
+
+## 🧬 КОНЦЕПЦИЯ ЭПИКА «Автономное саморазвитие платформы» (Слава, 09.06 ~17:48 MSK)
+- **Задача Славы:** проанализировать уроки орка (память+репо) + ORCH-8, инвентаризировать ВСЕ задачи Plane (все статусы), погуглить мировые практики → концепция автономного саморазвития по 4 блокам + управление.
+- **Документ:** `tasks/orchestrator/EPIC_AUTONOMOUS_SELF_EVOLUTION.md` (14КБ).
+- **Инвентаризация Plane: 94 задачи** (63 Done, 21 Backlog, 4 Cancelled, остальные в работе). Backlog уже содержит ~18 зародышей всех 4 блоков.
+- **ORCH-8** = ядро петли самообучения (детекция→журнал→анализ→предложение→конвейер ORCH-7→проверка). Safety-принцип ORCH-8: самомодификация агентов/ядра ТОЛЬКО через PR+апрув Славы, никогда не авто в рантайме.
+- **Структура концепции:** 4 модуля Славы + мета-контур M0:
+  - M1 Self-Repairing (надёжность): ORCH-83 фундамент, предиктив, авто-ремедиация, транзиент-резилентность, zero-downtime, chaos-staging, agent-liveness, backup.
+  - M2 Расширение: стеки-плагины, интерактив-аналитик (ORCH-18), UX/UI (ORCH-14), Android (ORCH-15), тяжёлые расчёты (ORCH-12), база знаний (ORCH-24), декомпозиция эпиков (ORCH-25).
+  - M3 Экономика: model-routing cascade (−87% мир), бюджет-breaker (ORCH-23), оценка задачи (ORCH-20), целевые файлы (ORCH-38, дешёвый высокий impact — developer жёг $13.68 на мелочь), fast-track багов (ORCH-19), semantic caching.
+  - M4 Масштаб: параллелизм (снять max_concurrency=1), онбординг (ORCH-9), тиражирование на хост (ORCH-10), воркер-пул, мультитенант.
+  - **M0 Управление:** петля ORCH-8 + safety-модель L0-L3 (L3 самомодификация=всегда апрув Славы) + журнал уроков + агент-ретроспективщик + приоритизатор RICE + дашборд эволюции. Лейблы autoApprove/autoDeploy (ORCH-89) = уже механизм управления автономией.
+- **Мир-практики:** STRATUS NeurIPS'25 (мультиагент SRE), ChaosEater ASE'25, self-healing LLM-agents arXiv'26, causal AIOps Stanford, model-routing −87%/semantic-caching −31%, FinOps guardrails.
+- **6 открытых вопросов Славе** в доке (структура Plane, safety L3, приоритет фаз, ретроспективщик сразу/потом, бюджет на эпик, первая задача).
+- ⏳ Ждёт апрува концепции → потом декомпозиция в задачи Plane. НЕ заводила задачи (концепция первая).

tasks/orchestrator/EPIC_AUTONOMOUS_SELF_EVOLUTION.md

@@ -0,0 +1,206 @@
+# 🧬 ЭПИК: Автономное саморазвитие платформы оркестратора
+
+> **Статус:** концепция (для апрува Славы → декомпозиция в задачи)
+> **Автор:** Стрим · **Дата:** 2026-06-09 · **Заказчик:** Слава
+> **Связанные:** ORCH-8 (петля самообучения), ORCH-83 (наблюдаемость), ORCH-54 (автономное внедрение, done)
+> **Источники:** память орка (инциденты 06–09.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 > автономность).
+
+Эпик делится на **4 модуля развития** + **1 управляющий контур** (мета-слой, который рулит первыми четырьмя).
+
+---
+
+## 1. Принцип деления (по Славе)
+
+| # | Модуль | Суть | Метрика успеха |
+|---|--------|------|----------------|
+| **M1** | 🛡️ **Self-Repairing** (надёжность) | Стабильность, отказоустойчивость, производительность БЕЗ потери функциональности | MTBF↑, MTTR↓, % автономных задач без ручного пинка↑ |
+| **M2** | 🚀 **Расширение функционала** | Новые возможности для заказчиков: стеки, фичи, удобства | число поддержанных типов проектов/стеков↑ |
+| **M3** | 💰 **Экономика** | Оптимизация $/токенов/времени/ресурсов на задачу + контроль расходов | $/задача↓, токены/задача↓, время/задача↓ при том же качестве |
+| **M4** | 📈 **Масштабируемость** | Параллелизм, онбординг проектов, перенос на новую инфру | задач параллельно↑, время онбординга проекта↓ |
+| **M0** | 🧭 **Управление саморазвитием** | Мета-контур: петля обучения, приоритизация, safety-гейты, дашборд эволюции | покрытие уроков→задачами↑, 0 неконтролируемых самоизменений |
+
+---
+
+## 2. Мировые практики (что берём)
+
+- **STRATUS (NeurIPS'25)** — мультиагентная автономная reliability-инженерия облака: агенты-расследователи + remediation с гарантиями безопасности. → паттерн для M1 (агент-SRE).
+- **ChaosEater (ASE'25)** — автоматизация chaos-engineering через LLM. → M1: периодически инъецировать сбои в staging, проверять самовосстановление.
+- **Self-Healing LLM-agents (arXiv 2026)** — мониторинг ВНУТРЕННЕГО reasoning агента + внешних результатов исполнения. → M0/M1: liveness не только по pid, но по «думает ли осмысленно».
+- **Agentic AIOps (LogicMonitor/Deimos 2025-26)** — зрелость: reactive→assistive→autonomous; «humans still press enter» на критичном. → M0 safety-модель.
+- **Causal AIOps (Stanford NeurIPS'25)** — предсказание сбоев плато на ~90% без причинно-следственного вывода. → M1 предиктивный мониторинг = causal, не только корреляция.
+- **Model routing cascades (−87% стоимости)** + **semantic caching (−31%)** + **prompt compression (LLMLingua)** + **runtime token governance** (TechTarget'26). → прямо в M3.
+- **FinOps guardrails** (Flexera/Amnic 2026): автономные cost-гардрейлы, бюджет-aware решения, аномалии расходов. → M3 + M0.
+
+---
+
+## 3. МОДУЛЬ M1 — 🛡️ Self-Repairing (надёжность)
+
+**Что уже есть (фундамент):** reconciler (ORCH-53), post-deploy monitor+rollback (ORCH-21), merge-verify (ORCH-71/73), job-reaper+stale-lease (ORCH-65), security-гейт (ORCH-22), disk-watchdog (ORCH-63), build-cache-prune (ORCH-62).
+
+**Уроки из истории, которые M1 закрывает системно:**
+- Фантом-merge (08.06): прод расходился с main, 4 PR не слиты → накопительная потеря кода.
+- Deploy-петля (06–07.06): bootstrap-парадокс, ложный staging FAIL.
+- Транзиенты (09.06): Anthropic Overloaded (отретраился) + Gitea 405 (не отретраился → ложный HOLD).
+- Флаппинг статусов (09.06, ORCH-94): done-задача дёргает deploy-статусы вечно.
+- Зомби-jobs/merge-lease залип (06.06).
+
+**Кандидаты-задачи M1:**
+- **M1.1 Предиктивный мониторинг** (на базе ORCH-83): time-series по диску/памяти/очереди → алерт ДО исчерпания (causal, не только порог). Прогноз «диск заполнится через N часов».
+- **M1.2 Авто-ремедиация рантайма** (расширение reconciler): типовые сбои чинятся сами по runbook (зомби-job→requeue, stale-lease→reclaim, флапп-статус→форс-терминал). Каталог авто-фиксов.
+- **M1.3 Транзиент-резилентность everywhere** (обобщение ORCH-93): единый retry-with-backoff слой для ВСЕХ внешних вызовов (Gitea/Plane/Anthropic) — breaker-паттерн как у агентов.
+- **M1.4 Zero-downtime деплой** платформы: blue-green/canary для self-hosting (сейчас рестарт = окно недоступности). Резервное плечо.
+- **M1.5 Авто-rollback по SLO** (расширение ORCH-21): не только health-check, но деградация метрик (latency/error-rate) → откат.
+- **M1.6 Chaos-в-staging** (ChaosEater-паттерн): периодически ломать staging, проверять что monitor+rollback ловят.
+- **M1.7 Agent-liveness deep** (self-healing LLM): детект «агент думает vs завис vs зациклился» по reasoning+CPU+прогрессу (урок: analyst завис 22 мин, лезли в /proc).
+- **M1.8 Backup/restore** БД орка + worktree-state (durable recovery после краша хоста).
+
+---
+
+## 4. МОДУЛЬ M2 — 🚀 Расширение функционала
+
+**Backlog уже содержит зародыши:**
+- **ORCH-12** тяжёлые миграции/расчёты (опциональная стадия).
+- **ORCH-14/18** UX/UI дизайнер + интерактивный аналитик (живой диалог, макеты).
+- **ORCH-15** Android-приложения (мобильный стек).
+- **ORCH-13** мультипровайдерность LLM (Claude+OpenRouter+др).
+- **ORCH-24** персистентная база знаний проекта.
+- **ORCH-25** декомпозиция эпиков (фича→подзадачи→сборка).
+- **ORCH-27** code-coverage гейт.
+- **ORCH-28** опциональная человеческая приёмка.
+
+**Кандидаты-задачи M2:**
+- **M2.1 Стеки-плагины:** формализовать «профиль стека» (web/mobile/data/ML) → агенты адаптируют процесс под стек. Расширяемо без правки ядра.
+- **M2.2 Интерактивный аналитик** (ORCH-18): диалог Слава↔analyst для уточнения BRD + согласования макетов до старта.
+- **M2.3 UX/UI слой** (ORCH-14): дизайнер-агент генерит макеты на аналитике.
+- **M2.4 Тяжёлые вычисления** (ORCH-12): стадия/воркер для долгих расчётов вне основного цикла.
+- **M2.5 База знаний проекта** (ORCH-24): RAG-контекст решений/архитектуры для агентов (меньше «слепого сканирования» = ещё и экономия).
+- **M2.6 Декомпозиция эпиков** (ORCH-25): автоматический разбор эпика на задачи (этот документ — кандидат №1 на проверку).
+
+---
+
+## 5. МОДУЛЬ M3 — 💰 Экономика
+
+**Backlog-фундамент:** ORCH-20 (оценка), ORCH-23 (бюджет circuit-breaker), ORCH-38 (контроль токенов), ORCH-19 (дешёвый трек багфикса), ORCH-92 (промпт-аудит, done — частично эффорт).
+
+**Боль (факт из ORCH-38):** developer сжёг **$13.68 на мелкую задачу** (cache_read 18.98M — слепое сканирование src/). Стоимость линейно зависит от перечитывания контекста.
+
+**Кандидаты-задачи M3:**
+- **M3.1 Model routing cascade** (мир: −87%): классификатор сложности (trivial/small/medium/complex) → дешёвая модель на простое, opus только на сложное (ORCH-20 шаг 2 + ORCH-13). Роутер-модель дешёвая.
+- **M3.2 Бюджет circuit-breaker** (ORCH-23): хард-лимит $/токенов/времени на задачу/стадию → пауза+алерт при превышении. Защита по факту.
+- **M3.3 Оценка задачи ДО старта** (ORCH-20 шаг 1): прогноз $/время по истории похожих → Слава видит до запуска.
+- **M3.4 Целевые файлы в задании** (ORCH-38): analyst кладёт точный список файлов из TRZ → агент не сканирует вслепую (главный пожиратель cache_read). **Самый дешёвый высокоэффективный фикс.**
+- **M3.5 Fast-track для простых задач** (ORCH-19): багфикс/тривиал → урезанный цикл (без architect, дешёвая модель) вместо полного 6-стадийного.
+- **M3.6 Эффорт-дисциплина** (на базе ORCH-92): per-stage effort, дешёвые модели на механику.
+- **M3.7 Semantic caching / prompt compression** (мир: −31%): кэш повторяющихся контекстов, сжатие промптов.
+- **M3.8 Cost-дашборд + аномалии** (связь M0): $/repo×agent, детект выбросов (как ORCH-16 поймали).
+
+---
+
+## 6. МОДУЛЬ M4 — 📈 Масштабируемость
+
+**Backlog-фундамент:** ORCH-9 (онбординг проектов turnkey), ORCH-10 (тиражирование на др. хост), ORCH-88 (пакетный режим, done — serial), ORCH-6 (multi-repo, done).
+
+**Текущее ограничение:** `max_concurrency=1` (serial-gate ORCH-88) — задачи идут по одной. Это сознательно для надёжности на этапе становления, но потолок масштаба.
+
+**Кандидаты-задачи M4:**
+- **M4.1 Параллельная разработка** (снять max_concurrency=1): безопасный N>1 (изоляция worktree уже есть ORCH-2; нужен merge-orchestration FIFO, защита от гонок main). Много фич параллельно.
+- **M4.2 Turnkey онбординг проекта** (ORCH-9): один скрипт/команда → Plane-проект + Gitea-репо + агенты + инфра. Минута вместо часов.
+- **M4.3 Тиражирование на новый хост** (ORCH-10): перенос всей платформы на инфру нового заказчика (IaC/compose-bundle).
+- **M4.4 Per-repo масштаб ресурсов:** разные лимиты concurrency/бюджета на проект.
+- **M4.5 Горизонтальный воркер-пул:** очередь jobs уже есть (ORCH-1) → несколько воркеров/хостов тянут одну очередь.
+- **M4.6 Мультитенантность:** изоляция заказчиков (БД/секреты/доступы) для SaaS-сценария.
+
+---
+
+## 7. МОДУЛЬ M0 — 🧭 Управление саморазвитием (мета-контур)
+
+> Это «мозг» эпика. Без него M1-M4 — просто список задач. M0 = ПЕТЛЯ, которая их генерит, приоритизирует и контролирует. Ядро = **ORCH-8**.
+
+### 7.1 Петля самообучения (ORCH-8)
+```
+ДЕТЕКЦИЯ отклонения → ЖУРНАЛ урока (машинный) → АНАЛИЗ/паттерны → ПРЕДЛОЖЕНИЕ задачи → [SAFETY-ГЕЙТ] → конвейер (ORCH-7) → проверка эффекта → обновление журнала
+```
+- **Детекция:** провал гейта, **ручное вмешательство человека (самый ценный сигнал — каждый ручной пинок = дыра автономности)**, ретраи/откаты/таймауты, ложные срабатывания, «деплой OK, прод сломан».
+- **Журнал:** структурированный (тип, контекст задача/стадия/агент, корень, предложение, статус) — НЕ свободный текст. Формализовать то, что сейчас в memory/.
+- **Анализ:** гибрид (склонение Стрим) — машина копит и предлагает черновик → Стрим фильтрует/оформляет → Слава апрувит.
+
+### 7.2 Safety-модель (КЛЮЧЕВОЕ — «контроль и управление»)
+**Принцип (ORCH-8, незыблемо):** самомодификация платформы (промпты/скиллы/конфиги агентов/ядро) — **ТОЛЬКО через PR + ревью + апрув Славы**. Никаких авто-правок в рантайме без человека в петле. Оркестратор ПРЕДЛАГАЕТ, ПРИМЕНЯЕТ через свой же конвейер с гейтами.
+
+**Уровни автономии (по зрелости, agentic AIOps):**
+| Уровень | Что можно авто | Гейт |
+|---------|----------------|------|
+| L0 reactive | только алерт | человек делает всё |
+| L1 assistive | предложить задачу+ТЗ (autoApprove/autoDeploy лейблы уже есть!) | человек апрувит запуск |
+| L2 autonomous-bounded | сам гонит безопасные классы (бэкенд-фиксы) до прода | safety-гейты (CI/staging/regression) держат |
+| L3 self-modifying | менять агентов/ядро | **всегда** PR+апрув Славы, никогда не авто |
+
+→ Текущие лейблы `autoApprove`/`autoDeploy` (ORCH-89) = уже механизм управления автономией per-task. M0 их обобщает в политику.
+
+### 7.3 Управление и видимость
+- **M0.1 Журнал уроков** (ORCH-8 шаг 1): машинная таблица отклонений + связь с задачами.
+- **M0.2 Агент-ретроспективщик:** после задачи/по расписанию анализирует уроки → черновик предложения.
+- **M0.3 Приоритизатор:** ранжирует кандидатов M1-M4 по impact/cost/risk (RICE-подобно). Что брать первым.
+- **M0.4 Дашборд эволюции** (расширение ORCH-83): метрики 4 модулей в динамике — видно, развивается ли платформа и куда.
+- **M0.5 Safety-политика автономии:** формализованные уровни L0-L3 + per-class правила (что орк может сам, что только через Славу).
+- **M0.6 Контроль расходов на саморазвитие:** сам эпик не должен жечь бюджет бесконтрольно (связь M3).
+
+---
+
+## 8. Связь с текущим Backlog (ничего не теряем)
+
+| Backlog-задача | Модуль | Действие |
+|----------------|--------|----------|
+| ORCH-8 петля самообучения | **M0** | ядро мета-контура |
+| ORCH-83 наблюдаемость [ЭПИК] | **M1/M0** | фундамент мониторинга |
+| ORCH-20 оценка задачи | M3 | M3.1/M3.3 |
+| ORCH-23 бюджет breaker | M3 | M3.2 |
+| ORCH-38 контроль токенов | M3 | M3.4/M3.8 |
+| ORCH-19 дешёвый трек багов | M3 | M3.5 |
+| ORCH-9 онбординг | M4 | M4.2 |
+| ORCH-10 тиражирование | M4 | M4.3 |
+| ORCH-12 тяжёлые расчёты | M2 | M2.4 |
+| ORCH-13 мультипровайдер | M2/M3 | M2/роутер |
+| ORCH-14 UX/UI | M2 | M2.3 |
+| ORCH-15 Android | M2 | M2.1 |
+| ORCH-18 интерактив-аналитик | M2 | M2.2 |
+| ORCH-24 база знаний | M2 | M2.5 |
+| ORCH-25 декомпозиция эпиков | M2/M0 | M2.6 |
+| ORCH-27 coverage-гейт | M1 | надёжность |
+| ORCH-28 человек-приёмка | M0 | safety |
+| ORCH-94 флапп-статус | M1 | авто-ремедиация |
+
+**Вывод:** ~18 backlog-задач уже ложатся в 4 модуля. Эпик их не заменяет — **систематизирует и достраивает** до связного контура с управляющим мозгом (M0).
+
+---
+
+## 9. Дорожная карта (предложение)
+
+1. **Фаза 0 (фундамент):** ORCH-83 наблюдаемость (M1) + ORCH-8 журнал уроков (M0). Без данных нечем рулить.
+2. **Фаза 1 (быстрые победы экономики):** M3.4 целевые файлы + M3.2 бюджет-breaker + M3.1 роутер. Дешёвый высокий impact.
+3. **Фаза 2 (надёжность):** M1.3 транзиент-резилентность + M1.2 авто-ремедиация + M1.1 предиктив.
+4. **Фаза 3 (мета-контур):** M0.2 ретроспективщик + M0.3 приоритизатор + M0.5 safety-политика → петля замыкается.
+5. **Фаза 4 (масштаб/расширение):** M4.1 параллелизм + M4.2 онбординг + M2.* по спросу заказчиков.
+
+---
+
+## 10. Открытые вопросы Славе (до декомпозиции)
+
+1. **Структура в Plane:** один мега-эпик ORCH-XX с 5 под-эпиками (M0-M4)? Или 5 отдельных эпиков? (Plane API v1 не умеет relations — иерархию ведём в доке + префиксах названий.)
+2. **Safety-модель L0-L3:** согласен, что L3 (самомодификация агентов/ядра) — ВСЕГДА через твой апрув, без авто? Или где-то хочешь выше автономность?
+3. **Приоритет модулей:** мой порядок Фаза0→экономика→надёжность→мета→масштаб. Согласен, или сначала масштаб (параллелизм)?
+4. **Агент-ретроспективщик (M0.2):** заводить как агента в конвейере сразу, или сначала Стрим вручную ведёт журнал и предлагает?
+5. **Бюджет на сам эпик:** лимит $/мес на саморазвитие, чтобы контур не жёг бесконтрольно?
+6. **Первая задача:** с чего стартуем после апрува концепции — ORCH-83 (видимость) или быстрая победа M3.4 (целевые файлы, −стоимость сразу)?