Dylan McCavitt

A full ecommerce platform for a handmade-jewelry business. Guest and authenticated checkout, order history, shipment tracking, saved addresses, and an admin dashboard for products and inventory.

React + TypeScript frontend, Node/Express backend, Postgres via Supabase, Stripe payments, Shippo shipping labels, Resend transactional email. Each one carries its own webhook patterns and failure modes, reconciled into one order lifecycle.

A tool that turns a real AI assistant session into a repeatable test. It records what the assistant actually did, step by step, then replays that run later to confirm the behavior still holds. When someone tweaks the assistant, this catches changes that quietly break it before they reach real users.

The idea: teams can watch what their AI does, but most have no way to fail a build when an edit makes it misbehave. evalgate is the missing safety check. The headline example wires it into a trading assistant, where rules like "never place an oversized order" become hard checks that stop a risky change before it can ever reach the broker.

An autonomous trading agent whose safety comes from deterministic, model-independent guardrails rather than from trusting the model. A scheduled headless Claude Code session wakes at 15:45 ET on weekdays, computes a signal, and trades through Robinhood’s official Agentic Trading MCP, with every order first clearing a deterministic gate that can block it.

The strategy (an RSI(2) mean-reversion rule) is a pluggable worked example; the project is really about the harness. In dry-run it journals every decision: intended entries, simulated fills, and the gate verdict that allowed or blocked each one. Going live is a config change.

An MCP server that drives TradingView Desktop from an agent conversation: chart whole stock universes, capture chartbooks, and round-trip Pine Script (set source, compile, read console errors back).

V1 is scoped to charting. No scanning, no execution.

Big AI training runs need many GPUs at the same moment: if even one is missing, the whole job stalls and the rest sit idle. slurmlet is the traffic controller that holds a job back until every GPU it asks for is free, then starts them all together, so expensive hardware never waits half-used while a run gets the machines it needs.

It is built twice, once in Go and once in Python, against one shared design, so the two implementations can be compared head to head on the same problem (and the trade-offs each language makes show up first-hand). Everything runs against a simulated fleet of stand-in GPUs, so the full lifecycle, scheduling a job, draining a machine, and rescheduling, is exercised without renting expensive hardware. The Go version is active; the Python version lands next.