DEV Community: Renga

A finished revision can still leave a stale review copy

Renga — Wed, 04 Nov 2026 04:51:35 +0000

A technical article had been revised locally, and the completion record contained the revised file's hash. The cloud copy provided for review still contained the earlier draft.

The URL had not changed. That did not establish which text it contained. Comparing the local revision and the review copy as separate artifacts revealed the mismatch.

A filename and a URL do not identify the revision

In the saved records from October 20, 2026, the revised local draft was 5,387 bytes. The review copy was 3,171 bytes. The revision added information about the verification scope, while the review copy retained the earlier explanation.

The entire review text matched the preserved old draft. The current local manuscript matched the SHA-256 recorded when the revision was completed.

Those checks established two different states: the local revision existed, and the delivered copy matched the old draft. An accessible URL and an unchanged filename did not distinguish them.

Separate the original, the intended snapshot, and the readback

For this UTF-8 Markdown workflow, three artifacts have different jobs:

Artifact	Purpose
Working original	The document that can continue to change
Manuscript snapshot	The exact text intended for this handoff
Text read back from the review copy	An observation of what the destination contains

After updating the review copy, the readback string was encoded as UTF-8 and compared with every byte of the manuscript snapshot. The reported stored size was also 5,387 bytes, and the SHA-256 values matched.

The simplified check looks like this. This is explanatory pseudocode with the retrieval API and error handling omitted, not a newly validated distribution tool.

expected = bytes of the manuscript snapshot intended for review
observed = complete review-copy text encoded as UTF-8

Check every byte of observed against expected
Compare the reported stored size with the length of expected
Record the SHA-256 of the compared text and the check time

This evidence is a comparison of retrieved UTF-8 text and reported size. It should not be described as a separate raw binary download test of the cloud file.

Check history and sharing separately from content

Before the update, the existing review text was checked against the preserved old draft. The content was then updated under the same file ID. No new public link or sharing destination was created.

The saved records show that the filename, ID, parent location, and nonshared permission state remained unchanged. They also show more than an old revision appearing in a history list: that revision was read back and its complete text matched the preserved old manuscript.

That establishes that the earlier revision was readable at the time of the operation. It does not promise indefinite history retention. The comparison before writing is also not an atomic lock. Safe handling of an edit arriving between the comparison and the write was not established.

If the destination differs from the preserved draft in an unexpected way, there is insufficient evidence to call it merely stale and replace it. Preserve both versions and resolve which one should be used. Avoiding automatic resends after an uncertain outcome is an operational rule here, not the result of a network-fault injection test.

Text identity is not factual review or publication approval

A hash or full-text comparison helps identify what was handed over. It does not establish that the claims are correct, that the prose is clear, or that the author has approved publication.

For this article, I rechecked the saved October 20 operation records and readback text against the manuscripts retained locally. This is not a fresh inspection of the current cloud document. The development tests discussed in the underlying manuscript were not rerun either.

Revising the original does not prove that the review copy was updated. Linking the intended snapshot to the text read back from its destination made that handoff mismatch observable and allowed it to be resolved in this case.

AI assisted the operation's comparison process, the organization of the saved records, and the organization and writing of this article.

An unknown note category should stop the write

Renga — Sun, 25 Oct 2026 11:19:33 +0000

Reorganizing notes into content categories does not update the code that saves the next note. If that code still defaults to the old shared folder, it can recreate the location you just retired.

My AI assistant had a note tool that appended to a project folder when a project was supplied, and to a shared location otherwise. After reorganizing the notes, I changed that fallback into an explicit destination check.

A new default would keep the same ambiguity

Replacing the old shared path with the root of the new knowledge folder would still collect unclassified notes in one place.

Instead, a save without a project must specify an existing content category. Missing both inputs, supplying an unknown category, or supplying both a project and a category now produces an error without saving.

The implementation follows this simplified order:

Trim the project and category names
  → Reject both being supplied
  → Keep the existing project route when a project is supplied
  → Otherwise check the category against the existing allowlist
  → Reject a missing or unknown category
  → Only then resolve the destination, create directories, and append

The checks sit before directory creation. That gives the tests a useful negative condition: an unclassified note must not create even the save root.

Keep the tool contract and the writer in agreement

I added the category enum to the model-facing tool definition, updated its Japanese and English descriptions, and passed the category through the tool consumer to the saving function.

The saving function also checks the allowlist. A description telling the model to choose a category is not the only place enforcing the rule. When both a project and a category arrive, the writer rejects the ambiguity rather than silently choosing one.

This establishes a no-write condition and a model-facing instruction. It does not demonstrate that an interactive clarification screen has worked in the real app.

Test refusal as well as successful appends

The saved tests use temporary folders and dummy data:

Input or operation	Verified result
Neither project nor category	Error; the save root is not created
Unknown or path-like category	Error; the save root is not created
Both project and category	Error; no destination is silently preferred
Append to an existing note in a valid category	Existing filename and original byte prefix remain; the addition is present
Category supplied through the tool consumer	Writes into the selected content category
Project supplied through the tool consumer	Keeps the existing project route
Japanese and English tool definitions	Category input and contract consistency are checked

The assistant-side result is 57 passing tests across three files, including existing tests. These are not 57 newly added tests. The main-layer TypeScript typecheck also passed.

A separate mock test covers the related one-way note generator. It runs the actual generation body with a temporary home and guarded filesystem access. It checks the new category destination, the location of the entry note, preservation of manually written originals, and absence of the retired folder.

Applied source is a different result from working software

I reviewed the saved patch and results from October 21, 2026, Japan time. The record covers three runtime source files and four related test files, with hashes confirming that the applied bytes matched the tested bytes. I did not rerun these tests for this article.

The record does not establish a packaged build, a running assistant saving notes in the real vault, or a real synchronization run. The generator's existing cleanup behavior was not redesigned. Before a real sync, preserving manual additions made after the move still needs separate checking.

Rejecting path-like category strings also does not prove safety against every path operation, symlink, or concurrent write.

The change is small: when a note's destination cannot be determined, a convenient default must not carry it into a write. The rule belongs in the writer and its no-write tests, as well as in the instructions given to the model.

This article summarizes implementation and saved validation records. AI assisted the implementation, validation, and the organization and writing of this article.

A generated video still needs a receipt and a stopped runtime

Renga — Sun, 18 Oct 2026 10:44:26 +0000

The five-second video existed, but the embedded UI had not caught up. Its completion message and receipt field did not update, and its exit button remained disabled.

This happened in a private prototype running Wan2.2 TI2V-5B on an L4 in Google Colab. The useful result was more specific than “the tool worked”: generation, receipt, and runtime release each had separate evidence.

Inspect the existing job before submitting another

The trial generated one silent clip of a paper boat moving across water. It used Python 3.12.13, fixed dependencies, and model files whose hashes had been checked.

The worker had exited successfully. Rather than submit another generation, the operator used a helper path that read the existing job's state and exported its output. That recovered the MP4 and its settings JSON. The cause of the stale UI remains unconfirmed.

A button click, a completed worker, and a file received by the user are different events. A successful worker exit does not establish that the file reached the user.

A matching hash answers a different question from a valid video

The received MP4 was 571,335 bytes; its settings JSON was 2,301 bytes. Their sizes and SHA-256 hashes matched the generation-side receipt records.

That established byte identity. Media validation checked the requested output separately:

Check	Recorded result
Video encoding	H.264 / yuv420p
Dimensions	832 × 480
Frame rate and count	24 fps, 120 frames
Duration and audio	5.000 seconds, no audio stream
Decode	All frames decoded without errors

The generation graph handled 121 frames; the export used the first 120 to meet the receipt specification. The graph's frame count and the delivered file's frame count were recorded separately.

For this article, I checked that the current MP4 and settings JSON still match the saved receipt hashes. I did not rerun generation or the full decode. Successful decoding also does not establish the clip's overall visual or motion quality.

A stopped engine does not establish runtime release

The saved shutdown checks showed no remaining owned generation-engine process, a closed listening endpoint, and a successful worker exit.

Those checks did not establish that Colab had released the runtime. Automatic disconnection could not be confirmed after receipt verification, so the runtime was disconnected and deleted through Colab's normal menu. The resource panel then showed zero sessions, and the session manager was empty.

The interval from the pre-allocation clock to release confirmation was about nineteen minutes in this one trial. It is not a completion-time estimate for another model or environment.

Keep completion states small enough to prove

The trial supports five separate claims:

Claim	Evidence
Generation finished	Successful worker exit
The output met the media specification	Media metadata and the saved full-decode check
The same output was received	Matching MP4 and settings sizes and hashes
The generation engine stopped	Owned-process and listening-endpoint checks
The runtime was released	Zero-session checks after normal deletion

The UI's completion display, automatic shutdown, and continuous playback in a browser remain unverified or unresolved. Recovering a valid video is a narrower result than completing the entire GUI workflow.

This article draws on implementation and saved verification records. AI assisted development, verification, and the organization and writing of the article.

A CSV comparison result expires when its inputs change

Renga — Thu, 15 Oct 2026 12:58:51 +0000

A CSV comparison has more inputs than two files. It also depends on the encoding, the key columns, the column mappings, and the fields the user wants to protect.

After a comparison finishes, the user can change any of those inputs. If the old result remains visible until the next comparison finishes, the UI can show a new filename next to an old diff. An enabled save button can turn that mismatch into a report.

A private browser-local CSV prototype handles this by expiring results as soon as their inputs change. This article describes its implementation and stored test records. It does not describe a customer incident or a public product launch.

The prototype runs previews, comparisons, and HTML report generation in Workers. A controller on the UI side owns result state.

Write the expiration rules first

Consider this illustrative sequence:

Start a comparison using configuration A.
Change the key column to configuration B before A finishes.
Receive A's result.

The result can be internally correct and still be unusable in the current UI. The relevant question is which state changes invalidate it.

The prototype uses these rules:

Action	Completed comparison	Unsaved report
Change a file, encoding, key, mapping, or protected field	Clear	Clear
Change only the case name	Keep	Clear and regenerate with the new name
Start another comparison	Clear	Clear
Cancel or reset	Clear	Clear

The case name is report metadata. It does not participate in the diff calculation, so a completed comparison can survive a name change. Cancel keeps the selected files; reset removes their references too.

These transitions clear data from application state. The result display and save button derive their availability from that same state. Hiding a panel while keeping an old report available elsewhere would leave the expiration rule incomplete.

An input epoch and a job token answer different questions

Each input change increments an epoch. A job receives the current epoch when it starts, and the state reducer rejects an event from another epoch:

This epoch tracks input and state generations. Changing the case name, canceling, or resetting also advances it. Rerunning a comparison without changing the inputs does not.

// State-update excerpt: events carry the epoch used to start the job.
if (event.epoch !== state.epoch) return state;

That rejects configuration A's result after the user moves to B. It does not distinguish two runs started with identical inputs: both can have the same epoch.

The controller therefore assigns each job a separate token. The left preview, right preview, comparison, and report have separate slots. A slot accepts only the token it currently owns.

The controller captures the token in the callback; it is not a field returned by the Worker. With an input containing the current epoch prepared, the comparison-start code registers the job in its slot:

const token = nextToken++;
const handle = runJob(input, event => onCompareEvent(token, event));
handles.compare = { token, handle };

The callback is expected to run asynchronously after slot registration. In this implementation, a Worker response triggers it; even Worker-construction failure is deferred with queueMicrotask. MDN's Worker.postMessage reference describes the message mechanism.

The response callback then checks its captured token against the current slot. These are excerpts, with input validation, cancellation of old jobs, and Worker creation omitted.

function onCompareEvent(token: number, event: JobEvent): void {
  if (disposed) return;
  if (handles.compare?.token !== token) return;
  handles.compare = null;
  setState(reduceState(state, { type: "event", event }));
}

The reducer still checks the epoch after the token check. The epoch identifies the input generation. The token identifies the particular operation the application currently accepts.

Reports need the same ownership rule because accepting a report can trigger a side effect. Starting another comparison cancels an in-flight report. An old report callback must not reach the function that initiates saving, even when the inputs and epoch have not changed.

Cancellation and acceptance have separate checks

The implementation terminates a Worker when its job is canceled. Worker.terminate stops the Worker immediately, without giving the running operation a chance to finish.

The controller separately specifies which callbacks it accepts. That rule can be tested without depending on a real Worker's termination behavior. This is not evidence that a browser delivers messages after Worker.terminate() has been called; the test uses a fake job deliberately capable of producing a canceled job's response.

Test the event order directly

The unit-test harness records cancellation but still lets a test emit a response afterward. This makes the order deterministic; it does not require a large CSV or a carefully chosen delay.

The stored tests cover these sequences:

Sequence supplied by the test	Required outcome
Start comparison A → change to B → emit A's response	No comparison or report reappears
Start a preview → reset → emit the old preview	Initial state remains free of that preview
Start a report → cancel → emit its response	No comparison or generated report remains
Start a report → rerun comparison with the same inputs → emit the old report	The save callback is not called despite the matching epoch

The cancel case checks result state; it does not directly monitor calls to the save callback. The last sequence exercises operation ownership within one epoch. The test checks that the array recording calls to the save callback stays empty after the old report responds.

Stored browser tests check the visible contract too: changing the file, encoding, key, mapping, or protected fields, and resetting, removes old output and the save button. A separate case verifies that changing only the case name keeps the completed comparison and puts the new name into the generated report.

These checks cover specific transitions. They do not prove every possible scheduling race or confirm that the browser finished writing a download to disk. For this article, I reviewed the implementation and existing logs; I did not rerun the tests.

Treat an input change as one operation that clears expired output, invalidates stored result data, stops obsolete work, and rejects obsolete responses. The comparison then stays attached to the inputs it actually describes.

AI assisted development, verification, and the organization and writing of this article. The claims above are grounded in implementation and test records; they do not imply customer adoption or commercial results.

A no-network test needs a request that makes it fail

Renga — Mon, 05 Oct 2026 15:24:20 +0000

A browser-local CSV comparison prototype developed and tested with AI assistance needed a test for network activity after file selection. Its saved records show that the first test failed because it counted local Blob worker loads as HTTP traffic. This article examines the implementation and those records to explain how an unwanted request can check the monitor itself.

The general rule of breaking a check to verify that it fails appears in an earlier article. Here the focus is specific to browser observation: a local Blob load that was counted as traffic, and a fetch attempt that CSP blocked.

A count of zero looks the same when the application is quiet and when the monitor misses everything. An intentional request provided a check on the monitor itself.

AI assisted the development, validation, and writing. This article is based on the implementation and saved validation records; the tests were not rerun for the article.

An HTTP origin inside a Blob URL is not an HTTP request

The prototype loads static assets at startup, then parses and compares CSV files in a Worker. The test treats startup asset loading separately from activity after file selection.

The observation log also contained local Worker loads using Blob URLs. Their text includes the creator's origin. Blob URLs represent resources in memory, so an HTTP origin appearing inside one does not establish a server request. MDN's Blob URL reference

The test counted the prototype's same-origin Blob loads separately. It kept HTTP, HTTPS, and unexpected URLs subject to the original checks. This excerpt shows the classification idea:

function classify(raw: string, appOrigin: string) {
  const url = new URL(raw);
  if (url.protocol === "blob:" && url.origin === appOrigin) {
    return "local-blob";
  }
  if (url.protocol === "http:" || url.protocol === "https:") {
    return "http";
  }
  return "unexpected";
}

Classification is only one part of observation. It does not establish privacy by itself.

A blocked call is still an attempt

Counting successful requests alone can miss an API call blocked by Content Security Policy. The connect-src directive controls connections made through interfaces such as fetch, XHR, and WebSocket. MDN's connect-src reference

The prototype's requirement was zero HTTP requests after CSV selection and zero observed network or storage API attempts. The test therefore combined request events with API-call observations and CSP violation events. Its request observations used Playwright's BrowserContext events. Playwright documentation

An intentional fetch made the test fail

A temporary fetch('/privacy-probe', ...) was inserted into the comparison path. It used a fixed synthetic string and the local test server. It did not use real CSV data or an external destination.

CSP blocked the call. The monitor still recorded fetch attempts and CSP violations, and the zero-attempt assertion failed. The test was capable of rejecting that blocked call.

After removing the temporary code and rebuilding production assets, the saved observation record contained:

Observation	Count
Initial HTTP asset requests	4
HTTP requests after CSV selection	0
Same-origin local Blob loads	8
Network or storage API attempts	0

The workflow covered file selection, comparison, report download, configuration changes, cancellation, reruns, and reset. The intentional failure and the normal build's success were recorded separately.

One mutation does not establish coverage of every path

The evidence establishes detection of the fetch inserted for this check. It does not establish detection of every API or a call made immediately after Worker initialization. Hook timing and observation coverage need their own checks as the monitored paths expand.

These are Chrome validation records using synthetic data. They do not establish the safety of browser extensions or the operating system, or secure erasure of browser memory.

For a no-network requirement, keep the evidence that made the monitor fail alongside its zero-count result.

"Zero matches" and "couldn't read the file" look identical

Renga — Wed, 02 Sep 2026 14:10:29 +0000

I wrote the checks before touching any of the 671 items I had to fix. So I wouldn't start fixing by feel.

Then I spent the rest of the project finding defects in my own checks. They all looked correct when I wrote them.

Write the check before the fix

Reverse the order and it fails.

Fix first and the check quietly loosens to match what you produced. Your own approach becomes the standard.

I froze the standard in code without touching a single item first.

Don't let the allowlist become an amnesty

Existing matches go into an allowlist. But both directions must be errors.

Direction	Meaning
A new match not in the allowlist	the standard has slipped
A line still in the allowlist after being fixed	you only think it's fixed

The second one is the load-bearing half. Without it the allowlist never shrinks. With it, the list decreases monotonically. Mine went 802 → 0.

There is no command to add entries. If you can add, you have a route to escape instead of fix.

When it empties, keep the empty file. Delete it and the next match starts with "create somewhere to put it." An empty file makes fix, not add the default.

The gate and the working view must be different tools

The check only reports matches outside the allowlist. It's a gate — pass or fail.

Which means the person doing the fixing cannot see what's in the allowlist. That needs a separate command that ignores the list and dumps contents.

You cannot see the defects in your own tooling

I handed it to five people and two defects in my check surfaced immediately.

The number it displayed and the number it judged on were different. Display was raw character count; the judgement excluded identifiers. Fix by reading the display and you miss.

It stripped punctuation before comparing. Strings that only joined up across a sentence boundary were flagged as copied, which pushed people to mangle perfectly natural prose. Replacing punctuation with a separator token means it only matches when the other side has a break in the same place.

Right after that fix, matches went 0 → 16. The separator was being counted toward match length. A separator is not content.

Carve exceptions at "there is no other way to say it"

Identifiers (NEXT_PUBLIC_, package.json) and raw data (log lines) cannot be paraphrased.

Exclude them from both the length calculation and the text comparison. Otherwise things that need no fixing get flagged, and the attempt to fix them makes the writing worse.

"Zero matches" and "couldn't read it" are indistinguishable

This is the dangerous one.

Zero items scanned also prints "zero matches."

I once misread a YAML key name, scanned nothing, and got a green check. Fail loudly when you cannot read the input.

Same reasoning: distrust the counting tool itself. My first aggregation used a regex, missed YAML block scalars, and every value was wrong. I nearly reported those numbers.

Watch it fail before you believe it watches

I wrote a guard and mutation testing passed twice in a row.

Searching by the shape of the call missed a second code path. Anything recorded more than one way slips past a shape match
Matching on name alone then matched the definition file itself. "Is defined" got read as "is used." Exclude the definition side

Both looked right when written. Until you break it and watch it fail, it is not guarding anything.

Reconcile what's written against what runs

Policies, terms, and help text drift the day you change the implementation. Nothing breaks. The page renders. Tests pass. You find out when someone tells you.

Just before adding analytics, my privacy policy said cookies were used only for keeping you signed in. It became a lie the moment I added it.

The guard has to fail if either side changes alone. Check "is the tracking code present" against "does the policy say so" in both directions. One direction misses either the stale text or the missing text.

Don't grep HTML and conclude it isn't rendering

Verifying production, I grepped for ¥[0-9,]+ and concluded the price wasn't showing.

React emits ¥ and the number as separate nodes, so the HTML reads ¥14,800 and never matches as one string. Zero-width spaces inserted by Japanese typesetting do the same thing.

Read the rendered string (innerText) instead.

Some defects only appear when it runs

A missing CSP allowance blocks exactly one request while the page works normally. Reading the code will never show you that.

That an analytics tag fires an image beacon at a different domain was not knowable until I put a real ID in and opened the page.

Takeaways

Write the check first. Reverse the order and the standard bends to the result
Both allowlist directions are errors. A list that never shrinks is an amnesty
Provide no way to add. Given an escape route, people escape
You cannot see the defects in your own tooling. Hand it to someone
Never trust "zero matches." Throw when the input can't be read
Watch it fail. Passing is not evidence of guarding
Reconcile docs and code in both directions. One direction misses half

Three independent proposals won't find the error. Adding a refuter killed one of them.

Renga — Tue, 01 Sep 2026 13:50:43 +0000

I used five AI agents to decide how to rewrite 671 quiz questions. Three perspectives, one refuter, one synthesizer.

The shape came out of a five-agent cap, but nothing in it turned out to be waste. Generating independent proposals is not enough. You need something whose job is to kill them.

The refuter killed one of the three

One proposal went down for this:

It never ran the verification it most strongly demanded, on its own headline number — it had confused the denominator with a subset.

Three proposals side by side did not surface that. I didn't catch it either, reading them myself.

The refuter's instructions were explicit:

Do not read this to agree with it
Find the place where you can say "this will fail in execution"
Suspect any number quoted without being run

The real win: the assumption all three shared

All three silently assumed that the metric they measured was the same thing as the problem that had been reported. Only the refuter went at that.

When I actually asked the operator, the answer was two different things entirely. Fixing only the headline metric would have missed the target.

Splitting the perspectives buys you independence of perspective. It does not buy you independence of assumption.

Don't let the synthesizer compromise

The synthesizer was told plainly: discard anything the refuter killed.

Allow compromise and a dead proposal comes back diluted. "Take the best of both" does not un-refute the reasoning that killed one of them.

Hand everyone the same measured data, up front

Let each agent do its own aggregation and they recount the same thing repeatedly and disagree on the results. I dumped the analysis to a file first and had all of them read it.

On top of that: write only numbers you produced by running something. No estimates.

One agent still got its own recount wrong. Because the report was fully reproducible, the refuter could determine that the agent was the thing that was off. Shared measured data decides who is wrong, not just that something is.

It also found errors in what I supplied

The refuter flagged two errors in the measured data I had handed them. Both were real.

Instruct it to suspect the premises it was given, and it catches your mistakes too.

Make "what to ask" a required output field

I required the synthesizer to emit open_question — things the operator should decide.

What came back: ask the operator which items they actually found confusing; ten minutes settles the direction. That pays for itself before you gamble 4 to 70 hours.

All three proposals started from one remark by the operator, and not one of them proposed going back and asking. It doesn't appear unless you require the field.

I hand-copied the work split and got a quarter of it wrong

This one is mine.

Distributing 116 sites across five agents, I hand-copied the script's assignment output into JSON. I got 28 of them — a quarter — wrong. Names that didn't exist went out; 28 real ones never did.

I caught it by diffing against the real data right after launch, before a single edit landed.

Three fixes:

Diff what you handed out against what generated it, as the first step after launch
Verify names down to file existence before handing them over (added an assert)
Remove the transcription step entirely. The script now emits a string you paste as-is

The cause wasn't carelessness. It was that a copying step existed at all.

Fix the standard in a document before distributing

Before handing out 390 rewrites, I did 76 myself and wrote the pattern into a document — good examples, bad examples, and what must not be touched.

The thing that breaks first when you split work is consistency of standard. One dialect per agent is worse than no standard at all.

Machine checks are the gate; the writing standard travels as prose. I also stated: do not loosen the check to pass. If it feels too strict, report it — don't edit it. Never leave the gate adjustable from the inside.

If everyone falls in the same hole, it's your handoff

Six agents, one video cut each: every one of them hit "the font file isn't here," and solved it four different ways — bare font names, embedding a font from another project, fetching from the network.

I only found out because each report was required to include "where the instructions and reality diverged."

When all of them raise the same point, it isn't the agents. It's a gap in what you handed them.

The next round, I folded the previous four failures into the instructions. None of the four recurred. But sealing holes reveals the next ones — three agents independently fell into a different one.

Requiring those reports is how you learn what to hand over next time.

Takeaways

Proposals alone don't find errors. Stand up an independent refuter
Separate perspectives still share assumptions. Only the refuter attacks those
Don't let the synthesizer compromise. Killed proposals return diluted
Distribute the same measured data first. It decides who is wrong
Tell it to suspect your premises. It will catch your errors
Require an "open questions" field. It doesn't appear otherwise
Never build a step that requires transcription. I got a quarter wrong
Everyone in the same hole means the handoff is missing something

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.

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.

DEV Community: Renga

A finished revision can still leave a stale review copy

A filename and a URL do not identify the revision

Separate the original, the intended snapshot, and the readback

Check history and sharing separately from content

Text identity is not factual review or publication approval

An unknown note category should stop the write

A new default would keep the same ambiguity

Keep the tool contract and the writer in agreement

Test refusal as well as successful appends

Applied source is a different result from working software

A generated video still needs a receipt and a stopped runtime

Inspect the existing job before submitting another

A matching hash answers a different question from a valid video

A stopped engine does not establish runtime release

Keep completion states small enough to prove

A CSV comparison result expires when its inputs change

Write the expiration rules first

An input epoch and a job token answer different questions

Cancellation and acceptance have separate checks

Test the event order directly

A no-network test needs a request that makes it fail

An HTTP origin inside a Blob URL is not an HTTP request

A blocked call is still an attempt

An intentional fetch made the test fail

One mutation does not establish coverage of every path

"Zero matches" and "couldn't read the file" look identical

Write the check before the fix

Don't let the allowlist become an amnesty

The gate and the working view must be different tools

You cannot see the defects in your own tooling

Carve exceptions at "there is no other way to say it"

"Zero matches" and "couldn't read it" are indistinguishable

Watch it fail before you believe it watches

Reconcile what's written against what runs

Don't grep HTML and conclude it isn't rendering

Some defects only appear when it runs

Takeaways

Three independent proposals won't find the error. Adding a refuter killed one of them.

The refuter killed one of the three

The real win: the assumption all three shared

Don't let the synthesizer compromise

Hand everyone the same measured data, up front

It also found errors in what I supplied

Make "what to ask" a required output field

I hand-copied the work split and got a quarter of it wrong

Fix the standard in a document before distributing

If everyone falls in the same hole, it's your handoff

Takeaways

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

`ViewThatFits` is not a general answer