Initial commit of the Flutter Cursor Generator project, including the core generator tool, project brief schema, example project setup, and CI configuration. Added README documentation outlining repository structure, quick start guide, and detailed descriptions of features and architecture pillars.

This commit is contained in:
2026-05-12 22:29:55 +05:30
commit 6dfb9a8aa5
72 changed files with 4542 additions and 0 deletions
@@ -0,0 +1,53 @@
---
description: "Clean Architecture conventions for {{PROJECT_NAME}}"
alwaysApply: true
---
# Clean Architecture — {{PROJECT_NAME}}
## Layer structure
```
lib/features/[feature]/
├── domain/
│ ├── entities/ ← Pure Dart, no framework imports
│ ├── repositories/ ← Abstract interfaces only
│ └── usecases/ ← Single-responsibility business operations
├── data/
│ ├── datasources/ ← Remote (API) + Local (cache) implementations
│ ├── models/ ← DTOs with fromJson/toJson (can use Freezed)
│ └── repositories/ ← Implements domain/repositories interfaces
└── presentation/
├── bloc/ or notifiers/
├── pages/
└── widgets/
```
## Import rules (STRICTLY ENFORCED by arch-guard hook)
{{ARCH_IMPORT_RULES}}
## UseCase pattern
```dart
// One UseCase = one operation = one method
class GetProductsUseCase {
final ProductRepository _repository;
const GetProductsUseCase(this._repository);
Future<Either<AppError, List<Product>>> call(ProductFilter filter) =>
_repository.getProducts(filter);
}
```
## Entity rules
- Entities are pure Dart — zero Flutter or framework imports
- Entities are immutable — use `final` fields + factory constructors
- Entities NEVER have `fromJson`/`toJson` — that belongs in the data layer model
## Repository rules
- Domain defines the **interface** (abstract class)
- Data layer **implements** it
- Use `Either<Failure, T>` or `Result<T>` return types — never throw in domain
## Dependency injection
- Use `injectable` + `get_it` if `codegen` includes `injectable`
- All UseCases injected into BLoC/Notifier via constructor
- `DataSource → Repository → UseCase → Bloc` dependency direction
@@ -0,0 +1,49 @@
---
description: "Feature-First architecture conventions for {{PROJECT_NAME}}"
alwaysApply: true
---
# Feature-First Architecture — {{PROJECT_NAME}}
## Folder structure
```
lib/
features/
auth/
auth_screen.dart
auth_provider.dart (or auth_bloc.dart)
auth_repository.dart
auth_model.dart
widgets/
login_form.dart
social_login_button.dart
home/
home_screen.dart
home_provider.dart
...
core/
di/ ← Dependency injection setup
network/ ← HTTP client, interceptors
storage/ ← Local storage abstraction
widgets/ ← Shared widgets used by 3+ features
theme/ ← App theme, colors, text styles
routing/ ← Router config
shared/
models/ ← Models shared across features
utils/ ← Pure utility functions
```
## Import rules (STRICTLY ENFORCED by arch-guard hook)
{{ARCH_IMPORT_RULES}}
## Feature isolation rules
- A feature folder is self-contained: its own screen, state, model, repository
- Features MUST NOT import from other feature folders
- Shared code MUST be extracted to `core/` or `shared/` before sharing
- The 3-feature rule: if 3+ features need the same widget → move it to `core/widgets/`
## File naming within a feature
- `[feature]_screen.dart` — the main screen widget
- `[feature]_provider.dart` — Riverpod providers (or `[feature]_bloc.dart`)
- `[feature]_repository.dart` — data fetching + caching
- `[feature]_model.dart` — data model (Freezed or plain Dart)
@@ -0,0 +1,17 @@
---
description: "Layered architecture conventions for {{PROJECT_NAME}}"
alwaysApply: true
---
# Layered Architecture — {{PROJECT_NAME}}
## Layers (top → bottom)
```
Presentation → Service/BLoC → Repository → Data Source
```
## Rules
- Dependencies flow downward only — upper layers depend on lower layers
- Each layer communicates via interfaces (abstract classes)
- Data transformations happen at layer boundaries (DTOs → domain models)
{{ARCH_IMPORT_RULES}}
@@ -0,0 +1,20 @@
---
description: "MVC architecture conventions for {{PROJECT_NAME}}"
alwaysApply: true
---
# MVC Architecture — {{PROJECT_NAME}}
## Layer responsibilities
- **Model**: Data + business logic. Pure Dart.
- **View**: Renders UI, observes Controller state. No business logic.
- **Controller** (GetX): Connects Model ↔ View. Manages state transitions.
## Import rules
{{ARCH_IMPORT_RULES}}
## Controller rules
- Controllers are injected via `Binding`, never created in widgets
- One Controller per feature screen (not per widget)
- Controllers fetch data in `onInit()`, clean up in `onClose()`
- All reactive state marked with `.obs`
@@ -0,0 +1,37 @@
---
description: "MVVM architecture conventions for {{PROJECT_NAME}}"
alwaysApply: true
---
# MVVM Architecture — {{PROJECT_NAME}}
## Layer responsibilities
- **View** (Widget): Renders UI, dispatches user actions to ViewModel. Zero business logic.
- **ViewModel**: Holds UI state, calls Model/Repository, exposes streams/notifiers. Zero Flutter imports.
- **Model**: Plain Dart data structures + repository interfaces.
## Import rules
{{ARCH_IMPORT_RULES}}
## ViewModel rules
```dart
// ViewModel has NO Flutter imports — testable with plain dart test
class AuthViewModel extends ChangeNotifier {
final AuthRepository _repository;
AuthViewModel(this._repository);
AuthViewState _state = const AuthViewState.initial();
AuthViewState get state => _state;
Future<void> login(String email, String password) async {
_state = const AuthViewState.loading();
notifyListeners();
final result = await _repository.login(email, password);
_state = result.fold(
(error) => AuthViewState.error(error.message),
(user) => AuthViewState.success(user),
);
notifyListeners();
}
}
```