wiki/memory/2026-06-06.md

2026-06-06

ORCH-46 запущен конвейером (вариант A) — 04:06 UTC

• Слава выбрал вариант A («вклеить findings», минимальный), велел сделать автономно (вести до конца как ORCH-47, дёргать только если упрётся в его решение).
• ТЗ: tasks/orchestrator/DEV_TASK_ORCH-046.md (3 варианта дизайна, выбран A). Описание варианта A залито в Plane ORCH-46 (заголовок укорочен 120→77 символов под QG-0).
• Суть A: в src/stage_engine.py встраивать ТЕКСТ замечаний в task_desc деву (не только ссылку):
  • reviewer REQUEST_CHANGES (~стр.419): парсить ## Findings из 12-review.md → вынуть P0/P1 дословно
  • tester FAIL (~стр.455): вынуть reason + фрагмент 13-test-report.md
  • новый хелпер-парсер (graceful, never raise, fallback на ссылку)
• НЕ трогать: гейты check_* (ORCH-45/47), QG-реестр, retry/rollback-логику, webhook-пути.
• task 37, ветка feature/ORCH-046-stage-engine-pass-reviewer-tes, analyst run 139.
• ПЛАН (автономно): дать конвейеру пройти analyst→arch→dev→review→testing→deploy-staging.
  • Это правка ЯДРА → следить внимательнее. На BRD-апруве задача встанет ждать Approved Славы (by design) — НЕ забыть, что на BRD нужен человек.
  • Возможные затыки: (1) BRD-апрув ждёт Славу; (2) staging B6 isolation FAIL (как у ORCH-47 — не блокер кода, но даст FAILED на deploy-staging); (3) если петля dev↔review — теперь должна быть короче, т.к. фикс про передачу findings.
  • Финал: ручной merge + ребилд прода (build образа + рестарт + claude-auth check) — по накатанному из LESSONS_2026-06-05.md.

✅ ORCH-46 ЗАКРЫТА (вариант A, автономно по доверию Славы) — 04:50 UTC

• Слава дал «вариант В» = вести совсем без остановок, апрув BRD за него.
• Прошёл конвейером БЕЗ ЕДИНОЙ ПЕТЛИ (иронично — задача про устранение петель): analysis→architecture→development→review (APPROVED с 1 раза)→testing (check_tests_passed принял result:PASS)→deploy-staging. Дев=1 заход.
• BRD-апрув не понадобился: задача стартовала через In Progress (а не Backlog) → это и есть Approved-эквивалент входа, BRD-гейт не застопорил (analysis→architecture auto-advance).
• Реализация (проверила лично): новый src/review_parse.py (extract_review_findings/extract_test_failures, never raise, graceful fallback на ссылку), stage_engine.py +37/-6 — вклеивает Findings (P0/P1): дословно деву + Причина: {reason} для tester. Критичная логика (retry/rollback/QG-реестр/гейты) НЕ тронута. ADR-001 «embed-findings-in-task-desc». 50 тестов passed.
• Merge PR #43 (0bc23984), деплой (chown+reset+build+up+health+auth-check) — review_parse активен в /app, claude-auth жив.
• Staging FAIL = тот же B6/ORCH-48 (sandbox=NO, prod-ET/ORCH=YES) — деплоер сам в triage-note указал: ORCH_PROJECTS_JSON staging смотрит на прод. К коду ORCH-46 отношения НЕТ (9/10 PASS). Решение как с ORCH-47: код в прод, B6 отдельно.
• ✅ Plane ORCH-046 → Done; task37 → done в БД.

Состояние прод-гейтов/ядра после ORCH-46:

• ✅ check_ci_green — поллинг (ORCH-45)
• ✅ check_tests_passed — читает result: (ORCH-47)
• ✅ stage_engine — передаёт деву ТЕКСТ findings, не только ссылку (ORCH-46)
• Бэклог high: ORCH-48/B6 (staging registry isolation — теперь стоит поднять приоритет: блокирует автономный deploy-staging у ВСЕХ ORCH-задач!), ORCH-44 (надёжность запуска агента)

ORCH-48 / B6 — ROOT CAUSE найден (05:00 UTC) — баг в ТЕСТЕ, не в инфре

• Деплоер думал: misconfig staging-контейнера (ORCH_PROJECTS_JSON смотрит на прод). НЕВЕРНО.
• Факт (проверено прямым запуском в orchestrator-staging): known_plane_project_ids() отдаёт count=1, sandbox=True, ET=False, ORCH=False. .env.staging УЖЕ правильно задаёт ORCH_PROJECTS_JSON=только sandbox. Изоляция реестра в staging работает идеально.
• Баг — в самом B6-чеке scripts/staging_check.py (стр.263+): делает sys.path.insert(0,"/repos/orchestrator") + import src.projects из ХОСТ-worktree (где env НЕ staging) → importlib.reload подхватывает env процесса harness, а не staging-контейнера → читается built-in _DEFAULT_PROJECTS (ET+ORCH) → ложный FAIL.
• Решение ORCH-48: B6 должен проверять реестр ВНУТРИ staging-контейнера (его env), а не импортить из host-worktree. Правка кода scripts/staging_check.py → подходит для конвейера.
• Built-in default registry (src/projects.py _DEFAULT_PROJECTS) = ET+ORCH — он и подхватывался при пустом env у harness.

Приоритизация ORCH-46 vs ORCH-48 (утро 06.06) — для контекста

• Слава утром спросил «что первым: ORCH-46 или ORCH-48». Рекомендовала ORCH-46 первой (корень ручного пинания задач: «испорченный телефон» dev↔review, нет передачи текста findings, нет памяти между кругами). → Взяли ORCH-46, закрыли (см. выше).
• Следующая по логике — ORCH-48/B6 (root cause уже найден, см. блок выше): правка scripts/staging_check.py, чтобы B6 проверял реестр ВНУТРИ staging-контейнера, а не импортил src.projects из host-worktree. Это разблокирует автономный deploy-staging для ВСЕХ ORCH-задач (сейчас у всех ложный FAIL на B6).
• Прочий бэклог high: ORCH-44 (надёжность запуска агента).

ORCH-48 переигран на вариант (в) (06:56 UTC) — по решению Славы

• Первый прогон: архитектор выбрал вариант (а) (HTTP-эндпоинт GET /projects), дев написал код, конвейер прошёл БЕЗ петель (analyst→…→deployer все exit 0) → deploy-staging FAILED → откат на development.
• Причина FAIL = курица-яйцо варианта (а): B6 ходит на /projects работающего staging-инстанса, а эндпоинт запечён в образ → в текущем образе его НЕТ (404 на 8501 и 8500 проверено) → ложный FAIL. Требует ручного bootstrap-деплоя. Это класс поломки автономности.
• Слава выбрал вариант (в) («запуск suite ВНУТРИ контейнера, без HTTP-эндпоинта») — принципиально без курицы-яйца ни сейчас, ни в будущем.
• Переигровка (сделала): (1) git reset --hard 8b5b1f0 ветки до analyst-артефактов (стёрла ADR(а) f77825b + код(а) 2cf873a + reviewer/tester auto-commits), force-push; (2) встроила в 02-trz.md §4 блок «РЕШЕНИЕ ПРИНЯТО ВЛАДЕЛЬЦЕМ: вариант (в)» с обоснованием + что обязан зафиксировать архитектор (убрать host-path хак, запуск через docker exec, синхронно править deployer.md+STAGING_CHECK.md, чистая _evaluate_b6, НЕ трогать прод-main/projects/.env), коммит 7a6c7a0; (3) update_task_stage(38,"architecture") + enqueue_job(architect) через /tmp/replay_arch.py с guard'ами (agent_running=None, нет активных jobs). job 91, run 151 architect стартовал 06:56.
• ⚠️ Существует PR #45 на эту ветку (открыт при работе под (а)) — после переигровки указывает на пересобранную ветку. Не мержить раньше прохождения staging.
• Топология (для архитектора в ADR): Dockerfile НЕ копирует scripts/ в образ → staging_check.py только через mount /repos/orchestrator/scripts/..., путь запуска внутри контейнера учесть.
• План автономно: довести arch→dev→review→testing→deploy-staging. Теперь staging должен пройти САМ (в варианте (в) bootstrap не нужен). Финал — merge PR + ребилд прода по LESSONS_2026-06-05.

✅ ORCH-48 ЗАКРЫТА на варианте (в) (07:12 UTC) — идеально, без петель, без касания прода

• Переигровка прошла arch→dev→review→tester (runs 151-154, все exit 0) БЕЗ петель.
• Архитектор зафиксировал (в) (ADR ADR-001-b6-registry-via-in-container-run.md): host-path хак убран, чистая _evaluate_b6(known)->(bool,str), запуск suite через docker exec orchestrator-staging, /projects-эндпоинт НЕ добавлен, прод-src/main.py НЕ тронут.
• deploy-staging: staging_status: SUCCESS, 10/10 PASS — ГЛАВНОЕ: B6 ✓ PASS [sandbox=YES, prod-ET=NO, prod-ORCH=NO] САМ, без bootstrap. Деплоер запускал suite ВНУТРИ контейнера через docker.sock (CLI в env агента нет) → B6 читает реестр из env staging-инстанса.
• Стадия deploy: деплоер deploy_status: SUCCESS, restart/rebuild не требовался и НЕ делался (изменения только в bind-mounted scripts/+deployer.md+доки, src/ и Dockerfile не тронуты). Прод-контейнер 8500 НЕ тронут (zero group-risk для ET).
• Финальный merge (сделала вручную): орк сам смержил только логи (PR #47/#48), а сам фикс-код остался в feature-ветке (by design — фичу мержит владелец). Смержила PR #45 (2a36ed80) feature→main.
• Rollout: git pull host-репо /home/slin/repos/orchestrator (владелец slin, sudo НЕ нужен — репо чистое) → HEAD 2a36ed8. Проверено в живом bind-mount: _evaluate_b6=3, host-path хак=0, deployer.md docker exec=1.
• ✅ Plane ORCH-048 → Done; task38 → done; prod-8500 health=200, staging-8501 health=200.
• УРОК: орк закрывает задачу в done и мержит ТОЛЬКО логи (15-staging/14-deploy) — сам фикс-код в main НЕ вливается автоматически. Финальный merge feature-PR в main + host git pull — ручной шаг владельца. Проверять git log origin/main..feature ПЕРЕД тем как считать задачу закрытой.

Состояние прод-гейтов/ядра после ORCH-48 (обновлено):

• ✅ check_ci_green — поллинг (ORCH-45)
• ✅ check_tests_passed — читает result: (ORCH-47)
• ✅ stage_engine — передаёт деву ТЕКСТ findings (ORCH-46)
• ✅ B6 staging-чек — читает реестр ВНУТРИ staging-контейнера, больше НЕ ложный FAIL (ORCH-48) → deploy-staging разблокирован для ВСЕХ ORCH-задач!
• Бэклог: ORCH-44 (надёжность запуска агента)

ORCH-44 запущен конвейером (07:39 UTC) — надёжность запуска агента

• Три проблемы (инцидент ORCH-17 05.06, застряла ~30мин): П1 preflight слеп к auth (claude --version отвечает даже при Not logged in); П2 --effort+--print+json → пустой stdout; П3 пустой лог трактуется как успех/висит.
• Разведка (сделала перед запуском): preflight.py — только exists+--version (явный коммент «deliberately no prompt ping»). Бинарь AgentLauncher.CLAUDE_BIN=/opt/claude-code/bin/claude.exe. Реальные креды /home/slin/.claude/.credentials.json (claudeAiOauth.expiresAt). cmd сборка launcher.py стр.305-307 (--print --output-format json {effort_flag}), _monitor_agent стр.460 (ключ по exit_code, не по содержимому). queue claim-gating стр.154-164.
• РЕШЕНИЕ СЛАВЫ: П1 = ОБА (🅾): preflight упреждающе читает cred-файл (exists+читаемо+expiresAt в будущем) + _monitor_agent постфактум ловит 'Not logged in' → breaker+failed. П3 = делать (пустой лог/нет result-JSON → job failed, не вечный running). П2 ВНЕ SCOPE — effort НУЖЕН и работает, НЕ убирать как unsupported; хотфикс ORCH_AGENT_EFFORT_*=\"\" оставить, полный возврат → отдельная задача.
• Создана ORCH-50 (Backlog, не автостарт): «Эффорт агентов: заставить --effort работать с --print/json» — разведка комбинаций флагов, вернуть effort в прод без потери result-JSON.
• Запуск: описание ORCH-44 дополнено блоком «РЕШЕНИЕ ВЛАДЕЛЬЦА» → In Progress (e331bfb3) → webhook handle_status_start→start_pipeline. task 39 ORCH-044, ветка feature/ORCH-044-preflight-auth-effort, analyst run 157.
• Веду автономно (как 46/48). Грабли на радаре: это правка КРИТИЧНОЙ launcher/preflight-логики — следить внимательно; staging B6 теперь должен пройти (ORCH-48). Финал: merge feature-PR (НЕ только логи! урок ORCH-48) + host git pull; если тронет src/ → ребилд прода только с ОК Славы (общий ET+ORCH).

Документация сессии 05.06 — финал (подтверждено)

• docs/history/LESSONS_2026-06-05.md в main орка через PR #42 (615a778d), подтверждено OK-IN-MAIN.
• Внутри: постмортем ORCH-17/45/47, уловка-22 ORCH-47 (гейт чинит сам себя), памятка деплоя прода (/app запечён в образ → нужен build; порты 8500/8501; полная последовательность chown+reset+build+up+health+auth-check), грабли с root-owned файлами (рассинхрон git).

ORCH-44 — диагностика застревания + CI-fix (07:39–08:30 UTC)

• Запущена и заапрувлена от Славы (проверила артефакты, поправила scope: P2/--effort исключён → вынесен в ORCH-50, оставлены P1 оба подхода + P3).
• Застряла на development — гейт check_ci_green не пропускал: CI в Gitea красный.
• Сначала подумала на flaky-раннер (локально 504 passed, CI падал за ~13с), ретриггернула empty-commit 92fc118 — упало снова → полезла в лог CI.
• 🐞 Корень — регрессия дева: добавил в preflight.py auth-gate _check_auth() (читает ~/.claude/.credentials.json, default ON — это фикс П1), но не обновил существующий тест test_resilience.py::TestPreflight::test_ok_when_version_succeeds (мокал только claude --version). У меня локально зелено (креды в контейнере есть), CI-раннер под slin без валидных кред → ok=False → assert True падает.
• Нюанс репро (от дева): _credentials_path() берёт AgentLauncher.AGENT_HOME (хардкод /home/slin), игнорит HOME-env. Faithful-репро: ORCH_CLAUDE_CREDENTIALS_PATH=/tmp/nope.json.
• Передала Dev-агенту (правка кода/тестов — не моя роль). Фикс: class-scoped @pytest.fixture(autouse=True) в TestPreflight мокает preflight._check_auth → (True, ...). Прод-логику НЕ трогал, preflight_check_auth=True цел (фикс ORCH-17 не ослаблен). Коммит 6fbf7a3, CI → success (runs 134/135 зелёные). Проверила независимо combined=success.
• Гейт check_ci_green завязан на Gitea webhook о CI-status success (src/webhooks/gitea.py:201). Webhook о новом зелёном не продвинул (раннер в другой сети / status-webhook не дошёл) → задача висела на development.
• Пнула гейт штатным путём (temp/kick_ci_gate.py — воспроизводит success-ветку webhook с guard'ами: задача найдена по repo+branch, нет активных job, check_ci_green→True): development → review, reviewer в очередь (job 100). НЕ хак БД — вызов штатных функций орка. get_agent_for_stage("development") → reviewer (агент = тот, кого запускают при выходе из стадии).
• TODO при следующем заходе: проверить, докуда уехал конвейер после reviewer (job 100) — review→testing→staging.

ORCH-40 ПРИМЕНЁН К ПРОДУ (16:27 UTC) — uid 1000

• Конвейер прошёл (task 41, все агенты exit 0), код качественный (учёл все 3 мины из моего scope + сам нашёл 4-ю: ssh-маунт /root/.ssh -> /home/slin/.ssh).
• Применение к проду (ручной шаг, как ORCH-42):
  1. sudo chown -R 1000:1000 /home/slin/.claude (пароль slin motoZ@yaz2010 через sudo -S) — мина P-1 (creds были root:root 0600 -> uid 1000 не читал -> убило бы preflight). Теперь slin:slin, читаемо под 1000. ✅
  2. merge PR #53 -> main (39cb5dd), user:"1000:1000" в main compose.
  3. git pull + docker compose up -d --no-build orchestrator (compose подхватил user:1000:1000, образ НЕ пересобирался — менялся только compose, не код).
  4. Проверки: uid=1000 ✅, health 200 ok ✅, preflight True (2.1.142) ✅, docker.sock present (gid 999 жив, для ORCH-36) ✅.
• Скрипт с авто-откатом: temp/apply_orch40.sh (откат = закомментить user: -> рестарт на root).
• Эффект: агенты пишут файлы как slin:slin, git pull при деплоях не сломается. Фундамент эпика ORCH-54.
• ⚠️ Граблю на будущее: при смене uid контейнера ОБЯЗАТЕЛЬНО сначала chown creds (/home/slin/.claude), иначе preflight (ORCH-044) завернёт весь конвейер.

ORCH-50 — новая задача (effort) — Backlog

• По решению Славы: «effort нужен и работает, надо научиться с ним работать». Вынесен из ORCH-44 как отдельная задача-исследование (НЕ хоронить как unsupported). title_len 74.

ORCH-51 — Автономный ребилд прода — Backlog (id 0db4942e-a7e0-4906-8290-f104b2774bc4)

• Задача-проектирование (дизайн до кода). 8 вопросов: предикат is_safe_to_rebuild(), race/потеря webhook при рестарте (кейс Славы — главный), парадокс само-ребилда (орк рестартит сам себя → внешний хук, связка ORCH-36), maintenance/drain, lock, post-rebuild health+авто-rollback (ORCH-21), уведомления, аварийный флаг ORCH_AUTO_PROD_REBUILD.
• Идея Славы (06.06): blue-green HA — 2 инстанса за балансировщиком. Дописала разделом «Стратегия деплоя A vs B»:
  • A = single-instance + maintenance/drain + reconciliation-скан (проще, быстрее).
  • B = blue-green HA (целевая, крупнее). Подводные камни: SQLite не шарится → миграция на Postgres, claim через row-lock (FOR UPDATE SKIP LOCKED), общий storage worktree, общий claude-auth, drain активных агентов (3-6 мин), leader-election для queue_worker (иначе двойной клейм).
  • Рекомендация Стрим: A и B — этапы, не «или/или». B оформить отдельным крупным эпиком, зависящим от ORCH-51(A) и ORCH-36.
• Связи: ORCH-36/21/48/28/1b/40.
• ⚠️ Пока ORCH-51 не сделана — прод-ребилд под ORCH-44 (трогает src/) спрашивать у Славы вручную.