check

Overview ¶

acceptance_edit_after_verdict.go — правка ОДОБРЕННОЙ приёмки после вердикта объявляется в самом документе.

Порт с монорепо (`internal/repohygiene/acceptanceeditafterverdict.go`, снят вынесением службы — `kacho#2597`). Изменилось: путь дома приёмок (был `docs/engineering/acceptance`, здесь — `docs/engineering/acceptance` от корня СВОЕГО модуля) и обход git через `platformtree`/`gitenv` вместо внутреннего `repoRoot(t)` монорепо. Осталось дословно: имя функции гейта (`TestAcceptanceEditedAfterItsVerdictSaysSo`), сам разбор и текст находки.

Предмет ¶

Вердикт есть утверждение о РЕВИЗИИ, которую прочитал проверяющий: правка её не переносит и не отзывает задним числом. Документ, чья строка состояния правлена раньше, чем сам файл, и не назвавший эту правку прямо, объявляет вердикт о ревизии, которую никто не читал.

Почему пара величин, а не одна ¶

Признак — сравнение двух отметок: когда последний раз правилась СТРОКА СОСТОЯНИЯ и когда сам документ. Обе берутся в ЭПОХЕ: строковое сравнение дат в двух часовых поясах даёт неверный порядок.

acceptance_path_coordinate.go — гейт: ПУТЬ, названный приёмкой как ПРЕДИКАТ, резолвится в дереве службы либо называет свой ДОМ.

Сосед по классу — `acceptance_probe_coordinate.go`: там координата есть ИМЯ ПРОБЫ, здесь — ПУТЬ. Предмет один (утверждение, пережившее свой предмет), граница разбора — разная, и разница ниже названа целиком, потому что дважды она ИНВЕРТИРОВАНА и списать её на небрежность легко.

Предмет ¶

Приёмка доказывает свои утверждения ПРЕДИКАТОМ — командой, которую читатель обязан прогнать сам: `git grep … -- <путь>`. Предикат, чей путь в дереве не существует, даёт пустоту НЕ ПОТОМУ, что находок нет, а потому, что читать было нечего. «Ноль находок» становится неотличимо от «ноль прочитанного», и читатель делает вывод О ДЕРЕВЕ по замеру, который ничего не измерял.

Это тот же класс, что у соседа, но он ТИШЕ. Мёртвое имя пробы обнаруживается первым же прогоном (`go test -run` отвечает «no tests to run»). Мёртвый путь не отвечает ничем: команда завершается успехом и печатает пустоту — ровно то, чего от неё и ждали, когда утверждение было «здесь чисто».

Замер, из которого гейт заведён (`kaname#71`, дерево на `bbd196ea`): путей, названных предикатом, — 52, из них не резолвилось **66 вхождений в 16 документах** по наивному предикату задачи и **192 в 24** по разбору, знающему путь-спецификацию в кавычках. Разница — не придирка: она и есть слепая зона наивного предиката, а слепая зона проверки не краснеет и не зеленеет.

ГРАНИЦА РАЗБОРА — названа явно, потому что путь стоит в тексте ТРОЯКО ¶

Один и тот же путь встречается в приёмке в трёх видах, и лишь один из них — координата, за которой читатель идёт с командой:

`git grep -n 'X' -- internal/manifest`   — ПРЕДИКАТ: путь после `--`, СУДИТСЯ
`internal/manifest/roles.go:135`         — проза: описание места, НЕ судится
`git ls-files 'proto/kacho/cloud/iam/**'` — путь-спец БЕЗ `--`, НЕ судится

ПРОЗА ВНЕ СУЖДЕНИЯ, и это решение, а не недосмотр. Путь в прозе — описание, а не адрес для прогона; в корпусе приёмок службы таких вхождений ОДНОГО только монорепного корня 992 в 33 документах, и почти все они — исторические утверждения о дереве, каким оно было ДО выноса (`kacho#2598`). Судить их значило бы требовать переписать свидетельство о прошлом. Число прозаических вхождений тем не менее ПЕЧАТАЕТСЯ переписью: слепая зона, которую видно, остаток, а не дыра.

ПУТЬ-СПЕЦИФИКАЦИЯ БЕЗ `--` ВНЕ СУЖДЕНИЯ ПО ДРУГОЙ ПРИЧИНЕ, и она несущая: в форме `git ls-files <спец>` путь сплошь и рядом есть САМ ПРЕДМЕТ УТВЕРЖДЕНИЯ ОБ ОТСУТСТВИИ — «такого корня в дереве нет, → 0». Там нерезолвящийся путь не дефект, а ровно то, что доказывают, и находка на нём была бы ложной. Отличить «путь мёртв» от «путь назван мёртвым намеренно» можно лишь прочитав НАМЕРЕНИЕ соседней прозы, а этого гейт не умеет и обещать не вправе. Замер: в дереве таких вхождений 33, из них утверждением об отсутствии — 27. Число печатается.

ОГОРОЖЕННЫЙ БЛОК КОДА СУДИТСЯ — ИНВЕРСИЯ ОТНОСИТЕЛЬНО СОСЕДА ¶

Сосед пропускает огороженные блоки целиком: имя пробы внутри команды — не координата, а часть предиката, и судить его значило бы краснеть на собственном объяснении документа.

Здесь наоборот: блок кода — ГЛАВНОЕ место жительства предиката. Приёмка выносит команду в блок именно тогда, когда хочет, чтобы её прогнали. Пропусти гейт огороженные блоки — и он потерял бы 48 вхождений из 192 (четверть), не сказав об этом ничем. Поэтому блок судится, а различение делает не забор, а ПОЗИЦИЯ ТОКЕНА: после `--` в строке, несущей `git grep` либо `git ls-files`.

ПОДСТАНОВОЧНЫЙ ЗНАК: судится ГЛУБОЧАЙШИЙ ПРЕДОК БЕЗ МЕТАСИМВОЛА ¶

`internal/migrations/*.sql` резолвится, если есть КАТАЛОГ `internal/migrations`, а не если шаблону что-то соответствует. Различие несущее в обе стороны:

• шаблон, которому сегодня не соответствует ничто, — ЗАКОННЫЙ вердикт («миграций с такой датой нет»), а не мёртвая координата;
• каталог, которого нет, — мёртвая координата, даже когда шаблон выглядит правдоподобно.

Отсюда правило отсечения: берём часть до первого метасимвола и поднимаемся до ближайшего `/`. Наивное «часть до звёздочки» ошибается на шаблоне, чей метасимвол стоит ВНУТРИ имени файла (`internal/migrations/20260902*`): оно объявило бы мёртвым живой каталог. Класс пойман на себе при заведении гейта.

НАЗВАННЫЙ ДОМ: чужой репозиторий — вне суждения, но НЕ прощён ¶

Форма ВЗЯТА у соседа (`владелец/репозиторий:путь`, необязательно `@<ревизия>`), а он взял её у `scripts/docs-gate/check-03-holding-claim-resolves.py` воркспейса. Отличие от соседа одно: там дом стоит у ИМЕНИ, здесь — у ПУТИ, потому что координата этого гейта и есть путь. Двоеточие не спутать с git-формой `<ревизия>:<путь>`: слева от него требуется слэш, которого у ревизии не бывает.

Чужой дом ВНЕ суждения по построению: чужого дерева рядом может не быть, а сеть в прогоне гейта запрещена. «Вне суждения» отличается от «прощено» тремя свойствами, и все три обязательны:

1. чужая координата СЧИТАЕТСЯ, а её дома ПЕЧАТАЮТСЯ: дом, стоящий в корпусе один раз, тем самым виден — опечатка в имени репозитория не уходит молча;
2. приставка, домом НЕ являющаяся (`kacho:internal/x`, `MOD-MF-21:internal/x`), — НАХОДКА. Иначе любой неразобранный префикс снимал бы путь с суждения, и приставка стала бы способом спрятать адрес, а не назвать дом;
3. СТОРОЖА живут в гейте, а не здесь: ядро судит поданные значения, и для него всякий непустой дом чужой. Свой дом, названный чужим, ловит гейт.

ЧЕГО ЭТОТ ГЕЙТ НЕ ДЕЛАЕТ — сказано прямо ¶

Он судит СУЩЕСТВОВАНИЕ пути, а НЕ истинность числа, стоящего рядом с предикатом. Путь, приведённый к дереву, делает предикат исполнимым; сойдётся ли его вывод с числом, которое приёмка назвала, — вопрос К ЧИСЛУ, и он закрывается кругом ревью, а не этой проверкой. Граница честная и она же неприятная: живой адрес с ложным содержимым хуже мёртвого, потому что не краснеет. Держателя у второй половины сегодня НЕТ, и завести его дороже: потребовался бы прогон каждого предиката приёмки на каждом прогоне гейта.

acceptance_probe_coordinate.go — гейт: имя пробы, названное приёмкой КООРДИНАТОЙ, резолвится функцией в дереве.

Порт с монорепо (`internal/repohygiene/acceptanceprobecoordinate.go`, снят вынесением службы — `kacho#2597`). До этой правки держатель (`TestAcceptanceProbeCoordinateResolves`) не существовал ни в одном файле, а восемь живых приёмок службы (`roles-come-as-data-not-migrations.md`, `model-block-prose-has-a-home.md`, `model-generated-from-manifest.md`, `classes-form-of-role-right.md`, `retire-tenant-condition-surface.md`, `system-role-segments-resolve.md`, `module-manifest-resources-roles-deprecated.md`, `module-manifest-roles-and-seed-grants.md`) продолжали называть его своим.

Предмет ¶

Приёмка ссылается на пробу, чтобы читатель мог её открыть и прогнать. Проба переживает не всякую правку: её переименовывают, сводят с соседней, снимают вместе с предметом — и делают это в СВОЁМ изменении, которое чужой приёмки не касается. Тогда координата остаётся стоять, а функции за ней нет.

Класс — утверждение, пережившее свой предмет, и он опаснее обычной устаревшей строки: следующий идёт по названному адресу, не находит ничего и делает вывод О ДЕРЕВЕ, а не о документе.

Почему координатой считается ТОЛЬКО целый пролёт кода ¶

Имя пробы встречается в приёмке в трёх видах, и лишь один из них — координата:

`TestFoo`                            — КООРДИНАТА: пролёт целиком есть имя
`go test -run '^TestFoo$' -count=1`  — предикат: имя стоит внутри команды
«проба TestFoo снята вместе с предметом» — проза разбора

Проверка по подстроке краснела бы на втором и третьем, то есть на СОБСТВЕННОМ объяснении документа. Поэтому документ читается РАЗОБРАННЫМ: огороженные блоки кода пропускаются целиком, а из строки берутся только пролёты `…`, чьё содержимое ЦЕЛИКОМ есть имя пробы.

Почему резолв по ПРЕФИКСУ, а не по равенству ¶

Корпус называет пробу двумя законными формами: полным именем и ИДЕНТИФИКАТОРОМ СЦЕНАРИЯ (`TestIAMCT112`), которым отбирают семейство — `-run '^TestIAMCT112'`. Отсюда правило: координата резолвится, если ОБЪЯВЛЕННОЕ имя начинается с неё. Направление существенно: `TestFoo‹хвост›` → `TestFoo` этим правилом не прощается — объявленное короче координаты и её префиксом не является.

НАЗВАННЫЙ ДОМ: чужой репозиторий — вне суждения, но НЕ прощён ¶

Служба вынесена из монорепо (`kacho#2598`), и приёмки уехали вместе с ней, а гейты дерева остались там, где судят своё дерево. Отсюда третья форма записи координаты:

`TestFoo`                              — координата ЭТОГО дерева, судится;
`PRO-Robotech/kacho:TestFoo`           — координата ЧУЖОГО дома;
`PRO-Robotech/kacho@d941344bd9:TestFoo` — чужой дом, связанный ревизией.

Форма ВЗЯТА, а не придумана здесь: `owner/name:` у координаты ввёл `PRO-Robotech/kacho-workspace` `scripts/docs-gate/check-03-holding-claim-resolves.py` по тому же поводу — вынос службы оставил его координаты нерезолвящимися в стволе продукта. Оттуда же довод в пользу двоеточия: спутать `owner/name:путь` с git-формой `<ревизия>:<путь>` нельзя, потому что слева требуется слэш, которого у ревизии не бывает. Отличие одно и вынужденное: там дом стоит у ПУТИ, здесь — у ИМЕНИ, потому что координата ЭТОГО гейта и есть имя.

Чужой дом ВНЕ суждения по построению: ни подтвердить, ни опровергнуть объявление функции в чужом репозитории этот гейт не может — дерева рядом нет, а сеть в прогоне гейта запрещена. Доктрина в дереве уже есть и здесь не заводится второй раз: `carried_coordinate_ledger.go` §«Кросс-репо координата — вне суждения ОБОИХ сторон».

РЕЗОЛВ В НАЗВАННОМ ДОМЕ ТЕПЕРЬ ДЕЛАЕТСЯ — `probe_home.go` плюс `JudgeHomes` у вызывающего. Ядро по-прежнему судит ЗНАЧЕНИЯ и чужих деревьев не читает: оно собирает координаты чужих домов в `ForeignCoordinates`, а резолвит их тот, у кого есть корень. Ниже — прежний разбор, объясняющий, почему ветвь нельзя было завести БЕЗ производителя входа; он остаётся верным и описывает, чем производитель стал.

ПРЕЖНИЙ ОСТАТОК (закрыт `kaname#44`): резолв в названном доме здесь НЕ делался, и это остаток с предметом, а не граница по незнанию: воркспейс его умеет (опознаёт дерево идентичностью `origin`, отвечает третьей категорией, когда дерева рядом нет), но в конвейере службы чужого дерева нет НИКОГДА — ветвь была бы вечно-пустой, то есть мёртвым стражем ровно того вида, который запрещает ban #16. Заводится вместе с резолвером дома и инъекцией на двух синтетических деревьях — `kaname#44`.

«Вне суждения» отличается от «прощено» ТРЕМЯ свойствами, и все три обязательны:

1. чужая координата СЧИТАЕТСЯ, а её дома ПЕЧАТАЮТСЯ переписью. Дом, стоящий в корпусе один раз, тем самым виден — опечатка в имени репозитория не уходит молча. Связанные РЕВИЗИЕЙ считаются отдельно: они не проверяемы даже там, где дерево дома есть;
2. приставка, домом НЕ являющаяся (`kacho:TestFoo`, `IAM-MV-04:TestFoo`), — НАХОДКА. Без этого любой не-разобранный префикс снимал бы координату с суждения, и приставка стала бы способом спрятать адрес, а не назвать дом;
3. ДВА СТОРОЖА, и живут они в гейте (`acceptance_probe_coordinate_test.go`), а не здесь, потому что им нужен дом ЭТОГО дерева — ядро судит значения, и для него всякий непустой дом чужой. Первый отвергает корпус, где ВСЕ координаты объявлены чужими: судить нечего, и «находок ноль» означало бы «ноль прочитанного». Второй ловит СВОЙ дом, названный чужим (`PRO-Robotech/kaname:TestFoo`), — иначе всякая мёртвая координата закрывается припиской своего же имени репозитория. Дом дерева выводится из `go.mod` (`OwnHomeOfTree`), а не складывается литералом.

Замер перед введением формы: пролётов вида `<что-то>:<имя-пробы>` в корпусе приёмок — НОЛЬ в обе стороны (и разобранных домом, и не разобранных), то есть правило 2 не краснеет ни на одной существующей строке.

applier_never_deletes.go — разбор пакета применителя ролей на предмет удаления строки роли (приёмка `docs/engineering/acceptance/roles-come-as-data-not-migrations.md` §3.1, держатель Г3; сценарий MOD-RD-15).

Порт с монорепо (`internal/repohygiene/applierneverdeletes.go`, снят вынесением службы — `kacho#2597`). Осталось дословно: имя функции гейта (`TestMODRD15ApplierNeverDeletesARoleRow`), сам разбор (обе оси, оба образца) и текст находки. Изменилось: пакет-цель — `internal/apps/kaname/moduleroles` (в монорепо — `internal/apps/kaname/moduleroles`), путь-константа без префикса `services/iam/`.

Предмет ¶

Роль с выдачами удалить нельзя (`ON DELETE RESTRICT`) — применитель встал бы на первой же роли, которой кто-то пользуется. Форма отзыва роли выбрана решением: строка ПОМЕЧАЕТСЯ снятой, а не удаляется (`docs/engineering/architecture/role-withdrawal-is-a-mark.md`).

Что здесь считается находкой — ДВЕ оси, и первая сильнее ¶

1. порт применителя объявляет ОДНОЗНАЧНО удаляющий глагол НАД СТРОКОЙ РОЛИ (судит имена методов интерфейса: глагол + предмет глагола);
2. в пакете стоит оператор `DELETE` над таблицей ролей строковым литералом узла разбора, а не подстрокой текста.

Чего разбор НЕ видит — названо, а не спрятано ¶

Запрос, собранный из кусков в рантайме, и запрос, приехавший параметром — первое не встречается в дереве, второе ловит первая ось: чтобы позвать чужое удаление, порт обязан его объявить.

ascii_identifiers.go — шов гейта имён этого дерева к общему разбору фундамента.

Предмет ¶

Ban #17 состоит из двух половин, и в этом дереве держалась ровно одна. Объявления конвейера судит `TestDeliveryCarriesItsOwnPipeline` (`internal/supplyhygiene`). Идентификаторы Go не судил НИКТО: держателем был гейт монорепо (`PRO-Robotech/kacho:TestIdentifiersAreASCII`), а после вынесения службы (`kacho#2597`, `kacho#2598`) он судит ЧУЖОЕ дерево — его зелёный о `PRO-Robotech/kaname` не говорит ничего. Шесть вхождений в приёмках службы продолжали называть его своим держателем. Предмет закрыт задачей #41.

Разбор переехал в фундамент — копии здесь больше нет ¶

Почему имя обязано быть латинским, чем омоглиф опасен и почему это РАЗБОР, а не поиск по образцу, — сказано в github.com/PRO-Robotech/corelib/treehygiene, там же и сам разбор. Здесь это не пересказывается: два места об одном предмете расходятся молча, и цена копии измерена — разбор имён совпадал с близнецом платформы на 17 строках кода из 34 (#51, ban #20).

Что осталось СВОИМ ¶

Обход и его КОРЕНЬ: фундамент разбирает ОДИН исходник и о деревьях не высказывается — судить чужое дерево значило бы краснеть на чужом. Обход по корню модуля службы, перепись и порог беспредметности живут у гейта, `ascii_identifiers_test.go`.

Своих правил у этого файла нет, и потому он — ШОВ, а не вторая реализация: гейт и его инъекция зовут одно имя, и связь с фундаментом объявлена в одном месте. Появится у службы своя часть разбора имён — её место здесь, и менять придётся один файл, а не три.

assertion_admission_calls.go — разбор обращений к базе, разложенных по функциям (приёмка F2, сценарий F2-28).

Порт с монорепо (`internal/repohygiene/assertionadmissioncalls.go`, снят вынесением службы — `kacho#2597`). Держатель этого гейта уже цитируется ПРОД-КОММЕНТАРИЕМ в дереве службы: `internal/repo/kaname/pg/client_assertion_replay_repo.go` — «Гейт TestAssertionAdmissionIsASingleDatabaseCall стережёт это число». Осталось дословно: имя функции гейта, сам разбор и текст находки. Изменилось: путь без префикса `services/iam/`.

Предмет ¶

Число обращений к базе внутри одной функции. Допуск однократности обязан делать РОВНО ОДНО: «не предъявлялось ли уже» и «погасить» неделимы, и неделимыми их делает первичный ключ таблицы, а не аккуратность вызывающего. Пара «посмотреть — записать» проходит ВСЕ последовательные пробы: окна между чтением и записью при последовательном прогоне не существует.

Почему владелец соединения берётся из ОБЪЯВЛЕНИЯ ТИПА, а не из списка имён ¶

Разбор читает объявления структур файла и берёт в носители соединения те поля, ЧЕЙ ТИП называет драйвер базы. Переименование поля исход не меняет, чужое одноимённое поле находкой не становится.

assertion_verifier_single.go — разбор «сверка утверждения ключа доступа в дереве ОДНА» (приёмка Ф13 `docs/engineering/acceptance/passwordless-login-with-access-key.md`, Р13, §7 инв. 2, сценарий Ф13-31; задача PRO-Robotech/kaname#613).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Утверждение ключа сверяют две полосы — проверка утверждения из сессии (Ф7) и вход без пароля (Ф13). Обе обязаны звать ОДНОГО проверяющего (`internal/webauthnverify`): вторая сверка — «упрощённая для входа» либо копия — разошлась бы с первой молча ровно там, где расхождение опасно, и ни проба одной полосы, ни проба другой этого не показали бы.

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ ВЫЗОВ ПРИМИТИВА ПОДПИСИ, А НЕ ИМЯ ФУНКЦИИ

Копия проверяющего под другим именем узнаётся по тому, что она ДЕЛАЕТ: зовёт примитив сверки подписи стандартной библиотеки (`ecdsa.Verify`, `ecdsa.VerifyASN1`, `ed25519.Verify`, `rsa.VerifyPKCS1v15`, `rsa.VerifyPSS`). Такой вызов в прод-коде законен только в доме проверяющего; функция дома, его содержащая, — «объявление сверки», и оно ОДНО. Обёртка, зовущая `webauthnverify.VerifyAssertion`, — вызывающий, а не вторая сверка: она молчит и считается в переписи вызывающих.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ НАЗВАНЫ

примитив, взятый значением (`f := ecdsa.VerifyASN1`), — узел селектора без
   вызова; разбор считает и его (сторона ложного красного, не молчания);
импорт примитива под псевдонимом распознаётся по пути импорта;
сверка чужой библиотекой (не стандартной) этим разбором не видна — в дереве
   её нет, и перепись импортов это показала бы ростом числа файлов.

assurance_level_sole_writer.go — разбор «кто производит уровень уверенности и где он лежит как состояние» (приёмка Ф11, Р1, §7 инв. 4; гейт §8 «правило одно»).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Уровень сессии производит ОДНО правило — `assurance.LevelOf` — и как состояние он лежит только в записи сессии. Второй писатель (константа оси, употреблённая как значение; строка, преобразованная в уровень мимо правила) даёт уровень, которого правило не выводило, и делает его молча: оба пути компилируются, оба типизированы осью. Второе место хранения (поле уровня в строке способа входа) было бы неверно для каждого утверждения ключа без проверки пользователя и без срока жило бы вечно.

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ ТИП ОСИ, А НЕ ИМЯ ПОЛЯ

Разбор ищет обращения к типу `assurance.Level` и его константам через импорт дома правила — под любым псевдонимом импорта — и классифицирует каждое ПО РОДИТЕЛЬСКОМУ УЗЛУ:

l == assurance.Level2 · l != … · case assurance.Level3:   ЧТЕНИЕ — молчит
assurance.LevelOf(…) · assurance.PresentableLevels(…)     ВЫЗОВ ПРАВИЛА — молчит
x = assurance.Level2 · T{Level: assurance.Level1} ·
return assurance.Level3 · f(assurance.Level2)             ПРОИЗВОДСТВО — находка
assurance.Level(s)                                        ПРЕОБРАЗОВАНИЕ — находка
type T struct { … assurance.Level … }                     ДЕРЖАТЕЛЬ — судит ведомость

Поле уровня в структуре — не находка само по себе: запись сессии и четыре её чтения (ответ краю, ответ церемонии, запись журнала, токен) законны и названы поимённо ведомостью в пробе. Разбор лишь ДОКЛАДЫВАЕТ держателя с координатой.

───────────────────────────────────────────────────────────────────────────── ПОЛОВИНА ПО МИГРАЦИЯМ

Объявление оси уровня в схеме — перечень значений ровно «1», «2», «3» (`IN (…)` либо `= ANY (ARRAY[…])`) — читается вместе с именем столбца и таблицей, при которой он объявлен. Нужна потому, что колонку с умолчанием пишет база, и писателя в коде у неё нет: половина по коду её не видит. Законных мест два вида: таблица сессии (дом состояния) и названная ведомостью СНИМКОВ таблица, где уровень лежит неподвижной копией события (JudgeAssuranceAxisColumns).

───────────────────────────────────────────────────────────────────────────── ГРАНИЦА НАЗВАНА

Разбор по узлам, без вывода типов: уровень, пронесённый через переменную типа оси (`l := assurance.Level2; rec.level = l`), находится на первом шаге (константа как значение), а не на втором. Уровень, собранный строкой без типа оси, невидим — это довод держать значение типом. Голый текстовый столбец без объявления оси половина по миграциям не видит.

assurance_method_vocabulary.go — разбор «где ещё объявлен перечень имён способов предъявления» (приёмка Ф11, Р8; гейт §8 «словарь один»).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Словарь способов — password · totp · lookup_secret · webauthn · recovery_code — объявлен ОДИН раз, в `internal/assurance`, вместе с правилом вывода уровня. Всякий, кому нужен перечень, читает `assurance.Methods()`. Второе объявление перечня в прод-коде службы расходится с первым молча: способ, заведённый в одном и не заведённый в другом, доезжает до сессии безуровневым либо отвергается хранилищем, которое правило о нём не спрашивало.

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ ОБЪЯВЛЕНИЕ ПЕРЕЧНЯ, А НЕ СЛОВО

Строковый литерал, совпадающий с именем способа, находкой НЕ является: он бывает именем поля запроса, областью токена (`"webauthn"` в области удостоверения и в условии модели прав), меткой в перечне секретов. Перечнем считается УЗЕЛ разбора, несущий два и более РАЗЛИЧНЫХ имени словаря строковыми литералами (ast.BasicLit вида token.STRING). Комментарии в счёт не идут by construction: разбор ходит по узлам, а не по тексту.

───────────────────────────────────────────────────────────────────────────── ФОРМЫ ЗАПИСИ ПЕРЕЧНЯ — ПЕРЕЧИСЛЕНЫ

[]string{"password", "totp"}                  составной литерал (среза, карты,
                                              структур — литералы собираются
                                              по всему поддереву литерала)
const ( a = "password"; b = "totp" )          группа const/var, включая
var ( p = kind{"password"}; t = kind{"totp"} ) локальную в теле функции и
                                              форму дома — структуры со
                                              строкой внутри
case "password", "recovery_code":             перечень ветви case

Форма, о которой разбор не знает, даёт не красное и не зелёное, а молчание; поэтому каждая из названных доказана инъекцией (assurance_method_vocabulary_injection_test.go).

───────────────────────────────────────────────────────────────────────────── ПОЛОВИНА ПО СХЕМЕ

Ограничение схемы, перечисляющее значения столбца (`IN (…)` либо `= ANY (ARRAY[…])`), среди которых есть имя словаря, обязано быть его ПОДМНОЖЕСТВОМ. Перечень без единого имени словаря — не предмет: состояния, алгоритмы, виды удостоверений у него свои. Чего разбор не видит — те же три границы, что у соседа по пакету (`key_algorithm_dictionary.go`): ограничение функцией или триггером, словарь из справочной таблицы, значение выражением.

ast_receiver.go — разбор получателя метода, общий для гейтов пакета.

Жил в гейте проводной стражи дороги к внешнему поставщику; гейт снят вместе с дорогой (kaname#363), а разбором пользуются гейты полосы входа и писателей адреса человека. Вторая копия одного разбора разошлась бы с первой молча, поэтому он вынесен сюда, а не скопирован.

audit_payload_pii.go — ГЕЙТ КЛАССА: нагрузка записи журнала аудита не несёт личных данных (задача `kacho#2483`).

Норма платформы названа здесь ФАКТОМ, а не ссылкой на документ: личные данные конечного пользователя — почта, телефон, предъявляемый секрет — не пишутся в след ни на успехе, ни на отказе, а корреляция ведётся по неизменяемому идентификатору.

Предмет ¶

Приёмник журнала аудита — собственный поток записей службы, и он кладёт ВСЕ поля нагрузки как есть: шага сокрытия нет ни одного. Значит всякий личный ключ, положенный в нагрузку, уезжает в поток, а срок хранения потока становится сроком хранения личных данных. Корреляция при этом личных полей НЕ требует: идентификатор субъекта (`user_id` / `resource_id`) в нагрузке уже есть, он неизменяем и остаётся правдой через год, тогда как почта и отображаемое имя изменяемы и правдой не остаются.

Почему ГЕЙТ, а не правка двух мест ¶

Правка закрывает экземпляр; класс приходит не по одному. Мест построения нагрузки в дереве три с лишним десятка, они лежат в разных пакетах, и ни одно из них не видит остальных. Автор следующего, скопировав соседнее, внесёт личный ключ незамеченным: отказа нет, красного нет, наблюдаемо это только у получателя потока.

Перечень личных ключей объявлен ЗАКРЫТЫМ СПИСКОМ, и он не выдуман ¶

Он взят у самого дерева: проба `set_blocked_test.go` уже утверждает отсутствие `email` / `display_name` / `displayName` / `external_id` в нагрузке пользовательского события — то есть решение о составе личных ключей дерево приняло раньше этого гейта, а гейт распространяет его с одного события на все. Сверх того перечень несёт ключи-секреты: та же нагрузка объявляет о себе «No secrets in payload», и это утверждение до сих пор держалось комментарием.

`external_id` попадает в перечень СОЗНАТЕЛЬНО, и это расходится с нормой платформы, называющей его не-личным идентификатором корреляции для журнала процесса. Расхождение разрешается ЕДИНИЦЕЙ НОСИТЕЛЯ: та норма — о СТРОКЕ ЖУРНАЛА процесса, которую читает оператор и которая живёт до ротации; здесь — о ЗАПИСИ ПОТОКА АУДИТА, которая живёт срок хранения потока и уезжает к внешнему получателю. Для второго носителя дерево выбрало строже, и выбрало до нас.

Чего перечень НЕ содержит и почему ¶

Ключа `name` в нём нет, хотя проба пользовательского события требует его отсутствия. Причина — предмет: в нагрузке роли, группы и реестра `name` есть имя РЕСУРСА, а не человека, и оно там законно (пять мест дерева). Запрет по имени ключа, верный для одного вида события и неверный для пяти, гейтом дерева быть не может; держит его проба СВОЕГО события, где известно, чьё это имя.

Формы построения нагрузки — перечислены ВСЕ, и каждая доказана ¶

Распознаватель, не знающий одной из форм, не даёт ни красного, ни зелёного — он МОЛЧИТ, и записанное в этой форме оказывается вне наблюдения, оставаясь на вид покрытым. Формы поэтому измерены по дереву, а не придуманы:

FormFieldLiteral    `Payload: map[string]any{…}` — литерал прямо в поле;
FormHelperDecl      `func …Payload(…) map[string]any { … }` — построитель,
                    чьи ключи живут у ОБЪЯВЛЕНИЯ, а не у вызова;
FormIndexAssign     `p["ключ"] = …` — ключ, добавленный ПОСЛЕ литерала;
                    литеральный разбор без него теряет условные ключи;
FormFieldIdent      `Payload: p`, где `p` собран выше в той же функции.

Поле `EventPayload` формой НЕ является и в счёт не идёт: это уже сериализованные байты у писателя, а не место построения. Разбор, судящий по подстроке `Payload:`, принял бы его за пятую форму — и судил бы место, где ключей нет вовсе.

Значение поля `Payload`, не сводящееся ни к одной форме, разбор объявляет НЕПРОЗРАЧНЫМ и печатает числом. Ноль непрозрачных — вердикт обхода, а не свойство записи: пока их ноль, «личных ключей нет» сказано обо всех местах.

Чем держится способность упасть ¶

`audit_payload_pii_injection_test.go` — инъекция в обе стороны по КАЖДОЙ форме и по КАЖДОМУ объявленному ключу: дефект находится с координатой, законный близнец (тот же ключ в НЕ-нагрузочном литерале, идентификатор вместо личного поля) молчит.

authz_wrapper_outcome_lanes.go — булева ОБЁРТКА вопроса о правах не вызывается там, где у неё есть парная форма с исходом (задача kacho#1045).

Порт с монорепо (`internal/repohygiene/authzwrapperoutcomelanes_test.go`, снят вынесением службы — `kacho#2597`). В кaname живёт как минимум одна такая пара: `authzguard.SubjectIsClusterAdmin` (bool) рядом с `SubjectIsClusterAdminE`/`SubjectIsClusterAdminPlainE` (bool, error) — то есть предмет ЖИВ, и гейт переносится. Изменилось: перечень «прод-корней» и путь модуля читаются из СВОЕГО дерева, а не из монорепо; имя гейта сохранено дословно.

Что ищется — СВОЙСТВО, и оно ВЫВОДИТСЯ ИЗ ДЕРЕВА ¶

Перечня имён у этого гейта нет и быть не может: пары выводятся —

F  — экспортированная функция пакета, возвращающая РОВНО `bool`;
FE — функция ТОГО ЖЕ пакета с именем `F`+`E` либо `F`+`PlainE`,
     возвращающая `(bool, error)`.

Есть пара ⇒ автор пакета УЖЕ объявил, что у этого вопроса три исхода, а не два. Значит вызов булевой половины из ЧУЖОГО пакета — выбор, а не необходимость, и выбран он в пользу формы, из которой «хранилище не ответило» достать нельзя.

Граница названа честно ¶

Вызовы ВНУТРИ пакета, объявившего пару, под гейт не подпадают: там булева половина и есть тело обёртки. Узнавание идёт по ИМЕНИ ИМПОРТА файла, а не по типам.

basic_credential_proof_run.go — доказательство формы базового удостоверения обязано ПРОИЗВОДИТЬСЯ ПРОГОНОМ, а не просто лежать в дереве (`PRO-Robotech/kacho#1253`).

Порт с монорепо (`internal/repohygiene/basiccredentialproofrun_test.go`, снят вынесением службы — `kacho#2597`). Осталось дословно: имя функции гейта, сам разбор `run:`-тел workflow и текст находки. Изменилось: пути без префикса `services/iam/`, конвейер — `.github/workflows/` СВОЕГО репозитория.

Предмет ¶

Во всём сквозном прогоне не было НИ ОДНОГО зелёного утверждения, читающего секрет базового удостоверения из УСПЕШНОГО ответа. Проверка, которую никто не зовёт, ничего не производит: её зелёное существует только в чужой голове.

Читается ИСПОЛНЯЕМАЯ часть, а не текст ¶

YAML разбирается, берутся тела `run:`, и из них выбрасываются строки оболочечных комментариев. Гейт по подстроке краснел бы на собственном объяснении и зеленел бы на шаге, откуда вызов сняли, а комментарий оставили.

binding_insert_writes_ledger.go — разбор «каждая вставка привязки доступа пишет ведомость выпущенных кортежей той же функцией» (kaname#670, класс kaname#665).

Предмет ¶

Снятие выдачи — штатное (`AccessBinding.Delete`) и дренажом области при удалении проекта или аккаунта (`shared.RevokeBindingsInScope`) — снимает РОВНО записанное в ведомости выдачи (`access_binding_emitted_tuples`). Выдача, вставленная без ведомости, уходит строкой, а кортежи, которые она выпустила, остаются фактами модели прав на объект, которого больше нет. Дважды этот класс жил молча (самовыдача заведения — #665, выдача приглашения — #670), потому что пустая ведомость неотличима от «выпускать было нечего».

Что судится ¶

Узел вызова `<…>.AccessBindingsW().Insert(…)` — вставка строки выдачи — и узел вызова `<…>.InsertEmittedTuples(…)` в ТОЙ ЖЕ самой внутренней функции (объявление либо литерал функции: вставка приглашения стоит в замыкании транзакции). Вставка без записи ведомости в своей функции — находка с координатой. Слово в комментарии или строке находкой не становится: судится узел вызова, а не текст.

Граница названа ¶

Разбор не следит за вызовами между функциями: ведомость, записанная вспомогательной функцией, которую зовёт вставляющая, гейтом не видна и даст находку. Это осознанно — запись ведомости и вставка обязаны стоять рядом, в одной транзакции и в одном месте чтения.

build_stamp_word.go — разбор объявления строковой константы синтаксическим деревом, а не текстом.

Предмет ¶

Слово «сборка штамп не проставила» стоит в прозе (шапках, документации) не реже, чем в объявлении. Поиск по подстроке нашёл бы собственное объяснение и остался бы зелёным при разошедшихся объявлениях — узел объявления константы судится вместо строки файла ровно по этой причине.

carried_coordinate_ledger.go — разбор ведомости координат, переносимых до снятия внешнего провайдера аутентификации клиента (приёмка F2, сценарий F2-46, §9.4).

Порт с монорепо (`internal/repohygiene/carriedcoordinateledger.go`, снят вынесением службы — `kacho#2597`). Осталось дословно: имя функции гейта (`TestCarriedCoordinateLedgerExpiresOnItsOwn`), сам разбор и словарь исходов. Изменилось: путь ведомости без префикса `services/iam/` (`docs/engineering/architecture/client-assertion-carried-over-coordinates.md`) и область зеркальной колонки — раньше сужалась до `services/iam/` внутри монорепо, теперь это ВЕСЬ репозиторий службы (у неё нет больше соседей по дереву). Ведомость службы, будучи скопирована целиком, несла координаты со старым префиксом `services/iam/` — они не резолвились НИ ОДНА (кросс-репо staleness, а не намеренное послабление); исправлено тем же изменением, которым перенесён гейт.

Предмет ¶

Фаза F2 завела принимающую сторону и ничего не сносит. У каждой координаты, дожившей до снятия внешнего провайдера, обязан быть назван исход из закрытого словаря; четвёртого — «осталось как есть, потому что не заметили» — не существует. У исхода «оставлено» обязан быть ПРЕДИКАТ СНЯТИЯ.

Гейт двусторонний ¶

• ПОЛНОТА: координата, живущая в дереве и не названная ведомостью, — находка;
• САМОИСТЕЧЕНИЕ: запись, чьей координаты в дереве больше нет, — находка.

Кросс-репо координата — вне суждения ОБОИХ сторон ¶

Ведомость несёт координаты не только своего репозитория (напр. `services/registry/...` — сервис реестра остался в монорепо продукта, а не уехал со службой доступа). Такую координату этот гейт не проверяет НИ ПОЛНОТОЙ, ни САМОИСТЕЧЕНИЕМ: он не может ни подтвердить, ни опровергнуть существование файла в ЧУЖОМ репозитории. «В скоупе» решает первый сегмент пути — совпадает с одним из ФАКТИЧЕСКИ отслеживаемых верхних каталогов своего дерева.

catalog_check_wiring.go — сверка каталога прав с копией края обязана быть ЗВАНОЙ конвейером, а не просто существующей целью Makefile.

ПРЕДМЕТ У ГЕЙТА ФОРМА-ПРОВЕРКА, А НЕ ФОРМА-СИНХРОНИЗАЦИЯ (kaname#15) ¶

Портированная редакция требовала вызова `sync-permission-catalog` — и была НЕИСПОЛНИМА by construction: эта цель ПИШЕТ файл. Задание, правящее дерево, вердикта о дереве не даёт: «копии совпали» после собственного `cp` истинно всегда, а рабочая копия ранера уезжает от коммита. Поэтому решение записано в самом рецепте, а гейт судит его: конвейер зовёт `check-permission-catalog` (ничего не пишет, годна обеим посадкам) и НЕ зовёт пишущую форму, которая объявлена ручной операцией выпуска.

Отсюда и переименование пробы: портированное имя было `TestCatalogSyncTargetIsCalledByThePipeline`, и после смены предмета оно утверждало бы неверное — цель синхронизации конвейером не звана НАМЕРЕННО.

Вторая половина того же решения — ОТКУДА БЕРЁТСЯ КОПИЯ КРАЯ. Замер, которого у портированной редакции не было: копия края приезжает в самостоятельный клон МОДУЛЕМ-ПИНОМ платформы (`go.mod`), поэтому сверка исполнима и здесь, а не только в полном чекауте монорепо. Предикат и его граница — в рецепте, у самой цели.

Порт с монорепо (`internal/repohygiene/catalogcheckwiring_test.go`, снят вынесением службы — `kacho#2597` с заявлением «предмет уехал вместе со службой»). Заявление НЕВЕРНО для kaname: своя половина цепочки уехала СЮДА — цель `sync-permission-catalog` объявлена в корневом Makefile службы (`GATEWAY_CATALOG`/`IAM_CATALOG_EMBED`), и её собственный комментарий говорит: «Копия каталога у iam ОБЯЗАНА побайтово совпадать с копией шлюза». Предмет, которым монорепошный гейт стерёг ПРОВЯЗКУ, здесь тот же самый, только половина цепочки живёт по обе стороны границы репозитория.

Здесь СУЖЕННАЯ форма монорепошного гейта: он спрашивал достижимость через ОБЩИЙ анализатор рецептов Makefile (`gatetargetwiring.go`, там же судят гейты `services/*`), которого в этом репозитории нет и заводить его ради двух целей с нулём зависимых — избыточно (ни у `check-permission-catalog`, ни у `sync-permission-catalog` сегодня НЕТ ни одной цели-потребителя внутри Makefile: обе стоят сами по себе, реаситься до них нечему). Поэтому проверяется прямая достижимость: зовёт ли ХОТЬ ОДИН шаг конвейера имя цели напрямую (`make check-permission-catalog` либо `make -C … <цель>`). Появится цель-потребитель — предикат обязан расшириться до реситься-графа, как в монорепо; это отдельное изменение, а не молчаливое сужение.

Чем этот гейт НЕ является ¶

Он не сверяет копии побайтово — это отдельный предмет, и живёт он внутри рецепта `check-permission-catalog`. Предмет ЭТОГО гейта — ПРОВЯЗКА: существует ли у сверки вызывающий среди того, что исполняется САМО, и не зовёт ли конвейер пишущую форму вместо неё.

catalog_copy_parity.go — сверка двух копий каталога прав: своей и копии края.

───────────────────────────────────────────────────────────────────────────── ЧТО ЗДЕСЬ ИЗМЕНИЛОСЬ И ПОЧЕМУ (kaname#79)

Прежняя сверка была `cmp` двух файлов с ОДНОНАПРАВЛЕННОЙ посылкой: «источник истины один — копия края», и единственный совет находки — позвать `sync-permission-catalog`, то есть ПЕРЕПИСАТЬ свою копию копией края.

Посылка держалась, пока оба дерева линковали ОДИН фундамент. Она перестала держаться, когда фундамент переименовал свой контракт: полное имя метода у контракта, живущего в библиотеке, задаёт ВЕРСИЯ БИБЛИОТЕКИ, которую линкует дерево, а версии у деревьев разные. Тогда расхождение означает не «наша копия отстала», а «отстала копия края», и прежний совет в этом направлении ВРЕДЕН:

перепись 2026-09-14 (`corelib@v1.7.0` переименовал форму подписки;
платформа на своём стволе пинила `corelib@v1.5.0`):
  записей у каждой стороны   338
  расходится                   1  — только сегмент пакета в `fqn`
  остальные поля записи       совпадают дословно

Этот случай ЗАКРЫТ 2026-09-15: платформа подняла пин, копии снова совпадают побайтово, и запись ведомости, объяснявшая расхождение, снята — разбор у самой ведомости ниже. Довод о направлении оставлен, потому что он о КЛАССЕ: следующее переименование в фундаменте даст ту же картину.

ЧЕМ ВРЕДЕН СОВЕТ — сказано ровно настолько, насколько измерено.

Наша копия индексируется ПО `fqn` (`internal/apps/kaname/seed/permissions.go`, `byFQN`), и по нему же её спрашивают о ПОЛНОМ ИМЕНИ МЕТОДА, с которым вызов пришёл на СВОЙ слушатель (`internal/authzguard/acr_floor.go`, `requiredACRMin` → `strings.TrimPrefix(fullMethod, "/")`; `public_caller_policy.go`). Служба линкует `corelib@v1.7.0`, поэтому вызов приходит как `/corelib.subscription.…/Subscribe`. Записав сюда имя отставшего края, мы положили бы в посев имя метода, которого этот двоичный файл НЕ СЛУЖИТ, — мёртвая запись, а у служимого глагола записи бы не стало.

ГРАНИЦА ЭТОГО ДОВОДА НАЗВАНА, ЧТОБЫ ЕГО НЕ ПЕРЕСКАЗАЛИ ШИРЕ. У пола ACR промах поиска даёт исход «требования нет» (правило 3 в `allow`), но ДО него стоит правило 1: глагол обязан быть во фронтируемом краем наборе (`authzguard.GatewayFrontedInternalRPCs`). Перепись 2026-09-14: глагола подписки в этом наборе НЕТ, значит сегодня промах на нём ИНЕРТЕН. Довод латентный, а не наступивший, и записан он так намеренно: наступит он тогда, когда глагол во фронтируемый набор внесут, — и заметить это будет нечем.

───────────────────────────────────────────────────────────────────────────── ЧТО СВЕРКА УТВЕРЖДАЕТ ТЕПЕРЬ

Норма прежняя и НЕ ослаблена: копии — ОДИН порождённый артефакт. Изменилось то, что у равенства появились ЧЕТЫРЕ закрытых перечня объявленных окон — переименования фундамента, записи службы, ждущие края (kaname#181), глаголы, снятые службой, которые край ещё называет (kaname#564), и записи, у которых служба сменила значение одного поля (kaname#720), — и каждая запись обязана держать себя САМА в обе стороны. Остаток после их применения — находка с прежним текстом.

Сравнение остаётся ПОБАЙТОВЫМ, а не «по смыслу»: файл режется на блоки записей по своей же форме, сборка блоков обязана дословно воспроизвести исходный файл (иначе форма файла сменилась — тоже находка), переименование применяется к блоку края, блоки пересортировываются по `fqn` (переименование двигает запись в перечне) и сравниваются дословно.

───────────────────────────────────────────────────────────────────────────── ЧЕГО ЭТА СВЕРКА НЕ ЗАКРЫВАЕТ — сказано прямо

1. Она НЕ знает пина фундамента у края: в конвейере копия края приезжает ВЫБОРКОЙ одного каталога, `go.mod` платформы в ней нет. Поэтому направление расхождения не ВЫЧИСЛЯЕТСЯ, а ОБЪЯВЛЯЕТСЯ ведомостью ниже, и держится ведомость самоистечением, а не доверием.
2. Она НЕ судит, верно ли переименование по существу. Она судит, что оно объявлено, что обе его стороны в деревьях ЕСТЬ и что кроме него не разошлось ничего.
3. Провязка сверки к конвейеру — предмет `catalog_check_wiring.go`, не этот.

catalog_covers_contract.go — своя копия каталога прав покрывает СВОЙ контракт.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ (kaname#184)

Копия каталога прав в этом дереве — порождённый артефакт: её строки край порождает из контрактов всех доменов, и строки ЭТОЙ службы — из её же контракта по пину модуля. Сверка копий (`catalog_copy_parity.go`) судит равенство ДВУХ копий, и только его; о том, покрывает ли наша копия наш собственный контракт, она не утверждает ничего — пока край пинит ревизию без нового глагола, обе копии его не несут, и сверка зелена.

Ровно так строка `InternalHumanSessionService/Resolve` осталась без предмета: контракт объявил глагол (kaname#179), обе копии молчали, обе сверки были зелены, и красное ждало подъёма пина платформой — то есть наступило бы в ЧУЖОМ дереве, чужим прогоном, на всяком следующем PR этой службы.

───────────────────────────────────────────────────────────────────────────── ЧТО УТВЕРЖДАЕТСЯ — В ОБЕ СТОРОНЫ, И ТОЛЬКО О СВОЁМ

1. У каждого RPC, объявленного файлами контракта службы, есть строка в копии, и строка совпадает с аннотациями метода по каждой оси, которую каталог несёт. Строка без источника — находка: она пережила свой RPC.
2. Строки ЧУЖИХ доменов не судятся вовсе: их источник живёт в чужом дереве, и «строка без RPC» для них означает лишь, что стабы чужого домена в этот двоичный файл не слинкованы. Судить их отсюда было бы утверждением о дереве, которого здесь нет.

Перечень своих пакетов ВЫВОДИТСЯ из обхода (пакет каждого файла контракта), а не выписывается: выписанный был бы вторым объявлением того же предмета.

Обход, не нашедший НИ ОДНОГО метода, — не «ноль находок», а ТРЕТИЙ ИСХОД: стабы не слинкованы либо приставка пути названа неверно, и гейт в таком состоянии не утверждает ничего. То же — пустая копия.

───────────────────────────────────────────────────────────────────────────── ЧТО ДЕЛАТЬ НА НАХОДКЕ — И ПОЧЕМУ НЕ РУКАМИ

Строка ПОРОЖДАЕТСЯ генератором края над контрактом службы (в дереве платформы `gateway/scripts/gen-permission-catalog.sh` с модулем службы, разрешённым на нужную ревизию), кладётся в копию и, пока край её не несёт, объявляется записью ведомости ожидающих края (`CatalogPendingEntries`, `catalog_copy_parity.go`). Правка JSON руками исходом не является: копия — порождаемый артефакт, и рукописная строка разошлась бы с тем, что край породит по пину, ровно на первой сверке после подъёма.

catalog_writer_lock.go — всякий прод-писатель строк `kaname.catalog_*` берёт глобальный транзакционный замок каталога (приёмка `docs/engineering/acceptance/plan-confirms-what-apply-withdraws.md` §7, объём О11, держатель Г1; kacho#1034).

Порт с монорепо (`internal/repohygiene/catalogwriterlock.go`, снят вынесением службы — `kacho#2597` с заявлением «обход служб жив, но исполняемых операторов записи в этот каталог ноль». Заявление было верно ТОЛЬКО для монорепо (там дерево служб доступа исчезло) — приёмка сама называет отсутствие держателя пунктом Н5 и требует его. Механизм в дереве службы ЖИВ дословно: `internal/repo/kaname/pg/catalog_writer.go` несёт `CatalogLockKey`/`LockCatalog` (`pg_advisory_xact_lock`) и три `UpsertModule`/`UpsertResource`/`UpsertVerb` на том же получателе (`catalogWriter`) — единица суждения по-прежнему сходится. Осталось дословно: весь алгоритм (регулярки, разбор, единица суждения, тексты находок). Изменилось: путь-константа без префикса `services/iam/`, обход — от корня СВОЕГО репозитория целиком (предмет запрета — «ВСЯКИЙ прод-писатель», не только сегодняшний).

Предмет ¶

Подтверждение применения (отпечаток состояния модуля) есть CAS ТОЛЬКО потому, что между чтением отпечатка и записью строк не может встать второй писатель. Обеспечивает это не сравнение, а `pg_advisory_xact_lock`, взятый В ТЕЛЕ КАКОГО-ЛИБО МЕТОДА писателя (гейт не проверяет порядок — это держит интеграционная проба, не разбор).

Единица суждения — ТИП (получатель метода), а не файл и не пакет-вызывающий ¶

Замок и запись могут лежать в РАЗНЫХ методах ОДНОГО получателя в ОДНОМ пакете (как здесь: `LockCatalog` и `UpsertModule` — оба методы `catalogWriter` в `internal/repo/kaname/pg`) — тогда они СХОДЯТСЯ в одну единицу суждения и гейт молчит. Замок, взятый ЧУЖИМ пакетом (например, вызывающим use-case, держащим порт `CatalogWriter`), этот гейт НЕ видит — он не о том, кто ЗОВЁТ замок, а о том, что писатель СПОСОБЕН его взять (несёт метод, который это делает).

census_fixture_producer.go — проба, которая пересчитывает ВСЕ строки таблицы, не вправе наполнять её сама в обход производителя.

Порт с монорепо (`internal/repohygiene/censusfixtureproducer_test.go`, снят вынесением службы — `kacho#2597`). Гейт уже цитируется ШЕСТЬЮ местами в дереве службы (прод-код `internal/repo/kaname/pg/scalegrid/{census,seed}.go` и пробы `relverdict`/`parentedge`) как «гейт дерева `TestCensusFixturesSeedThroughTheProducer`» — предмет жив, и цитаты уже ждут держателя. Осталось дословно: имя функции гейта, разбор и текст находки. Изменилось: пакет-производитель узнаётся ОДНОЙ величиной (каталог = хвост импорта: у самостоятельного модуля службы расхождения, из-за которого монорепо держало ДВЕ константы, больше нет), обход — от корня СВОЕГО модуля, без сегмента `services/iam`.

Предмет ¶

Утверждение вида «у каждой строки зеркала есть цепь предков» — квантор по всему множеству. Если множество наполнила сама проба прямой записью в таблицу, утверждается свойство ФИКСТУРЫ: она положила ровно то, что потом пересчитала. Такая проба остаётся зелёной, даже если производитель перестал писать цепь ЦЕЛИКОМ.

Единица суждения — ПАКЕТ, а не файл ¶

В Go все `_test.go` каталога с одним именем пакета собираются в один бинарь и делят помощников. Проба, сеющая через помощника из соседнего файла, сеет через производителя ровно так же.

Разбор идёт по СТРОКОВЫМ ЛИТЕРАЛАМ, а не по тексту файла ¶

Текстовый поиск нашёл бы обе примеет и в комментарии, объясняющем эту же дисциплину (в том числе в шапке самой пробы полноты).

ceremony_surface.go — гейт ЕДИНСТВЕННОСТИ ПОВЕРХНОСТИ церемонии (kaname#320; приёмка LINE-A-1, сценарий LINE-A-1-23: «эндпоинты монтируются на внешней поверхности выдачи и НИГДЕ больше»).

Что судится ¶

Два свойства, и «НИГДЕ больше» держат только оба вместе.

• ПУТЬ: для каждой координаты — на скольких ПОВЕРХНОСТЯХ процесса она резолвится. Не сколько раз её упомянули и не сколько вызовов Handle её назвали: обработчик, отданный двум поверхностям, регистрируется один раз и резолвится дважды; делегирование поддерева («/iam/v1/» → чужой мультиплексор) не называет координату вовсе и резолвит её.
• ОБРАБОТЧИК: конечная точка, до которой координата доходит на своей поверхности, не достижима ни на одной другой поверхности ни под каким путём. Эндпоинт выдачи, смонтированный на внутренней поверхности под путём «/internal/client-token», путём координаты там не резолвится — и всё же смонтирован. Тождество конечной точки — место рождения её значения, без копий по местам вызова: второй экземпляр того же конструктора на чужой поверхности — тот же эндпоинт. Обработчик координаты, не прослеженный до значения, — находка, а не молчание.

Как выводится, а не выписывается ¶

• ПОВЕРХНОСТЬ — объявление servicecontract.Surface в модуле службы: имя, досягаемость, обработчик. Перечня слушателей в гейте нет.
• ОБРАБОТЧИК поверхности прослеживается до мест рождения мультиплексоров сквозь переприсваивания, возвраты фабрик, поля, обёртки (ceremony_surface_flow.go).
• РЕГИСТРАЦИЯ — вызов Handle/HandleFunc на мультиплексоре net/http, Handle/HandlePath на мультиплексоре шлюза и http.Handle на общем мультиплексоре процесса, где бы в бинаре он ни стоял; путь сводится к значению обратным разбором (ceremony_surface_resolve.go). Опознаётся ВЫЗЫВАЕМЫЙ метод, а не синтаксис вызова: прямой выбор, значение метода, выражение метода, метод интерфейса и параметра типа, метод, продвинутый из встроенного поля, — один и тот же метод мультиплексора.
• «РЕЗОЛВИТСЯ» решает НАСТОЯЩИЙ мультиплексор: для каждого места рождения собирается http.ServeMux (или ServeMux шлюза) из выведенных образцов, и запрос координаты проходит его так же, как прошёл бы в процессе: метод и хост в образце, подстановки, хвостовой слэш, перенаправление. Своим разбором образца вердикт не выносится: образец расщепляется лишь затем, чтобы перечислить хосты, на которые идёт запрос, и формы переписи.

Чем гейт не судит (границы, названные прямо) ¶

• Правила HTTP контракта (.proto) читаются через порождённую привязку шлюза; её сверку с контрактом держит задание конвейера generate-diff.
• Путь, который задаёт оператор (поле, заполняемое декодером настройки), значения не имеет: он — лист ведомости с причиной, не пропуск.
• Маршрут, решаемый по пути запроса в теле обработчика (сравнение, switch, выбор из карты, функция сопоставления над путём и над значениями, в которые он течёт; куда выведение доходит и где кончается, названо в ceremony_surface_manual.go), и мультиплексор, отданный чужому коду, гейт не моделирует — и потому краснеет на них, а не молчит.
• Значения, прошедшие через пустой интерфейс, не прослеживаются. Вызов метода регистрации через интерфейс, который реализует мультиплексор, когда хоть у одного значения получателя реализация не найдена, — находка «не прослежен», даже если другие получатели разрешились; мультиплексор, переданный аргументом методу интерфейса с таким получателем, — находка «передан методу интерфейса». Ни то ни другое не молчание.
• Регистрация, которую разбор видит, стоит в переписи: на мультиплексоре своего вида, в непрослеженных или в недостижимом коде. Вызов через интерфейс, разрешившийся лишь у части получателей, стоит в двух графах: на мультиплексорах разрешившихся и в непрослеженных.
• Маршруты, которые заводят варианты конструктора мультиплексора шлюза (runtime.With…), не наблюдаются: вариант — чужой код без переданного ему мультиплексора. Сегодня варианты корня маршрутов не заводят.
• Обработчик судится по ЗНАЧЕНИЮ, а не по поведению: та же церемония, реализованная заново другим типом или другим конструктором, — другое значение, и её второй монтаж гейт не видит: это копия кода, а не второй монтаж того же эндпоинта.
• Монтаж обработчика на чужой поверхности судится по ВСЕМ её маршрутам, без учёта пути: эндпоинт за мультиплексором, до образцов которого запрос с этой поверхности не дойдёт, тоже считается смонтированным. Это перебор, а не недобор: гейт краснеет, а не молчит.

client_expiry_immutable.go — разбор операторов правки, разложенных по столбцам (приёмка F2, §9.4, решение §2.10).

Порт с монорепо (`internal/repohygiene/clientexpiryimmutable.go`, снят вынесением службы — `kacho#2597` с заявлением «снято вместе с предметом: таблицы user_oauth_clients в применённых миграциях дерева нет». Заявление было верно ТОЛЬКО для монорепо (там дерево служб доступа исчезло целиком) — в дереве службы обе таблицы объявлены (сегодня — в консолидированной `internal/migrations/0001_initial.sql`), с колонкой `expires_at`. Осталось дословно: имя функции гейта, сам разбор и текст находки. Изменилось: пути без префикса `services/iam/`.

Предмет ¶

Срок клиента неизменяем после создания. На этой предпосылке стоит структурная гарантия: срок выданного токена не превышает остатка срока клиента, и проверять это на пути запроса не нужно ровно потому, что срок не двигается. Сдвинь его — и гарантия держится ничем.

Что здесь считается ПРАВКОЙ СТОЛБЦА ¶

UPDATE t SET expires_at = $2 WHERE id = $1   ← правка: столбец назван в SET
INSERT INTO t (…, expires_at) VALUES (…)     ← СОЗДАНИЕ: срок назначается
SELECT expires_at FROM t WHERE id = $1       ← чтение

Чего разбор НЕ видит — названо, а не спрятано ¶

1. оператор, собранный из частей во время выполнения;
2. правка через функцию базы или триггер, а не оператором `UPDATE`;
3. `UPDATE` без имени таблицы в том же литерале.

client_truth_exclusion_form.go — извлечение для гейта «форма взаимоисключения, НАЗВАННАЯ оператору, есть та, которой оно держится» (задача #17, порт-ПОЛОВИНА семейства `clienttruth_kaname_exclusion_form` с монорепо `internal/repohygiene/clienttruth_kaname_exclusion_form.go`, снятого выносом службы — `kacho#2597`).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Назваться на публичном слушателе Kaname можно двумя способами: предъявить удостоверение самому либо получить личность от нашего края. Способы взаимоисключающи, и держится это ПОСТРОЕНИЕМ, а не проверкой.

Держалось оно не всегда так. Прежняя редакция требовала ОТВЕРГАТЬ запрос, несущий обе формы, — и эта проверка отвергала бы каждый запрос, проксированный нашим же краем, потому что сочетание производил он сам. Ветвь отказа снята вместе со своим предметом; страница оператора об этом узнать не могла — она не собирается и ничего не импортирует.

───────────────────────────────────────────────────────────────────────────── ДВА УТВЕРЖДЕНИЯ, И ВТОРОЕ ПОЛОЖИТЕЛЬНОЕ

A. отказ, ОБЕЩАННЫЙ страницей, обязан иметь производителя в не-тестовом коде
   читателя. Обещание без производителя — утверждение, пережившее свой
   предмет: оператор ждёт отказа, которого служба не делает;
B. пока построение живо, страница обязана НАЗЫВАТЬ его.

Второе — положительное, и это не стилистика. Отрицание («страница не говорит такого-то слова») ЗАМОЛКАЕТ при первой же переформулировке: вход, на котором оно находит нарушение, перестаёт быть представимым, а ветвь остаётся в коде и вердикт остаётся зелёным — а отличить это от исправной работы нельзя ничем, потому что обе стороны печатают ноль находок. Утверждение B умолкнуть не может: оно краснеет ровно тогда, когда объяснение исчезает.

───────────────────────────────────────────────────────────────────────────── ЧТО РАЗРЕЗ СДЕЛАЛ С УТВЕРЖДЕНИЕМ B — И ПОЧЕМУ ЭТО НЕ ОСЛАБЛЕНИЕ

Взаимоисключение держат ДВА построения, по одному на сторону провода, и разрез развёл их по репозиториям:

СНЯТИЕ у края   — край снимает арендаторское удостоверение перед пересылкой
                  за себя. Замер этого дерева: `git ls-files gateway | wc -l`
                  → 0; `git grep -l StripPresentedCredential` → 0. Живёт в
                  `PRO-Robotech/kacho`.
ОБЁРТКА у нас   — читатель предъявленного удостоверения НАКРЫВАЕТ пару
                  звеньев переданной личности и решает по её вердикту, а не
                  становится с ней в цепочку. Живёт ЗДЕСЬ.

Предок брал премисой первое, потому что оба лежали в одном дереве. Здесь премисой берётся ВТОРОЕ — наша половина построения, и она судится тем же разбором, что и всё остальное.

Это НЕ ослабление предмета, а смена ОПЕРАНДА ПРЕМИСЫ: утверждение B осталось прежним («построение живо ⇒ страница его называет»), сменилось то, чем доказывается «живо». Судить снятие у края отсюда было бы можно только чтением чужого репозитория с диска — тогда вердикт стал бы свойством того, что случайно лежит в кеше машины прогона, а не свойством коммита ни одного из двух деревьев.

───────────────────────────────────────────────────────────────────────────── ПОЧЕМУ ОБЁРТКА — ИМЕННО ПОСТРОЕНИЕ, А НЕ ПРОВЯЗКА

Носитель личности платформы устроен так, что снятие имеет приоритет над любым последующим назначением. Читатель, поставленный ПОСЛЕ пары, назначил бы вызывающего, и назначение молча не доехало бы до обработчика. Поэтому читатель прогоняет пару САМ и решает по её вердикту — решение о том, КТО звонит, принимается в одном месте, и сочетания двух форм не возникает by construction.

Разомкни обёртку — и взаимоисключение перестаёт держаться построением на нашей стороне, то есть страница начинает объяснять механизм, которого нет. Ровно это утверждение B и стережёт.

───────────────────────────────────────────────────────────────────────────── РАСПОЗНАВАТЕЛИ — ЧЕМ СУДЯТ, И ПОЧЕМУ НЕ ПОДСТРОКОЙ ПО ФАЙЛУ

Сторона ДЕРЕВА судится РАЗБОРОМ, а не текстом, и это несущее: файл читателя несёт НАДГРОБИЕ снятой ветви — связный абзац по-русски о том самом сочетании форм, — и проверка по подстроке объявила бы живым ровно то, что снято: предикат, судящий СЛОВО вместо УЗЛА, находит собственное объяснение. Поэтому считаются УЗЛЫ-ВЫЗОВЫ и литеральные аргументы, а комментарии не читаются вовсе.

Сообщение отказа собирают конкатенацией (`refuse("… " + err.Error())`), поэтому разбор аргументов идёт по дереву выражения: читатель одиночного литерала такое сообщение НЕ УВИДЕЛ БЫ — то есть дал бы молчание вместо вердикта.

Сторона СТРАНИЦЫ судится по абзацу — прозы иначе не судить, и это сказано прямо, а не спрятано. Смягчает три вещи:

• корень предмета один и это ИМЯ предмета (`взаимоисключ`), а не оборот речи: переформулировать объяснение, не назвав предмета, значит перестать его объяснять, и это ловит утверждение B;
• регистр снимается. Страница пишет `ОБЕ` прописными, и предикат, читающий написанное, промолчал бы на живом производителе;
• вердикт выносится ПОАБЗАЦНО. Соседний абзац той же страницы законно говорит об отказе — о единообразии его текста, — и файл целиком читать нельзя: отказ соседа зачёлся бы обещанием предмета.

client_truth_module_set.go — извлечение для гейта «перечень модулей платформы, названный клиентской поверхностью, ПОЛОН» (задача #17, порт семейства `clienttruth_iam_moduleset` с монорепо `internal/repohygiene/clienttruth_iam_moduleset.go`, снятого выносом службы — `kacho#2597`).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ — и почему цена неполноты в БЕЗОПАСНОСТИ, а не в удобстве

Набор модулей закрыт, и его единственный источник — приставки ключей закрытой таблицы типов объекта (`objectTypes` пакета `internal/authzmap`). Модуль — то, чем клиент выражает грант (`Rule.module`).

Перечень, назвавший МЕНЬШЕ, чем принимает сервер, читается клиентом как «тонко выдать доступ к недостающему домену НЕЛЬЗЯ», а единственный документированный выход при таком чтении — системная роль на весь уровень, то есть заведомое расширение доступа. Клиент платит доступом за нашу опечатку в прозе.

Замер, на котором семейство заведено (kacho#1627): сервер принимал ШЕСТЬ модулей, а называли ЧЕТЫРЕ и справочная страница ролей, и комментарий поля контракта; шапка функции членства рядом называла ПЯТЬ. Разошлись не документ с кодом, а ТРИ места об одном предмете, из которых верно было ни одно.

───────────────────────────────────────────────────────────────────────────── ЧТО ИЗМЕНИЛ ПЕРЕЕЗД, А ЧТО НЕТ

Предмет НЕ изменился. Изменились координаты: приставка `services/iam/` ушла вместе с монорепо, поверхности стали `docs/content` и `proto/kaname/cloud/iam` (копия контракта приехала сюда с `kaname#49`), объявление набора — `internal/authzmap`. ОБА операнда лежат в этом дереве, поэтому семейство судится здесь целиком, а не половиной.

Прежняя посылка задачи #17 называла семейство кросс-репозиторным. Она опровергнута замером операндов: пакет объявления — 61 файл, поверхности — 68.

───────────────────────────────────────────────────────────────────────────── НАБОР ВЫВОДИТСЯ РАЗБОРОМ, А НЕ ЧТЕНИЕМ ТЕКСТА

Считаются узлы-ключи составного литерала. Имена модулей стоят и в комментариях рядом с объявлением — и в том самом абзаце, который объясняет выбор написания ключа, — поэтому предикат по подстроке краснел бы на собственном объяснении таблицы: судящий СЛОВО вместо УЗЛА находит сам себя.

Объявление разрешается по ПАКЕТУ, а не по файлу. В монорепо оно переезжало между файлами дважды (`fga_types.go` → `tables_gen.go`), и оба раза привязка к имени файла давала не находку, а «анализатор не отработал» — третью категорию, поданную как красное. Пакет и есть единица области видимости Go: package-level имя в нём ровно одно by construction, и перенос между файлами о нём ничего не меняет.

Приставка берётся до ПЕРВОЙ точки — то же разбиение, каким его делает `authzmap.SplitObjectType`. Ключ без точки модуля НЕ ДАЁТ и себя целиком не отдаёт: он не «модуль без ресурса», а ключ неверной формы, и записать его в набор значило бы объявить модулем то, чем таблица его не называет.

───────────────────────────────────────────────────────────────────────────── ЧТО СЧИТАЕТСЯ ПЕРЕЧНЕМ — И ЧЕГО ГЕЙТ НЕ СУДИТ, НАЗВАНО ЧИСЛОМ

Перечень — имена модулей в КОД-ФОРМАТИРОВАНИИ (`имя` либо <code>имя</code>), соединённые косой чертой, ТРИ и более подряд. Каждый такой перечень обязан назвать набор целиком.

1. СПАН ИЗ ДВУХ ИМЁН перечнем не считается — это законная пара («`vpc`/`compute` остаются label-selectable»). Порог в три оставлен потому, что гейт, у которого находки ложные, отключают первым. Сколько таких пар встречено — печатает перепись, а не утверждает эта шапка: прежняя редакция абзаца в монорепо называла четыре, и гейт опроверг её на первом же прогоне. Способность молчать на паре доказана инъекцией.
2. ПРОЗА без код-форматирования не судится: «модули iam, vpc и compute» распознавателю не видны. Расширение на голый текст не замерялось и потому не вводится — оно находило бы имена модулей в любом предложении, где они соседствуют законно.
3. ПОРЯДОК не судится — только состав.

comment_coordinate_layout.go — разбор комментария на ОДИН факт: называет ли он координату приставкой ЧУЖОЙ раскладки, когда та же координата лежит здесь.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Служба жила каталогом `services/iam/` внутри дерева платформы и переехала в свой репозиторий. Код переезд пережил — координаты в комментариях нет: шестьдесят с лишним мест продолжали называть файл приставкой, которой в этом дереве не существует.

Читателя это отправляет в никуда, а замер делает недействительным: предикат, списанный из комментария, печатает пусто — и пусто читается как «находок нет», а не как «искали не там».

───────────────────────────────────────────────────────────────────────────── ЧТО СЧИТАЕТСЯ НАХОДКОЙ — И ПОЧЕМУ НЕ ВСЯКОЕ УПОМИНАНИЕ ПРИСТАВКИ

Находка — координата `<приставка>/<хвост>`, У КОТОРОЙ ХВОСТ РЕЗОЛВИТСЯ В ЭТОМ ДЕРЕВЕ. Это и есть «тот же файл, названный чужим адресом».

Не находка, и всё это законно:

приставка БЕЗ хвоста — `git grep … -- services/iam`, `приставки services/iam/
                       в самостоятельном клоне нет`: проза О ПЕРЕЕЗДЕ и
                       указатель области в ЧУЖОМ дереве;
хвост с многоточием  — `services/iam/internal/…`, `services/iam/.../x.txt`:
                       это не координата, а форма записи КЛАССА путей; обе
                       записи многоточия, знак и три точки, распознаватель
                       знает сам и отдаёт вызывающему помеченными;
хвост, не резолвящийся — назван файл, которого здесь нет: он либо чужой, либо
                       снят, и это ДРУГОЙ предмет (у него нет «того же файла
                       рядом», ради которого гейт и заведён).

Сужение до резолвящегося хвоста не осторожность, а точность: без него гейт краснел бы на каждом объяснении собственного предмета — проверка, судящая по слову, находит его в комментарии, который этот же предмет объясняет, и остаётся зелёной при снятой защите. Первая редакция этого файла так и покраснела: на строке выше, где форма с многоточием объявлена законной, — распознаватель формы не знал, а знал её только резолвер, до которого многоточие не доезжало.

───────────────────────────────────────────────────────────────────────────── РАЗБОР СУДИТ УЗЕЛ КОММЕНТАРИЯ, А НЕ СТРОКУ ФАЙЛА

Строковый литерал с приставкой — ЗАКОННАЯ и действующая форма: `treeposture` резолвит координату платформы в обеих посадках by construction, и именно ею пользуются пробы объёма, отпечатки и обходчики. Гейт, судивший бы строки, потребовал бы снять работающий механизм.

contract_names_live_machinery.go — МАШИНЕРИЯ, НАЗВАННАЯ КОММЕНТАРИЕМ КОНТРАКТА, ОБЯЗАНА СУЩЕСТВОВАТЬ В ДЕРЕВЕ.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Комментарий публичного контракта читает ИНТЕГРАТОР — у него нет ни нашей истории, ни возможности перемерить. Обещание механизма, снятого миграцией, для него неотличимо от действующего.

Класс тот же, что у поля запроса, которое принимают и не читают: возможность ОБЪЯВЛЕНА, и за неё никто не отвечает. Исходов у него три — реализовать · отвергать явно · снять с контракта; «оставить как есть» исходом не является, потому что вызывающий узнаёт о несделанном только по последствиям и только в своей отладке.

Наблюдалось (kacho#2486): `rpc ForceLogout` обещал строку в очереди федеративного уведомления и рассылку по каналу, обновляющую кэш отзыва на крае. Очередь снята миграцией, канал снят вместе со своим триггером, а рядом стояла ссылка на файл контракта, которого в модуле нет. Три утверждения пережили свой предмет и продолжали читаться как действующие.

───────────────────────────────────────────────────────────────────────────── СУЖЕНИЕ ИДЁТ ПО МАРКЕРУ, КОТОРЫЙ СТАВИТ САМ КОММЕНТАРИЙ

Голый предикат «слово в обратных кавычках обязано резолвиться» негоден, и это ИЗМЕРЕНО, а не предположено: на дереве службы он даёт 239 токенов, из которых 159 не резолвятся ни в таблицу, ни в канал, ни в колонку — 66 % ложных находок. Предикат с такой долей не читают, а гейт, который не читают, не держит ничего.

Поэтому заявлением считается не токен, а токен ВМЕСТЕ С МАРКЕРОМ, который комментарий ставит сам:

`<имя>_outbox`        суффикс очереди — заявлена ТАБЛИЦА
`<имя>` table         слово сразу после — заявлена ТАБЛИЦА
`<имя>` channel       слово сразу после — заявлен КАНАЛ
NOTIFY … on `<имя>`   оборот перед    — заявлен КАНАЛ

Замер того же дерева этим предикатом ДО правки: заявлений 9, резолвятся 6 (`audit_outbox`, `fga_outbox`, `session_revocations`), не резолвятся 3 — ровно те три, ради которых гейт заведён. Ложных находок ноль.

ПОСЛЕ правки заявлений о ТАБЛИЦЕ десять и все резолвятся, а заявлений о КАНАЛЕ НОЛЬ: оба, что были, называли снятый канал и сняты вместе с ним. Ноль здесь не прячется — перепись печатает виды РАЗДЕЛЬНО, поэтому «про каналы никто не писал» отличимо от «про каналы не спрашивали». Предмет у этой ветви производим в любой момент: она оживёт от первой же строки, назвавшей канал.

───────────────────────────────────────────────────────────────────────────── ЧТО СЧИТАЕТСЯ ИСТИНОЙ

Схему называет ПРИМЕНЁННОЕ дерево миграций, а не намерение: таблицы — `CREATE TABLE`, каналы — `pg_notify`. Обе половины читаются из одного источника, поэтому снятие механизма миграцией немедленно делает заявление о нём находкой, и держать запись ради зелёного негде.

───────────────────────────────────────────────────────────────────────────── ВТОРАЯ ОСЬ: ССЫЛКА НА СОСЕДНИЙ КОНТРАКТ

Комментарий, называющий `<имя>.proto` БЕЗ каталога, называет контракт ЭТОГО модуля — так в дереве и пишут (`internal_iam_service.proto`, `user.proto`). Такое имя обязано резолвиться.

Ссылка С КАТАЛОГОМ (`kacho/cloud/validation.proto`) под ось НЕ подпадает, и это решение, а не пропуск: у платформы свой репозиторий, её файла в этом модуле нет by construction, и утверждение о чужом дереве предикатом ЭТОГО дерева не судится. Замер: таких ссылок 2, обе законны; включив их, гейт начал бы с двух ложных находок и потребовал бы ведомости прощений — то есть исключения, выданного вперёд.

deferred_work.go — СВОЯ часть гейта отложенной работы: корень обхода и виды вычитания. Разбор общий и живёт в фундаменте.

Предмет ¶

Запреты «никакого тех-долга» и «всегда production-grade, НИКОГДА MVP» стоят в корпусе правил с самого начала. В ЭТОМ дереве их не держало ничего: держателем был гейт монорепо (`PRO-Robotech/kacho:TestNoDeferredWorkInTheTree`), а после вынесения службы (`kacho#2597`, `kacho#2598`) он судит ЧУЖОЕ дерево — его зелёный о `PRO-Robotech/kaname` не говорит ничего. Четыре приёмки службы продолжали называть его своим держателем. Предмет закрыт задачей #40.

Разбор переехал в фундамент — копии здесь больше нет ¶

Словарь форм, образец, отсев по затравке, граница употребления и упоминания, обход и перепись живут в github.com/PRO-Robotech/corelib/treehygiene и приезжают сюда ПИНОМ версии. Здесь они не пересказываются — пересказ и есть то второе место об одном предмете, ради снятия которого переезд и сделан.

Цена копии была измерена, а не предположена (#51): разбор отложенной работы совпадал с близнецом платформы на 99 строках кода из 186, разбор имён — на 17 из 34, а словарь форм совпадал по составу ТОЧНО. Совпадение содержимого нарушением не смягчалось, а доказывало его: держателя у одинаковости не было ни одного, и расхождение наступило бы молча — заведут в одном дереве тринадцатую форму, в другом её не будет, и написанное в ней окажется не находкой и не чистотой, а НЕВИДИМОСТЬЮ. Ban #20 корпуса правил говорит это прямо: файл, чей владелец — другой репозиторий, в этом дереве не лежит; нужен предмет — берут пином, не нужен — файла нет.

Что осталось СВОИМ — и почему именно это ¶

Ровно две вещи, и обе суть утверждения об ЭТОМ дереве, а не об общем разборе:

• КОРЕНЬ ОБХОДА. Его даёт гейт, и это корень МОДУЛЯ службы: судить дерево платформы отсюда значило бы краснеть на чужом, а в самостоятельном клоне его нет вовсе;
• ВИДЫ ВЫЧИТАНИЯ (treehygiene.DeferralSkip). Перечень вычитаемого есть утверждение о составе конкретного дерева, и предмет каждого вида измерен ЗДЕСЬ. Готовых видов фундамент не раздаёт намеренно: раздавая их, он утверждал бы о чужом дереве то, чего не измерял, и предикат «вид без предмета» обессмыслился бы.

Что СНЯТО вместе с переездом — и чем свойство держится теперь ¶

Прежняя редакция несла отдельный вычет имени функции стандартной библиотеки: вызова через точку, синтаксически похожего на обращение к читателю кода. Ветвь НЕ перенесена, потому что она недостижима — класс границы в самом образце фундамента уже отличает вызов через точку от обращения, и инъекция фундамента это измерила: с отключённым вычетом вердикт суиты не изменился ни на одной пробе.

Свойство при этом не потеряно и держится с ОБЕИХ сторон шва: TestDeferralGateStaysSilentOnStdlibContextTODO — здесь, на кроне этого дерева; TestDottedCallIsNotADeferral — в фундаменте, на самом образце. Ослабят класс границы — покраснеют обе.

derived_id_single_source.go — разбор объявлений деривации детерминированного идентификатора (приёмка `docs/engineering/acceptance/roles-come-as-data-not-migrations.md` §3.3; приёмка `seed-identity-names-its-own-service.md` §6, держатель `TestDeterministicIDDerivationIsDeclaredOnce`).

Предмет ¶

Идентификатор системной роли, служебной учётки модуля и связки OAuth есть функция ИМЕНИ: применённые миграции адресуют строки выражением `'<префикс>' || substr(md5('<имя>'), 1, 17)`, и на эти идентификаторы ссылаются выданные права. Вторая копия формулы разойдётся с первой МОЛЧА — и разойдётся ровно там, где обе отвечают «идентификатор вычислен»: полученное значение остаётся синтаксически верным и перестаёт находить строку. Наблюдаемо это только по отказу в доступе у арендатора, у которого право не отзывали.

Порт с монорепо (`internal/repohygiene/derivedidsinglesource.go`, снят вынесением службы — `kacho#2597`): формула не переехала с кодом целиком, а была написана заново рядом с единственным домом — `internal/domain/derived_id.go`, чей собственный комментарий уже называет этот гейт держателем и ожидает его присутствия. До этой правки объявление не охранялось ничем: единственность была фактом дня, а не удержанным свойством.

Что здесь считается ОБЪЯВЛЕНИЕМ ¶

Файл прод-дерева, импортирующий `crypto/md5`. Иных потребителей MD5 в этом продукте нет и быть не должно: как примитив защиты MD5 запрещён (сам импорт в доме несёт отметку `#nosec G501`), а как контрольная сумма он здесь не применяется — значит всякое его вычисление есть деривация идентификатора.

Распознаватель знает ВСЕ формы импорта by construction ¶

Он читает ПУТЬ импорта из разобранного дерева, а не имя пакета в тексте, поэтому псевдоним (`md5b "crypto/md5"`), точечный (`. "crypto/md5"`) и пустой (`_ "crypto/md5"`) импорты опознаются одинаково. Упоминание пути в комментарии или в строковом литерале импортом НЕ является — разбор судит узел, а не подстроку.

Чего разбор НЕ видит — названо, а не спрятано ¶

1. **своя реализация MD5 руками** — развёрнутый алгоритм без импорта. Это другой класс, и ловит его обзор, а не этот гейт;
2. **вычисление на стороне базы** — `md5()` в тексте миграции. Это ВТОРАЯ сторона равенства, а не вторая копия Go-функции, и этот гейт её не судит.

doc_header_names_its_declaration.go — разбор шапок объявлений на ОДИН факт: то ли объявление названо шапкой, над которым она стоит.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

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

Отвязывается она одним движением — между шапкой и её объявлением вставляют новое объявление со СВОЕЙ шапкой, а пустая строка между двумя блоками теряется. Go склеивает соседние строки комментария в ОДНУ группу, и вся она достаётся объявлению снизу. Тогда `go doc` печатает чужую шапку у одного имени и НИ ОДНОЙ у другого — при том что текст обеих на месте и дословно верен.

Второй путь тот же по исходу: объявление переименовали, шапку не тронули.

Почему это не косметика. Читатель, которому шапка уже ОТВЕТИЛА, что перед ним, дальше не проверяет — ровно как с комментарием о защите (`guard_named_in_comment.go`). Наблюдалось на посадочной настройке: шапка `APIServerConfig` с разбором двух форм адреса слушателя стояла над `SubscriptionConfig`, а у самой `APIServerConfig` шапки не было вовсе (kaname#118). Перепись по прод-дереву нашла тот же класс ещё в 22 местах.

───────────────────────────────────────────────────────────────────────────── ЧТО СЧИТАЕТСЯ ШАПКОЙ — ФОРМА НАЗВАНА, А НЕ ПОДРАЗУМЕВАЕТСЯ

Шапкой считается первая строка группы комментария вида

Имя — текст      (тире, длинное)
Имя – текст      (тире, среднее)
Имя - текст      (дефис)

где «Имя» — идентификатор Go. Разделитель обязателен: без него первое слово прозы («Package», «Returns») стало бы находкой на ровном месте.

───────────────────────────────────────────────────────────────────────────── ФОРМЫ ОБЪЯВЛЕНИЯ ПЕРЕЧИСЛЕНЫ ПОИМЁННО

Форма, о которой распознаватель не знает, даёт не красное и не зелёное, а МОЛЧАНИЕ: объявление уезжает вне наблюдения. Читаются ВСЕ формы, у которых шапка вообще бывает:

func F(…)                     — FuncDecl
func (r T) M(…)               — FuncDecl с получателем; имя — метода
type T …                      — GenDecl с одним TypeSpec, шапка на GenDecl
type ( A …; B … )             — блок; шапка на КАЖДОМ TypeSpec отдельно
const C = … / var V = …       — GenDecl с одним ValueSpec, шапка на GenDecl
const ( A = …; B = … )        — блок; шапка на КАЖДОМ ValueSpec отдельно

───────────────────────────────────────────────────────────────────────────── ЧЕГО РАЗБОР НЕ ВИДИТ — НАЗВАНО, А НЕ СПРЯТАНО

1. **шапка без разделителя** — каноническая форма Go «// F returns …». В этом дереве её почти нет (перепись печатает обе величины: шапок формы с разделителем и объявлений с шапкой вообще), а распознать её нельзя, не принимая за имя первое слово всякой прозы;
2. **объявление с НЕСКОЛЬКИМИ именами в одной спецификации** (`var a, b = …`): шапка вправе называть любое из них, поэтому находкой считается лишь то, чьё имя не совпало НИ С ОДНИМ;
3. **правдивость самого текста** шапки. Гейт судит, к тому ли объявлению она прикреплена, а не то, верно ли она его описывает.

documented_setting_key_exists.go — ОПИСЬ НАСТРОЕК В ПРОЗЕ НЕ ПЕРЕЖИВАЕТ СВОЙ ПРЕДМЕТ: всякий ключ, названный описью инженерной документации, существует в дереве настроек службы.

ПРЕДМЕТ ¶

Опись — таблица «переменная · ключ настройки · умолчание · описание» — живёт в прозе и НЕ исполняется. Настройка тем временем переезжает: группа `extapi.*` ушла целиком (`internal/apps/kaname/config/mode.go` объявляет её группой, «которой в настройке НЕТ ни одной ручки»), ручки поставщика личности переехали под `authn.*`. Опись осталась прежней — и читается как действительность.

Цена не гипотетическая, и одна из строк дороже прочих: опись называла YAML- ключ ДЛЯ ПРЕДЪЯВИТЕЛЯ (`extapi.hydra.admin-token`). Ключа нет, а оператор, прочитавший опись, пишет предъявитель в YAML — то есть в файл посадки, где секрету не место. Ложная опись здесь не просто устарела: она ПРИГЛАШАЕТ сделать то, что справочник посадки прямо запрещает.

РАСПОЗНАВАТЕЛЬ — ОБЪЯВЛЕННАЯ КОЛОНКА, А НЕ ФОРМА ТОКЕНА ¶

Судится не «всё, что похоже на ключ»: в этом корпусе точкой разделены имена Go (`authz.go`, `logger.Warn`), поля JSON (`invite.mailRateLimit`), маски (`authn.*`) и пары `ключ: значение`. Измерено на этом дереве: токенов вида `<секция>.<что-то>` в прозе 107, из них НЕ ключей настройки 36 — то есть треть, и почти вся она законна.

Поэтому судится то, что объявило СЕБЯ описью: колонка таблицы, чей заголовок называет ключ настройки. Автор описи утверждает «вот ключ» — это утверждение и проверяется.

Промах словаря заголовков не даёт молчания: всякий заголовок, несущий слово `yaml` и НЕ опознанный, печатается переписью с координатой. Новое написание колонки видно числом, а не отсутствием вопроса.

АВТОРИТЕТ КЛЮЧЕЙ — ПРОИЗВОДИТЕЛЬ, А НЕ ПЕРЕЧЕНЬ ¶

Множество ключей приходит ПАРАМЕТРОМ и берётся у структуры настроек по её разметке `mapstructure` (проба строит его отражением от `config.Config`). Выписанный здесь перечень разошёлся бы с настройкой молча — на той строке, которую забыли поправить, то есть ровно на классе, который гейт и ловит.

ГРАНИЦЫ — НАЗВАНЫ, ЧТОБЫ ГЕЙТ НЕ ЧИТАЛИ ШИРЕ ¶

1. Ключ, названный в прозе ВНЕ объявленной колонки, не судится. Это не упущение, а цена отказа от формы токена (см. выше); число неосмотренных токенов названо там же.
2. ИСТИННОСТЬ умолчания и описания не судится: здесь держится СУЩЕСТВОВАНИЕ ключа, то есть возможность его перемерить.
3. Ячейка без токена ключевой формы (`—`, «нет», проза) — не находка: автор ключа не назвал. Такие строки печатаются отдельной величиной, а не растворяются в зелёном.

envelope_composition_root.go — страж корня композиции: в не-тестовом дереве службы огибающую по потолку строит ОДНО место — композиционный корень, — и мера прогона в нём — мера настенных часов (приёмка Ф3, Р17 «Мера прогона», Ф3-53 строка стража; заказ kaname#295).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Мера прогона — вход огибающей (`passwordverify.CostMeter`). В боевом корне её мерят настенные часы вокруг самого прогона (`WallClockCostMeter`); стоимость, назначенная числом, живёт только в пробах выбора потолка. Назначенная мера в не-тестовом файле довела бы число пробы туда, где платит вход, и исход входа снова стал бы отличим по времени; второе построение — вторая огибающая со своим потолком, которого полоса входа не читает. Оба пути компилируются, и ни одна проба огибающей их не видит: у проб своя огибающая.

───────────────────────────────────────────────────────────────────────────── ЕДИНИЦА СЧЁТА — МЕСТО ПОСТРОЕНИЯ, УЗНАННОЕ РАЗБОРОМ

Местом построения считается КАЖДАЯ форма, в которой огибающая появляется:

вызов конструктора        `pv.NewEnvelope` (…) под любым именем импорта
                          дома, при импорте с точкой и без квалификатора в
                          самом доме; в скобках — то же;
конструктор значением     `f := pv.NewEnvelope` — мера у места не видна;
значение мимо конструктора `pv.Envelope{…}`, `&pv.Envelope{…}`,
                          `new(pv.Envelope)`, `var e pv.Envelope`, поле и
                          элемент значения, приведение — огибающая без меры
                          либо с мерой, которой страж не видит; в доме — всякое
                          такое место вне тела конструктора (литерал функции
                          в нём — вне тела: исполняется после построения).

Тип огибающей за указателем (`*pv.Envelope`), в доводах и результатах функций, в именованном поле и в получателе метода — не построение: значения он не заводит. Встраивание огибающей — не построение, а подставной тип (ниже).

Дом узнаётся по ПУТИ ИМПОРТА в каждом файле, а не по имени: пакет того же имени из другого пути — чужой, его конструктор построением не считается, а его мера на месте меры дома — иная мера.

Мера судится у места вызова: довод конструктора, чья позиция ВЫВЕДЕНА из объявления (единственный параметр типа меры), обязан быть мерой настенных часов дома — селектором, в скобках либо приведением к типу меры. Всё иное — литерал функции, метод меры пробы, переменная, довод обёртки — иная мера. Обёртка, принимающая меру доводом и строящая огибающую внутри, краснеет консервативно: у места построения мера — идентификатор, и что в него положили, страж не прослеживает.

───────────────────────────────────────────────────────────────────────────── ЗАПИСЬ ПОЛЯ МЕРЫ — ТОЛЬКО ДОВОДОМ КОНСТРУКТОРА

Мера у места построения — мера огибающей, лишь пока в поле меры ложится довод меры конструктора и ничто иное. Поле ВЫВЕДЕНО из объявления огибающей (единственное поле типа меры). Законная запись одна: довод меры — тем же именем, без переписывания — в теле самого конструктора, не в литерале функции. Всякая иная запись поля в доме — присваивание (и кортежем), взятие адреса, поле или позиция в составном литерале, цикл по диапазону — красное с координатой и выражением: сеттер, позванный корнем после построения, меняет меру мимо довода, который страж судит. Переписанный или затенённый в теле конструктора довод меры — тоже красное; конструктор, не кладущий довода в поле, — красное с координатой конструктора.

Носитель меры в доме один — поле меры, и вход в него один — довод конструктора. Всякое иное обращение к типу меры в доме — переменная пакета, которую корень пишет после построения, довод сеттера, исход геттера, поле иной структуры, приведение — и всякий функциональный тип подписи меры, записанный без её имени, кроме объявления функции и литерала, — красное с координатой: второй носитель доводит до прогона меру мимо судимого довода. Геттер краснеет консервативно.

───────────────────────────────────────────────────────────────────────────── ПОДСТАВНОЙ ТИП НА МЕСТЕ ПОРТА

Полоса входа принимает огибающую портом; методы порта ВЫВЕДЕНЫ из его объявления (`PortDir`, `PortInterface`). Не-тестовый метод с именем и арностью метода порта на типе помимо огибающей дома — реализация порта вне дома: целиком (исход допуска под псевдонимом ли, из третьего пакета ли — тип исхода не читается) или частью, подменой одного метода поверх встроенного порта либо встроенной огибающей. Встраивание огибающей дома в структуру — по значению и по указателю, вне дома и в нём — красное само: встроивший исполняет порт методами огибающей и подменяет любой из них.

───────────────────────────────────────────────────────────────────────────── ОБХОД СИСТЕМЫ ТИПОВ

Неэкспортированное поле меры пишется мимо дома только мимо системы типов: импорт `unsafe` в файле, обращающемся к дому, и директива `//go:linkname`, называющая символ дома, в любом не-тестовом файле — красное с координатой.

───────────────────────────────────────────────────────────────────────────── ПОСЫЛКА — ОТКАЗ, А НЕ МОЛЧАНИЕ

Конструктор объявлен в доме ровно раз и несёт ровно один довод типа меры, и у довода есть имя; мера настенных часов, тип огибающей и тип меры объявлены в доме, тип меры — функциональный; у огибающей ровно одно поле типа меры, оно неэкспортировано, и его имя в доме несёт одно поле — тогда запись вне дома не компилируется, а в доме узнаётся по имени однозначно; порт объявлен ровно раз, методы перечислены без встраивания, и каждый объявлен у огибающей дома с той же арностью; `go.mod` корня дерева называет модуль; корень композиции несёт не-тестовые файлы. Не держится — ErrEnvelopeRootPremise с тем, что не нашлось. Пустой обход — ErrEmptyTraversal. «Построений 0» — находка о дереве, а не отказ посылки.

Положительный контроль того же прогона: законная запись поля меры и методы порта у огибающей дома узнаются теми же распознавателями, что ищут нарушение; перепись печатает их координаты.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

1. Граница — РОД ФАЙЛА, суффикс `_test.go` (`ProductionGoFile`). Тег сборки не читается: не-тестовый файл под `//go:build ignore` судится, помощник пробы в не-тестовом файле краснеет по замыслу — Р17 проводит границу по роду файла, а не по имени меры.
2. Единица — синтаксическое место. Второе построение во время работы через то же место (цикл, двойной вызов сборщика корня) статически не видно.
3. Судится ИМЯ меры, путь довода в поле меры и носители меры в доме; что прогон делает с мерой поля дальше, — нет. Тело меры корня держит проба TestWallClockCostMeter_MeasuresTheWholeRunItCalls; то, что стоимость класса берётся мерой поля, — TestEnvelope_ADearerClassRaisesTheFloorACheaperOneDoesNot (назначенная пробой стоимость доходит до потолка).
4. Тип довода и исхода не выводится: подставной метод узнаётся по имени и арности метода порта, и метод с тем же именем и арностью, порта не исполняющий, краснеет консервативно. Порт — объявленный спекой: иной порт над огибающей стражу неизвестен. Подпись меры сличается текстом типов: носитель под псевдонимом типа довода не узнаётся. Копия значения огибающей (`c := *e`) новой меры не заводит и не судится.
5. Область обхода — `OutsideTraversal`: не-тестовые файлы под её сегментами не судятся, и перепись печатает их числом.
6. Состав — индекс git: файл, не внесённый в индекс, стражу невидим.

failure_reset_sole_writer.go — разбор «кто обнуляет счёт неверных предъявлений по адресу» (приёмка Ф12 Р7 редакция 11, `docs/engineering/acceptance/second-factor-totp-and-recovery-codes.md`; Ф3 Р10 редакция 11, `docs/engineering/acceptance/login-lane-issues-our-session-and-logout-ends-it-server-side.md`; задача PRO-Robotech/kaname#287).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Счёт по адресу обнуляет вход, ЗАВЕРШЁННЫЙ до уровня всех заведённых у личности факторов. Условие это — свойство того, какие СТРОКИ СПОСОБОВ ВХОДА заведены, и того, что ПРЕДЪЯВЛЕНО в сессии; свойством полосы, из которой обнуление зовётся, оно не является. Поэтому решать его обязано ОДНО место, и всякая полоса обязана проходить через него.

Полоса, зовущая обнуление напрямую, решает это условие СВОИМ путём — либо не решает вовсе, и тогда успех одного первого фактора открывает свежее окно подбора второго. Класс не ловится ни сборкой, ни типом: прямой вызов компилируется и выглядит ровно так же, как правильный.

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ ОБРАЩЕНИЕ, А НЕ ИМЯ ФАЙЛА

Разбор ищет обращения к имени порта и классифицирует КАЖДОЕ по узлу:

w.ResetFailures(ctx, …)            ВЫЗОВ           — судится домом
f := w.ResetFailures               ЗНАЧЕНИЕ-МЕТОД  — судится домом (вызовут позже)
ResetFailures(ctx, …) в интерфейсе ОБЪЯВЛЕНИЕ      — порт, молчит
func (w *…) ResetFailures(…)       РЕАЛИЗАЦИЯ      — адаптер, молчит

Значение-метод названо отдельной формой намеренно: распознаватель, знающий только прямой вызов, пропустил бы обнуление, вынесенное в переменную, — и пропустил бы МОЛЧА, не дав ни красного, ни зелёного (`.claude/rules/testing.md` §«Гейт на класс», п. 7).

───────────────────────────────────────────────────────────────────────────── ГРАНИЦА НАЗВАНА

Гейт ловит БОЛЬШЕ обещанного и слеп там, где обещает видеть: по имени он находит и формы сверх четырёх перечисленных (отложенный вызов, выражение метода), а стережёт он «имя не упомянуто селектором вне дома» — не то же, что «счёт не обнуляется без вопроса об уровне». Первое влечёт второе, пока обнулить счёт можно только селектором этого имени, а это свойство того, как дерево написано сегодня, а не следствие разбора.

Эта посылка судится ОТДЕЛЬНО, по дереву, а не утверждается (`JudgeFailureRowRemovals` ниже), и по признаку, а не по началу оператора: текст, называющий таблицу счёта и несущий изменяющее слово в любом месте, законен ровно в двух местах — удалением по ключу в реализации порта и по возрасту в уборщике `SweepAgedFailures`; всякий иной — находка, как и текст с таблицей, который разбор не классифицирует. Пока посылка верна, молчание гейта значит то, что обещает, — в пределах её границы, названной ниже.

Границы остаются, обе названы:

разбор судит ИМЯ, а не тип приёмника — одноимённый метод чужого типа был бы
   сочтён обращением к порту, и гейт покраснел бы на невиновном;
обёртка ВНУТРИ дома гейту невидима: он судит координату файла, поэтому
   второй безусловный путь, заведённый в самом доме, он не увидит — это
   держит таблица решений `completed_login_test.go`, а не он.

У посылки своя граница: она судит ЗНАЧЕНИЕ строкового выражения, которое сворачивается при разборе дерева, — литерала, склейки, имени константы либо связанного имени пакета этого модуля. Ей не видны оператор, собранный во время исполнения, — вызовом (`fmt.Sprintf`, `strings.Join`), в переменной функции, присваиванием переменной пакета, из константы чужого модуля (судятся тогда лишь его звенья-литералы, и имя таблицы с изменяющим словом в РАЗНЫХ звеньях не видно), — и оператор вне Go (триггер, правило либо функция миграции).

family_revocation_reason_writers.go — разбор «у каждого слова словаря причин отзыва семейства есть писатель» (задача PRO-Robotech/kaname#339, п.1 предиката снятия; приёмка `docs/engineering/acceptance/client-revocation-has-its-own-family-revocation-reason.md`, KN-FRV-17, решение Р12).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Словарь причин отзыва семейства ЗАКРЫТ: он перечисляет исчерпывающе, и ограничение схемы принимает ровно его. Слово, которого никто не пишет, превращает перечень в обещание — оно читается как работающее и не наступает ни при каком входе. Два таких слова жили в словаре со дня его заведения, и заметить это было нечем: имя без писателя компилируется, проходит пробы схемы и молчит.

───────────────────────────────────────────────────────────────────────────── ЧТО СЧИТАЕТСЯ ПИСАТЕЛЕМ — ДВЕ ВЕТВИ

1. на константу домена этого слова ссылается УЗЕЛ разбора — селектор пакета домена (`domain.<имя>`) — в не-тестовом `.go` вне самого домена;
2. причина фундамента того же написания сопрягается адаптером порта отзыва с этим словом (`ceremonyport.FamilyReasonOf`): такое слово пишется по значению и константы не называет.

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

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ УЗЕЛ, А НЕ ТЕКСТ

Упоминание константы в комментарии или в строке писателем не является: комментарий в дерево узлов не входит, строка — узел литерала, а не селектора. Селектор судится по ПУТИ ИМПОРТА, а не по имени пакета: псевдоним импорта домена — та же ссылка, одноимённый селектор чужого пакета — не она. Имена констант и их значения берутся из объявлений домена, а не выписываются здесь: своя копия была бы вторым объявлением словаря.

───────────────────────────────────────────────────────────────────────────── ПУСТОЙ ОБХОД — ОТДЕЛЬНЫЙ ИСХОД

Ноль разобранных файлов, ноль файлов, импортирующих домен, либо пустой перечень — это «ноль прочитанного», а не «ноль находок», и такой исход обязан быть КРАСНЫМ.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦА НАЗВАНА

Импорт домена точкой, затенение имени импорта локальной переменной и слово, собранное из частей строки, разбор не видит. В дереве таких путей к словарю нет; первое и третье — довод держать ссылку селектором, каким она и написана.

family_verdict_single_reader.go — «отозвано ли семейство выпуска» решает ОДИН читатель, и каждая поверхность предъявления спрашивает его через ОДНО правило (задача PRO-Robotech/kaname#319, решение К10 вариант А).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ И ПОЧЕМУ ОН ГЕЙТ, А НЕ ВНИМАНИЕ

Решение о доступе по семейству принимают три поверхности: `IsRevoked` службы отзыва, авторитет отзыва на внутреннем слушателе и читатель предъявленного на публичном. Одно решение держится одним читателем только тогда, когда второго написания нет нигде:

• оператор, читающий запись выпуска, — ОДИН литерал в дереве. Второй литерал (свой запрос у одной из поверхностей) разошёлся бы с первым молча — например, забыв, что снятое семейство оставляет у записи ПУСТУЮ живость, — и обе копии были бы зелены на своих пробах;
• порт чтения семейства зовёт ТОЛЬКО правило (`internal/tokenrevocation`). Поверхность, позвавшая порт мимо правила, завела бы свою политику на пустой идентификатор и на неответ хранилища;
• каждая поверхность ЗАКРЫТОГО перечня зовёт правило. Поверхность, правила не зовущая, семейства не спрашивает вовсе;
• у решения нет ВТОРОГО ХРАНИЛИЩА. Правило читает утверждения токена, и каждое прочитанное утверждение решено поимённо: ключ отсечки субъекта или клиента либо идентификатор выпуска — единственный вход к записи выпуска. Утверждение, несущее семейство, превратило бы отсечку по ключу во второе хранилище решения о семействе со своим писателем и своей уборкой (К10, вариант А: семейство судит только запись выпуска). Перечень сверяется в обе стороны: решённое утверждение, которого правило больше не читает, — тоже находка (правило без `jti` о семействе не спрашивает);
• у решения нет ПУСТОГО хранилища. Отсутствие записи правило читает как «семейству не принадлежит», поэтому выпуск церемонии, не пишущий запись, выпускает токен, который отзыв семейства не снимает. Реализация порта выпуска фундамента (`IssueAccessToken` либо `StoreAccessToken` из `corelib/oauthceremony`, порты есть с тега v1.10.0-rc.1) при нуле вызовов писателя записи в дереве — находка. Сколько реализаций в дереве, печатает перепись («реализаций порта выпуска N»), а не этот заголовок: число меняется с деревом. Ноль реализаций законен — выпускать нечему, и ось о нём молчит. Предпосылка оси — объявление писателя в дереве: без него ось ослепла бы молча.

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ УЗЕЛ РАЗОБРАННОГО ДЕРЕВА, А НЕ ТЕКСТ ФАЙЛА

Литерал — узел `BasicLit`, вызов — узел `CallExpr`. Упоминание в комментарии (в том числе в этом) находкой не является.

Читающим считается литерал, который ОТКРЫВАЕТСЯ словом `SELECT` либо `WITH` и называет таблицу выпусков. Вставка и уборка открываются иначе и читателями не считаются: у них другой предмет.

Утверждение считается прочитанным правилом, когда в файле каталога правила индексируется параметр типа `jwt.MapClaims`: литералом, константой пакета либо переменной цикла по перечню-литералу пакета.

───────────────────────────────────────────────────────────────────────────── ЧЕГО РАЗБОР НЕ ВИДИТ — НАЗВАНО

1. оператор, собранный из кусков во время исполнения: разбор читает литерал, а не результат конкатенации. Довод держать оператор ОДНОЙ константой, каким он и написан;
2. чтение таблицы выпусков ПОДЗАПРОСОМ внутри вставки, правки или удаления: такой литерал открывается не словом чтения. В дереве таких нет;
3. вызов порта через переменную функционального типа (`f := r.FamilyRevoked` без вызова на месте): узел вызова здесь другой. В дереве таких нет;
4. утверждение, прочитанное правилом не индексом параметра `jwt.MapClaims`: методом (`GetIssuedAt` — момент выпуска, ключом не служит), через переменную иного объявленного типа или через копию состава. Индекс, имя которого разбор не разрешил, — находка, а не молчание;
5. второе хранилище семейства ВНЕ правила — поверхность, сама читающая утверждение семейства и спрашивающая хранилище мимо правила. Его ловит только ось «поверхность зовёт правило» и пробы поверхностей, а не эта;
6. что писатель позван ИМЕННО на пути выдачи и ДО ответа, и что этот путь собран: ось судит, что вызов в дереве есть. Порядок на уровне адаптера держит `TestIssue_RecordsTheIssuanceInItsFamilyBeforeTheTokenLeaves` (`internal/ceremonyport`), сборку — гейт перечня источников отзыва службы (`TestContractListsFamilyAsProducedTodayOnlyWhenIssuanceIsRecorded`), путь запроса — сборка церемонии (kaname#407);
7. порт выпуска под другим именем метода: имена взяты из фундамента (`corelib/oauthceremony`, порты есть с тега v1.10.0-rc.1), и переименование там ослепило бы ось.

Перечень границ, названный не полностью, хуже отсутствующего: он создаёт уверенность.

granted_relation_in_model.go — разбор: отношение, которое ВЫДАЁТ миграция, обязано СУЩЕСТВОВАТЬ в модели, которую применяет решение о доступе.

Предмет ¶

Выдача права живёт в двух артефактах, и они доезжают до решения РАЗНЫМИ путями: отношение объявляет модель прав, а саму выдачу пишет миграция — строкой в очередь. Если миграция называет отношение, которого в применяемой модели нет, запись отвергается со значением «такого отношения нет», дренаж верно считает такой отказ ПОСТОЯННЫМ, и строка травится: счётчик попыток выставляется в потолок, и больше её не возьмут никогда.

Что это стоит ¶

У этой очереди НЕТ переезда отравленных строк обратно в работу: разбор партиций идёт по идентификатору ресурса, которого у неё нет by construction (она партиционирована по ключу кортежа). Следствие названо честно: отравленная строка не «подождёт», а ЛЕЖИТ ДО ВМЕШАТЕЛЬСТВА ОПЕРАТОРА. Право, которое она несла, не выдаётся.

Почему разбор дерева, а не внимание ¶

Расхождение не видно НИ ОДНОЙ из двух сторон. Миграция — обычный SQL: она применяется без ошибки, потому что про модель ничего не знает. Модель — обычный DSL: он проходит проверку, потому что про миграции ничего не знает. Сборка цела, пробы обеих сторон зелёные, а право не выдано. Единственное место, где два факта встречаются, — дерево.

Чего этот разбор НЕ ловит (названо, чтобы на него не сослались шире предмета) ¶

Он про СОСТАВ, а не про ПОРЯДОК. Если отношение в модели есть, но новая её редакция ещё не применена, а дренаж уже взял строку, — пара сойдётся, разбор промолчит, а строка отравится ровно так же. Порядок двух путей доставки деревом не проверяется.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/grantedrelationinmodel_test.go` (снято вынесением службы — `kacho#2598`; предмет жив здесь, задача #17). Изменилось: координаты обоих операндов (приставки `services/iam/` в самостоятельном клоне нет), разбор вынесен из пробы в пакет `check`. Осталось дословно: имя гейта, ОБЕ формы записи кортежа и то, что применяемая модель читается ВСТРОЕННАЯ, а не каноническая.

Близнеца в платформе нет: семейство снято там вместе со службой (ban #20).

guard_named_in_comment.go — разбор одного файла на ДВА РАЗНЫХ факта о защите: названа ли она КОММЕНТАРИЕМ и вызвана ли ВЫРАЖЕНИЕМ.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Комментарий, противоречащий коду, — не косметика. В обычном случае следующий читатель «чинит» код под неверный комментарий. Здесь хуже: комментарий уже ОТВЕТИЛ на вопрос «закрыт ли этот сегмент защитой», поэтому читатель не идёт проверять, и пробел остаётся незамеченным ИМЕННО ПОТОМУ, что о нём написано.

Класс наблюдался дважды и в двух разных видах. В монорепо: файл в пакете ролей утверждал, что сегмент глагола закрывается словарём домена, тогда как во всём пакете это имя встречалось РОВНО ОДИН раз — в самом этом комментарии. При выносе службы (kacho#2597): прод-код и приёмки службы продолжили называть держателями гейты монорепо, снятые вместе с каталогом, — то есть комментарий называл защиту, которой не существует ни в одном репозитории.

───────────────────────────────────────────────────────────────────────────── ПОЧЕМУ УЗЕЛ РАЗБОРА, А НЕ ПОДСТРОКА

Поиск по подстроке нашёл бы имя в комментарии, который эту же защиту ОБЪЯСНЯЕТ, и счёл бы её присутствующей — то есть гейт зеленел бы на собственном объяснении. Поэтому два факта читаются РАЗНЫМИ средствами:

упоминание — ТОЛЬКО из узла комментария (ast.CommentGroup);
наличие    — ТОЛЬКО из узла-идентификатора выражения (ast.Ident) и ТОЛЬКО
             из прод-кода: вызов защиты внутри пробы её в прод-коде не создаёт.

Строковый литерал, несущий то же имя, наличием НЕ является: он узел ast.BasicLit, а не ast.Ident, и разбор его не засчитывает by construction.

───────────────────────────────────────────────────────────────────────────── ФОРМЫ ЗАПИСИ — ПЕРЕЧИСЛЕНЫ, А НЕ ПОДРАЗУМЕВАЮТСЯ

Форма, о которой распознаватель не знает, даёт не красное и не зелёное, а МОЛЧАНИЕ. Поэтому обе стороны перечислены поимённо, и по каждой стоит утверждение инъекции.

Формы показаны на ВЫМЫШЛЕННОМ имени GuardedCall, а не на записи действующего реестра, и это не стиль: godoc — тоже комментарий, и пример на живом имени сделал бы ЭТОТ ФАЙЛ находкой собственного гейта. Класс поймал себя сам при первом же прогоне после индексации (kacho#2597).

Упоминание в комментарии — четыре формы:

bare       GuardedCall              — имя прозой
qualified  domain.GuardedCall       — имя с квалификатором пакета
call       GuardedCall()            — имя со скобками
backtick   `GuardedCall`            — имя в обратных кавычках

Наличие в выражении — четыре формы, и все четыре суть узел ast.Ident:

GuardedCall(v, t)          прямой вызов
domain.GuardedCall(v, t)   вызов с квалификатором (Sel — тот же ast.Ident)
f := GuardedCall           значение функции
f := domain.GuardedCall    значение с квалификатором

───────────────────────────────────────────────────────────────────────────── ГРАНИЦА ИМЕНИ — НЕСУЩАЯ

Совпадение считается по ГРАНИЦЕ идентификатора, а не по вхождению подстроки: иначе `GuardedCallStrict` засчитывался бы упоминанием `GuardedCall`, и находка приходила бы на имя, которого комментарий не называл.

identity_growth_reader.go — разбор: у величины роста числа личностей есть ЧИТАТЕЛЬ, и он назван.

Предмет ¶

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

Что считается читателем ¶

ТОЛЬКО выражение правила оповещения (`expr:`). Упоминание имени ряда в пояснении к тревоге или в таблице метрик читателем НЕ является: пояснение не срабатывает. Различие несущее — оба текста лежат в одном файле, и разбор, ищущий имя по всему документу, зеленел бы на ряде, о котором лишь написано.

Граница названа ¶

Судится ОДНО семейство, и его состав выводится из файла коллектора, а не из выписанного перечня. На прочие ряды службы разбор не распространяется, и это не оплошность: у части из них правил сегодня нет, и заведение им читателей — отдельная работа с отдельным предметом. Расширение на всё семейство метрик обязано прийти ВМЕСТЕ с этими правилами, иначе оно потребует перечня исключений — то есть заведёт ровно ту форму, в которой послабление переживает свой предмет.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/identitygrowthreader_test.go` (семейство снято вынесением службы, `kacho#2597`; предмет жив здесь — задача #17). Изменилось: координаты обоих операндов (приставки `services/iam/` в самостоятельном клоне нет), разбор вынесен из пробы в пакет `check`, приставка рядов берётся у того же имени, которым пакет уже называет свой словарь. Осталось дословно: имя гейта (`TestIdentityGrowthMetricsHaveANamedReader`), разбор выражений и граница «исполняемое против объяснения».

Близнец в платформе снят вместе с предметом — там этих рядов больше нет, поэтому пары файлов этот порт НЕ заводит.

injection_named_exists.go — разбор: доказательство способности упасть, НАЗВАННОЕ пробой, обязано существовать (kacho#2479).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Проба, чья шапка говорит «способность упасть доказана инъекцией — такой-то файл», делает утверждение о ДЕРЕВЕ. Утверждение это не компилируется и никем не сверяется: файл переименовали, унесли вместе с рефакторингом либо не написали вовсе — а шапка продолжает обещать доказательство. Гейт, потерявший способность краснеть, на чистом дереве выглядит РОВНО ТАК ЖЕ, как исправный, поэтому обещание доказательства читается как само доказательство.

Замер, из которого разбор выведен: на ревизии заведения упоминаний в комментариях было 122, не резолвилось ОДНО — шапка гейта осей адреса называла файл, которого в дереве не было с первого её дня.

───────────────────────────────────────────────────────────────────────────── У ЭТОГО РАЗБОРА ЕСТЬ БЛИЗНЕЦ В ПЛАТФОРМЕ — И ЭТО НАЗВАНО, А НЕ УМОЛЧАНО

Тот же разбор, поднятый до корня МОНОРЕПО, живёт в `tools/injectionproofgate` (задача kacho#2519): этот обходит корень своего модуля и о платформе не высказывается — в самостоятельном клоне службы монорепо нет вовсе. Обещания соседних модулей платформы этому модулю не принадлежат.

Свести обе реализации в одну сегодня НЕЛЬЗЯ: модуль службы пинит платформу псевдоверсией, поэтому импортировать пакет, которого в пинованной ревизии ещё нет, он не может. Предикат сведения: пин указывает на ревизию, где тот пакет существует; до этого две реализации об одном предмете живут рядом осознанно.

───────────────────────────────────────────────────────────────────────────── СУДЯТСЯ КОММЕНТАРИИ, И ЭТО РЕШЕНИЕ, А НЕ УПРОЩЕНИЕ

Координата доказательства пишется ПРОЗОЙ — это её законное место, и разбор читает разобранные группы комментариев, а не сырой текст файла. Строковые литералы намеренно НЕ судятся: в них живут синтетические имена, которые инъекции кладут во временные каталоги, и дерева они не называют вовсе. Судить их значило бы краснеть на чужой фикстуре — то есть на собственном доказательстве.

Величина «в строках» всё равно печатается переписью: молчание о целом виде вхождений неотличимо от их отсутствия.

───────────────────────────────────────────────────────────────────────────── ЗАКОННЫХ ФОРМ КООРДИНАТЫ ТРИ, И РАСПОЗНАВАТЕЛЬ ЗНАЕТ ВСЕ ТРИ

Форма, о которой он не знает, даёт не красное и не зелёное, а МОЛЧАНИЕ. Измерено на этом дереве: наивный резолвер («имя рядом с называющим») дал 4 непопадания из 138, и все четыре оказались ЗАКОННЫМИ формами, а не находками.

СОСЕД        `<имя>_injection_test.go` — файл в каталоге называющего;
ПО МОДУЛЮ    то же имя, но доказательство лежит в ДРУГОМ пакете модуля
             (проба одного пакета ссылается на инъекцию соседнего);
КООРДИНАТОЙ  `internal/<пакет>/<имя>_injection_test.go` — путь от корня
             МОДУЛЯ службы, а не от корня монорепо: в самостоятельном клоне
             приставки `services/iam/` нет, и счёт от неё указывал бы наружу
             дерева.

Имя в примерах — ОБРАЗЕЦ с угловыми скобками, а не координата, и это не подгонка текста под инструмент: координата, названная в прозе, есть утверждение о дереве, и выдуманная — ложное. Разбор судит объявленные координаты, поэтому пример обязан не выглядеть ею.

issue_ref_prefix.go — ссылка на задачу ДРУГОГО репозитория несёт его имя (задача kaname#387).

Предмет ¶

Служба вынесена из монорепо вместе с историей, и в её дереве остались ссылки вида `#<N>` на задачи монорепо. На GitHub такая ссылка разрешается ВНУТРИ этого репозитория: номер вне диапазона задач службы даёт 404, номер из диапазона — чужую задачу службы, и оба исхода молчаливы. Ссылка без префикса здесь значит задачу службы; задача монорепо пишется `kacho#<N>`, воркспейса — `kacho-workspace#<N>`, прежнего трекера `kacho-iam` (история до монорепо) — `kacho-iam#<N>`.

Что гейт умеет утверждать и чего — нет ¶

Номер ВЫШЕ потолка задач службы задачей службы быть не может — такая ссылка без префикса есть находка без чтения намерения. Номер В ДИАПАЗОНЕ гейт не судит: `#337` равно законно значит задачу службы и неверно — задачу монорепо с тем же номером, и различить их можно только по референту (сверка по истории строки и заголовку задачи — работа kaname#387, не машинное правило). Это граница утверждения, а не дыра: она названа и в шапке пробы, и в её выводе («ссылок без префикса N, из них выше потолка M»).

Форма ссылки — та же, что у предиката задачи ¶

git grep -hIoE '(^|[^A-Za-z0-9/_#-])#[0-9]{3,5}\b'

с одним сужением: `&` перед `#` — числовая сущность разметки (`&#123;`), а не ссылка. Цифр три–пять: короче — пункты и заголовки, длиннее — не номер задачи. Знак после номера — не буква, не цифра и не `_`: `#15161d` — цвет, не ссылка.

Предикат задачи вычитает ещё `docs/changes`; гейт этого исключения НЕ несёт: на дне заведения голых ссылок выше потолка там ноль, а исключение, которому нечего прощать, — слепая зона без срока.

job_knob_has_a_reader.go — разбор: у КАЖДОЙ величины секции фоновых заданий есть читатель вне пакета настроек (задача kacho#2647).

Предмет ¶

Ручка настроек, которую принимают, валидируют и не читают, — это «принято-и-проигнорировано» на уровне НАСТРОЙКИ, и там оно тише, чем в поле запроса. Оператор, выставивший величину, получает УСПЕХ: значение принято, провалидировано, отказа нет. Он уверен, что изменил поведение. Поведение осталось прежним.

Три обстоятельства делают это неотличимым от исправной работы, и все три наблюдались вместе на `jobs.catalog-snapshot.refresh-interval`:

• величина объявлена ДВАЖДЫ — секцией настроек и ручкой окружения в композиционном корне, — а петлю ведёт одна;
• умолчания РАСХОДЯТСЯ (минута против пятнадцати секунд), то есть даже незаданная ручка описывает поведение неверно вчетверо;
• страж старта у поля ЕСТЬ и отвергает непозитивное — и тем создаёт вид живого механизма: «ручка работает».

Наблюдаемого отличия нет ни одного: снимок обновляется, просто не с тем периодом. Заметить можно только замером окна отставания.

Что считается ЧИТАТЕЛЕМ, и почему собственная валидация им не является ¶

Читателем считается обращение к полю в композиционном корне — там, где величина попадает в механизм. Метод `Validate` самой секции читателем НЕ является by construction: он живёт в пакете настроек, и его вызов доказывает ровно то, что величину проверили, — а не то, что ею кто-то пользуется. Именно поэтому предикат задачи звучал «читатель ВНЕ собственной валидации»: у поля без механизма читателей было два, и оба — его собственная проверка.

Почему разбор УЗЛОВ, а не поиск имени ¶

Имя поля (`Interval`, `Enabled`, `Grace`) — из самых частых в дереве, и поиск по нему засчитал бы читателем одноимённое поле ЧУЖОЙ структуры, комментарий и строку журнала. Поэтому читатель опознаётся цепочкой узлов: обращение к полю через `…Jobs.<секция>` либо через ПСЕВДОНИМ, связанный с этой цепочкой (`c := cfg.Jobs.ExpiredCredentialReclaim`, дальше `c.Interval`) — ровно та форма, которой пользуется корень.

Граница названа: секция, переданная ЦЕЛИКОМ ¶

Секция, ушедшая в вызов целиком (`f(cfg.Jobs.X)`), пофайлово не разбирается: о её полях этот гейт не утверждает ничего. Такие секции НЕ прощаются молча — они печатаются переписью отдельной величиной, потому что «поле прочитано» и «секция уехала целиком, а поле, может, и не прочитано» — разные вердикты, и второй обязан быть видим.

judge_target_wiring.go — разбор: у ЕДИНСТВЕННОГО судьи оси обязан быть вызывающий среди того, что исполняется само.

Предмет ¶

Часть осей этого дерева судит ровно один исполнитель, поднимаемый целью рецепта: форму манифеста модуля — загрузчик `internal/manifest` (цель `module-manifest-check`), сходимость блоков модели доступов с манифестами — `tools/model-canon-check.sh` (цель `model-canon-check`). Единственность судьи назначена намеренно, и второго заводить нельзя: две копии одного суждения расходятся молча и расходятся там, где обе зелены.

У единственности есть цена. Если у такого судьи нет ВЫЗЫВАЮЩЕГО, то ось, которую судит только он, не встречает НИ ОДНОЙ автоматической проверки — и молчание неотличимо от исправной работы. Это вторая половина класса «проверка с формой, но без содержания»: страж, который ничего не проверяет, и страж, которого никто не зовёт. Здесь — вторая.

Чем этот разбор НЕ является ¶

Он не судит форму манифеста и не сверяет блоки модели: второй судья тех же осей запрещён. Его предмет — ПРОВЯЗКА.

Почему разобранный YAML, а не текст ¶

Имя цели встречается в носителях чаще, чем её вызов: в заголовке шага, в условии, в комментарии, который эту же провязку объясняет. Поиск подстрокой зеленел бы на собственном объяснении и оставался бы зелёным при СНЯТОЙ провязке. Поэтому вызов ищется в теле `run:` разобранного задания, а комментарии из тела снимаются (`ExecutableRunBodies`), и форма вызова требуется исполняемая (`CallsMakeTarget`).

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/gatetargetwiring.go` вместе с двумя его семействами (`modulemanifestcheckwiring`, `modelcanoncheckwiring`; сняты вынесением службы — `kacho#2598`, предмет жив здесь, задача #17). Изменилось: операндов у обхода не «Makefile каждого сервиса», а ОДИН корневой рецепт — у самостоятельного модуля сервисных подкаталогов нет by construction; носителей провязки тоже один род (задания конвейера), потому что локального прогонщика `scripts/ci-local.sh` в этом дереве не существует. Примитивы разбора не копируются: они уже живут в пакете (`MakefileDeclaresTarget`, `ExecutableRunBodies`, `CallsMakeTarget`) и приехали сюда портом гейта сверки каталога прав.

Близнеца в платформе у этого разбора нет: оба семейства сняты там вместе со службой, поэтому пары файлов порт НЕ заводит (ban #20).

key_algorithm_dictionary.go — разбор словаря зарегистрированного алгоритма в СХЕМЕ.

Предмет ¶

Словарь алгоритмов ключа объявлен дважды: ограничением схемы и закрытым перечнем кода. Совпадение двух объявлений держится ГЕЙТОМ, а не совпадением формулировок: разойдясь, они дают либо строку, которую схема примет, а проверяющий не признает, либо алгоритм, который проверяющий считает допустимым, а вставить его нельзя.

Пустое значение — ЗАКОННЫЙ вход, и означает оно «ключа нет» ¶

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

Что здесь считается ДЕЙСТВУЮЩИМ объявлением ¶

Миграции применяются по порядку и не правятся (ban #5), поэтому действует ПОСЛЕДНЕЕ объявление ограничения с этим именем, а снятое `DROP CONSTRAINT` не действует вовсе. Разбор читает файлы в том же порядке, в котором их применяет накат.

Какие формы записи словаря разбор ЗНАЕТ ¶

Их две, и обе законны в этом дереве (предмет [dictionaryListOpensAt]):

key_algorithm IN ('', 'ES256', 'RS256', 'EdDSA')                       -- рука
key_algorithm = ANY (ARRAY[''::text, 'ES256'::text, 'RS256'::text])    -- снимок

Вторую производит сведённый свод миграций: свод написан инструментом, и членство он записывает только так. Разбор, знавший одну форму, не краснел и не молчал, а ОСЛЕП: находил ноль объявлений и сообщал об этом словами «столбец не сужен ничем» — утверждение о СЕБЕ, сказанное о схеме.

Чего разбор НЕ видит — названо, а не спрятано ¶

1. **ограничение, наложенное функцией или триггером**, а не перечнем значений. Форма другая, и предмет у неё другой.
2. **словарь, собранный из значений другой таблицы** (внешний ключ на справочник): тогда объявления в тексте миграции нет вовсе, и сверять нечего — счётчик найденных ограничений это покажет.
3. **значение, собранное выражением** — конкатенация, вызов функции. Приведение типа на литерале в этот пункт НЕ входит: имя типа стоит за кавычками, поэтому значением оно не становится.
4. **перечень ЗАПРЕЩЁННОГО** — не по слепоте, а по решению: гейт сверяет словарь с перечнем ДОПУСТИМОГО кода, и засчитать дополнение множества значило бы сравнить его с самим множеством.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/keyalgorithmdictionary.go` (снято вынесением службы — `kacho#2598`; предмет жив здесь, задача #17). Изменилось: накат миграции подаёт ВЫЗЫВАЮЩИЙ (та же форма, что у соседа по пакету — `SQLCreateTableBody`), поэтому зависимости на пакет миграций у разбора нет; помощник чтения идентификатора переименован, чтобы не переобъявлять соседского. Осталось дословно: имя гейта, обе формы словаря и граница «пустое — не алгоритм».

Близнеца в платформе нет: семейство снято там вместе со службой (ban #20).

limit_export_procedure.go — разбор инструкций установки на предмет процедуры, которой оператор сохраняет строки таблицы ПЕРЕД её сносом (задача продукта kacho#2134, приёмка KAN-QUOTA-1 §9 `ПР-3`, сценарий `KAN-Q4-07`).

Предмет ¶

Накат отказывает, увидев живые строки в таблице, которую снесёт ещё не применённая миграция, и называет оператору два шага: сохранить и разрешить снос. Первый — команда, и производит её РОВНО ОДНО место, `dropguard.PreserveCommand`.

Оператор читает эту команду дважды и в двух РАЗНЫХ местах: в отказе, когда накат уже встал, и в инструкции обновления, когда он к обновлению готовится. Два написания одной команды расходятся молча — и расходится то, которое НЕ исполняется, то есть документ. Поэтому документ обязан нести её ДОСЛОВНО, а не пересказом.

Оси находки — две, и они с разных сторон ¶

1. **инструкция службы доступа обязана нести команду для таблицы величин.** Версия, снимающая домен величин, сносит `kaname.limits`; счёт её строк ненулевой у ЛЮБОЙ установки (цепочка сеет умолчания, администратор пишет сверх), значит отказ наступит у каждого, и процедура обязана быть записана ЗАРАНЕЕ. Ось привязана к координате намеренно: без неё «команды нет вовсе» давало бы ноль предметов, то есть зелёное на достигнутой потере;
2. **всякая процедура выгрузки в любой инструкции обязана совпадать с производителем побайтово.** Ось ловит ВТОРОЕ написание — то, что заведут соседи, скопировав абзац и поправив под себя.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/limitexportprocedure.go` (семейство снято вынесением службы, `kacho#2597`; предмет жив здесь — задача #17: INSTALL.md службы несёт команду для `kaname.limits`). Изменилось: дом производителя (`PRO-Robotech/corelib:dropguard`, приезжает пином — своей копии порт НЕ заводит), пакет, координата инструкции (приставки `services/iam/` в самостоятельном клоне нет) и имена трёх внутренних помощников, разведённые с соседями по пакету. Осталось дословно: имя гейта, обе оси находки и разбор.

Чего разбор НЕ видит — названо, а не спрятано ¶

Команду, разорванную переносом строки: строка документа читается целиком, и перенос внутри неё разорвал бы и саму команду для того, кто её копирует. Отдельно: разбор судит ТЕКСТ инструкции, а не то, что psql её исполнит, — исполнимость против живой схемы утверждает интеграционная проба службы доступа, где база поднимается.

list_scope_double.go — разбор: пакет, чей дублёр области видимости объявляет её НЕОГРАНИЧЕННОЙ, обязан называть живого держателя настоящего отбора.

Предмет, и почему требуется именно это ¶

Снисходительность здесь НАМЕРЕННА, и её цена названа в самих пробах: строк выдачи у их фикстуры нет вовсе, поэтому назвать кандидатов она не может, а сузив набор до пустого — вернула бы пустую страницу везде и стёрла бы предмет своих же проб (вердикт: каким отношением судится строка страницы). Требовать «почините дублёров» значило бы сломать работающее.

Опасно другое. Отбор кандидатов держит РОВНО ОДИН пакет, и держит он его на настоящей базе. Выпадет он из набора — по недосмотру, из-за недоступных контейнеров, при переименовании — и свойство перестанет проверяться НИГДЕ, а ссылки на него останутся и будут читаться как покрытие. Форма остаётся, содержание исчезает молча.

Поэтому разбор требует не сужения у дублёров, а РЕЗОЛВИМОСТИ ссылки: снятие держателя роняет прогон с ЕГО ИМЕНЕМ, а не тишиной.

Почему разбор синтаксиса для одной части и комментарии для другой ¶

Снисходительность — свойство ИСПОЛНЯЕМОГО кода (значение поля в литерале области), и ищется разбором: поиск подстроки нашёл бы слово в комментарии, объясняющем эту же проверку. Ссылка на держателя — наоборот, живёт ИМЕННО в комментарии, потому что адресована читателю; её и ищем в комментариях, разобранных парсером, а не в сыром тексте файла.

ДВА написания координаты — обе законны, и разбор обязан знать обе ¶

Здесь порт расходится с монорепошным оригиналом, и расходится ЗАМЕРОМ. Там координата была одна — `internal/apps/kaname/api/<пакет>`. Здесь в дереве живут ОБЕ формы, и обе законны: приставка `services/iam/` остаётся канонической для вызовов `platformtree` (`treeposture.PathOf` принимает координату ОТ КОРНЯ ДЕРЕВА ПЛАТФОРМЫ и снимает приставку сам, когда модуль стоит самостоятельным клоном), а без приставки пишут там, где адресуют каталог этого модуля напрямую.

Замер на дереве: строк-комментариев с приставкой — 53 в 31 файле, строк кода с ней же — 20, и КАЖДАЯ из двадцати законна by construction: это аргументы `platformtree`.

ЧТО ЭТА ОСЬ СЕГОДНЯ МЕНЯЕТ, НАЗВАНО ЧЕСТНО — вердикта она не меняет, и сказать это надо прямо, иначе следующий прочтёт её как закрытый дефект. Перемер образцом только с приставкой: пакетов 27, снисходительных 7, держателя называют те же 7, находок 0 — то есть ровно столько же. Голая форма слепой не бывает by construction (она совпадает и ВНУТРИ приставочной), а приставочная теряет сегодня лишь 4 ссылки переписи из 54.

Ось заведена не ради сегодняшнего числа, а ради ЗАВТРАШНЕГО: ссылка, написанная в голой форме в пакете, где другой ссылки нет, при однобразцовом распознавателе дала бы не красное и не зелёное, а невидимость. Перепись печатает обе величины порознь, поэтому смена соотношения будет видна числом, а не догадкой.

Граница, объявленная самим разбором ¶

Судятся только пакеты, которые снисходительного дублёра ЗАВОДЯТ. Пакет без него под разбор не подпадает — там нечему быть снисходительным. «Ноль находок» означает «у каждого снисходительного назван живой держатель», а не «снисходительных нет»: перепись печатает оба числа.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/listscopedoubleisnotlenient_test.go` (семейство снято вынесением службы — `kacho#2598`; предмет жив здесь, задача #17). Изменилось: корень обхода (приставки `services/iam/` в самостоятельном клоне нет), разбор вынесен из пробы в пакет `check`, распознаватель знает обе формы координаты. Осталось дословно: имя гейта (`TestLenientScopeDoubleNamesALiveHolder`), предмет, граница и то, что снисходительность ищется разбором, а ссылка — в комментариях.

Близнеца в платформе нет: семейство снято там вместе со службой (ban #20).

login_verifier_containment.go — ЯДРО гейта: проверочный материал способа входа выходит из своего типа ТОЛЬКО в названном файле и не уходит из него мимо объявленного потребителя, а таблицу секрета называет ТОЛЬКО её адаптер (фаза Ф2, `kacho#1268`).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Материал пароля живёт в типе `domain.LoginVerifier`, который не печатается, не пишется в журнал и не сериализуется: каждый общий путь вывода отдаёт заглушку либо отказ (`internal/domain/login_method_test.go`). Выход у материала ОДИН — метод `Reveal`, — и он нужен ровно тем, кто кладёт материал в базу и сверяет с ним предъявленное.

Правил три:

1. ВЫХОД вне разрешённого ФАЙЛА — находка: материал достан строкой и дальше ничем не защищён.
2. ВТОРОЙ ЧИТАТЕЛЬ КОЛОНКИ — выражение вне файла-владельца, называющее таблицу секрета, — находка: он читает материал строкой, минуя тип.
3. ВЫНОС — материал из разрешённого файла, имя таблицы из файла-владельца уходят туда, куда гейт дальше не смотрит, — находка. Разбор потока — `login_verifier_flow.go`, один на оба предмета.

Разрешение даётся ФАЙЛУ, а не пакету: пакет адаптера — 70 не-тестовых файлов, и разрешение каталогу пропускало выход в любом из них.

───────────────────────────────────────────────────────────────────────────── ПЕРЕПИСЬ НАПИСАНИЙ — ЧТО РАСПОЗНАВАТЕЛЬ ЗНАЕТ, ВЫВЕДЕНО ИЗ ГРАММАТИКИ

Судится РАЗБОРОМ, а не текстом: комментарий Go, объясняющий выход, и строка с его именем законны и обязаны остаться — гейт, краснеющий на собственном объяснении, снимают первым.

Правило 1 — выход записывается ОДНОЙ формой, селектором с его именем: вызов, значение метода, выражение метода, метод через интерфейс и через встроенное поле.

Правило 2 — имя таблицы. Строковое значение Go (литерал в двойных и в обратных кавычках, с экранированием Go внутри) судится ГРАММАТИКОЙ SQL — `sql_relation_name.go`: имя без кавычек в любом регистре, в кавычках побайтово, `U&"…"` с UESCAPE, со схемой и без, внутри строки SQL (`'…'::regclass`, `EXECUTE '…'`, E-, U&-, N-, долларовая строка, продолжение, склейка `||`). Каким выражением Go это значение записано:

литерал                  "…" и `…`
склейка                  `+` литералов, констант, приведений `string(…)`
                         и к строковому типу корпуса; судится свёрнутое
                         значение и отдельно каждое звено
связанное имя            константа либо переменная уровня пакета, чьё
                         значение называет таблицу, — в том числе
                         повторённая неявно в группе `const (…)`; сама
                         константа владельца — такое имя
локальная константа      `const` внутри функции участвует в склейке
селектор другого пакета  `пакет.Имя` — с именем пакета, псевдонимом импорта и
                         через импорт с точкой

Правило 3 — вынос: возврат, именованный результат, переменная пакета (своего и чужого, её поле, элемент, ключ карты), память параметра и получателя, канал, аргумент функции чужого файла, непрозрачный вызов без объявления потребителя, встроенный вывод. Результат ПРЕОБРАЗУЮЩЕГО потребителя несёт предмет и ведётся дальше (kaname#139). Полный перечень и то, что несёт предмет, — шапка `login_verifier_flow.go`. Переменная пакета в разрешённом файле, чьё значение обращается к выходу, — вынос материала сама по себе.

Объявление предмета (имя выхода, файл и тип, где он объявлен, имя таблицы, разрешённые файлы, потребители) приходит ПАРАМЕТРОМ из файла пробы: литерал имени таблицы в этом файле сделал бы гейт своей же первой находкой, а файл пробы в корпус не входит by construction.

───────────────────────────────────────────────────────────────────────────── ПРЕМИСЫ — ОТКАЗ, А НЕ МОЛЧАНИЕ

• выход объявлен РОВНО ОДИН раз, в названном файле, на названном типе. Иначе селектор с тем же именем означает не этот выход, и перепись мерит чужой метод;
• файл-владелец таблицы называет её хоть раз: иначе второе правило ослепло;
• каждый разрешённый файл выход ИСПОЛЬЗУЕТ, каждый объявленный потребитель получает предмет: разрешение без предмета — место, куда вызов вносят незамеченным (послабление обязано истекать само);
• каждый потребитель объявлен с ВИДОМ и причиной, чистая позиция преобразующего — с причиной и не отрицательна: иначе отказ прогона, а не «находок ноль». Чистая позиция за последней позицией результата — находка (ей нечего разрешать), где число позиций синтаксис называет.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

1. ФАЙЛЫ ПРОБ НЕ СУДЯТСЯ: пробе законно достать материал, чтобы сверить его побайтово, а фикстуре инъекции — написать форму дефекта. Файл пробы — `*_test.go` и оснастка проб `internal/testsupport/` (отбор `ShippedGoFile`): общая фикстура многих пакетов лежит в обычном файле, потому что `*_test.go` чужого пакета не импортируется (kaname#816). Что прод-сборка оснастку не импортирует, держит `ProbeToolingImports`.
2. ИМЯ, СОБРАННОЕ ВО ВРЕМЯ ИСПОЛНЕНИЯ, НЕ УЗНАЁТСЯ: `fmt.Sprintf`, `strings.Join`, `+=` к переменной, срез байтов — это поток данных, а не синтаксис. В дереве такой формы нет; появится — гейт промолчит.
3. ГРАНИЦЫ РАЗБОРА ПОТОКА — срез либо карта, скопированные присваиванием, материал, прочитанный владельцем из базы до обёртки в тип, отражение — названы в шапке `login_verifier_flow.go`.
4. ГРАНИЦЫ РАСПОЗНАВАТЕЛЯ SQL — имя, собранное во время исполнения, аргумент `format('%I', …)` — названы в шапке `sql_relation_name.go`.
5. ПУТЬ ВНЕ GO НЕ СУДИТСЯ: базу судит соседний гейт схемы `internal/repo/kaname/pg` `TestLoginVerifierStaysInsideTheSchema`, тем же распознавателем имени.

login_verifier_flow.go — РАЗБОР ПОТОКА предмета внутри файлов, которым он разрешён: материала способа входа — внутри разрешённых файлов, имени таблицы секрета — внутри файла-владельца. Предметов два, разбор один: вынос у них записывается одними и теми же формами, и вторая копия разбора разошлась бы с первой молча — ровно на той форме, которую знает одна из копий.

───────────────────────────────────────────────────────────────────────────── ЧТО ЗДЕСЬ «ВЫНОС» — ВСЕ СТОКИ ГРАММАТИКИ GO

Значение несёт предмет, если оно им является (источник), либо собрано из несущего: склейка `+`, приведение к предобъявленному типу (строке, числу — приведение к числу не очищает: `uint8(часть[0])` — байт материала), срезу байтов либо типу корпуса, взятие адреса, разыменование, индекс, срез, утверждение типа, составной литерал с несущим элементом (у карты — и с несущим ключом), встроенные `append`/`min`/`max`, замыкание, возвращающее несущее, и его вызов на месте, РЕЗУЛЬТАТ ПРЕОБРАЗУЮЩЕГО ПОТРЕБИТЕЛЯ (ниже) и результат функции своего файла, чей возврат нёс предмет. Хранилище, куда несущее положено, несёт его дальше; обход `range` по несущему делает несущими ключ и значение. Многозначный вызов судится по ПОЗИЦИЯМ во всех пяти местах, где грамматика Go его допускает: присваивание (`a, b, ok := f()`), объявление (`var a, b = f()`), возврат функции и возврат замыкания (`return f()`), единственный аргумент (`g(f())` — позиция i результата f есть аргумент i функции g). Где число позиций синтаксис не называет (оба вызова — непрозрачные), вызов несёт предмет, если несёт ЛЮБАЯ его позиция, — строже.

Вынос — любое место, откуда предмет уходит из файла мимо гейта:

возврат функции              значение возврата несёт предмет
именованный результат        присваивание ему — в том числе составное и
                             из отложенного замыкания: оно уходит вызывающему
переменная пакета            присваивание ей, её полю, её элементу; предмет
                             ключом её карты; переменная ДРУГОГО пакета
память параметра, получателя присваивание через них: поле, элемент,
                             разыменование, `copy` в них
канал                        отправка
вызов функции корпуса        аргумент либо получатель функции или метода,
                             объявленных в файле, которому предмет не
                             разрешён (соседний файл того же пакета, другой
                             пакет корпуса)
непрозрачный вызов           вызов, внутрь которого гейт не видит
                             (библиотека, метод значения, чей тип синтаксис
                             не называет, функция-значение), — находка, если
                             он не объявлен ПОТРЕБИТЕЛЕМ с причиной
встроенный вывод             `panic`, `print`, `println`
память без владельца         присваивание в поле результата вызова

Вызов функции СВОЕГО разрешённого файла выносом не является: предмет остаётся в файле, и разбор продолжается в её теле с отмеченными параметрами — до неподвижной точки. Обратная половина — ВОЗВРАТ СВОЕМУ ФАЙЛУ: возврат предмета из функции, которую зовёт ТОЛЬКО её файл (без получателя, неэкспортируемая, упомянута лишь вызовом и лишь в своём файле — `lvInternal`), выносом не является, и результат её вызова у вызывающего несёт предмет по позициям. Возврат из любой другой функции — вынос.

Отдать материал КОНСТРУКТОРУ ЕГО ТИПА (функция файла объявления выхода без получателя, чей результат называет тип) — не вынос, а возврат под защиту типа; перепись считает такие вызовы отдельно. Любая другая функция того же файла судится как функция корпуса.

ПОТРЕБИТЕЛЬ — непрозрачный вызов, которому предмет отдан по существу. Объявляется в `LoginVerifierSpec.OpaqueConsumers` ключом «функция → вызов» с ВИДОМ и причиной (kaname#139); объявление без вызова — находка (послабление обязано истекать само), объявление без вида — отказ прогона. Видов два:

поглощающий     оператор базы, сравнение, односторонняя функция: результат
                — признак исхода либо величина, из которой предмет не
                восстановить; ни одна позиция результата предмета не несёт
преобразующий   строковая операция, декодирование, разборщик, снятие
                обёртки: результат собран ИЗ предмета и несёт его в каждой
                позиции, кроме объявленных чистыми с причиной (признак
                «найдено», ошибка, не несущая входа). Результат ведётся
                дальше, как выход `Reveal`: часть, возвращённая из файла, —
                находка, часть, отданная необъявленному вызову, — находка.

Перепись называет порознь объявленных потребителей и прослеженные результаты: «потребителей N» не говорит, сколько результатов разбор вёл.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

1. ПСЕВДОНИМ ЗНАЧЕНИЕМ: указатель, взятый адресом (`p := &out; p.m = x`), и его копии прослеживаются до цели; срез либо карта, скопированные присваиванием (`ys := xs; ys[0] = x; return xs`), — нет: без типов синтаксис не отличает такую копию от копии значения.
2. ИСТОЧНИК ПОТОКА МАТЕРИАЛА — ВЫХОД `Reveal`. Материал, прочитанный владельцем из базы до обёртки в тип, — строка, и её путь внутри файла гейт не видит; держит ревью единственного разрешённого файла.
3. ОТРАЖЕНИЕ и `unsafe` синтаксического следа не оставляют.
4. ВИД ПОТРЕБИТЕЛЯ ГЕЙТ НЕ ПРОВЕРЯЕТ: внутрь вызова библиотеки он не видит, и «поглощающий», объявленный вызову, чей результат на деле несёт предмет, замолчит о его выносе. Вид держится причиной в ведомости, сверенной с кодом вызова, и ревью ведомости. Оператор базы, ЧИТАЮЩИЙ материал, объявлен поглощающим по границе 2: строка, прочитанная владельцем, до обёртки в тип не ведётся.
5. СТРОЖЕ, ЧЕМ НУЖНО, — названо, чтобы не чинилось ослаблением: сводка возврата функции своего файла одна на все места вызова (контекст не различается); структура, в поле которой лёг предмет, несёт его вся — число в соседнем поле тоже; признак `ok` у `v, ok := m[k]` и подобных некомпонентных форм несёт предмет вместе со значением; многозначный вызов, чьё число позиций синтаксис не называет (непрозрачный вызов аргументом непрозрачного либо вариадического), несёт предмет, если несёт любая позиция, и отдаёт его всем параметрам получателя.

mail_kind_sender_parity.go — перепись ВИДОВ ПИСЬМА против их ОТПРАВИТЕЛЕЙ (приёмка `docs/engineering/acceptance/recovery-of-access.md`, Р3, сценарии Ф5-10 и Ф5-11; задача PRO-Robotech/kacho#1271).

Две стороны одного словаря ¶

Вид письма объявлен ДВАЖДЫ, и оба объявления обязательны:

• СХЕМОЙ — ограничением на колонку вида события очереди писем: строку другого вида база не принимает. Это закрытый словарь того, что вообще может лечь в очередь;
• ПРИМЕНИТЕЛЕМ — функцией формы `drainer.Applier` (`func(ctx, eventType string, payload T) error`), которая ветвится на своём параметре вида и сдаёт письмо узлу. Вид, на который применитель не ветвится, у него — «неизвестный», и строка отравляется, а не отправляется.

Расходятся они молча: миграция и функция правятся разными коммитами, и каждая по отдельности зелена. Гейт кладёт их рядом.

Что распознаётся — все законные формы записи, по каждой инъекция ¶

Схема: `CONSTRAINT … CHECK ((event_type = ANY (ARRAY['…'::text, …])))` в теле `CREATE TABLE`, и то же выражение в `ALTER TABLE … ADD CONSTRAINT`. Ограничение, снятое `DROP CONSTRAINT` и не объявленное заново, из словаря уходит. Читается ТОЛЬКО секция `+goose Up`: секция отката несёт то же имя с обратным смыслом. Последнее живое объявление побеждает — в порядке версий миграций, а он же и лексикографический порядок имён.

Применитель: сравнения `eventType ==`/`!=` с константой либо литералом и `switch eventType { case …: }`. Константа разрешается через словарь строковых констант прод-корпуса (общий помощник семейства дренажа); неразрешимое имя считается отдельно в переписи, а не молчит.

Обе стороны судят по УЗЛУ, а не по подстроке: проза этого же файла несёт каждое из искомых слов.

Чем ограничено — сказано вслух ¶

Пространство видов письма — `mail.`. Словарь очереди, ни один вид которого не в этом пространстве, к письмам не относится и переписью не учитывается. Применитель, ветвящийся на вид через промежуточную переменную (`k := eventType; if k == …`), распознавателю невидим; в дереве такой формы нет, и её появление обязано прийти сюда новой инъекцией, а не молчанием.

mail_send_paths.go — MAIL-47 приёмки ID-MAIL-1: путей отправки письма у нас РОВНО ОДИН, и отправляет он ТОЛЬКО наши виды письма.

Предмет ¶

Видов письма в продукте пять (подтверждение адреса, восстановление доступа, приглашение, код смены адреса и уведомление о смене адреса), и все пять отправляем МЫ. Приглашение — наше по решению Р23 приёмки ID-MAIL-1: его предмет — строка в НАШЕЙ базе. Восстановление доступа — наше с фазы Ф5 (одобренная `docs/engineering/acceptance/recovery-of-access.md`, Р3 и Д5): код чеканим мы, поток поставщика истёк вместе с поставщиком. Подтверждение адреса — наше по одобренной `docs/engineering/acceptance/access-beyond-login-needs-a-verified-address.md` (kaname#456, Р8): приёмка назвала переезд, код подтверждения чеканим мы, и без него человеку не открывается ничего дальше экрана подтверждения. Код смены адреса и уведомление о смене — наши по одобренной `docs/engineering/acceptance/email-change-is-confirmed-from-the-new-address.md` (kaname#635, Р7): глагол смены — наш с первого дня.

Перечень НАШИХ видов — `OurMailKinds` — закрыт и объявлен один раз; вид входит в него ТОЛЬКО одобренной приёмкой, назвавшей переезд, а не правкой гейта под покрасневший прогон.

Отсюда два признака нарушения, и каждый сам по себе достаточен:

• ВТОРОЙ путь отправки того же вида нарушает Р1 («два способа доставить одно и то же письмо, и какой сработает, решает порядок»);
• НАШ путь отправки вида вне перечня означает, что вид уехал к нам без приёмки, назвавшей переезд: у письма стало два производителя, и какой доедет, решает порядок, а не решение.

Что здесь считается путём отправки — ДВЕ оси ¶

1. ТРАНСПОРТ. Не-тестовый файл Go, импортирующий пакет, который говорит с почтовым узлом. Список объявлен закрытым (`mailTransportTokens`), его предпосылка проверяется: якорный пакет `net/smtp` обязан найтись в дереве хотя бы раз, иначе ось судит пустоту и молчит по этой причине, а не по существу.

   Закрытый список знает ровно то, что в нём названо, — поэтому импорт, говорящий о почте словом в пути и не объявленный ни транспортом, ни не-транспортом (`mailNotTransport`), ни пакетом своего модуля, есть ОТКАЗ «форма разбору неизвестна», а не тишина. Второй отправитель на библиотеке вне списка иначе уезжал бы из-под наблюдения: якорная предпосылка на нём молчит (`net/smtp` в дереве остаётся), ось словаря молчит, если вид взят константой хранилища, а не литералом. Отказ снимается тем, кто форму знает: библиотека вносится в один из двух списков этим же изменением.

2. СЛОВАРЬ ВИДОВ. Строковый литерал вида `mail.<вид>.send` — имя события очереди писем, чей словарь закрыт CHECK'ом миграции. Вид, отличный от приглашения, есть находка ГДЕ УГОДНО в не-тестовом дереве, даже без транспорта рядом: расширить словарь молча нельзя, а расширенный словарь означает второй вид письма, уехавший от нас.

Вид письма, который отправляет путь, БЕРЁТСЯ ИЗ ЕГО ЖЕ ФАЙЛА — литералом оси 2. Путь, не назвавший вида, — находка: перепись обязана печатать ДВЕ величины, и вторая из воздуха не берётся.

Чего разбор НЕ видит — названо прямо ¶

Отправитель, написанный на голом сокете и говорящий по протоколу почты руками, осью 1 не опознаётся: он не импортирует ничего почтового. Границу закрывает ось 2 — такой отправитель всё равно обязан взять своё событие из очереди, а словарь очереди закрыт миграцией. Библиотека транспорта, чей путь импорта о почте не говорит ни словом (`sendgrid`, `ses` названы в списке именно поэтому), под отказ формы не подпадает — её место в списке, а не в предикате.

Путь — ОБЪЯВЛЕНИЕ, ОТКРЫВАЮЩЕЕ РАЗГОВОР, а не файл (kaname#175). Внутри файла, импортирующего транспорт, путём считается каждое объявление верхнего уровня, зовущее открывающую функцию транспорта (`mailTransportOpeners`: `Dial`, `NewClient`, `SendMail`, …) через имя его импорта; второе такое объявление в том же файле — второй путь, и находка называет оба. Объявление, упоминающее транспорт без открытия разговора (`smtp.PlainAuth`, тип `smtp.Auth`), путём не является. Файл, импортирующий транспорт и не открывающий разговора ни одним объявлением, остаётся одним путём на строке импорта: вид и производитель у него судятся по-прежнему, молчать о нём нельзя.

Об отправителе, живущем в ЧУЖОМ процессе, гейт не утверждает НИЧЕГО (круг 6, В3): его в нашем дереве нет и быть не может, а проверка, требующая утверждения о непрочитанном, есть «ноль находок» без прочтения. Что письма действительно уходят, утверждают сквозные пробы на поднятом стенде, наблюдая письмо у приёмника. Здесь утверждается, что у каждого нашего вида ровно один путь отправки, а вида вне перечня наш код не отправляет.

manifest_verb_class_rule.go — два распознавателя для свойств ДЕРЕВА, которых проба пакета утверждать не может.

1. правило «класс действия из его ИМЕНИ» объявлено в дереве РОВНО ОДИН РАЗ. Проба пакета о числе объявлений не утверждает ничего: она зелена при любом. Единственность объявления делает второе место НЕПРЕДСТАВИМЫМ, и это сильнее тождества импорта: появится генератор — импортировать ему будет нечего, кроме одной функции, by construction;

2. правило вывода «тип объекта из имени ресурса» СНЯТО и не возвращено тихо. Приёмка сняла его замером, и без держателя его можно вернуть молча: ключ перестал бы быть обязательным, а восстанавливающее правило поселилось бы в ДВУХ местах — в генераторе (когда опускать) и в загрузчике (как восстановить).

Как распознаётся правило «класс из имени» — и почему НЕ по набору литералов ¶

Наивный распознаватель («объявление, чей набор строковых литералов равен пяти каноническим») даёт ЛОЖНУЮ находку: рядом живёт ПОРЯДОК ПОКАЗА глаголов, набор у которого тот же, а референт другой. Гейт, краснеющий на верном коде, отключают первым.

Поэтому распознаётся ПАРА: функция, отвечающая «класс и получилось ли» (результаты `(string, bool)`), и набор ровно пяти канонических токенов, до которого она дотягивается — своим телом либо объявлением того же файла. Порядок показа под это не подпадает: его читает функция с ОДНИМ результатом.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/manifestverbclassrule_test.go` (семейство снято вынесением службы, `kacho#2597`; предмет жив здесь — задача #17). Изменилось: каталог загрузчика (приставки `services/iam/` в самостоятельном клоне нет), пакет, и вход распознавателей — исходник вместо уже разобранного узла: разбор живёт теперь в одном месте, а проба и инъекция подают ему текст. Осталось дословно: имена обоих гейтов, пара признаков и тексты находок.

membership_removal_expires_invite.go — MAIL-46 приёмки ID-MAIL-1: глагол, снимающий участие, ОБЕСЦЕНИВАЕТ невыкупленное приглашение.

Предмет ¶

Строка приглашения ГЛОБАЛЬНА, членства — по аккаунту. Сняв членство и оставив строку ждущей выкупа, продукт оставляет приглашение действующим: первый вход человека переводит строку в состояние участника и со-коммитит указатель на ТОТ САМЫЙ аккаунт, из которого его исключили. Заметить это неоткуда — отказа нет, красного нет, человек просто оказывается там, где ему быть не положено.

Предикат судит ИСХОД, а не ИМЯ ¶

Требование приёмки сформулировано по исходу — «человек перестал быть участником», — поэтому и гейт ищет исход: оператор, СНИМАЮЩИЙ СТРОКУ ЧЛЕНСТВА, в каком бы глаголе он ни стоял. Новый глагол того же смысла попадает под гейт по построению, а переименование прежнего его не снимает — тогда как перечень имён разошёлся бы с деревом молча на первом же заведённом глаголе.

Что считается обесцениванием ¶

Запись СРОКА на строку приглашения (`invite_expires_at`) — то самое плечо, которое делает её невыкупаемой. Оно обязано стоять в ТОЙ ЖЕ функции: между двумя операторами, разнесёнными по функциям, появляется окно, в котором первый вход видит членств ноль и срок живым.

Чего гейт НЕ видит — названо прямо ¶

Снятие членства каскадом чужого ограничения либо триггером базы этим разбором не опознаётся: он читает код Go, а не схему. Граница закрыта с другой стороны — интеграционной пробой (`internal/repo/kaname/pg/invite_revoked_on_removal_integration_test.go`), которая судит ИСХОД на живой базе, чем бы членство ни снималось.

migration_not_a_writer_of_module_role.go — разбор миграций и манифестов: роль модуля, у которого ЕСТЬ манифест, пишет применитель, а не миграция.

Предмет ¶

Миграция, вставившая такую роль, заводит ВТОРОГО писателя одного предмета: два места разойдутся молча — правка манифеста не доедет до строки, потому что строку держит миграция, а перепись применителя об этом ничего не скажет.

Перечень модулей с манифестом ВЫВОДИТСЯ, а ведомость НЕ заводится ¶

Ведомость «модули без манифеста» есть второе место об одном предмете, и расходится оно МОЛЧА — ровно в тот день, когда у модуля появляется или исчезает манифест. Производный перечень истекает BY CONSTRUCTION: запись исчезает вместе с появлением манифеста, и истекать вручную нечему.

Число манифестов здесь намеренно НЕ выписано вторым местом: оно растёт с каждым новым модулем и устарело бы молча. Узнаётся одной командой:

git ls-files '*manifest.yaml' | wc -l    # сколько их в дереве СЕЙЧАС

Как узнаётся манифест — по СОДЕРЖИМОМУ, а не по пути ¶

Разбор, привязанный к пути, молчал бы вечно, окажись путь другим, — и его молчание было бы неотличимо от чистоты. Поэтому манифест опознаётся парой ключей верхнего уровня: объявлением версии контракта и именем модуля.

Форм записи имени роли ДВЕ, и обе законны ¶

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

Чего разбор НЕ видит — названо ¶

1. **фикстуры проб** — они объявляют чужой модуль и сделали бы его «модулем с манифестом», превратив каждую его миграцию в находку. Исключены по каталогу, и это единственное исключение;
2. **манифест, приезжающий не файлом дерева** (карта настроек, том) — его в дереве нет by construction, и разбор о нём ничего не утверждает;
3. **имя роли, записанное литералом идентификатора** — такие роли вне закрытого набора модулей, то есть находкой быть не могут ни при каком манифесте.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/migrationnotawriterofmodulerole.go` (снято вынесением службы — `kacho#2598`; предмет жив здесь, задача #17). Разбор перенесён БЕЗ правок логики: его операнды — текст манифеста и текст миграции, и ни один не несёт координаты дерева. Изменились только координаты в гейте рядом.

Близнеца в платформе нет: семейство снято там вместе со службой (ban #20).

migration_section_split.go — ЯДРО гейта: директива секции мигратора объявлена в дереве ОДИН раз, а не выписана заново каждым, кому понадобился прямой ход миграции.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ: популяция шире предмета, и расходится она молча

Прямой ход миграции и обратный — РАЗНЫЕ утверждения. Накат обязан быть применим к живым строкам; откат восстанавливает снятое, и ни в одном развёрнутом дереве его строк нет. Разбор, читающий файл целиком, меряет величину, которой не существует.

Разрез поэтому нужен многим, и каждый, кому он понадобился, писал свой. Замер на дереве 2026-09-14 дал ОДИННАДЦАТЬ реализаций одного разреза, и они давали ПЯТЬ разных ответов на один вопрос — «что делать с файлом без маркера прямого хода»: отдать тело целиком ВМЕСТЕ С ОТКАТОМ · отдать пустую строку · отдать всё от начала · отказать · не спрашивать вовсе. Сегодня оба маркера стоят у всех семнадцати миграций, поэтому расхождение молчит: премиса держится СОВПАДЕНИЕМ, а не устройством. Ровно так же держалась премиса гейта пика аккаунтов до `kacho#2363` — до первого оператора вставки в откате.

───────────────────────────────────────────────────────────────────────────── ЧТО СУДИТСЯ И ПОЧЕМУ ИМЕННО ЭТО

Находка — СТРОКОВЫЙ ЛИТЕРАЛ с директивой секции в не-тестовом файле Go вне файла-владельца разбора. Не «вызов, который режет»: разрез бывает записан десятком форм (`Index`, `Cut`, `Split`, срез по двум индексам), и распознаватель форм вызова знал бы их не все — то есть молчал бы на незнакомой, а молчание от чистоты не отличить. Литерал же в не-тестовом коде законного предмета не имеет вовсе: директива объявлена константой, и взять её неоткуда, кроме владельца.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

1. ФАЙЛЫ ПРОБ НЕ СУДЯТСЯ. Фикстура синтетической миграции обязана нести директиву дословно — это её содержимое, а не копия разбора. Гейт их не читает by construction, и восемь таких копий разреза в пробах дерева остаются его слепой зоной. Названо числом, а не умолчанием.
2. СКЛЕЙКА НЕ УЗНАЁТСЯ. Директива, собранная сложением частей, под предикат не подпадает. Форма в дереве не встречалась ни разу; появится — гейт промолчит, и это его граница, а не чистота.
3. КОММЕНТАРИЙ — НЕ ЛИТЕРАЛ. Проза о директиве законна и обязана остаться: гейт, краснеющий на собственном объяснении, снимают первым.

Собственного литерала у этого файла нет: он спрашивает написание у владельца (`migrations.SectionMarkerStem`). Иначе гейт был бы своей же первой находкой, и его пришлось бы прощать — то есть заводить послабление там, где его можно не заводить вовсе.

mirror_catalog_condition.go — разбор: УСЛОВИЕ КАТАЛОГА НЕСЁТ КАЖДЫЙ ПИСАТЕЛЬ ЗЕРКАЛА.

Предмет ¶

Зеркало каталога ресурсов — проекция, которую владельцы присылают через проксируемую полосу регистрации. Требование «тип обязан иметь живую строку каталога» выражено ОПЕРАТОРОМ записи, а не внешним ключом: постоянное ограничение запретило бы платформе снять тип, пока у арендатора есть ресурс этого типа, то есть сделало бы решение платформы заложником данных арендатора.

Цена выбора: инвариант стал свойством ПОЛОСЫ, а не свойством ТАБЛИЦЫ. Инвариант, выраженный в одном операторе из нескольких, — это инвариант, которого нет: второй писатель обходит его молча, и обнаруживается это тогда, когда данные уже записаны. Этот разбор — второй рубеж под тем же утверждением.

Требование ВЫВОДИТСЯ из эталонной полосы, а не задаётся литералом ¶

Две копии одного условия разошлись бы молча — и разошлись бы именно там, где расхождение не видно: обе выглядели бы исправными. Поэтому условие берётся у полосы, через которую идёт регистрация от владельцев, и сверка идёт МЕЖДУ полосами. Переедет эталон — разбор объявит ОТКАЗ, а не промолчит.

Каталог берётся ИЗ ТОГО ЖЕ ЛИТЕРАЛА ¶

Обещание сверки, данное в комментарии рядом, условием не является — иначе писателю довольно было бы пообещать её словами.

Признак таблицы каталога — ПРЕФИКС, а не перечень ¶

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

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/mirrorcatalogcondition_test.go` (снято вынесением службы — `kacho#2598`; предмет жив здесь, задача #17). Изменилось: координаты эталонной полосы и владельца таблицы (приставки `services/iam/` в самостоятельном клоне нет — модуль и есть владелец, поэтому проверка «писатель вне владельца» здесь выродилась бы в тождество и заменена проверкой, что писатель лежит В ДЕРЕВЕ МОДУЛЯ); разбор вынесен из пробы в пакет `check`. Осталось дословно: имя гейта, перечень глаголов записи с признаком «вводит строку», вывод условия из эталона и самоистечение ведомости.

Близнеца в платформе нет: семейство снято там вместе со службой (ban #20).

mirror_divergence_wiring.go — у ЧТЕНИЯ РАЗНОСТИ зеркала и каталога обязан быть ВЫЗЫВАЮЩИЙ в композиционном корне (kacho#1828).

Предмет ¶

Разность зеркала и живого каталога — величина, от которой зависит решение владельца об отзыве, а отзыв ОТНИМАЕТ доступ. Читатель этой разности в дереве есть и хорошо построен; до этого гейта его не спрашивал НИ ОДИН путь исполнения — только интеграционные пробы. Механизм без вызывающего от отсутствующего неотличим: на поднятом стенде величина не производится, и «разности нет» читается ровно так же, как «никто не мерил».

Почему гейт судит УЗЕЛ ВЫЗОВА, а не слово ¶

Имя читателя встречается в этом дереве и прозой — в объяснениях, включая объяснение самого гейта. Проверка по подстроке краснела бы на собственном комментарии, а зеленела бы на закомментированном вызове.

Какие формы записи вызова гейт знает ¶

Обе законные: `resource_mirror.Divergence(…)` и вызов через АЛИАС импорта (`mirror "…/resource_mirror"` → `mirror.Divergence(…)`). Локальное имя пакета берётся из блока импортов каждого файла, а не предполагается равным последнему сегменту пути. Форма, о которой распознаватель не знает, — не редкость, а слепая зона: всё, записанное в ней, оказывается вне наблюдения.

Чем этот гейт НЕ является ¶

Он не утверждает, что разность ПУСТА, и не вправе: непустая разность на стенде арендатора — предмет решения владельца, а не находка проверки. Предмет здесь один — ВЫЗЫВАЮЩИЙ существует.

module_identity_seeded_only_by_baseline.go — личность модуля заводит ТОЛЬКО применённая базовая миграция (ПР-5 приёмки WIRE-1, задача продукта kacho#2098).

Порт с монорепо (`internal/repohygiene/moduleidentityseededonlybythebaseline_test.go`, снят вынесением службы — `kacho#2597`). В монорепо предикат жил ЦЕЛИКОМ внутри `_test.go` (пакет-«внешний тест», без отдельного `.go`); здесь он вынесен в не-тестовый файл, потому что кроме гейта его читает пересчёт.

ПРЕДМЕТ (дословно из монорепо) ¶

Личности модулей посеяны БАЗОВОЙ миграцией, то есть приезжают и в установку, где платформы нет вовсе. Строка, которую арендатор, развернувший службу доступа отдельно, нести не обязан, — это данные окружения, и в миграцию они не идут ни при каких условиях (§«Данные СТЕНДА заводятся посевом»).

СОСТОЯНИЕ НА ДЕНЬ ПЕРЕНОСА — ДРУГОЕ, чем в монорепо, и это названо числом ¶

В монорепо (на день заведения гейта) долг был НЕПОДВИЖЕН: применителя у раздела `seed` манифеста не было, применённую миграцию не поправить (ban #5), а свежая установка без платформы несла пять личностей чужого продукта.

В kaname этот долг ЗАКРЫТ отдельной задачей — kacho#2452 (`20260909202745_module_identities_leave_the_baseline.sql`, применена ДО выноса службы из монорепо, то есть закрытие произошло в исходном дереве, а не в этом порту): пять личностей (`kacho-vpc`, `kacho-compute`, `kacho-nlb`, `kacho-registry`, `kacho-storage`) СНЯТЫ этой миграцией, а применитель заведён (`internal/apps/kaname/moduleseed`), позван из композиционного корня. Остаются ДВЕ: `bootstrap-admin` (личность самой службы, не модульная — `IsModule()` false) и `kacho-api-gateway` (модульная, остаток, названный вслух в шапке миграции — у края манифеста нет вовсе, применителя заводить некому, снимается вместе со своим производителем).

Обе остаются посеянными БАЗОВОЙ миграцией (`0001_initial.sql`, первой в порядке применения) — то есть `moduleIdentitiesSeededOutsideTheBaseline` сегодня находит ноль нарушений. Это НЕ делает гейт вакуумным: он и дальше судит регресс — появление НОВОЙ миграции, сеющей модульную личность НЕ через применитель (ровно тот класс, который kacho#2452 только что убрал). Обновлять эту прозу нормой `kacho#2098` больше не нужно: предмет её первой половины («свежая установка без платформы несёт ноль модульных СА, кроме остатка api-gateway») закрывает kacho#2452, а не этот гейт; гейт стережёт РОСТ.

РОДСТВО, КОТОРОЕ НАДО НАЗВАТЬ — И РАЗЛИЧИЕ (дословно из монорепо) ¶

У ролей модуля такой судья есть отдельным семейством (Г2, `migrationnotawriterofmodulerole`, НЕ входит в этот батч) — запрещает миграции писать роль модуля, у которого есть манифест, ПОЛНОСТЬЮ (у ролей применитель есть). У личностей применитель тоже теперь есть — но не для ВСЕХ (api-gateway — остаток), поэтому запрет здесь остаётся УЗКИМ: не «личность модуля не сеет никакая миграция», а «личность модуля не сеет НИКАКАЯ МИГРАЦИЯ КРОМЕ БАЗОВОЙ» — тот же периметр, что был в монорепо.

ЧЕГО ГЕЙТ НЕ ЛОВИТ (названо, чтобы на него не сослались шире предмета) ¶

Он про ПОСЕВ, а не про живую базу: строку, заведённую не миграцией, он не читает by construction. И он ничего не утверждает о ПОЛНОТЕ посева.

named_verb_form_expiry.go — разбор ПАРЫ: отвергается ли поимённая форма права роли прод-кодом манифеста и есть ли в дереве пробы шести сценариев её полноты. Находка — ровно одно их сочетание: форма принята, полнота не проверяется.

Порт с монорепо (`internal/repohygiene/namedverbformexpiry.go`, снят вынесением службы — `kacho#2597`). Изменилось: пакет (`repohygiene` → `check`), путь домена (`internal/manifest/` → `internal/manifest/`, префикс `services/iam/` снят — в kaname код службы лежит от корня репозитория). Осталось дословно: разбор узла (не подстроки), закрытый перечень шести сценариев, различение двух законных причин молчания.

Почему этот перенос ОБЯЗАТЕЛЕН, а не факультативен ¶

Прод-код `internal/manifest/roleexport/check.go` (написанный ДО выноса службы, когда `internal/repohygiene` был тем же репозиторием) буквально называет держателя: «ЧЕМ ДЕРЖИТСЯ ЗАПРЕТ ... гейтом дерева `internal/repohygiene` `TestNamedVerbFormReturnsOnlyWithItsCompletenessCheck`». До этого файла держателя в дереве kaname не было ни одного: цитата утверждала присутствие проверки, которой не существует.

Предмет — ПАРА, а не любая её половина (дословно из монорепо) ¶

Принять перечень ИМЁН, не умея проверить его полноту по классу, значит свести его к классу МОЛЧА и выдать право ШИРЕ просимого (замер приёмки: 55 вхождений из 92 в черновике vpc совпадают с именем класса). Молчание гейта законно ПО ДВУМ причинам, и различать их вызывающему не нужно: форма отвергается сентинелом (возвратов > 0) ЛИБО она вернулась вместе со своей проверкой (все шесть проб MOD-RL найдены).

Замер на дне переноса (kaname@issue-2597, kacho#2597) ¶

Сентинел `ErrRoleRuleVerbsRetired` в `internal/manifest/` не объявлен и не возвращается (задача kacho#1844 сняла его вместе с формой, которую он отвергал — `f5bb097046` в истории монорепо). Все шесть проб MOD-RL (04, 04a, 18, 18a, 19, 19a) в дереве ЕСТЬ (`internal/manifest/rolenamedverbs_test.go`, `internal/manifest/roleexport/namedverbs_test.go`). Гейт сегодня молчит по ВТОРОЙ законной причине — форма вернулась вместе со своей проверкой, ровно как того требует приёмка kacho#1844, — а не по первой. Это и есть содержание переноса: без держателя регресс (снятие одной из шести проб при живом возврате перечня имён) не был бы замечен НИЧЕМ.

Чего разбор НЕ видит — названо, а не спрятано (дословно из монорепо) ¶

Возврат сентинела, собранный в рантайме (через переменную, через таблицу видов). Такой формы в этом пакете нет, и появись она — гейт увидит ноль возвратов и покраснеет, то есть ошибётся В СТОРОНУ находки, а не молчания.

paired_write.go — ПАРНАЯ ЗАПИСЬ: функция, делающая одно из двух действий, обязана делать и второе (задача kaname#313).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

В службе есть пары действий, которые поодиночке снимают доступ НАПОЛОВИНУ и выглядят исполненными целиком: две записи отсечки; снятие сессии и отзыв выданного в ней. Половина исполняется, глагол отвечает успехом, и отличить это от работающего контроля наблюдением нельзя.

───────────────────────────────────────────────────────────────────────────── СКЛЕЙКА ПО ВЫЗОВУ — УЗКАЯ, И ЭТО РЕШЕНИЕ

Второе действие часто делается ВЫЗОВОМ помощника, а не своим оператором, — разбор, не идущий по вызовам, дал бы ложную находку на всякой такой двери (измерено). Но склейка ШИРОКАЯ здесь хуже узкой, и вот почему: у соседнего прибора щедрость теряет находку о МЁРТВОМ коде, а здесь потеряла бы находку о ЖИВОМ половинном снятии доступа — у прибора, который объявлен единственным держателем пары.

Поэтому склейка ограничена тремя условиями сразу:

1. ОДИН ПАКЕТ. Имя, объявленное в чужом пакете, вызовом отсюда не разрешается; разные пакеты с одноимёнными функциями не склеиваются;
2. ОДНОЗНАЧНОЕ ИМЯ. Имя, объявленное в пакете больше одного раза, склейку НЕ даёт: какой из одноимённых вызван, разбор без типов не знает, и засчитывать любой значило бы засчитывать наугад;
3. ДОСТИЖИМЫЙ ВЫЗОВ. Вызов внутри заведомо мёртвой ветви (`if false`) не считается: дефект, спрятанный за такой ветвью, обязан ловиться. Ровно этим широкая склейка и была пробита.

───────────────────────────────────────────────────────────────────────────── ЧЕГО РАЗБОР НЕ ВИДИТ — НАЗВАНО, А НЕ СПРЯТАНО

1. приёмник вызова не разрешается: `a.Foo()` и `b.Foo()` при единственном в пакете `Foo` склеиваются одинаково. Сузить это до типа можно только разбором типов, и цена такого разбора решается отдельно;
2. мёртвая ветвь опознаётся по литералу `false`; ветвь, мёртвая по значению переменной, здесь живая;
3. действие, сделанное в схеме (триггер), не Go и здесь не судится.

password_hash_format_registry.go — гейт: перечень форматов проверочного значения сверен с ПРОВЕРЯЮЩИМИ, которые есть в дереве (приёмка ID-PW-1 §5 PWV-13 и строка 07.4).

Предмет ¶

Перечень форматов — закрытый словарь того, что продукт умеет ЧИТАТЬ. Он расходится с деревом двумя способами, и оба тихие:

• запись без проверяющего: формат объявлен, читателя нет. Значение такого формата доезжает до входа и получает исход «формат вне перечня» — то есть человек с верным паролем не входит, а перепись переноса его пропустила, потому что признак в перечне ЕСТЬ;
• проверяющий без записи: читатель есть, потолка у него нет. Тогда параметры стоимости берутся из самого значения без всякой границы, и чужой источник назначает цену каждой попытки.

Оба расхождения гейт называет находкой. Снятие записи ВМЕСТЕ с проверяющим он пропускает — дерево согласовано, — и это НЕ разрешение снимать: хранилищ установок гейт не читает, разрешение даёт перепись каждой из них (Р8, PWV-17). Сказано прямо, чтобы зелёный этого гейта не прочитали шире.

Что судится, и почему признаком СВОЙСТВА, а не именем ¶

«Проверяющий формата есть в дереве» опознаётся не по имени функции — имя переименуют, и гейт замолчит, — а по ВЕТВИ КЛАССИФИКАТОРА: в функции выбора стоит ветвь, которая по признаку формата уходит в свою функцию. Признак берётся из строковой константы, на которую ветвь ссылается, то есть из того же места, откуда его берёт исполняемый код.

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

Границы, названные вслух ¶

1. ЗАПИСИ ПЕРЕЧНЯ приходят ДОВОДОМ, а не разбором: их объявляет домен, и он же их проверяет. Гейт судит поданное — тем же, чем судил бы прочитанное, но без второго разбора одного предмета.
2. ВТОРОЕ ОБЪЯВЛЕНИЕ перечня ищется по составному литералу записи вне файла перечня. Литерал в пробе сюда не попадает: корпус не-тестовый.
3. ЭТАЛОН ПОЛА приходит доводом и правится вместе с нормой, на которой стоит. Читать его из текста приёмки гейт не вправе: он сверялся бы с прозой, а не с нормой (§8 приёмки).

password_rule_sole_declaration.go — ГЕЙТ КЛАССА: правило пароля объявлено в дереве ОДИН раз, и всякая полоса, меняющая материал, зовёт его, а не несёт своего (приёмка Ф3, сценарий Ф3-32; Ф1-38; задача kacho#1269).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Три полосы меняют материал пароля: смена пароля (Ф3), регистрация (Ф4), восстановление (Ф5). Правило — минимальная длина, сходство с почтой, база утечек — у них ОДНО. Второе объявление правила разошлось бы с первым молча, и человек, чей пароль принят на регистрации, получил бы отказ на смене — либо наоборот, и второе хуже: правило, которое строже на входе и мягче на смене, есть правило только на бумаге.

───────────────────────────────────────────────────────────────────────────── ЕДИНИЦА СЧЁТА — ОБЪЯВЛЕНИЕ ПРАВИЛА, УЗНАННОЕ РАЗБОРОМ, А НЕ ПОДСТРОКОЙ

Объявлением правила считается КАЖДАЯ из трёх форм, и распознаватель знает их все, потому что дубликат приходит не копией имени, а копией существа:

• конструктор `NewPasswordRule` и тип `PasswordRule` — форма по имени;
• метод `Judge` с параметром, названным `password` — форма по глаголу: второе правило в другом пакете завело бы свой тип со своим именем, но судить пароль оно стало бы тем же словом;
• сравнение ДЛИНЫ В РУНАХ параметра `password` — форма по существу: `len([]rune(password)) < n` и `utf8.RuneCountInString(password) < n`. Байтовая длина (`len(password)`) правилом НЕ считается намеренно: она судит МАТЕРИАЛ, а не пароль (у bcrypt потолок 72 байта, PWV-19), и живёт у проверяющего законно.

Вызывающим считается вызов метода `Judge` с тремя доводами — контекст, почта, пароль — вне дома правила. Перепись печатает «объявлений 1 · вызывающих M», и M сегодня равно 1: регистрация и восстановление — Ф4 и Ф5, их вызовы появятся вместе с ними, и рост M — перепись, а не находка.

───────────────────────────────────────────────────────────────────────────── ЧТО ГЕЙТ НЕ УТВЕРЖДАЕТ

Он не судит, ВСЕ ЛИ полосы, меняющие материал, зовут правило: полоса, которая пишет материал и правила не спрашивает, тремя формами выше не узнаётся. Эту половину держит запрет на замещение материала мимо `Writer` (гейт локализации проверяющего) и приёмки самих полос.

people_address_lawful_writers.go — ПЕРЕЧЕНЬ законных писателей адреса человека в существующую строку в непроверочном Go (задача PRO-Robotech/kaname#635; приёмка `docs/engineering/acceptance/email-change-is-confirmed-from-the-new-address.md`, Р9, сценарий EC-24).

Предмет ¶

Гейт `TestPeopleAddressHasNoWriterInServiceCode` держал число таких мест равным нулю, пока у продукта не было глагола смены адреса, и текст его находки (`addressWriterFinding`) называл условия, без которых глагол не вносится. Приёмка смены адреса разобрала каждое условие (Р9) и разрешила ОДНОГО законного писателя — оператор исхода смены. Перечень называет его координатой: файл и функция, в которой стоит оператор, и довод.

Чем перечень держится ¶

• запись поглощает РОВНО ОДНО место записи адреса в своём файле и своей функции: второй оператор той же функции, пишущий адрес, — находка, как и любое место вне перечня;
• запись без предмета — находка: перечень истекает вместе со своим писателем и не переживает его, оставаясь на вид рабочим;
• запись о файле, которого в корпусе нет, считается отдельно (как у ведомости применённых миграций) — инъекция судит синтетику, — а проба дерева требует, чтобы таких было ноль.

Пополняется перечень только одобренной приёмкой, назвавшей писателя, — не правкой гейта под покрасневший прогон.

people_address_writers.go — разбор «кто пишет адрес человека в существующую строку» (`kaname.users.email`): часть (б) условия 7 чек-листа поверхности подтверждения адреса (приёмка PRO-Robotech/kacho-workspace `docs/specs/sub-phase-F6b-console-and-edge-confirmed-address-gate-acceptance.md`, край и служба; приёмка службы `docs/engineering/acceptance/access-beyond-login-needs-a-verified-address.md`; задача PRO-Robotech/kaname#464). Половина, судящая миграции, — адрес И отметка его подтверждения, формы определения схемы и строки триггера, ведомость применённых миграций — в `people_address_writers_migrations.go` (задача PRO-Robotech/kaname#471).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Отметку подтверждения снимает база на смене адреса (триггер `users_email_change_drops_verification`, миграция `20260915111233_login_methods_live_in_their_own_rows.sql`). Снятие само по себе не закрывает того, что уже открыто: перепрос открытых соединений края отметку не спрашивает, кеш решений края снятием не сбрасывается. Поэтому глагол смены адреса вносится только вместе со своими условиями, и держит это гейт: мест, где непроверочный код службы пишет адрес в СУЩЕСТВУЮЩУЮ строку человека, — ровно столько, сколько называет перечень законных писателей (`people_address_lawful_writers.go`): одно, оператор исхода смены адреса, внесённый одобренной приёмкой, разобравшей условия (kaname#635, Р9). Появление любого другого места — находка, и её текст называет, с чем вместе глагол вносится (`addressWriterFinding`).

Заведение строки (`INSERT INTO users (…, email, …)`) адреса не меняет — у новой строки прежнего адреса нет — и находкой не является; оно считается в переписи операторов записи в строки людей.

Корпус — ДВА вида входа, и оба судит один разбор текста SQL: строковые выражения непроверочного Go и тексты миграций. Предмет у них разный: в Go — адрес (у отметки подтверждения в Go есть законный писатель — глагол подтверждения), в миграции — адрес и отметка (у миграции законного писателя отметки нет).

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ СПИСОК SET ОПЕРАТОРА, А НЕ ПОДСТРОКА

Текст — значение строкового выражения Go, свёрнутое тем же проходом, что у гейтов значений строк (`newLVIndex`: литерал, склейка, константа, связанное имя пакета), и разобранный общим лексером SQL (`sqlTokens`). Склейка, которая целиком не свернулась, судится звеньями, и звенья, сворачивающиеся подряд за значением времени исполнения (`tbl + " SET " + column + " = $1"`), — одним текстом. Колонка читается в голове элемента списка SET; адрес в условии, в цели конфликта (`ON CONFLICT (lower(email))`) и в списке колонок вставки записью не является. Законные формы записи, каждая доказана инъекцией:

UPDATE [ONLY] [kaname.]users [[AS] u] SET … email = …        ветвь UPDATE
UPDATE users SET (…, email, …) = (…)                          та же ветвь
IF … THEN UPDATE users SET … · правило DO UPDATE users SET …   та же ветвь
INSERT INTO users … ON CONFLICT … DO UPDATE SET … email = …    ветвь ON CONFLICT
MERGE INTO users … WHEN MATCHED THEN UPDATE SET … email = …    ветвь MERGE
любая из них внутри CTE, в склейке, в формате fmt.Sprintf, в строке SQL

и формы вне списка SET — определение схемы, переписывающее значения строк, и присваивание строке триггера (`people_address_writers_migrations.go`).

Имя без кавычек сравнивается без регистра ASCII, в кавычках — побайтово (так разрешает база; лексер общий).

───────────────────────────────────────────────────────────────────────────── ФОРМА, КОТОРУЮ РАЗБОР НЕ РЕШАЕТ, — НАХОДКА, А НЕ МОЛЧАНИЕ

«Не решается разбором» — каждая из форм ниже, и каждая доказана инъекцией:

• список SET над строками людей пуст, несёт пустой элемент, в голове элемента — подстановку формата (`%s`) либо не имя;
• UPDATE строк людей без списка SET в тексте;
• оператор с подстановкой вместо таблицы (либо вне текста), пишущий адрес либо колонку из подстановки;
• список SET без оператора в том же тексте, называющий адрес.

СПИСОК, ПОЛНЫЙ В ЛИТЕРАЛЕ И ПРОДОЛЖЕННЫЙ ВО ВРЕМЯ ИСПОЛНЕНИЯ. Гейт не прослеживает значение до исполнителя запроса, поэтому список SET над строками людей (либо над таблицей, которую текст не называет, — подстановка вместо таблицы либо оператор вне текста), чьи элементы решены и адреса не пишут, судится ещё раз:

• не закрыт в тексте — кончается концом текста, а не WHERE, FROM, RETURNING, `;` либо скобкой: хвост, приставленный склейкой с переменной, `+=`, `strings.Join` либо построителем, дописал бы колонку;
• несёт подстановку формата в значении элемента (`labels = %s`): подставленный текст дописал бы колонку.

Закрытый в своём тексте список продолжение колонкой не пополнит — хвост и подстановка после закрывающего слова молчат. Полная запись без хвоста тоже обязана закрыть список (`RETURNING`, `WHERE` либо `;`): отличить её от продолженной гейт не берётся. Пустой список над таблицей, которую текст не называет, колонок не несёт — его колонки приставляются звеньями и судятся звеньями.

ЗВЕНО-ПРИСВАИВАНИЕ. Текст, начатый списком присваиваний без оператора и без SET (`email = $2`, продолжение `, email = $3` либо `%s, email = $3`, кортеж `(display_name, email) = (…)`), приставляют к списку SET во время исполнения; голова элемента, называющая адрес, — «не решается». Звено условия отбора `email = $N` от звена списка SET неотличимо и пишется со своим словом (WHERE, AND, OR) либо выражением над колонкой — так пишет дерево (`lower(email) = lower($%d)`). Значение константы и имени уровня пакета звеном судится в месте обращения, не вошедшем в свёрнутое выражение (`q += set`, элемент `[]string{…}`): свёртка подставляет его туда.

Иначе колонку, собранную во время исполнения, гейт пропустил бы молча.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

1. Корпус — непроверочный Go дерева и миграции службы (`PeopleAddressInput`). Места в ПРИМЕНЁННЫХ миграциях, которые правке не подлежат (ban #5), названы ведомостью поимённо — точной координатой (`people_address_writers_migrations.go`); у Go ведомости нет.
2. Текст, собранный во время исполнения, судится по звеньям, которые сворачиваются (литерал, склейка, константа). Колонка адреса, дошедшая до списка SET не словом свёрнутого текста — из данных либо значением, подставленным в формат (`fmt.Sprintf("%s = $1", column)`), — видна только там, где ей негде встать молча: пустой список, пустой элемент, подстановка в голове либо в значении, список, не закрытый в тексте. Приставленная к списку, чья таблица в тексте не названа (`"UPDATE " + tbl + " SET "`), либо вставленная в закрытый текст заменой (`strings.Replace`), она не видна: адреса нет ни в одном слове, которое разбор читает. Звено с подстановкой в голове (`%s = $%d`) звеном-присваиванием адреса не считается — так же пишется условие любого построителя отбора.
3. Ветвь MERGE в дереве сегодня пуста: её держит инъекция, а не перепись.

people_address_writers_migrations.go — половина гейта писателей адреса людей, судящая МИГРАЦИИ службы, и формы записи вне списка SET, которые знает общий разбор (задача PRO-Robotech/kaname#471; предмет и разбор списка SET — в шапке `people_address_writers.go`, #464).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ В МИГРАЦИИ

Миграция не пишет в строки людей, которых сама не заводит, ни адреса (`kaname.users.email`), ни отметки его подтверждения (`kaname.users.email_verified_at`). У адреса глагол смены вносится только со своими условиями; у отметки писателей два — предъявление кода подтверждения ставит её, база на смене адреса снимает, — и миграция третьим не становится. Текст миграции судится ТЕМ ЖЕ разбором, что строковые выражения Go: файл — один текст SQL, тела `DO $$ … $$`, подпрограмм и динамический SQL — вложенные строки, судимые ещё раз. Разделы `-- +goose Up` и `-- +goose Down` судятся оба: откат исполняется так же, как накат.

───────────────────────────────────────────────────────────────────────────── ФОРМЫ ЗАПИСИ ВНЕ СПИСКА SET — каждая доказана инъекцией

Определение схемы, пишущее значение колонки в строки, которых оператор не заводит (ALTER TABLE над строками людей):

ADD [COLUMN] [IF NOT EXISTS] колонка … DEFAULT выражение | GENERATED …
ALTER [COLUMN] колонка SET DEFAULT выражение     (не NULL: заводимые строки)
ALTER [COLUMN] колонка [SET DATA] TYPE … USING выражение
ALTER [COLUMN] колонка SET EXPRESSION AS (…)
RENAME [COLUMN] другая TO колонка
ALTER TABLE [kaname.]другая RENAME TO users     (её строки становятся людьми)

Колонка либо таблица такого определения — подстановка формата (динамический SQL, `format('… %I …')`) — «не решается».

Запись строки триггера в теле подпрограммы на PL/pgSQL. База пишет ту строку, которую подпрограмма триггера ВЕРНУЛА, поэтому судятся две вещи.

• Цель присваивания, называющая строку триггера. Строку называют NEW, OLD, их псевдонимы (`имя ALIAS FOR new`, псевдоним псевдонима) и любое из них под меткой блока (`метка.new.колонка`; внешний блок помечен именем подпрограммы). Цели — все, какие есть в грамматике PL/pgSQL: начало оператора (`цель := …`, `цель = …`, с индексом `[…]`), `INTO [STRICT] цель[, …]`, `GET [CURRENT|STACKED] DIAGNOSTICS цель = …`, `FOR цель[, …] IN` (и под меткой цикла `<<метка>>`), `FOREACH цель … IN ARRAY`, аргумент `CALL` целиком (позиционный либо `имя =>`: выходной параметр процедуры пишет в него). Колонка названа — присваивание колонке; нет — строке целиком.
• RETURN в подпрограмме, объявленной `RETURNS trigger`: законно вернуть саму строку триггера (NEW, OLD, псевдоним, под меткой, в скобках), NULL, ничего и CASE, каждая ветвь которого законна. Прочее (`RETURN r` после `r := NEW; r.колонка := …`, `RETURN jsonb_populate_record(NEW, …)`) — строка, которая не строка триггера: база пишет её целиком.

Тело подпрограммы триггера на языке, отличном от PL/pgSQL, разбор не читает — оно пишет строку целиком. Какую таблицу пишет подпрограмма, решает ПРИВЯЗКА: объявление `CREATE TRIGGER … ON таблица … EXECUTE FUNCTION|PROCEDURE имя()` где угодно в корпусе (функция и триггер бывают в разных миграциях). Привязана к строкам людей — писатель, если колонка названа, и «не решается», если строка пишется целиком (событие не различается: заведённая строка, которую пишет триггер, — тоже строка, которой сам триггер не заводил); только к чужим таблицам — молчание; к таблице из подстановки либо ни к какой — «не решается». Триггер над строками людей либо над таблицей из подстановки, чья подпрограмма тела в корпусе не имеет (подпрограмма расширения пишет колонку, названную аргументом триггера), — «не решается» с координатой объявления триггера.

───────────────────────────────────────────────────────────────────────────── ВЕДОМОСТЬ ПРИМЕНЁННЫХ МИГРАЦИЙ — И ПОЧЕМУ ВЕДОМОСТЬ, А НЕ «ТОЛЬКО ДОБАВЛЕННОЕ»

В применённых миграциях места предмета ЕСТЬ (перепись — в пробе гейта), и применённая миграция не правится (ban #5). Соседние гейты миграций судят только добавленное относительно ствола; здесь это отвергнуто по трём доводам: (1) вердикт — свойство коммита без ствола: судится ВСЁ дерево на каждом прогоне, и клон без выборки ствола не уходит в пропуск; (2) места неподвижны — применённая миграция не меняется, поэтому ведомость точным числом не краснеет на движении к собственной цели; (3) писатель, ДОПИСАННЫЙ в применённую миграцию, — находка (обход добавленных файлов его не видит).

Запись ведомости — точная координата (файл, строка, колонка писателя либо форма «не решается») и довод. Запись с предметом молчит; запись, чьего места на своей строке разбор больше не находит, — находка (ведомость истекает вместе с предметом); запись о файле, которого нет в корпусе, считается отдельно (`LedgerOutOfCorpus`), и гейт дерева требует её нуля; что каждая запись называет ПРИМЕНЁННУЮ и нетронутую миграцию, держит проба гейта дерева по стволу.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

1. Привязка триггера — по ИМЕНИ подпрограммы, без схемы: база привязывает по идентификатору, и `ALTER FUNCTION … RENAME` привязки не меняет — разбор этого не прослеживает; триггер, снятый позже (`DROP TRIGGER`), привязку не отзывает — лишняя находка, не пропуск.
2. Подпрограмма, которую миграция ЗОВЁТ, судится там, где объявлено её тело; тело, объявленное вне корпуса, не видно (у подпрограммы триггера над строками людей это не молчание, а «не решается» — выше). Момент и уровень триггера не различаются: присваивание в подпрограмме триггера AFTER либо FOR EACH STATEMENT (возвращённая строка не пишется) и присваивание OLD в подпрограмме, возвращающей NEW, — лишняя находка, не пропуск.
3. Запись через представление, правило над представлением и подмена подпрограммы-снимателя отметки (`CREATE OR REPLACE` без присваивания, снятие её триггера) — не формы записи колонки и этим разбором не судятся: снятие отметки на смене адреса и неподтверждённость новой строки держит интеграционная проба схемы на накатанной цепочке (`TestIntegration_AddressVerificationIsBoundToTheValue`, `internal/migrations/login_method_schema_integration_test.go`).
4. Заведение строки с отметкой (`INSERT INTO users (…, email_verified_at)`) — заведение, а не запись в строку, которой оператор не заводил.

probe_home.go — РЕЗОЛВ НАЗВАННОГО ДОМА: координата чужого дерева проверяется В НЁМ, а не просто считается.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Приставка `<владелец>/<репозиторий>:` снимает координату с суждения соседнего гейта: подтвердить объявление функции в чужом репозитории он не мог. Пока это было так, у приставки была вторая, незаявленная роль — СПОСОБ СНЯТЬ КООРДИНАТУ С ПРОВЕРКИ. Имя, снятое в чужом дереве завтра, здесь не покраснело бы ни разу, и приёмка посылала бы читателя по адресу, которого нет.

ПОЧЕМУ ЭТО НЕ ЗАВОДИЛОСЬ РАНЬШЕ — И ПОЧЕМУ ДОВОД БЫЛ ВЕРЕН. Ветвь резолва без производителя входа есть мёртвый страж: объявлен и никогда не исполняется. Он заводится ВМЕСТЕ с производителем, и производитель здесь — две синтетические копии с РАЗНЫМИ идентичностями (`probe_home_injection_test.go`).

───────────────────────────────────────────────────────────────────────────── ПОРЯДОК КАНДИДАТОВ ЗАКРЫТ И ОБЪЯВЛЕН

1. переменная `KACHO_HOME_<ИМЯ>` — оператор назвал копию явно;
2. соседний клон: у каждого предка своего корня — `<предок>/<имя>` и `<предок>/project/<имя>`;
3. ничего — ТРЕТЬЯ КАТЕГОРИЯ.

ДОМ ОПОЗНАЁТСЯ ИДЕНТИЧНОСТЬЮ `origin`, А НЕ ИМЕНЕМ КАТАЛОГА. Каталог зовут как угодно, и совпадение имени ничего не обещает: копия под именем `kacho` бывает клоном чего угодно. Поэтому кандидат, чей `origin` не тот, ОТВЕРГАЕТСЯ и называется в причине — «указатель, ведущий в чужой репозиторий, дома не даёт».

ПРИЧИНА ПЕРЕЧИСЛЯЕТ КАЖДОГО ОТВЕРГНУТОГО. Без перечня «дома нет» читается как «искали одно место», а починки у «переменная указывает мимо» и «клона нет» разные — и первая состоит в правке того, что уже объявлено.

───────────────────────────────────────────────────────────────────────────── ГДЕ СУДИТСЯ — В СТВОЛЕ ДОМА, А НЕ В ИНДЕКСЕ ЛЕЖАЩЕЙ РЯДОМ КОПИИ

Координата резолвится по `origin/main` дома. Копия ОБЩАЯ: её ревизию переключает соседняя сессия, не спрашивая отправляющего, и вердикт, прочитанный с индекса, есть функция чужого переключения. Класс наблюдался целиком (`PRO-Robotech/kacho-workspace#543`): копия стояла на линии, где каталог переименован, и проверка объявила несуществующими координаты, которые в стволе ЕСТЬ.

Координата, СВЯЗАННАЯ РЕВИЗИЕЙ (`owner/repo@<хеш>:Имя`), судится на ЭТОЙ ревизии, а не на стволе: она указывает в прошлое состояние чужого дерева намеренно, и сводить её к стволу значило бы судить не то, что написано.

Ствол не резолвится (клон без этой ссылки) — ТРЕТЬЯ КАТЕГОРИЯ, а не находка: судить не по чему, и молчаливый откат на индекс копии здесь запрещён той же причиной, что выше.

───────────────────────────────────────────────────────────────────────────── ЧТО ЭТОТ РЕЗОЛВ СЕГОДНЯ ДАЁТ В КОНВЕЙЕРЕ — СКАЗАНО ПРЯМО, А НЕ ПОДРАЗУМЕВАЕТСЯ

На машине разработчика, где копия дома лежит рядом, резолв ИСПОЛНЯЕТСЯ: замер на дереве службы — домов 2, координат проверено в доме 101, находок 0.

В конвейере службы копии дома рядом НЕТ: единственная выборка чужого дерева (`ci.yml`, задание сверки каталога прав) кладёт его в каталог с ДРУГИМ именем и берёт один подкаталог. Кандидатом она поэтому не становится, и резолв даёт ТРЕТЬЮ КАТЕГОРИЮ со своим числом — то есть безопасный исход, а не ложную находку: «дома нет» никогда не читается как «имени нет».

ОСТАТОК НАЗВАН С ПРЕДИКАТОМ, А НЕ ОБЕЩАНИЕМ. Чтобы резолв исполнялся и в конвейере, заданию, гоняющему этот гейт, нужна выборка дома и переменная `KACHO_HOME_KACHO`, указывающая на неё. Предикат снятия: прогон конвейера печатает «координат проверено в доме N > 0». Цена шага не измерена здесь и решается своим изменением: у разрежённой выборки другой состав и другой вес.

probe_tooling.go — ОСНАСТКА ПРОБ: не-тестовые файлы Go под `internal/testsupport/`, которые импортируют только пробы (задача PRO-Robotech/kaname#816).

ПРЕДМЕТ ¶

Гейты прод-кода не судят файлы проб: пробе законно назвать таблицу секрета и поставить отметку, которую продукт ставит лишь миграцией, — фикстура заводит то, что заводит продукт. Файлом пробы до сих пор считался только `*_test.go`. Но `*_test.go` из другого пакета не импортируется, и общая фикстура многих пакетов обязана лежать в обычном файле — в оснастке проб. Без второй формы такой файл судился бы как прод-код, а у фикстуры, вынесенной из двадцати четырёх копий в одну, гейты прод-кода находили бы «третьего писателя», которого прод-сборка не содержит.

ПРЕДПОСЫЛКА — ПРОВЕРЯЕТСЯ, А НЕ ОБЪЯВЛЯЕТСЯ ¶

Снять оснастку с суда честно ровно тогда, когда прод-сборка её не видит. `ProbeToolingImports` судит это по разбору импортов каждого не-тестового файла вне оснастки: импорт пакета оснастки любой формы (обычный, псевдоним, с точкой, пустое имя, под любым тегом сборки) — находка с координатой. Иначе оснастка стала бы местом, куда прод-код прячет то, что гейт обязан видеть.

Оснастки в обходе нет — тоже находка: исключение, которому нечего исключать, истекает само.

ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ ¶

1. Судится импорт ИЗ ЭТОГО МОДУЛЯ: другой модуль `internal/` этого модуля импортировать не может — это держит компилятор.
2. Связь в обход импорта (`go:linkname`, отражение) не судится: в дереве такой формы нет.

proto_comment_names_a_real_message.go — разбор комментариев контракта на ОДИН факт: существует ли сообщение, которое комментарий называет координатой.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Комментарий контракта читает КЛИЕНТ, и он не всегда может открыть дерево. Названная в обратных кавычках координата `Message.field` есть обещание поля: клиент идёт за ним в стабы, не находит и решает, что отстала его версия.

Обещание переживает свой предмет МОЛЧА. Ни `buf lint`, ни `buf breaking`, ни генерация комментариев не читают: они судят объявления. Наблюдалось на привязке — комментарий обещал `Tuple.condition` при том, что сообщения `Tuple` в контрактах не было ни одного, а условия на кортеже своей формы на проводе не имеют вовсе (kaname#132).

───────────────────────────────────────────────────────────────────────────── ЧТО СЧИТАЕТСЯ ССЫЛКОЙ — ФОРМА НАЗВАНА, А НЕ ПОДРАЗУМЕВАЕТСЯ

Ссылкой считается токен В ОБРАТНЫХ КАВЫЧКАХ, несущий точку, у которого есть сегмент с заглавной первой буквой, а следом — сегмент со строчной:

`AccessBinding.scope_type`                     — короткая форма
`kaname.cloud.iam.v1.AccessBinding.scope_type` — полная форма
`AuthorizeService.CheckRequest.context`        — через службу

Тип — ПОСЛЕДНИЙ сегмент с заглавной буквы: у полной формы перед ним стоит имя пакета, у формы через службу — имя службы, и оба сообщением не являются.

───────────────────────────────────────────────────────────────────────────── ЧЕГО РАЗБОР НЕ ВИДИТ — НАЗВАНО, А НЕ СПРЯТАНО

1. **ссылка без обратных кавычек**. Проза контракта называет типы и по-русски, и мимоходом; принимать за координату всякое слово с заглавной значило бы краснеть на собственном объяснении;
2. **существование ПОЛЯ** внутри названного сообщения. Гейт судит тип: поле требует разбора тела сообщения вместе с вложенными и наследуемыми, а цена этого не окупается — `Tuple` не существовал целиком, и это тот случай, который встречается;
3. **чужие контракты вне дерева**. Набор известных типов строится по ВСЕМ `*.proto` дерева, включая копии фундамента, — координата в контракт, которого рядом нет, будет находкой, и это верно: клиент этого дерева его тоже не откроет.

published_key_rule_home.go — разбор обращений к правилу критичных параметров заголовка платформы (`tokenpolicy.CriticalHeadersUnderstood`), держатель `TestPublishedKeyRuleHasOneHome` (задача PRO-Robotech/kaname#396).

Предмет ¶

Токен службы проверяют три читателя: читатель предъявленного на публичном слушателе, интроспекция для соседей и опознание токена доступа церемонии. Ключ проверки каждый из них выбирает из публикуемого набора ОДНИМ правилом — форма `kid` → ключ по `kid` → алгоритм, закреплённый за ключом, → критичные параметры заголовка → открытая половина ключа. До сведения правило было написано трижды; копии уже разошлись в мелочи (одна читала испорченный свой ключ как негодный токен), и следующая расходилась бы так же молча: все три отвечают «подпись сошлась». Дом правила — `internal/publishedkey`.

Что здесь считается КОПИЕЙ ¶

Обращение к `tokenpolicy.CriticalHeadersUnderstood` — вызов либо значение функции. Иных потребителей правила критичных параметров у продукта нет: проверка утверждения клиента (`clientassertion`) судит свой перечень понятых параметров над ключом реестра клиентов, и платформенного правила не зовёт.

Распознаватель знает ВСЕ формы обращения by construction ¶

Он связывает имя с ПУТЁМ импорта из разобранного дерева, а не с текстом: обычный импорт, псевдоним и точечный импорт опознаются одинаково; пустой импорт обращения дать не может и только считается переписью. Метод чужого типа с тем же именем обращением не является, и упоминание имени в комментарии или строке — тоже: разбор судит узел, а не подстроку.

Чего разбор НЕ видит — названо, а не спрятано ¶

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

quota_authority_retired.go — АВТОРИТЕТ ВЕЛИЧИН УШЁЛ ИЗ СЛУЖБЫ ДОСТУПА ЦЕЛИКОМ.

Задача продукта `PRO-Robotech/kacho#2117`, приёмка `KAN-QUOTA-1`, стадия S4, сценарии `KAN-Q4-08`, `KAN-Q4-10`, `KAN-Q4-14`; условие готовности `DoD S4` пп. 1, 13.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ — ОТСУТСТВИЕ, А НЕ ПРИСУТСТВИЕ, И ПОТОМУ ГЕЙТ НУЖЕН ОСОБЕННО

Проверка, ищущая ОТСУТСТВИЕ формы, на исчезнувшем предмете замолкает: её образец не совпадёт больше никогда, обход и перепись целы, вердикт зелёный. Отличить это от исправной работы можно только переписью ОБЪЁМА: «находок ноль» и «прочитано ноль» обязаны быть разными вердиктами, и оба напечатаны.

Предмет разбора — ВОЗВРАТ: авторитет величин, заведённый заново в службе, чей продукт отвечает «кому что разрешено», а не «сколько чего можно завести».

───────────────────────────────────────────────────────────────────────────── ЧТО СНЯТО ВМЕСТЕ С АВТОРИТЕТОМ, КРОМЕ ЕГО КОДА (kaname#108)

Здесь же называется судьба СОСЕДНЕГО гейта, чтобы его исчезновение не пришлось восстанавливать по истории: `quota_reader_grant_test.go` требовал, чтобы владелец считаемого вида состоял в группе читателей пределов. Он судил миграции ВСЕХ модулей платформы (`<корень>/services/**/*.sql`) и опирался на группу `module.quota_readers`.

Ни того, ни другого в этом репозитории нет: каталога соседних модулей — by construction, группы читателей — потому, что хранилище авторитета ушло из схемы вместе с ним. Гейт при этом не краснел и не зеленел: он спрашивал координату дерева платформы и пропускал себя в любой посадке, то есть не исполнялся НИ РАЗУ с момента выноса службы.

───────────────────────────────────────────────────────────────────────────── РАЗБОР СУДИТ УЗЕЛ-ИДЕНТИФИКАТОР, А НЕ ТЕКСТ — И ЭТО НЕСУЩЕЕ

Гейт по подстроке краснел бы на СОБСТВЕННОМ объяснении: перечень снятых имён стоит в этом же файле, а надгробие снятого метода — в `authzguard`. Проверка, судящая ТЕКСТ, не отличает исполняемую часть от комментария, который эту же часть объясняет, — и снимают её первой, как непонятную.

Поэтому ось прод-кода разбирает файл `go/parser`-ом и судит ТОЛЬКО узлы `*ast.Ident`. Комментарий, строковый литерал и запись о снятом предмете под неё не подпадают by construction — и это намеренно: снятое называется в отрицательной форме, надгробием, а не стирается молча. Читатель, пришедший за методом, которого больше нет, обязан узнать, что его СНЯЛИ, а не решить, что он ищет не там.

Ось контракта разбирает СТРОКУ ОБЪЯВЛЕНИЯ (`service` / `message` / `enum` / `rpc` в начале строки).

Ось СКВОЗНОГО НАБОРА разбирает порождённую коллекцию как JSON и судит АДРЕС шага. Она заведена позже трёх остальных (`kaname#124`) и ровно потому, что те её предмет не покрывали: они читают `.go`, `.proto` и `.fga`, а набор живёт в `.py` и `.json`. Замер на день заведения: авторитет был снят из всех трёх осей, а набор нёс 47 шагов к его поверхности в двух коллекциях — одиннадцать кейсов целой коллекции и три в соседней. Ни одна ось этого не видела, и утверждения о снятом предмете не краснели и не зеленели: они невыполнимы.

Отступ в образцах записан `[ \t]`, а НЕ `[[:space:]]`, и это не придирка: второй класс включает перевод строки, поэтому совпадение начиналось на строку РАНЬШЕ объявления и находка называла чужую координату. Поймала это инъекция, а не чтение: сам факт находки был верен, неверно было место — то есть гейт послал бы читателя искать не туда. `.proto` не разбирается тем же парсером, но объявление от комментария отличимо: комментарий начинается с `//`, а объявление — с ключевого слова. Граница названа честно: объявление, записанное внутри многострочного комментария `/* */`, разбору невидимо.

───────────────────────────────────────────────────────────────────────────── ПОЧЕМУ ПРЕДИКАТ ПО СЛОВУ `limit` ОТВЕРГНУТ — ЭТО ИЗМЕРЕНО, А НЕ ВЫБРАНО

Прежняя редакция условия снятия kacho#2117 считала слово `limit` в контракте и была НЕДОСТИЖИМА by construction (`kacho#2457`): под неё попадали имя поля размера страницы (`int32 limit = 2`), предел веерного ответа и проза об учёте у владельцев. Чтобы предикат дал ноль, пришлось бы снять имя поля страницы — ломающее изменение, к величинам отношения не имеющее.

Здесь предмет назван ИМЕНЕМ АВТОРИТЕТА, а не словом: закрытый перечень снятых символов и объявления, чьё имя несёт `Limit`. Поле `limit` объявлением не является и разбору невидимо.

───────────────────────────────────────────────────────────────────────────── ЗАКОННЫЙ ОСТАТОК НАЗВАН ПОИМЁННО — ИНАЧЕ ГЕЙТ ПОТРЕБОВАЛ БЫ РАСШИРЕНИЯ ПОВЕРХНОСТИ

Из службы уходит АВТОРИТЕТ величин. НЕ уходят три вещи, и каждая обязана молчать под всеми осями:

`LimitKind` и словарь посадки  собственные потолки службы берут величину
                              из посадки (`П25`, `KAN-Q3-01`); снять их
                              значило бы оставить самостоятельную установку
                              без ограничения на число аккаунтов и
                              удостоверений — расширение поверхности, не
                              названное ни в одном артефакте;
`IdentityQuotaService`,       арендаторское чтение СВОЕГО потолка; переехало
`Quota`                       в контракт службы решением `Д9` именно затем,
                              чтобы пережить уход модуля;
предел СКОРОСТИ приёма        защита от злоупотребления, а не потолок
                              количества; слово «квота» в её отказе —
                              совпадение написания.

Ни одно из трёх в перечень снятых имён не входит, и каждое стоит законным близнецом в инъекции (`quota_authority_retired_injection_test.go`): без второй половины «находок нет» было бы неотличимо от «разбор не смотрит».

read_path_concat.go — разбор: НА ПУТИ ЧТЕНИЯ СРАВНИВАЮТСЯ КОЛОНКИ, А НЕ ИХ СКЛЕЙКА.

Предмет ¶

Склейка колонки внутри УСЛОВИЯ выводит колонку из-под индекса: сравнивать приходится вычисленное значение, а вычисленное значение отбирает строки только ПОСЛЕ того, как они прочитаны. Ответ от этого не меняется, стоимость растёт с числом строк в системе, и заметно это только под нагрузкой.

Класс измерен, а не предположен. Починка горячего пути перевела на пару колонок два места — вердикт и перечисление объектов. Перепись ПО СВОЙСТВУ («колонка склеивается там, где значение сравнивается») дала на том же дереве ЧЕТЫРЕ: два обратных вопроса и две точки прибора замера, гасившие индекс области. У одной из четырёх комментарий рядом обещал «колонками, а не склейкой» — то есть был ложен.

Поведенческой пробы для этого мало: она мерит ту точку входа, которую зовёт, и молчит об остальных — ровно это и позволило долгу прожить. Свойство — свойство ДЕРЕВА, и держать его обязан обход дерева.

Объём ВЫВОДИТСЯ, а не выписывается ¶

Каталоги берутся у объявления предмета замера (`scalegrid/fingerprint.go`) — того же источника, которым определяется предмет прибора. Выписанный перечень не двинулся бы от нового каталога и продолжал бы сторожить прежние.

Читается ИСПОЛНЯЕМАЯ часть ¶

Литералы разбираются по синтаксическому дереву Go (SQL в Go-комментарии кодом не является), внутри литерала снимаются SQL-комментарии, а содержимое строковых литералов SQL ЗАКРЫВАЕТСЯ с сохранением длины — иначе слово внутри литерала читается как ключевое, условие обрывается, и гейт молчит ровно на той форме, ради которой написан.

Порт с монорепо — пара файлов названа, а не умолчана ¶

Перенесено с `PRO-Robotech/kacho:internal/repohygiene/readpathconcat_test.go` (снято вынесением службы — `kacho#2598`; предмет жив здесь, задача #17). Изменилось: координата объявления предмета замера (приставки `services/iam/` в самостоятельном клоне нет), разбор вынесен из пробы в пакет `check`, разбор литералов Go взят у соседнего семейства того же дерева и живёт здесь одной копией. Осталось дословно: имя гейта, перечни ключевых слов условия, границы цепочки склейки и счёт законного близнеца.

Близнеца в платформе нет: семейство снято там вместе со службой (ban #20).

recipe_call_coordinate.go — гейт: КАТАЛОГ, названный строкой ВЫЗОВА в комментарии рецепта сборки, существует в этом дереве (задача PRO-Robotech/kacho#2613, предикат снятия п. 4).

Предмет ¶

Комментарий рецепта говорит читателю, ЧЕМ позвать цель: «Вызов: `make -C <кат> <цель>`». Строка вызова есть обещание исполнимости ЗДЕСЬ — она не описывает историю и не называет чужого держателя, она предписывает команду.

Каталог, которого в дереве нет, делает это обещание неисполнимым, и отказ приходит не там, где ошибка: `make -C <нет каталога>` печатает «нет такого файла или каталога» и выходит кодом 2, то есть читатель получает отказ ИНСТРУМЕНТА вместо отказа цели и идёт разбираться не туда. До задачи kacho#2613 таких строк в этом рецепте было ТРИ, и все три называли `services/iam` — каталог монорепо, от которого модуль отделён: отслеживаемых путей под `services/` в этом дереве НОЛЬ.

Класс тот же, что у соседей `acceptance_path_coordinate.go` (путь предиката) и `acceptance_probe_coordinate.go` (имя пробы): утверждение, пережившее свой предмет. Дерево у него другое — не приёмка, а рецепт сборки, — и потому у него свой держатель.

РАЗБОР ПО ПОЗИЦИЯМ АРГУМЕНТОВ, А НЕ ПОИСК ПОДСТРОКИ ¶

Подстрока `services/iam` встречается в этом файле, в прозе рецепта и в объяснениях прошлых дефектов — и там она ЗАКОННА: она свидетельствует о том, как было. Гейт по подстроке краснел бы на собственном объяснении (ровно тот класс, который корпус ловит).

Поэтому каталог опознаётся ПОЗИЦИЕЙ: строка вызова разбирается на поля, и каталогом признаётся аргумент ключа `-C` — приклеенный (`-C<кат>`) либо следующим полем (`-C <кат>`). Ни одно другое поле каталогом не считается: путь, названный прозой, этот гейт не судит вовсе, и это сказано ниже отдельной строкой, а не умолчано.

ГРАНИЦЫ НАЗВАНЫ, А НЕ УМОЛЧАНЫ ¶

• ПУТЬ, НАЗВАННЫЙ ПРОЗОЙ, не судится. `CLA.md` в объясняющем абзаце — координата, а не вызов; её предмет тот же, но её разбор требует отличать координату от формы имени, и это своя работа со своим замером. Число таких строк здесь не печатается: гейт их не ищет, и напечатанный ноль читался бы как «искали и не нашли».
• КАТАЛОГ СУДИТСЯ НА СУЩЕСТВОВАНИЕ, а не на исполнимость `make` в нём. Каталог, отслеживаемый деревом, но не несущий своего `Makefile`, здесь не находка: рецепт цитирует такую команду, чтобы объяснить, что она НЕИСПОЛНИМА, и отличить цитату от предписания машинно значило бы судить прозу. Ось соседняя и названа здесь, а не умолчана; предмет её — свой.
• ЦЕЛЬ вызова не проверяется. Объявлена ли она рецептом — предмет соседнего гейта провязки (`judge_target_wiring.go`), и второе место об одном предмете разошлось бы с ним молча.
• СТРОКА, НАЗВАВШАЯ ЧУЖОЙ РЕПОЗИТОРИЙ, освобождается: её координаты принадлежат чужому дереву, и требовать их отсюда значило бы завести находку на правдивой записи. Освобождение ВИДИМОЕ — перепись печатает его число, иначе оно стало бы слепой зоной ровно того размера, которого никто не видит.

registration_lanes.go — разбор ОБЪЯВЛЕНИЯ полос регистрации (приёмка Ф4 `docs/engineering/acceptance/registration-and-its-three-consequences.md`, Р4, Ф4-06…Ф4-10; задача PRO-Robotech/kacho#1270).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Полоса регистрации — сущность НАШЕГО кода, перечисленная одним местом: `registration.Lanes` в `internal/apps/kaname/api/registration/lanes.go`. Каждая полоса объявляет свои следствия, и гейт судит ЭТО объявление: полоса, у которой среди следствий нет выдачи сессии, — красное с её именем (Ф4-07); объявление, из которого не разобрано ни одной полосы, — не зелёное и не красное, а «вердикта нет» (Ф4-09).

Предмет переехал сюда из дома платформы: там свойство «каждая полоса выдаёт сессию» держал гейт, читавший объявление ЧУЖОЙ конфигурации по отступам (форма Ф-е). После Ф4 полоса — значение Go, и читается оно разбором.

───────────────────────────────────────────────────────────────────────────── ЧТО РАЗБИРАЕТСЯ — И В КАКИХ ФОРМАХ

Объявление — `var Lanes = []Lane{ … }` в файле объявления. Элемент перечня — составной литерал полосы; читаются два поля:

Name         — строковый литерал либо идентификатор константы ТОГО ЖЕ файла;
Consequences — составной литерал среза, чьи элементы — идентификаторы
               констант того же файла либо строковые литералы.

Формы записи элемента — ключевая (`{Name: …, Consequences: …}`) и позиционная (`{…, …}`), обе доказаны инъекцией. Выдача сессии узнаётся по ЗНАЧЕНИЮ следствия, а не по имени идентификатора: значение приносит вызывающий от производителя (`registration.ConsequenceSession`), и переименование константы гейт не ослепит.

───────────────────────────────────────────────────────────────────────────── ОБЪЯВЛЕНИЕ — ОДНО

Второе место, перечисляющее полосы, разошлось бы с первым молча, и гейт судил бы перечисленное, а исполнялось бы другое (Ф4-06). Поэтому вторая половина разбора обходит ВЕСЬ прод-код и считает составные литералы типа `Lane` (`registration.Lane` из чужого пакета): литерал вне файла объявления — находка с координатой. Комментарии и строки в счёт не идут by construction — разбор ходит по узлам.

relation_fact_sole_writer.go — разбор «кто пишет в таблицу прямого факта».

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Таблица `kaname.relation_fact` — то, из чего реляционная форма собирает безусловное основание вердикта. Наполняет её ТРИГГЕР на журнале намерений (`kaname.fga_outbox`, `relation_fact_follows_journal`), и это выбор схемы, а не привычка: производителей кортежа много и они разной природы (use-case, реконсайлер, посев старта, сырой SQL миграции), поэтому писатель, добавленный в код, не покрывает SQL вовсе, а перечень «кто ещё обязан писать факт» расходится с деревом при первой же новой миграции — молча.

Пока производитель ОДИН, появление нового происходит by construction: он кладёт строку журнала, и проекция подхватывает её, не зная о нём. Стоит завести второго писателя из кода — и инвариант ломается ровно в ту сторону, которую не видно: факт ЕСТЬ, и вердикт по нему выносится, а журнала за ним нет — то есть нет ни порядка применения, ни снятия, ни разбора оснований.

───────────────────────────────────────────────────────────────────────────── ПОЧЕМУ УЗЕЛ РАЗБОРА, А НЕ ПОДСТРОКА ПО ТЕЛУ ФАЙЛА

Перенесённая из монорепо форма читала ТЕЛО файла целиком и сверяла подстроку. В этом дереве так нельзя: имя таблицы стоит в КОММЕНТАРИЯХ десятка прод-файлов (`module_seed_writer.go`, `fga_outbox/emitter.go`, `authzmodel.go` и другие) — ровно там, где объясняют, что пишет её триггер, а не код. Подстрочный разбор дал бы находку на объяснении инварианта, то есть гейт краснел бы на собственном предмете.

Поэтому запись ищется ТОЛЬКО в строковых литералах (узел ast.BasicLit вида token.STRING), а комментарии считаются ОТДЕЛЬНО и печатаются переписью: их ненулевое число — свидетельство, что разбор дошёл до мест, где о таблице говорят, и промолчал по существу, а не по слепоте.

───────────────────────────────────────────────────────────────────────────── ФОРМЫ ЗАПИСИ — ПЕРЕЧИСЛЕНЫ

SQL в этом дереве пишется многострочными литералами с отступами, поэтому глагол и имя таблицы разделены произвольным пробелом, включая перевод строки. Совпадение ищется по образцу, терпимому к пробелу и регистру:

INSERT INTO kaname.relation_fact      одной строкой
insert into kaname.relation_fact      нижним регистром
INSERT INTO\n\t\tkaname.relation_fact переносом и отступом
DELETE FROM kaname.relation_fact      снятие
UPDATE kaname.relation_fact           правка

Чтение (`SELECT`) законно и в перечень глаголов НЕ входит: форма его и делает.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦА НАЗВАНА, А НЕ УМОЛЧАНА

Разбор НЕ видит: SQL миграций (там запись законна — миграция и есть схема), проб (им положено готовить состояние) и ДИНАМИЧЕСКИ СОБРАННОГО имени таблицы (склейка из кусков, fmt.Sprintf, константа из другого пакета). Последнее — настоящая слепая зона: имя, собранное из частей, не ловится образцом ничем, и молчание гейта на нём не является доказательством.

request_field_has_a_reader.go — разбор: у КАЖДОГО поля сообщения запроса есть читатель в прод-коде своей службы (задача kacho#1351).

Предмет ¶

Поле запроса, которое принимают и не читают, тише отказа: вызывающий получает УСПЕХ и уверен, что его параметр применён. Продукт обещает возможность, которой нет. Обнаруживается это не отладкой, а последствиями — в чужой.

Норма контракта, которую гейт исполняет: у поля публичного запроса ОБЯЗАН быть читатель в прод-коде своей службы; отсутствие — находка, а не стиль. Законных исходов у непрочитанного поля три, четвёртого нет: реализовать · отвергать явно, называя поле, синхронно · снять с контракта, зарезервировав И номер, И имя. «Молча принять и выбросить» исходом не является.

Почему разбор УЗЛОВ, а не поиск имени геттера по дереву ¶

Имя геттера НЕ уникально. Замер на `lane/wb-s4-remnant`, единицы названы:

# сообщений, объявляющих ОДИН И ТОТ ЖЕ геттер, — 57
grep -c 'func (x \*[A-Za-z]*) GetAccountId()' pkg/api/kaname/cloud/iam/v1/*.pb.go
# различных ИМЁН геттеров, встречающихся в прод-коде, — 150
git grep -ohE '\.Get[A-Za-z0-9_]+\(' -- '*.go' ':!*_test.go' ':!pkg/api' | sort -u | wc -l

Полей в сообщениях запроса при этом 295 (перепись гейта, печатается каждым прогоном). То есть предикат по ИМЕНИ различает 150 значений там, где предмет имеет 295, а одно имя `GetAccountId` покрывает 57 разных полей: мёртвое поле выглядело бы живым оттого, что где-то рядом живёт его тёзка.

Поэтому читатель опознаётся парой «получатель × селектор»: идентификатор, чей ОБЪЯВЛЕННЫЙ тип есть `*<пакет>.<Сообщение>`, и обращение к полю через него. Число 295 в этой шапке — снимок; живое печатает перепись.

Что читателем НЕ является, и это решение, а не упущение ¶

• СБОРКА запроса (`&iamv1.XRequest{AccountId: …}`) — это сторона ПРОИЗВОДИТЕЛЯ. Засчитав её, гейт разрешил бы полю жить оттого, что его кто-то заполняет, — ровно то состояние, которое он заведён ловить;
• проба. Прод-код судится прод-кодом: поле, которое читает только проба, арендатору не служит;
• сгенерированный код (`pkg/api/**`). Он объявляет геттер у КАЖДОГО поля by construction, поэтому засчитанный читателем делает гейт тождественно зелёным.

Граница названа: запрос, ушедший в вызов ЦЕЛИКОМ ¶

Запрос, переданный дальше целиком (`h.uc.Execute(ctx, req)`), прослеживается ровно до того вызываемого, чей параметр объявлен тем же типом: дальше цепочка обрывается на интерфейсе или на своей структуре входа. Такие передачи НЕ прощаются молча — они печатаются переписью отдельной величиной, потому что «поле прочитано» и «запрос уехал целиком, а поле, может, и не прочитано» — разные вердикты, и второй обязан быть видим.

retired_issuer_claim.go — ГЕЙТ КЛАССА: утверждение, что прежний внешний OAuth-сервер ОСТАЁТСЯ подписантом либо издателем (или что служба сама не чеканит), законно только в форме надгробия (эпик kacho#2564, линия B).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Своя чеканка токенов действует на каждой предлагаемой цепочке установки (`deploy/values.prod.yaml`, `authn.tokenSigning.enabled: true`), и пять путей выдачи из шести чеканим мы. Но прозу об этом писали в разное время, и в дереве живут ДВЕ редакции одного утверждения:

«data-plane fetches verification keys from iam (Hydra stays the signer).»
«Здесь стояло „Hydra stays the issuer/signer“ — утверждение, пережившее…»

Первая — утверждение, пережившее свой предмет (в дереве оно стояло без кавычек; здесь процитировано, потому что этот файл гейт читает тоже). Вторая — надгробие: та же фраза, но названная ПРЕЖНЕЙ и опровергнутая. Читатель, открывший первую, принимает её за действующее ограничение и строит на ней решение: «раз подписант чужой — ключницу здесь не ротировать, издателя здесь не сверять».

Цена этого класса в этом же дереве уже платилась: одно и то же утверждение «Hydra remains the signer/issuer» жило в ПЯТИ файлах двух репозиториев, и в день, когда его опровергли в одном, четыре других продолжали читаться как норма — их нашла эта перепись, а не обзор диффа.

───────────────────────────────────────────────────────────────────────────── ЧТО СУДИТСЯ — УТВЕРЖДЕНИЕ О ДЕЙСТВУЮЩЕМ, А НЕ СЛОВО

Слово «Hydra» в дереве законно во множестве мест: имена ручек посадки, колонка зеркала в применённой миграции, порт клиента к его админ-API, разбор самого переезда. Гейт по слову краснел бы на исправном дереве и был бы снят первым же обходом. Судится РОД утверждения — что прежний издатель остаётся (stays / remains / является) подписантом или издателем, что ключи проверки «его», что служба ничего не чеканит. Формы перечислены в `RetiredIssuerClaimForms` поимённо, и инъекция гоняет КАЖДУЮ.

───────────────────────────────────────────────────────────────────────────── ЗАКОННЫЙ БЛИЗНЕЦ — НАДГРОБИЕ, И РАСПОЗНАЁТСЯ ОН ДВУМЯ ПРИЗНАКАМИ

1. утверждение стоит В КАВЫЧКАХ на той же строке («…», "…", “…”): корпус цитирует снятое именно так — «Здесь стояло „…“»;
2. на той же строке стоит маркер прошедшего: «стояло», «It said», «пережившее», «no longer», «больше не».

Любого одного достаточно. Надгробие, разнесённое на две строки так, что ни маркер, ни кавычка не попали на строку с утверждением, гейт назовёт находкой — и это верно: такое надгробие читается как утверждение с той же вероятностью, с какой его не узнал распознаватель.

───────────────────────────────────────────────────────────────────────────── ЧЕГО ГЕЙТ НЕ ВИДИТ — НАЗВАНО ВСЛУХ

Описание полосы, названной по прежнему издателю («Hydra-issued token», «via Hydra»), под ось НЕ подпадает: это описание происхождения, а не утверждение о том, кто подписывает сегодня. Часть таких описаний тоже пережила предмет, и правится она обзором — предикат «назван прежний издатель» от «утверждается, что он действует» машинно не отличает. Пробы и e2e-наборы из обхода исключены: там прежний издатель законно стоит фикстурой.

retired_monorepo_gate_ledger.go — разбор «какие имена проб объявлены этим деревом».

Служебная половина ведомости гейтов, снятых из монорепо выносом службы (kacho#2597): ведомость обязана уметь спросить дерево, резолвится ли названный ею держатель, — и спросить УЗЛОМ ОБЪЯВЛЕНИЯ, а не подстрокой.

Разница несущая. Имя пробы встречается в этом дереве трижды помимо своего объявления: в прозе приёмок, в комментариях, объясняющих чем держится свойство, и в самой ведомости ниже. Подстрочный разбор объявил бы держателя живым по упоминанию о нём — то есть ведомость доказывала бы сама себя.

retired_vendor_bindings.go — ГЕЙТ КЛАССА: привязок к снимаемому провайдеру личности в дереве службы не становится больше, а их убыль записывается тем же изменением, которым она сделана (задача #323, эпик kacho#2564).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Прежний провайдер личности (выдача токена и сессия) снимается из службы. Снятие идёт многими изменениями, и каждое из них обязано уменьшать число привязок, а не менять одни на другие. Замер задачи: поле адреса прежнего издателя в конфигурации обогащения токена стояло в 74 строках 30 файлов на cbbac984 и в 79 строках 31 файла на 8f95be6c6 — две новые пробы полос хуков привязались к нему, и ни одна проверка этого дерева не покраснела.

Судья этого класса у платформы (задачи kacho#2730 и kacho#2864, файл `internal/repohygiene/retiredidentityvendorceiling.go` её дерева) читает дерево службы ПО ПИНУ `go.mod` платформы, то есть видит рост только тогда, когда платформа сдвигает пин, — после того как выросшее изменение уже влито здесь. Этот гейт судит то же дерево в момент изменения.

───────────────────────────────────────────────────────────────────────────── ФОРМА — ВЕДОМОСТЬ ПО ФАЙЛАМ, А НЕ ОДНО ЧИСЛО

Ведомость (`RetiredVendorLedger`, файл `RetiredVendorLedgerRel`) хранит ТОЧНОЕ число привязок каждого файла. Исходов у файла три, и два из них — находки:

привязок больше записи (или записи нет)   рост — снимите привязку
привязок меньше записи                    убыль не записана — снизьте запись
                                          до факта тем же изменением
привязок ноль, запись есть                запись без предмета — снимите её

Почему по файлам: сумма по дереву ПРОЩАЕТ перенос. Изменение, снявшее десять строк в одном файле и добавившее одну в новом, по сумме убывает — а новая привязка при этом появилась. Ровно так выглядел рост этой задачи: по всему классу в единице этого гейта дерево между cbbac984 и 8f95be6c6 убыло с 1068 до 873, а две пробы привязались заново. Ведомость по файлам называет такую координату, сумма — нет.

Почему точное число, а не потолок: потолок, не сниженный вслед за убылью, прощает возврат снятого до прежней высоты. Точная запись делает возврат ростом.

ЗАПИСЬ ЗАНИМАЕТ ДВЕ СТРОКИ — путь и число, — и это решение о слиянии, а не вкус. git сливает правки СОСЕДНИХ строк конфликтом (проверено на git 2.53: правки строк 2 и 3 в двух ветках дают конфликт, правки строк 2 и 4 при нетронутой строке 3 — чистое слияние). Две ветки волны, снявшие привязки в разных файлах, правят числа разных записей; строка пути между числами остаётся нетронутой, и сведение волны не конфликтует в ведомости.

───────────────────────────────────────────────────────────────────────────── ЕДИНИЦА СЧЁТА И ОСИ

Класс один: текст несёт имя снимаемого провайдера (`RetiredVendorMarks`), подстрокой без учёта регистра. Мест прочтения три, по оси на каждое:

RetiredVendorAxisPath    путь файла несёт имя        1 единица за файл
RetiredVendorAxisLine    строка текста несёт имя     1 единица за строку
RetiredVendorAxisBinary  байты двоичного несут имя   1 единица за файл

Граница слова НЕ ставится: слитное написание строчными — настоящая привязка, и правило границы отбросило бы её молча. Измерено на 8f95be6c6: слов, где имя продолжено строчной буквой, в дереве службы два (`hydraadminurl`, `hydraadmintokenenv`), и оба — привязки. Чужое слово, втекающее в имя, придёт находкой роста со своим текстом — видно, а не молча.

───────────────────────────────────────────────────────────────────────────── ЗАКОННЫЕ ФОРМЫ — КАК СНЯТИЕ ЗАПИСЫВАЕТСЯ, НЕ ПОДНИМАЯ ВЕДОМОСТИ

Подъём записи ответом не бывает (граница 4 ниже). Формы, которыми снятие обходится без него:

• ИСТОРИЯ СХЕМЫ СНЯТОГО. Строка каталога истории схемы (миграции и их пробы), каждое имя провайдера в которой — часть идентификатора, снятого самой историей, не привязка: миграция, снимающая столбец, обязана его назвать. Правило, условия и границы — `retired_vendor_schema_history.go`; перепись печатает число таких строк отдельно.
• ИМЯ ИЗ СЛОВАРЯ. Проба стража этого класса берёт имя провайдера из его словаря (`RetiredVendorMarks`, `RetiredIssuerName`), а не выписывает заново: привязка — строка словаря, и считается она один раз. То же для имени настройки: проба собирает его из того же словаря, а не выписывает литералом.
• ПЕРЕНОС. Запись нового файла заводится, запись прежнего снижается, обе правки — в одном диффе (шапка ведомости).

───────────────────────────────────────────────────────────────────────────── ЧЕГО ГЕЙТ НЕ ВИДИТ — НАЗВАНО, А НЕ ПОДРАЗУМЕВАЕТСЯ

1. ПРОЗА. Файлы `.md`/`.mdx` и строки, НАЧИНАЮЩИЕСЯ маркером комментария, не судятся: упоминание провайдера в тексте дерево к нему не привязывает, а утверждение о нём как о действующем судит `retired_issuer_claim.go`. Перепись печатает число таких строк отдельно.
2. ВЕДОМОСТЬ. Файл `RetiredVendorLedgerRel` — запись этого гейта, а не привязка; он исключён по точному пути, и его отсутствие в дереве — отказ (исключение, которому нечего исключать, истекает само).
3. ПУТЬ API ПРОВАЙДЕРА БЕЗ ЕГО ИМЕНИ, ИМЯ, СКЛЕЕННОЕ ИЗ ЛИТЕРАЛОВ, И СОДЕРЖИМОЕ АРХИВОВ. Эти оси держит судья платформы по пину: словарь поверхностей живёт у него в единственном экземпляре, копия его сюда запрещена правилом о копиях между репозиториями. Архивов в дереве службы нет; двоичные судятся байтами, и их число печатается переписью.
4. ПОДЪЁМ ЗАПИСИ. Ведомость — файл дерева, и изменение может поднять число записи вместе с ростом. Гейт этого не различает: без дерева базы перенос привязки из файла в файл и чистый рост дают одну и ту же правку. Подъём виден диффом одного файла, а чистый рост против базы ловит судья платформы на сдвиге пина. Так зелёное уже добывалось: сборка #483 подняла пять записей на 42 (коммит 49c38e18c) — строки снятия столбца, проба стража с именем литералом, проба с именем настройки литералом и перенос методов, записанный не в том диффе, где снижен прежний файл. Каждому из этих случаев отвечает законная форма выше.
5. ИМЯ ИЗ СЛОВАРЯ В НЕ-ПРОБЕ. Форма «имя из словаря» законна для проб стража; не-тестовый код, собирающий имя провайдера из словаря, привязку прячет, и гейт её не видит — как и всякую склейку (граница 3).

retired_vendor_bindings_ledger.go — ВЕДОМОСТЬ привязок к снимаемому провайдеру личности, по файлу. Судит её `retired_vendor_bindings.go`; единица счёта — `RetiredVendorCountingUnit`.

Число записи — ТОЧНОЕ число привязок файла, а не потолок:

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

Запись ЗАНИМАЕТ ДВЕ СТРОКИ — путь и число: две ветки, снявшие привязки в соседних по порядку файлах, правят несоседние строки и сливаются без конфликта (обоснование — шапка `retired_vendor_bindings.go`). Пути строго по возрастанию: форма проверяется судьёй, и место новой записи однозначно.

Точка отсчёта — дерево 8f95be6c6 (голова линии #367 на момент заведения), из которого тем же изменением сняты шесть строк роста, найденного задачей #323: две пробы полос хуков задавали адрес прежнего издателя, которого не судят. На сведённом дереве сборки волны 4 (#483) записи приведены вниз к факту: полосы волны снимали привязки, ещё не зная этой ведомости. Рост, который они принесли в пяти файлах, НЕ записан: три файла сняли привязки по существу, а строки миграции, снявшей столбец зеркала, и её пробы — история схемы снятого идентификатора (`retired_vendor_schema_history.go`); то же снятие снизило запись свода, который столбец завёл. Ни одна запись не поднималась выше точки отсчёта и ни одна не заведена сверх неё. Каждая запись уходит вниз вместе с изменением, снимающим её привязки.

retired_vendor_schema_history.go — ЗАКОННАЯ ФОРМА СНЯТИЯ для гейта `retired_vendor_bindings.go`: строка истории схемы, называющая идентификатор, который сама история сняла, — не привязка (задача #323, сборка #483).

───────────────────────────────────────────────────────────────────────────── ПОЧЕМУ ФОРМА НУЖНА

Столбец, названный по снимаемому провайдеру, снимается миграцией, и миграция обязана назвать его: `DROP COLUMN` без имени не пишется, предохранитель наката спрашивает строки по нему же, откат восстанавливает его под тем же именем, проба миграции засевает прежнее состояние и спрашивает столбец после отката. Судья, считающий каждую такую строку привязкой, объявлял снятие РОСТОМ: миграция снятия столбца зеркала прежнего издателя (#362) дала ему 29 строк в двух новых файлах, и зелёное на сборке #483 было получено подъёмом ведомости — ровно той правкой, которую гейт различить не может (граница 4 его шапки). Эта форма делает подъём ненужным: снятие столбца снижает ведомость, в том числе у свода, который столбец завёл.

───────────────────────────────────────────────────────────────────────────── ПРАВИЛО

Идентификатор СНЯТ ИСТОРИЕЙ, когда выполнены все четыре условия:

1. накат (секция до `-- +goose Down`) какой-либо миграции каталога его снимает оператором `DROP COLUMN | CONSTRAINT | INDEX | TABLE` — в исполняемом тексте: снятие в комментарии или в строковом литерале снятием не является;
2. после последнего такого снятия тот же накат его не называет;
3. ни одна миграция с бóльшей версией его не называет — ни накатом, ни откатом;
4. снятий не меньше, чем заведений во всех накатах: имя, заведённое в двух таблицах и снятое в одной, живо.

Строка ФАЙЛА КАТАЛОГА ИСТОРИИ (миграция либо файл Go рядом с ней — проба миграции) не привязка, когда КАЖДОЕ имя провайдера в ней — часть снятого историей идентификатора. Такие строки считаются переписью отдельно и печатаются числом, как проза и комментарии.

Идентификатор — наибольший отрезок `[a-z0-9_]` вокруг вхождения метки, в нижнем регистре, без схемы и кавычек: `kaname.t.<метка>_id` даёт `<метка>_id`, а `t_<метка>_id_check` — самостоятельное имя со своими снятием и заведением.

───────────────────────────────────────────────────────────────────────────── ЧТО ФОРМА НЕ ПРОЩАЕТ — И ЧЕМ ЭТО ДОКАЗАНО

Строка вне каталога истории (репозиторий, край, чарт) — привязка, даже если называет снятый столбец: код, читающий снятый столбец, — дефект, а не история. Вложенный каталог — не история. Путь файла — своя ось, и история её не прощает. Метка пути образа идентификатором SQL не бывает и не прощается никогда. Каждое из этого и каждое из четырёх условий выше гоняется инъекцией: `retired_vendor_schema_history_injection_test.go`.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

Все они падают в сторону ПОДСЧЁТА — незнакомая форма даёт привязку, видимую ростом, а не молчание:

• снятие столбца без слова `COLUMN` (`ALTER TABLE t DROP x`) не узнаётся;
• `DROP TABLE a, b` узнаёт только первое имя;
• заведение считается формами `CREATE [UNIQUE] INDEX`, `CONSTRAINT x` (кроме `DROP CONSTRAINT`), `ADD [COLUMN]`, `CREATE TABLE`, `RENAME … TO` и определением столбца в начале строки; лишнее совпадение (строка условия, начатая именем столбца) досчитывает заведения и падает в сторону подсчёта.

ЕДИНСТВЕННАЯ граница, падающая в сторону ПРОЩЕНИЯ: заведение формой, которой распознаватель не знает (`CREATE TABLE … AS`, `LIKE`, наследование), недосчитывает заведения. После снятия — в том же накате или в поздней миграции — её держат условия 2 и 3: такая форма имя называет. ДО снятия — то же имя во второй таблице, заведённое незнакомой формой, пережило бы снятие в первой, и строки истории о нём прощались бы. Код, читающий такой столбец, лежит вне каталога истории и судится как всякая привязка; прощаются только строки самой истории.

revocation_writer_has_a_caller.go — ПУТЬ СНЯТИЯ ДОСТУПА, НЕ ДОСТИГАЮЩИЙ НОСИТЕЛЯ, КОТОРЫМ СУДИТ ЧИТАТЕЛЬ (задача kaname#313).

───────────────────────────────────────────────────────────────────────────── ФОРМА ДЕФЕКТА, А НЕ ЕГО ЭКЗЕМПЛЯР

Записей отсечки в службе больше одной. У каждой свой ключ, свой круг читателей и своя величина сравнения, и взаимозаменяемыми они не являются. Отсюда форма: запись ОБЪЯВЛЕНА, писатель для неё НАПИСАН, а позвать его некому — и тогда контроль существует в виде кода, не исполняясь ни при каком входе. Отличить это от работающего контроля чтением нельзя: «не отозван» и «отзыв не доехал» дают один и тот же наблюдаемый ответ.

Гейт судит ДЕРЕВО, а не ведомость записей: ведомость ослепла бы ровно тогда, когда опустеет, а множество таблиц отсечки ВЫВОДИТСЯ обходом — по имени, оканчивающемуся на суффикс отсечки, — и печатается переписью.

───────────────────────────────────────────────────────────────────────────── НАПРАВЛЕНИЕ ОШИБКИ ВЫБРАНО, А НЕ ПОЛУЧИЛОСЬ

Вызов опознаётся ПО ИМЕНИ функции или метода где угодно в не-тестовом дереве. Это заведомо ЩЕДРО к писателю: вызов через интерфейс с тем же именем метода засчитывается, хотя разбор не доказывает, что реализация именно эта. Выбрано так намеренно: ложная находка у гейта, судящего безопасность, заставляет снимать сам гейт, а пропуск оставляет предмет видимым другим приборам.

───────────────────────────────────────────────────────────────────────────── ЧЕГО РАЗБОР НЕ ВИДИТ — НАЗВАНО, А НЕ СПРЯТАНО

1. писатель, чей единственный вызывающий — тоже мёртвый код: цепочку достижимости от композиционного корня разбор не строит;

2. писатель на SQL, собранном из кусков во время исполнения: разбор читает строковый ЛИТЕРАЛ, а не результат конкатенации;

3. писатель в схеме (триггер, функция) — он не Go и здесь не судится; именно такие писатели и создают вид работающего контроля;

4. ПИСАТЕЛЬ ОДНОЙ ЗАПИСИ ОТСЕЧКИ ИЗ ДВУХ — у него исполнитель ЕСТЬ, и этот гейт о нём молчит законно. Свойство независимое, и судят его отдельные гейты пары в `paired_write.go`, со СВОЕЙ, узкой склейкой по вызову.

   Перечень границ, названный не полностью, хуже отсутствующего: он создаёт уверенность. Эта граница названа здесь потому, что именно её отсутствие позволило дефекту уцелеть — гейт был зелён, а четыре писателя полосы входа клали одну запись из двух.

role_operation_response_state.go — анализатор «ответ операции над ролью не несёт вычисленного состояния, и это ОБЕСПЕЧЕНО, а не совпало».

Порт с монорепо (`internal/repohygiene/roleoperationresponsestate.go`, снят вынесением службы — `kacho#2597`). Дословно: весь анализатор. Изменилось: пакет (`repohygiene` → `check`); `ServiceRoot` теперь пустая строка у вызывающего — в kaname дерево службы лежит от корня, а не под `services/iam`.

Предмет ¶

Контракт роли обещает арендатору буквально следующее: нулевое значение `health` и `lifecycle` означает «ЭТИМ ОТВЕТОМ НЕ ВЫЧИСЛЕНО» и никогда «роль здорова» либо «роль объявлена»; его несут ответы операций `Create`/`Update`, а `Get` и `List` заполняют состояние всегда.

Обещание держится ТОЛЬКО ТЕМ, что производителя вычисленного состояния никто не звал на пути мутации. Свойство «by construction» тем и плохо, что его снятие ТИХОЕ.

Что судится ¶

ПЕРЕВОДЧИК ответа операции над ролью — не-тестовая функция, у которой (а) результаты ровно `(*anypb.Any, error)`, (б) есть параметр типа `domain.Role` и (в) в теле стоит вызов перевода `dto.Transfer`. Каждый такой переводчик обязан звать проекцию (`domain.Role.WithoutComputedState`). Не зовёт — находка с координатой.

ЧЕГО ОН НЕ СУДИТ ¶

1. ПОЛНОТУ набора производных полей — предмет пробы самой проекции;
2. ЛИШНЮЮ РАБОТУ — расход без последствий для контракта;
3. ЧТЕНИЯ (`Get`/`List`) — у них результат не `(*anypb.Any, error)`.

Падает на ПУСТОМ ОБХОДЕ ¶

Ноль прочитанных файлов, ноль разобранных функций либо ноль найденных переводчиков роли — «находок ноль» неотличимо от «прочитано ноль».

role_scope_chain_stays_empty.go — САМОИСТЕКАЮЩИЙ гейт решения «меточную ось сужать НЕ НАДО» (задача продукта kacho#1913, приёмка `docs/engineering/acceptance/role-withdrawal-has-a-producer.md` §2.8, §10 шаг 8).

Порт с монорепо (`internal/repohygiene/rolescopechainstaysempty.go`, снят вынесением службы — `kacho#2597`). Дословно: весь предикат, распознаватели, закрытый перечень ярусных источников. Изменилось: пакет (`repohygiene` → `check`), путь-приставка обхода (`services/iam/` снята — в kaname код службы лежит от корня).

Что здесь стережётся — ФАКТ О ДЕРЕВЕ, на котором стоит решение ¶

Приёмка решила НЕ сужать меточную ось выдачи по живости роли, и решение стоит целиком на одном факте: у роли МОДУЛЯ цепь областей ПУСТА, поэтому меточная выдача не достаёт её ни живую, ни снятую. Факт измерен и верен сегодня — и НЕ ЗАЩИЩЁН НИЧЕМ:

• роль модуля всегда кластерного яруса, потому что `owner_module` и `cluster_id` пишет ОДИН оператор, а не ограничение схемы;
• у роли кластерного яруса цепь пуста, потому что ни одна ветвь производителя звеньев её не отбирает: ветви берут `account_id` и `project_id`, а у роли модуля они пусты оба.

Значит производителя звена для `iam_role` может завести любая соседняя работа. Появится он — решение §2.8 станет неверным, а доступ вернётся МОЛЧА. Этот гейт и есть то единственное, что об этом скажет.

ЧТО СЧИТАЕТСЯ НАХОДКОЙ — ИСТОЧНИК ветви, а не имя типа ¶

Ветвей, производящих звено для `iam_role`, две, и обе ЗАКОННЫ:

(5a) роль АККАУНТА  → источник `account_id`
(5b) роль ПРОЕКТА   → источник `project_id`

Находка — ТРЕТЬЯ ветвь: та, что производит звено для `iam_role`, не спрашивая ни одного из двух ярусных столбцов.

ЧЕГО РАЗБОР НЕ ВИДИТ — НАЗВАНО, А НЕ СПРЯТАНО ¶

1. звено, приехавшее ЗЕРКАЛОМ ресурса (writer одинаков для всех типов);
2. запрос, собранный из кусков в рантайме;
3. производителя вне дерева kaname.

role_verb_projection_sole_writer.go — разбор операторов записи в проекции роли: «кто АВТОРУЕТ строку, кто её СНИМАЕТ, переселяет ли снимающий-не-автор снятое» (порт с монорепо `internal/repohygiene/roleverbsolewriter_test.go`, держатель `TestIAMRV112_RoleVerbProjectionHasASoleWriter`, снят вынесением службы доступа — `kacho#2597`).

Предмет ¶

Таблицы `kaname.role_verb` и `kaname.role_rule_ref` — проекции роли, то, из чего цепь вердикта собирает ответ «разрешено ли действие». Класс, ради которого гейт заведён: ДВЕ реализации знают, что такое законная строка, и расходятся МОЛЧА — обе компилируются, у обеих есть пробы, и различаются они только на входе, который ни одна проба не подаёт.

Единица — «авторует», а не «пишет» (решение kacho#1034, перенесено дословно) ¶

Что такое законная строка, объявляет ТОЛЬКО `INSERT`: он называет колонки и значения. `DELETE`/`UPDATE` строку не авторуют — они её снимают или правят. Значит класс живёт в АВТОРСТВЕ, а не в записи вообще, и единица гейта — функция, ВНОСЯЩАЯ строку. Снимающий не-автор обязан ПЕРЕСЕЛИТЬ снятое в `kaname.role_grant_orphan` ТЕМ ЖЕ оператором — иначе отобранное право неотличимо от никогда не выданного.

Что изменилось при переносе, а что осталось дословно ¶

Изменилось: пакет (`repohygiene` → `check`), путь-константа слоя (без префикса `services/iam/` — код лежит от корня модуля kaname), обход дерева (`gitenv`+`git ls-files` вручную → `github.com/PRO-Robotech/kacho/pkg/treecorpus` и `internal/testsupport/platformtree.RequireCorpus`, потому что предмет — внутри службы, дерева платформы модулю не нужно). Осталось дословно: имена таблиц-проекций, форма распознавателя (узел-литерал разобранного AST, а не текст файла), три оси проверки (авторство · переселение · слой) и имя держателя `TestIAMRV112_RoleVerbProjectionHasASoleWriter` — на нём стоят цитаты `docs/engineering/acceptance/role-verb-projection-sole-writer.md`, `rule-segments-have-a-referent.md` и `module-manifest-roles-and-seed-grants.md`, написанные ДО выноса, когда `internal/repohygiene` был тем же репозиторием.

Граница названа, а не умолчана ¶

Гейт читает СТРОКОВЫЕ ЛИТЕРАЛЫ непроверочного кода Go, разобранного в дерево, и приписывает находку объемлющей функции. Он НЕ видит: SQL миграций (там запись законна — миграция и есть схема), проб (им положено готовить состояние), имя таблицы, собранное из кусков (слепая зона, предикатом по подстроке не ловится ничем).

seed_identity_census.go — разбор ДВУХ текстов об одном предмете: вывода переписи посевной идентичности и чисел, объявленных приёмкой `docs/engineering/acceptance/seed-identity-names-its-own-service.md` §0.

ПРЕДМЕТ ¶

У приёмки есть исполняемый предикат, лежащий рядом с ней (`seed-identity-names-its-own-service.py`), и числа §0 — его вывод. Пока предиката никто не зовёт, эти два текста расходятся МОЛЧА: документ продолжает называть числа, верные для ревизии, которой в стволе уже нет, и отличить «перемерено» от «переписано по памяти» нечем.

ПРИЗНАК — ИЗМЕРЕН, А НЕ ПРЕДПОЛОЖЕН ¶

Расхождение наступило до заведения этого гейта и было найдено вручную: объявление называло по ведру ПРЕДМЕТА `130 · 54 ф.`, предикат на стволе давал `130 · 56 ф.`. Вхождений СТОЛЬКО ЖЕ — двигались файлы, — поэтому расхождение не видно ни по одному числу в отдельности и обнаруживается только сверкой обоих текстов целиком.

ЕДИНСТВЕННЫЙ ИСТОЧНИК ПЕРЕЧНЯ ВЁДЕР — САМ ПРЕДИКАТ ¶

Перечень вёдер здесь НЕ выписан. Он берётся из того, что предикат напечатал: выписанный был бы вторым местом об одном предмете и разошёлся бы с предикатом ровно тогда, когда тот заведёт новое ведро, — то есть остался бы зелёным на ведре, о котором никто не спросил.

ЧЕГО ЭТОТ РАЗБОР НЕ СУДИТ ¶

• ИСТИННОСТЬ вёдер. Правильно ли предикат раскладывает вхождение по вёдрам — вопрос его собственной адъюдикации, и машинного предиката у него нет;
• ПРОЗУ §0. Числа, названные прозой в тексте, здесь не ищутся: их формы столько же, сколько предложений, и разбор по образцу нашёл бы собственное объяснение. Судится ОБЪЯВЛЕНИЕ — блок, названный ревизией измерения.

seeded_service_accounts.go — разбор посева служебных учёток по цепочке миграций: вставка заводит строку, удаление её снимает.

Порт ОБЩЕГО вспомогательного разбора с монорепо (жил как package-private `seededSA`/`foldSeededServiceAccounts` в `internal/repohygiene/moduleserviceaccounthasacomponent_test.go`, снят вынесением службы — `kacho#2597`). Перенесён в НЕ-тестовый файл и экспортирован, потому что нужен как минимум ДВУМ гейтам монорепо: `moduleidentityseededonlybythebaseline` (перенесён этим же изменением, `module_identity_seeded_only_by_baseline.go`) и `moduleserviceaccounthasacomponent` (семейство, НЕ входящее в батч `kacho#2597` этого агента — предмета оно судит компоненты дерева, отдельная от «когда посеяно» ось). Держать разбор внутри теста значило бы, что следующий перенос его продублирует, не заметив: инструкция переноса прямо требует проверить, не появился ли общий помощник, и переиспользовать его — вместо копии.

sentinel_translator_parity.go — разбор ПЕРЕВОДЧИКОВ отказа: какие полосы каждый из них различает.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ

Переводчик отказа — то место, где признак хранилища становится кодом gRPC. У домена он свой: текст терминального INTERNAL называет предмет («internal SA key error»), и сводить их в один нельзя — текст есть часть контракта.

Своим обязан быть ТЕКСТ, а не НАБОР РАЗЛИЧАЕМЫХ ПОЛОС. Полоса, которой переводчик не знает, уезжает в терминальный INTERNAL — то есть отказ, ПОВТОРЯЕМЫЙ по своей природе, приходит клиенту как поломка платформы, и клиент не повторит. Обратное так же плохо: отказ в правах, поданный как INTERNAL, прячет от вызывающего, что ему нечего чинить повтором.

Класс уже закрывался ОДНАЖДЫ и вернулся. Годок канонического переводчика говорит дословно: «Полное покрытие 8 sentinel'ов (включая ErrPermissionDenied / ErrUnauthenticated, которых не было в per-resource копиях — leak'ало codes.Internal клиенту до этой консолидации)». Копии завелись заново и снова разошлись набором ветвей (kaname#114): `ErrAborted` достижим — 40001/40P01 приходит из `pgmaperr`, — и на путях ключей и токенов уходил в INTERNAL.

───────────────────────────────────────────────────────────────────────────── ЧТО СЧИТАЕТСЯ ПЕРЕВОДЧИКОМ — ПРИЗНАК СЕМАНТИЧЕСКИЙ, А НЕ ПО ИМЕНИ

Предикат по имени (`mapPGErr`, `mapErr`) мерил бы соглашение об именовании: переводчик, названный иначе, прошёл бы мимо — ровно тот отказ, который гейт и заводится закрыть. Переводчиком считается функция, у которой ОБА признака:

1. она различает ДВА И БОЛЕЕ разных sentinel'а `iamerr.Err*` в условии (ветвь `case` бестегового `switch` либо условие `if`);
2. её ПОСЛЕДНИЙ оператор — терминальный `status.Error(codes.Internal, "…")` с литералом.

Второй признак и есть «переводчик», а не «проверка на месте вызова»: функция, разбирающая одну полосу и отдающая остальное канону (`shared.MapRepoErr`), терминального INTERNAL не несёт и под разбор не подпадает. Без этого признака находкой стал бы каждый вызывающий, спрашивающий `ErrNotFound`.

───────────────────────────────────────────────────────────────────────────── ФОРМЫ ЗАПИСИ ПЕРЕЧИСЛЕНЫ ПОИМЁННО

Форма, о которой распознаватель не знает, даёт МОЛЧАНИЕ. Читаются:

case errors.Is(err, iamerr.ErrX):        — ветвь бестегового switch
case stderrors.Is(err, iamerr.ErrX):     — он же под псевдонимом пакета
if errors.Is(err, iamerr.ErrX) { … }     — условие if
errors.Is(a, iamerr.ErrX) || errors.Is(…) — дизъюнкция внутри условия

Псевдоним пакета `errors` разбор НЕ читает намеренно: он опознаёт sentinel по АРГУМЕНТУ (`iamerr.ErrX`), а не по имени вызываемого пакета. Поэтому `stderrors`, `goerrors` и любое другое написание опознаются одинаково.

ПОЛОСА КОНЦА КОНТЕКСТА (kaname#383) — не sentinel `iamerr`, а ошибки пакета `context`: `context.Canceled` и `context.DeadlineExceeded`, в тех же формах записи. Пакет опознаётся по ПУТИ ИМПОРТА файла, поэтому псевдоним импорта (`stdctx "context"`) читается так же, как голое имя; файл без импорта пакета читается по голому имени `context`. Поле `Canceled` чужого значения полосой не читается. В признак переводчика (п. 1 выше) эти полосы НЕ входят: счёт — по sentinel'ам `iamerr`, иначе переводчиком стала бы функция, судящая только срок.

───────────────────────────────────────────────────────────────────────────── ЧЕГО РАЗБОР НЕ ВИДИТ — НАЗВАНО, А НЕ СПРЯТАНО

1. **порядок ветвей**. Он несущий (у канона вложенные полосы спрашиваются до общего switch'а), но это другой предмет и другой гейт;
2. **правильность КОДА** у ветви. Гейт судит, различает ли переводчик полосу, а не в какой код он её переводит;
3. **переводчик БЕЗ терминального INTERNAL** — он под признак не подпадает и остаётся вне наблюдения. Это осознанная граница: без неё находкой стала бы всякая проверка на месте вызова.

sql_relation_name.go — ОБЩИЙ распознаватель имени отношения в тексте SQL. По нему судят оба гейта материала способа входа: гейт дерева Go — значения строковых литералов и их склеек (`login_verifier_containment.go`), гейт схемы — тексты подпрограмм базы (`internal/repo/kaname/pg` `TestLoginVerifierStaysInsideTheSchema`). Его же лексемы судят посылку гейта единственного писателя счёта (`failure_reset_sole_writer.go`). Разбор ОДИН: вторая копия разошлась бы с первой молча, и расхождение пришлось бы ровно на то написание, которое знает только одна из копий.

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ — ГРАММАТИКА, А НЕ ПОДСТРОКА

Прежде оба гейта искали имя таблицы образцом «целое слово, регистр как есть». Базе регистр имени без кавычек безразличен: `KANAME.USER_LOGIN_METHODS` она разрешает в ту же таблицу, и триггер соседней таблицы, читавший материал так, проходил мимо гейта схемы с «называющих таблицу 0». Ошибался образец и в обратную сторону: `user_login_methods$x` и `user_login_methodsé` для базы — другие имена, а образец считал их упоминанием.

Перечень написаний выведен из лексической структуры Postgres 16 (раздел 4.1 документации: идентификаторы, строковые константы, комментарии), а не из памяти:

ИМЯ
  без кавычек          [A-Za-z_\x80-\xff][A-Za-z0-9_$\x80-\xff]*; регистр
                       приводится к нижнему ТОЛЬКО у ASCII — база в UTF8
                       прочих букв не приводит
  в кавычках           "…", `""` внутри — кавычка; сравнение побайтовое
  Юникодное            U&"…" и u&"…": \XXXX, \+XXXXXX, `\\`, суррогатная
                       пара — один знак; UESCAPE 'c' после имени меняет знак
                       экранирования
  длиннее 63 байт      база усекает до 63 (NAMEDATALEN-1) по границе знака —
                       усекается и здесь
  со схемой и без неё  `схема.имя` и имя через путь поиска; `ONLY имя`,
                       `имя AS m`, `имя m`, `имя%ROWTYPE` — судится само имя

ИМЯ ВНУТРИ СТРОКИ — содержимое строки судится как текст SQL ещё раз: так
живут динамический SQL (`EXECUTE '…'`), разбор имени (`'…'::regclass`,
`to_regclass('…')`) и аргумент `format`
  '…' и N'…'           `''` — кавычка; содержимое судится и как есть, и с
                       раскрытой обратной косой (на случай посадки с
                       standard_conforming_strings = off)
  E'…'                 \b \f \n \r \t, \o…\ooo, \xh…\xhh, \uXXXX,
                       \UXXXXXXXX, `\c` — сам знак c
  U&'…'                как U&"…", с UESCAPE
  $метка$…$метка$      содержимое как есть
  продолжение          строки, разделённые пробелами с переводом строки
                       (и строчными комментариями после него), — одна строка
  склейка ||           цепочка строковых констант через `||` судится и
                       целиком, и по звеньям — как склейка у гейта Go
  B'…', X'…'           битовые строки: имени не несут и не судятся

КОММЕНТАРИИ — не судятся: `--` до конца строки и `/* */` с вложением.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦЫ, НАЗВАННЫЕ ВСЛУХ

1. ИМЯ, СОБРАННОЕ ВО ВРЕМЯ ИСПОЛНЕНИЯ, НЕ УЗНАЁТСЯ: склейка с переменной, `lower('USER_…')`, имя из каталога по oid — это поток данных, а не лексика.
2. АРГУМЕНТ `format('%I', …)` СУДИТСЯ КАК ТЕКСТ SQL. `%I` берёт имя в кавычки, и `format('%I', 'USER_LOGIN_METHODS')` называет ДРУГОЕ отношение, — распознаватель найдёт в нём таблицу. Ошибка в сторону лишней находки, не пропуска.
3. СТРОКИ, ВЛОЖЕННЫЕ ГЛУБЖЕ sqlMaxNesting, судятся без грамматики: имя ищется без учёта регистра и кавычек — лишняя находка возможна, пропуск нет.
4. ОСКОЛОК ТЕКСТА (литерал Go, который склеивают во время исполнения): незакрытые строка и имя в кавычках судятся как текст SQL до конца осколка — они могли открыться в соседнем осколке. Комментарий, открытый в осколке, судится как комментарий.
5. ТЕКСТ НЕ НА SQL — подпрограмма на языке, чью грамматику распознаватель не знает: `SQLRoutineNamesRelation` судит его без грамматики, как в границе 3.
6. ЭКРАНИРОВАНИЕ НА КРАЮ ДИАПАЗОНА судится как у базы (сверено с postgres:16, проба `sql_relation_name_escape_test.go`): \ooo выше \377 — младший байт (\563 → 's'); \u, \U и U& с нулём либо выше U+10FFFF база отвергает — здесь остаются как написано, и коса граничит имя (лишняя находка, не пропуск). Суррогаты — так же, как у базы, в E-строке и в U&: пара склеивается в один знак (и через смешение \u/\U, \XXXX/\+XXXXXX); одиночный старший, одиночный младший и \u/\U с неполными цифрами база отвергает — здесь они остаются как написано (kaname#174). НЕ судится: годность байтов в кодировке.

subject_change_flush_parity.go — извлечение для гейта «полоса производителей очереди смены субъекта не пополняется МОЛЧА» (задача #17, порт-ПОЛОВИНА семейства `subjectchangeflushparity` с монорепо `internal/repohygiene/subjectchangeflushparity.go`, снятого выносом службы — `kacho#2597`).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ ПРЕДКА — ДВЕ ПОЛОСЫ ОДНОГО МЕХАНИЗМА, СВЕРЯЕМЫЕ МЕЖДУ СОБОЙ

Смена прав доезжает до кэша решений края ДВУМЯ независимыми полосами:

• НЕМЕДЛЕННО, на реплике, обслужившей мутацию, — самосбросом по полному имени метода (набор `subjectChangingFQNs` у края);
• С ЗАДЕРЖКОЙ, на соседних репликах, — через очередь смены субъекта (`kaname.subject_change_outbox`), которую край читает сам.

Полосы кормит ОДНО событие, но перечни у них РАЗНЫЕ и ведутся врозь. Заведя шестого производителя очереди, легко не вспомнить о самосбросе: соседние реплики сойдутся за интервал опроса, а та, что мутацию обслужила, продолжит отвечать по закешированному вердикту — то есть по ОТОЗВАННОМУ праву, и дольше всех именно там, где пользователь только что нажал «отозвать».

Заметить это по одной полосе нельзя: каждая исправна сама по себе. Предок поэтому спрашивал не «верен ли перечень» (это и есть спорный вопрос), а РЕШАЛ ЛИ КТО-НИБУДЬ, что полосы различаются.

───────────────────────────────────────────────────────────────────────────── ЧТО РАЗРЕЗ СДЕЛАЛ С ЭТИМ ГЕЙТОМ — СКАЗАНО ЧИСЛОМ, А НЕ ОГОВОРКОЙ

Полосы развело по РАЗНЫМ РЕПОЗИТОРИЯМ. Замер этого дерева (`61053691` плюс дифф этого изменения):

производители очереди   internal/apps/kaname/api            5  ЗДЕСЬ
набор самосброса        gateway/internal/middleware/authz.go 0  у края платформы

Предикат второй строки: `git grep -l subjectChangingFQNs` → 0; каталога `gateway` в составе этого дерева нет вовсе (`git ls-files gateway | wc -l` → 0).

Сверить полосы МЕЖДУ СОБОЙ отсюда нельзя, и обходить это чтением чужого репозитория с диска — НЕЛЬЗЯ ТЕМ БОЛЕЕ: вердикт стал бы свойством того, что случайно лежит в модульном кеше машины прогона, а не свойством коммита ни одного из двух деревьев. Тот же довод, по которому соседнее семейство (`subject_change_gap_detection_test.go`) судит два звена из трёх.

───────────────────────────────────────────────────────────────────────────── ЧТО ЭТА ПОЛОВИНА ДЕРЖИТ — И ЧЕГО ОНА НЕ ДЕРЖИТ

ДЕРЖИТ: полоса производителей не пополняется молча. Перечень объявлен в дереве, и гейт сверяет его с разбором. Шестой производитель делает вердикт красным, а правку перечня — ВИДИМОЙ В ДИФФЕ, где обзор и спрашивает: «а краю сказали?». Без этого добавление производителя не оставляет в этом репозитории следа ВООБЩЕ, и расхождение полос наступает молча.

НЕ ДЕРЖИТ: что край свой набор пополнил. Это утверждение о ЧУЖОМ дереве, и сделать его отсюда нечем. Объявленный здесь перечень — ОПЕРАНД для той стороны: пинить его вправе гейт платформы, потому что перечень отслеживается git и меняется только изменением.

Сказано прямо, потому что половина, выдающая себя за целое, хуже отсутствия: зелёный вердикт читался бы как «полосы сошлись».

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ УЗЕЛ ОБРАЩЕНИЯ, А НЕ УЗЕЛ ВЫЗОВА — ЦЕНА ИЗМЕРЕНА ПРЕДКОМ

Обращений к методу в дереве ДВЕ формы, и обе законны:

w.AccessBindingsW().EmitSubjectChangeEvent(ctx, …)              // вызов на месте
fanout(ctx, …, w.AccessBindingsW().EmitSubjectChangeEvent, …)   // передан значением

Вторая появляется, когда строка пишется НА КАЖДОГО субъекта привязки общим развёртывателем: сам вызов уезжает в него, а производителем остаётся use-case, который метод отдал. Распознаватель, знавший только первую, объявлял вторую отсутствующей — не нарушением, а НЕВИДИМОСТЬЮ: два живых производителя пропадали из переписи. Поэтому судится `*ast.SelectorExpr`: узел вызова его содержит, поэтому обе формы считаются по разу и ни одна дважды.

В этом дереве вторая форма ЖИВАЯ — её несут `access_binding/delete.go` и `access_binding/revoke.go`, то есть два производителя из пяти. Слепота стоила бы ровно их.

system_role_row_is_never_deleted.go — разбор прод-кода kaname на предмет удаления строки СИСТЕМНОЙ роли (порт с монорепо `internal/repohygiene/systemrolerowisneverdeleted.go`, снят вынесением службы доступа — `kacho#2597`; решение `docs/engineering/architecture/role-withdrawal-is-a-mark.md`, задача продукта kacho#1913).

Предмет ¶

Роль, объявленная манифестом модуля, системная BY CONSTRUCTION: применитель ставит `IsSystem: true`, а `roles.is_system` вычисляется из `cluster_id`. Значит вопрос «как снять роль модуля» есть вопрос «что делает прод-код со строкой системной роли», и у него два взаимоисключающих ответа: удалить строку либо пометить её снятой. Линия выбрала ВТОРОЙ:

1. **роль в работе не удалится вовсе.** Выдачи ссылаются на роль ключом `access_bindings_role_fk … ON DELETE RESTRICT`; удаление роли, за которой стоит хоть одна строка выдачи, отвергается `SQLSTATE 23503`;
2. **если бы не отвергалось — три проекции уехали бы МОЛЧА**: селекторы правил, проекция глаголов и проекция объявленных сегментов;
3. **отзыв перестал бы достигать ПРЕДЪЯВЛЕНИЯ наблюдаемо.** У снятой пометкой строки есть что читать на пути запроса; у удалённой читать нечего.

Что здесь считается находкой — ОДНА ось, и она про оператор ¶

Оператор `DELETE` над таблицей `roles`, не сужённый на ПОЛЬЗОВАТЕЛЬСКУЮ роль. Сужение опознаётся в ДВУХ законных написаниях: `is_system = false` (и `NOT is_system`) — прямо по вычисляемой колонке; `cluster_id IS NULL` — по кластерному якорю, из которого она и вычисляется.

Ось судит СТРОКОВЫЙ ЛИТЕРАЛ узла разбора, а не текст файла: слово `DELETE` стоит и в комментариях, объясняющих сам запрет. Оператор отличается от ПРОЗЫ, цитирующей оператор, по ПРОДОЛЖЕНИЮ за именем таблицы (`WHERE`, `RETURNING`, `USING`, `;`, конец литерала) — привязки к началу строки недостаточно.

Что изменилось при переносе, а что осталось дословно ¶

Изменилось: пакет (`repohygiene` → `check`), путь-константа (`iamGoPrefix = "services/iam/"` → обход всего дерева модуля без префикса, код лежит от корня). Осталось дословно: обе регулярки сужения и продолжения, форма распознавателя (`ScanRoleDeletes`), имя держателя `TestSystemRoleRowIsNeverDeleted`.

Чего разбор НЕ видит — названо, а не спрятано ¶

1. **миграции.** Каждая снимала роль удалением до решения — это СТАТУС-КВО, который решение и заменяет, а не находка сегодняшнего дерева;
2. **каскад по чужому ключу.** Строка роли уезжает вместе со своим ярусом (аккаунт, проект). Для СИСТЕМНОЙ роли ярус — кластер;
3. **запрос, собранный из кусков в рантайме** либо приехавший параметром.

terminal_refusal_wrapping.go — разбор для двух гейтов приёмки kacho#2439: репозиторий операций попадает в use-case только ОБЁРНУТЫМ, и тексты отказа объявлены в одном месте.

Приёмка: `docs/engineering/acceptance/refusal-text-names-the-lane-that-can-retry.md`, сценарии KN-RTX-06 и KN-RTX-08.

Что предикат устанавливает, а что НЕТ — сказано здесь, а не в заголовке ¶

Он устанавливает ОДНО: всякий сырой конструктор репозитория операций в прод-коде обёрнут надстройкой прямо на месте вызова. Всеобщности вида «всякий терминальный исход проходит надстройку» он НЕ устанавливает и не обязан: четвёртый писатель терминального исхода — реконсайлер осиротевших операций — идёт мимо контракта репозитория и вынесен исключением приёмки (§2.3).

Различие несущее. Две первые редакции приёмки были отвергнуты ровно за заголовок шире предиката: читатель пишет гейт по заголовку, а не по телу.

Почему разбор синтаксический, а не по подстроке ¶

Имя конструктора встречается в комментариях — в этом дереве четыре вхождения, из которых настоящий вызов ОДИН. Проверка по подстроке краснела бы на собственном объяснении соседнего файла; разбор судит узел ВЫЗОВА.

token_claim_foreign_brand.go — разбор ИМЁН КЛЕЙМ выпущенного токена: не называет ли клеймо, которое читает предъявитель токена БЕЗ нашего исходного кода, чужой платформенный бренд (порт, СУЖЕННЫЙ ДО ОСИ А, с монорепо `internal/repohygiene/tokenclaimforeignbrand.go`, снят вынесением службы доступа — `kacho#2597`; задача продукта kacho#2127, семейство приёмки IAM-SEV-NAME-05).

Предмет ¶

Служба — самостоятельный продукт, ставящийся в чужом облаке. Норма разделения (решение владельца, kacho#2076): продукт наследует КОД, но не ИМЯ. Имя клейма читается оператором чужого облака без нашего исходного кода — достаточно раскодировать токен, — поэтому приставка имени клейма есть идентичность, а не код. Свой словарь — `kaname_`; чужой, платформенный — `kacho_`. `internal/domain/principal_claims.go` уже несёт три клейма формы `kaname_*` — предмет живой, не гипотетический.

Что здесь ПОРТИРОВАНО (ось А), а что НЕТ (ось Б) — сказано прямо ¶

Монорепошный предок судил ДВЕ оси: А — имя клейма принадлежит своему словарю; Б — у имени из своего словаря нет двойника в чужом словаре НИГДЕ в отслеживаемом дереве, включая не-Go текст (посевные наборы, профиль развёртывания, собранные коллекции проб, клиентская страница). Здесь перенесена ТОЛЬКО ось А — разбор Go-кода по четырём позициям чеканки и чтения. Ось Б требует единого свода дерева kaname И его нынешних потребителей (документация арендатора, коллекции проб), который на дату переноса не собран в одном месте; расширение до неё — отдельная работа, не сделанная здесь умышленно, а не забытая молча.

Позиции, которые СУДЯТСЯ (перенесены дословно) ¶

claims := map[string]any{"kacho_user_id": …}     ← ключ состава
pt, _ := claims["kacho_principal_type"].(string) ← чтение по имени
case "kacho_mfa_at":                             ← разбор по имени
verifiedClaim(vt, "kacho_principal_type")        ← имя передано вызовом

Чего разбор НЕ видит — названо, а не спрятано ¶

1. имя клейма, собранное из частей либо взятое переменной;
2. приставка, отданная предикату (`strings.HasPrefix(k, "kacho_")`) — ось Б предка ловила и её; здесь эта форма вне наблюдения;
3. не-Go текст.

token_claim_retired_provider.go — ГЕЙТ КЛАССА: имя утверждения в составе выданного токена не называет прежнего поставщика (kaname#375).

Предмет ¶

Состав утверждений нашего подписанта нёс утверждение, названное по поставщику, на КАЖДОЙ полосе выдачи, в том числе на посадке без поставщика. Имя утверждения — часть контракта токена: читатель, увидевший его, строит на нём решение о том, кто выдал токен. Экземпляр снят; этот гейт держит класс — всякое место сборки состава в дереве, чей ключ называет поставщика, находка.

Что судится ¶

Места сборки находит тот же разбор, что держит единственность состава (`ScanClaimAssemblies`): составной литерал `map[string]…` с ключами префикса утверждений. Судится КЛЮЧ, а не значение и не проза: значение выводится из настройки во время исполнения и дереву не видно — его держат пробы полос (`TestNoIssuanceLaneNamesTheRetiredProvider`). Имя поставщика берётся из одного источника с гейтом прозы (`RetiredIssuerName`).

Чего гейт НЕ видит — названо, а не спрятано ¶

Те же слепые зоны, что у разбора сборок: ключ, присвоенный по одному (`claims["…"] = v`), ключ, собранный из частей или взятый переменной, ключ без префикса утверждений.

token_claim_single_source.go — разбор мест, СОБИРАЮЩИХ состав утверждений выданного токена (порт с монорепо `internal/repohygiene/tokenclaimsinglesource.go`, снят вынесением службы доступа — `kacho#2597`; приёмка F2, сценарий F2-42, §2.11).

Предмет ¶

Токен принципалу выдают ДВА пути: обратный вызов прежнего провайдера, пока он жив, и собственный эндпоинт (`internal/service/token_enrichment_own_lane.go`). Пока перечень утверждений и правила их вычисления живут у каждого свои, различие между ними НЕ ЯВЛЯЕТСЯ НИЧЬЕЙ НАХОДКОЙ: оно не выражено и потому не может покраснеть. Первая же правка одной стороны разойдётся с другой молча — у ПРИНЦИПАЛА, чей токен выдан не тем путём.

Что здесь считается СБОРКОЙ, а что ПОТРЕБЛЕНИЕМ ¶

claims := map[string]any{"kaname_user_id": …, "kaname_account_id": …}  ← СБОРКА
return s.userTokenClaims(row, user, subject, hookCtx)                ← потребление

Потребителей должно быть МНОГО — они и есть цель: второй способ дойти до той же сборки, а не второй состав. Находкой является ВТОРАЯ СБОРКА.

Почему судится ИМЯ КЛЮЧА, а не тип отображения ¶

Предмет — СЛОВАРЬ утверждений, поэтому место опознаётся по именам ключей, а тип значений в счёт не идёт.

Почему порог по числу ключей, а не «хоть один» ¶

Префикс утверждений встречается и вне состава — им же названы метрики и поля контекста. Место, назвавшее один ключ, состава не объявляет.

Что изменилось при переносе, а что осталось дословно ¶

Изменилось: пакет (`repohygiene` → `check`), путь-константа владельца (без префикса `services/iam/`). Осталось дословно: обе функции разбора, форма узла (составной литерал `map[string]…`, узел вызова), имя держателя `TestTokenClaimsAreAssembledInOnePlace`.

Чего разбор НЕ видит — названо, а не спрятано ¶

1. состав, собранный присваиваниями по одному ключу за раз;
2. имя ключа, собранное из частей или взятое переменной;
3. состав, объявленный в чужом языке.

token_family_sole_writer.go — разбор «кто заводит семейство выданного» (задача PRO-Robotech/kaname#313).

───────────────────────────────────────────────────────────────────────────── ПРЕДМЕТ И ПОЧЕМУ ОН ГЕЙТ, А НЕ ВНИМАНИЕ

Семейство нельзя заводить в сессию, которой больше нет. Держится это НЕ ключом: истечение сессии ключом невыразимо в принципе — производная колонка от `now()` движком отвергается, а обёрнутая замерзает на вставке и говорит «жива» об истёкшей строке. Поэтому условие живости стоит В САМОМ ОПЕРАТОРЕ вставки, вместе с записью.

Цена такой границы названа честно: непредставимость держится ЭТИМ писателем, а не построением. Второй писатель — любая другая вставка в `kaname.token_families` — обойдёт условие молча: он скомпилируется, он пройдёт все пробы церемонии, и он заведёт живое семейство в снятой сессии.

Границе, которая держится писателем, нужен ПРЕДИКАТ, а не внимание. Вот он.

───────────────────────────────────────────────────────────────────────────── СУДИТСЯ СТРОКОВЫЙ ЛИТЕРАЛ В РАЗОБРАННОМ ДЕРЕВЕ, А НЕ ТЕКСТ ФАЙЛА

Разбор идёт по узлам: каждый непроверочный `.go` разбирается, и осматриваются только строковые литералы. Поиск по тексту файла считал бы находкой упоминание в комментарии — в том числе в этом.

Классификация литерала, несущего вставку в таблицу семейств:

несёт условие живости сессии (`ended_at IS NULL` и `expires_at >`)  — ОХРАНЯЕМЫЙ
не несёт                                                            — НАХОДКА

───────────────────────────────────────────────────────────────────────────── ПУСТОЙ ОБХОД — ОТДЕЛЬНЫЙ ИСХОД

Ноль охраняемых писателей означает не «чисто», а «гейт потерял предмет»: константу переименовали, оператор собрали из кусков, таблицу переназвали. Такой обход обязан быть КРАСНЫМ, иначе гейт зеленеет ровно тогда, когда перестаёт смотреть.

───────────────────────────────────────────────────────────────────────────── ГРАНИЦА НАЗВАНА

Оператор, собранный конкатенацией или `fmt.Sprintf` из частей, разбор по литералу не видит — это довод держать оператор ОДНОЙ константой, каким он и написан. Вставка, пришедшая из внешнего файла или сгенерированная, тоже невидима; в дереве таких путей к этой таблице нет.

withdrawal_producer_arrives_with_the_applier.go — разбор прод-дерева на СОГЛАСИЕ двух фактов: применитель ролей модуля приводится в действие, и производитель отзыва роли существует (порт с монорепо `internal/repohygiene/withdrawalproducerarriveswiththeapplier.go`, снят вынесением службы доступа — `kacho#2597`; задача продукта kacho#1913).

Предмет ¶

Сверка `moduleroles.Reconcile` объявляет вид расхождения `LiveNotDeclared` — «строка живёт, объявления у неё больше нет». Пока применитель НЕ приводится в действие в проде, отсутствие производителя снятия — остаток, а не дефект. Как только применитель начинают звать (`cmd/kaname/serve.go`, `moduleroles.NewApplier`, задача kacho#1034/#2010 — В KANAME ЭТО УЖЕ ПРОИЗОШЛО), остаток становится дефектом, необратимым ДЛЯ АРЕНДАТОРА: роль, которую нельзя снять, живёт вечно, и право, выданное через неё, продолжает действовать после того, как модуль перестал её объявлять.

Что здесь считается находкой — ОДНО согласие, а не два запрета ¶

Находка — состояние «применитель приводится в действие, производителя отзыва нет». Ни одна половина по отдельности находкой не является:

приводится в действие · производитель есть  → норма, работа сделана
приводится в действие · производителя нет   → НАХОДКА
не приводится        · производителя нет    → остаток
не приводится        · производитель есть   → норма, производитель приехал раньше

Обе половины судятся по УЗЛУ РАЗБОРА, а не по слову ¶

«Применитель приводится в действие» — это ВЫЗОВ через импортированный пакет, а не упоминание его имени. «Производитель отзыва» — это оператор ЗАПИСИ над `roles`, ставящий пометку снятия В СПИСКЕ ПРИСВОЕНИЙ.

Что изменилось при переносе, а что осталось дословно ¶

Изменилось: пакет (`repohygiene` → `check`), путь импорта применителя (без `services/iam/` — код лежит от корня модуля kaname: путь становится `github.com/PRO-Robotech/kaname/internal/apps/kaname/moduleroles`). Осталось дословно: обе регулярки, форма связывания импорта (по псевдониму, а не по последнему сегменту пути), различение узла разбора и узла-прозы, имя держателя `TestWithdrawalProducerArrivesWithTheApplier`.

Чего разбор НЕ видит — названо, а не спрятано ¶

1. миграцию как производителя (запрещена отдельным гейтом её же смысла);
2. производителя вне дерева модуля;
3. запрос, собранный из кусков в рантайме.