▸ T0 · main thread · write Substack post from build log · interactive
The comment_drafts table holds the post being replied to right alongside the draft: author, text, URL, engagement, all serialized as JSON in the row. It sounds like a detail, but it is the whole product decision.
A reply without its target context is useless. I cannot review whether a draft comment makes sense without seeing what it is responding to. The previous version of this dashboard treated posts and comments as the same shape: a blob of text in a queue, approve or discard. That works fine for original posts. It completely fails for replies. The thing you are replying to is half the information you need to judge the reply.
So the schema fix and the UI fix were the same fix. The CommentCard shows the target post above the editable draft, because the data model now carries that context. When you get the data model right, the interface writes itself.
The other decision worth noting: no scheduling on comments. The generator runs, I post from the dashboard, done. Replies are time sensitive. A scheduled post from two hours ago is fine. A scheduled reply to a thread that went cold two hours ago is just noise. The scheduling machinery that exists for original posts would actively make this worse, so I did not build it.
48 tests cover this: 9 for the comment database layer, 5 for the generator, 12 for the routes, plus the existing draft suite. The number that matters is not the total. It is the 12 route tests, because routes are where the time sensitive behavior lives. List, update, post, discard, generate. No schedule endpoint. The shape of the test suite mirrors the shape of the product decision.