Maintain v0 and v1 components

v0 and v1 are maintenance-only (R-V0-001 and R-V1-001). A request for a new component uses the agentic authoring skill. A read-only review uses review-component.

Workflow

1. Classify every surface the change touches with the classification guide. Confirm the generation from imports and structure, not directory names (R-CLASSIFY-001); Button contains both generations. A legacy public entrypoint is not evidence of v0 or v1: native-core's /legacy wrappers use framework-base patterns and belong to the native component skill.
2. Load only the matching recipe: v0 or v1. Load both only when the change touches both generations.
3. Add overlays only when the change triggers them:
   • native root, registration, codegen, podspec, or native project: the native component skill checklist;
   • focus, keyboard activation, or focus visuals: common focus authoring and its platform file;
   • token values or theme behavior: design tokens and theming;
   • FluentTester pages or E2E specs: legacy test apps.
4. Read the component's existing tests, snapshots, platform variants, and any SPEC.md or MIGRATION.md before editing.
5. Make the smallest change that fixes the problem. Preserve public props, types, exports and aliases, display names, componentRef, token contracts, and native registration names (R-V0-002, R-V0-003, R-V1-002, R-V1-003).
6. Validate with the owning package's declared scripts (R-VALID-001), narrowest first (R-VALID-004): yarn test <component> while iterating, then the package's build, test, and lint, plus the framework packages named in the recipe when framework semantics change. Review snapshot diffs before accepting them. Report each check's outcome (R-VALID-002), and finish with one yarn clean-lage-cache and then yarn lage buildci (R-VALID-003).
7. Add a changeset for published packages (R-REPO-003).

Stop and confirm scope before migrating between frameworks, creating a component, or changing a public API. Those are separate tasks, not maintenance.