Contributing

Practical Rules Before Any Change

1. Understand system order before editing layout, rendering, or interaction.
2. Do not break reflection on public types without a clear reason.
3. Validate changes against the current live package or equivalent source-level checks, not only unit tests.
4. When adding a new widget, ship:
   • a clear component API
   • a dedicated plugin
   • messages when needed
   • a runnable demo when the branch currently carries example sources
   • documentation in the README and this book

Docs and Example Placement

• Add new guide pages in both docs/src/en and docs/src/ar.
• Put a new runnable example inside the crate that owns the feature.
• Keep root examples/ only for facade-level integrated demos when such demos are present in the branch.
• Follow the conventions in Editorial Rules.
• Follow Naming Conventions when splitting or renaming internal modules.
• Use Maintainer Map and Architecture Rules before moving ownership boundaries.
• Use Widget Structure Conventions and Layout Engine Boundaries before splitting large subsystems.
• Use Docs Authoring Workflow for the exact bilingual and rustdoc steps.
• Use Docs Review Checklist before merging docs-heavy work.

Code Style Inside The Project

• favor small components and clear systems
• keep visual behavior driven by UNode, UBorder, and UInteractionColors
• avoid surprising side effects outside the intended schedule

Suggested Branch Names

• feat/<name> for features
• fix/<name> for fixes
• docs/<name> for documentation work