SHA256
chore: зафиксированы все текущие изменения проекта
This commit is contained in:
AidarKC
@@ -0,0 +1,67 @@
|
||||
# Кнопка создания канала только в разделе «Мои каналы»
|
||||
|
||||
- Горизонт:
|
||||
`near`
|
||||
- Ориентир:
|
||||
сегодня/завтра
|
||||
- Статус:
|
||||
`proposal`
|
||||
|
||||
## Кратко
|
||||
|
||||
Нужно поправить экран каналов: в общем списке должна быть простая надпись `Каналы` и переход к своим каналам, а кнопка создания канала должна появляться только в разделе `Мои каналы`.
|
||||
|
||||
## Ожидаемый сценарий
|
||||
|
||||
### Общий список
|
||||
|
||||
1. Заголовок: `Каналы`.
|
||||
2. Есть кнопка перехода в свои каналы: `Мои` или `Мои каналы`.
|
||||
3. Кнопки создания канала в общем списке нет.
|
||||
|
||||
### Раздел своих каналов
|
||||
|
||||
1. Заголовок: `Мои каналы`.
|
||||
2. Слева есть переход назад или кнопка `Ко всем каналам`.
|
||||
3. Справа от заголовка или в правой части шапки есть маленькая кнопка `+` для создания канала.
|
||||
4. Кнопка создания канала работает только здесь.
|
||||
|
||||
## Что нужно сделать
|
||||
|
||||
1. Найти компонент/страницу списка каналов в UI.
|
||||
2. Разделить состояние общего списка и списка своих каналов.
|
||||
3. Убрать кнопку создания канала из общего списка.
|
||||
4. Добавить или оставить кнопку создания канала в `Мои каналы`.
|
||||
5. Поправить заголовки:
|
||||
- общий список: `Каналы`;
|
||||
- свой список: `Мои каналы`.
|
||||
6. Проверить расположение кнопок на мобильном и desktop-экране.
|
||||
7. Убедиться, что существующее создание канала не ломается.
|
||||
|
||||
## Вопросы перед реализацией
|
||||
|
||||
1. Какой текст кнопки перехода лучше: `Мои`, `Мои каналы` или иконка с подписью.
|
||||
2. Нужна ли отдельная стрелка назад, если уже есть кнопка `Ко всем каналам`.
|
||||
3. Кнопка `+` должна быть иконкой без текста или `Создать канал`.
|
||||
4. Нужно ли сохранять выбранный режим после перезагрузки страницы.
|
||||
|
||||
## Риски и ограничения
|
||||
|
||||
- Нужно проверить, не завязаны ли текущие обработчики создания канала на общий экран.
|
||||
- На узких экранах заголовок, кнопка назад и `+` могут конфликтовать по ширине.
|
||||
- Если есть роутинг по query/state, важно не сломать прямые переходы.
|
||||
|
||||
## Документы, которые обновить при реализации
|
||||
|
||||
- `Dev_Docs/Pending_Features/` - добавить файл ручной проверки после реализации.
|
||||
- UI-документацию, если в проекте есть отдельное описание экранов каналов.
|
||||
|
||||
## Минимальная проверка
|
||||
|
||||
1. В общем списке виден заголовок `Каналы`.
|
||||
2. В общем списке нет кнопки создания канала.
|
||||
3. Переход в `Мои каналы` работает.
|
||||
4. В `Мои каналы` видна кнопка создания канала.
|
||||
5. Создание канала из `Мои каналы` работает.
|
||||
6. Возврат ко всем каналам работает.
|
||||
7. На мобильном экране шапка не ломается.
|
||||
@@ -0,0 +1,94 @@
|
||||
# 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,71 @@
|
||||
# Пополнение Solana и Arweave через внешний сервис покупки
|
||||
|
||||
- Горизонт:
|
||||
`near`
|
||||
- Ориентир:
|
||||
сегодня/завтра
|
||||
- Статус:
|
||||
`proposal`
|
||||
|
||||
## Кратко
|
||||
|
||||
Нужно добавить удобное пополнение кошельков на экране регистрации/кошелька: для Solana и Arweave дать отдельные действия `Пополнить`, которые ведут на международный сервис покупки криптовалюты с карты и помогают пользователю скопировать адрес кошелька.
|
||||
|
||||
## Пользовательский сценарий
|
||||
|
||||
1. Пользователь видит адрес кошелька Solana или Arweave.
|
||||
2. Нажимает `Пополнить`.
|
||||
3. Открывается промежуточное окно с инструкцией:
|
||||
- сейчас пользователь перейдёт на страницу покупки/пополнения;
|
||||
- нужно указать или проверить адрес кошелька;
|
||||
- после оплаты нужно закрыть внешнюю страницу и вернуться назад;
|
||||
- Solana обычно приходит быстро, ориентир 10-15 секунд после подтверждения сети;
|
||||
- Arweave может идти дольше, точное время нужно уточнить по выбранному сервису.
|
||||
4. В окне есть кнопки:
|
||||
- `Скопировать адрес и перейти`;
|
||||
- `Перейти без копирования`.
|
||||
5. Для Solana и Arweave используются разные окна/инструкции и, возможно, разные внешние ссылки.
|
||||
|
||||
## Что нужно сделать
|
||||
|
||||
1. Найти текущий экран, где показываются кошельки при регистрации и пополнении.
|
||||
2. Найти текущую ссылку покупки Arweave, если она уже есть в UI.
|
||||
3. Выбрать международный сервис покупки Solana с карты, не российский.
|
||||
4. Проверить, поддерживает ли сервис deep link с предзаполненным адресом кошелька.
|
||||
5. Если deep link невозможен, реализовать промежуточное окно с копированием адреса.
|
||||
6. Добавить отдельные действия для Solana и Arweave.
|
||||
7. Сделать текст инструкции коротким и понятным.
|
||||
8. Проверить, что адрес копируется в буфер обмена в браузере.
|
||||
9. Проверить мобильный сценарий и desktop-сценарий.
|
||||
|
||||
## Вопросы перед реализацией
|
||||
|
||||
1. Какой сервис покупки Solana использовать: тот же провайдер, что для Arweave, или другой международный on-ramp.
|
||||
2. Нужно ли разрешать покупку только SOL или также USDC/SPL-токены на Solana.
|
||||
3. Где именно показывать кнопку `Пополнить`: только регистрация, настройки кошелька или оба места.
|
||||
4. Нужно ли показывать предупреждение о комиссиях и стороннем сервисе.
|
||||
5. Нужно ли открывать внешнюю страницу в новой вкладке или в текущем окне.
|
||||
6. Нужно ли логировать факт нажатия `Пополнить` на сервере.
|
||||
7. Какой точный текст использовать для времени прихода Arweave.
|
||||
|
||||
## Риски и ограничения
|
||||
|
||||
- On-ramp-сервисы меняют ссылки и параметры, поэтому deep link нужно проверять перед реализацией.
|
||||
- Clipboard API может требовать HTTPS и пользовательский жест.
|
||||
- Нельзя обещать точное время поступления средств: лучше писать ориентир и зависимость от сети/провайдера.
|
||||
- Внешний сервис может быть недоступен в отдельных странах или для отдельных карт.
|
||||
|
||||
## Документы, которые обновить при реализации
|
||||
|
||||
- Документацию UI/кошельков, если такая есть.
|
||||
- `Dev_Docs/Pending_Features/` - добавить файл ручной проверки после реализации.
|
||||
- `Dev_Docs/API/`, только если появится новый серверный API или логирование.
|
||||
|
||||
## Минимальная проверка
|
||||
|
||||
1. На Solana-кошельке открывается правильное окно пополнения.
|
||||
2. Кнопка `Скопировать адрес и перейти` копирует Solana-адрес и открывает внешний сервис.
|
||||
3. Кнопка `Перейти без копирования` открывает внешний сервис без копирования.
|
||||
4. Аналогичный сценарий работает для Arweave.
|
||||
5. На мобильном экране текст и кнопки не перекрываются.
|
||||
6. Возврат назад в приложение не ломает состояние регистрации/кошелька.
|
||||
Reference in New Issue
Block a user