Erich Blume b0bac91ca9 Fix frontmatter field name for Quartz date display (#158 )

## Summary

- Rename `date-modified` -> `modified` in all 80 docs and the `docs-check-frontmatter` task

Quartz's `CreatedModifiedDate` plugin recognizes `modified`, `lastmod`, `updated`, and `last-modified` — but not `date-modified`. The wrong field name caused Quartz to ignore frontmatter dates entirely and fall through to filesystem timestamps (UTC inside Dagger), showing Feb 12 on pages built late on Feb 11 PST.

## Test plan

- [x] `mise run docs-check-frontmatter` passes
- [ ] Kick off docs release after merge — verify rendered dates match frontmatter values

Reviewed-on: https://forge.ops.eblu.me/eblume/blumeops/pulls/158

2026-02-11 16:45:12 -08:00

2.7 KiB

Raw Blame History

title

modified

Why GitOps?

Note: This article was drafted by AI and reviewed by Erich. I plan to rewrite all explanatory content in my own words - these serve as placeholders to establish the documentation structure.

BlumeOps uses GitOps principles for managing personal infrastructure. This might seem like overkill for a homelab, but there are good reasons.

The Problem with Manual Infrastructure

Traditional server management involves SSHing into machines and running commands. This works, but creates problems:

Drift: The actual state diverges from what you think it is
Amnesia: You forget what you changed and why
Fragility: One bad command can break things with no easy rollback
Bus factor: Only you know how it works (even AI assistants struggle without context)

Git as the Source of Truth

GitOps inverts the model: instead of pushing changes to servers, you commit desired state to Git, and automation pulls it into reality.

Benefits:

Every change is tracked with commit history
Pull requests enable review before deployment
Rollback is just git revert
The repo is the documentation

Why This Matters for a Homelab

A personal homelab isn't a production environment, but it shares the same challenges:

Memory is unreliable - Six months from now, you won't remember why you configured Caddy that way
Experimentation is constant - You try things, break things, want to undo things
AI assistance needs context - Claude can help much more effectively when it can read your infrastructure as code

The BlumeOps Approach

BlumeOps uses layered GitOps:

Layer	Tool	What it manages
Tailnet	[[tailscale	Pulumi]]
Host config	[[roles	Ansible]]
Kubernetes	[[argocd	ArgoCD]]

Each layer has its own reconciliation loop:

Pulumi applies on mise run tailnet-up
Ansible applies on mise run provision-indri
ArgoCD watches Git and syncs manually or automatically

Trade-offs

GitOps isn't free:

Learning curve - You need to understand Ansible, ArgoCD, Pulumi
Indirection - Can't just apt install something; need to add it to config
Complexity - More moving parts than a simple server

But for BlumeOps, the trade-off is worth it. The infrastructure is complex enough that managing it imperatively would be error-prone, and the GitOps approach enables effective AI-assisted operations.

architecture - How the pieces fit together
argocd - Kubernetes GitOps
roles - Host configuration

2.7 KiB Raw Blame History