@@ -343,5 +343,5 @@ https://mermaid.js.org/config/directives.html
   fullWidth={false}
   classes={{
     tbody:
-      '[&_td:nth-child(2)]:text-green [&_td:nth-child(3)]:text-warning [&_td:nth-child(4)]:text-danger',
+      '[&_td:nth-child(2)]:text-success [&_td:nth-child(3)]:text-warning [&_td:nth-child(4)]:text-danger',
   }}
@@ -22,18 +22,22 @@ A team enables Istio mTLS across their 50-service mesh. Initial rollout goes smo
 
 Recovery takes four hours because the on-call engineer has never manually rotated Istio certificates and the runbook doesn't exist yet.
 
-If this sounds familiar, you're not alone. Enabling mTLS is a configuration change; operating it reliably is an ongoing commitment to understanding certificate lifecycles, building automation for rotation, and monitoring for expiration failures.
+If this sounds familiar, you're not alone. <Highlighter>Enabling mTLS is a configuration change; operating it reliably is an ongoing commitment to understanding certificate lifecycles, building automation for rotation, and monitoring for expiration failures.</Highlighter>
 
 ## The Operational Reality of mTLS
 
 Standard TLS — what you use when visiting any HTTPS website — is a one-way trust relationship. The server proves its identity to the client by presenting a certificate. The client validates that certificate against its trust store. The server has no idea who the client is at the transport layer.
 
 Mutual TLS adds a second handshake step: after the client validates the server's certificate, the server requests and validates a certificate from the client. Both parties cryptographically prove their identity before any application data flows.
 
-The operational cost difference is significant. With standard TLS, you manage certificates for servers — maybe dozens or hundreds. With mTLS, __every__ service needs a certificate, and every service needs to validate certificates from every other service it communicates with. In a 100-service mesh, that's potentially thousands of certificate validation paths to maintain.
+The operational cost difference is significant. With standard TLS, you manage certificates for servers — maybe dozens or hundreds. With mTLS, _every_ service needs a certificate, and every service needs to validate certificates from every other service it communicates with. In a 100-service mesh, that's potentially thousands of certificate validation paths to maintain.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     thead: {
       th: ['Aspect', 'Standard TLS', 'Mutual TLS'],
@@ -79,22 +83,25 @@ __CA rotation__ is harder. When you rotate an intermediate or root CA, you're ch
 The safe order for CA rotation:
 
 <List
-  variant="numbered-with-background-list"
+  variant="timeline-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-12 mb-6",
+  }}
   items={[
     {
-      text: 'Add the new CA to all trust bundles (services now trust both old and new)',
+      lead: 'Add the new CA to all trust bundles (services now trust both old and new)',
     },
     {
-      text: 'Verify all services have received the updated trust bundle',
+      lead: 'Verify all services have received the updated trust bundle',
     },
     {
-      text: 'Start issuing certificates from the new CA',
+      lead: 'Start issuing certificates from the new CA',
     },
     {
-      text: 'Wait for all workload certificates to rotate to the new CA',
+      lead: 'Wait for all workload certificates to rotate to the new CA',
     },
     {
-      text: 'Remove the old CA from trust bundles',
+      lead: 'Remove the old CA from trust bundles',
     },
   ]}
 />
@@ -103,6 +110,7 @@ This sequence diagram shows the rotation flow:
 
 <Diagram
   src={caRotationDiagram}
+  size="full"
   title="CA rotation sequence showing the safe order of operations."
   description="Sequence diagram with three participants: Workload, Certificate Authority, and Trust Store. The first phase is Step 1, Add New CA to Trust. The Certificate Authority sends a new CA certificate to the Trust Store, and the Trust Store updates the Workload with a trust bundle that includes both the old and new CA. The second phase is Step 2, Verify Distribution, where the Workload confirms it has received the new trust bundle. The third phase is Step 3, Issue New Certs, where the Workload sends a CSR for a new certificate to the Certificate Authority, and the Certificate Authority returns a certificate signed by the new CA. The fourth phase is Step 4, Verify Full Rotation, where the Workload asks the Certificate Authority whether any certificates signed by the old CA remain, and the response is that none remain. The fifth phase is Step 5, Remove Old CA, where the Trust Store removes the old CA and the Workload receives an updated trust bundle containing only the new CA. The diagram emphasizes that trust must be updated before new certificates are issued, and the old CA must only be removed after all workloads have rotated."
 />
@@ -146,7 +154,8 @@ groups:
 Different certificate levels need different alert thresholds:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="numbered-review-table"
+  fullWidth={false}
   content={{
     thead: {
       th: ['Certificate Type', 'Typical TTL', 'Warning', 'Critical'],
@@ -184,31 +193,35 @@ mTLS failures produce cryptic errors. The TLS handshake fails, and you get a gen
 ### Common Failure Modes
 
 <List
-  variant="check-icons-list"
+  variant="zebra-list"
   items={[
     {
       lead: 'Certificate expired',
-      text: 'The most common cause of mTLS outages. Error messages include `x509: certificate has expired`. Check expiration with `openssl x509 -enddate -noout -in cert.pem`. Fix by forcing rotation or restarting the workload to trigger certificate renewal.',
+      text: 'The most common cause of mTLS outages. Error messages include <span class="font-mono">x509: certificate has expired</span>. Check expiration with <span class="font-mono">openssl x509 -enddate -noout -in cert.pem</span>. Fix by forcing rotation or restarting the workload to trigger certificate renewal.',
     },
     {
       lead: 'Trust chain broken',
-      text: 'The certificate is valid but the CA that signed it isn\'t in the trust store. You\'ll see `x509: certificate signed by unknown authority`. This happens during CA rotation if trust bundles aren\'t updated before new certificates are issued.',
+      text: 'The certificate is valid but the CA that signed it isn\'t in the trust store. You\'ll see <span class="font-mono">x509: certificate signed by unknown authority</span>. This happens during CA rotation if trust bundles aren\'t updated before new certificates are issued.',
     },
     {
       lead: 'SAN mismatch',
-      text: 'The certificate is valid but doesn\'t include the hostname being used. Error: `x509: certificate is valid for X, not Y`. This commonly happens when DNS names change or when certificates are issued with incomplete SAN lists.',
+      text: 'The certificate is valid but doesn\'t include the hostname being used. Error: <span class="font-mono">x509: certificate is valid for X, not Y</span>. This commonly happens when DNS names change or when certificates are issued with incomplete SAN lists.',
     },
     {
       lead: 'Wrong key usage',
-      text: 'The certificate exists but wasn\'t issued for mTLS. If it only has `serverAuth` in Extended Key Usage, it can\'t be used as a client certificate. Reissue with both `serverAuth` and `clientAuth`.',
+      text: 'The certificate exists but wasn\'t issued for mTLS. If it only has <span class="font-mono">serverAuth</span> in Extended Key Usage, it can\'t be used as a client certificate. Reissue with both <span class="font-mono">serverAuth</span> and <span class="font-mono">clientAuth</span>.',
     },
   ]}
 />
 
 I once spent two hours debugging a "connection reset by peer" that turned out to be a certificate with `serverAuth` only — no `clientAuth`. The error message mentioned nothing about key usage. The fix was a one-line change to the certificate spec, but finding it required systematically ruling out every other possibility.
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: '!text-content',
+  }}
   content={{
     thead: {
       th: ['Symptom', 'Likely Cause', 'First Check'],