Change a UI Component Library and Check That Nothing Breaks

## Run Commands from the Repository Root with the Repo's Package Manager Use only the package manager and workspace command style declared by the repository. Run package-scoped operations through the manager's workspace filter from the root instead of changing into package directories and invoking a different tool. Install dependencies only when necessary. Prefer the narrowest package build, test, lint, or type-check command during iteration, and reserve repository-wide builds for integration or release verification. Keep documentation development, package builds, documentation builds, unit tests, browser tests, end-to-end tests, visual regression tests, formatting, linting, and type checking as distinct workflows. ## Keep New Components in the Experimental Area and Internal Packages Private Map the library into its core components, styling system, experimental components, icons or assets, shared utilities, styling-engine abstraction, and unpublished internal packages. Respect which packages are public and which exist only to support the workspace. Introduce new or unstable components in the designated experimental area before promoting them to the stable package. Keep shared styling and theme behavior in the styling layer rather than duplicating it across components. Do not expose internal packages through public entry points or bypass the configured styling-engine abstraction with implementation-specific assumptions. ## Organize Component Files and Import Only What Is Needed Follow the repository's component file layout for implementation, declarations, tests, style classes, and public exports. Keep each responsibility in its owning file so API documentation, tests, and tree-shaking remain predictable. Use the repository's required declaration form for public component properties and export a consistently named property interface from the component module. Preserve path aliases and public export conventions. Use narrow, one-level package imports inside the workspace when broad barrel imports would pull an entire package into a bundle. Treat import shape as a performance and packaging contract, not a style preference. ## Write Error Messages That Say What Happened and How to Fix It Every error thrown from a public package must state what happened, why it matters, and what the caller can do to fix it. Use the required library prefix, readable message construction, and a documentation link when maintained guidance exists. Apply the repository's error-minification marker to supported error constructors so production bundles can replace long messages with stable codes while development remains understandable. After adding or changing a public error, regenerate the error-code catalog. If semantics and argument count are unchanged, update the existing catalog entry rather than creating a new code for the same error contract. ## Test Components the Way Users Click and Type Use the repository's shared renderer and assertion utilities so component tests match the supported environment. Prefer accessible queries and full user interactions over low-level event dispatch or direct property mutation. Test observable behavior, state transitions, warnings, and errors with the configured matchers. Keep unit tests focused, and use name filters while iterating without mistaking a filtered pass for complete coverage. When a test requires layout, browser APIs, or rendering behavior unavailable in a simulated DOM, restrict it to the supported real-browser environment and document the reason in the test condition. ## Turn Off Screenshots Without Turning Off Accessibility Checks Run accessibility analysis inside the established browser regression loop when the repository shares that session. Treat screenshots and accessibility assertions as independent controls: a demo may disable one without implicitly disabling the other. Keep accessibility rule coverage explicit. Record passed, failed, and incomplete results by demo and rule, include applicable accessibility-standard tags, and retain required assertions unless a narrowly justified exception is configured. Do not start a separate browser workflow when the integrated regression harness already owns navigation, rendering, screenshots, and accessibility analysis. ## Order Exception Rules So Skipping One Demo Doesn't Skip Others Match regression configuration against stable demo identifiers. When rules use last-match-wins precedence without inheritance, place narrow overrides after broad rules and restate every field the override intends to keep. Use narrow patterns for individual demos and broader patterns only for a complete component group. A rule that disables a single demo must not accidentally disable its siblings or inherit stale exception fields. Regenerate the structured accessibility and visual outputs after rule changes. Continuous integration should reject stale generated reports rather than silently accepting configuration that was never exercised. ## Test Only Matching Parts While Working, Then Run All Tests Before Pushing Scope local regression runs with the test runner's name filter so nonmatching tests do not navigate browsers or rewrite unrelated output. Confirm the filter matches the route or demo identifier embedded in the test name. Understand that a filtered run refreshes only matched component reports. Before pushing, run the unfiltered regression command so every report, screenshot, and accessibility result is current. Keep the regression server and runner as separate processes when the repository workflow requires it, and preserve the package manager's documented argument-forwarding syntax. ## Regenerate API Docs and Demos After Changing a Component After changing component properties or type declarations, run the property-extraction and API-documentation generators. Review the resulting public API diff together with the source change. Author the designated typed demo as the source of truth and generate alternate language variants through the supported formatter or converter. Do not hand-edit a generated demo variant as the only fix. When demos or Markdown change, run the corresponding demo-generation, documentation build, prose-style, and grammar checks. Keep specialized integration guidance in self-contained local instruction modules and load the relevant one for styling, theming, rendering, or framework integration work. ## Run the Checks the Change Needs and Report Any That Were Skipped Before review, format changed files, run linting and type checking, execute focused unit tests, and expand to real-browser, end-to-end, visual, accessibility, API-documentation, or prose checks according to the affected behavior. Verify generated error codes, API references, demo variants, screenshots, and accessibility reports when their sources changed. Report any blocked or unrun gate instead of presenting partial verification as complete. Keep the review focused on the component and use the repository's required change-title format: a stable component or documentation scope followed by an imperative description.