Follow the project’s established architecture

Follow the project’s established architecture

Inspect local conventions before adding public API, state management, abstractions or configuration.

Read analysis_options.yaml, pubspec.yaml and neighboring code first. Keep the existing state-management approach; use state_beacon_flutter and context_plus only where that is the established choice. Organize code by feature/domain, use one public class per file with a matching snake_case name, and export intended package API from the appropriate barrel. Never hardcode values as a workaround for behavior that should be computed, injected or configured. Avoid speculative abstractions, feature flags and future-proofing outside the requested scope. Use single quotes, multiline trailing commas and the project's formatter configuration (normally 120 columns). Document touched public classes and package API with concise /// comments, explaining non-obvious reasons and referencing [paramName] or [ClassName], not @param / @return. Run relevant formatting, analysis and behavior tests, review the diff, and report actual validation and limitations. Clarify missing information or consequential ambiguity before making dependent decisions. This reminder accompanies new or changed public class declarations; it does not claim the declaration violates any of these conventions.

Detection scope

This is a contextual review reminder, not proof of a violation. Explicit user instructions and applicable repository conventions take precedence.