Add a "Managing the OPNsense routers" note to generic.md §11 (Network): opn-cli talks to a site's OPNsense over its API, credentials in a per-site ~/.opn-cli/<site>.yml (api_key/secret + url + internal-CA ca:), --config is required. The split-horizon .internal records and public-name host-overrides live in each router's Unbound, so `unbound host list/create/update/delete` is how you inspect and fix them: opn-cli --config ~/.opn-cli/hanzalova.yml unbound host list opn-cli --config ~/.opn-cli/kosherinata.yml unbound host list Cross-referenced from reverse-proxies.md §2 as the tool to reach for when a mesh client resolves a name to the wrong host — exactly the rob.fyi case. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016fKZzDpvjiJ9eYbPGgJvUP
architecture
Living documentation for the conventions and scaffolding defaults I use across every project I maintain. If you're contributing to one of those projects — as a human or as an AI coding agent — this repo is required reading.
What this is
A single place where decisions about workspace layout, deployment, infrastructure, service hardening, firewall rules, SELinux posture, and similar cross-cutting concerns are written down once and reused everywhere. Rather than re-deriving (or forgetting) the same defaults in every repo, each project points here and inherits them.
The goal is boring consistency: the same crate layout, the same deploy flow, the same systemd hardening, the same firewalld approach across every app I own, so that context switching between projects doesn't mean re-learning the shape of things.
What's here
generic.md— the baseline. Applies to every project unless that project explicitly overrides a section. Covers workspace layout, separation of concerns, configuration, secrets, deployment, service accounts, firewalld, SELinux, and code quality.deployment-gitea-actions.md— CI-driven deployment via a Gitea Actions workflow, as an alternative to thedeploy.sh+manifest.ymlflow ingeneric.md§7. The workflow is the source of infra truth; the runner deploys as a scopedgitea_ciuser.gitea-runners.md— the catalogue ofgongfoo-managed CI runner images (whatruns-on:label gives you which toolchain), how to pick the right one, and how to add or extend an image instead ofdnf-installing at run time. Makesdeployment-gitea-actions.md§5 concrete.port-allocations.md— how to choose a conflict-unlikely TCP port for an internal service (uncommon, registered range, not the alt-HTTP cluster or the ephemeral range) and the fleet registry of what's already assigned. Extendsgeneric.md§9/§3.internal-tls.md— provisioning and renewing per-service internal TLS certs (<service>.internal) for mesh-only nginx vhosts, extending the PKI conventions ingeneric.md§11.external-tls.md— publicly-trusted certs for WAN-facing vhosts via Let's Encrypt (certbot, Cloudflare DNS-01, ECDSA). The external counterpart tointernal-tls.md.reverse-proxies.md— the per-site nginx edge proxies (oolonfor kosherinata,hanzalova.internalfor the office), what sits behind each, the public-vs-mesh access paths, and the per-vhost cert choice. Names the topology behindgeneric.md§11 Ingress.
More files will appear here over time as guidance that's more specific than generic.md gets extracted — per-stack, per-deployment-target, or per-problem-domain documents. When a project needs guidance that isn't generic, it belongs in a new file here, not buried in one project's repo.
How to use it
- If you're scaffolding a new project: start from
generic.mdand follow it. Deviations should be deliberate and noted in that project's own README. - If you're contributing to an existing project of mine: read
generic.mdfirst. The project's localCLAUDE.mdorREADME.mdwill note any intentional deviations; everything else defaults to what's here. - If you're an AI agent: treat this repo's contents as authoritative defaults for any project under my control. When the surrounding project doesn't specify, fall back to the guidance here. When it does specify, the project wins — but flag the deviation so it's visible.
How this evolves
This is living documentation, not a spec frozen at a point in time. When a convention changes — because something broke, because a better pattern emerged, or because the infrastructure itself changed — the update lands here first, and projects catch up on their next touch.
If you find guidance here that contradicts what's actually running in production, the guidance is wrong. Open an issue or a PR.