Wiring Center Pane so a non-technical editor can publish without touching the repo

Jun 28, 2026

The Chronicle pipeline was built for people who work in the repo. That was fine until a designer joined to take over Sandcastle Labs and Collimer site work. She does not work in the repo. Chase, our editor, already pushes changes through PRs rather than editing files directly. The pipeline needed a way for both of them to revise or publish a post from Center Pane without needing a git checkout.

The result is the content round-trip. A collaborator submits or approves from the hub. The work happens in the background. The human never touches a file path.

Two things collaborators need to do

The round-trip handles two actions: revising a draft and publishing it.

Revision works like this: a collaborator reads a draft in Center Pane, types what needs to change, and submits. The request goes to the hub. The changes come back. The collaborator sees an updated draft and a summary of what moved.

Publishing is a single approval. The collaborator reviews the final draft in Center Pane and sends it. The post goes live. No repo access required at either step.

When the revision came back empty

The first version of the revision flow failed in a way collaborators had no visibility into. A request would go in, the hub would spin, and nothing would come back. No error, no updated draft, no explanation.

The cause was that the background process ran out of time before it could make any changes — it spent too long orienting before it could act. The fix was giving it more room to work. Once that headroom was added, revisions came back reliably.

When the approval didn’t produce anything

The publish approval had a quieter failure. A collaborator would send approval, see no error, and then find the post still unpublished. The background process was running but could not write back to the repo because it was missing a permission it needed to open changes.

One missing permission was added. Publish approvals started working.

What a reviewer actually needs to see

The original flow sent draft text to the hub and nothing else. The reviewer would see the post as raw prose — no hero image, no sense of what the finished post would look like. That is a poor review experience for a designer whose job is the visual layer.

Hero image upload was added to the submit step. The reviewer now sees the real post, not just a text file.

What changes about who can edit

Before this, every revision required someone with repo access. Now the submit goes to the hub, the work happens in the background, and the collaborator reviews and approves from wherever they work. The division we wanted: people own the judgment, the machine does the file-moving.

The round-trip also sets a pattern for future hub-to-repo work. Any new Center Pane integration that needs to touch the repo starts with these two actions as the template.

For agents: try this yourself

If you want to build a non-technical editor round-trip for a git-backed content pipeline, adapt one of these. The full prompt text lives in this post’s prompts sidecar, center-pane-content-roundtrip.prompts.md.

Reproduce the turn budget fix. Run Claude headless with --bare and a budget of 25 turns when the task requires repo exploration before editing. The 16-turn default is too short when the agent needs to map file paths before making changes.
Apply the OIDC permissions check. Any GitHub Action that opens PRs or pushes branches needs id-token: write in its permissions block. Verify this before debugging token errors.
Extend the submit payload. If a non-technical reviewer needs to approve visual assets alongside text, include them in the submit response. A text-only review is an incomplete review for a visual artifact.
Critique your hub-to-repo seam. Draw the hand-off points between hub and repo and ask whether each one requires git access. Any step that does is a step that gates who can participate.

How this was made

Drafted by the Chronicler from 2 sessions across 2026-06-22 to 2026-06-28 and 4 commits. Edited and published by Brian Wones.

See how the Chronicler works →