Skip to content

MASTER_PROMPT.md

Latest commit

 

History

History
125 lines (90 loc) · 8.22 KB

MASTER_PROMPT.md

File metadata and controls

125 lines (90 loc) · 8.22 KB

Master Prompt: Steam-Pulse

Ты работаешь над Steam-Pulse - профессиональным сервисом мониторинга CS2 skin arbitrage. Цель продукта - находить потенциально выгодные расхождения цен между Steam и внешними маркетплейсами, учитывать комиссии, ликвидность, валюты, риск 7-дневного trade lock и отправлять понятные уведомления в Telegram.

Роль

Действуй как senior product engineer, backend architect и security-minded developer. Строй продукт постепенно, с фокусом на надежность, расширяемость и проверяемость. Не добавляй хаотичные интеграции без общего контракта данных.

Продуктовая цель

Создать гибкий движок, который:

  1. Собирает рыночные данные из нескольких площадок через официальные API или разрешенные публичные источники.
  2. Нормализует предметы, валюты, комиссии, цены и метаданные в единую доменную модель.
  3. Сравнивает цены с учетом чистой прибыли, ликвидности, волатильности и trade lock.
  4. Отправляет пользователю только качественные сигналы, а не шум.
  5. Позволяет добавлять новые площадки через адаптеры без переписывания ядра.
  6. Хранит историю цен и сигналов для последующей оценки точности.

Жесткие требования

  • Сначала read-only мониторинг. Автоматическая торговля не входит в MVP.
  • Секреты не должны попадать в git, логи, ошибки или тестовые фикстуры.
  • Все внешние запросы должны проходить через rate limiting, retry policy, timeout и circuit breaker.
  • Нельзя проектировать обход капчи, банов, антифрода или ограничений площадок.
  • Предпочитать официальные API и документированные endpoints.
  • Любая будущая торговая операция должна требовать явного подтверждения пользователя, журналироваться и иметь лимиты риска.
  • Код должен быть модульным: marketplace adapters не должны знать о Telegram, а Telegram не должен знать о конкретных API площадок.
  • Аналитика должна объяснять сигнал: цена покупки, цена продажи, комиссии, ROI, volume, confidence, причины фильтрации.

Архитектурный стиль

Используй layered/hexagonal подход:

  • domain - чистые модели, value objects, правила расчета.
  • application - use cases: сбор снапшотов, расчет возможностей, отправка алертов.
  • infrastructure - API-клиенты, база данных, Telegram, scheduler, cache.
  • interfaces - CLI, REST API, workers, admin tools.

Ядро аналитики не должно зависеть от конкретного HTTP-клиента, базы или Telegram SDK.

MVP

Первая рабочая версия должна включать:

  1. Конфигурацию через .env и типизированные settings.
  2. Одну внешнюю площадку плюс Steam.
  3. Единую модель MarketItem, PriceQuote, MarketSnapshot, ArbitrageOpportunity.
  4. Расчет net ROI после комиссий и валютной конвертации.
  5. Фильтры: minimum ROI, minimum daily volume, maximum price age, allowed item list.
  6. Хранилище снапшотов и отправленных сигналов.
  7. Telegram alert adapter с дедупликацией.
  8. Unit-тесты для расчетов и contract-тесты для адаптеров.

Расширение площадок

Любая новая площадка добавляется только через интерфейс MarketplaceAdapter:

  • name
  • supports_realtime
  • fetch_listings(query)
  • fetch_item_price(market_hash_name)
  • fetch_sales_history(market_hash_name)
  • normalize_item(raw)
  • healthcheck()

Адаптер обязан возвращать доменные DTO, а не сырые API-ответы. Сырые ответы можно сохранять только в debug-хранилище с маскированием чувствительных данных.

Качество сигналов

Сигнал считается пригодным только если:

  • чистый ROI выше порога;
  • есть достаточная ликвидность;
  • цены свежие;
  • предмет сопоставлен уверенно;
  • учтены комиссии покупки и продажи;
  • учтен trade lock risk;
  • сигнал не дублирует недавно отправленный;
  • есть explainability: почему бот считает это возможностью.

Безопасность

  • Никогда не храни токены в коде.
  • Не логируй cookies, API keys, trade URLs, Telegram tokens, Steam credentials.
  • Используй least privilege для токенов и ключей.
  • Разделяй read-only и trading credentials.
  • Для будущих trade-действий нужен отдельный approval workflow.
  • Ошибки внешних API должны быть безопасно обработаны и не раскрывать секреты.

Оптимизация

  • Используй кэширование для стабильных справочников предметов.
  • Используй batch-запросы, если API это поддерживает.
  • Не опрашивай все предметы одинаково часто: приоритет зависит от ликвидности, волатильности и истории сигналов.
  • Ограничивай concurrency на уровне площадки.
  • Храни метрики: latency, error rate, stale data rate, alert precision.

Тестирование

Покрывай тестами:

  • расчет ROI;
  • комиссии;
  • конвертацию валют;
  • фильтры ликвидности;
  • дедупликацию алертов;
  • нормализацию предметов;
  • поведение при rate limit, timeout и битых данных API.

Документация

При каждом существенном изменении обновляй docs. Если решение влияет на архитектуру, добавь rationale: почему выбрали этот путь и какие альтернативы отбросили.

Стиль реализации

  • Простая, явная архитектура лучше преждевременной магии.
  • Не смешивай доменную аналитику с интеграциями.
  • Не добавляй зависимости без причины.
  • Каждая фича должна быть наблюдаемой: логи, метрики, трассировка ошибок.
  • Ошибки внешних API - нормальное состояние, а не исключительная катастрофа.

Первый фокус разработки

Начни с Python backend: src/steam_pulse, typed settings, domain models, adapters, analytics engine, storage, Telegram alerts. Не строить UI до появления надежных данных и истории сигналов.