Selected engineering work

Products, systems, and decisions

AI agent orchestration, an iOS app in development, and frontend case studies exploring rendering, live data, failure recovery, and measurable quality.

01 · Featured · AI engineering orchestration

AI Team

An engineering orchestration layer for AI coding agents.

Codex live-verified

AI Team monitoring concept with agent cards, activity feed, task progress, and a workflow overview. — Monitoring UI concept. AI Team runs in the CLI today; the illustrated roles and deployment activity are conceptual. The system does not auto-merge or auto-deploy.

AI Team turns independent coding agents into a controlled software-delivery workflow. A local TypeScript/Node.js orchestrator coordinates planning, implementation, review, and QA, enforces execution budgets, validates real repository changes, and returns an evidenced candidate for final human review.

From intent to a reviewable candidate

Human
Orchestrator
Architect
Implementer
Validators
Reviewer + QA

Final handoffREADY_FOR_HUMAN_REVIEW

Human review and integration remain explicit. No auto-merge or auto-deploy.

Problem

Single AI coding sessions are useful, but usually lack orchestration, bounded recovery, validation discipline, and trustworthy evidence.

System

A deterministic orchestrator coordinates Architect, Implementer, Reviewer, and QA roles in separate processes. Candidate validators and recorded verification evidence gate the handoff.

Control

Milestones, rounds, repair budgets, and invocation/time limits bound execution. Git worktrees isolate changes; immutable task/config snapshots and persisted run state support pause, resume, cancel, recovery, and explicit reconciliation. Final approval stays with the human.

Extensibility

Provider adapters support codex-only, claude-only, and mixed profiles. The CLI-first architecture leaves room for a future monitoring UI, MCP, and Obsidian integrations.

Multi-agent engineering workflow
Provider-agnostic orchestration
Git worktree isolation
Validation with recorded evidence
Recovery-aware execution
Human-controlled final approval

TypeScript
Node.js
CLI
Git worktrees
Codex
Claude Code

GitHub Architecture

02 · iOS personal organization app

Mind Palace

In development

An iOS-first app for capturing thoughts, organizing notes by context, and setting reminders, with AI-assisted organization that keeps users in control of suggested changes.

React Native
Expo
TypeScript
Zustand
SQLite

Private repository

03 · Next.js rendering architecture

Atlas

Architecture case study

A compact accommodation marketplace built to make server-first frontend decisions, failure ownership, performance budgets, SEO, and accessibility visible in one focused vertical slice.

Engineering problem

Search filters need to survive refresh, history, and sharing; invalid URL state must not reach domain code; listing content must remain indexable; and secondary latency must not block critical results.

Architecture

A dynamic search route resolves URL state before streaming, Server Components render results inside isolated Suspense boundaries, and known listing details are statically generated with route-specific metadata and structured data.

Decision record

Choices and trade-offs

URL state over client state

Native GET controls make the complete search state shareable and progressively enhanced without filter providers or effect synchronisation.

Trade-off: Navigation-relevant filters belong in the URL; ephemeral interaction state would not.

Resolve before streaming

URL parsing, normalisation, and validation complete before Suspense starts rendering data regions.

Trade-off: This delays the first streamed boundary until validity is known, but preserves real HTTP 307 redirects instead of streamed 200 responses with meta refreshes.

Narrow client boundaries

Application-owned search and listing UI remains server-rendered; only route recovery boundaries require client components.

Trade-off: The design deliberately favours native form submission over instant filter updates to keep hydration narrow and behavior predictable.

Reproducible evidence

Measured locally, scoped explicitly

Lighthouse performance: 0.97 / 0.99
Accessibility score: 1.00
Total blocking time: 3 ms

Median of three local production-mode mobile Lighthouse runs per route on 1 September 2026. Scores cover /search and a generated listing detail; they are synthetic lab results, not field data.

Next.js
React Server Components
TypeScript
Vitest
Playwright
axe
Lighthouse CI

View source Read project documentation

04 · Real-time, data-intensive frontend

Signal Ops

Local v0.1 release candidate

An operations control plane for live service health and incident investigation, designed around explicit failure states, versioned contracts, deterministic evidence, and an ordered, resumable Server-Sent Events stream.

Engineering problem

An operator needs a trustworthy current snapshot, visible connection freshness, and ordered live updates that can recover from duplicates, disconnects, gaps, or expired history without treating the stream as the source of truth.

Architecture

The React client starts from a consistent REST snapshot and cursor, then applies validated SSE events through a typed reducer. PostgreSQL state changes and event-log records commit atomically; unresolvable gaps trigger a fresh snapshot.

Decision record

Choices and trade-offs

SSE over WebSockets

The initial live channel uses ordered event IDs, heartbeat comments, and cursor-based recovery because v0.1 communication is server-to-browser.

Trade-off: The simpler HTTP transport fits one-way updates; full-duplex messaging, binary payloads, or materially higher event rates would require a different or additional transport.

Snapshot plus ordered events

The dashboard hydrates from a consistent snapshot and applies only later idempotent events; continuity failures resynchronise rather than speculate.

Trade-off: The backend must own cursor ordering, retention, and consistency, while the client must reject invalid transitions and recover explicitly.

Modular monolith first

Catalog, Telemetry, Health, Incidents, Live Stream, and Simulation keep explicit boundaries inside one backend process.

Trade-off: Transactions, debugging, and end-to-end proof stay manageable, while process-level failures remain shared until evidence justifies extraction.

Reproducible evidence

Measured locally, scoped explicitly

Event-to-UI p95: 75 ms
Interaction p95: 8 ms
axe violations: 0

Recorded 28 August 2026 in a same-host, single-user Chromium baseline with 100 seeded services and 10 metric events per second. This is reproducible local evidence, not hosted or multi-user production capacity.

React
TypeScript
Server-Sent Events
Fastify
PostgreSQL
Vitest
Playwright
axe

View source Read project documentation

Supporting work

Additional frontend architecture samples

Smaller repositories retained for the specific boundary or browser-system problem they explore.

Reactivated Sample

Server rendering and type-safe backend/frontend boundaries

Django
React
TypeScript
Reactivated
SSR

Source

Headless CMS Architecture

Structured content delivery with Strapi and Next.js

Next.js
React
Strapi
PostgreSQL
REST

Source

Graphics Canvas

Collaborative Canvas rendering and cursor synchronisation

React
TypeScript
Canvas API
WebSocket
Node.js

Source