@rt-tools/agent-kit 0.8.0 → 0.8.2

package/assets/hooks/reuse-first-guard.sh

@@ -38,14 +38,46 @@ command -v jq >/dev/null 2>&1 || exit 0
 command -v perl >/dev/null 2>&1 || exit 0
 
 tool="$(printf '%s' "$input" | jq -r '.tool_name // empty' 2>/dev/null)"
+shell_cmd=""
 case "$tool" in
     # Инструмент среды заводит файл теми же двумя данными, только называет их иначе — без этой
     # ветки файл заводился мимо всех проверок.
     Edit | Write | MultiEdit | mcp__webstorm__create_new_file) ;;
+    # Команда оболочки, которая пишет файл, — та же правка. Без этой ветки гард обходится
+    # сменой не инструмента, а способа записи; текстом правки тогда служит сама команда, и
+    # заведённое ею в heredoc читается наравне с телом правки. Разбор —
+    # `2026-08-15-guard-denied-shell-wrote-anyway.md`.
+    Bash)
+        shell_cmd="$(printf '%s' "$input" | jq -r '.tool_input.command // empty' 2>/dev/null)"
+        [ -z "$shell_cmd" ] && exit 0
+        ;;
     *) exit 0 ;;
 esac
 
-path="$(printf '%s' "$input" | jq -r '.tool_input.file_path // .tool_input.pathInProject // empty' 2>/dev/null)"
+# Профиль дерева: сперва умолчание пакета, поверх него — надстройка проекта, если она есть.
+# Читается до разбора пути: пути из команды оболочки вынимает как раз профиль.
+rt_hooks_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+for profile in "$rt_hooks_dir/../rt-kit/defaults/project.sh" "$rt_hooks_dir/../defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/project.sh"; do
+    # shellcheck disable=SC1090
+    [ -f "$profile" ] && . "$profile" 2>/dev/null
+done
+
+if [ -n "$shell_cmd" ]; then
+    command -v rt_shell_writes >/dev/null 2>&1 && command -v rt_shell_paths >/dev/null 2>&1 || exit 0
+    rt_shell_writes "$shell_cmd" || exit 0
+    # Из команды берётся первый путь, чьё расширение гарду интересно: остальные ему безразличны.
+    path=""
+    while IFS= read -r candidate; do
+        case "$candidate" in
+            *.html | *.scss | *.ts) path="$candidate"; break ;;
+        esac
+    done <<EOF
+$(rt_shell_paths "$shell_cmd")
+EOF
+    [ -z "$path" ] && exit 0
+else
+    path="$(printf '%s' "$input" | jq -r '.tool_input.file_path // .tool_input.pathInProject // empty' 2>/dev/null)"
+fi
 # Путь от корня дерева приводится к абсолютному один раз, чтобы образцы не двоились.
 case "$path" in
     /*) ;;
@@ -56,13 +88,6 @@ case "$path" in
     *) exit 0 ;;
 esac
 
-# Профиль дерева: сперва умолчание пакета, поверх него — надстройка проекта, если она есть.
-rt_hooks_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-for profile in "$rt_hooks_dir/../rt-kit/defaults/project.sh" "$rt_hooks_dir/../defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/project.sh"; do
-    # shellcheck disable=SC1090
-    [ -f "$profile" ] && . "$profile" 2>/dev/null
-done
-
 # Слово о нехватке функции профиля: хук, вышедший молча, неотличим от работающего. Файл может
 # быть не разложен — тогда остаётся прежнее поведение, молчаливое.
 # shellcheck disable=SC1090
@@ -82,11 +107,16 @@ if [ -n "${RT_REUSE_SKIP_RE:-}" ] && printf '%s' "$path" | grep -qE "$RT_REUSE_S
     exit 0
 fi
 
-# Только новый текст: строка, уже лежавшая в файле, этой правкой не заводилась.
-added="$(printf '%s' "$input" | jq -r '
-    [ .tool_input.content?, .tool_input.text?, .tool_input.new_string?, (.tool_input.edits[]?.new_string) ]
-    | map(select(. != null)) | join("\n")
-' 2>/dev/null)"
+# Только новый текст: строка, уже лежавшая в файле, этой правкой не заводилась. У команды
+# оболочки таким текстом служит она сама: что она кладёт в файл, лежит в ней же.
+if [ -n "$shell_cmd" ]; then
+    added="$shell_cmd"
+else
+    added="$(printf '%s' "$input" | jq -r '
+        [ .tool_input.content?, .tool_input.text?, .tool_input.new_string?, (.tool_input.edits[]?.new_string) ]
+        | map(select(. != null)) | join("\n")
+    ' 2>/dev/null)"
+fi
 [ -z "$added" ] && exit 0
 
 # Явный отказ от правила: готового такого нет, автор это осознал и пометил. Считается по
@@ -138,11 +168,19 @@ has_re() {
 rt_checks_json="${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/checks.json"
 rt_bundles=''
 rt_own_signals=''
+rt_backend_roots=''
 if [ -f "$rt_checks_json" ]; then
     rt_bundles="$(jq -r '.reuse.bundles[]? // empty' "$rt_checks_json" 2>/dev/null | tr '\n' ' ')"
     own="$(jq -r '.reuse.signals // empty' "$rt_checks_json" 2>/dev/null)"
     [ -n "$own" ] && rt_own_signals="${CLAUDE_PROJECT_DIR:-.}/$own"
+    # Тем же ключом, каким их читает сплошная проверка: второе объявление тех же корней
+    # разошлось бы с первым молча.
+    rt_backend_roots="$(jq -r '.backendRoots[]? // empty' "$rt_checks_json" 2>/dev/null | tr '\n' ' ')"
 fi
+
+# Путь от корня дерева: образец в признаке пишет дерево, и писать его от корня машины оно не
+# может. Абсолютный путь нужен только для чтения файла с диска.
+rel_path="${path#"${CLAUDE_PROJECT_DIR:-.}"/}"
 rt_signals_dir="${CLAUDE_PROJECT_DIR:-.}/${RT_REUSE_SIGNALS_DIR:-tools/signals}"
 
 # Признаки объявленных наборов: те же файлы читает сплошная проверка. Ключ признака совпал с
@@ -172,9 +210,25 @@ while IFS= read -r signal; do
         '') ;;
         *) case "$path" in *"$ext") ;; *) continue ;; esac ;;
     esac
+    # Пропуск корней бэкенда: признак, объявленный с ним, на бэкенде не действует вовсе — там
+    # принят другой способ, и базового класса, которого признак требует, у бэкенда нет. Поле
+    # читает и сплошная проверка; читать его одному из двоих значит отбивать гардом ту самую
+    # правку, которую проверка пропускает, — а провести её больше нечем: маркер отступления
+    # объявляет обход готового, а обхода тут не было.
+    if [ "$(field "$signal" '.skipBackendRoots')" = 'true' ] && [ -n "$rt_backend_roots" ]; then
+        skip_backend=''
+        for backend_root in $rt_backend_roots; do
+            case "$rel_path" in "$backend_root"*) skip_backend=1 ;; esac
+        done
+        [ -n "$skip_backend" ] && continue
+    fi
+
+    # Образец имени сверяется с путём от корня дерева, а не с именем файла: слои, которые
+    # признак и разделяет, зовут свои файлы одинаково, и по имени они неразличимы. Сплошная
+    # проверка сверяет с путём — расходиться им нельзя.
     only_named="$(field "$signal" '.onlyNamed')"
     if [ -n "$only_named" ]; then
-        printf '%s' "${path##*/}" | grep -qE "$only_named" || continue
+        printf '%s' "$rel_path" | grep -qE "$only_named" || continue
     fi
 
     case "$(field "$signal" '.scope')" in

package/assets/hooks/skill-gate-layers.sh

@@ -124,7 +124,7 @@ esac
 
 # --- слой по пути: ведение работы -------------------------------------------------------------
 #
-# Папка задачи, договорённость о продукте до кода и линия работ — первые файлы, которые
+# Папка задачи, договорённость о продукте до кода и замысел эпика — первые файлы, которые
 # заводятся в работе. Требование ловит на них того, кто пошёл мимо порядка: «пришла новая
 # задача» инструментом не является, и поймать это больше нечем.
 case "$target" in

package/assets/hooks/skill-gate.sh

@@ -90,6 +90,32 @@ case "$tool" in
         fi
         req="$(skill_for bash "$target" "" 2>/dev/null)"
         kind="command"
+        # Команда оболочки, которая пишет файл, — та же правка, и правило ей нужно то же.
+        # Без этого яруса гейт обходится сменой не инструмента, а способа записи: отбитая
+        # правка легла командой дважды за один заход. Разбор —
+        # `2026-08-15-guard-denied-shell-wrote-anyway.md`.
+        for profile in "$rt_hooks_dir/../rt-kit/defaults/project.sh" "$rt_hooks_dir/../defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/project.sh"; do
+            # shellcheck disable=SC1090
+            [ -f "$profile" ] && . "$profile" 2>/dev/null
+        done
+        if command -v rt_shell_writes >/dev/null 2>&1 && command -v rt_shell_paths >/dev/null 2>&1 \
+            && rt_shell_writes "$target"; then
+            while IFS= read -r written_path; do
+                [ -z "$written_path" ] && continue
+                case "$written_path" in
+                    /*) ;;
+                    *) written_path="${CLAUDE_PROJECT_DIR:-.}/$written_path" ;;
+                esac
+                case "$written_path" in
+                    "${CLAUDE_PROJECT_DIR:-.}"/*) ;;
+                    *) continue ;;
+                esac
+                more="$(skill_for edit "$written_path" "" 2>/dev/null)"
+                [ -n "$more" ] && req="$req $more"
+            done <<EOF
+$(rt_shell_paths "$target")
+EOF
+        fi
         ;;
     mcp__claude-in-chrome__*)
         req="$(skill_for browser "$tool" "" 2>/dev/null)"

package/assets/hooks/task-flow-guard.sh

@@ -5,7 +5,7 @@
 #
 # Работа идёт много заходов, и между ними исполнитель не помнит ничего. Замысел, лежащий на
 # диске, — единственное, что переживает перерыв: изменения к этому моменту бывают не
-# закоммичены, отчёт не открыт, а очередь работ показывает задачу начатой и молчит о том, что
+# закоммичены, PR не открыт, а очередь работ показывает задачу начатой и молчит о том, что
 # внутри неё сделано.
 #
 # Гард требует три вещи и ровно их: папку задачи по имени ветки, замысел в ней и названную в
@@ -24,22 +24,8 @@ input="$(cat 2>/dev/null)"
 [ -z "$input" ] && exit 0
 command -v jq >/dev/null 2>&1 || exit 0
 
-tool="$(printf '%s' "$input" | jq -r '.tool_name // empty' 2>/dev/null)"
-case "$tool" in
-    # Инструмент редактора заводит файл теми же двумя данными, только называет их иначе —
-    # без этой ветки правка шла бы мимо гарда сменой инструмента.
-    Edit | Write | MultiEdit | mcp__webstorm__create_new_file) ;;
-    *) exit 0 ;;
-esac
-
-path="$(printf '%s' "$input" | jq -r '.tool_input.file_path // .tool_input.pathInProject // empty' 2>/dev/null)"
-[ -z "$path" ] && exit 0
-case "$path" in
-    /*) ;;
-    ?*) path="${CLAUDE_PROJECT_DIR:-.}/$path" ;;
-esac
-
 # Профиль дерева: сперва умолчание пакета, поверх него — надстройка проекта, если она есть.
+# Читается до разбора пути: пути из команды оболочки вынимает как раз профиль.
 rt_hooks_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 for profile in "$rt_hooks_dir/../rt-kit/defaults/project.sh" "$rt_hooks_dir/../defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/defaults/project.sh" "${CLAUDE_PROJECT_DIR:-.}/.claude/rt-kit/project.sh"; do
     # shellcheck disable=SC1090
@@ -52,12 +38,52 @@ done
 [ -f "$rt_hooks_dir/profile-check.sh" ] && . "$rt_hooks_dir/profile-check.sh"
 command -v rt_needs >/dev/null 2>&1 || rt_needs() { command -v "$1" >/dev/null 2>&1; }
 
+tool="$(printf '%s' "$input" | jq -r '.tool_name // empty' 2>/dev/null)"
+candidates=""
+case "$tool" in
+    # Инструмент редактора заводит файл теми же двумя данными, только называет их иначе —
+    # без этой ветки правка шла бы мимо гарда сменой инструмента.
+    Edit | Write | MultiEdit | mcp__webstorm__create_new_file)
+        candidates="$(printf '%s' "$input" | jq -r '.tool_input.file_path // .tool_input.pathInProject // empty' 2>/dev/null)"
+        ;;
+    # Второй ярус: та же правка, положенная командой оболочки. Без него отказ гарда обходится
+    # сменой не инструмента, а способа записи — перенаправлением, `sed -i`, интерпретатором с
+    # heredoc. Разбор — `2026-08-15-guard-denied-shell-wrote-anyway.md`.
+    Bash)
+        cmd="$(printf '%s' "$input" | jq -r '.tool_input.command // empty' 2>/dev/null)"
+        [ -z "$cmd" ] && exit 0
+        rt_needs rt_shell_writes task-flow-guard || exit 0
+        rt_needs rt_shell_paths task-flow-guard || exit 0
+        rt_shell_writes "$cmd" || exit 0
+        candidates="$(rt_shell_paths "$cmd")"
+        ;;
+    *) exit 0 ;;
+esac
+[ -z "$candidates" ] && exit 0
+
 # Признак «правка меняет поведение» — путь, а не оценка на глаз: оценку назначает тот, кому
 # она мешает, и порог плывёт. Где живёт код приложения, знает профиль: правила, тексты, обвязка
 # и зависимости под требование не попадают — иначе разбор задачи нельзя было бы вести до
 # заведения ветки.
 rt_needs rt_is_app_code task-flow-guard || exit 0
-rt_is_app_code "$path" || exit 0
+
+# Судится каждый названный путь: команда пишет столько файлов, сколько в ней стоит, и одного
+# под требованием довольно, чтобы отбить её целиком.
+path=""
+while IFS= read -r candidate; do
+    [ -z "$candidate" ] && continue
+    case "$candidate" in
+        /*) ;;
+        *) candidate="${CLAUDE_PROJECT_DIR:-.}/$candidate" ;;
+    esac
+    if rt_is_app_code "$candidate"; then
+        path="$candidate"
+        break
+    fi
+done <<EOF
+$candidates
+EOF
+[ -z "$path" ] && exit 0
 
 # Каталог папок задач: у дерева он свой, но имя обычно общее.
 tasks_dir="${RT_TASKS_DIR:-docs/tasks}"
@@ -113,7 +139,7 @@ fi
 
 # Договорённость, влитая в спек домена, с диска уходит — так и задумано: в главной ветке
 # директории «предложено» быть не должно. Но замысел на неё ссылается до конца работы, и без
-# этой развилки последний коммит отчёта запирал бы ветку: ни правки по замечаниям разбора, ни
+# этой развилки последний коммит PR запирал бы ветку: ни правки по замечаниям разбора, ни
 # записи в журнал изменений после вливания уже не сделать.
 #
 # Влитое от незаведённого отличает история ветки: путь, которого в ней никогда не было,

package/assets/hooks/window-fill-guard.sh

@@ -131,7 +131,7 @@ case "$tool" in
         esac
         ;;
     Bash | mcp__webstorm__execute_terminal_command)
-        # Поставка и сверки: коммит, пуш, отчёт, колонка задачи, состояние дерева. Список
+        # Поставка и сверки: коммит, пуш, PR, колонка задачи, состояние дерева. Список
         # дописывается профилем дерева — клиент хостинга и имена команд у каждого свои.
         if rt_needs rt_handoff_allowed_cmd window-fill-guard && rt_handoff_allowed_cmd "$cmd"; then
             allowed=1

package/assets/laws/delivery.md

@@ -28,10 +28,10 @@
   своим номером, а то, чего в первой не было, дописывается в неё до этого. Две строки об
   одной работе хуже дыры в нумерации: по ним потом не понять, что сделано, а что нет. Слить
   их можно, пока правка не въехала в главную ветку; после — обе остаются как есть.
-- **Задача, ветка под неё и отчёт о сделанном несут один и тот же номер в своих названиях.**
+- **Задача, ветка под неё и PR о сделанном несут один и тот же номер в своих названиях.**
   Иначе одну работу приходится узнавать по тексту названия, а в списке из полусотни строк это
   делается по памяти и с ошибками.
-- **Номер пишется всюду одинаково: ключ задач, дефис, номер.** Заголовок задачи и отчёта
+- **Номер пишется всюду одинаково: ключ задач, дефис, номер.** Заголовок задачи и PR
   начинается с этой пары в квадратных скобках, имя ветки — с неё же. Одна форма, а не три
   похожих, потому что номер читают не только глазами: из имени ветки его достаёт гард, из
   заголовка — сверка очереди. Формы, выведенные порознь, расходятся молча и не отказывают, а
@@ -46,9 +46,9 @@
   ничьей: по очереди работ не видно, кто её взял, и заведённая по ходу правка теряется среди
   чужих.
 - **Состояние задачи в очереди работ отвечает тому, что с ней происходит.** Взятая в работу
-  видна взятой, а та, отчёт по которой ждёт разбора, — ждущей разбора. Иначе очередь показывает
+  видна взятой, а та, PR по которой ждёт разбора, — ждущей разбора. Иначе очередь показывает
   один и тот же вид у нетронутого, у делаемого прямо сейчас и у сделанного: работа берётся
-  второй раз, а отчёт стоит неразобранным, пока про него не вспомнят. Состояние переставляется
+  второй раз, а PR стоит неразобранным, пока про него не вспомнят. Состояние переставляется
   в тот момент, когда работа переходит на следующий шаг, а не приводится в порядок потом:
   очередь читают между этими моментами, а не после них.
 - **Попадание правки в главную ветку означает выкатку.** Всё, от чего правка зависит снаружи
@@ -71,10 +71,16 @@
   иначе «сошлось» значит в этих двух местах разное.
 - **Документ едет вместе с правкой, которую он описывает.** Ни сборка, ни проверки текстов
   не читают, поэтому расхождение копится молча и потом выглядит действующей справкой.
-- **Отчёт о сделанном остаётся верным до самого слияния.** Он описывает дерево на день, когда
+- **PR о сделанном остаётся верным до самого слияния.** Он описывает дерево на день, когда
   его написали, а разбора ждёт днями: за это время главная ветка вливается в ветку, и
-  утверждение отчёта о соседних файлах становится неправдой молча — тел отчётов не читает ни
-  одна проверка. Всё, что вливается в ветку после публикации отчёта, — повод перечитать его.
+  утверждение PR о соседних файлах становится неправдой молча — тел PR не читает ни
+  одна проверка. Всё, что вливается в ветку после публикации PR, — повод перечитать его.
+- **PR в главную ветку вливает человек.** Слияние — последний момент, когда разбор ещё
+  возможен: после него правка стоит в главной ветке, работа ушла к следующей задаче, и
+  вернуться к ней уже некому. Исполнитель работы вливает свой PR только по прямому слову
+  человека и только про названный PR; молчание разрешением не бывает, а слово, сказанное об
+  одном PR, на следующий не переносится. Иначе разбор проходит тот, кого разбирают, и
+  очередь PR выглядит разобранной, не будучи ею.
 - **Слияние в главную ветку ещё не означает, что правка доехала.** Отказ выкатки не трогает ни
   задачу, ни очередь работ, поэтому расхождение главной ветки с тем, что работает, обязано быть
   видно там, где очередь читают. Иначе следующие работы вливаются поверх поломки, которую не

package/assets/laws/project-documentation.md

@@ -56,3 +56,24 @@
   знает само дерево, а не текст, приехавший в него. Утверждение, сказанное безусловно, врёт тем
   увереннее, что печатает его сам инструмент, — и поправить его дерево не может, если правки на
   месте у такого текста не предусмотрено.
+- **Принятое решение становится пунктом слоя правил, а не записью о прошлом.** Записанное
+  описанием прошлого перестаёт действовать в тот же день: описания прошлого не приходят в
+  контекст работы, читаются как история и ничего не требуют. Следующая работа принимает то же
+  решение заново — и принимает иначе, потому что доводов первого уже не видит.
+- **У решения есть слой, и он выбирается по тому, о чём решение говорит.** Что должно быть
+  верно в продукте — статья закона. Каким приёмом это делается здесь — пункт правила. Готовый
+  код и порядок действий — паттерн. Решение, положенное не в свой слой, находится только тем,
+  кто уже знает, что оно есть.
+- **Описание прошлого объясняет состоявшийся переезд, а не держит действующее требование.**
+  Разница видна вопросом: перестанет ли текст быть верным, если завтра всё переделать. Рассказ
+  о том, как и почему однажды перенесли, — прошлое; требование «делай так» — нет, и место ему
+  в слое правил.
+- **Признак, по которому решение относят к прошлому, записан заранее и один на все работы.**
+  Выводимый каждой работой заново, он назначается тем, кому мешает: под конец работы дешевле
+  назвать прошлым всё, что осталось разобрать.
+- **Раздел решений в описании домена — временное место, а не постоянное.** Пока решение там,
+  оно действует только для того, кто открыл этот файл. Разросшийся раздел — признак того, что
+  правило под него не заведено, а не того, что домен сложный.
+- **Работа, которая переносит решения, называет для каждого, куда оно ушло.** Иначе по
+  описанию прошлого не отличить решение, ставшее правилом, от решения, потерянного при
+  переносе: оба выглядят одинаково — записью, на которую никто не ссылается.

package/assets/laws/verifiability.md

@@ -33,7 +33,7 @@
 - **Успешный ответ команды означает, что она отработала, а не что нужное состояние
   наступило.** Часть запросов выполняется наполовину, и об отклонённой части в ответе ничего
   нет: по коду возврата такой вызов не отличить от исполненного. Поэтому результат читают
-  отдельным запросом, и в отчёт идёт то, что прочитали, а не то, что заказывали.
+  отдельным запросом, и в PR идёт то, что прочитали, а не то, что заказывали.
 - **Служба считается поднятой, когда она выполнила задание, а не когда сообщила о
   готовности.** Сообщение о готовности говорит лишь, что служба себя объявила: та, которой не
   досталось ни одного задания, выглядит в нём точно так же, как работающая. Проверяются обе
@@ -47,6 +47,11 @@
   выключают в настройке инструмента, а не обходят в каждом месте.** Обход приходится повторять
   столько раз, сколько таких мест, и ни в одном из них не написано, зачем он: со стороны это
   выглядит ошибкой автора, а не решением.
+- **Красная проверка означает неверный код, а не неверную проверку.** Место, выведенное
+  из-под проверки затем, чтобы она замолчала, чинит показание, а не то, на что она указала:
+  код остаётся прежним, а сигнала о нём больше нет ни у кого. Список известного накоплен к
+  дню заведения проверки и только сокращается; несогласие с самой проверкой — вопрос к
+  владельцу, а не строка в списке.
 - **Польза правила подтверждается наблюдением за тем, как им пользуются, а не мнением о нём.**
   Правило, которого не открыли ни разу, и правило, на котором держится половина работы, в тексте
   выглядят одинаково — и правится первым обычно то, о чём вспомнили, а не то, что мешает.

package/assets/laws/work-conduct.md

@@ -20,7 +20,7 @@
 - **Остановка называется первой строкой.** Сообщение, которым исполнитель останавливается,
   начинается с того, чего он ждёт и что будет, если ответа не будет. Замеры, находки и разбор
   к этому моменту уже записаны в ход работы — в сообщении владельцу они лишние. Чем подробнее
-  отчёт, тем надёжнее вопрос в нём тонет, и владелец переспрашивает, почему работа стоит.
+  PR, тем надёжнее вопрос в нём тонет, и владелец переспрашивает, почему работа стоит.
 - **Владельцу не задаётся вопрос, ответ на который уже записан.** Записанное читают до
   разговора, а не вместо ответа: вопрос о том, что уже решено, обесценивает и остальные.
 - **Вопрос владельцу задаётся после того, как ответ искали в дереве.** Что лежит в дереве,
@@ -31,6 +31,11 @@
   «здесь нет», «этого не заводили», «такого файла не бывает» — произносится только как вывод
   команды. Не проверенное отрицание опаснее вопроса: вопрос владелец поправит, а факт от
   исполнителя примет на веру, потому что тот в дерево смотрит.
+- **Отрицание, полученное одним источником, отрицанием не является.** Ответ «не найдено», отказ
+  в доступе и пустой список говорят о правах спрашивающего, а не о предмете: тот же вопрос,
+  заданный оттуда, где предмет виден, отвечает обратным. Сказать «этого нет» можно только после
+  второго источника — иначе исполнитель называет владельцу собственные права, приняв их за
+  устройство мира.
 - **Решение, однажды записанное, действует, пока его не отменили, и читается до того, как
   принимается заново.** Отменённое решение следа в работе не оставляет — по результату не
   видно ни того, что его принимали, ни того, что от него отказались. Принятое заново оно
@@ -58,7 +63,7 @@
   пересказ он даёт по своей памяти, а не по ходу работы, и следующий заход начинает с чужой
   картины.
 - **Замысел и ход работы — разные записи.** Замысел — то, с чем сверяют результат при
-  приёмке; правленный по ходу, он перестаёт отличаться от отчёта, и приёмке сверять нечего.
+  приёмке; правленный по ходу, он перестаёт отличаться от PR, и приёмке сверять нечего.
 - **Сделанное отмечается в одном месте.** Две записи об одном разъезжаются молча, и после
   этого ни по одной не видно, что осталось.
 - **Решение, принятое по ходу работы, записывается вместе с причиной.** Без причины оно
@@ -66,7 +71,7 @@
 - **Граница работы названа до её начала.** Не названная вслух граница не существует: правка
   расползается на соседнее, и снимать её приходится вручную.
 - **Действия, которые исполнитель не делает сам, названы списком.** Всё, что уходит за
-  пределы рабочего дерева или не откатывается — запись в общий репозиторий, публикация, отчёт,
+  пределы рабочего дерева или не откатывается — запись в общий репозиторий, публикация, PR,
   правка общего документа, — делается по слову владельца, и слово это даётся на действие, а не
   на работу целиком. Не названная списком граница выводится из общих слов: «делай, что нужно
   по плану» прочитывается как разрешение на всё, что в плане подразумевалось.
@@ -104,3 +109,62 @@
 - **У предложенной правки правил назван адрес: сам слой правил, имена этого дерева или его
   надстройка.** Без адреса правку кладут туда, где она видна автору, — то есть в своё дерево, —
   и общее оседает в одном месте, оставаясь неизвестным всем остальным.
+- **Предложение, о котором владелец сказал вслух, уходит наружу в тот же ход.** Написанное и не
+  отправленное лежит в дереве неотличимо от отправленного: своей записи в слое правил у него
+  нет, и владелец читает работу сделанной, пока не спросит прямо. Слово владельца о предложении
+  — «отправь», «заведи», «напиши» — распоряжение, а не тема разговора; показ того, что уехало
+  бы, отправкой не является и следа наружу не оставляет.
+- **Неудобство отправки — повод сказать о нём, а не повод не отправить.** Довод исполнителя
+  против уже принятого решения владельца остаётся доводом: он называется вслух, работа при этом
+  идёт. Отложить исполненное решение может только владелец; отложенное собственным доводом
+  выглядит для него сделанным, и цену этого он узнаёт последним.
+- **Работа, из которой видно серию задач, объявляется эпиком до первой из них.** Объявляется
+  дважды: карточкой в очереди работ и замыслом рядом с ней. Не объявленная серия существует
+  только в голове того, кто её задумал: следующий заход видит разрозненные задачи, порядка между
+  ними не находит и берёт ту, что ближе лежит.
+- **Замысел эпика называет разрабатываемую возможность, состав задач и их порядок.** Состав без
+  порядка порядком не является: две задачи, у которых порядок держался пониманием, ушли в работу
+  наоборот, и вторая переделывалась под первую. Возможность, названная одним словом, через неделю
+  читается каждым по-своему.
+- **Порядок задач эпика назначается на планировании и держится до его конца.** Пересмотр по ходу
+  — решение владельца, записанное там же, где идёт работа. Порядок, назначаемый заново перед
+  каждой задачей, назначает тот, кому ближе, и эпик кончается там, где надоел.
+- **Заход исполнителя не кончается вместе с задачей.** Конец задачи — не признак остановки:
+  остановиться позволяет только предел заполнения окна. Заход, закрытый на готовой задаче,
+  оставляет владельцу пустое место и стоит целого захода на возвращение к тому, что и так было
+  под рукой.
+- **Работа, отданная на разбор, освобождает исполнителя, а не останавливает его.** Отданное на
+  разбор ждёт владельца, а не машину: следующая задача эпика берётся тем же движением, которым
+  предыдущая ушла на разбор.
+- **Отдав работу на разбор, исполнитель называет, чего ждёт и что сделает следом.** Владелец
+  видит не голову исполнителя, а страницу работы: зелёная проверка и доступное действие
+  читаются как «всё кончено». Названное вслух ожидание — единственное, что отличает «жду
+  проверок, потом уберу за собой» от «готово, забирай». Не названное, оно не существует, и
+  владелец действует по тому, что видит.
+- **Работа не считается готовой, пока исполнитель не сказал этого прямо.** Готовность объявляет
+  тот, кто работу вёл, — отдельной просьбой и про эту работу. Зелёные проверки готовностью не
+  являются: они говорят, что не сломано, и молчат о том, осталось ли что-то сделать. Молчание
+  исполнителя владелец читает как готовность, и между двумя прочтениями теряется всё, что
+  стояло после разбора.
+- **Уборка за работой идёт до того, как о готовности сказано.** Всё, что работа обязана убрать
+  за собой, убирается раньше просьбы включить её в общее дерево, а не после согласия. После
+  включения убирать уже некому: работа перешла к следующей задаче.
+- **Пока эпик не кончился, следующая работа не выбирается, а берётся.** Выбор, предложенный
+  владельцу при назначенном порядке, — это просьба назначить его заново: он уже назначен, и
+  предлагать его повторно значит отменять собственное планирование.
+- **Замеченное по ходу и к эпику не относящееся становится задачей в очереди работ, а не работой
+  сейчас.** Отвлечение выглядит дешёвым ровно до того, как окажется, что вместе с ним уехала
+  правка соседнего домена: эпик при этом стоит, а откатывать приходится обе работы.
+- **Эпик кончается, когда кончились его задачи, а не когда стало непонятно, что дальше.**
+  Непонятно бывает от того, что замысел не открыли: он лежит и держит решения, которых в коде не
+  видно.
+- **Положение эпика показывается владельцу таблицей — в передаче и при остановке за его
+  решением.** Это два момента, когда владелец смотрит на работу снаружи: в первый он забирает её
+  в новый заход, во второй решает, куда её вести. Порядок задач при этом лежит в замысле, а
+  замысел ни там, ни там не открывают — передача пересказывает один заход, вопрос называет одну
+  развилку, и по обоим не видно ни сделанного, ни оставшегося.
+- **Таблица показывает все задачи эпика разом — закрытые, текущую и назначенные.** Строка на
+  задачу: место по порядку, задача, состояние; текущая отличается от остальных на вид. Порядок у
+  закрытых фактический, у будущих назначенный, и расхождение между ними тоже утверждение — оно
+  говорит, что порядок пересматривали. Перечень одних оставшихся не показывает, чего работа
+  стоила; перечень одних закрытых не показывает, сколько ещё впереди.

package/assets/patterns/git-workflow-commit.azure.md

@@ -43,6 +43,14 @@ az boards work-item update --id <номер> --title '[<номер>] …'   # н
 Номер в заголовок руками не пишется — он известен только после создания, и команда дописывает
 его сама.
 
+Заведение кончается не выводом команды, а ответом очереди работ. Команда спрашивает её сама и
+печатает прочитанное — присутствие на доске, состояние, исполнителя; отсутствие кончает её
+ненулевым кодом. В комментарий, в тело PR и в замысел идёт этот ответ, а не напечатанный
+номер: номер говорит «вызов прошёл», а не «работа видна тому, кто по ней придёт».
+
+Заведения, идущие подряд, проверяются не по последнему, а сверкой очереди целиком: промах у них
+общий, и по одному элементу он не виден.
+
 Чем сверить, что очередь работ в порядке:
 
 ```bash
@@ -187,7 +195,7 @@ az repos pr update --id 205 --description "$(cat тело.md)"
 ```
 
 Правка описания переписывает его целиком. Тело перечитывается всякий раз, когда в ветку что-то
-влилось после публикации: отчёт утверждает про дерево, а дерево с тех пор изменилось.
+влилось после публикации: PR утверждает про дерево, а дерево с тех пор изменилось.
 
 ## Состояние PR читается, а не додумывается
 
@@ -248,7 +256,7 @@ npm run task:move -- 86 in-review
 15. **Набор пересмотрен после вливания главной ветки.** Он выбирается по тому, что ветка везёт
     теперь, а не по тому, что правил автор. Ветка, не тронувшая ни строки показа, прогоняет
     снимки витрин: с момента вливания их гоняет конвейер на её коде, и красное придёт на её
-    отчёт.
+    PR.
 
 Сразу после публикации элемент переводится в разбор, и сверка очереди прогоняется ещё раз: до
 открытия PR состояние она не судит, а после открытия расхождение видит.

package/assets/patterns/git-workflow-commit.github.md

@@ -46,6 +46,15 @@ gh project item-add <номер борды> --owner <владелец> --url <а
 
 Последний шаг и есть тот, который забывается: без него задача заведена, но её нет в очереди.
 
+Заведение кончается не выводом команды, а ответом очереди работ. Команда спрашивает её сама и
+печатает прочитанное — присутствие на борде, колонку, исполнителя; отсутствие кончает её
+ненулевым кодом. В комментарий, в тело PR и в замысел идёт этот ответ, а не напечатанный
+номер: номер говорит «вызов прошёл», а не «задача видна тому, кто по ней работает».
+
+Заведения, идущие подряд, проверяются не по последнему, а сверкой очереди целиком: промах у них
+общий, и по одной задаче он не виден. Шестнадцать задач подряд напечатали номер, и ни одна не
+попала в очередь так, чтобы её увидел владелец.
+
 Название тикета говорит, что не так, а не что сделать: PR потом переводит его в сделанное.
 Номер в заголовок руками не пишется — он известен только после создания, и команда дописывает
 его сама.
@@ -227,7 +236,7 @@ $GH api -X POST "repos/$REPO/pulls/205/requested_reviewers" -f 'reviewers[]=<в
 $GH api -X PATCH "repos/$REPO/pulls/205" -f body="$(cat тело.md)"
 ```
 
-Тело перечитывается всякий раз, когда в ветку что-то влилось после публикации: отчёт
+Тело перечитывается всякий раз, когда в ветку что-то влилось после публикации: PR
 утверждает про дерево, а дерево с тех пор изменилось.
 
 ## Состояние PR читается, а не додумывается
@@ -270,6 +279,10 @@ npm run task:move -- 86 in-review
 гоняет ничего. Линтеры, юниты и сценарии хуков снимает гейт пуша — ниже то, чего он не знает.
 
 1. **Главная ветка влита в эту ветку** — `git fetch origin && git merge origin/main`.
+   Свежесть основания между ветками одного захода не наследуется: вторая и третья ветка
+   отводятся после своего `fetch`, а не от ссылки, подтянутой под первую. Пока идёт работа,
+   главная уходит вперёд — чаще всего собственным PR того же исполнителя, влитым час
+   назад.
    Всё, что проверяется ниже, проверяется от этого основания: PR с разошедшейся ветки
    показывает ревьюверу правку вперемешку с чужой. Порядок и разбор конфликта — паттерн
    `git-workflow-merge`.
@@ -305,7 +318,7 @@ npm run task:move -- 86 in-review
 15. **Набор пересмотрен после вливания главной ветки.** Он выбирается по тому, что ветка везёт
     теперь, а не по тому, что правил автор. Ветка, не тронувшая ни строки показа, прогоняет
     снимки витрин: с момента вливания их гоняет конвейер на её коде, и красное придёт на её
-    отчёт.
+    PR.
 
 Сразу после публикации задача переставляется в разбор — `npm run task:move -- <номер>
 in-review`, — и `npm run check:board` прогоняется ещё раз: до открытия PR колонку он не судит,

package/assets/patterns/git-workflow-commit.gitlab.md

@@ -46,6 +46,14 @@ glab issue update <номер> --title '[<КЛЮЧ>-<номер>] …'   # но
 Метка списка ставится при заведении, а не после: issue без неё лежит вне доски, и увидеть её
 можно только поиском по проекту.
 
+Заведение кончается не выводом команды, а ответом очереди работ. Команда спрашивает её сама и
+печатает прочитанное — присутствие на доске, список, исполнителя; отсутствие кончает её ненулевым
+кодом. В комментарий, в тело PR и в замысел идёт этот ответ, а не напечатанный номер: номер
+говорит «вызов прошёл», а не «задача видна тому, кто по ней работает».
+
+Заведения, идущие подряд, проверяются не по последнему, а сверкой очереди целиком: промах у них
+общий, и по одной задаче он не виден.
+
 Чем сверить, что очередь работ в порядке:
 
 ```bash
@@ -204,7 +212,7 @@ glab mr update 205 --description "$(cat тело.md)"
 
 Правка описания переписывает его целиком, поэтому строка `Closes #<номер>` пишется заново
 вместе с остальным текстом. Тело перечитывается всякий раз, когда в ветку что-то влилось после
-публикации: отчёт утверждает про дерево, а дерево с тех пор изменилось.
+публикации: PR утверждает про дерево, а дерево с тех пор изменилось.
 
 ## Состояние MR читается, а не додумывается
 
@@ -268,7 +276,7 @@ npm run task:move -- 86 in-review
 15. **Набор пересмотрен после вливания главной ветки.** Он выбирается по тому, что ветка везёт
     теперь, а не по тому, что правил автор. Ветка, не тронувшая ни строки показа, прогоняет
     снимки витрин: с момента вливания их гоняет конвейер на её коде, и красное придёт на её
-    отчёт.
+    PR.
 
 Сразу после публикации задача переставляется в разбор, и сверка очереди прогоняется ещё раз: до
 открытия MR список она не судит, а после открытия расхождение видит.