Runtime, аудит и доказательства

Увидеть действие и доказать результат — разные задачи#

GrantTap помогает восстановить ход работы: что запросил агент, какой результат сообщил провайдер, где был отказ и какие данные отсутствуют. Но одинаково уверенно утверждать можно не обо всём. Надпись агента «готово» не является самостоятельным доказательством изменения файла или успешного релиза.

Для учебного примера агент в GrantTap Lab добавляет скидку HELLO10 в расчёт заказа. В чате появляется вызов инструмента редактирования, затем сообщение об успехе и тестовая команда. Это полезная история. Чтобы назвать конкретный файл проверенно изменённым, нужны отдельные сведения о репозитории, ревизии и содержимом. Чтобы назвать релиз опубликованным, нужна отдельная квитанция публикации.

Это правило особенно важно при чтении старого чата, переходе между executions и работе после offline. Отсутствующая подробность не должна превращаться в придуманную уверенность.

Три истории, которые не стоит смешивать#

Usage отвечает на ещё один вопрос: каковы известные агрегаты вызовов и ресурсов за выбранный период. Это не замена полного Runtime journal.

Диагностический лог на телефоне ограничен и относится к устройству. Фильтры All и Errors помогают искать проблему подключения или обработки данных. Не воспринимайте этот лог как неизменяемый общий журнал всех действий аккаунта и не публикуйте его без проверки на приватные сведения.

Runtime внутри Task#

Runtime запрашивает ограниченные страницы Invocation history у компьютера соответствующего Project. Durable journal принадлежит отдельно работающему GrantTap Engine. Телефон показывает полученную проекцию, не создавая из небольшого Usage buffer фиктивный полный audit trail.

Если Engine отсутствует или history недоступна, экран должен сказать об этом прямо. «Unavailable» не означает, что инструментов не вызывали. Повторный запрос может обновить сведения, но не восстанавливает данные, которых источник никогда не зарегистрировал.

Сведения передаются под ключом Project. При открытии записи сверяйте execution и компьютер: идентичное имя команды в соседнем чате не делает события одним вызовом. После handoff у одной Task законно несколько executions со своей историей.

Как читать доказательства#

Request означает зарегистрированное намерение вызвать инструмент. Reported result означает исход, который сообщил native источник. Refusal означает решение остановить действие. Gap прямо отмечает, что часть источника отсутствует или не может быть надёжно приписана вызову.

Запись success может быть правдивой относительно инструмента: например, команда завершилась с кодом ноль. Однако она не доказывает, что приложение ведёт себя правильно, файл содержит нужное изменение или внешний сервер принял публикацию. Проверять нужно утверждение целиком.

Verified filesystem change требует отдельного наблюдения с repository identity, revision и content hash. Текущий публичный runtime не создаёт универсальную цепочку подтверждённых изменений и downstream impact для каждого вызова. Поэтому нельзя обещать, что любой edit в Runtime уже независимо проверен.

Отказ как часть истории#

Для поддерживаемых Claude Code и Codex native calls отказ может сохранять идентичность вызова, применённое правило и policy revision. Это позволяет увидеть, почему остановился конкретный шаг. Сырые аргументы и полный вывод для этого не нужны в content-free journal.

Если источник не даёт надёжный native call ID, приложение не должно придумывать его и приписывать решение случайному вызову. Это одна из причин, почему покрытие провайдеров различается.

Сравнивая отказ с Governance, смотрите ревизию на момент действия. Сегодняшняя policy не обязательно та же, которая действовала вчера. Неприменённое изменение с телефона также не переписывает исторический отказ задним числом.

Knowledge и решения#

Knowledge хранит понятный контекст проекта: явно записанные решения, факты из capsules и доступные записи Engine Memory. Это иной слой, чем необработанная история сообщений.

Новое решение может заменить прежнее через связь supersedes, сохранив историю исправления. Телефон ждёт подтверждение компьютера, прежде чем показывать, что запись сохранена. Заголовок чата или произвольная реплика агента не становится verified decision автоматически.

В GrantTap Lab полезно записать явное решение: «Учебные данные остаются локальными; публикация не входит в задачу». Позже его можно уточнить, не выдавая старую формулировку за актуальную. Если ответ на запись потерян, сначала проверьте существующий record; слепое повторение создаёт ненужную неоднозначность.

Практическая проверка результата#

Для обычной задачи пройдите короткий путь: прочитайте сообщение агента, откройте Files, посмотрите доступный diff и результаты проверок, затем сопоставьте их с правильной execution. Не путайте запрошенную правку с реально доступным содержимым.

Для проблем отправки идите в Message delivery, где этапы относятся к исходному сообщению. Runtime агента и relay receipt отвечают на разные вопросы. Для передачи задачи — в handoff, где подтверждается destination receipt.

Если доказательство отсутствует, оставляйте вывод открытым: «результат сообщён, отдельно не подтверждён». Это полезнее, чем зелёная галочка, которую невозможно связать с конкретной работой.