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

status, updated, canonical_source

status	updated	canonical_source
research-proposal	2026-10-04	/Users/admin/Developer/personal-os/planning/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 memory blocks, Khoj	Ограниченные блоки памяти, общая память для ролей; персональный поиск/агенты/автоматизации как доступный пользовательский продукт.	Нужен один короткий контекст для каждого сценария и удобный вход пользователя. Общая изменяемая память Letta имеет риск перезаписи; у нас blocks должны быть read-only проекциями принятых версий.
DBOS TypeScript, Temporal, LangGraph interrupts	Сохранение исполнения между шагами, ожидание человеческого решения, восстановление после сбоя.	DBOS — первый кандидат для ограниченной проверки совместимости с Node/TS + PostgreSQL. Temporal — полезный эталон гарантий, но отдельный сервис увеличивает эксплуатацию. LangGraph — кандидат для сложной логики агента, не ещё одна обязательная очередь поверх всего.
Timefold: replanning, Sunsama daily planning	Закрепление уже принятого плана, цена изменений, ограниченный дневной объём, начало/завершение дня.	Заимствуем поведение и ограничения; вводить Java solver или подписку для первого среза не требуется.
Screenpipe, Mem0 deletion	Доступ к личному контексту по приложениям/типам/времени; явные операции удаления памяти.	Перенимаем contract доступа и забывания. Полная запись экрана не нужна для нашей миссии по умолчанию; остаётся точечный сбор ActivityWatch/сессий/разрешённых источников.

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

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 берём уже известную цепочку Core Data: предложение → отмена → обновление project state → карьерный вклад без ложного implementation → agenda advisor. Она должна работать после нового transcript, backfill, restart и пользовательской коррекции. Затем добавляется незнакомый проект, чтобы результат не зависел от вручную заданных IDs.

Следующее действие реализации после принятия уточнения: создать этот воспроизводимый fixture и прогнать через минимальный context assembler; до расширения числа агентов измерить, находится ли отмена и получается ли корректный итог.