In the library checkout, inspect packages/@liquidify/react/src/components/<component>/ for the implementation, specification, stories, and tests. Shared behavior may live outside that folder; trace the relevant import before changing a local wrapper.

Use installed exports and runtime when investigating the website's behavior. The website's vendor snapshot can differ from upstream source even when both show the same version.

Check whether composition or an existing public option already supports the task. If a new API is necessary, specify its default, allowed values, callback behavior, and interaction with controlled state. Compare the change with the repository's API conventions.

For example, a repeated-save report may be an application concurrency issue, a missing loading state, or a component activation bug. Reproduce the event sequence before adding a new prop. Keep network retries and persistence in the application unless an explicit component contract requires otherwise.

Follow the development lifecycle: failing behavioral test, implementation, then aligned specification, stories, and documentation. Use the component checklist to inspect the affected states.

Do not patch website vendor files to implement a library enhancement. Change the owning source and use the project's artifact workflow in a separate library change. A documentation-only correction should describe the currently installed behavior and record an implementation defect separately.

Identify changes to imports, props, defaults, callback ordering, focus, or HTML semantics. Show a small before-and-after consumer example when behavior changes. Report actual check results and any unverified browser or packaging scenario.

Do not describe the enhancement as released until the relevant consumer artifact has been verified.

• the library checkout's docs/api-conventions.md
• Library checkout: packages/@liquidify/react/src/components/
• Migration guide