SHA256
Синхронизировать изменения проекта
This commit is contained in:
AidarKC
@@ -19,12 +19,11 @@ QR-подключение других устройств сейчас есть
|
||||
|
||||
## Откуда продолжать
|
||||
|
||||
- от текущих документов в `Dev_Docs/Future_Features/medium/`;
|
||||
- от текущих документов в `TODO/medium/`;
|
||||
- отдельно проверить, какие поля уже есть в PDA и UI.
|
||||
|
||||
## Какие документы потом обновить
|
||||
|
||||
- `Dev_Docs/Solana_Architecture/README.md`;
|
||||
- `Dev_Docs/Future_Features/medium/2026-06-03_подключение_других_устройств_через_qr.md`;
|
||||
- `Dev_Docs/Future_Features/medium/2026-06-02_сессионные_homeserver_в_pda.md`.
|
||||
|
||||
- `TODO/medium/2026-06-03_подключение_других_устройств_через_qr.md`;
|
||||
- `TODO/medium/2026-06-02_сессионные_homeserver_в_pda.md`.
|
||||
|
||||
@@ -18,12 +18,11 @@
|
||||
|
||||
## Откуда продолжать
|
||||
|
||||
- от `Dev_Docs/Future_Features/medium/2026-05-26_0029_esp32s3_file_storage.md`;
|
||||
- от `TODO/medium/2026-05-26_0029_esp32s3_file_storage.md`;
|
||||
- от документации по ESP32 UI homeserver.
|
||||
|
||||
## Какие документы потом обновить
|
||||
|
||||
- `Dev_Docs/Future_Features/medium/2026-05-26_0029_esp32s3_file_storage.md`;
|
||||
- `Dev_Docs/Future_Features/README.md`;
|
||||
- `TODO/medium/2026-05-26_0029_esp32s3_file_storage.md`;
|
||||
- `TODO/README.md`;
|
||||
- документацию по ESP32 UI homeserver, если добавятся экраны или статусы.
|
||||
|
||||
|
||||
@@ -12,6 +12,7 @@
|
||||
- откуда продолжать;
|
||||
- какие документы потом надо обновить.
|
||||
- Это не активная разработка. Тут только план и контекст.
|
||||
- Старую папку `Dev_Docs/Future_Features/` считать архивной и больше не использовать как источник новых задач.
|
||||
|
||||
## Текущие задачи
|
||||
|
||||
|
||||
@@ -86,7 +86,7 @@
|
||||
- `Dev_Docs/Blockchain/CHANGELOG.md`;
|
||||
- `Dev_Docs/API/04_Add_Block_to_Blockchain_API.md`;
|
||||
- документы API чтения каналов/тредов, если изменятся поля ответа.
|
||||
9. После реализации перенести задачу из `Dev_Docs/Future_Features/` в `Dev_Docs/Pending_Features/` как фичу, требующую ручной проверки.
|
||||
9. После реализации перенести задачу из `TODO/` в `Dev_Docs/Pending_Features/` как фичу, требующую ручной проверки.
|
||||
|
||||
## Минимальный чек-лист ручной проверки в будущем
|
||||
|
||||
|
||||
@@ -1,94 +0,0 @@
|
||||
# Telegram-агент для разрешённых игроков
|
||||
|
||||
- Горизонт:
|
||||
`near`
|
||||
- Ориентир:
|
||||
сегодня/завтра
|
||||
- Статус:
|
||||
`proposal`
|
||||
|
||||
## Кратко
|
||||
|
||||
Нужно расширить `SHiNE-agent-bot-coder`, чтобы агент мог принимать личные сообщения от заранее разрешённых пользователей, вести по каждому отдельную рабочую папку и историю, помогать им с обсуждениями/документами без изменения кода, а краткий результат публиковать в общий канал.
|
||||
|
||||
## Пользовательский сценарий
|
||||
|
||||
1. Разрешённый пользователь пишет агенту в личные сообщения текстом или голосом.
|
||||
2. Голосовое сообщение распознаётся так же, как сейчас распознаются voice/audio-задачи.
|
||||
3. Сервис определяет пользователя по разрешённому списку логинов.
|
||||
4. Для пользователя используется отдельная папка в `Players/`.
|
||||
5. Codex запускается с системным контекстом: от имени какого человека он работает, где лежит его папка, какие у него локальные инструкции.
|
||||
6. Агент может читать код и документацию проекта, но писать должен только в папку этого пользователя, если нет отдельного согласования на изменение общего проекта.
|
||||
7. После ответа пользователю агент отправляет в общий канал короткую сводку двумя сообщениями или двумя блоками: вопрос пользователя и полученный ответ.
|
||||
8. Команда `/new` или `New` сбрасывает только сессию этого пользователя.
|
||||
|
||||
## Предлагаемая структура
|
||||
|
||||
- `Players/`
|
||||
- `Ivan/`
|
||||
- `AGENTS.md`
|
||||
- `history/`
|
||||
- `files/`
|
||||
- `Sergey/`
|
||||
- `AGENTS.md`
|
||||
- `history/`
|
||||
- `files/`
|
||||
- `Milana/`
|
||||
- `AGENTS.md`
|
||||
- `history/`
|
||||
- `files/`
|
||||
|
||||
Имена папок можно уточнить после получения точных Telegram-логинов.
|
||||
|
||||
## Что нужно сделать
|
||||
|
||||
1. Добавить конфигурацию разрешённых Telegram-пользователей.
|
||||
2. Описать соответствие `telegram username -> имя игрока -> папка`.
|
||||
3. Создавать или использовать отдельную историю диалога для каждого игрока.
|
||||
4. Поддержать личные сообщения от разрешённых пользователей.
|
||||
5. Запретить постановку задач от неизвестных пользователей.
|
||||
6. Для групп/каналов оставить текущую логику: команды Айдара имеют приоритет.
|
||||
7. При запуске Codex для игрока добавлять отдельный системный контекст:
|
||||
- имя пользователя;
|
||||
- путь к его папке;
|
||||
- правило записи только в эту папку;
|
||||
- путь к персональному `AGENTS.md`.
|
||||
8. После ответа игроку отправлять краткую сводку в общий канал.
|
||||
9. Поддержать `/new`/`New` как сброс только персональной сессии игрока.
|
||||
10. Добавить защиту от случайного изменения общего кода в режиме игрока.
|
||||
|
||||
## Вопросы перед реализацией
|
||||
|
||||
1. Точные Telegram-логины Ивана, Сергея и Миланы.
|
||||
2. Какой общий канал использовать для сводок: текущий `@shine_writing` или отдельный чат.
|
||||
3. Нужно ли отправлять в общий канал полный текст вопроса/ответа или краткую выжимку.
|
||||
4. Нужно ли пересылать вложения игроков в общий канал или только текстовые сводки.
|
||||
5. Разрешить ли игрокам читать все документы проекта, включая технические заметки деплоя.
|
||||
6. Что делать, если пользователь просит изменить код: отказать, создать предложение в своей папке или просить подтверждение Айдара.
|
||||
7. Нужны ли русские имена папок (`Иван`, `Сергей`, `Милана`) или ASCII-имена (`Ivan`, `Sergey`, `Milana`).
|
||||
8. Нужно ли хранить истории игроков в общей папке сервиса или внутри `Players/<name>/history/`.
|
||||
|
||||
## Риски и ограничения
|
||||
|
||||
- Нужно аккуратно разделить режим Айдара и режим игрока, чтобы игроки не могли случайно запустить изменение общего кода.
|
||||
- Нужно не смешать истории разных пользователей.
|
||||
- Нужно ограничить публикацию в общий канал, чтобы не утекали личные или слишком длинные ответы.
|
||||
- Нужна проверка Telegram-идентификации: username может меняться, поэтому желательно хранить и `user_id`.
|
||||
|
||||
## Документы, которые обновить при реализации
|
||||
|
||||
- `SHiNE-agent-bot-coder/AGENTS.md`
|
||||
- `SHiNE-agent-bot-coder/AGENT.md`
|
||||
- `SHiNE-agent-bot-coder/README.md`
|
||||
- `Dev_Docs/deploy/agent-bot-coder-local-systemd.md`, если появятся новые переменные окружения или настройки сервиса.
|
||||
|
||||
## Минимальная проверка
|
||||
|
||||
1. Айдар по-прежнему может ставить задачи из `@shine_writing`.
|
||||
2. Неизвестный пользователь не ставит задачу в очередь.
|
||||
3. Разрешённый игрок пишет личное текстовое сообщение и получает ответ.
|
||||
4. Разрешённый игрок отправляет voice, оно распознаётся и обрабатывается.
|
||||
5. История одного игрока не попадает в историю другого.
|
||||
6. `/new` сбрасывает только историю текущего игрока.
|
||||
7. Сводка вопрос/ответ появляется в общем канале.
|
||||
8. В режиме игрока агент не пишет за пределы `Players/<name>/` без отдельного подтверждения.
|
||||
@@ -0,0 +1,182 @@
|
||||
# Восстановить полную логику `shine_login_guard`
|
||||
|
||||
Статус: отложено.
|
||||
|
||||
## Зачем это нужно
|
||||
|
||||
Сейчас в проекте включена временная заглушка для регистрации коротких логинов:
|
||||
|
||||
- on-chain `shine_login_guard` пропускает любые валидные логины длиной от `5` символов;
|
||||
- словарная `premium/trademark`-классификация временно отключена;
|
||||
- основной UI удерживает обычных пользователей от логинов `5..7` через временный код;
|
||||
- это сделано только до внедрения полноценной схемы продажи/выдачи красивых имён и промокодов.
|
||||
|
||||
Когда полноценная логика будет готова, нужно вернуть полный режим `shine_login_guard`.
|
||||
|
||||
## Что именно было в полной версии
|
||||
|
||||
Последняя полная словарная реализация зафиксирована в коммите:
|
||||
|
||||
- `0240db5` — `Подготовка перед деплоем в mainnet`
|
||||
|
||||
Ключевой файл полной реализации:
|
||||
|
||||
- `shine-solana/shine/programs/shine_login_guard/src/lib.rs`
|
||||
|
||||
Как быстро посмотреть старую версию:
|
||||
|
||||
```bash
|
||||
git show 0240db5:shine-solana/shine/programs/shine_login_guard/src/lib.rs
|
||||
```
|
||||
|
||||
## Как работала старая логика
|
||||
|
||||
Полная версия делала следующее:
|
||||
|
||||
1. Нормализовала логин:
|
||||
- удаляла `_`;
|
||||
- требовала только ASCII alnum;
|
||||
- приводила к lower-case;
|
||||
- запрещала пустой логин и логин длиннее `20`.
|
||||
|
||||
2. Пыталась разбить логин на `1..3` словарных слова:
|
||||
- premium-слова;
|
||||
- trademark-слова.
|
||||
|
||||
3. Приоритеты классов были такие:
|
||||
- если найден хотя бы один trademark-компонент -> `CLASS_TRADEMARK`;
|
||||
- если найден только premium-набор -> `CLASS_PREMIUM`;
|
||||
- если словарного матча нет и длина нормализованного логина `<= 7` -> `CLASS_PREMIUM`;
|
||||
- иначе -> `CLASS_FREE`.
|
||||
|
||||
4. Для разбивки использовался DFS/backtracking по префиксам строки.
|
||||
|
||||
## Какие файлы участвовали в полной логике
|
||||
|
||||
### Обязательно восстановить или проверить
|
||||
|
||||
1. Код программы:
|
||||
- `shine-solana/shine/programs/shine_login_guard/src/lib.rs`
|
||||
|
||||
2. Генерация словаря:
|
||||
- `shine-solana/shine/programs/shine_login_guard/build.rs`
|
||||
|
||||
3. Словари:
|
||||
- `shine-solana/shine/programs/shine_login_guard/src/dictionaries/premium/**/*.txt`
|
||||
- `shine-solana/shine/programs/shine_login_guard/src/dictionaries/trademarks/**/*.txt`
|
||||
|
||||
4. Документация программы:
|
||||
- `shine-solana/shine/doc/programs/shine_login_guard.md`
|
||||
|
||||
5. Архитектурная документация:
|
||||
- `Dev_Docs/Solana_Architecture/README.md`
|
||||
|
||||
6. UI-логика precheck:
|
||||
- `shine-UI/js/pages/register-view.js`
|
||||
- `shine-UI/js/pages/registration-payment-view.js`
|
||||
|
||||
## Что именно сейчас временно удалено из `lib.rs`
|
||||
|
||||
Временная упрощённая версия убрала:
|
||||
|
||||
- `mod wordlist { include!(...) }`
|
||||
- `MAX_WORDS_PER_LOGIN`
|
||||
- `classify_split(...)`
|
||||
- `is_premium_word(...)`
|
||||
- `is_trademark_word(...)`
|
||||
- словарную DFS-сегментацию
|
||||
- fallback `len <= 7 => premium` в пользу временного `len < 5 => premium`
|
||||
|
||||
Сейчас `classify(login)` делает только:
|
||||
|
||||
1. нормализацию;
|
||||
2. проверку минимальной длины `5`;
|
||||
3. возврат `CLASS_FREE` для всего остального.
|
||||
|
||||
## Как вернуть полную логику
|
||||
|
||||
### Минимальный путь
|
||||
|
||||
1. Взять старую версию `lib.rs` из коммита `0240db5`.
|
||||
2. Вернуть в файл:
|
||||
- `mod wordlist`
|
||||
- `MAX_WORDS_PER_LOGIN`
|
||||
- `classify_split`
|
||||
- `is_premium_word`
|
||||
- `is_trademark_word`
|
||||
3. Вернуть старые тесты и при необходимости дописать новые.
|
||||
4. Проверить, что `build.rs` всё ещё генерирует `generated_dictionary.rs` в прежнем формате.
|
||||
5. Сверить актуальность словарей в `src/dictionaries`.
|
||||
6. Обновить `shine_login_guard.md` обратно под словарную логику.
|
||||
7. Обновить `Dev_Docs/Solana_Architecture/README.md`.
|
||||
|
||||
### Проверка после возврата
|
||||
|
||||
Нужно убедиться, что:
|
||||
|
||||
- trademark-логины снова помечаются как `CLASS_TRADEMARK`;
|
||||
- premium-логины снова помечаются как `CLASS_PREMIUM`;
|
||||
- короткие логины `<= 7` без словарного совпадения снова считаются premium;
|
||||
- UI больше не использует временный код для коротких логинов.
|
||||
|
||||
## Что поменять в UI при возврате
|
||||
|
||||
После возврата полной on-chain логики нужно убрать временный клиентский костыль:
|
||||
|
||||
1. Из `shine-UI/js/pages/register-view.js` удалить:
|
||||
- `TEMP_MIN_LOGIN_WITHOUT_PROMO`
|
||||
- `TEMP_ABSOLUTE_MIN_LOGIN_LEN`
|
||||
- `TEMP_PROMO_HASH_HEX`
|
||||
- локальную проверку временного кода
|
||||
- временные тексты про код для логинов `5..7`
|
||||
|
||||
2. В `shine-UI/js/pages/registration-payment-view.js` пересмотреть временную строку:
|
||||
- сейчас `promoCode: ''` передаётся принудительно;
|
||||
- после внедрения нормальной promo/on-chain схемы это место надо вернуть к реальной логике промокодов.
|
||||
|
||||
## Что учитывать по размеру программы
|
||||
|
||||
Текущая временная версия сильно уменьшила размер `shine_login_guard.so`.
|
||||
|
||||
При возврате полной словарной логики:
|
||||
|
||||
- бинарь снова заметно вырастет;
|
||||
- потребуется больший `programdata` rent;
|
||||
- для апгрейда понадобится больший временный buffer.
|
||||
|
||||
Перед апгрейдом стоит отдельно:
|
||||
|
||||
1. собрать `.so`;
|
||||
2. измерить размер;
|
||||
3. проверить `solana rent <size>`;
|
||||
4. убедиться, что на кошельке достаточно SOL для upgrade buffer.
|
||||
|
||||
## Что ещё проверить перед возвратом
|
||||
|
||||
1. Не осталось ли временных пометок в документации и UI.
|
||||
2. Не завязаны ли новые сценарии на допуск логинов длиной `5..7`.
|
||||
3. Готова ли полноценная схема:
|
||||
- продажа красивых имён;
|
||||
- промокоды;
|
||||
- менеджеры/селлеры;
|
||||
- DAO-квоты;
|
||||
- или другая финальная модель, которая заменит временный режим.
|
||||
|
||||
## Откуда продолжать
|
||||
|
||||
Практически продолжать так:
|
||||
|
||||
```bash
|
||||
git show 0240db5:shine-solana/shine/programs/shine_login_guard/src/lib.rs
|
||||
git show 0240db5:shine-solana/shine/programs/shine_login_guard/build.rs
|
||||
git show 0240db5:shine-solana/shine/doc/programs/shine_login_guard.md
|
||||
```
|
||||
|
||||
Потом:
|
||||
|
||||
1. вернуть код;
|
||||
2. обновить UI;
|
||||
3. обновить документы;
|
||||
4. собрать `cargo test`;
|
||||
5. собрать `cargo build-sbf`;
|
||||
6. только потом делать апгрейд on-chain программы.
|
||||
Reference in New Issue
Block a user