obsidian-vault/personal/projects/personal-os/personal-os-architecture-decision-2026-10-04.md

status, updated, canonical_source

status	updated	canonical_source
draft-review	2026-10-04	/Users/admin/Developer/personal-os/planning/personal-os-architecture-decision-2026-10-04.md

Personal OS — архитектурное решение для согласования

Полный аудит, роли, промпты, фактические расписания, схема данных и план приёмки: системное ревью R1. Его разделы 05 и 15-16 уточняют пробелы раннего graph DDL; целевые решения по-прежнему не утверждены.

Детальная модель БД, правила связывания Asana/GitHub/Zoom/сессий и экран графа: проект графа доказательств. Он также ожидает согласования.

Статус: проект решения, не утверждён · 2026-10-04. Этот документ не разрешает запуск агента, установку расписания, миграцию базы, доставку карточек или запись в рабочие сервисы. Текущие ограничения и цель: миссия в Obsidian, действующий operating plan, проектная правда.

1. Выбор оркестрации

Вариант	Польза	Цена для Personal OS	Решение
Кастомное модульное ядро Node/TypeScript + PostgreSQL + launchd	Повторное использование действующих Asana, GitHub, ActivityWatch, Zoom и Mattermost адаптеров; доменные правила, тесты и версии в одном репозитории	Нужно самим сделать очередь запусков, мониторинг, админ-экран и восстановление	Рекомендация для ядра, ожидает согласования
n8n как центр	Графическое построение интеграций, история и повтор неудачных workflow (документация n8n)	Второй runtime и отдельная конфигурация; локальные Chrome-профили, ActivityWatch, доказательства и планнер всё равно остаются кастомным кодом	Возможен позже для периферийных интеграций, не как источник истины
Node-RED как центр	Удобен для событийных потоков и простых интерфейсов	Состояние context по умолчанию живёт в памяти; сохранение на диск настраивается отдельно (документация Node-RED); доменная модель и проверки всё равно кастомные	Не рекомендован как ядро

Рекомендация: не переписывать работающие Node-адаптеры. Вынести бизнес-правила в модули TypeScript, оставить PostgreSQL каноническим журналом и состоянием, а JSON — версионированной проекцией для интерфейсов. launchd на Mac запускает и контролирует процесс; очередь работ хранит статус/попытки в базе. Без Redis и отдельного визуального оркестратора на первом production-срезе. Переход с нынешнего JavaScript на TypeScript выполняется постепенно, после контрактных тестов. Это предложение, не принятое решение.

2. Границы системы и владельцы данных

• Asana владеет задачами, назначениями, комментариями и явными запросами; GitHub — состоянием PR, review, CI и merge; Zoom — текстом беседы и временем высказываний; Obsidian — заметками и подтверждёнными человеком решениями. Более свежий источник не становится автоматически более авторитетным для чужой сущности.
• ActivityWatch фиксирует приложение, окно и AFK, но не цель человека и не самочувствие. Энергию, фокус и границу рабочего дня задаёт Алекс добровольно. Календарь остаётся unknown, пока не подключён подтверждённый read-only путь.
• Агентные платформы дают явные run/status/approval/usage; отсутствие подтверждённого адаптера означает unknown, не «ждёт Алекса». Balda/Broker/Virfield подключаются только через принятый интерфейс, не становятся хранилищем Personal OS.
• PostgreSQL содержит версии фактов, связей, решений, планов, предложений и обратной связи. Obsidian остаётся читаемой памятью и проектной документацией, не скрытым runtime-хранилищем. JSON-файлы — проекции одной опубликованной версии, не конкурирующие источники истины.

3. Data flow и запуск

Источник → read-only адаптер → raw reference + нормализованное событие
                           → link candidates → подтверждённый граф проектов/тем
                           → evidence timeline (PostgreSQL, append/versioned)
                           → проектный аналитик + детерминированная проверка
                           → validated project_state
                           → work_demand + календарь/энергия/фокус/agent review queue
                           → planner → версия focus_state + рекомендации
                           → пользовательский интерфейс → явная коррекция/действие
                           → feedback log → retrospector → change proposal
                           → тест/shadow/review → следующая версия правил

Каждая запись содержит source, внешний ID/URL, время события и получения, внутренний project_id/work_thread_id, тип утверждения, область действия, уверенность и происхождение связи. Связывание сначала опирается на точные URL/ID; смысловое совпадение остаётся кандидатом до доказательства. Сырые полные Zoom-транскрипты не копируются в карточки и внешние каналы. Дубликаты обрабатываются идемпотентно по source ID и версии.

Новые факты, пользовательская коррекция и естественный переход рабочего контекста вызывают пересчёт затронутых состояний. Периодический read-only обход обнаруживает пропущенные изменения. Один run_id/state_version связывает опубликованные projects, focus и attention; потребитель не смешивает снимки разных запусков. Ошибка источника сохраняет последнюю известную версию с stale/unknown и причиной. Повторы ограничены, не создают дубликатов или бесконечного respawn. Расписание конкретных анализов остаётся предметом отдельного согласования.

4. Контур планнера

Вход: validated project_state, work_demand с ролями и последствиями ожидания, явный фокус Алекса, календарь если подтверждён, добровольная энергия, конец рабочего дня, перерывы, история переключений и подтверждённая очередь агентного ревью. Неизвестное не заполняется догадкой.

Детерминированная часть вычисляет доступные окна и защищает границы дня, перерывы и reviewer slot. Агентная часть предлагает максимум три действия делать сейчас / выделить окно / делегировать / ждать / перенести с причиной, длительностью, ссылками и риском ожидания. Валидатор проверяет сроки, роль, источники и ёмкость. Выход: версия focus_state с основной темой, одним ближайшим действием, переносами и временем следующего естественного пересмотра. Во время focus/meeting обычные изменения копятся молча. План перестраивается после явной коррекции, важного нового факта или окончания блока, а не после каждого события.

5. Контур ретроспектора и доработки

Ежедневно система локально сравнивает план с подтверждённым фактом: что осталось открытым, где была ложная срочность, насколько прогноз минут ревью и длительности совпал, как часто Алекс исправлял или игнорировал карточку. Отсутствие отклика не трактуется как согласие. Самочувствие — только добровольный самоотчёт, не вывод из ActivityWatch.

На недельном горизонте ретроспектор показывает 1–3 подтверждённых паттерна: пропущенные обязательства, повторяющиеся переносы, фрагментацию тем, перегрузку ревью, карьерные факты и качество источников. Для каждого — evidence и возможная причина; затем одно предложение изменения правила. Старый agent/prompts/retrospector.md, рассчитанный на отключённый Zulip/Hermes и corrections_log, не является действующим runtime-контуром.

Доработка: correction → воспроизводимый case → предлагаемое изменение кода/правила/промпта в отдельной ветке → тест + сравнение shadow до/после → review → версионированный выпуск → мониторинг и rollback. Агент может готовить изменение, но не меняет production-правило, расписание, канал доставки или внешние рабочие данные без согласованной границы полномочий. У каждой рекомендации и изменения есть owner, версия, причина и результат проверки.

6. Взаимодействие с Алексом

Рекомендуемый режим для согласования: один короткий экран Сейчас / что изменилось / одно следующее действие / почему / свежесть; максимум три действия раскрываются по запросу. Алекс может одним действием принять / неверно / слишком много / отложить / сменить фокус / конец дня. Коррекция применяется к следующему расчёту и видна как «исправлено». Вопрос задаётся только если ответ реально меняет план, в пилоте не чаще одного в день. Во время подтверждённого focus block, встречи и после рабочего дня обычных уведомлений нет; критическое исключение требует источника, владельца, последствия ожидания и срока.

Предложение канала: локальный экран на Mac для первого пилота; затем тонкий iPad-клиент над тем же ограниченным API с офлайн/устаревшим состоянием. Mattermost или push не включать без отдельного выбора канала и порога прерывания. Подготовка к career advisor call — производная карточка из подтверждённых карьерных фактов и project_state, не отдельный независимый вывод из сырых задач.

7. Критерии production v1 — предлагаются к согласованию

1. Правда и свежесть. Все уверенные проектные/рабочие утверждения имеют проверяемые source refs; в проверенной выборке нет ложных high-confidence привязок или статусов. Пропавший источник даёт unknown/stale. Asana/GitHub high-priority сигнал во время работы обновляется в пределах 15 минут, Zoom — к следующему рабочему утру после доступного transcript. Все интерфейсы используют один state_version.
2. Полезный план. Два рабочих дня shadow и минимум 20 вручную проверенных интервалов проходят без ложной уверенности. Пятидневный пилот показывает важные обязательства без пропусков, посильный план с перерывом и границей дня, меньше неплановых обращений к Алексу относительно baseline и отсутствие ухудшения добровольной оценки самочувствия.
3. Внимание и контроль. Одна карточка помещается на экран, обычные события не прерывают focus/meeting/после работы, исправление занимает до 10 секунд и влияет на следующую версию плана. Пользователь видит источник и может отменить/переопределить решение.
4. Автономность и восстановление. Десять последовательных рабочих дней без ручного перезапуска и тихих провалов; есть статус каждого источника и запуска, alert только на реальные отказы, ограниченные повторы, резервная копия и проверенное восстановление состояния, replay без дублей, откат предыдущей версии правил/кода.
5. Безопасная поставка. Исполняемый код привязан к известной ревизии и автоматическим тестам; нет запуска из произвольного грязного worktree. Ключи вне артефактов; локальные персональные данные не уходят в рабочие каналы. Внешние записи и сообщения требуют явно согласованной политики. iPad-клиент и основной экран показывают одну и ту же версию и честный offline/stale.

Это проверяемые предлагаемые пороги. Их надо утвердить или изменить до маркировки системы как production. Отдельные более ранние срезы могут быть полезны в shadow/pilot, но не получают статус production v1.

8. Открытые решения для Алекса

1. Ядро: принять Node/TypeScript + PostgreSQL + launchd как основной стек или выбрать n8n/Node-RED/гибрид.
2. Канал первого пользовательского пилота: локальный экран Mac, iPad или личный Mattermost; отдельно — режим критических прерываний.
3. Граница автономности: какие read-only агентские анализы допускаются вручную и когда обсуждать регулярный запуск; внешние записи остаются отдельным решением.
4. Порог production v1: подтвердить или скорректировать численные критерии раздела 7.

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