obsidian-vault/personal/plans/personal-os-source-audit-2026-10-03.md

namespace, tags, date, status, plan

namespace	tags	date	status	plan
personal	personal-os source-audit focus	2026-10-03	read-only-audit	personal/plans/personal-os-operating-plan-2026-10-03

Personal OS — аудит источников для P0

Вывод: технические факты уже собираются частично, но текущий feed не может надёжно ответить на два вопроса: чем Алекс занят как рабочей темой и какого действия от него действительно ждут. Это граница P0.1, а не повод включать старые briefs/Executor. Аудит выполнен чтением кода, локальной БД, ActivityWatch и проверкой доступа GitHub 3 октября; полнота каждого рабочего обязательства ещё не проверена по эталонной выборке.

Источник	Есть сейчас	Пробел, который влияет на P0	Конкретная следующая правка и проверка
Asana	sync.js читает мои, отслеживаемые, делегированные и проектные задачи, stories и часть зависимостей. sync_state для my_tasks, following, delegated обновлён 3 октября около 19:15 +06. В schema.sql есть assignee, creator, due date, stories, edges и raw JSON.	generate-attention.js считает любой чужой комментарий без моего ответа кандидатом «ответить»; это может быть FYI. asana.js сохраняет только первую project membership в нормализованных полях; источник обнаружения сводится к одному source. Нет структурированного owner/reviewer/advisor/observer, прямого запроса, ожидающего человека, последствий ожидания и confidence.	Добавить work_demand с role, requested_action, requester, due_evidence, evidence_gid/story_gid, confidence, observed_at; классифицировать assignment, mention, вопрос, dependency и FYI отдельно. Проверить 20 разных Asana событий по исходным stories: ложное «ответь» не проходит приёмку.
GitHub	gh-snapshot.js читает до 20 моих open PR с агрегированным CI/review decision. CLI авторизован; проверка 3 октября нашла 19 открытых PR в duckduckgo/apple-browsers.	Review requests берутся из notifications?all=false&participating=true и потому зависят от unread; team requests отбрасываются. reviewDecision и ci — агрегаты, нет модели новых review comments, конкретного required action, approval после последнего push, timestamps и независимого refresh state. Ограничение 20 PR близко к текущим 19.	Заменить notification-only review queue на запрос текущих reviewer assignments; отдельно получать reviews, unresolved threads, CI checks и head SHA для моих PR. Хранить fetched_at и ошибку по каждому потоку. Сверить set PR на ревью с GitHub UI/API, затем fixture: новый push после approval, failed CI, resolved/unresolved comment.
ActivityWatch, браузер и VS Code	Локальный AW отвечает. Buckets window/afk_Mac обновлены 3 октября около 21:08 +06; Xcode — 1 октября, VS Code — 2 октября, DDG URL — 8 июня. aw-query.js совмещает foreground window с editor/browser событиями для агрегатов.	currentFocus выбирает Xcode→VS Code→DDG→window из последних 20 минут, а не последнее активное окно; app у VS Code обозначен Cursor. DDG URL сегодня недоступен, поэтому Asana/PR/статью в браузере нельзя надёжно привязать. aw-projects.json классифицирует проекты по regex, не конкретные задачи и намерение.	Исправить Now по свежему foreground window + AFK, строго проверить перекрытие и freshness специализированных buckets; восстановить URL watcher либо пометить browser_url_unknown. Разбирать точные Asana task ID/PR number из URL; article URL связывать с задачей только при доказательстве. Проверить 20 интервалов, включая browser→Asana, lock, VS Code, статью и личный проект.
Git worktrees ↔ рабочая тема	Xcode watcher сообщает имя worktree/repo; aw-query.js агрегирует время. У старого Executor executor_runs хранит task_gid, worktree_path, branch_name, pr_url.	Нет общего индекса актуальных локальных worktrees, связей repo/worktree/branch/head SHA ↔ PR ↔ Asana task. Regex проекта не объясняет, что именно ревьюится или решается. Executor охватывает только собственные runs.	context-links.js: read-only git worktree list --porcelain по зарегистрированным репозиториям, branch/head SHA и явные PR/Asana ссылки; сохранять origin каждой связи и confidence. Проверить один PR с двумя worktrees и один worktree без PR; последний оставить unknown.
Codex/Claude/Balda и окна	Локальные Codex/Claude session JSONL существуют; metadata содержит cwd/git или cwd/gitBranch (без чтения бесед). Codex desktop даёт список задач со статусами active/idle/notLoaded. Старый Executor имеет отдельные run states и PR links.	Список задач не означает needs_human; desktop approval/request, завершённый результат и ответ нельзя вывести из mtime или idle. В Personal OS нет адаптера окон/сессий и единой review queue. Balda/Broker развивается отдельно, стабильный контракт пока не подтверждён.	session-observer.js читает только metadata и времена; agent-run-adapters.js принимает подтверждённые события running/blocked/needs_human/done, artifact URL, estimate review minutes и usage. Неизвестный approval = unknown. На двух одновременно активных агентах проверить отдельный agent time и один ограниченный human review slot.
Личный контекст	В aw-projects.json есть несколько namespace: personal проектов и общий класс Documentation/Research.	Статья может быть рабочим исследованием, отдыхом или незапланированным переключением; приложение/домен не доказывают намерение или самочувствие.	`context_type=work_task

Состояние запуска

com.personalos.readonly.plist описывает 30-минутный sync → status → attention, но 3 октября launchctl не нашёл загруженный com.personalos.readonly. Следовательно, свежие данные Asana были результатом разового запуска; регулярный refresh сейчас не подтверждён. GitHub и ActivityWatch доступны в read-only проверке, но это не означает, что Personal OS регулярно объединяет их в рабочую тему.

Минимальный сквозной пилот P0.1

Один реальный рабочий поток: Asana task с явным запросом к Алексу → связанный browser PR → локальный worktree → Codex/Claude run → итог, ожидающий его ревью. Система показывает текущую тему, источник запроса, свежесть, confidence и отдельно время человека/агента. Вторая ветка: статья или личный проект остаётся unknown/personal, пока нет доказательства намерения. Приёмка — 20 вручную проверенных интервалов из двух дней: ни одной ложной high-confidence связи и ни одного выдуманного needs_human.

Следующий шаг: согласовать конкретные правки P0.1 по этому аудиту, затем вести тихий baseline без новых уведомлений. Код, сервисы и внешние системы этим аудитом не изменены.