outbound-gate

OUTBOUND_GATE — исходящее только на живую просьбу (anton 26.07, строгий регламент)

ЦЕЛЬ: каждое исходящее (PR, коммент, DM, инвайт, пост-заявка, письмо) целится в ЧЬЮ-ТО живую потребность, а не в пустоту. Замер 26.07: 8 PR → человеческий отклик ровно у одного, единственного issue-matched. Возврат = чужая живая просьба, не наш объём.

ПОРЯДОК (шаги строго по очереди; провал шага = стоп, не шипим):

1. ПРЕРЫВАНИЕ-ЧЕК (всегда первым). Есть ли живой ответ человека на наше ПРОШЛОЕ исходящее (мейнтейнер на PR, ответ в DM, коммент)?

   • GitHub: gh pr list/gh api по нашим открытым PR (реестр в памяти/MEMORY.md) + вахта pr_watch.
   • Есть ответ → это прерывание №1: сначала отвечаем same-day, потом всё остальное (вкл. новый PR и ретро). Отклик экосистемы = сама суть миссии.
   • Просьба о КРЕДИТЕ = удовлетворить немедленно и щедро: co-author в authors/registry + референс на исходный issue, коммит с проверяемым диффом.
   • После нашего ответа тишина ~3 дня → ОДИН вежливый пинг («готово, скажи если поправить — same-day»), не чаще.

2. АНКЕР-ЧЕК: чью живую просьбу закрывает ЭТО исходящее? Обязателен линк-анкер:

   • PR → open issue / proposal / discussion мейнтейнера (радар: дашборд LLM-Cookbook-Radar + gh search issues);
   • DM/инвайт → его вопрос/боль/пост, на который отвечаем;
   • пост/заявка → явный запрос площадки/человека. Анкера НЕТ → НЕ шипим. «Ещё один рецепт/DM в пустоту» = антипаттерн. Либо ищем анкер (issue-matching), либо идея → alpha-backlog. Тихое прошлое исходящее не добивать объёмом — менять таргетинг.

1-бис. PRIOR-ART-ЧЕК В САМОМ РЕПО (anton 24.09, урок serena#2048 «already fixed via #2096»): перед PR/issue — ДВЕ команды по теме касания: gh pr list -R <repo> --search "<ключевые слова>" --state all --limit 10 + gh search issues --repo <repo> "<слова>" --limit 10; плюс беглый взгляд на свежие коммиты затронутого файла (gh api repos/<repo>/commits?path=<file>&per_page=5). Нашёлся открытый/свежезакрытый двойник → НЕ шипим свой, идём в ЕГО тред (ревью/коммент по §4.7). Класс: outbound-pr-duplicates-existing-work. 1-тер. ⭐ ПРАВО ВХОДА — ПРОВЕРЯЕТСЯ ВМЕСТЕ С ЗАНЯТОСТЬЮ, ОБА ДО СТРОЙКИ (08.10.2026). Дверь может быть никем не занята и при этом НЕ ПРИНИМАТЬ PR: репо требует assignment до PR и авто-закрывает остальное. Замер 05.10, оплаченный целым прогоном: pydantic/pydantic-ai#8582 пришла FREE (и это правда), вклад построен целиком, PR #9835 авто-закрыт ботом через минуту — а в CONTRIBUTING.md это стояло словами, то есть ловилось бесплатно ДО стройки. Единственный судья — python3 ~/.claude/scripts/door_claimcheck.py (JSONL с repo/issue на stdin): вердикт GATED = НЕ строим. ⛔ Копий этой логики здесь НЕ делаем — спрашиваем прибор. ⚠️ И ещё раз перед gh pr create: между отсевом и Send issue могут назначить другому.

1-тер. ПУТЬ-ВЕРИФИКАЦИИ-ЧЕК для веера (anton 24.09, урок Nango 10 PR): волна >2 однотипных PR → ДО отправки первого назвать, ЧЕМ каждый будет верифицирован (ключ/окружение/тест) и есть ли этот ресурс У НАС — сверка по реестру ~/.claude/registry/verification_park.json (status=have обязателен; absent там значит «не нашли в названном охвате», не «нет в мире» — нашёл ключ → допиши реестр). Ресурса нет → PR не рождается (или рождается ровно один пилот). Класс: fanout-before-verification-path-known, родня human-step-needs-forcing-function.

1-кватер. ОДИН РЕПО — ОДИН НАШ ОТКРЫТЫЙ PR (30.09.2026, оплачено QwenLM/Qwen-Agent#927). Два наших PR в одном репо конкурируют за внимание ОДНОГО мейнтейнера и вместе читаются как веер, даже если каждый по делу. #927 и #928 мы открыли в один день и #927 закрыли САМИ через сутки — работа впустую, потому что правила не было.

python3 ~/.claude/scripts/gh_pr_discipline.py one-pr <owner/repo>   # exit 1 = не открываем

exit 1 → новый PR НЕ рождается. Вместо него по порядку предпочтения: довести существующий до мержа (ответить, снять stale, ребейзнуть) · влить новую работу коммитом в него же, если тема та же · закрыть мёртвый своими руками ПЕРЕД новым · уйти в другой репо через /issue-match. exit 4 = забор упал: это не «чисто», вердикт не выдаём и не шипим (§5.4 индикатор = claim). Класс: two-our-prs-compete-in-one-repo, родня cold-pr-into-silent-queue. ⭐ ШАБЛОННОСТЬ (anton 01.10.2026, оплачено NangoHQ/nango): гейт ВСЕГДА зовётся с заголовком нового PR:

python3 ~/.claude/scripts/gh_pr_discipline.py one-pr <owner/repo> --title "<заголовок нового PR>"

Заголовок отличается от прошлых наших в этом репо ТОЛЬКО именем сущности (вендор/провайдер/язык/модель) и ни один из них не MERGED → exit 1 + вопрос «а первый по шаблону уже приняли?». N таких PR = ОДИН веер, а не N вкладов. Разрешено: один первый → вердикт человека → остальные, лучше одним PR на несколько сущностей, если их CONTRIBUTING это допускает. Замер: 9 PR «add support for <вендор>», 8 закрыты, а закрывающий коммент #7539 показал их процедуру на новый API — дверь была, но мы уже отстрелялись. Б (выше) считает ЧИСЛО открытых, это — ШАБЛОННОСТЬ; 1-тер — путь проверки. Три разных вопроса, не дубль. Класс: template-pr-fanout-one-repo. Тест: _test_gh_pr_discipline.py D1–D7 (красный до фикса 01.10).