Конфликты и сводки

Из этой страницы вы узнаете:

когда запись получает статус conflict и почему MMW ничего не перезаписывает молча;
как сделать сводку через derived_from, чтобы она не скрывала противоречий;
как разрешить конфликт.

Пример на всю страницу: в понедельник агент Анны сохранил, что staging выкатывается через systemd-юнит app-staging. В четверг агент Бориса сохранил, что staging теперь выкатывается через Docker Compose. Кто прав — решать людям, а не памяти.

Когда возникает конфликт

Записи сравниваются по fact_key. Если в одной рабочей области есть несколько записей с одинаковым ключом, но разным содержимым или хешем источника, все они получают статус conflict.

  workspace default, fact_key = deploy.staging.method
  ────────────────────────────────────────────────────────────────
  A  пн  «через systemd-юнит app-staging»          → conflict
  B  чт  «через Docker Compose, сервис staging»    → conflict

Ничего не перезаписывается. remember всегда добавляет новую запись, даже с тем же ключом. Старая версия остаётся и помечается.
Конфликт виден обеим сторонам. Помечается не только старая, но и новая запись: сервер не знает, какая из них верна.
Новейшая версия — первой. В search самая новая запись с этим ключом стоит выше старых, даже если старая совпадает с запросом лучше. Если запросу соответствует только старая версия, новая подтягивается в выдачу рядом с ней. У старых версий поле superseded_by содержит ID новейшей.
Одинаковый текст — не конфликт. Если та же формулировка сохранена повторно с тем же хешем источника, расхождения нет.
Тот же текст с новым хешем — конфликт. Если документ изменился и вы пересохранили факт с новым source_hash, не удалив старый, версии разойдутся по хешу. Сначала удалите старое — см. Источник и свежесть.
Границы. Сравниваются только записи одной рабочей области, которые вы можете видеть. Записи без fact_key в конфликт не попадают.

Что видит агент

[
  {
    "id": "b3e1…",
    "content": "staging выкатывается через Docker Compose, сервис staging",
    "fact_key": "deploy.staging.method",
    "status": "conflict",
    "created_at": "2026-10-08T14:03:00+00:00"
  },
  {
    "id": "a7d2…",
    "content": "staging выкатывается через systemd-юнит app-staging",
    "fact_key": "deploy.staging.method",
    "status": "conflict",
    "superseded_by": "b3e1…",
    "created_at": "2026-10-05T09:12:00+00:00"
  }
]

Новейшая версия — это подсказка, а не вердикт. Если новую запись сохранили как исправление, это видно по superseded_by; если нет уверенности, правильная реакция агента — не выбирать вариант по дате, а сказать человеку: «В памяти два противоречащих факта о выкатке staging: от 5 и от 8 октября. Какой актуален?»

Сводки: derived_from

Со временем записей становится много, и агент сжимает их в сводку. Чтобы сводка не стала «чистой» версией с потерянными противоречиями, передайте ID исходных записей в derived_from:

{
  "content": "Итоги недели по деплою: staging переводится на Docker Compose; миграции запускаются make migrate до выкатки",
  "fact_key": "deploy.weekly-summary.2026-w41",
  "derived_from": ["a7d2…", "b3e1…", "c9f0…"]
}

в derived_from — до 50 ID, и только существующих записей, которые вы видите; иначе ошибка derived_from contains unknown memory ids;
в результатах search у сводки есть поле derived_from со списком источников;
сводка наследует худший статус своих источников: если хоть один из них в conflict или stale, сводка тоже. Наследование проходит до трёх уровней (сводка сводок тоже видит проблему).

В нашем примере сводка получит статус conflict, хотя её собственный текст ни с чем не спорит: противоречие в её основе не решено.

Как разрешить конфликт

Выясните, какая версия верна. Спросите человека или перечитайте источник. Не решайте по дате: более новая запись не обязательно правильная.
Удалите неверную версию через forget по её ID:
forget
```
{ "memory_id": "a7d2…", "workspace": "default" }
```
Удаление мягкое: запись пропадает из поиска и графа, факт удаления остаётся для аудита.
Проверьте результат. В следующем search запись B уже unverified: у ключа осталась одна версия.
Обновите сводку при необходимости. Удалённые источники больше не влияют на статус сводки, поэтому, если у остальных источников всё в порядке, она тоже станет unverified. Но её текст мог опираться на неверную версию — если так, сохраните новую сводку и удалите старую.

Конфликт и архивариус

Архивариус работает рядом, но иначе. Он может заметить, что новая запись опровергает одну из недавних, даже без общего fact_key, — и пометить старую как stale, понизив её уверенность. Ничего при этом не удаляется. Конфликт по fact_key — строгое правило сервера, а отметки архивариуса — оценка модели.

Что дальше

Правила для агентов Как называть fact_key, чтобы конфликты были полезными.

Архивариус Связи и отметки устаревания, которые ставит модель.

Справочник search Все поля ответа, включая derived_from.