PACT: Программная система управления для Claude Code после сбоев в работе агентов

После трёх месяцев разработки мобильного приложения с Claude Code (более 350 файлов, 70+ таблиц базы данных, BLE peer-to-peer, зашифрованная локальная база данных, облачная синхронизация) разработчик выявил повторяющиеся паттерны сбоев, которые нельзя было исправить с помощью правил CLAUDE.md. Агент постоянно совершал одни и те же категории ошибок в разных сессиях, включая трижды добавление запрещённых библиотек базы данных после предупреждений, утечку метаданных шифрования на сервер (что сломало вход для всех пользователей), потратил 4+ часа на отладку Bluetooth, угадывая API вместо чтения документации, и внесение исправлений безопасности, которые сломали восстановление резервных копий из-за неучёта полного жизненного цикла.

Проблема с правилами

CLAUDE.md разросся до 50+ правил, но стал формальностью — Claude декламировал их в начале сессии и легко нарушал. На вопрос, почему правила игнорируются, Claude ответил: «Я должен быть честен с вами. Я могу игнорировать правила, рассматривая их скорее как рекомендации. Они не всегда могут предотвратить поведение...»

Решение: Фреймворк PACT

Разработчик спросил Claude: «Если бы я дал вам разрешение перепроектировать эту систему самостоятельно, что бы вы построили?» Это привело к созданию PACT (Programmatic Agent Constraint Toolkit) с ключевой идеей, по словам самого Claude: «Правила — это рекомендации. Инфраструктура — это закон.»

Четыре столпа PACT

• Механическое принуждение: PreToolUse хуки, которые блокируют запрещённые паттерны до внесения изменений. Примеры: import hive? Заблокировано. print() вместо логгера? Заблокировано. Редактирование файла, который вы не читали? Заблокировано.
• Замена контекста: YAML карта архитектуры (SYSTEM_MAP.yaml) описывает каждый поток данных: таблица базы данных → сервис → управление состоянием → экран UI → каскадное поведение. Агент читает это вместо того, чтобы тратить 15–20 минут на перечитывание исходных файлов в каждой сессии.
• Саморазвивающееся мышление: Вместо правил («всегда проверяй зависимости») — когнитивные перенаправления в виде вопросов: «Что зависит от этого, и от чего зависит это?» Вопросы вовлекают мышление так, как правила не могут. Агент может добавлять новые перенаправления, когда ловит себя на предположениях.
• Разделение структуры/поведения: Карты архитектуры (какие файлы существуют) остаются отдельно от потоков жизненного цикла (что происходит в разных состояниях приложения). Предотвращает две самые частые ошибки документации: карты превращаются в эссе, которые никто не читает, и потоки дублируют структуру, которая устаревает.

Примеры практической реализации

Когнитивные перенаправления на практике: «Когда собираешься удалить код: Почему этот код существует?» было добавлено после того, как Claude удалил обходное решение для бага фреймворка, хотя комментарий прямо над ним объяснял, почему оно там. «Когда находишь возражение против собственного решения: Это возражение реально, или я сдаюсь?» было добавлено после того, как Claude предложил правильное исправление, отговорил себя от него во время проверки, и разработчику пришлось спасать его же идею.

Трекер багов с базой знаний решений: Одна сессия потратила 3 часа на решение проблемы BLE, специфичной для Samsung. Следующая сессия столкнулась с тем же багом без памяти о нём. Теперь каждое исследование логируется в реальном времени — симптомы, неудачные попытки, коренная причина, исправление. Первое действие агента при любом баге — проверка, не решила ли его предыдущая сессия.

Файлы знаний о пакетах: Кошмар 4-часовой отладки Bluetooth произошёл потому, что Claude угадывал, как работает пакет, на основе устаревших обучающих данных. Теперь есть обязательное требование консультироваться с файлами знаний о пакетах.