auto-sync: 2026-06-08 14:30:01

memory/2026-06-08.md

@@ -208,3 +208,31 @@
 - **Bump-режим ORCH-67 уже работает:** в логах deleteMessage→sendMessage (старая карточка вниз).
 - ИТОГ: ORCH-67 (Telegram tracker bump+статусы+кликабельные номера) в проде. Исходная проблема «ORCH-67 не подхватывается» закрыта ПОЛНОСТЬЮ. Цикл само-исцеления орка замкнут: фантом → восстановление main → root-fix ORCH-71 → боевая проверка на ORCH-67 успешна.
 - **КОНТРАСТ:** ORCH-71 я деплоила вручную (провенанс-гард ругнулся, manual Done). ORCH-67 — полностью автоматом через новый merge-verify. Разница = именно то, что ORCH-71 и чинила.
+
+## 🐛 БАГ ORCH-72 заведён + урок (статус-строка карточки врёт)
+- Слава заметил: карточка ORCH-69 показывала «📍 To Analyse» при пройденных всех стадиях.
+- **Root cause:** ORCH-67 `_STAGE_STATUS_LABEL` (src/notifications.py) НЕ покрывает стадию `deploy-staging` (и возможно др.) → падает в `_DEFAULT_STATUS_LABEL="To Analyse"` (худший фолбэк = первый статус). ORCH-69 был на deploy-staging.
+- **ORCH-72** (seq=72, id=e722a596) в Backlog: дополнить карту ВСЕМИ стадиями из stage_engine, фолбэк нейтральный (не To Analyse), deploy-staging→осмысленный лейбл. Косметика, не функционал.
+- **УРОК (ревью-чеклист):** при stage-зависимом маппинге — покрывать ВСЕ стадии из единого источника (STAGE_TRANSITIONS), фолбэк нейтральный. Моё ревью ORCH-067 это пропустило — карту стадий надо сверять поимённо, не «на глаз». Аналитик/архитектор взяли «основные» стадии, забыли служебные (deploy-staging).
+
+## 🕐 Московское время — план (делать ПОСЛЕ финала ORCH-69, по просьбе Славы)
+- **Цель Славы: один часовой пояс ВЕЗДЕ = Europe/Moscow.** Разнобой сейчас: хост mva154=MSK✅, контейнер орка=UTC❌, Стрим=UTC❌. (Часы хоста НЕ ушли — ORCH-64 неактуален, NTP active.)
+- **План:** (1) контейнер орка → `TZ=Europe/Moscow` в docker-compose (логи/карточки/уведомления→MSK), требует рестарт контейнера ~7с; (2) Стрим → перейти на MSK в общении со Славой.
+- **Когда:** Слава просил сделать ПОСЛЕ того как ORCH-69 добежит до финала (чтобы рестарт никого не прервал). Дождаться done ORCH-69 → поставить TZ.
+
+## 🐛 ORCH-72 РАСШИРЕН — 3 дефекта карточки (Слава выловил 2 и 3)
+- **Дефект 1:** статус-строка «To Analyse» на непокрытых стадиях (deploy-staging) — исходный.
+- **Дефект 2 (Слава):** карточка НЕ отражает откаты. При rollback merge-gate deploy-staging→development (ORCH-43, конфликт CHANGELOG) верхние ✅ (Код-ревью/Тест/Внедрение) не снимаются, внизу снова 🔄 Разработка. Абсурд «Внедрение ✅ + Разработка 🔄».
+- **Дефект 3 (Слава, ДЕНЬГИ):** стоимость/токены повторных попыток НЕ суммируются. Карточка берёт последний agent_run на стадию. ORCH-69 developer×3: run370=$3.05, run372=$0.26, run376=$0.68 = РЕАЛЬНО $3.98, карточка показала ~$0. Тотал занижен на ~$3.3. Нужно SUM(agent_runs) по (task,stage), не последний.
+- ORCH-72 desc обновлён: +G4(откаты)/G5(сумма попыток) +AC-6/AC-7. Это уже НЕ косметика — искажение учёта денег.
+- **Контекст:** ORCH-69 откатилась deploy-staging→development 3 раза из-за конфликта CHANGELOG.md (наши деплои 71/67 сегодня трогали CHANGELOG → ветка разошлась). Штатное самолечение merge-gate, но дорого (3× разработка).
+
+## 💡 УРОК (Слава просил записать): CHANGELOG.md = частый источник дорогих merge-конфликтов
+- **Наблюдение:** ORCH-69 откатилась deploy-staging→development 3 раза (merge-gate, конфликт CHANGELOG.md). Причина — несколько задач в один день (ORCH-71, 67, 69) добавляют записи в один и тот же файл CHANGELOG.md → ветки расходятся → rebase-конфликт на merge-gate → откат на разработку.
+- **Цена:** каждый откат = повторный запуск developer. ORCH-69 разработка 3× = $3.98 вместо ~$1. Конфликты CHANGELOG прямо жгут деньги.
+- **Системная проблема (кандидат в задачу):** при параллельных задачах CHANGELOG.md — гарантированная точка конфликта (все пишут в `## [Unreleased]`). Варианты решения для будущей задачи орка:
+  1. auto-rebase merge-gate должен УМЕТЬ разрешать CHANGELOG-конфликты автоматически (union-merge для append-only секции Unreleased), а не откатывать на development.
+  2. ЛИБО: не писать CHANGELOG в feature-ветке, а генерировать запись при merge в main (post-merge hook).
+  3. ЛИБО: .gitattributes merge=union для CHANGELOG.md (git сам сливает обе вставки).
+- Вариант 3 (`.gitattributes merge=union`) — самый дешёвый и точечный фикс. Рекомендую завести задачу, если откаты по CHANGELOG повторятся.
+- **Связь:** этот же CHANGELOG-конфликт — причина, по которой ORCH-71 я сливала вручную, а auto-rebase ORCH-69 трижды откатывал. Системная, повторяющаяся боль.