- P1
маршрут не может уехать в прод: сегодня его держит только отказ в проде — ни лимита на сумму, ни одобрения вторым операторомanchor: до того, как ledger.manualAdjustment.enabled станет true где-либо кроме стенда
- P1
каждый флаг datacenter / VPN / proxy / Tor / abuser, каждая страна и каждый ASN читаются «unknown» на любом деплое, покрытие обогащения 0 — IP-половина фрод-портрета и обогащение панели кластеров слепы, пока провайдер не куплен; ни денежный путь, ни вердикт от него не зависят (фикстуры отвечают пусто, страницы печатают правду)anchor: до продакшн-релиза (Евгений, 2026-10-20 13:00:44Z, ask 0e5d0cf3) — блокер №7 цели #2494; свой эпик по обычному процессу, когда владельцы назовут поставщика (Никита 2026-10-29 назвал ipapi, около $20 в месяц; сайт ещё уточнить)
- P1
на стенде ничего, но на запуске ни одно письмо-алерт не уходит и страница подписки остаётся выключенной: вендор отправки (и его цена) и домен с SPF / DKIM / DMARC не выбраны, а DNS-записи требуют шага человека и ожидания распространенияanchor: до продакшн-релиза — не цель #2286 (её QA-обход идёт через Mailpit стенда): продовый бут с включёнными алертами обязан отказывать, пока не заданы креды вендора и домен отправки
- P1
30 PR класса A денежного пути из таблицы issue (#2433 … #2636; у #2388 человеческий проход снят владельцем) стоят на main только с автоматическим ревью — человеческий просмотр финального диффа (ADR-009, п. 3) отложен до релиза, и каждый следующий PR класса A под той же отсрочкой добавляет строкуanchor: до продакшн-релиза: отдельное ревью денежного пути владельцами (Евгений, 2026-10-27, ask c438a602) — форму и ревьюеров называют владельцы, «когда» — за релизом
- P1
казначейство bitcoin — кошелёк, а не один адрес: §2.3 исключает только настроенный адрес казначейства, поэтому пополнение флоата, подписанное кошельком казначейства со входом с его же адреса сдачи и отправленное на адрес депозита Игрока, будет зачислено этому Игроку, а член казначейства в §4.3 (один адрес через scantxoutset) недосчитывает сдачу казначейства — сегодня это держит только временное правило (казначейство — один адрес со сдачей на себя, пополнение никогда не идёт на адрес депозита)anchor: до включения bitcoin в мейннете (цель #2494) — блокер продакшна: записанный адрес флоата платформы для bitcoin («A+») делает правило механическим до продакшна
- P1
путь кражи на Solana: вендор шлёт сбор (депозит → hot) или вывод Игрока на первый перечисленный токен-аккаунт владельца, не проверяя владельца, и подсаженный чужой аккаунт, переоформленный в окне, получает токены, а пустой подсаженный аккаунт останавливает выплаты минта («Have not enough tokens») — наша сверка такой сбор не пейджит, недостачу позже покажет только сравнение §4.3 (гонка не воспроизведена на цепи)anchor: до включения Solana в мейннете (goal:mainnet-payments); стенд с локальным валидатором (N6 #2129) не затронут
- P1
выплата Solana становится paid по слову вендора «отправлено» (success сразу после sendTransaction), а не по факту на цепи — сброшенная или упавшая транзакция записывается выплаченной, и Игрок списан в Ledger, хотя средства не ушлиanchor: до включения Solana в продакшне (рядом с #2550)
- P2
каждый новый клиентский маршрут требует ручной проверки на пересечение с API — коллизии предотвращены, но не невозможныanchor: следующая цель
- P2
у оператора нет описанного действия для выплаты, которую вендор принял и молча провалил — ключ идемпотентности сожжёнanchor: до первой продовой выплаты
- P2
книга называет неоплачиваемое реферальное обязательство долгом — нет команды списать его как «благотворительность» (деньги остаются дома)
- P2
свидетельства проверок и известные блокеры терялись между агентами — закрыто инструментом #1019; остаётся обкатка (пилот)
- P2
раунды ревью переоткрывают соседние экземпляры одного класса дефекта; покрытие ревьюеров не отчитывается отдельно от консенсуса
- P2
лайки не ограничены по сессии: цикл по 300 сообщениям даёт до 1,2 млн записей в сокеты в секунду на 1000 сокетов — в 120 раз выше расчётного пикаanchor: до продового трафика в чате
- P2
дом должен выплаты ящиков в USDT против края во всех ассетах: нет размера флоата, нет алерта на балансе system:house в ассете выплаты и нет описанной операции продажиanchor: до цели, которая выводит crates-ev в прод
- P2
цикл ставка → отказ (1.00, исход «never a void») → повтор начисляет XP (уровни, ящики, рейкбек) и срез края по номинальным 200 bps при нулевом взятии дома; с T3 #2318 отказ one-road XP не минтит, но прогресс отыгрыша растёт, двухполосный экземпляр остаётся, а граница цикла и реферальные на нём не измерены — ни одна строка харнесса его не оценивает
- P2
Telegram-канал уезжает на стенд как none (не предлагается); его живые состояния приняты по скриншотам браузерного e2e над двойником (ask d57ebebd → A), а не глазами человека на стенде; каждый факт Bot API в адаптере и двойнике стоит на документации и вживую не проверен — изменённую Telegram формулировку или лимит покажет только прод; у Telegram-истории цели #2286 нет прохода на стенде, пока долг не оплаченanchor: до любого прод-раската Telegram-канала (спека #2344 D56: прод грузится с каналом none; FU6 той спеки свёрнут сюда — прод-бот станет debt:P1 на запуске рядом с #2291 в тот день, когда владельцы решат его запускать); на стенде это пометка, не блокер
- P2
Discord-канал уезжает на стенд как none (не предлагается); его живые состояния приняты по скриншотам браузерного e2e над двойником (ask d57ebebd → A, перенесено 6a3ea36e), а не глазами человека на стенде; каждый факт Discord в адаптере и двойнике — задокументированная догадка до живой проверки, и та, что решит, доставляет ли путь по умолчанию (приложение, установленное пользователем) личное сообщение вообще, — это SN1anchor: до любого прод-раската Discord-канала (спека #2363 D69: прод грузится с каналом none; прод-приложение станет debt:P1 на запуске рядом с #2291 в тот день, когда владельцы решат его запускать)
- P2
custody-e2e краснеет без единого упавшего теста (40787173560 — вердикт full, 41172379039, 41182259200): контейнер стека SHKeeper payout выходит до готовности celery (fleet.ts:185), а почему он умер, не печатается
- P2
общий 5xx-путь сервера (error-handler.ts) пишет сообщение ошибки хранилища целиком, а DrizzleQueryError несёт параметры запроса — данные от Игрока, вендора или ноды попадают в лог запросов любого модуля
- P2
findByChainAddress берёт любую строку адреса с такой строкой (LIMIT 1, без фильтра статуса и порядка): если строку выведут и перевыдадут, детекция и ремонт гейта могут привязать депозит не к той строке, возможно не к тому Игроку, — а депозит, зачисленный не тому Игроку, это денежный дефект (возможность пока не установлена)
- P2
вендор тратит UTXO с одним подтверждением (min_confirms=1), а это может быть депозит Игрока, ещё не зачисленный нашим гейтом на глубине 6: если такой депозит уйдёт в реорг, с ним падает и потратившая его транзакция выплаты, и пока сопоставление выплат D40 для bitcoin не перечитывает paid по финальности нашей ноды, выпавшая в реорг выплата может остаться paid
- P2
страницу wallet.deposit-unreadable-version можно залить: 200 транзакций × 50 адресов (около 0,001 SOL комиссий) дают ~10 000 страниц за проход lookback, а после 10 000 пар очистка целиком перепейджит всё 24-часовое окно на каждом проходе; бэкенд, ложно отвечающий -32015 на транзакцию версии 0, двигает курсор мимо реального депозита, и runbook этого не называет
- P2
проверка адреса назначения вывода, которая отказывает в выводе на наш собственный адрес депозита или платформы, сравнивает адреса TON как строки, а у одного аккаунта TON несколько написаний (сырое 0:<64 hex>, bounceable EQ… / non-bounceable UQ…, тестнетовые, url-safe): Игрок может ввести наш адрес депозита в другом написании, и он не будет распознан как наш — в том числе в QA-выводе, пока ton живёт на стендеanchor: до QA-журнала ton на стенде (N8 #2133), как #2528 для N5 у bitcoin; блокирует запуск выводов TON (N8 #2133) и мейннет TON (цель #2494)
- P2
три места в воркфлоу (checkCmd с pnpm verify в epic-implement.js, атаки атакующего места в e2e, третья запись pnpm verify в doc-sync.js) по-прежнему велят субагентам поднимать контейнеры — против правила «наборы с контейнерами гоняет только драйвер под box --hold» (с 2026-10-24), а правка одной строкой в промпте ломала цепочку записей evidence и была отозвана
- P2
decimals строки токена Solana берётся на веру — согласие с цепью на буте есть только для EVM, в проде пина нет, и строка с неверной экспонентой масштабирует каждую зачисленную сумму этого Asset на степень десятиanchor: до включения Solana в продакшне (рядом с #2550 и #2563)
- P2
пул бэкендов на двух форках может осиротить обе строки одного перевода — за один проход или через границу батча: ноль зачислений депозита Игрока и ноль страниц гейта, единственный след — страница баланса §4.2, называющая адрес, а не транзакцию; к тому же ремонт не видит штамп попытки и может осиротить уже проведённую строкуanchor: на пути цели goal:mainnet-payments
- P3
один именованный skip на каждом прогоне driver-hub.yml: операторская рука стендового набора не выполняется в CI
- P3
два фронтенд-гейта пропускают пять именованных форм невидимыми (тишина $app-переписи, написание prerender и т.д.)
- P3
SHKeeper стенда выкидывает сессию логина после ~500 новых и забывает все на рестарте — один повторный логин адаптера
- P3
живая 2048 не читается как игра: плитки нечитаемы, дроби вместо чисел прототипа — решение Никиты
- P3
телепорт-лаб — набросок в карантине: каждый слайс добавляет строку «портировать или удалить»; переписывается, не промоутится (Евгений)
- P3
каждое изменение семейства Plinko правится руками в девяти перечисляющих наборах плюс int-наборы — около часа механических правок и один раунд ревьюера «список в наборе X протух» на каждое изменениеanchor: до следующего изменения семейства Plinko (новый ряд, перенастроенная доска, снятая доска)
- P3
коллектор телеметрии пишет ~90 ошибок Could not inspect updated container в час на каждом прогоне с testcontainers — настоящую ошибку в этом шуме легко пропуститьanchor: следующая правка коллектора телеметрии
- P3
по замеру issue (2026-09-12, main c950d944): на quick-странице Plinko поле колышков до первого броска — пустой прямоугольник, смена доски после броска оставляет треугольник прежней доски, а опубликованный множитель с 12 рядов не влезает в ячейку и сливается с соседями — Игрок может неверно прочесть опубликованную цифру; деньги и данные не затронуты (холст aria-hidden), а отложенная ветка feat/1215-plinko-field-and-faces не проверена и стоит на ad00a126
- P3
progression.ts в web-player ссылается на позиционное имя components['schemas']['schema'], которое openapi-typescript раздаёт в порядке путей: первый путь, добавленный в ProgressionService выше него, молча переведёт алиас на тип другого чтения (так сломался queue.ts web-admin на PR #1285), а гарда, запрещающего эту форму в apps/web-*, нет
- P3
место, сменившее модель, показывает замороженный процент старой модели (fable 98 % на Opus) — по мёртвой цифре можно решить передать рольanchor: следующая правка отчёта о лимитах в who()
- P3
имя того, кто снял блокер, попадает в запись только текстом причины, а лишний флаг --by молча проглатываетсяanchor: следующая правка blockers в evidence CLI
- P3
app.yml (подсказка scope) и driver-protocol §3 называют scope fast двухминутным, а он несёт golden, test и harness, и его статическая половина идёт около 11 минут (прогоны 35011470300, 35011491938): драйвер, выбравший fast как дешёвую двухминутную пробу, тратит около 11 минут раннера, а оценки стоимости строятся на устаревшей цифре
- P3
кейсы Codex-лаунчера в наборе хаба изредка краснеют на presence never showed codex- (1 из 4 прогонов набора 2026-09-18; снова в driver-hub.yml 41295783828 на main 2026-11-01) и краснят прогон без дефекта, а причина не названа — 0 красных в 65 замерах, и лечения нет, пока следующий красный не назовёт её через лог лаунчера, который кейсы цитируют с PR #1748
- P3
примерно после 10 % завершённых задач раннер ~62 с ждёт отказа 409 при захвате следующей — выбранный рычаг C только смягчает этоanchor: следующая правка раннеров
- P3
golden-форк vitest изредка умирает на V8 Check failed: jit_page.has_value() без упавшего теста (на 2026-09-26 — 2 смерти на 188 полных golden-прогонов, ≈1,1 % на прогон), и вердикт краснеет без дефекта, а флаг --no-concurrent-recompilation как лечение опровергнут — форк умер и под ним (#2225)anchor: до решения владельцев о переходе на Node 26 (#1864): issue переоткрыт и остаётся долгом, пока это решение не принято; носитель — #2225
- P3
у оператора нет ни маршрута, ни CLI для пополнения system:bonus_pool: на стенде его пополнили разовым скриптом (#589), в проде бонус-коды упрутся в пустой пулanchor: когда пул бонусов понадобится пополнять не на стенде
- P3
набор ~20 нажатий идёт внутри кейса повторного открытия, а не в beforeAll, и бюджет 80 с не пересчитан — лишние секунды на каждом прогоне e2eanchor: следующая правка rewards-cooldown.test.ts
- P3
гейт «никто не патчит глобальный fetch» — регулярка: пять написаний патча проходят её (пробел у точки, каст цели, Object.assign, ??=, ||=); на сегодняшнем дереве ни одного нет — гейт слабее своей фразы, не живой дефект
- P3
общий Cooldown ящиков (цель #1586 закрыта по решению C) так и не пройден QA на одной сборке: истечение видели только через пересоздание бэкенда — смешанная сборка, не приёмка; подсказку в шапке вне Rewards не прошли, исключение реферального подарка не доказано (нет фикстуры; проба снимается, если #2008 уберёт Crate Loot), а дороги к Игроку с двумя ящиками разных уровней в бюджете QA стенд не даёт (2026-09-19 — 40 ставок Plinko на ETH; USDT на стенде не зачисляется)
- P3
страница SEV wallet.chain-collecting-unenabled — попытка «не более одного раза», а не надёжная доставка: падение между записанным claim и вызовом синка или бросивший синк оставляет заявленный отток, чья страница так и не ушла, и рестарт её не повторит, потому что claim говорит, что страница отправлена
- P3
три мониторинговые страницы кошелька (wallet.address-walk-unbounded, wallet.chain-watch-outage и wallet.pass-overrun, повторяющаяся ежечасно, пока проход висит) идут в группе инцидентов на line.error: оператор видит в канале «an incident» там, где README стенда называет это ожидаемой мониторинговой страницей, — канал преувеличивает, README успокаивает
- P3
у one-road Trek нет чтения открытой игры: отставшая страница перечитывает её повторной отправкой идентичного OpenTrek (T3 отвечает удержанной записью, сначала разрешив висящий Step) — принято только для quick-тира
- P3
на доске Financials стенда нет счёта концовок Trek (TrekSettled по gameId и endedBy), и добавить его панелью нельзя: 11 запросов и 12 слотов Grafana довели бы сумму до ровно 2 816 MiB бюджета и 32/32 слотов сервера без запаса
- P3
Оператор не может возобновить строку «Games» в Admin → Platform, если её приостановленные игры несут два разных сообщения паузы: ResumeGames отвечает 409 game-pause-messages-differ, а страница говорит только contact-support и не возобновляет по сообщениям
- P3
Пауза строки «Games» в Admin → Platform, где есть игра, выпавшая из ростера, но ещё на паузе, отказывается целиком (422 game-not-rostered) — страница называет id, но не предлагает исключить их или сначала возобновить (строку по-прежнему можно возобновить)
- P3
четыре шва чтения цепи кошелька открыты враждебному коду внутри процесса — двойное чтение override (Proxy подменяет EVM), изменяемая таблица CHAIN_READ_ADAPTERS, слишком широкое правило depcruise для заглушки Solana и NO_FAMILY_ROUTER на главном барреле (гейт семейств открывается), плюс принятый остаток: хук Error.prepareStackTrace второго realm кладёт URL с ключом в продовый лог; из конфигурации и деплоя ничего из этого не достижимо
- P3
три ветки «выше финальной» в lookback EVM-адаптера (N17a–c) не закреплены ни одним юнит-кейсом, и их мутанты раунда 5 выживают — только живость: код бросает или читает больше, но не пропускает, — а кэш времени блоков timeCache (N19) не вытесняется никогда и растёт без границы
- P3
проход финальности пейджит ожидание из-за нашей же конфигурации (выведенный Asset, нечитаемая строка адреса) как «цепь не прочитана», и выведенный Asset пейджит вечно без названного решения, а одна строка, чьё чтение бросает, останавливает каждую строку за ней на каждом проходе, и срабатывает только wallet.job-failed
- P3
никогда не зачисленный депозит, осиротевший после финального чтения без своей ноги, остаётся orphaned навсегда, даже когда полное чтение снова находит ногу на той же тройке — деньги лежат на адресе необъяснёнными, и оператора приводит страница баланса §4.2
- P3
кейс web-e2e site-switches на Plinko (widest-w, 1440×900) покраснел в вердикте affected 40926135423 при нагрузке ~17–25: блоки страницы сдвинулись на ~76 px между снимками — вероятно (не подтверждено), снимок «до» снят раньше, чем раскладка устоялась, и вердикт краснеет без дефекта в диффе
- P3
кейс «composes the same attributes» в codex-launcher.test.ts под нагрузкой (~15) краснит driver-hub.yml (40935170849) на диффе, не трогавшем путь запуска Codex: лаунчер кончается сигналом после одного SIGTERM (exitCode null), а каким сигналом и как он обошёл обработчик SIGTERM, неизвестно — сообщение кейса не печатает signalCode
- P3
токен-депозит Solana, не приземлившийся в канонический ATA адреса (одноразовый аккаунт, аккаунт, созданный или переданный адресу внутри транзакции, аккаунт со сменой владельца), не читается и не зачисляется: деньги приходят, страница баланса §4.2 зовёт оператора — безопасный отказ, но ценой ручного разбора каждого такого депозита
- P3
автовыплата вендора на стенде каждую минуту повторяет остаток-пыль меньше стоимости газа над триггером 0,5 ETH и падает: хранилище вендора растёт примерно на 1 440 строк FAIL payout на сеть в сутки (ETH и ARBETH с 2026-10-29; каждая новая EVM-сеть добавляет свою петлю), и настоящий сбой в этой таблице тонет среди них; деньги Игроков и их выплаты не затронуты
- P3
любой за ~0,2 SOL открывает больше 100 токен-аккаунтов, принадлежащих адресу депозита Solana, и lookback адреса отказывает, а сравнение баланса §4.2 для него пропускается, пока оператор их не закроет — догон пропущенных колбэков для адреса стоит
- P3
Btc.balance() вендора на ошибке сканера отдаёт 0, пока getstatus ещё отвечает Synced, — наблюдатели флоата пейджат недостачу, которую казначейство потом «исправляет»; а §4.3 для bitcoin вокруг стадии 2 и выплаты со сдачей, вероятно, пейджит временно ВЫШЕ или НИЖЕ, и временное ВЫШЕ может скрыть одновременную потерюanchor: до того, как страницам флоата bitcoin начнут доверять: снять на стенде после N5 (#2127); страницы §4.3 bitcoin до этого снятия не доверены
- P3
четыре остатка bitcoin приняты только записью: Игрок может узнать адрес сдачи вендора из любой полученной выплаты и вывести туда — это вредит самому Игроку и показывается как §4.3 above (закрыть маршрутом нельзя); после траты UTXO Игрока §4.2 держит explained > onChain; запись сбора §4.1 для bitcoin смысла не имеет, а докблок A1 в bitcoin-chain-read.ts неверно говорит, что сканер держит кошелёк на нашей ноде
- P3
кейс migrate.int.test.ts «rows of epic 1's three controls … kept exactly» на загруженном раннере падает по таймауту 30 с с «Connection terminated unexpectedly» и краснит вердикт full (41001988546) без дефекта в диффе, а убит ли контейнер Postgres или голодал, не установлено; это 6-й нагрузочно-чувствительный int- или conformance-кейс за два дня
- P3
чтение TRON на каждое окно lookback скачивает полные квитанции каждого солидифицированного блока, на раздутых блоках откатывается к поквитанционному чтению, а транзакция, чья квитанция больше лимита 64 MiB или не уложилась в срок, пропускается — страница вместо чтения
- P3
один пропущенный jetton-перевод TON поднимает две страницы под двумя хешами (H3 из lookback, H1 из триггера), и оператор, решающий jetton-master-initiated руками, видит два хеша на один перевод; ветка z05 не закреплена — деньги не затронуты
- P3
сеть vitest-poll в ростере доставки (delivery-scan.ts) не ловит expect и .poll(, разбитые форматтером на две строки, — int-файл с таким опросом ждёт по стенным часам незамеченным (на main d3bc9a294 такой формы пока нет)
- P3
удержанное чтение TRON (таймаут квитанции одной транзакции) пейджится как таймаут цепи («chain read timeout (N of N addresses unread)») без txid — дежурный видит то, что выглядит как падение эндпоинта, даже в окнах, не пославших ни одного запроса
- P3
пока заработанное открытие ящика в полёте, нажатие отказывается cooldown-active с уже прошедшим cooldownUntil, и web-player показывает Игроку «Crates are ready to open.» и держит Open живой столько, сколько висит застрявшее открытие — вопреки тексту 409 в openapi
- P3
межфорковая коллизия ключа (остаток iii) невидима для §4.2 — без открытой строки депозита её сигналят только платформенные страницы двух форков, а отказ platform_source не пейджится; §1 к тому же не называет разрыв carried → credited и слишком узко оценивает охват коллизии (только подписант)anchor: новый вид алерта — до включения Solana в мейннете; две строки §1 — через doc-sync эпика (DS #2135) или прямой правкой
- P3
под нагрузкой статический сервер e2e не отдаёт неизменяемый чанк, SvelteKit рисует «Internal Error» на /trek, и вердикт full краснеет без дефекта страницы (41116971434, нагрузка ~43) — не видели с 2026-11-01 07:39Z, но ничего не названо исправленным
- P3
шесть мутантов аренды чтения TRON (s7-01, -02, -06, -07, -11, -12) переживают 433 юнит- и 614 conformance-кейсов: собственный успех читателя рядом с чужой арендой даёт пропуск на окно раньше (со страницей), а карта аренд может расти на каждую прочитанную транзакцию — живость и память, не зачисление
- P3
приход Token-2022 (PYUSD вендора, carried) на адрес депозита Solana не зачисляется, не записывается как незачисленный приток и не пейджится, как carried-токен EVM, — а приход, который вендор уже вывел, невидим вовсе
- P3
разовая проверка genesis пары сканера только отказывает и никогда не подтверждает кластер стенда: после потери solana-ledger при живом томе сканера пара всё равно стартует и крутится в ветке без сна без ограничения логов, а любая другая SVM-сеть с реальной ценностью проходит проверку каждый раз
- P3
валидатор solana стенда на Agave v2.3.13 держит ~1 GiB под неиспользуемое PubSub-кольцо (флага для него нет) — он трижды убит OOM на 2 GiB и работает с потолком 5 GiB
- P3
на загруженной машине operation.int «a deadlock the engine absorbs» может выбрать жертвой собственного противника теста (его deadlock_timeout 1 с против 250 мс), и int краснеет без дефекта Ledger — не видели с 2026-11-01, но ничего не названо исправленным
- P3
фикс выкачен (init: true, PR #2620; зомби curl под minio телеметрии — 3275 до деплоя, 0 сразу и через 30 минут), но дневного чтения ещё нет: не подтверждено, что утечка PID (около 250 зомби в день) не вернулась и что падение чтения minio — крупнейшего читателя диска на машине — с 30,71 до 3,66 MB/s держится, а не ранний цикл его сканера; утечка не срочна (pid_max 4 194 304)
- P3
убитый супервизор оставляет started без terminal в runs.jsonl: 45 минут каждый следующий evidence run эпика отказывается (exit 6), пройти можно только --force, который снимает и защиту живого прогона, а висящая строка навсегда остаётся в записи
- P3
код исправлен #2625: telemetry:deploy монтирует конфиги ClickHouse, docker-proxy и коллектора из /srv/agent-telemetry/config, но миграционный деплой ещё не сделан — до него живые ClickHouse, прокси и коллектор монтируют их из worktree bcas-2-wt-teldeploy на b53650cf4, и его удаление, перенос или переключение молча меняет или удаляет конфигурацию живого стека до его следующего рестарта
- P3
кейс REAL-parsers в telemetry:test краснеет на spawnSync docker ETIMEDOUT под нагрузкой вердикта (driver-hub.yml 41232617525): чтения docker image inspect упираются в стенные 60 с на загруженном демоне, а причина не измерена
- P3
кейс ledger-mount.int «leaves /health exactly what it was» проверяет статус раньше отчёта, поэтому красный печатает только 503, и какая проверка упала, неизвестно — так было в обеих встречах #2569 и будет в следующей
- P3
evidence blockers match в логе с кадрами UNKNOWN STEP принимает строку ##[group]Run из вывода проходящего теста за шаг раннера и сверяет красный не с тем шагом — его exit 3 ничего не говорит, и известная открытая сигнатура (#1592) не находится
- P3
asOf доски — 2026-10-18, старше 14-дневного предела (воскресные обновления 10-25 и 11-01 пропущены): локальный тест свежести краснеет на main у каждого, а вердикт молчит, потому что лейн пропускает этот тест по имени
- P3
derive.mjs не видит открытые долги без поля Cost of carrying:: исходные 41 этого issue (40 без поля и #2314 без метки уровня), а в чтении 2026-11-02 — 58 пропущенных, после того как ещё 17 получили метку debt; поэтому derive --apply отказывает, а доска держит эти строки рукой — каждое обновление пишет и сверяет их вручную; к тому же derive неверно читает тело самого #2638 (поле, названное в прозе, принимается за значение, комментарий 6579816232); на продукт и деньги не влияет