Blogpipe

Before Blogpipe, publishing a post meant a person typing a prompt, watching a terminal stream for several minutes, eyeballing the result, and clicking publish. Nothing acted on quality scores, a failed run left no record of what to resume, headless runs needed blanket permissions, and nothing capped spend. Content for a small company has to ship on a schedule whether or not someone is at a laptop, and every post has to meet the same structural contract (frontmatter, schema markup, images on disk, internal links) or the live site breaks in subtle ways.

The pipeline is a state machine executed by a Python runner. A job goes QUEUED, WRITING, ENRICHING, VERIFYING, REVISING (looping back to verify as needed), FINALIZING, READY, and then PUBLISHED after approval; any stage can exit to FAILED or NEEDS_HUMAN. Rewrite jobs skip the write stage, and Search Console directed rewrites of live posts enter at a dedicated OPTIMIZE stage. Every exit path writes a report next to the draft, so a stuck job is reviewable without digging through scratch state.

Each stage is a Claude Agent SDK session that invokes the existing blog skill suite unchanged. Autonomy comes from scoping rather than trust: per-stage tool allowlists, an in-process PreToolUse hook that fences writes to allowlisted directories and blocks dangerous shell patterns, per-stage and per-day cost budgets, and a pacing module that backs off before the account's rolling usage window fills.

Quality is enforced in code. The verify stage produces a content score, an AI citation readiness score, and a fact-check report; a deterministic Python validator checks the frontmatter contract, JSON-LD types, image files, unresolved placeholders, internal links, and answer-first structure. A draft below the bar loops through revise a bounded number of times, then stops for a human.

All state lives in PostgreSQL: jobs, stage runs, events, scores, artifacts, a link registry, and Search Console snapshots. Deployment is one Docker image in two roles, a dashboard and a worker. Because they share no process tree, the dashboard writes run and stop intents to a control table and the worker, which owns the process ids, claims and executes them with SKIP LOCKED semantics. Draft images are mirrored to object storage, and publishing upserts by slug into the headless CMS.