Four apps with result pages, in rotation
Some of my web apps have result URLs. Zodiac, animal-face, Chinese zodiac, blood type: you give an input and each result gets its own page. I added an engine that runs through them in order: capture the result page, render it into a short video, and add it to the publish queue. The commit is titled 'sequential web app rotation engine.'
Capture, render and enqueue were just existing pipeline steps chained together. Two things were new decisions: what goes into the next run, and who remembers how far the rotation has gotten.
When your automation stops today, where does tomorrow's freshly started process find out where it left off?
If the answer is 'the last session remembers,' that memory dies with the session. An agent session, a terminal, a new process launched by a scheduler: none of them carry the previous run's memory. A rotation that can't remember its position starts from the top every time. At that point it isn't rotating anymore. It's repeating the first item.
Don't post the same thing back to back
The second constraint was authenticity. Posting near-identical result screens from the same app one after another looks like repetitive, machine-stamped content. That's why the commit note says 'avoid inauthenticity.'
So the unit of rotation is a theme group, not a single result. Groups are bundles like elements, triads, or types. For zodiac, the signs belonging to the fire element make up one run, and the next run gets a different group. The ordering rule is that every run lands on a different theme group.
What would you do?
Where would you keep the position? In the memory of whatever runs the job, or in a file that doesn't depend on any run?
The position went into one file
I picked the file. The rotation position is written to hook/rotation_state.json, and the next run reads it and continues. That's what 'session-independent' means in the commit note. Whichever session runs it, and whenever, the position stays on disk. The same commit added one line to .gitignore and 33 lines to the publish queue file.
Language lives inside the engine. Labels and hook lines for ko/en/ja are built in, and the CLI takes --lang, --n and --plan. The engine is a single 183-line file.
The part no cheap fix solves
Once it was built, I could see the part code can't fix. A result-URL app has a fixed number of possible results. So do zodiac signs, Chinese zodiac animals, and blood types. Theme groups bundle those results, so there are even fewer of them. Saving the position to a file stops the same group from coming right back. But rotation only widens the gap between repeats. It doesn't give you more to post. This commit doesn't say what happens after every group has gone around once.
Self-check
- Does your automation save 'how far it got' somewhere independent of the run, like disk, rather than in the running process's memory?
- Could your ordering rule fill two runs in a row with similar screens from the same app?
- If your rotation targets are finite, have you decided what happens after one full lap?
The honest part
Only one combination has been verified. I generated the ko zodiac_fire group and confirmed it came out fine. As of this commit there's no record of checking the en/ja labels and hooks, the other three apps, or whether the state file carries over correctly across consecutive runs. I also don't know whether rotating theme groups actually avoids what platforms judge as inauthentic. I made it look non-repetitive by my own standard. I didn't confirm the platform's verdict. And there are no numbers yet on how many people saw the videos this engine posted.