Files
wiki/memory/2026-06-10.md
2026-06-10 22:00:01 +03:00

27 KiB
Raw Permalink Blame History

2026-06-10

ORCH-100 (F1b sidecar-watchdog) BRD APPROVED (Слава: «проверь и если ок подтверждай», 05:41 UTC)

  • Первая задача эпика саморазвития, прошедшая аналитику. BRD/ТЗ/AC — ЭТАЛОН.
  • Аналитик ПРОЧИТАЛ концепцию из репо (docs/epics/self-evolution.md) и идеально усвоил архрамки: C-1 sidecar отдельный контейнер / код в репо watchdog/ / C-2 без плеча / C-3 тонкий не-Grafana / свой Telegram-канал / read-only docker.sock / орк-down=тревога. → подтвердило: класть концепцию в репо было правильным решением.
  • Верифицировала кодом (урок дня):
    • F1a /metrics РЕАЛЬНО в проде (ORCH-099 done, HTTP 200, конверт schema_version:1/generated_at/clk_tck:100/stages/queue/agents/cost — точно как в ТЗ). Контракт под F1b работает.
    • disk_watchdog.decide_action (src:105) — образец решающей функции реален (ТЗ звал 'decide', факт 'decide_action' — по сути верно).
    • watchdog/ папки ещё нет — верно, F1b создаёт.
  • Аналитик грамотно: анти-дубль диск-алерта с ORCH-063 (BR-10/FR-9/AC-5, тонкость!), вынес в зону архитектора стек Python/Go + владельца диск-алерта + mem_limit + топологию сети. 14 TC, 7 AC.
  • Закрыла brd-clock → Approved (200) → architect job 1526 running, stage=architecture, ветка feature/ORCH-100-fnd-f1b-sidecar-watchdog. autoApprove? нет — был ручной approve Славы (на 100 не вешали autoApprove, только запускали F1a в авто). Идёт автономно дальше (autoDeploy если был навешен).

🎯 Концепция: скоуп наблюдения (3 слоя) + атрибуция уроков (Слава 10.06 06:01)

  • Вопрос Славы: F1a/F1b мониторят только орк, или проекты (ET-контейнер) тоже? + саморазвитие может катить ET: фича в ET деградировала ET — это орк недоработал процесс или в ET усилить тесты?
  • Вписала в концепцию (docs/epics/self-evolution.md, обновлён в репо):
    • Скоп наблюдения 3 слоя: Слой1 проекты как ЗАДАЧИ в конвейере (ET в /metrics stages) — в скопе F1a/F1b (здоровье конвейера). Слой2 проекты как КОНТЕЙНЕРЫ на хосте (enduro-app через docker.sock) — в скопе F1b (жив/мёртв, общий хост впритык). Слой3 ВНУТРЕННЕЕ бизнес-здоровье продукта (эндпоинты ET 200? latency?) — НЕ фундамент, это мониторинг ПРОДУКТА = будущая фича D4/D5 (per-project health, опция заказчику).
    • Атрибуция уроков (новый шаг петли 8A): деградация продукта после фичи → петля различает: А) platform-level (орк недоработал ПРОЦЕСС — нет регресс-гейта/перф-бенчмарка → чинить в D1/D2, польза ВСЕМ) vs Б) project-level (в ET мало тестов → усилить тесты в бэклоге ET, польза только ET). Бывает ОБА. Без слоя-3 детекции петле нечего атрибутировать → слой3 нужен и петле, не только заказчику. E2-ретроспективщик несёт классификацию, спорное → Стрим/Слава.
  • Commit в main. Аналитик увидит свежую версию.

🚀 ORCH-98 (F2 журнал уроков) ЗАПУЩЕНА в авто (Слава: «запускаем, учти выводы, авто», 06:18 UTC)

  • Перед запуском УЧЛА выводы обсуждения: дописала в ТЗ ОБЯЗАТЕЛЬНОЕ поле атрибуции в схему журнала с самого начала (иначе переделывать):
    • attribution: platform-level / project-level / both / unknown (нуллабельно — классификацию позже ставит ретроспективщик/Стрим, но КОЛОНКИ сразу).
    • проект/repo (кого касается), целевой домен (slug модуля D1-D5).
    • связь со слоем-3 детекции (деградация продукта = тип урока).
  • autoApprove+autoDeploy, HIGH → task 86, analyst job 1528 queued, ветка feature/ORCH-098-fnd.
  • ⚠️ F1b (ORCH-100) уже на developer (job 1531 running) — architect отработал, sidecar-код пишется. Очередь serial: 100(dev)→98(analyst).
  • Фундамент: F1a done · F1b 🔵 developer · F2 🔵 queued. Все 3 кирпича в движении.
  • Скрипт: temp/launch_f2.py.

ORCH-100 (F1b sidecar-watchdog) В ПРОДЕ — КОД (Слава: «проверь и подтверждай», 06:57 UTC)

  • Проверила перед Confirm: reviewer APPROVED, tester PASS (66 поставочных + 1617 регресс зелёный, src/ НЕ тронут байт-в-байт). watchdog/ создан (Dockerfile/main/core/config/collectors), отдельный сервис orchestrator-watchdog в compose, network_mode host, docker.sock:ro, mem_limit 128m, kill-switch WATCHDOG_ENABLED.
  • Ключевая проверка безопасности: deploy-hook поднимает только $TARGET_SERVICE (orchestrator) с явным именем up -d --no-build → Confirm Deploy перезапускает ТОЛЬКО орк, watchdog НЕ трогает. Confirm = мёрж кода watchdog/ в main + рестарт орка. Безопасно.
  • Confirm Deploy (200) → deploy→done, merge-verify CONFIRMED сам (watchdog/ в main YES, орк health 200), Monitoring after Deploy (post-deploy job 1536).
  • ⚠️ ОСТАЁТСЯ РУЧНОЙ ИНФРА-ШАГ (Слава/Стрим на хосте) — sidecar ЕЩЁ НЕ ЗАПУЩЕН как контейнер:
    1. Создать ОТДЕЛЬНОГО Telegram-бота watchdog + chat-id → положить WATCHDOG_TG_BOT_TOKEN/CHAT_ID в .env.watchdog на хосте.
    2. Заполнить пороги (дефолты годятся), WATCHDOG_ENABLED=true.
    3. docker compose up -d --build orchestrator-watchdog (ТОЛЬКО этот сервис, НЕ трогать орк!).
    4. Проверка: docker logs orchestrator-watchdog (старт+тики), тестовый алерт, на staging остановка орка → orch_down.
  • Анти-дубль диска: WATCHDOG_DISK_CRIT_ENABLED=false дефолт (85%-алерт остаётся за disk_watchdog ORCH-063).
  • Фундамент: F1a · F1b КОД в проде (контейнер ждёт ручного старта) · F2 🔵 в работе (analyst).

🚀 Sidecar-watchdog ПОДНЯТ боем (Слава: «Поднимай», 08:46 UTC)

  • Создан /home/slin/repos/orchestrator/.env.watchdog (канон из .env.example + chat_id=126472752, токен ПУСТ fail-safe). WATCHDOG_CONTAINERS расширен: orchestrator,orchestrator-staging,gitea,enduro-trails-app-1,plane-app-api-1,plane-app-plane-db-1.
  • docker compose up -d --build orchestrator-watchdog (ТОЛЬКО watchdog) → собрался, Up. Орк НЕ задет (health 200).
  • Память 17.7/128 MiB — тонкий, как задумано. Тики каждые 30s, demon живёт.
  • 🔥 Sidecar сразу поймал мёртвый хвост ET (stage_stuck ET-001/003/004/010/013 — смоук-тесты в analysis ~20 дней). Наблюдаемость работает боем.
  • ⚠️ Алерты НЕ шлются: telegram token/chat not configured -> skip send (нет своего бота, BR-8 — свой канал не токен орка). chat_id прописан, нужен ТОЛЬКО токен отдельного бота от Славы (@BotFather /newbot → токен → впишу в .env.watchdog → рестарт watchdog).
  • Фундамент: F1a · F1b КОД в проде + КОНТЕЙНЕР ПОДНЯТ (молчит без бота) · F2 🔵 в работе.
  • ⚠️ Прод main HEAD b915503 — после рестарта орк подтянул; origin af949af (чуть впереди — проверить рассинхрон позже, орк жив).

🐶 Sidecar боевой + ET-хвост вычищен полностью (Слава: токен бота + /start + «1 вар», 10:25 UTC)

  • Бот @orch_assistant_bot (id 8216920640), Слава нажал /start → тестовый send OK (chat 126472752, SlavaMel). Канал watchdog активен.
  • ⚠️ Грабли: токен в shell-переменной обрезался (404), брать через grep WATCHDOG_TG_BOT_TOKEN .env.watchdog | cut -d= -f2 — len 46. Прямой sendMessage с этим токеном → ok:true.
  • ET-хвост вычищен (вариант 1 — завершить заброшенные):
    • task 2/3/5/6 — смоук-тесты (plane_issue_id=None) → stage=done.
    • task 18 (ET-010), 31 (ET-013) — заброшенные реальные (Backlog в Plane) → stage=done в БД орка по решению Славы.
    • Итого: tasks WHERE stage!='done' = ПУСТО. /metrics stages=0. watchdog tick fired=[] чисто.
  • ФУНДАМЕНТ ЭПИКА ЗАКРЫТ: F1a /metrics · F1b sidecar в проде+боевой (18MiB, свой бот, алертит) · F2 журнал уроков 🔵 в работе (последний кирпич, идёт автономно).
  • watchdog .env: /home/slin/repos/orchestrator/.env.watchdog (токен+chat+пороги). Контейнер orchestrator-watchdog, network_mode host, docker.sock:ro, mem_limit 128m, WATCHDOG_ENABLED=true.
  • Следующий домен — по решению Славы (D1 Надёжность / D3 Экономика / D4 Возможности / D5 Масштаб).

🆕🔥 ORCH-9 (онбординг проектов) запущена на FABLE-5 МАКСИМАЛКИ (Слава: «го, max важным, xhigh попроще», 11:33 UTC)

  • Fable-5 доступна через claude CLI — правильный id claude-fable-5 (не fable/fable-5/snapshot-дата). CLI 2.1.168. --effort поддерживается. Новейший топ Anthropic (выше opus-4-8, «included until June 22» — промо-дедлайн).
  • ORCH-9 актуализирована (PATCH 200): эталон=САМ orchestrator (docs/_templates 18 шаблонов + docs/_standards HANDOFF/PIPELINE/TRACEABILITY + 6 промптов агентов в .openclaw/agents + ADR канон). enduro-trails БОЛЬШЕ НЕ эталон (устарел). Дыра «только deployer.md» — ЗАКРЫТА (6 промптов на месте). Домен 6 Масштаб (D5).
  • Env прода (временно, ОТКАТ: /home/slin/repos/orchestrator/.env.bak-fable5-20260610-143425):
    • ORCH_AGENT_MODEL_DEFAULT=claude-fable-5, ORCH_AGENT_FALLBACK_MODEL=claude-opus-4-8 (страховка после June 22).
    • effort: analyst/architect/developer/reviewer=max, tester/deployer=xhigh, default=high.
    • Резолв подтверждён боем (resolve_agent_model/effort): все 6 агентов = claude-fable-5 с нужным эффортом.
  • Рестарт ТОЛЬКО орк (очередь была пуста, F2 done), health 200.
  • Запуск: autoApprove+autoDeploy → task 87, analyst job 1607 running, ветка feature/ORCH-009-turnkey-plane.
  • ⚠️ ПОСЛЕ прогона ORCH-9 — ВЕРНУТЬ модель на opus-4-8 (откат из .env.bak или убрать ORCH_AGENT_MODEL_DEFAULT + рестарт орк). Глобальный override = fable-5 на ВСЕХ задачах пока не откатить. Следить за cost через /metrics.
  • ORCH-10 (тиражирование) ждёт решений Славы по 2 развилкам (stateless/stateful + bundled/external). ORCH-11 (доки) — НЕ гнать, ждёт 9/10/8.

📦 ЭПИК ORCH-10 (тираж платформы) оформлен + запущен 10-common (Слава: «формируй таски, BRD на согласование, деплой авто», 12:11 UTC)

  • ORCH-10 переоформлена в ЭПИК-зонтик «Тираж платформы (2 типа: Lite + Bundled, stateless)», модуль 6 Масштаб. Цель: раздать ТЕКУЩУЮ функциональность нескольким заказчикам НА ТЕСТ. Оба типа stateless (наши задачи/данные не переносим).
  • 3 под-задачи (модуль scale, лейбл autoDeploy, БЕЗ autoApprove — BRD апрувит Слава):
    • ORCH-101 [HIGH] 10-common: расхардкод (вынести IP 82.22.50.71/пути /home/slin/repos/порты/gid 999/URL в env) + секреты (генерация новых не копирование) + smoke. БЛОКИРУЕТ 10a/10b. Самая мясная (аудит хардкодов по всему репо).
    • ORCH-102 [HIGH] 10a Lite: перенос орк+watchdog + ПОЛНАЯ инструкция docs/deployment/LITE_SETUP.md (Plane/Gitea/LLM/Telegram донастройка пошагово). Зависит от 101.
    • ORCH-103 [MED] 10b Bundled: весь стек одним комплектом + bootstrap-скрипт + BUNDLED_SETUP.md. Зависит от 101.
  • Порядок: 101 → 102 → 103. Режим: BRD на согласование (Слава) + autoDeploy.
  • ORCH-101 запущена → task 88, analyst queued за ORCH-9 (serial). На FABLE-5/max (env ещё не откатан!).
  • ORCH-11 (доки) — НЕ трогаем, ждёт 9/10/8.
  • ⚠️ fable-5 cost ORCH-9 пока: analyst $2.82, architect $2.86+$1.23 (max). ORCH-9 долетела до review, developer бежит.
  • Скрипт: temp/create_orch10_epic.py.

🔥 РЕШЕНИЕ: весь эпик ORCH-10 на FABLE-5 (Слава 12:19 UTC)

  • Откат на opus ПРИДЕРЖАН до конца эпика ORCH-10. fable-5 активен глобально → 101/102/103 все пройдут на fable-5/max автоматически. НЕ откатывать env раньше завершения всего эпика тиража.
  • Откат остаётся готов: .env.bak-fable5-20260610-143425. Следить за cost через /metrics + agent_runs.
  • Напоминание: после ORCH-103 (последняя в эпике) — вернуть ORCH_AGENT_MODEL_DEFAULT на opus-4-8 (или решить оставить fable, если до June 22 и нравится).

⚠️ ORCH-9 застряла на CI-gate (transient), разблокировала (Слава: «что там», 14:14 UTC)

  • Карточка показала откат Code-Review→Development + cost скачок $10→$16.83. Разбор:
    • merge-gate: rebase на свежий main + re-test → check_branch_mergeable FAILED («re-test failed after rebase»), в выводе мелькнул pre-existing Pydantic V2 deprecation (config.py:8). Откат deploy-staging→development, developer переделал (job 1615).
    • После developer: check_ci_green not passed «CI still pending after 120s» — CI не успел за окно 120с → задача замерла в development БЕЗ следующего job. reconciler НЕ подхватил → застряла на ~1 час.
  • Корень: transient — CI дозеленел ПОСЛЕ окна проверки. Реальный CI статус ветки = success (проверила Gitea API). Код задачи ни при чём.
  • Фикс штатный: advance_stage(87,'development',...,finished_agent='developer') → check_ci_green=passed (CI green) → development→review, reviewer job 1616. Конвейер пошёл.
  • cost ORCH-9 на момент: $18.52 (fable-5/max, с учётом передоработки developer×2 + откат).
  • ⚠️ УРОК/кандидат: check_ci_green тайм-аут 120с мал для fable-5 (медленнее) ИЛИ нет авто-реэнквела когда CI дозеленел после окна → задача виснет, reconciler не ловит этот кейс. Родственник транзиент-резилентности (D1.3). Если повторится на 101/102/103 — завести.

📌📌 ФИНАЛЬНАЯ СХЕМА МОДЕЛЕЙ+ЭФФОРТОВ (Слава согласовал 16:52 UTC) — ДЕФОЛТ платформы

  • analyst=fable-5/MAX, architect=fable-5/MAX, developer=fable-5/XHIGH, reviewer=fable-5/XHIGH, tester=opus-4-8/medium, deployer=opus-4-8/medium.
  • Резолв подтверждён боем. Логика: глубоко думающие (постановка/архитектура)=max; исполнение/проверка (код/ревью)=xhigh (экономия лимита, developer самый токеножорный); механика (тесты/деплой)=надёжный opus/medium.
  • ORCH-9 (онбординг проектов) В ПРОДЕ (done) — первая задача на гибридной схеме fable+opus. Хвост дожат на opus после ресета лимита. post-deploy-monitor armed (job 1627).

📌 (история) СХЕМА МОДЕЛЕЙ (Слава голосом 16:44 UTC) — ДЕФОЛТ для последующих задач

  • Думающие этапы → FABLE-5/max: analyst, architect, developer, reviewer.
  • Тестирование + внедрение → OPUS-4-8/medium: tester, deployer.
  • Применять для ВСЕХ последующих задач (не разовый прогон). Env прода уже так настроен:
    • ORCH_AGENT_MODEL_DEFAULT=claude-fable-5 (думающие наследуют), ORCH_AGENT_FALLBACK_MODEL=claude-opus-4-8
    • ORCH_AGENT_MODEL_TESTER=claude-opus-4-8, ORCH_AGENT_MODEL_DEPLOYER=claude-opus-4-8, эффорт tester/deployer=medium
    • эффорты думающих: analyst/architect/developer/reviewer=max
  • Логика: топ-модель на постановку/код/ревью, дешёвая надёжная opus на механический прогон тестов/деплой → экономия лимита Claude Max (session limit общий на подписку) + денег. Это model-routing D3.
  • ⚠️ Это БОЛЬШЕ НЕ «временный прогон fable» — стало штатной схемой. Откат .env.bak-fable5-* теряет смысл как «вернуть всё на opus»; новая норма = гибрид. Бэкап оставить на всякий.

💾 Анализ диска mva154 (Слава голосом 16:49 UTC, через installer ssh_exec read-only)

  • Диск КРИТИЧНО: 96% (108G/118G, свободно 5.2G). /home/slin = 75G (главный жор).
  • Топ потребителей:
    • enduro-trails/data 26G + repos/enduro-trails/data 20G (terrain 8.9G + srtm 1.8G) — ВОЗМОЖНЫЙ ДУБЛЬ (две копии data?). Проверить идентичность.
    • openclaw 23G: config 14G (tasks 7.7G [snowbike-rag 7.1G!], data 2.9G, temp 2.7G [image-gen 1.3G]), data 8.9G.
  • Docker: Images 14.9G (reclaimable 5.1G), Build Cache 4.09G (active=0 → весь чистится безопасно), volumes/containers малы.
  • Кандидаты на чистку (БЕЗ подтверждения НЕ трогаю):
    1. docker builder prune -af → ~4G (безопасно, active=0).
    2. docker image prune (dangling) → до 5G reclaimable.
    3. openclaw/config/temp/image-gen 1.3G — старые генерации картинок (temp = мусор).
    4. Дубль enduro data (если repos/enduro/data == enduro-trails/data) → до 20G!
    5. snowbike-rag 7.1G в tasks — проверить актуальность (большой индекс/данные).
  • ⚠️ Удаление — только после ОК Славы. installer change-режим для деструктива.

ORCH-101 (10-common расхардкод) BRD APPROVED — глубокое ревью fable-5 (Слава 17:05 UTC)

  • Первый BRD написан fable-5/max. КАЧЕСТВО ЭТАЛОННОЕ: полный аудит хардкодов с файлами:строками, нормативный реестр A(src)/B(compose)/C(Dockerfile)/D(scripts)/E(уже параметризовано), разделение «блокер vs config-backed fallback», привязка к инвариантам ORCH-040/058 + INV-4, спорные A5(_STAGING_PORT)/A6(SELF_HOSTING_REPO) вынесены архитектору с сохранением инварианта.
  • ВЕРИФИЦИРОВАЛА КОДОМ (урок дня, fable мог галлюцинировать строки) — ВСЁ ТОЧНО 100%:
    • A1 plane_sync.py:1064 gitea_base="http://git.mva154.duckdns.org"
    • A2 launcher.py:594-598+825-829 HOME/claude-bot@mva154.local (2 места)
    • A3/A4 self_deploy:332-336, post_deploy:575-579
    • A5 image_freshness:61, A6 qg/checks.py:517
    • B compose uid 1000:1000/gid 999 «МИНА 1»
  • fable-5/max на аналитике = очень сильно (реестр до строки, не выдумал). Закрыла brd-clock → Approved (200) → architect job 1633 running (fable-5/max), stage=architecture, ветка feature/ORCH-101-orch-10-common-smoke.
  • zero-regression: все новые параметры дефолт=текущему значению, пустой .env = поведение 1:1. AC-1..8 проверяемые.
  • ⚠️ ORCH-9 в проде (post-deploy-monitor job armed). Очередь: 101(arch) дальше по гибридной схеме.

🧹 Чистка диска mva154 — этап 1 безопасный (Слава: «даю добро на очистку 10гб», 17:22 UTC)

  • Результат: 96% → 89%, свободно 5.3G → 14G (освобождено ~8.3 ГБ).
  • docker builder prune -af → 4.087GB (build cache, active=0).
  • docker image prune -f (dangling) → 945.7MB.
  • rm -rf /home/slin/openclaw/config/temp/image-gen → 1.3GB (старые генерации картинок).
  • Через installer ssh_exec (очистка = операция, подтверждение Славы было).
  • ⚠️ ОСТАЛОСЬ (НЕ трогала, требует разбора/ОК):
    • Дубль enduro data ~20G (/home/slin/enduro-trails/data 26G vs repos/enduro-trails/data 20G) — СВЕРИТЬ идентичность + какая примонтирована в контейнер, потом удалять. Главный приз.
    • docker image -a (не-dangling неиспользуемые) — рискованно, могут быть нужные образы остановленных сервисов.
    • snowbike-rag 7.1G в tasks — проверить актуальность.
  • Диск всё ещё 89% — поджимает, дубль enduro решил бы кардинально (→ ~72%).

🔍 СВЕРКА дубля enduro (Слава: «проведи сверку», 17:24 UTC) — ЭТО НЕ ДУБЛЬ!

  • ⚠️ ВАЖНО: НЕ мусорный дубль. ОБЕ папки примонтированы в РАБОЧИЕ контейнеры:
    • /home/slin/repos/enduro-trails/data (20G) → enduro-trails-app-1 (приложение, /app/data).
    • /home/slin/enduro-trails/data (26G) → osrm-osrm-routed-1 (маршрутизатор OSRM!).
  • Удалять НЕЛЬЗЯ ни одну — обе живые данные разных сервисов. Хорошо что сверила (чуть не снесла рабочий OSRM-граф).
  • Содержимое osrm-data (26G): terrain 16G + srtm 1.8G + centralfederal.ru-latest.osm.pbf 861МБ + centralfederal.sqlite 451МБ + download_*.sh/log.
  • Кандидаты на чистку ВНУТРИ (требуют ОК + понимания нужны ли):
    • centralfederal.osm.pbf (861МБ) + sqlite (451МБ) — промежуточные артефакты сборки OSRM-графа; ЧАСТО не нужны после готового графа. ~1.3G. НО проверить не пересобирается ли граф из них.
    • terrain 16G в osrm-data vs terrain 8.9G в repos-data — РАЗНЫЕ размеры, возможно дублирующиеся хиллшейд/hypso тайлы между двумя проектами. Сверить.
    • srtm 1.8G в обеих — возможно дубль исходных DEM.
  • Диск 89%. Безопасного быстрого приза нет — нужен разбор с пониманием enduro/osrm пайплайна. Отложено до решения Славы.

ORCH-102 (10a Lite-тираж) BRD APPROVED (Слава: «проверь и продолжаем», 18:49 UTC)

  • docs-first задача (главный продукт = инструкция docs/deployment/LITE_SETUP.md). BRD/ТЗ/AC эталон, fable-5/max.
  • ВЕРИФИЦИРОВАЛА КОДОМ: compose реально подмножество (3 сервиса: orchestrator:12, watchdog:74, staging:100 за profiles; НИ ОДНОГО plane/gitea) ; фундамент ORCH-101 в ветке (REPLICATION.md+gen_secrets) ; src не тронут (+815 строк только docs 00-04) .
  • Сильные стороны: канон не форкает (ссылки на ONBOARDING/REPLICATION/SETUP_WEBHOOKS + анти-дрейф тесты), инварианты учтены (ADR D10 без branch protection, C-1 watchdog-бот≠бот орка, ORCH-040/058, INV-4), конфликт «pre-receive vs ADR D10» честно вынесен архитектору (А-1). 13 разделов LITE_SETUP с командой+проверкой на каждом шаге. Smoke на staging-песочнице (прецедент 101).
  • Закрыла brd-clock → Approved (200) → architect job 1688 running (fable-5/max), stage=architecture.
  • Эпик ORCH-10: 101 done → 102 🔵 в работе → 103 (Bundled) ждёт.