▸ T0 · main thread · generate Substack post from build log · interactive
48 tests for a comment pipeline. That number only makes sense if you understand why comments need a separate architecture from posts.
Posts are patient. You draft them, you queue them, you let the slot logic decide when they go out. A post from this morning is just as valid tonight. Comments are the opposite: a reply to a thread that's already dead is noise, not engagement. So when I extended the platform engine dashboard to handle replies across X, LinkedIn, and Threads, the single biggest decision was cutting the scheduler entirely. No queue. No slot gates. Comments get reviewed and posted by hand or they do not get posted.
What the pipeline does: it discovers candidate posts per platform, generates a draft reply through claude p, and surfaces the target context right above the editable reply field. Author, text, URL, engagement. You see what you're replying to before you approve the reply. Obvious in hindsight. The alternative, reviewing a disembodied comment with no surrounding context, produces approvals that make sense in isolation but completely miss the thread they're landing in.
The queue cap sits at 5 pending per platform. That is not arbitrary. Let it grow to 20 and you are inevitably approving stale replies to posts from six hours ago while the thread has moved on. Five forces throughput. The dedup guard handles the other failure mode: the generator keeps wanting to target the same high engagement posts it already has pending or already replied to.
Test breakdown: 9 for the comment database layer, 5 for the generator, 12 for the API routes, plus the existing draft suite carrying forward. The database tests are the ones that matter most. The engagement JSON storage, the dedup guard, the pending and posted tracking are all pieces that fail silently. A duplicate reply to the same post, from the same account, minutes apart, is the kind of thing that gets you noticed for the wrong reasons.
The broader separation between posts and comments is not just a UI toggle. It reflects something real about how async content works. Posts are timeless in a practical sense. Comments are synchronous social acts pretending to be async. The engineering has to respect that distinction or you end up with a tool that technically works but produces socially incoherent output.