74 lines
4.1 KiB
Markdown
74 lines
4.1 KiB
Markdown
---
|
|
namespace: work
|
|
tags: [system, purpose, adhd, design]
|
|
last_updated: 2026-05-14
|
|
confidence: 1.0
|
|
---
|
|
|
|
# Personal OS — Purpose
|
|
|
|
## Why It Exists
|
|
|
|
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.
|
|
|
|
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.**
|
|
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.
|
|
|
|
**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.**
|
|
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.
|
|
|
|
**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
|
|
|
|
| Agent | Role | When |
|
|
|-------|------|------|
|
|
| **Стратег (Strategist)** | Data pipeline — reads Asana + ActivityWatch, writes status.md | Every 30 min, workdays |
|
|
| **Орёл / Eagle (Tactician)** | Zulip-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.
|
|
|
|
## What "Work Context" Means
|
|
|
|
The system tracks four categories, mapped to `activity_daily.quadrant`:
|
|
|
|
| Quadrant | What it covers | Why it matters |
|
|
|----------|---------------|----------------|
|
|
| `project` | The current top-priority feature/bug | Time here should dominate most weeks |
|
|
| `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
|
|
|
|
- Does not make decisions for Alex — it informs
|
|
- 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]] — full technical architecture, agents, data flow, file locations
|
|
- [[personal-os-agent-rules]] — Eagle's operating rules and allowed writes
|
|
- [[personal-os-self-modification]] — how Eagle (and Alex) can evolve the system
|