The publishing pipeline
What happens between the editor clicking Save (with Published switched on) and a visitor seeing the post. Click any box to see what it does.
Nothing selected
Pick a box in the diagram above to see what it does and why it is there.
The editor stays in a sandbox
Posts and photos live in their own private repo. No AWS keys are stored there, so the editor account cannot reach deployment credentials.
Everything after Save is automatic
A signed webhook starts a trusted workflow in the site repo. It builds the pages, sitemap and assistant knowledge in one go.
Bad input fails closed
A HEIC photo, a file over 10 MB or a duplicate slug stops the deploy. The last known-good site stays live and the delivery team receives the alert.
How the editor works
Plain create, edit, publish, unpublish and delete, with one Save button. Selected after an early usability spike tested the workflow on desktop and mobile.
One button: Save
Every action is one click and one commit. New posts start hidden. Switching Published on and saving puts a post live; switching it off hides it again. No statuses, reviews or pull requests.
Preview looks like the real page
The preview beside the form uses the site's own stylesheet: fonts, layout, cover photo and bullet lists. Photos show as soon as they are uploaded. Rich text only, no HTML.
Works on a phone
Tested end to end on an iPhone in Safari: sign in, a camera-roll photo, preview, publish, unpublish and delete. Android is tested in Phase 4.
Who can sign in
Only the designated editor account can sign in. Two-step verification can be enabled, while a server-side allowlist remains the primary application gate.
2FA is optional
The design avoids requiring a separate source-control organization. The editor can enable two-step verification at any time, while the server-side allowlist remains mandatory.
The allowlist is the gate
The login service asks GitHub who just signed in. If the username is not on the list, no token is ever released to the browser.
Reassigning is easy
When the role changes hands, the owner can rotate the email, password, and verification device without changing the integration username.
What hide and delete do
Both go through the same deploy and leave the same result on the site. They differ in who can bring the post back.
One file keeps the assistant honest
All published posts go into a single news.md knowledge file. Hide or delete simply changes that file, so no orphan answers are left behind.
Old links do not hit an error
Visitors who open a hidden or deleted post's address are sent to News & Updates by a small redirect page. A true HTTP 301 is an optional upgrade.
History makes restore possible
Every change is a commit. A nightly backup bundle covers the case where history is overwritten, which the free GitHub plan cannot prevent.
The tech stack
Six layers, deliberately reusing the existing hosting and delivery stack. Teal marks new components; gray marks reused capabilities. Click a box for the reasoning.
Nothing selected
Pick a box in the diagram above to see what it is and whether it is new.
No new subscriptions
Sveltia CMS is free and open source (MIT licence). The Lambda, S3 and CloudFront all run inside the existing AWS hosting, at cents per month.
Pinned and self-hosted
The CMS files (the Sveltia bundle and its chunks folder) are served from the site itself at a fixed version, not loaded from a CDN, which closes off a supply-chain risk.
Build only touches news
CI regenerates only the news pages, images and sitemap. It does not re-run the whole site generator, which avoids known Pillow and image pitfalls.
A two-week delivery sequence
The work is sequenced across ten working days, with discovery and the content generator completed before stakeholder review of a working editor experience. Durations are illustrative.
Spikes
Validated simple versus editorial modes, photo limits, knowledge-base refresh, and mobile editing. Result: Sveltia CMS in simple mode with optional two-step verification.
Foundations
Established a private content repository, a site-styled editor preview, shared article styles, and test fixtures. Stakeholder choices move to review after the working editor is available.
Generator and templates
Added content checks, safe story rendering, a mobile-photo pipeline, list and post pages, redirects, the sitemap, and assistant knowledge output. Sixteen automated tests pass.
CMS, login and pipeline
Deploy the Sveltia editor and site-styled preview, login Lambda with allowlist enforcement, CloudFront rules, signed webhook, and trusted publishing workflow.
Test and pilot
After review of the working demo: run the 20-item acceptance matrix, timing checks, and iPhone and Android passes over HTTPS, then let the editor publish a practice post.
Hardening and handover
PageSpeed check after the cache change, one-page user guide, runbook and repo docs.
Go-live
Production switch, editor orientation, first real post published together, and sample content removed.
Delivery note: completing the highest-risk content and image work early leaves room for hands-on review, accessibility checks, and operational handover inside the two-week plan.
Eight decisions that shaped delivery
These decisions expose the tradeoffs behind the interface, security boundary, publishing speed, and recovery model. Mark Agree or Discuss to explore them; your choices stay in this browser and can be copied for a project conversation.