The workbench

The Hub

The fourth program never ships to anyone. It launches the other three, watches them, tests them, backs them up and packages the release. It is the room the rest of the project was built in.

Its views are grouped by what you are doing rather than by what things are — building, operating, or shipping. That sounds like a cosmetic decision and is not: it is the rule that decides where a new tool goes, and having a rule is what stops a workbench turning into a drawer.

The Hub — Workbench · the plan catalogue

The Hub — Dependencies

Three lists of one shape

The workbench keeps three lists that look alike and answer different questions, and they are never merged. The plan catalogue is a record of decisions — what is being built, and how far it got. The ideas board holds observations: what a scheduled review noticed on a given day that nobody has acted on yet. The prompt repository holds instructions not yet given — a request written now, filed with an urgency and a category, and submitted later.

• Promotion is a rewrite. An idea that turns out to be a project becomes a plan with a status of its own, not a flag on the idea. Merged, the lists would make the catalogue's own "what is left to build?" tally meaningless.
• The ideas board is read-only from the workbench. Its writer is a local process that can already open the file, so there is deliberately no way to post to it over the network — an intake would be a second writer needing a credential the workbench does not have.
• Urgency is a closed list; category is open. The categories asked for ended in "or other", so a closed vocabulary would be wrong the day a fourth is thought of. The one thing an open list can enforce is spelling, so "backend" never becomes a second group beside "Backend".
• Its limits refuse rather than trim. Every other bounded store here holds output a machine can produce again; this one holds text a person wrote. An over-long prompt is refused with its size named, and a full repository refuses the new prompt rather than dropping the oldest.
• Nothing sends a prompt anywhere. Submitting is copy, then paste. There is no verb that sends one and there must never be one: the workbench holds no credential that could speak for its operator.

Four rules this thing taught me

• The verdict is the exit code, never the printed summary. The 332 test suites print their results in six different formats, and a parser reading that prose would eventually read a failure as a pass. The runner reads the exit status and treats the counts as decoration. Suites that never call exit at all are badged as such — a row that could never turn red is not evidence that anything works.
• Reachable is not the same as latest. The dependency report distinguishes what is declared versus installed from what is installed versus available, and never derives one from the other. It also resolves the newest version each package can actually install given the interpreter — otherwise it reports three impossible upgrades every day, forever, until you stop reading it.
• A source that cannot be reached contributes absence, never zero. The background monitor records gaps as gaps, and charts draw them as breaks rather than joining the line across them. An outage that renders as a flat line at zero is an outage you will not notice.
• It reports and never acts. The dependency report will not upgrade anything. The stray-process finder will not kill anything. Restoring a backup stays a command you type rather than a button you can hit by accident. A process nobody has a record of is not thereby proven abandoned, and a bulk upgrade across a machine-learning stack breaks it silently.

Nothing on this site is investment advice or an offer of any product or service.

How it was built

Working notes

The project is 543 numbered rounds long. Each one is written up before it closes — what changed, what broke, and what the mistake taught. A handful of those lessons ended up shaping everything after them.

One fact, one owner

The recurring failure across the whole project has been the same shape every time: two places that both claim to know something, drifting apart quietly until one of them is wrong and nothing notices.

• The top-level navigation used to be four hand-maintained lists — one deciding which buttons existed, one deciding the labels, one deciding what loaded, one deciding grouping. Nothing checked that they agreed, so a tab could open and then never load anything. It is now one registry that all four are generated from, and the tests fail if an entry is missing its counterpart.
• Column layouts in the application were stored in the same file as window layouts, and were broken three separate ways as a result — the ordering never persisted at all, saving silently did nothing on a preset layout that new installs happen to start on, and changing your window layout changed your columns. Separating the two facts fixed all three at once.
• Two different services each have a file called changelog.json. Same name, same shape, completely different meaning. Merging them is the single most tempting wrong move in the codebase and there is a note about it in three separate places.

The palette was computed, not chosen

The application draws profit in green and loss in red. The original pair measured a colour difference of 5.4 under simulated deuteranopia — the most common form of colour blindness, affecting roughly one in twelve men. In an application where those two colours mean gained money and lost money, that is not a styling preference. It is a defect.

Every value was solved for rather than picked, using perceptual colour distance and colour-blindness simulation. The rebuilt gain and loss pair measures 11.3 under the same simulation. It deliberately does not go further: deuteranopia collapses the red-green axis, so pushing for more separation forces the green toward lime and the red toward salmon until neither reads as its own meaning any more. Around eleven, plus the plus-and-minus signs the interface already prints, is the honest optimum.

The theme family eventually closed into a deliberate two-by-two — warm and cold, night and day — plus a frosted twin for each corner and a neutrals-only high-contrast mode. Every borrowed palette was retired on measurement rather than taste: an imported theme inherits semantic colours that were solved against a different ground, and two of the best-known ones turned out to draw their loss colour below the contrast floor on their own panels. The light corners were the harder problem: on a pale ground everything must darken to keep contrast, which collapses the palette into one band of lightness, and lightness is most of what a colour-blind viewer has left. Their money colours were re-solved from scratch rather than inverted.

lamplight — warm night

ash — cold night, the default

bone — warm day

marble — cold day

Tests that could have passed forever

• Nineteen test suites were writing to real data. The isolation code they shared named eighteen of the application's thirty-eight data stores, and the list had simply stopped being updated. It now discovers them by introspection, so a store written next year is covered the day it exists rather than the day somebody remembers.
• Isolation has two directions. Stopping a test from writing into its own tree is only half of it. Every client falls back to a fixed default address when nothing else is configured — which, on the machine where the real services also run, is the real service. Blocking one hop was not enough: the tests still reached a live service, which obligingly relayed the request onward.
• A check that builds its own client is only testing its own client. A preflight check reported a connection healthy while every real request to that host was failing, because the check constructed a fresh connection with different settings instead of using the one the application uses. This has now happened three times in three different forms. It is written down.
• Skipping the awkward tests hid a real defect. Sixteen suites were being skipped because they needed live services. One of the things they would have caught was live and broken.
• A test that reads the source is satisfied by the wrong source. "This function calls that one" is equally true of a call commented out, renamed, or switched off with if (false) — a trap the project's own notes record more than a dozen times. Tests now pin the guard rather than the name, and where the claim is a sentence or a pixel, they render it.
• The tests are themselves tested. Most suites carry a manifest of deliberate defects; a replay re-introduces each one in a copy of the tree and requires the suite to go red. A defect nobody catches marks a check that was never checking — and a manifest whose baseline is already red has replayed nothing, which was also learned the hard way.
• One suite expired by the calendar. It fixed "now" as a literal and read a seven-day budget against the machine's clock: green for a week, then red for ever, with nothing in the product changed.

Found by rendering it and looking

A whole class of defect is invisible to any check that reads code. A control hidden by an attribute kept painting, because a stylesheet's display rule outranks the browser's own rule for hidden things; a legend wrapped onto several rows and was drawn over its own chart; a mark meant to show where a gap had been collapsed sat under a gridline and read as one. Each was found with every check green, by rendering the real page and reading it. The notes keep count of how many times that has happened, because the count is the best argument there is for looking.

Documents lie in both directions

The project has nearly seventy design documents. When I went to record which were finished, the obvious approach — read the status out of each document's own header — turned out to be worthless in both directions. One document still announced itself as "plan only, no code changed" eighty rounds after it had shipped end to end. Another carried no marker at all and had been fully built. Status is now tracked deliberately and separately, and nothing writes back into the documents, because two writers for one fact is the same failure as everything else on this page.

A short list of things that turned out to be load-bearing

Standing note for the whole site. This is a personal engineering showcase. Nothing here is investment advice, a recommendation to trade, a performance claim, a term of service, or an offer of any product or service. The only figures anywhere on this site are a demonstration instance's own arithmetic over app-generated synthetic series, inside screenshots, as illustrations of the tools — none are results and none are implied to be. Trading involves risk of loss, and software that tests ideas against history cannot tell you what happens next.