I ship software I don't write.

Slot math is a constrained optimization problem. You are given a target return, a hit frequency, a max win cap and a volatility profile, and the reel set and payout table have to satisfy all four at once. Then it has to survive an audit by someone whose job is to find where you got it wrong.

The first thing I did was go to Stake and confirm exactly what the math had to hit, rather than assume it and find out later. It still failed their checks three times before it passed. Each time their RTP output came back and told me what was off, and it went another round.

The front end had its own problem: spins would freeze partway through. That one mattered more than it looked, because a slot that stalls mid-spin loses the player and you do not get their attention back. The note below is how I found it.

Certification is a useful forcing function, because it removes the option of "close enough." A payout distribution is either provably correct across millions of rounds or it does not ship. Getting there meant a lot of runs where the answer was no.

It passed both front end and math certification, cleared final platform review, and is now live and playable on Stake. You can open it and play it yourself, linked above.

The most honest thing you can build while job hunting is the thing that solves your own job hunt. So this one runs in public, and you can read its output below.

Each morning it polls the public job-board APIs of a watchlist of companies. Cheap deterministic filters run first, checking title, location, and everything already seen, because there is no reason to spend model tokens learning that a Director of Sales role is a bad fit. About 4,500 postings become about 37.

Those go to Claude with a strict schema: a 0 to 100 fit score, the specific reasons, and a draft opener. Anything above the bar lands in a daily digest.

Two decisions I would defend. It drafts but never sends, because auto-applying at volume is how you become spam, and the goal was never to apply to more jobs. It was to only look at the ones that matter. And it is instructed to be harsh about my gaps. An early version rated every single posting exactly 72 and wrote openers claiming experience I do not have. That version was useless, and worse, dishonest. The current one routinely scores roles in the single digits and says why.

The openers it drafts are published on this page, which creates a problem worth solving properly. A later version was writing "I build AI tooling end-to-end" and naming a model provider I have never used. Instructing it not to got that from constant down to roughly one slip in forty, and one in forty is still a false claim on a public page. So the absolutes are enforced in code rather than in the prompt: an opener that claims I wrote the implementation, or names a tool I do not use, gets dropped instead of published. A missing opener is strictly better than a false one.

Most assistant projects are a thin wrapper around one model, so the day you swap models you lose the personality, the memory, and everything it knew about your house. The design decision here was to invert that. Identity lives in a service that sits between you and whichever model is answering.

It keeps a file of durable household facts injected into every conversation, plus a searchable store of past ones. Routing is by request type. Anything latency-sensitive stays on the model running locally on the GPU, open-ended questions go to the cloud, and if the cloud call fails it quietly falls back rather than dying.

Vision runs entirely on the local machine. Camera frames never leave the house. That was a requirement, not an optimization.

The whole assistant lives on the home PC and still answers from anywhere. It sits behind a private Tailscale network, so my phone reaches it on the home machine with nothing exposed to the public internet, and Home Assistant points at the same service. A question asked through the house and a question asked from my phone hit one identity and one memory.

The newest set of eyes is a pair of homemade smart glasses. An ESP32-S3 camera board registers itself with Jarvis the moment it powers on, then captures photos and short clips on a spoken command and hands them to that same on-device vision model. The glasses are still a breadboard on the bench rather than something you would wear, but the code path works end to end right now.

A smaller, tighter game than Sakura Storm on purpose. Three reels, three rows, nine fixed paylines, and a Key to Fortune pick-em bonus where the top box is a routed max win rather than a lucky roll.

The constraint I set was that the paytable, symbols and paylines had to be defined once and mirrored exactly between the Python math model and the TypeScript front end. If those two ever drift, the game pays out something different from what it displays, and you will not find out until someone else does.

Everything is built and the numbers hold. I have not put it through certification or launched it, and I am not going to claim otherwise.