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.
- package/LICENSE +21 -0
- package/README.md +139 -169
- package/package.json +2 -2
- package/src/cli.mjs +75 -75
- package/templates/bundle-ai-agents/.spec/constitution.md +24 -24
- package/templates/bundle-ai-agents/AGENTS.md +71 -71
- package/templates/bundle-ai-agents/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-ai-agents-deep/.spec/constitution.md +17 -17
- package/templates/bundle-ai-agents-deep/AGENTS.md +58 -58
- package/templates/bundle-ai-agents-deep/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-ai-agents-deep/skills/deep-agent-memory/SKILL.md +158 -158
- package/templates/bundle-base/AGENTS.md +99 -99
- package/templates/bundle-data-pipeline/.spec/constitution.md +23 -23
- package/templates/bundle-data-pipeline/AGENTS.md +68 -68
- package/templates/bundle-data-pipeline/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-frontend-spa/.spec/constitution.md +21 -21
- package/templates/bundle-frontend-spa/AGENTS.md +58 -58
- package/templates/bundle-frontend-spa/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-jhipster-microservices/.spec/constitution.md +31 -31
- package/templates/bundle-jhipster-microservices/AGENTS.md +70 -70
- package/templates/bundle-jhipster-microservices/PRD_TEMPLATE.md +63 -63
- package/templates/bundle-jhipster-monorepo/.spec/constitution.md +22 -22
- package/templates/bundle-jhipster-monorepo/AGENTS.md +64 -64
- package/templates/bundle-jhipster-monorepo/PRD_TEMPLATE.md +63 -63
|
@@ -1,65 +1,65 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Project: Data and ML Pipeline
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
You are building a data pipeline that includes ingestion, processing, model training, and serving. The project uses Python with a focus on data engineering and machine learning.
|
|
4
4
|
|
|
5
5
|
## Specification-Driven Development (SDD)
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
**
|
|
9
|
-
|
|
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
|
-
|
|
12
|
-
|
|
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
|
-
|
|
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` —
|
|
18
|
+
- `PRD.md` — Product requirements, user stories, API spec, data model
|
|
19
19
|
|
|
20
20
|
## References
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
Reference documents that the agent should consult when necessary:
|
|
23
23
|
|
|
24
|
-
- `references/pandas-patterns.md` —
|
|
25
|
-
- `references/mlflow-guide.md` —
|
|
26
|
-
- `references/data-validation.md` —
|
|
24
|
+
- `references/pandas-patterns.md` — Pandas transformation patterns
|
|
25
|
+
- `references/mlflow-guide.md` — Experiment tracking guide
|
|
26
|
+
- `references/data-validation.md` — Validation with Pandera/Great Expectations
|
|
27
27
|
|
|
28
|
-
## Stack
|
|
28
|
+
## Project Stack
|
|
29
29
|
|
|
30
|
-
- **
|
|
31
|
-
- **
|
|
30
|
+
- **Language:** Python 3.11+
|
|
31
|
+
- **Data:** Pandas, Polars, NumPy
|
|
32
32
|
- **ML:** Scikit-learn, XGBoost, LightGBM
|
|
33
|
-
- **Deep Learning:** PyTorch (
|
|
34
|
-
- **Pipeline:** Apache Airflow
|
|
33
|
+
- **Deep Learning:** PyTorch (when needed)
|
|
34
|
+
- **Pipeline:** Apache Airflow or Prefect
|
|
35
35
|
- **Experiment Tracking:** MLflow
|
|
36
|
-
- **RAG (
|
|
37
|
-
- **
|
|
36
|
+
- **RAG (if applicable):** LangChain + pgvector
|
|
37
|
+
- **Database:** PostgreSQL
|
|
38
38
|
- **Containers:** Docker
|
|
39
|
-
- **
|
|
39
|
+
- **Validation:** Pandera, Great Expectations
|
|
40
40
|
|
|
41
|
-
##
|
|
41
|
+
## Project Structure
|
|
42
42
|
|
|
43
43
|
```
|
|
44
44
|
src/
|
|
45
45
|
├── data/
|
|
46
|
-
│ ├── raw/ #
|
|
47
|
-
│ ├── processed/ #
|
|
46
|
+
│ ├── raw/ # Original data (immutable, never edit)
|
|
47
|
+
│ ├── processed/ # Transformed data
|
|
48
48
|
│ └── features/ # Feature store
|
|
49
49
|
├── pipelines/
|
|
50
|
-
│ ├── ingestion/ #
|
|
51
|
-
│ ├── preprocessing/ #
|
|
52
|
-
│ ├── feature_engineering/ #
|
|
53
|
-
│ └── training/ #
|
|
50
|
+
│ ├── ingestion/ # Ingestion from external sources
|
|
51
|
+
│ ├── preprocessing/ # Cleaning and transformation
|
|
52
|
+
│ ├── feature_engineering/ # Feature creation
|
|
53
|
+
│ └── training/ # Training pipeline
|
|
54
54
|
├── models/
|
|
55
|
-
│ ├── training/ #
|
|
56
|
-
│ ├── evaluation/ #
|
|
57
|
-
│ └── serving/ # API
|
|
58
|
-
├── rag/ #
|
|
55
|
+
│ ├── training/ # Training scripts
|
|
56
|
+
│ ├── evaluation/ # Evaluation and metrics
|
|
57
|
+
│ └── serving/ # Inference API (FastAPI)
|
|
58
|
+
├── rag/ # If applicable
|
|
59
59
|
│ ├── ingest.py
|
|
60
60
|
│ ├── retriever.py
|
|
61
61
|
│ └── embeddings.py
|
|
62
|
-
├── notebooks/ #
|
|
62
|
+
├── notebooks/ # ONLY for exploration (does not go to prod)
|
|
63
63
|
├── tests/
|
|
64
64
|
│ ├── test_preprocessing.py
|
|
65
65
|
│ ├── test_features.py
|
|
@@ -69,50 +69,50 @@ src/
|
|
|
69
69
|
└── models_config.yaml
|
|
70
70
|
```
|
|
71
71
|
|
|
72
|
-
##
|
|
72
|
+
## Code Standards
|
|
73
73
|
|
|
74
|
-
-
|
|
75
|
-
- Type hints
|
|
76
|
-
- Docstrings
|
|
77
|
-
- Black + Ruff
|
|
78
|
-
- Notebook
|
|
74
|
+
- Maximum 500 lines per file, 20 lines per function
|
|
75
|
+
- Type hints on public functions
|
|
76
|
+
- Docstrings on data transformation functions (input/output)
|
|
77
|
+
- Black + Ruff for formatting
|
|
78
|
+
- Notebook -> Python script before going to production
|
|
79
79
|
|
|
80
|
-
##
|
|
80
|
+
## Data Standards
|
|
81
81
|
|
|
82
|
-
-
|
|
83
|
-
-
|
|
84
|
-
-
|
|
85
|
-
-
|
|
86
|
-
- Logging
|
|
82
|
+
- Original data is IMMUTABLE -- never edit `raw/`
|
|
83
|
+
- Each transformation is a pure function (input -> output, no side effects)
|
|
84
|
+
- Validate schema at the entry of each pipeline step (Pandera)
|
|
85
|
+
- Dataset versioning with DVC
|
|
86
|
+
- Logging of all transformations
|
|
87
87
|
|
|
88
|
-
##
|
|
88
|
+
## ML Standards
|
|
89
89
|
|
|
90
|
-
-
|
|
91
|
-
- Cross-validation k=5
|
|
92
|
-
-
|
|
93
|
-
- Feature importance
|
|
94
|
-
-
|
|
95
|
-
- A/B testing
|
|
90
|
+
- Every model needs a baseline (majority class, mean, linear regression)
|
|
91
|
+
- Cross-validation k=5 minimum
|
|
92
|
+
- Documented metrics: accuracy, precision, recall, F1, AUC
|
|
93
|
+
- Feature importance recorded in MLflow
|
|
94
|
+
- Serialized model with version
|
|
95
|
+
- A/B testing before replacing a model in production
|
|
96
96
|
|
|
97
97
|
## Git
|
|
98
98
|
|
|
99
|
-
- Commits: `feat(preprocessing):
|
|
100
|
-
- Branches: `feature/<pipeline>-<
|
|
101
|
-
-
|
|
102
|
-
-
|
|
99
|
+
- Commits: `feat(preprocessing): add salary normalization`
|
|
100
|
+
- Branches: `feature/<pipeline>-<description>`
|
|
101
|
+
- Never commit data (use .gitignore, DVC for data)
|
|
102
|
+
- Never commit binary models (use MLflow registry)
|
|
103
103
|
|
|
104
|
-
##
|
|
104
|
+
## Tests
|
|
105
105
|
|
|
106
|
-
-
|
|
107
|
-
-
|
|
108
|
-
-
|
|
109
|
-
-
|
|
106
|
+
- Schema tests (Pandera) for each transformation
|
|
107
|
+
- Unit tests for feature engineering functions
|
|
108
|
+
- Regression tests for model metrics
|
|
109
|
+
- Minimum coverage: 80% on transformation pipelines
|
|
110
110
|
|
|
111
|
-
##
|
|
111
|
+
## What NOT to do
|
|
112
112
|
|
|
113
|
-
-
|
|
114
|
-
-
|
|
115
|
-
-
|
|
116
|
-
-
|
|
117
|
-
-
|
|
118
|
-
-
|
|
113
|
+
- Do not put notebooks in production without refactoring
|
|
114
|
+
- Do not train without a baseline
|
|
115
|
+
- Do not ignore data drift
|
|
116
|
+
- Do not use inconsistent random seeds
|
|
117
|
+
- Do not hardcode paths -- use config
|
|
118
|
+
- Do not use SELECT * on large data queries
|
|
@@ -1,50 +1,50 @@
|
|
|
1
1
|
# Product Requirements Document (PRD)
|
|
2
2
|
|
|
3
|
-
>
|
|
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.
|
|
5
|
+
## 1. Executive Summary
|
|
6
6
|
|
|
7
|
-
<!--
|
|
7
|
+
<!-- Describe in 2-3 sentences what the product is and what problem it solves -->
|
|
8
8
|
|
|
9
|
-
## 2.
|
|
9
|
+
## 2. Target Users
|
|
10
10
|
|
|
11
|
-
<!--
|
|
11
|
+
<!-- Who will use the system? Describe the personas -->
|
|
12
12
|
|
|
13
|
-
### Persona 1: [
|
|
14
|
-
- **
|
|
15
|
-
- **
|
|
16
|
-
- **
|
|
13
|
+
### Persona 1: [Name]
|
|
14
|
+
- **Profile:**
|
|
15
|
+
- **Goals:**
|
|
16
|
+
- **Pain points:**
|
|
17
17
|
|
|
18
|
-
## 3.
|
|
18
|
+
## 3. MVP Scope
|
|
19
19
|
|
|
20
|
-
###
|
|
20
|
+
### Included in MVP
|
|
21
21
|
- [ ] Feature 1
|
|
22
22
|
- [ ] Feature 2
|
|
23
23
|
- [ ] Feature 3
|
|
24
24
|
|
|
25
|
-
###
|
|
26
|
-
- [ ]
|
|
27
|
-
- [ ]
|
|
25
|
+
### Out of MVP (future)
|
|
26
|
+
- [ ] Future feature 1
|
|
27
|
+
- [ ] Future feature 2
|
|
28
28
|
|
|
29
29
|
## 4. User Stories
|
|
30
30
|
|
|
31
|
-
### US01: [
|
|
32
|
-
**
|
|
31
|
+
### US01: [Title]
|
|
32
|
+
**As** [persona], **I want** [action], **so that** [benefit].
|
|
33
33
|
|
|
34
|
-
**
|
|
35
|
-
- [ ]
|
|
36
|
-
- [ ]
|
|
34
|
+
**Acceptance criteria:**
|
|
35
|
+
- [ ] AC1:
|
|
36
|
+
- [ ] AC2:
|
|
37
37
|
|
|
38
|
-
### US02: [
|
|
39
|
-
**
|
|
38
|
+
### US02: [Title]
|
|
39
|
+
**As** [persona], **I want** [action], **so that** [benefit].
|
|
40
40
|
|
|
41
|
-
**
|
|
42
|
-
- [ ]
|
|
43
|
-
- [ ]
|
|
41
|
+
**Acceptance criteria:**
|
|
42
|
+
- [ ] AC1:
|
|
43
|
+
- [ ] AC2:
|
|
44
44
|
|
|
45
|
-
## 5.
|
|
45
|
+
## 5. High-Level Architecture
|
|
46
46
|
|
|
47
|
-
<!--
|
|
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
|
-
###
|
|
55
|
+
### Directory Structure
|
|
56
56
|
|
|
57
57
|
```
|
|
58
58
|
project/
|
|
@@ -61,29 +61,29 @@ project/
|
|
|
61
61
|
└── ...
|
|
62
62
|
```
|
|
63
63
|
|
|
64
|
-
## 6. Features
|
|
64
|
+
## 6. Detailed Features
|
|
65
65
|
|
|
66
|
-
### Feature 1: [
|
|
67
|
-
- **
|
|
68
|
-
- **
|
|
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: [
|
|
76
|
-
- **
|
|
77
|
-
- **
|
|
75
|
+
### Feature 2: [Name]
|
|
76
|
+
- **Description:**
|
|
77
|
+
- **Business rules:**
|
|
78
78
|
-
|
|
79
79
|
|
|
80
|
-
## 7. Stack
|
|
80
|
+
## 7. Technology Stack
|
|
81
81
|
|
|
82
|
-
|
|
|
82
|
+
| Component | Technology | Justification |
|
|
83
83
|
|---|---|---|
|
|
84
84
|
| Backend | | |
|
|
85
85
|
| Frontend | | |
|
|
86
|
-
|
|
|
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
|
-
- **
|
|
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
|
-
- **
|
|
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.
|
|
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.
|
|
126
|
+
## 10. Non-Functional Requirements
|
|
127
127
|
|
|
128
|
-
|
|
|
128
|
+
| Requirement | Target | Priority |
|
|
129
129
|
|---|---|---|
|
|
130
|
-
| Performance | Response time < 500ms |
|
|
131
|
-
|
|
|
132
|
-
|
|
|
133
|
-
|
|
|
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.
|
|
135
|
+
## 11. Implementation Phases
|
|
136
136
|
|
|
137
|
-
###
|
|
138
|
-
- [ ]
|
|
139
|
-
- [ ]
|
|
140
|
-
- [ ]
|
|
137
|
+
### Phase 1: Foundation
|
|
138
|
+
- [ ] Project setup
|
|
139
|
+
- [ ] Data model
|
|
140
|
+
- [ ] Basic endpoints
|
|
141
141
|
|
|
142
|
-
###
|
|
143
|
-
- [ ] Feature 1
|
|
144
|
-
- [ ] Feature 2
|
|
142
|
+
### Phase 2: Core Features
|
|
143
|
+
- [ ] Feature 1 complete
|
|
144
|
+
- [ ] Feature 2 complete
|
|
145
145
|
|
|
146
|
-
###
|
|
147
|
-
- [ ]
|
|
146
|
+
### Phase 3: Polish
|
|
147
|
+
- [ ] E2E tests
|
|
148
148
|
- [ ] Performance
|
|
149
|
-
- [ ]
|
|
149
|
+
- [ ] Documentation
|
|
150
150
|
|
|
151
|
-
## 12.
|
|
151
|
+
## 12. Risks and Mitigations
|
|
152
152
|
|
|
153
|
-
|
|
|
153
|
+
| Risk | Impact | Probability | Mitigation |
|
|
154
154
|
|---|---|---|---|
|
|
155
155
|
| | | | |
|
|
156
156
|
|
|
157
|
-
## 13.
|
|
157
|
+
## 13. Success Criteria
|
|
158
158
|
|
|
159
|
-
- [ ]
|
|
160
|
-
- [ ]
|
|
161
|
-
- [ ]
|
|
159
|
+
- [ ] Criterion 1
|
|
160
|
+
- [ ] Criterion 2
|
|
161
|
+
- [ ] Criterion 3
|
|
@@ -1,32 +1,32 @@
|
|
|
1
|
-
# Constitution —
|
|
1
|
+
# Constitution — Frontend SPA Project
|
|
2
2
|
|
|
3
|
-
##
|
|
3
|
+
## Principles
|
|
4
4
|
|
|
5
|
-
1. **Spec
|
|
6
|
-
2. **
|
|
7
|
-
3. **Server state
|
|
8
|
-
4. **TypeScript strict** — Zero `any`, types
|
|
9
|
-
5. **Mobile-first** —
|
|
5
|
+
1. **Spec first, code later** — Every demand goes through the SDD flow before implementation
|
|
6
|
+
2. **Component = 1 responsibility** — Small and focused components
|
|
7
|
+
3. **Server state in React Query** — Never duplicate API data in global state
|
|
8
|
+
4. **TypeScript strict** — Zero `any`, types for everything
|
|
9
|
+
5. **Mobile-first** — Write for mobile, breakpoints for desktop
|
|
10
10
|
|
|
11
|
-
##
|
|
11
|
+
## Development Standards
|
|
12
12
|
|
|
13
13
|
- React 18+, TypeScript strict mode
|
|
14
14
|
- Tailwind CSS + Shadcn/UI
|
|
15
15
|
- Feature-based folder structure
|
|
16
|
-
- Custom hooks
|
|
17
|
-
- React Hook Form + Zod
|
|
16
|
+
- Custom hooks for reusable logic
|
|
17
|
+
- React Hook Form + Zod for forms
|
|
18
18
|
|
|
19
|
-
##
|
|
19
|
+
## Component Standards
|
|
20
20
|
|
|
21
|
-
-
|
|
22
|
-
- Loading/Error/Empty states
|
|
23
|
-
-
|
|
24
|
-
- Lazy loading
|
|
25
|
-
-
|
|
21
|
+
- Composition over configuration
|
|
22
|
+
- Loading/Error/Empty states on every async
|
|
23
|
+
- Accessibility: semantic HTML, aria-labels
|
|
24
|
+
- Lazy loading per route
|
|
25
|
+
- Maximum 200 lines per component
|
|
26
26
|
|
|
27
|
-
##
|
|
27
|
+
## Quality Standards
|
|
28
28
|
|
|
29
|
-
- Vitest + Testing Library
|
|
30
|
-
- Playwright
|
|
31
|
-
-
|
|
32
|
-
- Commits
|
|
29
|
+
- Vitest + Testing Library for components
|
|
30
|
+
- Playwright for E2E
|
|
31
|
+
- Minimum coverage: 70%
|
|
32
|
+
- Commits follow Conventional Commits
|
|
@@ -1,110 +1,110 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Project: Frontend SPA (Single Page Application)
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
You are building a modern frontend application with React, TypeScript, and Tailwind CSS that consumes REST or GraphQL APIs.
|
|
4
4
|
|
|
5
5
|
## Specification-Driven Development (SDD)
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
**
|
|
9
|
-
|
|
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
|
-
|
|
12
|
-
|
|
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
|
-
|
|
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` —
|
|
18
|
+
- `PRD.md` — Product requirements, user stories, API spec, data model
|
|
19
19
|
|
|
20
20
|
## References
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
Reference documents that the agent should consult when necessary:
|
|
23
23
|
|
|
24
|
-
- `references/react-component-patterns.md` —
|
|
25
|
-
- `references/tailwind-design-system.md` — Design system
|
|
26
|
-
- `references/testing-library-guide.md` —
|
|
24
|
+
- `references/react-component-patterns.md` — React component patterns
|
|
25
|
+
- `references/tailwind-design-system.md` — Design system with Tailwind
|
|
26
|
+
- `references/testing-library-guide.md` — Testing Library guide
|
|
27
27
|
|
|
28
|
-
## Stack
|
|
28
|
+
## Project Stack
|
|
29
29
|
|
|
30
|
-
- **Framework:** React 18+
|
|
30
|
+
- **Framework:** React 18+ with TypeScript (strict mode)
|
|
31
31
|
- **Bundler:** Vite
|
|
32
|
-
- **
|
|
33
|
-
- **
|
|
34
|
-
- **
|
|
32
|
+
- **Styling:** Tailwind CSS + Shadcn/UI
|
|
33
|
+
- **State:** Zustand (global) + React Query (server state)
|
|
34
|
+
- **Routing:** React Router v6+
|
|
35
35
|
- **Forms:** React Hook Form + Zod
|
|
36
36
|
- **HTTP:** Axios
|
|
37
|
-
- **WebSocket:** Socket.io-client (
|
|
38
|
-
- **
|
|
37
|
+
- **WebSocket:** Socket.io-client (if real-time)
|
|
38
|
+
- **Tests:** Vitest + Testing Library + Playwright (E2E)
|
|
39
39
|
|
|
40
|
-
##
|
|
40
|
+
## Project Structure
|
|
41
41
|
|
|
42
42
|
```
|
|
43
43
|
src/
|
|
44
|
-
├── features/ #
|
|
44
|
+
├── features/ # Organized by feature/domain
|
|
45
45
|
│ ├── demands/
|
|
46
|
-
│ │ ├── components/ #
|
|
46
|
+
│ │ ├── components/ # Feature components
|
|
47
47
|
│ │ │ ├── DemandList.tsx
|
|
48
48
|
│ │ │ ├── DemandCard.tsx
|
|
49
49
|
│ │ │ └── DemandForm.tsx
|
|
50
50
|
│ │ ├── hooks/ # Custom hooks
|
|
51
51
|
│ │ │ └── useDemands.ts
|
|
52
|
-
│ │ ├── services/ #
|
|
52
|
+
│ │ ├── services/ # API calls
|
|
53
53
|
│ │ │ └── demandApi.ts
|
|
54
|
-
│ │ ├── types.ts #
|
|
54
|
+
│ │ ├── types.ts # Feature types
|
|
55
55
|
│ │ └── index.ts # Barrel export
|
|
56
56
|
│ ├── dashboard/
|
|
57
57
|
│ └── auth/
|
|
58
|
-
├── shared/ #
|
|
58
|
+
├── shared/ # Shared across features
|
|
59
59
|
│ ├── components/ # Button, Modal, Table, etc.
|
|
60
60
|
│ ├── hooks/ # useDebounce, useLocalStorage, etc.
|
|
61
61
|
│ ├── lib/ # api.ts (axios instance), utils
|
|
62
|
-
│ └── types/ #
|
|
62
|
+
│ └── types/ # Global types
|
|
63
63
|
├── layouts/ # AppLayout, AuthLayout
|
|
64
|
-
├── routes/ #
|
|
65
|
-
├── config/ #
|
|
66
|
-
├── styles/ #
|
|
64
|
+
├── routes/ # Route configuration
|
|
65
|
+
├── config/ # Constants, env vars
|
|
66
|
+
├── styles/ # Global CSS
|
|
67
67
|
└── tests/
|
|
68
68
|
├── e2e/ # Playwright
|
|
69
69
|
└── setup.ts # Vitest setup
|
|
70
70
|
```
|
|
71
71
|
|
|
72
|
-
##
|
|
72
|
+
## Code Standards
|
|
73
73
|
|
|
74
|
-
-
|
|
75
|
-
- Props
|
|
76
|
-
-
|
|
77
|
-
- Custom hooks
|
|
78
|
-
- Server state
|
|
79
|
-
- React Hook Form + Zod
|
|
80
|
-
- Lazy loading
|
|
74
|
+
- Maximum 200 lines per component
|
|
75
|
+
- Props typed with interface (not type)
|
|
76
|
+
- One component = one responsibility
|
|
77
|
+
- Custom hooks for reusable logic
|
|
78
|
+
- Server state in React Query, UI state in Zustand
|
|
79
|
+
- React Hook Form + Zod for forms
|
|
80
|
+
- Lazy loading per route
|
|
81
81
|
|
|
82
|
-
##
|
|
82
|
+
## Component Standards
|
|
83
83
|
|
|
84
|
-
-
|
|
85
|
-
- Container/Presenter
|
|
86
|
-
- Loading/Error/Empty states
|
|
87
|
-
-
|
|
84
|
+
- Composition > configuration (slots > boolean props)
|
|
85
|
+
- Container/Presenter for complex components
|
|
86
|
+
- Loading/Error/Empty states on every async component
|
|
87
|
+
- Accessibility: semantic HTML, aria-labels, keyboard nav
|
|
88
88
|
|
|
89
89
|
## Git
|
|
90
90
|
|
|
91
91
|
- Commits: `feat(demands): adicionar filtro por status`
|
|
92
|
-
- Branches: `feature/<feature>-<
|
|
93
|
-
-
|
|
92
|
+
- Branches: `feature/<feature>-<description>`
|
|
93
|
+
- Never commit node_modules, .env, dist/
|
|
94
94
|
|
|
95
|
-
##
|
|
95
|
+
## Tests
|
|
96
96
|
|
|
97
|
-
- Vitest + Testing Library:
|
|
98
|
-
- Playwright:
|
|
99
|
-
-
|
|
100
|
-
-
|
|
97
|
+
- Vitest + Testing Library: components and hooks
|
|
98
|
+
- Playwright: E2E flows (login, CRUD, navigation)
|
|
99
|
+
- Minimum coverage: 70%
|
|
100
|
+
- Test behavior, not implementation
|
|
101
101
|
|
|
102
|
-
##
|
|
102
|
+
## What NOT to do
|
|
103
103
|
|
|
104
|
-
-
|
|
105
|
-
-
|
|
106
|
-
-
|
|
107
|
-
-
|
|
108
|
-
-
|
|
109
|
-
-
|
|
110
|
-
-
|
|
104
|
+
- Do not use `any` in TypeScript
|
|
105
|
+
- Do not fetch inside the component (use React Query)
|
|
106
|
+
- Do not duplicate API data in global state
|
|
107
|
+
- Do not use index as key in dynamic lists
|
|
108
|
+
- Do not create mega-components of 500+ lines
|
|
109
|
+
- Do not ignore loading/error states
|
|
110
|
+
- Do not style with inline CSS when you have Tailwind
|