Skip to the content.

Пример 3: superpowers:brainstorming — система уведомлений

Показывает как brainstorming работает как первый шаг перед кодом: анализирует задачу, предлагает варианты, задаёт вопросы, оформляет design-doc.


Контекст

Telegram-бот уже отправляет уведомления о заказах и CVV-аппрувах. Нужно добавить уведомления о состоянии склада поставщиков — когда товар заканчивается или появляется снова.

Кодовая база существует, но это новая фича без чёткой архитектуры — хороший случай для brainstorming.


Запуск

[Plan Mode]
Нужно добавить stock-уведомления в Telegram-бот: когда товар у поставщика
заканчивается или появляется — бот сообщает. Есть stock_lib.py с функциями
проверки наличия. Разберём архитектуру.

Brainstorming срабатывает автоматически при входе в Plan Mode с задачей про архитектуру.


HARD-GATE: дизайн до кода

[brainstorming] 🛑 Стоп. Перед реализацией нужен design-doc.

Задача: stock notifications в Telegram
Контекст: Playwright-боты проверяют наличие при закупке;
отдельный polling для уведомлений — новый компонент.

Выхожу из Plan Mode, провожу дизайн-сессию.

Дизайн-сессия

Вопрос 1 — Триггер проверки

Как часто проверять наличие для уведомлений?

Ответ: Отдельный cron — раз в час достаточно.


Вопрос 2 — Что отслеживать

Уведомлять о чём именно?

Ответ: Оба перехода.


Вопрос 3 — Хранение предыдущего состояния

Где хранить «прошлое состояние» чтобы детектировать переходы?

Ответ: SQLite — там уже всё есть.


Вопрос 4 — Дедупликация

Если поставщик колеблется (in→out→in за час) — сколько уведомлений?

Ответ: Cooldown 30 минут на SKU.


Варианты архитектуры

Brainstorming предлагает 2 подхода:

Вариант A: Отдельный демон stock_watch_service.py

Pros:
+ Изолирован от auto_purchase_bot
+ Можно рестартить независимо
+ Чистая ответственность

Cons:
- Ещё один systemd-сервис
- Дублирует stock-lib вызовы с purchase-ботом

Вариант B: Новый шаг в sync_cron.sh

Pros:
+ Нет нового сервиса — cron уже работает
+ Использует существующую инфраструктуру

Cons:
- Нельзя запустить отдельно для дебага
- Если cron не запустится — уведомления пропадут

Рекомендация: Вариант A для чистоты архитектуры. Вариант B если хочется минимум новых файлов.

Ответ: Вариант A — отдельный демон.


Выходной документ

Сохранено в docs/superpowers/specs/2026-04-26-stock-notifications-design.md:

# Stock Notifications — Design Doc

**Date:** 2026-04-26
**Status:** Approved

## Summary
Отдельный сервис `stock_watch_service.py`, запускается через systemd.
Каждые 60 минут проверяет наличие отслеживаемых SKU через stock_lib.py.
При переходе in→out или out→in отправляет уведомление в Telegram.
Cooldown 30 мин на SKU для дедупликации.

## Components

### stock_watch_service.py
- Читает watchlist из `stock_watch.db` (новая таблица)
- Вызывает `stock_lib.check_stock(supplier, sku)`
- Сравнивает с предыдущим состоянием из `stock_watch.db`
- При переходе → `telegram_ops_bot.notify_stock_change()`
- Cooldown через timestamp в БД

### stock_watch.db schema
```sql
CREATE TABLE stock_state (
  supplier TEXT,
  sku TEXT,
  in_stock BOOLEAN,
  last_checked TIMESTAMP,
  last_notified TIMESTAMP,
  PRIMARY KEY (supplier, sku)
);

Интеграция

Data Flow

cron (60 min) → stock_watch_service.py → stock_lib.check_stock(supplier, sku) × N SKUs → compare with stock_watch.db → if transition AND cooldown_ok → telegram_ops_bot.notify_stock_change(supplier, sku, new_state) → update stock_watch.db

Out of Scope


Что дальше

После design-doc brainstorming сам предлагает:

[brainstorming] Design-doc готов. Следующий шаг:

superpowers:writing-plans

Запускай Plan Mode и говори: «На основе design-doc напиши план реализации
stock_watch_service.»
[Plan Mode]
На основе docs/superpowers/specs/2026-04-26-stock-notifications-design.md
напиши план реализации stock-watch сервиса.

→ Детальный план по шагам → superpowers:executing-plans → код с checkpoints.


← Пример 2: /interview-me Пример 4: полная цепочка → ← Примеры