restore: re-merge ORCH-067 tracker bump+статусы+ссылки

2026-06-08 14:58:03 +03:00
parent affbb259a1 41da03470a
commit befa2979ec
32 changed files with 2431 additions and 70 deletions
--- a/docs/architecture/README.md
+++ b/docs/architecture/README.md
@@ -13,6 +13,7 @@
 - **Queue** (`src/queue_worker.py`, ORCH-1) — персистентная очередь задач (SQLite `jobs`), atomic claim, max_concurrency, ретраи, restart-safe.
 - **Job-reaper** (`src/job_reaper.py`, ORCH-065 — [adr-0011](adr/adr-0011-job-reaper-lease-reclaim.md)) — фоновый daemon-поток (каркас `reconciler`), стартует/останавливается в `main.lifespan` (после `reconciler.start()` / перед `worker.stop()`). Детектирует «мёртвый» `running`-job **без рестарта** процесса (Tier-1 мёртвый `jobs.pid` после `reaper_dead_ticks` тиков; Tier-2 `agent_runs.exit_code` записан, а job ещё `running`; Tier-3 backstop `reaper_max_running_s`) и приводит строку к корректному статусу через те же контракты (`_try_advance_stage`/`_finalize_job`, gate-driven; exit≠0/неизвестно → `attempts<max`→`queued`, иначе `failed`+Telegram). Атомарный reap-claim (guard `status='running'`) совместим со стартовым `requeue_running_jobs`. Тот же поток периодически делает проактивный реклейм stale/dead merge-lease (см. ниже). never-raise; kill-switch `ORCH_REAPER_ENABLED`; снимок в `GET /queue` (блок `reaper`).
 - **Reconciler** (`src/reconciler.py`, ORCH-053 — реализовано, [adr-0007](adr/adr-0007-reconciler.md)) — фоновый daemon-поток (паттерн `queue_worker`), стартует/останавливается в `main.lifespan` (после `worker.start()` / перед `worker.stop()`). Реконсилирует рассинхрон «источник истины ≠ стадия задачи» при потерянном webhook. F-1 gate-side (продвигает застрявшую стадию по локальной БД через штатный `advance_stage(..., finished_agent=None)`), F-2 plane-side (опрос Plane API → `handle_*` из `plane.py`), F-3 (БД-fallback `sha→branch` в `handle_ci_status`). Источник истины — гейт/Plane, не событие; идемпотентность (active-job guard + atomic-claim + grace); kill-switch `ORCH_RECONCILE_ENABLED`. `analysis` F-1 не трогает (человеческий гейт). F-1 также пропускает escalated (retry≥лимита) и Blocked/Needs-Input задачи (ORCH-060). Наблюдаемость — блок `reconcile` в `GET /queue`.
+- **Notifications / Live-tracker** (`src/notifications.py`, ORCH-042/ORCH-067) — ОДНА live-карточка на задачу (`update_task_tracker`), обновляется на каждом переходе. Режим `ORCH_TRACKER_MODE` (дефолт `bump` с ORCH-067: delete+silent send+repoint внизу чата; `edit` — правка на месте). Карточка несёт строку Plane-статуса `📍 …` (оффлайн-ядро `plane_status_label` + best-effort live-overlay `_live_plane_branch_override`, kill-switch `ORCH_TRACKER_LIVE_STATUS`) и кликабельный номер задачи (`plane_issue_link`/`link_for` → ссылка в Plane, fail-safe на сырой номер). Все алерты, упоминающие `work_item_id`, делают номер кликабельным. Контракт всего компонента — never raises; карточка всегда silent. Детали — [internals.md](internals.md) §7.
 - **Project Registry** (`src/projects.py`, ORCH-6) — Plane project id → repo + prefix; фильтрация вебхуков по проекту.
 - **Plane Sync** (`src/plane_sync.py`) — синхронизация статусов/комментариев в Plane. Резолв статусов проекта `get_project_states` (ORCH-10) кэширует `{logical_key→uuid}` per-project; **ORCH-068** добавляет в кэш-запись `{uuid→group}` (для терминал-исключения F-2) и **TTL** `ORCH_PLANE_STATES_TTL_S` (дефолт 300с; `0` → прежний lifetime-кэш) — устаревший набор статусов самозалечивается без рестарта процесса через существующий `reload_project_states()` (баг кэша после появления нового Plane-статуса). Форма возврата `get_project_states` неизменна (обратная совместимость).

--- a/docs/architecture/internals.md
+++ b/docs/architecture/internals.md
@@ -111,12 +111,12 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash

 Вместо ~15 отдельных сообщений на задачу оркестратор держит **ОДНУ** live-карточку на задачу (`update_task_tracker`), которая обновляется на каждом переходе стадии. Текст рендерится статически из БД (`render_task_tracker`: стадии, токены, стоимость, BRD-подтверждение, итоги). Карточка всегда тихая (`disable_notification=True`); отдельные пинги шлют только `notify_approve_requested` / `notify_error`. `message_id` хранится в `tasks.tracker_message_id`; helpers `get_tracker_message_id` / `set_tracker_message_id`. Контракт всего компонента — **never raises**.

-**Режимы (ORCH-042, `ORCH_TRACKER_MODE` → `Settings.tracker_mode`).** Резолвится в `update_task_tracker` (case-insensitive, trim); всё, что ≠ `"bump"` (включая пустое/мусор/None), трактуется как `edit` → нулевая регрессия и безопасный фолбэк. Инвариант «одна карточка на задачу» сохраняется в обоих режимах.
+**Режимы (ORCH-042, `ORCH_TRACKER_MODE` → `Settings.tracker_mode`; дефолт переключён `edit → bump` в ORCH-067).** Резолвится в `update_task_tracker` (case-insensitive, trim); всё, что ≠ `"bump"` (включая пустое/мусор/None), трактуется как `edit` → безопасный фолбэк. Инвариант «одна карточка на задачу» сохраняется в обоих режимах.

 | Режим | Поведение при обновлении |
 |-------|--------------------------|
-| `edit` (дефолт) | первый вызов → `send_telegram` (тихо) + сохранение `message_id`; далее → `edit_telegram` на сохранённый id. Новое сообщение шлётся ТОЛЬКО при `EDIT_GONE` (удалено/старше 48ч/невалидный id). `EDIT_NOT_MODIFIED` / `EDIT_FAILED` → нового сообщения нет (анти-дубль). |
-| `bump` | карточка пересоздаётся внизу чата: best-effort `delete_telegram(старый_id)` → `send_telegram(text, disable_notification=True)` → `set_tracker_message_id(new_id)` **только** при успешном send (`new_mid is not None`). За один вызов — не более одного нового сообщения. |
+| `bump` (дефолт, ORCH-067) | карточка пересоздаётся внизу чата: best-effort `delete_telegram(старый_id)` → `send_telegram(text, disable_notification=True)` → `set_tracker_message_id(new_id)` **только** при успешном send (`new_mid is not None`). За один вызов — не более одного нового сообщения. Живая карточка всегда «догоняет» переписку. |
+| `edit` | первый вызов → `send_telegram` (тихо) + сохранение `message_id`; далее → `edit_telegram` на сохранённый id. Новое сообщение шлётся ТОЛЬКО при `EDIT_GONE` (удалено/старше 48ч/невалидный id). `EDIT_NOT_MODIFIED` / `EDIT_FAILED` → нового сообщения нет (анти-дубль). |

 **`delete_telegram(message_id) -> bool`** (low-level, never raises). Семантика возврата — «исчезло ли старое сообщение»:
 - `ok:true` → `True`;
@@ -128,6 +128,12 @@ claude.exe --print  --system-prompt  --allowedTools Read,Write,Edit,Bash

 **Текст карточки (оба режима, ORCH-042):** метка `Подтверждение BRD` (была «Ревью БРД»); после прохождения approve-gate строка BRD начинается с ✅ (ветка ожидания сохраняет ⏸️/⏳); русские display-labels стадий (`Анализ / Архитектура / Разработка / Код ревью / Тестирование / Внедрение`); финальная строка `📦 Внедрено` (было `deployed`). Меняются только отображаемые строки — ключи стадий и имена агентов (завязаны на `_STAGE_ACTIVE_AGENT`, `last_done`, БД) не трогаются.

+**Строка Plane-статуса и кликабельный номер (ORCH-067, слой B — индикация).** Под заголовком карточка несёт строку `📍 <Plane-статус>` по модели ORCH-066. Источник — двухслойный, контракт **never raises**:
+- **Оффлайн-ядро** `plane_status_label(task_row)` — чистая функция БЕЗ сети: `stage → статус` (`created→To Analyse`, `analysis→Analysis`, `architecture→Architecture`, `development→Development`, `review→Code-Review`, `testing→Testing`, `deploy→⏸️ Awaiting Deploy`, `done→Done`) + `⏸️ In Review` из brd-часов (`brd_review_started_at` задан, `…_ended_at` пуст). Неизвестная/битая стадия → безопасный дефолт `To Analyse`.
+- **Live-overlay** `_live_plane_branch_override` — best-effort: дорисовывает ветви-статусы, неразличимые оффлайн (Needs Input / Blocked / Rejected / Cancelled / Deploying / Monitoring after Deploy), чтением живого Plane-статуса (`fetch_issue_state` с коротким `tracker_live_status_timeout_s`, TTL-кэш `tracker_live_status_ttl_s`, kill-switch `tracker_live_status`). Любой сбой / выключенный флаг / нехватка данных → оффлайн-метка; `⏸️ In Review` (авторитет brd-часов) overlay не консультирует. Анти-false-positive: `deploying/monitoring`, алиасящие базовый UUID на проекте без выделенного статуса (enduro), не вызывают override.
+
+**Кликабельный номер задачи (ORCH-067).** Номер в заголовке карточки И во всех уведомлениях орка, где упоминается `work_item_id`, — HTML-ссылка на issue в Plane через общий `plane_issue_link` / `link_for` (URL строит `_plane_issue_url` с loopback/workspace/project-гардами, переиспользуя резолв ORCH-017). Fail-safe: при нехватке любого из (web-base/не-loopback, workspace, project_id, plane_issue_id) → `html.escape(work_item_id)` без `<a>`; динамические части экранируются, `<a>`-разметка валидна под `parse_mode=HTML`. Алерты `stage_engine`/`launcher`/`security_gate`/`reconciler` переведены на `link_for` (резолвит `repo`+`plane_issue_id` из БД по `task_id` или `work_item_id`).
+
 ## Database Schema

 ```sql
--- a/docs/work-items/ORCH-067/00-business-request.md
+++ b/docs/work-items/ORCH-067/00-business-request.md
@@ -0,0 +1,7 @@
+# Business Request: [высокий] Telegram tracker: bump + статусы Plane + кликабельный номер задачи
+
+Work Item ID: ORCH-067
+
+## Description
+
+TBD
--- a/docs/work-items/ORCH-067/01-brd.md
+++ b/docs/work-items/ORCH-067/01-brd.md
@@ -0,0 +1,158 @@
+# BRD — ORCH-067: Telegram tracker (bump + статусы Plane + кликабельный номер задачи)
+
+Work Item: **ORCH-067**
+Тип: **Багфикс + enhancement**
+Приоритет: высокий
+Компонент: Telegram live-tracker и уведомления оркестратора (`src/notifications.py`)
+Расширяет: открытый баг seq=55 («bump не сработал, регресс ORCH-042»)
+
+---
+
+## 1. Бизнес-контекст и проблема
+
+Оркестратор ведёт по одной «живой карточке» (live-tracker) на каждую задачу в Telegram
+(`src/notifications.py`). Карточка тихо обновляется на каждом переходе стадии, а отдельными
+пингами шлются только события, требующие внимания владельца (approve-gate, деплой-фейл,
+падение агента, ошибка задачи).
+
+Сейчас есть четыре боли:
+
+1. **bump не работает в проде.** Диагностика оператора: код режима `bump` в
+   `update_task_tracker` корректен (delete старого → sendMessage вниз → repoint
+   `tracker_message_id`), НО в проде `tracker_mode="edit"` (дефолт `src/config.py:408`),
+   а `ORCH_TRACKER_MODE=bump` не выставлен. Карточка обновляется edit-in-place и остаётся
+   «вверху» ленты, тонет под новыми сообщениями — наблюдатель не видит актуального
+   состояния без скролла.
+
+2. **Карточка показывает внутренние названия стадий, а не Plane-статусы.** После ввода
+   осмысленной статусной модели Plane (ORCH-066) карточка по-прежнему рендерит внутренние
+   ярлыки стадий (Анализ/Архитектура/…), а текущий статус задачи в терминах, понятных
+   наблюдателю в Plane (To Analyse → Analysis → In Review → … → Done), в шапке карточки
+   не отражён. Особенно теряется состояние **ожидания согласования BRD** = Plane-статус
+   `In Review`: сейчас это лишь строка «✅/⏸️ Подтверждение BRD … ⏳», не выраженная как
+   полноценный статус.
+
+3. **Номер задачи в карточке некликабелен.** `ORCH-066` в карточке — обычный текст;
+   чтобы открыть задачу в Plane, наблюдателю приходится искать её вручную.
+
+4. **Номер задачи некликабелен и во всех остальных уведомлениях орка** (approve-requested,
+   QG-fail, deploy SUCCESS/FAIL, Needs Input, прод-деплой и т. п.) — везде, где упоминается
+   `work_item_id`, это просто текст.
+
+## 2. Цель
+
+Сделать live-tracker и уведомления орка наблюдаемыми «из коробки»:
+- bump работает по умолчанию (карточка падает вниз свежим сообщением при каждом обновлении,
+  ровно одна карточка на задачу, без спама и дублей);
+- карточка явно показывает текущий Plane-статус по модели ORCH-066, включая человеческие
+  гейты (`⏸️ In Review` — согласование BRD, `⏸️ Awaiting Deploy` — ожидание Confirm Deploy,
+  `❓ Needs Input` — нужны уточнения);
+- номер задачи кликабелен в карточке и во всех Telegram-уведомлениях орка и ведёт на
+  страницу задачи в Plane.
+
+## 3. Заинтересованные стороны
+
+- **Owner (Слава)** — основной потребитель карточки и уведомлений; источник 4 требований.
+- **Агенты конвейера** — косвенно (карточка отражает их прогресс; поведение агентов не меняется).
+- **Другие проекты (enduro-trails)** — общий инстанс/БД; изменения не должны вызывать регресс.
+
+## 4. Объём работ (scope)
+
+### 4.1. Требование 1 — bump по умолчанию
+- Режим `bump` должен быть поведением по умолчанию: при каждом обновлении карточка
+  удаляется и пересоздаётся внизу ленты, одна карточка на задачу, тихо
+  (`disable_notification`), без дублей.
+- Инвариант «одна карточка на задачу» сохраняется в обоих режимах (`edit` остаётся как
+  опция через env).
+- Транзиентный фейл `send` не должен обнулять `tracker_message_id` и плодить дубли
+  (инвариант уже заложен в коде — сохранить).
+
+### 4.2. Требование 2 — статусы карточки как в Plane (модель ORCH-066)
+- В шапке/верхней части карточки явно отображается **текущий Plane-статус** задачи по
+  модели ORCH-066.
+- Полный маппинг состояний (имена — финальные из модели ORCH-066):
+  ```
+  To Analyse → Analysis → In Review (⏸️ ожидание согласования BRD) → Architecture →
+  Development → Code-Review → Testing → Awaiting Deploy (⏸️ ожидание Confirm Deploy) →
+  Deploying → Monitoring after Deploy → Done
+  ```
+  Ветки: `Needs Input` (аналитик задал вопросы), `Blocked`, `Rejected`, `Cancelled`.
+- Человеческие гейты отражаются как ПОЛНОЦЕННЫЕ статусы с паузой:
+  - согласование BRD → «⏸️ In Review — ожидание согласования BRD»;
+  - ожидание прод-деплоя → «⏸️ Awaiting Deploy — ожидание Confirm Deploy»;
+  - вопросы аналитика → «❓ Needs Input — нужны уточнения».
+- Существующая семантика строки «Подтверждение BRD» сохраняется (время ожидания/«твоё
+  время»), но статус карточки при этом явно показывает In Review (approve-pending).
+
+### 4.3. Требование 3 — кликабельный номер задачи в карточке
+- `work_item_id` (напр. `ORCH-066`) в карточке — гиперссылка на страницу задачи Plane:
+  `https://<PLANE_WEB_BASE>/<workspace_slug>/projects/<project_id>/issues/<issue_id>/`.
+- Источники частей URL:
+  - `PLANE_WEB_BASE` — из конфигурации (env, поле `plane_web_url` / `ORCH_PLANE_WEB_URL`;
+    значение прод — `plane.mva154.duckdns.org`); fail-safe: не задан → номер без ссылки;
+  - `workspace_slug` — `plane_workspace_slug` (уже есть в settings, прод — `ag_proj`);
+  - `project_id` — резолвится per-task по репозиторию задачи (ORCH / Sandbox);
+  - `issue_id` (UUID) — из БД: колонка `tasks.plane_issue_id`.
+- Рендер через `<a href="...">ORCH-NNN</a>` (`parse_mode=HTML` уже включён);
+  HTML в title/тексте экранируется, чтобы не сломать разметку.
+
+### 4.4. Требование 4 — кликабельный номер во ВСЕХ уведомлениях орка
+- Единый хелпер (напр. `plane_issue_link(work_item_id, plane_issue_id, project_id) -> html`)
+  строит кликабельный номер с fail-safe; применяется во всех точках `send_telegram`/
+  `notify_*`, где упоминается `work_item_id` (approve-requested, QG-fail, deploy
+  SUCCESS/FAIL, Needs Input, прод-деплой, alert'ы launcher/merge_gate/job_reaper/
+  security_gate/reconciler/main).
+
+## 5. Вне объёма (out of scope)
+
+- Транспорт `send_telegram` / `edit_telegram` / `delete_telegram` (parse_mode HTML уже есть) — не трогать.
+- Инвариант «одна карточка на задачу» — не нарушать (не плодить дубли).
+- Логика `disable_notification` (карточка тихая; пингуют только alert-хелперы) — не трогать.
+- `STAGE_TRANSITIONS`, Quality Gates, схема БД — НЕ менять.
+- Изменение поведения агентов/конвейера.
+
+## 6. Зависимости
+
+- Маппинг статусов (требование 2) опирается на статусную модель ORCH-066. ORCH-066 уже в
+  конвейере на стадии deploy. Эту задачу делать ПОСЛЕ прода ORCH-066, чтобы имена статусов
+  совпали. Если ORCH-066 ещё не в проде на момент разработки — использовать согласованные
+  финальные имена из модели: To Analyse, Analysis, Code-Review, Awaiting Deploy, Deploying,
+  Monitoring after Deploy, In Review, Needs Input, Blocked, Cancelled, Done.
+- Конфигурация `plane_web_url` / `plane_workspace_slug` уже существует в `src/config.py`
+  (ORCH-017); реестр проектов `src/projects.py` (`get_project_by_repo().plane_project_id`)
+  уже даёт per-task project_id.
+
+## 7. Fail-safe (обязательно)
+
+- Нет `PLANE_WEB_BASE` / нет `plane_issue_id` / нет `project_id` / loopback-база →
+  показывать номер БЕЗ ссылки, **не падать**.
+- HTML-экранирование пользовательского текста (title и пр.) во всех сообщениях с
+  `parse_mode=HTML`.
+- Bump: транзиентный фейл `send` не обнуляет `tracker_message_id` и не плодит дубли.
+- Любая ошибка построения статуса/ссылки никогда не должна ронять рендер карточки или
+  отправку уведомления (degrade gracefully).
+
+## 8. Критерии успеха (Definition of Done)
+
+- Bump работает из коробки: карточка падает вниз при обновлении, одна на задачу.
+- Карточка показывает Plane-статус новой модели, включая `⏸️ In Review` (согласование BRD),
+  `⏸️ Awaiting Deploy`, `❓ Needs Input`.
+- Номер задачи кликабелен в карточке И во всех уведомлениях орка (ведёт на страницу Plane).
+- Fail-safe покрыт тестами (нет URL/plane_id/project → без ссылки, не падает;
+  HTML-экранирование).
+- `pytest tests/ -q` зелёный.
+- Документация обновлена в том же PR: `CLAUDE.md` (раздел нотификаций/tracker),
+  `CHANGELOG.md`, ADR per-work-item.
+
+## 9. Риски
+
+- **Регресс enduro-trails.** Смена дефолта `tracker_mode` на bump меняет поведение для всех
+  проектов. Митигация: bump уже реализован и протестирован концептуально; инвариант «одна
+  карточка» сохранён; env-переключатель `edit` остаётся.
+- **Поломка HTML-разметки** при неэкранированном title → сообщение не доставится. Митигация:
+  обязательное `html.escape` + тесты.
+- **Источник «истинного» Plane-статуса** для веток, не выводимых из `tasks.stage`
+  (Needs Input/Blocked/Rejected/Cancelled, Deploying/Monitoring), при запрете на изменение
+  схемы БД — архитектурное решение (ADR), с обязательным fail-safe (без сети не падать).
+- **Self-hosting.** Орк правит сам себя; обязательна страховка через staging (8501) перед
+  прод-деплоем; прод-контейнер не ронять в рамках задачи.
--- a/docs/work-items/ORCH-067/02-trz.md
+++ b/docs/work-items/ORCH-067/02-trz.md
@@ -0,0 +1,205 @@
+# ТЗ — ORCH-067: Telegram tracker (bump + статусы Plane + кликабельный номер задачи)
+
+Work Item: **ORCH-067**
+Документ описывает КОНКРЕТНЫЕ изменения кода/конфигурации/тестов и документации.
+Архитектурные развилки помечены `[ARCH]` — решение принимает архитектор (ADR), здесь
+зафиксированы только требования и ограничения к ним.
+
+---
+
+## 0. Задействованные модули `src/`
+
+| Модуль | Роль в задаче |
+|---|---|
+| `src/config.py` | Дефолт `tracker_mode`; поле `plane_web_url`/`plane_workspace_slug` (уже есть). |
+| `src/notifications.py` | Основные изменения: bump-дефолт, статус-строка карточки, хелпер ссылки, применение хелпера в `notify_*`. |
+| `src/plane_sync.py` | Источник имён статусов/маппинга ORCH-066 (`_PLANE_NAME_TO_KEY`, `_STAGE_TO_STATE_KEY`); при необходимости reverse-map UUID→имя `[ARCH]`. |
+| `src/projects.py` | `get_project_by_repo(repo).plane_project_id` — per-task project_id для ссылки. |
+| `src/db.py` | Чтение `tasks.plane_issue_id`, `tasks.repo` (без изменений схемы). |
+| `src/stage_engine.py`, `src/agents/launcher.py`, `src/merge_gate.py`, `src/job_reaper.py`, `src/security_gate.py`, `src/reconciler.py`, `src/main.py` | Точки `send_telegram`, где есть `work_item_id` — применить хелпер ссылки (требование 4). |
+
+Изменения API (HTTP endpoints) — **нет**. Изменения схемы БД — **нет**. Новые QG checks — **нет**.
+
+---
+
+## 1. Требование 1 — bump по умолчанию
+
+### 1.1. Изменение
+- `src/config.py` (~стр. 408): сменить дефолт
+  `tracker_mode: str = "edit"` → `tracker_mode: str = "bump"`.
+- Обновить docstring-комментарий рядом (ORCH-042): отметить, что **дефолт теперь `bump`**,
+  `edit` остаётся доступен через `ORCH_TRACKER_MODE=edit`.
+
+### 1.2. Без изменений (сохранить инвариант)
+- Логика `update_task_tracker` (`src/notifications.py`, ветка `if mode == "bump"`):
+  `delete_telegram(old)` best-effort → `send_telegram(text, disable_notification=True)` →
+  `set_tracker_message_id` ТОЛЬКО при `new_mid is not None`. Не менять.
+- `send_telegram`/`edit_telegram`/`delete_telegram` — не трогать.
+
+### 1.3. Прод-аспект
+- Для прод-инстанса орка можно дополнительно выставить `ORCH_TRACKER_MODE=bump` в `.env`
+  на хосте (как страховку), но код должен работать «из коробки» и без env. Канон env —
+  `.env.example` (обновить, если там фигурирует tracker_mode).
+
+---
+
+## 2. Требование 2 — статус-строка карточки по модели ORCH-066
+
+### 2.1. Новый чистый хелпер маппинга
+Добавить в `src/notifications.py` функцию, возвращающую отображаемый Plane-статус для
+карточки на основе доступных данных задачи. Сигнатура (ориентир):
+```python
+def plane_status_label(task_row) -> str:
+    """Вернуть строку текущего Plane-статуса для шапки карточки (с emoji).
+    Никогда не падает: на неизвестном входе -> разумный дефолт по stage."""
+```
+Хелпер обязан быть чистым/детерминированным от входных данных и **никогда не бросать**
+исключения (любая ошибка → дефолт по `stage`, рендер карточки не ломается).
+
+### 2.2. Маппинг внутреннее состояние → Plane-статус (обязательные строки)
+Имена статусов — финальные из модели ORCH-066 (см. `_PLANE_NAME_TO_KEY` в `plane_sync.py`).
+
+| Источник (данные задачи в БД) | Plane-статус (отображение в карточке) |
+|---|---|
+| `stage == "created"` | `To Analyse` |
+| `stage == "analysis"`, BRD-clock не запущен | `Analysis` |
+| `stage == "analysis"`, `brd_review_started_at` есть, `brd_review_ended_at` пуст | `⏸️ In Review — ожидание согласования BRD` |
+| `stage == "architecture"` | `Architecture` |
+| `stage == "development"` | `Development` |
+| `stage == "review"` | `Code-Review` |
+| `stage == "testing"` | `Testing` |
+| `stage == "deploy"` (ожидание Confirm Deploy) | `⏸️ Awaiting Deploy — ожидание Confirm Deploy` |
+| `stage == "done"` | `Done` |
+
+Ветки (Needs Input / Blocked / Rejected / Cancelled / Deploying / Monitoring after Deploy):
+- `❓ Needs Input — нужны уточнения` — состояние «аналитик задал вопросы»;
+- `Blocked`, `Rejected`, `Cancelled`, `Deploying`, `Monitoring after Deploy`.
+
+`[ARCH]` **Источник сигнала для веток, не выводимых из `tasks.stage`** (Needs Input,
+Blocked, Rejected, Cancelled, Deploying, Monitoring after Deploy):
+- запрещено менять схему БД (нельзя добавлять колонку-флаг);
+- варианты для архитектора: (а) best-effort чтение живого Plane-статуса
+  (`fetch_issue_state` + reverse-map UUID→имя через `get_project_states`/
+  `_PLANE_NAME_TO_KEY`) с обязательным fail-safe (нет сети/ответа → деградация на
+  stage-маппинг, без задержки, блокирующей конвейер); (б) только stage-выводимые статусы,
+  а ветки — по уже имеющимся сигналам (например, In Review через brd-clock).
+- ОБЯЗАТЕЛЬНО к покрытию (DoD): `⏸️ In Review`, `⏸️ Awaiting Deploy`, `❓ Needs Input`.
+  In Review полностью выводится из brd-clock (см. таблицу) и должен работать без сети.
+
+### 2.3. Встраивание в `render_task_tracker`
+- В `render_task_tracker` (`src/notifications.py`) добавить в шапку/верх карточки отдельную
+  СТРОКУ статуса (под заголовком `🛠️ ORCH-NNN · <title>` / над разделителем `bar`),
+  напр.: `📍 <status_label>`.
+- Существующие строки по стадиям (`✅ done` / `🔄 active`), строка «Подтверждение BRD»,
+  тоталы токенов/стоимости, done-строка с PR/⏱️ — СОХРАНИТЬ (семантику не ломать).
+- Семантика строки «Подтверждение BRD» (⏸️+⏳ при ожидании, ✅ при пройденном гейте)
+  сохраняется; новая статус-строка дублирует её смысл в терминах Plane-статуса.
+
+---
+
+## 3. Требование 3 + 4 — кликабельный номер задачи
+
+### 3.1. Единый хелпер
+Добавить в `src/notifications.py`:
+```python
+def plane_issue_link(work_item_id, plane_issue_id=None, project_id=None, repo=None) -> str:
+    """Вернуть HTML с кликабельным номером задачи (<a href=...>ORCH-NNN</a>),
+    либо просто html.escape(work_item_id), если ссылку построить нельзя.
+    Никогда не падает."""
+```
+Поведение:
+- База URL: `settings.plane_web_url` → fallback `settings.plane_api_url`; loopback-база
+  (`localhost`/`127.0.0.1`/…) трактуется как «нет web URL» (переиспользовать
+  `_is_loopback_base`).
+- `workspace_slug`: `settings.plane_workspace_slug`.
+- `project_id`: явный аргумент → иначе резолв по `repo` через
+  `get_project_by_repo(repo).plane_project_id`.
+- `issue_id`: `plane_issue_id` (UUID из `tasks.plane_issue_id`).
+- URL-шаблон: `{web_base}/{workspace}/projects/{project_id}/issues/{issue_id}/`.
+- Текст ссылки = `html.escape(work_item_id)`; `href` = `html.escape(url, quote=True)`.
+- **Fail-safe:** если не хватает любого из (`web_base` валидный/не loopback, `workspace`,
+  `project_id`, `plane_issue_id`) → вернуть `html.escape(work_item_id)` (номер без ссылки).
+- Логика построения URL уже существует в `_build_plane_issue_link` (ORCH-017) — допустимо
+  переиспользовать/обобщить её, разнеся «текст-ссылки = номер» и «текст-ссылки = `✅ Задача
+  в Plane`», чтобы не дублировать резолв проекта и loopback-guard.
+
+### 3.2. Применение в карточке (требование 3)
+- В `render_task_tracker` заголовок строится из `work_item_id`. Заменить
+  `html.escape(work_item_id)` в обоих вариантах заголовка (done / not-done) на
+  `plane_issue_link(work_item_id, plane_issue_id, repo=repo)` — номер становится
+  кликабельным.
+- Для этого `render_task_tracker` должен дополнительно выбрать из БД `repo` и
+  `plane_issue_id` (расширить существующий `SELECT` по `tasks`). Схему НЕ менять — колонки
+  уже есть.
+- `title` уже экранируется (`html.escape(title)`) — сохранить.
+
+### 3.3. Применение во всех уведомлениях (требование 4)
+Во всех точках `send_telegram`/`notify_*`, где в тексте есть `work_item_id`, заменить
+«сырой» номер на `plane_issue_link(...)`. Перечень точек (из `src`):
+- `src/notifications.py`: `notify_approve_requested`, `notify_error`
+  (и любые будущие notify_* с work_item_id);
+- `src/stage_engine.py`: все `send_telegram(...)` с `work_item_id`
+  (≈ строки 613, 672, 719, 776, 820, 916, 971, 1057, 1134, 1192, 1228, 1257, 1355, 1367,
+  1425, 1447, 1601 — проверить каждую: применять ТОЛЬКО где упоминается номер задачи);
+- `src/agents/launcher.py`: deploy-failed alert (≈685–686), agent-failed alert (≈698–699),
+  alert ≈821–822;
+- `src/merge_gate.py` (≈431–432);
+- `src/job_reaper.py` (≈395–396);
+- `src/security_gate.py` (≈673–674);
+- `src/reconciler.py` (≈449);
+- `src/main.py` (≈45–47).
+
+`[ARCH]` Способ доступа к `plane_issue_id`/`project_id` в каждой точке (часто там уже есть
+`work_item_id`, но не обязательно `plane_issue_id`): хелпер должен уметь резолвить
+недостающее по `repo`/БД, оставаясь fail-safe. Допустимо добавить тонкую обёртку, которая по
+`work_item_id`/`task_id` достаёт `repo`+`plane_issue_id` из БД и зовёт `plane_issue_link`
+(аналогично существующему `_get_task_link_fields`). Везде, где данных нет — деградация на
+просто номер, без падения.
+
+### 3.4. HTML-экранирование
+- `parse_mode=HTML` уже стоит в `send_telegram`/`edit_telegram`. Любой пользовательский
+  текст (title, описания, причины QG-fail, сообщения об ошибках), попадающий в сообщение с
+  ссылками, должен экранироваться `html.escape`, чтобы не сломать `<a>`-разметку.
+
+---
+
+## 4. Конфигурация
+
+- `plane_web_url` (env `ORCH_PLANE_WEB_URL`) — уже существует (`src/config.py`), значение
+  прод — `plane.mva154.duckdns.org` (схему `https://` учесть при сборке URL).
+  Дополнительных полей конфигурации не требуется.
+- `tracker_mode` — сменить дефолт на `bump` (раздел 1).
+- Обновить `.env.example`, если в нём фигурируют `ORCH_TRACKER_MODE` / `ORCH_PLANE_WEB_URL`
+  (канон секретов/настроек — `.env.example`, не коммитить реальные секреты).
+
+---
+
+## 5. Артефакты pipeline, которые должны быть созданы/обновлены
+
+- `docs/work-items/ORCH-067/06-adr/ADR-NNN-*.md` — архитектурное решение (минимум: источник
+  «истинного» Plane-статуса для веток при запрете изменения схемы БД; дефолт bump; единый
+  хелпер ссылки).
+- `CLAUDE.md` — раздел про нотификации/tracker (дефолт bump; статус-строка карточки;
+  кликабельный номер в карточке и уведомлениях).
+- `CHANGELOG.md` — запись ORCH-067.
+- `docs/architecture/README.md` — при необходимости синхронизировать описание tracker'а.
+
+---
+
+## 6. Ограничения (что НЕ трогать)
+
+- Транспорт `send_telegram`/`edit_telegram`/`delete_telegram`.
+- Инвариант «одна карточка на задачу».
+- Логику `disable_notification` (карточка тихая; пингуют только alert-хелперы).
+- `STAGE_TRANSITIONS`, Quality Gates, схему БД.
+- Поведение агентов/конвейера.
+
+---
+
+## 7. Замечания по самохостингу
+
+Орк правит сам себя в проде (общий инстанс/БД с enduro-trails):
+- НЕ перезапускать прод-контейнер `orchestrator` в рамках задачи.
+- Обязательная страховка через `deploy-staging` (8501) до прод-деплоя.
+- Смена дефолта `tracker_mode` затрагивает ВСЕ проекты — проверить отсутствие регресса для
+  enduro-trails (тесты + staging-наблюдение карточки).
--- a/docs/work-items/ORCH-067/03-acceptance-criteria.md
+++ b/docs/work-items/ORCH-067/03-acceptance-criteria.md
@@ -0,0 +1,129 @@
+# Acceptance Criteria — ORCH-067
+
+Work Item: **ORCH-067**
+Каждый критерий формулирует чёткое условие PASS/FAIL. Привязка к тестам — в `04-test-plan.yaml`.
+
+---
+
+## Группа A — Bump по умолчанию (Требование 1)
+
+### AC-1 — дефолт tracker_mode = bump
+- **PASS:** `Settings().tracker_mode == "bump"` без выставленного env `ORCH_TRACKER_MODE`.
+- **FAIL:** дефолт остался `"edit"` или иное.
+
+### AC-2 — bump-поведение: одна карточка падает вниз
+- **PASS:** при втором (и последующем) вызове `update_task_tracker` для задачи с уже
+  сохранённым `tracker_message_id` вызывается `delete_telegram(old_id)` (best-effort),
+  затем `send_telegram(...)` с `disable_notification=True`, затем `set_tracker_message_id`
+  на новый id. В чате остаётся ровно одна карточка на задачу.
+- **FAIL:** карточка редактируется на месте при дефолте; либо появляются дубли; либо новая
+  карточка отправляется со звуком (`disable_notification` не True).
+
+### AC-3 — bump fail-safe: транзиентный фейл send не обнуляет указатель
+- **PASS:** если `send_telegram` вернул `None` (нет креды/транзиентный фейл),
+  `tracker_message_id` НЕ перезаписывается в `None` и дубликат в рамках вызова не создаётся.
+- **FAIL:** указатель обнулён или создан второй card-месседж в одном вызове.
+
+### AC-4 — режим edit остаётся доступен через env
+- **PASS:** при `ORCH_TRACKER_MODE=edit` поведение прежнее (editMessageText, fallback на
+  новый месседж только при EDIT_GONE).
+- **FAIL:** edit-режим сломан/недоступен.
+
+---
+
+## Группа B — Статус-строка карточки по модели ORCH-066 (Требование 2)
+
+### AC-5 — статус-строка присутствует в карточке
+- **PASS:** `render_task_tracker(task_id)` содержит явную строку текущего Plane-статуса
+  (напр. `📍 <status>`) в шапке/верхней части карточки.
+- **FAIL:** статус-строки нет.
+
+### AC-6 — корректный маппинг stage → Plane-статус
+- **PASS:** для всех stage-выводимых состояний строка статуса соответствует таблице ТЗ §2.2:
+  `created→To Analyse`, `analysis→Analysis`, `architecture→Architecture`,
+  `development→Development`, `review→Code-Review`, `testing→Testing`,
+  `deploy→Awaiting Deploy`, `done→Done`.
+- **FAIL:** хотя бы один stage маппится на неверное имя/внутренний ярлык.
+
+### AC-7 — In Review (ожидание согласования BRD) как полноценный статус
+- **PASS:** при `stage == "analysis"`, `brd_review_started_at` задан и
+  `brd_review_ended_at` пуст — статус-строка явно отражает `⏸️ In Review` с пометкой
+  «ожидание согласования BRD»; при этом существующая строка «Подтверждение BRD …» с ⏸️/⏳
+  сохранена. Работает без сетевых вызовов.
+- **FAIL:** In Review теряется/не показан как статус, либо строка «Подтверждение BRD» исчезла.
+
+### AC-8 — Awaiting Deploy и Needs Input отражены
+- **PASS:** состояние ожидания Confirm Deploy показывается как
+  `⏸️ Awaiting Deploy — ожидание Confirm Deploy`; состояние вопросов аналитика — как
+  `❓ Needs Input — нужны уточнения`.
+- **FAIL:** любое из этих состояний не отражено в статус-строке.
+
+### AC-9 — рендер карточки никогда не падает
+- **PASS:** при любой ошибке построения статуса (битые данные, недоступный источник)
+  `render_task_tracker` возвращает корректную карточку (деградация на stage-маппинг или
+  fallback-строку), исключение наружу не выходит.
+- **FAIL:** `render_task_tracker` бросает исключение.
+
+---
+
+## Группа C — Кликабельный номер в карточке (Требование 3)
+
+### AC-10 — номер задачи в карточке — гиперссылка
+- **PASS:** при наличии `plane_web_url` (не loopback), `plane_workspace_slug`, `project_id`
+  (резолв по repo) и `plane_issue_id` карточка содержит
+  `<a href="https://<base>/<ws>/projects/<pid>/issues/<issue_id>/">ORCH-NNN</a>`.
+- **FAIL:** номер выводится сырым текстом при наличии всех данных, либо URL собран неверно.
+
+### AC-11 — fail-safe ссылки в карточке
+- **PASS:** при отсутствии любого из (web_base/не-loopback, workspace, project_id,
+  plane_issue_id) карточка показывает номер БЕЗ ссылки (`html.escape(work_item_id)`) и не
+  падает.
+- **FAIL:** падение, пустая ссылка `<a href="">`, либо битый `<a>` тег.
+
+---
+
+## Группа D — Кликабельный номер во всех уведомлениях (Требование 4)
+
+### AC-12 — единый хелпер ссылки
+- **PASS:** существует `plane_issue_link(...)`, возвращающий HTML-ссылку при достаточных
+  данных и `html.escape(work_item_id)` при недостаточных; никогда не бросает.
+- **FAIL:** хелпера нет, либо он падает на неполных данных.
+
+### AC-13 — хелпер применён во всех уведомлениях с work_item_id
+- **PASS:** во всех точках `send_telegram`/`notify_*` из ТЗ §3.3, где упоминается
+  `work_item_id` (`notify_approve_requested`, `notify_error`, alert'ы stage_engine,
+  launcher, merge_gate, job_reaper, security_gate, reconciler, main), номер задачи
+  кликабелен (при наличии данных) и ведёт на ту же страницу Plane.
+- **FAIL:** хотя бы одна такая точка выводит номер сырым текстом при наличии данных.
+
+### AC-14 — HTML-экранирование пользовательского текста
+- **PASS:** title/причины/сообщения с потенциальным HTML (`<`, `>`, `&`) экранируются
+  `html.escape`; разметка `<a>` остаётся валидной; сообщение проходит `parse_mode=HTML`.
+- **FAIL:** неэкранированный текст ломает разметку (тест с title, содержащим `<b>`/`&`,
+  обнаруживает поломку).
+
+---
+
+## Группа E — Нерегресс и качество
+
+### AC-15 — инварианты транспорта/нотификаций сохранены
+- **PASS:** `send_telegram`/`edit_telegram`/`delete_telegram` не изменены по сигнатуре/
+  семантике; карточка тихая (`disable_notification=True`); инвариант «одна карточка на
+  задачу» соблюдён; `STAGE_TRANSITIONS`/QG/схема БД не тронуты.
+- **FAIL:** изменён транспорт, карточка пингует, появились дубли, тронута схема БД/QG.
+
+### AC-16 — нет регресса для enduro-trails
+- **PASS:** существующие тесты нотификаций (`test_notify_approve_links.py`,
+  `test_notify_done_regression.py` и др.) проходят; поведение карточки для не-ORCH проектов
+  без новых Plane-статусов деградирует корректно (alias-fallback, без ссылки при нехватке
+  данных).
+- **FAIL:** падение существующих тестов или сломанная карточка для enduro.
+
+### AC-17 — весь набор тестов зелёный
+- **PASS:** `pytest tests/ -q` зелёный.
+- **FAIL:** любой упавший тест.
+
+### AC-18 — документация обновлена в том же PR
+- **PASS:** обновлены `CLAUDE.md` (раздел нотификаций/tracker), `CHANGELOG.md`,
+  создан ADR per-work-item.
+- **FAIL:** функционал изменён, документация — нет (reviewer → REQUEST_CHANGES).
--- a/docs/work-items/ORCH-067/04-test-plan.yaml
+++ b/docs/work-items/ORCH-067/04-test-plan.yaml
@@ -0,0 +1,181 @@
+work_item: ORCH-067
+description: >
+  План тестов для ORCH-067 (Telegram tracker: bump по умолчанию, статус-строка
+  карточки по модели Plane ORCH-066, кликабельный номер задачи в карточке и во
+  всех уведомлениях орка). Сеть изолируется: send_telegram/edit_telegram/
+  delete_telegram подменяются рекордерами (как в tests/conftest.py и
+  tests/test_notify_approve_links.py); БД — временный SQLite, сидируемый фикстурой.
+
+tests:
+  # --- Группа A: bump по умолчанию (AC-1..AC-4) ---
+  - id: TC-01
+    type: unit
+    description: "Дефолт Settings().tracker_mode == 'bump' без env ORCH_TRACKER_MODE"
+    module: tests/test_tracker_bump_default.py
+    asserts: "AC-1"
+    expected: PASS
+
+  - id: TC-02
+    type: unit
+    description: >
+      bump-поведение: при повторном update_task_tracker с сохранённым
+      tracker_message_id вызывается delete_telegram(old) -> send_telegram(...,
+      disable_notification=True) -> set_tracker_message_id(new). Одна карточка.
+    module: tests/test_tracker_bump_default.py
+    asserts: "AC-2"
+    expected: PASS
+
+  - id: TC-03
+    type: unit
+    description: >
+      bump fail-safe: send_telegram вернул None (нет креды/транзиент) ->
+      tracker_message_id не обнуляется, дубликат в вызове не создаётся.
+    module: tests/test_tracker_bump_default.py
+    asserts: "AC-3"
+    expected: PASS
+
+  - id: TC-04
+    type: unit
+    description: "ORCH_TRACKER_MODE=edit -> прежнее edit-поведение (editMessageText)"
+    module: tests/test_tracker_bump_default.py
+    asserts: "AC-4"
+    expected: PASS
+
+  # --- Группа B: статус-строка карточки (AC-5..AC-9) ---
+  - id: TC-05
+    type: unit
+    description: "render_task_tracker содержит явную строку текущего Plane-статуса"
+    module: tests/test_tracker_status_line.py
+    asserts: "AC-5"
+    expected: PASS
+
+  - id: TC-06
+    type: unit
+    description: >
+      Маппинг stage -> Plane-статус по таблице ТЗ §2.2: created->To Analyse,
+      analysis->Analysis, architecture->Architecture, development->Development,
+      review->Code-Review, testing->Testing, deploy->Awaiting Deploy, done->Done
+      (параметризованный тест по всем stage).
+    module: tests/test_tracker_status_line.py
+    asserts: "AC-6"
+    expected: PASS
+
+  - id: TC-07
+    type: unit
+    description: >
+      analysis + brd_review_started_at задан + brd_review_ended_at пуст ->
+      статус '⏸️ In Review' (ожидание согласования BRD); строка 'Подтверждение
+      BRD' с ⏸️/⏳ сохранена; без сетевых вызовов.
+    module: tests/test_tracker_status_line.py
+    asserts: "AC-7"
+    expected: PASS
+
+  - id: TC-08
+    type: unit
+    description: >
+      Awaiting Deploy ('ожидание Confirm Deploy') и Needs Input ('нужны
+      уточнения') корректно отражаются в статус-строке.
+    module: tests/test_tracker_status_line.py
+    asserts: "AC-8"
+    expected: PASS
+
+  - id: TC-09
+    type: unit
+    description: >
+      render_task_tracker не падает при битых/недоступных данных статуса
+      (деградация на stage-маппинг/fallback, исключение не наружу).
+    module: tests/test_tracker_status_line.py
+    asserts: "AC-9, AC-16"
+    expected: PASS
+
+  # --- Группа C: кликабельный номер в карточке (AC-10..AC-11) ---
+  - id: TC-10
+    type: unit
+    description: >
+      При полных данных (plane_web_url не loopback, workspace, project_id по repo,
+      plane_issue_id) карточка содержит <a href=".../issues/<id>/">ORCH-NNN</a>
+      с корректным URL.
+    module: tests/test_tracker_issue_link.py
+    asserts: "AC-10"
+    expected: PASS
+
+  - id: TC-11
+    type: unit
+    description: >
+      Fail-safe ссылки в карточке: при отсутствии любого из (web_base/не-loopback,
+      workspace, project_id, plane_issue_id) номер выводится html.escape без <a>,
+      рендер не падает. Параметризовать по каждому отсутствующему полю.
+    module: tests/test_tracker_issue_link.py
+    asserts: "AC-11"
+    expected: PASS
+
+  # --- Группа D: единый хелпер и уведомления (AC-12..AC-14) ---
+  - id: TC-12
+    type: unit
+    description: >
+      plane_issue_link(...) возвращает HTML-ссылку при достаточных данных и
+      html.escape(work_item_id) при недостаточных; никогда не бросает (в т.ч. на
+      None-аргументах и loopback-базе).
+    module: tests/test_plane_issue_link.py
+    asserts: "AC-12"
+    expected: PASS
+
+  - id: TC-13
+    type: unit
+    description: >
+      notify_approve_requested: номер задачи кликабелен (ведёт на страницу Plane),
+      сохранён call-to-action 'Approved', ровно одно notifying-сообщение.
+    module: tests/test_notify_issue_links.py
+    asserts: "AC-13"
+    expected: PASS
+
+  - id: TC-14
+    type: unit
+    description: >
+      notify_error: номер задачи кликабелен при наличии данных, деградирует на
+      сырой номер без падения при их отсутствии.
+    module: tests/test_notify_issue_links.py
+    asserts: "AC-13, AC-12"
+    expected: PASS
+
+  - id: TC-15
+    type: integration
+    description: >
+      Точки send_telegram в stage_engine/launcher/merge_gate/job_reaper/
+      security_gate/reconciler/main, где есть work_item_id, используют
+      plane_issue_link (или эквивалент) — номер кликабелен. Проверка рекордером
+      send_telegram на представительных alert-путях (deploy fail, agent fail,
+      QG fail, прод-деплой).
+    module: tests/test_notify_issue_links.py
+    asserts: "AC-13"
+    expected: PASS
+
+  - id: TC-16
+    type: unit
+    description: >
+      HTML-экранирование: title с '<b>'/'&'/'>' экранируется, <a>-разметка
+      остаётся валидной, сообщение не ломается под parse_mode=HTML (карточка и
+      уведомления).
+    module: tests/test_tracker_issue_link.py
+    asserts: "AC-14"
+    expected: PASS
+
+  # --- Группа E: нерегресс (AC-15..AC-18) ---
+  - id: TC-17
+    type: integration
+    description: >
+      Инварианты: карточка отправляется с disable_notification=True; одна карточка
+      на задачу; транспорт send/edit/delete не изменён по семантике.
+    module: tests/test_tracker_bump_default.py
+    asserts: "AC-15"
+    expected: PASS
+
+  - id: TC-18
+    type: integration
+    description: >
+      Нерегресс существующих тестов нотификаций (test_notify_approve_links.py,
+      test_notify_done_regression.py) и корректная деградация карточки для
+      enduro-trails без новых Plane-статусов.
+    module: tests/test_notify_done_regression.py
+    asserts: "AC-16, AC-17"
+    expected: PASS
--- a/docs/work-items/ORCH-067/06-adr/ADR-001-tracker-plane-status-and-link.md
+++ b/docs/work-items/ORCH-067/06-adr/ADR-001-tracker-plane-status-and-link.md
@@ -0,0 +1,224 @@
+# ADR-001: Источник Plane-статуса для live-карточки и кликабельный номер задачи
+
+- **Статус:** Proposed
+- **Дата:** 2026-06-08
+- **Задача:** ORCH-067
+- **Слой:** B (индикация), НЕ слой A (машина стадий) — см. CLAUDE.md / ORCH-066
+- **Связи:** ORCH-066 (статусная модель Plane, `_PLANE_NAME_TO_KEY` / `_STAGE_TO_STATE_KEY`),
+  ORCH-042 (live-tracker, режимы `edit`/`bump`), ORCH-017 (`_build_plane_issue_link`,
+  `plane_web_url`/`plane_workspace_slug`, loopback-guard), ORCH-059 (Confirm Deploy),
+  ORCH-060 (`fetch_issue_state`), ORCH-010 (`get_project_states` per-project + кэш),
+  adr-0001 (реестр проектов), adr-0010 (post-deploy monitor).
+
+## Контекст
+
+ТЗ ORCH-067 (`02-trz.md`) фиксирует объём изменений; данный ADR закрывает развилки,
+явно отданные архитектору метками `[ARCH]`:
+
+1. **Источник «истинного» Plane-статуса для веток, не выводимых из `tasks.stage`**
+   (Needs Input, Blocked, Rejected, Cancelled, Deploying, Monitoring after Deploy),
+   при **запрете менять схему БД** (нельзя добавить колонку-флаг). TZ §2.2 предлагает
+   два варианта: (а) best-effort чтение живого Plane-статуса с fail-safe;
+   (б) только stage-выводимые статусы.
+2. **Способ доступа к `plane_issue_id`/`project_id`** в каждой точке `send_telegram`,
+   где есть только `work_item_id` (требование 4), оставаясь fail-safe.
+3. Смена дефолта `tracker_mode` (`edit` → `bump`) для общего инстанса.
+
+### Ключевая находка анализа (определяет развилку 1)
+
+Когда аналитик задаёт вопросы, `stage_engine.start_pipeline` при наличии
+`01-questions.md` вызывает `set_issue_needs_input(work_item_id)` (Plane → Needs Input),
+но **DB-стадия остаётся `analysis`**, а BRD-часы (`brd_review_started_at`) **не
+запускаются** (они стартуют позже, в `notify_approve_requested`, когда BRD готов).
+Следовательно состояния **`Analysis` (аналитик работает)** и **`❓ Needs Input`
+(аналитик ждёт ответа)** **неразличимы** по offline-данным БД (`stage` + brd-clock).
+Единственный авторитетный источник этого различия — **живой Plane-статус**, который
+оркестратор сам выставил через `set_issue_needs_input`.
+
+То же касается `Deploying` / `Monitoring after Deploy`: на стадии `deploy`/`done`
+конкретная фаза self-deploy видна только в Plane (ORCH-059/ORCH-066), не в `tasks.stage`.
+
+Вывод: чисто-offline вариант (б) **не покрывает обязательный по DoD `❓ Needs Input`**
+(AC-8). Нужен гибрид.
+
+## Решение
+
+### Р-1. Гибрид: offline-first ядро + best-effort live-overlay
+
+Статус карточки строится в два слоя; **offline-ядро авторитетно и всегда работает без
+сети**, live-overlay лишь дорисовывает ветки, неотличимые offline.
+
+**Слой 1 — чистая offline-функция `plane_status_label(task_row) -> str`** в
+`src/notifications.py`. Детерминированная, **никогда не бросает**, **никогда не ходит в
+сеть**. Маппинг (имена статусов — финальные из ORCH-066 `_PLANE_NAME_TO_KEY`):
+
+| Источник (DB) | Метка карточки |
+|---|---|
+| `stage == "created"` | `To Analyse` |
+| `stage == "analysis"`, brd-clock не запущен | `Analysis` |
+| `stage == "analysis"`, `brd_review_started_at` есть, `brd_review_ended_at` пуст | `⏸️ In Review — ожидание согласования BRD` |
+| `stage == "architecture"` | `Architecture` |
+| `stage == "development"` | `Development` |
+| `stage == "review"` | `Code-Review` |
+| `stage == "testing"` | `Testing` |
+| `stage == "deploy"` | `⏸️ Awaiting Deploy — ожидание Confirm Deploy` |
+| `stage == "done"` | `Done` |
+| неизвестный/битый `stage` | дефолт: `html`-безопасная строка по `stage` (или `To Analyse`) |
+
+Этого слоя достаточно для **`⏸️ In Review`** и **`⏸️ Awaiting Deploy`** — оба
+обязательны по DoD и **работают без сети** (AC-7, AC-8). `In Review` выводится
+исключительно из brd-clock.
+
+**Слой 2 — best-effort live-overlay** `_live_plane_branch_override(repo, plane_issue_id,
+base_label) -> str` для веток, неразличимых offline: **Needs Input, Blocked, Rejected,
+Cancelled, Deploying, Monitoring after Deploy**. Алгоритм:
+
+1. Резолв `project_id` по `repo` (`get_project_by_repo(repo).plane_project_id`).
+2. `live_uuid = fetch_issue_state(plane_issue_id, project_id)` (ORCH-060) — **с коротким
+   таймаутом** (см. Р-4), не дефолтным 10s.
+3. Сопоставление `live_uuid` с **конкретными** UUID веток из
+   `get_project_states(project_id)` (кэш ORCH-010): `needs_input`, `blocked`,
+   `cancelled`, `rejected`, `deploying`, `monitoring`.
+4. Override применяется **только** если `live_uuid` совпал с одним из этих ключей.
+   Иначе возвращается `base_label` (offline-метка).
+
+**Прецеденс (порядок приоритета):**
+1. Если offline-ядро дало **`⏸️ In Review`** (brd-clock) — overlay **не вызывается**:
+   brd-clock авторитетнее возможно-устаревшего Plane-чтения для In Review.
+2. Иначе `base_label` = offline-метка, затем применяется overlay (если включён и удался).
+
+**Анти-false-positive на enduro (важно):** на enduro-trails ключи `deploying`/
+`monitoring` алиасят UUID `in_progress`/`done` (`_STATE_ALIAS_FALLBACK`), поэтому прямое
+сравнение UUID дало бы ложный `Deploying` для любой `in_progress`-задачи. Поэтому для
+`deploying`/`monitoring` override применяется **только если** их UUID в
+`get_project_states` **отличается** от UUID базового ключа (т.е. проект реально завёл
+отдельный статус — это ORCH, не enduro). Ключи `needs_input/blocked/cancelled/rejected`
+имеют отдельные UUID и на enduro, и на ORCH (`_DEFAULT_STATES`), поэтому различимы всегда.
+
+### Р-2. Fail-safe и невлияние на конвейер (overlay)
+
+- `_live_plane_branch_override` обёрнут в `try/except` и **никогда не бросает**; любая
+  ошибка/таймаут/нет сети/нет данных → возвращается `base_label`. Это удовлетворяет
+  «без сети не падать» и AC-9 (рендер карточки никогда не падает).
+- Нет `plane_issue_id` / нет `project_id` / нет креды → overlay не вызывается, метка =
+  offline-ядро.
+- **Kill-switch:** новый флаг конфигурации `tracker_live_status: bool = True`
+  (env `ORCH_TRACKER_LIVE_STATUS`). При `False` overlay полностью отключён (никаких
+  сетевых чтений в рендере) — карточка деградирует на offline-ядро. Это аварийный
+  тумблер и страховка от регресса для не-ORCH проектов. **Дефолт `True`**, иначе
+  обязательный по DoD `Needs Input` не отобразится из коробки.
+
+### Р-3. Кэш live-статуса (защита hot-path)
+
+`render_task_tracker` вызывается на КАЖДОМ обновлении трекера (старт/финиш агента,
+переход стадии), а в режиме `bump` — с delete+send каждый раз. Чтобы серия быстрых
+перерисовок не била по Plane:
+
+- Добавить **TTL-кэш per-issue** для `live_uuid` (ключ — `plane_issue_id`, TTL
+  `tracker_live_status_ttl_s: int = 60`). По образцу `_STATES_CACHE` в `plane_sync.py`.
+- На промахе кэша — один `fetch_issue_state` с коротким таймаутом; результат кладётся в
+  кэш. На любой ошибке кэш не портится, возвращается offline-метка.
+
+Это ограничивает сетевую нагрузку overlay ~одним GET в `TTL` на задачу.
+
+### Р-4. Короткий таймаут live-чтения в рендере
+
+`fetch_issue_state` (ORCH-060) хардкодит `timeout=10`. Для пути рендера это слишком
+долго (рендер синхронный, в линии переходов общего конвейера). Решение: добавить в
+`fetch_issue_state` **необязательный параметр `timeout`** (дефолт прежний `10` —
+обратная совместимость для reconciler), а overlay вызывает его с
+`settings.tracker_live_status_timeout_s` (дефолт **3** с). Поведение/сигнатуры
+существующих вызовов не меняются.
+
+### Р-5. Единый хелпер кликабельного номера `plane_issue_link`
+
+Добавить в `src/notifications.py`:
+
+```python
+def plane_issue_link(work_item_id, plane_issue_id=None, project_id=None, repo=None) -> str:
+    """HTML с кликабельным номером (<a href=...>ORCH-NNN</a>) или html.escape(work_item_id).
+    Никогда не падает."""
+```
+
+- Переиспользовать логику и guard'ы `_build_plane_issue_link` (ORCH-017), **разнеся**
+  «текст ссылки = номер задачи» и «текст ссылки = `✅ Задача в Plane`», чтобы не
+  дублировать резолв проекта и loopback-guard. Рекомендуется выделить приватный
+  `_plane_issue_url(repo, plane_issue_id, project_id) -> str | None` (сборка URL +
+  loopback/workspace/project guard), который зовут оба: `plane_issue_link` (текст =
+  номер) и `_build_plane_issue_link` (текст = «✅ Задача в Plane»).
+- База URL: `plane_web_url` → fallback `plane_api_url`; loopback → «нет web URL»
+  (`_is_loopback_base`).
+- `project_id`: явный аргумент → иначе резолв по `repo`.
+- URL: `{web_base}/{workspace}/projects/{project_id}/issues/{plane_issue_id}/`.
+- Текст = `html.escape(work_item_id)`; `href` = `html.escape(url, quote=True)`.
+- **Fail-safe:** не хватает любого из (web_base/не-loopback, workspace, project_id,
+  plane_issue_id) → вернуть `html.escape(work_item_id)` (номер без ссылки). Никогда не
+  бросает (AC-11, AC-12).
+
+### Р-6. Доступ к `plane_issue_id`/`project_id` в точках уведомлений (требование 4)
+
+В большинстве точек `send_telegram` доступен только `work_item_id`. Решение —
+тонкая fail-safe обёртка по образцу `_get_task_link_fields`:
+
+```python
+def link_for(work_item_id, task_id=None) -> str:
+    """По work_item_id (или task_id) достать repo+plane_issue_id из БД и вернуть
+    plane_issue_link(...). На любой нехватке данных -> html.escape(work_item_id)."""
+```
+
+- Если у точки есть `task_id` — читать `(repo, plane_issue_id)` напрямую из `tasks` по
+  `id`. Если только `work_item_id` — `SELECT repo, plane_issue_id FROM tasks WHERE
+  work_item_id=? ORDER BY id DESC LIMIT 1` (как в `_resolve_project_id`).
+- Везде, где данных нет — деградация на `html.escape(work_item_id)`, без падения.
+- Применить во всех точках из TZ §3.3 (`notify_approve_requested`, `notify_error`,
+  `stage_engine`, `launcher`, `merge_gate`, `job_reaper`, `security_gate`, `reconciler`,
+  `main`) — **только там, где упоминается номер задачи**.
+
+### Р-7. `tracker_mode` дефолт → `bump`
+
+`src/config.py`: `tracker_mode: str = "edit"` → `"bump"`. Инвариант «одна карточка на
+задачу» сохранён в обоих режимах (код `update_task_tracker` не меняется по сути).
+`edit` остаётся доступен через `ORCH_TRACKER_MODE=edit`. Транзиентный фейл `send` не
+обнуляет `tracker_message_id` (инвариант уже в коде — сохранить).
+
+### Р-8. Чего НЕ делаем (границы)
+
+- НЕ менять схему БД, `STAGE_TRANSITIONS`, Quality Gates, транспорт
+  `send_telegram`/`edit_telegram`/`delete_telegram`, `disable_notification`-семантику.
+- НЕ менять поведение агентов/конвейера. Слой B (индикация) не управляет слоем A.
+- НЕ добавлять блокирующих сетевых ожиданий в линию переходов сверх одного короткого
+  best-effort GET с кэшем (Р-3/Р-4).
+- НЕ создавать глобальный (сквозной) ADR: изменение локально для `notifications.py` +
+  один config-дефолт, не вводит новую стадию/QG/компонент. Достаточно per-work-item ADR.
+
+## Последствия
+
+**Плюсы**
+- Обязательные по DoD `⏸️ In Review`, `⏸️ Awaiting Deploy` работают **без сети**
+  (детерминированно, тестируемо offline — AC-6/AC-7).
+- `❓ Needs Input` (и Blocked/Rejected/Cancelled/Deploying/Monitoring) отражаются через
+  авторитетный источник — живой Plane-статус, который иначе невосстановим из БД.
+- Единый хелпер ссылки убирает дублирование резолва проекта/loopback-guard (ORCH-017).
+- Kill-switch + кэш + короткий таймаут ограничивают риск для общего инстанса.
+
+**Минусы / ограничения**
+- Overlay добавляет ≤1 короткий GET (3 с таймаут) на задачу в `TTL=60s` в путь рендера.
+  Митигировано кэшем, таймаутом и kill-switch.
+- При недоступном Plane ветки `Needs Input`/`Blocked`/… деградируют на offline-метку
+  (`Analysis`/stage). Это осознанный, безопасный компромисс (рендер важнее точности
+  ветки; конвейер не блокируется).
+- На частично сконфигурированном проекте без отдельных статусов `Deploying`/`Monitoring`
+  эти ветки не показываются (alias-guard) — корректная деградация, не баг.
+
+**Риски** — см. `10-tech-risks.md`.
+
+## Альтернативы (отклонены)
+
+- **Только offline (вариант б TZ).** Отклонён: не отличает `Needs Input` от `Analysis`
+  → не покрывает обязательный AC-8.
+- **Чтение `01-questions.md` из worktree как offline-сигнал Needs Input.** Отклонён:
+  хрупко (резолв пути worktree из `notifications.py`, файл может пережить ответ,
+  гонки) — менее надёжно, чем авторитетный Plane-статус.
+- **Добавить DB-колонку-флаг для ветки.** Запрещено TZ (без изменения схемы).
+- **Асинхронный фон/демон для подтяжки статуса.** Избыточно для слоя индикации; кэш +
+  короткий таймаут дешевле и проще, без нового компонента.
--- a/docs/work-items/ORCH-067/07-infra-requirements.md
+++ b/docs/work-items/ORCH-067/07-infra-requirements.md
@@ -0,0 +1,46 @@
+# Инфраструктурные требования — ORCH-067
+
+Топология не меняется (никаких новых контейнеров/портов/сервисов). Изменения —
+**только конфигурация/env** и обязательный staging-гейт (self-hosting).
+
+## 1. Изменения конфигурации (`src/config.py`)
+
+| Поле | env | Старое | Новое | Назначение |
+|---|---|---|---|---|
+| `tracker_mode` | `ORCH_TRACKER_MODE` | `"edit"` | `"bump"` (дефолт) | Карточка падает вниз ленты при обновлении (ADR-001 Р-7). `edit` доступен через env. |
+| `tracker_live_status` | `ORCH_TRACKER_LIVE_STATUS` | — (нет) | `True` (дефолт) | Kill-switch live-overlay Plane-статуса (ADR-001 Р-2). `0/false` → только offline-метки, без сетевых чтений в рендере. |
+| `tracker_live_status_ttl_s` | `ORCH_TRACKER_LIVE_STATUS_TTL_S` | — | `60` | TTL per-issue кэша live-статуса (ADR-001 Р-3). |
+| `tracker_live_status_timeout_s` | `ORCH_TRACKER_LIVE_STATUS_TIMEOUT_S` | — | `3` | Короткий таймаут live-чтения в рендере (ADR-001 Р-4). |
+
+Уже существующие (не менять, использовать): `plane_web_url`
+(`ORCH_PLANE_WEB_URL`, прод — `https://plane.mva154.duckdns.org`),
+`plane_workspace_slug` (прод — `ag_proj`), `plane_api_url`.
+
+## 2. `.env` / `.env.example`
+
+- Обновить `.env.example`: добавить `ORCH_TRACKER_MODE`, `ORCH_PLANE_WEB_URL`,
+  `ORCH_TRACKER_LIVE_STATUS*` с дефолтами и комментариями (канон настроек —
+  `.env.example`, реальные секреты не коммитить).
+- На прод-хосте допустимо явно выставить `ORCH_TRACKER_MODE=bump` как страховку, но код
+  обязан работать «из коробки» и без env.
+- `ORCH_PLANE_WEB_URL` должен быть задан на проде (иначе номер задачи деградирует на
+  текст без ссылки — fail-safe, не падение).
+
+## 3. Self-hosting (обязательно)
+
+- **НЕ перезапускать / не ронять** прод-контейнер `orchestrator` (8500) в рамках задачи —
+  общий инстанс/БД с enduro-trails.
+- Обязательная страховка через `deploy-staging` (8501, изолированная БД) **до** прод-деплоя.
+  На staging проверить:
+  - режим `bump`: одна карточка на задачу, падает вниз, тихо (без звука), без дублей;
+  - статус-строка: `⏸️ In Review`, `⏸️ Awaiting Deploy`, `❓ Needs Input` отображаются;
+  - кликабельный номер ведёт на страницу Plane;
+  - **нет регресса для enduro-trails** (карточка без новых статусов деградирует корректно).
+- Прод-деплой орка — только переводом задачи на стадии `deploy` в статус
+  **«Confirm Deploy»** (ORCH-059), не `Approved`.
+
+## 4. Сетевые требования
+
+- Live-overlay требует доступности Plane API (`plane_api_url`) из контейнера — он уже
+  есть (используется plane_sync). Недоступность Plane → graceful degrade на offline-метку,
+  конвейер не блокируется (короткий таймаут + kill-switch).
--- a/docs/work-items/ORCH-067/08-data-requirements.md
+++ b/docs/work-items/ORCH-067/08-data-requirements.md
@@ -0,0 +1,35 @@
+# Требования к данным — ORCH-067
+
+## Изменения схемы БД: НЕТ
+
+`STAGE_TRANSITIONS`, таблицы и колонки `tasks`/`agent_runs` **не меняются**. Это жёсткое
+ограничение TZ §6 и предпосылка ADR-001 (запрет колонки-флага для веток статуса).
+
+## Читаемые колонки `tasks` (существующие)
+
+| Колонка | Использование в ORCH-067 |
+|---|---|
+| `id` | Ключ задачи. |
+| `work_item_id` | Текст номера (`ORCH-NNN`) + ключ резолва в `link_for`. |
+| `title` | Заголовок карточки (`html.escape`). |
+| `stage` | Offline-маппинг Plane-статуса (ADR-001 Р-1, слой 1). |
+| `brd_review_started_at`, `brd_review_ended_at` | Различение `Analysis` ↔ `⏸️ In Review` (offline, без сети). |
+| `repo` | Резолв `project_id` (`get_project_by_repo`) для ссылки и live-overlay. |
+| `plane_issue_id` (UUID) | `issue_id` в URL Plane + аргумент `fetch_issue_state` (live-overlay). |
+| `created_at`, `updated_at` | Тоталы времени в done-строке (без изменений). |
+
+`render_task_tracker` **расширяет существующий `SELECT`** по `tasks`, добавляя `repo` и
+`plane_issue_id` к уже выбираемым полям. Схему это не трогает — колонки уже есть.
+
+## Кэш в памяти (не БД)
+
+Per-issue TTL-кэш live-статуса (ключ `plane_issue_id`, TTL
+`tracker_live_status_ttl_s=60`, ADR-001 Р-3) — **in-memory**, по образцу `_STATES_CACHE`
+в `plane_sync.py`. Не персистится, переживание рестарта не требуется (best-effort
+индикация). Очистка при рестарте — допустима.
+
+## Источник имён статусов
+
+Имена и логические ключи статусов берутся из существующих структур `src/plane_sync.py`
+(`_PLANE_NAME_TO_KEY`, `get_project_states`, `_DEFAULT_STATES`), вводимых ORCH-066.
+Новых статусов/ключей ORCH-067 **не добавляет**.
--- a/docs/work-items/ORCH-067/10-tech-risks.md
+++ b/docs/work-items/ORCH-067/10-tech-risks.md
@@ -0,0 +1,21 @@
+# Технические риски — ORCH-067
+
+| # | Риск | Вероятность / Влияние | Митигация (ADR-001) | Остаточный риск |
+|---|---|---|---|---|
+| R-1 | **Регресс enduro-trails** при смене дефолта `tracker_mode` → `bump` (другое поведение карточки для всех проектов). | Сред / Сред | Инвариант «одна карточка на задачу» сохранён; `edit` доступен через env; проверка на staging + тесты нерегресса (AC-16). | Низкий |
+| R-2 | **Поломка HTML-разметки** неэкранированным `title`/причиной → сообщение с `parse_mode=HTML` не доставится. | Сред / Сред | Обязательный `html.escape` для всего пользовательского текста; `href` через `html.escape(url, quote=True)`; тест с `<b>`/`&` (AC-14). | Низкий |
+| R-3 | **Latency в hot-path конвейера**: live-overlay добавляет сетевой GET в синхронный рендер, вызываемый на каждом переходе/в bump. | Сред / Сред | Короткий таймаут 3 с (Р-4) + per-issue TTL-кэш 60 с (Р-3) + kill-switch `ORCH_TRACKER_LIVE_STATUS=0` (Р-2). ≤1 GET на задачу за TTL. | Низкий |
+| R-4 | **Рендер карточки падает** на битых данных/недоступном Plane. | Низк / Выс | `plane_status_label` чистая и never-raise; overlay в `try/except` → degrade на offline-метку; `render_task_tracker` уже never-raise (AC-9). | Очень низкий |
+| R-5 | **Ложный `Deploying`/`Monitoring` на enduro** (их UUID алиасит `in_progress`/`done`). | Сред / Низк | Override этих веток только если UUID статуса ≠ UUID базового ключа в `get_project_states` (Р-1, anti-false-positive). | Очень низкий |
+| R-6 | **Устаревший Plane-статус из кэша** показывает неактуальную ветку (например, `Needs Input` после ответа). | Сред / Низк | TTL 60 с самозаживает; offline-ядро авторитетно для In Review (brd-clock не оверрайдится). Индикация, не управление — расхождение косметическое. | Низкий |
+| R-7 | **Транзиентный фейл `send` плодит дубли / обнуляет указатель** в bump. | Низк / Сред | Инвариант уже в коде (`set_tracker_message_id` только при `new_mid is not None`); не менять; тест AC-3. | Низкий |
+| R-8 | **Self-hosting**: деплой орка ломает общий инстанс (enduro + ORCH, общая БД/очередь). | Низк / Выс | Обязательный staging-гейт (8501) до прода; прод-контейнер не ронять в задаче; прод-деплой только через «Confirm Deploy». | Низкий |
+| R-9 | **Пропущенная точка** уведомления с сырым номером (требование 4 — много call-sites). | Сред / Низк | Единый `link_for`/`plane_issue_link`; чек-лист точек из TZ §3.3; reviewer проверяет покрытие (AC-13). | Низкий |
+| R-10 | **Рассинхрон имён статусов** с ORCH-066, если та не в проде на момент разработки. | Низк / Низк | Имена берутся из `_PLANE_NAME_TO_KEY` (golden source); делать после прода ORCH-066 (BRD §6). | Низкий |
+
+## Сводно
+
+Все остаточные риски — низкие/очень низкие после митигаций. Главные защитные контуры:
+(1) offline-ядро статуса не требует сети и детерминировано; (2) live-overlay полностью
+best-effort с таймаутом+кэшем+kill-switch; (3) обязательный staging-гейт перед прод-деплоем
+общего инстанса (self-hosting).
--- a/docs/work-items/ORCH-067/12-review.md
+++ b/docs/work-items/ORCH-067/12-review.md
@@ -0,0 +1,78 @@
+---
+type: review
+work_item_id: ORCH-067
+verdict: APPROVED
+version: 2
+---
+
+# Review ORCH-067
+
+## Summary
+
+Повторное ревью после фикса документации (коммит `7a88f39`). Реализация полностью
+соответствует ТЗ (`02-trz.md`), ADR-001 и всем acceptance criteria (`03-acceptance-criteria.md`).
+
+**Код** (`src/notifications.py` — ядро):
+- **Req 1 (bump):** дефолт `tracker_mode` сменён `edit → bump` (`src/config.py`); логика
+  `update_task_tracker`, транспорт `send/edit/delete_telegram`, `disable_notification` и
+  инвариант «одна карточка на задачу» не тронуты (AC-1..AC-4, AC-15 ✓).
+- **Req 2 (статус-строка):** чистый never-raise `plane_status_label(task_row)` (offline-ядро:
+  stage→статус + `⏸️ In Review` из brd-clock + `⏸️ Awaiting Deploy`, всё без сети) +
+  best-effort `_live_plane_branch_override` для ветвей, неотличимых offline (Needs Input /
+  Blocked / Rejected / Cancelled / Deploying / Monitoring). Kill-switch
+  (`tracker_live_status`), per-issue TTL-кэш (`_LIVE_STATE_CACHE`), короткий таймаут
+  (`fetch_issue_state(..., timeout=)`, дефолт 10 сохранён → нет регресса reconciler).
+  Anti-false-positive guard для enduro (`_LIVE_BRANCH_BASE`: deploying/monitoring override
+  только при отдельном UUID). Прецеденс In Review > overlay соблюдён. `_card_status_label`
+  обёрнут в try/except → рендер никогда не падает (AC-5..AC-9 ✓).
+- **Req 3+4 (кликабельный номер):** единый `_plane_issue_url` устраняет дублирование
+  резолва проекта/loopback-guard (ORCH-017); `plane_issue_link` (текст=номер) и
+  `_build_plane_issue_link` (текст=«✅ Задача в Plane») оба зовут его. `link_for` fail-safe
+  достаёт `repo`/`plane_issue_id` из БД. Применено в заголовке карточки и во ВСЕХ точках
+  §3.3 с номером задачи (AC-10..AC-14 ✓).
+
+**Точки §3.3 проверены пофайлово:** `notify_approve_requested`, `notify_error`,
+`stage_engine.py` (все alert'ы с номером), `agents/launcher.py`, `security_gate.py`,
+`reconciler.py` — номер кликабелен. `merge_gate.py`/`job_reaper.py`/`main.py` оставлены без
+ссылки **осознанно и корректно**: их тексты ссылаются на repo/job/run_id, а НЕ на
+`work_item_id` (проверено: merge_gate:432 — lease/repo, job_reaper:396 — job/agent/repo,
+main:47 — orphaned run_ids).
+
+**Инварианты/нерегресс:** схема БД, `STAGE_TRANSITIONS`, QG, транспорт — не тронуты
+(AC-15 ✓). `get_db()` возвращает новое соединение на вызов, поэтому `conn.close()` в
+`link_for` корректен. `pytest tests/ -q` → **907 passed** (AC-16, AC-17 ✓).
+
+**Документация (блокеры v1 закрыты):** `CHANGELOG.md`, `CLAUDE.md`, `.env.example`
+обновлены в коммите `7a88f39`; ADR-001 присутствует и полон; `README.md`/`internals.md`
+синхронизированы (AC-18 ✓).
+
+## Findings
+
+### P0 — Blocker
+- (нет)
+
+### P1 — Must fix
+- (нет)
+
+### P2 — Should fix
+- (нет)
+
+### P3 — Nice to have (не блокирует)
+- [ ] Часть alert-сообщений в `stage_engine.py` (`_handle_self_deploy_phase_b`,
+      `_handle_merge_verify`) встраивает «сырой» `{msg}`/`{e}`/`{reason}` рядом с новой
+      `<a>`-ссылкой; под `parse_mode=HTML` редкий `<` в этих подстановках теоретически мог
+      бы помешать рендеру. Это **пре-существующее поведение** (parse_mode=HTML стоял и
+      раньше), не регресс данной задачи; `notify_error` свой `error` экранирует. Можно при
+      случае обернуть прочие подстановки в `html.escape`.
+
+## Документация
+
+- `docs/architecture/README.md` — обновлён (компонент Notifications / live-tracker). ✓
+- `docs/architecture/internals.md` — обновлён (§7: bump/edit, Plane-статус, кликабельный номер). ✓
+- `06-adr/ADR-001-tracker-plane-status-and-link.md` — присутствует, полный, закрывает все `[ARCH]`. ✓
+- `CHANGELOG.md` — обновлён (запись ORCH-067). ✓
+- `CLAUDE.md` — обновлён (раздел «Нотификации / Telegram live-tracker»). ✓
+- `.env.example` — синхронизирован (`ORCH_TRACKER_MODE=bump` + новые флаги live-overlay). ✓
+
+Документация = golden source: код и доку обновлены в одном PR. Блокеры предыдущего ревью
+(v1) закрыты. Замечаний уровня P0/P1/P2 нет → **APPROVED**.
--- a/docs/work-items/ORCH-067/13-test-report.md
+++ b/docs/work-items/ORCH-067/13-test-report.md
@@ -0,0 +1,78 @@
+---
+type: test-report
+work_item_id: ORCH-067
+result: PASS
+---
+
+# Test Report — ORCH-067
+
+Telegram tracker: bump по умолчанию, статус-строка карточки по модели Plane (ORCH-066),
+кликабельный номер задачи в карточке и во всех уведомлениях орка.
+
+## Окружение
+- Python: 3.12.13
+- pytest: 8.3.3
+- Ветка: `feature/ORCH-067-telegram-tracker-bump-plane` (worktree)
+- Дата: 2026-06-08
+- Review-вердикт: APPROVED (`12-review.md`, version 2)
+
+## Smoke test API (prod, :8500)
+| Endpoint | Результат |
+|----------|-----------|
+| `GET /health` | PASS — `{"status":"ok","service":"orchestrator"}` |
+| `GET /status` | PASS — отдаёт active_tasks (ORCH-067 на stage=testing) |
+| `GET /queue` | PASS — breaker closed, preflight_ok, counts корректны |
+
+Прод-контейнер не перезапускался (self-hosting инвариант соблюдён).
+
+## Результаты по тест-плану (04-test-plan.yaml)
+
+| TC ID | Описание | Модуль | AC | Результат |
+|-------|----------|--------|----|-----------|
+| TC-01 | Дефолт `tracker_mode == "bump"` без env | test_tracker_bump_default.py | AC-1 | PASS |
+| TC-02 | bump: delete(old)→send(silent)→repoint, одна карточка | test_tracker_bump_default.py | AC-2 | PASS |
+| TC-03 | bump fail-safe: send=None не обнуляет указатель | test_tracker_bump_default.py | AC-3 | PASS |
+| TC-04 | `ORCH_TRACKER_MODE=edit` — прежнее поведение | test_tracker_bump_default.py | AC-4 | PASS |
+| TC-05 | Карточка содержит строку Plane-статуса | test_tracker_status_line.py | AC-5 | PASS |
+| TC-06 | Маппинг stage → Plane-статус (§2.2, параметризованный) | test_tracker_status_line.py | AC-6 | PASS |
+| TC-07 | In Review из brd-clock, без сети; строка «Подтверждение BRD» сохранена | test_tracker_status_line.py | AC-7 | PASS |
+| TC-08 | Awaiting Deploy + Needs Input отражены | test_tracker_status_line.py | AC-8 | PASS |
+| TC-09 | render_task_tracker не падает на битых данных | test_tracker_status_line.py | AC-9, AC-16 | PASS |
+| TC-10 | Кликабельный номер в карточке при полных данных | test_tracker_issue_link.py | AC-10 | PASS |
+| TC-11 | Fail-safe ссылки в карточке (параметризованный) | test_tracker_issue_link.py | AC-11 | PASS |
+| TC-12 | `plane_issue_link(...)` — ссылка/escape, никогда не бросает | test_plane_issue_link.py | AC-12 | PASS |
+| TC-13 | notify_approve_requested: номер кликабелен, одна нотификация | test_notify_issue_links.py | AC-13 | PASS |
+| TC-14 | notify_error: кликабелен/деградирует без падения | test_notify_issue_links.py | AC-13, AC-12 | PASS |
+| TC-15 | Точки send_telegram (stage_engine/launcher/merge_gate/job_reaper/security_gate/reconciler/main) используют хелпер | test_notify_issue_links.py | AC-13 | PASS |
+| TC-16 | HTML-экранирование title/`&`, валидность `<a>` | test_tracker_issue_link.py | AC-14 | PASS |
+| TC-17 | Инварианты транспорта: disable_notification, одна карточка | test_tracker_bump_default.py | AC-15 | PASS |
+| TC-18 | Нерегресс нотификаций + деградация для enduro-trails | test_notify_done_regression.py | AC-16, AC-17 | PASS |
+
+Все 18 TC из тест-плана — PASS. Целевые модули: **57 passed**.
+
+## Покрытие acceptance criteria
+AC-1..AC-18 — все покрыты соответствующими TC и зелёные. AC-17 (полный набор) подтверждён
+прогоном всего пакета.
+
+## Вывод pytest (полный регресс)
+
+```
+$ python -m pytest tests/ -v --tb=short
+...
+======================= 907 passed, 1 warning in 22.36s ========================
+```
+
+Единственный warning — пре-существующий `PydanticDeprecatedSince20` в `src/config.py:4`
+(не относится к ORCH-067, не регресс).
+
+Целевые модули задачи:
+```
+$ python -m pytest tests/test_tracker_bump_default.py tests/test_tracker_status_line.py \
+    tests/test_tracker_issue_link.py tests/test_plane_issue_link.py \
+    tests/test_notify_issue_links.py tests/test_notify_done_regression.py -q
+57 passed, 1 warning in 1.39s
+```
+
+## Итог
+**PASS** — 907/907 тестов зелёные, все 18 TC и AC-1..AC-18 выполнены, smoke API OK,
+нерегресс для enduro-trails подтверждён. Задача готова к переходу на `deploy-staging`.
--- a/docs/work-items/ORCH-067/14-deploy-log.md
+++ b/docs/work-items/ORCH-067/14-deploy-log.md
@@ -0,0 +1,12 @@
+---
+deploy_status: SUCCESS
+work_item: ORCH-067
+hook_exit_code: 0
+deployed_by: deploy-finalizer
+---
+
+# Deploy log — ORCH-036 executable self-deploy
+
+Прод-деплой завершён хост-хуком с exit-code `0` -> `deploy_status: SUCCESS`.
+
+Вердикт зафиксирован детерминированным finalizer'ом (Фаза C), не LLM.
--- a/docs/work-items/ORCH-067/16-post-deploy-log.md
+++ b/docs/work-items/ORCH-067/16-post-deploy-log.md
@@ -0,0 +1,14 @@
+---
+post_deploy_status: HEALTHY
+action_taken: NONE
+work_item: ORCH-067
+window_s: 900
+checks_total: 30
+checks_failed: 0
+---
+
+# Post-deploy log — ORCH-021 post-deploy monitor
+
+Наблюдение прода завершено: `post_deploy_status: HEALTHY`, `action_taken: NONE`.
+
+Окно наблюдения: 900s; опросов всего: 30, из них с провалом: 0.