A website built to publish itself

A website that changes over time is a publishing system. Articles, software projects, restoration journals and photographs need different presentations, but they share a question: how does a private proposal become a controlled public change?

This site is its own first case study. Its architecture gives agents a workspace for drafting, gives the owner a concrete result to review and makes publication an explicit operation. That separation lets the content grow without turning every entry into a frontend code change.

CTO to Human: content has a lifecycle

The public site is a view of approved CMS records. The private Git repository is a place to write and preserve evidence before those records change. The Admin interface is another way to maintain the same content, including images and private channel versions.

A project is a hub rather than a long article. Its overview explains the work; independent dated updates record change; albums collect actual photographs; public repository information connects readers to code and community. Personal projects use the same underlying relationships, with a presentation suited to a restoration or a workshop journal.

The chronological Stream connects these forms without flattening them into one content type. RSS gives readers another way to follow published work. An image’s Unicode preview is a playful presentation of the CMS image, not a separate hidden catalog of content assets.

Engineer to Engineer: shared backend authority

The Java21 backend uses QQQ metadata, native actions and business processes. PostgreSQL owns CMS records and relationships; Liquibase versions the schema. The Next.js frontend reads published, site-scoped records and their visible ancestors. It contains the presentation system rather than the content database.

The Java publishing CLI uses the same native QQQ API as administration. It resolves parents, validates source and prepares a plan bound to the clean Git commit, configuration, proposed content and expected database state. The explicit publish command carries the reviewed digest. Server-side transactions apply the canonical change, private versions, ownership and a durable receipt together.

Admin edits are part of this contract. An unexpected canonical edit makes a plan stale; stored private versions take precedence over local copies. Exports preserve those database edits. A future project rendition can be saved privately without replacing the live overview. Restoration prepares local source and requires a fresh publication decision. A reviewed URL move updates content and a CMS redirect in one transaction.

Media follows the same ownership principle. Authored images are uploaded into CMS storage and selected through native Media records. Gallery publication checks the album, project/update and folder relationships before public exposure. Uploaded asset URLs retain the storage system’s public contract, so confidential images do not belong in an unpublished upload.

Delivery: source, artifact and running system

The frontend and backend have separate protected repositories and pipelines. Shared Munitor delivery tooling builds qualified artifacts and updates GitOps deployment state. Kubernetes runs those artifacts; ArgoCD reconciles the declared state. A source merge, an artifact release and a healthy deployment are different facts that need their own evidence.

The standards repository connects this work to the SDLC and security program. Those policies explain review, release, access and recovery expectations; the implementation and deployment checks show where they are being applied. Publishing new content remains independent of releasing a new frontend design.

Follow the Updates and Gallery areas as verified work is added. This overview describes the system, not a fabricated history of milestones or photographs. The website’s implementation and content repositories are private; its public QQQ, Munitor and Standards dependencies provide inspectable examples of the underlying approach.