seed-api-parity

SEED API parity

seed-component-mapRead only the actual paths found and compare the React and Lynx public surfaces of a single component. Do not create or modify files.

Run

Specify a single component within the repository.

bun skills/seed-api-parity/scripts/api-parity.ts ProgressCircle

Read the result JSON in the following order.

1. sourcesVerify that the implementation, public API, Recipe, Registry, and documentation paths analyzed in are correct.
2. dimensionsCheck both sides' observed values, common values, and reactOnly, lynxOnly, and the evidence paths.
3. platformDifferences.expectedCheck the platform constraints specified in the current Lynx implementation or documentation.
4. platformDifferences.needsReviewDirectly review the values observed on only one side in . possiblyExplainedByReturns expected the possibly relevant ID and both values whose names match that rule.

dimensionspreserves the raw comparison result. needsReviewalso preserves one-sided observed values without omission. possiblyExplainedByDo not remove from the review list even if present. After checking whether the difference can be explained by the difference between the browser DOM and the Lynx native environment, and whether the alternative behavior produces the same user result, determine whether it is unimplemented.

confidenceRead as follows.

• confirmed: Directly verified existence in the current component map.
• partial: Compared by reading the values directly declared in both sources.
• unknown: One side lacks evidence, the component could not be found precisely, or the full surface could not be verified due to inherited types. In this case, reactOnly와 lynxOnlyleave the difference blank without asserting it.

Platform difference determination

The following differences may not be considered feature deficiencies even if there is no API with the same name.

• React의 asChildand when rendering Lynx native elements directly instead of DOM Slot composition
• DOM role과 aria-* when conveying the same meaning and state via accessibility-* native accessibility attributes instead of
• when conveying heading meaning via accessibility-headinginstead of HTML heading level
• browser keyboard focus and focusVisible when using Lynx tap and native accessibility navigation instead of
• when achieving responsive goals via viewport units, JavaScript branching, or separate Recipe values instead of CSS media queries

However, platform constraints do not mean that alternative behaviors may be omitted. Verify that the accessible name, role, and state and the core user results are maintained on both sides. Detailed determination criteria follow React and Lynx platform difference determination criteria.

Task connection

1. First, seed-component-mapverify the exact component name and current surface with .
2. If handling React and Lynx together, run this script.
3. expectedUse only when the constraint has been explicitly verified in the Lynx source or documentation of the current component. possiblyExplainedByis not a determination but a review clue. Read the evidence path and alternative behavior directly.
4. unknown과 needsReviewDo not conclude that it is an omission. Determine after checking the inherited type and alternative behavior.
5. Input the confirmed differences into seed-create-component's platform and deployment surface decisions.

The script does not use the TypeScript compiler. extends, Omit, if you discover a prop inherited from an external type, lower the relevant prop dimension to unknownand leave only the directly confirmed values in both observed values.