@dcrackel/hematournamentui 1.0.707 → 1.0.709

package/AGENTS.md

@@ -1,118 +1,118 @@
-# Agent Guide
-
-This project is `@dcrackel/hematournamentui`, the shared Vue 3 Storybook/UI package for Meyer Squared tournament screens. It owns reusable presentation components, visual structure, Storybook examples, Tailwind styling, and small UI-only state. The consuming admin/frontend app owns routing, API calls, sockets, auth, localStorage, persistence, and tournament workflow orchestration.
-
-## Code Style
-
-- Prefer small, single-use, named functions over long inline blocks.
-- Prefer guard clauses and early returns over `else`.
-- Avoid `else if`. Use named predicate helpers, lookup maps, or dispatch tables when branching by type/status/action.
-- Prefer predicate dispatch tables over large `switch` statements or long conditional chains.
-- Use clear, boring names for important logic. Favor searchable names that describe the component intent or emitted action.
-- Keep comments sparse. Add comments for domain rules, accessibility choices, or non-obvious sequencing behavior, not for code that reads plainly.
-- Preserve existing component props, emitted events, slots, class contracts, and exported component names unless the change intentionally updates the package API.
-- Do not refactor unrelated files while fixing focused bugs or adding focused UI behavior.
-
-## Component Boundary
-
-- Components in this package should stay dumb, reusable, and presentation-focused.
-- App-specific tournament behavior belongs in the consuming frontend, not in this shared UI package.
-- Components should receive data through props and emit user intent upward for the parent to handle.
-- Emit events for parent-owned work such as persistence, API calls, socket messages, navigation, auth-sensitive behavior, and cross-screen workflow rules.
-- Keep local component state only for UI-only behavior, such as folding/unfolding menus, open/closed modal state when locally controlled, transient hover/focus state, input draft display, and similar presentation concerns.
-- Do not add API clients, socket code, localStorage workflow state, or route-level orchestration to this package unless the explicit goal is to create a reusable UI API around those concerns.
-- Clone incoming objects before building emitted payloads when the component may add or reshape UI-specific fields.
-- Do not mutate incoming props or nested prop data. Clone arrays/objects into local UI state before adding UI-only fields such as `Promoted`, `customStatus`, local order, temporary scores, or modal draft state. Emit changed intent upward for the parent to persist.
-- Keep emitted payload shapes stable. If an event contract changes, update the related Storybook examples and consuming documentation.
-
-## Atomic Design
-
-- Follow the existing atomic design structure as much as practical: `Atoms`, `Molecules`, `Organisms`, `Templates`, and `Skeletons`.
-- Put primitive, highly reusable controls in `Atoms`, such as base text, icons, inputs, tags, checkboxes, and radio groups.
-- Put small composed controls in `Molecules`, such as modals, filters, menus, button groups, titled inputs, indicators, and compact UI combinations.
-- Put larger reusable feature sections in `Organisms`, such as cards, containers, headers, forms, grids, complex inputs, wizards, and skeleton loaders.
-- Put page-shaped reusable layouts in `Templates`. Templates may compose many organisms, but should still avoid owning app orchestration, API calls, sockets, routing, or persistence.
-- Before creating a new component, check whether the behavior belongs in an existing atom, molecule, organism, or template instead of adding a near-duplicate.
-- Keep lower-level components generic. Do not make atoms or molecules depend on one tournament workflow when a prop, slot, or emitted event can keep them reusable.
-
-## Interaction Pattern
-
-- Prefer optimistic UI for presentation-only edits: update the visible component state right away, then emit the change upward.
-- Do not optimistically change authoritative workflow fields such as bout status, referee identity, sequence data, or completion timestamps.
-- The parent should perform persistence/API work and pass authoritative data back down through props.
-- Reconcile prop updates cleanly so the component reflects parent-owned truth after save, refresh, or rollback.
-- Do not block simple visual feedback on API completion unless the user action cannot be represented safely before confirmation.
-- Missing or invalid input data should degrade gracefully in the UI instead of crashing a component.
-
-## Vue Patterns
-
-- Use computed fields when derived data can be expressed declaratively.
-- Keep logic out of templates/JSX where practical. Move meaningful conditions, transformations, and class decisions into named computed values or helpers.
-- Keep Vue methods focused. Fetching, transforming, emitting, and local UI state updates should be separable when practical.
-- Prefer explicit `emits` declarations and prop definitions that document component contracts.
-- Keep emitted event names and payload fields aligned through wrapper components. When forwarding child events, use the same semantic event name, such as `penalty:add` for adding and `penalty:update` for updating, instead of compensating with swapped handlers.
-- Use watchers sparingly. Prefer computed values and direct event handlers unless side effects are truly needed.
-- Keep Storybook stories aligned with the public component API and use them to demonstrate meaningful states, variants, empty states, disabled states, and responsive behavior.
-
-## Styling And Layout
-
-- Use Tailwind for layout, spacing, color, state, and responsive design whenever practical.
-- Prefer CSS/Tailwind responsive behavior over JavaScript-driven breakpoints or resize logic.
-- Keep layout behavior stable across mobile and desktop. Avoid text overlap, dynamic content shifting controls, or assumptions about fixed viewport sizes.
-- Preserve existing visual language and component hierarchy before introducing new style patterns.
-- Keep reusable components theme-friendly. Avoid hard-coding app-specific colors or one-off layout assumptions unless the component already owns that visual contract.
-- Prefer accessible native controls and semantic markup where possible.
-
-## Data Ownership
-
-- Treat this package as a UI surface, not an authoritative data owner.
-- The consuming app owns persisted tournament state, live scoring truth, socket freshness, sequence handling, auth, routing, and recovery after reload/reconnect.
-- Scoreboards, cards, tables, menus, and forms in this package should display provided data and emit user intent; they should not invent tournament workflow state.
-- Keep tournament domain rules explicit when they are needed for rendering. Name conditions that depend on pool vs DE, completed vs active, visible vs hidden, or editable vs read-only.
-- If a rule requires backend knowledge or app workflow context, prefer making it a prop or emitted decision rather than embedding the rule in a shared component.
-
-## Pool And Direct Elimination Boundaries
-
-- Pool and Direct Elimination workflows are intentionally different. Confirm the domain rule before reusing assignment behavior between them.
-- Pools may display available directors and emit pool, ring, or pool-work assignment intent. The consuming application persists that intent.
-- Do not change pool assignment behavior while implementing bracket behavior.
-- DE uses one shared collection of available bouts. The signed-in director claims a scheduled bout by selecting or starting it.
-- Bracket components must not accept `directors` or `currentUserId` for assignment behavior.
-- Bracket components must not expose director-selection modals, assignment buttons, or Assigned Bouts sections.
-- The consuming application supplies `RefereeId` and `RefName` from the signed-in user.
-
-## Authoritative Bout Fields
-
-- The consuming application owns `Status`, `RefereeId`, `RefName`, `RingName`, `Seq`, `LastUpdateSeq`, `Ended`, `SubmissionId`, persistence, and socket broadcasts.
-- UI components may display authoritative fields and emit intent, but must not fabricate or authoritatively change them.
-- Clicking a bout must not mark it Active. Submitting presentation data must not mark it Completed or create `Ended`.
-- Closing a modal must not reset a bout to Scheduled or erase scores.
-- Sequence freshness, stale-update rejection, recovery, and broadcast behavior belong in the consuming application.
-
-## Bracket Event Contract
-
-- Scheduled and active bout selections emit `update:directing-bout`.
-- Completed bout selections emit edit intent.
-- BYE and incomplete bouts cannot be directed.
-- List and tableau views must provide equivalent behavior.
-- Do not introduce `assign:director` or `action:assignBout` into bracket components.
-- Before adding a prop or event, search all component consumers and Storybook stories.
-
-## Package Boundary
-
-- `src/index.js` is the package export surface. Keep exports intentional and stable.
-- `src/stories` contains reusable components and their Storybook-facing examples. Follow the existing atoms, molecules, organisms, templates, and skeletons structure.
-- `dist` is generated output. Do not edit it by hand.
-- Ignore `dist` and `node_modules` while searching unless debugging generated package output or dependency internals.
-- Do not add consuming-app-only dependencies to this package for one component. Prefer props, slots, events, or small local helpers.
-
-## Validation
-
-- Run focused lint/build checks after UI changes when practical.
-- Useful commands include `npm run lint`, `npm run build-storybook`, `npm run build:tailwind`, and `npm run test`.
-- For component behavior changes, verify emitted events, optimistic display updates, prop reconciliation, empty states, disabled states, and responsive layout.
-- For public API changes, update Storybook stories and check the consuming app contract.
-- For bracket changes, test scheduled directing, active resume, completed editing, BYE rejection, modal-close state preservation, list/tableau consistency, and the absence of director-assignment UI.
-- Keep Storybook args aligned with component props. Stories should use `{ args: { ... } }`, include required props in every variant, and use correct control types for arrays, objects, booleans, and text.
-- Avoid running package version/publish flows unless explicitly requested. `npm run build` currently patches the package version as part of the script.
-- Use `npm run build:check` for routine package validation without changing the package version.
+# Agent Guide
+
+This project is `@dcrackel/hematournamentui`, the shared Vue 3 Storybook/UI package for Meyer Squared tournament screens. It owns reusable presentation components, visual structure, Storybook examples, Tailwind styling, and small UI-only state. The consuming admin/frontend app owns routing, API calls, sockets, auth, localStorage, persistence, and tournament workflow orchestration.
+
+## Code Style
+
+- Prefer small, single-use, named functions over long inline blocks.
+- Prefer guard clauses and early returns over `else`.
+- Avoid `else if`. Use named predicate helpers, lookup maps, or dispatch tables when branching by type/status/action.
+- Prefer predicate dispatch tables over large `switch` statements or long conditional chains.
+- Use clear, boring names for important logic. Favor searchable names that describe the component intent or emitted action.
+- Keep comments sparse. Add comments for domain rules, accessibility choices, or non-obvious sequencing behavior, not for code that reads plainly.
+- Preserve existing component props, emitted events, slots, class contracts, and exported component names unless the change intentionally updates the package API.
+- Do not refactor unrelated files while fixing focused bugs or adding focused UI behavior.
+
+## Component Boundary
+
+- Components in this package should stay dumb, reusable, and presentation-focused.
+- App-specific tournament behavior belongs in the consuming frontend, not in this shared UI package.
+- Components should receive data through props and emit user intent upward for the parent to handle.
+- Emit events for parent-owned work such as persistence, API calls, socket messages, navigation, auth-sensitive behavior, and cross-screen workflow rules.
+- Keep local component state only for UI-only behavior, such as folding/unfolding menus, open/closed modal state when locally controlled, transient hover/focus state, input draft display, and similar presentation concerns.
+- Do not add API clients, socket code, localStorage workflow state, or route-level orchestration to this package unless the explicit goal is to create a reusable UI API around those concerns.
+- Clone incoming objects before building emitted payloads when the component may add or reshape UI-specific fields.
+- Do not mutate incoming props or nested prop data. Clone arrays/objects into local UI state before adding UI-only fields such as `Promoted`, `customStatus`, local order, temporary scores, or modal draft state. Emit changed intent upward for the parent to persist.
+- Keep emitted payload shapes stable. If an event contract changes, update the related Storybook examples and consuming documentation.
+
+## Atomic Design
+
+- Follow the existing atomic design structure as much as practical: `Atoms`, `Molecules`, `Organisms`, `Templates`, and `Skeletons`.
+- Put primitive, highly reusable controls in `Atoms`, such as base text, icons, inputs, tags, checkboxes, and radio groups.
+- Put small composed controls in `Molecules`, such as modals, filters, menus, button groups, titled inputs, indicators, and compact UI combinations.
+- Put larger reusable feature sections in `Organisms`, such as cards, containers, headers, forms, grids, complex inputs, wizards, and skeleton loaders.
+- Put page-shaped reusable layouts in `Templates`. Templates may compose many organisms, but should still avoid owning app orchestration, API calls, sockets, routing, or persistence.
+- Before creating a new component, check whether the behavior belongs in an existing atom, molecule, organism, or template instead of adding a near-duplicate.
+- Keep lower-level components generic. Do not make atoms or molecules depend on one tournament workflow when a prop, slot, or emitted event can keep them reusable.
+
+## Interaction Pattern
+
+- Prefer optimistic UI for presentation-only edits: update the visible component state right away, then emit the change upward.
+- Do not optimistically change authoritative workflow fields such as bout status, referee identity, sequence data, or completion timestamps.
+- The parent should perform persistence/API work and pass authoritative data back down through props.
+- Reconcile prop updates cleanly so the component reflects parent-owned truth after save, refresh, or rollback.
+- Do not block simple visual feedback on API completion unless the user action cannot be represented safely before confirmation.
+- Missing or invalid input data should degrade gracefully in the UI instead of crashing a component.
+
+## Vue Patterns
+
+- Use computed fields when derived data can be expressed declaratively.
+- Keep logic out of templates/JSX where practical. Move meaningful conditions, transformations, and class decisions into named computed values or helpers.
+- Keep Vue methods focused. Fetching, transforming, emitting, and local UI state updates should be separable when practical.
+- Prefer explicit `emits` declarations and prop definitions that document component contracts.
+- Keep emitted event names and payload fields aligned through wrapper components. When forwarding child events, use the same semantic event name, such as `penalty:add` for adding and `penalty:update` for updating, instead of compensating with swapped handlers.
+- Use watchers sparingly. Prefer computed values and direct event handlers unless side effects are truly needed.
+- Keep Storybook stories aligned with the public component API and use them to demonstrate meaningful states, variants, empty states, disabled states, and responsive behavior.
+
+## Styling And Layout
+
+- Use Tailwind for layout, spacing, color, state, and responsive design whenever practical.
+- Prefer CSS/Tailwind responsive behavior over JavaScript-driven breakpoints or resize logic.
+- Keep layout behavior stable across mobile and desktop. Avoid text overlap, dynamic content shifting controls, or assumptions about fixed viewport sizes.
+- Preserve existing visual language and component hierarchy before introducing new style patterns.
+- Keep reusable components theme-friendly. Avoid hard-coding app-specific colors or one-off layout assumptions unless the component already owns that visual contract.
+- Prefer accessible native controls and semantic markup where possible.
+
+## Data Ownership
+
+- Treat this package as a UI surface, not an authoritative data owner.
+- The consuming app owns persisted tournament state, live scoring truth, socket freshness, sequence handling, auth, routing, and recovery after reload/reconnect.
+- Scoreboards, cards, tables, menus, and forms in this package should display provided data and emit user intent; they should not invent tournament workflow state.
+- Keep tournament domain rules explicit when they are needed for rendering. Name conditions that depend on pool vs DE, completed vs active, visible vs hidden, or editable vs read-only.
+- If a rule requires backend knowledge or app workflow context, prefer making it a prop or emitted decision rather than embedding the rule in a shared component.
+
+## Pool And Direct Elimination Boundaries
+
+- Pool and Direct Elimination workflows are intentionally different. Confirm the domain rule before reusing assignment behavior between them.
+- Pools may display available directors and emit pool, ring, or pool-work assignment intent. The consuming application persists that intent.
+- Do not change pool assignment behavior while implementing bracket behavior.
+- DE uses one shared collection of available bouts. The signed-in director claims a scheduled bout by selecting or starting it.
+- Bracket components must not accept `directors` or `currentUserId` for assignment behavior.
+- Bracket components must not expose director-selection modals, assignment buttons, or Assigned Bouts sections.
+- The consuming application supplies `RefereeId` and `RefName` from the signed-in user.
+
+## Authoritative Bout Fields
+
+- The consuming application owns `Status`, `RefereeId`, `RefName`, `RingName`, `Seq`, `LastUpdateSeq`, `Ended`, `SubmissionId`, persistence, and socket broadcasts.
+- UI components may display authoritative fields and emit intent, but must not fabricate or authoritatively change them.
+- Clicking a bout must not mark it Active. Submitting presentation data must not mark it Completed or create `Ended`.
+- Closing a modal must not reset a bout to Scheduled or erase scores.
+- Sequence freshness, stale-update rejection, recovery, and broadcast behavior belong in the consuming application.
+
+## Bracket Event Contract
+
+- Scheduled and active bout selections emit `update:directing-bout`.
+- Completed bout selections emit edit intent.
+- BYE and incomplete bouts cannot be directed.
+- List and tableau views must provide equivalent behavior.
+- Do not introduce `assign:director` or `action:assignBout` into bracket components.
+- Before adding a prop or event, search all component consumers and Storybook stories.
+
+## Package Boundary
+
+- `src/index.js` is the package export surface. Keep exports intentional and stable.
+- `src/stories` contains reusable components and their Storybook-facing examples. Follow the existing atoms, molecules, organisms, templates, and skeletons structure.
+- `dist` is generated output. Do not edit it by hand.
+- Ignore `dist` and `node_modules` while searching unless debugging generated package output or dependency internals.
+- Do not add consuming-app-only dependencies to this package for one component. Prefer props, slots, events, or small local helpers.
+
+## Validation
+
+- Run focused lint/build checks after UI changes when practical.
+- Useful commands include `npm run lint`, `npm run build-storybook`, `npm run build:tailwind`, and `npm run test`.
+- For component behavior changes, verify emitted events, optimistic display updates, prop reconciliation, empty states, disabled states, and responsive layout.
+- For public API changes, update Storybook stories and check the consuming app contract.
+- For bracket changes, test scheduled directing, active resume, completed editing, BYE rejection, modal-close state preservation, list/tableau consistency, and the absence of director-assignment UI.
+- Keep Storybook args aligned with component props. Stories should use `{ args: { ... } }`, include required props in every variant, and use correct control types for arrays, objects, booleans, and text.
+- Avoid running package version/publish flows unless explicitly requested. `npm run build` currently patches the package version as part of the script.
+- Use `npm run build:check` for routine package validation without changing the package version.

package/README.md

@@ -1,106 +1,132 @@
-# Vue 3 + Vite
-
-This template should help get you started developing with Vue 3 in Vite. The template uses Vue 3 `<script setup>` SFCs, check out the [script setup docs](https://v3.vuejs.org/api/sfc-script-setup.html#sfc-script-setup) to learn more.
-
-## Recommended IDE Setup
-
-- [VS Code](https://code.visualstudio.com/) + [Volar](https://marketplace.visualstudio.com/items?itemName=Vue.volar) (and disable Vetur) + [TypeScript Vue Plugin (Volar)](https://marketplace.visualstudio.com/items?itemName=Vue.vscode-typescript-vue-plugin).
-
-## Publishing a Storybook Library to NPM
-
-Follow this guide to publish your Storybook library to NPM, making it available for others to easily npm install.
-
-## Shared CSS
-
-Build the package stylesheet as a separate step:
-
-```bash
-npm run build:package-css
-```
-
-The generated file is `dist/hematournamentui-tailwind.css`. Consuming apps should import it from the package instead of manually copying `tailwind/output.css`:
-
-```js
-import '@dcrackel/hematournamentui/tailwind.css';
-```
-
-Use `npm run build:tailwind` for Storybook's local `tailwind/output.css` workflow. Use `npm run build:package-css` when preparing CSS for the parent app or package publish.
-
-# 1. Setup & Prerequisites
-
-Ensure you have an account on npm. If not, you can create one for free.
-Verify node and npm installations:
-
-```
-Copy code
-node -v
-npm -v
-```
-
-# 2. Preparing Your Storybook Library
-
-a. Building the Library
-Compile your library with Vite or your bundler:
-
-```
-vite build
-```
-
-b. Update package.json
-Ensure the following fields are set:
-
-name: Name of your package.
-version: Version number.
-main: Main entry file (e.g., dist/index.js).
-files: Files to include, e.g., ["dist"].
-
-# 3. Logging in to NPM
-
-Login to npm (if you haven't already):
-
-```
-npm login
-```
-
-Provide your username, password, and email.
-
-# 4. Publishing to NPM
-
-a. Default (Private Package)
-For scoped private packages (@username/project-name):
-
-```
-npm publish
-```
-
-b. Public Package
-For public packages:
-
-```
-npm publish --access=public
-```
-
-# 5. Verifying Your Package
-
-Check on the npm website to verify your package's publication.
-
-Check the registry name
-
-```
-npm get registry
-```
-
-# 6. Installing and Using the Library
-
-To install the library:
-
-```
-npm install your-library-name
-```
-
-Users can then import and utilize your library's components.
-
-Notes:
-
-Always update the version in package.json before republishing.
-Ensure only necessary files are bundled to prevent package bloat.
+# Vue 3 + Vite
+
+This template should help get you started developing with Vue 3 in Vite. The template uses Vue 3 `<script setup>` SFCs, check out the [script setup docs](https://v3.vuejs.org/api/sfc-script-setup.html#sfc-script-setup) to learn more.
+
+## Recommended IDE Setup
+
+- [VS Code](https://code.visualstudio.com/) + [Volar](https://marketplace.visualstudio.com/items?itemName=Vue.volar) (and disable Vetur) + [TypeScript Vue Plugin (Volar)](https://marketplace.visualstudio.com/items?itemName=Vue.vscode-typescript-vue-plugin).
+
+## Publishing a Storybook Library to NPM
+
+Follow this guide to publish your Storybook library to NPM, making it available for others to easily npm install.
+
+## Shared CSS
+
+Build the package stylesheet as a separate step:
+
+```bash
+npm run build:package-css
+```
+
+The generated file is `dist/hematournamentui-tailwind.css`. Consuming apps should import it from the package instead of manually copying `tailwind/output.css`:
+
+```js
+import '@dcrackel/hematournamentui/tailwind.css';
+```
+
+Use `npm run build:tailwind` for Storybook's local `tailwind/output.css` workflow. Use `npm run build:package-css` when preparing CSS for the parent app or package publish.
+
+## Person profile drafts and Save
+
+`PersonManagement` edits a detached draft and emits `submit:person` with a detached snapshot only when the user saves a valid form. `BaseInput` emits `update:value` synchronously; consumers should debounce their own expensive searches or validation.
+
+```vue
+<PersonManagement
+  :personProfile="person"
+  :saving="saving"
+  :disabled="readOnly"
+  :draftResetKey="profileRevision"
+  @submit:person="savePerson"
+  @update:image="handleDraftImage"
+  @error:image="handleImageError"
+/>
+```
+
+The parent owns API calls, save failures, and authoritative reloads. After a successful reload, supply the refreshed `personProfile` and increment `draftResetKey` in the same update. Selecting a different `PersonId` resets the draft automatically. Updates for the same person preserve unsaved edits until the reset key changes; remounting with a versioned Vue `key` also works.
+
+`saving` and `disabled` disable the form's native controls and prevent new edits and save/delete/merge actions. An upload started earlier may still finish updating the draft. Saving shows accessible busy feedback. Image uploads temporarily disable Save until they finish. Validation failures show a summary across tabs, with links back to the invalid fields' tabs.
+
+Draft `LegalName` and `EmailAddress` take precedence over legacy names and email relations, including explicit empty strings. The library continues emitting `EmailAddress`; the parent maps it to backend `Email` and omits stale `PersonEmails` as required by its API. An explicit `HemaRatingsId: null` displays blank and never falls back to old ratings. Blank ID edits remain blank in the draft; the parent converts them to `null` and normalizes valid positive integer IDs.
+
+Successful uploads update the same draft's `ProfileImage` and emit `update:image` with the URL. That event is a draft notification and should not automatically persist the profile. `ImageCropper` emits successful edits as `update:url`, busy state as `update:uploading`, and failures separately as `error:load` or `error:upload`. `PersonManagement` displays image failures and forwards them as `error:image` with `{ type: 'load' | 'upload', message, url?, status? }`; failures never emit a null image edit.
+
+UI regression tests cover the draft and event contracts. Live backend save/reload checks for email, HR ID changes/clears, first-time profiles, and images remain the consuming application's responsibility; a skipped ratings refresh is separate from profile save success.
+
+# 1. Setup & Prerequisites
+
+Ensure you have an account on npm. If not, you can create one for free.
+Verify node and npm installations:
+
+```
+Copy code
+node -v
+npm -v
+```
+
+# 2. Preparing Your Storybook Library
+
+a. Building the Library
+Compile your library with Vite or your bundler:
+
+```
+vite build
+```
+
+b. Update package.json
+Ensure the following fields are set:
+
+name: Name of your package.
+version: Version number.
+main: Main entry file (e.g., dist/index.js).
+files: Files to include, e.g., ["dist"].
+
+# 3. Logging in to NPM
+
+Login to npm (if you haven't already):
+
+```
+npm login
+```
+
+Provide your username, password, and email.
+
+# 4. Publishing to NPM
+
+a. Default (Private Package)
+For scoped private packages (@username/project-name):
+
+```
+npm publish
+```
+
+b. Public Package
+For public packages:
+
+```
+npm publish --access=public
+```
+
+# 5. Verifying Your Package
+
+Check on the npm website to verify your package's publication.
+
+Check the registry name
+
+```
+npm get registry
+```
+
+# 6. Installing and Using the Library
+
+To install the library:
+
+```
+npm install your-library-name
+```
+
+Users can then import and utilize your library's components.
+
+Notes:
+
+Always update the version in package.json before republishing.
+Ensure only necessary files are bundled to prevent package bloat.