Àṣà Ojú Ìbánisọ̀rọ̀

Implement confirmed UI direction in application code. Preserve the project's framework, component system, tokens, and conventions; use accessible primitives rather than rebuilding mature interaction behavior.

Before coding

1. Inspect the actual project, manifests, component conventions, configuration, and current tooling before assuming framework/tool versions or UI libraries. Use the project's own package manager/wrappers and current tool/project documentation rather than cached generic commands.
2. If visual direction is missing, use amoye-ui-ux. When implementation follows a confirmed Amọ̀ye direction, retain the exact direction, controlling evidence, and any material affordance dispositions needed to review the rendered result without reconstructing intent from code. If canonical tokens/specifications are missing or changing materially, use eto-apere.
3. Read component-library decision when the project/user has not already settled the library. Never silently introduce a competing library. When introducing or switching a library materially changes system-wide source ownership, runtime/bundle architecture, compatibility/migration, or long-term integration boundaries, use architect for that technical decision before implementation.
4. For accessibility, component APIs, theming, utility/framework configuration, and version-specific behavior, use the selected library/framework's current official documentation plus current project conventions. Treat current WCAG guidance as the user-facing accessibility baseline; when custom/composed widgets require interaction semantics, use the current WAI-ARIA Authoring Practices (APG) rather than cached framework recipes. Prefer native/library primitives that already satisfy the applicable pattern.

Implementation rules