The awkward part of delivering an article is the handover. The editor has approved one version, the export contains several files, and the website expects a particular repository layout. A useful delivery workflow keeps those pieces together and leaves a reviewable record of what changed.
This walkthrough follows AI Content Machine's approved-article delivery implementation. It prepares one commit with Markdown, reviewed image files and a receipt, then opens a draft pull request. The branch is a proposal for a Git-based site. Publication remains a separate human decision.
The implementation reviewed here is main commit 3d118333, containing the PR #53 delivery changes. The production package validator received the v0.5.1 slug and link correction on 30 September 2026; the checked-in workflow retains its v0.5.0 name. A complete fresh production export was unavailable. The evidence below distinguishes repository code, a historical integration test and the September 30 offline checks.
Define exactly what was approved
Begin with a package contract, rather than passing loose article text into GitHub. This implementation requires final approval, a passed quality result, both review timestamps, matching requester and reviewer records, the article body hash and an image manifest.
The validator recomputes SHA-256 from the approved article body and each supplied image. A changed paragraph or different image must fail validation instead of quietly replacing the approved material. It checks safe paths, image byte limits, expected file signatures and image references in the Markdown. The current slug contract accepts lowercase words separated by hyphens, up to 180 characters.
These checks establish consistency inside a trusted workflow. A requester identifier typed into JSON does not authenticate its owner. Restrict workflow editors and callers, and obtain approval through the authenticated review process. Do not manufacture review records to make a real package pass.
The site-specific Markdown contract also matters. This delivery validator rejects code fences, HTML tags and table-style lines. Keep examples in compatible prose or separately reviewed supporting files. A draft that looks correct in a general Markdown editor can still be incompatible with this publishing path.
For the earlier input gate, read Validate Content Ideas in n8n Before Calling AI. This article starts after the editorial decisions, rather than repeating topic validation.
Stop when the destination is uncertain
The first remote check asks whether the target article already exists on main. An existing article blocks this new-article delivery path. An unexpected response also blocks it: permission trouble or a service error is not evidence that the article is absent.
Next, read the main branch reference and its commit. Retain both the commit SHA and its tree SHA. They describe the exact repository snapshot that will serve as the package's base.
A fictional slug such as demo-editorial-handover yields a deterministic editorial branch name. Creating that branch acts as a collision barrier for repeated delivery of that slug. If branch creation reports that the reference already exists, stop and inspect the existing branch. Changing the slug just to get past the barrier creates another delivery identity and defeats the protection.
There is still a concurrency boundary: main can change after the initial read. Review the pull request against current main before merging. The branch reservation protects one deterministic name; it is not a transaction covering the repository, deployment and editorial queue.
Build one complete commit
After reserving the branch, upload the package files as blobs. The delivery workflow collects the returned blob SHAs and pairs them with the expected repository paths. It checks that every expected file received a successful response before constructing the tree.
Use the captured main tree as base_tree. GitHub's Git trees API explains that omitting a base tree creates a tree containing only the supplied entries. A commit built that way can make unrelated repository files appear deleted. Supplying the existing tree and only the intended additions preserves the surrounding site.
The package then creates one commit whose parent is the captured main commit. It advances the reserved editorial branch with force disabled. The article, assets and receipt become reviewable together instead of appearing as a sequence of partially complete file commits.
For this site, Markdown goes under content/articles, images under public/images/articles, and the receipt under automation/editorial/receipts. Those are implementation conventions, not universal n8n requirements. Review them before adapting the workflow to another site.
Open the draft and verify the handover
Create the pull request with the editorial branch as head, main as base and draft set to true. The pull requests API documents that parameter. Save the returned PR number and URL only after checking the successful response.
The parent workflow waits for delivery to finish. n8n's Execute Sub-workflow documentation describes the wait-for-completion option. Waiting allows the parent to return a confirmed delivery result or a failure receipt beside the generated downloads.
The downloaded package and repository proposal have different purposes. The user downloads MD, HTML, PDF and ZIP. The site commit carries Markdown, images and the delivery receipt; it does not add every export format to the public website.
A receipt inside the proposed commit describes the intended awaiting-merge state. By itself, it does not prove a PR exists: the later PR-creation request could fail. Reconcile the actual branch, commit and PR when the outcome is uncertain.
What the test actually proves
The historical integration fixture is PR #52, titled TEST — DO NOT MERGE. A read-only check on 30 September confirmed it remains closed, unmerged and marked draft. Its file list contains exactly four additions: one article, two JPEGs and a receipt. It reused previously approved material with synthetic review identifiers; it was not a newly approved public article.
The saved test record reports successful delivery and a rejected repeat. We did not trigger another live delivery while preparing this tutorial. The September 30 offline checks exercise the current package validator, including changed article data, changed image data, unsafe links and the shared slug boundary. Small signature bytes in unit fixtures are synthetic test data, not proof that an image is a real screenshot.
Before approving your own handover, inspect the complete diff, image credits, preview rendering, canonical URL and expected article path. Check that no unrelated files changed and no private execution data entered the receipt. Only then consider the separate merge decision.
Cost and recovery boundaries
Packaging uses no model call, but operating n8n, GitHub and preview builds can still consume plan allowances or incur charges. A failed handover should not send the whole workflow back through paid generation.
Keep the exported files, record the last confirmed stage and reconcile remote state before another write. The Delivery Reconciliation Reporter, WF13 v0.1.0, was released on 30 September 2026 under MIT for its workflow code and documentation, with separate rights notices for supplied content and images. It classifies supplied snapshots offline; it does not fetch GitHub state, authenticate observations or authorize a retry. Preserve the package and ask the operator to decide any ambiguous recovery.
Verification evidence
Historical delivery review; observed 30 September 2026. read-only github record / not a fresh delivery. Rendered report, not a product UI screenshot. The original image retains its private-review label; the owner approved this historical report for publication on October 1, 2026.
Image provenance and reuse limits: publication asset manifest.