[Learning] Raw triage ignores completed curation and repeats reviewed evidence #84

Проблема

После запроса «проанализируй накопленную БД и проверь, что обработанные задачи отмечены, чтобы не разбирать их повторно» workflow самообучения не даёт единого завершения и инкрементального возобновления. Сырые события, triage runs и структурированные эпизоды имеют разные состояния; успешный run не означает, что задачи обработаны.

Окружение и workflow

• WebDev Agent Kit v1.8.0, установленная исходная ревизия ada52938b678507f7ad9ce7c13309594ea5e1e13.
• Codex в VS Code, Windows / PowerShell; версия расширения неизвестна. Модель: GPT-6, точная версия и effort не раскрыты runtime.
• Host stack: React, TypeScript, Vite; проблема относится к Kit, а не приложению.
• Навык: agent-self-improvement. Доступны локальные Python CLI и SQLite. Для публикации — GitHub connector для чтения и существующий gh CLI для создания issue.
• Тип evidence: наблюдаемый запуск и чтение установленного Python-кода. Приватная БД и диалоги не прилагаются.

Ожидание

Явный ручной запуск должен различать новый, уже разобранный и частично разобранный материал. После curation должна быть проверяемая отметка с точными source event IDs, чтобы следующий разбор брал только новые/изменившиеся данные. Обработанный эпизод, кандидатный урок и проверенное/установленное правило — разные состояния; не нужен ложный статус «модель обучена».

Фактическое поведение и воспроизведение

1. В существующем проекте learning.py status --project ROOT показывал включённую запись и накопленные события, но learning_memory.py audit --project ROOT ответил Project memory is unbound; run bind first. Причина исходного отсутствия binding не установлена; это наблюдение конфигурации, не доказанный дефект onboarding.
2. learning.py run --project ROOT создал run с needs_review. В run_triage() запрос выбирает все события данного проекта с kind='user_correction', без проверки memory_records, curation_state или ранее обработанных source IDs. Далее добавляется запись в runs; curation state не обновляется.
3. После отдельного bind и ручной подготовки структурированных records удалось выполнить record/check/audit и получить lesson_created/no_lesson. Прямое чтение SQLite подтвердило статусы и связи с источниками. Повторный импорт того же пакета вернул inserted: 0 — idempotency записи уже работает.
4. Однако эта idempotency не делает сырой run инкрементальным: его SELECT не учитывает сохранённый разбор. Повторное исполнение после curation не запускалось; повторный выбор следует из прочитанного запроса.

Дополнительные затруднения процесса

• Записанная пользовательская поправка может иметь kind user, а deterministic run рассматривает только user_correction. Это ограничение текущего алгоритма, не доказательство потери данных.
• В context есть усечённые tool outputs и фрагменты base64 изображений. Большие CLI-выводы дополнительно усекались, а часть технических фрагментов была просмотрена выборочно. Поэтому review честно сохранён как partial; полнота диалога и качество причинных выводов не доказаны.
• Во время ручного формирования JSON через PowerShell stdin потерялись кириллические поисковые алиасы. Ошибка агента/транспорта была обнаружена чтением из SQLite и исправлена новой ревизией с проверкой Unicode. Не утверждается, что SQLite или record CLI портят UTF-8.
• Для безопасного продолжения пришлось вручную создать локальный learning profile/checkpoint и changelog. Общие skills и Python CLI не изменялись.

Предлагаемые критерии решения

• Один понятный workflow для pending → review → record → audit, с проверяемой границей входного набора; события, поступившие во время анализа, остаются pending.
• Pending-выборка учитывает актуальные ревизии эпизодов и source event IDs. Повторный запуск без новых данных не предлагает те же задачи заново; явный re-review сохраняет историю.
• CLI явно сообщает разницу между raw triage и завершённой curation, включая partial coverage и кандидатов, не прошедших проверку.
• Безопасный UTF-8 путь формирования/импорта структурированных данных и readback-проверка; ограниченный вывод context без сырых изображений и с видимыми маркерами неполноты.
• Никакого автоматического повышения кандидатов, изменения skills, network sync или включения capture как побочного эффекта.

Проверки, ограничения и связанные задачи

В текущем разборе выполнены status, sessions, run, bind, context, record, check, audit, recall и прямые read-only SQLite-запросы. Integrity — ok, повторная запись идемпотентна; audit оставил предупреждения для неподтверждённых кандидатов. Новый независимый benchmark и тест изменения CLI не запускались; публичного fixture нет. Воспроизводимость подтверждена для установленной v1.8.0 и прочитанного SQL, а не для всех версий.

Связанные закрытые задачи: #78 (структурированная память) и #81 (адаптация/capture). Это отдельный оставшийся разрыв между triage, curation и повторным запуском в v1.8.0, а не просьба повторно реализовать обмен памятью или hooks.

Поиск открытых и закрытых issues выполнен по learning и curation. Публичный текст проверен: нет приватного кода, абсолютных пользовательских путей, ID локальных сессий, credentials, содержимого БД или сырых диалогов.