From 67c6386e2c5b72a9cde78558d02e0a062a031216 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Mon, 16 Mar 2026 16:31:39 +0300
Subject: [PATCH 01/15] Final pass
 golden-paths-developer-experience-standardization-autonomy article

---
 .../index.mdx                                 |  24 ++--
 .../pdf.mdx                                   | 109 ++++++++++++------
 2 files changed, 85 insertions(+), 48 deletions(-)

diff --git a/src/content/articles/golden-paths-developer-experience-standardization-autonomy/index.mdx b/src/content/articles/golden-paths-developer-experience-standardization-autonomy/index.mdx
index c746cf138..04c0ab3d8 100644
--- a/src/content/articles/golden-paths-developer-experience-standardization-autonomy/index.mdx
+++ b/src/content/articles/golden-paths-developer-experience-standardization-autonomy/index.mdx
@@ -30,10 +30,13 @@ There's a better way. Golden paths offer curated, supported ways to accomplish c
 
 ## What Makes a Path Golden
 
-A golden path is a supported, well-documented way to accomplish a common task that the platform team actively maintains and improves. That definition has important implications:
+<Highlighter>A golden path is a supported, well-documented way to accomplish a common task that the platform team actively maintains and improves.</Highlighter> That definition has important implications:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Opinionated but not mandatory",
@@ -61,7 +64,8 @@ A golden path is a supported, well-documented way to accomplish a common task th
 The difference between a golden path and golden handcuffs comes down to choice:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Golden paths vs. golden handcuffs.",
     thead: {
@@ -99,7 +103,7 @@ But having the right philosophy isn't enough. The mechanism that makes golden pa
 Escape hatches are how teams leave the golden path when they have a legitimate reason. Done well, they're a first-class feature of the platform. Done poorly, they're either so hidden that teams work around them anyway, or so easy that everyone uses them and the path becomes meaningless.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Escape hatches should be documented, not hidden",
@@ -120,12 +124,12 @@ Escape hatches are how teams leave the golden path when they have a legitimate r
   ]}
 />
 
+The escape hatch mechanism is what distinguishes a golden path from a mandate. Without it, you're not offering a better way — you're demanding compliance. And compliance without capability creates the shadow systems you were trying to prevent.
+
 <Callout type="info">
 Escape hatches without tracking become invisible technical debt. If you don't know who's using alternatives and why, you can't plan path improvements, estimate migration costs, or sunset deprecated options. Every escape hatch usage should be registered.
 </Callout>
 
-The escape hatch mechanism is what distinguishes a golden path from a mandate. Without it, you're not offering a better way — you're demanding compliance. And compliance without capability creates the shadow systems you were trying to prevent.
-
 ## Getting Started: A Prioritized Approach
 
 If you're building your first golden path — or trying to fix one that isn't working — here's where to focus. These five priorities are ordered: start at the top and don't skip ahead.
@@ -158,6 +162,10 @@ You're not deploying infrastructure; you're launching a product to internal cust
 
 Platform teams with a product mindset build paths that developers love. Platform teams with an infrastructure mindset build paths that developers tolerate — until something better comes along.
 
+## Making Standardization the Path of Least Resistance
+
+The platform team's job is to make standardization the path of least resistance. When you succeed, shadow infrastructure disappears because there's no reason to build it. Teams adopt standards voluntarily because the alternative is more work. Maintenance burden shifts from every team to the platform team, who can invest deeply in getting it right.
+
 <Download
   resource="golden-paths-developer-experience-standardization-autonomy"
   title="Download the Golden Paths Guide"
@@ -178,10 +186,6 @@ Platform teams with a product mindset build paths that developers love. Platform
   ]}
 />
 
-## Making Standardization the Path of Least Resistance
-
-The platform team's job is to make standardization the path of least resistance. When you succeed, shadow infrastructure disappears because there's no reason to build it. Teams adopt standards voluntarily because the alternative is more work. Maintenance burden shifts from every team to the platform team, who can invest deeply in getting it right.
-
 This approach requires more upfront investment than mandates. You have to build something worth using, not just declare what's required. You have to listen to feedback and iterate, not just enforce compliance. You have to prove value with data, not just assert it with authority.
 
 But the payoff is a platform that developers trust and willingly adopt. A successful golden path doesn't need enforcement. When developers choose your path because it's faster, easier, and better supported, you've built something valuable. That willing adoption is sustainable in a way that mandates never are.
diff --git a/src/content/articles/golden-paths-developer-experience-standardization-autonomy/pdf.mdx b/src/content/articles/golden-paths-developer-experience-standardization-autonomy/pdf.mdx
index f60b7fe2d..fa03c2926 100644
--- a/src/content/articles/golden-paths-developer-experience-standardization-autonomy/pdf.mdx
+++ b/src/content/articles/golden-paths-developer-experience-standardization-autonomy/pdf.mdx
@@ -23,12 +23,12 @@ Platform teams want standardization for maintainability, security, and operation
 
 Here's the scenario I've seen play out too many times: a platform team mandates a specific deployment pipeline. Teams with legitimate edge cases — ML workloads that need GPU nodes, regulated data that requires specific isolation, real-time systems that can't tolerate the standard rollout strategy — face a choice. They can fight for exceptions (slow, political), work around the mandate (shadow infrastructure), or shoe-horn their use case into an ill-fitting solution (technical debt, operational risk).
 
-Morale drops. Shadow platforms emerge. The "standard" becomes optional in practice because enough teams have found workarounds that enforcement is impossible. The mandate failed because it was a golden handcuff, not a golden path.
-
 <Callout type="warning">
 Mandates breed workarounds. When developers can't use the standard path for legitimate reasons and have no sanctioned escape hatch, they'll build shadow infrastructure. You end up with __less__ standardization than if you'd designed for autonomy from the start.
 </Callout>
 
+Morale drops. Shadow platforms emerge. The "standard" becomes optional in practice because enough teams have found workarounds that enforcement is impossible. The mandate failed because it was a golden handcuff, not a golden path.
+
 ## The Philosophy of Golden Paths
 
 ### What Makes a Path "Golden"
@@ -36,7 +36,10 @@ Mandates breed workarounds. When developers can't use the standard path for legi
 A golden path is a supported, well-documented way to accomplish a common task that the platform team actively maintains and improves. That definition has several important implications.
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Opinionated but not mandatory",
@@ -66,7 +69,10 @@ A golden path is a supported, well-documented way to accomplish a common task th
 Three failure modes kill golden paths:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Golden handcuffs",
@@ -88,7 +94,7 @@ Three failure modes kill golden paths:
 Standardization approaches exist on a spectrum from mandates to full self-service, with golden paths in the middle. The table below compares these approaches across four dimensions: how much consistency you achieve, how fast teams can move, how much the platform team invests, and what use cases each approach fits best.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Comparing standardization approaches.",
     thead: {
@@ -114,19 +120,19 @@ Standardization approaches exist on a spectrum from mandates to full self-servic
 />
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
-      lead: "Mandated standards work for security-critical controls, legal and compliance requirements, and cross-cutting concerns like observability where inconsistency creates real operational risk",
-      text: "The tradeoff is high adoption friction and stifled innovation. Use mandates sparingly.",
+      lead: "Mandated standards suit high-stakes controls.",
+      text: "They work for security-critical requirements, legal compliance, and cross-cutting concerns like observability where inconsistency creates real operational risk. The tradeoff is high adoption friction and stifled innovation. Use mandates sparingly.",
     },
     {
-      lead: "Golden paths work for common patterns like service creation and deployment, best practices like testing and monitoring, and productivity tooling",
-      text: "The tradeoff is that escape hatches can become the primary path if you're not careful, and paths can become outdated if you under-invest in maintenance.",
+      lead: "Golden paths suit common, repeatable patterns.",
+      text: "They work for service creation and deployment, best practices like testing and monitoring, and productivity tooling. The tradeoff is that escape hatches can become the primary path if you're not careful, and paths can become outdated if you under-invest in maintenance.",
     },
     {
-      lead: "Full self-service works for early-stage companies where standardization would slow down finding product-market fit, R&D and experimental work where the whole point is trying new things, and highly heterogeneous tech landscapes where no single path could cover the diversity",
-      text: "The tradeoff is duplication of effort, knowledge silos, and operational burden distributed across every team.",
+      lead: "Full self-service suits exploration and diversity.",
+      text: "It works for early-stage companies where standardization would slow down finding product-market fit, R&D work where the whole point is trying new things, and heterogeneous tech landscapes where no single path could cover the diversity. The tradeoff is duplication of effort, knowledge silos, and operational burden distributed across every team.",
     },
   ]}
 />
@@ -144,10 +150,11 @@ A well-designed golden path has five components: an entrypoint, a core journey,
 The best golden path is useless if developers don't know it exists or can't figure out which one applies to their situation. Path discovery is the zero-th step that makes everything else possible.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
-      text: "A service catalog (Backstage, Port, or similar) gives developers a searchable, browsable home for all paths. Each path has a card with a description, use cases, getting-started link, and owner contact. Developers searching for \"create a new service\" or \"set up monitoring\" find the relevant path immediately.",
+      lead: "A service catalog gives developers a browsable home for all paths.",
+      text: "Tools like Backstage or Port let each path have a card with a description, use cases, getting-started link, and owner contact. Developers searching for \"create a new service\" or \"set up monitoring\" find the relevant path immediately.",
     },
     {
       lead: "Decision trees help when multiple paths might apply",
@@ -171,16 +178,22 @@ Path discovery also means knowing when __not__ to use a path. Decision trees sho
 The __entrypoint__ is how developers discover and start using the path. This could be a CLI command (`platform create service`), a template catalog in Backstage, or a GitHub template repository. The entrypoint should be obvious and frictionless — if developers can't find the path or the first step is confusing, they won't use it.
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:mr-6 mb-6",
+  }}
   items={[
     {
-      text: "The core journey is the sequence of steps that gets developers from \"I need a thing\" to \"I have a working thing.\" For a service creation path, this might be: scaffold the service skeleton, configure service-specific values, provision infrastructure, and verify everything works. The core journey should be fast (10 minutes or less for common cases) and should handle the common case without requiring decisions the developer isn't equipped to make.",
+      lead: "The core journey takes developers from need to working artifact.",
+      text: "For a service creation path, this might be: scaffold the service skeleton, configure service-specific values, provision infrastructure, and verify everything works. The core journey should be fast (10 minutes or less for common cases) and should handle the common case without requiring decisions the developer isn't equipped to make.",
     },
     {
-      text: "Extension points are places where teams can customize the path without forking it. These might be pre/post hooks in a pipeline, config overrides, or plugin systems. Good extension points let teams add behavior without modifying the core path.",
+      lead: "Extension points let teams customize without forking.",
+      text: "These might be pre/post hooks in a pipeline, config overrides, or plugin systems. Good extension points let teams add behavior without modifying the core path.",
     },
     {
-      text: "Escape hatches are documented ways to leave the path entirely when it doesn't fit. These should be visible (not hidden), have clear processes, and ideally include a migration path back to the golden path later.",
+      lead: "Escape hatches provide a documented way off the path.",
+      text: "They should be visible (not hidden), have clear processes, and ideally include a migration path back to the golden path later.",
     },
   ]}
 />
@@ -286,7 +299,7 @@ Escape hatches are how teams leave the golden path when they have a legitimate r
 Four principles guide escape hatch design:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
   items={[
     {
       lead: "Documented, not hidden",
@@ -312,7 +325,7 @@ Four principles guide escape hatch design:
 Not all deviations are equal. A tiered system helps teams understand the implications:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     figure: "Escape hatch tiers with escalating process and decreasing support.",
     thead: {
@@ -321,19 +334,19 @@ Not all deviations are equal. A tiered system helps teams understand the implica
     tbody: {
       tr: [
         {
-          th: "1: Extension",
+          th: "Extension",
           td: ["Custom CI steps, extra K8s annotations", "Self-service, no approval", "Full support"],
         },
         {
-          th: "2: Override",
+          th: "Override",
           td: ["Custom Dockerfile, alternative test framework", "Document in README, async review", "Best-effort"],
         },
         {
-          th: "3: Exception",
+          th: "Exception",
           td: ["Alternative deployment target, custom networking", "Architecture review required", "Self-maintained"],
         },
         {
-          th: "4: Off-platform",
+          th: "Off-platform",
           td: ["Custom infrastructure, third-party managed service", "VP approval, convergence plan", "None"],
         },
       ],
@@ -394,7 +407,10 @@ The best golden paths don't need enforcement. Developers choose them because the
 Four incentive strategies drive sustainable adoption:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:mr-6 mb-6",
+  }}
   items={[
     {
       lead: "Intrinsic value",
@@ -406,7 +422,11 @@ Four incentive strategies drive sustainable adoption:
 Measure this by comparing time-to-first-deployment for path users vs. manual setup, tracking developer satisfaction surveys, and monitoring support ticket volume.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  startNumber={2}
+  classes={{
+    wrapper: "sm:mr-6 mb-6",
+  }}
   items={[
     {
       lead: "Network effects",
@@ -422,7 +442,11 @@ Measure this by comparing time-to-first-deployment for path users vs. manual set
 The operational benefits are particularly powerful because they compound over time. A team that's been on the path for a year has gotten dozens of automatic security patches, while a team off the path has been doing that work manually (or not at all).
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  startNumber={4}
+  classes={{
+    wrapper: "sm:mr-6 mb-6",
+  }}
   items={[
     {
       lead: "Organizational recognition",
@@ -436,7 +460,7 @@ The operational benefits are particularly powerful because they compound over ti
 Some tactics look like they'd drive adoption but actually backfire:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Shame dashboards",
@@ -466,7 +490,7 @@ Some tactics look like they'd drive adoption but actually backfire:
 There are legitimate ways to encourage adoption without coercion:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Opportunity cost visibility",
@@ -496,7 +520,10 @@ Remember the autonomy spectrum: we're aiming for high consistency __and__ high t
 ### Four Categories of Path Metrics
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Adoption metrics",
@@ -520,7 +547,7 @@ Remember the autonomy spectrum: we're aiming for high consistency __and__ high t
 ### Leading vs Lagging Indicators
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Leading and lagging indicators for path health.",
     thead: {
@@ -578,7 +605,7 @@ Golden paths aren't static. They have lifecycles — they're born, mature, and e
 Every path moves through four stages:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Incubation",
@@ -604,7 +631,10 @@ Every path moves through four stages:
 Deprecation announcements need to be comprehensive and actionable. A good deprecation communication includes several elements:
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "The what and why",
@@ -666,7 +696,10 @@ A healthy platform team needs several distinct roles, though in smaller organiza
 How platform teams interact with product teams determines whether paths feel like services or mandates:
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Regular touchpoints",
@@ -731,10 +764,10 @@ The key principles are straightforward: design escape hatches as first-class fea
 
 The platform team's job is to make standardization the path of least resistance. When you succeed, shadow infrastructure disappears because there's no reason to build it. Teams adopt standards voluntarily because the alternative is more work. Maintenance burden shifts from every team to the platform team, who can invest deeply in getting it right.
 
-This approach requires more upfront investment than mandates. You have to build something worth using, not just declare what's required. You have to listen to feedback and iterate, not just enforce compliance. You have to prove value with data, not just assert it with authority.
-
-But the payoff is a platform that developers trust and willingly adopt. And that voluntary adoption is both the goal and the measure of success.
-
 <Callout type="success">
 A successful golden path doesn't need enforcement. When developers voluntarily choose your path because it's faster, easier, and better supported, you've built something valuable. That voluntary adoption is sustainable in a way that mandates never are.
 </Callout>
+
+This approach requires more upfront investment than mandates. You have to build something worth using, not just declare what's required. You have to listen to feedback and iterate, not just enforce compliance. You have to prove value with data, not just assert it with authority.
+
+But the payoff is a platform that developers trust and willingly adopt. And that voluntary adoption is both the goal and the measure of success.

From cb1c261fc6fa017f5b1707ac0766354af0a57261 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Mon, 16 Mar 2026 17:34:38 +0300
Subject: [PATCH 02/15] Final pass
 grafana-dashboard-hygiene-pruning-actionable-metrics article

---
 _TODO.md                                      |   8 ++
 src/components/Icon/icons/git.astro           |  29 +++++
 src/components/Icon/icons/git.svg             |  44 ++++++++
 src/components/Icon/icons/turtle.svg          |  54 ----------
 src/components/List/__tests__/index.spec.ts   |  30 ++++++
 .../List/layouts/CardGridList.astro           |   5 +-
 .../index.mdx                                 |  54 ++++++----
 .../pdf.mdx                                   | 102 ++++++++++++------
 8 files changed, 218 insertions(+), 108 deletions(-)
 create mode 100644 src/components/Icon/icons/git.astro
 create mode 100644 src/components/Icon/icons/git.svg
 delete mode 100644 src/components/Icon/icons/turtle.svg

diff --git a/_TODO.md b/_TODO.md
index 5b5d7d751..0b606f0fc 100644
--- a/_TODO.md
+++ b/_TODO.md
@@ -322,6 +322,14 @@ src/content/articles/internal-developer-portal-platform-self-service-actions/pdf
   ]}
 />
 
+### Stretching the badge out to the same size and centering text:
+
+<List
+  variant="badge-list"
+  classes={{
+    titleClass: "block w-full text-center",
+  }}
+
 ### Spacing out the boxes:
 
 <List
diff --git a/src/components/Icon/icons/git.astro b/src/components/Icon/icons/git.astro
new file mode 100644
index 000000000..4b9cacaeb
--- /dev/null
+++ b/src/components/Icon/icons/git.astro
@@ -0,0 +1,29 @@
+---
+export type Props = {
+  color: string
+  classes?: string
+  size: number
+  accessible: boolean
+  focusable: boolean
+  isListMarker?: boolean
+  id?: string
+}
+
+const { color, classes, size, accessible, focusable, isListMarker, id } = Astro.props
+---
+
+<svg
+  id={id}
+  xmlns="http://www.w3.org/2000/svg"
+  class:list={["shrink-0", `w-${size} h-${size}`, `text-${color}`, classes, isListMarker ? "mt-0.5" : ""]}
+  fill="currentColor"
+  stroke="none"
+  viewBox="0 0 24 24"
+  aria-hidden={accessible ? "false" : "true"}
+  focusable={focusable ? "true" : "false"}
+>
+  {accessible && <title>User Avatar Icon</title>}
+  <path
+    d="M 23.547421,10.930935 13.068776,0.45285245 c -0.603095,-0.60346993 -1.581847,-0.60346993 -2.185692,0 L 8.707142,2.6287942 11.467429,5.3890808 c 0.641438,-0.2167504 1.377002,-0.071344 1.888316,0.4399696 0.513751,0.5145948 0.658126,1.25644 0.436126,1.8999413 l 2.660161,2.6602553 c 0.643595,-0.221719 1.38619,-0.07828 1.900223,0.436594 0.718407,0.718127 0.718407,1.882035 0,2.600631 -0.718596,0.718688 -1.882504,0.718688 -2.601474,0 -0.540376,-0.540939 -0.673877,-1.334534 -0.400314,-2.000254 L 12.86965,8.9454003 12.869369,15.473882 a 1.8581286,1.8581286 0 0 1 0.486376,0.347813 c 0.718407,0.718126 0.718407,1.882129 0,2.601286 -0.718595,0.718314 -1.883066,0.718314 -2.60063,0 -0.718408,-0.719157 -0.718408,-1.883066 0,-2.601192 a 1.8425661,1.8425661 0 0 1 0.60197,-0.401345 V 8.8311188 A 1.816691,1.816691 0 0 1 10.755115,8.4297743 C 10.210801,7.8862107 10.079926,7.0875529 10.358833,6.4192078 L 7.6378274,3.6979213 0.45281338,10.882467 c -0.60375117,0.604032 -0.60375117,1.582878 0,2.186441 L 10.931646,23.547179 c 0.603283,0.603563 1.581847,0.603563 2.18588,0 L 23.547327,13.117565 c 0.603564,-0.603751 0.603564,-1.58316 0,-2.18663"
+  ></path>
+</svg>
diff --git a/src/components/Icon/icons/git.svg b/src/components/Icon/icons/git.svg
new file mode 100644
index 000000000..322f0ab18
--- /dev/null
+++ b/src/components/Icon/icons/git.svg
@@ -0,0 +1,44 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Uploaded to: SVG Repo, www.svgrepo.com, Transformed by: SVG Repo Mixer Tools -->
+
+<svg
+   width="24"
+   height="23.999601"
+   viewBox="0 0 24 23.999601"
+   preserveAspectRatio="xMinYMin"
+   fill="#000000"
+   version="1.1"
+   id="svg7"
+   sodipodi:docname="git.svg"
+   inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg">
+  <defs
+     id="defs11" />
+  <sodipodi:namedview
+     id="namedview9"
+     pagecolor="#ffffff"
+     bordercolor="#000000"
+     borderopacity="0.25"
+     inkscape:showpageshadow="2"
+     inkscape:pageopacity="0.0"
+     inkscape:pagecheckerboard="0"
+     inkscape:deskcolor="#d1d1d1"
+     showgrid="false"
+     inkscape:zoom="7.984375"
+     inkscape:cx="32"
+     inkscape:cy="32.125245"
+     inkscape:window-width="2752"
+     inkscape:window-height="1080"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="svg7" />
+  <path
+     d="M 23.547421,10.930935 13.068776,0.45285245 c -0.603095,-0.60346993 -1.581847,-0.60346993 -2.185692,0 L 8.707142,2.6287942 11.467429,5.3890808 c 0.641438,-0.2167504 1.377002,-0.071344 1.888316,0.4399696 0.513751,0.5145948 0.658126,1.25644 0.436126,1.8999413 l 2.660161,2.6602553 c 0.643595,-0.221719 1.38619,-0.07828 1.900223,0.436594 0.718407,0.718127 0.718407,1.882035 0,2.600631 -0.718596,0.718688 -1.882504,0.718688 -2.601474,0 -0.540376,-0.540939 -0.673877,-1.334534 -0.400314,-2.000254 L 12.86965,8.9454003 12.869369,15.473882 a 1.8581286,1.8581286 0 0 1 0.486376,0.347813 c 0.718407,0.718126 0.718407,1.882129 0,2.601286 -0.718595,0.718314 -1.883066,0.718314 -2.60063,0 -0.718408,-0.719157 -0.718408,-1.883066 0,-2.601192 a 1.8425661,1.8425661 0 0 1 0.60197,-0.401345 V 8.8311188 A 1.816691,1.816691 0 0 1 10.755115,8.4297743 C 10.210801,7.8862107 10.079926,7.0875529 10.358833,6.4192078 L 7.6378274,3.6979213 0.45281338,10.882467 c -0.60375117,0.604032 -0.60375117,1.582878 0,2.186441 L 10.931646,23.547179 c 0.603283,0.603563 1.581847,0.603563 2.18588,0 L 23.547327,13.117565 c 0.603564,-0.603751 0.603564,-1.58316 0,-2.18663"
+     fill="#de4c36"
+     id="path4"
+     style="stroke-width:0.0937502" />
+</svg>
diff --git a/src/components/Icon/icons/turtle.svg b/src/components/Icon/icons/turtle.svg
deleted file mode 100644
index 812834651..000000000
--- a/src/components/Icon/icons/turtle.svg
+++ /dev/null
@@ -1,54 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Uploaded to: SVG Repo, www.svgrepo.com, Transformed by: SVG Repo Mixer Tools -->
-
-<svg
-   fill="#000000"
-   height="24"
-   width="24"
-   version="1.2"
-   id="_x31_"
-   viewBox="0 0 24 23.999999"
-   xml:space="preserve"
-   sodipodi:docname="turtle.svg"
-   inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:svg="http://www.w3.org/2000/svg"><defs
-   id="defs10" /><sodipodi:namedview
-   id="namedview8"
-   pagecolor="#ffffff"
-   bordercolor="#000000"
-   borderopacity="0.25"
-   inkscape:showpageshadow="2"
-   inkscape:pageopacity="0.0"
-   inkscape:pagecheckerboard="0"
-   inkscape:deskcolor="#d1d1d1"
-   showgrid="false"
-   inkscape:zoom="7.984375"
-   inkscape:cx="30.872798"
-   inkscape:cy="20.227006"
-   inkscape:window-width="2752"
-   inkscape:window-height="1080"
-   inkscape:window-x="0"
-   inkscape:window-y="0"
-   inkscape:window-maximized="1"
-   inkscape:current-layer="_x31_" />
-
-<g
-   id="SVGRepo_bgCarrier"
-   stroke-width="0"
-   transform="matrix(0.00938037,0,0,0.00938037,-0.44883694,0.03022296)" />
-
-<g
-   id="SVGRepo_tracerCarrier"
-   stroke-linecap="round"
-   stroke-linejoin="round"
-   transform="matrix(0.00938037,0,0,0.00938037,-0.44883694,0.03022296)" />
-
-<path
-   d="m 17.443099,6.7651333 v 0.019371 L 18.895884,5.5641648 C 17.791767,4.9733658 16.581114,4.644068 15.263922,4.644068 c -1.317191,0 -2.53753,0.3292978 -3.59322,0.9007264 l 1.452785,1.2203389 z M 9.7046004,12.915255 c -2.3922515,0 -4.3583537,1.966101 -4.3583537,4.358353 v 0.435835 0 c 0.019371,0.920097 0.7651335,1.646489 1.68523,1.646489 0.9200972,0 1.6658599,-0.726392 1.6852306,-1.646489 v 0 -0.435835 c 0,-0.552058 0.4358353,-0.978208 0.9782078,-0.978208 0.9394669,0 1.7046009,-0.765134 1.7046009,-1.704601 0,-0.939467 -0.755449,-1.675544 -1.6949156,-1.675544 z m 11.3123486,-0.03874 c -0.939467,0 -1.704601,0.765134 -1.704601,1.704601 v 3.138014 0 c 0.03874,0.900727 0.765134,1.627119 1.685231,1.627119 0.920096,0 1.646489,-0.726392 1.68523,-1.627119 v 0 -3.16707 c 0.01937,-0.929782 -0.745763,-1.675545 -1.66586,-1.675545 z M 24,13.757871 c 0,-0.416464 -0.135593,-0.823244 -0.329298,-1.162227 -0.213075,0.154964 -0.455206,0.251815 -0.745763,0.251815 0.397095,0.474577 0.62954,1.065376 0.62954,1.704601 v 0.532688 C 23.864407,14.716709 24,14.251818 24,13.757871 Z m -11.719128,0.842614 c 0,0.552057 -0.174335,1.036319 -0.455206,1.452784 1.123486,0.251816 2.276029,0.397094 3.457627,0.397094 1.104116,0 2.140436,-0.116222 3.16707,-0.329297 v -1.549637 c 0,-0.62954 0.232446,-1.220339 0.61017,-1.64649 h -7.409201 c 0.368039,0.455206 0.62954,1.026635 0.62954,1.675546 z m -0.648911,-1.66586 v 0 c 0.01937,0 0,-0.01937 0,-0.01937 z m 11.699758,-1.336562 c 0,-0.232445 -0.193705,-0.455205 -0.435835,-0.455205 h -0.05811 C 22.508474,9.0411623 21.346247,7.2106539 19.670702,6.0581117 l -1.7046,1.4334137 c 0.939467,1.1041163 1.588377,2.3341409 1.966101,3.6707026 H 19.012107 C 18.595641,9.9031482 17.90799,8.6828088 16.929782,7.6852304 H 13.743341 C 12.765133,8.7021795 12.096853,9.8837775 11.661017,11.162228 H 10.74092 C 11.118644,9.8644069 11.738498,8.6440682 12.668281,7.5883779 L 10.876513,6.0774823 C 9.2300244,7.2590798 8.0290557,9.0605329 7.7094429,11.162228 H 7.5932204 c -0.2324456,0 -0.4358353,0.193705 -0.4358353,0.435835 0,0.232445 0.1937044,0.435836 0.4358353,0.435836 H 22.876513 c 0.261501,0 0.455206,-0.203391 0.455206,-0.435836 z M 7.4285714,12.556901 C 6.9539948,12.498789 6.5665861,12.101695 6.5665861,11.598063 v -0.861985 c 0,-1.8111382 -1.452785,-3.2832932 -3.2832934,-3.2832932 C 1.472155,7.4527848 0,8.9055691 0,10.736078 v 0.861985 c 0,0.474576 0.3970944,0.861986 0.8619855,0.861986 h 2.3728813 c 0.213075,1.104116 0.8232447,2.004842 1.7046006,2.653753 0.5036318,-1.123487 1.3849877,-2.004843 2.489104,-2.556901 z m -5.559322,-2.430993 c -0.2905569,0 -0.5520581,-0.2324451 -0.5520581,-0.5520579 0,-0.2905569 0.2324455,-0.5520585 0.5520581,-0.5520585 0.3196125,0 0.5520581,0.2324457 0.5520581,0.5520585 -0.00969,0.3099274 -0.2421307,0.5520579 -0.5520581,0.5520579 z"
-   id="path4"
-   style="stroke-width:0.0968525" />
-
-</svg>
diff --git a/src/components/List/__tests__/index.spec.ts b/src/components/List/__tests__/index.spec.ts
index dfb8d8794..f5d58f925 100644
--- a/src/components/List/__tests__/index.spec.ts
+++ b/src/components/List/__tests__/index.spec.ts
@@ -132,4 +132,34 @@ describe('List (Astro)', () => {
       expect(lead?.getAttribute('style')).toBeNull()
     })
   })
+
+  test('applies interactive card styling for the card-grid-list variant', async () => {
+    const List = (await import('@components/List/index.astro')).default
+
+    const renderedHtml = await container.renderToString(List, {
+      props: {
+        variant: 'card-grid-list',
+        items: [
+          {
+            lead: 'Owner clarity matters.',
+            text: 'Each card should clearly communicate its primary action.',
+          },
+        ],
+      },
+    })
+
+    await withJsdomEnvironment(async ({ window }) => {
+      window.document.body.innerHTML = renderedHtml
+
+      const card = window.document.querySelector('ul li')
+      const lead = window.document.querySelector('ul li em')
+
+      expect(card).toBeTruthy()
+      expect(card?.className).toContain('hover:-translate-y-1')
+      expect(card?.className).toContain('hover:bg-page-base')
+      expect(card?.className).toContain('hover:shadow-md')
+      expect(card?.className).toContain('focus-within:border-primary')
+      expect(lead?.textContent).toContain('Owner clarity matters.')
+    })
+  })
 })
\ No newline at end of file
diff --git a/src/components/List/layouts/CardGridList.astro b/src/components/List/layouts/CardGridList.astro
index ce3b9cce9..5e27765cf 100644
--- a/src/components/List/layouts/CardGridList.astro
+++ b/src/components/List/layouts/CardGridList.astro
@@ -17,7 +17,10 @@ export type Props = {
 const { items, classes }: Props = Astro.props
 
 const ulClass = ["grid grid-cols-1 md:grid-cols-2 gap-4", classes?.ul]
-const liClass = ["bg-page-offset border border-trim rounded-lg p-5 hover:border-primary transition-colors", classes?.li]
+const liClass = [
+  "bg-page-offset border border-trim rounded-lg p-5 transition-all duration-200 ease-out hover:-translate-y-1 hover:border-primary hover:bg-page-base hover:shadow-md focus-within:-translate-y-1 focus-within:border-primary focus-within:bg-page-base focus-within:shadow-md",
+  classes?.li,
+]
 const emClass = ["block text-page-inverse font-semibold not-italic mb-2", classes?.em]
 ---
 
diff --git a/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/index.mdx b/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/index.mdx
index 13f41b2a1..0f6026f14 100644
--- a/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/index.mdx
+++ b/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/index.mdx
@@ -28,7 +28,7 @@ Every dashboard you create is a promise to maintain it. Dashboards without owner
 Dashboard accumulation isn't anyone's fault — it's a natural consequence of how teams work. Every dashboard enters your inventory through a legitimate path, and almost none ever leave.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "New services get dashboards",
@@ -53,8 +53,11 @@ Dashboard accumulation isn't anyone's fault — it's a natural consequence of ho
   ]}
 />
 
+Each of these patterns has a different expected lifecycle, but they all share the same outcome: permanent residency in your Grafana instance. Understanding the intended lifespan of each type is key to building cleanup policies that make sense — you wouldn't apply the same retention rules to a service overview dashboard and an incident debug dashboard.
+
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Dashboard types and their lifecycle patterns.",
     thead: {
@@ -89,10 +92,10 @@ Dashboard accumulation isn't anyone's fault — it's a natural consequence of ho
 
 The asymmetry is stark: creating a dashboard takes minutes, deciding to delete one feels like it requires a committee.
 
-Beyond the clutter, dashboards aren't free. Every panel issues queries to your backend — Prometheus, InfluxDB, your SQL warehouse. A dashboard with 20 panels viewed by 50 people triggers 1,000 queries every refresh cycle. Grafana-managed alerts linked to dashboard panels run continuously, checking for firing conditions even when nobody's watching. That DEBUG dashboard from last quarter? Its alert rules are still querying your metrics database every minute.
-
 <Newsletter />
 
+Beyond the clutter, dashboards aren't free. Every panel issues queries to your backend — Prometheus, InfluxDB, your SQL warehouse. A dashboard with 20 panels viewed by 50 people triggers 1,000 queries every refresh cycle. Grafana-managed alerts linked to dashboard panels run continuously, checking for firing conditions even when nobody's watching. That DEBUG dashboard from last quarter? Its alert rules are still querying your metrics database every minute.
+
 ## Measuring Dashboard Health
 
 You can't make evidence-based decisions about what to keep or delete without usage data. The first step in any hygiene program is instrumenting your Grafana instance to track who's looking at what.
@@ -100,7 +103,10 @@ You can't make evidence-based decisions about what to keep or delete without usa
 For each dashboard, you need four categories of metrics:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "View metrics",
@@ -130,41 +136,51 @@ Raw metrics are useful but overwhelming when you have hundreds of dashboards. A
 A reasonable weighting:
 
 <List
-  variant="check-icons-list"
+  variant="badge-list"
+  classes={{
+    titleClass: "block w-full text-center",
+  }}
   items={[
     {
-      lead: "Usage score (35%)",
-      text: "Based on views and unique viewers in the last 30 days. Zero views scores zero; 100+ views with 10+ unique viewers scores full marks.",
+      title: "Usage score (35%)",
+      lead: "Based on views and unique viewers in the last 30 days.",
+      text: "Zero views scores zero; 100+ views with 10+ unique viewers scores full marks.",
     },
     {
-      lead: "Freshness score (25%)",
-      text: "Based on time since last edit. Edited in the last 30 days scores 100; over a year without edits scores 0.",
+      title: "Freshness score (25%)",
+      lead: "Based on time since last edit.",
+      text: "Edited in the last 30 days scores 100; over a year without edits scores 0.",
     },
     {
-      lead: "Ownership score (25%)",
-      text: "Has an assigned owner? Has a team tag? Has any tags at all? Each adds points.",
+      title: "Ownership score (25%)",
+      lead: "Has an assigned owner?",
+      text: "Has a team tag? Has any tags at all? Each adds points.",
     },
     {
-      lead: "Quality score (15%)",
-      text: "Penalize broken panels heavily (they actively mislead), excessive complexity (30+ panels), and suspiciously simple dashboards (fewer than 3 panels might be incomplete).",
+      title: "Quality score (15%)",
+      lead: "Penalize broken panels heavily (they actively mislead),",
+      text: "excessive complexity (30+ panels), and suspiciously simple dashboards (fewer than 3 panels might be incomplete).",
     },
   ]}
 />
 
 Beyond the numeric score, flag dashboards with specific problems: "no-recent-views," "stale," "no-owner," "broken-panels," "unmaintained," "likely-clone" (title contains "copy"), or "incident-artifact" (title contains "debug").
 
-These flags help prioritize review. A dashboard scoring 40 with "broken-panels" needs immediate attention — it's actively misleading anyone who looks at it. A dashboard scoring 40 with "no-recent-views" can wait for the next cleanup cycle.
-
 <Callout type="success">
 Automate usage tracking from day one. Without data, hygiene decisions become political debates instead of evidence-based choices. "Nobody uses this dashboard" is much more persuasive when you can prove it with numbers.
 </Callout>
 
+These flags help prioritize review. A dashboard scoring 40 with "broken-panels" needs immediate attention — it's actively misleading anyone who looks at it. A dashboard scoring 40 with "no-recent-views" can wait for the next cleanup cycle.
+
 ## Making Cleanup Stick
 
 Process alone won't fix dashboard rot. People hoard dashboards because deletion feels risky and there's no reward for tidiness. You need to change the incentives — and have responses ready for the inevitable objections.
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "\"I might need it someday.\"",
@@ -199,6 +215,8 @@ The biggest obstacle to dashboard hygiene isn't technical — it's cultural. Peo
 
 Dashboard hygiene isn't a one-time project. It's ongoing maintenance, like any other operational practice.
 
+If you do nothing else: implement usage tracking and run one cleanup campaign. Those two actions will give you the data to make informed decisions and the momentum to build a sustainable hygiene practice.
+
 <Download
   resource="grafana-dashboard-hygiene-pruning-actionable-metrics"
   title="Download the Dashboard Hygiene Guide"
@@ -219,6 +237,4 @@ Dashboard hygiene isn't a one-time project. It's ongoing maintenance, like any o
   ]}
 />
 
-If you do nothing else: implement usage tracking and run one cleanup campaign. Those two actions will give you the data to make informed decisions and the momentum to build a sustainable hygiene practice.
-
 The goal isn't the smallest possible dashboard count. It's ensuring that every dashboard that exists is accurate, maintained, and serves a clear purpose. When an engineer searches for "payments" during an incident, they should find 3 relevant dashboards, not 30 stale ones.
diff --git a/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/pdf.mdx b/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/pdf.mdx
index 65d732aa5..b07eee86c 100644
--- a/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/pdf.mdx
+++ b/src/content/articles/grafana-dashboard-hygiene-pruning-actionable-metrics/pdf.mdx
@@ -33,7 +33,10 @@ Every dashboard you create is a promise to maintain it. Dashboards without owner
 Dashboard accumulation isn't anyone's fault — it's a natural consequence of how teams work. Every dashboard enters your inventory through a legitimate path, and almost none ever leave.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "New services get dashboards",
@@ -58,8 +61,10 @@ Dashboard accumulation isn't anyone's fault — it's a natural consequence of ho
   ]}
 />
 
+Each of these patterns has a different expected lifecycle, but they all share the same outcome: permanent residency in your Grafana instance. Understanding the intended lifespan of each type is key to building cleanup policies that make sense — you wouldn't apply the same retention rules to a service overview dashboard and an incident debug dashboard.
+
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Dashboard types and their lifecycle patterns.",
     thead: {
@@ -99,7 +104,10 @@ The asymmetry is stark: creating a dashboard takes minutes, deciding to delete o
 Dashboards aren't free. They consume resources even when nobody's looking at them.
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Data source pressure",
@@ -131,7 +139,7 @@ You can't make evidence-based decisions about what to keep or delete without usa
 For each dashboard, you need four categories of metrics:
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
       lead: "View metrics",
@@ -161,23 +169,31 @@ Raw metrics are useful but overwhelming when you have hundreds of dashboards. A
 A reasonable weighting:
 
 <List
-  variant="check-icons-list"
+  variant="badge-list"
+  classes={{
+    titleClass: "block w-full text-center",
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
-      lead: "Usage score (35%)",
-      text: "Based on views and unique viewers in the last 30 days. Zero views scores zero; 100+ views with 10+ unique viewers scores full marks.",
+      title: "Usage score (35%)",
+      lead: "Based on views and unique viewers in the last 30 days.",
+      text: "Zero views scores zero; 100+ views with 10+ unique viewers scores full marks.",
     },
     {
-      lead: "Freshness score (25%)",
-      text: "Based on time since last edit. Edited in the last 30 days scores 100; over a year without edits scores 0.",
+      title: "Freshness score (25%)",
+      lead: "Based on time since last edit.",
+      text: "Edited in the last 30 days scores 100; over a year without edits scores 0.",
     },
     {
-      lead: "Ownership score (25%)",
-      text: "Has an assigned owner? Has a team tag? Has any tags at all? Each adds points.",
+      title: "Ownership score (25%)",
+      lead: "Has an assigned owner?",
+      text: "Has a team tag? Has any tags at all? Each adds points.",
     },
     {
-      lead: "Quality score (15%)",
-      text: "Penalize broken panels heavily (they actively mislead), excessive complexity (30+ panels), and suspiciously simple dashboards (fewer than 3 panels might be incomplete).",
+      title: "Quality score (15%)",
+      lead: "Penalize broken panels heavily (they actively mislead),",
+      text: "excessive complexity (30+ panels), and suspiciously simple dashboards (fewer than 3 panels might be incomplete).",
     },
   ]}
 />
@@ -197,7 +213,10 @@ Grafana stores dashboard definitions in its database by default — SQLite for s
 The alternative is treating dashboards as code. Instead of editing in the browser, you define dashboards in a repository and deploy them through CI/CD.
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Generation tools",
@@ -225,7 +244,10 @@ Health scores tell you which dashboards need attention. A governance process ens
 Before you can hold people accountable, you need clear expectations. Document these upfront:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Ownership requirements",
@@ -251,7 +273,10 @@ Before you can hold people accountable, you need clear expectations. Document th
 Manual hygiene doesn't scale. The goal is a system that runs itself with minimal human intervention:
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Daily",
@@ -270,12 +295,12 @@ For dashboards scoring between 30 and 50, send a warning email to the owner. Giv
 
 For dashboards scoring below 30, the automation takes over. After the two-week warning period with no response, export the dashboard JSON to cold storage and delete from Grafana. Notify the owner that their dashboard was archived. If they need it back, they can claim it within 90 days. After 90 days, permanent deletion.
 
-This creates accountability. Dashboard owners either maintain their dashboards or lose them. The system is predictable and fair — everyone knows the rules, and the automation applies those rules consistently.
-
 <Callout type="warning">
 Always archive before deleting. A 90-day cold storage period catches the "but we need that during quarterly reviews!" case. Export the JSON, store it somewhere searchable, and only permanently delete after the retention period with no claims.
 </Callout>
 
+This creates accountability. Dashboard owners either maintain their dashboards or lose them. The system is predictable and fair — everyone knows the rules, and the automation applies those rules consistently.
+
 ## Actionable Dashboard Design
 
 Cleaning up existing dashboards is only half the battle. Without standards for __new__ dashboards, you'll be right back where you started in a year. The goal is dashboards that drive action, not dashboards that display data.
@@ -285,7 +310,10 @@ Cleaning up existing dashboards is only half the battle. Without standards for _
 Before creating or keeping a dashboard, it should pass these tests:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Does it answer a specific question?",
@@ -319,7 +347,7 @@ Before creating or keeping a dashboard, it should pass these tests:
 Four dashboard smells that signal problems:
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
       lead: "Vanity dashboards",
@@ -345,7 +373,7 @@ Four dashboard smells that signal problems:
 Rather than policing dashboard standards manually, encode them in templates. A well-designed service health template includes:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "SLO Status row",
@@ -385,7 +413,10 @@ With standards for new dashboards in place, let's address the existing inventory
 Start with the most important question: has anyone viewed this dashboard in the last 90 days?
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "If no",
@@ -405,7 +436,7 @@ Start with the most important question: has anyone viewed this dashboard in the
 Five possible outcomes for every dashboard:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: ["Outcome", "Criteria", "Action"],
@@ -448,7 +479,10 @@ Consolidation isn't always deletion. Sometimes the variants have useful addition
 While the automated hygiene cycle handles ongoing maintenance, a quarterly cleanup campaign creates urgency and clears the backlog.
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Four weeks before",
@@ -478,7 +512,7 @@ While the automated hygiene cycle handles ongoing maintenance, a quarterly clean
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Typical cleanup campaign results.",
     thead: {
@@ -518,7 +552,10 @@ Run cleanup campaigns quarterly. A single big cleanup is less effective than reg
 Process alone won't fix dashboard rot. People hoard dashboards because deletion feels risky and there's no reward for tidiness. You need to change the incentives.
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Celebrate deletion",
@@ -546,7 +583,7 @@ Maintenance is part of the job, not extra work.
 Good metrics focus on outcomes, not outputs:
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
       lead: "Engagement rate",
@@ -556,12 +593,6 @@ Good metrics focus on outcomes, not outputs:
       lead: "Average health score",
       text: "Tracks portfolio quality over time. Should trend upward as you clean up and maintain.",
     },
-  ]}
-/>
-
-<List
-  variant="check-icons-list"
-  items={[
     {
       lead: "Time to find the right dashboard during an incident",
       text: "The metric that actually matters. If engineers can't find the right dashboard quickly, your observability isn't helping when it counts.",
@@ -580,7 +611,7 @@ Bad metrics to avoid: total dashboard count (encourages hoarding to keep the num
 Every cleanup effort encounters the same objections. Have responses ready:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "\"I might need it someday.\"",
@@ -621,6 +652,9 @@ The core practices:
 
 <List
   variant="check-icons-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Track usage from day one",

From 30bb1873f002415d142bfd4717e47908855e760a Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Mon, 16 Mar 2026 18:02:33 +0300
Subject: [PATCH 03/15] Final pass
 helm-release-management-drift-detection-debugging article

---
 src/components/Icon/icons/git.svg             |  44 --------
 .../index.mdx                                 |  10 +-
 .../pdf.mdx                                   | 103 +++++++++++-------
 3 files changed, 66 insertions(+), 91 deletions(-)
 delete mode 100644 src/components/Icon/icons/git.svg

diff --git a/src/components/Icon/icons/git.svg b/src/components/Icon/icons/git.svg
deleted file mode 100644
index 322f0ab18..000000000
--- a/src/components/Icon/icons/git.svg
+++ /dev/null
@@ -1,44 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Uploaded to: SVG Repo, www.svgrepo.com, Transformed by: SVG Repo Mixer Tools -->
-
-<svg
-   width="24"
-   height="23.999601"
-   viewBox="0 0 24 23.999601"
-   preserveAspectRatio="xMinYMin"
-   fill="#000000"
-   version="1.1"
-   id="svg7"
-   sodipodi:docname="git.svg"
-   inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
-   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
-   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
-   xmlns="http://www.w3.org/2000/svg"
-   xmlns:svg="http://www.w3.org/2000/svg">
-  <defs
-     id="defs11" />
-  <sodipodi:namedview
-     id="namedview9"
-     pagecolor="#ffffff"
-     bordercolor="#000000"
-     borderopacity="0.25"
-     inkscape:showpageshadow="2"
-     inkscape:pageopacity="0.0"
-     inkscape:pagecheckerboard="0"
-     inkscape:deskcolor="#d1d1d1"
-     showgrid="false"
-     inkscape:zoom="7.984375"
-     inkscape:cx="32"
-     inkscape:cy="32.125245"
-     inkscape:window-width="2752"
-     inkscape:window-height="1080"
-     inkscape:window-x="0"
-     inkscape:window-y="0"
-     inkscape:window-maximized="1"
-     inkscape:current-layer="svg7" />
-  <path
-     d="M 23.547421,10.930935 13.068776,0.45285245 c -0.603095,-0.60346993 -1.581847,-0.60346993 -2.185692,0 L 8.707142,2.6287942 11.467429,5.3890808 c 0.641438,-0.2167504 1.377002,-0.071344 1.888316,0.4399696 0.513751,0.5145948 0.658126,1.25644 0.436126,1.8999413 l 2.660161,2.6602553 c 0.643595,-0.221719 1.38619,-0.07828 1.900223,0.436594 0.718407,0.718127 0.718407,1.882035 0,2.600631 -0.718596,0.718688 -1.882504,0.718688 -2.601474,0 -0.540376,-0.540939 -0.673877,-1.334534 -0.400314,-2.000254 L 12.86965,8.9454003 12.869369,15.473882 a 1.8581286,1.8581286 0 0 1 0.486376,0.347813 c 0.718407,0.718126 0.718407,1.882129 0,2.601286 -0.718595,0.718314 -1.883066,0.718314 -2.60063,0 -0.718408,-0.719157 -0.718408,-1.883066 0,-2.601192 a 1.8425661,1.8425661 0 0 1 0.60197,-0.401345 V 8.8311188 A 1.816691,1.816691 0 0 1 10.755115,8.4297743 C 10.210801,7.8862107 10.079926,7.0875529 10.358833,6.4192078 L 7.6378274,3.6979213 0.45281338,10.882467 c -0.60375117,0.604032 -0.60375117,1.582878 0,2.186441 L 10.931646,23.547179 c 0.603283,0.603563 1.581847,0.603563 2.18588,0 L 23.547327,13.117565 c 0.603564,-0.603751 0.603564,-1.58316 0,-2.18663"
-     fill="#de4c36"
-     id="path4"
-     style="stroke-width:0.0937502" />
-</svg>
diff --git a/src/content/articles/helm-release-management-drift-detection-debugging/index.mdx b/src/content/articles/helm-release-management-drift-detection-debugging/index.mdx
index c03249802..706245e65 100644
--- a/src/content/articles/helm-release-management-drift-detection-debugging/index.mdx
+++ b/src/content/articles/helm-release-management-drift-detection-debugging/index.mdx
@@ -11,7 +11,7 @@ featured: true
 
 It's 3 AM. Your pager goes off. A critical service is down, and you need to roll back to the previous version. You run `helm rollback myapp 42` with confidence - Helm keeps track of every release, so this should be straightforward. But instead of a clean rollback, you get cryptic errors about resources that don't match, conflicts with existing objects, and a rollback that makes things __worse__.
 
-I've been in this situation more times than I'd like to admit. What I learned is that the rollback wasn't the problem - the problem started days or weeks earlier when the cluster state quietly drifted away from what Helm thought it was managing.
+I've been in this situation more times than I'd like to admit. <Highlighter>What I learned is that the rollback wasn't the problem - the problem started days or weeks earlier when the cluster state quietly drifted away from what Helm thought it was managing.</Highlighter>
 
 This article explains where that drift comes from, how to catch it before it becomes an incident, and what to do when you're staring at a failed release at 3 AM.
 
@@ -45,7 +45,7 @@ The problem is that Helm only knows about changes made __through Helm__. Any mod
 Drift doesn't usually happen through malice. It happens through the normal operations of running production systems:
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
       lead: "Manual patches",
@@ -177,7 +177,7 @@ This command retrieves what Helm thinks it deployed and compares it against the
 ### The Three Most Common Failure Patterns
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
   items={[
     {
       lead: "Resource conflicts",
@@ -202,6 +202,8 @@ Before deleting any resources to fix a failed release, always check if there are
 
 Drift is inevitable in any cluster where humans and automation coexist. The goal isn't to eliminate it entirely but to detect it early and have clear remediation procedures when it causes problems.
 
+The key practices are straightforward: run `helm diff` before every upgrade (automate this in CI), schedule regular drift detection across your fleet, and when failures happen, follow a systematic diagnosis workflow instead of making changes blindly.
+
 <Download
   resource="helm-release-management-drift-detection-debugging"
   title="Download the Helm Operations Guide"
@@ -222,6 +224,4 @@ Drift is inevitable in any cluster where humans and automation coexist. The goal
   ]}
 />
 
-The key practices are straightforward: run `helm diff` before every upgrade (automate this in CI), schedule regular drift detection across your fleet, and when failures happen, follow a systematic diagnosis workflow instead of making changes blindly.
-
 For teams running dozens or hundreds of Helm releases, GitOps tools like Flux and Argo CD can enforce desired state continuously, but they come with their own complexity. The fundamentals of understanding Helm state and detecting drift remain essential regardless of what tooling you use.
diff --git a/src/content/articles/helm-release-management-drift-detection-debugging/pdf.mdx b/src/content/articles/helm-release-management-drift-detection-debugging/pdf.mdx
index c9c75b10e..c1c7f8ba8 100644
--- a/src/content/articles/helm-release-management-drift-detection-debugging/pdf.mdx
+++ b/src/content/articles/helm-release-management-drift-detection-debugging/pdf.mdx
@@ -12,14 +12,12 @@ featured: true
 import helmReleaseFailureDiagram from "./diagrams/helm-release-failure-diagnosis-workflow.jpg"
 import helmReleaseStateDiagram from "./diagrams/helm-release-state-and-drift-flow.jpg"
 
-*[YAML]: YAML Ain't Markup Language
-*[K8s]: Kubernetes
+*[ConfigMap]: Kubernetes ConfigMap resource
 *[CRD]: Custom Resource Definition
-*[CI]: Continuous Integration
-*[CD]: Continuous Deployment
+*[K8s]: Kubernetes
 *[OCI]: Open Container Initiative
 *[RBAC]: Role-Based Access Control
-*[ConfigMap]: Kubernetes ConfigMap resource
+*[YAML]: YAML Ain't Markup Language
 
 Helm makes deploying applications to Kubernetes straightforward. Write a chart, run `helm install`, and your app materializes in the cluster. But that simplicity doesn't scale. When you're managing dozens of services across multiple clusters, you lose track of which chart versions are deployed where, which releases are drifting from their declared state, and why that upgrade failed at 2 AM.
 
@@ -27,12 +25,12 @@ I've spent time untangling Helm state in production clusters, and the pattern is
 
 Here's a scenario I've seen more than once. During an incident, an engineer tries to rollback a Helm release to a known-good state. The rollback fails. Turns out someone ran `kubectl edit` on the deployment three weeks ago to bump memory limits. Helm's stored manifest doesn't match what's in the cluster, so the three-way merge produces unexpected results. The team spends 45 minutes reconciling state instead of fixing the actual problem.
 
-This article covers the operational side of Helm at scale: understanding how Helm tracks state, detecting drift before it causes incidents, maintaining a release inventory across clusters, debugging failed releases systematically, and integrating with GitOps tools for continuous reconciliation.
-
 <Callout type="warning">
 Helm tracks its own state, but the cluster is the source of truth. When these diverge — through manual edits, partial upgrades, or failed releases — Helm's model breaks down. At scale, drift isn't __if__, it's __when__.
 </Callout>
 
+This article covers the operational side of Helm at scale: understanding how Helm tracks state, detecting drift before it causes incidents, maintaining a release inventory across clusters, debugging failed releases systematically, and integrating with GitOps tools for continuous reconciliation.
+
 ## Understanding Helm State
 
 Before you can fix drift, you need to understand how Helm tracks what it's deployed. This isn't just academic — when things break, knowing where Helm stores its state and how it compares against the cluster determines whether you spend 5 minutes or 50 minutes recovering.
@@ -43,6 +41,7 @@ When you run `helm upgrade`, Helm doesn't just push resources to the cluster and
 
 <Diagram
   src={helmReleaseStateDiagram}
+  size="full"
   title="Helm release state and drift flow"
   description="Flowchart showing Helm upgrade processing and where drift appears. The flow starts with helm upgrade, then renders templates, computes a diff against the cluster, and applies changes. A success decision stores either a successful or failed release in Kubernetes Secrets, which then form Helm release history with revisions v1, v2, and current v3. Separately, the cluster contains actual live resources. A dotted relationship indicates the current stored release should match the live cluster state. A manual kubectl edit points directly to the live cluster state to show how out-of-band changes introduce drift between Helm's stored revision history and the actual resources."
 />
@@ -73,35 +72,11 @@ The critical thing to understand: Helm's stored manifest represents what Helm __
 
 Drift shows up in predictable patterns, and recognizing which pattern you're dealing with speeds up recovery.
 
-<List
-  variant="check-icons-list"
-  items={[
-    {
-      lead: "Manual kubectl edits",
-      text: "are the most common source. Someone runs `kubectl edit deployment` to bump resource limits during an incident, or `kubectl patch` to add an annotation. The cluster state changes, but Helm doesn't know. The next `helm upgrade` may revert those changes unexpectedly, or the three-way merge may produce surprising results.",
-    },
-    {
-      lead: "Partial upgrade failures",
-      text: "leave you in limbo. If Helm times out or hits an error mid-upgrade, some resources may be updated while others aren't. You'll see pods running different versions, ConfigMaps updated but Deployments not, and a release status of \"failed\" that blocks further operations.",
-    },
-    {
-      lead: "Secret storage corruption",
-      text: "is less common but more painful. If cleanup scripts, namespace recreation, or manual deletion removes Helm's release secrets, the cluster still has the resources but Helm has no record of them. `helm list` shows nothing, but `helm install` fails with \"already exists.\"",
-    },
-    {
-      lead: "Hook failures",
-      text: "create orphaned state. Pre-upgrade or post-upgrade hooks that fail can leave partial resources. The release is marked failed, but the hook's job or pod may still exist, and main resources may or may not have been deployed depending on when the hook failed.",
-    },
-    {
-      lead: "Three-way merge conflicts",
-      text: "are the trickiest. When Helm computes an upgrade, it compares the old manifest, new manifest, and live cluster state. If someone modified a field in the cluster that you're also changing in the new manifest, the merge can produce unexpected results — fields deleted, values unexpectedly retained, or strategic merge patches behaving counter-intuitively.",
-    },
-  ]}
-/>
-
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
+    figure: "Common Helm drift patterns, their frequency, severity, and recovery difficulty.",
     thead: {
       th: ["Drift Type", "Frequency", "Severity", "Recovery Difficulty"],
     },
@@ -132,6 +107,32 @@ Drift shows up in predictable patterns, and recognizing which pattern you're dea
   }}
 />
 
+<List
+  variant="zebra-list"
+  items={[
+    {
+      lead: "Manual kubectl edits",
+      text: 'The most common source. Someone runs <span class="font-mono">kubectl edit deployment</span> to bump resource limits during an incident, or <span class="font-mono">kubectl patch</span> to add an annotation. The cluster state changes, but Helm doesn\'t know. The next <span class="font-mono">helm upgrade</span> may revert those changes unexpectedly, or the three-way merge may produce surprising results.',
+    },
+    {
+      lead: "Partial upgrade failures",
+      text: 'These leave you in limbo. If Helm times out or hits an error mid-upgrade, some resources may be updated while others aren\'t. You\'ll see pods running different versions, <span class="font-mono">ConfigMaps</span> updated but <span class="font-mono">Deployments</span> not, and a release status of "failed" that blocks further operations.',
+    },
+    {
+      lead: "Secret storage corruption",
+      text: 'Less common but more painful. If cleanup scripts, namespace recreation, or manual deletion removes Helm\'s release secrets, the cluster still has the resources but Helm has no record of them. <span class="font-mono">helm list</span> shows nothing, but <span class="font-mono">helm install</span> fails with "already exists."',
+    },
+    {
+      lead: "Hook failures",
+      text: "Creates orphaned state. Pre-upgrade or post-upgrade hooks that fail can leave partial resources. The release is marked failed, but the hook's job or pod may still exist, and main resources may or may not have been deployed depending on when the hook failed.",
+    },
+    {
+      lead: "Three-way merge conflicts",
+      text: "The trickiest. When Helm computes an upgrade, it compares the old manifest, new manifest, and live cluster state. If someone modified a field in the cluster that you're also changing in the new manifest, the merge can produce unexpected results — fields deleted, values unexpectedly retained, or strategic merge patches behaving counter-intuitively.",
+    },
+  ]}
+/>
+
 <Callout type="info">
 Helm uses a three-way merge: old manifest, new manifest, live state. This usually works well, but manual changes to live state can create surprising merge results. When in doubt, use `--force` for a two-way merge (but understand the implications — it recreates resources rather than patching them).
 </Callout>
@@ -262,16 +263,22 @@ helm list --all-namespaces --output json
 The output includes release name, namespace, chart name and version, app version, status, and last deployment timestamp. Aggregate this across clusters and you can answer questions like:
 
 <List
-  variant="check-icons-list"
+  variant="colored-marker-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
+      color: "bg-secondary",
       text: "Which releases are using chart version X vs Y?",
     },
     {
-      text: "Are there any failed releases that need attention?",
+      color: "bg-orange-500",
+      text: "Which services haven't been deployed in over 30 days?",
     },
     {
-      text: "Which services haven't been deployed in over 30 days?",
+      color: "bg-danger-offset",
+      text: "Are there any failed releases that need attention?",
     },
   ]}
 />
@@ -318,7 +325,8 @@ groups:
 The version inconsistency alert is particularly useful during rollouts. If you're upgrading a chart across clusters, you can see at a glance which clusters are done and which are still pending.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ["Metric", "Purpose", "Alert Threshold"],
@@ -380,7 +388,10 @@ For higher-risk changes, upgrade in stages rather than all at once.
 __Canary upgrades__ deploy to a subset first — typically staging, then one production namespace or cluster — and verify before continuing. This gives you a chance to catch problems before they affect all users. The process looks like:
 
 <List
-  variant="numbered-with-background-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       text: "Upgrade in staging, run smoke tests, verify metrics",
@@ -441,6 +452,8 @@ Start with `helm status` to see the current release state, then `helm history` t
 
 <Diagram
   src={helmReleaseFailureDiagram}
+  magnifyButtonPosition="top-left"
+  size="full"
   title="Helm release failure diagnosis workflow"
   description="Flowchart for troubleshooting a failed Helm upgrade. The process begins with an upgrade failure, then checks helm status, helm history, and failed revision details before branching on the failure type. Hook failures lead to hook job/pod logs and then a decision on whether the hook is recoverable, resulting in either a fix-and-retry path or deletion of hook resources before retrying. Resource failures branch to checking resource events and whether the resource exists, followed by either kubectl describe for wrong state or admission webhook investigation for creation failures. Timeouts branch to pod status and then to image/registry checks, container log review, or node resource review depending on whether pods are in ImagePullBackOff, CrashLoopBackOff, or Pending. Validation errors go to rendering templates and running a server-side `--dry-run`."
 />
@@ -469,7 +482,10 @@ helm template my-release ./my-chart -f values.yaml | kubectl apply --dry-run=ser
 ### Common Failure Patterns
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Hook timeouts",
@@ -585,7 +601,7 @@ Code: ArgoCD Application with self-healing.
 
 ### Emergency Access
 
-GitOps requires discipline. If the only way to change the cluster is through Git, what happens during an incident when you need to make a change __now__?
+GitOps requires discipline. If the only way to change the cluster is through Git, what happens during an incident when you need to make a change _now_?
 
 The answer is break-glass procedures. Create a separate ServiceAccount — something like `emergency-ops`—with elevated permissions that's only used during incidents. Gate access behind your identity provider with MFA and time-limited credentials. When someone authenticates to this account, automatically create a ticket and send an alert to your incident channel.
 
@@ -604,7 +620,10 @@ Helm's simplicity at small scale becomes operational complexity at large scale.
 The key practices that keep Helm manageable:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Understand Helm state",

From 3f474c07035c2efa4155c24d442bfd6322116d7a Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Mon, 16 Mar 2026 19:35:43 +0300
Subject: [PATCH 04/15] Final pass
 idempotent-message-handlers-deduplication-retries article

---
 .../index.mdx                                 | 29 ++++---
 .../pdf.mdx                                   | 83 +++++++++++--------
 2 files changed, 65 insertions(+), 47 deletions(-)

diff --git a/src/content/articles/idempotent-message-handlers-deduplication-retries/index.mdx b/src/content/articles/idempotent-message-handlers-deduplication-retries/index.mdx
index 00c108786..420c51e9f 100644
--- a/src/content/articles/idempotent-message-handlers-deduplication-retries/index.mdx
+++ b/src/content/articles/idempotent-message-handlers-deduplication-retries/index.mdx
@@ -12,16 +12,16 @@ featured: true
 import idempotencyFlowDiagram from "./diagrams/idempotency-flow-second-delivery-skips-processing-entirely.jpg"
 
 *[ACK]: Acknowledgment
-*[UUID]: Universally Unique Identifier
-*[ULID]: Universally Unique Lexicographically Sortable Identifier
-*[TTL]: Time To Live
 *[DLQ]: Dead Letter Queue
+*[TTL]: Time To Live
+*[ULID]: Universally Unique Lexicographically Sortable Identifier
+*[UUID]: Universally Unique Identifier
 
 Your payment service receives a charge message, successfully charges the customer's card, and then the process crashes before it can acknowledge the message back to the queue. The queue sees no acknowledgment, assumes failure, and redelivers. Without idempotency, that's a double charge. With a properly designed idempotent handler, the second delivery is recognized as a duplicate and returns success without touching the payment gateway again.
 
 This isn't a hypothetical edge case. I've seen it happen in production - payment services that charged customers twice, inventory systems where stock counts drifted negative from duplicate decrements, and welcome emails that arrived in triplicate. The common thread? Handlers that assumed each message would arrive exactly once.
 
-Every production queue operates on at-least-once delivery - "probably more than once." The question isn't __if__ duplicates arrive, it's when.
+Every production queue operates on at-least-once delivery - "_probably more than once_." The question isn't _if_ duplicates arrive, it's when.
 
 This article covers the two foundational patterns for building idempotent handlers: designing idempotency keys that reliably identify duplicates, and choosing the right storage strategy for your deduplication state.
 
@@ -32,23 +32,26 @@ The idempotency key is the identifier your handler uses to recognize duplicate m
 There are four common strategies, each with distinct tradeoffs:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Producer-supplied message ID",
-      text: "is the cleanest approach. The producer generates a UUID or ULID when creating the message and includes it in the payload. This key survives redeliveries because it's part of the message content, not queue metadata. The downside is that it requires producer discipline - every producer must generate and include a unique ID.",
+      text: "The cleanest approach. The producer generates a UUID or ULID when creating the message and includes it in the payload. This key survives redeliveries because it's part of the message content, not queue metadata. The downside is that it requires producer discipline - every producer must generate and include a unique ID.",
     },
     {
       lead: "Content hash",
-      text: "works when you can't control producers. Hash the message payload with SHA-256 and use that as the key. Identical content produces identical keys automatically. The risk is that sometimes identical content should be processed multiple times (two separate orders for the same product), and a content hash would incorrectly dedupe them.",
+      text: "Works when you can't control producers. Hash the message payload with SHA-256 and use that as the key. Identical content produces identical keys automatically. The risk is that sometimes identical content should be processed multiple times (two separate orders for the same product), and a content hash would incorrectly dedupe them.",
     },
     {
       lead: "Business key composite",
-      text: "combines entity identifiers with operation context: `order:12345:payment:v3`. This approach has semantic meaning, making debugging easier, but requires careful thought about what constitutes a unique operation.",
+      text: 'Combines entity identifiers with operation context: <span class="font-mono">order:12345:payment:v3</span>. This approach has semantic meaning, making debugging easier, but requires careful thought about what constitutes a unique operation.',
     },
     {
       lead: "Queue message ID",
-      text: "- avoid this approach. SQS assigns a new MessageId on each redelivery. RabbitMQ's delivery tag changes. This approach only deduplicates within a single delivery attempt, which defeats the purpose entirely.",
+      text: 'Avoid this approach. SQS assigns a new <span class="font-mono">MessageId</span> on each redelivery. RabbitMQ\'s delivery tag changes. This approach only deduplicates within a single delivery attempt, which defeats the purpose entirely.',
     },
   ]}
 />
@@ -74,10 +77,10 @@ Once you have a stable idempotency key, you need somewhere to store the record o
 
 A dedicated idempotency store sits between your handler and your business logic. Before processing, the handler checks the store. If the key exists and shows "completed," return the cached result. If the key exists and shows "processing," another instance is handling it - either wait or fail fast. If the key doesn't exist, acquire a lock and proceed.
 
-Redis works well for high-throughput scenarios where you need sub-millisecond latency. The critical detail is the `NX` flag on the SET command - it only sets the key if it doesn't already exist, making the check-and-lock operation atomic.
-
 <Newsletter />
 
+Redis works well for high-throughput scenarios where you need sub-millisecond latency. The critical detail is the `NX` flag on the SET command - it only sets the key if it doesn't already exist, making the check-and-lock operation atomic.
+
 ### Database-Level Deduplication
 
 For financial operations or anywhere you need transactional consistency, database-level deduplication is often better than a separate store. The idempotency key becomes a unique constraint on your business table.
@@ -112,6 +115,7 @@ The sequence diagram below shows the full flow. Notice that on the second delive
 
 <Diagram
   src={idempotencyFlowDiagram}
+  size="full"
   title="Idempotency flow - second delivery skips processing entirely."
   description="Sequence diagram showing how an idempotent message handler processes a first delivery and short-circuits a duplicate. A queue delivers a message to the handler, which checks the idempotency store for key order:123:pay. The store reports the key is not found and grants the lock. The handler processes the payment through the database, receives success, marks the idempotency key as completed with a cached result, and acknowledges the message back to the queue. Later, after a note indicating the consumer crashed and the message was redelivered, the queue sends the same message again. The handler checks the same idempotency key, the store reports it is already completed with a cached result, and the handler immediately acknowledges the message without processing the payment again."
 />
@@ -119,7 +123,8 @@ The sequence diagram below shows the full flow. Notice that on the second delive
 Which storage should you use? It depends on your consistency requirements and latency budget:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Idempotency store options comparison.",
     thead: {
diff --git a/src/content/articles/idempotent-message-handlers-deduplication-retries/pdf.mdx b/src/content/articles/idempotent-message-handlers-deduplication-retries/pdf.mdx
index 131cda215..83d2b9040 100644
--- a/src/content/articles/idempotent-message-handlers-deduplication-retries/pdf.mdx
+++ b/src/content/articles/idempotent-message-handlers-deduplication-retries/pdf.mdx
@@ -13,14 +13,14 @@ import idempotencyFlowDiagram from "./diagrams/idempotency-flow-second-delivery-
 import messageDeliveryDiagram from "./diagrams/message-delivery-semantics.jpg"
 import transactionalOutboxDiagram from "./diagrams/transactional-outbox.jpg"
 
-*[UUID]: Universally Unique Identifier
-*[ULID]: Universally Unique Lexicographically Sortable Identifier
-*[TTL]: Time To Live
+*[ACK]: Acknowledgment
 *[DLQ]: Dead Letter Queue
-*[SQS]: Simple Queue Service
 *[FIFO]: First In First Out
-*[ACK]: Acknowledgment
 *[NACK]: Negative Acknowledgment
+*[SQS]: Simple Queue Service
+*[TTL]: Time To Live
+*[ULID]: Universally Unique Lexicographically Sortable Identifier
+*[UUID]: Universally Unique Identifier
 
 Every message queue you'll work with in production operates on a simple principle: at-least-once delivery. Networks partition, consumers crash, timeouts expire, and when any of those things happen, the queue does the only safe thing it can do - it redelivers the message. This isn't a bug or a misconfiguration. It's the fundamental contract.
 
@@ -28,12 +28,12 @@ The problem hits when your handler isn't ready for it. I've seen payment service
 
 Here's the scenario that makes this concrete: your payment service receives a charge message, successfully charges the customer's card, and then the process crashes before it can acknowledge the message back to the queue. The queue sees no acknowledgment, assumes failure, and redelivers. Without idempotency, that's a double charge. With a properly designed idempotent handler, the second delivery is recognized as a duplicate and returns success without touching the payment gateway again.
 
-This article walks through the patterns that make handlers survive retries: understanding delivery guarantees, designing idempotency keys, implementing deduplication stores, and building handlers that produce the same result regardless of how many times they receive the same message.
-
 <Callout type="warning">
 "At-least-once" means "probably more than once." Design every handler assuming the message has already been processed. The question isn't __if__ duplicates arrive - it's when and how often.
 </Callout>
 
+This article walks through the patterns that make handlers survive retries: understanding delivery guarantees, designing idempotency keys, implementing deduplication stores, and building handlers that produce the same result regardless of how many times they receive the same message.
+
 ## Delivery Guarantees
 
 Before diving into implementation, it's worth understanding why duplicates are inevitable. Message queues offer three delivery semantics, and the tradeoffs between them explain why at-least-once is the default for anything that matters.
@@ -41,7 +41,10 @@ Before diving into implementation, it's worth understanding why duplicates are i
 ### Understanding Message Delivery Semantics
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-18 mb-6",
+  }}
   items={[
     {
       lead: "At-most-once",
@@ -67,7 +70,8 @@ Before diving into implementation, it's worth understanding why duplicates are i
 The table below summarizes when to use each guarantee:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Delivery guarantee comparison.",
     thead: {
@@ -103,23 +107,26 @@ The idempotency key is the identifier your handler uses to recognize duplicate m
 There are four common strategies, each with distinct tradeoffs:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Producer-supplied message ID",
-      text: "is the cleanest approach. The producer generates a UUID or ULID when creating the message and includes it in the payload. This key survives redeliveries because it's part of the message content, not queue metadata. The downside is that it requires producer discipline - every producer must generate and include a unique ID.",
+      text: "The cleanest approach. The producer generates a UUID or ULID when creating the message and includes it in the payload. This key survives redeliveries because it's part of the message content, not queue metadata. The downside is that it requires producer discipline - every producer must generate and include a unique ID.",
     },
     {
       lead: "Content hash",
-      text: "works when you can't control producers. Hash the message payload with SHA-256 and use that as the key. Identical content produces identical keys automatically. The risk is that sometimes identical content should be processed multiple times (two separate orders for the same product), and a content hash would incorrectly dedupe them.",
+      text: "Works when you can't control producers. Hash the message payload with SHA-256 and use that as the key. Identical content produces identical keys automatically. The risk is that sometimes identical content should be processed multiple times (two separate orders for the same product), and a content hash would incorrectly dedupe them.",
     },
     {
       lead: "Business key composite",
-      text: "combines entity identifiers with operation context: `order:12345:payment:v3`. This approach has semantic meaning, making debugging easier, but requires careful thought about what constitutes a unique operation. Does a payment retry get a new version, or should it reuse the same key?",
+      text: 'Combines entity identifiers with operation context: <span class="font-mono">order:12345:payment:v3</span>. This approach has semantic meaning, making debugging easier, but requires careful thought about what constitutes a unique operation. Does a payment retry get a new version, or should it reuse the same key?',
     },
     {
       lead: "Queue message ID",
-      text: "- don't use this. SQS assigns a new MessageId on each redelivery. RabbitMQ's delivery tag changes. This approach only deduplicates within a single delivery attempt, which defeats the purpose entirely.",
+      text: "Don't use this. SQS assigns a new MessageId on each redelivery. RabbitMQ's delivery tag changes. This approach only deduplicates within a single delivery attempt, which defeats the purpose entirely.",
     },
   ]}
 />
@@ -152,19 +159,19 @@ Code: Recommended idempotency key pattern combining producer ID with business co
 Beyond the key format, you need to decide how long to remember processed keys and at what scope.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Global scope",
-      text: "means any service can check whether a message ID was already processed. This requires a centralized idempotency store (typically Redis or a shared database) and makes sense when the same message might be consumed by multiple services.",
+      text: "Means any service can check whether a message ID was already processed. This requires a centralized idempotency store (typically Redis or a shared database) and makes sense when the same message might be consumed by multiple services.",
     },
     {
       lead: "Entity scope",
-      text: "limits deduplication to a specific business entity. The key `order:12345:payment` only needs to be unique within the context of order 12345. This allows storing idempotency state alongside the entity itself, eliminating the need for a separate store.",
+      text: "Limits deduplication to a specific business entity. The key `order:12345:payment` only needs to be unique within the context of order 12345. This allows storing idempotency state alongside the entity itself, eliminating the need for a separate store.",
     },
     {
       lead: "Time-windowed scope",
-      text: "partitions keys by time period: `metric:cpu:host-789:2024-01-15T10:00`. This bounds storage growth for high-volume systems where eventual consistency is acceptable.",
+      text: "Partitions keys by time period: `metric:cpu:host-789:2024-01-15T10:00`. This bounds storage growth for high-volume systems where eventual consistency is acceptable.",
     },
   ]}
 />
@@ -271,6 +278,7 @@ The sequence diagram below shows the full flow. Notice that on the second delive
 
 <Diagram
   src={idempotencyFlowDiagram}
+  size="full"
   title="Idempotency flow - second delivery skips processing entirely."
   description="Sequence diagram showing idempotent message handling across two deliveries. A queue delivers a message to the handler for the first time. The handler checks the idempotency store using key order:123:pay, the store replies that the key is not found and the lock is acquired, the handler processes the payment through the database, the database returns success, the handler marks the key as completed with a cached result, and then acknowledges the message to the queue. A note indicates the consumer crashes and the message is redelivered. On the second delivery, the handler checks the same key again, the idempotency store reports the key is already completed with a cached result, and the handler immediately acknowledges the message without processing the payment again."
 />
@@ -278,7 +286,7 @@ The sequence diagram below shows the full flow. Notice that on the second delive
 Which storage should you use? It depends on your consistency requirements and latency budget:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Idempotency store options comparison.",
     thead: {
@@ -370,45 +378,48 @@ Code: Idempotent handler base class separating deduplication from business logic
 Not every operation needs explicit deduplication. Some operations are _naturally idempotent_ - executing them multiple times produces the same result as executing once.
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
       lead: "Set operations",
-      text: "are naturally idempotent. `user.email = 'new@example.com'` produces the same state whether you run it once or ten times. Same with `UPDATE users SET email = $1 WHERE id = $2`.",
+      text: 'Naturally idempotent. <span class="font-mono">user.email = \'new@example.com\'</span> produces the same state whether you run it once or ten times. Same with <span class="font-mono">UPDATE users SET email = $1 WHERE id = $2</span>.',
     },
     {
       lead: "Upserts",
-      text: "are naturally idempotent. `INSERT ... ON CONFLICT UPDATE` converges to the same final state regardless of how many times you execute it.",
+      text: 'Naturally idempotent. <span class="font-mono">INSERT ... ON CONFLICT UPDATE</span> converges to the same final state regardless of how many times you execute it.',
     },
     {
       lead: "Deletes by ID",
-      text: "are naturally idempotent. `DELETE FROM orders WHERE id = 123` succeeds once and becomes a no-op on subsequent executions.",
+      text: 'Naturally idempotent. <span class="font-mono">DELETE FROM orders WHERE id = 123</span> succeeds once and becomes a no-op on subsequent executions.',
     },
     {
       lead: "Absolute state sets",
-      text: "are naturally idempotent. `inventory.setQuantity(sku, 5)` sets the quantity to 5, not \"adds 5.\" Running it twice still leaves the quantity at 5.",
+      text: 'Naturally idempotent. <span class="font-mono">inventory.setQuantity(sku, 5)</span> sets the quantity to 5, not "adds 5." Running it twice still leaves the quantity at 5.',
     },
   ]}
 />
 
 ### Operations That Require Deduplication
 
-The operations that __aren't__ naturally idempotent are the ones that accumulate:
+The operations that _aren't_ naturally idempotent are the ones that accumulate:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Increments",
-      text: "compound on each execution. `balance += 100` adds 100 every time. The fix is to track which operations have been applied: `applyDeposit(depositId, 100)` can check whether `depositId` was already applied.",
+      text: 'Compound on each execution. <span class="font-mono">balance += 100</span> adds 100 every time. The fix is to track which operations have been applied: <span class="font-mono">applyDeposit(depositId, 100)</span> can check whether <span class="font-mono">depositId</span> was already applied.',
     },
     {
       lead: "Appends",
-      text: "grow the collection. `items.push(newItem)` adds another entry each time. The fix is to include an item ID and check before appending: `if (!items.some(i => i.id === newItem.id)) items.push(newItem)`.",
+      text: 'Grow the collection. <span class="font-mono">items.push(newItem)</span> adds another entry each time. The fix is to include an item ID and check before appending: <span class="font-mono">if (!items.some(i => i.id === newItem.id)) items.push(newItem)</span>.',
     },
     {
       lead: "External side effects",
-      text: "like sending emails or notifications aren't naturally idempotent. The user receives the email on each execution. Track sent notifications by key to prevent duplicates.",
+      text: "Like sending emails or notifications aren't naturally idempotent. The user receives the email on each execution. Track sent notifications by key to prevent duplicates.",
     },
   ]}
 />
@@ -429,6 +440,7 @@ This guarantees that if the state change commits, the event will eventually be p
 
 <Diagram
   src={transactionalOutboxDiagram}
+  size="xl"
   title="Transactional outbox."
   description="Flowchart showing the transactional outbox pattern. Inside a Single Transaction subgraph, a handler writes both an Update Business State action and an Insert Outbox Record action. Both outputs point to the same database, indicating they are committed together. Separately, an Outbox Publisher reads from the database and sends messages to a Message Queue. A Downstream Consumer receives messages from that queue. The diagram shows that business state and outbox event are written atomically first, and event publication happens afterward by polling the outbox."
 />
@@ -730,7 +742,8 @@ Code: Kafka idempotent consumer with database-backed deduplication.
 The table below summarizes what each major queue provides out of the box. The pattern is consistent: every queue requires handler-side idempotency for production workloads. Built-in deduplication helps at the margins but doesn't eliminate the need for application-level duplicate detection.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="timeline-labels-table"
+  fullWidth={false}
   content={{
     figure: "Queue deduplication capabilities - all require handler-side idempotency.",
     thead: {
@@ -739,23 +752,23 @@ The table below summarizes what each major queue provides out of the box. The pa
     tbody: {
       tr: [
         {
-          th: "SQS Standard",
+          th: { label: "SQS Standard", color: "bg-note" },
           td: ["None", "N/A", "Yes"],
         },
         {
-          th: "SQS FIFO",
+          th: { label: "SQS FIFO", color: "bg-success" },
           td: ["MessageDeduplicationId", "5 minutes", "Yes (for longer)"],
         },
         {
-          th: "Kafka",
+          th: { label: "Kafka", color: "bg-accent" },
           td: ["Idempotent producer", "Producer session", "Yes (consumer side)"],
         },
         {
-          th: "RabbitMQ",
+          th: { label: "RabbitMQ", color: "bg-warning" },
           td: ["None", "N/A", "Yes"],
         },
         {
-          th: "Azure Service Bus",
+          th: { label: "Azure Service Bus", color: "bg-info" },
           td: ["MessageId", "Session/window", "Yes"],
         },
       ],

From c6c8347f9c607bcb5517a83ce9589e535594eab4 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Mon, 16 Mar 2026 22:41:44 +0300
Subject: [PATCH 05/15] Final pass
 internal-cli-kubectl-terraform-wrapper-abstraction article

---
 .../index.mdx                                 |  64 +++++---
 .../pdf.mdx                                   | 149 ++++++++++--------
 .../index.mdx                                 |   4 +-
 src/styles/code-highlighting/general.css      |   5 +
 4 files changed, 132 insertions(+), 90 deletions(-)

diff --git a/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/index.mdx b/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/index.mdx
index a5306fb86..2c0781f64 100644
--- a/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/index.mdx
+++ b/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/index.mdx
@@ -17,32 +17,35 @@ Last year, a routine deploy took down production for two hours. An engineer ran
 
 The postmortem was predictable: "improve the wrapper's context handling." But here's the uncomfortable truth - that wrapper shouldn't have existed in its current form. It was solving a problem that didn't warrant the complexity, and the abstraction itself became the attack surface.
 
-This isn't an isolated story. Platform teams love building internal CLIs, and I've built several myself. Some genuinely improved developer experience: hiding multi-step complexity, enforcing standards, preventing the kind of mistakes that page you at 3am. Others became maintenance nightmares that lagged behind upstream releases, broke in subtle ways, and required developers to learn both the wrapper __and__ the underlying tool to troubleshoot problems.
+This isn't an isolated story. Platform teams love building internal CLIs, and I've built several myself. Some genuinely improved developer experience: hiding multi-step complexity, enforcing standards, preventing the kind of mistakes that page you at 3am. Others became maintenance nightmares that lagged behind upstream releases, broke in subtle ways, and required developers to learn both the wrapper _and_ the underlying tool to troubleshoot problems.
 
-The question isn't whether you __can__ build a wrapper - it's whether you __should__. And if you do, how do you build it in a way that doesn't become a liability?
+<Highlighter>The question isn't whether you _can_ build a wrapper - it's whether you _should_.</Highlighter> And if you do, how do you build it in a way that doesn't become a liability?
 
 ## When Wrappers Genuinely Add Value
 
 Not all wrappers are created equal. Some genuinely earn their maintenance cost; others are solutions looking for problems. Here's what separates the valuable from the wasteful:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Complexity hiding",
-      text: "is the strongest justification. When a workflow requires five or more manual steps with dependencies and ordering constraints, a wrapper reduces cognitive load and enforces the correct sequence. A `deploy-service` command that builds, pushes, runs helm upgrade, and executes smoke tests in the right order prevents the \"I forgot to push the image before deploying\" class of errors.",
+      text: "The strongest justification. When a workflow requires five or more manual steps with dependencies and ordering constraints, a wrapper reduces cognitive load and enforces the correct sequence. A `deploy-service` command that builds, pushes, runs helm upgrade, and executes smoke tests in the right order prevents the \"I forgot to push the image before deploying\" class of errors.",
     },
     {
       lead: "Guard rails",
-      text: "prevent dangerous operations. A `kubectl-safe` wrapper that blocks `delete` in production without an approval ticket prevents the kind of outages that make the news. This works when the underlying tool allows dangerous operations with severe consequences and the policy can be codified clearly.",
+      text: "Prevents dangerous operations. A `kubectl-safe` wrapper that blocks `delete` in production without an approval ticket prevents the kind of outages that make the news. This works when the underlying tool allows dangerous operations with severe consequences and the policy can be codified clearly.",
     },
     {
       lead: "Context injection",
-      text: "automatically selects environment-specific configuration. A terraform wrapper that auto-selects workspace, backend, and var files based on your git branch eliminates \"I thought I was in staging\" mistakes - but only if it shows you what it detected. Silent context switching is how you get production outages.",
+      text: "Automatically selects environment-specific configuration. A terraform wrapper that auto-selects workspace, backend, and var files based on your git branch eliminates \"I thought I was in staging\" mistakes - but only if it shows you what it detected. Silent context switching is how you get production outages.",
     },
     {
       lead: "Credential management",
-      text: "handles authentication complexity transparently. A kubectl wrapper that auto-refreshes tokens and selects the correct cluster config reduces auth friction when tokens expire frequently and manual credential management is error-prone.",
+      text: "Handles authentication complexity transparently. A kubectl wrapper that auto-refreshes tokens and selects the correct cluster config reduces auth friction when tokens expire frequently and manual credential management is error-prone.",
     },
   ]}
 />
@@ -54,7 +57,8 @@ Some "problems" have simpler solutions. Alias collections - just shorter names f
 Before building, ask these questions honestly:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Wrapper decision criteria.",
     thead: {
@@ -89,6 +93,8 @@ Each "no" is a signal that better docs, shell aliases, or lightweight scripts wi
 
 If you've decided a wrapper is worth building, the core principle is __transparency__: your wrapper should add value without hiding what's happening. Developers should always be able to see the underlying commands, bypass the wrapper when needed, and use their existing tool knowledge.
 
+<Newsletter />
+
 The transparent wrapper pattern treats the underlying tool as the source of truth. The wrapper adds hooks for context injection, guard rails, and logging, but everything it doesn't explicitly handle passes through unchanged. Unknown flags? Pass them through. New subcommands? Pass them through. The wrapper should __never__ be the reason a valid command fails.
 
 <Callout type="info">
@@ -99,15 +105,13 @@ Two features are essential. First, `--wrapper-debug` shows exactly what command
 
 Notice what a transparent wrapper __doesn't__ do: it doesn't parse kubectl's output, it doesn't assume specific flag formats, and it doesn't try to interpret what the user is doing beyond the minimum needed for guard rails. This restraint is what makes it maintainable. When kubectl adds a new flag in version 1.32, the wrapper doesn't need to change - the flag passes through automatically.
 
-<Newsletter />
-
 ### Context Injection Done Right
 
 Earlier I mentioned context injection as a legitimate use case - auto-selecting environment configs based on git branch or directory. But this is also where wrappers most often go wrong. Remember the `tf-deploy` incident? The rule is simple: __always show the injected context, never hide it__.
 
 A kubectl wrapper that silently switches to production because you're on the `main` branch is a disaster waiting to happen. A wrapper that __shows__ you it detected production context and asks for confirmation? That's genuinely useful.
 
-```text title="context-display-example.txt"
+```bash
 ┌─────────────────────────────────────┐
 │ Environment: production             │
 │ Cluster:     prod-us-east-1         │
@@ -120,22 +124,30 @@ Output: Context display before destructive operations.
 The detection hierarchy should be predictable and documented:
 
 <List
-  variant="numbered-with-background-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: "Explicit flags (`--context=prod`)",
+      lead: 'Explicit flags',
+      text: '<span class="font-mono">--context=prod</span>',
     },
     {
-      text: "Environment variables (`DEPLOY_ENV=staging`)",
+      lead: 'Environment variables',
+      text: '<span class="font-mono">DEPLOY_ENV=staging</span>',
     },
     {
-      text: "Git branch detection (`main` → production)",
+      lead: 'Git branch detection',
+      text: '<span class="font-mono">main</span> → production',
     },
     {
-      text: "Directory structure (`/environments/dev/`)",
+      lead: 'Directory structure',
+      text: '<span class="font-mono">/environments/dev/</span>',
     },
     {
-      text: "Default fallback (usually dev)",
+      lead: 'Default fallback',
+      text: 'Usually dev',
     },
   ]}
 />
@@ -147,27 +159,30 @@ And when context is injected automatically, don't override explicit user flags -
 Wrappers often fail gradually. Usage stays high because it's in deployment scripts, but developers increasingly bypass it for anything complex. Here's how to catch the decline early:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-18 mb-6",
+  }}
   items={[
     {
       lead: "Bypass rate above 20%",
-      text: "means developers don't trust the wrapper for real work. They're using the \"safe\" path for routine operations but dropping to raw tools when it matters.",
+      text: "Means developers don't trust the wrapper for real work. They're using the \"safe\" path for routine operations but dropping to raw tools when it matters.",
     },
     {
       lead: "Support tickets mention the wrapper",
-      text: "more than the underlying tool. If \"tf-deploy\" appears in more tickets than \"terraform,\" your abstraction is creating problems instead of solving them.",
+      text: "More than the underlying tool. If \"tf-deploy\" appears in more tickets than \"terraform,\" your abstraction is creating problems instead of solving them.",
     },
     {
       lead: "Developers ask \"what command is this actually running?\"",
-      text: "for basic operations. Transparency has failed - they can't predict what the wrapper does.",
+      text: "For basic operations. Transparency has failed - they can't predict what the wrapper does.",
     },
     {
       lead: "You're more than one major version behind",
-      text: "the upstream tool. You can't track releases, and the gap will only widen.",
+      text: "The upstream tool. You can't track releases, and the gap will only widen.",
     },
     {
       lead: "New team members learn the raw tool first",
-      text: "because the wrapper's behavior is too unpredictable. Your \"simplification\" made things more complex.",
+      text: "Because the wrapper's behavior is too unpredictable. Your \"simplification\" made things more complex.",
     },
   ]}
 />
@@ -177,7 +192,8 @@ Wrappers often fail gradually. Usage stays high because it's in deployment scrip
 Set up tracking before problems become crises:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Wrapper health indicators.",
     thead: {
diff --git a/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/pdf.mdx b/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/pdf.mdx
index 7706b0bc0..8af63a9bf 100644
--- a/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/pdf.mdx
+++ b/src/content/articles/internal-cli-kubectl-terraform-wrapper-abstraction/pdf.mdx
@@ -10,51 +10,48 @@ featured: true
 ---
 
 *[CLI]: Command Line Interface
-*[API]: Application Programming Interface
-*[SDK]: Software Development Kit
-*[UX]: User Experience
 *[DX]: Developer Experience
-*[RBAC]: Role-Based Access Control
 *[HCL]: HashiCorp Configuration Language
-*[CI]: Continuous Integration
-*[CD]: Continuous Deployment
+*[RBAC]: Role-Based Access Control
+*[SDK]: Software Development Kit
+*[UX]: User Experience
 
-Platform teams love building internal CLIs. I've built several myself - wrappers around kubectl, terraform, helm, and various deployment pipelines. Some of these genuinely improved developer experience: hiding multi-step complexity, enforcing standards, preventing the kind of mistakes that page you at 3am. Others became maintenance nightmares that lagged behind upstream releases, broke in subtle ways, and required developers to learn both the wrapper __and__ the underlying tool to troubleshoot problems.
+Platform teams love building internal CLIs. I've built several myself - wrappers around kubectl, terraform, helm, and various deployment pipelines. Some of these genuinely improved developer experience: hiding multi-step complexity, enforcing standards, preventing the kind of mistakes that page you at 3am. Others became maintenance nightmares that lagged behind upstream releases, broke in subtle ways, and required developers to learn both the wrapper _and_ the underlying tool to troubleshoot problems.
 
 The pattern is predictable. A platform team builds `deploy-cli` that wraps kubectl and helm. Initially, it's simpler than raw commands - developers type `deploy-cli push myapp` instead of a 12-step sequence. Everyone's happy. Then Kubernetes releases a new feature. Helm updates its flag syntax. The CLI needs updates, but the original author moved to a different team. Developers hit cryptic errors. They start bypassing the CLI. Within a year, the wrapper is abandonware that everyone works around, but nobody removes because "someone might be using it."
 
-I've seen this cycle repeat across multiple organizations. The question isn't whether you __can__ build a wrapper - it's whether you __should__, and if you do, how to build it in a way that doesn't become a liability. This article covers when wrappers genuinely add value, how to design them for transparency and maintainability, the real cost of keeping them healthy, and how to recognize when it's time to deprecate.
-
 <Callout type="warning">
 The bar for building a wrapper CLI should be high. Every abstraction layer you add is a maintenance commitment. If the underlying tool's UX is good enough with documentation and templates, don't wrap it - improve the docs instead.
 </Callout>
 
+I've seen this cycle repeat across multiple organizations. The question isn't whether you _can_ build a wrapper - it's whether you _should_, and if you do, how to build it in a way that doesn't become a liability. This article covers when wrappers genuinely add value, how to design them for transparency and maintainability, the real cost of keeping them healthy, and how to recognize when it's time to deprecate.
+
 ## When Wrappers Add Value
 
 Not all wrappers are created equal. Some genuinely earn their maintenance cost; others are solutions looking for problems. Here's what separates the valuable from the wasteful:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Complexity hiding",
-      text: "is the strongest justification. When a workflow requires five or more manual steps with dependencies and ordering constraints, a wrapper reduces cognitive load and enforces the correct sequence. A `deploy-service` command that builds, pushes, runs helm upgrade, and executes smoke tests in the right order prevents the \"I forgot to push the image before deploying\" class of errors. The key criterion: errors in the sequence cause significant problems, not just minor inconvenience.",
+      text: 'The strongest justification. When a workflow requires five or more manual steps with dependencies and ordering constraints, a wrapper reduces cognitive load and enforces the correct sequence. A <span class="font-mono">deploy-service</span> command that builds, pushes, runs helm upgrade, and executes smoke tests in the right order prevents the "I forgot to push the image before deploying" class of errors. The key criterion: errors in the sequence cause significant problems, not just minor inconvenience.',
     },
     {
       lead: "Guard rails",
-      text: "prevent dangerous operations or enforce policies. A `kubectl-safe` wrapper that blocks `delete` in production without an approval ticket prevents the kind of outages that make the news. This works when the underlying tool allows dangerous operations with severe consequences and the policy can be codified clearly. Don't create security theater - if you can't actually prevent the dangerous operation, don't pretend you can.",
+      text: 'Prevent dangerous operations or enforce policies. A <span class="font-mono">kubectl-safe</span> wrapper that blocks <span class="font-mono">delete</span> in production without an approval ticket prevents the kind of outages that make the news. This works when the underlying tool allows dangerous operations with severe consequences and the policy can be codified clearly. Don\'t create security theater - if you can\'t actually prevent the dangerous operation, don\'t pretend you can.',
     },
     {
       lead: "Context injection",
-      text: "automatically selects environment-specific configuration. A terraform wrapper that auto-selects workspace, backend, and var files based on your git branch or directory eliminates \"I thought I was in staging\" mistakes. This is valuable when you have multiple environments with different configs and mixing them up causes real problems - data corruption, customer impact, compliance violations.",
+      text: 'Automatically selects environment-specific configuration. A <span class="font-mono">terraform</span> wrapper that auto-selects <span class="font-mono">workspace</span>, <span class="font-mono">backend</span>, and <span class="font-mono">var</span> files based on your git branch or directory eliminates "I thought I was in staging" mistakes. This is valuable when you have multiple environments with different configs and mixing them up causes real problems - data corruption, customer impact, compliance violations.',
     },
     {
       lead: "Credential management",
-      text: "handles authentication complexity transparently. A kubectl wrapper that auto-refreshes tokens and selects the correct cluster config reduces auth friction. This makes sense when auth involves multiple systems, tokens expire frequently, and manual credential management is error-prone.",
+      text: 'Handles authentication complexity transparently. A <span class="font-mono">kubectl</span> wrapper that auto-refreshes tokens and selects the correct cluster config reduces auth friction. This makes sense when auth involves multiple systems, tokens expire frequently, and manual credential management is error-prone.',
     },
     {
       lead: "Audit logging",
-      text: "captures all operations for compliance and debugging. A terraform wrapper that logs who ran what commands when helps with incident investigation and change tracking. Worth building when audit requirements exist and the underlying tool doesn't provide adequate logging.",
+      text: 'Captures all operations for compliance and debugging. A <span class="font-mono">terraform</span> wrapper that logs who ran what commands when helps with incident investigation and change tracking. Worth building when audit requirements exist and the underlying tool doesn\'t provide adequate logging.',
     },
   ]}
 />
@@ -64,19 +61,19 @@ Not all wrappers are created equal. Some genuinely earn their maintenance cost;
 Some "wrappers" solve problems that have simpler solutions:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Alias collections",
-      text: "- just shorter names for common commands - belong in your shell config, not a distributed tool. `k` instead of `kubectl` is a shell alias, not a wrapper.",
+      text: 'Shorter names for common commands belong in your shell config, not a distributed tool. <span class="font-mono">k</span> instead of <span class="font-mono">kubectl</span> is a shell alias, not a wrapper.',
     },
     {
       lead: "Hardcoded flag defaults",
-      text: "are better handled by config files or environment variables. A wrapper that always sets `--replicas=3` is inflexible and hides what's happening.",
+      text: 'Better handled by config files or environment variables. A wrapper that always sets <span class="font-mono">--replicas=3</span> is inflexible and hides what\'s happening.',
     },
     {
       lead: "Output formatting",
-      text: "is a solved problem. Pretty-printing kubectl output? Use `kubectl` plugins, `jq`, or the many existing tools in the ecosystem.",
+      text: 'A solved problem. Pretty-printing kubectl output? Use <span class="font-mono">kubectl</span> plugins, <span class="font-mono">jq</span>, or the many existing tools in the ecosystem.',
     },
   ]}
 />
@@ -86,7 +83,11 @@ Some "wrappers" solve problems that have simpler solutions:
 Before you start writing code, run through these questions honestly. Each "no" is a signal that the simpler path - better docs, shell aliases, or lightweight scripts - will serve you better than a full wrapper. Each "yes" adds weight to the case for building, but also adds to your maintenance commitment.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Wrapper decision criteria.",
     thead: {
@@ -366,27 +367,30 @@ Guard rails are the second high-value wrapper feature. The idea is simple: inter
 The most valuable guard rails prevent operations that are both __easy to trigger accidentally__ and __hard to recover from__. For kubectl, that means:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Namespace deletion",
-      text: "in production or staging - a single command can wipe out an entire service",
+      text: "In production or staging, a single command can wipe out an entire service",
     },
     {
       lead: "Bulk deletion",
-      text: "with `--all` flags - too easy to delete more than intended",
+      text: 'Using <span class="font-mono">--all</span> flags, it becomes too easy to delete more than intended',
     },
     {
       lead: "Direct edits",
-      text: "to deployments, statefulsets, or daemonsets - causes drift from GitOps state",
+      text: 'To <span class="font-mono">deployments</span>, <span class="font-mono">statefulsets</span>, or <span class="font-mono">daemonsets</span> causes drift from GitOps state',
     },
     {
       lead: "Interactive shells",
-      text: "in production without audit logging - compliance nightmare",
+      text: "In production without audit logging are a compliance nightmare",
     },
     {
       lead: "Scaling to zero",
-      text: "- blocks all traffic, and developers sometimes do this thinking it's a \"safe\" way to test",
+      text: "Blocks all traffic, and developers sometimes do this thinking it's a \"safe\" way to test",
     },
   ]}
 />
@@ -394,23 +398,26 @@ The most valuable guard rails prevent operations that are both __easy to trigger
 For terraform, the high-risk operations are:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Destroy",
-      text: "in production - obvious, but worth blocking anyway",
+      text: "In production - obvious, but worth blocking anyway",
     },
     {
       lead: "Auto-approve",
-      text: "in production or staging - bypasses plan review",
+      text: "In production or staging - bypasses plan review",
     },
     {
       lead: "State manipulation",
-      text: "(rm, mv, push) - can corrupt state and cause resource orphaning",
+      text: '(<span class="font-mono">rm</span>, <span class="font-mono">mv</span>, <span class="font-mono">push</span>) - can corrupt state and cause resource orphaning',
     },
     {
       lead: "Import",
-      text: "without review - can corrupt state if done wrong",
+      text: "Without review - can corrupt state if done wrong",
     },
   ]}
 />
@@ -425,25 +432,28 @@ Every blocked operation needs an override. The override should:
 
 <List
   variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Require explicit acknowledgment",
-      text: "- not just a `--force` flag, but something that makes the user stop and think",
+      text: 'Not just a <span class="font-mono">--force` flag, but something that makes the user stop and think',
     },
     {
       lead: "Create an audit trail",
-      text: "- log who overrode the rule, when, and why",
+      text: "Log who overrode the rule, when, and why",
     },
     {
       lead: "Reference external authorization",
-      text: "- a ticket number, a change management ID, or a reviewer's approval",
+      text: "A ticket number, a change management ID, or a reviewer's approval",
     },
   ]}
 />
 
 A good block message looks like this:
 
-```text
+```bash
 BLOCKED: Namespace deletion requires manual approval
 
 Command: kubectl delete namespace payments
@@ -453,14 +463,20 @@ To proceed: Use --force-delete with ticket number
 Example: kube delete namespace payments --force-delete=TICKET-123
 ```
 
-The user knows __why__ it's blocked, __how__ to proceed if necessary, and the ticket number creates accountability.
+Code: Example guard rail block message with override instructions.
+
+The user knows _why_ it's blocked, _how_ to proceed if necessary, and the ticket number creates accountability.
 
 ### Environment-Specific Rules
 
 Not every guard rail applies everywhere. Blocking `terraform destroy` in production makes sense; blocking it in dev is just friction. Design your rules with environment awareness:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Environment-specific guard rail configuration.",
     thead: {
@@ -518,23 +534,23 @@ The most common wrapper failure mode is silent breakage. A new kubectl version c
 Your test suite needs to catch this. Use nox or tox to run your pytest suite against multiple tool versions. The key tests:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
   items={[
     {
       lead: "Passthrough verification",
-      text: "- Unknown flags should reach the underlying tool unchanged. New versions may add flags your wrapper doesn't know about, and they should work.",
+      text: "Unknown flags should reach the underlying tool unchanged. New versions may add flags your wrapper doesn't know about, and they should work.",
     },
     {
       lead: "Output preservation",
-      text: "- If kubectl's output format changes, your wrapper shouldn't break. Don't parse output unless absolutely necessary, and if you do, test against multiple versions.",
+      text: "If kubectl's output format changes, your wrapper shouldn't break. Don't parse output unless absolutely necessary, and if you do, test against multiple versions.",
     },
     {
       lead: "Complex argument handling",
-      text: "- JSONPath expressions, label selectors, and other complex arguments are easy to mangle. Test that `kube get pods -o jsonpath='{.items[*].metadata.name}'` passes through exactly as written.",
+      text: 'JSONPath expressions, label selectors, and other complex arguments are easy to mangle. Test that <span class="font-mono">kube get pods -o jsonpath=\'{ .items[*].metadata.name }\'</span> passes through exactly as written.',
     },
     {
       lead: "Guard rail accuracy",
-      text: "- Your blocked patterns should match what you intend to block, no more, no less. Test both positive cases (this should be blocked) and negative cases (this should be allowed).",
+      text: "Your blocked patterns should match what you intend to block, no more, no less. Test both positive cases (this should be blocked) and negative cases (this should be allowed).",
     },
   ]}
 />
@@ -546,7 +562,8 @@ Run this test matrix in CI on every PR, and run it against new upstream versions
 Be honest about what you're signing up for:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Wrapper maintenance commitments.",
     thead: {
@@ -675,15 +692,15 @@ The same Markdown source generates your README, your wiki page, and your man pag
 For internal tools, you have several options depending on your organization's infrastructure:
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
   items={[
     {
       lead: "Internal PyPI",
-      text: "- If you have an internal package index (Artifactory, CodeArtifact, a simple pypiserver), publish there. Users install with `pip install kube-wrapper --index-url https://pypi.internal.company.com/simple`. This works well for Python shops and handles dependencies automatically.",
+      text: 'If you have an internal package index (Artifactory, CodeArtifact, a simple pypiserver), publish there. Users install with <span class="font-mono">pip install kube-wrapper --index-url https://pypi.internal.company.com/simple</span>. This works well for Python shops and handles dependencies automatically.',
     },
     {
       lead: "Homebrew tap",
-      text: "- For macOS and Linux users, a private Homebrew tap provides a familiar installation experience. Create a tap repository with a formula that downloads your release tarball:",
+      text: "For macOS and Linux users, a private Homebrew tap provides a familiar installation experience. Create a tap repository with a formula that downloads your release tarball:",
     },
   ]}
 />
@@ -703,7 +720,7 @@ end
 ```
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
   items={[
     {
       lead: "Direct download",
@@ -711,7 +728,7 @@ end
     },
     {
       lead: "Container image",
-      text: "- For CI/CD pipelines or teams that prefer containers, publish an image with your wrapper pre-installed alongside kubectl/terraform. Users run `docker run company/kube-wrapper get pods`.",
+      text: 'For CI / CD pipelines or teams that prefer containers, publish an image with your wrapper pre-installed alongside <span class="font-mono">kubectl</span> / <span class="font-mono">terraform</span>. Users run <span class="font-mono">docker run company/kube-wrapper get pods</span>.',
     },
   ]}
 />
@@ -743,7 +760,7 @@ Here's how to recognize the warning signs early.
 ### Red Flags
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Developers bypass the wrapper.",
@@ -771,7 +788,8 @@ Here's how to recognize the warning signs early.
 If you want to be rigorous about wrapper health, track these metrics:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Wrapper health indicators.",
     thead: {
@@ -781,19 +799,19 @@ If you want to be rigorous about wrapper health, track these metrics:
       tr: [
         {
           th: "Adoption rate",
-          td: ["&gt;80% of commands through wrapper", "50-80%", "&lt;50%"],
+          td: ["&gt; 80% of commands through wrapper", "50-80%", "&lt; 50%"],
         },
         {
           th: "Bypass rate",
-          td: ["&lt;5% use --bypass", "5-20%", "&gt;20%"],
+          td: ["&lt; 5% use --bypass", "5-20%", "&gt; 20%"],
         },
         {
           th: "Update lag",
-          td: ["Within 1 week of upstream", "1-4 weeks", "&gt;4 weeks"],
+          td: ["Within 1 week of upstream", "1-4 weeks", "&gt; 4 weeks"],
         },
         {
           th: "Bug reports",
-          td: ["&lt;1 per month", "1-4 per month", "&gt;4 per month"],
+          td: ["&lt; 1 per month", "1-4 per month", "&gt; 4 per month"],
         },
       ],
     },
@@ -823,16 +841,16 @@ When it's time to sunset a wrapper, do it gracefully. A sudden removal leaves us
 ### The Four-Phase Sunset
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Phase 1: Announcement (30 days).",
-      text: "Show a deprecation notice on every wrapper invocation. Be specific about the timeline and provide a link to migration documentation. The notice should explain _why_ you're deprecating, not just _when_.",
+      text: "Show a deprecation notice on every wrapper invocation. Be specific about the timeline and provide a link to migration documentation. The notice should explain <em>why</em>you're deprecating, not just <em>when</em>.",
     },
   ]}
 />
 
-```text
+```bash
 ╔══════════════════════════════════════════════════════════════════╗
 ║  DEPRECATION NOTICE: kube wrapper will be retired in 90 days     ║
 ║                                                                  ║
@@ -841,9 +859,11 @@ When it's time to sunset a wrapper, do it gracefully. A sudden removal leaves us
 ║  Questions: #platform-support                                    ║
 ╚══════════════════════════════════════════════════════════════════╝
 ```
+Code: Example deprecation notice shown on wrapper invocation.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  startNumber={2}
   items={[
     {
       lead: "Phase 2: Migration assistance (60 days).",
@@ -851,7 +871,7 @@ When it's time to sunset a wrapper, do it gracefully. A sudden removal leaves us
     },
     {
       lead: "Phase 3: Opt-in only (30 days).",
-      text: "Flip the default. The wrapper no longer runs unless users explicitly enable it with a flag like `--use-wrapper`. Most users will have migrated by now; this phase catches the stragglers and forces anyone still dependent to acknowledge it.",
+      text: 'Flip the default. The wrapper no longer runs unless users explicitly enable it with a flag like <span class="font-mono">--use-wrapper</span>. Most users will have migrated by now; this phase catches the stragglers and forces anyone still dependent to acknowledge it.',
     },
     {
       lead: "Phase 4: Removal.",
@@ -863,7 +883,8 @@ When it's time to sunset a wrapper, do it gracefully. A sudden removal leaves us
 The migration guide is the most important artifact. For each wrapper feature, document the native alternative:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Wrapper feature alternatives.",
     thead: {
@@ -873,7 +894,7 @@ The migration guide is the most important artifact. For each wrapper feature, do
       tr: [
         {
           th: "Auto-context selection",
-          td: ["`kubectl config use-context` or kubie"],
+          td: ['<span class="font-mono">kubectl config use-context</span> or kubie'],
         },
         {
           th: "Production confirmation",
@@ -885,7 +906,7 @@ The migration guide is the most important artifact. For each wrapper feature, do
         },
         {
           th: "Command shortcuts",
-          td: ["Shell aliases in ~/.bashrc or ~/.zshrc"],
+          td: ['Shell aliases in <span class="font-mono">~/.bashrc</span> or <span class="font-mono">~/.zshrc</span>'],
         },
       ],
     },
@@ -904,8 +925,8 @@ Most internal CLI wrappers shouldn't exist. Before building one, exhaust the alt
 
 But when wrappers __are__ worth building - for genuine complexity hiding, meaningful guard rails, or critical context injection - build them well. Design for transparency: pass through unknown flags, show underlying commands, provide bypass modes. Commit to ongoing maintenance. Monitor adoption and bypass rates to catch problems early. And build with eventual deprecation in mind - the best outcome is retirement because the ecosystem caught up or your team outgrew the need.
 
-The goal isn't to build a wrapper that lasts forever. It's to build one that serves its purpose, helps your team work safely, and steps aside gracefully when it's no longer needed.
-
 <Callout type="success">
 A successful wrapper eventually gets deprecated - not because it failed, but because users learned the underlying tool and the ecosystem caught up. Build wrappers with their eventual retirement in mind. The goal is empowerment, not dependence.
 </Callout>
+
+The goal isn't to build a wrapper that lasts forever. It's to build one that serves its purpose, helps your team work safely, and steps aside gracefully when it's no longer needed.
diff --git a/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx b/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx
index 228eb355f..1023ecb17 100644
--- a/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx
+++ b/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx
@@ -18,12 +18,12 @@ And yet the outcome was identical to not having a portal at all - the same ticke
 
 That's the portal-versus-platform distinction that trips up most organizations. A portal __indexes__ things: it aggregates links, surfaces documentation, shows who owns what. A platform __does__ things: it provisions infrastructure, creates repositories, grants access. The portal tells you how to request a database. The platform gives you a database.
 
-Self-service actions are what transform a directory into a platform. Without them, you've built a prettier wiki.
-
 <Callout type="warning">
 If your "platform" requires developers to read documentation and file tickets to get things done, you've built a directory, not a platform. Platforms execute workflows. Directories point to workflows that humans execute.
 </Callout>
 
+Self-service actions are what transform a directory into a platform. Without them, you've built a prettier wiki.
+
 ## The Portal Maturity Model
 
 Most internal developer portals evolve through predictable stages. Understanding where you are helps clarify where to invest next - and where most organizations get stuck.
diff --git a/src/styles/code-highlighting/general.css b/src/styles/code-highlighting/general.css
index a7286b02a..a11bd4626 100644
--- a/src/styles/code-highlighting/general.css
+++ b/src/styles/code-highlighting/general.css
@@ -11,6 +11,11 @@
  * We keep line numbers in a fixed gutter so wrapped lines align under the code,
  * not under the line number column.
  */
+pre.shiki {
+  overflow-x: hidden;
+  overflow-y: hidden;
+}
+
 pre.shiki code {
   counter-increment: step calc(var(--start, 1) - 1);
   counter-reset: step;

From 590efff8cabc65274b9f0f6882affc7a1487371c Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Mon, 16 Mar 2026 23:46:34 +0300
Subject: [PATCH 06/15] Final pass
 internal-developer-portal-platform-self-service-actions article

---
 _TODO.md                                      |   1 +
 .../index.mdx                                 |  39 +++--
 .../pdf.mdx                                   | 135 +++++++++---------
 3 files changed, 90 insertions(+), 85 deletions(-)

diff --git a/_TODO.md b/_TODO.md
index 0b606f0fc..bdd845abe 100644
--- a/_TODO.md
+++ b/_TODO.md
@@ -307,6 +307,7 @@ src/content/articles/internal-developer-portal-platform-self-service-actions/pdf
 />
 
 <List
+  startNumber={2}
   classes={{
     wrapper: "sm:ml-6 sm:mr-12 mb-6",
   }}
diff --git a/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx b/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx
index 1023ecb17..8449ba987 100644
--- a/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx
+++ b/src/content/articles/internal-developer-portal-platform-self-service-actions/index.mdx
@@ -16,20 +16,23 @@ Last month I watched a developer spend three days getting a PostgreSQL database.
 
 And yet the outcome was identical to not having a portal at all - the same tickets, the same meetings, the same waiting.
 
-That's the portal-versus-platform distinction that trips up most organizations. A portal __indexes__ things: it aggregates links, surfaces documentation, shows who owns what. A platform __does__ things: it provisions infrastructure, creates repositories, grants access. The portal tells you how to request a database. The platform gives you a database.
+That's the portal-versus-platform distinction that trips up most organizations. A portal _indexes_ things: it aggregates links, surfaces documentation, shows who owns what. A platform _does_ things: it provisions infrastructure, creates repositories, grants access. The portal tells you how to request a database. The platform gives you a database.
+
+<Highlighter>Self-service actions are what transform a directory into a platform.</Highlighter> Without them, you've built a prettier wiki.
 
 <Callout type="warning">
 If your "platform" requires developers to read documentation and file tickets to get things done, you've built a directory, not a platform. Platforms execute workflows. Directories point to workflows that humans execute.
 </Callout>
 
-Self-service actions are what transform a directory into a platform. Without them, you've built a prettier wiki.
-
 ## The Portal Maturity Model
 
 Most internal developer portals evolve through predictable stages. Understanding where you are helps clarify where to invest next - and where most organizations get stuck.
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Level 1: Directory.",
@@ -51,7 +54,11 @@ Most internal developer portals evolve through predictable stages. Understanding
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Portal maturity levels.",
     thead: {
@@ -158,7 +165,7 @@ The YAML is straightforward, but the design decisions matter. Notice the sensibl
 Five principles separate good actions from frustrating ones.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Obvious outcomes.",
@@ -191,24 +198,28 @@ The best self-service actions feel like filling out a form to order something on
 
 Approvals are where self-service platforms regress into ticket systems. The instinct is understandable - production changes are risky, expensive resources need oversight, compliance requires audit trails. But if every request routes through a manual approval queue, you've just built Jira with a different skin.
 
-The solution is __policy-based approval routing__: define rules that auto-approve low-risk requests while routing high-risk ones to the right approvers. Most requests should flow through automatically. Approvals become the exception, not the rule.
+The solution is _policy-based approval routing_: define rules that auto-approve low-risk requests while routing high-risk ones to the right approvers. Most requests should flow through automatically. Approvals become the exception, not the rule.
 
 The dimensions that typically matter:
 
 <List
-  variant="check-icons-list"
+  variant="badge-list"
+  classes={{
+    titleClass: "block w-full text-center",
+    wrapper: "sm:ml-2 mb-6",
+  }}
   items={[
     {
-      lead: "Environment-based:",
-      text: "dev auto-approves, production needs sign-off",
+      title: "Environment-based:",
+      lead: "Dev auto-approves, production needs sign-off",
     },
     {
-      lead: "Cost-based:",
-      text: "under $100/month auto-approves, over $500 needs finance",
+      title: "Cost-based:",
+      lead: "Under $100/month auto-approves, over $500 needs finance",
     },
     {
-      lead: "Risk-based:",
-      text: "standard operations auto-approve, IAM changes need security review",
+      title: "Risk-based:",
+      lead: "Standard operations auto-approve, IAM changes need security review",
     },
   ]}
 />
diff --git a/src/content/articles/internal-developer-portal-platform-self-service-actions/pdf.mdx b/src/content/articles/internal-developer-portal-platform-self-service-actions/pdf.mdx
index 983905c6b..4880eeca9 100644
--- a/src/content/articles/internal-developer-portal-platform-self-service-actions/pdf.mdx
+++ b/src/content/articles/internal-developer-portal-platform-self-service-actions/pdf.mdx
@@ -12,30 +12,33 @@ featured: true
 import multiStepDiagram from "./diagrams/multi-step-service-creation-workflow.jpg"
 
 *[IDP]: Internal Developer Portal/Platform
-*[RBAC]: Role-Based Access Control
-*[SSO]: Single Sign-On
 *[K8s]: Kubernetes
 *[PR]: Pull Request
+*[RBAC]: Role-Based Access Control
 *[SLA]: Service Level Agreement
+*[SSO]: Single Sign-On
 
 Last month I watched a developer spend three days getting a PostgreSQL database. The company had a beautiful internal developer portal - Backstage, fully themed, comprehensive service catalog, scorecards showing tech debt metrics. The developer found the "Database Provisioning" page in under 30 seconds. Then he read the instructions: file a Jira ticket with the DBA team, wait for triage, attend a 15-minute review meeting to justify the request, and receive credentials via a separate ticket once provisioning completed. Three to five business days, assuming no holidays or sick leave on the DBA team.
 
 The portal worked perfectly. The developer knew exactly where to go and what to do. And yet the outcome was identical to not having a portal at all - the same tickets, the same meetings, the same waiting.
 
-That's the portal-versus-platform distinction that trips up most organizations. A portal __indexes__ things: it aggregates links, surfaces documentation, shows who owns what. A platform __does__ things: it provisions infrastructure, creates repositories, grants access. The portal tells you how to request a database. The platform gives you a database.
-
-The difference matters because it determines whether your internal developer platform actually reduces toil or just makes toil easier to find. Self-service actions are what transform a directory into a platform. Without them, you've built a prettier wiki.
+That's the portal-versus-platform distinction that trips up most organizations. A portal _indexes_ things: it aggregates links, surfaces documentation, shows who owns what. A platform _does_ things: it provisions infrastructure, creates repositories, grants access. The portal tells you how to request a database. The platform gives you a database.
 
 <Callout type="warning">
 If your "platform" requires developers to read documentation and file tickets to get things done, you've built a directory, not a platform. Platforms execute workflows. Directories point to workflows that humans execute.
 </Callout>
 
+The difference matters because it determines whether your internal developer platform actually reduces toil or just makes toil easier to find. Self-service actions are what transform a directory into a platform. Without them, you've built a prettier wiki.
+
 ## The Portal Maturity Model
 
 Most internal developer portals evolve through predictable stages. Understanding where you are helps clarify where to invest next - and where most organizations get stuck.
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Level 1: Directory.",
@@ -57,7 +60,11 @@ Most internal developer portals evolve through predictable stages. Understanding
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Portal maturity levels.",
     thead: {
@@ -179,7 +186,7 @@ The YAML is straightforward, but the design decisions matter. Notice the sensibl
 ### Action Design Guidelines
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Obvious outcomes.",
@@ -220,6 +227,7 @@ Consider what happens when a developer requests a new service. The portal valida
 
 <Diagram
   src={multiStepDiagram}
+  size="full"
   title="Multi-step service creation workflow."
   description='Sequence diagram showing a Developer submitting a "Create Service" action to the Platform, the Platform validating inputs + permissions, creating a repository and infrastructure PR through Git, receiving plan output from CI / CD, either auto-approving or waiting for approval before merging, then triggering apply, provisioning Infrastructure, storing credentials in Vault, and notifying the Developer when the service is ready.'
 />
@@ -251,27 +259,31 @@ The solution is __policy-based approval routing__: define rules that auto-approv
 Different situations warrant different approval requirements. Here are the dimensions that typically matter:
 
 <List
-  variant="check-icons-list"
+  variant="badge-list"
+  classes={{
+    titleClass: "block w-full text-center",
+    wrapper: "sm:ml-2 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      lead: "Environment-based.",
-      text: "Dev and staging requests auto-approve instantly. Production requests require team lead approval. This is the most common pattern and handles the majority of cases.",
+      title: "Environment-based:",
+      lead: "Dev and staging requests auto-approve instantly. Production requests require team lead approval. This is the most common pattern and handles the majority of cases.",
     },
     {
-      lead: "Cost-based.",
-      text: "Resources under $100/month auto-approve. Resources between $100-500 need team lead sign-off. Resources over $500 require team lead plus finance approval. Thresholds vary by organization, but the principle is consistent: more expensive means more oversight.",
+      title: "Cost-based:",
+      lead: "Resources under $100/month auto-approve. Resources between $100-500 need team lead sign-off. Resources over $500 require team lead plus finance approval. Thresholds vary by organization, but the principle is consistent: more expensive means more oversight.",
     },
     {
-      lead: "Scope-based.",
-      text: "Changes affecting only your own team auto-approve. Changes affecting multiple teams require approval from each affected team's lead. This prevents one team from unilaterally impacting another's infrastructure.",
+      title: "Scope-based:",
+      lead: "Changes affecting only your own team auto-approve. Changes affecting multiple teams require approval from each affected team's lead. This prevents one team from unilaterally impacting another's infrastructure.",
     },
     {
-      lead: "Risk-based.",
-      text: "Standard operations auto-approve. High-risk operations - deleting databases, modifying IAM permissions, changing network configs, rotating encryption keys - require security review regardless of environment.",
+      title: "Risk-based:",
+      lead: "Standard operations auto-approve. High-risk operations - deleting databases, modifying IAM permissions, changing network configs, rotating encryption keys - require security review regardless of environment.",
     },
     {
-      lead: "Time-based.",
-      text: "Normal business hours follow standard policies. Change freeze windows require explicit exception approval. This prevents well-meaning developers from deploying during critical periods.",
+      title: "Time-based:",
+      lead: "Normal business hours follow standard policies. Change freeze windows require explicit exception approval. This prevents well-meaning developers from deploying during critical periods.",
     },
   ]}
 />
@@ -281,7 +293,7 @@ These dimensions combine. A production database deletion during change freeze mi
 In Backstage, you'd implement these rules through a custom approval plugin or integrate with Open Policy Agent (OPA) for policy-as-code. The scaffolder evaluates the policy before executing steps, routing to the appropriate approval workflow or proceeding automatically based on the policy decision.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Approval types and SLAs.",
     thead: {
@@ -323,8 +335,12 @@ In Backstage, you'd implement these rules through a custom approval plugin or in
   }}
 />
 
+### Making Approvals Fast
+
+Even when manual approval is required, it shouldn't be slow. A few practices help:
+
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
   items={[
     {
       lead: "Give approvers context.",
@@ -344,36 +360,6 @@ In Backstage, you'd implement these rules through a custom approval plugin or in
     },
   ]}
 />
-
-### Making Approvals Fast
-
-Even when manual approval is required, it shouldn't be slow. A few practices help:
-
-<List
-  variant="check-icons-list"
-  items={[
-    {
-      lead: "Git providers",
-      text: "handle repository creation, pull request management, and team permissions. GitHub and GitLab are the common choices. The platform creates repos from templates, opens PRs for infrastructure changes, and manages who can access what. Authentication typically uses GitHub Apps or access tokens with appropriate scopes.",
-    },
-    {
-      lead: "Infrastructure provisioning",
-      text: "is where resources actually get created. Terraform Cloud (or Atlantis for self-hosted) handles the IaC workflow - creating workspaces, queuing plans and applies, reading state outputs. For direct resource creation, you need AWS/GCP/Azure SDK access via IAM roles or service accounts. Kubernetes clusters need ServiceAccount tokens for applying manifests and managing RBAC.",
-    },
-    {
-      lead: "Secrets management",
-      text: "stores and distributes credentials securely. HashiCorp Vault is the most common choice, using AppRole authentication for the platform to create secrets and generate dynamic credentials. AWS Secrets Manager is simpler if you're already AWS-native.",
-    },
-    {
-      lead: "Observability",
-      text: "integration means the platform can provision monitoring alongside infrastructure. Datadog or Prometheus for metrics, PagerDuty for alerting. When a new service is created, its dashboards and alerts should be created automatically - not added manually weeks later when someone remembers.",
-    },
-    {
-      lead: "Communication",
-      text: "enables notifications and interactive approvals. Slack integration with a bot token lets the platform send messages, create channels, and handle approval buttons directly in chat. Email provides fallback notifications.",
-    },
-  ]}
-/>
 <Callout type="info">
 Approvals should be the exception, not the rule. If most requests require manual approval, you haven't built self-service - you've built a ticket system with a nicer UI. Use policy-based auto-approval aggressively for low-risk operations.
 </Callout>
@@ -387,27 +373,27 @@ A self-service platform doesn't exist in isolation. It needs to talk to your Git
 Most platforms need integrations across five categories:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Git providers",
-      text: "handle repository creation, pull request management, and team permissions. GitHub and GitLab are the common choices. The platform creates repos from templates, opens PRs for infrastructure changes, and manages who can access what. Authentication typically uses GitHub Apps or access tokens with appropriate scopes.",
+      text: "Handles repository creation, pull request management, and team permissions. GitHub and GitLab are the common choices. The platform creates repos from templates, opens PRs for infrastructure changes, and manages who can access what. Authentication typically uses GitHub Apps or access tokens with appropriate scopes.",
     },
     {
       lead: "Infrastructure provisioning",
-      text: "is where resources actually get created. Terraform Cloud (or Atlantis for self-hosted) handles the IaC workflow - creating workspaces, queuing plans and applies, reading state outputs. For direct resource creation, you need AWS/GCP/Azure SDK access via IAM roles or service accounts. Kubernetes clusters need ServiceAccount tokens for applying manifests and managing RBAC.",
+      text: "Where resources actually get created. Terraform Cloud (or Atlantis for self-hosted) handles the IaC workflow - creating workspaces, queuing plans and applies, reading state outputs. For direct resource creation, you need AWS / GCP / Azure SDK access via IAM roles or service accounts. Kubernetes clusters need ServiceAccount tokens for applying manifests and managing RBAC.",
     },
     {
       lead: "Secrets management",
-      text: "stores and distributes credentials securely. HashiCorp Vault is the most common choice, using AppRole authentication for the platform to create secrets and generate dynamic credentials. AWS Secrets Manager is simpler if you're already AWS-native.",
+      text: "Stores and distributes credentials securely. HashiCorp Vault is the most common choice, using AppRole authentication for the platform to create secrets and generate dynamic credentials. AWS Secrets Manager is simpler if you're already AWS-native.",
     },
     {
       lead: "Observability",
-      text: "integration means the platform can provision monitoring alongside infrastructure. Datadog or Prometheus for metrics, PagerDuty for alerting. When a new service is created, its dashboards and alerts should be created automatically - not added manually weeks later when someone remembers.",
+      text: "Integration means the platform can provision monitoring alongside infrastructure. Datadog or Prometheus for metrics, PagerDuty for alerting. When a new service is created, its dashboards and alerts should be created automatically - not added manually weeks later when someone remembers.",
     },
     {
       lead: "Communication",
-      text: "enables notifications and interactive approvals. Slack integration with a bot token lets the platform send messages, create channels, and handle approval buttons directly in chat. Email provides fallback notifications.",
+      text: "Enables notifications and interactive approvals. Slack integration with a bot token lets the platform send messages, create channels, and handle approval buttons directly in chat. Email provides fallback notifications.",
     },
   ]}
 />
@@ -421,7 +407,10 @@ Each adapter declares its capabilities (what actions it can perform), implements
 This abstraction pays off when you need to swap providers. Moving from GitHub to GitLab, or from Terraform Cloud to Atlantis, becomes a configuration change rather than a rewrite of every action that touches those systems.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Common integration patterns.",
     thead: {
@@ -480,23 +469,23 @@ Building a platform is an investment - in tooling, integrations, and ongoing mai
 ### Metric Categories
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Adoption metrics",
-      text: "tell you whether developers are actually using the platform. Track the number of self-service actions executed, the percentage of the engineering org using actions, and the coverage of common tasks available as actions. Growing adoption means the platform is solving real problems. Flat or declining adoption means something's wrong - either discoverability, trust, or the actions themselves.",
+      text: "Tell you whether developers are actually using the platform. Track the number of self-service actions executed, the percentage of the engineering org using actions, and the coverage of common tasks available as actions. Growing adoption means the platform is solving real problems. Flat or declining adoption means something's wrong - either discoverability, trust, or the actions themselves.",
     },
     {
       lead: "Efficiency metrics",
-      text: "measure time savings. Compare time-to-provision before and after the platform: how long did it take to get a database via tickets versus via self-service? Track approval wait times. Measure what percentage of requests auto-approve versus requiring manual intervention. The goal is dramatic improvement - not 20% faster, but 95% faster.",
+      text: "Measure time savings. Compare time-to-provision before and after the platform: how long did it take to get a database via tickets versus via self-service? Track approval wait times. Measure what percentage of requests auto-approve versus requiring manual intervention. The goal is dramatic improvement - not 20% faster, but 95% faster.",
     },
     {
       lead: "Quality metrics",
-      text: "track whether the platform is reliable. Action success rate should be above 95% - if actions fail frequently, developers stop trusting them. Rollback rate indicates how often workflows fail partway through and need cleanup. Support ticket reduction shows whether the platform is actually offloading work from the platform team or just creating different work.",
+      text: "Track whether the platform is reliable. Action success rate should be above 95% - if actions fail frequently, developers stop trusting them. Rollback rate indicates how often workflows fail partway through and need cleanup. Support ticket reduction shows whether the platform is actually offloading work from the platform team or just creating different work.",
     },
     {
       lead: "Satisfaction metrics",
-      text: "capture developer perception. Net Promoter Score for the platform overall, ratings for individual actions, and satisfaction when escalation is needed. High efficiency with low satisfaction means the platform works but feels bad to use - maybe the UX is confusing or errors are frustrating.",
+      text: "Capture developer perception. Net Promoter Score for the platform overall, ratings for individual actions, and satisfaction when escalation is needed. High efficiency with low satisfaction means the platform works but feels bad to use - maybe the UX is confusing or errors are frustrating.",
     },
   ]}
 />
@@ -506,23 +495,26 @@ Building a platform is an investment - in tooling, integrations, and ongoing mai
 Metrics are most useful in combination. Here's what different patterns indicate:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "High efficiency, low adoption",
-      text: "- the platform works but developers don't trust it or can't find it. Improve discoverability, add more actions for common tasks, or investigate why developers prefer the old way.",
+      text: "The platform works but developers don't trust it or can't find it. Improve discoverability, add more actions for common tasks, or investigate why developers prefer the old way.",
     },
     {
       lead: "High adoption, low efficiency",
-      text: "- developers use the platform but it's slow. Actions need optimization, approval policies are too strict, or workflows have bottlenecks.",
+      text: "Developers use the platform but it's slow. Actions need optimization, approval policies are too strict, or workflows have bottlenecks.",
     },
     {
       lead: "High adoption, high efficiency, low satisfaction",
-      text: "- the platform works and is fast, but developers don't like using it. UX problems, confusing errors, or missing features they expected.",
+      text: "The platform works and is fast, but developers don't like using it. UX problems, confusing errors, or missing features they expected.",
     },
     {
       lead: "Declining adoption with stable efficiency",
-      text: "- something changed. Maybe a competing tool emerged, a key action broke, or the platform team shipped something unpopular. Investigate quickly.",
+      text: "Something changed. Maybe a competing tool emerged, a key action broke, or the platform team shipped something unpopular. Investigate quickly.",
     },
   ]}
 />
@@ -532,7 +524,8 @@ Metrics are most useful in combination. Here's what different patterns indicate:
 If you can only track a few things, focus on these:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Portal vs platform value comparison.",
     thead: {
@@ -596,8 +589,8 @@ That developer waiting three days for a database? In a real platform, they'd hav
 
 Getting there requires intentional design. Actions need obvious outcomes and sensible defaults. Approval policies should auto-approve aggressively and only route exceptions to humans. Workflow orchestration must handle failures gracefully and clean up after itself. Integrations should abstract away provider specifics so you can evolve the underlying systems without rewriting everything.
 
-Level 4 platform maturity isn't cheap. It requires investment in tooling, integration work, and ongoing maintenance. But the returns are proportional: developer productivity multiplied across the organization, platform team leverage instead of ticket-by-ticket toil, and the compounding benefits of standardization and automation.
-
 <Callout type="success">
 The test of a real platform: can a new developer join, need a database, and have it provisioned without asking anyone for help? If yes, you've built a platform. If no - if they need to read Confluence, file a Jira ticket, or ping someone on Slack - you've built a prettier ticket system.
 </Callout>
+
+Level 4 platform maturity isn't cheap. It requires investment in tooling, integration work, and ongoing maintenance. But the returns are proportional: developer productivity multiplied across the organization, platform team leverage instead of ticket-by-ticket toil, and the compounding benefits of standardization and automation.

From 1f88135136ca482a515ec866746c5777e3135b81 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 00:34:55 +0300
Subject: [PATCH 07/15] Final pass
 internal-platform-api-versioning-deprecation-breaking-changes article

---
 src/components/List/__tests__/index.spec.ts   |  37 ++++
 .../List/layouts/ColoredMarkerList.astro      |   4 +-
 .../index.mdx                                 |  24 ++-
 .../pdf.mdx                                   | 167 ++++++++++++------
 4 files changed, 165 insertions(+), 67 deletions(-)

diff --git a/src/components/List/__tests__/index.spec.ts b/src/components/List/__tests__/index.spec.ts
index f5d58f925..cd49babf1 100644
--- a/src/components/List/__tests__/index.spec.ts
+++ b/src/components/List/__tests__/index.spec.ts
@@ -162,4 +162,41 @@ describe('List (Astro)', () => {
       expect(lead?.textContent).toContain('Owner clarity matters.')
     })
   })
+
+  test('stacks lead and text vertically for the colored-marker-list variant', async () => {
+    const List = (await import('@components/List/index.astro')).default
+
+    const renderedHtml = await container.renderToString(List, {
+      props: {
+        variant: 'colored-marker-list',
+        items: [
+          {
+            lead: 'Compatibility adapters',
+            text: 'Provide a translation layer during migration.',
+            color: 'bg-success',
+          },
+        ],
+      },
+    })
+
+    await withJsdomEnvironment(async ({ window }) => {
+      window.document.body.innerHTML = renderedHtml
+
+      const listItem = window.document.querySelector('ul li')
+      const marker = window.document.querySelector('ul li > span:first-child')
+      const contentWrapper = window.document.querySelector('ul li > div')
+      const lead = window.document.querySelector('ul li em')
+      const text = window.document.querySelector('ul li div > span')
+
+      expect(listItem).toBeTruthy()
+      expect(marker?.className).toContain('bg-success')
+      expect(contentWrapper?.className).toContain('flex-col')
+      expect(contentWrapper?.className).not.toContain('sm:flex-row')
+      expect(contentWrapper?.className).toContain('items-start')
+      expect(contentWrapper?.className).toContain('gap-1')
+      expect(lead?.className).not.toContain('sm:mr-2')
+      expect(lead?.textContent).toContain('Compatibility adapters')
+      expect(text?.textContent).toContain('Provide a translation layer during migration.')
+    })
+  })
 })
\ No newline at end of file
diff --git a/src/components/List/layouts/ColoredMarkerList.astro b/src/components/List/layouts/ColoredMarkerList.astro
index f9f68c283..bcea5ede6 100644
--- a/src/components/List/layouts/ColoredMarkerList.astro
+++ b/src/components/List/layouts/ColoredMarkerList.astro
@@ -19,7 +19,7 @@ const { items, classes, size = 2 }: Props = Astro.props
 
 const ulClass = ["list-none pl-0 text-content mt-4 mb-2 space-y-2", classes?.ul]
 const liClass = ["flex items-start", classes?.li]
-const emClass = ["mr-0 sm:mr-2 not-italic font-bold", classes?.em]
+const emClass = ["not-italic font-bold", classes?.em]
 const markerSizeInRem = `${size * 0.25}rem`
 const markerStyle = `width: ${markerSizeInRem}; height: ${markerSizeInRem};`
 const iconClass = ["rounded-full mt-2 mr-3 shrink-0", classes?.icon]
@@ -31,7 +31,7 @@ const textClass = classes?.text ? [classes.text] : []
     items.map((item) => (
       <li class:list={liClass}>
         <span class:list={[iconClass, item.color]} style={markerStyle} />
-        <div class="flex flex-col sm:flex-row sm:items-start">
+        <div class="flex min-w-0 flex-col items-start gap-1">
           {item.lead && <em class:list={emClass} set:html={item.lead}></em>}
           <span class:list={textClass} set:html={item.text}></span>
         </div>
diff --git a/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/index.mdx b/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/index.mdx
index 2c62e6b5d..5ac3ce701 100644
--- a/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/index.mdx
+++ b/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/index.mdx
@@ -13,7 +13,7 @@ Last week, a platform team I know shipped what they called a "small cleanup" to
 
 Monday morning, 40 CI pipelines failed. Three teams scrambled to update their deployment scripts. A critical security hotfix got blocked because the team couldn't deploy. The platform team spent the entire week doing emergency migrations instead of planned work. And the trust they'd built over the previous year? Gone.
 
-This happens constantly with internal APIs. There's a temptation to treat them differently than external ones: "we can just tell people to update," "everyone's in the same building," "we'll coordinate in Slack." But internal APIs deserve __more__ versioning discipline than external ones, not less.
+This happens constantly with internal APIs. There's a temptation to treat them differently than external ones: "we can just tell people to update," "everyone's in the same building," "we'll coordinate in Slack." <Highlighter>But internal APIs deserve _more_ versioning discipline than external ones, not less.</Highlighter>
 
 Internal customers are captive customers. They can't switch to a competitor's platform. This makes breaking their workflows worse, not better - they have no recourse except escalating to leadership or building workarounds that create tech debt.
 
@@ -26,7 +26,8 @@ __Will existing client code still work?__ That's the question that determines wh
 Some changes are obviously breaking - removing endpoints, changing HTTP methods, adding required fields. These require full deprecation process, no exceptions. Other changes are obviously safe - adding optional fields, new endpoints, loosening validation. The table below draws the line.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Breaking vs safe changes.",
     thead: {
@@ -102,7 +103,7 @@ Some changes are obviously breaking - removing endpoints, changing HTTP methods,
 The tricky cases fall in between - changes that are technically compatible but break consumer assumptions:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
   items={[
     {
       lead: "Error code changes",
@@ -114,7 +115,7 @@ The tricky cases fall in between - changes that are technically compatible but b
     },
     {
       lead: "Semantic changes",
-      text: "Making `count` include deleted items when it previously didn't - breaking even though the field name stays the same",
+      text: 'Making <span class="font-mono">count</span> include deleted items when it previously didn\'t - breaking even though the field name stays the same',
     },
   ]}
 />
@@ -128,7 +129,10 @@ When you're unsure whether a change breaks existing clients, treat it as breakin
 Once you've identified a breaking change, follow a structured process that gives consumers time to adapt. Skipping steps is how you end up with 40 broken pipelines and a week of emergency migrations.
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Step 1: Identify affected consumers.",
@@ -158,7 +162,11 @@ Once you've identified a breaking change, follow a structured process that gives
 The key insight is that urgency should escalate as the deadline approaches. Early communication is broad and informational - changelog updates, Slack posts, email announcements. As sunset nears, communication becomes targeted and direct.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Deprecation communication timeline.",
     thead: {
@@ -228,8 +236,6 @@ A good migration guide answers questions in the order developers ask them. Start
 
 Tier your support by consumer need. Most migrations should be self-service with docs and validators. For stuck teams, offer office hours and PR reviews. For critical consumers or complex cases, the platform team writes the migration PRs directly.
 
-Automation pays for itself quickly. A codemod that handles 80% of cases automatically and flags the remaining 20% for manual review dramatically reduces the burden on consuming teams. Compatibility adapters that translate v1 requests to v2 internally buy time for slow migrators without extending your maintenance window.
-
 <Download
   resource="internal-platform-api-versioning-deprecation-breaking-changes"
   title="Download the API Versioning Guide"
@@ -250,6 +256,8 @@ Automation pays for itself quickly. A codemod that handles 80% of cases automati
   ]}
 />
 
+Automation pays for itself quickly. A codemod that handles 80% of cases automatically and flags the remaining 20% for manual review dramatically reduces the burden on consuming teams. Compatibility adapters that translate v1 requests to v2 internally buy time for slow migrators without extending your maintenance window.
+
 ## The Invisible Success
 
 Good API versioning is invisible. Consumers barely notice migrations because they're well-communicated, well-supported, and well-timed. The new version shows up with deprecation warnings months in advance. The migration guide makes the change trivial. By the time sunset arrives, everyone's already moved on.
diff --git a/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/pdf.mdx b/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/pdf.mdx
index 4d8714614..175245c44 100644
--- a/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/pdf.mdx
+++ b/src/content/articles/internal-platform-api-versioning-deprecation-breaking-changes/pdf.mdx
@@ -9,14 +9,12 @@ tags: ["platform-engineering"]
 featured: true
 ---
 
-*[SDK]: Software Development Kit
-*[SLA]: Service Level Agreement
-*[CI]: Continuous Integration
-*[CD]: Continuous Deployment
-*[REST]: Representational State Transfer
+*[EOL]: End of Life
 *[gRPC]: Google Remote Procedure Call
+*[REST]: Representational State Transfer
+*[SDK]: Software Development Kit
 *[SemVer]: Semantic Versioning
-*[EOL]: End of Life
+*[SLA]: Service Level Agreement
 
 Last week, a platform team I know shipped what they called a "small cleanup" to their deployment API. They renamed a field from `service_id` to `serviceId`, removed an endpoint that was "barely used," and updated the response format to match their new schema. No version bump. No deprecation notice. Just a Friday afternoon deploy and a Slack message in `#platform-updates` that nobody read.
 
@@ -24,12 +22,12 @@ Monday morning, 40 CI pipelines failed. Three teams scrambled to update their de
 
 This happens constantly with internal APIs. There's a temptation to treat them differently than external ones: "we can just tell people to update," "everyone's in the same building," "we'll coordinate in Slack." But internal APIs deserve _more_ versioning discipline than external ones, not less.
 
-The same practices that make external APIs predictable - semantic versioning, deprecation policies, migration support - apply to internal platform APIs. The difference is that internal teams have higher expectations because they're colleagues, and lower patience because they have their own roadmaps that don't include "emergency migration of the deployment API."
-
 <Callout type="warning">
 Internal customers are captive customers. They can't switch to a competitor's platform. This makes breaking their workflows worse, not better - they have no recourse except escalating to leadership or building workarounds that create tech debt.
 </Callout>
 
+The same practices that make external APIs predictable - semantic versioning, deprecation policies, migration support - apply to internal platform APIs. The difference is that internal teams have higher expectations because they're colleagues, and lower patience because they have their own roadmaps that don't include "emergency migration of the deployment API."
+
 ## Versioning Strategies
 
 ### Choosing a Versioning Scheme
@@ -37,19 +35,22 @@ Internal customers are captive customers. They can't switch to a competitor's pl
 Four versioning approaches dominate API design, each with tradeoffs that matter for internal platforms.
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-18 mb-6",
+  }}
   items={[
     {
       lead: "URL path versioning",
-      text: '(<span class="text-mono">/api/v1/deployments</span>, <span class="text-mono">/api/v2/deployments</span>) is explicit and visible - every request clearly shows which version it\'s using. Load balancers can route traffic easily, and deprecating old versions is straightforward. For internal platform APIs, this is usually the right choice because visibility trumps elegance. When debugging a failed pipeline at 2 AM, you want to immediately know which API version the client is calling.',
+      text: '<span class="text-mono">/api/v1/deployments</span> and <span class="text-mono">/api/v2/deployments</span> is explicit and visible - every request clearly shows which version it\'s using. Load balancers can route traffic easily, and deprecating old versions is straightforward. For internal platform APIs, this is usually the right choice because visibility trumps elegance. When debugging a failed pipeline at 2 AM, you want to immediately know which API version the client is calling.',
     },
     {
-      lead: "Header versioning",
-      text: '(<span class="text-mono">Accept: application/vnd.platform.v2+json</span>) and _query parameter versioning_ (<span class="text-mono">/api/services?version=2</span>) both hide version information where developers forget to set it and debugging tools don\'t show it. Skip these unless you have specific requirements for URL stability.',
+      lead: "Header versioning and query parameter versioning",
+      text: '<span class="text-mono">Accept: application/vnd.platform.v2+json</span> and <span class="text-mono">/api/services?version=2</span> both hide version information where developers forget to set it and debugging tools don\'t show it. Skip these unless you have specific requirements for URL stability.',
     },
     {
       lead: "Date-based versioning",
-      text: '(<span class="text-mono">/api/2024-01-15/services</span>) works well for APIs with frequent, incremental changes - Stripe and AWS use this successfully. The downside is version accumulation: after a few years, you have dozens of dated endpoints. This works best when you have the tooling to manage many concurrent versions.',
+      text: '<span class="text-mono">/api/2024-01-15/services</span> works well for APIs with frequent, incremental changes - Stripe and AWS use this successfully. The downside is version accumulation: after a few years, you have dozens of dated endpoints. This works best when you have the tooling to manage many concurrent versions.',
     },
   ]}
 />
@@ -61,25 +62,29 @@ For most internal platform APIs, I recommend URL path versioning. Maximum visibi
 Semantic versioning gives version numbers meaning. For APIs, the interpretation is straightforward:
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Major versions (v1 → v2)",
-      text: "indicate breaking changes that require consumer code updates. This includes removing endpoints, removing fields from responses, adding required fields to requests, changing field types, changing authentication mechanisms, or renaming fields without backward-compatible aliases. Major bumps need 90+ days advance notice and full deprecation process. Support the previous major version for at least 12 months.",
+      text: "Indicate breaking changes that require consumer code updates. This includes removing endpoints, removing fields from responses, adding required fields to requests, changing field types, changing authentication mechanisms, or renaming fields without backward-compatible aliases. Major bumps need 90+ days advance notice and full deprecation process. Support the previous major version for at least 12 months.",
     },
     {
       lead: "Minor versions (v1.1 → v1.2)",
-      text: "are backward-compatible additions. New optional endpoints, new optional request fields, new response fields, new enum values - anything that existing client code can safely ignore. No advance notice required, just release notes. Consumers can upgrade without code changes.",
+      text: "These are backward-compatible additions. New optional endpoints, new optional request fields, new response fields, new enum values - anything that existing client code can safely ignore. No advance notice required, just release notes. Consumers can upgrade without code changes.",
     },
     {
       lead: "Patch versions (v1.2.1 → v1.2.2)",
-      text: "are backward-compatible fixes. Bug fixes, performance improvements, documentation updates, security patches. These should be transparent to consumers - they shouldn't even notice. Apply patches to all supported versions.",
+      text: "These are backward-compatible fixes. Bug fixes, performance improvements, documentation updates, security patches. These should be transparent to consumers - they shouldn't even notice. Apply patches to all supported versions.",
     },
   ]}
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
+  fullWidth={false}
   content={{
     figure: "Version bump decision guide.",
     thead: {
@@ -162,7 +167,8 @@ Some changes are obviously safe. Adding an optional request field doesn't affect
 The tricky cases fall in between. Changing error codes from 400 to 422 is technically correct but breaks error handling logic. Changing pagination defaults affects clients that assumed a specific page size. Changing a field's _meaning_ - like making `count` include deleted items when it previously didn't - is breaking even though the type and field name stay the same.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Changes that require full deprecation process.",
     thead: {
@@ -220,8 +226,13 @@ The tricky cases fall in between. Changing error codes from 400 to 422 is techni
   }}
 />
 
+Not every change demands that level of process. Many changes are additive or relaxing — they expand what the API accepts or returns without invalidating anything consumers already depend on. The distinction matters operationally because safe changes can ship continuously without coordination, while breaking changes gate on migration timelines and consumer readiness.
+
+Misclassifying a safe change as a breaking change slows delivery unnecessarily; misclassifying a breaking change as safe causes outages. When the boundary is unclear — a changed default, a subtly different error shape — treat the change as breaking and let consumers confirm otherwise. It's easier to relax a deprecation notice than to roll back a broken deployment.
+
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Changes that can ship without deprecation.",
     thead: {
@@ -274,7 +285,11 @@ When you're unsure, treat it as breaking. Consumers will tell you if you're bein
 Once you've identified a breaking change, follow a structured process that gives consumers time to adapt.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    ul: "!divide-y-0 !border-0 !overflow-visible !rounded-none space-y-4",
+    li: "!rounded-lg !border border-trim",
+  }}
   items={[
     {
       lead: "Step 1: Identify affected consumers.",
@@ -310,19 +325,19 @@ Identify consumers before announcing changes. API gateway logs, service mesh tel
 A well-run deprecation follows a predictable timeline that gives consumers multiple opportunities to act - and escalating urgency as the deadline approaches.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Major version sunsets",
-      text: "need 12 months total. Start with a 30-day feedback period where you announce the proposal and gather input. Release the new version, then run both versions in parallel for 12 months. Send the 90-day warning, the 30-day warning, and finally sunset the old version. This sounds like a long time, but internal teams have their own roadmaps. A migration that takes 2 days of work might not get scheduled for 3 months.",
+      text: "Needs 12 months total. Start with a 30-day feedback period where you announce the proposal and gather input. Release the new version, then run both versions in parallel for 12 months. Send the 90-day warning, the 30-day warning, and finally sunset the old version. This sounds like a long time, but internal teams have their own roadmaps. A migration that takes 2 days of work might not get scheduled for 3 months.",
     },
     {
       lead: "Minor feature deprecations",
-      text: "can move faster - 6 months is usually sufficient. Same pattern: announcement, parallel operation, escalating warnings, sunset.",
+      text: "These can move faster - 6 months is usually sufficient. Same pattern: announcement, parallel operation, escalating warnings, sunset.",
     },
     {
       lead: "Security emergencies",
-      text: "are the exception. When you need to remove something immediately for security reasons, the minimum is 30 days with direct contact to every known consumer. Get security team approval, document the risk, and communicate urgently. Don't use this as a shortcut for normal deprecations - it burns trust.",
+      text: "These are the exception. When you need to remove something immediately for security reasons, the minimum is 30 days with direct contact to every known consumer. Get security team approval, document the risk, and communicate urgently. Don't use this as a shortcut for normal deprecations - it burns trust.",
     },
   ]}
 />
@@ -334,7 +349,11 @@ People miss messages. The developer who needs to migrate might be on vacation wh
 The key insight is that urgency should escalate as the deadline approaches. Early communication is broad and informational - changelog updates, Slack posts, email announcements. As sunset nears, communication becomes targeted and direct: personal outreach to remaining consumers, calendar invites for the sunset date, escalation to team leads. The table below shows the progression.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Deprecation communication timeline.",
     thead: {
@@ -434,25 +453,33 @@ Never surprise people with deprecations. Even if policy says "90 days notice," e
 The faster consumers migrate, the sooner you can sunset the old version. Every friction point in migration extends the deprecation timeline. Invest in making migration as easy as possible - it pays back in reduced support load and faster adoption.
 
 <List
-  variant="check-icons-list"
+  variant="badge-list"
+  classes={{
+    titleClass: "block w-full text-center",
+    wrapper: "sm:mr-12 mb-6",
+  }}
   items={[
     {
-      lead: "Tier 1: Self-service.",
-      text: "Most migrations should be completable without platform team involvement. Provide a comprehensive migration guide with before/after code examples, a comparison table of old vs new API, an FAQ covering common questions, and a self-service validator that consumers can run to check their migration status. Support comes through async channels like #platform-help.",
+      title: "Tier 1:<br />Self-Service",
+      lead: "Most migrations should be completable without platform team involvement.",
+      text: "Provide a comprehensive migration guide with before/after code examples, a comparison table of old vs new API, an FAQ covering common questions, and a self-service validator that consumers can run to check their migration status. Support comes through async channels like #platform-help.",
     },
     {
-      lead: "Tier 2: Assisted.",
-      text: "For consumers who need more help, offer scheduled office hours for questions, code review of migration PRs, and migration progress tracking. This tier catches teams who are stuck on edge cases or unclear about specific changes.",
+      title: "Tier 2:<br />Assisted",
+      lead: "For consumers who need more help, offer scheduled office hours for questions, code review of migration PRs, and migration progress tracking.",
+      text: "This tier catches teams who are stuck on edge cases or unclear about specific changes.",
     },
     {
-      lead: "Tier 3: Hands-on.",
-      text: "For high-impact consumers or complex migrations, the platform team creates the migration PRs directly. This includes pair programming sessions and production deployment support. Reserve this for critical paths where a delayed migration blocks the entire deprecation.",
+      title: "Tier 3:<br />Hands-On",
+      lead: "For high-impact consumers or complex migrations, the platform team creates the migration PRs directly.",
+      text: "This includes pair programming sessions and production deployment support. Reserve this for critical paths where a delayed migration blocks the entire deprecation.",
     },
   ]}
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="semantic-coloring-table"
+  fullWidth={false}
   content={{
     figure: "Migration support tiers.",
     thead: {
@@ -569,19 +596,25 @@ Code: Custom jscodeshift codemod for internal API migration.
 The key to good codemods is conservative transformation: change what you're certain about, flag what you're not. A codemod that silently breaks edge cases is worse than no codemod at all.
 
 <List
-  variant="check-icons-list"
+  variant="colored-marker-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Compatibility adapters",
-      text: "provide a translation layer that accepts v1 format and converts to v2 internally. This lets the platform team sunset the actual v1 implementation while giving consumers more time to migrate their code. The adapter logs usage for migration tracking, creating visibility into who still depends on the compatibility layer.",
+      text: "Provides a translation layer that accepts v1 format and converts to v2 internally. This lets the platform team sunset the actual v1 implementation while giving consumers more time to migrate their code. The adapter logs usage for migration tracking, creating visibility into who still depends on the compatibility layer.",
+      color: "bg-success",
     },
     {
       lead: "Migration validators",
-      text: "scan codebases for v1 API usage and generate reports. Run them in CI to block PRs that introduce new v1 dependencies. Provide them as self-service tools so consumers can check their own migration progress.",
+      text: "Scans codebases for v1 API usage and generate reports. Run them in CI to block PRs that introduce new v1 dependencies. Provide them as self-service tools so consumers can check their own migration progress.",
+      color: "bg-success",
     },
     {
       lead: "Progress trackers",
-      text: "aggregate data from API gateway logs, validator results, and team self-reports to show migration status across all consumers. The platform team uses this to identify holdouts and target support.",
+      text: "Aggregates data from API gateway logs, validator results, and team self-reports to show migration status across all consumers. The platform team uses this to identify holdouts and target support.",
+      color: "bg-success",
     },
   ]}
 />
@@ -597,15 +630,18 @@ The easier migration is, the faster it happens. Codemods that automatically tran
 You can't manage what you can't measure. Deprecation metrics tell you whether migration is on track, where consumers are stuck, and whether the deprecation is causing problems.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-2 sm:mr-8 mb-6",
+  }}
   items={[
     {
       lead: "Adoption metrics",
-      text: "track migration progress. New version adoption - the percentage of traffic on v2 versus v1 - is the headline number. Migration velocity shows how many consumers migrate per week; you want this linear or accelerating, not flat. Holdouts - consumers still on v1 near sunset - identify who needs urgent attention.",
+      text: "Tracks migration progress. New version adoption - the percentage of traffic on v2 versus v1 - is the headline number. Migration velocity shows how many consumers migrate per week; you want this linear or accelerating, not flat. Holdouts - consumers still on v1 near sunset - identify who needs urgent attention.",
     },
     {
       lead: "Health metrics",
-      text: "catch problems. Monitor error rates during the migration period; they shouldn't increase versus baseline. Track migration-related support tickets to ensure the platform team isn't overwhelmed. Watch for rollbacks - services that migrated to v2 then reverted to v1 indicate something's wrong with the new version.",
+      text: "Catches problems. Monitor error rates during the migration period; they shouldn't increase versus baseline. Track migration-related support tickets to ensure the platform team isn't overwhelmed. Watch for rollbacks - services that migrated to v2 then reverted to v1 indicate something's wrong with the new version.",
     },
   ]}
 />
@@ -617,23 +653,26 @@ __Timeline metrics__ keep the deprecation on schedule. Compare actual milestone
 Think of migration as a funnel with stages: total consumers → aware → started migration → testing on v2 → production on v2 → v1 fully retired. Each stage has observable metrics.
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
+  classes={{
+    wrapper: "sm:ml-2 sm:mr-8 mb-6",
+  }}
   items={[
     {
       lead: "Aware",
-      text: "is measured by announcement reach - did your Slack post get emoji reactions? Did affected teams acknowledge the notification?",
+      text: "Measured by announcement reach - did your Slack post get emoji reactions? Did affected teams acknowledge the notification?",
     },
     {
       lead: "Started migration",
-      text: "shows up as PRs opened, branches created, or SDK upgrades in package files.",
+      text: "Shows up as PRs opened, branches created, or SDK upgrades in package files.",
     },
     {
       lead: "Testing on v2",
-      text: "means staging or dev traffic hitting the new version.",
+      text: "Means staging or dev traffic hitting the new version.",
     },
     {
       lead: "Production on v2",
-      text: "is the goal - production traffic on the new version, ideally with v1 traffic dropping to zero.",
+      text: "The goal - production traffic on the new version, ideally with v1 traffic dropping to zero.",
     },
   ]}
 />
@@ -641,19 +680,26 @@ Think of migration as a funnel with stages: total consumers → aware → starte
 Here's what a healthy migration funnel looks like in practice. For a deployment API v2 migration with 50 consuming services:
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: "Week 1: 50 total → 45 aware (90%) → 0 started. _Normal - teams are reading the announcement._",
+      lead: "Week 1:",
+      text: "50 total → 45 aware (90%) → 0 started. <em>Normal - teams are reading the announcement.</em>",
     },
     {
-      text: "Week 4: 50 total → 50 aware (100%) → 30 started (60%) → 5 testing. _Good velocity._",
+      lead: "Week 4:",
+      text: "50 total → 50 aware (100%) → 30 started (60%) → 5 testing. <em>Good velocity.</em>",
     },
     {
-      text: "Week 8: 50 total → 50 aware → 45 started (90%) → 35 testing (70%) → 20 production (40%). _On track._",
+      lead: "Week 8:",
+      text: "50 total → 50 aware → 45 started (90%) → 35 testing (70%) → 20 production (40%). <em>On track.</em>",
     },
     {
-      text: "Week 12 (90 days out): 50 total → 48 production (96%) → 2 holdouts identified. _Target support at holdouts._",
+      lead: "Week 12 (90 days out):",
+      text: "50 total → 48 production (96%) → 2 holdouts identified. <em>Target support at holdouts.</em>",
     },
   ]}
 />
@@ -661,7 +707,11 @@ Here's what a healthy migration funnel looks like in practice. For a deployment
 When consumers are stuck at a particular stage, investigate why. Often it's a missing migration tool (stuck at "started"), unclear documentation (stuck at "testing"), or a blocking bug in v2 (stuck at "production"). Rarely is it resistance - most developers would rather move on than maintain compatibility with deprecated APIs.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Migration milestone targets.",
     thead: {
@@ -727,12 +777,19 @@ Good API versioning is invisible. Consumers barely notice migrations because the
 
 Getting there requires treating internal APIs with the same discipline as external ones. Internal customers deserve predictable, well-communicated changes - arguably more so, because they can't switch providers when you break them. Use semantic versioning to signal intent clearly. Follow a structured deprecation process with real timelines and escalating communication. Invest in migration support that makes adoption easy: guides, codemods, adapters, validators.
 
+<Callout type="success">
+Good API versioning is invisible - consumers barely notice migrations because they're well-communicated, well-supported, and well-timed. Bad versioning is very visible: broken pipelines, emergency meetings, and angry Slack messages. Invest in the former to avoid the latter.
+</Callout>
+
 The payoff is substantial. Trust with internal teams that makes future changes easier. Faster adoption of new versions because consumers know what to expect. Reduced support burden because migrations are self-service. And the platform team's time spent on planned work instead of emergency migrations.
 
 ## Quick Reference
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
+  classes={{
+    figure: "sm:ml-24 sm:mr-36 mb-6",
+  }}
   content={{
     figure: "Key deprecation timeline thresholds.",
     thead: {
@@ -802,7 +859,3 @@ The payoff is substantial. Trust with internal teams that makes future changes e
 - [Stripe's API Versioning](https://stripe.com/docs/api/versioning) - Date-based versioning done well, with excellent migration tooling
 - [GitHub's Breaking Changes Policy](https://docs.github.com/en/rest/overview/breaking-changes) - Clear communication patterns for a large API surface
 - [jscodeshift](https://github.com/facebook/jscodeshift) - Facebook's toolkit for writing JavaScript/TypeScript codemods
-
-<Callout type="success">
-Good API versioning is invisible - consumers barely notice migrations because they're well-communicated, well-supported, and well-timed. Bad versioning is very visible: broken pipelines, emergency meetings, and angry Slack messages. Invest in the former to avoid the latter.
-</Callout>

From 1b217d3121704721d51117cc9b7194ffcc91b100 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 01:28:15 +0300
Subject: [PATCH 08/15] Final pass
 kubernetes-cluster-upgrade-playbook-risk-reduction article

---
 _TODO.md                                      |  35 +----
 .../index.mdx                                 |  44 +++---
 .../pdf.mdx                                   | 126 +++++++++++-------
 3 files changed, 110 insertions(+), 95 deletions(-)

diff --git a/_TODO.md b/_TODO.md
index bdd845abe..493549b35 100644
--- a/_TODO.md
+++ b/_TODO.md
@@ -181,13 +181,7 @@ Need a tooltip component for consistency. List to add tooltips to:
 
 ## Downloads / Gated Content
 
-- We need a gating system, where the user gets a token to be able to download a PDF and the token is checked before downloading. If a reader has already given their email address - newsletter signup, contact form, download registration, then the download CTA on short form articles should go directly to the HTML version of the deep dive, and it should have a PDF download button.
-
-- Make `/deep-dive/` SSR loaded so we can check if they've given their e-mail address.
-
-- If they haven't and they get to the path from sharing a link or something, we should use the `index.astro` file in that directory to explain that they've accessed gated content, and ask for their e-mail address. Then redirect to the content they want when they give it.
-
-- If they've given their email link, the content switcher button to switch should be enabled.
+- We need a gating system, where the user gets a token to be able to download a PDF and the token is checked before downloading. If a reader has already given their email address - newsletter signup, contact form, download registration, then the download CTA on short form articles should show the PDF download button instead of trying to collect email addresses again.
 
 - We had this copyright statement for articles, it should be in the front matter of PDFs:
 
@@ -197,8 +191,6 @@ The text, diagrams, and images in this work are licensed under CC BY-NC 4.0
 All code samples in this article are licensed under the MIT License. Feel free to use, modify, and distribute them in any project.
 ```
 
-- When someone's already given their email address, the Download CTA should just have a download button - not require them to sign up again
-
 ## Search
 
 - How do we handle the keywords in the long form / pdf files from a search perspective? Can we return the result in the search results if the short form content is not returned in the search results, and highlight it somehow in the search results to show that it is gated content? And clicking on its link takes the user to the Download page for that item?
@@ -218,8 +210,6 @@ https://mermaid.js.org/config/directives.html
 
 - Uppy, Tus server, whatever other server needed for file upload on Contact Form component
 
-- Add Inset component and convert `text` code blocks to use it.
-
 - Focus-visible / active handling on ToC nav items
 
 - Style "Share to Mastodon" modal in src/components/Social/Mastodon/client/index.ts
@@ -236,12 +226,6 @@ https://mermaid.js.org/config/directives.html
 
 - Improve `<abbr>` styling: https://codepen.io/ire/pen/NoqWpm
 
-- Service worker isn't caching favicon
-
-- Image component with zoom + and -, and magnify glass. Modal to expand full size.
-
-- Don't lazy load hero image
-
 ## List Component
 
 - Task list checked variant Markdown in dark theme is awkward, it has a dark shadow
@@ -256,18 +240,12 @@ https://mermaid.js.org/config/directives.html
 
 ## Content Issues
 
-- "### Geographic/Currency Mismatches" in deep-dive/cdn-edge-caching-cache-keys-vary-headers has a table -> callout -> table back to back
-
 - Need an article on OpenStack
 
 - Add a Social Share on some compelling text in each article
 
 - Home page reorganization: move the "What I Deliver" box from the Hero into the Backstage image. Move the Backstage image / video to the hero.
 
-- Determine if any of the python code blocks should have `#!/bin/python` added
-
-- Need a Q & A format to use in `blameless-postmortem-incident-analysis-systemic-causes`. Might be one of the list formats.
-
 - We need to check for short form and deep article articles where the deep-dive index.pdf has a non-featured tag like "argo-cd" only in the pdf.mdx. In those cases, we should make sure the callout for the deep dive includes the name of that non-featured (technology) tag
 
 - deep-dive/kubernetes-pod-resource-requests-limits-qos-classes is showing the Download hero image
@@ -278,12 +256,7 @@ https://mermaid.js.org/config/directives.html
 
 - Need to update Case Studies with lists and tables too
 
-### This file was badly mangled during refactoring, need to compare against original:
-
-src/content/articles/internal-developer-portal-platform-self-service-actions/pdf.mdx
-
-├──
-└──
+### Snippets
 
 <span class="font-mono">
 </span>
@@ -323,7 +296,7 @@ src/content/articles/internal-developer-portal-platform-self-service-actions/pdf
   ]}
 />
 
-### Stretching the badge out to the same size and centering text:
+#### Stretching the badge out to the same size and centering text:
 
 <List
   variant="badge-list"
@@ -331,7 +304,7 @@ src/content/articles/internal-developer-portal-platform-self-service-actions/pdf
     titleClass: "block w-full text-center",
   }}
 
-### Spacing out the boxes:
+#### Spacing out the boxes:
 
 <List
   variant="zebra-list"
diff --git a/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/index.mdx b/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/index.mdx
index c89ca866d..7bcfcaad1 100644
--- a/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/index.mdx
+++ b/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/index.mdx
@@ -9,45 +9,45 @@ tags: ["cloud-platforms","kubernetes","aws","azure"]
 featured: true
 ---
 
-*[K8s]: Kubernetes
-*[API]: Application Programming Interface
-*[CRD]: Custom Resource Definition
 *[CNI]: Container Network Interface
+*[CRD]: Custom Resource Definition
 *[CSI]: Container Storage Interface
 *[etcd]: Distributed key-value store used by Kubernetes
+*[K8s]: Kubernetes
 
-I watched a company avoid Kubernetes upgrades for 18 months. When they finally __had__ to upgrade for security compliance, they faced a five-version jump. Deprecated APIs were everywhere. Custom controllers broke. Workloads failed in ways nobody expected. What should have been four routine 2-hour maintenance windows became a three-week crisis involving weekend war rooms and executive escalations.
+I watched a company avoid Kubernetes upgrades for 18 months. When they finally _had_ to upgrade for security compliance, they faced a five-version jump. Deprecated APIs were everywhere. Custom controllers broke. Workloads failed in ways nobody expected. What should have been four routine 2-hour maintenance windows became a three-week crisis involving weekend war rooms and executive escalations.
 
-The lesson is counterintuitive but consistent: frequent, incremental upgrades are __less__ risky than infrequent large jumps. Kubernetes releases new versions roughly every four months, so each version you skip accumulates deprecated APIs, changed behaviors, and incompatible add-ons. A cluster three or more versions behind isn't technical debt - it's an emergency waiting to happen. The goal of this playbook is to make upgrades boring: predictable procedures that happen quarterly without drama.
+The lesson is counterintuitive but consistent: frequent, incremental upgrades are _less_ risky than infrequent large jumps. Kubernetes releases new versions roughly every four months, so each version you skip accumulates deprecated APIs, changed behaviors, and incompatible add-ons. <Highlighter>A cluster three or more versions behind isn't technical debt - it's an emergency waiting to happen.</Highlighter> The goal of this playbook is to make upgrades boring: predictable procedures that happen quarterly without drama.
 
 ## The Pre-Upgrade Checklist
 
 Most upgrade failures trace back to skipped preparation. Before touching the cluster, work through four categories of readiness checks.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Timing and planning",
-      text: "comes first. Review the release notes for your target version - not just the highlights, but the deprecations and breaking changes. Kubernetes only supports upgrading one minor version at a time (1.28 to 1.29 is fine, 1.28 to 1.30 isn't), so verify your upgrade path. Schedule a maintenance window with buffer time.",
+      text: "Comes first. Review the release notes for your target version - not just the highlights, but the deprecations and breaking changes. Kubernetes only supports upgrading one minor version at a time (1.28 to 1.29 is fine, 1.28 to 1.30 isn't), so verify your upgrade path. Schedule a maintenance window with buffer time.",
     },
     {
       lead: "Cluster health",
-      text: "establishes your baseline. All nodes should show Ready status. There shouldn't be unexpected pending pods. Control plane components and etcd should be healthy. Resource utilization should be below 70% - upgrades temporarily reduce capacity as nodes drain and restart.",
+      text: "Establishes your baseline. All nodes should show Ready status. There shouldn't be unexpected pending pods. Control plane components and etcd should be healthy. Resource utilization should be below 70% - upgrades temporarily reduce capacity as nodes drain and restart.",
     },
     {
       lead: "Backup and recovery",
-      text: "is your safety net. Take an etcd snapshot before starting. Document current cluster state. Most importantly, document and test your rollback procedure in a non-production environment before you need it.",
+      text: "These are your safety net. Take an etcd snapshot before starting. Document current cluster state. Most importantly, document and test your rollback procedure in a non-production environment before you need it.",
     },
     {
       lead: "Compatibility verification",
-      text: "catches the issues that break workloads. Check that your add-ons - CNI plugin, CSI drivers, ingress controller, cert-manager, monitoring stack - are compatible with the target version. Validate workload manifests for deprecated APIs.",
+      text: "Catches the issues that break workloads. Check that your add-ons - CNI plugin, CSI drivers, ingress controller, cert-manager, monitoring stack - are compatible with the target version. Validate workload manifests for deprecated APIs.",
     },
   ]}
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Pre-upgrade checklist summary.",
     thead: {
@@ -110,7 +110,10 @@ Kubernetes components have strict version compatibility requirements. The API se
 This is by design. Kubernetes explicitly allows version skew during upgrades. If you're upgrading from 1.28 to 1.29, you'll temporarily have 1.29 API servers serving requests alongside 1.28 kubelets - and that's fine.
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Phase 1: Preparation (30 minutes).",
@@ -136,7 +139,8 @@ This is by design. Kubernetes explicitly allows version skew during upgrades. If
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Upgrade phases with risk assessment.",
     thead: {
@@ -207,19 +211,22 @@ __Control plane rollback__ is the nuclear option. For self-managed clusters, rol
 Managed Kubernetes rollback options are limited:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-18 mb-6",
+  }}
   items={[
     {
       lead: "EKS",
-      text: "doesn't support control plane downgrades - your options are restoring from Terraform state or creating a new cluster",
+      text: "Doesn't support control plane downgrades - your options are restoring from Terraform state or creating a new cluster",
     },
     {
       lead: "GKE",
-      text: "supports rollback within the maintenance window",
+      text: "Supports rollback within the maintenance window",
     },
     {
       lead: "AKS",
-      text: "doesn't support downgrades either",
+      text: "Doesn't support downgrades either",
     },
   ]}
 />
@@ -229,7 +236,8 @@ If you're on managed Kubernetes, test what "rollback" actually means for your pr
 __Worker node rollback__ is much simpler. If a node is misbehaving after upgrade, you can downgrade its kubelet without affecting the rest of the cluster: cordon, drain, downgrade, uncordon. Some teams use a blue-green node pool strategy - creating new nodes at the target version, then draining old nodes. With this approach, rollback is trivial: uncordon the old pool and delete the new one.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Rollback scenario risk assessment.",
     thead: {
diff --git a/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/pdf.mdx b/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/pdf.mdx
index 6d1b40daf..bcf2f66aa 100644
--- a/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/pdf.mdx
+++ b/src/content/articles/kubernetes-cluster-upgrade-playbook-risk-reduction/pdf.mdx
@@ -9,30 +9,29 @@ tags: ["cloud-platforms","kubernetes","aws","azure"]
 featured: true
 ---
 
-*[K8s]: Kubernetes
-*[API]: Application Programming Interface
-*[CRD]: Custom Resource Definition
-*[PDB]: Pod Disruption Budget
-*[PSP]: Pod Security Policy
-*[PSA]: Pod Security Admission
-*[etcd]: Distributed key-value store used by Kubernetes
 *[CNI]: Container Network Interface
+*[CRD]: Custom Resource Definition
 *[CSI]: Container Storage Interface
+*[etcd]: Distributed key-value store used by Kubernetes
 *[HPA]: Horizontal Pod Autoscaler
+*[K8s]: Kubernetes
+*[PDB]: Pod Disruption Budget
+*[PSA]: Pod Security Admission
+*[PSP]: Pod Security Policy
 *[PVC]: Persistent Volume Claim
 
 Kubernetes releases new versions roughly every four months. Each version brings new features, deprecates old APIs, and eventually removes them. Fall behind and you're accumulating upgrade debt: missed security patches, deprecated APIs piling up in your manifests, and eventually a multi-version jump that's far riskier than incremental updates would have been.
 
 Yet upgrades feel scary. The control plane manages everything - one mistake can take down the entire cluster. So teams delay. "Everything is working fine" becomes the justification for running a version that's a year out of support.
 
-I watched this play out at a company that avoided upgrades for 18 months. When they finally __had__ to upgrade for security compliance, they faced a five-version jump. Deprecated APIs were everywhere. Custom controllers broke. Workloads failed in ways nobody expected. What should have been four routine 2-hour maintenance windows became a three-week crisis involving weekend war rooms and executive escalations.
-
-The lesson: frequent, incremental upgrades are __less__ risky than infrequent large jumps. The goal of this playbook is to make upgrades boring - predictable procedures that happen quarterly without drama.
+I watched this play out at a company that avoided upgrades for 18 months. When they finally _had_ to upgrade for security compliance, they faced a five-version jump. Deprecated APIs were everywhere. Custom controllers broke. Workloads failed in ways nobody expected. What should have been four routine 2-hour maintenance windows became a three-week crisis involving weekend war rooms and executive escalations.
 
 <Callout type="warning">
 The riskiest upgrade is the one you've been avoiding. Each version you skip accumulates: deprecated APIs, changed behaviors, incompatible add-ons. A cluster 3+ versions behind is an emergency waiting to happen.
 </Callout>
 
+The lesson: frequent, incremental upgrades are _less_ risky than infrequent large jumps. The goal of this playbook is to make upgrades boring - predictable procedures that happen quarterly without drama.
+
 ## Upgrade Preparation
 
 ### Pre-Upgrade Checklist
@@ -40,19 +39,24 @@ The riskiest upgrade is the one you've been avoiding. Each version you skip accu
 Most upgrade failures trace back to skipped preparation. Before touching the cluster, work through four categories of readiness checks.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+    ul: "!divide-y-0 !border-0 !overflow-visible !rounded-none space-y-4",
+    li: "!rounded-lg !border border-trim",
+  }}
   items={[
     {
       lead: "Timing and planning",
-      text: "comes first. Review the release notes for your target version - not just the highlights, but the deprecations and breaking changes. Kubernetes only supports upgrading one minor version at a time (1.28 to 1.29 is fine, 1.28 to 1.30 isn't), so verify your upgrade path. Schedule a maintenance window with buffer time: even \"zero-downtime\" upgrades can hit unexpected issues that need investigation.",
+      text: "Comes first. Review the release notes for your target version - not just the highlights, but the deprecations and breaking changes. Kubernetes only supports upgrading one minor version at a time (1.28 to 1.29 is fine, 1.28 to 1.30 isn't), so verify your upgrade path. Schedule a maintenance window with buffer time: even \"zero-downtime\" upgrades can hit unexpected issues that need investigation.",
     },
     {
       lead: "Cluster health",
-      text: "establishes your baseline. All nodes should show Ready status. There shouldn't be unexpected pending pods. Control plane components and etcd should be healthy. Resource utilization should be below 70% - upgrades temporarily reduce capacity as nodes drain and restart, so you need headroom.",
+      text: "Establishes your baseline. All nodes should show Ready status. There shouldn't be unexpected pending pods. Control plane components and etcd should be healthy. Resource utilization should be below 70% - upgrades temporarily reduce capacity as nodes drain and restart, so you need headroom.",
     },
     {
       lead: "Backup and recovery",
-      text: "is your safety net. Take an etcd snapshot before starting. Document current cluster state with `kubectl get all -A -o yaml`. Most importantly, document and test your rollback procedure in a non-production environment before you need it.",
+      text: 'Your safety net. Take an etcd snapshot before starting. Document current cluster state with <span class="font-mono">kubectl get all -A -o yaml</span>. Most importantly, document and test your rollback procedure in a non-production environment before you need it.',
     },
   ]}
 />
@@ -75,7 +79,8 @@ Code: etcd backup before upgrade.
 __Compatibility verification__ catches the issues that break workloads. Check that your add-ons - CNI plugin, CSI drivers, ingress controller, cert-manager, monitoring stack - are compatible with the target version. Run custom controllers against the target version in staging. Validate workload manifests for deprecated APIs.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Pre-upgrade checklist summary.",
     thead: {
@@ -170,7 +175,10 @@ The good news: this is by design and fully supported. Kubernetes explicitly allo
 The order of operations matters. Upgrade in the wrong sequence and you'll hit version skew limits, incompatible components, or cascading failures. The sequence is: control plane first, then add-ons, then worker nodes.
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Phase 1: Preparation (30 minutes).",
@@ -205,7 +213,10 @@ az aks upgrade -g my-rg -n my-cluster --control-plane-only --kubernetes-version
 Code: Control plane upgrade commands by platform.
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Phase 3: Add-ons (15-30 minutes).",
@@ -237,7 +248,10 @@ kubectl wait --for=condition=Ready node/$NODE --timeout=120s
 Code: Worker node upgrade sequence.
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Phase 5: Validation (15-30 minutes).",
@@ -247,7 +261,8 @@ Code: Worker node upgrade sequence.
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Upgrade phases with risk assessment.",
     thead: {
@@ -316,7 +331,7 @@ Control plane upgrades are the highest-risk phase. API server downtime affects a
 If you have multiple clusters, don't upgrade them all at once. Use a tiered approach where non-critical clusters serve as canaries for critical ones.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Tier 1: Canary clusters (dev, staging, internal tools).",
@@ -334,7 +349,7 @@ If you have multiple clusters, don't upgrade them all at once. Use a tiered appr
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
     figure: "Canary cluster upgrade schedule.",
     thead: {
@@ -383,25 +398,30 @@ Define rollback triggers in advance. Automatic triggers should fire on clear fai
 For managed Kubernetes (EKS, GKE, AKS), node pool strategy significantly affects upgrade risk and rollback options. Three approaches dominate:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    ul: "!divide-y-0 !border-0 !overflow-visible !rounded-none space-y-4",
+    li: "!rounded-lg !border border-trim",
+  }}
   items={[
     {
       lead: "In-place rolling upgrade",
-      text: "upgrades nodes one at a time within the existing pool. Pros: no IP address changes, minimal disruption, no extra cost. Cons: slower (sequential), reduced capacity during upgrade, harder to roll back. Best for small clusters or environments with tight capacity constraints.",
+      text: "Upgrades nodes one at a time within the existing pool. Pros: no IP address changes, minimal disruption, no extra cost. Cons: slower (sequential), reduced capacity during upgrade, harder to roll back. Best for small clusters or environments with tight capacity constraints.",
     },
     {
       lead: "Blue-green node pools",
-      text: "creates a new pool at the target version, migrates workloads, then deletes the old pool. Pros: easy rollback (just keep the old pool), no capacity reduction, clean nodes with no accumulated state. Cons: temporarily doubles node costs, IP addresses change, more complex orchestration. Best for production clusters with stateless workloads.",
+      text: "Creates a new pool at the target version, migrates workloads, then deletes the old pool. Pros: easy rollback (just keep the old pool), no capacity reduction, clean nodes with no accumulated state. Cons: temporarily doubles node costs, IP addresses change, more complex orchestration. Best for production clusters with stateless workloads.",
     },
     {
       lead: "Surge upgrade",
-      text: "creates extra nodes temporarily, upgrades, then removes the extras. This is the middle ground - faster than pure rolling, maintains capacity, balances speed and safety. Most managed Kubernetes services support configuring surge percentages.",
+      text: "Creates extra nodes temporarily, upgrades, then removes the extras. This is the middle ground - faster than pure rolling, maintains capacity, balances speed and safety. Most managed Kubernetes services support configuring surge percentages.",
     },
   ]}
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Node pool upgrade strategy comparison.",
     thead: {
@@ -447,27 +467,31 @@ For production clusters, I recommend blue-green node pools. The sequence:
 
 <List
   variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+    li: "[&>div]:!pt-3",
+  }}
   items={[
     {
-      text: "Create new node pool at target version (with a `NoSchedule` taint to prevent scheduling)",
+      lead: 'Create new node pool at target version (with a <span class="font-mono">NoSchedule</span> taint to prevent scheduling)',
     },
     {
-      text: "Wait for all new nodes to show Ready",
+      lead: "Wait for all new nodes to show Ready",
     },
     {
-      text: "Remove the taint from the new pool",
+      lead: "Remove the taint from the new pool",
     },
     {
-      text: "Cordon the old pool (no new pods scheduled)",
+      lead: "Cordon the old pool (no new pods scheduled)",
     },
     {
-      text: "Drain the old pool (pods migrate to new pool)",
+      lead: "Drain the old pool (pods migrate to new pool)",
     },
     {
-      text: "Validate workloads are healthy on the new pool",
+      lead: "Validate workloads are healthy on the new pool",
     },
     {
-      text: "If healthy, delete the old pool. If not, uncordon the old pool and delete the new one.",
+      lead: "If healthy, delete the old pool. If not, uncordon the old pool and delete the new one.",
     },
   ]}
 />
@@ -553,19 +577,22 @@ Be aware that restoring from an etcd backup resets cluster state to the backup t
 For managed Kubernetes, rollback options are more limited:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-18 mb-6",
+  }}
   items={[
     {
       lead: "EKS",
-      text: "doesn't support control plane downgrades. Your options are restoring the cluster from Terraform/CloudFormation state or creating a new cluster and migrating workloads.",
+      text: "Doesn't support control plane downgrades. Your options are restoring the cluster from Terraform / CloudFormation state or creating a new cluster and migrating workloads.",
     },
     {
       lead: "GKE",
-      text: "supports rollback within the maintenance window using `gcloud container clusters upgrade --cluster-version=PREVIOUS_VERSION`.",
+      text: 'Supports rollback within the maintenance window using <span class="font-mono">gcloud container clusters upgrade --cluster-version=PREVIOUS_VERSION</span>.',
     },
     {
       lead: "AKS",
-      text: "doesn't support control plane downgrades. You'll need to create a new cluster or open an Azure support ticket.",
+      text: "Doesn't support control plane downgrades. You'll need to create a new cluster or open an Azure support ticket.",
     },
   ]}
 />
@@ -614,7 +641,11 @@ Code: Ansible playbook for worker node rollback.
 If you used blue-green node pools for the upgrade, rollback is trivial: uncordon the old pool and delete the new one. This is one of the strongest arguments for blue-green upgrades in production.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     figure: "Rollback scenario risk assessment.",
     thead: {
@@ -706,24 +737,26 @@ echo "System pods not Running: $SYSTEM_NOT_RUNNING"
 ```
 Code: Basic infrastructure validation script.
 
+Infrastructure health is the foundation, but a cluster where nodes are Ready and the API server responds doesn't mean your workloads are actually working. The remaining validation categories probe progressively higher up the stack — from network connectivity between pods, to storage volume availability, to whether application containers are running without errors. Treating these as separate passes makes failures easier to diagnose: if networking checks fail, you know the issue is at the CNI or DNS layer rather than somewhere in your application code. If networking passes but workload checks fail, the problem is likely a deprecated API or changed default that your manifests haven't accounted for.
+
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
       lead: "Networking checks",
-      text: "confirm that cluster DNS resolves, pods can reach each other across nodes, and ingress routes traffic correctly. DNS failures are the most common post-upgrade issue I see - usually caused by CoreDNS pods not rescheduling properly.",
+      text: "Confirm that cluster DNS resolves, pods can reach each other across nodes, and ingress routes traffic correctly. DNS failures are the most common post-upgrade issue I see - usually caused by CoreDNS pods not rescheduling properly.",
     },
     {
       lead: "Storage checks",
-      text: "verify that PersistentVolumeClaims are bound and that volume attachments are working. The storage provider (EBS CSI driver, Azure Disk CSI, etc.) may need upgrades alongside the cluster, and version mismatches cause attachment failures.",
+      text: "Verify that PersistentVolumeClaims are bound and that volume attachments are working. The storage provider (EBS CSI driver, Azure Disk CSI, etc.) may need upgrades alongside the cluster, and version mismatches cause attachment failures.",
     },
     {
       lead: "Workload checks",
-      text: "confirm that your applications are running. Look for pending pods, crashloops, and increased error rates. Deployments should have their expected replica counts, and StatefulSets should show all pods ready.",
+      text: "Confirm that your applications are running. Look for pending pods, crashloops, and increased error rates. Deployments should have their expected replica counts, and StatefulSets should show all pods ready.",
     },
     {
       lead: "Observability checks",
-      text: "ensure that metrics are being collected and logs are flowing. If your monitoring breaks during the upgrade, you won't know about problems until users report them. Check that Prometheus is scraping, alerting rules are evaluating, and log collectors are shipping.",
+      text: "Ensure that metrics are being collected and logs are flowing. If your monitoring breaks during the upgrade, you won't know about problems until users report them. Check that Prometheus is scraping, alerting rules are evaluating, and log collectors are shipping.",
     },
   ]}
 />
@@ -733,7 +766,8 @@ Code: Basic infrastructure validation script.
 Validation should be automated and fast. If checking takes an hour, you won't check after each phase - you'll rush through the upgrade and validate once at the end, when problems are hardest to diagnose. A comprehensive validation suite that runs in 5 minutes lets you validate after each phase, catching issues early when they're easiest to fix.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     figure: "Validation checks by category.",
     thead: {
@@ -803,8 +837,8 @@ Kubernetes upgrades don't have to be scary. The teams I've seen handle them best
 
 The investment in upgrade infrastructure pays for itself quickly. Automated API scanning, blue-green node pools, practiced rollbacks, and comprehensive validation all reduce risk and build confidence.
 
-The pattern is clear: small, regular upgrades beat large, infrequent ones. A quarterly 1.28→1.29 upgrade with well-tested procedures is dramatically safer than an annual 1.25→1.29 jump with four versions of changelog to audit and four times the deprecations to handle.
-
 <Callout type="success">
 The goal is making upgrades so routine they're boring. Quarterly upgrades, practiced procedures, automated validation, and quick rollback capability transform upgrades from scary events into regular maintenance. The teams that upgrade often are the teams that upgrade well.
 </Callout>
+
+The pattern is clear: small, regular upgrades beat large, infrequent ones. A quarterly 1.28→1.29 upgrade with well-tested procedures is dramatically safer than an annual 1.25→1.29 jump with four versions of changelog to audit and four times the deprecations to handle.

From 1e45940bb42739cec50cf840558332b1584f19f3 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 01:44:55 +0300
Subject: [PATCH 09/15] Update npm dependencies

---
 package-lock.json                        | 642 +++++++++++------------
 package.json                             |  28 +-
 src/styles/code-highlighting/general.css |   3 +-
 3 files changed, 323 insertions(+), 350 deletions(-)

diff --git a/package-lock.json b/package-lock.json
index dcc487342..8f7de045e 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -13,13 +13,13 @@
       ],
       "dependencies": {
         "@adobe/remark-gridtables": "^3.0.18",
-        "@astrojs/check": "0.9.7",
+        "@astrojs/check": "0.9.8",
         "@astrojs/db": "^0.20.0",
-        "@astrojs/mdx": "5.0.0",
-        "@astrojs/preact": "5.0.0",
+        "@astrojs/mdx": "5.0.1",
+        "@astrojs/preact": "5.0.1",
         "@astrojs/rss": "4.0.17",
         "@astrojs/sitemap": "^3.7.1",
-        "@astrojs/vercel": "^10.0.0",
+        "@astrojs/vercel": "^10.0.1",
         "@axe-core/playwright": "^4.11.1",
         "@eslint-community/eslint-plugin-eslint-comments": "^4.7.1",
         "@eslint/js": "10.0.1",
@@ -32,7 +32,7 @@
         "@nanostores/persistent": "^1.3.3",
         "@playwright/browser-chromium": "^1.58.2",
         "@playwright/test": "1.58.2",
-        "@semantic-ui/astro-lit": "^5.1.2",
+        "@semantic-ui/astro-lit": "^5.3.0",
         "@sentry/astro": "^10.43.0",
         "@sentry/browser": "^10.43.0",
         "@shikijs/transformers": "^4.0.2",
@@ -58,8 +58,8 @@
         "@types/react": "^19.2.14",
         "@types/sanitize-html": "^2.16.1",
         "@types/to-ico": "1.1.3",
-        "@typescript-eslint/eslint-plugin": "8.57.0",
-        "@typescript-eslint/parser": "8.57.0",
+        "@typescript-eslint/eslint-plugin": "8.57.1",
+        "@typescript-eslint/parser": "8.57.1",
         "@ungap/structured-clone": "^1.3.0",
         "@uppy/audio": "^3.1.0",
         "@uppy/box": "^4.1.0",
@@ -75,11 +75,11 @@
         "@vitest/coverage-v8": "^4.1.0",
         "@webcomponents/template-shadowroot": "^0.2.1",
         "alex": "^11.0.1",
-        "astro": "6.0.4",
+        "astro": "6.0.5",
         "astro-link-validator": "github:rodgtr1/astro-link-validator",
         "astro-og-canvas": "^0.10.1",
         "astro-vtbot": "^2.1.12",
-        "baseline-browser-mapping": "^2.10.7",
+        "baseline-browser-mapping": "^2.10.8",
         "canvas-confetti": "^1.9.4",
         "confusing-browser-globals": "1.0.11",
         "cross-env": "^10.1.0",
@@ -109,14 +109,14 @@
         "is-whitespace-character": "^2.0.1",
         "isomorphic-git": "^1.37.4",
         "js-cookie": "^3.0.5",
-        "jsdom": "^28.1.0",
+        "jsdom": "^29.0.0",
         "libphonenumber-js": "1.12.40",
         "lighthouse": "^13.0.3",
         "lit": "^3.3.2",
         "markdownlint-cli2": "^0.21.0",
         "md-attr-parser": "^1.3.0",
         "mermaid": "^11.13.0",
-        "nanostores": "^1.1.1",
+        "nanostores": "^1.2.0",
         "nodemailer": "^8.0.2",
         "npm": "^11.11.1",
         "playwright-lighthouse": "^4.0.0",
@@ -149,7 +149,7 @@
         "remark-stringify": "^11.0.0",
         "remark-supersub": "^1.0.0",
         "remark-video": "^0.10.0",
-        "resend": "^6.9.3",
+        "resend": "^6.9.4",
         "retext": "^9.0.0",
         "retext-smartypants": "^6.2.0",
         "rimraf": "6.1.3",
@@ -161,7 +161,7 @@
         "stylelint": "^17.4.0",
         "stylelint-config-standard": "^40.0.0",
         "stylelint-declaration-block-no-ignored-properties": "3.0.0",
-        "stylelint-order": "8.0.0",
+        "stylelint-order": "8.1.1",
         "tailwindcss": "^4.2.1",
         "temp-dir": "3.0.0",
         "timezones-ical-library": "^2.1.3",
@@ -169,7 +169,7 @@
         "to-ico": "1.1.5",
         "tslib": "2.8.1",
         "typescript": "5.9.3",
-        "typescript-eslint": "8.57.0",
+        "typescript-eslint": "8.57.1",
         "unified": "^11.0.5",
         "unist": "^0.0.1",
         "unist-util-inspect": "^8.1.0",
@@ -184,19 +184,13 @@
         "zod": "4.3.6"
       },
       "engines": {
-        "node": ">=22.0.0 <23.0.0",
+        "node": ">=24.0.0 <25.0.0",
         "npm": ">=10.0.0"
       },
       "optionalDependencies": {
         "@rollup/rollup-linux-x64-gnu": "^4.59.0"
       }
     },
-    "node_modules/@acemir/cssom": {
-      "version": "0.9.31",
-      "resolved": "https://registry.npmjs.org/@acemir/cssom/-/cssom-0.9.31.tgz",
-      "integrity": "sha512-ZnR3GSaH+/vJ0YlHau21FjfLYjMpYVIzTD8M8vIEQvIGxeOXyXdzCI140rrCY862p/C/BbzWsjc1dgnM9mkoTA==",
-      "license": "MIT"
-    },
     "node_modules/@adobe/mdast-util-gridtables": {
       "version": "4.0.17",
       "resolved": "https://registry.npmjs.org/@adobe/mdast-util-gridtables/-/mdast-util-gridtables-4.0.17.tgz",
@@ -245,44 +239,50 @@
       }
     },
     "node_modules/@asamuzakjp/css-color": {
-      "version": "4.1.2",
-      "resolved": "https://registry.npmjs.org/@asamuzakjp/css-color/-/css-color-4.1.2.tgz",
-      "integrity": "sha512-NfBUvBaYgKIuq6E/RBLY1m0IohzNHAYyaJGuTK79Z23uNwmz2jl1mPsC5ZxCCxylinKhT1Amn5oNTlx1wN8cQg==",
+      "version": "5.0.1",
+      "resolved": "https://registry.npmjs.org/@asamuzakjp/css-color/-/css-color-5.0.1.tgz",
+      "integrity": "sha512-2SZFvqMyvboVV1d15lMf7XiI3m7SDqXUuKaTymJYLN6dSGadqp+fVojqJlVoMlbZnlTmu3S0TLwLTJpvBMO1Aw==",
       "license": "MIT",
       "dependencies": {
-        "@csstools/css-calc": "^3.0.0",
-        "@csstools/css-color-parser": "^4.0.1",
+        "@csstools/css-calc": "^3.1.1",
+        "@csstools/css-color-parser": "^4.0.2",
         "@csstools/css-parser-algorithms": "^4.0.0",
         "@csstools/css-tokenizer": "^4.0.0",
-        "lru-cache": "^11.2.5"
+        "lru-cache": "^11.2.6"
+      },
+      "engines": {
+        "node": "^20.19.0 || ^22.12.0 || >=24.0.0"
       }
     },
     "node_modules/@asamuzakjp/css-color/node_modules/lru-cache": {
-      "version": "11.2.6",
-      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.2.6.tgz",
-      "integrity": "sha512-ESL2CrkS/2wTPfuend7Zhkzo2u0daGJ/A2VucJOgQ/C48S/zB8MMeMHSGKYpXhIjbPxfuezITkaBH1wqv00DDQ==",
+      "version": "11.2.7",
+      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.2.7.tgz",
+      "integrity": "sha512-aY/R+aEsRelme17KGQa/1ZSIpLpNYYrhcrepKTZgE+W3WM16YMCaPwOHLHsmopZHELU0Ojin1lPVxKR0MihncA==",
       "license": "BlueOak-1.0.0",
       "engines": {
         "node": "20 || >=22"
       }
     },
     "node_modules/@asamuzakjp/dom-selector": {
-      "version": "6.8.1",
-      "resolved": "https://registry.npmjs.org/@asamuzakjp/dom-selector/-/dom-selector-6.8.1.tgz",
-      "integrity": "sha512-MvRz1nCqW0fsy8Qz4dnLIvhOlMzqDVBabZx6lH+YywFDdjXhMY37SmpV1XFX3JzG5GWHn63j6HX6QPr3lZXHvQ==",
+      "version": "7.0.3",
+      "resolved": "https://registry.npmjs.org/@asamuzakjp/dom-selector/-/dom-selector-7.0.3.tgz",
+      "integrity": "sha512-Q6mU0Z6bfj6YvnX2k9n0JxiIwrCFN59x/nWmYQnAqP000ruX/yV+5bp/GRcF5T8ncvfwJQ7fgfP74DlpKExILA==",
       "license": "MIT",
       "dependencies": {
         "@asamuzakjp/nwsapi": "^2.3.9",
         "bidi-js": "^1.0.3",
-        "css-tree": "^3.1.0",
+        "css-tree": "^3.2.1",
         "is-potential-custom-element-name": "^1.0.1",
-        "lru-cache": "^11.2.6"
+        "lru-cache": "^11.2.7"
+      },
+      "engines": {
+        "node": "^20.19.0 || ^22.12.0 || >=24.0.0"
       }
     },
     "node_modules/@asamuzakjp/dom-selector/node_modules/lru-cache": {
-      "version": "11.2.6",
-      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.2.6.tgz",
-      "integrity": "sha512-ESL2CrkS/2wTPfuend7Zhkzo2u0daGJ/A2VucJOgQ/C48S/zB8MMeMHSGKYpXhIjbPxfuezITkaBH1wqv00DDQ==",
+      "version": "11.2.7",
+      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.2.7.tgz",
+      "integrity": "sha512-aY/R+aEsRelme17KGQa/1ZSIpLpNYYrhcrepKTZgE+W3WM16YMCaPwOHLHsmopZHELU0Ojin1lPVxKR0MihncA==",
       "license": "BlueOak-1.0.0",
       "engines": {
         "node": "20 || >=22"
@@ -295,12 +295,12 @@
       "license": "MIT"
     },
     "node_modules/@astrojs/check": {
-      "version": "0.9.7",
-      "resolved": "https://registry.npmjs.org/@astrojs/check/-/check-0.9.7.tgz",
-      "integrity": "sha512-dA7U5/OFg8/xaMUb2vUOOJuuJXnMpHy6F0BM8ZhL7WT5OkTBwJ0GoW38n4fC4CXt+lT9mLWL0y8Pa74tFByBpQ==",
+      "version": "0.9.8",
+      "resolved": "https://registry.npmjs.org/@astrojs/check/-/check-0.9.8.tgz",
+      "integrity": "sha512-LDng8446QLS5ToKjRHd3bgUdirvemVVExV7nRyJfW2wV36xuv7vDxwy5NWN9zqeSEDgg0Tv84sP+T3yEq+Zlkw==",
       "license": "MIT",
       "dependencies": {
-        "@astrojs/language-server": "^2.16.1",
+        "@astrojs/language-server": "^2.16.5",
         "chokidar": "^4.0.3",
         "kleur": "^4.1.5",
         "yargs": "^17.7.2"
@@ -313,9 +313,9 @@
       }
     },
     "node_modules/@astrojs/compiler": {
-      "version": "2.13.0",
-      "resolved": "https://registry.npmjs.org/@astrojs/compiler/-/compiler-2.13.0.tgz",
-      "integrity": "sha512-mqVORhUJViA28fwHYaWmsXSzLO9osbdZ5ImUfxBarqsYdMlPbqAqGJCxsNzvppp1BEzc1mJNjOVvQqeDN8Vspw==",
+      "version": "2.13.1",
+      "resolved": "https://registry.npmjs.org/@astrojs/compiler/-/compiler-2.13.1.tgz",
+      "integrity": "sha512-f3FN83d2G/v32ipNClRKgYv30onQlMZX1vCeZMjPsMMPl1mDpmbl0+N5BYo4S/ofzqJyS5hvwacEo0CCVDn/Qg==",
       "license": "MIT"
     },
     "node_modules/@astrojs/db": {
@@ -383,28 +383,28 @@
       }
     },
     "node_modules/@astrojs/language-server": {
-      "version": "2.16.1",
-      "resolved": "https://registry.npmjs.org/@astrojs/language-server/-/language-server-2.16.1.tgz",
-      "integrity": "sha512-OzTpyEPeCPLpp0oyeI/fSCBYemlVos0GewCTYglAW+TAJAMR3nRl5nYlf9ESMFy97SlptZCsRdKlQXDvFHJRNQ==",
-      "license": "MIT",
-      "dependencies": {
-        "@astrojs/compiler": "^2.10.3",
-        "@astrojs/yaml2ts": "^0.2.2",
-        "@jridgewell/sourcemap-codec": "^1.4.15",
-        "@volar/kit": "~2.4.23",
-        "@volar/language-core": "~2.4.23",
-        "@volar/language-server": "~2.4.23",
-        "@volar/language-service": "~2.4.23",
-        "fast-glob": "^3.2.12",
+      "version": "2.16.5",
+      "resolved": "https://registry.npmjs.org/@astrojs/language-server/-/language-server-2.16.5.tgz",
+      "integrity": "sha512-MEQvrbuiFDEo+LCO4vvYuTr3eZ4IluZ/n4BbUv77AWAJNEj/n0j7VqTvdL1rGloNTIKZTUd46p5RwYKsxQGY8w==",
+      "license": "MIT",
+      "dependencies": {
+        "@astrojs/compiler": "^2.13.1",
+        "@astrojs/yaml2ts": "^0.2.3",
+        "@jridgewell/sourcemap-codec": "^1.5.5",
+        "@volar/kit": "~2.4.28",
+        "@volar/language-core": "~2.4.28",
+        "@volar/language-server": "~2.4.28",
+        "@volar/language-service": "~2.4.28",
         "muggle-string": "^0.4.1",
-        "volar-service-css": "0.0.66",
-        "volar-service-emmet": "0.0.66",
-        "volar-service-html": "0.0.66",
-        "volar-service-prettier": "0.0.66",
-        "volar-service-typescript": "0.0.66",
-        "volar-service-typescript-twoslash-queries": "0.0.66",
-        "volar-service-yaml": "0.0.66",
-        "vscode-html-languageservice": "^5.5.2",
+        "tinyglobby": "^0.2.15",
+        "volar-service-css": "0.0.70",
+        "volar-service-emmet": "0.0.70",
+        "volar-service-html": "0.0.70",
+        "volar-service-prettier": "0.0.70",
+        "volar-service-typescript": "0.0.70",
+        "volar-service-typescript-twoslash-queries": "0.0.70",
+        "volar-service-yaml": "0.0.70",
+        "vscode-html-languageservice": "^5.6.2",
         "vscode-uri": "^3.1.0"
       },
       "bin": {
@@ -452,9 +452,9 @@
       }
     },
     "node_modules/@astrojs/mdx": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/@astrojs/mdx/-/mdx-5.0.0.tgz",
-      "integrity": "sha512-J4rW6eT+qgVw7+RXdBYO4vYyWGeXXQp8wop9dXsOlLzIsVSxyttMCgkGCWvIR2ogBqKqeYgI6YDW93PaDHkCaA==",
+      "version": "5.0.1",
+      "resolved": "https://registry.npmjs.org/@astrojs/mdx/-/mdx-5.0.1.tgz",
+      "integrity": "sha512-xfvc9MuV/5Kl6JaiYYEFi7ilbGYyaaOboH+gH8f2jHAZ2pmmHtnSrewS03vNeruBsa8rtS3X8NHJrqeZt+0wLg==",
       "license": "MIT",
       "dependencies": {
         "@astrojs/markdown-remark": "7.0.0",
@@ -475,13 +475,13 @@
         "node": "^20.19.1 || >=22.12.0"
       },
       "peerDependencies": {
-        "astro": "^6.0.0-alpha.0"
+        "astro": "^6.0.0"
       }
     },
     "node_modules/@astrojs/preact": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/@astrojs/preact/-/preact-5.0.0.tgz",
-      "integrity": "sha512-KJBLQtKxmx/MnNMqDNFFp2N6o430eyx90uaLKJS4IzUnR0fOgekyGOPjE+3deuetIS+7uNcp1kALpLPG21/tFQ==",
+      "version": "5.0.1",
+      "resolved": "https://registry.npmjs.org/@astrojs/preact/-/preact-5.0.1.tgz",
+      "integrity": "sha512-KGX2Eku/6Og21+zoIvIDCGoMbMvX+lX4mCxx2A7FUBg539jkw6czmRpnm0VEIy5RvNOsTh7AAtzgmnB00t2c1A==",
       "license": "MIT",
       "dependencies": {
         "@astrojs/internal-helpers": "0.8.0",
@@ -705,9 +705,9 @@
       }
     },
     "node_modules/@astrojs/vercel": {
-      "version": "10.0.0",
-      "resolved": "https://registry.npmjs.org/@astrojs/vercel/-/vercel-10.0.0.tgz",
-      "integrity": "sha512-U80Lswq1zZporn8DFBrtmAkjQyUns9lN22YPoFGV1NsvKJJy/2XGuoo+NDRK8C98eqpUOLtwXtFFmw0QDV5JYA==",
+      "version": "10.0.1",
+      "resolved": "https://registry.npmjs.org/@astrojs/vercel/-/vercel-10.0.1.tgz",
+      "integrity": "sha512-Ghl8L2ckDuNbfHbYYTRymUn87YrNTWD64Zz0zwYaGlZDkrG2nT3pmAU5BqzfOOV4Yvzgqxea+HEiEn6puefQZQ==",
       "license": "MIT",
       "dependencies": {
         "@astrojs/internal-helpers": "0.8.0",
@@ -719,7 +719,7 @@
         "tinyglobby": "^0.2.15"
       },
       "peerDependencies": {
-        "astro": "^6.0.0-alpha.0"
+        "astro": "^6.0.0"
       }
     },
     "node_modules/@astrojs/vercel/node_modules/@vercel/analytics": {
@@ -761,12 +761,12 @@
       }
     },
     "node_modules/@astrojs/yaml2ts": {
-      "version": "0.2.2",
-      "resolved": "https://registry.npmjs.org/@astrojs/yaml2ts/-/yaml2ts-0.2.2.tgz",
-      "integrity": "sha512-GOfvSr5Nqy2z5XiwqTouBBpy5FyI6DEe+/g/Mk5am9SjILN1S5fOEvYK0GuWHg98yS/dobP4m8qyqw/URW35fQ==",
+      "version": "0.2.3",
+      "resolved": "https://registry.npmjs.org/@astrojs/yaml2ts/-/yaml2ts-0.2.3.tgz",
+      "integrity": "sha512-PJzRmgQzUxI2uwpdX2lXSHtP4G8ocp24/t+bZyf5Fy0SZLSF9f9KXZoMlFM/XCGue+B0nH/2IZ7FpBYQATBsCg==",
       "license": "MIT",
       "dependencies": {
-        "yaml": "^2.5.0"
+        "yaml": "^2.8.2"
       }
     },
     "node_modules/@axe-core/playwright": {
@@ -2424,9 +2424,9 @@
       }
     },
     "node_modules/@csstools/color-helpers": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/@csstools/color-helpers/-/color-helpers-6.0.1.tgz",
-      "integrity": "sha512-NmXRccUJMk2AWA5A7e5a//3bCIMyOu2hAtdRYrhPPHjDxINuCwX1w6rnIZ4xjLcp0ayv6h8Pc3X0eJUGiAAXHQ==",
+      "version": "6.0.2",
+      "resolved": "https://registry.npmjs.org/@csstools/color-helpers/-/color-helpers-6.0.2.tgz",
+      "integrity": "sha512-LMGQLS9EuADloEFkcTBR3BwV/CGHV7zyDxVRtVDTwdI2Ca4it0CCVTT9wCkxSgokjE5Ho41hEPgb8OEUwoXr6Q==",
       "funding": [
         {
           "type": "github",
@@ -2466,9 +2466,9 @@
       }
     },
     "node_modules/@csstools/css-color-parser": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/@csstools/css-color-parser/-/css-color-parser-4.0.1.tgz",
-      "integrity": "sha512-vYwO15eRBEkeF6xjAno/KQ61HacNhfQuuU/eGwH67DplL0zD5ZixUa563phQvUelA07yDczIXdtmYojCphKJcw==",
+      "version": "4.0.2",
+      "resolved": "https://registry.npmjs.org/@csstools/css-color-parser/-/css-color-parser-4.0.2.tgz",
+      "integrity": "sha512-0GEfbBLmTFf0dJlpsNU7zwxRIH0/BGEMuXLTCvFYxuL1tNhqzTbtnFICyJLTNK4a+RechKP75e7w42ClXSnJQw==",
       "funding": [
         {
           "type": "github",
@@ -2481,8 +2481,8 @@
       ],
       "license": "MIT",
       "dependencies": {
-        "@csstools/color-helpers": "^6.0.1",
-        "@csstools/css-calc": "^3.0.0"
+        "@csstools/color-helpers": "^6.0.2",
+        "@csstools/css-calc": "^3.1.1"
       },
       "engines": {
         "node": ">=20.19.0"
@@ -2515,9 +2515,9 @@
       }
     },
     "node_modules/@csstools/css-syntax-patches-for-csstree": {
-      "version": "1.0.28",
-      "resolved": "https://registry.npmjs.org/@csstools/css-syntax-patches-for-csstree/-/css-syntax-patches-for-csstree-1.0.28.tgz",
-      "integrity": "sha512-1NRf1CUBjnr3K7hu8BLxjQrKCxEe8FP/xmPTenAxCRZWVLbmGotkFvG9mfNpjA6k7Bw1bw4BilZq9cu19RA5pg==",
+      "version": "1.1.1",
+      "resolved": "https://registry.npmjs.org/@csstools/css-syntax-patches-for-csstree/-/css-syntax-patches-for-csstree-1.1.1.tgz",
+      "integrity": "sha512-BvqN0AMWNAnLk9G8jnUT77D+mUbY/H2b3uDTvg2isJkHaOufUE2R3AOwxWo7VBQKT1lOdwdvorddo2B/lk64+w==",
       "funding": [
         {
           "type": "github",
@@ -2528,7 +2528,15 @@
           "url": "https://opencollective.com/csstools"
         }
       ],
-      "license": "MIT-0"
+      "license": "MIT-0",
+      "peerDependencies": {
+        "css-tree": "^3.2.1"
+      },
+      "peerDependenciesMeta": {
+        "css-tree": {
+          "optional": true
+        }
+      }
     },
     "node_modules/@csstools/css-tokenizer": {
       "version": "4.0.0",
@@ -2639,8 +2647,9 @@
       }
     },
     "node_modules/@emmetio/css-parser": {
-      "version": "0.4.0",
-      "resolved": "git+ssh://git@github.com/ramya-rao-a/css-parser.git#370c480ac103bd17c7bcfb34bf5d577dc40d3660",
+      "version": "0.4.1",
+      "resolved": "https://registry.npmjs.org/@emmetio/css-parser/-/css-parser-0.4.1.tgz",
+      "integrity": "sha512-2bC6m0MV/voF4CTZiAbG5MWKbq5EBmDPKu9Sb7s7nVcEzNQlrZP6mFFFlIaISM8X6514H9shWMme1fCm8cWAfQ==",
       "license": "MIT",
       "dependencies": {
         "@emmetio/stream-reader": "^2.2.0",
@@ -3324,9 +3333,9 @@
       }
     },
     "node_modules/@exodus/bytes": {
-      "version": "1.11.0",
-      "resolved": "https://registry.npmjs.org/@exodus/bytes/-/bytes-1.11.0.tgz",
-      "integrity": "sha512-wO3vd8nsEHdumsXrjGO/v4p6irbg7hy9kvIeR6i2AwylZSk4HJdWgL0FNaVquW1+AweJcdvU1IEpuIWk/WaPnA==",
+      "version": "1.15.0",
+      "resolved": "https://registry.npmjs.org/@exodus/bytes/-/bytes-1.15.0.tgz",
+      "integrity": "sha512-UY0nlA+feH81UGSHv92sLEPLCeZFjXOuHhrIo0HQydScuQc8s0A7kL/UdgwgDq8g8ilksmuoF35YVTNphV2aBQ==",
       "license": "MIT",
       "engines": {
         "node": "^20.19.0 || ^22.12.0 || >=24.0.0"
@@ -6671,9 +6680,9 @@
       "license": "MIT"
     },
     "node_modules/@semantic-ui/astro-lit": {
-      "version": "5.1.2",
-      "resolved": "https://registry.npmjs.org/@semantic-ui/astro-lit/-/astro-lit-5.1.2.tgz",
-      "integrity": "sha512-FZ7J9oLWX08WK8G87BtrDZ+wRbc3Ui83sDr3t2fkTp+ZsbU3vGsywq7jS9SMyIaGbFNUARk7kUTUsSBtpLDLpg==",
+      "version": "5.3.0",
+      "resolved": "https://registry.npmjs.org/@semantic-ui/astro-lit/-/astro-lit-5.3.0.tgz",
+      "integrity": "sha512-IQ/EPmHg7RQUfvwhhp1uy+zcZ+037AVs7fGpfLQLfhcQNg+mjAeFqu6Eyx6X2YSH6Jt4ZvyDqRzIkCj3gxyBrA==",
       "license": "MIT",
       "dependencies": {
         "@lit-labs/ssr": "^3.3.1",
@@ -8638,16 +8647,16 @@
       }
     },
     "node_modules/@typescript-eslint/eslint-plugin": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/eslint-plugin/-/eslint-plugin-8.57.0.tgz",
-      "integrity": "sha512-qeu4rTHR3/IaFORbD16gmjq9+rEs9fGKdX0kF6BKSfi+gCuG3RCKLlSBYzn/bGsY9Tj7KE/DAQStbp8AHJGHEQ==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/eslint-plugin/-/eslint-plugin-8.57.1.tgz",
+      "integrity": "sha512-Gn3aqnvNl4NGc6x3/Bqk1AOn0thyTU9bqDRhiRnUWezgvr2OnhYCWCgC8zXXRVqBsIL1pSDt7T9nJUe0oM0kDQ==",
       "license": "MIT",
       "dependencies": {
         "@eslint-community/regexpp": "^4.12.2",
-        "@typescript-eslint/scope-manager": "8.57.0",
-        "@typescript-eslint/type-utils": "8.57.0",
-        "@typescript-eslint/utils": "8.57.0",
-        "@typescript-eslint/visitor-keys": "8.57.0",
+        "@typescript-eslint/scope-manager": "8.57.1",
+        "@typescript-eslint/type-utils": "8.57.1",
+        "@typescript-eslint/utils": "8.57.1",
+        "@typescript-eslint/visitor-keys": "8.57.1",
         "ignore": "^7.0.5",
         "natural-compare": "^1.4.0",
         "ts-api-utils": "^2.4.0"
@@ -8660,7 +8669,7 @@
         "url": "https://opencollective.com/typescript-eslint"
       },
       "peerDependencies": {
-        "@typescript-eslint/parser": "^8.57.0",
+        "@typescript-eslint/parser": "^8.57.1",
         "eslint": "^8.57.0 || ^9.0.0 || ^10.0.0",
         "typescript": ">=4.8.4 <6.0.0"
       }
@@ -8675,15 +8684,15 @@
       }
     },
     "node_modules/@typescript-eslint/parser": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/parser/-/parser-8.57.0.tgz",
-      "integrity": "sha512-XZzOmihLIr8AD1b9hL9ccNMzEMWt/dE2u7NyTY9jJG6YNiNthaD5XtUHVF2uCXZ15ng+z2hT3MVuxnUYhq6k1g==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/parser/-/parser-8.57.1.tgz",
+      "integrity": "sha512-k4eNDan0EIMTT/dUKc/g+rsJ6wcHYhNPdY19VoX/EOtaAG8DLtKCykhrUnuHPYvinn5jhAPgD2Qw9hXBwrahsw==",
       "license": "MIT",
       "dependencies": {
-        "@typescript-eslint/scope-manager": "8.57.0",
-        "@typescript-eslint/types": "8.57.0",
-        "@typescript-eslint/typescript-estree": "8.57.0",
-        "@typescript-eslint/visitor-keys": "8.57.0",
+        "@typescript-eslint/scope-manager": "8.57.1",
+        "@typescript-eslint/types": "8.57.1",
+        "@typescript-eslint/typescript-estree": "8.57.1",
+        "@typescript-eslint/visitor-keys": "8.57.1",
         "debug": "^4.4.3"
       },
       "engines": {
@@ -8699,13 +8708,13 @@
       }
     },
     "node_modules/@typescript-eslint/project-service": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/project-service/-/project-service-8.57.0.tgz",
-      "integrity": "sha512-pR+dK0BlxCLxtWfaKQWtYr7MhKmzqZxuii+ZjuFlZlIGRZm22HnXFqa2eY+90MUz8/i80YJmzFGDUsi8dMOV5w==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/project-service/-/project-service-8.57.1.tgz",
+      "integrity": "sha512-vx1F37BRO1OftsYlmG9xay1TqnjNVlqALymwWVuYTdo18XuKxtBpCj1QlzNIEHlvlB27osvXFWptYiEWsVdYsg==",
       "license": "MIT",
       "dependencies": {
-        "@typescript-eslint/tsconfig-utils": "^8.57.0",
-        "@typescript-eslint/types": "^8.57.0",
+        "@typescript-eslint/tsconfig-utils": "^8.57.1",
+        "@typescript-eslint/types": "^8.57.1",
         "debug": "^4.4.3"
       },
       "engines": {
@@ -8720,13 +8729,13 @@
       }
     },
     "node_modules/@typescript-eslint/scope-manager": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/scope-manager/-/scope-manager-8.57.0.tgz",
-      "integrity": "sha512-nvExQqAHF01lUM66MskSaZulpPL5pgy5hI5RfrxviLgzZVffB5yYzw27uK/ft8QnKXI2X0LBrHJFr1TaZtAibw==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/scope-manager/-/scope-manager-8.57.1.tgz",
+      "integrity": "sha512-hs/QcpCwlwT2L5S+3fT6gp0PabyGk4Q0Rv2doJXA0435/OpnSR3VRgvrp8Xdoc3UAYSg9cyUjTeFXZEPg/3OKg==",
       "license": "MIT",
       "dependencies": {
-        "@typescript-eslint/types": "8.57.0",
-        "@typescript-eslint/visitor-keys": "8.57.0"
+        "@typescript-eslint/types": "8.57.1",
+        "@typescript-eslint/visitor-keys": "8.57.1"
       },
       "engines": {
         "node": "^18.18.0 || ^20.9.0 || >=21.1.0"
@@ -8737,9 +8746,9 @@
       }
     },
     "node_modules/@typescript-eslint/tsconfig-utils": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/tsconfig-utils/-/tsconfig-utils-8.57.0.tgz",
-      "integrity": "sha512-LtXRihc5ytjJIQEH+xqjB0+YgsV4/tW35XKX3GTZHpWtcC8SPkT/d4tqdf1cKtesryHm2bgp6l555NYcT2NLvA==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/tsconfig-utils/-/tsconfig-utils-8.57.1.tgz",
+      "integrity": "sha512-0lgOZB8cl19fHO4eI46YUx2EceQqhgkPSuCGLlGi79L2jwYY1cxeYc1Nae8Aw1xjgW3PKVDLlr3YJ6Bxx8HkWg==",
       "license": "MIT",
       "engines": {
         "node": "^18.18.0 || ^20.9.0 || >=21.1.0"
@@ -8753,14 +8762,14 @@
       }
     },
     "node_modules/@typescript-eslint/type-utils": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/type-utils/-/type-utils-8.57.0.tgz",
-      "integrity": "sha512-yjgh7gmDcJ1+TcEg8x3uWQmn8ifvSupnPfjP21twPKrDP/pTHlEQgmKcitzF/rzPSmv7QjJ90vRpN4U+zoUjwQ==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/type-utils/-/type-utils-8.57.1.tgz",
+      "integrity": "sha512-+Bwwm0ScukFdyoJsh2u6pp4S9ktegF98pYUU0hkphOOqdMB+1sNQhIz8y5E9+4pOioZijrkfNO/HUJVAFFfPKA==",
       "license": "MIT",
       "dependencies": {
-        "@typescript-eslint/types": "8.57.0",
-        "@typescript-eslint/typescript-estree": "8.57.0",
-        "@typescript-eslint/utils": "8.57.0",
+        "@typescript-eslint/types": "8.57.1",
+        "@typescript-eslint/typescript-estree": "8.57.1",
+        "@typescript-eslint/utils": "8.57.1",
         "debug": "^4.4.3",
         "ts-api-utils": "^2.4.0"
       },
@@ -8777,9 +8786,9 @@
       }
     },
     "node_modules/@typescript-eslint/types": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/types/-/types-8.57.0.tgz",
-      "integrity": "sha512-dTLI8PEXhjUC7B9Kre+u0XznO696BhXcTlOn0/6kf1fHaQW8+VjJAVHJ3eTI14ZapTxdkOmc80HblPQLaEeJdg==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/types/-/types-8.57.1.tgz",
+      "integrity": "sha512-S29BOBPJSFUiblEl6RzPPjJt6w25A6XsBqRVDt53tA/tlL8q7ceQNZHTjPeONt/3S7KRI4quk+yP9jK2WjBiPQ==",
       "license": "MIT",
       "engines": {
         "node": "^18.18.0 || ^20.9.0 || >=21.1.0"
@@ -8790,15 +8799,15 @@
       }
     },
     "node_modules/@typescript-eslint/typescript-estree": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/typescript-estree/-/typescript-estree-8.57.0.tgz",
-      "integrity": "sha512-m7faHcyVg0BT3VdYTlX8GdJEM7COexXxS6KqGopxdtkQRvBanK377QDHr4W/vIPAR+ah9+B/RclSW5ldVniO1Q==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/typescript-estree/-/typescript-estree-8.57.1.tgz",
+      "integrity": "sha512-ybe2hS9G6pXpqGtPli9Gx9quNV0TWLOmh58ADlmZe9DguLq0tiAKVjirSbtM1szG6+QH6rVXyU6GTLQbWnMY+g==",
       "license": "MIT",
       "dependencies": {
-        "@typescript-eslint/project-service": "8.57.0",
-        "@typescript-eslint/tsconfig-utils": "8.57.0",
-        "@typescript-eslint/types": "8.57.0",
-        "@typescript-eslint/visitor-keys": "8.57.0",
+        "@typescript-eslint/project-service": "8.57.1",
+        "@typescript-eslint/tsconfig-utils": "8.57.1",
+        "@typescript-eslint/types": "8.57.1",
+        "@typescript-eslint/visitor-keys": "8.57.1",
         "debug": "^4.4.3",
         "minimatch": "^10.2.2",
         "semver": "^7.7.3",
@@ -8865,15 +8874,15 @@
       }
     },
     "node_modules/@typescript-eslint/utils": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/utils/-/utils-8.57.0.tgz",
-      "integrity": "sha512-5iIHvpD3CZe06riAsbNxxreP+MuYgVUsV0n4bwLH//VJmgtt54sQeY2GszntJ4BjYCpMzrfVh2SBnUQTtys2lQ==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/utils/-/utils-8.57.1.tgz",
+      "integrity": "sha512-XUNSJ/lEVFttPMMoDVA2r2bwrl8/oPx8cURtczkSEswY5T3AeLmCy+EKWQNdL4u0MmAHOjcWrqJp2cdvgjn8dQ==",
       "license": "MIT",
       "dependencies": {
         "@eslint-community/eslint-utils": "^4.9.1",
-        "@typescript-eslint/scope-manager": "8.57.0",
-        "@typescript-eslint/types": "8.57.0",
-        "@typescript-eslint/typescript-estree": "8.57.0"
+        "@typescript-eslint/scope-manager": "8.57.1",
+        "@typescript-eslint/types": "8.57.1",
+        "@typescript-eslint/typescript-estree": "8.57.1"
       },
       "engines": {
         "node": "^18.18.0 || ^20.9.0 || >=21.1.0"
@@ -8888,12 +8897,12 @@
       }
     },
     "node_modules/@typescript-eslint/visitor-keys": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/@typescript-eslint/visitor-keys/-/visitor-keys-8.57.0.tgz",
-      "integrity": "sha512-zm6xx8UT/Xy2oSr2ZXD0pZo7Jx2XsCoID2IUh9YSTFRu7z+WdwYTRk6LhUftm1crwqbuoF6I8zAFeCMw0YjwDg==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/@typescript-eslint/visitor-keys/-/visitor-keys-8.57.1.tgz",
+      "integrity": "sha512-YWnmJkXbofiz9KbnbbwuA2rpGkFPLbAIetcCNO6mJ8gdhdZ/v7WDXsoGFAJuM6ikUFKTlSQnjWnVO4ux+UzS6A==",
       "license": "MIT",
       "dependencies": {
-        "@typescript-eslint/types": "8.57.0",
+        "@typescript-eslint/types": "8.57.1",
         "eslint-visitor-keys": "^5.0.0"
       },
       "engines": {
@@ -12487,13 +12496,13 @@
       }
     },
     "node_modules/@volar/kit": {
-      "version": "2.4.26",
-      "resolved": "https://registry.npmjs.org/@volar/kit/-/kit-2.4.26.tgz",
-      "integrity": "sha512-shgNg7PbV8SIxxQLOQh5zMr8KV0JvdG9If0MwJb5L1HMrBU91jBxR0ANi2OJPMMme6/l1vIYm4hCaO6W2JaEcQ==",
+      "version": "2.4.28",
+      "resolved": "https://registry.npmjs.org/@volar/kit/-/kit-2.4.28.tgz",
+      "integrity": "sha512-cKX4vK9dtZvDRaAzeoUdaAJEew6IdxHNCRrdp5Kvcl6zZOqb6jTOfk3kXkIkG3T7oTFXguEMt5+9ptyqYR84Pg==",
       "license": "MIT",
       "dependencies": {
-        "@volar/language-service": "2.4.26",
-        "@volar/typescript": "2.4.26",
+        "@volar/language-service": "2.4.28",
+        "@volar/typescript": "2.4.28",
         "typesafe-path": "^0.2.2",
         "vscode-languageserver-textdocument": "^1.0.11",
         "vscode-uri": "^3.0.8"
@@ -12503,23 +12512,23 @@
       }
     },
     "node_modules/@volar/language-core": {
-      "version": "2.4.26",
-      "resolved": "https://registry.npmjs.org/@volar/language-core/-/language-core-2.4.26.tgz",
-      "integrity": "sha512-hH0SMitMxnB43OZpyF1IFPS9bgb2I3bpCh76m2WEK7BE0A0EzpYsRp0CCH2xNKshr7kacU5TQBLYn4zj7CG60A==",
+      "version": "2.4.28",
+      "resolved": "https://registry.npmjs.org/@volar/language-core/-/language-core-2.4.28.tgz",
+      "integrity": "sha512-w4qhIJ8ZSitgLAkVay6AbcnC7gP3glYM3fYwKV3srj8m494E3xtrCv6E+bWviiK/8hs6e6t1ij1s2Endql7vzQ==",
       "license": "MIT",
       "dependencies": {
-        "@volar/source-map": "2.4.26"
+        "@volar/source-map": "2.4.28"
       }
     },
     "node_modules/@volar/language-server": {
-      "version": "2.4.26",
-      "resolved": "https://registry.npmjs.org/@volar/language-server/-/language-server-2.4.26.tgz",
-      "integrity": "sha512-Xsyu+VDgM8TyVkQfBz2aIViSEOgH2un0gIJlp0M8rssDDLCqr4ssQzwHOyPf7sT7UIjrlAMnJvRkC/u0mmgtYw==",
+      "version": "2.4.28",
+      "resolved": "https://registry.npmjs.org/@volar/language-server/-/language-server-2.4.28.tgz",
+      "integrity": "sha512-NqcLnE5gERKuS4PUFwlhMxf6vqYo7hXtbMFbViXcbVkbZ905AIVWhnSo0ZNBC2V127H1/2zP7RvVOVnyITFfBw==",
       "license": "MIT",
       "dependencies": {
-        "@volar/language-core": "2.4.26",
-        "@volar/language-service": "2.4.26",
-        "@volar/typescript": "2.4.26",
+        "@volar/language-core": "2.4.28",
+        "@volar/language-service": "2.4.28",
+        "@volar/typescript": "2.4.28",
         "path-browserify": "^1.0.1",
         "request-light": "^0.7.0",
         "vscode-languageserver": "^9.0.1",
@@ -12529,30 +12538,30 @@
       }
     },
     "node_modules/@volar/language-service": {
-      "version": "2.4.26",
-      "resolved": "https://registry.npmjs.org/@volar/language-service/-/language-service-2.4.26.tgz",
-      "integrity": "sha512-ZBPRR1ytXttSV5X4VPvEQR/glxs+7/4IOJIBCOW3/EJk4z77R4mF2y4wM3fNgOXXZT5h16j3sC5w+LGNkz2VlA==",
+      "version": "2.4.28",
+      "resolved": "https://registry.npmjs.org/@volar/language-service/-/language-service-2.4.28.tgz",
+      "integrity": "sha512-Rh/wYCZJrI5vCwMk9xyw/Z+MsWxlJY1rmMZPsxUoJKfzIRjS/NF1NmnuEcrMbEVGja00aVpCsInJfixQTMdvLw==",
       "license": "MIT",
       "dependencies": {
-        "@volar/language-core": "2.4.26",
+        "@volar/language-core": "2.4.28",
         "vscode-languageserver-protocol": "^3.17.5",
         "vscode-languageserver-textdocument": "^1.0.11",
         "vscode-uri": "^3.0.8"
       }
     },
     "node_modules/@volar/source-map": {
-      "version": "2.4.26",
-      "resolved": "https://registry.npmjs.org/@volar/source-map/-/source-map-2.4.26.tgz",
-      "integrity": "sha512-JJw0Tt/kSFsIRmgTQF4JSt81AUSI1aEye5Zl65EeZ8H35JHnTvFGmpDOBn5iOxd48fyGE+ZvZBp5FcgAy/1Qhw==",
+      "version": "2.4.28",
+      "resolved": "https://registry.npmjs.org/@volar/source-map/-/source-map-2.4.28.tgz",
+      "integrity": "sha512-yX2BDBqJkRXfKw8my8VarTyjv48QwxdJtvRgUpNE5erCsgEUdI2DsLbpa+rOQVAJYshY99szEcRDmyHbF10ggQ==",
       "license": "MIT"
     },
     "node_modules/@volar/typescript": {
-      "version": "2.4.26",
-      "resolved": "https://registry.npmjs.org/@volar/typescript/-/typescript-2.4.26.tgz",
-      "integrity": "sha512-N87ecLD48Sp6zV9zID/5yuS1+5foj0DfuYGdQ6KHj/IbKvyKv1zNX6VCmnKYwtmHadEO6mFc2EKISiu3RDPAvA==",
+      "version": "2.4.28",
+      "resolved": "https://registry.npmjs.org/@volar/typescript/-/typescript-2.4.28.tgz",
+      "integrity": "sha512-Ja6yvWrbis2QtN4ClAKreeUZPVYMARDYZl9LMEv1iQ1QdepB6wn0jTRxA9MftYmYa4DQ4k/DaSZpFPUfxl8giw==",
       "license": "MIT",
       "dependencies": {
-        "@volar/language-core": "2.4.26",
+        "@volar/language-core": "2.4.28",
         "path-browserify": "^1.0.1",
         "vscode-uri": "^3.0.8"
       }
@@ -14488,9 +14497,9 @@
       }
     },
     "node_modules/astro": {
-      "version": "6.0.4",
-      "resolved": "https://registry.npmjs.org/astro/-/astro-6.0.4.tgz",
-      "integrity": "sha512-1piLJCPTL/x7AMO2cjVFSTFyRqKuC3W8sSEySCt1aJio+p/wGs5H3K+Xr/rE9ftKtknLUtjxCqCE7/0NsXfGpQ==",
+      "version": "6.0.5",
+      "resolved": "https://registry.npmjs.org/astro/-/astro-6.0.5.tgz",
+      "integrity": "sha512-JnLCwaoCaRXIHuIB8yNztJrd7M3hXrHUMAoQmeXtEBKxRu/738REhaCZ1lapjrS9HlpHsWTu3JUXTERB/0PA7g==",
       "license": "MIT",
       "dependencies": {
         "@astrojs/compiler": "^3.0.0",
@@ -15268,9 +15277,9 @@
       "license": "MIT"
     },
     "node_modules/baseline-browser-mapping": {
-      "version": "2.10.7",
-      "resolved": "https://registry.npmjs.org/baseline-browser-mapping/-/baseline-browser-mapping-2.10.7.tgz",
-      "integrity": "sha512-1ghYO3HnxGec0TCGBXiDLVns4eCSx4zJpxnHrlqFQajmhfKMQBzUGDdkMK7fUW7PTHTeLf+j87aTuKuuwWzMGw==",
+      "version": "2.10.8",
+      "resolved": "https://registry.npmjs.org/baseline-browser-mapping/-/baseline-browser-mapping-2.10.8.tgz",
+      "integrity": "sha512-PCLz/LXGBsNTErbtB6i5u4eLpHeMfi93aUv5duMmj6caNu6IphS4q6UevDnL36sZQv9lrP11dbPKGMaXPwMKfQ==",
       "license": "Apache-2.0",
       "bin": {
         "baseline-browser-mapping": "dist/cli.cjs"
@@ -16541,13 +16550,13 @@
       }
     },
     "node_modules/css-tree": {
-      "version": "3.1.0",
-      "resolved": "https://registry.npmjs.org/css-tree/-/css-tree-3.1.0.tgz",
-      "integrity": "sha512-0eW44TGN5SQXU1mWSkKwFstI/22X2bG1nYzZTYMAWjylYURhse752YgbE4Cx46AC+bAvI+/dYTPRk1LqSUnu6w==",
+      "version": "3.2.1",
+      "resolved": "https://registry.npmjs.org/css-tree/-/css-tree-3.2.1.tgz",
+      "integrity": "sha512-X7sjQzceUhu1u7Y/ylrRZFU2FS6LRiFVp6rKLPg23y3x3c3DOKAwuXGDp+PAGjh6CSnCjYeAul8pcT8bAl+lSA==",
       "license": "MIT",
       "dependencies": {
-        "mdn-data": "2.12.2",
-        "source-map-js": "^1.0.1"
+        "mdn-data": "2.27.1",
+        "source-map-js": "^1.2.1"
       },
       "engines": {
         "node": "^10 || ^12.20.0 || ^14.13.0 || >=15.0.0"
@@ -16577,30 +16586,6 @@
         "node": ">=4"
       }
     },
-    "node_modules/cssstyle": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/cssstyle/-/cssstyle-6.0.1.tgz",
-      "integrity": "sha512-IoJs7La+oFp/AB033wBStxNOJt4+9hHMxsXUPANcoXL2b3W4DZKghlJ2cI/eyeRZIQ9ysvYEorVhjrcYctWbog==",
-      "license": "MIT",
-      "dependencies": {
-        "@asamuzakjp/css-color": "^4.1.2",
-        "@csstools/css-syntax-patches-for-csstree": "^1.0.26",
-        "css-tree": "^3.1.0",
-        "lru-cache": "^11.2.5"
-      },
-      "engines": {
-        "node": ">=20"
-      }
-    },
-    "node_modules/cssstyle/node_modules/lru-cache": {
-      "version": "11.2.6",
-      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.2.6.tgz",
-      "integrity": "sha512-ESL2CrkS/2wTPfuend7Zhkzo2u0daGJ/A2VucJOgQ/C48S/zB8MMeMHSGKYpXhIjbPxfuezITkaBH1wqv00DDQ==",
-      "license": "BlueOak-1.0.0",
-      "engines": {
-        "node": "20 || >=22"
-      }
-    },
     "node_modules/csstype": {
       "version": "3.2.3",
       "resolved": "https://registry.npmjs.org/csstype/-/csstype-3.2.3.tgz",
@@ -22651,35 +22636,35 @@
       }
     },
     "node_modules/jsdom": {
-      "version": "28.1.0",
-      "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-28.1.0.tgz",
-      "integrity": "sha512-0+MoQNYyr2rBHqO1xilltfDjV9G7ymYGlAUazgcDLQaUf8JDHbuGwsxN6U9qWaElZ4w1B2r7yEGIL3GdeW3Rug==",
+      "version": "29.0.0",
+      "resolved": "https://registry.npmjs.org/jsdom/-/jsdom-29.0.0.tgz",
+      "integrity": "sha512-9FshNB6OepopZ08unmmGpsF7/qCjxGPbo3NbgfJAnPeHXnsODE9WWffXZtRFRFe0ntzaAOcSKNJFz8wiyvF1jQ==",
       "license": "MIT",
       "dependencies": {
-        "@acemir/cssom": "^0.9.31",
-        "@asamuzakjp/dom-selector": "^6.8.1",
+        "@asamuzakjp/css-color": "^5.0.1",
+        "@asamuzakjp/dom-selector": "^7.0.2",
         "@bramus/specificity": "^2.4.2",
-        "@exodus/bytes": "^1.11.0",
-        "cssstyle": "^6.0.1",
+        "@csstools/css-syntax-patches-for-csstree": "^1.1.1",
+        "@exodus/bytes": "^1.15.0",
+        "css-tree": "^3.2.1",
         "data-urls": "^7.0.0",
         "decimal.js": "^10.6.0",
         "html-encoding-sniffer": "^6.0.0",
-        "http-proxy-agent": "^7.0.2",
-        "https-proxy-agent": "^7.0.6",
         "is-potential-custom-element-name": "^1.0.1",
+        "lru-cache": "^11.2.7",
         "parse5": "^8.0.0",
         "saxes": "^6.0.0",
         "symbol-tree": "^3.2.4",
-        "tough-cookie": "^6.0.0",
-        "undici": "^7.21.0",
+        "tough-cookie": "^6.0.1",
+        "undici": "^7.24.3",
         "w3c-xmlserializer": "^5.0.0",
         "webidl-conversions": "^8.0.1",
         "whatwg-mimetype": "^5.0.0",
-        "whatwg-url": "^16.0.0",
+        "whatwg-url": "^16.0.1",
         "xml-name-validator": "^5.0.0"
       },
       "engines": {
-        "node": "^20.19.0 || ^22.12.0 || >=24.0.0"
+        "node": "^20.19.0 || ^22.13.0 || >=24.0.0"
       },
       "peerDependencies": {
         "canvas": "^3.0.0"
@@ -22690,15 +22675,6 @@
         }
       }
     },
-    "node_modules/jsdom/node_modules/agent-base": {
-      "version": "7.1.4",
-      "resolved": "https://registry.npmjs.org/agent-base/-/agent-base-7.1.4.tgz",
-      "integrity": "sha512-MnA+YT8fwfJPgBx3m60MNqakm30XOkyIoH1y6huTQvC0PwZG7ki8NacLBcrPbNoo8vEZy7Jpuk7+jMO+CUovTQ==",
-      "license": "MIT",
-      "engines": {
-        "node": ">= 14"
-      }
-    },
     "node_modules/jsdom/node_modules/entities": {
       "version": "6.0.1",
       "resolved": "https://registry.npmjs.org/entities/-/entities-6.0.1.tgz",
@@ -22711,17 +22687,13 @@
         "url": "https://github.com/fb55/entities?sponsor=1"
       }
     },
-    "node_modules/jsdom/node_modules/https-proxy-agent": {
-      "version": "7.0.6",
-      "resolved": "https://registry.npmjs.org/https-proxy-agent/-/https-proxy-agent-7.0.6.tgz",
-      "integrity": "sha512-vK9P5/iUfdl95AI+JVyUuIcVtd4ofvtrOr3HNtM2yxC9bnMbEdp3x01OhQNnjb8IJYi38VlTE3mBXwcfvywuSw==",
-      "license": "MIT",
-      "dependencies": {
-        "agent-base": "^7.1.2",
-        "debug": "4"
-      },
+    "node_modules/jsdom/node_modules/lru-cache": {
+      "version": "11.2.7",
+      "resolved": "https://registry.npmjs.org/lru-cache/-/lru-cache-11.2.7.tgz",
+      "integrity": "sha512-aY/R+aEsRelme17KGQa/1ZSIpLpNYYrhcrepKTZgE+W3WM16YMCaPwOHLHsmopZHELU0Ojin1lPVxKR0MihncA==",
+      "license": "BlueOak-1.0.0",
       "engines": {
-        "node": ">= 14"
+        "node": "20 || >=22"
       }
     },
     "node_modules/jsdom/node_modules/parse5": {
@@ -22737,9 +22709,9 @@
       }
     },
     "node_modules/jsdom/node_modules/tough-cookie": {
-      "version": "6.0.0",
-      "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-6.0.0.tgz",
-      "integrity": "sha512-kXuRi1mtaKMrsLUxz3sQYvVl37B0Ns6MzfrtV5DvJceE9bPyspOqk9xxv7XbZWcfLWbFmm997vl83qUWVJA64w==",
+      "version": "6.0.1",
+      "resolved": "https://registry.npmjs.org/tough-cookie/-/tough-cookie-6.0.1.tgz",
+      "integrity": "sha512-LktZQb3IeoUWB9lqR5EWTHgW/VTITCXg4D21M+lvybRVdylLrRMnqaIONLVb5mav8vM19m44HIcGq4qASeu2Qw==",
       "license": "BSD-3-Clause",
       "dependencies": {
         "tldts": "^7.0.5"
@@ -22761,9 +22733,9 @@
       }
     },
     "node_modules/jsdom/node_modules/undici": {
-      "version": "7.21.0",
-      "resolved": "https://registry.npmjs.org/undici/-/undici-7.21.0.tgz",
-      "integrity": "sha512-Hn2tCQpoDt1wv23a68Ctc8Cr/BHpUSfaPYrkajTXOS9IKpxVRx/X5m1K2YkbK2ipgZgxXSgsUinl3x+2YdSSfg==",
+      "version": "7.24.4",
+      "resolved": "https://registry.npmjs.org/undici/-/undici-7.24.4.tgz",
+      "integrity": "sha512-BM/JzwwaRXxrLdElV2Uo6cTLEjhSb3WXboncJamZ15NgUURmvlXvxa6xkwIOILIjPNo9i8ku136ZvWV0Uly8+w==",
       "license": "MIT",
       "engines": {
         "node": ">=20.18.1"
@@ -22788,9 +22760,9 @@
       }
     },
     "node_modules/jsdom/node_modules/whatwg-url": {
-      "version": "16.0.0",
-      "resolved": "https://registry.npmjs.org/whatwg-url/-/whatwg-url-16.0.0.tgz",
-      "integrity": "sha512-9CcxtEKsf53UFwkSUZjG+9vydAsFO4lFHBpJUtjBcoJOCJpKnSJNwCw813zrYJHpCJ7sgfbtOe0V5Ku7Pa1XMQ==",
+      "version": "16.0.1",
+      "resolved": "https://registry.npmjs.org/whatwg-url/-/whatwg-url-16.0.1.tgz",
+      "integrity": "sha512-1to4zXBxmXHV3IiSSEInrreIlu02vUOvrhxJJH5vcxYTBDAx51cqZiKdyTxlecdKNSjj8EcxGBxNf6Vg+945gw==",
       "license": "MIT",
       "dependencies": {
         "@exodus/bytes": "^1.11.0",
@@ -25907,9 +25879,9 @@
       }
     },
     "node_modules/mdn-data": {
-      "version": "2.12.2",
-      "resolved": "https://registry.npmjs.org/mdn-data/-/mdn-data-2.12.2.tgz",
-      "integrity": "sha512-IEn+pegP1aManZuckezWCO+XZQDplx1366JoVhTpMpBB1sPey/SbveZQUosKiKiGYjg1wH4pMlNgXbCiYgihQA==",
+      "version": "2.27.1",
+      "resolved": "https://registry.npmjs.org/mdn-data/-/mdn-data-2.27.1.tgz",
+      "integrity": "sha512-9Yubnt3e8A0OKwxYSXyhLymGW4sCufcLG6VdiDdUGVkPhpqLxlvP5vl1983gQjJl3tqbrM731mjaZaP68AgosQ==",
       "license": "CC0-1.0"
     },
     "node_modules/mdurl": {
@@ -27155,9 +27127,9 @@
       }
     },
     "node_modules/nanostores": {
-      "version": "1.1.1",
-      "resolved": "https://registry.npmjs.org/nanostores/-/nanostores-1.1.1.tgz",
-      "integrity": "sha512-EYJqS25r2iBeTtGQCHidXl1VfZ1jXM7Q04zXJOrMlxVVmD0ptxJaNux92n1mJ7c5lN3zTq12MhH/8x59nP+qmg==",
+      "version": "1.2.0",
+      "resolved": "https://registry.npmjs.org/nanostores/-/nanostores-1.2.0.tgz",
+      "integrity": "sha512-F0wCzbsH80G7XXo0Jd9/AVQC7ouWY6idUCTnMwW5t/Rv9W8qmO6endavDwg7TNp5GbugwSukFMVZqzPSrSMndg==",
       "funding": [
         {
           "type": "github",
@@ -33381,13 +33353,13 @@
       }
     },
     "node_modules/resend": {
-      "version": "6.9.3",
-      "resolved": "https://registry.npmjs.org/resend/-/resend-6.9.3.tgz",
-      "integrity": "sha512-GRXjH9XZBJA+daH7bBVDuTShr22iWCxXA8P7t495G4dM/RC+d+3gHBK/6bz9K6Vpcq11zRQKmD+B+jECwQlyGQ==",
+      "version": "6.9.4",
+      "resolved": "https://registry.npmjs.org/resend/-/resend-6.9.4.tgz",
+      "integrity": "sha512-/M3dsJzu5OgozqVsA4Psd/1L7EdePgOIIxClas453GOQYFG3VHc2ZyCHZFlvqsc9aZCCd2BJRRqZgWC8D9c7/g==",
       "license": "MIT",
       "dependencies": {
         "postal-mime": "2.7.3",
-        "svix": "1.84.1"
+        "svix": "1.86.0"
       },
       "engines": {
         "node": ">=20"
@@ -35829,9 +35801,9 @@
       }
     },
     "node_modules/stylelint-order": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/stylelint-order/-/stylelint-order-8.0.0.tgz",
-      "integrity": "sha512-1oAwPRz6Ba8u9LPjgvdbeMjZszHhjY6DBBK+xMlS3IC89GdTsvAPpGYvW+dkn6pxc4ZaI1S959g4c8CftZbhIg==",
+      "version": "8.1.1",
+      "resolved": "https://registry.npmjs.org/stylelint-order/-/stylelint-order-8.1.1.tgz",
+      "integrity": "sha512-LqsEB6VggJuu5v10RtkrQsBObcdwBE7GuAOlwfc/LR3VL/w8UqKX2BOLIjhyGt0Gne/njo7gRNGiJAKhfmPMNw==",
       "license": "MIT",
       "dependencies": {
         "postcss": "^8.5.8",
@@ -36057,9 +36029,9 @@
       "integrity": "sha512-ovssysQTa+luh7A5Weu3Rta6FJlFBBbInjOh722LIt6klpU2/HtdUbszju/G4devcvk8PGt7FCLv5wftu3THUA=="
     },
     "node_modules/svix": {
-      "version": "1.84.1",
-      "resolved": "https://registry.npmjs.org/svix/-/svix-1.84.1.tgz",
-      "integrity": "sha512-K8DPPSZaW/XqXiz1kEyzSHYgmGLnhB43nQCMeKjWGCUpLIpAMMM8kx3rVVOSm6Bo6EHyK1RQLPT4R06skM/MlQ==",
+      "version": "1.86.0",
+      "resolved": "https://registry.npmjs.org/svix/-/svix-1.86.0.tgz",
+      "integrity": "sha512-/HTvXwjLJe1l/MsLXAO1ddCYxElJk4eNR4DzOjDOEmGrPN/3BtBE8perGwMAaJ2sT5T172VkBYzmHcjUfM1JRQ==",
       "license": "MIT",
       "dependencies": {
         "standardwebhooks": "1.0.0",
@@ -36508,21 +36480,21 @@
       "license": "MIT"
     },
     "node_modules/tldts": {
-      "version": "7.0.19",
-      "resolved": "https://registry.npmjs.org/tldts/-/tldts-7.0.19.tgz",
-      "integrity": "sha512-8PWx8tvC4jDB39BQw1m4x8y5MH1BcQ5xHeL2n7UVFulMPH/3Q0uiamahFJ3lXA0zO2SUyRXuVVbWSDmstlt9YA==",
+      "version": "7.0.26",
+      "resolved": "https://registry.npmjs.org/tldts/-/tldts-7.0.26.tgz",
+      "integrity": "sha512-WiGwQjr0qYdNNG8KpMKlSvpxz652lqa3Rd+/hSaDcY4Uo6SKWZq2LAF+hsAhUewTtYhXlorBKgNF3Kk8hnjGoQ==",
       "license": "MIT",
       "dependencies": {
-        "tldts-core": "^7.0.19"
+        "tldts-core": "^7.0.26"
       },
       "bin": {
         "tldts": "bin/cli.js"
       }
     },
     "node_modules/tldts-core": {
-      "version": "7.0.19",
-      "resolved": "https://registry.npmjs.org/tldts-core/-/tldts-core-7.0.19.tgz",
-      "integrity": "sha512-lJX2dEWx0SGH4O6p+7FPwYmJ/bu1JbcGJ8RLaG9b7liIgZ85itUVEPbMtWRVrde/0fnDPEPHW10ZsKW3kVsE9A==",
+      "version": "7.0.26",
+      "resolved": "https://registry.npmjs.org/tldts-core/-/tldts-core-7.0.26.tgz",
+      "integrity": "sha512-5WJ2SqFsv4G2Dwi7ZFVRnz6b2H1od39QME1lc2y5Ew3eWiZMAeqOAfWpRP9jHvhUl881406QtZTODvjttJs+ew==",
       "license": "MIT"
     },
     "node_modules/tldts-icann": {
@@ -37019,9 +36991,9 @@
       }
     },
     "node_modules/typescript-auto-import-cache/node_modules/semver": {
-      "version": "7.7.3",
-      "resolved": "https://registry.npmjs.org/semver/-/semver-7.7.3.tgz",
-      "integrity": "sha512-SdsKMrI9TdgjdweUSR9MweHA4EJ8YxHn8DFaDisvhVlUOe4BF1tLD7GAj0lIqWVl+dPb/rExr0Btby5loQm20Q==",
+      "version": "7.7.4",
+      "resolved": "https://registry.npmjs.org/semver/-/semver-7.7.4.tgz",
+      "integrity": "sha512-vFKC2IEtQnVhpT78h1Yp8wzwrf8CM+MzKMHGJZfBtzhZNycRFnXsHk6E5TxIkkMsgNS7mdX3AGB7x2QM2di4lA==",
       "license": "ISC",
       "bin": {
         "semver": "bin/semver.js"
@@ -37031,15 +37003,15 @@
       }
     },
     "node_modules/typescript-eslint": {
-      "version": "8.57.0",
-      "resolved": "https://registry.npmjs.org/typescript-eslint/-/typescript-eslint-8.57.0.tgz",
-      "integrity": "sha512-W8GcigEMEeB07xEZol8oJ26rigm3+bfPHxHvwbYUlu1fUDsGuQ7Hiskx5xGW/xM4USc9Ephe3jtv7ZYPQntHeA==",
+      "version": "8.57.1",
+      "resolved": "https://registry.npmjs.org/typescript-eslint/-/typescript-eslint-8.57.1.tgz",
+      "integrity": "sha512-fLvZWf+cAGw3tqMCYzGIU6yR8K+Y9NT2z23RwOjlNFF2HwSB3KhdEFI5lSBv8tNmFkkBShSjsCjzx1vahZfISA==",
       "license": "MIT",
       "dependencies": {
-        "@typescript-eslint/eslint-plugin": "8.57.0",
-        "@typescript-eslint/parser": "8.57.0",
-        "@typescript-eslint/typescript-estree": "8.57.0",
-        "@typescript-eslint/utils": "8.57.0"
+        "@typescript-eslint/eslint-plugin": "8.57.1",
+        "@typescript-eslint/parser": "8.57.1",
+        "@typescript-eslint/typescript-estree": "8.57.1",
+        "@typescript-eslint/utils": "8.57.1"
       },
       "engines": {
         "node": "^18.18.0 || ^20.9.0 || >=21.1.0"
@@ -39817,9 +39789,9 @@
       }
     },
     "node_modules/volar-service-css": {
-      "version": "0.0.66",
-      "resolved": "https://registry.npmjs.org/volar-service-css/-/volar-service-css-0.0.66.tgz",
-      "integrity": "sha512-XrL1V9LEAHnunglYdDf/7shJbQXqKsHB+P69zPmJTqHx6hqvM9GWNbn2h7M0P/oElW8p/MTVHdfjl6C8cxdsBQ==",
+      "version": "0.0.70",
+      "resolved": "https://registry.npmjs.org/volar-service-css/-/volar-service-css-0.0.70.tgz",
+      "integrity": "sha512-K1qyOvBpE3rzdAv3e4/6Rv5yizrYPy5R/ne3IWCAzLBuMO4qBMV3kSqWzj6KUVe6S0AnN6wxF7cRkiaKfYMYJw==",
       "license": "MIT",
       "dependencies": {
         "vscode-css-languageservice": "^6.3.0",
@@ -39836,12 +39808,12 @@
       }
     },
     "node_modules/volar-service-emmet": {
-      "version": "0.0.66",
-      "resolved": "https://registry.npmjs.org/volar-service-emmet/-/volar-service-emmet-0.0.66.tgz",
-      "integrity": "sha512-BMPSpm6mk0DAEVdI2haxYIOt1Z2oaIZvCGtXuRu95x50a5pOSRPjdeHv2uGp1rQsq1Izigx+VR/bZUf2HcSnVQ==",
+      "version": "0.0.70",
+      "resolved": "https://registry.npmjs.org/volar-service-emmet/-/volar-service-emmet-0.0.70.tgz",
+      "integrity": "sha512-xi5bC4m/VyE3zy/n2CXspKeDZs3qA41tHLTw275/7dNWM/RqE2z3BnDICQybHIVp/6G1iOQj5c1qXMgQC08TNg==",
       "license": "MIT",
       "dependencies": {
-        "@emmetio/css-parser": "github:ramya-rao-a/css-parser#vscode",
+        "@emmetio/css-parser": "^0.4.1",
         "@emmetio/html-matcher": "^1.3.0",
         "@vscode/emmet-helper": "^2.9.3",
         "vscode-uri": "^3.0.8"
@@ -39856,9 +39828,9 @@
       }
     },
     "node_modules/volar-service-html": {
-      "version": "0.0.66",
-      "resolved": "https://registry.npmjs.org/volar-service-html/-/volar-service-html-0.0.66.tgz",
-      "integrity": "sha512-MKKD2qM8qVZvBKBIugt00+Bm8j1ehgeX7Cm5XwgeEgdW/3PhUEEe/aeTxQGon1WJIGf2MM/cHPjZxPJOQN4WfQ==",
+      "version": "0.0.70",
+      "resolved": "https://registry.npmjs.org/volar-service-html/-/volar-service-html-0.0.70.tgz",
+      "integrity": "sha512-eR6vCgMdmYAo4n+gcT7DSyBQbwB8S3HZZvSagTf0sxNaD4WppMCFfpqWnkrlGStPKMZvMiejRRVmqsX9dYcTvQ==",
       "license": "MIT",
       "dependencies": {
         "vscode-html-languageservice": "^5.3.0",
@@ -39875,9 +39847,9 @@
       }
     },
     "node_modules/volar-service-prettier": {
-      "version": "0.0.66",
-      "resolved": "https://registry.npmjs.org/volar-service-prettier/-/volar-service-prettier-0.0.66.tgz",
-      "integrity": "sha512-CVaQEyfmFWoq3NhNVExoyDKonPqdacmb/07w7OfTZljxLgZpDRygiHAvzBKIcenb7rKtJNHqfQJv99ULOinJBA==",
+      "version": "0.0.70",
+      "resolved": "https://registry.npmjs.org/volar-service-prettier/-/volar-service-prettier-0.0.70.tgz",
+      "integrity": "sha512-Z6BCFSpGVCd8BPAsZ785Kce1BGlWd5ODqmqZGVuB14MJvrR4+CYz6cDy4F+igmE1gMifqfvMhdgT8Aud4M5ngg==",
       "license": "MIT",
       "dependencies": {
         "vscode-uri": "^3.0.8"
@@ -39896,9 +39868,9 @@
       }
     },
     "node_modules/volar-service-typescript": {
-      "version": "0.0.66",
-      "resolved": "https://registry.npmjs.org/volar-service-typescript/-/volar-service-typescript-0.0.66.tgz",
-      "integrity": "sha512-8irsfCEf86R1RqPijrU6p5NCqKDNzyJNWKM6ZXmCcJqhebtl7Hr/a0bnlr59AzqkS3Ym4PbbJZs1K/92CXTDsw==",
+      "version": "0.0.70",
+      "resolved": "https://registry.npmjs.org/volar-service-typescript/-/volar-service-typescript-0.0.70.tgz",
+      "integrity": "sha512-l46Bx4cokkUedTd74ojO5H/zqHZJ8SUuyZ0IB8JN4jfRqUM3bQFBHoOwlZCyZmOeO0A3RQNkMnFclxO4c++gsg==",
       "license": "MIT",
       "dependencies": {
         "path-browserify": "^1.0.1",
@@ -39918,9 +39890,9 @@
       }
     },
     "node_modules/volar-service-typescript-twoslash-queries": {
-      "version": "0.0.66",
-      "resolved": "https://registry.npmjs.org/volar-service-typescript-twoslash-queries/-/volar-service-typescript-twoslash-queries-0.0.66.tgz",
-      "integrity": "sha512-PA3CyvEaBrkxJcBq+HFdks1TF1oJ8H+jTOTQUurLDRkVjmUFg8bfdya6U/dWfTsPaDSRM4m/2chwgew5zoQXfg==",
+      "version": "0.0.70",
+      "resolved": "https://registry.npmjs.org/volar-service-typescript-twoslash-queries/-/volar-service-typescript-twoslash-queries-0.0.70.tgz",
+      "integrity": "sha512-IdD13Z9N2Bu8EM6CM0fDV1E69olEYGHDU25X51YXmq8Y0CmJ2LNj6gOiBJgpS5JGUqFzECVhMNBW7R0sPdRTMQ==",
       "license": "MIT",
       "dependencies": {
         "vscode-uri": "^3.0.8"
@@ -39935,9 +39907,9 @@
       }
     },
     "node_modules/volar-service-typescript/node_modules/semver": {
-      "version": "7.7.3",
-      "resolved": "https://registry.npmjs.org/semver/-/semver-7.7.3.tgz",
-      "integrity": "sha512-SdsKMrI9TdgjdweUSR9MweHA4EJ8YxHn8DFaDisvhVlUOe4BF1tLD7GAj0lIqWVl+dPb/rExr0Btby5loQm20Q==",
+      "version": "7.7.4",
+      "resolved": "https://registry.npmjs.org/semver/-/semver-7.7.4.tgz",
+      "integrity": "sha512-vFKC2IEtQnVhpT78h1Yp8wzwrf8CM+MzKMHGJZfBtzhZNycRFnXsHk6E5TxIkkMsgNS7mdX3AGB7x2QM2di4lA==",
       "license": "ISC",
       "bin": {
         "semver": "bin/semver.js"
@@ -39947,13 +39919,13 @@
       }
     },
     "node_modules/volar-service-yaml": {
-      "version": "0.0.66",
-      "resolved": "https://registry.npmjs.org/volar-service-yaml/-/volar-service-yaml-0.0.66.tgz",
-      "integrity": "sha512-q6oTKD6EMEu1ws1FDjRw+cfCF69Gu51IEGM9jVbtmSZS1qQHKxMqlt2+wBInKl2D+xILtjzkWbfkjQyBYQMw7g==",
+      "version": "0.0.70",
+      "resolved": "https://registry.npmjs.org/volar-service-yaml/-/volar-service-yaml-0.0.70.tgz",
+      "integrity": "sha512-0c8bXDBeoATF9F6iPIlOuYTuZAC4c+yi0siQo920u7eiBJk8oQmUmg9cDUbR4+Gl++bvGP4plj3fErbJuPqdcQ==",
       "license": "MIT",
       "dependencies": {
         "vscode-uri": "^3.0.8",
-        "yaml-language-server": "~1.19.2"
+        "yaml-language-server": "~1.20.0"
       },
       "peerDependencies": {
         "@volar/language-service": "~2.4.0"
@@ -39965,9 +39937,9 @@
       }
     },
     "node_modules/vscode-css-languageservice": {
-      "version": "6.3.8",
-      "resolved": "https://registry.npmjs.org/vscode-css-languageservice/-/vscode-css-languageservice-6.3.8.tgz",
-      "integrity": "sha512-dBk/9ullEjIMbfSYAohGpDOisOVU1x2MQHOeU12ohGJQI7+r0PCimBwaa/pWpxl/vH4f7ibrBfxIZY3anGmHKQ==",
+      "version": "6.3.10",
+      "resolved": "https://registry.npmjs.org/vscode-css-languageservice/-/vscode-css-languageservice-6.3.10.tgz",
+      "integrity": "sha512-eq5N9Er3fC4vA9zd9EFhyBG90wtCCuXgRSpAndaOgXMh1Wgep5lBgRIeDgjZBW9pa+332yC9+49cZMW8jcL3MA==",
       "license": "MIT",
       "dependencies": {
         "@vscode/l10n": "^0.0.18",
@@ -39977,9 +39949,9 @@
       }
     },
     "node_modules/vscode-html-languageservice": {
-      "version": "5.6.0",
-      "resolved": "https://registry.npmjs.org/vscode-html-languageservice/-/vscode-html-languageservice-5.6.0.tgz",
-      "integrity": "sha512-FIVz83oGw2tBkOr8gQPeiREInnineCKGCz3ZD1Pi6opOuX3nSRkc4y4zLLWsuop+6ttYX//XZCI6SLzGhRzLmA==",
+      "version": "5.6.2",
+      "resolved": "https://registry.npmjs.org/vscode-html-languageservice/-/vscode-html-languageservice-5.6.2.tgz",
+      "integrity": "sha512-ulCrSnFnfQ16YzvwnYUgEbUEl/ZG7u2eV27YhvLObSHKkb8fw1Z9cgsnUwjTEeDIdJDoTDTDpxuhQwoenoLNMg==",
       "license": "MIT",
       "dependencies": {
         "@vscode/l10n": "^0.0.18",
@@ -40986,15 +40958,18 @@
       "license": "ISC"
     },
     "node_modules/yaml": {
-      "version": "2.8.1",
-      "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.8.1.tgz",
-      "integrity": "sha512-lcYcMxX2PO9XMGvAJkJ3OsNMw+/7FKes7/hgerGUYWIoWu5j/+YQqcZr5JnPZWzOsEBgMbSbiSTn/dv/69Mkpw==",
+      "version": "2.8.2",
+      "resolved": "https://registry.npmjs.org/yaml/-/yaml-2.8.2.tgz",
+      "integrity": "sha512-mplynKqc1C2hTVYxd0PU2xQAc22TI1vShAYGksCCfxbn/dFwnHTNi1bvYsBTkhdUNtGIf5xNOg938rrSSYvS9A==",
       "license": "ISC",
       "bin": {
         "yaml": "bin.mjs"
       },
       "engines": {
         "node": ">= 14.6"
+      },
+      "funding": {
+        "url": "https://github.com/sponsors/eemeli"
       }
     },
     "node_modules/yaml-eslint-parser": {
@@ -41026,15 +41001,14 @@
       }
     },
     "node_modules/yaml-language-server": {
-      "version": "1.19.2",
-      "resolved": "https://registry.npmjs.org/yaml-language-server/-/yaml-language-server-1.19.2.tgz",
-      "integrity": "sha512-9F3myNmJzUN/679jycdMxqtydPSDRAarSj3wPiF7pchEPnO9Dg07Oc+gIYLqXR4L+g+FSEVXXv2+mr54StLFOg==",
+      "version": "1.20.0",
+      "resolved": "https://registry.npmjs.org/yaml-language-server/-/yaml-language-server-1.20.0.tgz",
+      "integrity": "sha512-qhjK/bzSRZ6HtTvgeFvjNPJGWdZ0+x5NREV/9XZWFjIGezew2b4r5JPy66IfOhd5OA7KeFwk1JfmEbnTvev0cA==",
       "license": "MIT",
       "dependencies": {
         "@vscode/l10n": "^0.0.18",
         "ajv": "^8.17.1",
         "ajv-draft-04": "^1.0.0",
-        "lodash": "4.17.21",
         "prettier": "^3.5.0",
         "request-light": "^0.5.7",
         "vscode-json-languageservice": "4.1.8",
@@ -41049,9 +41023,9 @@
       }
     },
     "node_modules/yaml-language-server/node_modules/ajv": {
-      "version": "8.17.1",
-      "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.17.1.tgz",
-      "integrity": "sha512-B/gBuNg5SiMTrPkC+A2+cW0RszwxYmn6VYxB/inlBStS5nx6xHIt/ehKRhIMhqusl7a8LjQoZnjCs5vhwxOQ1g==",
+      "version": "8.18.0",
+      "resolved": "https://registry.npmjs.org/ajv/-/ajv-8.18.0.tgz",
+      "integrity": "sha512-PlXPeEWMXMZ7sPYOHqmDyCJzcfNrUr3fGNKtezX14ykXOEIvyK81d+qydx89KY5O71FKMPaQ2vBfBFI5NHR63A==",
       "license": "MIT",
       "dependencies": {
         "fast-deep-equal": "^3.1.3",
@@ -41232,7 +41206,7 @@
       "version": "0.0.1",
       "license": "AGPL-3.0",
       "engines": {
-        "node": ">=22.0.0 <23.0.0",
+        "node": ">=24.0.0 <25.0.0",
         "npm": ">=10.0.0"
       }
     },
@@ -41241,7 +41215,7 @@
       "version": "0.0.1",
       "license": "AGPL-3.0",
       "engines": {
-        "node": ">=22.0.0 <23.0.0",
+        "node": ">=24.0.0 <25.0.0",
         "npm": ">=10.0.0"
       }
     }
diff --git a/package.json b/package.json
index 61f89cbfb..702c0835d 100644
--- a/package.json
+++ b/package.json
@@ -67,13 +67,13 @@
   },
   "dependencies": {
     "@adobe/remark-gridtables": "^3.0.18",
-    "@astrojs/check": "0.9.7",
+    "@astrojs/check": "0.9.8",
     "@astrojs/db": "^0.20.0",
-    "@astrojs/mdx": "5.0.0",
-    "@astrojs/preact": "5.0.0",
+    "@astrojs/mdx": "5.0.1",
+    "@astrojs/preact": "5.0.1",
     "@astrojs/rss": "4.0.17",
     "@astrojs/sitemap": "^3.7.1",
-    "@astrojs/vercel": "^10.0.0",
+    "@astrojs/vercel": "^10.0.1",
     "@axe-core/playwright": "^4.11.1",
     "@eslint-community/eslint-plugin-eslint-comments": "^4.7.1",
     "@eslint/js": "10.0.1",
@@ -86,7 +86,7 @@
     "@nanostores/persistent": "^1.3.3",
     "@playwright/browser-chromium": "^1.58.2",
     "@playwright/test": "1.58.2",
-    "@semantic-ui/astro-lit": "^5.1.2",
+    "@semantic-ui/astro-lit": "^5.3.0",
     "@sentry/astro": "^10.43.0",
     "@sentry/browser": "^10.43.0",
     "@shikijs/transformers": "^4.0.2",
@@ -112,8 +112,8 @@
     "@types/react": "^19.2.14",
     "@types/sanitize-html": "^2.16.1",
     "@types/to-ico": "1.1.3",
-    "@typescript-eslint/eslint-plugin": "8.57.0",
-    "@typescript-eslint/parser": "8.57.0",
+    "@typescript-eslint/eslint-plugin": "8.57.1",
+    "@typescript-eslint/parser": "8.57.1",
     "@ungap/structured-clone": "^1.3.0",
     "@uppy/audio": "^3.1.0",
     "@uppy/box": "^4.1.0",
@@ -129,11 +129,11 @@
     "@vitest/coverage-v8": "^4.1.0",
     "@webcomponents/template-shadowroot": "^0.2.1",
     "alex": "^11.0.1",
-    "astro": "6.0.4",
+    "astro": "6.0.5",
     "astro-link-validator": "github:rodgtr1/astro-link-validator",
     "astro-og-canvas": "^0.10.1",
     "astro-vtbot": "^2.1.12",
-    "baseline-browser-mapping": "^2.10.7",
+    "baseline-browser-mapping": "^2.10.8",
     "canvas-confetti": "^1.9.4",
     "confusing-browser-globals": "1.0.11",
     "cross-env": "^10.1.0",
@@ -163,14 +163,14 @@
     "is-whitespace-character": "^2.0.1",
     "isomorphic-git": "^1.37.4",
     "js-cookie": "^3.0.5",
-    "jsdom": "^28.1.0",
+    "jsdom": "^29.0.0",
     "libphonenumber-js": "1.12.40",
     "lighthouse": "^13.0.3",
     "lit": "^3.3.2",
     "markdownlint-cli2": "^0.21.0",
     "md-attr-parser": "^1.3.0",
     "mermaid": "^11.13.0",
-    "nanostores": "^1.1.1",
+    "nanostores": "^1.2.0",
     "nodemailer": "^8.0.2",
     "npm": "^11.11.1",
     "playwright-lighthouse": "^4.0.0",
@@ -203,7 +203,7 @@
     "remark-stringify": "^11.0.0",
     "remark-supersub": "^1.0.0",
     "remark-video": "^0.10.0",
-    "resend": "^6.9.3",
+    "resend": "^6.9.4",
     "retext": "^9.0.0",
     "retext-smartypants": "^6.2.0",
     "rimraf": "6.1.3",
@@ -215,7 +215,7 @@
     "stylelint": "^17.4.0",
     "stylelint-config-standard": "^40.0.0",
     "stylelint-declaration-block-no-ignored-properties": "3.0.0",
-    "stylelint-order": "8.0.0",
+    "stylelint-order": "8.1.1",
     "tailwindcss": "^4.2.1",
     "temp-dir": "3.0.0",
     "timezones-ical-library": "^2.1.3",
@@ -223,7 +223,7 @@
     "to-ico": "1.1.5",
     "tslib": "2.8.1",
     "typescript": "5.9.3",
-    "typescript-eslint": "8.57.0",
+    "typescript-eslint": "8.57.1",
     "unified": "^11.0.5",
     "unist": "^0.0.1",
     "unist-util-inspect": "^8.1.0",
diff --git a/src/styles/code-highlighting/general.css b/src/styles/code-highlighting/general.css
index a11bd4626..60bf0511a 100644
--- a/src/styles/code-highlighting/general.css
+++ b/src/styles/code-highlighting/general.css
@@ -12,8 +12,7 @@
  * not under the line number column.
  */
 pre.shiki {
-  overflow-x: hidden;
-  overflow-y: hidden;
+  overflow: hidden;
 }
 
 pre.shiki code {

From 8631ac380ae691205b292c6738178224de4d36ff Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 01:45:37 +0300
Subject: [PATCH 10/15] Final pass
 kubernetes-cost-optimization-resource-sizing-spot-instances article

---
 .../index.mdx                                 | 23 ++++++----
 .../pdf.mdx                                   | 42 ++++++++++---------
 2 files changed, 36 insertions(+), 29 deletions(-)

diff --git a/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/index.mdx b/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/index.mdx
index e8ced6a0e..8ca477f2e 100644
--- a/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/index.mdx
+++ b/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/index.mdx
@@ -10,19 +10,19 @@ featured: true
 ---
 
 *[K8s]: Kubernetes
-*[VPA]: Vertical Pod Autoscaler
-*[QoS]: Quality of Service
 *[OOM]: Out of Memory
+*[QoS]: Quality of Service
+*[VPA]: Vertical Pod Autoscaler
 
 I worked with a team running 50 nodes who'd never looked at their actual resource utilization. When we finally checked, average CPU usage was 15% and memory was 25%. Resource requests were 3-4x what workloads actually used. Right-sizing those requests and enabling the cluster autoscaler dropped them to 20 nodes - a 60% cost reduction with zero performance impact.
 
 This isn't unusual. Compute is typically 60-80% of Kubernetes spend, yet most teams have no visibility into whether their resource requests match actual usage. The default behavior - developers requesting "enough" resources with generous padding - leads to clusters running at 20-30% utilization while paying for 100%.
 
-The good news: Kubernetes cost optimization has three levers, and two of them deliver 80% of the savings. Use cheaper compute (spot instances), use less compute (right-sizing), and use compute more efficiently (bin packing). This article focuses on right-sizing and spot - the changes you can make this week that will actually move your bill.
+The good news: <Highlighter>Kubernetes cost optimization has three levers, and two of them deliver 80% of the savings.</Highlighter> Use cheaper compute (spot instances), use less compute (right-sizing), and use compute more efficiently (bin packing). This article focuses on right-sizing and spot - the changes you can make this week that will actually move your bill.
 
 ## The Resource Model That Costs You Money
 
-The Kubernetes resource model trips up a lot of teams because __requests__ and __limits__ sound similar but do completely different things.
+The Kubernetes resource model trips up a lot of teams because _requests_ and _limits_ sound similar but do completely different things.
 
 __Requests__ are what the scheduler uses for placement decisions. When you set `cpu: 500m` as a request, you're telling Kubernetes "this container needs half a CPU core guaranteed." The scheduler won't place your pod on a node unless that capacity is available. Requests are promises - the node reserves that capacity for your container whether you use it or not.
 
@@ -31,7 +31,8 @@ __Limits__ are enforcement boundaries. CPU limits throttle - if your container t
 This distinction matters for cost because __requests determine how many nodes you need__. If every pod requests 1 CPU but only uses 0.1, you're paying for 10x the capacity you need. The scheduler sees the cluster as full when it's actually 90% idle. Here's how they compare:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     figure: "Requests vs limits comparison.",
     thead: {
@@ -126,18 +127,22 @@ The workflow I use:
 
 <List
   variant="numbered-with-background-list"
+  classes={{
+    li: "[&>div]:!pt-3 mb-6",
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: "Deploy VPAs in recommendation mode for all deployments",
+      lead: "Deploy VPAs in recommendation mode for all deployments",
     },
     {
-      text: "Review recommendations weekly",
+      lead: "Review recommendations weekly",
     },
     {
-      text: "Apply changes through the normal deployment process (not via VPA auto-apply)",
+      lead: "Apply changes through the normal deployment process (not via VPA auto-apply)",
     },
     {
-      text: "Validate that workloads remain healthy after the change",
+      lead: "Validate that workloads remain healthy after the change",
     },
   ]}
 />
diff --git a/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/pdf.mdx b/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/pdf.mdx
index 8971c3a4d..d5d043fb8 100644
--- a/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/pdf.mdx
+++ b/src/content/articles/kubernetes-cost-optimization-resource-sizing-spot-instances/pdf.mdx
@@ -9,27 +9,27 @@ tags: ["cloud-platforms","kubernetes","prometheus","aws","azure"]
 featured: true
 ---
 
-*[K8s]: Kubernetes
-*[VPA]: Vertical Pod Autoscaler
-*[HPA]: Horizontal Pod Autoscaler
-*[QoS]: Quality of Service
-*[OOM]: Out of Memory
-*[EC2]: Elastic Compute Cloud
-*[GCE]: Google Compute Engine
 *[AKS]: Azure Kubernetes Service
+*[EC2]: Elastic Compute Cloud
 *[EKS]: Elastic Kubernetes Service
+*[GCE]: Google Compute Engine
 *[GKE]: Google Kubernetes Engine
+*[HPA]: Horizontal Pod Autoscaler
+*[K8s]: Kubernetes
+*[OOM]: Out of Memory
+*[QoS]: Quality of Service
+*[VPA]: Vertical Pod Autoscaler
 
 Compute is typically 60-80% of Kubernetes spend, yet most teams have no visibility into whether their resource requests match actual usage. The default behavior - developers requesting "enough" resources with generous padding - leads to clusters running at 20-30% utilization while paying for 100%.
 
 I worked with a team running 50 nodes who'd never looked at their actual resource utilization. When we finally checked, average CPU usage was 15% and memory was 25%. Resource requests were 3-4x what workloads actually used. Right-sizing those requests and enabling the cluster autoscaler dropped them to 20 nodes - a 60% cost reduction with zero performance impact. The workloads didn't notice because they were never using the resources they'd requested.
 
-Cost optimization isn't about penny-pinching. It's about eliminating waste that funds nothing. The savings can fund actual improvements: better observability, more environments, faster CI runners, or simply budget for the next project.
-
 <Callout type="info">
 Kubernetes cost optimization has three levers: use cheaper compute (spot instances), use less compute (right-sizing), and use compute more efficiently (bin packing). Most savings come from the boring work of accurate resource requests, not clever architecture.
 </Callout>
 
+Cost optimization isn't about penny-pinching. It's about eliminating waste that funds nothing. The savings can fund actual improvements: better observability, more environments, faster CI runners, or simply budget for the next project.
+
 ## Understanding Kubernetes Resource Model
 
 ### Requests vs Limits
@@ -45,7 +45,8 @@ This distinction matters for cost because __requests determine how many nodes yo
 Kubernetes assigns a QoS class based on how you set resources. __Guaranteed__ pods (requests equal limits for all resources) get the highest priority and are evicted last under pressure. __Burstable__ pods (requests less than limits) are the common case. __BestEffort__ pods (no requests or limits) are evicted first - avoid these in production. To control your pod's QoS class, set both CPU and memory requests equal to their limits for Guaranteed, or set requests lower than limits (or omit limits) for Burstable.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Aspect', 'Request', 'Limit'],
@@ -86,7 +87,7 @@ A side note on memory limits: there's an ongoing debate about whether to set the
 
 ### The Over-Provisioning Problem
 
-Understanding the request/limit distinction explains __why__ over-provisioning is so expensive - but it doesn't explain why it's so common.
+Understanding the request/limit distinction explains _why_ over-provisioning is so expensive - but it doesn't explain why it's so common.
 
 Over-provisioning happens organically. A developer sets resource requests during initial deployment, picks numbers that seem reasonable with some safety margin, and never revisits them. The service works fine, so the requests stay. Multiply this across hundreds of services and you end up with a cluster that's 30% utilized but "full" according to the scheduler.
 
@@ -168,12 +169,12 @@ After deploying the VPA, wait 24-48 hours for it to collect enough data, then ch
 
 The workflow I use: deploy VPAs in recommendation mode for all deployments, review recommendations weekly, apply changes through the normal deployment process (not via VPA auto-apply), and validate that workloads remain healthy after the change. This keeps humans in the loop while still automating the analysis.
 
-VPA has other update modes - "Initial" applies recommendations only when pods are created, and "Recreate" evicts pods to apply new resource values. These work, but they remove the verification step. For production workloads, I prefer explicit control over when resource changes roll out.
-
 <Callout type="success">
 Start VPA in "Off" mode to get recommendations without automatic changes. Review recommendations weekly, apply them through your normal deployment process, and validate that workloads remain healthy. Automatic modes work but remove the human verification step.
 </Callout>
 
+VPA has other update modes - "Initial" applies recommendations only when pods are created, and "Recreate" evicts pods to apply new resource values. These work, but they remove the verification step. For production workloads, I prefer explicit control over when resource changes roll out.
+
 ## Spot and Preemptible Instances
 
 ### Spot Instance Fundamentals
@@ -293,7 +294,8 @@ When a spot instance is about to be reclaimed, something needs to cordon the nod
 On AWS, deploy the `aws-node-termination-handler` as a DaemonSet on spot nodes. It monitors the instance metadata service for interruption warnings and triggers a drain when one arrives. GKE has built-in handling. AKS requires a separate node drain handler.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Provider', 'Warning Time', 'Detection Method', 'Handler'],
@@ -391,7 +393,7 @@ The cluster autoscaler adds nodes when pods can't be scheduled and removes nodes
 
 The key scale-down settings are `scale-down-utilization-threshold` (nodes below this utilization are candidates for removal) and `scale-down-unneeded-time` (how long a node must be underutilized before removal). A threshold of 0.5 and unneeded time of 10 minutes is a reasonable starting point - aggressive enough to remove waste but not so aggressive that you're constantly churning nodes.
 
-The __expander__ controls which node pool the autoscaler scales when multiple pools could satisfy pending pods. For cost optimization, use `least-waste` (picks the pool that results in least idle resources) or `priority` (lets you explicitly prefer spot pools over on-demand). The `price` expander sounds ideal but requires accurate cost data that's often stale.
+The _expander_ controls which node pool the autoscaler scales when multiple pools could satisfy pending pods. For cost optimization, use `least-waste` (picks the pool that results in least idle resources) or `priority` (lets you explicitly prefer spot pools over on-demand). The `price` expander sounds ideal but requires accurate cost data that's often stale.
 
 ### Priority-Based Autoscaling
 
@@ -419,7 +421,7 @@ Code: Priority expander configuration for preferring spot instances.
 With this configuration, the autoscaler first tries to scale spot pools. If spot capacity isn't available (the cloud provider is out of that instance type), it falls back to general on-demand. The critical on-demand pool only gets used when everything else fails. Add `--expander=priority` and `--expanderConfigMap=cluster-autoscaler-priority-expander` to the autoscaler command to enable it.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: ['Setting', 'Cost Optimization', 'Stability', 'Recommendation'],
@@ -454,10 +456,10 @@ Kubernetes cost optimization comes down to a few straightforward practices: meas
 
 The biggest wins come from fixing over-provisioned resources - the boring work of adjusting requests to match actual usage. Teams that invest in cost visibility and right-sizing typically reduce spend by 40-60% without any architectural changes. No new services, no migration projects, just better numbers in existing deployment manifests.
 
-Start with visibility. Deploy VPA in recommendation mode across your workloads and let it collect data for a week. Query efficiency ratios to find your worst offenders - the deployments requesting 4x what they use - and fix those first. The Pareto principle applies: 20% of your workloads probably account for 80% of your waste. Once you've addressed the obvious outliers, build a dashboard that tracks efficiency by namespace so teams can self-service.
-
-Then look at spot instances. Any workload that can tolerate losing a node - web servers, API servers, workers, CI runners - is a spot candidate. With proper interruption handling (multiple replicas, zone spreading, graceful shutdown), spot instances deliver 50-70% savings on compute with minimal operational overhead.
-
 <Callout type="warning">
 Cost optimization is continuous, not a one-time project. Usage patterns change, new services deploy with default resources, and spot savings vary. Build cost review into your regular operations - a monthly meeting that reviews efficiency dashboards and identifies right-sizing opportunities keeps savings compounding.
 </Callout>
+
+Start with visibility. Deploy VPA in recommendation mode across your workloads and let it collect data for a week. Query efficiency ratios to find your worst offenders - the deployments requesting 4x what they use - and fix those first. The Pareto principle applies: 20% of your workloads probably account for 80% of your waste. Once you've addressed the obvious outliers, build a dashboard that tracks efficiency by namespace so teams can self-service.
+
+Then look at spot instances. Any workload that can tolerate losing a node - web servers, API servers, workers, CI runners - is a spot candidate. With proper interruption handling (multiple replicas, zone spreading, graceful shutdown), spot instances deliver 50-70% savings on compute with minimal operational overhead.

From 9b7820c9e0f6734f005315ebaf19be597affe6f1 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 02:44:28 +0300
Subject: [PATCH 11/15] Final pass
 kubernetes-decision-framework-when-not-to-use article

---
 .../index.mdx                                 | 13 +--
 .../pdf.mdx                                   | 80 ++++++++++++-------
 2 files changed, 59 insertions(+), 34 deletions(-)

diff --git a/src/content/articles/kubernetes-decision-framework-when-not-to-use/index.mdx b/src/content/articles/kubernetes-decision-framework-when-not-to-use/index.mdx
index 059925e82..d6c26bbc3 100644
--- a/src/content/articles/kubernetes-decision-framework-when-not-to-use/index.mdx
+++ b/src/content/articles/kubernetes-decision-framework-when-not-to-use/index.mdx
@@ -21,7 +21,7 @@ A startup I advised last year had a familiar story. They'd spent three months mi
 
 The kicker? Their traffic was 50 requests per minute. A $20/month VM could have handled their load with room to spare.
 
-This isn't an indictment of Kubernetes. It's a recognition that K8s solves specific problems at specific scales, and choosing it prematurely creates problems you wouldn't otherwise have. The goal isn't to use the most powerful tool available. It's to use the __right__ tool for where you are today.
+This isn't an indictment of Kubernetes. <Highlighter>It's a recognition that K8s solves specific problems at specific scales, and choosing it prematurely creates problems you wouldn't otherwise have.</Highlighter> The goal isn't to use the most powerful tool available. It's to use the _right_ tool for where you are today.
 
 ## The Kubernetes Complexity Tax
 
@@ -40,7 +40,10 @@ This isn't optional learning. It's the baseline for keeping production running.
 The managed Kubernetes pricing page shows the control plane cost. It doesn't show the full picture.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     thead: {
       th: ['Cost Category', 'What the Pricing Page Shows', "What You'll Actually Pay"],
@@ -95,7 +98,7 @@ These guidelines give you a starting point, but every situation has nuance. The
 Evaluate each factor on a 1-5 scale, where 1 strongly favors simpler alternatives and 5 strongly favors Kubernetes.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: ['Factor', '1 (Simpler is Better)', '5 (K8s Fits)'],
@@ -160,8 +163,8 @@ The best infrastructure choice is the one that lets your team ship features inst
 
 A VM with a straightforward deployment script might feel less sophisticated than a Kubernetes cluster, but sophistication isn't the goal. Shipping reliable software is the goal. If a simpler architecture gets you there with less overhead, that's a win.
 
-This doesn't mean Kubernetes is wrong. It means Kubernetes is __contextual__. The organizations that get the most value from K8s are the ones who adopted it because they needed its specific capabilities, not because it seemed like the professional choice.
-
 <Callout type="info" title="Start with the Scorecard">
 Before your next infrastructure decision, run through the scorecard with your team. Be honest about your current state, not your aspirations. The right tool for today might not be the right tool for next year, and that's fine. You can always migrate later when the complexity becomes worth it.
 </Callout>
+
+This doesn't mean Kubernetes is wrong. It means Kubernetes is __contextual__. The organizations that get the most value from K8s are the ones who adopted it because they needed its specific capabilities, not because it seemed like the professional choice.
diff --git a/src/content/articles/kubernetes-decision-framework-when-not-to-use/pdf.mdx b/src/content/articles/kubernetes-decision-framework-when-not-to-use/pdf.mdx
index 61a51e3fd..e9dbfc1c5 100644
--- a/src/content/articles/kubernetes-decision-framework-when-not-to-use/pdf.mdx
+++ b/src/content/articles/kubernetes-decision-framework-when-not-to-use/pdf.mdx
@@ -28,12 +28,12 @@ Here's a scenario I've seen play out multiple times. A five-person startup runs
 
 Six months later, after weeks of migration work, they have the same application running on Kubernetes. But now they're also maintaining a cluster, debugging CNI networking issues, managing Helm charts, configuring ingress controllers, and spending 40% of engineering time on infrastructure instead of product. They just bought complexity without gaining capability.
 
-Kubernetes solves specific problems: multi-service orchestration, complex networking, multi-team deployment isolation, sophisticated scaling requirements. If you don't have those problems, you're paying the Kubernetes tax without getting the benefits.
-
 <Callout type="warning">
 The goal of infrastructure is to run your workloads reliably and efficiently, not to use any particular technology. If your workloads run better on VMs, serverless, or managed services, choosing those over Kubernetes isn't settling for less. It's making the right engineering decision.
 </Callout>
 
+Kubernetes solves specific problems: multi-service orchestration, complex networking, multi-team deployment isolation, sophisticated scaling requirements. If you don't have those problems, you're paying the Kubernetes tax without getting the benefits.
+
 ## The Kubernetes Complexity Tax
 
 ### What You're Signing Up For
@@ -57,8 +57,10 @@ For a team of five running ten services on Kubernetes, expect 20-30 hours per mo
 Compare that to the same workloads on VMs. Operations drops to 5-10 hours monthly. Debugging is simpler because there's less abstraction. OS updates are less complex than Kubernetes upgrades. The learning burden is dramatically lower. You might spend 15-25 hours per month total.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
+  fullWidth={false}
   content={{
+    figure: 'Infrastructure approach cost comparison. Serverless costs vary dramatically with traffic patterns.',
     thead: {
       th: [
         'Cost Category',
@@ -111,7 +113,6 @@ Compare that to the same workloads on VMs. Operations drops to 5-10 hours monthl
         },
       ],
     },
-    figure: 'Infrastructure approach cost comparison. Serverless costs vary dramatically with traffic patterns.',
   }}
 />
 
@@ -127,6 +128,7 @@ The first question isn't "Should we use Kubernetes?" It's "What problems are we
 
 <Diagram
   src={kubernetesFitDiagram}
+  size="full"
   title="Kubernetes fit decision tree."
   description="Flowchart that starts with Considering Kubernetes? and asks how many services do you have. For 1-3 services, it asks whether they are tightly coupled and whether auto-scaling is needed, leading toward Monolith on VMs or Serverless or PaaS. For 4-10 services, it asks about complex networking requirements, team K8s experience, and whether the team can invest in learning, leading toward Kubernetes may fit or VMs with simple orchestration. For 10+ services, it asks about multiple teams deploying independently and whether microservices are actually needed, leading toward Kubernetes likely fits or Modular monolith first. A final decision asks whether managed K8s is used, ending at Proceed with caution or Reconsider: Self-managed rarely makes sense."
 />
@@ -138,7 +140,10 @@ The service count matters because Kubernetes overhead amortizes across workloads
 Kubernetes fits well when your workloads have these characteristics:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Multiple services needing independent deployment.",
@@ -166,7 +171,10 @@ Kubernetes fits well when your workloads have these characteristics:
 Kubernetes fits __poorly__ in these situations:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Single application.",
@@ -198,13 +206,15 @@ Kubernetes requires specific skills across a timeline:
 __Day one prerequisites__ (must have before starting):
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
   items={[
     {
-      text: "Intermediate: container fundamentals, Linux systems administration, networking basics (TCP/IP, DNS, load balancing)",
+      lead: "Basic:",
+      text: "YAML proficiency, cloud provider familiarity",
     },
     {
-      text: "Basic: YAML proficiency, cloud provider familiarity",
+      lead: "Intermediate:",
+      text: "Container fundamentals, Linux systems administration, networking basics (TCP / IP, DNS, load balancing)",
     },
   ]}
 />
@@ -212,13 +222,15 @@ __Day one prerequisites__ (must have before starting):
 __Day thirty__ (need within first month):
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
   items={[
     {
-      text: "Intermediate: Kubernetes resource model (pods, deployments, services), kubectl, pod debugging (logs, exec, describe)",
+      lead: "Basic:",
+      text: "Helm or Kustomize, resource requests/limits",
     },
     {
-      text: "Basic: Helm or Kustomize, resource requests/limits",
+      lead: "Intermediate:",
+      text: "Kubernetes resource model (pods, deployments, services), kubectl, pod debugging (logs, exec, describe)",
     },
   ]}
 />
@@ -226,10 +238,15 @@ __Day thirty__ (need within first month):
 __Day ninety__ (for sustainable operations):
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
   items={[
     {
-      text: "Intermediate: Kubernetes networking (CNI, services, ingress), storage (PV, PVC, storage classes), RBAC and security, cluster upgrades, monitoring and alerting, troubleshooting distributed systems",
+      lead: "Basic:",
+      text: "CI / CD pipeline integration, GitOps workflows (Flux or ArgoCD), cost awareness and resource right-sizing, disaster recovery planning",
+    },
+    {
+      lead: "Intermediate:",
+      text: "Kubernetes networking (CNI, services, ingress), storage (PV, PVC, storage classes), RBAC and security, cluster upgrades, monitoring and alerting, troubleshooting distributed systems",
     },
   ]}
 />
@@ -249,7 +266,7 @@ If Kubernetes isn't the right choice, what is? The answer depends on your worklo
 VMs aren't outdated technology. For many workloads, they're the right choice.
 
 <List
-  variant="check-icons-list"
+  variant="card-grid-list"
   items={[
     {
       lead: "Simplicity wins.",
@@ -283,7 +300,7 @@ VMs aren't outdated technology. For many workloads, they're the right choice.
 Serverless shines when your traffic is unpredictable or your team is small.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Variable traffic.",
@@ -314,6 +331,8 @@ Two factors dominate the infrastructure decision: traffic patterns and team size
 
 <Diagram
   src={decisionFactorsDiagram}
+  magnifyButtonPosition="bottom-left"
+  size="full"
   title="Decision factors for infrastructure choice."
   description="Flowchart divided into two subgraphs. The first, Traffic Pattern Decision, starts with What's your traffic pattern? and asks whether load is constant, whether it scales to zero, and whether spikes occur with an existing baseline, leading to VMs or K8s, Serverless, or K8s with HPA or Serverless + baseline. The second, Team Size Decision, starts with Team size? and asks whether there are less than 5 engineers or less than 15 engineers, leading to Serverless or PaaS, Managed K8s or Platform team, or Can justify dedicated platform team."
 />
@@ -323,18 +342,21 @@ Two factors dominate the infrastructure decision: traffic patterns and team size
 PaaS platforms trade control for speed. When time-to-market matters more than infrastructure flexibility, that's a good trade.
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-18 mb-6",
+  }}
   items={[
     {
-      lead: "Speed to deploy.",
+      lead: "Speed to deploy:",
       text: "Git push to deploy. Automatic SSL. Preview environments. You're shipping in minutes, not days. The tradeoff is less control and potentially higher cost at scale, but for many organizations, engineering velocity is worth more than infrastructure savings.",
     },
     {
-      lead: "Developer experience.",
+      lead: "Developer experience:",
       text: "When developers focus on code instead of infrastructure, they ship faster. PaaS platforms handle the undifferentiated heavy lifting.",
     },
     {
-      lead: "Managed everything.",
+      lead: "Managed everything:",
       text: "If you don't want to manage databases, CI/CD, SSL certificates, or preview environments, PaaS platforms bundle it all.",
     },
   ]}
@@ -346,12 +368,12 @@ For frontend-focused workloads, Vercel and Netlify both offer free tiers and exc
 
 [^jamstack]: JAMstack (JavaScript, APIs, Markup) is an architecture where sites are pre-rendered at build time and served from a CDN, with dynamic functionality handled by JavaScript calling APIs. It trades server-side rendering complexity for simpler deployment and better performance.
 
-When should you consider leaving PaaS? When your monthly bill exceeds $5k-10k, when you need more infrastructure control, when performance requirements exceed PaaS limits, or when compliance requires specific configurations. When __shouldn't__ you leave? Because "it's not real infrastructure," because everyone else uses Kubernetes, because you might need to scale someday, or because you want to learn Kubernetes. Those are bad reasons.
-
 <Callout type="success">
 Many successful companies run on PaaS well past their startup phase. If your PaaS bill is $5,000/month and your engineering team's time is worth $50,000/month, spending 20% of engineering time on Kubernetes operations to save $3,000 is a bad trade.
 </Callout>
 
+When should you consider leaving PaaS? When your monthly bill exceeds $5k-10k, when you need more infrastructure control, when performance requirements exceed PaaS limits, or when compliance requires specific configurations. When __shouldn't__ you leave? Because "it's not real infrastructure," because everyone else uses Kubernetes, because you might need to scale someday, or because you want to learn Kubernetes. Those are bad reasons.
+
 ## Migration Considerations
 
 ### If You're Already on Kubernetes
@@ -359,7 +381,7 @@ Many successful companies run on PaaS well past their startup phase. If your Paa
 Maybe you adopted Kubernetes and it's not working out. That's not a failure — it's information. Here are the signals that suggest reconsidering:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Operational burden exceeds value.",
@@ -389,7 +411,7 @@ For staged migration, start with workloads that fit Kubernetes poorly: batch job
 The most pragmatic organizations don't commit to one platform for everything. They match platforms to workload characteristics.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Managed services for stateful workloads.",
@@ -421,7 +443,7 @@ Most organizations that use Kubernetes well don't use it for everything. They ru
 Here's a simple scoring framework to help clarify whether Kubernetes makes sense for your situation. Score each factor from 0-3, then sum them up.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: [
@@ -504,10 +526,10 @@ Kubernetes is a powerful platform for the right use cases: many services that ne
 
 But it comes with significant operational burden that isn't justified for every workload. The complexity tax is real: ongoing operations, cluster upgrades, debugging distributed systems, and keeping skills current. For small teams, single applications, or workloads that don't need orchestration, simpler infrastructure isn't settling — it's the right engineering decision.
 
-The best infrastructure choice considers workload characteristics, team capabilities, and total cost of ownership. Not industry trends. Not what "everyone else" is using. The question isn't "Should we use Kubernetes?" It's "What infrastructure best serves our workloads, team, and business?"
-
-Sometimes that's Kubernetes. Often, especially for smaller organizations, it's something simpler. VMs with modern tooling. Serverless for variable workloads. PaaS for fast deployment. Managed services for stateful workloads. The best engineers choose the right tool, not the most powerful one.
-
 <Callout type="warning">
 If you're evaluating Kubernetes, start with the scorecard. If you score below 7, save yourself months of complexity and pick a simpler path. Your future self will thank you.
 </Callout>
+
+The best infrastructure choice considers workload characteristics, team capabilities, and total cost of ownership. Not industry trends. Not what "everyone else" is using. The question isn't "Should we use Kubernetes?" It's "What infrastructure best serves our workloads, team, and business?"
+
+Sometimes that's Kubernetes. Often, especially for smaller organizations, it's something simpler. VMs with modern tooling. Serverless for variable workloads. PaaS for fast deployment. Managed services for stateful workloads. The best engineers choose the right tool, not the most powerful one.

From 0906ccb9cd62450af8ddd145a0948f95672efd2f Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 03:06:43 +0300
Subject: [PATCH 12/15] Final pass
 kubernetes-dns-debugging-ndots-coredns-troubleshooting article

---
 .../List/layouts/TimelineList.astro           |  3 +-
 .../index.mdx                                 | 14 ++++--
 .../pdf.mdx                                   | 43 ++++++++++++-------
 3 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/src/components/List/layouts/TimelineList.astro b/src/components/List/layouts/TimelineList.astro
index ca71eb2d3..be9de5e76 100644
--- a/src/components/List/layouts/TimelineList.astro
+++ b/src/components/List/layouts/TimelineList.astro
@@ -8,6 +8,7 @@ export type Props = {
     ul?: string
     li?: string
     em?: string
+    icon?: string
   }
 }
 
@@ -24,7 +25,7 @@ const ulClass = ["space-y-0", classes?.ul]
 const liClass = ["relative grid grid-cols-[1.5rem_1fr] gap-4", classes?.li]
 const emClass = ["block text-content font-bold not-italic mb-1", classes?.em]
 const wrapperClass = "mb-4"
-const iconClass = ["relative h-5 w-5 mt-0.5 rounded-full border-2 border-primary bg-page-base z-10"]
+const iconClass = ["relative h-5 w-5 mt-0.5 rounded-full border-2 border-primary bg-page-base z-10", classes?.icon]
 const connectorClass = ["absolute left-1/2 top-[1.375rem] -bottom-1 -translate-x-1/2 w-0.5 bg-content-offset"]
 ---
 
diff --git a/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx b/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx
index 9cb34aa2c..a1350bd75 100644
--- a/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx
+++ b/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx
@@ -28,6 +28,7 @@ Here's what happens when your application looks up `api.stripe.com`. The resolve
 
 <Diagram
   src={externalDnsDiagram}
+  size="full"
   title="External DNS lookup showing failed search domain queries before success."
   description="Sequence diagram showing how Kubernetes DNS resolution slows an external lookup when ndots is set to 5. An Application Pod sends a lookup for api.stripe.com to /etc/resolv.conf. A note over the resolver explains that the hostname has 2 dots and that ndots:5 causes search domains to be tried first. The resolver then sends three queries to CoreDNS in order: api.stripe.com.default.svc.cluster.local, api.stripe.com.svc.cluster.local, and api.stripe.com.cluster.local. CoreDNS returns NXDOMAIN for each of those internal-style names. After those failures, the resolver finally sends api.stripe.com as a fully qualified domain name to CoreDNS. CoreDNS forwards that final query to an upstream DNS server, receives the A record 93.184.216.34, and returns the successful answer back to the application. The diagram emphasizes that the delay comes from the three failed search-domain lookups that happen before the real external hostname is attempted."
 />
@@ -125,7 +126,11 @@ For most teams, I recommend starting with trailing dots for immediate relief, th
 To make this concrete, here's what the fix looks like in practice. Before applying either fix, a simple HTTP request to an external API:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     thead: {
       th: ['Metric', 'Before Fix', 'After Fix'],
@@ -158,14 +163,17 @@ When connectivity issues arise and you suspect DNS, here's the fastest path to c
 
 <List
   variant="numbered-with-background-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "Launch a debug pod",
-      text: "`kubectl run dns-debug --image=nicolaka/netshoot --rm -it --restart=Never -- bash`",
+      text: '<span class="font-mono">kubectl run dns-debug --image=nicolaka/netshoot --rm -it --restart=Never -- bash</span>',
     },
     {
       lead: "Run the ndots test",
-      text: "Compare `time nslookup api.example.com` vs `time nslookup api.example.com.`",
+      text: 'Compare <span class="font-mono">time nslookup api.example.com</span> vs <span class="font-mono">time nslookup api.example.com.</span>',
     },
     {
       lead: "Interpret the results",
diff --git a/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/pdf.mdx b/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/pdf.mdx
index b77e4d97a..00bd2d50c 100644
--- a/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/pdf.mdx
+++ b/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/pdf.mdx
@@ -30,12 +30,12 @@ That single configuration option, the default in every Kubernetes cluster, cause
 
 I've seen this pattern repeatedly. Mysterious application failures, latency spikes, and "works sometimes" bugs that trace back to DNS. The Kubernetes DNS system adds layers of complexity that catch even experienced engineers off guard. When your application can't reach a service, DNS should be your first suspect.
 
-This article covers the DNS internals you need to debug production issues: how `resolv.conf` and search domains work, why `ndots` creates overhead for external lookups, how to tune CoreDNS, and a systematic workflow for diagnosing DNS problems.
-
 <Callout type="warning" title="The First Rule of Kubernetes Debugging">
 When something is slow or broken and you don't know why, check DNS first. Not because DNS is always the problem, but because it's the problem often enough that ruling it out early saves hours of debugging in the wrong direction.
 </Callout>
 
+This article covers the DNS internals you need to debug production issues: how `resolv.conf` and search domains work, why `ndots` creates overhead for external lookups, how to tune CoreDNS, and a systematic workflow for diagnosing DNS problems.
+
 ## Kubernetes DNS Architecture
 
 Understanding the DNS stack is essential for effective debugging. Kubernetes doesn't use a single DNS server. It's a layered system where your pod's `resolv.conf` configuration determines how queries are constructed, CoreDNS handles the actual resolution, and upstream servers resolve anything outside the cluster. Each layer has its own configuration and failure modes.
@@ -92,7 +92,7 @@ Code: Examining pod DNS configuration.
 The options in `resolv.conf` control DNS behavior in ways that matter for debugging and performance tuning.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: ['DNS Option', 'Default', 'Purpose', 'Impact'],
@@ -358,6 +358,7 @@ The diagram below shows how CoreDNS processes queries. Notice that cache hits re
 
 <Diagram
   src={corednsQueryDiagram}
+  size="full"
   title="CoreDNS query processing flow."
   description="Flowchart showing the decision path CoreDNS follows when handling a DNS query. The chart is grouped under the heading CoreDNS Query Flow. A query first enters at Query Received, then moves to a decision asking In Cache. If yes, the flow goes directly to Return Cached Response. If no, it moves to a second decision asking whether the query is for cluster.local. If yes, the flow goes to Kubernetes Plugin, then to a decision asking Service Exists. A yes result returns Return Service IP, while a no result returns NXDOMAIN. If the query is not for cluster.local, the flow goes to a decision asking Custom Zone. A yes result forwards the query to Zone Server, while a no result forwards it to Upstream. The outcomes Return Service IP, NXDOMAIN, Forward to Zone Server, and Forward to Upstream all converge on Cache Response. The diagram emphasizes that cached answers are returned immediately, internal cluster names are handled by the Kubernetes plugin, and everything else is forwarded externally or to a custom zone handler before being cached."
 />
@@ -450,6 +451,7 @@ Most DNS problems fall into a few categories. The decision tree below helps you
 
 <Diagram
   src={dnsDebuggingDiagram}
+  size="full"
   title="DNS debugging decision tree."
   description="Flowchart showing a step-by-step DNS troubleshooting path in Kubernetes. The process starts at DNS Problem Reported and first asks whether the pod can reach the CoreDNS IP. If no, the issue is categorized as Network issue and the next step is Check CNI, NetworkPolicy. If yes, the chart asks whether internal DNS is working. If no, the issue is categorized as CoreDNS issue and the next step is Check CoreDNS pods, logs, config. If internal DNS is working, the chart asks whether external DNS is working. If no, the issue is categorized as Upstream or forward issue and the next step is Check CoreDNS forward config, upstream DNS. If external DNS is working but slow, the chart asks whether lookups are faster with a trailing dot. If yes, the issue is categorized as ndots issue and the recommended action is Reduce ndots or use FQDNs. If no, the issue is categorized as Upstream DNS slow and the recommended action is Change upstream DNS or increase cache. The diagram is intended to guide the reader from symptom to likely cause in a fixed order that rules out the most common DNS failure modes."
 />
@@ -457,7 +459,12 @@ Most DNS problems fall into a few categories. The decision tree below helps you
 Here's what to check for each common scenario:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+    ul: "!divide-y-0 !border-0 !overflow-visible !rounded-none space-y-4",
+    li: "!rounded-lg !border border-trim",
+  }}
   items={[
     {
       lead: "DNS timeouts or intermittent failures",
@@ -542,7 +549,7 @@ Now `legacy-db.production.svc.cluster.local` resolves to both IP addresses, and
 The `dnsPolicy` field on a pod controls which DNS server the pod uses. Most pods use the default (`ClusterFirst`), but certain scenarios require different configurations.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: ['Policy', 'CoreDNS Used', 'Use Case'],
@@ -550,20 +557,20 @@ The `dnsPolicy` field on a pod controls which DNS server the pod uses. Most pods
     tbody: {
       tr: [
         {
-          th: '`ClusterFirst`',
+          th: '<span class="font-mono">ClusterFirst</span>',
           td: ['Yes', 'Default for standard workloads'],
         },
         {
-          th: '`Default`',
+          th: '<span class="font-mono">Default</span>',
           td: ["No", "Pod needs the node's DNS, not cluster DNS"],
         },
         {
-          th: '`ClusterFirstWithHostNet`',
+          th: '<span class="font-mono">ClusterFirstWithHostNet</span>',
           td: ['Yes', 'Pods with `hostNetwork: true` that still need cluster DNS'],
         },
         {
-          th: '`None`',
-          td: ['No', 'Fully custom DNS configuration via `dnsConfig`'],
+          th: '<span class="font-mono">None</span>',
+          td: ['No', 'Fully custom DNS configuration via <span class="font-mono">dnsConfig</span>'],
         },
       ],
     },
@@ -665,27 +672,31 @@ For production clusters, the optimizations that matter most are negative caching
 When connectivity issues arise, run through this checklist:
 
 <List
-  variant="numbered-with-background-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-0",
+    icon: "!bg-info-inverse",
+  }}
   items={[
     {
       lead: "Is CoreDNS running?",
-      text: "`kubectl get pods -n kube-system -l k8s-app=kube-dns`",
+      text: '<span class="font-mono">kubectl get pods -n kube-system -l k8s-app=kube-dns</span>',
     },
     {
       lead: "Can you resolve internal names?",
-      text: "`nslookup kubernetes.default` from inside a pod",
+      text: '<span class="font-mono">nslookup kubernetes.default</span> from inside a pod',
     },
     {
       lead: "Can you resolve external names?",
-      text: "`nslookup google.com` from inside a pod",
+      text: '<span class="font-mono">nslookup google.com</span> from inside a pod',
     },
     {
       lead: "Is it an ndots issue?",
-      text: "Compare `time nslookup api.example.com` vs `time nslookup api.example.com.`",
+      text: 'Compare <span class="font-mono">time nslookup api.example.com</span> vs `time nslookup api.example.com.`',
     },
     {
       lead: "Check CoreDNS logs",
-      text: "for errors: `kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50`",
+      text: 'for errors: <span class="font-mono">kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50</span>',
     },
   ]}
 />

From 2a73045d463005a2ba4978c53b22750b6b307abe Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 03:51:31 +0300
Subject: [PATCH 13/15] Final pass
 kubernetes-hpa-autoscaling-metrics-tuning-latency article

---
 src/components/List/__tests__/index.spec.ts   | 33 +++++++
 .../List/layouts/ThreeColumnIconList.astro    |  2 +-
 .../index.mdx                                 |  2 +-
 .../index.mdx                                 | 37 +++++---
 .../pdf.mdx                                   | 90 +++++++++++--------
 5 files changed, 116 insertions(+), 48 deletions(-)

diff --git a/src/components/List/__tests__/index.spec.ts b/src/components/List/__tests__/index.spec.ts
index cd49babf1..c34c5ad01 100644
--- a/src/components/List/__tests__/index.spec.ts
+++ b/src/components/List/__tests__/index.spec.ts
@@ -199,4 +199,37 @@ describe('List (Astro)', () => {
       expect(text?.textContent).toContain('Provide a translation layer during migration.')
     })
   })
+
+  test('applies hover styling for the three-column-icon-list variant', async () => {
+    const List = (await import('@components/List/index.astro')).default
+
+    const renderedHtml = await container.renderToString(List, {
+      props: {
+        variant: 'three-column-icon-list',
+        items: [
+          {
+            title: 'Resource metrics',
+            text: 'Built-in via Metrics Server.',
+            icon: 'graph',
+            color: 'page-inverse',
+            bgColor: 'info-inverse',
+          },
+        ],
+      },
+    })
+
+    await withJsdomEnvironment(async ({ window }) => {
+      window.document.body.innerHTML = renderedHtml
+
+      const card = window.document.querySelector('ul li')
+      const title = window.document.querySelector('ul li h3')
+
+      expect(card).toBeTruthy()
+      expect(card?.className).toContain('transition-all')
+      expect(card?.className).toContain('duration-200')
+      expect(card?.className).toContain('hover:-translate-y-1')
+      expect(card?.className).toContain('hover:shadow-lg')
+      expect(title?.textContent).toContain('Resource metrics')
+    })
+  })
 })
\ No newline at end of file
diff --git a/src/components/List/layouts/ThreeColumnIconList.astro b/src/components/List/layouts/ThreeColumnIconList.astro
index fd8e5e793..a7543d4ee 100644
--- a/src/components/List/layouts/ThreeColumnIconList.astro
+++ b/src/components/List/layouts/ThreeColumnIconList.astro
@@ -25,7 +25,7 @@ export type Props = {
 const { items, classes, size }: Props = Astro.props
 
 const ulClass = ["grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6", classes?.ul].filter(Boolean).join(" ")
-const liClass = ["flex items-start gap-2 bg-white rounded-xl p-6 shadow-md", classes?.li].filter(Boolean).join(" ")
+const liClass = ["flex items-start gap-2 bg-white rounded-xl p-6 shadow-md transition-all duration-200 ease-out hover:-translate-y-1 hover:shadow-lg", classes?.li].filter(Boolean).join(" ")
 const iconWrapper = ["shrink-0 rounded-lg flex items-center justify-center mt-1 p-2", classes?.icon].filter(Boolean).join(" ")
 const contentWrapper = ["text-page-inverse mb-1 ml-2", classes?.content].filter(Boolean).join(" ")
 const headerClass = ["font-sans text-lg font-semibold text-gray-900 mt-0 mb-2", classes?.header].filter(Boolean).join(" ")
diff --git a/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx b/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx
index a1350bd75..dbf8b4a8a 100644
--- a/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx
+++ b/src/content/articles/kubernetes-dns-debugging-ndots-coredns-troubleshooting/index.mdx
@@ -18,7 +18,7 @@ An application works perfectly in development. You deploy it to Kubernetes, and
 
 That single configuration option — the default in every Kubernetes cluster — causes every lookup like `api.stripe.com` to first try `api.stripe.com.default.svc.cluster.local`, then `api.stripe.com.svc.cluster.local`, then `api.stripe.com.cluster.local`, before finally trying the actual hostname. Three failed lookups, each potentially timing out, equals mysterious latency.
 
-I've watched teams lose days to this problem. The symptoms look like network issues, timeout misconfigurations, or flaky external services. But most Kubernetes DNS latency traces back to one misunderstood setting. The good news: once you know what to look for, you can diagnose the problem in 30 seconds and fix it in another 30.
+I've watched teams lose days to this problem. The symptoms look like network issues, timeout misconfigurations, or flaky external services. <Highlighter>But most Kubernetes DNS latency traces back to one misunderstood setting.</Highlighter> The good news: once you know what to look for, you can diagnose the problem in 30 seconds and fix it in another 30.
 
 ## Understanding the ndots Problem
 
diff --git a/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/index.mdx b/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/index.mdx
index 9b4bfd085..d609fadca 100644
--- a/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/index.mdx
+++ b/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/index.mdx
@@ -9,18 +9,19 @@ tags: ["cloud-platforms","kubernetes","prometheus"]
 featured: true
 ---
 
-An e-commerce team configures HPA with a 50% CPU target. During a flash sale, traffic spikes 10x in 30 seconds. HPA takes 15 seconds to detect the load, another 15 seconds for its evaluation cycle, then the stabilization window kicks in. Meanwhile, new pods need scheduling, image pulls, and readiness probes. By the time capacity catches up—3+ minutes later — frustrated users have already left.
+An e-commerce team configures HPA with a 50% CPU target. During a flash sale, traffic spikes 10x in 30 seconds. HPA takes 15 seconds to detect the load, another 15 seconds for its evaluation cycle, then the stabilization window kicks in. Meanwhile, new pods need scheduling, image pulls, and readiness probes. By the time capacity catches up — 3+ minutes later — frustrated users have already left.
 
 I've watched this play out repeatedly. The Horizontal Pod Autoscaler looks deceptively simple: set a target CPU percentage, and Kubernetes scales your pods automatically. In practice, teams discover that HPA reacts too slowly to traffic spikes, oscillates between scaling up and down, or scales on entirely the wrong signals.
 
-The problem is that HPA is __reactive__, not predictive. By the time it decides to scale, your workload is already under stress. Tuning HPA means understanding where delays come from, choosing metrics that respond quickly, and configuring behavior that matches your traffic patterns.
+<Highlighter>The problem is that HPA is _reactive_, not predictive.</Highlighter> By the time it decides to scale, your workload is already under stress. Tuning HPA means understanding where delays come from, choosing metrics that respond quickly, and configuring behavior that matches your traffic patterns.
 
 ## The Delay Problem
 
 The HPA controller runs every 15 seconds by default, querying the metrics server and calculating how many replicas are needed. That sounds fast, but the total time from "traffic spike begins" to "new capacity receives traffic" is much longer. Every step in the pipeline adds latency.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Delay Component', 'Typical Duration', 'Notes'],
@@ -62,7 +63,10 @@ These delays stack. The metrics scrape and HPA sync cycles run independently —
 With aggressive tuning and cached images, the timeline improves but still isn't instant. Here's a typical tuned scenario:
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "T+0s",
@@ -104,7 +108,8 @@ Most teams start with CPU utilization because it's built-in. But CPU is a __lagg
 __Leading indicators__ like requests per second and queue depth increase the moment traffic arrives — before your system shows stress. __Lagging indicators__ like CPU utilization and response latency rise only after work is already backing up. When possible, scale on what's coming, not what's already hurting.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="timeline-labels-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Metric', 'Type', 'Best For'],
@@ -112,19 +117,31 @@ __Leading indicators__ like requests per second and queue depth increase the mom
     tbody: {
       tr: [
         {
-          th: 'Requests per second',
+          th: {
+            label: 'Requests per second',
+            color: 'bg-success',
+          },
           td: ['Leading', 'Web APIs, high-traffic services'],
         },
         {
-          th: 'Queue depth',
+          th: {
+            label: 'Queue depth',
+            color: 'bg-info',
+          },
           td: ['Leading', 'Async workers, background job processors'],
         },
         {
-          th: 'CPU utilization',
+          th: {
+            label: 'CPU utilization',
+            color: 'bg-warning',
+          },
           td: ['Lagging', 'Compute-bound workloads, synchronous processing'],
         },
         {
-          th: 'Response latency',
+          th: {
+            label: 'Response latency',
+            color: 'bg-danger',
+          },
           td: ['Lagging', 'SLO-driven scaling, user-facing services'],
         },
       ],
@@ -223,7 +240,7 @@ HPA tuning comes down to three things: understanding delays so you know what's r
   ]}
 />
 
-If your traffic is predictable — business hours, scheduled events, marketing campaigns — don't rely on HPA to catch up. Pre-scale ahead of time using KEDA cron triggers or simple CronJobs. HPA's job is handling __unexpected__ variance around your baseline, not scrambling to meet traffic you knew was coming.
+If your traffic is predictable — business hours, scheduled events, marketing campaigns — don't rely on HPA to catch up. Pre-scale ahead of time using KEDA cron triggers or simple CronJobs. HPA's job is handling _unexpected_ variance around your baseline, not scrambling to meet traffic you knew was coming.
 
 Start with defaults, observe behavior under real load, and tune based on what you see. If you're scaling too slowly, reduce stabilization windows and increase policy percentages. If you're oscillating, increase stabilization and lower your target utilization. There's no universal "best" configuration — only the configuration that matches your traffic pattern.
 
diff --git a/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/pdf.mdx b/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/pdf.mdx
index 3faec4689..64631b8d9 100644
--- a/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/pdf.mdx
+++ b/src/content/articles/kubernetes-hpa-autoscaling-metrics-tuning-latency/pdf.mdx
@@ -25,12 +25,12 @@ The Horizontal Pod Autoscaler (HPA) looks deceptively simple: set a target CPU p
 
 I've watched this play out repeatedly. An e-commerce team configures HPA with a 50% CPU target. During a flash sale, traffic spikes 10x in 30 seconds. HPA takes 15 seconds to detect the load via the metrics server, another 15 seconds for the controller sync, then the stabilization window kicks in. Meanwhile, new pods need to be scheduled, images pulled, and readiness probes passed. By the time capacity catches up—3+ minutes later — frustrated users have already left. The service survived, but barely.
 
-The lesson: HPA is reactive, not predictive. By the time it decides to scale, your workload is already under stress. The goal of HPA tuning is to minimize that reaction time while avoiding oscillation — a balance that requires understanding your traffic patterns, choosing the right metrics, and configuring stabilization windows that match your workload's characteristics.
-
 <Callout type="warning" title="HPA Cannot Predict the Future">
 HPA responds to current conditions, not anticipated load. If your traffic can spike faster than HPA can respond (typically 30-90 seconds minimum), you need either pre-scaling for known events, higher baseline capacity, or request queuing to absorb the delay.
 </Callout>
 
+The lesson: HPA is reactive, not predictive. By the time it decides to scale, your workload is already under stress. The goal of HPA tuning is to minimize that reaction time while avoiding oscillation — a balance that requires understanding your traffic patterns, choosing the right metrics, and configuring stabilization windows that match your workload's characteristics.
+
 ## HPA Fundamentals
 
 ### How HPA Works
@@ -45,6 +45,7 @@ If you have 3 replicas running at 75% CPU with a target of 50%, HPA calculates $
 
 <Diagram
   src={hpaScalingDiagram}
+  size="full"
   title="HPA scaling decision flow."
   description="Sequence diagram showing the Horizontal Pod Autoscaler control loop. The participants are HPA Controller, Metrics Server, Deployment, and Pods. Inside a loop labeled Every 15 seconds by default, the HPA Controller queries the Metrics Server for current metrics, and the Metrics Server returns CPU at 75 percent and Memory at 60 percent. The HPA Controller then calculates desired replicas internally, with a note explaining the formula desired = ceil(3 × 75/50) = 5. Next, the controller applies the stabilization window and checks scale-up or scale-down policies. It then tells the Deployment to scale to 5 replicas, and the Deployment creates 2 new pods. A note over the Pods indicates the lifecycle Scheduling to Starting to Ready. The diagram shows that HPA scaling is a repeated control loop that depends on periodic metrics collection, replica calculation, policy evaluation, and the time it takes for newly created pods to become ready."
 />
@@ -84,7 +85,8 @@ The 50% target might seem conservative, but it's intentional. You want headroom
 The HPA loop sounds fast—15-second intervals — but the total time from "traffic spike begins" to "new capacity receives traffic" is much longer. Every step in the pipeline adds latency.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Delay Component', 'Typical Duration', 'Can Reduce?', 'How'],
@@ -126,7 +128,10 @@ The HPA loop sounds fast—15-second intervals — but the total time from "traf
 Here's a best-case timeline for a traffic spike (assuming 15-second metrics resolution and cached images):
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "T+0s",
@@ -168,7 +173,8 @@ Even with aggressive tuning, the minimum realistic time to scale up is 30-45 sec
 The metric you choose determines how quickly HPA reacts — and whether it reacts to the right signal at all. Most teams start with CPU utilization because it's built-in, but CPU is a __lagging__ indicator: by the time CPU spikes, requests are already queuing. For web services, requests per second or queue depth are __leading__ indicators that increase before your system shows stress.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="timeline-labels-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Metric Type', 'Pros', 'Cons', 'Best For'],
@@ -227,6 +233,7 @@ Custom metrics let you scale on application-specific signals instead of generic
 
 <Diagram
   src={customMetricsDiagram}
+  size="full"
   title="Custom metrics flow from application to HPA."
   description="Flowchart showing how application metrics reach the Horizontal Pod Autoscaler through Prometheus-based custom metrics. The main path starts at Application, which exposes a /metrics endpoint to Prometheus. Prometheus sends PromQL queries to Prometheus Adapter. Prometheus Adapter exposes those results through the Custom Metrics API to the HPA Controller. The HPA Controller then scales the Deployment. A separate path shows Metrics Server sending Resource Metrics API data directly to the same HPA Controller. The diagram emphasizes that HPA can consume both standard resource metrics from Metrics Server and custom application metrics translated through Prometheus and Prometheus Adapter before making scaling decisions."
 />
@@ -234,19 +241,32 @@ Custom metrics let you scale on application-specific signals instead of generic
 HPA supports three metric types, each suited to different scenarios:
 
 <List
-  variant="check-icons-list"
+  variant="three-column-icon-list"
+  classes={{
+    header: "text-page-inverse",
+    text: "text-content",
+  }}
   items={[
     {
-      lead: "Resource metrics",
+      title: "Resource metrics",
       text: "(CPU, memory): Built-in via Metrics Server. No setup required, but limited to what kubelets report.",
+      icon: "graph",
+      color: "success",
+      bgColor: "success-inverse",
     },
     {
-      lead: "Pod metrics",
+      title: "Pod metrics",
       text: "Custom metrics exposed by your application and scraped by Prometheus. Queried per-pod, then averaged.",
+      icon: "api",
+      color: "info",
+      bgColor: "info-inverse",
     },
     {
-      lead: "External metrics",
+      title: "External metrics",
       text: "Metrics from outside Kubernetes — queue depths, SaaS API usage, database connections. Useful when scaling should respond to external systems.",
+      icon: "globe",
+      color: "warning",
+      bgColor: "warning-inverse",
     },
   ]}
 />
@@ -398,18 +418,21 @@ Code: Asymmetric HPA behavior — aggressive scale-up, conservative scale-down.
 The `selectPolicy` field determines how HPA chooses between multiple policies:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:mr-18 mb-12",
+  }}
   items={[
     {
-      lead: "Max",
+      lead: "Max:",
       text: "Use the policy that results in the largest change. For scale-up, this means adding the most pods. Good for aggressive scaling.",
     },
     {
-      lead: "Min",
+      lead: "Min:",
       text: "Use the policy that results in the smallest change. For scale-down, this means removing the fewest pods. Good for conservative scaling.",
     },
     {
-      lead: "Disabled",
+      lead: "Disabled:",
       text: "Don't scale in this direction at all.",
     },
   ]}
@@ -417,6 +440,7 @@ The `selectPolicy` field determines how HPA chooses between multiple policies:
 
 <Diagram
   src={hpaPolicyDiagram}
+  size="full"
   title="HPA policy selection flow."
   description="Flowchart showing how HPA decides whether and how to scale after a metric exceeds its target. The process starts at Metric exceeds target and moves to a decision asking whether the stabilization window has passed. If no, the flow goes to Wait and re-evaluate. If yes, the flow moves to Calculate replicas per each policy. From there, a decision asks for the selectPolicy setting. If the value is Max, the chart goes to Use largest increase. If the value is Min, it goes to Use smallest increase. If the value is Disabled, it goes to No scaling. The Max and Min branches both lead to Apply scale-up. The diagram shows that HPA does not act on raw metrics alone: it first waits for stabilization rules, then compares scaling policies, then applies the policy selected by the configuration."
 />
@@ -426,7 +450,7 @@ The `selectPolicy` field determines how HPA chooses between multiple policies:
 Different traffic patterns call for different behavior configurations. The tradeoff is always between responsiveness (scale fast to handle spikes) and stability (avoid oscillation and wasted resources).
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: ['Pattern', 'Use Case', 'Scale-Up', 'Scale-Down', 'Tradeoff'],
@@ -556,7 +580,8 @@ Before tuning HPA, you need to understand your traffic. Four characteristics mat
 These characteristics map to specific HPA strategies. The table below shows common traffic patterns and the scaling approaches that work best for each:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="semantic-coloring-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Traffic Type', 'Peak:Trough', 'Ramp-Up', 'Predictable', 'Recommended Strategy'],
@@ -670,16 +695,22 @@ __Problem: HPA stuck at minReplicas despite high load__
 This usually means HPA can't see your metrics. Check the Conditions section in `kubectl describe hpa`—look for "unable to get metrics" or "AbleToScale: False". The most common causes:
 
 <List
-  variant="check-icons-list"
+  variant="colored-marker-list"
+  classes={{
+    wrapper: "sm:ml-12 sm:mr-12 mb-6",
+  }}
   items={[
     {
       text: "Metrics Server not running or unhealthy",
+      color: "bg-accent",
     },
     {
       text: "Pods missing resource requests (HPA can't calculate utilization without knowing the baseline)",
+      color: "bg-secondary",
     },
     {
       text: "Custom metrics adapter not configured for non-CPU metrics",
+      color: "bg-success",
     },
   ]}
 />
@@ -751,6 +782,7 @@ When HPA isn't behaving as expected, work through this diagnostic flow:
 
 <Diagram
   src={hpaDebuggingDiagram}
+  size="full"
   title="HPA debugging decision tree."
   description="Flowchart showing a troubleshooting path for HPA behavior problems. The process starts at HPA not scaling as expected and first asks whether kubectl describe hpa shows metrics. If no and the message says unable to get metrics, the path goes to Check Metrics Server and then asks whether kubectl top pods works. If that answer is no, the next step is Fix Metrics Server deployment. If yes, the next step is Check pod resource requests. If metrics are visible, the chart asks what the symptom is. For Not scaling up, it asks whether the current metric is above target. If no, the result is Load not high enough yet. If yes, the next step is Check scaleUp stabilization and policies. For Not scaling down, it asks whether the current metric is below target. If no, the result is Load still too high. If yes, the next step is Check scaleDown stabilization and policies. For Oscillating, the path proceeds through Increase stabilization windows, then Lower target utilization, then Smooth metrics averaging. The diagram is meant to guide an operator from a visible scaling symptom to the most likely configuration or metrics problem."
 />
@@ -842,23 +874,9 @@ Code: Multi-metric HPA using CPU, RPS, and latency.
 
 Here's how the calculation works. Suppose current state is 5 replicas:
 
-<List
-  variant="check-icons-list"
-  items={[
-    {
-      lead: "CPU metric",
-      text: "60% utilization, target 50% → $$5 \\times (60/50) = 6$$ replicas",
-    },
-    {
-      lead: "RPS metric",
-      text: "120 RPS/pod, target 100 → $$5 \\times (120/100) = 6$$ replicas",
-    },
-    {
-      lead: "Latency metric",
-      text: "400ms P99, target 500ms → $$5 \\times (400/500) = 4$$ replicas",
-    },
-  ]}
-/>
+- __CPU metric__: 60% utilization, target 50% → $$5 \times (60/50) = 6$$ replicas
+- __RPS metric__: 120 RPS/pod, target 100 → $$5 \times (120/100) = 6$$ replicas
+- __Latency metric__: 400ms P99, target 500ms → $$5 \times (400/500) = 4$$ replicas
 
 HPA takes the maximum: 6 replicas. The latency metric calculates fewer replicas than currently running (4 < 5), which would suggest scaling down if it were the only metric — but CPU and RPS both want more capacity, so we scale up. This "max wins" behavior ensures you don't under-provision when __any__ metric indicates stress.
 
@@ -935,7 +953,7 @@ Use KEDA when you need scale-to-zero (queue workers, batch jobs, dev environment
 HPA tuning comes down to four principles:
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Understand the delays.",
@@ -956,8 +974,8 @@ HPA tuning comes down to four principles:
   ]}
 />
 
-The tuning process is iterative. Start with defaults, run under real load, and watch what happens. If you're scaling too slowly, reduce stabilization windows and increase policy percentages. If you're oscillating, increase stabilization and lower your target utilization. If you're wasting money on idle pods, tighten scale-down policies or raise target utilization. There's no universal "best" configuration — only the configuration that matches your traffic pattern.
-
 <Callout type="info" title="The Goal Is Invisibility">
 The best HPA configuration is one you never think about. Traffic varies, capacity adjusts, users don't notice. Getting there requires measuring actual behavior — not guessing at configurations. Instrument your HPA, watch its scaling decisions under real load, and tune based on data. The article's examples are starting points, not destinations.
 </Callout>
+
+The tuning process is iterative. Start with defaults, run under real load, and watch what happens. If you're scaling too slowly, reduce stabilization windows and increase policy percentages. If you're oscillating, increase stabilization and lower your target utilization. If you're wasting money on idle pods, tighten scale-down policies or raise target utilization. There's no universal "best" configuration — only the configuration that matches your traffic pattern.

From 1de146a38f9e4af1b4e7b09f8381051a5e1e79c8 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 04:32:47 +0300
Subject: [PATCH 14/15] Final pass
 kubernetes-ingress-gateway-api-comparison-migration article

---
 _TODO.md                                      |   9 +
 .../index.mdx                                 |  20 ++-
 .../pdf.mdx                                   | 169 +++++++++++-------
 3 files changed, 125 insertions(+), 73 deletions(-)

diff --git a/_TODO.md b/_TODO.md
index 493549b35..69fbc093c 100644
--- a/_TODO.md
+++ b/_TODO.md
@@ -226,6 +226,8 @@ https://mermaid.js.org/config/directives.html
 
 - Improve `<abbr>` styling: https://codepen.io/ire/pen/NoqWpm
 
+- Moving the scroll bar up quickly with the mouse seems to make the header logic break - the Switcher component and Breadcrumbs are hidden under the header
+
 ## List Component
 
 - Task list checked variant Markdown in dark theme is awkward, it has a dark shadow
@@ -323,3 +325,10 @@ https://mermaid.js.org/config/directives.html
     tbody: '!text-content',
   }}
 />
+
+<Table
+  variant="numbered-review-table"
+  fullWidth={false}
+  classes={{
+    tbody: "[&_tr>td:nth-of-type(2)]:!font-normal",
+  }}
diff --git a/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/index.mdx b/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/index.mdx
index f492c8490..2e5deb5a1 100644
--- a/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/index.mdx
+++ b/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/index.mdx
@@ -9,17 +9,17 @@ tags: ["cloud-platforms","kubernetes"]
 featured: true
 ---
 
+*[CRD]: Custom Resource Definition
 *[GA]: General Availability
-*[TLS]: Transport Layer Security
-*[TCP]: Transmission Control Protocol
-*[UDP]: User Datagram Protocol
 *[gRPC]: Google Remote Procedure Call
-*[CRD]: Custom Resource Definition
 *[RBAC]: Role-Based Access Control
+*[TCP]: Transmission Control Protocol
+*[TLS]: Transport Layer Security
+*[UDP]: User Datagram Protocol
 
 You've spent months perfecting your NGINX Ingress configuration. The annotations are just right, traffic flows smoothly, and you've documented every quirk. Then someone decides you're switching to Traefik. Or Contour. Or migrating to a service mesh that uses Gateway API. Suddenly, none of your annotations work. Some are silently ignored, others cause validation errors, and you're left wondering why Kubernetes made this so hard.
 
-The answer: Ingress was designed in 2015 as a minimal abstraction. It defines __what__ you want (route traffic to services) but leaves __how__ entirely to the controller. Every controller filled that gap differently, creating the annotation mess you're now untangling.
+The answer: <Highlighter>Ingress was designed in 2015 as a minimal abstraction. It defines _what_ you want (route traffic to services) but leaves _how_ entirely to the controller.</Highlighter> Every controller filled that gap differently, creating the annotation mess you're now untangling.
 
 Gateway API, which reached GA in 2023, takes a different approach. It's more expressive, more portable, and designed for multi-team environments. But more powerful doesn't always mean better for your use case. I've seen teams migrate to Gateway API because "it's the future," only to discover that their simple routing requirements worked perfectly with Ingress — they just added complexity without new capabilities.
 
@@ -90,7 +90,11 @@ Code: HTTPRoute with cross-namespace reference to a shared Gateway.
 The critical difference: HTTPRoute uses native fields for routing configuration, not annotations. These fields work identically across any Gateway API implementation — Envoy Gateway, Istio, Contour, Kong, NGINX Gateway Fabric. Portability is built in, not bolted on.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
+  fullWidth={false}
+  classes={{
+    tbody: "[&_tr>td:nth-of-type(2)]:!font-normal",
+  }}
   content={{
     thead: {
       th: ['Aspect', 'Ingress', 'Gateway API'],
@@ -133,12 +137,12 @@ Gateway API's layered architecture also enables something Ingress can't: applica
 
 The decision depends on your current situation, not abstract feature comparisons.
 
-<Newsletter />
-
 ### When to Stick with Ingress
 
 Your routing needs are simple — host-based routing, path prefixes, TLS termination. If everything lives in one namespace (or a small number managed by one team) and your current setup works without friction, Ingress is fine. There's no deprecation timeline. The Kubernetes networking SIG has confirmed both APIs will coexist indefinitely.
 
+<Newsletter />
+
 Migrating because Gateway API is "the future" wastes engineering time. I've watched teams spend weeks converting resources, only to end up with equivalent functionality in a more complex setup. They'd have been better served improving their deployment pipeline or writing better runbooks.
 
 Ingress makes sense for: a single application with a few endpoints, internal tools with basic routing, microservices where one team owns everything.
diff --git a/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/pdf.mdx b/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/pdf.mdx
index 009cc8c8a..8df4c1e95 100644
--- a/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/pdf.mdx
+++ b/src/content/articles/kubernetes-ingress-gateway-api-comparison-migration/pdf.mdx
@@ -12,14 +12,14 @@ featured: true
 import ingressDiagram from "./diagrams/ingress-uses-flat-resources-gateway-api-uses-shared-gateway.jpg"
 import roleBasedDiagram from "./diagrams/role-based-ownership-with-gateway-api.jpg"
 
+*[CRD]: Custom Resource Definition
 *[GA]: General Availability
-*[TLS]: Transport Layer Security
-*[TCP]: Transmission Control Protocol
-*[UDP]: User Datagram Protocol
 *[gRPC]: Google Remote Procedure Call
-*[SNI]: Server Name Indication
-*[CRD]: Custom Resource Definition
 *[RBAC]: Role-Based Access Control
+*[SNI]: Server Name Indication
+*[TCP]: Transmission Control Protocol
+*[TLS]: Transport Layer Security
+*[UDP]: User Datagram Protocol
 
 Kubernetes Ingress has been the standard for HTTP routing since 2015, but its limitations led to every ingress controller implementing different annotations and behaviors. If you've ever tried to port an Ingress configuration from NGINX to Traefik, you've felt this pain — annotations that worked perfectly on one controller are silently ignored by another. Gateway API, which launched in 2020 and reached GA in 2023, addresses these limitations with a more expressive, portable, and role-oriented design.
 
@@ -27,19 +27,19 @@ But more powerful doesn't always mean better for your use case.
 
 I've seen this play out both ways. A team running NGINX Ingress Controller decided to migrate to Gateway API because "it's the future." They spent two weeks converting resources, only to discover that their simple host-based routing with TLS termination worked perfectly with Ingress — Gateway API added complexity without new capabilities. Meanwhile, another team I worked with was managing a multi-tenant platform with complex traffic splitting and cross-namespace routing. They'd accumulated a mess of hacky Ingress annotations to work around limitations. For them, Gateway API solved real problems and simplified their configuration.
 
-The lesson: evaluate based on your actual requirements, not industry hype. The choice between Ingress and Gateway API depends on your current tooling, team structure, and routing complexity — not on which technology is newer.
-
 <Callout type="info">
 There's no deprecation timeline for Ingress. The Kubernetes networking SIG has stated both APIs will be supported indefinitely. Plan your technology choices assuming Ingress remains viable for at least the next 5-10 years.
 </Callout>
 
+The lesson: evaluate based on your actual requirements, not industry hype. The choice between Ingress and Gateway API depends on your current tooling, team structure, and routing complexity — not on which technology is newer.
+
 ## Understanding the Models
 
 Before diving into features and migration, it helps to understand how these two APIs think about routing. Ingress is flat — one resource type handles everything. Gateway API is layered — different resource types for different concerns, managed by different teams.
 
 ### Ingress Model
 
-Ingress uses a single resource type that combines routing rules, TLS configuration, and backend references. Everything lives in one YAML file, which makes simple cases easy but complex cases awkward. The catch is that Ingress itself only defines the __interface__ — the actual behavior depends entirely on which controller you're running. NGINX Ingress Controller interprets annotations one way; Traefik interprets them differently; some controllers ignore certain annotations entirely.
+Ingress uses a single resource type that combines routing rules, TLS configuration, and backend references. Everything lives in one YAML file, which makes simple cases easy but complex cases awkward. The catch is that Ingress itself only defines the _interface_ — the actual behavior depends entirely on which controller you're running. NGINX Ingress Controller interprets annotations one way; Traefik interprets them differently; some controllers ignore certain annotations entirely.
 
 ```yaml title="ingress-example.yaml"
 # Single Ingress resource handles routing, TLS, and backend config
@@ -161,6 +161,7 @@ Notice how the HTTPRoute in the `production` namespace can reference a Gateway i
 
 <Diagram
   src={ingressDiagram}
+  size="full"
   title="Ingress uses flat resources - Gateway API uses a shared Gateway."
   description="Flowchart comparing the structural models of Ingress and Gateway API. On the left, a grouped section labeled Ingress Model: Single Resource shows three separate Ingress resources, each pointing to a single Controller, and that Controller pointing to a Service. This illustrates that Ingress resources are flat and controller behavior is centralized behind one implementation. On the right, a grouped section labeled Gateway API: Layered Resources shows GatewayClass pointing to Gateway, then Gateway pointing to three route resources: HTTPRoute Team A, HTTPRoute Team B, and GRPCRoute Team C. Each route then points to its own backend service: Service A, Service B, and Service C. The diagram emphasizes that Gateway API splits responsibilities into layers and allows multiple teams and route types to share a common Gateway while still routing to separate services."
 />
@@ -168,7 +169,11 @@ Notice how the HTTPRoute in the `production` namespace can reference a Gateway i
 The table below summarizes the key differences. If you're scanning for a quick answer: Ingress is simpler when you don't need the advanced features, Gateway API is more capable when you do.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
+  fullWidth={false}
+  classes={{
+    tbody: "[&_tr>td:nth-of-type(2)]:!font-normal",
+  }}
   content={{
     thead: {
       th: ['Aspect', 'Ingress', 'Gateway API'],
@@ -220,7 +225,10 @@ Gateway API's layered model adds complexity. If you don't need cross-namespace r
 Beyond basic host and path matching, modern routing often requires matching on headers, query parameters, or HTTP methods. Ingress provides limited support for these patterns — you're dependent on controller-specific annotations that may or may not exist. Gateway API makes advanced matching a first-class feature.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
+  classes={{
+    tbody: "[&_tr>td:nth-of-type(2)]:!font-normal",
+  }}
   content={{
     thead: {
       th: ['Capability', 'Ingress', 'Gateway API'],
@@ -380,7 +388,11 @@ Code: gRPC routing with method-level matching in Gateway API.
 The table below summarizes protocol support across both APIs. For HTTP workloads, either option works. For anything else, Gateway API is your only portable choice.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     thead: {
       th: ['Protocol', 'Ingress', 'Gateway API', 'Status'],
@@ -389,27 +401,27 @@ The table below summarizes protocol support across both APIs. For HTTP workloads
       tr: [
         {
           th: 'HTTP',
-          td: ['✓ Native', '✓ HTTPRoute', 'GA'],
+          td: ['<span class="text-success">✓</span> Native', '<span class="text-success">✓</span> HTTPRoute', 'GA'],
         },
         {
           th: 'HTTPS (terminate)',
-          td: ['✓ Native', '✓ HTTPRoute + TLS', 'GA'],
+          td: ['<span class="text-success">✓</span> Native', '<span class="text-success">✓</span> HTTPRoute + TLS', 'GA'],
         },
         {
           th: 'HTTPS (passthrough)',
-          td: ['Annotation-dependent', '✓ TLSRoute', 'GA'],
+          td: ['Annotation-dependent', '<span class="text-success">✓</span> TLSRoute', 'GA'],
         },
         {
           th: 'TCP',
-          td: ['Not supported', '✓ TCPRoute', 'Beta'],
+          td: ['Not supported', '<span class="text-success">✓</span> TCPRoute', 'Beta'],
         },
         {
           th: 'UDP',
-          td: ['Not supported', '✓ UDPRoute', 'Alpha'],
+          td: ['Not supported', '<span class="text-success">✓</span> UDPRoute', 'Alpha'],
         },
         {
           th: 'gRPC',
-          td: ['Annotation-dependent', '✓ GRPCRoute', 'GA'],
+          td: ['Annotation-dependent', '<span class="text-success">✓</span> GRPCRoute', 'GA'],
         },
       ],
     },
@@ -420,7 +432,7 @@ The table below summarizes protocol support across both APIs. For HTTP workloads
 
 ## Role-Based Ownership
 
-In organizations with multiple teams, the question of __who manages what__ becomes critical. With Ingress, there's no natural separation — anyone with permission to create Ingress resources in a namespace can affect cluster-wide routing behavior. This leads to either overly permissive access (risky) or centralized bottlenecks where a platform team manages all routing (slow).
+In organizations with multiple teams, the question of _who manages what_ becomes critical. With Ingress, there's no natural separation — anyone with permission to create Ingress resources in a namespace can affect cluster-wide routing behavior. This leads to either overly permissive access (risky) or centralized bottlenecks where a platform team manages all routing (slow).
 
 Gateway API's layered architecture maps naturally to organizational boundaries. Each layer corresponds to a different team with different responsibilities and different access levels.
 
@@ -429,19 +441,22 @@ Gateway API's layered architecture maps naturally to organizational boundaries.
 The three-layer model creates clear ownership:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: 'Infrastructure team',
-      text: 'manages GatewayClass resources. They select and configure the controller, set cluster-wide policies, and typically have cluster-admin access. This layer changes rarely — maybe during major upgrades or when adding new controller capabilities.',
+      text: 'Manages GatewayClass resources. They select and configure the controller, set cluster-wide policies, and typically have cluster-admin access. This layer changes rarely — maybe during major upgrades or when adding new controller capabilities.',
     },
     {
       lead: 'Platform team',
-      text: 'manages Gateway resources. They configure listeners, TLS certificates, and crucially, which namespaces can attach routes. They control the blast radius of application team changes through the `allowedRoutes` configuration.',
+      text: 'Manages Gateway resources. They configure listeners, TLS certificates, and crucially, which namespaces can attach routes. They control the blast radius of application team changes through the `allowedRoutes` configuration.',
     },
     {
       lead: 'Application teams',
-      text: 'manage HTTPRoute resources in their own namespaces. They define their routing rules, but can only attach to Gateways that explicitly allow their namespace. They can\'t affect other teams\' traffic.',
+      text: 'Manage HTTPRoute resources in their own namespaces. They define their routing rules, but can only attach to Gateways that explicitly allow their namespace. They can\'t affect other teams\' traffic.',
     },
   ]}
 />
@@ -504,6 +519,7 @@ This separation is enforced at the Kubernetes API level, not just by convention.
 
 <Diagram
   src={roleBasedDiagram}
+  size="full"
   title="Role-based ownership with Gateway API."
   description="Flowchart showing how Gateway API maps routing resources to different team responsibilities. A grouped section labeled Infrastructure Team contains GatewayClass pointing to Gateway Controller through a controllerName relationship. A grouped section labeled Platform Team contains Gateway pointing back to GatewayClass through gatewayClassName and also pointing to a Namespace Selector through allowedRoutes. A grouped section labeled App Team A contains HTTPRoute A pointing to Gateway through parentRef and also pointing to Service A. A grouped section labeled App Team B contains HTTPRoute B pointing to Gateway through parentRef and also pointing to Service B. The Namespace Selector points to HTTPRoute A and HTTPRoute B through label match relationships. The diagram shows that infrastructure teams choose the controller, platform teams manage the shared Gateway and define which namespaces may attach, and application teams manage their own routes and services only when their namespaces satisfy the selector rules."
 />
@@ -525,22 +541,25 @@ Assuming you've already decided Gateway API is the right fit (see the Decision F
 __Timing signals that suggest waiting:__
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: 'You\'re in the middle of a major release or incident stabilization period',
+      lead: 'You\'re in the middle of a major release or incident stabilization period',
     },
     {
-      text: 'The team responsible for routing config doesn\'t have capacity for learning and testing',
+      lead: 'The team responsible for routing config doesn\'t have capacity for learning and testing',
     },
     {
-      text: 'Your controller\'s Gateway API support is still in beta or missing route types you need',
+      lead: 'Your controller\'s Gateway API support is still in beta or missing route types you need',
     },
     {
-      text: 'You have a complex `configuration-snippet` annotation that doesn\'t have a clear Gateway API equivalent',
+      lead: 'You have a complex <span class="font-mono">configuration-snippet</span> annotation that doesn\'t have a clear Gateway API equivalent',
     },
     {
-      text: 'Your CI/CD pipeline doesn\'t have good staging coverage for routing changes',
+      lead: 'Your CI / CD pipeline doesn\'t have good staging coverage for routing changes',
     },
   ]}
 />
@@ -548,25 +567,28 @@ __Timing signals that suggest waiting:__
 __Prerequisite checklist before starting:__
 
 <List
-  variant="check-icons-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: 'Controller supports Gateway API at GA level for the route types you need — most major controllers (NGINX Gateway Fabric, Envoy Gateway, Istio, Contour, Kong, Traefik) have GA support',
+      lead: 'Controller supports Gateway API at GA level for the route types you need — most major controllers (NGINX Gateway Fabric, Envoy Gateway, Istio, Contour, Kong, Traefik) have GA support',
     },
     {
-      text: 'Team has read the official Gateway API getting started guide',
+      lead: 'Team has read the official Gateway API getting started guide',
     },
     {
-      text: 'Staging environment can run parallel Ingress and Gateway API resources',
+      lead: 'Staging environment can run parallel Ingress and Gateway API resources',
     },
     {
-      text: 'Rollback plan documented (typically: delete HTTPRoute, traffic returns to Ingress)',
+      lead: 'Rollback plan documented (typically: delete HTTPRoute, traffic returns to Ingress)',
     },
     {
-      text: 'Monitoring covers both Ingress and Gateway API traffic paths',
+      lead: 'Monitoring covers both Ingress and Gateway API traffic paths',
     },
     {
-      text: 'At least one low-risk service identified for initial migration',
+      lead: 'At least one low-risk service identified for initial migration',
     },
   ]}
 />
@@ -579,9 +601,15 @@ Migration timelines depend heavily on annotation complexity. If your Ingress res
 
 The safest migration runs both APIs in parallel, migrating routes one at a time with the ability to roll back each change independently.
 
-__Phase 1: Parallel operation (2-4 weeks)__
-
-Deploy the GatewayClass and Gateway resources, but only create HTTPRoutes for __new__ services. Your existing Ingress resources continue to handle existing traffic. This phase validates that your Gateway setup works without risking existing routes.
+<List
+  variant="numbered-with-background-list"
+  items={[
+    {
+      lead: 'Phase 1: Parallel operation (2-4 weeks)',
+      text: 'Deploy the GatewayClass and Gateway resources, but only create HTTPRoutes for new services. Your existing Ingress resources continue to handle existing traffic. This phase validates that your Gateway setup works without risking existing routes.',
+    },
+  ]}
+/>
 
 ```yaml title="parallel-operation.yaml"
 # New API version uses Gateway API
@@ -612,7 +640,8 @@ Code: New routes use Gateway API while existing Ingress handles legacy paths.
 This coexistence works because Ingress and Gateway API are separate resource types that controllers watch independently. When a request arrives, the controller checks both APIs and routes based on the matching rules. Requests to `/v2` match the HTTPRoute; requests to `/v1` match the Ingress. There's no conflict because they handle different paths. If you need to migrate an existing path, create the HTTPRoute first with a different hostname for testing, then update DNS or the hostname field to cut over.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
+  startNumber={2}
   items={[
     {
       lead: 'Phase 2: Migrate routes (4-8 weeks)',
@@ -636,7 +665,8 @@ The key insight is that rollback is easy in phases 1-3. If an HTTPRoute causes p
 Converting an Ingress resource to an HTTPRoute is mostly mechanical, but there are gotchas. The path matching types have different names: Ingress `Prefix` becomes HTTPRoute `PathPrefix`. Ingress `ImplementationSpecific` has no direct equivalent — you'll need to understand what your controller actually did with it and pick the appropriate HTTPRoute match type.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Ingress pathType', 'HTTPRoute path.type', 'Notes'],
@@ -664,22 +694,22 @@ Converting an Ingress resource to an HTTPRoute is mostly mechanical, but there a
 The harder part is annotations. Each annotation that your Ingress uses for non-standard behavior needs to be converted to Gateway API's native features or policy attachments. Common conversions:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
   items={[
     {
-      lead: 'Rewrite annotations',
+      lead: 'Rewrite annotations:',
       text: 'URLRewrite filter',
     },
     {
-      lead: 'Header add/remove annotations',
+      lead: 'Header add/remove annotations:',
       text: 'RequestHeaderModifier / ResponseHeaderModifier filters',
     },
     {
-      lead: 'Rate limiting annotations',
+      lead: 'Rate limiting annotations:',
       text: 'Policy attachment (controller-specific)',
     },
     {
-      lead: 'Authentication annotations',
+      lead: 'Authentication annotations:',
       text: 'Policy attachment or external auth service',
     },
   ]}
@@ -700,8 +730,9 @@ Gateway API is newer, which means less community content and less battle-tested
 All major ingress controllers now support Gateway API at some level. The implementations vary in completeness:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
   content={{
+    figure: 'Controller Gateway API support.',
     thead: {
       th: ['Controller', 'Gateway API Status', 'Route Types', 'Notes'],
     },
@@ -737,7 +768,6 @@ All major ingress controllers now support Gateway API at some level. The impleme
         },
       ],
     },
-    figure: 'Controller Gateway API support.',
   }}
 />
 
@@ -749,7 +779,7 @@ Ingress has an 8-year head start. You'll find more blog posts, more examples, an
 
 Debugging tools are similar in capability but different in approach. Gateway API resources have richer status conditions that tell you exactly why a route isn't working. Run `kubectl describe httproute <name>` and look at the `conditions` section:
 
-```text
+```bash
 Status:
   Parents:
     Conditions:
@@ -766,7 +796,7 @@ This structured feedback beats digging through controller logs — you can see i
 For GitOps workflows (ArgoCD, Flux), both work natively. The main gotcha with Gateway API is that you need the CRDs installed before ArgoCD tries to sync resources that use them — plan your sync waves accordingly.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
   content={{
     thead: {
       th: ['Aspect', 'Ingress', 'Gateway API'],
@@ -812,22 +842,25 @@ After all the feature comparisons and migration details, the decision comes down
 Stick with Ingress if:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: 'Your routing needs are simple: host-based routing, path prefixes, TLS termination',
+      lead: 'Your routing needs are simple: host-based routing, path prefixes, TLS termination',
     },
     {
-      text: 'Everything lives in one namespace (or a small number of namespaces managed by one team)',
+      lead: 'Everything lives in one namespace (or a small number of namespaces managed by one team)',
     },
     {
-      text: 'Your current setup works and you don\'t have concrete problems to solve',
+      lead: 'Your current setup works and you don\'t have concrete problems to solve',
     },
     {
-      text: 'Your team doesn\'t have capacity to learn a new API right now',
+      lead: 'Your team doesn\'t have capacity to learn a new API right now',
     },
     {
-      text: 'Your controller doesn\'t support Gateway API yet',
+      lead: 'Your controller doesn\'t support Gateway API yet',
     },
   ]}
 />
@@ -839,25 +872,28 @@ Example scenarios: a single application with a few endpoints, internal tools wit
 Choose Gateway API if:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: 'You need cross-namespace routing (app teams routing to a shared Gateway)',
+      lead: 'You need cross-namespace routing (app teams routing to a shared Gateway)',
     },
     {
-      text: 'You need native traffic splitting for canary or blue-green deployments',
+      lead: 'You need native traffic splitting for canary or blue-green deployments',
     },
     {
-      text: 'You need TCP, UDP, or gRPC routing',
+      lead: 'You need TCP, UDP, or gRPC routing',
     },
     {
-      text: 'You\'re building a multi-team platform with self-service routing',
+      lead: 'You\'re building a multi-team platform with self-service routing',
     },
     {
-      text: 'You\'re planning a controller migration anyway',
+      lead: 'You\'re planning a controller migration anyway',
     },
     {
-      text: 'It\'s a greenfield project and you want to start with the more portable option',
+      lead: 'It\'s a greenfield project and you want to start with the more portable option',
     },
   ]}
 />
@@ -869,7 +905,10 @@ Example scenarios: multi-tenant platforms, deployment pipelines with canary stag
 You don't have to choose one or the other. Many organizations run both:
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: 'Ingress',
@@ -894,8 +933,8 @@ Ingress is simpler, more mature, and has years of battle-tested operational patt
 
 Gateway API is more powerful and more portable. Its layered architecture enables multi-team self-service with guardrails. Native support for traffic splitting, header manipulation, and non-HTTP protocols eliminates the annotation sprawl that makes Ingress configurations fragile. If you need these capabilities, Gateway API delivers them in a standardized way that works across controllers.
 
-Both APIs will coexist for years — the Kubernetes networking SIG has confirmed there's no deprecation timeline for Ingress. Migrating purely because Gateway API is "the future" is a poor use of engineering time. Migrate when you have concrete requirements that Gateway API solves better: cross-namespace routing, native traffic splitting, protocol support, or role separation. For greenfield projects where you don't have strong opinions, Gateway API is a reasonable default — it's mature enough for production, and starting there avoids a future migration.
-
 <Callout type="success">
 The best choice is the one that solves your actual problems with acceptable complexity. If Ingress works for you, keep using it. If you need Gateway API's capabilities, it's mature enough for production. Make the decision based on requirements, not hype.
 </Callout>
+
+Both APIs will coexist for years — the Kubernetes networking SIG has confirmed there's no deprecation timeline for Ingress. Migrating purely because Gateway API is "the future" is a poor use of engineering time. Migrate when you have concrete requirements that Gateway API solves better: cross-namespace routing, native traffic splitting, protocol support, or role separation. For greenfield projects where you don't have strong opinions, Gateway API is a reasonable default — it's mature enough for production, and starting there avoids a future migration.

From 2bda84c3bd8d1eb12062eda3b015fcc8b8914fe0 Mon Sep 17 00:00:00 2001
From: Kevin Brown <kevin@webstackbuilders.com>
Date: Tue, 17 Mar 2026 05:20:02 +0300
Subject: [PATCH 15/15] Final pass
 kubernetes-multi-cluster-fleet-management-configuration article

---
 .../index.mdx                                 |  99 ++++++++---
 .../pdf.mdx                                   | 167 ++++++++++++------
 2 files changed, 184 insertions(+), 82 deletions(-)

diff --git a/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/index.mdx b/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/index.mdx
index b94ca02c0..44d0af026 100644
--- a/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/index.mdx
+++ b/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/index.mdx
@@ -13,17 +13,17 @@ featured: true
 *[GitOps]: Git Operations
 *[K8s]: Kubernetes
 
-A platform team I worked with managed 15 Kubernetes clusters across dev, staging, and three production regions. They'd started with infrastructure-as-code, consistent tooling, and documented architecture. Two years later, hotfixes had been applied to some clusters and not others. "Temporary" manual changes became permanent. Someone upgraded the service mesh in US-East but forgot US-West. The clusters that started identical had become 15 unique configurations — and nobody could confidently say what was __intentionally__ different versus what had __accidentally__ drifted.
+A platform team I worked with managed 15 Kubernetes clusters across dev, staging, and three production regions. They'd started with infrastructure-as-code, consistent tooling, and documented architecture. Two years later, hotfixes had been applied to some clusters and not others. "Temporary" manual changes became permanent. Someone upgraded the service mesh in US-East but forgot US-West. The clusters that started identical had become 15 unique configurations — and nobody could confidently say what was _intentionally_ different versus what had _accidentally_ drifted.
 
-This is the core multi-cluster problem: not deployment (that's straightforward), but __consistency__. How do you know what's supposed to be the same across clusters? How do you detect when drift occurs? The answer is GitOps-based fleet management with automated drift detection. The practical questions are which tools to use — and how to prevent drift once you've deployed them.
+<Highlighter>This is the core multi-cluster problem: not deployment (that's straightforward), but _consistency_.</Highlighter> How do you know what's supposed to be the same across clusters? How do you detect when drift occurs? The answer is GitOps-based fleet management with automated drift detection. The practical questions are which tools to use — and how to prevent drift once you've deployed them.
 
 ## ArgoCD vs Flux: Two Models for Multi-Cluster
 
-The two dominant GitOps tools for multi-cluster management are ArgoCD (with ApplicationSets) and Flux. Both store desired state in Git and reconcile clusters toward that state. They differ fundamentally in __how__ they handle multi-cluster targeting. Let's start with ArgoCD's centralized approach, then contrast it with Flux's distributed model.
+The two dominant GitOps tools for multi-cluster management are ArgoCD (with ApplicationSets) and Flux. Both store desired state in Git and reconcile clusters toward that state. They differ fundamentally in _how_ they handle multi-cluster targeting. Let's start with ArgoCD's centralized approach, then contrast it with Flux's distributed model.
 
 ### ArgoCD ApplicationSets: Centralized Generation
 
-ArgoCD ApplicationSets use a centralized model. A single ApplicationSet controller generates multiple ArgoCD Applications — one per target cluster — from a template. The __generator__ produces parameters (cluster names, environments, regions), and the __template__ stamps out Applications using those parameters.
+ArgoCD ApplicationSets use a centralized model. A single ApplicationSet controller generates multiple ArgoCD Applications — one per target cluster — from a template. The _generator_ produces parameters (cluster names, environments, regions), and the _template_ stamps out Applications using those parameters.
 
 The cluster generator is the most common pattern. It queries ArgoCD's registered clusters, filters by labels, and creates one Application per matching cluster:
 
@@ -71,26 +71,66 @@ Flux takes the opposite approach. Instead of a central controller generating App
 
 The typical pattern uses three layers: base configurations (shared across all clusters), environment overlays (dev/staging/production), and cluster-specific directories. Each cluster's Flux installation points to its own path in the repo:
 
-```text
-platform-config/
-├── base/
-│   └── platform/
-│       ├── kustomization.yaml
-│       ├── deployment.yaml
-│       └── service.yaml
-├── overlays/
-│   ├── development/
-│   ├── staging/
-│   └── production/
-│       └── kustomization.yaml
-└── clusters/
-    ├── us-east-prod/
-    ├── us-west-prod/
-    └── eu-west-prod/
-        └── kustomization.yaml
-```
-
-Figure: Repository structure for Flux multi-cluster configuration.
+<FileExplorer
+  fullWidth={false}
+  classes={{
+    wrapper: "sm:ml-24 sm:mr-24 mb-6",
+  }}
+  figure="Repository structure for Flux multi-cluster configuration."
+  data={[
+    {
+      type: 'folder',
+      name: 'platform-config',
+      children: [
+        {
+          type: 'folder',
+          name: 'base',
+          children: [
+            {
+              type: 'folder',
+              name: 'platform',
+              children: [
+                { type: 'file', name: 'kustomization.yaml', comment: 'Assembles shared platform manifests' },
+                { type: 'file', name: 'deployment.yaml', comment: 'Defines platform service deployment' },
+                { type: 'file', name: 'service.yaml', comment: 'Exposes platform service internally' },
+              ],
+            },
+          ],
+        },
+        {
+          type: 'folder',
+          name: 'overlays',
+          children: [
+            { type: 'folder', name: 'development' },
+            { type: 'folder', name: 'staging' },
+            {
+              type: 'folder',
+              name: 'production',
+              children: [
+                { type: 'file', name: 'kustomization.yaml', comment: 'Applies production-specific overrides' },
+              ],
+            },
+          ],
+        },
+        {
+          type: 'folder',
+          name: 'clusters',
+          children: [
+            { type: 'folder', name: 'us-east-prod' },
+            { type: 'folder', name: 'us-west-prod' },
+            {
+              type: 'folder',
+              name: 'eu-west-prod',
+              children: [
+                { type: 'file', name: 'kustomization.yaml', comment: 'Sets cluster-specific resources' },
+              ],
+            },
+          ],
+        },
+      ],
+    },
+  ]}
+/>
 
 Flux Kustomizations (not to be confused with Kustomize's kustomization.yaml) define dependencies between layers. Base configs apply first, then environment overlays, then cluster-specific configs:
 
@@ -117,10 +157,10 @@ Code: Flux Kustomization with cluster-specific value substitution.
 
 The `postBuild.substituteFrom` feature injects cluster-specific values from ConfigMaps at reconciliation time — each cluster maintains its own `cluster-values` ConfigMap with region, replica counts, and other parameters.
 
-Flux's model works well when you think in terms of "configuration layers that build on each other." It scales better than ArgoCD for very large fleets (1000+ clusters) because there's no central controller bottleneck. The trade-off is less centralized visibility — there's no built-in UI showing fleet-wide status.
-
 <Newsletter />
 
+Flux's model works well when you think in terms of "configuration layers that build on each other." It scales better than ArgoCD for very large fleets (1000+ clusters) because there's no central controller bottleneck. The trade-off is less centralized visibility — there's no built-in UI showing fleet-wide status.
+
 ### Which to Choose?
 
 The decision isn't about features — both tools can handle most multi-cluster scenarios. It's primarily about mental model. If you think "deploy this app to these clusters," ArgoCD ApplicationSets match that framing. If you think "base config plus environment overlay plus cluster tweaks," Flux's Kustomization hierarchy fits better.
@@ -154,7 +194,7 @@ Auto-remediation is powerful but dangerous. If someone made a legitimate emergen
 
 ### Prevention with Admission Control
 
-Detection tells you __that__ drift happens. Prevention stops it from happening. Kubernetes admission controllers can intercept API requests before resources are created or modified, rejecting changes that violate fleet policies.
+Detection tells you _that_ drift happens. Prevention stops it from happening. Kubernetes admission controllers can intercept API requests before resources are created or modified, rejecting changes that violate fleet policies.
 
 The two main policy engines are OPA/Gatekeeper[^opa-gatekeeper] and Kyverno[^kyverno]. Here's a Kyverno policy that rejects changes to production resources without GitOps annotations:
 
@@ -193,7 +233,10 @@ Drift prevention through admission control is powerful but can block emergency c
 The tools only work if you've done the organizational groundwork:
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: 'Document your fleet topology first.',
diff --git a/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/pdf.mdx b/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/pdf.mdx
index 438b881f6..abfb8a334 100644
--- a/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/pdf.mdx
+++ b/src/content/articles/kubernetes-multi-cluster-fleet-management-configuration/pdf.mdx
@@ -13,29 +13,29 @@ import argocdDiagram from "./diagrams/argocd-generates-applications-centrally-fl
 import configurationLayeringDiagram from "./diagrams/configuration-layering-from-fleet-wide-to-cluster-specific.jpg"
 import multiClusterDiagram from "./diagrams/multi-cluster-topology-patterns.jpg"
 
-*[K8s]: Kubernetes
-*[GitOps]: Git Operations
+*[AKS]: Azure Kubernetes Service
 *[CRD]: Custom Resource Definition
-*[RBAC]: Role-Based Access Control
-*[GKE]: Google Kubernetes Engine
 *[EKS]: Elastic Kubernetes Service
-*[AKS]: Azure Kubernetes Service
+*[GitOps]: Git Operations
+*[GKE]: Google Kubernetes Engine
+*[K8s]: Kubernetes
+*[RBAC]: Role-Based Access Control
 
 Running multiple Kubernetes clusters is easy. Keeping them consistent is hard.
 
-As organizations grow, they accumulate clusters: dev, staging, production, regional deployments, edge locations, disaster recovery. Each cluster starts as a copy of the others, templated from the same base configuration. A platform team I worked with managed 15 clusters across dev, staging, and three production regions. They'd done everything right at the start: infrastructure-as-code, consistent tooling, documented architecture. But two years later, hotfixes had been applied to some clusters and not others, "temporary" manual changes became permanent, and someone upgraded the service mesh in US-East but forgot US-West. The clusters that started identical had become 15 unique configurations — and nobody could tell you what was __intentionally__ different versus what had __accidentally__ drifted.
-
-The multi-cluster management problem isn't primarily about tools. It's about the operating model: how you balance consistency with environment-specific flexibility, how you detect when drift occurs, and how you maintain clarity about what's __supposed__ to be the same versus what's __supposed__ to be different. This article covers the patterns and tools that make fleet management tractable: configuration templating strategies, GitOps-based deployment, drift detection, and progressive rollout across clusters.
+As organizations grow, they accumulate clusters: dev, staging, production, regional deployments, edge locations, disaster recovery. Each cluster starts as a copy of the others, templated from the same base configuration. A platform team I worked with managed 15 clusters across dev, staging, and three production regions. They'd done everything right at the start: infrastructure-as-code, consistent tooling, documented architecture. But two years later, hotfixes had been applied to some clusters and not others, "temporary" manual changes became permanent, and someone upgraded the service mesh in US-East but forgot US-West. The clusters that started identical had become 15 unique configurations — and nobody could tell you what was _intentionally_ different versus what had _accidentally_ drifted.
 
 <Callout type="warning">
 The hardest part of multi-cluster isn't deploying to many clusters — it's knowing what's supposed to be the same vs. different, and detecting when drift occurs. Without this clarity, you're managing independent configurations, not a fleet.
 </Callout>
 
+The multi-cluster management problem isn't primarily about tools. It's about the operating model: how you balance consistency with environment-specific flexibility, how you detect when drift occurs, and how you maintain clarity about what's _supposed_ to be the same versus what's _supposed_ to be different. This article covers the patterns and tools that make fleet management tractable: configuration templating strategies, GitOps-based deployment, drift detection, and progressive rollout across clusters.
+
 ## A Brief History: Why Not Federation?
 
 Kubernetes Federation (KubeFed) was the original attempt to solve multi-cluster management. The idea was appealing: a control plane that could deploy resources across multiple clusters from a single API. You'd create a "FederatedDeployment" and it would propagate to member clusters automatically.
 
-In practice, Federation never gained traction. The v1 implementation was deprecated in 2018, and KubeFed v2 saw limited adoption before being archived in 2022. The problems were fundamental: Federation tried to abstract away cluster differences, but real-world multi-cluster deployments __need__ those differences. A one-size-fits-all API couldn't handle the nuanced configuration variations between dev and production, between AWS and on-prem, between US-East and EU-West.
+In practice, Federation never gained traction. The v1 implementation was deprecated in 2018, and KubeFed v2 saw limited adoption before being archived in 2022. The problems were fundamental: Federation tried to abstract away cluster differences, but real-world multi-cluster deployments _need_ those differences. A one-size-fits-all API couldn't handle the nuanced configuration variations between dev and production, between AWS and on-prem, between US-East and EU-West.
 
 The industry moved toward a different model: GitOps-based fleet management. Instead of a control plane pushing identical configs everywhere, each cluster pulls its configuration from Git, with templating systems handling the variations. This approach — implemented by tools like ArgoCD ApplicationSets, Flux, and Rancher Fleet — provides the consistency benefits Federation promised while preserving the flexibility real deployments require.
 
@@ -43,32 +43,33 @@ The industry moved toward a different model: GitOps-based fleet management. Inst
 
 ### Common Patterns
 
-Organizations arrive at multi-cluster architectures for different reasons, and the reason shapes the configuration strategy. Understanding __why__ you have multiple clusters determines what should be consistent versus different across them.
+Organizations arrive at multi-cluster architectures for different reasons, and the reason shapes the configuration strategy. Understanding _why_ you have multiple clusters determines what should be consistent versus different across them.
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: "Environment-based",
-      text: "clusters are the most common pattern: dev, staging, and production running as separate clusters. The configuration model here is straightforward — core add-ons, security policies, and RBAC structure should be identical, while resource quotas, replica counts, and feature flags differ by environment. You want staging to behave like production, just smaller.",
+      text: "Clusters are the most common pattern: dev, staging, and production running as separate clusters. The configuration model here is straightforward — core add-ons, security policies, and RBAC structure should be identical, while resource quotas, replica counts, and feature flags differ by environment. You want staging to behave like production, just smaller.",
     },
     {
       lead: "Regional",
-      text: "clusters serve global applications or data sovereignty requirements. US-East, US-West, EU-West, and AP-Southeast might all run the same application versions and security policies, but with region-specific endpoints, compliance settings, and capacity. The challenge here is keeping application deployments synchronized while allowing regional customization.",
+      text: "Clusters serve global applications or data sovereignty requirements. US-East, US-West, EU-West, and AP-Southeast might all run the same application versions and security policies, but with region-specific endpoints, compliance settings, and capacity. The challenge here is keeping application deployments synchronized while allowing regional customization.",
     },
     {
       lead: "Workload isolation",
-      text: "clusters separate concerns by team or workload type: frontend, backend, data platform, ML training. Each cluster shares network policies and security baselines, but node types, add-ons, and resource profiles differ dramatically. An ML training cluster needs GPUs and tolerates batch job failures; a frontend cluster needs fast scaling and zero-downtime deployments.",
+      text: "Clusters separate concerns by team or workload type: frontend, backend, data platform, ML training. Each cluster shares network policies and security baselines, but node types, add-ons, and resource profiles differ dramatically. An ML training cluster needs GPUs and tolerates batch job failures; a frontend cluster needs fast scaling and zero-downtime deployments.",
     },
     {
       lead: "Hybrid cloud",
-      text: "clusters span providers: AWS primary, GCP disaster recovery, Azure edge, on-premises for sensitive workloads. Application manifests and security policies stay consistent, but cloud-specific integrations (load balancers, storage classes, IAM bindings) differ by necessity.",
+      text: "Clusters span providers: AWS primary, GCP disaster recovery, Azure edge, on-premises for sensitive workloads. Application manifests and security policies stay consistent, but cloud-specific integrations (load balancers, storage classes, IAM bindings) differ by necessity.",
     },
   ]}
 />
 
 <Diagram
   src={multiClusterDiagram}
+  size="full"
   title="Multi-cluster topology patterns."
   description="Flowchart showing three common multi-cluster topology patterns. In the first grouped section, labeled Environment-Based, a Git Repository points to three clusters: dev-cluster, staging-cluster, and prod-cluster. In the second grouped section, labeled Regional, a Git Repository points to four regional clusters: us-east, us-west, eu-west, and ap-southeast. In the third grouped section, labeled Hybrid, a Git Repository points to four infrastructure targets: AWS, GCP, Azure, and On-Prem. The diagram emphasizes that the same GitOps source model can support different organizational reasons for multi-cluster deployment: separate environments, geographic regions, or mixed cloud and on-premises platforms."
 />
@@ -78,7 +79,7 @@ Organizations arrive at multi-cluster architectures for different reasons, and t
 Every multi-cluster strategy sits somewhere on a spectrum from "all clusters are identical" to "each cluster is independent." Neither extreme works well in practice.
 
 <List
-  variant="check-icons-list"
+  variant="numbered-with-background-list"
   items={[
     {
       lead: "Fully consistent",
@@ -104,8 +105,10 @@ Every multi-cluster strategy sits somewhere on a spectrum from "all clusters are
 [^kyverno]: Kyverno is a Kubernetes-native policy engine. Unlike Gatekeeper, it doesn't require learning Rego; policies are written in standard YAML. It can validate, mutate (modify), and generate resources, as well as verify container image signatures.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
+    figure: "Consistency vs flexibility tradeoffs.",
     thead: {
       th: ["Approach", "Consistency", "Flexibility", "Operational Overhead", "Best For"],
     },
@@ -129,7 +132,6 @@ Every multi-cluster strategy sits somewhere on a spectrum from "all clusters are
         },
       ],
     },
-    figure: "Consistency vs flexibility tradeoffs.",
   }}
 />
 
@@ -144,33 +146,37 @@ The fleet management landscape has matured around a few dominant approaches. All
 ### Tool Comparison
 
 <List
-  variant="check-icons-list"
+  variant="chevron-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
       lead: "ArgoCD ApplicationSets",
-      text: "extend ArgoCD's Application concept with generators that create Applications dynamically based on clusters, Git directories, or custom lists. If you're already running ArgoCD, ApplicationSets are the natural choice. The generator patterns (cluster, list, git, matrix, merge) handle most multi-cluster scenarios elegantly. The limitation is scale: beyond 500 clusters, the ApplicationSet controller can struggle, and you'll need sharding or multiple ArgoCD instances.",
+      text: "Extends ArgoCD's Application concept with generators that create Applications dynamically based on clusters, Git directories, or custom lists. If you're already running ArgoCD, ApplicationSets are the natural choice. The generator patterns (cluster, list, git, matrix, merge) handle most multi-cluster scenarios elegantly. The limitation is scale: beyond 500 clusters, the ApplicationSet controller can struggle, and you'll need sharding or multiple ArgoCD instances.",
     },
     {
       lead: "Flux",
-      text: "takes a different approach, building multi-cluster support into its Kustomization hierarchy. Each cluster runs its own Flux controllers pulling from Git, with dependencies between Kustomizations enabling layered configuration. Flux excels at lightweight, distributed deployments where each cluster is fairly autonomous. The trade-off is less centralized visibility — there's no built-in UI showing fleet-wide status.",
+      text: "Takes a different approach, building multi-cluster support into its Kustomization hierarchy. Each cluster runs its own Flux controllers pulling from Git, with dependencies between Kustomizations enabling layered configuration. Flux excels at lightweight, distributed deployments where each cluster is fairly autonomous. The trade-off is less centralized visibility — there's no built-in UI showing fleet-wide status.",
     },
     {
       lead: "Rancher Fleet",
-      text: `provides centralized multi-cluster GitOps with a strong UI for fleet visibility. The "bundle" concept groups related resources for deployment across cluster groups. It's pull-based (clusters pull their configs), but the Rancher UI gives operators a single pane of glass. The downside is ecosystem lock-in — Fleet integrates deeply with Rancher's cluster management.`,
+      text: "Provides centralized multi-cluster GitOps with a strong UI for fleet visibility. The \"bundle\" concept groups related resources for deployment across cluster groups. It's pull-based (clusters pull their configs), but the Rancher UI gives operators a single pane of glass. The downside is ecosystem lock-in — Fleet integrates deeply with Rancher's cluster management.",
     },
     {
-      lead: "Google Config Sync",
-      text: "(part of Anthos) offers deep GKE integration with built-in policy controller and namespace hierarchy management. If your fleet is GKE-centric, Config Sync provides tight integration with Google Cloud's IAM and audit logging. For multi-cloud or on-prem clusters, it's less flexible.",
+      lead: "Google Config Sync (part of Anthos)",
+      text: "Offers deep GKE integration with built-in policy controller and namespace hierarchy management. If your fleet is GKE-centric, Config Sync provides tight integration with Google Cloud's IAM and audit logging. For multi-cloud or on-prem clusters, it's less flexible.",
     },
     {
       lead: "Crossplane",
-      text: "approaches fleet management differently — as a Kubernetes-native control plane extension for both infrastructure and configuration. You define Compositions that abstract cluster provisioning and configuration together. This is powerful for platform teams building internal developer platforms, but the learning curve is steep.",
+      text: "Approaches fleet management differently — as a Kubernetes-native control plane extension for both infrastructure and configuration. You define Compositions that abstract cluster provisioning and configuration together. This is powerful for platform teams building internal developer platforms, but the learning curve is steep.",
     },
   ]}
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="report-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ["Tool", "Model", "Best For", "Scale Ceiling", "Learning Curve"],
@@ -357,30 +363,71 @@ Code: Flux Kustomization hierarchy with base, overlay, and cluster-specific laye
 
 The repository structure mirrors the Kustomization hierarchy. Base configurations define the canonical resources. Environment overlays patch those resources for dev/staging/production. Cluster-specific directories handle the last-mile customization — things like cluster-specific ingress hostnames or region-specific resource limits. The `postBuild.substituteFrom` feature lets you inject cluster-specific values from ConfigMaps or Secrets at reconciliation time, avoiding the need to duplicate paths for every cluster.
 
-```text
-platform-config/
-├── base/
-│   └── platform/
-│       ├── kustomization.yaml
-│       ├── namespace.yaml
-│       ├── deployment.yaml
-│       └── service.yaml
-├── overlays/
-│   ├── development/
-│   ├── staging/
-│   └── production/
-│       └── kustomization.yaml
-└── clusters/
-    ├── us-east-prod/
-    ├── us-west-prod/
-    └── eu-west-prod/
-        └── kustomization.yaml
-```
-
-Figure: Repository structure for Flux multi-cluster configuration.
+<FileExplorer
+  fullWidth={false}
+  classes={{
+    wrapper: "sm:ml-24 sm:mr-24 mb-6",
+  }}
+  figure="Repository structure for Flux multi-cluster configuration."
+  data={[
+    {
+      type: 'folder',
+      name: 'platform-config',
+      children: [
+        {
+          type: 'folder',
+          name: 'base',
+          children: [
+            {
+              type: 'folder',
+              name: 'platform',
+              children: [
+                { type: 'file', name: 'kustomization.yaml', comment: 'Assembles shared platform manifests' },
+                { type: 'file', name: 'namespace.yaml', comment: 'Creates shared target namespace' },
+                { type: 'file', name: 'deployment.yaml', comment: 'Defines platform service deployment' },
+                { type: 'file', name: 'service.yaml', comment: 'Exposes platform service internally' },
+              ],
+            },
+          ],
+        },
+        {
+          type: 'folder',
+          name: 'overlays',
+          children: [
+            { type: 'folder', name: 'development' },
+            { type: 'folder', name: 'staging' },
+            {
+              type: 'folder',
+              name: 'production',
+              children: [
+                { type: 'file', name: 'kustomization.yaml', comment: 'Applies production-specific overrides' },
+              ],
+            },
+          ],
+        },
+        {
+          type: 'folder',
+          name: 'clusters',
+          children: [
+            { type: 'folder', name: 'us-east-prod' },
+            { type: 'folder', name: 'us-west-prod' },
+            {
+              type: 'folder',
+              name: 'eu-west-prod',
+              children: [
+                { type: 'file', name: 'kustomization.yaml', comment: 'Sets cluster-specific resources' },
+              ],
+            },
+          ],
+        },
+      ],
+    },
+  ]}
+/>
 
 <Diagram
   src={argocdDiagram}
+  size="full"
   title="ArgoCD generates Applications centrally - Flux controllers pull independently."
   description="Flowchart comparing the ArgoCD and Flux multi-cluster operating models. In the grouped section labeled ArgoCD Model, ApplicationSet points to Generator, which then fans out to Cluster 1 App, Cluster 2 App, and Cluster 3 App. Each of those generated applications points to a corresponding cluster: Cluster 1, Cluster 2, and Cluster 3. In the grouped section labeled Flux Model, a shared Git Repository points directly to Cluster 1 Flux, Cluster 2 Flux, and Cluster 3 Flux. Each cluster-specific Flux controller then points to its own layered configuration composed of base plus overlay plus cluster-specific settings. The diagram highlights that ArgoCD centralizes application generation before deployment, while Flux distributes reconciliation to controllers running inside each cluster, all pulling from the same repository."
 />
@@ -391,7 +438,7 @@ ArgoCD ApplicationSets excel at generating many similar applications with cluste
 
 ## Configuration Templating
 
-Once you've chosen a fleet management tool, the next decision is how to generate cluster-specific configurations from shared definitions. The fleet tool handles __where__ configs deploy; the templating strategy handles __what__ varies between clusters.
+Once you've chosen a fleet management tool, the next decision is how to generate cluster-specific configurations from shared definitions. The fleet tool handles _where_ configs deploy; the templating strategy handles _what_ varies between clusters.
 
 The two dominant approaches are Kustomize (patch-based) and Helm (template-based), though alternatives like Jsonnet[^jsonnet] and CUE[^cue] exist for organizations with more complex needs.
 
@@ -401,6 +448,7 @@ The two dominant approaches are Kustomize (patch-based) and Helm (template-based
 
 <Diagram
   src={configurationLayeringDiagram}
+  size="full"
   title="Configuration layering from fleet-wide to cluster-specific."
   description="Flowchart showing a three-layer configuration model for multi-cluster fleets. Inside a grouped section labeled Configuration Layering, Base Config points to Security policies, Monitoring stack, and Core add-ons. Environment Overlay points to Replica counts, Resource limits, and Feature flags. Cluster-Specific points to Regional endpoints, Cloud integrations, and Compliance settings. Outside those branch relationships, Base Config points to Environment Overlay, and Environment Overlay points to Cluster-Specific, showing that the layers build on one another from shared fleet-wide defaults to environment-level overrides and finally to per-cluster customization. The diagram illustrates how organizations can preserve consistency while still allowing necessary differences between environments and individual clusters."
 />
@@ -426,6 +474,8 @@ commonLabels:
 
 Code: Base kustomization with shared resources.
 
+The production overlay references the base and layers on deployment-specific settings — replica counts, pinned image tags, resource requests and limits, and merged ConfigMap values. Kustomize's `patches` field uses JSON Patch operations to surgically modify individual fields without rewriting the entire manifest.
+
 ```yaml title="kustomize-production-overlay.yaml"
 # Production overlay (overlays/production/kustomization.yaml)
 apiVersion: kustomize.config.k8s.io/v1beta1
@@ -463,6 +513,8 @@ configMapGenerator:
 
 Code: Production overlay with resource limits and config.
 
+The final layer targets a specific cluster. It references the production overlay and adds region-aware patches — injecting the correct database endpoint and constraining pod scheduling to the matching availability zone via `nodeSelector`.
+
 ```yaml title="kustomize-cluster-overlay.yaml"
 # Cluster-specific (clusters/us-east-prod/kustomization.yaml)
 apiVersion: kustomize.config.k8s.io/v1beta1
@@ -516,6 +568,8 @@ config:
 
 Code: Base Helm values for all environments.
 
+The production values file overrides the base defaults with deployment-grade settings — higher replica counts, a pinned image tag, explicit resource limits, and a PodDisruptionBudget to maintain availability during rolling updates.
+
 ```yaml title="helm-production-values.yaml"
 # Production values (values/production.yaml)
 replicaCount: 5
@@ -539,6 +593,8 @@ podDisruptionBudget:
 
 Code: Production values with higher resources and PDB.
 
+The cluster-specific file adds the final layer of customization — scaling replicas for a high-traffic region, wiring in the regional database endpoint, and using `nodeSelector` and `tolerations` to pin workloads to dedicated node pools.
+
 ```yaml title="helm-cluster-values.yaml"
 # Cluster-specific values (values/clusters/us-east-prod.yaml)
 replicaCount: 8  # Higher traffic region
@@ -556,7 +612,7 @@ tolerations:
 
 Code: Cluster-specific values for high-traffic region.
 
-Helmfile orchestrates this layering, merging values files in order and injecting environment variables for cluster-specific paths:
+Helmfile orchestrates this layering, merging values files in order and injecting environment variables for cluster-specific paths.
 
 ```yaml title="helmfile.yaml"
 environments:
@@ -582,8 +638,10 @@ releases:
 
 Code: Helmfile for multi-cluster deployment orchestration.
 
+The key thing to get right with layered values is merge order. Helm performs a shallow merge by default, so nested maps in a later values file replace — rather than merge with — the same key from an earlier file. If your base defines `resources.requests.cpu` and a cluster file only sets `resources.requests.memory`, you lose the CPU request entirely. Use Helmfile's `mergeStrategy: strategic` or restructure values to keep overrides at leaf keys to avoid silent misconfigurations that only surface under load.
+
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
   content={{
     thead: {
       th: ['Approach', 'Pros', 'Cons', 'Best For'],
@@ -905,7 +963,8 @@ The key principles are:
 />
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="criteria-highlight-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Operation Type', 'Strategy', 'Verification', 'Rollback'],
@@ -940,7 +999,7 @@ Progressive rollout is essential for production fleet operations. Start with a c
 
 ## Conclusion
 
-The shift from Kubernetes Federation to GitOps-based fleet management reflects a fundamental insight: multi-cluster consistency isn't about making clusters identical, it's about making differences __intentional and documented__. Federation failed because it tried to abstract away cluster variations. Modern fleet tools succeed because they embrace variations while providing guardrails.
+The shift from Kubernetes Federation to GitOps-based fleet management reflects a fundamental insight: multi-cluster consistency isn't about making clusters identical, it's about making differences _intentional_ and _documented_. Federation failed because it tried to abstract away cluster variations. Modern fleet tools succeed because they embrace variations while providing guardrails.
 
 The practical path forward has four components. First, document your fleet topology explicitly — which clusters exist, what each serves, what should be shared versus different. This documentation becomes the foundation for your templating strategy, whether you choose Kustomize overlays or Helm values hierarchies.
 
@@ -950,8 +1009,8 @@ Third, implement drift detection from day one, before clusters have had time to
 
 Finally, treat fleet-wide changes as first-class operations with their own patterns: progressive rollout through canary clusters, automated verification between waves, and clear rollback procedures. The overhead of wave-based deployment pays for itself the first time it catches a bad change before it reaches your primary production clusters.
 
-One area this article hasn't covered in depth is secrets management across clusters — synchronizing credentials, certificates, and API keys while maintaining proper access controls. Tools like External Secrets Operator, Sealed Secrets, and HashiCorp Vault each solve this differently. That's a topic for its own deep dive.
-
 <Callout type="info">
 Fleet management maturity is measured by how confidently you can answer: "What's different between these clusters, and is that difference intentional?" If you can't answer quickly, start with documentation. Tools amplify good processes; they can't substitute for them.
 </Callout>
+
+One area this article hasn't covered in depth is secrets management across clusters — synchronizing credentials, certificates, and API keys while maintaining proper access controls. Tools like External Secrets Operator, Sealed Secrets, and HashiCorp Vault each solve this differently. That's a topic for its own deep dive.