maestro-bundle 1.3.0 → 1.4.0

package/templates/bundle-jhipster-monorepo/skills/ddd-tactical/SKILL.md

@@ -1,13 +1,32 @@
 ---
 name: ddd-tactical
-description: Implementar padrões táticos do DDD - Entities, Value Objects, Aggregates, Domain Events, Repositories e Domain Services. Use quando for modelar domínio, criar entidades ricas, ou aplicar DDD no código.
+description: Implement DDD tactical patterns -- Entities, Value Objects, Aggregates, Domain Events, Repositories, and Domain Services. Use when modeling domain, creating rich entities, defining aggregates, or applying DDD patterns.
+version: 1.0.0
+author: Maestro
 ---
 
-# DDD Tático
+# DDD Tactical Patterns
 
-## Value Objects
+Implement Domain-Driven Design tactical patterns including Entities, Value Objects, Aggregates, Domain Events, Repositories, and Domain Services.
 
-Imutáveis, comparados por valor, contêm validação.
+## When to Use
+- When modeling domain entities with rich behavior
+- When creating value objects for validated types
+- When defining aggregate boundaries and invariants
+- When implementing domain events for cross-aggregate communication
+- When business logic spans multiple entities (Domain Services)
+
+## Available Operations
+1. Create Value Objects with validation
+2. Create Entities with identity and behavior
+3. Define Aggregates with invariant protection
+4. Implement Domain Events
+5. Create Domain Services for cross-entity logic
+
+## Multi-Step Workflow
+
+### Step 1: Identify Value Objects
+Value Objects are immutable, compared by value, and contain self-validation.
 
 ```python
 @dataclass(frozen=True)
@@ -24,7 +43,7 @@ class ComplianceScore:
 
     def __post_init__(self):
         if not 0 <= self.value <= 100:
-            raise ValueError("Score deve ser entre 0 e 100")
+            raise ValueError("Score must be between 0 and 100")
 
     def is_passing(self) -> bool:
         return self.value >= 80.0
@@ -33,9 +52,8 @@ class ComplianceScore:
         return f"{self.value:.1f}%"
 ```
 
-## Entities
-
-Identidade única, mutáveis, contêm comportamento.
+### Step 2: Create Entities
+Entities have unique identity, are mutable, and contain behavior.
 
 ```python
 class Task:
@@ -66,31 +84,29 @@ class Task:
         return None
 ```
 
-## Aggregates
-
-Cluster de entities com uma raiz que protege invariantes.
+### Step 3: Define Aggregates
+An Aggregate is a cluster of entities with a root that protects invariants.
 
 ```python
 class Demand:  # Aggregate Root
-    """Demand é a raiz. Tasks só são acessadas via Demand."""
+    """Demand is the root. Tasks are only accessed via Demand."""
 
     def add_task(self, task: Task) -> None:
         if len(self._tasks) >= 20:
-            raise TooManyTasksException("Máximo 20 tasks por demanda")
+            raise TooManyTasksException("Maximum 20 tasks per demand")
         self._tasks.append(task)
 
     def start_task(self, task_id: TaskId) -> None:
         task = self._find_task(task_id)
-        # Verificar invariante: não ter mais de 3 tasks simultâneas
+        # Invariant: no more than 3 concurrent tasks
         active = [t for t in self._tasks if t.status == TaskStatus.IN_PROGRESS]
         if len(active) >= 3:
             raise TooManyActiveTasksException()
         task.start()
 ```
 
-## Domain Events
-
-Notificam que algo aconteceu no domínio.
+### Step 4: Implement Domain Events
+Domain Events notify that something happened in the domain.
 
 ```python
 @dataclass(frozen=True)
@@ -112,9 +128,8 @@ class ComplianceViolationDetected(DomainEvent):
     severity: str  # "warning" | "critical"
 ```
 
-## Domain Services
-
-Lógica que não pertence a uma única entidade.
+### Step 5: Create Domain Services
+For logic that does not belong to a single entity.
 
 ```python
 class TeamRecruitmentService:
@@ -130,9 +145,63 @@ class TeamRecruitmentService:
         return team
 ```
 
-## Ordem de prioridade para regras
+### Step 6: Write Tests for Domain Logic
+
+```bash
+# Run domain unit tests (no infrastructure dependencies)
+pytest tests/domain/ -v
+
+# For Java/JUnit
+./mvnw test -Dtest="*DomainTest,*ValueObjectTest"
+```
+
+```python
+class TestComplianceScore:
+    def test_passing_score(self):
+        score = ComplianceScore(85.0)
+        assert score.is_passing() is True
+
+    def test_invalid_score_raises(self):
+        with pytest.raises(ValueError):
+            ComplianceScore(150.0)
+```
 
-1. **Value Object** — validação e comportamento simples
-2. **Entity** — regras que envolvem estado da entidade
-3. **Domain Service** — regras que envolvem múltiplas entidades
-4. **Use Case** — orquestração (NÃO contém regras)
+## Resources
+- `references/ddd-patterns.md` - DDD pattern decision guide and examples
+
+## Examples
+### Example 1: Create a Value Object
+User asks: "Create a value object for email validation"
+Response approach:
+1. Create immutable dataclass/record with validation in constructor
+2. Add behavior methods (e.g., `domain()`, `is_corporate()`)
+3. Ensure equality by value, not reference
+4. Write unit tests for valid and invalid cases
+
+### Example 2: Define an Aggregate
+User asks: "Model a Demand that contains Tasks with business rules"
+Response approach:
+1. Make Demand the Aggregate Root
+2. Tasks are only accessed through Demand methods
+3. Add invariants: max tasks, max concurrent, completion rules
+4. Emit domain events on state changes
+5. Write tests for each invariant
+
+### Example 3: Implement a Domain Service
+User asks: "I need logic that involves both Demands and Agents"
+Response approach:
+1. Create a Domain Service (not a generic "Service")
+2. Accept entities as parameters, not IDs
+3. Implement the cross-entity logic
+4. Return results, let the use case persist
+5. Write tests with test doubles for entities
+
+## Notes
+- Priority for placing business rules:
+  1. **Value Object** -- validation and simple behavior
+  2. **Entity** -- rules involving entity state
+  3. **Domain Service** -- rules involving multiple entities
+  4. **Use Case** -- orchestration only (NO business rules)
+- Aggregates should be small -- prefer separate aggregates connected by ID
+- Domain Events are immutable records of what happened
+- Domain layer must have zero framework dependencies

package/templates/bundle-jhipster-monorepo/skills/ddd-tactical/references/ddd-patterns.md

@@ -0,0 +1,48 @@
+# DDD Tactical Patterns Reference
+
+## Decision Guide: Where to Put Business Logic
+
+| Pattern | When to Use | Example |
+|---|---|---|
+| Value Object | Validation, simple behavior, no identity | Email, Money, ComplianceScore |
+| Entity | Has identity, mutable state, behavior | Task, Agent, Demand |
+| Aggregate | Cluster with invariants, transactional boundary | Demand (root) + Tasks (children) |
+| Domain Event | Notify something happened | TaskCompleted, DemandCreated |
+| Domain Service | Logic spanning multiple entities | TeamRecruitmentService |
+| Repository (Port) | Persistence abstraction | DemandRepository (interface) |
+
+## Value Object Checklist
+- [ ] Immutable (frozen dataclass / Java record)
+- [ ] Validated in constructor
+- [ ] Compared by value, not reference
+- [ ] Contains behavior methods
+- [ ] No identity field
+
+## Entity Checklist
+- [ ] Has unique identity (ID)
+- [ ] Mutable state with controlled transitions
+- [ ] Contains behavior (not anemic)
+- [ ] State changes enforce invariants
+- [ ] Compared by identity, not value
+
+## Aggregate Checklist
+- [ ] Has a single root entity
+- [ ] Children accessed only through root
+- [ ] Invariants enforced by root
+- [ ] Small boundary (prefer separate aggregates)
+- [ ] Cross-aggregate references by ID only
+- [ ] One aggregate per transaction
+
+## Domain Event Checklist
+- [ ] Immutable (record/frozen dataclass)
+- [ ] Contains occurred_at timestamp
+- [ ] Named in past tense (TaskCompleted, not CompleteTask)
+- [ ] Contains only IDs and primitives (no entity references)
+- [ ] Published after aggregate state change
+
+## Domain Service Checklist
+- [ ] Logic involves multiple aggregates
+- [ ] Stateless (no internal state)
+- [ ] Named after the operation (TeamRecruitmentService)
+- [ ] Accepts entities as parameters
+- [ ] Does not persist (caller persists)

package/templates/bundle-jhipster-monorepo/skills/jhipster-angular/SKILL.md

@@ -1,48 +1,57 @@
 ---
 name: jhipster-angular
-description: Desenvolver frontend Angular no JHipster com componentes, services, routing e formulários reativos. Use quando precisar criar telas, componentes Angular, ou customizar o frontend JHipster.
+description: Develop Angular frontend in JHipster with components, services, routing, and reactive forms. Use when creating screens, customizing Angular components, adding filters, or building dashboards.
+version: 1.0.0
+author: Maestro
 ---
 
 # JHipster Angular
 
-## Estrutura gerada pelo JHipster
+Develop and customize the Angular frontend generated by JHipster, including components, services, reactive forms, and custom pages.
+
+## When to Use
+- When creating new Angular components or pages
+- When customizing JHipster-generated CRUD screens
+- When adding filters, sorting, or pagination to lists
+- When building dashboards or custom views
+- When working with reactive forms and validation
+
+## Available Operations
+1. Customize generated CRUD components
+2. Create new standalone components
+3. Add reactive forms with validation
+4. Create Angular services for API calls
+5. Configure routing with lazy loading
+
+## Multi-Step Workflow
+
+### Step 1: Understand the Generated Structure
 
 ```
 src/main/webapp/app/
-├── entities/                    # CRUD gerado por entidade
-│   ├── demand/
-│   │   ├── demand.model.ts
-│   │   ├── demand.routes.ts
-│   │   ├── service/
-│   │   │   └── demand.service.ts
-│   │   ├── list/
-│   │   │   └── demand.component.ts
-│   │   ├── detail/
-│   │   │   └── demand-detail.component.ts
-│   │   ├── update/
-│   │   │   └── demand-update.component.ts
-│   │   └── delete/
-│   │       └── demand-delete-dialog.component.ts
-│   └── task/
-├── shared/                     # Componentes compartilhados
-│   ├── date/
-│   ├── filter/
-│   ├── pagination/
-│   └── sort/
-├── core/                       # Services core
-│   ├── auth/
-│   ├── interceptor/
-│   └── util/
-├── layouts/                    # Layouts de página
-│   ├── main/
-│   ├── navbar/
-│   └── footer/
-└── config/
+  entities/               # Generated CRUD per entity
+    demand/
+      demand.model.ts
+      demand.routes.ts
+      service/demand.service.ts
+      list/demand.component.ts
+      detail/demand-detail.component.ts
+      update/demand-update.component.ts
+      delete/demand-delete-dialog.component.ts
+  shared/                 # Shared components
+  core/                   # Core services (auth, interceptors)
+  layouts/                # Page layouts (navbar, footer)
+  config/                 # App configuration
 ```
 
-## Customizar componentes gerados
+```bash
+# Explore the generated structure
+ls src/main/webapp/app/entities/
+ls src/main/webapp/app/shared/
+```
 
-O JHipster gera CRUD básico. Customizar SEM modificar a estrutura gerada:
+### Step 2: Customize Generated Components
+Add filters and custom behavior WITHOUT breaking the generated structure:
 
 ```typescript
 // entities/demand/list/demand.component.ts
@@ -56,7 +65,7 @@ export class DemandComponent implements OnInit {
   demands?: IDemand[];
   isLoading = false;
 
-  // ADICIONAR — filtros customizados
+  // ADD -- custom filters
   statusFilter: DemandStatus | null = null;
   priorityFilter: Priority | null = null;
 
@@ -67,7 +76,7 @@ export class DemandComponent implements OnInit {
     protected sortService: SortService,
   ) {}
 
-  // ADICIONAR — método de filtro
+  // ADD -- filter method
   filterByStatus(status: DemandStatus): void {
     this.statusFilter = status;
     this.loadDemands();
@@ -94,7 +103,7 @@ export class DemandComponent implements OnInit {
 }
 ```
 
-## Criar componentes novos (fora do CRUD gerado)
+### Step 3: Create New Components (Outside Generated CRUD)
 
 ```typescript
 // dashboard/dashboard.component.ts
@@ -112,16 +121,8 @@ export class DemandComponent implements OnInit {
         </div>
       </div>
     </div>
-    <div class="row mt-4">
-      <div class="col-md-8">
-        <app-agent-activity-feed />
-      </div>
-      <div class="col-md-4">
-        <app-active-demands />
-      </div>
-    </div>
   `,
-  imports: [CommonModule, AgentActivityFeedComponent, ActiveDemandsComponent],
+  imports: [CommonModule],
 })
 export class DashboardComponent implements OnInit {
   metrics: Metric[] = [];
@@ -134,7 +135,7 @@ export class DashboardComponent implements OnInit {
 }
 ```
 
-## Reactive Forms com validação
+### Step 4: Add Reactive Forms with Validation
 
 ```typescript
 @Component({...})
@@ -157,10 +158,56 @@ export class DemandUpdateComponent {
 }
 ```
 
-## Regras
+### Step 5: Build and Verify
+
+```bash
+# Run Angular dev server
+npm start
+
+# Run Angular tests
+npm test
+
+# Run lint
+npm run lint
+
+# Build for production
+npm run build
+```
 
-- Não modificar `navbar.component.ts` diretamente — usar menus configuráveis
-- Usar `SharedModule` para imports comuns
-- Lazy loading para todas as rotas de entidades
-- Usar `TranslateService` do JHipster para i18n
-- Manter compatibilidade com regeneração: marcar customizações claramente
+## Resources
+- `references/angular-structure.md` - JHipster Angular project structure and conventions
+
+## Examples
+### Example 1: Add Status Filter to Entity List
+User asks: "Add a status filter to the demands list"
+Response approach:
+1. Open `entities/demand/list/demand.component.ts`
+2. Add `statusFilter` property and `filterByStatus()` method
+3. Update the template to include filter buttons/dropdown
+4. Pass filter as query param to `demandService.query()`
+5. Run `npm test` to verify
+
+### Example 2: Create a Dashboard Page
+User asks: "Create a dashboard showing key metrics"
+Response approach:
+1. Create `dashboard/` directory under `app/`
+2. Create `dashboard.component.ts` with standalone component
+3. Create `dashboard.service.ts` to fetch metrics from API
+4. Add route in app routing with lazy loading
+5. Run `npm start` to verify
+
+### Example 3: Add Form Validation
+User asks: "Add validation to the demand creation form"
+Response approach:
+1. Open `entities/demand/update/demand-update.component.ts`
+2. Add validators to FormGroup controls
+3. Add error messages in the template
+4. Test validation behavior
+5. Run `npm test`
+
+## Notes
+- Do not modify `navbar.component.ts` directly -- use configurable menus
+- Use `SharedModule` for common imports
+- Use lazy loading for all entity routes
+- Use JHipster's `TranslateService` for i18n
+- Mark customizations clearly to maintain compatibility with regeneration

package/templates/bundle-jhipster-monorepo/skills/jhipster-angular/references/angular-structure.md

@@ -0,0 +1,59 @@
+# JHipster Angular Structure Reference
+
+## Directory Layout
+```
+src/main/webapp/app/
+  entities/                    # Generated CRUD per entity
+    <entity>/
+      <entity>.model.ts        # TypeScript interface
+      <entity>.routes.ts       # Lazy-loaded routes
+      service/<entity>.service.ts
+      list/<entity>.component.ts
+      detail/<entity>-detail.component.ts
+      update/<entity>-update.component.ts
+      delete/<entity>-delete-dialog.component.ts
+  shared/                      # Shared modules and components
+    date/                      # Date utilities
+    filter/                    # Filter components
+    pagination/                # Pagination components
+    sort/                      # Sort directives
+  core/                        # Core services
+    auth/                      # Authentication
+    interceptor/               # HTTP interceptors
+    util/                      # Utility services
+  layouts/                     # Page layouts
+    main/                      # Main layout
+    navbar/                    # Navigation bar
+    footer/                    # Footer
+  config/                      # App configuration
+```
+
+## Key Conventions
+- All components are `standalone: true`
+- Use `SharedModule` for common imports
+- Lazy loading for entity routes
+- JHipster's `TranslateService` for i18n
+- `AlertService` for user notifications
+- `SortDirective` and `SortByDirective` for table sorting
+- `PaginationComponent` for paginated lists
+
+## Service Pattern
+```typescript
+@Injectable({ providedIn: 'root' })
+export class EntityService {
+  private resourceUrl = 'api/entities';
+
+  constructor(private http: HttpClient) {}
+
+  query(req?: any): Observable<HttpResponse<IEntity[]>> {
+    const options = createRequestOption(req);
+    return this.http.get<IEntity[]>(this.resourceUrl, { params: options, observe: 'response' });
+  }
+}
+```
+
+## Custom Component Best Practices
+- Place custom components outside `entities/` to avoid regeneration conflicts
+- Mark any changes to generated files with `// CUSTOM` comments
+- Use standalone components with explicit imports
+- Follow JHipster naming: `jhi-` prefix for entity components