@uoyo/mvtt 2.0.0-beta.0 → 2.0.0-beta.2

package/sources/knowledge/core/review-principles.md

@@ -1,51 +0,0 @@
-# Code Review Principles
-
-Actionable checklist for reviewing code quality. Use during `#review` and as reference during `#implement`.
-
-## Naming & Readability
-
-- [ ] Classes/functions named by **what they do**, not how they do it
-- [ ] No abbreviations unless universally understood (e.g., `id`, `url`, `http`)
-- [ ] Boolean variables/methods start with `is`, `has`, `can`, `should`
-- [ ] Collections named as plural nouns; single items as singular
-- [ ] No "Manager", "Helper", "Utils" god-classes — split by responsibility
-
-## Single Responsibility
-
-- [ ] Each class/module has **one reason to change**
-- [ ] Functions do **one thing** and are ≤ 30 lines (guideline, not hard rule)
-- [ ] If you need "and" to describe what a function does → split it
-
-## Dependency Direction
-
-- [ ] Business logic does NOT import framework/infrastructure code
-- [ ] Dependencies point **inward** (infrastructure → application → domain)
-- [ ] External services accessed through **interfaces/abstractions**
-- [ ] No circular dependencies between modules
-
-## Error Handling
-
-- [ ] Errors are handled at the **appropriate level** (not swallowed silently)
-- [ ] Fail fast: validate inputs at entry points
-- [ ] No empty catch blocks
-- [ ] Error messages include **context** (what failed, why, what to do)
-
-## Duplication & Abstraction
-
-- [ ] No copy-paste blocks — extract shared logic into functions
-- [ ] But: don't merge similar-looking code that changes for **different reasons**
-- [ ] Abstractions are justified by **current** requirements, not hypothetical ones
-- [ ] No dead code or commented-out blocks
-
-## State & Side Effects
-
-- [ ] Mutable state is **minimized** and localized
-- [ ] Functions clearly indicate whether they have side effects
-- [ ] No hidden global state mutations
-- [ ] Concurrent access to shared state is protected
-
-## Testing Indicators
-
-- [ ] Public API has clear contracts that are testable
-- [ ] Dependencies are injectable (not hard-coded `new`)
-- [ ] No logic in constructors that makes testing difficult

package/sources/knowledge/patterns/clean-architecture/manifest.yaml

@@ -1,66 +0,0 @@
-id: "clean-architecture"
-type: "pattern"
-name: "Clean Architecture"
-version: "1.0"
-description: "Robert C. Martin's Clean Architecture for testable, maintainable systems"
-
-token_estimate:
-  total: 800
-  breakdown:
-    - file: review-checklist.md
-      tokens: 800
-      load_priority: 1
-      summary: "Clean Architecture compliance checklist"
-
-loading_strategy:
-  level_1_manifest_only:
-    tokens: 150
-    use_case: "Check available Clean Architecture patterns"
-
-  level_2_full:
-    tokens: 800
-    use_case: "Complete Clean Architecture review guidance"
-
-loading:
-  priority: 10
-  auto_load: false
-
-files:
-  - path: "review-checklist.md"
-    description: "Checklist for reviewing code against Clean Architecture"
-    required: true
-    tokens: 800
-
-attributes:
-  terminology:
-    entity: "Entity"
-    use_case: "Use Case"
-    interface_adapter: "Interface Adapter"
-    framework: "Framework"
-    boundary: "Boundary"
-    presenter: "Presenter"
-    controller: "Controller"
-    gateway: "Gateway"
-    request_model: "Request Model"
-    response_model: "Response Model"
-    view_model: "View Model"
-
-  checklist:
-    - "Dependencies point inward"
-    - "Entities are pure business objects"
-    - "Use Cases contain application logic"
-    - "Interfaces defined by inner layer"
-    - "Frameworks are details"
-    - "Database is a detail"
-    - "UI is a detail"
-    - "Testable without external dependencies"
-
-scenarios:
-  - name: "Design application architecture"
-    files: ["overview.md"]
-
-  - name: "Code review"
-    files: ["review-checklist.md"]
-
-  - name: "Understand layer separation"
-    files: ["overview.md"]

package/sources/knowledge/patterns/clean-architecture/review-checklist.md

@@ -1,230 +0,0 @@
-# Clean Architecture Review Checklist
-
-Specific review criteria for Clean Architecture implementations.
-
-## The Dependency Rule
-
-### Inward Dependencies
-
-- [ ] Entities have no outward dependencies
-- [ ] Use Cases depend only on Entities
-- [ ] Interface Adapters depend on Use Cases/Entities
-- [ ] Frameworks only depend on Interface Adapters
-
-### No Circular Dependencies
-
-- [ ] Inner layers don't reference outer layers
-- [ ] No imports from outer to inner
-- [ ] Abstractions defined in inner layer
-- [ ] Implementations provided by outer layer
-
----
-
-## Entities Layer
-
-### Purity
-
-- [ ] No framework dependencies
-- [ ] No database annotations
-- [ ] No external library imports
-- [ ] Pure business objects
-
-### Business Rules
-
-- [ ] Critical business rules in entities
-- [ ] Enterprise-wide rules captured
-- [ ] Behavior, not just data
-- [ ] Reusable across applications
-
-### Independence
-
-- [ ] Would exist without application
-- [ ] Not affected by use case changes
-- [ ] Not affected by UI changes
-- [ ] Not affected by database changes
-
----
-
-## Use Cases Layer
-
-### Application Logic
-
-- [ ] Application-specific rules here
-- [ ] Orchestrates entity behavior
-- [ ] Coordinates data flow
-- [ ] Single responsibility per use case
-
-### Interface Definitions
-
-- [ ] Input/Output ports defined here
-- [ ] Repository interfaces defined here
-- [ ] External service interfaces defined here
-- [ ] Inner layer controls contracts
-
-### Data Flow
-
-- [ ] Request models for input
-- [ ] Response models for output
-- [ ] No framework objects cross boundaries
-- [ ] Simple data structures at boundaries
-
----
-
-## Interface Adapters Layer
-
-### Controllers
-
-- [ ] Receives external input
-- [ ] Converts to use case format
-- [ ] No business logic
-- [ ] Thin layer
-
-### Presenters
-
-- [ ] Formats use case output
-- [ ] Creates view models
-- [ ] No business logic
-- [ ] UI-specific formatting only
-
-### Gateways
-
-- [ ] Implements interfaces from use cases
-- [ ] Converts external data formats
-- [ ] Handles external system details
-- [ ] Abstracts infrastructure
-
-### Repository Implementations
-
-- [ ] Implements domain interfaces
-- [ ] Handles persistence details
-- [ ] Converts between domain and persistence models
-- [ ] No business logic
-
----
-
-## Frameworks Layer
-
-### Framework Isolation
-
-- [ ] Framework code contained here
-- [ ] Not leaking into inner layers
-- [ ] Configuration in this layer
-- [ ] Easy to replace framework
-
-### Database
-
-- [ ] Treated as a detail
-- [ ] Repository implementations here
-- [ ] ORM configuration here
-- [ ] No SQL in inner layers
-
-### UI Framework
-
-- [ ] Treated as a detail
-- [ ] Views/components here
-- [ ] Routing configuration here
-- [ ] No UI logic in inner layers
-
----
-
-## Boundary Crossing
-
-### Data Transfer
-
-- [ ] Simple data structures cross boundaries
-- [ ] No entity leakage to outer layers
-- [ ] Request/Response models used
-- [ ] Mapping at boundaries
-
-### Dependency Inversion
-
-- [ ] Inner layer defines interfaces
-- [ ] Outer layer implements
-- [ ] Injection at composition root
-- [ ] No new operator for implementations in inner layers
-
----
-
-## Testability
-
-### Unit Testing
-
-- [ ] Entities testable without mocks
-- [ ] Use cases testable with mock gateways
-- [ ] No framework needed for core tests
-- [ ] Fast execution
-
-### Integration Testing
-
-- [ ] Can test with real implementations
-- [ ] Boundaries make integration clear
-- [ ] External systems mockable
-- [ ] End-to-end scenarios testable
-
----
-
-## Code Organization
-
-### Package/Namespace Structure
-
-- [ ] Clear separation by layer
-- [ ] Consistent naming convention
-- [ ] Easy to locate code
-- [ ] Dependencies visible in imports
-
-### Module Boundaries
-
-- [ ] Modules respect layer boundaries
-- [ ] Inter-module dependencies follow rules
-- [ ] Clear public APIs per module
-- [ ] Internal details hidden
-
----
-
-## Anti-Patterns to Watch
-
-### Dependency Violations
-
-- [ ] No direct database access in use cases
-- [ ] No framework objects in entities
-- [ ] No UI concerns in business logic
-- [ ] No outward dependencies from core
-
-### Bloated Layers
-
-- [ ] Controllers are thin
-- [ ] Use cases are focused
-- [ ] No "god" objects
-- [ ] Single responsibility maintained
-
-### Missing Abstraction
-
-- [ ] External services behind interfaces
-- [ ] Database behind repositories
-- [ ] Third-party libraries wrapped
-- [ ] Detail changes don't affect core
-
----
-
-## Severity Levels
-
-### Critical
-
-- Dependencies point outward (violates core rule)
-- Business logic in controllers/presenters
-- Framework leakage into entities
-- Direct database access in use cases
-
-### Major
-
-- Missing boundary interfaces
-- Use case doing too much
-- Entity with infrastructure concerns
-- Circular dependencies
-
-### Minor
-
-- Inconsistent layer naming
-- Missing mapping at boundary
-- Test depends on framework
-- Response model too complex

package/sources/knowledge/patterns/ddd/manifest.yaml

@@ -1,83 +0,0 @@
-id: "ddd"
-type: "pattern"
-name: "Domain-Driven Design"
-version: "1.0"
-description: "Tactical and strategic patterns for complex domain modeling"
-
-token_estimate:
-  total: 1400
-  breakdown:
-    - file: tactical-patterns.md
-      tokens: 800
-      load_priority: 1
-      summary: "DDD key rules"
-    - file: review-checklist.md
-      tokens: 600
-      load_priority: 2
-      summary: "DDD compliance checklist"
-
-loading_strategy:
-  level_1_overview:
-    description: "Read manifest only for summary"
-    tokens: 150
-    use_case: "Check available DDD patterns"
-
-  level_2_full:
-    description: "Load complete knowledge files"
-    tokens: 1400
-    use_case: "Complete DDD implementation guidance"
-
-loading:
-  priority: 10
-  auto_load: false
-
-files:
-  - path: "tactical-patterns.md"
-    description: "Key rules for DDD building blocks"
-    required: true
-    tokens: 800
-
-  - path: "review-checklist.md"
-    description: "Checklist for reviewing DDD code"
-    required: false
-    tokens: 600
-
-attributes:
-  terminology:
-    aggregate: "Aggregate"
-    aggregate_root: "Aggregate Root"
-    entity: "Entity"
-    value_object: "Value Object"
-    domain_event: "Domain Event"
-    domain_service: "Domain Service"
-    repository: "Repository"
-    factory: "Factory"
-    bounded_context: "Bounded Context"
-    ubiquitous_language: "Ubiquitous Language"
-    context_map: "Context Map"
-    anti_corruption_layer: "Anti-Corruption Layer"
-    shared_kernel: "Shared Kernel"
-    customer_supplier: "Customer-Supplier"
-
-  checklist:
-    - "Aggregate boundaries protect invariants"
-    - "Entities have identity and lifecycle"
-    - "Value objects are immutable"
-    - "Domain events capture state changes"
-    - "Repositories only for aggregates"
-    - "No anemic domain models"
-    - "Business logic in domain layer"
-    - "Ubiquitous language used consistently"
-
-scenarios:
-  - name: "Design domain model"
-    files: ["overview.md", "tactical-patterns.md"]
-
-  - name: "Code review"
-    files: ["review-checklist.md"]
-
-  - name: "Understand DDD concepts"
-    files: ["overview.md"]
-
-  - name: "Event-driven design"
-    files: ["tactical-patterns.md"]

package/sources/knowledge/patterns/ddd/review-checklist.md

@@ -1,226 +0,0 @@
-# DDD Review Checklist
-
-Specific review criteria for Domain-Driven Design implementations.
-
-## Aggregate Design
-
-### Boundaries
-
-- [ ] Aggregate boundaries align with consistency requirements
-- [ ] Aggregates are as small as possible
-- [ ] Cross-aggregate references are by ID, not object reference
-- [ ] Each aggregate can be persisted independently
-
-### Root Entity
-
-- [ ] Only the root is accessible from outside
-- [ ] Root enforces all aggregate invariants
-- [ ] Root controls access to internal entities
-- [ ] External changes go through root methods
-
-### Invariants
-
-- [ ] All business rules enforced within aggregate
-- [ ] Invalid state cannot be created
-- [ ] Invariants checked on every state change
-- [ ] Constructors/factories ensure valid initial state
-
----
-
-## Entity Design
-
-### Identity
-
-- [ ] Entity has clear identity
-- [ ] ID type is appropriate (Guid, long, etc.)
-- [ ] ID generation strategy is defined
-- [ ] Equality based on ID
-
-### Encapsulation
-
-- [ ] Private setters for properties
-- [ ] State changes through methods
-- [ ] No direct collection manipulation
-- [ ] Internal state properly protected
-
-### Behavior
-
-- [ ] Rich behavior, not just data
-- [ ] Methods named using domain language
-- [ ] Business logic in entity, not services
-- [ ] Validation in business methods
-
----
-
-## Value Object Design
-
-### Immutability
-
-- [ ] All properties are readonly
-- [ ] No methods that modify state
-- [ ] "Modification" returns new instance
-- [ ] Thread-safe by design
-
-### Equality
-
-- [ ] Equality based on all attributes
-- [ ] GetHashCode implemented correctly
-- [ ] Equals handles null properly
-- [ ] Consistent with domain semantics
-
-### Validation
-
-- [ ] Validated in constructor
-- [ ] Invalid values throw exceptions
-- [ ] No partial/invalid instances possible
-- [ ] Error messages are meaningful
-
----
-
-## Domain Event Design
-
-### Structure
-
-- [ ] Named in past tense
-- [ ] Contains all relevant context
-- [ ] Immutable after creation
-- [ ] Includes timestamp
-
-### Usage
-
-- [ ] Events raised when significant things happen
-- [ ] Events capture business meaning
-- [ ] Handlers don't modify originating aggregate
-- [ ] Event naming uses ubiquitous language
-
----
-
-## Repository Design
-
-### Interface
-
-- [ ] Interface defined in Domain layer
-- [ ] One repository per aggregate type
-- [ ] Methods use domain language
-- [ ] Returns domain objects, not persistence entities
-
-### Implementation
-
-- [ ] Implementation in Infrastructure layer
-- [ ] Abstract persistence details
-- [ ] Handle concurrency appropriately
-- [ ] Efficient queries for use cases
-
----
-
-## Domain Service Design
-
-### Responsibility
-
-- [ ] Stateless operations only
-- [ ] Clear reason why not in an entity
-- [ ] Named using domain language
-- [ ] Single responsibility
-
-### Dependencies
-
-- [ ] Depends on interfaces, not implementations
-- [ ] Can be injected
-- [ ] Doesn't hold state between calls
-- [ ] Accesses aggregates through repositories
-
----
-
-## Layer Architecture
-
-### Domain Layer
-
-- [ ] Contains entities, value objects, domain services
-- [ ] No dependencies on infrastructure
-- [ ] No framework annotations (if possible)
-- [ ] Pure business logic only
-
-### Application Layer
-
-- [ ] Orchestrates domain objects
-- [ ] Handles transactions
-- [ ] No business logic here
-- [ ] Coordinates between aggregates
-
-### Infrastructure Layer
-
-- [ ] Repository implementations
-- [ ] External service integrations
-- [ ] Framework-specific code
-- [ ] Depends on domain layer
-
----
-
-## Ubiquitous Language
-
-### Naming
-
-- [ ] Code uses domain terminology
-- [ ] Same terms as domain experts
-- [ ] Consistent across codebase
-- [ ] Reflects actual business concepts
-
-### Documentation
-
-- [ ] Domain concepts documented
-- [ ] Glossary maintained
-- [ ] Code comments use domain language
-- [ ] Team understands terminology
-
----
-
-## Anti-Patterns to Watch
-
-### Anemic Domain Model
-
-- [ ] Entities have behavior, not just data
-- [ ] Business logic not in services alone
-- [ ] Domain objects are more than DTOs
-
-### Big Ball of Mud
-
-- [ ] Clear bounded contexts
-- [ ] Explicit boundaries
-- [ ] Context relationships defined
-
-### God Aggregate
-
-- [ ] Aggregates are focused
-- [ ] Not too many entities
-- [ ] Clear consistency needs
-
-### Repository for Non-Aggregates
-
-- [ ] Repositories only for aggregate roots
-- [ ] No repositories for entities within aggregates
-- [ ] No repositories for value objects
-
----
-
-## Severity Levels for DDD Issues
-
-### Critical
-
-- Aggregate boundaries don't protect invariants
-- Business rules can be bypassed
-- Invalid domain state possible
-- Security vulnerabilities through domain bypass
-
-### Major
-
-- Anemic domain model
-- Repository for non-aggregate
-- Business logic in wrong layer
-- Missing domain events for important occurrences
-
-### Minor
-
-- Naming doesn't match ubiquitous language
-- Aggregate slightly too large
-- Value object could be extracted
-- Event naming not in past tense

package/sources/knowledge/patterns/ddd/tactical-patterns.md

@@ -1,12 +0,0 @@
-# DDD Tactical Patterns — Key Rules
-
-Quick reference for key rules when applying DDD.
-
-## Key Rules
-
-1. **One repository per aggregate root** — never for child entities
-2. **Reference other aggregates by ID** — not by object reference
-3. **Keep aggregates small** — only include what must be immediately consistent
-4. **Domain layer has zero infrastructure imports** — dependency inversion
-5. **Events are immutable facts** — include all context needed to understand what happened
-6. **Value Objects validate in constructor** — always valid or not created

package/sources/knowledge/patterns/frontend-react/manifest.yaml

@@ -1,44 +0,0 @@
-id: "frontend-react"
-type: "pattern"
-name: "Frontend (React)"
-version: "1.0"
-description: "Modern React frontend application patterns"
-
-token_estimate:
-  total: 3000
-  breakdown:
-    - file: review-checklist.md
-      tokens: 800
-      load_priority: 3
-      summary: "React code review checklist"
-
-loading_strategy:
-  level_1_manifest_only:
-    tokens: 150
-    use_case: "Check React pattern info"
-
-files:
-  - path: "review-checklist.md"
-    description: "React code review checklist"
-    required: false
-    tokens: 800
-
-scenarios:
-  - name: "Code review"
-    files: ["review-checklist.md"]
-
-applicable_project_types:
-  - web-app
-  - spa
-  - pwa
-
-frameworks:
-  - react
-  - next.js
-  - remix
-  - vite-react
-
-not_recommended_for:
-  - backend-api
-  - cli
-  - library (unless UI library)