pasika 0.1.4 → 0.1.6

package/docs/code-organization-guide/rules/locales-rule.md

@@ -3,10 +3,8 @@
 When locale strings are scattered across components and constants, they are hard to find and keep consistent. This rule keeps them in one central file, puts each feature's strings together, and uses readable keys.
 
 - All locales MUST live in the named `locales` object exported from `src/locales/index.ts`.
-- A locale consumer is a module that reads the locale.
-- A new locale with no consumers MUST use a feature namespace when it is for one feature; otherwise it MUST live at the top level of `locales`.
-- Locales read only by modules in one feature folder MUST live in an object with the camelCase form of its feature folder name (for example, `user-settings` becomes `userSettings`).
-- Locales read by modules in more than one feature folder or by `src/shared/`, `src/compositions/`, `src/app/`, or root support folders MUST live at the top level of `locales`.
+- Locales read only by files in one feature folder MUST live in an object with the camelCase form of its feature folder name (for example, `user-settings` becomes `userSettings`).
+- Locales read by files in more than one feature folder or by `src/shared/`, `src/compositions/`, `src/app/`, or root support folders MUST live at the top level of `locales`.
 - A namespaced locale MUST be read through its full dotted path (`locales.stream.watchLiveStream`).
 - A locale key MUST be camelCase English based on the text, unless a direct translation would be unclear or unwieldy. In that case, it MAY describe the message's purpose instead.
 

package/docs/code-organization-guide/rules/no-mixed-concerns-rule.md

@@ -3,7 +3,6 @@
 One component per file keeps components easy to find and change independently. This rule applies the same requirement to copied and generated source.
 
 - A `.tsx` file that defines a component MUST contain exactly one component.
-- A non-component module MUST use `.ts`, except when a framework requires a `.tsx` routing file.
 
 ## Incorrect — Two Components in One File
 

package/docs/code-organization-guide/rules/repeated-structure-rule.md

@@ -2,7 +2,7 @@
 
 Repeated markup can drift when one copy changes and another does not. This rule makes repeated structure a clear extraction trigger.
 
-- A block of elements MUST be extracted as a named component when the same structural frame and semantic purpose appear in two or more places. Different data or labels do not prevent extraction.
+- A block of elements MUST be extracted as a named component when two or more places use the same arrangement of elements for the same purpose. Different data or labels do not prevent extraction.
 
 ## Incorrect — Repeated Structure Kept Inline
 

package/docs/code-organization-guide/rules/smart-vs-dumb-component-rule.md

@@ -2,12 +2,8 @@
 
 Without a file-name convention, a component's smart vs dumb ownership is invisible to reviewers from the tree alone. Without a `data-testid` matching the file's casing, tests hardcode DOM identities that break on rename or restructure.
 
-- Remote or shared application data or state is data from a server, context, store, URL, or server action. A component MUST be smart when it fetches or mutates that data, performs an effect, or defines a callback that changes it, including through a hook or service.
-- A component is considered to perform these operations when it calls a custom hook that performs them.
-- In this rule, an effect MUST be a subscription, external I/O, DOM manipulation, or resource lifecycle.
-- Local UI state and callbacks that only update it MUST NOT make a component smart, including when passed to another component or directly to a native element.
-- A dumb component MUST NOT do any of these.
-- A component that does none of these MUST be dumb.
+- A smart component MUST fetch data, or define `handle*` callbacks and pass them to children as `on*` props.
+- A dumb component MUST NOT fetch data or define `handle*` callbacks for children.
 - A smart component file name MUST be `PascalCase.tsx`.
 - A dumb component file name MUST be `kebab-case.tsx`.
 - A smart component with one outer DOM element in every rendered result MUST set `data-testid` on that element, and its value MUST match the component name in `PascalCase`.

package/docs/code-organization-guide/rules/sole-state-owner-rule.md

@@ -2,8 +2,7 @@
 
 Some blocks of elements are the only consumers of a state hook. This rule extracts those blocks into components that own the hook.
 
-- A state hook's consumers are the JSX, callbacks, and effects that read its state value or call its updater.
-- A proper sub-block of a component's output MUST be extracted when it contains every consumer of one state hook and one clear component name describes it. A consumer declared before `return` belongs to a sub-block only when it is used exclusively by that sub-block; otherwise this rule does not require extraction. The component that owns the state is not itself an extraction trigger.
+- A component MUST extract a named component when one part of its JSX contains every JSX expression, callback, and effect that reads one state hook's value or calls its updater.
 
 ## Incorrect — Parent Keeps Child-Only State
 

package/docs/code-organization-guide/rules/types-and-schemas-rule.md

@@ -2,14 +2,15 @@
 
 Types and schemas are easy to bury in component files or scatter across the project. This rule keeps them close to one component and gives independently used ones a consistent location.
 
-- A type or schema used only to implement one configuration object MUST live in that object's `types/` or `schemas/` folder.
-- Except for a type or schema used only to implement one configuration object, a type or schema declared in a component MUST stay in that component file until another file imports it without the component where it is defined. Importing it alongside that component does not trigger extraction.
-- Except for a type or schema used only to implement one configuration object, a type or schema declared outside a component MUST stay with its declaring module until another file imports it independently.
+- A type or schema declared in a component MUST stay in that component file until another file imports it without the component where it is defined.
+- Importing a type or schema alongside the component that defines it MUST NOT require extraction.
+- A type or schema declared outside a component MUST stay in its file until another file needs it without using the code in that file.
 - Extracted types and schemas MUST live in their matching `types/` or `schemas/` folder at the closest common folder (CCF) of their consumers.
-- A `types/` or `schemas/` `index.ts` MAY define its exports directly.
-- Types and schemas that are used together MAY be grouped in a file with a kebab-case name and named-re-exported from `index.ts`.
-- When a `types/` or `schemas/` folder uses grouped files, its `index.ts` MUST only named-re-export those files.
 - When a type or schema's CCF is `src/features/`, it MUST move to `src/types/` or `src/schemas/`.
+- A `types/` or `schemas/` folder MUST either define its exports directly in `index.ts` or group related types and schemas in kebab-case files that `index.ts` named-re-exports.
+- Consumers MUST import an extracted type or schema through the `index.ts` in that type or schema's `types/` or `schemas/` folder.
+- A type or schema used only to implement one configuration module MUST live in that module's `types/` or `schemas/` folder.
+- A type MAY stay in `src/config/<module>/` when its meaning is derived from the configuration that it parameterizes, even when consumers exist outside the config module.
 
 ## Incorrect — Feature and Composition Type Kept in a Feature
 

package/docs/code-organization-guide/rules/utilities-rule.md

@@ -3,13 +3,12 @@
 Pure functions should not be hidden in component files. This rule extracts them to a predictable `utils/` folder and keeps their imports direct.
 
 - A pure function MUST be extracted to `utils/`, even when it has one consumer.
-- A pure function returns the same result for the same arguments and does not read or write external mutable state, perform I/O, or manipulate the DOM.
-- A utility used only to implement one configuration object MUST live in that object's `utils/` folder.
 - An extracted utility MUST live in the `utils/` folder at the closest common folder (CCF) of its consumers.
 - When a utility's CCF is `src/features/`, it MUST move to `src/utils/`.
 - A utility MUST be imported directly without a barrel.
 - A utility file that exports one function MUST have a name in that function's kebab-case form.
 - Utilities that are used together MAY be grouped in a file with a kebab-case name.
+- A utility used only to implement one configuration module MUST live in that module's `utils/` folder.
 
 ## Incorrect — Pure Function Left Beside Its Consumer
 

package/docs/documentation-guide/_templates/grouped-reference.md

@@ -0,0 +1,11 @@
+# [Topic] Reference
+
+[1-2 short sentences naming exactly what readers can look up here and when they should use this reference.]
+
+## [Lookup Block Name]
+
+[1-2 short sentences explaining what this lookup block contains and why it is included.]
+
+[Place this lookup block's content here.]
+
+[Repeat this section for every remaining lookup block.]

package/docs/documentation-guide/_templates/guide.md

@@ -1,6 +1,6 @@
 # [Topic] Guide
 
-[1-2 short sentences explaining the underlying idea behind this guide and why it matters.]
+[1-2 short descriptive sentences explaining this guide's scope, underlying idea, and why it matters.]
 
 ## How To [Workflow]
 

package/docs/documentation-guide/_templates/single-lookup-reference.md

@@ -0,0 +1,5 @@
+# [Topic] Reference
+
+[1-2 short sentences naming exactly what readers can look up here and when they should use this reference.]
+
+[Place the reference's single lookup block here without a heading.]

package/docs/documentation-guide/references/documentation-types-reference.md

@@ -1,9 +1,9 @@
 # Documentation Types Reference
 
-Use this reference to look up the three standard Markdown document kinds in this repository. Their templates are in `docs/documentation-guide/_templates/`.
+Use this reference to look up the three standard Markdown document kinds in this repository.
 
-| Kind      | Shape                                                                                           | Template                                         |
-| --------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------ |
-| Guide     | A workflow-oriented document with one or more `## How To [...]` sections.                       | `guide.md`                                      |
-| Rule      | An opinionated project rule that states required, forbidden, recommended, or optional behavior. | `rule.md`                                       |
-| Reference | Lookup material such as a table, hierarchy, configuration block, glossary, or catalog.          | `reference.md`                                  |
+| Kind      | Shape                                                                                           | Template                                                              |
+| --------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
+| Guide     | A workflow-oriented document with one or more `## How To [...]` sections.                       | `/_templates/guide.md`                                                |
+| Rule      | An opinionated project rule that states required, forbidden, recommended, or optional behavior. | `/_templates/rule.md`                                                 |
+| Reference | Lookup material. A lookup block is one self-contained set of facts for a reader's question. Use the single template for one lookup block and the grouped template for several blocks organized by topic. | `/_templates/single-lookup-reference.md` or `/_templates/grouped-reference.md` |

package/docs/documentation-guide/rules/guide-creation-rule.md

@@ -4,6 +4,7 @@ Guides without a consistent creation process invent their own structure. This ru
 
 - Each How To step MUST be concise and use one sentence.
 - A Guide MAY reference Rules, References, and other Guides.
+- A Guide overview MUST contain one or two short descriptive sentences about the guide's scope and purpose, and MUST NOT contain instructions or links to other documentation.
 - Each How To step MUST link at most one documentation file total, whether that file is a Rule, Reference, or Guide.
 - When a step links a Rule, Reference, or Guide, the step MUST name the concrete decision or result the reader will have after reading it.
 - A step that links another Guide MUST link directly to the relevant How To section.

package/docs/documentation-guide/rules/reference-creation-rule.md

@@ -5,7 +5,7 @@ References without a consistent creation process scatter lookup material. This r
 - Reference file names MUST match the document title in kebab-case and use the `-reference` suffix (e.g., `foo-reference.md`).
 - A Reference MUST NOT link to Rules, Guides, or other References.
 - A Reference MUST NOT use RFC 2119 vocabulary (`MUST`, `MUST NOT`, `SHOULD`, `SHOULD NOT`, `MAY`), because lookup material describes what exists rather than imposing requirements.
-- A Reference document overview and each section overview MUST contain one or two short sentences.
+- A Reference overview and the overview of each headed lookup block MUST contain one or two short sentences.
 - A Reference with a single lookup block MUST NOT add a section heading for it.
 - A Reference with two or more lookup blocks MUST add a section heading for every block, including the first.
 

package/docs/documentation-guide/rules/template-usage-rule.md

@@ -2,9 +2,10 @@
 
 Authoring without a template makes every doc invent its own title, orientation, and section shape. This rule keeps new docs predictable. Templates for each document kind live in `../_templates/`.
 
-- Authors MUST start from the template for the chosen document kind.
+- Authors MUST start from the template that matches the chosen document kind and structure.
 - Authors MUST replace each bracketed prompt with the final title, explanation, step, or lookup content it asks for.
 - Authors MUST delete template branches that do not apply to the document being written.
+- Documentation support assets MAY live in folders whose names start with an underscore.
 
 ## Incorrect — Template Prompts and Unused Branches Kept
 

package/docs/styling-guide/rules/arbitrary-value-rule.md

@@ -0,0 +1,31 @@
+# Arbitrary Value Rule
+
+Literal arbitrary-value classes hide values used for the project's styling in component code. This rule requires every such value to have a named utility or token.
+
+- Components MUST NOT use arbitrary-value classes for project styling. They MUST use an existing Tailwind or project utility, or define a project token or custom utility first.
+
+## Incorrect — Literal Arbitrary Radius
+
+```tsx
+<button className="rounded-[13px]">Save</button>
+```
+
+Why: the design value is hidden in markup and cannot be tracked as part of the project's explicit token set.
+
+## Correct — Named Radius Token
+
+```css
+:root {
+  --radius-md: 0.375rem;
+}
+
+@theme inline {
+  --radius-md: var(--radius-md);
+}
+```
+
+```tsx
+<button className="rounded-md">Save</button>
+```
+
+Why: the named value makes the radius searchable and exposes the matching Tailwind radius utility.

package/docs/styling-guide/rules/class-composition-rule.md

@@ -1,15 +1,12 @@
 # Class Composition Rule
 
-Class conditions and caller overrides need one consistent merge point so ordering stays understandable and conflicting Tailwind utilities resolve correctly.
+`cn` is the project's helper for combining conditional classes and resolving conflicting Tailwind utilities. It gives conditional classes and a passed `className` one predictable merge point.
 
-- Components MUST use `cn` or the project's equivalent class-merging helper for conditional classes and a consumer-provided `className`.
+- Components MUST use `cn` or the project's equivalent class-merging helper for conditional classes and a `className` passed to the component.
 - Components MUST NOT concatenate class strings with template literals or `+` when any part is conditional.
-- A consumer-provided `className` MUST contain only outer-layout utilities: margins, width constraints, permitted height constraints, and flex or grid item placement.
-- Permitted height constraints MUST be limited to `h-full`, `h-auto`, `min-h-*`, and `max-h-*`; fixed component heights MUST use a typed component API or an external wrapper.
-- A consumer-provided `className` MUST NOT change padding, internal gaps, fixed height, colors, typography, borders, radius, shadows, effects, positioning, inset, or z-index.
-- A component MUST expose supported internal appearance and fixed-size choices through typed props rather than consumer classes.
-- Components SHOULD group long static class lists by concern inside `cn`.
-- Components MAY keep a short, fully static `className` string inline.
+- A `className` passed to a component MUST contain only outer-layout utilities: margins, sizing, flex or grid item placement, and `z-index`.
+- A component MUST expose its supported appearance and size variants through typed props, not through a passed `className` or separate class-name props for internal elements.
+- A static class list with more than five class names MUST use `cn` with multiple string literals, each grouped by styling concern and containing no more than five class names.
 
 ## Incorrect — Conditional Classes Concatenated Manually
 
@@ -22,11 +19,34 @@ Why: the condition and merge order are embedded in a string expression, which be
 ## Correct — Conditional Classes Merged with `cn`
 
 ```tsx
-export default function Card({ className, ...props }: CardProps): React.JSX.Element {
-  return <article className={cn("surface-card rounded-lg p-4", className)} {...props} />;
+export function Card({ className, ...props }: CardProps): React.JSX.Element {
+  return <article className={cn("card-surface rounded-lg p-4", className)} {...props} />;
 }
 
 <Card className="w-full max-w-lg self-center" />;
 ```
 
 Why: every class source is explicit, and a consumer can add outer layout such as `w-full max-w-lg self-center` without reconstructing the card's internal treatment.
+
+## Incorrect — Long Static Class Literal
+
+```tsx
+<article className="rounded-lg border border-border bg-card px-6 py-4 shadow-sm transition-shadow hover:shadow-md" />
+```
+
+Why: one static literal contains more than five class names, so its styling concerns are difficult to scan.
+
+## Correct — Static Classes Grouped in `cn`
+
+```tsx
+<article
+  className={cn(
+    "rounded-lg border border-border",
+    "bg-card shadow-sm",
+    "px-6 py-4",
+    "transition-shadow hover:shadow-md",
+  )}
+/>
+```
+
+Why: each literal contains at most five class names and groups one styling concern.

package/docs/styling-guide/rules/component-ui-state-rule.md

@@ -0,0 +1,53 @@
+# Component UI State Rule
+
+Visual state communicates whether a component can be used and what will happen when it is used. This rule keeps that feedback owned by the component rather than reconstructed by every caller.
+
+- A component MUST own a distinguishable appearance for every UI state it supports.
+- A component MUST use Tailwind "state variants" when they can express a supported UI state.
+- Components MUST use native semantic elements and attributes and MUST NOT use custom equivalents.
+
+## Incorrect — State Styled Only with Classes
+
+```tsx
+<Button className={isSaving ? "pointer-events-none opacity-50" : ""}>Save</Button>
+```
+
+Why: every caller has to reconstruct the saving or disabled treatment, and the button does not receive a semantic disabled state.
+
+## Correct — State Exposed Through Component Props
+
+```tsx
+import { cn } from "@/utils/cn";
+
+type ButtonProps = {
+  children: React.ReactNode;
+  disabled?: boolean;
+  loading?: boolean;
+};
+
+export function Button({ children, disabled = false, loading = false }: ButtonProps): React.JSX.Element {
+  const isUnavailable = disabled || loading;
+
+  return (
+    <button
+      aria-busy={loading}
+      className={cn(
+        "rounded px-3",
+        "hover:opacity-90 focus-visible:outline-2",
+        "disabled:cursor-not-allowed disabled:opacity-50",
+        "aria-busy:animate-pulse",
+      )}
+      disabled={isUnavailable}
+      type="button"
+    >
+      {loading ? "Saving…" : children}
+    </button>
+  );
+}
+
+<Button loading={isSaving}>
+  Save
+</Button>
+```
+
+Why: `Button` uses native disabled and ARIA busy attributes with Tailwind state variants, while callers express only loading through its typed API.

package/docs/styling-guide/rules/component-variant-rule.md

@@ -1,14 +1,11 @@
 # Component Variant Rule
 
-When callers choose between a component's visual appearances, the styling definition and TypeScript API need one source of truth. This rule uses CVA for named choices and reserves `cn` for standalone boolean conditions.
+`cva` is Class Variance Authority, a helper for defining a component's visual options and deriving their TypeScript API. `cn` handles a standalone boolean choice without creating a variant matrix.
 
-- A component that lets callers choose between named visual appearances MUST define those choices with `cva`.
-- Component variant prop types MUST be derived with `VariantProps<typeof componentVariants>`.
-- Component props MUST NOT manually duplicate a union already defined by the CVA configuration.
-- A boolean appearance input MUST use conditional `cn()` when it only adds or removes one standalone class treatment.
-- A boolean appearance input MUST use a CVA variant when both boolean values have explicit treatments or when the boolean participates in a compound variant.
-- A component MUST NOT expose separate class-name props for internal elements to vary their appearance.
-- A component MAY expose structured content slots when callers need to provide content rather than alter internal styling.
+- A component that lets callers choose visual options MUST define them with `cva`.
+- A component's variant prop types MUST be derived from its `cva` definition with `VariantProps` rather than manually duplicated unions.
+- A boolean prop that changes appearance MUST use conditional `cn()` when it only adds or removes one standalone class treatment.
+- A boolean prop that changes appearance MUST use a CVA variant when both boolean values have explicit treatments or when the boolean participates in a compound variant.
 
 ## Incorrect — Variant Union Duplicated by Hand
 
@@ -39,8 +36,8 @@ const buttonVariants = cva("inline-flex items-center", {
       lg: "h-11 px-5",
     },
     tone: {
-      primary: "surface-primary",
-      danger: "surface-danger",
+      primary: "primary-surface",
+      danger: "danger-surface",
     },
   },
   defaultVariants: {
@@ -51,78 +48,78 @@ const buttonVariants = cva("inline-flex items-center", {
 
 type ButtonProps = React.ComponentProps<"button"> & VariantProps<typeof buttonVariants>;
 
-export default function Button({ size, tone, className, ...props }: ButtonProps): React.JSX.Element {
+export function Button({ size, tone, className, ...props }: ButtonProps): React.JSX.Element {
   return <button className={cn(buttonVariants({ size, tone }), className)} {...props} />;
 }
 ```
 
 Why: the CVA definition owns the accepted values, defaults, and classes, while `VariantProps` derives the public TypeScript API from the same source.
 
-## Incorrect — Standalone Boolean Added to CVA
+## Incorrect — Standalone Boolean Variant Added to CVA
 
 ```tsx
 const buttonVariants = cva("inline-flex", {
   variants: {
-    loading: {
-      true: "cursor-wait opacity-70",
+    elevated: {
+      true: "shadow-md",
       false: "",
     },
   },
 });
 ```
 
-Why: one boolean merely adds a standalone treatment and has no compound relationship, so CVA adds configuration without a styling matrix.
+Why: one boolean variant merely adds a standalone treatment and has no compound relationship, so CVA adds configuration without a styling matrix.
 
-## Correct — Standalone Boolean Uses `cn`
+## Correct — Standalone Boolean Variant Uses `cn`
 
 ```tsx
-<button className={cn(buttonVariants({ size, tone }), loading && "cursor-wait opacity-70", className)} />
+<button className={cn(buttonVariants({ size, tone }), elevated && "shadow-md", className)} />
 ```
 
-Why: the named appearance choices stay in CVA while the independent boolean remains a direct conditional class.
+Why: the named appearance choices stay in CVA while the independent boolean variant remains a direct conditional class.
 
-## Incorrect — Compound Boolean Styling Split Across Conditions
+## Incorrect — Compound Boolean Variant Styling Split Across Conditions
 
 ```tsx
 <button
   className={cn(
-    buttonVariants({ tone }),
-    loading && "cursor-wait",
-    loading && tone === "primary" && "surface-primary-loading",
-    loading && tone === "danger" && "surface-danger-loading",
+    buttonVariants({ size }),
+    square && "justify-center",
+    square && size === "sm" && "w-8 px-0",
+    square && size === "lg" && "w-11 px-0",
   )}
 />
 ```
 
-Why: the boolean changes treatment according to another variant, but the styling matrix is spread across conditional expressions outside CVA.
+Why: the boolean variant changes treatment according to another variant, but the styling matrix is spread across conditional expressions outside CVA.
 
-## Correct — Boolean with Compound Styling Uses CVA
+## Correct — Boolean Variant with Compound Styling Uses CVA
 
 ```tsx
 const buttonVariants = cva("inline-flex", {
   variants: {
-    tone: {
-      primary: "surface-primary",
-      danger: "surface-danger",
+    size: {
+      sm: "h-8 px-3",
+      lg: "h-11 px-5",
     },
-    loading: {
-      true: "cursor-wait",
-      false: "cursor-default",
+    square: {
+      true: "justify-center",
+      false: "justify-start",
     },
   },
   compoundVariants: [
     {
-      tone: "primary",
-      loading: true,
-      className: "surface-primary-loading",
+      size: "sm",
+      square: true,
+      className: "w-8 px-0",
     },
     {
-      tone: "danger",
-      loading: true,
-      className: "surface-danger-loading",
+      size: "lg",
+      square: true,
+      className: "w-11 px-0",
     },
   ],
 });
 ```
 
-Why: both boolean values have explicit treatment and loading changes by tone, so CVA owns the complete styling matrix.
+Why: both boolean values have explicit treatment and the square appearance changes by size, so CVA owns the complete styling matrix.

package/docs/styling-guide/rules/global-stylesheet-rule.md

@@ -0,0 +1,67 @@
+# Global Stylesheet Rule
+
+Use the global stylesheet to define Tailwind, the shared theme, and base styles. This rule keeps all of the project's global CSS in one entry point and ordered predictably.
+
+- A repository MUST have one global stylesheet entry point that registers Tailwind.
+- The project's global CSS MUST live in the global stylesheet entry point and MUST NOT be imported from another file.
+- The global stylesheet MUST reset Tailwind's default theme with `--*: initial`.
+- Every value used for the project's styling MUST be defined as a CSS variable in `:root`, even when no theme selector overrides it. A Tailwind theme variable MUST reference that CSS variable through `@theme inline`.
+- Style declarations added by the project inside global selectors MUST use `@apply`.
+- The global stylesheet MUST order imports, `@custom-variant` definitions, `:root` variables and the selectors that override them, `@theme` definitions, custom utilities, base styles, and keyframes in that order.
+- The global base layer MUST apply `base-canvas` and `base-ink` to the document body as the default page pair.
+
+## Incorrect — Global Styles Split Across Unrelated Files
+
+```css
+/* globals.css */
+@import "tailwindcss";
+
+@theme {
+  --spacing: 0.25rem;
+}
+
+/* editor.css */
+@import "tailwindcss";
+
+@theme {
+  --font-editor: Georgia, serif;
+}
+```
+
+Why: Tailwind and theme definitions are split across competing global entry points, so neither file clearly owns the system.
+
+## Correct — One Global Stylesheet Owns the System
+
+```css
+@import "tailwindcss";
+
+:root {
+  --spacing: 0.25rem;
+  --base-canvas: #ffffff;
+  --base-ink: #111827;
+}
+
+@theme {
+  --*: initial;
+}
+
+@theme inline {
+  --spacing: var(--spacing);
+}
+
+@utility bg-base-canvas {
+  @apply bg-(--base-canvas);
+}
+
+@utility text-base-ink {
+  @apply text-(--base-ink);
+}
+
+@layer base {
+  body {
+    @apply bg-base-canvas text-base-ink;
+  }
+}
+```
+
+Why: one entry point registers Tailwind, defines the shared system, and applies document defaults in a predictable order.