Development

islet has over 600 tests. casectl has 313. cable-club has 19 accuracy tests that compare framebuffer output pixel-by-pixel against a reference emulator. These are different projects in different languages solving different problems, and they all test heavily. This is not an accident. The principle If you cannot verify a claim automatically, you do not actually know if it is true. You think it works. You believe it works. You tested it manually once and it seemed fine. None of that counts. What counts is a command you can run that tells you, definitively, whether the system does what it is supposed to do. ...

When I rewrote cable-club, the first thing I built was not the CPU or the renderer. It was the test harness. An emulator without accuracy tests is a program that produces plausible-looking output with no way to know if it is correct. I had already learned that lesson once. What accuracy testing means A GBA emulator can pass every standard CPU test suite — every ARM instruction, every Thumb instruction, every edge case in isolation — and still produce the wrong output when running a real game. The test suites verify that individual instructions behave correctly. They do not verify that the CPU, memory bus, DMA controller, interrupt system, and PPU all interact correctly over thousands of frames. ...

On March 29, I started writing a Game Boy Advance emulator from scratch in Rust. By March 30 — seventeen commits and roughly thirty-six hours later — Pokemon FireRed was playing its intro cinematic. The CPU passed 100% of the standard ARM and Thumb test suites. The relay server was working. I had a functioning emulator. Then I threw it away. Why a GBA emulator My nephew Declan has never seen a Game Boy. I wanted to trade Pokemon with him over the internet, the way I did with a link cable twenty years ago. That is the entire motivation. ...

In late March, I bought a Freenove case kit for griffpi — the Raspberry Pi that runs everything. Three PWM fans, four addressable LEDs, a small OLED screen, and an STM32 expansion board that ties it all together over I2C. The case came with a Python script. The script was not good enough. The problem The stock software was a single monolithic script that assumed it was the only thing running on the Pi. It pinned a CPU core polling temperature in a tight loop. It had no configuration file. It could not be controlled remotely. If you wanted to change the fan speed, you edited the script, killed the process, and restarted it. ...

I am never going to open a journal app and write "today this happened." I know this about myself with absolute certainty. Every journaling app I have tried — Day One, Notion, Apple Journal, plain text files — assumes the user will voluntarily sit down and compose an entry. That assumption is the entire reason they fail for me. pwyslais starts from the opposite premise: I will not write unless something asks me to. ...

islet has one user. pwyslais has one user. llywio has one user. ira has one user. I am that user. This is not a limitation — it is the design constraint that makes everything else possible. The advantage When you build for one person, every decision collapses into a question you can answer immediately: does this work for me? Not “does this work for most users” or “will this confuse new signups” or “should we A/B test this.” Does it work for me, right now, on my hardware, with my constraints. ...

On Friday morning, islet had 766 tests and no concept of food components, rate limiting, or offline caching. By Sunday evening it had 1,750 tests, schema v8, a tiered rate limiter, photo-based meal estimation, a component meal architecture, a sync infrastructure, an iOS SwiftData cache, an alert detection engine, and a time-in-range dashboard showing 51.8% TIR across 14,000 CGM entries. One session. Safety note: islet is a personal project and is not medical advice. It does not make dosing decisions. ...