readme updates

README.md

@@ -13,6 +13,30 @@
 
 I'm a curious, self-taught technologist who runs a real, multi-host homelab as a production-grade playground: a Proxmox hypervisor cluster hosting a fleet of VMs/LXCs, a two-zone Caddy reverse-proxy design fronted by Authentik SSO, self-hosted Gitea with Ansible-driven scheduled maintenance, and Terraform+Packer provisioning for bootstrapping new hosts from hardened, minimal images. What started as a hobby project has grown into a full-on journey into DevOps, automation, infrastructure, and security.
 
+# thesabear's Homelab
+
+Most homelabs are a media server with some extra apps bolted on. This one is a platform: the same categories of systems a company's platform/security team owns — secrets management, zero-trust network segmentation, self-hosted CI/CD, human-gated fleet orchestration, a self-built SOC — run at homelab scale, for real, 24/7, by one person.
+
+<table>
+<tr>
+<td align="center"><strong>11</strong><br/>fleet hosts</td>
+<td align="center"><strong>53</strong><br/>compose stacks</td>
+<td align="center"><strong>15</strong><br/>documented systems</td>
+<td align="center"><strong>4</strong><br/>trust boundaries</td>
+<td align="center"><strong>13</strong><br/>automated maintenance flows</td>
+</tr>
+</table>
+
+## The decision that shows the most
+
+Most self-hosted setups have one trust boundary: "you're on the LAN, you're trusted." That's the easy answer, and it's wrong — a single compromised container can reach everything else with no further resistance. The other easy answer, mutual TLS on every single connection with no exceptions, is also wrong: real overhead, real certificate-lifecycle burden, on traffic that doesn't need it — exactly the kind of complexity that gets quietly disabled under pressure, which is worse than never building it.
+
+This fleet runs **four trust boundaries, each calibrated to who's actually on the other end** — public internet traffic, human browsers on personal devices, machine-provisioned containers, and non-HTTP infra traffic each get a different control, matched to their real risk, not a blanket policy applied everywhere or nowhere. Enforced by **three independent routing authorities** instead of one central router, specifically so a failure or misconfiguration in any single one only ever takes out its own third of the traffic — never all of it at once. It didn't start this way, either: the public proxy used to be its own VM, and the internal service-to-service model used to be a flat, unauthenticated mesh with no boundary at all. Both got replaced deliberately, trading operational simplicity for a smaller blast radius.
+
+Full breakdown — the boundary-by-boundary reasoning, the routing-authority failure table, all 8 traffic laws: [docs/architecture-overview.md](docs/architecture-overview.md).
+
+This repo is a sanitized showcase of the systems behind that platform — the actual engineering decisions and tradeoffs, not just a list of installed apps. Every real IP, hostname, and internal domain has been stripped or genericized throughout.
+
 My long-term goal is to build a career in IT — specifically in environments where learning never stops and innovation is part of the culture.
 
 ---
@@ -50,29 +74,6 @@ I'm entirely self-taught. Every tool, trick, concept, and workflow in my repos i
 ![Bash](https://img.shields.io/badge/Bash-Scripting-lightgrey?style=for-the-badge&logo=gnu-bash)
 ---
 
-# thesabear's Homelab
-
-Most homelabs are a media server with some extra apps bolted on. This one is a platform: the same categories of systems a company's platform/security team owns — secrets management, zero-trust network segmentation, self-hosted CI/CD, human-gated fleet orchestration, a self-built SOC — run at homelab scale, for real, 24/7, by one person.
-
-<table>
-<tr>
-<td align="center"><strong>11</strong><br/>fleet hosts</td>
-<td align="center"><strong>53</strong><br/>compose stacks</td>
-<td align="center"><strong>15</strong><br/>documented systems</td>
-<td align="center"><strong>4</strong><br/>trust boundaries</td>
-<td align="center"><strong>13</strong><br/>automated maintenance flows</td>
-</tr>
-</table>
-
-## The decision that shows the most
-
-Most self-hosted setups have one trust boundary: "you're on the LAN, you're trusted." That's the easy answer, and it's wrong — a single compromised container can reach everything else with no further resistance. The other easy answer, mutual TLS on every single connection with no exceptions, is also wrong: real overhead, real certificate-lifecycle burden, on traffic that doesn't need it — exactly the kind of complexity that gets quietly disabled under pressure, which is worse than never building it.
-
-This fleet runs **four trust boundaries, each calibrated to who's actually on the other end** — public internet traffic, human browsers on personal devices, machine-provisioned containers, and non-HTTP infra traffic each get a different control, matched to their real risk, not a blanket policy applied everywhere or nowhere. Enforced by **three independent routing authorities** instead of one central router, specifically so a failure or misconfiguration in any single one only ever takes out its own third of the traffic — never all of it at once. It didn't start this way, either: the public proxy used to be its own VM, and the internal service-to-service model used to be a flat, unauthenticated mesh with no boundary at all. Both got replaced deliberately, trading operational simplicity for a smaller blast radius.
-
-Full breakdown — the boundary-by-boundary reasoning, the routing-authority failure table, all 8 traffic laws: [docs/architecture-overview.md](docs/architecture-overview.md).
-
-This repo is a sanitized showcase of the systems behind that platform — the actual engineering decisions and tradeoffs, not just a list of installed apps. Every real IP, hostname, and internal domain has been stripped or genericized throughout.
 
 ## Architecture at a glance