That net also ate every real query where a user typed “0” on purpose.

“Players with 0 or more three baggers” — a real, syntactically valid query that used to return nothing sensible.

The parse is identical either way

Type “players with 0 or more three baggers” into the search bar, and the LLM parses it toexactly the same shape as the hallucinated placeholder:

1

{ "stat": "triples", "direction": "at_least", "value": 0 }

There’s nothing in the parsed object that distinguishes “the model made this up” from “the userexplicitly asked for this.” The stripper had no way to tell them apart, so it deleted both,every time. “1 or more” and anything higher worked fine, because value === 0 simply nevermatched — which is exactly why this sat unnoticed for a while. It’s the kind of bug that onlyshows up on the specific boundary condition nobody thinks to test, because a query for “0 ofsomething” feels like a null query even when it isn’t one.

Losing the threshold broke more than the threshold

The consequence wasn’t just a missing filter — it silently broke sort order too. Downstream,sortBy gets inferred from whichever *_min/*_max filter key survived the parse. Strip thethreshold, and there’s no filter key left to infer a sort from, so the query falls back to nosort at all. A request for the top 20 by some stat quietly stopped showing the top 20 — itshowed whatever order the database happened to return, with no threshold and no ranking, and noerror anywhere in the chain to say so.

The fix: check the query text before you strip

The stripper’s problem was that it only had the parsed shape to go on. The fix gives it a secondsource of truth: before deleting a zero-valued threshold, re-run that stat’s own threshold regex— the same THRESHOLD_PATTERNS used to parse the query in the first place, defined instat-aliases.ts — against the raw text the user actually typed. If “0” for that stat has areal textual basis in the query, the threshold survives. If it doesn’t — if there’s no explicitzero anywhere in the sentence — it gets stripped as the hallucination it almost certainly is.

1
2

buildFallbackToolArgs("players with 0 or more three baggers", 'player')
// -> { stat: 'triples', direction: 'at_least', value: 0 }  (now survives)

Same parsed shape, same value, but now the decision to keep or drop it is grounded in what theuser actually wrote instead of a blanket rule about the number zero.

The broader shape of the bug

This is a pattern worth naming on its own: a safety net built to catch model noise, tunedagainst the failure case that motivated it, without checking whether it could also match alegitimate input that happens to look identical after parsing. The net wasn’t wrong to exist —LLM hallucination on placeholder values is real, and letting one through can null out a wholepage of results. It just needed a second signal beyond the parsed value to tell the two casesapart, and that signal — the original query text — was sitting right there the whole time,already used earlier in the same pipeline.

— James

This is the write-up, in the order I actually found them, because the order matters: each fixrevealed the next failure instead of resolving the symptom.

Adley Rutschman’s page today — the state all three bugs conspired to prevent.

Bug 1: the cache flush that flushed nothing

The first theory was stale cache. I ran the project’s clear-cache script, expected a cleanslate, and got the same stale data back. Ran it again. Same result. The script printed✓ cleared every time.

The cause was an environment mismatch that had been there since the caching layer was built:

1

const CACHE_NAMESPACE = (process.env.CACHE_NAMESPACE || process.env.NODE_ENV || 'dev').trim();

The server runs with NODE_ENV=development and writes keys under development:*. TheCLI script, run from a plain shell, has no NODE_ENV set at all — it resolves to dev:,issues a delete against dev:*, matches zero keys, and reports success anyway, becausedelPattern returned void. A zero-match delete was indistinguishable from a real one, at thetype level and in the printed output.

I only found it by going around the tool: redis-cli EXISTS against the development:* keysdirectly, before and after a “successful” flush. The keys were still there. That’s when Inoticed the namespace mismatch.

The fix made a no-op impossible to mistake for success:

• delPattern now returns the number of keys it actually deleted, and every call site reportsthat count — ⚠️ 0 entries cleared reads very differently than ✓ cleared.
• The tool now prints the namespace it’s about to operate on and what Redis actually holds,so a mismatch is visible before you even wait for the delete.
• It detects the mismatch and tells you the fix:

1
2
3
4

Namespace: dev:  (Redis currently holds: development, test, today)
⚠️  No keys exist under "dev:" — this flush will delete NOTHING.
   Keys live under: development:, test:, today:
   Re-run matching it, e.g.  NODE_ENV=development npm run clear-cache -- ...

This had been the standing explanation for a whole class of “why didn’t my fix take effect”reports across the project. The remedy people reached for first had never actually worked.

Bug 2: the importer that outvoted the trade

With caching ruled out, the database itself said Rutschman was still Baltimore’s. A trade syncjob (refresh-player-teams) had correctly written his real club days earlier. Something waswriting it back.

The culprit was a stats importer — a job that pulls a player’s current-season batting orpitching splits and, as an incidental side effect, decided it should also own that player’steam assignment:

1
2
3
4

// Update player's team if this is the most recent MLB team ...
if (player && teamId && teamName && season === CURRENT_SEASON && isMLBTeamId(teamId)) {
  await prisma.player.update({ where: { id: playerId }, data: { teamId, teamName } });
}

The comment claims “most recent.” There is no recency check anywhere in that block — it simplyoverwrites with whatever split MLB’s API happens to return next, in whatever order the APIhappens to return them. For a player traded mid-season, the old club is often the only onewith any stat rows at all: Rutschman had two Baltimore rows for 2026 and zero for Boston,because he went straight to Boston’s injured list without playing a game there yet. So everytime his stats got re-synced — including just from a page view triggering a background refresh —his team flipped back to the club that had traded him away, silently, with a normal-lookingupdated_at timestamp as the only trace.

The fix was to make that write fill-only: populate a missing team, never overwrite an existingone. A stats importer has no business deciding a player’s current club — that’s what the tradesync and MLB’s own parentOrgId field are for. The importer can still help a player that thoseother syncs haven’t reached yet, which is the entire reason the write existed in the firstplace; it just can’t outrank them anymore.

Fixing this repaired 51 players who’d been reverted by exactly this path.

Bug 3: the schema that quietly dropped the answer

There was a third bug feeding into the same symptom, found a few days earlier in the same chase:fix-milb-teams, a job meant to correct minor-league team assignments, saw Rutschman parked ona non-MLB affiliate, decided that looked broken, and “fixed” it by picking whichever MLB clubhe’d played the most games for historically — which, for a player traded five days ago onto aninjured list, is always the old team. Volume-based inference is exactly backwards for someonewho just moved.

MLB’s API does hand back the correct answer directly, as currentTeam.parentOrgId. But our Zodschema for the player payload didn’t declare that field, and Zod drops unknown keys by default —so the correct value arrived from MLB and was silently discarded before any of our code ever sawit. The first draft of this fix read parentOrgId, got undefined, and would have quietlyfallen back to the same broken most-played-games logic while looking like it had been fixed. Ionly caught that by checking the parsed output against the raw response, not trusting thatadding a schema field was enough on its own.

With parentOrgId declared and read, fix-milb-teams now asks MLB directly instead ofinferring from history. Repair applied to the 328 players whose team contradicted their mostrecent trade: 52 genuinely wrong, corrected; 276 were false positives from the detection queryitself — players like Verlander and Scherzer, whose team correctly differs from an old tradebecause they’ve since moved again on their own. The script checks with MLB before touchinganyone, so only the 52 real mismatches changed.

What all three had in common

None of these bugs were exotic. A namespace typo. A missing recency check with a comment thatlied about having one. A schema that silently dropped a field. Individually they’re the kind ofthing you’d catch in five minutes. What made them dangerous together is that each one’s silencelooked exactly like the previous fix working: flush the cache (nothing happens, but it saysit worked), so you conclude the data itself must be wrong; fix the importer (the revert stopsfor a while, until the next stats sync), so you conclude the trade sync must be flaky; add theschema field (still wrong, because the value was never read), so you conclude the API itselfmust be inconsistent.

The lesson I keep relearning on this project: a tool that can silently do nothing is worse thana tool that fails loudly, because it burns your best hypothesis on every pass. The actual fix,each time, was smaller than the investigation it took to find it.

— James

The trade board today — the Skubal and Rutschman deals are the two real trades this whole build kept getting checked against.

First, the data had to stop lying about who was in a trade

Before any ranking could matter, the transactions table had a structural bug: Transaction.idwas declared as the primary key, but MLB’s Stats API id field is a deal identifier shared byevery player in that trade, not a per-person id. A four-player trade upserts four rows that allshare one id — so each row overwrote the last, and only one player of every multi-player dealever survived in the database. The natural key needed to be (dealId, personId), not id alone.Re-keying that was the precondition for everything that followed: you can’t rank a trade’splayers if the database only remembers one of them.

With the key fixed, I ran a one-off backfill pulling MLB’s transaction history in monthly windowsfrom January 2016 through the present. The first full run silently dropped 56 of 128 windows.The cause: the API client wrapped its schema validation in a try/catch that swallowed any Zoderror and returned an empty array — so one malformed record failed validation for the entiremonth, and the caller had no way to distinguish “zero trades this month” from “parsing blew upand we got nothing.” The captured Zod errors pointed at the real cause: some historical records(pre-2020 releases, minor-league moves) omit a name field on the traded-to or traded-from teamthat the schema had marked required. Making that field optional, and adding a strict variant ofthe fetch that rethrows instead of swallowing, turned “quietly wrong” into “loudly correct”: there-run processed all 132 windows with zero failures, landing 513,690 transactions including 5,883trade records going back a decade.

Estimating control years without contract data

A trade’s weight depends heavily on how many years of team control each player still has left —but this project has no contract or service-time database yet. So I built an estimator thatworks from what’s actually available: MLB debut date, bucketed into EXPIRING / SHORT /MEDIUM / LONG control windows based on years of service.

Before shipping it, I ran the validation the spec called for: hand-check the 25 active playerswith the highest career WAR — the worst case for a debut-date-only heuristic, since long-tenuredstars are exactly who tends to sign extensions the heuristic can’t see — against their realcontract status via web search. 15 of 25 (60%) were false positives. The heuristic wascalling players “expiring” who were actually locked up for years.

60% is well above the 25% threshold the spec had set as an acceptable error rate for a roughestimate, so the fix wasn’t a tuning pass — it was changing what the UI claims. The bucket’sdisplay label went from the confident-sounding RENTAL to the honest CONTRACT UNKNOWN, andevery control estimate in the product now carries a persistent confidence: 'estimate' flag.The estimator wasn’t good enough to assert a fact, so the product stopped asserting one.

Scoring “blockbuster” against real trades, not intuition

The ranking itself — scoreBlockbuster() — blends six weighted signals: star power, awards,headcount, estimated control years, deadline proximity, and whether the trade crosses leagues.The weights aren’t guesses. They’re derived by scoring all 201 real MLB trades from the 2026season against three different candidate models — star-dominant, package-weighted, and aWAR-rate model — and picking the one whose output actually matched a human sense of “how big wasthis trade,” which meant falsifying and discarding the first two before landing on the currentone.

Two bugs surfaced in the process worth calling out because both hid behind a passing test suite:

Award matching was silently wrong. The scorer needs to recognize award types like Cy Youngand MVP, but the real award_type values in the database are granular — WS_MVP, ALCS_MVP,NLCS_MVP, ALL_STAR_MVP all contain the substring MVP. A naive substring match would scoreevery one of those as a full regular-season MVP. Worse, the test fixture for the headline Skubaltrade used awardType: 'AL_CY_YOUNG' — a value that doesn’t exist anywhere in the real data (CyYoung is stored league-neutral as CY_YOUNG, with league in a separate column). That typo meantthe fixture silently fell through to the generic unknown-award fallback weight instead ofexercising the actual Cy Young weight — so the single highest-value award in the whole config hadzero real test coverage, and the test suite was green the entire time. The fix was exact-keymatching plus a corrected fixture pulling Skubal’s real award rows straight from the database.

Truncation before filtering. A related bug in the trade-detail page: getPlayerTradeDealsscanned a date range and capped it with limit: 500 before filtering to the player beingviewed. Across a full career that window holds thousands of deals, so for a player with enoughtransaction history, their trade could get cut by the limit before the filter ever ran. The fixwas to select by dealId directly instead of truncating a superset and hoping the targetsurvived. This is the same shape of bug as the ranking’s earlier limit-then-filter mistake in adifferent query — worth naming as a pattern: never truncate a set you’re about to filter.

What actually shows up in the product

The result is what’s on the trade board now: every deal shows real WAR, real awards, and acontrol-year estimate that’s honest about being an estimate — not a synthetic “trade grade”dressed up to look more certain than the underlying data supports. The Skubal/Dodgers-Tigers dealthat ran through every stage of this build as the reference case — four players, real awards, aCy Young winner headlining one side — is the top-ranked trade of the season, which is also justtrue.

— James

The theme is written against Hexo 4.x’s generator and renderer APIs specifically. Upstream Hexo has moved past that, so floating a ^4.2.1 dependency was never going to be safe long-term, there was no version of “just upgrade” that didn’t mean rewriting the theme. So I vendored it instead: Hexo 4.2.1 lives at packages/hexo now, published locally as @jameswomack/hexo, installed via "hexo": "file:packages/hexo" so it lands in node_modules/hexo right where hexo-cli expects it. Every hexo-* plugin version is pinned exact, no carets, and package-lock.json is finally tracked. The tree can’t drift out from under the theme again because nothing in it is allowed to move on its own anymore.

Before trusting it I ran hexo generate under Node 20, 22, and 24 and diffed the output. Byte-identical, except sitemap.xml‘s entry order, which turned out to be non-deterministic tie-breaking on same-timestamp posts, not a real difference. .nvmrc moved to 24.7.0 for Vercel the same day.

Fifteen minutes after that landed, npm audit flagged send under 0.19.0 for a template injection XSS, GHSA-m6fv-jmcg-4jfg, reachable through hexo-server and hexo-browsersync, both of which are dev-server-only and both of which haven’t been touched upstream in years. No fixed version existed inside their declared ranges. Forced send to 0.19.2 and serve-static to 1.16.3 via package.json overrides. Tried jumping serve-static straight to 2.x first, that broke hexo-browsersync‘s plugin loading outright, its wrapper assumes the 1.x API, so back to the patched 1.x line instead.

Fitting, in a way, to be doing this kind of plumbing work on the same blog that’s currently telling you about it. Still finding these, four commits later it was a footer “Next »” link rendering as literal escaped text because of the same paginator helper’s default escaping. Old software has old corners.

This is the engineering story — the musical decisions and the programming ones — with thewar stories left in.

The suite today:

• Womack FX — a fuzz → univibe → tape-delay pedalboard (aufx).
• Womack Resonote — a note-quantized resonant filter/EQ, single- and multi-band (aumf).
• Womack Lyriqueue — session-stored lyrics with a playhead-following teleprompter (aufx).
• WomackBus — a shared, in-process message bus the plugins register on.

Stack throughout: JUCE 8.0.12, C++20, CMake (Xcode generator), building AU +VST3 + Standalone, unit-tested with JUCE’s console UnitTest runner, signed and notarizedfor distribution.

Part 1 — Resonote: making a filter that knows about notes

Most EQs think in raw Hz. Musicians think in notes. Resonote closes that gap: its cutoffcan snap to note frequencies, optionally constrained to a key, with a live cents-from-nearestreadout so you always know how in-tune the resonance is.

Note math you can trust

The pitch math lives in a small, pure, unit-tested header (NoteFrequency.h): MIDI↔Hz,nearestMidi, noteName, centsFromNearest, and scale-aware snapping for chromatic, major,and minor. Keeping it pure meant I could test the tricky parts directly instead of poking ata filter and squinting at a spectrum.

One bug from this corner is worth calling out because it’s so ordinary: the cents readout onceshowed +9.61706e-05 c. juce::String(cents, 0) doesn’t round — it formats — so a whiskerabove zero printed in scientific notation. The fix was a juce::roundToInt before display.Tiny, but it’s the difference between “precise instrument” and “toy.”

The warmth: one SVF with a tanh in the feedback

The heart of Resonote is a single zero-delay-feedback TPT state-variable filter(ResonantSVF). It runs in Bell, Low-Pass, or High-Pass mode. The only “analog” trick — andit’s deliberately the only one — is a tanh nonlinearity in the resonance feedback path.

That tanh does two jobs. It adds a gentle, level-dependent saturation as resonance climbs —the “warmth” — and it self-limits, so the filter stays stable and never tips intoself-oscillation. That let me be aggressive with the resonance range. resonanceToQ maps anormalized 0..1 knob to Q ≈ 0.5 … 75:

1
2
3
4
5
6

// 0..1 -> Q 0.5..~75, musically weighted toward the top of the range.
float resonanceToQ (float r) noexcept
{
    r = juce::jlimit (0.0f, 1.0f, r);
    return 0.5f + std::pow (r, 3.0f) * 74.5f;
}

Cranked, it sings on a note without ever howling — because the tanh in the loop eats therunaway energy that self-oscillation would need.

The fisheye response curve

An EQ curve on a log-frequency axis wastes its most interesting real estate: the region rightaround where you’re working is cramped. So Resonote’s response display bends space. It drawseverything through a horizontal fisheye — an erf “bump” that magnifies the area aroundthe current cutoff and compresses the far edges — plus a subtle convex vertical bow for atactile “glass” feel.

Schematic illustration (not a screenshot).

The real Resonote UI in Logic Pro — single band, cutoff snapped to A3.

The horizontal mapping from a normalized log-frequency position u ∈ [0,1] to a pixel x is:

1
2
3
4
5
6

// erf "bump" centred on u0 (the cutoff), pinned at the frame edges.
float uToX (float u) const noexcept
{
    const float bump = lensStrength * (std::erf ((u - lensU0) / lensWidth) - lensBumpAt0);
    return lastArea.getX() + ((u + bump) / lensDenom) * lastArea.getWidth();
}

Because uToX is monotonic increasing in u, it has a well-defined inverse — and I needthat inverse constantly: to hit-test the mouse against the curve, and to let you drag thecrossover handles between bands and have them land exactly on the boundary they control.Rather than derive a closed-form inverse of an erf, I just bisect:

1
2
3
4
5
6
7
8
9
10
11
12

// uToX is monotonic in u, so bisect for its inverse. ~30 iterations over [0,1]
// is well below sub-pixel at any realistic width.
float xToU (float x) const noexcept
{
    float lo = 0.0f, hi = 1.0f;
    for (int i = 0; i < 30; ++i)
    {
        const float mid = 0.5f * (lo + hi);
        if (uToX (mid) < x) lo = mid; else hi = mid;
    }
    return 0.5f * (lo + hi);
}

Thirty iterations is nothing per frame, it’s trivially correct, and it means the exact samewarp is used for drawing and for interaction. The handles never drift off the slabs they sit on.

Multiband: up to four bells that don’t step on each other

Resonote grew from one band to up to four, each a colour-coded bell with its ownfrequency, resonance, and gain, and each confined to a mutually-exclusive range at least anoctave wide. A + / – LED changes the band count; adding a band auto-splits the spectrum,after which the crossovers are draggable (through that same fisheye inverse). Each band alsogets tempo-synced resonance modulation — an LFO with a per-band depth and a host-syncedrate, plus a global shape.

Schematic illustration (not a screenshot).

Multiband Resonote in Logic with Suite Spectrum on — the greyed “Organ Donations” ghost marker is another instance’s frequency, and the readout names the combined chord.

The chord detector I had to rip out and rewrite

The multiband version reads out the chord formed by the active bands. My first attempt washand-rolled, and it was simply wrong: for the notes of an F minor 7 itdisplayed F +3 +5 +7 — printing raw semitone offsets as if they were chorddegrees. For a music app, that’s just not good enough.

There is no clean drop-in C++ chord library, so I ported the algorithm that the JavaScriptworld trusts — tonal.js-style detection: normalize the pitch classes, then rotate throughevery note as a candidate root, match the resulting interval set against known chordqualities, and prefer the interpretation with the best root; fall back to slash-chordinversions (C/E) and, only if nothing matches, to an honest note-name list rather thanfake degrees. Augmented-7 spells as aug7, never +7, precisely because a + had been thesymptom of the old bug.

The lesson wasn’t “chords are hard” (they are). It was: when your domain has a correct answer,either compute the correct answer or say you can’t — don’t invent notation that looks right.

Part 2 — The Logic bug class that bit us three times

Here’s the war story every plugin dev should internalize.

Resonote’s visualizer, note readout, and chord display all read their values from smallstd::atomic snapshots that were written inside processBlock. In the Standalone app thatwas fine — the audio device runs continuously, so processBlock fires forever and the snapshotsare always fresh. Ship the same binary into Logic, stop the transport, turn a knob… andnothing moves. The curve freezes. The chord goes stale. It looked broken, and only in the DAW.

The root cause: Logic doesn’t call processBlock when the transport is stopped (and onlydoes at all when audio flows through the track). Reading UI values from process-time snapshotscouples your interface to the transport state. The fix is a one-liner in spirit — read theparameters directly on the message thread, not the process-time mirror — and I routed everyUI getter through a single effectiveBandFreqHz() helper so the audio path and the display cannever disagree.

It bit three times: first the band count stuck at 1, then the whole visualizer + chordreadout went inert, then Lyriqueue’s transport readout froze for the same reason.“Works in Standalone, dead in Logic” is now a smell I recognize instantly.

The sibling gotcha: change gestures

While chasing the band-count issue I hit its cousin. Writing a parameter from code withsetValueNotifyingHost works in Standalone and silently reverts in Logic — unless youbracket it in a gesture:

1
2
3

param->beginChangeGesture();
param->setValueNotifyingHost (newValue);
param->endChangeGesture();

Logic treats an un-gestured programmatic write as noise and rolls it back. Standalone doesn’tcare. Same shape of bug, same “only in the DAW” signature.

The meta-lesson: Standalone is a liar of omission. It’s a great fast loop, but the DAW isthe only ground truth. auval on every build, then quit-and-reopen Logic (it caches AU binariesin memory) before you trust anything.

Part 3 — Lyriqueue: lyrics that follow the playhead

Lyriqueue stores lyrics in the session and shows a teleprompter that follows the DAW’splayhead, cue by cue, in musical time. Cues are stored canonically as absolute PPQ(quarter-notes from song start) and rendered as Bar.Beat.Ticks using the host’s timesignature. The active line is simply “the cued line with the greatest cue ≤ now.”

An early version showed impossible Bar.Beat.Ticks values; the fix was to do all arithmetic inPPQ and convert once at the edges, so beats and ticks always roll over musically.

It’s an aufx audio effect that doesn’t touch the audio — which produced a genuinely confusingsupport moment: on a silent track, Logic never processes it, so the playhead never arrivesand following looks broken. The right move wasn’t code gymnastics; it was discoverability —a live transport readout plus a “waiting for transport” hint that appears only when the host hasnever processed the track (detected with a processBlock counter that never advances), andlatches off the instant a block arrives so it never nags on a working track.

Lyriqueue’s teleprompter in Logic — the amber line at the bottom is exactly that “waiting for transport” hint.

Part 4 — WomackBus: the shared bus that almost wasn’t

This is the part I’m proudest of, because it looked done, passed its tests, and was quietlywrong.

I wanted the plugins to be a suite — to share musical context in one process. So I builtWomackBus: a process-wide singleton with a client registry, a small blackboard, and changelisteners; each plugin owns a RAII WomackBusClient that registers on construction andunregisters on destruction, and shows a tiny “Womack ×N” presence badge.

I built WomackCommon as a static library, linked it into each plugin, saw the badge show×1, shipped it. The unit tests were green. The badge was… always ×1 across differentplugins.

Why static linking silently broke it

A function-local-static singleton (WomackBus::get()) linked statically into two separateplugin bundles gets duplicated — each bundle carries its own copy. On macOS with thedefault two-level namespace, strong duplicate symbols are not coalesced across separatelyloaded bundles. So Resonote had one bus, Lyriqueue had another, and they never saw each other.Two instances of the same plugin shared (same image); two different plugins did not.

nm shows it plainly — every plugin binary defined the symbol (T), instead of importing it:

1
2
3
4

$ nm "Womack Resonote" | grep WomackBus3getEv
0000000000009ea0 (__TEXT,__text) external __ZN9WomackBus3getEv     # T: its OWN copy
$ nm "Womack Lyriqueue" | grep WomackBus3getEv
0000000000009094 (__TEXT,__text) external __ZN9WomackBus3getEv     # T: a DIFFERENT own copy

The fix: one shared, JUCE-free dylib

WomackCommon became a single shared dylib with an absolute install name under a shareddirectory (/Library/Application Support/Womack for installs; ~/Library/Application Support/Womackfor dev). Every plugin records that one path, so at load time dyld maps one copy — one busper process. Now nm shows the symbol imported (U) everywhere:

1
2
3
4

$ nm "Womack Resonote" | grep WomackBus3getEv
                 U __ZN9WomackBus3getEv          # imported from the shared dylib
$ otool -L "Womack Resonote" | grep Womack
    /Library/Application Support/Womack/libWomackCommon.dylib

There was one more trap I designed around from the start of the rewrite: the dylib’s ABI isdeliberately JUCE-free — std::string, a plain std::uint32_t ARGB, plain structs. Why?Each plugin already embeds its own JUCE runtime. If the shared dylib also linked JUCE and Ipassed, say, a juce::Identifier or juce::String across the boundary, I’d be sharing objectsthat reference JUCE’s global string pool — but there’d be two JUCE runtimes with two pools.That’s a corruption waiting to happen. Keeping the bus boundary to std types means it links onlylibc++/libSystem (verifiable with otool -L) and can’t entangle the runtimes. Pluginsconvert juce::String ↔ std::string at the edge.

The installer ships the dylib as a required component (always installed), Developer-ID signedand notarized alongside the plugins.

The takeaway: green tests are necessary, not sufficient. The bus’s logic was alwayscorrect — N clients produce count N. What was wrong lived in the linking, a layer the unittests couldn’t see. nm/otool were the tests that mattered here.

Part 5 — Where it’s going: shared musical context

With one real bus in place, the suite can finally share music, not just presence. The nextpiece (in progress) adds two things over the bus, both opt-in, both symmetric-peer:

1. Shared key — turn on “Sync Key” and changing root/scale in one instance updates theothers (with origin-id + value-compare + an “adopting” guard so it can’t echo forever).
2. Frequency-signature awareness — each Resonote publishes the frequencies it occupies, andevery instance can see the others’ occupied frequencies as coloured ghosts on its own curve,with a warning when two land within 50 cents of each other. Put a Resonote on a piano andanother on an organ, and each can carve out its own spectral pocket instead of fightingfor the same one. Awareness first; you carve manually; automatic avoidance is on the backlog.

A future Womack Ex Machina on the master bus can then become the leader that drives thewhole suite — but that’s a later chapter.

How it’s built

A few process notes, because they mattered as much as the DSP:

• Worktree per task. Every change happens on its own git worktree/branch; main only everreceives tested, confirmed work. Multiple build sessions never collide.
• TDD on the pure parts. Note math, band ranges, chord naming, and the sync helpers are allpure and unit-tested (ResonoteTests, WomackBusTests) before they touch a filter or a UI.
• Subagent-driven development. Larger features are executed task-by-task with a freshimplementer per task and a spec + code-quality review after each — plus a broad review beforemerge.
• Validate relentlessly. auval on every build for all three plugins; nm/otool for thelinking guarantees; quit-and-reopen Logic before trusting a change.

Closing

The fun of this project has been that the musical problems and the systems problems keepturning out to be the same problem viewed from two sides. A filter that “knows about notes” isequal parts pitch math and a fisheye you can drag. A “suite” is equal parts a shared key and asymbol that must be U and not T. And the recurring humbling lesson — from the scientific-notation cents, to the F +3 +5 +7 chord, to the bus that passed its tests while being wrong —is that looking right is not the same as being right. The DAW, the linker, and the musictheory all get a vote.

More soon, once instances can carve out their own place in the mix.

— Womack Audio

The prediction surface this loop feeds — a real game, produced by the champion model after all three fixes below.

Bug 1: the eval set that stopped growing

The gate that decides whether to promote a new model runs entirely against games flaggedheld_out = true. That flag is a persisted boolean, and it was only ever set by a one-offbackfill script — the daily import path that adds new games as the season progresses never setit. So the holdout set froze at whatever the last manual backfill happened to cover: 120 games,static, while every game imported afterward leaked into the training set instead. Two evalreports run a month apart came back byte-identical — same 120 games, same Brier score to fourdecimal places — because the loop was judging every new candidate against a yardstick thathadn’t moved in a month.

The fix was to stop treating “mark the holdout set” as a manual, one-time step: importGamesnow assigns heldOut at insert time for every game, using the same holdout-selection rule thebackfill script used, so the eval set grows deterministically with every import and can’t driftout of sync again. Re-running the backfill once to catch the 67 games that had already leakedbrought the holdout set current — 187 games instead of 120.

Bug 2: a fixed threshold that noise could clear

With a live holdout set, the next problem was the promotion gate itself. It compared aggregatecomposite scores against a flat epsilon = 0.005 — if the candidate beat the champion by morethan that, it got promoted. But per-game Brier-score noise on a ~180-game holdout runs around±0.02, several times larger than the threshold meant to detect real improvement. The gate wasmostly reacting to noise: on at least one occasion it treated a +0.025 swing that was almostcertainly sampling variance as a genuine, promotion-worthy gain. And because the epsilon wasfixed, a growing holdout set — which should make the gate more discerning as more data comesin — never actually lowered the bar for what counted as a real signal.

The fix replaced the flat threshold with a paired one-sided significance test on per-gamecomposite scores: compute the champion-minus-candidate delta on the same holdout games for bothmodels, and promote only when the lower bound of a 95% confidence interval on that delta clearszero. As the holdout set grows, the standard error shrinks, so smaller real gains becomedetectable over time — the gate gets sharper with more data instead of staying flat forever. Adry run against the live 180-game holdout immediately started returning honest reasons insteadof noisy verdicts: a worse candidate failed on a negative lower bound; a directionally-bettermodel (a real +0.0010 edge, ±0.0066) correctly failed as not yet statistically significantrather than being promoted on what was still mostly noise.

Bug 3: the tuner that optimized for the wrong exam

Fixing the gate exposed the last problem. The coordinate-descent tuner that produces eachcandidate ran to convergence minimizing composite score on a single ~785-game walk-forwardsample, then got graded on the separate holdout set. That’s an overfitting setup byconstruction: the tuner wins on the sample it was allowed to see and loses on the one it wasn’t— in this case, +0.017 on walk-forward against −0.023 on holdout, which now correctly failed thesignificance gate every single time.

The fix added an explicit shrinkage-to-champion penalty to the tuning objective —composite + λ · penalty, where the penalty is the range-normalized distance from the currentchampion’s weights — and chose λ by k-fold cross-validation rather than by hand: for eachcandidate λ, tune on k−1 folds and score the held-back fold on pure composite (no penalty term),and keep the λ whose out-of-fold score is best. λ = 0 stays in the search grid, so a genuinelygeneralizing tune is never blocked from winning outright.

On the same live holdout, the heuristic candidate’s performance went from −0.0234 (overfit) to+0.0003 — and the CV procedure chose λ = 2, which is the tuner correctly concluding that thedata doesn’t support moving off the champion at all. That microscopic +0.0003 edge alsocorrectly fails a companion fix from the same pass: a minimum-effect-size floor on thesignificance gate, added after noticing that heavy shrinkage makes a candidate converge towardthe champion so closely that its paired variance collapses too, letting a statistically“significant” but practically meaningless edge slip through a bare > 0 check. Requiring theconfidence interval to clear a real minimum, not just zero, closed that gap.

Why the order of these fixes mattered

None of the three bugs were individually exotic — a flag that never got set, a threshold thatdidn’t account for sample noise, an objective that didn’t match its own exam. What made this amulti-week chase rather than a single fix is that each one made the next one look like thereal problem. A frozen holdout set makes a noisy gate look stable, because it’s comparingagainst the same games every time. A noisy gate makes an overfitting tuner look successful,because noise-driven promotions occasionally go through. Only once the eval set was current andthe gate was honestly measuring uncertainty did the tuner’s overfitting become visible as itsown distinct bug rather than getting attributed to “the gate is too strict” or “the holdout istoo small.”

The loop is mechanically sound now — it evaluates on a live holdout, requires statistically realimprovement at a real effect size, and tunes candidates against an objective that generalizesinstead of memorizing. heuristic_v9 is already near-optimal for its current feature set, andneither a re-tuned version of itself nor a logistic-regression challenger beats it meaningfullyright now, which is the gate correctly reporting a true negative rather than a broken positive.Getting further gains from here is a features-and-data problem. It’s no longer aloop-machinery problem, and proving that distinction was most of the actual work.

— James

So I wrote a PreToolUse hook. It sits in front of every Bash call and denies anything that looks destructive against those two: redis-cli DEL/FLUSHALL/SET/HSET/EXPIRE/RENAME, and psql DROP/DELETE/TRUNCATE/UPDATE/anything with ALTER ... DROP|RENAME. Read-only and additive operations pass right through. It’s not a “no touching the database” hook, it’s a “no overwriting production by accident” hook.

It pairs with a hook that already blocked killing or restarting the dev servers, and with a step in this project’s architecture-check skill that makes me, or an agent reading the skill, state a blast-radius verdict before writing code that touches shared infra. Three separate nets for the same failure mode, because I’ve watched it happen at least once each way.

The honest reason I built this w/ a hook instead of a note in CLAUDE.md: instructions are advisory, hooks are not. I’d rather over-trust a shell script than a language model’s reading comprehension when the blast radius is “the database everyone’s using.”

The batting-average and ERA/WHIP leaderboards are supposed to carry a minimum sample size, at-bats for hitters, innings for pitchers, otherwise you get exactly this: someone who went 2-for-3 outranking someone who went 180-for-560. The backend already supported it. getStatsLeaders in the API client accepts minAtBats/minInningsPitched, the route maps them, the SQL applies them as AND at_bats >= N. The one place that was supposed to send them, a single call site in the leaderboards page, just didn’t. It only passed minGames.

One missing line, in other words, was the entire distance between “AVG leaderboard” and “who’s had the luckiest 3 at-bats this week.”

Fixed, and now the real floors apply, 200+ AB for AVG/OPS, 50+ IP for ERA/WHIP. Judge, Alvarez, Arraez, the names you’d actually expect.

The overlay meant to cover stale rows while new ones loaded used bg-card for its background and bg-muted for the skeleton shapes. In this theme both of those resolve to blue-tinted dark values, so every stat switch painted a blue rectangle over black-and-grey rows for a beat. Nobody designed that. It’s just what two independently-reasonable Tailwind classes do once you stack them.

The fix was to stop covering the content and dim it instead: drop the skeleton overlay div entirely, set the real rows to opacity: 0.4 while fetching, block clicks with pointerEvents: none until the new data lands. Real colors stay real colors, just quieter for a moment. Skeleton rows, the animate-pulse placeholders, are still there for a true cold load with nothing cached yet. They just don’t fire on every category switch anymore.

Chasing that down surfaced a second, uglier one: switching from a hitting category to a pitching category for the first time in a session returned no cached data for that query key, so the whole table got replaced by skeleton rows instead of just dimming. Fixed by keeping a ref to the last non-empty result set and falling back to it across query key changes, so the previous category’s rows sit underneath as the background while the new ones fade in over top.

Small bug. Embarrassingly satisfying to finally kill.

It started with GitHub Actions deprecating Node 20 on its runners, a warning on every job, while all four CI jobs still hardcoded node-version: 20 against a local/prod toolchain already on Node 24 via .nvmrc. Switched every setup-node step to node-version-file: .nvmrc so CI can’t drift from the one file that’s supposed to be the source of truth, again.

That unstuck the next one: husky‘s prepare script runs on every npm install, including Vercel’s production install, where there’s no .git directory and husky exits non-zero. Vercel deploys had been failing on that alone. Gated it behind a .git existence check.

Past that, tsc failed with about 250 errors, all downstream of one thing: nobody had run prisma generate before it. Vercel caches node_modules and skips regeneration by default. GitHub CI only worked because its build job ran prisma generate explicitly first. Added it as a postinstall and prepended it to build, so the client exists before tsc touches it in any environment. prisma generate only reads schema.prisma, no DATABASE_URL required, so it’s safe in a DB-less build too.

Then the deployed function crashed at import: winston’s File transport calls mkdirSync('logs') on construction, and Vercel’s filesystem is read-only. Gated the file transports on a serverless check (VERCEL/AWS_LAMBDA_FUNCTION_NAME) and wrapped construction in try/catch. Console transport is enough there, Vercel captures stdout anyway.

None of this makes the API actually happy running on Vercel, that’s a persistent Fastify server with node-cron and a live Redis connection, a different problem for a different day, tracked and deliberately backlogged. This week was just about getting the pipeline green again without six people’s worth of “works on my machine.”

Four endpoints under /api/today, each cached 5 minutes, and search got a new intent detector, detectTodayIntent(), that recognizes four shapes of question: what games are on today, who’s leading today, how’d a specific player do today, how’d a specific team do today. It slots into the existing semantic search response as an optional field rather than a separate code path, so “what’s the score of the Yankees game” and “who’s on pace for 40 home runs” both come out of the same box.

On the frontend, a TodayBand widget on the homepage, a game rail plus tabs for home runs, strikeouts, and total bases, refetching itself every 5 minutes via react-query. It also seeds the plumbing for live in-progress linescores, which isn’t built yet, GameCardLive already accepts a linescore prop, there’s just nothing populating it. That’s its own ticket. Shipping the “today” layer without the “live, mid-game” layer felt like the right cut. One is a poll every 5 minutes against data MLB has already finalized. The other is a websocket-shaped problem I didn’t want to solve in the same afternoon.

Fixed it as a priority chain instead of one flat check: if the dropdown’s showing, close the dropdown. If it’s not, but there’s text in the input, clear the input. Only quit the program if neither applies, dropdown hidden and input empty. Escape now does the smallest reasonable thing first and only exits as a last resort, which is what everyone means by “hit escape” in literally every other program with a text field.

Fixed with one query instead of two: DISTINCT ON (player_id) ORDER BY player_id, team_id ASC picks the team_id = 0 row for anyone who has one and falls through to their single per-team row otherwise, then the outer query sorts and takes the top N like it always should have. Checked it live after: Judge, Alvarez, Schwarber, back where they belong.

Small, dumb, expensive bug. The kind where the fix is three lines and the entire distance between “leaderboard” and “not a leaderboard” was one wrong WHERE clause the whole time.

generateGamePrediction() had the weights hardcoded as literals, eraSwingMax, parkRunFactorWeight, homeAdvantageBase, the works, regardless of which model version the database said was champion. The tuner could promote a model with meaningfully different weights and the prediction endpoint would go on doing exactly what it had always done. Self-improving in name only.

Fix was to actually read the champion: getCurrentChampion() loads its weights once at the top of generateGamePrediction, and calculateWinProbability takes them as a parameter instead of reaching for a constant. Checked it against a real game, Nationals at Marlins on May 10th: 38% home win probability under v9, 46% under v0, an 8-point swing from wiring alone, no new data, no new model, just finally using the one that had already won. Across that week’s slate of 92 games, v9 picks the home team 47% of the time vs v0’s 65%. The old hardcoded weights had a structural home-field bias that was never supposed to survive a real promotion.

Somewhere on this project there’s a lesson about verifying the thing you shipped is the thing that’s running. I already knew that lesson. Here we are anyway.

Node/CorePack

One of those is Node’s corepack, which holds pnpm as an add’l official package manager that it will manage for you. You enable corepack like so. You declare which package manager and version thereof your Node project is using like so

Node::Test

Another is the introduction of the Node-native test package, which works really nicely with assert. assert has always been useful for Node projects but the introduction of test makes it so that jest is just not necessary for many projects

Experimental Permissions

Node 20 now has a method for locking down which system aspects your code can access & have side effects on. I’m predicting that this feature will also be useful for debugging issues related to third-party code interacting with the file system (e.g. “what the hell is mutating this file?”). Here is an example of making FS permissions read-only and limited to the current directory & its descendents. Experimental Node API usage triggers warning messages by default, I’ve also used an environment variable to silence those—the point of that repo is using experimental APIs

Tying it all together

By running these tests with pnpm I’m combining corepack, test & --experimental-permissions to verify that FS reads are enabled in the project directory, while FS writes are not

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import cluster from 'cluster';
import {createServer} from 'http';
import {cpus} from 'os';

const isMainCluster = cluster.isMaster;
const {length:CPUCount} = cpus();

if (isMainCluster) {
  console.log(`Main ${process.pid} is running`);

  // Fork workers.
  for (let currentCPU = 0; currentCPU < CPUCount; currentCPU++)
    cluster.fork();

  cluster.on('exit', worker =>
    console.log(`worker ${worker.process.pid} died`));
} else {
  // Workers can share any TCP connection
  // In this case it is an HTTP server
  createServer((req, res) => {
    res.writeHead(200);
    res.end('hello world\n');
  }).listen(8000);

  console.log(`Worker ${process.pid} started`);
}

Changes from the current Node.js ‘cluster’ docs include:

1. Using import over require
2. Using named imports over the default where feasible
3. Using clearer, more semantic identifier names, e.g. currentCPU v. i
4. Replacing archaic terminology, e.g. Master w/ Main

Output w/ ESM Node code w/ syntactical & semantic updates

1
2
3
4
5
6
7
8
9
10
11
12
13
14

> $ node index.mjs                                                                       ⬡ 14.15.1 [±main ●]
Main 57290 is running
Worker 57292 started
Worker 57295 started
Worker 57291 started
Worker 57294 started
Worker 57293 started
Worker 57296 started
Worker 57298 started
Worker 57297 started
Worker 57299 started
Worker 57300 started
Worker 57302 started
Worker 57301 started

See here for the full repo

Runningnpx jsinspect ./packages/agent/src/components/Itinerary/EditItinerary/*Step.js will give you a set outputs like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

./packages/agent/src/components/Itinerary/EditItinerary/FlightStep.js:132,136
<EditableInput
  textValue={formatMoney(step.sell, 'USD')}
  inputValue={step.sell}
  editOnly={true}
  inputProps={{ className: classes.editableAlignRight }}

./packages/agent/src/components/Itinerary/EditItinerary/RoadStep.js:136,140
<EditableInput
  textValue={formatMoney(step.sell, 'USD')}
  inputValue={step.sell}
  editOnly={true}
  inputProps={{ className: classes.editableAlignRight }}

------------------------------------------------------------

Match - 2 instances

./packages/agent/src/components/Itinerary/EditItinerary/RoadStep.js:94,97
<Paper className="stepLine" elevation={0} style={{ marginLeft: '0px' }}>
  <Box className="header">
    <Box className="type-icon">
      <AirportShuttle />

./packages/agent/src/components/Itinerary/EditItinerary/StayStep.js:284,287
<Paper className="stepLine" elevation={0} style={{ marginLeft: '0px' }}>
  <Box className="header">
    <Box className="type-icon">
      <Tipi />

------------------------------------------------------------

This is especially useful for finding unDRY code in large codebases that you are new to or aren’t wholly familiar with

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

{
  "libs": [
    "browser",
    "ecma5",
    "ecma6"
  ],
  "loadEagerly": [
    "./node_modules/abacus-notepad-component/dist/*.js",
    "./node_modules/activity-component/lib/*.js",
    "./node_modules/component-popup/src/popup.jsx",
    "./server/**/*.js",
    "./server/*.js",
    "./client/src/js/**/*.js"
  ],
  "plugins": {
    "node": {}
  }
}

We’re using TernJS and it’s loadEagerly option to have intelligent & dynamic autocomplete available in our JavaScript editor setup. It works anywhere from vim to Visual Studio Code. But I digress.

As out project grows, we add more entries. As our number of projects grow, it will likely get copied all over the place, including onto other developers’ machines that you do not control. Even if you did automate (and even control) the propogation and maintenance of this file, you’d have a problem: the module names, file paths and file names aren’t normalized. A file path is an address. Addresses are normalized in society because they serve a purpose that is not reached if humans cannot make assumptions about them. When identifying structures within the United States of America, addresses are generally normalized to meet the following assumptions:

• The first piece of the identifier is real number, with the vast majority being integers (a small percentage have a vulgar fraction appended). Most importantly, the overwhelming majority of US streets have the odd numbers on one side of the street and the even numbers on the other. Anecdotal evidence shows this to be even more important than chromatic sequence when locating a structure
• The second piece is almost always the name of the thoroughfare touching the land nearest the official entrance to the structure
• The (optional) third piece is a sub-identifier representing that identity of the unit within the structure identified by the preceding and succeeding pieces
• The fourth piece is the city name
• The fifth piece is the state name
• The sixth piece is the Zone Improvement Code or ZIP code. It consist of five- and four-digit integer separated by a hypen (or “dash”). This is, in my opinion, one of the weaker parts of the address system as most folks do not know the 4 digit appendage that was introduced in 1983, nor do they usually know many ZIP codes other than their own

Just as the home address system in the USA does, a file path convention will have stronger and weaker aspects to it. All the same, we all know having an address system is better than none, so why would you not have one for files? In retrospect it becomes an obvious choice.

Take a look at an improved .tern-project file, taking into account the lessons of the address system

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
  "libs": [
    "browser",
    "ecma5",
    "ecma6"
  ],
  "loadEagerly": [
    "./node_modules/abacus-*-component/lib/**/*.js",
    "./lib/**/*.js"
  ],
  "plugins": {
    "node": {}
  }
}

What changes did we make?

• Name all our team’s custom components using the format teamname-modulename-component
• Always put our transpiled/consumable JavaScript files in a folder named lib, organized into appropriate subfolders& always using the extension .js. This is the convention, whether it’s a small package or an application

That’s it! We went from 6 entries to 2 just like that.

Happy filemaking!

My thought is that this type of automation cannot solve the type of hiring problems we have at Netflix. Programming tests embody an extremely poor evaluation of senior programmers. Senior programmers leverage their past experience to effectively combine the best existing solutions in such a way that they’ve created some new, maintainable and sustainable. Senior programmers are good at working with others. They conform to, while incrementally improving, coding style and standards. The only way to pre-suppose about these things is looking through open source contributions, Stack Overflow answers, behavior on Twitter and then pair programming with them. An automated programming quiz merely tests how long they’ve spent doing automated programming quizzes.