# RELAY — ответы на вопросы технического ревью

**Дата:** 22.10.2026 · **Автор:** продуктовый дизайн + платформенная команда · **Статус:** на согласование с техлидом

---

## 0. Как читать этот документ

Техлид прислал **36 вопросов** в 10 темах (в сопроводительном письме фигурировало «30» — по факту вопросов 36, отвечаем на все).

Каждый ответ построен по одной схеме:

| Часть | Что это значит |
|---|---|
| **Короткий ответ** | Решение в одну-две фразы. Это то, что можно зафиксировать как ADR. |
| **Обоснование** | Ссылка на раздел технического проекта и логика, почему именно так. |
| **Что нужно от техлида** | Что осталось нерешённым или требует подтверждения. Ничего из этого не блокирует публикацию документа — всё фиксируется на Фазе 0/1. |

Приоритеты исходные: **P0** — блокирует старт, **P1** — блокирует MVP, **P2** — уточнить до Фазы 2.

Ссылки вида «§5.9» — разделы `01-технический-проект.md`.

---

## 0.1. Сводка: что меняется в техническом проекте по итогам ревью

| # | Вопрос | Принятое решение | Где зафиксировано |
|---|---|---|---|
| 1 | Агрегатор и координатор — один продукт? | Один продукт; в MVP агрегатор — основной сценарий, координатор — несущий слой | §11.2, §5.1 |
| 2 | Репозиторий платформы | Отдельный self-hosted сервис + тонкий CLI; стенд уже развёрнут | §6.1, §15 п.1 |
| 3 | Сколько адаптеров в MVP | Три: Claude Code, ChatGPT/Codex, Grok. Контракт — `RunResult` + `AgentAdapter` | §4.2, §6.3 |
| 4 | MCP-сервер | Свой, схема инструментов — публичный API платформы | §6.1, §6.3 |
| 5 | Events | Postgres, append-only, replay через пересборку проекций | §6.2, §7.2 |
| 6 | Истечение claim | Авто-возврат в `ready` + событие; эскалация — при повторе | §7.2, §6.2 |
| 7 | Breaking-флаг | Вычисляется по diff схемы, человек подтверждает спорное | §9.3 |
| 8 | pgvector для D-5 | В MVP не нужен: триграммы + правила; эмбеддинги — Фаза 2 | §7.3, §11.2 |
| 9 | Judge — роль или процесс | Процесс с владельцем-техлидом; правка промпта = ADR | §5.10 |
| 10 | Порог D-5 | В MVP блокировок нет — только пометка; порог калибруется на baseline | §14 R-6 |
| 11 | Веса ролей | Конфигурация проекта, по умолчанию — из RACI | §4.3 |
| 12 | N для D-6 | N = TTL/2, 15–60 мин, конфигурируемо; сам D-6 — Фаза 2 | §7.2, §11.3 |
| 13 | Политика режимов | Принимается как есть; порог 60% → в конфиг | §5.9 |
| 14 | Бюджет пилота | Пересчитан: $1,48/задачу → 338 задач при $500, не 110–180 | §5.11 |
| 15 | Cost ledger Grok | По токенам; в MVP достаточно per-task лимита | §5.4, §11.3 |
| 16 | Лимиты | 80% — предупреждение, 100% — пауза и эскалация; авто-понижения нет | §9.4 |
| 17 | Маппинг ролей | Таблица §4.2; Grok по умолчанию не пишет код | §4.2, §15 п.10 |
| 18 | SLA 1ч/4ч | Разделены: агентские и человеческие; 4 ч — только рабочее время | §4.4, §9.2 |
| 19 | Недоступный владелец зоны | Primary + fallback; зона никогда не остаётся без владельца | §4.4 |
| 20 | RACI | Утверждает владелец продукта, ревью — ежеквартально | §4.3 |
| 21 | `pass_with_warnings` | Не блокирует; warnings → отдельные задачи со сроком | §9.2 |
| 22 | Handoff-пакет | Валидирует платформа по JSON Schema; невалидный — не уходит в review | §9.2, §5.5 |
| 23 | Reject со ссылкой | Ссылка проверяется автоматически; неизвестный критерий → reject не принят | §9.2, §12 кр.5 |
| 24 | Redacting логов | Обязательный тест-кейс в критериях приёмки | §12, §14 R-8 |
| 25 | Секреты | Владеет пользователь; платформа — брокер и аудит | §15 п.9, §14 R-8 |
| 26 | Allowlist инструментов | Ведёт техлид; пересмотр ежемесячно; по умолчанию пуст | §14 R-8 |
| 27 | Baseline | 5 метрик, sales.travel, 2 недели ретро, `baseline.yaml` | §11.1, §13 |
| 28 | «85% без человека» | Это цель Фазы 3, не факт и не обещание MVP | §13 |
| 29 | «% задач из RELAY» | Порог 80% в Фазе 1, 95% в Фазе 2 | §14 R-1 |
| 30 | Ежемесячный тюнинг | Ритуал техлида, 1,5 ч/мес, привязан к ревью спринта | §5.9, §5.10 |
| 31 | R-1: работа мимо платформы | Соглашение + отсутствие выгоды: без claim нет контекст-пакета | §14 R-1, §6.3 |
| 32 | R-3: очередь гейтов | SLA 2 ч/8 ч рабочего времени; человек видит 2–3 готовых варианта | §14 R-3, §11.3 |
| 33 | R-5: дрейф интеграций | «Золотые» прогоны на каждый адаптер, гоняются в CI | §14 R-5 |
| 34 | 2-недельный срез | Принимается; sales.travel; техлид 0,3 + fullstack 1,0 FTE | §11.1, §15 п.8 |
| 35 | Владелец продукта | Вы; лично — цели, non_goals, релиз, бюджет, семантика | §4.3, §15 п.2 |
| 36 | Хранение артефактов | Git-репозиторий + RELAY как индекс; синхронизация — CI → webhook | §15 п.7, §6.1 |

---

## 1. Архитектура и границы

### В1. P0. Агрегатор и координатор — это один продукт или два режима?

**Короткий ответ.** Один продукт с двумя слоями, но в MVP пользовательский сценарий один — **агрегатор**. Координатор в MVP — несущая конструкция, а не отдельный продукт с отдельным интерфейсом.

**Обоснование.** Агрегатор (§5) физически не может работать без координатора: чтобы запустить три прогона, нужно взять claim, собрать Context Pack, проверить DoD-гейт, записать ADR и свести диффы. Это всё координатор. Обратное тоже верно: агрегатор — это 4 из 12 подсистем Фазы 1 (1.8–1.11), а не весь продукт. Делить кодовую базу на два проекта искусственно: у агрегатора и координатора одна схема БД (19 таблиц), один жизненный цикл задачи (§9.1), один контракт `RunResult`.

Практическая граница, которую я предлагаю зафиксировать явно:

- **RELAY (MVP) = агрегатор как главный сценарий** + минимальный координатор (Contract / Task / Handoff / Decision) как инфраструктура.
- **В MVP нет** авто-декомпозиции целей, авто-назначения, семантического поиска, cost-ledger-дашборда, Human Gate Service — это Фаза 2 (§11.3). Декомпозицию делает Product-агент вручную, агент забирает задачу через `relay pull`.

**Что нужно от техлида.**

1. Подтвердить, что «координатор» в MVP — внутренний слой без отдельного пользовательского интерфейса, и что доска в срезе 2 недели ограничена списком задач, а не полноценным UI.
2. Подтвердить, что авто-декомпозиции в MVP нет. Если техлид считает её обязательной для демонстрации агрегатора — это меняет сроки Фазы 1 минимум на 2 недели, и это надо назвать сейчас, а не в Фазе 2.

---

### В2. P0. Где живёт репозиторий платформы, кто его эксплуатирует и как обновляет?

**Короткий ответ.** Отдельный self-hosted сервис (Docker Compose) + тонкий CLI в отдельном репозитории. Решение уже принято и, что важно, **уже реализовано на практике**: стенд развёрнут, схема БД создана, health- и ready-эндпоинты работают.

**Обоснование.** Рекомендация §15 п.1 и §6.1. Монорепо с продуктовыми проектами отвергнут по трём причинам: у RELAY своя схема БД (19 таблиц) и свой жизненный цикл; продуктовые репозитории не должны зависеть от релизов платформы; обновление платформы должно быть одной операцией, а не «пересобрать всё, что задевает».

Фактическое состояние на сегодня: платформа развёрнута в отдельном контейнере, обслуживается как самостоятельный сервис с Docker Compose, образы собираются из репозитория платформы, миграции вшиты в образ и применяются при старте.

**Что нужно от техлида.**

1. Схема обновления: теги релизов или работа по ветке? Предлагаю **теги** — `v0.9.1` и т. д., откат = предыдущий тег + миграция с `down`.
2. Кто дежурит, если платформа упала в рабочем дне? Сейчас это не описано ни в одном разделе, а вопрос реальный: агент не может взять задачу, значит, работа команды встаёт.
3. Допустим ли self-managed Postgres (бэкапы и PITR — на владельце сервера) или нужен managed? Это влияет на стоимость и на §11.5.

---

### В3. P1. Адаптерный слой: сколько агентов реально подключаем в MVP, кто пишет адаптеры и на каком контракте?

**Короткий ответ.** Три инструмента: **Claude Code** (основной исполнитель), **ChatGPT/Codex** (второй исполнитель + ревьюер диффа), **Grok** (исследователь, код по умолчанию не пишет). Контракт — `RunResult` (§5.5) и интерфейс `AgentAdapter` (§6.3). Адаптеры пишет команда платформы; **владеет контрактом техлид**.

**Обоснование.** §4.2 фиксирует роли инструментов, §11.2 п.1.8 — подсистему адаптеров. Интерфейс намеренно минимален:

```
interface AgentAdapter {
  capabilities(): Capability[]          // design | code | research | verify | plan
  run(task: TaskEnvelope): RunHandle    // получает Context Pack + Task
  report(run: RunHandle): RunReport     // что сделано / не сделано / риски
}
```

`TaskEnvelope` = `{ contract_snapshot, context_pack, task, acceptance_checks, zone, deadline, budget }`. Правило, которое стоит зафиксировать: **всё, что не выражается через эти три метода, — не часть контракта**. Иначе каждый агент «немного свой», и сопоставление прогонов разваливается.

Сопоставимость трёх инструментов обеспечивается именно сведением к общему `RunResult`: `diff`, `checks`, `cost`, `verdict`, `artifacts` (§5.5). Именно этот контракт, а не «формат ответа модели», позволяет потом написать единый движок сведения и Judge.

**Что нужно от техлида.**

1. Подтвердить, что интерфейс из трёх методов достаточен. Особенно: `capabilities()` — по нему планировщик режимов (§5.9) будет понимать, кто на что способен.
2. Кто физически пишет адаптеры: инженеры платформы или сами агенты через API платформы? Предлагаю: адаптеры — инженеры, потому что от их качества зависит корректность сбора стоимости и DoD-вердиктов.
3. Подтвердить решение §15 п.10 — Grok по умолчанию не пишет код. Если техлид хочет Grok как кодописателя, меняются §5.4 (сведение) и §4.2, и это надо решить до начала.

---

### В4. P1. MCP-сервер — свой или сторонний? Кто владеет схемой инструментов?

**Короткий ответ.** Свой MCP-сервер RELAY, построенный на существующем SDK, а не на самописном протоколе. Схемой инструментов владеет платформа; она же отвечает за обратную совместимость.

**Обоснование.** §6.1 (Interface: Agent CLI + MCP-сервер + WebSocket/SSE-стрим) и §6.3 (pull-модель — агент сам ходит в RELAY за задачами). Сторонний MCP-сервер здесь не подходит: инструменты RELAY (`claim`, `report`, `handoff`, `pull`) несут продуктовый смысл, и их семантика — часть контракта. Взять чужой сервер и «навесить» на него эти операции — значит тащить в проект чужую модель прав и несовместимый lifecycle.

Но писать MCP с нуля не нужно: используем официальный SDK, свои — только схемы инструментов и бизнес-правила.

**Что нужно от техлида.**

1. Какой SDK берём (официальный TS или Python; или совместимая реализация, если нужен особый транспорт).
2. Имена инструментов и правило версионирования: имена — публичный API, semver, обратная совместимость гарантируется.
3. Как обнаруживаются новые инструменты: агент должен узнать о новом инструменте без обновления своей конфигурации — это влияет на то, как RELEASE NOTES пишутся.

---

## 2. Модель данных и состояние

### В5. P0. Events — append-only лента: где хранится, как обеспечивается replay, кто отвечает за миграции схемы?

**Короткий ответ.** Postgres, таблица `events`. Append-only на уровне приложения: в API нет ни `UPDATE`, ни `DELETE` для событий. Replay — пересборка проекций из ленты. Миграции схемы `events` — только вперёд, владеет backend-инженер платформы.

**Обоснование.** §6.2 (событийная модель как ключевое техническое решение), §7.2, критерий приёмки 8 (§12). Отдельный лог (Kafka/NATS) для MVP — явный оверинжиниринг: нам нужен replay по конкретной задаче и по проекту, а не бесконечный поток с партиционированием. Отдельная аналитическая БД — тоже: Postgres 16 + pgvector уже покрывает и состояние, и поиск.

Принципиальное разделение, которое стоит зафиксировать: **events — источник истины, а таблицы текущего состояния — проекции**. Поэтому «как откатить задачу в in_progress» — это не `UPDATE tasks`, а компенсирующее событие. Побочный выигрыш: метрики (§13) считаются из той же ленты, без отдельного пайплайна.

Replay должен быть **воспроизводимым**: та же последовательность событий даёт ту же проекцию. Значит, у события есть `seq` (монотонная последовательность), и никаких «текущих» значений внутри payload.

**Что нужно от техлида.**

1. Политика хранения: бесконечно в Postgres или с архивированием в S3 по возрасту (например, старше 90 дней)? Ошибочный `seq` при архивировании сломает replay — нужен ответ.
2. Что делать с поздними событиями (опоздавший handoff, пришедший после того, как проекция пересчитана): пересчитывать проекцию или отклонять событие?
3. Кто может писать в `events` напрямую. Предлагаю: только оркестратор — это упрощает рассуждение о порядке.

---

### В6. P1. Claims с lease и TTL — что происходит при истечении lease?

**Короткий ответ.** Артефакт **автоматически освобождается и возвращается в `ready`**; в ленту пишется событие `claim.expired`. Эскалация при истечении — нет: она была бы шумом. Эскалация возникает при **повторном** истечении по той же задаче.

**Обоснование.** §6.2 («Claim = lease с TTL. Истёкший TTL освобождает артефакт — "забытый" артефакт не блокирует проект навсегда»), §7.2 (`lease_until timestamptz NOT NULL`), критерий 3 (§12).

Схема работы:

- Агент продлевает lease **heartbeat'ом** раз в TTL/3. Пока heartbeat идёт, lease продлевается — и агент, который просто долго работает, ничего не теряет.
- Heartbeat пропал дольше TTL/2 → lease истекает, артефакт освобождается, задача возвращается в `ready`, пишется событие.
- Задача, у которой lease истёк **второй раз**, помечается флагом `flaky_claim` и уходит на разбор — это уже признак проблемы с агентом, а не с таймаутом.

Тонкость, которую надо зафиксировать: если у истёкшего claim'а был **частичный результат** (ветка, коммиты), задача возвращается в `ready` не «с нуля», а с пометкой «нужна переоценка состояния» — иначе работа агента теряется молча.

**Что нужно от техлида.**

1. Значения TTL по умолчанию: предлагаю 2 часа для обычных задач, 30 минут для задач с коротким контекстом, до 4 часов для задач с веб-поиском (Grok медленнее). Подтвердить или скорректировать.
2. Возврат всегда в `ready` или в `ready` с флагом переоценки при наличии частичного результата (предлагаю второе).
3. Кто чинит «мёртвые» claims: фоновый сборщик по TTL (предлагаю — он же пишет `claim.expired`) или ленивая проверка при следующем `pull`.

---

### В7. P1. Версионирование артефактов: кто и как определяет, что бамп breaking?

**Короткий ответ.** Breaking **вычисляется** по diff'у схемы, но **подтверждается человеком** в спорных случаях. То есть это не ручная метка и не чистый автомат.

**Обоснование.** §9.3, §7.2 (`artifact_versions` с breaking-флагом), §5.9 (жёсткое исключение: изменение `consumer_contract` — всегда Fan-out ×3).

Автоподсчёт покрывает ~90% случаев. Правила, которые предлагаю зафиксировать как формальный и версионируемый список:

| Признак в diff схемы | Breaking? |
|---|---|
| Поле удалено | да |
| Поле переименовано | да |
| Тип поля изменён | да |
| Поле стало `required` (было опциональным) | да |
| Значение удалено из `enum` | да |
| Поле стало `optional` | нет |
| Добавлено новое опциональное поле | нет |
| Изменено описание или `default` | нет, но помечается как «ревизия» |

Остаётся 10% — «структура не поменялась, а смысл поменялся». Пример: enum-значение `pending` переименовали в `awaiting_review`, структура та же, но потребитель, сравнивающий строки, ломается. Здесь нужен человек.

**Асимметрия ошибок** — то, ради чего я предлагаю подтверждение человеком: ложный `non-breaking` = тихая поломка потребителей, ложный `breaking` = лишний fan-out и лишние деньги. Первое дороже.

**Что нужно от техлида.**

1. Утвердить формальный список правил breaking — это таблица, которую надо версионировать вместе с контрактом.
2. Кто утверждает список: владелец продукта или техлид? Предлагаю техлид по формальным правилам, владелец — по исключениям из них.
3. Нужен ли «мягкий breaking» — признак «потребитель может сломаться, но, скорее всего, переживёт»? Полезно для семиминора.

---

### В8. P2. pgvector для D-5 — какая модель эмбеддингов, где хостится, кто платит за инференс?

**Короткий ответ.** В MVP эмбеддинги **не запускаем**. Для D-5 хватает триграммного индекса и правил дедупликации. Эмбеддинги — Фаза 2, когда накопится разметка.

**Обоснование.** §7.3 (GIN-индекс `gin_trgm` по `tasks.intent` — уже заложен под D-5), §11.2 (детекторы D-1, D-2, D-4, D-5 в Фазе 1), §14 R-6 (ложные срабатывания D-5 — высокая вероятность).

Практическая аргументация: эмбеддинги требуют (1) внешнего инференса — деньги, латентность и сетевой доступ, чего в нашем контуре нет по умолчанию; (2) хранения и пересчёта при смене модели; (3) калибровки порога, которой ещё не существует. Триграммы дают основную пользу (похожие формулировки) без внешней зависимости.

Если эмбеддинги всё же понадобятся: локальная модель на своём железе, эмбеддинги считает платформа, оплачивает владелец проекта из своего бюджета — **отдельной строкой**, не из «общего котла» пилота. И жёсткое правило: эмбеддинги никогда не блокируют задачу, только предлагают.

**Что нужно от техлида.**

1. Подтвердить, что D-5 в MVP работает без эмбеддингов.
2. Если нет — какая модель и где: локально в CT (медленно, но дёшево и безопасно) или внешний API (быстро, но зависимость и деньги).
3. Согласен ли техлид, что эмбеддинги в MVP **не блокируют**, а только помечают задачу как кандидата в дубликаты.

---

## 3. Движок конфликтов

### В9. P0. Judge: кто пишет промпт, кто его тюнит, кто разбирает ложные решения — это роль или процесс?

**Короткий ответ.** Это **процесс** с одним владельцем — **техлидом**. Техлид владеет промптом Judge, техлид проводит еженедельные разборы, каждый разбор оформляется как ADR.

**Обоснование.** §5.10 (контракт арбитра), §5.6, §5.4. Judge — узкое место: он включается только на семантических конфликтах, а не на каждой задаче (§5.6). Значит, частота срабатывания низкая, и работающая практика — «команда переписывает промпт по ходу дела» — вполне допустима, если она оформлена.

Процесс разбора:

1. Каждое решение Judge пишется в `events` с **полным пакетом входа и выхода** (§5.10) — это условие аудита.
2. Еженедельно берётся выборка из 20 решений и проверяется человеком пост-фактум. Метрика — точность авто-решений, цель ≥ 90%.
3. Каждое **ложное** авто-решение (отменённое человеком после применения) разбирается отдельно — это цель < 5%.
4. Разбор даёт одно из трёх: правка промпта, повышение порога `confidence`, добавление критерия во входной пакет. Любое из трёх — **ADR**, потому что меняет правила разрешения конфликтов.

**Что нужно от техлида.**

1. Подтвердить, что техлид — владелец промпта Judge (это прямо следует из того, что Judge — компонент платформы).
2. Подтвердить бюджет времени: 20 решений в неделю ≈ 1 час. Это нужно закладывать, а не делать «когда появятся силы».
3. Кто принимает решение о смене порога 0.7 — техлид единолично или с владельцем продукта? Предлагаю: техлид предлагает, владелец утверждает, потому что порог влияет на стоимость и на нагрузку на человека.

---

### В10. P1. D-5: порог близости по умолчанию — какой? Кто его калибрует на baseline из Фазы 0?

**Короткий ответ.** В MVP порога **нет**: D-5 работает как «предложение», а не как блокировка. Порог появляется после baseline и калибруется **владельцем продукта** по данным Фазы 0.

**Обоснование.** §14 R-6 — ложные срабатывания D-5 имеют высокую вероятность и среднее влияние. Цена ложного срабатывания (блокировка реальной, нужной задачи) выше цены пропуска (дубликат доживёт до ревью Product-агента). §11.1 требует baseline **до** старта Фазы 1.

Механика в MVP:

1. D-5 **помечает** вторую задачу как `duplicate_candidate` и показывает рядом похожие задачи с пересечением зон.
2. Блокировки нет. Product-агент (или человек) решает: объединить, оставить обе, переформулировать.
3. Каждое такое решение — обучающая пара: «дубликат / не дубликат». Пара записывается в разметку.
4. После накопления выборки (предлагаю 100–200 размеченных пар) подбирается порог, при котором precision ≥ 90%. Он становится параметром конфигурации, а не константой в коде.

**Что нужно от техлида.**

1. Готов ли он (или Product-агент) размечать пары «дубликат / не дубликат»? Это ~100–200 пар за Фазу 0 — работа на полдня, но её некому делать иначе.
2. Где хранить разметку: `labels/d5.csv` в репозитории проекта? Предлагаю там — версионируется и переживает смену платформы.
3. Кто утверждает целевой порог после калибровки.

### В11. P1. D-3: «человек, если веса ролей равны» — как определяются веса ролей? Это конфиг или хардкод?

**Короткий ответ.** Конфигурация проекта, а не хардкод. По умолчанию веса берутся из RACI (§4.3): **A > R > C > I**. Если веса равны — эскалация человеку.

**Обоснование.** §4.3, §14 R-6 (ложные срабатывания детекторов). Формулировка «веса ролей равны» на практике означает: оба решения претендуют на одну зону или на две зоны с одинаковым статусом — тогда решает человек.

Правило сравнения, которое предлагаю зафиксировать точнее, чем «веса ролей»:

> Сравниваются не роли авторов, а **приоритет решений в зоне, к которой относится конфликт**. Решение, принятое владельцем зоны (A), сильнее решения, принятого исполнителем (R) в другой зоне. Если обе стороны в равной позиции — эскалация.

Это лучше, чем сравнивать роли буквально, потому что иначе решение SEO-агента о семантике всегда проигрывало бы решению Product-агента о требованиях, даже когда зоны разные и конфликта нет.

**Что нужно от техлида.**

1. Подтвердить модель: веса по зонам или по ролям? Предлагаю — по зонам с дефолтом из RACI.
2. Где лежит конфиг: `relay.config.yaml` в репозитории проекта (тогда он версионируется и попадает в impact-граф) или в БД платформы (тогда быстрее менять, но теряется история)? Предлагаю — в репозитории, с ADR на изменение.
3. Как фиксируется изменение весов — тем же ADR, что и любое изменение правил.

---

### В12. P2. D-6: «агент молчит дольше N минут» — чему равно N и от чего зависит?

**Короткий ответ.** N = **TTL lease / 2**, с границами 15–60 минут для обычных задач; для задач с веб-поиском — до 2 часов. N конфигурируется на уровне проекта. Сам D-6 в MVP не работает: в Фазе 1 тихий сбой ловится грубее — по истечении claim.

**Обоснование.** §7.2 (`lease_until`), §6.3, §11.3 (**детектор D-6 и авто-переназначение — Фаза 2**). Разводить D-6 и lease имеет смысл: lease — это про владение артефактом, D-6 — про переназначение задачи другому агенту.

Механика:

- Heartbeat каждые TTL/3 — агент жив, lease продлевается.
- Нет heartbeat дольше TTL/2 → детектор срабатывает.
- Разница между провайдерами реальна: у Grok с веб-поиском ответ может идти долго, и общий таймаут убьёт нормальный прогон. Поэтому N настраивается на адаптер.

**Что нужно от техлида.**

1. Подтвердить формулу N = TTL/2 и границы.
2. Нужен ли разный N по провайдерам (у Grok — длиннее). Предлагаю да, с дефолтом из TTL адаптера.
3. Что делает авто-переназначение: тот же адаптер с чистым контекстом (проще, но теряем накопленное) или другой адаптер той же зоны (лучше разнообразие, но нужен перенос контекст-пакета). Предлагаю второй вариант с обязательной передачей контекст-пакета.

---

## 4. Политика режимов и экономика

### В13. P0. Политика выбора режима (Solo/Dual/Fan-out) — принимается в этой формулировке или техлид видит другие критерии?

**Короткий ответ.** §5.9 принимается в текущей формулировке. Владелец правила — **владелец продукта**, техлид правило исполняет. Со стороны техлида предлагается ровно одна правка формулировки: порог детектора дублирования 60% назвать **ориентиром по умолчанию** и вынести в конфигурацию, а не считать константой.

**Обоснование.** §5.9, §15 п.13, критерий приёмки 12 (§12). Четыре оси, детерминированное правило 0–2 / 3–4 / 5–8, жёсткие исключения — всё это проверяемо и не зависит от настроения в конкретный день. Важный нюанс, который надо проговорить прямо: **детерминированно правило, но не детерминирована оценка осей** — оси оценивает LLM, и поэтому у правила есть порог, лог и метрика качества (§5.9).

Именно поэтому предлагаю не «менять правило», а **измерить точность оценки осей**: сверять машинную оценку с решением человека на размеченной выборке. Если расхождение систематическое — правятся формулировки осей, а не пороги.

**Что нужно от техлида.**

1. Подтвердить, что порог 60% — конфигурация, и предложить значение по умолчанию.
2. Предложить способ проверки качества оценки осей (сравнение с решением человека на размеченной выборке — предлагаю 50–100 задач).
3. Подтвердить приоритет жёстких исключений над суммой баллов.

---

### В14. P0. Бюджет пилота $300–500/мес — пересчитан ли под реальный объём?

**Короткий ответ.** Да, пересчитан — и пересчёт даёт **не 110–180 задач, а 338 задач/мес** при бюджете $500, потому что политика режимов снижает стоимость задачи с $2,72 до **$1,48**.

**Обоснование.** §5.11. Расчёт:

| Величина | Значение |
|---|---|
| LLM-расход на задачу при наивном fan-out ×3 | $2,72 |
| Средний множитель режимов (Solo 55% / Dual 30% / Fan-out 15%) | **1,50×** вместо 2,75× |
| LLM-расход на задачу с политикой режимов | $2,72 × 1,50 / 2,75 = **$1,48** |
| Задач при LLM-бюджете $500/мес | 500 / 1,48 ≈ **338** |
| Задач при LLM-бюджете $300/мес | 300 / 1,48 ≈ **203** |
| Инфраструктура | ≈ $0 (своё железо, стенд уже развёрнут) |

То есть ~7–14 задач в рабочий день. Для «одного фича-спринта» этого более чем достаточно — спринт на 40–60 задач укладывается в **$60–90** LLM-бюджета. $300–500 — это потолок для пилота, а не целевой расход.

**Критическая оговорка, без которой расчёт врёт:** это **не чистая экономия, а перераспределение**. Мы тратим меньше на задачу, но делаем больше задач — лимит остаётся $500. Экономия появляется, когда появляется **свободное время человека**: без RELAY человек тратит его на ручную координацию, а с RELAY — на задачи.

**Что нужно от техлида.**

1. Подтвердить, что $300–500 — это потолок, а не цель, и что мы готовы не выбирать режим по принципу «потратим бюджет».
2. Нужен ли жёсткий месячный cap в cost ledger или мягкий (пауза на 100% от месячной нормы)? §9.4 описывает лимит на задачу и проект — но не месячный.
3. Как разделить бюджет пилота (на проверку платформы) и бюджет продуктовых проектов (на работу через RELAY). Сейчас это один котел, и это неверно: расходы на демонстрацию и расходы на работу — разные статьи.

---

### В15. P1. Cost ledger: как считается стоимость Grok (0 строк кода, но 7 фактов)?

**Короткий ответ.** **По токенам** — это единственная честная единица, потому что только она сопоставима между провайдерами. «Ценность факта» измеряется отдельной метрикой, не деньгами.

**Обоснование.** §5.4 (Grok → факты в отчёт и ADR, код не трогаем), §6.2 (полный аудит и cost ledger), §11.3 (**cost ledger — Фаза 2**).

Здесь важно не сломать MVP: по плану ledger — Фаза 2, и для Фазы 1 достаточно двух вещей:

1. **Лимит токенов на задачу** — работает уже в MVP, это §9.4.
2. **Фактическое потребление по каждому прогону** — пишется в `RunResult.cost` (§5.5) уже сейчас: `{ tokens, duration_s, usd }`.

Полноценный ledger (разрезы по проекту, по агенту, по модели, по дню) — Фаза 2. Это честная позиция: заявлять в MVP «полную стоимость задачи в проекте» нельзя, пока нет разрезов.

Отдельно про Judge: стоимость его прогона обязана идти **отдельной строкой `judge_cost`** (§5.10) — иначе решения арбитра растворяются в общей стоимости агрегации и их нельзя оптимизировать.

**Что нужно от техлида.**

1. Подтвердить, что в MVP достаточно per-task лимита плюс `cost` в `RunResult`, без полного ledger.
2. Как считать стоимость, когда трафик идёт через прокси/шлюз: по usage-данным провайдера (точнее) или по оценке по токенам и цене модели (дешевле, но может расходиться с фактом).
3. Подтвердить отдельную строку `judge_cost`.

---

### В16. P1. Лимиты на задачу и на проект — кто их устанавливает и что происходит при превышении?

**Короткий ответ.** Лимиты устанавливает **владелец проекта** (они лежат в контракте проекта), по умолчанию — из конфигурации платформы. При превышении: 80% → предупреждение агенту; 100% → **пауза и эскалация человеку**. Авто-понижение режима — **нет**.

**Обоснование.** §9.4. Причина, по которой авто-понижения быть не должно: оно тихо ухудшает результат, и пользователь узнаёт об этом только на ревью — то есть цена ошибки обнаруживается слишком поздно. Пауза + эскалация сохраняет явность, которая и является ценностью платформы.

**Важная деталь для fan-out, которой сейчас нет в §9.4:** лимит считается **суммарно на все прогоны задачи**, а не на каждый. Иначе задача с лимитом $2 при fan-out ×3 получит $6 молча — и именно этот баг делал бы экономику §5.11 неверной.

**Что нужно от техлида.**

1. Значения по умолчанию: на задачу и на проект.
2. Автопродление при эскалации — один раз или нет? Предлагаю: одно автопродление с пометкой, дальше — только человек.
3. Кто может увеличить лимит: только человек, через гейт. Подтвердить, что агент не может поднять свой лимит.

---

## 5. Роли, владение, SLA

### В17. P0. Маппинг пяти ролей (Product, Design, Eng, SEO, QA) на трёх агентов — какая таблица? Один агент может держать несколько зон?

**Короткий ответ.** Таблица §4.2 — это и есть маппинг. **Да**, один агент может держать несколько зон, но решает он их **по разным профилям**, и это отражается в профиле прогона.

**Обоснование.** §4.1 (пять проектных ролей и их зоны), §4.2 (маппинг на инструменты), §4.3 (RACI).

Сводная таблица:

| Проектная роль | Кто играет | Инструмент | Как именно |
|---|---|---|---|
| Реализация, рефакторинг, многофайловые изменения | Основной исполнитель | **Claude Code** | CLI headless + MCP, свой worktree |
| Альтернативная реализация, тесты, edge-cases, ревью диффа | Второй исполнитель и ревьюер | **ChatGPT (Codex)** | `codex exec` в отдельном worktree |
| Исследование, семантика, внешний контекст | Исследователь | **Grok** | xAI API + web search, код не пишет |
| Требования, критерии приёмки, приоритеты | Product / ведущий | **Человек** (или Claude Code в режиме plan) | Решения — ADR |
| Приёмка по DoD, регрессия | Верификатор | **Claude Code в отдельном прогоне** + CI | Прогон-верификатор ≠ прогон-автор |

Два правила, которые надо удерживать, потому что на них держится смысл всей конструкции:

- **Judge не может быть автором** (§4.2). Если Claude Code написал код, судьёй выступает отдельный запуск другого инструмента или человек.
- **Прогон-верификатор ≠ прогон-автора.** Это дешёво и снимает главный источник «зелёного, но некачественного» результата.

**Что нужно от техлида.**

1. Подтвердить решение §15 п.10: Grok по умолчанию **не пишет код**. Если техлид хочет Grok как кодописателя — меняются §5.4 (сведение) и §4.2, и это надо решить до старта, а не в процессе.
2. Кто верифицирует DoD в MVP: отдельный прогон Claude Code или CI? Предлагаю: CI как источник фактов + отдельный прогон как интерпретатор. Требует ещё одного прогона, но это дешевле, чем переделки.
3. Как зоны в MVP назначаются агентам: вручную в `relay.config.yaml` или автоматически по `capabilities()`. Предлагаю: в MVP — вручную, это быстрее и предсказуемее.

---

### В18. P1. SLA 1ч/4ч — разделён ли на агентов и людей? Для человека-верификатора 4 часа реалистичны?

**Короткий ответ.** **Разделён, и это обязательно.** 1ч/4ч — это SLA **агента** на ответ по заявке и хендоффу (§4.4, §9.2). Для человека нужен отдельный SLA, и 4 часа для человека реалистичны **только в рабочее время**.

**Обоснование.** §4.4 (SLA владельца зоны), §9.2 (получатель обязан ответить вердиктом за SLA), §15 п.4 (человек в контуре: только гейты + 1 разбор в день).

Предлагаемое разделение:

| Кто | Блокирующее | Обычное | В нерабочее время |
|---|---|---|---|
| Агент | 1 час | 4 часа | не применимо — агент работает всегда |
| Человек | 2 рабочих часа | 8 рабочих часов | очередь, эскалация утром |

Почему нельзя смешивать: если «решено за 4 часа» в ночном счётчике означает «человек посмотрел в 9 утра», то метрика MTTR конфликта (§13) систематически занижается, а ожидания по SLA становятся бессмысленными.

**Что нужно от техлида.**

1. Подтвердить разделение агентского и человеческого SLA.
2. **Реальный режим доступности владельца.** Это ключевой вход: если вы доступны 4 часа в день, порог эскалации и SLA приёмки надо ставить выше, чем «8 рабочих часов», иначе система будет постоянльно эскалировать в пустоту. Если недоступность — выходные и вечер, честный SLA — «1 рабочий день», и это надо назвать сразу.
3. Нужен ли «анонимный» режим приёмки — верификатор-агент без человека. В плане это Фаза 3 (§11.4), и если техлид хочет его в MVP, критерий 10 (§12) ослабляется.

---

### В19. P1. «Правило одного владельца зоны»: что происходит, если владелец зоны — агент, который недоступен?

**Короткий ответ.** Зона **никогда не остаётся без владельца**. У зоны есть primary owner и **fallback owner** (по умолчанию — второй экземпляр того же адаптера), который принимает зону автоматически, с записью в `events`.

**Обоснование.** §4.4. Ключевая мысль: **владение зоной — это право на интерфейс, а не персональная обязанность**. Поэтому оно делегируемо по умолчанию, и агент, который «недоступен», не блокирует работу, а просто перестаёт быть первым в очереди.

Цепочка деградации:

1. Primary owner не отвечает в пределах SLA → зону принимает fallback owner, пишется событие `zone.owner_fallback`.
2. Fallback тоже не отвечает в пределах 2×SLA → эскалация человеку-владельцу проекта.
3. Человек недоступен → зона остаётся **явно помеченной** «нет владельца», задачи в ней не висят молча, а видны в очереди на разбор.

Важная деталь: пункт 3 — это сознательное решение. Альтернатива «закрыть зону и раздать задачи другим» нарушила бы правило одного владельца и породила бы конфликты прав, которые RELAY как раз и устраняет.

**Что нужно от техлида.**

1. Подтвердить, что fallback — это второй экземпляр **того же** адаптера (а не другой инструмент: иначе меняется стиль кода в зоне, и это дороже, чем простой сбой).
2. Нужны ли «human-owned зоны» — например, `zone:copy` может по определению принадлежать человеку. Предлагаю да, и это снимает часть вопроса с SLA.
3. Кто назначает fallback при смене адаптера или при добавлении нового — конфиг проекта или платформа автоматом.

---

### В20. P2. RACI-матрица: кто утверждает изменения в ней и как часто пересматривается?

**Короткий ответ.** Утверждает **владелец продукта**, техлид готовит изменение как ADR. Пересмотр — **раз в квартал** и при любом изменении зон, контракта или состава агентов.

**Обоснование.** §4.3, §6.2 («оркестратор оптимизирует поток, но не имеет права менять цели; гейты — единственный путь изменения контракта»).

Отдельно стоит подумать, нужна ли **проверка RACI против фактического поведения** агентов: матрица говорит, кто за что отвечает, но агент может взять задачу из чужой зоны. Это уже ловится детектором D-2 (§ нарушение контракта → claim отклоняется). То есть RACI — это ожидание, D-2 — его enforcement. Стоит только явно сказать это в документе, чтобы не искали отдельный механизм.

**Что нужно от техлида.**

1. Где хранится матрица: в `contract.yaml` проекта (версионируется, попадает в impact-граф) или отдельно в платформе (быстрее менять, но без истории)? Предлагаю — в `contract.yaml`.
2. Нужна ли автоматическая проверка «фактические claims ⊆ зоны из RACI» как отдельный отчёт. Детектор D-2 её закрывает частично — он ловит нарушения в момент claim, но не даёт сводки «какая зона фактически принадлежит кому сейчас».

---

## 6. Handoff и приёмка

### В21. P1. Семантика DoD-вердиктов: pass / pass_with_warnings / fail — что делает pass_with_warnings при сведении?

**Короткий ответ.** **`pass_with_warnings` не блокирует.** Артефакт принимается, предупреждения превращаются в отдельные задачи. Блокирует только `fail`.

**Обоснование.** §9.2, §10 (шаг 8) — в примере сквозного сценария вердикт `accept_with_comments` с одним замечанием и одним мелким багом закрывает задачу, а замечание уходит в отдельную задачу. Это и есть рабочая семантика.

Практический смысл: если warnings блокируют, DoD-гейт превращается в гарантированный источник задержек, и люди начинают «перебивать» вердикт — то есть система перестаёт быть достоверной.

**Правило, которое предлагаю добавить:** у warnings есть срок. Незакрытая warning старше 5 рабочих дней поднимается в эскалацию. Иначе «не блокирует» превращается в «забывается».

**Что нужно от техлида.**

1. Подтвердить, что warnings не блокируют сведение.
2. Кто превращает warning в задачу: система автоматически или верификатор вручную? Предлагаю автоматически — иначе теряется.
3. Есть ли категории warnings, которые **всё же** блокируют. Предлагаю две: проблемы безопасности и дрейф дизайн-токенов (§11.4) — то есть ровно те, где цена ошибки асимметрична.

---

### В22. P1. Handoff-пакет: какие поля обязательные и опциональные, кто валидирует пакет и что происходит при невалидном пакете?

**Короткий ответ.** Валидирует **платформа**, автоматически, по JSON Schema — до приёма. Невалидный пакет = задача **не переходит в `review`**, агент получает машинный список ошибок и чинит пакет.

**Обоснование.** §9.2 («пустой `not_done` при отсутствии рисков — норма, но `done` без единого пункта — ошибка валидации»), §5.5 (`RunResult`), критерий 1 (§12).

Поля пакета:

| Поле | Обязательное | Что значит |
|---|---|---|
| `done` | **да** | Что сделано. Минимум одна строка. |
| `not_done` | да | Что не сделано и почему. Может быть пустым, если рисков нет. |
| `changed` | да | Что и как изменилось: артефакты, версии, зоны. |
| `risks` | да | Известные риски. Может быть пустым. |
| `checks` | да | Результаты DoD-проверок: имя, результат, значение. |
| `artifact_refs` | да | Ссылки на версии артефактов, которых касается задача. |
| `suggested_followups` | нет | Предложения по следующим задачам. |
| `screenshots` | нет | Визуальные приложения. |
| `notes` | нет | Свободные заметки. |

Принципиальный момент: **валидация машинная, не человеческая**. Человек не должен ловить «пустой done» — это работа схемы. Иначе на 5 handoff'ах ручная проверка съедает смысл автоматизации.

**Что нужно от техлида.**

1. Утвердить финальный список полей — в частности, обязательность `changed` и `artifact_refs`: это влияет на то, сможет ли impact-граф работать.
2. Нужна ли линтер-команда для локальной проверки пакета до отправки (предлагаю `relay report --check`), чтобы агент не тратил цикл на отказ.
3. Нужны ли «тихие» handoff'ы — минимальный пакет для однострочных правок? Предлагаю: да, но не в MVP — иначе схема разрастётся исключениями.

---

### В23. P2. Reject со ссылкой на критерий — кто проверяет, что ссылка валидна?

**Короткий ответ.** **Платформа, автоматически.** Ссылка должна указывать на критерий, существующий в `acceptance` задачи или в `consumer_contract` артефакта. Ссылка на несуществующий критерий → reject **отклоняется валидатором**.

**Обоснование.** §9.2 п.3 («вердикт `reject` без ссылок на нарушенные критерии не принимается системой»), критерий 5 (§12).

Это двусторонняя защита:

- от «отклонил потому что не нравится» — reject без ссылки не проходит;
- от «отклонил, сославшись на свой выдуманный критерий» — несуществующий критерий не проходит.

**Что нужно от техлида.**

1. Разрешены ли ссылки на `non_goals` и на ADR (предлагаю — да, это первые кандидаты на «критерий», который не в acceptance);
2. Что делать с вердиктом, в котором есть ссылка, но нет рассуждения: валидируем ли структуру «ссылка + текст» или достаточно ссылки? Предлагаю требовать и то, и другое — пустые рассуждения не проходят.
3. Нужен ли fuzzy-режим, когда критерий сформулирован иначе, чем в acceptance. Предлагаю в MVP — не делать: fuzzy-сопоставление критериев отменяет дисциплину формулировок, а дисциплина критериев и есть ценность.

## 7. Безопасность

### В24. P0. Sandbox без сети по умолчанию: как тестируется redacting логов? Есть ли тест-кейс «агент сгенерировал код с секретом»?

**Короткий ответ.** Да, такой тест-кейс есть, и я предлагаю **внести его в критерии приёмки MVP** — сейчас в §12 его нет, и это пробел. Redacting проверяется по конкретным паттернам, а не «на глаз».

**Обоснование.** §6.2 (sandbox исполнения: изолированный контейнер без сети и секретов, кроме allowlist), §14 R-8, §5.8 (промпт-инъекция из веба, особенно от Grok).

Предлагаемые тест-кейсы (их стоит добавить в §12 отдельным пунктом):

| # | Кейс | Ожидание |
|---|---|---|
| S-1 | Агент пишет в код строку вида `sk-ant-…` | Значение вычищено из логов, stdout, `events`; в коде остаётся плейсхолдер или ошибка линтера |
| S-2 | Агент печатает `env` | В лог попадают только allowlist-заглушки, реальные значения — нет |
| S-3 | Агент пытается обратиться к сети | Соединение отклонено **на уровне сети контейнера**, а не на уровне промпта |
| S-4 | В лог агента попадает внешняя веб-страница с инструкцией «выполни команду X» | Страница идёт в канал «данные», не в инструкции; команда не выполняется |
| S-5 | Агент читает файл вне своей зоны | Отказ на уровне sandbox, попытка зафиксирована в `events` |

S-4 — не формальность: §5.8 называет промпт-инъекцию из веба специфичным риском агрегации, а Grok — единственный, кто ходит в веб по умолчанию.

**Что нужно от техлида.**

1. Утвердить список паттернов redacting (ключи API, токены, строки подключения, PEM-блоки). Маскировать или удалять — маскировать (иначе логи становятся нечитаемыми), но с пониманием, что маска сама по себе утечка не даёт.
2. Решить: в `events` секреты маскируются или вырезаются полностью? Предлагаю вырезать — `events` читаются чаще, чем логи.
3. Кто пишет тест-кейсы безопасности — отдельный инженер или это часть DoD основной команды. Предлагаю: тест-кейсы в общий критерий приёмки, пишет тот, кто делает sandbox.

---

### В25. P1. Секреты: кто владеет ими — платформа или пользователь? MCP-broker с аудитом — свой или сторонний?

**Короткий ответ.** **Владеет пользователь** (или его провайдер секретов). Платформа — **брокер доступа и аудит**, но не хранилище долгоживущих ключей. Брокер — **свой**, минимальный, поверх MCP, с полным журналом обращений.

**Обоснование.** §15 п.9 (ключи платформы в secret-хранилище, доступ по проекту и лимиту; в репозитории — только идентификаторы), §14 R-8, §6.1.

Модель владения:

- Платформа хранит **ссылку** на секрет и правила доступа: какой проект, какая зона, какой лимит, какой срок.
- Каждая заявка агента на секрет — запись в `events`: кто, какая зона, какая цель, какой объём, какой результат.
- Срок жизни выдачи — ограниченный (по умолчанию — время жизни прогона), а не «навсегда до отзыва».

Про «свой или сторонний» для брокера: сторонний MCP-broker не решает нашу задачу, потому что наша политика доступа — продуктовая (зоны, лимиты, проекты), а не техническая. Свой минимальный брокер поверх MCP — это несколько сотен строк и полный контроль аудита.

**Что нужно от техлида.**

1. Какой secret-хранилище используем: внешний (Vault, Yandex/Key Vault и т. п.), SOPS в репозитории или переменные окружения платформы? Это решение эксплуатации, и от него зависит §11.5.
2. Кто выдаёт доступы и как это вписывается в гейты: предлагаю, чтобы выдача доступа к секрету была отдельной задачей с вердиктом.
3. Нужна ли двусторонняя модель — агент получает временный токен к внешнему сервису вместо самого секрета. Это лучше, но требует поддержки на стороне сервиса.

---

### В26. P2. Allowlist инструментов: кто его ведёт и как часто пересматривается?

**Короткий ответ.** Ведёт **техлид**. Пересмотр — **ежемесячно** и **немедленно** после каждого инцидента. Allowlist — часть контракта проекта, версионируется вместе с ним.

**Обоснование.** §14 R-8 (sandbox без сети по умолчанию, allowlist инструментов, секреты только через MCP-broker с аудитом, redacting логов), §6.2.

Принцип, который предлагаю зафиксировать: **allowlist по умолчанию пустой.** Расширение — только с обоснованием в ADR: какой инструмент, зачем, какой риск, какой срок. Инструмент, добавленный «на пять минут», имеет срок.

Практическая деталь: `npm install`, `git push`, `curl` и запуск тестов — это не один allowlist, а разные уровни. Управление сетевыми вызовами должно быть **отдельным** правилом, а не одной строкой в списке инструментов.

**Что нужно от техлида.**

1. Базовый набор инструментов на MVP: `git` (read/write в пределах ветки прогона), `npm ci`, `tsc`, тест-раннер, `relay` CLI, MCP-инструменты RELAY.
2. Как часто — ежемесячно достаточно? Плюс автоматический пересмотр при смене версии образа.
3. Процедура экстренного расширения: кто может разрешить «дать доступ сейчас» и как это потом фиксируется в ADR.

---

## 8. Процесс и метрики

### В27. P0. Baseline из Фазы 0: какие метрики замеряем, на каком проекте, кто замеряет и в каком формате?

**Короткий ответ.** Метрики определены в §13 (колонка «baseline»); проект — **sales.travel**, объём — **один фича-спринт**; замеряет **владелец продукта**; формат — `baseline.yaml` в репозитории проекта, версионируется.

**Обоснование.** §11.1 («Baseline-замер: сколько конфликтов, сколько переделок, сколько часов на согласование»), §13 («Baseline обязателен до старта Фазы 1 — иначе эффект платформы невозможно доказать»), §15 п.3.

Минимальный набор — **5 чисел**:

| # | Метрика | Как получить | Зачем |
|---|---|---|---|
| B-1 | Конфликты за спринт | Ретроспектива по чатам и тикетам | Базовый счётчик конфликтов (§13) |
| B-2 | Rework Rate | Доля задач, возвращавшихся в работу | Основной эффект платформы (§5.7) |
| B-3 | First-Pass Acceptance | Доля handoff'ов без reject | Главная метрика качества (§13) |
| B-4 | Lead time goal → done | Из планировщика | Guardrail против R-4 (§14) |
| B-5 | Прямой LLM-расход на задачу | Биллинги провайдеров | База для экономики §5.11 |

**Метод.** 2 недели ретроспективы по последнему спринту + подъём логов согласований. Не «ощущение», а цифры: иначе baseline станет тем, чем был до этого — «примерно 30–40% задач переделываем».

**Формат.** `baseline.yaml` в репозитории проекта: метрика, значение, период, источник, кто замерял. Версионируется — это позволит потом показать дельту «до/после» без споров о памяти.

**Что нужно от техлида.**

1. Подтвердить окно в 2 недели.
2. Нужен ли инструмент сбора (скрипт, выгружающий из трекера) или достаточно ручного заполнения формы. Предлагаю: вручную, но по шаблону `baseline.yaml` — автоматизация сейчас не окупается.
3. Где хранить: предлагаю в репозитории проекта, рядом с `contract.yaml`.

---

### В28. P0. Цифра «85% конфликтов без человека» — это цель или факт?

**Короткий ответ.** Это **цель Фазы 3**, а не факт и не обещание MVP. Фактом по плану является ≥ 60% в MVP.

**Обоснование.** §13 — в таблице прямо стоит: «Конфликты, закрытые без человека: — | ≥ 60% | ≥ 85%», то есть «—» в MVP означает «ещё не измерено», а 85% стоит в колонке «Целевое (Фаза 3)».

Откуда взялась цифра — проектное допущение, и его надо назвать: из шести типов конфликтов четыре (D-1, D-2, D-4, D-5) закрываются автоматически, D-3 — частично, семантические — через Judge с порогом 0,7. **Проверяемо** это становится только на Фазе 1 (критерии 6 и 7: детекторы срабатывают, авто-разрешения попадают в журнал).

**Что нужно от техлида.**

1. Подтвердить, что 85% — цель, а не обещание MVP. Если техлид настаивает на «85% в MVP», это означает перенос части Фазы 2 в Фазу 1 и +2–3 недели.
2. Что входит в счётчик: только конфликты, зафиксированные **RELAY**, или все конфликты, включая неформальные? Предлагаю: считаем только зафиксированные RELAY, иначе счётчик зависит от внимательности людей.
3. Соглашение по «без человека»: закрыто системой без гейта — или закрыто системой, но человек потом согласился? Предлагаю первое, второе — отдельная метрика «согласие после авто-решения».

---

### В29. P1. Метрика «% задач из RELAY» как guardrail против R-1 — какой целевой порог и что происходит при его недостижении?

**Короткий ответ.** Порог — **80% задач спринта взяты через RELAY** к концу Фазы 1; в Фазе 2 — 95%. При недостижении — **разбор, а не наказание**.

**Обоснование.** §14 R-1 («Pull-модель: агент берёт задачи только из RELAY; интеграция в MCP/промпт по умолчанию; метрика "% задач из RELAY"»), критерий 1 (§12).

Формула: `(задачи, взятые через relay pull) / (все задачи спринта)`.

Метрика работает **только в связке с First-Pass Acceptance**. Если 80% задач идут через RELAY, а FPA падает — значит, платформа вредит, и это видно на второй метрике. По одной этой цифре судить нельзя: можно гнать 100% задач через платформу и при этом делать их хуже.

**Что нужно от техлида.**

1. Кто ведёт счётчик: платформа (это её данные, и она может отдавать его в еженедельный отчёт автоматически).
2. Подтвердить, что недостижение порога — это разбор причин, а не наказание; иначе метрика начнёт «улучшаться» за счёт того, что люди перестанут фиксировать часть работы.
3. Базовый порог на старте пилота — какой? Предлагаю 50% на первую неделю и 80% к концу Фазы 1.

---

### В30. P1. Ежемесячный тюнинг D-5 и Judge — кто владеет ритуалом и как он встроен в календарь?

**Короткий ответ.** Ритуал принадлежит **техлиду**. Бюджет — **1,5 часа в месяц**. Встраивается в календарь как ревью спринта, а не «когда получится».

**Обоснование.** §5.9 (метрика качества политики: доля задач, где режим был повышен после reject, и доля fan-out'ов с консенсусом с первого раза; цель — оба < 15%), §5.10 (правило тюнинга: каждое ложное авто-решение → разбор → обновление промпта или порога, запись в ADR), §14 R-6 (регулярный тюнинг по логу).

Формат ритуала (предлагаю зафиксировать как процедуру):

1. **Срез метрик за месяц**: точность авто-решений Judge, доля эскалаций, доля ложных авто-решений, доля повышенных режимов, доля fan-out'ов с консенсусом с первого раза.
2. **Разбор 20 решений Judge** — проверка человеком пост-фактум (§5.10).
3. **Разбор всех ложных авто-решений** — обязательно.
4. **Решения**: правка промпта Judge / изменение порога / правка формулировок осей §5.9 / правка конфигурации. Любое — ADR.
5. **Обновление конфигурации** и запись в журнал.

**Что нужно от техлида.**

1. Подтвердить 1,5 часа в месяц как реалистичную цифру.
2. Где живёт «календарь»: предлагаю привязать к ежемесячному ревью спринта, а не к отдельному календарному событию — иначе ритуал будет пропускаться первым.
3. Кто подписывает правки промпта Judge: техлид единолично или с владельцем продукта (предлагаю — с владельцем, потому что порог влияет на нагрузку на человека).

---

## 9. Риски и решения

### В31. P0. R-1 (агенты работают мимо платформы) — что технически мешает взять задачу из чата?

**Короткий ответ.** **Технически — ничего**, и это надо признать прямо. Работает не запрет, а **отсутствие выгоды** плюс организационное соглашение.

**Обоснование.** §14 R-1, §6.3 (pull-модель), критерий 1 (§12).

Логика: агент может получить ту же задачу из чата и просто не сообщить об этом — RELAY не может это запретить, не контролируя агента. Значит, защита строится на том, чтобы работа мимо платформы была **дороже**:

1. `relay pull` — единственный способ узнать acceptance, зону, бюджет и срок. В чате этого нет.
2. **Без claim в RELAY агент не получает Context Pack** (§6.1) — то есть артефакты, ADR, DoD-чеклисты, историю зоны. Работая мимо, агент собирает контекст сам или работает вслепую.
3. Без claim агент не может закрыть задачу: результат без вердикта не попадает в `done`, а значит, не попадает в метрики и не получает следующую работу.
4. Метрика «% задач из RELAY» делает видимым то, что происходит, когда соглашение нарушается.

Это уважительно к реальности: агент — не подконтрольный процесс, а инструмент в руках человека. Соглашение «задачи берутся из RELAY» — часть §4.1 (роли и зоны), а не отдельный документ.

**Что нужно от техлида.**

1. Согласовать формулировку соглашения — «задачи берутся только из RELAY» — и место его в §4.1.
2. Подтвердить, что D-2 (работа вне зоны) блокирует именно агентов, ходящих через RELAY, и не претендует на агентов вне системы. Это честная граница возможностей.
3. Нужно ли включать в `relay` CLI подсказку «задача N уже в работе» при попытке взять дубликат из чата — то есть телеметрия из мира вне RELAY. Предлагаю: не делать, но собрать ручную оценку на Фазе 0.

---

### В32. P1. R-3 (RELAY — бутылочное горлышко) — SLA на гейты: кто следит за очередью решений человека и что происходит при переполнении?

**Короткий ответ.** SLA на гейты — **2 рабочих часа** для блокирующих и **8 рабочих часов** для обычных. Очередь решений — отдельный экран (Human Gate Service, Фаза 2). При переполнении — **авто-понижение приоритета**, но не блокировка.

**Обоснование.** §14 R-3 («Авто-разрешение по правилам; человек видит только 2–3 варианта; SLA на гейты»), §11.3 (Human Gate Service), критерий 2 (§12).

Главный приём против R-3: **человек видит не задачу, а 2–3 готовых варианта с обоснованием** — и от него требуется один выбор, а не разбор контекста. Именно это, а не «больше людей», снижает MTTR (§13). Сюда же относится правило Judge: на эскалацию приходит не вопрос «кто прав», а готовые варианты (§5.10).

При переполнении очереди предлагаю не блокировку, а **понижение**: обычные гейты уходят в конец очереди, блокирующие остаются. Если очередь растёт — это сигнал, что авто-разрешения недостаточно, и это предмет тюнинга §5.9/§5.10, а не предмет «давайте подождём».

**Что нужно от техлида.**

1. Кто в очереди: один владелец или ротация? Предлагаю: один владелец с явным дежурством — ротация без регламента даёт 100% эскалаций «кто сегодня дежурит».
2. Согласен ли техлид с авто-понижением режима задачи (Dual вместо ×3) при переполнении? Это конфликт с §5.9 («жёсткие исключения переопределяют сумму»), и решение должно быть явным.
3. Нужен ли лимит длины очереди — и что делаем при его превышении: останавливаем приём новых задач или продолжаем с понижением?

---

### В33. P2. R-5 (дрейф интеграций) — контрактные тесты адаптеров: кто их пишет и как часто прогоняются?

**Короткий ответ.** Да — набор **«золотых» прогонов** на каждый адаптер. Пишет владелец адаптера (тот, кто его реализовал). Гоняются автоматически при каждом обновлении образа или версии CLI провайдера.

**Обоснование.** §14 R-5 («Адаптерный слой + контрактные тесты адаптеров; поддержка ≥ 3 агентов на старте»), §11.2 п.1.8, §12.

Состав минимального набора:

1. **Смоук-прогон**: одна задача, один файл, самый простой сценарий — проверяет, что адаптер вообще запускается и возвращает результат.
2. **Проверка формы `RunResult`** по схеме — это главная защита от дрейфа: если провайдер обновил CLI и поле переехало, ловится сразу.
3. **Проверка закреплённых версий** CLI провайдера в образе — версия не «последняя», а зафиксированная.
4. **Проверка стоимости**: usage-поле заполнено и непустое — иначе cost ledger деградирует молча.

Частота: при каждой сборке образа с изменённым адаптером; полный прогон — раз в неделю, в том числе на «ничего не менялось» — именно он ловит тихий дрейф внешнего провайдера.

**Что нужно от техлида.**

1. Минимальный набор «золотых» кейсов — согласовать состав: предлагаю 1 смоук + 1 проверка формы + 1 проверка usage.
2. Подтвердить частоту: еженедельно — приемлемо?
3. Владение: адаптер = владелец = ответственный за зелёный статус. Подтвердить, что «зелёный» статус адаптера виден в общем health-эндпоинте платформы.

---

## 10. Первый шаг

### В34. P0. 2-недельный срез (доска + контракт + handoff + ADR) — принимается? Кто в команде эти 2 недели и какой проект берём?

**Короткий ответ.** **Принимается.** Проект — **sales.travel**. Команда: техлид 0,3 FTE + fullstack/backend 1,0 FTE + владелец продукта (вы) на один разбор в день.

**Обоснование.** §11.1 (Фаза 0 — процесс без кода, 1–2 недели), §15 п.8 (горизонт: 2-недельный срез → показ → полный MVP).

Состав среза — ровно четыре предмета из §11.1:

| Предмет | Что сдаём | Критерий готовности |
|---|---|---|
| `contract.yaml` | Для 2–3 текущих проектов | Есть зоны, DoD, acceptance, non_goals |
| ADR | Шаблон + первые 10 решений | Решения реально принимаются и используются |
| Handoff | Регламент и шаблон пакета | Пакет проходит валидацию схемой |
| Доска | Список в любом трекере | Видны состояния и владельцы зон |
| Baseline | 5 метрик (§27) | `baseline.yaml` в репозитории |

**Что нужно от техлида.**

1. Подтвердить состав среза: в него входит **baseline** — без него Фаза 1 недоказуема (§13).
2. Кто делает «доску»: если это полноценный UI — работы больше, чем на 2 недели. Предлагаю: список задач с состояниями в существующем трекере, без отдельного интерфейса; UI доски — в Фазе 1 (п.1.2).
3. Нужен ли отдельный репозиторий для среза или он живёт внутри основного репозитория платформы. Предлагаю: внутри, в `platform/`, отдельной директорией.

---

### В35. P0. Кто владелец продукта RELAY — вы лично или делегируется техлиду? Какие гейты вы закрываете лично?

**Короткий ответ.** **Владелец продукта — вы.** Лично вы закрываете гейты из RACI, где у человека стоит **A**: изменение целей и non_goals, релиз, семантика и контент-план, требования и приоритеты, а также бюджет и решения об эскалации.

**Обоснование.** §4.3 (колонка «Человек»), §15 п.2, §6.2 («оркестратор оптимизирует поток, но не имеет права менять цели; гейты — единственный путь изменения контракта»).

Разделение получается такое:

| Гейт | Кто закрывает |
|---|---|
| Изменение целей, non_goals, приоритетов | **Вы** |
| Релиз | **Вы** |
| Семантика и контент-план | **Вы** |
| Бюджет, лимиты, авто-продления | **Вы** |
| Эскалация при равных весах ролей (D-3) | **Вы** |
| Архитектура, ADR, риски, изменения правил | **Техлид** |
| Конфликты зон, слияние, приоритет версий | **Техлид** |

**Следствие, которое надо назвать прямо:** если вы доступны 4 часа в день, максимум гейтов в день ограничен, и это напрямую влияет на SLA (§18) и на R-3 (§32). Владелец продукта — это не только роль, это **календарь доступности**, и его надо зафиксировать до начала Фазы 1, а не выяснять в первый же конфликт.

**Что нужно от техлида.**

1. Подтвердить разделение: продуктовые гейты — ваши, технические — техлида. Если техлид претендует на часть продуктовых (например, релиз), это меняет §4.3.
2. Делегируете ли часть гейтов после первого успешного спринта — и по какому критерию.
3. Как фиксируется, что гейт закрыт: подпись в системе, ADR, запись в `events`. Предлагаю — все три, но автоматически: `events` пишет факт, ADR — содержание.

---

### В36. P1. Формат хранения артефактов: git-репозиторий + RELAY как индекс — принимается? Кто настраивает синхронизацию?

**Короткий ответ.** **Принимается.** Артефакты живут в git-репозитории проекта: дизайн-токены — JSON, спеки — Markdown, схемы — JSON Schema. RELAY — **индекс и реестр версий**, но не хранилище содержимого.

**Обоснование.** §15 п.7, §6.1 (Artifact Registry), §9.3 (версионирование), §5.11 (contract-first: типы генерируются из схемы, а не из скриншота).

Разделение обязанностей:

| Git-репозиторий проекта | RELAY (индекс) |
|---|---|
| Содержимое артефактов | Ссылка на версию и её хэш |
| Diff, история, revert, code review | Impact-граф: кто потребляет версию |
| Pull request на изменение токенов | Связь с задачами и handoff-пакетами |
| Merge в основную ветку | DoD-гейт: проверка соответствия контракту |

Почему именно так: git даёт всё, что нужно для аудита и отката, и работает с существующими инструментами команды без нового хранилища. RELAY даёт то, чего git не умеет: impact-граф, DoD-гейт и связь артефакт → задача → handoff.

**Синхронизация (мой ответ на «кто настраивает»):** CI-джоб в репозитории проекта после merge в основную ветку вызывает API RELAY → RELAY перечитывает артефакты, пересчитывает impact-граф, помечает затронутые задачи и устаревшие handoff-пакеты. Частота — по событию push, а не по расписанию.

**Что нужно от техлида.**

1. Кто настраивает синхронизацию: инженер платформы (предлагаю — он же владелец интеграционного слоя §6.1).
2. Подтвердить частоту: по push или по расписанию. Предлагаю — по push, с фолбэком-расписанием на случай, если CI-джоб не отработал.
3. Как разрешаются расхождения «в репо новее, чем в RELAY»: предлагаю — RELAY доверяет git и перечитывает при следующей синхронизации, а расхождение показывает как предупреждение, а не как блокировку.

---

## 11. Что осталось нерешённым

Семь пунктов требуют ответа техлида до старта Фазы 1. Остальные решения уже зафиксированы в техническом проекте и не требуют повторного обсуждения.

| # | Вопрос | Почему важно | Срок |
|---|---|---|---|
| 1 | Кто дежурит при падении платформы в рабочий день | Агент не может взять задачу — работа команды встаёт | До старта Фазы 1 |
| 2 | Реальный календарь доступности владельца продукта | Определяет SLA приёмки и допустимую нагрузку на гейты | До старта Фазы 1 |
| 3 | Правило breaking: список признаков и кто утверждает | Определяет автоматический бамп версий | До старта Фазы 1 |
| 4 | Авто-понижение режима при переполнении очереди гейтов или нет | Конфликт с §5.9, должен быть явным решением | До старта Фазы 1 |
| 5 | Инфраструктура: self-managed или managed Postgres | Влияет на стоимость и на §11.5 | До Фазы 1 |
| 6 | Baseline: готов ли техлид размечать пары для D-5 | Без разметки порог не откалибровать | В течение Фазы 0 |
| 7 | Secret-хранилище: какой используем | Определяет модель владения секретами (§25) | До начала работы с ключами |

---

## 12. Как ответы соотносятся с техническим проектом

Ответы **не меняют** архитектуру RELAY. Они уточняют места, где документ был неопределён:

- **§5.9 (политика режимов)** — добавлено: порог 60% → конфигурация; измерение точности оценки осей.
- **§5.10 (контракт Judge)** — добавлено: ритуал разбора, владелец промпта, ADR на каждую правку.
- **§5.11 (экономика)** — уточнено: $300–500 — потолок, а не цель; $500 ÷ $1,48 = 338 задач, а не 110–180; разделение бюджета пилота и бюджета проектов.
- **§9.4 (правила бюджета)** — добавлено: лимит суммарный на все прогоны задачи, а не на каждый.
- **§7.2 (claims)** — уточнено: возврат в `ready` с флагом переоценки при наличии частичного результата.
- **§12 (критерии приёмки)** — добавлено: тест-кейсы безопасности S-1…S-5; критерий на суммарный лимит fan-out.
- **§13 (метрики)** — уточнено: 85% — цель Фазы 3, а не обещание MVP; baseline = 5 конкретных метрик.
- **§4.4 (владение зоной)** — добавлено: primary + fallback owner.
- **§9.2 (правила handoff)** — добавлено: состав полей пакета, машинная валидация, срок для warnings.

Полный построчный трек ответов — в разделе 0.1 «Сводка» и в `04-ответы-на-вопросы-ревью.md`.

---

*Конец документа. Согласование: владелец продукта + техлид. Следующий шаг — ответы по §11 и старт Фазы 0.*