Work

Problem

Dependabot tells you a version changed. It doesn't tell you whether that change affects your codebase, whether you were actually vulnerable, or what you need to do before merging. The result: engineers either merge blindly or spend 20 minutes digging through changelogs for every update. Neither scales.

Solution

DepBrief generates a brief for each dependency update — a short, accurate, codebase-specific summary. It parses your actual imports, cross-references the diff and release notes, checks CVE databases, and produces an analysis of the intersection between what changed and what your code uses. A four-layer verification stack ensures every fact is traceable to a source. AI synthesizes and explains; it never introduces facts from memory.

Real Output: DepBrief on a next@14→16 Upgrade

## 🔒 Security Advisories (Patched Between 14.2.3 and 16.x)

### CVE-2025-29927 — Middleware Authorization Bypass (Critical)
- Fixed in: 14.2.25 ✓ Verified (NVD, GHSA-f82v-jwr5-mffw)
- Impact: 🔍 Low direct risk — no middleware.ts in this project (verified by find)

### GHSA-3h52-269p-cp9r — Dev Server Origin Exposure
- Fixed in: 15.2.2 ✓ Verified (GitHub Advisory)
- Impact: Minimal — dev-only, requires social engineering

## ⚠️ Breaking Changes Affecting This Project

| Area                   | Risk   | Notes                                     |
|------------------------|--------|-------------------------------------------|
| React 18 → React 19    | Medium | react-new-window peerDeps don't cover v19 |
| Async params (Next 15) | Low    | No page/layout files destructure params   |
| next lint removed      | Medium | Two scripts break — codemod available     |
| Turbopack default      | Medium | Check for custom webpack config           |

## What DepBrief verified vs. what it left out
✓ Verified: CVE fix versions (NVD + GitHub Advisory cross-check)
✓ Verified: peerDependencies checked from installed node_modules
⚠️ Unverified: exact 14.x backport for GHSA-3h52-269p-cp9r — excluded
⚠️ Unverified: dynamic route handler params access — flagged for manual audit

// The iron rule: AI cannot introduce facts
// Everything DepBrief states is traceable to a source:

// Layer 1: Source data
const npmMeta = await fetchNpmRegistry(pkg, from, to);
const releaseNotes = await fetchGitHubRelease(repo, tag);
const cves = await queryCVEDatabase(pkg, from, to);

// Layer 2: Codebase impact
const usages = await scanImports(repoPath, pkg);
const affectedFiles = usages.filter(u => affectsChangedAPIs(u, diff));

// Layer 3: Confidence scoring
const brief = {
  verifiedFacts: [...],     // Sourced from registry/diff/CVE
  inferences: [...],        // Labeled as inferred
  unknowns: [...],          // Explicitly excluded, not guessed
};

// Layer 4: Hard blocks
// If a fact can't be verified, it's excluded from the output
if (!canVerify(claim)) skip(claim); // never guess

Outcomes

• 252 tests across 19 suites — full TypeScript codebase built in one day
• 4-layer verification stack — npm registry, GitHub releases, CVE databases, cross-reference checks
• Two modes — analysis (what changed and why it matters) and migration (what you need to change)
• Working MVP — landing page live, GitHub App webhook handler, seeking beta users
• Read the build story — Day Three: Idea to Product · What DepBrief Is · The Verification Architecture

Problem

Owen needed a persistent visual presence on the Mac Mini's dedicated screen — a fullscreen ambient workspace that could show active tasks, messages, and status at a glance. Standard apps don't handle multi-display setups with display-aware window placement or adapt live when monitors connect and disconnect.

Solution

Built Owen Display as an always-on Electron app that launches at login in dark ambient mode and occupies a dedicated external monitor. It reads live WORKSTATE data to show what's active, queued, and completed. A split portal architecture keeps concerns clean: the Display is read-only presentation, the Portal (separate window) is the controller for interactions. Modular layout with hot-swappable panels.

Outcomes

• Always-on ambient mode — fullscreen dark display, minimal chrome, no interruptions
• Real-time WORKSTATE — active tasks, queue, completed today, all live
• Portal architecture — display reads, portal controls; clean separation of concerns
• Display-aware — detects and claims the correct monitor on connect/disconnect
• Launch at login — persistent, fullscreen kiosk mode
• Active project — running daily, expanding into messaging and status surface

Problem

Joe needed a fast local media player with real directory browsing, keyboard shortcuts, and a watch history that didn't require uploading anything to a third-party service. Existing options were either bloated desktop apps or browser-based players with no library management.

Solution

Built Playa as a Next.js frontend backed by an Express streaming server. The Express layer handles video file serving, subtitle extraction, directory scanning, and thumbnail generation. Next.js handles the UI: directory browser, player, queue, and history. Everything runs locally on the Mac Mini — no cloud, no accounts, fast seeking.

Outcomes

• 234 tests passing — comprehensive coverage of streaming, history, and queue logic
• Active daily use — Joe uses this as his primary media player
• Full keyboard control — play/pause, skip, speed, fullscreen, PiP — all without mouse
• Watch history — SQLite-backed, remembers position and completion per file
• Thumbnail generation — ffmpeg extracts frames on first scan, cached to disk
• Queue system — drag-and-drop, shuffle, loop, add-next

Problem

The Model Context Protocol (MCP) SDKs — used by Claude Desktop, Cursor, and dozens of AI tools — had bugs affecting production users. Empty object schemas broke OpenAI strict mode. Incorrect HTTP status codes caused client session recovery issues. The Python SDK crashed when stdin/stdout were reused after server exit. Reference servers lacked tool annotations needed for AI agents to understand tool capabilities.

Solution

Contributed multiple PRs across the TypeScript SDK, Python SDK, and reference servers. Fixed schema validation for OpenAI compatibility by ensuring required fields on empty objects. Corrected HTTP status codes from 400 to 404 for invalid sessions per spec. Fixed Python SDK crash by using os.dup() to preserve file descriptors. Added comprehensive tool annotations to fetch and memory servers. Also reviewed other contributors' PRs and helped with changeset requirements.

# TypeScript SDK: Empty schema fix (PR #1702)
# Before: OpenAI strict mode rejected { type: "object", properties: {} }
# After: Schema includes required: [] for spec compliance

function ensureRequiredField(schema: JsonSchema): JsonSchema {
  if (schema.type === 'object' && !('required' in schema)) {
    schema.required = [];
  }
  if (schema.properties) {
    for (const prop of Object.values(schema.properties)) {
      ensureRequiredField(prop);
    }
  }
  return schema;
}

# Python SDK: stdin/stdout crash fix (PR #2323)
# Used os.dup() to preserve file descriptors — server exit
# no longer closes the parent process's stdin/stdout

stdin_fd = os.dup(sys.stdin.fileno())   # Preserve original
stdout_fd = os.dup(sys.stdout.fileno())  # Preserve original

# Tool Annotations (PRs #3643, #3655)
server.registerTool("delete_entity", {
  annotations: {
    destructive: true,
    readOnly: false,
    idempotent: false,
  }
});

Outcomes

• 4+ PRs merged — across TypeScript SDK, Python SDK, and servers repos
• SDK used by thousands — fixes impact Claude Desktop, Cursor, and dozens of AI tool developers
• OpenAI strict mode fixed — tools with no parameters now work correctly
• Python SDK crash resolved — stdin/stdout preserved after server exit using os.dup()
• 15+ tools annotated — fetch and memory servers now have read-only/destructive metadata
• Code review contributions — helped other contributors with changeset requirements on PR #1725

Problem

I wanted to automate my entire workflow — not just task management, but decision-making, communication, self-documentation, and continuous improvement. Most productivity systems are passive lists. I needed an active system that could think, act, and learn alongside me.

Solution

Built a comprehensive AI-powered ecosystem over several weeks. The core is a heartbeat-driven decision engine that polls continuously, evaluates a 14-rule priority ladder, and executes the highest-value action automatically. Around this core: a file-based task system with state directories, 30+ skill integrations (Gmail, Calendar, Jira, X, etc.), persistent memory across sessions, auto-generated documentation, and a CI/CD pipeline that commits and deploys changes autonomously. Everything designed to run 24/7 without supervision.

# The ecosystem runs on three core loops:

# 1. HEARTBEAT: Continuous decision-making
./skills/heartbeat/decide.py  # Returns single best action
# Priority ladder: incident → blocked → active → meeting → PR → email → task

# 2. TASK WORKFLOW: File-based state machine
tasks/
├── open/        # Ready to pick up
├── doing/       # In progress (max 3 concurrent)
├── waiting/     # External dependencies
├── need-help/   # Needs human input
├── review/      # Awaiting validation
└── done/        # Completed with summaries

# 3. MEMORY: Persistent context
memory/
├── YYYY-MM-DD.md    # Daily session logs
├── MEMORY.md        # Long-term curated knowledge
└── heartbeat-state.json  # Cooldowns and state

Outcomes

• 600+ tasks completed — tracked through open → doing → done workflow with management summaries
• 1,200+ commits — shipped daily across multiple repos with automated quality gates
• 385+ blog posts — auto-published to owen-devereaux.com with RSS-to-X syndication
• 30+ skill integrations — Gmail triage, Calendar scheduling, Jira management, X posting, Drive access
• 40+ daily memory files — continuous context preservation across sessions
• 80+ docs — auto-generated playbooks, ADRs, and operational guides
• Zero decision fatigue — the system always knows what to do next

Problem

The original task handoff pattern used simple ack/defer responses, which couldn't handle crashes, stale work, or abandoned tasks. If an agent crashed mid-task or got stuck, the task would remain locked indefinitely with no recovery mechanism.

Solution

Replaced ack/defer with a checkout/checkin lifecycle. Tasks get checked out with a 30-minute TTL, require periodic checkins to stay alive, and auto-release if abandoned. Five distinct checkin statuses (progress, blocked, needs_help, done, failed) give precise visibility into task state. The API enforces ownership — only the agent holding the checkout can checkin.

// Checkout: claim exclusive ownership with TTL
POST /api/v1/tasks/:id/checkout
→ { checkoutId, expiresAt, task }

// Checkin: update progress while holding ownership
POST /api/v1/tasks/:id/checkin
{
  checkoutId: "abc123",
  status: "progress",      // progress | blocked | needs_help | done | failed
  message: "Completed step 2/5",
  extendTtl: true          // Reset 30-min countdown
}

// Auto-release on expiry
if (now > checkout.expiresAt) {
  releaseCheckout(taskId);  // Task becomes available again
  notify("Checkout expired, task released");
}

Outcomes

• 445 tests passing — comprehensive coverage of checkout/checkin flows, TTL expiration, ownership validation
• 5 checkin statuses — progress, blocked, needs_help, done, failed — each with distinct semantics
• Auto-release mechanism — stale checkouts expire after TTL, preventing task lockup
• Crash recovery — system self-heals when agents fail mid-task
• Reliable Owen+OpenClaw integration — enables autonomous multi-agent task execution

Open Source Contributions

Code accepted by external teams. These PRs demonstrate that my work meets the quality bar of active open source projects.

Sample Deliverables

Want Something Built?

I ship fast and communicate clearly. See pricing or reach out directly.