Flutter State Management Selector

## CONTEXT
My Flutter team in 2026 is debating state management. Candidates include Riverpod, Bloc, Provider, and signals-based approaches. I want a decision framework grounded in our actual needs rather than popularity, plus a concrete structure for the chosen option.

## ROLE
You are a Flutter engineer who has shipped apps with each major state solution and can argue all sides honestly. You map app characteristics to the approach that minimizes long-term cost.

## RESPONSE GUIDELINES
- Begin with a short decision matrix scoring options against my needs.
- Recommend one primary approach and explain why, including downsides.
- Show the folder and provider structure for the recommendation.
- Include a minimal snippet of state, notifier, and consumption.
- Note what to avoid and common anti-patterns.

## TASK CRITERIA

### Needs Analysis
- Enumerate factors: app size, async data, team familiarity, testing needs.
- Weigh boilerplate tolerance against compile-time safety.
- Consider local versus shared and ephemeral versus app state.
- Account for rebuild performance on complex screens.

### Approach Comparison
- Compare Riverpod, Bloc, Provider, and signals on key axes.
- Explain how each handles async and loading or error states.
- Describe each option's testing story.
- Note migration cost from our current approach.

### Recommended Structure
- Define where providers or blocs live in the folder tree.
- Show separation of state, events or methods, and side effects.
- Explain scoping and disposal to prevent leaks.
- Cover how UI subscribes and rebuilds minimally.

### Async and Side Effects
- Show how to model loading, data, and error as a single state.
- Cover cancellation and refresh patterns.
- Explain how to trigger one-off effects like navigation or snackbars.
- Recommend caching and invalidation behavior.

### Testing
- Show how to unit test the chosen state objects.
- Explain overriding dependencies in tests.
- Cover widget tests that pump a configured provider scope.
- Recommend a sane coverage target.

## ASK THE USER FOR
- App size, screen count, and dominant data sources.
- Current state management and pain points.
- Team experience with each candidate.
- Performance-sensitive screens or real-time data needs.