Удалить старый мусор из документации

2026-06-28 10:29:27 +04:00
parent c93cc6c522
commit c397c28acb
17 changed files with 2 additions and 760 deletions
@@ -0,0 +1,25 @@
+# Регистрация: FAQ и режим пароля из 12 слов
+
+- краткое описание:
+  - на экране регистрации добавлен блок частых вопросов с переходом на отдельный экран справки;
+  - добавлен альтернативный режим ввода пароля через 12 полей-слов в кошелёчном формате, которые склеиваются в одну строку без изменения API;
+  - такой же режим добавлен и на экран входа по логину и паролю.
+
+- что проверять:
+  - на стартовом экране открыть `Зарегистрироваться`;
+  - убедиться, что внизу экрана есть кнопки FAQ;
+  - открыть несколько вопросов и проверить возврат обратно на регистрацию;
+  - включить галочку `Представить пароль в виде 12 слов`;
+  - убедиться, что появляется сетка с нумерованными полями в 3 колонки;
+  - ввести часть слов, перейти дальше и проверить, что шаг подтверждения и генерация ключей работают;
+  - выключить галочку и проверить, что пароль остаётся собранным в одном поле;
+  - открыть экран входа по паролю и повторить те же проверки для режима `12 слов`;
+  - пройти регистрацию до шага оплаты без ошибок интерфейса.
+
+- ожидаемый результат:
+  - FAQ открывается отдельным экраном и содержит понятные ответы;
+  - режим `12 слов` не ломает регистрацию и вход и даёт тот же поток, что и обычный пароль;
+  - пароль не отправляется в новом формате, а продолжает использоваться как одна строка.
+
+- статус:
+  - pending
@@ -0,0 +1,25 @@
+# Временная бесплатная загрузка аватара в Arweave
+
+- краткое описание фичи:
+  Добавлены два временных `Test...` API для бесплатной загрузки маленьких аватаров в Arweave через серверный кошелёк с лимитом `3` загрузки на пользователя. В UI мастера смены аватара добавлен пункт `Залить аватар бесплатно`.
+
+- что именно проверять:
+  1. Пользователь с активной сессией открывает редактирование профиля.
+  2. По нажатию на аватар открывается мастер `Сменить аватар`.
+  3. В мастере есть пункт `Залить аватар бесплатно`.
+  4. До первой загрузки UI показывает остаток `3 из 3`.
+  5. Маленький JPEG/PNG/WebP после уменьшения до файла <= `128 KB` успешно уходит через `TestUploadFreeAvatar`.
+  6. После загрузки приходит `txId`, и аватар сохраняется в профиль как `avatar.ar`.
+  7. Остаток уменьшается: `2`, `1`, `0`.
+  8. На четвёртой попытке сервер отвечает понятной ошибкой про исчерпанный бесплатный лимит.
+  9. Если итоговый уменьшенный файл всё ещё > `128 KB`, UI не отправляет его и показывает понятную ошибку.
+  10. Если серверный Arweave JWK/path не настроен, UI получает понятную ошибку временной функции.
+
+- ожидаемый результат:
+  - первые 3 маленькие аватарки загружаются через серверный Arweave-кошелёк;
+  - после каждой успешной загрузки `ava` в профиле указывает на новый `txId`;
+  - после исчерпания лимита дальнейшая бесплатная загрузка блокируется без записи в профиль;
+  - обычная загрузка через свой Arweave-кошелёк продолжает работать отдельно.
+
+- статус:
+  pending
@@ -0,0 +1,28 @@
+# Общий список каналов без stories
+
+- Краткое описание:
+  вкладка `Каналы` переведена на единый список без разделения на "мои" и "подписки".
+  Название канала в списке теперь показывается как `login_владельца/название_канала`.
+  Служебный канал `stories` скрыт из списка каналов, поиска, подписки и связанных UI-сценариев.
+
+- Что проверять:
+  1. Открыть вкладку `Каналы`.
+  2. Убедиться, что сразу показывается один общий список.
+  3. Проверить, что свои и чужие каналы отображаются вместе.
+  4. Проверить формат названий: `ownerLogin/channelName`.
+  5. Открыть свой канал и убедиться, что внутри сохраняется UI владельца.
+  6. Открыть чужой канал и убедиться, что внутри сохраняется UI подписчика.
+  7. Проверить, что `stories` не отображается:
+     - в общем списке;
+     - в поиске каналов;
+     - в подписке на канал;
+     - в списках выбора канала для репоста.
+
+- Ожидаемый результат:
+  - вкладка `Каналы` больше не делится на два режима;
+  - все видимые каналы идут единым списком;
+  - `stories` нигде не виден и не предлагается пользователю;
+  - переход в канал сохраняет корректный UI в зависимости от владельца.
+
+- Статус:
+  `pending`
@@ -0,0 +1,47 @@
+# Crash-safe запись обычного `AddBlock` через `tmp_bch`
+
+## Кратко
+
+Обычный `AddBlock` переведён на схему:
+
+1. сборка `<blockchainName>.tmp_bch`;
+2. запись sidecar `<blockchainName>.write_check` с `blockNumber` и `blockHash`;
+3. создание пустого marker `<blockchainName>.write_pending`;
+4. SQL-транзакция;
+5. атомарная подмена `tmp -> main`;
+6. удаление временных файлов.
+
+## Что проверить
+
+1. Обычный `AddBlock` на свежей цепочке.
+2. Падение до SQL-commit:
+   - должны остаться только временные файлы;
+   - на старте они должны быть удалены.
+3. Падение после SQL-commit, но до `atomicReplaceBlockchainFile(...)`:
+   - на старте recovery должен довести swap до конца.
+4. Падение после `atomicReplaceBlockchainFile(...)`, но до удаления marker/sidecar:
+   - на старте recovery должен просто подчистить хвост.
+5. Сценарий без marker:
+   - `tmp_bch` / `write_check` считаются мусором и удаляются.
+
+## Ожидаемый результат
+
+- БД и файловая версия цепочки остаются согласованными.
+- Повторный старт сервера не ломает chain и не требует ручной правки файлов.
+- `BlockchainTmpRecoveryOnStartup` корректно обрабатывает и живые остатки, и мусор.
+
+## Статус
+
+`pending`
+
+## Что уже сделано
+
+- В коде есть `tmp_bch`, `write_check` и `write_pending`.
+- `BlockchainWriter` пишет обычный `AddBlock` через временные артефакты.
+- `BlockchainTmpRecoveryOnStartup` умеет добивать или чистить незавершённую запись.
+
+## Что ещё перепроверить
+
+- ручной crash-test на тестовом сервере;
+- совместимость с уже существующими `resync_pending` marker-файлами;
+- отсутствие ложных срабатываний на старых временных файлах.
@@ -0,0 +1,29 @@
+# Проверка аварийных остановок на разных этапах
+
+## Кратко
+
+Нужно отдельно проверить, как сервер восстанавливается после внезапной остановки:
+
+1. во время обычного `AddBlock` / `tmp_bch`-pipeline;
+2. во время `full resync` цепочки;
+3. во время startup recovery, если остановка произошла на предыдущем запуске;
+4. при обычном апгрейде сервиса без явного crash-сценария.
+
+## Что проверять
+
+1. Остановка сервиса до `commit` БД.
+2. Остановка сервиса после `commit`, но до замены `main.bch`.
+3. Остановка сервиса во время `BlockchainResyncCleanupDAO`.
+4. Остановка сервиса во время повторной загрузки цепочки по `GetBlockchainBlock`.
+5. Поведение при обычном `systemctl restart`, когда сервер сам должен добить recovery.
+
+## Ожидаемый результат
+
+- после старта сервер либо дочищает временные артефакты, либо завершает незаконченный `resync`;
+- не остаётся битых `.tmp_bch`, `.write_check`, `.write_pending`, `.resync_pending`;
+- БД и файлы цепочки остаются согласованными;
+- обычная работа сервера не стартует поверх незавершённого recovery.
+
+## Статус
+
+`pending`