@rt-tools/agent-kit 0.16.1 → 0.18.0

package/assets/patterns/git-workflow-stack.md

@@ -2,7 +2,7 @@
 name: git-workflow-stack
 kind: pattern
 rule: git-workflow
-description: Паттерн правила git-workflow. Брать, когда из одного основания заведено больше двух веток и все ждут слияния: единица работы, порядок вливания, перевливание главной по факту конфликта, сложение у общих указателей. Один конфликт — паттерн git-workflow-merge.
+description: Паттерн правила git-workflow. Брать, когда работы идут одна за другой либо когда из одного основания уже заведено больше двух веток: ветвление чередой от предыдущей, основание заявки, порядок вливания снизу вверх, перевливание главной по факту конфликта. Один конфликт — паттерн git-workflow-merge.
 ---
 
 # Стопка заявок из одного основания
@@ -11,12 +11,70 @@ description: Паттерн правила git-workflow. Брать, когда
 `docs/constitution/delivery.md`. Разбор одного конфликта — паттерн `git-workflow-merge`,
 открытие одной заявки — `git-workflow-pr`.
 
+**Вызовы здесь даны клиентом GitHub.** Дерево на другом хостинге читает их как форму, а команду
+берёт у своего клиента: имена полей и подкоманд у клиентов разные, а спрашиваемое — одно.
+Соответствие называет редакция правила поставки, разложенная в этом дереве.
+
 ## Когда брать
 
 - Из одного основания заведено больше двух веток, и все ждут слияния.
 - За заход сделано несколько работ, и они лежат в дереве невыложенными.
 - Решается, в каком порядке отдавать накопленное владельцу.
 
+## Череда: ветвиться от предыдущей, а не от главной
+
+Стопка из одного основания — то, чего надо избежать. Работы, идущие подряд, ветвятся подряд:
+
+```bash
+# первая работа череды — от главной, как обычно
+git checkout -b <КЛЮЧ>-<номер>-<slug> origin/main
+
+# каждая следующая — от предыдущей ветки, а не от origin/main
+git checkout -b <КЛЮЧ>-<следующий>-<slug> <КЛЮЧ>-<номер>-<slug>
+```
+
+Правка предыдущей лежит тогда в общем предке, и сводить два разных изменения одного файла не
+приходится вовсе. Расхождение всплывает при ветвлении — у того, у кого обе правки свои и под
+рукой, — а не при слиянии, у владельца, у которого нет ни одной.
+
+От главной ветвится первая работа череды и всякая, которая предыдущей не касается: череда — это
+про соседние работы, а не про все подряд.
+
+## Заявка череды стоит на предыдущей ветке
+
+```bash
+gh pr create --base <предыдущая ветка> --title '[<КЛЮЧ>-<номер>] <что сделано>' --body-file <файл>
+```
+
+Основанием главная не ставится: разбор тогда показывает свою правку вперемешку со всем, что под
+ней. Влитую нижнюю хостинг переносит сам — базой её заявки-наследницы становится главная.
+
+Порядок вливания стоит в теле каждой заявки строкой «стоит на #<номер>, вливать после него»:
+владелец вливает по списку, а родство веток по списку не видно.
+
+**Конвейер дерева проверяется на то, слушает ли он заявку с таким основанием.** Событие заявки
+хостинг шлёт с фильтром по базе, и дерево, оставившее в фильтре одну главную ветку, всей череде
+прогонов не даёт вовсе: заявка стоит зелёно-пустой, а вернуть событие нечем — ни новый коммит,
+ни перезакрытие заявки базы не меняют. Спрашивается это до того, как череду заводить: у
+настройки конвейера, а не у страницы заявки, где отсутствие прогона выглядит так же, как его
+ожидание.
+
+```bash
+# порядок череды целиком — снизу вверх
+gh pr list --state open --json number,headRefName,baseRefName \
+    --jq '.[] | "\(.number)\t\(.headRefName)\tна \(.baseRefName)"'
+```
+
+## Чего в череде не делают
+
+- **Историю нижней ветки не переписывают.** Ни `rebase`, ни силовая отправка: вершина верхней
+  становится достижимой из её основания, и хостинг закрывает заявку верхней как слитую — при том
+  что в главной её правок нет. Отставшая нижняя чинится вливанием главной в неё и дальше вверх.
+- **Череду не вливают из середины.** Влитая не по порядку тащит за собой всё, что под ней, — и
+  разбор той работы уже не состоится.
+- **Готовые ветки не копят.** Череда не отменяет того, что единица работы — влитая заявка: она
+  лишь делает безопасной ту длину, которая всё же накопилась.
+
 ## Единица работы — влитая заявка, а не открытая
 
 Открытый черновик работой не является: кнопка слияния у него заблокирована, в главной ветке его
@@ -65,6 +123,21 @@ docs/archive/README.md merge=union
 Сложение ставится только на указатели, где правка всегда добавляющая. На текст, который
 переписывают, оно оставит в файле обе редакции.
 
+**Сложение сторон метку сливаемости не снимает, и вливать главную по ней нельзя.** Хостинг
+считает сливаемость своим приёмом и настроек слияния не читает: ветка, тронувшая сложенный
+указатель, помечается конфликтующей всё равно. Спрошенная у него стопка отвечает «конфликтует»
+целиком, и вливание по этому ответу — то же вливание во все ветки, что и без сложения: раздел
+ниже велит вливать главную по факту конфликта, а факт этот хостинг называет про каждую ветку
+стопки. Пятнадцать заявок разом простояли так за один заход. Проверяется одной командой: то же
+слияние без драйвера даёт конфликтный маркер, с драйвером идёт чисто — значит метку держит
+указатель, а не правка.
+
+**Указатель, куда дописывает каждая ветка стопки, из стопки убирается, а не складывается.**
+Сложение — починка проявления: конфликта нет, метка есть, вливать по-прежнему приходится.
+Спрашивается это до заведения веток: отвечает ли указатель на вопрос, которого не закрывает
+обход каталога. Не отвечает — он снимается, и площадь пересечения стопки падает до настоящих
+общих файлов.
+
 ## Порядок вливания задаётся заранее и называется владельцу
 
 Порядок считается до открытия заявок — по тому, кто какие файлы правит:
@@ -79,6 +152,25 @@ done | sort | uniq -c | sort -rn | head
 конфликт там, где подряд его бы не было. Порядок называется владельцу в теле заявки — кнопки
 нажимает он, а о родстве веток не знает.
 
+## Волна веток проверяется пробным слиянием
+
+Ветка, лежащая невлитой рядом с соседками, зелена сама по себе: линт, тесты, сборки и сверки
+она проходит одна. Сталкивается она с ними тем, чего на отдельной ветке не видит ни одна
+проверка — тот же следующий свободный номер сценария, тот же заведённый новым файл, та же
+правленная строка отметки. После слияния первые два чинятся уже в главной и стоят отдельной
+работы.
+
+```bash
+git fetch origin
+git checkout -b probe-merge origin/main
+for b in <ветка-1> <ветка-2> <ветка-3>; do git merge --no-edit "origin/$b" || break; done
+npm run check:all
+git checkout - && git branch -D probe-merge
+```
+
+Ветка пробы удаляется, а находки и порядок слияния записываются туда, где живёт замысел линии
+работ: пробное слияние отвечает на «что столкнётся», а не заменяет собой отдачу.
+
 ## Частые промахи
 
 - Открыты все заявки разом, потому что ветки были готовы. Готовность ветки признаком того, что

package/assets/patterns/lib-layers-move.md

@@ -77,6 +77,10 @@ grep -rn "@<область>/<семья>/<домен>" libs/ apps/ | sed 's/:.*/
     npx nx run-many -t lint --projects=<список по изменённым файлам>
     ```
 
+    Этот прогон — быстрый, по горячим следам переноса, и набором перед пушем он не бывает:
+    набор, собранный по изменённым файлам, пропускает то, до чего правка дошла связями. Перед
+    пушем идёт тот же набор, что гоняет конвейер, и теми же командами.
+
 ## Проверить
 
 ```bash

package/assets/patterns/spec-driven-domain.md

@@ -33,6 +33,11 @@ docs/specs/<домен>/
 та же связь сценариев с тестами. Домен, у которого половина поддоменов описана, а половина
 заведена пустыми каталогами, зелёным не бывает.
 
+Работа, задевшая домен и его поддомен, пишет две договорённости, а не одну. Префикс сценариев у
+поддомена свой, а второго префикса одному спеку сверка не даёт: сценарии такой работы
+разъезжаются по двум нумерациям — по одной на каждый спек, в который вольются. Замысел называет
+обе, и вливаются они порознь, каждая в свой спек.
+
 ## Обязательные разделы
 
 `## Зачем` · `## Терминология` с подразделом `### Как это называется в интерфейсе` ·
@@ -49,6 +54,18 @@ docs/specs/<домен>/
 такой спек по строкам бесполезно, потому что делится в нём не описание домена, а ненаписанное
 правило.
 
+**Заголовок записи раздела решений датой не называется.** Дата говорит, когда решение приняли, а
+раздел отвечает на «почему так, а не иначе»: по дате решение не отобрать и не найти, зато
+названная ею запись читается описанием прошлого и остаётся в спеке навсегда. Запись начинается с
+самого решения.
+
+**Утверждение, стоящее в другом разделе того же спека, вторым пунктом правил не заводится.**
+Устройство записи живёт в разделе данных, порядок вызовов — в разделе контракта, причина
+существования домена — в разделе «Зачем»: все три говорят о том же, о чём говорило бы правило.
+Второй экземпляр расходится с первым молча, и заметить это нечем — сверка знает пункт правила
+против якоря, а два утверждения об одном не сравнивает никто. Решение при этом из раздела решений
+уезжает целиком: место, где требование живёт, найдено.
+
 Шапка несёт статус, дату ревизии, префикс сценариев, зависимости от других доменов, строку
 `**Законы:**` — законы, которые домен применяет, — и строку `**Процедуры:**` — корни либ, чьи
 процедуры домен обслуживает.
@@ -79,7 +96,7 @@ docs/specs/<домен>/
 ```
 
 Правило, которому места в коде не нашлось, — намерение: ему место в «Открытых вопросах» как
-`Q-N`, а не формальный якорь.
+`Q-<буква закона>-<номер>`, а не формальный якорь.
 
 ## Сценарий
 
@@ -95,11 +112,17 @@ docs/specs/<домен>/
 `Не покрыто: <причина>`, сценарий с неполным тестом — `Покрытие: частичное — <чего не
 хватает>`.
 
+Сценарий, который проверить нечем в принципе, не заводится вовсе. Пометка о непокрытом говорит
+«теста ещё нет» и обещает, что он появится; там, где проверки не существует, обещания нет, а
+помеченный сценарий висит в наборе вечно, читается как долг и заставляет каждого следующего
+заново выяснять, не пора ли его закрыть. Правило, ради которого сценарий хотели завести,
+остаётся правилом: его держат строка в компаньоне и запись в истории изменений, и этого довольно.
+
 Номер в идентификаторе живёт так:
 
 | Что случилось           | Что делается с номером                                                                               |
 | ----------------------- | ---------------------------------------------------------------------------------------------------- |
-| сценарий добавили       | берётся следующий свободный — наибольший выданный в домене плюс один, а не дырка в середине          |
+| сценарий добавили       | берётся следующий свободный — наибольший выданный **во всех ветках** плюс один, а не дырка в середине |
 | обещание изменили       | номер тот же, заголовок теста правится тем же коммитом                                               |
 | сценарий удалили        | номер остаётся пустым и новому сценарию не отдаётся; тест удаляется вместе со сценарием              |
 | номера захотелось сжать | не пересчитываются: связь с тестами держит только номер, а прогон остаётся зелёным при обеих правках |
@@ -107,6 +130,15 @@ docs/specs/<домен>/
 Номер записывается так же, как у соседей в этом же файле: сверка ищет его шаблоном, и номер,
 записанный иначе, не совпадёт ни в спеке, ни в заголовке теста.
 
+**Свободный номер ищется во всех ветках, а не в одной главной.** Соседняя работа держит свои
+номера на диске и в главную ещё не въехала: шесть номеров так раздали дважды, и двигаться
+пришлось той работе, чья договорённость не влита. Номер — единственное, чем сценарий связан с
+тестом, и отданный второй раз он оставляет старую ссылку правильной на вид и ведущей не туда.
+
+Спрашивается это командой дерева, если дерево её завело: она читает заголовки сценариев во всех
+ветках — своих и удалённых — и печатает первый свободный за наибольшим занятым. Имя команды
+называет компаньон правила.
+
 ## Порядок работы
 
 1. Задача заводится сценариями: что станет верно, когда работа закончится.
@@ -115,6 +147,10 @@ docs/specs/<домен>/
 4. `npm run check:specs` — до пуша.
 5. Приёмка идёт по сценариям, а не по пересказу правки.
 
+Правило, обещающее человеку видимый результат, подтверждается на работающем приложении, а не
+выводом из графа вызовов. Чтением подтверждаются заголовки, связь с привязками и форма данных;
+правило, которое подтвердить не на чем, уезжает открытым вопросом и утверждением не пишется.
+
 ## Частые промахи
 
 - Выросший домен делят на новые домены, а не на поддомены: новый домен приходится заводить в
@@ -139,10 +175,19 @@ docs/specs/<домен>/
 - Закон, названный в тексте, но забытый в строке `**Законы:**`: по закону тогда не узнать,
   какие домены на нём стоят.
 - Правка `.proto` без спеков задетых доменов: `docs-guard` отбивает такой коммит.
+- **Правило, выведенное из графа вызовов, ошибается беззвучно.** Читается оно так же уверенно,
+  как замеренное, и сверка привязки его пропускает — символ на месте, просто описывает он не то.
+  Два правила одного спека оказались перевёрнутыми: связь шла не между хранилищами, а через
+  слушающий их компонент, — и оба чуть не стали задачей на дефект, которого нет.
+
 - **Выросший домен делится на поддомены, а не на новые домены.** Новый домен пришлось бы
   заводить в указателе, сверять с кодом отдельно и объяснять, чем он соседу не поддомен;
   поддомен остаётся в своём домене и наследует его контракт. Соседний домен заводится только
   тогда, когда предмет живёт своей сущностью.
+- **Наибольший выданный номер ищется по всему домену командой, а не глазами по хвосту файла.**
+  Номера в файле сценариев идут не по порядку: правки вставляли их к соседям по смыслу, и
+  последняя строка максимума не показывает. Шесть новых номеров из одиннадцати легли на занятые
+  — поймала это сверка спеков, а не чтение, и переписывать пришлось заодно заголовки тестов.
 - **Границу между доменами проводит владелец, а не автор очередной правки.** Автор видит свою
   правку, а не то, чем предмет обрастёт: домен, заведённый по ходу дела, через месяц оказывается
   половиной соседнего, и разводить их приходится вместе с номерами сценариев.

package/assets/patterns/spec-driven-rule.md

@@ -33,7 +33,10 @@ description: Паттерн правила spec-driven. Брать при зав
 вопрос есть, и стираются вместе с последним закрытым: закрытый вопрос из закона убирается, а
 не превращается в пустой раздел.
 
-Ни истории правок, ни доводов о том, почему когда-то выбрали так, в законе нет. Историю
+Даты в законе тоже нет: у одного закона из семнадцати она стояла, у остальных не появлялась
+никогда, а прочитанная как срок годности — старит верный текст, которого никто не трогал, потому
+что трогать было нечего. Ни истории правок, ни доводов о том, почему когда-то выбрали так, в
+законе нет. Историю
 держит система контроля версий, а довод с отвергнутой альтернативой — свойство работы, а не
 продукта: ему место в «Ловушках» правила под этим законом, где и путям к файлам можно.
 Утверждение, которое нельзя написать как «верно всегда», статьёй не становится вовсе.
@@ -43,8 +46,6 @@ description: Паттерн правила spec-driven. Брать при зав
 
 Как правка доезжает до работающего приложения. …
 
-**Ревизия:** 2026-08-05
-
 ## Статьи
 
 - **Выкатывается образ того коммита, который выкатывают.** Умолчание «последний» отстаёт от
@@ -74,6 +75,17 @@ description: Правило под «Закон о поставке». Брат
 ---
 ```
 
+Под шапкой стоит строка требования к соседним ресурсам — тем, без которых статьи правила не
+исполняются:
+
+```markdown
+**Требует:** `hooks/<гард>.sh`, `checks/<проверка>.mjs`
+```
+
+Ресурсы называются именами пакета, а не путями дерева. Строки нет — правило не требует ничего;
+пустой она не бывает. Выводить требование из фразы в тексте нельзя: разложено у потребителя не
+всё, и текст, сказавший «правку отбивает гард», врёт в дереве, где гарда нет.
+
 Разделы: `## Как это называется здесь` · `## Где это лежит` · `## Как закон применяется
 здесь` · `## Чего из закона здесь нет` · `## Паттерны` · `## Ловушки`.
 
@@ -87,7 +99,7 @@ description: Правило под «Закон о поставке». Брат
 ```
 
 Утверждение, которому места в коде не нашлось, в этот раздел не ставится: оно уходит прозой в
-«Ловушки» или вопросом `Q-N` в закон.
+«Ловушки» или вопросом `Q-<буква закона>-<номер>` в закон.
 
 ## Паттерн
 

package/assets/patterns/spec-driven-sweep.md

@@ -0,0 +1,57 @@
+---
+name: spec-driven-sweep
+kind: pattern
+rule: spec-driven
+description: Паттерн правила spec-driven. Брать при сплошном разборе привязки домена — пять проходов, три из которых делает машина, разбор срабатываний чтением и доля ложных по слоям. Не брать для заведения спека домена — это паттерн spec-driven-domain.
+---
+
+# Сплошной разбор привязки домена
+
+Паттерн правила `spec-driven`. Что при этом должно быть верно — закон о документации проекта.
+
+## Когда брать
+
+- Привязка домена разбирается целиком: каждое утверждение против кода, на который оно указывает.
+- Тексты дерева сверяются с деревом задачей, а не по ходу другой работы.
+
+## Проходов пять, и порядок у них один
+
+Три первых делает машина по всему домену разом, два последних — чтение. Порядок не
+переставляется: чтение идёт по строкам, которые машина уже отобрала, иначе читается весь домен.
+
+1. **Мёртвый адрес.** Названного файла нет в дереве, или символа нет нигде. Даёт ноль на домене,
+   который уже разбирали, и целую пачку на том, откуда недавно уезжал код.
+2. **Якорь, живущий только в пояснении.** Символ встречается в дереве лишь в комментариях.
+   Проверка привязки комментарий засчитывает наравне с кодом, поэтому такому якорю она зелёная, а
+   места исполнения за ним нет.
+3. **Символ не объявлен в названном файле.** Файл его импортирует и зовёт, а объявление лежит в
+   другом месте. Самый урожайный проход и самый шумный.
+4. **Обещание против кода.** Читается код по адресу: делает ли он то, что утверждает правило.
+   Машине этот проход не даётся вовсе — расхождение здесь обычно в условии и в порядке шагов.
+5. **Число, код отказа и ключ словаря — поимённо.** Каждое число из текста ищется в дереве,
+   каждый названный код отказа — в месте, где он бросается, каждый ключ словаря — во всех
+   локалях. Расхождение тут выглядит опечаткой и живёт годами.
+
+## Срабатывание — очередь на чтение, а не список дефектов
+
+Проход выдаёт строки, находкой становится подтверждённая чтением. Разница не словесная: строки
+третьего прохода на треть законны у любого домена, и записанные находками они превращают разбор в
+правку верного кода. В ход работы идут оба числа — сколько строк дал проход и сколько из них
+оказались расхождениями.
+
+## Доля ложных зависит от слоя
+
+Там, где правило живёт в процедуре, место исполнения одно и оно публично: срабатывание третьего
+прохода чаще оказывается расхождением — из четырнадцати строк шесть. Там, где правило живёт в
+компоненте или службе, местом исполнения законно бывает приватное поле или приватный метод: из
+тридцати шести строк расхождений не оказалось ни одной. Поэтому число находок прошлого домена на
+следующий не переносится — переносится только сам порядок проходов.
+
+## Частые промахи
+
+- **Урожайность прохода обещана фактом.** «Проход даст столько-то» — оценка, и по чужому слою она
+  промахивается целиком. Разбор просьбы называет проходы, а не число находок.
+- **Проход, давший ноль, не записан.** Следующий заход гоняет его заново по тому же домену. Ноль
+  — такой же результат, и он пишется вместе с остальными.
+- **Счёт сторон принят за разбор.** Зелёная проверка привязки говорит, что у каждого утверждения
+  есть строка, а куда эта строка ведёт — не говорит ничего.

package/assets/patterns/status-report-table.github.md

@@ -57,7 +57,7 @@ gh api repos/:owner/:repo/issues/<номер> --jq '{t:.title,s:.state,labels:[.
 имя команды в оболочке бывает занято чужим псевдонимом, и тогда вызов уходит в интерактивный
 вход вместо ответа.
 
-## Ловушки
+## Частые промахи
 
 - **Задача на борде читается запросом, а не подкомандой просмотра.** Подкоманда тянет за собой
   доски старого образца, хостинг отвечает отказом о них, и вызов краснеет целиком, ничего не

package/assets/patterns/task-flow-archive.md

@@ -46,7 +46,17 @@ description: Паттерн правила task-flow. Брать, когда т
 | `grill.md`      | в `docs/archive/` — ответы владельца невосстановимы, и это единственная запись о том, почему задача поставлена так |
 | `progress.md`   | в `docs/archive/`, если в нём есть решения по ходу с причинами; иначе удаляется                                    |
 | `plan.md`       | удаляется — после выкатки на его вопрос отвечает код, а на «как работает» отвечает спек домена                     |
-| находки разбора | переезжают к замыслу эпика — их читает владелец, когда эпик кончится; работа вне эпика показывает их сразу         |
+| находки разбора | пишутся сразу рядом с замыслом эпика — не переезжают отсюда; работа вне эпика показывает их владельцу тем же ходом |
+
+Находки в папке задачи не живут вовсе. Разбор идёт фоном, и когда он кончится, не знает никто:
+папка к этой минуте разобрана, а ветка бывает уже влита и снята. Оба срока назначает не
+исполнитель, поэтому переезд «из папки к замыслу эпика» держался бы на совпадении, которого может
+и не случиться. Тем же местом пользуется находка, замеченная не разбором, а по ходу работы.
+
+Находки, вернувшиеся после того, как ветка ушла, едут веткой следующей задачи: пуш в снятую ветку
+её не обновляет, а заводит заново, и коммит остаётся вне главной. Следующая задача к этой минуте
+уже взята — её веткой уборка за предыдущей и едет, тем же порядком, каким разбирают чужую папку
+задачи. Эпик кончился и следующей задачи нет — находки уезжают своей задачей.
 
 Уезжающее складывается одним файлом с говорящим именем, а не папкой из трёх:
 
@@ -117,18 +127,50 @@ npm run check:docs    # пути, названные в текстах, суще
 3. **Вернувшиеся находки принимают одним ходом** — записать и вернуться к прежнему. Разбор,
    отложенный «до удобного момента», не случается вовсе: заход кончается раньше.
 
-**Следующее движение:** пока роль разбирает, тот же ход занят следующей задачей; вернувшиеся
-находки принимаются одним ходом — записать и продолжить прежнее.
+### Записи груза переводятся в «готово» тем же ходом
+
+Работа, начатая с приехавшего груза, кончается здесь, а не на разборе папки: до слияния правки в
+дереве нет, и отметка утверждала бы то, чего в главной ветке ещё не лежит. Это единственное
+состояние, где слияние уже случилось, а ход о задаче ещё идёт.
+
+Ключи берутся из описания прошлого — папки задачи на диске к этой минуте нет, — и подставляются
+полными, как их печатает чтение приёма:
+
+```bash
+npm run cargo:mark -- --state fixed \
+    --proposal <полный ключ> --proposal <полный ключ> \
+    --fix '<чем исправлено: статья правила, гард, проверка, правка кода>'
+```
+
+Приём починки один на вызов, поэтому записи едут пачками по тому, чем закрыты, а не всей задачей
+разом. Ответ читается: «переведено 0» означает, что этот разбор не двинул ничего.
+
+**Следующее движение:** пока роль разбирает, тот же ход занят следующей задачей; записи груза
+переводятся в «готово» этим же ходом, вернувшиеся находки принимаются одним ходом — записать и
+продолжить прежнее, а владельцу о них говорится, когда кончился эпик.
 
-## Состояние `влито`: находки разбора ложатся в папку задачи и ждут владельца
+## Находки разбора ложатся к замыслу эпика и ждут владельца
 
-Ответ роли живёт в переписке и умирает вместе с ней, поэтому он сразу ложится на диск — в папку
-задачи, файлом рядом с ходом работы. Пишет его исполнитель: роль файлов не пишет.
+Ответ роли живёт в переписке и умирает вместе с ней, поэтому он сразу ложится на диск. Пишет
+его исполнитель: роль файлов не пишет.
 
-Папка задачи умирает со слиянием, а находки должны пережить весь эпик — владелец читает их
-разом, когда эпик кончился. Поэтому при разборе папки файл находок не удаляется вместе
-с остальным, а **переезжает к замыслу эпика**: там его найдут и после того, как ветка въехала.
-Работа вне эпика показывает находки владельцу сразу, тем же ходом.
+**Пишутся находки сразу в файл рядом с замыслом эпика, а не в папку задачи.** Разбор идёт
+фоном, и когда он кончится, не знает никто; папка задачи к этому времени бывает уже разобрана,
+а ветка влита и снята. Оба срока назначает не исполнитель, поэтому переезд «из папки к замыслу
+эпика» держится на совпадении, которого может и не случиться. Тем же местом пользуется находка,
+замеченная не разбором, а по ходу работы. Работа вне эпика показывает находки владельцу тем же
+ходом.
+
+**Находки, вернувшиеся после того, как ветка ушла, едут веткой следующей задачи.** Пуш в снятую
+ветку её не обновляет, а заводит заново: коммит остаётся вне главной ветки и пропадает вместе
+с ней. Следующая задача к этому времени уже взята — её веткой уборка за предыдущей и едет.
+Эпик кончился и следующей задачи нет — находки уезжают своей задачей.
+
+**Накопительный файл находок делится до дописи, а не после.** Длина смотрится одной командой
+перед первой написанной строкой: раздел задачи занимает десятки строк, и предел длины документа
+он переходит молча. Гейт пуша показывает превышение, когда допись уже закоммичена, — тогда
+деление идёт задним числом, вместе с правкой ссылок на файл. Не влезает — заводится следующая
+часть, и раздел пишется сразу в неё.
 
 **Наружу без слова владельца уезжает только сводка наблюдений.** Она говорит, чем пользовались
 и чем не пользовались ни разу, — это факт, и мнением он не станет. Предложение — другое дело:
@@ -155,18 +197,18 @@ npm run check:docs    # пути, названные в текстах, суще
 котором владелец сказал вслух, уходит наружу в тот же ход: написанное и не отправленное лежит в
 дереве неотличимо от отправленного.
 
-**Следующее движение:** записанные находки работу не держат — следующая задача уже идёт, а
-владельцу о них говорится, когда кончился эпик.
-
-## Ловушки
+## Частые промахи
 
 - **Папку разбирают до открытия заявки — потом о ней уже никто не вспомнит.** Сверка очереди
   считает задачу закрытой по слиянию: после него за папку никто не отвечает — работа перешла к
   следующей задаче, и находка достанется чужому заходу. Держит это гард поставки:
   открытие заявки отбивается, пока папка лежит в ветке.
 - **Разбор папки идёт последним коммитом, после того как гейт пуша прошёл целиком.** Порядок
-  один: мерж главной ветки, все линтеры и проверки зелёные, вливание договорённости, приведение
-  текстов домена, разбор папки — и только потом заявка.
+  один: мерж главной ветки, вливание договорённости, приведение текстов домена, все линтеры и
+  проверки зелёные, разбор папки — и только потом заявка. Дешёвый шаг стоит раньше дорогого:
+  заход, потративший окно на прогон, упирался в порог заполнения на четырёх строках привязки, и
+  дописать их было уже нечем. Второй довод сильнее: прогон, стоящий после вливания, проверяет и
+  само вливание — иначе он смотрит то состояние дерева, которое в главную ветку не поедет.
 - **После разбора замысла на диске нет, и собирать папку заново не надо.** Правку по замечаниям
   разбора и починку красного прогона гард хода работы пропускает по признаку из истории ветки:
   папка, снятая её коммитом, и есть признак отданной работы. Собранная заново папка вернула бы