The service is a ghost-writing loop for subscribed users, so its architecture is shaped by what it must guarantee end-to-end:

• Topic in, post out. A subscriber hands over a topic or a rough draft; the service must turn it into a finished post without further hand-holding.
• Human-in-the-loop before publish. Nothing goes live until the subscriber has seen and approved the draft — the review step is mandatory, not optional.
• Schedule adherence. Once approved, a post publishes on the agreed cadence; the scheduler must fire reliably and not drop or double-publish a post.
• Edit after publish. A published post can still be revised; edits must update the live copy cleanly.
• Syndication. A published post is pushed out to its agreed destinations as a distinct, repeatable step.
• Accountable by construction. Every draft, edit and publish is owned by Bilbo, so authorship and actions are traceable to one accountable agent.

Grounded in the shared Carolverse stack; this service is wip, so several pieces are still being built:

• Python 3 on FastAPI / Flask behind nginx for the service surface.
• SQLite (WAL) to hold drafts, post state and publish schedules.
• cron / systemd to fire the recurring publish-on-schedule job.
• Claude (Sonnet for routine drafting, Opus for harder editorial reasoning) to draft and edit posts.
• The registry and design store remain the binding sources of truth for the service and its owner agent.

The service is a single-agent editorial loop rather than a multi-block pipeline — it currently has no formal blocks. It is an instance of Carolverse's agent-centric modular architecture: one accountable owner, Bilbo, carries the whole draft → review → publish → edit → syndicate flow.

• Draft stage. Bilbo turns a topic or rough draft into a finished post.
• Review gate. The draft goes back to the subscriber for approval before anything publishes.
• Scheduled publish. A recurring job publishes approved posts on the agreed cadence.
• Edit + syndicate. Published posts can be revised in place and pushed to their agreed destinations.

The per-stage droids that would carry each step are not yet split out — see the team and blocks on the service page.

• Single source of truth. Service identity and ownership come from the live registry and design store, never hand-copied — the shared principle on the Carolverse Architecture page.
• Agent-centric modular architecture. One accountable owner (Bilbo) owns every action in the loop.
• Human-in-the-loop before publish. The subscriber approves the draft; the service never publishes unreviewed copy.
• Schedule over ad-hoc. Publishing happens on the agreed cadence, not on a manual whim.
• Build honestly. The service is wip; capability is added as real blocks and droids, not declared ahead of the work.

• A subscriber's topic or rough draft becomes a finished, approved post with no further hand-holding.
• Nothing publishes unreviewed — the subscriber sees and approves every draft first.
• Approved posts publish on the agreed schedule, with no missed or duplicate publishes.
• A published post can be edited cleanly and syndicated to its agreed destinations.
• Every action is traceable to Bilbo as the accountable owner.

• Owner is an agent, never a human. The service is owned by Bilbo (agt_035).
• Subscriber approval is required before publish — the review step cannot be skipped.
• Publish on the agreed schedule — the cadence is set with the subscriber, not changed unilaterally.
• Service identity is read from the registry/design store, not hand-edited.
• Internal audience, wip readiness — new capability ships through the standard build path, not bolted on.

Current

• Accept a topic or rough draft from a subscribed user and draft a finished post — owned by Bilbo.
• Run the draft past the subscriber for approval before anything goes live.
• Publish approved posts on the agreed schedule.

Much of this is still being wired — the service is wip, with no per-stage blocks or droids split out yet.

Future (on demand)

• Split the editorial loop into first-class blocks (draft, review, publish, edit, syndicate), each with its own droid.
• A durable, observable scheduled publisher with run-audit so missed publishes are caught.
• Edit-after-publish and syndication as repeatable, tracked steps to the subscriber's agreed destinations.
• A subscriber-facing surface to hand over topics and approve drafts.

This service has no agent-facing tools yet — it is operated through its owner agent and the standard build path.

Interact today

• Hand a topic or rough draft to Bilbo; he drafts the post and returns it for approval, then publishes on the agreed schedule.

Operate / extend

• New capability (blocks, a scheduled publisher droid, syndication) ships through the standard Carolverse build path against the registry and design store.
• Because the publisher will be a recurring job, it must be registered as a droid and emit run-audit rows so the Daily Process Sweep can see and heal it.