admin/wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4a2849d76a262994f74cb2eacd84c8bc67c5b47d
wiki/memory/2026-06-03.md
Stream 4a2849d76a auto-sync: 2026-06-04 01:50:01
2026-06-04 01:50:01 +03:00

51 KiB
Raw Blame History

Конвейер UX — статусная модель + токены (03.06 день, в работе)

Решения Славы по статусной модели (ПОДТВЕРЖДЕНЫ):

  • Бэклог в Plane. Задача лежит в Backlog/Todo/Triage пока Слава не переведёт в In Progress → только это запускает конвейер (analyst). Сейчас триггер = work_item.created (любой тикет сразу стартует) — НАДО починить.
  • Вердикт статусами (вариант B): статус Approved = advance, Rejected = rollback. Комменты :approved:/:rejected: ОСТАВИТЬ параллельно. Причину reject Слава пишет комментом.
  • Стадии видимы на доске: architecture/development/review/testing — отдельными статусами, не скрыты в In Progress.
  • Расход токенов по агентам: показывать (A) в комменте каждого агента + (B) итог-сводка от Deployer.

Механика конвейера (по факту кода, для справки):

  • Все 6 агентов работают над ОДНОЙ задачей = 1 тикет Plane = 1 feature-ветка, комментят в неё (теперь под своими именами).
  • Статус сейчас меняется только: in_review (analyst ждёт approve), needs_input (вопросы), blocked, in_progress, done. Стадии architecture/dev/review/testing невидимы.
  • 2 ручных гейта: analyst→ждёт :approved: (In Review); reviewer→:approved:. Остальное едет автоматически.
  • Needs Input: analyst пишет 01-questions.md, статус Needs Input, ждёт. Слава отвечает обычным комментом → analyst перезапуск. Лимит 3 раунда → Blocked + Telegram-алерт.
  • Агенты = Claude CLI (/opt/claude-code/bin/claude.exe --print), вывод в лог. Версия 2.1.142.

ИНФРА сделана Стримом (БД Plane, бэкап states plane-states-backup-*):

6 новых статусов в проекте enduro (7a79f0a9-...), группа started, в правильном порядке доски:

architecture=3020bbb7-6122-4663-930c-0315ba8dfa3d  development=9920609b-f140-4e46-ab95-89acda8412c8
review=ba0d802c-5218-41d4-ab43-978b0ea123ed         testing=7855d807-b1bf-42ef-8dae-6cde0df92d02
approved=a519a341-dada-4a91-8910-7604f82b79c5       rejected=ba958f3c-5db5-461d-8f82-89425e413b97

CLI usage подтверждён вживую (для фичи токенов):

claude --output-format json отдаёт: total_cost_usd, usage.{input_tokens,output_tokens,cache_read_input_tokens,cache_creation_input_tokens}, modelUsage, num_turns, duration_ms. Сейчас запуск plain-text (--print без формата) → usage НЕ собирается. agent_runs (id,task_id,agent,started/finished,exit_code,output_path) — НЕТ полей токенов, надо ALTER.

Код — Dev, ветка feature/pipeline-ux, ТЗ DEV_TASK_PIPELINE_UX.md (4 фичи):

  1. Старт по статусу (in_progress), не по created. Идемпотентно (задача уже есть → не дублить).
  2. Вердикт-статусы Approved/Rejected (+ комменты живы).
  3. Видимость стадий: PLANE_STATES += 6 UUID, set_issue по стадии (Needs Input/Blocked приоритетны).
  4. Токены: --output-format json, ALTER agent_runs (+input/output/cache/cost), коммент агента + сводка Deployer.
  • ⚠️ Статусы per-project — ОСТАВИТЬ TODO (ORCH-10 эпик), не переделывать резолв сейчас.
  • Baseline 166 passed. Мерж — Стрим после живой проверки.

Recraft (попутно, 03.06): модель OpenRouter = recraft/recraft-v4.1 (НЕ в каталоге /models, но работает). Дёргать chat/completions с modalities:["image"] (только image, без text — иначе 404). Сгенерила пляжные картинки Славе.

PR #10 СМЕРЖЕН в main (03.06, вечер) — конвейер UX

Merge commit main = 4773137. Проверено вживую перед мержем (не на слово Dev):

  • 5 коммитов на remote: a4668c0 feat(plane) stage visibility+verdict UUIDs, 09b1c5e feat(webhook) старт на In Progress, 38a741d feat(webhook) вердикт Approved/Rejected (вариант B), 9a702a0 feat(metrics) токены/cost per-agent, 7fd6529 test(conftest) глушилка Telegram.
  • Прогон тестов сама: 190 passed, 9 failed. Девять — pre-existing baseline (сравнила полную сюиту на main ДО ветки = те же 9). Regression = 0. Из девяти: 8 это 401-invalid-signature, 1 это test_plane_approved TypeError — ВСЕ падали и на main. ⚠️ Уточнение к прошлым заметкам: реальный baseline = 9 (не только 401-набор).
  • Telegram-утечка закрыта: tests/conftest.py autouse-фикстура глушит send_telegram во всех тестах. Sentinel-проверка: 0 запросов в api.telegram.org за прогон. Покрыты модули: notifications (источник), stage_engine (module-level import — критичный), plane/launcher/queue_worker/main (local imports, raising=False). Источник шума «🔄 ET-100» = тест test_webhook_dedup гонялся на проде без мока.

✅ ЗАДЕПЛОЕНО (03.06 ~16:10 UTC)

Деплой = rebuild образа + recreate (код COPY в образ из src/, НЕ bind-mount; data/ — bind-mount, переживает). Команда: git checkout main && git pull && docker compose up -d --build. Бэкап БД: data/orchestrator.db.bak-1780503005.

  • ⚠️ Перед сборкой репо был на feature/pipeline-ux — обязательно git checkout main (иначе соберётся ветка).
  • Контейнер Up, uvicorn:8500, queue worker стартовал, ошибок нет. Образ на 4773137.
  • Миграция agent_runs прошла: добавились input_tokens, output_tokens, cache_read_tokens, cost_usd. БД цела (11 задач).

Боевые тесты статусной модели на проде (вживую, HMAC-подписанные webhook):

  • ✅ ТЕСТ 1 (created НЕ стартует): work_item.created → HTTP 200, задач создано 0, только soft QG-0 warning в лог. Бэклог-режим работает.
  • ✅ ТЕСТ 2b (idempotency): In Progress для существующей задачи (f9009756) → лог task already exists (stage=analysis), not restarting, 11→11 задач. Защита handle_comment работает.
  • ⏳ ТЕСТ 2a (позитивный старт) не делала: запустит реальный analyst (токены + ветка в Gitea). Спросила Славу прежде чем плодить мусор.
  • ⚠️ Грабля: UUID In Progress = b873d9eb-993c-48cd-97ac-99a9b1623967. State UUID извлекается из data.state.id (или bare string).
  • HMAC секрет: ORCH_PLANE_WEBHOOK_SECRET (len 40). Подпись: printf %s BODY | openssl dgst -sha256 -hmac SECRET, заголовок X-Plane-Signature.

После деплоя — боевой тест (план):

Завести задачу в Backlog → перевести в In Progress (должен стартовать analyst, НЕ на created) → провести по доске (видеть переезд по колонкам Architecture→…→Testing) → показать Славе токены живьём (коммент агента 💻 Developer · Nk in / Mk out · $X + сводка Deployer). Боевой usage-тест на ветке уже дал 💻 Developer готов · 6 in / 15 out · $0.06.

Формат Plane-webhook на смену статуса (Dev нашёл по реальному payload):

event="issue", action="updated", новый статус в data.state.id. Старт ловит переход в In Progress из бэклог-статуса. Идемпотентность: задача уже в БД tasks → не дублить/не перезапускать.

Первый штатный тикет в Plane после фичи-1 (03.06 16:56)

  • Тикет создан штатно в Backlog (не в обход!) — фича-1 наконец позволяет: создание НЕ запускает конвейер.
  • ET-? seq=6, id bfb4866c-4b69-4f97-916b-e7233d8259de, name «Скачивание трека из popup на карте (enduro-trails)», state=Backlog (113b24f6-...).
  • ✅ Проверено: 0 задач в оркестраторе, конвейер не стартанул. Бэклог работает в бою.
  • Суть фичи (запрос Славы): тап по треку на карте → в popup с инфо кнопка «Скачать» → отдать файл трека (GPX обяз., KML опц.). Источник: пользовательские треки на карте (enduro-trails). Нужен бэкенд-эндпоинт отдачи трека по id + Content-Disposition.
  • Создание issue через Plane REST: токен ORCH_PLANE_API_TOKEN (len 60, общий orchestrator-токен), POST http://localhost:8091/api/v1/workspaces/ag_proj/projects/<proj>/issues/, заголовок X-API-Key, тело {name, state, description_html}. Backlog UUID = 113b24f6-cce8-4be9-9a22-a359b9cf0122.

Боевой запуск #6 (ET-006) — баги вскрыты, чистка сделана (03.06 ~18:00)

Что РАБОТАЕТ (доказано в бою):

  • ✅ Триггер по статусу In Progress (после фикса webhook URL)
  • ✅ Токены считаются: run 59 analyst → 27 in / 36851 out / $2.13 записаны в agent_runs
  • ✅ Per-agent authorship: комменты под именем analyst
  • ✅ Webhook URL фикс: http://172.21.0.1:8500/webhook/plane (Plane не резолвит DuckDNS — docker-сеть изолирована; старый внешний URL давал 500). UPDATE webhooks SET url в БД Plane сделан.

БАГИ (для Dev):

  1. issue.updated без description → QG-0 падает в Blocked. Plane на смену статуса шлёт только изменённые поля, description/description_stripped пустые. start_pipeline читает описание из webhook payload → QG-0 «Description < 20 символов» → задача в Blocked. ФИКС: тянуть описание через GET Plane API (issue detail) в start_pipeline, не из payload.
  2. Коллизия work_item_id + рассинхрон веток. M-6 выдал ET-006 ПОВТОРНО: task 8 (plane 9884fb9c, 22 мая, gpx-upload, done) и task 25 (plane bfb4866c, сегодня, popup-enduro-trails). Worktree резолвится по work_item_id → analyst run 59 писал в ЧУЖОЙ worktree (gpx-upload task 8), а не в свой (popup task 25). Гейт check_analysis_complete искал артефакты в branch task 25 → не нашёл → не перевёл в In Review. ФИКС: get_next_work_item_id должен гарантировать уникальность (не переиспользовать seq); worktree/ветка должны привязываться к task_id, не к work_item_id.

Чистка ET-006 (сделана, бэкап БД orchestrator.db.bak-clean-*):

  • Удалён дубль task 25 + его runs из БД.
  • Удалён мусорный worktree feature_ET-006-gpx-upload.
  • Откачен мусорный коммит 6edf97f (analyst run 59 в чужую ветку) → force-push origin/feature/ET-006-gpx-upload на d379e48.
  • Тикет #6 (bfb4866c, seq 6) → Backlog, описание на месте. Готов к повторному чистому запуску ПОСЛЕ фикса бага 1.

PR #11 (баги конвейера) — смержен + задеплоен + ОБА бага побеждены в бою (03.06 ~18:15)

  • Merge main cd73c75. Деплой: rebuild+recreate, образ на cd73c75. Бэкап orchestrator.db.bak-deploy11-*.
  • Мой прогон: 195 passed (190+5 новых), 9 baseline (те же, regression 0).
  • Баг1 фикс работает: лог start_pipeline: pulled description from Plane API (445 chars) → QG-0 прошёл, НЕ Blocked. Функция fetch_issue_description в plane_sync (переиспользует GET issue endpoint + PLANE_HEADERS).
  • Баг2 фикс работает: лог work_item_id collision: derived ET-006 already in use; reassigned -> ET-011. Guard ensure_unique_work_item_id в db.py (поверх M-6 derive). Ветка уникальна per task.
  • Боевой перезапуск #6: task 26 = ET-011, analyst запущен (job_id=7).
  • ⚠️ Мелочь: ветка feature/ET-011-untitled (slug untitled — в тестовом webhook не было name; реальный Plane шлёт name, не критично).
  • ⚠️ Дедуп webhook по телу: повторный идентичный payload → {"status":"duplicate"}. Для теста уникализировать тело (activity_id).

PR #11 — финальный отчёт Dev (03.06 ~18:25, дополнение)

  • Баг1 (description): src/plane_sync.py → fetch_issue_description(issue_id, project_id) — переиспользует GET issue-detail + shared-токен PLANE_HEADERS (как fetch_issue_sequence_id). Берёт description_stripped, при пустом стрипает description_html (_strip_html). На ошибке → "" (не бросает). Вызов в start_pipeline ПЕРЕД QG-0. Если и API пусто → честный QG-0 fail.
  • Баг2a (uniqueness): src/db.py → ensure_unique_work_item_id(work_item_id, repo) — guard ПОВЕРХ M-6 derive (derive не тронут). ET-NNN занят в tasks для repo → шагает вперёд. Изоляция по repo. Warning при реассайне.
  • Баг2b (worktree, ~15 строк): worktree в git_worktree.py ключуется по branch, таски реверс-резолвятся по (repo, branch). С 2a work_item_id уникален → префикс ветки уникален. Доп. страховка: занятая ветка → feature/{work_item_id}-{plane_id[:8]} + warning. Сам git_worktree.py НЕ переписан (достаточно уникальности ветки).
  • Тесты: tests/test_pipeline_start_bugs.py — 5 новых passed. Коммиты fa74610, ac9f5a0, c69e113.

Уроки tooling (03.06)

  • Маски ломают bash/psql/python-heredoc: кавычки и спецсимволы в маскированных значениях рвут командную строку и python3 -c. Решение: писать значения во временный bash/sql-скрипт через write, исполнять файлом — масок нет внутри write.
  • <pending>/<> в .env ломают source: строка вида HEYGEN_TALKING_PHOTO_ID=<pending> — <> интерпретируется как редирект. На ключи не влияет, но source .env падает. Чистить такие placeholder-строки или грепать конкретный ключ.
  • Plane DNS-изоляция: Plane-контейнеры (docker-сеть 172.21.0.0/16) НЕ резолвят внешние домены даже через 8.8.8.8. Оркестратор в host-сети — резолвит. Поэтому webhook URL в БД Plane = http://172.21.0.1:8500/webhook/plane (внутренний gateway), НЕ внешний DuckDNS-домен. Это уже починено, НЕ трогать.
  • Plane issue.updated шлёт только изменённые поля — на смене статуса description отсутствует. Любая логика, требующая полей тикета на updated-событии, должна дотягивать их из Plane API, а не из payload.
  • Webhook-дедуп по телу: идентичный payload → {"status":"duplicate"}. Для повторного теста уникализировать тело (напр. activity_id/timestamp).

Tokenator — лимит исчерпан (03.06)

  • Ключ TOKENATOR_API_KEY (sk-fp-...5625), baseUrl https://api.tokenator.top/v1.
  • Месячная квота: 200,000,000 токенов. Потрачено 200,116,633 → remaining −116,633. Всё блокируется (Token limit exceeded), включая /v1/models.
  • Нет эндпоинтов usage/account/limits (404). Расход виден в теле ошибки completions: {"error":"Token limit exceeded","usage":{"remaining":...,"token_limit":...,"tokens_used":...}}.
  • .dev-домен даёт SSL exit 35; .top (из openclaw.json) — рабочий.
  • Не блокирует OpenClaw — авто-фолбэк на другие провайдеры (OpenRouter DeepSeek/Grok). Claude CLI агентов (analyst и т.д.) Tokenator не касается.

Открытый хвост (для следующей сессии)

  • Боевой #6 перезапущен как task 26 / ET-011, analyst (job_id=7) запущен ~18:15. Проверить: дошёл ли до In Review, появилось ли уведомление с кнопкой одобрения, в правильную ли ветку писал.
  • Tokenator: ждать сброса квоты (вероятно 1-е число) или писать саппорту на повышение лимита.

БАГ 3 — самоудар по эхо-комменту: In Review → In Progress (03.06 ~18:30)

Симптом: analyst довёл #6 (ET-011) до In Review корректно (баг2 фикс работает!), но через 0.1с статус откатился обратно в In Progress. На скрине Славы State=In Progress, уведомления с :approved: нет. Цепочка (лог 18:17:05):

  1. analyst PATCH → In Review (38fb1f64) ✅
  2. analyst постит коммент «BRD/ТЗ готовы. Жду :approved:» (author=analyst)
  3. Этот коммент эхом прилетает в handle_comment (src/webhooks/plane.py ~433)
  4. Коммент без :approved:/:rejected:, а current_stage=="analysis" → код трактует как «ответ человека на вопросы аналитика» → set_issue_in_progress(work_item_id) → ОТКАТ In Review→In Progress 🐛 Корень: handle_comment НЕ отличает собственный коммент бота/агента от ответа человека. Любой не-вердиктный коммент на стадии analysis → возврат в In Progress. analyst сам себя сбивает. Фикс (для Dev): в handle_comment игнорировать комменты, автором которых является бот/агент (analyst/architect/... или служебный actor). Проверять author/actor вебхука: если это наш сервисный аккаунт или один из агентов — return (no action). Только комменты РЕАЛЬНОГО человека (Слава) должны триггерить approved/rejected/answer-to-questions. NB: PLANE_STATES в Enduro Trails корректен — один In Progress (b873d9eb). «5 In Progress» ранее — статусы ДРУГИХ проектов, ложная тревога. Состояние: #6 сейчас In Progress (откачен), task 26 stage=analysis, артефакты в feature/ET-011-untitled готовы. После фикса бага3 — повторить и убедиться что In Review держится.

РЕШЕНО: чистая статусная модель управления конвейером (03.06, подтверждено Славой)

Слава управляет конвейером ТОЛЬКО статусами. Комменты НИКОГДА не триггерят переходы. Финальная модель:

  • Одобрение → Слава ставит статус Approved → оркестратор двигает на след. стадию (сам ставит статус стадии).
  • Отклонение → Слава СНАЧАЛА пишет коммент с причиной, ПОТОМ ставит Rejected → оркестратор откатывает + читает причину из последнего коммента.
  • Ответ на вопросы analyst (задача в Needs Input) → Слава пишет коммент(ы), ПОТОМ САМ возвращает статус в In Progress → оркестратор перезапускает агента текущей стадии (читает комменты). Триггер = СТАТУС In Progress, не коммент.
  • Комментный механизм (:approved:/:rejected:/answer-by-comment) — ВЫПИЛИВАЕТСЯ полностью. ТЗ: tasks/orchestrator/DEV_TASK_STATUS_ONLY_VERDICT.md Ключевая правка vs прошлого PR: handle_status_start теперь должен ПЕРЕЗАПУСКАТЬ агента при возврате In Progress из Needs Input (не просто idempotent-skip), отличая от защиты-дублей через running-job/prev-status.

PR #12 — статус-онли модель + баг 3 закрыт, боевой прогон удачен (03.06 ~19:25)

Merge main = 2d392b6. Ветка fix/status-only-verdict (из main с PR #11). Задеплоен (rebuild+recreate).

Что выпилено/изменено (src/webhooks/plane.py):

  • handle_comment → чистый логгер. Весь комментный механизм управления убран: ветки :approved: (~427), :rejected: (~420), answer-to-questions if current_stage=="analysis" (~433-490). Ни один коммент не меняет статус и не запускает агентов. Router routes comment.created → только лог. Корень бага 3 (эхо-самоудар) устранён.
  • handle_status_start: перезапуск агента при In Progress из Needs Input. Развилка решена через running-job (а НЕ prev-status — его нет: tasks-таблица без status-колонки, payload несёт только новый статус). Логика: нет task → start_pipeline; task есть + НЕТ active job → агент простаивает = «Слава ответил на вопросы» → relaunch агента текущей стадии (STAGE_AUTHORS[stage]); task есть + active job → busy/дубль → skip. Двухслойный дедуп: insert_event_dedup (идентичные тела) + новый db-хелпер has_active_job_for_task(task_id) (SELECT 1 FROM jobs WHERE task_id=? AND status IN ('queued','running')) — для РАЗНЫХ webhook при живой джобе.
  • handle_verdict(approved): убран set_issue_in_progress — он откатывал статус перед advance (мелькание In Progress). Подтверждено: _try_advance_stage → advance_stage → notify_stage_change → update_issue_state (plane_sync.py:255) сам PATCH-ит статус след. стадии. Безопасно.
  • handle_verdict(rejected): причина из последнего коммента. Новый _latest_comment_reason(issue_id, repo, project_id): GET .../issues//comments/, новейший по created_at, стрип HTML, trim 300. Fallback «Rejected via status, no reason comment». Передаётся в _rollback_stage.

Тесты (мой прогон сам): 204 passed, 9 failed (те же 9 baseline pre-existing signature/401, regression 0, +12 новых).

Новые/переписанные: test_status_only_verdict.py (test_inreview_comment_does_not_revert = главный для бага3, test_any_comment_no_pipeline_action, test_approved_status_advances_without_inprogress_reset, test_rejected_status_pulls_reason_from_comment); test_status_trigger.py (test_repeat_in_progress_while_job_active_does_not_relaunch, test_inprogress_from_needs_input_relaunches_analyst); test_verdict_status.py (approved/rejected comment → noop); test_webhooks.py (approved/rejected переписаны на статус-триггеры). Коммиты: fix(webhook): remove comment-based approve, keep status-only verdict, fix(webhook): drop redundant in_progress reset on Approved, feat(webhook): pull reject reason from latest comment.

✅ БОЕВОЙ ПРОГОН — баг 3 побеждён (главное):

Почистил прошлый task 26, вернул #6 в Backlog → перевёл в In Progress → новый прогон task 27 = ET-011 (guard снова ушёл от занятого ET-006). analyst run 61: 6105 out, $0.40.

  • ✅ Лог: comment.created ... logged only, no pipeline action (status-only verdict) — коммент analyst НЕ триггерит ничего.
  • ✅ Лог: issue updated to state 38fb1f64... no pipeline action — перевод в In Review больше НЕ вызывает откат.
  • ✅ #6 = In Review ДЕРЖИТСЯ (раньше за 0.1с был откат в In Progress). Баг 3 закрыт в бою.

Артефакты analyst ET-011 (ветка feature/ET-011-untitled, Gitea admin/enduro-trails):

docs/work-items/ET-011/: 00-business-request.md, 01-brd.md, 02-trz.md, 03-acceptance-criteria.md, 04-test-plan.yaml, 04b-ui-test-cases.md. Внешний URL Gitea = https://git.mva154.duckdns.org/admin/enduro-trails/src/branch/feature/ET-011-untitled/docs/work-items/ET-011/<файл>.

Открытый хвост (следующая сессия):

  • #6 сейчас в In Review в Plane, ждёт ручной проверки Славы: перевести в Approved → должна уехать в Architecture БЕЗ мелькания In Progress. Или Reject: коммент причины → Rejected → analyst перезапуск с причиной. Слава решит — сам в UI или мне симулировать.
  • Косметика (предложен 2-й тикет Dev, Слава ещё не подтвердил): (1) коммент analyst всё ещё пишет «Жду :approved:» — устаревшая формулировка, поправить на «переведите в Approved»; (2) добавить ссылки на артефакты прямо в коммент Plane (чтобы не лезть в Gitea руками).
  • Ветка-slug всё ещё untitled (в тестовом webhook нет name; реальный Plane шлёт name — не критично).
  • Tokenator: квота исчерпана (−116k), ждать сброса (~1 число) или саппорт. OpenClaw не блокирует (фолбэк), Claude CLI агентов не касается.

PR #13 — вход/выход analyst: 3 бага закрыты, боевой прогон чистый (03.06 ~20:30)

Merge main = dce9ac8. Ветка fix/taskmd-description из main 2d392b6 (после PR #12). Задеплоен (rebuild+recreate). 3 коммита на remote (ORCH-7 проверено): b91be74, 96c5e6b, a9cdb17.

Баг A (главный) — description дотягивался, но НЕ доходил до analyst

src/webhooks/plane.py, start_pipeline task_desc (~стр.512→522): собирался БЕЗ description (...Stage: analysis\nTitle: {name}), хотя description дотянут на ~401 (445 chars в логе). .task.md = 101 байт → analyst писал «business request пуст» (его заключение было ПРАВИЛЬНЫМ — ему дали пустышку). Фикс: добавлен \n\nDescription:\n{description} (финальная переменная после дотяжки, не payload). После фикса .task.md = 973 байта с полным ТЗ.

Баг B — name=untitled

start_pipeline ~376: name = data.get("name","untitled") → на issue.updated Plane не шлёт name → untitled (ветка feature/ET-011-untitled, Title untitled). Тот же класс что баг1(description), но для name фикс не делали. Фикс: новая fetch_issue_fields(issue_id, project_id) -> (name, description) в plane_sync.py рядом с fetch_issue_description (его НЕ тронули, переиспользовали endpoint/токен). Один GET вместо двух. В start_pipeline name тянется ВЫШЕ построения slug/branch (~469). Пустой name → fallback untitled, не падает. После фикса ветка = feature/ET-011-popup-enduro-trails.

Баг C — коммент analyst устарел + нет ссылок

src/stage_engine.py, ветка artifacts-ready→In Review (_handle_analysis_approved_flow). Новый _build_analyst_ready_comment: текст просит статус Approved (НЕ :approved:, НЕ In Progress — подтверждено Славой: одобрение=Approved). <a href>-ссылки в comment_html на реально существующие доки (os.path.isfile по worktree). База settings.gitea_url + settings.gitea_owner.

Тесты (мой прогон сам): 207 passed + 9 failed (те же 9 baseline pre-existing signature/401, regression 0, +3 новых).

test_taskdesc_includes_description, test_name_fetched_when_payload_empty, test_analyst_comment_asks_approved_with_links. Обновлены 3 мока в test_pipeline_start_bugs.py (fetch_issue_description→fetch_issue_fields). Коммиты: fix(pipeline): pass issue description to analyst task file, fix(pipeline): fetch issue name from Plane API on status-trigger start, feat(plane): analyst comment asks for Approved status + links docs.

✅ БОЕВОЙ ПРОГОН — всё чисто:

Почистил прошлый прогон, #6 в Backlog с реальным name → In Progress → analyst run 62 (exit 0, 26302 out, $1.60). Логи: pulled name from Plane API ('Скачивание трека из popup на карте'), .task.md 973 байта, BRD осмысленный («Пользователь видит публичные GPS-треки... возможности скачать нет...»), comment.created no pipeline action, issue updated 38fb1f64 no pipeline action, analyst finished, requested Approved status. #6 = In Review ДЕРЖИТСЯ.

⚠️ Хвост (для следующей сессии):

  • Ссылки в комменте localhost → ИСПРАВЛЕНО в PR #14 (см. ниже).

PR #14 — ссылки в комменте на внешний Gitea (03.06 ~20:00)

Merge main = b01643f. Ветка fix/gitea-public-url, 1 коммит ca63bc2. Задеплоен.

  • Проблема: ссылки строились от settings.gitea_url = localhost:3000 (внутренний, для git-операций clone/push) → из браузера не кликаются. Менять gitea_url НЕЛЬЗЯ (сломает клоны).
  • Решение: новое поле gitea_public_url в config.py (env ORCH_GITEA_PUBLIC_URL), fallback на gitea_url при пустом. В _build_analyst_ready_comment (stage_engine.py ~299): base = (getattr(settings,'gitea_public_url','') or settings.gitea_url).rstrip('/'). gitea_url НЕ тронут.
  • Env на проде (ассистент дописал в .env, бэкап .env.bak-*): ORCH_GITEA_PUBLIC_URL=https://git.mva154.duckdns.org. Домен живой (HTTP 200).
  • Тесты сам: 208 passed + 9 baseline (regression 0).
  • ✅ Боевой прогон (task 29, run 63, exit 0, $1.37): ссылки в комменте = https://git.mva154.duckdns.org/admin/enduro-trails/.../ET-011/*.md — внешние, кликабельные. Коммент про Approved корректен. #6 = In Review держится.

Открытый хвост:

  • HTML коммента <p>...<ul>...</ul></p> — формально невалидная вложенность (Plane/TipTap переваривает, ссылки рабочие). Косметика.
  • #6 висит в In Review, ждёт Славу. Approved → должна уехать в Architecture БЕЗ мелькания In Progress (PR #12, ещё не проверено живьём). Слава решит: сам в UI или мне симулировать.
  • Боевая ветка теперь feature/ET-011-popup-enduro-trails (slug исправлен).

PR #14 — ссылки в комменте analyst: localhost → внешний публичный Gitea (03.06 ~20:50)

Merge main = b01643f. Ветка fix/gitea-public-url из main dce9ac8 (после PR #13). Один коммит ca63bc2 feat(config): external gitea_public_url for clickable doc links. Задеплоен.

Проблема

Ссылки на доки в комменте analyst строились от settings.gitea_url = http://localhost:3000 (env ORCH_GITEA_URL) — это ВНУТРЕННИЙ URL для git-операций (clone/push из docker), из браузера Славы не кликается.

Решение (НЕ менять gitea_url — он для git!)

  • src/config.py: новое поле gitea_public_url: str = "" (env ORCH_GITEA_PUBLIC_URL, префикс ORCH_, fallback на gitea_url).
  • src/stage_engine.py _build_analyst_ready_comment (~стр.299): base = (getattr(settings,"gitea_public_url","") or settings.gitea_url).rstrip("/"). Только эта строка.
  • gitea_url НЕ тронут — git-операции по-прежнему localhost.

Env на проде (ставила Я, не Dev): ORCH_GITEA_PUBLIC_URL=https://git.mva154.duckdns.org дописан в .env (аккуратно, не затирая), проверен в контейнере.

Тесты (мой прогон): 208 passed + 9 failed (те же baseline pre-existing). test_analyst_comment_asks_approved_with_links расширен (public задан→ссылки от него) + новый test_analyst_comment_falls_back_to_gitea_url.

✅ БОЕВОЙ ПРОГОН (task 29, run 63, exit 0, 20530 out, $1.37): ссылки в комменте на https://git.mva154.duckdns.org, кликабельны, все 6 доков. Коммент правильный (Approved/Rejected). #6 = In Review ДЕРЖИТСЯ.

⚠️ Состояние на конец сессии:

  • #6 висит в In Review, ждёт вердикта Славы в Plane (ссылки рабочие — глянуть доки → Approved или Rejected+причина).
  • НЕ проверено живьём: переход Approved → Architecture без мелькания In Progress (PR #12). Слава решит сам в UI или симулировать.
  • Был сбой PGPASSWORD на UPDATE статуса при ручном переводе #6 — webhook всё равно прошёл (analyst стартанул). Если повторять ручной перевод статуса через psql — подставлять реальный $PW, не литерал.
  • HTML коммента <p>...<ul>...</ul></p> — формально невалидная вложенность (Plane переваривает, косметика).

Хронология багов входа/выхода analyst (закрыто за сессию):

PR #12 (status-only verdict, баг3 эхо-самоудар) → PR #13 (баги A description, B name, C коммент+ссылки) → PR #14 (ссылки на внешний домен). Все боевые прогоны чистые, #6 In Review стабилен.

PR #15 — БАГ 4: Approved из analysis не двигал конвейер (03.06 ~20:32)

Merge main = b6aa107. Ветка fix/approved-advances-stage, коммит 0b8013c fix(stage): approved verdict advances analysis->architecture instead of re-running gate. Задеплоен.

  • Симптом (боевой, Слава нажал Approved на #6): лог advance from analysis → 200 OK, но task 29 застрял stage=analysis, architect НЕ запущен, в Architecture не уехало. Блокер.
  • Корень: stage_engine.py advance_stage ветка check_analysis_approved ВСЕГДА _handle_analysis_approved_flow(...) + return result → блок Advance недостижим. А _handle_analysis_approved_flow при agent=None (webhook Approved) делал return (т.к. if not (agent=='analyst' ...)). Два пути через один тупик.
  • Фикс: развести по finished_agent: agent=='analyst' (launcher) → approved-flow+return (In Review+коммент, как было); agent is None (Approved-вердикт) → НЕ заходить в flow, провалиться в общий Advance (update_task_stage(architecture)+enqueue architect).
  • Сама проверила ДО фикса: get_agent_for_stage('analysis')=architect, get_next_stage('analysis')=architecture → фикс не зациклит analyst.
  • Тесты сама: 210 passed + 9 baseline. Новый test_approved_verdict_advances_analysis_to_architecture зелёный.
  • ✅ БОЕВОЙ: догнала Approved (task 29 застрял) → послала Approved-вердикт → analysis -> architecture (auto-advance after None), enqueued architect job 11, run 64 pid 47. Plane #6 = Architecture (3020bbb7). Конвейер впервые прошёл стадию end-to-end через ручной Approved.
  • architect запущен, проектирует. Следить: создаст docs/work-items/ET-011/ архитектуру → Development.

Хронология (вся сессия): PR#12 (status-only, баг3 эхо) → PR#13 (баги A desc/B name/C коммент+ссылки) → PR#14 (ссылки внешний домен) → PR#15 (баг4 Approved-advance). Все боевые чистые.

PR #15 — БАГ 4: ручной Approved из analysis НЕ двигал конвейер (03.06 ~20:30) — БЛОКЕР, закрыт

Merge main = b6aa107. Ветка fix/approved-advances-stage из main b01643f (PR #14). Коммит 0b8013c fix(stage): approved verdict advances analysis->architecture instead of re-running gate. Задеплоен.

Симптом (боевой)

Слава перевёл #6 (task 29) в Approved из analysis. Лог: Task 29: Approved status -> advance from analysis → 200 OK, НО task остался stage=analysis, architect НЕ запущен, в Architecture не уехало. Конвейер встал на первой стадии.

Корень (src/stage_engine.py advance_stage, ~стр.193)

Ветка if qg_name == "check_analysis_approved": _handle_analysis_approved_flow(...); return result — ВСЕГДА ранний return → блок Advance (~стр.228: update_task_stage + enqueue_job) недостижим. А _handle_analysis_approved_flow (~стр.312) в начале if not (agent=="analyst" and work_item_id): return → на webhook-пути Approved (finished_agent=None) выходил ничего не сделав. Доп.нюанс: check_analysis_approved ищет :approved: коммент, а Слава ставил статус Approved → QG вернул бы False и снова заблокировал advance даже при простом fall-through.

Фикс — развести ветку по finished_agent

  • agent == "analyst" (launcher) → _handle_analysis_approved_flow + return (In Review + коммент, НЕ ломать).
  • agent is None (webhook Approved-вердикт) → result.qg_passed=True, qg_reason="approved-via-status", НЕ заходить во flow, НЕ перезапускать QG → провалиться в блок Advance (analysis→architecture + enqueue architect).
  • Прочие QG обёрнуты в else: passed,reason=_run_qg(...).

Подтверждено: get_agent_for_stage("analysis")=architect (не analyst!), get_next_stage("analysis")=architecture (src/stages.py:14). Зацикливания analyst нет.

Тесты: 210 passed + 9 pre-existing failed (test_webhooks HMAC/401). +2 новых: test_approved_verdict_advances_analysis_to_architecture (finished_agent=None→advanced/architecture/architect, QG замокан на fail = доказывает что гейт не перезапускается), test_launcher_path_does_not_advance_and_calls_flow (finished_agent=analyst→не advance, flow вызван). test_stage_engine: 18→20.

✅ БОЕВОЙ ПРОГОН (task 29): отправила Approved-вердикт заново → analysis→architecture auto-advance, #6 уехал в Architecture, architect запущен (job 11, run 64, pid 47), без мелькания In Progress. Первый полный end-to-end проход стадии через ручной Approved.

🔥 Конвейер поехал дальше сам (пока писала доки):

  • architect завершился (exit 0, 49758 tokens): создал docs/work-items/ET-011/06-adr/ADR-014-gpx-download-endpoint.md, ADR-015-source-redistribution-policy.md, 07-infra-requirements.md.
  • architecture → development auto-advance, developer запущен (run 65) — пишет код.
  • ⚠️ QG check_ci_green — failed: CI state: failure — CI красный (ожидаемо, кода ещё нет / early-fail). developer работает.
  • Итог: три стадии подряд (analysis→architecture→development) с одного Approved.

Документация обновлена (03.06) — по запросу Славы «обнови доки + запиши баги»

  • tasks/orchestrator/ORCHESTRATOR_DOCS.md: новый раздел «🐛 Баги входа/выхода analyst (03.06.2026)» — таблица 4 багов; обновлены статус-шапка, переходы статусов (status-only model PR#12), ссылки (gitea_public_url PR#14), webhook events, Changelog (PR #12–#15).
  • tasks/orchestrator/STATUS.md: свежий блок 03.06 + таблица багов сессии.
  • wiki ingest обеих доков (правило: при работе с проектами обновлять онтологию + wiki).

Сводка 4 багов сессии (для быстрой ссылки):

  • Баг 3 PR #12 (status-only verdict): эхо-самоудар — собственный апдейт статуса перезапускал стадию.
  • Баг A PR #13: description (Plane API, 445 симв) не попадал в .task.md (был 101-байт пустышка).
  • Баг B PR #13: name не тянулся → ветка untitled.
  • Баг C PR #13: устаревший коммент analyst «Жду :approved:» + нет ссылок на доки.
  • PR #14: ссылки в комменте на localhost:3000 → внешний gitea_public_url=https://git.mva154.duckdns.org.
  • Баг 4 PR #15 (БЛОКЕР): ручной Approved не продвигал analysis→architecture.

Хвост на следующую сессию:

  • Следить за developer (run 65) + CI: дойдёт ли до review/testing/deploy.
  • Старые разделы ORCHESTRATOR_DOCS про :approved:/:rejected: комментом — переписаны на status-only, но перепроверить остаточные упоминания в нижней части файла (~стр.100+).

Баги 5-6 закрыты (03.06 вечер) — конвейер дошёл до честного CI-гейта

Баг 5 (PR #16, main 994f73a): QG check_tests_local зависел от make (нет в контейнере)

  • src/qg/checks.py check_tests_local: ["make","test"] → ["python","-m","pytest","../../tests/","-v"], cwd=<repo>/src/api (1:1 с Makefile цели test). Коммит 90c9ffe.
  • Тесты: 213 passed + 9 baseline. Боевой прогон: make-бага ушла, но вылез баг 6.

Баг 6 (PR #17, main 7922f6b): локальный QG дублировал CI + гонял тесты enduro-trails в окружении оркестратора без зависимостей (lxml/shapely/defusedxml → ModuleNotFoundError)

  • Задумка check_tests_local изначально: S-1 затычка эпохи «Gitea CI не настроен → always false». CI теперь настроен (.gitea/workflows/ci.yml) → затычка устарела, дублирует check_ci_green в кривом окружении.
  • Вариант 1 (выбран Славой): довериться CI.
    • src/stages.py:16 development QG: check_tests_local → check_ci_green.
    • src/webhooks/gitea.py ~219: снято подавление CI-failure, теперь state==failure && stage==development → notify_qg_failure.
    • check_tests_local НЕ удалён, помечен DEPRECATED, остался в QG_CHECKS, не wired ни к одной стадии.
    • Коммит e15d339. Тесты: 215 passed + 10 failed (9 baseline + 1 новый webhook-тест на том же 401 HMAC-барьере — среда, не логика).
  • Деплой ✅, get_qg_for_stage("development")=="check_ci_green" подтверждён на проде.

🎯 Боевой прогон ET-011 (task 29): конвейер РАБОТАЕТ КАК ЗАДУМАНО

  • Прямой вызов handle_ci_status(success) → check_ci_green (double-check API) → False: CI state: failure → справедливо НЕ пропустил development→review. Логика верна.
  • Реальный CI ET-011: lint=failure (ruff стиль), test=success (тесты в правильном окружении ПРОХОДЯТ!), build=skipped.
  • Т.е. конвейер уперся не в свой косяк, а в РЕАЛЬНОЕ качество кода — линтер честно краснит на стиле. Здоровое состояние.

Хвост на след. сессию:

  • task 29 стоит в development, CI красный ТОЛЬКО из-за ruff lint (тесты зелёные).
  • Развилка: (A) developer-retry чтобы сам починил lint, или (B) глянуть на что ruff ругается. Слава склонялся глянуть ruff сначала.
  • HMAC webhook через curl/shell даёт 401 (подпись от raw body не сходится при shell-сериализации) — для боевых прогонов дёргать обработчики напрямую в python (docker exec orchestrator python3), а не через HTTP.

Итог сессии 03.06: закрыто 6 багов (PR #12-#17), конвейер прошёл analysis→architecture→development end-to-end, дошёл до честного CI-гейта на качестве кода.

Баг 7 закрыт (03.06 ночь) — конвейер САМОВОССТАНАВЛИВАЕТСЯ на красном CI 🔥

Баг 7 (PR #18, main a0621b9): красный CI на development не возвращал задачу developer'у

  • Дыра: после бага 6 CI стал авторитетным гейтом, но handle_ci_status при failure делал ТОЛЬКО notify_qg_failure → конвейер вис, требовал ручного вмешательства. Слава прямо спросил «почему автономно не ушло на девелопера».
  • Корень: retry developer'а был только на review request_changes (max 3x), на CI-failure ветки retry не было — побочка нашего же фикса бага 6 (достроили мост наполовину).
  • Фикс (по образцу review-retry): src/webhooks/gitea.py CI-failure ветка ~стр.219 — после notify_qg_failure добавлен блок: retry_count = COUNT agent_runs developer; if < MAX_DEV_RETRIES(=3) → enqueue_job("developer", attempt N/3); else notify_error escalating. Отличия от review: задача УЖЕ в development (без update_task_stage), branch из переменной branch. Коммит 3a285de.
  • Лимит: общий MAX_DEV_RETRIES=3 по ВСЕМ agent_runs developer'а (review+CI вместе ≤3) — по требованию Славы «ограничить как на ревью».
  • Тесты: 217 passed (215+2 pure-logic, вызов handle_ci_status напрямую с моками, не через TestClient → обход 401 HMAC baseline) + 10 baseline failed.

🎯🔥 БОЕВОЙ прогон — САМОВОССТАНОВЛЕНИЕ РАБОТАЕТ

  • Дёрнула CI-failure на ET-011 (task 29) → оркестратор АВТОНОМНО: увидел красный CI → check_ci_green failed → поставил developer'а в очередь (job 13) → запустил run_id=66 pid=45 (attempt 2/3). developer runs 1→2.
  • Лог: 🚀 ET-011: developer запущен (run_id=66). Без единого ручного пинка.
  • developer run 66 пошёл чинить 10× E402 в src/api/main.py (импорты не в шапке: shapely/typing/fastapi после кода на стр.20). Если починит → зелёный CI → development→review автономно.

Хвост на след. сессию:

  • Следить за developer run 66: починит ли E402, перезапушит ли, станет ли CI зелёным, поедет ли конвейер в review.
  • Если E402 — намеренный поздний импорт (после sys.path), developer может добавить noqa вместо перетасовки — оба варианта валидны.
  • Лимит retry: после 3 попыток developer'а суммарно (review+CI) — эскалация Славе.

ИТОГ сессии 03.06: закрыто 7 БАГОВ (PR #12-#18). Конвейер: analysis→architecture→development end-to-end + честный CI-гейт + АВТОНОМНОЕ самовосстановление на красном CI с лимитом попыток. Боевая обкатка на ET-011.

Reference in New Issue View Git Blame Copy Permalink