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

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

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

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

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

0.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% случаев. Правила, которые предлагаю зафиксировать как формальный и версионируемый список:

Остаётся 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. Расчёт:

То есть ~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).

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

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

• 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 разбор в день).

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

Почему нельзя смешивать: если «решено за 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» — это работа схемы. Иначе на 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-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 чисел:

Метод. 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:

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

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 («оркестратор оптимизирует поток, но не имеет права менять цели; гейты — единственный путь изменения контракта»).

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

Следствие, которое надо назвать прямо: если вы доступны 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 даёт то, чего 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. Остальные решения уже зафиксированы в техническом проекте и не требуют повторного обсуждения.

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.