Land the pack follow-up and correct myself twice: the cgroup mechanism I put in the canon was a known default already documented in the runner, and the statement count came from a grep instead of the gate

docs/architecture/05-decisions-log.md

@@ -20,7 +20,21 @@
 > ⚠ **Эррата 27.08-з (D39.156, состав пункта 2в): «воркер решений → глагол перед возобновлением» СНЯТ — посылка изменилась.** Пункт писался, когда двери в контракте не было и подразумевалось НАКОПЛЕНИЕ: платформа копит решения у себя и скармливает их движку перед `resume`. С дверью канона 0.5.0 накопления не существует — правка ПРИМЕНЯЕТСЯ в момент подачи, и гарантия «до возобновления» у синхронной формы СИЛЬНЕЕ воркерной: применено прежде, чем клиент получил `200`. Проверено исполнением с обеих сторон: движок на стопе ВЫХОДИТ (`cmd/tmctl/main.go:95`, код 3), флок не-блокирующий и отпускается ядром на выходе процесса (`store/store.go:187`), между стопом и возобновлением живого процесса на проекте нет — запинено `pipeline/bankchain_test.go:62-64`; кап 5000 решений выведен ИМЕННО из синхронности («the call stops fitting the caller's timeout»). Остаётся не воркер, а пер-книжная сериализация в обработчике. `Resume` «с решениями как они есть» не тронут.
 > ⚠ **Эррата 28.08-и (D39.165 §3, размер мины) — ошибка ОРКЕСТРАТОРА, найденная опровергателем промта P10.** Нота утверждает: «первый же ПРОДОЛЖАЮЩИЙ прогон после первой же правки банка УПАДЁТ». **Переоценено.** Гард снапшота стреляет по СУЩЕСТВУЮЩЕМУ джобу (`backend/internal/pipeline/stagerun.go:47` — `EnsureJob` создаёт джоб стадии в момент, когда стадия впервые исполняется), а правка в ГЛАВНОМ окне — стоп подписи `awaiting_bank` — двигает edit-снапшот, когда edit-джобов ЕЩЁ НЕТ: возобновление создаёт их свежими, и гард молчит. Драфт-волна mined-строк не видит вовсе (`seeding.go:143-153`). **Дефект СТОИТ, но его триггер уже: правка, сделанная ПОСЛЕ появления edit-джобов** — пауза потолком посреди редактуры и ДОЧИТАННАЯ книга. ⚠ Срочность при этом НЕ падает: флагманский случай продукта («поправил имя героя в дочитанной книге») — ровно тот, где edit-джобы существуют, то есть мина бьёт именно по нему. **Цена ошибки была бы прямой:** репро на потоке `awaiting_bank` показало бы ЗЕЛЕНЬ без фикса, и пак мог быть отозван как мнимый. Промт P10 §4.2 исправлен: репро обязано фиксировать состояние «edit-джоб существует ДО правки».
 > ⚠ **Эррата 28.08-к (D39.165 §3 + решение оркестратора о глава-полосе) — ДВЕ ошибки, обе найдены широким самопроходом платформенной сессии, обе доказаны исполнением.** **(1) Посылка «смета УЖЕ публикуется в `status --json`» верна только ПОСЛЕ свёртки.** `bank-apply` пишет только ФАЙЛЫ решений, а `status` считает ре-билл от СОХРАНЁННОГО глоссария (`backend/internal/pipeline/status.go:733-744`, `projectStoredMemory` — его собственный комментарий: «A seed-FILE edit not yet re-run is NOT reflected here… that drift surfaces on the next translate's re-seed»). Свёртка происходит внутри СЛЕДУЮЩЕГО `translate`, поэтому сразу после правки движок отвечает `units=0`/`drift=false`. Следствие: продажа «затронуто N юнитов» и холд от сметы В ТЕКУЩЕМ ШВЕ НЕДОСТИЖИМЫ — для них нужен движковый глагол «свернуть банк и оценить ВНЕ translate», которого нет. **(2) Решение оркестратора «полоса пере-прохода — в ГЛАВАХ» ОТМЕНЯЕТСЯ: его посылка опровергнута.** Я рассудил, что $0-репин двигает полосу, потому что идёт через тот же `resumeFromChunkStatus`, — и не проверил анонс. Движок анонсирует юнит ОДИН РАЗ на жизнь книги (announce-once, `backend/internal/pipeline/events.go:49,143-162`), пере-проход не ре-анонсирует ни репины, ни пере-переводы ⇒ `done` остался бы НУЛЁМ навсегда. Это ровно тот класс, от которого предостерегает памятка «не выводить из соседнего механизма, не проверив свой». ⚠ **Что при этом НЕ отменяется:** запрет класть ЮНИТЫ в поле, объявленное в главах, стоит — но объявленная в каноне «одна единица работы» запретом не является, потому что она НЕ молчаливая.
-> ⚠ **Эррата 29.08-а (D39.172, две строки, объявленные заведёнными) — ошибка ОРКЕСТРАТОРА №19.** Тело ноты дважды утверждает «Заведено строкой» / «строка заведена» — про `Touch`, выбрасывающий `RowsAffected`, и про пересборку `tmctl` в рецепте стенда. **На момент ратификации ни одной из этих строк не существовало:** последняя строка регистра платформы была `PD-430`, и проверка грепом по `Touch|RowsAffected|пересбор` давала только совпадения слов в чужих строках. Утверждение о будущем записано как о свершившемся — ровно тот класс, который эта же смена ловила у сессий трижды. Строки заказаны зоне отдельным пингом; эррата снимается их появлением, тело ноты не переписывается (D23.3). ⚠ Сюда же третий пункт того же абзаца: `PD-423` предписано ПЕРЕ-ПРОВЕРИТЬ (у сессии `sqlc` тест зелёный в трёх прогонах), и пометки в строке регистра тоже нет.
+> ⚠ **Эррата 29.08-а (D39.172, две строки, объявленные заведёнными) — ошибка ОРКЕСТРАТОРА №19.** Тело ноты дважды утверждает «Заведено строкой» / «строка заведена» — про `Touch`, выбрасывающий `RowsAffected`, и про пересборку `tmctl` в рецепте стенда. **На момент ратификации ни одной из этих строк не существовало:** последняя строка регистра платформы была `PD-430`, и проверка грепом по `Touch|RowsAffected|пересбор` давала только совпадения слов в чужих строках. Утверждение о будущем записано как о свершившемся — ровно тот класс, который эта же смена ловила у сессий трижды. **СНЯТА 29.08: строки заведены зоной — `PD-431` (`Touch`) и `PD-432` (пересборка `tmctl`), `PD-423` получил вторую точку. Проверено грепом по регистру.** Тело ноты не переписывается (D23.3). ⚠ Сюда же третий пункт того же абзаца: `PD-423` предписано ПЕРЕ-ПРОВЕРИТЬ (у сессии `sqlc` тест зелёный в трёх прогонах), и пометки в строке регистра тоже нет.
+> ⚠ **Эррата 29.08-б (D39.171 механизм cgroup + D39.172 число операторов) — ДВЕ ошибки ОРКЕСТРАТОРА №19.**
+> (а) **Механизм, который я объявил причиной неприменения `MemoryMax`, НЕВЕРЕН.** Я вывел «вызывающий
+> процесс обязан жить внутри `user@<uid>.service`» из пробы `systemd-run --user --scope` без
+> `--property=Slice=`. Пере-проверено: такой scope попадает в `app.slice` ВНУТРИ пользовательского
+> менеджера даже при оболочке в `/init.scope`, то есть cgroup вызывающего процесса условие НЕ
+> предсказывает, а команда-проверка из строки даёт ложный отрицательный. ⚠ **Настоящая причина была
+> УЖЕ ЗАПИСАНА в коде зоны, и я её не прочитал:** `platform/internal/runner/runner.go:47-53` —
+> «a --user unit left in the default app.slice gets NO cgroup control files at all … MemoryMax= …
+> enforce nothing (a process that faulted in 400 MiB survived MemoryMax=64M)». Ради этого раннер и
+> кладёт юниты в СВОЙ слайс. Моя проба воспроизводила известный дефолт, а не свойство хоста.
+> Формулировку в рецепте `STACK_DECISIONS` в нынешнем виде вносить НЕЛЬЗЯ. Поймала сессия `sqlc`.
+> (б) **Число операторов после конверсии — 172, а не 167.** Гейт печатает его сам
+> (`sqlgate_test.go`, `172 statements`); моё 167 получено грепом и унаследовано в тело ноты. Пол 140
+> далёк в обоих случаях, вывод приёмки не меняется, но в каноне стоит число из гейта, а не из грепа.
 
 > ⚠ **Навигация (актуализация 07.08, эра D39.1xx):** append-only-дисциплина (D23.3) означает, что
 > НЕВЕРНЫЙ ФАКТ внутри старой ноты не переписывается, а получает эрратау — и тогда он опасен ровно

platform/docs/platform-PROGRESS.md

@@ -128,6 +128,56 @@ M2, M3, M6 и арность M4. **Параметрическую половин
 единственное честное доказательство, что пак купил то, ради чего затевался; плюс собственные новые
 посадки на генерённый слой (снятый override, подменённая цель `Scan`, сломанная арность).
 
+### ДОФИКС после лендинга `63fcee5`: три строки регистра + §3.8-свип (сессия `textmachine-1b`, 29.08)
+
+Оркестратор №19 обнаружил, что в теле ноты дважды написал «заведено строкой» про строки, которых не
+существовало, и попросил завести их. Заведено, и заодно исполнен пункт `ENGINEERING_STANDARDS` §3.8,
+который в самом паке я прошла формально: **греп ОТКРЫТЫХ строк по своим файлам с диспозицией каждой.**
+Он дал больше, чем заказ.
+
+**Заведено:**
+- **`PD-431`** — `Touch` выбрасывает `RowsAffected`; апдейт, не тронувший ни строки, неотличим от
+  успеха, батарея зелёная. В теле прямо сказано, что **паком не чинится СОЗНАТЕЛЬНО**: проверка тега —
+  изменение поведения, а не конверсия.
+- **`PD-432`** — рецепт стенда не говорит о пересборке `tmctl`; устаревший бинарь даёт красную батарею
+  с сообщением про `models.yaml`, которое читается как дефект платформы.
+- **`PD-423`** — не новая строка, а **вторая точка с числами** (по образцу `PD-420`), см. ниже.
+
+**§3.8-свип: 13 открытых строк касаются моих файлов. Четыре получили содержательную диспозицию, и две
+из них закрыты — обе пере-проверены ПОСАДКОЙ, а не сходством формулировок:**
+
+| Строка | Диспозиция | Доказано |
+|---|---|---|
+| **`PD-380`** | **ЗАКРЫТА** | её собственная мутация M12 (`now.Add(maxAge)` → `now.Add(100*maxAge)`) теперь КРАСНАЯ адресно на `TestTheTwoSessionDeadlinesAreNotInterchangeable`. Пак строку не искал: тест писался против перестановки сроков, потолок оказался запинен тем же утверждением |
+| **`PD-44`** | **ЗАКРЫТА** | инструмент взят и заленджен; заодно исправлены устаревшие числа в теле (41 → 42 места / 41 текст / 40 конвертируемых) |
+| **`PD-383`** | **СУЖЕНА, остаётся `open`** | M16 (`and 1=0`) теперь красная — свип-предикат запинен; **M15 (срок 180 суток → 180 ЛЕТ) пере-прогнана на полной батарее: EXIT=0, ноль красных** — срок и `sweepLogins` живут в пакете `main`, куда тест `pgstore` не достаёт |
+| **`PD-86`** | указатель пере-нацелен | оба клауза уехали в `queries/sessions.sql`; **прежний указатель `counts.py --lint` НЕ ловил** — у него нет `=токена`, поэтому он молча показывал на строки, где клауз давно нет. Сам дефект цел и открыт |
+
+Прочие девять (`PD-425`, `PD-377`, `PD-369`, `PD-395`, `PD-374`, `PD-23`, `PD-98`, `PD-170`, `PD-421`)
+конверсией не затронуты: их предмет — поведение, которого пак не менял.
+
+### `PD-423`: вторая точка ПРОТИВОРЕЧИТ первой, и я правлю СЕБЯ вместе со строкой
+
+Замер по протоколу приёмки (изоляция, пять раз): **5 из 5 ЗЕЛЕНО** при `cut -d: -f3 /proc/self/cgroup`
+= `/init.scope` — то есть при том же значении, при котором приёмка №19 видела 5 из 5 красных. Скипов в
+этих прогонах ноль (сверено по логам), и тест НЕ пустой: он требует настоящего `oom-kill` после касания
+400 МиБ под `MemoryMax=64M`. Прямая проба механизма: `systemd-run --user --scope -p MemoryMax=64M`
+кладёт процесс в `…/user@1000.service/app.slice/run-….scope`, то есть ВНУТРЬ, а не оставляет в исходном
+cgroup. Сам `tm-runs.slice` лежит глубже, чем его ищут: `user@1000.service/`**`tm.slice`**`/tm-runs.slice`.
+
+**Следствие:** предложенная той же строкой команда-проверка даёт ЛОЖНЫЙ ОТРИЦАТЕЛЬНЫЙ, и вносить её в
+рецепт `STACK_DECISIONS` в нынешнем виде нельзя. **И я правлю себя:** в отчёте пака я написала
+«четвёртое условие НЕ выполнено», прочитав это из ОДНОЙ команды, названной доком, вместо того чтобы
+спросить сам гейт. Та же ошибка «вывод из счёта, а не из предмета», которую этот пак ловил в §3.1 —
+только на этот раз моя.
+
+### ⚠ Число в ноте приёмки расходится с деревом
+
+Приёмка называет **167 операторов** после конверсии. На чистом залендженном дереве гейт печатает сам:
+**172** (`sqlgate_test.go:54`, `go test ./internal/pgstore/ -run TestEverySQLStatementParsesAgainstTheMigratedSchema -v`).
+Пол 140 далёк в обоих случаях, вывод приёмки не меняется — но число в ратифицированной ноте стоит
+поправить, а не унаследовать.
+
 ### Вопросы оркестратору (не блокируют работу)
 
 1. **Три живых оператора без единого исполнения — это находки регистра, независимо от sqlc.** Завожу
@@ -300,10 +350,15 @@ Override с явным именем алиаса тоже НЕ применяе
 (⚠ `tmctl` пришлось ПЕРЕСОБРАТЬ: бинарь стенда от 24.08 старше сегодняшнего `models.yaml`, и батарея
 краснела `field system_messages not found` — это выглядит как дефект кода, а не стенда; рецепт в
 `STACK_DECISIONS` про пересборку не говорит) · достижимый менеджер systemd (все тесты `runner`
-прогнались, скипов 0). **Четвёртое — процесс внутри `user@<uid>.service` — НЕ выполнено:**
-`cut -d: -f3 /proc/self/cgroup` даёт `/init.scope`. ⚠ Но `TestARunIsBoundedByItsOwnCgroup` при этом
-ЗЕЛЁНЫЙ (у меня и независимо у агента, три прогона) — то есть симптом `PD-423` на этом хосте не
-воспроизводится, и строку стоит пере-проверить.
+прогнались, скипов 0). ⚠ **Про четвёртое условие я сама сказала неточно, и правлю себя:** я написала «НЕ выполнено», прочитав
+это из команды-проверки `cut -d: -f3 /proc/self/cgroup` (даёт `/init.scope`). Пере-проверка после
+лендинга показала, что **проверка врёт, а условие выполнено**: тест зелен 5 из 5 в изоляции и трижды в
+полных батареях, скипов ноль (сверено по логам, тест не пустой — требует настоящего `oom-kill` под
+`MemoryMax=64M`), а прямая проба `systemd-run --user --scope` кладёт процесс
+в `user@1000.service/app.slice/run-….scope`, то есть ВНУТРЬ. Правильная формулировка: cgroup
+ВЫЗЫВАЮЩЕГО процесса это условие не предсказывает. Числа и проба — второй точкой в `PD-423`.
+**Урок мой:** я прочитала статус условия из ОДНОЙ команды, названной доком, вместо того чтобы спросить
+сам гейт, — та же ошибка «вывод из счёта, а не из предмета», которую этот же пак ловил в §3.1.
 
 ### Вопросы оркестратору