diff --git a/.env.example b/.env.example
index 40423d9..9f413e1 100644
--- a/.env.example
+++ b/.env.example
@@ -12,11 +12,25 @@ ORCH_GITEA_WEBHOOK_SECRET=
 ORCH_CLAUDE_BIN=/usr/bin/claude
 ORCH_REPOS_DIR=/home/slin/repos
 ORCH_DB_PATH=/app/data/orchestrator.db
-# ORCH-042: live-tracker mode. edit (DEFAULT) -> the task card is edited in place
-# (editMessageText). bump -> on every update the old card is deleted and a fresh
-# one is sent silently to the BOTTOM of the chat (deleteMessage + sendMessage +
-# repoint). One card per task in both modes. Any value other than "bump" -> edit.
-ORCH_TRACKER_MODE=edit
+# ORCH-042/ORCH-067: live-tracker mode. bump (DEFAULT since ORCH-067) -> on every
+# update the old card is deleted and a fresh one is sent silently to the BOTTOM of
+# the chat (deleteMessage + sendMessage + repoint), so the current status is always
+# the last message in an active chat. edit -> the task card is edited in place
+# (editMessageText). One card per task in both modes. Any value other than "bump"
+# (incl. empty/garbage) -> edit.
+ORCH_TRACKER_MODE=bump
+# ORCH-067: best-effort live-overlay for the card status line. The offline core
+# (stage -> Plane status, In Review from the brd-clock) always works without network;
+# the overlay only fills in branches indistinguishable offline (Needs Input / Blocked /
+# Rejected / Cancelled / Deploying / Monitoring after Deploy) by reading the LIVE Plane
+# status with a short timeout + per-issue TTL cache. It NEVER blocks the pipeline and
+# NEVER raises.
+#   LIVE_STATUS         -> kill-switch (false -> offline core only).
+#   LIVE_STATUS_TTL_S   -> TTL (seconds) of the per-issue live-uuid cache (hot-path guard).
+#   LIVE_STATUS_TIMEOUT_S -> timeout (seconds) of a single live-GET on the render path.
+ORCH_TRACKER_LIVE_STATUS=true
+ORCH_TRACKER_LIVE_STATUS_TTL_S=60
+ORCH_TRACKER_LIVE_STATUS_TIMEOUT_S=3
 # ORCH-043: merge-gate (auto-rebase onto current origin/main + re-test + merge-lock)
 # on the deploy-staging -> deploy edge. Deterministic sub-gate (no LLM) that catches
 # the branch up to the CURRENT origin/main, re-tests it, and serialises merges so two
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 6f5361f..7b37bec 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -5,6 +5,7 @@
 ## [Unreleased]
 
 ### Added
+- **Telegram live-tracker: `bump` по умолчанию + статус-строка Plane + кликабельный номер задачи** (ORCH-067): три улучшения карточки задачи (`src/notifications.py`), без изменения транспорта/схемы БД/`STAGE_TRANSITIONS`/QG. (1) **Дефолт `tracker_mode` сменён `edit → bump`** (`src/config.py`): актуальный статус всегда последним сообщением в чате при активной переписке; `edit` остаётся доступен через `ORCH_TRACKER_MODE=edit`. Логика `update_task_tracker` (best-effort `delete_telegram(old)` → `send_telegram(..., disable_notification=True)` → `set_tracker_message_id` только при успешном send) и инвариант «одна карточка на задачу» сохранены. (2) **Статус-строка карточки** `📍 <status_label>` по статусной модели ORCH-066: чистый/детерминированный, never-raise хелпер `plane_status_label(task_row)` (любая ошибка → дефолт по `stage`, рендер не ломается). Оффлайн-ядро (`stage → Plane-статус`; `⏸️ In Review` из brd-clock; `⏸️ Awaiting Deploy`) работает всегда без сети; ветки, неотличимые offline (`❓ Needs Input`, `Blocked`, `Rejected`, `Cancelled`, `Deploying`, `Monitoring after Deploy`), дорисовывает **best-effort live-overlay** `_live_plane_branch_override` — читает живой Plane-статус (reverse-map UUID→имя) с kill-switch'ем, per-issue TTL-кэшем и коротким таймаутом; недоступность сети/ответа → тихая деградация на stage-маппинг, конвейер НИКОГДА не блокируется (ADR Р-2/Р-3/Р-4). (3) **Кликабельный номер задачи**: единый never-raise хелпер `plane_issue_link(work_item_id, plane_issue_id, project_id, repo)` → `<a href={web_base}/{workspace}/projects/{project_id}/issues/{issue_id}/>ORCH-NNN</a>`, переиспользует guard'ы ORCH-017 (`_plane_issue_url`, loopback-base → «нет web URL»); fail-safe (не хватает web_base/workspace/project_id/issue_id) → `html.escape(work_item_id)` (номер без ссылки). Применён в заголовке карточки (`render_task_tracker` дочитывает `repo`/`plane_issue_id` из `tasks`, схема не менялась) и во всех точках `send_telegram`/`notify_*`, где в тексте есть `work_item_id` (`notify_approve_requested`/`notify_error`, `stage_engine.py`, `agents/launcher.py`, `merge_gate.py`, `job_reaper.py`, `security_gate.py`, `reconciler.py`, `main.py` — ровно где упоминается номер). Новые настройки: `ORCH_TRACKER_LIVE_STATUS` (true, kill-switch), `ORCH_TRACKER_LIVE_STATUS_TTL_S` (60), `ORCH_TRACKER_LIVE_STATUS_TIMEOUT_S` (3). Самохостинг: смена дефолта `bump` затрагивает ВСЕ проекты — проверено отсутствие регресса (тесты + staging). ADR `docs/work-items/ORCH-067/06-adr/ADR-001-tracker-plane-status-and-link.md`. Документация: `CLAUDE.md` (раздел «Нотификации / Telegram live-tracker»), `docs/architecture/README.md`, `docs/architecture/internals.md` (§7), `.env.example`.
 - **Merge-в-`main` + пост-деплой верификация как обязательное условие `done` (фикс «фантомного merge»)** (ORCH-071): задача могла дойти до `done`, хотя ветка фактически НЕ влита в `main` («фантомный merge») — конвейер рапортовал успех без реального состояния репозитория. Введён под-гейт ребра `deploy → done`: единственная точка перехода `advance_stage` теперь гейтится `_handle_merge_verify` (`src/stage_engine.py`), который покрывает ВСЕ пути финализации (finalizer Phase C, reconciler F-1, job-reaper). Добавлены детерминированный merge-актор и пост-деплой верификатор (`src/merge_gate.py`): merge выполняется ТОЛЬКО через PR-merge API (без push/force-push, INV-4) в restart-surviving Phase C, верификация подтверждает фактическое слияние в `main` прежде чем разрешить переход в `done`. Раскат условный и снабжён kill-switch (`src/config.py`, `src/main.py`, по образцу условности ORCH-35/43/58), never-raise контракты соблюдены. Документация: глобальный `docs/architecture/adr/adr-0013-merge-verify-gate.md`, детальный `docs/work-items/ORCH-071/06-adr/ADR-001-merge-verify-gate.md` (D1–D9), раздел в `docs/architecture/README.md`, runbook постмортема `docs/operations/PHANTOM_MERGE_RUNBOOK.md` (4 проверки + критерий «фантом подтверждён» + remediation). Тесты: `tests/test_merge_actor.py`, `tests/test_merge_verify.py`, `tests/test_deploy_finalizer_merge_gate.py`, `tests/test_deploy_restart_merge_recovery.py`, `tests/test_qg_checks.py`, `tests/test_stages.py`.
 - **Security-гейт: secret-scanning (gitleaks) + dependency audit (pip-audit) перед мержем** (ORCH-022): автономный конвейер вливал ветку в `main` без проверки на утёкший секрет (ключ/токен/пароль/приватный ключ) и уязвимую зависимость (известный CVE) — для self-hosting `orchestrator` это особенно остро: один общий прод-инстанс обслуживает все проекты из общей БД, поэтому секрет/CVE, проскочивший через одну задачу, уезжает в прод всех проектов (CLAUDE.md §self-hosting, §8). ORCH-022 вводит детерминированный (без LLM) **security-гейт как под-гейт ребра `deploy-staging → deploy`**, исполняемый **ПЕРВЫМ** среди edge-под-гейтов (ДО merge-gate ORCH-043 и image-freshness ORCH-058) — дёшево фейлить до дорогих rebase/rebuild, а скан ветки ДО rebase не «обвиняет» задачу в CVE из обновившегося `main`. Паттерн соседей: новый leaf-модуль `src/security_gate.py` (контракт «never-raise», по образцу `merge_gate`/`image_freshness`/`staging_verdict`) + тонкая обёртка `check_security_gate` в реестре `QG_CHECKS` (`src/qg/checks.py`, lazy-import → нет цикла) + врезка `_handle_security_gate` в `src/stage_engine.py` в блок `current_stage == "deploy-staging"` ПЕРВОЙ. `STAGE_TRANSITIONS` и схема БД — **без изменений**. **Secret-scanning (`gitleaks`, offline):** скан диапазона `origin/main..HEAD` (ровно коммиты задачи); любой секрет вне аллоулиста версионируемого `.gitleaks.toml` → вклад в FAIL. Полностью оффлайн (локальные правила) → гарантия «секрет всегда блокирует» (BR-2) безусловна, не зависит от сети; **fail-closed** при ошибке инструмента/отсутствии бинаря/таймауте (нельзя доказать «секретов нет» → FAIL). Контракт exit-кодов: 0=чисто, 1=найдено, ≥2=ошибка. **Dependency audit (`pip-audit`, OSV/PyPI):** аудит `requirements.txt`; severity ≥ `security_dep_block_severity` (дефолт `HIGH`, порядок CRITICAL>HIGH>MEDIUM>LOW) → вклад в FAIL (`deps_blocking`); ниже порога / UNKNOWN → warning (`deps_warning`, анти-петля Р-4, не авто-блок). Источник advisory требует сети → недоступность фида **fail-open + громкий warning** по умолчанию (`deps_audit_degraded: true` + Telegram + лог; прецедент анти-петли ORCH-061), флаг `security_dep_audit_fail_closed` переводит в строгий режим без редеплоя кода. **Артефакт `17-security-report.md`** (YAML-frontmatter `security_status`/`secrets_found`/`deps_blocking`/`deps_warning`/`deps_audit_degraded` + тело-списки находок); машинный вердикт читается ТОЛЬКО из frontmatter (гейт пишет → читает обратно через `parse_security_status` → возвращает ровно то, что записал: единый источник истины, AC-8), negative-токен (FAIL) авторитетен, нет frontmatter/битый YAML/нет поля → **fail-closed** на чтении; значения секретов в артефакте маскируются (не ре-лик). **FAIL → откат на `development`** + developer-retry (общий `_developer_retry_count`, cap `MAX_DEVELOPER_RETRIES`=3, затем `set_issue_blocked` + Telegram, без бесконечного баунса); `task_desc` перезапущенного developer'а несёт дословные находки (`extract_security_findings`, паттерн ORCH-046) + ссылку на артефакт. **Self-hosting safety:** гейт только читает/сканирует/пишет артефакт — не вызывает деплой-хук, не рестартит прод-контейнер (под-гейт исполняется ДО захвата merge-lease → при FAIL lease освобождать не нужно). **Условность как ORCH-35/43/58:** `security_gate_enabled` (kill-switch) + `security_gate_repos` (CSV; пусто → только self-hosting `orchestrator`); таймаут `security_scan_timeout_s`; never-raise. v1 — Python-only стек; SAST/мульти-стек — follow-up (BR-14). Инфраструктура: pinned `gitleaks` (статический Go-бинарь) в `Dockerfile` (+ `curl`/`ca-certificates`), `pip-audit` (pinned) в `requirements.txt`, `.gitleaks.toml` в корне репо. Новые настройки: `ORCH_SECURITY_GATE_ENABLED` (true), `ORCH_SECURITY_GATE_REPOS` (""), `ORCH_SECURITY_DEP_BLOCK_SEVERITY` (HIGH), `ORCH_SECURITY_SCAN_TIMEOUT_S` (300), `ORCH_SECURITY_DEP_AUDIT_FAIL_CLOSED` (false), `ORCH_SECURITY_SECRETS_BLOCK` (true). Инварианты НЕ менялись: `STAGE_TRANSITIONS` (9 стадий), `check_branch_mergeable`/`check_staging_image_fresh` и их под-гейты, БАГ-8 откат, terminal-sync, схема БД (без миграций). ADR `docs/work-items/ORCH-022/06-adr/ADR-001-security-gate.md`, глобальный `docs/architecture/adr/adr-0012-security-gate.md`. Документация: `docs/architecture/README.md`, `CLAUDE.md`, `.env.example`. Тесты: `tests/test_security_gate.py`, `tests/test_qg_security.py`, `tests/test_stage_engine_security_gate.py`, `tests/test_qg_registry_snapshot.py`, `tests/test_config.py`.
 - **Выделенный статус-триггер прод-деплоя «Confirm Deploy»** (ORCH-059): жест запуска прод-деплоя отделён от человеческого гейта одобрения. Раньше один Plane-статус `Approved` был перегружен: на `analysis` он работал как человеческий гейт BRD (`check_analysis_approved`), а на `deploy` — молча триггерил Фазу B прод-деплоя ORCH-036 (`advance_stage(deploy, finished_agent=None) → _handle_self_deploy_phase_b → detached host-рестарт прод-контейнера 8500`). Привычный жест approve = групповой self-hosting риск (прод обслуживает ВСЕ проекты из одного инстанса). ORCH-059 вводит отдельный логический статус `confirm_deploy` («Confirm Deploy»), который триггерит **ТОЛЬКО** Фазу B на `deploy`; `Approved` остаётся исключительно гейтом конвейера. Четыре точечные правки в трёх модулях: (1) `src/plane_sync.py` — маппинг `"Confirm Deploy" → "confirm_deploy"` в `_PLANE_NAME_TO_KEY`; ключ намеренно НЕ добавлен в `_DEFAULT_STATES` (нет UUID для enduro/fallback) → **fail-closed**: для проекта ORCH резолвится из живого Plane API (`get_project_states(orch)["confirm_deploy"]` → реальный UUID), для сред без статуса (enduro / недоступный API / доска без статуса) ключ просто отсутствует, доступ через `.get("confirm_deploy")` → `None`, без `KeyError`. (2) `src/webhooks/plane.py` — `handle_issue_updated` ДО ветки `approved` добавляет fail-closed-ветку `confirm_state = proj_states.get("confirm_deploy"); if confirm_state and new_state == confirm_state: handle_confirm_deploy(...)`; новый `handle_confirm_deploy` резолвит задачу, гард `stage == "deploy"` (иначе no-op с логом — защищает прочие гейты от случайного триггера), иначе → `_try_advance_stage(..., confirm_deploy=True)`. `handle_verdict(approved=True)` не изменён (продолжает звать `_try_advance_stage` с дефолтным `confirm_deploy=False`). (3) `src/stage_engine.py` — `advance_stage` получил keyword-only параметр `confirm_deploy: bool = False` (обратносовместимо: все существующие вызовы из launcher/reconciler/finalizer передают `finished_agent`); блок Фазы B теперь **всегда возвращается рано** для `deploy + finished_agent is None` self-hosting, но `_handle_self_deploy_phase_b` вызывается ТОЛЬКО при `confirm_deploy=True`, иначе (обычный `Approved`) — детерминированный **no-op** (`result.note = "approved-on-deploy-noop"`): возврат ДО блока Quality Gate → `check_deploy_status` не запускается → нет ложного отката БАГ-8 (вердикта ещё нет, R-2). (4) CTA Фазы A (`_handle_self_deploy_phase_a`) — Plane-коммент и Telegram просят перевести задачу в статус «Confirm Deploy» (а не «Approved»). Следствие для reconciler F-1 на `deploy` (ORCH-053): попадает в no-op-ветку вместо неявного запуска Фазы B → прод-деплой нельзя инициировать автоматически, только явным человеческим «Confirm Deploy» (усиление safety). Условность как ORCH-35/36 (реально только для `self_deploy.self_deploy_applies("orchestrator")`; прочие репо — прежний синхронный ssh-деплой агентом, статус не нужен и не влияет). Контракты НЕ менялись: `STAGE_TRANSITIONS`, реестр `QG_CHECKS`, `check_deploy_status`/`_parse_deploy_status`, exit-код-контракт хука (0/1/2), Фазы A/C, merge-gate, terminal-sync, схема БД (статусы — на стороне Plane; restart-safe состояние деплоя — существующие sentinel-файлы ORCH-036). Эксплуатационное предусловие: в Plane-проекте ORCH создать статус доски «Confirm Deploy» (точное имя, регистр) + сброс кэша состояний — `docs/work-items/ORCH-059/07-infra-requirements.md`. До создания статуса прод-деплой через approve не запустится (желаемое fail-closed-поведение). ADR `docs/work-items/ORCH-059/06-adr/ADR-001-confirm-deploy-status.md` (уточняет триггер Фазы B относительно adr-0007). Тесты: `tests/test_plane_states.py`, `tests/test_plane_confirm_deploy.py`, `tests/test_stage_engine_phase_b.py`, `tests/test_stage_engine_phase_a_cta.py`, `tests/test_confirm_deploy_integration.py`, `tests/test_deploy_approve.py` (обновлён под новый триггер).
diff --git a/CLAUDE.md b/CLAUDE.md
index 4b633ab..7b3b780 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -41,6 +41,22 @@ created → analysis → architecture → development → review → testing →
 ## Статусная модель Plane (ORCH-066) — индикация ≠ управление
 Статусы Plane — это **слой B (индикация)**, отдельный от **слоя A (машина стадий)** `src/stages.py::STAGE_TRANSITIONS`. Plane показывает наблюдателю осмысленную картину (`Backlog → Todo → Analysis → Architecture → Development → Code-Review → Testing → Awaiting Deploy → Deploying → Monitoring after Deploy → Done` + человеческие гейты `In Review/Approved`, `Confirm Deploy`), но НИКОГДА не управляет конвейером. Маппинг и сеттеры — `src/plane_sync.py` (6 новых ключей: `to_analyse/analysis/code_review/awaiting_deploy/deploying/monitoring`), с project-relative alias-fallback: на частично сконфигурированном проекте новый ключ деградирует на базовый UUID ТОГО ЖЕ проекта (нулевая регрессия для enduro-trails). Детали — `docs/architecture/README.md`.
 
+## Нотификации / Telegram live-tracker (ORCH-042/066/067)
+Каждая задача = **одна карточка** в Telegram (`src/notifications.py`). Поведение карточки:
+- **Дефолт `tracker_mode` — `bump`** (ORCH-067; `edit` доступен через `ORCH_TRACKER_MODE=edit`).
+  `bump` на каждом обновлении удаляет старую карточку и шлёт свежую вниз чата (тихо), `edit`
+  редактирует на месте. Инвариант «одна карточка на задачу» — в обоих режимах.
+- **Статус-строка карточки** (`📍 <status_label>`) показывает текущий Plane-статус по модели
+  ORCH-066 (`plane_status_label`). Оффлайн-ядро (`stage → статус`, In Review из brd-clock)
+  работает всегда без сети; best-effort live-overlay (kill-switch `tracker_live_status`,
+  TTL-кэш, короткий таймаут) лишь дорисовывает ветки, неотличимые offline (Needs Input /
+  Blocked / Rejected / Cancelled / Deploying / Monitoring) и **никогда не блокирует конвейер**.
+- **Кликабельный номер задачи** (`plane_issue_link`) — `ORCH-NNN` в карточке И во всех
+  уведомлениях (`notify_*`, alert'ы стадий) рендерится как `<a href=…>` на issue в Plane;
+  fail-safe → просто `html.escape(номер)`, если ссылку построить нельзя. Никогда не падает.
+- Транспорт (`send_telegram`/`edit_telegram`/`delete_telegram`), `disable_notification`
+  (карточка тихая, пингуют только alert-хелперы), схема БД — не трогаются.
+
 ## Конвенции
 - Conventional Commits (`feat:`, `fix:`, `docs:`, `refactor:`, `test:`)
 - Ветки: `feature/ORCH-NNN-slug`, `fix/ORCH-NNN-slug`