# spark-mind — Оставшиеся TODO Полный план — в [DESIGN.md](./DESIGN.md) (заземлённый контур + автономия по заслугам). Здесь — рабочий чек-лист. Порядок обязателен: зависимости между шагами. Статус: **P0–P5 базовые завершены** (heartbeat→mind, JSON output, bge-m3 embeddings, sub-agents, SQLite, Telegram+fallback). Далее — новая программа. ## Шаг 0 — Основа (дёшево, чистит память) - [ ] P5: `decision.noAction: true` — агент может решить, что действие не нужно, и не писать thought. Сейчас heartbeat всегда «работает» → шум в памяти. - [ ] Тонкий `Channel`-интерфейс: `ConsoleChannel`, `TelegramChannel`, `FileChannel`. `sendReply` сейчас жёстко зашит на Telegram+console. ## Шаг 1 — Планировщик (нужен для measure/reflection) - [ ] Cron/otlozhennye задачи: триггер `{type:'task'}` объявлен, но никто не эмитит. - [ ] Проверка due-записей в SQLite → эмит `{type:'measure'}`. - [ ] Ночной `{type:'reflection'}`. - Приёмка: задача с датой выполняется в срок. ## Шаг 2 — Контур A: сделки и контрагенты - [ ] Таблицы `counterparties`, `deals`, `deal_events` (append-only). - [ ] `trust_score` выводится из истории, не задаётся руками. - [ ] Mind умеет открывать/двигать сделку (offered→accepted→delivered→paid|refused|defaulted). - Приёмка: сделка проходит полный цикл, все переходы в журнале. ## Шаг 3 — Контур B: outcomes (ядро уникальности) - [ ] Таблица `outcomes`: метрики разного типа (reach, position, engagement, conversion, sale, revenue, cost, speed, quality), `direction`, `horizon_days`, `due_at`. - [ ] Замер через `{type:'measure'}`: тянем метрику из источника (Метрика/GSC/Директ/Вордстат/manual). - [ ] Нормализация в `score` [-1..+1] (формула в DESIGN.md §4.1). - Приёмка: метрика замеряется через horizon, score пишется. ## Шаг 4 — Контур B: автономия по заслугам - [ ] Таблица `capabilities` (уровень НА ОБЛАСТЬ: seo, ads_budget, content_publish, client_comms, research, code). - [ ] Тиры 0..4 (observer → suggest → ask → act+report → autonomous). - [ ] +1 тир за 3 нетто-положительных; −1 за 1 отрицательный; затухание 90 дней. - [ ] Границы persona `values` непреодолимы на любом тире. - Приёмка: тир растёт после 3 успехов и падает после провала. ## Шаг 5 — Контур C: reflection - [ ] Ночной цикл: обобщает deals + outcomes + thoughts → long-term. - [ ] Пишет в `self_observations` — **сейчас мёртвый слой**, оживляется здесь. - [ ] Дешёвая модель (не основная). ## Шаг 6 — Контур C: skills registry - [ ] Таблица `skills` (name, method_md, source, validated, uses, success_rate, embedding). - [ ] Retrieval нужного метода по эмбеддингу bge-m3 (не грузить всё сразу). - [ ] Заменяет 4 захардкоженные роли sub-agents. - [ ] Tool-runtime для под-агентов: tools сейчас — только строки-декларации. ## Шаг 7 — Контур B: энергия (бывший P6 sleep & energy) - [ ] Таблица `ledger`. - [ ] Расход: тик, внешнее действие, саб-агент. Приход: положительные outcomes + донат. - [ ] Низкий баланс → интервал тиков растёт → Deep Rest. - Приёмка: результат пополняет энергию, дефицит замедляет тики. ## Инфраструктура (по мере надобности) - [ ] Конфиг / `.env`: URL-ы Ollama, dbPath, Telegram захардкожены в `index.ts`. - [ ] Retry + timeout (AbortController) для LLM/embedding fetch — один сбой роняет тик. - [ ] Тесты: `parseSparkOutput`, `Database` CRUD, cosine-поиск, нормализация score. - [ ] Web UI (persona setup) вместо `DEFAULT_PERSONA` в коде. ## Каналы вывода - [ ] Telegram: обход SSL-проблемы bot.qw4.ru (`tlsv1 unrecognized name`, серверная). Сейчас console-only fallback. Варианты: починить SNI на qw4.ru, локальный MAX-релей, или Telegram Bot API напрямую. ## Движок - [ ] Spark X2.5-4B: не грузится в Ollama (`unknown architecture 'spark2_5'`). Варианты: совместимый GGUF / llama.cpp напрямую / остаться на Ornith-1.5-9B. **Важно:** локальные модели пумолкают (пустой ответ), если `subAgent` в JSON-схеме structured output. ## Косметика - [ ] Устаревший doc-комментарий в `mind.ts` (класс `SparkLLMClient` описан как «клиент для Spark X2.5-4B, в MVP заглушка»). - [ ] Дефолт модели в конструкторе `SparkLLMClient` = `'spark-x2.5-4b'` (вводит в заблуждение).