categorize-task

Categorize Task

Classify development tasks into the 8-phase clean architecture structure. This helps organize work into the correct architectural layer.

Purpose

Provide a reference guide for determining which architectural phase (Foundational → Models → Services → Data → Rules → State Management → UI → Tests) a development task belongs to.

The 8 Phases

Tasks must be classified into one of these sequential phases:

Phase 1: Foundational

Purpose: Abstract classes, base setup, toolings, utilities, infrastructure

Belongs here if the task involves:

• Setting up base infrastructure
• Creating abstract classes or interfaces
• Configuring tooling or build setup
• Dependency injection framework
• Environment configuration
• Shared utilities and helpers
• Project scaffolding

Examples:

• "Set up dependency injection container"
• "Create base repository interface"
• "Configure environment variables"
• "Add logging utility"
• "Set up project structure"

---

Phase 2: Models

Purpose: Entities, models, JSON classes, data structures

Belongs here if the task involves:

• Defining a data structure
• Creating an entity or model class
• Data serialization/deserialization
• DTOs (Data Transfer Objects)
• Value objects
• Enums and constants

Examples:

• "Create User model with fields"
• "Define Product entity"
• "Add OrderStatus enum"
• "Create UserDTO for API responses"
• "Define Address value object"

---

Phase 3: Services

Purpose: APIs, external services, network layer

Belongs here if the task involves:

• Calling an external API
• Integrating with a third-party service
• Network communication
• REST/GraphQL clients
• HTTP/networking layer
• API error handling

Examples:

• "Implement authentication API client"
• "Create payment service integration"
• "Add REST API endpoints for products"
• "Integrate with Stripe API"
• "Implement GraphQL query client"

---

Phase 4: Data

Purpose: Repositories, DAOs, data access layer, local storage

Belongs here if the task involves:

• Accessing local storage
• Implementing a repository
• Data persistence or caching
• Database access objects
• Local storage (SQLite, SharedPreferences, etc.)
• Cache implementations

Examples:

• "Implement UserRepository"
• "Create ProductDAO for database access"
• "Add local cache for API responses"
• "Implement SQLite database schema"
• "Create data source abstraction"

---

Phase 5: Rules

Purpose: Use cases, business rules, domain logic

Belongs here if the task involves:

• Business logic or validation
• Use case or workflow
• Domain-specific rules
• Business workflows
• Domain event handlers
• Complex validation rules

Examples:

• "Implement login use case"
• "Add business validation for orders"
• "Create checkout workflow"
• "Implement password strength validator"
• "Add discount calculation logic"

---

Phase 6: State Management

Purpose: View models, presenters, state handlers, controllers

Belongs here if the task involves:

• Managing application state
• View models or presenters
• State transitions
• State management setup (Bloc, Provider, Riverpod, Redux, etc.)
• Controllers
• Reactive state handling

Examples:

• "Create LoginViewModel"
• "Implement ProductListBloc"
• "Add state management for cart"
• "Create AuthenticationCubit"
• "Implement Redux store for user data"

---

Phase 7: UI

Purpose: Widgets, components, screens, views, user interface

Belongs here if the task involves:

• Screens, pages, or components
• User interface rendering
• User interaction handling
• Navigation setup
• Layouts and styling
• Visual elements

Examples:

• "Create login screen"
• "Build product card component"
• "Implement navigation flow"
• "Add loading spinner widget"
• "Create responsive layout for dashboard"

---

Phase 8: Tests

Purpose: Unit tests, integration tests, e2e tests, test utilities, test fixtures

Belongs here if the task involves:

• Writing unit tests for business logic or services
• Creating integration tests across layers
• Building end-to-end test scenarios
• Setting up test utilities, mocks, or fixtures
• Configuring test infrastructure (test runners, coverage tools)
• Writing test helpers or shared test data

Examples:

• "Write unit tests for login use case"
• "Add integration tests for checkout flow"
• "Create e2e tests for authentication"
• "Set up mock repository for testing"
• "Add test fixtures for product data"

---

Classification Process

To classify a task, ask these questions in order:

1. Is it foundation/infrastructure? → Phase 1
2. Is it defining data structures? → Phase 2
3. Does it call external APIs? → Phase 3
4. Does it access local data/storage? → Phase 4
5. Is it business logic/rules? → Phase 5
6. Does it manage application state? → Phase 6
7. Is it user interface? → Phase 7
8. Does it write tests or test utilities? → Phase 8

Clean Architecture Principle

Remember: Dependencies flow inward

Tests → UI → State Management → Rules → Data → Services → Models → Foundational

• Outer layers depend on inner layers
• Inner layers never depend on outer layers
• Each phase can only depend on phases that come before it

Quick Reference Table

If the task creates...	Phase
Abstract base classes, utilities	1 - Foundational
Data models, entities, DTOs	2 - Models
API clients, external integrations	3 - Services
Repositories, DAOs, local storage	4 - Data
Use cases, business rules	5 - Rules
ViewModels, Blocs, state handlers	6 - State Management
Screens, widgets, components	7 - UI
Unit tests, integration tests, e2e tests	8 - Tests

Complex Task Classification

Some tasks may span multiple phases. In these cases:

1. Break the task down into sub-tasks for each phase
2. Create separate tasks for each phase
3. Maintain phase order - implement foundation before UI

Example: "Implement user authentication"

• Phase 1: Create base auth interfaces
• Phase 2: Define User and Token models
• Phase 3: Implement auth API client
• Phase 4: Create auth token repository
• Phase 5: Create login/logout use cases
• Phase 6: Build AuthenticationBloc/ViewModel
• Phase 7: Create login/signup screens
• Phase 8: Write unit and integration tests for auth flow

Edge Cases

Configuration files: Phase 1 (Foundational) if infrastructure, Phase 7 (UI) if theme/styling

Validation: Phase 5 (Rules) if business validation, Phase 6 (State Management) if form state validation

Error handling: Goes with the phase where the error occurs

Testing: Always Phase 8 (Tests), regardless of which phase the tested code belongs to

Documentation: Same phase as the feature being documented

When in Doubt

If you're unsure between two phases:

1. Consider the primary responsibility of the code
2. Think about dependencies - what does this code depend on?
3. Ask: "Where does this fit in the dependency flow?"
4. Choose the earlier phase when truly ambiguous (favor inner layers)

Usage Example

Task: "Add user profile picture upload"

Classification:

• Primary responsibility: UI interaction (file picker, display)
• Depends on: API service, data storage, business rules
• This is primarily about user interface

Result: Phase 7 (UI) - but may require supporting tasks in earlier phases:

• Phase 3: API endpoint for upload
• Phase 4: Save profile picture URL locally
• Phase 5: Validate image size/format