# Как устроен MMW

> Записи, рабочие области, проекты, ключи и статусы — общая картина того, что происходит с фактом после remember.

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

1. из чего состоит память MMW — записи, рабочие области, проекты и ключи;
2. что означают статусы `unverified`, `stale` и `conflict` и почему статуса «проверено» нет;
3. что происходит на сервере между вызовом `remember` и моментом, когда запись находит `search`.

Сквозной пример: в проекте `backend` агент сохранил факт «staging выкатывается через systemd-юнит `app-staging`», сославшись на документ `docs/deploy.md`. Потом документ поменяли.

## Общая схема

```text
  Ваш ассистент                      Сервер MMW
  (Claude, Cursor, Codex, ChatGPT)
        │
        │  MCP по HTTP, ключ mmw_…  ─────────►  Аккаунт
        │  (напрямую или через                    └─ Проект (ключ привязан к проекту)
        │   локальный mmw-agent)                      └─ Рабочая область (workspace)
        │                                                └─ Записи
        │                                                     ├─ content, fact_key
        │  remember(content, ...)                             ├─ source_id / source_hash
        │  ───────────────────────────►  Memory Guard          ├─ status
        │                                → запись              ├─ derived_from
        │                                → архивариус          └─ связи графа
        │  search(query)
        │  ───────────────────────────►  записи + источник + статус
        ◄──────────────────────────────
```

## Записи

Запись — один факт, решение или договорённость. Главное поле — `content` (текст). Остальное необязательно, но делает память полезнее:

| Поле | Зачем |
|---|---|
| `fact_key` | Ключ темы, например `deploy-staging`. Записи с одним ключом сравниваются между собой. |
| `source_id`, `source_hash`, `source_revision` | Откуда взят факт: документ, файл, сессия — и хеш его содержимого. |
| `confidence` | Уверенность от 0 до 1, по умолчанию 0,5. |
| `derived_from` | ID записей, которые эта запись обобщает (до 50). |
| `scope` | Ярлык для фильтра (`shared`, `private`). Доступ он не ограничивает. |

`remember` никогда не удаляет и не перезаписывает записи. Если сохранить факт с тем же `fact_key` ещё раз, появится более новая версия, а старые останутся и будут помечены. Удаление — только явным вызовом `forget`, и оно мягкое: запись уходит из поиска вместе со связями графа, а факт удаления сохраняется для аудита.

## Рабочие области, проекты и ключи

- **Аккаунт** делится на **проекты**, проект — на **рабочие области** (`workspace`).
- Рабочая область по умолчанию называется `default` и создаётся при первой записи. Используйте отдельные области, чтобы не смешивать темы, например `backend` и `personal`.
- **Ключ** можно привязать к проекту: агент с таким ключом видит только этот проект. Удобно выдавать отдельный ключ на каждый проект или каждый компьютер.
- Аккаунты, проекты и рабочие области изолированы друг от друга. В организации поверх этого действуют правила видимости записей — см. [Видимость](/organizations/visibility/).

## Статусы

| Статус | Когда появляется | Что делать агенту |
|---|---|---|
| `unverified` | Всегда у новой записи. | Использовать как сведения с указанием источника. |
| `stale` | Источник изменился: в `search` или `validate_memory` передан другой `current_source_hash`. | Перечитать источник и сохранить актуальный факт. |
| `conflict` | Есть записи с тем же `fact_key`, но разным содержимым. | Показать человеку расхождение, не выбирать молча. |

Статуса «проверено» (`verified`) нет. `source_hash` — это сведения о происхождении, а не доказательство: клиент может прислать любой хеш, поэтому сервер не считает запись подтверждённой.

В примере: после правки `docs/deploy.md` агент вызывает `validate_memory` с `source_id="docs/deploy.md"` и новым хешем. В отчёте старая запись окажется среди устаревших, а в `search` с тем же хешем получит статус `stale`. Подробнее — [Источник и свежесть](/memory/source-and-freshness/).

## Сводки и derived_from

Агент может сжать несколько записей в одну сводку и передать их ID в `derived_from`. Сводка **наследует** статусы источников: если одна из исходных записей в конфликте или устарела, сводка тоже получит `conflict` или `stale`. Так обобщение не прячет нерешённые расхождения. Подробнее — [Конфликты и сводки](/memory/conflicts-and-summaries/).

## Что происходит после remember

1. **Проверки.** Пустой или слишком длинный `content`, `source_hash` без `source_id`, `confidence` вне 0..1, больше 50 ID в `derived_from` или несуществующие ID — запрос отклоняется с понятной ошибкой. Проверяется и лимит записей тарифа.
2. **Memory Guard.** Секреты (API-ключи, токены, пароли) в любом поле заменяются заглушками. Запись, похожая на попытку внедрить инструкции в память агента, отклоняется с ошибкой `Memory rejected by Security Guard: …`.
3. **Сохранение.** Запись получает ID и статус `unverified`. Если клиент передал заголовок `X-Idempotency-Key`, повтор того же запроса вернёт ту же запись; тот же ключ с другим содержимым вернёт `409 Conflict`.
4. **Архивариус.** Модель анализирует новую запись: строит связи с недавними записями (они видны в `search` как `graph_relations`) и может пометить старую запись как уточнённую или устаревшую. В организации архивариус работает только с записями, которые видит автор.
5. **Поиск.** `search` ищет по смыслу и ключевым словам и возвращает записи с источником, уверенностью, статусом, `derived_from` и связями.

Если подписка не активна, память недоступна. Когда подписка истекла, на льготный период память переходит в режим только чтения: искать можно, сохранять нельзя.

## Локальный агент

mmw-agent — необязательный посредник на вашем компьютере. Он пересылает все вызовы на сервер, добавляет инструмент `mmw_sync_status` и, только после вашего согласия в терминале (`mmw-agent consent`), загружает историю сессий Claude Code и Codex. Поиск по загруженным сессиям пока не сделан. Подробнее — [Агент mmw-agent](/agent/overview/).

## Что дальше