admin/wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
wiki/memory/2026-06-09.md
Stream 3bc5d1fb13 auto-sync: 2026-06-10 01:00:01
2026-06-10 01:00:01 +03:00

66 KiB
Raw Permalink Blame History

2026-06-09 — Дневник

🔍 ORCH-087 БЫЛА ЗАСТРЯВШЕЙ 6.5ч — разморозила (05:27 MSK, Слава заметил «статусы неактуальны»)

  • Слава: «посмотри что висит в deploying/monitoring, статусы неактуальные».
  • ⚠️ Ложная тревога #1 снята: Plane API v1 запрос ?state=<uuid> НЕ фильтрует — вернул ВСЕ 89 issue в каждом deploy-статусе. Это артефакт API, не реальное состояние. Реальный статус — только прямым GET issue.
  • ⚠️ Ложная тревога #2 снята: коммиты analyst(ET) у ВСЕХ ORCH-задач (082/086) — безобидный хардкод-префикс commit-helper, repo=orchestrator правильный. Не баг.
  • 🎯 РЕАЛЬНЫЙ баг — ORCH-087 (task 64) застряла: история состояний Plane:
    • 22:49:44 Backlog→To Analyse→Analysis
    • 22:54:25 Analysis→In Review (analyst job 718/run 420 отработал успешно, BRD/ТЗ/AC эталон, $1.24)
    • 22:56:49 In Review→Backlog ❗ — задачу ОТКАТИЛО в Backlog через 2.5 мин (вероятно мой PATCH/гонка при создании ORCH-89 в то же время ИЛИ sweeper)
    • Итог: Plane=Backlog, БД орка=analysis с НЕзакрытым brd_review_ended_at=None, 0 активных jobs → мёртвая задача 6.5ч
  • Фикс (правило ORCH-89, техническая → согласовала сама): проверила BRD/ТЗ/AC в worktree (эталон, оба требования учтены: G0-расследование bump + эффорт в карточку) → закрыла BRD-clock (brd_review_ended_at=datetime('now')) → Plane Backlog→Approved (PATCH 200) → webhook подхватил → architect job 770/run 426 running, stage=architecture. Разморожена.
  • ⚠️ УРОК: одновременные ручные PATCH-операции в Plane (я создавала ORCH-89 + патчила статусы) могут откатить задачу с In Review в Backlog (гонка/случайное наложение). Когда задача на In Review ждёт approve — НЕ трогать соседние операции в Plane, либо проверять что approve-pending не сбросился. Застрявшую In Review→Backlog ловить по brd_review_ended_at IS NULL + stage=analysis + 0 jobs.

⤷ ORCH-087 расширена 2 замечаниями Славы (09.06 ~05:33 MSK) — оба верны

  • Слава (reply на карточку 087): «(1) мы же нотифай меняли в 86, 87 должна использовать свежий; (2) в карточке время итоговое неправильно считается».
  • G6 — пересечение 86↔87 (Слава ПРАВ, риск эрозии): ORCH-86 СЛИТА в main (PR #86, merge 493b9be: F-1 terminal-skip + state_uuid в reconciler.py). НО ветка 087 срезана от 9281788 (ДО 86), отстала на 9 коммитов, трогает src/reconciler.py+tests/test_reconciler.py — ТЕ ЖЕ файлы что 86. Domerge как есть → затрёт 86 (эрозия, .gitattributes union спасает только CHANGELOG не reconciler.py).
    • Решение: ORCH-26 auto_rebase_onto_main сработает на merge-gate (merge_gate.py:113, rebase+force-with-lease ТОЛЬКО ветку). При конфликте reconciler.py → откат на development, dev переделает на свежей базе. Штатно, НЕ лезть руками под работающий конвейер (урок ORCH-26/71). G6 вписан в ТЗ 087.
  • G5 — итоговое время в карточке врёт (Слава ПРАВ, код-аудит notifications.py): финальная строка ⏱️ Всего <wall> · агенты <agent_seconds> · твоё <review>:
    • agent_seconds=Σ(finished−started) agent_runs — КОРРЕКТНО.
    • review_seconds=brd_review_ended−started — РАЗДУВАЕТСЯ при застое (087 показал «Подтверждение BRD 392м» = мой 6.5ч застой In Review→Backlog, не реальное обдумывание).
    • wall=updated_at−created_at — включает ВСЁ ожидание/простой/queue-wait → не сходится с agent+review.
    • G5: честно разделить рабочее (Σ agent_runs) / ожидание человека (только фактическое, без аномалий застоя) / wall (помечать «с ожиданием», не выдавать за работу); итог должен сходиться. AC: задача с искусств. застоем 6ч → «твоё время» НЕ показывает 6ч.
  • PATCH ORCH-087 desc 200 (16767 симв). Задача идёт: analyst→architect(done, ADR корень=гонка update_task_tracker из ≥5 потоков без замка)→developer running (job 771).
  • ⚠️ Следить: на merge-gate 087 ОБЯЗАН отребейзиться на main с 86. Проверить что reconciler.py 86 НЕ затёрт после merge 087 (регресс-гард ORCH-73 check_main_regression должен поймать).

↩️ ОТКАТ моей ошибки + ВАРИАНТ А (перепрогон 087 на свежей базе) (09.06 ~05:43 MSK)

  • МОЯ ОШИБКА: Слава НАМЕРЕННО перевёл 087 в Backlog (вчера 22:56), чтобы перепрогнать через аналитика со СВЕЖИМ нотифаем из 86. Я приняла за «застряла» и протолкнула вперёд на СТАРОМ анализе (без 86). Слава поправил → откатываю.
  • Решение Славы: ВАРИАНТ А — полный перепрогон через аналитика на свежей базе (main с 86).
  • Выполнено чисто (по урокам ORCH-81/26):
    1. developer pid 2130 был ЖИВ (проверила CPU delta=21/4с, 9 сокетов — НЕ убивала вслепую). Исчерпала ретраи job 771 (max_attempts=attempts) ПЕРЕД kill → SIGTERM → graceful выход 2с → job 771=failed, БЕЗ requeue.
    2. Удалила worktree + локальную + remote ветку 87 (была срезана от 9281788, ДО 86). Бэкап рефа: backup/ORCH-087-oldbase-20260609-084302 (194d6c8, работа developer'а на старой базе — на случай если понадобится).
    3. Удалила task64 + jobs + agent_runs из БД орка → webhook на To Analyse пойдёт по start_pipeline (if not existing) = СВЕЖАЯ task + ветка от origin/main (493b9be с 86) + аналитик с нуля.
    4. Plane 087 → Backlog (PATCH 200).
  • ⚠️ ВАЖНАЯ МЕХАНИКА (запомнить): webhook на To Analyse при СУЩЕСТВУЮЩЕЙ task НЕ создаёт новую — релончит агента ТЕКУЩЕЙ стадии на ТОЙ ЖЕ ветке (webhooks/plane.py:250-300). Чтобы перепрогнать с НУЛЯ на свежем main — удалить task+ветку, тогда start_pipeline режет ветку от origin/main (git_worktree.py:86 worktree add -b ... origin/main).
  • ✅ Готово к запуску: 087 в Backlog, чистая. При переводе в To Analyse аналитик прогонит на main с фиксом 86. ТЗ 087 уже содержит G5 (время) + G6 (использовать свежий notify/reconciler 86).
  • ⚠️ УРОК: НЕ интерпретировать действия Славы как «баг застрял» без проверки его сообщений. Он перевёл в Backlog ОСОЗНАННО (написал про нотифай) — я не связала. Читать контекст реплаев внимательнее.

✅ ORCH-087 ПЕРЕЗАПУЩЕНА на свежей базе (09.06 ~05:50 MSK) + 📝 ORCH-90 STOP-механизм заведён

  • ORCH-087 запуск: Plane Backlog→To Analyse (PATCH 200) → webhook start_pipeline (task64 удалена → if not existing) → новая task 65, stage=analysis, analyst job 772 run 428 running, ветка от свежего origin/main 493b9be. Проверено: reconciler.py = 6× skipped_terminal_total → фикс 86 на месте, ветка содержит свежий main. Аналитик прогонит на свежей базе с нотифаем 86. ТЗ содержит G5(время)+G6(свежий 86).
  • 📝 ORCH-90 STOP-механизм заведён (Слава заказал) seq=90 id=dec2d922-9c98-4180-afd0-2abc507645aa, Backlog, HIGH:
    • Идея Славы: новый Plane-статус STOP → орк немедленно останавливает работу (SIGTERM агенту, cancel job'ов, исчерпать ретраи, снять таймеры).
    • STOP = полный сброс прогресса. Повторный запуск ТОЛЬКО через To Analyse (с нуля: свежая ветка от origin/main + аналитик).
    • Промежуточные статусы (Development/Architecture/...) вручную НЕ запускают стадии — закрыть текущую дыру (handle_status_start релончит агента текущей стадии на той же ветке — ИМЕННО это вызвало сегодняшний инцидент с 087, когда я случайно протолкнула через статусы).
    • G1 остановка / G2 полный сброс ветки+worktree+task / G3 единственный вход=To Analyse / G4 промежуточные статусы=no action / G5 идемпотентность+fail-safe при прерывании merge/deploy.
    • Технические зацепки в карточке: webhooks/plane.py диспетчер, launcher SIGTERM, queue_worker cancel, git_worktree, новый STOP-UUID (группа cancelled). never-raise/kill-switch/self-hosting safety/не путать с Rejected.
    • 🎯 Прямая мотивация: сегодняшний ручной откат 087 (kill+удаление ветки+task вручную) — это и должен делать STOP автоматически.

✅ ORCH-087 BRD APPROVED на свежей базе (09.06 ~05:58 MSK, Стрим сама — ORCH-89)

  • Проверила свежие BRD(11к)/ТЗ(14к)/AC(9к) перепрогона (task 65, analyst run 428) — ЭТАЛОН, все замечания учтены:
    • BR-G6 + AC-6.1/6.2 — ветка от main с ORCH-86, reconciler.py не эродирован, проверка на merge-gate (маркеры 86 присутствуют).
    • BR-G5 + AC-5.1/5.2/5.3 — честное время: AC-5.1 застой 6ч → «твоё время» НЕ 6ч (ровно мой косяк), agent-время точное, итог сходится.
    • BR-EFF/AC-E.1-4 эффорт в карточке (developer=xhigh из стампа resolve_agent_effort при запуске — эффорт не возвращается в result-JSON), G0-расследование, never-raise, ссылки/preview сохранены. 18 AC.
  • PATCH In Review→Approved (200) → architect job 773 run 429 running, stage=architecture. Идёт автономно на свежей базе.

🔄 ORCH-88 ПЕРЕСМОТРЕН — полностью ПОСЛЕДОВАТЕЛЬНЫЙ E2E (Слава, 09.06 ~06:05 MSK)

  • Решение Славы: после инцидентов 08-09.06 (эрозия main, перезатирание, ветка 087 срезана до 086) — отказ от параллелизма. Задачи строго ПОСЛЕДОВАТЕЛЬНО e2e: аналитика N+1 стартует ТОЛЬКО когда N задеплоена (stage=done). Post-deploy мониторинг (~15м) НЕ в счёт. «Восстановление дороже».
  • Корень (почему от АНАЛИЗА, не от merge): анализ создаёт ветку от origin/main (git_worktree.py). Если N+1 анализируется пока N не в main → ветка от устаревшего main (= сегодняшний 087 до 086). Serial от анализа = каждая ветка от свежего main со всеми предыдущими.
  • Это РАДИКАЛЬНО упрощает Этап 1: не нужны merge-очередь FIFO / pre-merge rebase / фазовый A-B-C. Достаточно ОДИН gate планировщика:
    • FR-1 serial gate: не запускать analysis пока есть НЕ-done задача (stage<done) в репо.
    • FR-2 очередь не параллель: «пачка утром» = в очередь, обработка по одной e2e.
    • FR-3 per-repo (orch vs enduro параллельны — main-ы независимы).
    • FR-4 restart-safe (gate по БД, не in-memory).
  • ⚠️ Открытые вопросы к Славе (в карточке): (1) меняется батч-сценарий — BRD появляются по одному (не пачкой днём) → подтвердить размен надёжность>батч-просмотр; (2) merge vs deploy как сигнал «завершена» (предложила deploy-done — один чёткий сигнал); (3) auto-rollback ORCH-21 во время мониторинга — приостановить gate+алерт?
  • Зависимость ORCH-88←ORCH-83 сохраняется. PATCH 200 (13847 симв). Backlog.

✅ ORCH-88 СКОУП ЗАФИКСИРОВАН (Слава, 09.06 ~06:14) — решения по 3 вопросам

  • (1) Serial e2e подтверждён — BRD по одному, не пачкой. Осознанный размен надёжность>батч. «Пока так».
  • (2) Сигнал «завершена» = успешный ПРОД-деплой (не merge, не staging). Gate N+1 открывается когда N задеплоена в прод (done). Мониторинг не ждём.
  • (3) Auto-rollback во время мониторинга → ЗАМОРОЗИТЬ gate + алерт (FR-5). Не стартовать следующую до ручного разбора.
  • ⚠️ Зависимость ORCH-88←ORCH-83 УБРАНА (Слава: «сейчас не критично»). 88 запускается независимо.
  • Итоговый скоуп Этапа 1 (минимальный): FR-1 serial gate (analysis ждёт done предыдущей в репо) / FR-2 очередь e2e / FR-3 per-repo (orch∥enduro) / FR-4 restart-safe по БД / FR-5 rollback-freeze. БЕЗ merge-очереди/rebase/фазового режима. Backlog, запуск по решению Славы. PATCH 200 (15650 симв).

🔴 ORCH-087 застряла на development — CI КРАСНЫЙ из-за непереносимого теста (09.06 ~06:40 MSK)

  • Слава: «что тут» (карточка $0.00) → потом «разбирайся, может связано с нештатным срубанием прошлой итерации».
  • НЕ связано с моими kill (зомби нет, claude.exe нет, act_runner на хосте жив, я его не трогала). НЕ инфраструктура.
  • Корень (распаковала zst-лог CI 1240 из gitea-контейнера): ОДИН тест упал — FAILED tests/test_launcher.py::TestEffortStamp::test_spawn_stamps_resolved_effort - PermissionError: [Errno 13] Permission denied: '/app'. 1 failed, 1089 passed.
  • Механизм: launcher._spawn (стр.464) хардкодит output_path="/app/data/runs/{run_id}.log" + os.makedirs('/app/data/runs'). Новый тест BR-EFF (стамп эффорта) дёргает _spawn, который пытается makedirs('/app/...'). В КОНТЕЙНЕРЕ орка /app есть → проходит (я локально видела 1090 passed). В CI на ХОСТЕ (act_runner hostexecutor, юзер slin) /app недоступен → PermissionError → fail.
  • Это законный баг теста: developer не замокал хардкод /app в _spawn. Тест окружение-зависимый (контейнер vs CI-хост). check_ci_green ПРАВИЛЬНО держит задачу на development (гейт работает).
  • ⚠️ Почему dev получил 1090 локально: он тоже бежал pytest В контейнере орка (/app есть). CI бежит на хосте — там нет. Расхождение local-vs-CI = непереносимый тест.
  • Урок: тесты НЕ должны зависеть от хардкод-путей контейнера (/app). _spawn хардкодит /app → надо мокать output_path/makedirs ИЛИ брать путь из settings. Это надо чинить (reviewer должен был поймать, или developer — замокать). Задача вернётся на доработку через REQUEST_CHANGES естественным путём ИЛИ нужно перезапустить dev с указанием.
  • ⏸️ Жду решения Славы: (a) дать конвейеру самому завернуть на reviewer REQUEST_CHANGES; (b) перезапустить developer с явным указанием замокать /app; (c) я через сессию Dev-агента поправлю тест. НЕ обхожу CI-гейт.

🔒 УРОК ЗАКРЕПЛЁН (Слава: «закрепи») + перезапуск developer (вариант 2)

  • Урок (класс «зелёный локально → красный CI»): тесты орка НЕ должны зависеть от хардкод-путей контейнера (/app). developer/тестер гоняют pytest В контейнере (/app есть), CI бежит на ХОСТЕ (act_runner hostexecutor под slin, /app НЕТ).
  • Закреплено в 3 местах: (1) ТЗ ORCH-087 — новый AC + fix-требование (мокать output_path/tmp_path или вынести runs-путь в settings); (2) коммент reviewer в Plane ORCH-087; (3) reviewer-чеклист «заворачивать тесты с хардкод-путями контейнера» — для ВСЕХ задач впредь.
  • Диагностика CI-фейла (метод): логи Gitea Actions = zstd в gitea-контейнере /data/gitea/actions_log/admin/orchestrator/dN/NNNN.log.zst. API /actions/.../logs КЭШИРУЕТ старые логи (отдал 07.06!) — распаковывать zst напрямую (docker cp + zstd -dc на хосте). Статусы: GET /commits/<sha>/statuses (все), combined /status.
  • ⚠️ TODO: дописать этот урок в MEMORY.md (раздел про тесты) — сейчас не вышло (bootstrap-усечение секции). Дописать append'ом в конец позже.

🎉 ORCH-087 В ПРОДЕ (09.06 ~07:12 MSK) — перепрогон на свежей базе УСПЕШЕН, автономный деплой

  • Слава: «Аппрувь» (на staging-OK уведомление) → проверила → Confirm Deploy.
  • developer (job 775/run 431) починил CI-тест ПРАВИЛЬНО (вынос в settings, не костыль): config.py runs_dir="/app/data/runs" + launcher output_path через settings.runs_dir везде (no hardcoded /app). Проблемный тест test_spawn_stamps_resolved_effort → 1 passed (окружение-независим). CI → success.
  • Верификация перед прод-деплоем (моя): G6 цел — ветка от main с 86, reconciler.py НЕ тронут (0 изменений, skipped_terminal_total=6), terminal-skip 86 на месте. Тест-фикс = корневой (хардкод /app убран), не маскировка.
  • Confirm Deploy → автономный деплой БЕЗ ручного домержа: PR #87 merged=True (честный, ensure_open_pr ORCH-81 сработал), main a23d4c0, код 087 в main (runs_dir=2, tracker_messages=9). task→done, post-deploy-monitor HEALTHY.
  • ИТОГ 087: весь цикл перепрогона на свежей базе (после моего отката варианта А) прошёл чисто: analysis→arch→dev→CI-fail(непереносимый тест)→dev-fix→review→test→staging→prod. Реализованы G1(сироты: леджер tracker_messages)/G2(заголовок)/G3(deploy-цикл)/BR-EFF(эффорт в карточке)/BR-G5(честное время, cap brd-review)/G6(свежий 86)/G7(гонка метрик)+урок про /app.
  • ✅ Карточка трекера теперь: не оставляет сирот, показывает эффорт (· model · effort), честное итоговое время (cap на застой). Баг со скриншота Славы закрыт.

🚀 ORCH-88 ЗАПУЩЕНА (serial e2e) + ✏️ ORCH-89 ПЕРЕПИСАНА (авто-режим по лейблам) (09.06 ~07:35 MSK)

  • ORCH-88 запуск: перед To Analyse вычистила МИНУ — карточка содержала ДВЕ противоречивые версии скоупа подряд (старый фазовый A/B/C+merge-очередь+зависимость от ORCH-83 СВЕРХУ, новый serial e2e СНИЗУ). Аналитик прочёл бы весь desc → спроектировал фазовую махину. Переписала: один скоуп serial e2e (FR-1..5) + дисклеймер сверху «фазовый/merge-очередь/ORCH-83 ОТМЕНЕНЫ». PATCH 200.
    • Plane Backlog→To Analyse (PATCH 200) → webhook start_pipeline → task 66, analyst job 810 run 435 running, ветка feature/ORCH-088-orch-88-10-20 от свежего main a23d4c0 (с 86+087). Конвейер был свободен (0 активных). Идёт автономно, жду BRD на апрув.
    • ⚠️ УРОК: при повторных PATCH desc карточки старый текст НЕ затирается — накапливается. Перед запуском задачи ВСЕГДА вычитать ВЕСЬ desc, убрать устаревшие/противоречивые блоки, иначе аналитик возьмёт не ту версию. Single source of truth в одной карточке.
  • ORCH-89 переписана (Слава: «забудь прошлый подход»): старая модель «Стрим ревьюит и аппрувит BRD технических задач» ОТМЕНЕНА. Новая модель — автономность по ЛЕЙБЛАМ Plane:
    • autoApprove → орк САМ подтверждает BRD (гейт 1, In Review→Approved), без человека.
    • autoDeploy → орк САМ подтверждает прод-деплой (гейт 2, Confirm Deploy) и деплоит, без человека.
    • Лейблы независимы; оба = полная автономность анализ→деплой. Без лейблов = текущее ручное поведение.
    • 🔒 Авто снимает ТОЛЬКО человеческое решение. Тех-гейты (CI green, staging healthy, provenance, regression-guard ORCH-73, merge-lease ORCH-81) ОСТАЮТСЯ — autoDeploy НЕ деплоит сломанное.
    • fail-safe: label неясен → откат к ручному гейту. Каждый авто-проход логируется в карточку/Telegram (прозрачность).
    • 7 AC. Лейблов в проекте СЕЙЧАС нет (count=0) → создать autoApprove/autoDeploy (labels API v1 работает). Новое name + desc, PATCH 200. Backlog.

🐛 ORCH-91 ЗАВЕДЕНА — заголовок карточки застывает «To Analyse» на stage=deploy-staging (09.06 ~08:25 MSK)

  • Слава (скрин): «почему опять на тестировании To Analyse». Карточка ORCH-088: тело все стадии ✅ ($20+), а заголовок «📍 To Analyse».
  • ⚠️ Сначала решила «косметика/гонка bump» — но ПРОВЕРИЛА КОДОМ и нашла РЕАЛЬНЫЙ детерминированный баг:
    • tasks.stage='deploy-staging', а в _STAGE_STATUS_LABEL (notifications.py ~941) НЕТ ключа deploy-staging (только deploy). .get(stage, _DEFAULT_STATUS_LABEL) → дефолт «To Analyse».
    • Воспроизведено: plane_status_label(task66) → 'To Analyse' при stage='deploy-staging'. render_task_tracker(66) свежий → тоже «To Analyse».
    • render stateless и читает stage каждый раз — рендер ОК, баг в СЛОВАРЕ меток. Не bump, не сироты (леджер tracker_messages работает: 18432 активна, старые deleted).
  • Шире: набор реальных stage-значений stage_engine/STAGE_TRANSITIONS РАСХОДИТСЯ с ключами _STAGE_STATUS_LABEL. Возможно не только deploy-staging выпадает — проверить deploy-prod/confirm и др. при реализации.
  • Связь с ORCH-87: 87 закрыл сирот+эффорт+время, но G2 «заголовок не застывает» НЕ полностью — этот кейс (неизвестный stage→дефолт) остался. ORCH-91 = follow-up.
  • ORCH-91 seq=91 id=60bba158-c1b2-40d5-98e4-e0d9f31b578e, Backlog, medium. BR-1 все stage имеют метку / BR-2 deploy-staging→Deploying / BR-3 анти-регресс тест по всем STAGE_TRANSITIONS / 4 AC. Где: notifications.py _STAGE_STATUS_LABEL + plane_status_label, сверить со stage_engine.
  • ⚠️ УРОК: не объявлять «косметика» не проверив кодом. Сначала решила гонка bump — оказался детерминированный баг словаря. Воспроизводить вживую (render_task_tracker + plane_status_label) ПЕРЕД выводом.

🔬 Системное ревью 6 промптов агентов + ORCH-92 «промпт-аудит» (09.06 ~15:30 MSK)

  • Контекст: Слава спросил про роль аналитика (БА vs системный). Вывод: агент-«аналитик» делает 01-brd (БА) + 02-trz (модули src/, API, схема БД — уже системный анализ) + 03-acceptance-criteria + 04-test-plan → это бизнес-системный аналитик, не чистый БА (спускается до src/-модулей и схемы БД).
  • По просьбе Славы провела системное ревью всех 6 промптов (.openclaw/agents/: analyst/architect/developer/reviewer/tester/deployer). Достала из main через exec. Качество высокое (52d/52e подтянули единый канон Anthropic, эмит схемы 52c, анти-регресс).
  • 3 системные проблемы найдены:
    1. (изначально подозревала рассинхрон tester-гейта check_tests_passed vs _parse_tests_verdict)
    2. вердикт-формат tester читает result:
    3. сверка имён гейтов в промптах с реестром QG_CHECKS.
  • ⚠️ КЛЮЧЕВОЙ УРОК ДНЯ (проверка кодом окупилась): перед закладкой P0-замечаний в ТЗ ВЕРИФИЦИРОВАЛА их реальным кодом (grep по checks.py / QG_CHECKS). Моё P0-замечание №2 оказалось ЛОЖНЫМ: гейт check_tests_passed реально существует (checks.py:182, в QG_CHECKS:765) — tester.md называет его ВЕРНО. Я спутала с внутренним хелпером _parse_tests_verdict (это не имя гейта). Если бы не проверила — аналитик пошёл бы «чинить» то, что не сломано. → Правило: ВСЕГДА верифицировать замечания/баги кодом ПЕРЕД закладкой в ТЗ. Не доверять памяти про имена функций/гейтов.
  • Реальные имена гейтов в QG_CHECKS (проверено grep'ом checks.py): check_analysis_complete, check_architecture_done, check_ci_green, check_tests_passed (checks.py:182), check_security_gate. tester читает вердикт result: — security-гейт зовётся check_security_gate.
  • ORCH-92 заведена (seq 92, id 4f83483e-89b8-4c7f-80a8-ae69e4d1cd10, HIGH): «промпт-аудит» с детальными ПРОВЕРЕННЫМИ замечаниями. В карточке явно отмечено: «подозрение про check_tests_passed было ложным — гейт верный, НЕ трогать».
  • Запуск: навесила autoDeploy (label f04e2721-1f9b-469e-bd2b-d87e7c3b106f) → To Analyse → webhook start_pipeline → task, stage=analysis, analyst job 1069 running, ветка feature/ORCH-092-6-escalation. Идёт автономно.
  • Скрипт создания: temp/create_promptaudit.py (21469 байт).

📌 Состояние ORCH-задач на конец сессии (09.06 ~15:36 MSK)

  • ORCH-87 ✅ В ПРОДЕ (перепрогон на свежей базе успешен, сироты+эффорт+время+G6 закрыты).
  • ORCH-88 идёт (serial e2e gate, task 66, заведена утром).
  • ORCH-89 Backlog (переписана: автономность по лейблам autoApprove/autoDeploy).
  • ORCH-90 Backlog (STOP-механизм, HIGH).
  • ORCH-91 Backlog (баг словаря _STAGE_STATUS_LABEL: нет ключа deploy-staging→дефолт «To Analyse»).
  • ORCH-92 running (промпт-аудит, autoDeploy, analyst job 1069).

🔀 ORCH-72 → дубль (Cancelled), всё слито в ORCH-91 — баг карточки трекера, 3 дефекта (09.06 ~15:50 MSK)

  • Слава: «72 и 91 разберись, баг въедливый. Проанализируй таски/прод/логи/телегу, заверни всё в 91, 72 отмени как дубль».
  • Анализ обеих карточек Plane: оба — про ОДИН баг live-карточки трекера (ORCH-067). 72 старше (Слава 08.06), 91 свежее (09.06, мой детерминированный repro). ⚠️ 72 ШИРЕ — содержит 3 дефекта; 91 покрывал только дефект 1. Простое «отменить 72» потеряло бы дефекты 2/3 → слила ВСЁ в 91.
  • 3 дефекта (все верифицированы кодом/БД прода 09.06 — урок дня сработал):
    • Деф.1 (заголовок «To Analyse»): _STAGE_STATUS_LABEL (notifications.py:940) = 8 ключей, нет deploy-staging. Реальные stage = ключи STAGE_TRANSITIONS (src/stages.py): 9 шт, не покрыта РОВНО deploy-staging → .get(stage, _DEFAULT) → «To Analyse». Проверено программно: из 9 stage непокрыта одна (deploy-staging), но фолбэк-«To Analyse» = мина на будущее.
    • Деф.2 (откаты): при rollback стадии карточка не снимает ✅ с верхних стадий («Внедрение ✅, но идёт Разработка 🔄»). Требование: снимать ✅ после точки отката.
    • Деф.3 (метрики 💰🔢⏱, НЕ косметика): карточка берёт ПОСЛЕДНИЙ agent_run на стадию, теряя ретраи. Верифицировано на ORCH-069 (task 54): developer×3=$3.98, reviewer×3=$2.10, tester×2, deployer×2 — карточка показывала ~$0 за «Разработка», тотал занижен. Требование: Σ всех agent_runs по (task_id,agent) для $/токенов/времени.
  • Сделано (Plane): PATCH 091 desc (полное ТЗ, 3 дефекта, AC-1..7) + priority high (200); PATCH 072→Cancelled (200); коммент-трассировка на обе (201/201). На 091 уже висели лейблы autoApprove+autoDeploy → запустится автономно.
  • ⚠️ Источник истины stage = src/stages.py STAGE_TRANSITIONS (НЕ stage_engine — там нет такого атрибута). Реальные tasks.stage = его КЛЮЧИ: created/analysis/architecture/development/review/testing/deploy-staging/deploy/done.
  • Скрипты: temp/inspect_72_91.py, inspect3.py, merge_72_into_91.py.

🚀 ORCH-091 ЗАПУЩЕНА (Слава: «Погнали», 09.06 ~15:52 MSK)

  • Plane Backlog→To Analyse (PATCH 200) → webhook start_pipeline → task 77, analyst job 1111 queued, ветка feature/ORCH-091-bug-to-analyse-stage-deploy-st от свежего main.
  • Конвейер serial (max_concurrency=1, serial_gate ORCH-88 в проде): очередь = 063(developer running)→062(analyst q)→090(analyst q)→091(analyst q). Пойдёт по одной e2e.
  • ⚠️ 063 уже на development (job 1110), не architecture — продвинулась пока разбирала 72/91.
  • 091 несёт autoApprove+autoDeploy → пройдёт автономно (BRD сама подтвердит, прод сама задеплоит после тех-гейтов).
  • ⚠️ Хвост старых ET-задач (task 2,3,5,6,18,31) висит в analysis/development БЕЗ активных job — старые смоук-тесты, не наш конвейер, не трогаю (serial-gate их игнорит т.к. репо enduro≠orchestrator, либо это мусор для будущей чистки).

🚨→✅ ORCH-063 «deploy succeeded but not merged» — транзиент Gitea 405, домержила штатно (09.06 ~16:11 MSK)

  • Алерт: deploy прошёл, но main не получил коммит задачи → HOLD на deploy (защита ORCH-81). Слава: «А это?».
  • Корень (из docker logs orchestrator): merge_pr: PR #98: HTTP 405 {"message":"Please try again later"} — транзиентная ошибка Gitea (мерж временно недоступен, часто пока пересчитывается mergeable после пуша). НЕ конфликт, НЕ баг кода. Финализатор-актор one-shot (не ретраит мерж) → HOLD сработал корректно как защита (не пометил done вслепую).
  • Проверка: PR #98 = open, mergeable=True, конфликтов нет, транзиент давно прошёл. Безопасно домержить.
  • Фикс (штатно, не руками-через-API):
    1. merge_gate.merge_pr() повторно → merged PR #98, verify_merged_to_main=True, check_main_regression=True (markers intact 5). disk_watchdog.py в main ✅, нет unmerged-коммитов.
    2. stage_engine.run_deploy_finalizer({task_id:74}) идемпотентно → merge_pr=already-merged → CONFIRMED → deploy→done, Plane→Done→Monitoring after Deploy (post-deploy monitor job 1116 armed).
    3. Прибрала побочный PR #99 (финализатор создал т.к. #98 уже merged+closed, ensure_open_pr не нашёл открытого → создал пустой; closed).
  • ✅ ORCH-063 в проде, task done. disk-watchdog (мониторинг диска mva154 + Telegram-алерт ≥85%) задеплоен — особенно вовремя, диск был 89%.
  • ⚠️ УРОК / кандидат на follow-up: merge-актор финализатора НЕ ретраит транзиентные ошибки Gitea (405 "try again later") — one-shot → ложный HOLD при инфра-икоте Gitea, требует ручного домержа. Стоит добавить ретрай merge_pr на 405/5xx (как breaker у агентов) ИЛИ ensure_open_pr не создавать новый PR если ветка уже в main (PR #99 — мусор). Если повторится — завести ORCH-задачу.

📝 ORCH-93 заведена — merge-актор ретрай транзиентов Gitea (Слава: «заведи задачу да», 09.06 ~16:18 MSK)

  • Follow-up по инциденту 063 (Gitea 405 → ложный HOLD). seq=93, id=d4deab67-2f51-4c44-b4fd-ea103ec67a94, Backlog, MEDIUM.
  • 2 дефекта (верифицированы по src/merge_gate.py прода):
    • Деф.1: merge_pr (~685) one-shot — на 405/5xx/таймаут сразу return False, нет ретрая (у агентов breaker есть, у мержа нет). G1/G2: ретраить транзиенты (405/408/409-not-mergeable-yet/5xx) с backoff, НЕ ретраить реальный конфликт.
    • Деф.2: ensure_open_pr (~590) плодит пустой PR на уже влитой ветке (PR #99 сегодня). G3: гард «ветка уже в main» (нет diff origin/main..branch) → no-op «already-in-main».
  • AC-1..6 (ретрай 405×2→200, не-ретрай конфликта, HOLD при исчерпании, already-in-main, kill-switch, never-raise+зелёный pytest). Зацепки: check_ci_green как образец ретрая, config флаги ORCH_MERGE_RETRY_*.
  • Не-цель: НЕ убирать защиту ORCH-81 (корректна), не ретраить реальный конфликт, INV-4 (только Gitea API, не push main).
  • Запуск по решению Славы. Скрипт: temp/create_merge_retry.py.

🚀 ORCH-93 запущена + ⏸️ очередь упёрлась в ORCH-062 (ждёт ручной approve) (09.06 ~16:27 MSK)

  • Слава: «Да, навесь, и в работу отдай» (про 93). Навесила autoApprove+autoDeploy (200) → To Analyse (200) → task 78, analyst job 1132 queued, ветка feature/ORCH-093-bug-merge-gitea-405-5xx-hold-p.
  • Очередь serial (max_concurrency=1): 062(In Review)→091(Analysis,q)→090(Analysis,q)→093(Analysis,q). НИ ОДНА не running.
  • ⚠️ Затык: ORCH-062 analyst отработал (run 490, BRD готов), brd_review_started_at стоит, ended_at=None → In Review, ждёт РУЧНОГО approve. У 062 НЕТ autoApprove → ждёт Славу. 062 первая в serial → держит 091/093 (у них autoApprove, но serial-gate не пускает их analyst пока 062 не done/вперёд).
  • 091/093 — автономные (autoApprove+autoDeploy), 090 — проверить лейблы. Решение по 062 — за Славой: либо заапрувить BRD 062 вручную, либо навесить autoApprove чтобы пошла сама.

✅ ORCH-062 BRD APPROVED (Слава: «Проверь и аппрувь», 09.06 ~16:30 MSK) — очередь разморожена

  • Проверила BRD/ТЗ/AC (task 75): ЭТАЛОН. Аналитик грамотно разграничил 062↔063 (watchdog сигналит / pruner убирает, НЕ дублирует), жёстко зафиксировал self-hosting безопасность (строго docker builder prune, запрет system/image prune + рестарта прода), развилку реализации A(демон)/B(daemon.json)/C(cron) отдал архитектору — верно.
  • Верифицировала кодом: disk_watchdog.py (образец) В main ✅; docker.sock доступен (root:999, контейнер в gid 999, A-1 верно); build cache сейчас 330МБ (после моих чисток), в инцидент рос до 11ГБ — P1 обоснован.
  • Закрыла brd-clock (UPDATE brd_review_ended_at, как штатный approve — урок G5 ORCH-87, чтобы время не раздувалось) → PATCH In Review→Approved (200) → webhook → architect job 1138 running, stage=architecture.
  • Очередь разморожена: 062 держала serial (была In Review без autoApprove). Теперь 062(arch running)→091→090→093 поедут по одной. 062 без autoDeploy → на прод-деплое снова спросит Славу (BRD заапрувлен вручную, деплой тоже будет ручной — если надо автономно, навесить autoDeploy).

🐛 ORCH-094 заведена — терминальная done-задача флаппит deploy-статусы (Слава: «синхронизируй, если опять слетит — баг», 09.06 ~16:48 MSK)

  • Контекст: Слава просил sync ORCH-061→Done. Сделала PATCH→Done (200, 16:47) → через ~60 сек СЛЕТЕЛО обратно Done→Awaiting→Monitoring (16:48). Условие «опять слетит → баг» выполнено.
  • Диагностика (живьём):
    • ORCH-061 task47 БД=done с 07.06, 0 активных jobs. Реально в проде.
    • Plane флаппит Monitoring⟷Awaiting парами, 273 активности, actor=daf4d3f4 (bot-токен орка).
    • В момент флаппа лог орка = только ВХОДЯЩИЕ webhooks «no pipeline action» → орк ПОЛУЧАЕТ переходы, не шлёт. Источник внешний.
    • Активный pdm только у 063 (task74), у 061 нет. orchestrator-staging (8501) — НЕ источник (нет task 061 в его БД). Reconciler 061 не упоминает.
    • Источник под bot-токеном, не привязан к активной task/job — «зомби»-таймер/sweeper/Plane-automation. Нужен инструментальный поиск в коде.
  • ORCH-094 seq=94 id=28466feb-3802-4dd8-9a8f-fe47eae7c1d6, Backlog, MEDIUM. Гипотезы H1-H4 (зомби-таймер pdm/конкурирующие статус-пути/reconciler-маятник/цикл по живому Plane-статусу config.py:602). G1-G4, AC-1..5 (done держит Done ≥10мин, идемпотентный sync, pdm детерминированно завершается без таймера). Зацепки: post_deploy.py, stage_engine.py:396 run_post_deploy_monitor, plane_sync.py terminal-skip ORCH-068/086, config.py:602.
  • Родственник ORCH-091 (врущие статусы). Скрипт: temp/create_flap_bug.py.

✅ ORCH-090 BRD APPROVED (Слава: «проверь все ли ок и запускай», 09.06 ~17:23 MSK) — STOP-механизм

  • Проверила BRD/ТЗ/AC (task 76, ветка feature/ORCH-090-stop-plane): ЭТАЛОН, самая системная задача дня. Аналитик опирается строго на реальный код, 7 архитектурных развилок честно вынесены в OQ-1..7, поймана тонкость BR-4/OQ-7 (закрытие дыры релонча может сломать легитимный resume после Needs Input).
  • Верифицировала кодом (урок дня):
    • Дыра релонча РЕАЛЬНА: handle_status_start (plane.py:264) if has_active_job_for_task иначе enqueue_job(stage_agent) стр.288 — ручной перевод в рабочий статус релончит стадийного агента. ✅
    • SIGTERM-каскад _watchdog (launcher.py:661-687, ORCH-7) есть, переиспользуется. ✅
    • _PLANE_NAME_TO_KEY: Cancelled→cancelled (141), терминал-скип done/cancelled (reconciler.py:196). STOP-имени нет — верно. ✅
    • jobs.status УЖЕ содержит 'cancelled' (по факту в БД!) → OQ-2 имеет готовый вариант. ✅
  • Закрыла 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. НЕ заводила задачи (концепция первая).

🧬→v2 Концепция эпика ПЕРЕСМОТРЕНА (Слава: «беру твоё предложение за основу + рост фич очень нужен», 09.06 ~19:02 MSK)

  • Слава попросил критику моей же схемы → дала честную (пересечения модулей, наблюдаемость зря в M1, M0=мозг недооценён, нет оси КАЧЕСТВА). Слава: берём за основу, НО саморазвитие — не только стабильность/качество, рост фич равноценен.
  • Переписала документ v2 (структура: фундамент + 5 доменов + 2 вертикали):
    • Фундамент (слой 0): F1 наблюдаемость (ORCH-83) + F2 журнал уроков (ORCH-8 шаг1).
    • 5 доменов (равноценны, «две руки роста»): D1 Надёжность / D2 Качество-Доверие (НОВЫЙ — надёжная платформа ≠ корректный результат) / D3 Экономика / D4 Возможности-фичи (равноценный, акцент Славы — не второй эшелон!) / D5 Масштаб.
    • 2 вертикали сквозь всё: Двигатель (петля ORCH-8) + Тормоз (governance/safety L0-L3).
    • Градусник автономности — сквозная метрика.
  • Ключевая правка Славы: D4 (Android/UX-UI/интерактив-аналитик/тяжёлые расчёты/стеки-плагины/база знаний) + D5 — РАВНОЦЕННЫ надёжности, параллельно, не после. «Стабильная платформа без роста = тупик».
  • 7 вопросов Славе. Документ: EPIC_AUTONOMOUS_SELF_EVOLUTION.md (v2, 12.8КБ). Ждёт финального апрува → декомпозиция.

🧬→v3 Концепция: добавлен ГЕНЕРАТОР ИДЕЙ роста (Слава: «нужен ещё источник для новых идей развития функционала, не только требования от меня», 09.06 ~19:32 MSK)

  • Слава нащупал асимметрию двигателя: реактивная петля (уроки=боли) кормит «крепнем» (D1-D3), но «растём» (D4 фичи) питался ТОЛЬКО Славой = бутылочное горлышко.
  • Переделала вертикаль-двигатель в ДВЕ турбины:
    • 8A Реактивная 🔄 — петля самообучения из уроков (ORCH-8): детекция→журнал→анализ→предложение. Кормит надёжность/качество/экономику.
    • 8B Проактивная 💡 — ГЕНЕРАТОР ИДЕЙ новых возможностей (НОВОЕ). Источники I1-I7: гэпы реализации проектов (enduro/snowbike — что было тяжело), паттерны ручного труда вне платформы, тренды/новые технологии (web-скан моделей/стеков), конкурентный анализ (Devin/Cursor/Copilot), анализ своего бэклога/истории, обратная связь заказчиков, саморефлексия Стрим. Компоненты: E4 агент-идеатор (product-discovery), E5 банк идей (отдельно от журнала уроков).
    • 8C E3 приоритизатор RICE сводит ОБА потока в единый ранжированный бэклог, баланс «крепнем vs растём» — настраиваемая квота слотов.
  • Документ EPIC_AUTONOMOUS_SELF_EVOLUTION.md обновлён до v3. Добавлен вопрос 8 (какие источники идей ценнее, генерить автономно или по запросу). Ждёт апрува → декомпозиция.

🐛 КОРЕНЬ найден: карточка трекера застывает из-за HTML-инъекции «<1м» (Слава: «карточка не обновляется, на 93й застряла, по 91 нету», 09.06 ~19:42 MSK)

  • Симптом: карточка 93 застряла, 91 «пропала». Задачи в БД: 090 done(prod), 091 done(prod), 093 review. У всех свой tracker_message_id (90→18817, 91→18851, 93→18854).
  • Диагностика edit_telegram по каждой: 90/91 → OK (я их руками обновила, теперь актуальны), 93 → FAILED.
  • КОРЕНЬ (сырой ответ Telegram): 400 Bad Request: can't parse entities: Unsupported start tag "1м" at byte offset 500. На позиции 379 текста карточки 93: <1м · тв... — длительность стадии «меньше 1 минуты» отрендерена как <1м. parse_mode=HTML видит <1м как открывающий тег → 400 → editMessageText падает → карточка ЗАСТЫВАЕТ на стейте где впервые появилось <1м.
  • Это баг рендера render_task_tracker (notifications.py:355): длительность «<1м» НЕ экранируется (нужно <→&lt; / html.escape). Родственник ORCH-91/87. Ловится ТОЛЬКО когда стадия <1 мин → проявляется не всегда (поэтому 90/91 пронесло, у них не было <1м на момент edit).
  • ⚠️ 93 ещё в работе (review) → каждое обновление с «<1м» будет падать снова, пока не пофиксят рендер. Нужен КОД-фикс (html.escape всех динамических значений в карточке), не только ручной редроп.
  • Действия: 91/90 карточки обновила вручную (edit OK). Завожу баг на html-экранирование рендера.

🚀 ORCH-95 заведена в авторежиме (Слава: «заводи багу в авторежиме», 09.06 ~19:46 MSK)

⏸️ ОТЛОЖЕНО (Слава: «пока забей, ещё увижу скажу», 09.06 ~20:11 MSK): баг отображения модели в карточке

  • Карточка показывает haiku-4-5 вместо opus-4-8. КОРЕНЬ: usage.py:95 _extract_model выбирает из modelUsage ключ с макс outputTokens. На лёгкой analyst-задаче (ORCH-094) opus сгенерил мало, haiku (служебная модель Claude CLI) больше → эвристика выбрала haiku. Работал РЕАЛЬНО opus-4-8 ($2.51 честный), баг ТОЛЬКО отображения.
  • Фикс-кандидат: исключать служебные модели (haiku-*) ИЛИ выбирать по cost/сумме токенов ИЛИ самую дорогую. Родственник трекер-багов 067/087/091/095.
  • НЕ заводила по просьбе Славы — ждёт его сигнала. Когда скажет — завести (вероятно авторежим HIGH).
  • Открытый вопрос структуры Plane: остановились на ЛЕЙБЛАХ-namespace (домен D1-D5/F + вертикаль V-engine/V-governance + epic:self-evolution), Modules выключены в проекте. Ждём решения Славы: лейблы + включать ли Modules для UI-обзора.

✅ Структура эпика саморазвития ЗАВЕДЕНА в Plane (Слава: «go», 09.06 ~20:40 MSK)

  • Решение: домены→МОДУЛИ Plane (1 задача=1 модуль), вертикали→ЛЕЙБЛЫ (мало). Slug в external_id (орк ищет по нему), name с эмодзи для человека.
  • 7 модулей созданы (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
  • 2 вертикали-лейбла: engine (36f398f7-5a1c-4eeb-847a-56c457e1da6b), governance (9eea4dd8-0fe7-473a-8c40-630fc3ab0d25). + autoApprove/autoDeploy (ортогональны).
  • Правило раскладки: задача = 1 модуль-домен (по slug external_id) + 0..N вертикаль-лейблов. Орк привязывает по external_id, НЕ по русскому имени (устойчиво к переименованию).
  • ⚠️ Plane API игнорит sort_order на запись (только drag-and-drop UI) → порядок модулей сейчас перевёрнут (Масштаб сверху). Славе поправить мышкой. На машинную логику не влияет.
  • external_source='orch-self-evolution' у всех модулей. Скрипт: temp/create_modules.py.
  • Концепция обновлена: раздел «Реализация в Plane» с module_id/slug. Документ EPIC_AUTONOMOUS_SELF_EVOLUTION.md.

✅ Модули переименованы (цифра) + backlog разнесён по доменам (Слава: «добавь цифру + разноси задачи», 09.06 ~20:47 MSK)

  • Plane sort_order через API не двигается, перетаскивание неудобно → цифра в начале name: «0 · 👁️ Фундамент» … «6 · 📈 Масштаб». Теперь и порядок (алфавитно по цифре), и категория видна.
  • 23 backlog-задачи разнесены по модулям (привязка external_id→module-issues, все HTTP 200):
    • 1 brain 🧠: ORCH-8 (петля самообучения)
    • 0 foundation 👁️: ORCH-83 (наблюдаемость), 56 (realtime-уведомления), 95 (html-трекер)
    • 2 reliability 🛡️: ORCH-57 (root-файлы), 93 (merge-ретрай), 94 (флапп-статус)
    • 3 quality ✅: ORCH-27 (coverage), 28 (человек-приёмка)
    • 4 economy 💰: ORCH-19 (дешёвый трек), 20 (оценка), 23 (бюджет-breaker), 38 (токены)
    • 5 features 🚀: ORCH-11 (доки), 12 (тяжёлые расчёты), 13 (мультипровайдер), 14 (UX/UI), 15 (Android), 18 (интерактив-аналитик), 24 (база знаний), 25 (декомпозиция эпиков)
    • 6 scale 📈: ORCH-9 (онбординг), 10 (тиражирование)
  • Backlog-задач БЕЗ модуля не осталось — весь релевантный backlog классифицирован.
  • Вертикали-лейблы (engine/governance) пока не вешала на конкретные задачи — это следующий шаг (большинство существующих backlog не от петли/идеатора, а ручные постановки Славы → вертикаль им не обязательна; вешать engine на будущие авто-сгенерённые).
  • Скрипт: temp/rename_and_assign.py.

✅ ORCH-094 фикс флаппинга ПОДТВЕРЖДЁН БОЕМ на 4 задачах (09.06 ~20:57 MSK)

  • 094 задеплоена → выровняла застрявшие в deploy-статусах задачи в Done: 036, 059, 061 (Слава: «да - 36 59 61»). Все в БД давно done.
  • Plane: 036 Deploying→Done, 059 Deploying→Done, 061 Monitoring→Done. Проверка ~2 мин: ВСЕ держатся, 0 авто-переходов (раньше 061 слетала за 60 сек).
  • Фикс 094 работает СИСТЕМНО: терминальные done-задачи держат Done, флапп Awaiting↔Monitoring мёртв для всех залипших. Доска чистая.
  • Историческая ирония: задача про застревающие статусы (094) стабилизировала свой же статус + вычистила 036/059/061.

🏗️ ФУНДАМЕНТ эпика — первые 3 задачи заведены (Слава: «начинаем с фундамента, заводи задачи», 09.06 ~21:00 MSK)

  • Стартуем эпик саморазвития с домена 0 Фундамент. Привязаны к модулю foundation (74dee25a).
  • ORCH-96 [HIGH] FND: сбор метрик наблюдаемости (agent-liveness/очередь/стадии/хост/контейнеры/деп). Бывш. ORCH-83a. Расширить /status или /metrics, leaf-модуль по образцу disk_watchdog, read-only never-raise. Триггер: завис analyst 81 (лезли в /proc), диск 93%, merge-HOLD молча.
  • ORCH-97 [HIGH] FND: алертинг (пороги+Telegram+дедуп: диск/память/агент-завис/job-failed/застрявшая-стадия/контейнер-down/деп). Бывш. ORCH-83b. ЗАВИСИТ от 96. Не дублировать disk_watchdog-алерт.
  • ORCH-98 [HIGH] FND: машинный журнал уроков (ORCH-8 шаг1, F2). Аддитивная таблица lessons в БД, автодетект 2-3 типов отклонений + ручная запись + выборка. Топливо петли/приоритизатора. НЕ путать с банком идей (D4).
  • ⚠️ ORCH-83 (родительский эпик наблюдаемости) и ORCH-8 (петля) остаются как зонтики; 96/97 = реализация 83a/83b, 98 = реализация ORCH-8 шаг1.
  • Лейблы/авторежим пока НЕ навешивала — жду решения Славы: запускать фундамент в авторежиме (autoApprove+autoDeploy) и в каком порядке (96→97 цепочка, 98 параллельно).
  • Скрипт: temp/create_foundation_tasks.py.

🏗️ Фундамент ПЕРЕСОБРАН под sidecar-модель + концепция в репо (Слава: «sidecar в репо орка можно; A/без плеча/тонкий», 09.06 ~21:53 UTC)

  • Архрамки наблюдаемости (решены Славой): наблюдатель ОТДЕЛЁН от наблюдаемого. C-1 sidecar-контейнер на хосте; C-1б КОД sidecar В РЕПО орка (папка watchdog/), рантайм = ОТДЕЛЬНЫЙ контейнер (свой Dockerfile + сервис orchestrator-watchdog в compose); C-2 без внешнего плеча; C-3 тонкий стек (НЕ Grafana — хост впритык: RAM 171Mi free, диск 92%). Орк отдаёт только сырьё (/metrics), sidecar = мозг (пороги/алерты/свой Telegram-канал).
  • Концепция положена В РЕПО орка: docs/epics/self-evolution.md (commit 9c522e9f, main). Теперь аналитик её видит (Filesystem-доступ к репо). Урок: мой workspace-файл агенты НЕ видят — контекст эпика обязан жить в репо.
  • Задачи пересобраны: ORCH-96/97 (внутри-орка модель) → Cancelled. Заведены:
    • ORCH-99 [HIGH] F1a: лёгкий /metrics в орке (стадии/очередь/agent-liveness/cost) — ВНУТРИ орка, только сырьё, read-only never-raise. Блокирует F1b.
    • ORCH-100 [HIGH] F1b: sidecar-watchdog (watchdog/ в репо, отдельный контейнер) — сбор хост/контейнеры/деп + алертинг своим Telegram. Зависит от F1a. Орк-down → репортит.
    • ORCH-98 журнал уроков (F2) — обновлён ссылкой на концепцию.
  • У всех 3 в описании: ссылка на docs/epics/self-evolution.md + архрамки.
  • Скрипты: temp/rebuild_foundation.py, create_foundation_tasks.py.
Reference in New Issue View Git Blame Copy Permalink