@@ -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,15 +296,15 @@ 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"
   classes={{
     titleClass: "block w-full text-center",
   }}
 
-### Spacing out the boxes:
+#### Spacing out the boxes:
 
 <List
   variant="zebra-list"
 
@@ -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: {