Fix comma splices for readability across infra and smarthome articles

infra/docker/index.njk

@@ -9,7 +9,7 @@ layout: base.njk
 <h1>Docker Container Strategy</h1>
 <div class="detail-content">
 
-<p>My homelab runs almost entirely on Docker, spread across three dedicated Debian VMs instead of installing containers directly on bare metal or on the NAS operating system itself. Each VM is a clean, disposable Docker host that can be snapshotted and backed up as a whole through Proxmox, and every service is defined declaratively as a Docker Compose file living under <code>/docker-data/compose/&lt;service&gt;/</code>. This keeps the setup portable, reproducible, and easy to document, if a host dies, restoring a VM snapshot brings every container definition back with it.</p>
+<p>My homelab runs almost entirely on Docker, spread across three dedicated Debian VMs instead of installing containers directly on bare metal or on the NAS operating system itself. Each VM is a clean, disposable Docker host that can be snapshotted and backed up as a whole through Proxmox, and every service is defined declaratively as a Docker Compose file living under <code>/docker-data/compose/&lt;service&gt;/</code>. This keeps the setup portable, reproducible, and easy to document. If a host dies, restoring a VM snapshot brings every container definition back with it.</p>
 
 <h2>The three Docker hosts</h2>
 <ul>

infra/lxc/index.njk

@@ -9,7 +9,7 @@ layout: base.njk
 <h1>LXC Container Strategy</h1>
 <div class="detail-content">
 
-<p>Alongside the Docker-based setup, I run a small number of Linux Containers (LXC) directly on the main Proxmox host (PVE). An LXC is an OS-level virtualization container, unlike a Docker container, which packages a single application and its dependencies, an LXC behaves like a full lightweight Linux system with its own init process, systemd services and package manager, but without the overhead of a full virtual machine. Proxmox manages LXCs natively as first-class citizens, right next to VMs, with their own snapshotting, backup and resource-limit tooling. I use far fewer LXCs than Docker containers, reserving them for cases where a persistent, OS-like environment or tight integration with Proxmox itself makes more sense than a containerized app.</p>
+<p>Alongside the Docker-based setup, I run a small number of Linux Containers (LXC) directly on the main Proxmox host (PVE). An LXC is an OS-level virtualization container. Unlike a Docker container, which packages a single application and its dependencies, an LXC behaves like a full lightweight Linux system with its own init process, systemd services, and package manager, but without the overhead of a full virtual machine. Proxmox manages LXCs natively as first-class citizens, right next to VMs, with their own snapshotting, backup and resource-limit tooling. I use far fewer LXCs than Docker containers, reserving them for cases where a persistent, OS-like environment or tight integration with Proxmox itself makes more sense than a containerized app.</p>
 
 <h2>Why LXC instead of Docker here</h2>
 <ul>

infra/monitoring/index.njk

@@ -11,8 +11,8 @@ layout: base.njk
 
 <p>Prometheus and Grafana form the central monitoring stack for the whole
 homelab, running as Docker containers on the NAS. Every machine in the
-flat, Proxmox host, Docker VM, Synology NAS, and Raspberry Pi devices,
-feeds metrics into this central instance.</p>
+flat, including the Proxmox host, Docker VM, Synology NAS, and Raspberry
+Pi devices, feeds metrics into this central instance.</p>
 
 <h2>What's monitored</h2>
 <ul>

smarthome/airplay-audio/index.njk

@@ -25,7 +25,7 @@ speaker app.</p>
 a software mixer stage (<code>+20&nbsp;dB</code> via an ALSA softvol plugin) sits between
 shairport-sync and the hardware. The hardware mixer itself is deliberately
 left fixed at 100% / 0&nbsp;dB, and shairport-sync only ever adjusts its own
-internal software volume, this avoids the volume jumps and mixer
+internal software volume. This avoids the volume jumps and mixer
 conflicts that show up when multiple layers all try to control loudness.</p>
 
 <h2>Bathroom-specific integration</h2>

smarthome/octoprint/index.njk

@@ -39,7 +39,7 @@ that point to better reflect its now-singular focus on the printer.</p>
 
 <h2>Notable OS lesson</h2>
 <p>After moving this Pi to a newer OS release, boot configuration files
-moved to a new path, editing the old path silently does nothing, which
+moved to a new path. Editing the old path silently does nothing, which
 is an easy trap when following older notes or tutorials for the same
 hardware. The lesson: always verify that configuration changes actually
 take effect, especially after OS upgrades on embedded hardware.</p>

smarthome/tasmota-energy/index.njk

@@ -27,7 +27,7 @@ and LED matrix displays.</p>
 
 <h2>Multi-socket power strips</h2>
 <p>Several rooms use multi-outlet smart power strips (each socket
-individually switchable and metered) rather than single smart plugs, this
+individually switchable and metered) rather than single smart plugs. This
 keeps things like "washing machine + dryer" or "office desk cluster" on
 one strip while still tracking each socket's consumption separately.</p>