DEV Community: Renga

I published three posts in one day and two of them were never seen by anyone

Renga — Sun, 30 Aug 2026 10:20:08 +0000

I wrote eight technical posts and put them on dev.to. Then I pulled the view counts from the API.

Published	Posts that day	Views per post
Aug 11	1	12
Aug 14	3	0 / 62 / 0
Aug 15	1	35
Aug 16	1	23
Aug 21	1	10
Aug 22	1	11

Every day I published once, the post got views. The one day I published three, two of them got zero.

Not low. Zero. Never shown to anybody. Two out of eight — a quarter of everything I had written — had never reached a single reader.

I killed two explanations first

My immediate thought was "one post per author per day." But believing the first plausible story is how you get this wrong, so I went looking for anything else that fit.

Were the tags too small?

No.

The zero-view post was tagged ffmpeg, python, video, tutorial. python is the 8th most-followed tag on the platform and tutorial is 7th.

Big tags and still zero. Tags don't explain it.

Was it published at a bad hour?

Also no — if anything, backwards.

Views	Published (US Eastern)
62	00:27 — the middle of the night
0	13:43 — prime time

My best-performing post went out at the worst possible hour, and a zero-view post went out at a good one. The timing hypothesis doesn't survive.

Only the count is left

Not tags, not timing. The only thing that differs is how many posts I published that day.

Forem's scoring, per the open implementation, blends roughly these:

match against tags the reader follows
reactions the post has accumulated
whether the reader already follows the author
language match
some random jitter

With zero followers and zero reactions, tags are the only lever you have. Cap per-author exposure on top of that, and a same-day second post has nothing left to work with.

Zenn does the same thing, worse

Zenn has a posting-rate limit. Hit it and the article simply doesn't publish.

The nasty part is that nothing errors. The git push succeeds. Only the deploy log mentions the limit, and the article URL sits at 404.

I misdiagnosed this the first time as a frontmatter formatting problem, because the push had succeeded and I took that as evidence of publication.

The fix is a machine, not a resolution

Deciding to post once a day isn't enough. You break it on the day you forget.

The publishing script now carries a 24-hour guard.

✗ dev.to published within the last 24 hours (0h ago: "...").
  A second post the same day never reaches the feed and gets zero views.
  Wait another 23.7 hours.

Zenn has the same guard, plus one more condition: it does not record the post as published until the URL returns 200. The success of a push is not evidence that anything shipped.

I tripped the guard myself within an hour of adding it. Without it, I would have produced another 404.

What I'd take away

Publish twice in a day and one of them is discarded. Nothing errors
It isn't tags and it isn't timing. Big tags at good hours still went to zero
A 200 from the API is not delivery. Zenn returns a successful push and a 404 page
Encode it, don't resolve it. A countermeasure that depends on remembering fails on the day you don't
Measure after you ship. Line up posts-per-day against views and this shape is visible immediately

The writing time was not what bothered me. The time spent writing things that were thrown away was.

The jitter wasn't in the interpolation. It was in the schedule.

Renga — Sat, 22 Aug 2026 01:23:52 +0000

The avatar standing on my desktop looked like it was stuttering. One symptom — but it turned out to have three causes of completely different kinds.

Check them in the wrong order and you waste a lot of time. I started with interpolation, which was the wrong end.

1. First, suspect overlap

This was the big one. The next motion was starting before the previous one had finished.

The interval was set to 5 seconds. The motion was 9 seconds long. Calling it again mid-playback resets elapsed time to zero, so it snaps back to the first frame partway through. There's no chance to settle back into the idle pose before the next one begins. That reads as "stuttering".

The symptom is jitter, but the cause is the timetable, not the curve. No amount of smoothing fixes it.

Two things to check:

Is the next run scheduled when the motion starts, or when it finishes?
Does your "skip if already playing" guard cover every playback path?

I got caught by the second. The guard only consulted a flag used by the .vrma path, and the procedural-motion path walked straight past it. A gate on one of two doors is not a gate.

2. Then, suspect velocity discontinuity

Eyes pick up discontinuity in velocity, not position. Move at a constant rate and stop abruptly, and the stop itself looks like a jolt.

Two common sources:

Linear trapezoids (ramping with t / rise) — velocity jumps at both the start and the peak
Math.abs(Math.sin(x)) — forms a sharp point at every zero crossing. (1 - cos) / 2 is the drop-in replacement

Detecting a kink without picking a threshold

This is the practically useful part.

My first attempt divided the jump by the amplitude and compared against a threshold. That doesn't work. Larger motions are penalised, so legitimate movement trips the check.

Instead, double the number of samples and see what happens to the jump.

	When you double the samples
A smooth curve	the jump halves — you were only sampling curvature
A real kink	it doesn't change — there is an actual corner there

Independent of amplitude and of speed. And no threshold to guess at.

3. Last, check whether it's visible at all

If you've fixed the smoothness and something still feels off, the motion may not be visible in the first place.

Movement along the depth axis — leaning forward, for instance — barely changes the image from a front-facing camera. I measured one pose where the top of the head moved 10 px. That's 0.65% of the screen height.

"Something feels off" turned out to mean "effectively nothing is happening."

Don't measure in degrees. Measure how many pixels it moves on screen. However far it rotates in 3D, if the camera can't see it move, it didn't move.

Writing the lesson down doesn't stop the repeat

About that third one, a confession.

It was already written in a comment in the same repository.

Forward/back motion runs along the screen's depth axis, so from a front view it looks like it isn't doing anything

I hit it once with a folded-arms pose and wrote that down at the time. Then I hit it again, somewhere else, having written it myself.

Keeping the lesson in a note was not enough. Unless a machine fails the build, you repeat it.

Smoothness now has npm run check:smooth, implementing the sample-doubling test directly.

Visibility I still measure by hand. That hole isn't closed yet.

Takeaways

Suspect overlap first. Jitter doesn't imply the interpolation is at fault
"Skip if playing" must see every path. A gate on one door is not a gate
Detect kinks by doubling the samples. Dividing by amplitude penalises big motions
Visibility is measured in pixels. Degrees will lie to you
Turn lessons into tooling. You will hit your own notes twice

Separately from this, I build a desktop AI agent called Wisp. It stands on your desktop, answers when you talk to it, and runs commands when you ask — always showing you what it's about to do first.

My VRM was rejected at upload and every viewer I own said it was fine

Renga — Fri, 21 Aug 2026 19:15:46 +0000

I uploaded Mira.vrm to VRoid Hub and it was rejected.

Nothing was wrong on my machine. Every viewer opened it correctly. My own VRM validation passed.

The error:

POSITION Z: declared -0.391, actual -0.238

The data was correct. The declaration about the data was wrong.

glTF accessors declare their own range

In glTF, separately from the vertex data itself, each accessor declares min and max.

{
  "type": "VEC3",
  "count": 12043,
  "min": [-0.512, 0.000, -0.391],
  "max": [ 0.512, 1.621,  0.284]
}

The spec requires that declaration to match the actual data. When it doesn't, the file is invalid — even though nothing about it looks wrong.

Why you cannot catch this locally

This is the part worth internalising.

Rendering reads the data. min/max are bounds metadata; they play no part in producing pixels. So when the declaration drifts, the render is still perfectly correct.

Open it in a viewer — fine
Run your own validator — passes
Ship it to a device — works

Everything you own reports "fine", because this isn't the kind of information you can check by looking.

The only thing that catches it is a distribution target that runs a real validator. Which means the place you find out is the moment before publishing.

Where it actually broke

A script that moves vertices around. On write-back it never recomputed min/max.

Walking the chain:

Artifact	Bounds
Input base file	correct
Intermediate build product	drifted
Final output	drifted

The input was clean, which pinned the damage to the transform step. Locating where it broke is what tells you the thing to fix is the script, not the file.

Fixing it must not touch the vertices

Recomputing bounds changes no vertex data at all.

node app/scripts/fix-accessor-bounds.mjs <file.vrm> --check

With --check it only inspects, exiting non-zero on drift. Without it, it repairs.

Afterwards I took the sha256 of the BIN chunk and confirmed it was byte-identical to before the repair. That's the guarantee that only the declaration moved. Skip that check and you're left unable to rule out "I broke the model while trying to fix it."

Writing the lesson down is not enough

This is the real point.

If "recompute bounds after moving vertices" only exists as a note, you will stop in the same place next time. A countermeasure that depends on remembering fails on the day you don't remember.

I wired it into verify:release-assets. A broken model now means the build refuses to start.

Then I dropped in a deliberately broken model and confirmed it actually fails. Adding a check isn't finished until you've watched it reject something.

The general shape

This trap isn't specific to glTF.

Metadata you cannot verify by looking must be recomputed on every transform, or checked by a machine.

Bounds — min/max, bounding boxes
Counts — count, length, total
Hashes — checksums, ETags
Offsets — byteOffset, index tables

All of them look correct while being wrong. And things that look correct go unquestioned right up until you publish.

Separately from this, I build a desktop AI agent called Wisp. That Mira.vrm is its default body. It stands on your desktop, answers when you talk to it, and runs commands when you ask — always showing you what it's about to do first.

I set the font to the largest size and found the same bug eleven times

Renga — Sun, 16 Aug 2026 00:01:23 +0000

I was cleaning up the UI on a side-project iOS app and did one thing: set Dynamic Type to XXXL and screenshot every screen.

Reading the code had turned up nothing. The screenshots showed problems immediately.

Eleven of them, in the end. All the same cause.

Here's the conclusion first. "A parent that pins things side by side" × "text that grows" is not a bug, it's a pattern. And in Japanese it breaks reliably worse than in English.

English truncates. Japanese stacks vertically.

Same layout, different failure depending on language.

English wraps at word boundaries and, failing that, ends in …. You can't read it, but you can tell something was cut.

Japanese doesn't do that. It can break between almost any two characters, so once a column is squeezed to one character wide, you get one character per line, stacked downward.

Actual output:

Rendered	Intended
`Paire / d / Macs`	Paired Macs (broken mid-word)
`Claud / e / Code`	Claude Code
One character per line	"実行中のセッション" (Running sessions)
Three step labels stacked vertically	A three-step horizontal stepper
`De / mo`, turning the capsule into a circle	A "Demo" badge

Paire / d / Macs is English breaking mid-word. Once the column has only a few characters left, even English gets there. Japanese gets there much earlier.

The cause had the same shape every time

Nearly all eleven were this:

HStack {
  Image(systemName: icon).frame(width: 44)   // fixed
  Text(label)
  Spacer()
  Text(value)                                 // pinned right
}

The 44pt icon and the trailing value claim their width first, leaving the label column a few characters.

The fix: rows that carry a value drop the value to the line below — but affordances like chevrons and toggles stay on the right.

That row component was shared across the whole settings tree, so fixing one place fixed the entire settings screen. Which also means one decision inside a shared component was breaking eleven screens.

`ViewThatFits` is not a general answer

I used ViewThatFits to switch to a stacked layout. It broke the standard size.

ViewThatFits decides using each child's ideal width. A title that wraps reports its unwrapped full length as its ideal width. So the side-by-side candidate was judged "doesn't fit" and the badge dropped below the title at the standard size.

I could not have reasoned my way to this. I found it by screenshotting the standard size.

Where each one belongs:

ViewThatFits — when every child is short and has an intrinsic width (badges, two-word metrics)
An explicit isAccessibilitySize branch — when one of the children is a sentence that wraps

Only pin things to the right if you operate them in place

I reversed one of my own calls partway through.

I'd classified a .menu Picker with Toggle, as something that belongs pinned right. A screenshot of the audit-log screen disproved that — the filter label came out as 絞り… / 込み.

The rule I ended up with:

Pin right — controls whose state changes in place (Toggle)
Allowed to take the full-width row — things that merely open something (.menu Picker, chevron)

The modals had never been tested at all

I had a UITEST_FORCE_ACCESSIBILITY_XXXL env var for UI tests. It applies .dynamicTypeSize to the root view.

That does not propagate into a .sheet's environment.

So the paywall and the setup guide had never once been rendered at the largest text size. What was passing was "the tests are green," not "the modals were checked."

Now it's applied from the system side:

xcrun simctl ui <udid> content_size accessibility-extra-extra-extra-large

I declared convergence twice

After fixing six, I wrote that the pattern had converged. It hadn't.

There were simply screens I hadn't looked at. When I did, four more appeared — numbers seven through ten. Then I went through the QR scanner, host-add and pairing flows in Japanese at XXXL, confirmed zero new findings, and only then called it converged at eleven.

The lesson is: don't declare convergence until you've actually looked at the screens. Judge by how many screens you looked at, not by how many you fixed.

And, incidentally, zero pluralization

While reading the audit log, 1 items need attention caught my eye. I swept the strings: of 38 English strings with a quantity placeholder, zero had plural variants.

1 items need attention
1 saved Macs
1 days free (on the paywall)
1 sessions, 1 active… — in a share-sheet body, i.e. it leaves the device

Thirteen keys got variants. Japanese has no plural agreement, so nothing changed there. Strings like %d of %d Macs, where the number doesn't agree with the noun, were deliberately left alone.

The verification order mattered. Add one key, build, confirm 1 item needs attention on a real screen, then roll out the rest. Finally, read en.lproj/Localizable.stringsdict out of the build product and confirm NSStringPluralRuleType was generated correctly.

Things I deliberately didn't change

Recorded honestly, on the principle of not manufacturing work:

The list screens survive XXXL intact
Onboarding is fully reachable by scrolling at XXXL (clipping at the boundary is normal ScrollView behaviour)
The top padding in settings is the standard .large navigation title layout — the same as Apple's own apps

What I'd take away

"Fixed horizontal layout" × "growing text" is a pattern, not a bug. Find one, suspect every screen
Japanese breaks worse than English. English truncates; Japanese wraps anywhere, so it stacks vertically
One decision in a shared component broke eleven screens — and fixing one place fixed all of them
ViewThatFits judges on ideal width. A wrapping sentence among its children will break your standard size
Pin to the right only what the user operates in place
Env vars don't reach sheets. "Tests are green" is not "I looked at the modal"
Don't declare convergence until you've looked at the screens

Reading the code found zero of the eleven.

Separately from this, I build a desktop AI agent called Wisp.
It stands on your desktop, answers when you talk to it, and runs commands when you ask — always showing you what it's about to do first.

My evidence pipeline was saving Cloudflare block pages as evidence

Renga — Sat, 15 Aug 2026 15:58:57 +0000

I build a web service that preserves evidence of harassment on social platforms.

The core feature is a single thing: automatically capture a real screenshot of the offending post.

There was no substitute for it. I built an alternative that pulled the text through an API and rendered a tidy "evidence card" image, and threw it away. An image you can author freely afterwards proves nothing.

Here's the conclusion first. Third-party wrappers eventually die, and when they do, the failure comes back as a plausible-looking image rather than an error.

The first approach was refused by the other side

I started with Cloudflare Browser Rendering. The wiring worked. The capture didn't.

X blocks headless browsers. The request times out
YouTube refuses script injection under a Trusted Types CSP. There's no way to make it render the comment

Neither is a bug in my implementation — that is how they are built. So I declared Cloudflare alone impossible for this and moved to a service with a real browser and bot avoidance behind it.

Both captures started working. For X, open the post page and clip the tweet element. For YouTube, open the URL with &lc= and screenshot just that comment element.

Element screenshots have one trap worth knowing: selector_algorithm=clip returns a blank image when the element sits below the fold. The selector matches, the capture "succeeds," and the file is empty. That took a while to see.

ytd-comment-thread-renderer:has(a[href*="lc=ID"])

A parameter that had worked started returning 400

I wanted timestamps rendered in Japan time, so I passed time_zone: Asia/Tokyo.

One day every request started coming back 400. Every capture failed.

The provider had narrowed which timezones they accept. Nothing changed on my side.

I could diagnose it immediately only because I was storing the raw error body in the database. The response went into rawPayload.screenshotError, so opening one row told me why. Without that, this starts as "captures stopped working, no idea why."

The fix was to drop the parameter, leave the rendering in GMT, and record the legally meaningful capture timestamp on my side, in JST. How a third party displays a time is their business and can change. What I record is mine and doesn't.

This was the bad one

For X captures I was going through a third-party embed wrapper called twitframe.

That domain had been retired.

Here is what that looks like from the inside. The capture succeeds. HTTP 200. An image is written to storage. The image is a Cloudflare block page.

So: as evidence of online harassment, I was storing error screens.

If it had failed, I'd have known. It didn't. A stored, plausible-looking image doesn't stand out when you scan a list of them. You find out when someone needs to actually use it.

Two causes stacked:

A dependency on a third-party wrapper. When the domain dies, nobody tells you
ignore_host_errors: true was set. That says "continue capturing even if the host returns an error" — which is precisely permission to save a block page as a success

ignore_host_errors is reasonable when a slightly broken capture beats no capture. In a feature that handles evidence, it is only a hazard.

X capture now goes through the official embed:

platform.twitter.com/embed/Tweet.html?id=

A third-party wrapper ends when that person stops caring. An official embed is maintained because the platform wants it maintained. Both are "someone else's," but only one has a reason to keep existing.

Making it faster removed the evidence

Scanning was slow, so I moved capture from synchronous to background. It got faster.

Saved evidence stopped having screenshots attached.

The save path assumed "by the time we get here, the screenshot exists" and copied it forward. Make the earlier stage async and that assumption quietly stops holding.

The fix is two-layered:

scanning responds immediately and captures in the background
at the moment evidence is saved, check for the screenshot and capture it right there if missing

Anything missed also gets picked up by the next scan.

When you move a synchronous step to the background, audit every later stage that inherited data assuming it was synchronous. Optimise on speed alone and this is the shape of the breakage.

What I'd take away

Third-party wrappers die. Use the official embed
When they die, the failure arrives as a plausible image, not an exception
Flags like ignore_host_errors that mean "continue even if it looks wrong" are pure hazard when the artifact is evidence
Provider parameters change. Keeping the raw error body makes the day it changes a five-minute diagnosis
Separate values that depend on someone else's rendering (timezone) from values you must record yourself (capture time)
Move something to async, then re-check what the later stages assumed

"The capture succeeded" and "we captured evidence" turned out to be different claims. The first is visible in the status code. The second requires looking at the pixels.

Separately from this, I build a desktop AI agent called Wisp.
It stands on your desktop, answers when you talk to it, and runs commands when you ask — always showing you what it's about to do first.

My dev environment was hiding eight production bugs

Renga — Fri, 14 Aug 2026 17:43:04 +0000

I pushed a side-project iOS app to TestFlight and then stopped.
Every test I had run up to that point had run under __DEV__.

Sixty-second unlocks, anonymous sign-in, sample recordings.
Which means the paths that only exist in production had never executed once.

I don't own a spare device, so the most useful thing I could do was read those
paths in code. That turned up eight defects, every one of them production-only.

Here is the conclusion first. Enumerate the places where your development
environment is being convenient, and the defects are sitting right next to them.
Counting conveniences is faster than hunting bugs.

A 60-second unlock hid a duplicate notification

Notifications in this app arrive seven days later. Two things scheduled them:

creation time registered a task
a 03:00 daily sweep picked up anything not yet registered

The creation-time path never wrote the flag saying it had registered
(notificationScheduled). A seven-day capsule matches the sweep's condition
exactly, so both registered it and two notifications fired at the same moment.

In development I opened everything after 60 seconds. Opening it takes it out of
the condition, so the 03:00 sweep never once saw it. That's why I never saw it.

Now the creation path writes the flag and claims ownership.

The simulator not receiving notifications hid a missing main path

The tap subscription only used onNotificationOpenedApp, which fires only
while the app is alive in the background.

The notification arrives seven days later. By then the app is almost certainly
terminated. The main path was missing entirely.

export async function consumeLaunchNotification(): Promise<string | null> {
  return capsuleIdOf(await getInitialNotification(messaging));
}

The same blind spot hid a second defect: nothing registered the device token
right after the user granted permission.

On launch, try to register — fails, no permission (swallowed by .catch(() => {}))
User records something, gets asked for permission, grants it
Nobody registers here
Until the next launch, the server does not know this device exists

The very first capsule unlocks after 24 hours. That lands squarely inside the
window above. The first notification is the single most important one a product
sends, and it was likely never arriving.

Treating every send failure as a dead token

// before
const deadTokens = response.responses
  .map((result, index) => (result.success ? null : tokens[index]))

Plenty of FCM failures are transient: internal-error, server-unavailable,
dropped connections, quota. Valid tokens were being deleted by all of them.

Re-registration only happens on next launch. In an app people open once a week,
once you enter "no notifications, so I don't open it," you never come back.
The loop ends quietly.

Now only genuinely dead codes delete.

const DEAD_TOKEN_CODES = [
  'messaging/registration-token-not-registered',
  'messaging/invalid-registration-token',
  'messaging/invalid-argument',
];

Anonymous sign-in hid a reset that destroys the rhythm

The user-document upsert wrote hasCompletedFirstCapsule: false
unconditionally, every time.

Sign out and back in — or reinstall — and the next capsule opens in 24 hours
instead of 7 days. The weekly rhythm, which is the whole product, breaks.

In development, anonymous sign-in hands you a new uid each time, so you never hit
an existing document. That's why I never hit it.

An always-on connection hid "I recorded it and it vanished"

A function returning the pending-upload count existed. Nothing called it.

Record somewhere with no signal and this happens:

the upload fails, so no document lands in Firestore
the home screen reads that collection, so it shows "nothing recorded yet"
to the user it looks exactly like the recording vanished

Testers use this on trains. That is not an edge case, it's the normal path.

The copy I settled on:

3 items haven't been sent yet.
They'll go automatically when you have signal. They are not lost.

"They are not lost" is stated explicitly because in that moment it is
the only thing the user actually wants to know.

Permissions being pre-granted hid a dead end

iOS shows the system permission dialog exactly once. After someone taps
"Don't Allow," requesting again shows nothing and returns granted: false
immediately.

The screen still offered an "Allow" button. Pressing it did nothing.
The answer screen deliberately has no way out, so anyone who denied the
microphone could not answer at all. That is the response rate, dead.

Now it checks canAskAgain and switches to "Open Settings" when asking is over.

const exhausted =
  (mode === 'video' && cameraPermission && !cameraPermission.canAskAgain) ||
  (microphonePermission && !microphonePermission.canAskAgain);

The simulator grants permissions, so this branch never ran.

Not having shipped the public feed hid two rule holes

allow update: if isOwner(resource.data.uid);   // before

The ownership check reads the uid on the existing document. Rewrite the uid
in the request to someone else's and the condition still passes, because the old
uid is yours.

Separately, the read condition was
visibility == 'public' && moderationStatus == 'ok' while updates were
unrestricted — so an owner can set both in the same write.

There is no public feed UI yet, so nothing surfaces.
The moment the public feature ships, review becomes self-approval.

Moderation only means anything when the moderated party cannot write the verdict.

allow update: if isOwner(resource.data.uid)
              && request.resource.data.uid == resource.data.uid
              && request.resource.data.moderationStatus == resource.data.moderationStatus;

Some I left alone

Issue	Call
`createdAt` not pinned	You can fake "N days ago," but only to yourself
`status` freely writable	Same
Owner can read own media pre-unlock	Documented as known in the rules

Each of these only lets you break your own experience. Re-evaluating when the
public feature ships.

What I'd take away

All eight were concealed by a property of the development environment itself.

What hid it	The defect
60-second unlock	Duplicate notification (never reached the 03:00 sweep)
Simulator gets no notifications	Tap from terminated state; token unregistered after grant
Anonymous sign-in (fresh uid each time)	Re-sign-in resets to first-run state
Stable always-on connection	Upload failure invisible
Permissions pre-granted	Anyone who denied once can never record again
No public feed yet	uid and moderation verdict both rewritable

"It worked in dev" is not evidence that it works in production
Don't hunt bugs — enumerate where your environment is being convenient
List the conveniences one line at a time; the defects are next to them
Treating transient and permanent failures identically deletes the recovery path
Put failures on screen. Anything not shown reads to a user as "gone"

The app this came out of is Wisp.
It stands on your desktop, answers when you talk to it, and runs commands when you ask.
It always shows you what it is about to do, and waits for your approval.

My approval dialog grew until the buttons went off screen

Renga — Fri, 14 Aug 2026 04:27:06 +0000

Originally published on my own site.

I build a desktop app where an AI agent can run commands on your machine. Every
command goes through an approval dialog first: here is exactly what I am about
to run, yes or no.

Halfway through recording a demo, I got stuck. The buttons went off the
bottom of the screen and I could neither approve nor reject.

The conclusion first: showing the user everything and letting the user choose
are two different properties. Once they cannot choose, there is no approval
step — there is just a modal.

What happened

The model decided to write an HTML file, and built this:

cat > index.html <<'EOF'
<!doctype html>
… 4,558 bytes of HTML …
EOF

That whole string goes into showMessageBox's detail. The file contents
became the height of the approval dialog. It grew taller than the display and
the buttons ended up somewhere below the bottom edge.

detail does not scroll.

Escape worked. Enter did not.

Two things I found while stuck:

Escape dismissed it
Enter did nothing

Because I had set defaultId and cancelId both to 0 — the safe button. On
macOS, when those two point at the same index, the Return key equivalent is
dropped.

Defaulting to the safe button is the right call; it stops a stray Enter from
approving something dangerous. But that same setting removes the keyboard
path to approving at all. Decide one without looking at the other and this is
where you land.

Having Escape as the only escape hatch is a thin design.

The same recording broke in a second place

cd ~/work && claude "build me a landing page" went down the
wait-for-the-result path. Claude Code sat at its prompt until the 60-second
timeout killed it.

No terminal ever opened, so from the user's side nothing happened at all.
I confirmed it afterwards: not one hand-off script had been written to disk.

Interactive commands must never go down a path that waits for output.

Three layers of fix

1. Split file writing out of command execution

What the approver needs to see is different for the two operations.

For a command, you need the whole thing to judge what it does. For a write, what
you need is where, how many bytes, and is it an overwrite. The content
itself can be inspected separately if you want it.

Splitting the tool decoupled the dialog's size from the content's size.

content written	dialog
4,558 bytes of HTML	16 lines
34,889 bytes	17 lines

Three more decisions came with it:

Overwrites are their own case. warning type, and the words "this will be lost"
Expand ~ and relative paths before asking. Approve the unexpanded string and the path you approved can differ from the path that gets written
Both dialogs default to the "do not write" button

2. Refuse terminal-hogging commands before asking

claude, codex, gemini, vim, ssh, psql and 18 others. Check every
segment joined by &&, ||, ;, |.

export function findInteractiveCommand(command: string): string | null {
  for (const segment of command.split(/&&|\|\||[;|]/)) {
    const words = segment.trim().split(/\s+/)
      .filter((w) => !/^[A-Za-z_][A-Za-z0-9_]*=/.test(w));   // skip FOO=1
    const head = (words[0] ?? '').replace(/^.*\//, '').replace(/^["']|["']$/g, '');
    if (INTERACTIVE_COMMANDS.includes(head)) return head;
  }
  return null;
}

Making someone click a button and then failing is bad manners. Refuse
before the dialog, and tell the model to use the hand-it-to-a-terminal tool
instead.

3. If it is still long, truncate the display

14 lines / 900 characters. Write the full text to a temp file and put that
path in the dialog.

Never truncate the thing being approved. Only the string being shown. Mix
those two up and you get the worst possible shape: the user approves something
short and something long runs.

How do you test "can still be clicked"?

You cannot eyeball it. What you can write down is that the size does not
depend on the content.

it('stays the same size regardless of content length', () => {
  const short = planWrite('/t/a.html', '<p>hi</p>', '/', () => false);
  const huge  = planWrite('/t/a.html',
    Array.from({ length: 2000 }, (_, i) => `<p>${i}</p>`).join('\n'), '/', () => false);

  const a = String(buildWriteApproval(short, 'reason', 'en').options.detail);
  const b = String(buildWriteApproval(huge,  'reason', 'en').options.detail);

  expect(b.length).toBeLessThan(a.length + 200);
  expect(b.length).toBeLessThan(900);
});

a.length + 200 is the real assertion; 900 is a belt-and-braces ceiling.
"The big one is about the same as the small one" encodes the entire reason
the tool was split.

For the interactive check, assert that no dialog was shown at all:

it('refuses before asking — no dialog at all', async () => {
  const showMessageBox = vi.fn();
  const executeCommand = vi.fn();
  await runCommand('cd ~/x && claude "build it"', 'reason', { showMessageBox, executeCommand, … });

  expect(showMessageBox).not.toHaveBeenCalled();
  expect(executeCommand).not.toHaveBeenCalled();
});

A postscript: the display depended on how the argument was passed

While fixing the above I found one more. The "open a file" approval was
printing whatever string the model handed it.

First call: ~/Downloads/…. Second call: /Users/<my-username>/Downloads/….
Same file, different display.

If the display depends on how the argument was phrased, it is not an approval
screen. Now the path is resolved to an absolute path for opening, and only
the displayed string is folded back to ~.

Worse, the ~ form would not have opened at all — Electron's
shell.openPath does not expand it. Approving that dialog did nothing.

Takeaways

Showing and choosing are different. No choice, no approval
Matching defaultId and cancelId kills Enter on macOS
What the approver needs differs per operation. Split the tool
If you are going to refuse, refuse before the click
Never truncate what is being approved. Only what is displayed
"Still clickable" is testable as size does not depend on content

The app this came out of is Wisp — a
desktop agent with a 3D body that runs commands and writes files, and shows you
exactly what it is about to do first.

I redacted my username from a screen recording three times and missed it every time

Renga — Fri, 14 Aug 2026 03:46:41 +0000

Originally published on my own site.

I make a desktop AI agent. I recorded a demo of it writing files, and the
approval dialog showed /Users/<my-username>/Downloads/… in plain text.

Blurring it out should have been a five-minute job. I checked the result by
eye three times and missed a leak every time. The fix that finally worked was
scanning the finished video with a machine.

The conclusion first: you cannot verify a redaction by looking at it. The
scan needs to be as much a part of the pipeline as the blur.

A fixed rectangle does not cover a moving dialog

The naive version: open one frame where the path is visible, measure the box,
and paint over it.

delogo=x=450:y=300:w=370:h=44:enable='between(t,99.9,102.4)'

The result had the username visible for the first one or two seconds.

macOS dialogs animate in. They keep moving until they settle.

time (s)	dialog top	dialog left
98.4	372	458
98.8	230	180
99.2	19	462
99.6	71	407
100.0	94	398
102.4	94	398

A box measured at 100.0 s lands nowhere near the frame at 98.4 s — and the text
is legible the whole way in.

You can sidestep this by trimming each cut to start after the dialog settles.
That was not available here: the whole point of the video was that it is
uncut. So the box has to follow the text.

Track it with an FFT correlation

The dialog moves, but the font size does not. So take the rendered
/Users/sa from a settled frame as a stencil, and slide it over every
frame to find the best match.

Done directly, that is 2 million positions × 5,700 pixels per frame. Python
will not finish. Correlation is a convolution, and convolution is one
multiplication in the frequency domain.

def correlate(field, kernel):
    """Convolution via FFT. The direct loop does not finish."""
    fh, fw = field.shape
    F = np.fft.rfft2(field)
    K = np.fft.rfft2(kernel[::-1, ::-1], s=(fh, fw))
    out = np.fft.irfft2(F * K, s=(fh, fw))
    kh, kw = kernel.shape
    return out[kh - 1:, kw - 1:]        # align the origin to top-left

Score on two things: misses and over-eager matches.

def find(img, tmpl):
    d = dark(img)
    hit  = correlate(d, tmpl)                    # stencil ink ∩ frame ink
    load = correlate(d, np.ones_like(tmpl))      # total ink inside the window
    ink  = tmpl.sum()

    score = hit / (load + 0.35 * ink + 1e-6)
    score[hit < 0.55 * ink] = 0                  # reject misses outright
    y, x = np.unravel_index(int(np.argmax(score)), score.shape)
    return int(x), int(y), float(score[y, x])

hit on its own latches onto any dense block of dark pixels — a code excerpt,
for instance. Dividing by load penalises windows carrying ink the stencil
does not account for. The 0.35 * ink term in the denominator keeps the score
from exploding in near-empty regions.

Feed the per-frame boxes into delogo's enable. Merge runs at the same
position, or you end up with 500 filters and the graph stops building.

Three misses

One — mid-animation

The one above. The fixed box does not land.

Two — while it fades up

Tracking still leaked. The dialog appears translucent first.

My dark() threshold was 120, so the faint text on those frames did not count
as ink and tracking never started there. Faint text is still readable text.

def dark(img):
    # Threshold is 150. At 120 the faint text of the fade-in is dropped,
    # tracking never starts, and those frames pass through untouched.
    return (img < 150).astype(np.float32)

I also extend each run 0.3 s earlier and 0.2 s later.

Three — the browser address bar

This is the one that mattered.

At the end of the video the agent opens the generated HTML in a browser.
The address bar showed file:///Users/<my-username>/… for 23 seconds.

I had been staring at dialogs. It never occurred to me to look there.
You do not find what you did not think to look for.

So scan the finished file

At that point I stopped trusting the redaction and started scanning the output.

TEMPLATES = [
    (100.0, (452, 302, 150, 38)),   # write_file  … larger type
    (148.7, (850, 512,  90, 28)),   # open_path   … smaller type
    (152.0, (940,  12, 100, 30)),   # address bar … different again
]

One stencil is not enough. Different dialogs are different widths and set
their text at different sizes. With a single stencil the smaller one never
matched at all and instead latched onto false peaks around 0.30.

Set the verification threshold higher than the tracking one. Measured: real
hits scored 0.64–0.74, false peaks topped out at 0.46, so 0.55 separates them
cleanly. At 0.45 the scan flagged 179 frames of browser iconography and buried
the real result.

The scan found one more leaked frame.

Sample the tracker at the output frame rate

The leak was at 113.933… s.

I was tracking at 20 fps, so I looked at 113.90 and 113.95. The output is
30 fps, so the frame that actually ships is 113.933…. Nobody looked at it.

# (start, end, frames per second to sample)
WINDOWS = [
    (113.4, 118.2, 30),     # animating — sample at the output rate
    (150.8, 174.8,  5),     # static — coarse is fine
]

Sample the moving stretches at the output rate and leave the static ones
coarse. Running everything at 30 means 4,000 FFTs and no result.

Final pass: 2,225 frames scanned, nothing found.

Takeaways

A fixed rectangle cannot hide something that moves. Dialogs animate in
Track with an FFT correlation; the direct search does not finish
Score against both misses and over-eager matches
Eyeballing it missed three times. One was a place I never thought to check
Scan the finished file. Sample the tracker at the output frame rate

None of this is needed if the app never puts a username on screen in the first
place, which is the real fix and the one I shipped. I kept the scan anyway.
You do not find what you did not think to look for.

The app in the recording is Wisp — a
desktop agent with a 3D body that runs commands and writes files, and shows you
exactly what it is about to do before it does it.

Where to split a sentence for streaming TTS is decided by one number

Renga — Tue, 11 Aug 2026 16:29:14 +0000

I build a desktop app where you talk to a VRM avatar and it answers out loud. Someone told me the gap between speaking and hearing a reply was too long.

I measured it and fixed it. Then I found out my benchmark had been running on a machine with a full disk and a load average in the low hundreds, which made the number 4x worse than reality, and the design decision I derived from it was wrong for weeks without ever failing.

The conclusion first: the split point for streaming TTS follows from the real-time factor, and you should store the formula rather than the number it produces.

Seconds are the wrong unit

You cannot compare TTS engines by how long they took. Longer sentences take longer. What matters is the ratio against the length of the audio produced.

import io, wave
with wave.open(io.BytesIO(audio)) as w:
    seconds = w.getnframes() / w.getframerate()

rtf = synth_time / seconds   # real-time factor

r = 1.0 means 10 seconds of speech takes 10 seconds to synthesize
r = 0.25 means 10 seconds of speech takes 2.5 seconds

Every downstream decision comes out of this one number.

Measurements

VOICEVOX 0.25.2, Apple M4, 10 cores, idle machine.

chars	synthesis	audio length	r
3	0.38s	0.60s	0.64
7	0.59s	1.44s	0.41
21	1.16s	4.36s	0.26
40	1.74s	7.71s	0.23

Note that longer sentences get a better ratio. Short ones carry fixed costs (model setup, leading and trailing silence), so 3 characters at 0.64 is the worst case. That is already telling you not to chop too finely.

Warm up once before measuring. The first call includes model loading and gives you a number you cannot use.

The split point falls out of the ratio

If you synthesize the whole reply before playing any of it, the app is silent the entire time. So you cut the first sentence, start playing it, and synthesize the rest while it plays.

The question is where to cut. Cut early and audio starts sooner. Cut too early and you finish playing the first part before the second part exists, so the sentence has a hole in the middle.

Let r be the real-time factor, D the total audio length, and p the fraction of the sentence in the first chunk.

first chunk is synthesized at r*p*D
first chunk finishes playing at r*p*D + p*D
second chunk is synthesized at r*D (both chunks run back to back)

No gap requires that the second chunk is ready before the first finishes:

r*D <= r*p*D + p*D
   ->  p >= r / (1 + r)

r	minimum first chunk
1.0	50%
0.5	33%
0.25	20%
0.1	9%

At r = 0.25 anything past 20% works, so you can cut at an early comma and start talking almost immediately. At r = 1.0 you have to wait until halfway. The same code breaks or does not break depending on the machine.

// measured 0.23 to 0.64. short sentences carry fixed cost, so default high
export function splitAtComma(text: string, rtf = 0.5): [string, string] {
  const positions: number[] = [];
  for (let i = 0; i < text.length; i++) {
    if (text[i] === '、' || text[i] === ',') positions.push(i);
  }
  if (positions.length === 0) return [text, ''];

  const minRatio = rtf / (1 + rtf);   // the lower bound, from r

  // earliest comma that satisfies it = earliest possible start
  for (const pos of positions) {
    const ratio = (pos + 1) / text.length;
    if (ratio >= minRatio && ratio <= 0.7) {
      return [text.slice(0, pos + 1), text.slice(pos + 1)];
    }
  }
  return [text, ''];
}

Only the first sentence needs splitting. Everything after it gets synthesized while the previous chunk plays.

The part I got wrong

My first measurement gave r = 1.09. More than 4x worse than the table above. I believed it, concluded that local TTS runs at roughly real time, put r = 1 into p >= r/(1+r), and shipped "split in the middle".

I also tested thread counts and got 1.09 -> 1.47 going to 8 threads, so I concluded there was no headroom in parallelism.

Both conclusions were wrong. Here is what the machine looked like.

	first run	re-run
load average	99 to 214	5
free disk	833 MB (100% used)	38 GB
r	1.09	0.23 to 0.64
8 threads	1.47 (worse)	0.20 to 0.51 (better)

The disk was full, so swap could not do its job, and the load average was in three digits. The number was not a lie. That is genuinely how long it took at that moment. Which is exactly why I had no reason to doubt it.

The nasty part is that the wrong conclusion worked. The real lower bound is 20%, so cutting at 50% satisfies it. It was only ever too conservative. It never crashed, never produced a gap, never showed up in a bug report. There was no symptom to chase, so nothing pointed back at the measurement.

What I take from it:

Check that the machine is idle before benchmarking. uptime and df. Thirty seconds.
Look at ratios, not wall clock. "4.7 seconds" tells you nothing is wrong. "r = 1.09" is shaped like something you can recognize as absurd.
Store the formula, not the constant. If I had written p >= r/(1+r) from the start instead of "split in the middle", re-measuring r would have fixed the behaviour everywhere, by itself, the moment I got a clean number.

The third one is the real lesson. A constant freezes an assumption you made on one particular day on one particular machine. A formula carries the assumption as an input, so correcting the input corrects the system.

Two smaller traps on the way

The playback side needs a queue. I sent chunks as they finished and the second one cut off the first, because synthesis is async and chunk two was ready while chunk one was still playing. When you add the queue, watch out that on an HTML audio element ended and error can both fire for the same clip. If your advance handler is on both without a guard, you silently skip a sentence. It reads like a synthesis bug, so I spent a while in the wrong layer.

I measured while the previous reply was still playing. I was watching a lipSyncAttached flag to decide when audio had started, and got 0.1 seconds. It was not fast. The previous answer had not finished. Wait for actual silence before starting the next measurement:

while state["lipSyncAttached"]:
    time.sleep(0.1)

Summary

Confirm the machine is idle before you measure (uptime, df)
Use the real-time factor, not seconds
The split point is p >= r/(1+r). At r = 1.0 that is halfway, at 0.25 it is a fifth
Keep it as a formula so it follows the machine instead of freezing one day's guess
Queue the playback, and guard against ended and error both firing

These numbers come from building Wisp, a desktop AI agent with a VRM body. p >= r / (1 + r) is in the shipping code.

DEV Community: Renga

I published three posts in one day and two of them were never seen by anyone

I killed two explanations first

Were the tags too small?

Was it published at a bad hour?

Only the count is left

Zenn does the same thing, worse

The fix is a machine, not a resolution

What I'd take away

The jitter wasn't in the interpolation. It was in the schedule.

1. First, suspect overlap

2. Then, suspect velocity discontinuity

Detecting a kink without picking a threshold

3. Last, check whether it's visible at all

Writing the lesson down doesn't stop the repeat

Takeaways

My VRM was rejected at upload and every viewer I own said it was fine

glTF accessors declare their own range

Why you cannot catch this locally

Where it actually broke

Fixing it must not touch the vertices

Writing the lesson down is not enough

The general shape

I set the font to the largest size and found the same bug eleven times

English truncates. Japanese stacks vertically.

The cause had the same shape every time

ViewThatFits is not a general answer

Only pin things to the right if you operate them in place

The modals had never been tested at all

I declared convergence twice

And, incidentally, zero pluralization

Things I deliberately didn't change

What I'd take away

My evidence pipeline was saving Cloudflare block pages as evidence

The first approach was refused by the other side

A parameter that had worked started returning 400

This was the bad one

Making it faster removed the evidence

What I'd take away

My dev environment was hiding eight production bugs

A 60-second unlock hid a duplicate notification

The simulator not receiving notifications hid a missing main path

Treating every send failure as a dead token

Anonymous sign-in hid a reset that destroys the rhythm

An always-on connection hid "I recorded it and it vanished"

Permissions being pre-granted hid a dead end

Not having shipped the public feed hid two rule holes

Some I left alone

What I'd take away

My approval dialog grew until the buttons went off screen

What happened

Escape worked. Enter did not.

The same recording broke in a second place

Three layers of fix

1. Split file writing out of command execution

2. Refuse terminal-hogging commands before asking

3. If it is still long, truncate the display

How do you test "can still be clicked"?

A postscript: the display depended on how the argument was passed

Takeaways

I redacted my username from a screen recording three times and missed it every time

A fixed rectangle does not cover a moving dialog

Track it with an FFT correlation

Three misses

One — mid-animation

Two — while it fades up

Three — the browser address bar

So scan the finished file

Sample the tracker at the output frame rate

Takeaways

Where to split a sentence for streaming TTS is decided by one number

Seconds are the wrong unit

Measurements

The split point falls out of the ratio

The part I got wrong

Two smaller traps on the way

Summary

`ViewThatFits` is not a general answer