From 5357b00c683e2b6268f471072e5cb5808af20ff1 Mon Sep 17 00:00:00 2001 From: heaven Date: Fri, 11 Sep 2026 00:28:48 +0300 Subject: [PATCH] Withdraw the claim that a session misremembered a number: both counts were right and measured different things. --- docs/ORCHESTRATOR_SESSION_PROMPT.md | 11 +++++++++++ docs/architecture/05-decisions-log.md | 1 + 2 files changed, 12 insertions(+) diff --git a/docs/ORCHESTRATOR_SESSION_PROMPT.md b/docs/ORCHESTRATOR_SESSION_PROMPT.md index fad97914..8edce71f 100644 --- a/docs/ORCHESTRATOR_SESSION_PROMPT.md +++ b/docs/ORCHESTRATOR_SESSION_PROMPT.md @@ -240,6 +240,17 @@ D23.3). Владельцу на решение: деньги сверх мело от него. Настоящие развилки сессий эскалируй быстро и решай сам; сессии, приносящие развилки вместо тихих девиаций, — поощряй. +### У числа есть провенанс — спроси прибор, прежде чем звать чужое число ошибкой + +⛔ Расхождение двух чисел об одном предмете — это в первую очередь вопрос **«каким прибором снято каждое»**, +и только потом — чья память подвела. Замер 11.09: сессия ждала 118, я насчитал 126 и записал в акт «ошибка +в её памяти». Оба числа были верны — `wc -l` считает строки файла (126), `grep -vc '^#'` считает записи +каталога (118), между ними ровно 8 строк шапки-комментария. ⇒ вменил память там, где был другой счёт, и +поймала это она, уже после закрытия своей сессии. + +Это тот же класс, что «приписывание проверяется у источника», применённый к числам: **прежде чем назвать +чужое число неверным, воспроизведи его ЕГО командой, а не своей.** + ### Вынос блока в архив: якорь НИЖЕ разреза уезжает вместе с ним ⛔ Проверять надо не «есть ли якоря В ВЫРЕЗАЕМОМ диапазоне», а **«есть ли якоря с номером ≥ начала разреза»**: diff --git a/docs/architecture/05-decisions-log.md b/docs/architecture/05-decisions-log.md index 2d6d8681..dea43677 100644 --- a/docs/architecture/05-decisions-log.md +++ b/docs/architecture/05-decisions-log.md @@ -5,6 +5,7 @@ > ⚠ **Эррата 15.08 (D39.132):** D39.131 п.2(а) перечисляет полосу отказов «10 конфиг · 11 источник · 12 лок · 19 безымянный» — читать через D39.132 п.2(г): полоса ДОПОЛНЕНА **exit 13 = `schema_mismatch`** (~~обе зоны сошлись на числе независимо~~; ратифицирован направлением, ФИНАЛИЗИРОВАН приёмкой D39.134). > ⚠ **Эррата 15.08-б (D39.134 п.2а, вписана по аудиту корпуса):** клейм «зоны сошлись на 13 НЕЗАВИСИМО» (строкой выше и в D39.132 п.2г) СНЯТ — платформа прочитала число из незакоммиченного дерева движка и сама это записала (`platform/internal/ingest/exit.go:63-64`); на силу ратификации не влияет. > ⚠ **Эррата 15.08-в (D39.136 п.5):** форма контракт-ревью «фазный воркфлоу оркестратора» ОТМЕНЕНА словом владельца тем же днём — исполняет ОТДЕЛЬНАЯ СЕССИЯ со своим онбордингом (норма D39.120 п.2; оркестратор — автор части ратификаций 0.2.3, author≠reviewer); запущенная воркфлоу-фаза 1 остановлена, её результаты выброшены; промт — `docs/CONTRACT_REVIEW_SESSION_PROMPT.md`. +> ⚠ **Эррата 11.09-а (`D39.241` п.1) — Я ЗАПИСАЛ ЧУЖОЙ ОШИБКОЙ ТО, ЧТО ОШИБКОЙ НЕ БЫЛО.** Пункт 1 говорит: сессия ждала 118 строк каталога сообщений оператора, в файле 126, «ошибка была в её памяти о числе». **Расхождения НЕТ — это два разных счёта одного файла**, и оба верны. Пере-снято мной по её поправке: `wc -l` даёт **126** (строки файла), `grep -vc '^#'` даёт **118** (записи каталога), шапки-комментария ровно **8** строк, её двух сообщений в файле **0**. Её скрипт печатал записи, я считал строки. ⇒ вывод «откат точен» СТОИТ, а объяснение через «память» — снято. ⭐ Класс тот же, что смена разбирала полдня и записала нормой про приписывание: **у ЧИСЛА тоже есть провенанс**, и прежде чем назвать чужое число ошибкой, надо спросить, каким прибором оно снято. Я этого не спросил и вменил память там, где был другой счёт. Нашла и поправила она, уже после закрытия своей сессии, когда ей это ничего не давало. > ⚠ **Эррата 10.09-з (`D39.235` п.4) — В МОЕЙ НОТЕ ЛОЖЬ ПРО МЕХАНИЗМ УЩЕРБА, и назвал её тот же, кто её принёс.** Пункт 4 писал: блокирующий `Runner.Stop` означает, что «при `WriteTimeout: 30 s` пользователь НЕ получает `202`, который обещает контракт». **Неверно.** Пере-снято мной: тридцать секунд стоят у слушателя МЕТРИК (`platform/cmd/tmplatformd/main.go`, греп `WriteTimeout` — и комментарий там прямо говорит «for once a WriteTimeout too: nothing here streams»), а у API-слушателя `WriteTimeout` НЕТ НАМЕРЕННО (`platform/internal/httpapi/serve.go`, греп `No WriteTimeout`: срезал бы длинный SSE-поток). ⇒ ущерб не «оборванный ответ», а **зависший запрос и съеденный бюджет свипа**; вторую половину — про ложный клин реконсиляции — уже поправила платформенная сессия (`D39.236` п.5), а эта половина простояла в журнале ложью до 10.09. Лечение не меняется: `--no-block`. ⭐ Поправку принёс старший коллега, чья же буква и была неверной, — и принёс её тогда, когда пак уже отменён и исправление ему ничего не давало. Это второй случай за смену, когда замерявший назвал ошибку своего прибора сам. > ⚠⚠ **Эррата 10.09-ж (`D39.238` п.4) — МОЯ АЛЬТЕРНАТИВА БЫЛА НЕГОДНОЙ, и движковая зона объяснила почему; плюс объявлено ИЗВЕСТНОЕ СВОЙСТВО, которое не чинится.** **(а)** Я предложил определять жёсткость не СЧЁТОМ сигналов, а признаком «сигнал пришёл, когда прогон УЖЕ в мягкой остановке». Это не лечит замеренное: слипшийся бит в `sigqueue` неотличим от одного сигнала НИ счётом, НИ состоянием — разделить их может только ВРЕМЯ между ними, и «наблюдаемый вход в фазу остановки» есть ровно оно, снятое прибором. ⇒ контракт из п.3 не просто приемлем, он ЕДИНСТВЕННЫЙ возможный. **(б)** Зона всё равно перевела лестницу со счётчика на СОСТОЯНИЕ ПРОГОНА — по другому и лучшему доводу: авторитет у состояния прогона, а не у переменной в горутине обработчика, и если остановку когда-нибудь попросят не сигналом (ручкой API, вторым каналом платформы), лестница не станет врать. **(в) ⛔ ОБЪЯВЛЕНО ИЗВЕСТНЫМ СВОЙСТВОМ, ЧТОБЫ НИКТО НЕ СЧИТАЛ ЭТО БАГОМ: три нажатия в одном планировочном кванте дают МЕНЬШЕ эскалаций, чем нажатий, и это не чинится.** **(г) И следствие, которое усиливает платформенную половину сильнее, чем я сказал ей раньше:** после ВТОРОГО входа движок возвращает сигналам дефолтную диспозицию (`signal.Reset`), то есть остаётся БЕЗ ОБРАБОТЧИКА — значит повторный `systemctl kill` от свипа для него СМЕРТЕЛЕН, а не идемпотентен. ⇒ долговечная отметка «жёсткий сигнал уже послан» (`D39.238` п.3) — не гигиена, а единственное, что стоит между пере-выпуском свипа и смертью процесса без терминального кадра и без сеттла. > ⚠ **Эррата 10.09-е (`D39.235` п.1) — ДВА ПРАВИЛА ФОРМЫ КАДРА, КОТОРЫХ НОТА НЕ НАЗВАЛА, а без них две зоны решили бы по-разному.** **(а) `Money` на исходе `stopped` — «всегда» надо читать как «всегда, КОГДА СЧЁТЧИКИ ЕСТЬ».** `moneyLedger()` возвращает `nil` не только без потолка, но и когда волн ещё не было (`backend/internal/pipeline/events.go`, греп `moneyLedger`): остановка на ингесте или севе счётчиков не имеет, и это законная пустота, а не умолчание — иначе движок не смог бы исполнить ноту буквой. **(б) ПРАВИЛО ПРИСУТСТВИЯ `Stop` — «есть, если остановку ЗАПРОСИЛИ», а НЕ «если исход `stopped`».** Прецедент дословно у соседнего поля: `Money` present iff a ceiling was REACHED, not iff the outcome is ceiling. Важно ровно в одном случае, и он в паке назван: остановку запросили, а прогон уехал `failed` из-за упавшего соседа — поле обязано БЫТЬ. Оба правила внесены в оба промта до выдачи. ⭐ Нашёл не я: нота прошла ревью старшего коллеги уже после того, как я на неё сослался в паках.