DEV Community: Sungsoo Youn

My Dashboard Said the ISBN Had Been Pending for 29 Days. The Clock Had Not Started.

Sungsoo Youn — Fri, 16 Oct 2026 04:10:07 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

The Korean edition of my book sells on a Korean e-book platform. To reach the big bookstores through that platform, the book needs an ISBN, and the platform files the ISBN request for you.

My agent submitted the book for sale on August 31, and I requested the ISBN on September 4. Every evening its summary for me carried one line about it: ISBN pending, day N. On October 3 that line said 29 days.

Why a long number is a bad number

A wait that grows by one every day stops meaning anything. Nobody acts on day 29 differently from day 28. Worse, if something really did get stuck, the line would look exactly the same. A counter that always rises can't tell you when to act.

So instead of guessing whether 29 days was normal, the agent went looking for the rule.

The rule was public

The platform has a public help board. On September 30 an operator answered a seller's question on that board. The answer, in short: the ISBN request can go ahead only after the book is approved for sale.

My book had been waiting for sale approval the whole time. The agent had resubmitted it on October 1, and on October 2 the agent read the status back as on sale. So the ISBN request had most likely not gone out at all before October 2. The real wait was one day, not 29.

There was one more thing in the old notes. On October 1, while fixing the author name on the listing, the agent had written in a code comment that it would also email the platform a question. A search of the agent's own code and logs showed that email was never sent. The plan existed only as a sentence.

What changed

When the platform first shows the book as on sale, the agent records that date. It does not move if the book stays on sale, and it is not touched on days the status could not be read.
The summary line now counts from that date: on sale for N days, ISBN pending.
If the ISBN is still missing more than 10 days after the sale approval, the line adds a bell: time to ask the platform.
When an ISBN number appears, the line switches to the next job: request bookstore distribution. That bell stays until the request is recorded.

The line that said 29 days now says 1 day.

The rules

Before counting a wait, find out what starts the other side's work. Count from that event, not from the day you asked.
A counter needs a threshold. Without one, it rises forever and nobody acts on it.
A plan written in a log is not an action. Search for the evidence that it happened before you rely on it.

Where this comes from. Every post here comes from one setup I run daily: a CLAUDE.md, memory files the agent reads before it touches anything, and a separate auditor agent that returns PASS or FAIL. The first 3 chapters of the book that walks through it are free as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

The full edition is 11 chapters plus 4 ready-to-use templates (CLAUDE.md starter, memory files, auditor checklist, measurement guide) and a hands-on section for every chapter, $19 as a PDF: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My Link Card Was Clicked. The Posts Carrying It Got Less Than Half the Views.

Sungsoo Youn — Thu, 15 Oct 2026 04:10:07 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent posts three times a day on Threads. One of the daily posts is a short insight post with a link to a free edition of my book. Earlier versions put that link in a reply, on six insight posts between September 19 and 25. The click ledger goes back to August 20; in those 37 days before September 26 it shows 0 clicks on that link. A later version put the link in the post body, where Threads shows it as a link card.

The verdict

The first card window ran for five days, September 26 to 30. Its judge had two rulers:

Clicks. At least 2 clicks on the free-edition link in five days counts as clicked.
Reach. The average views of the card posts divided by the average views of the other posts from the same days. Below 0.5 counts as a reach drop.

The result: 2 clicks, one on September 26 and one on September 27. The reach ratio was 0.46 (51.6 against 111.1).

Both rules fired. But the judge checked clicks first and stopped there, so the verdict was that the card was clicked. The reach drop was printed in the reason line, and no rule acted on it.

The card was then extended until October 18, and a new judge was written for a two-week window (October 2 to 15). That judge measured clicks and downloads of the free edition. It did not measure views at all.

Reading the ledger again

The averages had a problem of their own. One of the ten other posts had 396 views, more than the next two combined, and it pulls the average. So the agent compared medians, and also looked at the same days before the card existed:

	Insight posts	Other posts
Before the card (Sep 19–25), link in a reply	median 95 (6 posts)	median 35 (15 posts)
With the card (Sep 26–30)	median 29 (5 posts)	median 81 (10 posts)

Before the card, the insight posts got about 2.7 times the views of the other posts. With the card, they got about a third.

These are small samples, and the view counts are each post's latest snapshot, not views at a fixed age. It is not proof that the card caused the drop. But it points the same way as the 0.46 the old judge had already printed.

Meanwhile the click ledger shows 0 clicks on September 28, 29 and 30 and October 1. The sales ledger shows 0 downloads of the free edition through October 2.

What changed

The two-week judge now carries a reach ruler: the median views of card posts divided by the median views of the other posts in the same window. If the card is clicked (3 or more) but nobody downloads the free edition and the ratio is below 0.5, the verdict is that the card is clicked but reach dropped, and the next step is to take the card down. A download still wins over everything else, with the reach cost shown in the reason.

The card itself was not changed. The window is still running.

The rules

When a judge has two rulers, the order of the checks is a decision. Write down why one wins, or the other one goes quiet.
An extension is a new experiment. Carry every ruler from the old one with it, especially the one that measures the cost.
With a handful of posts, use medians. One popular post can move an average more than the thing you are testing.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

Twelve of My Fifteen Products Had Exactly 7 Visits. The 7 Was My Own Check.

Sungsoo Youn — Wed, 14 Oct 2026 04:10:03 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent sells fifteen small products on a Korean digital storefront. One of its goals is a traffic number: the sum of the total-visits figure that the storefront dashboard shows for each product. The target is 240.

This note is about what that number is made of.

First: it was a window, not a day

On September 17 the goal ledger said 1,219. The dashboard said 177.

The agent had been treating the dashboard figure as one day of visits and adding up seven days of it. But the figure is a rolling window. The values went up and down from day to day (one product read 29, then 22, then 12), and the buttons for choosing a period were disabled (they are a paid-plan feature). Adding seven snapshots of a window counted the same visit up to seven times.

The fix was to read only the latest snapshot. The ledger has done that since.

Second: the floor was the agent

Four days later the agent looked at each product instead of the total. Over twelve measured days, twelve of the products never moved much: their daily minimums were 4 to 9 and their maximums 9 to 11. Only three products ever went higher.

A flat line across a dozen items is worth explaining before it is read as a little traffic. So the agent searched its own code for scheduled jobs that open the products' public pages, and found a daily check at 08:30 that opens every product page once and confirms the buy button is there.

A floor of 7 is what one check a day looks like if the window is seven days long. The storefront does not say how long the window is; the floor is consistent with seven.

The search was not complete

That search looked at the scheduled jobs whose purpose was to check pages. When this note was audited, the auditor traced every call in the code that opens a public product page instead. It found more:

Jobs at 09:45, 18:40 and 19:00 open the main paid guide's public page to read its price.
Jobs at 09:45 and 18:40 open the full-collection bundle's public page.

They do this in a browser that is logged in as the seller. Whether the storefront counts a logged-in seller as a visitor has never been measured.

The latest row

The October 1 row in the traffic ledger:

Total: 135
Twelve products: exactly 7 each
The full-collection bundle: 22. The main paid guide: 20. The free edition: 9.

Fifteen products times 7 is 105. So at most about 30 of the 135 visits in the window came from anyone other than the 08:30 check. For the twelve products sitting at exactly 7, it is close to zero. For the bundle and the main guide, part of what sits above 7 may be the other jobs. The ledger cannot split the two.

The goal of 240 includes the 105 floor. To reach it, visits from anyone other than the 08:30 check would have to go from at most about 30 to about 135 per window: at least four and a half times what they are now.

The rules

Know whether a dashboard number is a count or a window before you add it up. Watch it for a few days: a window goes down as well as up.
Subtract your own monitoring. Any health check that loads a public page is a visitor to some counters.
Find every place your code opens the page, not only the jobs built to check pages. A price lookup is a page visit too.
A flat line across many items at the same value can be a probe. Find the probe before you read the line as demand.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My Mutation Check Stopped Because a Scheduled Task Wrote a Ledger

Sungsoo Youn — Tue, 13 Oct 2026 04:10:06 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent checks its tests with mutation testing. It changes one line of the real code, runs the tests, and expects at least one test to fail. A mutant that no test catches means a test is missing.

The mutants run in a copy of the repository, not in the real one. There is one more guard. Before and after each mutant, the check records the modification time and size of the files in the real data folder, where the ledgers live. If anything there changed, it stops and prints which files changed. A mutant should never reach real data, so a change there is treated as a possible leak.

The stop

The agent had registered eight mutants for a new judge function and the lines that connect it to the command that prints every experiment's verdict. On the first run, one mutant was caught. Then the check stopped: the real data folder had changed.

The two changed files were Threads ledgers: one written at 10:40:20 and one at 10:41:11.

Leak or not?

Before treating it as a leak, the agent looked at the clock. The machine runs a scheduled task that collects Threads data four times a day: 10:40, 13:40, 16:40 and 21:10. Its last run time was 10:40:01. The two files were written 19 and 70 seconds after that.

The agent also confirmed that the source folders showed the same uncommitted changes as at the start, and nothing new.

So the writes came from the scheduled task. The mutant had not leaked. The guard did what it was built for: it saw a change it could not explain and refused to continue. Working out the reason was a separate step.

The next scheduled run was at 13:40. The agent ran the remaining seven mutants before then. All seven were caught, with none surviving. Together with the first run, that makes eight of eight.

The same stop, a session earlier

This was the second time in two sessions. In the session before, the check stopped for a reason the agent had caused itself. It had started a real data collection run at the same time as the mutation check, and the collection updated the ledgers.

Both stops were correct. In both cases the cause was something else writing to the real ledgers while the check was running.

The rules

A guard that stops is asking a question. Answer it with evidence, such as file times and task run times. Don't guess, and don't turn the guard off.
Know what else writes to your data, and when. Scheduled tasks are part of the environment your checks run in.
Don't run collectors and checks that watch the same data at the same time. Run the check in the gap between scheduled writes.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

The Same Number for Seven Days: Broken Meter or No Visitors?

Sungsoo Youn — Mon, 12 Oct 2026 04:10:07 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My book is also sold on a Korean store, split into 12 listings: the full bundle and single parts. My agent records each listing's view count every evening.

For seven days in a row, the full bundle's count was 17, and the total across all 12 listings was 42. It had been 42 since the first time the agent measured it.

During that week, a new link to the full bundle had been added to the profile of my YouTube channel. If that link worked, the count should have moved. It did not.

A number that does not move has two explanations. Nobody came, or the meter is broken. They need opposite responses. If the meter is broken, fix the measurement. If nobody came, the measurement is fine, and the problem is getting people there. So before deciding anything, the agent tested the meter.

Test 1: a plain request

The agent fetched a single listing's page with a plain HTTP request. The response was a 21 KB empty shell, and the view count stayed at 3.

That did not answer the question. On this store, the page itself may count the view after its script runs in a browser, and a plain request never runs the script. A meter that ignores plain requests could still be working.

Test 2: a real browser visit

So the agent opened the same listing in a fresh headless Chromium, with no login, the way a stranger would arrive. While loading, the page sent a request to the store's view-counting endpoint.

The listing's count in the seller list went from 3 to 4, and the total went from 42 to 43. Both changed within 20 seconds.

The meter works and updates in real time. So the seven flat days meant something plain: nobody visited any of those 12 listings that week.

The leftovers

That +1 is the agent's own visit. It is now written in the handoff notes: when you read that listing's count, subtract one. It was a different listing from the full bundle, so the profile link's measurement is not affected.

The test also showed a gap. The profile link had no judge. Its success condition had been written as a sentence in an earlier work log, and no code checked it. The agent turned it into code: a function that compares the full bundle's count at the end of the window with the last reading taken before the link was added, and counts the link as clicked only if the count rose by at least 2 and faster than before the link. If a needed day is missing, the judge reports that it can't judge, instead of reporting zero.

The rules

A number that doesn't change is a question, not an answer. Check the meter before you explain the result.
Test the meter the way the real visitor arrives. A plain request didn't move the count. A real browser visit did.
If your test touches the meter, write down how much. Otherwise your own visit becomes a customer.
A success condition written only in prose will not be checked. Put it in code that gives a verdict.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My Free Sample Said 11 Chapters on the Cover and 15 at the End

Sungsoo Youn — Sun, 11 Oct 2026 04:10:07 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My book has a free English sample: the first three chapters as a PDF. My agent rebuilt it to fix two problems, and the independent auditor found a third problem that the fix had left behind.

The first fix: the cover

The line under the sample's cover title said "3 chapters + 0 ready-to-use templates". The full book has 4 templates. The cover code counted only the manuscript files that are inside the sample, and the sample has no templates, so the count was 0.

The agent changed the line to "Free sample · chapters 1–3 of 11". The 11 comes from the function that counts the book's chapters, not from the files in the sample. A test checks the sample cover, and another test checks that the full book's cover did not change.

What the fix missed

The last page of the same PDF tells the reader what the rest of the book contains. It said "This sample is the first 3 chapters of 15."

That 15 came from a different count: the number of manuscript files in the full book. That is 11 chapters plus 4 template files. So after the fix, one PDF gave two different totals: 11 on the cover and 15 at the end.

The agent had fixed one line that stated the chapter count. It did not search the same file for the other lines that state it. The test it added also looked only at the cover.

The auditor caught the two totals and failed the work.

The second fix

The last page now uses the same chapter-count function as the cover.

The new test takes the whole sample, pulls out every "of N" chapter total with a regular expression, and requires that set to be exactly one number: the chapter count. Before the fix, the test failed with {11, 15} == {11}. That is the bug in one line: two totals where there should be one.

The test also checks a precondition: the chapter count and the file count must be different. If they were ever equal, the test could not tell the two counts apart, and it says so.

The rebuilt sample has 13 pages, and "of 11" appears in two places.

The rules

When you fix a number in an output, find every place in that output that states the same number. Fixing one is half the fix.
Test the whole output as a set. "All chapter totals in this file are the same number" catches the line you forgot. "The cover says 11" does not.
Know which count you are using. Chapters and manuscript files are both reasonable things to count. They are not the same number.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My Agent's Fake Ledger Was Thinner Than the Real One, So a Wrong Count Passed

Sungsoo Youn — Sat, 10 Oct 2026 04:10:06 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent judges its own experiments from ledgers. One judge counts "applied days": days on which a post actually went out with a link card attached. If no post carried the card, the judge must say "can't judge" instead of giving a verdict.

The posting code writes two fields. comment_kind marks a post where a card was tried. The daily limit counts this field. link_card is written only when the card was actually attached. If the card was refused and the post went out without it, there is no link_card. So the correct count uses link_card.

The mutant that survived

To check its tests, the agent runs mutation testing: it changes one line of the real code, runs the tests, and expects at least one to fail. One registered mutant changed the count to use comment_kind instead of link_card.

It survived: none of the tests run against it failed.

The test had the right idea. It had one refused attempt and one real card, and expected 1 applied day. But the fake real card had only link_card. Counting by comment_kind gave 1 (the refused one), and counting by link_card gave 1 (the real one). Different counts, same answer.

What the real ledger looks like

The agent read the real posting ledger. All six posts that actually carried a card had both fields, comment_kind and link_card. With that shape in the test, counting by comment_kind gives 2 and the right count gives 1. The mutant was caught.

The fake ledger had only the fields the author was thinking about. The real ledger had one more, and that field was the difference between the right count and the wrong one.

Where this happened

The agent found this while finishing the work of a session that had been cut off. That session wrote the judge and the tests and was stopped by the runner's time limit before the mutation run finished and before anything was committed. It also left a lock file saying the mutation check was "running". The agent deleted it only after confirming that no mutation or test process was alive.

The rules

Build fake data from one real record. Read a real row first and keep all its fields. A thinner fake can make different calculations agree.
A test of "count A, not B" needs a case where A and B give different answers. If both give the same number, the test can't tell them apart.
A stale lock is a claim. Check it before you delete it.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

The Link at the End of My Free Sample Couldn't Be Tapped. Replacing the File Was the Hard Part.

Sungsoo Youn — Fri, 09 Oct 2026 04:10:07 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My book has a free sample PDF. It ends by saying where to read the rest and gives the address of the full bundle. That line is the whole point of a free sample.

My agent counted the link annotations in that PDF. There were zero. The address was printed as plain text. On a phone, a reader would have had to copy it by hand.

Why it was text

The PDF is built from Markdown, and the line ended with a bare URL. Python-Markdown does not turn a bare URL into a link. Wrapping it in angle brackets (<https://...>) makes it an autolink. The rebuilt sample had exactly the same body text as the old one, 6,667 characters, and link annotations went from 0 to 1.

Replacing it on the first store

The first store has an option to replace a product's files. The agent replaced the file, then downloaded it back and compared the bytes. They matched.

The independent auditor still rejected it. The change was in which file spec the replace function uses, and the test covered only the new helper that picks the spec. The call line inside the replace function was not tested. With the old call put back, the error was caught by an except and the function quietly returned False. Every test still passed. A test that goes through that call line, with a fake browser and a fake ledger, now fails if it is reverted.

Replacing it on the second store

The second store, a Korean one, had a harder problem. The existing update tool rewrites the title, the price and the description along with the file. That is too much to change just to swap a file.

And the store's edit screen shows only the file's name. No size, no address. If the agent uploaded a file with the same name, reading the screen back could not tell whether anything had changed.

So the agent built a separate path that touches only the file field:

Check the file first: it exists, it is a PDF, it has text, and it contains no banned material.
Upload a copy whose name ends with the date.
Go through confirm, next, next, save. If any step fails, don't save.
Open the edit screen again. Count it as a success only if the new name is shown.

The real run reported success after the read-back. The public page still had the same title and the same free-download button.

There is one limit, and it is written in the handoff notes: two uploads on the same day get the same name, and the read-back can't tell them apart.

The auditor found one more gap. The runner passes a product ID to the replace function, and the test called it only with the free sample's ID. Hardcoding that ID would still pass, and replacing a different product would then change the free sample. A second test now passes a different product's ID.

The rules

Count what the reader can do, not what the file contains. The address was in the PDF. It just couldn't be tapped.
If a screen can't show a change, make the change visible. A dated file name turns "did it upload?" into a question the screen can answer.
Test the line that calls the new code, not only the new code. An except that swallows errors will hide a revert.
Pass an unusual value in tests. If the only value tested is the common one, a hardcoded value passes too.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My Agent's Winning Experiment Was Set to Switch Itself Off. Twice.

Sungsoo Youn — Thu, 08 Oct 2026 04:10:08 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent runs small experiments on where buyers come from. One of them added a link to the free sample of my book under some of its Threads posts. To keep an old experiment from running quietly forever, the experiment file has an end date. After that date the link stops being added. That part worked exactly as designed.

The first time

The end date was September 22. The judgement was scheduled for the evening of the same day. Then the agent's loop paused for a usage limit from the afternoon of the 22nd until the 24th, so the judgement ran two days late.

The verdict was "the door is being clicked". But the door had been switched off since the 23rd. For two days the experiment that looked like a win was closed, and nothing reported it. The off switch was automatic. "If it wins, keep it open" was left to the next session's memory.

The fix: the end date now sits at least three days after the end of the judgement window, and a test locks that gap. A judgement that runs a couple of days late, as this one did, no longer closes a winning door first.

There was a twist. Later the agent measured clicks on the comment link itself, and over the five days around the window they were zero. The views had come from somewhere else. The same address is also on the account's profile. The first verdict was wrong too, and the judge now reports that case as "views from outside the comment".

The second time

A later version put the link in the post body as a link card instead of a comment. On October 1 it was judged "clicked": 2 clicks in 5 days, against a threshold of 2. The experiment file said October 3. The three-day gap was there.

But the prescription after that win was not "done". It was: keep the card and see whether people actually take the free copy. That needs two more weeks, and the door would have closed on the fourth.

The rule the agent had written after the first time protected the judgement. It did not protect what comes after a win. The agent extended the end date to October 18 without changing the card, and wrote the next judge before the window opened: a 14-day window that measures whether clicks repeat (at least 3) and whether the free copy is actually received.

The ledger shows why repetition is the first question. Both clicks came on September 26 and 27. The four days after that had none. "Clicked" was a verdict right at the threshold.

The rules

An automatic off switch needs an automatic "keep going" too. Otherwise the safe default quietly ends your best result.
Put the end date after the next step, not only after the judgement. A win can ask for a longer window, not a finished one.
Check the door, not the verdict. The agent's mistake log now says: at the start of a cycle, run the judge, then check that every "clicked" door is actually on today.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My New Link Would Show on 5 Days Out of 14. Then I Found the Reader Never Looked.

Sungsoo Youn — Wed, 07 Oct 2026 04:10:06 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent prepares a daily "card" for a blog that another system I run publishes: a story, a footnote, a link. For an experiment it added one new field to the card, a "door" line pointing at the single-chapter edition that matches the day's story. None of those editions had a link pointing at them anywhere in my systems.

The field was ready days early. Before switching it on, the agent asked a question I now ask of every feature: on how many days will this actually fire?

Count it by simulation, not by intent

The door line only appears when the day's story is one of 18 stories linked to a chapter. So the agent replayed card selection against the real queue, including the other system's rule that skips any story it covered in the last 30 days.

Result: the door would appear on 5 days out of the first 14, scattered. Stories were picked in a date-based rotation, so a linked story came up only by chance.

The fix was small: during the experiment window, pick linked stories first. That gave 6 days in a row. It can't go higher, because 12 of the 18 linked stories are blocked by the other system's 30-day rule, and that rule belongs to the other system.

Measure what readers saw, not what the card said

A card with a door line is not a blog post with a door line. The publishing system might drop the field, or the post might fail. And the publish log doesn't record the footnote's contents.

So before the window opened, the agent built the ruler: every evening it reads the day's blog post once and records whether the door URL is visible on the page. Only days where it was seen count as "applied". A page that couldn't be read is recorded as unknown, never as "no door". On a real post from before the window it correctly reported "read, no door".

The reader

When the field was built, the agent had already seen that the other system's publishing code didn't read it yet, and left a handoff note asking it to. The day before the window opened, it searched that code for the field name again. Still zero places. The handoff note was still marked open.

All the simulation, the ordering fix and the ruler were correct. As things stood, the field would never reach a reader, because the code that turns cards into posts didn't know it existed.

The agent doesn't edit the other system's code; that system decides for itself. It re-sent the request with a deadline: before the next day's publishing run. If the field isn't read, the ruler will report "0 days applied, can't judge" instead of a false result. An honest "can't judge" is still better than a confident wrong answer.

The rules

Before switching a feature on, simulate how often it fires on real data. "It's wired in" says nothing about frequency.
Measure at the reader's end. What you sent is not what was shown.
Check the consumer again right before the switch, not only when you hand it off. A handoff note is a request, not a change. One search for the field name in the reading code tells you which one you have.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

"Zero Other Places" Was Just a grep. The URL Was Assembled at Runtime.

Sungsoo Youn — Mon, 05 Oct 2026 04:10:06 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent runs small experiments on where buyers come from. The rule is one change at a time, so before adding a link anywhere, it checks which other channels already carry the same link. Otherwise a rise can't be traced to the new spot.

This time the new spot was the profile link on a YouTube channel, pointing at the bundle edition of my book on a Korean creator store. The agent searched the codebase for the product's ID, found nothing outside the new code, and wrote in the experiment log: no other channel carries this URL.

The independent auditor rejected it.

Where the URL actually was

Two channels were already carrying that exact link, both since before the experiment's baseline week.

The first was inside the store itself. Each of the eleven single-chapter editions ends with a note recommending the bundle, added by a script since early September. That script never contains the full URL. It holds a template:

ITEM_URL = "https://ctee.kr/item/store/{item_id}"

and the bundle's ID is filled in when the note is built. A search for the finished URL, or for the ID typed into code, can't see that.

The second was in another system I run: the footnotes on its short videos, which carry the same bundle link.

Neither one was hidden. One was assembled at runtime and the other lived in another system's data, and a text search over my code sees neither. The experiment kept both channels; they are now counted in its baseline instead of being missed.

The test that tested the wrong thing

The same review found a second gap. The new tool reads the channel's links back from the screen, and an empty field reads as an invisible placeholder character (U+FFFC), so a small cleaning function removes it. Its test put that character only in front of the URL. But a later normalising step already cuts everything before the //, so that character was removed anyway. The cleaning function could be deleted and the test still passed.

Moving the character to the middle and the end of the URL, where nothing else removes it, made the test fail without the cleaner.

The checklist now

Before writing "nowhere else" about a link, the agent counts five ways:

the finished string,
the ID alone,
the functions that assemble it (templates, format calls),
the data ledgers outside the code (saved descriptions, card queues),
the queues and outputs of the other systems that publish for me.

The rules

"Zero" is a claim about everything, so search everything. Code that builds strings at runtime is invisible to a search for the built string.
A test input has to land where no other code will fix it for you. If a different function already removes the problem, your test is measuring that function.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.

My EPUB Passed My Own Checks. The Store's Validator Found 17 Errors.

Sungsoo Youn — Sun, 04 Oct 2026 04:10:08 +0000

A field note from the autonomous Claude Code agent I run every day on one Windows PC. The numbers come from its own ledgers, not from memory.

Free to read first: a PDF sample of the book behind this setup — its first 3 chapters: https://dbsoul.gumroad.com/l/autonomous-ai-agents-claude-code-free-sample

My agent builds the ebook file for a Korean ebook distributor. For a month its verify step printed that the file was in a format the store would accept. When the store's upload check ran on a resubmission, it rejected the file with 17 errors.

What "verified" meant

The verify step checked what I had thought to check: the file is a valid zip, each XHTML page parses, the copyright page contains the right text. All true.

What it never did was run the checker the store actually uses, the W3C validator epubcheck. A month earlier only the package file had been converted to EPUB 2. The pages inside were still shaped like EPUB 3: an epub: namespace prefix, no DOCTYPE, a bare cover image. And the cover was a PNG stored under the name cover.jpg.

Our checks passed because our checks had no opinion on any of that.

The failure nobody read

The resubmission tool had a second problem. After uploading the file, it decided the upload had worked by watching a hidden form field change value. The page also showed an alert: "File upload failed". The tool didn't read alerts. It moved on and clicked the next button.

A failed upload was counted as a success, and the next step ran on top of it.

The date nobody touched

Once the file passed and the resubmission went through, the agent re-read the listing. The price and the author were right. The registered publication date was not: pressing the final "submit for sale" button had quietly reset it to the date of the very first submission, weeks earlier. The copyright page inside the book says a different date, and the store's notice asks for the two to match.

The tool had checked the fields it changed. It never re-read the field it didn't touch.

What changed

The verify step now runs epubcheck 5.1.0 itself. Any error is a problem, and the resubmission tool won't open the browser until the count is zero.
The conversion now rewrites the pages too (XHTML 1.1 with a DOCTYPE, no epub: attributes, the cover image wrapped in a block), and the cover is converted to a real JPEG, not just renamed.
After uploading, the tool reads the alert text. If it says the upload failed, it stops.
After submitting, the tool re-reads the publication date and the listed price. If the date has moved, it saves it back and reads it again. (Author and publisher are checked before the button is pressed.)

The rules

"Verified" means verified by the receiver's checker. Your own checks measure what you thought of. The store measures what it requires. If the receiver publishes its validator, run that one before you upload.
Read what the other side tells you. A changed field value is your guess about success. An alert on the page is their answer.
After pressing a button in someone else's system, re-read the fields you didn't touch. That system has its own rules about what a button changes.

Questions about the setup are welcome in the comments — I'll answer with what actually happened, not theory.