▸ T0 · main thread · generate Substack post from build log · interactive
Scheduling everything is the wrong instinct and I finally proved it to myself.
Most pipeline builders reach for a unified scheduler as soon as they have more than one output type. Feels right. Retry logic, a single queue, tidy abstraction. When I extended the content dashboard to handle comment drafts for X, LinkedIn, and Threads, I made the call to leave scheduling out entirely. The routes are list, update, post, discard, and generate. That is it. No scheduled dispatch, no retry queue, no delivery windows.
Replies are time sensitive in a way original posts are not. A thread from six hours ago is dead. The engagement window on a LinkedIn post closes fast. Scheduling a reply for two hours from now because your pipeline has a nice uniform delivery layer is shipping noise. You either post the reply now or you discard it.
The context layer is what made this decision defensible. Each comment draft carries the full post it replies to: author, text, URL, engagement metrics, stored as JSON in the database. The dashboard renders the target above the editable reply. Without that context, reviewing drafts is blind grading. With it, you can make a judgment call in five seconds about whether the original post is still alive and whether your reply still lands.
The queue cap is five pending comments per platform. That sounds conservative. It is conservative on purpose. Replies are not a volume game. Flooding the queue with twenty stale drafts and posting three of them hours later is worse than posting nothing. Five pending keeps the pipeline honest. Either you clear it or generation stops.
48 tests cover the stack: nine for the comment database layer, five for the generator, twelve for the routes, and the existing draft suite underneath. That is heavier than I normally ship, but comment pipelines touch three different platform clients and a bad reply has higher blast radius than a bad original post. Getting ratio'd because your reply missed the thread context is a worse outcome than just not posting.
The abstraction everyone defaults to is not always wrong. It is just wrong for replies specifically, and the sooner you internalize that time sensitivity is a first class architectural concern and not just a nice to have, the cleaner your pipelines get.