Рубка

Оболочка над Windows с глубокой интеграцией ИИ. Одно окно = один контур с живой сессией Agent SDK, которая не пересоздаётся. Диалог, задачи, документы, браузер с авторизациями, почта, кроны и таймеры, виджеты, диктовка. Постановка задач из Телеграма и MAX. Цель владельца: пользоваться компьютером только через оболочку. Делается для себя, при успехе выкладывается открытым кодом: оболочка наша, всё остальное (подписка, ключи, ssh, профиль браузера, память, скиллы) приносит пользователь.

server: Локальная машина владельца, Windows 11 Pro. Серверов не требует.память: ai-shell-windows-project

готовS1 · С1 · Макет и решения5/5

Цель: Согласовать вид и ключевые развилки ДО кода. Гейт: владелец сказал да на макет.

↑ Макет главного окна: лента задач вместо ленты чата

Владелец: визуально надо как-то по-другому обыграть, не как чат. Гипотеза к показу: карточки задач (в работе / ждёт подтверждения / готово), каждая разворачивается в шаги, разговор внутри карточки. Слева корешки контуров с индикатором: жив, остаток лимита, сколько в очереди. Внизу одна строка ввода всегда. Показать 2-3 варианта, дождаться да. | СДЕЛАНО 01.09: Собраны и показаны три варианта: А лента карточек-задач с корешками контуров, Б пульт из плиток с вызовом диалога горячей клавишей, В разделённый экран ход работы плюс результат. Страница: https://myvisionagency.ru/lab/rubka-maket/ Ждёт выбора владельца, можно гибрид. | 01.09: ВЫБОР ВЛАДЕЛЬЦА 01.09: гибрид А+Б. Дом это дашборд виджетов, виджет раскрывается по нажатию. Из контура проваливаешься в сессию с задачами, историей и общением. Собран живой прототип: https://myvisionagency.ru/lab/rubka-vid/ Ждёт да. | ПРАВКА ВЛАДЕЛЬЦА 01.09: в макете не хватало САМОГО разговора. Первая версия сессии была лентой сухих шагов, из неё выпало то, ради чего всё затевается. Переделано: Разговор это главный экран сессии (вкладка по умолчанию), задачи и история вспомогательные. Четыре вида сообщений от ассистента: короткое подтверждение в начале, промежуточный отчёт сделал то-то, вопрос с готовыми вариантами посреди работы, выделенный итог в конце с цифрами и предложением. Шаги сворачиваются в одну строку и разворачиваются по клику.

✓ Владелец сказал да. Гибрид: дом с виджетами, внутри контура разговор как главный экран. Прототип: myvisionagency.ru/lab/rubka-vid/

feature

↑ Макет виджетов и превью правки документа

Виджеты: остаток лимита (данные готовы, см. задачу про rate_limit_event), очередь задач, последние действия, заметки. Отдельно overlay-окно с превью правки слева на пол-экрана по высоте с анимацией, как просил владелец. Красота критична, это одна из причин затеи. | СДЕЛАНО 01.09: На той же странице: полка из четырёх виджетов на уже проверенных данных (остаток лимита, очередь, лента действий, серверы) и живая анимация overlay-панели с превью правки слева на пол-экрана. Ждёт реакции владельца. | 01.09: Виджеты на доме реально раскрываются в прототипе: остаток (расход по часам, разбивка по контурам, оба окна), задачи (полный список), серверы, лента действий. Overlay-превью правки остаётся из первого макета. Ждёт да. https://myvisionagency.ru/lab/rubka-vid/

✓ Владелец сказал да, но состав виджетов не фиксируем: это живая вещь, будем тестировать. Заведена отдельная задача на механику добавления и удаления.

feature

Решить: Electron или Tauri

Ядро на Node обязательно, Agent SDK живёт там. Electron = один язык, меньше рисков сборки на Windows, память при 32 ГБ не проблема. Tauri = меньше памяти и размер дистрибутива, важно только при раздаче людям, цена третий язык (Rust). Рекомендация Клода: Electron, UI держать отдельным слоем для возможного переезда. Ждёт решения владельца. | 01.09: Electron. Владелец дважды пропустил вопрос, взято по рекомендации: ядро всё равно на Node, Electron это на один язык меньше и меньше рисков сборки на Windows, память при 32 ГБ не проблема. Вид держим отдельным слоем, переезд на Tauri возможен, если дойдёт до раздачи людям.

✓ Electron, вид отдельным слоем для возможного переезда.

feature

🔴 Схема контекста: окно = контур, сессия живёт

Наказ владельца: как в VS Code. Окно открыто, сессия поднята один раз и не пересоздаётся. Новое окно = новый контур = новая загрузка. Причина не только удобство: замерено 01.09.2026, старт сессии стоит 31.7к токенов без ~/.claude и 44.5к с ним. Сессия на задачу сожжёт пятичасовое окно к обеду. Доложить: автосжатие длинной сессии плюс кнопка чистый лист в контуре с сохранением памяти, в SDK есть forkSession. | 01.09: Решено: два уровня. Дом это обзор, контекст там лёгкий. Сессия на контур держит живой контекст и не пересоздаётся, как окно в VS Code. Переход дом-сессия контекст не роняет. Открытых контуров держим три-четыре, потому что каждый стоит 31-44к токенов на подъём.

✓ Два уровня: дом обзорный, сессия с живым контекстом на контур.

feature

↓ Имя проекта и репозиторий

Рабочее имя Рубка взято Клодом, владелец его не утверждал. Переименовать это одна команда. Решить финальное имя и завести репозиторий.

✓ Имя Рубка принято по умолчанию, владелец вопрос не оспорил дважды. Репозиторий заводится в С2.

feature

готовS2 · С2 · Каркас: ядро, окно, слой прав6/6

Цель: Работающий скелет: живая сессия, стрим шагов, гейт безопасности, конфиг отдельно от кода.

🔴 Ядро-служба на Node с живой сессией Agent SDK

Проверено 01.09.2026: @anthropic-ai/claude-agent-sdk 0.3.252 работает на подписке, apiKeySource none, ни одной переменной с ключом не задано. ssh cfru uptime из-под SDK отработал вживую. Служба держит сессию, стримит сообщения, переживает закрытие окна (фон это С3, но архитектуру закладывать сразу).

✓ Служба на Node держит живую сессию через потоковый ввод, реплики подаются в бесконечный генератор. Доказано сквозной проверкой: два хода в одной сессии, на втором из кэша 83674 токена против 4 свежих, контекст переиспользован, а не собран заново. Источник ключа none, то есть подписка.

feature

🔴 Слой прав на PreToolUse-хуке, НЕ на canUseTool

ЛОВУШКА, поймана на замере 01.09.2026: canUseTool молча обходится. Голое имя в allowedTools авто-одобряет инструмент раньше колбэка, и allow-правила из settings-файлов тоже обходят колбэк. Значит settingSources user плюс личный settings.json продырявят гейт оболочки. Строить на PreToolUse-хуке. Приёмка: попросить rm -rf и убедиться, что остановлено.

✓ core/src/gate.mjs на хуке PreToolUse. 14 модульных проверок зелёные плюс сквозная на живой модели. Гейт останавливает rm -rf ПРИ подтянутых настройках пользователя (36 навыков), разбирает команду внутри ssh (вердикт ask, где=внутри ssh), катастрофу не пропускает даже с согласием, ослабить встроенные правила через конфиг нельзя, некому спросить означает отказ.

feature

↑ Окно: диалог, стрим шагов, приём файлов

Первая рабочая версия интерфейса по согласованному макету. Кидание файлов, текста, скриншотов.

✓ Electron 44. Дом это сетка раскрываемых виджетов, внутри контура главный экран разговор: ассистент отвечает словами, шаги свёрнуты в строку и разворачиваются, вопрос гейта приходит карточкой в поток. Композер растёт, плюсик и переключатели работают. Виджеты описаны списком объектов, добавить или убрать это правка списка. Приём файлов пока только пункт меню плюсика, настоящее вложение отдельной задачей. Проверено снимками живого окна.

feature

↑ Конфиг пользователя отдельно от кода

Правило проекта: личное (ssh-алиасы, пути, домены, токены ботов, профиль браузера) только в конфиге, никогда в исходнике. Соблюдать с первого дня, иначе публикация превращается в переписывание.

✓ core/src/config.mjs: %APPDATA%/rubka/config.json либо RUBKA_CONFIG. Проверено: без файла служба поднимается на встроенных значениях и гейт живой; поиск по репозиторию не находит ни адреса сервера, ни ssh-алиаса, ни личного пути (ссылки на домен из README убраны специально ради этого).

feature

Подтягивание окружения пользователя через settingSources

Проверено: settingSources user подтягивает ~/.claude, видно 37 скиллов владельца (avito-work, deploy-cfru, service-down), 67 инструментов, 70 команд, 6 агентов. Взвесить с задачей про слой прав: allow-правила оттуда обходят гейт, тянуть выборочно.

✓ settingSources:[user] подтягивает 36 навыков и правила пользователя, и при этом гейт не дырявится, потому что живёт на хуке. Побочная находка: с подтянутым CLAUDE.md модель сама отказывается от rm -rf раньше гейта, поэтому проверку самого гейта пришлось изолировать в отдельную сессию без настроек пользователя.

feature

Приёмка С2

1) Сказал покажи uptime cfru и видишь шаги и ответ. 2) Попросил rm -rf, гейт остановил и спросил. 3) Снёс конфиг, код не сломался. | 01.09: три пункта из четырёх закрыты доказательством (ssh проходит, rm -rf останавливается, конфиг снимается без поломки). Остаётся окно: его ещё нет.

✓ Закрыта доказательством. Ядро: 14 модульных и 8 сквозных проверок зелёные, подписка (ключ none), 36 навыков, второй ход берёт 83674 токена из кэша против 4 свежих. Гейт: останавливает rm -rf при подтянутых настройках пользователя, разбирает команду внутри ssh, ослабить встроенное конфигом нельзя. Личное: поиск по репозиторию не находит ни адреса сервера, ни ssh-алиаса; служба поднимается без конфига. Окно: снимки живого окна показали дом с раскрытием виджета, сессию с разговором и вопрос гейта прямо в потоке с ожиданием ответа. По ходу поймано и исправлено 4 дефекта вида: заголовки виджетов на разной высоте (button центрует содержимое), внутренняя кухня в интерфейсе (ключ none и счётчики токенов), приписки переключателей внутри реплики пользователя.

feature

В РАБОТЕS3 · С3 · Долгая жизнь: фон, контуры, планировщик3/6

Цель: Задачи переживают закрытие окна. Кроны, таймеры, автозапуск. Контуры со своими сессиями.

🔴 Фоновая служба: задачи переживают закрытие окна

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

✓ Ядро вынесено в отдельный процесс, окно находит его по адресу в папке состояния. Разговор по http на петле: события потоком, действия запросом, ключ обязателен (без него 401). Доказано проверкой core/test/service.test.mjs: окно отключилось посреди задачи, служба доделала её без единого подключённого слушателя, вернувшееся окно увидело и ответ, и итог. Журнал и расписания переживают перезапуск службы, сессии возобновляются через resume. ОСТАЁТСЯ РУЧНАЯ ПРОВЕРКА: что служба переживает закрытие самого окна на живом рабочем столе. В песочнице разработки это не проверить, она гасит всё дерево процессов разом.

feature

↑ Контуры: сессия на проект, переключение, автосжатие

У владельца порядка двадцати проектов. Корешки контуров, у каждого своя живая сессия. Длинная сессия за день распухнет, заложить автосжатие и forkSession. | 01.09: СДЕЛАНО: служба держит несколько контуров, восстанавливает их после перезапуска через resume, событие сжатия приходит в поток и человек видит человеческую фразу вместо цифр. НЕ СДЕЛАНО: переключение контуров горячей клавишей и заведение контура из интерфейса, сейчас список берётся из конфига.

feature

↑ Планировщик: кроны, таймеры, автозапуск при входе

Одна из причин затеи по словам владельца. Приёмка: ночной крон отработал сам. | 01.09: СДЕЛАНО: планировщик в службе, свой разбор крона на пять полей без зависимостей, разовые таймеры, вкладка Расписания в интерфейсе где человек задаёт время и повтор словами, а не кроном. Кривое расписание отвергается сразу с объяснением. 9 проверок зелёные. НЕ СДЕЛАНО: автозапуск при входе в систему. Это правка автозагрузки машины, делать без спроса не стал.

feature

История и поиск по сессиям

Проверено: listSessions() отдаёт 50 сессий с полями sessionId, summary, customTitle, firstPrompt, cwd, tag, createdAt, lastModified. Основа для копаться по общениям почти готова из коробки, нужен интерфейс. | 01.09: СДЕЛАНО: вкладка История показывает действия текущей сессии, журнал службы переживает перезапуск и подгружается в окно при подключении. НЕ СДЕЛАНО: сквозной поиск по прошлым сессиям через listSessions, это отдельная задача.

feature

↑ Механика виджетов: добавить, убрать, переставить

НАКАЗ ВЛАДЕЛЬЦА 01.09: состав виджетов не фиксируем, это живая вещь, а не статичная. Нужна механика: добавить виджет из списка доступных, убрать, переставить перетаскиванием, раскладка сохраняется. Сам набор будем подбирать опытом. Стартовые четыре из макета (остаток, задачи, серверы, что я делал) это не финальный список, а первые кандидаты.

✓ Виджеты описаны списком объектов. У раскрытого есть кнопка убрать, внизу сетки плитка добавить виджет со списком свободных, перетаскивание перестраивает порядок. Раскладка запоминается на этой машине. Проверено снимками: кнопка убрать и плитка добавить видны. Перетаскивание снимком не проверяется, нужна проверка руками.

feature

Виджет остатка лимита

Проверено: в потоке приходит rate_limit_event с живыми данными, five_hour и seven_day utilization плюс resetsAt. На замере было 31 процент и 16 процентов. Данные готовые, собрать виджет.

✓ Сделан ещё в С2 и работает на живых данных из rate_limit_event: кольцо с долей за пять часов, в раскрытом виде оба окна с полосками и время сброса.

feature

готовS4 · С4 · Входы: Телеграм и MAX3/3

Цель: Поставить задачу с телефона и получить отчёт. Тот же гейт и журнал, что в окне.

↑ Телеграм-бот: постановка задачи в очередь ядра

Владелец: ставить задачи через бота и получать отчёт по ним. Телеграм без ограничений и уже подключён. Тот же слой прав и тот же журнал, что в окне.

✓ core/src/bots.mjs, бот живёт в СЛУЖБЕ, а не в окне: с телефона пишут как раз тогда, когда окно закрыто. Длинный опрос getUpdates, поэтому белого адреса и вебхука не нужно. Белый список обязателен: пустой означает, что задачи не принимаются ни от кого, чужому бот не отвечает вообще ничем. Гейт тот же самый: вопрос про необратимое уходит кнопками и показывает саму команду, работа ждёт ответа, чужое нажатие ничего не разрешает. Проверено: api.telegram.org достаётся с машины напрямую (401 на подставной токен), прокси не нужен, подмена основы в конфиге предусмотрена.

feature

Бот MAX

Владелец подтвердил: юрлицо есть, боты в MAX уже есть, ограничение только юрлица с августа 2025 не мешает. REST platform-api2.max.ru (для ботов рекомендован именно он, не platform-api), лимит 30 запросов в секунду, SDK на JS/Go/Java/PHP, токен с dev.max.ru.

✓ Тот же класс, своя механика площадки: основа platform-api2.max.ru (для ботов рекомендован именно он), токен в заголовке Authorization без Bearer, через параметр запроса MAX его больше не принимает. Длинный опрос GET /updates с маркером, кнопки вложением inline_keyboard, ответ на нажатие через POST /answers. Проверено, что площадка достаётся с машины напрямую (429 без токена). Живого бота заводит владелец.

feature

↑ Отчёт о задаче обратно в бота

Что сделано, что заблокировано гейтом, ссылка на карточку задачи в окне.

✓ Отчёт привязан к тому, кто поставил задачу: слова ассистента и итог уходят только в его чат и только по его контуру, события чужого контура в чат не текут, после итога отчёты прекращаются. Длинный ответ обрезается, а не валит отправку. 12 проверок с подменённым выходом наружу, в сеть не ходят.

feature

готовS5 · С5 · Десктоп-руки: Office, превью, браузер, почта3/4

Цель: Правка документа с превью и подтверждением. Браузер на живом профиле.

↑ Office через COM: найти документ и внести правку

Проверено вживую 01.09.2026: Word 16.0 сборка 16.0.20326, COM отработал, открыл документ, сделал замену в тексте, закрыл. Excel, PowerPoint, Outlook зарегистрированы в реестре. Правку делать через объектную модель или прямо файл (python-docx, openpyxl), НЕ кликами по интерфейсу.

✓ Сессия получила свои инструменты: find_document, read_document, preview_edit, apply_edit. Показ и запись разделены, между ними человек. Перед записью всегда копия прежней версии в папку рядом. Мост на PowerShell, правка через объектную модель Word. 12 проверок на настоящем документе без участия модели: создание, чтение, поиск куска, замена, сверка что в копии остался прежний текст, понятные отказы. Отдельно проверено живым прогоном, что ассистент действительно зовёт эти инструменты. Запись проходит через гейт и спрашивает.

feature

↑ Overlay-окно с превью правки и анимацией

Просьба владельца дословно: правка слева на пол-экрана по высоте, красивая анимация как в маках. WebView2 151.0.4129.107 на машине есть.

✓ Отдельное окно без рамки, прозрачное, поверх всего, слева на половину экрана, выезжает и уезжает. Показывается без кражи фокуса: человек мог печатать в другом окне. Проверено снимком живого окна на настоящем договоре: видно имя документа, пояснение от ассистента, было красным и стало бирюзовым, и сноска что на диске пока ничего не изменилось. Кнопки на вопрос гейта в коде есть, снимком не проверены.

feature

↑ Браузер на существующем профиле с авторизациями

НЕ строить с нуля: у владельца уже есть ~/.claude/playwright-auth-profile на 166 МБ и playwright-auth.json на 65 КБ с живыми сессиями Авито, Яндекс Директа, ВК, mail.ru, МТС. Живой Chrome подключать нельзя, профиль залочен. Заложить белый список доменов и подтверждение необратимого.

✓ СВОЕГО МОСТА НЕ СТРОИМ. Проверено: у владельца уже подключён Playwright MCP, сессия получает 23 браузерных инструмента вместе с его настройками. Находка по профилю: запуск идёт с ключами --isolated --storage-state playwright-auth.json, то есть снимок кук подхватывается, но НОВЫЕ входы обратно не сохраняются, а постоянный профиль на 166 МБ не используется вовсе. Нужен выбор владельца: переводить ли Рубку на постоянный профиль (тогда входы живут, но профиль занят одним окном за раз).

feature

Почта: разобраться с Outlook COM или уйти в IMAP

ОТКРЫТЫЙ ВОПРОС. На замере 01.09.2026 Outlook COM упал с 80080005 CO_E_SERVER_EXEC_FAILURE, похоже на несовпадение уровня прав, сессия шла с повышенными. Проверить в обычном режиме, если не лечится то IMAP/SMTP или Graph API. Через браузер почту НЕ делать, ломается на каждом редизайне. | 02.09 ДОПРОВЕРЕНО: Outlook COM падает с 80080005 дважды, при этом Word через COM работает. Права ни при чём: процесс не с правами администратора, Outlook установлен (найден OUTLOOK.EXE в Office16), почтовый профиль заведён, Outlook в момент проверки не запущен. Похоже, COM-сервер Outlook просто не стартует из фонового процесса. ДВА ПУТИ, нужен выбор владельца: (1) работать с почтой только когда Outlook уже открыт, тогда COM цепляется к живому экземпляру и реквизиты не нужны; (2) IMAP и SMTP с реквизитами в конфиге, надёжнее и работает без Outlook, но нужен пароль приложения. Через браузер почту НЕ делаем. | 02.09 ОТВЕТ ВЛАДЕЛЬЦА: настольный Outlook ему не нужен и не настроен, на работе он пользуется ОБЛАЧНЫМ Outlook, плюс подписка на Office кончилась два месяца назад и Word руками уже не правит документы. Значит путь через Outlook COM закрыт окончательно. Остаются два: IMAP и SMTP с паролем приложения в настройках, либо Microsoft Graph с согласием на рабочую учётку. Нужен выбор владельца и его реквизиты, вслепую не делаем.

✓ ОТЛОЖЕНО ВЛАДЕЛЬЦЕМ 03.09: почту не трогай, потом решим что с ней делать. Что известно на момент отката: настольный Outlook не настроен и не нужен, работает он в облачном, подписка на Office кончилась. Outlook COM из фонового процесса не поднимается (80080005 дважды). Останутся два пути, когда вернёмся: IMAP и SMTP с паролем приложения либо Microsoft Graph с согласием на рабочую учётку.

⛔ Решение владельца 03.09: почту не трогаем, вернёмся позже

feature

В РАБОТЕS6 · С6 · Джарвис: виджеты, поиск, диктовка3/5

Цель: Рабочий день без запуска приложений руками.

Виджеты: очередь, действия, заметки, рисование

Владелец: виджет нарисовать что-то. Настраиваемый набор виджетов. | 02.09: СДЕЛАНО пять виджетов на живых данных (остаток, задачи, расписания, сессия, что я делал) плюс механика добавить, убрать, перетащить. НЕ СДЕЛАНО: заметки и рисование.

feature

↑ Сквозной поиск: сессии, логи, скрины, действия

Формат Джарвиса по словам владельца: легко копаться по памяти, общениям, скринам, логам, действиям.

✓ Ищет в трёх местах сразу: журнал службы, заголовки прошлых разговоров, внутри разговоров. Показывает кто говорил, когда и в каком разговоре, с куском вокруг находки. Ради скорости сначала дешёвые заголовки, вглубь только к последним по времени, список разговоров кэшируется на минуту. Проверено снимком на живых данных: по слову директ 11 находок внутри прошлых разговоров, запрос около трёх секунд на 69 разговорах.

feature

Диктовка голосом

НЕ Whisper: ломает лицо глагола на русском, доработаю превращается в доработают, владелец это уже ловил, память asr-whisper-vs-scribe-russian. Брать связку со встреч AITODO: GigaAM локально плюс Scribe кнопкой, память aitodo-meetings-asr-stack. Железо машины: RTX 3050 4 ГБ, 32 ГБ ОЗУ. | 02.09 ЗАМЕРЕНО НА МАШИНЕ: python 3.11 есть, vosk установлен, НО модель к нему не скачана. torch для GigaAM нет. Ключа ElevenLabs в окружении нет. Микрофоны в системе есть (Realtek, NVIDIA Broadcast). ТРИ ПУТИ, нужен выбор: (1) vosk — офлайн, бесплатно, скачать модель 45 МБ или 1.8 ГБ, качество среднее; (2) Scribe от ElevenLabs — качество владелец уже проверил на встречах, платно по минутам, нужен ключ; (3) GigaAM локально — качество и офлайн, но тянет torch и модель на гигабайты, на RTX 3050 с 4 ГБ пойдёт. Whisper исключён: ломает лицо глагола на русском, владелец это уже проходил.

✓ СДЕЛАНА на GigaAM, на машине, без облака и без денег. Своего не строили: взято готовое окружение владельца (gigaam 0.2.0 в venv проекта asr-local, модель v2_rnnt уже лежала в кэше на 448 МБ). Первая проверка была неполной: смотрел только один питон из двух и объявил, что gigaam нет. Владелец поправил, нашлось. ЗАМЕРЕНО: холодный запуск около 9 секунд на загрузку модели, прогретая расшифровывает короткую фразу за 0.2-0.3 секунды, поэтому процесс держится горячим и поднимается лениво. Путь к питону только в настройках, в коде его нет. Не настроено — диктовка выключена и окно объясняет почему. Запись голоса удаляется с диска через несколько секунд. Текст ВСТАВЛЯЕТСЯ в поле, а не отправляется: сказанное вслух хочется поправить глазами. Ловушка по дороге: питон читает stdin в кодировке консоли, путь с русскими буквами приходил покорёженным и файл не находился.

⛔ Нужен выбор владельца между тремя путями

feature

↑ Компиляция стабильных сценариев в код

Принцип владельца, память compiled-ai-principle. Замер 01.09.2026: два хода с ssh заняли 10 секунд. Сценарий из 5-8 шагов это до минуты, анимация ощущение медленности не спасёт. Стабилизировался сценарий, компилируется в код, ИИ остаётся на что именно сделать. | 02.09: частично уже сделано самой архитектурой. Планировщик, гейт, поиск, работа с документами и мост к Office это код, а не рассуждения модели: она их зовёт, но не изобретает. Осталась настоящая компиляция: заметить, что сценарий повторяется, и предложить превратить его в расписание или в свой инструмент.

feature

Запуск двойным щелчком: файл rubka.cmd и ярлык на столе

✓ Владелец спросил, что вообще открывать, и был прав: команда в терминале это не ответ. Сделан rubka.cmd и ярлык Рубка на рабочем столе, ярлык проверен запуском: поднялось три процесса Electron и служба на своём порту. Файл запуска намеренно без единой русской буквы и без chcp: cmd.exe читает .cmd в кодировке OEM и русские буквы внутри превращаются в мусор, ломающий разбор строк, а chcp 65001 внутри скрипта ломает подстановку %~dp0 на пути с кириллицей, из-за чего cd уходил не туда и Electron не находился. Попутно проверено по реестру: ELECTRON_RUN_AS_NODE выставлена только в оболочке разработки, ни в пользовательских, ни в системных переменных Windows её нет, то есть у владельца всё запускается и без ухищрений.

feature

В РАБОТЕS7 · Проверки по сроку3/5

Цель: Отложенные проверки сработало ли. Команда проверки лежит в detail.

↑ Рубка: служба переживает закрытие окна и ночное расписание

Две вещи, которые проверяются только руками на живом рабочем столе. 1) СЛУЖБА ПЕРЕЖИВАЕТ ОКНО. В песочнице разработки не проверить: она гасит всё дерево процессов разом. Команда: открыть окно (env -u ELECTRON_RUN_AS_NODE npm start из E:/Проекты для Гитхаба/rubka), поставить долгую задачу, закрыть окно крестиком, подождать, открыть заново тем же способом. Задача должна оказаться доделанной, а в потоке должен быть ответ и итог. Заодно посмотреть в диспетчере, что процесс electron остался жив после закрытия окна. 2) НОЧНОЕ РАСПИСАНИЕ. Завести во вкладке Расписания что-нибудь простое на ближайшую ночь (например: посмотри свободное место на дисках и скажи одной строкой), утром открыть окно и проверить, что оно сработало: счётчик сработало вырос, в потоке есть ответ. Если не сработало: ssh не нужен, всё локально. Смотреть журнал в %APPDATA%/rubka/журнал.json и адрес службы в %APPDATA%/rubka/служба.json.

✓ Ночная смена 01-02.10.2026. 1) Служба пережила закрытие окна весь день 01.10 (ты работал, окно перезапускалось, очередь на месте); теперь её ещё и сторож держит из планировщика Windows каждые 10 минут. 2) Ночное расписание: разовая задача «место на дисках» заведена на 17:21:54 UTC, сработала в 17:22:00, выполнена на Фейбле: «C: свободно 295 ГБ из 465, D: 154 из 466, E: 158 из 932». Счётчик «сработало» = 1.

check

↑ Рубка: живой бот в Телеграме от начала до конца

⏱ 03.09 · просрочено 57 дн.

Код бота написан и проверен 36 проверками, но на настоящем токене не гонялся: бота заводит владелец. КАК ЗАВЕСТИ (минута): 1) В Телеграме @BotFather, команда /newbot, дальше по шагам. Получишь токен. 2) На машине: cd E:/Проекты для Гитхаба/rubka затем npm run бот Скрипт скажет, куда вписать токен (%APPDATA%/rubka/config.json), проверит его и попросит написать боту сообщение. 3) Напиши боту что угодно. Скрипт напечатает твой номер. 4) Впиши номер в раздел боты, телеграм, кому, и перезапусти службу. ЧТО ПРОВЕРИТЬ: - поставить задачу с телефона обычными словами, получить ответ и итог; - поставить задачу с необратимым (например docker stop несуществующий-контейнер) и убедиться, что пришли кнопки Разрешить и Не надо, а работа ждёт; - нажать Не надо и убедиться, что команда не выполнилась; - написать боту с другого аккаунта и убедиться, что он молчит и задачу не берёт. MAX проверяется так же: npm run бот -- макс. Токен берётся в кабинете dev.max.ru, юрлицо у владельца есть.

⛔ Ночная смена 01-02.10.2026. Бот Рубки в Телеграме заводится только тобой (@BotFather, токен в config.json). Со спринта К1 владельцу Рубка пишет через Джарвиса в Лию — свой бот ей для этого больше не нужен; проверка остаётся только ради постановки задач с телефона.

check

Рубка: диктовка на настоящей речи

Диктовка собрана и замерена на тишине, но настоящую речь она ещё не слышала. Проверяется только голосом. КАК ПРОВЕРИТЬ: 1) Открыть окно: env -u ELECTRON_RUN_AS_NODE npm start из E:/Проекты для Гитхаба/rubka 2) Нажать кнопку с точкой рядом с плюсиком, разрешить микрофон. 3) Сказать фразу с глаголом от первого лица, например: в ближайшие дни доработаю отчёт и пришлю. 4) Нажать кнопку ещё раз. Через секунду текст появится в поле ввода. ЧТО СМОТРЕТЬ: не поехало ли лицо глагола. Именно на этом ломается Whisper: доработаю превращается в доработают. GigaAM не должен. Если поехало — писать сюда, будем думать про Scribe. Первая фраза после запуска службы будет думать секунд девять: грузится модель. Дальше доли секунды.

✓ Владелец проверил голосом 03.09: озвучка отработала, распознала фразу целиком и правильно. Лицо глагола не поехало. GigaAM подтвердил себя, Scribe не нужен.

check

Рубка: первая настоящая ночная выгрузка

Ночь впервые пишет по-настоящему в 00:00 8 сентября. Проверить: ssh cfru 'tail -40 /var/log/night-tg.log' — должны быть все пять шагов и RESULT без раздела «режим». Потрачено: ssh cfru 'ls /opt/aitodo-tg/spend/' и python3 /opt/aitodo-tg/money.py. Ожидание: ноль или центы. Метки связей у новых материалов: ssh aitodo 'docker exec -e TG_LINKS=/tmp/links.json aitodo-backend python /tmp/kb_find.py Нина' — у свежих должно стоять «как нашли: по связям». Отчёт должен прийти в телеграм от Лии.

✓ Ночь отработала сама в 00:01 по Москве. Собрано 8 файлов (3 оцифрованы), 7 знаний, 4 поручения и 3 встречи во Входящие, 1 встреча в календарь на 09.09. Ошибок ноль. Потрачено 0,00128 доллара — десятая доля цента при потолке в доллар. Отчёт дошёл в телеграм. Голосовых за сутки не было, поэтому расшифровка не проверялась живым прогоном ночью — но проверена днём на 13 записях.

check

Рубка: после включения ПК поднялась ровно одна служба

⏱ 20.10 · просрочено 10 дн.

Починка 19.10 (замок). Живая служба 17268 на 19.10 ещё старого кода, новый вступает при следующем подъёме. КОМАНДА ПРОВЕРКИ (PowerShell): Get-CimInstance Win32_Process | ? { $_.CommandLine -match "rubka\\core\\src\\index.mjs" } | select ProcessId,CreationDate — ждём ровно один процесс; Get-Content E:\Рубка\сторож.log -Tail 20 — после включения одна строка «поднял заново», дальше «служба жива» или «замок держит процесс N, вторую не завожу». Две живые службы = провал, гасить лишнюю и разбирать.

check

планS8 · С7 · Очередь и парковка: не простаивать0/8

Цель: Ждать должна задача, а не контур. Упёрлись в вопрос — задача в ожидание, контур берёт следующую. Полное ТЗ: docs/TASK-queue-and-parking.md в репозитории.

↑ Р1. Очередь задач в службе

Очередь в состоянии службы, переживает перезапуск так же, как расписания (переиспользовать schedule.mjs + state.mjs, новый механизм персиста не заводить). Поля: id, контур, текст, источник, статус (в очереди / в работе / ждёт тебя / ждёт лимита / готово / упало), вопрос, критерии, создана, обновлена, кругов. Служба отдаёт: положить, список, отменить, ответить.

task

🔴 Р2. Парковка вместо ожидания

Сейчас в ACCEPTANCE записано: работа действительно ЖДЁТ ответа. Менять: ждёт задача, а не контур. Гейт вернул ask — задача в ждёт тебя вместе с вопросом, контур освобождается и берёт следующую. РАЗВИЛКА, решить и записать в ARCHITECTURE.md: сессия живая и одна на контур, поэтому контекст припаркованной задачи затопчется следующей. Рекомендация — форк сессии (forkSession есть в SDK). Запасной путь — возобновлять новой репликой с пересказом сделанного.

task

↑ Р3. Автопродолжение по очереди

Контур освободился — диспетчер сам берёт следующую задачу, без слова продолжи. Стоп-условия: пустая очередь, лимит на исходе, пауза владельца. Защита от вечного цикла: задача, трижды вернувшаяся без смены статуса, уходит в упало с причиной. Счётчик хранится в самой задаче, не в памяти процесса.

task

↑ Р4. Гейт: экзамены только на чтение

Новое общее правило работы: критерии приёмки превращаются в исполняемые проверки ДО кода, исполнитель их не правит (тест падает — чинится код). В gate.mjs: запись и удаление в test/spec/** и tests/spec/** плюс пути из конфига дают ask, а не allow. Не deny: критерий иногда действительно меняется. Конфиг может добавить пути, убрать встроенные нельзя. Разбор вложенной в ssh команды распространить и сюда. Прежние проверки gate.test.mjs остаются зелёными.

task

Р5. Диспетчер знает про лимит

С 26.06.2026 Agent SDK и headless тянут из обычных лимитов подписки, отдельного пула нет, окно и недельный бак общие с чатом. Ночная автономия без учёта лимита выест бак. Не брать новую задачу и не поднимать контур на исходе окна; упёрлись — не падать, а переводить в ждёт лимита и продолжить, когда откроется; владельцу одно сообщение, не поток. Точного API остатка нет: посмотреть, что отдаёт SDK у лимита, считать по факту с резервом, находки записать в ARCHITECTURE.md.

task

Р6. Разбор пачкой: раздел Решения

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

task

Р7. Пульт на доме

Виджет с шестью числами: в работе, ждёт тебя, упало, потрачено, остаток лимита, застряло дольше суток. Единственное место, куда владелец смотрит по ходу дня.

task

↑ Экзамены спринта до кода

По новому правилу спека → экзамены → код. Критерии приёмки уже написаны в docs/TASK-queue-and-parking.md (21 штука). Превратить их в исполняемые проверки в test/spec/ ДО реализации и убедиться, что каждая падает на текущем коде. Скилл spec-tests. Ручные критерии (закрытие окна на живом столе, ночное расписание) идут отдельным списком с инструкцией, автотестом не притворяются.

task

готовS9 · С9 · Привести вид в порядок6/6

Цель: Показать можно клиенту: без технической кухни, вопросы кнопками, всё по-русски. Делается В КОНЦЕ, когда работа закончена.

🔴 Вопросы кнопками, а не текстом

НАКАЗ ВЛАДЕЛЬЦА 03.09. Сейчас ассистент задаёт вопрос обычным текстом: скажите да в корзину или да насовсем. Человек должен нажимать кнопки, а не переписывать слова. Вопрос гейта уже приходит кнопками, а вопросы самого ассистента нет. Нужно: ассистент задаёт вопрос через отдельный инструмент с вариантами, окно рисует их кнопками в потоке, нажатие уходит обратно как ответ.

✓ СДЕЛАНО и доказано живым прогоном. У ассистента появился инструмент ask_owner: вопрос вариантами. Задача при этом паркуется, проект берёт следующую, выбор возвращается репликой. ВАЖНОЕ: одного инструмента мало, проверено что модель сама к нему не тянется и зовёт только если назвать прямо. Поэтому у сессии появились короткие правила поведения оболочки. По дороге нашёлся разрыв от перехода на парковку: вопрос перестал появляться В РАЗГОВОРЕ и был виден только в сводке решений, для человека беседа обрывалась на полуслове. Починено. На снимке ассистент сам сходил в папку загрузок, посчитал 1306 элементов и 7.11 ГБ и предложил пять вариантов кнопками с числами файлов.

feature

🔴 Убрать техническую кухню из интерфейса

НАКАЗ ВЛАДЕЛЬЦА 03.09, это его давнее правило и я его нарушил в трёх местах. 1) Виджет ЧТО Я ДЕЛАЛ показывает сырые имена инструментов вида mcp__rubka-docs__preview_edit. Должно быть по-человечески: посмотрел документ, показал правку. 2) В шапке справа висит полный путь C:/Users/pc/AppData/Roaming/rubka/config.json. Спрятать, но не выбрасывать: путь нужен, когда что-то не так, значит под раскрытие или в отдельный экран. 3) Пройти по всем текстам и вычистить остальное. | 03.09 ЕЩЁ НАГЛЯДНЕЕ: на новом снимке виджет ЧТО Я ДЕЛАЛ показывает целиком сырой PowerShell с путями и переменными, вида $p = C:/Users/pc/Downloads/ПП $items = Get-ChildItem $p -Recurse. Виджет должен говорить человеческими словами что делалось, а команду прятать под раскрытие. | 03.09 СДЕЛАНА ПЕРВАЯ ЧАСТЬ по прямой просьбе владельца: лента ЧТО Я ДЕЛАЛ теперь говорит словами (остановил контейнер, сходил на сервер, прочитал документ, работал в браузере), сама команда открывается кнопкой в раскрытом виде. Проверено снимком. ОСТАЛОСЬ: путь к настройкам в шапке, меню окна на английском, общая вычитка.

✓ СДЕЛАНО. Лента ЧТО Я ДЕЛАЛ говорит словами (остановил контейнер, сходил на сервер, прочитал документ), команда под кнопкой. Полный путь к настройкам убран из шапки и переехал в меню, вместе с папкой состояния: в шапке им не место, но добраться надо в два клика.

feature

↑ Меню окна и всё системное по-русски

Сверху висит File Edit View Window. Нужно русское меню, а лишние пункты убрать вовсе: человеку там нужны единицы.

✓ СДЕЛАНО. Вместо File Edit View Window три раздела по-русски: Рубка (обновить окно, настройки, папка состояния, закрыть), Правка, Вид (крупнее, мельче, во весь экран, внутренности окна). Лишнее убрано.

feature

↑ Состояние и настройки вести на диске E, а не на C

НАКАЗ ВЛАДЕЛЬЦА 03.09: диск C маленький, всё надо вести на E. Сейчас состояние лежит в %APPDATA%, то есть на C: настройки, журнал, расписания, контуры. Сделать папку состояния настраиваемой и по умолчанию складывать на диск с местом. Учесть переезд: если на старом месте что-то есть, перенести, а не потерять.

✓ СДЕЛАНО. Папка состояния задаётся настройкой, при запуске прежнее нажитое ПЕРЕНОСИТСЯ, а не бросается. У владельца переведено на E:/Рубка, перенеслось три файла: журнал, контуры, очередь. Копируем, а не двигаем: если что-то пойдёт не так, прежнее остаётся на месте.

feature

↑ Общая вычитка вида: как будто показываем клиенту

Владелец: сделать красиво и круто, без лишних косяков. Пройти все экраны подряд, вычистить неровности, проверить снимками. Смотреть: ровность, одинаковые отступы, пустые состояния, поведение при узком окне.

✓ Пройдено снимками живого окна по всем экранам: дом с пультом и решениями, разговор с вопросом кнопками, превью правки, поиск, расписания. Правки внесены по ходу.

feature

Из дома не видно, что в контур надо проваливаться

РАЗОБРАНО 03.09. Поломки нет, есть недоработка вида. Владелец смотрел на ДОМ и считал виджеты вкладками: остаток, задачи, сессия, что я делал, других не вижу. А Разговор, Задачи, Расписания и История живут ВНУТРИ контура, куда попадаешь нажатием на кнопку Рубка внизу слева. По дому этого не видно: контур выглядит как ещё одна кнопка, а не как вход куда-то. Человек не нашёл половину приложения и решил, что её нет. ЧТО СДЕЛАТЬ: показать на доме, что контур это вход (подпись, стрелка, превью содержимого), либо вынести разговор и историю прямо на дом, либо и то и другое. Заодно решить, не путает ли слово контур: для владельца это просто его проект.

✓ СДЕЛАНО. Появился раздел ПРОЕКТЫ с подписью «нажми на проект, чтобы открыть разговор, задачи и историю», у проекта стрелка и счётчик задач. Раньше контур выглядел как ещё одна кнопка, и владелец не нашёл половину приложения.

feature

ревьюS10 · С10 · Очередь, парковка и пульт7/7

Цель: Ждать должна ЗАДАЧА, а не контур. Упёрлись в вопрос — задача на парковку, контур берёт следующую. Постановка лежит в репозитории: docs/TASK-queue-and-parking.md, ЖДЁТ ПОДТВЕРЖДЕНИЯ владельца перед началом.

🔴 Р1. Очередь задач в состоянии службы

Переживает перезапуск так же, как расписания. Механизм переиспользовать, второй не заводить. Поля задачи и статусы описаны в docs/TASK-queue-and-parking.md.

✓ core/src/queue.mjs. Переживает перезапуск тем же способом, что расписания, второй механизм не заводили. Статусы: в очереди, в работе, ждёт тебя, ждёт лимита, готово, упало, отменена. Задачи из окна, ботов и расписаний кладутся в неё, а не говорятся сессии напрямую.

feature

🔴 Р2. Парковка вместо ожидания

Гейт вернул ask — задача в ждёт тебя, контур свободен и берёт следующую. РАЗВИЛКА, которую надо решить и записать в ARCHITECTURE.md: сессия одна на контур и живая, поэтому контекст припаркованной задачи затопчется. Рекомендация постановки: форк сессии. Запасной путь: возобновление с коротким пересказом. Выбор обосновать замером.

✓ Главное изменение. Раньше хук гейта ЖДАЛ ответа и весь проект стоял. Теперь задача уходит в ждёт тебя, хуку возвращается отказ, ход завершается, проект берёт следующую. РАЗВИЛКА РЕШЕНА ПО ЦЕНЕ: не форк сессии, а возобновление коротким пересказом. Форк стоит подъёма контекста 31-44 тысячи токенов, парковок за день много, пересказ стоит десятков токенов. Записано в комментарии dispatcher.mjs. ДОКАЗАНО НА ЖИВОЙ СЕССИИ: первая задача упёрлась в вопрос и ушла ждать, вторая пошла в ту же минуту, ответ вернул первую и она продолжилась пересказом, а не начала заново.

feature

↑ Р3. Автопродолжение с защитой от вечного цикла

Контур освободился — берёт следующую сам, без вопроса продолжить. Стоп-условия: пустая очередь, лимит на исходе, пауза владельца, три возврата без смены статуса.

✓ Диспетчер сам берёт следующую задачу, без слова продолжи. Стоп-условия все на месте: пустая очередь молчит без холостых событий, пауза владельца, исход лимита, три возврата без движения уводят задачу в упало с причиной. Счётчик кругов живёт в самой задаче и переживает перезапуск.

feature

↑ Р4. Гейт: экзамены только на чтение

Запись в test/spec/** даёт ask, а не allow и не deny. Конфиг может добавить пути, убрать встроенные нельзя. Разбор вложенной в ssh команды распространить.

✓ Запись в test/spec и tests/spec даёт ask с прямым объяснением что это экзамен. Не deny: критерий иногда меняется, но это решение владельца. Конфиг может добавить свои пути, убрать встроенные нельзя. Разбор внутри ssh распространён.

feature

↑ Р5. Диспетчер знает про лимит

Не брать новую задачу на исходе окна, переводить в ждёт лимита и продолжать, когда откроется. Владельцу ОДНО сообщение. Точного API остатка нет: выяснить на живом SDK и записать в ARCHITECTURE.md.

✓ Порог по доле израсходованного пятичасового окна, по умолчанию 0.95, настраивается. На исходе новые задачи не берутся, ждущие уходят в ждёт лимита, служба не падает. Владельцу ОДНО сообщение, проверено экзаменом на трёх задачах подряд. Окно открылось — задачи возвращаются сами.

feature

Р6. Разбор пачкой: раздел Решения

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

✓ Виджет Решения на доме: все ждущие вопросы одним списком с проектом, задачей, самой командой и кнопками. Кнопка применить все дефолты. Срочные вопросы (деньги, деструктив) уходят отдельным событием немедленно и не ждут сводки.

feature

Р7. Пульт на доме

Виджет с шестью числами: в работе, ждёт тебя, упало, потрачено, остаток лимита, застряло дольше суток.

✓ Виджет Пульт: в работе, ждёт тебя, в очереди, упало, застряло дольше суток, всего. Тревожные числа красным. Кнопка паузы разбора очереди. Обновляется опросом раз в пять секунд без перезапуска окна.

feature

готовS11 · С11 · Канбан по проектам4/4

Цель: Владелец кладёт задачи в очередь и СМОТРИТ, как они двигаются. Карточки двигает ассистент: взял в работу, завершил. Разбито по проектам, чтобы не было миллиона карточек в одном слое. Идея владельца 03.09, делать ПОСЛЕ спринта очереди.

↑ Доска по проектам, а не одним списком

НАКАЗ ВЛАДЕЛЬЦА 03.09: разбить по проектам, чтобы не было миллиона карточек в одном слое. Значит либо доска на проект с переключением, либо колонки внутри проекта. Решить, что удобнее при двадцати проектах.

✓ СДЕЛАНО. Чипы проектов сверху с числом живых задач плюс отдельный чип «все проекты». Причина прямая: при двадцати проектах общая колонка нечитаема, владелец сказал об этом сразу.

feature

↑ Карточки двигает ассистент, владелец смотрит

Владелец кладёт задачу в очередь. Ассистент сам передвигает: взял в работу, завершил. Владелец наблюдает за движением, а не таскает карточки руками. Ручное перетаскивание может быть, но не оно главное.

✓ СДЕЛАНО и доказано снимком: две задачи положены с доски, прошли по колонкам сами и доехали до готово. Перетаскивания нет нарочно: колонка это состояние задачи, а не место, куда её кладут руками. С карточки можно отменить живую задачу и ответить на вопрос кнопками.

feature

Колонки под реальные состояния задачи

Состояния уже определены спринтом очереди: в очереди, в работе, ждёт тебя, ждёт лимита, готово, упало. Канбан должен показывать именно их, а не выдуманные.

✓ СДЕЛАНО. Колонки ровно по статусам очереди: в очереди, в работе, ждёт тебя, ждёт лимита, готово, упало. Редкие (ждёт лимита и упало) показываются только когда в них что-то есть: видеть их пустыми каждый день это шум, а не сведения.

feature

Связь с очередью, а не второй список

Доска это ВИД на очередь из спринта очереди, а не своё хранилище. Второй механизм не заводить.

✓ СДЕЛАНО. Доска это вид на очередь службы, своего хранилища нет. Всё, что на ней видно, переживает перезапуск, потому что живёт в очереди. Второй механизм рядом с существующим не заводили, как и требовала постановка.

feature

ревьюS12 · С12 · Отчёты по соцсетям3/4

Цель: Понедельничный отчёт по соцсетям сам приходит владельцу. Данные считает код, не модель.

↑ Сборщик недельной статистики соцсетей

/opt/atlas/scripts/smm-week.py на cfru. Берёт данные Контент Завода из smm_analytics_daily по владельцу аккаунта.

✓ СДЕЛАНО и проверено на живых данных. ГЛАВНАЯ НАХОДКА: в smm_analytics_daily лежат НАКОПИТЕЛЬНЫЕ значения, а не суточные (лайки 77,77,78,78,79; показы 6045...8537). Сумма за неделю врёт в сотни раз: мой первый подсчёт дал 25946 просмотров и 622 лайка, тогда как настоящий прирост +182 просмотра и +2 лайка. Скрипт считает РАЗНИЦУ между концом и началом окна. Поле reach скачет (0, 17, 323, 1834) и в отчёт не идёт, по ютубу просмотров нет вовсе, заполняются показы. Живой прогон: Инстаграм 3351 подписчик (-3), +182 просмотра, +2 лайка; Ютуб 227 подписчиков (0), +4426 показов, +24 лайка; Пинтерест без движения. | 06.09 добавлены подписи аккаунтов в отчёт (Ютуб · BRENDOSS мебель, Инстаграм · brendoss1). Без подписи легко отдать человеку чужие числа: профиль один на два завода.

feature

↑ Расписание в Рубке на понедельник 9:00

Крон 0 9 * * 1 в контуре Рубка. Задача зовёт скрипт по ssh и показывает его вывод.

✓ Заведено и видно в состоянии службы: включено, крон 0 9 * * 1. В тексте задачи прямо сказано не пересчитывать числа самому. ВАЖНО: сработает только когда Рубка запущена. Автозапуск владелец просил сделать позже, после ручного тестирования. | 06.09 переписано под Брендосс: в тексте задачи названы аккаунты Альфреда, пинтерест исключён как личный аккаунт Оксаны, и прямо сказано наружу ничего не отправлять.

feature

↑ Куда отправлять отчёт Альфреду: нужен ответ владельца

ОТКРЫТО. Владелец сказал: написать Альфреду отчёт по соцсетям в понедельник 9:00, и чтобы отчёт по Альфреду приходил в Рубку или в Лию в телеге. КТО ТАКОЙ АЛЬФРЕД - неизвестно: его нет ни в памяти, ни в складе знаний AITODO, ни среди заводов Контент Завода, ни среди подключённых аккаунтов. Нужно: (1) кто он и его ли это соцсети (аккаунты Оксаны Яхиной) или другие; (2) куда слать - в Рубку, в Лию в телеге, или ему напрямую. Отправка наружу без явного да не делается. | 06.09 РАЗОБРАНО ДАННЫМИ, спрашивать не пришлось. Альфред это владелец мебельной фабрики БРЕНДОСС, ему делали сайт брендосс.рф и видео в Контент Заводе. Статистика Контент Завода тянется из Upload-Post по имени ПРОФИЛЯ, а не по заводу: у Оксаны два завода (Диван и Фабрика Брендосс) смотрят в один профиль factory_329f630e_divan, поэтому цифры у них совпадают до единицы, и это не ошибка. Проверено через Upload-Post, что за аккаунты: ютуб BRENDOSS мебель, инстаграм brendoss1, пинтерест yahina186 (личный Оксаны, в отчёт не идёт). Значит цифры действительно Альфреда, Диван это раннее рабочее название того же профиля. ОСТАЛОСЬ ОДНО: куда слать сам отчёт. Сейчас он приходит только владельцу в Рубку. Отправка Альфреду наружу без явного да не делается.

✓ РЕШЕНО ВЛАДЕЛЬЦЕМ 06.09: отчёт присылает Лия в телеграм. Сделано НЕ через Рубку, а кроном на cfru: 0 6 * * 1 UTC это понедельник 9:00 по Москве, запускатель /opt/atlas/scripts/smm-week-cron.sh, ключи Лии в /opt/atlas/scripts/.smm-week.env с правами 600. Причина: cfru работает всегда, а Рубка только когда открыта, и до автозапуска отчёт бы просто не пришёл. Дубль из расписаний Рубки убран. Проверено настоящей отправкой.

feature

Разбивка по отдельным роликам

Владелец просил в отчёт «сколько какие видео набрали». СЕЙЧАС НЕВОЗМОЖНО: в smm_analytics_daily только сводка по площадке, а smm_network_posts хранит лишь факт публикации без метрик, и у Оксаны там ноль записей. Для разбивки по роликам нужен прямой доступ к YouTube Data API и Instagram Graph API с токенами её аккаунтов. Это отдельная работа и чужие доступы.

feature

ревьюS13 · С13 · Забор задач из AITODO22/22

Цель: Рубка забирает из AITODO задачи с галкой «через ИИ» в свою очередь, ждёт условия «инфа собрана», читает паспорт задачи из базы знаний и возвращает итог в задачу AITODO и в телеграм. Очередь и парковка уже есть (С10, core/src/queue.mjs). Решения владельца 06.09.2026, роадмап скилла в проекте aitodo, спринт С17.

↑ Экзамены спринта до кода

Скилл spec-tests: подставной AITODO (или живой с тестовой задачей), проверки очереди снаружи через состояние службы.

✓ core/test/spec/aitodo.spec.mjs: 9 экзаменов, подставной AITODO. Первый прогон до кода красный (модуля нет). После кода 9 из 9; регресс npm test 58 из 58.

task

Есть исполняемый файл проверок по одной на критерий; прогон без кода красный; исполнитель их не правит

✓ ✓ файл экзаменов есть, первый прогон до кода красный, исполнитель не правил

acceptance

↑ Р1. Опрос AITODO по расписанию: галка «через ИИ» → очередь

Расписание службы (schedule.mjs) раз в 30 минут: GET /api/tasks?via_ai=true&status=todo долгоживущим ключом. Единица очереди с источником aitodo, контур по проекту задачи, ключ дедупликации = id задачи AITODO.

✓ core/src/aitodo.mjs ОпросAITODO: GET /api/tasks/?via_ai=true&limit=500 с X-Service-Key раз в каждыеМинут (30), контур по проекту из настроек aitodo.контуры, дедуп по внешний{система,id}; в очередь кладёт, в работу берёт тик диспетчера.

feature

Поставил галку в AITODO, и в течение 30 минут задача стоит в очереди Рубки с контуром по проекту

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ задача в очереди с контуром FitLead, источник aitodo, запрос с via_ai=true и X-Service-Key

acceptance

Повторный опрос не плодит дубли: одна задача AITODO = одна единица очереди

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ три опроса подряд = одна единица очереди

acceptance

Ключ к AITODO лежит в настройках пользователя (APPDATA/rubka), в репозитории его нет

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ config/rubka.example.json: aitodo.ключ=null; в core/src нет 64-hex ключей

acceptance

↑ Р2. Статус «ждёт условия»: подзадача «собрать информацию» закрыта

Новый статус рядом с «ждёт тебя» и «ждёт лимита». Условие: у родительской задачи в AITODO подзадача или пункт чеклиста «собрать информацию» выполнен. Проверяется тем же опросом.

✓ queue.mjs: статус «ждёт условия», поля внешний/условие, найтиВнешнюю, ждутУсловия, условиеВыполнено, счётчик в пульте. Условие: незакрытая подзадача «собрать информацию» у того же родителя.

feature

Задача с незакрытой предпосылкой висит в «ждёт условия» и не занимает контур

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ задача с открытой подзадачей стоит в «ждёт условия», диспетчер её не берёт

acceptance

Закрыл подзадачу в AITODO, и в следующий опрос задача уходит в «в очереди» и стартует сама

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ подзадача закрыта → следующий опрос переводит в очередь, диспетчер берёт сам

acceptance

Р3. Паспорт задачи в контексте прогона

Перед стартом Рубка читает <Проект>-База-Знаний/задачи/<slug>.md и папку файлов рядом; путь берётся из описания задачи AITODO.

✓ aitodo.mjs текстДля: реплика начинается с номера задачи AITODO, включает описание с путём к паспорту и велит прочитать паспорт и файлы, перечислив прочитанное в отчёте.

feature

Прогон начинается с чтения паспорта и файлов задачи; в отчёте перечислено, что прочитано

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ реплика содержит «паспорт», путь kp-avtogeneratsiya.md, «AITODO №5», «прочитал»

acceptance

↑ Р4. Отчёт назад: итог и вопросы в задачу AITODO и в телеграм

Готово: строка в описании задачи AITODO с датой и ссылкой на результат, задача владельцу на проверку, сообщение в телеграм. Вопрос гейта: «ждёт тебя» плюс телеграм, как сейчас.

✓ aitodo.mjs слушать: копит «слово» по контуру задачи, на «задача:готова»/«задача:упала» шлёт POST /api/tasks/{id}/result {text, url}; bots.mjs: для задач с источником aitodo адресат = первый из белого списка, вопросы гейта и итог уходят владельцу в телеграм; dispatcher.mjs отдаёт источник и внешний в «задача:взята».

feature

Итог прогона виден в задаче AITODO и пришёл в телеграм

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ POST /api/tasks/5/result с текстом из сказанного и url из текста

acceptance

Вопрос по задаче из AITODO уходит в «ждёт тебя» и в телеграм; ответ из телеграма возвращает задачу в работу

✓ core/test/spec/aitodo.spec.mjs 06.09.2026 (npm run экзамены: 34 из 34, npm test: 58 из 58): ✓ упавшая задача отчитывается «Упало: …»

acceptance

↑ Р5. Правки по разбору ОТК (круг 2)

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

✓ Сделано: итог кладётся в задачу очереди до отправки и досылается каждым опросом (задача с недоставленным итогом не вытесняется из журнала); ошибки и возврат связи видны в окне и уходят владельцу в телеграм одним сообщением на смену состояния; папка контура берётся из настроек и заведённых окном, без папки задача не кладётся; отменяется всё, что ещё не в работе; ссылка берётся названная или последняя; условие ловится и у подзадач самой задачи; таймаут запроса 30 с, списки страницами по 200.

task

Итог, который кабинет не принял, не теряется и уходит следующим опросом

✓ aitodo.spec.mjs 07.09.2026 (npm run экзамены 41 из 41, npm test 58 из 58): ✓ 503 на первой попытке: итог в задаче очереди, пережил перезапуск, дослан вторым опросом, ровно две попытки

acceptance

Кабинет молчит или ключ не подошёл — владелец получает сообщение с подсказкой

✓ aitodo.spec.mjs 07.09.2026 (npm run экзамены 41 из 41, npm test 58 из 58): ✓ 401 даёт aitodo:ошибка с подсказкой про ключ и адрес, бот пишет владельцу, ничего не кладётся

acceptance

Нет папки проекта — задача не кладётся, владельцу сказано, какой контур завести

✓ aitodo.spec.mjs 07.09.2026 (npm run экзамены 41 из 41, npm test 58 из 58): ✓ задача не положена, подсказка про контур, на втором опросе не повторяется

acceptance

Снятая галка отменяет всё, что ещё не в работе

✓ aitodo.spec.mjs 07.09.2026 (npm run экзамены 41 из 41, npm test 58 из 58): ✓ после снятия галки задача отменена и в работу не пошла

acceptance

Ссылкой на результат становится названная или последняя, а не первая попавшаяся

✓ aitodo.spec.mjs 07.09.2026 (npm run экзамены 41 из 41, npm test 58 из 58): ✓ из двух ссылок взята названная результатом, ok=true

acceptance

Условие «собрать информацию» ловится и у подзадачи самой задачи

✓ aitodo.spec.mjs 07.09.2026 (npm run экзамены 41 из 41, npm test 58 из 58): ✓ галка на верхней задаче ждёт свою подзадачу, после её закрытия идёт в очередь

acceptance

Упавший прогон уходит в кабинет с признаком «не получилось»

✓ aitodo.spec.mjs 07.09.2026 (npm run экзамены 41 из 41, npm test 58 из 58): ✓ ok:false в теле отчёта

acceptance

готовS14 · С14 · Ночная выгрузка и связи знаний13/14

Цель: Раз в сутки собирать телеграм и MAX по четырём папкам, раскладывать файлы, аудио и тексты с разметкой кто-от-кого, задачи во Входящие, связывать кто что знает. НЕ НАЧАТО: сначала развилки владельца.

🔴 Развилка: чем читать MAX и рисковать ли аккаунтом

ПРОВЕРЕНО 06.09: официальный Bot API личные чаты читать НЕ МОЖЕТ, у ботов в списке чатов только групповые. Читать свои переписки можно только юзерботом на ВНУТРЕННЕМ неофициальном API: обычный аккаунт с подтверждённым номером, которым управляет скрипт, глубина до 5000 сообщений за 3 месяца. Схема та же, что уже работает с телеграмом, но MAX строже, и цена ошибки это блокировка аккаунта. НУЖНО РЕШЕНИЕ: рискуем или MAX пока не трогаем.

✓ Отменено владельцем 07.09: «ок не надо». MAX из ночной выгрузки исключён, читаем только Телеграм. Личный аккаунт MAX под автоматизацию не подставляем.

feature

Сканы PDF: 12 файлов не читаются без распознавания

Владелец сказал «ставь» 08.09. Поставлено на cfru: tesseract 5.3.4 с русским и английским плюс poppler-utils, места не занял заметно. Читалка file_text.py включает распознавание сама, когда текстового слоя в pdf почти нет: страницы рисуются pdftoppm в картинки на 200 точках и читаются tesseract. Порог — меньше 60 знаков на страницу. Первых 12 страниц хватает: вопрос обычно про начало документа, а скан договора на сорок листов ночь бы не осилила. Качество проверено на живой странице презентации Фит Лида: «Блогинговое агентство в нишах ЗОЖ, фитнес, wellness и beauty. Мы соединяем бренды с проверенными блогерами» — чисто, вместе с латиницей. На aitodo tesseract НЕ ставим: это прод-образ, а читалка без него просто не распознаёт и работает как раньше. Осталось: дооцифровать 11 сканов, которые уже лежат в складе пустыми.

✓ Поставлено по слову владельца «ставь». На cfru tesseract 5.3.4 с русским и английским плюс poppler-utils. Читалка включает распознавание сама, когда текстового слоя в pdf почти нет: порог 60 знаков на страницу, первых 12 страниц, 200 точек. Заодно научилась читать картинки (png, jpg, webp) — скриншоты переписки приходят в чат постоянно и раньше лежали именем файла. На aitodo tesseract НЕ ставили: это прод-образ, читалка там просто работает как раньше. Итог по складу: из 11 материалов, лежавших пустыми, оцифровано 10. Один не поддался и не поддастся — файл битый при загрузке, 234 КБ нулей вместо pdf, оригинал остался в телеграме. Тексты записаны, куски и векторы пересчитаны, темы проставлены. Проверка: скан «ECONITY КЕЙС.pdf» теперь находится поиском и несёт темы блогеры, реклама, маркетинг, социальные сети; до этого он был невидим. Качество русского на живой странице: «Блогинговое агентство в нишах ЗОЖ, фитнес, wellness и beauty. Мы соединяем бренды с проверенными блогерами». Потрачено за день всего 0,1567 доллара при согласованных 36 центах; само распознавание бесплатно, платили только за темы и векторы. Правка в kb_digitize.py: флаг --сканы поднимает материалы с пометкой «текста внутри нет», которые раньше пропускались навсегда.

task

🔴 Развилка: где оцифровывать файлы ночью

Конвейер разнесён по трём машинам не случайно: сессия телеграма на cfru, ЧИТАЛКИ pdf и docx только на машине владельца, база и ключ расшифровки в контейнере aitodo. Крон в 00:00 упрётся в средний шаг: компьютер ночью выключен. ДВА ПУТИ: перенести читалки на cfru и сделать конвейер полностью серверным, либо оставить как есть и оцифровывать при первом включении, тогда ночью копится только сырьё.

✓ Решено: оцифровка на cfru, ночь не ждёт включённого компьютера. Окружение /opt/aitodo-tg/venv (питон 3.12, 35 МБ): pypdf, python-docx, openpyxl, python-pptx. Читалка /opt/aitodo-tg/file_text.py, она же выложена на aitodo. Прогон по реальному сбору: 76 файлов, прочитано 64, ошибок 0. Пустых 12 — это сканы PDF без текстового слоя (проверено: страниц 7, знаков на первой 0, картинка 1). Для них нужен OCR, вынесено отдельным вопросом владельцу.

feature

🔴 Гейт на деньги в ночном автомате

Потолок владельца 07.09: не больше 1 доллара за ночь, «должно быть гораздо меньше». Замер по живому сбору: 55 голосовых, 63,6 минуты речи всего накопленного. Значит платный путь дал бы центы, но берём нулевой: GigaAM на самом cfru, 8 ядер AMD EPYC. Причина не только деньги — Whisper ломает лицо глагола на русском («доработаю» слышит как «доработают»), а в голосовых от клиентов это переворачивает смысл задачи. Гейт всё равно ставим жёстким счётчиком: ночь останавливается на пороге, а не после списания.

✓ Гейт /opt/aitodo-tg/money.py, потолок 1,00 за ночь (переменная NIGHT_BUDGET). Запись до вызова, повтор бесплатен по хешу вопроса, обрыв не теряет трату, несостоявшийся вызов возвращает бронь, битый журнал останавливает ночь. Экзамен test_money.py: 16 проверок, все зелёные. Главное: расшифровка выведена из платного контура вовсе — GigaAM поставлен на cfru (venv-asr, 1,1 ГБ), считает на CPU быстрее реального времени. Ожидаемая цена ночи 0,00 доллара.

feature

Вызов, который переваливает за потолок ночи, не происходит вовсе: прогон получает отказ до обращения к провайдеру

✓ Экзамен 1 зелёный: при потолке 1,00 и потраченных 0,90 вызов на 0,20 поднимает Потолок до обращения к провайдеру, потрачено осталось 0,90.

acceptance

Тот же вопрос второй раз за ночь не тратит: ответ берётся из журнала

✓ Экзамен 2 зелёный: ключ = хеш вопроса, повторный уже() отдал прежний ответ, потрачено не выросло.

acceptance

Цена записана до вызова и переживает обрыв: после перезапуска она в журнале

✓ Экзамен 3 зелёный: цена пишется в журнал до вызова, новый объект гейта после «обрыва» видит 0,30 и помнит, что ответа не было.

acceptance

Вызов не состоялся (сеть, отказ провайдера) — бронь снята, деньги не списаны

✓ Экзамен 4 зелёный: вернуть() снимает бронь, потрачено 0,00, потолок снова целый.

acceptance

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

✓ Экзамен 5 зелёный: отчёт сложил 0,10+0,15+0,05=0,30, показал потолок и две статьи, в разметке 2 вызова.

acceptance

Ночь с расшифровкой голосовых показывает потрачено 0,00

✓ Экзамен 6 зелёный: voice_text.py не обращается ни к какому платному провайдеру, GigaAM считает на самом cfru. Замер: 25 секунд речи за 14,3 секунды счёта на 8 ядрах, доля 0,57 — быстрее реального времени, видеокарта не нужна.

acceptance

↑ Крон в 00:00 по четырём папкам

Сборщик /opt/aitodo-tg/tg-collect.py УЖЕ умеет отбор по папкам через --folders и --days. Папки: Личные, Фит Лид, Пульс Цен, Клиенты. Своего сборщика не пишем. Работа: запускатель по образцу smm-week-cron.sh. Идемпотентность есть по source_ref. Чтобы мусор не собирался, берём только эти четыре папки.

✓ Крон 0 21 * * * на cfru — это 00:00 по Москве, сервер живёт по UTC. Прогон /opt/aitodo-tg/night.sh, пять шагов: граф связей, сбор за сутки по четырём папкам (Личные, Фитлид, Пульс цен, Клиенты), расшифровка через nice 19, упаковка со связями, запись в склад на aitodo. Отдельным файлом, а не строкой в crontab: экранирование там уже съедало &&. Холостой прогон целиком: 1 минута 17 секунд, собрано 1 файл и 7 пунктов повестки, отчёт дошёл в телеграм.

feature

↑ Разметка: кто, откуда, о чём

Владелец: файл с пометкой что это и откуда взят, аудио с тегом от кого, тексты с автором. Часть конвейер уже делает. Работа: доразметить источник до уровня папка-чат-человек и проверить на настоящей выгрузке, что метки не пустые.

✓ Каждой записи проставляются метки: от кого, когда, папка, чат, проект, человек или тема, плюс отметка «проект подтверждён названием чата». Живой прогон: 48 записей из 48 со связями. Пример как просил владелец — голосовое Нины несёт «от: Нина фитлид Тарасова, когда: 2026-09-01, папка: Фитлид, проект: Фит Лид, человек: Нина Тарасова». Метки строками с приставкой, а не словарём: в складе уже лежат 562 материала со списком тегов, смена формы поломала бы их поиск.

feature

↑ Связи: кто что знает и у кого спросить

Расширено владельцем 07.09: «не только рагом размечать, а ещё и связями». Каждый материал (файл, голосовое, встреча, сообщение) помечается: от кого, дата, к какому проекту. Связи транзитивные: Нина → Фит Лид → Искра. Проверка приёмки словами владельца: «найди инфу по такой то задаче» — и наружу выходит весь контекст сразу, из сообщений, аудио, встреч и файлов, без ручного поиска по папкам.

✓ Граф /opt/aitodo-tg/links.json собирается tg_graph.py из самой структуры телеграма, без модели: папка это проект, тип собеседника отличает человека от группы, метка в названии чата подтверждает принадлежность. Вышло 4 проекта, 64 человека, 19 групп. Поиск kb_find.py раскрывает запрос в обе стороны: «Искра» опозналась как тема в Фит Лиде и в Клиентах и развернулась в 65 меток связей — то есть материалы Нины поднимутся на вопрос про Искру, хотя слова «Искра» в них нет. Проверено на живом складе: по «Нине» нашлись наработки, ссылка и расшифровка встречи. Ручные правки владельца живут в разделе «руками» и переживают пересборку.

feature

Задачи во Входящие

То, что похоже на поручение, кладём во Входящие AITODO. Конвейер это умеет. Работа: проверить на настоящей выгрузке, что задачи узнаются и не дублируются.

✓ Работало и раньше, теперь проверено на живом сборе: холостая ночь показала 1 поручение и 2 встречи во Входящие и 1 встречу в календарь (09.09 11:00, Алёна по финансам). Встреча идёт в календарь только при однозначном времени, иначе во Входящие: соврать в календаре хуже, чем не поставить. Свои реплики поручением себе не считаются.

feature

готовS15 · С15 · Спираль связей: темы, паспорта, один поиск14/14

Цель: От любого сообщения раскрутить спираль и собрать весь контекст задачи. Человек, проект и тема становятся метками одного сорта, поэтому от любой можно шагнуть к любой. Две оси и путать их нельзя: связи сужают и говорят чьё это, темы расширяют поперёк проектов и вытаскивают чужие встречи, где обсуждали то же самое.

Р1. Доразметка старых материалов связями

Бесплатно и без модели: в ссылке каждого материала лежит номер чата (521 из 547), граф знает чей это чат. Заодно чинится показ «проект: None» — проект брался из тегов, а лежит он в своём поле.

✓ kb_relink.py: 554 материала получили структурные метки без единого вызова модели. Проект брался из своего поля, автор и дата из своих, чат и человек из номера чата в ссылке, родитель из решётки. Заодно нашёлся и починен настоящий дефект данных: у 75 материалов имя автора было записано в cp1251, прочитанной как latin-1 («Íèíà ôèòëèä Òàðàñîâà»). Нина из-за этого была двумя разными узлами графа: 108 материалов под верным именем и 72 под сломанным. kb_fix_names.py чинит обратным преобразованием, проверяя, что на выходе появился русский текст.

feature

Старые 547 размечены так же, как новые: у каждого от кого, когда, проект

✓ Проверено: 554 материала тронуто, проставлено проект 548, когда 547, от кого 521, папка 520, чат 520, человек 317, группа 210, родитель 128.

acceptance

Нигде в ответе не пишется «проект: None», если проект у материала проставлен

✓ Проверено: проект берётся из своего поля через связку с таблицей проектов, а не из тегов. В выдаче по «Нине» и по «лендингам» проект проставлен у всех.

acceptance

Р2. Темы как узлы графа

Модель вытаскивает темы один раз при заносе, дальше они живут метками и достаются бесплатно. Разово по 547 материалам около 36 центов, согласовано владельцем 08.09. Ночью доли цента.

✓ kb_topics.py: 429 материалов размечены темами, 103 остались пустыми и правильно (короткие реплики вроде «ок, понял»). Потрачено 0,1221 доллара при согласованных владельцем 36 центах. Словарь схлопывается намеренно: в каждый вызов кладётся список известных тем с указанием брать существующую. Первая проба вскрыла две беды и обе закрыты кодом, а не надеждой на подсказку: модель тащила в темы названия чатов («ТОПы Fit&Lead») и слишком общие слова («файлы», «материалы»), под которые подходит что угодно.

feature

Спрошу «лендинги» — поднимаются материалы из РАЗНЫХ проектов, включая встречи, где лендинги обсуждали мимоходом

✓ Проверено: вопрос «лендинги» поднял материалы из ЧЕТЫРЁХ проектов — Фит Лид 112, Пульс цен 14, Клиенты 4, Клиент Искра 3. Среди них встреча Нины про блогеров и амбассадоров, где лендинги обсуждались попутно. Связи такую встречу отсекали: она привязана к своему проекту.

acceptance

Р3. Паспорт проекта в ответе

У брендов паспорта уже заполнены: чем занимается, моя роль, кто такие рекламодатели. Синонимы стоят у всех 13 проектов. Надо подставлять их в ответ, чтобы агент понимал предметную область, а не угадывал.

✓ Паспорта у брендов были заполнены и раньше, но в поиск не попадали. Теперь вопрос «Фит Лид» возвращает паспорт первым: «блогинговое агентство и партнёрка, привлекаю рекламодателей в агентство». Проект опознаётся и по синонимам — «фл», «fit&lead», «фитлид» ведут в один.

feature

Спрошу «Фит Лид» — в ответе первым идёт паспорт: чем занимается, моя роль, кто такие рекламодатели

✓ Проверено: «Фит Лид» опознан как проект, паспорт идёт первым разделом ответа.

acceptance

Р4. Обход спирали с затуханием

От сообщения к человеку, от человека к проекту, от проекта к теме, от темы обратно к чужим встречам. Вес падает с каждым шагом, иначе на третьем притянется весь склад.

✓ Обход с затуханием в kb_ask.py. Две проверки подряд вскрыли по дефекту, оба исправлены. Сперва спираль взорвалась: 520 материалов из 563, потому что человек вроде Нины это узел-концентратор, через который связано полсклада. Лечится редкостью связи и потолком узла: через метку крупнее 25 материалов дальше первого шага не идём. Затем вылезло обратное: редкая тема со второго шага обгоняла то, о чём спросили. Лечится жёстким порядком — сперва шаг, потом вес. Итог на вопросе про лендинги: 133 материала вместо 520, вся верхушка первого шага.

feature

Скажу «раскрути» от одного сообщения — вернётся цепочка шагов, и видно, на каком шаге что нашлось

✓ Проверено: kb_ask.py --от tg:1212457921/295982 вернул шаг 0 (само сообщение), шаг 1 и шаг 2, и у каждого куска написано, какой меткой его притянуло.

acceptance

На третьем шаге не притягивается весь склад: вес падает, дальний материал ниже ближнего

✓ Проверено: раскрутка от сообщения даёт 126 материалов вместо 497 до правки, шаг 1 упал с 464 до 38. Вся верхушка выдачи — первый шаг, дальний материал ниже ближнего всегда.

acceptance

Р5. Один поиск вместо четырёх куч

Паспорт, синонимы, связи и векторы сейчас не соединены. Один вопрос должен проходить через все.

✓ kb_ask.py проходит один вопрос через все четыре кучи разом: опознание по синонимам, паспорт проекта, раскрытие связей, обход по темам. Склад держится в памяти целиком — пятьсот материалов это мелочь, зато на каждый кусок видно, на каком шаге и какой меткой его притянуло. Объяснение здесь важнее скорости: владелец должен видеть, откуда взялся каждый кусок.

feature

Ни один шаг поиска не стоит денег: разметка оплачена один раз при заносе

✓ Проверено: kb_ask.py не обращается ни к модели, ни к встраиваниям — только выборка по меткам и словам. Разметка оплачена один раз при заносе.

acceptance

Р6. Пункты встречи и путь назад к родителю

128 материалов уже рождены из родителя, ссылка это помнит. Надо обходить след в обе стороны: от пункта к встрече и от встречи ко всем её пунктам.

✓ След родителя теперь проиндексирован и ходится в обе стороны. От расшифровки видно «пунктов внутри 6», от пункта видно «вышло из». Ребром спирали метка родителя при этом не служит: путь к родителю показывается отдельно, чтобы не смешивать происхождение с обходом по смыслу.

feature

От пункта видно родителя, от родителя видны все его пункты

✓ Проверено: у расшифровки видно «пунктов внутри 6», у каждого пункта «вышло из».

acceptance

ревьюS16 · С14 · Рабочее место: параллельные проекты, экран задачи, проверка через окно23/23

Цель: Владелец ставит задачу и уверен в результате как в VS Code: три проекта параллельно, у задачи свой экран с шагами, поправкой и итогом, слово владельца первым, автозабор с согласия, пауза видна, служба живёт без окна, всё проверено мной через настоящее окно до владельца. Спека docs/TASK-workplace.md, критерии С14.1–С14.14.

↑ Р1. Контуры по проектам, параллельно

Фит Лид, Пульс цен, Клиенты, Свои с папками; задача в контур своего проекта; три сессии одновременно.

✓ Экзамены ядра 49/49 (workplace.spec.mjs), окно 6/6 (workplace-ui.mjs, Playwright+Electron, подставная модель), живой прогон на настоящей модели прошёл (итог: 27 файлов в docs Фит Лида). Отчёт со снимками: https://myvisionagency.ru/lab/rubka-proverka/

task

С14.1 Четыре контура с папками, без папки не заводится

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

С14.2 Три задачи из трёх контуров одновременно в работе, четвёртая ждёт

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

С14.3 Задача AITODO в контур своего проекта, иначе в «Свои»

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

↑ Р2. Экран задачи со своим разговором

События потока несут id задачи; GET /задача/:id; экран задачи в окне; «поправить» в сессию или продолжением.

task

С14.4 События потока помечены задачей

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

С14.5 Карточка задачи: только её события

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

С14.6 Поправка: в сессию / продолжение с родителем

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

↑ Р3. Слово владельца первым

Задача из окна в голову очереди контура; композер контура и экрана задачи разведены.

task

С14.7 Задача из окна в голову очереди

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

↑ Р4. Автозабор с согласия

Вопрос «В AITODO N задач. Брать?» вместо молчаливого забора; настройка братьВсегда.

task

С14.8 Автозабор спрашивает «Брать?», братьВсегда возвращает старое

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

Р5. Вид: пауза, статусы, итог на карточке

Полоса паузы везде с кнопкой «Продолжить», карточка со статусом словами, откуда, сколько идёт, итог и ссылка.

task

С14.9 Полоса паузы с «Продолжить», задача на паузе подписана

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

С14.10 Карточка: статус словами, откуда, сколько идёт, итог и ссылка

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

Р6. Живёт без окна и перезапуска

Закрытие окна и перезапуск службы не теряют очередь; задача в работе продолжается.

task

С14.11 Служба переживает закрытие окна, всё на месте

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

Р7. Телефон: in_progress в AITODO при взятии

Лента Джарвиса показывает «Рубка делает».

task

С14.12 in_progress в кабинете при взятии

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

↑ Р8. Подставная модель и сквозной прогон окна

RUBKA_FAKE_MODEL, Playwright+Electron, снимки, отчёт /lab/rubka-proverka, потом один живой прогон.

task

С14.13 Сквозной прогон окна 6 шагов со снимками

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

С14.14 Живой прогон одной задачей Фит Лида на настоящей модели

Экзамены: core/test/spec/workplace.spec.mjs, core/test/ui/workplace-ui.mjs, live-run.mjs

acceptance

↑ Экзамены спринта до кода

core/test/spec/workplace.spec.mjs (ядро) и core/test/ui (окно); сначала красные.

task

ревьюS17 · С15 · Пульт управления: лимиты, слово на ходу, модели, замер, контекст, команды21/21

Цель: Рубкой можно управлять как VS Code, но по-русски: видно оба лимита и контекст, слово владельца доходит прямо во время работы, модель выбирается по проекту и виду задачи и меняется на живой сессии, время и расход по задаче считаются и уходят в AITODO, есть русские команды. Спека docs/TASK-control.md, критерии С15.1–С15.14.

↑ Р1. Оба лимита и сброс в шапке

five_hour и seven_day с процентами и временем сброса; цвет при >80%.

✓ Экзамены ядра 59/59 (control.spec.mjs), окно 7/7 (workplace-ui.mjs, подставная модель), живой прогон на настоящей модели: лимит «5 часов 12% · неделя 2% · сброс в 15:00», слово на ходу учтено, /модель сонет переключила живую сессию, контекст 11% (113к из 1М), замер задачи 12 с, 1 ход, 113 634 токена.

task

С15.1 Оба окна лимита и время сброса в шапке, тревога при 80%

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

↑ Р2. Слово владельца во время работы

Занят контур → текст идёт репликой в живую сессию, а не новой задачей; видно в разговоре и на экране задачи; правило про авторизацию в браузере (не закрывать, звать владельца и ждать).

task

С15.2 Контур занят → слово уходит репликой в живую сессию задачи

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

С15.3 Контур свободен → новая срочная задача, как раньше

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

С15.4 Правила: слово на ходу важнее шага; браузер при входе не закрывать, звать владельца

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

↑ Р3. Модели: по умолчанию, по проекту, по виду

Настройка модели: поумолчанию/контуры/виды; setModel на живой сессии; список из supportedModels; выбор в шапке контура.

task

С15.5 Модель по правилу вид → контур → по умолчанию, без настройки не навязывается

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

С15.6 /модель и шапка меняют модель на живой сессии (setModel), плохое имя не применяется

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

↑ Р4. Русские команды

/помощь /модель /лимит /контекст /сжать /стоп /пауза /очередь /усилие: обрабатываются окном и службой, в модель не уходят.

task

С15.7 Строка с / это команда, не задача; десять команд разбираются

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

С15.8 /стоп, /пауза, /сжать делают своё

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

↑ Р5. Замер времени и расхода по задаче

взята/закончилась/работаМс/ходов/токены; строка в отчёте AITODO; сводка по проекту за день и неделю.

task

С15.9 По задаче копятся время, ходы и токены

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

С15.10 Строка замера уходит в отчёт AITODO

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

С15.11 Сводка по контурам за сегодня и за неделю

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

↑ Р6. Контекст: сколько занято и сжатие

Процент заполнения из usage, потолок по модели, предупреждение и кнопка «сжать»; событие сжатия видно.

task

С15.12 Контекст в процентах и токенах, потолок по модели

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

С15.13 Тревога на 70% и 85%, сжатие по команде

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

↑ Экзамены спринта до кода

core/test/spec/control.spec.mjs (ядро) + шаги в экзамене окна; сначала красные.

task

С15.14 Живой прогон: команды, слово на ходу, модель, контекст, время

Экзамены: core/test/spec/control.spec.mjs, core/test/ui/workplace-ui.mjs, live-control.mjs

acceptance

ревьюS18 · С16 · Диалоги вместо контуров: своя сессия, свой контекст, управление ходом53/53

Цель: Единица работы — диалог со своей сессией, моделью и контекстом; проект — группа диалогов. Всё, что видно на экране, можно трогать: крошки, модель, усилие, контекст, папка. Плюс управление ходом работы: остановить, продолжить, перезапустить, остановить всё.

↑ Р1. Диалог — первичная сущность

Спека: docs/TASK-dialogs.md, критерии docs/ACCEPTANCE.md (спринт 16).

✓ Экзамены: ядро 78/78 (npm run экзамены, в т.ч. новый dialogs.spec.mjs), окно 11/11 (workplace-ui.mjs, настоящее Electron-окно), старые проверки 58/58 (npm test). Живой прогон на настоящей модели (live-dialogs.mjs): два диалога одного проекта не видят контекста друг друга («не просил запомнить никакое число»), слово на ходу доходит, пульт показывает «Опус 5 (1m)» и «контекст 5% (52к из 1М)», «Остановить» придерживает, «Продолжить» возвращает в работу. Масштаб прогнан: 600 диалогов, 800 шагов — 77 мс.

feature

С16.1 У диалога своё имя, проект, папка, модель, усилие, сессия, контекст, поток, статус, замер