Полигон

SOSTOYANIE.md — точка входа, на которую ссылаются 20 файлов репозитория, — считает открытые вопросы только по следу `shina/sled` и ни разу не открывает `content/razvilki-*.md`. Два других живых прибора и сам реестр развилок в один голос дают число 3.

чем доказано · Python-скрипт независимо пересчитал число двумя путями (след шины + `start.razvilki_otkrytye()`) и сверил с напечатанным в файле: код возврата 1, «SOSTOYANIE.md печатает '0', первоисточник даёт 3». После правки то же мерило проходит нулём — числа считаются одной и той же функцией и разойтись им больше негде.

дело · Патч сделан и проверен: `scripts/shina.py` теперь импортирует `start.razvilki_otkrytye()` вместо собственного слепого подсчёта; при ошибке чтения — красная строка с причиной, а не тихий ноль.

источник: content/audit/2026-09-05/10-otchyot.md; content/audit/2026-09-05-pravki/pravka-03-sostoyanie-vryot.md

Коммит от 16.08 с реальными значениями девяти API-ключей вычищен из main, но живёт через забытую резервную ссылку git filter-branch — доступен локально любому агенту, работающему в общем .git.

чем доказано · `git show cbaa4d9:.env.local.bak` печатает файл целиком; `git for-each-ref refs/original` находит резервную ссылку `refs/original/refs/heads/main`, которая одна из ~40 рефов доходит до этого коммита. Аудит 05 и правка 02, 05.09.2026.

дело · Владельцу: сделать полную копию репозитория, затем `git update-ref -d refs/original/refs/heads/main`, точечно вычистить 4 записи рефлога main и выполнить `git gc --prune=now`; отдельно — сменить все девять ключей у провайдеров, независимо от того, дошла ли история до GitHub.

источник: content/audit/2026-09-05/05-otchyot.md; content/audit/2026-09-05-pravki/pravka-02-klyuchi-v-istorii.md

`.github/workflows/yersham.yml` каждый день коммитил и пушил в main то, что написала платная модель, — без прогона мин, без ветки и без PR. Единственное такое место во всей системе: все остальные пути к пушу так или иначе спотыкаются о ветку, кнопку или проверку.

чем доказано · Аудит 04 (05.09) построчно прочитал workflow и сравнил его с `noch.sh` (там перед пушем — дельта мин и PR). Правка 01 подтвердила код возврата не чтением, а прогоном: синтетический `/tmp/gate_sim.sh` с искусственно проваленной миной и с реальным `proverka_min.py` (4 из 25 проверок красные на этом дереве) оба дали `[SKIPPED] Commit new items`, `ИТОГ ДЖОБЫ: FAILURE`; контрольный зелёный прогон коммитил как обычно.

дело · Владельцу — вставить готовый диф в `yersham.yml` (добавляет шаг «Прогон мин» между сборкой карточек и коммитом) и включить branch protection на `main` в настройках GitHub — это единственная часть, которую правка файла сделать не может.

источник: content/audit/2026-09-05/04-otchyot.md; content/audit/2026-09-05-pravki/pravka-01-vorota-avtopusha.md

`shina/logi/` — каталог, на который ссылаются все приборы как на доказательство своего запуска, — целиком отсутствует в репозитории. Реестр приборов называет несуществующий скрипт, а прибор, который следит за молчанием остальных, сам молчит почти три недели.

чем доказано · `git log --all -- shina/logi` — пустой вывод за всю историю (строка в .gitignore). `git log --all --diff-filter=A -- scripts/noch_audit.sh` — пуст, хотя реестр требует его голос под именем «ночной аудит». `git log -1 -- content/pribory.json` = 2026-08-17 — 19 суток на момент проверки при собственном пороге тревоги в 48 часов.

дело · Заменить в `shina/pribory-raspisanie.json` запись-призрак «ночной аудит» на реально существующие `audity.sh`/`audity_zapusk.sh`; разобраться, почему `pribory.py` не пишет уже 19 суток — именно он должен был первым закричать о молчании остальных.

источник: content/audit/2026-09-05/01-otchyot.md; content/audit/2026-09-05-pravki/pravka-06-pribory-prizraki.md

Замер по журналам работы (resheniya.md, ZHURNAL.jsonl, zhurnal-agentov.md, ZHURNAL-NASTROEK.md, след шины) нашёл только установку и правки текста скиллов — ни одного факта применения. Это совпадает с прямым разбором вызовов инструмента Skill по транскриптам прошлого раунда.

чем доказано · `grep -rn "<имя_скилла>" content/resheniya.md content/ZHURNAL.jsonl content/zhurnal-agentov.md docs/ZHURNAL-NASTROEK.md breaks/zhurnal-nochi.md pamyat/otkazy.jsonl shina/sled/*.jsonl shina/logi/zhurnal_avto.log` по каждому из 35 имён — совпадений-применений 0. Независимо: разбор `tool_use` по 372 транскриптам мака (`docs/audit/07-skilly.md`, 04.09) дал 0 из 34 вызовов инструмента Skill.

дело · Не заводить новые скиллы бездумно на месте старых промптов-заготовок. Для явных кандидатов на снятие (семь скиллов семейства superpowers/executing-plans без единого следа и три внешних — claude-usage-analyst, context-engineering, python-memory-safe-scripts) решение — за владельцем.

источник: content/audit/2026-09-05/08-otchyot.md

Бэкфилл канала Yersham (67 карточек одним коммитом) почти целиком не получил второго прохода линзы. Конвейер выглядел рабочим, потому что «пустой список забрать» в 93% случаев — это корректный вердикт «мимо», а не брак; настоящая дыра пряталась за похожим на неё нормальным фоном.

чем доказано · `grep -L '^verdict:' content/lenta/*.md` → 93 карточки без вердикта вообще. `git log --diff-filter=A` по 67 файлам того бэкфилла показал: у 65 из них (97%) verdict и zabrat отсутствуют полностью, спустя неделю не исправлено. Дозор того же дня (`content/dozor/2026-08-29.md`) независимо фиксирует: «материалы 1094 +1 карточек с действиями» — из 67 новых карточек действие получила фактически одна.

дело · Прогнать второй проход линзы точечно по этим 65 карточкам; проверить `scripts/potolok.json` (введён 30.08 как реакция на класс этой же проблемы) — не обрывает ли он очередь так же на следующем крупном бэкфилле.

источник: content/audit/2026-09-05/06-otchyot.md

Тяжёлый чанк поиска (3,6 МБ прямо в браузер) заменён на статический индекс, собираемый на сборке Vercel. Живой запрос на проде вернул одну точную карточку вместо трёх ложных срабатываний прежней схемы.

чем доказано · Коммит 21fc529 задеплоен, /pagefind/pagefind-entry.json отдаёт русский индекс на живом сайте; запрос «замысел операции» дал точную карточку с баллом 6, три прежних ложных ушли в «Рядом по смыслу». Замер по 28 контрольным словам из середины транскриптов: 22 попадания в первую пятёрку, средний ранг 3,1. Владелец лично сверил выдачу глазами и сказал «выдача лучше и кажется годится».

дело · Не закрыто: вес JS-страницы поиска ещё не измерен — сборка на мосту не идёт из-за нативного биндинга tailwind под linux-arm64. Это последний открытый порог тикета.

источник: content/resheniya.md, запись 2026-09-05 «Поиск по сайту видит весь корпус, включая тело транскриптов»

Проверка на случайной выборке карточек с прежним вердиктом «мимо»: линза v2 находит готовое действие в points и ставит непустой zabrat. Критерий провала — меньше 6 из 10 — записан ДО прогона, а не подобран задним числом.

чем доказано · `content/proby/linza-v2-podjom.json`: порог 6 из 10, зерно случайности 17, объём выборки — из 777 карточек, удачно 8, вердикт «успех», хэш прогона `0b36f2ed3018df9c`. Независимо подтверждено аудитом 03 (05.09): «коммит 3476507 прямо называет это „проба пройдена“».

дело · Массовый прогон на оставшихся 777 карточках — по тексту самой просьбы это действие лично владельца, не агента.

источник: content/proby/linza-v2-podjom.json; content/audit/2026-09-05/03-otchyot.md

PRAVILA.md прямо называет цену повтора: путь-плейсхолдер вида «/полный/путь/к/папке» был выполнен как есть дважды. Проверка `min_zaglushki_v_komandah`, которая по названию обязана это ловить, на такой форме не срабатывает вовсе.

чем доказано · Regex-функция проверки прогнана как python-однострочник на реальной фразе из правил: `ZAGLUSHKA_V_KOMANDE.findall("bash zapusk.sh /полный/путь/к/папке")` вернул `[]` — пусто. Проверка ловит только `<угловые скобки>`, `ВСТАВЬ_ИМЯ`, `YOUR_KEY`, но не слово внутри обычного пути.

дело · Расширить `min_zaglushki_v_komandah`: если сегмент пути (между `/`) целиком совпадает со словом из набора {путь, папка, файл, каталог, имя, полный} — считать плейсхолдером и проваливать проверку.

источник: content/audit/2026-09-05/02-otchyot.md

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

чем доказано · `shina/logi/miny-do-*.json` за 14 дней: иероглифы в сводках — 10 срабатываний, запретное наружу — 8, потолок расхода — 8, след шины — 6, канарейка — 4, пробы в рабочих файлах — 4, коммит без пуша — 3, ещё две мины по одному разу. Итого 45 срабатываний на 9 разных проверках.

дело · Ничего чинить не требуется — вывод подтверждает уже существующий механизм. Единственное действие — поддерживать соответствие между `content/miny.md` и `proverka_min.py` по мере роста реестра, как показал соседний вывод о словесном плейсхолдере.

источник: content/resheniya.md, запись 2026-09-05 «Чем доказано, что проверки мин работают»

Посетитель, кликнувший на /prosby, /miny или /ochered с публичной главной, получал 307 на /vhod — «Личный раздел. Публичного здесь нет» — вместо открытого журнала, который сайт обещает показывать.

чем доказано · Обход 180 внутренних ссылок с 16 страниц браузерной панелью на маке (аудит 09, живой сайт): битых ссылок 0, но 14 адресов уводят в /vhod. Повторная проверка из облака через WebFetch (правка 04) подтвердила: починка лежит в HEAD (коммит 058f422), но main опережает origin/main на 4 коммита — на живом buyanov.io дыра ещё открыта.

дело · Отправить готовую починку в origin (`git push origin main`); отдельно проверить, показываются ли гостю ссылки на /moe и /pult из `ZabratChecklist.tsx` и `PultLauncher.tsx` — если да, спрятать их за проверкой владельца, как сделано в app/moe/page.tsx.

источник: content/audit/2026-09-05/09-otchyot.md; content/audit/2026-09-05-pravki/pravka-04-snaruzhi.md

До этого дня ни одна заявка с сайта не доходила ни разу за всё время существования формы. Разрыв держался с 2 сентября и складывался из трёх независимых поломок сразу, каждая записана отдельной строкой в реестре мин.

чем доказано · Три пробы цепочки «сайт → своя дверь → телеграм → телефон», третья — живым заполнением формы на /offer, а не запросом мимо неё. Все три пришли в рабочую группу телеграма в 01:08, 01:14 и 01:16, скриншот доставки у владельца.

дело · Закрыто; три причины разрыва (пропуск сборки на Vercel, отсутствие переменных телеграма в окружении, чужой сервис на главном пути формы) не чинить заново — они уже записаны отдельными строками в content/miny.md, следить, чтобы не повторились по отдельности.

источник: content/resheniya.md, запись 2026-09-05 «дверь заявки»

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

чем доказано · Один и тот же кусок канона прогнан через `scripts/hody.py` на русском и английском: русский — 926 символов / 139 слов / ≈514 токенов; английский — 1019 символов / 172 слова / ≈443 токена. Отношение 1,16, не 2. Сторонний токенизатор не понадобился — считал тот же прибор, что меряет окно сессии.

дело · Не переводить скиллы и правила на английский ради экономии; не доверять пословным оценкам стоимости языка без прямого замера на одинаковом смысле — источником приёма было чужое видео, а не собственный тест.

источник: content/resheniya.md, запись 2026-09-03 «приборы и учёт»

Операторские проверки вынесены из scripts/proverka_min.py в отдельный переносимый пакет и прогнаны на дереве, собранном с нуля по README, а не по памяти прежней работы.

чем доказано · На пустом чужом репозитории — 7 проверок зелёные, 3 честно «не проверено», ложных красных ноль. На том же дереве с десятью намеренно заложенными минами — найдены все десять, код возврата 1. После слияния обратно — вердикты ядра и старого прибора совпали по всем десяти проверкам на этой же копии.

дело · Ядро можно предлагать другим проектам как самостоятельный пакет; вопрос «куда выложить и под каким именем» остался решением владельца, тикет не закрыт до его ответа.

источник: content/resheniya.md, запись 2026-09-03 «тикет 08, ядро проверок»

Первый прямой замер всей полки локальных моделей (раньше существовал только для одной) показал разброс от ×0,93 до ×7,1 между весом файла на диске и занятой оперативной памятью на живом вызове.

чем доказано · `scripts/zamer_modeley.py` обошёл `/api/tags`, `/api/ps` и `/api/embed` по 13 моделям за 2,2 минуты (4 облачных `:cloud` пропущены по конструкции). `phi3:3.8b`: 2,18 ГБ на диске → 15,50 ГБ в памяти (×7,1). `gpt-oss:20b`: 13,79 ГБ на диске → 12,80 ГБ в памяти (×0,93, память меньше веса файла).

дело · Подбор пары моделей под задачу теперь идёт по занятой памяти из `/api/ps` (правило: 28,3 ГБ живёт, 34,6 ГБ падает), а не по размеру файла модели на диске.

источник: content/resheniya.md, запись 02.09.2026 «карта локальных моделей и замер всей полки»

Критерий провала («совет обязан совпасть с исходом больше чем в половине развилок корпуса») записан ДО прогона. Результат — 33% совпадений на 39 развилках против нужных 50% — назван провалом, а не «почти получилось».

чем доказано · Файл прогона `etalon-razvilki.json`, 02.09 в 03:52: три способа связать совет с исходом (концентраторы, словарь, смысл) и четыре порога отсечки проверены на 91 собранной развилке. Совпадений — 13 из 39, случайное совпадение на тех же данных — 3%: различение есть, но заявленный порог не взят.

дело · Не подбирать порог отсечки по этому же прогону задним числом — это узаконит подгонку под удобный результат. Следующая проверка мерила — только на развилках, записанных после 02.09.

источник: content/resheniya.md, запись 2026-09-02 «Мерило совета на живых развилках · ПРОВАЛ»

Рычаг, поднявший счёт мерила до 12 из 14 на 199 кусках, при расширении на 1214 кусков (весь непокрытый личный контент) просел до 8 из 14. Это не списали на случайность: откат к первым 199 кускам вернул ровно 12 из 14 с теми же промахами.

чем доказано · Ночной прогон `poisk/noch_rasshirenie.sh`: 1214 кусков, 4303 вопроса, 1 ч 55 мин, деньги — ноль. Контрольный замер без ключа доступа к вопросам — 9 из 14 (столько же, сколько до прогона: база и эмбеддинги целы). Индекс пересобран обратно на первых 199 кусках — мерило вернуло 12 из 14 с теми же двумя промахами.

дело · Не расширять покрытие doc2query дальше 199 авторских кусков и не перегенерировать вопросы дешёвой моделью ради одного лишь охвата — на 1214 кусках вопросы плодят конкурентов, которые перебивают нужный результат.

источник: content/resheniya.md, запись 2026-08-29 «Расширение doc2query на всё личное (1015 кусков)»

Из шести опробованных способов починить поиск (вес слоя, свод близости по файлу, реранкер, HyDE, doc2query, приписка заголовка документа) только один дал прирост на контрольных 14 вопросах с заранее известным правильным ответом.

чем доказано · `poisk/merilo.py`, один и тот же корпус и те же 14 контрольных вопросов: было 9 из 14, стало 12 из 14 — починены промахи 4, 5, 10, 11 (сломан один ранее проходивший, 12). Для сравнения реранкер на тех же вопросах дал 9→9, HyDE — 0 или 1 починенный вопрос из пяти на пяти разных локальных моделях.

дело · Не возвращаться к починке поиска со стороны запроса (ранжирование, веса, реранкер, HyDE — все шесть замеров этой стороны отрицательные). Расширять покрытие doc2query только на личные куски и с оглядкой на нелинейность — см. соседнюю запись о регрессе при расширении.

источник: content/resheniya.md, запись 2026-08-29 «doc2query для авторских кусков»