spark-mind/TODO.md

spark-mind — Оставшиеся TODO

Полный план — в 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' (вводит в заблуждение).