DEV Community: Deland

Five things that break when a user pastes 𝕗𝕒𝕟𝕔𝕪 text into your app

Deland — Mon, 31 Aug 2026 13:45:47 +0000

Someone signs up for your app with the display name 𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮. Your length check passes. Your profanity filter passes. Your search index has never heard of them again.

The thing most people get wrong on first contact: this is not a font. Nobody installed anything. 𝓯 is not the letter f wearing a costume — it is U+1D4EF, MATHEMATICAL BOLD SCRIPT SMALL F, a separate character with its own code point. Unicode has a whole parallel Latin alphabet (several, actually), added over the years for maths notation, phonetics and enclosed symbols, and the copy-paste generator sites turned it into a bio decoration.

That distinction has consequences all the way down your stack. Here are the five that have bitten me.

1. Your length check counts the wrong thing

const name = '𝓯𝓪𝓷𝓬𝔶';

name.length          // 10
[...name].length     // 5
name.slice(0, 3)     // '𝓯\ud835'  ← a broken half-character

Everything above U+FFFF is stored as a surrogate pair in JavaScript strings, so .length returns UTF-16 code units, not characters. A 15-character display-name limit becomes a 7-character limit for these users, and a naive .slice() for a preview truncates straight through the middle of a code point and emits a lone surrogate. That lone surrogate is what shows up later as � in your emails, or as an invalid-UTF-8 error the first time it hits a stricter downstream service.

Use [...str] or Array.from(str) when you mean characters, and Intl.Segmenter when you mean what a human would call a character (that one also handles emoji with ZWJ sequences and combining marks).

2. Your blocklist stops matching

Whitelist validation is fine — /^\w+$/u rejects 𝓪𝓭𝓶𝓲𝓷 because \w is ASCII-only. The problem is everywhere you use a blocklist:

const reserved = ['admin', 'support', 'billing'];
reserved.includes('𝗮𝗱𝗺𝗶𝗻')   // false
'𝗮𝗱𝗺𝗶𝗻'.includes('admin')     // false

Reserved usernames, profanity filters, spam-keyword rules, moderation regexes: all of them compare against ASCII and all of them are trivially bypassed by a copy-paste generator. This is not a theoretical attack. It is how "support" impersonation accounts get past signup on platforms that only check the literal string.

3. Search and sorting silently misbehave

'𝓯𝓪𝓷𝓬𝔶'.includes('fancy')            // false
['banana', '𝓪pple', 'cherry'].sort()  // ['banana', 'cherry', '𝓪pple']

The sort result is not a bug — default sort() compares code units, and U+1D4EA sorts after every ASCII letter. But it means the user who styled their name is now at the bottom of every alphabetical list in your product, and unfindable by typing their name into your search box. They will report this as "search is broken."

4. NFKD fixes most of it, and then stops

Unicode normalisation is the standard answer, and for the maths alphabets it works beautifully:

'𝓯𝓪𝓷𝓬𝔶'.normalize('NFKD')    // 'fancy'
'𝗯𝗼𝗹𝗱'.normalize('NFKD')     // 'bold'
'ᵗⁱⁿʸ'.normalize('NFKD')      // 'tiny'
'ⓑⓤⓑⓑⓛⓔ'.normalize('NFKD')   // 'bubble'

Then you hit this:

'ᴛɪɴʏ ᴛᴇxᴛ'.normalize('NFKD')   // 'ᴛɪɴʏ ᴛᴇxᴛ'  ← unchanged
's̶t̶r̶i̶k̶e̶'.normalize('NFKD')       // 's̶t̶r̶i̶k̶e̶'      ← unchanged

Two different reasons, both worth knowing.

Small caps are not decorated letters. ᴛ is U+1D1B, LATIN LETTER SMALL CAPITAL T, from the Phonetic Extensions block. Linguists needed it to write IPA. It has no compatibility decomposition to t because, as far as Unicode is concerned, it is not a t — it is its own letter that happens to look like a small one. NFKD is defined by those decomposition mappings, so there is nothing for it to do. .toUpperCase() won't touch it either.

Strikethrough and Zalgo are combining marks. s̶ is a plain ASCII s followed by U+0336 COMBINING LONG STROKE OVERLAY. The base letter was there all along; normalisation has no reason to remove a mark you deliberately added.

So the complete fold needs three passes, not one:

const SMALL_CAPS = {
  'ᴀ':'a','ʙ':'b','ᴄ':'c','ᴅ':'d','ᴇ':'e','ꜰ':'f','ɢ':'g','ʜ':'h','ɪ':'i',
  'ᴊ':'j','ᴋ':'k','ʟ':'l','ᴍ':'m','ɴ':'n','ᴏ':'o','ᴘ':'p','ǫ':'q','ʀ':'r',
  'ꜱ':'s','ᴛ':'t','ᴜ':'u','ᴠ':'v','ᴡ':'w','ʏ':'y','ᴢ':'z',
  // no x: Unicode's small capital X is unrenderable in most fonts, so
  // generators leave lowercase x alone and there is nothing to fold.
};
const SMALL_CAPS_RE = new RegExp(`[${Object.keys(SMALL_CAPS).join('')}]`, 'gu');

function foldFancy(input) {
  return input
    .replace(SMALL_CAPS_RE, (c) => SMALL_CAPS[c])  // before NFKD: ǫ would decompose first
    .normalize('NFKD')                    // maths alphabets, super/subscript, circled
    .replace(/\p{Mn}/gu, '')              // combining marks: strikethrough, underline, Zalgo
    .replace(/[^\P{C}\n\t]/gu, '')        // zero-width and other control characters
    .normalize('NFC');
}

Results:

foldFancy('𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮')  // 'fancy name'
foldFancy('ᴛɪɴʏ ᴛᴇxᴛ')     // 'tiny text'
foldFancy('s̶t̶r̶i̶k̶e̶')         // 'strike'
foldFancy('ⓐⓓⓜⓘⓝ')        // 'admin'
foldFancy('𝗮𝗱𝗺𝗶𝗻')        // 'admin'
foldFancy('ᵃᵈᵐⁱⁿ')         // 'admin'
foldFancy('admin')         // 'admin'  ← that one had a zero-width space in it

That last line is the one I'd flag to your security reviewer. Zero-width characters are invisible in every UI you own, and they are the same bypass as the fancy letters with none of the visual tell.

Two caveats on that function. \p{Mn} strips all non-spacing marks, so foldFancy('café') returns 'cafe'. For a search key that is usually what you want. For anything you intend to display back to the user it is data loss, so keep this on the comparison path only. And the small-caps ranges cover the Latin ones; if you care about Cyrillic or Greek lookalikes you are in homoglyph-attack territory, which is a bigger problem with a real answer (Unicode TR39 and the confusables table).

5. Screen readers give up

This is the part that turns a curiosity into an accessibility issue.

Screen readers pronounce characters using their pronunciation dictionaries, which are built for the letters people actually write with. Hand them the maths alphabets and the behaviour ranges from reading the Unicode character name aloud, to spelling the word out letter by letter, to skipping the run entirely — it varies by screen reader, by version, and by the TTS voice underneath. A bio that says 𝓱𝓮𝓵𝓵𝓸 𝓲'𝓶 𝓪 𝓭𝓮𝓼𝓲𝓰𝓷𝓮𝓻 can come out as silence, or as forty seconds of character names.

Same story for search engines and for anything doing NLP on your content. The text looks like words to a sighted human and like noise to every machine that processes it.

You cannot stop users from doing this, and honestly it's their bio. What you can do is keep the folded version alongside the original, and use it for everything except display.

The pattern that actually works

Store what the user typed. Never rewrite their name for them — it's theirs, and they picked it deliberately.

Alongside it, store a folded key, and use that for the comparison paths:

// on write
await db.users.insert({
  displayName: input,                 // '𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮'  — render this
  displayNameFolded: foldFancy(input) // 'fancy name'  — index, search, sort, moderate on this
});

Then: uniqueness checks against the folded column, blocklists against the folded column, full-text index on the folded column, ORDER BY on the folded column, moderation on the folded column. Render the original, with the folded text as an aria-label when the field is user-facing:

<span aria-label="fancy name">𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮</span>

That one line gets you most of the accessibility win for free.

If you're on Postgres, the same idea lives in a generated column plus an index on it, which keeps the two from drifting. The application-level version drifts the first time someone writes to the table from a migration script.

Test data

Fixtures for this are annoying to type by hand, because you cannot type these characters — you have to generate them. I maintain tinytextgen.com partly because I needed a fast way to produce them: paste a string, get the small caps, superscript and subscript versions side by side, copy one out. The full set of styles covers the maths alphabets, circled letters and combining-mark effects, which is roughly the space you want your test suite to cover.

A reasonable fixture list: one maths-alphabet string, one small-caps string, one with combining marks, one with a zero-width space, and one plain-ASCII control. If those five pass through your signup, your search and your moderation intact, you're in decent shape.

Anything I missed? I'd be curious whether anyone has hit this in a database collation rather than in application code — that's the version I suspect is out there and under-reported.

iOS Safari can't decode your .mov, and the reason is 2 bytes deep in the container

Deland — Mon, 31 Aug 2026 09:14:53 +0000

Our tool transcribes audio in the browser — Whisper running locally via transformers.js, no upload. It worked fine, until analytics showed something too clean to be a coincidence:

.mov uploads on mobile failed 100% of the time. Not 90%. Every single one. Desktop had never reported a single .mov failure.

This is what I found, and how it got fixed without pulling in ffmpeg.wasm or WebCodecs.

The 30-second reproduction

I took one AAC audio track and put it in two containers — same encoder, same bytes for the audio itself, only the wrapper differs:

const buf = await file.arrayBuffer();
await new AudioContext().decodeAudioData(buf);

On an iPhone 17 Pro simulator (iOS 18.7 / Safari 26.5):

File	iOS Safari	Chromium
`sample.mov` (ftyp `qt`)	`EncodingError: Decoding failed`	OK
`sample.mp4` (ftyp `isom`)	OK	OK

So it isn't the codec. It's the container.

The obvious fix that doesn't work

First instinct: it's the brand in the ftyp box. Patch qt → isom, four bytes, done.

It still fails. I'm writing this down so nobody else burns an afternoon on it. The ftyp brand is not what Safari looks at. The difference lives inside moov.

The actual root cause

Dig down to moov → trak → mdia → minf → stbl → stsd — the sample description that tells the decoder how the audio is encoded. Both files carry an mp4a entry. They are not the same mp4a entry:

QuickTime writes:                  MP4 expects:
  version       = 1        <—        version       = 0
  compressionID = -2 (fffe) <—       compressionID = 0
  + 16 bytes of v1 extension <—      (absent)
  esds wrapped in a 'wave' box <—    esds is a direct child
  extra 'chan' channel layout        (absent)

iOS Safari's decodeAudioData only accepts a version 0 audio sample entry. Chromium accepts both — which is exactly why desktop never saw this and mobile never survived it.

That version field is a uint16. Two bytes decide whether the file plays.

The fix: rebuild the container, don't touch the codec

Since the audio bitstream is already valid AAC, nothing needs to be re-encoded. The job is pure byte plumbing: extract the audio samples, write a fresh audio-only MP4 with a well-formed stsd, and hand it back to the browser's native decodeAudioData.

That last part matters. Because we never decode audio ourselves, we don't need WebCodecs — and therefore don't inherit AudioDecoder's iOS 17+ floor — and we don't ship a multi-megabyte ffmpeg.wasm to fix a container-level problem.

.mov ──► scan top-level boxes to find moov (read box headers only, never touch mdat)
      ──► parse the audio track's stsd / stts / stsc / stsz / stco|co64
      ──► sliding window (8 MB) to copy out audio samples
      ──► rebuild ftyp + moov (stsd forced to version 0) + mdat
      ──► decodeAudioData

The sample entry we emit is deliberately boring:

box('mp4a',
  zeros(6),
  u16(1),  // data_reference_index
  u16(0),  // version — the only one iOS Safari accepts
  u16(0),  // revision
  u32(0),  // vendor
  u16(channels),
  u16(16), // samplesize
  u16(0),  // compressionID — QuickTime writes -2; MP4 says 0
  u16(0),  // packetsize
  u32(Math.min(sampleRate, 65535) * 65536), // 16.16 fixed point
  esds     // pulled out of QuickTime's 'wave' wrapper if needed
)

One parsing subtlety worth stealing: the esds descriptor sits as a direct child of mp4a in MP4, but QuickTime buries it inside a wave box. So the lookup scans all siblings first, then recurses — otherwise a wave-nested esds can shadow the one you actually want.

Version 1 entries also carry 16 extra bytes before their child boxes, and version 2 carries 36 with the real sample rate in a float64. Get those offsets wrong and you'll parse garbage as a box header:

const version = view.getUint16(base + 8);
let childStart = base + 28;
if (version === 1) childStart = base + 28 + 16;
else if (version === 2) { sampleRate = view.getFloat64(base + 32); childStart = base + 64; }

The bug we weren't looking for

The old code started with this:

const buf = await file.arrayBuffer();  // 161 MB average on mobile

Mobile video files in our logs average 161.9 MB — and 99% of those bytes are video frames we don't need for a transcript. Reading the whole file into memory, then decoding it into an equally long PCM buffer, is a great way to get killed by iOS Safari's memory limits.

Locating boxes by reading only their 8–16 byte headers, then copying samples through an 8 MB sliding window, changes the peak from whole file to 8 MB + the audio itself:

File	Native decode	After extraction	Extract time	Decode after
`sample.mov` (0.10 MB / 5s)	FAIL	0.08 MB	16 ms	OK
`hevc.mov` (HEVC video + AAC)	FAIL	0.12 MB	4 ms	OK
`huge5.mov` (158.6 MB / 900s)	FAIL	13.88 MB	378 ms	OK (476 ms)
`audio.m4a`	OK	0.08 MB	3 ms	OK (no regression)
`sample.mp4`	OK	0.08 MB	3 ms	OK (no regression)

The huge5.mov row is the one that mattered: 158.6 MB is the real-world mobile average, the old path read all of it and still threw EncodingError, the new path produces a decoded 15-minute audio buffer in 854 ms total. Decoded output was verified non-silent (peak > 0) and length-accurate (900.023s → 900.1s), because "it returned a buffer" is not the same as "it worked".

Fail backwards, never sideways

Every step returns null the moment reality stops matching the assumptions, and the caller falls back to the original direct-decode path:

Input	Result
Fragmented MP4 (`empty_moov`)	`null` — sample tables live in `moof`, assumption broken
PCM audio track in `.mov`	`null` — only `mp4a` is handled
`.webm`	never enters this path
`.mov` with no audio track	`null` — no `soun` track found

This is the rule that kept the change safe to ship: a module that exists to rescue guaranteed failures must never make a working case worse. Every null is a case where the old path was already going to run anyway.

What I'd take away from this

When a format works in one browser and not another, suspect the container before the codec. Codec support is well-documented; container tolerance is not.
ffmpeg.wasm is not the default answer. If the bitstream is already valid, you have a plumbing problem, and plumbing is a few hundred lines of DataView.
Reading a whole file to decode it is a bug on mobile, even when it doesn't crash today.
And afterwards: delete the warning banner. We used to tell mobile users "large .mov files may fail". Leaving that up after the fix would be worse than never having shown it — the file size no longer correlates with any real risk, because we only ever move the audio bytes now.

This shipped in TranscriptSnap, a browser-local transcription tool — Whisper runs on your machine via transformers.js, files never leave the device, which is also why a container quirk in Safari became our problem instead of a server's. The full write-up with the on-device measurements lives here.

Every test passed and the level was unwinnable

Deland — Mon, 31 Aug 2026 08:39:26 +0000

I shipped a wilderness survival game with eight scenarios. The hardest one — a five-star map behind the paywall — could not be finished. Not "was brutally hard." Could not be finished. Walking onto the exact tile the design calls the ending did nothing at all.

Every test was green. That is the part worth writing down.

The bug

Locations connect through exits, and some exits stay hidden until you find them. travel() handled that discovery like this:

if exit.hiddenUntilDiscovered, !state.discoveredLocationIds.contains(target.id) {
    state.discoveredLocationIds.insert(target.id)   // marked before the move
    state.log("log.hidden_passage_found", ...)
}

And arrive() decided first-visit rewards like this:

if !state.discoveredLocationIds.contains(location.id) {
    ...
    effects.apply(location.onFirstVisitEffects, to: &state, rng: &rng)
}

One set, written before the move and read after it. Any location reached through a hidden exit is already a member by the time arrival checks, so its entire onFirstVisitEffects block is skipped in silence. Getting lost and retreating did the same thing: the destination got marked, and the real arrival later never counted as a first.

Sixteen locations across all eight maps lost their first-visit payload that way — standing shelters, supply caches, morale, story flags. On one of them, the payload was the ending.

Scenario	Location	Never fired
highland_mine	vent_shaft	victory
highland_mine	timber_stope	shelter, flag, morale
forest_lake	abandoned_camp	three supplies, flag, morale
tide_island	old_lighthouse	shelter, two supplies, morale
burnt_range	lookout_tower	shelter, supply, flag, morale
…	…	…

highland_mine's only win condition is reaching vent_shaft. vent_shaft's only entrance is a hidden exit. The win was unreachable through the single door that led to it, and the player starves in a dead end that the content files consider the finish line.

The fix is boring: let arrive() own discovery exclusively, and move the secret-passage log line to after arrival is confirmed.

Why nothing caught it

Run down what a content-driven game normally validates. Map connected from spawn. Every recipe's ingredients exist as items. Every scenario has a victory path. No dangling ids anywhere. All green — and all still green with the bug in place.

Every one of those asks is this configuration valid. The configuration was valid. The victory location existed, was reachable, and carried a victory effect. The effect simply never ran.

That's the shape: structure correct, execution never happens. You cannot find it by validating the graph. Something has to walk it.

The instrument: a bot that plays

So I wrote one. The important decision wasn't writing it, it was splitting it into instruments that don't contaminate each other.

1. Can you win when survival isn't the obstacle?

Every step, the harness tops up hydration, body heat, stamina, calories, and clears injury and infection. Everything from the content side stays: location tags, disabledActionIds, per-location resource exhaustion, flag gates, recipe materials.

The bot pathfinds ignoring flag gates, and when travel refuses the step, it degrades to "look for the key here" — trying every action that can set the flag it's missing, which it collects once by scanning effects:

private lazy var flagActions: [String: [String]] = {
    var map: [String: [String]] = [:]
    for action in content.actions.values {
        for eff in action.successEffects where eff.type == .flagSet {
            guard let flag = eff.flag else { continue }
            map[flag, default: []].append(action.id)
        }
    }
    return map
}()

The win condition itself is inferred from content rather than a hardcoded table, because a hardcoded table keeps passing after a scenario is redesigned and hides exactly the problem you wrote the test for.

If you can't win under those conditions, it is a materials or path problem, full stop. Currently 8/8.

2. Do the winning materials exist at all?

Pure static pass, no simulation: given disabledActionIds and the location tags actually present, compute the theoretical ceiling on every material a raft or a signal fire needs — direct gathering plus anything craftable. A ceiling of zero means unwinnable.

This exists because survival scenarios are designed by subtraction. The desert has no water source, the burnt forest has no standing wood, the mine has no vegetation — highland_mine disables eight gathering actions and burnt_range disables cutting firewood. Subtracting the interesting thing and accidentally subtracting a victory material is one edit apart.

3. Win rate under normal play — printed, never asserted

This is the one I'd defend hardest, and it asserts nothing.

Partway through, I gave the bot one piece of common sense: don't travel below 62 body heat. Reasonable. Humans do that.

frost_ridge went from 7/8 to 0/8.

On a five-star snow map body heat is almost never above 62, so the bot sat by the fire and froze in place. Nothing about the scenario changed. The number moved 88 points because I edited the player.

A metric with your agent's competence baked into it cannot be an assertion. It's a trend line and nothing more. The moment I let that number gate CI, every future improvement to the bot reads as a content regression and every content regression can be argued away as bot noise.

The check that needed no bot at all

Separately: every scenario, crossed with every row of its own weather table, must survive its first night when the player does everything right.

Push the clock to sunset. Then simulate the night hour by hour with the fire lit, fuelled, and rain-protected, and a shelter at the tier that difficulty has the right to demand:

// Difficulty should decide how much the player must invest,
// not whether a solution exists at all.
let required: ShelterLevel = scenario.difficultyStars >= 4 ? .leanTo : .basic

Night length comes from the scenario's own sunset and sunrise, not a hardcoded 12 hours — long nights and short nights differ by a factor of two, and hardcoding it means the hardest maps are tested on the easiest assumption.

Then assert body heat above zero, and condition above 30, because surviving with 4 health left is not a passing grade.

highland_mine failed this too, arithmetically. −11 °C at night with snow drains 26.8 body heat per hour. The best insulation the entire game can assemble — coat 2.5, natural cover 1, fire 9 — is 12.5. A twelve-hour night takes 136 points. You start the night with 76.

No balance pass gets you out of that. The fix was per-location microclimate: inside a mountain doesn't take the weather.

let indoors = node?.shieldsFromWeather ?? false
let ambient = baseTemp + (indoors ? 0 : weather.tempOffsetC) + (node?.tempOffsetC ?? 0)

Baselines relative, never absolute

The older, dumber probe — the one that only forages in place and answers "does the player die on day two" — compares each new scenario's worst seed against a known-good free scenario, with one day of slack:

XCTAssertGreaterThanOrEqual(
    worst, baseline - 1,
    "\(scenario): worst seed died on day \(worst), baseline \(baseline)"
)

Absolute survival days measure how dumb my bot is. The same dumb bot across different scenarios measures the scenario. Anchoring to a baseline instead of a constant is what makes an unreliable instrument produce a reliable comparison.

The determinism bug sitting underneath all of it

None of this reproduces without deterministic randomness. Same seed, same run, forever — otherwise a failing probe is a rumour. Each action draws from its own stream derived from one save seed, SplitMix64.

The obvious way to derive stream s is to offset the initial state by s. Do not.

SplitMix64 advances by a fixed gamma — 0x9E3779B97F4A7C15 — on every step. If your stream offset is any integer multiple of that gamma, then stream s's i-th output is exactly stream s−k's (i+k)-th output. Individually each stream still passes every randomness smell test you'd casually apply. Collectively they're one sequence walking in lockstep, and "independent stream per action" is a comment, not a fact.

Avalanche the stream index before it ever becomes state:

init(seed: UInt64, stream: Int = 0) {
    var mixed = seed ^ (UInt64(truncatingIfNeeded: stream) &* 0xD1B54A32D192ED03)
    mixed = (mixed ^ (mixed >> 33)) &* 0xFF51AFD7ED558CCD
    mixed = (mixed ^ (mixed >> 33)) &* 0xC4CEB9FE1A85EC53
    state = mixed ^ (mixed >> 33)
}

There's a second-order constraint that comes with this, and it caught me on the discovery fix above: the repair had to preserve RNG call order. Move a generator call earlier or later and every existing save and every seeded result shifts underneath you — the bug is fixed and the whole test suite goes red for unrelated reasons. Once determinism is load-bearing, "fix this without changing how many times you call the generator" becomes part of the diff review.

Where it landed

216 tests. Eight scenarios reachable once survival pressure is removed, no material gaps, and both the iOS and watchOS builds walked through the previously-broken vent shaft on a real simulator before I believed any of it.

The thing I actually changed my mind about: for a content-driven game, the valuable test is not the one that validates your data. It's the one that consumes your data the way a player does and then tells you what it couldn't reach.

The game is Wilds Survivor — on the App Store. Eight ways to be stranded, five difficulty tiers, fully offline, no ads, no accounts, no energy timers, and a watchOS app that runs the entire engine standalone with the phone left at home. Two scenarios are free, which is enough to see whether the decision loop is your kind of thing. Every number in this post came out of its repo.

Still short of a good answer on the win-rate problem: a bot competent enough that its win rate describes the scenario rather than the bot. For now I just refuse to assert on it. If you've solved that for a game with hidden information, I'd like to hear how.

Delta E is a distance, not a score

Deland — Mon, 31 Aug 2026 08:10:24 +0000

I run a game where you get a brand name — Spotify, IKEA, Home Depot — and rebuild its primary color from memory with three sliders: hue, saturation, lightness. On submit, the guess and the target both go to CIE Lab and the score comes from the distance between them.

The scoring line was this:

const score = Math.max(0, 100 - deltaE * 2);

It looks defensible. ΔE around 2 is the classic just-noticeable-difference; ΔE 50 is "those are not the same color." Map 0–50 onto 100–0, done.

It was wrong for three months and I couldn't see it, because I kept reading the formula instead of the distribution.

The number I couldn't query

The scores were on screen the whole time and nowhere in my analytics. GA4 only reports event parameters you have registered as custom dimensions or metrics, and registration is not retroactive — the day you create it is the day data starts existing. So there was no query to run against the past. I registered score as an event-scoped custom metric and waited.

Eight days later, 232 first-round samples, mean score per round:

Round	Mean score	Rating shown	Share square
1	21.3	Miss	⬜
2	22.1	Miss	⬜
3	29.2	Miss	⬜
4	18.6	Miss	⬜
5	40.0	Miss	⬜

The rating bands are ≥96 Perfect, ≥86 Great match, ≥70 Close, ≥45 Off, below that Miss. Every round averaged below the worst threshold. An average player finished a five-round game without once being told they did anything but badly, and the Wordle-style result they were invited to share was five white squares.

Nobody shares five white squares. Result-page arrivals: 247. Shares and copies: 4.

What the formula was actually asking for

Work backwards from the bands through 100 - ΔE × 2 and you get the ΔE each rating required:

Rating	Old curve needs	New curve needs
Perfect	ΔE < 2	ΔE < 9
Great match	ΔE < 7	ΔE < 22
Close	ΔE < 15	ΔE < 38
Off	ΔE < 27.5	ΔE < 59
zero points	ΔE ≥ 50	ΔE ≥ 90

Perfect required a guess a human eye could not distinguish from the target. The whole rating vocabulary — five labels — lived inside ΔE 0 to 27.5, and everything past 50 was a flat zero.

Measured play sits at a mean ΔE of about 37.

That is the entire bug. Not a coefficient that was slightly off — a curve whose expressive range and the actual distribution of play barely overlapped. 27.8% of guesses scored exactly 0, which also means the formula stopped conveying anything at all for more than a quarter of its inputs: badly-off and hopelessly-off scored the same.

And ΔE 37 is not a bad guess. Two independent errors compound in this game — your memory of the color, and your ability to steer toward a remembered color through hue/saturation/lightness, which are not the axes perception uses. Landing 37 away is what a competent human does. The formula was calling normal human performance a failure.

The fix

const MAX_DELTA = 90;
const CURVE_EXPONENT = 1.4;

export function scoreForDelta(delta) {
  const normalized = Math.min(Math.max(delta, 0), MAX_DELTA) / MAX_DELTA;
  return Math.max(0, Math.round(100 * (1 - normalized ** CURVE_EXPONENT)));
}

Two knobs, each doing one job.

MAX_DELTA decides where zero lives. At 90 it sits out past anything a player who is genuinely trying will produce, so the score keeps carrying information across the whole real range instead of saturating inside it. Zeros went from 27.8% of guesses to 2.3%.

The exponent above 1 bends the curve so it is generous early and steep late. At ΔE 37 you now get 71 (Close) instead of 26 (Miss); to be told you're Perfect you still have to land inside ΔE 9. Difficulty didn't leave, it moved to the top of the range where it belongs.

ΔE	Old	New
10	80	95
20	60	88
30	40	79
37	26	71
45	10	62
50	0	56
60	0	43
75	0	23

Simulated against the real brand pool before shipping: mean score 35.7 → 68.4, median game total 152 → 339 out of 500, squares 🟩23% / 🟨34% / 🟧25% / ⬜18%.

The discipline that made the change measurable

I did not touch the 45/70/90 thresholds. That was tempting — since I was in there anyway, why not retune the bands too?

Because score is the metric I'm judging the change by. Move the curve and the bands in the same deploy and the before/after comparison answers nothing: you cannot tell whether players started scoring better or you just repainted the ruler. Change the thing under measurement or change the measuring instrument, never both in one release.

Same reason the outcome of a share attempt is encoded in the event name (share_image_copied, share_image_downloaded) instead of a parameter. Parameters need registered dimensions, registration isn't retroactive, and the quota is 50. Event names cost nothing and work the day you ship them.

Two things that bit me

Verifying in a hidden browser panel. The per-round number counts up through a requestAnimationFrame animation. rAF is throttled to a stop in a background or hidden tab, so the round score renders 0 forever and never moves. I nearly concluded the deploy hadn't taken. The rating text next to it is not animated and neither is the game total — read those. Anything driven by rAF is not evidence when nothing is compositing.

Reading the local file as though it were production. The fix sat uncommitted in my working tree for two days while a different change went out around it. The live bundle still contained Math.max(0,Math.round(100-2*n)), and GA4 agreed: daily first-round means of 14–30 the whole time. The five-second version of this check is to grep the deployed JS for your formula. Local source is a claim about production, not an observation of it.

The color-nerd footnote

This is ΔE*76 — plain Euclidean distance in Lab, D65 white point. CIEDE2000 is more perceptually faithful, particularly for saturated blues, and I may move to it. It would not have changed anything above: at the distances real play produces, the correction is small next to being wrong by a factor of three about where the scale should end.

The game is at logocolorquiz.com. Every number here came out of it.

Ranking by exponential decay without a cron job

Deland — Tue, 25 Aug 2026 02:13:59 +0000

I built a board of 1,000 tiles where anyone can pay to take a tile away from whoever currently holds it. Tiles are sorted by "heat" — a value that decays over time — so the board reorders itself continuously.

The obvious way to do that is a scheduled job that recomputes every row on a timer. I didn't want a scheduled job. Here's how you avoid one.

The problem

Heat is the sum of every payment a tile has received, each one decaying exponentially:

heat(t) = Σ Aᵢ · 2^(-(t - tᵢ) / H)

Aᵢ is a payment, tᵢ is when it landed, H is the half-life (3 days, in my case).

Every term shrinks as t advances, so every tile's heat changes every second. Sorting by that looks like it requires recomputing all 1,000 rows on a timer. With a million rows, that timer stops being a detail and becomes the whole system.

Collapse the sum first

You never need to store individual payments. The entire sum can be represented by a single pair (P, t_P). When a new payment A arrives:

P'   = P · 2^(-(t_new - t_P)/H) + A
t_P' = t_new

One row, two columns, no matter how many payments a tile has taken over its life.

Then take the log

Let k = ln2 / H:

ln(heat(t)) = ln(P) - k·(t - t_P)
            = [ln(P) + k·t_P] - k·t

Look at the two halves separately. The -k·t term depends only on the current time, which means it is identical for every row in the table. A term that is the same for every row cannot affect their relative order. Drop it.

What's left is ln(P) + k·t_P. There is no t in it. It's a constant that changes only when someone pays.

Store it as rank_key, put an index on it, and:

SELECT * FROM tiles ORDER BY rank_key DESC

is a permanently correct real-time ranking. Nothing is recomputed on a schedule. A row is rewritten only when money actually moves. The ordering is right one second after launch and still right three years later, with no job having ever run.

Log space is also where you add heat. Use a numerically stable log-add so a small payment on top of a large one doesn't vanish into floating point:

function logAddExp(a, b) {
  if (a === -Infinity) return b;
  if (b === -Infinity) return a;
  const hi = a > b ? a : b;
  const lo = a > b ? b : a;
  // lo - hi <= 0, so exp can't overflow; log1p is accurate near zero
  return hi + Math.log1p(Math.exp(lo - hi));
}

Two things that will bite you

Choose the time unit deliberately. rank_key contains k · t_P. If t is unix seconds, then k = 2.674e-6 and k·t is roughly 4800 today — that burns four significant digits of a double before you've stored anything useful. Use days instead: k = 0.231, k·t ≈ 55, and you still have around 12 decimal digits of headroom, which is sub-microsecond resolution. Pick an epoch near your launch date and count days from it.

Never exponentiate rank_key directly. It grows linearly with time. Mine is ~55 today and will be ~1687 in twenty years, and Math.exp(1687) is Infinity. To get a real heat value for display, exponentiate in the domain shifted to now:

// rankKey - K·days(now) == ln(heat(now)), which stays in the 6..10 range
const heat = Math.exp(rankKey - K * toDays(nowUnixS));

The rule: rank_key is for ordering. Never do arithmetic that leaves log space.

The bug this nearly gave me

All 1,000 tiles live in a single Cloudflare Durable Object. A DO gives you one JS execution stack — only one thing runs at a time — which sounds like it makes critical sections free. It doesn't.

Every await is a yield point. The input gate only blocks delivery during storage operations; it does nothing across a D1 query or an outbound fetch(). So this is broken:

const locked = await db.prepare('SELECT ... WHERE tile_id = ?').all()
if (locked.results.length) throw conflict()
// two requests both reach here, both see zero locks, both proceed

The check and the claim have to happen in a purely synchronous block, before any await exists:

async reserve(input) {
  // ==== synchronous critical section: not one await in here ====
  const conflicts = [];
  for (const id of input.tileIds) {
    const t = this.tiles.get(id);
    if (t.status === 'frozen') conflicts.push(id);
    else if (this.inflight.has(id) || isBlocking(t.lock, now)) conflicts.push(id);
  }
  if (conflicts.length) throw new TileConflict(conflicts, retryAfter);

  for (const id of input.tileIds) this.inflight.add(id);
  // ==== end of critical section ====

  try {
    return await this.reserveSlow(input, now);   // D1 writes, payment intent, etc.
  } finally {
    for (const id of input.tileIds) this.inflight.delete(id);
  }
}

inflight is a plain in-memory Set. JavaScript's single thread guarantees that block can't be interrupted, so staking the claim there is atomic in the only sense that matters here. Everything slow happens afterwards, and finally releases the claim even if the slow part throws.

The division of labour is worth being precise about: the DO owns serialization, alarms, and snapshot generation. D1 owns every persistent fact — ownership, amounts, rank_key, the ledger. The DO's own storage holds nothing but the alarm, so crash recovery is a single hydrate() from D1 and there's no dual-write to reconcile.

The decision that mattered more than the math

When someone takes a tile, does the new owner inherit its heat or reset it?

Inheriting feels natural — the tile is hot, that's why it got taken. But the steal price is 1.5x current heat, so inheriting compounds: new heat = old + 1.5·old = 2.5·old. After four steals the tile sits at 39x its original heat and nobody can afford it again. An iron throne. The most interesting tile on the board becomes the one nobody can touch.

Resetting heat to the amount actually paid gives 1.5^n instead — 3.4x after four steals — and the 3-day half-life pulls that back down within a week. Contests stay winnable.

Identical decay math either way. One choice produces a living board, the other produces a museum. Worth remembering that the interesting part of this kind of system is usually not the formula.

Seeing it run

The board is at tilesquat.com. 1,000 tiles, $5 to take one, and the thing the Million Dollar Homepage never had: nothing you buy stays yours. Everything above is taken from its source.

Tile #0000 is mine at the moment. Feel free to evict me.

I gave my coding agent its own computer

Deland — Mon, 17 Aug 2026 08:33:52 +0000

I run coding agents with shell access all day, and for a long time there was a low-grade dread underneath it. The permission prompts get annoying enough that everyone eventually turns them off, and then you are one confidently wrong rm away from a bad afternoon.

What fixed it was not better prompting. It was giving the agent its own computer.

The setup is a VM on the same Mac. The agent gets a filesystem with nothing of mine in it, credentials that only work on throwaway repos, and a snapshot taken before every session. If it does something destructive I do not debug it. I roll back. Thirty seconds and the mistake never happened.

That part is easy to describe and, on Apple Silicon, surprisingly annoying to actually build. Here is what I learned doing it.

What Apple's Virtualization framework will actually boot

This is the first thing that trips people up, so it is worth being blunt about it.

Virtualization.framework boots two things: macOS on ARM and Linux on ARM. That is the entire list. There is no Windows on ARM, and no amount of configuration will produce one. It is not a licensing gate you can argue your way past, there is simply nothing to enable. Anything you read that claims otherwise is describing UTM's QEMU backend or VMware Fusion, both of which use their own hypervisor rather than Apple's.

For the agent sandbox case this does not matter, because you want Linux anyway. Linux guests are smaller on disk, boot faster, and you are not burning one of your two permitted macOS guests on a machine that mostly runs npm install.

The two guest types are configured differently in ways the docs do not really foreground:

switch os {
case .macOS:
    // Boots the macOS bootloader, and needs a separate
    // auxiliary storage file next to the disk image.
    bootLoader = .macOS
    platform = .mac(auxiliaryStoragePath: auxPath)
case .linux:
    // Boots EFI, and needs a variable store that
    // persists across reboots. Lose this file and the
    // guest forgets where its bootloader is.
    bootLoader = .linuxEFI(variableStorePath: efiVars)
    platform = .generic
}

The EFI variable store is the one people lose. It is a small file that lives next to the disk image and holds the boot entries. Copy the disk image somewhere without it and you get a guest that boots to an EFI shell and looks broken.

The serial console will change your guest's behavior

This one cost me an evening, and I have never seen it written down.

Attaching a serial console to a Linux guest is the obvious move when the guest fails silently. You get hvc0 piped to a log file and you can finally see what the kernel is doing.

Except Ubuntu's installer detects the serial port and decides that is where you want to be. Subiquity moves the installation UI off the graphical display and onto the serial console, in a reduced text mode, and your VM window sits there showing what looks like a hang. The guest is fine. You just moved its face.

So the serial console has to be opt in, not always on:

// Only attach the console when actively debugging.
consoleLogPath: os == .linux
    && UserDefaults.standard.bool(forKey: "Serial")
    ? bundle.consoleLogURL.path : nil

The general lesson generalizes past this one bug: on this framework, adding a device is never free. Every device you attach is visible to the guest and the guest may make decisions about it.

Getting code in and out without defeating the point

My first version of this mounted my real project directory into the VM through VirtioFS. It worked immediately and it was completely pointless, because an agent that can write to my actual project folder is just my main machine with extra steps.

The version that works: copy in, work, copy the diff out. The share is read only, or there is no share at all and everything moves over SSH.

If you do want a share, the tag matters and differs by guest:

// Linux guests: pick your own tag, then mount it:
//   mount -t virtiofs myshare /mnt/share
let tag = "myshare"

// macOS guests: use Apple's automount tag and the
// share shows up at /Volumes/My Shared Files with
// no mount command at all.
let tag = VZVirtioFileSystemDeviceConfiguration
    .macOSGuestAutomountTag

The macOS automount tag is genuinely nice and almost nobody knows it exists.

Rosetta inside a Linux guest

If your toolchain has an x86-64 binary in it somewhere, and it usually does, you can share Rosetta into an ARM Linux guest:

switch VZLinuxRosettaDirectoryShare.availability {
case .installed:     // attach the share
case .notInstalled:  // offer installRosetta { ... }
case .notSupported:  // hide the feature entirely
@unknown default:    // treat as unsupported
}

Mount it in the guest with mount -t virtiofs rosetta /mnt/rosetta, register it with binfmt_misc, and x86-64 binaries start running.

Two caveats before you build anything load bearing on this. Apple has signalled that Rosetta 2 is being wound down in future macOS releases, and has not committed to the Linux virtualization path surviving that. Check Apple's current guidance rather than mine. And handle @unknown default as unsupported rather than crashing, because the day this enum grows a case is the day your app stops launching.

Things I got wrong

Snapshot before, not after. Obvious in hindsight. Cost me a session.

Real credentials get used. If the agent can reach it, treat it as in scope. Scope the tokens to throwaway repos and assume anything reachable from that VM is reachable by the agent.

Disk images only grow. The image expands toward whatever you provisioned and does not shrink when you free space inside the guest. Do not oversize "just in case". Keep one clean base image you never boot, clone off it, and delete the clone when you are done. One image that stays reasonable beats five that have all ballooned.

Two macOS guests per host, maximum. That is Apple's license terms, not a technical limit. Nothing stops you, which means it is on you. Irrelevant for Linux guests, which is another reason to use them here.

What actually changed

I run with permissions fully open now. The blast radius is a disk image I can throw away, so the prompt that used to make me think twice does not anymore.

The odd side effect is that I review the final diff more carefully than I used to. I am not spending attention on "is this rm safe", so there is attention left over for whether the code is any good.

Getting started

Any of these will get you there. Apple's framework directly if you want to write the roughly two hundred lines yourself, and honestly it is a good weekend, the API is one of the better ones Apple ships. UTM if you want something free with a GUI and do not mind the setup. lume or Tart if you would rather script it.

Disclosure: I got annoyed enough at the setup friction that I built a Mac app for this, called Kyvenza. Every code sample above is from its engine. It is 49 dollars one time with a 7 day trial, and it will not run Windows either, for the reason in the second section. The approach is the point of the post though, and UTM does it for free if you do not mind the assembly.

Still curious whether anyone has a cleaner pattern for handing credentials to a sandboxed agent. That is the part I like least.