Более правильная структура Vault,Storage

Report/includes/ch02.typ

@@ -10,7 +10,7 @@
 
 === Карта процессов
 
-Основные процессы: создание vault → опциональное шифрование → открытие → работа с содержимым → закрытие; для удалённых vault — авторизация OAuth → привязка хранилища → проектная синхронизация.
+Основные процессы: создание storage в vault → опциональное шифрование → открытие → работа с файлами → закрытие; для удалённых vault — OAuth → привязка учётной записи → листинг storage провайдера → проектная синхронизация.
 
 === Диаграмма BPMN
 
@@ -42,6 +42,16 @@ DFD уровня 0 (рис. @fig-16) отражает потоки между UI
 
 #pz-fig("fig_04_domain_class.png", [Диаграмма классов модуля domain], "fig-04")
 
+=== Доменная иерархия хранения данных
+
+Модель данных приложения строится на трёх уровнях (см. `IVaultsManager`, `IVault`, `IStorage` на рис. @fig-04):
+
++ *VaultsManager* — единая точка доступа: реактивный список всех vault (`vaults`), агрегированный список storage (`allStorages`) и `IUnlockManager` для открытых storage;
++ *IVault* — контейнер, объединяющий набор storage. *LocalVault* в приложении один (корень на устройстве); удалённые vault (например, `YandexVault`) добавляются по одному на привязанную учётную запись OAuth;
++ *IStorage* — хранилище, которое пользователь создаёт, переименовывает и удаляет в интерфейсе; внутри — файлы и каталоги, доступные через `IStorageAccessor` (с опциональным клиентским шифрованием).
+
+Пользовательские сценарии «создать локальный vault» в UI соответствуют созданию нового *storage* внутри единственного `LocalVault`, а не появлению второго локального vault.
+
 Служебные сущности Room показаны на рисунке @fig-11.
 
 #pz-fig("fig_11_room_schema.png", [Схема служебных сущностей Room], "fig-11")
@@ -58,14 +68,14 @@ DFD уровня 0 (рис. @fig-16) отражает потоки между UI
 
 == Проектирование локальной базы данных
 
-Служебная БД Room хранит соответствия между исходным хранилищем и зашифрованным представлением (`DbStorageKeyMap`), метаданные vault (`DbStorageMetaInfo`), учётные записи Яндекс (`DbYandexAccount`) и группы синхронизации (`DbStorageSyncGroup`). Пользовательский контент в открытом виде в БД не сохраняется — только параметры, необходимые для восстановления состояния приложения при следующем запуске. Доступ инкапсулирован в DAO и репозиториях модуля `:infrastructure-android`.
+Служебная БД Room хранит ключи шифрования для пар «исходный storage → зашифрованное представление» (`DbStorageKeyMap`), сериализованные метаданные storage (`DbStorageMetaInfo`), учётные записи Яндекс (`DbYandexAccount`) и группы синхронизации (`DbStorageSyncGroup`). Пользовательский контент в открытом виде в БД не сохраняется — только параметры, необходимые для восстановления состояния приложения при следующем запуске. Доступ инкапсулирован в DAO и репозиториях модуля `:infrastructure-android`.
 
 #pz-table(
   [Сущности Room и назначение],
   3,
   table.header([Сущность], [Назначение], [Связь с тестами]),
-  [`DbStorageKeyMap`], [Связь vault ↔ параметры шифрования], [Интеграция],
-  [`DbStorageMetaInfo`], [Имя, путь, флаги состояния vault], [Интеграция],
+  [`DbStorageKeyMap`], [Ключ для `sourceUuid` storage (связь с зашифрованной копией)], [Интеграция],
+  [`DbStorageMetaInfo`], [Сериализованные метаданные `IStorage` (имя, путь, шифрование)], [Интеграция],
   [`DbYandexAccount`], [OAuth access token, идентификатор аккаунта], [`YandexAccountRepositoryTest`],
   [`DbStorageSyncGroup`], [Группа UUID для синхронизации], [`StorageSyncEngineTest`],
 ) <tbl-room-entities>