## РОЛЬ
Ты — синтез трёх экспертов:
1. **Game Producer** — 10+ лет опыта в мобильном геймдеве, понимаешь, почему люди залипают в игры.
2. **Web3-стратег** — запускал токен-проекты и play-to-earn игры, знаешь экономику внимания криптосообщества.
3. **Viral Growth Hacker** — понимаешь, как продукты становятся виральными без бюджета (Flappy Bird, Wordle, Hamster Kombat).

Твоя задача — дать список из **10 игровых концепций**, идеально подходящих для клонирования соло-разработчиком в 2026 году.

## КОНТЕКСТ

— **Платформа: ** Web / Mobile Web (PWA/TWA). Игра должна мгновенно открываться по ссылке — без установки.
— **Блокчейн: ** Base (L2 от Coinbase). Дешёвые транзакции, быстрые подтверждения, доступ к DeFi-экосистеме.
— **Цель: ** Виральность, удержание (retention) и онбординг пользователей в экосистему Base.
— **Аудитория: ** Микс из «нормисов» (обычных игроков, которые не знают, что такое кошелёк) и «дегенов» (криптанов, которые ищут следующий x100).
— **Ограничения разработчика: ** 1 человек. Бюджет ≈ 0. Дедлайн на MVP — 1–2 вечера.

## ПЕРЕД ОТВЕТОМ: ПРОВЕДИ АНАЛИЗ

Прежде чем предлагать игры, кратко (5–7 предложений на каждый блок) проанализируй:

### Блок A — Психология залипания (вне Web3)
Какие НЕ-крипто игры стали виральными за последние 10 лет (Flappy Bird, 2048, Wordle, Suika Game, Vampire Survivors, и т. д.)? Какой **конкретный психологический триггер** стоит за каждой? (FOMO, near-miss effect, social proof, completion bias, loss aversion, variable reward schedule — используй термины из поведенческой психологии.)

### Блок B — Психотип криптана
Что движет «дегеном»? Почему он кликает, минтит, фармит? Перечисли 5–7 ключевых триггеров крипто-аудитории (FOMO на иксы, гэмблинг-драйв, tribal identity, airdrop hunting, flex/status через NFT, speculation-as-entertainment). Как это можно встроить в игровую механику?

### Блок C — Пересечение
Где пересекаются триггеры «нормиса» и «дегена»? Какая механика одновременно цепляет обоих? (Это и есть sweet spot для Base-игры.)

## СТРУКТУРА ОТВЕТА (для каждой из 10 игр)

### 1. 🎮 Название и Референс
Что мы клонируем? Конкретный пример (Flappy Bird, 2048, Suika Game, Cookie Clicker, Tinder-swipe, Fruit Ninja и т. д.).

### 2. 🪝 The Hook (Крючок)
Психологическая причина, почему в это залипают. Назови конкретный когнитивный баг / триггер (near-miss, variable reward, social comparison). Одно предложение — без воды.

### 3. 🔄 Core Loop
Цикл действий игрока **в одном предложении**.
Формат: «[Действие] → [Результат] → [Мотивация продолжать]».

### 4. 🛠 Техническая оценка
| Параметр | Оценка (1–10) | Комментарий |
|----------|: ---: |---|
| Сложность кода |? | Что именно надо писать |
| Сложность ассетов |? | Нужны ли спрайты/звуки/3D |
| Рекомендуемый стек | — | React +? |
| **Время до MVP** | — | Сколько вечеров |

### 5. 🔗 Потенциал для Web3 (кратко)
В одном абзаце: как эта механика может выиграть от дешёвых транзакций Base в будущем? (Не расписывай токеномику — просто обозначь направление: ставки, награды, рекорды и т. д.)

### 6. 🧲 Виральный потенциал
Как именно игра распространяется? (Скриншот результата в Twitter? Referral-механика? PvP-вызовы? Провокационный контент?)

## ФИНАЛ: СРАВНИТЕЛЬНАЯ ТАБЛИЦА

После описания всех 10 игр — сводная таблица:

| # | Игра | Сложность Dev (1–10) | Виральность (1–10) | Web3-потенциал (1–10) | Вечеров до MVP |
|---|------|: ---: |: ---: |: ---: |: ---: |

Отсортируй по сумме баллов (Виральность + Web3-потенциал), от лучших к худшим.

## СТИЛЬ ОТВЕТА
— Конкретика, а не абстракция. Не «можно сделать это виральным» →, а «при каждом merge предметов выше уровня 7, экран показывает анимацию с кнопкой Share Score для Twitter».
— Каждая идея должна быть реализуема **одним человеком за 1–2 вечера** в MVP-версии.
— Думай как продюсер, а не как мечтатель: если идея требует мультиплеер-сервера — это минус.

## РОЛЬ
Ты — Frontend Developer, который специализируется на быстром прототипировании игр.

## ЗАДАЧА
Напиши **рабочий прототип** игры, который я смогу запустить и протестировать за 30 секунд.
Мне не нужна красота — мне нужна МЕХАНИКА. Я хочу понять, как это ощущается.

## ДАННЫЕ ИГРЫ
- **Название:** [ВСТАВИТЬ НАЗВАНИЕ ИГРЫ]
- **Референс:** [ВСТАВИТЬ, например: «клон Suika Game / 2048 / Flappy Bird»]
- **Core Loop:** [ВСТАВИТЬ из описания, например: «Свайп → Merge → Рост объекта → Мотивация добраться до максимального уровня»]
- **Ключевая механика:** [ВСТАВИТЬ из описания]

## ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
1. **Стек:** React + Tailwind CSS (или чистый CSS, если быстрее).
2. **Структура:** Всё в ОДНОМ файле `App.jsx` — никаких разбивок по компонентам на этом этапе.
3. **Визуал:** Цветные квадраты/круги вместо картинок. Стандартные кнопки. Никакого дизайна — только функционал.
4. **Обязательный функционал:**
- Базовое взаимодействие (клик/свайп/таp) работает.
- Есть обратная связь на действие (что-то происходит на экране).
- Есть простейший счётчик очков.
- Есть состояние проигрыша или перезапуска.
5. **Запрещено:** Не используй `TODO`, `// implement later`, заглушки вместо логики. Весь код должен быть РАБОЧИМ.

## РЕЗУЛЬТАТ
Выдай полный код `App.jsx`, который я могу вставить в проект `npm create vite@latest` и сразу запустить.

## ЗАДАЧА
Мы сделали скелет игры. Код работает, но это голый прототип.
Подготовь мне **Context Brief** — краткую объективную справку о текущем состоянии проекта. Эту справку я передам другим специалистам для анализа.

⚠️ ВАЖНО: v0.5 — это фронтенд-скелет для проверки механики. Описывай ТОЛЬКО то, что есть сейчас. Не предлагай решения, инструменты, библиотеки или архитектурные изменения. Только факты.

## ФОРМАТ ОТВЕТА

### 1. Current Gameplay
Что КОНКРЕТНО сейчас может делать игрок? Перечисли все доступные действия и реакции системы.
(Пример: «Игрок тапает на экран → мяч подпрыгивает. Есть счётчик пройденных труб. При столкновении — экран Game Over с кнопкой Restart.»)

### 2. Current Tech Stack
Какие технологии и библиотеки использованы? Структура файлов.

### 3. What Works
Что уже реализовано и функционирует корректно?

### 4. What's Missing
Чего явно не хватает для полноценной игры? Перечисли по категориям:
- **Геймплей:** (механики, баланс, уровни сложности)
- **Game Feel:** (анимации, звуки, тряска экрана, партиклы)
- **UX:** (онбординг, туториал, UI-элементы)
- **Social:** (лидерборд, шеринг, мультиплеер)
- **Инфраструктура:** (база данных, бэкенд, аналитика)

### 5. Архитектура кода
Ответь на эти вопросы фактами, без рекомендаций:
- **Ключевые функции:** Перечисли 3–5 главных функций, которые управляют игровой логикой. Формат: `имяФункции()` → что она делает (одно предложение).
- **State:** Где хранится состояние игры? (один store/context или разбросано по useState в компонентах?)
- **Разделение слоёв:** Отделена ли игровая логика от UI? Или всё в одном компоненте?

### 6. Code Quality
Перечисли технические проблемы, которые усложнят любое дальнейшее развитие проекта:
(Всё в одном файле, хардкод значений, отсутствие типизации, потенциальные race conditions и т.д.)

⚠️ СТОП-ПРАВИЛО: Не упоминай конкретные библиотеки, фреймворки или инструменты, которых НЕТ в текущем коде. Не пиши «нужно добавить X» или «заменить на Y». Только описание текущего состояния.

Выдай это компактным текстом, который я смогу скопировать одним блоком.

## СКОУП ТЕКУЩЕЙ СТАДИИ

⚠️ То, что ты видишь в Context Brief — это v0.5, голый фронтенд-скелет для проверки механики.

СЕЙЧАС мы работаем над:
- **Геймплей:** Сделать игру FUN — без блокчейна. Если в неё не залипают без крипты — никакая токеномика не поможет.
- **Game Feel:** Анимации, звуки, тряска экрана, партиклы — всё, что делает игру «сочной».
- **Виральность:** Механики шеринга, провокации, PvP, соревнования — то, что заставляет скриншотить и делиться.
- **Визуальный дизайн:** Профессиональный UI/UX, тёмная тема, Web3-стилистика.

🚫 НЕ предлагай на этом этапе: смарт-контракты, подключение кошелька, токеномику, NFT, P2E, staking, onchain-логику. Это будет в СЛЕДУЮЩЕЙ серии (Часть 3). Сейчас — только геймплей и визуал.

Когда ты предлагаешь твисты и фичи — думай как Game Designer, а не как блокчейн-разработчик.

## КОНТЕКСТ
Я делаю Web3-игру на блокчейне Base. Вот текущее состояние проекта:

[ВСТАВИТЬ ВЕСЬ CONTEXT BRIEF ИЗ ПРОМПТА 3]

## ТВОЯ РОЛЬ
Lead Product Designer + UX-критик.
Ты обладаешь широкой базой знаний по играм и UX. Используй свою эрудицию — приводи конкретные примеры из индустрии.

## ЗАДАЧА
Стратегия «Copy + Add». Предложи **3 варианта модификации («Твиста»)**:

### Twist 1: «The Meme Twist» — Переосмысли через мемы/культуру.
### Twist 2: «The Stakes Twist» — Добавь риск/азарт (внутриигровая валюта, double-or-nothing).
### Twist 3: «The Community Twist» — Игроки влияют друг на друга.

Для каждого: суть, психологический триггер, виральная механика, техническая сложность (1–10).

### ДОПОЛНИТЕЛЬНО (твоя сильная сторона):
- Приведи 2–3 примера игр из истории (Web2 или Web3), которые успешно использовали похожий твист. Что из их опыта мы можем взять?
- Какие **UX-ошибки** чаще всего совершают при реализации каждого твиста? Как их избежать?

### ФИНАЛ
Рекомендация: какой твист + какие элементы из примеров индустрии.

## КОНТЕКСТ
Я делаю Web3-игру на блокчейне Base. Вот текущее состояние проекта:

[ВСТАВИТЬ ВЕСЬ CONTEXT BRIEF ИЗ ПРОМПТА 3]

## ТВОЯ РОЛЬ
Lead Product Designer + Trend Researcher.
Твоя суперсила — доступ к свежей информации из интернета. Используй это: найди АКТУАЛЬНЫЕ тренды, которые мы можем встроить.

## ЗАДАЧА
Стратегия «Copy + Add». Предложи **3 варианта модификации («Твиста»)**:

### Twist 1: «The Meme Twist» — Переосмысли через мемы/культуру.
### Twist 2: «The Stakes Twist» — Добавь риск/азарт.
### Twist 3: «The Community Twist» — Игроки влияют друг на друга.

Для каждого: суть, психологический триггер, виральная механика, техническая сложность (1–10).

### ДОПОЛНИТЕЛЬНО (твоя сильная сторона):
- **Актуальные тренды:** Поищи в интернете — какие игры/механики/мемы СЕЙЧАС набирают популярность в Web3, на Base, в Telegram? Что хайпует на Farcaster/Warpcast? Какие виральные механики работают прямо сейчас?
- **Данные:** Есть ли свежая статистика по retention/DAU успешных Web3-игр, которую можно использовать для обоснования выбора?

### ФИНАЛ
Рекомендация с привязкой к текущим трендам.

## КОНТЕКСТ
Я делаю Web3-игру на блокчейне Base. Вот текущее состояние проекта:

[ВСТАВИТЬ ВЕСЬ CONTEXT BRIEF ИЗ ПРОМПТА 3]

## ТВОЯ РОЛЬ
Lead Product Designer + Маркетолог-провокатор.
Ты — тот, кто думает не как все. Твоя задача — добавить в игру «грязь», провокацию, эмоцию. То, от чего люди скринят экран и кидают друзьям со словами «чувак, ты это видел?!»

## ЗАДАЧА
Стратегия «Copy + Add». Предложи **3 варианта модификации («Твиста»)**:

### Twist 1: «The Meme Twist» — Переосмысли через мемы/культуру.
### Twist 2: «The Stakes Twist» — Добавь риск/азарт.
### Twist 3: «The Community Twist» — Игроки влияют друг на друга.

Для каждого: суть, психологический триггер, виральная механика, техническая сложность (1–10).

### ДОПОЛНИТЕЛЬНО (твоя сильная сторона):
- **Провокационные элементы:** Обидные надписи при проигрыше? Звуки мемов? Пасхалки? Трэш-ток между игроками? Trolling-механики? Дай конкретные примеры текстов, звуков, ситуаций.
- **Виральные хаки:** Какие грязные (но этичные) трюки заставят людей шерить игру? «Share-to-unlock»? Провокационные результаты для скриншотов? Персонализированные оскорбления?
- Не стесняйся быть дерзким. Цензура — враг виральности.

### ФИНАЛ
Какой твист даст максимальный «WTF-эффект» и шеринг?

## РОЛЬ
Ты — Chairman (Арбитр) совета директоров игровой студии.
Ты НЕ участвовал в генерации идей ниже — ты беспристрастный судья.

## КОНТЕКСТ
Мы разрабатываем Web3-игру на блокчейне Base. Три эксперта (Grok, ChatGPT, Gemini) предложили свои идеи по улучшению прототипа. Ниже — их ответы.

ОТВЕТ GROK (маркетолог-провокатор):
[ВСТАВИТЬ ПОЛНЫЙ ОТВЕТ GROK]

ОТВЕТ CHATGPT (UX-критик):
[ВСТАВИТЬ ПОЛНЫЙ ОТВЕТ CHATGPT]

ОТВЕТ GEMINI (исследователь трендов):
[ВСТАВИТЬ ПОЛНЫЙ ОТВЕТ GEMINI]

## ЗАДАЧА
1. **Выбери лучший Twist** из всех предложенных. Аргументируй.
2. **Составь ФИНАЛЬНЫЙ список фич** для внедрения. Раздели на:
- 🔴 **Must Have** (без этого не запускаемся): 3–5 фич
- 🟡 **Should Have** (значительно улучшит, но можно жить без): 3–5 фич
- 🟢 **Nice to Have** (вишенка на торте): 2–3 фичи
3. Для каждой фичи — одно предложение: что делать.
4. **Рекомендуемый порядок внедрения** — от самого важного к наименее важному.
5. Если эксперты противоречат друг другу — разреши конфликт и объясни решение.

Ответ должен быть КОНКРЕТНЫМ и готовым к передаче разработчику.

Проверь этот GitHub-репозиторий на безопасность перед тем, как я его клонирую:

https://github.com/lamawuf/lamochka-llm-council

Прочитай содержимое и проанализируй:
1. **package.json / requirements.txt** — подозрительные зависимости? Опасные скрипты (postinstall, preinstall)?
2. **setup.sh / .sh файлы** — что делают? Скачивают что-то извне? Меняют системные файлы?
3. **Основной код** — обращения к подозрительным URL? Отправка данных? Чтение приватных файлов (.ssh, .env, кошельки)?

Вердикт: ✅ безопасно / ⚠️ есть вопросы / 🚫 не запускать.

# 1. Клонируй
git clone https://github.com/lamawuf/lamochka-llm-council.git
cd lamochka-llm-council

# 2. Запусти setup (создаёт .env, ставит зависимости)
chmod +x setup.sh && ./setup.sh

# 3. Добавь API-ключи в .env
# Минимум — ключ OpenRouter (один ключ для всех моделей): https://openrouter.ai/keys
# Или отдельные ключи для OpenAI, Anthropic, Google, xAI — setup покажет что доступно

# 4. Проверь что всё работает
python3 main.py status

# 5. Отправь промпт (промпт 4-API ниже)
python3 main.py run "ВСТАВЬ СЮДА ПРОМПТ 4-API"

## ВОПРОС ДЛЯ СОВЕТА

У нас есть рабочий прототип Web3-игры на блокчейне Base. Нужно решить: как превратить этот клон в уникальный продукт.

## КОНТЕКСТ ПРОЕКТА (Context Brief)

[ВСТАВИТЬ ВЕСЬ CONTEXT BRIEF ИЗ ПРОМПТА 3]

## СКОУП ТЕКУЩЕЙ СТАДИИ

⚠️ Context Brief выше описывает v0.5 — голый фронтенд-скелет. Сейчас мы НЕ занимаемся блокчейном.

Текущий фокус:
- **Геймплей:** Сделать игру FUN без крипты. Залипательные механики, game feel, анимации, звуки.
- **Виральность:** Мемы, провокации, PvP, share-механики — то, что заставляет скриншотить и делиться.
- **Визуал:** Профессиональный UI/UX.

🚫 НЕ предлагай: смарт-контракты, кошельки, токеномику, NFT, P2E, staking, onchain. Это будет в Части 3.

Все рекомендации должны быть про ГЕЙМПЛЕЙ и ВИЗУАЛ, не про блокчейн.

## СТРАТЕГИЯ

Мы используем подход «Copy + Add»: берём проверенную игровую механику и добавляем уникальный слой, который делает игру запоминающейся и виральной в Web3-среде.

## ЧТО НУЖНО ОТ СОВЕТА

Каждый участник совета должен предложить **3 варианта модификации («Твиста»)**:

### Twist 1: «The Meme Twist»
Переосмысление визуала/сеттинга через интернет-культуру, мемы, крипто-культуру. Скриншот игры сам по себе должен быть мемом, которым хочется поделиться.

### Twist 2: «The Stakes Twist»
Механика риска и азарта (betting на внутриигровую валюту, all-in, double-or-nothing, leaderboard stakes). Что поставил — можешь потерять.

### Twist 3: «The Community Twist»
Механика, где игроки влияют друг на друга (PvP-вызовы, голосования, коллективные рейды, async multiplayer, кланы/фракции).

## ФОРМАТ ОТВЕТА ОТ КАЖДОГО УЧАСТНИКА

Для каждого твиста:
1. **Суть изменения** — что конкретно меняется в геймплее (3–5 предложений).
2. **Психологический триггер** — какой когнитивный баг задействован (FOMO, loss aversion, social proof и т.д.).
3. **Виральная механика** — как именно это заставит людей делиться.
4. **Техническая сложность** (1–10).
5. **Реализация** — как это технически сделать (фронтенд, анимации, game logic).

## УКАЗАНИЯ ПО РОЛЯМ

- **Critic:** Сфокусируйся на провокационных элементах — обидные надписи при проигрыше, трэш-ток, мем-звуки, пасхалки, «грязные» виральные хаки. Будь дерзким.
- **Researcher:** Поищи актуальные тренды — какие игры/механики/мемы СЕЙЧАС набирают обороты в Web3, на Base, в Telegram, на Farcaster? Приведи свежие данные по retention/DAU.
- **Optimizer:** Приведи 2–3 конкретных примера из истории игр (Web2 и Web3), которые успешно использовали похожие твисты. Сфокусируйся на UX — какие ошибки чаще всего совершают и как их избежать. Превращай идеи в actionable план.

## ЧТО ДОЛЖЕН СДЕЛАТЬ CHAIRMAN НА ФИНАЛЕ

1. Выбрать лучший Twist из всех предложенных (аргументировать).
2. Составить ФИНАЛЬНЫЙ список фич, разделённый на:
- 🔴 Must Have (3–5 фич)
- 🟡 Should Have (3–5 фич)
- 🟢 Nice to Have (2–3 фичи)
3. Для каждой фичи — одно предложение: что делать.
4. Рекомендуемый порядок внедрения.
5. Разрешить конфликты между участниками, если есть.

## РОЛЬ
Ты — Technical Architect для игрового проекта.

## КОНТЕКСТ ПРОЕКТА
[ВСТАВИТЬ CONTEXT BRIEF ИЗ ПРОМПТА 3]

## ВЕРДИКТ СОВЕТА ДИРЕКТОРОВ
[ВСТАВИТЬ ПОЛНЫЙ ВЕРДИКТ АРБИТРА — весь документ от Claude]

## СКОУП
Сейчас мы работаем ТОЛЬКО над:
- Геймплей (механики, game feel, анимации, звуки)
- Виральность (мемы, share-механики, провокации)
- Визуал (UI/UX, дизайн)

🚫 НЕ включай в план: подключение кошелька (wallet), смарт-контракты, токеномику, NFT, Farcaster Frames SDK, Web3-провайдеры (Privy, Dynamic, wagmi). Это отдельная стадия, которая будет позже. Если в вердикте есть такие фичи — вынеси их в раздел «Бэклог (не в текущий план)».

## ЗАДАЧА
На основе вердикта составь **архитектурный план внедрения**, разбитый на **2 запуска разработки**.

⚠️ Почему именно 2: один разработчик-агент не вытянет все фичи за один запуск — контекст кончается, качество падает. Поэтому раздели план так, чтобы каждый запуск был самостоятельным блоком работы.

### ЗАПУСК 1 — Ядро
Рефакторинг (если нужен) + основные механики из вердикта. То, что меняет геймплей: новые экраны, новые взаимодействия, ключевые фичи.
- Детальный план: какие фичи, структура файлов, порядок работ, зависимости.

### ЗАПУСК 2 — Polish
Звуки, анимации, второстепенные фичи, доводка. То, что делает игру «сочной».
- Детальный план: какие фичи, что добавляется поверх Запуска 1.

### Для обоих запусков:
4. **Стек и зависимости:** Какие библиотеки добавить (Framer Motion, Howler.js, Canvas API и т.д.).
5. **Архитектурная гигиена (встраивай в запуски, не выделяй отдельно):**
- Вынеси ключевые игровые действия в отдельный слой абстракции (`gameActions.js` / `useGameActions()`), чтобы потом можно было подменить внутреннюю логику без переписывания UI.
- Централизуй state management (React Context / Zustand) — один источник правды.
- Отметь в плане точки, где в будущем может встать внешняя интеграция.
6. **Риски:** Что может пойти не так? Как откатить?

НЕ ПИШИ КОД. Только план. Мы обсудим его и утвердим, после чего я передам его в окно разработки.

## РОЛЬ
Ты — Creative Game Developer. Твоя задача — реализовать архитектурный план.

## ТЕКУЩЕЕ СОСТОЯНИЕ ПРОЕКТА (Context Brief)
[ВСТАВИТЬ CONTEXT BRIEF ИЗ ПРОМПТА 3]

## АРХИТЕКТУРНЫЙ ПЛАН
[ВСТАВИТЬ ВЕСЬ ОТВЕТ АРХИТЕКТОРА ЦЕЛИКОМ]

## ЗАДАНИЕ
Выполни только **ЗАПУСК 1** из архитектурного плана. Запуск 2 не трогай.

## ТЕХНИЧЕСКИЕ СТАНДАРТЫ
1. **Mobile First:** touch-action: none, минимум 48px touch targets.
2. **Визуал:** Тёмная тема. Web3/Base стилистика (синий, неон, градиенты).
3. **Качество:** Никаких `TODO` для логики текущего запуска. Коммить после каждого завершённого шага.
4. 🚫 Не добавляй wallet, Web3-провайдеры, смарт-контракты или блокчейн-логику. Только геймплей и визуал.

Начинай.

## ЗАДАНИЕ
Выполни только **ЗАПУСК 2** из архитектурного плана. Запуск 1 уже реализован.

Прочитай содержимое этого репозитория: https://github.com/nextlevelbuilder/ui-ux-pro-max-skill
Используй эти инструкции как руководство по улучшению дизайна моего проекта.

## РОЛЬ
Ты — UI/UX эксперт для Web3 приложений и игр.
Твоя задача — превратить функциональный прототип в визуально привлекательную, «сочную» игру, не ломая существующую логику.

## ПЕРЕД НАЧАЛОМ РАБОТЫ

1. **Бэкап:**
git add -A && git commit -m "backup: UI before visual upgrade"
Сообщи мне хэш коммита для возможного отката.

2. **Изучи приложение:**
- Прочитай все файлы проекта (App.jsx/tsx, index.css, компоненты).
- Пойми механику, текущее визуальное состояние, целевую аудиторию (крипто + казуальные игроки).
- ВАЖНО: Работай ТОЛЬКО с текущим состоянием кода. Не смешивай версии.

3. **Жди моих ответов на вопросы ниже перед тем, как начать.**

## ВОПРОСЫ ПЕРЕД СТАРТОМ

Перед улучшением дизайна уточни:

1. **Стиль:** По умолчанию — dark theme + neon glow (стандарт для crypto/gaming). Хочешь другой стиль?
2. **Агрессивность:** По умолчанию — subtle улучшения, которые не ломают существующий стиль. Нужен полный redesign?
3. **Приоритет:** Что важнее всего сейчас — кнопки/CTA, фон, панели, анимации, всё сразу?

Или скажи «делай по умолчанию» — и я начну с оптимальных настроек.

## ПОСЛЕ ПОЛУЧЕНИЯ ОТВЕТОВ — АНАЛИЗ И ПЛАН

Проанализируй текущий UI и выяви проблемы. Типичные проблемы AI-сгенерированного UI:

| Проблема | Решение |
|----------|---------|
| Плоский фон | Gradient mesh, subtle grid, particles |
| Нет глубины у панелей | Glassmorphism (blur + border glow + shadow) |
| Статичность | Hover-эффекты, subtle анимации, transitions |
| Кнопки без акцента | Glow, pulse animation, gradient |
| Скучные progress bars | Gradient fill + shine-эффект |
| Базовые карточки | Border glow on hover, lift effect |
| Плохой контраст | Проверь читаемость текста |
| Нет visual hierarchy | Размеры, цвета, spacing для приоритетов |

**Выведи план в формате:**

### План улучшений

**Критичные (сильно влияют на восприятие):**
1. [Что] — [Почему]
2. ...

**Желательные (subtle improvements):**
1. [Что] — [Почему]
2. ...

**Опционально (если хочу redesign):**
1. [Что] — [Почему]

Утверждаешь план? Или убрать/добавить что-то?

## ПОСЛЕ УТВЕРЖДЕНИЯ

1. **Работай с CSS/стилями отдельными коммитами.** Если что-то сломается — легко откатить.
2. **Не удаляй старые классы сразу.** Сначала добавь новые, проверь, потом чисти.
3. **После каждого блока изменений сообщи:**
- Что изменилось (коротко).
- Какие эффекты видны ТОЛЬКО при hover/interaction (пользователь не увидит их на скриншоте).
- Команда для отката: `git checkout [хэш]`

## CSS-ПАТТЕРНЫ ДЛЯ WEB3/CRYPTO (справочник)

### Фон с глубиной:
```css
body::before {
content: '';
position: fixed;
inset: 0;
background:
radial-gradient(ellipse at 20% 20%, rgba(0, 82, 255, 0.15) 0%, transparent 50%),
radial-gradient(ellipse at 80% 80%, rgba(139, 92, 246, 0.1) 0%, transparent 50%);
pointer-events: none;
}

Glassmorphism-панель:

.panel {
background: rgba(17, 24, 39, 0.6);
backdrop-filter: blur(20px);
border: 1px solid rgba(0, 212, 255, 0.15);
box-shadow: 0 8px 32px rgba(0, 0, 0, 0.3);
transition: all 0.3s ease;
}
.panel:hover {
border-color: rgba(0, 212, 255, 0.4);
transform: translateY(-2px);
}

Glow-кнопка с pulse:

.cta-button {
box-shadow: 0 0 15px rgba(0, 212, 255, 0.3);
animation: pulse 2s ease-in-out infinite;
}
@keyframes pulse {
50% { box-shadow: 0 0 25px rgba(0, 212, 255, 0.5); }
}

Progress bar с shine:

.progress-fill::after {
content: '';
position: absolute;
inset: 0;
background: linear-gradient(90deg, transparent, rgba(255,255,255,0.3), transparent);
animation: shine 2s infinite;
}
@keyframes shine {
0% { transform: translateX(-100%); }
100% { transform: translateX(100%); }
}

ПРИНЦИПЫ

Не галлюцинируй — работай только с тем кодом, который видишь.

Не смешивай версии — старый дизайн в бэкапе, новый в текущих файлах.

Спрашивай, если не уверен — лучше уточнить, чем переделывать.

Предупреждай о невидимом — hover/animation эффекты не видны на скриншоте, предупреди пользователя.

Ты — Game Producer* и Web3-стратег с опытом запуска виральных продуктов в Telegram и Mobile Web.

Твоя задача — дать мне список из 10 игровых концепций, которые идеально подходят для клонирования соло-разработчиком в 2026 году.

КОНТЕКСТ:
1. Платформа: Web / Mobile Web (PWA/TWA). Игра должна мгновенно открываться по ссылке.
2. Цель: Виральность, удержание (retention) и онбординг пользователей в экосистему Base.
3. Аудитория: Микс из «нормисов» (обычных игроков) и «дегенов» (криптанов).

СТРУКТУРА ОТВЕТА (Для каждой игры):
1. Название и Референс: (Что мы клонируем? Пример: Flappy Bird, 2048, Tinder).
2. The Hook (Крючок): Психологическая причина, почему в это залипают.
3. Core Loop: Цикл действий игрока в одном предложении.
4. Техническая оценка (1-10): Сложность кода, сложность ассетов, рекомендуемый стек.
5. 💎 CRYPTO / BASE LAYER: (Самое важное!)
 — Как внедрить Base (дешевые транзакции)?
 — Идея токеномики (P2E, Betting, Burn, NFT-skins).
 — Как это повышает виральность?

ВЫВОД:
Сделай сравнительную таблицу всех 10 игр по параметрам: «Сложность Dev», «Виральность», «Crypto-Potential».

В чате у нас очередной холивар: влияет ли ролевая инструкция в духе «Ты — [роль]» на качество решения логических задач GPT (программирование, математика и т.п.) 🔥

Довольно легко показать вроде бы парадоксальный факт: почти любая ролевая инструкция ухудшает качество генерации у GPT. И «Ты — junior developer», и «Ты — senior developer», не говоря уже про странные роли типа «Ты — инквизитор», как любят делать коллеги.

Давайте просто разберём, как ИИ обучался программировать.

На скриншоте — датасет обучения программированию GPT через задачи Codeforces. Основное обучение идёт через SFT, и модель обобщает огромное количество пар «задание → код». Как легко заметить, ни в одном варианте логических задач в датасете нет ролевой инструкции как параметра.

Многим разработчикам не приходит в голову, что на деле, когда ИИ пишет код, он в значительной степени работает как переводчик (translate machine). GPT обучается «переводить» описание задачи в код — примерно так же, как русский в английский.

А теперь что происходит, когда вы добавляете «Ты — junior developer» или «Ты — senior developer»?

В обоих случаях вы вносите семантический шум, который сдвигает модель от оптимума самого качественного кода — просто по-разному.

Инструкция «Ты — junior developer» заставляет модель вести себя «как юноша-разработчик» — в том числе вносить ошибки «как у джуна» в рамках этой роли.

«Ты — senior developer» тоже ухудшает выдачу кода, потому что априори заставляет отходить от оптимума качества генерации, который роль вообще не учитывает. Главный риск здесь — over-engineering и карго-культ у сеньоров, а вы фактически велите GPT подражать их социальной роли.

Как раз обсуждаемые в чате «рои агентов», где можно было сделать одного агента с RAG + Tools, — это и есть пример повреждения качества от инструкции «быть сеньором». Модель начинает городить сложности, неадекватные задаче, потому что «сеньоры обычно делают сложно».

Ещё одна опасность «Ты — senior developer» — модель резко повышает вес карго-культов как социального явления у сеньор-разработчиков. Пример из чата: модель вставила калькулятор Wolfram, хотя у неё есть своя песочница на Python, а размах весов LLM уже 5 лет не нуждается в технологиях Wolfram для Siri-уровня. Это связано с тем, что есть "карго культ" Вольфрама у сеньоров как его личный авторитет.

Обычно роль агента задают ради формата общения в чате с оператором — чтобы модель была «понятнее человеку». Но если посмотреть промпты агентов, которые уже автономно делают генерации без оператора, то профессионалы редко ставят роли — именно потому, что они ухудшают качество, сбивая модель с оптимумов решений из SFT.

По факту для GPT ваша роль — это разновидность прайминга контекста. Вы повышаете вероятность выбора паттернов из SFT, которые больше коррелируют с этой ролью. Но поскольку задачи в SFT почти никогда не ролевые — чаще всего это просто семантический шум.

Я выбрал для реализации игру: [ВСТАВИТЬ НАЗВАНИЕ ИГРЫ, НАПРИМЕР: TINDER SWIPE GAME].

Твоя роль: Frontend Developer.

Задача: Напиши ПРОСТЕЙШИЙ рабочий прототип этой механики (MVP).

ТРЕБОВАНИЯ:

1. Стек: React + Tailwind CSS.

2. Файл: Сделай всё в одном файле (App.jsx), чтобы я мог сразу запустить и проверить.

3. Дизайн: Не трать время на красоту. Используй цветные квадраты вместо картинок и стандартные кнопки.

4. Функционал: Мне нужно только проверить базовое взаимодействие (нажал/свайпнул — получил результат).

Код должен быть рабочим. Выдай полный код компонента.

Clauding.....

Мы сделали базу (Скелет). Код работает, но он "пустой".
Подготовь мне краткую справку (Context Brief) для продуктового дизайнера.

Напиши:
1. Current Gameplay: Что именно сейчас может делать игрок? (Например: "Только свайпать цветные квадраты").
2. Current Tech: Какой стек мы использовали?
3. Missing Features: Чего явно не хватает для полноценной игры? (Звуки, анимации, подсчет очков, база данных).

Выдай это коротким текстом, который я скопирую.

ЗАДАЧА: У меня есть этот базовый клон (см. выше). Теперь переключись в режим Lead Product Designer. Мы не хотим делать просто копию. Мы используем стратегию "Copy + Add".

Предложи 3 варианта модификации ("Твиста"), которые сделают эту игру хитом на блокчейне Base:

1. The "Meme" Twist: Как изменить визуал/сеттинг на что-то хайповое (мемы, графики, culture)?
2. The "Gambling" Twist: Как добавить механику риска/азарта (High Stakes)?
3. The "Community" Twist: Механика, где игроки влияют друг на друга (PvP, голосование).

Для каждой идеи напиши:

• В чем суть изменения.
• Почему это заставит людей делиться игрой.

Ты — Degen-Маркетолог с огромным опытом запуска щиткоинов и виральных проектов на [ВСТАВИТЬ БЛОКЧЕЙН, НАПРИМЕР: BASE/SOLANA]. Ты ненавидишь скуку, корпоративный стиль и "безопасность". Твоя стихия — FOMO, Хайп, Грязь и Мемы.

Я делаю игру/проект: [ВСТАВИТЬ НАЗВАНИЕ И КРАТКОЕ ОПИСАНИЕ].

У МЕНЯ ПРОБЛЕМА:
Я показал этот концепт "правильному" продакт-менеджеру (Gemini/Claude), и он предложил мне скучную фигню, чтобы "улучшить UX":
1. [ВСТАВИТЬ СКУЧНЫЙ СОВЕТ №1. Например: "Добавить детальное обучение для новичков"]
2. [ВСТАВИТЬ СКУЧНЫЙ СОВЕТ №2. Например: "Сделать подтверждение действий, чтобы игрок не ошибся"]

ТВОЯ ЗАДАЧА:
1. **Разнеси эти советы.** Объясни жестко и с юмором, почему это убьет виральность и почему "нормис-подход" здесь не сработает.
2. **Предложи свои 3 "Growth Hacks"**, чтобы добавить ГРЯЗИ, АЗАРТА и ЗАСТАВИТЬ людей репостить:

👉 **Idea 1: The "Roast" Factor (Эмоциональный Урон)**
Как игра должна унижать или троллить игрока, если он играет плохо, медленно или слишком "сейвово"? (Предложи тексты, звуки, визуальные эффекты).

👉 **Idea 2: The "Flex" Factor (Социальное Доминирование)**
Что должно происходить при победе/высоком результате, чтобы игрок моментально захотел выложить скриншот в Twitter/Telegram? (Уникальные скины, оскорбительные для других ачивки, генерация мема).

👉 **Idea 3: The "Degen" Easter Egg (Пасхалка для своих)**
Какую скрытую механику или отсылку добавить специально для OG-криптанов и пользователей [ВСТАВИТЬ НАЗВАНИЕ СЕТИ], которую поймут только "свои"?

Стиль общения: Агрессивный, с использованием крипто-сленга (Gem, Rug, NGMI, LFG, Chad).
НЕ пиши код. Дай мне конкретные, злые и виральные фичи.

Это такой элементарный способ применения LLM-Council. Вообще по хорошему, систему можно устроить сложнее и эффективнее. Например, как устроено у меня: грок и гемини прикручены к моей системе работы через API. И когда нужно - я вызываю их, чтобы они все втроём (Claude, Grok, Gemini), обсудили ту или иную проблему, покритиковали друг друга (можно даже в несколько кругов), и пришли к общему решению. Но это уже отдельная тема, расскажу в последующих уроках курса по вайбкодингу, который выкладываю себе в приватку @llamichzhopabot

Role: Ты — Creative Developer с опытом в GameDev и Web3.
Твоя задача — написать ФИНАЛЬНУЮ, готовую к релизу версию игры.

📝 КОНТЕКСТ ПРОЕКТА:
1. Название игры: [ВСТАВИТЬ НАЗВАНИЕ]
2. Жанр/Механика: [ВСТАВИТЬ МЕХАНИКУ, НАПРИМЕР: SUIKA MERGE / TINDER SWIPE / FLAPPY BIRD]
3. Основная идея (Twist): [ВСТАВИТЬ ОПИСАНИЕ ТВИСТА ИЗ ЭТАПА 3]

🤖 ИНТЕГРАЦИЯ ФИДБЕКА (ОТ СОВЕТА ДИРЕКТОРОВ):
Я показал прототип Маркетологу и UX-Критику. Вот список фич, которые ОБЯЗАТЕЛЬНО нужно внедрить в код прямо сейчас:

👉 ОТ МАРКЕТОЛОГА (Для виральности и "грязи"):
[СКОПИРУЙ СЮДА ЛУЧШИЕ ПУНКТЫ ИЗ ОТВЕТА GROK]
*Пример: "Добавь обидные надписи при проигрыше", "Звуки мемов", "Пасхалки".*

👉 ОТ UX-КРИТИКА (Для качества и "сочности"):
[СКОПИРУЙ СЮДА ЛУЧШИЕ ПУНКТЫ ИЗ ОТВЕТА GEMINI]
*Пример: "Тряска экрана (Screen Shake)", "Партиклы при действии", "Плавная физика".*

🛠 ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ:
1. Стек: React + Vite + Tailwind CSS.
2. Библиотеки: Используй [ВСТАВИТЬ НУЖНЫЕ БИБЛИОТЕКИ, НАПРИМЕР: MATTER.JS ДЛЯ ФИЗИКИ / FRAMER MOTION ДЛЯ АНИМАЦИЙ].
3. Mobile First: Игра должна ощущаться как нативное приложение.
- Заблокируй скролл и зум (`touch-action: none`).
- Сделай большие зоны для тапа/свайпа.
4. Структура: Сделай всё в одном файле `App.jsx` (или разбей на компоненты, если код очень большой), но дай мне ПОЛНЫЙ рабочий код, который я могу скопировать и запустить.
5. Визуал: Темная тема, стилистика Web3/Base (Синий/Неон/Градиенты).

ВАЖНО:
Не используй `TODO` для основной логики. Реализуй все механики (счет, проигрыш, анимации) полностью. Вместо картинок используй цветные заглушки с текстом (Placeholder), но напиши код так, чтобы я легко мог заменить их на URL.

Начинай писать код.

Кидайте или в тот же чат с LLM, где уже было общение по этой игре, или если кидаете в новый — газуйте плюсом к этому контекст игры (как выгружать его из клод кода вы уже знаете + скриншот никогда не помешает

Ты — Degen-Экономист и архитектор виральных крипто-схем (в духе Friend.tech или pump.fun).
Мы делаем игру "Evolution of a Degen" (Merge-механика) на блокчейне Base.

МОЯ ГИПОТЕЗА (DRAFT):
1. **Pay-to-Play:** Вход в одну игру стоит $3 (в ETH).
2. **Revenue Split:** $1.5 уходит разработчикам (нам), $1.5 идет в Призовой Пул.
3. **Incentive:** Мы обещаем, что 50% будущего аирдропа от Base (Developer Grants) мы раздадим активным игрокам.
4. **On-Chain Goal:** Нам нужно набить много транзакций, чтобы Base нас заметил.

ТВОЯ ЗАДАЧА:
Разнеси эту модель и предложи "Turbo-Mode", чтобы включить у игроков дикое FOMO.
1. **The Hook:** $3 — это скучно. Как упаковать этот взнос? (Например: "Buy the Dip Ticket", "Wager Contract"). Предложи название.
2. **Jackpot Mechanics:** Если просто делить $1.5 на всех — выигрыши будут копеечные. Предложи схему распределения, которая сводит с ума. (Например: "Winner takes 50%", "Лотерея среди лузеров"?).
3. **Transaction Farming:** Как заставить игрока делать транзакции не только на входе, но и ВНУТРИ игры, но чтобы он делал это с радостью? (Платные бустеры? Страховка от вылета?).

Дай мне 3 агрессивные экономические механики, которые превратят игру в казино.

Ты — Финансовый Аналитик и Game Economy Designer.
Мы проектируем экономику для Web3-игры на Base.
Модель: Платный вход $3.

ПРОБЛЕМА:
Если мы будем забирать $1.5 себе, а $1.5 отдавать в пул, игрокам может стать невыгодно играть (RTP - Return to Player слишком низкий). Они быстро уйдут.

ЗАДАЧА:
Посчитай математику и предложи сбалансированную модель "Play-to-Earn / Play-to-Airdrop":

1. **Unit Economics:** Расспиши таблицу распределения этих $3.
- Сколько на Gas (реалистично)?
- Сколько в Treasury (нам)?
- Сколько в Prize Pool?
- Сколько в "Next Game Discount" (на удержание)?

2. **Retention Reward:** Как мотивировать игрока, который проиграл свои $3, вернуться завтра? (Накопление поинтов? Кэшбек в нативном токене?).

3. **Base Builder Grant Strategy:** Нам нужно показать Base, что мы генерируем транзакции.
Предложи стратегию: В какой момент игры лучше всего вызывать транзакцию, чтобы это выглядело органично, а не как спам? (Level Up, Mint NFT-достижения, Claim Rewards).

Выдай конкретную таблицу с цифрами.

Привет, Claude. Нам нужна твоя помощь в качестве эксперта по блокчейн-разработке и безопасности.

**Задача:** Разработать план по интеграции ончейн-функций в нашу существующую игру.

**Главные приоритеты:**
1. **Максимальная безопасность:** Все решения должны приниматься с учетом минимизации рисков взлома, эксплойтов и потери активов игроков.
2. **Надежность:** Инфраструктура должна быть стабильной и масштабируемой.
3. **Эффективность:** Газовые издержки для игроков должны быть оптимизированы.

**Что нужно сделать:**

1. **Исследование основ:**
* Подготовь подробное руководство по языку программирования Solidity, охватывающее основные концепции, синтаксис, типы данных и лучшие практики для разработки безопасных смарт-контрактов.
* Опиши стандартные паттерны разработки смарт-контрактов (например, "Factory", "Proxy", "Singleton").
* Составь список наиболее распространенных уязвимостей в смарт-контрактах (Re-entrancy, Integer Overflow/Underflow, Front-running и т.д.) и объясни, как их избегать.

2. **Проектирование архитектуры:**
* Предложи архитектуру смарт-контрактов для игровых функций (например, владение NFT-предметами, внутриигровая валюта, система достижений).
* Опиши, как разделить логику между ончейн (на блокчейне) и оффчейн (на наших серверах) компонентами для достижения баланса между безопасностью и производительностью.

3. **План по обеспечению безопасности:**
* Разработай пошаговый процесс безопасной разработки (Secure Development Lifecycle) для наших смарт-контрактов. Он должен включать:
* Написание кода в соответствии с лучшими практиками.
* Обязательное модульное и интеграционное тестирование.
* Процедуру код-ревью.
* План проведения внешнего аудита безопасности.
* Составь чеклист для аудита безопасности смарт-контрактов.

Всю необходимую документацию по нашей игре я предоставлю по запросу. Начни с первого пункта – исследования основ Solidity и уязвимостей.

сейчас наша задача - имплементировать блокчейн в нашу игру. давай продумаем план того как будем это делать, и сделаем. газ

Improve this Web3/crypto game interface with modern design trends:
KEEP:
- Dark theme foundation
- Current layout structure and information hierarchy
- Core UI elements and functionality
- Brand colors
IMPROVE:
- Add premium glow effects (neon, holographic accents)
- Modern gradients with brand colors (vibrant → saturated)
- Glassmorphism cards with subtle borders and blur
- Depth through shadows, layering, and z-axis effects
- Animated particle effects or geometric background patterns
- Better visual hierarchy (emphasize CTAs, key metrics)
- Web3 aesthetic: neon accents, cyber elements, futuristic feel
- Interactive states: hover glows, button animations
- Typography: bolder headlines, better contrast
- Card designs: floating effect, inner shadows
- Color accent system: success (green), warning (orange), primary (brand)
Design language: Modern crypto gaming, premium, futuristic, high-energy
Target audience: Web3 natives, crypto enthusiasts, gamers
Inspiration: DeFi dashboards, modern gaming UIs, cyberpunk aesthetic

Далее с вашего позволения будут не так распространённо, а просто в дополнение к видео (ссылка на которое было, есть и будет в начале сей гайда) — ебану вам чёткий, выверенный промпт-гайд, который вы поэтапно будете скармливать вашему агенту

cat > claude.md << 'EOF'
# Правила проекта

## После КАЖДОЙ задачи — автоматическая верификация

Это не опционально. После выполнения любой задачи (написал код, пофиксил баг, добавил фичу) — СРАЗУ запусти проверку. Не жди когда попросят.

Порядок:
1. Выполнил задачу
2. СРАЗУ проверяй каждый изменённый компонент:
- Написал код → grep что функция/класс существует
- Изменил билд → npm run build или forge build
- Тесты есть → npm test или forge test
- Сервер → curl endpoint
- Фронт → проверь что компонент импортирован и рендерится
3. Покажи результат:
Пункт: [что проверял]
Проверка: [команда]
Результат: [вывод]
Вердикт: PASS / FAIL
4. В конце — таблица итогов

Запрещено:
- Говорить "готово" без проверки
- "Файл создан" без cat / grep
- "Должно работать" без запуска

## Безопасность
- .env НИКОГДА не коммитить в git
- Приватные ключи только в env, не в коде
- console.log(process.env) запрещён
- .env: только placeholder (0x_ВСТАВЬ_КЛЮЧ), не фейковые ключи

## Дисциплина фаз
- Выполняй ТОЛЬКО то что просят в текущем промпте
- Не забегай вперёд. Не делай "заодно".

## Деплой
- НЕ запускай деплой без явного "ОК" от пользователя

## Не проси копировать то что уже в проекте
- Адрес контракта → читай из docs/deploy.md (если нет — из contracts/broadcast/*/run-latest.json)
- ABI → читай из contracts/out/
- Архитектура → читай из docs/architecture.md
- Не проси пользователя вставлять адреса, ABI или конфиги вручную

## Лог проблем
- Нашёл проблему которую не фиксишь сейчас → запиши в ISSUES.md
- Формат: дата, фаза, критичность, описание, OPEN/FIXED
EOF

grep -qxF 'claude.md' .gitignore 2>/dev/null || echo "claude.md" >> .gitignore

## ЗАДАЧА
У меня есть работающая аркадная игра. Я планирую добавить в неё блокчейн (Web3 P2E на Base L2).
Подготовь мне **Context Brief** — объективную справку о текущем состоянии проекта.
Эту справку я передам в следующий промпт для проектирования ончейн-архитектуры.

⚠️ ВАЖНО: Описывай ТОЛЬКО то, что есть сейчас. Не предлагай решения, библиотеки или архитектурные изменения. Только факты.

## ФОРМАТ ОТВЕТА

### 1. Gameplay — что может делать игрок
Перечисли все доступные действия и реакции системы.
(Пример: «Игрок кликает → элементы мержатся → скор растёт. Есть таймер 90 секунд. По окончании — экран результата с итоговым скором.»)

### 2. Монетизируемые механики
Какие действия в игре ПОТЕНЦИАЛЬНО могут стоить денег или приносить деньги?
Просто перечисли факты:
- Что игрок делает, чтобы получить высокий скор?
- Есть ли соревновательный элемент? (лидерборд, PvP, турниры)
- Есть ли элемент случайности? (рандом, лотерея)
- Есть ли прогрессия? (уровни, апгрейды, валюта)
- Есть ли социальный элемент? (друзья, команды)

### 3. Экономика (если есть)
- Есть ли внутриигровая валюта? Как зарабатывается, как тратится?
- Есть ли магазин / апгрейды за валюту?
- Есть ли ограничения на игру? (энергия, жизни, таймеры)

### 4. Tech Stack
- Фреймворк и язык (React, Vue, vanilla JS)
- Бэкенд (есть/нет, на чём, какие endpoints)
- База данных (есть/нет, что хранит)
- Хостинг / деплой
- Структура ключевых файлов

### 5. Архитектура кода
- **Ключевые функции:** 5-8 главных функций, управляющих игровой логикой.
Формат: `имяФункции()` → что делает (одно предложение).
- **State:** Где хранится состояние игры? (store, context, useState, глобальные переменные?)
- **Score:** Как считается скор? Формула или описание. Где хранится (клиент/сервер)?
- **Валидация:** Проверяется ли скор на сервере? Или клиент = source of truth?

### 6. Что уже работает
Перечисли всё, что функционирует корректно.

### 7. Чего нет (факты, не рекомендации)
- **Блокчейн:** Есть ли что-то Web3? (подключение кошелька, контракты, токены)
- **Аутентификация:** Как идентифицируется игрок? (кошелёк, логин, анонимно?)
- **Anti-cheat:** Есть ли защита от накрутки скора?
- **API защита:** Rate limiting, CORS, auth на endpoints?

⚠️ СТОП-ПРАВИЛО: Не упоминай конкретные библиотеки, фреймворки или инструменты, которых НЕТ в текущем коде. Не пиши «нужно добавить X». Только описание текущего состояния.

Выдай компактным текстом и СОХРАНИ в файл `docs/context-brief.md` в проекте.

Я делаю Web3 Play-to-Earn аркадную игру на Base L2.
Сейчас — ТЕСТНЕТ (Base Sepolia). Токена НЕТ — только ETH как entry fee.

Прочитай файл docs/context-brief.md — это Context Brief моей игры.
(Если файла нет — скажи, я вставлю brief текстом.)

Спроектируй архитектуру ончейна для ОДНОГО контракта. Без токена, без ERC-20.

-—
## 1. Что на блокчейне, что на сервере?

Принцип: деньги и права — ончейн, игровая логика — оффчейн.
Для КАЖДОЙ механики из Context Brief — укажи: on-chain / off-chain — и почему.

## 2. Функции контракта

Один контракт должен содержать:

### Базовые:
- activate() — вход за ETH (entry fee). Подбери сумму исходя из механик игры.
- withdraw(amount) — owner забирает ETH из контракта
- pause() / unpause() — аварийная остановка

### Данные:
- totalPlayers — сколько активировано
- activatedAt[player] — когда активировался (timestamp)
- isActivated[player] — булевый статус

### Скоры (operator записывает):
- recordScore(player, score) — operator записывает скор
- playerScore[player] — текущий скор
- playerBestScore[player] — лучший скор (если имеет смысл для этой игры)

### Сезоны:
- currentSeason — номер сезона
- newSeason() — owner стартует новый
- seasonScores[season][player] — скоры по сезонам (замораживаются при newSeason)

Для КАЖДОЙ функции: что делает, кто может вызывать (owner/operator/anyone), какие проверки.

Если для ЭТОЙ КОНКРЕТНОЙ игры какие-то функции не нужны — скажи какие и почему.
Если нужны ДОПОЛНИТЕЛЬНЫЕ — предложи (но минимум, не раздувай).

## 3. Роли

- Owner: какие функции, какие ограничения
- Operator: какие функции (только запись скоров? или ещё что-то?)
- Player: что может, что не может

## 4. Поток денег

Нарисуй flow: игрок платит → куда идёт ETH → как потом выводится.
Для ЭТОЙ игры — на основе её механик.

## 5. Free vs Activated

На основе механик игры определи:
- Что может FREE игрок (без оплаты)
- Что может ACTIVATED игрок (после activate())
- Что конкретно блокируется без активации (лидерборд? глобальный счётчик?)

-—
## ⚠️ ОГРАНИЧЕНИЯ

- Контракт IMMUTABLE (не upgradeable). Без proxy pattern.
- Один контракт. Не два, не три.
- Без ERC-20 токена. Только ETH.
- Без Chainlink, VRF, Uniswap — ничего внешнего.
- Каждое число (entry fee, лимиты) — предложение с обоснованием: «предлагаю X, потому что...»
- Этот output пойдёт в Phase 1 (код контракта) — будь конкретен.

Не пиши код. Только архитектуру, функции и таблицы.

-—
СОХРАНИ результат в файл docs/architecture.md

Напиши игровой контракт, тесты и деплой скрипт для Base Sepolia.

Прочитай файлы:
- docs/architecture.md — утверждённая архитектура (функции, роли, поток денег)

## КОНТРАКТ

Реализуй ВСЕ функции из утверждённой архитектуры. Примерный скоуп
(адаптируй под архитектуру):

### Базовые:
- activate() payable — вход за ETH. Проверка: не активирован, не на паузе, msg.value >= fee.
- withdraw(amount) — только owner. Вывод ETH.
- pause() / unpause() — только owner.

### Данные:
- isActivated[player] — bool
- activatedAt[player] — block.timestamp при активации
- totalPlayers — counter

### Скоры (operator пишет):
- recordScore(player, score) — только operator. Обновляет текущий скор.
Если score > bestScore → обновить bestScore.
- **MAX_SCORE** — константа. Максимально возможный скор (из anti-cheat порогов в 0.2). `require(score <= MAX_SCORE)` в recordScore. Без этого оператор (или атакующий с ключом оператора) может записать любой скор.
- playerScore[player] — текущий скор (сбрасывается при новом сезоне)
- playerBestScore[player] — лучший за всё время

### Сезоны:
- currentSeason — uint256, стартует с 1
- newSeason() — только owner. Инкрементирует season.
- seasonScores[season][player] — замораживает скор при записи.
recordScore пишет одновременно в playerScore и seasonScores[currentSeason].

### Обязательные паттерны:
- ReentrancyGuard (OpenZeppelin) на activate и withdraw
- Ownable2Step (двухэтапная передача ownership)
- **renounceOwnership() — ЗАБЛОКИРОВАТЬ.** Ownable2Step наследует renounceOwnership() от OpenZeppelin. Если кто-то вызовет — контракт останется без owner НАВСЕГДА: нельзя pause, withdraw, newSeason. Override и revert:
`function renounceOwnership() public pure override { revert("disabled"); }`
- Pausable
- **CEI Pattern — СТРОГО.** В каждой функции с ETH: сначала все require (Checks), потом все изменения состояния (Effects: запись в mapping, обновление counter), и ТОЛЬКО ПОТОМ отправка ETH (Interactions). Нарушение порядка = reentrancy уязвимость. AI должен проверить CEI в КАЖДОЙ функции и прокомментировать.
- Custom errors вместо require строк (дешевле по газу)
- Events для всех значимых действий
- NatSpec комментарии на каждую публичную функцию

### Роли:
- Owner: pause, unpause, withdraw, newSeason, setOperator, setEntryFee
- Operator: recordScore. Только operator.
- Player: activate. Чтение — public (view функции).

-—
## ТЕСТЫ (Foundry)

Покрой ВСЕ функции:

**Для каждой функции:**
- Happy path
- Revert: неправильная роль (не operator, не owner)
- Revert: неправильные параметры (нулевой amount, уже активирован, недостаточно ETH)
- Event проверки (vm.expectEmit)

**Access control:**
- Только operator может recordScore
- Только owner может pause/withdraw/newSeason/setOperator
- Random address НЕ может вызвать protected функции

**Edge cases:**
- Повторная активация → revert
- recordScore для неактивированного игрока → revert (или разрешить? — на основе архитектуры)
- recordScore с score > MAX_SCORE → revert
- withdraw больше чем баланс → revert
- Операции при паузе → revert
- newSeason → старые seasonScores заморожены, новые пишутся в новый сезон
- renounceOwnership() → revert (заблокирована)

**setUp():**
- Деплой контракта
- Установить operator
- Создать тестовые адреса (owner, operator, player1, player2)
- vm.deal для ETH балансов

Файл: test/[Name]Game.t.sol

-—
## ДЕПЛОЙ СКРИПТ (Base Sepolia)

1. Deploy Game Contract
2. Set operator address
3. Логировать адрес контракта (console.log)

Скрипт:
- vm.startBroadcast() / vm.stopBroadcast()
- Работает с: forge script script/Deploy.s.sol:Deploy --rpc-url https://sepolia.base.org --broadcast --verify --etherscan-api-key $BASESCAN_API_KEY -vvvv

Файл: script/Deploy.s.sol

-—
## ВЕРИФИКАЦИЯ КОНТРАКТА (BaseScan)

Для `--verify` нужен API ключ. У Etherscan единый ключ — он работает на всех их эксплорерах (Etherscan, BaseScan, Arbiscan и т.д.):
1. Зайди на https://etherscan.io/apidashboard → Sign Up (если нет аккаунта) → Create API Key
2. Один ключ работает на всех сетях включая Base Sepolia
3. Добавь в .env: BASESCAN_API_KEY=твой_ключ
4. В foundry.toml уже настроено:
[etherscan]
base_sepolia = { key = "${BASESCAN_API_KEY}", url = "https://api-sepolia.basescan.org/api" }

Верификация = исходный код контракта виден на Basescan.
Без неё: на Basescan виден только байткод (нечитаемый). Никто не может проверить что контракт делает.
С верификацией: любой видит исходный Solidity код, может вызывать функции прямо с Basescan.

### Если верификация не проходит

Частая проблема: `Unable to locate ContractCode` — BaseScan Sepolia ещё не проиндексировал контракт. Контракт задеплоен (можешь проверить `cast code АДРЕС --rpc-url https://sepolia.base.org` — вернёт байткод), но API тормозит.

**Что делать:**
1. Подожди 2-5 минут и повтори `forge verify-contract`
2. Если не помогает — попробуй с явным `--verifier-url https://api-sepolia.basescan.org/api`
3. Всё ещё нет — верифицируй вручную: зайди на `https://sepolia.basescan.org/address/АДРЕС` → Contract → Verify & Publish → вставь код
4. На тестнете это НЕ блокер. Контракт работает без верификации. Верификация = удобство (видеть код на BaseScan). Можешь вернуться позже.

Не проси AI долбить retry в цикле — это трата времени. Подожди или верифицируй вручную.

-—
## FOUNDRY SETUP

Также дай:
1. Команды для forge init + установки OpenZeppelin
2. foundry.toml с remappings
3. Проверочную команду (forge build)
4. `.gitignore` — ОБЯЗАТЕЛЬНО добавь: `.env`, `broadcast/`, `cache/`, `out/`. Файл `.env` содержит приватные ключи — если он попадёт в git, боты автоматически сканят GitHub и крадут ключи за секунды.
5. `.env` файл — ОБЯЗАТЕЛЬНО создай с placeholder'ами:
PRIVATE_KEY=0x_ВСТАВЬ_OWNER_ПРИВАТНЫЙ_КЛЮЧ
OPERATOR_PRIVATE_KEY=0x_ВСТАВЬ_ПРИВАТНЫЙ_КЛЮЧ_ОПЕРАТОРА
OPERATOR_ADDRESS=0x_ВСТАВЬ_АДРЕС_ОПЕРАТОРА
BASE_SEPOLIA_RPC_URL=https://sepolia.base.org
BASESCAN_API_KEY=ВСТАВЬ_КЛЮЧ_С_ETHERSCAN
Деплой скрипту нужен OPERATOR_ADDRESS (для setOperator). OPERATOR_PRIVATE_KEY — для бэкенда (Фаза 2), но сохрани сразу чтобы не потерять.
НЕ вставляй тестовые/фейковые ключи от Hardhat или Anvil. Только placeholder'ы.

-—
## ⚠️ ОГРАНИЧЕНИЯ

- Solidity ^0.8.24
- OpenZeppelin contracts (последняя версия)
- Контракт IMMUTABLE. Без proxy.
- Без ERC-20 токена. Только ETH.
- Entry fee — фиксированный в wei (для тестнета).
Пиши TODO-комментарий: "Chainlink Price Feed для mainnet (если привязка к USD)"
- Все числа (fee, лимиты) — из утверждённой архитектуры 0.1

## 🚫 СТОП — ТОЛЬКО КОНТРАКТ

Этот промпт создаёт ТОЛЬКО эти файлы (проверь что ВСЕ созданы):
1. `src/Game.sol` — Solidity контракт
2. `test/Game.t.sol` — тесты
3. `script/Deploy.s.sol` — деплой скрипт
4. `foundry.toml` — конфиг Foundry
5. `.env` — с placeholder'ами (PRIVATE_KEY, OPERATOR_PRIVATE_KEY, OPERATOR_ADDRESS, BASESCAN_API_KEY). НЕ пропускай этот файл.
6. `.gitignore` — включает .env, out/, cache/, broadcast/

Если забыл создать любой из 6 файлов — создай сейчас.

НЕ ДЕЛАЙ в этом промпте:
- Бэкенд (сервер, API, Express, база данных) — это Фаза 2
- Фронтенд (React компоненты, wagmi, кошелёк) — это Фаза 3
- PRNG, heartbeat, session API — это Фаза 2
- Никакого JavaScript/TypeScript кроме деплой скрипта

Если хочется "заодно сделать бэкенд" — СТОП. Сначала контракт должен компилироваться, тесты проходить, деплой работать. Потом следующая фаза.

## 🚀 ПОСЛЕ КОДА — ПРОВЕДИ ЧЕРЕЗ ДЕПЛОЙ

Когда контракт написан, тесты проходят — НЕ просто покажи команду деплоя. Проведи пользователя пошагово:

1. **Кошельки:** спроси — "У тебя есть два кошелька (owner + operator)? Если нет — давай создадим."
- Объясни: нужны два отдельных кошелька в MetaMask (или другом). Owner = главный, Operator = для записи скоров.
- Покажи как получить адреса и приватные ключи из MetaMask.

2. **Тестовый ETH:** "Тебе нужен тестовый ETH на Base Sepolia. Два варианта:"

**Вариант А — напрямую Base Sepolia faucet:**
- https://www.alchemy.com/faucets/base-sepolia
- https://faucet.quicknode.com/base/sepolia

**Вариант Б — Sepolia ETH + бридж (если фаусеты не работают):**
- Получи Sepolia ETH: https://testnetbridge.com/sepolia
- Бриджани в Base Sepolia: https://testnets.relay.link/bridge/sepolia

Нужно на оба кошелька (owner для деплоя, operator для gas на recordScore).

3. **BaseScan API ключ:** "Для верификации контракта нужен API ключ. Зайди на https://etherscan.io/apidashboard → Sign Up → Create API Key. Один ключ работает на всех сетях (Ethereum, Base, Arbitrum)."

4. **Создай .env:** Если файл `contracts/.env` не существует — создай его с placeholder'ами. Потом скажи пользователю: "Открой contracts/.env и замени placeholder'ы на свои реальные ключи:
- PRIVATE_KEY=твой_owner_приватный_ключ
- OPERATOR_PRIVATE_KEY=приватный_ключ_оператора (для бэкенда в Фазе 2, но сохрани сейчас чтобы не потерять)
- OPERATOR_ADDRESS=адрес_кошелька_оператора (для setOperator в деплой скрипте)
- BASESCAN_API_KEY=твой_ключ_с_etherscan"

5. **Подтверждение:** "Готово? Скажи ОК — и я запущу деплой."

6. **Деплой + верификация:** только после подтверждения — запусти forge script.

7. **После деплоя:** покажи адрес контракта, ссылку на BaseScan, проверь что верификация прошла. **Сохрани адрес в `docs/deploy.md`** (адрес контракта, сеть, txHash). При переходе к Фазе 3 (фронтенд) — сам добавь VITE_CONTRACT_ADDRESS в .env фронтенда. Не проси пользователя копировать адрес вручную — ты его уже знаешь.

НЕ пропускай шаги 1-5. НЕ запускай деплой без подтверждения пользователя.

Напиши бэкенд для хранения скоров, лидерборда и heartbeat.

Мой стек: [TypeScript/Node.js/Python — что используешь] БД: PostgreSQL (Railway)

Контракт задеплоен на Base Sepolia: прочитай адрес из docs/deploy.md (если нет — найди в contracts/broadcast//run-latest.json) ABI контракта: прочитай из contracts/out//Game.json (или docs/architecture.md для списка функций) Библиотека: viem (для TypeScript) или web3.py (для Python)

Архитектура (из 0.1):

Прочитай docs/architecture.md — секции роли, operator, поток денег.

1. База данных

Таблицы:

• players: wallet_address (PK), activated_at, total_score, best_score, current_season_score
• scores: id, wallet_address, score_delta, session_id, timestamp, flagged (bool)
• heartbeats: id, wallet_address, session_id, timestamp, client_data (JSON)
• sessions: id, wallet_address, started_at, expires_at, ended_at, total_score, heartbeat_count

Миграции или ORM модели — на твоё усмотрение.

2. API Endpoints

POST /api/score

Клиент отправляет дельту скора.

• Проверка: wallet_address активирован? (кэш или запрос в контракт)
• Проверка: heartbeat свежий? (последний < [X] секунд назад)
• Сохранить в scores table
• Обновить player total_score и current_season_score

POST /api/heartbeat

Клиент пингует каждые [X] секунд.

• Записать в heartbeats table
• Вернуть: { ok: true, server_time: timestamp }

GET /api/leaderboard

Топ-100 игроков текущего сезона.

• Только activated игроки
• Поля: rank, wallet_address (сокращённый 0x123...abc), score, activated_at
• Кэш: обновлять раз в [X] секунд

GET /api/player/:address

Профиль игрока.

• score, best_score, rank, season_scores, activated_at
• is_activated (из контракта или кэша)

3. Blockchain модуль (operator)

Бэкенд подписывает транзакции от имени operator wallet:

recordScore(player, score) — запись ончейн

• Когда вызывать: конец сезона / по крону / по достижении порога
• Retry при failed транзакциях (nonce issues)
• Логирование txHash

Чтение (бесплатно):

• isActivated(address) — проверка при первом запросе + кэш
• totalPlayers() — для лидерборда
• currentSeason() — для фильтрации скоров

Конфигурация через env (адрес контракта — возьми из docs/deploy.md):

• GAME_CONTRACT_ADDRESS
• OPERATOR_PRIVATE_KEY
• RPC_URL=https://sepolia.base.org

Обработка ошибок:

• Retry с экспоненциальным backoff
• Алерт если gas balance оператора < 0.001 ETH
• Все tx логируются в таблицу transactions (hash, status, gas_used)

4. CORS + Rate Limiting + Аутентификация

• CORS: только [ДОМЕН ФРОНТЕНДА]
• Rate limit: [N] запросов/мин на IP
• Payload size limit: 10KB

Аутентификация запросов:

POST endpoints (/api/score, /api/heartbeat) должны проверять что запрос от реального владельца кошелька:

• При старте сессии: клиент подписывает сообщение кошельком (signMessage) → отправляет подпись на бэкенд
• Бэкенд: проверяет подпись (ecrecover / verifyMessage) → если подпись валидна, выдаёт session token
• Все последующие запросы: клиент отправляет session token в header (Authorization: Bearer ...)
• Без валидной подписи / токена → 401 Unauthorized

Это критично: без аутентификации любой может отправить curl POST /api/score с чужим адресом.

Безопасность сессий (обязательно):

• TTL: Каждая сессия имеет expires_at. По умолчанию 30 минут (или длина сезона/раунда). Middleware проверяет expires_at на КАЖДОМ запросе. Просроченный токен = 401. Без TTL: украденный токен = бесконечный доступ.
• Одна активная сессия: При создании новой сессии — закрыть все предыдущие незакрытые сессии этого игрока (ended_at = NOW). Без этого: игрок открывает 10 вкладок = 10 параллельных сессий = фарм.
• Валидация входных данных: Все поля в POST body — whitelist. Только ожидаемые поля, только ожидаемые типы. client_data в heartbeat — либо строгая схема, либо убрать. Произвольный JSON = вектор атаки.
• Скоры — только целые числа: Number.isInteger(score) перед записью. Float (15.5) пройдёт валидацию "score > 0" но крашит BigInt() при записи ончейн. Проверяй тип ДО любой обработки.

5. ДЕПЛОЙ НА RAILWAY

После того как код написан и работает локально — задеплой на Railway:

5.1 Проверь CLI:

bash

railway --version

Если нет — установи и залогинься:

bash

npm i -g @railway/cli
railway login

5.2 Создай проект + БД:

bash

cd server/
railway init
railway add --database postgres

5.3 Добавь env переменные:

bash

railway variables set OPERATOR_PRIVATE_KEY=0x_ВСТАВЬ_КЛЮЧ_ОПЕРАТОРА
railway variables set GAME_CONTRACT_ADDRESS=0x_АДРЕС_КОНТРАКТА
railway variables set RPC_URL=https://sepolia.base.org
railway variables set CORS_ORIGIN=http://localhost:5173

DATABASE_URL и PORT — Railway добавит автоматически. GAME_CONTRACT_ADDRESS — возьми из docs/deploy.md.

5.4 Деплой:

bash

railway up
railway domain

5.5 Проверь:

bash

curl https://RAILWAY_URL/api/leaderboard

Должен вернуть [] (пустой массив). Если 500 — миграции не прошли, запусти:

bash

railway run node migrate.js
# или: railway run npx prisma migrate deploy

5.6 Сохрани:

Запиши Railway URL в docs/deploy.md рядом с адресом контракта.

🚫 ТОЛЬКО БЭКЕНД

Этот промпт создаёт ТОЛЬКО эти файлы (проверь что ВСЕ созданы):

1. server/ (или backend/) — Express/Fastify сервер, API endpoints, operator модуль
2. server/.env — ОБЯЗАТЕЛЬНО создай с placeholder'ами: OPERATOR_PRIVATE_KEY=0x_ВСТАВЬ_OPERATOR_ПРИВАТНЫЙ_КЛЮЧ GAME_CONTRACT_ADDRESS=0x_АДРЕС_КОНТРАКТА (возьми из docs/deploy.md или broadcast) RPC_URL=https://sepolia.base.org DATABASE_URL=postgresql://... (Railway добавит автоматически после деплоя) PORT=3001 CORS_ORIGIN=http://localhost:5173 Без этого файла: кто деплоит не на Railway — не будет знать какие env vars нужны.
3. server/.gitignore — включает .env
4. PostgreSQL схема (миграция или init SQL)

НЕ трогай: контракт (уже задеплоен), фронтенд (React, UI) — это Фаза 3.

Если забыл создать .env — создай сейчас. После написания кода — ОБЯЗАТЕЛЬНО выполни секцию 5 (деплой на Railway). Не останавливайся на "код готов".

Напиши модуль серверной валидации для моей игры.

Механика (из Context Brief):
-— Прочитай docs/context-brief.md — секция Gameplay.

## 1. Валидация при записи скора

### Hard reject (отклонить, не сохранять):
На основе КОНКРЕТНЫХ механик игры определи нереальные значения:
- Score/second > [порог] → reject
- Session length < [min] секунд → reject (слишком быстро)
- Session length > [max] часов → reject (забыл выключить)
- Score > теоретический максимум за session → reject

### Soft flag (сохранить, пометить):
- Идеальная регулярность (bot pattern: ровно N действий каждые M мс)
- Score в top 1% за сессию → flag для ручной проверки
- Новый аккаунт + аномально высокий скор → flag

## 2. Heartbeat валидация

- Ожидаемый интервал: [X] секунд ± [Y]% допуск
- Пропуск > [Z] пингов подряд → сессия помечается как suspicious
- Отсутствие heartbeat при высоком score → reject

## 3. Rate limiting

- Макс [N] записей скора в час на адрес
- Макс [M] сессий в день на адрес
- Хранение в БД (не in-memory — чтобы пережило рестарт)

## 4. Агрегация и алерты

- 3+ soft flags за день от одного адреса → пометить аккаунт
- Flagged аккаунты: скоры не участвуют в лидерборде
- Не блокировать моментально — собирать данные, разбирать потом

## 5. Middleware

Сделай middleware/decorator который:
1. Проверяет hard limits → reject с кодом 422
2. Проверяет soft limits → flag в БД, вернуть 200
3. Проверяет rate limit → reject с кодом 429
4. Логирует каждую проверку

Интегрируй с endpoints из промпта 2.1.

Добавь Web3 кошелёк в мой [React / Next.js / Vue] фронтенд.

Мой стек:
-— Прочитай docs/context-brief.md — секция Tech Stack.
-—
Используй:
- wagmi v2 + viem — для взаимодействия с блокчейном
- ConnectKit или RainbowKit — для UI кнопки подключения (выбери что проще интегрировать с моим стеком)
- Сеть: Base Sepolia (testnet, chainId 84532)

Дай мне:

1. **Установка пакетов** — npm install команда

2. **wagmi конфигурация** — файл config/wagmi.ts:
- Base Sepolia chain
- HTTP transport. RPC URL из env переменной (import.meta.env.VITE_RPC_URL или process.env.NEXT_PUBLIC_RPC_URL), fallback на публичный https://sepolia.base.org
- Используй ConnectKit или RainbowKit — они включают WalletConnect из коробки (встроенный projectId, ручная регистрация не нужна)

3. **Провайдер-обёртка** — обернуть App:
- WagmiProvider
- QueryClientProvider (TanStack Query — wagmi v2 требует)

4. **Компонент ConnectButton:**
- Не подключён → кнопка "Connect Wallet"
- Подключён → показать адрес (0x123...abc), баланс ETH, кнопка Disconnect
- Неправильная сеть → кнопка "Switch to Base Sepolia"

5. **Хук useAccount** — как получить текущий адрес, isConnected, chain

Важно:
- Автоматический switch на Base Sepolia при подключении
- Обработка ошибок (пользователь отклонил, кошелёк не установлен)
- Не ломай существующий UI — кнопка должна вписаться в текущий дизайн
- RPC URL через env переменную, не хардкодом

Напиши React хуки (wagmi v2) для взаимодействия с моим контрактом.

Контракт: прочитай адрес из docs/deploy.md. Если файла нет — найди в contracts/broadcast/*/run-latest.json (поле contractAddress). Добавь в .env фронтенда как VITE_CONTRACT_ADDRESS (если ещё нет).
ABI: прочитай из contracts/out/*/Game.json

Создай хуки:

### useActivate()
- Отправить ETH (entry fee) в контракт → activate()
- Возвращает: { activate, isPending, isSuccess, error, txHash }
- После успеха: показать "Activated!" + обновить статус

### useIsActivated(address)
- Прочитать isActivated[address] из контракта
- Возвращает: { isActivated, isLoading }
- Кэш: refetch при подключении кошелька и после activate()

### usePlayerScore(address)
- Прочитать playerScore[address] и playerBestScore[address]
- Возвращает: { score, bestScore, isLoading }

### useLeaderboard()
- Запрос к бэкенду GET /api/leaderboard (не из контракта — слишком дорого)
- Возвращает: { players: [{rank, address, score}], isLoading }
- Auto-refresh каждые [X] секунд

### useGameStats()
- Прочитать из контракта: totalPlayers, currentSeason, contract balance
- Возвращает: { totalPlayers, currentSeason, treasuryETH, isLoading }

### useEntryFee()
- Прочитать ENTRY_FEE из контракта
- Возвращает: { fee (в wei), feeFormatted (в ETH), isLoading }

Каждый хук:
- Возвращает loading/error/data
- Обрабатывает ошибки (показать revert reason человеческим языком)
- Показывает pending транзакции (отправлена → подтверждена)

Файл: src/hooks/useContract.ts (или разбей на отдельные файлы)

У меня есть работающая игра и хуки контракта (из промпта 3.2).
Нужно интегрировать ончейн в существующий UI.

Мой текущий UI:
-— Прочитай docs/context-brief.md — секции UI/экраны.
-—
Хуки доступны: useActivate, useIsActivated, usePlayerScore, useLeaderboard,
useGameStats, useEntryFee (из промпта 3.2)

## 1. Два режима: FREE и ACTIVATED

### FREE (кошелёк не подключён ИЛИ не активирован):
- Игрок играет как обычно
- Скоры хранятся в localStorage (как сейчас)
- НЕ показывать в лидерборде
- Скоры НЕ идут на бэкенд
- Показать баннер: "Activate for $3 to join leaderboard and earn rewards"

### ACTIVATED (кошелёк подключён + activate() вызван):
- Скоры идут на бэкенд (POST /api/score)
- Heartbeat активен (POST /api/heartbeat каждые [X] секунд)
- Показывать в лидерборде
- Показать: rank, score, % от общего (вклад в пул)
- Прогресс НЕ переносится из FREE — начинает с нуля (anti-abuse)

## 2. Компоненты

### ActivationBanner
- Показывать FREE игрокам
- Текст: что даёт активация (leaderboard, rewards, on-chain scores)
- Кнопка "Activate for [FEE] ETH"
- При клике → useActivate() → pending → success → скрыть баннер

### PlayerStatus
- FREE: "Free Mode — scores are local only"
- ACTIVATED: "Activated ✓ — Season [N] — Rank #[X]"
- Адрес кошелька (сокращённый)

### Leaderboard (обновлённый)
- Только ACTIVATED игроки (данные из /api/leaderboard)
- Колонки: Rank, Player (0x123...abc), Score, % Contribution
- % Contribution = player_score / total_all_scores × 100
- Подсветить текущего игрока

### GameStats (из контракта)
- Total Players: [N]
- Treasury: [X] ETH
- Current Season: [N]
- Данные из useGameStats() — прямо из блокчейна, верифицируемые

## 3. Обработка ошибок

Для каждого on-chain действия:
- Кошелёк не подключён → "Connect wallet first"
- Неправильная сеть → "Switch to Base Sepolia"
- Недостаточно ETH → "You need at least [FEE] ETH"
- Транзакция отклонена → "Transaction cancelled"
- Транзакция pending → spinner + "Confirming..."
- Транзакция успешна → "Activated! Welcome to Season [N]"

## 4. Flow

Нарисуй обновлённый flow и напиши код для интеграции с МОИМ существующим UI.
Не переписывай всё — минимальные изменения в существующих компонентах.

## 5. Размещение компонентов в UI

### Leaderboard — ОБЯЗАТЕЛЬНО видимый:
- Встрой в главный экран игры (таб, сайдбар, нижняя панель — выбери что подходит к текущему layout)
- НЕ прячь на отдельную страницу без ссылки — игрок должен видеть лидерборд без лишних кликов
- Обновляется при каждом открытии (GET /api/leaderboard)
- Если экран маленький — сделай переключатель Game / Leaderboard

### ActivationBanner:
- Показывать на главном экране ДО и ВО ВРЕМЯ игры (пока FREE)
- После активации — убрать навсегда

### PlayerStatus + GameStats:
- В header или над игровым полем — всегда видны

## 5. Интеграция

Посмотри мой текущий UI (прочитай код компонентов) и напиши КОД интеграции.
Не переписывай всё — минимальные изменения в существующих компонентах.
Покажи какие файлы трогаешь и что именно меняешь.

Адаптируй мой фронтенд для мобильных устройств.

Мой стек:
---
Прочитай docs/context-brief.md — секция Tech Stack.
---

Текущее состояние: десктоп работает, Web3 интегрирован (кошелёк, хуки, FREE/ACTIVATED).

---

## 1. МОБИЛЬНЫЙ КОШЕЛЁК

### Deep links:
- Обычный мобильный браузер (нет window.ethereum) → кнопка Connect должна открывать MetaMask/Coinbase через deep link
- ConnectKit/RainbowKit уже поддерживают это — проверь что НЕ сломано кастомным CSS или обёрткой
- Если используется кастомная кнопка Connect вместо стандартной — убедись что мобильный flow работает

### MetaMask in-app browser:
- window.ethereum есть → стандартный flow
- Проверь: после подключения кошелёк остаётся подключённым при навигации между страницами
- Проверь: транзакция activate() открывает подтверждение корректно (не дублируется, не зависает)

### WalletConnect:
- QR код на десктопе, deep link на мобилке — ConnectKit/RainbowKit делают автоматически
- Проверь что WalletConnect modal не обрезается на маленьком экране

---

## 2. RESPONSIVE UI

### Точки перелома (breakpoints):
- Мобилка: < 640px
- Планшет: 640px — 1024px
- Десктоп: > 1024px

### Критичные элементы (проверь каждый на 375px ширины):

**ActivationBanner:**
- Полная ширина экрана, текст не обрезается
- Кнопка "Activate for X ETH" — минимум 44px высоты, тапается без промахов
- Не перекрывает игровое поле

**Leaderboard:**
- На мобилке: убрать или сократить колонку % Contribution
- Адреса кошельков: 0x12...ab (короче чем на десктопе)
- Скролл горизонтальный НЕ нужен — таблица должна влезать

**GameStats (Total Players, Treasury, Season):**
- Горизонтальный ряд на десктопе → вертикальный стак или 2×2 grid на мобилке

**Модалки (транзакция pending, ошибки):**
- Не выходят за экран
- Закрываются тапом на overlay
- Текст читаем (минимум 14px)

**Connect Wallet кнопка:**
- Видна без скролла (в header или sticky)
- После подключения: адрес сокращён (0x12...ab), не ломает layout

---

## 3. ТАЧ-КОНТРОЛЫ

- Все интерактивные элементы: минимум 44×44px (Apple HIG стандарт)
- Убрать hover-эффекты на мобилке (или заменить на :active)
- Если игра использует клики — проверь что тач-события работают (touchstart/touchend vs click)
- Свайпы: не конфликтуют с жестами кошелька или браузера (pull-to-refresh, back swipe)
- Двойной тап: не вызывает зум на кнопках (добавить touch-action: manipulation)

---

## 4. ПРОИЗВОДИТЕЛЬНОСТЬ НА МОБИЛКЕ

- RPC запросы (чтение контракта) — кэшируй через wagmi (staleTime).
Мобильный интернет медленнее — не дёргай контракт на каждый ре-рендер.
- Анимации — проверь fps на реальном телефоне (не эмулятор). Тяжёлые анимации убей или упрости для мобилки.
- Bundle size — если используешь мобильные deep links, НЕ добавляй лишние wallet SDK. ConnectKit/RainbowKit уже всё включает.

---

## 5. ТЕСТИРОВАНИЕ

Проверь на реальном устройстве (не эмулятор):
- [ ] iPhone Safari → Connect Wallet → deep link в MetaMask → вернулся → кошелёк подключён
- [ ] MetaMask Mobile in-app browser → Connect → Activate → транзакция прошла
- [ ] Android Chrome → Connect Wallet → deep link работает
- [ ] Лидерборд читаем на 375px экране
- [ ] Все кнопки тапаются без промахов
- [ ] Модалки не обрезаются
- [ ] Игра работает (тач, fps, нет лагов)

Если нет реального устройства — Chrome DevTools → Toggle Device Toolbar → iPhone SE (375px).
Но мобильный кошелёк можно протестировать ТОЛЬКО на реальном телефоне.

---

## ⚠️ ОГРАНИЧЕНИЯ

- НЕ переписывай игровую логику. Только UI адаптация и мобильный кошелёк.
- НЕ добавляй отдельное мобильное приложение — только responsive web.
- НЕ ломай десктоп. Все изменения — адаптивные (media queries / контейнерные запросы).
- Если игра использует Canvas — тач-адаптация Canvas отдельно (touch events, viewport scaling).

Проведи security review моего контракта.

Прочитай файл contracts/src/*.sol

Проверь по чеклисту:

REENTRANCY:
- Есть ли nonReentrant на всех state-changing функциях?
- Соблюдается ли CEI pattern (effects before interactions)?
- Есть ли внешние вызовы после изменения стейта?

ACCESS CONTROL:
- Все ли критические функции за модификаторами (onlyOwner, onlyOperator)?
- Используется ли msg.sender (не tx.origin)?
- Ownable2Step вместо Ownable?
- renounceOwnership() заблокирована? (override → revert). Без этого: случайный вызов = контракт без owner навсегда.
- Может ли owner получить слишком много власти? (централизация)

ВХОДНЫЕ ДАННЫЕ:
- Есть ли MAX_SCORE константа? recordScore проверяет score <= MAX_SCORE?
- Есть ли проверка score > 0?
- Есть ли проверка что player != address(0)?
- Entry fee: что если кто-то отправит 0 ETH? (msg.value >= fee)

МАТЕМАТИКА:
- Overflow/underflow? (Solidity 0.8+ проверяет, но проверь edge cases)
- Деление на ноль?
- Что если totalPlayers = 0 при расчётах?

ЛОГИКА:
- Можно ли активироваться дважды?
- Можно ли записать скор неактивированному игроку?
- Что если owner забирает ВСЕ ETH из контракта?
- Работают ли сезоны корректно при переходе?

DOS:
- Может ли один адрес заблокировать систему?
- Есть ли лимиты на массивы?

EVENTS:
- Все ли важные действия логируются?
- Хватит ли информации в events для восстановления состояния?

Для каждой проблемы:
- Severity: Critical / High / Medium / Low / Info
- Описание
- Рекомендация по исправлению
- Код фикса (если применимо)

После аудита: все Critical и High → фикси сразу. Medium и ниже → запиши в ISSUES.md с датой и пометкой 🟡/🟢.

Проведи security review бэкенда моей Web3 игры.

Прочитай файлы в server/ (или backend/) — ключевые endpoints и middleware.

Проверь:

API:
- SQL Injection: parameterized queries?
- XSS: санитизация входных данных?
- Rate limiting: есть?
- CORS: ограничены домены (не wildcard *)?
- Payload size limit?

АУТЕНТИФИКАЦИЯ:
- POST endpoints защищены подписью кошелька?
- Можно ли отправить скор от чужого адреса без его подписи?
- Session tokens: как создаются, сколько живут, хранятся ли в БД?
- Можно ли переиспользовать чужой session token?
- Проверяется ли wallet_address из токена, а не из тела запроса?

СЕССИИ:
- TTL: есть ли expires_at? Middleware проверяет на каждом запросе?
- Параллельные сессии: может ли один игрок иметь N активных сессий? (должна быть одна)
- При создании новой — закрываются ли старые?
- Что происходит при использовании просроченного токена? (должен быть 401)

ВАЛИДАЦИЯ ВХОДНЫХ ДАННЫХ:
- Скоры: проверяется ли Number.isInteger(score)? (float крашит BigInt при ончейн записи)
- Скоры: проверяется ли score > 0 и score <= MAX_SCORE?
- client_data в heartbeat: whitelist полей или произвольный JSON? (произвольный = вектор атаки)
- Все POST body: проверяются ли типы каждого поля? (не только наличие)

OPERATOR КЛЮЧ:
- Где хранится OPERATOR_PRIVATE_KEY?
- Разделены ли Owner и Operator?
- Если украдут Operator ключ — что максимум может сделать атакующий?
(recordScore — плохо, но не критично. withdraw — катастрофа.)

HEARTBEAT:
- Можно ли спуфить heartbeat без реальной игры?
- Достаточен ли интервал для обнаружения ботов?

RACE CONDITIONS:
- Два одновременных recordScore для одного игрока?
- Два одновременных score submit?

ДАННЫЕ:
- Что in-memory vs в БД? (ничего важного не должно быть только in-memory)
- Бэкапы БД?

Для каждой проблемы: severity + описание + рекомендация.
Critical/High → фикси сразу. Medium и ниже → в ISSUES.md.

Иерархия ключей

OWNER KEY (самый ценный)
│ Может: pause, withdraw, newSeason, setOperator
│ Хранение: отдельный кошелёк, НЕ повседневный
│ Используется: редко (настройка, emergency)
│
├── OPERATOR KEY (рабочий)
│ Может: только recordScore
│ Хранение: env variable на сервере
│ Используется: постоянно
│ Если утёк: неприятно, но деньги в безопасности
│
└── PLAYER KEY (у пользователя)
Может: activate (тратить свой ETH)
Ты НЕ контролируешь

Помоги настроить безопасность ключей для моей Web3 игры.
Принцип: owner и operator — РАЗНЫЕ кошельки.

Текущее состояние:
- Owner = deployer wallet (private key в .env)
- Operator = [тот же или отдельный] wallet
- Контракт на Base Sepolia

-—
## 1. РАЗДЕЛЕНИЕ КЛЮЧЕЙ:
- Operator wallet: отдельный от deployer, только для recordScore
- Как создать отдельный кошелёк (cast wallet new)
- Как установить operator в контракте (setOperator)
- Operator private key: env variable на Railway, не в коде

## 2. .ENV БЕЗОПАСНОСТЬ:
- .gitignore включает .env
- Railway env variables для продакшена
- Никаких ключей в коде, логах, ошибках

## 3. МОНИТОРИНГ:
- Как проверить баланс operator wallet (cast balance)
- При каком балансе пополнять (< 0.001 ETH на Sepolia)
- Как проверить owner через cast call

## 4. ПРОЦЕДУРА ПРИ КОМПРОМЕТАЦИИ:

### Если утёк Operator key:
1. Owner вызывает pause() (cast send)
2. Owner вызывает setOperator(новый_адрес)
3. Сгенерировать новый ключ, обновить env на сервере
4. Owner вызывает unpause()

### Если утёк Owner key:
На тестнете — не критично (нет реальных денег). На мейннете — отдельная тема по защите owner key.

Для каждого шага — конкретные команды (cast).

Задеплой фронтенд на Vercel и свяжи с уже работающим бэкендом на Railway.

Бэкенд УЖЕ задеплоен на Railway (Фаза 2). URL в docs/deploy.md.

## 0. ПРОВЕРКА АВТОРИЗАЦИИ (делай ПЕРВЫМ):
```bash
gh auth status # GitHub
npx vercel whoami # Vercel
```

Если не авторизован — СТОП. Скажи какой CLI, команду для логина, жди.
Railway уже авторизован (деплоили в Фазе 2).

## 1. ПОДГОТОВКА КОНФИГОВ:

- vercel.json — security headers (X-Frame-Options: DENY, X-Content-Type-Options: nosniff, CSP frame-ancestors none) + rewrites для SPA
- .gitignore — проверь: .env, node_modules/, dist/, contracts/out/, contracts/cache/, contracts/broadcast/
- npm run build проходит без ошибок

## 2. GITHUB:

Если нет репо: `gh repo create НАЗВАНИЕ --public --source=. --push`
Если есть: `git add -A && git commit -m "prepare deploy" && git push`

## 3. ДЕПЛОЙ ФРОНТЕНДА (Vercel CLI):
```bash
npx vercel --prod
```

Фреймворк: Vite, Build: npm run build, Output: dist

После деплоя — добавь env переменные:
```bash
vercel env add VITE_RPC_URL production # https://sepolia.base.org
vercel env add VITE_CONTRACT_ADDRESS production # из docs/deploy.md
vercel env add VITE_API_URL production # Railway URL из docs/deploy.md
```
Если есть другие VITE_ переменные — добавь их тоже.
Затем передеплой: `npx vercel --prod`

## 4. СВЯЗАТЬ С RAILWAY:

Обнови CORS_ORIGIN в Railway на Vercel URL:
```bash
cd server/
railway variables set CORS_ORIGIN=https://VERCEL_URL
railway up
```

## 5. ПРОВЕРИТЬ:
```bash
# Бэкенд жив?
curl https://RAILWAY_URL/api/leaderboard

# Фронтенд жив?
curl -I https://VERCEL_URL
# Проверь X-Frame-Options: DENY в ответе

# Связка работает? (фронтенд дёргает бэкенд)
# Открой VERCEL_URL в браузере → Connect Wallet → проверь что лидерборд грузится
```

Покажи финальные URL. Обнови docs/deploy.md.

## Промпт 5.1 — Финальный тест + чеклист перед запуском

Последний промпт. Полный flow от начала до конца + чеклист перед запуском.

**Что понадобится:**

- **cast** — CLI инструмент из Foundry. `cast call` — прочитать (бесплатно). `cast send` — записать (нужен газ).
- Два кошелька с тестовым ETH (faucet Base Sepolia).
- Фронтенд и бэкенд задеплоены по URL.

Напиши скрипт/чеклист для тестирования полного flow на Base Sepolia.

Мой контракт: прочитай из docs/deploy.md (если нет — из contracts/broadcast/*/run-latest.json) Мой бэкенд: прочитай URL из railway status или спроси у пользователя Мой фронтенд: прочитай URL из vercel ls или спроси у пользователя

Шаги с командами (cast CLI + фронтенд):

1. PRE-CHECK:
• [ ] Контракт на Basescan Sepolia → код верифицирован?
• [ ] Owner правильный? (cast call [CONTRACT] "owner()")
• [ ] Operator установлен? (cast call [CONTRACT] "operator()" → отдельный адрес, НЕ owner)
• [ ] Entry fee правильный? (cast call [CONTRACT] "ENTRY_FEE()")
• [ ] Контракт не на паузе? (cast call [CONTRACT] "paused()")
2. ACTIVATE (с фронтенда):
• [ ] Подключить кошелёк → адрес отображается
• [ ] Нажать Activate → транзакция в кошельке
• [ ] Подтвердить → pending → success
• [ ] Проверить: isActivated = true (cast call)
• [ ] Проверить: totalPlayers увеличился
3. ACTIVATE (второй адрес):
• [ ] Повторить с другим кошельком
• [ ] totalPlayers = 2
4. GAMEPLAY:
• [ ] Играть 2 минуты (activated)
• [ ] Скоры отправляются на бэкенд? (проверить в БД)
• [ ] Heartbeat работает? (проверить в БД)
• [ ] Лидерборд обновляется?

4.5. ANTI-CHEAT КАЛИБРОВКА: Пока играл — собери реальные данные:

• [ ] Какой макс скор ты набрал за 5-10 сессий?
• [ ] Какой средний?
• [ ] Длина типичной сессии?
• [ ] Не блокирует ли anti-cheat легитимную игру? (false positive)

1. RECORD SCORE (operator):
• [ ] Бэкенд вызывает recordScore → txHash
• [ ] Проверить: playerScore ончейн обновился (cast call)
• [ ] Проверить: seasonScores записались
2. OWNER OPERATIONS (через cast от owner wallet):
• [ ] Вызвать pause() → контракт на паузе?
• [ ] Activate при паузе → revert?
• [ ] Вызвать unpause() → контракт работает?
• [ ] Вызвать newSeason() → currentSeason увеличился?
• [ ] Старые seasonScores заморожены?
• [ ] Новые скоры пишутся в новый сезон?
3. EDGE CASES:
• [ ] recordScore не от operator → revert?
• [ ] Повторная активация → revert?
• [ ] Скор от неактивированного → поведение корректно?
• [ ] curl POST /api/score без подписи/токена → 401?
• [ ] curl POST /api/score с чужим wallet_address → reject?
4. WITHDRAW (через cast от owner):
• [ ] Вызвать withdraw → ETH на owner wallet?
• [ ] Проверить баланс контракта уменьшился

Для каждого шага: команда + ожидаемый результат.

После прохождения flow — проверь полный чеклист:

КОНТРАКТ:

• [ ] Все forge test проходят
• [ ] Coverage: forge coverage (цель: >90% для критических функций)
• [ ] Код верифицирован на Basescan Sepolia (BaseScan API key настроен)
• [ ] Entry fee адекватный (не 0, не 100 ETH)
• [ ] Operator установлен (отдельный от owner)
• [ ] Owner и operator — разные кошельки
• [ ] Paused = false

БЭКЕНД:

• [ ] Работает по URL (не localhost)
• [ ] POST /api/score принимает и сохраняет
• [ ] POST /api/heartbeat работает
• [ ] GET /api/leaderboard возвращает данные
• [ ] Аутентификация: POST endpoints требуют подпись кошелька / session token
• [ ] Без подписи POST /api/score возвращает 401 (проверить через curl)
• [ ] CORS настроен на домен фронтенда (не wildcard *)
• [ ] Rate limiting активен
• [ ] Operator wallet имеет тестовый ETH для газа
• [ ] Env variables: CONTRACT_ADDRESS, OPERATOR_KEY, RPC_URL

ФРОНТЕНД:

• [ ] Работает по URL
• [ ] Connect Wallet → показывает адрес
• [ ] Неправильная сеть → предлагает switch на Base Sepolia
• [ ] Activate → транзакция → success → статус обновляется
• [ ] FREE mode работает (без кошелька)
• [ ] ACTIVATED mode: скоры на бэкенд, лидерборд, heartbeat
• [ ] Лидерборд показывает данные
• [ ] Обработка ошибок (нет ETH, отмена, timeout)
• [ ] Security headers (vercel.json / _headers): X-Frame-Options, X-Content-Type-Options, CSP
• [ ] RPC URL и CONTRACT_ADDRESS через env переменные (не хардкод)

КОНТРАКТ (допроверка):

• [ ] MAX_SCORE константа в контракте, recordScore проверяет score <= MAX_SCORE
• [ ] renounceOwnership() заблокирована (override → revert)
• [ ] CEI pattern соблюдён во всех функциях с ETH (проверить вручную)
• [ ] После редеплоя: адрес контракта обновлён ВЕЗДЕ (фронтенд env, бэкенд env, abi.js)

БЕЗОПАСНОСТЬ:

• [ ] .env НЕ в git
• [ ] Ключи разделены (owner ≠ operator)
• [ ] Аудит промптом 4.1 пройден, критические фиксы сделаны
• [ ] Аудит промптом 4.2 пройден (включая проверку аутентификации API)

ИНФРАСТРУКТУРА:

• [ ] SSL сертификат работает (https://, зелёный замок)
• [ ] 2FA на аккаунте регистратора домена
• [ ] npm audit: 0 critical / high уязвимостей
• [ ] package-lock.json в git
• [ ] RPC endpoint работает (приватный для прода, публичный ок для тестнета) ТЕСТ:
• [ ] Тестировал с 2+ кошельками
• [ ] Лидерборд корректный

ISSUES.md:

• [ ] Все 🔴 = FIXED
• [ ] Все 🟡 = есть план (первая неделя после запуска)
• [ ] Нет незаписанных проблем (всё что нашёл при аудите — в логе)

Для каждого пункта: как проверить + что делать если не готово.

## ЗАДАЧА: Собрать полный контекст проекта для запуска на Base

Ты начинаешь процесс подготовки Web3 приложения к запуску на Base L2 как Mini App.
Первый шаг — собрать всю информацию о проекте в один файл.

### ЧТО СДЕЛАТЬ

Проанализируй весь проект и создай файл `PROJECT_BRIEF.md` в корне проекта.
Файл должен содержать ТОЧНУЮ информацию, полученную из кода — не догадки.

### СТРУКТУРА PROJECT_BRIEF.md

```markdown
# Project Brief

## 1. ИДЕНТИФИКАЦИЯ
- Название проекта: [из package.json name, title в index.html, или README]
- Описание (1 предложение): [из package.json description или README]
- Тип: [game / defi / social / utility / nft / marketplace]
- Текущий URL (если задеплоен): [из env, config, или README]

## 2. СТЕК
- Frontend framework: [React/Next.js/Vue/Svelte + версия из package.json]
- Build tool: [Vite/Webpack/Next.js/Turbopack — из config файлов]
- CSS: [Tailwind/CSS Modules/Styled Components/etc]
- Web3 библиотека: [wagmi/ethers/viem/web3.js + версия]
- Wallet UI: [RainbowKit/ConnectKit/Web3Modal/AppKit + версия]
- Contract framework: [Foundry/Hardhat/Truffle — по наличию foundry.toml, hardhat.config, etc]
- Backend: [есть/нет, если есть — фреймворк: Express/Hono/Fastify/Next API]
- Database: [есть/нет, тип]

## 3. КОНТРАКТЫ
Для каждого .sol файла:
- Имя: [ContractName.sol]
- Путь: [contracts/src/...]
- Solidity версия: [из pragma]
- Назначение: [что делает]
- Ключевые функции: [payable функции, withdraw, claim, etc]
- Constructor args: [типы и описание]
- Внешние зависимости: [Chainlink, Uniswap, OpenZeppelin, etc]

## 4. ТЕКУЩАЯ СЕТЬ
- Chain: [Base Sepolia / Base Mainnet / Ethereum Sepolia / localhost]
- Chain ID: [84532 / 8453 / 11155111 / 31337]
- Адреса контрактов (текущие): [список]
- Как переключается сеть: [env var / hardcoded / config]
- RPC URL: [откуда берётся]

## 5. ТРАНЗАКЦИИ
Список ВСЕХ мест где пользователь отправляет on-chain транзакцию:
- [файл:строка] — [functionName] — [описание что делает]
- [файл:строка] — [functionName] — [описание]
Как отправляются: [useWriteContract / useContractWrite / sendTransaction / ethers.Contract]

## 6. АДРЕСА В UI
Список мест где показываются 0x-адреса пользователю:
- [файл:строка] — [контекст: leaderboard / profile / history]
Формат отображения: [полный 0x... / сокращённый ...abcd / ENS]

## 7. ТЕМЫ И LAYOUT
- Dark mode: [есть/нет, как реализован]
- Light mode: [есть/нет]
- Переключатель темы: [есть/нет]
- Mobile responsive: [есть/нет]
- Bottom navigation: [есть/нет]
- Safe area padding: [есть/нет]
- Touch targets >= 44px: [да/нет/не проверено]

## 8. ДЕПЛОЙ
- Хостинг: [Vercel/Railway/Netlify/AWS/свой]
- Build command: [npm run build / vite build / next build]
- Output directory: [dist / .next / build / out]
- Монолит или split: [frontend+backend вместе / отдельно]
- Dockerfile: [есть/нет]
- CI/CD: [есть/нет, что используется]

## 9. FARCASTER / BASE APP
- farcaster.json: [есть/нет, путь]
- @farcaster/miniapp-sdk: [установлен/нет, версия]
- sdk.actions.ready(): [вызывается/нет, где]
- base:app_id meta tag: [есть/нет]
- fc:miniapp meta tag: [есть/нет]
- Builder Code: [интегрирован/нет]
- Account Association: [подписан/нет]

## 10. ENV ПЕРЕМЕННЫЕ
Список всех VITE_*/NEXT_PUBLIC_*/REACT_APP_* переменных:
- [VAR_NAME] = [описание, текущее значение если не секретное]

## 11. ПРОБЛЕМЫ (найденные при анализе)
- [проблема 1]
- [проблема 2]
```

### КАК СОБИРАТЬ ИНФОРМАЦИЮ

1. **package.json** — название, зависимости, scripts, версии wagmi/viem/rainbowkit
2. **Все .sol файлы** — grep `pragma solidity`, найди контракты
3. **Config файлы** — foundry.toml, hardhat.config, vite.config, next.config, tailwind.config
4. **Grep по 0x** — найди все адреса контрактов в коде (исключи node_modules)
5. **Grep по chainId / chain** — определи текущую сеть
6. **Grep по writeContract / sendTransaction / useSendTransaction** — найди все транзакции
7. **Grep по address / 0x / wallet** в JSX/TSX компонентах — найди отображение адресов
8. **index.html** — найди meta tags, title
9. **public/ или static/** — найди .well-known/farcaster.json
10. **Grep по dark / theme / mode** — найди тему
11. **.env* файлы** (кроме .env.local с секретами) — найди переменные
12. **Dockerfile, railway.json, vercel.json, netlify.toml** — найди деплой конфиг

### ВАЖНО
- Пиши ТОЛЬКО то что нашёл в коде. Не угадывай.
- Если что-то не нашёл — пиши "НЕ НАЙДЕНО"
- В секции ПРОБЛЕМЫ — отметь всё что выглядит как потенциальный баг или блокер для mainnet
- Проверь `npm run build` — билдится ли проект вообще

Создай PROJECT_BRIEF.md и выведи краткое саммари: что готово, что нужно доделать.

ЗАДАЧА: Аудит и подготовка к деплою на Base Mainnet

Прочитай PROJECT_BRIEF.md — там полный контекст проекта.

### ШАГ 1: КОНТРАКТЫ — SECURITY AUDIT

Прочитай КАЖДЫЙ .sol файл и проверь по списку:

#### Access Control (КРИТИЧНО)
- [ ] Все функции вывода средств (withdraw*, claim*, transfer*) имеют modifier (onlyOwner/onlyOperator/onlyRole)
- [ ] Если НЕ имеют → ЭТО КРИТИЧЕСКИЙ БАГ. Любой может вывести все деньги. ИСПРАВЬ НЕМЕДЛЕННО.
- [ ] Ownership transfer protected (двухшаговый через Ownable2Step, или хотя бы onlyOwner)
- [ ] Operator/admin функции защищены

> РЕАЛЬНЫЙ СЛУЧАЙ: Мы задеплоили контракт где withdrawFounders() не имел onlyOperator.
> Пришлось редеплоить. Контракт НЕЛЬЗЯ изменить после деплоя. Проверяй ДО.

#### Reentrancy
- [ ] Все функции с external calls используют checks-effects-interactions паттерн
- [ ] Или используют ReentrancyGuard (nonReentrant modifier)
- [ ] Особенно: функции с .call{value:}(), .transfer(), .send()

#### Integer Safety
- [ ] Solidity >= 0.8.0 (встроенная overflow защита)
- [ ] Если < 0.8 — используются SafeMath

#### External Calls
- [ ] Все .call{value:}() проверяют return value: `(bool success, ) = addr.call{value: amount}(""); require(success);`
- [ ] Нет unchecked send()/transfer() (они тихо fail'ят при 2300 gas limit)

#### Price Feed / Oracle
- [ ] Если используется Chainlink — адрес Price Feed правильный для TARGET СЕТИ
- Base Mainnet ETH/USD: `0x71041dddad3595F9CEd3DcCFBe3D1F4b0a16Bb70`
- Base Sepolia ETH/USD: `0x4aDC67696bA383F43DD60A9e78F2C97Fbbfc7cb1`
- [ ] Есть проверка на stale price (updatedAt не старше X часов)
- [ ] Есть проверка answer > 0

### ШАГ 2: ABI СИНХРОНИЗАЦИЯ

> РЕАЛЬНЫЙ СЛУЧАЙ: Бэкенд ожидал drawJackpot(uint256), контракт имел drawJackpot().
> Settlement бы крашнулся в production. Всегда генерируй ABI из сорса.

Если есть бэкенд:
1. Найди все ABI определения в бэкенд коде (grep по `abi`, `ABI`, `interface`)
2. Сравни с реальным контрактом:
```bash
cd contracts && forge inspect ContractName abi
```
3. Если есть расхождения — обнови ABI в бэкенде чтобы точно соответствовали контракту
4. Проверь: имена функций, типы аргументов, return types

### ШАГ 3: ТЕСТЫ

```bash
# Foundry
cd contracts && forge test -vvv

# Hardhat
npx hardhat test
```

- Все тесты ДОЛЖНЫ проходить
- Если тестов нет — напиши минимум:
- Тест на deploy (контракт создаётся)
- Тест на основную функцию (entry/play/mint)
- Тест на withdraw (только owner может)
- Тест на edge cases (нулевые значения, повторные вызовы)

### ШАГ 4: ХАРДКОД АДРЕСОВ

Найди ВСЕ захардкоженные адреса контрактов в коде:
```bash
grep -rn "0x[a-fA-F0-9]\{40\}" --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" --include="*.sol" --exclude-dir=node_modules
```

Для каждого найденного адреса:
- Определи: это testnet или mainnet?
- Если testnet — нужно будет заменить после деплоя в mainnet
- Создай систему переключения если нет:

```javascript
// Правильный паттерн
const isMainnet = import.meta.env.VITE_NETWORK === 'mainnet'
// или для Next.js:
const isMainnet = process.env.NEXT_PUBLIC_NETWORK === 'mainnet'

const CONTRACTS = isMainnet ? {
game: '0x...mainnet...',
token: '0x...mainnet...',
} : {
game: '0x...testnet...',
token: '0x...testnet...',
}
```

> РЕАЛЬНЫЙ СЛУЧАЙ: У нас были хардкод testnet адреса в 4 файлах.
> Один пропустили → фронтенд пытался читать testnet контракт на mainnet → белый экран.

### ШАГ 5: DEPLOY SCRIPT

Проверь или создай deploy script для Base Mainnet:

**Для Foundry** — создай `script/DeployMainnet.s.sol`:
```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {Script, console} from "forge-std/Script.sol";
import {MyContract} from "../src/MyContract.sol";

contract DeployMainnet is Script {
function run() external {
uint256 deployerKey = vm.envUint("DEPLOYER_PRIVATE_KEY");
address operator = vm.envAddress("OPERATOR_ADDRESS");
address treasury = vm.envAddress("TREASURY_ADDRESS");

vm.startBroadcast(deployerKey);
// Deploy contracts here
vm.stopBroadcast();
}
}
```

**Для Hardhat** — проверь что в hardhat.config есть network `base`:
```javascript
networks: {
base: {
url: process.env.BASE_MAINNET_RPC_URL || 'https://mainnet.base.org',
chainId: 8453,
accounts: [process.env.DEPLOYER_PRIVATE_KEY],
}
}
```

### ШАГ 6: ENV ПОДГОТОВКА

Создай `.env.deploy.example` (БЕЗ реальных ключей):
```
DEPLOYER_PRIVATE_KEY=0x_YOUR_PRIVATE_KEY
OPERATOR_ADDRESS=0x_YOUR_OPERATOR
TREASURY_ADDRESS=0x_YOUR_TREASURY_OR_SAFE_MULTISIG
BASE_MAINNET_RPC_URL=https://mainnet.base.org
BASESCAN_API_KEY=YOUR_BASESCAN_API_KEY
```

Проверь что `.env.deploy` в `.gitignore`. Если нет — ДОБАВЬ.

### ШАГ 7: FRONTEND BUILD

```bash
npm run build
```

Билд ДОЛЖЕН проходить без ошибок. Если есть ошибки — исправь.
Типичные проблемы:
- TypeScript ошибки (unused vars, type mismatches)
- Import несуществующих модулей
- Missing env vars при билде (VITE_* переменные)

### ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

**ОБЯЗАТЕЛЬНО:** Допиши результаты аудита в конец файла PROJECT_BRIEF.md:

```markdown
## 12. АУДИТ (Prompt 1)
Дата: [сегодня]

| Проверка | Статус | Действие |
|----------|--------|----------|
| Access control | ✅/❌ | [что исправлено] |
| Reentrancy | ✅/❌ | ... |
| ABI sync | ✅/❌ | ... |
| Tests | ✅/❌ | X/Y passed |
| Hardcoded addresses | ✅/❌ | ... |
| Network switching | ✅/❌ | ... |
| Deploy script | ✅/❌ | ... |
| Frontend build | ✅/❌ | ... |

### Файлы изменённые при аудите:
- [список файлов и что изменено]

### Deploy script:
- Путь: [путь к deploy script]
- Команда: [forge script ...]

### Env template:
- Путь: [.env.deploy.example]
```

Если есть ❌ — ИСПРАВЬ ВСЁ до перехода к следующему этапу.
Если всё ✅ — напиши "Аудит пройден, PROJECT_BRIEF.md обновлён. Готов к Prompt 2."

## ЗАДАЧА: Деплой контрактов на Base Mainnet и верификация на BaseScan

Прочитай PROJECT_BRIEF.md — там контракты, адреса, стек.

### ПОДГОТОВКА

1. Прочитай deploy script проекта

2. Убедись что всё из Prompt 1 (аудит) исправлено

3. Проверь что `.env.deploy` существует и содержит нужные переменные

### ДЕПЛОЙ — FOUNDRY

```bash

# Загрузи env

source .env.deploy

# ВАЖНО: вычисли OPERATOR_ADDRESS из private key если он не задан

# cast wallet address $DEPLOYER_PRIVATE_KEY

# Деплой + верификация ОДНОЙ КОМАНДОЙ

forge script script/DeployMainnet.s.sol:DeployMainnet \

--rpc-url https://mainnet.base.org \

--broadcast \

--verify \

--etherscan-api-key $BASESCAN_API_KEY \

-vvvv

```

#### Флаги (объяснение):

- `--broadcast` — реально отправляет транзакцию (без него = dry run)

- `--verify` — автоматически верифицирует на BaseScan после деплоя

- `--etherscan-api-key` — нужен для верификации

- `-vvvv` — максимальный verbose (видны все детали)

#### Если --verify не сработал (бывает при таймауте):

```bash

forge verify-contract \

<DEPLOYED_ADDRESS> \

src/MyContract.sol:MyContract \

--chain base \

--etherscan-api-key $BASESCAN_API_KEY \

--constructor-args $(cast abi-encode "constructor(address,address,address)" $ARG1 $ARG2 $ARG3) \

--watch

```

> ТИПИЧНАЯ ОШИБКА: forge verify-contract fails с "Unable to verify"

> Причина: constructor args не совпадают. Используй ТОЧНО те же args что при деплое.

> Проверь: `cast abi-encode` должен дать тот же output что в broadcast JSON.

### ДЕПЛОЙ — HARDHAT

```bash

source .env.deploy

npx hardhat run scripts/deploy.js --network base

# Верификация (отдельно)

npx hardhat verify --network base <ADDRESS> <CONSTRUCTOR_ARG1> <CONSTRUCTOR_ARG2>

```

### ПОСЛЕ ДЕПЛОЯ

#### 1. Запиши адреса

Из output команды скопируй ВСЕ задеплоенные адреса.

#### 2. Обнови все файлы с адресами

Найди ВСЕ файлы где есть старые (testnet) адреса контрактов и замени на mainnet:

```bash

grep -rn "OLD_TESTNET_ADDRESS" --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" --include="*.json"

```

Замени на новые mainnet адреса. Типичные файлы:

- Frontend: wagmi config, hooks, constants

- Backend: config/constants, services/blockchain

- Config: .env файлы

#### 3. Переключи сеть

Установи env var для mainnet:

- Vite: `VITE_NETWORK=mainnet`

- Next.js: `NEXT_PUBLIC_NETWORK=mainnet`

- Backend: `USE_MAINNET=true` или `NETWORK=mainnet`

Убедись что chain config указывает на Base Mainnet (8453), не Base Sepolia (84532).

> ТИПИЧНАЯ ОШИБКА: Забыть обновить chain в wagmi config.

> Симптом: кошелёк подключается но транзакции fail — "wrong network".

> Проверь: в wagmi config должен быть `import { base } from 'wagmi/chains'` (не baseSepolia).

#### 4. Проверь верификацию

Открой каждый контракт на BaseScan:

```

https://basescan.org/address/<ADDRESS>#code

```

Должна быть зелёная галочка "Contract Source Code Verified".

#### 5. Тестовая транзакция

Отправь минимальную транзакцию в контракт чтобы убедиться что всё работает:

```bash

# Пример: вызов read функции

cast call <CONTRACT_ADDRESS> "owner()" --rpc-url https://mainnet.base.org

```

### ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

**ОБЯЗАТЕЛЬНО:** Допиши в PROJECT_BRIEF.md:

```markdown

## 13. ДЕПЛОЙ (Prompt 2)

Дата: [сегодня]

### Contracts Deployed (Base Mainnet)

| Contract | Address | Verified |

|----------|---------|----------|

| ... | 0x... | ✅/❌ |

### Files Updated

- [список файлов где обновлены адреса с testnet на mainnet]

### Network Config

- Chain: Base Mainnet (8453)

- RPC: https://mainnet.base.org

- Frontend env: VITE_NETWORK=mainnet

- Backend env: NETWORK=mainnet

### Deploy Command (для повторного деплоя)

[точная команда]

```

Напиши "Деплой завершён, PROJECT_BRIEF.md обновлён. Готов к Prompt 3."

```

---

## PROMPT 3 — SMART TRANSACTIONS + BUILDER CODE

> Обёртка для транзакций: Smart Wallet поддержка + ERC-8021 builder attribution.

> Адаптируется под стек проекта автоматически (wagmi v2+, ethers.js, viem).

```

## ЗАДАЧА: Создать обёртку для on-chain транзакций с Builder Code (ERC-8021)

Прочитай PROJECT_BRIEF.md — там список всех транзакций в приложении (секция 5) и стек (секция 2).

### КОНТЕКСТ

Нужно сделать две вещи:

1. **Smart Wallet Support** — если пользователь в Coinbase Smart Wallet, использовать sendCalls (paymaster = газ за юзера)

2. **Builder Code (ERC-8021)** — ко ВСЕМ транзакциям добавлять 20-byte суффикс с builder address

Builder address — адрес кошелька разработчика, зарегистрированный на base.dev.

ERC-8021 добавляет 20 байт в конец calldata. Контракт их игнорирует, Base indexer считывает для атрибуции.

### ШАГ 1: ОПРЕДЕЛИ BUILDER ADDRESS

Найди в проекте (PROJECT_BRIEF.md, .env, manifest) или спроси пользователя:

- Builder address (20 bytes, 0x...)

- Обычно совпадает с deployer/operator адресом

- Если нет — используй placeholder `0xYOUR_BUILDER_ADDRESS_HERE` и предупреди

### ШАГ 2: ОПРЕДЕЛИ СТЕК И ВЕРСИЮ

Из PROJECT_BRIEF.md секция 2 определи Web3 библиотеку. ОБЯЗАТЕЛЬНО проверь версию:

```bash

# Проверь точную версию в проекте

grep '"wagmi"' package.json

grep '"ethers"' package.json

grep '"viem"' package.json

```

**Маршруты:**

- **wagmi v2+ (2.x.x)** → useWriteContract, useCapabilities, useSendCalls — ПЕРЕЙДИ К ВАРИАНТУ A

- **wagmi v1 (1.x.x)** → useContractWrite (ДРУГОЙ API!) — ПЕРЕЙДИ К ВАРИАНТУ B

- **ethers.js v6** → contract.functionName() — ПЕРЕЙДИ К ВАРИАНТУ C

- **ethers.js v5** → contract.functionName() (другие типы) — ПЕРЕЙДИ К ВАРИАНТУ C

- **viem (без wagmi)** → walletClient.writeContract() — ПЕРЕЙДИ К ВАРИАНТУ D

> КРИТИЧНАЯ ОШИБКА: wagmi v1 и v2 имеют РАЗНЫЙ API. Не угадывай — проверяй.

> v1: useContractWrite({ address, abi, functionName }) → write()

> v2: useWriteContract() → writeContractAsync({ address, abi, functionName })

### ШАГ 3: СОЗДАЙ ОБЁРТКУ

---

#### ВАРИАНТ A: wagmi v2+ (React)

Создай файл `src/hooks/useSmartTransaction.js` (или .ts):

```javascript

import { useCallback } from 'react'

import { useAccount, useCapabilities, useSendCalls, useWriteContract } from 'wagmi'

import { getCallsStatus } from '@wagmi/core'

import { encodeFunctionData } from 'viem'

import { base } from 'wagmi/chains'

import { config } from '../config/wagmi' // ← АДАПТИРУЙ путь к вашему wagmi config

// ERC-8021: Builder address suffix (20 bytes, registered on base.dev)

const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

export function useSmartTransaction() {

const { address, isConnected } = useAccount()

// Smart Wallet detection (Coinbase Smart Wallet exposes paymasterService)

const { data: capabilities } = useCapabilities({

query: { enabled: Boolean(address), retry: false },

})

const hasPaymaster = Boolean(capabilities?.[base.id]?.paymasterService?.supported)

// sendCalls — Smart Wallet path

const { sendCallsAsync, isPending: isSendCallsPending } = useSendCalls()

// writeContract — regular wallet path (EOA, MetaMask, etc.)

const { writeContractAsync, isPending: isWritePending } = useWriteContract()

const isPending = isSendCallsPending || isWritePending

const execute = useCallback(async ({ address: contractAddress, abi, functionName, args, value }) => {

if (!isConnected) throw new Error('Wallet not connected')

if (hasPaymaster) {

// Smart Wallet: sendCalls + paymaster + builder suffix in calldata

const calldata = encodeFunctionData({ abi, functionName, args: args || [] })

const dataWithSuffix = calldata + BUILDER_ADDRESS.slice(2)

const id = await sendCallsAsync({

calls: [{ to: contractAddress, data: dataWithSuffix, value: value || 0n }],

capabilities: { paymasterService: {} },

})

// sendCalls returns an ID (NOT a tx hash) — poll for receipt

const receipt = await pollForConfirmation(id)

return { hash: receipt?.receipts?.[0]?.transactionHash || id }

} else {

// Regular wallet: writeContract + dataSuffix (wagmi v2 supports this natively)

const hash = await writeContractAsync({

address: contractAddress,

abi,

functionName,

args: args || [],

value,

dataSuffix: `0x${BUILDER_ADDRESS.slice(2)}`,

})

return { hash }

}

}, [isConnected, hasPaymaster, sendCallsAsync, writeContractAsync])

return { execute, isPending, hasPaymaster }

}

// Poll getCallsStatus until CONFIRMED or timeout (60s)

async function pollForConfirmation(id) {

const start = Date.now()

while (Date.now() - start < 60_000) {

try {

const status = await getCallsStatus(config, { id })

if (status.status === 'CONFIRMED') return status

} catch {}

await new Promise(r => setTimeout(r, 1500))

}

return null // Timeout — tx may have succeeded, check on chain

}

```

**ВАЖНО — что НЕ делать:**

- ❌ `require('wagmi')` — не работает в Vite/ESM. Только static imports.

- ❌ `useCallsStatus` хук для polling — создаёт dead code. Используй `getCallsStatus` из `@wagmi/core`.

- ❌ Динамический `import('@wagmi/core')` внутри цикла — импортируй статически вверху.

- ❌ Условные вызовы хуков (нарушает Rules of Hooks). Все хуки вызываются безусловно.

---

#### ВАРИАНТ B: wagmi v1 (React)

```javascript

import { useCallback } from 'react'

import { useAccount, useContractWrite, usePrepareContractWrite } from 'wagmi'

import { encodeFunctionData } from 'viem'

const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

// wagmi v1: нет sendCalls, нет dataSuffix — builder suffix через encodeFunctionData

export function useSmartTransaction() {

const { address, isConnected } = useAccount()

// В v1 нет paymaster support — только builder suffix

const execute = useCallback(async ({ address: contractAddress, abi, functionName, args, value }) => {

if (!isConnected) throw new Error('Wallet not connected')

const calldata = encodeFunctionData({ abi, functionName, args: args || [] })

const dataWithSuffix = calldata + BUILDER_ADDRESS.slice(2)

// v1: используй sendTransaction напрямую с raw data

const { sendTransactionAsync } = await import('wagmi/actions')

const hash = await sendTransactionAsync({

to: contractAddress,

data: dataWithSuffix,

value,

})

return { hash }

}, [isConnected])

return { execute, isPending: false, hasPaymaster: false }

}

```

> ПРИМЕЧАНИЕ: wagmi v1 не поддерживает sendCalls/useCapabilities.

> Рекомендуется обновить до v2 для полной Smart Wallet поддержки.

---

#### ВАРИАНТ C: ethers.js (v5/v6)

```javascript

// Утилита (не React хук — для этого фреймворка)

import { ethers } from 'ethers' // v5 или v6

const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

export async function executeWithBuilder(signer, { address, abi, functionName, args, value }) {

const iface = new ethers.Interface(abi) // v6: Interface, v5: utils.Interface

const calldata = iface.encodeFunctionData(functionName, args || [])

const dataWithSuffix = calldata + BUILDER_ADDRESS.slice(2).toLowerCase()

const tx = await signer.sendTransaction({

to: address,

data: dataWithSuffix,

value: value || 0n,

})

return { hash: tx.hash }

}

```

---

#### ВАРИАНТ D: viem (без wagmi)

```javascript

import { encodeFunctionData } from 'viem'

const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

export async function executeWithBuilder(walletClient, { address, abi, functionName, args, value }) {

const hash = await walletClient.writeContract({

address,

abi,

functionName,

args: args || [],

value,

dataSuffix: `0x${BUILDER_ADDRESS.slice(2)}`, // viem поддерживает dataSuffix

})

return { hash }

}

```

---

### ШАГ 4: ЗАМЕНИ ВСЕ ТРАНЗАКЦИИ

Из PROJECT_BRIEF.md секция 5 у тебя есть список ВСЕХ мест с write-транзакциями.

Замени КАЖДЫЙ вызов на `execute()` из новой обёртки.

**Было (wagmi v2):**

```javascript

const { writeContractAsync } = useWriteContract()

await writeContractAsync({

address: GAME_CONTRACT,

abi: gameAbi,

functionName: 'enterGame',

value: parseEther('0.001'),

})

```

**Стало:**

```javascript

const { execute } = useSmartTransaction()

await execute({

address: GAME_CONTRACT,

abi: gameAbi,

functionName: 'enterGame',

value: parseEther('0.001'),

})

```

**Проверь grep'ом что ничего не пропустил:**

```bash

# Для wagmi: не должно остаться прямых вызовов writeContract (кроме внутри хука)

grep -rn "writeContractAsync\|useContractWrite\|sendTransaction" --include="*.jsx" --include="*.tsx" --include="*.js" --include="*.ts" src/ --exclude="*useSmartTransaction*"

# Для ethers: не должно остаться прямых contract.functionName() без builder suffix

grep -rn "\.sendTransaction\|contract\." --include="*.jsx" --include="*.tsx" --include="*.js" src/

```

### ШАГ 5: ПРОВЕРКА

1. `npm run build` — билд проходит без ошибок

2. Запусти приложение, подключи кошелёк, отправь тестовую транзакцию

3. В блок-эксплорере: открой транзакцию → Input Data → последние 40 hex символов = builder address (без 0x)

4. Grep: убедись что writeContractAsync/useContractWrite не используется напрямую в UI хуках

### ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

**ОБЯЗАТЕЛЬНО:** Допиши в PROJECT_BRIEF.md:

```markdown

## 14. SMART TRANSACTIONS (Prompt 3)

Дата: [сегодня]

- Builder Address: 0x...

- Стек: [wagmi v2 / wagmi v1 / ethers / viem]

- Обёртка: [путь к файлу]

- Транзакций обновлено: X

- [файл:строка] — functionName

- Smart Wallet (sendCalls + paymaster): [да/нет — только wagmi v2+]

- ERC-8021 builder suffix: добавлен ко всем транзакциям

- Build: ✅

```

Напиши "Smart Transactions готовы, PROJECT_BRIEF.md обновлён. Готов к Prompt 3."

ЗАДАЧА: Создать обёртку для on-chain транзакций с Builder Code (ERC-8021)

Прочитай PROJECT_BRIEF.md — там список всех транзакций в приложении (секция 5) и стек (секция 2).

### КОНТЕКСТ

Нужно сделать две вещи:
1. **Smart Wallet Support** — если пользователь в Coinbase Smart Wallet, использовать sendCalls
(paymaster = газ за юзера)
2. **Builder Code (ERC-8021)** — ко ВСЕМ транзакциям добавлять 20-byte суффикс с builder address

Builder address — адрес кошелька разработчика, зарегистрированный на base.dev.
ERC-8021 добавляет 20 байт в конец calldata. Контракт их игнорирует, Base indexer считывает для
атрибуции.

### ШАГ 1: ОПРЕДЕЛИ BUILDER ADDRESS

Найди в проекте (PROJECT_BRIEF.md, .env, manifest) builder address.

Если НЕ найден — **СТОП. Спроси пользователя:**
1. "Какой адрес использовать как Builder Address для ERC-8021?"
2. "Этот адрес зарегистрирован на base.dev? Если нет — зарегистрируй сейчас: https://base.dev"

**НЕ ПРОДОЛЖАЙ** с placeholder `0xYOUR_BUILDER_ADDRESS_HERE` — это бессмысленный суффикс, Base его
не засчитает.
Builder address должен быть реальным и зарегистрированным, иначе весь Prompt 3 = мёртвый код.

- Builder address обычно совпадает с deployer/owner адресом
- Регистрация на base.dev бесплатна и занимает 2 минуты

### ШАГ 2: ОПРЕДЕЛИ СТЕК И ВЕРСИЮ

Из PROJECT_BRIEF.md секция 2 определи Web3 библиотеку. ОБЯЗАТЕЛЬНО проверь версию:

```bash
# Проверь точную версию в проекте
grep '"wagmi"' package.json
grep '"ethers"' package.json
grep '"viem"' package.json

Маршруты:
- wagmi v2+ (2.x.x) → useWriteContract, useCapabilities, useSendCalls — ПЕРЕЙДИ К ВАРИАНТУ A
- wagmi v1 (1.x.x) → useContractWrite (ДРУГОЙ API!) — ПЕРЕЙДИ К ВАРИАНТУ B
- ethers.js v6 → contract.functionName() — ПЕРЕЙДИ К ВАРИАНТУ C
- ethers.js v5 → contract.functionName() (другие типы) — ПЕРЕЙДИ К ВАРИАНТУ C
- viem (без wagmi) → walletClient.writeContract() — ПЕРЕЙДИ К ВАРИАНТУ D

КРИТИЧНАЯ ОШИБКА: wagmi v1 и v2 имеют РАЗНЫЙ API. Не угадывай — проверяй.
v1: useContractWrite({ address, abi, functionName }) → write()
v2: useWriteContract() → writeContractAsync({ address, abi, functionName })

ШАГ 3: СОЗДАЙ ОБЁРТКУ

---
ВАРИАНТ A: wagmi v2+ (React)

Создай файл src/hooks/useSmartTransaction.js (или .ts):

import { useCallback } from 'react'
import { useAccount, useCapabilities, useSendCalls, useWriteContract } from 'wagmi'
import { getCallsStatus } from '@wagmi/core'
import { encodeFunctionData } from 'viem'
import { base } from 'wagmi/chains'
import { config } from '../config/wagmi' // ← АДАПТИРУЙ путь к вашему wagmi config

// ERC-8021: Builder address suffix (20 bytes, registered on base.dev)
const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

export function useSmartTransaction() {
const { address, isConnected } = useAccount()

// Smart Wallet detection (Coinbase Smart Wallet exposes paymasterService)
const { data: capabilities } = useCapabilities({
query: { enabled: Boolean(address), retry: false },
})
const hasPaymaster = Boolean(capabilities?.[base.id]?.paymasterService?.supported)

// sendCalls — Smart Wallet path
const { sendCallsAsync, isPending: isSendCallsPending } = useSendCalls()

// writeContract — regular wallet path (EOA, MetaMask, etc.)
const { writeContractAsync, isPending: isWritePending } = useWriteContract()

const isPending = isSendCallsPending || isWritePending

const execute = useCallback(async ({ address: contractAddress, abi, functionName, args, value })
=> {
if (!isConnected) throw new Error('Wallet not connected')

if (hasPaymaster) {
// Smart Wallet: sendCalls + paymaster + builder suffix in calldata
const calldata = encodeFunctionData({ abi, functionName, args: args || [] })
const dataWithSuffix = calldata + BUILDER_ADDRESS.slice(2)

const id = await sendCallsAsync({
calls: [{ to: contractAddress, data: dataWithSuffix, value: value || 0n }],
capabilities: { paymasterService: {} },
})

// sendCalls returns an ID (NOT a tx hash) — poll for receipt
const receipt = await pollForConfirmation(id)
return { hash: receipt?.receipts?.[0]?.transactionHash || id }
} else {
// Regular wallet: writeContract + dataSuffix (wagmi v2 supports this natively)
const hash = await writeContractAsync({
address: contractAddress,
abi,
functionName,
args: args || [],
value,
dataSuffix: `0x${BUILDER_ADDRESS.slice(2)}`,
})
return { hash }
}
}, [isConnected, hasPaymaster, sendCallsAsync, writeContractAsync])

return { execute, isPending, hasPaymaster }
}

// Poll getCallsStatus until CONFIRMED or timeout (60s)
async function pollForConfirmation(id) {
const start = Date.now()
while (Date.now() - start < 60_000) {
try {
const status = await getCallsStatus(config, { id })
if (status.status === 'CONFIRMED') return status
} catch {}
await new Promise(r => setTimeout(r, 1500))
}
return null // Timeout — tx may have succeeded, check on chain
}

ВАЖНО — что НЕ делать:
- ❌ require('wagmi') — не работает в Vite/ESM. Только static imports.
- ❌ useCallsStatus хук для polling — создаёт dead code. Используй getCallsStatus из @wagmi/core.
- ❌ Динамический import('@wagmi/core') внутри цикла — импортируй статически вверху.
- ❌ Условные вызовы хуков (нарушает Rules of Hooks). Все хуки вызываются безусловно.

---
ВАРИАНТ B: wagmi v1 (React)

import { useCallback } from 'react'
import { useAccount, useContractWrite, usePrepareContractWrite } from 'wagmi'
import { encodeFunctionData } from 'viem'

const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

// wagmi v1: нет sendCalls, нет dataSuffix — builder suffix через encodeFunctionData
export function useSmartTransaction() {
const { address, isConnected } = useAccount()
// В v1 нет paymaster support — только builder suffix
const execute = useCallback(async ({ address: contractAddress, abi, functionName, args, value })
=> {
if (!isConnected) throw new Error('Wallet not connected')

const calldata = encodeFunctionData({ abi, functionName, args: args || [] })
const dataWithSuffix = calldata + BUILDER_ADDRESS.slice(2)

// v1: используй sendTransaction напрямую с raw data
const { sendTransactionAsync } = await import('wagmi/actions')
const hash = await sendTransactionAsync({
to: contractAddress,
data: dataWithSuffix,
value,
})
return { hash }
}, [isConnected])

return { execute, isPending: false, hasPaymaster: false }
}

ПРИМЕЧАНИЕ: wagmi v1 не поддерживает sendCalls/useCapabilities.
Рекомендуется обновить до v2 для полной Smart Wallet поддержки.

---
ВАРИАНТ C: ethers.js (v5/v6)

// Утилита (не React хук — для этого фреймворка)
import { ethers } from 'ethers' // v5 или v6

const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

export async function executeWithBuilder(signer, { address, abi, functionName, args, value }) {
const iface = new ethers.Interface(abi) // v6: Interface, v5: utils.Interface
const calldata = iface.encodeFunctionData(functionName, args || [])
const dataWithSuffix = calldata + BUILDER_ADDRESS.slice(2).toLowerCase()

const tx = await signer.sendTransaction({
to: address,
data: dataWithSuffix,
value: value || 0n,
})

return { hash: tx.hash }
}

---
ВАРИАНТ D: viem (без wagmi)

import { encodeFunctionData } from 'viem'

const BUILDER_ADDRESS = '0xYOUR_BUILDER_ADDRESS_HERE'

export async function executeWithBuilder(walletClient, { address, abi, functionName, args, value })
{
const hash = await walletClient.writeContract({
address,
abi,
functionName,
args: args || [],
value,
dataSuffix: `0x${BUILDER_ADDRESS.slice(2)}`, // viem поддерживает dataSuffix
})
return { hash }
}

---
ШАГ 4: ЗАМЕНИ ВСЕ ТРАНЗАКЦИИ

Из PROJECT_BRIEF.md секция 5 у тебя есть список ВСЕХ мест с write-транзакциями.
Замени КАЖДЫЙ вызов на execute() из новой обёртки.

Было (wagmi v2):
const { writeContractAsync } = useWriteContract()
await writeContractAsync({
address: GAME_CONTRACT,
abi: gameAbi,
functionName: 'enterGame',
value: parseEther('0.001'),
})

Стало:
const { execute } = useSmartTransaction()
await execute({
address: GAME_CONTRACT,
abi: gameAbi,
functionName: 'enterGame',
value: parseEther('0.001'),
})

Проверь grep'ом что ничего не пропустил:
# Для wagmi: не должно остаться прямых вызовов writeContract (кроме внутри хука)
grep -rn "writeContractAsync\|useContractWrite\|sendTransaction" --include="*.jsx" --include="*.tsx"
--include="*.js" --include="*.ts" src/ --exclude="*useSmartTransaction*"

# Для ethers: не должно остаться прямых contract.functionName() без builder suffix
grep -rn "\.sendTransaction\|contract\." --include="*.jsx" --include="*.tsx" --include="*.js" src/

ШАГ 5: ПРОВЕРКА

1. npm run build — билд проходит без ошибок
2. Grep: убедись что writeContractAsync/useContractWrite не используется напрямую в UI хуках (только
внутри useSmartTransaction)
3. Попроси пользователя проверить вручную (это нельзя сделать из CLI):
- "Открой приложение в браузере, подключи кошелёк, отправь тестовую транзакцию"
- "В BaseScan открой транзакцию → Input Data → последние 40 hex символов должны = builder address
(без 0x)"
- "Подтверди что builder suffix виден в транзакции"

НЕ ПИШИ "проверка пройдена" пока пользователь не подтвердит. Это единственный способ убедиться что
ERC-8021 реально работает.

ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

ОБЯЗАТЕЛЬНО: Допиши в PROJECT_BRIEF.md:

## 14. SMART TRANSACTIONS (Prompt 3)
Дата: [сегодня]

- Builder Address: 0x...
- Стек: [wagmi v2 / wagmi v1 / ethers / viem]
- Обёртка: [путь к файлу]
- Транзакций обновлено: X
- [файл:строка] — functionName
- Smart Wallet (sendCalls + paymaster): [да/нет — только wagmi v2+]
- ERC-8021 builder suffix: добавлен ко всем транзакциям
- Build: ✅

Напиши "Smart Transactions готовы, PROJECT_BRIEF.md обновлён. Готов к Prompt 4."

ЗАДАЧА: Привести UI в соответствие с требованиями Base Mini App

Прочитай PROJECT_BRIEF.md — секции 6, 7 (адреса в UI, темы и layout).

### КОНТЕКСТ

Base App имеет обязательные требования. Если не соответствуешь — не попадёшь в Featured.
Ниже — полный чеклист. Пройди по КАЖДОМУ пункту, проверь в коде, исправь если нужно.

---

### БЛОК A: DARK / LIGHT MODE [ОБЯЗАТЕЛЬНО]

Проверь: есть ли в проекте поддержка тёмной и светлой темы.

**Если НЕТ — создай:**

1. Создай ThemeProvider (или useTheme хук):

```jsx
// src/hooks/useTheme.jsx (или .tsx)
import { createContext, useContext, useState, useEffect } from 'react'

const ThemeContext = createContext()

export function ThemeProvider({ children }) {
const [theme, setTheme] = useState(() => {
if (typeof window === 'undefined') return 'dark'
const saved = localStorage.getItem('app-theme')
if (saved) return saved
return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light'
})

useEffect(() => {
const root = document.documentElement
root.classList.remove('light', 'dark')
root.classList.add(theme)
localStorage.setItem('app-theme', theme)
// Обнови meta theme-color для mobile browser chrome
const meta = document.querySelector('meta[name="theme-color"]')
if (meta) meta.content = theme === 'dark' ? '#0a0a1a' : '#F5F7FA'
}, [theme])

const toggle = () => setTheme(t => t === 'dark' ? 'light' : 'dark')

return (
<ThemeContext.Provider value={{ theme, setTheme, toggle }}>
{children}
</ThemeContext.Provider>
)
}

export const useTheme = () => useContext(ThemeContext)

2. Оберни приложение в ThemeProvider (в App.jsx или main.jsx)
3. Определи CSS переменные для обеих тем:

/* В глобальном CSS (index.css / globals.css) */
:root, .light {
--color-bg: #F5F7FA;
--color-surface: #FFFFFF;
--color-text: #1A1A2E;
--color-text-secondary: #6B7280;
--color-border: #E5E7EB;
--color-accent: #0052FF; /* Base blue */
}

.dark {
--color-bg: #0a0a1a;
--color-surface: #1a1a2e;
--color-text: #F0F0F0;
--color-text-secondary: #9CA3AF;
--color-border: #2a2a3e;
--color-accent: #0052FF;
}

4. Замени hardcoded цвета на CSS variables во ВСЕХ компонентах.
Если используешь Tailwind — настрой через tailwind.config:

// tailwind.config.js
module.exports = {
darkMode: 'class',
theme: {
extend: {
colors: {
bg: 'var(--color-bg)',
surface: 'var(--color-surface)',
// ...
}
}
}
}

5. Если используешь RainbowKit/ConnectKit — переключай их тему тоже:
import { darkTheme, lightTheme } from '@rainbow-me/rainbowkit'
const { theme } = useTheme()
<RainbowKitProvider theme={theme === 'dark' ? darkTheme() : lightTheme()}>

Если theme УЖЕ ЕСТЬ — проверь:
- Переключатель работает
- Сохраняется в localStorage
- Системная тема детектится (prefers-color-scheme)
- RainbowKit/wallet UI тоже переключается
- Нет мест с хардкод цветами (#ffffff, rgb(0,0,0)) в inline styles

---
БЛОК B: АДРЕСА [ОБЯЗАТЕЛЬНО]

Base App ЗАПРЕЩАЕТ показывать полные 0x адреса. Пользователь должен видеть имя, не хеш.

1. Найди ВСЕ места где показываются адреса (из PROJECT_BRIEF.md секция 6)
2. Замени полные адреса на сокращённые:

// Утилита для сокращения адресов
function shortenAddress(address, chars = 4) {
if (!address) return ''
return `${address.slice(0, chars + 2)}...${address.slice(-chars)}`
}
// Пример: 0xB3b8...595d

3. Ещё лучше — показывай Basename (ENS на Base):

import { useEnsName, useEnsAvatar } from 'wagmi'
import { base } from 'wagmi/chains'

function useBasename(address) {
const { data: name, isLoading } = useEnsName({
address,
chainId: base.id,
universalResolverAddress: '0xC6d566A56A1aFf6508b41f6c90ff131615583BCD',
query: { enabled: Boolean(address), staleTime: 5 * 60 * 1000 },
})
const { data: avatar } = useEnsAvatar({
name,
chainId: base.id,
query: { enabled: Boolean(name), staleTime: 5 * 60 * 1000 },
})
return { name: name || shortenAddress(address), avatar, isLoading }
}

4. Используй useBasename(address) везде где показываешь адрес: лидерборд, профиль, история.

---
БЛОК C: LAYOUT [ОБЯЗАТЕЛЬНО]

Bottom Navigation

Если в приложении есть навигация между экранами — создай bottom nav:
<nav className="fixed bottom-0 left-0 right-0 bg-[var(--color-surface)] border-t
border-[var(--color-border)]"
style={{ paddingBottom: 'env(safe-area-inset-bottom)' }}>
<div className="flex justify-around items-center h-14">
<NavItem icon="🎮" label="Game" to="/" />
<NavItem icon="🏆" label="Rewards" to="/rewards" />
<NavItem icon="👤" label="Profile" to="/profile" />
</div>
</nav>

Требования:
- Иконки + текстовые лейблы (НЕ только иконки)
- Safe area padding внизу (для iPhone notch): env(safe-area-inset-bottom)
- Touch targets >= 44px (высота каждого элемента nav)

Если одноэкранное приложение без навигации — bottom nav не нужен (пометь N/A).

Portrait Orientation

- Все экраны оптимизированы под вертикальный экран
- CTA кнопки видимые без скролла (в верхней/средней части)
- Контент не обрезается на узких экранах (320px width тест)

Touch Targets

Найди все кнопки, ссылки, интерактивные элементы. Каждый должен быть минимум 44x44px:
button, a, [role="button"] {
min-height: 44px;
min-width: 44px;
}

---
БЛОК D: КЛИЕНТ-АГНОСТИЧНОСТЬ [ОБЯЗАТЕЛЬНО]

Найди в коде:
grep -rni "farcaster\|warpcast\|cast\|fid" --include="*.jsx" --include="*.tsx" --include="*.js"

Замени:
- "Share to Warpcast" → "Share"
- "Post a cast" → "Share to feed"
- Hardcoded Warpcast URLs → generic share

Исключение: farcaster.json manifest и SDK imports — их НЕ трогай.

---
БЛОК E: META TAGS [ОБЯЗАТЕЛЬНО]

Проверь index.html :

<!-- Обязательные -->
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0,
user-scalable=no, viewport-fit=cover" />
<meta name="theme-color" content="#0a0a1a" />

<!-- Apple PWA -->
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />

<!-- OG tags -->
<meta property="og:title" content="App Name" />
<meta property="og:description" content="Description" />
<meta property="og:image" content="https://your-domain.com/og-1200x630.png" />

<!-- Предотвращение pulldown-to-refresh и scroll bounce -->
<style>
body { overscroll-behavior: none; }
</style>

РЕАЛЬНЫЙ СЛУЧАЙ: Без viewport-fit=cover контент залезает под iPhone notch.
Без overscroll-behavior: none — pull-to-refresh мешает геймплею.
Без maximum-scale=1.0 — pinch zoom ломает мобильный layout.

---
БЛОК F: ПРОИЗВОДИТЕЛЬНОСТЬ

- Загрузка < 3 секунд
- Проверь размер бандла: npm run build → посмотри output
- Если > 500KB JS — нужен code splitting / lazy loading
- Loading индикаторы при всех async операциях
- Нет мерцания при загрузке (skeleton/placeholder)

---
ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

ОБЯЗАТЕЛЬНО: Допиши в PROJECT_BRIEF.md:

## 15. BASE APP COMPLIANCE (Prompt 4)
Дата: [сегодня]

| Требование | Статус | Действие |
|------------|--------|----------|
| Dark mode | ✅/❌ | [что сделано] |
| Light mode | ✅/❌ | ... |
| Theme toggle | ✅/❌ | ... |
| System preference | ✅/❌ | ... |
| No 0x addresses | ✅/❌ | ... |
| Basename support | ✅/❌ | ... |
| Bottom nav | ✅/❌ | ... |
| Nav labels | ✅/❌ | ... |
| Safe area | ✅/❌ | ... |
| Touch 44px | ✅/❌ | ... |
| Portrait layout | ✅/❌ | ... |
| Client-agnostic | ✅/❌ | ... |
| Meta tags | ✅/❌ | ... |
| viewport-fit | ✅/❌ | ... |
| overscroll | ✅/❌ | ... |
| Performance <3s | ✅/❌ | ... |
| Loading states | ✅/❌ | ... |

### Файлы созданные/изменённые:
- [список файлов]

Build: ✅/❌

Напиши "Base App Compliance готов, PROJECT_BRIEF.md обновлён. Готов к Prompt 5."

ЗАДАЧА: Настроить Farcaster Mini App manifest, SDK и сгенерировать ассеты

Прочитай PROJECT_BRIEF.md — секция 9 (Farcaster / Base App).

### КОНТЕКСТ

Manifest файл `/.well-known/farcaster.json` — это "паспорт" приложения.
Без него Base App и Warpcast не знают что это Mini App.

---

### ШАГ 1: ГЕНЕРАЦИЯ КАРТИНОК

Все картинки для манифеста генерируются автоматически скриптом.
Создай файл `scripts/generate-assets.sh` если его ещё нет:

```bash
# Проверь наличие
ls scripts/generate-assets.sh 2>/dev/null && echo "EXISTS" || echo "NEED TO CREATE"

Если скрипта нет — создай его. Скрипт должен:

1. Генерировать 4 картинки из HTML-шаблонов через Python + Playwright (system Chrome):
- icon-1024.png (1024×1024) — название на тёмном фоне, grid pattern, accent glow
- splash-200.png (200×200) — уменьшенная иконка
- hero-1200x630.png (1200×630) — баннер с визуализацией геймплея (SVG чарт/графика)
- og-1200x630.png (1200×630) — социальное превью
2. Если есть GEMINI_API_KEY в ~/.claude/.env — использовать Gemini 2.5 Flash Image
для hero и OG (AI-генерация, красивее):
- API:
https://generativelanguage.googleapis.com/v1beta/models/gemini-2.5-flash-image:generateContent
- Auth: header x-goog-api-key
- Config: "responseModalities": ["IMAGE", "TEXT"]
- Gemini генерит 1024×1024 — нужен resize через PIL до 1200×630
- Если Gemini не ответил — fallback на HTML
3. Без GEMINI_API_KEY — ВСЁ генерируется процедурно (HTML шаблоны, 0 API)
4. Параметры:
- --name "App Name" (автодетект из package.json)
- --tagline "Tagline"
- --accent "#00ff88" (accent color)
- --bg "#0a0a1a" (background)
- --no-ai — принудительно процедурный режим
- --skip-existing — не перезаписывать

Запусти генерацию:

chmod +x scripts/generate-assets.sh
./scripts/generate-assets.sh --name "APP_NAME" --tagline "TAGLINE"

Подставь реальные name и tagline из PROJECT_BRIEF.md.

Проверь результат:

for f in public/icon-1024.png public/splash-200.png public/hero-1200x630.png public/og-1200x630.png;
do
if [ -f "$f" ]; then
python3 -c "from PIL import Image; i=Image.open('$f'); print(f'✅ {\"$f\"}:
{i.size[0]}x{i.size[1]}')" 2>/dev/null \
|| echo "✅ $f exists ($(wc -c < "$f" | tr -d ' ') bytes)"
else
echo "❌ $f MISSING"
fi
done

---
ШАГ 2: УСТАНОВИ SDK

npm install @farcaster/miniapp-sdk

ПРОВЕРЬ ВЕРСИЮ после установки:
ls node_modules/@farcaster/miniapp-sdk/dist/
Убедись что sdk экспортируется.

ШАГ 3: SDK INITIALIZATION

Добавь в КОРНЕВОЙ компонент приложения (App.jsx / App.tsx / layout.tsx):

import { useEffect } from 'react'

useEffect(() => {
// Динамический импорт — SDK может не быть в обычном браузере
import('@farcaster/miniapp-sdk').then(({ sdk }) => {
sdk.actions.ready()
}).catch(() => {
// Не Mini App контексте (обычный браузер) — ok, игнорируем
})
}, [])

РЕАЛЬНЫЙ СЛУЧАЙ: Без sdk.actions.ready() Base App показывает бесконечный
загрузочный экран. Пользователь видит splash image и ничего не происходит.
Это самая частая ошибка новых Mini App. Вызывай ready() СРАЗУ при монтировании.

ВАЖНО: sdk.actions.ready() нужно вызывать даже если приложение ещё грузит данные.
Оно говорит "фрейм загрузился", не "данные готовы". Вызывай в useEffect([], []).

ШАГ 4: СОЗДАЙ MANIFEST

Создай файл public/.well-known/farcaster.json:

КРИТИЧНО: Ключ ОБЯЗАТЕЛЬНО "miniapp", НЕ "frame"!
Ключ "frame" — это устаревший формат Frame V1. Для Mini App нужен "miniapp".

{
"accountAssociation": {
"header": "PENDING_SIGNATURE",
"payload": "PENDING",
"signature": "PENDING"
},
"miniapp": {
"version": "1",
"name": "APP_NAME",
"subtitle": "Subtitle here",
"tagline": "Max 30 characters tagline",
"description": "Max 170 characters. No emojis or special characters.",
"primaryCategory": "games",
"tags": ["tag1", "tag2", "tag3"],
"homeUrl": "https://YOUR_DOMAIN",
"iconUrl": "https://YOUR_DOMAIN/icon-1024.png",
"splashImageUrl": "https://YOUR_DOMAIN/splash-200.png",
"splashBackgroundColor": "#0a0a1a",
"heroImageUrl": "https://YOUR_DOMAIN/hero-1200x630.png",
"screenshotUrls": [],
"ogTitle": "APP_NAME",
"ogDescription": "Short OG description, max 100 chars",
"ogImageUrl": "https://YOUR_DOMAIN/og-1200x630.png"
},
"baseBuilder": {
"ownerAddress": "0xYOUR_BUILDER_ADDRESS"
}
}

Заполни поля из PROJECT_BRIEF.md:
- name, homeUrl, ownerAddress — из проекта
- iconUrl, splashImageUrl, heroImageUrl, ogImageUrl — указывают на файлы сгенерированные в Шаге 1
- splashBackgroundColor — из --bg цвета (default: #0a0a1a)

Ограничения (ПРОВЕРЬ!):

┌──────────┬───────────────────────────────────────────────────────────────────────────┬────────┐
│ │ │ Ошибка │
│ Поле │ Лимит │ если │
│ │ │ наруше │
│ │ │ но │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ │ │ Обреже │
│ name │ <= 32 chars │ тся в │
│ │ │ UI │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ │ │ Reject │
│ subtitle │ <= 30 chars, sentence case, без точки │ при │
│ │ │ ревью │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ tagline │ <= 30 chars │ Обреже │
│ │ │ тся │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ descript │ <= 170 chars, без эмодзи │ Reject │
│ ion │ │ │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ │ │ Ошибка │
│ tags │ max 5, каждый <= 20 chars, lowercase, без пробелов │ индек │
│ │ │ сации │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ primaryC │ Одно из: games/social/finance/utility/productivity/entertainment/health-f │ Ошибка │
│ ategory │ itness/news-media/music/shopping/education/developer-tools/art-creativity │ │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ iconUrl │ PNG, 1024×1024, без прозрачности │ Обязат │
│ │ │ ельно │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ splashIm │ │ Рекоме │
│ ageUrl │ PNG, ~200×200 │ ндуетс │
│ │ │ я │
├──────────┼───────────────────────────────────────────────────────────────────────────┼────────┤
│ heroImag │ │ Рекоме │
│ eUrl │ PNG, 1200×630 │ ндуетс │
│ │ │ я │
└──────────┴───────────────────────────────────────────────────────────────────────────┴────────┘

ШАГ 5: EMBED METADATA В HTML

Добавь в <head> файла index.html ОБА meta тега (для совместимости):

<!-- Farcaster Mini App embed — ОБЯЗАТЕЛЬНО ОБА тега -->
<meta name="fc:miniapp"
content='{"version":"1","imageUrl":"https://YOUR_DOMAIN/og-1200x630.png","button":{"title":"Open
App","action":{"type":"launch_miniapp","name":"APP_NAME","url":"https://YOUR_DOMAIN","splashImageUrl
":"https://YOUR_DOMAIN/splash-200.png","splashBackgroundColor":"#0a0a1a"}}}' />
<meta name="fc:frame"
content='{"version":"1","imageUrl":"https://YOUR_DOMAIN/og-1200x630.png","button":{"title":"Open
App","action":{"type":"launch_miniapp","name":"APP_NAME","url":"https://YOUR_DOMAIN","splashImageUrl
":"https://YOUR_DOMAIN/splash-200.png","splashBackgroundColor":"#0a0a1a"}}}' />

КРИТИЧНО: Ставь ОБА тега — fc:miniapp И fc:frame.
fc:miniapp — новый формат (Base App каталог).
fc:frame — обратная совместимость (Warpcast лента, embed preview).

Замени YOUR_DOMAIN и APP_NAME на реальные значения.

ШАГ 6: SECURITY HEADERS (если есть бэкенд)

Если бэкенд отдаёт фронтенд — добавь в CSP:
frame-ancestors 'self' https://*.base.org https://warpcast.com https://*.coinbase.com
https://*.farcaster.xyz

Без этого — Base App не сможет загрузить приложение в iframe.

ШАГ 7: ПРОВЕРКИ

# 1. Картинки существуют
for f in public/icon-1024.png public/splash-200.png public/hero-1200x630.png public/og-1200x630.png;
do
test -f "$f" && echo "✅ $f" || echo "❌ $f MISSING"
done

# 2. Manifest JSON валиден
cat public/.well-known/farcaster.json | python3 -m json.tool > /dev/null && echo "✅ Valid JSON" ||
echo "❌ Invalid JSON"

# 3. Ключ = miniapp
python3 -c "import json; d=json.load(open('public/.well-known/farcaster.json')); assert 'miniapp' in
d and 'frame' not in d, 'FAIL'; print('✅ miniapp key')"

# 4. Tagline существует и <= 30 chars
python3 -c "
import json; d=json.load(open('public/.well-known/farcaster.json'))['miniapp']
tl = d.get('tagline','')
assert tl, 'MISSING'
assert len(tl) <= 30, f'TOO LONG: {len(tl)}/30'
print(f'✅ tagline: \"{tl}\" ({len(tl)}/30)')
"

# 5. Все поля заполнены
python3 -c "
import json; d=json.load(open('public/.well-known/farcaster.json'))['miniapp']
for k in ['name','tagline','description','homeUrl','iconUrl','primaryCategory']:
v = d.get(k,'')
print(f'{chr(9989) if v else chr(10060)} {k}: {v[:50] if v else \"MISSING\"}')"

# 6. ОБА meta тега в HTML
grep -q 'fc:miniapp' index.html && echo "✅ fc:miniapp meta" || echo "❌ fc:miniapp meta MISSING"
grep -q 'fc:frame' index.html && echo "✅ fc:frame meta" || echo "❌ fc:frame meta MISSING"

# 7. SDK ready
grep -rq 'sdk.actions.ready\|sdk\.actions\.ready' src/ && echo "✅ sdk.actions.ready()" || echo "❌
sdk.actions.ready() NOT FOUND"

# 8. Build
npm run build

ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

ОБЯЗАТЕЛЬНО: Допиши в PROJECT_BRIEF.md:

## 16. FARCASTER MANIFEST + ASSETS (Prompt 5)
Дата: [сегодня]

- Assets: сгенерированы скриптом ✅
- icon-1024.png: [размер]
- splash-200.png: [размер]
- hero-1200x630.png: [размер] ([AI/процедурный])
- og-1200x630.png: [размер] ([AI/процедурный])
- Manifest: public/.well-known/farcaster.json ✅
- SDK: @farcaster/miniapp-sdk@[версия]
- sdk.actions.ready(): [файл:строка]
- fc:miniapp meta: [файл] ✅
- fc:frame meta: [файл] ✅
- Account Association: ⏳ (после деплоя в Prompt 6)
- CSP frame-ancestors: ✅/N/A

Manifest fields:
- name: "[value]" ([X]/32 chars)
- tagline: "[value]" ([X]/30 chars)
- description: "[value]" ([X]/170 chars)
- primaryCategory: [value]

Напиши "Manifest и ассеты готовы, PROJECT_BRIEF.md обновлён. Готов к Prompt 6."

ЗАДАЧА: Финальный деплой, подпись манифеста, Farcaster setup, smoke test

Прочитай PROJECT_BRIEF.md — секции 8 (деплой) и 16 (manifest).

КОНТЕКСТ

Всё подготовлено в предыдущих промптах. Этот промпт делает:
1. Production билд + деплой
2. Регистрация FID (если нет)
3. Account Association (подпись манифеста)
4. Farcaster full setup (storage, signer, профиль, fname, первый каст)
5. Rebuild + redeploy с подписанным манифестом
6. Smoke test

---
ШАГ 1: PRODUCTION BUILD

npm run build

Проверь:
- Билд без ошибок
- .well-known/farcaster.json есть в build output (dist/ или .next/)
- grep "84532" dist/assets/*.js — НЕ должен находить testnet chain ID

ТИПИЧНАЯ ОШИБКА: VITE_* переменные бэйкаются в бандл при билде.
Если билдишь без VITE_NETWORK=mainnet, в бандле будет testnet.

ШАГ 2: ДЕПЛОЙ

Определи платформу из PROJECT_BRIEF.md:

Vercel

vercel --prod

Railway

unset RAILWAY_TOKEN && railway up

Запомни production URL — нужен для шагов ниже.

ШАГ 3: РЕГИСТРАЦИЯ FID

FID — числовой Farcaster ID. Без него нельзя подписать манифест и постить.

Создай scripts/register-fid.mjs:

ВАЖНО: Расширение .mjs ОБЯЗАТЕЛЬНО. viem и @farcaster/hub-nodejs работают ТОЛЬКО через ES modules
import. require() = ошибка.

#!/usr/bin/env node
import { createPublicClient, createWalletClient, http } from 'viem'
import { privateKeyToAccount } from 'viem/accounts'
import { optimism } from 'viem/chains'
import { readFileSync } from 'fs'

const envFile = readFileSync('./contracts/.env', 'utf8')
const keyMatch = envFile.match(/OPERATOR_PRIVATE_KEY=(.+)/)
if (!keyMatch) { console.error('OPERATOR_PRIVATE_KEY not found'); process.exit(1) }
const pk = keyMatch[1].trim().startsWith('0x') ? keyMatch[1].trim() : `0x${keyMatch[1].trim()}`

const account = privateKeyToAccount(pk)
console.log(`Wallet: ${account.address}`)

const RECOVERY_PROXY = '0x00000000FcB080a4D6c39a9354dA9EB9bC104cd7'
const ID_REGISTRY = '0x00000000Fc6c5F01Fc30151999387Bb99A9f489b'
const ID_GATEWAY = '0x00000000Fc25870C6eD6b6c7E41Fb078b7656f69'

const ID_REGISTRY_ABI = [
{ type: 'function', name: 'idOf', stateMutability: 'view',
inputs: [{ name: 'owner', type: 'address' }],
outputs: [{ name: '', type: 'uint256' }] }
]
const ID_GATEWAY_ABI = [
{ type: 'function', name: 'price', stateMutability: 'view',
inputs: [{ name: 'extraStorage', type: 'uint256' }],
outputs: [{ name: '', type: 'uint256' }] },
{ type: 'function', name: 'register', stateMutability: 'payable',
inputs: [{ name: 'recovery', type: 'address' }, { name: 'extraStorage', type: 'uint256' }],
outputs: [{ name: '', type: 'uint256' }] }
]

const publicClient = createPublicClient({ chain: optimism, transport:
http('https://mainnet.optimism.io') })
const walletClient = createWalletClient({ account, chain: optimism, transport:
http('https://mainnet.optimism.io') })

const existingFid = await publicClient.readContract({
address: ID_REGISTRY, abi: ID_REGISTRY_ABI, functionName: 'idOf', args: [account.address]
})

if (existingFid > 0n) {
console.log(`Already registered — FID: ${existingFid}`)
process.exit(0)
}

console.log('Registering...')
const price = await publicClient.readContract({
address: ID_GATEWAY, abi: ID_GATEWAY_ABI, functionName: 'price', args: [0n]
})
console.log(`Price: ${Number(price) / 1e18} ETH`)

const hash = await walletClient.writeContract({
address: ID_GATEWAY, abi: ID_GATEWAY_ABI, functionName: 'register',
args: [RECOVERY_PROXY, 0n], value: price
})
await publicClient.waitForTransactionReceipt({ hash })

const newFid = await publicClient.readContract({
address: ID_REGISTRY, abi: ID_REGISTRY_ABI, functionName: 'idOf', args: [account.address]
})
console.log(`Registered FID: ${newFid}`)

node scripts/register-fid.mjs
# Запомни FID — нужен для всех следующих шагов

Если у кошелька УЖЕ есть FID — скрипт просто напечатает его и выйдет.

ШАГ 4: ACCOUNT ASSOCIATION

Создай scripts/sign-manifest.mjs:

#!/usr/bin/env node
import { privateKeyToAccount } from 'viem/accounts'
import { readFileSync, writeFileSync } from 'fs'

const envFile = readFileSync('./contracts/.env', 'utf8')
const keyMatch = envFile.match(/OPERATOR_PRIVATE_KEY=(.+)/)
if (!keyMatch) { console.error('OPERATOR_PRIVATE_KEY not found'); process.exit(1) }
const pk = keyMatch[1].trim().startsWith('0x') ? keyMatch[1].trim() : `0x${keyMatch[1].trim()}`

const FID = parseInt(process.env.FID)
if (!FID) { console.error('FID env var required'); process.exit(1) }

const MANIFEST_PATH = './public/.well-known/farcaster.json'
const manifest = JSON.parse(readFileSync(MANIFEST_PATH, 'utf8'))
const DOMAIN = new URL(manifest.miniapp?.homeUrl).hostname

const account = privateKeyToAccount(pk)
console.log(`Signing — FID: ${FID}, Domain: ${DOMAIN}, Wallet: ${account.address}`)

function base64url(obj) {
return Buffer.from(JSON.stringify(obj)).toString('base64')
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
}
function base64urlBytes(hexStr) {
return Buffer.from(hexStr.slice(2), 'hex').toString('base64')
.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
}

const header = { fid: FID, type: 'custody', key: account.address }
const payload = { domain: DOMAIN }
const encodedHeader = base64url(header)
const encodedPayload = base64url(payload)

const signature = await account.signMessage({ message: `${encodedHeader}.${encodedPayload}` })

manifest.accountAssociation = {
header: encodedHeader,
payload: encodedPayload,
signature: base64urlBytes(signature)
}
writeFileSync(MANIFEST_PATH, JSON.stringify(manifest, null, 2) + '\n')
console.log('Account Association signed')

FID=YOUR_FID node scripts/sign-manifest.mjs

ШАГ 5: FARCASTER FULL SETUP

Storage + Ed25519 signer + профиль + fname + первый каст.

npm install @noble/ed25519 @noble/hashes @farcaster/hub-nodejs

ИЗВЕСТНЫЕ ЛОВУШКИ (все найдены на реальных проектах — ОБЯЗАТЕЛЬНО УЧТИ)

Каждый из этих пунктов стоил реальных денег и часов отладки.
НЕ пропускай, НЕ "упрощай". Если проигнорируешь — получишь те же ошибки.

1. ESM-only (.mjs)
viem и @farcaster/hub-nodejs = ES modules. Скрипт ОБЯЗАТЕЛЬНО .mjs. require() = ошибка.

2. ed25519 sha512 инициализация
БЕЗ этих строк NobleEd25519Signer не может подписывать — молча возвращает ошибку:
import * as ed from '@noble/ed25519'
import { sha512 } from '@noble/hashes/sha512'
ed.etc.sha512Sync = (...m) => sha512(ed.etc.concatBytes(...m))

3. @noble/ed25519 v3: randomSecretKey(), НЕ randomPrivateKey()
Функция переименована в v3. getPublicKeyAsync() принимает Uint8Array, НЕ hex string.
const privKeyBytes = ed.utils.randomSecretKey() // ← Uint8Array
const pubKeyBytes = await ed.getPublicKeyAsync(privKeyBytes) // ← тоже Uint8Array
// Конвертируй в hex ТОЛЬКО для сохранения в JSON:
const privHex = Buffer.from(privKeyBytes).toString('hex')

4. StorageRegistry.rentedUnits — ГЛОБАЛЬНЫЙ счётчик, НЕ per-FID
Нельзя проверить "арендован ли storage для конкретного FID" on-chain. Без защиты = повторные
платежи.
Решение — двойная проверка:
- Primary: локальный маркер файл .storage-rented (JSON с fid и tx hash)
- Secondary: Hub API storageLimitsByFid?fid=
- Rent ТОЛЬКО если ОБА отрицательные
- Записать маркер СРАЗУ после успешного rent (до любых других операций)

5. KeyGateway.add() metadata — TUPLE encoding, не flat
Solidity abi.decode(data, (SignedKeyRequestMetadata)) = struct = tuple.
Flat encoding (uint256, address, bytes, uint256) → REVERT (другой byte layout).
const metadata = encodeAbiParameters(
[{ type: 'tuple', components: [
{ name: 'requestFid', type: 'uint256' },
{ name: 'requestSigner', type: 'address' },
{ name: 'signature', type: 'bytes' },
{ name: 'deadline', type: 'uint256' },
]}],
[{ requestFid: BigInt(FID), requestSigner: account.address, signature: sig, deadline }]
)

6. Neynar demo key (NEYNAR_API_DOCS) → 403 из Node.js fetch()
Тот же ключ работает из curl. Для ВСЕХ запросов к Hub API используй execSync('curl ...'):
const result = execSync(
`curl -s "${HUB_URL}/endpoint?fid=${FID}" -H "x-api-key: ${NEYNAR_KEY}"`,
{ encoding: 'utf8' }
)
const data = JSON.parse(result)

7. makeUserDataAdd / makeCastAdd — сигнатура (body, dataOptions, signer)
FID передаётся во ВТОРОЙ аргумент, НЕ в body. Если fid в body → ошибка "fid is missing".
// ПРАВИЛЬНО:
makeUserDataAdd(
{ type, value }, // body
{ fid: FID, network: 1 }, // dataOptions — fid ЗДЕСЬ
signer
)

// НЕПРАВИЛЬНО (fid в body):
makeUserDataAdd({ type, value, fid: FID }, signer) // → "fid is missing"

8. signUserNameProofClaim возвращает Uint8Array, не hex
Fnames API (fnames.farcaster.xyz/transfers) ожидает hex string с 0x префиксом:
const sig = await eip712Signer.signUserNameProofClaim({ name, timestamp: BigInt(ts), owner })
if (sig.isOk()) {
const sigHex = '0x' + Buffer.from(sig.value).toString('hex')
// Используй sigHex в JSON body
}

9. submitMessage — ТОЛЬКО curl --data-binary, НЕ fetch
Node.js fetch ломает бинарные protobuf данные при отправке в Hub:
const encoded = Buffer.from(Message.encode(msg).finish())
writeFileSync(tmpFile, encoded)
execSync(`curl -s -X POST "${HUB_URL}/submitMessage" \
-H "x-api-key: ${NEYNAR_KEY}" \
-H "Content-Type: application/octet-stream" \
--data-binary @${tmpFile}`, { encoding: 'utf8' })

10. Hub sync — НЕ exit на timeout
Hub'ы синкают ончейн-события с задержкой (минуты → часы). Если поллинг не нашёл signer за 10 минут —
НЕ exit. Продолжай — signer скорее всего уже работает, просто API отстаёт.

11. Hub sync key comparison — strip 0x, lowercase
Hub возвращает ключ с 0x префиксом. Локальный ключ без 0x. При сравнении:
const hubKey = (e.signerEventBody?.key || '').toLowerCase().replace('0x', '')
const localKey = signerPublicKey.toLowerCase()
const match = hubKey.includes(localKey) || localKey.includes(hubKey)

12. Секреты в .gitignore
.farcaster-app-signer.json содержит приватный ключ signer. .storage-rented — маркер.
Оба ОБЯЗАТЕЛЬНО добавить в .gitignore.

---
Скрипт scripts/setup-farcaster.mjs

#!/usr/bin/env node
/**
* Full Farcaster profile setup: storage, signer, profile, fname, first cast.
* Idempotent — safe to re-run, skips completed steps.
*
* Usage: FID=12345 FNAME=appname node scripts/setup-farcaster.mjs
* Requires: OPERATOR_PRIVATE_KEY in contracts/.env
*/

import { createPublicClient, createWalletClient, http, encodeAbiParameters } from 'viem'
import { privateKeyToAccount } from 'viem/accounts'
import { optimism } from 'viem/chains'
import { readFileSync, writeFileSync, existsSync } from 'fs'
import { execSync } from 'child_process'
import { tmpdir } from 'os'
import { join } from 'path'
import * as ed from '@noble/ed25519'
import { sha512 } from '@noble/hashes/sha512'
import {
NobleEd25519Signer,
ViemLocalEip712Signer,
makeUserDataAdd,
makeCastAdd,
UserDataType,
Message,
} from '@farcaster/hub-nodejs'

// ЛОВУШКА #2: Без этой строки NobleEd25519Signer не работает
ed.etc.sha512Sync = (...m) => sha512(ed.etc.concatBytes(...m))

// --- Config (подставь реальные значения) ---
const envFile = readFileSync('./contracts/.env', 'utf8')
const keyMatch = envFile.match(/OPERATOR_PRIVATE_KEY=(.+)/)
if (!keyMatch) { console.error('OPERATOR_PRIVATE_KEY not found'); process.exit(1) }
const pk = keyMatch[1].trim().startsWith('0x') ? keyMatch[1].trim() : `0x${keyMatch[1].trim()}`

const FID = parseInt(process.env.FID)
if (!FID) { console.error('FID env var required'); process.exit(1) }

const FNAME = process.env.FNAME || 'appname' // ← ЗАМЕНИТЬ
const DOMAIN = 'your-domain.vercel.app' // ← ЗАМЕНИТЬ
const APP_NAME = 'App Name' // ← ЗАМЕНИТЬ
const BIO = 'App description for Farcaster profile.' // ← ЗАМЕНИТЬ
const HUB_URL = 'https://snapchain-api.neynar.com/v1'
const NEYNAR_KEY = 'NEYNAR_API_DOCS'
const SIGNER_FILE = '.farcaster-app-signer.json'

const account = privateKeyToAccount(pk)
console.log(`\nSetup Farcaster — FID: ${FID}, Wallet: ${account.address}\n`)

const publicClient = createPublicClient({ chain: optimism, transport:
http('https://mainnet.optimism.io') })
const walletClient = createWalletClient({ account, chain: optimism, transport:
http('https://mainnet.optimism.io') })

// --- Contracts ---
const STORAGE_REGISTRY = '0x00000000fcCe7f938e7aE6D3c335bD6a1a7c593D'
const KEY_GATEWAY = '0x00000000fC56947c7E7183f8Ca4B62398CaAdf0B'
const SIGNED_KEY_REQUEST_VALIDATOR = '0x00000000FC700472606ED4fA22623Acf62c60553'

const STORAGE_ABI = [
{ type: 'function', name: 'price', stateMutability: 'view',
inputs: [{ name: 'units', type: 'uint256' }],
outputs: [{ name: '', type: 'uint256' }] },
{ type: 'function', name: 'rent', stateMutability: 'payable',
inputs: [{ name: 'fid', type: 'uint256' }, { name: 'units', type: 'uint256' }],
outputs: [{ name: 'overpayment', type: 'uint256' }] }
]

const KEY_GATEWAY_ABI = [
{ type: 'function', name: 'add', stateMutability: 'nonpayable',
inputs: [
{ name: 'keyType', type: 'uint32' },
{ name: 'key', type: 'bytes' },
{ name: 'metadataType', type: 'uint8' },
{ name: 'metadata', type: 'bytes' }
],
outputs: [] }
]

// ========== STEP 1: STORAGE ==========
console.log('--- Step 1: Storage ---')
// ЛОВУШКА #4: rentedUnits — глобальный. Маркер файл + Hub API = двойная защита.
const STORAGE_MARKER = '.storage-rented'
let hasStorage = false

// Check 1: маркер файл (primary — переживает API outages)
if (existsSync(STORAGE_MARKER)) {
const marker = JSON.parse(readFileSync(STORAGE_MARKER, 'utf8'))
if (marker.fid === FID) {
hasStorage = true
console.log(`Storage already rented (marker: tx ${marker.tx?.slice(0, 16)}...)`)
}
}

// Check 2: Hub API (secondary) — ЛОВУШКА #6: curl, не fetch
if (!hasStorage) {
try {
const curlResult = execSync(
`curl -s "${HUB_URL}/storageLimitsByFid?fid=${FID}" -H "x-api-key: ${NEYNAR_KEY}"`,
{ encoding: 'utf8' }
)
const hubData = JSON.parse(curlResult)
if (hubData.limits?.length > 0) {
hasStorage = true
console.log(`Storage confirmed by Hub (${hubData.limits.length} limits)`)
writeFileSync(STORAGE_MARKER, JSON.stringify({ fid: FID, tx: 'confirmed-by-hub' }))
}
} catch {}
}

if (!hasStorage) {
const storagePrice = await publicClient.readContract({
address: STORAGE_REGISTRY, abi: STORAGE_ABI, functionName: 'price', args: [1n]
})
console.log(`Renting 1 unit for ${Number(storagePrice) / 1e18} ETH...`)
const hash = await walletClient.writeContract({
address: STORAGE_REGISTRY, abi: STORAGE_ABI, functionName: 'rent',
args: [BigInt(FID), 1n], value: storagePrice
})
await publicClient.waitForTransactionReceipt({ hash })
// Маркер СРАЗУ после rent — до любых других операций
writeFileSync(STORAGE_MARKER, JSON.stringify({ fid: FID, tx: hash, date: new Date().toISOString()
}))
console.log(`Storage rented. Tx: ${hash}`)
}

// ========== STEP 2: ED25519 KEYPAIR ==========
console.log('\n--- Step 2: Ed25519 Keypair ---')
let signerPrivateKey, signerPublicKey

if (existsSync(SIGNER_FILE)) {
const saved = JSON.parse(readFileSync(SIGNER_FILE, 'utf8'))
signerPrivateKey = saved.privateKey
signerPublicKey = saved.publicKey
console.log(`Loaded existing keypair from ${SIGNER_FILE}`)
} else {
// ЛОВУШКА #3: randomSecretKey(), НЕ randomPrivateKey(). Принимает/возвращает Uint8Array.
const privKeyBytes = ed.utils.randomSecretKey()
signerPrivateKey = Buffer.from(privKeyBytes).toString('hex')
const pubKeyBytes = await ed.getPublicKeyAsync(privKeyBytes)
signerPublicKey = Buffer.from(pubKeyBytes).toString('hex')
writeFileSync(SIGNER_FILE, JSON.stringify({ privateKey: signerPrivateKey, publicKey:
signerPublicKey }, null, 2))
console.log(`Generated new keypair, saved to ${SIGNER_FILE}`)

// ЛОВУШКА #12: секреты в .gitignore
const gitignore = existsSync('.gitignore') ? readFileSync('.gitignore', 'utf8') : ''
if (!gitignore.includes(SIGNER_FILE)) {
writeFileSync('.gitignore', gitignore.trimEnd() + `\n${SIGNER_FILE}\n.storage-rented\n`)
}
}
console.log(` Public key: 0x${signerPublicKey.slice(0, 16)}...`)

// ========== STEP 3: REGISTER SIGNER ON-CHAIN ==========
console.log('\n--- Step 3: Register Signer ---')
const publicKeyBytes = `0x${signerPublicKey}`
const deadline = BigInt(Math.floor(Date.now() / 1000) + 86400)

const eip712Signer = new ViemLocalEip712Signer(account)
const signedKeyRequestSig = await account.signTypedData({
domain: {
name: 'Farcaster SignedKeyRequestValidator',
version: '1',
chainId: 10,
verifyingContract: SIGNED_KEY_REQUEST_VALIDATOR,
},
types: {
SignedKeyRequest: [
{ name: 'requestFid', type: 'uint256' },
{ name: 'key', type: 'bytes' },
{ name: 'deadline', type: 'uint256' },
],
},
primaryType: 'SignedKeyRequest',
message: { requestFid: BigInt(FID), key: publicKeyBytes, deadline },
})

// ЛОВУШКА #5: TUPLE encoding, не flat
const metadata = encodeAbiParameters(
[{ type: 'tuple', components: [
{ name: 'requestFid', type: 'uint256' },
{ name: 'requestSigner', type: 'address' },
{ name: 'signature', type: 'bytes' },
{ name: 'deadline', type: 'uint256' },
]}],
[{ requestFid: BigInt(FID), requestSigner: account.address, signature: signedKeyRequestSig,
deadline }]
)

try {
const hash = await walletClient.writeContract({
address: KEY_GATEWAY, abi: KEY_GATEWAY_ABI, functionName: 'add',
args: [1, publicKeyBytes, 1, metadata]
})
await publicClient.waitForTransactionReceipt({ hash })
console.log(`Signer registered. Tx: ${hash}`)
} catch (err) {
if (err.message?.includes('0xbaf3f0f7') || err.message?.includes('already')) {
console.log('Signer already registered (skipping)')
} else {
throw err
}
}

// ========== STEP 4: WAIT FOR HUB SYNC ==========
console.log('\n--- Step 4: Wait for Hub sync ---')
const start = Date.now()
let synced = false
const pubKeyLower = signerPublicKey.toLowerCase()
while (Date.now() - start < 600_000) {
try {
// ЛОВУШКА #6: curl, не fetch
const curlResult = execSync(
`curl -s "${HUB_URL}/onChainSignersByFid?fid=${FID}" -H "x-api-key: ${NEYNAR_KEY}"`,
{ encoding: 'utf8' }
)
const data = JSON.parse(curlResult)
const signers = data.events || []
// ЛОВУШКА #11: strip 0x, lowercase
if (signers.some(e => {
const hubKey = (e.signerEventBody?.key || '').toLowerCase().replace('0x', '')
return hubKey.includes(pubKeyLower) || pubKeyLower.includes(hubKey)
})) {
synced = true
break
}
} catch {}
process.stdout.write('.')
await new Promise(r => setTimeout(r, 15_000))
}
if (synced) {
console.log('\nSigner synced to Hub')
} else {
// ЛОВУШКА #10: НЕ exit — продолжай
console.log('\nSync timeout (10 min). Continuing anyway — signer may work.')
}

// ========== STEP 5: PROFILE ==========
console.log('\n--- Step 5: Set Profile ---')
const signer = new NobleEd25519Signer(new Uint8Array(Buffer.from(signerPrivateKey, 'hex')))

// ЛОВУШКА #9: submitMessage ТОЛЬКО через curl --data-binary
async function submitToHub(msg) {
const encoded = Buffer.from(Message.encode(msg).finish())
const tmpFile = join(tmpdir(), `fc-msg-${Date.now()}.bin`)
writeFileSync(tmpFile, encoded)
const result = execSync(
`curl -s -X POST "${HUB_URL}/submitMessage" -H "x-api-key: ${NEYNAR_KEY}" -H "Content-Type:
application/octet-stream" --data-binary @${tmpFile}`,
{ encoding: 'utf8' }
)
return JSON.parse(result)
}

const profileData = [
{ type: UserDataType.DISPLAY, value: APP_NAME },
{ type: UserDataType.PFP, value: `https://${DOMAIN}/icon-1024.png` },
{ type: UserDataType.BIO, value: BIO },
{ type: UserDataType.URL, value: `https://${DOMAIN}` },
]

for (const { type, value } of profileData) {
const typeName = Object.entries(UserDataType).find(([, v]) => v === type)?.[0] || type
try {
// ЛОВУШКА #7: fid во ВТОРОМ аргументе (dataOptions), НЕ в body
const msgResult = await makeUserDataAdd(
{ type, value },
{ fid: FID, network: 1 },
signer
)
if (msgResult.isErr()) { console.log(` ${typeName}: ${msgResult.error.message}`); continue }
const hubResult = await submitToHub(msgResult.value)
if (hubResult.hash) {
console.log(` ${typeName}: ${value.slice(0, 50)}`)
} else {
console.log(` ${typeName}: ${JSON.stringify(hubResult).slice(0, 100)}`)
}
} catch (err) {
console.log(` ${typeName}: ${err.message?.slice(0, 80)}`)
}
}

// ========== STEP 6: FNAME + FIRST CAST ==========
console.log('\n--- Step 6: Fname ---')
try {
const timestamp = Math.floor(Date.now() / 1000)
const fnameSignature = await eip712Signer.signUserNameProofClaim({
name: FNAME,
timestamp: BigInt(timestamp),
owner: account.address,
})

if (fnameSignature.isOk()) {
// ЛОВУШКА #8: signUserNameProofClaim → Uint8Array → hex для JSON API
const sigHex = '0x' + Buffer.from(fnameSignature.value).toString('hex')
const fnameRes = await fetch('https://fnames.farcaster.xyz/transfers', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
name: FNAME, from: 0, to: FID, fid: FID,
owner: account.address, timestamp, signature: sigHex,
}),
})
const fnameData = await fnameRes.json()
if (fnameRes.ok || fnameData.code === 'ALREADY_REGISTERED') {
console.log(`Fname: @${FNAME}`)
} else {
console.log(`Fname: ${JSON.stringify(fnameData).slice(0, 100)}`)
}
}

// ЛОВУШКА #7: fid в dataOptions
const usernameMsg = await makeUserDataAdd(
{ type: UserDataType.USERNAME, value: FNAME },
{ fid: FID, network: 1 },
signer
)
if (usernameMsg.isOk()) {
await submitToHub(usernameMsg.value)
console.log(` USERNAME set to ${FNAME}`)
}
} catch (err) {
console.log(`Fname error: ${err.message?.slice(0, 80)}`)
}

// First cast
console.log('\n--- First Cast ---')
try {
const castText = `${APP_NAME} is live!\n\nhttps://${DOMAIN}`
// ЛОВУШКА #7: fid в dataOptions
const castMsg = await makeCastAdd(
{
text: castText,
embeds: [{ url: `https://${DOMAIN}` }],
embedsDeprecated: [],
mentions: [],
mentionsPositions: [],
},
{ fid: FID, network: 1 },
signer
)
if (castMsg.isOk()) {
const castResult = await submitToHub(castMsg.value)
if (castResult.hash) {
console.log(`First cast posted: "${castText.slice(0, 50)}..."`)
} else {
console.log(`Cast: ${JSON.stringify(castResult).slice(0, 100)}`)
}
} else {
console.log(`Cast build error: ${castMsg.error.message}`)
}
} catch (err) {
console.log(`Cast error: ${err.message?.slice(0, 80)}`)
}

console.log('\nFarcaster setup complete!')

FID=YOUR_FID FNAME=appname node scripts/setup-farcaster.mjs

Скрипт идемпотентен — безопасно перезапускать. Выполненные шаги будут пропущены.
Если Hub отвечает ошибками — подожди 5-10 минут и перезапусти.

Стоимость всех операций: ~0.0006 ETH на Optimism

ШАГ 6: REBUILD + REDEPLOY

Манифест обновлён (Account Association подписана). Нужен передеплой:

npm run build
vercel --prod # или: unset RAILWAY_TOKEN && railway up

ШАГ 7: SMOKE TEST

DOMAIN="YOUR_PRODUCTION_DOMAIN"

# 1. HTTP status
echo "=== HTTP Status ==="
curl -s -o /dev/null -w "%{http_code}" https://$DOMAIN

# 2. Manifest
echo -e "\n=== Manifest ==="
curl -s https://$DOMAIN/.well-known/farcaster.json | python3 -c "
import json,sys
d = json.load(sys.stdin)
aa = d.get('accountAssociation', {})
if aa.get('header','').startswith('PENDING') or not aa.get('header'):
print('Account Association: NOT signed')
else:
print('Account Association: signed')
key_used = 'miniapp' if 'miniapp' in d else ('frame' if 'frame' in d else 'NONE')
print(f'Manifest key: {key_used}')
mini = d.get('miniapp', d.get('frame', {}))
for f in ['name','homeUrl','iconUrl','tagline']:
v = mini.get(f)
print(f' {f}: {v or \"MISSING\"}')"

# 3. Assets
echo -e "\n=== Assets ==="
curl -s https://$DOMAIN/.well-known/farcaster.json | python3 -c "
import json,sys,subprocess
d = json.load(sys.stdin)
mini = d.get('miniapp', d.get('frame', {}))
for key in ['iconUrl','splashImageUrl','heroImageUrl','ogImageUrl']:
url = mini.get(key)
if url:
code = subprocess.run(['curl','-s','-o','/dev/null','-w','%{http_code}',url],capture_output=
True,text=True).stdout
print(f'{key}: {code}')"

# 4. Meta tags
echo -e "\n=== Meta Tags ==="
curl -s https://$DOMAIN | python3 -c "
import sys; html = sys.stdin.read()
for tag in ['fc:miniapp','fc:frame','og:title','og:image']:
print(f'{tag}: {\"found\" if tag in html else \"MISSING\"}')"

ШАГ 8: ВЕРДИКТ

Всё зелёное → ВЫВОД.
Account Association не подписана → вернись к шагу 4.
Assets 404 → нормально если картинки ещё не созданы. Скажи юзеру какие файлы нужны.
Meta tags missing → поправь сам.

ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

ОБЯЗАТЕЛЬНО: Допиши в PROJECT_BRIEF.md:

## 17. ДЕПЛОЙ + FARCASTER SETUP (Prompt 6)
Дата: [сегодня]

URL: https://...
Platform: [Vercel/Railway]
FID: [номер]
Wallet: [адрес]

Account Association: signed
Farcaster Profile: Display/PFP/BIO/URL set
First Cast: posted
Signer: 0x... (Ed25519)
Fname: [результат]

Smoke Test:
- HTTP 200: Y/N
- Manifest (miniapp key): Y/N
- Account Association: Y/N
- Assets: Y/N (список недостающих)
- Meta tags (fc:miniapp + fc:frame): Y/N

Scripts:
- scripts/register-fid.mjs
- scripts/sign-manifest.mjs
- scripts/setup-farcaster.mjs

Deploy command: [команда]

Напиши "Production деплой и Farcaster setup завершены. Готов к Prompt 7."

ЗАДАЧА: Зарегистрировать приложение и запустить

Прочитай PROJECT_BRIEF.md — секция 17 (деплой).

КОНТЕКСТ

Приложение задеплоено и работает. Часть шагов — ручные (base.dev UI).
Агент не может кликать в браузере → даёт ТОЧНЫЕ инструкции и ждёт.

---
ШАГ 0: ПРОВЕРКИ ПЕРЕД ЗАПУСКОМ

Перед регистрацией на base.dev — убедись что всё настроено:

0.1: CORS на .well-known (КРИТИЧНО для base.dev)

base.dev делает server-side fetch /.well-known/farcaster.json — без CORS получишь 502.
Проверь vercel.json — ДОЛЖНО быть отдельное правило для .well-known:

{
"headers": [
{
"source": "/.well-known/(.*)",
"headers": [
{ "key": "Access-Control-Allow-Origin", "value": "*" },
{ "key": "Access-Control-Allow-Methods", "value": "GET, OPTIONS" },
{ "key": "Access-Control-Allow-Headers", "value": "Content-Type" },
{ "key": "Cache-Control", "value": "public, max-age=300" },
{ "key": "X-Content-Type-Options", "value": "nosniff" }
]
},
{
"source": "/(.*)",
"headers": [ ... ]
}
]
}

Правило для .well-known ОБЯЗАТЕЛЬНО идёт ПЕРЕД /(.*)!

0.2: CSP frame-ancestors — добавить base.dev

В CSP заголовке frame-ancestors ОБЯЗАТЕЛЬНО должны быть:
frame-ancestors 'self' https://*.base.org https://*.base.dev https://base.dev https://warpcast.com
https://*.coinbase.com https://*.farcaster.xyz

0.3: Убрать X-Frame-Options (deprecated)

X-Frame-Options: ALLOW-FROM — DEPRECATED, не работает в Chrome/Firefox.
Удали этот заголовок полностью. Вместо него работает frame-ancestors в CSP.
Если оставить — может конфликтовать с frame-ancestors.

0.4: sdk.actions.ready() — ПОСЛЕ монтирования

SDK ready() ОБЯЗАТЕЛЬНО вызывается в useEffect ПОСЛЕ монтирования React, НЕ на верхнем уровне
модуля:

// ПРАВИЛЬНО:
import { sdk } from '@farcaster/miniapp-sdk'

function App() {
useEffect(() => {
sdk.actions.ready()
}, [])
// ...
}

// НЕПРАВИЛЬНО (может не сработать в iframe):
import('@farcaster/miniapp-sdk').then(({ sdk }) => {
sdk.actions.ready() // ← вызывается ДО React mount
})

base.dev preview показывает "Ready call: Not Ready" → sdk.actions.ready() не дошёл до хоста.
base.dev preview показывает "Ready call: Ready" → всё ок.

0.5: Применить и задеплоить

Если что-то из 0.1-0.4 пришлось менять:
npm run build && vercel --prod

Проверь CORS:
curl -sI "https://YOUR_DOMAIN/.well-known/farcaster.json" | grep -i "access-control-allow-origin"
# Должно быть: access-control-allow-origin: *

---
ШАГ 1: РУЧНЫЕ ДЕЙСТВИЯ — СРАЗУ ПОСЛЕ ПРОВЕРОК

КРИТИЧНО: Покажи юзеру ВСЁ что нужно сделать руками
СРАЗУ, ДО автоматических проверок чеклиста.
Пока юзер работает в браузере — ты параллельно гоняешь чеклист (шаг 2).

ОБЯЗАТЕЛЬНО напиши юзеру:

═══════════════════════════════════════════════════════════
НУЖНО ДЕЙСТВИЕ: base.dev регистрация (2 мин)

1. Открой https://base.dev
2. Подключи кошелёк: [ownerAddress из manifest baseBuilder]
3. "Create App" → заполни:
- URL: [production URL из PROJECT_BRIEF.md]
- Name: [name из manifest]
- Category: [primaryCategory из manifest]
4. Скинь мне App ID — он в URL:
base.dev/apps/XXXXXXXXXXXXX
^^^^^^^^^^^^^ вот это

Если интерфейс непонятный — скинь скриншот,
разберёмся вместе.
═══════════════════════════════════════════════════════════

ЖДИ ОТВЕТА. Но пока ждёшь — параллельно запускай автоматические проверки (шаг 2).

ШАГ 2: АВТОМАТИЧЕСКИЕ ПРОВЕРКИ (параллельно с шагом 1)

Прогони полный чеклист. Всё что можно проверить — проверь:

DOMAIN="YOUR_PRODUCTION_DOMAIN" # из PROJECT_BRIEF.md

echo "=== LAUNCH CHECKLIST ==="

# Manifest
echo -e "\n--- Manifest ---"
curl -s https://$DOMAIN/.well-known/farcaster.json | python3 -c "
import json,sys
d = json.load(sys.stdin)
aa = d.get('accountAssociation',{})
mini = d.get('miniapp',{})
checks = [
('miniapp key', 'miniapp' in d),
('Account Association signed', aa.get('header','').startswith('ey')),
('name filled', bool(mini.get('name'))),
('tagline filled', bool(mini.get('tagline'))),
('description filled', bool(mini.get('description'))),
('homeUrl filled', bool(mini.get('homeUrl'))),
('iconUrl filled', bool(mini.get('iconUrl'))),
('splashImageUrl filled', bool(mini.get('splashImageUrl'))),
('heroImageUrl filled', bool(mini.get('heroImageUrl'))),
('primaryCategory filled', bool(mini.get('primaryCategory'))),
('baseBuilder.ownerAddress', bool(d.get('baseBuilder',{}).get('ownerAddress'))),
]
for name, ok in checks:
print(f'{\"✅\" if ok else \"❌\"} {name}')
"

# CORS check
echo -e "\n--- CORS (.well-known) ---"
CORS=$(curl -sI https://$DOMAIN/.well-known/farcaster.json | grep -i "access-control-allow-origin" |
tr -d '\r')
[ -n "$CORS" ] && echo "✅ $CORS" || echo "❌ No CORS headers — base.dev will get 502!"

# Meta tags
echo -e "\n--- Meta Tags ---"
curl -s https://$DOMAIN | python3 -c "
import sys; html = sys.stdin.read()
for tag in ['fc:miniapp','fc:frame','og:title','og:image','theme-color','viewport-fit=cover']:
print(f'{\"✅\" if tag in html else \"❌\"} {tag}')
if 'base:app_id' in html:
print('✅ base:app_id')
else:
print('⏳ base:app_id (after base.dev registration)')
"

# SDK
echo -e "\n--- SDK ---"
grep -rn "sdk.actions.ready\|sdk\.actions\.ready" src/ --include="*.js" --include="*.jsx"
--include="*.ts" --include="*.tsx" 2>/dev/null && echo " ✅ sdk.actions.ready()" || echo " ❌
sdk.actions.ready() NOT FOUND"

# Check it's in useEffect, not top-level
grep -B3 "sdk.actions.ready" src/**/*.{jsx,tsx,js,ts} 2>/dev/null | grep -q
"useEffect\|onMount\|mounted" && echo " ✅ Called after mount" || echo " ⚠️ Check:
sdk.actions.ready() should be in useEffect, not top-level"

# Assets
echo -e "\n--- Assets ---"
curl -s https://$DOMAIN/.well-known/farcaster.json | python3 -c "
import json,sys,subprocess
mini = json.load(sys.stdin).get('miniapp',{})
for key in ['iconUrl','splashImageUrl','heroImageUrl','ogImageUrl']:
url = mini.get(key)
if url:
code = subprocess.run(['curl','-s','-o','/dev/null','-w','%{http_code}',url],capture_output=
True,text=True).stdout
print(f'{\"✅\" if code==\"200\" else \"❌\"} {key}: {code}')
else:
print(f'⏳ {key}: not set')
"

# Farcaster profile + cast (from Prompt 6)
echo -e "\n--- Farcaster Profile ---"
FID_VAR="FID_FROM_PROJECT_BRIEF"
curl -s "https://api.neynar.com/v2/farcaster/user/bulk?fids=$FID_VAR" \
-H "x-api-key: NEYNAR_API_DOCS" | python3 -c "
import json,sys
d = json.load(sys.stdin)
users = d.get('users', [])
if users:
u = users[0]
print(f'✅ FID: {u.get(\"fid\")} Display: {u.get(\"display_name\")} @{u.get(\"username\")}')
else:
print('❌ User not indexed')
"

echo -e "\n--- Casts ---"
curl -s "https://api.neynar.com/v2/farcaster/feed/user/casts?fid=$FID_VAR&limit=3" \
-H "x-api-key: NEYNAR_API_DOCS" | python3 -c "
import json,sys
d = json.load(sys.stdin)
casts = d.get('casts', [])
if casts:
print(f'✅ {len(casts)} casts found. Latest: {casts[0].get(\"text\",\"\")[:60]}')
else:
print('❌ No casts — indexation not triggered')
"

# Security headers
echo -e "\n--- Security Headers ---"
curl -sI https://$DOMAIN | python3 -c "
import sys
headers = sys.stdin.read().lower()
# X-Frame-Options should NOT be present (deprecated)
if 'x-frame-options' in headers:
print('⚠️ X-Frame-Options present (deprecated — remove it, use CSP frame-ancestors)')
else:
print('✅ No X-Frame-Options (correct — using CSP frame-ancestors)')
# frame-ancestors should include base.dev
if 'base.dev' in headers:
print('✅ CSP frame-ancestors includes base.dev')
else:
print('❌ CSP frame-ancestors missing base.dev')
"

Если есть ❌ — поправь автоматически. Если ⏳ — ожидаемо, пометь.

ВАЖНО: Если manifest возвращает HTML вместо JSON — передеплой.
Vercel исключает .well-known/ из rewrites, но только после деплоя с файлом в dist/.

ВАЖНО: Если base.dev preview показывает "Failed to fetch manifest: 502" —
проверь CORS заголовки (шаг 0.1). Без Access-Control-Allow-Origin: * на
.well-known/farcaster.json base.dev не может сделать server-side fetch.

ШАГ 3: ПОСЛЕ ПОЛУЧЕНИЯ APP ID

Когда юзер скинет App ID — добавь meta тег в <head> index.html:
<meta name="base:app_id" content="APP_ID_FROM_USER" />

Перебилди + передеплой:
npm run build && vercel --prod

Проверь на base.dev/preview:
- "Ready call: Ready" (зелёный) — sdk.actions.ready() работает
- Манифест загружен без ошибок
- Аппка рендерится в превью

ШАГ 4: ИНДЕКСАЦИЯ

Индексация запускается когда URL шарится в Farcaster ленте.
Если Prompt 6 выполнен — первый каст уже опубликован (проверено в шаге 2).

Если каста НЕТ — перезапусти:
FID=YOUR_FID FNAME=appname node scripts/setup-farcaster.mjs

Скрипт идемпотентен — пропускает выполненные шаги.

ВНИМАНИЕ: Fname cooldown. Fnames API разрешает 1 transfer в 28 дней на FID.
Если FID использовался для другого проекта (другой fname) — переименовать нельзя
~28 дней. Живи с текущим fname или используй другой FID.

Если скрипт не работает (Hub не синкает >30 минут) — fallback:

═══════════════════════════════════════════════════════════
НУЖНО ДЕЙСТВИЕ: Первый пост (1 минута)

1. Открой Warpcast
2. Создай пост: "[App Name] is live! [URL]"
3. Индексация через ~10 минут

Скажи "запостил" — я проверю.
═══════════════════════════════════════════════════════════

ШАГ 5: ПОДАЧА НА FEATURED (опционально)

═══════════════════════════════════════════════════════════
ОПЦИОНАЛЬНО: Подать на Featured Placement

Форма:
https://docs.google.com/forms/d/e/1FAIpQLSeZiB3fmMS7oxBKrWsoaew2LFxGpktnAtPAmJaNZv5TOCXIZg/viewform

Что заполнить:
- URL: [production URL]
- Описание: [из manifest]
- Категория: [primaryCategory]

Скажи "подал" или "пропускаю".
═══════════════════════════════════════════════════════════

ШАГ 6: ФИНАЛЬНЫЙ ЧЕКЛИСТ

## Launch Checklist

### Контракты
- [ ] Deployed to Base Mainnet
- [ ] Verified on BaseScan
- [ ] Test transaction successful

### Frontend
- [ ] Touch targets >= 44px
- [ ] Portrait optimized
- [ ] Loads < 3 seconds

### Transactions
- [ ] Smart Wallet support (sendCalls)
- [ ] Builder Code suffix (ERC-8021)

### Manifest + SDK
- [ ] /.well-known/farcaster.json (miniapp key)
- [ ] Account Association signed
- [ ] sdk.actions.ready() in useEffect (NOT top-level)
- [ ] fc:miniapp + fc:frame meta tags
- [ ] base:app_id meta tag

### CORS + Security Headers
- [ ] .well-known has Access-Control-Allow-Origin: *
- [ ] CSP frame-ancestors includes base.dev
- [ ] No X-Frame-Options header (deprecated)

### Registration
- [ ] base.dev app created + URL verified
- [ ] base.dev preview: Ready (green), manifest loads
- [ ] URL posted in Farcaster feed
- [ ] Featured form submitted (optional)

Пройдись по чеклисту и пометь каждый пункт ✅/❌/⏳.

ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md

ОБЯЗАТЕЛЬНО: Допиши в PROJECT_BRIEF.md:

## 18. РЕГИСТРАЦИЯ И LAUNCH (Prompt 7)
Дата: [сегодня]

- base.dev: зарегистрирован ✅/❌
- base:app_id: [значение или "пропущено"]
- base.dev preview: Ready ✅/❌, Load time: [X]s
- CORS on .well-known: ✅/❌
- Индексация: ✅/❌ (каст с URL в ленте)
- Featured: подано/пропущено

Launch Checklist: [X из Y пунктов ✅]
Оставшиеся блокеры: [список или "нет"]

## СТАТУС: LAUNCHED ✅

Напиши "Приложение запущено как Base Mini App. PROJECT_BRIEF.md содержит полную историю запуска."

ЗАДАЧА: Полная верификация запущенного Base Mini App

Прочитай PROJECT_BRIEF.md — секция 17 (деплой), возьми production URL.

### КОНТЕКСТ

Приложение уже запущено. Этот промпт НЕ меняет код — только проверяет что ВСЁ работает.
Результат: таблица ✅/❌ по каждому требованию Base Mini App.

---

### ШАГ 1: АВТОМАТИЧЕСКИЙ SMOKE TEST

Подставь реальный домен из PROJECT_BRIEF.md:

```bash
DOMAIN="YOUR_PRODUCTION_DOMAIN"

echo "╔══════════════════════════════════════════╗"
echo "║ POST-LAUNCH VERIFICATION ║"
echo "║ $DOMAIN"
echo "╚══════════════════════════════════════════╝"

# ── HTTP ──
echo -e "\n── HTTP ──"
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" https://$DOMAIN)
[ "$HTTP_CODE" = "200" ] && echo "✅ HTTP $HTTP_CODE" || echo "❌ HTTP $HTTP_CODE"

# ── MANIFEST ──
echo -e "\n── Manifest ──"
curl -s https://$DOMAIN/.well-known/farcaster.json | python3 -c "
import json,sys
try:
d = json.load(sys.stdin)
except: print('❌ Invalid JSON'); sys.exit(1)
aa = d.get('accountAssociation',{})
mini = d.get('miniapp', {})
checks = [
('Manifest key = miniapp', 'miniapp' in d and 'frame' not in d),
('Account Association signed', aa.get('header','').startswith('ey')),
('name', bool(mini.get('name'))),
('subtitle', bool(mini.get('subtitle'))),
('tagline', bool(mini.get('tagline'))),
('description', bool(mini.get('description'))),
('homeUrl', bool(mini.get('homeUrl'))),
('iconUrl', bool(mini.get('iconUrl'))),
('splashImageUrl', bool(mini.get('splashImageUrl'))),
('heroImageUrl', bool(mini.get('heroImageUrl'))),
('ogImageUrl', bool(mini.get('ogImageUrl'))),
('primaryCategory', bool(mini.get('primaryCategory'))),
('tags (1-5)', 1 <= len(mini.get('tags',[])) <= 5),
('screenshotUrls', len(mini.get('screenshotUrls',[])) > 0),
('baseBuilder.ownerAddress', bool(d.get('baseBuilder',{}).get('ownerAddress'))),
]
for name, ok in checks:
print(f' {chr(9989) if ok else chr(10060)} {name}')
# Limits
n = mini.get('name',''); st = mini.get('subtitle','')
tl = mini.get('tagline',''); desc = mini.get('description','')
print(f'\n Limits:')
for label, val, mx in [('name',n,32),('subtitle',st,30),('tagline',tl,30),('description',desc,170)]:
ok = len(val) <= mx and len(val) > 0
print(f' {chr(9989) if ok else chr(10060)} {label}: {len(val)}/{mx} chars')
"

# ── ASSETS ──
echo -e "\n── Assets ──"
curl -s https://$DOMAIN/.well-known/farcaster.json | python3 -c "
import json,sys,subprocess
mini = json.load(sys.stdin).get('miniapp',{})
for key in ['iconUrl','splashImageUrl','heroImageUrl','ogImageUrl']:
url = mini.get(key)
if url:
code = subprocess.run(['curl','-s','-o','/dev/null','-w','%{http_code}',url],capture_output=True,text=True).stdout
print(f' {chr(9989) if code==\"200\" else chr(10060)} {key}: HTTP {code}')
else:
print(f' {chr(10060)} {key}: NOT SET')
"

# ── META TAGS ──
echo -e "\n── Meta Tags ──"
curl -s https://$DOMAIN | python3 -c "
import sys; html = sys.stdin.read()
tags = [
('fc:miniapp', 'fc:miniapp' in html),
('fc:frame', 'fc:frame' in html),
('og:title', 'og:title' in html),
('og:image', 'og:image' in html),
('og:description', 'og:description' in html),
('theme-color', 'theme-color' in html),
('viewport-fit=cover', 'viewport-fit=cover' in html),
('base:app_id', 'base:app_id' in html),
('apple-mobile-web-app-capable', 'apple-mobile-web-app-capable' in html),
]
for tag, ok in tags.items() if isinstance(tags, dict) else tags:
print(f' {chr(9989) if ok else chr(10060)} {tag}')
"

# ── HEALTH (если есть бэкенд) ──
echo -e "\n── Backend Health ──"
HEALTH=$(curl -s https://$DOMAIN/health 2>/dev/null)
if echo "$HEALTH" | python3 -c "import json,sys; d=json.load(sys.stdin); print('✅ Backend alive, uptime:', d.get('uptime','?'), 'sec')" 2>/dev/null; then
:
else
echo "⏭️ No /health endpoint (frontend-only deploy)"
fi
```

### ШАГ 2: ПРОВЕРКИ В КОДЕ

```bash
echo "── Code Checks ──"

# SDK
echo ""
grep -rn "sdk.actions.ready\|sdk\.actions\.ready" src/ --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" 2>/dev/null && echo " ✅ sdk.actions.ready()" || echo " ❌ sdk.actions.ready() NOT FOUND"

# Builder Code (ERC-8021)
echo ""
BUILDER=$(grep -rn "BUILDER_ADDRESS\|dataSuffix\|ERC-8021" src/ --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" 2>/dev/null | head -1)
[ -n "$BUILDER" ] && echo " ✅ Builder Code (ERC-8021)" || echo " ❌ Builder Code NOT FOUND"

# Smart Transaction wrapper
SMART=$(grep -rn "useSmartTransaction\|executeWithBuilder" src/ --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" 2>/dev/null | head -1)
[ -n "$SMART" ] && echo " ✅ Smart Transaction wrapper" || echo " ⚠️ No Smart Transaction wrapper (direct writeContract)"

# Direct writeContract outside wrapper (should be 0)
DIRECT=$(grep -rn "writeContractAsync\|useWriteContract\|useContractWrite" src/ --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" --exclude="*useSmartTransaction*" --exclude="*useSmart*" 2>/dev/null | grep -v "import" | wc -l | tr -d ' ')
[ "$DIRECT" = "0" ] && echo " ✅ No direct writeContract calls" || echo " ⚠️ $DIRECT direct writeContract calls found (should go through wrapper)"

# Theme
THEME=$(grep -rn "useTheme\|ThemeProvider\|prefers-color-scheme" src/ --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" 2>/dev/null | head -1)
[ -n "$THEME" ] && echo " ✅ Theme support (dark/light)" || echo " ❌ No theme support"

# Address display
ADDR=$(grep -rn "shortenAddress\|useBasename\|useEnsName\|formatAddress" src/ --include="*.js" --include="*.jsx" --include="*.ts" --include="*.tsx" 2>/dev/null | head -1)
[ -n "$ADDR" ] && echo " ✅ Address shortening/Basename" || echo " ⚠️ No address shortening found"

# CSP frame-ancestors (backend only)
CSP=$(grep -rn "frame-ancestors" server/ --include="*.ts" --include="*.js" 2>/dev/null | head -1)
[ -n "$CSP" ] && echo " ✅ CSP frame-ancestors" || echo " ⏭️ No CSP (frontend-only or check manually)"

# overscroll-behavior
OVERSCROLL=$(grep -rn "overscroll-behavior" src/ index.html --include="*.css" --include="*.html" --include="*.js" --include="*.jsx" 2>/dev/null | head -1)
[ -n "$OVERSCROLL" ] && echo " ✅ overscroll-behavior: none" || echo " ⚠️ No overscroll-behavior"

# Security: secrets in gitignore
echo -e "\n── Security ──"
for f in ".env" ".farcaster-signer.json" ".farcaster-app-signer.json"; do
if [ -f "$f" ]; then
if grep -q "$(echo $f | sed 's/\./\\\\./g')" .gitignore 2>/dev/null; then
echo " ✅ $f in .gitignore"
else
echo " ❌ $f EXISTS but NOT in .gitignore!"
fi
fi
done

# Build
echo -e "\n── Build ──"
npm run build 2>&1 | tail -1
```

### ШАГ 3: ВЕРДИКТ

Посчитай результаты и выведи саммари:

```
═══════════════════════════════════════════════════
POST-LAUNCH VERIFICATION COMPLETE

✅ Passed: X
❌ Failed: Y
⚠️ Warnings: Z

[Если Y > 0: список что починить]
[Если Y = 0: "All checks passed. App is fully compliant."]
═══════════════════════════════════════════════════
```

### ВЫВОД — СОХРАНИ В PROJECT_BRIEF.md (опционально)

Если хочешь зафиксировать результат:

```markdown
## 19. POST-LAUNCH VERIFICATION (Prompt 8)
Дата: [сегодня]

Результат: X/Y passed
Проблемы: [список или "нет"]
```

Напиши "Верификация завершена. [X из Y проверок пройдено]."