@@ -8,7 +8,7 @@ export interface Props {
   /** The image source for the diagram */
   src?: ImageSource | undefined
   /** The desktop preview max width token for the diagram image */
-  size?: '3xl' | '2xl' | 'xl' | 'lg' | 'md' | 'sm' | 'xs' | undefined
+  size?: 'full' | '3xl' | '2xl' | 'xl' | 'lg' | 'md' | 'sm' | 'xs' | undefined
   /** The magnify button corner for the preview image */
   magnifyButtonPosition?: 'top-right' | 'bottom-right' | 'top-left' | 'bottom-left' | undefined
   /** The title of the diagram */
@@ -18,8 +18,9 @@ export interface Props {
 }
 
 const { src, title, description, magnifyButtonPosition = 'top-right', size } = Astro.props as Props
+const imageVariant = size === 'full' ? 'full' : 'center'
 const imageProps = {
-  ...(typeof size !== 'undefined' ? { size } : {}),
+  ...(typeof size !== 'undefined' && size !== 'full' ? { size } : {}),
   ...(typeof magnifyButtonPosition !== 'undefined' ? { magnifyButtonPosition } : {}),
 }
 const hasDefaultSlot = Astro.slots.has('default')
@@ -30,7 +31,7 @@ const hasDefaultSlot = Astro.slots.has('default')
     <Image
       src={src}
       alt={title}
-      variant="center"
+      variant={imageVariant}
       {...imageProps}
     />
   )}
 
@@ -68,4 +68,40 @@ describe('List (Astro)', () => {
       })
     ).rejects.toThrow('ChatBubbles: invalid size "3xl". Expected one of: lg, xl, 2xl.')
   })
+
+  test('starts numbering at the provided startNumber and applies the provided color for the numbered-with-background-list variant', async () => {
+    const List = (await import('@components/List/index.astro')).default
+
+    const renderedHtml = await container.renderToString(List, {
+      props: {
+        variant: 'numbered-with-background-list',
+        color: 'info',
+        startNumber: 4,
+        items: [
+          {
+            lead: 'Step one',
+            text: 'First item.',
+          },
+          {
+            lead: 'Step two',
+            text: 'Second item.',
+          },
+        ],
+      },
+    })
+
+    await withJsdomEnvironment(async ({ window }) => {
+      window.document.body.innerHTML = renderedHtml
+
+      const badges = Array.from(window.document.querySelectorAll('li > span:first-child'))
+      const leads = Array.from(window.document.querySelectorAll('li em'))
+
+      expect(badges).toHaveLength(2)
+      expect(leads).toHaveLength(2)
+      expect(badges[0]?.textContent?.trim()).toBe('4')
+      expect(badges[1]?.textContent?.trim()).toBe('5')
+      expect(badges[0]?.className).toContain('bg-info')
+      expect(leads[0]?.className).toContain('text-info')
+    })
+  })
 })
@@ -39,14 +39,18 @@ export type Props = {
     wrapper?: string
   }
   size?: number | 'lg' | 'xl' | '2xl'
+  color?: string
+  startNumber?: number
   variant: string
   style?: Record<string, unknown>
 }
 
-const { items, size, variant = 'default', classes, style } = Astro.props
+const { items, size, color, startNumber, variant = 'default', classes, style } = Astro.props
 const classesProps = classes ? { classes } : {}
 const numericSizeProps = typeof size === 'number' ? { size } : {}
 const chatBubbleSizeProps = typeof size === 'string' ? { size } : {}
+const colorProps = typeof color === 'string' && color.trim().length > 0 ? { color } : {}
+const startNumberProps = typeof startNumber === 'number' ? { startNumber } : {}
 const styleProps = style ? { style } : {}
 const itemsWithColor = items as Array<{
   title?: string
@@ -77,7 +81,7 @@ const plainIconItems = items.filter((item): item is Props['items'][number] & { i
   {variant === 'check-icons-list' && <CheckIconsList items={items} {...classesProps} {...styleProps} />}
   {variant === 'chevron-list' && <ChevronList items={items} {...classesProps} {...styleProps} />}
   {variant === 'colored-marker-list' && <ColoredMarkerList items={itemsWithColor} {...classesProps} {...numericSizeProps} {...styleProps} />}
-  {variant === 'numbered-with-background-list' && <NumberedWithBackgroundList items={items} {...classesProps} {...styleProps} />}
+  {variant === 'numbered-with-background-list' && <NumberedWithBackgroundList items={items} {...classesProps} {...colorProps} {...startNumberProps} {...styleProps} />}
   {variant === 'plain-icon-list' && <PlainIconList items={plainIconItems} {...classesProps} {...numericSizeProps} {...styleProps} />}
   {variant === 'side-by-side-list' && <SideBySideList items={items} {...classesProps} {...styleProps} />}
   {variant === 'timeline-list' && <TimelineList items={items} {...classesProps} {...styleProps} />}
 
@@ -4,25 +4,29 @@ export type Props = {
     lead?: string
     text: string
   }[]
+  color?: string
+  startNumber?: number
   classes?: {
     ol?: string
     li?: string
     em?: string
   }
 }
 
-const { items, classes }: Props = Astro.props
+const { items, classes, color, startNumber = 1 }: Props = Astro.props
+const resolvedColor = typeof color === 'string' && color.trim().length > 0 ? color.trim() : 'primary-offset'
+const pillColorClass = `bg-${resolvedColor}`
 
 const olClass = ["space-y-3", classes?.ol]
 const liClass = ["flex items-start gap-4 bg-page-offset/50 rounded-lg p-4", classes?.li]
-const emClass = ["text-primary-offset font-semibold not-italic", classes?.em]
+const emClass = [`text-${resolvedColor}`, "font-semibold not-italic", classes?.em]
 ---
 
 <ol class:list={olClass}>
   {
     items.map((item, index) => (
       <li class:list={liClass}>
-        <span class="mt-2 shrink-0 w-8 h-8 bg-primary-offset text-content-inverse rounded-full flex items-center justify-center text-sm font-bold">{index + 1}</span>
+        <span class:list={["mt-2 shrink-0 w-8 h-8 text-content-inverse rounded-full flex items-center justify-center text-sm font-bold", pillColorClass]}>{startNumber + index}</span>
         <div class="pt-1">
           {item.lead && <em class:list={emClass} set:html={item.lead}></em>}
           <div set:html={item.text}></div>
 
@@ -21,14 +21,28 @@ Here's the uncomfortable truth most deployment strategy comparisons skip: the "b
 
 Before we dive into the database problem, let's establish baseline understanding of what these strategies actually do.
 
-__Blue/green deployment__ maintains two identical production environments. Blue runs your current version. When you're ready to release, you deploy to green, test it thoroughly, then switch all traffic at once. If something breaks, you switch back to blue.
-
-__Canary deployment__ takes the opposite approach. Instead of switching everyone simultaneously, you route a small percentage of traffic — say, 5%—to the new version. You watch metrics, gradually increase the percentage, and only complete the rollout once you're confident the new version is healthy.
+<List
+  variant="zebra-list"
+  items={[
+    {
+      lead: "Blue/green deployment",
+      text: "Maintains two identical production environments. Blue runs your current version. When you're ready to release, you deploy to green, test it thoroughly, then switch all traffic at once. If something breaks, you switch back to blue.",
+    },
+    {
+      lead: "Canary deployment",
+      text: "Takes the opposite approach. Instead of switching everyone simultaneously, you route a small percentage of traffic — say, 5% — to the new version. You watch metrics, gradually increase the percentage, and only complete the rollout once you're confident the new version is healthy.",
+    },
+  ]}
+/>
 
 The fundamental difference comes down to exposure:
 
 <Table
-  variant="vertical-column-delineation-table"
+  variant="grid-and-accent-header-table"
+  fullWidth={false}
+  classes={{
+    tbody: "[&_td:last-child]:text-content",
+  }}
   content={{
     figure: "Strategy comparison",
     thead: { th: ["Aspect", "Blue/Green", "Canary"] },
@@ -80,7 +94,10 @@ Adding a required column breaks old code that can't provide values. Removing a c
 The solution is to __never__ deploy schema changes and code changes together. Instead, use a multi-phase approach:
 
 <List
-  variant="check-icons-list"
+  variant="side-by-side-list"
+  classes={{
+    wrapper: "sm:ml-6 sm:mr-18 mb-6",
+  }}
   items={[
     {
       lead: "Phase 1 (Expand):",
@@ -97,9 +114,6 @@ The solution is to __never__ deploy schema changes and code changes together. In
   ]}
 />
 
-
-<Newsletter />
-
 This pattern works with both strategies, but it's __mandatory__ for canary deployments. Blue/green can sometimes shortcut this with careful timing and instant cutover, but you're accepting more risk.
 
 ```sql
@@ -121,12 +135,14 @@ The teams that struggle with deployment strategies are usually the ones trying t
 
 Now that we've established database compatibility as the primary constraint, the decision framework becomes clearer. Here's how to choose.
 
-### Choose Blue/Green When
+### Choose Blue / Green When
 
 Your deployments frequently include database migrations that can't easily follow expand-contract patterns. Legacy systems with tightly coupled schemas often fall into this category.
 
 You need instant, complete rollback. Blue/green's traffic switch is as close to "undo" as deployments get. If your downtime tolerance is measured in seconds rather than minutes, this matters.
 
+<Newsletter />
+
 Your team is smaller or less experienced with progressive delivery. Blue/green is conceptually simpler: deploy, test, switch. There's less tooling to maintain and fewer operational scenarios to train for.
 
 You can afford the infrastructure cost. Running two complete environments doubles your compute costs during deployments. For many organizations, this is acceptable for the operational simplicity it provides.
@@ -151,6 +167,10 @@ Many mature organizations don't choose one strategy — they use both. Schema mi
 
 The key insight is that the database constraint drives the decision __per deployment__, not as a blanket policy. A team might deploy three canary releases in a row, then switch to blue/green for a migration, then back to canary. The tooling supports both; the deployment contents determine which to use.
 
+## Conclusion
+
+The deployment strategy debate often focuses on the wrong things — rollback speed, blast radius, tooling sophistication. These matter, but they're secondary to the fundamental question: what are you actually deploying?
+
 <Download
   resource="blue-green-canary-deployment-strategy-comparison"
   title="Download the Deployment Strategies Guide"
@@ -171,10 +191,6 @@ The key insight is that the database constraint drives the decision __per deploy
   ]}
 />
 
-## Conclusion
-
-The deployment strategy debate often focuses on the wrong things — rollback speed, blast radius, tooling sophistication. These matter, but they're secondary to the fundamental question: what are you actually deploying?
-
 For database schema changes, blue/green's instant cutover is often the only safe option. For application logic changes, canary's gradual rollout provides better production validation with limited risk. Most real-world systems need both approaches, selected based on what each specific deployment contains.
 
 The best deployment strategy isn't the most technically impressive one. It's the one your team can operate reliably, that matches your database change patterns, and that you'll actually use consistently. Start with the simpler option that works for your constraints, and add sophistication only when you have specific problems that require it.