[0P0][Reliability] Разрешённый DEV-деплой застревает между snapshot, допуском секретов и восстановлением после сбоя #300

Проблема

Ожидание владельца от режима 0P0 в этом сценарии: доводить уже разрешённую задачу до проверенного результата в пределах действующих достаточных полномочий, без повторного согласования тех же действий. В случае Pulse подготовка DEV-деплоя закончилась цепочкой внутренних отказов и отчётами «готовность не подтверждена»; организацию дальнейших действий пришлось снова брать на себя владельцу.

Это сквозной дефект подготовки и продолжения доставки. Сам отказ читать секрет через неразрешённый скрипт соответствует политике. Требуется рабочий разрешённый путь с восстановлением и точной диагностикой.

Предлагаемый приоритет: P1 / High. Блокируется конкретная разрешённая доставка. Авария DEV, ошибка пароля и утечка секретов не установлены.

Наблюдения и границы доказательств

Источник локальных результатов — предоставленный владельцем отчёт проверки от 2 ноября 2026 года; команды и аварийные тесты автор этого issue повторно не выполнял. Дополнительно выполнено чтение исходников Getzilla и существующего оператора Pulse на GitHub. Тождество GitHub-копии локальному оператору не проверено.

• В Pulse установлена Getzilla 2.3.1. В проектной политике есть точечные secret_consumers, но временный .getzilla/runtime/scratch/selector-ui-deploy.py в них не включён. Разрешение для selector_c1f_ui_deploy.py относится к другому файлу. Точечный тест политики прошёл: разрешённый потребитель принимается, посторонние читатели отклоняются.
• В беседе приведено сообщение Command blocked by PreToolUse hook: Reading secret material is blocked: the shell command references <consumer-root>/.env. Исходный raw event позднее восстановить не удалось. Отсутствие допуска у текущего кандидата установлено; приписывать именно ему точную причину исторического отказа без исходного события нельзя.
• По отчёту новый оператор передаёт путь учётных данных подключаемому модулю и явно не печатает пароль, но включает до 1000 байт произвольного удалённого stderr в сообщение ошибки. Это непроверенный канал вывода секретных данных, а не доказанная утечка. Рабочий .env в ходе диагностики не читался.
• В изолированном локальном тесте SIGKILL после создания каталога блокировки и до замены файла оставил блокировку; повтор получил release locked, целевой файл не изменился.
• Во втором локальном тесте SIGKILL сразу после замены сохранил новую версию файла, журнал исходного состояния и каталог блокировки; повтор был остановлен. После удаления блокировки только в этом изолированном тесте, при достоверно завершённом процессе, повтор прошёл.
• Блокировка кандидата реализована созданием общего каталога; подтверждённого владельца для безопасного автоматического восстановления в нём нет.
• Исторический набор тестов другого selector-оператора завершился двумя ошибками несовпадения текущих файлов с зафиксированным снимком. Причины конкретных различий требуют проверки.
• Повторный поиск исходной команды в runtime был остановлен после незавершённого ограниченного сканирования и circuit breaker. Это наблюдение о диагностике, не доказательство состояния DEV.
• Подключение и доставка на DEV не выполнялись. Наличие зависшего lock на DEV не установлено.

По чтению репозитория разрешённый selector_c1f_ui_deploy.py также не является универсальной заменой: его профиль привязан к конкретной исходной ревизии и одному selector-v2.js; его исполнитель использует общий mkdir-lock. Запись в allowlist сама по себе не подтверждает пригодность для нового пакета.

Три независимых условия готовности

Пересборка снимка может устранить два исторических сбоя только после проверки их причин. Она не добавляет secret_consumers, не исправляет crash recovery и сама по себе не подтверждает готовность DEV-доставки.

Ожидаемое поведение 0P0

1. Проверять допуск до обращения к учётным данным и цели. Определить текущий проект, разрешённую цель, фактический исполняемый артефакт и его исходную ревизию, credential selector, необходимые полномочия и протокол блокировки. Изменение артефакта, selector или цели требует повторной проверки применимости допуска. Переиспользовать совместимый штатный путь; независимую локальную подготовку и проверяемую доработку выполнять в существующем контуре.
2. Отделять полномочия от технической готовности. Существующее согласие используется только в своём точном объёме. Агент не выдаёт себе новые права на секреты. Если необходимое разрешение отсутствует, завершает доступную локальную подготовку и предъявляет один конкретный недостающий scope; повторно спрашивать уже данное согласие не требуется.
3. Восстанавливать по общему протоколу. Сохранить совместимость всех операторов общей блокировки; подтверждать идентичность владельца/поколения и завершение всей операции, сверять журнал и фактические хеши цели. Для оставшихся дочерних/удалённых процессов исход не считается известным по смерти одного родителя. Неизвестный владелец или исход блокирует только зависимую mutation.
4. Разделять освобождение lock и восстановление данных. После аварии до замены и после замены система должна либо безопасно продолжить/откатить операцию, либо выдать конкретное проверяемое условие для восстановления. Для legacy-lock без владельца нужна отдельная ограниченная процедура; нельзя подменять общий mkdir-протокол на flock у одного клиента.
5. Давать ограниченную безопасную диагностику. Сохранять достаточные санитизированные сведения об отказе: идентификатор попытки, версия политики, стадия и причина, идентичность цели/оператора. Не записывать сырой ввод, stdout/stderr или секреты ради воспроизводимости. Ограничение 1000 байт не является редактированием секретов.
6. Сохранять возможность продолжать независимую работу. Circuit breaker прекращает повтор запрещённой операции; независимые разрешённые проверки и локальные исправления, не воспроизводящие запрещённый доступ, сохраняются. Повтор возможен в пределах явного лимита после доказанного изменения относящегося к отказу условия, с записью этого изменения в trace, без косметических переписываний команды или очистки denial ledger.
7. Показывать раздельные статусы. Проверка пакета, допуск, восстановление, подключение и фактическая доставка имеют собственные результаты. BLOCKED указывает точное условие и следующий разрешённый шаг; не подменяет выполнение доступной части работы.

Критерии приёмки

• В изолированной интеграционной фикстуре уже разрешённая операция проходит подготовку, проверку допуска, исполнение и независимую проверку результата без повторного запроса тех же полномочий.
• Неразрешённый потребитель, другой secret selector/target или изменённая непроверенная версия оператора не получают доступ автоматически. Доработка не ослабляет границы действующей политики.
• Исправление только snapshot mismatch оставляет готовность ложной, пока допуск и crash recovery не подтверждены. Новые ожидаемые значения проверяются по требованиям и разобранному diff.
• Аварии до замены и сразу после неё, повторный запуск, повторная авария во время восстановления и повторный rollback дают согласованный проверенный результат без потери исходных данных и дублирования побочных эффектов.
• Параллельный живой оператор, неизвестный legacy-owner и ещё работающий дочерний/удалённый процесс защищены; общий lock не удаляется по одному TTL, PID или факту наличия.
• Существующие операторы общей блокировки совместимы с выбранным восстановлением либо выполняется проверенная согласованная миграция. Смешанный режим не допускает двух одновременных writers.
• Синтетический секрет, помещённый тестом в stderr/исключение и данные отказа, не попадает в ответы агенту, пользовательские журналы и сохраняемый trace. Диагностика сохраняет стадию и безопасный код причины.
• После отказа доступна разрешённая ограниченная диагностика конкретной операции; её ошибка не объявляется ошибкой пароля/недоступностью сервера. Независимая работа не теряет scope.
• Итог отдельно показывает локальную готовность и фактическую доставку. DEV считается проверенным только по реальному результату и независимому чтению целевого состояния/проверке нужной функции.

Связанные задачи и объём

• Meta: make process cost proportional to change risk #138 — стоимость процесса и лишние согласования.
• Длинная задача теряет scope; snapshot и диагностика tree-bound grants при доставке Pulse #252 — сохранение scope, диагностика tree-bound grants и ограниченного сканирования.
• approve accepts git-push-branch without --resource and creates an unusable grant #221 — успешное создание непригодного разрешения.
• [P1][Reliability] Automatic resource cleanup without loss of local work #168 — владение ресурсами и восстановление после сбоев; его закрытие не доказывает исправление конкретного consumer deploy-lock.
• [P1][Security] Trust boundaries: secrets/PII egress and prompt-injection defenses #148 — фильтрация секретов в выходных данных.

Этот issue фиксирует сквозную приёмку разрешённой доставки и продолжения работы. Он не дублирует общее управление временными ресурсами и не переносит автоматически весь отложенный runtime-бэклог в текущую работу. Дефект конкретного Pulse-оператора и интеграция Getzilla должны иметь отдельные проверяемые результаты. Закрытие требует результатов перечисленной изолированной интеграционной матрицы; успешная локальная приёмка не подтверждает выкладку на DEV. Оформление issue не означает исправление, зелёные тесты или выполненную выкладку.