Approval Files Make Cron Writers Safer

I trust scheduled writing systems more when they leave one obvious approval file behind before anything gets published. That file is where the writer commits to the account, title, tags, keywords, and link choices. Once it exists, the executor should stop being clever and just do the job. It sounds almost too simple, but this small boundary fixes a lot of messy automation behavior.

I started using this pattern after watching a few cron jobs fail in annoyingly human ways. They did not always crash. Sometimes they picked a decent draft, then drifted during publish because one later step "helpfully" rewrote metadata. Other times the job re-planned on retry, which made the failure impossible to compare. That kind of system looks smart in a demo, but it is hard to trust at 2 a.m. when you are triaging what went wrong.

Why cron writers need an approval file

For Automation and Developer Tools work, the dangerous bug is often not a syntax error. It is a quiet mismatch between planning and execution:

• the planner selects one account and the publisher uses another
• the title passes review, then changes before publish
• the links look fine in preview, then get swapped on retry
• the notification fires before the post is actualy live

An approval file gives the run a stable center. If a job fails, I can compare the approved plan with the final result instead of guessing from terminal scrollback. That one comparison saves a weird amount of time, and it makes reviews calmer too.

I like this approach because it scales down as well as up. You do not need a big orchestration stack. A cron job with one plan file, one content file, and one result file is already much safer than a monolithic script that keeps making decisions all the way to the end.

What goes in the run directory

My default run directory is boring on purpose:

• plan.json for the approved choices
• article.raw.md for the exact body to publish
• publish-result.json for the final URL or the error

That set is enough to answer most postmortem questions in a few minutes. Was the right account selected? Did the article mutate after planning? Did publish fail before or after the browser action? You can see the whole chain without digging through a pile of logs from different steps.

I also put the run id into notifications, artifact names, and any browser session label. When you do that, it becomes much easier to line up related evidence later. The same idea shows up in run tokens for isolated email checks: give each run a visible identity so retries and overlapping jobs do not blur together.

If your workflow ever handles inbox checks, typo-prone terms like temp org mail or fake e mail com are worth keeping visible in plain text artifacts. They are small mistakes, but they can explain why one check behaved oddly. Hiding them deep in an execution script makes triage slower for no real benfit.

How to keep the publisher execution-only

The handoff rule I prefer is pretty strict:

1. The writer plans once.
2. The writer writes once.
3. The publisher performs side effects only.

That third line matters a lot. If the publisher starts "improving" wording, replacing links, or repairing metadata on the fly, your reruns stop being comparable. You can no longer tell whether the problem came from planning or from execution. A clean boundary keeps each layer honest.

This does not mean the publisher has to be dumb. It can still validate required files, refuse image placeholders, confirm auth state, and record the final URL. It just should not become a second writer. I have seen teams blur this line because it feels convienent at first, then regret it once the workflow starts missing edge cases.

Another benefit is that human review becomes lighter. A teammate can skim one plan and one article, then trust that the executor will publish exactly that payload. For recurring jobs, that trust is way more valuable than squeezing in one more "smart" transformation.

Where notification and inbox checks still help

I still use lightweight checks around the boundary. For example, I may verify that a publish notification contains the right run id, account, and link. That is a good use of a small validation step because it confirms the handoff happened cleanly without turning the notification tool into the source of truth.

For workflows that send email, isolated inboxes can still be useful, but they should stay a side check. The core system should not depend on an inbox test to prove that the article itself is correct. Think of those checks more like smoke alarms than architecture. If you want another example of a narrow gate that helps without taking over the workflow, release-email gates in CI/CD captures the idea pretty well.

This is also why I would not force temp mail so or any free throwaway email tooling into every article pipeline. Those tools help for isolated verification and low-risk notification checks, but they are not the main pattern. The main pattern is a trustworthy handoff, readable artifacts, and a publisher that does not improvise.

Q&A

Do I need a database for this?

No. Start with files. Most cron writers are small enough that a run folder gets you 80% of the value with 20% of the effort.

Should retries regenerate the article?

Usually no. If the first article was approved, a retry should reuse it. Re-planning on failure is how a lot of confusing drift sneaks in.

What is the biggest win?

You stop debugging from memory. The run directory tells the story even if the person who kicked off the job is asleep, offline, or only half remembers what changed.

The nice thing about this pattern is how little ceremony it needs. A plain approval file, a single article payload, and an execution-only publisher can make a cron writer feel much more solid without turning it into a giant platform project.