4.1 KiB
namespace, tags, last_updated, confidence
| namespace | tags | last_updated | confidence | ||||
|---|---|---|---|---|---|---|---|
| work |
|
2026-05-14 | 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:
- A comment sits on an Asana task for days — Alex never saw it because he was in Xcode
- A career-level task (Ship Review, Tech Design review) gets deferred until it becomes a bottleneck
- 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.md— full technical architecture, agents, data flow, file locationspersonal-os-agent-rules.md— Eagle's operating rules and allowed writespersonal-os-self-modification.md— how Eagle (and Alex) can evolve the system