import { CopyBlock } from '~/chrome/ui/copy';
/*
 * `Paragraph` and `SubHeading` are aliased back to the one-letter names this
 * document reads best with — `<P>` appears 55 times in a page that is prose.
 * `ProseTable` is not aliased on purpose: `Table` is the name `chrome/ui/tables.tsx`
 * exports, and shortening it here is how a future import of that one becomes a
 * collision.
 */
import { Finding, Hex, Paragraph as P, ProseTable, SubHeading as H3 } from '~/chrome/ui/prose';
import { useMessages } from '../i18n';
import { Link } from '../router';

/**
 * The narrative half of Figma parity: what was found, the evidence, and which
 * side has to move.
 *
 * Ported from `docs/FigmaParity.mdx` when Storybook became optional. It is
 * deliberately separate from `parity.tsx`, which is generated from
 * `figma-spec.json` — that page tells you *where* the two disagree, this one
 * tells you *why* and what to do about it. A finding only lands here once
 * somebody has resolved it against the variable table.
 *
 * Kept in English, unlike the rest of the site: it is an audit record aimed at
 * whoever is holding the Figma file open, and it is mostly node ids, hex values
 * and variable paths — none of which translate. The tab says so.
 */

export function ParityFindings() {
  const m = useMessages();

  return (
    <div className="space-y-8">
      <header className="space-y-3">
        <P>
          <strong className="text-foreground">File:</strong> CBAR - Design System (Copy) ·{' '}
          <strong className="text-foreground">Date:</strong> 2026-08-02, §7 added 2026-08-06 ·{' '}
          <strong className="text-foreground">Method:</strong> the local bridge plugin (
          <code>figma_variables</code>, <code>figma_node</code>, <code>figma_css</code>), read live
          — no REST, no cached export.
        </P>
        <P>
          Discrepancies found between CBAR&rsquo;s Figma file and this kit, with the evidence for
          each and which side has to change. They are written down rather than fixed in passing
          because every one of them is a decision for the design file, not for the code.
        </P>
        <p className="max-w-prose text-xs text-muted-foreground italic">
          {m.parity.findingsEnglishOnly}
        </p>
      </header>

      <Finding
        n={1}
        title="Button and avatar: colorPalette=primary and secondary are crossed"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> high — Button is the most used
            component in the set, and the same wiring turned up in a second one.{' '}
            <strong className="text-foreground">Where:</strong> component sets <code>Button</code>{' '}
            (node <code>2446:6959</code>, page &ldquo;Button&rdquo;) and <code>avatar</code> (node{' '}
            <code>2446:757</code>, page &ldquo;Avatar&rdquo;).{' '}
            <strong className="text-foreground">Who is wrong:</strong> Figma. This kit is correct
            and must not be changed.
          </>
        }
      >
        <H3>What renders — Button</H3>
        <P>
          Every <code>colorPalette=primary</code> variant of Button paints with the{' '}
          <em>secondary</em> (turquoise) role, and every <code>colorPalette=secondary</code> variant
          paints with the <em>primary</em> (navy) role. It holds across all five treatments, not
          just <code>solid</code>:
        </P>
        <ProseTable
          head={['variant', 'palette', 'bound variable', 'colour', 'should be']}
          rows={[
            [
              <code key="v">solid</code>,
              <strong key="p">primary</strong>,
              <code key="b">surface/colored/secondary</code>,
              <Hex key="c" value="#4BC7B5" />,
              <code key="s">surface/colored/primary</code>,
            ],
            [
              <code key="v">solid</code>,
              <strong key="p">secondary</strong>,
              <code key="b">surface/colored/primary</code>,
              <Hex key="c" value="#004976" />,
              <code key="s">surface/colored/secondary</code>,
            ],
            [
              <code key="v">subtle</code>,
              <strong key="p">primary</strong>,
              <code key="b">surface/subtle/secondary</code>,
              <Hex key="c" value="#CFF3EC" />,
              <code key="s">surface/subtle/primary</code>,
            ],
            [
              <code key="v">subtle</code>,
              <strong key="p">secondary</strong>,
              <code key="b">surface/subtle/primary</code>,
              <Hex key="c" value="#D6EAF4" />,
              <code key="s">surface/subtle/secondary</code>,
            ],
            [
              <code key="v">outline</code>,
              <strong key="p">primary</strong>,
              <code key="b">border/colored/secondary</code>,
              <Hex key="c" value="#A6E8DA" />,
              <code key="s">border/colored/primary</code>,
            ],
            [
              <code key="v">outline</code>,
              <strong key="p">secondary</strong>,
              <code key="b">border/colored/primary</code>,
              <Hex key="c" value="#7FBBD9" />,
              <code key="s">border/colored/secondary</code>,
            ],
            [
              <code key="v">surface</code>,
              <strong key="p">primary</strong>,
              <code key="b">surface/subtle/secondary + border/colored/secondary</code>,
              <span key="c" className="flex flex-wrap gap-2">
                <Hex value="#CFF3EC" />
                <Hex value="#A6E8DA" />
              </span>,
              <span key="s">
                both <code>…/primary</code>
              </span>,
            ],
            [
              <code key="v">surface</code>,
              <strong key="p">secondary</strong>,
              <code key="b">surface/subtle/primary + border/colored/primary</code>,
              <span key="c" className="flex flex-wrap gap-2">
                <Hex value="#D6EAF4" />
                <Hex value="#7FBBD9" />
              </span>,
              <span key="s">
                both <code>…/secondary</code>
              </span>,
            ],
          ]}
        />
        <P>
          <code>ghost</code> draws neither a fill nor a border for either palette, so it is
          unaffected.
        </P>
        <P>
          <strong className="text-foreground">Scope: 160 of the set&rsquo;s 560 variants</strong> —
          2 palettes × 5 treatments × 4 states × 4 sizes.
        </P>

        <H3>The same crossing on the avatar set</H3>
        <P>
          Found while building{' '}
          <Link to="/avatars?tab=figma" className="font-medium text-foreground hover:underline">
            the avatar Figma-layout tab
          </Link>
          , which reads
          each band&rsquo;s fill rather than trusting its name. All three of avatar&rsquo;s
          treatments are crossed the same way Button&rsquo;s five are:
        </P>
        <ProseTable
          head={['variant', 'palette', 'bound variable', 'colour', 'should be']}
          rows={[
            [
              <code key="v">solid</code>,
              <strong key="p">primary</strong>,
              <code key="b">surface/colored/secondary</code>,
              <Hex key="c" value="#4BC7B5" />,
              <code key="s">surface/colored/primary</code>,
            ],
            [
              <code key="v">solid</code>,
              <strong key="p">secondary</strong>,
              <code key="b">surface/colored/primary</code>,
              <Hex key="c" value="#004976" />,
              <code key="s">surface/colored/secondary</code>,
            ],
            [
              <code key="v">subtle</code>,
              <strong key="p">primary</strong>,
              <code key="b">surface/subtle/secondary</code>,
              <Hex key="c" value="#CFF3EC" />,
              <code key="s">surface/subtle/primary</code>,
            ],
            [
              <code key="v">subtle</code>,
              <strong key="p">secondary</strong>,
              <code key="b">brand/primary/50</code>,
              <Hex key="c" value="#EDF6FB" />,
              <code key="s">surface/subtle/secondary</code>,
            ],
            [
              <code key="v">outline</code>,
              <strong key="p">primary</strong>,
              <code key="b">border/subtle/secondary</code>,
              <Hex key="c" value="#CFF3EC" />,
              <code key="s">border/subtle/primary</code>,
            ],
            [
              <code key="v">outline</code>,
              <strong key="p">secondary</strong>,
              <code key="b">border/subtle/primary</code>,
              <Hex key="c" value="#D6EAF4" />,
              <code key="s">border/subtle/secondary</code>,
            ],
          ]}
        />
        <P>
          One row is wrong twice over. Avatar&rsquo;s <code>subtle</code> /{' '}
          <code>secondary</code> cell binds <code>brand/primary/50</code> — a raw ramp step rather
          than a semantic role, and one step lighter than the <code>…/100</code> the other
          treatments read. Rebinding it to <code>surface/subtle/secondary</code> fixes both at
          once. Note also that avatar&rsquo;s <code>outline</code> takes its stroke from{' '}
          <code>border/subtle/*</code> where Button takes it from <code>border/colored/*</code>;
          that difference is the set&rsquo;s own choice and is left alone here.
        </P>
        <P>
          <strong className="text-foreground">Scope: 72 of the set&rsquo;s 150 variants</strong> —
          2 palettes × 3 treatments × 2 shapes × 6 sizes. The six{' '}
          <code>avatar-type=avatar</code> variants are drawn only on <code>third</code>, so they
          are unaffected.
        </P>
        <P>
          Everything else about avatar matches: the box ladder (24 / 32 / 36 / 40 / 48 / 64px),
          the type ladder (10 / 12 / 14 / 16 / 20 / 24px) and the flat 8px square corner are
          identical to what the kit draws, measured rung by rung through the bridge.
        </P>

        <H3>Why Figma is the one that is wrong</H3>
        <P>Three independent places in the same file disagree with Button:</P>
        <ol className="max-w-prose list-decimal space-y-3 pl-5 text-sm text-muted-foreground">
          <li>
            <strong className="text-foreground">The variable table</strong> (
            <code>figma_variables</code>, the layer the REST API refuses):
            <pre className="mt-2 overflow-x-auto rounded-lg border border-border bg-muted px-3 py-2 text-[11px]">
              <code>{`brand/primary/500          = #004976   (navy)
brand/secondary/500        = #4BC7B5   (turquoise)
surface/colored/primary   -> brand/primary/500
surface/colored/secondary -> brand/secondary/500
border/colored/primary    -> brand/primary/300
border/colored/secondary  -> brand/secondary/200`}</code>
            </pre>
          </li>
          <li>
            <strong className="text-foreground">IconButton</strong> (<code>2399:522</code>),
            Button&rsquo;s closest sibling — <code>variant=solid, state=default, size=md</code>:
            primary <Hex value="#004976" />, secondary <Hex value="#4BC7B5" />. Correct.
          </li>
          <li>
            <strong className="text-foreground">ProgressCircle</strong> (<code>2264:23</code>) —
            track stroke at <code>size=md</code>: primary <Hex value="#D6EAF4" /> (Primary-100),
            secondary <Hex value="#CFF3EC" /> (Secondary-100). Correct.
          </li>
        </ol>
        <P>
          And this kit: <code>src/styles/tokens.css</code> names CBAR&rsquo;s Primary ramp{' '}
          <code>--ui-color-brand-*</code> (<Hex value="#004976" /> at 500, read by{' '}
          <code>.palette-primary</code>) and its Secondary ramp <code>--ui-color-secondary-*</code> (
          <Hex value="#4BC7B5" />
          ). Both match the variable table.
        </P>

        <H3>The two ways to fix it, and which to pick</H3>
        <P>
          <strong className="text-foreground">A — the variant names are wrong (recommended).</strong>{' '}
          Swap the <code>colorPalette</code> value on all 232 crossed variants — 160 on Button, 72
          on avatar: what is called <code>secondary</code> today becomes <code>primary</code>, and
          vice versa. Bindings are left alone.
        </P>
        <P>
          The argument for A is each set&rsquo;s own default. Button&rsquo;s is{' '}
          <code>colorPalette=secondary</code> and renders navy, so CBAR&rsquo;s default button
          already <em>is</em> the brand primary colour and only the label on it is wrong.
          Avatar&rsquo;s is <code>colorPalette=primary</code> and renders turquoise, so the rename
          lands it on <code>secondary</code> — correct for what it draws. In both cases A changes
          no pixel of anything anyone has already placed.
        </P>
        <P>
          <strong className="text-foreground">B — the bindings are wrong.</strong> Rebind each
          cell&rsquo;s fill and stroke to the opposite role. If you take this route you must{' '}
          <strong className="text-foreground">also move each set&rsquo;s default</strong>, or the
          default silently changes colour in every instance in every file — Button turning
          turquoise, avatar turning navy. Avatar needs one extra edit either way: its{' '}
          <code>subtle</code> / <code>secondary</code> cell has to leave{' '}
          <code>brand/primary/50</code> for a semantic role, which no rename can do.
        </P>
        <div className="max-w-prose rounded-lg border border-border bg-muted/50 px-4 py-3 text-sm text-muted-foreground">
          Either way, nothing changes in this kit.{' '}
          <strong className="text-foreground">
            Do not &ldquo;fix&rdquo; this by swapping the ramps in <code>tokens.css</code>.
          </strong>{' '}
          That trades one wrong component for a whole kit that disagrees with the variable table it
          is generated from — and <code>tokens.css</code> is machine-owned, so the next{' '}
          <code>figma-sync</code> would overwrite the edit anyway.
        </div>
      </Finding>

      <Finding
        n={2}
        title="Button outline: an inconsistent white fill"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> low.{' '}
            <strong className="text-foreground">Where:</strong> same set.
          </>
        }
      >
        <P>
          <code>variant=outline, colorPalette=secondary</code> carries a <strong>visible</strong>{' '}
          white fill (<Hex value="#FFFFFF" />
          ); <code>variant=outline, colorPalette=primary</code> carries none. An outline button
          should have no fill on either. Independent of §1 — fixing the palette crossing will not
          fix this.
        </P>
      </Finding>

      <Finding
        n={3}
        title="Solid label colour — resolved in Figma's favour"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> was high (a visible divergence).{' '}
            <strong className="text-foreground">Where:</strong> same set.{' '}
            <strong className="text-foreground">Who moved:</strong> this kit.
          </>
        }
      >
        <P>Every solid fill in the set was read together with the label drawn on it:</P>
        <ProseTable
          head={['palette (Figma label)', 'fill', 'label']}
          rows={[
            [<code key="p">secondary</code>, <Hex key="f" value="#004976" />, <Hex key="l" value="#FFFFFF" />],
            [<code key="p">primary</code>, <Hex key="f" value="#4BC7B5" />, <Hex key="l" value="#FFFFFF" />],
            [<code key="p">red</code>, <Hex key="f" value="#EF4444" />, <Hex key="l" value="#FFFFFF" />],
            [<code key="p">green</code>, <Hex key="f" value="#22C55E" />, <Hex key="l" value="#FFFFFF" />],
            [<code key="p">yellow</code>, <Hex key="f" value="#F3C67F" />, <Hex key="l" value="#865F28" />],
            [<code key="p">black</code>, <Hex key="f" value="#333333" />, <Hex key="l" value="#FFFFFF" />],
            [<code key="p">third</code>, <Hex key="f" value="#0082BA" />, <Hex key="l" value="#FFFFFF" />],
          ]}
        />
        <P>
          So CBAR&rsquo;s rule is: white on every solid fill, with yellow the single exception — the
          one place it darkens the ink instead. The kit had made that same trade in two more places,
          on the turquoise and the green, because white measures{' '}
          <strong className="text-foreground">2.07:1</strong> and{' '}
          <strong className="text-foreground">2.28:1</strong> there against the 3:1 WCAG asks for a
          control.
        </P>
        <P>
          That deviation is now removed: <code>.palette-secondary</code> and{' '}
          <code>.palette-green</code> set <code>--ctl-solid-fg</code> to{' '}
          <code>--ui-color-neutral-0</code>. Fidelity to the design system was chosen over the
          contrast number, deliberately and with the number on the record —{' '}
          <code>test/contrast.test.ts</code> still measures both pairs and prints them, with a floor
          of 1 so they no longer gate the suite. <code>--ctl-fg</code>, the ink every tinted
          treatment uses, did not move and still clears 4.5:1. Consumer-facing note in README §9c.
        </P>
        <P>
          <strong className="text-foreground">The design-side finding stands:</strong> if CBAR wants
          those two labels to pass AA, the fill has to move, not the ink. <code>secondary-700</code>{' '}
          and <code>green-700</code> both carry white comfortably.
        </P>
      </Finding>

      <Finding
        n={4}
        title="state=active is drawn identically to state=hover"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> none — recorded so nobody
            &ldquo;implements&rdquo; a state that does not exist.
          </>
        }
      >
        <P>
          Across all five treatments of the primary band, each <code>state=active</code> variant
          paints exactly what its <code>state=hover</code> twin paints (<code>2446:9576</code> solid,{' '}
          <code>2446:7384</code> subtle, <code>2446:7464</code> surface, <code>2446:7544</code>{' '}
          outline, <code>2446:7624</code> ghost). The kit has no <code>:active</code> treatment at
          all, which lands on the same rendering. The showcase&rsquo;s{' '}
          <Link to="/buttons" className="font-medium text-foreground hover:underline">
            Figma layout
          </Link>{' '}
          tab therefore draws both rows with the same forced class and says so.
        </P>
        <P>Two hover tints do differ, and are left alone for now:</P>
        <ul className="max-w-prose list-disc space-y-2 pl-5 text-sm text-muted-foreground">
          <li>
            <code>subtle</code> and <code>surface</code> — CBAR&rsquo;s hover is the same tint as its
            default (step 100); the kit deepens one step to <code>--ctl-subtle-hover</code> (200), so
            a tinted button here responds to the pointer and there does not.
          </li>
          <li>
            <code>outline</code> and <code>ghost</code> — CBAR&rsquo;s hover is step{' '}
            <strong className="text-foreground">50</strong>; the kit uses step 100 (
            <code>--ctl-subtle</code>). The kit already has the right token for this,{' '}
            <code>--ctl-soft</code>, which <code>theme.css</code> introduced for exactly this rung.
            Switching the two transparent treatments over is a one-line change in{' '}
            <code>controlVariants</code> — but it also moves Tabs and Pagination, which read{' '}
            <code>--ctl-soft</code> today, so it wants its own decision.
          </li>
        </ul>
        <P>
          <code>disabled</code> is a third: CBAR draws <code>opacity: 0.3</code>, the kit{' '}
          <code>0.5</code>.
        </P>
      </Finding>

      <Finding
        n={5}
        title="Muted text is 4.41:1 — a hair under AA, in light mode only"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> medium — it is the colour every
            secondary line of text on every page is painted in.{' '}
            <strong className="text-foreground">Where:</strong> CBAR variable{' '}
            <code>text/tertiary</code>, the kit&rsquo;s <code>--ui-color-neutral-500</code> →{' '}
            <code>--muted-foreground</code>. <strong className="text-foreground">Who moves:</strong>{' '}
            the design file, if anyone. The kit follows the ramp and should keep following it.
          </>
        }
      >
        <P>
          CBAR&rsquo;s neutral ramp puts <code>text/tertiary</code> at <Hex value="#787878" />. Read
          on the two surfaces it actually lands on:
        </P>
        <ProseTable
          head={['pair', 'foreground', 'background', 'ratio', 'AA body text (4.5:1)']}
          rows={[
            [
              'muted text on the page',
              <span key="f" className="flex flex-wrap gap-2">
                <code>neutral-500</code>
                <Hex value="#787878" />
              </span>,
              <span key="b" className="flex flex-wrap gap-2">
                <code>neutral-0</code>
                <Hex value="#FFFFFF" />
              </span>,
              <strong key="r" className="text-foreground">
                4.41:1
              </strong>,
              'fails, by 0.09',
            ],
            [
              'muted text on a muted surface',
              <span key="f" className="flex flex-wrap gap-2">
                <code>neutral-500</code>
                <Hex value="#787878" />
              </span>,
              <span key="b" className="flex flex-wrap gap-2">
                <code>neutral-100</code>
                <Hex value="#F0F0F0" />
              </span>,
              <strong key="r" className="text-foreground">
                3.87:1
              </strong>,
              'fails',
            ],
            [
              'dark: muted text on the page',
              <span key="f" className="flex flex-wrap gap-2">
                <code>neutral-400</code>
                <Hex value="#A3A3A3" />
              </span>,
              <span key="b" className="flex flex-wrap gap-2">
                <code>neutral-950</code>
                <Hex value="#0A0A0A" />
              </span>,
              <strong key="r" className="text-foreground">
                7.85:1
              </strong>,
              'passes comfortably',
            ],
          ]}
        />
        <P>
          The second row is the one worth reading twice. Muted text on a muted surface is the{' '}
          <em>more</em> common pairing in practice — table headers, code blocks, chips, every
          secondary line inside a <code>Card</code> — and it is well under, not marginally under.
        </P>
        <P>
          The third row is why this is filed as a light-mode finding rather than a token finding.
          Dark mode drops <code>--muted-foreground</code> to <code>neutral-400</code> and clears AA
          outright, so the ramp is not the problem; the choice of step on a white page is.
        </P>

        <H3>How it was found, and where it is recorded</H3>
        <P>
          The showcase&rsquo;s own axe run — the <strong className="text-foreground">Axe</strong>{' '}
          switch in the toolbar, or <code>?a11y=on</code> on any page — reports it on every page in
          light mode and nothing in dark. After the five structural
          fixes made while that panel was built, this token is the <em>only</em> remaining violation
          anywhere on the site — which is the useful part: the panel is reporting a known trade, not
          a regression, and a new finding there stands out.
        </P>
        <P>
          <code>test/contrast.test.ts</code> carries all three rows. The two light ones have a floor
          of <strong className="text-foreground">3</strong> — enough to catch a real regression, low
          enough not to gate the suite on a decision already taken — and the dark one has the full
          4.5, because nothing about it is a compromise.
        </P>

        <H3>What the design file could do</H3>
        <P>
          Nothing here is fixable in code without leaving the ramp, which is not worth doing for
          0.09. The options belong to CBAR:{' '}
          <code>text/tertiary</code> moves one step to <code>neutral-600</code> (
          <Hex value="#474747" />, 8.6:1, but it stops reading as tertiary), or the file states that{' '}
          <code>text/tertiary</code> is for large text and non-essential labels only and a second
          variable covers body copy. Until one of those happens the kit renders what the ramp says.
        </P>
      </Finding>

      <Finding
        n={6}
        title="Elevation has no dark counterpart — the shadows are the page colour"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> low — nothing is unreadable, an
            affordance is simply absent. <strong className="text-foreground">Where:</strong>{' '}
            <code>--ui-shadow-xs … xl</code> in <code>tokens.css</code>; CBAR&rsquo;s{' '}
            <code>shadows/shadows light/*</code> effect styles.{' '}
            <strong className="text-foreground">Who moves:</strong> the design file — it has no dark
            elevation set to sync from.
          </>
        }
      >
        <P>
          Every one of the kit&rsquo;s five shadows is painted in{' '}
          <code>oklch(0.145 0 0)</code> at 5–10% alpha. That value is not merely dark, it is{' '}
          <em>exactly</em> <code>--ui-color-neutral-950</code>{' '}
          <Hex value="#0A0A0A" /> — which is what <code>.dark</code> sets{' '}
          <code>--background</code> to. So in dark mode a raised surface casts a shadow in the colour
          of the page it is sitting on, at one tenth opacity. It is not subtle; it is not there.
        </P>
        <P>
          <code>theme.css</code>&rsquo;s <code>.dark</code> block overrides forty-odd roles and none
          of them is a shadow, so this is not an oversight in one component — the whole elevation
          scale is light-mode-only. It is visible on the{' '}
          <Link to="/tokens" className="font-medium text-foreground hover:underline">
            tokens page
          </Link>
          : switch to dark and the five elevation swatches become five flat rectangles.
        </P>

        <H3>Why the sync cannot fix it</H3>
        <P>
          <code>tokens.css</code> marks this block <strong className="text-foreground">UNMAPPED</strong>{' '}
          — CBAR&rsquo;s file defines no elevation scale at all as a variable collection, and the
          only shadow effect anywhere in it is a 1px inner shadow used as a border. What it does
          publish is a set of <em>effect styles</em> named{' '}
          <code>shadows/shadows light/*</code> — and the name is the finding. There is no{' '}
          <code>shadows dark/*</code> beside it. The showcase&rsquo;s own chrome uses those published
          values (<code>--cbar-shadow-*</code> in <code>showcase.css</code>) and inherits the same
          gap.
        </P>
        <P>
          So a <code>figma-sync</code> run cannot close this. There is nothing on the other side to
          read.
        </P>

        <H3>What each side can do</H3>
        <P>
          <strong className="text-foreground">Design:</strong> publish a{' '}
          <code>shadows dark/*</code> set. The usual answer is not a darker shadow — on a near-black
          page there is no room below — but a larger spread at higher alpha plus a light 1px ring, so
          the edge does the work the drop shadow does in light.
        </P>
        <P>
          <strong className="text-foreground">Kit:</strong> the convention CBAR already uses in light
          is available and costs no new token. It tints its cards one step off the page rather than
          relying on a shadow, which is why <code>--card</code> is a tinted surface here and not
          white — and <code>.dark</code> already lifts <code>--card</code> to{' '}
          <code>neutral-900</code>. Extending that lift to the popover/dialog layers would give dark
          mode a real elevation cue in the file&rsquo;s own idiom. Left undone deliberately: it is a
          visual change to every floating surface, so it wants its own decision rather than a quiet
          fix inside a parity write-up.
        </P>
      </Finding>

      <Finding
        n={7}
        title="Alert: wired correctly — and three outline variants carry a stray fill"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> low — one copy-paste artefact on
            three of 72 variants, plus two off-ramp colours.{' '}
            <strong className="text-foreground">Where:</strong> set <code>Alert</code> (
            <code>2446:316</code>); nodes <code>2446:592</code>, <code>2446:597</code>,{' '}
            <code>2446:587</code>. <strong className="text-foreground">Who moves:</strong> the design
            file — the kit&rsquo;s <code>outline</code> is border-only by definition.
          </>
        }
      >
        <P>
          Read in full while rebuilding the{' '}
          <Link to="/alerts?tab=figma" className="font-medium text-foreground hover:underline">
            Alert Figma-layout tab
          </Link>
          . The headline is the good news, and it is the direct counter-example to §1: this set is
          bound to the variables correctly. Its <code>status</code> axis is what the kit expresses as{' '}
          <code>colorPalette</code>, and every band&rsquo;s fill lands on the ramp step the variable
          table says it should.
        </P>

        <ProseTable
          head={['status', 'solid', 'subtle', 'border', 'kit palette']}
          rows={[
            ['info', <Hex value="#4BC7B5" />, <Hex value="#CFF3EC" />, <Hex value="#A6E8DA" />, <code>secondary</code>],
            ['warning', <Hex value="#F3C67F" />, <Hex value="#FEF9C3" />, <Hex value="#F3C67F" />, <code>yellow</code>],
            ['success', <Hex value="#22C55E" />, <Hex value="#DCFCE7" />, <Hex value="#22C55E" />, <code>green</code>],
            ['error', <Hex value="#EF4444" />, <Hex value="#FEE2E2" />, <Hex value="#F00000" />, <code>red</code>],
            ['info-secondary', <Hex value="#004976" />, <Hex value="#D6EAF4" />, <Hex value="#7FBBD9" />, <code>primary</code>],
            ['neutral', <Hex value="#333333" />, <Hex value="#E5E5E5" />, <Hex value="#D4D4D4" />, <code>black</code>],
          ]}
        />

        <P>
          Note what <code>info</code> is: the turquoise <code>brand/secondary/500</code>, while{' '}
          <code>info-secondary</code> is the navy <code>brand/primary/500</code>. That is the same
          pair §1 finds crossed on Button — and here it is the right way round, which is a third
          witness (beside <code>IconButton</code> and <code>ProgressCircle</code>) that Button is the
          single mis-wired set rather than the ramps being backwards. The showcase&rsquo;s band table
          was corrected to match; <code>tokens.css</code> was not touched.
        </P>

        <H3>The stray outline fill</H3>
        <P>
          <code>variant=outline</code> is supposed to be a border with nothing behind it, and on{' '}
          <code>info</code>, <code>error</code> and <code>neutral</code> it is. On{' '}
          <code>warning</code> (<code>2446:592</code>), <code>success</code> (<code>2446:597</code>)
          and <code>info-secondary</code> (<code>2446:587</code>) it carries a{' '}
          <Hex value="#D6EAF4" /> fill — <code>brand/primary/100</code>, the navy tint. On{' '}
          <code>info-secondary</code> that makes <code>outline</code> pixel-identical to{' '}
          <code>surface</code>; on the other two it puts a blue wash under a yellow or green border.
          It reads as three cells pasted from the <code>surface</code> row and re-bordered.
        </P>
        <P>
          Not replicated. The kit&rsquo;s <code>outline</code> stays{' '}
          <code>border-(--ctl-border)</code> with no background at every palette, so the Figma tab
          shows three cells that are lighter than the canvas. Same call as §2, which is the same bug
          on Button.
        </P>

        <H3>Two colours off the ramp, and one icon doing six jobs</H3>
        <P>
          The <code>error</code> border is <Hex value="#F00000" /> — pure red, not{' '}
          <code>red-600</code> <Hex value="#E7000B" />. And <code>warning</code>&rsquo;s subtle fill
          is <Hex value="#FEF9C3" />, which is Tailwind&rsquo;s yellow-100, not CBAR&rsquo;s{' '}
          <Hex value="#FEF8EB" />. The second one is the stale standalone <code>Yellow</code>{' '}
          collection surfacing again — the same one that put nine wrong steps in the kit before the
          Variables became readable. Neither is worth a token change; both are worth knowing before
          somebody eyedrops a value off this set.
        </P>
        <P>
          Lastly, all 72 variants draw the same icon —{' '}
          <code>Outline/Status/Info-triangle</code> — including <code>success</code> and{' '}
          <code>neutral</code>. There is no <code>INSTANCE_SWAP</code> property to vary it, so a
          consumer reading the set alone would think an alert has one icon. The kit takes the icon as
          a child and imposes nothing, which is the right shape; the Figma tab draws{' '}
          <code>InfoTriangleIcon</code> on all six bands purely to match the canvas.
        </P>
      </Finding>

      <Finding
        n={8}
        title="Toast: four states exact, and two competing neutral surfaces"
        meta={
          <>
            <strong className="text-foreground">Severity:</strong> low — four of five states match to
            the byte; the fifth exposes an inconsistency inside the design file itself.{' '}
            <strong className="text-foreground">Where:</strong> set <code>Toast</code> (
            <code>2414:10758</code>); nodes <code>2414:10757</code>, <code>2414:10759</code>;
            compared against <code>Alert</code> <code>2446:432</code> and <code>Badge</code>{' '}
            <code>2456:5339</code>. <strong className="text-foreground">Who moves:</strong> the design
            file — the kit cannot satisfy both spellings at once.
          </>
        }
      >
        <P>
          Read while building the{' '}
          <Link to="/toasts?tab=figma" className="font-medium text-foreground hover:underline">
            Toast Figma-layout tab
          </Link>
          . This set is the easiest to audit so far: <code>getCSSAsync()</code> returns the bound
          variable names directly, so there is nothing to infer from hex values.
        </P>

        <ProseTable
          head={['state', 'surface', 'border', 'variables', 'kit kind', '']}
          rows={[
            ['success', <Hex value="#DCFCE7" />, <Hex value="#22C55E" />, <code>subtle-positive / colored-positive</code>, <code>success</code>, 'exact'],
            ['error', <Hex value="#FEE2E2" />, <Hex value="#F00000" />, <code>subtle-negative / colored-negative</code>, <code>error</code>, 'exact'],
            ['warning', <Hex value="#FEF9C3" />, <Hex value="#F3C67F" />, <code>subtle-warning / colored-warning</code>, <code>warning</code>, 'exact'],
            ['info', <Hex value="#CFF3EC" />, <Hex value="#A6E8DA" />, <code>subtle-secondary / colored-secondary</code>, <code>info</code>, 'exact'],
            ['neutral', <Hex value="#F9F9F9" />, <Hex value="#474747" />, <code>subtle-gray / colored-black</code>, <code>default</code>, 'differs'],
          ]}
        />

        <P>
          <code>info</code> binds <code>--surface-subtle-secondary</code> — the turquoise again, the
          third independent witness after §7&rsquo;s <code>info</code> band and Badge&rsquo;s{' '}
          <code>default</code> colour that §1 is a Button-and-avatar defect rather than the ramps
          being backwards. <code>kindPalettes</code> in <code>toast.tsx</code> already maps the first
          four rows exactly, and the kit renders them byte-identical to the canvas.
        </P>

        <H3>Two neutral surfaces, applied inconsistently</H3>
        <P>
          The fifth row does not match, and the reason is not on the kit&rsquo;s side. CBAR carries{' '}
          <em>two</em> variables for the same visual role, and different sets reach for different
          ones:
        </P>
        <ProseTable
          head={['set', 'variable', 'surface', 'border']}
          rows={[
            ['Alert (2446:432)', <code>--surface-subtle-neutral</code>, <Hex value="#E5E5E5" />, <Hex value="#D4D4D4" />],
            ['Toast (2414:10757)', <code>--surface-subtle-gray</code>, <Hex value="#F9F9F9" />, <Hex value="#474747" />],
            ['Badge (2456:5339)', <code>--surface-subtle-gray</code>, <Hex value="#F9F9F9" />, <Hex value="#474747" />],
          ]}
        />
        <P>
          The kit has one <code>palette-black</code>, whose <code>--ctl-subtle</code> is{' '}
          <Hex value="#E5E5E5" /> and <code>--ctl-border</code> <Hex value="#A3A3A3" />. So it agrees
          with Alert and reads a step lighter than Toast and Badge. Not changed: re-pointing{' '}
          <code>--ctl-subtle</code> at <Hex value="#F9F9F9" /> would fix two sets by breaking the
          one that is currently right, and <code>tokens.css</code> is machine-owned — a{' '}
          <code>figma-sync</code> would undo a hand edit anyway. The design file should collapse the
          two variables to one; until then the kit stays on the value the majority of its own
          components already render.
        </P>

        <P>
          Geometry matches too, measured rather than assumed: <code>12px 16px</code> padding, a 6px
          radius, a 3px border on the <em>leading edge only</em>, 10px between icon and text, title
          14/600 over description 14/28 with 5px between them, glyphs at 20px. Two differences are
          the kit&rsquo;s and both are deliberate — the canvas frames every toast at a fixed 306px
          where the kit&rsquo;s column is 384px and the toast fills it, and the kit adds{' '}
          <code>shadow-lg</code> because a notification floating over live content has to read as
          elevated where a flat swatch on a canvas does not.
        </P>

        <H3>The same glyph five times — adopted</H3>
        <P>
          Every variant&rsquo;s left slot instantiates <code>Solid/Status/Info-circle</code> (
          <code>2163:653</code>) — including <code>success</code> and <code>error</code> — and only
          the fill changes. Checked on all five through the bridge rather than inferred from one,
          and the close cross beside it takes the same colour:
        </P>
        <ProseTable
          head={['state', 'canvas ink', 'ramp step', 'on its tint', 'the label beside it']}
          rows={[
            ['success', <Hex value="#16A34A" />, <code>green-600</code>, '3.00:1', '6.18:1'],
            ['error', <Hex value="#F00000" />, <code>red-600</code>, '3.65:1', '6.86:1'],
            ['warning', <Hex value="#865F28" />, <code>yellow-ink</code>, '5.31:1', '5.31:1'],
            ['info', <Hex value="#4BC7B5" />, <code>secondary-500</code>, '1.74:1', '8.34:1'],
            ['neutral', <Hex value="#222222" />, <code>neutral-800</code>, '15.11:1', '15.11:1'],
          ]}
        />
        <P>
          Every one is already a named ramp step, which is what made adopting them a token change
          rather than five literals. The close cross takes the same colour as the status glyph, so
          the table covers it too. The last column is <code>--ctl-fg</code>, what the title and
          description are set in and what the glyph used to use: on <code>warning</code> and{' '}
          <code>neutral</code> the two agree byte-for-byte, and on the other three the glyph is now
          the lighter of the two. <code>info</code> is the extreme — a turquoise glyph on a
          turquoise surface at <strong>1.74:1</strong> is decorative rather than legible, and the
          text beside it stays at 8.34:1.
        </P>
        <P>
          Unlike Alert there <em>is</em> an <code>INSTANCE_SWAP</code> property (<code>icon</code>,
          defaulting to that node), so the set can vary it and simply does not.
        </P>
        <P>
          <strong className="text-foreground">This one was adopted rather than recorded.</strong>{' '}
          The kit used to pick a glyph per kind — a tick for <code>success</code>, a warning
          triangle for <code>warning</code>, an octagon for <code>error</code>, and none at all for
          a plain toast. It now draws CBAR&rsquo;s single info-circle on all five and tells them
          apart by colour, which is the design file&rsquo;s own scheme. <code>loading</code> keeps
          its spinner: it has no counterpart on the canvas, and a static circle would throw away
          the one thing a pending toast has to say.
        </P>
        <P>
          The ink moved with it, through a new <code>--ctl-icon</code> role in{' '}
          <code>theme.css</code> bound to the ramp steps above. It is a <em>lower</em>-contrast role
          than <code>--ctl-fg</code> and must never be used for text — that is the cost, and it is
          the second time on this page that matching CBAR was chosen over a contrast number, after
          §3. Both tabs of <code>/toasts</code> now render the same thing, and the Figma-layout tab
          forces nothing at all: the two sides converged, which is the outcome a parity page exists
          to produce.
        </P>

        <H3>The close button defaults on</H3>
        <P>
          <code>iconRight?</code> is a boolean defaulting <strong>true</strong>, so every variant on
          the canvas carries a dismiss control. The kit&rsquo;s{' '}
          <code>Toaster closeButton</code> defaults <strong>false</strong>. Left alone on purpose:
          flipping it would add a button to every toast in every app already consuming the kit, for
          a difference that is one prop away. The Figma-layout tab draws it on to match the canvas
          and says so.
        </P>

        <H3>A reporting bug this set exposed</H3>
        <P>
          Toast&rsquo;s only axis is named <code>state</code>, and the parity report treats an axis
          by that name as an interaction concern drawn in CSS — correct for the fourteen other sets
          whose <code>state</code> holds <code>hover</code> / <code>focused</code> /{' '}
          <code>disabled</code>, and wrong here, where it holds statuses. Toast was therefore being
          reported with no comparable axis at all. Fixed with an explicit{' '}
          <code>statusAxes</code> opt-out on the registry entry rather than a cleverer heuristic,
          because <code>Button</code> already maps its own <code>state</code> axis onto a{' '}
          <code>disabled</code> prop while genuinely being a CSS state.
        </P>
      </Finding>

      <section className="space-y-3 border-t border-border pt-8">
        <h2 className="t-h4 text-foreground">Checked and not a problem</h2>
        <ul className="max-w-prose list-disc space-y-2 pl-5 text-sm text-muted-foreground">
          <li>
            <strong className="text-foreground">Hidden paints on ghost.</strong> A node dump shows
            fills and strokes on the <code>ghost</code> variants, but they are{' '}
            <code>visible: false</code> and never render — <code>getCSSAsync()</code> reports
            neither. Do not read a raw <code>fills</code> array without checking visibility.
          </li>
          <li>
            <strong className="text-foreground">The third palette.</strong>{' '}
            <code>colorPalette=third</code> solid is <Hex value="#0082BA" />, which is exactly{' '}
            <code>--ui-color-tertiary-500</code> here. The ramp is right; only the <em>name</em> is
            legacy (<code>third</code> is kept as a deprecated alias of <code>tertiary</code> for one
            major — see README §9a-i).
          </li>
        </ul>
      </section>

      <section className="space-y-3 border-t border-border pt-8">
        <h2 className="t-h4 text-foreground">Re-verifying this</h2>
        <P>
          Open the &ldquo;CBAR Figma bridge&rdquo; plugin in Figma, then from the project root:
        </P>
        <CopyBlock
          code={`node tools/figma-bridge/cli.mjs variables -o out/variables.json
node tools/figma-bridge/cli.mjs node 2446:6959 --depth 2 -o out/button.json
node tools/figma-bridge/cli.mjs css 2446:7312     # solid / primary
node tools/figma-bridge/cli.mjs css 2446:6972     # solid / secondary
node tools/figma-bridge/cli.mjs node 2446:316 --depth 2 -o out/alert.json   # §7
node tools/figma-bridge/cli.mjs node 2446:587 --depth 3   # outline / info-secondary`}
        />
        <P>
          Or, with no scripting at all: open{' '}
          <Link to="/button" className="font-medium text-foreground hover:underline">
            the Button page
          </Link>{' '}
          and read the <strong className="text-foreground">Figma</strong> panel at the bottom. It
          resolves the playground&rsquo;s selection to the real variant and puts CBAR&rsquo;s own
          render and computed style beside the kit&rsquo;s — which is how §1 was found.
        </P>
        <P>
          For §3 and §4 the faster route is the{' '}
          <Link to="/buttons" className="font-medium text-foreground hover:underline">
            Figma layout tab
          </Link>
          : it arranges the live components the way the canvas arranges them — a band per palette, a
          column per treatment, a row per state — so the two can be compared cell for cell without
          resolving anything by hand.
        </P>
      </section>
    </div>
  );
}