maestro-bundle 1.8.0 → 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,50 +1,50 @@
1
1
  # Product Requirements Document (PRD)
2
2
 
3
- > Este documento define os requisitos do produto. Deve ser preenchido pelo analista de requisitos e/ou pelo dev antes de iniciar o desenvolvimento. O agente AI usa este documento como contexto para entender O QUE construir.
3
+ > This document defines the product requirements. It should be filled out by the requirements analyst and/or the developer before starting development. The AI agent uses this document as context to understand WHAT to build.
4
4
 
5
- ## 1. Resumo Executivo
5
+ ## 1. Executive Summary
6
6
 
7
- <!-- Descreva em 2-3 frases o que é o produto e qual problema resolve -->
7
+ <!-- Describe in 2-3 sentences what the product is and what problem it solves -->
8
8
 
9
- ## 2. Usuários Alvo
9
+ ## 2. Target Users
10
10
 
11
- <!-- Quem vai usar o sistema? Descreva as personas -->
11
+ <!-- Who will use the system? Describe the personas -->
12
12
 
13
- ### Persona 1: [Nome]
14
- - **Perfil:**
15
- - **Objetivos:**
16
- - **Dores:**
13
+ ### Persona 1: [Name]
14
+ - **Profile:**
15
+ - **Goals:**
16
+ - **Pain points:**
17
17
 
18
- ## 3. Escopo do MVP
18
+ ## 3. MVP Scope
19
19
 
20
- ### Incluído no MVP
20
+ ### Included in MVP
21
21
  - [ ] Feature 1
22
22
  - [ ] Feature 2
23
23
  - [ ] Feature 3
24
24
 
25
- ### Fora do MVP (futuro)
26
- - [ ] Feature futura 1
27
- - [ ] Feature futura 2
25
+ ### Out of MVP (future)
26
+ - [ ] Future feature 1
27
+ - [ ] Future feature 2
28
28
 
29
29
  ## 4. User Stories
30
30
 
31
- ### US01: [Título]
32
- **Como** [persona], **quero** [ação], **para** [benefício].
31
+ ### US01: [Title]
32
+ **As** [persona], **I want** [action], **so that** [benefit].
33
33
 
34
- **Critérios de aceite:**
35
- - [ ] CA1:
36
- - [ ] CA2:
34
+ **Acceptance criteria:**
35
+ - [ ] AC1:
36
+ - [ ] AC2:
37
37
 
38
- ### US02: [Título]
39
- **Como** [persona], **quero** [ação], **para** [benefício].
38
+ ### US02: [Title]
39
+ **As** [persona], **I want** [action], **so that** [benefit].
40
40
 
41
- **Critérios de aceite:**
42
- - [ ] CA1:
43
- - [ ] CA2:
41
+ **Acceptance criteria:**
42
+ - [ ] AC1:
43
+ - [ ] AC2:
44
44
 
45
- ## 5. Arquitetura de Alto Nível
45
+ ## 5. High-Level Architecture
46
46
 
47
- <!-- Diagrama em Mermaid ou ASCII mostrando os componentes principais -->
47
+ <!-- Mermaid or ASCII diagram showing the main components -->
48
48
 
49
49
  ```mermaid
50
50
  graph LR
@@ -52,7 +52,7 @@ graph LR
52
52
  B --> C[Database]
53
53
  ```
54
54
 
55
- ### Estrutura de Diretórios
55
+ ### Directory Structure
56
56
 
57
57
  ```
58
58
  project/
@@ -61,29 +61,29 @@ project/
61
61
  └── ...
62
62
  ```
63
63
 
64
- ## 6. Features Detalhadas
64
+ ## 6. Detailed Features
65
65
 
66
- ### Feature 1: [Nome]
67
- - **Descrição:**
68
- - **Regras de negócio:**
66
+ ### Feature 1: [Name]
67
+ - **Description:**
68
+ - **Business rules:**
69
69
  -
70
70
  - **Inputs:**
71
71
  - **Outputs:**
72
72
  - **Edge cases:**
73
73
  -
74
74
 
75
- ### Feature 2: [Nome]
76
- - **Descrição:**
77
- - **Regras de negócio:**
75
+ ### Feature 2: [Name]
76
+ - **Description:**
77
+ - **Business rules:**
78
78
  -
79
79
 
80
- ## 7. Stack Tecnológica
80
+ ## 7. Technology Stack
81
81
 
82
- | Componente | Tecnologia | Justificativa |
82
+ | Component | Technology | Justification |
83
83
  |---|---|---|
84
84
  | Backend | | |
85
85
  | Frontend | | |
86
- | Banco de dados | | |
86
+ | Database | | |
87
87
  | Cache | | |
88
88
  | Deploy | | |
89
89
 
@@ -92,7 +92,7 @@ project/
92
92
  ### Endpoints
93
93
 
94
94
  #### `GET /api/v1/resource`
95
- - **Descrição:**
95
+ - **Description:**
96
96
  - **Response:** `200 OK`
97
97
  ```json
98
98
  {
@@ -104,7 +104,7 @@ project/
104
104
  ```
105
105
 
106
106
  #### `POST /api/v1/resource`
107
- - **Descrição:**
107
+ - **Description:**
108
108
  - **Body:**
109
109
  ```json
110
110
  {
@@ -113,7 +113,7 @@ project/
113
113
  ```
114
114
  - **Response:** `201 Created`
115
115
 
116
- ## 9. Modelo de Dados
116
+ ## 9. Data Model
117
117
 
118
118
  ```sql
119
119
  CREATE TABLE example (
@@ -123,39 +123,39 @@ CREATE TABLE example (
123
123
  );
124
124
  ```
125
125
 
126
- ## 10. Requisitos Não-Funcionais
126
+ ## 10. Non-Functional Requirements
127
127
 
128
- | Requisito | Alvo | Prioridade |
128
+ | Requirement | Target | Priority |
129
129
  |---|---|---|
130
- | Performance | Response time < 500ms | Alta |
131
- | Disponibilidade | 99.9% uptime | Média |
132
- | Segurança | OWASP Top 10 | Alta |
133
- | Escalabilidade | Até X usuários simultâneos | Média |
130
+ | Performance | Response time < 500ms | High |
131
+ | Availability | 99.9% uptime | Medium |
132
+ | Security | OWASP Top 10 | High |
133
+ | Scalability | Up to X simultaneous users | Medium |
134
134
 
135
- ## 11. Fases de Implementação
135
+ ## 11. Implementation Phases
136
136
 
137
- ### Fase 1: Foundation
138
- - [ ] Setup do projeto
139
- - [ ] Modelo de dados
140
- - [ ] Endpoints básicos
137
+ ### Phase 1: Foundation
138
+ - [ ] Project setup
139
+ - [ ] Data model
140
+ - [ ] Basic endpoints
141
141
 
142
- ### Fase 2: Core Features
143
- - [ ] Feature 1 completa
144
- - [ ] Feature 2 completa
142
+ ### Phase 2: Core Features
143
+ - [ ] Feature 1 complete
144
+ - [ ] Feature 2 complete
145
145
 
146
- ### Fase 3: Polish
147
- - [ ] Testes E2E
146
+ ### Phase 3: Polish
147
+ - [ ] E2E tests
148
148
  - [ ] Performance
149
- - [ ] Documentação
149
+ - [ ] Documentation
150
150
 
151
- ## 12. Riscos e Mitigações
151
+ ## 12. Risks and Mitigations
152
152
 
153
- | Risco | Impacto | Probabilidade | Mitigação |
153
+ | Risk | Impact | Probability | Mitigation |
154
154
  |---|---|---|---|
155
155
  | | | | |
156
156
 
157
- ## 13. Critérios de Sucesso
157
+ ## 13. Success Criteria
158
158
 
159
- - [ ] Critério 1
160
- - [ ] Critério 2
161
- - [ ] Critério 3
159
+ - [ ] Criterion 1
160
+ - [ ] Criterion 2
161
+ - [ ] Criterion 3
@@ -1,32 +1,32 @@
1
- # Constitution — Projeto JHipster Monorepo
1
+ # Constitution — JHipster Monorepo Project
2
2
 
3
- ## Princípios
3
+ ## Principles
4
4
 
5
- 1. **Spec primeiro, código depois** — Toda demanda passa pelo fluxo SDD antes de implementação
6
- 2. **JDL como fonte de verdade** — Modelo de entidades definido em JDL, código gerado pelo JHipster
7
- 3. **Enriquecer, não substituir** — Entidades geradas pelo JHipster são enriquecidas com DDD, não reescritas do zero
8
- 4. **Migrations versionadas** — Toda mudança de schema via Liquibase changeset, nunca manual
9
- 5. **DTO na fronteira** — Nunca expor entidade JPA na API REST
5
+ 1. **Spec first, code later** — Every demand goes through the SDD flow before implementation
6
+ 2. **JDL as source of truth** — Entity model defined in JDL, code generated by JHipster
7
+ 3. **Enrich, don't replace** — Entities generated by JHipster are enriched with DDD, not rewritten from scratch
8
+ 4. **Versioned migrations** — Every schema change via Liquibase changeset, never manual
9
+ 5. **DTO at the boundary** — Never expose JPA entities in the REST API
10
10
 
11
- ## Padrões de desenvolvimento
11
+ ## Development Standards
12
12
 
13
13
  ### Java / Spring Boot
14
- - Java 21+, Records para DTOs
15
- - Constructor injection (nunca @Autowired em campo)
16
- - @Transactional apenas no Service
17
- - Entidades com comportamento rico (não anêmicas)
18
- - MapStruct para conversão Entity DTO
14
+ - Java 21+, Records for DTOs
15
+ - Constructor injection (never @Autowired on fields)
16
+ - @Transactional only on Services
17
+ - Entities with rich behavior (not anemic)
18
+ - MapStruct for Entity <-> DTO conversion
19
19
 
20
20
  ### Angular
21
21
  - Standalone components (Angular 17+)
22
- - Lazy loading por rota
23
- - Reactive Forms com validação
24
- - Services para chamadas HTTP
22
+ - Lazy loading per route
23
+ - Reactive Forms with validation
24
+ - Services for HTTP calls
25
25
 
26
- ## Padrões de qualidade
26
+ ## Quality Standards
27
27
 
28
- - Cobertura mínima: 80%
29
- - JUnit 5 + Mockito para backend
30
- - Jest + Cypress para frontend
31
- - Code review obrigatório
32
- - Commits seguem Conventional Commits
28
+ - Minimum coverage: 80%
29
+ - JUnit 5 + Mockito for backend
30
+ - Jest + Cypress for frontend
31
+ - Code review mandatory
32
+ - Commits follow Conventional Commits
@@ -1,51 +1,51 @@
1
- # Projeto: JHipster Monorepo
1
+ # Project: JHipster Monorepo
2
2
 
3
- Você está construindo uma aplicação monolítica com JHipster. Backend em Java/Spring Boot, frontend em Angular, banco PostgreSQL, tudo em um único repositório.
3
+ You are building a monolithic application with JHipster. Backend in Java/Spring Boot, frontend in Angular, PostgreSQL database, all in a single repository.
4
4
 
5
5
  ## Specification-Driven Development (SDD)
6
6
 
7
- A regra fundamental de SDD está definida no bundle-base (AGENTS.md base) e é inegociável:
8
- **Sem spec, sem código. Sem exceção.** O agente deve recusar implementar qualquer demanda que
9
- não tenha passado pelo fluxo `/speckit.specify` → `/speckit.plan` → `/speckit.tasks` → `/speckit.implement`.
7
+ The fundamental SDD rule is defined in the bundle-base (base AGENTS.md) and is non-negotiable:
8
+ **No spec, no code. No exception.** The agent must refuse to implement any demand that
9
+ has not gone through the `/speckit.specify` → `/speckit.plan` → `/speckit.tasks` → `/speckit.implement` flow.
10
10
 
11
- Se o usuário pedir para codar algo sem spec, PARE e inicie o fluxo SDD primeiro.
12
- Consulte `.specify/specs/` para verificar se existe spec para a demanda.
11
+ If the user asks to code something without a spec, STOP and initiate the SDD flow first.
12
+ Check `.specify/specs/` to verify if a spec already exists for the demand.
13
13
 
14
14
  ## Product Requirements Document
15
15
 
16
- O arquivo `PRD.md` na raiz do projeto contém os requisitos do produto definidos pelo analista/dev. Consulte-o para entender O QUE construir, as user stories, critérios de aceite, modelo de dados e API specification. Este AGENTS.md define COMO o agente deve trabalhar; o PRD define O QUE deve ser construído.
16
+ The `PRD.md` file at the project root contains the product requirements defined by the analyst/dev. Consult it to understand WHAT to build, the user stories, acceptance criteria, data model, and API specification. This AGENTS.md defines HOW the agent should work; the PRD defines WHAT should be built.
17
17
 
18
- - `PRD.md` — Requisitos do produto, user stories, API spec, modelo de dados
18
+ - `PRD.md` — Product requirements, user stories, API spec, data model
19
19
 
20
20
  ## References
21
21
 
22
- Documentos de referência que o agente deve consultar quando necessário:
22
+ Reference documents that the agent should consult when necessary:
23
23
 
24
- - `references/jhipster-jdl-guide.md` — Guia completo de JDL
25
- - `references/spring-boot-patterns.md` — Padrões Spring Boot
26
- - `references/angular-patterns.md` — Padrões Angular no JHipster
27
- - `references/liquibase-guide.md` — Guia de migrations Liquibase
24
+ - `references/jhipster-jdl-guide.md` — Complete JDL guide
25
+ - `references/spring-boot-patterns.md` — Spring Boot patterns
26
+ - `references/angular-patterns.md` — Angular patterns in JHipster
27
+ - `references/liquibase-guide.md` — Liquibase migrations guide
28
28
 
29
- ## Stack do projeto
29
+ ## Project Stack
30
30
 
31
- - **Backend:** Java 21 + Spring Boot 3.x (gerado pelo JHipster)
32
- - **Frontend:** Angular 17+ com TypeScript
33
- - **Banco:** PostgreSQL
34
- - **Cache:** Ehcache ou Redis
35
- - **Migrations:** Liquibase (padrão JHipster)
36
- - **Auth:** JWT (padrão JHipster) ou OAuth2/Keycloak
37
- - **Testes:** JUnit 5 + Mockito (back), Jest + Cypress (front)
38
- - **Build:** Maven ou Gradle
39
- - **API docs:** Swagger/OpenAPI (auto-gerado)
31
+ - **Backend:** Java 21 + Spring Boot 3.x (generated by JHipster)
32
+ - **Frontend:** Angular 17+ with TypeScript
33
+ - **Database:** PostgreSQL
34
+ - **Cache:** Ehcache or Redis
35
+ - **Migrations:** Liquibase (JHipster default)
36
+ - **Auth:** JWT (JHipster default) or OAuth2/Keycloak
37
+ - **Tests:** JUnit 5 + Mockito (back), Jest + Cypress (front)
38
+ - **Build:** Maven or Gradle
39
+ - **API docs:** Swagger/OpenAPI (auto-generated)
40
40
 
41
- ## Estrutura JHipster Monorepo
41
+ ## JHipster Monorepo Structure
42
42
 
43
43
  ```
44
44
  project/
45
45
  ├── src/
46
46
  │ ├── main/
47
- │ │ ├── java/com/empresa/projeto/
48
- │ │ │ ├── domain/ # Entidades JPA (enriquecer com DDD)
47
+ │ │ ├── java/com/company/project/
48
+ │ │ │ ├── domain/ # JPA Entities (enrich with DDD)
49
49
  │ │ │ │ ├── Demand.java
50
50
  │ │ │ │ ├── Task.java
51
51
  │ │ │ │ └── enumeration/
@@ -81,27 +81,27 @@ project/
81
81
  └── package.json # Frontend deps
82
82
  ```
83
83
 
84
- ## Padrões de código
84
+ ## Code Standards
85
85
 
86
86
  ### Java
87
- - Máximo 500 linhas por classe
88
- - Records para DTOs imutáveis (Java 21)
89
- - Optional ao invés de null returns
90
- - Streams API para coleções (não loops imperativos)
87
+ - Maximum 500 lines per class
88
+ - Records for immutable DTOs (Java 21)
89
+ - Optional instead of null returns
90
+ - Streams API for collections (not imperative loops)
91
91
  - Google Java Style Guide
92
- - Lombok apenas para: `@Slf4j`, `@RequiredArgsConstructor`. Evitar `@Data`.
93
- - Nunca `@Autowired` em campo usar constructor injection
92
+ - Lombok only for: `@Slf4j`, `@RequiredArgsConstructor`. Avoid `@Data`.
93
+ - Never `@Autowired` on fields -- use constructor injection
94
94
 
95
95
  ### Angular
96
- - Strict mode habilitado
96
+ - Strict mode enabled
97
97
  - Standalone components (Angular 17+)
98
- - Signals para estado reativo quando possível
99
- - Lazy loading por rota/feature
100
- - Reactive Forms com validação
98
+ - Signals for reactive state when possible
99
+ - Lazy loading per route/feature
100
+ - Reactive Forms with validation
101
101
 
102
- ## JDL Modelo de entidades
102
+ ## JDL -- Entity Model
103
103
 
104
- Usar JDL para definir entidades e gerar código:
104
+ Use JDL to define entities and generate code:
105
105
 
106
106
  ```jdl
107
107
  entity Demand {
@@ -141,19 +141,19 @@ dto * with mapstruct
141
141
  service * with serviceImpl
142
142
  ```
143
143
 
144
- ## Enriquecer JHipster com DDD
144
+ ## Enriching JHipster with DDD
145
145
 
146
- O JHipster gera entidades anêmicas por padrão. Enriqueça com comportamento:
146
+ JHipster generates anemic entities by default. Enrich them with behavior:
147
147
 
148
148
  ```java
149
- // NÃO FAZER entidade anêmica (padrão JHipster)
149
+ // DON'T -- anemic entity (JHipster default)
150
150
  public class Demand {
151
151
  private String description;
152
152
  private DemandStatus status;
153
- // apenas getters/setters
153
+ // only getters/setters
154
154
  }
155
155
 
156
- // FAZER entidade rica
156
+ // DO -- rich entity
157
157
  public class Demand {
158
158
  private String description;
159
159
  private DemandStatus status;
@@ -181,9 +181,9 @@ public class Demand {
181
181
  }
182
182
  ```
183
183
 
184
- ## Liquibase Migrations
184
+ ## Liquibase -- Migrations
185
185
 
186
- Sempre gerar changeset para mudanças de schema:
186
+ Always generate changesets for schema changes:
187
187
 
188
188
  ```xml
189
189
  <changeSet id="20260327-1" author="dev">
@@ -204,27 +204,27 @@ Sempre gerar changeset para mudanças de schema:
204
204
  </changeSet>
205
205
  ```
206
206
 
207
- ## Testes
207
+ ## Tests
208
208
 
209
- - **JUnit 5:** Testar services e entidades enriquecidas
210
- - **MockMvc:** Testar controllers (status codes, validação)
211
- - **Testcontainers:** Integração com PostgreSQL real
212
- - **Jest:** Componentes Angular
209
+ - **JUnit 5:** Test services and enriched entities
210
+ - **MockMvc:** Test controllers (status codes, validation)
211
+ - **Testcontainers:** Integration with real PostgreSQL
212
+ - **Jest:** Angular components
213
213
  - **Cypress:** E2E flows
214
- - Cobertura mínima: 80%
214
+ - Minimum coverage: 80%
215
215
 
216
216
  ## Git
217
217
 
218
- - Commits: `feat(demand): adicionar decomposição automática`
219
- - Branches: `feature/<entity>-<descricao>`
220
- - Nunca alterar arquivos gerados do JHipster sem necessidade
221
- - Regenerar com `jhipster import-jdl` quando mudar modelo
218
+ - Commits: `feat(demand): add automatic decomposition`
219
+ - Branches: `feature/<entity>-<description>`
220
+ - Never alter JHipster-generated files unnecessarily
221
+ - Regenerate with `jhipster import-jdl` when changing the model
222
222
 
223
- ## O que NÃO fazer
223
+ ## What NOT to do
224
224
 
225
- - Não editar manualmente arquivos que o JHipster regenera (liquibase gerado, webpack config)
226
- - Não colocar regras de negócio no REST controller
227
- - Não usar `@Transactional` em todo lugar só onde necessário
228
- - Não criar services genéricos "God class"
229
- - Não ignorar DTOs nunca expor entidade JPA na API
230
- - Não usar Lombok `@Data` (gera equals/hashCode perigoso com JPA)
225
+ - Do not manually edit files that JHipster regenerates (generated liquibase, webpack config)
226
+ - Do not put business rules in the REST controller
227
+ - Do not use `@Transactional` everywhere -- only where necessary
228
+ - Do not create generic "God class" services
229
+ - Do not ignore DTOs -- never expose JPA entities in the API
230
+ - Do not use Lombok `@Data` (generates dangerous equals/hashCode with JPA)