Senior technical architect and AI agentic automation engineer, working in Python — data pipelines, backend systems, and agent tooling. Also shipping TypeScript design systems and frontend tooling.
- 🔭 Building well-architected, fully-tested projects rather than one-off scripts — every repo below has a test suite, CI, and a README that explains why, not just what
- ⚙️ Focused on the unglamorous parts of AI agent systems: budget enforcement, per-call failure isolation, and honest verification against live APIs rather than mocks alone
- 🎨 Building thoughtful design systems with accessible React components and clear design tokens
- 🌱 Actively contributing real fixes to existing open source projects, not just building my own
- 💬 Ask me about Python architecture, ETL pipelines, agentic/MCP tooling, or design systems
- 📫 Reach me by opening an issue on any of my repos
Same checklist on every repo below, whether it's a Python agent tool or a Flutter game — this is the actual gate, not aspirational:
- Logic and interface are separate. Business/game logic lives in its own module with zero framework imports — no Flutter widgets in a game's rules, no HTTP client in an agent's planning loop — so it's unit-testable without spinning up a UI or hitting a live API.
- Test depth matches the actual complexity, not a padded-to-look-thorough number. An exhaustive-search AI gets an exhaustive test that plays out every opponent line; a heuristic AI gets concrete tactical positions; a puzzle generator gets a correctness proof (uniqueness, solvability, or connectivity — whichever invariant is load-bearing); a card game gets its actual rulebook exercised edge case by edge case.
- Static analysis has to be clean —
flutter analyze/ linting with zero issues — before anything moves on. - It has to actually run, not just build. For the Flutter games specifically, that means launching the real Windows
.exeand confirming the process is alive via a live process check, because a successful compile and a working app are not the same claim. - Downloadable, not just readable, on more than one platform. Each game repo ships as a ready-to-run GitHub Release — a Windows
.exebundle and an Android.apkon the same tag — no Flutter SDK, no build step, just download and run.
A few specific things that came up doing the above, because "it works" is worth backing with what actually happened rather than asserted on faith:
- A cross-drive Kotlin bug, caught on one repo before it could waste 57 identical failures. Building the first Android release,
flutter build apk --releaseran for 19 minutes and 36 seconds before failing withIllegalArgumentException: this and base files have different roots. Root cause: Kotlin's incremental-compilation cache tries to compute a relative path between the project directory (D:\Games\...) and the Flutter pub-cache (C:\Users\...) — which is undefined on Windows once two paths don't share a drive letter. Fix was one line (kotlin.incremental=falseinandroid/gradle.properties). The important part isn't the line, it's the sequencing: piloted the fix on a single repo, confirmed the rebuild succeeded in 102 seconds, verified the resulting APK actually uploaded and matched what a clean install expects — then rolled the fix out to all 58 projects. Discovering that bug 58 times, mid-rollout, would have cost hours instead of one extra pilot run. - A silent Firebase gap, caught by checking for the file instead of assuming. One game (
brain_quest) uses Firebase email/password auth. Before shipping it as a release on any platform, checking forfirebase_options.dartandandroid/app/google-services.jsonturned up neither — the Firebase packages were wired in, but the project was never actually connected to a live Firebase project. That's not a platform limitation to route around, it's a broken build waiting to happen, so it's excluded from both the Windows and Android release rollouts until it's properly configured, rather than shipped anyway and left for someone to discover by downloading it. - Windows builds are verified by launching them, not by trusting exit code 0. Every game's
.exeis confirmed alive afterward via a live process check, because a Flutter Windows release can compile clean and still fail to start if a plugin's native dependencies aren't bundled correctly — "the build finished" and "the app runs" are different claims, and only the second one is the one that matters.
The throughline across these five: a hard budget or circuit breaker checked before work happens, failures isolated to the one call that raised them instead of taking the whole run down, and README sections that say plainly what's been verified against the real Claude API versus what's only proven against fakes.
| Project | What it does |
|---|---|
| horizon | A context-window budget manager for long-running Claude agents: drops or summarizes old turns to stay within a token budget, never crashing on overflow |
| quorum | A multi-agent orchestration control plane built around budget enforcement and per-agent failure isolation, not another happy-path demo framework |
| pathfinder | A long-horizon task planner that detects when a plan has drifted from its goal and replans only the remaining work — the re-planning loop quorum's own README leaves as a known gap |
| waypoint | A durable, checkpointed workflow engine for chaining Claude-powered steps, with human-in-the-loop approval gates and an audit trail |
| rubric | An LLM-as-judge eval harness that grades Claude outputs against rubric criteria using structured outputs, not regex on free text |
| Project | What it does |
|---|---|
| hearth-design-system | Hearth — a Claude-inspired design system: tokens, accessible React components, and a written rulebook |
58 small Flutter games, each its own repo, each shipped as source and as a downloadable build under that repo's Releases tab — a Windows .exe and an Android .apk on the same v1.0.0 tag. See How I verify before shipping and Field notes above for the pipeline every one of them goes through, including the one that shipped Windows-only for a documented reason.
🧠 Where the AI actually thinks — exhaustive proofs, minimax, and pathfinding
| Project | What it does |
|---|---|
| chess | Minimax + alpha-beta AI, but the real story is the move generator: verified with perft against published reference values across three positions, because start-position perft alone never even reaches castling or promotion |
| tictactoe | An actually-unbeatable AI — full minimax verified by an exhaustive test that plays it against every possible opponent line, not a couple of hand-picked cases |
| nim | AI plays the mathematically perfect nim-sum strategy from combinatorial game theory, not a heuristic — verified against every possible opponent reply, not just spot-checked |
| connectfour | Minimax + alpha-beta with a window-counting heuristic, tested against concrete tactical positions (winning drops, blocked threats) rather than just "does it run" |
| checkers | Mandatory captures and multi-jump chains — the two rules a simplified checkers implementation usually drops — verified with a constructed double-jump position, not just single captures |
| pixelchase | Pac-Man-style ghosts that recompute a fresh BFS shortest path to the player every tick (not a path frozen at spawn), and flee toward the farthest open cell once you've eaten a power pellet |
| lightcycles | A Tron-style AI that doesn't chase you at all — it flood-fills the open space behind each candidate move and picks whichever leaves it the most room to keep riding |
🔍 Where correctness is the whole point — generators, physics, and rules
| Project | What it does |
|---|---|
| sudoku | A real backtracking generator that guarantees a unique solution — not naive fill-then-remove, which can silently ship ambiguous puzzles |
| fifteenpuzzle | Generates only solvable boards using the actual parity invariant that governs the 15-puzzle — verified against the historically famous "14-15 swap," the real-world proof case for why the invariant matters |
| freecell | Full Freecell rules, not a simplified card game — moving one card at a time through free cells is how Freecell actually works, unlike the single-card-move scope-cut in the Klondike build |
| dotsandboxes | Handles a single line completing two boxes at once (a shared edge), with an AI that specifically avoids gifting the opponent a free box |
| wordle | Duplicate-letter-aware color feedback (unit tested) and a persisted win streak |
| brain_quest | Four brain-training mini-games behind Firebase email/password sign-in — currently source-only, no release build, until its Firebase project connection is finished (see Field notes) |
🕹️ The rest of the collection — 45 more, same rigor, one tap away
Minesweeper, Battleship, Hangman, Rock Paper Scissors, Whack-a-Mole, Simon Says, Yahtzee, Boggle, Mastermind, Reversi, Mancala, Lights Out, Tetris, Bubble Shooter, Match 3, Air Hockey, Gomoku, Ultimate Tic-Tac-Toe, Tower of Hanoi, Peg Solitaire, Go Fish, Crazy Eights, Solitaire, Blackjack, War, Word Search, Anagram, Math Quiz Sprint, Typing Speed Test, 2048, Breakout, Pong, Asteroids, Doodle Jumper, Maze Runner, Memory Match, Space Invaders, Flood Fill, Threes Merge, Balloon Pop, Fruit Slice, Mini Crossword, Trivia Quiz, SkyHop, Snake — and counting.
Full list, always current, on the repositories page.
| Project | What it does |
|---|---|
| oss-scout | An MCP server that finds genuinely-contributable open source issues by filtering out ones already swarmed with duplicate PRs |
| flowforge | A small, config-driven, pluggable ETL pipeline toolkit |
- pandera#2415 — fixed a regression where optional pydantic fields were incorrectly rejected as non-nullable. Found it the same way oss-scout now automates: searching for a genuine, unclaimed bug instead of a swarmed "good first issue."
- google/langextract — verified two genuine, unclaimed bugs against current
main: #492 (OpenAI o-series/gpt-3.5 model IDs route to no provider) and #491 (a refused/content-filtered OpenAI completion is silently reported as a successful empty result instead of raising, unlike the equivalent batch-path guard). Fixes and regression tests are ready; PRs are pending because the repo's contribution guidelines require the linked issue to have community reactions first — commented on both to help clear that bar honestly rather than opening PRs against a 0-reaction issue.