Selected work / P♠
Projects
Tools, products, simulations, infrastructure, and evidence-gated research—with the honest limits left in.
A model-agnostic, security-first software delivery harness that turns specialist model roles into a gated SDLC with human approvals and inspectable evidence.
Open projectThree public, verifier-first explorations of Conway-99, an Erdős covering problem, and the Krenn–Gu conjecture—publishing exact finite or conditional progress while keeping every global problem explicitly unresolved.
Open projectA deterministic neural-worm terrarium with contact-driven boarding, randomized Seed Forge worlds, causal control lanes, and checksummed replay—plus one unapologetically scripted aerial kickflip.
Open project
A public scientific-computing lab running 302 graded-potential neurons, 95 body-wall muscles, an inextensible low-Reynolds-number body, and a browser viewer as one closed loop.
Open projectA reproducible PufferLib training harness where one compact policy stabilizes and races 2,048 batched Crazyflie-style drones through randomized 3D rings, backed by a measured and hash-checked baseline.
Open projectA living 3D glasshouse aviary backed by a fail-safe weekly asset pipeline that quarantines, validates, optimizes, and provenance-tracks generated bird models before publication.
Open projectA private, production-shaped client value ledger that turns promised outcomes and source-backed proof into monthly briefs, client pulse signals, and transparent renewal readiness.
Open projectAn original Godot 4 vertical slice with an explorable magical hub and a complete, repeatable card duel built around readable enemy intent, mana, wards, status effects, and real win/loss states.
Open projectPrivate, local-first tooling for immutable market-data evidence, deterministic normalization, frozen offline experiments, and reports that keep plumbing checks separate from effectiveness claims.
Open project
An evidence-first Codex plugin and reusable skill that researches current roles and builds truthful, role-specific application packages without quietly inventing a better candidate.
Open projectThe deployment plumbing behind this site and its smaller siblings: signed webhooks, health-checked Docker rollouts, and Caddy routing on one VPS.
Open project
An interactive, repository-derived map of the Krenn–Gu proof programme that keeps scoped results, open branches, and failed routes visibly distinct while the global conjecture remains unresolved.
Open project
A small 3D aquarium for the browser, built with React and Three.js and deployed like a real app because apparently I cannot leave anything simple.
Open project
A tiny daily bird site powered by recent eBird observations, a small Express API, and an unreasonable amount of affection for birds.
Open project
A six-person capstone connecting a NestJS/PostgreSQL backend, an Expo mobile app, and a classroom reader service for verified check-ins.
Open project
Two Expo/Firebase prototypes: one for vehicle access approvals and one for QR-based classroom attendance.
Open project2026
Central Deploy Manager
The deployment plumbing behind this site and its smaller siblings: signed webhooks, health-checked Docker rollouts, and Caddy routing on one VPS.
Interactive architecture / safe rollout path
How a deploy earns production
Current traffic lane
Caddy → production container- 01
git pushGitHub ActionsA repository asks for a deploy.
- 02
HMACSigned webhookThe request proves who sent it.
- 03
allowlistDeploy managerThe manager finds root-owned app config.
- 04
docker buildCandidate containerA new image starts on a temporary port.
- 05
GET /healthHealth gateThe candidate must answer before promotion.
- 06
swapPromoteOnly healthy code receives production traffic.
My notes
I built this because copying a slightly different deployment setup into every tiny side project was getting old fast. I wanted each app to own its code and Dockerfile while one boring, predictable service handled the dangerous bit on the server.
Now a new app mostly needs a health endpoint, a small config file, and a webhook secret. The manager builds a candidate container, checks that it is alive, and only then swaps it into production. It is not the flashiest project here, but it is the reason the flashier ones can live on their own subdomains without me manually babysitting every deploy.
Central Deploy Manager is the deployment layer I built to move my personal VPS from a one-off portfolio deployment into a small multi-app hosting setup.
The manager exposes a signed webhook endpoint, maps app IDs to root-owned deployment config files, and runs a shared Docker rollout script for each app. The rollout keeps the pattern I wanted from the original website deploy: build the image, start a candidate container on a temporary loopback port, health-check it, then swap the production container only after the candidate passes.
The system currently supports the portfolio site, Aquarium, and Bird of the Day from one server. Caddy handles the public domains and TLS, while Docker containers stay bound to 127.0.0.1 on app-specific ports.
The part I like most is that adding another app is mostly configuration: clone a repo, give it a Dockerfile and health endpoint, add one app env file, add one allowlist entry, and point a GitHub Actions workflow at the central deploy endpoint.