appiq-solution 1.2.0 → 1.3.0

package/#NEW APP PROMPT/accesibility_prompt.md

@@ -0,0 +1,103 @@
+# Accessibility-System für moderne Webseiten
+
+Erstelle ein umfassendes Barrierefreiheits-System für meine Webseite mit folgenden Komponenten und Funktionen:
+
+## 1. Accessibility Provider (Kontext-System)
+
+Implementiere einen React Context Provider mit folgenden Funktionen:
+- Verwaltung der Schriftgröße (80%-150%)
+- Hochkontrast-Modus-Einstellung
+- Einstellung für reduzierte Animation/Bewegung
+- Text-to-Speech-Funktionalität
+- Speicherung der Einstellungen im localStorage
+
+Code-Struktur:
+```jsx
+'use client'
+import { createContext, useState, useEffect, useContext } from 'react'
+
+// Definiere Interface für Einstellungen
+interface AccessibilitySettings {
+  fontSize: number;
+  highContrast: boolean;
+  reducedMotion: boolean;
+  textToSpeechEnabled: boolean;
+}
+
+// Erstelle Kontext mit Funktionen
+const AccessibilityContext = createContext({/* Standardwerte */})
+
+export function AccessibilityProvider({ children }) {
+  // State-Management und Funktionen
+  // Speichern und Laden von Einstellungen
+  // Text-to-Speech-Implementierung
+  
+  return (
+    <AccessibilityContext.Provider value={/* Werte und Funktionen */}>
+      {children}
+    </AccessibilityContext.Provider>
+  )
+}
+
+export const useAccessibility = () => {
+  const context = useContext(AccessibilityContext)
+  if (!context) throw new Error('useAccessibility muss innerhalb eines AccessibilityProviders verwendet werden')
+  return context
+}
+```
+
+## 2. Accessibility Menu UI
+
+Erstelle ein schwebendes Accessibility-Menü mit folgenden Eigenschaften:
+- Positionierung in der unteren linken Ecke des Bildschirms
+- Einstellbares Popup-Menü, das links vom Button erscheint
+- Steuerelemente für alle Barrierefreiheits-Optionen
+- Responsive Design für alle Bildschirmgrößen
+- Animation für sanfte Übergänge
+
+Styling-Anweisungen:
+- Verwende Tailwind CSS für Styling
+- Runde, schwebende Schaltfläche mit Schatten-Effekt
+- Popup mit deutlichem Kontrast zum Hintergrund
+- Klare, lesbare Beschriftungen
+- Ausreichend große Bedienelemente
+
+## 3. Barrierefreie UI-Komponenten
+
+Implementiere folgende barrierefreie Komponenten:
+- AccessibleAccordion: Ausklappbare Inhalte mit Keyboard-Navigation
+- AccessibleImage: Bilder mit Alt-Text und optional Vorlese-Funktion
+- AccessibleTabs: Tab-Navigation mit Keyboard-Unterstützung
+- AccessibleTable: Tabellen mit angemessenen ARIA-Attributen
+- AccessiblePagination: Navigation mit Keyboard-Unterstützung
+- AccessibleTooltip: Barrierefreie Tooltips
+- AccessibleAlert: Benachrichtigungen für Screenreader
+- AccessibleBreadcrumbs: Navigations-Breadcrumbs
+- AccessibleDialog: Modal-Dialoge mit Trap-Focus
+- AccessibleNavigation: Hauptnavigation mit ARIA-Attributen
+- AccessibleForm: Formulare mit geeigneten Labels und Fehlermeldungen
+
+## 4. Integration und Tests
+
+Integration:
+- Binde den AccessibilityProvider im Root-Layout ein
+- Platziere das AccessibilityMenu an geeigneter Stelle
+- Verwende die barrierefreien Komponenten in der gesamten Anwendung
+
+Tests:
+- Teste mit Screenreadern (NVDA, VoiceOver)
+- Überprüfe Keyboard-Navigation
+- Teste auf verschiedenen Geräten und Bildschirmgrößen
+- Führe Kontrast- und Lesbarkeits-Tests durch
+
+## 5. Wichtige Standards und Best Practices
+
+Stelle sicher, dass deine Implementation folgende Standards erfüllt:
+- WCAG 2.1 Level AA
+- Aria-Label und Aria-Attributes
+- Semantic HTML
+- Ausreichende Kontrastverhältnisse
+- Keyboard-Navigation
+- Focus-Management
+
+Verwende die obigen Anweisungen, um ein komplettes Barrierefreiheits-System zu implementieren, das alle Nutzergruppen berücksichtigt und ihnen eine optimale Benutzererfahrung bietet.

package/#NEW APP PROMPT/clean-code.mdc

@@ -0,0 +1,55 @@
+---
+description: Guidelines for writing clean, maintainable, and human-readable code. Apply these rules when writing or reviewing code to ensure consistency and quality.
+globs: 
+---
+# Clean Code Guidelines
+
+## Constants Over Magic Numbers
+- Replace hard-coded values with named constants
+- Use descriptive constant names that explain the value's purpose
+- Keep constants at the top of the file or in a dedicated constants file
+
+## Meaningful Names
+- Variables, functions, and classes should reveal their purpose
+- Names should explain why something exists and how it's used
+- Avoid abbreviations unless they're universally understood
+
+## Smart Comments
+- Don't comment on what the code does - make the code self-documenting
+- Use comments to explain why something is done a certain way
+- Document APIs, complex algorithms, and non-obvious side effects
+
+## Single Responsibility
+- Each function should do exactly one thing
+- Functions should be small and focused
+- If a function needs a comment to explain what it does, it should be split
+
+## DRY (Don't Repeat Yourself)
+- Extract repeated code into reusable functions
+- Share common logic through proper abstraction
+- Maintain single sources of truth
+
+## Clean Structure
+- Keep related code together
+- Organize code in a logical hierarchy
+- Use consistent file and folder naming conventions
+
+## Encapsulation
+- Hide implementation details
+- Expose clear interfaces
+- Move nested conditionals into well-named functions
+
+## Code Quality Maintenance
+- Refactor continuously
+- Fix technical debt early
+- Leave code cleaner than you found it
+
+## Testing
+- Write tests before fixing bugs
+- Keep tests readable and maintainable
+- Test edge cases and error conditions
+
+## Version Control
+- Write clear commit messages
+- Make small, focused commits
+- Use meaningful branch names 

package/#NEW APP PROMPT/codequality.mdc

@@ -0,0 +1,47 @@
+---
+description: Code Quality Guidelines
+globs: 
+---
+# Code Quality Guidelines
+
+## Verify Information
+Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.
+
+## File-by-File Changes
+Make changes file by file and give me a chance to spot mistakes.
+
+## No Apologies
+Never use apologies.
+
+## No Understanding Feedback
+Avoid giving feedback about understanding in comments or documentation.
+
+## No Whitespace Suggestions
+Don't suggest whitespace changes.
+
+## No Summaries
+Don't summarize changes made.
+
+## No Inventions
+Don't invent changes other than what's explicitly requested.
+
+## No Unnecessary Confirmations
+Don't ask for confirmation of information already provided in the context.
+
+## Preserve Existing Code
+Don't remove unrelated code or functionalities. Pay attention to preserving existing structures.
+
+## Single Chunk Edits
+Provide all edits in a single chunk instead of multiple-step instructions or explanations for the same file.
+
+## No Implementation Checks
+Don't ask the user to verify implementations that are visible in the provided context.
+
+## No Unnecessary Updates
+Don't suggest updates or changes to files when there are no actual modifications needed.
+
+## Provide Real File Links
+Always provide links to the real files, not x.md.
+
+## No Current Implementation
+Don't show or discuss the current implementation unless specifically requested.

package/#NEW APP PROMPT/flutter-ai-rules/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Ivanna
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/#NEW APP PROMPT/flutter-ai-rules/README.md

@@ -0,0 +1,104 @@
+# Flutter Rules for Windsurf, Cursor, and Other AI-Powered IDEs
+
+<img src="media/flutter_ai_rules.png" width="500" alt="Flutter Rules for Windsurf, Cursor">
+
+## ⚡ TLDR
+
+Copy the contents of the rule set of your choice (e.g., [combined/flutter_dart__under_6K.md](combined/flutter_dart__under_6K.md)) into your IDE's global or local rules.
+
+## 🚀 Introduction
+
+This repository provides a comprehensive, (almost) non-opinionated collection of Flutter-related rules tailored for use with **Windsurf**, **Cursor**, and other AI-powered IDEs. These rules are designed to improve your development workflow, ensure consistency, and help you get the most out of your AI coding assistant.
+
+## 📁 Repository Structure
+
+- **`rules/`**  
+  Contains individual rule files, each focused on a specific topic or tool (e.g., `bloc.md`, `effective_dart.md`, etc.).  
+  These files are:
+    - Based **only** on official documentation from Flutter, Dart, or relevant package websites.
+    - Categorized by subject to make them easy to mix, match, and reference.
+    - Meant to be refined, adjusted, or extracted based on your project needs.
+
+- **`combined/`**  
+  Contains pre-made, curated sets of rules that combine commonly used topics (e.g., Flutter + Riverpod + Mockito).  
+  These files:
+    - Are kept under **6,000 characters** to comply with **Windsurf's** limit.
+    - Can be used **as-is** by copying them into your global or local rules configuration.
+
+## ✅ How To Use
+
+### Option 1: Use Pre-Made Combined Rules
+
+If you want a quick setup:
+
+1. Browse the [`combined/`](./combined) folder.
+2. Copy a file that suits your project.
+3. Paste it into your IDE's global or local rules config.
+4. You're ready to go.
+
+### Option 2: Use Individual Rule Files
+
+If you prefer more control:
+
+1. Browse the [`rules/`](./rules) folder.
+2. Pick files relevant to your project (e.g., `riverpod.md`, `bloc.md`, etc.).
+3. You can:
+    - **Include** them directly in your IDE setup.
+    - **Reference** them in prompts to add context.
+    - **Extract** only the parts that are useful for your context.
+    - **Include** them partially or fully in a PRD (Product Requirements Document).
+
+<div align="center">
+  <img src="media/mocktail_md_01.png" width="300" alt="Example usage with Mocktail rules">
+  <img src="media/mocktail_md_02.png" width="300" alt="Example usage with Mocktail rules">
+</div>
+
+Everything is modular — use what works best for you.
+
+## 📏 No Opinions, Just Documentation
+
+All rules are sourced from official documentation — no personal preferences or subjective interpretations. That’s intentional. You’re free to alter them to your taste, but this repo keeps things objective by sticking to the source.
+
+Note: This might sometimes lead to contradictory rules (e.g., if one package suggests one folder architecture and another recommends a different one).
+
+## 📌 Use Cases
+
+- Set up global rules for a Flutter project in your IDE.
+- Configure project-specific constraints for popular state management packages.
+- Provide clear expectations in a PDR when working with a team.
+- Extract only what you need to avoid rule clutter.
+
+## 🛠️ Contributing
+
+Contributions are welcome! If you'd like to suggest a new rule or improve an existing one, here’s how you can help:
+
+1. Fork this repository.
+2. Add or modify rules in the appropriate folder.
+3. Submit a pull request with a clear explanation of your changes.  
+   **Make sure to include an official documentation link** for any rule set you’re adding or modifying to keep everything objective and reliable.
+
+## 📚 References
+
+Here are the official sources that have been used to build these rules:
+
+### Flutter
+- [Flutter App Architecture](https://docs.flutter.dev/app-architecture) - Official Flutter architecture guidelines
+- [Flutter Common Errors](https://docs.flutter.dev/testing/common-errors) - Common errors documentation
+- [Flutter ChangeNotifier State Management](https://docs.flutter.dev/data-and-backend/state-mgmt/simple) - Simple state management with ChangeNotifier
+
+### Dart
+- [Effective Dart](https://dart.dev/effective-dart) - Official Dart style guidelines
+- [Dart 3 Updates](https://dart.dev/language) - Documentation on Dart 3 features including:
+  - [Records](https://dart.dev/language/records)
+  - [Patterns](https://dart.dev/language/patterns)
+  - [Pattern Types](https://dart.dev/language/pattern-types)
+  - [Branches](https://dart.dev/language/branches)
+
+### State Management
+- [Bloc Library](https://bloclibrary.dev/) - Official Bloc library documentation
+- [Provider](https://pub.dev/packages/provider) - Official Provider package documentation
+- [Riverpod](https://riverpod.dev/) - Official Riverpod documentation
+
+### Testing
+- [Mockito](https://pub.dev/packages/mockito) - Official Mockito for Dart documentation
+- [Mocktail](https://pub.dev/packages/mocktail) - Official Mocktail documentation

package/#NEW APP PROMPT/flutter-ai-rules/combined/README.md

@@ -0,0 +1,25 @@
+# Combined Rules Character Count
+
+This document contains character counts for all combined rule files.
+
+| File | Character Count |
+|------|----------------|
+| flutter_dart__under_6K.md |     5858 |
+| flutter_dart_bloc_mocktail__under_6K.md |     4751 |
+| flutter_dart_bloc_mocktail.md |    24801 |
+| flutter_dart_change_notifier__under_6K.md |     5553 |
+| flutter_dart_change_notifier.md |    17155 |
+| flutter_dart_provider__under_6K.md |     5681 |
+| flutter_dart_provider.md |    17264 |
+| flutter_dart_riverpod_mockito__under_6K.md |     5635 |
+| flutter_dart_riverpod_mockito.md |    31917 |
+| flutter_dart.md |    14400 |
+| flutter_with_bloc__under_6K.md |     5145 |
+| flutter_with_bloc.md |    22250 |
+| flutter_with_riverpod__under_6K.md |     5779 |
+| flutter_with_riverpod.md |    30379 |
+
+---
+
+**Windsurf limits:** `global_rules.md` and `.windsurfrules` are limited to 6000 characters each. Any content above 6000 characters will be truncated and Cascade will not be aware of them.
+Source: [Windsurf Documentation - Memories](https://docs.windsurf.com/windsurf/memories), accessed Apr 15 2025.

package/#NEW APP PROMPT/flutter-ai-rules/combined/flutter_dart.md

@@ -0,0 +1,192 @@
+# Effective Dart Rules
+
+### Naming Conventions
+1. Use terms consistently throughout your code.
+2. Follow existing mnemonic conventions when naming type parameters (e.g., `E` for element, `K`/`V` for key/value, `T`/`S`/`U` for generic types).
+3. Name types using `UpperCamelCase` (classes, enums, typedefs, type parameters).
+4. Name extensions using `UpperCamelCase`.
+5. Name packages, directories, and source files using `lowercase_with_underscores`.
+6. Name import prefixes using `lowercase_with_underscores`.
+7. Name other identifiers using `lowerCamelCase` (variables, parameters, named parameters).
+8. Capitalize acronyms and abbreviations longer than two letters like words.
+9. Avoid abbreviations unless the abbreviation is more common than the unabbreviated term.
+10. Prefer putting the most descriptive noun last in names.
+11. Consider making code read like a sentence when designing APIs.
+12. Prefer a noun phrase for non-boolean properties or variables.
+13. Prefer a non-imperative verb phrase for boolean properties or variables.
+14. Prefer the positive form for boolean property and variable names.
+15. Consider omitting the verb for named boolean parameters.
+16. Use camelCase for variable and function names.
+17. Use PascalCase for class names.
+18. Use snake_case for file names.
+
+### Types and Functions
+1. Use class modifiers to control if your class can be extended or used as an interface.
+2. Type annotate variables without initializers.
+3. Type annotate fields and top-level variables if the type isn't obvious.
+4. Annotate return types on function declarations.
+5. Annotate parameter types on function declarations.
+6. Write type arguments on generic invocations that aren't inferred.
+7. Annotate with `dynamic` instead of letting inference fail.
+8. Use `Future<void>` as the return type of asynchronous members that do not produce values.
+9. Use getters for operations that conceptually access properties.
+10. Use setters for operations that conceptually change properties.
+11. Use a function declaration to bind a function to a name.
+12. Use inclusive start and exclusive end parameters to accept a range.
+
+### Style
+1. Format your code using `dart format`.
+2. Use curly braces for all flow control statements.
+3. Prefer `final` over `var` when variable values won't change.
+4. Use `const` for compile-time constants.
+
+### Imports & Files
+1. Don't import libraries inside the `src` directory of another package.
+2. Don't allow import paths to reach into or out of `lib`.
+3. Prefer relative import paths within a package.
+4. Don't use `/lib/` or `../` in import paths.
+5. Consider writing a library-level doc comment for library files.
+
+### Structure
+1. Keep files focused on a single responsibility.
+2. Limit file length to maintain readability.
+3. Group related functionality together.
+4. Prefer making fields and top-level variables `final`.
+5. Consider making your constructor `const` if the class supports it.
+6. Prefer making declarations private.
+
+### Usage
+1. Use strings in `part of` directives.
+2. Use adjacent strings to concatenate string literals.
+3. Use collection literals when possible.
+4. Use `whereType()` to filter a collection by type.
+5. Test for `Future<T>` when disambiguating a `FutureOr<T>` whose type argument could be `Object`.
+6. Follow a consistent rule for `var` and `final` on local variables.
+7. Initialize fields at their declaration when possible.
+8. Use initializing formals when possible.
+9. Use `;` instead of `{}` for empty constructor bodies.
+10. Use `rethrow` to rethrow a caught exception.
+11. Override `hashCode` if you override `==`.
+12. Make your `==` operator obey the mathematical rules of equality.
+
+### Documentation
+1. Format comments like sentences.
+2. Use `///` doc comments to document members and types; don't use block comments for documentation.
+3. Prefer writing doc comments for public APIs.
+4. Consider writing doc comments for private APIs.
+5. Consider including explanations of terminology, links, and references in library-level docs.
+6. Start doc comments with a single-sentence summary.
+7. Separate the first sentence of a doc comment into its own paragraph.
+8. Use square brackets in doc comments to refer to in-scope identifiers.
+9. Use prose to explain parameters, return values, and exceptions.
+10. Put doc comments before metadata annotations.
+11. Document why code exists or how it should be used, not just what it does.
+
+### Testing
+1. Write unit tests for business logic.
+2. Write widget tests for UI components.
+3. Aim for good test coverage.
+
+### Widgets
+1. Extract reusable widgets into separate components.
+2. Use `StatelessWidget` when possible.
+3. Keep build methods simple and focused.
+
+### State Management
+1. Choose appropriate state management based on complexity.
+2. Avoid unnecessary `StatefulWidget`s.
+3. Keep state as local as possible.
+
+### Performance
+1. Use `const` constructors when possible.
+2. Avoid expensive operations in build methods.
+3. Implement pagination for large lists.
+
+# Dart 3 Updates
+
+### Branches
+1. Use `if` statements for conditional branching. The condition must evaluate to a boolean.
+2. `if` statements support optional `else` and `else if` clauses for multiple branches.
+3. Use `if-case` statements to match and destructure a value against a single pattern. Example: `if (pair case [int x, int y]) { ... }`
+4. If the pattern in an `if-case` matches, variables defined in the pattern are in scope for that branch.
+5. If the pattern does not match in an `if-case`, control flows to the `else` branch if present.
+6. Use `switch` statements to match a value against multiple patterns (cases). Each `case` can use any kind of pattern.
+7. When a value matches a `case` pattern in a `switch` statement, the case body executes and control jumps to the end of the switch. `break` is not required.
+8. You can end a non-empty `case` clause with `continue`, `throw`, or `return`.
+9. Use `default` or `_` in a `switch` statement to handle unmatched values.
+10. Empty `case` clauses fall through to the next case. Use `break` to prevent fallthrough.
+11. Use `continue` with a label for non-sequential fallthrough between cases.
+12. Use logical-or patterns (e.g., `case a || b`) to share a body or guard between cases.
+13. Use `switch` expressions to produce a value based on matching cases. Syntax differs from statements: omit `case`, use `=>` for bodies, and separate cases with commas.
+14. In `switch` expressions, the default case must use `_` (not `default`).
+15. Dart checks for exhaustiveness in `switch` statements and expressions, reporting a compile-time error if not all possible values are handled.
+16. To ensure exhaustiveness, use a default (`default` or `_`) case, or switch over enums or sealed types.
+17. Use the `sealed` modifier on a class to enable exhaustiveness checking when switching over its subtypes.
+18. Add a guard clause to a `case` using `when` to further constrain when a case matches. Example: `case pattern when condition:`
+19. Guard clauses can be used in `if-case`, `switch` statements, and `switch` expressions. The guard is evaluated after pattern matching.
+20. If a guard clause evaluates to false, execution proceeds to the next case (does not exit the switch).
+
+### Patterns
+1. Patterns are a syntactic category that represent the shape of values for matching and destructuring.
+2. Pattern matching checks if a value has a certain shape, constant, equality, or type.
+3. Pattern destructuring allows extracting parts of a matched value and binding them to variables.
+4. Patterns can be nested, using subpatterns (outer/inner patterns) for recursive matching and destructuring.
+5. Use wildcard patterns (`_`) to ignore parts of a matched value; use rest elements in list patterns to ignore remaining elements.
+6. Patterns can be used in:
+   - Local variable declarations and assignments
+   - For and for-in loops
+   - If-case and switch-case statements
+   - Control flow in collection literals
+7. Pattern variable declarations start with `var` or `final` and bind new variables from the matched value. Example: `var (a, [b, c]) = ('str', [1, 2]);`
+8. Pattern variable assignments destructure a value and assign to existing variables. Example: `(b, a) = (a, b); // swap values`
+9. Every case clause in `switch` and `if-case` contains a pattern. Any kind of pattern can be used in a case.
+10. Case patterns are refutable; if the pattern doesn't match, execution continues to the next case.
+11. Destructured values in a case become local variables scoped to the case body.
+12. Use logical-or patterns (e.g., `case a || b`) to match multiple alternatives in a single case.
+13. Use logical-or patterns with guards (`when`) to share a body or guard between cases.
+14. Guard clauses (`when`) evaluate a condition after matching; if false, execution proceeds to the next case.
+15. Patterns can be used in for and for-in loops to destructure collection elements (e.g., destructuring `MapEntry` in map iteration).
+16. Object patterns match named object types and destructure their data using getters. Example: `var Foo(:one, :two) = myFoo;`
+8. Constant patterns match if the value is equal to a constant (number, string, bool, named constant, const constructor, const collection, etc.). Use parentheses and `const` for complex expressions.
+9. Variable patterns (`var name`, `final Type name`) bind new variables to matched/destructured values. Typed variable patterns only match if the value has the declared type.
+10. Identifier patterns (`foo`, `_`) act as variable or constant patterns depending on context. `_` always acts as a wildcard and matches/discards any value.
+11. Parenthesized patterns (`(subpattern)`) control pattern precedence and grouping, similar to expressions.
+12. List patterns (`[subpattern1, subpattern2]`) match lists and destructure elements by position. The pattern length must match the list unless a rest element is used.
+13. Rest elements (`...`, `...rest`) in list patterns match arbitrary-length lists or collect unmatched elements into a new list.
+14. Map patterns (`{"key": subpattern}`) match maps and destructure by key. Only specified keys are matched; missing keys throw a `StateError`.
+15. Record patterns (`(subpattern1, subpattern2)`, `(x: subpattern1, y: subpattern2)`) match records by shape and destructure positional/named fields. Field names can be omitted if inferred from variable or identifier patterns.
+16. Object patterns (`ClassName(field1: subpattern1, field2: subpattern2)`) match objects by type and destructure using getters. Extra fields in the object are ignored.
+17. Wildcard patterns (`_`, `Type _`) match any value without binding. Useful for ignoring values or type-checking without binding.
+18. All pattern types can be nested and combined for expressive and precise matching and destructuring.
+
+### Records
+1. Records are anonymous, immutable, aggregate types that bundle multiple objects into a single value.
+2. Records are fixed-sized, heterogeneous, and strongly typed. Each field can have a different type.
+3. Records are real values: store them in variables, nest them, pass to/from functions, and use in lists, maps, and sets.
+4. Record expressions use parentheses with comma-delimited positional and/or named fields, e.g. `('first', a: 2, b: true, 'last')`.
+5. Record type annotations use parentheses with comma-delimited types. Named fields use curly braces: `({int a, bool b})`.
+6. The names of named fields are part of the record's type (shape). Records with different named field names have different types.
+7. Positional field names in type annotations are for documentation only and do not affect the record's type.
+8. Record fields are accessed via built-in getters: positional fields as `$1`, `$2`, etc., and named fields by their name (e.g., `.a`).
+9. Records are immutable: fields do not have setters.
+10. Records are structurally typed: the set, types, and names of fields define the record's type (shape).
+11. Two records are equal if they have the same shape and all corresponding field values are equal. Named field order does not affect equality.
+12. Records automatically define `hashCode` and `==` based on structure and field values.
+13. Use records for functions that return multiple values; destructure with pattern matching: `var (name, age) = userInfo(json);`
+14. Destructure named fields with the colon syntax: `final (:name, :age) = userInfo(json);`
+15. Using records for multiple returns is more concise and type-safe than using classes, lists, or maps.
+16. Use lists of records for simple data tuples with the same shape.
+17. Use type aliases (`typedef`) for record types to improve readability and maintainability.
+18. Changing a record type alias does not guarantee all code using it is still type-safe; only classes provide full abstraction/encapsulation.
+19. Extension types can wrap records but do not provide full abstraction or protection.
+20. Records are best for simple, immutable data aggregation; use classes for abstraction, encapsulation, and behavior.
+
+# Common Flutter Errors
+
+1. If you get a "RenderFlex overflowed" error, check if a `Row` or `Column` contains unconstrained widgets. Fix by wrapping children in `Flexible`, `Expanded`, or by setting constraints.
+2. If you get "Vertical viewport was given unbounded height", ensure `ListView` or similar scrollable widgets inside a `Column` have a bounded height (e.g., wrap with `Expanded` or `SizedBox`).
+3. If you get "An InputDecorator...cannot have an unbounded width", constrain the width of widgets like `TextField` using `Expanded`, `SizedBox`, or by placing them in a parent with width constraints.
+4. If you get a "setState called during build" error, do not call `setState` or `showDialog` directly inside the build method. Trigger dialogs or state changes in response to user actions or after the build completes (e.g., using `addPostFrameCallback`).
+5. If you get "The ScrollController is attached to multiple scroll views", make sure each `ScrollController` is only attached to a single scrollable widget at a time.
+6. If you get a "RenderBox was not laid out" error, check for missing or unbounded constraints in your widget tree. This is often caused by using widgets like `ListView` or `Column` without proper size constraints.
+7. Use the Flutter Inspector and review widget constraints to debug layout issues. Refer to the official documentation on constraints if needed.

package/#NEW APP PROMPT/flutter-ai-rules/combined/flutter_dart__under_6K.md

@@ -0,0 +1,99 @@
+# Effective Dart Rules
+
+### Naming Conventions
+1. Use terms consistently throughout your code.
+2. Name types using `UpperCamelCase` (classes, enums, typedefs, type parameters).
+3. Name extensions using `UpperCamelCase`.
+4. Name packages, directories, and source files using `lowercase_with_underscores`.
+5. Name import prefixes using `lowercase_with_underscores`.
+6. Name other identifiers using `lowerCamelCase` (variables, parameters, named parameters).
+7. Capitalize acronyms and abbreviations longer than two letters like words.
+8. Avoid abbreviations unless the abbreviation is more common than the unabbreviated term.
+9. Prefer putting the most descriptive noun last in names.
+10. Prefer a noun phrase for non-boolean properties or variables.
+
+### Types and Functions
+1. Use class modifiers to control if your class can be extended or used as an interface.
+2. Type annotate fields and top-level variables if the type isn't obvious.
+3. Annotate return types on function declarations.
+4. Annotate parameter types on function declarations.
+5. Use `Future<void>` as the return type of asynchronous members that do not produce values.
+6. Use getters for operations that conceptually access properties.
+7. Use setters for operations that conceptually change properties.
+8. Use inclusive start and exclusive end parameters to accept a range.
+
+### Style and Structure
+1. Prefer `final` over `var` when variable values won't change.
+2. Use `const` for compile-time constants.
+3. Keep files focused on a single responsibility.
+4. Limit file length to maintain readability.
+5. Group related functionality together.
+6. Prefer making declarations private.
+
+### Imports & Files
+1. Don't import libraries inside the `src` directory of another package.
+2. Prefer relative import paths within a package.
+3. Don't use `/lib/` or `../` in import paths.
+4. Consider writing a library-level doc comment for library files.
+
+### Usage
+1. Use strings in `part of` directives.
+2. Use adjacent strings to concatenate string literals.
+3. Use collection literals when possible.
+4. Use `whereType()` to filter a collection by type.
+5. Test for `Future<T>` when disambiguating a `FutureOr<T>` whose type argument could be `Object`.
+6. Initialize fields at their declaration when possible.
+7. Use initializing formals when possible.
+8. Use `;` instead of `{}` for empty constructor bodies.
+9. Use `rethrow` to rethrow a caught exception.
+10. Override `hashCode` if you override `==`.
+11. Make your `==` operator obey the mathematical rules of equality.
+
+### Documentation
+1. Use `///` doc comments to document members and types; don't use block comments for documentation.
+2. Prefer writing doc comments for public APIs.
+3. Start doc comments with a single-sentence summary.
+4. Use square brackets in doc comments to refer to in-scope identifiers.
+
+### Flutter Best Practices
+1. Extract reusable widgets into separate components.
+2. Use `StatelessWidget` when possible.
+3. Keep build methods simple and focused.
+4. Avoid unnecessary `StatefulWidget`s.
+5. Keep state as local as possible.
+6. Use `const` constructors when possible.
+7. Avoid expensive operations in build methods.
+8. Implement pagination for large lists.
+
+### Dart 3: Records
+1. Records are anonymous, immutable, aggregate types that bundle multiple objects into a single value.
+2. Records are fixed-sized, heterogeneous, and strongly typed. Each field can have a different type.
+3. Record expressions use parentheses with comma-delimited positional and/or named fields, e.g. `('first', a: 2, b: true, 'last')`.
+4. Record fields are accessed via built-in getters: positional fields as `$1`, `$2`, etc., and named fields by their name (e.g., `.a`).
+5. Records are immutable: fields do not have setters.
+6. Use records for functions that return multiple values; destructure with pattern matching: `var (name, age) = userInfo(json);`
+7. Use type aliases (`typedef`) for record types to improve readability and maintainability.
+8. Records are best for simple, immutable data aggregation; use classes for abstraction, encapsulation, and behavior.
+
+### Dart 3: Patterns
+1. Patterns represent the shape of values for matching and destructuring.
+2. Pattern matching checks if a value has a certain shape, constant, equality, or type.
+3. Pattern destructuring allows extracting parts of a matched value and binding them to variables.
+4. Use wildcard patterns (`_`) to ignore parts of a matched value.
+5. Use rest elements (`...`, `...rest`) in list patterns to match arbitrary-length lists.
+6. Use logical-or patterns (e.g., `case a || b`) to match multiple alternatives in a single case.
+7. Add guard clauses (`when`) to further constrain when a case matches.
+8. Use the `sealed` modifier on a class to enable exhaustiveness checking when switching over its subtypes.
+
+### Common Flutter Errors
+1. If you get a "RenderFlex overflowed" error, check if a `Row` or `Column` contains unconstrained widgets. Fix by wrapping children in `Flexible`, `Expanded`, or by setting constraints.
+2. If you get "Vertical viewport was given unbounded height", ensure `ListView` or similar scrollable widgets inside a `Column` have a bounded height.
+3. If you get "An InputDecorator...cannot have an unbounded width", constrain the width of widgets like `TextField`.
+4. If you get a "setState called during build" error, do not call `setState` or `showDialog` directly inside the build method.
+5. If you get "The ScrollController is attached to multiple scroll views", make sure each `ScrollController` is only attached to a single scrollable widget.
+6. If you get a "RenderBox was not laid out" error, check for missing or unbounded constraints in your widget tree.
+7. Use the Flutter Inspector and review widget constraints to debug layout issues.
+
+### Testing
+1. Write unit tests for business logic.
+2. Write widget tests for UI components.