Привести документацию и TODO к production-структуре

AGENTS.md

@@ -38,43 +38,43 @@
 - В git добавлять исходники, lock-файлы, настройки проекта и документацию Solana-модуля, но не добавлять локальные ключи, `.git`, `.idea`, `.gradle`, `target`, `node_modules`, `test-ledger`, логи, временные run-отчёты и `.env`-конфиги.
 - Для Solana deploy/push использовать правила из локального `shine-solana/shine/AGENTS.md`; не смешивать deploy Solana-модуля с `deployServer`/`deployUI` основного проекта.
 - Для регистрации пользователей в Solana (программа `shine_users`) единая актуальная инструкция по деплою/инициализации, адресам программ, и куда их прописывать в UI/сервере находится в:
-  - `Dev_Docs/Инициализация_Solana_регистрации/README.md`
+  - `docs/Инициализация_Solana_регистрации/README.md`
 - Этот файл считать основной справкой (single source of truth) по деплою и первичной инициализации Solana-регистрации в текущем проекте.
 - Актуальная архитектурная справка по устройству Solana-программ, PDA-счетам, ролям DAO и движению средств находится в:
-  - `Dev_Docs/Solana_Architecture/README.md`
+  - `docs/Solana_Architecture/README.md`
 - Документ формата пользовательской PDA-записи `shine_users` находится в:
   - `shine-solana/shine/doc/formats/shine-user-pda-format-v.1.0.md`
 
 ## Документация блокчейна
-- Актуальная документация по форматам блокчейна находится в `Dev_Docs/Blockchain/README.md`.
+- Актуальная документация по форматам блокчейна находится в `docs/Blockchain/README.md`.
 - Это точка входа (оглавление), рядом расположены детальные файлы по форматам, типам каналов и командным сообщениям.
-- При любом изменении кода, связанного с блокчейном (формат блока, типы каналов, правила чтения/записи, команды), обязательно обновлять соответствующие документы в `Dev_Docs/Blockchain/`.
-- Дополнительно обязательно вести `Dev_Docs/Blockchain/CHANGELOG.md`: дописывать изменения построчно с указанием даты/времени и хэша коммита, после которого внесено изменение.
+- При любом изменении кода, связанного с блокчейном (формат блока, типы каналов, правила чтения/записи, команды), обязательно обновлять соответствующие документы в `docs/Blockchain/`.
+- Дополнительно обязательно вести `docs/Blockchain/CHANGELOG.md`: дописывать изменения построчно с указанием даты/времени и хэша коммита, после которого внесено изменение.
 - Перед любым изменением формата блокчейна обязательно заранее предупреждать пользователя, что формат будет изменён.
 - Изменять формат блокчейна можно только после явного подтверждения пользователя (без подтверждения формат не менять).
 - Добавление любых данных в блокчейн выполнять только через операцию `AddBlock`.
 - Перед каждым `AddBlock` обязательно проверять/актуализировать текущее состояние вершины блокчейна (`last global number/hash`) и использовать его при формировании блока.
 
 ## Документация личных сообщений (DM)
-- Актуальная документация по логике личных сообщений находится в `Dev_Docs/Personal_Messages/Протокол_DM_v1.md`.
-- Точный байтовый формат DM находится в `Dev_Docs/Personal_Messages/Формат_DM_v1.md`.
+- Актуальная документация по логике личных сообщений находится в `docs/Personal_Messages/Протокол_DM_v1.md`.
+- Точный байтовый формат DM находится в `docs/Personal_Messages/Формат_DM_v1.md`.
 - При любом изменении кода, связанного с личными сообщениями (формат подписанного DM-блока, типы DM-сообщений, правила доставки/ACK/read-receipt, роутинг по сессиям, UI-логика чатов), обязательно обновлять оба документа:
-  - `Dev_Docs/Personal_Messages/Протокол_DM_v1.md`
-  - `Dev_Docs/Personal_Messages/Формат_DM_v1.md`
+  - `docs/Personal_Messages/Протокол_DM_v1.md`
+  - `docs/Personal_Messages/Формат_DM_v1.md`
 - Логика личных сообщений в коде должна всегда соответствовать этим документам.
 - Документ по личным сообщениям обязан поддерживаться в актуальном состоянии.
 
 ## Документация API сервера
-- Актуальная документация по публичному JSON/WebSocket API сервера находится в `Dev_Docs/API/`.
-- При любом изменении серверного API/эндпоинтов/операций `op` обязательно обновлять соответствующие документы в `Dev_Docs/API/`.
+- Актуальная документация по публичному JSON/WebSocket API сервера находится в `docs/API/`.
+- При любом изменении серверного API/эндпоинтов/операций `op` обязательно обновлять соответствующие документы в `docs/API/`.
 - Перед изменением самого серверного API обязательно явно предупредить пользователя, какие операции, поля запросов/ответов или коды ошибок будут изменены, и запросить отдельное подтверждение.
 - Без явного подтверждения пользователя формат серверного API не менять; допускается только приведение документации в соответствие уже существующему коду.
-- Если добавляется новая операция `op`, нужно обновить общий список операций в `Dev_Docs/API/09_Operations_Index.md` или создать его, если файла ещё нет.
+- Если добавляется новая операция `op`, нужно обновить общий список операций в `docs/API/09_Operations_Index.md` или создать его, если файла ещё нет.
 
 ## Документация Figma
-- Актуальная документация по переносу экранов SHiNE в Figma и обратному переносу из Figma в код находится в `Dev_Docs/Figma/`.
-- Точка входа: `Dev_Docs/Figma/README.md`.
-- Подробный рабочий регламент: `Dev_Docs/Figma/TRANSFER_UI_SCREENS.md`.
+- Актуальная документация по переносу экранов SHiNE в Figma и обратному переносу из Figma в код находится в `docs/Figma/`.
+- Точка входа: `docs/Figma/README.md`.
+- Подробный рабочий регламент: `docs/Figma/TRANSFER_UI_SCREENS.md`.
 - Для экранов регистрации, входа и других чувствительных UI-flow по умолчанию переносить экраны в Figma по одному, а не пачкой, если пользователь отдельно не подтвердил иной способ.
 
 ## Версионирование
@@ -124,8 +124,8 @@
 - В этих записях искать поля `reason`, `failureStage`, `pcConnectionState`, `pcIceConnectionState`, `routeLabel`, `configuredTurnHosts*`, `reachableTurnHosts*`.
 
 ## Недопроверенные фичи (обязательно)
-- Папка для учёта недопроверенных фич: `Dev_Docs/Pending_Features/`.
-- По каждой новой доработке, которая требует ручной проверки, добавлять отдельный markdown-файл в `Dev_Docs/Pending_Features/`.
+- Папка для учёта недопроверенных фич: `docs/Pending_Features/`.
+- По каждой новой доработке, которая требует ручной проверки, добавлять отдельный markdown-файл в `docs/Pending_Features/`.
 - Рекомендуемый формат имени файла: `YYYY-MM-DD_HHMM_<short-feature-name>.md`.
 - Имена новых файлов и краткие описания фич по возможности писать на русском языке.
 - Внутри файла обязательно указывать:
@@ -134,7 +134,7 @@
   - ожидаемый результат;
   - статус (например: `pending`, `in_progress`, `done`).
 - После подтверждения, что фича проверена и работает корректно, соответствующий файл удалять.
-- В `Dev_Docs/Pending_Features/README.md` вести краткий регламент и поддерживать актуальность.
+- В `docs/Pending_Features/README.md` вести краткий регламент и поддерживать актуальность.
 
 ## Будущие фичи / TODO
 - Папка для задач, сознательно отложенных на будущее: `TODO/`.
@@ -142,7 +142,7 @@
 - Внутри планы разделены по горизонтам: `near/`, `medium/`, `far/` и тематическим подпапкам.
 - Если пользователь спрашивает, какие есть планы или что можно продолжить, сначала читать `TODO/README.md`, затем при необходимости конкретные файлы из подпапок.
 - Файлы из этой папки не считать активными задачами и не начинать реализацию без явной просьбы пользователя.
-- Старую папку `Dev_Docs/Future_Features/` считать выведенной из использования и больше не использовать для новых записей.
+- Старую папку `docs/Future_Features/` считать выведенной из использования и больше не использовать для новых записей.
 - Если часть кода временно отключена или закомментирована, либо удалена как временная заглушка, в TODO-файле подробно описывать:
   - какие файлы и участки отключены;
   - что осталось в коде как заготовка;