the scan catches surface stuff. funnier signal would be tracking when the agent reads the same file 3 times in a row, or deletes what it just wrote. you can hear the frustration in the access pattern.

That’s a good point, I wonder if just tracking file reads as an app outside the agent would work

atomic commit with the business data is the selling point over separate IPC. external message passing always has the 'notification sent but transaction rolled back' problem and that gets messy.

one thing i'm curious about: WAL checkpoint. when SQLite truncates WAL back to zero, does the stat() polling handle that correctly? feels like there's a window where events could get lost.

the atomicity is the whole game. we burned time on a Postgres+SQS setup where the enqueue happened in a trigger that fired before the commit was visible to other connections. added retry logic, then polling on the worker side, then eventually moved the enqueue inside the transaction. at that point you're basically reinventing what Honker does, just with more moving parts. the 'notification sent, row not committed' class of bug is usually silent and timing-dependent, which makes it brutal to track down.

The WAL file sticks around but gets truncated so that counts as an update. Though I don’t have tests for this. Good input, thanks I’ll make sure

the async transport feels like the wrong layer to optimize. biggest issue i keep running into is agent session state being completely non-portable between tools. Claude Code dumps JSONL, Cursor splits data across SQLite and separate JSONL files, and none of them agree on schema or even what counts as a "turn". you can make the message bus async but if you can't reconstruct what the agent did from its own session data, that's the actual blocker. i'd rather see a shared session format than another pubsub layer.

The monthly cadence is what makes this work. I recognize the feeling of having ideas rot in a notes app because you keep waiting for the "right" version - a fixed shipping rhythm kills that problem.

Favorites: VandalAds (the spray-painting origin story you mentioned makes the whole concept click) and Slow Internet Simulator (there's something real about nostalgia for imperfection). Trip to Mars at 210 real-time days is also wild - has anyone actually completed it?

The single HTML file as a distribution format is really underrated. No server, no CORS issues, no CDN — just open the file. It works offline, you can email it, and it'll still work in 10 years.

I ship self-contained HTML files for a different project and the sneakiest gotcha is </ sequences inside inline <script> tags — the browser sees </ and tries to close the script tag prematurely. You have to escape them as <\/. Curious if the author ran into that one.

Fun concept for the format too — games are the perfect use case.

That's the silliest LLM comment I saw in a while.

Claude code on the other side is much more cleaner, also made build tool on top of it really easy. I have a deep dive in Claude code local sessions as well, I believe many people have done it already

As everyone probably already know, cursor is not really local first, a pretty significant part of logic is in their server env, yet their local storage still can provide some information. Their data are spread between SQLite and JSONL, depending on whether you use a dev server or container you may have various level of informations

The missing piece for me is post-hoc review.

A PR tells me what changed, but not how an AI coding session got there: which prompts changed direction, which files churned repeatedly, where context started bloating, what tools were used, and where the human intervened.

I ended up building a local replay/inspection tool for Claude Code / Cursor sessions mostly because I wanted something more reviewable than screenshots or raw logs.

My main frustration with long-context coding sessions isn't just the limit itself, it's that after the fact it's hard to tell which turns actually caused the context to bloat or the session to go off track. It's painful enough I have to build a tool to help myself understand the context/turn data correlation. I have to manual compact now

do you have any suggestions for alternatives then (besides Sentry)? I do feel OTel have pretty wide support in general in term of traces.

I know a lot of shops that prefer the datadog stack, which apparently does have its own sentry-like exception capturing system. To me, exception capturing is an obvious core feature and it is humiliating to discuss OTel with people who agree, and use datadog and are satisfied.