WEB board

P0: клиентская синхронизация затирает СЕРВЕРНЫЕ метаданные источника целиком (конспект, статистика) и откатывает updatedAt

НАСТОЯЩИЙ корень регресса Франкенштейна, найден по owner-бенчмарку 06.08 12:23-12:29. Цепочка доказательств: (1) 10:59 я записал конспект для источника cmsayu5p90025rmyy7sszom8p и ПРОВЕРИЛ в базе — ключи documentOutline/Status/Fingerprint на месте, updatedAt = 2026-08-06T10:59:12. (2) 12:22:43 owner задаёт широкий вопрос — журнал: scope pending, reason MISSING, ответ 4 цитаты. То есть конспекта уже нет. (3) 12:23:36 повтор — reason BUILDING (пересборка, ещё 20 платных вызовов). (4) 12:29:34 — scope READY, 19 секций, 19 с доказательствами, ответ 27 цитат. (5) СЕЙЧАС в базе у этого источника снова НЕТ ключей конспекта, а updatedAt = 2026-08-01 23:09:14 — то есть строка ОТКАЧЕНА к состоянию пятидневной давности. КОРЕНЬ В КОДЕ: src/app/api/sync/route.ts:1009-1046, mapIncomingSourceRow — sourceMetadata собирается как { ...incomingMetadata } (ЧИСТО клиентские метаданные, БЕЗ слияния с серверной строкой) и пишется целиком, плюс updatedAt берётся из клиентского payload (:1054). Значит любая вкладка со старым снимком тетради при синхронизации СТИРАЕТ все серверные ключи: конспект, а также вероятно nerFingerprint/citationCount/referencedChunkCount/entities и статистику. ЭТО ОБЪЯСНЯЕТ, почему WEB-260 (запись конспекта) починен, а эффекта нет: запись доходит и тут же затирается. ПОЧИНИТЬ: (а) метаданные источника при синхронизации СЛИВАТЬ — клиент владеет только своими полями (readOnly и т.п.), серверные ключи (documentOutline*, ner*, citationCount, referencedChunkCount, entities, stats, processing) клиент перезаписывать НЕ может; составить явный список серверных ключей и защитить их; (б) updatedAt из клиентского payload НЕ принимать для строк, которые сервер обновлял позже (или не принимать вовсе — сервер сам знает время записи); (в) тест: строка с серверными ключами + входящая синхронизация со старым снимком БЕЗ этих ключей → серверные ключи на месте, updatedAt не откатился; положительный контроль — клиентское поле readOnly действительно применяется.

Записать конспект серверно → открыть тетрадь в старой вкладке (или дождаться фоновой синхронизации) → ключи конспекта исчезают, updatedAt откатывается

Серверные ключи метаданных переживают клиентскую синхронизацию; updatedAt не уезжает назад; клиентские поля по-прежнему применяются

Журнал прода 12:22:43 reason=missing / 12:23:36 reason=building / 12:29:34 scope=ready; база: updatedAt откатился с 2026-08-06T10:59 на 2026-08-01T23:09, ключи конспекта исчезли; код sync/route.ts:1009-1046,1054

v4-dc699c5

v4-7722b05

ПРИНЯТО МНОЙ. Доказательство: после посадки фикса запись конспекта в прод-базе ПЕРЕЖИВАЕТ клиентскую синхронизацию — count(*) WHERE metadata ? documentOutline = 1 спустя час (до фикса было 0 по всей таблице, а updatedAt откатывался на пять дней назад). Плюс 35 тестов с положительными контролями.