For three mornings in a row, my audit log printed the same line: .
Nothing crashed.
The scripts ran, exited, and produced nothing.
The entire cause turned out to be a 41-second margin — a 300-second timeout against a process that actually takes 259 seconds.
Changing one number to 600 turned 0/3 into 3/3 the next morning.
Some background: I went from earning 100k yen a month as a university student to 600k a month juggling multiple gigs, then lost all of it overnight to a company-initiated layoff.
Over the following six months I built an autonomous Claude Code environment, and I'm now above 1.2M yen in monthly revenue.
At the core of it is a system that publishes three affiliate articles every morning without a human touching anything.
Why this system works The difference between people who keep earning from affiliate marketing and people who drop out is not writing skill, and not a nose for picking products.
It's whether you can keep going.
Articles that tend to earn on Rakuten Affiliate share a common pattern: spec-comparison articles about home appliances and gadgets priced above 50,000 yen, with lots of reviews and in stock.
Robot vacuums, portable power stations, heat-pump washer-dryers, fully automatic coffee makers.
The search intent is "I want to compare before I buy," so product link click-through is high and it fits the structure of affiliate marketing well.
The problem is cost.
Researching the specs of a high-ticket appliance on the web, building a comparison table, and finishing an article good enough to include the "honestly weak points" section takes 30 to 40 minutes.
Three articles is close to two hours.
Almost nobody has the willpower to repeat that 365 days a year.
I don't either.
What you need here isn't "trying harder" — it's an environment that keeps running even when you don't try hard.
Once the system is built, the running cost is just API calls.
The I built is a simple structure made of four shell scripts. macOS (the successor to cron) fires three times a day — morning, midday, and night — and three affiliate articles get published to Hatena Blog every day without any human involvement.
There's one more design-level core idea: idempotency.
A naive script doesn't care how many articles have already been published today.
If the morning batch fails, the day ends at zero.
This system first counts "how many were successfully published today" and "how many drafts are left on the Desktop," and generates only the number still missing against the target of three.
Even if the morning batch is wiped out by API limits, the midday batch calculates "we still need 3 today" and refills.
The evening batch fills the last one.
No matter how many times it runs, the day's publish count converges to three.
Once you understand this design, the roles of the four scripts look completely different.
I assume many readers are in the situation of "having to write an article every day is exhausting." I was too.
But to be precise, what's exhausting is "making the decision to write an article every day." When the system takes over the decision, the human just looks at the published articles.
The overall flow Here's the structure of the whole system as an ASCII diagram. daily.sh — the idempotent controller The role of is simple.
Calculate what's left for today, call only as many times as needed, then run publishing and auditing in order.
That's it. counts the files under carrying today's prefix. is the number of drafts still sitting directly on the Desktop. is the difference, clamped to 0 if it goes negative.
The important part is that processing doesn't stop when one run fails. swallows the error and a later batch refills the remainder. is declared at the top, while individual generation failures are absorbed inside the loop.
The design keeps the whole flow alive without losing track of what happened. generate.sh — mass-producing articles with claude -p is the heart of this system.
Using WebSearch, it picks a high-ticket appliance that