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.

I specified the game and drove it to certification. The judgement calls were mine: how volatile it should feel, when the numbers coming back were wrong rather than merely surprising, when a cascade animation read as broken instead of dramatic, and when it was actually finished.

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 has passed both front end and math certification. It is now in final platform review ahead of release, and I will link it here the day it goes live.

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.

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.

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.