[2026-10-03] eagle: personal/projects/personal-os/personal-os-purpose.md

This commit is contained in:
Alexey Martemyanov committed 2026-10-03 20:19:15 +06:00
1 parent 5aa849a0ea
commit da6e668d5f
1 file changed
+38 -50
+38 -50
View File
@@ -1,73 +1,61 @@
--- ---
namespace: work namespace: work
tags: [system, purpose, adhd, design] tags: [system, purpose, mission, adhd, design]
last_updated: 2026-04-28 last_updated: 2026-10-03
confidence: 1.0 confidence: 1.0
status: current-mission
--- ---
# Personal OS — Purpose # Personal OS — миссия и главные цели
## Why It Exists > Эта миссия уточнена Алексом 2026-10-03. Она задаёт цель новой системы. Описание старых агентов и каналов в [[personal-os-architecture]] — история выключенной реализации, а не задание на её восстановление. Текущий статус: [[personal-os-status-2026-10]].
Alex is a macOS Browser Developer / DRI at DuckDuckGo. Async-first company, primary channels Asana and Slack. ADHD profile. ## Миссия
The Personal OS exists to hold work context **outside Alex's head** — so that context isn't lost during deep focus, transitions, or when switching back from a meeting. **Personal OS координирует внимание, нагрузку и рабочий контекст Алекса так, чтобы он хорошо себя чувствовал, мог глубоко работать, сохранял баланс жизни и работы и устойчиво улучшал рабочие и карьерные результаты.** Система держит контекст вне головы Алекса, помогает выбрать посильный фокус дня, защищает его, возвращает к задаче после переключения и берёт на себя анализ, который не требует решения человека.
Without it, three things happen regularly: Это персональная система поддержки решений и исполнения, а не генератор длинных статусов. Её качество определяется тем, уменьшились ли переключения, перегрузка и ручная координация при сохранении важных обязательств. Рост числа задач, сообщений и агентных результатов сам по себе не считается улучшением.
1. A comment sits on an Asana task for days — Alex never saw it because he was in Xcode
2. A career-level task (Ship Review, Tech Design review) gets deferred until it becomes a bottleneck
3. End of day: "what did I actually do today?" — no clear answer, no signal for tomorrow
## Design Principles ## Приоритет целей — в указанном порядке
**Principle 1 — Context is the product, not notifications.** 1. **Самочувствие.** Учитывать явно указанное настроение/энергию и возможность отдыха. ActivityWatch не может достоверно вывести самочувствие сам по себе. Плохое самочувствие уменьшает предлагаемый объём работы, а не создаёт долг «догнать план».
The system's job is to maintain a live, accurate picture of what's happening. Eagle reads that picture and speaks when something actually matters. It is not a notification firehose. 2. **Качество фокуса и посильная нагрузка.** Учитывать текущую работу, время на погружение, переключения, встречи, перерывы, дедлайны и доступные окна. План дня меняется вместе с реальностью; система показывает одну обоснованную рекомендацию, а не навязывает жёсткое расписание.
3. **Баланс жизни и работы.** Защищать перерывы, окончание рабочего дня и личное время; не превращать свободное время в автоматически доступный ресурс для рабочих или агентных задач.
4. **Работа и карьера.** Не пропускать реальные обязательства в Asana, PR/review и встречах; сохранять подтверждённые результаты, вклад и возможности роста, чтобы они не терялись за текущей срочностью.
**Principle 2 — Protect focus.** Эти цели образуют порядок принятия решений: система не оптимизирует рабочие метрики ценой ухудшения первых трёх пунктов. Алекс всегда может вручную изменить приоритет, уровень энергии или режим дня.
If Alex is in Xcode or Cursor, don't interrupt unless there's a red signal older than 3 hours. ADHD makes context switches expensive — the system should absorb noise, not amplify it.
**Principle 3 — No hallucinated state.** ## Что система должна понимать
Eagle never guesses about Asana tasks. All Asana data flows through sync.js → PostgreSQL → generate-status.js → status.md. Eagle reads markdown, not the API. This means the data is always consistent and never stale by more than 30 minutes.
**Principle 4 — Career goals are first-class.** - **Рабочие обязательства:** Asana — основной источник задач, назначений, комментариев и сроков; GitHub — PR, CI, review requests и ожидание ответов. Ни просрочка, ни комментарий сами по себе не доказывают срочность.
The system explicitly tracks: Project Advisor opportunities, visibility gaps (Ship Reviews where Alex hasn't commented), Tech Design reviews pending. These surface in status.md and the daily brief. Without explicit tracking they'd be invisible. - **Фактическая работа и контекст:** ActivityWatch (активное приложение, AFK, окна работы, перерывы, переключения), Xcode/Cursor и git worktrees, соответствие worktree ↔ PR ↔ задача/проект; сессии Codex/Claude как работа над проектом, а не автоматически работа Алекса.
- **Ритм дня:** подтверждённые встречи, Zoom-записи/транскрипты, окна между встречами, время на переходы и восстановление контекста. Существование записи не означает, что она уже импортирована.
- **Человеческая сторона:** настроение и энергия по желанию Алекса, заданный им фокус, доступное время и граница рабочего дня. Отсутствие самоотчёта — «неизвестно», а не «энергии достаточно».
- **Нагрузка от агентов:** ожидаемое время ревью и число результатов, которые ждут Алекса; стоимость, токены, длительность и повторы агентных задач.
**Principle 5 — No new infra.** ## Основной контур — управление фокусом
The system has enough moving parts. New capabilities go into existing components: Postgres tables, generate-status.js queries, prompt files in `agent/prompts/`, SOUL.md rules. No new YAML files, no new shell scripts, no new launchd plists unless there is no other way.
## The Four Agents 1. Система поддерживает живую картину: что Алекс делает сейчас, что важно сегодня, что ждёт его, что может подождать, насколько план посилен при текущей энергии и календаре.
2. Во время глубокого фокуса и встреч она копит изменения и бережёт внимание. Исключение для действительно критического сигнала задаётся явным правилом с доказательством; старое правило «красный сигнал старше трёх часов» — исходная гипотеза для проверки, а не универсальная команда прервать работу.
3. На естественном переходе она даёт короткую карточку: где остановился, что изменилось, что разумно сделать дальше, почему, сколько это займёт. Рядом — возможность отложить, сменить фокус или снизить план.
4. В конце дня она фиксирует фактическую работу и доказательства вклада без оценки «успешности» по числу активных минут. Если день был тяжёлым, результатом может быть сохранённый контекст и защищённое восстановление.
| Agent | Role | When | ## Кодинговые и аналитические агенты — подчинённый контур
|-------|------|------|
| **Стратег (Strategist)** | Data pipeline — reads Asana + ActivityWatch, writes status.md | Every 30 min, workdays |
| **Орёл / Eagle (Tactician)** | Discord-facing reactive agent — briefs, inbox, focus gating | Cron + on-demand |
| **Ретроспектор (Retrospector)** | Weekly pattern analysis — corrections, quadrant drift, visibility | Friday 17:30 |
| **Исполнитель (Executor)** | On-demand bug-fix worker — analysis → fix → PR → CI loop | Explicit trigger only |
Eagle is the only agent Alex directly talks to. The others are background infrastructure. Агенты могут исследовать, программировать и проверять задачи. **Их выпуск — нагрузка на Алекса как reviewer**, а не бесплатный результат. Координатор запускает/продолжает агентную работу лишь в пределах доступного бюджета: токены/деньги, время машины, число одновременных задач и ожидаемые минуты человеческого ревью. Если очередь ревью заполнена или день тяжёлый, новые результаты не должны забивать вход Алекса; задачи остаются в очереди или готовятся без требования немедленного просмотра.
## What "Work Context" Means Каждый агентный результат должен иметь проверяемый артефакт, краткое объяснение, результат проверки и оценку времени ревью. Повторяющаяся без прогресса попытка останавливается по лимиту. Внешняя публикация и запись в рабочие системы требуют отдельного разрешения. Контур разработки Personal OS, Zoom-импорт и iPad-клиент важны, но их очерёдность подчинена пользе для фокуса и баланса.
The system tracks four categories, mapped to `activity_daily.quadrant`: ## Как понять, что миссия выполняется
| Quadrant | What it covers | Why it matters | - Алекс субъективно отмечает, что план посилен и ему легче удерживать фокус; короткий добровольный отклик важнее вывода из телеметрии.
|----------|---------------|----------------| - Во время фокусного блока нет обычных прерываний; после встречи/перерыва контекст возвращается без ручного поиска по Asana, PR и чатам.
| `project` | The current top-priority feature/bug | Time here should dominate most weeks | - День учитывает встречи, рабочие обязательства, review-очередь агентов, перерывы и границу рабочего времени. Перегруженный день ведёт к явному сокращению/переносу задач.
| `aor` | AOR maintenance: code review, bug fixes, blocklist | Required to keep the area healthy | - Количество запросов к Алексу и минуты ревью измеряются. Агентные задачи прекращают расходовать бюджет при превышении лимитов или отсутствии прогресса.
| `career` | Project Advisor, Ship Reviews, Tech Design, visibility | Easily deferred; system forces it into view | - Важные рабочие обязательства не теряются, а карьерный вклад хранится с датой и ссылкой на подтверждение.
| `strategy` | Planning, Personal OS, Asana organisation | Meta-work; needs a floor, not a ceiling |
Personal pet projects (AXPressDeck, media_files_db, etc.) are tracked separately and not counted as work time. See `aw-projects.json` (`namespace: "personal"` entries). ## Связанные документы
## What It Does Not Do - [[personal-os-status-2026-10]] — текущее состояние реализации.
- [[personal-os-failed-approaches]] — почему прежний контур остановлен.
- Does not make decisions for Alex — it informs - [[personal/plans/personal-os-operating-plan-2026-10-03]] — аудит и последовательность правок по этой миссии.
- Does not send notifications during focus (deep focus gate in inbox STEP 0)
- Does not access Asana API directly from Eagle — only reads pre-rendered status.md
- Does not create PRs, commits, or messages without explicit confirmation (except Executor, after its single approval gate)
## See Also
- `personal-os-architecture.md` — full technical architecture, agents, data flow, file locations
- `personal-os-agent-rules.md` — Eagle's operating rules and allowed writes
- `personal-os-self-modification.md` — how Eagle (and Alex) can evolve the system