@@ -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.')
+    })
+  })
 })
@@ -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>
 
@@ -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.