E2E-стенд Path 3 с рабочей SQLite

Инструмент живого E2E-тестирования SQLite для Path 3 доказывает, что Gateway использует SQLite как каноническое хранилище сеансов и транскриптов, а устаревшие файлы JSONL остаются входными данными для миграции или архивными материалами. Это инструмент проверки для сопровождающих, а не обычное средство диагностики для пользователей.

После того как Gateway обработал трафик после миграции, соответствие устаревшим JSONL больше не является допустимым показателем работоспособности среды выполнения. У исправного мигрированного Gateway количество строк транскриптов SQLite может отличаться от количества записей в устаревших JSONL, поскольку новые ходы должны добавляться только в SQLite. Поэтому инструмент живого тестирования должен на каждом шаге измерять поведение Gateway, изменение строк SQLite, отсутствие активности устаревших файлов и состояние журналов.

Формат команды

Предполагаемая команда для живой проверки:

node scripts/path3-live-sqlite-e2e.mjs \  --url http://127.0.0.1:18789 \  --agent main \  --session-key agent:main:path3-live-e2e:<timestamp> \  --json

Команда подключается к уже запущенному Gateway. Она не запускает, не останавливает, не импортирует и не выполняет миграцию повторно, если явный режим миграции не будет добавлен позже. Вариант для CI или изолированной локальной среды может использовать test/helpers/openclaw-test-instance.ts, но путь живой проверки должен исследовать фактический операторский Gateway и его реальную базу данных SQLite для каждого агента.

Изолированная проверка собранного CLI

Средство проверки собранного CLI заполняет изолированное устаревшее хранилище сеансов, запускает пересобранный Gateway и доказывает, что при запуске активные устаревшие сеансы импортируются в SQLite до начала чтения средой выполнения. Оно не должно запускать openclaw doctor --fix до первого запуска Gateway, поскольку это доказывало бы работу ручного пути миграции, а не пути обновления, который получают пользователи при первой загрузке после переключения.

После импорта при запуске изолированная проверка может выполнить openclaw doctor --session-sqlite inspect и openclaw doctor --session-sqlite validate для получения диагностических данных. Эти команды doctor не являются механизмом миграции для проверки обновления при запуске. Отдельные сценарии импорта через doctor должны создавать устаревшие файлы транскриптов вместе с сопутствующими файлами траекторий и проверять, что doctor архивирует эти артефакты, а SQLite остаётся каноническим хранилищем.

Предварительная проверка

Предварительная проверка собирает исходные данные и завершается ошибкой до отправки проверочного хода, если Gateway непригоден для использования:

• GET /health и подробный статус Gateway должны сообщать о запущенном и доступном Gateway.
• Версии CLI и Gateway должны соответствовать тестируемой ветке.
• Инструмент сохраняет позицию в активном файловом журнале Gateway.
• Инструмент сохраняет количество строк таблиц SQLite для каждого агента: sessions, session_entries, transcript_events, transcript_event_identities и session_routes.
• Инструмент сохраняет mtime, size и сведения о наличии устаревших sessions.json, указанных файлов JSONL и возможных путей JSONL проверочного сеанса.
• lsof -p <gateway-pid> должен показывать дескрипторы SQLite DB/WAL/SHM и отсутствие активных дескрипторов .jsonl или sessions.json.

openclaw doctor --session-sqlite validate в живом режиме служит только для информации. После трафика, поступившего после переключения, он может сообщать об ожидаемом расхождении с устаревшими файлами. Инструмент должен использовать вывод doctor для классификации и инвентаризации миграции, а не как критерий успешности среды выполнения.

Сценарий под управлением агента

Живой сценарий использует отдельный ключ проверочного сеанса и по возможности управляет Gateway через общедоступные пути RPC. Одного хода агента должно быть достаточно для проверки обычного сохранения данных, но полная проверка должна охватывать точки интеграции 3.1b, которые ранее требовали отдельных живых проверок:

• Обычный ход чата: создать или повторно использовать проверочный сеанс, отправить настоящий запрос агенту, дождаться окончательного результата ассистента и проверить chat.history или эквивалентную проекцию Gateway.
• Идентичность транскрипта: проверить, что один и тот же маркер присутствует в истории Gateway и в строках транскрипта SQLite, включая строки со стабильными идентификаторами событий, если они имеются.
• Средства доступа к метаданным сеансов: прочитать проверочный сеанс и выбранные существующие активные сеансы через средства доступа Gateway/сеансов и сопоставить их со строками SQLite.
• Проекция изменения сеанса: применить обратимое изменение модели или метаданных сеанса к проверочному сеансу, затем проверить соответствие спроецированной строки и ответа Gateway.
• Жизненный цикл контрольной точки Compaction: вывести список контрольных точек, создать ответвление и восстановить контрольную точку только в проверочном сеансе или синтетическом тестовом сеансе, созданном инструментом.
• Восстановление после перезапуска: выполнить безопасный путь с маркером восстановления для контролируемого проверочного сеанса или изолированного тестового экземпляра; в живом режиме этот шаг можно выполнять, только если целевой набор сеансов задан явно, а изменения обратимы.
• Жизненный цикл очистки: удалить или сбросить проверочный сеанс, затем проверить строки жизненного цикла SQLite и состояние архивированного транскрипта.

Точки интеграции, относящиеся к определённому транспорту и не допускающие безопасной проверки на действующем операторском Gateway, например входящий трафик WhatsApp или голосовых вызовов, следует проверять с помощью проб среды выполнения на уровне владельца по тому же контракту SQLite, а не имитировать внешний транспорт.

Проверки на каждом шаге

На каждом шаге создаются снимки состояния до и после, а также записывается структурированный результат проверки:

• Количество строк SQLite увеличивается только там, где ожидается.
• Количество строк траектории среды выполнения увеличивается для проверочных сеансов с маркерами, в которых записываются события среды выполнения.
• Строка проверочного сеанса содержит ожидаемые session_id, состояние, временные метки, метаданные и строки маршрута.
• Проекция истории/сеанса Gateway соответствует окончанию транскрипта SQLite.
• Файл JSONL проверочного сеанса не создаётся и не изменяется.
• Не создаются сопутствующие файлы проверочного сеанса .trajectory.jsonl, .trajectory-path.json или trajectory/<session>.jsonl, производные от маркера.
• Существующие устаревшие файлы JSONL и sessions.json остаются неизменными, если только шаг явно не является автономной операцией миграции или архивирования.
• Процесс Gateway не открывает дескрипторы .jsonl или sessions.json.
• Журналы после предыдущей позиции не содержат ERROR, FATAL, SQLITE_, no such column, сообщений о недоступности хранилища сеансов, сбоях восстановления после перезапуска или предупреждений о сверке транскриптов, если только сценарий явно не разрешает их.

Проверка журнала входит в контракт успешности. Gateway, который отвечает на проверки работоспособности, но выдаёт ошибки схемы SQLite или повторяющиеся ошибки сверки транскриптов, не считается успешно прошедшим Path 3.

Артефакт с доказательствами

Инструмент должен записывать доказательства в .artifacts/path3-live-e2e/<timestamp>/ и не добавлять их в git:

• summary.json: аргументы команды, версия Gateway, результат, непройденная проверка и пути к артефактам.
• sqlite-before.json и sqlite-after.json: количество строк и выбранные проверочные строки.
• legacy-files.json: наличие устаревшего файла, mtime, размер и сведения о том, изменился ли каждый файл.
• gateway-log-scan.json: диапазон позиций, совпавшие строки журнала и решения о разрешении.
• events.jsonl: упорядоченные наблюдения по каждому шагу, пригодные для комментариев с доказательствами в PR.

В доказательствах для PR следует кратко описывать эти артефакты, а не вставлять полные транскрипты или содержимое личных сообщений.

Правила безопасности

• В живом режиме запрещено повторно импортировать устаревшие JSONL во время работы Gateway.
• В живом режиме запрещено изменять непроверочные сеансы, кроме явно выбранных обратимых диагностических операций восстановления.
• Любой разрушающий или масштабный шаг миграции требует создания новой резервной копии затронутой базы данных SQLite и каталога устаревших сеансов.
• Резервные копии должны ограничиваться затронутой базой данных агента или каталогом сеанса и повторно использоваться в течение одного запуска проверки, чтобы избежать неограниченного роста использования диска.
• После этапа очистки не должно оставаться проверочного сеанса, проверочного JSONL или изменённого устаревшего файла, если вызывающая сторона не передала --keep-artifacts.

Успешный результат

Успешный живой запуск означает, что Gateway принял реальный управляемый агентом поток сеанса, всё наблюдаемое каноническое состояние находилось в SQLite, устаревшие файлы среды выполнения оставались неактивными, а состояние журналов оставалось чистым в течение измеряемого интервала. Это не означает, что после живого трафика сохраняется соответствие устаревшим JSONL; расхождение в живой среде ожидается, когда SQLite становится каноническим хранилищем.