DEV Community: Kenji Sakuramoto

From "this is broken" to a fix PR I merge by hand

Kenji Sakuramoto — Thu, 15 Oct 2026 04:18:01 +0000

A tester on my household-budget app, yen-yen, reported that on the Transactions screen the fixed header covered the first transaction row. It was a layout bug, so nothing threw and my error tracker had nothing to show. The row was still hidden.

Mushi Mushi (虫虫) is my attempt to close the gap between errors that throw and bugs that users feel. Below is what happens to one report, stage by stage, and why the two steps that touch my repo still wait for me.

What happens to one report

That tester tapped the widget in the app and typed one sentence: "The fixed header covers the first transaction row…"

Capture. The report arrives with their note, the route, the browser and viewport, and the last console and network events. A screenshot is attached, and the reporter can remove it before sending. If session replay is on for that session, the last 30 seconds come along too.
Filter. Claude Haiku 4.5 makes a cheap first pass and drops spam and noise.
Diagnose. Reports that pass go to a second model (Claude Sonnet 5.5 by default, GPT-5.4 as the fallback). It writes a category, a severity, the likely component, a plain-English summary and a confidence score. It reads code retrieved from my repo while it does this, so it can name a file it actually saw instead of guessing. On the hosted service this takes about 10 seconds.
Group. Each report is embedded and compared with earlier ones by cosine similarity in pgvector. Above 0.82 (the default; each project can change it), the new report joins the existing group instead of opening a new row. Grouped duplicates don't count toward the monthly diagnosis quota. Until early October the per-project threshold was saved but never read, so every project got 0.82. It is read now.
Fix. Auto-fix stays off until I enable it for a project. Then I click Dispatch fix on the report. The fix worker loads whole files from the repo at a pinned commit and asks the model for find-and-replace edits through a typed schema. The model gets no tools and no shell. If the edits don't apply, the worker retries once with the exact error, then stops. If any single file's diff would pass 200 changed lines (a per-project setting), the run aborts. Otherwise it opens the PR as a draft and marks it ready for review so CI runs. Every LLM call is traced in Langfuse.
Check. The fix's PDCA receipt in the console shows CI on that PR as pending, passed or failed.
Act. I merge it, or I don't. On merge, Mushi marks the report fixed, resolves the linked Sentry issue if the Sentry plugin is on, and sends the person who reported it a "fixed" notice when their report can receive one.

For the header report, the diagnosis read: "Header stays fixed and covers the first transaction row when scrolling on Transactions; content clipped under sticky chrome on iOS + Android" (severity high, confidence 0.95). The draft fix it opened is public: yen-yen #68. I closed it without merging.

Why I still click merge

The loop could run without me: CI already runs on every fix PR. I kept the merge manual anyway.

The grades are useful, not final

A separate background job, the judge, re-reads classified reports in batches. It scores accuracy, severity calibration, component tagging and repro quality from 0 to 1, and says whether it agrees with the overall call. Those scores feed an A/B test between classifier prompts, so a better prompt can win. They don't change a report's status, and they aren't a reason to merge a fix unread. A severity that is off, or a fix aimed at the wrong component, is exactly what a loop with nobody watching would ship.

A wrong fix costs more than a slow one

When someone reports a bug and later sees it marked fixed, they learn that the app is looked after. An automatic fix that changes the wrong thing and breaks something else teaches them the opposite. The fix worker's header comment states the rule: "human still confirms merge — nothing auto-merges." I made the path from report to reviewable PR fast and left the merge to me.

What's open source

The SDKs are MIT: @mushi-mushi/web for any site, plus React, Vue, Svelte, Angular, React Native, Capacitor and Node. The CLI and the MCP server are MIT too. iOS, Android and Flutter SDKs are in preview. The server (Supabase Edge Functions, Postgres and pgvector) is AGPLv3. You can self-host it for your own product for free, with your own LLM key and no diagnosis cap. If you run a modified server as a service for other people, AGPL §13 asks you to publish your changes, or you can take a commercial license.

Source

The fix worker, the judge and the grouping code described above are in github.com/kensaurus/mushi-mushi.

If you've caught user-reported bugs that never threw anything, I'd like to hear how.

I wrote this post with help from an AI assistant. The numbers, the quoted report and its diagnosis come from the Mushi repo and the public yen-yen PR linked above.

A 147,000-word interactive book as a free SPA, and the stack behind it

Kenji Sakuramoto — Thu, 23 Apr 2026 07:48:48 +0000

the wanting mind is a free 147,000-word interactive book: no ads, no account, in English, Japanese, Chinese and Thai. It is a React 19 SPA with Supabase behind it and Capacitor for the mobile apps. ElevenLabs reads the chapters, fal.ai made the chapter art, Veo made the hero videos, and Claude translated the chapters. This post covers what worked, what I'd do again, and the stack.

What it is

A long-form book about why we're never satisfied: the economics, neuroscience and Buddhist philosophy of taṇhā ("thirst"). At 147,000 words, reading it cover to cover takes about eleven hours. Most people won't do that, so the app gives them other ways in:

Narrated chapters. ElevenLabs voices, with 12 narrator personas.
A 3D knowledge graph of the concepts, people and chapters, built with react-three-fiber.
22 simulations you can play with: the Easterlin paradox, Minsky moments, r > g.
Four languages, switchable while you read.
An "essence" view: each chapter compressed to one quote over its chapter image, shareable as a card.

Read it: kensaur.us/the-wanting-mind

The stack

Layer	Choice	Why
Framework	React 19 + Vite 8	Fast dev loop; a prerender step after the build for SEO
Language	TypeScript 6	The book's content lives in typed data files, so a typo in a chapter reference fails the build
Styling	Tailwind CSS 4	Design tokens in one file, dark mode with `dark:`
3D	reagraph on react-three-fiber	The knowledge graph and the closing constellation scene
Mobile	Capacitor 8	The same React build for iOS and Android
Auth + DB	Supabase	Accounts and cloud sync, with row-level security
Audio	ElevenLabs	English narration of all 36 chapters, about 20 hours
Images	fal.ai (nano-banana-2)	Chapter essence images, batch-generated
Video	Veo 3.1	35 looping hero videos and a cover video
Translation	Claude	Chapter by chapter, into Japanese, Chinese and Thai
Hosting	S3 + CloudFront	Static files; no server to keep running
Errors	Sentry	Errors on readers' devices reach me without anyone having to report them
Push	Firebase Cloud Messaging	Notifications to signed-in readers' devices

Three things that mattered more than I expected

1. Prerendering chapter HTML

An SPA serves one HTML shell for every route. Google can render JavaScript, but other crawlers and link previews often read only that shell. So scripts/prerender-chapter-html.mjs runs after vite build. It copies dist/index.html once for every chapter and feature page in all four locales, and gives each copy its own <title>, description, canonical URL and OpenGraph tags. The deploy uploads each file to the matching S3 key, so a crawler or link preview asking for /ja/ch-4 gets that chapter's title and description in the first response. The chapter text itself still renders in the browser.

2. Quote cards drawn in the browser

Every chapter has an "essence", one sentence that sums it up. generateQuoteCardBlob in src/components/QuoteCard.tsx draws it as a 1080×1080 card on a Canvas: the chapter image as the backdrop, a translucent overlay, the quote, and the book's name. It runs in the browser with no server. Readers can save the card or share it with navigator.share() on mobile.

For social posts I call the same function from a Playwright script (scripts/generate-quote-cards.mjs), so the cards I post are the cards readers get.

3. Store listings from one file

The store listings exist in four locales on both stores, and editing them by hand is slow and easy to get wrong. Two scripts do it now:

scripts/asc-update-listing.mjs signs a JWT with the App Store Connect API key, reads the listing copy from docs/store-listings.md, and pushes name, subtitle, promotional text, description and keywords for each locale.
scripts/play-update-listing.mjs does the same through the Google Play Publisher API with a service account.

docs/store-listings.md is the one place the listing copy is edited.

If you build something similar

Pick one mobile shell (Capacitor or Tauri) and stay with it.
Prerender before you write growth posts. The posts link to pages, and the pages should show their content to whatever opens them.
Add error reporting on the first day, even for a personal project.
Generate marketing images from the app's own code, so they match what readers see.
Keep the content (chapters, essences, graph nodes) as plain TypeScript files in git. For a single author, that is enough of a CMS.

What's next

The source isn't public yet. If a translation reads wrong, the feedback button in the app reaches me directly.

I wrote this post with help from an AI assistant. The figures come from the project's repository.