Steering by comment
A draft comes back from the overnight run and it’s close: right shape, right length, the voice landing where it should, and one thing in it that’s just wrong. A date pulled from the wrong field. A sentence that reads like it’s selling something instead of describing it. A note that should have linked the piece it follows on from and didn’t. Small, and exactly the kind of thing a second pair of eyes catches that an agent alone won’t, because it never knew to look for it.
Before there was a proper way to send that back, fixing it meant one of two things. Either I went into Postiz myself and hand-edited the HTML, which works for a typo and badly for anything bigger, or I waited, opened a session myself, pasted the brief back in and described what was wrong, and hoped whatever came out landed in the same slot on the same channel as the thing it was replacing. Neither of those is a loop. They’re both just redoing the work by hand.
So now there’s an actual loop. I leave a comment on the draft, in Postiz, the same place I’d leave a note on anything else there, and tag the card Revise. The next scheduled run reads it, reworks the draft in place, and hands it straight back to being an ordinary approved post. Same slot, same channel, nothing re-created.
A comment that only ever means the newest thing
Why it is here. A card can go round this loop more than once. If a run re-applied every comment ever left on it, the second pass would try to redo the first fix too, on html that’s already been fixed, and likely break it. The agent needs to know which comments are instructions it hasn’t acted on yet, and which it already has.
How it works. Every time a card is successfully reworked, its id gets written to a small file, revisions.json, sitting in the project’s plain-text state next to the ledger, a flat id-to-timestamp map. Everything else the project keeps is YAMLA plain-text format for structured settings, readable by people and machines. Docker Compose files, bosun-x records and most config you will touch are YAML.; this one’s plain JSON, because there’s nothing in it that nests. When the next run asks for a card’s comments, it reads Postiz’s own comment thread on that post and checks each comment’s timestamp against whatever’s stored for that id. Nothing stored yet, every comment counts as new. Something stored, only what landed after it does. It’s the same idea as marking a ship’s log at the end of a watch: everything written after the mark is new to whoever reads it next, everything before it they’ve already had. A gitThe tool that tracks every change to your code and lets you go back to any earlier version. The history lives in a hidden .git folder inside the project. log read since the last commit works the same way.
Signal flags, and which one wins
Why it is here. Postiz already has a comment thread and a tag field on every post. Building a separate review tool on top of that would mean a second place to check, and the whole point was to stop the review step living somewhere else.
How it works. Each card carries one of five tags, Topic, Write, Skip, Ready or Revise, and its actual status is whichever of those outranks the rest: Skip beats Revise beats Ready beats Write beats a plain Topic with nothing decided yet. Tagging a Ready draft Revise doesn’t clear anything else off it, it just outranks Ready while it’s sitting there, so the moment I notice something’s off I can pull a draft straight out of the approved pile without deleting the approval underneath it. The rework step only accepts a card whose status comes out Write or Revise; hand it anything still Topic, anything Ready with nothing above it, or anything Skip, and it refuses outright rather than guess at what I meant.
Same post, every time
Why it is here. A fix that quietly created a second post, or moved the original to a new slot, would be worse than no fix at all. Whoever’s watching the calendar needs Tuesday’s post to still be Tuesday’s post.
How it works. Reworking a card never creates anything. It’s the same Postiz post id going back into the same update call that first wrote it: new html, new tags, same date, same channel. The only two things that change are the body and the tag list, Revise comes off, Ready goes back on, and the revisions file gets today’s timestamp so the next round of comments has a fresh line to measure against. What a man can do and what a man can’t do: this part can edit a card’s words, and it can never touch its slot.
Verified vs assumed
Verified: a draft tagged Revise with a fresh comment gets reworked and returns to Ready, in place, and a second round of comments on the same card only surfaces what was said after the first rework. Assumed: that a comment is always specific enough to act on. Postiz strips nothing from what I type, so a vague one, “not quite right,” goes through as readable text, and whatever happens next depends on reading between the lines the way anyone would with a vague note. The timestamp doesn’t know whether the comment was useful. That part’s still on me.
Fair winds.
-x