Signup
Same-origin forms on the site itself
Pages can post to /newsletter/signup without needing the site publishing path to become an app server.
htmlctl / Extension Page
The newsletter extension shows how htmlctl adds dynamic behavior without losing its agent-first shape.
A newsletter is the kind of feature that can easily push a website stack toward application complexity: signups, verification, unsubscribe flows, campaigns, send tracking, and provider integration. In `htmlctl`, that behavior lives in an extension, not in the core publishing system. That is the point.
Same-origin
Signup and verify under the site’s own domain
Tracked
Campaign sends, previews, unsubscribe state
Separate
Runtime service outside the asset publishing core
Why this matters
Without an extension model, a feature like this starts bending the whole platform.
The bad path
If the core website system absorbs newsletters directly, it starts accumulating signup logic, token flows, mail provider integration, campaign storage, send pacing, and operator workflows. Very quickly the “simple publishing system” is actually becoming an application framework in disguise.
The better path
Keep the website system focused on what agents need most: generating and publishing assets fast and safely. Put the newsletter into a dedicated extension service with its own runtime, and expose it through a declared site path. You get the feature without sacrificing the shape of the system.
What the newsletter extension handles
The dynamic behavior is real. It is just not forced into the core.
Verification
Token-based confirmation under the site domain
Verification and unsubscribe flows are served under the site’s own URLs while the runtime stays isolated on the host.
Campaigns
Preview, upsert, send, and pacing workflows
Operators can preview a campaign, store canonical HTML/text bodies, and send with explicit pacing when provider limits demand it.
State
Subscribers, status, and send tracking
Subscriber confirmation, unsubscribe state, and per-campaign delivery tracking stay in the extension’s own data model.
Operations
Compatibility checks and explicit cutovers
Before traffic is routed, the extension can be validated against the current client and server versions. That keeps runtime adoption disciplined.
Core protection
htmlctl still stays for agents
The newsletter is proof that the system can gain dynamic power without requiring every agent-authored site change to inherit application-framework complexity.
What operators actually do
The workflow is still explicit and legible.
1
Install and configure the extension runtime
Run the service separately with its own env vars, secrets, database, and loopback listener.
2
Validate and route it
Check compatibility, add the backend route, and verify the runtime behavior on staging before prod cutover.
3
Keep publishing and sending distinct
Website content can move through preview and promote. Newsletter campaigns remain operator actions within the extension runtime.
Next step
See the broader product model.
The newsletter extension makes more sense once you see it as part of a larger principle: `htmlctl` is for agents, and dynamic behavior should only appear where the site actually needs it.