The Handoff We Deleted
A preview-first runner translated a 37-date campaign plan into 148 account-specific jobs, uploaded 32 media files once, and recorded every external post ID.
- Project
- Dakic campaign publishing workflow
- Role
- Workflow design, automation, and release safeguards
- Timeframe
- August 2026 – present
- Status
- Ongoing

Evidence from the work
- Removed handoff
- 37-date schedule to 148 account-specific publishing jobs
- Safety control
- Preview first; external scheduling requires `--execute`
What this is
Dakic created a publishing runner that turns an approved campaign directory into account-specific scheduling jobs. The directory contains the artwork manifest, social copy, dated schedule, destination accounts, and time fields.
The tool prepares a review file first. An explicit execution flag allows it to upload media and create the external posts after approval.
The friction
Without the runner, the editorial calendar and the scheduling queue require the same decisions in two places. Someone approves a date and account in a document, then copies the caption, selects the account, uploads the image, and enters the date again in the publishing tool.
That handoff added little judgment. It introduced mismatched artwork, wrong account voices, timezone errors, and uncertainty about whether the scheduled post still matched the approved source.
Media created another boundary. Postiz needs its own uploaded URL. A local PNG path could not prove which file reached the external system.
The senior decision
We kept editorial approval in files and automated the transfer into the queue.
The runner joins each schedule slot with its tile, account-specific copy, integration ID, and publication time. It writes the full list of jobs to postiz-preview.json and stops. Review remains a human decision.
Execution requires --execute. The script checks authentication, uploads each unique media file once, creates the scheduled posts, and writes each returned post ID and media URL to a receipt. It can resume without recreating work already recorded in that receipt.
What became real
One campaign directory now shows the approved source, the jobs prepared for publishing, and the receipt from the external scheduler. The reviewed campaign contains 32 tiles across 37 dates. Its schedule expands into 148 account-specific posts, allowing four voices to share the campaign without sharing identical copy or publication times.
The “What Changed This Week?” receipt records 32 uploaded media files and 148 scheduled post IDs for LinkedIn and X destinations. The schedule preserves the Chicago publishing rhythm in explicit UTC timestamps.
Evidence
The repository contains the scheduling runner, campaign plan, generated preview, schedule, and Postiz receipt. The receipt connects each of the 148 publishing jobs to its account voice, content, media file, external post ID, and scheduled time.
The tool does not make approval decisions. It moves approved decisions across the system and records the result.
What we learned
The campaign system decides what the accounts should say. This runner has a narrower job: move those approved decisions into an external queue without silently changing them. The preview and execution gate keep judgment outside the script while eliminating the mechanical handoff.
An external action needs a durable receipt. Without one, the local plan and the remote queue can drift without a reliable way to compare them.
Current state
The workflow has scheduled a real campaign and supports resumable execution. We continue to refine queue refresh behavior and account-specific campaign roles.