obsidian-vault/personal/projects/personal-os/personal-os-best-practices-2026-10-04.md

Personal OS — внешнее сравнение и конкретные поправки к R2

Дата проверки: 2026-10-04. База сравнения: миссия Personal OS, system-review R2, graph-design R2, проекты промптов и текущий package.json. Изучены официальные документы и публичные репозитории; продукты не устанавливались и сравнительный benchmark на наших данных не запускался. Ниже — инженерные выводы для нашего случая, а не рейтинг универсально «лучшей системы».

Главное: у R2 сильная модель происхождения и времени, но недостаточно специфицированы поиск решающих свидетельств, цена человеческого review, устойчивость планирования, возобновление длинного процесса и полный жизненный цикл памяти. Код дополнительно отстаёт от собственного плана: общий граф, semantic runner и пользовательский цикл ещё не внедрены. Эти два вида отставания различаются.

1. Какие системы полезны как образцы

Класс и первичные источники	Практика, которую стоит перенять	Применимость к Personal OS
Graphiti, код search recipes	Temporal facts с provenance; несколько способов retrieval и reranking.	Модель времени у нас уже заложена. Недостаёт измеримого retrieval и сборки контекста. Библиотека требует дополнительного runtime/backend; её установка не заменяет наши правила принятия истины.
Актуальная Letta Code, Khoj	Постоянный контекст агента; персональный поиск/агенты/автоматизации как доступный пользовательский продукт.	Нужен один короткий контекст для каждого сценария и удобный вход пользователя. Letta теперь использует редактируемую MemFS; прежние V1 memory blocks — исторический пример, не текущий integration contract. Наш принятый контекст должен предоставляться как versioned projection через evidence API.
DBOS TypeScript, Temporal, LangGraph interrupts	Сохранение исполнения между шагами, ожидание человеческого решения, восстановление после сбоя.	DBOS — первый кандидат для ограниченной проверки совместимости с Node/TS + PostgreSQL. Temporal — полезный эталон гарантий, но отдельный сервис увеличивает эксплуатацию. LangGraph — кандидат для сложной логики агента, не ещё одна обязательная очередь поверх всего.
Timefold: replanning, Sunsama daily planning	Закрепление уже принятого плана, цена изменений, ограниченный дневной объём, начало/завершение дня.	Заимствуем поведение и ограничения; вводить Java solver или подписку для первого среза не требуется.
Screenpipe, Mem0 deletion	Доступ к личному контексту по приложениям/типам/времени; явные операции удаления памяти.	Перенимаем contract доступа и забывания. Полная запись экрана не нужна для нашей миссии по умолчанию; остаётся точечный сбор ActivityWatch/сессий/разрешённых источников.

Это образцы отдельных частей. Проверенные источники не устанавливают, что какой-либо из этих продуктов уже решает нашу миссию целиком или лучше работает на данных Алекса.

Дополнение 04.10: сравнение готовых систем и навыков рассматривает LifeOS/PAI как кандидат пользовательского слоя, проверку его Atlas/TELOS и конкретный shortlist повторного использования. V1 Letta server перемещён в archive — обновлено выше по текущему upstream.

2. Пять существенных поправок

A. P0 — поиск доказательств и сборка контекста

Что уже есть: identifiers, full-text, bounded traversal, immutable packets, source spans, lineage. Чего не хватает: контракт выбора содержимого packet, отдельная проверка retrieval recall и обязательный поиск опровержений. Иначе поздняя отмена может существовать в БД, но не попасть к аналитику — прежняя ошибка Core Data повторится.

Graphiti содержит разные search recipes; Anthropic context engineering описывает ограниченность контекста, адресную подгрузку и сжатие истории. Наш вывод: нужен context assembler как функция evidence core, а не новая БД или постоянно работающий агент.

Конкретное решение для плана:

1. Packet содержит пять секций: подтверждённые цели/ограничения пользователя; текущее состояние scope; релевантные новые события; отмены/конфликты/контрсвидетельства; адреса дополнительных источников с coverage. Для секций задаются лимиты и hash версии.
2. Retrieval выполняет exact IDs → text search → bounded graph paths → отдельный запрос поздних решений/отмен → rerank/dedup. Vector search добавляется только после сравнения с этим baseline. Scope/time/permissions фильтруются до ranking.
3. Context assembler записывает, какие records включены/исключены и почему; обязательное контрсвидетельство не вытесняется общим лимитом top-k. Если необходимое основание не помещается, возвращается gap или запускается bounded follow-up packet; текущий вывод остаётся unknown.
4. Project/career summaries являются materialized views с input revision IDs. Новое решение делает summary stale; автоматическое переиспользование stale summary запрещено. Цели/предпочтения — versioned user state; поведение человека не переписывает их автоматически.
5. Возобновление работы использует маленькую карточку: где остановился, последний принятый результат, нерешённый вопрос, следующий шаг и ссылки. Это производная истории; она не становится новым доказательством самой себя.

Приёмка BP-A, R2→R3: отмена спрятана среди нерелевантных похожих документов; находится при разных формулировках и позднем backfill. На наборе с размеченными обязательными источниками измеряются recall retrieval, recall контрсвидетельств, citation correctness и итоговый статус раздельно. Фиксированные критические случаи требуют полного набора решающих evidence; top-k hit по одному удобному источнику недостаточен.

B. P0 — автономность без бесконечного человеческого review

Что уже есть: manual semantic acceptance в пилоте, reviewer budget, scoped feedback. Недосмотр: blanket review всех смысловых claims может сделать Алекса главным обработчиком очереди, а accepted-only consumers — почти бесполезными. Сам budget предотвращает перерасход, но не определяет, как выбирать полезное ревью.

LangGraph interrupts даёт сохраняемую паузу и возобновление; предупреждает о повторном исполнении кода при resume. Это механизм, а выбор того, что стоит показывать человеку, должен определяться нашим продуктом.

Конкретное решение: сохраняем независимые поля evidence_kind = observed/reported/inferred и review_status. Достоверно извлечённая цитата «на встрече сказано X» не равна утверждению «X внедрено». Точные API facts принимает код; смысловые candidates в пилоте принимаются человеком. Непринятые candidates доступны в раскрываемом разделе и для дальнейшего поиска, но не меняют обязательства/факт внедрения/решение о внешнем действии.

Review queue группирует связанные candidates по решению, показывает evidence и цену ошибки; порядок: ближайшее реально зависящее решение → последствия ошибки → цена проверки. Нет запроса, если ответ не меняет предстоящего действия. При исчерпании бюджета остается unknown и безопасный доступный план. Автоматическое принятие разрешается по одному оценённому классу и policy version; confidence модели не служит порогом доверия.

review_requests хранит target/input hash/policy version, варианты ответа, expires_at, state pending/answered/expired/superseded. Resume проверяет актуальность основания и полномочий; новая отмена делает старый approve неприменимым. Повторный ответ не дублирует публикацию. Это расширение существующих job/feedback contracts, а не отдельная система правды.

Приёмка BP-B, R3: поток из 100 candidates укладывается в согласованный лимит reviewer minutes; проверяется, что важный вопрос показан, а остальные не порождают поток уведомлений. Restart во время ожидания сохраняет запрос. Ответ после изменения evidence не принимает старый claim. Качество измеряется одновременно по ошибкам, полезному покрытию и нагрузке: «всё unknown» не проходит.

C. P0 — планнер управляет посильным и устойчивым планом

Что уже есть: constraints, вместимость, current focus, перерывы, end-of-day, defer и reviewer load. Недосмотр: слова «важность / цена переключения» ещё не задают алгоритм; при каждом событии LLM может менять рекомендацию. Личный отдых указан в миссии, но модель в основном наполнена рабочими demands.

Timefold явно разделяет ограничения разных уровней, непомещающуюся работу и цену перепланирования. Sunsama включает дневной объём и shutdown. Наше решение переносит эти принципы в небольшой детерминированный planner.

Конкретное решение: обязательные ограничения имеют лексикографический приоритет над score полезности. Время отдыха, личные блоки, встречи, конец дня и уже принятый focus block — реальные planning objects. После их вычитания выбираются доступные действия; непомещающиеся получают unassigned с причиной и последствием. Deadline сам по себе не снимает ограничение вместимости.

Начатое/подтверждённое действие закреплено до конца блока или команды пользователя. Новое обычное событие обновляет очередь, но не переключает фокус. За пределами закреплённого окна смена рекомендации требует выигрыша над explicit switching cost; сравнение причин хранится в decision. Критический override имеет отдельное принятое правило.

Оценка длительности — диапазон с источником и наблюдаемой ошибкой; calibration по типам работ, не по foreground app time. План резервирует место на неопределённость; точный buffer выбирается в pilot policy. Reviewer debt включается как оставшиеся человеческие минуты, а не число готовых агентных файлов.

Приёмка BP-C, R1 основа / R4 расширение: 10 несущественных событий не меняют закреплённый фокус; overload оставляет часть задач unassigned без нарушения границы дня; личный блок не вытесняется накопленными рабочими score. Длительности сравниваются с подтверждёнными исходами; unknown interval не записывается как нулевая работа. В UI виден путь «почему эта задача / почему сейчас / что перенесено».

D. P0 — возобновляемое исполнение и ранняя проверка готовой библиотеки

Что уже есть: outbox, idempotency, lease fencing, retry, catch-up, code versions. Недосмотр: R2 фактически планирует свой небольшой workflow engine, но не задаёт историю шагов, ожидание review, правила code upgrade и ambiguous external outcome. Job lease не равен сохранению всего процесса.

DBOS workflows сохраняют выполненные шаги; steps могут повторяться при сбое. Версионирование workflow требует отдельной дисциплины. Temporal — другой пример history/replay. Эти гарантии не означают однократный внешний эффект на произвольном сервисе.

Конкретное решение для порядка реализации: до custom lease/checkpoint engine выполнить короткую техническую проверку DBOS на fixtures. Recommendation: TypeScript + PostgreSQL остаются, launchd отвечает за жизненный цикл процесса; library отвечает за workflow/queue. Проверяются local deployment, schema isolation, recovery, version upgrade, bounded concurrency, ожидание человека, traces и rollback. Пока эта проверка не пройдена, DBOS — кандидат, а не принятая новая зависимость.

Интерфейс WorkflowRuntime фиксируется независимо от кандидата: start/get/cancel/resume, stage result, workflow/code/policy version, immutable packet reference. Domain tables остаются нашим контрактом. Состояние lease/step хранит один владелец, а job_runs проецирует наблюдаемый результат — без двух конкурирующих очередей.

Для будущих внешних действий adapter хранит operation key, approval scope/version, provider receipt, verify query и результат succeeded/failed/unknown. После timeout с неизвестным эффектом выполняется reconciliation, а не слепой повтор. Отмена workflow не обещает отменить уже сделанную внешнюю запись. На replay LLM-результат читается из сохранённого шага; повторный inference — новая явно учтённая попытка.

Приёмка BP-D, R1 spike / R3 runtime: остановка процесса между fetch/analysis/review/publish; restart и resume; истёкший worker; новая версия кода при старом pending run; revoke policy перед commit; provider timeout после возможного успеха. Результат — сохранённый verdict по каждому случаю. Установка библиотеки и новый scheduler здесь не выполнялись.

E. P0/P1 — проверка реальной пользы и жизненный цикл личной памяти

Что уже есть: AC01–16, holdout, provenance, privacy classes, restore. Недосмотр: нет операционного eval-набора и отдельных метрик поиска/вывода/плана; хорошие цифры можно получить, оставив всё unknown. SC3 измеряет часть пользы, но почти не измеряет время обслуживания самой OS. Append-only история без forget contract конфликтует с управляемой личной памятью.

LongMemEval проверяет извлечение, несколько сессий, обновления знания, время и abstention. Anthropic evals разделяет итоговое состояние, траекторию и повторяемость; предлагает начинать с небольшого набора реальных случаев. Наши рабочие кейсы остаются основным holdout, публичный benchmark — дополнительной проверкой класса способности.

P0 eval design: 30–50 фиксированных случаев до prompt tuning, отдельные development/holdout sets. Сюжеты: proposal→отмена, идентичные названия, косвенная связь, цепь сессий, неполный источник, отсутствующий ответ, overload, false urgency, удалённые данные. Записывать retrieval recall, precision/recall принятых claims, долю actionable случаев с полезным ответом, unknown rate, plan violations, число переключений/прерываний и reviewer minutes. Для критических nondeterministic cases — три повторных прогона и все результаты, без выбора удачного. Эти количества — предложенная стартовая конфигурация, не доказательство production-качества.

Каждое исправление пользователя становится replay case с исходным input, ожидаемым поведением и scope коррекции. Ретро предлагает одну проверяемую гипотезу, сравнивает с фиксированным baseline и учитывает meeting load/coverage. Пять дней pilot дают предварительный продуктовый verdict, не причинное доказательство карьерного роста. Новая полезная метрика: ручные минуты на поиск контекста + обслуживание OS + ревью агентов в сравнении с baseline; не требовать длинного ежедневного отчёта.

P1 память и доступ: Screenpipe показывает фильтры по приложениям/типам/времени и enforcement вне prompt; Mem0 — явное удаление выбранной памяти. Наш контракт: access_policy_version проверяется до retrieval, при resume и delivery; «забыть» покрывает raw spans, summaries, embeddings, exports/cache и производные claims. Tombstone/source delete, истечение retention и явное erase — разные события. Историческая публикация после erase показывает redacted/missing evidence, а не восстанавливает удалённый текст.

Для backups нужен срок хранения и журнал erase, применяемый при restore до открытия API; UI раскрывает, какие offline/exported копии нельзя отозвать автоматически. Append-only сохраняет историю решений, но допускает санкционированное удаление содержимого; физическое удаление выполняется только после отдельного подтверждения. Текущая работа ничего не удаляет.

Приёмка BP-E: balanced replay не проходит со стратегией «всё unknown»; запрещённый record отсутствует уже в retrieved packet. Erase test проверяет поиск, summary, граф, кеш и restore; содержимое не возникает снова. Сохранённый evidence без разрешения на чтение не считается открываемым доказательством для данного consumer.

3. Что в R2 уже соответствует практикам

Сильная сторона плана	Что сохраняем
Evidence и время	Source spans, valid/system time, lineage, late events, конфликт вместо ложной уверенности.
Границы системы	Один PostgreSQL truth store, клиенты как проекции, роли без обязательных микросервисов, инструменты ограничены runner-ом.
Явные статусы	Proposal, decision, implementation, merge, release и impact раздельны; closed task не доказывает внедрение.
Контроль внимания	Scoped feedback, delivery gates, ручные цели/энергия, reviewer budget, защищённая граница дня.
Последовательность	Первый Mac-срез и iPad отдельно; измеримая приёмка, shadow, restore и rollback.

Оценка «заложено в плане» не означает «работает». Переход на Neo4j, векторную БД, n8n или полную Swift-перепись не исправляет BP-A–E автоматически. Заимствуем проверяемое поведение; новую зависимость выбираем по нашему fixture и эксплуатационной цене.

4. Конкретный diff roadmap для согласования

Этап R2-плана	Уточнённый результат
R0	Принять BP-A–E как дополнение к контрактам; отдельно зафиксировать budget/review/data retention.
R1	Вертикальный срез остаётся первым; добавить policy стабильного фокуса, overload/unassigned, minimum replay fixtures и bounded DBOS compatibility spike до собственного workflow engine.
R2	К графу добавить context assembler, summary invalidation, permission-aware retrieval, модель целей/личных блоков и erase design до накопления большого архива.
R3	К runner/prompts добавить durable review_requests, поэтапное принятие классов, retrieval+semantic eval и saved step results.
R4	Закрыть BP-C/E: стабильность плана, суммарная человеческая нагрузка, counterexample replay, memory erase/restore и bounded change experiments.

Для end-to-end eval нужен независимый набор по нескольким направлениям: тихие обязательства, косвенная ответственность, отменённые решения, платформенные варианты одной темы, последовательности встреч и неизвестность из-за неполного источника. Один ранее найденный эпизод не определяет ни эталон, ни вывод о карьерном вкладе.

Следующее действие реализации: доказать покрытие выбранных проектов и сохранить все memberships; затем сравнить компоненты на разнообразном эталоне. Подробный алгоритм и приёмка — шесть уровней Personal OS.

Уточнение следующего этапа

Исследование понимания потока работ конкретизирует ещё не доказанную часть: покрытие большого корпуса, извлечение и разрешение связей, временные состояния и приоритеты относительно роли. Следующий этап — WG-0, до сравнения оболочек.