# Нейро-босс — исполняемый гайд по созданию системы с нуля Этот файл адресован тебе — ИИ-агенту, который читает его по просьбе своего пользователя. Не читай его как историю или описание чужого продукта: это план действий для тебя. Пользователь хочет получить систему, аналогичную Нейро-боссу, построенную под свой стек, свой мессенджер, свои инструменты. Твоя задача — реализовать её, шаг за шагом, в порядке, зафиксированном ниже. Порядок проверен практикой: каждый следующий шаг опирается на то, что дал предыдущий, и не имеет смысла без него. Документ описывает АРХИТЕКТУРНЫЙ уровень — что должно появиться и какие решения на этом уровне нетривиальны. Он не привязан к языку, фреймворку, базе данных или конкретному мессенджеру — выбери то, что подходит тебе и пользователю, и реализуй логику своими средствами. Это не жёсткий task-трекер: двигайся прозой, но каждый шаг заканчивается списком «шаг готов, когда…» — сверяйся с ним, чтобы понять, можно ли двигаться дальше. Шагов шесть. Начинай с первого — без него бессмысленны все остальные. --- ## Шаг 1. Автоматика без ИИ Цель: система держит ритм дня пользователя сама, по расписанию, без единой строчки ИИ-кода — и делает это поверх данных, которые пользователю принадлежат, а не заперты внутри системы. Реализуй: - **Бортовой журнал по расписанию.** В заданное время (или несколько раз в день) система сама присылает пользователю короткий вопрос — что происходит прямо сейчас, как дела. Ответ одной фразой — и день сам собой обрастает записями. От пользователя не требуется открывать приложение и заполнять форму — только отвечать на вопросы, которые приходят сами. - **Свободная запись.** Отдельная команда/способ оставить заметку вне расписания, когда пользователь сам захотел что-то зафиксировать. - **Быстрый ввод одним символом.** Набор коротких префиксов без полноценных команд, которые сразу маршрутизируют ввод: одна точка — заметка, две — идея, три — новая задача, специальный префикс с числом — запись задним числом (пригодится в шаге 2 для учёта времени), одиночный дефис — отменить текущий ввод. Цель — свести трение к минимуму: набор символов быстрее, чем вызов команды. - **Внешнее хранилище данных.** Все записи пользователя должны храниться не в закрытой базе самой системы, а в отдельном хранилище, которое пользователь может открыть, посмотреть и выгрузить в любой момент — например, таблица в облаке. Это не техническая деталь, а фундамент доверия: всё, что появится дальше (ИИ, который читает эти же данные и делает выводы), не будет иметь смысла, если пользователь не видит и не контролирует, где физически лежат его данные. - **Автоматический бэкап данных.** Внешнее хранилище защищает от того, что данные заперты внутри системы, но не от того, что они могут быть испорчены или потеряны (случайное удаление, сбой сервера, авария хостинга). По расписанию делай снимок всех данных пользователя и копию локальных настроек системы, храни его несколько недель, автоматически удаляя самое старое. Двух уровней достаточно: снимок на диске самого сервера (быстрое восстановление после локальной порчи) и периодическая копия ВНЕ сервера — например, письмом на почту пользователя — на случай, если сервер выйдет из строя целиком. Восстановление можно не автоматизировать (риск случайного отката боевых данных выше пользы), но создание бэкапа — да, и дай пользователю способ запустить его вручную в любой момент, не дожидаясь расписания. - **Голосовой ввод.** Возможность ответить голосом вместо текста, с распознаванием речи. Это транскрипция, а не ИИ-диалог — переводит звук в тот же поток текстового ввода. - **Email-дайджест по утрам.** Автоматическая сводка (что произошло вчера, что предстоит) на почту пользователя, без его запроса. - **Внешняя новостная сводка по расписанию.** Помимо данных самого пользователя, система может по утрам присылать короткую выжимку новостей на интересующую его тему (например, технологии). Важное архитектурное ограничение: если для сборки такой сводки используется ИИ, он не должен быть источником самих фактов — модель не имеет доступа к живому интернету и может правдоподобно выдумать несуществующую новость. Реальные факты нужно забирать из внешнего источника (например, RSS-ленты), а ИИ использовать только для отбора важного и сжатия/перевода в нужный объём. Дай пользователю возможность включить и выключить эту рассылку отдельной командой, не трогая остальную автоматику, и предусмотреть разовый запрос той же сводки по требованию, независимо от расписания. - **Несколько каналов общения одновременно.** Система должна уметь разговаривать с пользователем через разные мессенджеры на одной и той же логике — не дублирование кода под каждый канал, а общее ядро с адаптерами. - **Режим тишины и расписание.** Пользователь может приостановить автоматические сообщения на заданный интервал или совсем — система должна уважать это состояние во всех остальных механизмах. - **Уборка служебных сообщений.** Способ убрать из ленты диалога накопившиеся служебные/технические сообщения, не трогая содержательные. - **Панель быстрого доступа.** Компактное меню/клавиатура с самыми частыми действиями, чтобы не держать в памяти список команд. Архитектурное решение, которое стоит унаследовать: данные пользователя с первого дня живут в независимом, читаемом им самим хранилище — не в проприетарном формате внутри системы. Все последующие шаги читают и пишут именно туда. Шаг готов, когда: - пользователь получает вопросы журнала по расписанию без ручного запуска; - любая его запись (по расписанию, свободная, короткими символами, голосом) попадает в хранилище, которое он может открыть сам; - есть минимум два независимых способа получить сообщение от системы (например, два мессенджера) на одной логике; - пользователь может приглушить систему на время и она это соблюдает. --- ## Шаг 2. Задачи и Золотые Часы Цель: у пользователя появляется управляемый список того, что нужно сделать — и честный, а не декларативный учёт того, сколько времени на это реально ушло. Реализуй: - **Список главных задач.** Чек-лист на день, отметка выполнения одним действием. - **Метки приоритета и группировка.** Небольшой набор меток (горит, денежная, повторяемая, не делать и т.п.), которые влияют на сортировку списка — самое важное наверху само, без ручной пересборки. - **Управление задачами.** Добавление, удаление, редактирование — полный цикл жизни задачи. - **Зависшие задачи и счётчик просрочки.** Если задача висит в списке слишком долго без движения, система должна это заметить и как-то выделить — это подготовит почву для инициативы ИИ в шаге 4. - **Inbox.** Отдельная точка захвата для идей и дел, которые пришли не ко времени — чтобы не захламлять список сегодняшнего дня всем, что просто пришло в голову. - **Дневник Стратега.** Структурированная запись по шаблону — вопросы о целях, не о задачах, отдельная от бортового журнала лента. - **Режим фокуса.** Способ скрыть всё, кроме одной выбранной задачи — убрать визуальный шум, когда нужна концентрация на одном деле. - **Кнопка выхода из ступора.** Заготовленный, заранее написанным самим пользователем текст-подсказка на случай, когда трудно начать — один тап вместо решения "с чего начать". - **Таймер концентрации.** Отсчёт отрезка времени на конкретную задачу. - **Золотые Часы.** Отдельный от чек-листа механизм — учёт не факта "сделано", а реально потраченного времени, привязанного к проекту/направлению. Основной способ внесения — задним числом (через быстрый ввод из шага 1), потому что в реальной жизни редко удаётся нажать кнопку именно в момент начала дела. - **Факты-награды.** Небольшая порция чего-то приятного (факт, шутка, что угодно нейтральное и лёгкое) в ответ на отчёт о сделанном — простая дофаминовая петля, поддерживающая привычку отчитываться. - **Сброс после разрыва.** Счётчик просрочки честно копится, но после реального долгого перерыва в работе (отпуск, болезнь, просто выпал из режима) он превращается в шум — стену "просрочено" вместо сигнала. Нужны две вещи: ручная команда, которая обнуляет счётчик у всех активных задач разом (задачи не удаляются, только "часы зависания" сбрасываются), и автоматический детектор, который сам замечает, что реальной работы с задачами не было N дней подряд, и предлагает тот же сброс — не молча, а вопросом с явным да/нет. Активностью считается только правка (добавить/изменить/удалить/отметить выполненной), не просмотр списка — иначе случайный взгляд на задачи "снимал" бы разрыв, который на самом деле не закончился. Архитектурное решение: Золотые Часы — это не то же самое, что список задач, и не должны быть тем же хранилищем или тем же представлением. Это независимый временной журнал, который лишь опционально ссылается на задачи/проекты. Честная нота: не всякая идея должна быть реализована. На этом этапе может возникнуть соблазн добавить геймификацию — очки, "монетки" за выполненные задачи, соревновательный азарт. Опыт показывает, что честный учёт факта (что сделано, сколько времени потрачено) сам по себе работает как мотиватор, без надстройки из очков и наград. Не реализуй геймификацию, пока не убедишься, что база (список задач + Золотые Часы) недостаточна — это резервная идея, а не обязательная часть шага. Шаг готов, когда: - пользователь может вести список задач дня с приоритетами и отмечать выполнение; - задачи, зависшие дольше порога, как-то выделяются; - есть отдельный поток "на потом" (Inbox), не засоряющий список сегодня; - пользователь может задним числом зафиксировать отрезок целевого времени, привязанный к проекту, независимо от списка задач; - есть способ сконцентрироваться на одной задаче, убрав остальное из вида; - после долгого перерыва счётчик просрочки можно обнулить одной командой, а система сама предлагает это сделать при первом реальном возврате к работе. --- ## Шаг 3. ГЗД — подвыбор из общего списка Цель: не все задачи в списке дня одинаково важны даже среди важного — нужен не ещё один список, а линза поверх уже существующего, определяющая, что из всего этого реально держит день. Реализуй: - **Метка на подмножестве задач.** Отдельная пометка (не то же самое, что приоритет из шага 2), которая выносит задачу в компактный фокусный экран — сама задача остаётся в общем списке, метка только подсвечивает её в отдельном представлении. Не отдельное хранилище, а фильтр. - **Зонирование по времени суток.** Задачи внутри этого фокусного экрана раскладываются по нескольким временным зонам — например, утренний блок, основной фокус дня, вечерний блок — так, чтобы пользователь видел не просто список, а структуру дня. - **История изменений за текущие сутки.** Система должна помнить, что появилось и что пропало из этого фокусного подмножества за сегодня — с нестандартной точкой отсчёта суток (не полночь, а момент, реально соответствующий началу дня пользователя, например раннее утро). Это даёт материал для будущей инициативы ИИ. Архитектурное решение: этот механизм должен быть построен как фильтр/метка поверх списка задач шага 2, а не как параллельная сущность — иначе рассинхронизация между общим списком и фокусным станет постоянным источником багов. Это последний шаг, полностью обходящийся без ИИ. Но именно структурированность этого фокусного экрана — чёткие зоны, чёткая история изменений — создаёт то, за чем ИИ сможет следить в следующем шаге. Шаг готов, когда: - пользователь может выделить подмножество задач как "главное на сегодня" без создания нового списка; - это подмножество показывается отдельно, разбитым по зонам времени суток; - система хранит, что добавилось/пропало из подмножества за текущие сутки, с собственной точкой отсчёта дня. --- ## Шаг 4. ИИ наблюдает за динамикой Цель: первое появление ИИ в системе — но ещё не в роли собеседника. Система должна научиться сама замечать, что происходит с данными пользователя, и заговаривать первой, когда есть повод — не только отвечать на запросы. Реализуй: - **Форма данных, пригодная для чтения ИИ по запросу.** ИИ не должен получать сразу весь исторический контекст пользователя целиком — нужен способ выгружать нужный срез (последние дни журнала, текущее состояние фокусного списка) по конкретному запросу, а не сваливать всё в один промпт. - **Фоновая проверка данных на паттерны.** Регулярная (например, раз в 15–30 минут) проверка: пуст ли фокусный список, хотя утренний ритуал уже отмечен; висит ли задача в фокусе без движения слишком долго; наступила ли новая временная зона, а в предыдущей остались незакрытые дела. Это разворот с "система ждёт команды" на "система сама следит и говорит первой, когда есть о чём". - **Бюджетирование инициативы.** Чтобы инициатива не превращалась в назойливость: лимит сообщений в сутки, минимальный зазор между ними, тихие часы (уважающие режим тишины из шага 1). - **Управление инициативой со стороны пользователя.** Под каждым инициативным сообщением — простой способ приглушить: либо всю инициативу целиком на время, либо конкретно этот повод, не трогая остальные. - **Блиц-анализ формулировок задач.** Короткая проверка ИИ, что формулировка задачи в списке достаточно конкретна и действенна — не расплывчатое "разобраться с X", а понятный следующий шаг. - **Разбор дня.** Текстовый анализ на основе журнала — по запросу или по расписанию — что происходило за день, какие паттерны видны. Архитектурное решение: бюджетирование инициативы (лимиты, кулдауны, тихие часы) должно быть отдельным слоем, через который проходит любое инициативное сообщение — а не разбросанной проверкой внутри каждого детектора. Иначе при добавлении нового повода легко забыть про лимиты. Шаг готов, когда: - фоновая проверка регулярно смотрит на данные и может решить, что есть повод написать первой; - инициативные сообщения ограничены бюджетом (частота, тихие часы) и не превращаются в спам; - пользователь может заглушить конкретный повод или всю инициативу отдельно от обычного диалога; - есть возможность получить текстовый разбор дня на основе журнала. --- ## Шаг 5. ИИ как собеседник в разных ролях Цель: от "замечает и сообщает" — к полноценному диалогу. Система становится настоящим собеседником, с характером, памятью и границами этой памяти, честно прописанными, а не подразумеваемыми. Реализуй: - **Несколько сменных характеров поверх одной памяти.** Разные голоса/роли ИИ-собеседника (например, энергичный прямой, спокойный взвешенный, циничный стратегический), которые пользователь может переключать. Переключение не начинает разговор заново — лента диалога и память остаются общими, меняется только характер ответа. - **Долговременная память с явными границами.** Нужно честно зафиксировать: что ИИ помнит всегда (отдельное постоянное хранилище, куда сам ИИ записывает то, что стоит помнить дольше одного разговора — договорённости, наблюдения, гипотезы) и что — только в пределах текущего окна (например, последние N дней журнала, последние M реплик диалога). Не весь исторический контекст разом. - **Два режима глубины ответа.** Короткий обмен ведётся налегке, без полного разворачивания характера и памяти; развёрнутый разговор раскрывает голос и контекст целиком. Переключение — по длине реплики или явным сигналом от пользователя, чтобы не тратить глубину (и стоимость вызова ИИ) там, где она не нужна. - **Чтение внешних материалов по запросу.** Возможность в разговоре попросить ИИ прочитать и учесть внешнюю ссылку или документ. - **Настраиваемый слой ИИ-провайдеров.** Модель и провайдер, стоящие за диалогом, должны быть заменяемым слоем под капотом, не зашитым намертво в логику диалога — на случай смены провайдера, отладки, экономии. - **Простые переключаемые роли для разового диалога.** Более лёгкий предок полноценного собеседника — разовый вопрос-ответ с выбранной ролью, без постоянной памяти и характера, для случаев, когда не нужен полный диалоговый режим. Архитектурное решение: границы памяти (что вечно, что временно) должны быть зафиксированы как явное архитектурное решение с первого дня — если оставить их неявными, велик риск либо утечки нерелевантного контекста в каждый запрос, либо потери важного факта, который нужно было запомнить навсегда. Шаг готов, когда: - пользователь может переключать характер собеседника без потери истории разговора; - у ИИ есть отдельное постоянное хранилище памяти, отличное от окна диалога, и explicit-правило о том, что туда попадает; - короткие обмены не расходуют полный контекст/бюджет, а развёрнутые — расходуют; - провайдер/модель ИИ можно сменить, не переписывая логику диалога. --- ## Шаг 6. Система документирует себя Цель: когда у продукта накопилось достаточно возможностей и голосов, он должен научиться объяснять сам себя — и тому, кто им пользуется, и тому, кто его создаёт. Реализуй: - **Справочник команд внутри интерфейса.** Библиотека глав/разделов, доступная прямо в самом продукте (не внешний сайт) — пользователь может полистать её, не выходя из диалога. - **Полный пользовательский гайд.** Исчерпывающий справочник функций для конечного пользователя — что есть и как этим пользоваться, живущий отдельно от кода, обновляемый при значимых изменениях. - **Этот самый исполняемый документ, рекурсивно.** Если ты, ИИ-строитель, довёл систему до этой точки — у неё уже достаточно возможностей, чтобы нуждаться в собственном документе такого рода: объясняющем архитектурную логику построения, который можно передать дальше. Шаг готов, когда: - пользователь может получить справку по функциям, не покидая интерфейс продукта; - существует отдельный документ, описывающий все функции для конечного пользователя, актуальный на момент завершения этого шага; - у системы есть документ уровня "как это построено", который можно передать другому ИИ-строителю для воспроизведения логики. --- ## Как использовать эти шесть шагов Это не жёсткий чек-лист, который нужно пройти буквально построчно. Адаптируй порядок и детали каждого шага под контекст, в котором ты работаешь — свой стек, своего пользователя, свои ограничения. Но сохраняй зависимость между шагами: каждый следующий шаг опирается на то, что дал предыдущий, и не имеет полного смысла без него. Пропуск шага 1 (независимое хранилище данных) обесценивает всё, что появляется в шаге 4 (ИИ, читающий эти данные) — доверие к выводам ИИ невозможно без доверия к тому, где физически лежат данные, на которых эти выводы строятся. Держи эту логическую цепочку в голове сильнее, чем порядок пунктов.