Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.changeset/mosaic-slot-recipes.md:
- Around line 1-2: The empty changeset file .changeset/mosaic-slot-recipes.md
must be populated with a proper changeset: add a YAML frontmatter listing the
package "`@clerk/ui`" and set the bump type to "minor", and include a concise
summary explaining the mosaic slot recipes feature and the new public APIs
(e.g., defineSlotRecipe, useRecipe, MosaicProvider enhancements) so release
tooling and consumers understand the change.

In `@packages/ui/src/mosaic/appearance.ts`:
- Around line 63-88: Add a JSDoc block above the exported function
parseMosaicAppearance describing its purpose (parses a MosaicAppearance.elements
object into global+scoped layers), document the parameters (appearance?:
MosaicAppearance, scope?: string) with types and meanings, document the return
type (ParsedMosaicElements) and behavior (global keys collected first, then
scoped keys if scope matches SCOPE_KEY_SET), and include a short example showing
input appearance and the resulting array (as in the suggested snippet); ensure
the JSDoc is on the exported function so Clerk Docs will pick it up and mention
usage by MosaicProvider.

---

Nitpick comments:
In `@packages/ui/src/mosaic/slot-recipe.ts`:
- Around line 269-311: Extract the local kebab function into a shared utility
module (e.g., export function kebab(value: string): string) and replace the
duplicated implementations by importing that exported kebab in both
slot-recipe.ts (used by variantsToAttrs and stateToAttrs) and useSlot.ts; update
the files to remove the local kebab definitions, add the import, and ensure the
shared util is exported for reuse and covered by existing tests/typings.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/ui/src/mosaic/MosaicProvider.tsx`:
- Around line 47-56: The useInsertionEffect in MosaicProvider currently runs on
every render because it has no dependency array; update it to only re-run when
its inputs change (e.g., include cssLayerName and cache.key in the dependency
array) so you don't repeatedly re-scan and wrap all
style[data-emotion^="${cache.key}"] tags each render, while retaining the
idempotent `@layer` check; if you intentionally need per-render execution, add a
concise comment in MosaicProvider explaining why it must run every render
despite the cost and referencing useInsertionEffect, cssLayerName, and
cache.key.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@packages/swingset/src/stories/dialog.component.stories.tsx`:
- Around line 14-19: Change the story function Default to accept a single
parameter of type Record<string, unknown> (e.g., Default(args: Record<string,
unknown>)) and cast that generic args object to the concrete prop types used in
the story before passing them through; locate the Default function and update
how props are forwarded into Dialog.Trigger's render and the Button (cast args
to the proper HTMLAttributes/prop types) so the story follows the shared
knobs-to-props contract.

In `@packages/ui/src/mosaic/MosaicProvider.tsx`:
- Around line 25-33: The provider removed the standalone variables prop and now
only reads appearance?.variables, which breaks backward compatibility; update
MosaicProviderProps to reintroduce variables (e.g., variables?:
Partial<MosaicVariables>) and change the memo that builds theme to merge/precede
props.variables with appearance?.variables (e.g.,
resolveVariables(defaultMosaicVariables, variables ?? appearance?.variables) or
otherwise merge so existing consumers using the variables prop keep their
overrides), leaving parseMosaicAppearance(scope, appearance) unchanged;
reference MosaicProvider, MosaicProviderProps, appearance, variables,
resolveVariables, parseMosaicAppearance, and defaultMosaicVariables when making
the change.

In `@references/mosaic-architecture.md`:
- Line 263: Update the sentence at line 263 to distinguish between two cases:
(1) when a variant map entry is null — explain that pickSlot converts falsy
entries (null → undefined) and mergeInto only merges truthy sources so those
variant-map entries result in no styles; and (2) when a variant prop is
explicitly passed as null — explain that it becomes the string key "null" for
lookup so styles only apply if the recipe defines a "null" variant. Reference
the existing terms pickSlot, mergeInto, variant map, variant prop, and recipe in
the revised wording to make the distinction clear.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@packages/ui/src/mosaic/__tests__/MosaicProvider.test.tsx`:
- Around line 44-46: Replace the verbose React.createElement usage in the test
hook wrappers with JSX to improve readability: update the wrapper function
passed to renderHook that currently uses React.createElement(MosaicProvider, {
appearance, scope: 'signIn' }, children) (and the other two similar instances)
to return JSX for MosaicProvider with props appearance and scope and the
children inside; target the useMosaicAppearance test wrappers and any other
wrapper lambdas referencing MosaicProvider to make this change.
- Around line 56-71: Add a test to MosaicProvider.test.tsx that verifies
useMosaicTheme throws when called outside a MosaicProvider: create an it() case
that calls renderHook(() => useMosaicTheme()) with no wrapper and assert it
throws with the exact message 'useMosaicTheme must be used within a
MosaicProvider' (use expect(() => renderHook(...)).toThrow(...)); reference the
useMosaicTheme hook and MosaicProvider to locate where to add the test.