From 29bd0dbd18fb72cc2b27b2f5e45c53b7fc0b3fe4 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Sat, 3 Oct 2026 21:15:01 +0600 Subject: [PATCH] [2026-10-03] eagle: personal/plans/personal-os-operating-plan-2026-10-03.md personal/plans/personal-os-source-audit-2026-10-03.md --- .../personal-os-operating-plan-2026-10-03.md | 2 +- .../personal-os-source-audit-2026-10-03.md | 30 +++++++++++++++++++ 2 files changed, 31 insertions(+), 1 deletion(-) mode change 100755 => 100644 personal/plans/personal-os-operating-plan-2026-10-03.md create mode 100644 personal/plans/personal-os-source-audit-2026-10-03.md diff --git a/personal/plans/personal-os-operating-plan-2026-10-03.md b/personal/plans/personal-os-operating-plan-2026-10-03.md old mode 100755 new mode 100644 index 367accc3..17c42379 --- a/personal/plans/personal-os-operating-plan-2026-10-03.md +++ b/personal/plans/personal-os-operating-plan-2026-10-03.md @@ -53,7 +53,7 @@ mission: "[[personal/projects/personal-os/personal-os-purpose]]" 3. **Разбор расхождений.** Сначала исправлять неверный/устаревший источник, затем связь объектов, затем роль и приоритет, затем момент/формат обращения. Менять одно правило за раз; сохранить в `calibration_cases` и `calibration_changes` исходный пример, исправление и результат повторного прогона. Уточнение у Алекса только на естественном переходе и лишь когда неоднозначность меняет его план; в пилоте максимум один такой вопрос в день. 4. **Shadow-план и пятидневный пилот.** На двух днях воспроизвести решения без доставки и проверить H3; после согласованного включения короткой карточки проверить H2/H4/H5 на пяти рабочих днях. Ежедневно смотреть только критические ложные срочности и пропущенные обязательства; по завершении сравнить субъективный фокус/самочувствие, неплановые обращения, review minutes, границу дня и расход токенов. Если карточки не читаются или вредят фокусу, остановить доставку и исправить правило. Отсутствие обратной связи не считать согласием. -**Непосредственный следующий артефакт:** read-only аудит источников/адаптеров в отдельной параллельной задаче: `есть / нет / свежесть / достоверность / что требуется от Алекса / точная правка / проверка` для Asana, GitHub, браузера, worktrees и Codex/Claude/Balda. Его выводы уточняют P0.1, пока готовится baseline; аудит не включает автозапуск сборщиков. +**Аудит источников:** [[personal/plans/personal-os-source-audit-2026-10-03]] фиксирует `есть / нет / свежесть / достоверность / что требуется от Алекса / точная правка / проверка` для Asana, GitHub, браузера, worktrees и Codex/Claude/Balda. Его выводы уточняют P0.1; аудит не включал автозапуск сборщиков. ## 2. Что действительно есть 2026-10-03 diff --git a/personal/plans/personal-os-source-audit-2026-10-03.md b/personal/plans/personal-os-source-audit-2026-10-03.md new file mode 100644 index 00000000..784ded5e --- /dev/null +++ b/personal/plans/personal-os-source-audit-2026-10-03.md @@ -0,0 +1,30 @@ +--- +namespace: personal +tags: [personal-os, source-audit, focus] +date: 2026-10-03 +status: read-only-audit +plan: "[[personal/plans/personal-os-operating-plan-2026-10-03]]" +--- + +# Personal OS — аудит источников для P0 + +**Вывод:** технические факты уже собираются частично, но текущий feed не может надёжно ответить на два вопроса: **чем Алекс занят как рабочей темой** и **какого действия от него действительно ждут**. Это граница P0.1, а не повод включать старые briefs/Executor. Аудит выполнен чтением кода, локальной БД, ActivityWatch и проверкой доступа GitHub 3 октября; полнота каждого рабочего обязательства ещё не проверена по эталонной выборке. + +| Источник | Есть сейчас | Пробел, который влияет на P0 | Конкретная следующая правка и проверка | +|---|---|---|---| +| Asana | [`sync.js`](file:///Users/admin/Developer/personal-os/sync.js) читает мои, отслеживаемые, делегированные и проектные задачи, stories и часть зависимостей. `sync_state` для `my_tasks`, `following`, `delegated` обновлён 3 октября около 19:15 +06. В [`schema.sql`](file:///Users/admin/Developer/personal-os/schema.sql#L15) есть assignee, creator, due date, stories, edges и raw JSON. | [`generate-attention.js`](file:///Users/admin/Developer/personal-os/generate-attention.js#L125) считает любой чужой комментарий без моего ответа кандидатом «ответить»; это может быть FYI. [`asana.js`](file:///Users/admin/Developer/personal-os/asana.js#L57) сохраняет только первую 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`](file:///Users/admin/Developer/personal-os/gh-snapshot.js#L74) читает до 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`](file:///Users/admin/Developer/personal-os/aw-query.js#L269) совмещает foreground window с editor/browser событиями для агрегатов. | [`currentFocus`](file:///Users/admin/Developer/personal-os/aw-query.js#L319) выбирает Xcode→VS Code→DDG→window из последних 20 минут, а не последнее активное окно; app у VS Code обозначен `Cursor`. DDG URL сегодня недоступен, поэтому Asana/PR/статью в браузере нельзя надёжно привязать. [`aw-projects.json`](file:///Users/admin/Developer/personal-os/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`](file:///Users/admin/Developer/personal-os/aw-query.js#L262) агрегирует время. У старого 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`](file:///Users/admin/Developer/personal-os/aw-projects.json) есть несколько `namespace: personal` проектов и общий класс Documentation/Research. | Статья может быть рабочим исследованием, отдыхом или незапланированным переключением; приложение/домен не доказывают намерение или самочувствие. | `context_type=work_task|work_research|personal_project|leisure_or_break|unknown`; источник/уверенность отдельно. Попросить уточнение лишь когда оно меняет рекомендацию, не более одного в день в пилоте. | + +## Состояние запуска + +[`com.personalos.readonly.plist`](file:///Users/admin/Developer/personal-os/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 без новых уведомлений. Код, сервисы и внешние системы этим аудитом не изменены.