OPS Content Platform
A Rust-based, file-first workflow for creating, reviewing and publishing content on a personal technical website.
Problem
Technical writing easily gets fragmented across notes, drafts and publishing tools. That makes consistent review difficult and increases the risk of publishing incomplete, unclear or sensitive material.
Platform today
The platform now focuses exclusively on the website. Markdown files with TOML frontmatter are the source of truth. They are stored in content/ and grouped into private ideas and drafts or public-facing articles, notes, projects and pages.
A Rust CLI creates content from templates, validates the content model, shows review prompts and builds a responsive static website. The same reviewed sources generate detail pages, listings, topic pages and the RSS feed. There is no social-media publishing integration.
The public website is available at https://ops.kiepe.dev/.
Workflow 1: capture and develop an idea
An early thought can remain private while it is being developed:
text ops-content new idea "Working title" ops-content new draft --from-idea <idea-id> ops-content review <draft-id>
Ideas and drafts are deliberately excluded from the website. This makes it possible to collect context, open questions and source requirements before a public format is chosen.
Workflow 2: create website content
The CLI provides separate templates for the main public formats:
text ops-content new article "Detailed technical topic" ops-content new note "Short operational check" ops-content new project "Project name"
An article explains a topic in depth, a note captures one concise operational lesson, and a project page documents a problem, approach, working state and limitations. Existing fixed pages such as About, Imprint and Privacy are maintained directly in content/pages/.
After editing, the author runs validate and review, checks facts and sensitive details, then deliberately changes the status. Only reviewed, ready, published and archived content crosses the public website boundary.
Workflow 3: build and inspect the website
text ops-content validate ops-content build-site
The build recreates site/public/ from the source files. Before publication, the generated start page, navigation, content pages, topic pages, legal pages, mobile layout and RSS feed can be inspected locally. Generated files are not committed.
Workflow 4: publish with a controlled deployment
Production deployment is a separate, explicit operation. The infrastructure wrapper first validates the sources, runs tests, builds the site and verifies required artifacts. A deployment dry-run shows the exact synchronization changes without modifying the server:
text scripts/ops-content-platform.sh deploy-site --dry-run
Only after reviewing that output is the production deployment run without --dry-run. The deployment synchronizes the static build and then verifies DNS plus selected public pages against the local artifacts.
What works
- Content creation, validation, review guidance and static-site generation are available through one Rust CLI.
- A shared visibility gate is applied consistently to detail pages, listings, topics and RSS.
- The responsive Editorial-Tech layout covers the complete public site, including legal pages and topic navigation.
- Dry-run and production deployment paths use the same verified build.
- Production smoke tests compare selected public artifacts with the local output after deployment.
Limitations
- Editing and review remain file- and command-line based; there is no browser admin interface.
- Status changes and editorial approval are intentionally manual.
- Deployment is environment-specific rather than a general CI/CD service.
Next improvements
- Add more real articles, notes and project pages.
- Improve review assistance as the content collection grows.