- Weekly publishing cap (
weekly_publish_cap, 1–14, 3 by default). A rolling seven-day window — not “since Monday” — counting new posts the autopilot actually published. Once the cap is reached, the tick keeps drafting and keeps refreshing; it just stops putting new posts live. - Publication checkpoint (
checkpoint_at, 10 by default). A running count across weeks. When it is reached, hands-off publication of new posts pauses until an administrator confirms on the Schedule tab. Confirming resets the count and lifts the pause.
- Only new posts going live on their own are affected. Drafting continues, refreshes of posts already live continue, topic mining continues. The pause is on publication, not on the pipeline.
- Raising
new_per_rundoes not raise the cap. The extra topics are still drafted and still land in the queue — they simply do not publish themselves that week. - Both brakes apply only to a decision the autopilot makes on its own, inside a tick this add-on started (cron or “Run now”). A draft an administrator generates by hand from the Queue asks the very same filter with the very same context, but it is that person’s decision, so it is neither counted nor refused.
- Deciding “yes” and recording a publication are two separate moments. The filter only decides; the count is advanced by the
draftforge/post_publishedaction the free generator fires once the post is actually live. A “yes” the gate then rejects never spends a cap slot. - One e-mail goes out when the checkpoint engages, and not again while the pause stands. A second engagement after a confirm sends a second e-mail.
- The calendar draws the cap as its own “This week” column and marks a week whose forecast would cross it.
- These are the methods that make free 1.3.0 require Pro 1.3.0. An older add-on has no cap and no checkpoint to read, so it is reported as too old — absent, not fatal.