Instruction file imported from maxiBon18/runaya_app_flutter (.cursor/rules/project-context.mdc). Copyright stays with the author.

Application Context

Name: project-context
Author: maxiBon18

Project Overview

App description: Flutter mobile application representing a social network for anime lover, cosplayer addicted and every person with passion for anime/manga art that make fan art
Target: Flutter android and Flutter ios
Design: developed in Figma.

Flutter 3.38.5
Dart SDK version: 3.10.4
Android toolchain - develop for Android devices (Android SDK version 36.1.0)
Xcode 26.3
FVM for Flutter version management
Firebase

Use a clean architecture with MVVM design pattern with a feature first approach In the /lib folder there are 2 main type of folder:

core: contain all the general variables, methods and code that can we use in the features code
specific feature contain the specific feature code

Every feature follow this directory pattern:

data
- source
  - DTO -> contains all the concrete DTO implementation for the feature
  - *.dart -> contains concrete implementation of source data interface
- repo
  - source -> contain the interface of source feature
  - DTO -> contain the interface of DTO
  - *.dart -> contains concrete implementation of repository interface
domain
- entities -> contain all the feature entities and entities interface
- services -> contains usecase and services
- repo -> contain the interface of repository feature
application
- viewmodel -> feature viewmodel
- ux:
  - pages -> all the pages of app
  - widgets: -> reusable feature widget
- mixins
- exceptions
- controllers -> used for DI and general controller of feature.
- constants

Application layer depends on domain layer. Domain layer defines repository interfaces. Data layer implements those interfaces. Dependencies always point inward. -> Example code: lib/registration.
Use a clean architecture with feature first approach MVVM design pattern
Now, the backend is Firebase, but we implemented an abstract factory pattern to abstract domain and application layer from the used backend.
- It is important to maintain this abstraction for the future where we will use a custom backend
- Example code: lib/registration.
Don't commit any credential or API keys.
CRITICAL For every dart and flutter command use ALWAYS fvm tool

Code Language: english
Comments language: italian
File naming: snake_case
Class naming: PascalCase
Variable and method naming: camelCase
Private members prefixed with _
Boolean variables/methods use is, has, should, can prefix
Page files: <feature>_page.dart
Widget files: <name>_widget.dart
DTO files: <name>_dto.dart
Entity files: <name>_entity.dart
Every provider in his riverpod file
Use Flutter and dart formatter
No dynamic types unless strictly necessary — prefer strong typing
No as casting without prior is check
No unused imports, variables or parameters
No deprecated API usage
const constructors used wherever possible
final used for variables that are never reassigned
late used only when initialization is guaranteed before access
No hardcoded or magic value, insert in the specific dart file contained in the constants folder.
Use @immutable every where is possible for class
No catchError — prefer try/catch for readability
No unnecessary ! (bang operator) — handle null cases explicitly
No ?. chains longer than 2 levels — extract into variables
Default values provided where null is not a valid state
Nullable return types are intentional and documented

For packages and versions, always refer to pubspec.yaml as the single source of truth