flutter-atomic-components

# Flutter Atomic Components ## Overview The same atomic-design discipline the web app follows applies to Flutter: build a shared component library organized by level and compose screens from it. This keeps the app visually consistent and makes screens small. **Core principle:** Reuse before you build. Before writing any button/card/chip/input/list-row, search the component library — hand-rolling a duplicate is a review-blocking defect. ## The Levels | Level | What | Flutter example | |-------|------|-----------------| | **Atom** | Smallest reusable UI, no app logic | `AppButton`, `AppTextField`, `StatusChip`, `Avatar` | | **Molecule** | A few atoms forming a unit | `TaskCard` (title + chip + avatar), `SearchBar` | | **Organism** | Section built from molecules/atoms | `TaskList`, `BoardColumn`, `AppBarWithActions` | | **Screen** | Route wiring organisms to state | `TaskBoardScreen` | Library lives under `lib/ui/atoms`, `lib/ui/molecules`, `lib/ui/organisms` (follow the app's existing layout if different). ## Rules - **Before creating a component, grep the library.** If an atom exists, use it. If it almost fits, extend it backward-compatibly — don't fork a near-duplicate. - **Place new components at the correct level.** A button is an atom; a card composed of atoms is a molecule. A "component" that fetches data is not a component — split the presentation out. - **Atoms take data + callbacks, never talk to services.** `AppButton({required this.label, required this.onPres...