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

Report/appendices/appendix-b.typ

@@ -2,7 +2,7 @@
 
 == Обзор программного продукта Wallenc
 
-Wallenc — мобильное приложение для Android, предназначенное для управления vault (хранилищами) с клиентским шифрованием. Продукт не использует собственный сервер; взаимодействие с облаком выполняется через API внешних провайдеров после OAuth.
+Wallenc — мобильное приложение для Android: `VaultsManager` объединяет vault (один локальный и удалённые по OAuth), внутри каждого vault пользователь управляет storage с файлами и клиентским шифрованием. Продукт не использует собственный сервер; взаимодействие с облаком выполняется через API внешних провайдеров после OAuth.
 
 == Техническое задание (выдержка)
 
@@ -34,17 +34,17 @@ Wallenc — мобильное приложение для Android, предна
 
 Установите APK сборки debug/release, полученной от разработчика, или соберите проект из репозитория GitLab ЮФУ. Разрешите доступ к файловой системе при запросе системы.
 
-=== Первый запуск и локальные vault
+=== Первый запуск и storage в локальном vault
 
 1. Откройте приложение Wallenc.
-2. На экране локальных vault нажмите «+» для создания хранилища.
-3. Укажите имя vault и подтвердите создание.
+2. На экране «локальные vault» (список storage в единственном LocalVault) нажмите «+» для создания storage.
+3. Укажите имя storage и подтвердите создание.
 
-#pz-fig("fig_05_local_vaults.jpg", [Экран списка локальных vault], "fig-05-rp")
+#pz-fig("fig_05_local_vaults.jpg", [Экран списка storage (локальный vault)], "fig-05-rp")
 
-=== Шифрование vault
+=== Шифрование storage
 
-1. Выберите vault в списке.
+1. Выберите storage в списке.
 2. Выберите действие «Включить шифрование».
 3. Введите пароль (мастер-ключ) и подтвердите. *Важно:* без пароля восстановление невозможно.
 

Report/includes/abstract-ru.typ

@@ -16,5 +16,5 @@
 
   parbreak()
 
-  [Реализованы управление локальными и удалёнными vault, клиентское AES-шифрование, OAuth Яндекс, служебное хранение метаданных в Room; спроектирован контур синхронизации без передачи ключей провайдеру. Исходный код размещён в приватном репозитории GitLab ЮФУ. Полный листинг исходных файлов — приложение А; программная документация — приложение Б.]
+  [Реализованы иерархия VaultsManager → vault → storage → файлы (один LocalVault на устройстве, удалённые vault по OAuth), клиентское AES-шифрование, служебные метаданные в Room и проектный контур синхронизации без передачи ключей провайдеру. Исходный код размещён в приватном репозитории GitLab ЮФУ. Полный листинг исходных файлов — приложение А; программная документация — приложение Б.]
 }

Report/includes/ch01.typ

@@ -18,9 +18,9 @@
 
 === Назначение и цели создания системы
 
-*Назначение* системы Wallenc — предоставление пользователю мобильного клиента для управления локальными и удалёнными vault с обязательным клиентским шифрованием содержимого до выгрузки во внешнее хранилище.
+*Назначение* системы Wallenc — предоставление пользователю мобильного клиента для работы с иерархией *vault → storage → файлы*: один локальный vault на устройстве, удалённые vault по учётным записям провайдера; внутри каждого vault пользователь управляет отдельными storage с обязательным клиентским шифрованием до выгрузки во внешнее хранилище.
 
-*Цели создания*: обеспечить единую модель хранилищ; минимизировать доверие к провайдеру; поддержать расширение списка провайдеров через адаптеры; сохранить метаданные и состояние приложения в локальной БД без хранения пользовательского контента в открытом виде.
+*Цели создания*: обеспечить единую модель vault и storage; минимизировать доверие к провайдеру; поддержать расширение списка провайдеров через адаптеры; сохранить служебные метаданные в локальной БД без хранения пользовательского контента в открытом виде.
 
 === Функциональные требования
 
@@ -30,23 +30,23 @@
   [Свод функциональных требований],
   2,
   table.header([Код], [Требование]),
-  [ФР-1], [Создание, просмотр, переименование и удаление локальных vault],
-  [ФР-2], [Включение шифрования vault, проверка ключа, открытие и закрытие зашифрованного представления],
-  [ФР-3], [Просмотр и операции с файлами через абстракцию хранилищ; текстовые секреты и 2FA в vault],
-  [ФР-4], [OAuth-авторизация во внешнем провайдере (Яндекс), учёт удалённых vault],
+  [ФР-1], [Создание, просмотр, переименование и удаление storage в локальном vault (LocalVault — один на устройстве)],
+  [ФР-2], [Включение шифрования storage, проверка ключа, открытие и закрытие зашифрованного представления],
+  [ФР-3], [Просмотр и операции с файлами внутри storage; текстовые секреты и 2FA],
+  [ФР-4], [OAuth-авторизация (Яндекс), регистрация удалённых vault и листинг их storage],
   [ФР-5], [Синхронизация: группы хранилищ, журнал коммитов, фоновый Worker без передачи ключей],
   [ФР-6], [Очередь фоновых задач: шифрование, синхронизация, отображение прогресса],
 ) <tbl-req>
 
-==== Управление локальными vault
+==== Управление storage в локальном vault
 
-Пользователь создаёт vault, просматривает список, переименовывает и удаляет хранилища. Служебные каталоги и системные пути не отображаются в пользовательском представлении.
+Пользователь создаёт storage, просматривает список, переименовывает и удаляет их в единственном `LocalVault`. Служебные каталоги и системные пути не отображаются в пользовательском представлении.
 
-==== Шифрование и открытие зашифрованного vault
+==== Шифрование и открытие storage
 
-При включении шифрования формируются параметры `StorageEncryptionInfo`; открытие выполняется только после успешной проверки ключа. Повторное шифрование одного vault до завершения предыдущей операции блокируется.
+При включении шифрования формируются параметры `StorageEncryptionInfo`; открытие выполняется только после успешной проверки ключа. Повторное шифрование одного storage до завершения предыдущей операции блокируется.
 
-==== Работа с содержимым 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>

Report/includes/ch03.typ

@@ -30,7 +30,7 @@
   [User Story Wallenc],
   3,
   table.header([ID], [Формулировка], [Критерий приёмки]),
-  [US-1], [Создаю локальный vault для файлов на устройстве], [Vault в списке (рис. 5)],
+  [US-1], [Создаю storage для файлов в локальном vault на устройстве], [Storage в списке (рис. 5)],
   [US-2], [Включаю шифрование vault паролем], [Статус encrypted, тест T-8],
   [US-3], [Открываю зашифрованный vault ключом], [Доступ к контенту, тест T-9],
   [US-4], [Подключаю Яндекс и удалённый vault], [OAuth OK, тест T-10],
@@ -56,7 +56,7 @@ CJM сценария «защитить и открыть vault» предста
 
 Интерфейс реализован на Jetpack Compose @compose-docs. Экраны локальных и удалённых vault, диалоги шифрования и OAuth показаны на рис. @fig-05–@fig-10 (подробно — приложение В и руководство пользователя в приложении Б).
 
-#pz-fig("fig_05_local_vaults.jpg", [Список локальных vault], "fig-05")
+#pz-fig("fig_05_local_vaults.jpg", [Список storage в локальном vault (экран «локальные vault»)], "fig-05")
 #pz-fig("fig_06_encrypt_dialog.jpg", [Диалог включения шифрования], "fig-06")
 #pz-fig("fig_07_open_close_dialog.jpg", [Диалог открытия и закрытия vault], "fig-07")
 #pz-fig("fig_08_rename_delete_dialog.jpg", [Диалог переименования и удаления], "fig-08")

Report/includes/ch04-expand.typ

@@ -2,7 +2,7 @@
 
 === Модуль :vault-contracts
 
-Определяет интерфейсы регистрации типов хранилищ (`VaultRegistrar`, `VaultRegistration`) и фасад `Vaults` для получения реализации по идентификатору. Позволяет подключать новый провайдер без изменения `:app`.
+Определяет дескрипторы vault (`VaultDescriptor`, `DescribedVault`) и контракты регистрации удалённых vault (`VaultRegistrar`, `VaultRegistration`). Реализация агрегатора — `VaultsManager` в `:domain-vault`.
 
 === Модуль :domain-vault
 

Report/includes/ch04.typ

@@ -12,7 +12,7 @@
 
 === Модуль управления vault и шифрованием
 
-Use case `ManageStoragesEncryptionUseCase` инкапсулирует проверку `canEncrypt`, включение шифрования и открытие хранилища. ViewModel предотвращает повторный запуск шифрования для занятого vault.
+Use case `ManageStoragesEncryptionUseCase` инкапсулирует проверку `canEncrypt`, включение шифрования и открытие хранилища. ViewModel предотвращает повторный запуск шифрования для занятого storage.
 
 Фрагмент логики включения шифрования:
 
@@ -38,7 +38,7 @@ fun enableEncryption(storage: IStorageInfo, password: String, encryptPath: Boole
 
 === Модуль адаптеров хранилищ
 
-Адаптеры реализуют единый контракт доступа к локальным и удалённым хранилищам; регистрация vault выполняется через модуль `:vault-contracts`.
+`VaultsManager` агрегирует один `LocalVault` и удалённые vault; адаптеры реализуют доступ к файлам внутри каждого `IStorage`. Регистрация удалённых vault — через модуль `:vault-contracts`.
 
 === Проект модуля синхронизации
 

Report/includes/ch05.typ

@@ -41,7 +41,7 @@
   [T-4], [Синхронизация группы хранилищ], [Unit], [Да], [Копирование, удаление, trash, блокировки],
   [T-5], [2FA TOTP генерация], [Unit], [Да], [Совпадение с эталоном Java OTP],
   [T-6], [Маппинг ошибок сети/диска], [Unit], [Да], [Типизированные `WallencException`],
-  [T-7], [CRUD локального vault], [Ручной], [Нет], [Список обновлён (рис. @fig-05)],
+  [T-7], [CRUD storage в LocalVault], [Ручной], [Нет], [Список обновлён (рис. @fig-05)],
   [T-8], [Включение шифрования vault], [Ручной], [Нет], [Статус «зашифровано» (рис. @fig-06)],
   [T-9], [Открытие/закрытие vault], [Ручной], [Нет], [Доступ только с ключом (рис. @fig-07)],
   [T-10], [OAuth Яндекс], [Ручной / IT], [Частично], [Токен в Room (рис. @fig-10)],
@@ -125,7 +125,7 @@
   [Протокол ручного тестирования],
   5,
   table.header([ID], [Шаг], [Статус], [Фактический результат], [Иллюстрация]),
-  [T-7], [Создать локальный vault], [OK], [Vault в списке], [@fig-05],
+  [T-7], [Создать storage в LocalVault], [OK], [Storage в списке], [@fig-05],
   [T-8], [Включить шифрование], [OK], [Статус encrypted], [@fig-06],
   [T-9], [Открыть/закрыть vault], [OK], [Контент только при открытом vault], [@fig-07],
   [T-10], [OAuth Яндекс], [OK], [Запись в `DbYandexAccount`], [@fig-10],
@@ -145,7 +145,7 @@
   [Трассировка требований → тесты],
   3,
   table.header([ФР], [Тесты], [Комментарий]),
-  [ФР-1], [T-7, StorageDomainUseCasesTest], [Локальный vault и CRUD секретов],
+  [ФР-1], [T-7, StorageDomainUseCasesTest], [Storage в LocalVault и CRUD секретов],
   [ФР-2], [EncryptorTest, T-8, T-9], [Покрытие AES],
   [ФР-3], [TextSecretsScreenContentTest], [UI + domain],
   [ФР-4], [YandexDiskRepositoryTest, T-10], [HTTP-мок и ручной OAuth],

Report/includes/conclusion.typ

@@ -4,7 +4,7 @@
 
 По главе 1 сформированы требования и выполнен сравнительный анализ аналогов; обоснован выбор стека Kotlin/Compose/Room/Hilt. По главе 2 спроектированы бизнес-процессы, DFD, UML-диаграммы и модель данных Room. Глава 3 описывает пользовательские сценарии и интерфейсные решения. Глава 4 представляет реализованные модули; полный исходный код приведён в приложении А. Глава 5 документирует план и результаты тестирования. Глава 6 содержит краткую экономическую оценку.
 
-*Цель работы достигнута*: разработан и протестирован прототип Android-приложения с клиентским шифрованием, управлением vault, OAuth Яндекс и проектным контуром синхронизации.
+*Цель работы достигнута*: разработан и протестирован прототип Android-приложения с иерархией vault → storage → файлы, клиентским шифрованием, OAuth Яндекс и проектным контуром синхронизации.
 
 *Перспективы развития*: завершение синхронизации по модели коммитов; поддержка дополнительных провайдеров; расширение автоматизированных UI-тестов.
 

Report/includes/intro.typ

@@ -4,7 +4,7 @@
 
 *Актуальность* темы обусловлена распространением мобильных приложений для хранения файлов и секретов, а также ограниченностью готовых решений: многие продукты привязаны к собственному backend, закрытой экосистеме или узкой предметной области @google-secure-folder @bitwarden-help @cryptomator-docs.
 
-*Цель работы* — повысить конфиденциальность пользовательских данных при работе с недоверенными хранилищами за счёт разработки мобильного приложения для защищённого хранения пользовательских данных (Wallenc) без собственного сервера приложения и с единой моделью vault и клиентским шифрованием.
+*Цель работы* — повысить конфиденциальность пользовательских данных при работе с недоверенными хранилищами за счёт разработки мобильного приложения для защищённого хранения пользовательских данных (Wallenc) без собственного сервера приложения, с иерархией vault → storage → файлы и клиентским шифрованием.
 
 Для достижения цели были поставлены следующие *задачи*:
 + выполнить анализ предметной области и сравнительный обзор аналогов, сформировать требования к программному продукту;
@@ -19,7 +19,7 @@
 
 *Практическая база.* Работа выполнена в рамках производственной практики в ООО НМФ «Нейротех» (09.02.2026–06.05.2026) по направлению 09.03.04 «Программная инженерия» на кафедре математического обеспечения и применения ЭВМ (МОП ЭВМ). Научный руководитель — Беликов А. Н. (кафедра системного анализа и телекоммуникаций, САИТ); руководитель от организации — Алексеев Д. М.
 
-*Научная новизна* заключается в сочетании универсальной модели vault, клиентского шифрования и адаптерного доступа к разным типам хранилищ без собственного сервера приложения, с проектным контуром синхронизации зашифрованных данных без передачи ключей провайдеру.
+*Научная новизна* заключается в сочетании единого `VaultsManager`, модели vault/storage, клиентского шифрования и адаптерного доступа к провайдерам без собственного сервера приложения, с проектным контуром синхронизации зашифрованных данных без передачи ключей провайдеру.
 
 *Практическая значимость* — использование результатов при дальнейшей разработке продукта и в учебных проектах по мобильной разработке и информационной безопасности.
 

Report/puml/fig_17_use_case.puml

@@ -6,8 +6,8 @@ left to right direction
 
 actor "Пользователь" as User
 rectangle "Wallenc" {
-  usecase "Управление\nлокальными vault" as UC1
-  usecase "Шифрование\nи открытие vault" as UC2
+  usecase "Управление storage\n(локальный vault)" as UC1
+  usecase "Шифрование\nи открытие storage" as UC2
   usecase "Работа с\nсодержимым" as UC3
   usecase "OAuth и\nудалённые vault" as UC4
   usecase "Синхронизация\nгрупп" as UC5