letopis 1.1.0 → 1.2.0

package/CHANGELOG.md

@@ -2,6 +2,583 @@
 
 Формат: [Keep a Changelog](https://keepachangelog.com/), версии — semver.
 
+## [1.2.0] — 2026-10-28
+
+letopis 1.2 по плану `reports/PLAN-LETOPIS-1.1.md` (редакция 5, этапы 4–6 и контрольная точка Б) и плану доработок
+после точки Б: проекторы из журнала, агрегаты в базе, инструменты MCP; ревью безопасности №2 и №3. Версия `1.2.0` (во
+время работы — `1.2.0-alpha.0`, не публиковалась). Схема 1.1.0 обновляется повторным `up()`: ревизия движка прежняя
+(6), функции накатываются заново. Первый `up()` строит индекс журнала `log_class_tenant_at (class, tenant, at)` вместо
+`log_class_at`, и пока индекс строится, запись в журнал ждёт: на большой установке постройте его заранее
+(`create index concurrently`, README, «Обновление пакета и схемы»). Обновление схемы 1.1.0 с данными проверено разовым
+прогоном (установка пакетом 1.1.0, `up()` 1.2, вход, чтение, запись, ужесточение, `purge` удалённого в 1.1,
+`maintain()`, `verify({ data: true })`); в набор тестов оно не входит.
+
+### Added — этап 4а (проекторы)
+- `db.projector(имя, { from, into, version, handle, withBefore, onExpired, batch, pollMs })` — проектор из журнала
+  (`lib/src/project.ts`): строит строки производных классов из изменений классов-источников. `run()` догоняет
+  журнал и следует за ним до `stop()`, `run({ once: true })` только догоняет; `rebuild()` и `rebuild({ chunked: true })`
+  перестраивают проекцию с текущего состояния; `status()` отдаёт состояние, версию, курсор и отставание; `close()`
+  останавливает проектор и отписывает его от сигналов. Каждая пачка — одна транзакция: блокировка проектора,
+  чекпоинт, изменения журнала, `handle(changes, out)`, запись результатов и сдвиг курсора. Каждое изменение
+  применяется ровно один раз, писатель у проектора один. Только на администраторском подключении (иначе
+  `admin_required`).
+- Опция класса `derivedBy: 'имя-проектора'`: строки класса пишет только этот проектор. Опция наследуется, потомок её
+  не меняет; концы производного класса — только `onDelete: 'cascade'` или `'unset'`; системный класс производным не
+  бывает; концы других классов на производный класс не ведут. Опцию показывают реестр, `db.describe()` и
+  `describeText()`.
+- Функции базы `lib/sql/88-derived.sql` (только для роли владельца): `projector_state` (чекпоинт — строка `secret`
+  вида `PROJECTOR`), `projector_advance` (сдвиг чекпоинта, только если курсор не изменился), `derived_split`,
+  `derived_id`, `derived_apply` (запись результатов пачки: `upsert`, `inc`, `delete`), `derived_clear` (удаление
+  строк проектора перед перестройкой).
+- Код ошибки базы `LT021` `derived_class`: строку производного класса пишет, правит или удаляет не его проектор,
+  либо конец ведёт на такую строку.
+- Коды библиотеки `rebuild_required` (проекция построена другой версией проектора) и `projector_busy` (перестройку
+  не начать: проектор сейчас работает в другом процессе).
+- Зарезервированное имя корня `projector`; типы `Projector`, `ProjectorOptions`, `ProjectorChange`, `ProjectorOut`,
+  `ProjectorRow`, `ProjectorReport`, `ProjectorStatus`.
+
+### Changed — этап 4а
+- Функции кредов (`auth_credentials`, `auth_revoke_credential`, `auth_set_flags`) не видят вид `PROJECTOR`, а
+  `auth_kind_ok` не принимает его как вид кредов.
+- `targets_bad` отличает производную цель: возвращает `!роль`, и триггеры записи, `check_links` и проверка базы в
+  загрузчике отвечают `derived_class`, а не `target_not_found`.
+- Загрузчик (`db.load()` и первая заливка) отклоняет строки производных классов и ссылки на их строки —
+  `derived_class` в отчёте.
+- `restore`, `reclass`, `rekey` и `rekeyClass` строк производного класса — `derived_class`.
+- Ревью коммита: проектор работает с арендаторами, у которых каждый класс `into` помечен его `derivedBy`, и
+  пропускает изменения остальных — одноимённый класс без пометки у другого арендатора больше не останавливает его для
+  всех; класс System, который становится производным, сверяется со ссылками всех арендаторов; описание со ссылкой и
+  пометка `derivedBy` идут под блокировками семейства и не проходят параллельно мимо друг друга; источники и
+  результаты проектора — свои у каждого арендатора: имя класса одного арендатора не меняет набор источников другого.
+- Правка `derivedBy` в описании класса — не безопасное изменение (`class_change_safe`): её проверяют как ужесточение.
+
+### Tests — этап 4а
+- `projector` (план 1.1, §7.5 №1–11 и гонка №19 §7.8): догонка 10 000 изменений, ровно один раз при обрыве
+  посреди пачки, один писатель, долгая пишущая транзакция, транзакция на границе снимка перестройки, запрет записи
+  в производные классы и ссылок на них, границы `out`, перестройка атомарная и пачками во время записи источника,
+  `purge` источника служебным изменением, отставание старше яруса `all` (`cursor_expired`, `onExpired: 'rebuild'`,
+  молчащий проектор не истекает), функции кредов; версия, имя, администраторское подключение, повторный `up()`;
+  два процесса одного проектора при параллельной записи источника.
+- `engine-attacks` №33–34 (план 1.1, §7.7): запись в производный класс и ссылка на него — `derived_class`, описание
+  класса со ссылкой на производный отклонено; чекпоинт проектора через функции кредов — строк нет в ответах,
+  изменить его нельзя.
+- `scenario-salon`: матрица покрытия API исключает `projector` — его проверяет набор `projector`.
+- `initial-load` 7.4 №5: загрузка стартует после вставки транзакции `early`, как `holdRow` в `write-races`. В CI
+  загрузка иногда брала блокировку первой и проходила по пустой таблице без `not_empty`. `lt()` сообщает
+  «ожидалась ошибка X, а операция прошла», если операция не бросила, вместо `TypeError` на `null`.
+
+### Added — этап 4б (агрегаты в базе)
+- Опция класса `aggregate: { поле: { sum: 'поле' | count: true, of: 'Класс', via: 'роль', where?: JSON Schema } }`:
+  поле держит сама база — сумма поля или число живых строк класса-источника (с потомками) того же арендатора, чей
+  одиночный конец `via` ведёт на строку и чьи данные проходят `where`. Строка System в агрегат не входит. Опция
+  наследуется, потомок заменяет её целиком; её показывают реестр (`ClassInfo.aggregate`), `db.describe()` и
+  `describeText()`; в `letopis/model` — `ClassDef.aggregate` и тип `AggregateDef`, экспорт типа `AggregateInfo`.
+- Триггеры `entity_total_ai`, `entity_total_au`, `entity_total_ad` (`lib/sql/88-derived.sql`): после оператора, с
+  переходными таблицами, без условия `WHEN` — срабатывают и для владельца (каскад удаления, `restore`, `reclass`,
+  `rekey`, удаление аккаунта, загрузчик), `enable always`. Вклады строк оператора складываются по цели, цели
+  блокируются в порядке id, итог проверяет описание класса цели (`minimum: 0` → `invalid_data`), версия цели —
+  `sys_update` с автором и причиной операции. Новая цель оператора (вставка, `restore`, смена класса) считается
+  целиком из живых источников в ту же версию. Перенос строки (`move_row`) копит вклады до своего конца и применяет их
+  одним итогом — промежуточная сумма не выходит за правило класса.
+- Проверки описания агрегата (`invalid_class`): поле есть в схеме, числовое и не в ключе; ровно одно из `sum` и
+  `count`; конец `via` источника одиночный и принимает класс цели; поле `sum` — число; нет цикла агрегатов; цель и
+  источник не системные и не производные; агрегат арендатора не считает классы System. Источник, описанный после
+  цели, сверяется при появлении; его класс получает метку `resolved.aggregatedBy`.
+- `db.rebuildAggregates(класс)` — ремонт: поле класса и его потомков во всех арендаторах заново из живых источников
+  под исключительными блокировками, версия только у исправленных; возвращает их число. Только администраторское
+  подключение (иначе `admin_required`); функция владельца `rebuild_aggregates`. Зарезервированное имя корня
+  `rebuildAggregates`.
+- `verify({ data: true })` сообщает расхождения агрегатов: `{ id, class, field, stored, expected, problem }`.
+- Код ошибки базы `LT022` `aggregate_field`: приложение передало или изменило агрегатное поле.
+
+### Changed — этап 4б
+- Агрегатное поле пишет только база: `trg_entity_bi` отклоняет переданное значение и ставит 0 до умолчаний и
+  проверки, `trg_entity_bu` отклоняет изменённое, а при замене данных целиком без поля возвращает прежнее значение;
+  `reclass()` и `rekey()` отклоняют его в данных. Библиотека отвечает `aggregate_field` до отправки (`create`,
+  `upsert`, `update`, `reclass`, `rekey`), а `upsert` заменяет данные без агрегатных полей
+  (`excluded.data - поля`).
+- Добавить или изменить агрегат — ужесточение (`class_change_safe`): исключительные блокировки семейства цели и
+  семейств источников, пересчёт поля у всех целей (`class_evolve`), метки источников заново (`agg_mark`).
+- Загрузчик ставит агрегатные поля в 0 (поле посчитает триггер), при `existing: 'update'` сохраняет прежние значения
+  (`agg_keep`) и пишет журнал пачки раньше строк: новая цель получает итог в ту же версию. Первая заливка считает
+  поле функцией `agg_fill` — одним оператором на агрегат до перестройки индексов, в ту же версию в `entity` и `log`.
+- `restore()` и `sys_update` со сменой класса пишут в журнал строку таблицы, а не `returning`: агрегатные поля
+  досчитаны триггером; `sys_create` пишет журнал раньше строки. `reset({ level: 'tenant' })` агрегаты не
+  пересчитывает: строки арендатора уходят вместе с целями.
+- Ревью коммита этапа 4б: агрегат считают функции владельца по всем строкам источника, без прав чтения, и описание с
+  `where` выдавало суммы и счётчики по строкам, которые автору не видны. Теперь строки попадают в агрегат только с
+  ведома того, кто читает их все. Описать или изменить агрегат может только тот, у кого право READ без условий на все
+  строки каждого класса-источника (класс `of` и его потомки) — и свой агрегат, и унаследованный (новый потомок цели,
+  смена `parent`); неизменённый агрегат при правке описания не проверяется. Сделать класс источником (новый класс, смена `parent`, источник после цели) можно только с таким правом
+  на этот класс и его потомков — до правки, по прежним предкам, и после. Иначе `acl_denied` (`class_admit`, а для
+  нового класса и новых предков — `agg_source_admit` в триггерах после оператора и в `class_evolve`). Агрегат класса
+  арендатора считает только классы своего арендатора — везде одинаково (`agg_prepare`, `agg_classes`, `agg_compute`,
+  `agg_apply`, `agg_fill`, `agg_cycle`): класс System с именем `of` его источником не бывает. Поэтому такой агрегат
+  больше не останавливает установку и правку классов System (`agg_source` его пропускает, а не отвечает
+  `invalid_class`), не расходится с `verify` и `rebuildAggregates` и не мешает арендатору править цель.
+
+### Tests — этап 4б
+- `aggregate` (план 1.1, §7.5 №12–16, №18–20 и гонка №18 §7.8): описание агрегата в реестре и его проверки;
+  20 соединений пишут операции одного кошелька; `insert`, `update` и `delete` сырым SQL; каскад, `reclass` (с
+  переносом id и без), `restore` операции, загрузчик, удаление аккаунта; `restore` кошелька после удаления части
+  операций, `rekey` и `reclass` кошелька — одна версия без поправок; агрегат добавлен под параллельной записью;
+  смена описания и параллельные операции; `aggregate_field`; порча владельцем, `verify` и `rebuildAggregates`;
+  строка System.
+- `initial-load` 7.4 №10: первая заливка в схему с агрегатом — итог равен сумме загруженных операций, одна версия,
+  журнал совпадает со строкой, `verify` чист.
+- `roles` №4 и №7: триггерные функции агрегатов приложению не выданы; триггеры `entity_total_*` — `enable always`
+  без условия `WHEN`. `engine-attacks` №19 включает их обратно вместе с остальными. `scenario-salon`: матрица
+  покрытия исключает `rebuildAggregates` — его проверяет набор `aggregate`.
+
+### Added — этап 5 (MCP)
+- Подпуть `letopis/mcp`: `createMcpServer(db, { write, maxRows, maxBytes })` (`lib/src/mcp.ts`) — сервер MCP для
+  одного пользователя letopis. Инструменты: `letopis_model` (модель: классы, поля, `anyOf`/`oneOf`, концы, ключи,
+  алиасы, метаданные; с `class` — один класс), `letopis_query` (чтение JSON-цепочкой: старт `class` и `filter`, `id`
+  или `ids`, `steps` по ролям и классам, `asOf`, `withDeleted`, `sort`, `limit`, `cursor`; терминалы `rows`, `first`,
+  `ids`, `count`, `sum`, `avg`, `min`, `max`, `countBy`), `letopis_history` (`versions`, `diff`, `blame`) и при
+  `write: true` — `letopis_write` (`create`, `update`, `upsert`, `delete`). Цепочка собирается вызовами API, без
+  `eval` и без SQL; операторы фильтра JSON (`$ne`, `$gt`, `$gte`, `$lt`, `$lte`, `$between`, `$in`, `$like`, `$ilike`,
+  `$starts`, `$ends`, `$has`, `$hasAny`, `$hasAll`, `$exists`, `$isNull`, `$not`, `$or`) — фабрики `ops.ts`.
+- Ответ — `structuredContent` и его текстовый дубль: не больше `maxRows` строк (100) и `maxBytes` байт (50 000),
+  дальше — свой курсор `cursor` (сортировка и значение последней строки; без `sort` — по `id`). Всё, что пришло из
+  базы, в тексте — внутри `<untrusted-data-…>` со случайным суффиксом и пояснением; описания инструментов и
+  `instructions` — постоянный текст пакета, `meta` классов — только в результатах. Неизвестный класс, роль, параметр,
+  оператор — `isError` с подсказкой похожих имён (расстояние Левенштейна по классам, алиасам и ролям реестра).
+- Запись через MCP: `update` — только с `rev`; `delete` без `confirm` — превью и код операции, с `confirm` —
+  подтверждение человека через elicitation (ревизия 2025 — запрос клиенту, 2026-07-28 — `input_required` с
+  подписанным `requestState`), привязанное к хэшу операции; превью и удаление — одной транзакцией. Причина каждой
+  записи — `mcp: letopis_write`.
+- Команда `letopis mcp` (stdio): `--dsn`, `--schema`, `--token` или `LETOPIS_DSN`, `LETOPIS_SCHEMA`, `LETOPIS_TOKEN`;
+  `--write`; только токен сессии пользователя. Сервер — `serveStdio` SDK: ревизию протокола выбирает клиент.
+- Необязательная peer-зависимость `@modelcontextprotocol/server` ^2.4.0 (dev — вместе с `@modelcontextprotocol/client`
+  для тестов): основная точка входа и CLI её не загружают, `letopis/mcp` грузит её динамическим `import()`; нет
+  пакета — ошибка с командой установки.
+- Коды библиотеки: `user_session_required` — `createMcpServer` без сессии пользователя или от корня сервиса без
+  `as()`, `letopis mcp` с ключом сервиса или без токена; `confirmation_required` — удаление через MCP без подтверждения
+  человека.
+
+### Changed — этап 5
+- `createMcpServer` отклоняет подключение в обход RLS (`bypass_rls`): признак — внутренний модуль `lib/src/internal.ts`
+  (фасад → свойства подключения; `makeDb` регистрирует каждый фасад, в `exports` модуля нет), а не слова вызывающего;
+  корень сервиса без `as()` и подключение без сессии — по `ctx()` базы (`user_session_required`); фасад `db.begin()` —
+  `invalid_query`.
+- CLI: строгий `parseArgs` принимает `--write`; `letopis mcp` подставляет `LETOPIS_*` до проверки `--dsn` и
+  `--schema`, отклоняет `--api-key` (код 2), загружает `mcp.js` и SDK лениво и держит процесс до закрытия stdin.
+  В stdout — только протокол.
+- Отступление от плана: имена SDK 2.4.0 сверены по типам — `McpServer`, `fromJsonSchema`, `InMemoryTransport`,
+  `createMcpHandler`, `serveStdio` (`@modelcontextprotocol/server/stdio`), `inputRequired`/`inputResponse`. В ревизии
+  2026-07-28 подтверждение идёт ответом `input_required` (запрос клиенту `elicitInput` там отключён), поэтому сервер
+  поддерживает оба пути. Обработчик HTTP в ревизии 2025 без состояния возможностей клиента не знает — удаление по нему
+  отклоняется (`confirmation_required`).
+
+### Tests — этап 5
+- `mcp` (план 1.1, §7.6 №1–12): модель и `meta` только в результатах; права — пользователь арендатора A не видит
+  строк и классов B; JSON-цепочка — шаги по ролям и классам, операторы, неизвестный класс, роль, параметр и оператор,
+  зарезервированные имена — `isError` с подсказкой в обёртке; 1000 строк — 100 и курсор, обход всех страниц,
+  сортировка по полю данных, предел байт; строка с текстом-инструкцией и поддельной меткой — внутри обёртки, суффикс
+  меняется; без `write` инструмента записи нет; `update` без `rev` — отказ, чужая версия — `conflict`; удаление —
+  превью, подтверждение человека в ревизиях 2025 и 2026-07-28, отказ человека, код операции от агента, клиент без
+  elicitation; причина в `blame`, `versions`, `diff`; учётные данные — `letopis mcp --api-key` и с токеном сервиса,
+  подключение в обход RLS, корень сервиса, подключение без сессии, `db.begin()`, `svc.as(пользователь)`; схемы
+  инструментов; `index.ts` и `cli.ts` не тянут `mcp.ts` и SDK статически. Дополнительно: `letopis mcp` по stdio
+  (клиент SDK запускает команду, `LETOPIS_*`, `--write`) и обработчик HTTP `createMcpHandler` (ревизии 2025 и
+  2026-07-28, удаление с подтверждением через новый экземпляр сервера на запрос).
+- `engine-attacks` №35 (§7.7): агент через MCP пишет без `write` и удаляет без подтверждения человека — отказ, строка
+  цела.
+- `docs`: сценарий `mcp` README (обе версии) — обработчик HTTP из примера, клиент SDK через `fetch` приложения;
+  `letopis/mcp` в примерах — исходники пакета.
+
+### Changed — этап 6
+- Документация — по проверке понятности (§7.9): агент, видевший только README, решил все пять задач, но угадывал
+  форму ответов. README (обе версии): `diff` и `blame` — пример ответа, форма `from`, `to`, `changes` и `fields`
+  (`path` — массив сегментов, листья по порядку пути, пустые `agent`, `reason`, `before`, `after` опускаются), типы
+  `DiffResult`, `DiffChange`, `BlameResult`, `BlameField` — и в «Экспортах пакета»; сигналы — канал с полным именем
+  схемы (`LISTEN "v2.shop"`), нагрузка по режимам, служебные `session:<16 hex>`, `session:*` и `*`; проекторы — когда
+  `before` равен `null` и когда его нет вовсе, значения `status().state`; MCP — `structuredContent` по терминалам
+  `letopis_query`, отказ (`isError`, `structuredContent.error`), `sort: { field, dir }`, вызов `letopis_write` без
+  `write` — ошибка протокола SDK, проверка обработчика HTTP клиентом SDK без сети (как в тесте `docs`). Шпаргалка
+  (обе версии) — то же коротко.
+- Сверка документации с кодом 1.2 (план 1.1, §5, этап 6, п. 1 и 5). README (обе версии): во введении — производные
+  данные, MCP и `diff`/`blame`, в требованиях — необязательная peer-зависимость `@modelcontextprotocol/server`; `secret`
+  хранит и чекпоинты проекторов; администраторское подключение нужно и проекторам, и `rebuildAggregates`; ревизия
+  движка — 6, а не 5. Новые рецепты: «Баланс агрегатом» (§8) — операция без `inc`, корректировка операцией на разницу
+  под `forUpdate()`; «Дневная выручка» (§12) — проектор со свёрткой по дню из данных продажи и таблица «агрегат или
+  проектор». `describe()` отдаёт `derivedBy` и `aggregate`. MCP: ответы `letopis_model` (краткая модель с
+  `brief: true`, если полная больше `maxBytes`), `letopis_history` и `letopis_write`, концы записи `links`, предел
+  `maxBytes` — по JSON строк (строка больше предела приходит на странице одна), отказ фасаду `db.begin()`
+  (`invalid_query`), код выхода 2 у `letopis mcp` без токена и с `--api-key`. «Справочник API»:
+  типы проекторов, `AggregateInfo` и `AggregateDef`, опции `createMcpServer` с умолчаниями и пределами, флаги и
+  переменные `letopis mcp`, число исправленных строк у `rebuildAggregates`, подраздел «Проектор» (опции, методы,
+  `ProjectorReport`, `ProjectorStatus`, `ProjectorFailure`, `ProjectorChange`, `ProjectorOut`). «Ошибки»:
+  `admin_required` — и у `rebuildAggregates`, `user_session_required` — и без токена, `derived_class` — и у проектора
+  без участников. «Ограничения», «Проекторы»: только администраторское подключение и журнал всех арендаторов в обход
+  RLS, участник без опции `tenants` — любой арендатор с пометкой `derivedBy`, производные строки пишет только проектор,
+  ревизия движка. Сверка нашла и расхождение кода с README: источник с `history: false` проектор принимал молча —
+  исправлено (раздел «Security», Н1, продолжение). Шпаргалка (обе версии): `derivedBy` и `aggregate` в полной форме
+  `hub()`, свёртка дневного итога, право на описание агрегата, `LETOPIS_*`, `maxRows` и `maxBytes`, администраторское
+  подключение у проектора и `rebuildAggregates` (грабли №8).
+- Замеры этапа 6 (план 1.1, §5, этап 6, п. 2): новый `lib/bench/derived.bench.mjs` — цена агрегата при записи (один
+  писатель, 20 писателей одного и разных кошельков, сырой SQL), догонка проектора на 100 тыс. изменений, перестройка
+  атомарная и пачками, задержка подписки во время перестройки, цена триггеров агрегатов у классов без агрегатов;
+  повтор `lib/bench/vs-101.bench.mjs` (четыре прогона — `lib/bench/results/vs-101-1.2.md`). Итог и выводы —
+  `docs/checkpoint-1.2.md`. По замерам README (обе версии): §17 — числа 1.2; горячий счётчик — около 150–190 операций
+  в секунду на объект, а не «тысячи записей» (§5, «Рецепт: баланс агрегатом», «Ограничения»); §12 — скорость
+  проектора задаёт число правок строк, а не изменений (свёртку `inc` в `out` добавила точка Б); в таблице «агрегат или
+  проектор» проектор применяет изменения пачками; «Ограничения» — цена атомарной перестройки
+  и очередь фиксаций с `NOTIFY` у писателей сырым SQL; §2 «Сигналы» — `db.sql` и `db.transaction()` шлют сигналы
+  отложенно, как другие транзакции библиотеки. Шпаргалка (обе версии) — горячий счётчик.
+
+### Security — ревью безопасности №2
+- Н1 (проекторы, отказ в обслуживании между арендаторами). Участником проектора становится любой арендатор, который
+  пометит свои классы его `derivedBy`, а пачка всех арендаторов была одной транзакцией и одним `derived_apply`: ошибка
+  данных одного (например, `DayTotal` с `maximum: 0`) откатывала пачку, курсор стоял, `rebuild()` падал, перестройка
+  пачками успевала стереть производные строки всех и оставалась в `rebuilding`, а `status()` молчал. Теперь
+  (`lib/src/project.ts`: `apply`, `atomic`, `chunked`) пачка делится по арендаторам: `handle` получает изменения одного
+  арендатора, запись его результатов идёт под точкой сохранения. Ошибка данных арендатора — отказ базы при записи его
+  результатов (коды letopis, неверные значения, пределы размера) или отказ `out` по его строке или приращению —
+  откатывает только его группу: арендатор выбывает — `meta.failed[арендатор] = { cursor, code, message }` пишется в
+  чекпоинт в той же транзакции — и пропускается до `rebuild({ tenant: id })`, а остальные записываются. `status()`
+  отдаёт `failed`. Производные строки выбывшего больше не меняются: выбывший в `run()` сохраняет их на момент до
+  пачки с ошибкой, а выбывший посреди перестройки остаётся без них (частично построенные удаляются). Новая опция
+  `rebuild({ tenant })` перестраивает одного арендатора одной транзакцией: удаляет его производные строки, строит их из
+  его текущих строк источников и снимает отметку; снимок перестройки встаёт в чекпоинт (`meta.resync`), и хвост
+  журнала не применяет учтённые изменения второй раз. Полная перестройка начинает всех участников заново. Текст ошибки
+  `derived_apply` называет проектор, арендатора и id строки, а `fromDbError` сохраняет у `ValidationError` текст базы
+  целиком. Опция `tenants` в `ProjectorOptions` — явный список участников. Исключение `handle`, нарушение границ `out`
+  и сбой окружения (взаимная блокировка, отмена запроса, обрыв связи) по-прежнему откатывают пачку целиком: это не
+  данные арендатора, и выводить его из проекции не за что. Тип `ProjectorFailure`.
+- Н1, продолжение: ярус журнала и журнал источников — по арендатору. Тем же путём арендатор останавливал проектор
+  описанием своих классов: предел `cursor_expired` был общим — самый короткий ярус `all` политики хранения источников
+  всех участников, и ярус в одну секунду у классов одного арендатора ронял `run()` для всех (а при
+  `onExpired: 'rebuild'` зацикливал полные перестройки). Теперь ярус — по арендатору (`resolve`, `step`): курсор старше
+  яруса у всех участников — `cursor_expired`, как прежде; у части — выбывают они с кодом `cursor_expired`, а с
+  `onExpired: 'rebuild'` перестраиваются сами, каждый своей транзакцией (`rebuild({ tenant })`). Источник без журнала
+  (`history: false`) проектор принимал молча: изменений такого класса он не видит, и проекция арендатора расходилась с
+  данными. Теперь такой арендатор выбывает с кодом `invalid_class` (и при перестройке, атомарной и пачками), его
+  производных строк нет, а `rebuild({ tenant })` отказывает, пока журнал класса не включат.
+- Н2 (известна с 1.0). Право WRITE на `Class` позволяло сменить у класса `parent` или `alias`, и его строки попадали
+  под правила READ, WRITE и DELETE нового предка или алиаса: план прав берёт для класса имена предков и их алиасы.
+  Теперь `class_admit` при правке, которая меняет `resolved.ancestors`, `alias` или `resolved.derivedBy`, зовёт функцию
+  владельца `class_acl_admit` (`lib/sql/60-write.sql`, по образцу `agg_source_admit`): для самого класса и каждого его
+  потомка своего арендатора `acl_check_data` по READ, WRITE и DELETE должна разрешать без условий, иначе `acl_denied`;
+  потомки класса System у арендаторов пропускаются, как у агрегатов. Проверка идёт после проверок агрегатов. Алиас не
+  совпадает с именем другого класса (в том числе `Class` и системных) и с чужим алиасом арендатора и System —
+  `invalid_class`, и у нового класса тоже. И наоборот: имя класса не совпадает с чужим алиасом арендатора и System
+  (автоматическое ревью коммита `6c66d02`): иначе правило, написанное для нового класса, действовало бы и на строки
+  класса с этим алиасом. `class_acl_admit` — не `security definer`: приложению она не выдана, словарь
+  негативных тестов `roles` №4 не изменился.
+- О1. Чекпоинт проектора искался по виду `PROJECTOR` и имени, без аккаунта. Теперь `projector_state`,
+  `projector_advance` и `status()` берут только строку System. Накат помечает удалёнными строки `PROJECTOR` других
+  аккаунтов (идемпотентно), а `projector_state`, не найдя своей строки, так же помечает чужую с тем же именем: иначе
+  уникальный индекс `secret_kind_ident` не дал бы записать свою.
+- О2. `derived_clear` удалял строки всех классов с пометкой проектора во всех арендаторах. Теперь
+  `derived_clear(имя, арендаторы[], классы[])` удаляет только пары «арендатор, класс», которые передаёт проектор
+  (участники и их семейства `into`), и только у классов с его пометкой; прежняя `derived_clear(text)` удаляется при
+  накате.
+- О7 (MCP). Окно подтверждения удаления показывало алиас класса так, как его прислал агент, — текст арендатора. Теперь
+  в окне каноническое имя класса (`registry.resolve(cls).name`) и id целей (первые 10, дальше «и ещё K»); алиас и
+  `meta` в текст не попадают.
+- О8 (MCP). `countBy` и `versions` читали всё и обрезали в памяти. Теперь предел — в самом запросе: `countBy` читает
+  самые частые `maxRows` + 1 групп, `versions` — последние `maxRows` + 1 версий. Для этого в цепочке `limit()` и
+  `offset()` перед `countBy()` относятся к группам (по убыванию числа), а `versions()` учитывает `sort()`
+  (`sort('at', 'desc').limit(n).versions()` — n последних версий). Ответ `countBy` — без `groups`, ответ `versions` —
+  без `total`. Шагов `steps` — не больше 16, условий `$or` в одном фильтре — не больше 64, иначе `invalid_query`.
+  README советует `statement_timeout` для роли базы сервера MCP: время запроса пределы не ограничивают.
+- Смысл `before` у проектора. У первой версии нового id после `reclass` и `rekey` `before` была последняя версия
+  прежнего id, а у надгробия прежнего id — тоже она: свёртка вычитала её дважды (пример README §12 после `rekey` давал
+  0 вместо 10). Теперь `before` — всегда прошлая версия того же id (`fillBefore`): у первой версии нового id — `null`,
+  прежние данные вычитает надгробие прежнего id.
+- Документация: README (обе версии) — §12 «Проекторы»: `failed` в `status()`, `rebuild({ tenant })`, опция `tenants`,
+  смысл `before`, обработка ошибки `run()` в примере (`catch`, а не `void`); §10 «Права» — смена `parent`, `alias` и
+  `derivedBy`; «Агенты и MCP» — форма ответа `countBy`, пределы шагов и `$or`, окно подтверждения; «Агрегаты» и
+  «Версии» — `limit()` у `countBy()` и `sort()` у `versions()`; §15 «Цепочка» — терминалы `diff()` и `blame()`.
+  Шпаргалка (обе версии) — то же коротко.
+
+### Tests — ревью безопасности №2
+- `projector`: арендатор x с `DayTotal` (`derivedBy: 'daily'`, у `total` — `maximum: 0`) и строки `Sale` у x и t —
+  `run({ once: true })` проходит, итог t записан, `status().failed` содержит x с `invalid_data` и текстом с арендатором
+  и id строки (и арендатора y, чью сумму-строку отклонил `out.inc`); `rebuild()` и `rebuild({ chunked: true })` дают
+  верные итоги остальных; пока описание не исправлено, `rebuild({ tenant })` отклоняется; после снятия ограничения
+  `rebuild({ tenant: x.id })` восстанавливает x, а хвост журнала применяет его изменения ровно один раз; опция `tenants`
+  отсекает x — его изменения и строки, не участник — `tenant_denied`. Арендатор z, выбывший посреди перестройки
+  (`batch: 1`: первая строка источника проходит, вторая — нет), после `rebuild()` и `rebuild({ chunked: true })`
+  остаётся без производных строк, а не с их частью. Ярус `all` источника одного арендатора (1 день) при курсоре
+  старше трёх дней — выбывает только он (`cursor_expired`), изменения остальных применены; `rebuild({ tenant })`
+  возвращает его, `onExpired: 'rebuild'` перестраивает его сам; ярус истёк у всех — `cursor_expired`, как прежде.
+  Источник с `history: false` — арендатор выбывает с `invalid_class` (и при перестройке, атомарной и пачками),
+  `rebuild({ tenant })` отказывает до включения журнала, после — возвращает его. Подложенная строка `PROJECTOR`
+  другого аккаунта не мешает проектору, накат её удаляет. Перестройка не трогает класс с пометкой вне семейства
+  `into`. `rekey` строки источника — итог свёртки верный, `before` первой версии нового id — `null`.
+- `acl`: участник с одним правом WRITE на `Class` меняет у класса `alias`, затем `parent` — оба раза `acl_denied`,
+  `rev` строки `Class` не меняется; условного права READ и READ без WRITE и DELETE мало, запрет DELETE на потомка —
+  отказ; с правами без условий — проходит; алиас, совпадающий с именем класса, системным именем или чужим алиасом, —
+  `invalid_class`, у нового класса тоже. Подкласс класса System, чьи строки закрывает запрет System весом 1000, не
+  снять с наследования (`parent` убран, поля скопированы) — `acl_denied`, случай (г) ревью. Новый класс с именем,
+  совпадающим с алиасом класса арендатора или System, — `invalid_class`.
+- `engine-attacks` №36: то же сырым SQL — `alias`, `parent` и `derivedBy` без прав на строки, алиас — имя класса.
+- `mcp`: окно подтверждения удаления по алиасу — имя `Task`, первые 10 id и «и ещё 2», без алиаса и `meta`;
+  `countBy` по 1000 группам и `versions` по 150 версиям читают из базы не больше 101 строки (`onQuery`); 17 шагов и
+  65 условий `$or` — `invalid_query`, 16 и 64 — можно.
+- `aggregate`: правка описания без изменения агрегата — `meta` вместо `alias` (смена алиаса теперь требует прав на
+  строки класса); перенос `Secret` под `Sale` — ещё и с правами WRITE и DELETE на его строки.
+
+### Changed — точка Б (решения владельца)
+- Перестройка проектора в автоматических путях — пачками: первый `run()` новой проекции и `onExpired: 'rebuild'`
+  перестраивают пачками, и горизонт подписок кластера стоит не дольше пачки; `rebuild()` без опций остаётся
+  атомарным (`lib/src/project.ts`: `run`, `rebuildNow`, `chunked`). Второй процесс того же проектора во время такой
+  перестройки не падает с `projector_busy`: занятую блокировку он пережидает, а начатую другим процессом перестройку
+  продолжает, а не начинает заново. Перестройка одного арендатора по `onExpired: 'rebuild'` по-прежнему идёт одной
+  транзакцией.
+- Свёртка `out.inc` (предложение по замерам этапа 6): приращения строки, заданной одними полями ключа или одним `$id`,
+  `out` складывает до отправки в базу, пока между ними нет `upsert`, `delete` или `get`, — одна правка строки за пачку
+  (`Out`, `Projector.foldKey`; поля ключа классов `into` проектор берёт из их описаний). Правило класса проверяется над
+  итогом приращений строки в пачке, а не над каждым промежуточным значением; строку с другими полями `inc` не
+  складывает. Повтор серий 2 и 3 бенча (`BENCH_SERIES=2,3` — новый выбор серий, итог —
+  `lib/bench/results/derived-23.md`): handle с `out.inc` на каждое изменение догоняет 6 076 и 33 395 изменений в
+  секунду (`batch` 500 и 2000) вместо 992 и 1 203, атомарная перестройка 75 тыс. строк — 13,3–13,5 с вместо 101 с,
+  перестройка пачками — 13,0–13,2 с вместо 58–63 с.
+- О5 ревью безопасности №2 — отказывать по умолчанию: `letopis_write` не пишет, не правит и не удаляет строки классов
+  прав — `rule`, `Resource`, `member`, `Account`, `Class` и их потомков (`acl_denied`), а `createMcpServer` отклоняет
+  сессию в арендаторе System (`user_session_required`): так работает системный администратор, и его роль `admin`
+  действует только там. Разрешают это только новые опции `McpOptions` — `allowAclWrite` и `allowSystemAdmin`; у
+  `letopis mcp` таких флагов нет. Об отказе говорят описание `letopis_write` и `instructions` сервера.
+- Документация: README и шпаргалка (обе версии) — §12 (перестройка `run()` пачками, свёртка `inc`, рецепт), «Агенты и
+  MCP», «Справочник API», «Ошибки», «Ограничения», §17; `docs/checkpoint-1.2.md` — решения владельца и повтор замера;
+  `reports/PLAN-LETOPIS-1.1.md` — решения точки Б в шапке.
+
+### Tests — точка Б
+- `projector`: три приращения строки в пачке — одна правка (`created` 1, `updated` 0); −5 и +5 по новой строке с
+  `minimum: 0` — итог 0, а не выбывание; `delete` и `get` свёртку сбрасывают; строка с полем вне ключа не складывается,
+  и порядок правок сохраняется. Первый `run()` новой проекции снаружи виден как `rebuilding`; два процесса одного
+  проектора на новой проекции (`batch: 1`) — ни один `run()` не падает, перестройка одна, итог верный.
+- `mcp`: `create` классов `rule`, `Resource`, `member`, `Account`, `Class`, правка и удаление правила — `acl_denied`, об
+  этом говорит описание `letopis_write`; с `allowAclWrite` — превью удаления правила; сессия системного
+  администратора — `user_session_required`, с `allowSystemAdmin` — сервер работает; `letopis mcp` с её токеном — код 1;
+  неверный тип опций — `invalid_data`.
+- `engine-attacks` №37: агент через MCP выдаёт постороннему членство с ролью `admin`, правило, ресурс и класс —
+  `acl_denied`, строк классов прав не прибавилось; сессия системного администратора — отказ.
+- Без исправлений все новые тесты падают: каждое исправление отключалось по отдельности.
+
+### Security — доработки после точки Б
+- Производный класс — только у администратора (`/security-review` после точки Б). Пользователь арендатора с правом
+  WRITE на `Class` (по умолчанию — любой) заводил класс с `derivedBy` проектора, проектор без `tenants` брал его
+  арендатора в участники и писал туда итоги по всем строкам источников, в том числе по тем, которые пользователю читать
+  запрещено. Теперь `class_admit` (`lib/sql/60-write.sql`) пропускает вставку и правку строки `Class` производного
+  класса — свой `derivedBy` или унаследованный, до правки или после — и `trg_entity_ad` её удаление только с правом
+  `letopis.projector` (`letopis_allowed`): оно есть у администраторской роли подключения и по правилам System —
+  у системного администратора по маске `letopis.*`; иначе `acl_denied`. Правила сида не меняются. Производные классы
+  синхронизирует администраторское подключение с сессией арендатора; `letopis sync` принимает такое подключение
+  (`allowBypassRls`, как `load`, `verify` и `maintain`). README и шпаргалка: кто заводит производные классы, рецепт
+  дневной выручки, «Ограничения» — итоги производного класса видит каждый, кому правила дают на него READ, а с
+  `history: true` его журнал показывает изменение каждой пачки.
+- `rekeyClass` предка не переносит строки производного потомка (укрепление из ревью №2). Производный потомок
+  непроизводного предка наследует его ключ, а `rekey_class` (`lib/sql/90-time.sql`) проверял `derivedBy` только у
+  самого класса и переносил строки потомка на новые id мимо проектора. Теперь класс с производным потомком —
+  `derived_class`.
+- MCP: `structuredContent` с пояснением (укрепление из ревью №2). Данные базы в текстовом дубле стоят внутри
+  `<untrusted-data-…>`, а `structuredContent` повторял их без пояснения — клиент, который отдаёт модели его, обходил
+  смягчение. Теперь `structuredContent` — `{ notice, data }` у ответа и `{ notice, error }` у отказа (`ok` и
+  `failure` в `lib/src/mcp.ts`): данные базы — только в `data` и `error`, `notice` — постоянный текст пакета. Прежние
+  формы ответов — внутри `data`. README и шпаргалка (обе версии): «Агенты и MCP», «Ограничения».
+- Удаление и пересоздание класса (остаток Н2 ревью №2). Пустой класс можно было удалить и создать заново с другим
+  `parent` или `alias`: история его удалённых строк осталась в журнале, а правила прав находят строки по именам
+  класса, предков и алиасов — старые версии попадали под правила новых имён. Теперь `trg_entity_ad` не удаляет класс,
+  пока в журнале есть версии его строк (кроме записей `purge`, `trim`, `reset`; у класса System — у любого арендатора),
+  — `invalid_class`, историю удалённых строк сначала стирает `purge()`; а `trg_entity_bi` создаёт заново класс,
+  удалённый с историей раньше (надгробие строки `Class` хранит прежнее описание), только с прежними
+  `resolved.ancestors`, `alias` и `resolved.derivedBy` — иначе `invalid_class`. Если у истории строк нет надгробия
+  своего класса (строки класса System, удалённого в 1.1, у арендатора), класс с этим именем не создаётся вовсе, пока
+  историю не сотрёт `purge()` (автоматическое ревью коммита). Функция владельца `class_has_history`.
+- Ужесточение класса — не оракул по невидимым строкам (ревью №2, вне его области: было до 1.2). Пробное ужесточение
+  (`maximum`, `enum`, `pattern` и т. п.) отвечало `tightening_conflict` с числом невидимых актору строк, которые ему не
+  соответствуют (`others`), и двоичным поиском узнавались значения чужих строк. Теперь ужесточение (`class_evolve`) и
+  смена ключа (`rekey_class`) до проверки строк требуют права READ без условий на все строки класса и его потомков
+  своего арендатора (`class_rows_admit`, функция владельца; через неё теперь и `class_acl_admit`), иначе `acl_denied`
+  без деталей. Описание агрегата — тоже ужесточение цели. Число строк других арендаторов при ужесточении класса System
+  системным администратором остаётся: это уровень установки. В тексте `problem` id ссылающейся строки — только видимой.
+- Кэш реестра `db.as()` (ревью №2, вне его области: было до 1.2). Реестр арендатора, общий для всех `db.as()`,
+  перечитывался под контекстом первого вызвавшего: если тот выбыл из арендатора или его сессия кончилась, ошибка
+  перечитывания опустошала реестр для всех пользователей арендатора (`load([])`), два одновременных `as()` нового
+  арендатора создавали два реестра (первый больше не обновлялся), а каждый сигнал `Class` перечитывал реестры всех
+  арендаторов процесса. Теперь (`lib/src/index.ts`: `registryFor`, `refresh`, `reload`) перечитывание идёт под
+  контекстом последнего успешного `as()` арендатора, ошибка или контекст не в этом арендаторе оставляют прежний
+  реестр, одновременные `as()` получают один реестр, а сигнал `Class` с токеном арендатора (режимы `tenant` и
+  `opaque`) перечитывает только его реестр.
+- Политика хранения истории (ревью №2, вне его области: было до 1.2). Одно право WRITE на `Class` задавало
+  `history: { all: '1 day' }` или `false`, и ближайший `maintain()` стирал аудит строк, на которые у автора правки
+  прав нет (`trimHistory` требует DELETE и READ на каждую цель). Теперь `class_admit` пропускает смену развёрнутой
+  `history` существующего класса только с правом READ и DELETE без условий на все строки класса и его потомков своего
+  арендатора (`class_rows_admit`), иначе `acl_denied`.
+- `reclass` (ревью №2, вне его области: было до 1.2). Смена класса проверяла WRITE на прежнюю и новую строку, но не
+  DELETE: с одним WRITE строку переносили в класс, где есть DELETE, и удаляли там. Перевод ссылок (`move_row`)
+  переписывал строки глубже первого уровня (ссылающиеся на строку, чей id сменился вместе с ключом) без проверки
+  прав, а текст отказа называл класс невидимой ссылающейся строки. Теперь `reclass` и сырая смена класса
+  (`trg_entity_bu`) требуют права DELETE на прежнюю строку; `move_row` получает план WRITE актора и проверяет каждую
+  переписываемую строку на всех уровнях (`reclass`, `rekey`, `rekey_class`; пути владельца — без плана); класс
+  неправимой ссылающейся строки называется, только если актор её видит. Число невидимых мешающих строк в
+  `reclass_denied` остаётся, как у `restrict` (решение плана 1.0).
+- Цена чтения не растёт с данными других арендаторов (ревью №2, вне его области: было до 1.2). `find_ids`
+  (`lib/sql/70-read.sql`) не называла арендатора: строки и версии классов с тем же именем у всех арендаторов
+  перебирались, и только `row_visible` отсекала чужие, а срез `asOf` и `withDeleted` по классу шёл по индексу
+  `log_class_at (class, at)` без арендатора. Теперь ветви по классу, вложению и концам берут строки арендатора сессии и
+  System явным условием, а свои членства в других арендаторах — отдельным запросом по концу `User`: это ровно то, что
+  пропускает `row_visible`. Индекс журнала — `log_class_tenant_at (class, tenant, at)` вместо `log_class_at`; первый
+  `up()` после обновления строит его, запись в журнал на это время ждёт (README, «Обновление пакета и схемы»: как
+  построить его заранее `create index concurrently`). Ревизия движка остаётся 6.
+- MCP: подпись подтверждения удаления привязана к пользователю и истекает (укрепление из ревью №2). В ревизии
+  2026-07-28 `requestState` был HMAC одного хэша операции ключом процесса: подпись, выданная серверу одного
+  пользователя, проходила у сервера другого пользователя того же арендатора и процесса (у той же операции тот же хэш)
+  и не истекала. Теперь `requestState` — срок и HMAC аккаунта и арендатора сессии сервера, срока и хэша операции
+  (`stateOf`, `stateError` в `lib/src/mcp.ts`); срок — 10 минут, сравнение — `timingSafeEqual`. Подделанная подпись,
+  подпись другого пользователя и устаревшая — `confirmation_required`.
+
+### Changed — доработки после точки Б
+- Проекторы: перестройка одного арендатора пачками и повтор автоматической перестройки (`lib/src/project.ts`).
+  `rebuild({ tenant, chunked: true })` перестраивает арендатора пачками — каждая своей транзакцией со своим снимком,
+  пока хвост журнала идёт для всех: изменения арендатора выше последней пачки хвост пропускает (их прочтёт пачка), в
+  пройденной пачке — если транзакция видна в её снимке; карта пачек — `meta.retenant` чекпоинта. `onExpired: 'rebuild'`
+  перестраивает выбывшего по ярусу пачками, а не одной транзакцией; состояние лежит в чекпоинте, и перестройку
+  продолжает `run()` любого процесса. Прежде неудавшаяся перестройка (занятая блокировка, ошибка) молча оставляла
+  арендатора выбывшим навсегда, а выбывшего в другом процессе не перестраивал никто. Теперь занятая блокировка — повтор
+  на следующем проходе, ошибка данных — выбывание с её кодом без повторов. Ярус перестроенного арендатора
+  отсчитывается от начала его перестройки (`meta.since`), пока курсор её не догнал: прежде отстающий проектор выводил
+  его по `cursor_expired` сразу после перестройки. `status().rebuildingTenants` — кого перестраивают пачками.
+  Арендатор, который к автоматической перестройке перестал подходить (не участник, источник без журнала), выбывает
+  с причиной и не останавливает `run()` для всех (автоматическое ревью коммита).
+
+- Подписка (хвосты выпуска 1.1.0, `lib/src/watch.ts`). `sub.ready()` — обещание начальной точки: у `from: 'now'` —
+  горизонт и снимок момента подписки (`watch_head()`), у `'start'` и курсора — сразу; запись после него в поток
+  придёт. `next()` ставит вызовы в очередь: параллельные вызовы получают разные события — прежде два вызова читали
+  журнал с одной позиции и отдавали событие дважды, а второй затирал ожидание первого. Тестовый помощник
+  `watchStarted` (читал приватное поле) снят: тесты ждут `sub.ready()`.
+
+- Первая заливка (хвост выпуска 1.1.0): `esc` без замен для значений без обратной косой, табуляции и переводов строки,
+  голова строк `entity` и `log` собирается один раз, `uuidv5` — `crypto.hash` и кэш байтов пространства имён (байты
+  `COPY` прежние). Бенч `initial-load.mjs` — выбор прогонов `BENCH_RUNS`. Замер на полном полигоне: первая заливка
+  78,5 с, обычный загрузчик 233,3 с — 2,97×; предел первой заливки — запись `COPY` на сервере (генерируемые колонки
+  `ends` и `hash`, WAL), поэтому подготовку в `worker_threads` по решению владельца не делали
+  (`docs/checkpoint-1.2.md`, «Доработки после точки Б: первая заливка»).
+
+- `check-docs`: ссылки, якоря и управляющие символы сверяются во всех `docs/*.md` (прежде из отчётов — только
+  `docs/checkpoint-a.md`); новая проверка `paths` — пути в обратных кавычках в `docs/checkpoint-*.md` (`lib/…`,
+  `docs/…`, `reports/…`, `.github/…`) существуют.
+
+- Ревью безопасности №3, №1: пустой последний проход перестройки пачками (полной и одного арендатора) теперь тоже
+  пачка со своим снимком — до конца диапазона id. Прежде хвост применял изменения id выше последней прочитанной
+  строки, уже учтённые этим проходом: надгробие строки с наибольшим id, удалённой во время перестройки, вычиталось
+  лишний раз.
+
+- Ревью безопасности №3, №6: арендатор, которого хвост выводит посреди его перестройки пачками (ошибка данных,
+  источник без журнала), остаётся без производных строк — частично построенные удаляются, как обещает README.
+
+- Ревью безопасности №3, №3: перенос строки (`move_row`: `reclass`, `rekey`, `rekeyClass`) не переписывает ссылки
+  строк производного класса, которые на неё ссылаются, — `derived_class`: их пишет только проектор (прежде перевод
+  ссылок шёл мимо него, и проекция расходилась).
+
+- `/security-review` после ревью безопасности №3: имя строки-замка лежит в `meta`, а не в `ident`. Уникальный индекс
+  `ident` таблицы `secret` сравнивает без регистра, поэтому строка-замок семейства, чей корень отличается от корня
+  другого семейства того же арендатора только регистром (`Kase` и `kase`), не вставлялась, и его блокировка молча не
+  бралась: ужесточение шло мимо незафиксированной записи. Так же отключала блокировку строка вида `LOCK`, заведённая в
+  1.1 функциями кредов (тогда этот вид был им открыт), под именем блокировки: накат теперь помечает такие строки
+  удалёнными. Если строки-замка нет и после вставки, `family_lock` отвечает ошибкой, а не пишет без блокировки.
+
+- Ревью безопасности №3, №5: `purge()` удалённого объекта отказывает новым кодом `projector_pending` (LT023), пока
+  курсор проектора, чьи источники `from` включают класс объекта, а у арендатора объекта есть его производный класс,
+  не прошёл надгробие (в том числе надгробие этой же транзакции). Прежде `purge` стирал непрочитанное надгробие, и
+  вклад объекта навсегда оставался в итогах. Чекпоинт проектора хранит `from` (`meta.from`; чекпоинт без него касается
+  всех классов). Брошенный проектор, чьи производные классы удалены, `purge` не держит.
+
+- Ревью безопасности №3, №4: смена класса без смены id (классы без ключа: сырой `UPDATE … SET class`, `reclass()`)
+  журнал пишет версией уже нового класса, и подписка проектора по классам `from` ухода строки из семейства не видела —
+  её вклад оставался в итогах; вошедшая так строка приходила с `before` — версией чужого класса, и свёртка вычитала
+  её. Теперь уход приходит удалением (`op` `delete`, `row` — последняя версия в семействе с `$deleted`), а у
+  вошедшей `before` = `null`. `watch_read(…, p_leaving)` отдаёт такие версии проектору; подписке `db.watch()` — нет.
+
+- Ревью безопасности №3, №2 (было до 1.2): внутренние блокировки — семейства классов (`family_lock`), проектора и
+  обслуживания — больше не advisory, а строки-замки: строки вида `LOCK` таблицы `secret`, которой у приложения нет
+  (`lock_row`, `lock_try`). Advisory-блокировку берёт любая роль базы, а её ключ виден всем в `pg_locks`: посторонняя
+  роль занимала блокировку с ключом из `hashtext` открытого имени (или подсмотренным) и останавливала запись
+  семейства, проектор или обслуживание для всех. Писатели берут строку-замок семейства `for key share`, ужесточение и
+  `rekeyClass` — `for update`. Строковые блокировки очереди не держат — поток записей не дал бы ужесточению случиться
+  никогда, — поэтому ужесточение сначала занимает шлюз семейства (вторую строку-замок), и новые писатели ждут у него.
+  Писатель проходит шлюз в подтранзакции один раз за транзакцию: справка о взятых блокировках
+  (`letopis.family_locks`) пропускает только шлюз, а строку-замок функция берёт на каждую строку — повторно взятая
+  своя блокировка не ждёт. Справку клиент выставляет сам, и в первой редакции, где по ней пропускалась и блокировка,
+  запись с подделанной справкой шла мимо ужесточения (автоматическое ревью коммита 1bc6584). Строки-замки заводятся
+  заранее — при записи строки `Class` и в `seed_system()` (установка, `up()` после обновления, `reset({ all })`).
+  Блокировку обслуживания берёт сама функция `maintain()`. Цена — строковая блокировка на строку записи и
+  подтранзакция на первую запись в семейство за транзакцию; замер (`bench/family-lock.bench.mjs`, медиана трёх
+  кругов) — в пределах шума против advisory 1.1: построчная запись 159 и 157 строк/с, 20 писателей 576
+  и 544 строк/с, 1000 строк одним оператором 303 и 300 мс (`bench/results/family-lock.md`). id строки-замка —
+  `lock_id`: первые 16 байт `sha256` имени (с `v5_id` вставка 1000 строк одним оператором стоила 352 мс против 321).
+
+### Tests — доработки после точки Б
+- `engine-attacks` №38: сессия приложения заводит класс с `derivedBy`, потомка производного класса, правит
+  (`history`, снятие `derivedBy`) и удаляет производный класс — `acl_denied`, строк не прибавилось;
+  администраторское подключение с сессией арендатора (сырой SQL и `syncModels`) и системный администратор в System —
+  проходят. Производные классы тестов заводит `defineDerived` (`lib/test/_engine.ts`, администраторский пул с
+  токеном арендатора), правит — `asAdmin`; бенч `derived.bench.mjs` — так же.
+- `engine-attacks` №39: `rekey_class` непроизводного предка с производным потомком — `derived_class`, строки потомка
+  и ключ предка прежние.
+- `mcp` №5: у ответа `structuredContent` — ровно `notice` и `data`, у отказа — `notice` и `error`; текст-инструкция из
+  базы и из запроса — только внутри `data` и `error`. Остальные проверки `mcp`, `engine-attacks` №35, №37 и `docs`
+  читают ответ из `data`.
+- `engine-attacks` №40: класс Master, закрытый пользователю, с историей удалённых строк — удаление класса
+  `invalid_class`; удалённый раньше (надгробие) — создать его потомком `Note` или с алиасом нельзя, с прежним
+  описанием можно, история пользователю по-прежнему не видна; история без надгробия своего класса — класс с этим
+  именем не создать. `engine-class`: класс с историей строк удаляется только
+  после `purge()`, класс с `history: false` — сразу.
+- `engine-attacks` №41: условное право READ на `Org` — ужесточение и `rekey_class` отклонены `acl_denied` без строк и
+  их числа; READ без условий — `tightening_conflict` с перечнем и `others: 0`. `aggregate`: описанию агрегата нужно ещё
+  право READ на строки цели.
+- `engine-attacks` №42: `reclass` и сырая смена класса без права DELETE на прежнюю строку — отказ; `reclass`, чей
+  перевод ссылок переписал бы невидимую неправимую строку третьего уровня, — `acl_denied`, имени её класса в тексте
+  нет, строка не переписана.
+- `engine-attacks` №43: пользователь с WRITE на `Class` и без DELETE на строки `Note` задаёт `history: { all: '1 day' }`
+  и `false` — `acl_denied`, описание прежнее; с правом DELETE — проходит.
+- `impersonation`: одновременные `as()` — один реестр; пользователь последнего `as()` выбыл из арендатора — реестр не
+  пустеет, после `as()` другого пользователя перечитывается; в режиме `tenant` сигнал `Class` арендатора А не
+  перечитывает реестр арендатора Б.
+- `projector`: `rebuild({ tenant, chunked: true })` по две строки, пока пишутся источники и хвост идёт в другом
+  процессе, — итоги арендатора и остальных равны сумме источников; выбывший по ярусу в процессе без `onExpired`
+  перестраивается процессом с `onExpired: 'rebuild'`; отстающий курсор после перестройки не выводит его снова; ошибка
+  данных при автоматической перестройке — выбывание с `invalid_data` и ни одной повторной попытки.
+- `watch`: `ready()` у `'start'` и `'now'`; два параллельных `next()` — два разных события; ожидающие вызовы при
+  `close()` — `done`.
+- `find-ids-parity`: свои членства в других арендаторах (живое и удалённое) и строки `Class` System — сейчас, `asOf`
+  и `withDeleted`: ответы `find_*` и прямого чтения под RLS совпадают. `explain`: срез `asOf` по классу у арендатора с
+  двадцатью версиями `Staff` читает из индекса `log_class_tenant_at` не больше 40 записей при пяти тысячах версий
+  `Staff` у другого арендатора (`pg_stat_get_xact_tuples_returned`); прежнего индекса нет.
+- `mcp`: клиент ревизии 2026-07-28 повторяет вызов с подменённым `requestState` — подделанная подпись, подпись сервера
+  другого пользователя того же арендатора и истёкшая (`mock.timers` для `Date`) — `confirmation_required`, объект цел;
+  своя подпись до срока — удаление проходит.
+- `projector` (ревью безопасности №3, №1 и №6): после начала перестройки арендатора пачками удалена строка с
+  наибольшим id, пачки её уже не прочтут — итог равен сумме живых строк; источник арендатора выключил журнал посреди
+  его перестройки пачками — арендатор выбывает (`invalid_class`) без частичных строк.
+- `engine-attacks` №44 (ревью безопасности №3, №3): `reclass` строки, на которую ссылается строка производного
+  класса, — `derived_class`, ссылка и класс прежние.
+- `projector` (ревью безопасности №3, №4): сырая смена класса строки без ключа из `Mv` в `Away` — изменение `delete`
+  с `$deleted`, классом `Mv` и прежними данными, вклад вычтен; `reclass()` обратно с новыми данными — изменение
+  `reclass` с `before` = `null`, итог верен.
+- `engine-attacks` №45 (ревью безопасности №3, №2): пока идёт запись семейства, в `pg_locks` нет advisory-блокировок;
+  `secret` вида `LOCK`, `lock_try` и `lock_row` прикладной роли недоступны (`42501`); пока она держит advisory с
+  прежними ключами семейства, обслуживания и проектора, проходят запись, ужесточение, `maintain()` и `run()`
+  проектора. `engine-races` №3а: ужесточение во время непрерывной перекрывающейся записи в семейство проходит меньше
+  чем за 3 с (без шлюза ждало, пока писатели не остановятся). `maintain`: блокировку обслуживания держит транзакция
+  другого процесса (`lock_try`) — `skipped`. Бенч `bench/family-lock.bench.mjs` — цена блокировки семейства: строка-
+  замок со шлюзом против строки без шлюза и advisory 1.1.
+- `projector` (ревью безопасности №3, №5): удаление, которого проектор ещё не прочёл, — `purge` отклонён
+  `projector_pending`; после `run()` — проходит, итог верен; удаление и `purge` одной транзакцией — отказ; класс вне
+  источников и арендатор без производного класса проектора — `purge` сразу. 7.5 №9: `purge` источника до `run()`
+  проекторов — `projector_pending`, после — служебное изменение `purge`.
+- `engine-races` №3б и №3в (`/security-review` после ревью №3): корни семейств `Kase` и `kase` одного арендатора —
+  ужесточение `kase` ждёт незафиксированную запись в него и находит её строку; строка вида `LOCK` чужого аккаунта с
+  именем блокировки ещё не созданного семейства — блокировка семейства работает, накат помечает строку удалённой. Без
+  исправления ужесточение шло, не дожидаясь записи.
+- `engine-attacks` №46 (автоматическое ревью коммита 1bc6584): транзакция выставляет справку `letopis.family_locks`
+  «семейство уже взято» и пишет строку, пока ужесточение держит семейство, — запись ждёт его и получает
+  `invalid_data`, строк, нарушающих новое описание, нет. Без исправления запись проходила сразу.
+
 ## [1.1.0] — 2026-10-11
 
 letopis 1.1 по плану `reports/PLAN-LETOPIS-1.1.md` (редакция 5, этапы 0–3 и контрольная точка А): `diff` и `blame`