tasks: закрыты три задачи о проверках над проверками

- Отменены migrations-step-norm-and-tests, gate-steps-subject-guard и review-config-from-go-upgrade: много механики, мало пользы. - go-linters.md больше не числит отсутствие проверок шага migrations долгом — это решение, а не незакрытая работа.
2026-08-13 16:31:39 +03:00
parent 3ffb5109a7
commit 6994feec55
6 changed files with 7 additions and 135 deletions
@@ -43,8 +43,10 @@ Go-проект как есть. Своё здесь — перечень пра
  проверяются построчно (`scripts/check_go_version_test.go`). Второй самодельный
  шаг — `migrations` — нормы не имеет: он проверен мутацией на трёх исходах
  (переписанный шаг, пустой каталог, чистое дерево), но регрессионных проверок у
-  него нет, и дрейф его собственного шаблона имени никто не поймает. Это
+  него нет, и дрейф его собственного шаблона имени никто не поймает. Владелец
-  объявленный долг, а не умолчание.
+  решил 2026-08-13 оставить это как есть: проверка над проверкой даёт много
  механики и мало пользы. Долгом это больше не числится — задача
  `migrations-step-norm-and-tests` закрыта без реализации.
 ## Лестница механизации
@@ -43,9 +43,6 @@
 ## Очередь
 - [🧹 Проверить шаг гейта migrations так же, как шаг сверки версий Go](items/migrations-step-norm-and-tests.md) — Шаг охраняет critical-инвариант «применённый шаг схемы не переписывается», но своих проверок не имеет: дрейф шаблона имени, переезд каталога или потеря grep в конвейере оставят его вечно зелёным, и это не заметит ничто.
 - [🔬 Шаги гейта, у которых правило может потерять предмет](items/gate-steps-subject-guard.md) — У шага migrations страж предмета есть, у шагов docs, tasks и openspec неизвестно: они зовут чужие скрипты из плагинов, и правило, потерявшее файлы, зеленело бы молча.
 - [🧹 Настроить конвейер ревью по итогам прогона go-1-26-upgrade](items/review-config-from-go-upgrade.md) — Прогон вскрыл две прорехи настройки: «Типовые узлы» знают только рантайм и не знают рода «проверочный шаг набора проверок», а «Триггеры метки» не видят оси «изменение трогает канон» — и именно она дала обе блокирующие находки.
 - [🧹 Поднимать сервис локально без действующего токена бота](items/local-run-without-telegram-token.md) — Адаптер Telegram проверяет токен обращением к Telegram и роняет старт, а боевым токеном запускаться запрещено: проверить поведение живым прогоном не может ни одна задача.
 - [🐞 Убрать код провайдера из журнала запросов хранилища](items/provider-code-out-of-storage-log.md) — Строка запроса с кодом входа целиком уезжает в таблицу _logs и лежит там пять суток, хотя спека access требует, чтобы код в журнал не попадал.
 - [🐞 Вести учёт употреблённых состояний входа на сервере](items/server-side-login-state.md) — Одноразовость возврата держится на уборке куки, то есть на браузере: сервер не помнит, какие состояния уже потрачены.
@@ -18,3 +18,6 @@
 - 2026-08-13 `user-settings` — 🎯 Пользователь настраивает, что сервис делает с его записями. Причина: Зонтик над разобранной работой: дом настроек заводит settings-screen, читает их в конвейере settings-applied-in-pipeline. Тип goal упразднён раскладкой av-dev 3. Была секция: Запланировано.
 - 2026-08-13 `web-access` — 🎯 Записи загружаются и читаются в приложении, которое ставится на телефон. Причина: Зонтик над разобранной работой: каркас даёт spa-skeleton, контракт json-api-for-spa, экраны upload-and-status-screen, records-list-screen, play-recording-in-app, установку на телефон installable-pwa. Тип goal упразднён раскладкой av-dev 3. Была секция: Запланировано.
 - 2026-08-13 `gate-changed-lines-coverage` — 🧹 Ронять гейт на изменённой функции, которую не выполняет ни один тест. Причина: Владелец отменил 2026-08-13: механизировать покрытие изменённых функций не нужно. Прототип шага гейта откачен, в дерево ничего не уехало. Была секция: Очередь.
 - 2026-08-13 `migrations-step-norm-and-tests` — 🧹 Проверить шаг гейта migrations так же, как шаг сверки версий Go. Причина: Владелец отменил 2026-08-13: проверка над проверкой даёт много механики и мало пользы. Сам шаг migrations остаётся и работает — без проверок остаётся только он. Была секция: Очередь.
 - 2026-08-13 `gate-steps-subject-guard` — 🔬 Шаги гейта, у которых правило может потерять предмет. Причина: Владелец отменил 2026-08-13: разведка того же класса — проверка над проверками. Ведут ли себя шаги docs, tasks и openspec зелёными без предмета, остаётся неизвестным. Была секция: Очередь.
 - 2026-08-13 `review-config-from-go-upgrade` — 🧹 Настроить конвейер ревью по итогам прогона go-1-26-upgrade. Причина: Владелец отменил 2026-08-13: настройка конвейера ревью даёт много механики и мало пользы. Разделы «Типовые узлы» и «Триггеры метки» в docs/review.md остаются как есть. Была секция: Очередь.
@@ -1,34 +0,0 @@
 # 🔬 Шаги гейта, у которых правило может потерять предмет
 - **Тип:** research
 - **Категория:** Очередь — Разведка того же класса: правило, потерявшее предмет. Её исход правит соседние шаги гейта, поэтому идёт до работы над ними.
 - **Зачем:** У шага migrations страж предмета есть, у шагов docs, tasks и openspec неизвестно: они зовут чужие скрипты из плагинов, и правило, потерявшее файлы, зеленело бы молча.
 Класс известен и записан: правило, чей предмет исчез, обходит пустой перечень
 ноль раз и проходит зелёным. В `internal/archrules` от этого стоит
 `TestПакетыПравилСуществуют` — он падает, когда пакет из правила переименован. У
 шага `migrations` страж завёлся 2026-08-13: пустой каталог шагов роняет шаг с
 кодом 3.
 Чего не знаем: ведут ли себя так же `docs.py check`, `tasks.py check` и
 `openspec.py check`. Скрипты чужие — они живут в плагине `av-dev`, и править их
 в этом репозитории нельзя. Отсюда и тип записи: способ починки зависит от
 ответа. Найдётся страж внутри — делать
 нечего; не найдётся — либо обёртка в `Taskfile.yml` со своей проверкой предмета,
 либо разговор с владельцем плагина.
 ## Вопрос
 Какие шаги гейта проходят зелёными, когда предмет их правила исчез, — и чем это
 чинится, если сам скрипт править нельзя?
 ## Куда ляжет ответ
 `docs/research/gate-steps-subject-guard.md` — записка с перечнем шагов, снятыми
 исходами (по каждому: что сделали с предметом, каким кодом ответил шаг) и
 рекомендацией. Исход разведки — задачи на те шаги, где страж нужен и возможен.
 ## Рамки
 Скрипты плагинов не правим: они не в этом репозитории. Прогоны идут на временном
 клоне репозитория, каталоги `docs/` и `tasks/` рабочего дерева не трогаем.
@@ -1,48 +0,0 @@
 # 🧹 Проверить шаг гейта migrations так же, как шаг сверки версий Go
 - **Тип:** chore
 - **Категория:** Очередь — Страж шага гейта — тот же слой оснований, что и покрытие изменённых строк: проверкам, которым верят ниже по списку, верить можно только после этого.
 - **Зачем:** Шаг охраняет critical-инвариант «применённый шаг схемы не переписывается», но своих проверок не имеет: дрейф шаблона имени, переезд каталога или потеря grep в конвейере оставят его вечно зелёным, и это не заметит ничто.
 Шаг заведён 2026-08-13 и проверен мутацией на восьми исходах вручную — правка
 уехавшего шага в дереве и в коммите, удаление, переименование, новый шаг, правка
 `migrations.go`, отсутствующий ключ в `.av-dev.toml`, каталог без шагов,
 неразрешимая база диффа. Прогон был разовым: в дереве от него не осталось ничего.
 Прецедент рядом. У шага сверки версий Go есть спека
 [toolchain](../../openspec/specs/toolchain/spec.md) и 20 мутационно проверенных
 сценариев в `scripts/check_go_version_test.go`; заведены они после дефекта
 2026-08-12, когда зелёный шаг не проверял ничего и образ перестал собираться.
 Долг назван строкой в
 [go-linters.md](../../docs/conventions/go-linters.md), «Границы: где что живёт».
 **Развилка, решаемая внутри задачи:** нормировать шаг спекой (второй capability
 о проверке, как `toolchain`) либо ограничиться проверками без нормы. Первое
 дороже и даёт построчную сверку сценариев; второе закрывает регрессию, но
 оставляет норму в комментарии `Taskfile.yml`.
 ## Затрагивает
 - шаг `migrations` в `Taskfile.yml` — его логика разбора `git diff`;
 - ключ `migrations` секции `[docs]` в `.av-dev.toml` — из него шаг берёт каталог;
 - каталог шагов схемы `internal/adapter/repo/pocketbase/migrations/` как предмет
  правила;
 - возможно — новая capability в `openspec/specs/` и файл проверок рядом с
  `scripts/check_go_version_test.go`.
 ## Критерии приёмки
 - Переписанный уехавший шаг схемы роняет проверку. Оракул — прогон сценария на
  временном клоне репозитория: правка файла шага даёт код 1 и называет файл.
 - Новый файл шага проверку не роняет, и правка `migrations.go` тоже: строка
  `Register` нового шага прибавляется именно там. Оракул — те же два сценария.
 - Каталог без единого файла шага и отсутствующий ключ в `.av-dev.toml` дают
  код 3, а не тихий ноль. Оракул — два сценария на временном каталоге.
 - Проверка сценариев идёт в гейте, а не руками. Оракул — `task gate` красный при
  внесённом нарушении шаблона имени файла шага.
 ## Рамки
 Боевой каталог данных и файлы шагов схемы не трогаем: сценарии гоняются на
 временном клоне репозитория. Чужие скрипты проверок (`docs.py`, `tasks.py`,
 `openspec.py`) — не наши, они в задаче `gate-steps-subject-guard`.
@@ -1,48 +0,0 @@
 # 🧹 Настроить конвейер ревью по итогам прогона go-1-26-upgrade
 - **Тип:** chore
 - **Категория:** Очередь — Настраивает конвейер ревью, которым проверяется всё, что ниже: настройка после половины списка проверила бы вторую половину иначе, чем первую.
 - **Зачем:** Прогон вскрыл две прорехи настройки: «Типовые узлы» знают только рантайм и не знают рода «проверочный шаг набора проверок», а «Триггеры метки» не видят оси «изменение трогает канон» — и именно она дала обе блокирующие находки.
 Обе прорехи одного рода — настройка конвейера, живущая в `docs/review.md`, — и
 правятся одним заходом.
 **Род узла.** Сегодня перечень покрывает шаг конвейера, транспорт, клиент
 внешнего сервиса, репозиторий и обёртку над внешним процессом. Скриптов гейта в
 проекте четыре, и свойства у них свои: отличает ли шаг расхождение от сломанного
 окружения, есть ли исход функция коммита, а не машины, покрыт ли шаг мутационным
 прогоном. Без этого рода находка «шаг набора проверок не проверен ничем»
 добывается заново каждый раз.
 **Ось метки.** Два прохода независимо сказали, что метка `medium` занижена:
 изменение заводило новую capability и новый каталог верхнего уровня. Триаж
 проверил и подтвердил — по записанному правилу разметка была верна, потому что
 такой оси в правиле нет вовсе, а обе блокирующие находки прогона пришли именно
 по ней.
 Провенанс обоих — отчёт
 `openspec/changes/archive/2026-08-12-go-1-26-upgrade/review/report.md`,
 кандидаты в правило P-2 и P-5.
 ## Затрагивает
 - раздел «Типовые узлы» в `docs/review.md`;
 - раздел «Триггеры метки» в `docs/review.md`.
 ## Критерии приёмки
 - Проверочный шаг набора проверок описан родом со своими свойствами. Оракул —
  открыть «Типовые узлы» и найти род; свойств не меньше трёх, и каждое
  сформулировано проверяемо.
 - Правило выбора метки видит заведение новой capability и нового каталога
  верхнего уровня. Оракул — приложить правило к прогону `go-1-26-upgrade` задним
  числом: метка выходит выше `medium`.
 - Гейт зелёный целиком. Оракул — `task gate`.
 ## Рамки
 Правится только настройка конвейера в `docs/review.md`. Устав самого конвейера
 живёт в скилле `av-dev:code-review` и этой задачей не трогается: проект вправе
 настраивать свои темы и триггеры, но не переписывать чужой скилл.
 Журнал дефектов в том же файле не трогается — записи неизменяемы.